ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

ОглавлениеДобавить в закладки К обложке

    Регистрация Запросов на Изменения

    Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):

    ? идентификационный номер Запроса;

    ? номер проблемы/известной ошибки (если имеется), связанной с Запросом;

    ? описание и определение соответствующих Конфигурационных Единиц (CI);

    ? причина изменения, включая обоснование и ожидаемый бизнес-результат;

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

    ? имя, адрес и номер телефона лица, направляющего Запрос;

    ? дата подачи;

    ? предварительная оценка необходимых ресурсов и времени.

    7.4.2. Прием в обработку

    После регистрации Запроса на Изменения (RFC) Управление Изменениями делает первичную про­верку, нет ли среди них неясных, нелогичных, непрактичных или ненужных Запросов. Такие Запро­сы отклоняются с объяснением причин. Сотруднику, направившему Запрос, всегда должна быть предоставлена возможность для защиты своего Запроса.

    Проведение изменения ведет за собой обновление в базе данных CMDB, например:

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

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

    ? новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;

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

    Если Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения включается информация, необходимая для дальнейшей обработки изменения. Позднее к записи до­бавляется следующая информация:

    ? назначенный приоритет;

    ? оценка степени воздействия и требующихся затрат;

    ? категория;

    ? рекомендации Руководителя Процесса Управления Изменениями;

    ? дата и время авторизации изменения;

    ? запланированная дата проведения;

    ? план возврата к исходному состоянию;

    ? требования по поддержке;

    ? план проведения изменения;

    ? информация о разработчике и сотрудниках, ответственных за проведение изменения;

    ? фактическая дата и время проведения изменения;

    ? дата проведения оценки результатов;

    ? результаты испытания и обнаруженные проблемы;

    ? причины отклонения Запроса (если необходимо);

    ? оценка результатов.

    7.4.3. Классификация

    После приема Запроса на Изменения (RFC) определяются его приоритет и категория.

    ? Приоритет показывает, насколько важным является данный Запрос по сравнению с другими. Это, в свою очередь, определяется его срочностью и степенью воздействия. Если изменение касается исправления известной ошибки, код приоритета уже может быть назначен Управлением Проблемами. Однако Управление Изменениями назначает окончательный код приоритета после рассмот­рения других обрабатываемых Запросов.

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

    Определение приоритета

    Пример системы кодирования приоритетов:

    ? Низкий приоритет – изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).

    ? Обычный приоритет – нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.

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

    ? Наивысший приоритет – Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых не­больших изменений, не терпящих отсрочки[110]. Изменения с таким приоритетом классифицируются как "срочные". Для срочных изменений обычные процедуры не используются, так как необходи­мые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного сове­щания Консультативного комитета (CAB) или Руководящего комитета ИТ[111]. Специально для этих целей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС)[112] с пол­номочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.


    -= 53 =-
    Регистрация.
    Забыли пароль?
    Логин
    Пароль
    Запомнить меня