На всех этапах проекта в него могут быть внесены изменения. Цель процесса управления изменениями — обеспечение эффективного проведения изменений и минимизация последствий их воздействия на проектную деятельность компании. Поэтому внесение изменений в структуру проектов на всех стадиях их выполнения происходит в соответствии со стандартизованными процедурами.
Общая схема проведения изменений начинается с регистрации запроса на изменения — Request for Change (RFC) . Ему присваивается идентификационный номер, и в дальнейшем осуществляется классификация запроса, то есть фактически определяется сценарий, по которому данный запрос будет обрабатываться. Многие компании считают необходимым следовать одному сценарию процесса для всех изменений.
В общем случае необходимо использовать различные сценарии процесса управления изменениями. Точнее, может быть один сценарий для незначительных изменений с малой степенью риска неучтенных ошибок, а также более совершенные сценарии в случае существенных и масштабных изменений. Например, одна и та же компания может поддерживать сценарии для изменений и с малой, и со средней, и с повышенной степенью риска. Такой подход обеспечит гибкость и своевременность процесса, а также приведет к снижению себестоимости работ по его реализации.
Чтобы сократить срок обработки изменений, типовые (с точки зрения их обработки) выделяются в отдельные группы стандартных изменений, которые обрабатываются по упрощенным сценариям. Необходимо предусмотреть несколько сценариев обработки запроса на изменения в зависимости от их срочности и масштабности, что позволит направлять поток стандартных изменений по наиболее короткому сценарию, тогда как масштабные изменения потребуют всех необходимых согласований и обоснований.
Проведение всех действий по согласованию изменений требует знаний и квалификации в различных сферах деятельности, а также высоких полномочий для принятия решения.
Для обеспечения вышеуказанных условий создается группа согласования и подтверждения изменений (Change Advisory Board ), которая является неотъемлемой частью всего процесса и включает в себя представителей различных подразделений с обязательным участием руководства финансовых подразделений и руководства компании (за которым остается право окончательного решения).
В небольших компаниях достаточно одной такой группы, в более крупных возможно существование нескольких групп, что позволяет рассмотреть запросы и планы изменений представителями разных служб, что впоследствии снижает вероятности рисков неудачных или невостребованных изменений. Кроме того, группы обеспечивают взаимодействие между IT и бизнес подразделениями для определения их согласованной точки зрения на изменение. Для выполнения этих задач в группы следует включать людей, знакомых с бизнес-процессами предприятия и его информационными системами. После утверждения запроса на изменение или графика будущих изменений (FSC — Forward Schedule of Change ) — документа, описывающего порядок изменений и задействованные ресурсы, на специально формируемом совещании проектные группы могут начинать внедрять утвержденные изменения в деятельность компании.
Помимо группы согласования и подтверждения изменений необходимо определить владельца процесса, который должен принимать решение в случае небольших изменений и анализировать успешность в каждом конкретном случае. В крупных организациях возможно разделение полномочий владельца процесса управления изменениями по областям, в которых они проводятся, поскольку для анализа изменений необходимо быть специалистом в той или иной конкретной области. Для сложных систем весьма вероятна профессиональная специализация, и тогда единственным путем к реальной оценке влияния изменений является совместная работа в группах тех специалистов, которые поддерживает систему, с теми, кто ее использует.
Если попытаться охватить цели данного процесса одной фразой, то прежде всего это обеспечение применения стандартизованных процедур и методов для эффективной и быстрой обработки всех изменений с учетом снижения негативного влияния изменений на бизнес и качество IT-сервиса. Для его описания в графическом виде используются модели описания процессов, в рамках которых отражаются как минимум логика процесса, бизнес-роли, документы и информационные системы.
На основе данных моделей очень просто получить регламент процесса и ролевые инструкции его участников.
Основное преимущество в управлении изменениями как процессом заключается в возможности анализа ключевых показателей результативности (КПР). Любой способ контроля, в том числе и процесс управления изменениями, не может дать абсолютной гарантии отслеживания всех ошибок. Конечно, процесс управления изменениями должен быть внедрен таким образом, чтобы риски сократились до приемлемого уровня, но попытка внедрить процесс с целью полного избавления от рисков приведет к медленному дорогостоящему бюрократизированному процессу, причем ожидаемый результат не может быть гарантирован.
Такой анализ статистики процесса управления изменениями нацелен на выявление любых ошибок, которые по той или иной причине были пропущены и привели к неудаче введенных изменений.
Использование процессного подхода, ITIL и, например, референтных моделей ARIS IDS Reference Model позволяет в большинстве случаев избежать вышеобозначенных проблем и разработать эффективный процесс управления изменениями.