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

Вопросы:
Эволюция подходов к моделированию и управлению бизнес-процессами.
Понятие моделирования бизнес-процессов.
Методология функционального моделирования IDEF0.
Диаграмма потока данных DFD.
Нотации Процесс и Процедура.
Нотация EPC.

Эволюция подходов к моделированию и управлению бизнес-процессами
Первая волна:
Фредерика Тейлора «Принципы научного управления».
Используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD.
Попытки автоматизации бизнес-процессов.
Вторая волна:
M. Хаммера и Д. Чампи «Реинжиниринг корпорации: манифест революции в бизнесе».
Появление систем управления потоками работ WfMS (Workflow Management Systems) 2-го поколения.
Третья волна:
Г. Смит и П. Фингар «Управление бизнес-процессами: третья волна».
Появление систем управления бизнес-процессами BPMS.
Стремление к стандартизации.

Эволюция подходов к моделированию и управлению бизнес-процессами

Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами:
OASIS (Organization for the Advancement of Structured Information Standards): в спецификации ebXML и BPEL, стандарты для электронного бизнеса на базе XML и веб-сервисов;
OMG (Object Management Group): стандарты BPMN и UML, MDA и CORBA;
W3C (World Wide Web Consortium): стандарты WS-CDL, WSCI, спецификации XML, технологии веб-сервисов;
WfMC (Workflow Management Coalition): стандарты Wf-XML и XPDL.
Изначально методологии BPML и BPMN были созданы консорциумом BPMI.org (Business Process Management Initiative), дальнейшее развитие BPML было прекращено в пользу BPEL, в 2005 г. произошло слияние BPMI.org с OMG, и в настоящее время работы над BPMN ведутся в рамках OMG.

Пояснение:
Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.
UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
Концепция MDA (Model Driven Architecture) призвана обеспечить общую основу для описания и использования большинства существующих стандартов, не ограничивая разработчиков в выборе конкретных технологий.
CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов; типовая архитектура опосредованных запросов к объектам) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология.
Web Services Choreography Description Language (WS-CDL). Спецификация предназначена для создания сценариев взаимодействия Web-сервисов в рамках общего бизнес-протокола.

Современный этап
Технологии автоматизации межкорпоративного взаимодействия:
бизнес-бизнес (Business-to-Business, B2B);
ebXML (Electronic Business using extensible Markup Language, ISO 15000).
Наращивание функционала систем Workflow.
Переход от задач описания процессов к задачам совершенствования по параметрам стоимости, качества и времени выполнения.
Использование системы сбалансированных показателей (BSC — Balanced ScoreCard) для обеспечения контроля результативности через наборы ключевых показателей результативности (KPI — Key Performance Indicators).

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

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

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

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

Понятие моделирования бизнес-процессов
Подходы к построению моделей БП
Функциональный
Объектно-ориентированный
Структурообразующий элемент
бизнес-функция, действие, операция
объект
(клиент, заказ, услуга)

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

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

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

Методология функционального моделирования IDEF0
Функциональный подход основан на трех принципах:
Разбиение исследуемого процесса на функциональные блоки – подпроцессы, исходя из набора принципов, среди которых принцип «определенности» (выход каждого блока должен быть ясно понимаем независимо от сложности процесса), «единственности» и т. д.
2) Возможность детализации любых процессов путем иерархической декомпозиции.
3) Использование для описания процесса графических нотаций с возможностью текстового разъясняющего дополнения.

Методология функционального моделирования IDEF0
1960-х гг. Дуглас Росс (Массачусетский технологический институт, компания SoftTech): методология структурного анализа и проектирования SADT (Structured Analysis and Design Technique).
конец 1970-х гг. Министерство обороны США, программа интегрированной компьютерной поддержки производства ICAM (Integrated Computer-Aided Manufacturing): принята значительная часть SADT.
в 1970-х гг. появился целый набор таких методов под общим названием IDEF (первоначально ICAМ DEFinition, затем Integrated DEFinition).
1981 г. Технология SADT, переименованная в IDEF0, получила статус федерального стандарта США (последняя редакция выпущена Национальным Институтом По Стандартам и Технологиям США NIST – National Institute of Standards and Technology в 1993 г.,).

Методология функционального моделирования IDEF0
IDEF0 – методология функционального моделирования, снабженная наглядным графическим языком и позволяющая представить моделируемую систему в виде набора взаимосвязанных функций. Как правило, является первым этапом изучения системы;
IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 eXtended) – методология построения реляционных структур. Относится к типу методологий «сущность-взаимосвязь» (Entity-Relationship – ER) и, как правило, применяется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

Методология функционального моделирования IDEF0
IDEF3 – методология описания процессов, происходящих в системе. Описывает сценарий и последовательность операций для каждого процесса. Близка к алгоритмическим методам построения схем процессов и стандартным средствам построения блок-схем (построение блок-схемы в программе MS Word);
IDEF4 – методология объектно-ориентированного проектирования. Реализует объектно-ориентированный анализ больших систем, предоставляя пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов;
IDEF5 – методология онтологического исследования сложных систем. Систему можно описать с помощью определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На базе этих утверждений формируются выводы о дальнейшем развитии системы и производится ее оптимизация.

