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

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

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

Примером применения метода 5-Why's в ITIL служит анализ поломки принтера: 1) Принтер не работает, потому что сгорел нагревательный элемент; 2) Нагревательный элемент сгорел из-за перепадов напряжения в сети; 3) Перепады напряжения возникают из-за нестабильной работы подстанции; 4) Подстанция работает нестабильно из-за устаревшего оборудования; 5) Устаревание оборудования связано с отсутствием модернизации. Практическим решением становится установка стабилизатора напряжения, так как модернизация подстанции выходит за рамки зоны влияния ИТ-службы.

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

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

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

Согласно ITIL 4 Foundation [2.4], предоставление услуг (service provision) включает четыре основных элемента: управление ресурсами поставщика, сконфигурированными для предоставления услуги (например, серверы, инфраструктура, технологии); предоставление пользователям доступа к этим ресурсам (как к мобильной сети или сетевому хранилищу); выполнение согласованных сервисных операций (например, работа Service Desk по поддержке пользователей); управление эффективностью услуг и постоянное совершенствование (реализация собственных инициатив и учёт обратной связи от пользователей).

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

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