Epc моделирование. EPC и EPC-M контракты — что это такое и их стандарты. Алгоритм построения диаграммы EPC

«Воздушные змеи, жмурки и салки
Прятки, мячи, чехарда, и скакалки,
И просто, и просто, и просто скакалки,
Ну просто, просто, просто скакалки!!!»

А.Вратарёв

При подготовке этой статьи я обнаружила невероятный факт: о нотации 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 всё ближе и ближе.

(4,14 - оценили 21 чел.)

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

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

Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.

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

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

На диаграмме не должны присутствовать объекты без единой связи. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор ветвления – только одной входящей связью и хотя бы двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями. Если оператор обладает входящей связью от элемента «событие», то он должен обладать исходящей связью к элементу «функция» и наоборот. За одиночным событием не должны следовать операторы «OR (ИЛИ)» или «XOR (Исключающее ИЛИ)». Операторы могут объединять или разветвлять только функции или только события.

Рис. 2.62 Пример диаграммы процесса в нотации EPC

Пример недопустимой ситуации.

Рис. 2.65 Пример недопустимой ситуации

Статистические методы управления процессами

Приведены примеры наиболее востребованных методов статистического анализа и предложен механизм их оценки.

Анализ диаграммы Парето

На промышленных предприятиях постоянно возникают всевозможные проблемы: появление брака, неполадки оборудования и т.д. В большинстве случаев подавляющее число дефектов и связанные сними потери возникают из-за относительно небольшого числа причин, при чем доля материальных затрат составляет порядка 70 – 80%. Чтобы выяснить, какие из этих причин или факторов являются основными, строят диаграмму Парето.

Диаграмма Парето – инструмент, позволяющий объективно представить и выявить основные причины, влияющие на исследуемую проблему. Различают два вида диаграмм Парето: по результатам деятельности и по причинам.

Диаграмма по результатам деятельности предназначена для выявления главной проблемы и отражает следующие нежелательные результаты деятельности:

· Себестоимость: объем потерь, затраты;

· Безопасность: несчастные случаи, аварии;

· Сроки поставок: срыв сроков, нехватка запасов.

Диаграмма Парето по причинам отражает причины проблем, возникающих в ходе производства:

· Исполнитель работы: смена, бригада и т.д.;

· Оборудование: станки, агрегаты, инструменты и т.д.;

· Методы работы: последовательность операций, условия производства;

· Измерения: точность, воспроизводимость, стабильность.

Построение диаграммы Парето состоит из следующих этапов.

Этап 1. Определите, какие проблемы необходимо исследовать и как собирать данные; как их классифицировать. Установите метод и период сбора данных.

Этап 2. Разработайте контрольный листок для регистрации данных с перечнем видов собираемой информации.

Этап 3. Заполните листок регистрации данных и подсчитайте итоги.

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

Таблица 3.1.1 Построение диаграммы Парето

Этап 5. Начертите одну горизонтальную и две вертикальные оси. Вертикальные оси: на левую ось нанесите шкалу с интервалом от 0 до числа, соответствующего общему итогу; на правую ось – шкалу с интервалом от 0 до 100 %. Горизонтальную ось разделите на число контролируемых признаков.

Рис. 3.1.1 Диаграмма Парето

Этап 6. Постройте столбчатый график, где каждому виду брака соответствует свой прямоугольник.

Этап 7. Начертите кумулятивную прямую.

При построении диаграммы следует обратить внимание на следующие моменты:

· Диаграмма оказывается наиболее эффективной, если число факторов составляет 7 – 10;

· При обработке данных необходимо производить их расслоение по отдельным параметрам (время отбора данных, тип изделий, партия материалов, оператор и т.д.);

· Если фактор “прочие” оказывается слишком большим, следует повторить анализ содержания этого фактора;

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

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «СТАНКИН»

ЛАБОРАТОРНЫЕ РАБОТЫ
ПО
ДИСЦИПЛИНЕ «ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА CALS-ТЕХНОЛОГИЙ»

Москва 2009 г.

ЛАБОРАТОРНАЯ РАБОТА №1

Цель работы: Формирование навыков разработки модели бизнес-процесса с использованием EPC-диаграммы.

Задачи работы:

1. Изучение правил построения EPC-диаграммы;

2. Разработка EPC-диаграммы бизнес-процесса в соответствии с заданием.

Правила построения EPC-диаграммы

Объекты диаграммы:

Отношения объектов диаграммы:

1. Для построения диаграммы событийно-управляемого процесса используются объекты, указанные в разделе «Объекты» и связи между ними, указанные в разделе «Отношения объектов».

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

Рис. 1. Функционально-событийная последовательность бизнес-процесса

