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

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

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

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

Ключевые переменные, влияющие на баланс между Agile (гибкостью) и стабильностью в ИТ: Release rate (частота внедрений) и Release size (средний размер внедрения). Чем выше частота внедрений (Release rate), тем меньшими порциями можно внедрять изменения (меньше Release size), и наоборот. Частые внедрения помогают сокращать размер очереди изменений (Backlog Size), уменьшают риски (Change Risk) и способствуют накоплению опыта. Большой размер релиза приводит к повышенным рискам, поскольку сложнее планировать и контролировать изменения. Также важны Process Time (время работы над изменением), Queue Time (время ожидания в очереди), Change capability (способность ИТ-организации проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют эффективность и качество процесса внедрения изменений в систему.

ITIL предоставляет структурированный подход к управлению стоимостью сервисов через Financial Management for IT, который описывает методы расчета стоимости ресурсов и услуг с учетом как прямых, так и косвенных затрат. Это обеспечивает точное распределение затрат между потребителями услуг, позволяет анализировать стоимость-эффективность различных сервисов и формировать обоснованные цены или внутренние ставки для учета ресурсов, что ведет к более прозрачному и экономически рациональному управлению ИТ-услугами.

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

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

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

CLD предлагает способ агрегирования показателей для управления изменениями, позволяя сгруппировать метрики по ключевым областям управления. Например, для контроля своевременности реализации (Time to Market) можно использовать метрики Lead Time и Percentage of changes timely implemented. Для управления затратами (Cost per change) подходят Process Time и Standard Change Rate. Для оценки негативного влияния от изменений (Change Risk) можно использовать как прямые метрики (Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases), так и опережающие индикаторы (Release size, Emergency change rate). Такое структурирование помогает формировать комплексную картину эффективности процесса изменений.