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

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

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

Можно отметить 3 самые популярные нотации: семейство IDEF, eEPC и BPMN 2.0. Я не буду рассказывать об истории возникновения, развития и правилах использования нотаций – все это можно прочитать в Википедии. Вместо этого представляю свой взгляд на их использование сугубо с практической точки зрения.

Семейство IDEF

Ну всё-таки небольшое вступление будет. IDEF – это не одна нотация, а целое семейство. Различаются они по порядковым номерам – IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.

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

Модель процесса в нотации IDEF3

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

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

Нотация eEPC

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

Модель процесса в нотации eEPC

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

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

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

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

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

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

Нотация BPMN 2.0

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

BPMN – самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия “дорожка”. Дорожка – это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.

Модель процесса в нотации BPMN

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

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

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

rzbpm.ru

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

---

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

Например, популярная сейчас нотация BPMN по-настоящему раскроет свои преимущества только в связке с BPM-системой, которая может «понимать» и «исполнять» нарисованную схему бизнес-процесса в реальном времени. То есть при помощи этой нотации можно автоматизировать и контролировать выполнение процесса. Если же вы просто нарисуете процесс в нотации BPMN в Visio и сохраните его как картинку, то при этом вы потеряете практически все преимущества данной нотации перед любой другой.

Сейчас на рынке появилось множество программных продуктов, которые якобы поддерживают сразу несколько нотаций, но дело в том, что на самом деле логика работы у этих программ одинаковая для любой из этих нотаций. Как правило, ответственность и документы закрепляются внутри блока, а затем, для визуального соответствия требованиям одной из нотаций, на схему можно добавить графические блоки, наличие которых никак на функционал не влияет. То есть по сути вы строите две модели: одну по логике работы программы, а вторую – для соответствия требованиям нотации и при этом эти модели могут не совпадать (то, что мы видим не соответствует тому что сохранилось в базу данных).

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

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

Процессы верхнего уровня

---

Самые распространённые нотации для построения процессов верхнего уровня на сегодняшний день это IDEF0 (методология функционального моделирования) и ARIS VAD (цепочка создания ценности).

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

В чём же отличие нашей схемы от IDEF0? В первую очередь в том, что в IDEF0 есть требования к тому к какой стороне блока какая стрелка должна подходить:

• стрелка входа приходит всегда в левую кромку активности
• стрелка управления — в верхнюю кромку
• стрелка механизма — нижняя кромка
• стрелка выхода — правая кромка

Является ли это важным отличием, которое даёт преимущества данной нотации перед нашим подходом? С нашей точки зрения – нет, но при желании, вы можете привести схему взаимодействий в Fox Manager в чёткое соответствие с требованиями этой нотации (сверху – оригинальная схема в IDEF0, снизу – её аналог в Fox Manager).

Как видите, при желании, вы можете моделировать схемы IDEF0 и в Fox Manager.

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

Что касается нотации ARIS VAD – то тут всё ещё проще: достаточно выстроить процессы по цепочке создания ценности и при желании показать ответственных и взаимодействия.

На картинке приведён пример такой схемы в нашей программе (сверху – оригинальная диаграмма ARIS VAD, снизу – её аналог в Fox Manager). Конечно, можно придраться в форме блоков, стрелок или подсветке, но в целом, не возникает сомнений, что в нашей программе, при желании, можно строить диаграммы в соответствии с требованиями нотации ARIS VAD.

Процессы нижнего уровня

---

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

Существует множество нотаций для моделирования бизнес-процессов нижнего уровня: Basic Flowchart, Cross Functional Flowchart, EPC и другие. Большинство из них имеют незначительные отличия друг от друга.

Например, если в программе Fox Manager на диаграмме свернуть блоки ответственных, документов и ресурсов, то мы получим аналог нотации Basic Flowchart (справа – оригинальный процесс, слева – аналог в Fox Manager).

Если же все блоки на диаграмме развернуть – то мы получим аналог процесса в нотации EPC. Самое замечательное то, что при использовании нотации Fox Manager блоки можно сворачивать и разворачивать динамически, и при этом не нужно создавать новую версию процесса в другой нотации. На картинке справа изображен оригинальный процесс, а слева – аналог в Fox Manager.

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

