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

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

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

Можно отметить 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 позволяет создавать свои, что позволяет адаптировать нотацию к любым потребностям.

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

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

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

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

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

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

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

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

Основы бизнес-моделирования: 5 популярных нотаций с примерами | by Nick Komissarenko

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

ЧТО ТАКОЕ БИЗНЕС-МОДЕЛИРОВАНИЕ: ВЗГЛЯД BABOK НА МНОГООБРАЗИЕ НОТАЦИЙ

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

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

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

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

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

СТРУКТУРА И ДИНАМИКА: КАК ОПИСАТЬ СИСТЕМЫ И БИЗНЕС-ПРОЦЕССЫ

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

· Структурные, которые показывают компонентный состав исследуемого объекта и взаимосвязи между его элементами. Например, UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. Из нотаций стандарта IDEF к структурным относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6.

· Динамические, которые показывают движение потоков данных или логику выполнения процессов. Например, DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

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

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

· при разработке требований к программному обеспечению и документировании готового решения чаще всего применяется стандарт UML, позволяющий описать проектируемый продукт в объектно-ориентированных терминах. Для описания структуры базы данных используется ERD-нотация IDEF1x (Extended). А DFD-диаграмма наглядно продемонстрирует движение потоков данных между различными хранилищами (СУБД, файлы, бумажные и другие материальные носители) и процессами по их преобразованию.

· для описания бизнес-процессов предприятия с целью их анализа и последующей оптимизации используются нотации IDEF0, BPMN, EPC. При этом указанные методы отлично дополняют друг друга, детализируясь от структуры метапроцессов, таких как «продвижение и продажи», «осуществление основного вида деятельности» и пр., представленных в IDEF0, к пошаговым алгоритмам, показывающим логику исполнения процессов в виде EPC- или BPMN-диаграмм. Например, именно такой подход реализован в популярной отечественной системе бизнес-моделирования Business Studio [8].

От структуры к логике: функциональная декомпозиция IDEF0-процесса в BPMN в системе Business Studio

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

Пример простой EPC-диаграммы без логических ветвлений в системе Business Studio

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

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

INTRO: Основы бизнес-анализа для начинающих

UML для бизнес-аналитика

ЗАПИСАТЬСЯ НА ОБУЧЕНИЕ

Источники

1. https://ru.wikipedia.org/wiki/Нотация

2. https://ru.wikipedia.org/wiki/UML

3. https://ru.wikipedia.org/wiki/IDEF

4. https://ru.wikipedia.org/wiki/BPMN

5. https://ru.wikipedia.org/wiki/IDEF3

6. https://en.wikipedia.org/wiki/IDEF4

7. https://www.iiba.org/standards-and-resources/babok/

8. https://www.businessstudio.ru/products/business_studio/notations/

Что такое бизнес-моделирование: краткий обзор популярных нотаций

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

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

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

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

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

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

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

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

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

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

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

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

От структуры к логике: функциональная декомпозиция IDEF0-процесса в BPMN в системе Business Studio

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

Пример простой EPC-диаграммы без логических ветвлений в системе Business Studio

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

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

 

 

Источники

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

Нотации моделирования

Нотация IDEF0

IDEF0 — одна из наиболее популярных нотаций моделирования бизнес-процессов семейства нотаций IDEF, основанная на методологии структурного анализа SADT (Structured Analysis & Design Technique*). IDEF0 служит для создания функциональной модели, включающей структурированное описание функций, действий или процессов моделируемой системы.

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

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

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

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

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

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

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

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

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

Нотация Процедура (Cross Functional Flowchart в Visio)

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

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

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

Нотация BPMN 2.0

BPMN 2.0 (Business Process Model and Notation) — модель бизнес-процессов и нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Важной особенностью данной нотации является то, что она предназначена как для моделирования бизнес-процессов, так и для их последующего исполнения. BPMN 2.0 доступна для понимания как бизнес-аналитикам, так и IT-специалистам, которые занимаются автоматизацией исполнения процессов. Экспорт схем процессов из Business Studio возможен посредством стандарта XPDL.

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

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

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

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

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

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

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

Подробную информацию о нотациях можно посмотреть в методике «Проектирование системы управления».

