Управление конфигурациями и изменениями

Цель построения всякой системы управления — достижение состояния, при котором все имеющиеся объекты управления будут находиться под контролем и готовы адекватно реагировать на управляющие воздействия. Методология ITSM (IT Service Management) рассматривает пути достижения такого состояния. В [1] описана модель, в соответствии с которой все управленческие процессы размещаются вокруг единого стержня — процессов управления конфигурациями и изменениями. Какой смысл в таком размещении?

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

• разработка правил учета элементов ИТ-инфраструктуры;
• осуществление учета в соответствии с разработанными правилами;
• разработка правил получения/предоставления информации и проверки точности;
• осуществление повседневной деятельности в соответствии с разработанными правилами.

Правила учета элементов инфраструктуры

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

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

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

После того, как элементы инфраструктуры промаркированы, встает вопрос об организации базы данных, содержащей информацию о них. Она именуется «База данных конфигурационных единиц» (Configuration Management Data Base — CMDB) [2].

Роль CMDB в управлении конфигурациями

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

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

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

Существует множество различных подходов к построению CMDB: использование существующей в организации бухгалтерской системы; создание собственной базы данных; использование специализированного средства автоматизации.

Создание собственной системы — наиболее гибкий и полный вариант. Основными его недостатками является высокая ресурсоемкость и необходимость дальнейшего сопровождения.

В виду некоторой схожести рассматриваемых задач с теми, которые традиционно стоят перед бухгалтерией, процесс учета и управления элементами инфраструктуры часто именуют Asset Management («управление активами»). Верно это лишь частично, поскольку кроме стоимости, работоспособности, местоположения и иных характеристик для описания конфигурационных единиц исключительно важно наличие информации об их взаимосвязях и уровнях взаимодействия. Большинство разнообразных ИТ-служб строится с использованием целого ряда различных элементов, которые одновременно могут задействоваться в ходе реализации других служб. Правильная оценка текущего состояния систем без учета их взаимосвязей сложна, а иногда и просто невозможна. Поэтому в рамках ITIL рассматривается иной процесс, отличный от управления активами, — Configuration Management («управление конфигурациями»). Адаптация бухгалтерских систем для нужд управления конфигурациями часто оказывается малореальной в связи с отсутствием возможности удобного предоставления доступа к информации большому числу сотрудников ИТ-службы и невозможностью качественного отображения взаимосвязей между различными конфигурационными единицами.

Специализированные системы лишены этих недостатков, поскольку требуют лишь незначительной настройки и могут быть внедрены в сжатые сроки. С другой стороны, за это приходится платить некоторой потерей гибкости и снижением возможностей глубокой настройки. К наиболее известным системам относятся Remedy ARS (отдельно или с модулем Asset Management), HP Service Desk, Peregrine AssetCenter. Имеется и целый ряд менее распространенных решений. Системы различаются качеством реализации процессов, полнотой соответствия рекомендациям ITIL, качеством и полнотой отображения информации, удобством ее визуализации и, что немаловажно для систем этого класса в нашей стране, полнотой и качеством локализации. В то же время, всегда следует помнить о том, что окончательный выбор решения должен осуществляться на основании разработанных процессов, а не процессы должны строиться так, как того требует продукт.

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

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

Существенную помощь при организации такого рода проверок могут оказать специфичные средства автоматизированного управления различным оборудованием и приложениями. К примеру, при совместном использовании с HP Service Desk и Microsoft SMS можно автоматически проконтролировать комплектность рабочих станций и серверов на платформе Windows NT и тем самым проверить соответствие имеющихся в CMDB данных реальному состоянию.

О необходимости работать по правилам

Все формальные процедуры, изложенные на бумаге, бесполезны, если их не исполнять.

