Жизненный цикл электронного документа. Создание и жизненный цикл документа в сэд

• Recovery Mode

Несмотря на кажущуюся очевидность утверждения «главный компонент приложения на базе СЭД - документ, а то, что оно автоматизирует – его «оборот», на практике оказывается, что под документом в приложениях могут иметься в виду самые различные сущности. Зависит это от типа документа и характера его «оборота», т.е. жизненного цикла обработки. Docsvision обеспечивает механизмы для реализации таких объектов. Связано это с тем, что даже для самых типовых приложений СЭД (например, для автоматизации задач классического делопроизводства) нам было необходимо моделировать в системе документ, который описывается очень сложной структурой данных и сложным жизненным циклом. Возможность моделировать такие сложные сущности как документ в делопроизводстве и позволила нам приобрести достаточную универсальность в реализации приложений для обработки документов различной природы. Держа в голове соображения, высказанные в , попробуем описать модель сущности, которую мы называем словом «документ».

Информация в документе

Документ – прежде всего, носитель информации. Какая информация может содержаться в документе СЭД?

Неструктурированная информация

– разного рода файлы. При этом реальный документ в приложении СЭД может содержать:

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

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

Структурированная информация

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

Итак, из чего состоит структурированная часть документа.

• набор атрибутов стандартных типов (строка, число, дата, время)
• атрибуты перечисления (простые справочники) – для различных типов документов атрибуты могут быть заполнены предопределенными значениями различных типов (вид договора, уровень доступа и пр.).
• атрибуты, заполняемые из справочников, в отличие от перечислений, - это могут быть сложноорганизованные справочники (например, сотрудников, контрагентов, номенклатуры дел или товарных позиций и пр.). С одной записью справочника может быть связано несколько атрибутов документа. Например, для конкретного контрагента в документе могут сохранятся такие атрибуты как ФИО, юр. адрес, телефон и пр. В зависимости от способа обработки документа справочное поле может сохранять статическое значение выбранного элемента - справочника или ссылку, которая будет восстанавливать значение при каждом открытии документа, а, возможно, и то и другое.
• атрибуты, специфичные для конкретной системы обработки документов. Так, например, для Docsvision - это такие атрибуты как ссылка на связанный документ, категория документа, ссылка на папку, в которой хранятся документы, номер документа, ссылка на задание, которое создано по документу и пр. Заполнение подобных полей требует определённой логики обработки в зависимости от типа атрибута.

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

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

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

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

Системная Информация – используется приложением для выполнения различных сервисных функций и для реализации функций приложений, скрытых от глаз пользователя. К такой информации в системе Docsvision относятся:

• Время последнего изменения данных документа
• Информация о правах доступа к документу
• Наличие блокировки документа или отдельных файлов (Check-in/check-out контроль)
• Этап жизненного цикла обработки документа (состояние документа)

Как видим, документ в системе документооборота представляет собой сложный информационный объект.

В Docsvision есть несколько возможностей конструировать информационную структуру и визуальный интерфейс формы документов. Низкоуровневый визуальный инструмент Менеджер карточек (CardEditor) позволяет создавать новые типы документов, описывать их информационную структуру и определять ограничение на значения полей. При использовании данного инструмента программный компонент, реализующий интерфейс документа, разрабатывается на любом языке программирования с использованием API платформы Docsvision.

Рисунок 1. Низкоуровневый инструмент CardEditor позволяет описывать информационную структуру документов.

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

Рисунок 2. Высокоуровневый инструмент «Конструктор карточек» позволяет описывать информационную структуру документов и ее интерфейс.

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

Жизненный цикл документа

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

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

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

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


Рисунок 3. Инструмент «Конструктор состояний» позволяет описывать жизненный цикл документа.

Замечание! Жизненный цикл документа описывает не процесс его обработки, а изменение документа в процессе его обработки. Обычно в ECM/BPM-системах реализуются две подсистемы – управления жизненным циклом документов (Life Cycle) и бизнес-процессами их обработки (Workflow).

