ИИ в 1С:Документооборот: маршрутизация и согласование без ручной сортировки 

Откройте журнал регистрации и поставьте рядом два поля: время поступления документа и время первой резолюции. Медиана этого промежутка — первая честная цифра о вашей канцелярии. Вторую дает журнал задач: доля поручений, которые переадресовывали или возвращали автору. Каждый такой возврат — сутки срока, сгоревшие до того, как кто-то взялся за работу.

1С:Документооборот в этих потерях не виноват. Он честно отрабатывает маршрут, который ему задали: маршрут строится по реквизитам карточки, а решение «кому это» человек принимает, прочитав текст письма. Вот в зазор между реквизитом и смыслом и помещается модель. Ниже — четыре узла, где зазор существует, с какого из них начинать, во что это обходится по деньгам и что автоматике отдавать нельзя ни при каких обстоятельствах.

Четыре узла, где уходит время

Работа канцелярии раскладывается на четыре узла. Смотреть в таблице надо на правую колонку: цена ошибки в узлах разная, и она решает, что отдавать машине первым.

Асимметрия тут принципиальная. Верхняя строка обратима: карточку поправили до записи, ничего никуда не ушло. Нижняя требует проверяемого ответа, иначе им нельзя пользоваться. Отсюда и порядок работ.

Посчитайте свой поток до разговора о моделях

Три формулы, которые считаются за вечер по журналу регистрации. Без них любой разговор про автоматизацию документооборота превращается в обмен мнениями.

Формула первая, сортировка. Возьмем канцелярию с потоком 800 входящих в месяц. Открыть, прочитать, определить вид и адресата, зарегистрировать — положим четыре минуты на письмо, свою цифру снимете секундомером. Получается 53 часа в месяц. Час сотрудника канцелярии с окладом 70 000 ₽ стоит компании (70 000 + 30% взносов) ÷ 165 рабочих часов ≈ 550 ₽. Итого 29 000 ₽ в месяц, около 350 000 ₽ в год.

350 000 ₽ в год — это потолок экономии на самой сортировке, и снять его целиком нельзя: подтверждение карточки человеком остается. Если вы считаете окупаемость только по этой строке, проект не окупится. Считать надо две следующие.

Формула вторая, переадресация. Та самая доля из журнала задач: перенаправленные и возвращенные автору поручения, деленные на общее число задач за квартал. Считается она в календарных сутках срока, минуты делопроизводителя тут уже ничего не решают.

Формула третья, просрочка. Возьмите число просроченных задач за квартал и умножьте на цену одной просрочки в вашем бизнесе: штраф по договору, повторный запрос от контролера, сорванный срок подачи. У кого-то это ноль, у кого-то шестизначное число. Именно третья формула обычно и оплачивает проект, а первые две только уточняют картину.

Классификация входящих — самый окупаемый первый шаг

Из четырех узлов начинать надо с самого скучного. Три причины, и все три инженерные.

Метрика простая до неприличия. Доля писем, у которых предложенный вид документа и корреспондент приняты делопроизводителем без правок. Одно число, снимается из журнала автоматически, спорить о методике приемки не о чем — в проектах с ИИ это редкость.

Обучающая выборка уже оплачена. Журнал регистрации за прошлый год — это тысячи размеченных вручную примеров: текст письма и поставленный человеком вид документа. Никто не собирал их специально, они накопились сами. Достаточно выгрузки и пары дней на чистку.

Цена ошибки почти нулевая. Модель ошиблась в виде документа — делопроизводитель поменял значение в выпадающем списке до сохранения карточки. Сравните с ошибкой в проведенном документе учетной базы, которая уже разошлась по остаткам и отчетам.

Что конкретно предсказывается на этом шаге: вид документа (письмо, претензия, договор, служебная записка, заявление, счет), корреспондент из справочника, тематика или категория, признак срочности и отдельный класс «это вообще не документ» — автоответы, рассылки, уведомления сервисов. Последний класс недооценивают, а он снимает заметную часть потока еще до регистрации.

