TrainingMaterials Theory

Система управления бизнес-процессами и административными регламентами RunaWFE.

Версия 4.6.0

© 2015-2023, ООО "Процессные технологии"

• Старая версия этого документа на 07.06.2022

Процессный подход к управлению

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

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

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

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

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

Для автоматизации процессного управления предприятием разработан специальный класс компьютерных систем – системы управления бизнес-процессами и административными регламентами (далее СУБПиАР). Основная задача таких систем - раздавать задания исполнителям и контролировать их выполнение. Последовательность заданий определяется схемой бизнес-процесса, которую можно разработать и в дальнейшем быстро модифицировать при помощи среды разработки. Эта схема похожа на блок-схему алгоритма. По схеме перемещаются точки управления. В узлах схемы генерируются задания исполнителям.

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

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

В последние годы происходит активное внедрение СУБПиАР как в бизнесе, так и в государственных организациях. Поэтому возникла задача обучения специалистов как экономических специальностей, так и специальностей, связанных с информационными технологиями, процессному подходу и работе с СУБПиАР.

В лабораторном практикуме дано описание основных элементов систем управления бизнес-процессами. Описание дано на примере свободной системы с открытым кодом – RunaWFE. RunaWFE свободно распространяется вместе со своими исходными кодами на условиях открытой лицензии LGPL. Система бесплатная, ее можно свободно установить на любое количество компьютеров без каких-либо ограничений.

Скачать дистрибутивы

Исполнимые бизнес-процессы и административные регламенты

В данном методическом пособии мы будем рассматривать термины бизнес-процесс и административный регламент как синонимы. Традиционно термин бизнес-процесс используется в случае промышленного предприятия, а административный регламент – государственной организации.

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

Дадим определение исполнимого бизнес-процесса, основу которого составляют идеи С. Яблонского и С. Бусcлера [6].

Исполнимый бизнес-процесс определяется при помощи задания следующих перспектив (точек зрения или слоев/уровней рассмотрения):

• перспектива потока управления (control-flow perspective)
• перспектива данных (data perspective)
• перспектива ресурсов (resource perspective)
• перспектива операций (operational perspective).

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

1. на схеме находятся перемещающиеся точки управления
2. переменные, типы которых заданы в определении бизнес-процесса, содержат конкретные значения
3. на роли назначаются конкретные исполнители заданий.

Рассмотрим более подробно уровни определения исполнимого бизнес-процесса.

Перспектива потока управления. Схема бизнес-процесса

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

Узлы бизнес-процесса могут быть трех типов:

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

Шаги процесса:

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

Маршрутных узлов имеем 5:

• стартовый узел (начало)
• окончание
• завершение потока управления
• исключающий шлюз
• параллельный шлюз.

Согласно свойствам маршрутного узла, в нём может происходить:

• появление точек управления
• удаление их
• их разветвление-слияние
• направление точки управления по одному из множества исходящих переходов на основании прописанных в маршрутном узле правил.

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

По мере развития теории СУБПиАР в поздних спецификациях определение схемы бизнес-процесса было расширено весьма удобными и полезными элементами:

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

   Комбинированные узлы (скомбинированные с последующими маршрутными узлами) могут быть построены только на базе:

   • узла-действия
   • узла-мультидействия.

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

    

   В среде разработки RunaWFE реализовано также комбинирование некоторых видов шагов процесса с таймером.

2. Были добавлены дополнительные конструкции (далее – "дополнительные конструкции"), элементы которых не являются элементами графа (и не могут быть шагами процесса соответственно):

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

3. Были добавлены узлы, соответствующие шагу процесса, но не являющиеся узлами-действиями:

   • узлы-ожидания (узлы-таймеры), в которых не дается заданий исполнителям процесса; СУБПиАР просто ожидает в этих узлах наступления определенного события, после которого точка управления идет дальше
   • узлы-подпроцессы, узлы подпроцессы-композиции, узлы-мультиподпроцессы, для которых не может быть определен конкретный исполнитель; в этих узлах СУБПиАР запускает другой бизнес-процесс в качестве подпроцесса текущего процесса и передает ему соответствующие данные.

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

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

Рисунок 2.01. Обозначения узлов: а – Начало; б – Завершение потока; в – Окончание; г – Действие

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

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

Узел «Действие» относится к шагам процесса и генерирует задание исполнителю. Обозначается он прямоугольником со скругленными углами, в центре которого пишется имя узла (Рис.2.01,г) и имеет один входящий и один исходящий переходы.

После выполнения исполнителем задания точка управления движется по исходящему переходу к следующему узлу процесса.

Узел «Исключающий шлюз» относится к маршрутным узлам и может иметь несколько входящих и несколько исходящих переходов. Для каждой пришедшей в него точки управления на основании заложенных в узел условий определяется, по какому из исходящих переходов она будет перемещена далее. Обозначается он ромбом, в котором изображен «крестик» (Рис.2.02,а).

Рисунок 2.02. Обозначения узлов: а – Исключающий шлюз; б – Параллельный шлюз

Узел «Параллельный шлюз» относится к маршрутным узлам и может иметь несколько входящих и несколько исходящих переходов. Для каждого входящего перехода пришедшая по нему в параллельный шлюз точка управления ставится в очередь. Если для всех входящих переходов их очереди заполнены хотя бы одной точкой управления, то все точки управления, находящиеся на первой позиции очереди каждого входящего перехода, удаляются, а на каждом исходящем ребре генерируется точка управления. Обозначается «Параллельный шлюз» ромбом, в котором изображен «плюс» (Рис.2.02,б).

Перспектива данных. Переменные бизнес-процесса

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

Перспектива ресурсов. Роли и исполнители

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