Поддержка нотации Cross Functional Flowchart была добавлена в программу в одном из наших бесплатных обновлений. Данная нотация отличается от уже рассмотренных выше нотаций тем, что на ней можно показывать ответственных дорожками, а не рядом с блоком. К сожалению, у этого способа есть свои недостатки, когда ответственных очень много – то процесс становится ненаглядным и трудночитаемым. Также возникают проблемы, когда необходимо распределить ответственность за функцию сразу двум и более должностям. Ниже приведён пример такого процесса в Fox Manager.

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

Конечно, наверное, можно сократить набор элементов этой нотации до необходимого минимума и попытаться приспособить её для целей регламентации, но при этом мы потеряем её главное преимущество – возможность исполнения процессов BPM-движком. При этом, если оставить только 5-10 необходимых блоков, то, скорее всего, внешний вид таких процессов будет очень походить на уже рассмотренные нами нотации.

Вывод

---

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

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

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

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

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

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

www.fox-manager.com.ua

Краткое описание BPMN с примером

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

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

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

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

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

Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.

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

В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.

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

BPM: основные понятия

Для того чтобы разобраться, что такое BPMN , нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management.  В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.

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

Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

Можно сказать, что BPMN является частью двух важнейших составляющих:

• BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
• BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.

Итак, основные понятия у нас есть. Подробнее о BPM я планирую поговорить в следующих статьях.

Язык описания бизнес-процессов

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

А основой здесь является наличие языка описания бизнес-процессов. И важно понимать, что это действительно язык, как и языки программирования или даже языки, на которых говорят люди, он также прост на базовом уровне и сложен, если начинать изучать нюансы. У этого языка есть свои правила, семантика, орфография, свои законы, которые нужно изучить и строго им следовать. С другой стороны, как и любой искусственный язык, предназначенный не для живого общения, а для строгого и однозначного описания каких-то действий и процессов, он в своей основе проще “живых” языков, а его правила — строго логичны.

Кроме того, в силу ограниченности задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же и здесь имеется очень много нюансов, каких-то сочетаний «слов», которые несут собственную смысловую нагрузку. И очень важно строго следовать правилам сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, чем заканчивать и пр.).

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

Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.

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

Немного истории BPMN

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

Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative.  Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.

Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.

Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.

В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.

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

Сегодня BPMN – это один из наиболее распространенных методов описания бизнес-процессов, которые сегодня уже «понимают» как бизнес-пользователи, так и программные продукты, предназначенные для работы с бизнес-моделями. Т.е. этот язык описания является стандартным также и для создания исполняемых алгоритмов в сфере управления бизнесом.

Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.

Из чего состоит нотация BPMN?

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

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

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

Язык описания бизнес-процессов опирается на следующие базовые объекты:

• Event – Событие;
• Activity – Действия;
• Gateway – Шлюзы или Развилки;
• Flow – Поток.
• Date – Данные;
• Artefact – Артефакты;
• Pool (Пул) — набор.

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

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

Event (Событие)

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

Например, опишем процесс получения заказа от клиента по телефону:

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

Конечными  могут быть самые разные события. Здесь и запись перечня потребностей клиента, и сохранение документа заказа, и создание на его основе расходной накладной, налоговой и т.д.

Activity (Действия)

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

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

Обычно действия делят следующим образом:

• Процесс – крупное действие, которое требует дальнейшей детализации при моделировании.
• Задача – элементарное действие, которое уже не может быть дальше детализировано.

Gateway (Шлюз, Развилка)

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

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

Flow (Поток) и Message Flows (поток сообщений)

Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.

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

Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).

Pool (Пул)

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

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

Data Object (данные, объекты данных)

Объекты данных – это элемент, который показывает, какие данные и документы нужны для того, чтобы какое-то действие запустилось, либо которые являются результатом выполненного действия. Объектом данных может быть сформированный заказ. Для менеджера это будет результат действий, а для склада, который получает заказ – началом действия (сбор товаров и отгрузка).

Message (Сообщение)

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

Artefact (Артефакты)

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

Выделяют два вида артефактов:

• Object Group (Группа объектов)
• Text Annotation  (Текстовая аннотация)

Object Group (Группа объектов) –  это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.

Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.

