Зачем измерять поддержку изменений?
Практика «Поддержка изменений» (Change Enablement) призвана повышать количество успешных изменений в ИТ-услугах за счет оценки рисков, надлежащего согласования и управления расписанием изменений.
Измерения позволяют понять, насколько эффективно работает практика и где требуются улучшения. Например, большое количество согласованных изменений еще не говорит о том, что все они были успешны: часть из них может приводить к сбоям, переносам сроков или дополнительным затратам.
Система метрик помогает ответить на более важные вопросы, чем просто количество выполненных изменений: насколько быстро организация реализует необходимые изменения, как часто они вызывают негативные последствия, насколько обоснованны решения о согласовании и удается ли поддерживать приемлемый уровень риска.
Кому полезны результаты измерений практики?
Бизнесу — чтобы понимать, насколько предсказуемо реализуются изменения и как они влияют на доступность услуг и достижение бизнес-целей.
Руководителю ИТ — чтобы оценивать баланс между скоростью развития ИТ и стабильностью услуг, обосновывать инвестиции и определять приоритеты улучшений.
Владельцу практики — чтобы выявлять узкие места, совершенствовать правила оценки и согласования изменений, повышать качество планирования.
Командам разработки и эксплуатации — чтобы сокращать ожидание согласований, улучшать подготовку изменений и уменьшать количество неудачных внедрений.
Заинтересованным сторонам и владельцам услуг — чтобы оценивать влияние изменений на пользователей и качество услуг.
Почему измерять непросто?
У практики есть несколько типичных ловушек.
Во-первых, трудно определить, что считать успешным изменением. Формально завершенное изменение может вызвать инциденты, ухудшить производительность или потребовать срочного исправления. Поэтому критерии успеха должны учитывать не только факт внедрения, но и последствия для услуги. А это требует того, чтобы те, кто управляет инцидентами и проблемами, умели связывать инциденты и проблемы с проведенными изменениями. Кроме того, негативное влияние может сказать не сразу по завершению изменения, а через какое-то время, когда это изменение уже будет учтено в статистике как успешное.
Во-вторых, результаты зависят не только от самой практики. На них влияют качество разработки, тестирования, управления конфигурациями, релизами и развертыванием. Например, рост числа неудачных изменений не всегда означает, что проблема именно в согласовании и координации изменения.
В-третьих, средние значения могут вводить в заблуждение. Стандартные, нормальные и экстренные изменения имеют разные профили риска и требования к обработке. Их нужно анализировать раздельно.
Наконец, легко превратить метрики в стимул для нежелательного поведения. Если оценивать сотрудников по скорости согласования, они могут начать формально одобрять изменения. Если по доле успешных внедрений — команды могут избегать сложных, но необходимых изменений.
С чего начать измерения изменений
Систему измерения следует строить от целей бизнеса, а не от данных, которые уже доступны в ITSM-системе.
Например, бизнес-цель — быстрее выводить новые продукты и функции на рынок. Она может быть связана с целью ИТ — сократить время реализации изменений без неприемлемого роста рисков. На уровне практики это превращается в конкретные вопросы: где возникают задержки, насколько качественно оцениваются риски, как часто внедрения приводят к сбоям?
Далее, для каждого фактора успеха практики определяют метрики, источники данных и целевые значения. При этом важно учитывать исходный уровень: сначала измерить текущее состояние, затем определить реалистичные цели и периодичность контроля.
Метрики практики «Поддержка изменений»
Для практики «Поддержка изменений» выделяют четыре фактора успеха. При этом важно оценивать не только скорость обработки изменений, но и последствия внедрений, опыт заинтересованных сторон и соблюдение обязательных требований.
1. Обеспечение своевременной и эффективной реализации изменений
Этот фактор показывает, насколько предсказуемо организация реализует изменения и насколько эффективно организован весь путь от запроса до внедрения.
| Метрика | Что показывает и как рассчитать | Кому интересна |
| Доля изменений, реализованных в запланированный срок | Количество изменений, внедрённых в согласованный срок / общее количество завершённых изменений × 100% | Руководителю ИТ, владельцу практики, владельцам услуг |
| Медианное время реализации изменения | Медианное время от регистрации запроса до завершения внедрения. При необходимости отдельно измеряется время ожидания согласования | Бизнесу, руководителю ИТ, командам разработки и эксплуатации |
| Доля изменений, выполненных с первого раза | Количество изменений без повторного внедрения, отката или внепланового исправления / общее количество внедрённых изменений × 100% | Владельцу практики, техническим командам, руководителям ИТ |
| Доля изменений, отложенных или отменённых из-за недостаточной готовности | Количество переносов и отмен по причинам недостаточной подготовки / общее количество запланированных изменений × 100% | Владельцам услуг, руководителям команд, владельцу практики |
Эти метрики помогают обнаруживать задержки, оценивать качество планирования и определять, какие этапы процесса мешают своевременному внедрению. При анализе важно разделять задержки из-за согласований, недостаточной технической готовности и изменения бизнес-приоритетов. В организации может не быть нормативов по срокам реализации изменений целиком, но могут быть нормативы на длительность отдельных этапов (оценка, авторизация, планирование, тестирование). В таком случае оценивается своевременность выполнения этих этапов.
2. Минимизация негативного влияния изменений
Даже своевременно внедрённое изменение нельзя считать успешным, если оно вызывает серьёзные инциденты или ухудшает качество ИТ-услуги. Этот фактор отражает способность организации предотвращать нежелательные последствия и ограничивать их влияние.
| Метрика | Что показывает и как рассчитывать | Кому интересна |
| Доля изменений, приведших к связанным инцидентам | Количество внедрённых изменений, после которых зарегистрированы связанные инциденты / общее количество внедрённых изменений × 100% | Владельцу практики, владельцам услуг, руководителям ИТ |
| Количество значительных инцидентов, связанных с изменениями |
Количество значительных инцидентов, для которых установлена связь с изменениями Или Суммарная длительность значительных инцидентов, для которых установлена связь с изменениями |
Бизнесу, руководству ИТ, ответственным за непрерывность услуг |
| Доля изменений, потребовавших отката | Количество изменений, для которых выполнен откат / общее количество внедрённых изменений × 100% | Техническим командам, владельцу практики, руководителям эксплуатации |
| Время восстановления после неудачного изменения | Время от возникновения вызванного изменением нарушения до восстановления нормальной работы услуги | Владельцам услуг, сервис-деску, руководителям эксплуатации |
| Доля изменений с выполненной оценкой риска | Количество изменений, для которых была выполнена оценка риска / количество изменений, для которых оценка риска является обязательной × 100% | Владельцу практики, ответственным за риски и информационную безопасность |
Эти метрики помогают оценивать не только частоту неудач, но и тяжесть их последствий. Например, одинаковая доля изменений с инцидентами может скрывать принципиально разный уровень риска, если в одном случае возникают кратковременные сбои, а в другом — длительная недоступность критичной услуги. Но следует учитывать, что для измерения первых двух метрик необходима способность практики управления инцидентами связывать инциденты и измерения, а это требует определенной зрелости обоих практик.
3. Обеспечение удовлетворённости заинтересованных сторон изменениями и практикой поддержки
Практика должна не только обеспечивать контроль, но и помогать заинтересованным сторонам получать нужные изменения без неоправданных задержек и чрезмерных организационных усилий.
| Метрика | Что показывает и как рассчитывать | Кому интересна |
| Удовлетворённость результатами изменений | Средняя оценка пользователей, владельцев услуг инициаторов изменений после внедрения по согласованной шкале | Бизнесу, владельцам услуг, руководителям ИТ |
| Удовлетворённость процессом поддержки изменений | Средняя оценка технических специалистов, инициаторов изменений, руководителей команд по согласованной шкале | Владельцу практики, инициаторам изменений, руководителям команд |
| Доля изменений с негативной обратной связью | Количество изменений, по которым поступили обоснованные жалобы на результат или процесс / общее количество изменений, по которым собиралась обратная связь × 100% | Владельцу практики, владельцам услуг, бизнес-заказчикам |
Эти метрики позволяют понять, не стала ли практика чрезмерно бюрократичной и приносит ли реальную пользу. Например, сокращение времени согласования может быть позитивным изменением, но только если оно не сопровождается ростом рисков и ухудшением качества услуг.
Удовлетворённость рекомендуется измерять отдельно для разных групп: инициаторов изменений, технических команд, владельцев услуг и представителей бизнеса. Их ожидания могут существенно различаться.
4. Соответствие изменений требованиям со стороны руководства и регуляторов
Этот фактор показывает, насколько последовательно организация соблюдает установленные правила, внутренние политики, требования к контролю и внешние обязательства.
| Метрика | Что показывает и как рассчитывать | Кому интересна |
| Доля изменений, соответствующих обязательным процедурам | Количество проверенных изменений, соответствующих применимым требованиям / общее количество проверенных изменений × 100% | Руководству ИТ, внутреннему аудиту, владельцу практики |
| Доля изменений с полным комплектом подтверждающих записей | Количество изменений, по которым сохранены необходимые оценки, решения, результаты тестирования и сведения о внедрении / общее количество проверенных изменений × 100% | Внутреннему аудиту, специалистам по соответствию требованиям, владельцу практики |
| Количество выявленных нарушений и замечаний аудита | Число нарушений, связанных с управлением изменениями, за отчётный период; при необходимости с разбивкой по критичности | Руководству ИТ, внутреннему аудиту, ответственным за риски |
| Доля экстренных изменений, прошедших обязательный последующий анализ | Количество экстренных изменений с выполненным последующим анализом в установленный срок / общее количество экстренных изменений, подлежащих такому анализу × 100% | Владельцу практики, руководству ИТ, внутреннему аудиту |
Эти метрики помогают подтвердить управляемость изменений, готовность организации к аудиту и соблюдение обязательных требований. При этом формальное наличие согласования не всегда свидетельствует о качестве решения, поэтому результаты проверок желательно дополнять анализом существенных нарушений и их причин.
Как использовать метрики в единой системе измерения
То, насколько практика соответствует своему назначению определяется выполнением всех её факторов успеха, поэтому оценивать их изолированно не следует. Например, ускорение реализации изменений, увеличение доли экстренных измений может сопровождаться увеличением числа инцидентов, а ужесточение контроля — снижением удовлетворённости инициаторов.
Для начала достаточно выбрать по две-три метрики на каждый фактор, определить их формулы, источники данных, периодичность и ответственных. Затем измерить исходные значения и согласовать целевые показатели с заинтересованными сторонами.
При выборе метрик полезно придерживаться нескольких правил:
Не подменять результат активностью. Количество согласований и обработанных запросов характеризует объём работы, но не доказывает успешность практики.
Разделять типы изменений. Стандартные, нормальные и экстренные изменения следует анализировать с учётом их разных целей и профилей риска.
Сопоставлять скорость, качество и риски. Ни одна из этих характеристик не должна оптимизироваться за счёт остальных.
Измерять то, на что можно влиять. Если задержки обусловлены внешними зависимостями, это необходимо учитывать при интерпретации результатов.
Связывать метрики с управленческими решениями. Каждый показатель должен помогать определить, что именно следует улучшить и как проверить эффект.
Итоговая задача системы измерения — дать понимание того, обеспечивает ли практика своевременную реализацию изменений, ограничивает ли негативные последствия, удовлетворяет ли заинтересованные стороны и помогает ли организации выполнять обязательные требования. И если отклонения есть, то своевременно их вывлять и корректировать процессы.
