Сравнение нотаций описания бизнес процессов

Cпоры о выборе нотации для моделирования бизнес-процессов по-прежнему не утихают. Анализу подвергаются возможности нотаций EPC (Event-driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. д. Однако сравнивать нотации и языки описания бизнес-процесса путем анализа их функциональности некорректно — является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес-процессов и появлению некачественных моделей.

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

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

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

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

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

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

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

Перспективы процесса

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

Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) — перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую-либо важную функцию. Если две разные организации выполняют один и тот же процесс, то функциональная декомпозиция работ у них будет одинаковой, хотя очередность исполнения работ может меняться с учетом отличий их организационной структуры. Таким образом, функциональная модель слабо зависит от организационной структуры и может рассматриваться как справочная.

Часто функциональную модель ошибочно называют картой процессов; например, модели SCOR (The Supply-Chain Operations Reference-model) и ETOM (Enhanced Telecom Operations Map) содержат иерархии функций и цепочки создания ценности, но отнюдь не процессы [ 2 ]. Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сравнительный анализ нотаций EPC и BPMN

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

Нотация EPC является средством описания бизнес-логики процесса. Как показывает сравнение [6], нотация позволяет реализовывать основные паттерны бизнес-логики, не уступая остальным нотациям описания процессов. Диаграммы EPC часто не включают бизнес-правила, однако этот недостаток следует отнести не к нотации, как таковой, а к методологии применения. Что касается расписания исполнения, то тут надо отметить отсутствие средств моделирования временных характеристик исполнения. В нотации EPC присутствует конструкция «событие», однако она применяется для описания состояния объекта управления, а не для синхронизации исполнения. Методология EPC не акцентирует внимание на степени детальности и полноты получаемых диаграмм, оставляя этот вопрос на откуп аналитику. В отсутствие жесткой регламентации аналитики стремятся обеспечить простоту и читабельность диаграмм, поэтому ограничиваются описанием уровня операций и не стремятся выявить все маршруты исполнения. Нотация EPC часто используется для автоматизации с применением функционально-ориентированных систем, где человек играет ведущую, направляющую роль, так что отсутствие какого-либо сценария исполнения не является опасным. Все это позволяет классифицировать модели EPC как диаграмму потоков работ.

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

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

Нотация BPMN описывает логику процесса. Немного лучшая поддержка паттернов бизнес-логики, по сравнению с EPC [6], не является решающим преимуществом. Нотация оперирует понятиями «событие» и «интервал времени», содержит средства синхронизации веток процесса между собой и процессов друг с другом. Сама нотация не содержит рекомендаций разделять логику и правила, но руководства по правильному стилю моделирования включают такую рекомендацию [8]. Нотация BPMN применяется для создания процессно-ориентированных систем, где человек играет подчиненную, а система — ведущую роль, поэтому пропуск одного, даже самого редкого сценария не позволит выполнить работу и, следовательно, недопустим, соответственно модели BPMN покрывают все сценарии исполнения. Модели BPMN являются исполняемыми моделями, поэтому описывают все детали, вплоть до элементарных действий. Все вышесказанное позволяет классифицировать диаграмму BPMN как модель потоков управления.

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

Проблемы трансляции диаграммы EPC в исполняемый формат

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

Перечислим типовые ошибки моделирования.

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

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

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

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

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

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

***

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

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

Литература 

1. B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
2. eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
3. R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. 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.
5. Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Игорь Федоров (Igor.Fiodorov@bpexpert.ru) – директор, «Центр компетенции процессного управления», МЭСИ (Москва).

18.09.2020

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

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

Для начала необходимо разобраться, что же такое нотация.

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

Зачем они нужны, ведь мы всегда можем нарисовать схему бизнес-процесса на листе бумаги или на доске маркером? Ответ — необходимость в автоматизации, т. е. в переводе нарисованного маркером на доске в какое-то ПО.

Мы рассмотрим 3 самых популярных на данный момент вида нотаций:

IDEF — Integration DEFinition.

