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

В. Климов, АО Весть

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

Задачи (tasks) - это собрание неких действий направленных на достижение некой деловой цели (конкретного сотрудника, отдела, предприятия в целом)
Сотрудники (people) - Эти задачи выполняются в определенном порядке определенными людьми или некоторые выполняют роль людей на основании заранее определенных деловых условий или правил.
Инструменты (tools) - В реальной жизни, информации связанная с каждой отдельно взятой задачей обрабатывается не АДП-приложением, а специализированной информационной системой ¹ . Приложения, которые обрабатывают информацию, связанную с задачей или задачами называются инструментами.
Процесс (process) - Собрание скоординированных последовательных и/или параллельных действий.
Деловой процесс (Business Process) - Собрание скоординированных последовательных и/или параллельных действий в контексте структуры организации и политики фирмы для достижения каких-либо деловых целей.
Описание процесса (Process definition) - Формализованное описание процесса. Описание процесса состоит из описание действий и их взаимосвязей и критериев которые определят начало и окончание процесса.
Действие (Activity) - Выделенный, логический шаг внутри делового процесса, который вносит вклад в достижение деловой цели. Это мельчайший (самый маленький, который мы способны выделить) элемент из делового процесса в целом, который мы способны описать с помощью модели, которая помогает нам формализовать деловые процессы.
Данные (Data) - Информация, которая необходима для осуществления действия. Выделяют два типа данных: данные процесса и внешние данные. Пример данных процесса: срока, даты. Примеры внешних данных: документ в самых разнообразных форматах (текстового процессора, электронной таблицы, изображение, голос, видео и т.п.)

Кроме того системы можно подразделить по типу движения задач:

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

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

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

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

Системы со свободным движением документов с контролем доставки и прочтения - это обычные системы электронной почты. С помощью дополнительного программирования к ним можно добавить еще и контроль выполнения.
Системы со свободным движением документов и со всеми функциями контроля исполнения, включая мониторинг, извещения и историю - это класс специализированных маршрутизаторов. К ним можно отнести маршрутизатор Компании ВЕСТЬ WorkRoute 1.0
Системы с жестким движением документов и со всеми функциями контроля исполнения - это высший класс АДП-систем. К ним можно отнести Action WorkFlow, StaffWare, IBM FlowMark, WorkRoute II.

Рассмотрим компоненты АДП-систем ³ высшего класса, как наиболее неизвестного российскому пользователю класса систем.

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

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

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

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

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

Какую модель выбрать для своей системы, это в основном зависит от Вас, от стиля работы Вашего предприятия, от задач, которые стоят перед Вами. В жизни, никогда не побеждают крайности и последние версии ряда АДП-систем доказывают нам это. Корпорация KeyFile выпустила новую АДП-систему, которая в качестве транспортного механизма использует Microsoft Exchange, а объектную базу данных собственной разработки для информационного хранилища для деловых процессов. Также имеет право на жизнь и обратный подход, к существующей АДП-системе основанной на базе данных прицепить почтового клиента, который поддерживает удаленных пользователей
Все вышеизложенное выше не претендует на всесторонний анализ проблемы работы с электронными документами, но он может быть оказаться полезным для выбора той или иной системы. В данном обзоре, я не пытался дать какие либо рекомендации по выбору то или иного конкретного программного продукта, так как рекомендации должны быть всегда привязаны к конкретным требованиям и условиям заказчика. Эйфория об абсолютном оружии на все случаи жизни была, но быстро прошла по мере погружения в проблему. Компания ВЕСТЬ имеет в своем портфеле набор программных продуктов, которые закрывает определенные задачи. Но понимая то, что каким бы хорошим продукт не был, он не решит все задачи, которые иногда возникают в гениальном мозгу заказчика, нам пришлось обобщая накопленный опыт создавать новые программные продукты, которые дополняют функционал уже имеющихся. Почему же не написать все с нуля, задаст вопрос проницательный читатель. Идеи написания своей операционной системы, системы управления документами и подобных сложных управляющих комплексов посещают людей или никогда не писавших программы в своей жизни ⁸ , либо не желающих оглядеться вокруг и посмотреть, что кто делает. Нельзя сказать, что Компания ВЕСТЬ писала много и выдающееся, но того, что было сделано сформировало стойкий принцип: "Если можно не писать, то лучше не писать". Поэтому наша позиция сейчас следующая: к продукту, который максимально соответствует всем принципам изложенным выше и решает все функции создавать программные системы-дополнения, которые позволят предлагать единый комплекс Заказчику удовлетворяющий его требования на 101 процент.

[Назад] [Содержание] [Вперед]