что такое epc нотация

Глава 3. Нотация EPС: весёлая, яркая, суперпростая

Глава 3. Нотация EPС: весёлая, яркая, суперпростая

«Воздушные змеи, жмурки и салки
Прятки, мячи, чехарда, и скакалки,
И просто, и просто, и просто скакалки,
Ну просто, просто, просто скакалки. »

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

А начну я с того, что нотация EPCбыла разработана в начале 1990-х гг. в ходе разработки методологии ARIS, как, скажем, процессная её составляющая. Отцом-основателем EPC считается профессор Вильгельм-Август Шеер, чьё имя одним только своим звучанием внушает обывателю благоговейный трепет (произнесите вслух и проникнитесь). Что уж говорить о названии факультета, на котором работал этот уважаемый дядечка: Institut für Wirtschaftsinformatik университета Universität des Saarlandes.

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

Название нотации расшифровывается как Event-driven Process Chain, что недвусмысленно указывает на то, что центральным элементом диаграмм нотации EPC являются события. События порождают выполнение неких действий некими участниками. Завершение выполнения действий, в свою очередь, генерирует другое событие и так далее, пока система не придёт в состояние, появление которого в рамках процесса считается конечным событием.

Для наглядной демонстрации возможностей нотации воспользуюсь житейским примером, навеянным недавно завершившимся отпуском в тёплых краях. Сотрудник рецепции уважаемого отеля Иво Петков получает запрос от одного из постояльцев на срочную замену умывальных принадлежностей в номере. Вполне понятно, что его задача – выполнить запрос клиента, а в терминах EPC – привести систему из состояния «Получен запрос от клиента на смену умывальных принадлежностей» в состояние «Запрос клиента удовлетворён».

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

Итак, возвращаемся к примеру. Сразу после получения запроса от клиента Иво должен отправить запрос на выполнение требования клиента горничной, чем привести систему в состояние «Запрос на выполнение отправлен». Горничная, пользуясь имеющимися на складе запасами, выполняет запрос Иво. И здесь впервые появляется распараллеливание нашего процесса: если горничная понимает, что необходимых умывальных принадлежностей (скажем, геля для душа) сейчас на складе нет, то она, сама, быть может, того не желая, переводит систему в состояние «Выполнение запроса невозможно», из чего само собой следует, что Иво придётся иметь не самый приятный разговор с клиентом, и то, в какое состояние дальше придёт система, зависит только от нрава клиента и его склонности к дракам. Если же на складе имеются все необходимые постояльцу принадлежности, то горничная успешно выполняет переданный ей запрос, сообщает о выполнении Иво, который в свою очередь сообщает об этом клиенту. И все живут долго и счастливо и умирают в один день.

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

Рис. 1. EPC-диаграмма процесса обработки запроса клиента в отеле

А теперь по традиции достоинства и недостатки нотации.

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

Плюсом EPC-диаграмм является тот факт, что, как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от блока к блоку. К тому же, в отличие от всё той же IDEF0, появилась возможность распараллеливать процесс, направляя его только по одной из альтернативных веток (в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно). Достоинством также мне показалась возможность указать исполнителя по каждому этапу (читай: функции).

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

Очень удобной показалась мне эта нотация с позиций осуществления контроля выполнения процесса: каждая функция непременно переводит в систему в новое состояние, из чего следует, что после выполнения каждой функции систему можно проверить, действительно ли переход в нужное состояние был осуществлён. Но тут же возник вопрос: а так ли это действительно нужно? У меня, например, такое желание появляется нечасто =)

Итак, в целом нотация EPC кажется мне для описания бизнес-процессов неудобной: слишком много внимания событиям, слишком мало внимания действиям и в особенности их группировке по признаку исполнителя или используемых материалов. Да, она простая, да, она красивая, и да, к сожалению, это всё, что я могу о ней сказать, как, наверное, и многие другие люди. =)

А статьи о нотациях UML и BPMN всё ближе и ближе.

Источник

Использование нотации eEPC для графического описания бизнес-процессов

Всякая вещь есть форма проявления беспредельного разнообразия.
Козьма Прутков

Введение в нотацию eEPC

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

Главный «стержень» нотации eEPC