Начнём с того, что IDEF — это не одна нотация, а целая группа. Они различаются по номерам (IDEF0, IDEF1, IDEF2 и т. д.) и используются для описания разных элементов бизнес-системы. 

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

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

(картинка примера IDEF)

Разберём плюсы и минусы нотации IDEF.

Плюсы:

1. Блок-схема, с использованием нотации IDEF, всегда «заточена» под лист А4. Удобно распечатывать.
2. Программ, поддерживающих IDEF, много.

Минусы:

1. Использовать модели, построенные в IDEF, сложно.
2. Построенную модель трудно анализировать.
3. Ограничения по количеству отображаемых в схеме процессов (всего 7).
4. Правила описания и чтения бизнес-процессов неудобны и сложны.
5. Программы, поддерживающие IDEF, устарели вместе с ней.

Вывод: если Вы встали перед выбором нотации для описания бизнес-процессов, то IDEF пропускаем мимо.

eEPC — extended Event-driven Process Chain.

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

За основу при разработке данной системы была взята IDEF3, однако eEPC намного нагляднее и обладает большим функционалом.

(картинка пример eEPC) 

Плюсы нотации eEPC:

1. Логика построения легка и понятна.
2. Многие ПО позволяют моделировать в eEPC.
3. Удобно изучать и анализировать.
4. Можно увидеть события, которые управляют развитием процессов.
5. Большое количество возможностей для моделирования любого процесса.

Минусы нотации eEPC:

1. Невозможно определить как происходит взаимодействие между участниками процесса.
2. События нельзя отличить по типу.
3. Дороговизна.
4. Ориентация на сложные и комплексные программные решения.

Вывод: eEPC стоит рассматривать для описания и моделирования бизнес-процессов.

BPMN 2.0 — Business Process Model and Notation.

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

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

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

Плюсы BPMN:

1. Регулярное обновление, развитие и доработка нотации.
2. Гибкость и удобство настройки.
3. Многофункциональность и простота в использовании.
4. Наличие «дорожек».
5. Возможность деления событий на типы: начало, промежуточное и окончание.
6. Возможность создавать свои собственные значки и адаптировать нотацию под свои потребности.
7. ПО с BPMN — самое активно развивающиеся. Многие программы бесплатные.
8. Подходит как для малых и средних, так и крупных компаний 
9. Возможность привязки к 1С.

Минусы:

1. В нотации много понятий и терминов. Их нужно знать и грамотно применять.
2. Высокий уровень вхождения. Из-за широкого круга возможностей нужно довольно много времени на их детальное изучение (по сравнению с другими нотациями).
3. Требуется знание бизнес-анализа. BPMN модели — не просто картинки, которые может рисовать любой ребёнок на листе А4. В этой нотации очень важная грамотная структура и последовательность.

Общий вывод: 

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

Если после прочтения статьи, у Вас возникли вопросы и Вы хотите получить на них ответы, то оставьте заявку на сайте:

Наш телефон: +7 (495) 981-63-05
Наша почта: expert@salecraft.ru

---

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

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

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

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

Сегодня в мире наиболее популярны 3 нотации:

• IDEF0.
• EPC.
• BPMN.

Когда возникли нотации?

Первая, IDEF0, возникла в армии, точнее – в ВВС США, произошло это в 1980-х годах. Целью была оптимизация работы предприятий, выпускающих военную продукцию.

Вторая, EPC (Event-driven Process Chain), появилась на 10 лет позднее. Её название (“цепочка событийных процессов”) даёт понять, что фокус сделан именно на событие.

Нотация BPMN – часть концепции BPM (управления бизнес-процессами). Впервые она возникла в 2004 году (версия 1.0) и несколько раз модернизировалась в 2008, 2009, 2011 и 2013 годах. Самая последняя версия – BPMN 2.0.2.

Рассмотрим особенности каждой из нотаций и их отличия.

Нотация IDEF0

Она позволяет создать модель, которая будет отражать:

• Структуру системы.
• Функции.
• Потоки ресурсов, информации.