Исполняемые и неисполняемые бизнес-процессы

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

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

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

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

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

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

Подходит ли BPMN для малого и среднего бизнеса?

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

Но, тем не менее, на уровне неисполняемых бизнес-процессов я очень активно используют именно BPMN. Дело в том, что при всей сложности вхождения (т.е изучения и умения работать с нотациями), уровень понимания BPMN — низкий, т.е. для чтения нотаций не требуется вообще никаких особых знаний и навыков. Графические нотации понимаются интуитивно. И я еще не встретил ни одного человека, для которого бы прочесть нотацию было бы сложно. Эта нотация создавалась специально для того, чтобы найти общий язык между аналитиком и обычными бизнесменами (управленцами).

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

Минусы и важные особенности BPMN

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

Система имеет значительное количество понятий и терминов, их нужно знать и применять грамотно.

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

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

Пример практического применения BPMN

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

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

Данный бизнес-процесс выполняется следующим образом:

1. Менеджер по продажам получает информацию о потребностях клиента (заказ).
2. В системе CRM создается документ Заказ покупателя.
3. Если нужные товары есть в наличие, то менеджер создает расходный документ в программе учета. Если товара нет в наличии, менеджер делает запрос в отдел закупки.
4. Отдел закупки оформляет запрос поставщикам на получение товара.

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

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

Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».

Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:

• Если весь товар имеется в наличие, то менеджер выполняет подпроцесс «резервирование товаров». Я специально оформил эти действия именно подпроцессом, чтобы иметь возможность при необходимости детализировать действия менеджера. А потом – к точке выхода «Резервирование товаров проведено».
• Если товаров в наличие нет, то менеджер выполняет запрос в отдел закупки. Информация о заказе переходит в отдел закупки к другому исполнителю – менеджеру по закупкам, что наглядно видно на схеме, и уже этот исполнитель создает заказ поставщику.  На схеме также видно, что заказ поставщику создан на основе запроса на поставку и заказа поставщикам.

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

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

Как разрабатывать диаграммы BPMN на практике?

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

1. Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.
2. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату. Далее при необходимости добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
3. Пришло время определить ответственных лиц.  До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.
4. Добавляем данные, сноски, комментарии.

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

Что еще хотелось бы посоветовать:

1. Создавайте диаграммы как можно менее разветвленные.  Чем больше элементов окажется на вашей диаграмме, тем сложнее ее будет читать и вам, и вашим заказчикам.
2. Используйте наиболее простую и понятную терминологию. Очень важно, чтобы ваши заказчики, а также технические специалисты, которые будут работать с диаграммами, без лишних пояснений понимали все (или почти все) термины.
3. Все названия процессов должны быть максимально информативны и понятны. Иначе читабельность диаграммы также будет крайне низкой. Для названий процессов лучше всего подойдут либо термины, принятые в конкретной организации для описания работы, либо – просто понятные интуитивно фразы.
4. Зоны ответственности также важно называть понятно для сотрудников компании, бизнес-модель работы которой вы описываете. Самое простое решение – выбирать названия среди существующих подразделений. А если необходимой должности или отдела в компании пока еще не существует, не бойтесь придумывать его сами. Но постарайтесь, чтобы название также было «говорящим», понятным для широкого круга бизнес-аудитории.
5. Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
6. Не бойтесь ошибаться! Если вы ошибетесь в исполняемой методологии, это очень быстро выяснится в процессе исполнения (отладки) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не столь важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчики, технические специалисты), понять все нюансы вашей идеи. И в любом случае, на ошибках учатся, а исправления внести в бизнес-модель можно быстро и просто.

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

‍

www.trinion.org

BPMN 2.0 Из чего состоит модель бизнес процесса

Чтобы моделировать бизнес процессы в нотации BPMN 2.0 , можно обойтись базовыми элементами.
Если же хотите вы настоящим джедаем стать, мастером простых и эффективных моделей, глубину нотации и силу знаков постичь нужно.

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

Это описание элементов BPMN 2.0 поможет вам.

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

Нотация BPMN 2.0 – самая гибкая и простая. Гибкость достигается благодаря набору элементов и правилам нотации. Простота – за счет наглядности. Процессы и ситуации могут быть по разному изображены в модели. Например, циклы или ссылки на части процесса могут быть смоделированы как минимум тремя способами. Все зависит от вашего выбора, целей моделирования и того, на кого модель ориентирована.

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

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

