ЕЕРС - событийно-функциональные диаграммы

Событийно-функциональные диаграммы (сокращенно еЕРС - extended event-process chain),

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

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

• отправка заказа

• доставка товара

• разработка рекламного макета. Примеры событий:

• получена заявка от клиента

• товар доставлен

• проверка качества проведена

• рекламный стенд установлен. Для описания ветвлений процесса используются логические операторы.

• и--®

• или -®

• исключающее или - ®

BPMN

BPMN (Business Process Modeling Notation) — спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах, называемых BPD (Business Process Diagram, что дословно переводится просто как «диаграмма бизнес-процессов»). Эта спецификация разработана организацией Business Process Management Initiative (BPMI) в 2001-2004 годах с учётом множества ранее существовавших диаграмм (в т.ч. всех, упомянутых выше). Основной целью данной разработки было получение нотации, легко понимаемой всеми пользователями: от бизнес-аналитика, создающего первые наброски описаний процессов, к техническим специалистам, отвечающим за реализацию этих процессов в Системе, и, наконец, до людей бизнеса, которые управляют этими процессами и контролируют их работу.

Сама спецификация BPMN не определяет формата файла, в котором можно сохранять описание и которым можно обмениваться (в том числе, и с Системой), однако уже есть как минимум одна спецификация, описывающая этот формат — это XPDL. В спецификации XPDL v.2.00 [4] явно указано, что одно из её назначений — служить описанием формата файла для нотации BPMN. Т.е. XPDL позволяет хранить не только логику процесса (как и BPEL, другая спецификация формата описания бизнес-процесса, понимаемого машиной), но и его графическое BPMN-представление. Таким образом, формат файла BPMN уже существует, что позволяет «понимать друг друга» различным инструментальным средствам моделирования.

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.

№	Критерии сравнения	ARIS	IDEF0	IDEF3
	Принцип построения диаграммы / логика процесса	Временная последовательность выполнения процедур	Принцип доминирования (см. стандарт IDEF0)	Временная последовательность выполнения процедур
	Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
	Входящий документ	Используется отдельный объект для описания («документ»)	Стрелка слева, стрелка сверху	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Входящая информация	Используется отдельный объект для описания («кластер», «технический термин»)	Стрелка слева, стрелка сверху	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Исходящий документ	Используется отдельный объект для описания («документ»)	Стрелка справа	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Исходящая информация	Используется отдельный объект для описания («кластер», «технический термин»)	Стрелка справа	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Исполнитель процедуры	Используется отдельный объект для описания («позиция», «организационная единица»)	Стрелка снизу	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Используемое оборудование	Используется отдельный объект для описания	Стрелка снизу	Нет (может быть отражен в модели только привязкой объекта-комментария)
	Управление процедурой	Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов	Стрелка сверху	Только временная последовательность выполнения процедур и логика процесса
	Контроль выполнения процедуры	Нет. Может быть отражен указанием входящих документов	Стрелка сверху	Нет.
	Обратная связь по управлению/контролю	Нет. Может быть отражена только символами логики (последовательность выполнения процедур)	Стрелка сверху	Нет.

Таблица 1

Описание бизнес-процессов как один из этапов автоматизации

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

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

Цель

• Во-первых, нужно получить рисунки («блок-схемы»...), которые мы сможем использовать во время презентаций и обсуждений, а также которыми мы снабдим (дополним) текстовые документы, описывающие процессы: те текстовые документы, которые станут основой для проектирования системы.

К этим рисункам (диаграммам) нужно предъявить следующие требования:

• Они должны достаточно подробно и точно описывать логику процесса. При этом для различных сочетаний требований к «подробности и точности» желательно использовать одни и те же диаграммы.
• Они должны быть понятны, причём одинаково, различными людьми, заинтересованными в работе с этими рисунками. Это, в первую очередь, люди бизнеса (Клиенты, сотрудники организации), чью работу необходимо описать, а также бизнес-аналитики, консультанты и т.п.. В идеале, любой человек, знакомый с использованным способом описания процесса, должен правильно понимать то, что изобразили.
• Во-вторых, необходимо построить «модель» процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса нужно используем не карандаш и бумагу или их компьютерный аналог: программу — «рисовалку» типа Adobe Photoshop, — а специальное «инструментальное средство моделирования». Традиционно под этим термином известны продукты ARISи BPWin, однако не следует ассоциировать способ описания процессов с конкретным продуктом. Более того, зависимость от конкретного продукта сегодня уже является минусом как самого способа описания бизнес-процессов, так и

что же конкретно мы хотим получить от модели бизнес-процессов?

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

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

И наоборот: наличие обратной связи от Системы к её модели замыкает контур управления Системой, делает реальностью циклическую разработку (round — trip engineering), которая сейчас является необходимым элементом любой серьёзной среды разработки автоматизированных систем.

Достоинство модели бизнес-процессов по сравнению с «моделями компонентов Системы» (к которым нас приучил язык UML) в том, что модель бизнес-процессов создаётся на другом, более высоком, уровне абстракции и позволяет бизнес-аналитикам и клиентам непосредственно участвовать в развитии Системы во время её промышленной эксплуатации, работая в команде на своём уровне понимания: на бизнес-уровне Системы. Т.е. в данном случае для внесения в Систему достаточно большой группы изменений: тех изменений, которые относятся к уровню бизнеса и его логики, — Клиенту уже не нужно самому быть программистом или использовать программиста в качестве переводчика его мыслей на язык машины (и наоборот: с языка машины на язык бизнеса).