? Какие ресурсы имеются для сбора и обновления информации?

? Насколько зрелыми являются наши административные и материально-технические (логистиче­ские) процессы?

? На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распростране­ние компонентов отдельно от основного компонента?

? Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и конт­ролироваться?

? Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диаг­ностики этих сбоев?

? Для каких компонентов следует регистрировать статус и его предысторию?

? Какие компоненты используются в организации в различных версиях или вариантах?

? Изменения в каких компонентах могут повлиять на возможности и доступность услуг?

? Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери?

? Какова настоящая и будущая информационная потребность у других процессов?

? Для каких компонентов требуется такая информация, как серийный номер, дата покупки и по­ставщик, и какая информация необходима для бухгалтерии?

? Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг?

? Какая информация необходима для выставления счетов заказчикам?

? Насколько реальны наши стремления, не нужна ли корректировка?

Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Сле­дует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). По­нятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежа­щие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже.

Охват (сфера действия, границы)

При создании Конфигурационной Базы Данных и обновлении модели данных следует определить­ся, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфи­гурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как "электронные органайзеры" (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса? Границы, опреде­ленные для процесса Управления Конфигурациями, влияют на границы, в которых, например, про­цесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, прово­димый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д.

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

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

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

На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инци­дентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предо­ставление сервиса. Такая информация в дальнейшем может быть использована для улучшения ус­луг. У такой "сервисной" Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В приве­денном примере услуга "В" полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге "А", входят в сферу действия Конфигура­ционной Базы Данных (например, находятся в рассматриваемой организации), это означает, что ус­луга "А" не может полноценно поддерживаться.

Рис. 6.3. Охват Конфигурационной Базы Данных (источник: OGC)

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

Уровень Детализации CMDB

Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями. Здесь нет универсальных решений. На этом этапе анализируется информация о Конфигурационных Единицах. Для определения Уровня Детализации составляется схема взаимоотношений между задействованными Конфигурационными Единицами и выбирается требуемая глубина детализации CMDB. Кроме того, определяются имена и атрибуты для Конфигурационных Единиц.

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

Взаимоотношения между Конфигурационными Единицами

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

? Взаимоотношения на физическом уровне:

? Является частью: это взаимоотношения типа "parent/child" ("родитель/ребенок"), например, дисковод является частью PC, а программный модуль – частью программы.

? Подключена к: например, PC подсоединен к сегменту сети.

? Требуется для: например, технические средства требуются для работы приложения.

? Взаимоотношения на логическом уровне:

? Является копией: что-то является копией стандартного модуля, Базисной Конфигурации или программы.

? Связано с: процедурой, руководством и документацией, Соглашением об Уровне Услуг или группой заказчиков.

? Используется: например, Конфигурационная Единица, участвующая в предоставлении услуги, или программный модуль, к которому обращаются несколько программ.

Глубина CMDB

При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов. Выбираются родительские Конфигурационные Единицы и определяется количество уровней, необхо­димых для их детализации. На самом высоком уровне находится сама ИТ-инфраструктура. Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять конт­роль. Включение Конфигурационных Единиц в Конфигурационную Базу Данных будет целесообраз­ным только в том случае, если информация об этих CI будет полезна для других процессов ITIL. Определяя уровни и глубину Конфигурационной Базы Данных, следует помнить, что изменение в любой Конфигурационной Единице, зарегистрированной в CMDB, должно пройти через формаль­ный процесс Управления Изменениями, прежде чем оно будет произведено. Поэтому регистрируя такой компонент как компьютерная мышь в Конфигурационной Базе Данных, создается ситуация, при которой любой Запрос на новую мышь уже не будет проходить как Запрос на Обслуживание , а должен будет проводиться через процесс Управления Изменениями в форме Запроса на Изменение (RFC). Это показательный пример для организаций, которые чрезмерно увлекаются детализацией.

При определении структуры Конфигурационной Базы Данных руководствуются следующими сооб­ражениями:

? Чем больше уровней в базе данных, тем больше информации надо обрабатывать. Это ведет к уве­личению рабочей нагрузки и созданию более сложной CMDB.

? Чем меньше уровней, тем слабее контроль и хранится меньше информации об инфраструктуре.

Если степень детализации CMDB слишком мала, то становится невозможным эффективный мони­торинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой едини­цы . Например, PC с двумя видами жесткого диска будет проходить как Вариант "А" и Вариант "В". Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для со­провождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддержи­вать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: "Какой драйвер нужен для этого типа технических средств?", "К какому сегменту подсоединена сетевая плата?" и "Какая программа использует эту библиотеку?".

Соглашения о присвоении имен

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

Соглашения о присвоении имен также можно использовать для физической маркировки Конфигу­рационных Единиц, для упрощения их идентификации при инвентаризации (аудите), в процессе со­провождения и регистрации инцидентов. Некоторые из предложенных библиотекой ITIL правил присвоения имен:

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

? Контролируемые документы, такие как Соглашения об Уровне Услуг (SLA), процедуры и органи­зационные схемы должны маркироваться с указанием номера Конфигурационной Единицы, номе­ра версии и даты выпуска версии.

? Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения (DSL), см. главу "Управление Релизами". Все компоненты программного обеспече­ния должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.

Атрибуты

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

АТРИБУТ	ОПИСАНИЕ
Номер/метка Конфигурационной Единицы или штриховой код	Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер
Номер лицензии или серийный номер	Идентификационный номер поставщика в виде серийного номера или номера лицензии
Номер инвентаризационной системы	Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой
Номер модели/ идентификационный номер Каталога	Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-C366-4000-T
Наименование модели	Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ
Изготовитель	Изготовитель Конфигурационной Единицы
Категория	Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.)
Тип	Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль
Гарантийный срок	Срок действия гарантии
Номер версии	Номер версии Конфигурационной Единицы
Расположение	месторасположение Конфигурационной Единицы, например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица
Владелец	Имя владельца или лица, ответственного за Конфигурационную Единицу
Дата начала ответственности	Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу
Источник/поставщик	Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика "X" и т. д.
Лицензия	Номер лицензии и ссылка на лицензионное соглашение
Дата поставки	Дата поставки Конфигурационной Единицы в организацию
Дата приемки	Дата приемки Конфигурационной Единицы в операционную среду
Статус (текущий)	Текущее состояние Конфигурационной Единицы, например, "в тестировании", "в работе", "выведено из операционной среды"
Статус (запланированный)	Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий
Стоимость	Стоимость приобретения Конфигурационной Единицы
Остаточная	Текущая стоимость Конфигурационной Единицы с учетом амортизации амортизационная стоимость
Комментарии	Текстовое поле для комментариев, например, для описания отличий одного варианта от другого