Модель IDEF0 разворачивается одновременно слева направо и сверху вниз, по диагонали. Объекты, расположенные левее / выше, доминируют над теми, которые находятся правее / ниже. Доминирующие объекты могут включать в себя зависимые: например, доставка заказа – это элемент, входящий в состав более масштабного процесса управления заказами. Также доминирующие объекты могут являться предшествующими этапами для зависимых: получение заявки – согласование заявки.

Графические элементы:

• Прямоугольники – действия или этапы.
• Стрелки – ресурсы, исполнители, необходимые для совершения действия или прохождения этапа.

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

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

Нотация EPC

Она использует значительно больше элементов – разноцветных фигур.

• Розовые фигуры – события.
• Зелёные – функции (действия).
• Жёлтые — исполнители.
• Серые – ресурсы.
• Оранжевые – информационные системы.

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

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

Чтобы выстроить схему, сначала определяются стартовое / финальное событие, затем – промежуточные события, необходимые для них исполнители, ресурсы.

Достоинство EPC – простота для восприятия. Разноцветные элементы делают модель более “живой”, приятной для глаз, а это немаловажно, если требуется нарисовать схему для сотрудников или провести презентацию.

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

Главный недостаток EPC в том, что её структурной единицей является событие, поэтому приходится создавать события для любых, даже самых незначительных этапов. EPC справедливо критикуют и за обилие тавтологических элементов: задача “определить исполнителей” – событие “исполнители определены”, задача “согласовать договор” – событие “договор согласован”. Если схема длинная и сложная, такие элементы её перегружают, как и многочисленные стрелки от “исполнителей” к “”событиям”, особенно если один исполнитель отвечает за множество событий, или на одно событие назначено несколько сотрудников.

Нотация BPMN

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

Основные элементы BPMN:

• Задача (прямоугольник).
• Событие (круг).
• Шлюз, развилка (ромб).
• Поток, ход (стрелка).
• Базы данных, документы.
• Сноски.
• Пулы.

Базовая нотация BPMN включает не более 10 типов значков и помогает описать алгоритм в такой форме, которая будет понятна бизнес-пользователю, не прошедшему специального обучения. Расширенная BPMN содержит около 100 значков и позволяет сделать регламент машиночитаемым, причём не допуская разночтений.

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

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

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

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

В этой статье мы поговорим про основы бизнес-анализа и рассмотрим наиболее популярные на сегодня нотации моделирования UML, BPMN и EPC, а также покажем, почему структурные методы IDEF0, IDEF1 и DFD до сих пор актуальны. Читайте в этом материале, где и как использовать различные нотации бизнес-моделирования и что рекомендует руководство BABOK.

Что такое бизнес-моделирование: взгляд BABOK на многообразие нотаций

Прежде всего отметим, что цель этой статьи – не научить читателя рисовать диаграммы в той или иной нотации моделирования, а показать возможности этих инструментов для практикующего бизнес-аналитика. Начнем с определения: нотация бизнес-моделирования – это система графических элементов, символов и условных обозначений, для описания процессов или систем, позволяющая описать ключевые понятия предметной области и их взаимоотношения. Используемые при этом символы, условные и графические обозначения составляют алфавит нотации, с которым можно работать по специальным правилам применения его элементов [1]. Существует множество нотаций, используемых при описании бизнес-процессов и проектировании информационных систем, например, один только стандарт UML (Unified Modeling Language) включает 12 видов диаграмм для объектного моделирования при разработке программного обеспечения [2].

Семейство стандартов IDEF (ICAM или Integrated DEFinition) насчитывает целых 14 методологий, каждая из которых предназначена для моделирования процессов или систем с определенной точки зрения. Например, IDEF0 наглядно показывает структуру процессов и систем за счет функциональной декомпозиции, IDEF1x используется при проектировании реляционных баз данных, позволяя создавать ERD-диаграммы (Entity Relationship Diagram), с помощью IDEF3 можно документировать логику выполнения процесса и пр. [3]. Наконец, среди наиболее часто используемых на практике нотаций стоит упомянуть DFD (Data Flow Diagram, диаграммы потоков данных), EPC (Event-driven Process Chain, событийная цепочка процессов) и BPMN (Business Process Management Notation, нотация моделирования бизнес-процессов).

