Задача: перестать отвечать по отменённым редакциям
Типовая картина зрелой организации: сотни локальных нормативных актов — регламенты процессов, положения подразделений, инструкции по рабочим местам, приказы, меняющие отдельные пункты. Юридически актуальная версия одна; физически в обороте — файлы из почты, сетевых папок и распечатки. Сотрудник спрашивает коллегу или ищет сам и получает ответ из редакции двухлетней давности. Ошибка стоит по-разному: от лишней согласующей инстанции до нарушения процедуры, за которое отвечает исполнитель.
Задача контура — сделать действующую редакцию единственным источником ответа: вопрос обычным языком, ответ с реквизитами пункта и датой, с которой он применяется, а история редакций остаётся доступной для разбора споров.
Почему регламенты сложнее договоров
Общая база документов прощает многое: если в индекс попала старая версия договора, ответ просто будет менее полезным. С регламентами версия — это часть правильного ответа. Поэтому подготовка данных здесь главнее модели: акты раскладываются на структурные единицы (раздел — пункт — подпункт), каждая единица получает признаки документа, редакции и срока действия, точечные правки приказами связываются с базовым документом.
Вторая особенность — иерархия и противоречия. Когда два акта отвечают на вопрос по-разному, контур не выбирает молча: он показывает оба со статусами и подсвечивает конфликт владельцам документов. Третья — права доступа: регламентная база почти всегда разноуровневая, и сотрудник должен видеть только свой горизонт — фильтрация идёт на уровне фрагментов индекса, а не интерфейса.
Архитектура: ответ пунктом действующей редакции
Источники: регламенты, положения, инструкции, приказы о правках │ разбор структуры: раздел → пункт → подпункт ▼ Версионный индекс: фрагмент + документ + редакция + срок действия │ точечные правки приказами связываются с базовым актом ▼ Вопрос сотрудника (роль учитывается при поиске) │ гибридный поиск: смысл + структурные признаки ▼ LLM: ответ по найденным пунктам + реквизиты + «действует с …» ├──► пункты конфликтуют ──► оба источника + эскалация владельцу └──► в базе нет ответа ──► «не найдено» вместо домысла ▼ Обновление: новая редакция → перезагрузка → старая уходит в историю
Такая схема экономит самое дорогое — доверие к системе: ответ всегда проверяем, а история редакций доступна для разбора «как было на ту дату», что регулярно требуется в спорах и аудитах.
Этапы внедрения
| Этап | Что получается | Цена | Срок |
|---|---|---|---|
| Ревизия базы | инвентаризация актов, карта версий и противоречий, план вычистки | 90 000 ₽ | 3–5 рабочих дней |
| Пилот в одном подразделении | версионный индекс, ответы пунктами, замер доли точных ответов | от 480 000 ₽ | 4–6 недель |
| Промышленная система | все подразделения, роли, стыковка с СЭД и процессом издания актов | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | контроль актуальности, донастройка после кадровых и процессных изменений | по отдельному договору | — |
Ориентир рынка: в выборке из 236 закрытых лотов сентября медиана начальной цены — 2,43 млн ₽; регламентная база относится к более лёгкому сегменту. Стоимость указана «от», НДС не облагается в связи с применением УСН (п. 2 ст. 346.11 НК РФ).
Приёмка: как проверяем систему
Пилот регламентной базы принимается по контрольной выборке вопросов реальных сотрудников. Замеряются три доли: точных ответов, ответов со ссылкой на действующую редакцию и честных «не найдено» — третье так же важно, как первое: система, которая выдумывает, опаснее системы, которая признаёт пробел. Отдельно прогоняются граничные случаи: вопрос, на который в базе есть два противоречащих пункта, и вопрос, ответ на который появился лишь новой редакцией.
Права доступа проверяются контрольными аккаунтами разных ролей: сотрудник одного подразделения не должен видеть режимные акты другого даже через поиск — это требование соблюдается так же строго, как точность ответов. Система считается готовой к промышленному развёртыванию, когда доля точных ответов выходит на согласованный порог, а найденные конфликты базы либо устранены, либо стоят в плане вычистки с датами. Протокол приёмки становится базовой линией для сопровождения: дальше качество только измеряется и не деградирует незамеченным.
Типовые метрики «до/после»
Дальше — типовые диапазоны результатов класса, а не отчёт конкретной компании. Базовая линия замеряется до старта: время поиска пункта, доля ответов по устаревшим редакциям (аудит контрольной выборки).
- Поиск пункта регламента: с 15–40 минут до секунд; типовая экономия — час и более на специалиста в неделю.
- Доля ответов по устаревшим редакциям: снижение в разы за счёт версионного индекса и правил актуальности.
- Противоречия базы: типовая находка ревизии — 5–15% актов конфликтуют между собой; после вычистки конфликты ловятся на издании.
- Онбординг новых сотрудников: типовое сокращение времени до самостоятельной работы — 20–40%.
Безопасность и границы
Регламентная база описывает процессы и может содержать сведения ограниченного доступа. Типовой контур: российские информационные системы, разграничение фрагментов по ролям, журналирование, обезличенная аналитика запросов — под 152-ФЗ и режим коммерческой тайны там, где он объявлен. Граница автоматизации: система отвечает «как прописано» и подсвечивает конфликты, но решение о применении нормы в спорной ситуации остаётся за владельцем процесса. Ответы по режимным актам проходят через те же права доступа, что и сами документы.
Об этом разборе. Это обезличенный типовой проект из нашей практики проектирования: имена компаний не раскрываются (NDA), метрики приведены как типовые вилки; рабочие цифры фиксируются в КП и на приёмке. Реквизиты актов в ответах всегда проверяемы — модель не конструирует номера редакций.