• после внедрения новой Конфигурационной Базы Данных;
• к примеру, спустя полгода с момента внедрения;
• перед серьезными изменениями и после них;
• после чрезвычайных обстоятельств;
• в любое другое удобное время.
При проведении аудита рассматриваются следующие вопросы:
• Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию?
• Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему? Какое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздействия запланированных изменений)?
• Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с соглашением о присвоении имен?
• Правильно ли используются варианты?
• Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступными к использованию?
• Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Склада эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных? Если нет, то почему?
Аудиторские проверки также можно проводить, выбирая объекты случайным образом или проводить там, где Руководитель Процесса Управления Конфигурациями считает, что информация может быть некорректной. Если существует связь с автоматическими инструментальными средствами аудита, тогда можно делать аудит соответствующих областей или формировать по ним дельта-отчеты практически ежедневно.
Если обнаруживаются расхождения, то инструментальные средства аудита не должны автоматически обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.
6.5. Контроль процесса
6.5.1. Отчеты и Ключевые показатели эффективности
В отчет по процессу Управления Конфигурациями возможно включение следующей информации:
• информация о качестве процесса;
• расхождения между регистрационными записями и реальной ситуацией, обнаруженные во время аудита (дельта);
• количество случаев, когда используется неавторизованная Конфигурация;
• количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;
• отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;
• длительность обработки Запросов на Регистрацию информации;
• перечень Конфигурационных Единиц, в отношении которых количество зарегистрированных инцидентов или изменений превышало заданную величину;
• статистическая информация о структуре и составе ИТ-инфраструктуры;
• данные о росте и другая информация о развитии ИТ-инфраструктуры;
• сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Конфигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;
• расходы на персонал при внедрении процесса.
6.5.2. Критические факторы успеха
Условием успешной работы по Управлению Конфигурациями является получение необходимой информации для поддержания базы данных в актуальном состоянии. Это означает, что обязательно нужно поддерживать взаимосвязи с процессом Управлением Изменениями, а для регистрируемых характеристик всегда должен быть найден тот, кому они требуются.
Внедрение процесса важно правильно разбить на этапы. Попытки ввести требование регистрации компонентов инфраструктуры без соответствующей подготовки обычно заканчиваются неудачей, т. к. дисциплина, необходимая для Управления Конфигурациями, не может появиться мгновенно. Записи, которые велись до ввода процесса, должны быть выведены из обращения во избежание дублирования. При запуске процесса в работу важно продемонстрировать несколько явных преимуществ, которые дает Управление Конфигурациями (быстрые удачи[97]). Кроме того, важно, чтобы обязанности по регистрации были закреплены за теми сотрудниками, у кого есть не только необходимые навыки, но и должное отношение к работе.
6.5.3. Функции и роли