Описание бизнес процессов в нотации eepc

При изучении бизнес-процессов предприятия как правило требуется зафиксировать в документальном виде описание бизнес-процесса. Как это сделать?

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

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

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

Оптимизированная нотация EPC-O описания бизнес-процессов

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

• eEPC:extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями.
• ARIS:Architecture of Integrated Information Systems.

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

Первоисточник – фундаментальный труд: Шеер. “Бизнес-процессы. Основные понятия. Теории. Методы”.

Элементарным кирпичиком нотации ARIS является функция бизнес-процесса и все сопряженные с ней элементы:

В этой статье рассмотрим “урезанное” подмножество eEPC ARIS, которое наиболее часто применяется для документирования бизнес-процессов (потоков работ work flow) на проектах автоматизации.

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

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

Например, “от начала выполнения техоперации прошло 10 мин” – это тоже событие.

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

Современные нотации описания бизнес-процессов

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

Далее, у каждой функции надо указать исполнителя:

Получаем последовательность состояний системы (результатов) и соответствующих действий пользователей. Но для описания процесса этого недостаточно.

Нужно добавить данные, которые перемещаются между функциями:

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

В вышеприведенной схеме исходящими данными из функции “Действие 1” является “Заказ клиента”, а результатом выполнения функции (завершающим событием) может быть “Заказ обработан отделом продаж”…

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

Некоторые нотации (например, нотация, принятая в 1С СППР) рассматривают только потоки работ, а на связях указываются наименования документов и результатов. Такая упрощенная модель с использованием элементов ARIS выглядела бы так:

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

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

Далее, использование логических операторов “И”, “ИЛИ”, “ИСКЛЮЧАЮЩЕ ИЛИ” позволяет указать ветвление потоков работ.

Оператор “И”

“И” – позволяет указать что после события запускаются сразу несколько функций:

либо указать, что событие (состояние) возникает только если выполнено несколько функций:

либо указать что только несколько событий (состояний) разрешают выполнение функции:

также, “И” позволяет указать что выполнение функции приводит одновременно к нескольким состоянием (событиям):

Оператор “ИЛИ”

“ИЛИ” – позволяет указать что возникновение одного из нескольких событий (состояний) – достаточно чтобы начать выполнение функции:

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

Оператор “Исключающее ИЛИ”

И наконец, “Исключающее или” отличается от просто “ИЛИ” тем, что возможен только один из альтернативных вариантов – либо Событие 1 либо Событие 2, но не оба одновременно. Это взаимоисключающие альтернативы: два взаимоисключающих события приводят к выполнению одной функции

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

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

Типичные ошибки

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

Перечислим наиболее распространенные ошибки моделирования в нотации eEPC ARIS.

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

• Два (или больше) входа в одну функцию. Например, при кольцевом выполнении функций:

Источник: xn--h1aoch.xn--p1ai

Business Studio, нотация eEPC: границы процессов, события, стрелки

В статье рассматриваются практические аспекты определения границ процессов при моделировании в среде Business Studio в нотации eEPC. Статья адресована сотрудникам компаний, осваивающим моделирование процессов с использованием Business Studio 4.0. Статья № 2 из серии статей.

Введение

В данной статье мы рассмотрим некоторые практические важные аспекты описания процессов в нотации eEPC в среде моделирования Business Studio 4.0.

Методология ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем) является одной из современных методологий описания процессов. Она была разработанная немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная система, описание которой строится из четырех основных групп моделей: моделей организационной структуры, моделей функций, моделей данных и объединяющих эти три группы, — моделей . К числу наиболее практически важных, относится основная нотация архитектуры ARIS — нотация eEPC, что означает «расширенная цепочка процесса, управляемого событиями».

Нотацию eEPC поддерживают многие современные программные продукты, предназначенные для описания , в том числе Business Studio 4.0.

Нотация eEPC в Business Studio

Входы/выходы процесса

Посмотрим, каким образом визуально можно показать границы процесса в нотации eEPCсреды моделирования BusinessStudio. На рис. 1 показан пример процесса, который мы разбирали в первой статье серии (там была представлена его схема в нотации «Процедура»). Границы процесса в нотации eEPC можно показать при помощи:

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

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

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

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

