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

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

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

В ITIL 4 вместо критических факторов успеха процессов (CSF), использовавшихся в ITILv3, появились факторы успеха практик (PSF). Основные изменения заключаются в том, что теперь факторы успеха определяются не для отдельных процессов, а для практик в целом. PSF представляют собой комплексные функциональные компоненты практики, необходимые для обеспечения её соответствия своему назначению, и охватывают все аспекты управления услугами: Организации и люди, Информация и технологии, Потоки ценности и процессы, Поставщики и партнёры. Формулирование KPI по-прежнему основывается на этих факторах, но теперь в контексте практик и их вклада в потоки создания ценности.

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

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

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

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

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

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