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

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

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

Введение в нотацию 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», процессу обработки входящего контакта код «ВК». Тогда схема примет следующий вид (идентификация выделена красным для наглядности). Код документа при этом указывает на порядковые номер документа в общем реестре документов (мы это тоже будем рассматривать отдельно, когда доберемся до обследования системы документооборота).

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

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

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

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

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

Бизнес-процесс:	Обработка входящего контакта	04.ВК
Функции процесса:
Наименование	Описание	Номер на схеме
Обработка входящего звонка	При поступлении входящего звонка оператор обрабатывает звонок в соответствии с правилам обработки входящих звонков. Выявляет интерес клиента, предоставляет информацию об услугах	04.ВК.01
Формирование коммерческого предложения	При наличии интереса клиента, оператор передает контакт менеджеру по продажам. Менеджер по продажам готовит коммерческое предложение и отправляет клиенту по электронной почте	04.ВК.02
Показатели процесса:
Наименование	Способ оценки / измерения
Количество отказов	Статистика по базе данных

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

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

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 чел.)

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

12.10.2011 Игорь Федоров

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

Cпоры о выборе нотации для моделирования бизнес-процессов по-прежнему не утихают. Анализу подвергаются возможности нотаций EPC (Event-driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. д. Однако сравнивать нотации и языки описания бизнес-процесса путем анализа их функциональности некорректно - является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес-процессов и появлению некачественных моделей.

Модели и перспективы

Модель - это материальное или мысленное представление объекта или явления, повторяющее одни свойства, существенные для целей конкретного моделирования, и опускающее другие, несущественные свойства, в которых модель может отличаться от прототипа. Сложный объект, например бизнес-процесс, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей связана с главным вопросом, на который должна давать ответ соответствующая модель. Выделяются четыре перспективы модели бизнес-процесса (см. рисунок).

Функциональная: «Что делают участники?». Описывает состав выполняемых работ.

Поведенческая: «Как работают участники?». Описывает очередность, расписание выполнения, бизнес-правила.

Информационная: «Что обрабатывают участники?». Описывает бизнес-сущности предметной области процесса.

Организационная: «Кто выполняет работу?». Описывает состав и структуру исполнителей.

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

Функциональная перспектива

Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) - перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую-либо важную функцию. Если две разные организации выполняют один и тот же процесс, то функциональная декомпозиция работ у них будет одинаковой, хотя очередность исполнения работ может меняться с учетом отличий их организационной структуры. Таким образом, функциональная модель слабо зависит от организационной структуры и может рассматриваться как справочная.

Часто функциональную модель ошибочно называют картой процессов; например, модели SCOR (The Supply-Chain Operations Reference-model) и ETOM (Enhanced Telecom Operations Map) содержат иерархии функций и цепочки создания ценности, но отнюдь не процессы . Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы

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

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

Бизнес-логика процесса

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

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

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

Бизнес-правила

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

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

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

Расписание исполнения

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

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

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

Степень детализации бизнес-логики

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

Руководящий документ Госстандарта России, «Методология функционального моделирования IDEF0» вводит понятия «действие» и «операция». Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а операция - как «совокупность последовательно или/и параллельно выполняемых действий».

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

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

Степень полноты бизнес-логики процесса

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

Сравнительный анализ нотаций EPC и BPMN

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

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

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

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

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

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

Интерес к BPM и BPMS (Business Process Management Suite) достиг той степени зрелости, когда уже не приходится говорить о моде. Кроме этого, закончилась война стандартов и нотация BPMN получила признание всех крупных игроков, став стандартом де-факто. Это событие по значимости можно сравнить с появлением SQL, ставшего основой современных информационных систем.

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

• Поддержка BPMN. Какая версия BPMN поддерживается (1.x или 2.0)? Насколько полна реализация: поддерживаются ли сообщения, сигналы, транзакционные подпроцессы?

• Тип процессного движка BPMN. Непосредственное исполнение предпочтительнее трансляции в какое-либо другое представление – только в этом случае удается на практике реализовать непрерывное усовершенствование бизнес-процессов.
• Связь между процессами и данными. Предпочтительнее хранение атрибутов про
цесса в максимально открытом виде – в таблицах и столбцах реляционной СУБД, что обеспечивает ссылочную целостность, высокие оперативные характеристики и свободу доступа к данным извне, в противоположность, например, хранению атрибутов в виде XML-строки.
• Пользовательский интерфейс. Интерфейс должен быть функциональным, эргономичными
и разрабатываться быстро, повозможности без программирования. Система должна позволять силами бизнес-аналитика создавать работающий пользовательский интерфейс, который при желании можно доработать уже с привлечением программиста.
• Системная платформа. В зависимости от технической политики компании выбор
может быть ограничен платформой Java или. Net – BPMS, поддерживающие обе платформы, являются редкостью.
• Схема лицензирования. Условно-бесплатные системы позволяют сэкономить на ли
цензии, но требуют больших ресурсов на разработку; некоторые коммерческие системы требуют значительных затрат даже в минимальной конфигурации.
• Наличие представительства или партнера в России.

Не следует забывать, что BPMS – это только одна из составляющих BPM, и для успеха проекта создания системы управления бизнес-процессами необходимы также компетенции в методологии и в управлении agile-проектами.

Анатолий Белайчук ([email protected]) – президент компании «Бизнес-Консоль» (Москва).

Проблемы трансляции диаграммы EPC в исполняемый формат

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

Перечислим типовые ошибки моделирования.

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

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

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

Недостаточная степень детализации процесса приводит к необходимости повторного уточнения и описания упущенных деталей на этапе подготовки требований к разрабатываемой ИТ-системе.

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

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

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

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

Литература

1. B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
2. eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
3. R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Игорь Федоров ([email protected]) – директор Центра компетенции процессного управления МЭСИ (Москва).

Моделирование бизнес-процессов, перспектива моделирования, функциональное и процессное моделирование