Некоторые из перечисленных нотаций частично дублируют назначение друг друга и даже похожи визуально. К примеру, у BPMN очень много общего с EPC и UML-диаграммой деятельности (Activity Diagram), а также процессным методом IDEF3 [4]. В свою очередь, объектный метод IDEF3 пересекается с UML-диаграммой состояний (State Diagram) [5], а IDEF4 вообще включает целый набор методов, аналогичных UML, позволяя проектировать систему «сверху вниз» через моделирование классов, объектов и взаимоотношений между ними [6].

Чтобы не запутаться в многообразии различных нотаций моделирования, бизнес-аналитику стоит помнить, что все эти диаграммы – всего лишь инструмент для описания процесса или системы с определенного ракурса. В частности, профессиональное руководство BABOK (Business Analysis Body of Knowledge) по бизнес-анализу [7], о котором мы рассказывали здесь, поясняет, что для комплексного описания системы следует использовать несколько нотаций моделирования, т.к. ни одна точка зрения не может автономно определить всю архитектуру сложного объекта. Более того, BABOK подчеркивает, что попытки вложить слишком много информации в одну точку зрения и представить все аспекты сложной системы, таких как набор требований к программному обеспечению, архитектура предприятия, корпоративные бизнес-процессы и пр., только усложнят видение и не позволят получить модели приемлемого качества.

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

Структура и динамика: как описать системы и бизнес-процессы

Все многообразие нотаций бизнес-моделирования можно разделить на 2 категории:

• Структурные, которые показывают компонентный состав исследуемого объекта и взаимосвязи между его элементами. Например, UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. Из нотаций стандарта IDEF к структурным относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF.
• Динамические, которые показывают движение потоков данных или логику выполнения процессов. Например, DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

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

• в задачах системного анализа и синтеза, таких как разработка совершенно нового технического продукта (ракета, автомобиль и пр.), преимущественно используются комплексные методологии семейства IDEF, позволяющие проектировать систему «сверху вниз» за счет функциональной декомпозиции – разбиения сложного объекта на более простые элементы с их последующим описанием;
• при разработке требований к программному обеспечению и документировании готового решения чаще всего применяется стандарт UML, позволяющий описать проектируемый продукт в объектно-ориентированных терминах. Для описания структуры базы данных используется ERD-нотация IDEF1x (Extended). А DFD-диаграмма наглядно продемонстрирует движение потоков данных между различными хранилищами (СУБД, файлы, бумажные и другие материальные носители) и процессами по их преобразованию. Подробнее о том, как разработать DFD-диаграмму, читайте здесь.
• для описания бизнес-процессов предприятия с целью их анализа и последующей оптимизации используются нотации IDEF0, BPMN, EPC. При этом указанные методы отлично дополняют друг друга, детализируясь от структуры метапроцессов, таких как «продвижение и продажи», «осуществление основного вида деятельности» и пр., представленных в IDEF0, к пошаговым алгоритмам, показывающим логику исполнения процессов в виде EPC- или BPMN-диаграмм. Например, именно такой подход реализован в популярной отечественной системе бизнес-моделирования Business Studio [8]. Подробнее о достоинствах и недостатках IDEF0, а также примерах практического использования этой нотации, которая сегодня несправедливо считается устаревшей и неактуальной, читайте в нашей новой статье.

В заключение отметим, что все рассмотренные и другие нотации бизнес-моделирования, в первую очередь, предназначены для аналитика и могут показаться сложными для руководителя или специалиста другой предметной области. В частности, руководство BABOK отмечает, что UML и BPMN-диаграммы в большинстве случаев кажутся стейкхолдерам слишком «техническими», что затрудняет восприятие информации. Поэтому при выборе нотации как инструмента моделирования следует помнить не только о цели (что хотим описать), но и о целевой аудитории (кому будем показывать). К примеру, схемы EPC, ярко и понятно описывающие алгоритм выполнения отдельных процессов, достаточно легко воспринимаются бизнес-пользователями. Что общего между EPC и BPMN нотациями, я рассказываю в этом материале.

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