1. Все функции должны идти в правильной последовательность. Необходимо учитывать параллельны они или последовательны.
2. События и функции должны иметь только по одному входящему и одному исходящему отношению, показывающему ход выполнения бизнес-процесса.

В случае если есть разветвления, то необходимо использовать оператор ветвления , при этом показывать все возможные варианты течения процесса и результаты выполнения функций. Разветвление всегда начинается после функции.
На eEPC - диаграмме допустимы следующие варианты использования правил ветвления/слияния:
1) Условное ветвление процесса с помощью оператора «исключающее ИЛИ» (при выполнении функции наступает только одно из возможных событий) (Рис.2).

Рис. 2. Разветвление с оператором «исключающее ИЛИ»

2) Условное ветвление процесса с помощью оператора «ИЛИ» (при выполнении функции наступают либо одно событие, либо другое, либо оба сразу) (Рис.3).

Рис. 3. Разветвление с оператором «ИЛИ»

3) Условное ветвление процесса с помощью оператора «И» (при выполнении функции наступают оба события) (Рис.4).

Рис. 4. Разветвление с оператором «И»

4)Функция выполнится, если наступили оба события (Рис.5).

Рис. 5. Соединение с оператором «И»

5) Функция выполнится, если наступило, либо одно событие, либо другое, но не оба сразу (Рис.6).

Рис. 6. Соединение с оператором «исключающее ИЛИ»

6) Функция выполнится, когда наступило хотя бы одно из событий (Рис.7).

Рис. 7. Соединение с оператором «ИЛИ»

1. На входе и выходе разветвления обязательно должны использоваться одинаковые операторы (Рис. 8).

Рис. 8. Использование операторов на входе и выходе

1. Определяются предшествующие и последующие процессы и отображаются в интерфейсах (рис.9). Если нет предшествующих и последующих процессов в рамках компании, то используется объект «Границы процесса» («Начало процесса», «Завершение процесса»).

Рис. 9. Функционально-событийная последовательность бизнес-процесса с интерфейсами, указанием границы процесса

1. Определяется и отображается вся необходимая информация и ресурсы, необходимые для выполнения функции, а также результаты выполнения функции. Необходимо максимально точно отображать входящую и исходящую информацию. Для таких документов таких как: Приказ, Служебная записка, Заявление и т.д., необходимо указывать их назначение. Информация, которая передается в устном виде, а также неструктурированная информация на любых носителях отображается информационным значком (рис.10).

Рис. 10. Функционально-событийная последовательность бизнес-процесса с интерфейсами, входящей и исходящей информацией

1. Определяется и отображается исполнитель каждой функции (рис.11).

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

1. Определяется возможность и необходимость декомпозиции функции. Если нужно, расписываются функции более детально на ЕРС диаграмме и делается ссылка на нее.

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

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

3. Рекомендуемое количество функций на диаграмме - не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.

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

5. События и операторы, окружавшие функцию на вышележащей диаграмме (Рис.16 ), должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции (Рис.17 ).

6. На диаграмме не должны присутствовать объекты без единой связи.

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

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

9. За одиночным событием не должны следовать операторы "OR (ИЛИ)" или "XOR (Исключающее ИЛИ)".

10. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.

11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления "И", оператор объединения - "ИЛИ".

Примеры допустимых ситуаций (Рис.18 , Рис.19 , Рис.20 , Рис.21 ):

Рисунок 18	Рисунок 19	Рисунок 20	Рисунок 21

Пример недопустимой ситуации (Рис.22 ).

«Чем нагляднее передана информация, тем быстрее и точнее ее воспримет тот, кому она адресована». Эту истину давно и активно используют маркетологи, педагоги и исследователи. Не остались в стороне и менеджеры. В этой статье рассмотрена нотация EPC как один их наиболее популярных современных методов, который позволяет сделать описание сложной работы не только удобным, но и гораздо более точным и понятным всем участникам проекта или процесса.

История возникновения графических стандартов моделирования

Сейчас, когда темпы развития всех процессов в обществе растут и системы усложняются, управление как искусство воздействия на людей вынуждено приобретать еще и способности к системному управлению, схожему с управлением инженерными системами. В начале 90-х годов прошлого века в бизнес-лексикон вошло слово «реинжинирингМайкл Хаммер и Джеймс Чампи впервые ввели это определение в своей книге «Реинжиниринг корпорации» ». А вслед за ним появилось и понятие «инжиниринг» бизнеса. Если первое – это перепроектирование бизнес-процессов, то второе – проектирование эффективной организационной системы с нуля.

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

Социально-экономическая система, коей является организация, гораздо более разнообразна, чем естественные науки, и единой формы записи «аксиом», управленческих формул так пока и не найдено. Но дорожка проложена. А начинается она со всем нам известных блок-схем, которые позволяют описать порядок действий для достижения заданного результата. Но, к сожалению, изобразительные возможности блок-схемы очень ограниченны, и она не позволяет отобразить всего многообразия элементов процесса управления бизнесом.