ИТ-инфраструктуры не являются чем-то жестко зафиксированным: они развиваются и совершенствуются. Изменения бывают связаны с необходимостью замены вышедшего из строя оборудования, с переходом на новые версии программного обеспечения, с новыми потребностями бизнеса и др. Будет ли зафиксированное в CMDB состояние соответствовать реальному положению дел в случае, если в систему было внесено изменение? Конечно, нет — если не производилась актуализация базы. Но можно ли организовать внесение изменений в системы таким образом, чтобы гарантировать отсутствие снижения качества обслуживания? Да, это возможно — как с методической точки зрения, так и с точки зрения наличия соответствующего инструментария. В рамках методологии ITSM за это отвечает процесс управления изменениями (Change Management), в самом общем виде несущий ответственность за соблюдение процедур внесения изменений в оборудование, системное ПО, прикладные системы, документацию, различные процедуры обслуживания, ИТ-службы.

Причины внесения изменения могут быть самыми разными: запросы пользователей, реакция на выявленную проблему, реакция на возникший инцидент, требования бизнеса. В соответствии с ITIL [3] предлагается следующая схема организации внесения изменения. Прежде всего осуществляется регистрация запроса на внесение изменения (Request for Change — RFC). Инициатором запроса, в принципе, может быть любой сотрудник компании; более точно это определяется соответствующими регламентами. Регистрация запроса может осуществляться как самостоятельно, так и при помощи оператора службы Service Desk [4]. Зарегистрированный запрос попадает под контроль управления изменениями.

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

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

Поскольку проведение всех перечисленных действий требует знаний и квалификации в различных сферах, а также в связи с высокой ответственностью, в рамках процесса управления изменениями создается комитет согласования и подтверждения изменений (Change Advisory Board — CAB). Комитет объединяет специалистов и представителей различных подразделений организации, с обязательным участием компетентных представителей финансовой службы компании и представителя руководства компании, имеющего право окончательного принятия решения. Все это должно обеспечить всестороннюю оценку запрашиваемого изменения и необходимых для его реализации ресурсов, одновременно гарантируя обязательность принятого решения для исполнителей.

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

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

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

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

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

Пример управления изменениями

Рассмотрим небольшой пример.

1. Пользователь А пришел к выводу, что ему необходимо прейти на новую прикладную программу. Он обращается с запросом в службу Service Desk, высказывает свои пожелания.
2. Оператор Service Desk регистрирует обращение пользователя как запрос на внесение изменения и назначает ответственного менеджера управления конфигурациями.
3. Менеджер рассматривает запрос и приходит к выводу, что он не относится к срочным и не лежит в сфере его личной компетенции. Поэтому он инициирует стандартную процедуру рассмотрения запроса и с этой целью определяет (по информации о пользователе и по содержанию запроса) перечень компетентных специалистов, список потенциально затрагиваемых служб и конфигурационных единиц.
4. Менеджер управления конфигурациями информирует выделенных специалистов, а также ключевых членов комитета подтверждения изменений, о поступившем запросе и дате заседания комитета CAB, на котором будет рассматриваться данный запрос. Дополнительно всем предоставляется вся доступная информация по затрагиваемым службам и конфигурационным единицам (она должна быть подготовлена управлением конфигурациями по запросу менеджера управления изменениями или специалистов по направлениям).
5. Задействованные сотрудники комитета производят оценку влияния изменения:
   • представители бизнес-подразделений — изменений с точки зрения необходимости для решения бизнес-задач;
   • финансисты — с точки зрения стоимости и рентабельности;
   • ответственные за сопровождение приложений — с точки зрения работоспособности других приложений;
   • ответственные за сопровождение рабочих станций — с точки зрения возможности установки приложения на рабочую станцию;
   • специалисты, обслуживающие сети передачи данных — с точки зрения достаточности производительности сетей;
   • специалисты других направлений — со своих точек зрения;
   и подготавливают необходимые выводы к заседанию комитета.