В бизнес-процессе производится связывание узлов-действий с исполнителями заданий при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам-действиям. Во время выполнения бизнес-процесса ролям назначаются конкретные исполнители. Здесь можно провести аналогию с театральным спектаклем: в процессе написании сценария определяются используемые в спектакле роли. Потом, при постановке в конкретном театре, на роли назначаются актеры – исполнители ролей. Например, роль может называться «Эдмон Дантес», а исполнителем быть – заслуженный артист Петров. В узле-действии бизнес-процесса может быть сразу несколько возможных исполнителей роли.

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

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

Перспективе операций бизнес-процесса соответствует список элементарных действий, совершаемых исполнителями в рамках узла-действия.

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

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

На примере ПО RunaWFE

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

Для выполнения этих функций в СУБПиАР служат следующие графические интерфейсы:

• интерфейсы для работы с заданиями исполнителей
• интерфейсы для работы с загруженными в СУБПиАР определениями бизнес-процессов
• интерфейсы для работы с выполняющимися в СУБПиАР экземплярами процессов
• интерфейсы для администрирования пользователей и групп пользователей
• интерфейсы для настройки замещений исполнителей заданий.

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

В системе RunaWFE для интеграции приложений реализованы специальные сущности – боты и бот-станции.

В данной части методического пособия на примере системы RunaWFE продемонстрирована вся перечисленная функциональность и пользовательские интерфейсы.

Основные компоненты системы управления бизнес-процессами

RunaWFE состоит из следующих основных компонентов:

• RunaWFE–сервер
• Среда разработки
• Web-интерфейс системы
• Бот-станция (необязательный компонент)
• Клиент-оповещатель о поступивших заданиях (необязательный компонент).

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

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

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

Web-интерфейс системы RunaWFE:

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

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

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

Замечание. Если оповещение о поступивших задачах не требуется или достаточно оповещения по электронной почте, то для получения остальной описанной выше функциональности можно клиент-оповещатель не устанавливать. Эта функциональность доступна при помощи Web-интерфейса системы через обычный браузер.

Краткое описание функциональности компонентов системы

Web-интерфейс системы

При помощи web-интерфейса системы пользователь может:

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

При помощи web-интерфейса системы администратор может:

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

Среда разработки

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

Симулятор бизнес-процессов

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

Основы разработки бизнес-процессов предприятия

Построение уровней описания бизнеса

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

1. Уровни описания бизнеса


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

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




2. Уровни бизнес-процессов


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

• Уровень предприятия
• Уровень бизнеса
• Уровень операций
• Уровень шагов выполнения задачи
• Уровень исполнителя.

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

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

Уровень операций. Это взгляд со стороны операционного менеджера. Операционные менеджеры - это руководители, отвечающие за контроль эффективности работы. Их взгляд отражает уровень работ, выполняющихся в рамках одного подразделения. Описания этого уровня более детальные по сравнению с описаниями с точки зрения бизнеса или описаниями с точки зрения предприятия. Эти описания разбиваются на действия, которые выполняются «функциями» - должностями, подразделениями, системами. Описание содержит связь действий с процессом и с функциями. На этом данном уровне детализации легко понять, какие действия выполняет функциональное подразделение. Группируя действия снизу вверх, можно понять, какой вклад каждое действие вносит в создание конечной продукции процесса. Описания данного уровня дают лишь базовое представление о бизнес-операциях.

Уровень шагов выполнения задачи. Описание бизнеса можно детализировать еще глубже. Основное правило - детализировать процесс до уровня, достаточного для:

• решения задач, поставленных аналитику в рамках проекта
• решения своих задач другими участниками на следующих фазах проекта.

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

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




3. Проведение описания «снизу-вверх» и «сверху-вниз»


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




4. Методы сбора информации


Применяются следующие способы сбора информации:

• Изучение имеющейся документации
• Прямое наблюдение
• Интервью
• Опрос
• Специальное совещание.


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

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

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

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

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

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

Проектирование бизнес-процессов

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

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

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

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

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

Спроектированный бизнес-процесс определяет, что делается и как это делается. Проектирование процесса начинается с изучения того, как бизнес работает в текущий момент времени - что он делает, где, как и зачем. Это исследование документированных и недокументированных действий, составляющих процесс. Но важно понимать не только как бизнес работает, но и как он должен работать (по мнению руководства предприятия). Что делается не так и почему? Где возникают проблемы при передаче ответственности между подразделениями, при принятии решений? Где бизнес-правила не задокументированы и допускают вольную трактовку?

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

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

Спецификация бизнес-процессов, как правило, состоит из следующих описаний:

1. Описание исполнения бизнес-процессов (цепочек действий)
2. Описание декомпозиции бизнес-процессов на подпроцессы
3. Описание бизнес-функций
4. Описание сценариев операций.

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

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

Результат проектирования должен содержать, в том или ином виде, следующие уровни:

1. Верхний уровень - это сквозные бизнес-процессы, относящиеся ко всему предприятию. Они могут содержать подпроцессы.
2. Следующий уровень - это подпроцессы, показывающие распределение работы по бизнес-функциям и соответствие между бизнес-функциями и подразделениями.
3. Третий уровень - это процессы подразделений, показывающие выполняющиеся действия. Процессы этого уровня могут также показывать связь между действиями, выполняемыми в этом же подразделении в рамках других функций и подпроцессов.
4. Четвертый уровень детализации - бизнес-процессы, соответствующие сценариям, позволяют понять, какими событиями или данными вызываются выполняемые в бизнес-процессе работы. На этом уровне можно проследить, как отдельные работы складываются в процесс и их роль в создании конечной продукции процесса.
   Четвертый уровень обеспечивает только базовое понимание бизнес-операций. Этого уровня детализации часто недостаточно для последующей автоматизации.
