А. Г. Михеев, В. Е. Пятецкий
Вступление
Системы управления бизнес-процессами и административными регламентами (далее СУБП) генерируют задачи исполнителям и контролируют их исполнение. Они позволяют исключить из действий сотрудников рутинные операции, неэффективные процедуры, связанные с поиском и передачей информации, существенно повысить скорость взаимодействия сотрудников. При использовании СУБП работники предприятия могут выполнять поступившие задачи, не отвлекаясь на получение от других работников необходимой для выполнения задания информации, передачу результатов своего труда другим работникам, изучение должностных инструкций. Вся необходимая информация возникает перед работником на экране компьютера.
Использование СУБП позволяет оперативно перестраивать бизнес-процессы организации и административные регламенты ведомства. Во многих случаях исполнителей заданий можно даже не информировать об изменении бизнес-процесса, так как это не отразится на характере их работы. То есть получается легче и быстрее изменять выполнение процессов. Таким образом предприятие или ведомство может более эффективно реагировать на изменение внутренних или внешних условий.
Также при помощи СУБП можно организовать взаимодействие граждан и различных ведомств через электронные каналы связи путем прямого выполнения административных регламентов государственных организаций в компьютерной среде. В случае использования СУБП в ведомстве появляется аналог производственного конвейера, от которого можно получить увеличение производительности труда работников, сравнимое с тем, которое было получено от внедрения конвейера на производстве.
Кроме увеличения производительности труда СУБП сильно повышают "прозрачность" деятельности ведомства: Все контролируется - кто выполнил данную
задачу, когда выполнил, сколько времени выполнял, сколько прошло времени между обращением гражданина и выполнением задачи и т.д.
К программному обеспечению, используемому в государственных органах, разумно предъявить следующие требования:
• Государственные организации должны иметь возможность использования неограниченного количества экземпляров программного обеспечения без увеличения расходов при увеличении количества экземпляров
• Граждане должны иметь возможность использования такого программного обеспечения бесплатно
• В случае, если разработчик программного обеспечения по каким-либо причинам перестал устраивать государство, государство должно иметь возможность сменить разработчика, не потеряв при этом программное обеспечение
Этим требованиям удовлетворяет свободное программное обеспечение с открытым кодом.
Также свободное ПО можно использовать средство кооперации "генераторов идей" и разработчиков промышленного ПО. В этом заинтересованы обе стороны:
"Генераторы идей", передав свои идеи и теории в проекты разработки свободного ПО, получат в конечном счете инструмент, реализующий их идеи. При этом:
• Этот инструмент они получат бесплатно
• При помощи данного инструмента они смогут передавать (продавать) реализацию своих идей другим людям и этим людям не придется платить за ПО, а также тратить усилия на получение и установку ключей, лицензионных файлов и т. п.
• При использовании реализации идей и теорий "генераторов идей" на реальных предприятиях, предприятия смогут избежать расходов на приобретение ПО
• Разработанное ПО можно будет свободно модифицировать при дальнейшем развитии идей и теорий
Разработчики промышленного ПО в свою очередь бесплатно получат идеи и теории, которые позволят разрабатываемому ПО получить качественные преимущества.
В настоящее время существует несколько свободных СУБП. Одна из них, система RunaWFE, - разработана в России. Эту систему можно бесплатно скачать через интернет вместе с документацией и исходными кодами с портала разработчиков свободного программного обеспечения sourceforge (http://sourceforge.net/projects/runawfe ) и установить в любой организации без каких-либо ограничений. Также можно модифицировать код системы и включать её в состав другого ПО, как свободного, так и проприетарного.
В настоящей статье приведено описание нескольких идей, относящихся к СУБП, реализованных в этом свободном ПО.
Описание четырёх идей, примененных к системам управления бизнес-процессами
Идея 1. Концепция ботов и бот-станций
Описание идеи
Исполнителями заданий в современных СУБП (системах управления бизнес-процессами) могут быть как люди, так и компьютерные приложения.
Во многих СУБП узлы, в которых задание выполняет компьютерное приложение, отмечаются на схеме процесса специальным образом (отличным от узлов, в которых задание выполняет человек), а роль в таких узлах всегда задается одинаково, например - "система".
В данном случае предлагается применить другое решение. В результате опроса управленцев было выявлено, что при работе с приложениями, выполняющими
задания в бизнес-процессах, управленцам комфортнее мыслить в понятиях некоторых различных сущностей, которые были бы аналогичны людям, а не использовать термин "система" во всех случаях выполнения задания компьютерным приложением.
Логика управленцев при этом следующая: Управленец традиционно мыслит в понятиях должностей специалистов и их компетенций. Он говорит: в компании есть должность "уборщица", я знаю, что сотрудник на этой должности умеет выполнять ограниченный набор действий (например "подметать" и "убирать") и исходя из этих возможностей я планирую участие уборщицы в соответствующих бизнес-процессах. Для компьютерных приложений мне тоже было бы удобно видеть "что они умеют делать" при планировании их использования в бизнес-процессах. Для самих приложений тоже удобна была бы логическая группировка по видам деятельности (например, - работа с электронной почтой, работа с отчетами и т.п.)
Идея: Было введено понятие бота для СУБП. Для заданий, выполняемых компьютерными системами была сделана их логическая группировка по ботам, чтобы при работе с бизнес-процессами управленец мог мыслить в терминах автоматических исполнителей и их областях компетенции.
Кроме того, для ботов было введено понятие прав на выполняемые действия (аналогичные правам людей-пользователей). Поэтому боты, также как люди, во время своей работы аутентифицируются в СУБП, после чего СУБП проводит их авторизацию при совершении операций.
Для работы ботов была разработана специальная среда - бот-станция, организует их взаимодействие с СУБП. Как правило, бот-станция соответствует серверу, на котором размещены боты. Находящиеся в бот-станции боты обращаются к СУБП. Если выполняющиеся на сервере экземпляры бизнес-процессов содержат задачи для ботов, то боты выполняют эти задачи и возвращают результаты работы на сервер.
Реализация
Настройка всех бот-станций и ботов производится через меню «Бот станции».
Пользователь имеет доступ к меню «Бот станции», если у него есть права на чтение бот-станций. Если прав на чтение бот-станций у пользователя нет, то пункт меню «Бот станции» интерфейсе пользователя будет отсутствовать. Для изменения настроек бот-станций необходимо иметь права «Конфигурировать бот-станцию».
Для изменения параметров бота необходимо выбрать изменяемого бота на странице информации по бот-станции, перейдя по ссылке с именем бота. Изменение параметров бота производится в секции “Параметры бота”. После выполнения команды “Применить” новые параметры вступят в силу немедленно без перезапуска системы и будут использованы при очередном вызове ботов.
Параметрами бота являются: имя бота (соответствует логину пользователя), пароль бота, список заданий, выполняемых ботом. Список заданий состоит из имени задания, ссылки на обработчик и конфигурации задания.
Идея 2. Правила замещения исполнителей заданий
Описание идеи
Подсистема замещения пользователей используется в случаях, когда исполнитель, которому предназначено задание, не имеет возможности его выполнить, - например, заболел, находится в отпуске или командировке. В таких случаях подсистема перенаправляет задание другому пользователю.
Традиционно в СУБП решают эту проблему при помощи импорта организационной структуры предприятия в СУБП и задания в ней функций замещения, основанных на положении сотрудников в административной системе управления предприятием. В некоторых системах эта проблема решается при помощи вставки программного кода, реализующего перенаправление заданий, непосредственно в бизнес-процессы.
Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно, т.к она также используется в других системах предприятия (ERP, CRM и т.п.). В случае использования программного кода бизнес-процесс становится неудобным для модификации, т.к. для изменения замещения как правило требуется привлекать программиста.
Но главное - такое решение неудобно управленцам, потому, что оно не соответствует их мышлению. В случае замещений исполнителей задач управленцам гораздо комфортнее думать "в терминах" людей, а не бизнес-процессов. Им удобнее не перебирать все бизнес-процессы, в которых теоретически может участвовать замещаемый пользователь и изменять в них настройки, а явно задать замещение в свойствах пользователя, может быть, указав при этом какие-то условия, при выполнении которых замещение будет выполнено.
Идея: Правила замещения должны быть "привязаны" к исполнителям задач, а не к бизнес-процессам.
Реализация
В свойствах пользователя можно задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:
• Заместитель (Функция над организационной структурой предприятия, возвращающая пользователя-заместителя)
• Условие применения правила (Критерий)
У пользователя может быть одно из двух состояний:
• Активен
• Не активен
Механизм замещения применяется только к пользователям, имеющим статус «не активен».
При формировании списка заданий правила замещения, относящиеся к данному пользователю, просматриваются сверху вниз до тех пор, пока либо не будет найдено первое по порядку подходящее правило замещения (в котором выполняется условие в «критерии» и заместитель имеет статус «Активен»), либо будет выяснено, что ни одного подходящего правила нет.
В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Идея 3. Использование концепции бинарных отношений при инициализации ролей
Описание идеи
Роли в бизнес-процессе используются для связывания узлов бизнес-процесса с исполнителями заданий. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы бизнес-процесса. Инициализация роли – это назначение на роль конкретного исполнителя.
Реализация компонентов-инициализаторов ролей бизнес-процессов является одной из самых неудобных и трудоемких проблем при внедрении систем управления бизнес-процессами и административными регламентами на предприятиях.
Традиционных подходов к реализации инициализатора роли два:
1. Внутри системы управления бизнес-процессами и административными регламентами задается организационная структура предприятия и роли инициализируются при помощи указания параметров этой структуры
2. Процедура инициализации роли выносится в какую-то другую информационную систему
У обоих этих подходов есть существенные неудобства.
• Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно. Кроме того, путем задания иерархической организационной структуры можно инициализировать роли, соответствующие иерархии управления – «руководитель сотрудника», «руководитель отдела», «директор». Однако сложно инициализировать роли, не относящиеся к административному управлению: «сотрудник кадровой службы, ответственный за адаптацию принятого на работу сотрудника», или «секретарь, отвечающий за корреспонденцию данного сотрудника».
• Вынос инициализации роли в другую систему и организация удаленного вызова процедуры из другой информационной системы приводят к техническим сложностям, а также работам по настройкам, связанным с информационной безопасностью
Идея: Использование в данном случае понятия чистой математики — «бинарного отношения» позволяет разработать очень простое, но весьма эффективное решение задачи построения инициализатора роли.
Бинарное отношение для множеств A и B можно задать, определив набор упорядоченных пар, в которых первый элемент принадлежит множеству A, а второй - множеству B.
Инициализация при помощи бинарных отношений производится следующим образом: Из указанной в инициализаторе роли переменной бизнес-процесса берется ее значение-исполнитель. Это значение будет соответствовать правой части отношения. Строится множество значений всех левых частей отношения, соответствующих данному элементу правой части. Этим множеством и инициализируется роль.
Задавать отношения перечислением всех определяющих его пар исполнителей не всегда удобно, так как таких пар может быть очень много. Для уменьшения количества вводимых данных в парах кроме исполнителей допускается использовать группы пользователей.
Реализация
В главное меню системы был добавлен еще один пункт - Отношения (в английской локализации - Relations).
В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.
Для каждого исполнителя в его свойствах добавлены два раздела:
• Отношения, в которых он может находиться в левой части
• Отношения, в которых он может находиться в правой части
Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения
Работа с отношениями в редакторе бизнес-процессов
В редакторе в бизнес-процессе при редактировании инициализатора роли можно выбрать закладку «задать роль с помощью отношения». В этом случае можно задать настройки соединения с сервером и импортировать отношения в редактор.
Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения и переменная или константа, соответствующая правой части отношения, задающая пользователя или группу пользователей.
Идея 4. Использование элементов-обработчиков
Описание идеи
Бизнес-процессы, непосредственно исполняющиеся в компьютерной среде принято называть исполнимыми бизнес-процессами. С. Яблонский и С. Бусслер в работе [1] предложили определять исполнимый бизнес-процесс путем задания нескольких перспектив (точек зрения или слоев/уровней рассмотрения). Обычно используется четыре перспективы:
• перспектива управления потоком (control-flow perspective)
• перспектива данных (data perspective)
• перспектива ресурсов (resource perspective)
• перспектива операций (operational perspective)
Перспективе управления потоком соответствует схема бизнес-процесса. Перспективе данных соответствует набор переменных бизнес-процесса. Перспективе ресурсов соответствует набор исполнителей, которые могут выполнять задания в узлах схемы бизнес-процесса. Перспективе операций соответствует список элементарных действий, совершаемых исполнителями в рамках задания.
Предлагается в перспективе управления потоком к традиционным элементам схемы бизнес-процесса добавить новый элемент "обработчик". Задача этого элемента - привязать к схеме бизнес-процесса выполнение небольших автоматических операций, для которых не требуется определять полноценный узел-действие на графе бизнес-процесса.
Идея
Предлагается добавить новый элемент "обработчик", который может быть присоединен к переходу или узлу-действию. С обработчиком связывается набор настроек и программный код, который будет выполнен при прохождении точки управления через элемент, к которому присоединен обработчик. Обработчик обозначается небольшим кружком, расположенном непосредственно на переходе или узле-действии.
Обработчики удобны для встраивания в бизнес-процесс небольших операций над переменными бизнес-процесса. Типичным примером такой операции является формула a = b + c, которая записывает в переменную бизнес-процесса a сумму значений переменных бизнес-процесса b и c. Обработчики удобно использовать для выполнения действий над содержащимися в переменных бизнес-процесса числовыми и строковыми значениями, записи в переменную текущей даты-времени, номера экземпляра бизнес-процесса, идентификатора выполнившего задание пользователя, преобразования переменных, содержащих даты и время и т.п. То есть, обработчики используются при задании вспомогательных операций, для которых выделение полноценного узла-действия на графе процесса будет только усложнять полноценное восприятие схемы бизнес-процесса человеком
Для изображения элементов графа процесса применяются различные графические нотации (наборы графических элементов, соответствующих различным элементам схемы бизнес-процесса). Наиболее распространены BPMN и UML - нотации , являющиеся международными стандартами.
Ни в BPMN, ни в UML - нотации элемента-обработчика нет. Поэтому, предлагается показывать обработчики только в редакторе бизнес-процессов, а на схемах, отгружаемых в систему управления бизнес-процессами и административными регламентами, предлагается их скрывать, чтобы схемы соответствовали стандартной нотации. При этом в редакторе бизнес-процессов для каждого элемента-обработчика задаются настройки и исполнимый код, который будет вызван во время исполнения бизнес-процесса.
Реализация
В графическом редакторе бизнес-процессов элементы-обработчики добавлены в палитру элементов перспективы потока управления. При помощи мыши можно поместить обработчики на элементы схемы бизнес-процесса и связать их с программным кодом и переменными бизнес-процесса.
Пример расположения обработчиков на схеме бизнес-процесса:
В редакторе бизнес-процессов для обработчика задается тип:
и конфигурация:
Далее можно снять галочку в строке "Показать обработчики" меню "Вид"
и обработчики на схеме будут скрыты. При этом после загрузки разработанного бизнес-процесса в среду исполнения элементы-обработчики будут выполняться при прохождении через них точек управления.
Литература.
1.S. Jablonski and C. Bussler. Workfow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, London, UK, 1996.
2. Михеев А.Г, Орлов М.В., Пятецкий В.Е. Комплексный подход к процессному управлению предприятием. Автоматизация в промышленности № 1, 2013
