ITIL 4 упрощает формулирование ключевых показателей эффективности (KPI) благодаря подробному описанию каждого фактора успеха практики (PSF) и предоставлению сопровождающих примеров метрик, которые можно использовать в качестве KPI. Описания практик в ITIL 4 стали более практико-ориентированными, что позволяет легче определить, какие показатели следует измерять для оценки эффективности конкретных практик в контексте их вклада в потоки создания ценности. В ITILv3 подход был более процесс-ориентированным, и, хотя концепция CSF также позволяла формулировать KPI, в ITIL 4 это становится проще благодаря более структурированному и конкретному описанию факторов успеха.

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

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

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

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

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

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

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

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

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