Нотации бизнес-процессов. | Тринион.Системный интегратор.

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

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

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

Цели моделирования

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

Первая цель моделирования – наглядно и однозначно поставить задачу или пояснить решение. Графика – всегда нагляднее слов. В случае использования нотаций разночтений практически не возникает.

Графика против текста

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

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

Преимущества такого подхода:

1. Графика нагляднее. Она проще воспринимается.
2. Графика обладает глубиной. В отличие от последовательности слов, графическая нотация двухмерна. В отличие от цепочки, здесь можно продемонстрировать взаимодействие слева-направо, сверху-вниз и т.д.
3. Графические нотации информативны. Кроме самой графики, они содержат краткие и однозначные текстовые пояснения.
4. Нотация кратко и наглядно на одной схеме поясняет суть решения: от и до.

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

В своей практике я видел технические задания, состоящие из 200 или 300 страниц. Честно говоря, я с трудом представляю, как можно в голове «связать» такой объем информации. А ведь это не художественная литература, здесь каждая страница содержит огромное количество технической информации. А ведь ее нужно не просто изучить и понять, но еще и обсудить, а иногда и «защитить» идею. Графическая нотация в этом случае явно выигрывает.

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

Какие бывают нотации

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

•      функциональным;
•      процессным;
•      ментальным.

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

В зависимости от поставленной задачи выбирают и языки моделирования – IDEF0, IDEF3, BPMN, UML, ARIS и многие другие.

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

Выбор языка моделирования.

Язык графических нотаций выбирают с точки зрения выбранного подхода и особенностей применения.

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

Для описания последовательности действий при выполнении каких-то работ оптимально подойдет IDEF3 или BPMN.

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

Что касается вопроса: «А какой из языков, созданных для одинаковых целей лучше?» — я считаю, это зависит от личных предпочтений. Я не использую ARIS или Дракон, предпочитаю языки семейства IDEF0 и BPM. С моей точки зрения они удобны, и другие просто ни к чему. Другие люди работают в том же Драконе, и, думаю, смогут привести массу доводов, почему он для них оказался самым лучшим.

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

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

В каком порядке моделировать?

Для начала вспомним бессмертную истину – «нельзя объять необъятное». Следовательно, необходимо:

•      очертить границы модели.

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

Следующий этап:

•       изучаем поставленную задачу.

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

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

Далее,

•      создается первый вариант графической нотации и вносятся уточнения.

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

И последний этап –

•      текстовые пояснения.

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

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

Насколько важно знать сферу деятельности при моделировании?

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

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

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

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

Подведем итоги.

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

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

Что такое нотация BPMN. Основные понятия с примером

О бизнес-процессах, что такое BPM

Разговаривать о процессном подходе, методологии BPM и нотации BPMN невозможно без понятия бизнес-процесса.

Управление процессом – вот что предполагает методология BPM. Существует множество определений, что такое бизнес-процесс, и выбрать какой-то один сложно. Но можно выделить ключевые свойства бизнес-процесса:

1. Повторяемость. Выполнение одних и тех же экземпляров по одному шаблону. Например, бизнес-процесс «Ремонт автомобиля». Каждый заказчик, который хочет отремонтировать автомобиль, проходит ряд этапов: приходит в офис, оформляет заявку, отдает в ремонт, оплачивает услуги, получает отремонтированный автомобиль, т.е. шаблон процесса один, но заказчик, автомобиль и сам ремонт различны.
2. Предсказуемость. Все задачи, события, развилки известны наперед. Хочется обратить внимание на это свойство. Сейчас не всегда бизнес-процесс «предсказуем» и мы можем определить реально ВСЕ развилки. Поэтому тут лучше сказать не предсказуемы, а полуформальны, для вариантов действий используется понятие «кейсы». Например, поведение пациента в больнице. Бизнес-процесс ли это? Да, но все ли развилки мы можем сразу определить, их может быть миллион.
3. Кросс-функциональность – участвует несколько бизнес-функций (подразделений).
4. Сквозной – история рассказана от начала и до конца. Бизнес-процесс должен иметь старт и финиш (результат его выполнения).

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

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

