Требуемая роль: change_manager.


Назначение и обновление запросов на изменение


Чтобы назначить запрос на изменение, выполните следующие действия:

  1. Перейдите в Запросы на изменение → Все запросы на изменение и откройте запрос, который необходимо назначить.
  2. На вкладке Общее нажмите на значок лупы рядом с полем Назначено на группу или Кому назначен.
  3. Выберите человека или группу, на которых хотите назначить запрос на изменение.
  4. Нажмите Сохранить или Сохранить и выйти, чтобы применить изменения.

Чтобы обновить запрос на изменение, выполните следующие действия:

  1. Перейдите в Запросы на изменение → Все запросы на изменение и откройте запрос, который необходимо обновить.
  2. Обновите необходимые поля.
  3. Нажмите Сохранить или Сохранить и выйти, чтобы применить изменения.

Планирование и создание расписания для изменений


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

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

Чтобы создать расписание для запроса на изменение, выполните следующие действия:

  1. Перейдите в Запросы на изменение → Все запросы на изменение и откройте необходимый запрос.
  2. На вкладке Расписание введите дату и время, когда работа над запросом должна быть начата и завершена.
  3. После обработки запроса введите фактическую дату и время.

Поля вкладки Расписание

Автоматические переходы статусов для запросов на изменения, в которых планируемая дата и время окончания истекли, описаны в статье Типы изменений и статусная модель.

ПолеОбязательное*Описание

Планируемая дата/время начала

Нет/Да

Выберите дату и время начала обработки запроса. Заполните это поле перед обработкой запроса на изменение.

Планируемая дата/время окончания

Нет/Да

Выберите дату и время для завершения обработки запроса. Заполните это поле перед обработкой запроса на изменение.

Если запрос не был взят в работу в согласованный период, он отменяется. 

Календарь изменений


Смотрите статью Календарь изменений.

Плановый простой

Нет/Да

Если ожидается простой услуги, укажите его продолжительность. Ответственное лицо должно заполнить это поле перед обработкой запроса на изменение.

Информация по простою

Нет/Да

Добавьте любые примечания о запланированном простое услуги. Заполните это поле перед обработкой запроса на изменение.

Возможны пересечения с изменениями

Нет/Да

Содержит запросы на изменение, время которых совпадает с данным запросом. Это может повлиять на выполнение запроса. Поле заполняется автоматически.

Фактическая дата/время начала

Нет/Да

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

Фактическая дата/время окончания

Нет/Да

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

Фактический простой

Нет/Да

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

Это поле является обязательным, если поле Плановый простой заполнено, а статус запроса на изменение содержит значение Завершено.

*Обязательность поля зависит от статуса запроса на изменение.

Чтобы спланировать запрос на изменение, выполните следующие действия:

  1. Перейдите в Запросы на изменение → Все запросы на изменение и откройте необходимый запрос.
  2. На вкладке Планирование изменений заполните необходимые поля.

Поля вкладки Планирование изменений

ПолеОбязательное*Описание

Подготовка

Нет/Да

В этом плане указаны шаги, которые необходимо выполнить, и критерии, которые необходимо соблюсти перед внедрением изменения. Заполните это поле перед обработкой запроса на изменение.

Внедрение

Нет/Да

Опишите процесс внедрения изменений. Заполните это поле перед обработкой запроса на изменение.

Валидация

Нет/Да

Опишите процесс проверки изменения после его внедрения. Заполните это поле перед обработкой запроса на изменение.

Откат

Нет/Да

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

*Обязательность поля зависит от статуса запроса на изменение.

Авторизация запросов на изменение

Запросы на изменение нестандартного типа, у которых Уполномоченный за авторизацию не равно Локальная авторизация, должны проходить процедуру авторизации. Для стандартных запросов на изменение статус меняется на Запланировано автоматически, без авторизации.

Авторизация — это запрос на утверждение уполномоченными органами разного уровня, в зависимости от уровня риска и вероятности. Чем выше уровень риска и вероятность, тем строже процедура авторизации.

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

Если все заявки на утверждение согласованы, запрос на изменение считается успешно согласованным. Статус запроса меняется на Запланировано.

Если хотя бы одна заявка на утверждение отклонена, то:

  • все остальные заявки на утверждение отклоняются автоматически.
  • запрос на изменение считается отклоненным и возвращается на этап авторизации.
  • состояние запроса меняется обратно на Зарегистрировано.

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

Уровень уполномоченного за авторизацию

Данный список ролей указан во внешнем скрипте calculateCAB, поставляемым вместе с продуктом. Этот скрипт предназначен для автоматической генерации CAB (за исключением Локальной авторизации).

В следующей таблице показана зависимость между уровнем риска запроса на изменение и уровнем полномочий.

Уровень риска

