Для организации взаимодействия между внутренними ИТ-подразделениями без использования OLA рекомендуется сосредоточиться на построении четких SLA и UC (Underpinning Contracts). Это позволит регулировать внутренние процессы с теми же принципами, что и внешние отношения с заказчиками. Важно определить ответственные области, уровни обязательств и механизмы контроля, но без введения дополнительного слоя терминов и документов (таких как OLA). Такой подход снижает риски излишней бюрократизации и избежит путаницы. Также необходимо пересмотреть организационную структуру для обеспечения эффективной коммуникации и контролю за выполнением обязательств, возможно, через создание централизованного арбитра, но без усложнения терминологии.

Особо важными soft skills для успешного агента изменений являются широта ума, открытость, чёткость мысли и готовность к диалогу. Специалист должен быть гибким для встраивания в организацию, достаточно умным, чтобы понять сложные процессы во всех их аспектах, и достаточно мотивированным для проведения изменений. Знание методологий (таких как agile) и опыт работы важны, но могут не компенсировать отсутствие необходимых социальных навыков, таких как чуткость к команде и внимательность к реальным проблемам организации.

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

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

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

Первая стратегия предполагает концентрацию трех классов инструментов влияния: 1) Информация (данные, технические знания, экспертиза, политическая ситуация); 2) Ресурсы (финансовые, материальные, человеческие, временные); 3) Поддержка (подтверждение, одобрение, легитимность). Используя эти инструменты, коалиция планомерно доносит до ключевых сотрудников необходимость изменений, стремясь вызвать у них проактивность в их продвижении. Высший результат — когда сотрудники сами предлагают изменения, воспринимая их как свои собственные.

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

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

В ITIL4 произошел переход к более гибкой модели классификации услуг через призму парадигмы ресурсы-продукты-услуги. Вместо жесткого разделения на бизнес-услуги и поддерживающие услуги (как в ITIL V3), ITIL4 рассматривает видимость ресурсов для потребителя. Услуги могут иметь разную степень видимости в зависимости от контекста их использования. ITIL4 уделяет меньше внимания терминам 'бизнес-услуга' и 'информационная технологическая услуга', упоминая их лишь раз в описании практики Service Design в контексте SIAM (Service Integration and Management).

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