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

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

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

Подход с разделением ALM для разработки и ITSM для эксплуатации соответствует уровню зрелости «Controlled» в модели KPMG maturity phases model of the IT organisation. На этом этапе операционные процессы, такие как управление инцидентами, изменениями и релизами, контролируются и стандартизированы, но отсутствует сквозная ответственность за ИТ-услуги как целостные элементы, влияющие на бизнес-процессы. Такой уровень зрелости может быть достаточным для организаций, где нет высокой потребности в изменении ИТ-инфраструктуры ради поддержки бизнеса.

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

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

Роль Service Owner изначально является частью обязанностей CIO, так как руководитель ИТ-организации несет окончательную ответственность за все ИТ-услуги. По мере роста организации и увеличения количества услуг CIO может делегировать ответственность за отдельные услуги конкретным Service Owner'ам. Таким образом, Service Owner может рассматриваться как расширенная роль, делегированная CIO для управления конкретной услугой.

"Процедура" в структуре PCF - это отдельные активности в исполняемом процессе, представляющие собой следующий уровень детализации после процесса. Процедуры обозначаются четырьмя цифрами, разделенными точками (5.2.3.4, 8.3.4.2). Примеры процедур, приведенные в тексте: Предоставление ответа на жалобу клиента (в рамках процесса Управление жалобами клиентов), Подготовка консолидированной финансовой отчетности (в рамках процесса Ведение финансовой отчетности). Процедуры представляют собой конкретные, выполняемые действия в рамках более общих процессов.

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

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