Как я уже упоминал, в дословном переводе аббревиатуры eEPC кроется понятие событийности. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: «Событие» и «Функция». Когда кто-то первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то часто возникает вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Так вот: событие – это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием Поясню на примере. Звонит телефон. Менеджер взял трубку для телефонного разговора. В данном случае «Звонит телефон» — это событие. Телефонный разговор – это функция. Разговор завершен (повесил трубку) –снова событие. Таким образом, наблюдается событийная цепочка: Звонок – разговор – завершение звонка. А завершении звонка наверняка потребует выполнение новой функции: запись результата звонка и т.д.
Давайте попробуем это нарисовать. Для начала надо выяснить, как отображаются элементы «Событие» и «Функция».

Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. Думаю, надо сказать пару слов об используемых цветах. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, т.к. схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае (в нтации eEPC) так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше – сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. Почему они такие? Точно не уверен, но мне кажется от того, что компания ARIS, когда сделала в своем продукте поддержку нотации eEPC, дала им такие цвета, они и «прижились». Кстати, иногда эту нотацию еще называют «ARIS», «ARIS EPC», что является не совсем верным, т.к. компания ARIS не изобретала эту нотацию, а сделала ее поддержку в своей программе моделирования бизнес-процессов. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой (т.е. отличаться лишь цветом), т.к. в черно-белом варианте это может вызвать путаницу. Существуют и другие правила, которые позволяют придать «стройность» диаграмме eEPC, мы будем о них говорить.
Итак, есть событие, есть функция. Как они связаны?
Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2. Если применительно к примеру с телефонным звонком, то будет так:

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

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

Элементы логики в схемах нотации eEPC

Как видите, существует два варианта графического представления элементов логики. Они ничем не отличаются, совершенно альтернативные. Я привел их оба, т.к. на практике в различных источниках можно увидеть оба варианта. Какой из них использовать, решать Вам. Мне больше нравится первый.
Теперь необходимо разобраться с применением элементов логики. Сначала рассмотрим встречающиеся варианты, затем перейдем к примеру. Разберем каждый элемент в отдельности.
Логический элемент «И».

Когда для выполнения функции требуется одновременное выполнение нескольких событий:

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

Соединение элементов, если при выполнении функции, возникает несколько событий:

Пример: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: взаиморасчеты сверены (событие 1), акт подписан (событие 2).

На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий.

Соединение элементов, если при выполнении нескольких функций, возникает событие:

Пример: Кладовщик собрал заказ (функция 1), оператор выписал документы (функция 2), товар готов к отгрузке (событие).

Соединение элементов, если возникновение одного события приводит к выполнению нескольких функций:

Пример: Поступила партия товара (событие). Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе.

Логический элемент «ИЛИ».
Соединение элементов, если одно из событий может вызвать выполнение функции:

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

Пример: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте (событие 1), по факсу (событие 2).

Соединение элементов, когда выполнение нескольких функций вызовет событие:

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

Логический элемент «ИСКЛЮЧАЮЩЕЕ ИЛИ».

Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий:

Пример: Клиент приехал в магазин лично (событие 1) или совершил заказ через интернет (событие 2). Необходимо выполнить отгрузку товара (функция 1).

Соединение элементов, если в результате выполнения функции происходит максимум одно из событий:

Пример: Решение либо принято либо нет.

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

Пример: Доставка товара осуществлена (событие 1) либо собственным транспортом (Функция 1), либо транспортной компанией (функция 2)

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

Попробуйте применить элементы логики на практике. Если будут трудности, напишите мне, постараюсь помочь.

Расширение нотации собственными элементами

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

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

Соглашения о правилах размещения фигур на схеме

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

Я придерживаюсь (и рекомендую) следующих правил:

Идентификация элементов на диаграмме

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

Отображение обратной связи

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

Для отображения обратной связи по управлению используется принцип «прямого включения» в процесс дополнительной функции управления с последующим ветвлением (используется логический элемент «Исключающие ИЛИ»). Например:

Текстовое описание процессов

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

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

Источник

Как моделировать бизнес-процессы в нотации eEPC?

В ходе своей работы и преподавания я сталкиваюсь с описанием бизнес-процессов организации в нотации eEPC (Extended event driven process chain), которая принята стандартом де-факто для описания процедур и регламентов после обследования деятельности организации. К сожалению, используя эту нотацию очень просто допустить ошибки моделирования, не зная правил, по которым она составляется. Эти ошибки приводят в последующем к несоответствию логики процесса, и как следствие – непониманию реальной ситуации в организации. Эта статья является некоторым обобщением моего опыта моделирования бизнес-процессов, и надеюсь, послужит некоторым читателям полезным руководством.

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

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

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

Самыми распространенными ошибками являются использование оператора «ИЛИ» и «исключающего ИЛИ» после события, например:

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

либо добавление двух дополнительных состояний:

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

Самой распространенной ошибкой является неправильное использование обратной связи, например, как тут:

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

Источник