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

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

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

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

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

Рисунок 16. Диаграмма процесса, на которой встречается Функция 1	Рисунок 17. Диаграмма декомпозиции Функции 1

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

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

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

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

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

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

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

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

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

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

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

Функции в модели ARIS EPC запускаются событиями, например, «Счет поступил на согласование», и событиями оканчиваются, например, «Счет согласован» или «Счет не согласован». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, событие между этими функциями может не рисоваться.

Модель бизнес-процесса нотации ARIS EPC обязательно начинается и заканчивается одним, или несколькими событиями или интерфейсами в другие модели бизнес-процессов. Для отражения интерфейсов используются специальные объекты «Интерфейс процесса» — тип объекта «Функция».

При создании модели ARIS EPC могут возникнуть ситуации, когда один и тот же документ является исходящим для одной функции и входящим для следующей. В этих случаях для улучшения эргономики модели допустимо использования одного представления документа с одной входящей связью (от функции, в которой он создается или корректируется) и одной исходящей связью (к функции, которой он используется).

Модель EPC не может быть несвязной, т.е. расположение на модели, одного объекта, не связанного с остальными, является ошибкой.

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

На модели ARIS EPC указывается следующая информация:

• выполняемые функции
• информационные ресурсы функций (входящие/исходящие документы)
• события
• интерфейсы процессов
• логические операторы
• исполнители (должности, бизнес-роли)
• информационные системы

Правила именования события в ARIS EPC

Имя события (Event) должно содержать существительное и описание изменения состояния в виде отглагольной формы. Пример: «Сделка исполнена».

Правила именования функции в ARIS EPC

Для наименования функции (Function) необходимо использовать ее реальное название. Имя должно состоять из двух частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым он выполняется. Наименование функции состоит из краткого наименования объекта, начинающегося с заглавной буквы, например, «Поиск контактов клиента».

Правила именования роли/должности в ARIS EPC

Наименование бизнес-роли (Person Type) должно соответствовать сути возлагаемых на исполнителя обязанностей. Как правило, наименование содержит фразу «Ответственный за …». Наименования должностей (Position) пишутся в соответствии со штатным расписанием.

Правила именования документов

Объект соответствует документу (Information Carrier) (в бумажном и/ или электронном виде). Для наименования документов (независимо от используемого символа) необходимо использовать их реальное название.

Правила именования информационных систем в ARIS EPC

Для наименования информационных систем (Application system type) следует использовать их устоявшиеся названия.

Правила именования интерфейса процесса

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

22 сентября 2010 г. 20:30

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

А.Вратарёв

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

Ноты для бизнеса

Статья опубликована в журнале "Новости менеджмента" в январе 2012 года.

Музыка нас связала
Тайною нашей стала

Все эпиграфы к этой статье взяты из песни "Музыка нас связала" группы Мираж.

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

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

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

Неужели я сама
Не найду на все ответ

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

Документ "Описание БП" становиться особенно актуальным, как только появляется потребность реорганизации (или как сейчас модно говорить - реинжиниринга) компании. В этом случае документ используется чтобы:

1. На нем как на карте сражений пометить суть запланированных преобразований,
2. Ввести в курс дела участника преобразований,
3. Ручкой а не на пальцах поставить задачу начальникам отделов и внешним специалистам.

В том, что документ готовиться своими силами, есть плюсы:

• Это выходит дешевле;
• Внутренний специалист, лучше разбирается в практиках родного бизнеса.

Стороннему консультанту, сначала предстоит изучить терминологию и ключевые особенности предмета, стандарты отрасли. На это уходит время. Правда он лучше знает как и что надо описывать. Есть же определенные правила, общепринятые нотации и специальный софт. Пример такой нотации можно посмотреть на рис. 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.

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

Полнота и глубина звучания

Что меня тянет сюда я не знаю

1. займет много времени,
2. часть деталей измениться в процессе создания документа.

Распространенной ошибкой является попытка подогнать описания под нотацию. Например, пытаться описать процедуры в формате ARIS, т.е. достигать очевидной избыточности в описании, когда это не требуется.

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

Мелодия - это последовательность звуков, а не нот

Позабудь об этом дне
Спор не нужен никому

Значит можно описать БП и просто словами, без всяких нотаций. С нотацией конечно правильней, однако важно не это. Описание БП это не конечный продукт, а только инструмент для новых свершений. Это значит, что он должен быть приспособлен к дальнейшему активному использованию. Главная проблема большинства документов из серии "сделай сам" заключается в неудобстве применения. Например, один такой документ состоял из описания сделанного в Microsoft Word и рисунков сделанных в PowerPoint, прыгать из программы в программу было ужасно неудобно, пришлось потратить большое количество времени, чтобы просто свести все это в один документ. Получается, что документ должен обладать следующими свойствами:

1. Иметь четкий порядок и группировку разделов, т.е. быть концептуально целостным (обычно это значит, что если ты концепцию - значит ты научился им пользоваться);
2. Четко выделять бизнес подразделения и давать им понятные названия и нумерацию;
3. Четко выделять бизнес процессы и тоже давать им понятное название и нумерацию;
4. Нумеровать элементы следует так, чтобы исключить путаницу (это заметно облегчает поиск): например, Отдел №1 должен иметь в документе номер Отд001, а Бизнес-процесс №1 должен иметь номер БП001;
5. Документ должен иметь раздел содержание с древовидной структурой;
6. Компания это целостный организм и ни какой бизнес-процесс не висит в воздухе - он всегда связан с другими БП, с бизнес единицами и отделами. Для отражения этих связей можно использовать гиперссылки - это облегчит поиск информации и переход от одного объекта к другому.

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

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

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

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

Всем уговорам твержу я в ответ
Нас не разлучат, нет

Напоминаем, что все эпиграфы к этой статье взяты из песни "Музыка нас связала" группы Мираж

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

«Чем нагляднее передана информация, тем быстрее и точнее ее воспримет тот, кому она адресована». Эту истину давно и активно используют маркетологи, педагоги и исследователи. Не остались в стороне и менеджеры. В этой статье рассмотрена нотация 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. При распараллеливании работ очень сложно отразить исполнителей. Если один человек выполнят группу функций, картинка усложняется стрелками. Если присутствуют несколько исполнителей или мы не хотим рисовать длинные стрелки, приходится дублировать «овальчики» с исполнителями. Все это очень скоро может привести к полной неразберихе на схеме.

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