Программные продукты и системы

Условия развития экономики предъявляют жесткие требования к эффективности решения задач управления на предприятиях [1]. Конкурентоспособное функционирование предприятий требует проведения реорганизации их бизнес-процессов [2]. Вследствие этого у предприятий возникает потребность в гибких компьютерных системах, основанных на процессном подходе к управлению. Такие системы называются системами управления бизнес-процессами и административными регламентами (СУБП). Их важной характеристикой является возможность быстрой разработки и изменения бизнес-процессов предприятия без изменения кода системы.

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

Цель разработки системы

СУБП с открытым кодом востребована. Такую систему можно использовать в государственных организациях для оказания услуг гражданам, в вузах для обучения студентов, а также во многих других организациях.

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

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

Функции системы

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

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

Все необходимое появляется на экране пользователя при клике на задание.

Исполнителями могут быть как люди, так и специальные компьютерные приложения – боты.

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

Архитектура системы

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

Опишем основные компоненты системы.

Уровень JVM. Система полностью разработана на языке Java, поэтому для ее работы в операционной системе должна быть установлена виртуальная машина Java – JVM. Использование JVM позволило workflow-серверу не зависеть от конкретной операционной системы. Редактор про- цессов использует фреймворк Eclipse, который зависит от операционной системы, однако поддерживает все распространенные операционные системы. Графический редактор бизнес-процессов может работать под Windows, Linux, FreeBSD, MacOS и др. Workflow-сервер. Это основной компонент системы, который реализует среду исполнения экземпляра процесса в соответствии с его определением. Workflow-сервер позволяет создавать и изменять свойства пользователей, генерирует списки заданий и визуальные формы, соответствующие заданиям, дает возможность устанавливать различные права на объекты системы, может служить средством интеграции автоматизированных систем предприятия.

В workflow-сервер входят следующие модули.

·     Подсистема авторизации и аутентификации.

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

·     Подсистема для работы с бот-станциями. Позволяет автоматизировать ряд шагов бизнес-процесса с помощью ботов, назначенных исполнителями.

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

·     Ядро JBoss jBPM.

·     Сервер приложений JBoss Application Server.

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

Web-интерфейс представляет собой среду доступа пользователей к функциональности workflow-сервера. В частности, отображает списки заданий и визуальные формы заданий; позволяет пользователям выполнять задания, а администратору системы устанавливать права на объекты системы; дает возможность осуществлять мониторинг исполнения экземпляров бизнес-процессов. Является тонким приложением.

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

Совместная работа пользователей и компонентов системы

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

На клиентских компьютерах пользователей запускается клиент-оповещатель о поступивших заданиях или браузер, в котором открывается web-интерфейс системы.

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

На workflow-сервере выполняются экземпляры бизнес-процессов.

Размещенные в бот-станциях боты периодически опрашивают workflow-сервер. Если выполняющиеся на workflow-сервере экземпляры бизнес-процессов содержат задачи для ботов, боты выполняют эти задачи и возвращают результаты работы на workflow-сервер.

Web-интерфейсы и клиенты-оповещатели периодически обращаются к workflow-серверу и отображают задачи пользователей.

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

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

При помощи графического редактора бизнес-процессов аналитики разрабатывают и модифицируют бизнес-процессы.

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

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

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

Установленные клиенты-оповещатели сигнализируют пользователям о появлении новых  заданий.

В проекте использованы следующие технологии: EJB 2.0 (stateless session beans) – интерфейс взаимодействия с серверной частью и декларативная транзакционность; JSP 2.0, Servlet 2.3; Struts 1.2 – web-интерфейс; Hibernate 3.2.4 – ORM; Jboss 4.2.3 – сервер приложений; Eclipse 3.5 – графический редактор; JAAS – аутентификация.

Особенность системы – подсистема замещения пользователей

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

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

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

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

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

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

-    замещаемый пользователь (пользователь),

-    заместитель (функция над оргструктурой, возвращающая пользователя),

-    применимо ли правило (формула).

Пример правила назначения заместителя:

-    Иванов

-    Петров

-    (Роль = «инспекторКадровойСлужбы») & (Бизнес-процесс= «больничный»)

Правило замещения пользователя. У пользователя может быть одно из двух состояний – активен или неактивен.

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

Внедрение системы

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

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

На этапе внедрения системы возникли как типичные для проекта внедрения ПО проблемы (например, фактическое время работ оказалось больше запланированного), так и проблемы, связанные со спецификой СУБП. На начальном этапе внедрения у пользователей возникали психологические трудности: до внедрения системы они при выполнении задания работали с документами, а после внедрения в некоторых случаях стали получать задания, не связанные ни с одним из документов. Поэтому возникал типичный вопрос: в какой папке сейчас находится документ? Однако в ходе внедрения он постепенно трансформировался в вопрос: на каком шаге находится бизнес-про­цесс?

На предприятии, где внедрена система, более 700 сотрудников, почти 200 из них одновременно работают с системой. Система эксплуатируется на сервере со следующими характеристиками: Intel(R) Xeon 3.2 GHz 4 ядра (процессора), оперативная память – 4GB, диск – 70 GB.

В системе реализовано около 20 процессов предприятия. Освоение ее позволило сотрудникам предприятия перейти на процессное мышление.

Код системы выложен для свободного доступа на сайте разработчиков открытого кода sourceforge: http://sourceforge.net/projects/runawfe.

Литература

1.   Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. М.: Финансы и статистика, 2006.

2.   Тельнов Ю.Ф. Реинжиниринг бизнес-процессов. М.: Финансы и статистика, 2003.

3.   Михеев А.Г., Орлов М.В. Перспективы workflow-систем // PC WEEK. 2004. № 23; 2004. № 28. 2004. № 43; 2005. № 36.