Бизнес-логика обработки документа, операции по обработке документа

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

Однако большое количество сценариев обработки бизнес-логики документа невозможно заранее предугадать. Для их реализации документ Docsvision поддерживает возможность программных расширений. Для этого можно использовать язык #C и специализированное API для доступа и управления данными документа. Программа обработки может быть связана с любым событием, происходящим с документом – его открытием, модификацией поля или файла.


Рисунок 4. Конструктор карточек позволяет создавать различные программные сценарии для реализации расширенной логики обработки документа.

Особая группа логики обработки информации в документе связана с синхронизацией данных из полей содержимого файла (например, ячейки Excel или поля Word) документа и его атрибутами. Для этого в Docsvision реализован специальный инструмент разметки офисных документов.

В следующем разделе мы расскажем про средства оптимизации интерфейса документа для конкретного сценария использования и ролевой модели Docsvision.

Жизненный цикл документа состоит из двух основных стадий:

1. Стадия разработки документа, которая может включать:

· собственно разработка содержания документа;

· оформление документа;

· утверждение документа.

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

· активный доступ;

архивный документ: краткосрочного хранения; долгосрочного хранения;

· уничтожение документа.

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

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

Электронный архив предприятия - это комплекс программного и аппаратного обеспечения, предназначенный для решения следующих задач:

· Организация хранения электронных документов.

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

· Организация учета бумажных и микрографических документов.

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

· Организация поиска документов.

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

· Поддержка защиты документов от несанкционированного доступа и аудита работы.

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

полный контроль над документом;

право редактировать, но не уничтожать документ;

право создавать новые версии документа, но не редактировать его;

право аннотировать документ, но не редактировать и не создавать новые версии;

право доступа к карточке, но не к содержимому документа;

полное отсутствие прав доступа к документу;

· Поддержка просмотра документов без загрузки приложений, которые порождают документ.

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

· Поддержка аннотирования документа.

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

· Поддержка коллективной работы с документом.

Выражается в поддержке целостности документов, для этого должны быть реализованы библиотечные функции выписки и возврата документов на/c редактирования, что предотвращает одновременное редактирование одного документа несколькими пользователями, устраняя тем самым возможные конфликты. Для того чтобы позволить в рамках одного документа работать одновременно нескольким пользователям, вводится понятие версии и подверсии документа - один документ может содержать несколько версий, а каждая версия - несколько подверсий. Кроме того, в рамках одного документа и одной версии (подверсии) документа может существовать несколько представлений документов (в разных форматах).

· Поддержка составных документов.

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

Где можно найти письмо, которое вы высылали примерно год тому назад кому-нибудь из контрагентов? Хорошо, если у вас есть секретарь, который хранит все бумаги в порядке. А если нет? Попробуйте теперь выяснить, какой объем занимает архив бумажных документов, который вы вынуждены хранить, и сколько ресурсов ежемесячно уходит на его поддержку? Или подумайте над тем, как часто вашей организации приходится терпеть плохого сотрудника только потому, что он многое знает, и передача дел новому сотруднику может привести к большим потерям?

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

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

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

Документ в СЭД

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

В свое время в 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. Это позволяет использовать все механизмы, заложенные в эту среду, в том числе средства резервного копирования, репликации, поиска и т.д. Проблемы такого подхода лежат в самой необходимости наличия определенной среды для работы системы управления документами, а также в тех ограничениях, которые накладывает конкретная среда на структуру ее баз данных.

Хранилище самих документов

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

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

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