Освоить все рассмотренные нотации моделирования и их применение на практике вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
• Основы бизнес-анализа: вход в профессию для начинающих
• UML для бизнес-аналитика

Источники

1. https://ru.wikipedia.org/wiki/Нотация
2. https://ru.wikipedia.org/wiki/UML
3. https://ru.wikipedia.org/wiki/IDEF
4. https://ru.wikipedia.org/wiki/BPMN
5. https://ru.wikipedia.org/wiki/IDEF3
6. https://en.wikipedia.org/wiki/IDEF4
7. https://www.iiba.org/standards-and-resources/babok/
8. https://www.businessstudio.ru/products/business_studio/notations/

В.В.Репин

Оглавление

1. Введение. Типовые задачи описания бизнес-процессов.
   Требования к описанию бизнес-процессов предприятий.
2. Описание нотации ARIS eEPC.
3. Описание нотации IDEF0, IDEF3.
4. Сравнительный анализ нотаций ARIS и IDEF.
5. Функциональные возможности продуктов ARIS и BPwin.
6. Выводы. Рекомендации по применению систем в зависимости от типовых задач.

Введение. Типовые задачи описания бизнес-процессов. Требования к описанию бизнес-процессов предприятий.

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

1. какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
2. как моделировать процессы с использованием продукта «Х»?;
3. как проводить анализ и выявлять проблемы при помощи продукта «Х»?;
4. какую методологию использовать для описания процессов?

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

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

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

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

1. какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
2. в какой последовательности выполняются эти процедуры;
3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
4. кто выполняет процедуры процесса;
5. какие входящие документы/информацию использует каждая процедура процесса;
6. какие исходящие документы/информацию генерирует процедура процесса;
7. какие ресурсы необходимы для выполнения каждой процедуры процесса;
8. какая документация/условия регламентирует выполнение процедуры;
9. какие параметры характеризуют выполнение процедур и процесса в целом.

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

Описание нотации ARIS eEPC

Нотация ARIS eEPC расшифровывается следующим образом — Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты.

Таблица 1

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

Рисунок 1.

На рисунке 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

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

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

На рисунке 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Рисунок 2.

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

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

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Пример моделей, сформированных с использованием ARIS eEPC, показаны на рисунках 3-4.

Рисунок 3.

Рисунок 4.

Описание нотации IDEF0, IDEF3

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.

Таблица 2

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

Таблица 3

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

Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).

Рисунок 5.

На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.

Рисунок 6.

В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.

Сравнительный анализ нотаций ARIS и IDEF

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.

Таблица 4

Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90% (см. пример на следующем рисунке).

Рисунок 7. Недостатки описания бизнес-процесса в ARIS eEPC.

На рисунке 7 Функция 4 является контрольной и служит для проверки результатов выполнения работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:

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

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

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

Функциональные возможности продуктов ARIS и BPwin

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в следующей таблице.

Таблица 5

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В ModelMart так же предусмотрено администрирование базы данных.

Часто одним из недостатков BPwin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPwin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

Выводы. Рекомендации по применению систем в зависимости от типовых задач

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

Таблица 6

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 8).

Рисунок 8.

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

В статье Владимира Репина рассмотрены три нотации моделирования бизнес-процессов, при помощи которых можно создавать графические диаграммы с использованием продукта Business Studio: «Процедура», eEPC, BPMN.
Обсуждаются преимущества и недостатки каждой нотации. Приводится сравнительный анализ и рекомендации по выбору нотации для описания бизнес-процессов компании.

Введение

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

В Business Studio представлено три нотации, которые можно для этого использовать: «Процедура», eEPC, BPMN.

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

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

Нотация «Процедура»

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

Рассмотрим ключевые преимущества и недостатки нотации «Процедура».

Преимущества:

• внешняя простота;
• интеграция с IDEF0 по потокам объектов;
• возможность использования междиаграммных ссылок для интеграции моделей в архитектуре.

Недостатки:

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

Рис. 1. Пример диаграммы бизнес-процесса в нотации «Процедура».

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

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

