Наверх

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

Время чтения: 6 минут
6
Глава 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-диаграммами, я, как уже упоминала ранее, была очень рада тому, насколько легко они читаются: каждый блок выделен формой и цветом, очень просто увидеть исполнителей, требующиеся материалы, выделить список возможных состояний системы, список выполняемых в ходе процесса функций. Это несомненно огромный плюс: у заказчика не возникнет сложностей при чтении схемы бизнес-процесса при внедрении СЭД, если она будет представлена именно в нотации EPC. Однако, возможно, заказчика собьёт с толку такое гигантское количество состояний, ведь по сути из-за них схема сильно разрастается. Даже в нашем примере: какие-то 4 функции породили целых 5 состояний (не считая начального). Порой и задумаешься: зачем их все указывать. Скажем, зачем нужно после согласования договора генеральным директором указывать отдельным блоком «Договор согласован», а после подписания - «Договор подписан», если дальше процесс всё равно остаётся линейным. Откровенно говоря, незачем, разве только что вы Капитан Очевидность.

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

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

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 6

Что за странность сравнивать нотацию eEPCи IDEF0? Это все равно, что спорить, что лучше увеличительное стекло или микроскоп! Все зависит от цели, ради которой инструмент используется.

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

Если уж очень хочется сравнить eEPCс чем ни будь, то для этой цели лучше всего сгодиться IDEF3 или BPMN.

По всему остальному даже писать нет желания, статья очень среднего уровня

Михаил Романов 18 октября 2010
Что за странность сравнивать нотацию eEPCи IDEF0?
А в чем, собственно проблема? Почему eEPC нельзя использовать для высокоуровневого описания процессов и наоборот что мешает с помошью IDEF0 описывать детальные бизнес-процессы?
По всему остальному даже писать нет желания, статья очень среднего уровня
А все-же что именно скрывается за небрежным "всем остальным"?
И кстати, очень хочется узнать относительно вашего эксперного виденья вопросов применимости eEPC. Про IDEF0 вы уже писали, она годится лишь для "процессов верхнего уровня" (кстати, автор вроде бы нигде и никак явно не позиционировал эти нотации, т.е. не обозначал "высоту уровня" ... )
А в чем, собственно проблема? Почему eEPC нельзя использовать для высокоуровневого описания процессов и наоборот что мешает с помошью IDEF0 описывать детальные бизнес-процессы?
eEPC и IDEF0 принадлежат к определенным методологиям в рамках, которых они собственно и используются.
eEPC является частью методологии ARIS, в котрой высокоуровневые процессы описывают используя модели VAD. IDEF0 принадлежит к группе стандартов IDEF где для описания workflow процессов используют IDEF3.
Главное все таки в том, что чем выше уровнеь процесса, тем меньше мы уделяем внимание мелочам и больше сосредатачиваем внимание на концептуальных вещах и наооборот.
К вопросу можно ли применять eEPC для описания процессов верхнего уровня - можно, только зачем? Для высокоуровневых процессах детали запрятаны глубоко в иерархии, эти процессы не запускаются и заканчиваться одним-десятью событиями их гораздо больше!

По поводу использования EDEF0 для описания алгоритмов, представьте, что Вам необходимо подготовить схему работы с поручениями по документу начиная с момента создания поручений заканчивая снятием документа с контроля. Верю, такую схему в IDEF0 Вы нарисуете только можно ли помощью этой схемы проследить всю логику процесса? Поймет ли Вас заказчик и разработчик без дополнительных и очень пространных разъяснений? Думаю, что нет. Так зачем использовать для этого EDEF0? может лучше eEPC или EDEF3?

Кстати, по поводу методологии, в Business Studio 3 прекрасно уживаются и EDEF0 и eEPC ;)  Причем EDEF0 используется для моделирования высокоуровневых процессов, а eEPC для воркфлоу.