Системы, имеющие свое собственное хранилище файлов или использующие хранилище среды, на основе которой построены (например, Lotus Notes/Domino или Microsoft Exchange), могут гарантировать более эффективное управление доступом к документам и более надежное решение проблемы разграничения доступа. Так устроены, например, Documentum и системы на основе Lotus Notes («БОСС-Референт», CompanyMedia). Но при этом возникают вопросы, связанные с целостностью данных, наличием эффективных средств резервного копирования и интеграцией со средствами архивного хранения на медленных носителях. В большинстве систем они так или иначе решены, однако можно пользоваться только инструментами, доступными в самой системе, в то время как в случае файлового хранения вы всегда имеете выбор.

Бизнес-уровень

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

• Управление документами в хранилище. Включает процедуры добавления и изъятия документов, сохранения версий, передачи на хранение в архив, поддержания архива и т.д.
• Поиск документов. Состоит из поиска по атрибутам, визуального поиска по различным деревьям, в которые уложены документы, поиска по полному тексту, смыслового поиска и т.д.
• Маршрутизация и контроль исполнения. Обеспечивает доставку документов в рамках бизнес-процедур в организации. Собственно, от этой функциональности и пошел термин "электронный документооборот". Маршруты документов могут быть гибкими и жесткими. В случае гибкой маршрутизации следующий получатель документа определяется сотрудником, в ведении которого документ находится в данный момент. В случае жесткой маршрутизации путь прохождения документов определяется заранее на основе некоторой логики. В реальной жизни применяется "смесь" из этих двух подходов: для одних документов и структур в организации уместнее жесткая маршрутизация, для других гибкая. Функция маршрутизации присутствует не во всех СЭД. Обычно, чтобы не путаться, системы без средств маршрутизации называют электронными архивами. Контроль исполнения является неотъемлемой частью маршрутизации. Если у документа "появились ноги", то нужен контроль того, куда он идет и где сейчас находится. Фактически, маршрут определяется в терминах пути прохождения и временных интервалов на исполнение документа каждым из участников процесса прохождения. Под исполнением документа подразумевается выполнение действия, связанного с документом, каждым из участников в рамках его должностных полномочий. Проще говоря, кому-то нужно его просто прочитать, а кто-то, возможно, будет уволен.
• Отчеты. Служат аналогом конторских журналов учета документов. Используя различные отчеты, можно посмотреть, например, общее время, потраченное сотрудниками на работу над конкретным документом, скорость прохождения документов по подразделениям и т.д. Отчеты - отличный материал для принятия управленческих решений.
• Администрирование. Поддержика работы самой системы, настройки ее параметров и т. д.

«Правильная» СЭД

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

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

Место СЭД в информационной системе предприятия

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

СЭД и другие

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

В некоторых случаях интеграция этих систем еще более тесная - СЭД может служить интегрирующим транспортом для передачи документов между системами, которые их порождают, и системами, которые их потребляют, в случае, когда прямая связь на уровне структурированных данных между этими системами не нужна. Предположим, предприятие имеет системы CRM и ERP, причем требуется, чтобы в CRM фиксировались ежеквартальные отчеты из ERP о поставках товара конкретному клиенту, дополненные, возможно, комментариями экспертов. Понятно, что такие отчеты удобнее всего хранить в СЭД. Благодаря интеграции ERP и СЭД документ будет автоматически создан и сохранен. Благодаря интеграции СЭД и CRM возможно автоматическое прикрепление документа к карточке конкретного клиента. И все эти операции могут происходить автоматически. (Подчеркнем, что приведенный пример является чисто умозрительным и на самом деле может не иметь практического смысла; интеграция любых информационных систем имеет смысл только тогда, когда четко понятна ее цель.)

СЭД и управление знаниями

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

Тенденции

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

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

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

Арам Пахчанян ([email protected]) - вице-президент по корпоративным проектам компании ABBYY Software House (Москва).

Типовые требования к СЭД

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

Система электронного документооборота должна:

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

Продвинутые системы должны поддерживать:

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

Требования к архитектуре:

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

Требования к открытости и интеграции с другими системами:

