Моделирование бизнес процессов в нотации epc. Правила построения EPC-диаграммы
Цель EPC - это планирование и описание потоков работ, нижнего (операционного) уровня, бизнес-процессов. Основные элементы для построения диаграмм выступают события и функции. Бизнес-процессы, в диаграмме EPC, изображаются как последовательности чередующихся событий и функций.
Область применения EPC
Диаграмма EPC является стандартизированной графической диаграммой для моделирования бизнес-процессов, применима для:
- Составления моделей и документирование бизнес процессов как есть (as is)
- Описание возможных усовершенствований существующих бизнес процессов как будет (to be)
- Выявление всех участников процесса
- Выявление всех информационных систем, ресурсов и документов участвующих в процессе
Чтобы лучше получить представление о диаграмме EPC советуем посетить ссылки:
Введение в EPC
Ссылка ведет на введение в EPC. Советуем посетить ссылку в первую очередь.Элементы и структура построения диаграмм EPC
Ссылка ведет на описание где представлены самые важные графические элементы диаграммы. Представление элементов и их использование отлично структурированно, Вам будет очень удобно ориентироваться.Примеры правил построения EPC диаграмм
Ссылка ведет на документ где описаны примеры построения диаграмм. P.S. В данном случае нас интересует только информация, представленная в четвертой главе с 86 страницы.
Прочие полезные материалы:
- Ссылка ведет на сборник учебных материалов по методологии ARIS.
Стандарт EPC
EPC (Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции. Нотация EPC была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS.
Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т. е., выполнение Функции создает некоторое событие (состояние). Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение. Для ветвления процесса используются операторы И, ИЛИ, исключающее ИЛИ.
EPC используется на низших уровнях описания бизнес-модели, когда стоит задача описать подробный ход выполнения бизнес-процесса. Функции EPC могут быть декомпозированы (разбиты на детальные бизнес-процессы только в нотации EPC).
К недостаткам EPC можно отнести то, что эта нотация обладает очень широким набором графических элементов, что может быть сложным для понимания, по сравнению с другими нотациями. Для разработки процессов в этой нотации и их чтения требуется предварительная подготовка сотрудников.
К преимуществам EPC относится возможность очень детально и точно описать выполнение бизнес-процесса, показать на диаграмме в графическом виде всех исполнителей, все используемые объекты. Также плюсом EPC-диаграмм является тот факт, что, как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от блока к блоку. К тому же, в отличие от всё той же IDEF0, появилась возможность распараллеливать процесс, направляя его только по одной из альтернативных веток (в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно). Достоинством также мне показалась возможность указать исполнителя по каждому этапу (читай: функции). Но, в IDEF0 исполнитель указан на каждом уровне декомпозиции единожды, и от его имени тянутся стрелки ко всем исполняемым им блокам. В EPC, чтобы подсчитать, какое количество действий выполняет исполнитель, нужно пробежаться по всем блокам действия и проверять, указан ли по нему нужный нам исполнитель.
Эта нотация оказалась очень привлекательной с позиций осуществления контроля выполнения процесса - каждая функция непременно переводит в систему в новое состояние, из чего следует, что после выполнения каждой функции систему можно проверить, действительно ли переход в нужное состояние был осуществлён.
В целом нотация EPC является признанной во всем мире как одна из лучших нотаций для построения бизнес-процессов и моделирования работы предприятия.
Выбор метода моделирования
Для моделирования необходимого бизнес-процесса была выбрана методология BPMN. Этот выбор обусловлен тем, что нотация BPMN позволяет наиболее точно отобразить логические процессы, происходящие при выполнении задач, требующих с высокой точностью описать последовательность действий, продемонстрировать взаимодействие сотрудников и клиента, а также позволяет показать временной разрыв между выполнением некоторых задач.
Ноты для бизнеса
Статья опубликована в журнале "Новости менеджмента" в январе 2012 года.Музыка нас связала
Тайною нашей сталаВсе эпиграфы к этой статье взяты из песни "Музыка нас связала" группы Мираж.
В классической музыке музыкант является инструментом в руках композитора и играет по нотам. В популярной музыке чаще всего музыканты пишут музыку сами, а искусство импровизации совсем не подразумевает нот. Правда, знаменитые импровизации ставши классическими затем перекладывают на ноты, и у них появляется новая жизнь: меняется аранжировка, добавляется новое звучание и настроение.
Так и бизнес, который вырос как искусная импровизация для перехода на новый уровень требует переложение факта на бумагу, для анализа происходящего и принятия решений по совершенствованию.
Последнее время все чаще можно встретить описания бизнес-процессов (БП), сделанных, что называется, "своими силами" . Именно это обстоятельство побудило к написанию статьи. К сожалению большинство таких документов, которые случилось увидеть были мало пригодны для серьезного дела. Нельзя сказать, что они были принципиально неправильными, но ряд упущений настолько их портил, что об их существовании хотелось тут же забыть. Что же это за упущения, и как с ними бороться, мы разберемся по ходу этой статьи постепенно приближаясь к сути вопроса. Постараемся избежать большого количества технических деталей, но полностью от них уйти нельзя, т.к. предмет разговора того требует.
Неужели я сама
Не найду на все ответ
Эта статья адресована тем, кто хочет сэкономить на описании бизнес-процессов, поручив подготовку документа внутренним специалистам. Ведь описание бизнес-процессов вещь для фирмы не обязательная, и без него все работает. Но в любой стабильной компании существует механизм передачи полномочий, он называется "должностные инструкции". Если бизнес сложен, а должность ключевая, то должностные инструкции полезно нарисовать для облегчения восприятия. Аккумулирование бизнес-процессов в общем описании нужно, для того чтобы сделать бизнес более прозрачным, особенно для его продажи.
Документ "Описание БП" становиться особенно актуальным, как только появляется потребность реорганизации (или как сейчас модно говорить - реинжиниринга) компании. В этом случае документ используется чтобы:
- На нем как на карте сражений пометить суть запланированных преобразований,
- Ввести в курс дела участника преобразований,
- Ручкой а не на пальцах поставить задачу начальникам отделов и внешним специалистам.
В том, что документ готовиться своими силами, есть плюсы:
- Это выходит дешевле;
- Внутренний специалист, лучше разбирается в практиках родного бизнеса.
Стороннему консультанту, сначала предстоит изучить терминологию и ключевые особенности предмета, стандарты отрасли. На это уходит время. Правда он лучше знает как и что надо описывать. Есть же определенные правила, общепринятые нотации и специальный софт. Пример такой нотации можно посмотреть на рис. 1 и рис. 2.
Нотация IDEF0
Рис.1.Пример описания БП с помощью IDEF0
Рис.2.
Не читайте нам нотаций
Не читай нотаций мне
Мама, это ни к чему
А разве это нам нужно? - Спросит директор, резонно предполагая, что соблюдение всех стандартов заметно повысит стоимость результата. Один из знакомых директоров рассуждал так: "Приглашать стороннего специалиста - дело дорогое, а у нас задачи простые - зачем нам все эти нотации. А спец, бывает что то там нарисует своими крючками, ничего не понятно, признаться не удобно, так ему еще за это и платить надо".
Соглашусь, если задачи простые, чего городить огород. А если сложные, то надо упрощать, а не усложнять навороченной нотацией. Ведь, очевидных плюсов от использования красивых крючков нет. Если нет очевидных, это не значит, что нет ни каких. Эти правила и нотации придуманы не для того, чтобы консультант не скучал... Тот кто занимается бизнесом, хорошо знает, что не все полезное является очевидным. Что ж, поищем скрытый позитив и для этого заглянем в историю вопроса.
Рынок описания БП существует очень давно. Однако за последние полтора десятилетия он сделал стремительный рывок, благодаря появлению новой отрасли - автоматизации учета и управления на предприятиях. Растущий рынок дал шанс новичкам, придумавшим новые нотации пробиться и застолбить свое место. Например на российском рынке за несколько последних лет массированные рекламные и информационные акции со стороны IDS Scheer (главного поставщика ARIS - см. рис. 3) создали прослойку специалистов по описаниям автоматизируемых процессов.
Использование нотация ARIS требует большой детализации бизнес-процессов.
Рис.3.
Внедрение систем класса ERP (управления ресурсами), CRM (взаимоотношения с клиентами), MRP (планирования производства) неизбежно приводит к изменению процессов, и если это заранее не планировать, то результат может быть хуже, чем хочется. Кроме того автоматизация это работа с информацией, а значит полезно знать, какая информация кем генерируется, откуда и куда идет. Но специальные нотации для внедрения автоматизации, у нас так и не прижились и используются редко.
Описание бизнес-процессов в России веяние относительно недавнее, несмотря на внушительное количество ГОСТов в этой области (3.1109, 34, ИСО и др.). Сейчас, с качеством описания собственных бизнес-процессов лучше всего дела обстоят в банках. Дело в том, что в отличии от других коммерческих структур банк - это инфраструктурная организация и поэтому она находится в жестких рамках регламентов определенных законодательством. Банк работает по принципу управления операционным днем. В результате даже упрощенное описанные бизнес-процессов Банка (русским языком без использования нотаций) получается более детально проработанным, т.к. опирается на фундамент, построенный на томах регламентов предопределяющих стандарты, терминологию, роли и правила. Эти стандарты являются общепринятым языком в банковской среде и описание бизнес процессов будет легко читаемым для любого специалиста.
В коммерческих структурах описание бизнес процессов требует предварительного словаря терминов. И начиная его готовить и согласовывать многие сталкиваются с тем, что одни и те же вещи в разных отделах называются по разному. Вдаваясь в детали выясняется, что разные названия действительно несут в себе разные оттенки смысла. Согласование терминологии один из самых трудоемких процессов описания БП. Важно начать и запустить этот процесс. Большую часть работы могу взять собственные подразделения фирмы, ведь необходимость регламентировать свою деятельность приводит к большей организации процессов и процедур.
Когда описание требуется для автоматизации, возможна и обратная последовательность. Изменение бизнес-процессов делается параллельно внедрению информационной системы, а описание новых БП ведется "по горячим следам" и представляет из себя одно целое с документацией системы.
Нотный стан
Я забыла все, чему
Нас учили столько лет
Как ни странно, но выбор нотации и правильность описания более критична для малого и среднего бизнеса. Крупные компании обычно обладают большей эластичностью процессов из-за взаимозаменяемости сотрудников. Для малого бизнеса, где исполнение критических точек сводится к 2-3 принимающим решения людям - некорректное указание маршрута процесса может породить в корне неправильную концепцию решения. Раз критичен результат, значит важен и инструмент, но как его выбрать?
Каждая нотация приспособлена под определенный круг задач. Будем считать наиболее актуальной задачей изменение бизнес-процессов в рамках проекта автоматизации управления. Для этих целей есть хороший набор инструментов имеющий достаточное распространение: это и российские ГОСТы, и тот же ARIS, и IDEF, а так же EPC (рис.4 и рис.5).
Нотация EPC
Рис.4.
Описание бизнес-процесса с помощью EPC
Рис.5.
Если книга пишется на определенном языке, то самым важным является наличие читателя, который знает это язык и умеет его читать. Исходя из этого наилучшим является наиболее распространенный стандарт описания БП.
При выборе нотации так же важным критерием является так же возможность использования знакомого программного инструмента. Например, Microsoft Business Solution в 2002 году предлагал для информационной системы Navision нотацию On-Target, сопровожденную специальным программным решением. Это тот самый случай, когда лучше выбрать что то другое - мало того что, нотацию On-Target у нас ни кто не знает, так еще и программная среда потребует времени на ее изучение. Положительным же примером я бы назвал использование нотации IDEF, и программы Visio, весьма распространенной и обладающей, необходимым набором инструментов для рисования IDEF диаграмм (рис. 6).
Бизнес-процессы IDEF выполненные в Visio
Рис.6.
Конечно описание БП можно сделать и просто словами, а так же нарисовать различными симовлами (собственной придумки) так как это кажется понятным. Наличие такого описания это лучше чем ничего, но соблюдение стандартов все же полезно.
Полнота и глубина звучания
Что меня тянет сюда я не знаю
- займет много времени,
- часть деталей измениться в процессе создания документа.
Распространенной ошибкой является попытка подогнать описания под нотацию. Например, пытаться описать процедуры в формате ARIS, т.е. достигать очевидной избыточности в описании, когда это не требуется.
Но, более частой ошибкой является недостаточная глубина документа. В итоге, получается формальный документ не пригодный для работы, т.к. все важные детали приходится выяснять в процессе.
Мелодия - это последовательность звуков, а не нот
Позабудь об этом дне
Спор не нужен никому
Значит можно описать БП и просто словами, без всяких нотаций. С нотацией конечно правильней, однако важно не это. Описание БП это не конечный продукт, а только инструмент для новых свершений. Это значит, что он должен быть приспособлен к дальнейшему активному использованию. Главная проблема большинства документов из серии "сделай сам" заключается в неудобстве применения. Например, один такой документ состоял из описания сделанного в Microsoft Word и рисунков сделанных в PowerPoint, прыгать из программы в программу было ужасно неудобно, пришлось потратить большое количество времени, чтобы просто свести все это в один документ. Получается, что документ должен обладать следующими свойствами:
- Иметь четкий порядок и группировку разделов, т.е. быть концептуально целостным (обычно это значит, что если ты концепцию - значит ты научился им пользоваться);
- Четко выделять бизнес подразделения и давать им понятные названия и нумерацию;
- Четко выделять бизнес процессы и тоже давать им понятное название и нумерацию;
- Нумеровать элементы следует так, чтобы исключить путаницу (это заметно облегчает поиск): например, Отдел №1 должен иметь в документе номер Отд001, а Бизнес-процесс №1 должен иметь номер БП001;
- Документ должен иметь раздел содержание с древовидной структурой;
- Компания это целостный организм и ни какой бизнес-процесс не висит в воздухе - он всегда связан с другими БП, с бизнес единицами и отделами. Для отражения этих связей можно использовать гиперссылки - это облегчит поиск информации и переход от одного объекта к другому.
Для дела можно использовать любой текстовый редактор поддерживающий гиперссылки.
Некоторые считаю, что в профессиональной музыкальной группе достаточно иметь одного или двух настоящих музыкантов. Ни один искренний ценитель музыки с этим не согласится. Эти разговоры, возникают по причине недостатка в профессионалах и творческих личностях.
У бизнеса бывают похожие сложности. Хороших специалистов знающих свою компанию с ног до головы, немного, при этом они очень заняты. Анализируя бизнес-процессы своими силами, мы экономим деньги, и может быть, экономим время. Но отрывать лучших на описание БП не всегда возможно. Можно поручить рутину исполнителям рангом пониже, но тогда появляется риск затягивания процесса. Незнание принципов построения таких документов несет в себе риск безрезультатности (результат непригодный к употреблению, это все равно что его отсутствие).
Наилучшее качество и скорость при подготовке документа возможны в альянсе, ключевого специалиста и опытного консультанта. Результатом будет согласованный язык описания бизнес процессов (т.е. терминология бизнеса компании) и само описание в деталях достаточных для решения дальнейших задач.
Всем уговорам твержу я в ответ
Нас не разлучат, нетНапоминаем, что все эпиграфы к этой статье взяты из песни "Музыка нас связала" группы Мираж
Сторонний консультант напишет документ на языке нотаций понятной другим консультантам и часто, более приспособленной для дела. Вам не понятны все эти крючки? Но эти нотации совсем не сложны, может быть стоит их выучить?
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «СТАНКИН»
ЛАБОРАТОРНЫЕ РАБОТЫ
ПО
ДИСЦИПЛИНЕ «ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА CALS-ТЕХНОЛОГИЙ»
Москва 2009 г.
ЛАБОРАТОРНАЯ РАБОТА №1
Цель работы: Формирование навыков разработки модели бизнес-процесса с использованием EPC-диаграммы.
Задачи работы:
1. Изучение правил построения EPC-диаграммы;
2. Разработка EPC-диаграммы бизнес-процесса в соответствии с заданием.
Правила построения EPC-диаграммы
Объекты диаграммы:
| Объект | Описание |
| Функции представляют собой элементарные действия, направленные на осуществление бизнес-процесса | |
| Департамент или отдельное штатное подразделение, выполняющий функцию | |
| Должность (в т.ч. множественная) в организационной структуре, выполняющая функцию | |
| Информационные носители, как материальной формы (бумажные документы и т.д.), так и электронного представления информации: файлы, электронные письма, ресурсы Интернет и т.д. | |
| Товар или услуга, являющаяся результатом выполнения бизнес-функции или необходимые для выполнения функции | |
| Информационные потоки, обеспечивающие входные и выходные данные процесса | |
| Качественная или количественная ситуация (состояние), достижение которой важно для компании | |
| Нормативные документы |
Отношения объектов диаграммы:
|
1. Для построения диаграммы событийно-управляемого процесса используются объекты, указанные в разделе «Объекты» и связи между ними, указанные в разделе «Отношения объектов».
2. Диаграмма определяется последовательность действий и событий, необходимых для выполнения процесса. Каждая EPC-модель должна начинаться как минимум одним стартовым инициирующим событием (состоянием) и завершаться как минимум одним результирующим событием (состоянием). События и функции по ходу выполнения процесса должны чередоваться (сменять друг друга) (рис.1).
Рис. 1. Функционально-событийная последовательность бизнес-процесса
- Все функции должны идти в правильной последовательность. Необходимо учитывать параллельны они или последовательны.
- События и функции должны иметь только по одному входящему и одному исходящему отношению, показывающему ход выполнения бизнес-процесса.
В случае если есть разветвления, то необходимо использовать оператор ветвления , при этом показывать все возможные варианты течения процесса и результаты выполнения функций. Разветвление всегда начинается после функции.
На eEPC - диаграмме допустимы следующие варианты использования правил ветвления/слияния:
1) Условное ветвление процесса с помощью оператора «исключающее ИЛИ» (при выполнении функции наступает только одно из возможных событий) (Рис.2).
Рис. 2. Разветвление с оператором «исключающее ИЛИ»
2) Условное ветвление процесса с помощью оператора «ИЛИ» (при выполнении функции наступают либо одно событие, либо другое, либо оба сразу) (Рис.3).
Рис. 3. Разветвление с оператором «ИЛИ»
3) Условное ветвление процесса с помощью оператора «И» (при выполнении функции наступают оба события) (Рис.4).
Рис. 4. Разветвление с оператором «И»
4)Функция выполнится, если наступили оба события (Рис.5).
Рис. 5. Соединение с оператором «И»
5) Функция выполнится, если наступило, либо одно событие, либо другое, но не оба сразу (Рис.6).
Рис. 6. Соединение с оператором «исключающее ИЛИ»
6) Функция выполнится, когда наступило хотя бы одно из событий (Рис.7).
Рис. 7. Соединение с оператором «ИЛИ»
- На входе и выходе разветвления обязательно должны использоваться одинаковые операторы (Рис. 8).
Рис. 8. Использование операторов на входе и выходе
- Определяются предшествующие и последующие процессы и отображаются в интерфейсах (рис.9). Если нет предшествующих и последующих процессов в рамках компании, то используется объект «Границы процесса» («Начало процесса», «Завершение процесса»).
Рис. 9. Функционально-событийная последовательность бизнес-процесса с интерфейсами, указанием границы процесса
- Определяется и отображается вся необходимая информация и ресурсы, необходимые для выполнения функции, а также результаты выполнения функции. Необходимо максимально точно отображать входящую и исходящую информацию. Для таких документов таких как: Приказ, Служебная записка, Заявление и т.д., необходимо указывать их назначение. Информация, которая передается в устном виде, а также неструктурированная информация на любых носителях отображается информационным значком (рис.10).
Рис. 10. Функционально-событийная последовательность бизнес-процесса с интерфейсами, входящей и исходящей информацией
- Определяется и отображается исполнитель каждой функции (рис.11).
Рис. 11. Функционально-событийная последовательность бизнес-процесса с интерфейсами, входящей и исходящей информацией, регламентирующими документами и исполнителями
- Определяется возможность и необходимость декомпозиции функции. Если нужно, расписываются функции более детально на ЕРС диаграмме и делается ссылка на нее.
Нотация EPC (Event-Driven Process Chain – событийная цепочка процессов) используется для описания процессов нижнего уровня. Диаграмма, описанная в нотации EPC, представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотации EPC.
Используемые графические символы
| Символ | Изображение | Описание |
| Функция | Блок представляет собой функцию – действие или набор действий, выполняемых над исходным объектом (документом, материалом и проч.) с целью получения заданного результата. Внутри блока помещается наименование функции. Временная последовательность выполнения функций задается расположением функций на диаграмме процесса сверху вниз. | |
| Событие | Событие – состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Отображает события, активизирующие функции или порождаемые функциями. Внутри блока помещается наименование события. | |
| Стрелка |  | Стрелка отображает связи элементов диаграммы EPC между собой. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи. |
| Оператор AND («И») | 
Рис.18
Рис.19
Рис.20
Рис.21
| Оператор «И» используется для обозначения слияния/ разветвления как функций, так и событий. Если завершение выполнения функции должно инициировать одновременно несколько событий, то это обозначается с помощью оператора «И», следующего после функции и перед событиями. На рисунке (Рис.18) Рис.20завершение выполнения Функции одновременно инициирует события: Событие 1 и Событие 2. Если событие происходит только после обязательного завершения выполнения нескольких функций, то это обозначается с помощью оператора «И», следующего после функций и перед одиночным событием. На рисунке (Рис.19) Событие произойдет только после обязательного завершения Функции 1 и Функции 2. Если функция может начать выполняться только после того, как произойдут несколько событий, то это обозначается с помощью оператора «И», следующего после нескольких событий и перед функцией. На рисунке (Рис.20) Функция начнет выполняться только после того, как произойдут Событие 1 и Событие 2. Если одно событие может инициировать выполнение нескольких функций, то это обозначается с помощью оператора «И», следующего после события и перед функциями. На рисунке (Рис.21 ) Событие одновременно инициирует выполнение Функции 1 и Функции 2. |
| Оператор OR («ИЛИ») | 
Рис.22
Рис.23
Рис.24
| Оператор «ИЛИ» используется для обозначения слияния/ разветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «ИЛИ». Если завершение выполнения функции может инициировать одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями. На рисунке (Рис.22) Рис.20завершение выполнения Функции 1 может инициировать только Событие 1, только Событие 2, одновременно и Событие 1, и Событие 2. Если событие происходит после завершения выполнения одной или нескольких функций, то это обозначается с помощью оператора «ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.23) Событие может произойти либо после завершения выполнения Функции 1, либо после завершения Функции 2, либо после завершения выполнения и Функции 1, и Функции 2. Если функция может начать выполняться после того, как произойдет одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.24) Функция может начать выполняться либо после того, как произойдет Событие 1, либо после того, как произойдет Событие 2, либо после того, как произойдут и Событие 1, и Событие 2. |
| Оператор XOR («Исключающее ИЛИ») | 
Рис.25
Рис.26
Рис.27
| Оператор «Исключающее ИЛИ» используется для обозначения слияния/ разветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «Исключающее ИЛИ». Если завершение выполнения функции инициирует только одно из событий в зависимости от условия, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего за функцией и перед событиями. На рисунке (Рис.25) Функция инициирует либо только Событие 1 либо только Событие 2. Если событие происходит сразу после завершения выполнения либо одной функции, либо другой, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.26) Событие может произойти либо сразу после завершения выполнения Функции 1, либо сразу после завершения выполнения Функции 2. Если функция может начать выполняться после того, как произойдет либо только одно событие, либо только другое, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.27) Функция может начать выполняться сразу после того, как произойдет либо Событие 1, либо Событие 2. |
| Интерфейс процесса |  
Рис.28
Рис.29 Диаграмма Процесса 1
Рис.30 Диаграмма Процесса 2
| Элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или функцию. Используется для указания связи процессов между собой: - обозначает предыдущий или следующий процесс; - обозначает процесс, откуда поступил или куда передается объект. Внутри блока помещается наименование внешнего процесса. На рисунке (Рис.28 ) показано, что договор является результатом выполнения процесса «Заключение договоров». На рисунке (Рис.29 ) показано, что после окончания процесса «Процесс 1» (и наступления события «Событие 1») начинает выполняться «Процесс 2». На диаграмме «Процесс 2» (Рис.30 ) показано, что перед началом «Процесса 2» был завершен «Процесс 1», инициировавший «Событие 1». |
| Бумажный документ | Используется для отображения на диаграмме бумажных документов, сопровождающих выполнение функции. Внутри блока помещается наименование бумажного документа. | |
| Электронный документ | Используется для отображения на диаграмме электронных документов, сопровождающих выполнение функции. Внутри блока помещается наименование электронного документа. | |
| ТМЦ | Используется для отображения на диаграмме товарно-материальных ценностей (ТМЦ), сопровождающих выполнение функции. Внутри блока помещается наименование ТМЦ. | |
| Информация | Используется для отображения на диаграмме информационных потоков, сопровождающих выполнение функции. Внутри блока помещается наименование информационного потока. | |
| Информационная система |  | Используется для отображения на диаграмме информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование информационной системы. |
| Модуль информационной системы |  | Используется для отображения на диаграмме модуля информационной системы, поддерживающего выполнение функции. Внутри блока помещается наименование модуля информационной системы. |
| Функция информационной системы | Используется для отображения на диаграмме функции информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование функции информационной системы. | |
| База данных | Используется для отображения на диаграмме базы данных, сопровождающей выполнение функции. Внутри блока помещается наименование базы данных. | |
| Термин |  
Рис.31
| Используется для отображения на диаграмме терминов, сопровождающих выполнение функции. Внутри блока помещается наименование термина. Может быть также использован для обозначения статусов бумажных/электронных документов и других элементов справочника «Объекты деятельности». На рисунке (Рис.31) статус документа «Акт выполненных работ» устанавливается с помощью термина «Подписанный». |
| Набор объектов |  | Используется для отображения на диаграмме наборов объектов, сопровождающих выполнение функции. Внутри блока помещается наименование набора объектов. |
| Прочее | Используется для отображения на диаграмме потоков объектов, которые нельзя отнести ни к одной из предопределенных групп справочника «Объекты деятельности». Внутри блока помещается наименование прочего объекта. |
Команды панели инструментов для диаграммы EPC
Палитра элементов диаграммы EPC
Вертикальная палитра элементов, предназначенная для добавления элементов на диаграмму EPC, разделена на 3 части.
В верхней части палитры представлены элементы: Стрелка, Процесс, Событие и три типа операторов (И, ИЛИ, Исключающее ИЛИ). Добавление Процесса или События на диаграмму создает новый элемент в соответствующем справочнике.
Средняя часть палитры предназначена для добавления Сноски и Рамки на диаграмму.
Нижняя часть палитры предназначена для добавления на диаграмму элементов, уже существующих в подгруппах справочника «Объекты деятельности», справочниках «Процессы» и «Субъекты». При нажатии на любую кнопку нижней части палитры откроется окно соответствующего справочника, и будет предложено выбрать элемент, который необходимо добавить на диаграмму. Элементы вышеперечисленных классов могут быть также добавлены на диаграмму из Навигатора.
Типы связей, которые могут быть наведены между элементами на диаграмме EPC, перечислены в справочнике «Типы связей». Дополнительно к возможности показывать/убирать наименования типов связей на диаграмме с помощью кнопки в справочнике «Типы связей» существует возможность установить показ наименования того или иного типа связи на всех диаграммах, где эта связь установлена. Для этого необходимо проставить галочку у параметра «Видимость типа связи» для данной связи (Рис.32):
Рис.32 Управление показом наименования типа связи на всех диаграммах
Правила моделирования нотации EPC
1. Диаграмма функции EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).
2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями.
3. На диаграмме функции располагаются сверху вниз в соответствии с временной последовательностью их выполнения.
4. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций получается значительно выше, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
5. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.
6. События и операторы, окружавшие функцию на вышележащей диаграмме (Рис.33 ), должны быть начальными/ результирующими событиями и операторами на диаграмме декомпозиции функции (Рис.34 ). Стартовые события могут следовать за интерфейсами процесса, конечные события могут предшествовать интерфейсам процесса.
Рис.33 – Диаграмма процесса, на которой встречается Функция 1
Рис.34 – Диаграмма декомпозиции Функции 1
7. На диаграмме не должны присутствовать объекты без единой связи.
8. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор разветвления – только одной входящей связью и хотя бы двумя исходящими. Операторы не могут располагать одновременно несколькими входящими и исходящими связями.
9. Если оператор обладает входящей связью от элемента «событие», то он должен обладать исходящей связью к элементу «функция» и наоборот.
10. За одиночным событием не должны следовать операторы «OR (И)» и «XOR (ИЛИ)».
11. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ разветвление функции и события невозможно.
12. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор начала «И», оператор конца – «ИЛИ».
Примеры допустимых ситуаций (Рис.35 , Рис.36 , Рис.37 , Рис.38 ):
Рис.35
Рис.36
Рис.37
Рис.38
Пример недопустимой ситуации (
Загрузка...