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

К вопросу о потоковом вводе

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

Ольга Мельник

Сдерживающие и ограничивающие факторы

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

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

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

Тому есть объективные причины. Основная — дешевизна рабочей силы и безработица. «Да мы посадим сто человек, и они все сделают даже лучше!» Эта идея серьезно сдерживает автоматизацию ввода документации. Поставщики оборудования и ПО утверждают, что только внутри МКАД этот аргумент потерял актуальность, а чем от столицы дальше, тем он действенней. Но ему все сильней противостоит масштаб проблемы. Когда нужно ввести десятки тысяч документов в месяц, о ручном вводе речь уже не идет. Раньше такие объемы генерировали только государственные учреждения, но развитие сервисных бизнесов, работающих с частными лицами (банки, сотовые, телефонные и другие телекоммуникационные операторы, предприятия ЖКХ, страховые и торговые компании), сделали автоматизацию ввода более востребованной, чем раньше.

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

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

Представитель компании — дистрибьютора компьютерной техники, одного из крупнейших в стране, сообщил интересные сведения об итогах перехода в компании к автоматическому потоковому вводу платежных документов. Традиционно эта работа была ручной, но кризис заставил считать затраты на каждого человека, и самые простые бухгалтеры перестали казаться такими уж дешевыми сотрудниками. Однако оставались большие сомнения в том, что уровень автоматического распознавания не привнесет в работу слишком большого числа ошибок. Когда заменили ручной ввод платежек на сканирование и распознавание, с удивлением обнаружилось, что ошибок стало меньше. Примерно 20% документов приходится корректировать, что‑то добивать и править. «Теперь наш финансовый директор требует не останавливаться на бухгалтерии, а распространить эту практику на склады», — говорит менеджер. При этом, по его словам, наблюдается еще один, довольно общий процесс: формы общения компаний между собой унифицируются, в том числе информационный обмен с другими дистрибьюторами. Все фирмы, связанные цепочками поставок, постепенно переходят на одинаковые формы счетов и прочих массовых документов, поскольку это заметно ускоряет их обработку.

Задачи, поставленные практикой

В проектах по обработке платежных поручений, как бумажных, так и электронных, основная задача — сделать фронт-офис «легким». Каждое отделение должно становиться как можно меньше и дешевле, чтобы можно было эффективно развивать ритейловый бизнес. Логичное решение для этого — централизация обработки информации.

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

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

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

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

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

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

Проблема выбора

Ориентирами при выборе сканеров, и не только для создания архивов, могут быть следующие соображения. Если поток документов в организации менее 10—15 тыс. документов в год, поточный сканер обычно не рекомендуют. Практика показывает, что с таким объемом вполне справляются два регистратора с обычными планшетными сканерами. Если же в компании вводится 30—40—50 тыс. документов в год, то уже стоит задуматься о поточном сканировании.

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

Многофункциональные модели иногда используют не только по назначению, но даже и сверх того. Например, мощный потоковый сканер, имеющий встроенный процессор и собственное ПО, используется в небольшой турфирме как CRM, для хранения клиентской информации. Или такая же модель, будучи установлена в центре и в филиалах торговой фирмы, может применяться для рассылки и размножения распорядительной документации и обеспечивать обратную связь филиалов с центром. Показателен ответ подрядчика на вопрос, почему же эта функциональность, традиционно решаемая в СЭД, реализуется таким несколько экзотическим способом. Неужели у крупного ритейлера, о котором идет речь, нет системы работы с документами? Есть, а как же. «Но у них СЭД на FileNet, она рассчитана исключительно на обработку входящей документации. В ней обрабатываются приходные накладные, счета-фактуры и тому подобные документы. Централизованно стоят большие сканеры. Они собирают, сканируют и через FileNet обрабатывают кипы бумаг от поставщиков. В эту систему вносить изменения сложно. А мы ведь «железячники», софтом не занимаемся, для нас подключение СЭД к какому‑нибудь Oraclе — это такой темный лес… но о железе мы расскажем что угодно. Поэтому мы и предложили такое решение. Клиентам этот подход понравился, очень удобно, просто и недорого, особенно по сравнению с затратами, которые они несут сейчас на рассылку бумажных документов. С учетом всех сканеров получается в полтора раза дешевле». Проект еще не запущен в промышленную эксплуатацию, однако мысль решать традиционно софтверные задачи аппаратными способами не лишена смысла. Это, кроме всего прочего, свидетельствует и о стирании граней между разными типами решений: программным и аппаратным. Комплексность становится принципиальной характеристикой решения.

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

Обзор подготовлен по материалам круглого стола с участием вендоров СЭД, интеграторов и поставщиков сканеров, проведенного компанией Canon в рамках выставки Docflow.

Основной вопрос — технология

Хахамов Сергей,

заместитель руководителя Департамента продвижения решений и продуктов корпорации «Электронный архив»

