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

Равно как и для прикладного функционала, в ряде случаев общесистемный функционал среды 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 (роль). Мы получаем модель, определяющую зависимость подразделение – его должностной состав, а для каждой должности – ее исполнителя и список обязанностей (ролей), которые исполнитель по решению или кадровых органов, или менеджера по прикладному функционалу должен выполнять.