6.4.5. Верификация и аудит

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

• после внедрения новой Конфигурационной Базы Данных;

• к примеру, спустя полгода с момента внедрения;

• перед серьезными изменениями и после них;

• после чрезвычайных обстоятельств;

• в любое другое удобное время.

При проведении аудита рассматриваются следующие вопросы:

• Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию?

• Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему? Ка­кое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздейст­вия запланированных изменений)?

• Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с согла­шением о присвоении имен?

• Правильно ли используются варианты?

• Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступны­ми к использованию?

• Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Скла­да эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных? Если нет, то почему?

Аудиторские проверки также можно проводить, выбирая объекты случайным образом или прово­дить там, где Руководитель Процесса Управления Конфигурациями считает, что информация может быть некорректной. Если существует связь с автоматическими инструментальными средствами ау­дита, тогда можно делать аудит соответствующих областей или формировать по ним дельта-отчеты практически ежедневно.

Если обнаруживаются расхождения, то инструментальные средства аудита педолжны автоматиче­ски обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изме­нения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.

6.5. Контроль процесса

1. Отчеты и Ключевые показатели эффективности

В отчет по процессу Управления Конфигурациями возможно включение следующей информации: « информация о качестве процесса;

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

• количество случаев, когда используется неавторпзованная Конфигурация;

• количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;

• отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;

• длительность обработки Запросов на Регистрацию информации;

• перечень Конфигурационных Единиц, в отношении которых количество зарегистрированых ин­цидентов или изменений превышало заданную величину;

• статистическая информация о структуре и составе ИТ-инфраструктуры;

• данные о росте и другая информация о развитии ИТ-инфраструктуры;

• сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Кон­фигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;

• расходы на персонал при внедрении процесса

2. Критические факторы успеха

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

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

3. функции и роли

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

• предложения по изменению сферы действия и Уровня Детализации Процесса Управления Конфи­гурациями;

• информированность всей организации о существующем Процессе Управления Конфигурациями;

• обеспечение процесса персоналом и его обучение;

• разработка системы идентификации и соглашений о присвоении имен;

• разработка интерфейсов с другими процессами;

• оценка существующих систем и внедрение новых систем автоматизации процесса;

• планирование и внедрение системы наполнения информации в Конфигурационной Базе Данных;

Quick wins.

• формирование отчетов;

• организация аудиторских проверок.