Нотация ARIS EPC, используемая для моделирования бизнес-процессов в инструментарии ARIS, представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата.
Модель ARIS EPC предназначена для описания алгоритма выполнения бизнес-процесса в виде последовательности функций, управляемых событиями. В модели ARIS EPC главное внимание уделяется последовательности выполнения функций, а для описания условий в модели бизнес-процесса используются события и правила, которые могут описывать сложные алгоритмы выполнения бизнес-процесса.
Функции в модели ARIS EPC запускаются событиями, например, «Счет поступил на согласование», и событиями оканчиваются, например, «Счет согласован» или «Счет не согласован». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, событие между этими функциями может не рисоваться.
Модель бизнес-процесса нотации ARIS EPC обязательно начинается и заканчивается одним, или несколькими событиями или интерфейсами в другие модели бизнес-процессов. Для отражения интерфейсов используются специальные объекты «Интерфейс процесса» — тип объекта «Функция».
При создании модели ARIS EPC могут возникнуть ситуации, когда один и тот же документ является исходящим для одной функции и входящим для следующей. В этих случаях для улучшения эргономики модели допустимо использования одного представления документа с одной входящей связью (от функции, в которой он создается или корректируется) и одной исходящей связью (к функции, которой он используется).
Модель EPC не может быть несвязной, т.е. расположение на модели, одного объекта, не связанного с остальными, является ошибкой.
Расположение документов относительно функций как правило следующее, слева сверху – входящие, слева снизу – исходящие документы, исполнителей, как правило располагают справа от функции.
На модели ARIS EPC указывается следующая информация:
- выполняемые функции
- информационные ресурсы функций (входящие/исходящие документы)
- события
- интерфейсы процессов
- логические операторы
- исполнители (должности, бизнес-роли)
- информационные системы
ARIS EPC в интерфейсе ARIS 9.8.
Правила именования события в ARIS EPC
Имя события (Event) должно содержать существительное и описание изменения состояния в виде отглагольной формы. Пример: «Сделка исполнена».
Правила именования функции в ARIS EPC
Для наименования функции (Function) необходимо использовать ее реальное название. Имя должно состоять из двух частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым он выполняется. Наименование функции состоит из краткого наименования объекта, начинающегося с заглавной буквы, например, «Поиск контактов клиента».
Правила именования роли/должности в ARIS EPC
Наименование бизнес-роли (Person Type) должно соответствовать сути возлагаемых на исполнителя обязанностей. Как правило, наименование содержит фразу «Ответственный за …». Наименования должностей (Position) пишутся в соответствии со штатным расписанием.
Правила именования документов
Объект соответствует документу (Information Carrier) (в бумажном и/ или электронном виде). Для наименования документов (независимо от используемого символа) необходимо использовать их реальное название.
Правила именования информационных систем в ARIS EPC
Для наименования информационных систем (Application system type) следует использовать их устоявшиеся названия.
Правила именования интерфейса процесса
Интерфейс (Process interface) показывает ссылку на смежный процесс. Имя интерфейса процесса соответствует названию модели, которая описывает смежную часть бизнес-процесса. Интерфейс может использоваться для ссылок на модели бизнес-процесса, не входящие в описываемый бизнес-процесс.
Источник: koptelov.info
Правила моделирования процессов в нотации epc
Для декомпозиции бизнес-процесса необходимо в навигаторе выбрать в контекстном меню (правая кнопка мыши) данного процесса «Преобразовать в EPC».
На рис. 7.4. показан пример декомпозиции функции (нотация Event-Driven Process Chain).
Рис. 7.4. Диаграмма в нотации EPC
Работа с диаграммой нотации epc
Для добавления существующих элементов на диаграмму можно пользоваться механизмом Draghttps://studfile.net/preview/16467508/page:2/» target=»_blank»]studfile.net[/mask_link]
Нотация EPC — удобное и наглядное средство описания бизнес-процессов
Во время занятий в ВУЗе, по предмету «Визуальное иерархическое моделирование», нас кратко ознакомили с IDEF, BPMN и EPC нотациями. Особенно мне интересна была EPC, т.к. давно с ней хотел разобраться. И все оказалось не так уж и страшно.
Начнем с того, что EPC расшифровывается как Event-driven Process Chain или по русски говоря «событийная цепочка процессов». Очень емкое выражение, в котором каждое слово ключевое.
С данной нотацией лично я работал в программе ARIS Express, хотя также есть и облачные версии данной системы. Тем не менее, для обучения, ARIS Express более чем хватает.
Но одно дело уметь пользоваться программой, а другое — разобраться в самой нотации. И сразу хочу сказать, что EPC-диаграмма бизнес-процесса представляет собой непрерывный поток (workflow), который начинается и заканчивается каким-либо событием.
Основные элементы EPC нотации
Английское название каждого элемента прекрасно отражает его назначение:
- «Event» — обозначает само событие;
- «Activity» — бизнес-функция, т.е. мы производим какую-то работу и тем самым прогоняем поток бизнес-процессов дальше;
- «Organizational Unit» — этот элемент подразумевает под собой организационную единицу, т.е. отдел, департамент и пр. ;
- «Role» — просто бизнес-роль;
- «Person» — в отличие от бизнес-роли, этот объект представляет конкретную персону;
- «Location» — представляет определенное местоположение;
- «Document» -это может быть как бумажный, так и электронный носитель информации, будь то справка или USB-флешка;
- «IT System» — любая IT-система, будь то система электронного документооборота, CRM, ERP и пр.;
- «Entity» — различные сущности с помощью которых выполняется конкретная функция;
- «Database» — любое хранилище данных (базы данных, файловое хранилище и пр.), в т.ч. бумажные архивы;
- «Product»- продукт, получаемый в ходе выполнения функции;
- «Risk» — тут описывается вероятный риск;
- «Process Interface» — является коннектором к внешним процессам или функциям и используется для связи процессов между собой.
И конечно три логических коннектора-оператора:
- «AND» — логическое «И», т.е. все события должны быть исполнены;
- «OR» — логическое «ИЛИ», т.е. достаточно исполнения одного или нескольких событий;
- «XOR» — логическое «исключающее ИЛИ», т.е. исполнение только одного любого события.
Соответственно поведение этих логических операторов стоит отражать на ситуации, когда несколько потоков в них входит и один выходит или наоборот., один поток на входе и множество на выходе.
На каждую бизнес-функцию мы может выполнить декомпозицию, которая будет отражена в отдельной диаграмме и связана ссылкой с родительской функцией.
Пример EPC-диаграммы с декомпозицией
Приведу пример диаграммы, которую я кстати делал на экзамене. Сразу уточню, что диаграммы не претендуют на точность и безошибочность исполнения и приведены в качестве учебного примера.
И соответственно сразу приведу пример декомпозиции функции «Проверка состояния квартиры клиента»:
По итогу хочу сказать, что как и BPMN (с которым тоже недавно ознакомился и думаю надо привести описание, на примере Bizagi Modeler), EPC является общепринятым форматом, который очень удобно применять при описании бизнес-процессов. А т.к. в схеме активно применяются логические коннекторы (AND, OR, XOR), то неудивительно, почему EPC получила особую популярность в IT-среде.
Источник: olegbarabanov.ru
