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

Техническая услуга - это компонент внутренней инфраструктуры, который не имеет прямого контакта с конечными пользователями бизнеса. OLA (Operational Level Agreement) - это внутреннее соглашение между подразделениями ИТ-организации, определяющее обязательства каждой части организации по поддержке конечных бизнес-услуг. Наличие каталога технических услуг и OLA часто недооценивается по своим последствиям, которые значительно влияют на другие процессы, отношения между подразделениями и даже оргструктуру. Однако такая практика управления применима только к очень небольшой доле компаний, где реализован сервисный подход.

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

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

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

Для определения данных, подлежащих переносу в CMDB, используются следующие критерии: 1) Удобство использования - данные должны быть доступны в интерфейсе CMDB без перехода в другие системы; 2) Необходимость поиска - если требуется выполнять поиск или группировку конфигурационных элементов (КЕ) по определенному атрибуту, этот атрибут должен находиться в самой CMDB; 3) Потребность в отчетности - если для формирования отчетов по КЕ требуются атрибуты из внешних систем, необходимо либо перенести эти атрибуты в CMDB, либо создать консолидированный источник данных для отчетов.

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

Для связи ИТ-метрик с бизнес-целями следует заменить показатели, фокусирующиеся только на выходах, на метрики, влияющие на результаты. Вместо 'времени ответа на запрос' измерять 'рост NPS клиентов', вместо 'количества релизов' - 'ускорение вывода продукта на рынок'. Хороший пример - компания Ford, которая заменила KPI 'количество строк кода' на 'снижение времени сборки авто', повысив эффективность ИТ на 200%. Необходимо всегда проверять, как технические метрики влияют на конечные бизнес-результаты и перестроить систему отчетности и поощрений вокруг этих результатов.

Важно учитывать как warranty, так и utility при оценке качества ИТ-услуг, потому что они охватывают разные, но взаимодополняющие аспекты восприятия качества. Utility отвечает за соответствие услуги бизнес-потребностям и функциональным требованиям заказчика, а warranty гарантирует стабильность, доступность и безопасность предоставления услуги. Наличие только одного аспекта недостаточно: даже самая функциональная услуга (высокая utility) будет непригодна, если она ненадежна (низкая warranty), и наоборот – надежная, но ненужная услуга (высокая warranty, низкая utility) не будет удовлетворять потребности заказчика.

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