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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 10

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

Например: на модели (рис. 11) с функцией высокого уровня, выделенной черными квадратами, связан список подмоделей типа eEPC, каждая из которых реализует специфический функционал, определенный типом транспорта. Атрибут Identifier каждой подмодели имеет свое значение, разное в зависимости от, например, типа транспорта. Перед началом обхода модели высокого уровня при помощи скрипта последний формирует диалоговое окно, из которого пользователь может выбрать нужное значение, например вида транспорта, в зависимости от анализируемой версии бизнес-процесса. Выбранное значение запоминается в переменной. Значение переменной используется при выборе из списка ассоциированных с функцией подмоделей.

Рис. 11

В приложении 1 приведен пример кода функции seltrans (выбор вида транспорта).

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

В приложении 1 приведен пример кода функции getassmodpar (получить ассоциированную с текущей функцией подмодель с нужным видом транспорта).

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

При написании и отладке скриптов применялся встроенный в среду ARIS интерпретатор языка программирования Sax Basic, окно экранного редактора которого приведено на рис. 12.

Рис. 12

Для доступа к специфическим средствам языка – компонентам объектовой среды ARIS – применялись стандартные библиотеки ATARep.dll и ATDRepDb.dll среды ARIS (рис. 13).

Рис. 13

При помощи диалогового окна «ActiveX Automation Members» можно получить доступ как к средствам языка Sax Basic, так и к типам данных – объектам среды ARIS, информацию обо всех их свойствах (Properties) и методах, реализованных через процедуры (Sub) и функции (Function), о типе возвращаемого значения, количестве и типах параметров методов (рис. 14).

Рис. 14

При необходимости можно подключить другие библиотеки из опубликованного в системном реестре набора dll-ресурсов. Доступ к этой возможности предоставляется через опцию Tools/Referenses… окна экранного редактора среды ARIS (рис. 15).

Рис. 15

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

В штатном режиме среда ARIS предоставляет стандартные возможности навигации, состоящие в ручном прохождении по моделям путем или выбора имени модели из окна Explorer, или – на модели – выделения функции, имеющей ассоциации с другими подмоделями, выбора ассоциированной подмодели из списка закладки Assignments окна просмотра модели. В этих случаях можно увидеть модель и ее объекты, просмотреть свойства модели и ее объектов, можно изменить модель и любое из ее свойств, изменить любой объект и любое из его свойств. Формирование статистики обхода или любое документирование воздействий невозможно. При помощи специально написанного скрипта можно:

? произвести фиксацию «следа», «тропы», по которой происходил обход моделей;

? получить возможность интерактивного режима принятия бизнес-решений;

? получить подробный протокол обхода;

? получить новые модели, на которых отражены только те объекты, которые были использованы при обходе исходных моделей.

Список сервисного функционала может быть значительно расширен в зависимости от бизнес-потребностей заказчика и возможностей разработчика.

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

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

? модель, являющаяся детализацией, начинается и заканчивается событием;

? интерфейсный процесс с детализацией вначале ссылается на модель-предшественник;

? интерфейсный процесс с детализацией в конце ссылается на модель-последователь;

? если модели связаны через интерфейсные процессы, то должна выполняться дисциплина: на модели-источнике – событие 1, интерфейсный процесс 1, ссылающийся на модель-приемник, на модели-приемнике – интерфейсный процесс 1, но ссылающийся на модель-источник, затем событие 1;

? интерфейсный процесс без детализации в конце завершает процесс и обход.

Последовательное применение таких соглашений облегчит навигацию и понимание связей между моделями.

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

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

Рис. 16

Если в процессе обхода модели встречается правило, то сначала анализируется его тип.

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

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

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

Дисциплина доступа к стеку: последним вошел – первым вышел (LIFO).

Стек может быть организован несколькими способами.

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

Если надо хранить один параметр для каждого объекта, может подойти или одномерный массив вариантного типа, или список. Список в этом случае более предпочтителен.

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

На рис. 17 приведен пример выбора альтернативной ветви процесса для правила XOR.

Рис. 17

В приложении 1 приведен пример кода, реализующего этот функционал. Это процедура XOROpen. Строки диалогового окна формируются при помощи функции Getname(), код которой также приведен в приложении 1.

Оглавление книги