Рис. 1. Схема процесса в нотации eEPC

В левом верхнем углу схемы, представленной на рис. 1, показана внешняя ссылка «Клиент» (маленький квадрат), из которой выходит стрелка, привязанная к бумажному документу «Запрос от клиента» (Вариант, А). Строго говоря, в нотации eEPC нет такого объекта, как «внешняя ссылка». Это элемент системы Business Studio. Возможность и целесообразность использования внешних ссылок на схемах в нотации eEPC должна обсуждаться на методическом совете компании при разработке внутреннего Стандарта описания процессов с использованием Business Studio.

Вариант «Б» — показать, что «Запрос от клиента» поступает от объекта справочника «Субъекты» под названием «Клиент» (в справочнике мы создали объект с типом «внешний субъект»). Такой вариант моделирования так же поддерживается Business Studio, но не предполагается в нотации eEPC (он возможен на диаграммах другого типа в методологии ARIS). Хотя для неискушенного пользователя рассматриваемый вариант выглядит вполне естественно, но использовать его при моделировании не рекомендуется последующих проблем с формированием отчетов.

Пользователям нотации eEPC в Business Studio рекомендуется запомнить простой принцип: «обмен документами возможен только между процессами», на схемах процессов обмен документами между субъектами моделировать нельзя (если только не использовать специальную нотацию, где, наоборот, это как раз требуется).

Обратите внимание на такой важный объект схемы, как интерфейс процесса. На рис. 1 из такого объекта под названием «Управление ценообразованием» выходит документ « на товар», который является входом операции «Выполнить анализ запроса». Такое представление означает, что процесс «Управление ценообразованием» является поставщиком информационного входа (документа) для рассматриваемого нами процесса. Если выделить интерфейс процесса на схеме мышкой и нажать стрелку «вниз» на панели инструментов, то в Business Studio произойдет переход на соответствующую схему процесса.

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

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

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

Итак, при формировании схемы процесса в нотации eEPC в Business Studio можно пользоваться рядом объектов и функциональными возможностями, которые не были изначально сформулированы в оригинальной нотации eEPC. С одной стороны это повышает гибкость моделирования, с другой — возникает риск некорректного использования нотации. Например, формирование схемы коммуникаций вместо событийно управляемой цепочки процесса, как показано на рис. 2. Читателю предлагается самому найти ошибки в этой схеме.

Рис. 2. Некорректное использование объектов нотации eEPC

Использование событий

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

На рис. 3 представлен пример некорректной обратной связи. В «Операцию, А» входят две стрелки предшествования и выходит одна. С точки зрения нотации eEPC это методически некорректно. Справа на рис.

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

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

Но при комплексной, систематической работе по созданию база знаний компании в области , такой подход категорически неприемлем. Есть риск разработки нестандартных схем низкого качества.

В среде моделирования Business Studio события хранятся в специальном справочнике событий. При моделировании процесса можно использовать события из этого справочника. На рис. 4 показано, как можно выбрать событие. Например, при моделировании процесса, представленного на рис. 1, было выбрано событие «Поступил запрос от клиента», которое уже содержалось в справочнике.

Мы создали его при описании процесса в нотации «Процедура» в той же базе данных Business Studio.

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

Рис. 4. Использование события из справочника при формировании схемы процесса в нотации eEPC

На рис. 5 представлена еще одна весьма удобная функциональная возможность Business Studio, которая часто используется при описании процессов в нотации eEPC. При декомпозиции процессов возможен перенос так называемого «окружения» процесса на нижестоящий уровень. Переносятся такие объекты, как: события, логические операторы, стрелки, исполнители, документы.

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

Рис. 5. Перенос «окружения» операции процесса при декомпозиции

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

Рис. 6 поясняет, как используются события и потоки ресурсов, представленные на схеме в нотации eEPC, при формировании регламентирующих документов в среде Business Studio.

Рис. 6. Использование событий при формировании регламента процесса