Для нас и наших заказчиков потоковый ввод не является диковинкой, хотя, быть может, это исключение. Мы считаем, что на начальном этапе важно не просто дать инструмент и обучить заказчика, но и загрузить в систему наиболее востребованные документы, чтобы можно было начать работу с системой, а затем вселить в заказчика уверенность, что он самостоятельно справится с валом все новых и новых документов. Корпорацией «Электронный архив» создана своя уникальная индустриальная технология, позволяющая быстро и качественно выполнять все работы по оцифровке больших объемов неэлектронных документов.

Для организации центра потоковой обработки данных главное — это технология. Подбирается промышленное сканирующее оборудование, созданное на основе симбиоза высокопроизводительного, надежного и универсального сканирующего оборудования, оригинального программного обеспечения и современной вычислительной техники. В данном случае не важно, использовались ли программные продукты Cаptiva, Cofax, решения Abbyy, или программное обеспечение было специально разработано специалистами корпорации «Электронный архив» для решения задачи, поставленной клиентом. Это вопрос только функциональных возможностей и соответственно стоимости.

 

Потоковый ввод финансовых документов

Максим Галимов,

директор по перспективным исследованиям компании DIRECTUM

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

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

В-третьих, ввод и распознавание. «Правильный» сканер, кроме надежности, скорости, легкости использования, должен обладать гибкими настройками по размещению отсканированных образов в файловую систему, предоставлению их в требуемом формате. Не всегда требуется полное распознавание образа счета или накладной, но частичное распознавание нужно — для правильной группировки отдельных страниц в документы. Существуют разные способы распознавания (по чистому листу, по штрихкоду и т.п.). Часто с этим справляется драйвер сканера, специализированное ПО. Хорошо, если задачу разбиения потока можно переложить на подсистему захвата ECM‑системы.

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

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

 

Продолжение темы в эксклюзивных материалах ECM-Journal:

●  Интервью с Дмитрием Шушкиным (Abbyy) о вопросах потокового ввода

●  Взгляд на требования к потоковому вводу финансовых документов

Источник: Intelligent Enterprise, 22 декабря 2009

Ещё материалы автора
Похожие записи
Комментарии (4)
Наталья Храмцовская 22 апреля 2010 г. 13:50  

Ольга Мельник>> Если поток документов в организации менее 10—15 тыс. документов в год, поточный сканер обычно не рекомендуют. Практика показывает, что с таким объемом вполне справляются два регистратора с обычными планшетными сканерами.

Вопрос: "Обычный" планшетный сканер - это сканер с автоподачей или без? Сканер с автоподачей ещё очень далек от поточного по своим возможностям, но гораздо производительнее планшетного с ручной подачей листов :)

Станислав Ким 02 мая 2010 г. 23:31  
Позволю себе немного критики данной статьи.

Про сканирование пачки документов.

Практически все современные МФУшки имеют лоток с автоподатчиком и многим приходилось копировать и сканировать пачку документов. Другой вопрос, что потом делать с этой пачкой одностраничных документов или одним многостраничным документом? А вы пытались распознавать пачку отсканирванных платежек и СРАЗУ после этого ввести данные в финансовую систему? И данная мысль общепризнанной не стала именно по причине ее сложности. Дешевая рабочая сила и безработица тут вам не помогут. Кто хоть раз сажал хотя бы 10 человек на сканирование планшетниками каких-либо документов, знает, что в таком экстенсивном варианте высокой производительности и качаства добиться крайне сложно. Меньшие расходы размазываются на более длительные временные периоды, а в итоге получается как всегда.

OCR, ABBYY и конкуренты.

Почему в данной статье все крутится вокруг распознавания символов? Автор наверно не совсем в курсе, что такие системы потокового ввода как Cаptiva или Kofax не имеют собственного энджина OCR, а пользуются движками третьих лиц в том числе и продукцией компании ABBYY. Да и цену на данные продукты сложно назвать доступной. "Неприятный и дорогой монополизм" ABBYY существовал и будет еще некоторое время существовать не потому, что не было конкурентов

Если говорить о прямых конкурентах имеет смысл обратить внимание на такие продукты как IRIS, Omnipage или оупенсорсный Cuneiform. Какими бы умными не были распознавалки, на сегодняший они успешно справляются только с типизированными документами, т.е. такими, которые можно привести к определенным шаблонам (название документа - сверху посередине, дата — сверху слева и т.д.). Никаких рукописных букв и цифр и т.д. Указанные выше решения для интеллектуального ввода информации и системы автоматизированной обработки форм имеет смысл внедрять при больших объемах более-менее однородной документации. Унификация документов всей цепочки поставок — дело замечательное, но крайне трудно выполнимое.

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

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

О внеофисном хранении документов.

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

О сканерах.

