Верификация и аудит
Если обнаруживаются расхождения, то инструментальные средства аудита не должны автоматически обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.
Управление изменениями
В ходе эксплуатации ИУС требуется постоянно вносить изменения в состав ее ИТ-компонентов, а также в их конфигурацию. Бесконтрольное внесение данных изменений может негативно повлиять на уровень качества предоставляемых ИТ-сервисов, поэтому внесение таких изменений должно документироваться и контролироваться.
Целью внедрения подсистемы управления изменениями является минимизация негативного влияния вносимых изменений в состав и конфигурацию ИТ-компонентов ИУС на качество предоставляемых ИТ-сервисов.
Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:
§ Направление Запроса — не включается в виды деятельности по Управлению Изменениями, но поддерживается этим процессом, так как Управление Изменениями отвечает за правильную регистрацию всех изменений.
§ Прием в обработку — предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.
§ Классификация — сортировка Запросов на Изменения по категориям и приоритету.
§ Планирование — объединение изменений, планирование их проведения и планирование необходимых ресурсов.
§ Координация — координирование компоновки, испытаний и проведения изменений.
§ Оценка — оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).
Виды деятельности
Регистрация
Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.
Что представляет собой Запрос на Изменения (RFC)?
Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные задания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (на пример, изменения «категории 0», см. 7.1.1). В результате возникает следующая классификация. изменений:
§ Запросы на Обслуживание (здесь: стандартные изменения) — полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменениями. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслуживание являются изменениями).
§ Запросы на Изменения — все другие Запросы на Модификацию инфраструктуры.
Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями
Регистрация запросов на изменения
Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):
§ идентификационный номер Запроса;
§ номер проблемы/известной ошибки (если имеется), связанной с Запросом;
§ описание и определение соответствующих Конфигурационных Единиц (CI);
§ причина изменения, включая обоснование и ожидаемый бизнес-результат;
§ текущая и новая версия изменяемой Конфигурационной Единицы;
§ имя, адрес и номер телефона лица, направляющего Запрос;
§ дата подачи;
§ предварительная оценка необходимых ресурсов и времени.