В отчет по процессу Управления Конфигурациями возможно включение следующей информации:
? информация о качестве процесса;
? расхождения между регистрационными записями и реальной ситуацией, обнаруженные во время аудита (дельта);
? количество случаев, когда используется неавторизованная Конфигурация;
? количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;
? отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;
? длительность обработки Запросов на Регистрацию информации;
? перечень Конфигурационных Единиц, в отношении которых количество зарегистрированных инцидентов или изменений превышало заданную величину;
? статистическая информация о структуре и составе ИТ-инфраструктуры;
? данные о росте и другая информация о развитии ИТ-инфраструктуры;
? сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Конфигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;
? расходы на персонал при внедрении процесса.
6.5.2. Критические факторы успеха
Условием успешной работы по Управлению Конфигурациями является получение необходимой информации для поддержания базы данных в актуальном состоянии. Это означает, что обязательно нужно поддерживать взаимосвязи с процессом Управлением Изменениями, а для регистрируемых характеристик всегда должен быть найден тот, кому они требуются.
Внедрение процесса важно правильно разбить на этапы. Попытки ввести требование регистрации компонентов инфраструктуры без соответствующей подготовки обычно заканчиваются неудачей, т. к. дисциплина, необходимая для Управления Конфигурациями, не может появиться мгновенно. Записи, которые велись до ввода процесса, должны быть выведены из обращения во избежание дублирования. При запуске процесса в работу важно продемонстрировать несколько явных преимуществ, которые дает Управление Конфигурациями (быстрые удачи
). Кроме того, важно, чтобы обязанности по регистрации были закреплены за теми сотрудниками, у кого есть не только необходимые навыки, но и должное отношение к работе.
6.5.3. Функции и роли
Работа процессов происходит в горизонтальной плоскости, относительно вертикальной иерархической структуры организации. Это возможно только при четком распределении ответственностей и полномочий по их реализации. Для повышения гибкости может быть использован ролевой подход. В небольших организациях или в силу экономических причин возможно комбинирование ролей, например, Руководителя Процесса Управления Изменениями и Управления Конфигурациями. В задачи Руководителя Процесса Управления Конфигурациями может входить следующее:
? предложения по изменению сферы действия и Уровня Детализации Процесса Управления Конфигурациями;
? информированность всей организации о существующем Процессе Управления Конфигурациями;
? обеспечение процесса персоналом и его обучение;
? разработка системы идентификации и соглашений о присвоении имен;
? разработка интерфейсов с другими процессами;
? оценка существующих систем и внедрение новых систем автоматизации процесса;
? планирование и внедрение системы наполнения информации в Конфигурационной Базе Данных;
? формирование отчетов;
? организация аудиторских проверок.
6.6. Затраты и проблемы
6.6.1. Затраты
Расходы на запуск и реализацию процесса Управления Конфигурациями во многом зависят от области действия и Уровня Детализации Процесса. В число расходов входят затраты на аппаратное и программное обеспечение и персонал. Расходы на аппаратное и программное обеспечение состоят из затрат на:
? дополнительные технические средства и их конфигурирование;
? дополнительное программное обеспечение и его конфигурирование;
? лицензии, пропорционально количеству пользователей;
? разработку приложений и базы данных, наполнение их данными, настройку на требования заказчика и внедрение;
? поддержку и сопровождение базы данных;
? дополнительный персонал, необходимый для работы процесса.
6.6.2. Проблемы
ИТ-организация должна четко определить свои намерения относительно того, какие характеристики ИТ-инфраструктуры должны регистрироваться и обеспечить необходимые руководящие ресурсы для исполнения намеченного. В организации должна существовать твердая приверженность в использовании Конфигурационной Базы Данных (CMDB). Необходимо произвести перенос всех ранее использованных данных из других баз в CMDB.
На успешную реализацию процесса могут повлиять следующие проблемы:
? Неправильно определен охват (границы) Конфигурационной Базы Данных или Уровень Детализации Конфигурационных Единиц – если сфера действия Конфигурационной Базы Данных слишком мала, то важные части инфраструктуры будет невозможно проверить, исправить, защитить или восстановить. Если же наоборот охват слишком большой, то громоздкость базы данных будет препятствием, замедляющим все процессы Сервис-менеджмента. При большом количестве уровней, атрибутов и взаимоотношений будет трудно поддерживать базу данных в актуальном состоянии. Слишком низкий Уровень Детализации приведет к регистрации неполной информации о Конфигурационных Единицах и связанных с ними инцидентах, проблемах, известных ошибках и Запросах на Изменение.
? Неадекватная система ручной обработки – некоторые организации стараются как можно дольше хранить данные на бумажных носителях и покупают автоматизированные средства только тогда, когда работать становится невозможно. Это может приводить к задержкам в работе, путанице, потере персонала и ресурсов и т. д. Рекомендуется закупать автоматизированные средства обработки как можно раньше, ориентируясь на функциональные требования процесса.
? Влияние срочных изменений – всегда будут возникать ситуации, когда нужно срочно произвести изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немедленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и обновление CMDB необходимо будет сделать при первой возможности.
? Чрезмерно плотный график работы – если график изменений (Запросов на Изменения) не оставляет времени на выполнение действий в рамках процесса Управления Конфигурациями, то в работе могут появляться задержки и данный процесс будет восприниматься как препятствие. Следует составлять реалистичные графики, основываясь на прошлом опыте.
? Понимание руководством важности процесса – поскольку Управление Конфигурациями является относительно новым процессом, не всегда достаточно видимым для сотрудников, персонал может сопротивляться его принятию. Должна быть достаточная приверженность к необходимости процесса со стороны руководства. Поэтому руководитель процесса должен информировать об Управлении Конфигурациями сотрудников компании и пропагандировать этот процесс в компании. Опыт показывает, что затраты на реализацию процесса будут значительно ниже, если процесс Управления Конфигурациями представлен в компании как отдельная дисциплина с закрепленным за ней персоналом и руководителем, отвечающим за процесс.
? Попытки обхода процесса – в состоянии спешки персонал может пытаться обойти правила работы процесса Управления Конфигурациями. Если такая ситуация возникает регулярно, то после разъяснения негативных последствий таких действий возможно применение дисциплинарных мер.
Глава 7 Управление Изменениями
7.1. Введение
Быстрое развитие ИТ-технологий и рынка привели к тому, что сейчас изменения стали обычным делом. Однако опыт показывает, что инциденты, влияющие на бизнес-приложения, часто бывают вызваны изменениями. Причины таких инцидентов могут быть различными: халатность сотрудников, недостаток ресурсов, недостаточная подготовка, слабый анализ воздействия изменения, несовершенство испытаний или "болезни роста". Если инциденты, связанные с изменениями, не будут контролироваться, из-под контроля может выйти все предоставление ИТ-услуг и сам бизнес. Число инцидентов может увеличиваться, каждый из них будет требовать принятия срочных мер, что в свою очередь может привести к возникновению новых инцидентов. Ежедневное планирование часто не в состоянии учитывать увеличивающуюся рабочую нагрузку. Это может повлиять на повседневную работу и на сопровождение ИТ-услуг.
Целью Процесса Управления Изменениями является руководство проведением изменений и ограничение числа инцидентов, вызванных изменениями. Девиз Процесса Управления Изменениями:
Не всякое изменение является улучшением, но всякое улучшение является изменением.
На рис. 7.1 показан цикл изменений, вызванный предложениями на новые разработки и улучшения (Процессы Предоставления услуг и Управления Проблемами), Запросами (адресованные в Процесс Управления Изменениями) и требуемыми решениями (Процесс Управление Проблемами):
? Инновации и усовершенствования – внедрение новых услуг и новых технических средств в ИТ-инфраструктуру становится причиной появления новых регулярно возникающих ошибок
в ИТ-инфраструктуре.
? Изменения – все, от небольших инсталляций до перестановки метафреймов, при неаккуратном проведении изменений могут стать причиной появления новых регулярно возникающих ошибок в ИТ-инфраструктуре.
? Корректирующие меры — нацелены на исправление недавно появившихся регулярно возникающих ошибок.
Рис. 7.1. Входы Процесса Управления Изменениями
Управление Изменениями действует как терморегулятор между гибкостью (одобрение изменений, которые могут привести к долгосрочным ошибкам) и стабильностью (одобрение изменений для исправления долгосрочных ошибок). Корректирующие меры уменьшают число инцидентов, за счет чего снижается рабочая нагрузка. Возвращаясь к аналогии с терморегулятором, можно сказать, что температура воды соответствует Уровню Изменений и Инноваций, с которой организация может справиться. Новые дома оборудуются душами с терморегуляторами, автоматически компенсирующими любые изменения давления воды. Если кто-либо и откроет кран холодной воды где-нибудь в доме, принимающий душ не ошпарится.
7.1.1. Основные термины
Две точки принятия решения об изменениях
Существуют две точки принятия решения о проведении изменений:
? Руководитель Процесса Управления Изменениями – лицо, ответственное за предварительный просмотр (фильтрацию) и классификацию Запросов на Изменения
(RFC). В больших организациях в помощь Руководителю Процесса могут существовать Координаторы изменений, осуществляющие взаимодействие между ним и различными подразделениями организации. Одной из задач Процесса Управления Изменениями является получение требуемой авторизации изменения. В определенной степени сам процесс уже имеет полномочия, но для проведения некоторых изменений может потребоваться согласование с руководством ИТ (например, с Руководящим комитетом
или Исполнительным комитетом
). Руководитель Процесса Управления Изменениями также несет ответственность за планирование и координацию проведения изменений.
? Консультативный комитет по изменениям
(CAB) – консультативный орган, регулярно собирающийся для оценки и планирования изменений. Чаще всего одно или несколько значительных изменений выносятся на обсуждение Комитета. Отдельно создается комитет по срочным изменениям
(ЕС), который назначается руководством для принятия чрезвычайных решений. Состав Консультативного комитета является гибким и включает представителей всех основных ИТ-подразделений:
? Руководителя по Управлению Изменениями (председатель);
? Руководитель по Управлению (Уровнями) Услуг;
? Представителей Службы Service Desk и Процесса Управления Проблемами;
? Руководителей линейных подразделений компании;
? Бизнес-руководителей (или их представители) со стороны заказчика;
? Представителей пользователей;
? Представителей разработчиков приложений;
? Администраторов программного обеспечения и системных администраторов;
? Представителей поставщиков.
Охват (сфера действия или границы)
процесса
Сфера действия Процесса Управления Изменениями определяется вместе со сферой действия Процесса Управления Конфигурациями, так как Управление Конфигурациями предоставляет информацию для оценки воздействия изменения на инфраструктуру. После проведения изменения Управление Конфигурациями обновляет Конфигурационную Базу Данных (CMDB). Если в базе данных CMDB ведется учет компьютерных мышей и клавиатур, то замена клавиатуры рассматривается как изменение. Определение сферы действия процесса является динамической деятельностью, так как сфера действия может меняться, и потребность в информации из базы данных CMDB также меняется. Следовательно, сфера действия должна регулярно пересматриваться, и модель данных CMDB должна обновляться соответственно.
Для того, чтобы обеспечить эффективное взаимодействие Процессов Управления Изменениями и Управления Конфигурациями, необходимо регистрировать изменения и обновлять соответствующие записи в CMDB. Можно допустить, что ряд повседневных заданий, точно определенных и подчиняющихся установленным процедурам (т. е. стандартных заданий), не требуют контроля со стороны Процесса Управления Изменениями. Примерами таких заданий могут быть установка кассет для резервного копирования, создание идентификаторов (ID) пользователей и т. д. Эти действия не обрабатываются как изменения, а самое большее классифицируются как Запросы на Обслуживание в рамках Процесса Управления Инцидентами. Внимательное изучение стандартных действий может быть полезно для предотвращения излишней бюрократизации Процесса Управления Изменениями.
Одним из способов выполнения таких действий является определение так называемых "предварительно авторизованных"
изменений (или "категории 0"), которые записываются в базу данных изменений (предпочтительно самими запрашивающими), но не требуют использования процедур по Управлению Изменениями. Например, если при приеме на работу нового сотрудника обычно выполняются четырнадцать действий (создание новой учетной записи
, настройка рабочей станции, электронной почты и т. д.), то эти действия не требуют столь внимательного изучения, как значительные изменения инфраструктуры. Такой вид стандартных изменений обрабатывается по типовому шаблону как предварительно авторизованный "Запрос на Обслуживание".
7.2. Цель процесса
Целью Процесса Управления Изменениями является гарантия использования стандартных методов и процедур для быстрой обработки изменений с минимальным возможным отрицательным воздействием изменения на качество услуг. Все изменения должны быть отслеживаемыми, чтобы можно было ответить на вопрос: "Что изменилось?"
7.2.1. Преимущества использования процесса
Для эффективного предоставления ИТ-услуг организация должна уметь обрабатывать большое количество изменений с надлежащим Уровнем Ответственности при принятии решений.
Преимуществами Процесса Управления Изменениями являются:
? уменьшение отрицательного воздействия изменений на качество ИТ-услуг;
? более точные оценки затрат для предлагаемых изменений;
? уменьшение количества изменений, потребовавших возврата к исходному состоянию, и каждый такой возврат происходит более гладко;
? предоставление руководству более полной информации об изменениях, что позволяет выявлять проблемные области;
? повышение производительности работы пользователей за счет более высокой стабильности и качества ИТ-услуг;
? повышение производительности работы ИТ-персонала, не отрывающегося от плановой работы для проведения срочных изменений и процедур возврата;
? рост способности компании проводить частые изменения без нарушения стабильности ИТ-среды.
7.3. Процесс
Процесс Управления Изменениями принимает или отклоняет каждый Запрос на Изменение (RFC). Руководитель Процесса Управления Изменениями содействует работе процесса, но реальные решения о наиболее значительных изменениях принимаются консультативным комитетом по изменениям (CAB). Членами комитета CAB являются представители разных отделов компании, а также заказчиков и поставщиков. Ответственность за предоставление информации о потенциальном воздействии предлагаемых изменений несет Процесс Управления Конфигурациями.
Рис. 7.2. Позиционирование Процесса Управления Изменениями
Входы Процесса Управления Изменениями включают в себя:
? Запросы на Изменения (RFC);
? информация из базы данных CMDB (в частности, анализ степени воздействия изменений);
? информация из других процессов (из Базы данных мощностей CDB, информация о бюджете и т. д.);
? планирование изменений (Согласованный план изменений
FSC).
Выходы процесса включают:
? обновленный план изменений (Согласованный план изменений FSC);
? моменты инициирования действий (триггеры) в рамках Процессов Управления Конфигурациями и Управления Релизами;
? повестка дня Консультативного комитета CAB, протоколы и принятые решения;
? отчеты по Процессу Управления Изменениями.
Управление Изменениями имеет описанную ниже взаимосвязь с другими процессами.
7.3.1. Управление Инцидентами
Процесс Управления Инцидентами имеет двухстороннюю связь с Процессом Управления Изменениями. С одной стороны, Управление Изменениями обрабатывает направляемые Управлением Инцидентами Запросы на Изменения для разрешения инцидента или запрашиваемые Управлением Проблемами изменения, устраняющие причину инцидента. С другой стороны, несмотря на многочисленные предосторожности, внедрение изменений все же может привести к возникновению инцидентов. Это может быть связано с ошибками проведения изменения или с недостаточной подготовкой пользователей к изменениям. Соответствующий персонал Управления Инцидентами должен быть информирован о проведении изменений, чтобы иметь возможность быстро определить и устранить возникающие инциденты.
7.3.2. Управление Конфигурациями
Управление Изменениями и Управление Конфигурациями являются настолько тесно связанными процессами, что они могут быть эффективно интегрированы между собой – шаг, рекомендованный в библиотеке ITIL.
Изменения регистрируются под контролем Процесса Управления Конфигурациями, анализ воздействия изменений также проводится с участием Процесса Управления Конфигурациями. Управление Конфигурациями определяет зависимость между Конфигурационной Единицей CI (вовлеченной в проводимое изменение) и другими CI, чтобы определить, на какие другие элементы будет воздействовать это изменение.
7.3.3. Управление Проблемами
Взаимосвязь между Процессами Управления Изменениями и Управления Проблемами во многом похожа на такую же связь между Процессами Управления Изменениями и Управления Инцидентами. С одной стороны, изменения часто бывают необходимы для разрешения проблем. С другой стороны, если проведение изменений недостаточно контролируются, они могут привести к новым проблемам.
7.3.4. Управление Релизами
Изменения часто приводят к необходимости разработки и распространения новых приложений или установке технической инфраструктуры. Это осуществляется с помощью Процесса Управления Релизами. Контроль над распространением новых версий осуществляется Процессом Управления Изменениями.
7.3.5. Управление Уровнем Сервиса
Процесс Управления Уровнем Сервиса вовлечен в определение степени воздействия изменений на предоставление услуг и бизнес-процессы. В зависимости от ситуации в Консультативном комитете (CAB) могут участвовать представители Процесса Управления Уровнем Сервиса. Если изменение оказывает значительное воздействие или связано с высоким риском, его внедрение и сроки должны всегда обсуждаться с заказчиком. Управление Изменениями направляет в Управление Уровнем Услуг отчет "Проектируемая доступность услуг"
(PSA). В этом отчете Управление Изменениями излагает изменения в имеющихся Соглашениях об Уровне Услуг (SLA) и воздействие Согласованного плана изменений (FSC) на доступность услуг.
7.3.6. Управление Доступностью
Процесс Управления Доступностью инициирует изменения, направленные на повышение доступности услуг и проверяет, привели ли предпринимаемые меры к ожидаемому результату. Управление Доступностью часто привлекается при оценке потенциального воздействия изменений, так как это воздействие может повлиять на доступность услуги.
7.3.7. Управление Мощностями
Руководитель Процесса Управления Мощностями в первую очередь занимается вопросом анализа совокупного эффекта по результатам изменений в течение продолжительного периода времени, например, увеличением времени реакции приложений или потребностью в большей емкости для хранения информации. На основе составленного Плана мощностей Управление Мощностями регулярно предлагает усовершенствования и инициирует изменения в форме Запросов на Изменения (RFC).
7.3.8. Управление Непрерывностью ИТ-услуг
Превентивные мероприятия и планы восстановления, гарантирующие непрерывность услуг, должны постоянно контролироваться, так как изменения инфраструктуры могут сделать эти планы неосуществимыми или избыточными. Процесс Управления Изменениями действует в тесной взаимосвязи с Процессом Управления Непрерывностью ИТ-услуг, чтобы в нем учитывались все изменения, которые могут повлиять на планы восстановления, и предусматривались меры, необходимые для проведения восстановления.
7.3.9. Виды деятельности в рамках Процесса Управления Изменениями
Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:
? Направление Запроса – не включается в виды деятельности по Управлению Изменениями, но поддерживается этим процессом, так как Управление Изменениями отвечает за правильную регистрацию всех изменений.
? Прием в обработку – предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.
? Классификация – сортировка Запросов на Изменения по категориям и приоритету.
? Планирование – объединение изменений, планирование их проведения и планирование необходимых ресурсов.
? Координация – координирование компоновки, испытаний и проведения изменений.
? Оценка – оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).
Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями
7.4. Виды деятельности
7.4.1. Регистрация
Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.
Что представляет собой Запрос на Изменения (RFC)?
Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные задания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (например, изменения "категории 0", см. 7.1.1). В результате возникает следующая классификация изменений:
? Запросы на Обслуживание (здесь: стандартные изменения) – полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменениями. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслуживание являются изменениями).
? Запросы на Изменения – все другие Запросы на Модификацию инфраструктуры.
Откуда исходят Запросы на Изменения (RFC)?
Запросы на Изменения могут касаться всех аспектов инфраструктуры в пределах сферы действия процессов ITIL. Любой сотрудник, работающий с инфраструктурой, может подать Запрос на Изменения (RFC). Можно определить несколько источников Запросов на Изменения (RFC), например:
? Управление Проблемами – предлагает решения для исключения долговременных ошибок с целью стабилизации предоставления услуг.
? Заказчики – могут запросить больший, меньший Уровень Сервиса или другие услуги. Эти запросы могут подаваться прямо как Запрос на Изменения или направляться через Управление Уровнем Сервиса (SLM) или через Управление Отношениями с заказчиками ИТ (IT CRM).
? Политика компании – тактические и стратегические процессы из области Предоставления услуг (Service Delivery Set) и Указания руководства (Managers Set) могут привести к направлению Запросов на Изменение Услуг. Например, Управление Уровнем Услуг, Управление Доступностью и Управление Мощностями составляют ежегодные планы улучшения услуг, которые позднее могут быть поданы как Запросы на Изменения (RFC).
? Законодательство – если возникают ограничения, регламентирующие бизнес-деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.
? Поставщики – поставщики выпускают новые версии и модификации
своих продуктов и сообщают об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определенные версии или что не могут гарантировать производительность версии (например, из-за "Ошибки тысячелетия" – Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).
? Проекты – проект часто вызывает ряд изменений. Руководство проекта должно эффективно согласовывать свои действия с Управлением Изменениями с помощью соответствующих процессов, таких как Управление Уровнем Услуг, Управление Мощностями и т. п.
? Любой другой сотрудник ИТ - в принципе, любой сотрудник может подать предложения по улучшению услуг. В особенности, ИТ-персонал может способствовать усовершенствованию процедур по поддержке и предоставлению услуг и обновлению руководств.
Регистрация Запросов на Изменения
Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):
? идентификационный номер Запроса;
? номер проблемы/известной ошибки (если имеется), связанной с Запросом;
? описание и определение соответствующих Конфигурационных Единиц (CI);
? причина изменения, включая обоснование и ожидаемый бизнес-результат;
? текущая и новая версия изменяемой Конфигурационной Единицы;
? имя, адрес и номер телефона лица, направляющего Запрос;
? дата подачи;
? предварительная оценка необходимых ресурсов и времени.
7.4.2. Прием в обработку
После регистрации Запроса на Изменения (RFC) Управление Изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных Запросов. Такие Запросы отклоняются с объяснением причин. Сотруднику, направившему Запрос, всегда должна быть предоставлена возможность для защиты своего Запроса.
Проведение изменения ведет за собой обновление в базе данных CMDB, например:
? изменение статуса существующей Конфигурационной Единицы;
? изменение взаимосвязи между различными Конфигурационными Единицами;
? новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;
? новый владелец или другое месторасположение Конфигурационной Единицы.
Если Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения включается информация, необходимая для дальнейшей обработки изменения. Позднее к записи добавляется следующая информация:
? назначенный приоритет;
? оценка степени воздействия и требующихся затрат;
? категория;
? рекомендации Руководителя Процесса Управления Изменениями;
? дата и время авторизации изменения;
? запланированная дата проведения;
? план возврата к исходному состоянию;
? требования по поддержке;
? план проведения изменения;
? информация о разработчике и сотрудниках, ответственных за проведение изменения;
? фактическая дата и время проведения изменения;
? дата проведения оценки результатов;
? результаты испытания и обнаруженные проблемы;
? причины отклонения Запроса (если необходимо);
? оценка результатов.
7.4.3. Классификация
После приема Запроса на Изменения (RFC) определяются его приоритет и категория.
? Приоритет показывает, насколько важным является данный Запрос по сравнению с другими. Это, в свою очередь, определяется его срочностью и степенью воздействия. Если изменение касается исправления известной ошибки, код приоритета уже может быть назначен Управлением Проблемами. Однако Управление Изменениями назначает окончательный код приоритета после рассмотрения других обрабатываемых Запросов.
? Управление Изменениями присваивает категорию, исходя из степени воздействия и требуемых ресурсов. Эта классификация определяет дальнейшие процедуры обработки Запроса и обозначает важность изменения.
Определение приоритета
Пример системы кодирования приоритетов:
? Низкий приоритет – изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
? Обычный приоритет – нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.