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

Был создан скрипт, который, реализуя весь ранее уже описанный функционал, позволял вдобавок создавать в автоматическом режиме новую тестовую Group, копии моделей, по которым «проходил».

На этих новых моделях отражались только те объекты и ветви, которые анализировались скриптом, и помечались цветом и уникальным последовательным номером. Объекты, которые не анализировались, не копировались на новую модель.

В итоге получалось нечто, похожее на приведенное на рис. 19.

Рис. 19

В процессе формирования новой модели проводился соответствующий анализ, состоявший в том, что:

♦если атрибуты объекта, число и тип связей, число и тип ассоциаций не изменялись, то на новой модели создавался новый occurence уже существующего объекта, при этом, естественно, сохранялись все уже существовавшие связи этого объекта, затем создавались новые occurences связей уже существующего объекта, аналогичные связям объекта – оригинала с модели-источника;

♦если же менялись атрибуты объекта, или число и тип связей, или число и тип ассоциаций, то:

– в новой группе создавался новый объект, аналогичный оригинальному, но уже со своим, специфицированным набором атрибутов;

– на новой модели создавался новый occurence объекта;

– затем создавались новые occurences связей нового объекта, аналогичные связям объекта – оригинала с модели-источника.

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

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

Скрипты из стандартной поставки ARIS многочисленны и позволяют производить довольно подробный анализ объектового состава моделей. При грамотном подходе эти скрипты – мощное подспорье для анализа моделей в руках умелого пользователя. Но они практически не позволяют пользователю делать произвольную группировку объектов нужной модели.

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

Одна из версий скрипта может формировать документ приведенной ниже структуры (табл. 9).

Это пример типового функционала формирования технологической карты.

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

Событие, связанное с появлением точки принятия решения, фиксируется в отчете строкой, содержащей текст сделанного выбора. Для каждой функции на помеченном пути поизводится анализ ее (функции) «окружения». Итогом этого анализа является помещение в отчет отсортированной информации по группам, указанным в примере заголовка отчета.

Также в отчет включается список моделей, пройденных при обходе. Этот же список сохраняется отдельно в текстовом файле. Информация из этого файла может быть использована другими – сервисными – скриптами, например для повторного обхода помеченного маршрута, сброса объектов пройденных моделей в исходное состояние – восстановление цветов объектов, сброс номеров пройденных функций, сброс сервисных атрибутов помеченного маршрута.

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

При формировании этого документа создается список должностей – объектов типа Position, присутствующих в базе. Этот список можно сформировать как скриптом, так и вручную, создав специальную модель (Должности) типа Organization Chat. Также создается список ролей – объектов типа Person Type, присутствующих в базе. Этот список тоже можно сформировать как скриптом, так и вручную, создав специальную модель (Роли) типа Organization Chat. Далее пользователю предлагается в интерактивном режиме выбрать одну должность и произвести назначение этой должности ролей из списка ролей. Это вполне логично, так как должность, в принципе, может выполнять несколько ролей. После этого производится анализ базы. Для каждой выбранной роли в цикле ищется функция-хозяин, строится список таких функций. После поиска список функций делается уникальным, чтобы исключить повторные вхождения одной функции, сортируется и выводится в отчет. Надо заметить, что рассмотренный скрипт формирует обобщенный список функций, выполняемых ролями данной должности, то есть без учета конкретного бизнес-процесса.

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

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

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

Стандартная конфигурация ARIS предоставляет в распоряжение пользователя очень богатый и функционально полный набор специализированных опций экономического анализа. Это ABC – Activity Based Cost Calculation, Balanced Scoreboard и Simulation. Правда, надо признать, что ожидаемый эффект достигается лишь при условии, что исследуемые модели соответствующим образом подготовлены к анализу. Имеются в виду такие действия, как: