Реестр обращений граждан в ведомстве: учёт, сроки и ответственные
У каждого обращения есть срок, ответственный и история, а просрочка видна заранее, а не после жалобы
Проверяется: сверка с бумажным журналом и прогон ролей
ГоссекторРаботаем по NDA
Обращения приходят разными путями: почта, сайт, приём, межведомственные запросы. Регистрируют их в разных таблицах и журналах. Сроки ответа отслеживает один сотрудник, поручения теряются при передаче между подразделениями, а отчёт руководителю собирают вручную.
Что съедает срок и бюджет на самом деле
Здесь проблема не в форме регистрации, а в процессе вокруг неё. Вот что встаёт.
Много входов, один реестр
обращение должно попасть в один реестр независимо от канала. Дубли и повторные обращения нужно находить и связывать.
Сроки зависят от типа обращения
правила сроков задаются нормативно и меняются. Их нужно хранить данными, а не вшивать в код.
Поручения теряются на передаче
при передаче между подразделениями не фиксируются ответственный и срок. Нужны статусы, маршрут и напоминания.
Отчётность собирают вручную
без единого реестра цифры для руководителя строятся по таблицам и расходятся. Отчёт должен формироваться из реестра.
Ограничение, которое определяет решение
Данные обращений содержат персональные данные граждан, поэтому система работает в контуре ведомства на серверах организации, с разграничением прав и журналом действий. Требования к программному обеспечению из реестра российского ПО и аттестация системы определяются вашим регулятором, лицензируемые работы по защите информации мы не выполняем, лицензии ФСТЭК у нас нет.
Как проверить, что работа сделана
Сверка с бумажным журналом: за согласованный период число и состав обращений в реестре совпадают с журналом, расхождения разобраны по каждому.
Прогон ролей: из-под каждой роли пробуем открыть обращения чужого подразделения и изменить закрытое, сервер должен отказать.
Сроки: контрольные обращения разных типов получают верный срок, просрочка и напоминания срабатывают в нужное время.
О чём спросить любого подрядчика
- Как реестр получает обращения из разных каналов и находит повторы.
- Где хранятся правила сроков и кто может их менять.
- Как устроены роли и журнал действий.
- Где работает система и кто имеет к ней доступ.
- Как формируется отчёт и совпадает ли он с реестром.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Карта процессаЗаписываем каналы, маршруты, роли и сроки. Результат: схема процесса и перечень правил.
- Модель реестраОпределяем поля, статусы, связи между обращениями. Результат: схема данных и матрица ролей.
- РазработкаРегистрация, маршрут, сроки, напоминания, журнал, отчёты. Раз в две недели показываем рабочую версию на стенде.
- Перенос и сверкаЗагружаем действующие данные из таблиц, сверяем с бумажным журналом. Результат: протокол сверки.
- Запуск в подразделенииВключаем в одном подразделении, затем расширяем. Передаём исходный код, инструкции и регламент сопровождения.
Как это обычно устроено внутри
Типовая схема: веб-приложение на серверах ведомства, база данных с историей изменений, ролевая модель с разграничением по подразделениям, правила сроков хранятся данными. Напоминания и отчёты формируются по расписанию, каждое действие пишется в журнал, вход идёт через каталог пользователей организации.
- PostgreSQL
- Astra Linux
- REST API
- LDAP
- Журнал действий
- Docker
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.