5. На пятом уровне в бизнес-процессе привязывают правила к действиям, данные - к экранным формам и отчетам, описывают порядок ввода данных и низкоуровневые решения. Этот уровень вплотную подходит к разработке исполнимых бизнес-процессов, которые управляют работой и автоматизируют ввод-вывод данных и их обработку. На этом уровне бизнес-аналитик определяет задачи, выполнение которых дает требуемые результаты действий.

Рекомендуется сопровождать спецификации дополнительной информацией, которая будет полезна на этапе изменения бизнес-процессов:

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

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

Разработка исполнимых бизнес-процессов

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

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

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

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

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

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

Понятие парадигма рассматривается в данном случае в терминах концепции парадигм программирования Роберта Флойда (Флойд Р. О парадигмах программирования. В кн.: Лекции лауреатов премии Тьюринга. М.: Мир, 1993) , которая является расширением концепции парадигм Томаса Куна, предложенной в работе «Структура научных революций» (Кун Т. Структура научных революций. М.: Прогресс, 1975).

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

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

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

Готовить этих специалистов в ВУЗах надо сегодня. По аналогии с обучением программированию, обучение студентов разработке бизнес-процессов можно разделить на два подхода:

• изучение нотаций описания бизнес-процессов и обучение работе с конкретными СУБП (аналог обучения синтаксису языков программирования и работе с конкретными компиляторами)
• изучение различных возможных вариантов реализации в виде исполнимых бизнес-процессов тех или иных типичных ситуаций в бизнесе предприятия (аналог обучения приемам программирования).

Существуют большое количество учебных курсов, посвященные первому подходу. В частности, авторами настоящей работы обобщен опыт обучения студентов разработке исполнимых бизнес-процессов в МЭСИ, НИТУ МИСиС и УГАТУ. На занятиях студенты изучают теорию исполнимых бизнес-процессов, графические нотации описания бизнес-процессов, основные компоненты типичных BPMS и получают практический опыт разработки и исполнения простейших бизнес-процессов.

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

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

Правила разработки исполнимых бизнес-процессов

1. Названиях узлов схемы бизнес-процессов, соответствующих действиям исполнителей


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

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

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




2. Размер схемы бизнес-процесса


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




3. Направления движения точек управления по схеме бизнес-процесса


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

В некоторых случаях, при длинных участках движения точек управления без разветвлений, можно располагать связанные линиями переходов узлы схемы слева-направо - сверху-вниз, аналогично тому, как человек читает слова на листе печатного документа. Пример такого движения точек управления приведен на Рис.4.01.

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

Рисунок 4.01. Схема с движением точек управления слева-направо - сверху-вниз.




4. Отказ от использования ролей в виде дорожек на схеме бизнес-процесса


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

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

Нотация BPMN позволяет не рисовать дорожки на схеме. Однако при анализе схемы бизнес-процесса информация о связанной с узлом роли очень важна. Поэтому предлагается помещать название роли на графический элемент узла-действия схемы бизнес-процесса. Графическая нотация UML AD позволяет помещать название роли над именем узла-действия в круглых скобках. В нотации BPMN такая возможность не не стандартизована. Тем не менее мы предлагаем даже в случае BPMN нотации располагать название роли в круглых скобках в верхней части графического элемента узла-действия и считать его префиксом названия узла. Этот прием реализован в RunaWFE и будет использован в приведенных в настоящей книге схемах бизнес-процессов.




5. Реализация действия, которое должно быть выполнено одновременно двумя исполнителями


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

Рисунок 4.02. «Интуитивная» реализация действия, выполняемого одновременно двумя лицами.


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

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

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

Поэтому предлагается использовать другое решение: на схеме бизнес-процесса узлы, в которых даются задания двум исполнителям, располагаются не последовательно, а параллельно, то есть они находятся в параллельных ветках (см. Рис.4.03):

Рисунок 4.03. Правильная реализация действия, выполняемого одновременно двумя лицами




6. Вынесение второстепенных действий в параллельную ветку


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

На Рис.4.04 представлен пример схемы бизнес-процесса, в котором задания, факт выполнения которых вводит в BPMS «Сотрудник», могут заблокировать нормальное выполнение бизнес-процесса. Эти задания выделены на рисунке овалами. То есть если, например, сотрудник не будет отмечать в BPMS выполнение задания «ознакомиться с одобрением», то бизнес-процесс не перейдет к оформлению приказа и выплате денег. В режиме промышленной эксплуатации такие схемы бизнес-процессов могут привести к серьезным сбоям в работе предприятия.

Рисунок 4.04. Неправильная реализация бизнес-процесса с второстепенными действиями

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

Рисунок 4.05. Правильная реализация бизнес-процесса с второстепенными действиями

Легко видеть, что начисление денег сотруднику согласно приказу призойдёт гарантированно и полностью независимо от него. А когда он сможет их получить - целиком зависит от его исполнительности.




7. Использование парных разделений и слияний


Использование парных разделений и слияний - это возможность мысленной декомпозиции участка схемы.

Нотация BPMN позволяет использовать в схемах бизнес-процессов элементы разделения без парных им элементов-слияний. В этом случае для удаления выполнивших свою задачу точек управления можно использовать элемент-событие завершения потока управления (на Рис.4.06 приведен пример такой схемы, эквивалентной схеме, представленной на Рис.4.05). Однако, по нашему мнению, предпочтительной схемой является схема с парными разделениями и слияниями, так как такие схемы, несмотря на большее число содержащихся в них элементов, являются более понятными.

Рисунок 4.06. Другая реализация бизнес-процесса со второстепенными действиями

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





