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

3. Проставление штампа «Выпуск разрешен» и соответствующей записи и ЛНП.

4. Проставление штампа «Выпуск запрещен» и соответствующей записи, ЛНП в правом верхнем углу заявления.

5. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи, ЛНП в правом верхнем углу контрольного экземпляра документа.

6. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.

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

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

Подобное копирование можно производить или вручную, или при помощи механизма Variants. Однако если модели копируются как Copies occunrence, то любые изменения объектов этих новых моделей автоматически приводят к изменениям occurences этих объектов на моделях-источниках, что далеко не всегда то, что нужно пользователю.

Как правило, модели копируются пользователями как Copies definitions, но в этом случае пропадают все связи объектов этих моделей и на новых моделях все связи приходится восстанавливать вручную, что очень затратно по времени и чревато ошибками.

Был создан скрипт, который, реализуя весь ранее уже описанный функционал, позволял вдобавок создавать в автоматическом режиме новую тестовую 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. Правда, надо признать, что ожидаемый эффект достигается лишь при условии, что исследуемые модели соответствующим образом подготовлены к анализу. Имеются в виду такие действия, как:

♦ приведение семантики модели в полное соответствие с требованиями методологии ARIS;

♦ удовлетворение условиям по количеству уровней вложенности моделей;

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

♦ создание дополнительных сервисных моделей, таких как, например, диаграммы событий, календари смен.

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