В дословном переводе аббревиатуры eEPC кроется понятие событийности. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: «Событие» и «Функция». Когда кто-то первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то часто возникает вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Так вот: событие – это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием. Например. Звонит телефон. Менеджер взял трубку для телефонного разговора. В данном случае «Звонит телефон» — это событие. Телефонный разговор – это функция. Разговор завершен (повесил трубку) –снова событие. Таким образом, наблюдается событийная цепочка: Звонок – разговор – завершение звонка. А завершении звонка наверняка потребует выполнение новой функции: запись результата звонка и т.д.
Давайте попробуем это нарисовать. Для начала надо выяснить, как отображаются элементы «Событие» и «Функция».
Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. В выбранной нотации важную роль играют цвета. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, т.к. схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае (в нотации eEPC) так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше – сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. Кстати, иногда эту нотацию еще называют «ARIS», «ARIS EPC», что является не совсем верным, т.к. компания ARIS не изобретала эту нотацию, а сделала ее поддержку в своей программе моделирования бизнес-процессов. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой (т.е. отличаться лишь цветом), т.к. в черно-белом варианте это может вызвать путаницу. Существуют и другие правила, которые позволяют придать «стройность» диаграмме eEPC, мы будем о них говорить.
Итак, есть событие, есть функция. Как они связаны?
Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2. Если применительно к примеру с телефонным звонком, то будет так:
Связку событие – функция — событие принято отображать сверху вниз в одну линию либо слева направо. Направление цепочки указывается связывающими линиями со стрелками.
Для того, чтобы схема была более наглядной, нотация предусматривает еще несколько стандартных элементов:
- Должность (исполнитель). Тот, кто выполняет данную функцию
- Информация. Любая информация, используемая для выполнения функции, кроме документальной. Например, телефонный звонок, инструкция по выполнению операции т.п.
- Документ. Элемент «Документ» предназначен для отображения носителей информации (бумажной или электронной). Т.е. представление информации в определенной структуре.
- Программа (приложение). Программное обеспечение, используемое для выполнения функции.
Все остальные элементы являются вспомогательными, и практически не регламентированы требованиями самой eEPC. Однако, нет никаких препятствий для того, чтобы добавить свои собственные элементы. Главное, зафиксировать это во внутреннем стандарте, чтобы было единое понимание, как они выглядят и зачем применяются. Такое расширение не нарушает требований, если не нарушается связка событие-функция-событие, и предназначено лишь для улучшения восприятия информации или адаптации правил описания в какой-либо отраслевой специфике. Иногда может быть добавлен свой набор инструментов, пример которого представлен ниже.
Еще требуется выяснить, как рассмотренные элементы должны располагаться. Все эти элементы так или иначе должны быть связаны с функцией. Это общее правило: с событием не связывается ни один элемент, кроме функции. Т.е. все эти элементы должны быть связаны стрелочками с функцией. Что касается стрелок и их направлений: принято считать, что если нет направления передачи информации, то вместо стрелки отображается просто линия. Если информация входит (поступает на вход), то направление стрелки от объекта к функции, если выходит, то наоборот.
Еще пару слов о месте нахождения этих элементов на схеме и можно перерисовать нашу схему, уточнив выполнение функции обработки звонка. Жестких требований по расположению элементов нет, но принято их отображать на всех схемах одинаково (для однообразия и стройности схемы). Для унификации вешнего вида графических схем бизнес-процессов такие правила надо закрепить во внутреннем стандарте и следовать им. Чуть позже и приведу некоторые рекомендации по этому поводу.
Теперь перерисуем нашу схему:
Мы видим, что оператор выполняет обработку входящего звонка, действуя в соответствии с правилами обработки входящих звонков и использует для этого программу «CRM». Ни входящих, ни исходящих документов при этом не используется.
Как уже упоминалось, одной из сильных сторон нотации являются элементы логики. Одновременно это и один из самых сложных для понимания моментов. Поэтому, сначала приведем пример, а потом рассмотрим элементы логики.
Пусть в нашем примере будет так: в случае заинтересованности клиента дальнейшую работу с ним проводит менеджер по продажам и выставляет коммерческое предложение, которое отправляет по почте с использованием почтового клиента «MS Outlook». Если заинтересованности нет, то обработка звонка завершена. В реальной жизни хорошо бы использовать и правила завершения звонка, но это индивидуальные корпоративные тонкости. Вот что получится:
Элементы логики в схемах нотации eEPC
Элементы логики просты, но есть свои особенности и правила, чтобы схема была логичной и однозначно истолкована. Самое важное правило, которому нужно придерживаться на 100%: логические решения могут приниматься только при выполнении функц ии. Т.е. после некоторого события не может быть разветвления. Почему? Потому, что в этом случае это противоречит самому понятию события – оно простое и мгновенное, без времени выполнения. Например, если зазвонил телефон, и человек сидит думает, брать ему трубку или не брать, теоретически это уже будет функцией, где он принимает решение. А практически, в том числе из здравого смысла, он нарушает правила обработки звонков, т.к. ему зарплату платят за то, чтобы он эти звонки обрабатывал, и нечего тут рассуждать (в целом как нарисовано на схеме).
Всего различается 3 элемента логики:
- И. Когда произойдут два или более события одновременно;
- ИЛИ. Когда могут произойти одно ли несколько событий, но как минимум одно должно произойти обязательно;
- ИСКЛЮЧАЮЩЕЕ ИЛИ. Либо одно, либо другое. Т.е. два варианта одновременно невозможны.
Вот как одни выглядят:
Как видите, существует два варианта графического представления элементов логики. Они ничем не отличаются, совершенно альтернативные.
Теперь необходимо разобраться с применением элементов логики. Сначала рассмотрим встречающиеся варианты, затем перейдем к примеру. Разберем каждый элемент в отдельности.
Логический элемент «И».
Когда для выполнения функции требуется одновременное выполнение нескольких событий:
Пример: Если закрыт отчетный период (событие 1) и наступил срок подачи отчета руководителю (событие 2), сотрудник готовит ежемесячный отчет.
Соединение элементов, если при выполнении функции, возникает несколько событий:
Пример: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: взаиморасчеты сверены (событие 1), акт подписан (событие 2).
На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий.
Соединение элементов, если при выполнении нескольких функций, возникает событие:
Пример: Кладовщик собрал заказ (функция 1), оператор выписал документы (функция 2), товар готов к отгрузке (событие).
Соединение элементов, если возникновение одного события приводит к выполнению нескольких функций:
Пример: Поступила партия товара (событие). Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе.
Логический элемент «ИЛИ».
Соединение элементов, если одно из событий может вызвать выполнение функции:
Пример: Поступила заявка по телефону (событие 1) или поступление заявки по электронной почте (событие 2) приведет к необходимости ее обрабатывать.
Соединение элементов, если одна функция может вызвать как минимум одно событие:
Пример: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте (событие 1), по факсу (событие 2).
Соединение элементов, когда выполнение нескольких функций вызовет событие:
Пример: Оказана услуга (функция 1) или продан товар (функция 2), возникла задолженность у клиента (событие 1).
Логический элемент «ИСКЛЮЧАЮЩЕЕ ИЛИ».
Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий:
Пример: Клиент приехал в магазин лично (событие 1) или совершил заказ через интернет (событие 2). Необходимо выполнить отгрузку товара (функция 1).
Соединение элементов, если в результате выполнения функции происходит максимум одно из событий:
Пример: Решение либо принято либо нет.
Соединение элементов, если событие произойдет после того, как будет выполнена одна и только одна из функций.
Пример: Доставка товара осуществлена (событие 1) либо собственным транспортом (Функция 1), либо транспортной компанией (функция 2)
Корректное применение элементов логики требует определенной практики. Но это не сложно. Надо отметить, что не все рассмотренные комбинации широко применяются на практике (а вообще это определяется образом мышления аналитика).
Расширение нотации собственными элементами
Как уже говорилось, eEPC является не совсем нотацией, а именно правилами описания. И эти правила не запрещают добавлять собственные элементы на схему. Главное, чтобы эти элементы были понятными, и существовал документ, где такие расширения элеметов зафиксированы. Обычно используются следующие дополнительные элементы, которые возникали постепенно в процессе описания реальных процессов для различных задач, от простого описания для постановки задач для автоматизации.
Файл с данными. Используется, если в результате выполнения операции создается файл данных, или файл используется для выполнения операции.
База данных. Используется при описании информационных потоков между автоматизированными системами.
Картотека. Используется для отображения бумажной картотеки или архива.
Материальный поток. Используется для обозначения входящих и исходящих материальных потоков, а также ресурсов, потребляемых при выполнении процесса. Материальный поток отображается слева от сопровождающих его документов.
Кластер информации. Используется для обозначения структурированной информации (представление сущности). На диаграмме может применяться для обозначения документов, сформированных программным образом при использовании пользовательских приложений. В этом случае элемент «Кластер» располагается слева от соответствующего документа. Т.е. говорит о том, что пользователь не просто создал бумажный документ, но и создал его экземпляр в программе.