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

Область применения EPC

Диаграмма EPC является стандартизированной графической диаграммой для моделирования бизнес-процессов, применима для:

• Составления моделей и документирование бизнес процессов как есть (as is)
• Описание возможных усовершенствований существующих бизнес процессов как будет (to be)
• Выявление всех участников процесса
• Выявление всех информационных систем, ресурсов и документов участвующих в процессе

Чтобы лучше получить представление о диаграмме EPC советуем посетить ссылки:

• Введение в EPC

  Ссылка ведет на введение в EPC. Советуем посетить ссылку в первую очередь.

• Элементы и структура построения диаграмм EPC

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

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

  Ссылка ведет на документ где описаны примеры построения диаграмм. P.S. В данном случае нас интересует только информация, представленная в четвертой главе с 86 страницы.

Прочие полезные материалы:

• Ссылка ведет на сборник учебных материалов по методологии ARIS.

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 ).

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

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

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

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

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

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

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

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

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

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

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

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

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

Нотация IDEF0

Пример описания БП с помощью IDEF0

Не читайте нам нотаций

Не читай нотаций мне
Мама, это ни к чему

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

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

Рынок описания БП существует очень давно. Однако за последние полтора десятилетия он сделал стремительный рывок, благодаря появлению новой отрасли - автоматизации учета и управления на предприятиях. Растущий рынок дал шанс новичкам, придумавшим новые нотации пробиться и застолбить свое место. Например на российском рынке за несколько последних лет массированные рекламные и информационные акции со стороны IDS Scheer (главного поставщика ARIS - см. рис. 3) создали прослойку специалистов по описаниям автоматизируемых процессов.

Использование нотация ARIS требует большой детализации бизнес-процессов.

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

Описание бизнес-процессов в России веяние относительно недавнее, несмотря на внушительное количество ГОСТов в этой области (3.1109, 34, ИСО и др.). Сейчас, с качеством описания собственных бизнес-процессов лучше всего дела обстоят в банках. Дело в том, что в отличии от других коммерческих структур банк - это инфраструктурная организация и поэтому она находится в жестких рамках регламентов определенных законодательством. Банк работает по принципу управления операционным днем. В результате даже упрощенное описанные бизнес-процессов Банка (русским языком без использования нотаций) получается более детально проработанным, т.к. опирается на фундамент, построенный на томах регламентов предопределяющих стандарты, терминологию, роли и правила. Эти стандарты являются общепринятым языком в банковской среде и описание бизнес процессов будет легко читаемым для любого специалиста.

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

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

Нотный стан

Я забыла все, чему
Нас учили столько лет

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

Каждая нотация приспособлена под определенный круг задач. Будем считать наиболее актуальной задачей изменение бизнес-процессов в рамках проекта автоматизации управления. Для этих целей есть хороший набор инструментов имеющий достаточное распространение: это и российские ГОСТы, и тот же ARIS, и IDEF, а так же EPC (рис.4 и рис.5).

Нотация EPC

Описание бизнес-процесса с помощью EPC

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

При выборе нотации так же важным критерием является так же возможность использования знакомого программного инструмента. Например, Microsoft Business Solution в 2002 году предлагал для информационной системы Navision нотацию On-Target, сопровожденную специальным программным решением. Это тот самый случай, когда лучше выбрать что то другое - мало того что, нотацию On-Target у нас ни кто не знает, так еще и программная среда потребует времени на ее изучение. Положительным же примером я бы назвал использование нотации IDEF, и программы Visio, весьма распространенной и обладающей, необходимым набором инструментов для рисования IDEF диаграмм (рис. 6).

Бизнес-процессы IDEF выполненные в Visio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт EPC