В методологии BPM рассматриваются следующие понятия:

• Видение – образ глобального будущего. Это мир условно через 5 лет.
• Миссия – глобальные шаги Компании. Что нужно делать Компании, чтобы соответствовать этому будущему миру. Место в этом мире.
• Стратегия – конкретные шаги для достижения миссии.
• Процессы – детализированные шаги стратегии.

  BPM позволяет более гибко реагировать на изменчивость мира. Процессы изменчивы и это данность, в схему процесса могут и должны вноситься изменения. Отсюда возникает цикл «PDCA (Plan-Do-Check-Act)»:

• Планирование
  — Анализ процесса — Проектирование процесса
• Действие
  — Внедрение процесса — Исполнение процесса
• Проверка
  — Измерение эффективности — Сравнение с целевыми показателями
• Корректировка
  — Вмешательство в ход процесса — Изменение схемы процесса

В век цифровой трансформации методология BPM как никогда становится востребованной. Те компании, кто способен гибко и во время перестраивать свои бизнес-процессы повышают эффективность своего бизнеса.

 

Каким компаниям подходит использование BPM

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

• 0 уровень. Для этого уровня характерно небольшое количество сотрудников, которые горят идеей. Процессы понятны, сложностей в руководстве нет.
• 1 уровень. Это компании до 50 человек. На этом этапе руководить процессами становится тяжелее и на помощь приходит их жесткая регламентация. Трудности на этом этапе ‒ это устаревание регламентов. Также, надо понимать, что чем подробнее и жестче регламент, тем меньше людей заставишь работать по нему.
• 2 уровень. На этом уровне Компания автоматизирует свои бизнес-процессы. Всё «зашивается» в ERP систему, и из-за этого сложно ‒ гибко и быстро реагировать на изменения, поменять бизнес-процесс сложно.
• 3 уровень. На этом уровне компания готова управлять сквозными бизнес-процессами, ей жизненно необходима гибкость в этом. На этом этапе имеет смысл использовать методологию BPM.

Нотация BPMN

BPMN – система условных обозначений (нотация) и их описания для моделирования бизнес-процессов. Для исполнения смоделированных бизнес-процессов с помощью BPMN существует инструмент BPMS. Ярким представителем является BizAgi.

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

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

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

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

В регламентированном описании бизнес-процессов в нотации BPMN используется примерно 10 значков без привязки к методологии, она не сложнее других нотаций, таких как (IDEF, DFD, Aris, EPC, UML, BPEL), понятна без специализированного обучения (базовый уровень) и идеальна для коммуникаций Аналитик — Бизнес.

Для исполнения процесса в нотации BPMN используется примерно 100 значков и модификаторов, нотация BPMN позволяет точно и однозначно описывать процесс, используется строгая семантика – возможность исполнения, последовательность шагов внутри процесса, межпроцессное взаимодействие, переносимый формат на основе XML (XPDL, BPDM) и идеальна для коммуникаций Аналитик — Программист.

К преимуществам BPMN следует также отнести открытый стандарт Object Management Group (omg.ru) и признания ее всеми ведущими поставщиками ПО.

К недостаткам нотации BPMN можно отнести коллективное авторство в рамках «не привязки» к методологии, не хватает стройности, что ведет к сложности освоения и реализации в BPMS. Решается данный недостаток соглашением о моделировании – своде правил, чем пользуемся в организации, в рамках проекта.

Читать бизнес-процесс, отрисованный с помощью нотации BPMN, проще, чем его рисовать. При этом читать Заказчику проще СВОЙ процесс. К принципам описания следует также отнести итерационный подход – сначала делается эскиз бизнес-процесса, а затем постепенно наращивается сложность. По сути своей BPMN — это блок-схема, и стремится нужно к простоте ее понимания, а не к усложнению. Схема в идеале должна помещаться на формат A4.

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

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

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

— Event

 

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

Старт необязателен при описании бизнес-процесса, не запрещено также использовать несколько стартов. Завершение также необязательно, т.к процесс может, например, заканчиваться ошибкой. Также как стартов, завершений может быть больше одного. Хорошим стилем считается использование одного старта, несколько завершений.