Рисунок 4.07. Пример схемы бизнес-процесса с тремя вложенными парами разделений-слияний




8. Расположение парных разделений-слияний и переходов, их соединяющих


Разделения и парные им слияния удобно располагать на одной горизонтальной или вертикальной линии, чтобы на схеме бизнес-процесса для одного элемента можно было бы легко найти парный ему элемент. Примеры таких расположений представлены, например, на Рис.4.05,4.07. На Рис.4.08 линии, на которых расположены парные разделения–слияния, выделены желтым цветом.

Рисунок 4.08. Схема бизнес-процесса, на которой линии расположения парных разделений–слияний выделены желтым цветом

Желательно, чтобы линии переходов, соответствующих одновременно выполняющимся потокам действий, были параллельными. Это увеличивает понятность схемы, так как бизнес-аналитику проще представить параллельно расположенные на схеме последовательности действий как «параллельно» выполняющиеся. Примеры таких расположений также представлены на Рис.4.05,4.07,4.08.

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




9. Решения с непарными разделениями-слияниями


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


Рисунок 4.08а. Схема с непарными разделениями-слияниями

Он состоит из следующих действий:

• Заключить договор аренды помещения
• Подготовить помещение к конференции
• Подготовить пригласительные материалы
• Впечатать в материалы конференции адрес
• Разослать материалы конференции.

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

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




10. Использование элемента «окончание бизнес-процесса»


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

На основе элемента «окончание бизнес-процесса» можно строить процессные решения для некоторых ситуаций. Рассмотрим случай согласования документов: Три отдела должны согласовать документ. Каждый отдел может утвердить или отклонить документ. Если любой отдел отклоняет документ, то документ получает статус "не согласован" и согласование сразу же должно прекращаться. Рассмотрения документов другими отделами уже не требуется.

Согласование всеми отделами должно происходить параллельно, порядок одобрения в данном бизнес-процессе не важен. На Рис.4.09 представлена схема, использование которой внутри подпроцесса решает поставленную задачу.

Рисунок 4.09. Схема бизнес-процесса, реализующая согласование документа

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

Забавные примеры бизнес-процессов

1. Пример "компромиссного" решения по разделениям-слияниям и использованию элемента «завершение потока управления»


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

В качестве примера рассмотрим упрощенный бизнес-процесс розничного кредитования банка.

Описание бизнес-процесса:

Операционист вводит в стартовую форму данные заявки на кредит и запускает экземпляр бизнес-процесса. Далее Специалист-Верификатор выполняет задание «Верифицировать данные». Он выбирает один из двух вариантов - Данные верифицированы / Данные не верифицированы.

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

В случае, если данные верифицированы, Сотрудник скорингового центра выполняет задание «Определить риски». В форме задания он выбирает один из двух вариантов - "Риски приемлемы" / "Риски не приемлемы". В случае, если риски не приемлемы, Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание «Уведомить об отказе». После этого бизнес-процесс завершается. В случае, если риски приемлемы, Сотрудник службы безопасности выполняет задание «Произвести проверку СБ». В форме задания он вводит результат проверки - один из четырех вариантов: "Отлично", "Хорошо", "Удовлетворительно", "Не удовлетворительно". В случае неудовлетворительного результата Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание «Уведомить об отказе».

Если результат не равен «Не удовлетворительно», то задание «Принять решение по кредиту» выполняет Кредитный менеджер. Если он принял положительное решение, то:

• Оператор колл-центра информирует клиента о положительном решении по кредиту
• одновременно Операционист выполняет задание «Оформить кредит»
• Бухгалтер выполняет задание «Зачислить средства»
• бизнес-процесс завершается.

Если Кредитный менеджер принял отрицательное решение, то

• Операционист и Сотрудник службы безопасности знакомятся с информацией об отказе в оформлении кредита
• SMS-шлюз выполняет задание «Уведомить об отказе»
• бизнес-процесс завершается.

Замечание. В данном бизнес-процессе не должно быть дублирования задач Операционисту по ознакомлению с информацией об отказе и SMS-шлюзу «Уведомить заемщика об отказе». Каждая из этих задач должна соответствовать только одному узлу-действию

На Рис.4.10 приведено "компромиссное" решение данной задачи. Оно содержит как парные разделения и слияния, так и непарное разделение, а также как узел окончания бизнес-процесса, так и два узла завершения потоков управления. Так получается потому, что в случае отказа кредитного менеджера появляется еще один исполнитель (Сотрудник СБ), которого надо проинформировать об отказе.





Рисунок 4.10. Схема бизнес-процесса розничного кредитования банка




2. Использование алгоритмов в схеме бизнес-процесса


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

В качестве примера рассмотрим реализацию задачи об игре в камешки. Игра состоит в следующем: есть кучка в 100 камней. Игроки ходят по очереди. За один ход игрок должен взять из кучки не менее одного, но не более 9 камней. Тот, кто возьмет последний камень, является выигравшим. Надо разработать бизнес-процесс, реализующий игру в камешки. Также требуется придумать гарантированно выигрышную стратегию поведения игрока. В бизнес-процессе на форме задания каждому игроку должен предлагаться соответствующий стратегии совет от экземпляра бизнес-процесса: какое количество камней игроку на данном ходу стоит взять из кучки для выигрыша в этом или последующих ходах. Если при данном количестве камней в кучке не существует "выигрышного" хода, то на форме должно содержаться сообщение "Не могу дать совет". На Рис.4.11 представлен пример бизнес-процесса, решающего данную задачу.

Рисунок 4.11. Схема бизнес-процесса, решающего задачу об игре в камешки


Далее приведём несколько алгоритмических задач.




