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

Процессы EDM01 и EDM05 вызывают вопросы, так как следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (EDM02–EDM04), в то время как согласно принципу COBIT 5, эти процессы должны описывать управление системой руководства. Если EDM01 и EDM05 — процессы управления, то их структура должна быть больше похожа на управленческий цикл PDCA. Если же они относятся к руководству, тогда возникает вопрос: кем и на каком уровне осуществляется руководство над самой системой руководства, что представляется избыточным и противоречащим логике разделения функций руководства и управления.

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

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

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

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

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

Если консультанты при составлении RACI-матрицы не предусмотрели механизмы контроля для ответственных (A), необходимо: 1. До окончательного утверждения матрицы определить, какие конкретно инструменты контроля нужны для каждой позиции с символом A. 2. Требовать от консультантов или внутренней команды разработать и внедрить эти механизмы контроля. 3. В случае если консультанты отказываются это делать, настаивать на внесении в матрицу примечаний о необходимых механизмах контроля с указанием ответственных за их создание. 4. При отсутствии возможности привлечь консультантов - самостоятельно разработать простые, но эффективные механизмы отслеживания выполнения задач (регулярные отчеты, контрольные точки, проверочные встречи). Механизмы контроля являются неотъемлемой частью ответственности, и без них система распределения ролей теряет смысл, так как ответственный не сможет влиять на результат, за который несет ответственность.

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

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