Таблица 6.1. Примеры атрибутов

В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инци­дентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.

АТРИБУТ	ОПИСАНИЕ
Номера запросов на изменения (RFC)	Номер (номера) Запросов на изменение (RFC), открытых в настоящий момент или ранее для данной Конфигурационной Единицы
Номера изменений	Номер (номера) изменений, открытых в настоящий момент или ранее для данной Конфигурационной Единицы
Номера проблем	Номер (номера) проблем, открытых в настоящий момент или ранее для данной Конфигурационной Единицы
Номера инцидентов	Номер (номера) инцидентов, связанных с данной Конфигурационной Единицей

Таблица 6.2. Примеры других записей, связанных с Конфигурационными Единицами

Обычно номера соответствующих Конфигурационных Единиц входят в состав регистрационных запи­сей инцидентов, проблем и изменений. Независимо от выбранного подхода должны поддерживаться вза­имоотношения между Конфигурационными Единицами и следующими записями (табл. 2).

АТРИБУТ	ОПИСАНИЕ
Взаимоотношения с родительскими Конфигурационными Единицами	Ключ или номер родительской Конфигурационной Единицы
Взаимоотношения между дочерними Конфигурационными Единицами	Ключ или номер дочерней Конфигурационной Единицы
Другие взаимоотношения	Взаимоотношения между Конфигурационной Единицей и другими единицами, отличными от родительских и дочерних, например, эта Конфигурационная Единица имеет статус "используется" или "подключена к..."

Таблица 6.3. Атрибуты взаимоотношений

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

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

Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оператив­ной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют та­кую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предостав­ляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.

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

Базисная Конфигурация

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

? авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);

? стандартных Конфигурационных Единиц для учета информации о стоимости;

? базы при разработке и тестировании новых Конфигураций;

? для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигура­цией после проведения изменений;

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

? базы при установке нового программного обеспечения.

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

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

До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:

? Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?

? Финансы: приемлемы ли затраты на поддержку?

? Влияние: приемлем ли уровень воздействия модели/продукта на услугу?

Регистрация

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

6.4.3. Мониторинг статуса

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

Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы

Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом "неэксплуатирующиеся запасные части", то эти тех­нические средства нельзя перераспределять куда-либо еще без предварительного согласования, на­пример, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.

Может быть использована следующая классификация:

? Новые Конфигурационные Единицы:

? В разработке/заказе;

? Протестирована;

? Принята (по результатам тестирования).

? Существующие Конфигурационные Единицы:

? Получена (принята в операционную среду);

? Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;

? Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и до­кументация (также являющаяся Конфигурационной Единицей) будут предоставлены;

? На обслуживании;

? Не функционирует.

? Архивированные Конфигурационные Единицы:

? Выведена из операционной среды;

? Исключена (deleted);

? Удалена (removed);

? Похищена;

? Продана или истек срок аренды/лизинга;

? В архиве в ожидании безвозмездного дарения, продажи или уничтожения;

? Уничтожена.

? Все Конфигурационные Единицы:

? В наличии;

? Получена по заказу или доступна новая версия;

? Тестируется;

? Одобрена для инсталляции;

? Активная Конфигурационная Единица находится в использовании;

? Запасные части.

6.4.4. Контроль

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

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

Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение – при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library – DSL).

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

Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инф­раструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигураци­онной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями . Формализованные записи об изменениях являются основным источни­ком информации об изменениях в инфраструктуре, которая используется для обновления Конфигу­рационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операцион­ной средой и проведения закупок.

Для того, чтобы авторизованная Конфигурационная База Данных отражала реальную ситуацию, не­обходимо проводить мониторинг следующих действий:

? добавление Конфигурационной Единицы;

? изменение статуса Конфигурационной Единицы, например, "работает" или "не работает" (полез­но для процесса Управления Доступностью);

? изменение владельца Конфигурационной Единицы;

? изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Еди­ницами;

? удаление Конфигурационной Единицы;

? возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;

? возобновление или изменение лицензии;

? обновление детальной информации о Конфигурационной Единице после аудита.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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