«Когда ты пытаешься внедрить управление изменениями в ИТ-инфраструктуре, первое, что ты слышишь — «нужен процесс согласования». Ты его создаёшь, а потом сталкиваешься с тем, что сам этот процесс требует изменений. И вот ты уже в тупике: как согласовать изменения в процессе согласования, если для этого нужен… тот самый процесс? Это не бюрократический абсурд, а фундаментальная проблема любой системы, которая хочет быть устойчивой к самой себе.»
Почему процесс согласования изменений не может быть статичным
Любой процесс управления изменениями (ITSM, Change Management) создаётся для конкретного технологического ландшафта, уровня зрелости команды и требований регуляторов. Время идёт: появляются новые технологии, меняются бизнес-процессы, ужесточаются требования ФСТЭК по 152-ФЗ. Жёсткий, неизменный процесс согласования быстро превращается в тормоз, мешающий адаптации всей ИТ-системы к новым условиям.
Представь, что процесс требует обязательного согласования с руководителем отдела безопасности для любых изменений в сетевой инфраструктуре. Компания переходит на микросервисную архитектуру, где деплои происходят десятки раз в день. Старый процесс ломает цикл разработки. Его нужно менять — делегировать часть полномочий, вводить автоматизированные проверки. Но как это сделать, если любое изменение процесса должно пройти через… длительное согласование со всеми теми же сторонами? Возникает парадокс: система не может эволюционировать, потому что заблокирована собственными правилами.
Метапроцесс: управление правилами игры
Решение — создание метапроцесса, или процесса управления процессом согласования изменений. Это не «согласование согласования» ради бюрократии. Это выделение отдельного, более высокоуровневого контура управления, который отвечает за жизненный цикл самих рабочих процедур.
Такой метапроцесс определяет:
- Кто имеет право инициировать изменения в основном процессе. Обычно это владелец процесса, архитекторы или руководители направлений, которые ощущают его неэффективность.
- Как оценивается предлагаемое изменение. Оценка идёт не с точки зрения технического риска (это задача основного процесса), а с точки зрения процессного риска: не создаст ли новое правило конфликтов, не снизит ли оно общий уровень контроля, соответствует ли оно стратегическим целям.
- Упрощённый контур согласования для метаизменений. Круг согласующих сужается до ключевых стейкхолдеров (например, Head of Engineering, CISO, владелец ITSM). Цель — не задушить инициативу, а обеспечить взвешенное решение.
- Механизм тестирования и отката. Изменения в процессе могут вводиться пилотно для определённых типов изменений или команд, с чёткими метриками эффективности (например, время цикла согласования, процент отказов).
Связь с регуляторикой и 152-ФЗ
В контексте российских требований информационной безопасности необходимость метапроцесса становится не просто рекомендацией, а практически обязательной. ФСТЭК России в своих требованиях делает акцент на постоянном совершенствовании системы защиты информации. Жёстко прописанный и не пересматриваемый процесс согласования изменений в ИСПДн может быть расценен как формальный, не отвечающий принципу адекватности.
Например, при изменении класса защищённости системы или внедрении нового средства криптографической защиты информации может потребоваться пересмотреть состав комиссии, которая согласует изменения. Если для этого пересмотра нет регламентированной процедуры, организация либо нарушит свой же внутренний регламент, либо будет действовать неформально, что является риском при проверке.
метапроцесс обеспечивает доказательную базу для регулятора: компания не только имеет процесс управления изменениями, но и обладает механизмом для его актуализации в соответствии с меняющейся средой и угрозами.
Практические шаги для внедрения
Создание работающего метапроцесса требует баланса между гибкостью и контролем.
1. Определи границы и триггеры
Чётко опиши, какие именно изменения основного процесса подпадают под метапроцесс. Это не каждая правка шаблона заявки, а изменения, затрагивающие:
- Критерии классификации изменений (Standard, Normal, Emergency).
- Состав утверждающих лиц или ролей.
- Пороговые значения для автоматического одобрения.
- Перечень обязательных проверок или чек-листов.
Триггером может служить регулярный аудит процесса, рост числа исключений или прямая инициатива ключевых стейкхолдеров.
2. Создай облегчённую CAB
Для метапроцесса не нужна громоздкая Change Advisory Board, которая собирается еженедельно. Достаточно создать небольшую группу управления процессами (Process Governance Board), в которую входят:
- Владелец сервиса или процесса ITSM.
- Представитель службы информационной безопасности.
- Ведущий архитектор.
Их задача — рассматривать предложения не с технической, а с процессно-архитектурной точки зрения.
3. Введи понятие «экспериментального правила»
Позволь вносить изменения в процесс на ограниченный срок (например, на один квартал) в рамках пилотного проекта. Это снимает психологический барьер «меняем всё навсегда» и позволяет собрать реальные данные об эффективности нововведения перед его финализацией.
4. Документируй решения и их обоснование
Каждое изменение, внесённое через метапроцесс, должно сопровождаться кратким решением, где указаны: проблема, предложенное изменение, ожидаемый эффект и ответственные. Эта история изменений становится ценным активом для аудита и для обучения новых сотрудников.
Чего следует избегать
Главная опасность — превратить метапроцесс в такое же бюрократическое чудовище, против которого он был создан.
- Не дублируй этапы. Если для технического изменения нужна оценка риска ИБ, для изменения процесса эта оценка должна быть качественно иной (процессный риск, риск потери контроля).
- Избегай излишней демократии. Не нужно собирать голоса всех, кого процесс касается. Достаточно мнения тех, кто несёт ответственность за его результаты.
- Не допускай застоя. Установи периодический обязательный пересмотр ключевых процессов (например, раз в год) даже при отсутствии жалоб. Это профилактика устаревания.
Итог: от бюрократии к адаптивной системе
Процесс согласования процесса согласования изменений, это не оксюморон, а признак зрелости системы управления. Это переход от статичного набора правил к живой, адаптивной системе, которая способна учиться и меняться. В условиях российского ИТ-рынка, где требования регуляторов динамичны, а технологии обновляются быстро, такая способность к самонастройке становится конкурентным преимуществом. Это уже не просто выполнение формальных требований 152-ФЗ, а построение инфраструктуры, которая устойчива не только к внешним угрозам, но и к внутреннему организационному склерозу.