— Task

 

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

— Gateway

 

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

— Flow

 

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

• Сontrol – последовательность выполнения задач внутри потока работ,
• Message – передача сигналов и информации между потоками работ,
• Association – используется для визуализации связи между элементами потока и объектами, не являющимися элементами потока.

— Date

 

Объекты данных – показывает либо результат выполненного действия, либо какие данные, объекты требуются для запуска действия.

 

— Pool

 

 

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

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

Пример применения BPMN

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

Бизнес-процесс в компании выстроен так:

1. Сотрудник на портале сотрудника заполняет заявку на потребность, где указывает номенклатуру и необходимое ему количество товара.
2. Данная заявка проверяется на необходимость Менеджером в системе.
3. Если потребность подтверждена, Менеджер проверяет, есть ли заказанный товар на складе. При наличии —  резервирует. Если товара на складе нет, Менеджер отправляет заявку на согласование.
4. Сотрудник отдела Закупок, если заявка подтверждена, создает заказ поставщику. Иначе — бизнес-процесс закупки завершается.

5. После получения товаров от поставщика, Кладовщик приходует и выдает Сотруднику со склада заказанные наименования.

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

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

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

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

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

 

НОТАЦИИ ДЛЯ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ — Business architecture

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

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

• использование контекстной диаграммы;
• поддержка декомпозиции;
• доминирование;
• выделение 4 типов стрелок (вход, выход, механизм, управление).

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

Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.

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

Нотация IDEF3 — важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). В течение длительного
времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне — при описании работ, выполняемых в подразделениях и на рабочих местах. Данная нотация являлась прототипом для создания нотации Aris eEPC.

Моделирование в нотациях IDF0, IDF3 приобрело популярность в программном продукте Erwin Business Process. Сейчас в данных нотациях можно моделировать в программном продукте Business studio, который создан в России. Программные продукты Erwin и Business studio являются дорогостоящими платными решениями (с 30 дневным бесплатным режимом). Нотация не служит для исполнения бизнес-процессов, а служит только для их анализа.

Нотация ARIS eEPC– расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

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

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

Данная нотация используется в программном продукте – Aris Express (бесплатная версия), Aris Toolset (платная версия), Business studio (платная версия).  Нотация не служит для исполнения бизнес-процессов, служит только для анализа бизнес-процессов.

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

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

Нотация используется как в бесплатных решениях (Bonita BPM, Bizagi и др), так и в платных решениях (Pega BPM, IBM BPM, Elma BPM и др.). Нотация может служить для моделирование исполняемых бизнес-процессов и не исполняемых.

BPEL (англ. Business Process Execution Language) — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.

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

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

Основные файлы BPEL-проекта:

• .bpel — логический синтез и координация веб-служб. Фактически алгоритм исполнения бизнес-процесса. (его графическое представление напоминает блок-схему и диаграмму потоков данных в одном лице).
• .wsdl — описание интерфейсов для обмена сообщениями. «Как достичь веб-службы» (WSDL).
• .xsd — описание структур данных проекта (XML Schema).

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

<process name=»mathProcess» targetNamespace=»http://example.com/ws-bp/math»

 xmlns=»http://docs.oasis-open.org/wsbpel/2.0/process/executable»

 xmlns:math=»http://manufacturing.org/wsdl/math»>

    <partnerLinks>

        <partnerLink name=»Math» partnerLinkType=»math:exampleMath» myRole=»mathService» />

    </partnerLinks>

    <variables>

        <variable name=»numIn»   messageType=»math:unsignedInt»/>

        <variable name=»numOut»  messageType=»math:unsignedInt»/>

        <variable name=»num»     type=»xsd:unsignedInt»/>

    </variables>

    <sequence>

        <receive partnerLink=»Math» portType=»math:mathPort» operation=»secondDegree» variable=»numIn» createInstance=»yes»/>

        <assign name=»LoopCounterIncrement»>

          <copy>

             <from>$numIn.request</from>

             <to variable=»num»/>

          </copy>

          <copy>

             <from>$num * $num</from>

             <to variable=»numOut» part=»response»/>

          </copy>

        </assign>

        <reply operation=»secondDegree» partnerLink=»Math» portType=»math:mathPort» variable=»numOut»/>

    </sequence>

 </process>

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.

