В контексте противопоставления оперативных вопросов и развития под 'развитием' понимаются долгосрочные задачи, направленные на рост как личный, так и компании в целом. Это не те задачи, которые приносят немедленное удовлетворение или решают текущие проблемы, но которые необходимы для будущего успеха. К таким задачам можно отнести: - Стратегическое планирование - Обучение новым навыкам и технологиям - Создание новых бизнес-моделей и процессов - Развитие команды и культуры компании - Инвестиции в перспективные, но пока нерентабельные направления Автор отмечает, что на такие задачи время обычно выделяется по остаточному принципу, то есть почти не выделяется, что создаёт проблему для долгосрочного развития.

'Ценностное предложение' в контексте определения услуги означает, что услуги создаются и предоставляются для удовлетворения конкретных потребностей клиентов, позволяя им достигать желаемых результатов. Ценность услуги определяется способностью услуги решать задачи или проблемы, стоящие перед клиентом, при этом клиент не берет на себя ответственность за внутренние процессы и ресурсы поставщика. Например, в случае центрального водоснабжения ценностное предложение заключается в возможности получения горячей воды для повседневных нужд без необходимости управлять очистными сооружениями или водопроводной системой.

Из провала проекта можно извлечь несколько важных уроков: важно своевременно проводить ретроспективы и выделять пункты для улучшения по таким аспектам, как коммуникация, распределение ролей, взаимодействие и отчетность. Необходимо вовремя задавать уточняющие вопросы заказчику, чтобы понимать его реальные потребности. Также важно не откладывать кардинальные изменения до последнего момента и быть готовым к оперативной адаптации планов. Ключевым уроком является то, что даже самый безнадежный проект можно спасти при наличии воли ключевых участников и слаженной работы всей команды.

В контексте ITSM могут быть переданы на аутсорсинг такие процессы, как управление изменениями, управление инцидентами, управление проблемами и другие процессы управления ИТ-услугами. При этом передается не просто выполнение задач, но и ответственность за организацию всего процесса, что делает такую модель более сложной и глубокой по сравнению с краткосрочным проектным аутсорсингом.

ИТ-служба может решать множество внутренних задач без применения сервисного подхода, таких как поддержание технической инфраструктуры, управление доступом, обеспечение безопасности данных, обновление программного обеспечения и другие операционные задачи. Эти задачи являются стандартными для любой ИТ-службы и не зависят от взаимодействия с заказчиками в формате предоставления услуг. Они ориентированы на стабильность и функциональность системы, а не на удовлетворение запросов внешних или внутренних заказчиков.

Главное отличие COBIT 5 PAM от COBIT 4.1 состоит в методологии оценки зрелости процессов. COBIT 4.1 использовал шкалу зрелости с описанием содержания процессов на каждом уровне, что было более наглядно, но менее объективно. COBIT 5 PAM, следуя стандарту ISO/IEC 15504, фокусируется на оценке управленческой надстройки процессов через шесть уровней способности, не зависящих от содержания процесса. Это позволяет проводить более объективные и воспроизводимые оценки, применимые к любым процессам и отраслям. При этом COBIT 5 PAM становится более абстрактной и сложной для понимания, но повышает качество оценки за счет устранения субъективных интерпретаций и опоры на реальные свидетельства выполнения управленческих практик.

Суть концепции деления задач объясняется через пример создания слона. Вместо разделения слона на несвязанные части (уши, ноги, хвост), которые не формируют целостный продукт, следует начать с минимально жизнеспособной версии — слонёнка, который, несмотря на упрощения (например, один глаз, короткий хобот), всё ещё является слоном и способен выполнять базовые функции. С каждым этапом разработки слонёнок постепенно обрастает 'жирком', то есть получает новые функции, сохраняя при этом работоспособность. Это демонстрирует, что цель — не сборка частей, а постепенное улучшение рабочего прототипа.

В отличие от управления инцидентами, для управления проблемами нет строгих целевых сроков решения. Проблема в статусе «известной ошибки» может находиться в таком состоянии бесконечно долго. Однако на этапах управления проблемами могут устанавливаться контрольные сроки, например, на диагностику, применение решения или проверку эффективности решения. Эта гибкость объясняется тем, что управление проблемами часто требует глубокого анализа и разработки коренных решений, что может занять значительно больше времени.

Автор описывает эволюцию своего отношения к проблемам управления временем следующим образом: Изначально, работая на стороне заказчика, времени на выполнение всех задач в основном хватало, несмотря на периодические авралы. Тогда не было острой нехватки времени, и даже оставалось пространство для изучения новых технологий и методик. После перехода в консалтинг ситуация резко изменилась — рабочая загрузка возросла до 120-160%, что привело к острой нехватке времени и постановке вопроса 'как это всё можно успеть'. Это заставило начать поиски решений в области тайм-менеджмента. Создание собственного бизнеса усугубило проблему, сделав управление временем ещё более сложной задачей. Автор отмечает, что обращался к этой теме неоднократно раньше, писал статьи на эту тему, но никогда не формулировал чётко саму задачу, которую пытается решать. Только сейчас он осознал важность точного обозначения проблемы и выделил четыре её основные составляющие.

Чем ближе сотрудник к выполнению задач, тем детальнее он знает контекст. Старший группы видит операционные проблемы, менеджер процесса — стратегические последствия. Если аналитику формирует не тот уровень, ответственность за который оценивается, теряются важные детали. Например, менеджер может не знать, что сроки выполнены за счет качества, а автоматизированная система не отразит эту связь. Поэтому аналитика должна добавляться на уровне, где принимались решения и решались задачи.