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

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

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

Как известно, Simulation при выполнении может проанализировать только те функции, которые имеют одну и только одну ассоциацию с моделью типа eEpc. Если ассоциаций больше, то процесс Simulation «зависает». Был разработан скрипт, который так корректирует структуру модели, что она (модель) удаляет лишние не нужные для бизнес-процесса связи, сохраняет связи с нужными для бизнес-процесса моделями и источниками данных. Этот скрипт применяется к группе, копируя в целевую группу все модели группы-источника, и дополнительно выполняет следующий функционал:

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

♦ в автоматическом режиме копирует модели группы как Copy Occurrences;

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

♦ при наличии таких функций:

– создается новое definition (определение) функции;

– атрибуты новой функции делаются такими же, как у функции-источника;

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

– создается новое occurrence (представление) новой функции;

– создаются новые occurrences (представления) связей между occurrence (представлением) новой функции и occurrences (представлениями) объектов, составляющих окружение функции-источника;

– удаляется «старое» occurrence функции на модели.

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

Такие группы моделей после соответствующей подготовки (назначения вероятностей событиям или формирования диаграмм событий, формирования дополнительных моделей, например графиков смен) можно оптимизировать Simulation или анализировать другими стандартными средствами ARIS (ABC или Balanced Scoreboard).

Формирование чувствительности документов

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

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

Например, значение атрибута документа Identifier= «DOC_NP_*» «делает» документ нормативным, а «DOC_OP_*» – оперативным. Добавление постфикса вместо символа «*» позволяет ввести дополнительную градацию. Например, «PSM» – это письма, а «LAW» – законы и т. д. На рис. 26, 27 приведены примеры применения такой практики к документам.

Рис. 26

Рис. 27

Для задания чувствительности документов к, например, типу товара, некоему режиму и типу транспорта происходит присвоение атрибутам документа «User attribute Text 1», «User attribute Text 2» и «User attribute Text 3» специальных значений, определенных в «Соглашении о моделировании» в соответствующей, также согласованной нотации. Пример применения этих соглашений приведен на рис. 28.

Рис. 28

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

Тестирование

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

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

Формирование случайных сочетаний параметров входных условий

При формировании входных параметров использовались случайным образом выбранные тип товара, некий режим, тип транспорта. В приложении 2 приведен пример кода, формирующего случайным образом тип транспорта. Это Function seltransrand() As String.

Формирование случайных сочетаний принимаемых бизнес-решений

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

Потоковое тестирование и анализ модели на основе случайно заданных параметров входных условий и чисел

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

Специализированные проверки составных элементов модели

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

Интеграционные решения

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

♦ форматов загрузки, выгрузки информации;

♦ использования специализированного функционала.

Стандартно ARIS предоставляет средства взаимодействия с другими CASE-средствами разработки и поддержки моделирования бизнес-процессов. Назначение этих средств – обмен отдельными моделями с другими программными CASE-системами посредством файлов, записанных в XML-кодах. Этот обмен осуществляется при помощи специальных программ-интерфейсов сторонних производителей, например компании Reischmann Informatik GmbH (RI) (www.reischmann.com). В настоящее время интерфейсы TOOLBUS компании RI поддерживают больше чем 30 инструментальных CASE-средств. Посредством этих интерфейсов можно произвести обмен данными между ARIS и такими CASE-си-стемами, как ErWin от СА, PowerDesigner от Sybase и OracleDesigner. Обмен может быть произведен в обоих направлениях.