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

Федоров Игорь Григорьевич, Профессор кафедры ПИЭ, Центр компетенции процессного управления МЭСИ

Не вполне корректно называть моделью процесса диаграмму описывающую только отдельные аспекты поведения бизнес-процесса. Модель процесса есть взаимоувязанное описание Функциональной, Поведенческой, Информационной и Организационной перспектив. Для описания Поведенческой перспективы следует использовать Диаграмму потока управления, которая дает исчерпывающий ответ на вопрос «Как исполняется процесс» и, включает бизнес-логику, бизнес-правила, расписание исполнения, имеет детализацию уровня действий и описывает все возможные сценарии исполнения. Диаграмма потоков работ, которую не вполне обоснованно называют моделью процесса, не описывают все многообразие поведения процесса и не в полной мере дает описание динамики процесса. Можно констатировать, что многие модели, которые используются в практике реинжиниринга, не удовлетворяют всем перечисленным требованиям, предъявляемым к процессным, и потому не могут называться процессными.

Введение

Сейчас очень популярно сравнивать нотации и языки моделирования бизнес-процессов (БП) [1,2]. Анализу подвергаются возможности нотаций для описания процессов [3,4], синтаксис и набор примитивов языка описания и т.д. Однако, как будет показано в данной работе, сравнивать нотации и языки описания процесса путем анализа их функциональности не вполне корректно.

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

Модели и перспективы

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

Сложный объект, коим является БП, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей называется перспективой [5], с ней связан главный вопрос, на который должна давать ответ соответствующая модель. Первоначально, выделялись четыре перспективы модели БП:

1.       Функциональная: отвечает на вопрос: «Что делают участники?», описывает состав выполняемых работ.

2.       Поведенческая: отвечает на вопрос: «Как работают участники?», описывает очередность, расписание выполнения, бизнес-правила.

3.       Информационная: отвечает на вопрос: «Что обрабатывают участники?», описывает бизнес сущности, предметной области процесса.

4.       Организационная: отвечает на вопрос: «Кто выполняет работу?», описывает состав и структуру исполнителей.

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

Рисунок 1. Перспективы процесса

Функциональная перспектива

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

Часто функциональную модель ошибочно называют картой процессов. В качестве примера назову модели SCOR, ETOM, которые сдержат иерархии функций и цепочки создания ценности, но отнюдь не процессы [6] в нашем понимании. Даже руководящие документы TeleManagement Forum призывают различать  процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы

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

●   В какой очередности выполняются операции, образующие процесс?

●   В какое время выполняется операция?

●   Почему операции исполняются в заданной очередности?

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

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

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

Рассмотрим три аспекта поведенческой перспективы более подробно.

Бизнес-логика процесса

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

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

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

Бизнес правила

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

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

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

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

●   Правила классификации, помогают проверить истинность фактов. Например, клиент считаеся VIP, если на его счете имеется определенная сумма денег и он не имел задолжности по платежам.

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

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

Из сказанного следует практическая рекомендация – следует явно выделять Правила определения в отдельные конструкции на диаграмме потоков работ. Это поможет аналитику четко локализовать соответствующую логику.

Расписание исполнения процесса

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

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

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

Степень детализации бизнес-логики процесса

Что бы ответить на вопрос «Как?», диаграмма процесса должна содержать максимально подробное описание действий, образующих процесс. Многие аналитики ограничиваются перечислением функций, без указания деталей их исполнения. Этот подход предполагает, что исполнитель знает, как следует выполнить работу. Однако на практике сотрудники склонны выполнять работу с учетом своего индивидуального опыта, приобретенного на предприятиях с отличной организацией труда и производственной культурой, что приводит к высокой вариативности исполнения процесса.

Руководящий документ Госстандарта России, «Методология Функционального Моделирования IDEF0» [9] вводит понятия Действия и Операции. Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а Операция - как «совокупность последовательно или/и параллельно выполняемых Действий».

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

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

Степень полноты бизнес-логики процесса

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

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

Модель процесса, диаграммы управления и потоков работ

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

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

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

Обсуждение: почему возникают проблемы трансляции диаграммы EPC в исполняемый формат

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

Нотации, включенные в ARIS, обладают чрезвычайно широкими возможностями по моделированию процессов, но, к сожалению, они не подкреплены открытыми и доступными для пользователей методологиями. Находящийся в открытом доступе документ, называемый «Методология ARIS» [11], описывает не методологию, а правила применения нотации, что допускает широкие возможности по «интерпретации» способов моделирования.

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

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

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

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

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

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

Выводы

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

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

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

Диаграмма потоков работ, которую не обоснованно называют моделью процесса, не описывает всех деталей поведения процесса и не является процессной диаграммой. Можно констатировать, что многие модели, которые используются в практике реинжиниринга, не удовлетворяют всем перечисленным требованиям и потому не могут называться процессными. Вдумаемся, Хаммер и Чампи [12] призвали нас заменить функциональное управление на процессное, а мы, что бы реализовать их призыв, производим функциональное моделирование бизнес-процессов (БП). Возникает законный вопрос: можно ли переходить к процессному управлению через функциональное моделирование, нет ли тут противоречия? Может в этом кроется неудача многих проектов реинжиниринга БП?

Литература:

1.   Stein, Dr. Sebastian. EPC vs. BPMN - the perfect flamewar. ARIS Community. [Online] Software AG, 04 15 , 2010. http://www.ariscommunity.com/users/sstein/2010-04-15-epc-vs-bpmn-perfect-flamewar.

2.   van der Weel, Harald. Will BPMN completely replace EPC? BrainStormCentral. [Online] 1 16, 2011.

3.   Kiepuszewski В., ter Hofstede A.H.M., van der Aalst W.M.P.: Fundamentals of Control Flow in Workows,

4.   Schluchter, S. SAP Network Blog: BPMN or EPC? SAP Network Blog. [Online] 07 14, 2006. [Cited: 02 14, 2010.] http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3974.

5.   Curtis, B., M., Kellner and Over, J. Process Modeling. 1992. pp. 75-90.

6.   eTOM, Representative process flows. ITU. s.l. : TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU, 2004.

7.   Ross R., Principles of the Business Rule Approach. Addison-Wesley Professional(2003).

8.   Pedrinaci1 C., Domingue ., Alves de Medeiros A., A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008

9.   МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0. Москва : ГОССТАНДАРТ РОССИИ, 2000.

10. Tscheschner, W. Transformation from EPC to BPMN. [Online] http://bpt.hpi.uni-potsdam.de/pub/Public/OryxResearch/TransformEPC2BPMN.pdf.

11. Methods ARIS 7.0. Saarbrücken : IDS Scheer AG, 2005.

12. Hammer, M. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review. July-August 1990, pp. pp104-112.

Статья опубликована в авторском варианте, более полном, чем в Источнике.

Источник: Журнал «Открытые системы», № 08, 2011