Журнал о системах электронного документооборота (СЭД)
Электронные архивы

Зачем делать распознавание входящих документов?

  10 комментариев Добавить в закладки

Вопрос: В процессе работы в СЭД все входящие бумажные документы (договоры, факсы, письма) должны быть отсканированы и переведены в электронный вид. В нашей организации документы хранятся в СЭД в виде отсканированных изображений (графического файла в формате JPG или PDF) без возможности редактирования. Но есть возможность при вводе документов в систему осуществлять предварительное распознавание текста документа, после чего такой документ можно легко отредактировать. Зачем это нужно, если договор уже подписан, входящее письмо и факс получены, и в них уже нельзя вносить какие-либо изменения?

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

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

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

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

 

Источник: Журнал "Современные технологии делопроизводства и документооборота" №10 2012

Ещё материалы автора
Похожие записи
Комментарии (10)
Михаил Романов 17 сентября 2012 г. 15:16  

Не все утверждения мне представляются достаточно прозрачными. В частности:

Согласитесь, что не всегда сотрудник может знать реквизиты документа

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

Более того, с помощью полнотекстового поиска по распознанным графическим документам в результате поискового запроса можно найти все документы, в которых упоминается интересующий сотрудника вопрос.
А если он не сможет правильно составить поисковый запрос, то получит ворох "левых" документов, которые ему нужно, а значит ему все равно придется уточнять запрос (например, отбрасывать договоры).
 
Также распознавание существенно облегчит создание новых текстовых документов на основе существующего графического.
Хотелось бы увидеть конкретные примеры, для каких именно документов это имеет смысл. Если речь об уже упомянутых договорах, то что там нужно копировать из уже подписанного я не могу представить. Такие документы в 90% случаев создаются на основе некоего шаблона, но никак не скан-копии.
Валентина Писанова 17 сентября 2012 г. 15:30  
Согласитесь, что не всегда сотрудник может знать реквизиты документа (название, контрагента, дату создания и т.д.), но именно благодаря распознаванию графических документов, они станут доступны для полнотекстового поиска.
Возможно я ошибаюсь, но мне казалось, что подобные реквизиты чаще всего существуют в качестве метаданных, на которые распознавание никоим образом не влияет.
Михаил Романов 17 сентября 2012 г. 16:06  

Ну и плюс, отвечая на подобный вопрос, я бы упомянул следующие моменты:

1. Любая дополнительная операция (а особенно операция распознавания) имеет свою цену.

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

Мало того, при потоковом вводе документов фоновое автоматическое распознавание документов дас очень приличную нагрузку на инфраструктуру СЭД. Вплоть до выделения специальных серверов ТОЛЬКО на станцию распознавания.

Всегд ли это оправданно? Думаю нет.

2. Качество распознавания.

От него зависит для каких целей вы сможете использовать документ. Например, для полнотекстового поиска (который все же считается функцией вспомогательной) подойдет текст и с 10-20% ошибок (особенно если потенциальные ошибки скрадываются алгоритмом построения полнотекстового индекса).

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

3. Как хранить распознанный вариант документа?

Отдельным документом - это значительно усложняет обработку (нужно следить за согласованностью прав на оба документа, за правильностью использования имено первоисточника в Workflow, ...). И даже просто ручная работа требует учета того, что в системе хранится 2 документа, которые по сути - одно и то же в разных форматах.

Если же использовать, например, механизм версий, который предоставляют некоторые системы, то это тоже задает кучу вопросов

  • с какой именно версией работать (человеку каждый раз придется делать выбор - что не лучшим образом сказывается на производительности).
  • как отличать версии, которые ни что иное, как "история работы с документом" от версий "разные форматы"

Реально систем, в которых было именно понятие "документ в другом формате" я могу припомнить штуки две, но в обеих работать с такими документами было ничуть не удобнее, чем в остальных.

4. Помимо варианта распознавания документа до состояния "пригодно к редактированию" есть и другие, промежуточные варианты - например, сканированный документ со скрытым слоем "для поиска"

Этот вариант хоть и несколько урезан по применению, но зато решает (или частично решает) некоторые из перечисленных выше проблем.

Михаил Романов 17 сентября 2012 г. 16:22  

Валентина, по вашему замечанию:

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

- все так и обстоит.

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