3. Алгоритмическая задача про хитрых врачей


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

Рисунок 4.12. Получение справок в поликлинике (основной бизнес-процесс)




Рисунок 4.13. Получение справок в поликлинике (подпроцесс)


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




4. Классическая алгоритмическая задача исследования операций - задача о дуэли


Описание начальных условий дуэли:

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


Описание последовательностей действий в бизнес-процессе:


Бизнес-процесс начинается с того, что "Первый дуэлянт" в стартовой форме выбирает "Второго дуэлянта" (Выбор происходит из списка, полученного применением отношения "Обидчики" к Первому дуэлянту).


Далее происходит дуэль:

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

После каждого выстрела обоим дуэлянтам направляются задания на ознакомление с результатом выстрела:

Если выстрел успешный, то дуэль заканчивается, противник выстрелившего дуэлянта считается проигравшим.

Если дуэлянт дошел до барьера, то дальше он идти не может, он может только сделать выстрел.

Если выстрел не успешный и второй противник ранее тоже сделал неуспешный выстрел, то дуэль заканчивается с результатом "Ничья".

Если выстрел не успешный, а второй противник еще не стрелял, то второй противник получает задание подойти к барьеру, после чего стреляет от барьера.

После окончания дуэли первому и второму дуэлянту направляются задания на ознакомление с результатом дуэли.




5. Алгоритмическая задача М.Гарднера о разборчивой невесте


Описание предметной области:

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


Описание последовательностей действий в бизнес-процессе:

Ведущий запускает бизнес-процесс. В стартовой форме он выбирает Невесту из списка (соответствует группе "Невесты").

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

В подпроцессе:

Каждый претендент получает задание "Ознакомиться с тем, что невеста рассматривает претендентов и ввести свой рейтинг". Форма задания содержит имя Невесты и поле для ввода рейтинга претендента (вещественное число). После этого экземпляр подпроцесса завершается.

В родительском процессе (после завершения всех экземпляров подпроцесса) Невеста последовательно начинает получать задания "Рассмотреть претендента", задание предусматривает две возможные реакции Невесты: "Отказать" и "Согласиться". В форме задания Невеста видит рейтинг текущего претендента, номер претендента по порядку и количество всех претендентов.

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

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

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


Пример решения:

Рисунок 4.14. "Разборчивая невеста"

Внедрение BPMS

1. Возможное сопротивление изменениям


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

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

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

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

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

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

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

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

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

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

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

Очень полезно так разработать исполнимые бизнес-процессы, чтобы нагрузка на персонал снизилась при том, что объем выполняемой работы не уменьшился. Часто этого можно добиться при помощи автоматической генерации документов, которые до внедрения бизнес-процессов создавались сотрудниками вручную. Также можно снизить нагрузку путем исключения дублирования ввода данных в разных подразделениях, через которые «проходит» внедряемый бизнес-процесс. В таких случаях, убедившись на собственном опыте, что внедрение бизнес-процессов облегчает выполнение текущей работы, сотрудники начинают положительно относиться к внедряемой BPMS.




2. Вовлечение персонала


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

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

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

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

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

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




3. Обучение пользователей


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

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

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

После обучения менеджеры среднего звена должны быть готовы отвечать на вопросы, важные для их непосредственных подчиненных: «Как изменится моя работа?», «Изменятся ли мои обязанности?», «Кто поможет мне в случае затруднений?» «Изменится ли система поощрения?», «Изменятся ли критерии оценки?». При изменениях и менеджеры, и персонал хотят услышать от своего непосредственного руководителя, как изменения отразятся на них персонально.




4. Внедрение бизнес-процессов в эксплуатацию


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

Если же это бизнес-процессы, затрагивающие всех сотрудников предприятия, то сначала они внедряются в одном – двух отделах, а вся остальная компания продолжает работать по-старому. В качестве первых подразделений имеет смысл выбирать «обслуживающие» предприятие отделы с относительно спокойной размеренной деятельностью: ИТ-отдел, кадровая служба, бухгалтерия, отдел маркетинга и т.п.. В этих подразделениях фиксируются и исправляются все обнаруженные проблемы и логические ошибки бизнес-процессов, бизнес-процессы корректируются с учетом обнаруженных факторов, пропущенных при проектировании. На каждом следующем этапе количество сотрудников в «подключаемых» подразделениях примерно удваивается и процедура адаптации бизнес-процессов повторяется. Количество новых неучтенных факторов при этом, как правило, уменьшается, поэтому трудоемкость каждого этапа внедрения не возрастает, несмотря на увеличение числа «подключаемых» к бизнес-процессам сотрудников. Так продолжается, пока на работу с внедряемым набором бизнес-процессов не будут переведены все сотрудники предприятия.

На данном этапе необходимо следить, чтобы в переводимых на процессное управление подразделениях не оставалось возможности выполнять операции по-старому, «в обход» бизнес-процессов. Это достигается, если руководители подразделений отказываются совершать относящиеся к внедряемым бизнес-процессам действия (подписывать документы, выделять ресурсы, рассматривать заявки и т.п.) не через BPMS.

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

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

В результате внедрения BPMS менеджмент получает недостижимый ранее уровень контроля. Становится доступен обзор всех совершаемых бизнес-операций. Становится возможным привязать деятельность предприятия к конечной продукции, а затраты - к бизнес-процессам, выявить «слабые места» в управлении и процессах создания продукции.

Анализ бизнес-процессов

Применяется два вида анализа бизнес-процессов:

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

2. Для последующего перепроектирования бизнес-процессов (Чтобы после этого "Делать правильные вещи").

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

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

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

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

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

На этапе анализа могут применяться следующие способы сбора информации (совпадающие с некоторыми способами, используемыми на этапе проектирования):