Нотация eEPC

На рис. 2. представлен пример диаграммы процесса в нотации eEPC. Это тот же процесс, который был описан в «Процедуре» выше.

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

Преимущества:

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

Недостатки:

• ресурсоемка при моделировании + размер диаграммы;
• ограниченная семантика;
• отсутствуют дорожки;
• устарела с точки зрения автоматизации.

Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.

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

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

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

В целом, конечно, нотация eEPC, как и «Процедура», безнадежно устарела. Особенно с точки зрения использования моделей процессов для настройки BPM-систем.

Рис. 2. Пример диаграммы бизнес-процесса в нотации eEPC.

Нотация BPMN

На рис. 3 представлена схема процесса в нотации BPMN. Это тот же самый процесс, который был представлен выше в нотациях «Процедура» и eEPC.

Рис. 3. Пример диаграммы бизнес-процесса в нотации BPMN.

Рассмотрим преимущества и недостатки нотации BPMN вообще, и с точки зрения моделирования процессов в Business Studio, в частности.

Преимущества:

• международный стандарт ISO с 2013 года;
• «де-факто» принята всеми разработчиками BPMS;
• семантика, позволяющая описывать сложные практические ситуации;
• возможность отображения потока объектов (документов) со статусами;
• возможность импорта диаграмм из MS Visio;
• возможность экспорта для автоматизации в BPMS.

Недостатки:

• сложная семантика;
• неадекватное межпроцессное взаимодействие в части информационных потоков (задача решается);
• не вся семантика BPMN поддерживается при имитационном моделировании.

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

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

В Business Studio можно импортировать схемы процессов в нотации BPMN, разработанные в MS Visio. Из Business Studio возможен экспорт моделей для настройки исполняемых процессов в BPMS.

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

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

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

Попробуем сравнить рассматриваемые нотации по набору критериев.

Сравнительный анализ нотаций

Сравнение нотаций можно сделать по трем группам критериев:

1. Внешний вид диаграмм.
2. Интеграция.
3. Семантика и имитация.

В следующей таблице 1 представлено сравнение по группе критериев «Внешний вид диаграмм». Максимальный балл -10.

Таблица 1

	«Процедура»	eEPC	BPMN
Простота и понятность диаграммы	6	7	10
Наличие дорожек на диаграмме	10	0	10
Компактность диаграммы	10	3	7
Ресурсоемкость при моделировании	10	4	8
	36	14	35

В таблице 2 представлена оценка нотаций по критерию «Интеграция».

Таблица 2

	«Процедура»	eEPC	BPMN
Интеграция с моделями верхнего уровня	10	3	0
Интеграция на горизонтальном уровне	10	4	4
Импорт диаграмм из MS Visio	0	0	10
Экспорт для автоматизации процесса	0	3	10
	20	10	24

В таблице 3 представлено сравнение нотаций по группе критериев «Семантика и интеграция».

Таблица 3

	«Процедура»	eEPC	BPMN
Международный стандарт	0	0	10
Семантика модели	2	5	10
Визуализация движения документов	1	8	10
Корректность и возможности для имитации	2	7	10
	4	20	40

Выводы

Итоговая оценка нотаций в баллах представлена на следующей диаграмме:

Диаграмма. Итоговая оценка нотаций в баллах.

По совокупности критериев, я рекомендую использовать нотацию BPMN для описания, анализа и регламентации бизнес-процессов на операционном уровне. На сегодня — BPMN — лучшая нотация!

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

Успехов вам при описании и оптимизации бизнес-процессов!

Опубликовано по материалам:
http://www.finexpert.ru/view/notatsii_modelirovaniya_protsessov_v_Business_Studio_protsedura_eEPC_i_BPMN_chto_vybrat/950

Февраль 2019 г.

Рекомендуемые материалы по тематике

Референтные (типовые) модели банковской деятельности

Положение и регламент управления проектами компании

Оптимизация бизнес-процесса за три месяца, или как повысить операционную эффективность клиентского сервиса на 30%

Business Studio 4.0: новое пространство бизнес-моделирования