Сложно понять о каких сканерах идет речь. Для меня «мощный потоковый сканер» - это промышленный образец со скоростью свыше 90 страниц в минуту и производительностью несколько десятков тысяч страниц в сутки. Такие сканеры обычно стартуют с ценника 10 000$ и маленькими турфирмами не закупаются в качестве офисных. Может я плохо знаю турфирмы и их предпочтения по оборудованию. Предполагаю, что использование “железа” в качестве CRM и ECM систем - не от хорошей жизни. Если пользователи идут на это, поставщикам ПО надо серьезно задуматься, что они делают не так. Может это результат разачарования в сказках о чудесном софте, который только стоит купить и все само отсканируется, распознается и уложится в систему, а потом силой мысли будет находится и выводиться в любом формате? Я встречал печальные случаи, например, когда финансовые специалисты крупной табачной компании уверовали в чудесный сканер, самостоятельно сканирующий по ночам и вносящий данные в SAP.

О цене.

«Проекты по потоковому вводу не такие уж дорогие». Это где? Зайдите на сайт госзакупок, найдите пару проектов по сканированию и посмотрите на цены. Предлагаю не вводить людей в заблуждение. Промышленное сканирование еще некоторое время останется крайне сложной и дорогой процедурой.

2 Хахамов Сергей:

Сергей, а какой уникальной индустриальной технологии, передаваемой клиентам вы говорите? Что за программное обеспечение, специально разработанное специалистами корпорации «Электронный архив»? На ваших сайтах ничего такого не нашел. Кстати, правильно пишется Kofax.

2 Максим Галимов:

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

Эпилог.

Меня на прошлой неделе остановил инспектор ГИБДД и спросил: «Куда вы так торопитесь, вас не смутило, что вы едете, а навстречу вам толпа пешеходов? Вы решили, что вы правы на несколько десятков людей — нет?» Я ответил утвердительно, на что инспектор, учитывая близость технического ВУЗа, предположил, что я преподаватель. Мы ежедневно общаемся с клиентами по телефону о вопросах сканирования и создания электронных документов. Скорее всего и мы многого не знаем, видим только одну сторону медали, не так быстро отслеживаем конкурентные решения в области промышленного сканирования. Тем не менее, я рад, что мои коллеги по цеху стали серьезно относиться к данному вопросу и как минимум обсуждать его. Думаю, бОльшая информированность конечного пользователя приведет к правильному пониманию процессов рынка. Кстати, если кто-то из коллег не поучаствовал в опросе DSS Consulting по рынку электронных архивов, призываю это сделать.

Валерий Климов 05 мая 2010 г. 18:02  

Всем доброго времени суток!

Не смог удержаться от комментария на фразу

«Проекты по потоковому вводу не такие уж дорогие». Это где?

Ваш покорный слуга в 2002 году (по темпам развития ИТ-индустрии это можно сказать "тому уж минули немалые года") был Руководителем проекта по потоковому вводу бумажных документов в российском филиале очень крупной  западной компании, которая очень скурпулезно считала "каждый рубль"

Проблема

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

2. чтобы выполнить отгрузку продукции партнеру необходимо, чтобы партнер не только заказал товар, но и оплатил счет на поставку продукцию. Кто первый оплатит, тот первым и получит.

3. Проблемным являлся этап между выпиской счета на оплату продукции и получение этого счета партнером. Т.е. проблема была не в том, что патнер долго оплачивает, или вообще "динамит" с оплатой, а в том, что логистика позволяла доставить счет партнеру с задержкой в несколько дней. К этому накидываем банковские издержки с перечислением средств...получается печальная картина. Вот этот "узел" и предстояло распутать.

Предложенное решение 

1. Отдел продаж выполняет распечатку всех счетов как и прежде (эта задача крутилась где-то на западном мэйнфрейме и поменять логику ее работы, чтобы она еще и отправляла PDF на указанный адрес не представлялось возможным - вроде как "работате и не трогайте")

2. далее распечатанная пачка счетов на оплату складывалась на сканер и сканировалась. В результате отсканированные счета анализировались - 2 или 3 поля - для того, чтобы идентифицировать партнера, и на основании полученной информации публиковались на ftp в нужной папке (была создана определенная иерархия папок для каждого партнера).

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

4. а оригинальные счета уже обычным путем оправлялись партнерам

Детали

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

2. сложности вызвали настройки модуля распознавания дабы правильно распознать некоторые символы - типа "ноль" и буква "О", цифра "1" и буква "I" и т.п.

Бюджет проекта

Собственно то, что подвигло на комментарий

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

1. закупка среднепроизводительного сканера от Fujitsu (~ 4-5K) - требования были до 100 документов в день

2. закупка ПО от Кофакс (~5K)

3. Закупка движка FineReader (не помню точно, но не более 1К)

4. и стоимость работ по настройке и адаптации решения (из 16К нужно вычесть пп 1-3)

В сухом остатке

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

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

Максим Галимов 06 мая 2010 г. 09:05  

> Не каждая СЭД (ECM-система) ... справится...

Спорить не буду :)

 

> Что такое частичное распознавание документа?

Я имел в виду (там как раз в следующих предложениях поясняется) распознавание штрих-кодовых меток для группировки листов в документы.

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