Событие «А» является завершающим для «Процесса 1» и одновременно инициирующим для «Процесса 2». Документ «А» является исходящим для «Процесса 1» и одновременно входящим для «Процесса 2». Наименования события и документа попадают в соответствующие столбцы таблицы, представленной в регламенте выполнения .

Резюме

Подводя итоги, отметим, что eEPC — это одна из наиболее продуманных и удобных для моделирования нотация. На мой взгляд, она более строгая и логичная, чем «Процедура».

Функциональные возможности Business Studio делают моделирование более удобным, чем в оригинальной нотации eEPC, расширяют возможности для создания более информативных схем. Однако использовать их нужно аккуратно, предварительно продумав и зафиксировав во внутреннем Стандарте описания .

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

Источник: www.businessstudio.ru

XV Международная студенческая научная конференция Студенческий научный форум — 2023

Моделирование бизнес-процесса выполнения заказа продукции непрерывного производства с помощью диаграммы еEPC

Кочеткова О.В. 1 , Заборская И.А. 1
1 ФГБОУ ВО «ВолГАУ»
Работа в формате PDF

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

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

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

Какие преимущества имеет нотация eEPC [2]:

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

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

eEPC содержит элементы логики. Это позволяет строить схемы с условиями, что необходимо для описания деятельности («если договор согласован, то …, иначе …»).

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

Конечно, нотация имеет недостатки. Но рациональное использование сводит их к минимуму.

Как уже было упомянуто выше, в дословном переводе аббревиатуры eEPC кроется понятие некоторого события. На этом важном моменте строится весь принцип построения схемы. Существует два ключевых понятия: «Событие» (« Event ») и «Действие» (« Activity »). Когда кто-то первый раз попытается описать свой процесс в виде диаграммы eEPC, часто возникает вопрос об отличии от « Event » от « Activity ». Событие – это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения действия/операции, и исполнение действия всегда заканчивается событием.

Для того, чтобы схема была более наглядной, нотация предусматривает еще несколько стандартных элементов [3]:

должность (исполнитель). Тот, кто выполняет данную функцию;

информация. Любая информация, используемая для выполнения функции, кроме документальной. Например, телефонный звонок, инструкция по выполнению операции т.п.;

документ. Элемент «Документ» предназначен для отображения носителей информации (бумажной или электронной). Т.е. представление информации в определенной структуре;

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

Также нотации eEPC включают в себя возможность более детального рассмотрения процессов с помощью логических операций [4]:

И. Когда произойдут два или более события одновременно;

ИЛИ. Когда могут произойти одно ли несколько событий, но как минимум одно должно произойти обязательно;

ИСКЛЮЧАЮЩЕЕ ИЛИ. Либо одно, либо другое. Т.е. два варианта одновременно невозможны.

Таким образом мы имеем возможность рассмотреть на примере разработанную диаграмму eEPC , представленную на рисунке 1, объектом для которой послужил бизнес-процесс выполнения заказа продукции непрерывного производства.

Бизнес-процесс относится к непрерывному производству, которое планируется методом непрерывного планирования [7]. При такой организации производства после получения заказа клиента определяется возможность его выполнения и цех, исполнитель заказа. Полученный заказ ставится в очередь на его исполнение и исполнение заказа планируется.

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

Рисунок 1 – Диаграмма eEPC бизнес-процесса выполнения заказа продукции непрерывного производства (начало)

Рисунок 1 — Диаграмма eEPC бизнес-процесса выполнения заказа продукции непрерывного производства(окончание)

Список используемых источников:

Моделирование бизнеса — IDEF , UML , ARIS // Business Analysis – База знаний по бизнес-анализу [сайт]
URL : https://analytics.infozone.pro/business-modeling-idef-uml-aris/#_ARIS

01.2022) [сайт]
URL : https://habr.com/ru/post/645425/

01.2012) [сайт]
URL : https://habr.com/ru/post/137086/

Нотация описание бизнес-процессов ARIS e EPC. 07.2016) [сайт]
URL : https :// itrp . ru / questions / notatsiya — opisaniya — biznes — protsessov — aris — eepc /

Кочеткова О.В. — Лекция №4 «Арис» (Дата обращения 31.10.2022)

Источник: scienceforum.ru