Управление изменениями

Записаться

Управление изменениями при развертывании услуг

1. Место управления изменениями в ITIL 2011

В ITIL 2011 (Information Technology Infrastructure Library — библиотека инфраструктуры ИТ) картина управления изменениями выглядит неоднозначно. В процессах стратегии услуг (Service Strategy), проектирования услуг (Service Design) и разработки услуг отдельного процесса управления изменениями (Change Management) нет. Он появляется позже — при развертывании услуг (Service Transition).

2. Почему изменения появляются при развертывании

При развертывании услуга впервые попадает в рабочую среду. Появляются живые пользователи и заказчики. Они начинают работать с услугой, выдвигают новые требования, которых не замечали в среде разработчиков. Поэтому сразу возникают запросы на изменения (Request for Change, RFC) с разных сторон.

3. Опытная эксплуатация и сбор изменений

Особенно важен короткий этап опытной эксплуатации. Он специально существует для сбора таких изменений. Также меняются SLA (Service Level Agreement — соглашение об уровне услуг), стратегии, создаются комитеты по изменениям.

4. Корпоративные регламенты и анализ процессов

При этом не всегда понятно, где находится корпоративный процесс управления изменениями, который должен объединять все эти действия и выполнять их с единых позиций. Даже если есть корпоративные регламенты обработки, согласования и оценки изменений, все процессы SLM (Service Level Management — управление уровнем услуг), связанные с управлением изменениями, нужно периодически анализировать — как минимум ежегодно.

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

Краткие итоги

Управление изменениями становится критичным не тогда, когда услуга только проектируется, а тогда, когда она входит в соприкосновение с реальной эксплуатацией. До этого момента требования кажутся относительно стабильными, а решения — контролируемыми внутри проектной или разработочной среды. Однако рабочая среда разрушает эту иллюзию: пользователи, заказчики и внешние условия формируют поток новых ожиданий. Поэтому изменения перестают быть исключением и превращаются в постоянный фон. Опытная эксплуатация выполняет роль управляемого механизма обратной связи: она позволяет не потерять первые сигналы и превратить их в оформленные запросы. Практическая ценность такого подхода в том, что компания получает возможность отличать локальные пожелания от системных изменений, влияющих на SLA, стратегию и архитектуру услуг. Но сбор изменений сам по себе недостаточен. Если нет единого корпоративного процесса, решения распадаются на отдельные инициативы, комитеты и регламенты. Тогда возникают конфликты полномочий: неясно, кто оценивает, согласует и приоритизирует изменения, как они связаны с управлением уровнем услуг и стратегическими целями. Регулярный анализ процессов управления изменениями, включая ежегодный пересмотр, нужен не для формальности, а для проверки актуальности. Любой процесс устаревает, если меняются услуги, SLA, организационная структура или ожидания заказчиков. Если процессы находятся под управлением общего процесса изменений, важно обеспечить прозрачные правила. Если применяется особый режим, нужно явно определить его границы и взаимодействие с корпоративным контуром. Иначе возникает разрыв между локальной практикой и общим управлением. Практический вывод: управление изменениями следует выстраивать как связующий контур между развертыванием, эксплуатацией, уровнем услуг и стратегией. Оно должно опираться на обратную связь, иметь четкие полномочия, регулярно пересматриваться и не подменяться набором разрозненных регламентов. Тогда изменения становятся управляемым ресурсом развития, а не источником хаоса.