Методология функционального моделирования IDEF0
Элемент – функциональный блок.

Методология функционального моделирования IDEF0
Элемент – стрелка (интерфейсная дуга).
Стрелки могут быть:
Входящие Input – вводные, которые ставят определенную задачу (вход).
Исходящие Output– выводящие результат деятельности (выход)
Управляющие (сверху вниз) Control– механизмы управления (положения, инструкции и др.).
Механизмы (снизу вверх) Mechanism
– используется для того, чтобы произвести необходимую работу (обеспечение, ресурсы).
Каждая сторона четырехугольника определяет тип стрелки.
Каждая стрелка на дочерней диаграмме должна соответствовать стрелкам на родительской диаграмме.

Методология функционального моделирования IDEF0
Граничные стрелки помечаются с помощью ICOM-меток:
Input,
Control,
Output,
Mechanism.

Методология функционального моделирования IDEF0
Принципы моделирования:
− функциональной декомпозиции;
− ограничения сложности;
− контекста.

Принцип декомпозиции
Родительская диаграмма
Дочерняя диаграмма

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

Принцип контекста
Моделирование бизнес-процесса начинается с построения контекстной диаграммы.
На диаграмме отображается только один блок – главная бизнес-функция моделируемой системы.
Планировать учебную нагрузку преподавателя
А0
Нормативные документы
Сотрудники кафедры
Спланированная учебная нагрузка преподавателя
Данные о преподавателе и учебных дисциплинах

Методология функционального моделирования IDEF0
Нумерация диаграмм:
Происходит сверху вниз — от диаграммы верхнего уровня к диаграммам нижнего уровня.
Каждая диаграмма нижнего уровня получает свой номер на основе номера родительской диаграммы верхнего уровня.

Методология функционального моделирования IDEF0
Ветвление и
слияние стрелок

Методология функционального моделирования IDEF0
Туннелирование

Рамка (каркас) диаграммы

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

Методология функционального моделирования IDEF0
Построение модели:
Шаг 1. Построение модели «как есть».
Шаг 2. Определение бизнес-правил.
Шаг 3. Построение модели «как должно быть».
Шаг 4. Распределение ресурсов.

Методология функционального моделирования IDEF0
Определение бизнес-правил

Методология функционального моделирования IDEF0
Направлена на анализ функциональных аспектов и позволяет ответить на вопрос: «Что делает система?».
Подходит для описания бизнес-процессов верхнего уровня и позволяет отразить управление процессами, обратные связи и информационные потоки.
Существует целый ряд программных инструментов, поддерживающих функциональное моделирование в стандарте IDEF0:
BPwin и ERwin, ERwin Process Modeler (Computer Associates), IDEF0.EM Tool (ИП Ориентсофт), Design/IDEF (MetaSoftware).

Методология функционального моделирования IDEF0

Диаграмма потоков данных DFD
DFD (Data Flow Diagram, 1979 г.) представляет иерархию функциональных процессов, связанных потоками данных.
Цель — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов.
Используется при построении функциональной модели TO-BE.
Распространенные графические нотации DFD:
Йордана – Де Марко (Эд Йордан (Yourdon) и Том де Марко (DeMarko));
Гейна Сарсона (Gane Sarson).

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

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

Диаграмма потоков данных DFD
Элементы:
Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны.
Внешние сущности (англ. External Entity). Любые объекты, которые не входят в систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных.
Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе.
Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

Нотация
Гейна Сарсона

Диаграмма потоков данных DFD
Требования к оформлению процесса:
Каждая функция (процесс) должна иметь идентификатор;
Название процесса нужно формулировать согласно формуле:
Название процесса = Действие + Объект, над которым действие осуществляется
Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать <Продать продукцию>.
Название работы должно быть по возможности кратким и состоять из 2-3 слов.

Диаграмма потоков данных DFD
Требования к оформлению потока:
Название потока нужно формулировать согласно формуле:
Название потока = Объект, представляющий поток + Статус объекта
Если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать <Продукция, отгруженная> или <Продукция, отгруженная клиенту>. В данном случае <Продукция> это объект, представляющий поток, а <отгруженная клиенту> — статус объекта.
Название должно быть по возможности кратким и состоять из 2-3 слов.

Диаграмма потоков данных DFD
Требования
нумерации:
Внешние сущности
(External Entity).
Хранилище данных
(Data store).

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

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

Диаграмма потоков данных DFD

Диаграмма потоков данных DFD
Шаг 1. Построение контекстной диаграммы.
Уровень системы

Диаграмма потоков данных DFD
Шаг 1. Построение контекстной диаграммы.
В некоторых случаях стоит построить несколько контекстных диаграмм с иерархией:
наличие большого количества внешних сущностей (десять и более);
распределенная природа системы;
многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

Диаграмма потоков данных DFD
Шаг 2. Детализация подсистем на контекстной диаграмме.
Правила:
балансировки — при детализации процесса дочерняя диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь соответствующий процесс на родительской диаграмме;
нумерации — при детализации процессов должна поддерживаться их иерархическая нумерация.
семи — для того, чтобы диаграмма легко читалась, количество функций на диаграмме не должно быть больше семи. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