Операции

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

Сервисная операция

Операция, которая выполняется сервисом или механизмом. Иными словами, это операции, выполняемые автоматически. Пример – рассчитать цену с учетом скидки. Операция выполняется программой автоматически. Этот тип операций удобно использовать, когда вы отображаете работу программы или инструмента. Или показываете взаимодействие человека и программы. Кстати, пул, который означает сотрудника в модели, также может обозначать программу. Если задать один пул как программу, а другой как пользователя, то можно раскрыть процесс взаимодействия. Такое возможно только в нотации BPMN 2.0.

Отправка сообщения

Операция, результатом которой является отправленное сообщение. И вот первый пример гибкости нотации – операция «отправить электронное письмо» может быть как типом «пользовательская операция», так и «отправка сообщения». Какой тип использовать, зависит от целей моделирования конкретного процесса и правил, которые вы для себя приняли.

Получение сообщения

Операция, связанная с получением сообщения. Пример – получить письмо на почте.

Пользовательская операция

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

Ручная операция

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

Выполнение сценария

Операция, которая подразумевает выполнение сценария. Сценарий создается заранее и представляет собой последовательность действий. По сути , сценарий – это тоже процесс. Проще всего понять сценарий как процедуру. Например, проверить документ. Эта операция подразумевает выполнение ряда действий, т.е. мы проверяем конкретные пункты в документе. Это и есть сценарий. Если вы используете этот тип операции, то нужно обязательно указать, какой сценарий используется. Кстати, когда для проверки используется чек-лист, то такая операция явно имеет тип «выполнение сценария», а чек-лист – это сценарий.

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

Выполнение бизнес-правила

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

Бизнес-правило – это уникальная штука! И с точки зрения моделирования бизнес процессов, и с точки зрения выполнения. Есть мнение, что описанные бизнес процессы строги и не дают свободу действий сотрудникам. Это неверно. И как раз бизнес-правила дают допустимую свободу действий модели – с точки зрения развития процесса, сотруднику – с точки зрения действий.

Операция-ссылка

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

Операция-вызов

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

Процессы в BPMN 2.0

Повторно используемый процесс

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

Процесс-ссылка

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

Событийный процесс

Особый вид процесса. Особенность заключается в том, что такой процесс не имеет входящих/исходящих потоков. Т.е. на диаграмме он не соединен стрелками с другими процессами/операциями. А запускается он, когда в процессе наступает событие, такое же, какое указано в событийном процессе в качестве старта. Зачем это нужно? Иногда не нужно включать процесс в основной поток. Например, потому что событие, запускающее процесс, возникает крайне редко. При этом ход основного процесса может как прерываться и переходить в событийный подпроцесс, так и нет. Т.е. событийный процесс выполняется параллельно. Например, в процессе обслуживания клиента в банке оператор видит, что клиент является мошенником. В таком случае он подает сигнал службе безопасности, который служит стартом для соответствующего процесса в СБУ. Однако оператор не прерывает процесс, а продолжает обслуживание с целью удержания мошенника на месте до прибытия сотрудников СБУ.

Спонтанный процесс (ad-hoc)

Еще один вид особого процесса. В спонтанном процессе операции не имеют последовательности действий. Т.е. они могут выполняться спонтанно, в любом порядке, с любым количеством повторений. Выполнение такого процесса полностью определяется его исполнителем. Например, спонтанный процесс “Приготовить кофе” имеет в своем составе операции: “Насыпать кофе”, “Насыпать сахар”, “Налить воду”. Порядок действий не важен, т.к. в любом случае мы получим один результат. Что еще важно – не все действия в спонтанном процессе обязательны для выполнения. События начала и окончания не могут включаться в спонтанный подпроцесс.

Повторения

Повторение может относится как к операциям, так и к процессам.

Стандартное повторение

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

Множественное повторение

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

Компенсация

Операция или процесс компенсации выполняется в том случае, если в процессе произошло что-либо, что требует дополнительных действий для его завершения. Например, при согласовании документа необходимо внести поправки. В таком случае выполняется компенсирующее действие “внести поправки”, которое позволяет завершить процесс согласования. Форма компенсации очень удобна для моделирования. Компенсация – отличительная черта нотации BPMN 2.0.

