S – Rb, Sn 14 страница

Для ведения намеченного графика изменений может использоваться календарь в программе Outlook или Exchange корпорации Microsoft или же в другой программе электронной почты. Программа Outlook может использоваться для создания назначений в графике изменений, после чего могут быть определены права доступа, позволяющие большинству пользователей читать календарь, но лишь ограниченному количеству пользователей (из группы менеджеров изменений) обновлять или корректировать содержимое этого календаря.

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

Назначение владельца изменения

После того как изменение будет запланировано, менеджер изменений должен определить и назначить владельца изменения, который должен контролировать прохождение изменения через процесс разработки и реализации, а также передачу изменения в производственную среду. Владельцем изменения может также стать инициатор изменения. Владельцем изменения может стать лицо, выполнявшее ранее роль технического эксперта в жизненном цикле этого изменения, если инициатор не владеет всей информацией о влиянии на ИТ среду выдвинутого им изменения. Еще один вариант состоит в том, что владельцем изменения может стать вновь назначенное лицо, которое может оказаться экспертом в предметной области, относящейся к RFC, и поэтому обладает техническими возможностями, необходимыми для управления процессом осуществления изменения от начала и до конца. В случае небольших изменений владелец изменения может лично осуществить все изменение. А если изменение является более крупным, то владелец изменения действует в роли руководителя проекта при осуществлении фаз разработки и проверки, а также наблюдает за реализацией изменения. В составе критериев, используемых для назначения подходящего владельца изменения для конкретного RFC, должны применяться приоритет и категория изменения. Например, чтобы иметь возможность реализовать крупное изменение, имеющее высокий приоритет, от выбранного владельца изменения может потребоваться овладение определенным уровнем навыков управления проектом или наличие высокой должности в организации.

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

Методология разработки изменений

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

Стандартные изменения представляют собой повторно осуществляемые изменения, связанные с небольшим риском, поэтому они не проходят через фазу разработки. Для изменений других типов выбор методологии, используемой в стадии разработки изменения, является открытым и существует много подобных методологий. При этом могут осуществляться либо простые шаги методологии разработки изменения, либо применяться процесс разработки, используемый внутри самой организации. Кроме того, для структуризации разработки изменения может использоваться модель процессов из подхода к решениям Microsoft (Microsoft Solutions Framework — MSF), которая показана на рис. 8. Более подробную информацию об MSF можно найти по адресу http://www.microsoft.com/MSF.

Рис. 8. Модель процесса MSF

Выбранная методология разработки должна быть достаточно гибкой для того, чтобы с ее помощью можно было обеспечить проведение работ по разработке любого объема. Например, неформально можно отметить, что с использованием MSF можно даже осуществить такую работу, как внесение поправок в документ с описанием процесса, который проходит через процедуры управления изменениями. В этом случае фазы прогнозирования и планирования являются очень короткими и не требуют участия большого количества людей. А для фазы разработки не требуется сложный план проекта, поскольку исправление документа сводится в основном к работе над текстом и может потребовать привлечения только одного или двух человек. С другой стороны, сложное изменение, такое как обновление операционных систем всех настроенных компьютеров с переходом на Microsoft Windows® XP, — это очень большой проект, предусматривающий участие большого количества людей во всей организации, требующий проведения продолжительных этапов планирования и разработки и оцениваемый крупными денежными затратами. В подобных случаях необходимо придерживаться формальной методологии разработки, для того чтобы менеджер изменений мог отслеживать ход работ по внесению изменений и координировать любые сдвиги в запланированных сроках развертывания с другими изменениями.

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

Дата добавления: 2015-01-03