Создание системы управления документами и бизнес-процессами: технологические аспекты

Современная система автоматизации управления документами и бизнес-процессами, иначе говоря, система автоматизации документооборота, представляет собой сложный комплекс ПО, к которому предъявляется множество специфических требований. В отличие от традиционных учетных систем, которые, по сути, представляют собой комплексы специализированных по профилю основной деятельности АРМ, система документооборота совмещает в себе подходы, как свойственные классическим приложениям, так и относительно новые - и порой весьма специфические. Например, для автоматизации рабочего места секретаря-делопроизводителя используются технологии, вполне отвечающие традициям обычного АРМ, но при этом при автоматизации деловых процессов компании должны быть реализованы основные принципы процессной автоматизации. Весьма специфические требования предъявляют к системе автоматизации документооборота и стандарты хранения юридически значимых документов (MoReq, DoD и т.п.), которые, очевидно, в ближайшее время начнут применять и в нашем отечестве. Целая группа требований, связанных с интеграцией приложений, предъявляется к системе автоматизации документооборота в силу того, что реальные процессы компании, как правило, не ограничиваются обработкой документов, а захватывают различные приложения информационной системы. И наконец, можно говорить о совершенно новом наборе требований к системе автоматизации документооборота, возникающих в связи с использованием системы в режиме хостинга, по модели Software as a Service. Все перечисленные аспекты заставляют разработчиков прибегать к различным технологическим инновациям, которые мы и рассмотрим в данной статье на примере функциональности новой версии системы DocsVision.

Механизмы реинжиниринга бизнес-процессов

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

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

Кратко остановимся на том, каким образом реализуются данные конструкторы.

Средства быстрого конструирования решений

Начнем со средств конструирования бизнес-объектов. По сути для реализации данного инструмента имеется три варианта:

• использование имеющегося на рынке инструмента разработки электронных форм (пример - Microsoft InfoPath);
• создание собственной среды разработки форм;
• использование набора компонентов и дополнительных средств описания структуры метаданных объектов для программной сборки компонентов с помощью той или иной среды разработки (например, набора расширений для Microsoft Visual Studio).

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

Платформа DocsVision поддерживает все три описанные возможности. Для создания бизнес-объектов системы можно использовать готовые редакторы форм - Microsoft InfoPath, если в качестве объектов используются XML-документы, или средства разработки Microsoft Visual Studio for Application для обработки офисных документов. В системе есть собственный дизайнер форм для быстрой разработки форм объектов (рис. 1), если нужно быстро сконструировать сложные объекты, использующие специфические компоненты системы. И наконец, в DocsVision реализованы средства моделирования бизнес-объектов (менеджер карточек) и набор программных компонентов для создания более сложных приложений путем компиляции.

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

Следующий уровень конструирования решений на базе системы документооборота - дизайнер бизнес-процессов, или, как его принято называть, дизайнер WorkFlow. Практика реализации такого инструментария отличается большим разнообразием подходов. Отсутствие стандартов описания бизнес-процессов, а также различие подходов к структурам моделирования базовых бизнес-объектов приводят к тому, что в каждой системе по сути существует собственный подход к реализации этого дизайнера. Практически общего между ними - только сам факт наличия графического дизайнера топологии бизнес-процесса и поддержка двух общих типов активностей (функций, элементов бизнес-процессов) в соответствии с требованиями WorkFlow Management Coalition (WfMC): функции ручной обработки (этап участия человека в бизнес-процессе) и серверных активностей (реализуемых с помощью программного кода). Другие компоненты Workflow, такие как типы специализированных активностей, средства описания переменных окружения процесса, нотация описания процесса, способы реализации обработки событий, передачи информации между этапами бизнес-процесса, описание средств декомпозиции и взаимодействия процессов, средства передачи и получения внешних данных, реализуются достаточно произвольно.

В системе DocsVision используется два инструментария для описания структуры бизнес-процесса (рис. 2). Первый - это дизайнер собственной разработки, включающий расширяемый набор из полутора десятков специализированных функций, который максимально приспособлен для обработки бизнес-объектов системы DocsVision и позволяет реализовать большее количество процессов обработки информации без программирования, посредством визуального конструирования. При необходимости программного расширения бизнес-процессов можно воспользоваться функцией Script, которая реализует в рамках бизнес-процесса произвольную программу, написанную на языке C# или VB.NET. Данная программа будет исполняться в контексте бизнес-процесса и иметь доступ к его переменным и окружению.

