В статье
Введение
В данной статье мы рассмотрим некоторые практические важные аспекты описания процессов в нотации eEPC в среде моделирования Business Studio 4.0.
Методология ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем) является одной из современных методологий описания процессов. Она была разработанная немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная система, описание которой строится из четырех основных групп моделей: моделей организационной структуры, моделей функций, моделей данных и объединяющих эти три группы, — моделей
Нотацию eEPC поддерживают многие современные программные продукты, предназначенные для описания
Нотация 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 из такого объекта под названием «Управление ценообразованием» выходит документ «
Но если при использовании междиаграммных ссылок в нотации «Процедура» мы сразу увидим аналогичную ссылку и выходящую из нее стрелку документа, то при использовании интерфейса процесса в нотации eEPC ничего такого не произойдет. Переход с диаграммы на диаграмму возможен, но обратная ссылка (интерфейс процесса) и соответствующий документ автоматически сформированы не будут. Придется делать это вручную, что весьма неудобно.
При использовании интерфейсов процессов на схемах в нотации eEPC поставщик BusinessS tudio рекомендует связывать между собой по входам и выходам операции процессов,
Еще одна неудобная мелочь (с точки зрения регламентации) состоит в невозможности отключить показ на диаграмме номера процесса, на который ссылается
Итак, при формировании схемы процесса в нотации 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 не работает.
Рис. 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
Октябрь 2014 г.
Поделиться: