В мае прошла очередная выставка-конференция Docflow 2012. Данное мероприятие, как известно, посвящено актуальным тенденциям в автоматизации документооборота. И в текущем году такой тенденцией было названо объединение данных из разных систем автоматизации тех или иных бизнес-процессов.

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

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

Недостаточная квалификация и кадровый голод

Часто это связывают с тем, что внедрением СЭД обычно занимаются функциональные службы, отвечающие за делопроизводство. ИТ подключаются лишь потом, по ходу проекта. А часто такие проекты ведутся и вовсе без привлечения ИТ. В итоге возникают, что называется, «детские» ошибки.

На круглом столе «На ошибках учатся. Опыт решения типичных проблем при внедрении СЭД» был приведен пример того, как заказчики при внедрении EMC Documentum отказывались приобретать оборудование по спецификации, предложенной интегратором. Это мотивировалось тем, что имелись избыточные серверные мощности, вполне соответствующие минимальным системным требованиям. А ведь всем известно, даже по банальным настольным системам, что минимальные требования нужно увеличивать раза так в четыре. Ну или как минимум вдвое, если вендор более-менее честный. А когда речь идет о системе из числа «тяжелых», то разница между конфигурацией, на которой система соизволит запуститься, и той, на которой можно будет реально работать, окажется существенно больше.

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

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

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

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

Внедрение системы потокового ввода равносильно DDOS-атаке

Фразу, вынесенную в заголовок, автор этих строк услышал в кулуарах выставки. И действительно, образы документов весьма «увесисты». Играют свою роль и неоптимальные настройки процесса сканирования, и, скажем так, недоработки разработчиков ПО (например, когда для хранения образов документов используются файловые форматы со слабым сжатием). А если еще было принято решение централизовать процесс потокового ввода, разместив его подальше от столиц, где ниже стоимость аренды помещений и требования к заработной плате у персонала… Но вот о том, как будут «путешествовать» по сети образы документов и как это скажется на работе других приложений, думают уже потом. В итоге возникает та самая ситуация, которая и вынесена в заголовок (см., например: Из бумаги в цифровой поток//Intelligent Enterprise, № 3/2011).

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

Рост объемов неструктурируемой информации

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

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

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

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

Один плюс один плюс один равно…

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

Да и если удалось полностью исключить длительное хранение всяких промежуточных данных, успокаиваться рано. Очень часто в силу многих причин при импорте данных объем, который они занимают, может возрасти, скажем так, несколько больше, чем это первоначально планировалось, особенно после того как импорт проведен несколько раз. Все зависит от конкретной СУБД или корректности программного кода. А как известно, чем более сжатые сроки у проекта, тем неряшливее код и больше в нем разных ошибок. Эта проблема тоже поправима, но требует времени на решение.

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