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

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

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

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

Для разработки отчётности по измерению доступности бизнес-процессов необходимы следующие компоненты: 1) чётко определённые критические функции бизнеса (VBF) или упрощённые функциональные блоки; 2) установленные связи между VBF/функциональными блоками и конкретными ИТ-услугами/компонентами; 3) разработанные критерии доступности для каждого VBF/блоков и компонентов услуг; 4) механизмы сбора данных о доступности компонентов ИТ-услуг; 5) алгоритмы агрегирования данных о доступности компонентов до уровня VBF/функциональных блоков; 6) система визуализации и презентации этих данных в форме, понятной бизнесу. Отчётность должна позволять рассчитывать итоговые показатели доступности ИТ-обеспечения бизнес-процессов на основе данных нижнего уровня.

Формальные измерения, такие как SLA, часто не вызывают интереса у бизнес-заказчика, потому что то, что можно легко измерить формально, обычно не соответствует реальным бизнес-результатам, которые нужны заказчику. Например, бизнесу важен конечный результат («в номере было комфортно»), а не формальные показатели («кондиционер есть»). В ИТ-сфере аналогично - бизнесу важен вклад в бизнес-результаты, а не технические показатели доступности систем. Как сказано в тексте, это создает разрыв между тем, что сервис-провайдер может четко определить и измерить, и тем, что на самом деле представляет ценность для заказчика. Поэтому заказчику нередко кажется, что формальные показатели и сервисные контракты не отражают реальных потребностей его бизнеса.

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

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

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

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