Одна грабля тут стоит отдельного абзаца. Выборку из журнала нельзя размечать по ФИО исполнителя: за год люди увольняются, подразделения переезжают, половина меток протухает. Метку ставят на подразделение или роль, а конкретного человека под ролью подставляет штатный механизм платформы.

Определение ответственного: лестница из трех ключей

Тут важно сказать вещь, невыгодную подрядчику. Значительная часть маршрутизации в 1С:Документообороте закрывается штатными средствами без всякого машинного обучения: условия маршрутизации и автоподстановки исполнителя в шаблоне процесса умеют выбирать адресата по реквизитам карточки. Если у вас эти механизмы не настроены — начните с них, это дешевле любого пилота.

Рабочая схема выглядит как лестница, где каждая ступень слабее и дороже предыдущей.

1. Реквизит карточки. Контрагент известен, у него в справочнике заполнен ответственный менеджер. Договор указан — есть куратор договора. Точное правило, детерминированный результат, штатные условия маршрутизации.
2. История переписки. Кому уходили письма от этого корреспондента по этой теме за последний год. Данные лежат в журнале задач, модель тут считает статистику, понимать текст ей еще не требуется.
3. Смысл текста. Корреспондент новый, тема на стыке подразделений, в письме три вопроса к трем службам. Вот здесь без модели никак, и здесь же она чаще всего промахивается.

На третьей ступени обязателен порог уверенности. Ниже порога система не угадывает: она показывает делопроизводителю трех кандидатов с формулировкой основания — «похоже на обращения, которые за год уходили в юридический отдел». Выбор человека возвращается в обучающую выборку, и через месяц третья ступень срабатывает заметно чаще, чем в первый день.

Маршрут — это еще срок и гриф

Адресат — половина решения. Вторая половина: какой шаблон процесса запускается, какой срок ставится и кому документ вообще можно показывать.

В 1С:Документообороте вид документа тянет за собой шаблон процесса, нумератор, набор дополнительных реквизитов и типовой срок. Поэтому ошибка в виде документа дороже, чем кажется на первый взгляд: перепутали претензию с обычным письмом — получили другой маршрут и другой срок.

Отдельная история — доступ. Заявление сотрудника со сканом паспорта в приложении, кадровые документы, коммерческие условия договоров. Такие вложения не уезжают в публичные облака: это требование 152-ФЗ. Классификатор, работающий на своем железе, тут перестает быть вопросом вкуса.

Грабли этого узла, собранные по живым конфигурациям:

• Суть письма во вложении. В теле «во вложении наша претензия», в файле — три страницы текста. Классификатор, читающий только тело, даст мусор.
• Один конверт, несколько документов. Акт, счет и сопроводительное письмо приходят вместе, а регистрируются по-разному.
• Цепочка пересылок. Последнее сообщение состоит из фразы «см. ниже», а под ним двадцать килобайт цитирования. Цитаты режутся до классификации, иначе модель уверенно определит вид документа по переписке трехмесячной давности.
• Дубли по трем каналам. Один документ приходит по ЭДО, почтой и бумагой с курьером. Дедуп строится по номеру, дате и корреспонденту; повторное нажатие кнопки тут ловится только заодно.
• Скан без текстового слоя. Для классификатора это пустой документ, и распознавание становится обязательной ступенью работ.

Согласование: где модель полезна и где ее не пускают

Согласование — самый заметный процесс в системе и самый деликатный. Модель работает на подготовительной части, до того как кто-то ставит визу.

• Сверка проекта договора с вашим шаблоном. Что изменено относительно типовой формы, какие пункты пропали, какие условия оплаты и ответственности отличаются от принятых. Механика разбора и поиска рисков в договорах — в отдельной статье про ИИ-юриста без утечки в чужое облако.
• Комплектность пакета. В карточке должны лежать протокол разногласий, спецификация и доверенность подписанта. Проверка формальная, и место ей до запуска процесса: на третьем круге такая находка стоит недели.
• Сводка изменений между версиями. Согласующий получает список того, что поменялось со второй редакции, вместо двух файлов и предложения сравнить самому.
• Подсказка маршрута согласования. Сумма договора и вид предмета определяют состав согласующих. Правило пишется штатно, модель нужна только там, где предмет договора приходится понимать из текста.