Стандартные операции: 

• Action: выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями.
• Assign: присваивает новое значение показателю.
• Call: запускает процесс и ждет его завершения.
• Compensate: инициирует компенсацию для указанных процессов.
• Delay: выражает промежуток времени.
• Empty: ничего не делает.
• Fault: выдает сообщение об ошибке в текущем контексте.
• Raise: активизирует сигнал.
• Spawn: запускает процесс без ожидания его завершения.
• Synch: синхронизирует по сигналу.

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

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

1. Программные продукты, где используются рассмотренные нотации, кроме BPMN, являются платными. Стоимость может доходить до нескольких тысяч долларов.
2. Нотация IDF0 используется для описания верхнеуровневых бизнес-процессов, нотация IDF3 и eEPC служит для описания потока работы. Нотации используются в Erwin Business modeler и Aris. Данные нотации идеально читаются и подходят для анализа системы, бизнес-процессов.
3. Нотация BPMN используется в нескольких профессиональных BPM системах и служит для моделирования исполняемых и не исполняемых бизнес-процессов. Чтение нотации для обычных работников затруднительно.
4. Нотация BPEL используется программистами, чтение обычными пользователями затруднительно.

Что такое нотация моделирования бизнес-процессов (BPMN)?

По

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

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

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

Последний раз обновлялся в ноябре 2010 г.

Продолжить чтение о нотации моделирования бизнес-процессов (BPMN)

Узнайте больше о корпоративных бизнес-приложениях

Моделирование и нотация бизнес-процессов (BPMN) 101

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

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

События расширены

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

Расширенные подпроцессы событий

Задачи действий, подпроцессы, транзакции и действия вызовов расширены

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

• Прием ожидает сообщения от внешнего участника.

• Скрипт — задача, выполняемая движком.

• Manual — это задача, которая работает без помощи двигателей или приложений.

• Прием (экземпляр) — это задача, которая предназначена для ожидания получения сообщения от внешнего участника. Затем он создает экземпляр процесса.

• Служба — это задача, которая использует веб-службу или автоматизированное приложение.

• Пользователь — это задача, выполняемая человеком, которая запланирована с помощью менеджера.

• Отправить — это задача, предназначенная для отправки сообщения внешнему участнику.

• Бизнес-правило — это задача, которая подтверждает с помощью механизма бизнес-правил ввод перед выполнением.

Также для задачи определены три типа маркеров. К ним относятся петля, несколько экземпляров и компенсация.

• Цикл будет продолжаться, пока выполняется условие; может быть указана числовая заглавная буква.

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

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

Задачи цикла, задачи с несколькими последовательными экземплярами и задачи компенсации, соответственно.

Подпроцессы показывают более низкие или более подробные уровни в событии процесса. Свернутый подпроцесс показан ниже:

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

Источник: OMG

Подпроцесс транзакции

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

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

Расширенные шлюзы

Нотация

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

• Эксклюзивные шлюзы — основной тип. У них может быть крестик посередине или они могут быть пустыми. Они моделируют альтернативные пути и являются местом отклонения.

• Шлюзы на основе событий используются для моделирования альтернативных путей, но основаны на происходящих событиях, а не на выражении потока.

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

• Сложные шлюзы моделируют сложное поведение синхронизации.

• Параллельные шлюзы создают и объединяют параллельные потоки. Они не проверяют никаких условий.

Расширенные объекты данных

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

Слева направо: ввод данных, вывод данных, сбор объектов данных, сбор вводимых данных и сбор данных вывода.

Соединение объектов расширено

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

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

• Потоки по умолчанию выбираются только в том случае, если другие потоки последовательности недоступны. Условия в потоке последовательности по умолчанию всегда игнорируются. Для каждого объекта может быть только один поток по умолчанию.

• Исключительные потоки возникают вне нормального потока процесса и основаны на промежуточном событии на границе.

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

Условные потоки и потоки по умолчанию.

Исключительные потоки и потоки компенсации.

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

BPMN отображает эти четыре типа элементов для диаграмм бизнес-процессов:

