В рамках 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-организациях возникают риски: пренебрежение необходимостью координации между многочисленными подразделениями и подрядчиками, игнорирование особенностей гетерогенной инфраструктуры, недооценка сложности перехода от традиционных процессов к гибким методам. Это может привести к снижению стабильности систем, увеличению числа инцидентов и простоя, неоправданным затратам на реинжиниринг унаследованных систем, а также к конфликтам между командами с разными культурами и подходами к работе. Успешное внедрение требует адаптации практик под контекст крупной организации, а не слепого копирования подходов из стартапов.

Для организаций, где услуги постоянно меняются, особенно важны рекомендации ITIL по управлению изменениями. Этот процесс помогает структурировать, оценить и реализовать изменения в контролируемой среде, минимизируя риски и негативное воздействие на пользователей. Также полезен процесс постоянного совершенствования (CSI), который способствует регулярному анализу и улучшению услуг. Если изменения связаны с технологическими аспектами, будут полезны процессы управления выпусками, конфигурациями и релизами. В целом, ITIL предоставляет структурированный подход к управлению динамичной средой, что особенно ценно в условиях постоянного развития услуг и технологий.

Кратного ускорения поставки задач можно достичь за счет нескольких мер: сокращение количества задач в системе (уменьшение работы в прогрессе), фокусировка на завершении текущих задач вместо начала новых, автоматизация этапов, не добавляющих ценность (например, тестирование), минимизация лишней работы. Эти изменения позволяют снизить время ожидания для задач с 95% до 70% и повысить эффективность потока с 3-10% до 30%, что приводит к трехкратному (и более) увеличению скорости поставки без увеличения числа разработчиков или рабочего времени.