Бизнес процесс epc пример

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

Приведенные в статье примеры бизнес-процессов упрощены в ознакомительных и учебных целях и не могут быть внедрены в действующие системы управления бизнес-процессов без дополнительной детализации. Моделирование бизнес-процессов производится в рамках этапа описания процесса управления бизнес-процессами, результатом которого является модель. В качестве примера будет смоделирован бизнес-процесс «Управление проблемами» (Problem Management).

Описание бизнес-процесса

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

Начало бизнес-процесса

• Service Desk
• Система мониторинга

Выполнение бизнес-процесса

1. Информационная система с функционалом «Система принятия решений» собирает информацию о вновь зафиксированных проблемах, категоризует проблему, устанавливает приоритет и сохраняет её в информационной системе обработки проблем.
2. Администратор информационной системы обработки проблем назначает ответственного исполнителя заявки на устранение проблем
3. Ответственный исполнитель устраняет проблему и по окончанию фиксирует результат в заявке

Окончание бизнес-процесса

Результатом исполнения бизнес-процесса является фиксация результата решения проблемы

Пример бизнес-процесса в EPC

Бизнес-процесс смоделирован в EPC-совместимой нотации с помощью сервиса визуального моделирования bpsimulator.com. Чтение модели производится сверху вниз.

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

Пример бизнес-процесса в BPMN

Бизнес-процесс смоделирован в BPMN нотации с помощью сервиса моделирования бизнес-процессов bpmn.io. Чтение модели производится слева направо.

Модели бизнес-процессов в нотации BPMN легко имплементировать в существующие информационные системы управления потоком работ workflow tool. Этот стандарт описания бизнес-процессов активно развивается и расширяется.

Пример бизнес-процесса в IDEF

Бизнес-процесс смоделирован в IDEF нотации с помощью сервиса графического сервиса gliffy.com. Чтение модели производится слева направо.

По моделям в нотациях IDEF0, IDEF3 удобно анализировать процессы трансформации состояний объектов и субъектов бизнес-процессов. Так же этот стандарт удобен для анализа всех внешних воздействий на процесс, приводящих к тому или иному результату выполнения бизнес-процесса.

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

Источник: spark.ru

Глава 3. Нотация EPС: весёлая, яркая, суперпростая

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

Источник: ecm-journal.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Розовые фигуры – это события. Событие – это некоторое состояние, которое принимает система и определяет дальнейшее развитие одного или более бизнес-процессов. События могут активизировать функции или порождаться функциями.
2. Зелёные элементы – функции или функциональные блоки. Функциональный блок – это действие или подпроцесс, выполняемый с целью получения заданного результата и перевода системы из одного состояния в другое. Порядок выполнения функций задается на диаграмме сверху-вниз.
3. Так же хорошо улавливается информация об исполнителях каждой работы, которые отображаются с помощью желтых овалов . Этот элемент называется «Субъект», он обозначает исполнителей, владельцев или участников. В качестве субъектов могут быть прикреплены должности исполнителей, подразделения и роли.
4. Помимо названных фигур на диаграмме используются серые прямоугольники или похожие на них фигуры, которые обозначают все многообразие используемых и создаваемых ресурсов и результатов в процессе. Если мы захотим отобразить передачу денег, то также должны будем воспользоваться серым прямоугольником.

Основные элементы нотации EPC

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

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

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

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

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

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

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

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

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

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

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

Пример второго шага работы над процессом
(нажмите для увеличения)

Схема процесса на третьем шаге нотации EPC
(нажмите для увеличения)

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

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

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

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

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

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

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

Источник: projectimo.ru