Принцип "Действуйте итерационно" (Progress iteratively), описанный в ITIL Practitioner Guidance 2016 года, был дополнен в ITIL 4 2019 года до формулировки "Действуйте итерационно, используя обратную связь" (Progress iteratively with feedback). Это изменение подчеркивает важность не просто итерационного подхода к работе, но и обязательного сбора и учета обратной связи на каждой итерации. Авторы ITIL 4 таким образом делают акцент на том, что обратная связь является ключевым элементом успешных итераций, позволяющим корректировать дальнейшие шаги и улучшать результаты.

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

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

Наиболее частые ошибки при внедрении систем управления конфигурациями включают: чрезмерный фокус на самом процессе и инструменте, а не на создании ценности для конечных пользователей; попытки собрать слишком много информации без чёткого понимания, кто и как будет её использовать; недостаточное внимание к поддержанию актуальности данных; отсутствие коммуникации и обучения для пользователей о том, как и зачем использовать систему; игнорирование обратной связи от пользователей. Эти ошибки приводят к тому, что CMDB превращается в «базу только для записи», которую никто не использует, и инвестиции в систему не окупаются.

Для обеспечения долгосрочной стабильности показателей своевременности обслуживания ИТ-процессов необходимо: 1. Регулярно измерять 'температуру' процессов с большей частотой и адресностью 2. Реализовывать стратегию Shift left - раннее обнаружение и решение проблем на начальных этапах жизненного цикла 3. Систематически собирать и анализировать данные для принятия решений, опираясь на объективные измерения 4. Обучать сотрудников и развивать их экспертизу для повышения общей эффективности процесса 5. Проводить регулярные аудиты и рефакторинг процессов с удалением лишних этапов и упрощением структуры 6. Инвестировать в автоматизацию рутинных операций и вспомогательные инструменты 7. Поддерживать запас ресурсов для оперативного реагирования на неожиданные изменения спроса 8. Формировать культуру непрерывного улучшения, где анализ проблем и внедрение решений является повседневной практикой 9. Обеспечивать прозрачность показателей и проблем как для исполнителей, так и для руководства 10. Делать упор на общий результат, а не на отдельные локальные оптимизации Это позволит создать устойчивую систему, способную как к оперативному реагированию на проблемы, так и к предотвращению их возникновения.

Этапы управления рисками в процессах обеспечения качества ИТ-услуг включают: 1) выявление потенциальных угроз, связанных с обслуживанием услуг; 2) классификацию угроз по типам и степеням воздействия; 3) отбор наиболее значимых угроз, основанный на комбинации вероятности наступления и возможного ущерба; 4) разработка и внедрение контрмер для предотвращения или минимизации воздействия угроз; 5) мониторинг реализации угроз и эффективности контрмер, а также анализ инцидентов при возникновении проблем. Такой подход позволяет создавать устойчивые ИТ-услуги, готовые к критическим ситуациям.

На объединенном радаре линия результативности показывает текущую пользу, которую процессы приносят организации, измеряемую по шкале от 0 до 100%. Эта линия отражает фактическую эффективность выполнения процессов в свете бизнес-целей. Линия зрелости, в свою очередь, характеризует уверенность в том, что организация сможет продолжать получать эту пользу даже при изменяющихся условиях. Это показывает, насколько надежно процессы построены и документированы, и насколько легко их можно масштабировать или адаптировать. Другими словами, результативность — это «функциональность», а зрелость — это «гарантия», аналогично известной концепции ITIL.

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

ISO 31010 представляет собой полное собрание методов идентификации, анализа и оценки рисков. Стандарт охватывает широкий спектр подходов – от организации работы экспертных групп до количественной оценки вероятности негативных событий. Среди описанных методов присутствуют FTA (анализ дерева отказов), ETA (анализ дерева событий), BIA (анализ бизнес-воздействия), метод Дельфи, SWIFT (Структурированный Что-Если Анализ Технологии) и диаграмма Ишикавы. Все эти методы собраны в едином документе, что делает стандарт ценным практическим руководством.

Роли менеджера изменений в ITIL часто вызывают неоднозначность, потому что в ITIL V3 эта роль не была описана как отдельная, а вместо нее упоминались другие роли, такие как владелец процесса и практик. В зависимости от контекста и организации роль 'менеджера изменений' могла включать в себя различные функции, иногда совмещая обязанности менеджера процесса, администратора изменений и председателя CAB. Даже в ITIL4, где роль менеджера изменений стала официальной, остается гибкость в распределении обязанностей: менеджер изменений может выступать как универсальный ролевой игрок, объединяющий несколько функций, или его обязанности могут быть распределены между менеджером изменений и координаторами, в зависимости от масштаба организации и сложности изменений.