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

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

Прикладной функционал

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

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

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

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

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

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

♦ «позиционирование» маршрута в рамках общей модели путем его выделения каким-либо образом, например цветом;

♦ выделение всего маршрута в отдельную подмодель, поддерживающую связь с общей базой;

♦ проведение финансового, стоимостного, временного и других видов анализа «маршрута»;

♦ отслеживание последовательности этапов прохождения маршрута и т. д.

К сожалению, инструментальная среда ARIS не позволяет только своими стандартными средствами в полном объеме реализовать такую постановку задач и предлагаемое проектное решение. Средства ARIS покрывают решение следующей части задачи:

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

♦ стандартные процедуры финансового, стоимостного, временного и других видов анализа «маршрута».

По этой причине исполнителю необходимо самостоятельно разрабатывать ряд программных модулей – скриптов, которые позволяют:

♦ «выделить» из среды ARIS уникальный маршрут;

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

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

♦ интерактивный режим задания параметров входных условий;

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

♦ цветовое выделение «маршрута» на фоне общей модели;

♦ сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры;

♦ интерактивный режим навигации по сохраненной (измененной) модели маршрута.

Группа прикладных функций аналитической обработки «маршрута»:

♦ технологическая карта;

♦ специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов.

Группа прикладных функций выделения «маршрута»:

♦ интерактивный режим задания параметров входных условий.

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

На модели верхнего уровня формируется функция, с ней ассоциируется набор подмоделей, реализующих специфический функционал (рис. 10).

Рис. 10

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