EPC (Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции. Нотация EPC была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS.

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

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

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

К преимуществам EPC относится возможность очень детально и точно описать выполнение бизнес-процесса, показать на диаграмме в графическом виде всех исполнителей, все используемые объекты. Также плюсом EPC-диаграмм является тот факт, что, как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от блока к блоку. К тому же, в отличие от всё той же IDEF0, появилась возможность распараллеливать процесс, направляя его только по одной из альтернативных веток (в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно). Достоинством также мне показалась возможность указать исполнителя по каждому этапу (читай: функции). Но, в IDEF0 исполнитель указан на каждом уровне декомпозиции единожды, и от его имени тянутся стрелки ко всем исполняемым им блокам. В EPC, чтобы подсчитать, какое количество действий выполняет исполнитель, нужно пробежаться по всем блокам действия и проверять, указан ли по нему нужный нам исполнитель.

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

В целом нотация EPC является признанной во всем мире как одна из лучших нотаций для построения бизнес-процессов и моделирования работы предприятия.

Выбор метода моделирования

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

Всякая вещь есть форма проявления беспредельного разнообразия.

Козьма Прутков

Введение в нотацию eEPC

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

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

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

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

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

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

Пора начать наше повествование об очень интересной, простой и практичной нотации eEPC (в переводе: расширенное описание событийной цепочки процессов). В ее дословном переводе раскрывается и основное предназначение: описание цепочки бизнес-процессов. Главная «фишка» нотации в ее принципе «событийности», который мы рассмотрим подробно.

Какие преимущества имеет нотация eEPC:

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

Конечно, как и все в этом мире, она имеет и недостатки. Но рациональное использование сводит их к минимуму. Главный недостаток, на мой взгляд, это тот факт, что если использовать простые инструменты (т.е. программы для рисования схем, а не для моделирования бизнес-процессов), то мы не имеем единой базы данных объектов. Кроме этого, сложно проконтролировать, входы-выходы (надо их именно контролировать, т.е. придумать способ такого контроля, если требуется). Но, с другой стороны, использование инструментов моделирования сложных бизнес-процессов стоит весьма внушительных сумм, а проект с их использованием измеряется в миллионах. А так мы имеем очень экономичный и понятный инструмент. Если говорить точнее, этот недостаток относится именно к рассматриваемому мной способу описания, т.е. с использованием MS Visio или аналогичного ПО. Если Вы будее использовать специализированные системы описания бизнес-процессов, поддерживающие базы данных объектов, то этого недостатка можно избежать. Ну что, пора начать…

Главный "стержень" нотации eEPC

Как я уже упоминал, в дословном переводе аббревиатуры eEPC кроется понятие событийности. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: «Событие» и «Функция». Когда кто-то первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то часто возникает вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Так вот: событие - это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием Поясню на примере. Звонит телефон. Менеджер взял трубку для телефонного разговора. В данном случае «Звонит телефон» - это событие. Телефонный разговор - это функция. Разговор завершен (повесил трубку) -снова событие. Таким образом, наблюдается событийная цепочка: Звонок - разговор - завершение звонка. А завершении звонка наверняка потребует выполнение новой функции: запись результата звонка и т.д.

Давайте попробуем это нарисовать. Для начала надо выяснить, как отображаются элементы «Событие» и «Функция».

Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. Думаю, надо сказать пару слов об используемых цветах. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, т.к. схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае (в нтации eEPC) так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше - сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. Почему они такие? Точно не уверен, но мне кажется от того, что компания ARIS, когда сделала в своем продукте поддержку нотации eEPC, дала им такие цвета, они и «прижились». Кстати, иногда эту нотацию еще называют «ARIS», «ARIS EPC», что является не совсем верным, т.к. компания ARIS не изобретала эту нотацию, а сделала ее поддержку в своей программе моделирования бизнес-процессов. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой (т.е. отличаться лишь цветом), т.к. в черно-белом варианте это может вызвать путаницу. Существуют и другие правила, которые позволяют придать «стройность» диаграмме eEPC, мы будем о них говорить.

Итак, есть событие, есть функция. Как они связаны?

Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2. Если применительно к примеру с телефонным звонком, то будет так:

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

• Должность (исполнитель). Тот, кто выполняет данную функцию
• Информация. Любая информация, используемая для выполнения функции, кроме документальной. Например, телефонный звонок, инструкция по выполнению операции т.п.
• Документ. Элемент «Документ» предназначен для отображения носителей информации (бумажной или электронной). Т.е. представление информации в определенной структуре.
• Программа (приложение). Программное обеспечение, используемое для выполнения функции.

Все остальные элементы являются вспомогательными, и практически не регламентированы требованиями самой eEPC. Однако, нет никаких препятствий для того, чтобы добавить свои собственные элементы. Главное, зафиксировать это во внутреннем стандарте, чтобы было единое понимание, как они выглядят и зачем применяются. Такое расширение не нарушает требований, если не нарушается связка событие-функция-событие, и предназначено лишь для улучшения восприятия информации или адаптации правил описания в какой-либо отраслевой специфике. Я добавил свой набор элементов, о которых расскажу ниже.

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

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

Мы видим, что оператор выполняет обработку входящего звонка, действуя в соответствии с правилами обработки входящих звонков и использует для этого программу «CRM». Ни входящих, ни исходящих документов при этом не используется.

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

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

Элементы логики в схемах нотации eEPC

Элементы логики просты, но есть свои особенности и правила, чтобы схема была логичной и однозначно истолкована. Самое важное правило, которому нужно придерживаться на 100%: логические решения могут приниматься только при выполнении функции. Т.е. после некоторого события не может быть разветвления. Почему? Потому, что в этом случае это противоречит самому понятию события - оно простое и мгновенное, без времени выполнения. Например, если зазвонил телефон, и человек сидит думает, брать ему трубку или не брать, теоретически это уже будет функцией, где он принимает решение. А практически, в том числе из здравого смысла, он нарушает правила обработки звонков, т.к. ему зарплату платят за то, чтобы он эти звонки обрабатывал, и нечего тут рассуждать (в целом как нарисовано на схеме).

Всего различается 3 элемента логики:

• И. Когда произойдут два или более события одновременно;
• ИЛИ. Когда могут произойти одно ли несколько событий, но как минимум одно должно произойти обязательно;
• ИСКЛЮЧАЮЩЕЕ ИЛИ. Либо одно, либо другое. Т.е. два варианта одновременно невозможны.

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

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

Логический элемент «И». Когда для выполнения функции требуется одновременное выполнение нескольких событий:

Пример: Если закрыт отчетный период (событие 1) и наступил срок подачи отчета руководителю (событие 2), сотрудник готовит ежемесячный отчет.

Соединение элементов, если при выполнении функции, возникает несколько событий:

Пример: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: взаиморасчеты сверены (событие 1), акт подписан (событие 2). На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий

Соединение элементов, если при выполнении нескольких функций, возникает событие:

Пример: Кладовщик собрал заказ (функция 1), оператор выписал документы (функция 2), товар готов к отгрузке (событие).

Соединение элементов, если возникновение одного события приводит к выполнению нескольких функций:

Пример: Поступила партия товара (событие). Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе.

Логический элемент «ИЛИ».

Соединение элементов, если одно из событий может вызвать выполнение функции:

Пример: Поступила заявка по телефону (событие 1) или поступление заявки по электронной почте (событие 2) приведет к необходимости ее обрабатывать.

Соединение элементов, если одна функция может вызвать как минимум одно событие:

Пример: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте (событие 1), по факсу (событие 2).

Логический элемент «ИСКЛЮЧАЮЩЕЕ ИЛИ».

Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий:

Пример: Клиент приехал в магазин лично (событие 1) или совершил заказ через интернет (событие 2). Необходимо выполнить отгрузку товара (функция 1).

Соединение элементов, если в результате выполнения функции происходит максимум одно из событий:

Пример: Решение либо принято либо нет.

Соединение элементов, если событие произойдет после того, как будет выполнена одна и только одна из функций.

Пример: Доставка товара осуществлена (событие 1) либо собственным транспортом (Функция 1), либо транспортной компанией (функция 2)

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

Расширение нотации собственными элементами

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

Файл с данными. Используется, если в результате выполнения операции создается файл данных, или файл используется для выполнения операции.

База данных. Используется при описании информационных потоков между автоматизированными системами.

Картотека. Используется для отображения бумажной картотеки или архива.

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

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

Соглашения о правилах размещения фигур на схеме

Сама по себе нотация eEPC не предъявляет жестких требованиях в расположении элементов друг относительно друга, хотя принято рисовать схему сверху вниз или слева направо. Есл это не унифицировать в случае работы нескольких специалистов, то может получиться своеобразный «винегрет». Что бы этого избежать, рекомендуется выработать и утвердить свои правила расположения элементов. Я придерживаюсь (и рекомендую) следующих правил:

• Последовательность событий и функций располагают сверху вниз (лучше) или слева направо (если не хватает места);
• Элементы, обозначающие исполнителей, располагаются справа от функций;
• Входящие документы слева вверху от функций; направление стрелки от документов к функции;
• Исходящие документы слева внизу от функций; направление стрелки от функции к документам;
• Элемент «Информация» располагается внизу справа от функции. Если места недостаточно, допускается произвольное расположение, как можно ближе к функции;
• Элемент «Приложение» располагается вверху справа от функций. (если для этого используется файловые хранилища, не являющиеся отчетами, то отображаются аналогично). Связь без стрелки.
• Элементы «База данных» и «Картотека» располагаются произвольно;
• Элемент «Материальный поток» располагается слева от сопровождающих его документов с привязкой к документу линией без стрелки;
• Элемент «Кластер» в случае использования в сочетании с фигурой «Документ» для обозначения документа в электронном виде располагается слева от соответствующего документа.

Например: Расчетчик заработной платы рассчитывает заработную плату на основании предоставленных ему документов «Бригадный наряд». При этом он руководствуется документом «Положение о заработной плате», расчет производит в программе «1С: ЗиК». Результатом расчета является документ «Ведомость».

Идентификация элементов на диаграмме

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

Обязательной идентификации на диаграмме подлежат фигуры «Документ» и «Функция».

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

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

Поэтому, сейчас я лишь покажу на примере, как это может быть представлено на схеме. Вернемся к примеру с обработкой звонка. Предположим, что отделу продаж мы присвоили код «04», процессу обработки входящего контакта код «ВК». Тогда схема примет следующий вид (идентификация выделена красным для наглядности). Код документа при этом указывает на порядковые номер документа в общем реестре документов (мы это тоже будем рассматривать отдельно, когда доберемся до обследования системы документооборота).

Отображение обратной связи

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

Текстовое описание процессов

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

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

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