Решение о смене модели поддержки часто принимают после серии проблем, когда желание изменить ситуацию уже есть, а проект еще нужно защитить внутри компании. В этот момент полезно отделить реальные риски перехода от общего страха перемен. Реестр рисков делает обсуждение предметным: что именно может произойти, почему, на какой процесс повлияет и как это контролировать.
Хороший реестр не доказывает, что переход безопасен. Он показывает, какие неопределенности известны, какие меры подготовлены и кто имеет право принять остаточный риск. Для руководства это намного сильнее обещания «все пройдет бесшовно», потому что позволяет увидеть управляемость инициативы.
Если риски начинают собирать после старта, часть решений уже принята: выбран срок, согласован бюджет, выданы доступы, запущена передача знаний. Тогда реестр превращается в журнал проблем. До согласования он выполняет другую функцию — помогает выбрать масштаб перехода, приоритеты, необходимые ресурсы и контрольные точки.
Реестр также снимает ложную дилемму «менять опасно / не менять безопасно». В него стоит включить риски сохранения текущей модели: зависимость от экспертов, повторные инциденты, непрозрачные стыки и накопленный технический долг. Тогда руководство сравнивает два набора рисков, а не только стоимость изменений.
Формулировка «может упасть система» слишком общая. Рабочая запись связывает причину, событие и последствие: например, «если знания по критичному обмену не переданы до переключения, новая команда может дольше диагностировать сбой, что увеличит время недоступности процесса отгрузки». Такая запись уже подсказывает меры контроля.
Для каждого риска нужны владелец, вероятность или качественная оценка, влияние, меры до события, действия при реализации и остаточный риск после мер. Необязательно строить сложную количественную модель — достаточно единой шкалы, которую одинаково понимают участники проекта.
Удобно группировать риски по источнику: непрерывность сервиса, знания, доступы и безопасность, незавершенные работы, организация, финансы и контракт. Такая структура помогает не сосредотачиваться только на технических сбоях и вовлекать нужных владельцев со стороны бизнеса, ИБ, закупок и ИТ.
Отдельная группа — внешние зависимости: вендоры, каналы связи, облачные сервисы, лицензии. Они могут не меняться вместе с подрядчиком, но переход меняет точки контакта и порядок эскалации, поэтому их тоже нужно включать в анализ.
Категория 1. Риски непрерывности сервиса
Сюда относятся потеря контроля над критичным инцидентом, неполная настройка мониторинга, разрыв каналов обращения, отсутствие готового отката, переход в чувствительный бизнес-период. Меры контроля — поэтапное переключение, дежурство, контрольные сценарии, запрет на крупные изменения и усиленный мониторинг после старта.
Владелец риска должен быть связан с бизнес-сервисом, а не только с технической системой. Тогда приоритет определяется влиянием на процесс, а не уровнем тревожности конкретной команды.
Категория 2. Риски знаний и зависимости от людей
Риск возникает, если критичный контекст остается у старого подрядчика или отдельных сотрудников: неписаные правила, известные ошибки, история архитектурных решений, контакты внешних участников. Простая передача документов не закрывает проблему.
Контролем служат карта знаний, дублеры, совместное решение задач и проверка воспроизводимости. Для наиболее критичных процедур новая команда должна выполнить сценарий самостоятельно до переключения.
Категория 3. Доступы, ИБ и данные
На переходе одновременно меняются права двух команд. Возможны избыточные привилегии, потерянные учетные записи, общие доступы, отсутствие журналирования или слишком ранний отзыв прав у прежнего исполнителя. Отдельно оцениваются правила работы с выгрузками и чувствительными данными.
Меры контроля включают матрицу ролей, временные права, проверку логирования, план отзыва и приемку доступов по фактическим операциям. ИБ должна участвовать до начала продуктивной работы, а не только согласовать договор.
Категория 4. Незавершенные работы и технический долг
Открытые релизы, проблемы, аварийные обходы и старые дефекты могут потерять владельца при смене команды. Особенно опасны задачи, которые не находятся в активной очереди, но уже влияют на стабильность. Поэтому перед переходом нужна отдельная инвентаризация незавершенных обязательств.
По каждой значимой позиции фиксируются статус, следующий шаг, владелец после переключения и решение: завершить старой командой, передать новой или временно заморозить. Это уменьшает риск «наследства без контекста».
Категория 5. Организационные риски
Сопротивление внутренней команды, перегрузка ключевых специалистов, неясная роль заказчика и конфликт между подрядчиками могут сорвать технически корректный переход. Эти риски часто недооценивают, потому что их нельзя закрыть настройкой системы.
Нужны план коммуникаций, понятные роли, ограничение параллельных инициатив и вовлечение владельцев процессов. Если переход требует значительной работы от внутренних экспертов, эта нагрузка должна быть учтена в плане, а не считаться бесплатным ресурсом.
Категория 6. Финансовые и контрактные риски
Переход может временно увеличить расходы из-за параллельных команд, работ по передаче знаний и настройки инструментов. Риск возникает, если этот профиль затрат не показан заранее и воспринимается как неожиданное удорожание. Отдельно учитываются обязательства по старому контракту, лицензии и стоимость незавершенных работ.
Меры контроля — раздельный учет разовых затрат и регулярного сервиса, прозрачный объем работ и условия приемки. Экономический эффект после перехода нельзя обещать без исходных данных, но можно заранее показать, какие статьи затрат меняются и почему.
Для большинства проектов достаточно качественной шкалы из трех-пяти уровней. Вероятность оценивает шанс события, влияние — последствия для бизнеса и сервиса. После мер контроля оценивается остаточный риск. Это позволяет понять, где нужны дополнительные действия, а где риск можно принять.
Шкала должна быть одинаковой для всех категорий. Если техническая команда считает высоким только риск простоя, а бизнес — только финансовое влияние, общий реестр не работает. Лучше заранее описать критерии уровней и примеры.
«Усилим внимание» и «подрядчик гарантирует» не являются мерами. Контроль должен быть проверяемым: выдать доступ, провести сценарий, назначить владельца, включить мониторинг, выполнить выгрузку базы знаний, согласовать откат, закрыть конкретный пробел.
Хорошая мера имеет срок или условие завершения и доказательство. Это может быть протокол теста, запись в ITSM, обновленная матрица, принятая инструкция. Такой подход помогает использовать реестр как рабочий инструмент, а не презентационную таблицу.
Руководству не нужен полный технический список. На защиту выносят ключевые риски, влияние на бизнес, меры контроля, владельцев и решения, которые требуется согласовать. Это показывает, что команда понимает не только выгоды смены модели, но и цену перехода.
Полезно отдельно показать риски бездействия. Например, сохраняющуюся зависимость от одного эксперта или повторяемые инциденты. Тогда проект оценивается как выбор между управляемыми изменениями и продолжением текущих проблем, а не как «рискованный переход ради перехода».
Часть рисков нельзя устранить полностью: внешние сервисы, дефицит редкой экспертизы, критичные бизнес-окна. После завершения перехода они должны перейти в штатное управление сервисом с владельцами, мониторингом и регулярным пересмотром.
Практика проектов IBS полезна как источник сценариев, но реестр всегда строится под конкретный ландшафт. Копирование чужого списка создает ложную полноту и пропускает уникальные зависимости.
На встрече не нужно перечитывать весь реестр. В фокус попадают новые риски, записи с изменившейся оценкой, просроченные меры и решения, требующие владельца. Для каждого такого пункта команда фиксирует конкретное действие или осознанное принятие риска. Это удерживает документ в рабочем состоянии и не превращает его в архив страхов.
После каждой контрольной точки полезно закрывать устаревшие риски и добавлять новые, которые проявились в реальной передаче. История изменений при этом сохраняется: она помогает объяснить, почему проект поменял последовательность этапов или потребовал дополнительный ресурс.
| Риск | Триггер | Последствие | Вероятность | Влияние | Мера | Владелец | Стоп-фактор |
|---|---|---|---|---|---|---|---|
| Не переданы критичные знания | Провал контрольного сценария | Зависимость от старой команды | Оценивается | Высокое | Дополнительная передача | руководитель перехода | Да |
| Не готовы доступы | Нет административной роли | Невозможность восстановления | Оценивается | Высокое | Закрыть матрицу прав | ИБ/ИТ | Да |
| Пиковый период бизнеса | Смена в запретное окно | Рост операционного риска | Оценивается | Высокое | Перенести переключение | Бизнес-владелец | Да |
Реестр рисков нужен не для доказательства, что проблем не будет, а для управляемого решения. Если требуется собрать риск-модель перехода и контрольные точки под конкретные системы, обсудить переход с IBS можно до внутренней защиты инициативы.