• Изучение документации
• Интервью
• Опрос
• Совещание экспертов.

Анализ бизнес-процессов исследует выполнение действий бизнес-процессов и измеряет результаты этих действий, сопоставляя их с целями бизнеса.

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

1. Проверка эффективности эксплуатирующихся бизнес-процессов



Анализ затрат по действиям

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

• простое снижение затрат
• оценка величины прироста показателя результативности бизнес-процесса в сравнении с увеличением величины затрат.


Анализ чувствительности

Анализ чувствительности, также известный как анализ «что если», призван оценить возможное влияние изменений, вносимых в параметры или в действия бизнес-процесса. В результате анализа получаются следующие характеристики:

• Чувствительность процесса: Это измерение того, насколько хорошо бизнес-процесс выдерживает изменения различных параметров, таких как увеличение/уменьшение определенных ресурсов или увеличение/уменьшение времени. Это позволяет прогнозировать возникновение "узких мест" для различных комбинаций параметров.
• Вариативность бизнес-процесса: Это измерение того, как меняется результат экземпляра бизнес-процесса при изменении его параметров. Уменьшение диапазона вариаций может быть одной из целей усовершенствования бизнес-процесса.


Анализ рисков

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


Метрики эффективности

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


Анализ взаимодействия с заказчиком

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


Анализ точек передач ответственности

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


Анализ бизнес-правил

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


Анализ производительности

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


Анализ узких мест

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




2. Измерение эффективности бизнес-процессов


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

То есть, для каждого вида измерения надо сформулировать следующее:

• Цель измерения
• Что надо измерять
• Где измерять
• Как измерять
• С чем сопоставлять результаты измерения
• Ответственный за измерение.

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

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




3. Отчет по результатам анализа


Завершающий этап анализа - подготовка отчета по его результатам.

Отчет может включать следующие пункты):

• Обзор текущей бизнес-среды
• Назначение каждого бизнес-процесса
• Описание каждого процесса
• Количественные результаты изменения эффективности по каждому бизнес-процессу и по совокупности
• Потенциал повышения эффективности бизнес-процессов
• Причины неэффективности бизнес-процессов
• Избыточные действия, которые можно устранить, и ожидаемая экономия
• Рекомендуемые изменения бизнес-процессов.

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

Управление эффективностью бизнес-процессов

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

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

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

Управление эффективностью включает в себя постоянный анализ результативности. Если результативность не устраивает, то производительность не имеет значения: нет смысла делать неправильные вещи быстрее и более производительно. Всё должно оцениваться с точки зрения вклада в конечную продукцию или услугу. Целью управления эффективностью бизнес-процесса является доведение до совершенства того, что следует делать, а не просто того, что делается сейчас.

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

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

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

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

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

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

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

1. Работа с бизнес-правилами


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

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


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

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

• Объединять бизнес-процессы в группы
• Уменьшать число передач ответственности между подразделениями
• Избегать дублирования ввода информации в бизнес-процесс (группу родственных бизнес-процессов)
• При проектировании бизнес-процессов учитывать желаемые показатели эффективности.


При перепроектировании бизнес-процессов производится следующее:

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




2. Имитационное моделирование


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

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

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

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

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




3. Регулярные отчеты по результатам мониторинга


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

Ежедневный мониторинг:

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

Управление бизнесом путем трансформации бизнес-процессов

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

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

Также собственники предприятия могут принять решение об изменении стратегии и целей бизнеса.

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

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

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

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

Далее можно оценить масштаб трансформации и установить связь между изменением бизнес-процессов и ожидаемым эффектом. Это позволяет спроектировать концептуально новые бизнес-процессы.

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

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

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

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

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

Правильно проводимая трансформация должна:

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

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

Модель верхнего уровня задает систему координат для построения схем бизнес-процессов «как будет». С помощью имитационного моделирования проектная команда может проверить соответствие модели требованиям верхнего уровня и целям трансформации.

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

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

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

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

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

Стандарты и концепции, связанные с СУБПиАР

Графические нотации BPMN и UML Activity Diagram

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

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

Наиболее известными графическими нотациями изображения бизнес-процессов являются:

• BPMN
• UML Activity Diagram (далее UML AD).

В работе Stephen A. White Process Modeling Notations and Workflow Patterns, посвященной сравнению выразительной мощи UML AD и BPMN нотаций, основанной на реализациях с помощью этих нотаций типичных конструкций бизнес-процессов, содержится вывод, что выразительная мощь основных конструкций обеих нотаций примерно одинакова. Позже этот результат был подтвержден в более полном исследовании: Lauri Eloranta, Eero Kallio, Ilkka Terho A Notation Evaluation of BPMN and UML Activity Diagrams.

Рассмотрим базовые элементы обеих нотаций, относящиеся к перспективе потока управления.

1. Базовые элементы нотации BPMN, относящиеся к перспективе потока управления:



Узел-Действие

Рисунок 5.01. Узел-действие


Маршрутные узлы:

В BPMN существует единая форма для маршрутного узла, представляющая собой ромбик:

Рисунок 5.02. Маршрутный узел


Конкретные маршрутные узлы отличаются изображенными внутри этой формы иконками.


Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рисунок 5.03. Ветвление

Внутри ромбика содержится иконка – «крестик».


Разделение - Разделение точки управления на несколько точек управления:

Рисунок 5.04. Разделение


Внутри ромбика содержится иконка – «плюсик».


Слияние - Слияние точек управления в одну точку управления:

Рисунок 5.05. Слияние


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




2. Базовые элементы нотации UML AD, относящиеся к перспективе потока управления:



Узел-Действие

Рисунок 5.06. Узел-Действие


