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

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

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

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

Приоритеты изменений могут быть следующими:

1. Низкий — изменение желательно, но его внедрение может быть отложено.

2. Обычный — нет срочности, но откладывать нельзя.

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

4. Наивысший — необходимо наиболее быстрым образом провести изменение, поскольку оно влияет на бизнес в целом.

Число и описание приоритетов в каждой компании могут быть различными, но на выбор приоритета всегда должны влиять категории изменений с точки зрения масштабности, которые могут быть, в частности, следующими:

· Крупные изменения (например, реструктуризация головного офиса или внедрение ERP системы).

· Средние изменения (например, внедрение процесса бюджетирования или системы управления документами).

· Мелкие изменения (внедрение процесса обучения).

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

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

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

2. Техническое одобрение: оценка необходимости, возможности проведения изменения и степени его воздействия.

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

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

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

В небольших компаниях достаточно одного комитета, в более крупных возможно несколько. Наличие комитетов позволяет рассмотреть запросы и планы изменений представителям разных служб, что, таким образом, снижает вероятность риска неудачного или невостребованного изменения. Кроме того, комитеты обеспечивают взаимодействие между IT и бизнесом для определения их согласованной точки зрения на изменение. Для выполнения этих задач в комитет следует включать людей, знакомых с бизнес-процессами предприятия и его информационными системами. После утверждения запроса на изменение или графика будущих изменений (FSC — Forward Schedule of Change) — документа, описывающего порядок изменений и задействованные ресурсы, на специально формируемом комитете проектные группы могут начинать внедрять утвержденные изменения в деятельность компании.

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

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

При этом основными задачами владельца процесса управления изменениями являются:

· руководство процессом;

· фильтрация и классификация запросов на изменения;

· принятие решений для небольших запросов на изменения;

· взаимодействие с заказчиком изменений;

· планирование изменений;

· координация изменений;

· анализ успешности изменений.

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

На основе данных моделей очень просто получить регламент процесса и ролевые инструкции его участников.