Михаил Романов 19 октября 2010
eEPC и IDEF0 принадлежат к определенным методологиям в рамках, которых они собственно и используются
Да, это я понимаю. Однако, как показывает практика, та же IDEF0 легко применяется и как абсолютно самостоятельная нотация (т.е. не в рамках SADT), а IDEF3, почему-то, распространена крайне мало (впрочем, это только мое личное наблюдение, не более).
Кстати, может этот просто так совпало у вас в тексте, но по мне, ставить рядом "цепочкие прибавочной стоимости" (вы ведь их имели в виду под аббревиатурой VAD?) и IDEF0, котороми можно описать полноценный процесс как-то сомнительно...
К вопросу можно ли применять eEPC для описания процессов верхнего уровня - можно, только зачем? Для высокоуровневых процессах детали запрятаны глубоко в иерархии, эти процессы не запускаются и заканчиваться одним-десятью событиями их гораздо больше!
Ну за все процессы, конечно, не скажу, но большинство процессов, связанных с управлением документами (из тех, понятное дело, что попадались мне) имеют ограниченное и вполне осязаемое число выходов. Т.е. ничего принципиально страшного, в том, чтобы их описать сверху в виде eEPC я не вижу.
Кстати, сами представители IDS Sheer как-то демонстрировали процесс, полностью описанный с помощью eEPC. И диаграмма верхнего уровня была вполне простой и понятной... правда далее творился ад кромешный.
только можно ли помощью этой схемы проследить всю логику процесса? Поймет ли Вас заказчик и разработчик без дополнительных и очень пространных разъяснений? Думаю, что нет. Так зачем использовать для этого EDEF0? может лучше eEPC или EDEF3?
Так у меня и вопрос - чего не хватает IDEF0 для полноценного описания процессов?
Мне лично использовать IDEF0 на практике не приходилось, но коллеги из других компаний утверждали, что им нравится IDEF0 именно за то, что его легко читает заказчик (другое дело, что я не в давался в подробности какой сложности были эти диаграмы). Однако, с уверенностью могу сказать, что даже упомянутый ранее BPMN требует полноценный сопроводительной спецификации ибо его задача (в моем понимании) это все-таки общее описание процесса, без деталировки.
Кстати, по поводу методологии, в Business Studio 3 прекрасно уживаются и EDEF0 и eEPC ;) Причем EDEF0 используется для моделирования высокоуровневых процессов, а eEPC для воркфлоу.
Ну вот видите! :)
В общем, мне кажется Ольга выбрала вполне приемлемую стратегию знакомства с различными нотациями - потенциальными кандидатами для описания диаграмм процессов.
Как подсказывает мне мой опыт общения и с заказчиками и с разработчиками, им зачастую не хватает именно навыка понимания конкретной нотации - большее (т.е. полноценное следование ... или наоборот, не следование :) ) какой-дибо методологии, это удел "специально обученных аналитиков", коим конкретная нотация по-большому счету не особо уже и нужна. Скажу даже больше - им вообще зачастую не нужна никакая нотация :).
Так что не знаю как вы, Александр, а я с удовольствием буду ждать продолжения серии ... если конечно, автор найдет время и силы на продолжение.
Сложилось ощущение, что автор немного не понимает сути нотаций IDEF0 и eEPC. Как уже говорили выше, нотация IDEF0 используется для описания процессов верхнего уровня. В ней удобно показывать взаимодействия между процессами, но при этом она не отражает последовательности выполнения действий. Поэтому для меня немного дико звучит фраза:
в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно
Что касается нотации eEPC без привязки к системе бизнес-моделирования, то не вижу в ней никаких преимуществ по сравнению с обычной диаграммой в Visio. Никто не мешает в диаграмме FlowChart указывать исполнителей, а также использовать блок условного перехода. Дополнительное описание состояний («документ подписан», «клиент удовлетворён» и т.д.) считаю в данном случае лишним для среднестатистического пользователя. 
рисуйте хоть по 50 исполнителей (там это называется Mechanisms) к каждому блоку

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