1. Объекты потока: события, действия, шлюзы
2. Соединяющие объекты: поток последовательности, поток сообщений, ассоциация
3. Дорожки: пул или дорожка
4. Артефакты: объект данных, группа, аннотация

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

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

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

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

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

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

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

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

Дополнительная информация, которую разработчики добавляют для обеспечения необходимого уровня детализации диаграммы.Есть три типа артефактов: объект данных, группа или аннотация. Объект данных показывает, какие данные необходимы для действия. Группа показывает логическую группировку действий, но не меняет последовательность операций на диаграмме. В аннотации дается дополнительное объяснение части схемы.

Символы и обозначения схем BPMN

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

9 лучших методов моделирования бизнес-процессов (с примерами)

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

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

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

За прошедшие годы было разработано множество методов моделирования бизнес-процессов. Давайте изучим ваши варианты.

1. Нотация моделирования бизнес-процессов (BPMN)

BPMN состоит из серии символов или «стандартных объектов» для представления задач и рабочих процессов. Конечно, ничто не мешает вам разработать собственный набор символов.Однако использование стандартных упрощает сотрудничество с внешними аналитиками и избавляет вас от необходимости придумывать собственный визуальный язык.

Что такое Tallyfy?

Tallyfy помогает вам документировать и автоматизировать задачи между коллегами и клиентами

Немного о Tallyfy

Вы хотите автоматизировать задачи между коллегами или клиентами? Вы нашли для этого подходящее приложение! С Tallyfy вы можете автоматизировать задачи и бизнес-процессы за считанные минуты.

Вернемся к остальной части этой статьи!

Щелкните здесь, чтобы узнать о Tallyfy

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

BPMN-символы делятся на следующие категории:

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

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

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

2. Диаграммы UML

Диаграммы UML (унифицированный язык моделирования) предлагают альтернативный метод моделирования бизнес-процессов. Язык моделирования был разработан разработчиками программного обеспечения, но его можно адаптировать для моделирования бизнес-процессов. Есть только одна проблема с диаграммами UML, или, скорее, мы должны сказать, что их не менее четырнадцати! Существует не менее 14 типов диаграмм UML.Как вы понимаете, это ограничивает полезность диаграмм UML, поскольку понимание этого типа диаграмм намного сложнее, чем интерпретация представлений на основе BPMN.

Хотя есть некоторые споры о том, какой подход лучше всего подходит для моделирования бизнес-процессов, большинство экспертов сходятся во мнении, что BPMN ориентирована на процессы, а UML — на объектно-ориентированные, и что это делает BPMN лучше для представления бизнес-процессов.

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

Хотите узнать об использовании каждого типа диаграммы UML? У нас есть для этого руководство!

3. Блок-схемы

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

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

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

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

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

4. Диаграммы потоков данных (DFD) Yourdon

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

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

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

5. Диаграммы Ганта

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

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

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

6. Диаграммы PERT

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

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

7. Блок-схемы функциональных потоков

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

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

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

8. Интегрированное определение для моделирования функций (IDEF)

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

Существует 15 форм IDEF, каждая из которых обращается к разному типу потока. Таким образом, существуют различные формы IDEF для функций, информации, данных, проектирования имитационной модели, сбора описания процесса и т. Д.

9. Сети Петри и цветные сети Петри (CPN)

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

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

Программное обеспечение BPM: наилучшее использование методов моделирования бизнес-процессов

Хотя методы моделирования BPM полезны сами по себе, их лучше всего использовать с помощью программного обеспечения BPM.

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

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

Не знаете, какой инструмент BPM выбрать? Эти 5 — одни из самых лучших.

Что такое BPMN?

История BPMN

BPMN является производной от синтеза множества нотаций бизнес-моделирования.Изначально опубликованная Business Process Management Initiative (BPMI) в 2004 году, BPMN теперь поддерживается OMG после слияния двух организаций в 2005 году. BPMI объединилась с OMG, Object Management Group. Документ спецификации BPMN был выпущен OMG в феврале 2006 года. Версия 2.0 BPMN была разработана в 2010 году, а фактическая версия спецификации была выпущена в декабре 2013 года. Последняя версия (BPMN 2.0.2) была официально опубликована ISO в качестве стандарта издания 2013 года: ИСО / МЭК 19510.

