Автор: Владимир Репин
Информация об авторе

В статье В. В. Репина рассматриваются практические аспекты определения границ процессов при моделировании в среде Business Studio в нотации eEPC. Статья адресована сотрудникам компаний, осваивающим моделирование процессов с использованием Business Studio 4.0. Статья № 2 из серии статей.

Введение

В данной статье мы рассмотрим некоторые практические важные аспекты описания процессов в нотации eEPC в среде моделирования Business Studio 4.0.

Методология ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем) является одной из современных методологий описания процессов. Она была разработанная немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная система, описание которой строится из четырех основных групп моделей: моделей организационной структуры, моделей функций, моделей данных и объединяющих эти три группы, — моделей бизнес-процессов. К числу наиболее практически важных, относится основная нотация архитектуры ARIS — нотация eEPC, что означает «расширенная цепочка процесса, управляемого событиями».

Нотацию eEPC поддерживают многие современные программные продукты, предназначенные для описания бизнес-процессов, в том числе Business Studio 4.0.

Нотация eEPC в Business Studio

Входы/выходы процесса

Посмотрим, каким образом визуально можно показать границы процесса в нотации eEPCсреды моделирования BusinessStudio. На рис. 1 показан пример процесса, который мы разбирали в первой статье серии (там была представлена его схема в нотации «Процедура»). Границы процесса в нотации eEPC можно показать при помощи:

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

Пиктограммы ресурсов (бумажные и электронные документы, информация и проч.) связаны с конкретными объектами из справочника «Объекты деятельности».

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

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

Рис. 1. Схема процесса в нотации eEPC

В левом верхнем углу схемы, представленной на рис. 1, показана внешняя ссылка «Клиент» (маленький квадрат), из которой выходит стрелка, привязанная к бумажному документу «Запрос от клиента» (Вариант, А). Строго говоря, в нотации eEPC нет такого объекта, как «внешняя ссылка». Это элемент системы Business Studio. Возможность и целесообразность использования внешних ссылок на схемах в нотации eEPC должна обсуждаться на методическом совете компании при разработке внутреннего Стандарта описания процессов с использованием Business Studio.

Вариант «Б» — показать, что «Запрос от клиента» поступает от объекта справочника «Субъекты» под названием «Клиент» (в справочнике мы создали объект с типом «внешний субъект»). Такой вариант моделирования так же поддерживается Business Studio, но не предполагается в нотации eEPC (он возможен на диаграммах другого типа в методологии ARIS). Хотя для неискушенного пользователя рассматриваемый вариант выглядит вполне естественно, но использовать его при моделировании не рекомендуется из-за последующих проблем с формированием отчетов.

Пользователям нотации eEPC в Business Studio рекомендуется запомнить простой принцип: «обмен документами возможен только между процессами», т. е. на схемах процессов обмен документами между субъектами моделировать нельзя (если только не использовать специальную нотацию, где, наоборот, это как раз требуется).

Обратите внимание на такой важный объект схемы, как интерфейс процесса. На рис. 1 из такого объекта под названием «Управление ценообразованием» выходит документ «Прайс-лист на товар», который является входом операции «Выполнить анализ запроса». Такое представление означает, что процесс «Управление ценообразованием» является поставщиком информационного входа (документа) для рассматриваемого нами процесса. Если выделить интерфейс процесса на схеме мышкой и нажать стрелку «вниз» на панели инструментов, то в Business Studio произойдет переход на соответствующую схему процесса.

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

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

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

Итак, при формировании схемы процесса в нотации eEPC в Business Studio можно пользоваться рядом объектов и функциональными возможностями, которые не были изначально сформулированы в оригинальной нотации eEPC. С одной стороны это повышает гибкость моделирования, с другой — возникает риск некорректного использования нотации. Например, формирование схемы коммуникаций вместо событийно управляемой цепочки процесса, как показано на рис. 2. Читателю предлагается самому найти ошибки в этой схеме.

Рис. 2. Некорректное использование объектов нотации eEPC

Использование событий

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

Кстати говоря, имитационное моделирования в Business Studio будет работать в обоих случаях за счет внутренних функциональных возможностей и унификации модели в системе. Некоторые аналитики пренебрегают правилом «двух стрелок». В результате схемы процессов формируются с грубыми нарушениями нотации eEPC. На первый взгляд, ничего страшного в этом нет. Но при комплексной, систематической работе по созданию база знаний компании в области бизнес-процессов, такой подход категорически неприемлем. Есть риск разработки нестандартных схем низкого качества.

Рис. 3

В среде моделирования Business Studio события хранятся в специальном справочнике событий. При моделировании процесса можно использовать события из этого справочника. На рис. 4 показано, как можно выбрать событие. Например, при моделировании процесса, представленного на рис. 1, было выбрано событие «Поступил запрос от клиента», которое уже содержалось в справочнике. Мы создали его при описании процесса в нотации «Процедура» в той же базе данных Business Studio.

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

Рис. 4. Использование события из справочника при формировании схемы процесса в нотации eEPC

На рис. 5 представлена еще одна весьма удобная функциональная возможность Business Studio, которая часто используется при описании процессов в нотации eEPC. При декомпозиции процессов возможен перенос так называемого «окружения» процесса на нижестоящий уровень. Переносятся такие объекты, как: события, логические операторы, стрелки, исполнители, документы. С содержательной точки зрения это очень удобно, т. к. на схеме сразу становятся видны инициирующее и завершающее события, входы и выходы процесса. Остается только описать последовательность шагов между началом и завершением процесса.

Рис. 5. Перенос «окружения» операции процесса при декомпозиции

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

Рис. 6 поясняет, как используются события и потоки ресурсов, представленные на схеме в нотации eEPC, при формировании регламентирующих документов в среде Business Studio.

Рис. 6. Использование событий при формировании регламента процесса

Событие «А» является завершающим для «Процесса 1» и одновременно инициирующим для «Процесса 2». Документ «А» является исходящим для «Процесса 1» и одновременно входящим для «Процесса 2». Наименования события и документа попадают в соответствующие столбцы таблицы, представленной в регламенте выполнения бизнес-процесса.

Резюме

Подводя итоги, отметим, что eEPC — это одна из наиболее продуманных и удобных для моделирования бизнес-процессов нотация. На мой взгляд, она более строгая и логичная, чем «Процедура».

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

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

Опубликовано по материалам:
http://finexpert.ru/view/Business_Studio_notatsiya_protsedura_granitsy_protsessov_sobytiya_strelki/876

Рекомендуемые материалы по тематике