Правила и рекомендации построения EPC-диаграмм
Билет №49
Событийная цепочка процессов (EPC, event-drivenprocesschain) - тип диаграмм, используемых для моделирования, анализа и реорганизации бизнес-процессов (функционального моделирования). В тоже время EPC-диаграммы могут использоваться для моделирования поведения отдельных частей системы при реализации функций и служить заменой традиционных блок-схем (поведенческого моделирования).
EPC-метод был разработан Августом-Вильгельмом Шеером (August-WilhelmScheer) в рамках работ над созданием методологии ARIS (ArchitectureofIntegratedInformationSystems - Архитектура интегрированных информационных систем) в начале 1990-х годов.
Диаграмма процесса (функции) в нотации EPC представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и информационные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни.
Как и в случае с DFD, методология EPC «разрослась» интерпретациями, поддерживающими различные нотации (синтаксис и семантику элементов). К этому «приложили руку» как сам автор методологии, так и производители ПО, в котором реализована возможность моделирования бизнес-процессов посредством EPC (ARIS, MicrosoftVisio, BusinessStudio, Bflow). По аналогии с блок-схемами, символы (элементы) графической нотации можно сгруппировать по назначению. В следующей таблицы приведены символы EPC и их альтернативные изображения, наиболее часто встречающиеся в литературе и ПО.
|
|
|
Таблица 8.2. Условные обозначения на EPC-диаграммах
| № п/п | Символ | Наименование | Примечания | ||
| 1. СИМВОЛЫ ПРОЦЕССА | |||||
| 1.1 | 
| Событие (Event) | Факт (ситуация, набор условий или обстоятельств), который активирует или оказывает влияние на дальнейшее развитие одного или более процессов. Событие инициируют действия или являются их результатами. В отличие от функции, выполнение которой занимает определенный промежуток времени, событие относится к конкретной точке во времени. | ||
| 1.2 | 
| Функция, деятельность (Activity) | Действие или набор действий, выполняемых над объектом (документом, ТМЦ и т.п.) с целью получения заданного результата. | ||
| 1.3 | 
| Интерфейс процесса (ProcessInterface) | Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов: - обозначает предыдущий или следующий процесс по отношению к текущему процессу (диаграмме); - обозначает процесс, откуда поступил или куда передается объект. | ||
| 2. СИМВОЛЫ ОБЪЕКТОВ | |||||
| 2.1 | 
| ТМЦ, информация (Information, Entity) | Товарно-материальные ценности (ТМЦ) или информация, используемые или получаемые в результате действий. Может использоваться вместо элемента «Вход / Выход». | ||
| 2.2 | 
| Документ (Document) | Информация, представляемая не в компьютерном виде (на бумаге, пленках, слайдах). | ||
| 2.3 |  
| Файл, база данных (File, Database) | Информация, представляемая в компьютерном виде (файл, таблица, БД, электронный документ). | ||
| 2.4 | 
| Контекстные данные, кластер (Cluster) | Набор данных, необходимых для выполнения функции (модель, диаграмма, заказ). | ||
| 2.5 | 
| Набор объектов, картотека (CardFile) | Набор ТМЦ или документов. | ||
| 2.6 | 
| Сообщение (Message) | Требование отправителя к получателю на создание ТМЦ, предоставление информации или оказание услуги. | ||
| 2.7 | 
| Вход / Выход, продукт (Input / Output, Product | Объект, необходимый для выполнения процесса (план работ, заказ, материалы) или являющийся результатом процесса (документация, изделие, выполненная услуга). | ||
| 3. СИМВОЛЫ ИСПОЛНИТЕЛЕЙ
| |||||
| 3.1 | 
| Организационная единица (Organizationalunit) | Структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба). | ||
| 3.2 | 
| Должность, типисполнителя (Position, Role, Person type) | Должность исполнителя или роль субъекта, которому поручено выполнение действия. Составная часть организационной единицы. | ||
| 3.3 | 
| Исполнитель (Person) | Конкретный исполнитель, которому поручено выполнение действия (имя исполнителя). Экземпляр должности. | ||
| 3.4 | 
| Местоположение (Location) | Местоположение объекта, выполнения действия или возникновения события (фирма, организация, отдел, служба, завод, здание, комната, адрес). | ||
| 4. СИМВОЛЫ ПО
| |||||
| 4.1 |  
| Приложение, прикладная система (Application) | Информационная система (программный продукт), с помощью которой выполняется функция. | ||
| 4.2 | 
| Модуль (Module) | Составная часть информационной системы. | ||
| 5. СИМВОЛЫ ЛИНИЙ | |||||
| 5.1 | 
| Потокуправления (Control Flow Arrow) | Задает последовательность (до-после) возникновения событий и выполнения действий. | ||
| 5.2 | 
| Организационныйпоток (Organizational Flow Arrow) | Иерархическая связь между однотипными элементами (организационная единица – должность – персона). | ||
| 5.3 |
| Потокресурсов (Resources Flow Arrow) | Связь между действием и ресурсами, необходимыми для его выполнения (организационными единицами, персонами, приложениями, модулями и т.п.). | ||
| 5.4 | 
| Информационный поток (InformationFlowArrow) | Связывает действие и элемент, являющийся источником и/или приемником информации (приложение, кластер). | ||
| 5.5 | 
| Поток информационных услуг (InformationoutputFlowArrow) | Связь между действием и информационным входом/выходом. | ||
| 5.6 | 
| ПотокТМЦ (Material output Flow Arrow) | Связь между действием и материальным входом/выходом. | ||
| 6. ЛОГИЧЕСКИЕ СИМВОЛЫ
| |||||
| 6.1 |   
| Логическое «И» (AND) | Используется для обозначения слияния и/или ветвления параллельно выполняемых действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно только при завершении выполнения (наступления) всех предыдущих действий (событий). При ветвлении должны выполняться (наступать) все последующие действия (события). | ||
| 6.2 |   
| Логическое «ИЛИ» (OR) | Используется для обозначения слияния и/или ветвления параллельно выполняемых действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно при завершении выполнения (наступления) хотя бы одного из предыдущих действий (событий). При ветвлении должно выполняться (наступить) хотя бы одно из последующих действий (событий). | ||
| 6.3 |   
| Исключающее «ИЛИ» (XOR) | Используется для обозначения слияния и/или ветвления действий и событий. При слиянии выполнение (наступление) следующего действия (события) возможно при завершении выполнения (наступления) только одного из предыдущих действий (событий). При ветвлении должно быть выполнено (наступить) только одно из последующих действий (событий). | ||
| 7. СПЕЦИАЛЬНЫЕ (ДОПОЛНИТЕЛЬНЫЕ) СИМВОЛЫ | |||||
| 7.1 | 
| Цель (Objective) | Цель выполнения процесса (высокое качество, низкая себестоимость, сокращение издержек, увеличение прибыли). | ||
| 7.2 | 
| Термин (Term) | Используется: - для обозначения данных, передаваемых между процессами или обрабатываемых при выполнении процессов (Техническое задание, Форма № 1, Ведомость ЦДЛ №3, пин-код); - для обозначения статусов бумажных или электронных документов (подписанный, утвержденный). | ||
Следует отметить, что некоторые элементы нотации представлены одним и тем же графическим примитивом (информация и исполнитель, кластер и приложение), но различаются цветом фона.
Несмотря на отличия в синтаксисе и семантике, можно выделить основные элементы (ядро) методологии EPC, присутствующие и остающиеся неизменными в различных нотациях. К ним относятся: функция, событие, логические символы (правила) и поток управления. Остальные элементы при одинаковой семантике могут иметь различный внешний вид. В частности в последней версии программного продукта ARIS (версия 2.4) все дополнительные (документ, персона и т.д.) и новые (риск) элементы отображаются в виде прямоугольника со скругленными углами, но с различным цветом фона и иконкой в левом верхнем углу.
| 
| |
| а) организационная единица | б) информационная система |
Рис. 8.6. Условные обозначения элементов графической нотации EPC в ARIS
Правила и рекомендации построения EPC-диаграмм
Процесс моделирования процессов с помощью EPC подчиняется классическим принципам моделирования: декомпозиции и иерархического упорядочивания. Декомпозиция, с отображением на отдельных диаграммах, выполняется для функций, подобно работам на диаграммах IDEF0 или предопределенным процессам на блок-схемах.
Билет №50
1. Диаграмма функции EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).
2. События и функции по ходу выполнения процесса должны чередоваться.
3. Рекомендуемое количество функций на диаграмме - не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
4. События и функции должны содержать строго по одной входящей и одной исходящей связи (потоку управления), отражающей ход выполнения процесса.
5. На диаграмме не должны присутствовать элементы без единой связи. Исключение может составлять элемент «цель» всего процесса (диаграммы).
6. События и логические операторы, окружавшие функцию на вышележащей (родительской) диаграмме, должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции.
7. Каждый оператор слияния должен обладать минимум двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и минимум двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями.
8. Логические операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.
9. Логический оператор, разветвляющий ветви, и оператор, объединяющий эти ветви, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ».
Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке.
а) допустимые ситуации
| 
| 
| 
|
б) недопустимые ситуации
| 
|
Рис. 8.7. Примеры допустимого и недопустимого использования логических операторов
10. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.
Дата добавления: 2018-04-15; просмотров: 1211; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!