Виза при этом остается за человеком. Всегда. Это не осторожность подрядчика, это юридическая конструкция: согласование — акт воли конкретного сотрудника, и делегировать его алгоритму нечем.

Контроль сроков и эскалация

Самый недооцененный узел. Срок в документообороте берется из трех источников, и они конфликтуют между собой.

1. Регламент. Виду документа сопоставлен нормативный срок. Штатный механизм, работает без всякого ИИ, если регламент существует.
2. Текст документа. «Просим предоставить ответ в течение десяти рабочих дней с момента получения». Вот здесь модель полезна: она находит формулировку и подсвечивает ее делопроизводителю.
3. Договор. Срок реакции зафиксирован в разделе о претензиях и отличается от общего регламента.

Ключевое инженерное правило: модель достает формулировку, а дату ставит правило. Фраза «в течение 30 дней» содержит две неопределенности — календарные или рабочие, с даты получения или с даты регистрации. Пусть их решает регламент компании один раз, вместо языковой модели на каждом документе.

Эскалация строится лестницей и настраивается вместе с канцелярией: за два дня до срока — напоминание исполнителю, в день срока — уведомление руководителю подразделения, после — строка в утренней сводке для секретариата. Тонкость в том, что уведомления обесцениваются от частоты. Если система пишет каждому по восемь писем в день, ее отключат через неделю, и никакая точность модели этого не спасет.

Метрика узла тоже из двух чисел: доля задач, закрытых в срок, и — это важнее — число задач, у которых срок не проставлен вообще. Второе число в первый месяц обычно неприятно удивляет.

Поиск по архиву: чем он отличается от полнотекстового

Запрос «какой у нас срок оплаты в договоре с этим поставщиком» полнотекстовый поиск не обрабатывает в принципе. Он вернет список документов, где встречаются слова «срок» и «оплата», а дальше человек читает.

Две нижние строки — те, на которых проваливаются внедрения. Права доступа: векторный индекс сам по себе ничего не знает про рабочие группы и грифы 1С:Документооборота, поэтому фильтрация делается на этапе отбора фрагментов, до того как модель составила ответ. Иначе рядовой сотрудник получит цитату из документа, который ему в системе не показывают.

Отказ при отсутствии данных настраивается так же жестко: ответ строится исключительно по найденным фрагментам, каждый тезис сопровождается ссылкой на документ и страницу, а при пустом поиске выдается «в архиве не найдено». Механика ответа строго по источникам разобрана в статье про галлюцинации LLM в бизнесе, а почему поиск обязан отвечать ссылкой на конкретный пункт — в разборе RAG по нормативке предприятия. Почему сотрудники не находят то, что в архиве точно есть, и как это чинится нарезкой документов, — в статье про семантический поиск по базе знаний.

По деньгам: поиск по архиву — самостоятельный проект со своей экономикой, он собирается на закрытом контуре и стоит от 700 000 ₽ за пилот в 4–6 недель, состав работ описан на странице локального RAG. Поэтому его и не ставят первым: классификация входящих дает измеримый результат раньше и дешевле.

Что нельзя отдавать автоматике

Список короткий и не обсуждается на внедрении. Он пишется в техническое задание до начала работ, чтобы через полгода никому не пришло в голову «включить автоматический режим на выходные».

Общий принцип по всей системе один: машина готовит и предлагает, человек подтверждает одним кликом. Ровно так же, как документ в учетной базе создается черновиком, а проведение остается за бухгалтером.

Как это встраивается в базу

