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

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

Деловая игра 'Проект Феникс' демонстрирует, что кратное ускорение действительно возможно без смены персонала. На начальном этапе участники, работая как в обычных компаниях, показывают низкую эффективность: Time to Market составляет около 25 минут на задачу, а процент завершённых задач - 25-50%. К концу дня, после осознанного подхода к организации работы - правильной приоритизации задач, управлению потоком и внедрения ограничений на текущую работу - Time to Market снижается до 40 секунд - 1,5 минуты, а процент завершённых задач возрастает до 85-100%. Это подтверждает, что системные изменения в организации процессов, даже без изменения архитектуры и технологий (в рамках игры такие изменения невозможны), могут привести к ускорению в 15-25 раз.

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

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

Для выбора подходящего владельца критичного для бизнеса процесса необходимо сначала определить степень критичности каждой обязанности владельца, используя десятибалльную шкалу, где 10 означает, что отсутствие выполнения этой обязанности может привести к серьезным проблемам. Затем следует искать человека, обладающего достаточными полномочиями и возможностями для выполнения наиболее критичных обязанностей. Для высококритичных процессов владельец должен иметь широкий охват контроля (scope of control), охватывающий все подразделения, участвующие в процессе. Если невозможно назначить высокопоставленного руководителя, необходимо создать надежные механизмы поддержки и эскалации, чтобы владелец мог оперативно получать необходимую поддержку от руководства. Также важно учитывать, что владелец должен иметь достаточно времени для выполнения обязанностей по управлению процессом, не будучи перегруженным другими обязанностями.

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

На основе анализа дерева отказов можно точно определить, какая конфигурационная единица (КЕ) влияет на какую функциональность услуги. Поскольку дерево наглядно показывает, какие КЕ и в какой комбинации приводят к отказу конкретной функции, становится возможным оценить критичность времени восстановления каждой КЕ. Например, если отказ определенной КЕ ведет к полной недоступности критически важной функции через оператор «ИЛИ», это означает, что для этой КЕ требуется минимальное RTO. Если же КЕ влияет на функцию только в комбинации с другими отказами через оператор «И», то RTO для такой КЕ может быть более мягким. Таким образом, FTA позволяет связать архитектурную модель с показателями непрерывности, а не устанавливать RTO/RPO на основе общих рекомендаций или произвольных решений.

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

Если после пятого уровня анализа корневая причина остаётся не выявленной, следует продолжить задавать вопрос «почему», пока не будет достигнута точка, влияние на которую возможно. Метод 5-Why's использует пять шагов как ориентир, а не жёсткое правило. Важно сохранять логическую стройность цепочки, при необходимости привлекать экспертов и проверять гипотезы. Критическая точка — достижение фактора, находящегося в зоне ответственности организации, где могут быть внедрены корректирующие действия.