Но вот на сколько такой поиск будет сравним по эффективности с поиском по реквизитам, вопрос открыт.

Валентина Писанова 18 сентября 2012 г. 07:18  
В том-то и дело, Михаил. Я немного потерялась во фразе:
Согласитесь, что не всегда сотрудник может знать реквизиты документа (название, контрагента, дату создания и т.д.), но именно благодаря распознаванию графических документов, они станут доступны для полнотекстового поиска.
Я с натяжкой соглашусь, что сотрудник может не знать реквизиты (хотя что вообще в таком случае он знает о документе?), но чем его спасёт то, что "благодаря распознаванию они станут доступны для полнотекстового поиска"? Он всё равно их не знает.
Как Вы справедливо отметили выше, в подобном случае поисковый запрос даст такую выдачу, что, как мне кажется, проще будет сперва выяснить хоть что-то более определённое об искомом документе.
Михаил Романов 18 сентября 2012 г. 14:21  
в подобном случае поисковый запрос даст такую выдачу, что, как мне кажется, проще будет сперва выяснить хоть что-то более определённое об искомом документе.
Именно. Но многие уже привыкли к поиску одной строкой (который реализуют большинство поисковых систем). И ждут подобного же механизма от СЭД.
При этом не берется в расчет, что обычно в поисковике мы ищем значимо различимую информацию. Можно вспомнить, что тот же Google по умолчанию отбрасывает схожие (!) результаты, считая их малозначимыми - а шаблонные документы схожи на 95-99%.
 
Я даже слышал от коллег (самому не довелось посмотреть) про схему хранения документов, в которой тела документов не хранились вовсе - хранились только метаданные и общий шаблон, на основе которых можно было в любой момент построить текст самого документа. В такой ситуации о полнотекстовом поиске речь вести как-то не получается...
 
Резюмирую: было бы здорово, если бы Евгений смог прокоментировать наши вопросы.
Елена Питомцева 19 сентября 2012 г. 10:41  

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

Сергей Бушмелев 19 сентября 2012 г. 13:04  

Лена высказала интересную мысль: порой значительная часть информации из входящих документов не попадает ни в одну информационную систему. Например, организация заказывает сувенирную продукцию. В учетные системы попадает только финансовая информация (итоговые суммы по всей накладной), а также часть метаданных: контрагент, дата, номер документа, номер договора и т.п. Сведения о товарных позициях могут не попасть в учетные системы, так как учет в них может вестись по более крупным аггрегациям (например, в случае с "малоценкой") или вестись только в суммовом выражении. И в метаданные скан-образа этого документа, хранимого в ECM-системе, такие данные могут не попасть. В таком случае сотруднику, чтобы найти договор или накладную, по которым поставлялись именно "красные шариковые ручки с золотым логотипом компании", нужно будет перерыть все накладные от данного поставщика (если ему вообще известен этот параметр). Возможно, просматривая скан-образы на экране, он сделает это быстрее, нежели роясь в подшивках бухгалтерских документов, но такой поиск не будет интеллектуальным, а значит, и быстрым.

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

Михаил Романов 19 сентября 2012 г. 16:47  
если мне нужно найти когда и на каких условиях мы заказывали какую-то конкретную позицию
Ну вот, один вариант, когда можно найти документ - есть.
Т.е. по перечню позиций в счетах и/или договорах.
 
Но как я и говорил ранее, он срабатывает только если документы различимы (т.е. различимы позиции в документе), а если, например, те самы "ручки шариковые Pilot" вы заказываете каждый месяц, то проще будет поднять все счета от одного контрагента (если, конечно, он был одним)
Александр Сидоренков 27 сентября 2012 г. 17:50  

Почему никто не поднимает тему собственно поиска. Есть ли на рынке системы с релевантным поиском документов? Я таких не знаю.

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

Я хочу сделать акцент на другом примере. Предположим нам нужно найти "протокол №25". Введя в строку поиска текст "протокол 25", полнотекстовый поиск нам выдаст сначала несколько сотен документов (скорее всего совсем не протоколов), в которых слово "протокол" и цифра "25" встречается чаще всего, а потом уже сам этот протокол с номером 25.

Поэтому на мой взгляд технологии поиска в СЭД отстают от технологий распознавания, но серьезных обсуждений на эту тему нет...

Сейчас обсуждают
Больше комментариев