Типы изменений и статусная модель
Целью процесса управления изменениями является контроль жизненного цикла всех изменений. Это позволяет вносить полезные изменения с минимальным нарушением работы IT-услуг.
Типы изменений
Поддерживаются три типа изменений: стандартные, нормальные и экстренные. Тип изменения определяет, какую статусную модель следует использовать и какой процесс изменения необходимо соблюдать.
Стандартное изменение
Стандартное изменение – это предварительно санкционированное изменение с низким уровнем риска, относительно распространенное и соответствующее определенной процедуре или рабочей инструкции.
Изменения этого типа внедряются чаще всего, имеют повторяющиеся шаги и успешно внедрялись ранее. Поскольку стандартные изменения предварительно утверждаются, они следуют процессу, в котором этапы авторизаций не требуются.
Чтобы сделать запрос на изменение более эффективным, вы можете создать шаблон в соответствующем каталоге на основе утвержденных стандартных запросов на изменение. Кроме того, это позволяет команде контролировать изменения, авторизованные как стандартные.
Нормальное изменение
Нормальные изменения используется для реализации полезного изменения, которое не является стандартным или экстренным.
Эти изменения требуют полного набора оценок и авторизаций, таких как техническое утверждение, разрешение Комитета по изменениям (CAB), разрешение менеджера и другие. Планирование нормальных изменений предусматривает возможные перебои в обслуживании, поэтому эти изменения часто планируются за пределами периодов блокировки изменений или во время определенных периодов обслуживания. Этот тип изменений используется для реализации полезного изменения для любой услуги, которое не является стандартным или экстренным изменением для какой-либо другой услуги.
Экстренное изменение
Экстренное изменение – это изменение, которое необходимо внедрить как можно скорее, например, для разрешения значительного инцидента или внедрения исправления (патча) безопасности.
Вы можете использовать экстренный запрос, чтобы исправить:
- текущий сбой или ситуацию, когда некий сбой уже успел повлиять на бизнес-процессы.
- ситуацию, когда н егативное влияние останется неизменным, если не предпринимать никаких действий.
Приоритет экстренного изменения позволяет ему перейти напрямую в необходимый статус для утверждения группой Комитета по изменениям (CAB).
Статусная модель изменений
На приведенной ниже схеме показаны статусные модели стандартных, нормальных и экстренных типов запроса на изменение.
Описание статусов
В следующей таблице перечислены переходы статусов для стандартных, нормальных и экстренных изменений.
- Регистрация
- Разрешение и планирование
- Планирование
- Планирование и реализация
- Закрытие
| Статус | Описание | Доступные переходы |
|---|---|---|
| Зарегистрировано | Этот статус предназначен для новых запросов на изменение.
|
|
| Статус | Описание | Доступные переходы |
|---|---|---|
| Авторизация | Этот статус является обязательным для экстренных и нормальных изменений. После того как все этапы авторизации пройдены, экстренные и нормальные запросы на изменение переходят в статус Запланировано. Нормальное изменение также можно отклонить и превратить в зарегистрированное. Если в рамках нормального или экстренного изменения в поле Уполномоченный за авторизацию указано значение Локальная авторизация, этап авторизации пропускается. |
|
| Статус | Описание | Доступные переходы |
|---|---|---|
| Запланировано | В этом статусе запрос на изменение имеет следующие предварительные условия:
Когда запрос на изменение находится в ст атусе Запланировано, поля на форме записи становятся доступными только для чтения, за исключением следующих:
По истечении Плановой даты/времени окончания стандартные изменения автоматические переводятся системой в статус Завершено. При этом для нормальных и экстренных изменений автоматический переход не осуществляется. Только агент может перевести их из Запланировано в любой другой доступный статус. |
|
| Статус | Описание | Доступные переходы |
|---|---|---|
| В работе | Этот статус показывает, что в настоящее время запрос находится в процессе реализации. Когда статус запроса меняется на В работе, пользователи, ответственные за связанные задачи и зменения, получают уведомление, что работа над задачами может быть начата. Когда работа закончена, статус должен быть изменен на Завершено. Когда запрос на изменение находится в статусе В работе, поля на форме записи становятся доступными только для чтения, за исключением следующих:
|
|
| Статус | Описание | Доступные переходы |
|---|---|---|
| Завершено | После того как работа завершена и запрос переходит в этот статус, запрашивающая сторона может провести необходимые тесты и дать отзыв о результатах реализации. Запрос на изменение может быть переведен в статус Завершено, только если все связанные с ним задачи изменения тоже Завершены. Если запрашивающая сто рона удовлетворена результатами, можно перевести изменение в статус Закрыто. Когда запрос на изменение находится в статусе Завершено, поля на форме записи становятся доступными только для чтения, за исключением следующих:
|
|
| Оценка результатов внедрения | Когда запрос выполнен (успешно или нет), менеджер по изменениям имеет право провести оценку результатов внедрения на основе реализации изменения. Это хорошая практика, которая позволяет извлечь полезный опыт после внедрения изменения, особенно если в процессе возникли какие-либо проблемы. После проверки, по аналогии со статусом Завершено, изменение можно перевести в статус Закрыто. |
|
| Закрыто | Все действия по этому запросу на изменение завершены и запрос нельзя открыть повторно. |
*Ответственный за задачу пользователь может перевести запрос в статус Завершено из статуса Зарегистрировано, нажав кнопку Отменить. Менеджер изменений (change_manager) может перевести запрос в статус Завершено из статуса Зарегистрировано, Авторизация и Запланировано.
Код закрытия при этом будет Не внедрено (Отменено). Все связанные задачи изменений и задачи на согласование также будут отменены.