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

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

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

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

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

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

Был создан скрипт, при помощи которого на базе многоуровневой модели создавались наборы «плоских» моделей.

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

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

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

♦решения по визуализации и настройкам;

♦проектные решения;

♦тестирование.

В рамках каждого из выделенных направлений рассмотрим следующие основные решения.

ARIS предлагает пользователю свой проводник (ARIS Explorer), дающий возможность доступа ко всем своим возможностям. Если баз в системе много и базы сложны по структуре, то только или разработчик, или высококвалифицированный эксперт сможет быстро сориентироваться в том объеме информации, который представлен на экране. Конечному пользователю, работающему с ограниченным, узко специализированным набором средств, такой объем информации не нужен (рис. 20, 21).

Рис. 20

Рис. 21

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

Рис. 22

Разработчики применили для этого концептуально понятный графический образ «домика ARIS», нагрузив его узнаваемые разделы специальным функционалом. Функционал связан с названием раздела – «комнаты» «домика ARIS». Способ доступа прост и применяем в любой модели ARIS – клик мышкой на пирамидке справа внизу от объекта или выбор в окне «Object Windows» на закладке «Assignments».

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

Разработчики проекта исходили из того соображения, что конкретная бизнес-функция реализуется не конкретным исполнителем Иванов – Петров – Сидоров, находящимся на конкретной должности, а некоторой организационной единицей, которая в одной организации – техник, в другой – инженер, в третьей – менеджер или еще кто-то. По мнению разработчиков, модель на этапе разработки не должна быть привязана к конкретной штатно-должностной структуре. По этой причине функционал, реализованный в модели, выполняет некую РОЛЬ, с которой может быть связана в последующем любая совокупность исполнителей и штатных структур. Связывание РОЛЬ – ДОЛЖНОСТЬ – ИСПОЛНИТЕЛЬ должно происходить отдельно от модели и никак не влиять на ее (модели) структуру и состав.

Подключение библиотек настроек организационно-технологической структуры

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

Рис. 23

Для связывания ролей с должностями и конкретными исполнителями применяется механизм создания организационной модели. Создается модель типа Organization Charts. Элементами ее становятся объекты типа Person Type (роли). Далее создается еще одна модель типа Organization Charts, на ней располагаются иерархически организованные объекты типа Organization Unit (подразделение) и Position (должность) (рис. 24).

Рис. 24

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

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