Популярные нотации описания бизнес процессов

В этой статье мы поговорим про основы бизнес-анализа и рассмотрим наиболее популярные на сегодня нотации моделирования 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/

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

---

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

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

Семейство IDEF

Ну всё-таки небольшое вступление будет. IDEF — это не одна нотация, а целое семейство. Различаются они по порядковым номерам — IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Первое что надо знать, IDEF является самой «старой» нотацией. Второе, она уже очень давно (десятилетия!) не развивается. Отсюда первый камень в огород. Семейство IDEF безнадёжно, морально, функционально устарело.
Дальше. Использовать модели бизнес процессов, выполненных в IDEF, крайне сложно. Как для изучения, так и для анализа. Ниже представлен пример схемы бизнес процесса. Судите сами.

Нотация имеет ограничения по количеству отображаемых на схеме процессов — не больше 7. Отсюда возникает необходимость подстраивать описания под эти правила. Кроме того, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес процессов, так и «читателям».
В совокупности это влечёт за собой огромное количество тяжёлых для восприятия, крайне запутанных схем. Но есть и плюс — вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок-схема будет ориентирована на лист формата А4 в альбомной ориентации. То есть распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающего моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своём оно тоже устарело и не позволяет решать актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами, например, Microsoft Visio. Даже от руки на листе бумаги можно создать схему.
К слову, именно из потребности в автоматизации, т.е. в переводе моделей бизнес процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

Резюме — если вы встали перед выбором нотации для описания и моделирования бизнес-процессов, ни в коем случае не останавливайтесь на IDEF.

Нотация eEPC

А вот это уже интересно. Само название нотации Событийная цепочка процессов (event driven process chain, «e» вначале означает extended, расширенное) говорит о том, что моделирование в данной нотации сосредоточено вокруг событий. А именно события и определяют развитие процесса.
В основе этой нотации лежит… Одна из нотаций семейства IDEF. А конкретно IDEF3. Впрочем, eEPC намного функциональнее и нагляднее.

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

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

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

Резюме — нотация eEPC является не самым плохим решением для описания и моделирования бизнес процессов.

Нотация BPMN 2.0

Скажу сразу, на мой взгляд, это лучшая нотация для описания и моделирования любых бизнес процессов.
BPMN (Business Process Model and Notation) — нотация управления бизнес-процессами. Вот так скромно и без прикрас назвал своё детище Институт управления бизнес процессами (BPI). Да, созданием и развитием BPMN занимается целый институт. Одно это говорит о том, что нотация является результатом серьёзной, научно обоснованной работы. Более того, работа эта происходит постоянно, а в настоящее время нет ничего важнее постоянного развития инструментов управления. Впрочем, перейдём к сути.
BPMN — самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия «дорожка». Дорожка — это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.

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

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

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

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

Есть ещё возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн. Но об этом я буду рассказывать в другой раз в обзоре программ для моделирования и управления бизнес-процессами.

Правила и примеры моделирования в нотации BPMN

Резюме — нотацию BPMN выбирает большинство профессионалов в управлении бизнес-процессами. Она наиболее современная и активно развивающаяся. Я рекомендую работать именно с ней.

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

• Выбирайте ту нотацию, с которой у вас уже принято работать.
• Если не принято, выбирайте BPMN.
• Выбирайте ПО и соответственно ту нотацию, с которой оно работает.
• Не знаете с чего начать? Начинайте с BPMN.
• В конце концов, выбирайте ту нотацию, которая вам понятна и симпатична:)

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

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

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

Сегодня в мире наиболее популярны 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.

В.В.Репин

Оглавление

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 месяца, но это является необходимым элементом последующей успешной работы.