Управление изменениями - управление стабильностью

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

Абсурдный пример. В один прекрасный весенний вечер инженер Сергей Юрьевич, проживающий на окраине Южного Бутово, приходит к выводу, что для того, чтобы его телевизор лучше принимал телеканалы, необходимо срочно усовершенствовать Останкинскую телебашню
, увеличив ее высоту всего на 15 метров...

Естественно, инициативу Сергея Юрьевича реализовать будет практически невозможно, поскольку Останкинская телебашня находится под пристальным контролем глобального процесса управления изменениями, который регулируется законодательством, множеством стандартов, технических регламентов, СНиП и прочей бюрократической документацией, а также бесконечным числом чиновников, инспекторов и согласований. Даже если инициатива Сергея Юрьевича пройдет первые инстанции, и его предложение не будет с позором отклонено, придется составить огромную кучу документов, пройти миллиарды согласований... Скорее всего Сергей Юрьевич решит, что намного проще жить с плохо работающим ТВ или переехать поближе к Останкино, нежели пройти через эту бюрократическую машину для реализации такого незначительного изменения... Этот пример можно продолжить, представив, что южно-бутовский проект будет успешно согласован, начнется разработка и согласование проектной документации, составление смет, откаты заключение контрактов...

А теперь в ИТ
Для того, чтобы такие инициаторы, как Сергей Юрьевич своими инициативами (запросами на изменение) не смогли нанести вред ИТ-инфраструктуре, необходимо чтобы в ИТ-подразделении функционировал процесс управления изменениями, который обеспечивает:

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

Сформулируем цель процесса управления изменениями:

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

Барьер 1: Прием и регистрация запросов на изменение
Все запросы на изменение должны подаваться в установленной форме. Если запрос подан неверно, он должен быть направлен обратно инициатору на переоформление.

 

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

Запрос на изменение, информация об инициаторе, о времени подачи запроса на изменение должны быть зарегистрированы.

Барьер 2: Оценка и авторизация изменений
Запрос на изменение должен быть оценен. Как минимум, необходимо оценить:

• реальную необходимость запрашиваемого изменения
• возможность и стоимость его реализации
• наличие необходимых ресурсов (деньги, люди, время, технические средства, административные ресурсы и проч.)
• самое главное! влияние изменения на инфраструктуру и риски, связанные с изменением

На этой стадии запрос на изменение может быть отклонен.

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

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

Оценка и авторизация изменения может проводиться коллективно. Для этого может быть организован коллегиальный орган - комитет по изменениям. Комитетов по изменениям может быть столько, сколько захотите. Сами определите, для какие изменения должны проходить через комитеты, а какие - нет. Заседания и решения комитета должны протоколироваться.

Барьер 3: Планирование изменения
Изменения должны планироваться. Необходимо контролировать, чтобы были разработаны и согласованы планы разработки, тестирования и внедрения изменений, а также обязательно планы возврата в первоначальное состояние. В зависимости от конкретного изменения возможно потребуются и другие планы.

На этом этапе изменение может быть:

• отклонено
• перенесено на неопределенный срок
• перенесено на более поздний срок, поскольку оно может конфликтовать с другими проводимыми работами, изменениями, проектами, графиками отпусков и т.п.

Барьер 4: Контроль реализации
Необходимо контролировать, чтобы изменение было реализовано, протестировано и внедрено согласно плану, не отступая от него ни на шаг.

В ходе реализации изменения могут всплыть дополнительные детали, возникнуть необходимость перепланирования... Это неминуемо должно привести к повторной оценке и авторизации изменения, и к его повторному планированию (снова барьеры 2 и 3). Или же изменение может быть отклонено и закрыто.

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

В ходе внедрения может потребоваться реализация плана возврата в исходное состояние. Этот факт, а также результаты возврата в исходное состояние также должны быть зарегистрированы.

Барьер 5: Оценка и закрытие изменения

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

• достигло ли изменение своей цели
• насколько изменение стабильно
• не оказало ли изменение негативное влияние на отдельные системы, ИТ-инфраструктуру и на пользователей
• не нарушены ли политики и стандарты безопасности

Программа приемо-сдаточных испытаний должна быть спланирована и согласована. Результаты испытаний должны быть зарегистрированы (отчеты, акты и т.п.).

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

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

• реализация плана возврата в исходное состояние
• регистрация проблемы, ее анализ, поиск решения, регистрация и обработка нового запроса на изменение

Подведем итоги

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

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

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

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

Не стоит поддаваться соблазну и включать в охват процесса все изменения. Например, изменения в конфигурации рабочей станции нанесет серьезный урон бизнесу, такие изменения не требуют детального анализа и планирования. Включайте в охват процесса действительно критичные и сложные корпоративные системы, доступность которых обеспечивает функционирование предприятия в целом (например АБС, ERP, системы документооборота, финансово-учетные системы, почтовая система и т.п.).