Базовые конструкции

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

Дорожки

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

Элементы потока

Элементы потока — это элементы, которые соединяются друг с другом для формирования бизнес-процессов. Элементы потока — это основные элементы, определяющие поведение процесса.Существует три типа элементов потока: события, действия и шлюзы.

Соединение объектов

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

Данные

Данные — это в основном информация, необходимая или производимая при выполнении бизнес-процесса.Существует четыре типа данных: объекты данных, входные данные, выходные данные и хранилища данных.

Дорожки плавания BPMN

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

Есть два типа дорожек: бассейны и дорожки.

Бассейны

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

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

Дорожки

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

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

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

Деятельность

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

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

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

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

События

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

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

У каждого процесса должно быть стартовое событие, показывающее начало бизнес-процесса.Это позволяет читателям найти в BPD, где начинается процесс. Более того, конечное событие используется, чтобы указать, где завершается бизнес-процесс, а промежуточное событие отвечает за управление бизнес-потоком на основе события, которое оно указывает. Промежуточное событие может быть присоединено к действию для моделирования события, которое может произойти ВО ВРЕМЯ выполнения этого действия, а также может быть связано с помощью соединяющего объекта для моделирования события, которое может произойти ПОСЛЕ выполнения элемента потока раньше. Мы поговорим более подробно позже в этом уроке.

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

Шлюзы

Шлюзы

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

Вот несколько типичных типов шлюзов:

Эксклюзивный шлюз на основе данных

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

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

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

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

Потоки последовательности

Последовательный поток используется для соединения элементов потока.Он показан сплошной линией со стрелкой. Он показывает порядок элементов потока.

Поток последовательности можно использовать только для соединения элементов потока в одном пуле: либо в одном пуле / полосе, либо между дорожками одного пула. Если вы хотите соединить элементы между пулами, вы не можете использовать поток последовательности, а вместо этого поток сообщений.

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

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

Поток последовательности можно использовать только для соединения элементов потока в одном пуле: либо в одном пуле / полосе, либо между дорожками одного пула. Если вы хотите соединить элементы между пулами, вы не можете использовать поток последовательности, а вместо этого поток сообщений.

Данные

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

Группы

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

Текстовые аннотации

Текстовая аннотация может использоваться для добавления дополнительных деталей к объектам потока в BPD. Он не влияет на поток, но дает подробную информацию об объектах внутри потока.

BPMN — пример

Компания True Aqua Distilled Water Company — молодой поставщик дистиллированной воды в городе. Они продают дистиллированную воду для бизнеса и для дома. Теперь компания True Aqua Distilled Water Company хочет увеличить свою долю рынка с 5% до 10% в следующие 12-18 месяцев.Для достижения этой цели они пытаются найти способы повышения операционной эффективности и достижения более высокого уровня удовлетворенности клиентов.

В результате компания True Aqua Distilled Water Company решила улучшить процесс заказа дистиллированной воды. Теперь вы бизнес-аналитик, отвечающий за эту миссию. После встречи с компанией True Aqua Distilled Water Company вы собрали следующую информацию о процессе заказа. Давайте взглянем.

На рисунке ниже представлена ​​бизнес-схема процесса доставки дистиллированной воды компании True Aqua Distilled Water Company.

Согласно схеме, клиенты могут позвонить на горячую линию или отправить нам электронное письмо для заказа дистиллированной воды. В настоящее время 90% заказов поступает по телефону, а 10% заказов размещается по электронной почте. Помощник по обслуживанию клиентов, получивший заказ, проверит, является ли клиент существующим клиентом или новым. Если клиент никогда раньше не размещал заказ, помощник по обслуживанию клиентов создаст для него или нее учетную запись клиента до обработки заказа.

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

Ссылки по теме

1. Профессиональный инструмент моделирования процессов BPMN
2. Попробуйте Visual Paradigm БЕСПЛАТНО

Что такое BPMN? Стандартное обозначение бизнес-процессов — BPI

Управление процессами публикаций в блоге

---

