17.Управленческая модель. EEpc (ерc) – описание процессов. Модели процедурного описания деятельности. Методика проектирования бизнес процессов.

Нотация eEPC расшифровывается следующим образом – extended Event Driven Process Chain, расширенное модельное описание цепочки процесса, управляемого событиями. Эта нотация в РФ в основном представлено в CASE-пакете ARIS. Другое похожее описание есть в пакете

MS Visio, где оно представлено в виде нотации ЕРС. Управленческая модель, созданная в нотации ARIS eEPC наглядно отражает поток операций, который протекает внутри процесса, а также

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

Для каждой функции внутри процесса определяются: конечные и начальные события, ответственный исполнитель, материальные и информационные потоки, сопровождающие операции процесса. Событие порождает выполнение функций/операций. Завершение выполнения их действий, в свою очередь, генерирует другое событие и так далее, пока система не придёт в

состояние, появление которого в рамках процесса считается конечным событием.

Основные правила при моделировании достаточно просты:

· во-первых, каждая функция инициируется событием и завершается так же событием,

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

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

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

разветвления в потоке процесса отображаются при помощи операторов:

· логическое И,

· логическое ИЛИ,

· логическое взаимоисключающее ИЛИ.

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

· Графические элементы процесса (события и функции) следует располагать сверху вниз.

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

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

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

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

включать следующую информацию:

1. Входы/поставщики процесса.

2. Ресурсы: персонал, информация, оборудование, производственная среда.

3. Выходы/потребители процесса.

4. Участие руководителя при управлении процессом.

5. Последовательность выполнения процесса (события, функции).

6. Контрольные точки для измерения результативности процесса.

7. Все этапы алгоритма управления процессом.

8. Возможные отклонения от нормального хода процесса.

9. Показатели результативности и эффективности процесса, продукции и данные о степени удовлетворенности клиентов.

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

11. События и функции по ходу выполнения процесса должны последовательно сменять друг друга, чередоваться.

12. Функции и события и должны иметь только одну входящую и одну выходящую связь в виде стрелки, показывающей направление последовательности выполнения процесса.

13. Путь процесса должен разделяется и объединяется с помощью правил логического ветвления/слияния.

14. Решения о дальнейшем ходе выполнения процесса принимаются функциями.

15. Функции, принимающие решения о ходе процесса, на выходе события всегда соединяются по правилу «И».

16. Правила должны показывать все возможные варианты течения процесса после решения выбора (функции).

17. События, следующие после логики выбора должны описывать все возможные результаты выбора.

18. Логика ветвления/слияния не может описываться одновременно несколькими входящими и исходящими соединениями.

19. Поле события не должен следовать оператор «исключающее ИЛИ» или «ИЛИ»;

Достоинствами еЕРС-модели являются:

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

2. Достоинством является тот факт, что, также как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от операции к операции. К тому же с использованием логических выражений есть возможность распараллеливать процесс, направляя его только по одной из альтернативных веток.

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

Недостатками являются:

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