Маршрутные узлы:


Ветвление - Узел выбора направления дальнейшего движения точки управления:

Рисунок 5.07. Ветвление


Разделение - Разделение точки управления на несколько точек управления:

Рисунок 5.08. Разделение


Слияние - Слияние точек управления в одну точку управления:

Рисунок 5.09. Слияние




3. Сравнение графических нотаций


Нотация BPMN – имеет более универсальные элементы. Элементы BPMN-нотации определяются парой графических объектов – формой элемента и изображенной внутри нее иконкой. Например, форма для всех маршрутных узлов BPMN одинакова, а поведение определяется иконкой: «крестик» соответствует выбору одного из нескольких направлений, а «плюсик» - разделению точки управления на несколько одновременно перемещающихся точек. Это позволяет использовать различные комбинации форм и иконок вместо того, чтобы вводить новые графические элементы и таким образом можно уменьшить общее число используемых в нотации объектов, сохраняя выразительность и функциональность нотации.

UML AD нотация проще для изучения неподготовленным пользователем, она интуитивно более понятна. UML AD нотация использует хотя и не универсальные, но широко известные графические элементы. Например, в ней для выбора одного из нескольких направлений используется «ромбик». А параллельно выполняющиеся узлы-действия в UML AD нотации как правило соединены с элементами – разделениями-слияниями параллельными линиями, что интуитивно соответствует одновременно выполняющимся действиям.

В UML AD нотации изображение процессов очень похоже на блок-схемы, которые изучаются в российских технических ВУЗах и техникумах. В начальной школе при изучении математики в некоторых учебниках также активно используются те же блок-схемы (Петерсон Л. Г. Математика. Учебники для 1-4 класса. Ювента. 2009). То есть многим российским пользователям изображения в UML AD нотации сразу будут интуитивно понятны, а для понимания изображений в BPMN нотации придется потратить время и усилия на ее изучение.

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




4. Пример процесса «заявка на платеж» в BPMN-нотации

Рисунок 5.10. Пример процесса «заявка на платеж» в BPMN-нотации




5. Пример процесса «заявка на платеж» в UML-нотации

Рисунок 5.11. Пример процесса «заявка на платеж» в UML-нотации


Для того, чтобы объяснять схемы несложных бизнес-процессов, нарисованные в UML AD нотации, не требуется много усилий. В случае же BPMN нотации требуются учебные курсы и различные консультации.

Кратко преимущества нотаций можно сформулировать так:

Преимущества UML нотации относительно BPMN для российских пользователей:

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

Преимущества BPMN нотации:

• Более понятные изображения некоторых элементов (например – таймеров)
• Более удобно работать с бизнес-исключениями.

Использование бинарных отношений для упрощения инициализации ролей

1. Роли и их инициализация


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




2. Понятие «бинарное отношение»


Бинарное отношение можно рассматривать как расширение понятия функции.

Бинарным отношением над множеством исполнителей называется набор пар (a,b), в которых каждый из элементов a и b являются либо пользователем, либо группой пользователей.

Замечание. Некоторые (но не все) бинарные отношения являются функциями. Функция соответствует такому бинарному отношению, состоящему из пар (a,b), в котором для каждого значения b не существует более одной пары. Только в этом случае, выбирая каждый раз для b единственную существующую пару и выбирая из нее а, мы сможем получить функцию: a=f(b).




3. Применение понятия «бинарное отношение» к инициализации ролей


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

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

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

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




4. Использование групп пользователей при задании отношений


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

Группы пользователей служат для объединения пользователей по какому-либо признаку. Обычно группа «наследует» свойства всех групп, в которые она входит.

Зададим отношение как множество пар (Исполнитель1, Исполнитель2), в которых Исполнитель является пользователем или группой пользователей.

Инициализация роли при помощи отношения производится следующим образом:

1. Из указанной в инициализаторе роли переменной бизнес-процесса берется ее значение-Исполнитель – имя пользователя или группы пользователей. Это значение будет соответствовать правой части отношения.
2. Строится множество значений всех левых частей отношения, соответствующих данному элементу правой части. Делается это так: Для Исполнителя – значения правой части отношения находятся все группы, в которые он входит (хотя бы в одну из их подгрупп). Далее находятся все пары, определенные для данного отношения, у которых в правой части стоит Исполнитель или одна из найденных групп. Далее рассматривается множество всех левых частей этих пар.

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




5. Реализация бинарных отношений в системе RunaWFE


Концепция отношений реализована в интерфейсе RunaWFE следующим образом

1. В главном меню системы содержится пункт меню - Отношения (в английской локализации - Relations).

Рисунок 5.12. Вкладка «Отношения» в Simulation web interface


В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.

2. Для каждого исполнителя в его свойствах добавлены два раздела:

• Отношения, в которых он может находиться в левой части
• Отношения, в которых он может находиться в правой части.




Рисунок 5.13. Вкладка исполнители в Simulation web interface


Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения.




Рисунок 5.14. Редактирование отношений в Simulation web interface

Доступ к созданию новых и изменению существующих отношений имеет только пользователь, обладающий соответствующим полномочием.




Рисунок 5.15. Редактирование прав на отношение в Simulation web interface




6. Работа с отношениями в среде разработки


В среде разработки при редактировании инициализатора роли можно выбрать закладку «задать роль с помощью отношения». В этом случае можно задать настройки соединения с сервером и импортировать отношения в среду.




Рисунок 5.16. Среда разработки. Импорт процессов


Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения, а в качестве параметра может быть задана переменная формата "Пользователь", "Исполнитель", "Группа" или "Роль-дорожка".




Рисунок 5.17. Редактор инициализатора роли


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