Что такое BPMN? BPMN расшифровывается как «Обозначение модели бизнес-процесса».Это актуально, когда дело доходит до определения, управления и совместного использования процессов в рамках дисциплины BPM. Текущая версия стандарта — 2.0.

В нашем последнем посте мы рассмотрели определение BPM и то, как начать его применять на малых, средних или крупных предприятиях. Пытаясь помочь владельцам бизнеса понять дисциплину BPM, мы подумали, что пришло время охватить мировой стандарт BPMN. Это наиболее распространенный стандарт для моделирования и обозначения процессов. Мы представим его, отвечая на вопрос «Что такое BPMN?» вопрос.

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

Итак, что такое BPMN?

Вместо ответа на вопрос «что такое BPMN? «Мы решили представить вам отличную статью, опубликованную Брюсом Сильвером, специалистом по BPM, который написал много книг по этой теме и работает независимым консультантом и аналитиком.Статья гласит:

---

«В Твиттере кто-то написал мне:« Вы когда-нибудь видели краткий обзор BPMN, который имеет смысл для людей, которые никогда о нем не слышали? » Хммм… Наверное, нет. Итак, вот моя попытка.

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

Во-первых, BPMN — это открытый отраслевой стандарт под эгидой Object Management Group. Он не принадлежит конкретному инструменту или консалтинговой компании. Его поддерживают самые разные инструменты, и смысл диаграммы бизнес-процесса не зависит от инструмента, использованного для ее создания. С BPMN вам не нужно стандартизировать единый инструмент для всех в организации, поскольку все они используют общий язык моделирования процессов.

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

В-третьих, BPMN — это язык , используемый бизнесом и ИТ , первый язык моделирования процессов, способный заявить об этом. Когда около 10 лет назад впервые была разработана BPMN, единственные доступные на тот момент стандарты моделирования процессов — диаграммы активности UML и IDEF, среди прочего — были отвергнуты как «стандарты ИТ», которые не были приняты бизнес-пользователями. Для бизнес-пользователей диаграмма процесса выглядела как блок-схема, широко используемая практиками BPM, но не имеющая точного определения в спецификации.BPMN адаптировала базовый внешний вид блок-схемы дорожек и добавила к ней точности и выразительности, необходимых ИТ. Фактически, этой точности и выразительности достаточно, чтобы управлять механизмом автоматизации процессов в BPM Suite (BPMS). Тот факт, что визуальный язык, используемый бизнесом для описания предлагаемого будущего процесса, совпадает с языком, используемым разработчиками для построения этого процесса в BPMS, открыл новую эру бизнес-решений для процессов, в которых бизнес и ИТ-специалисты тесно сотрудничают на протяжении более быстрого и гибкого цикла улучшения процессов.

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

Итак, да, внедрение BPMN связано с расходами, независимо от того, переходите ли вы от обычных инструментов, таких как блок-схемы Powerpoint или Visio, или от мощного, но проприетарного языка, такого как ARIS EPC. Существует новый словарь диаграмм для изучения, правила построения диаграмм, а также упомянутые выше соглашения и методология, такие как метод и стиль. Но польза от общения на общем языке процесса огромна.Инвестиции в обнаружение и анализ процессов намного превышают стоимость инструмента или время, необходимое для построения диаграмм. Это включает в себя сотни человеко-часов встреч, сбор информации от заинтересованных сторон, семинары и презентации руководству. Диаграмма процесса — это результат всего этого времени и усилий. Если он не может быть передан всей проектной команде — бизнесу и ИТ — или другим проектным группам на предприятии, сейчас или в будущем, вы выбрасываете большую часть этих инвестиций. BPMN предоставляет возможность совместно использовать его , не требуя от всех стандартизировать один инструмент. […]

Хорошо, некоторые, вероятно, говорят, что если BPMN настолько хороша, почему я слышу эти жалобы на нее? Да, это хороший вопрос.

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

Проблема в том, что подробное поведение узлов потока фактически определяется их значками, маркерами и стилями границ. Я с готовностью признаю, что их слишком много. Лишь небольшая часть из них широко используется и ее важно знать; остальное можно просто игнорировать. […]

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

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

No related posts.