В управлении внеплановыми простоем при срочном внедрении изменений задействованы три основных процесса ITIL: управление изменениями (Change Management), который отвечает за процесс внедрения изменений и формирование документа PSO; управление уровнем услуг (Service Level Management, SLM), который занимается обсуждением и согласованием с заказчиком целевых показателей доступности на период внедрения изменений; и управление доступностью (Availability Management), который проверяет соответствие плановой доступности целевым значениям и оценивает влияние изменений на доступность сервисов в долгосрочной перспективе.

Укрупнённые схемы ИТ-систем, показывающие только общие компоненты (например, «ERP-система»), недостаточны для расчёта себестоимости услуг, потому что не учитывают различия в потреблении ресурсов различными группами пользователей. Например, одни пользователи могут постоянно работать в системе, другие использовать её редко для отчётов, третьи — обрабатывать большие объёмы данных. Себестоимость услуг зависит от профиля использования, который определяется бизнес-процессами. Для точного расчёта необходима детализация до уровня подсистем, отражающая, как именно разные пользователи потребляют ресурсы.

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

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

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

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

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

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

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

Принцип "Используйте целостный подход" (Think and work holistically) в ITIL 4 предполагает, что при управлении услугами необходимо учитывать все взаимосвязанные элементы системы, а не изолированные компоненты. В отличие от формулировки в ITIL Practitioner Guidance ("Work holistically"), формулировка в ITIL 4 включает слово "think" (думать), что подчеркивает важность целостного мышления на этапе планирования, а не только действия в рамках целостного подхода. Принцип побуждает организации рассматривать все аспекты управления услугами как взаимосвязанную систему, учитывая, как изменения в одной области могут повлиять на другие области, и стремиться к оптимизации всей системы в целом, а не отдельных ее частей.