6. На заседании предлагаемое изменение обсуждается и принимается итоговое решение. При этом в приложении к итоговому решению указываются специфичные требования и дополнительные условия, при которых должно осуществляться изменение: обновление версии операционной системы, частичное изменение параметров рабочей станции (увеличение емкости оперативной памяти) и т.д.
7. Менеджер управления изменениями в соответствии с принятым решением и стандартными процедурами определяет список исполнителей изменения и сроки их проведения: надо закупить новый продукт; ответственный за рабочие станции должен доукомплектовать компьютер пользователя А и обновить ОС; ответственный за приложения должен установить и проверить работоспособность нового продукта на компьютере пользователя.
8. Через некоторое время завершения изменения менеджер должен собрать информацию от исполнителей и от пользователей об итогах, проанализировать ее и принять решение об успешности изменения.
9. Изменение осуществлено успешно, пользователь получил новые возможности для более эффективного выполнения своих обязанностей. Менеджер управления изменениями информирует управление конфигурациями о внесенных изменениях, сообщает список затронутых конфигурационных единиц и их новое состояние.
10. Менеджер учитывает новые данные.
11. Менеджер закрывает запрос на внесение изменения, отмечая в регистрационной записи все выполненные действия и итоговый вывод об успешности изменения.

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

Опасности и положительный эффект

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

• общий обзор требований к процессам, предназначение и сфера их ответственности;
• описание организационной структуры управления конфигурациями и изменениями, ролевые обязанности сотрудников;
• методы и процедуры идентификации конфигураций и отдельных конфигурационных единиц;
• методы и процедуры изменения конфигураций;
• методы и процедуры аудита конфигураций;
• описание выбранных средств автоматизации и детальное изложение всех процедур с учетом использования данных средств;
• методы и процедуры обучения персонала;
• порядок ввода плана в действие.

Документ утверждается высшим руководством компании.

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

• Внедрение осуществляется без необходимого планирования и дизайна. В результате получается совсем не то, что ожидалось.
• Не совсем корректно определены уровни и степень декомпозиции конфигурационных единиц, в результате чего персонал вовлекается в лишнюю кропотливую работу по учету ненужных деталей.
• Процесс кажется излишне бюрократизованным и скрупулезным. Поэтому отдельные группы и отдельные личности стараются его избежать.
• Процесс легко обойти. Некоторые сотрудники делают это из желания ускорить отдельные мероприятия. Причина этого часто кроется в непонимании пользы от управления конфигурациями.
• Процесс подвержен ошибкам, поэтому рекомендуется прибегать к возможным автоматизированным решениям. Так, осуществление инвентаризации в условиях крупной компании вручную однозначно приведет к неточностям, исключить которые можно, только воспользовавшись одним из специальных решений (Microsoft SMS, Intel LanDesk, Novell ZenWorks и т.п.). Всякий учет информации без поддержки единых классификаторов допускает различные варианты описания одного и того же элемента, что в последствии может привести к неоднозначному толкованию, повторному счету и иным проблемам.
• Избранное средство автоматизации непригодно для дальнейшего развития. Многие компании на начальном этапе стараются экономить на средствах автоматизации, выбирая слабое, немасштабируемое решение, а иногда — и просто неподходящее, наподобие Excel. С ростом организации, числа учитываемых конфигурационных единиц, полноты их учета и классификации возможностей такого средства не хватит, что существенно осложнит реализацию процесса и сведет на нет его положительные качества.
• Управление конфигурациями реализовано в отрыве от остальных процессов и поэтому менее эффективно, а в результате многие полезные возможности окажутся недоступны.
• Ожидания от внедрения процесса управления конфигурациями нереальны. При слабом общем управлении ни учет активов, ни управление конфигурациями не в состоянии оказать существенную пользу.

При управлении изменениями имеется целый ряд проблем.

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

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

Что практически получит бизнес от реализации данных процессов:

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

Заключение

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

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

Литература

[1] Н. Дубова. ITSM — новая идеология управления ИТ, «Открытые системы», 2000, № 10

