В версии стандарта ISO 20000 за 2005 год было указано требование «There shall be an integrated approach to change and configuration management planning», предписывающее использовать интегрированный подход к планированию этих процессов. Однако в обновлённой версии 2011 года данная формулировка была удалена, что отразило более гибкий подход к взаимодействию процессов, позволяющий организациям самостоятельно определять степень их интеграции в зависимости от специфики бизнеса.

Рефакторинг кода может не привести к ожидаемому результату из-за недостаточного понимания задачи исполнителем и эффекта Даннинга-Крюгера. В тексте приводится пример, когда команда обсудила план рефакторинга, но через месяц выяснилось, что исполнитель просто переносил проблему в другой слой системы, вместо того чтобы решать её. Это произошло потому, что человек не осознавал своей недостаточной компетентности в вопросе рефакторинга, считая, что его действия приведут к улучшению кода. Автор отмечает, что такой случай не уникален: «каждый человек понимает «в меру своей испорченности», переоценивает свои умения, не понимая истинной глубины своей некомпетентности». Поэтому важно не только обсудить план, но и обеспечить постоянный контроль и коммуникацию в процессе выполнения задачи.

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

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

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

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

Некорректное применение emergency-процедуры, например, использование её для некритических изменений, ведёт к деградации процесса управления. Риск в том, что команда начнёт игнорировать настоящие emergency-ситуации, так как «крик волка» станет обыденным. Кроме того, постоянное переключение ресурсов на ложные тревоги замедлит выполнение плановых задач и ухудшит стабильность системы. Например, если патч безопасности внедрятся со сдвигом из-за ложного emergency-запроса на косметическое изменение, это может привести к реальной утечке данных.

Пример Twitter иллюстрирует необходимость разделения потоков ценности на основе инициативы по добавлению кнопки 'Купить'. Эта кнопка представляла собой отдельный вид бизнеса (торговую площадку для партнеров), а не просто техническую задачу добавления элемента интерфейса. Twitter, изначально основанный на рекламной модели, получил дополнительную ценностную составляющую. Пример показывает, что Twitter содержит как минимум три взаимосвязанных блока потоков: Community (коммуникационная платформа), Advertising (рекламный бизнес) и Marketplace (торговая площадка). Эти потоки создают разную по природе ценность: Community формирует аудиторию (измеряется в натуральных единицах), Advertising и Marketplace создают выручку (измеряются в финансах). При этом они сильно зависят друг от друга и могут конфликтовать за ресурсы.

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

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