8.4.2. Системы электронной почты
Минимальной достаточной системой, обеспечивающей маршрутизацию документов является система электронной почты, которая осуществляет параллельное распространение документов (маршрутизация отличается от распространения или рассылки тем, что маршрутизируемый документ возвращается в начало маршрута, например к инициатору, а рассылаемый документ уходит к исполнителю без контроля факта возврата). С помощью дополнительных приложений система электронной почты может обеспечивать последовательную маршрутизацию документов.
8.4.3. Свободная маршрутизация документов с контролем исполнения
Под контролем исполнения понимается следующая функциональность.
· Контроль доставки задания - инициатору выдается информация о том, что его задание достигло места назначения (исполнителя).
· Контроль прочтения задания - инициатору выдается информация о том, что с его заданием ознакомились сотрудники для которых это задание было предназначено.
· Контроль выполнения - инициатору выдается информация о том, что задание выполнено.
· Мониторинг задания - инициатор всегда может посмотреть, кто и что сейчас делает с его заданием.
· Извещение о нарушении сроков исполнения - система документооборота может известить инициатора о том, что посланное им задание просрочено конкретным сотрудником.
· История выполнения заданий.
Контроль качества исполнения означает, что, если пользователь говорит о том, что задание исполнено, это еще не означает, что оно действительно исполнено, инициатор должен проверить качество исполнения, подтвердить или нет исполнение.
Информация может выдаваться в виде изменения статуса задания в окнах входящих и исходящих заданий или в виде нового задания сформированного системой инициатору либо с помощью сообщения по электронной почте.
8.4.4. Маршрутизация документов по заранее определенным маршрутам с контролем исполнения (жесткая маршрутизация)
Маршруты могут быть более сложными, чем простые последовательные или параллельные:
· комбинированные из последовательных и параллельных элементов;
· условные, с переходами в зависимости от состояния тех или иных переменных маршрутов.
Такие маршруты становятся сложными для их задания "на лету", поэтому в этом случае используется специализированный графический редактор, позволяющий создать маршрут. Инициатор вызывает созданный и именованный маршрут и прикрепляет к нему документы - инициирует его. Система маршрутизации должна быть интегрирована с архивной системой, и реальные приложения для работы с документами не могут быть основаны только на файловой системе. И вот почему. Любой процесс маршрутизации документов - это движение одного документа, а не множества его копий, как это происходит в системах электронной почты. Посылать один документ необходимо не только по соображениям экономии пространства, но и в основном для поддержания его целостности - в процессе маршрутизации многие пользователи пытаются вносить изменения в документ. Кроме этого, было бы желательно, чтобы система маршрутизации была интегрирована с архивной системой по следующим параметрам:
· По списку пользователей и системе безопасности. Это означает, что если вы собираетесь послать кому-то документ, то адресат должен обладать соответствующим набором прав для работы с этим документом. Если прав недостаточно, то система должна попросить инициатора работы или маршрута установить соответствующие права.
· Интеграция с операцией публикования документа. Задача состоит в том, что после окончания маршрута документ, ассоциированный с маршрутом, меняет свой статус на опубликованный. В качестве примеров таких маршрутов можно привести процесс утверждения документа.
Рассмотренные возможности обеспечивают построение любой частной системы документооборота на любом предприятии в любой предметной области. Естественно, для построения частного решения можно ограничивать функционал системы в зависимости от предъявляемых заказчиком требований.
На сегодняшний день применяется два подхода к организации хранения электронных документов. Первый состоит в том, что собственно тело документов хранится в файловой системе, второй предусматривает хранение документов в реляционной или специализированной базе данных. Второй подход хотя и обладает большей степенью защиты собственно документов, но несет в себе следующих ключевых недостатков:
Как и любая область человеческой деятельности, сфера документооборота не могла избежать всеобщего веяния стандартизации и имеет свои проблемы.
Проблема 1. Архивная система должна быть интегрирована с приложениями, в которых порождаются различные электронные документы. Желательно, чтобы эта интеграция была прозрачной для пользователя, который работал бы с архивной системой напрямую, минуя обращения к файловой системе. Следовательно, диалоги операций с файловой системой должны быть заменены на диалоги работы с архивной системой. Единственным решением удовлетворить как производителей приложений, так и производителей архивный систем является выработка единого стандарта взаимодействия между системами такого класса. Этой цели достигла первая версия стандарта ODMA (Open Document Management API). На сегодняшний день данный интерфейс поддерживается следующими производителями архивных систем: PC DOCS, Saros, Novell (Soft Solutions), Watermark, Documentum и со стороны производителей приложений компаниями Corel (Corel WordPerfect Suite) и Microsoft (Office 97).
Проблема 2. Иногда предприятие использует одновременно несколько систем управления документами. В качестве примера можно привести транснациональную и многопрофильную корпорацию DuPont. В подразделениях, которые ведут разработку новых химических продуктов, исторически используют Documentum; новые подразделения остановили свой выбор на DOCS Open, как на более дешевом решении в расчете на одного пользователя. Соответственно возникает проблема, как пользователю с одного рабочего места иметь доступ к нескольким архивным серверам для поиска документов. Для обеспечения совместной работы нескольких архивных серверов предназначен стандарт ODMA версия 2. Впервые такая совместная работа серверов DOCS Open и Documentum была продемонстрирована в середине 1996 года.
Проблема 3. Аналогичная проблеме 2, но для систем класса workflow. Выработкой стандарта для совместной работы workflow-систем от различных производителей занимается некоммерческая организация WorkFlow Coalition, а выработанная ею спецификация носит название Workflow Coalition API. В середине 1996 года была показана совместная работа систем от семи производителей.
Определенные ранее направления автоматизации документооборота: поддержка фактографической информации, возможность работы с полнотекстовыми документами, поддержка регламента хождения документов, определяют трехмерное пространство свойств (рисунок 6), где по некоторой траектории движется любой программный продукт данного класса, проходя различные стадии в своем развитии.
Рисунок 6.
Модель документооборота.
Первая ось (F) характеризует уровень организации хранения фактографической информации, которая привязана к специфике конкретного рода деятельности компании или организации. Например: при закупке материальных ценностей происходит оформление товарно-сопроводительных документов (накладных, приемо-передаточных актов, приходных складских ордеров и т.д.), регистрируемых в качестве операционных документов, атрибутика которых очень важна для принятия управленческих решений. Информация из операционных документов используется при сложной аналитической и синтетической обработке, и, в частном случае, может быть получена пользователем через систему отчетов.
Вторая ось (D) - полнотекстовые документы, отражает необходимость организации взаимодействия: формирование и передача товаров, услуг или информации как внутри корпорации так и вне ее. В этих документах наряду с фактографической информацией содержится слобо структурированная информация, не подлежащая автоматизированной аналитической обработке, такая, например, как форс-мажерные факторы и порядок предъявления претензий при нарушении условий договора. Все взаимоотношения между субъектами бизнеса сопровождаются документами, которые становятся осязаемым отражением результата взаимодействия.