Реестр планов
У каждого критичного процесса — срок восстановления, ответственный и статус, который нельзя поправить руками
План непрерывности перестаёт быть файлом на сетевом диске. Это запись с обязательными полями, целевыми показателями RTO и RPO, порядком перехода на резервную схему и статусной моделью из семи состояний. Пока обязательное поле пустое, план не уйдёт на согласование; пока согласование не пройдено — план не считается действующим.
ОНиВД — обеспечение непрерывности и восстановления деятельности; англоязычное обозначение — Continuity of Бизнес-подразделение (CoB).
Реестр планов: один список вместо десятка версий одного файла
Реестр показывает планы критичных процессов со статусом, целевыми показателями восстановления, подразделением и датой последнего изменения. Руководитель подразделения и координатор восстановления подразделения видят в нём только свою ветку оргструктуры — вместе с подчинёнными подразделениями.
Таблица прокручивается вбок.
| План | Критичный процесс | Подразделение | Координатор восстановления | RTO | RPO | Изменён | Статус |
|---|---|---|---|---|---|---|---|
| П-41 | Расчёты по операциям с ценными бумагами | Управление расчётов | Координатор восстановления подразделения | 4 ч | 15 мин | 03.02.2026 | Согласован |
| П-47 | Приём и исполнение платёжных поручений | Операционное управление | Координатор восстановления подразделения | 2 ч | 5 мин | 21.02.2026 | На согласовании |
| П-52 | Обслуживание клиентов в офисах сети | Розничный блок | Координатор восстановления подразделения | 8 ч | 1 ч | 27.02.2026 | Черновик |
| П-58 | Казначейские операции | Казначейство | Координатор восстановления подразделения | 1 ч | 0 мин | 05.03.2026 | На подтверждении завершения |
| П-63 | Сопровождение карточных операций | Управление сопровождения | Координатор восстановления подразделения | 4 ч | 30 мин | 11.03.2026 | Завершён |
| П-66 | Депозитарный учёт | Депозитарий | Координатор восстановления подразделения | 6 ч | 15 мин | 14.03.2026 | Аттестация не пройдена |
Полный набор состояний плана: черновик, на согласовании, согласован, на подтверждении завершения, завершён, аттестация не пройдена, в архиве.
Состав колонок, полей, этапов и статусов — как в продукте. Данные в строках — пример заполнения.
Сотрудник видит планы только своей ветки оргструктуры
Для роли «Руководитель подразделения» и роли «Координатор восстановления подразделения» реестр фильтруется по строкам: система берёт действующие записи привязки сотрудника к подразделениям — те, у которых не проставлена дата закрытия и стоит признак согласования, — и рекурсивно разворачивает дерево вниз, до самых нижних подразделений. Соседний блок в выдачу не попадает: не потому, что кнопка спрятана, а потому, что строк там для этого сотрудника нет.
Карточка плана: семь вкладок, каждая — с собственным правом доступа
Карточка собирает в одном месте то, что обычно живёт в разных файлах и у разных людей: сам процесс, целевые показатели, поставщиков, системы, годовую аттестацию, переписку и историю правок. Вкладку, на которую у сотрудника нет права чтения, он не увидит; если недоступны все вкладки — карточка не откроется вовсе.
Что видит владелец процесса
- Процесс — критичный процесс, его уровень критичности, режим работы, владелец и подразделение.
- Описание — RTO, RPO, оценка ущерба и её обоснование, нематериальный ущерб, уровень внедрения, порядок перехода на резервную схему и порядок возврата к штатной работе, критичные сотрудники.
- Поставщики — строки, привязанные к плану при его создании.
- Системы и приложения — то же для ИТ-объектов процесса.
Что видит проверяющий
- Годовая аттестация — подтверждение готовности подразделения, собранное из последних согласованных тестов.
- Комментарии — обсуждение, привязанное к самой записи, с вложениями, а не в почте.
- История изменений — кто, когда и какое поле поменял, со старым и новым значением.
Обязательные поля: карточку нельзя закрыть формально
Отметьте поля, как их заполняет владелец процесса, — кнопка отправки на согласование останется недоступной, пока не заполнено всё. Так же ведёт себя продукт.
В работе
Не заполнено полей: 7. Карточка остаётся в работе — на согласование она не уйдёт.
Связи процесса подтягиваются сами — переносить их руками не нужно
План создаётся прямо из карточки критичного процесса. Система связывает процесс с планом, наследует подразделение процесса и назначает автора ответственным, а поставщиков и системы переносит в план связанными строками из представлений данных. Это снимает классический разрыв: процесс изменили, а в плане остался прежний состав ресурсов.
План непрерывности корневая запись
Целевые показатели восстановления, порядок перехода и возврата, оценка ущерба, координатор, подразделение, статус.
Критичные процессы связь «процесс — план»
- Наименование и описание на русском и английском
- Код процесса по классификатору организации
- Уровень критичности и статус процесса
- Режим работы — берётся из последней записи расписания процесса
- Владелец процесса, владелец данных, менеджер процесса, менеджер качества и их подразделения
Офисы и площадки связь «план — офис — площадка»
- Офис или подразделение размещения
- Площадка размещения из справочника
- Резервная стратегия из справочника
По этой тройке — офис, площадка, резервная стратегия — годовая аттестация ищет последний согласованный тест.
Поставщики переносятся при создании плана
- Поставщик и связанный с ним критичный процесс
- Дата создания связи
- Закрытые связи поставщика с процессом в список не попадают
Системы и приложения переносятся при создании плана
- ИТ-объект и связанный с ним критичный процесс
- Дата создания связи
- По каждому объекту ведётся собственный тест переключения на резервную схему
Мастер-данные — критичные процессы, поставщики, ИТ-объекты, площадки, резервные стратегии, оргструктура и расписания — ведутся в модуле управления операционным риском и инцидентами той же платформы. План непрерывности не заводит их заново, а ссылается на них. Следствие для внедрения: справочники наполняются один раз и работают на оба контура.
RTO, RPO и ущерб — поля записи, а не абзац в документе
Целевые показатели восстановления хранятся числами в отдельных полях. Их видно в реестре, они попадают в отчётные формы, изменение любого из них фиксируется в истории с прежним и новым значением. Вопрос проверяющего «когда и на каком основании RTO стал восемь часов вместо четырёх» перестаёт быть расследованием по переписке.
Целевые показатели
RTO — целевое время восстановления процесса. RPO — целевая точка восстановления, допустимый объём потерянных данных. Оба — числовые поля карточки, оба выходят в отчёты по планам и по критичным процессам.
Оценка последствий
Ущерб, обоснование оценки ущерба и нематериальный ущерб — три отдельных поля. Обоснование хранится рядом с числом, поэтому оценку можно защитить, а не пересчитывать заново перед каждой проверкой.
Готовность резервной схемы
Уровень внедрения резервной схемы, порядок перехода на неё и порядок возврата к штатной работе — поля того же плана. Регламент лежит не в приложении к письму, а в записи, по которой проводится тест.
Наименование и описание у большинства сущностей хранятся в двух языках сразу. Отчёт формируется на языке сеанса пользователя, поэтому одна и та же форма без переверстки уходит и в надзорную отчётность, и в головную организацию международной группы.
Статус меняется переходом, а не правкой поля
Семь состояний и объявленные переходы между ними. Пользователь не выбирает статус из выпадающего списка — он выполняет действие, доступное из текущего состояния и разрешённое ему правами. Наведите указатель на название состояния под схемой или перейдите к нему с клавиатуры: появится пояснение, что это означает для работы.
Схема прокручивается вбок.
Состав состояний и переходов — как в продукте: семь состояний, пять объявленных переходов, на возврате в работу комментарий обязателен. Седьмое состояние — «В архиве» — снимает запись с оперативного контроля, не удаляя её.
Что означает состояние: Черновик · На согласовании · Согласован · На подтверждении завершения · Завершён · Аттестация не пройдена · В архиве
| Состояние | Код | Что это означает для работы |
|---|---|---|
| Черновик | Черновик | Рабочий план на стадии наполнения. Автор — тот, кто создал запись. Правки свободны, к отчётности запись не относится. |
| На согласовании | onConfirmation | Ответственность передана согласующему. Автор отправки согласовать эту же запись не сможет. |
| Согласован | approved | Действующий план. С него начинается годовая аттестация подразделения. |
| На подтверждении завершения | onConfirmationCompleted | Аттестация подразделения пройдена, ждём подтверждения. Правка полей аттестации в этом состоянии закрыта. |
| Завершён | Завершено | Годовой цикл по плану закрыт подтверждением. Карточка аттестации только для чтения. |
| Аттестация не пройдена | failed | Подразделение не подтвердило готовность. Запись остаётся на виду с отрицательным результатом — «потерять» её нельзя. |
| В архиве | archived | Запись снята с оперативного контроля и сохранена вместе со всей историей. |
Разделение полномочий: защита от халатности и от внутреннего фрода
Контроль, который в регламенте звучит как «принцип четырёх глаз», здесь работает не на дисциплине исполнителя, а на данных. Это единственный способ ответить проверяющему на вопрос «а что мешает согласовать собственный план» иначе, чем ссылкой на порядочность сотрудников.
Кто отправил на согласование — тот не согласует
При переходе в состояние «Согласован» система читает журнал статусов, находит последнюю запись о переводе на согласование и сравнивает её автора с текущим пользователем. Совпали — действие согласования недоступно. Правило одинаково работает для планов и для тестов восстановления и не зависит от того, какие права у пользователя есть на бумаге.
Отправил на согласование
Координатор восстановления подразделения перевёл план из черновика. Отметка об этом легла в журнал статусов вместе с датой и идентификатором сотрудника.
не может быть
одним лицом
Согласовал
Действие доступно другому сотруднику — при условии, что у него есть право «Выполнить» на целевое состояние и право «Читать» на исходное.
Возврат на доработку без комментария невозможен
Переход «на доработку» открывает форму с обязательным комментарием. Текст ложится в журнал статусов рядом с исходным и целевым состоянием, датой и автором. Через полгода видно не только то, что план вернули, но и почему.
Права выдаются на каждое состояние отдельно: одному сотруднику можно разрешить только отправку на согласование, другому — только согласование, третьему — только возврат на доработку. Подробно ролевая модель разобрана в разделе «Права доступа и аудит».
История изменений отвечает на вопрос «кто и когда» без расследования
Каждое изменение поля — отдельная запись журнала: дата, сотрудник, сущность и её идентификатор, поле, прежнее и новое значение. Отдельно ведётся журнал статусов с комментариями. Оба доступны прямо из карточки.
Журнал изменений полей
Показывает дату и время, сотрудника, запись и её идентификатор, наименование поля, прежнее и новое значение. Ссылочные поля отображаются наименованием объекта, а не внутренним номером, и на языке сеанса.
Журнал статусов
Фиксирует запись и её тип, исходное и целевое состояние, дату изменения, комментарий с формы возврата, получателей уведомления и сотрудника, выполнившего переход. Этот же журнал читает правило разделения полномочий.
Комментарии живут в записи, а не в переписке
К плану, поставщику и системе прикрепляется обсуждение с вложениями. Ветка привязана к конкретной записи, поэтому вместе с планом передаётся и её контекст: почему выбрана эта резервная стратегия, что решили по итогам прошлого теста, чего ждут от следующего.
Что это даёт ИТ-директору
- 7вкладок карточки плана, и каждая — самостоятельный объект защиты: право на чтение выдаётся отдельно
- 2роли с фильтрацией строк по оргструктуре: доступ ограничивается данными, а не интерфейсом
- 11полей в записи журнала изменений, включая прежнее и новое значение
- 0исходящих сетевых вызовов в модуле: он работает внутри вашего контура
Границы блока «Планы» очерчены явно: он владеет планом, его связями с процессами, офисами, поставщиками и системами, годовой аттестацией и статусной моделью. Справочники и оргструктура приходят из модуля управления операционным риском и инцидентами. Такое разделение означает предсказуемую нагрузку на инфраструктуру и одно место для наполнения справочников. Подробности развёртывания — в разделе «Архитектура и внедрение».
Что входит и что настраивается под вашу организацию
Что входит
- Реестр и карточка плана непрерывности с семью вкладками
- Статусная модель из семи состояний с объявленными переходами и обязательным комментарием на возврате
- Правило разделения полномочий на согласовании
- Связи плана с критичными процессами, офисами и площадками, поставщиками, системами и приложениями
- Целевые показатели RTO и RPO, оценка ущерба и её обоснование, уровень внедрения, порядок перехода и возврата
- Журнал изменений по полям, журнал статусов, комментарии с вложениями
- Годовая аттестация подразделения на отдельной вкладке плана
Что настраивается под вашу организацию
- Состав ролей и их соответствие вашим подразделениям — набор ролей продукта служит методическим ориентиром, а не жёсткой рамкой
- Права на вкладки карточки и на отдельные состояния плана
- Справочники площадок и резервных стратегий
- Привязка сотрудников к подразделениям, определяющая видимость строк
- Классификатор критичных процессов и уровней критичности
- Состав получателей уведомлений о смене статуса
Кому подходит: организациям, где непрерывность закреплена за подразделениями, а не за одним человеком, и где по каждому критичному процессу нужно предъявлять действующий план с целевыми показателями и следом согласования.
Показать карточку плана на вашем критичном процессе
Возьмите один процесс со всеми его поставщиками и системами — на демонстрации заведём по нему план, отправим на согласование и покажем, что произойдёт при попытке согласовать собственную запись.