Причем сходство между «классическим» процессом управления изменениями ITIL и подготовкой и внесением изменений в прикладное ПО очень большое:
· одни и те же участники (service manager, менеджеры систем и эксперты по прикладному ПО, представители заказчика, финансовые службы);
· похожие потенциальные риски (недоступность системы, потеря данных) и сходные пути борьбы с ними (тестирование, резервное копирование, планирование отката);
· потенциальный переход в формат проектной деятельности;
· часто — одни и те же источники финансирования;
· неизбежный перерыв в предоставлении ИТ-услуг при реализации и необходимость его оптимально спланировать.
Некоторые случаи вообще сложно классифицировать. Например, если речь идет о доработке системы обмена данными в распределенной прикладной системе. С одной стороны, это доработка прикладного ПО, а с другой — изменяются функции, не видимые конечным потребителям, и относящиеся скорее к платформе, нежели к приложению.
Если же говорить об этапе реализации, то с точки зрения конечных потребителей нет никакой разницы, из-за чего произошел плановый перерыв в предоставлении услуги: производится замена аппаратной части системы, отключили на профилактику телекоммуникации или устанавливают новый релиз ПО.
Предлагаемая модель
Возможный вариант модели, по которой можно отстроить управление изменениями, выглядит следующим образом (см. рис.). Процесс разделяется на две основные фазы:
· планирование и подготовка изменения;
· реализация изменения.
|  |
Рис. Модель построения управления изменениями
На этапе планирования и подготовки изменения, связанные с ИТ-инфраструктурой, производятся в формате CAB. При этом, поскольку они не затрагивают бизнес-приложений, вполне достаточно наличия CAB, состоящего только из сотрудников ИТ-служб. Для создания такого органа обычно вполне достаточно полномочий CIO (ИТ-директора).
А вот для управления изменениями в приложениях используются нормативно-методические документы, описывающие процедуры эксплуатации информационных систем. Такие документы разрабатываются и утверждаются при приемке информационной системы в промышленную эксплуатацию. В регламент должен быть включен отдельный раздел, описывающий, как инициируется и авторизуется запрос на модернизацию прикладной системы, как определяются источники финансирования, как осуществляется тестирование и т.п. А так как для каждой информационной системы существует отдельный регламент, то в нем можно учесть все индивидуальные особенности системы — архитектуру, особенности платформы, список заказчиков, зоны распространения, планы развития.
На этапе реализации изменения разница между инфраструктурными изменениями и модернизацией прикладных систем практически отсутствует. Так, в обоих случаях вам потребуется выполнить следующие действия:
· сформировать список ИТ-услуг, в предоставлении которых произойдет (или может произойти) перерыв, составить соответствующий график и согласовать его с заказчиками ИТ-услуг;
· определить список сотрудников, которых надо будет оповестить, и выполнить необходимые оповещения;
· сформировать группу сотрудников (включая внешних подрядчиков), которая будет выполнять само изменение;
· сформировать дежурную аварийную группу, которая подключится к работам в случае необходимости произвести откат (если такая группа предусмотрена планом отката);
· после завершения работ провести анализ результатов изменения.
Иными словами, на этапе реализации все изменения могут быть осуществлены в едином формате, по единому алгоритму и на основании единого комплекта регламентирующих документов.