Ежедневно компании выполняют операционную и административную работу – неинтересную рутину, но без которой в действительности невозможен никакой бизнес. Крупная часть этой истории – входящий и исходящий документооборот, который может достигать тысяч бумажных копий. Чем быстрее организация сможет его систематизировать и автоматизировать бизнес-процессы, тем больше удастся сэкономить на операционной работе и устранении ошибок в будущем. 

К нам в НОРБИТ обратилась компания с запросом на разработку решения для оптимизации работы с входящей документацией. В первой части этой статьи мы расскажем, какие задачи решали на этом проекте, рассмотрим предложения со схожим функционалом, существующие на рынке, и покажем архитектуру предобученного классификатора документооборота, во второй – разберем технические аспекты этого решения.

Проблемы, которые мы решали

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

Так как документы поступают в печатном виде, сначала мы посмотрели, что есть на рынке готовых решений с OCR-функционалом (Optical Character Recognition – процесс, в рамках которого изображение текста преобразуется в машиночитаемый текстовый формат).

Yandex Vision

Это облачное CV-решение (Computer Vision, компьютерное зрение), в котором есть OCR-движок. На данный момент продукт еще разрабатывается, так что необходимого функционала идентификации получателя на основе данных здесь найдено не было. Более того, для заказчика был важен вопрос конфиденциальности, а в этом подходе данные по документам обрабатываются в облаке. 

Плюсы: облачное решение, легко развернуть, высокие вычислительные мощности обеспечат соответствующую скорость обработки документов.

1С OCR

Готовый блок 1С для определения содержимого документов. Хорошо распознает бизнес-значимые поля у стандартизованных документов. Есть много вендоров, которые готовы разработать и внедрить связанный функционал. Сама классификация при обработке «оптом» стоит приличных денег, в связи с чем тестирование и обучение могло потребовать серьезных финансовых издержек. При более подробном изучении предлагаемой функциональности мы также пришли к выводу, что определение получателя на основе текста возможно только для документов, имеющих стандартную форму, а их отправка потребует сложной разработки. Получается, что самописное решение может быть как проще в разработке, так и удобнее в использовании с существующими решениями: в планы добавилось разработать коннекторы к уже имеющимся системам документооборота.

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

ABBYY

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

Плюсы: есть как облачное решение, так и on-premise, высокое качество работы с документами, в том числе и на кириллице.

Общий минус 1С и ABBYY: нет встроенной функциональности, обеспечивающей выбор адресата входящей корреспонденции. Частично есть в 1С:ЭДО, но на момент написания статьи инструмент относился только к электронным документам.

Tesseract OCR

Довольно популярная Opensource-библиотека для распознавания текста, в том числе и на кириллице. Благодаря открытому коду есть возможность для разработки on-premise решения, без опасений за конфиденциальность данных. Упрощает интеграцию модуля с другими библиотеками и API, но при этом требуются большие инвестиции в разработку и поддержку решения.

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

Обсудив варианты с заказчиком, мы приняли решение углубиться в вариант использования Opensource-библиотеки и собрать собственный продукт, который бы помог справиться со всеми проблемами заказчика. 

Идея решения 

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

В первом приближении получились следующие схемы автоматизации процесса.

As is

Всю работу выполняет секретарь. Каждый новый шлюз – потенциальный риск влияния человеческого фактора. Учет входящих документов ведется в реестре Excel, определение получателя осуществляется через исторические совпадения.

To be

Секретарю остается только отсканировать документ и прикрепить на распознавание в классификатор, в то время как все остальные шаги выполнит алгоритм. Данные автоматически сохраняются в системе ЭДО, что позволяет развить зрелость учета документов в компании.

Сбор требований и разработка методологии

В ходе исследования процессов выявили пять основных подразделений-стейкхолдеров:

• секретариат;

• бухгалтерия;

• отдел кадров;

• юридический отдел;

• специалисты документооборота по направлениям.

Секретариат является основной точкой входа и бизнес-исполнителем, в то время как остальные четыре подразделения – получатели документации. Это и определило наши классы для распознавания алгоритмом. 

Первая гипотеза была сформулирована так: «Я как владелец сервиса распознавания документа, предоставив предобученный классификатор и возможность ручного исправления ошибок, через два месяца получу точность выбора адресата документов не менее 90%».

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

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

