Устанавливается вместе с ядром платформы — не отдельным проектом с чистого листа
Технологический стек
Ниже — то, что подтверждается файлами сборки и миграций, с указанием источника. Значения, которые код не фиксирует напрямую, в этот список не включены — они вынесены отдельным списком в раздел «Что требует подтверждения владельца» ниже.
| Параметр | Значение | Источник |
|---|---|---|
| Сборка | Gradle, единый war-артефакт на всё приложение платформы | build.gradle |
| Миграции | Liquibase 4.21.1 | build.gradle |
| СУБД | PostgreSQL | СУБД-специфичные каталоги миграций реестра — только pg |
| Профили запуска | prod (по умолчанию), dev, uat | application-*.properties |
| Схемы БД | oper, nsi, dm, stgoper, securityoper, mca, supplier_analysis | миграции соответствующих наборов |
Развёртывание в инфраструктуре заказчика
Реестр процессов устанавливается в инфраструктуре заказчика вместе с общим war-приложением платформы — отдельного контейнера, отдельного облачного контура или SaaS-версии у процессной части нет: она разворачивается, обновляется и масштабируется как часть общего приложения. Собственных сетевых требований, кроме доступа к базе данных и, при использовании внешней оргструктуры, к её веб-сервису, реестр процессов не предъявляет.
Отдельно реестр процессов не отключается и не откатывается
Пакеты реестра входят в общий component scan приложения и поднимаются вместе с ним; миграции реестра перемешаны в тех же кумулятивных наборах, что и остальная операционная надёжность. Планировать установку и откат стоит на уровне всего приложения, а не отдельной «процессной» части.
Интеграционные точки и обмен данными
Смежные модули не опрашивают реестр процессов через отдельный API — они читают те же таблицы и представления напрямую: самооценка контролей и анализ поставщиков — через собственные представления и отображённые сущности индикативной схемы поверх той же таблицы реестра, непрерывность деятельности — через собственный домен поверх неё же. Массовый ввод данных заведён отдельным каналом: импорт процессов, сквозных процессов, иерархии процессов и шаблона критичных элементов данных — через приёмные таблицы стейджинга и хранимые процедуры, вызываемые из формы импорта Excel.
- 5смежных схем БД, читающих таблицы реестра напрямую
- 3типа объектов защиты, разделяющих доступ к разделам и статусам
- 5видов импорта из Excel через стейджинг
Что настраивается под вашу организацию
Это не пробелы в продукте, а решения, которые правильно принимать на стороне внедрения, а не фиксировать заранее в коде продукта: применимость технологических процессов к конкретной организации, собственные уровни допустимого простоя сверх регуляторных значений, состав пользователей и их роли, а также способ аутентификации — он задаётся конфигурацией и определяется на внедрении, а процессные роли назначаются уже поверх учётной записи, прошедшей вход.
Ниже — то, что стороны фиксируют вместе на старте проекта, а не то, что продукт решает за заказчика:
Безопасность и аудиторский след
Доступ к реестру процессов управляется тремя раздельными типами объектов защиты — доступ к справочнику, доступ к разделам карточки и право на конкретные переходы статусной модели — подробный разбор на странице «Права доступа». Для аудита доступа предусмотрены отдельные роли с правом только READ на реестр, справочники и разделы карточки — «Аудитор» и «Аудитор администрирования», — которые могут проверить, что назначено, не имея возможности что-либо изменить.
Каждый переход статуса процесса — отдельная запись протокола с исполнителем, датой, исходным и целевым статусом. Карточка процесса отдельно ведёт «Историю изменений» — журнал правок самих полей, не только статуса. Вместе это даёт полный аудиторский след и по содержимому карточки, и по её согласованию.
Этапы внедрения
Реестр процессов вводится в эксплуатацию первым среди процессно-зависимой группы модулей — пока он пуст, смежные модули технически работают, но им не к чему привязать свои планы, таксономии и анкеты. Порядок ниже — фактическая последовательность приёмки, а не оценка сроков: сроки и длительность пилота — предмет отдельного согласования, см. список выше.
1. Подготовка инфраструктуры и конфигурации СУБД, файловое хранилище, параметры
Развёртывание PostgreSQL, файлового хранилища вложений и заполнение параметров подключения — общих для всего приложения платформы.
2. Миграции и первичная настройка доступа схемы, справочники 716-П, роли
Применение миграций создаёт схемы и справочники 716-П, назначаются роли участникам процессного контура — без них навигатор реестра не построится ни у одного пользователя.
3. Наполнение реестра процессов верхние уровни — КПО, нижние — владельцы и менеджеры
Верхние уровни иерархии заводит, как правило, роль «Сотрудник КПО»; уровни ниже — владельцы процессов и менеджеры процессов, каждый в границах своей роли.
4. Непрерывность деятельности, контроли, поставщики осмысленны только после наполненного реестра
Планы восстановления, таксономия контролей и анкеты поставщиков читают реестр процессов напрямую — до его наполнения эти модули технически работают, но не к чему привязать их объекты.
Что это даёт ИТ-директору. Порядок внедрения смежных модулей — не организационная договорённость, а прямое следствие того, что они читают тот же реестр: планировать проект стоит с наполнения реестра процессов, а не параллельно с ним.