Для балансировки между сопряженными метриками необходимо четко определить бизнес-цели и установить приоритеты: что важнее для организации в данный момент. Затем определить допустимые диапазоны значений для каждой метрики, при которых процесс будет эффективен. Решение принимается волевым управлением после анализа потенциальных последствий и консультации с заинтересованными сторонами, учитывая, насколько можно ухудшить второстепенную метрику, чтобы улучшить основную.

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

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

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

Постепенное 'протухание' отложенных задач негативно влияет на качество работы тем, что с каждым днем пребывания в статусе 'Отложено' задача становится менее актуальной и нужной. Результат теряет ценность, что соответствует принципу бережливого производства: 'Незавершёнка есть потери!'. Кроме того, команда постепенно теряет контекст работы над задачей - забывает, что именно нужно было сделать, почему задача отложена, что осталось сделать и как исправить возможные проблемы. Это приводит к росту дефектов в конечном продукте и необходимости специализированного управления дефектами.

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

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

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

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

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