Уровень уполномоченного за авторизацию

НизкийЛокальная авторизация (авторизация лицом, указанным в поле Назначено кому)
Средний

Только менеджеры по изменениям:

  • Все менеджеры по изменениям
Высокий

Базовый комитет по изменениям:

  • Все менеджеры по изменениям
  • Владелец услуги
Очень высокий

Расширенный комитет по изменениям: 

  • Все менеджеры по изменениям
  • Все менеджеры по проблемам
  • Все менеджеры по инцидентам
  • Все владельцы связанных CI

  • Владелец услуги
  • Менеджер по изменениям контролирует жизненный цикл всех изменений.
  • Комитет по изменениям (CAB) консультирует менеджеров по изменениям в вопросах определения приоритетов, авторизации и планирования изменений.

Настройка CAB


Используемая по умолчанию структура CAB описана выше. Если вам требуется изменить ее в соответствии с организационной структурой или потребностями бизнеса, это можно сделать несколькими способами:

  • Путем изменения внешнего скрипта, содержащего параметры, отвечающие за сбор CAB. Эти изменения повлияют на все запросы на изменение, созданные позже.
  • Путем добавление новых участников в CAB указанного запроса на изменение в процессе его обработки.

Изменение скрипта CAB

Требуемая роль: admin.

Чтобы внести глобальные изменения в CAB, используемый по умолчанию, выполните следующие действия:

  1. Перейдите к разделу Настройка системы → Внешние скрипты.
  2. Нажмите на значок лупы в верхней части списка. 
  3. Введите calculateCAB в поле Наименование и нажмите Enter на клавиатуре. Будет найден соответствующий скрипт.
  4. Нажмите на наименование скрипта, чтобы открыть его.
  5. Все наборы ролей для разных CAB определяются в этом скрипте с соответствующим комментарием:
Complex CAB
  // Complex CAB
    const roles = [
      'change_manager',
      'problem_manager',
      'incident_manager'
    ];

Добавьте или удалите роль в соответствующем разделе, чтобы изменить любой CAB, базовый или сложный.

Например, если вы хотите, чтобы менеджеры по запросам входили в состав расширенного CAB, и в то же время хотите освободить от этих обязанностей менеджеров по проблемам, необходимо удалить из скрипта роль problem_manager и добавить роль request_manager.

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

Изменение конкретного CAB

Вы также можете изменить CAB для любого указанного запроса на изменение, не влияя на дальнейшие запросы. Например, если вы хотите, чтобы конкретный запрос на изменение был одобрен определенными сотрудниками.

  • CAB можно настроить для запросов на изменение в статусе Зарегистрировано или Авторизация.

  • Для запросов на изменение в статусе Авторизация, когда необходимый пользователь добавляется в CAB и запрос на изменение сохраняется, этому пользователю автоматически отправляется заявка на одобрение.
  • Виджет Настройка CAB позволяет добавлять пользователей с ролью itsm_agent.
  • Пользователи добавляются как обязательные участники процесса одобрения.
  • Опция Игнорировать автоинформирование позволяет переопределить участников CAB, назначенных скриптом, описанным выше, участниками, выбранными из списка. Этот параметр доступен только для запросов на изменение в статусе Зарегистрировано.

Чтобы изменить CAB, выполните следующие шаги:

  1. Перейдите к необходимому запросу на изменение.
  2. Убедитесь, что он находится в статусе Зарегистрировано или Авторизация, а Тип изменения не является Стандартным.
  3. Выберите вкладку Расписание.
  4. Нажмите кнопку Настроить CAB и выберите из списка нужных пользователей (вы можете выбрать столько пользователей, сколько необходимо).
  5. Нажмите Добавить.

Информация о закрытии

В соответствии со статусной моделью, запрос на изменение должен быть закрыт, когда он полностью обработан. 

Вкладка Информация о закрытии появляется и становится обязательной, когда статус запроса меняется на Завершен, Оценка результатов внедрения (PIR) или Закрыт.

ПолеОбязательноеОписание

Закрыть инициирующие объекты

Нет

Установите этот флажок, чтобы вместе с запросом были завершены связанные с ним инициирующие объекты.

Информация о закрытии

Да

Добавьте краткую информацию о процессе реализации изменения.

Код закрытия

Да

Укажите код закрытия. Доступные опции:

  • Внедрено  запрос на изменение был полностью реализован.
  • Внедрено частично  запрос на изменение был реализован с некоторыми исключениями, которые не влияют на критическую функциональность услуги.
  • Не внедрено (Откат)  запрос на изменение не был реализован, состояние услуги или конфигурационной единицы не изменилось.
  • Не внедрено (Отменено)  запрос на изменение был отменен, так как авторизация уполномоченным за авторизацию (CAB) не удалась или была отозвана.