Концепция ботов и бот-станций

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

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

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

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

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

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

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

Реализация концепции

Настройка всех бот-станций и ботов производится через меню «Бот станции».

Рисунок 5.18. Меню редактора Бот-станции

Пользователь имеет доступ к меню «Бот станции», если у него есть права на чтение бот-станций. Если прав на чтение бот-станций у пользователя нет, то пункт меню «Бот станции» интерфейсе пользователя будет отсутствовать. Для изменения настроек бот-станций необходимо иметь право «Изменять». Для изменения полномочий необходимо иметь права "Изменять полномочия".

Для изменения параметров бота необходимо выбрать изменяемого бота на странице информации по бот-станции, перейдя по ссылке с именем бота. Изменение параметров бота производится в секции “Параметры бота”. После выполнения команды “Применить” новые параметры вступят в силу немедленно без перезапуска системы и будут использованы при очередном вызове ботов.

Рисунок 5.19. Работа с Бот-станциями

Параметрами бота являются: имя бота (соответствует логину пользователя), пароль бота, опция включения последовательного выполнения заданий в одном потоке в рамках бота, список заданий, выполняемых ботом. Список заданий состоит из имени задания, ссылки на обработчик, конфигурации задания и режима выполнения. Опция “Последовательное выполнение” позволяет установить особый режим, при котором данная задача будет выполняться последовательно в одном потоке в рамках данной задачи.

Рисунок 5.20. Параметры бота

Кроме того, разработку бот станции, ботов и их задач можно вести и в среде разработки.

Рисунок 5.21. Бот станция в среде разработки

Замещение исполнителей заданий

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

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

Оба этих решения неудобны:

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

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

1. Описание правила назначения заместителя


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

Список параметров правила:

• Замещаемый Пользователь (Пользователь)
• Заместитель (Функция над орг-структурой, возвращающая Пользователя)
• Критерий применимости правила (Формула).

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

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




2. Реализация в системе RunaWFE


В свойствах пользователя можно задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:

• Заместитель (Функция над организационной структурой предприятия, возвращающая пользователя-заместителя)
• Условие применения правила (Критерий).


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

Правила замещения могут быть двух видов:

• “Правило” – определяет, кем надо замещать Исполнителя в определенном случае
• “Терминатор” – определяет, что в определенном случае Исполнителя замещать не надо.




Рисунок 5.22. Корректировка правил замещения сотрудников


У пользователя может быть одно из двух состояний:

• Активен
• Не активен.

Механизм замещения применяется только к пользователям, имеющим статус «Не активен».

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

Для каждого правила замещения с установленной галочкой «Применить» проверяется следующее:

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

В список заданий пользователя, выбранного заместителем, и будет перенаправлено данное задание.

Замечание. Возможны ситуации, в которых у Пользователя не будет заместителя.

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

Список литературы

1. BPM CBOK 3.0. Свод знаний по управлению бизнес-процессами. Перевод с английского под редакцией Белайчука А.А., Елифёрова В.Г. М.: АПУБП, 2015
2. Михеев А. Г., Орлов М. В. Перспективы Workflow-систем // PC Week/RE, №№ 23 2004, 28 2004, 43 2004, 36 2005
3. Mikheev A.G., Pyatetskiy V.E. Designing executable business processes as a programming paradigm //Business Informatics. 2016. No. 1 (35). DOI: 10.17323/1998-0663.2016.1.45.56
4. Тельнов Ю.Ф. Реинжиниринг бизнес-процессов: Компонентная методология. – М.: Финансы и статистика, 2004
5. Кловпулос Т. Необходимость Workflow. – М. Весть-МетаТехнология 2000
6. S. Jablonski and C. Bussler. Workfow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, London, UK, 1996
7. Михеев А. Г. Системы управления бизнес-процессами и административными регламентами на примере свободной программы RunaWFE – М.: ALT Linux, 2011
8. Куликов Г. Г., Михеев А. Г., Орлов М. В., Габбасов Р. К., Антонов Д. В. Изучение методологии BPMN на примере программного продукта RunaWFE. Лабораторный практикум по дисциплине «Автоматизированные информационные системы в производстве» и «Автоматизированные информационные системы в экономике». - Уфа. УГАТУ. 2010
9. Куликов Г. Г., Михеев А. Г. Особенности реализации процессного подхода и обучения управлению бизнес-процессами при помощи свободного ПО с открытым кодом. / Открытое образование, № 4 2011 с. 47 – 57
10. Документация Runa WFE [официальный сайт проекта]. URL: https://runawfe.ru/rus/doc/Документация

Нерешённые вопросы

1. По тексту получается, что уровни бизнес-процессов

   1 Уровень операций

   2 Уровень шагов выполнения задачи

   3 Уровень исполнителя
   являются подчинёнными по отношению к уровню "Уровень бизнеса". Так ли это?

2. Уровни "Уровень шагов выполнения задачи" и "Уровень исполнителя" на мой взгляд являются идентичными. И там, и там идёт речь о шагах операции. В чём отличие?
3. Скрин-шоты, относящиеся к DS (разделы 5.2 и далее) сильно устарели и требуют замены на более продвинутую версию и с синими эмблемами.
4. Раздел "5.4 Замещение исполнителей заданий" требует проработки. Здесь произошло пересечение бытового понимания "Исполнителя" как физического лица, исполняющего данное задание, и типа данных "Исполнитель", который включает как физических пользователей, так и их группы. Разумно было бы вместо типов переменных "Пользователь" и "Исполнитель" ввести типы с иным звучанием (например, "Кракен" и "Суперкракен" ;-))) ). Наложение бытового понимания на определения может вводить в заблуждение, особенно начинающих пользователей.