Для описания бизнеса отлично подходит латинское выражение Non progredi est regredi. Если ты не прогрессируешь, то регрессируешь. Оставаться на одних и тех же позициях означает откатываться назад. Чтобы двигаться вперед, нужны постоянные изменения. А поскольку бизнес прочно завязан на информационных технологиях, менять придется и IT-инфраструктуру.

Зачем управлять изменениями?

Для начала посмотрим, какими вообще бывают изменения в IT-инфраструктуре. Самая простая классификация называет 3 основных типа:

• стандартные – планируются наперед и внедряются по типовой схеме (например, установка нового оборудования);
• нормальные – чаще всего связаны с внедрением новых IT-решений и вносятся в ходе работы над проектом (например, изменения в архитектуре системы после перехода в мобайл);
• экстренные – вынужденные изменения, связанные со сбоями и критическими ошибками в системе.

Многие компании уверены, что если и нужно управлять какими-то изменениями, то разве что экстренными. Но это не так. Любое изменение в IT-инфраструктуре – это риск. А что, если оно нарушит работу IT-сервисов и связанных с ними бизнес-процессов? Или окажется неэффективным и снизит отдачу от IT?

Чтобы минимизировать все эти и многие другие риски, изменениями нужно управлять. И лучше всего делать это по хорошо продуманному плану.

Основные этапы управления изменениями

Регистрация

Чтобы изменениями можно было управлять, сначала их нужно регистрировать. Например, фиксировать запросы на изменения. Чтобы упростить себе задачу, можно включить перечень типовых запросов в каталог IT-сервисов и потом просто выбирать их из списка.

Анализ

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

Анализировать запросы на изменения гораздо проще, имея постоянно обновляемую базу конфигураций (CMDB). В ней должна быть информация обо всех элементах инфраструктуры и связях между ними. Тогда при оценке запроса можно будет быстро узнать, как изменение отобразится на работе системы.

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

Если анализ дал добро на изменение, можно планировать, как именно его внедрить. В крупных компаниях за планирование отвечает Комитет по изменениям, в меньших его функцию может выполнять руководитель IT-отдела.

Основная цель этого этапа – расписать процесс внедрения изменения и распределить работу (и ответственность) по внедрению между сотрудниками.

Внедрение и оценка

Само внедрение проводят технические специалисты, а Комитет по изменениям (или сотрудник, выполняющий его функции) создает отчет, в котором анализирует:

• была ли достигнута цель изменения;
• не была ли нарушена работа IT-системы;
• как изменение повлияло на бизнес-процессы компании.

Документирование

Этот сугубо бюрократический этап является неотъемлемой частью управления изменениями и преследует 2 цели:

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

Как видите, управление изменениями в IT-инфраструктуре – процесс длительный и трудоемкий. Но этот тот случай, когда игра стоит свеч, ведь в итоге вы:

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

Как же организовать процесс управления изменений? В мировой IT-практике для этого разработаны целые методологии. Самые известные из них – ITIL и ASAP. Кроме того, вы можете применять отдельные инструменты для управления изменениями (например, Atlassian Jira), использовать собственные наработки или подгонять чужие методики под себя. А если вам нужна помощь, вы знаете, куда обращаться.