назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [ 31 ] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


31

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

Вот 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ания.

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [ 31 ] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]