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

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

Governance в контексте аутсорсинга процессов — это роль заказчика, которая предполагает стратегическое руководство и контроль за выполнением процесса на высоком уровне. Заказчик определяет цели, стандарты и ожидаемые результаты, но не участвует в оперативном управлении и не контролирует ежедневные задачи. Это позволяет заказчику сосредоточиться на ключевых бизнес-целях, делегируя исполнение поставщику.

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

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

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

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

Негативные последствия фокуса только на выходах: снижение качества услуг, когда, например, сервис-деск сокращает время звонка (выход), но не решает фактических проблем клиентов, что приводит к росту жалоб в регулирующие органы; потраченные впустую ресурсы на технические реализации, которые не приносят бизнес-ценности (как внедрение крутого API без интеграции с CRM); ухудшение репутации компании и финансовые потери, как в случае с дискаунтером «Светофор», где фокус на количестве магазинов привел к серьезным нарушениям и закрытию точек; утрата доверия бизнеса к ИТ-отделу из-за отсутствия вклада в достижение стратегических целей.

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

ITIL 4 не упоминает приоритизацию в процессе решения инцидента (Incident handling and resolution), потому что она переквалифицирована из отдельного шага процесса в фактор успеха всей практики управления инцидентами. Приоритизация остается важной, но теперь рассматривается как более широкая концепция, которая необходима для достижения основной цели практики — минимизации негативного влияния инцидентов. Поскольку приоритизация может происходить многократно и на разных этапах работы с инцидентами, её нецелесообразно ограничивать одним отдельным шагом в процессе. Вместо этого она представляется как элемент, который требуется для эффективного выполнения всей практики в целом.