Реферат: Технологии электронного документооборота
Для того чтобы в современном мире оставаться на месте, надо быстро бежать. Но скорости все увеличиваются. Что делать? Совсем не очевидно, что спасение в системе электронного документооборота, однако полезно рассмотреть типичные симптомы проблем, решению которых он поможет.
Где можно найти письмо, которое вы высылали примерно год тому назад кому-нибудь из контрагентов? Хорошо, если у вас есть секретарь, который хранит все бумаги в порядке. А если нет? Попробуйте теперь выяснить, какой объем занимает архив бумажных документов, который вы вынуждены хранить, и сколько ресурсов ежемесячно уходит на его поддержку? Или подумайте над тем, как часто вашей организации приходится терпеть плохого сотрудника только потому, что он многое знает, и передача дел новому сотруднику может привести к большим потерям?
Жизнь ставит перед организацией все новые задачи. У вас возникает ощущение, что многие люди перегружены, а другие тихо бездельничают, и при этом проблемы вскрываются только при провалах.
Другой симптом — ваши сотрудники вместе готовят какой-то контракт. Идет обсуждение с контрагентом, вносятся изменения в текст, приходится хранить несколько файлов с различными вариантами контракта. Наконец все готово, а потом выясняется, что на самом деле был подписан не последний вариант, была взята не та «рыба» и юрист контракт не читал, а партнер с некоторыми его пунктами не согласен.
Если вам знакома хотя бы одна из подобных ситуаций, то, возможно, система электронного документооборота (СЭД) — это выход. Описанные проблемы могут встретиться в государственной структуре, на промышленном предприятии и в адвокатской конторе. Попробуем описать концепцию устройства СЭД этих систем в общей информационной инфраструктуре организации. Замечу, что во всех случаях, когда идет речь о функциональности СЭД, имеется в виду некоторая абстрактная идеальная система, которая «все может». При этом — если не оговаривается иное — предполагается, что та или иная функциональность является практически стандартной, так что любая «нормальная» система электронного документооборота просто обязана ее поддерживать.
Документ в СЭД
Документ — основная единица информации, и все существование системы документооборота посвящено хранению документа, его свойств и истории его жизни, а также собственно обеспечению его жизнедеятельности.
В свое время в Microsoft ввели для всех файлов, сохраняемых своими офисными приложениями, стандартную шапку, в которой задавались бы свойства, такие, как заголовок и автор. Однако на практике эта возможность не прижилась; редкий документ содержит что-то осмысленное в разделе свойств. Не получил широкого применения и механизм сохранения различных версий документа в одном файле, реализованный в MS Office 2000. Причина проста: без системных организационных мер и единства подхода наличие частных механизмов в конкретных продуктах не дает результата. Очевидно, что такие средства, как описание атрибутов документа, сохранение его версий и т.д., должны быть поддержаны в рамках информационной среды безотносительно к типу документа и приложению, с помощью которого этот документ создан.
Документ — логическая единица. Способ его хранения зависит от того, как с ним удобнее работать. Ваш документ может состоять из текста, чертежей, рисунков и таблиц. Механизм COM позволяет организовать в одном файле подобие файловой системы, состоящей из аналогов папок и файлов. Этот механизм используется, например, в Word для того, чтобы обеспечить возможность вставки в текст объектов, созданных другими приложениями. Но это не всегда удобно; проще и практичнее хранить все части документа в отдельных файлах, каждый из которых редактируется своей программой. В большинстве СЭД отдельный документ может физически состоять из набора файлов.
Жизненный цикл документа в СЭД
Рождение
В один прекрасный день на свет появляется новый документ. Этот праздничный для документа день в современных системах хранения фиксируется и хранится, однако в стихии обычных файловых систем можно легко потерять предысторию файла. Достаточно, например, просто переписать на его место новый файл с тем же именем, и никто уже не вспомнит о предшественнике, не говоря уже о том, что файл, полученный из Сети, вообще не имеет «ни рода ни племени»: датой его создания всегда будет момент, когда он оказался на жестком диске вашего компьютера. В СЭД документ не может возникнуть, если у него нет «паспорта» — карточки учета, которая может быть разной для различных типов документов: документ нельзя просто так удалить, переименовать или переписать поверх. Все эти действия протоколируются, их следы останутся. В случае необходимости, система сохранит все предыдущие варианты и даже удаленные документы. Все действия, которые могут быть проделаны над документами, определяются правами, которые даны пользователям, что позволяет задать стратегию работы с документами.
Становление
Любой документ непременно проходит этап своей жизни, который называется «черновиком» — неокрепший документ в этот период переходит из рук в руки, его меняют и переделывают. Качество результирующего документа во многом зависит от того, насколько успешно и организованно он прошел через эту «черную» полосу своей жизни. В СЭД для организации коллективной работы над документом применяется техника блокировки редактируемых документов («check-out, check-in»). Система берет на себя заботу о том, чтобы в каждый момент документ мог редактировать только один человек. Благодаря этому механизму исключается возможность того, что два сотрудника создадут у себя две локальные копии документа и одновременно внесут в него изменения. Когда в СЭД один из сотрудников забирает документ для редактирования, остальные увидят это и не смогут изменить документ до тех пор, пока первый не вернул его обратно. При этом возвращенному документу автоматически присваивается новый номер подверсии. Прежняя подверсия документа сохраняется, ее можно открыть, посмотреть и редактировать. Все действия всех участников процесса документируются, поэтому никакой путаницы не возникнет.
Публикация
Это день, ради которого документ создавался и доводился до ума. Публикация — это момент, после которого документ «умирает». Благодаря наличию механизма публикации вы можете быть уверены, что всегда будете иметь в электронном виде в точности то же самое, что было, например, подписано, или отправлено в печать, или выслано партнеру. А что если потребовалось что-то изменить в документе после публикации? Для этого на основе опубликованной версии создается новый вариант документа и начинается новый жизненный цикл. В различных системах эта функция поддержана по-разному. Где-то создается полностью новый документ, а где-то — просто новая версия.
Архивирование
После публикации документ отправляется в электронный архив, где ему предстоит пробыть столько времени, сколько это предусмотрено распорядком вашей организации. Есть документы, которые хранятся вечно. Есть документы, которые нужно хранить несколько дней. Создание архива — задача непростая, зависящая от потребностей организации. Например, документы, к которым часто обращаются, нужно хранить на быстрых носителях, а неактуальные документы, которые редко используются, можно положить на менее дорогие, но медленные носители. Для решения таких задач применяются технологии управления иерархическим хранением HSM (Hierarchical Storage Management), которые создают из всевозможных разнородных средств хранения «виртуальную файловую систему» сколь угодно большого размера, при этом управляя переносом информации с одного носителя на другой. Базовые средства HSM были встроены в Windows 2000, однако существуют и другие технологии, обеспечивающие более сложную и эффективную функциональность. Таковыми являются, например, продукты серии DiskXtender компании Legato Systems, Tivoli Storage Manager, Veritas Storage Migrator и др.
Поддержка жизненного цикла в различных СЭД
Практически все современные системы электронного документооборота поддерживают все этапы жизненного цикла документа. Вопрос только в том, насколько полна эта поддержка. Перечислять СЭД, в которых та или иная функциональность не поддержана, задача неблагодарная: к моменту появления этой статьи может выйти новая версия, где эта функция уже имеется. Часть систем не поддерживает механизм блокировки редактируемых документов, что делает коллективную работу с документами невозможной. Есть системы, ориентированные на делопроизводство, и в них не реализовано эффективное хранение документов, а актуально выполнение всех процедур работы с документами, регламентированных существующими нормами. А сами документы могут лежать в папках в шкафу. Некоторые системы ориентированы на эффективную поддержку движения электронных документов внутри структуры, но при этом не имеют собственного электронного архива — хранилище, реализованное в этих системах, предназначено только для оперативного хранения документов в процессе их жизненного цикла. После опубликования документы выходят из системы и возвращаются в типовую для них среду хранения, например, в файловую систему. К такой системе можно «пристыковать» электронный архив, где сохраняется документ вместе с его историей и сопроводительной карточкой. Например, компания «Электронные Офисные Системы» предлагает состыковать свой продукт «Дело» с электронным архивом, созданным компанией на основе сервера «Кодекс-Intranet/Internet». Тот же самый сервер компании «Кодекс» применяет и компания «Гранит-Центр» в качестве электронного архива к своей системе «ГранДок». Прежние версии обеих систем поставлялись без электронного архива.
Компоненты СЭД
Все СЭД содержат обязательные типовые компоненты: хранилище карточек (атрибутов) документов; хранилище документов; компоненты, осуществляющие бизнес-логику системы.
Хранилище атрибутов документов
Хранилище атрибутов документов предназначено для хранения «карточки» — набора полей, характеризующих документ. Обычно в СЭД имеется понятие типа документов (например, договор, спецификация, письмо и т.д.) и для каждого типа заводится своя собственная карточка. Карточки разных типов имеют обязательные поля, общие для всех документов, и специальные поля, относящиеся к документам данного типа. Например, общими полями может быть уникальный номер документа, его название, автор, дата создания. При этом документы типа «договор» могут содержать такие поля, как дата подписания, срок действия, сумма договора. Типы документов, в свою очередь, могут иметь подтипы, имеющие общий набор полей, который они наследуют от основного типа, и при этом дополнительные поля, уникальные для подтипа. Наиболее развитая система управления документами может поддерживать большую вложенность таких подтипов. Типизация документов, выстраивание их иерархии, и проектирование карточек для них является одним из наиболее важных этапов в процессе внедрения СЭД.
Кроме понятия типа документов, возможно присваивание документам категорий, причем один документ может принадлежать одновременно к нескольким категориям. Категории могут быть выстроены в дерево категорий. Например, можно иметь категорию «Юридические документы» с подкатегориями «Законы», «Договоры», «Приказы» и т.д. При этом можно иметь параллельную структуру по отделам, например, категорию «Документы отдела продаж», а в ней подкатегории «Договоры на продажу», «Счета» и т.д. Договор на продажу может быть одновременно отнесен к подкатегориям «Договоры» и «Договоры на продажу», относящимся к разным ветвям в иерархии категорий. Таким образом, появляется возможность поиска документа в таком дереве на основе его классификации, причем один и тот же физический документ может встречаться любое число раз в разных узлах этой иерархии.
Для организации хранилища карточек возможны три варианта решения: использование собственного хранилища, стандартной СУБД или средств среды, на основе которой построена СУБД.
Собственное хранилище атрибутов документов позволяет оптимизировать его под задачу хранения карточек, гибко реализовать функции создания сложных карточек (имеющих, например, большую вложенность типов), а также использовать эффективные алгоритмы поиска информации в карточках. К системам, имеющим собственное хранилище, относятся, например, Documentum, «Евфрат» компании Cognitive Technologies и «Гарант-Офис» компании «Гарант Интернейшнл». Очевидным недостатком такого подхода является невозможность использовать стандартные ресурсы имеющейся информационной среды, а также зависимость критически важной информации от поставщика СЭД. В случае, если вы используете стандартную СУБД, всегда есть возможность миграции данных на СУБД от другого поставщика. Здесь же выбор жестче — придется отказаться от использования конкретной СЭД вообще, а миграция данных из одной СЭД в другую на порядок сложнее, чем в случае СУБД.
При использовании стандартных СУБД для хранения документов данная проблема решается. К такого рода системам относятся, например, системы «Дело» от ЭОС, «1С:Архив» и DocsFusion компании Hummingbird. Однако такой подход имеет свои слабые стороны — реляционная модель, реализованная в большинстве СУБД, не удобна для модели данных, используемой в СЭД. Достаточно сложно обеспечить необходимую гибкость при создании карточек документов, особенно, если нужна сложная структура. Разработчики СЭД при этом оказываются перед дилеммой: разработать простую, но эффективную структуру хранения данных, при этом отказаться от гибкости при создании карточек, либо иметь громоздкую структуру, которая обеспечивает необходимую гибкость за счет эффективности, прозрачности и надежности работы системы. Вторая неприятная проблема состоит в том, что при использовании внешней СУБД возникают некоторые трудности как при миграции с одной версии СЭД на другую, так и при переходе с одной версии СУБД на другую. Чаще всего такая ситуация приводит к определенному консерватизму пользователей в вопросе перехода на новые версии.
Если СЭД построена на основе какой-либо информационной среды, то грех не воспользоваться ее ресурсами. Большинство систем такого типа, популярных в России, построено на основе Lotus Notes/Domino. Это позволяет использовать все механизмы, заложенные в эту среду, в том числе средства резервного копирования, репликации, поиска и т.д. Проблемы такого подхода лежат в самой необходимости наличия определенной среды для работы системы управления документами, а также в тех ограничениях, которые накладывает конкретная среда на структуру ее баз данных.
--> ЧИТАТЬ ПОЛНОСТЬЮ <--