На сегодня вариантов блок-схем, с помощью которых можно изобразить взаимодействие людей и систем в процессе созидательной деятельности, разработано достаточно много. Они объединены в комплексы инструментов для того, чтобы более полно описать все аспекты деятельности предприятия. Такие инструментальные средства называют методологиями моделирования. Наиболее полными и известными являются три из них:

• ARIS (Architecture of Integrated Information Systems);
• SADT (Structured Analysis and Design Technique);
• UML (Unified Modeling Language).

(нажмите для увеличения)

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

Особенности нотации EPC

Нотация моделирования EPC (Event-driven Process Chain) ориентирована на построение алгоритмов взаимодействия в процессе выполнения конкретной работы. Её главными элементами являются:

• события, которые запускают или завершают работу;
• действия (работа), которая переводит систему из одного состояния в другое;
• исполнители работы;
• ресурсы и результаты работы (входы и выходы).

Эта нотация является составной частью методологии ARIS, автор Вильгельм-Август Шеер, разработана в начале 1990-х гг. В конце предыдущего раздела на рисунке продемонстрирован общий вид процесса стандартизации работы с использованием нотации EPC. Рассмотрим особенности описания бизнес-процессов организации с помощью этой нотации. Даже не вникая в суть схемы, сразу бросается в глаза чередование красных и зелёных элементов – это и есть цепочка событий и процессов, заложенная в названии нотации. Состав элементов модели определяется четырьмя основными позициями.

Вполне вероятно, что в ходе описания модели процесса мы соберемся применить информационную систему. Тогда сможем её отобразить с помощью специальных трехуровневых наборов элементов (оранжевого цвета ).

1. ИС – информационная система.
2. Модуль ИС.
3. Функция ИС.

У баз данных традиционно есть свое изображение – в виде цилиндра. Хотя использование их без информационной системы и системы без базы данных на сегодня мне представляется невозможным. Для отображения логики переходов между функциями используются логические операторы, которые помогают конкретизировать условия выполнения параллельных работ или возникновения событий. Они показывают варианты слияния или ветвления как функций, так и событий. Логических операторов всего три: «И», «ИЛИ» и «Исключающее ИЛИ». В разных системах могут использоваться их разные графические обозначения.

Обозначение и использование логических операторов в нотации EPC

Алгоритм построения диаграммы EPC

Как мы видим, несомненным преимуществом данной нотации является интуитивно понятный набор элементов и правил построения диаграмм. Для создания диаграмм процессов рекомендуется использовать специальные программы для моделирования процессов. Для EPC это, в первую очередь, система ARIS. Но она дорогая и достаточно сложная, и для небольших периодических проектов по упорядочиванию деятельности подразделений не используется.

Простота и популярность нотации стимулировало создание других инструментов для рисования бизнес-процессов, в том числе в нотации EPC. Самым простым из них является Visio – один из шаблонов в нем так и называется – «Схема EPC». Наиболее полезным инструментом для меня является система Бизнес Студио. В ней, кроме возможности нарисовать процесс, можно автоматически сгенерировать документ (Регламент процесса) и рабочие инструкции для его участников, что заметно облегчает рутинную часть процесса разработки стандартов деятельности.

Цвета и обозначения вторичных элементов в разных программах могут немного отличаться, но общие правила всегда выдержаны. На представленном в первом разделе статьи примере нотации EPC отражен упрощенный алгоритм работы с данной нотацией. Давайте разберем его по шагам.

После выполнения всех шагов мы получаем детальный план выполнения процесса, понятный его исполнителям. А четко обозначенные события и результаты позволяют настроить точки контроля для всех значимых этапов процесса. И я вновь отсылаю вас к примеру визуальной модели, размещенной в начале статьи.

Преимущества и недостатки нотации EPC

Использование EPC помимо простоты и доступности имеет следующие преимущества.

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

В то же время эта нотация не стала единственной и неповторимой в силу следующих недостатков.

1. Необходимость придумывать события на каждые даже незначительные действия сильно усложняет схему.
2. Вероятны организационные разрывы из-за неудобного отслеживания назначений.
3. Качественное прописывание входов и выходов приводит к перегрузке схемы прямоугольниками, стрелками, которые начинают пересекаться и тем самым еще сильнее усложняют восприятие схемы.
4. При распараллеливании работ очень сложно отразить исполнителей. Если один человек выполнят группу функций, картинка усложняется стрелками. Если присутствуют несколько исполнителей или мы не хотим рисовать длинные стрелки, приходится дублировать «овальчики» с исполнителями. Все это очень скоро может привести к полной неразберихе на схеме.

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