Второй инструмент - дизайнер, ориентированный на разработку бизнес-процессов на базе нотации и с использованием активностей Windows WorkFlow Foundation. Этот программный протокол появился в составе .NET Framework 3.0 и по сути дела стал стандартом для создания систем Workflow на базе Windows. О поддержке данного стандарта заявили многие производители промышленных систем WorkFlow, и большинство разработчиков программных комплексов намереваются в ближайшем будущем выпустить наборы функций для реализации доступа к данным и функциям своих приложений из процессов на базе протокола Windows WF. Однако в сегодняшней реализации нотация и средства разработки WF-процессов ориентированы скорее на разработчиков, нежели на системных аналитиков и инженеров-внедренцев, что делает широкое использование этого модуля несколько проблематичным.

В новой версии DoscVision 5.0 планируется существенно расширить использование протокола Windows WF. Базовый дизайнер бизнес-процесса планируется также перевести на эту платформу и обеспечить его полную совместимость с нотацией BPMN, постепенно де-факто занимающей место стандарта моделирования бизнес-процессов на базе Workflow. Для этого планируется использовать возможности расширения базового компонента дизайнера, входящего в состав библиотек .NET.

Ролевая и контекстная безопасность

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

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

В DocsVision имеется специальный механизм настройки контекстной безопасности, который служит для разработки приложений (в частности, он используется в продукте "Административное делопроизводство" на базе DocsVision). Данный механизм позволяет при внедрении системы определить доступность или недоступность тех или иных операций обработки объектов для пользователей системы. Данные правила могут быть закреплены как статически, на уровне справочника сотрудников, так и динамически, в зависимости от текущего контекста объекта (рис. 3). Правила определения контекста формируются на основании описания XML-запроса к содержимому объекта и значений параметров окружения (времени, текущего пользователя и т.п.)

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

Интеграция процессов

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

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

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

В системе DocsVision имеется набор программных шлюзов, реализующих вышеперечисленные функции, которые могут быть включены в различные бизнес-процессы практически без программирования, для следующих приложений: "1С:Предприятие 8.0", Microsoft Office SharePoint Server 2007, Microsoft Dynamics CRM, Microsoft Dynamics AX, Microsoft Exchange Server, файловая система Windows.

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

Организация хостинга приложений

Еще одна из современных тенденций в создании систем автоматизации документов и бизнес-процессов связана с возможностью их использования в режиме аренды на базе публичного хостинг-провайдера. Такая модель использования ПО называется Software as a Service (SaaS). Несмотря на ограниченное ее распространение в России, в целом в мире подобный способ использования ПО становится все более популярным, в частности, и для бизнес-приложений, к которым относится рассматриваемый нами класс программных продуктов. Свидетельством тому служат титанические усилия компании Microsoft по выводу на рынок проекта Azure - программной платформы для хостинга приложений в сети. Очевидно, в ближайшее время данная тенденция станет более распространенной и в нашей стране, так как подобный способ использования ПО сулит огромные выгоды в плане сокращения стоимости владения системой в целом.

Чтобы систему управления документами и бизнес-процессами можно было использовать в модели SaaS, она должна соответствовать следующим основным требованиям:

• возможность доступа ко всем основным функциям системы, как административным, так и пользовательским, с использованием Web-технологий, по протоколу HTTP в сети публичного доступа;
• обеспечение секретности передачи данных через Интернет;
• возможность обойтись без установки клиентского ПО (легкий клиент) или максимально упрощенная, прозрачная для пользователя его установка (smart-клиент);
• возможность использовать одну серверную инсталляцию системы для поддержки большого числа пользователей, в частности, поддержка на одном сервере изолированных областей для различных компаний - так называемый режим использования MultiTenancy;
• наличие средств автоматизации административных функций - средств развертывания виртуального окружения для пользователей и компаний, детализированного журнала активностей пользователя для процедур биллинга, инструментария для автоматического изменения режимов использования системы и т.п.

Система DocsVision изначально создавалась с ориентацией на такой режим работы. Сервер системы представляет собой Web-сервер, взаимодействующий с клиентом по протоколу SOAP/HTTP. Клиентское рабочее место и все приложения, разрабатываемые на базе платформы, представляют собой исполняемые в среде Microsoft Internet Explorer автоматически инсталлируемые программные компоненты. Поддерживается работа как в среде VPN, так и по публичному каналу доступа с использованием шифрования трафика по протоколу HTTPS. Наличие развитой системы разграничения прав на все модули и компоненты системы позволяет изолировать отдельные группы пользователей и реализовать полноценный режим MultiTenancy. Пример реализации приложения в режиме SaaS можно посмотреть на сайте live.docsvision.com.

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

Заключение

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