Диаграмма потоков данных DFD
Шаг 2. Детализация подсистем на контекстной диаграмме.
Уровень подсистемы

Диаграмма потоков данных DFD
Шаг 2. Детализация подсистем на контекстной диаграмме.
Уровень процесса

Диаграмма потоков данных DFD
Шаг 3. Миниспецификация.
Документ, детально описывающий логику процесса. Содержит номер процесса, списки входных и выходных данных, тело процесса — подробный алгоритм функции, преобразующий входные потоки данных в выходные.

Диаграмма потоков данных DFD
Шаг 3. Миниспецификация.
Требования:

Диаграмма потоков данных DFD
Шаг 4. Создание Словаря данных.
Определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонент хранилищ.
Определения элементов данных в словаре осуществляются:
описанием значений потоков и хранилищ, изображенных на DFD;
описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные символы (например, АДРЕС ПОКУПАТЕЛЯ содержит ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ и т.д.);
описанием композиции групповых данных в хранилище;
специфицированием значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах;
описанием деталей отношений между хранилищами.

Диаграмма потоков данных DFD
Шаг 4. Создание Словаря данных.
Определяются структура и содержание всех потоков данных и хранилищ данных, которые присутствуют на диаграммах.
Для каждого потока в словаре хранятся: имя потока, тип, атрибуты.
Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.

Нотации Процесс и Процедура
Нотация Basic FlowChart (BFC, Процесс, простая блок-схема) применяется для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, например, совместно с IDEF0.
Представляет алгоритм выполнения процесса и является нотацией класса workflow.
Позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса.
1921 г. – американский инженер Франк Банкер Гилбрет представил первый структурированный метод для документирования потоков процесса (flow process chart) для членов Американского общества инженеров-механиков (American Society ofMechanical Engineers , ASME).

Нотация Процесс
Графические элементы нотации BFC:

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

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

Нотация Процесс

Нотация Процедура
Нотация Cross Functional Flowchart (CFC, Процедура , функциональная блок-схема, кросс-функциональная схема, перекрестно-функциональная диаграмма) отображает процесс на нижнем уровне бизнес-модели.
Разработана в 1990-ых гг. на основе диаграмм, которые использовались для представления алгоритмов и описания логики компьютерных программ.
Процедура отображает детальный алгоритм выполнения бизнес-процесса, участников бизнес-процесса и их взаимодействие в рамках Процедуры.

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

Нотация Процедура
Графические элементы CFC:

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

Нотация CFC

Нотация EPC
Нотация Event-Driven Process Chain (EPC, событийная цепочка процессов) используется для описания процессов на разных уровнях.
Представляет упорядоченную комбинацию событий и функций.
Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её.
Может быть проведена декомпозиция (например, в нотациях EPC или BPMN).
Нач. 1990-ых гг. – EPC-метод разработан Августом-Вильгельмом Шеером (August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems, Архитектура интегрированных информационных систем).
Методология EPC существует в разных интерпретациях (ARIS, Microsoft Visio, Business Studio, Bflow).

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:

Нотация EPC
Основные графические элементы EPC:
https://sites.google.com/site/anisimovkhv/learning/pris/lecture/tema8/tema8_3
http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation

Нотация EPC
Типы связей между объектами на диаграмме процесса в нотации EPC (http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation):
процесса;
субъекта;
программного продукта;
документа;
базы данных;
информации;
товарно-материальных ценностей (ТМЦ);
терминов;
операторов.

Нотация EPC
Правила моделирования:
1. Диаграмма функции должна начинаться как минимум одним стартовым событием) и завершаться как минимум одним конечным событием.
2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями.
3. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
4. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.

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

Нотация EPC
Правила моделирования:
6. На диаграмме не должны присутствовать объекты без единой связи.
7. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и хотя бы двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями.
8. Если оператор обладает входящей связью от элемента "событие", то он должен обладать исходящей связью к элементу "функция" и наоборот.
9. За одиночным событием не должны следовать операторы OR или XOR.
10. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.
11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления AND, оператор объединения OR .

Нотация EPC
Допустимые ситуации

Нотация EPC
Недопустимая ситуация

Нотация EPC
Алгоритм построения диаграммы:
Шаг 1. Определить начальное и конечное события.
Шаг 2. Добавить действия и соответствующие им промежуточные события.
Шаг 3. Присоединить документы и (или) информацию, которая необходима для выполнения каждого этапа (входы) и документы, которые являются результатами работы на каждом этапе (выходы).
Добавить связи с исполнителями и с обозначением ролей.
Распространенная роль – «выполняет».
Другие: «утверждают результат», «отвечает за техническую часть», «должен быть уведомлен о нестандартном завершении» и т.п.
Шаг 4. Оценить полноту и качество схемы. Проанализировать, все ли варианты исполнения процесса учтены в схеме.

Нотация EPC
Алгоритм построения диаграммы:
Пример первого шага

Нотация EPC
Алгоритм построения диаграммы:
Пример второго шага

Нотация EPC
Алгоритм построения диаграммы:
Пример третьего шага

Нотация EPC