В статье Владимира Репина рассмотрены три нотации моделирования бизнес-процессов, при помощи которых можно создавать графические диаграммы с использованием продукта Business Studio: «Процедура», eEPC, BPMN. Обсуждаются преимущества и недостатки каждой нотации. Приводится сравнительный анализ и рекомендации по выбору нотации для описания бизнес-процессов компании.
Введение
Многие компании используют программный продукт Business Studio для описания бизнес-процессов на операционном уровне с целью их последующего анализа и оптимизации, регламентации и автоматизации.
В Business Studio представлено три нотации, которые можно для этого использовать: «Процедура», eEPC, BPMN.
Цель статьи – кратко рассмотреть ключевые преимущества и недостатки каждой нотации, а также сравнить их между собой при помощи ряда критериев.
Такой анализ и сравнение может быть полезен при выборе нотации моделирования бизнес-процессов для использования в проекте построения системы управления бизнес-процессами компании.
Нотация «Процедура»
На рис. 1 представлен пример диаграммы бизнес-процесса, сформированной в нотации «Процедура». В этой старой нотации (1974 г.) используется весьма ограниченный набор графических элементов, в том числе: стартовое и завершающее события – овал, операция процесса – четырехугольник, операция принятия решения или шлюз типа «исключающее «ИЛИ» (кто как использует) – ромб, стрелка с одним наконечником («Связь предшествования») – для отображения потока работы, стрелка с двумя наконечниками – для отображения потока объектов (в первую очередь, документов).
Рассмотрим ключевые преимущества и недостатки нотации «Процедура».
Преимущества:
• внешняя простота;
• интеграция с IDEF0 по потокам объектов;
• возможность использования междиаграммных ссылок для интеграции моделей в архитектуре.
Недостатки:
• морально устарела;
• примитивная семантика, в т.ч. отсутствие нормального аппарата шлюзов и событий;
• отсутствие визуальных значков для моделирования движения документов и статусов;
• нельзя использовать промежуточные события;
• некорректная работа имитации;
• невозможность экспорта моделей в BPMS для автоматизации.
Одним из существенных преимуществ «Процедуры» является внешняя простота. Если цель диаграммы процесса – передача информации только для людей (без имитации и автоматизации), то это является большим преимуществом. Другими словами, если вы создаете аналитическую диаграмму процесса, не предполагая делать из нее модель для расчетов или передавать на автоматизацию в BPMS, то «Процедура» вам подходит.
При использовании «Процедуры» весьма удобно, что стрелки с диаграммы в нотации IDEF0 мигрируют на диаграмму в «Процедуре» автоматически. Кроме того, на «Процедуре» можно использовать междиаграммные ссылки, напрямую увязывая процессы между собой по входам/выходам и условиям старта/завершения.
На этом преимущества «Процедуры» заканчиваются. Семантика этой морально устаревшей нотации не позволяет удобно моделировать сколько-нибудь сложные ситуации, которые возможны в реальных бизнес-процессах. В «Процедуре» нет логических операторов (кроме «ромба»). Нельзя использовать промежуточные события. Нет значков документов.
Имитация в нотации «Процедура» работает некорректно. Это значит, что невозможно адекватно анализировать процесс и обосновывать решения по его оптимизации. Так же следует отметить, что из «Процедуры» невозможен корректный экспорт в BPM-системы для последующей автоматизации.
Нотация eEPC
На рис. 2. представлен пример диаграммы процесса в нотации eEPC. Это тот же процесс, который был описан в «Процедуре» выше.
Особенностью нотации eEPC является использование событий до и после каждой операции процесса, наличие логических операторов и визуальное представление потоков документов (информации) на схеме. Рассмотрим преимущества и недостатки нотации eEPC.
Преимущества:
• простота и понятность для исполнителей;
• возможность отображения потока объектов (документов) со статусами;
• адекватное межпроцессное взаимодействие (процессные интерфейсы);
• возможность корректной имитации.
Недостатки:
• ресурсоемка при моделировании + размер диаграммы;
• ограниченная семантика;
• отсутствуют дорожки;
• устарела с точки зрения автоматизации.
Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.
Нотация eEPC имеет весьма ограниченную семантику. Это приводит к тому, что для сложных практических случаев приходится искать обходные пути для того, чтобы показать нужные аспекты на диаграмме.
В тоже время диаграмма в нотации eEPC является вполне понятной большинству сотрудников. На ней можно отобразить потоки документов, причем со статусами. Можно использовать значок процессного интерфейса для интеграции с другими диаграммами в рамках общей модели компании.
Важным плюсом нотации eEPC является возможность корректной имитации процессов. Полученные расчеты можно использовать для анализа процесса и обоснования действия по его оптимизации.
В целом, конечно, нотация eEPC, как и «Процедура», безнадежно устарела. Особенно с точки зрения использования моделей процессов для настройки BPM-систем.
Нотация BPMN
На рис. 3. представлена схема процесса в нотации BPMN.
Это тот же самый процесс, который был представлен выше в нотациях «Процедура» и eEPC.
Рассмотрим преимущества и недостатки нотации 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 представлено сравнение по группе критериев «Внешний вид диаграмм». Максимальный балл -10.
В таблице 2 представлена оценка нотаций по критерию «Интеграция».
В таблице 3 представлено сравнение нотаций по группе критериев «Семантика и интеграция».
Выводы
Итоговая оценка нотаций в баллах представлена на следующей диаграмме:
Диаграмма. Итоговая оценка нотаций в баллах.
По совокупности критериев, я рекомендую использовать нотацию BPMN для описания, анализа и регламентации бизнес-процессов на операционном уровне. На сегодня — BPMN – лучшая нотация!
Если, всё-таки, по каким-то причинам вам придется делать выбор между «Процедурой» и eEPC, и если не нужна имитация, то лучшим выбором станет нотация «Процедура». Но если предполагается серьезно заниматься имитацией процессов, то лучше выбрать нотацию eEPC, чем «Процедуру».
Успехов вам при описании и оптимизации бизнес-процессов!
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Средняя оценка 0 / 5. Количество оценок: 0
Оценок пока нет. Поставьте оценку первым.
Источник: repin.guru
Полное руководство по BPMN
BPMN расшифровывается как нотация моделирования бизнес-процессов. BPMN очень похожа на концепцию блок-схем, которая существует с 1980-х годов. Подобно блок-схемам, моделирование BPMN имеет целью позволить человеку отобразить рабочий процесс таким образом, чтобы его могли легко понять другие заинтересованные стороны.
BPMN — это язык, и, как и любой другой язык, его цель — облегчить общение. BPMN предназначена для облегчения общения и понимания бизнес-процессов.
BPMN — это не программное обеспечение, и оно не «принадлежит» бизнесу, а было разработано OMG (Группой управления объектами) в качестве стандарта записи, понятного бизнес-аналитикам, техническим разработчикам и руководителям проектов.
BPMN 2.0: что нового?
BPMN 2.0 существует уже несколько лет и имеет несколько новых функций и преимуществ по сравнению со старыми версиями. Версии до 2.0 менее последовательны, не настолько технологически зрелы и не поддаются автоматизации. Многие диаграммы, созданные в более старых версиях BPMN, устарели и гораздо полезнее и содержательнее, когда отображаются в BPMN 2.0. BPMN 2.0 на сегодняшний день является самой серьезной версией BPMN, в которой были улучшены как визуальные элементы BPMN, так и «внутренние» элементы BPMN, такие как семантика.
BPMN 1.2 обеспечивает отображение «действительной» диаграммы BPMN на BPEL, так что механизм может выполнить процесс. Спецификация 1.2 содержит только словесные описания элементов графических обозначений и правил моделирования. Это приводит к путанице и путанице в процессе перевода.
BPMN 2.0 представляет собой самую большую версию BPMN с момента ее создания. BPMN 2.0 получила формальное определение в виде метамодели, то есть точного определения конструкций и правил, необходимых для создания конкретных моделей.
Некоторые из основных изменений, которые привнесли с собой BPMN версии 2.0, среди прочего:
- Добавление схемы хореографии.
- Добавление диалоговой диаграммы.
- Непрерывающие события для процесса.
- Подпроцессы событий для процесса.
Основные технические изменения включают в себя:
- Определение семантики выполнения процесса.
- Формальная метамодель, как показано на рисунках диаграммы классов.
- Форматы обмена для обмена моделями абстрактного синтаксиса в метаданных XML
- Обмен данными (XMI) и определение схемы XML (XSD).
- Форматы обмена для обмена диаграммами как в XMI, так и в XSD.
- Расширяемые преобразования языка таблиц стилей (XSLT) между форматами XMI и XSD.
Другие технические изменения включают в себя:
- Справочные задачи удалены. Они обеспечивают возможность повторного использования в рамках одной диаграммы по сравнению с глобальными задачами, которые можно повторно использовать на нескольких диаграммах. Новое действие вызова можно использовать для ссылки на глобальную задачу или другой процесс, который будет использоваться в процессе (вместо эталонных задач).
Благодаря обновлениям версии 2.0 количество элементов увеличилось более чем вдвое с 55 до 116. Многие из этих новых элементов применялись для моделирования взаимодействия между процессами и/или сущностями, например новая хореографическая диаграмма.
BPMN 2.0.2, выпущенная в декабре 2013 г., включала лишь незначительные модификации с точки зрения исправления опечаток и изменения в пункте 15.
Является ли инструментарий BPMN 2.0 сложным?
Многие критики BPMN 2.0 жалуются, что BPMN слишком сложна для изучения. Даже если сам язык спроектирован так, чтобы быть однозначным за счет включения единственного семантического слоя, в BPMN просто слишком много объектов, чтобы стандарт был полезен.
Эти критики часто указывают на изображения из спецификации BPMN 2.0 OMG, такие как эта матрица событий, чтобы подчеркнуть свою точку зрения. Эти критики часто отдают предпочтение другим инструментам и методологиям моделирования.
Изучение нотации BPMN более простым способом
О чем критики не упоминают, так это о том, что большинство процессов не требует от разработчика модели знания всей спецификации. На самом деле в большинстве моделей используется лишь несколько наиболее распространенных элементов процесса.
По сути, BPMN фактически состоит всего из 3 основных элементов:
- События
- Деятельность
- Шлюзы
Да все верно. В BPMN всего три основных элемента! Хорошо, давайте добавим четвертый элемент, чтобы мы могли соединить остальные три — поток последовательностей (черные линии со стрелками, которые соединяют все вместе).
Возможно, если вы сможете запомнить набор наиболее часто используемых основных элементов BPMN, их будет достаточно для решения большинства ваших задач:
BPMN учиться на примере
Как говорят некоторые критики, у BPMN довольно много символов и обозначений. Запомнить их все не так-то просто. Сначала мы должны использовать базовый базовый набор элементов BPMN, и постепенно, по мере того, как мы сталкиваемся со все большим количеством проблем, мы узнаем больше. Лучший способ понять их значение — изучить их на примерах и шаблонах.
Здесь я привожу для вас несколько примеров BPMN в качестве отправной точки и желаю вам всего наилучшего в вашем исследовательском путешествии.
Этот пример диаграммы бизнес-процесса иллюстрирует процесс бизнес-отдела в отделе кадров, начиная с сообщения об открытии вакансии и заканчивая публикацией объявления о вакансии, которое включает потоки, задачи, начальные и конечные события и шлюзы.
Пример диаграммы бизнес-процесса: объявление о вакансии
Пример диаграммы бизнес-процесса: система управления поставщиками
Это схема процесса BPMN для управления поставщиками. Он показывает будущий процесс закупок для создания новых поставщиков. Этот BPM показывает несколько задач, шлюзов (решений) и соединителей.
Пример диаграммы бизнес-процесса: запрос котировок
Это пример BPD, описывающий процесс запроса предложения. Он показывает действия, событие тайм-аута и маркер, отображаемый в циклах подпроцесса.
Источник: www.cybermedian.com
BPMN Примеры
Рекомендации по созданию диаграмм процессов BPMN 2.0.
- BPMN Примеры
- Бизнес-правила и BPMN
- Зависимые экземпляры
- Принцип четырех глаз
- Ежемесячное выставление счетов
- Требуется дополнительная информация
- Обработка партии заказов
- Переназначение пользовательских задач
- Двухэтапная эскалация
- Избегайте пересечения потоков
- Соглашения об именах
- Симметричное моделирование
- Использовать равные размеры задач
Бесплатный BPMN инструмент
Cawemo — это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.
Обзор
Мы преподавали BPMN тысячам людей, и мы применяем обозначения в нашей ежедневной проектной работе с 2007 года. Ниже вы можете найти множество примеров BPMN общих проблем моделирования. Независимо от вашего конкретного проекта или вашей отрасли, есть много общих вопросов об использовании BPMN. По нашему опыту, большинство приведенных ниже примеров BPMN полезны для любого пользователя BPMN.
Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.
BPMN Примеры
Бизнес-правила и BPMN
Сценарий моделированияo
Предположим, мы хотим моделировать процесс в BPMN, и процесс вызывает некоторые бизнес-правила. Мы будем использовать пример создания счета. Чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.
Это очень простой пример, который покажет нам, где применять BPMN, а где нет.
Решение как диаграмма BPMN 2.0
Объяснение
Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат — очень простой процесс.
Не имеет смысла моделировать расчет самой скидки в модели BPMN (см. Пример ниже). Для дерева решений правил, для каждого дополнительного критерия, мощности будут расти экспоненциально. Это не то, что мы хотим в модели BPMN.
Поэтому имеет смысл разделить процессы и бизнес-правила.
Неправильный способ моделирования
Зависимые экземпляры
Сценарий моделирования
Предположим, мы хотим моделировать процесс с совпадающими экземплярами. Мы используем простой пример. Если выполняется одна кредитная проверка клиента, мы не хотим, чтобы еще одна кредитная проверка для одного и того же клиента была выполнена одновременно.
Причиной может быть то, что общее количество проведенных кредитных проверок влияет на результат проверки.
Предположим, что мы выполняем кредитную проверку для клиента, и мы получаем второй запрос для одного и того же клиента одновременно.
Что общего у всех решений, так это то, что каждый новый экземпляр должен проверять совпадение экземпляров на уровне данных перед началом фактической проверки кредита.
Решение с сигнальным событием
запуск экземпляров одного и того же клиента?
и того же клиента?
Объяснение
Событие сигнала — это самый простой и компактный способ моделирования взаимодействия между различными экземплярами. Проблема сигнала заключается в том, что он функционирует как широковещательный и не адресует какой-либо конкретный экземпляр. Итак, строго говоря, клиент игнорируется, и все ожидающие экземпляры ловят его.
Решение с событием Message
проверить на ожидание
Объяснение
Это решение немного сложнее, так как вам нужно определить получателя (один экземпляр) сообщения. Это вызывает второй запрос данных до конца экземпляра. Однако это правильный способ решить проблему, возникающую в решении сигнального события.
Решение с таймером и циклом
Объяснение
В этом примере нам не нужна связь между экземплярами. Сам экземпляр проверяет периодичность, если он может перейти к проверке кредита. Недостатком является то, что это может вызвать задержки и накладные расходы из-за цикла.
Принцип четырех глаз
Сценарий моделирования
Мы хотим моделировать следующую ситуацию с использованием BPMN 2.0. Для запроса (например, оплаты) необходимы два разрешения двух разных людей. Механизм процесса должен гарантировать, что оба утверждения будут выполнены до утверждения запроса. Ручные шаги, выполняемые двумя утверждающими, также должны быть смоделированы на диаграмме BPMN. Решение об одобрении выполняется с использованием портала с списком задач.
Случаи использования
Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:
- Утверждение оплаты
- Утверждение счета
- Утверждение контракта
- .
Решение как диаграмма BPMN 2.0
Процеесы в двигателе
Объяснение
Мы используем отдельные пулы для Process Engine, для первого утверждающего и для второго утверждающего. Таким образом, мы можем четко определить, кто контролирует какой процесс.
В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.
Взаимодействие между задачами пользователя в двигателе и между ручным процессом утвердителей моделируется с использованием потоков сообщений. Эти потоки сообщений инкапсулируют шаги документации, которые должен выполнить утвердитель, чтобы выполнить пользовательскую задачу.
Сам список задач не моделируется, чтобы уменьшить сложность.
Вариации
Утверждение в качестве сбитых пулов
Определение приемника с помощью LDAP
Ежемесячное выставление счетов
Сценарий моделирования
В этом примере объясняется очень распространенная борьба со структурированием диаграмм BPMN 2.0. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обращаться за юридической консультацией, когда им это нужно. Адвокат предоставляет запрошенный совет и ставит оплачиваемые часы на лист времени клиента. Когда месяц закончился, бухгалтер-юрист определяет оплачиваемые часы на основе расписания и создает счет-фактуру.
Этот пример иллюстрирует очень общий сценарий моделирования. Это не те шаги процессов, которые сложны, это структура диаграммы.
Решение как диаграмма BPMN 2.0
создать и отправить
Объяснение
Наиболее важным аспектом диаграммы является ее структура.
Процесс предоставления юридических консультаций выполняется много раз в месяц. Процесс ежемесячного выставления счетов выполняется только один раз в месяц. Поэтому эти два процесса должны быть смоделированы как отдельные пулы.
Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными — листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.
Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.
Неправильный способ моделирования
создать и отправить
Объяснение, почему это неправильно
В этом примере оба процесса смешиваются в один. Это — в лучшем случае — очень неявный способ его моделирования. Это означало бы, что при каждом предоставленном юридическом консультировании счет-фактура отправляется раз в месяц. Этот способ моделирования в большинстве случаев является неправильным.
Дополнительная информация, необходимая после задачи пользователя
Сценарий моделирования
Предположим, мы хотим моделировать следующий сценарий: мы хотим выполнить пользовательскую задачу, которая выполняется пользователем на портале. После завершения пользовательской задачи может потребоваться дополнительная информация. В этом случае процессор процесса отправляет запрос информации другому пользователю (решение 1) или технической службе (решение 2).
Источник: camundarus.ru
