УДК 004.9

Особенности произведения декомпозиции процессно-событийной модели бизнес-процесса в нотации ARIS

Акатьев Ярослав Алексеевич – ассистент кафедры Практической и прикладной информатики МИРЭА – Российского технологического университета.

Анищенко Екатерина Игоревна – студент магистратуры кафедры Практической и прикладной информатики МИРЭА – Российского технологического университета.

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

Ключевые слова: проектирование программного продукта, моделирование, процессно-событийная модель, eEPC, ARIS, декомпозиция.

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

Одной из распространенных методологий моделирования бизнес-процессов является методология ARIS. ARIS, как методология, - подход к структурированному описанию деятельности компании. В системном структурном анализе основным понятием выступает структурный элемент или объект описываемой предметной области, в виде которого обычно представлены процессы и функции. Для детального описания процессов, которые выполняются в рамках одного или нескольких подразделений конкретными сотрудниками используется процессно-событийная модель в нотации eEPC (extended Event-driven Process Chain). Данная нотация относится к методологии ARIS и предлагает такую систему описания процессов, в которой все функции семантически связаны. При этом нотация не подразумевает четкого выполнения функций, она носит событий характер. Событие – это некоторое состояние, которое является необходимым условием для начала и окончания выполнения функции. Каждая модель должна начинаться как минимум одним стартовым инициирующим событием и завершаться одним или более результативным событием или интерфейсами другого процесса. События и функции должны иметь только по одному входящему и исходящему отношению. При этом важно помнить, что при определении событий, они должны быть мгновенны во времени.

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

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

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

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

Следуя данным принципам, необходимо проводить агрегирование объектов до единого функционального блока или подпроцесса. При этом объекты декомпозированного блока должны быть отражены на отдельной диаграмме с ссылкой на родительскую функцию. Таким образом, сформированная диаграмма будет представлять уже другой уровень абстракции. Для связи процессов между собой используется «коннектор» к процессам уровня выше или объект Process Interface. Другими словами, если событие формируется в другом процессе, то ему предшествует интерфейс, который ссылается на предыдущий процесс. Если результатное событие является инициирующим для другого процесса, то за ним также должен располагаться интерфейс, отражающий последующий процесс. Process Interface при декомпозиции процессов является средством связи и границей между двумя функциональными объектами.

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

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

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

image1

Рисунок 1. Верхний уровень процесса.

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

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

Также основной проблемой заметно неверное расположение участников процесса, документов и объектов, из-за чего трудно верно определить к какому процессу или группе процессов они относятся.

image2

Рисунок 2. Декомпозиция процесса «Проверка состояния квартиры клиента».

Из приведенного примера наглядно заметно, что нарушение парадигм и семантики построения диаграмм в нотации ARIS влечет за собой затрудненное чтение диаграммы, а также ошибочные рассуждение при предоставлении диаграммы заказчику.

Перечислим основные требования к декомпозиции процесса:

  • наличие стартового/завершающего события с верхнего уровня для четкого определения точки начала бизнес-процесса, так как в ARIS отсутствует понятие, как например, в BPMN0;
  • наличие структурного элемента Process interface содержащего ссылку на внешний предшествующий и последующий процесс, также данный элемент может использоваться для отображения внешнего процесса, влияющего на текущий;
  • все элементы документы и базы данных должны располагаться по возможности слева от процесса, а местоположение и роль справа;
  • агрегирование атомарных функций в один функциональный блок позволит значительно сократить схему, а также способствует более качественному анализу бизнес-процесса.
  • моделирование и чтение процесса должно проводиться «сверху-вниз» для наибольшей читаемости диаграммы.

На основании изложенных пунктов сформирован общий вид модели, описывающий верное расположение объектов при декомпозиции (Рисунок 3).

image3

Рисунок 3. Общий вид модели.

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

Список литературы

  1. Бьерн Андерсен. Бизнес-процессы. Инструменты совершенствования – Москва: Издательство «ASQ», 2019 г.
  2. Д. Джестон. Управление бизнес-процессами. Практическое руководство по реализации проектов – Москвы: Издательство «Альпина Диджитал», 2020 г.
  3. Владимир Репин. Бизнес-процессы. Моделирование, внедрение и управление – Москва: Издательство «Манн, Иванов и Фербер», 2019 г.
  4. Шёнталер Франк, Фоссен Готфрид. Бизнес-процессы. Языки моделирования, методы, инструменты. 2019. – C. 86-134
  5. Майк Мартин Хаммер. Реинжиниринг корпорации: манифест революции в бизнесе. Москва: Издательство «Манн, Иванов, Фербер», 2019 г.
  6. Карл И. Вигерс, Джой Битти. Разработка требований к программному обеспечению. Санкт-Петербург: Изд-во БХВ-Петербург 2020.

Интересная статья? Поделись ей с другими: