Регистрация Запросов па Измеиепия
Вот npiiMciibi и11(х)рмаи1П1, которая может включаться в Запросы на Изменения (RFC):
•илентификаипопный номер Запроса;
•номер проблемы/известно!! ошибки (если имеется), связа1НГ0п с Запросом;
•оппсание п онределенпе соответствующих Конфпруращюнных Единиц (CI);
•нрпч1ша измеиепия, включая обоспованне п ожпдаеьплп бизнec-pe:yльтaт;
•гскуп1ая и новая версия пзмсняелюп Кон(])Игураг1понной Единицы;
•имя, адрес и помер телефона лица, направляющего Запрос;
•дата подачи;
•предварительная оценка необходимых ресурсов и времени.
7.4.2.Прием в обработку
После регистрации Запроса па Изменения (RFC) Управление Изменениями делает первичную проверку, 1гет ли среди них неясных, нелогич1п>1х, непрактичных или испужтпгх Запросов. Такие Запро-. сы отклоняются с обьясне!П1ем причин. Сотруднику, направившему Запрос, всегда должна быть предоставлена возможность для запщты своего Запроса.
Проведение изменения ведет за собой обновление в базе данных CMDB, например:
•n:jMeneinie статуса суи1ествующей Копфигурациоппой Единицы;
•изменение взапл;освязи между различными Кон()игураци<лип51ми Единигтамн;
•новая Конфигурационная Единица или изменение суп1ествуюн1ей Кон()нгурационной Единицы;
•новый владелец или другое месгорасположепие Конфигурациотюй Еди1ШЦ1>1.
Еслп Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения вюночастся ипформащгя, тгеобходимая для дальнеЙ1ней обработки измене1П1я. no;vHiee к записи добавляется следующая информация;
•назначенный приоритет;
•оценка степени во:1дейстпия и гребуюнптхся затрат;
•категория;
•рекомеидацгн! Руководителя Процесса Управления Изменениями;
•дата и время авторизации изменения;
•занлаиировапна! дата проведения;
•план возврата к исходному состоянию:
•требования по поддержке;
•план пропедетш изменення;
•информация о разработчике и сотрудниках, ответственных за проведеппе изменения;
•фактическая дата и время проведения изменения;
•дата проведения оценки резульгатов;
•результапл исиыта1П1Я и обнаруженпые проблемы;
•причины отклонения Запроса (если необходимо);
•оценка результатов.
7.4.3.Классификация
После приема Запроса на Измепешгя (Ri-C) определяются его приоритет и категория.
•Приоритет показьп»1ет, насколько важным является данный Запрос по сравнетпо с другими. Это, в свою очередь, определяется его срочностью и степенью во.здеиствия. Если г/зменсние касается нсправления известной ошибки, код приоритета уже молсет быть назначен Управлением Пробле-малт. Однако Управление Изменениями назначает окончательный код приоритета гюсле рассмотрения других обрабатываемых Запросов.
•Управление Изменениями нрисваивает категорию, исходя из стеиени воздействия и требуемых ресурсов. Эта классификация определяет дальнсСипие проиедуры обработки Запроса и обозначает важность измеиепия.
Определение приоритета
Пример системы кодирования и])иоритетов:
•Низкий приоритет - изменение желательно, ио его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
•Обычный приоритет - пет особой срочности и высокой степепи воздействия, но изменение не следует откладывать. На coBeniamni Консультативного комитета (CAB) при выделении ])есу])сов изменению присваивается обычный приоритет.
•Высокий приоритет - изме}1ение касается серьезной оигибки, затрагивающей ряд пользователей, или новой нетипичной оншбки, затрагиваюн1ей болыную группу пользователей, или связано с д])угнмн срочными вопросами. Такому измепентгю на ближап1пем совещапии CAB присваивается высокий приоритет.
•Наивыспннт приоритет - Запрос на Изменения (RFC) касается проблемы, серьезно влияюи1сй на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, повой функциональности для целен бизнеса), срочного изменения законодате;П)СГва или быстрых небольших изменшитй, не терняпщх отсрочки. Изменения с laKHM прио])итетом классис1)нцируются как «срочные». Для срочных изменений обычные процедуры не используются, так как необходи-тле ресурсы п1)едосгавляются незамедлительно. Может потребоваться проведение срочного совещания Консультативного кол«итета (CAB) или Руководящего комитета ИР. Специально для зтих целей в компании должен бьггь сформирован Комитет но срочным изменениям (САВ/ЕС)- с полномочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.
Эти коды могут быть нредставленны в цифрах, например: низкий приоритет ~ 1 / наивысший приоритет = 4.
Определение категор1пт
Категории определяются в рамках Процесса Управления Изменениями, в случае необходимости с участием Консультативного комитета (CAB), который определяет степень воздействия изменения и требования, пред1>являемые им к ИТ-организации (в первую очередь, выдслшпте ресурсов). Примеры категорий:
•Низкая степень воздействия - измене»П1е, гребуюпгее вьиюлнепия небольшого объема работ. Руководитель Процесса Управления Изменениями может авторнзова1ь эти измене1Н1Я без П1)ивлече-иия Консультативного комитета (CAB).
•Существенная степень воздействия - изменопю, требующее значительных усилий и оказьшаю-niee существенное воздействие на ИТ-услуги. Эти изменения обсуждаются па совещании Консультативного комитета (CAB) для определения необходимых усилий (ресурсов и др.) и потенциального воздействия. Перед совещанием членам Консультативного комитета (СА13) \\, возможно, спегпалистам и разработчикам направляется соответствующая документания.
•Павысшая степень воздействия - измените, требуюи1ее значительных усилий. Руководителю Процесса ггеобходимо предварительно получить авторизацию иа выполиоше изменения от руководства ИТ или Руководящего ко.мигета ИТ, после чего изменение и]}едс1авляется иа рассмотрение Консультативного комитета (CAB).
Эти коды могут быть представлсн1П)1 в цифрах, например: низкая степень = 1 / высшая степень = 3.
Quick fix
" IT Steering Committee Emersency СотглКее.
Тогл-агс) Schedule of Change - f SC. Back-out.
Болынпнство изменений относятся к двум первым категориям. В добавление к классификации должпы быть также определены группы, участвующие в работе над техническим рсшс1птем, и услуги, затрагиваемые изменением.
7.4.4. Планирование
В рамках процесса осуществляется планпрова1Гие изменений па основе графика, называемого Согласованным планом изменен1Н1 (FSC). План FSC содержит подробную информацию обо всех утвержденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомен-дащп! но планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, затраты, различные аспекты задействованных услуг, а также мненне заказчиков. Консультативный комитет (CAB) играет po.iib консультативного органа. В целом Управление Изменениями имеет делеги-рован1н,1е полномочия, т. к. оно действует от лица руководства ИТ. Возможно, что изменення наивысшей категории необходимо утверждать руководством ИТ до их представления Ко1гсулг1тативному комитету (CAB). Утверждение изменения имеет несколько аспектов: .♦ Финансовое одобрение - анализ затрат/выгод и выделение бюджета.
•Техническое одобрение - оце1п<а необходимости, возможности проведения изменения и его степени во.здействия.
•Бизнес-одобрение - одобре1гие по;п>зователями требуемой функциональности приложения и степени воздействия измепе}1ия.
Для целей эффективного планирования Унравление Изменениями должно взаимодействовать с проектным офисом и другими полра:аделениямн компании, затпхмаюпщ.мнся разработкой и В1гедре-ние.\1 изменений. Кроме того, достаточное внимание долж1го уделяться своевременному осведомле-Н1П0 пользователей о планировании изменений, возможно, в виде рассылки Согласованного плана изменеинй (FSC).
Политика проведения изменений
Изменения по разным Запросам можно объединять в одном релизе. В :том случае при 1юудачпой реализации будет достаточно одного возврата к исходному состоянию Такой групповой релиз должен рассматриваться как од1ю изменение, даке если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функщюнмьных ;1адач, необходимых для бизнеса. Они могут охватглвать аппаратные и программные средства, н их внедрение осуп1ествляется Процессом Управления Релизами. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-органи-защно и заказчиков (см. таюке «Управление Релизами»). Цель политики - оградить пользователя от ненужного беспокойства («перекапывапие дороги каждую неделю»).
После консультаций с участву)оин1Ми ИТ-подра.зделеииями, Консультативный комитет (CAB) может определить регулярные периодтл времени («окна») для проведения изменетигй, когда степень воздействия на ИТ-сервисы будет минимальной. Подходяии1ми периодалн! могут бьгть выходные дни или нерабочее время. Таким же образом мог}т быть определены периоды, когда допускается ми-1П1мум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все полра.зделепня пользователей делают отчеты.
Совепаиия Консультативного комитета (CAB)
Инфор.мация о планировании изменениий должна распространяться заранее до совещахшя CAB. Соответствуюпщя документация и информация о пунктах повестки дня также должны рассылаться до совси1ания.