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

CLD помогает в определении опережающих и отложенных показателей, отображая причинно-следственные связи между элементами системы. Отложенные показатели (trailing indicators) напрямую связаны с конечным результатом и отражают уже случившиеся события (например, 'Percentage of Changes Without Recurring incidents' для оценки Change Risk). Опережающие показатели (leading indicators) связаны с факторами, которые влияют на конечный результат (например, 'Release size' и 'Emergency change rate' для прогноза уровня риска изменений). Это позволяет использовать опережающие показатели для прогнозирования будущих результатов и своевременной корректировки процесса.

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

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

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

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

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

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

Чтобы преобразовать продажу товара в продажу услуги, необходимо определить, какие риски и затраты клиент может переложить на поставщика. Например, простая продажа шоколадки - это товарная модель, где клиент сам решает вопросы ее приобретения и хранения. Чтобы превратить это в услугу, можно добавить компоненты: 1) Регулярная доставка (покупатель получает шоколадку к утреннему кофе без необходимости самому ее покупать); 2) Обеспечение доступности через автомат (ресурс - сам автомат, операции - его загрузка и обслуживание). Таким образом, клиент не просто получает товар, но и перекладывает на поставщика ответственность за обеспечение доступности и своевременности получения товара, что и составляет суть услуги.

В процессе управления релизами ITIL V3 выделены следующие технические роли: Практик пакетирования и построения релизов, занимающийся сборкой и подготовкой компонентов релиза; Практик развёртывания релизов, отвечающий за внедрение релиза в производственную среду и подготовку документации; Практик первичной (early life) поддержки, обеспечивающий поддержку системы в начальный период эксплуатации после релиза. Эти роли сосредоточены на выполнении конкретных работ, а не на координации процесса в целом. Все они работают под управлением менеджера процесса и обеспечивают техническую реализацию отдельных этапов жизненного цикла релиза.