• интеграция со средствами потокового ввода документов;
• интеграция с офисными приложениями;
• интеграция с электронной почтой;
• наличие развитого программного интерфейса (API);
• интеграция со стандартными службами каталогов (к примеру, LDAP) для ведения и синхронизации списка пользователей системы;
• возможность адаптации пользовательского интерфейса под конкретные задачи;
• возможность дополнения системы собственными специализированными компонентами;

В случае использования внешней базы данных для хранения атрибутов документов необходимо наличие подробного описания структуры данных и средств работы с разными СУБД.

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

Стандартизация в области систем управления документами в основном заключается в выработке спецификаций взаимодействия систем от различных производителей, а также внешних приложений. Стандартизируются как сами протоколы, так и форматы данных, передаваемых между системами. На данный момент наиболее популярным универсальным стандартом взаимодействия с внешними приложениями (офисными приложениями, средствами потокового ввода) стал ODMA (http://odma.info ). Этот стандарт существует с 1994 года, и его поддерживают многие производители ПО. Однако, как все универсальное, ODMA содержит определенные ограничения и всегда оказывается «запасным» вариантом взаимодействия с СЭД, когда, по какой-то причине, нет возможности реализовать более полноценную интеграцию. К примеру, несмотря на то, что начиная с версии Office 97 в продуктах Word и PowerPoint поддерживается ODMA, практически все производители СЭД поставляют специальные макросы для интеграции с MS Office.

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

1.3 Жизненный цикл документа

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

Что такое - жизненный цикл документа? Любой документ вне зависимости от его структуры или содержания проходит ряд стадий, которые в целом называются «жизненным циклом документа». Все документы проходят через пять основных этапов жизненного цикла (некоторые этапы могут повторяться, а некоторые имеют место только один раз):

1) документы создаются;

2) они рецензируются и исправляются:

3) формально или неформально утверждаются;

4) распространяются или публикуются для более широкой аудитории;

5) они выполняют свою основную функцию и попадают в архив;

6) при необходимости извлекаются из архива, а затем снова архивируются.

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

прием и первичная обработка;

предварительное рассмотрение и распределение;

регистрация документов;

направление на исполнение и исполнение, документов;

оформление и удостоверение документов; отправка.

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

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

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

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

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

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

Работа эта состоит из двух частей:

1) ввод реквизитов документа;

2) ввод образа документа.

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

Далее документу присваивается регистрационный номер. На документ накладывается резолюция, назначаются ответственные за его исполнение, прописывается срок исполнения. Выполняет выдачу резолюции ее автор резолюции. Но бывают ситуации, когда он не может (или не хочет) это делать. Тогда на плечи секретаря ложится работа по занесению в систему резолюции, выполненной автором в традиционном - «бумажном» - формате. Следующим этапом обработки документа является создание отчета о его исполнении (отметки об исполнении). Гораздо удобнее, если можно сделать не просто пометку «выполнено такого-то числа», а иметь возможность оставить комментарий, сохранить файл, который будет являться подтверждением, что документ действительно исполнен.

Данная операция может быть разбита на две части:

Отчет самого исполнителя;

Отметка руководителя о том, что результат его устраивает.

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

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

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

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

Технологий у СЭД появляется еще один серверный компонент, отвечающий за доступ к документам через Web-навигаторы. ГЛАВА 2. ПОСТРОЕНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ ООО "КСЕНОКС" 2.1 Постановка задачи Целью автоматизации документооборота организации ООО «Ксенокс» является сбор, регистрация, хранение, обработка и предоставление внутри организации и между отделами информации о клиентах и их заказах. ...

Так и средства автоматизации бизнес-процессов. DocsVision обеспечивает тесную интеграцию приложений, созданных на базе платформы, и единое пространство управления документами и процессами в организации. Основные функции DocsVision: Автоматизация управления предприятием; Поддержка процессного подхода в организации управления; Автоматизация систем менеджмента качества; Автоматизация...