События в BPMN 2.0

Все виды событий – стартовые, промежуточные и события окончания – тоже делятся на типы. Точнее, они имеют разные тригеры – спусковые крючки. Спусковой крючок – это тип условия, при котором наступает событие. Например, событие – получение сигнала. Тип события – сигнал. Спусковой крючок – его получение.

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

Входящие / исходящие события

rzbpm.ru

Нотации «Процесс» и «Процедура» [BS Docs 4]

Нотации «Процесс» (Basic Flowchart в Microsoft Visio) и «Процедура» (Cross-Functional Flowchart в Microsoft Visio) используются для представления алгоритма (сценария) выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы, также как и нотация IDEF0.

Различие между нотациями «Процесс» и «Процедура» состоит в том, что дополнительно к графическим элементам, применяемым в нотации «Процесс», в нотации «Процедура» используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса. Это позволяет повысить наглядность диаграммы.

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

Описание назначения графических символов, используемых в нотациях «Процесс» и «Процедура», приведено в Таблице 1.

Название	Графический символ	Описание
Действие		Действие обозначается с помощью прямоугольного блока. Внутри блока помещается название действия. Временная последовательность выполнения действий задается расположением действий на диаграмме процесса в нотации «Процесс»/»Процедура» сверху вниз (слева направо на горизонтальной диаграмме процесса в нотации «Процедура»).
Решение		Элемент «Решение» обозначает ветвление, после которого процесс может пойти по одному и только одному альтернативному направлению в зависимости от некоторого условия. Элемент «Решение» может иметь один или несколько входов и ряд альтернативных выходов. Элемент «Решение» используется в двух вариантах: для обозначения действия, результат которого определяет дальнейшее выполнение процесса, или для обозначения проверки условия. Если «Решение» используется для обозначения действия, то все возможные варианты результатов этого действия показываются выходящими стрелками (Рис. 1). Рисунок 1. Элемент «Решение» обозначает действие Если элемент «Решение» используется для проверки условия, то «Решение» помещается на диаграмму после элемента «Действие», в названии элемента «Решение» указывается проверяемое условие, а все возможные варианты значения условия показываются выходящими стрелками (например, «Да» или «Нет» (Рис. 2)). Рисунок 2. Элемент «Решение» обозначает проверку условия Элемент «Решение» аналогичен элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Связь предшествования		Стрелки «Связь предшествования» обозначают передачу управления от одного действия к другому, т.е. предыдущее действие должно закончиться прежде, чем начнется следующее. Стрелка, запускающая выполнение действия, изображается входящей в действие сверху. Стрелка, обозначающая передачу управления другому (другим) действию, изображается выходящей из действия снизу (Рис. 3). Рисунок 3. Стрелки «Связь предшествования» Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым. Если кроме передачи управления из предыдущего действия в следующее действие поступает объект(ы) деятельности, то стрелка именуется, и в список объектов стрелки заносится соответствующий объект(ы) деятельности (Рис. 4). Рисунок 4. Именованная стрелка «Связь предшествования», содержащая объекты деятельности
Поток объектов		Стрелки «Поток объектов» используются в случаях, когда необходимо показать, что из одного действия объекты передаются в другое, при этом первое действие не запускает выполнения второго. Стрелки «Поток объектов» обозначаются стрелкой с двумя треугольниками на конце. Если обозначение источника объекта(ов) неважно, то такой объект показывается стрелкой с туннелированным началом (Рис. 5). Рисунок 5. Стрелка «Поток объектов» с туннелированным началом Если источником объекта(ов) является одно из действий процесса, то такой объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим объект (Рис. 6). Рисунок 6. Стрелка «Поток объектов», исходящая из действия-источника и входящая в действие-потребитель При этом действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция».
Дорожки (элемент диаграммы процесса в нотации «Процедура»)		Дорожки предназначены для отображения организационных единиц (должности, подразделения, роли, внешнего субъекта) — исполнителей действий процесса.
Событие		События отображают стартовые точки процесса в нотациях «Процесс»/»Процедура», приводящие к началу выполнения процесса, и конечные точки, наступлением которых заканчивается выполнение процесса. Началом процесса считается событие, из которого только исходят стрелки передачи управления. Концом процесса считается событие, в которое только входят стрелки передачи управления.
Этап		Элемент «Этап» предназначен для определения этапа в рамках процесса на диаграмме, созданной в нотации «Процедура».
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Междиаграммная ссылка служит для обозначения перехода стрелки на диаграмму другого процесса без отображения стрелки на вышележащей диаграмме (при использовании иерархических моделей). В качестве междиаграммной ссылки не может выступать диаграмма процесса в нотациях EPC и BPMN. Междиаграммные ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, «Процесс», «Процедура».

