Отношения процесса управления Изменениями с другими процессами.

a. Управление Инцидентами

Процесс Управления Инцидентами имеет двухстороннюю связь с Процессом Управления Изменениями.

С одной стороны, Управление Изменениями обрабатывает направляемые Управлением Инцидентами RFC для разрешения инцидента (разрешает временные решения) или запрашиваемые Управлением Проблемами изменения, устраняющие причину инцидента.

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

 

b. Управление Конфигурациями

Изменения регистрируются под контролем Процесса Управления Конфигурациями, анализ воздействия изменений также проводится с участием Процесса Управления Конфигурациями.

Управление Конфигурациями определяет зависимость между Конфигурационной Единицей CI (вовлеченной в проводимое изменение) и другими CI, чтобы определить, на какие другие элементы будет воздействовать это изменение.

c. Управление Проблемами

Взаимосвязь между Процессами Управления Изменениями и Управления Проблемами во многом похожа на такую же связь между Процессами Управления Изменениями и Управления Инцидентами.

d. Управление Релизами

Изменения часто приводят к необходимости разработки и распространения новых приложений или установке технической инфраструктуры!. Это осуществляется с помощью Процесса Управления Релизами. Контроль над распространением новых версий осуществляется Процессом Управления Изменениями.

e. Управление Уровнем Сервиса

Процесс Управления Уровнем Сервиса вовлечен в определение степени воздействия изменений на предоставление услуг и бизнес-процессы. В зависимости от ситуации в Консультативном комитете (CAB) могут участвовать представители Процесса Управления Уровнем Сервиса. Если изменение оказывает значительное воздействие или связано с высоким риском, ' его внедрение и сроки должны всегда обсуждаться с заказчиком.

f. Управление Доступностью

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

 

g. Управление Мощностями

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

h. Управление Непрерывностью ИТ-услуг

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

3. 3. Виды деятельности в рамках Процесса Управления Изменениями

Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:

■ Прием в обработку — предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.

■ Классификация — сортировка Запросов на Изменения по категориям и приоритету.

■ Планирование — объединение изменений, планирование их проведения и планирование необходимых ресурсов.

■ Координация — координирование компоновки, испытаний и проведения изменений.

■ Оценка — оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).

 

a. Регистрация

Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.

Откуда исходят Запросы на Изменения (RFC)?

Можно определить несколько источников Запросов на Изменения (RFC), например:

■ Управление Проблемами — предлагает решения для исключения долговременных ошибок с целью стабилизации предоставления услуг.

■ Заказчики — могут запросить больший, меньший Уровень Сервиса или другие услуги. Эти запросы могут подаваться прямо как Запрос на Изменения или направляться через Управление Уровнем Сервиса (SLM) или через Управление Отношениями с заказчиками ИТ (IT CRM).

■ Политика компании — тактические и стратегические процессы! из области Предоставления услуг ( Service Delivery Set) и Указания руководства (Managers Set) могут привести к направлению Запросов на Изменение Услуг. Например, Управление Уровнем Услуг, Управление Доступностью Управление Мощностями составляют ежегодные планы улучшения услуг, которые позднее могут быть поданы как Запросы на Изменения (RFC).

■ Законодательство — если возникают ограничения, регламентирующие бизнес- деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.

■ Поставщики — поставщики выпускают новые версии и модификации своих продуктов и сообщают об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определенные версии или что не могут гарантировать производительность версии (например, из-за «Ошибки тысячелетия» — Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).

■ Проекты — проект часто вызывает ряд изменений.

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

■ категория (в какой области будут изменения);

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

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

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

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

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

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

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

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

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

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

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

■ Приоритет показывает, насколько важным является данный Запрос по сравнению с другими. Если изменение касается исправления известной ошибки, кодприоритета уже может быть назначен

Управлением Проблемами. Однако Управление Изменениями назначает окончательный код приоритета после рассмотрения других обрабатываемых Запросов.

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

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

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

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

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

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

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

d. Планирование