Но встречались и подводные камни. Например, мы исходили из концепции, что в одном скане содержится один документ, а исключения составляют не более 5% из практики, что не является критичным, как с точки зрения качества распознавания, так и для скорости работы алгоритма. После интеграции и дополнительного анализа документов, полученных в 1С, вывод получился противоположный – почти каждый присланный скан включал в себя несколько документов. Как оказалось, технически это означало, что секретарям приходит пачка документов, которую они отправляют в сканер, он «прокручивает» ее автоматически целиком и создает единый pdf-файл.

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

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

Концепция решения. Главные функциональные модули 

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

• бухгалтерия;

• юристы;

• специалисты по документообороту;

• кадры.

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

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

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

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

В процессе анализа и пробных подходов к классификации, появился механизм решения, который выражается тремя шагами-задачами:

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

• решить задачу разделения пакетов входящих документов на отдельные документы;

• определить методы, которые бы извлекали информацию из бизнес-значимых полей. 

Остановимся на каждом из них подробнее.

Задача #1. Классификация 

Такая задача могла бы быть решена SOTA-методом (state-of-the-art, передовой, инновационный), когда используется какая-либо предобученная BERT-модель (Bidirectional Encoder Representation Transformers), для русского языка и дообучается с помощью наших документов. 

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

Задача #2. Разделение пакетов входящих документов — сепарация 

Когда секретари сканируют приходящие письма, им удобно сохранить несколько документов одним файлом, а сканеры со скоростью сканирования 40-60 страниц в минуту распространены в офисном документообороте. Этот процесс не занимает много времени, секретарь не теряет концентрации и количество ошибок уменьшается. Такой подход проще и не требует отдельных инструкций для секретаря, как правильно определять границы документов. 

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

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

Задача #3. Определение бизнес-значимых полей

Одна из задач, которая стоит перед разработчиками электронного документооборота, — создать механизм эффективного заполнения специальных тегов (бизнес-полей) в структуре хранения документов. Это могут быть: названия организаций, их ИНН или ОГРН, номера счетов.  Значения представляются в виде отдельных полей, сопоставляются с другими документами. Такая задача тегирования может быть решена автоматически.

Классификатор документооборота в процессе своей работы определяет тип входящего документа, например, «договор», «дополнительное соглашение», «постановление» и т.п. А исходя из типа документа, может извлечь из него необходимые поля и сохранить их в виде структуры данных. Такую структуру данных легче обработать и представить в необходимом виде для поиска, сопоставить с UUID (Universally Unique Identifier) контрагента, зарегистрированного в системе.

Такая задача носит название «Распознавание именованных сущностей» и решается тремя способами: 

• применением набора правил, построенных на регулярных выражениях;

• с помощью библиотек обработки естественного языка и предварительно обученных моделей;

• через обучение собственной модели, если два предыдущих способа не показывают эффективности.

Примеры бизнес-полей и возможный способ поиска:

Архитектура решения

Исходя из описанного бизнес-процесса, архитектура разработанного решения состоит из следующих инфраструктурных компонентов:

В качестве основного модуля классификатора документооборота используется хранилище статусов входящих документов. Задача этого блока — хранить разнообразные данные, связанные с документами, стадиями его обработки. 

Это реализовано на основе связки ElasticSearch и MinIO (S3 хранилище). В этой связке MinIO агрегирует изображения страниц документов, а ElasticSearch — текстовую информацию и организует работу системы, реализуя хранение статусов обработки.

Разберем работу на примере. Есть метод API, который предназначен для передачи метаинформации о документе (входящих параметров: регистрационный номер письма, в котором пришел документ, и идентификационный номер документа). Эти поля необходимы для того, чтобы сопоставить документы в классификаторе и в документообороте. Документу присваивается статус «Пришедший» и под него выделяется «слот» для дальнейшей работы. 

Загрузка файлов осуществляется отдельным методом и имена файлов сопоставляются с существующим слотом в хранилище. При отсутствии ошибок документ попадает в S3 хранилище и статус меняется на «Сохранен в хранилище». Таким образом, реализован блок распознавания текста документа. 

Таким образом, мы проанализировали имеющиеся на рынке варианты аналогичных решений, изучили их плюсы и минусы, определили круг задач и разобрались с архитектурой предобученного классификатора документооборота. На этом мы завершаем первую часть статьи, а в следующей расскажем про наши тесты OCR-библиотек, выбор компонентов решения и проблемы, с которыми мы столкнулись при внедрении.