[2] З. Алехин. ITIL — основа концепции управления ИТ-службами. «Открытые системы», 2001, № 3

[3] CCTA. Best Practice for Service Support. London: The Stationery Office, 2000

[4] З. Алехин. Service Desk — цели, возможности, реализации. «Открытые системы», 2001, №5-6

Пример схемы кодирования конфигурационных единиц

Каждой конфигурационной единице присваивается идентификационный номер следующего вида:

F-123-S-999-9999V01.02

где:

• F-123 — код организации-собственника единицы (вводится для возможности раздельного учета в одной системе конфигурационных единиц, относящихся к различным подразделениям и организациям);
• S — код типа конфигурационной единицы (S обозначает программное обеспечение; T — программное обеспечение, предлагаемое заказчикам; H — оборудование; D - документация);
• 999 — код группы (подтипа) конфигурационной единицы (вводится для более полной классификации; принимает последовательные значения, дополняется слева нулями до трех знаков);
• 9999 — последовательный номер конфигурационной единицы (уникальный идентификационный номер, присваиваемый каждой конфигурационной единице; номер содержит 4 знака, при необходимости дополняется нулями слева; номера для каждого типа конфигурационных единиц независимы);
• V — обозначение кода версии (ставится всегда);
• 01.02 — номер версии конфигурационной единицы или ее компонента (каждой конфигурационной единице присваивается номер версии, состоящий из двух частей: номера релиза и номера изменения в нем).

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

Частичное улучшение ситуации малоэффективно. Да, можно организовать формальный учет информации независимо по каждому направлению. Однако в таком случае вряд ли получится согласовать данные и правила для различных направлений. Еще важнее то, что очень трудно будет получать сквозные отчеты, учитывающие несколько подразделений организации. Между тем для бизнеса особый интерес представляют именно совокупные данные, не отдельные элементы инфраструктуры, а предоставляемые услуги, которые, конечно же, зависят от большого числа разнородных элементов. Время доступа к разрозненной информации будет немалым, что в свою очередь означает, что в аварийной ситуации воспользоваться ею не смогут ни операторы Service Desk, ни представители других подразделений.

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

Оценка качества реализации процессов и работы персонала

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

• количество случаев возникновения неавторизованных конфигураций;
• количество инцидентов и проблем, возникших по причине ошибочных изменений;
• количество не выполненных полностью запросов на изменения по причине некорректных данных в CMDB или плохого контроля версий;
• время, необходимое на согласование и осуществление изменений;
• число некорректно отслеженных лицензий;
• число обнаруженных в ходе проверки ошибок конфигураций;
• число используемых неавторизованных компонентов ИТ;
• изменение числа инцидентов, самостоятельно устраняемых службой Service Desk;
• изменение числа серьезных инцидентов и проблем;
• изменение среднего времени и стоимости диагностирования и разрешения инцидентов и проблем, которые не удалось устранить сразу;
• изменение числа серьезных нарушений соглашений об уровнях сервисов;
• число изменений в CMDB по причине обнаружения в ней ошибок.

Для оценки управления изменениями можно предложить следующие метрики:

• число осуществленных за данный период изменений (в целом и с разбивкой по категориям, службам, типам и т.д.);
• анализ причин изменений (запросы пользователей, развитие систем, потребности бизнеса, инциденты/проблемы/запросы на обслуживание и т.д.);
• число удачных изменений и изменений, после которых пришлось возвращаться к предыдущему состоянию, причины;
• число инцидентов, завершившихся изменениями;
• число запросов на внесение изменений и тенденции;
• число проанализированных осуществленных изменений и время, понадобившееся на проведение анализа;
• данные прошлых периодов (с целью сравнения);
• число отвергнутых запросов на внесение изменений;
• пропорциональное отношение числа неудачных изменений ко всем изменениям;
• невыполненные изменения (всего и с разбивкой по группам).

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