В рамках процесса осуществляется планирование изменений на основе графика, называемого Согласованным планом изменений (FSC). План FSC содержит подробную информацию обо всех утвержденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомендации по планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, затраты, различные аспекты задействованных услуг, а также мнение заказчиков. Утверждение изменения имеет несколько аспектов:

■ Финансовое одобрение — анализ затрат/выгод и выделение бюджета.

■ Техническое одобрение — возможности проведения изменения.

■ Бизнес-одобрение — одобрение пользователями требуемой функциональности приложения.

Для целей эффективного планирования Управление Изменениями должно взаимодействовать с проектным офисом и другими подразделениями компании, занимающимися разработкой и внедрением изменений. Кроме того, достаточное внимание должно уделяться своевременному осведомлению пользователей о планировании изменений, возможно, в виде рассылки Согласованного плана изменений (FSC).

Политика проведения изменений

Изменения по разным Запросам можно объединять (МОСЭНЕРГО!!) в одном релизе. В этом случае при неудачной реализации будет достаточно одного возврата к исходному состоянию. Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функциональных задач, необходимых для бизнеса. Цель политики — оградить пользователя от ненужного беспокойства («перекапывание дороги каждую неделю»).

После консультаций с участвующими ИТ-подразделениями, Консультативный комитет (CAB) может определить регулярные периоды времени (««окна»») для проведения изменений, когда степень воздействия на ИТ-сервисы будет минимальной. Подходящими периодами могут быть выходные дни или нерабоче время. Таким же образом могут быть определены периоды, когда допускается минимум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все подразделения пользователей делают отчеты.

e. Координация

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

i. Подготовка изменения

Не все изменения проходят отдельную фазу компоновки. Например, стандартные изменения, такие как перемещение персональных компьютеров, могут планироваться и осуществляться незамедлительно.

Компоновка может включать:

создание новой версии программы с

· новой документацией, руководствами,

· инсталляционными процедурами,

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

· аппаратными изменениями.

 

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

ii. Тестирование

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

· приемо­сдаточные испытания для пользователей, при которых представители бизнес-подразделений (обычно заказчики изменения) проверяют его функциональные характеристики, и

· операционные (эксплуатационные) испытания, при которых независимое тестирование проводят те, кто должен поддерживать и обслуживать новую инфраструктуру. Сюда включаются также отделы технической поддержки и Служба Service Desk. Они проверяют соответствующую документацию, процедуры резервного восстановления данных (back-up) и т. д.

iii. Внедрение

Управление Изменениями гарантирует, что проводимое изменение является запланированым изменением. Должен существовать точный план информирования всех вовлеченных сотрудников о проведении изменения (коммуникационный план), например, пользователей, Службы Service Desk, группы администрирования сетей и т. п.

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

f. Оценка

Необходимо давать оценку произведенным изменениям, за возможным исключением стандартных изменений. При необходимости Консультативный комитет (CAB) принимает решение о проведении последующих дополнительных мероприятий. Должны быть рассмотрены следующие вопросы:

■ Привело ли изменение к достижению намеченной цели?

■ Удовлетворены ли пользователи результатом?

■ Возникали ли какие-либо побочные эффекты?

■ Были ли превышены расчеты по затратам и ресурсам?

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

4. 4. Показатели эффективности и проблемы процесса управления изменениями

a. Показатели эффективности

определяют, насколько успешно Процесс Управления Изменениями осуществляет эффективную и рациональну обработку изменений при минимальном отрицательном воздействии на согласованный Уровень Услуг. Эти показатели могут быть следующими:

■ количество изменений, завершенных за единицу времени, по категориям;

■ скорость проведения изменений;

■ количество отклоненных изменений;

■ количество инцидентов, вызванных изменениями;

■ количество возвратов к исходному состоянию, связанных с изменениями;

■ затраты на проведенные изменения;

■ количество изменений, осуществленных в рамках расчетных затрат ресурсов и времени.

b. Проблемы

При внедрении Процесса Управления Изменениями возможно появление следующих проблем:

Работа без средств автоматизации слишком трудоемка, она будет создавать много проблем.

■ Возможно сопротивление всеохватывающему Процессу Управления Изменениями, осуществляющему мониторинг всех аспектов ИТ-инфраструктуры..

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