Таблица 1. Графические символы, используемые в нотациях «Процесс» и «Процедура»

Информация о способах добавления элементов на диаграмму содержится в главе Руководство пользователя → Создание модели деятельности организации.

Пример диаграммы процесса в нотации «Процесс» приведен на Рис. 7.

Рисунок 7. Пример диаграммы процесса в нотации «Процесс»

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

Рисунок 8. Пример диаграммы процесса в нотации «Процедура»

www.businessstudio.ru

Нотации моделирования системы Business Studio: от IDEF0 до EPC : Энциклопедия результативного маркетинга

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

Business Studio — это простота и удобство

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

Используемые нотации моделирования

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

1. Нотация IDEF0

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

Методология IDEF0 — это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы. А также — потоки информации и материальных объектов, связывающие эти функции. На рисунке ниже представлена графическая диаграмма в нотации IDEF0 — пример реализован в системе Business Studio.

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

Особенностями нотации являются:

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

Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.

С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».

2.  Нотация Процесс (Basic Flowchart B Visio)

Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок — стрелки предшествования и стрелки «Поток объектов».

Нотация Процесс поддерживает декомпозицию на подпроцессы.

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

3.  Нотация Процедура (Cross-Functional Flowchart B Visio)

Эта нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса.

Нотация Процедура поддерживает декомпозицию на подпроцессы.

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

4.  Нотация BPMN 2.0

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Особенность нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, в том, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения.

Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.

В Business Studio представлено 2 типа диаграмм BPMN 2.0 — диаграммы процессов и диаграммы взаимодействия процессов.

Используются следующие графические элементы:

• процессы;
• события;
• шлюзы;

3 типа стрелок:

• поток управления;
• поток сообщений;
• ассоциации;

объекты:

• документы;
• информация;
• сообщения;базы данных.

Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.

В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, то есть поддерживается декомпозиция.

Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.

5. Нотация EPC (Event-Driven Process Chain)

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций.

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

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

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

---

А какие нотации используете в своей деятельности Вы?

Валерия Репина,бизнес-аналитик

Статьи в тему

blog.zolle.ru

Моделирование бизнес процессов. Нотация BPMN

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

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

Пул

Пул символизирует собой сотрудника, выполняющего определенную роль в процессе. Если вы хотите показать, что цепочка операций выполняется конкретной ролью, поместите эти операции в пул. Такое представление позволяет очень наглядно отобразить взаимодействие между ролями, сотрудниками в процессе. Пул — это зона ответственности роли. Почему роли? Логика очень проста — каждый сотрудник выполняет несколько ролей. Совокупность ролей – это должность. Каждая роль требует определенных знаний и навыков. Так что если вы определите роли в процессах и определите, из каких ролей складывается та или иная должность, то сможете с легкостью сформировать должностные инструкции.

Операции в пуле

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

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

Операция

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

Процесс / подпроцесс

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

Декомпозиция процесса

Событие

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

• Событие времени — истечение какого-то времени (через час) или дата/время (в 10:00)
• События состояния — идет дождь, позвонил друг, упал курс доллара и т.д.
• Событие сообщение — например, пришло письмо.
• и т.д. Подробнее о типах событий будет написано дальше.

Дата контакта с клиентом – пример промежуточного события

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

Ветвление

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

Поток операций

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

Поток сообщений

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

Потоки сообщений

Объект данных

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

Ассоциация

Этот тип соединения используется для отображения взаимосвязи информационных объектов и баз данных с операциями. В таком случае стрелка ассоциации будет иметь направление.

rzbpm.ru