Описание процессов с помощью BPM-систем

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

 

При этом, в соответствии с глоссарием консорциума Workflow Management Coalition (WfMC), под описанием процесса понимается представление бизнес-процесса в форме, допускающей автоматизированное манипулирование (например, моделирование) или реализацию его с помощью системы управления Workflow, или, как теперь принято называть данную категорию программного обеспечения, системой управления бизнес-процессами (Business Process Management System – BPMS).

 

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

 

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

 

Для решения задач описания процессов существует множество инструментов, как встроенных в BPM-системы, так и существующих в виде отдельных продуктов. Примерами специализированных инструментов являются продукты семейства ARIS Platform компании IDS Scheer (такие как ARIS Toolset) и AllFusion Process Modeler (бывший BPwin) компании Computer Associates. Применение специализированных инструментов позволяет обеспечить высокое качество и полноту описания бизнес-процессов. Однако нужно понимать, что для автоматизации описанных процессов требуется внедрение BPM-систем.

 

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

 

Нужно отметить, что они не обладают такой функциональностью, как у специализированных систем, но зато полученное описание процессов без дополнительных интерфейсов может быть использовано при автоматизации процесса. В качестве примеров, встроенных в BPMS средств описания, можно привести модуль Process Design системы Ultimus Adaptive BPM Suite, который позволяет описать процесс и даже провести его имитационное моделирование, или IBM WebSphere Business Modeler, где тоже существует нотация, предназначенная для описания процессов. Конечно, получаемое описание процессов больше интересно ИТ–специалистам, нежели бизнес–пользователям, но в тоже время данные продукты дешевле специализированных систем.

 

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

 

Пример описания процесса в BPM-системе представлен на рис.1. Рис.1.

 

Описание процесса в BPM-системе Ultimus

 

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

 

Целью моделирования является уверенность в том, что построенный процесс будет вести себя так, как ожидается, и результаты его работы будут соответствовать требованиям владельцев процесса. Моделирование отвечает на вопросы типа: - Сколько инцидентов (или экземпляров) бизнес-процесса может быть выполнено в течение недели? - Если инциденты происходят 100 раз в день – какова должна быть численность персонала, чтобы каждый из инцидентов выполнялся в течение 3-х дней? - Какова стоимость шага «Проверка заказа» в процессе обработки заказа? - Если число сотрудников, обрабатывающих рекламации, сократится вдвое – насколько дольше будет проводиться обработка рекламации?

 

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

 

Описание организационной структуры с помощью BPM-систем

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

 

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

 

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

 

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

 

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

 

Рис.2. Описание организационной структуры в BPM-системе Ultimus

 

Автоматизация процессов с помощью BPM систем

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

 

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

 

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

 

Главные требования к среде разработки BPM-системы можно определить следующим образом: Совместная разработка процессов; Моделирование и автоматизация процессов; Определение логики процессов; Создание электронных форм; Связывание форм с базами данных; Создание компонентов, позволяющих многократное использование; Имитационное моделирование и тестирование; Возможность использования внешних редакторов; Документирование процессов; Публикация/развертывание процессов. Одним из основных компонентов BPM системы является сервер выполнения бизнес-процессов (ядро workflow), в рамках которого происходит назначение задач и контроль выполнения потоков работ. В соответствии с глоссарием WfMC сервер – это программный модуль или «ядро», обеспечивающее среду для выполнения экземпляра процесса в реальных условиях.

 

При этом ядро workflow / BPM предоставляет операционные функции, поддерживающие выполнение экземпляров бизнес-процессов на основе описаний процессов. К числу этих функций относятся: интерпретация описания процесса; создание экземпляров процесса и управление их выполнением, включая запуск, остановку, приостановку, возобновление и т.д.; навигация между функциями и создание надлежащих рабочих объектов для обработки этими функциями; функции надзора и управления. Фактически на сервер «выкладывается» процесс, и сервер маршрутизирует задачи, интерпретируя логику процессов, и контролирует прохождение потока работ. Как и в большинстве информационных систем, для работы с системой необходимо клиентское приложение, в котором будут работать пользователи, получая задачи и выполняя их в рамках процессов.

 

В соответствии с глоссарием WfMC, клиентское место — это приложение, которое взаимодействует с ядром workflow/BPM, запрашивая у него задачи. К основным основным выполняемым функциям пользовательского места BPM -системы относятся: Обработка списка работ; Инициация, приостановка/возобновление экземпляра процесса; Извлечение и манипулирование данными описания процесса; Различные функции системного администрирования (например, приостановка использования некоторых описаний процессов). Нужно отметить, что стандартной практикой для BPM-системы является использование «тонких» клиентских мест (например, на основе веб-браузеров), не требующих установки и позволяющих централизованное администрирование (рис.3.).

 

Рис.3. Клиентское место системы Ultimus

Контроль и анализ процессов с использованием средств анализа процессов

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

 

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

 

Стандартные системы OLAP (Online Analytical Processing) в настоящее время предоставляют универсальную технологию и инструментальные средства для анализа данных, способствовавшие определенному прогрессу в этой области. Но некоторые из этих подходов чрезмерно технически ориентированны и требуют значительных затрат на внедрение. Поэтому специализированные продукты могут рассматриваться в качестве средства, использующего эти технологии и применяющегося в сфере управления бизнес-процессами. Примером таких специализированных приложений являются продукты ARIS Process Performance Manager и HP Business Process Insight. Эти продукты использует реляционную базу данных для определения и агрегации данных, относящихся к выполнению бизнес-процесса и получаемых в режиме реального времени из работающих информационных систем через XML-адаптеры.

 

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

 

Пример рабочего места ARIS Process Performance Manager представлен на рис.4.

Рис.4. Клиентское место системы ARIS Process Performance Manager

 

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