S – Rb, Sn 4 страница

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

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

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

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

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

Резюме

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

· Инициатор изменения создает и передает на рассмотрение полный отчет о требуемом изменении, оформленный в виде RFC.

· Назначенный рецензент определяет, является ли объем информации, содержащейся в RFC, достаточным для того, чтобы провести его утверждение.

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

· Этот циклический процесс приводит к получению рецензированного RFC, готового для рассмотрения в процессе классификации изменения.

Классификация изменений

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

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

Рис. 3. Последовательность операций уточнения классификации

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

Задача присваивания значений приоритета является исключительно важной, поскольку от приоритета запроса непосредственно зависит, в каком порядке и в какие сроки этот запрос будет проходить процессы изучения и реализации. Особенно важно правильно проводить классификацию по экстренным приоритетам, присваивая этот приоритет только тем изменениям, которые в нем нуждаются, поскольку путь таких изменений через процесс реализации изменений значительно ускоряется. Не менее важными эти соображения становятся, если RFC, которым ранее был присвоен неправильный приоритет, снова передаются менеджеру изменений для повторной оценки. Менеджер изменений может откорректировать приоритет, если он не считает приемлемым значение приоритета, предложенное инициатором изменения, или если изменение, имеющее экстренный приоритет, не рассматривается как безотлагательное кризисным комитетом консультативного совета по изменениям (CAB/EC).

Дата добавления: 2015-01-03