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

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

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

К вопросам, задаваемым пользователю для оценки влияния инцидента, предъявляются следующие основные требования: 1) Пользователь должен быть в состоянии дать на них ответ, используя имеющуюся у него информацию. 2) Трактовка ответов должна быть максимально однозначной, чтобы разные сотрудники поддержки приходили к одинаковой оценке влияния. 3) Количество вопросов должно быть ограничено (обычно 2-4), чтобы процесс оценки оставался быстрым и не создавал нагрузку на пользователя. 4) Вопросы должны покрывать ключевые аспекты, определяющие уровень влияния (масштаб проблемы и степень недоступности). 5) Формулировки вопросов должны быть понятны неподготовленному пользователю без технических знаний.

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

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

Метрики, которые помогают оценить предсказуемость выполнения задач в DevOps, в основном связаны с регулярностью и стабильностью работы команды. Ключевая метрика предсказуемости - это последовательность выполнения взятых на себя задач за определенные отрезки времени. Если команда регулярно выполняет запланированный объем работы в установленные сроки, это говорит о высокой предсказуемости. Дополнительно могут анализироваться показатели отклонения от плана, частота срывов сроков, стабильность velocity (скорости выполнения задач) и улучшение точности оценок. Предсказуемость является важным компонентом качества работы DevOps-команды, так как позволяет более точно планировать релизы и управлять ожиданиями заинтересованных сторон, что в конечном итоге способствует уменьшению времени выпуска продукта (lead time).

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

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

Основная цель процесса «Управление проблемами» (Problem Management) в рамках ITIL заключается в минимизации негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре, и предотвращении повторного возникновения таких инцидентов. Процесс направлен как на реагирование на уже произошедшие инциденты с устранением их корневых причин, так и на проактивное выявление потенциальных проблем, способных вызвать инциденты в будущем, чтобы предотвратить их возникновение.