Типовую конфигурацию 1С:Документооборота не правят: снятие с поддержки превращает каждое обновление в отдельный проект. Модель живет отдельным сервисом, обмен идет штатными интерфейсами платформы — OData, HTTP-сервис в расширении или промежуточная очередь. Способы и их цена сравниваются в разборе как встроить ИИ в 1С и не трогать конфигурацию.

Результат работы модели кладется в дополнительные реквизиты карточки: предполагаемый вид документа, предполагаемый исполнитель, найденная в тексте формулировка срока и уверенность по каждому полю. Делопроизводитель видит заполненную форму с подсвеченными предположениями и подтверждает или правит. Никаких скрытых автоматических действий в фоне — все, что сделала машина, должно быть видно на форме до сохранения.

Про нагрузку. Классификация одного письма — это доли секунды и запрос к сервису в момент регистрации. Индексация архива под поиск по смыслу — тяжелая пакетная работа, ее ставят регламентным заданием на ночь и никогда не запускают в рабочие часы поверх боевой базы.

Что мерить, чтобы понять, работает ли

Пять чисел. Все пять снимаются из журналов системы, все пять надо замерить до старта работ — иначе сравнивать будет не с чем.

1. Доля входящих, у которых вид документа и корреспондент приняты без правок.
2. Доля задач, ушедших верному исполнителю с первого раза, без переадресации.
3. Медиана времени от поступления документа до первой резолюции.
4. Доля задач, закрытых в срок, и отдельно — число задач без проставленного срока.
5. Доля вопросов к архиву, закрытых поиском, без обращения к живому человеку.

Замер до старта — это одна выгрузка и полдня работы. Проекты, где его не сделали, через полгода упираются в спор «стало лучше или просто привыкли».

Когда не надо

Пять ситуаций, в которых честный ответ — оставьте как есть.

• Меньше сотни входящих в месяц. Подставьте свой поток в первую формулу: экономия окажется меньше стоимости сопровождения. Секретарь справляется, тема закрыта.
• Регламента нет. Если сроки и ответственные нигде не описаны, модели неоткуда взять правильный ответ, а вам — метрику приемки. Сначала регламент, потом автоматизация. Порядок обратный обычно заканчивается дорогим разочарованием.
• Поток однороден. Три вида документов и два адресата раскладываются штатными условиями маршрутизации за неделю работы администратора. Модель тут будет дорогим способом сделать то же самое.
• Архив в сканах без текстового слоя. Поиск по смыслу поверх картинок не работает. Сначала распознавание всего массива, и это отдельная строка бюджета, которую надо увидеть до подписания договора.
• Ожидание, что система будет подписывать сама. Если заказчик считает целью убрать человека с визы, лучше разойтись на берегу. Такой проект не сдается ни по одной метрике.

С чего начать на этой неделе

Шесть пунктов, которые займут день и дадут почти готовое техническое задание.

1. Выгрузите журнал регистрации за год и посчитайте распределение по видам документов. Если восемьдесят процентов потока — три вида, начинайте с них.
2. Посчитайте долю задач, которые переадресовывались или возвращались. Это ваша базовая линия по второму узлу.
3. Замерьте секундомером обработку десяти входящих от открытия письма до сохранения карточки. Средняя цифра важнее любых нормативов.
4. Проверьте у администратора, настроены ли штатные условия маршрутизации и автоподстановки. Возможно, половина задачи решается там.
5. Посмотрите, какая доля архива лежит сканами без текстового слоя. От нее зависит, доступен ли вам поиск по смыслу вообще.
6. Зафиксируйте письменно список действий из таблицы запретов. Один абзац в ТЗ снимает половину будущих споров.

Дальше считается бюджет. Первый процесс внутри учетной системы стоит от 250 000 ₽ и доходит до пилота за 3–5 недель — состав работ и границы описаны на странице ИИ в 1С, прикинуть вилку под свой поток можно на калькуляторе. Разговор по существу начинается с выгрузки журнала регистрации и пачки реальных входящих: по ним сразу видно, сколько классов документов у вас на самом деле и какая доля писем в принципе поддается автоматической сортировке.