Вместо разрозненных Excel-планов восстановления, писем с напоминаниями и ручного отслеживания годовой аттестации — единый реестр планов с RTO/RPO по каждому процессу, дерево тестов офисов, поставщиков и систем, и правило «четырёх глаз» на каждом согласовании.
На показе открываем рабочий стенд: реестр планов восстановления с RTO и RPO по каждому процессу, карточку тестирования поставщика с блокировкой без действующей аттестации и годовую аттестацию плана с подтверждением координатора. На реальных экранах, без слайдов.
Сокращение трудозатрат на подготовку к проверке непрерывности деятельности и защита от операционных убытков при сбое — за счёт того, что план, тест и аттестация связаны в одном контуре, а не расходятся по файлам и переписке. Если сначала нужны подробности — устройство планов восстановления и требования к развёртыванию. CoB — Continuity of Business, управление непрерывностью деятельности.
Про деньги — по вашим числам. Сокращение трудозатрат на подготовку к проверкам и защита от операционных убытков — считаются на ваших ставках и объёмах, не на чужих процентах: система убирает ручную сборку реестра планов, сверку версий файлов и рассылку напоминаний, а пропущенный срок тестирования или аттестации перестаёт быть неожиданностью.
Один план, одна карточка теста, один статус и один ответственный. Ниже — реестры и колонки в том виде, в каком они заведены в продукте.
Таблица листается вбок — колонок больше, чем помещается на экране.
| Идентификатор плана | Подразделение | Ответственный плана | RTO, ч | RPO, ч | Статус плана |
|---|---|---|---|---|---|
| 214 | Департамент расчётов | Координатор восстановления подразделения | 4 | 1 | Одобрен |
| 213 | Процессинговый центр | Координатор восстановления подразделения | 2 | 0,5 | Ожидание завершения годовой аттестации |
| 212 | Клиентское обслуживание | Координатор восстановления подразделения | 8 | 4 | Ожидает одобрения |
| 211 | Казначейство | Координатор восстановления подразделения | 4 | 1 | Черновик |
Значения RTO (время восстановления) и RPO (допустимый объём потери) указаны в часах для каждого критического процесса плана.
| Идентификатор теста | Поставщик / система | Ответственный теста | Номер попытки | Дата тестирования | Статус теста |
|---|---|---|---|---|---|
| Т-408 | Процессинговый центр (поставщик) | Менеджер поставщика | 1 | 12.03.2026 | Согласован |
| Т-407 | Система обработки платежей | Координатор восстановления приложения | 2 | 05.03.2026 | На согласовании |
| Т-406 | Служба печати карт (поставщик) | Менеджер поставщика | 5 | 26.02.2026 | На доработке |
| Т-405 | Система дистанционного обслуживания | Координатор восстановления приложения | 1 | — | Создан |
Тест поставщика или системы нельзя создать без одобренной карточки и, для поставщика, без действующей положительной аттестации. Попытка 5 у теста Т-406 уже превысила порог в 4 попытки — ответственному корневого теста уходит уведомление о превышении.
| Идентификатор аттестации | Подразделение | Ответственный сотрудник | Дата аттестации | Результат аттестации | Статус аттестации |
|---|---|---|---|---|---|
| А-96 | Департамент расчётов | Координатор обеспечения непрерывности деятельности | 28.02.2026 | Пройдена | Аттестация успешно завершена |
| А-95 | Процессинговый центр | Координатор обеспечения непрерывности деятельности | 21.02.2026 | — | Ожидание завершения годовой аттестации |
| А-94 | Клиентское обслуживание | Координатор обеспечения непрерывности деятельности | 14.02.2026 | Не пройдена | Аттестация не пройдена |
Годовая аттестация собирает результаты тестирования офисов, поставщиков и систем плана в одну карточку и завершается подтверждением координатора обеспечения непрерывности деятельности.
Интерфейс продукта на нейтральных данных. Состав реестров, колонок и статусов — как в продукте.
План восстановления заводится один раз, проходит согласование по правилу «четырёх глаз», подтверждается тестированием и попадает в годовую аттестацию. У каждого шага — статус, ответственный и срок.
Как обычно
Кто отправил план на согласование и кто его одобрил — видно только по переписке. Просроченный тест обнаруживается, когда о нём спросят.
В системе
История изменений · история статусов · комментарии к плану, поставщику и системе · журнал отправленных уведомлений
Версия одна. Одобрить план или тест не может тот же сотрудник, который отправил его на согласование. Уведомление о просрочке, приближающемся сроке или превышении попыток уходит само.
Головному офису нужен единый управляемый реестр планов по всем подразделениям сложной организационной структуры, а не переписка с каждым из них.
Зависимость от внешних поставщиков и партнёрских каналов требует отдельного цикла их тестирования и аттестации — не общей строки в таблице рисков.
Критические процессы привязаны к коду процесса по классификации Банка России, а тестирование торговых систем ведётся отдельно от тестирования офисов и поставщиков.
Три роли, для которых в продукте есть отдельные права, уведомления и разделы — каждая держит свою часть контура непрерывности деятельности.
Держит контур целиком и первым видит разрозненность данных: без общего реестра он собирает статус по каждому подразделению вручную. В продукте — получает уведомление о смене статуса справочников и о необходимости подтвердить завершение годовой аттестации каждого подразделения, без обхода ответственных по почте.
Отвечает за план восстановления и критические процессы своего подразделения, но без отдельного инструмента не видит, какие из них не прошли годовую аттестацию. В продукте — реестры планов и тестирований фильтруются по его подразделениям и дочерним структурам автоматически.
Оценивает модель ролей и прав перед внедрением и отвечает за то, чтобы согласующий и отправитель не совпадали. В продукте — отдельный административный интерфейс модуля с полным набором прав, независимый от прав остальной платформы.
Не «система поддерживает разделение полномочий», а конкретные правила, заложенные в продукт и проверяемые на живом стенде.
Один человек не может завести план, согласовать его и закрыть
Правило «четырёх глаз» действует и на планах, и на тестах: одобрить план или тест не может тот же сотрудник, который отправил его на согласование. Кнопка одобрения не срабатывает для отправителя — это проверяется по последней записи в истории статусов, а не по памяти согласующего.
Каждую полночь система проверяет все тесты офисов, поставщиков и систем, а также общие тесты оповещения: помечает просроченные, истекающие сегодня и тесты с незаполненной датой и рассылает уведомления ответственным. Срок перестаёт быть тем, что держат в голове.
После четвёртой неудачной попытки тестирования система не создаёт пятую попытку молча — она отправляет ответственному корневого теста цепочки отдельное уведомление о превышении попыток тестирования.
Тест поставщика невозможно создать без одобренной карточки поставщика и без действующей положительной аттестации; тест системы — без одобренной карточки системы. Порядок «сначала карточка, потом тест» встроен в форму, а не держится на памяти сотрудника.
Руководителям подразделений и координаторам восстановления реестры планов и тестов показываются с фильтром по своим и дочерним подразделениям; если подразделений не назначено, реестр остаётся пустым, а не открывается целиком.
Модуль ведёт собственный контур ролей и прав: 7 бизнес-ролей и 13 типов защищаемых объектов, включая каждую вкладку карточки плана и теста по отдельности — с собственным журналом аудита, независимым от прав остальной платформы.
Смена статуса плана, теста или справочника пишется в единый журнал: кто, когда и на какой статус перевёл объект. Вопрос «кто согласовал» закрывается записью, а не перепиской.
У теста фиксируются связанные недостаток (Issue) и план корректирующих действий (CAP), а раздел годовой аттестации плана подтягивает последний тест и связанный с ним недостаток — без отдельной сверки вручную.
Годовая аттестация собирает результаты тестирования офисов, поставщиков и систем плана в одну карточку и завершается подтверждением координатора обеспечения непрерывности деятельности — отдельным действием, а не по умолчанию.
Реестр планов восстановления по подразделениям с RTO и RPO на каждый критический процесс, критическими сотрудниками и статусной моделью из 7 статусов — от черновика до подтверждённой годовой аттестации.
Критические процессы подразделения с кодом процесса по Банку России, уровнем критичности, привязкой к офисам и планам восстановления.
Отдельные циклы тестирования офиса, поставщика и системы с обязательными предпосылками, окном переключения для систем и аттестацией поставщика.
10 готовых Excel-отчётов — по планам, тестированиям и критическим процессам — с выгрузкой за выбранный период.
Ежедневная проверка сроков тестирования в полночь и эскалация по числу попыток — уведомления уходят ответственному автоматически.
Собственная модель прав модуля: 7 ролей, 13 типов защищаемых объектов до вкладки карточки и журнал аудита смен статусов.
Веб-приложение, развёртывание в инфраструктуре заказчика; отдельный административный интерфейс для настройки ролей и прав модуля.
Границы применимости — с обеих сторон, чтобы разговор о пилоте сразу шёл по существу.
Разработано с учётом практики банков под надзором Банка России
Продукт разработан с учётом требований по обеспечению непрерывности деятельности, предъявляемых к организациям под надзором Банка России: код критического процесса по Банку России — самостоятельный атрибут карточки процесса. Состав планов, ролей и отчётов настраивается под вашу организацию без правки кода.
Разработчик — российская компания ООО «Ланселот-ИТ». Продукт разворачивается в инфраструктуре заказчика, внешние сервисы для работы ему не требуются.
Платформа внедрена в банках и профессиональных участниках рынка под надзором Банка России
Перечень относится к платформе в целом; состав внедрённых продуктов у каждой организации свой.
Показываем систему на живом стенде: реестр планов, карточку тестирования поставщика с блокировкой без аттестации и завершение годовой аттестации. Без слайдов. Состав показа согласуем заранее.
Обычный маршрут плана и теста за пять шагов — на тех же экранах, что и на странице.
1 Реестр планов восстановления
Координатор восстановления подразделения открывает план в статусе «Черновик» и заполняет RTO, RPO и критических сотрудников.
2 Отправка плана на согласование
Одобрить план не может тот же сотрудник, который отправил его на согласование — правило «четырёх глаз».
3 Тестирование поставщика: проверка предпосылок
Без одобренной карточки и действующей положительной аттестации поставщика создать тест нельзя.
4 Превышение попыток тестирования
После четвёртой неудачной попытки система сама отправляет уведомление о превышении.
5 Годовая аттестация плана
Координатору обеспечения непрерывности деятельности уходит уведомление о необходимости подтвердить завершение годовой аттестации подразделения.
На демо-показе это работает на живом стенде.
Записаться на демо-показКак с нами связаться
Отвечаем в рабочие дни. Если удобнее письмом — напишите, приложив вопрос по существу.