 |
Цветовое выделение «маршрута» на фоне общей модели
|
|
|
|
В стандартном режиме ARIS позволяет просматривать модели любой группы, свойства модели и любого из ее объектов, менять свойства модели и любого из ее объектов. Журнал посещений моделей не ведется, поэтому запомнить путь, повторить просмотр, пометить как-то просмотренные модели и т. п. невозможно.
Для реализации подобного функционала создан скрипт, позволяющий в интерактивном режиме пройти по любой модели или группе моделей, сделать осознанный выбор альтернативного пути развития бизнес-процесса, пометить уже пройденный путь (выделить отличным от стандартного цветом пройденные объекты), получить журнал – список пройденных моделей. В процессе прохода по модели формируется подробный журнал, типа Технологической карты, в котором отмечаются все точки принятия решений, все пройденные функции, фиксируется окружение каждой пройденной функции.
Создан также скрипт, при помощи которого можно повторить обход модели, так как пройденные объекты на модели помечаются не только цветом, но и последовательным номером. Кроме того, этот скрипт использует навигационную информацию из журнала, созданного при первом проходе.
Создан также скрипт, который производит восстановление всех моделей из списка просмотренных до первоначального состояния – восстановление цветов, сброс номеров объектов, сброс других сервисных атрибутов моделей и объектов на них.
На рис. 18 приведен пример использования описанного скрипта, под ним – список моделей, пройденных скриптом за последний сеанс работы.
Рис. 18
Изменение цвета объекта и присвоение ему последовательного номера производятся путем назначения некоторым атрибутам объектов специальных значений.
|
|
|
Пример кода, реализующего этот функционал, приведен в приложении 2.
Это функции setfunnomer() и setcolor(). Список пройденных моделей:
1. Оформление запрещения выпуска товаров.
2. Проставление штампа «Выпуск запрещен» и соответствующей записи, подписи и ЛНП.
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).
В выходной документ попадают только те функции, хозяевами которых являются роли из списка, выбранные на первом этапе формирования документа ролей.
Он (скрипт) объединяет возможности как скрипта «должностная инструкция», так и скрипта «технологическая карта». Алгоритм формирования, вид и структура выходного документа практически аналогичны уже ранее рассмотренным.
|
|
|
