1

Система межведомственного электронного взаимодействия

РАЗРАБОТКА МОДЕЛИ ПРОЦЕССА ОКАЗАНИЯ УСЛУГИ В ARIS BUSINESS ARCHITECT 7.1

(ARIS BUSINESS DESIGNER 7.1)

Методические указания по моделированию процессов межведомственного взаимодействия

Уфа 2011

2

Составители: П.И. Навалихин, Н.Д. Торопова.

УДК ББК

Разработка модели оказания услуги в ARIS Business Architect 7.1 (ARIS Business Designer 7.1): Методические указания по моделированию процессов межведомственного взаимодействия /ООО «Организационно-технологические решения 2000»; Сост.: П.И. Навалихин, Н.Д. Торопова. – Уфа, 2011. - ___ с.

Направлены на закрепление теоретических знаний по моделированию бизнес-процессов и информационных систем, приобретение практических навыков создания модели оказания услуги с использованием программного продукта ARIS Business Architect 7.1 (ARIS Business Designer 7.1). Рассматривается последовательность построения модели, начиная с диаграммы процессов, где создается новая модель предметной области, до разработки отчетов на основе модели средствами ARIS Business Architect 7.1 (ARIS Business Designer 7.1).

Методические указания предназначены для подготовки специалистов по моделированию процессов оказания услуг на проекте Межведомственное взаимодействие.

Табл.: _ Ил.: __ Библиогр.: _ Рецензенты: ________________________ ________________________

© ООО «Организационно-технологические решения 2000», 2011

3

СОДЕРЖАНИЕ

Введение......................................................................................................................... 4 1. Выбор нотации моделирования и программного обеспечения………….4

1.1. Выбор нотации моделирования……………………………………....4 1.2. Выбор программного обеспечения…………………………………..5

2. Общие сведения о моделировании процессов межведомственного взаимодействия………………………………………………………………..5

2.1. Порядок разработки пакета моделей по услуге………………………...5 2.2. Пакет документов, необходимый для моделирования услуг........…6 2.3. Правила моделирования в нотации BPMN……………………….…6 2.4. Использование основных категорий элементов на примере

моделирования в ARIS Business Architect 7.1 (ARIS Business Designer)......7 2.5 Основные компоненты модели…………………………………....….7

3. Методика моделирования процессов межведомственного взаимодействия………………………………………………………………10

3.1 Создание и настройка нового проекта моделирования……………10 3.2 Создание диаграммы процесса………………………………………11

Список использованных источников ................................................................... 23

4

ВВЕДЕНИЕ

Методика межведомственного взаимодействия предполагает проведение следующих основных работ на проекте: - письменное оповещение ведомств – потребителей1 о проведении работ; - сбор информации по услугам; - составление описания процессов2, перечня документов по услугам и технологической карты межведомственного взаимодействия (далее ТКМВ); - согласование документов с ведомством-потребителем информации и поставщиками3; - разработка формализованного описания процессов оказания услуг (далее моделирование процесса (услуги)); - разработка прототипа регламента на основе моделей (по требованию заказчика). 1. Выбор нотации и программного обеспечения

Критичным является выбор цели моделирования. В данном случае необходимо совместить 2 цели: прозрачное моделирование межведомственного взаимодействия и разработку вербальной модели административных регламентов на основе изменения модели услуги.

1.1. Выбор нотации моделирования

В процессе обследования рынка нотаций моделирования на основе конкретных задач был выделен следующий перечень наиболее подходящих из них: SADT, BPMN и EPC нотации. Из перечисленных, SADT и EPC нотации не удовлетворили требуемой наглядности диаграмм.

1 Ведомство-потребитель - орган власти, ответственный за предоставление услуги и запрашивающий данные, необходимые для предоставления услуги, у других ведомств

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

3 Ведомство-поставщик - ведомство, располагающее сведениями, необходимыми для предоставления услуги, и обеспечивающее их предоставление Потребителю данных по запросу в соответствии с 210-ФЗ

5

Не исключено, что такие нотации как, например, UML и другие (не рассмотренные выше), в результате анализа были бы не менее эффективны, однако в требованиях заказчика был ограничен выбор «из».

Нотация BPMN полностью удовлетворяет требованиям заказчика по следующим критериям: - прозрачность модели; - визуализация межведомственного взаимодействия (в разрезе использования пулов и дорожек); -возможность вывода отчетов по трудозатратам на оказание услуги. Дополнительным требованием заказчика к моделям может являться обеспечение возможности автоматической генерации Административных регламентов на основе разработанных диаграмм4.

1.2 Выбор программного обеспечения

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

Итого максимально приемлемым ПО в соответствии с требованиями заказчика (пилотный проект г.Уфа) было выбрано программное средство ARIS (с учетом использования иных возможностей продукта) и принято решение о доработке мастера отчетов с использованием языка JavaScript

2. Методика моделирования процессов межведомственного взаимодействия

Так как моделирование бизнес-процесса позволяет наглядно отразить ход работ по оказанию услуги, а так же дает возможность оценить процесс оказания услуги на наличие прямых или косвенных противоречий с НПА и нормами 210-ФЗ предлагается проводить моделирование процесса параллельно с разработкой ТКМВ

2.1 Порядок разработки пакета моделей по услуге

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

6

Порядок разработки пакета моделей по услуге: 1) на основе Административного регламента и описания процедуры составить прототип модели существующего процесса оказания услуги; 2) провести согласование прототипа модели существующего процесса с ведомством-потребителем, выделить противоречия с НПА и нормами ФЗ №210; 3) разработать ТКМВ по услуге согласно выделенным в модели подуслугам; 4) доработать модель существующего процесса в соответствии с ТКМВ; 5) разработать модель предлагаемого процесса с вводом/расширением межведомственного взаимодействия на основе ТКМВ; 6) провести согласование модели предлагаемого процесса с ведомством-потребителем; 7) подписать лист согласования. Ориентировочное время на разработку пакета документов по моделированию одной услуги средней сложности 3 дня5 (при наличии всей необходимой информации).

2.2 Пакет документов, необходимый для моделирования услуг

Пакет документов, необходимый для моделирования услуг: - документ «Соглашение о моделировании»6; - Административный регламент по оказанию услуги, нормативно-правовые акты (далее НПА) и Описание процедуры; - прототип ТКМВ. Все данные, необходимые для построения модели должны содержаться в предоставленных документах.

2.3 Правила моделирования в нотации BPMN

Нотация по моделированию бизнес-процессов (The Business Process Modeling Notation, BPMN) - это стандарт для моделирования бизнес-процессов и сетевых услуг, который впервые был выпущен в мае 2004 года. Руководство-спецификация представляет собой более чем двухлетние усилия BPMI Notation Working Group.

Конечный результат BPMN составляет диаграмма бизнес-процесса (Business Process Diagram, BPD), отображающая поток работ в виде отдельных шагов и задач, основанный на стандартах графической нотации. В диаграмму могут входить условия, от которых зависит выбор тех или иных операций и другие объекты.

5 Трудозатраты на разработку одной модели находятся на этапе расчета и согласования

6 Документ "Соглашение по моделированию" - описание принципов, правил проведения работ и взаимодействия между сотрудниками по разработке бизнес-модели оказания услуг

7

Выделяют четыре основные категории элементов, размещаемых на BPM - диаграммах: - объекты потока управления (Flow Objects): события, действия и логические операторы; - соединяющие объекты (Connecting Objects): поток управления, поток сообщений и ассоциации; - роли или зоны ответственности (Swimlanes): пулы и дорожки; - артефакты (Artifacts): данные, группы и текстовые аннотации. 2.4 Использование основных категорий элементов на примере моделирования в ARIS Business Architect 7.1 (ARIS Business Designer 7.1)

Программный продукт ARIS Business Architect 7.1 поддерживает нотацию BPMN 2.0. Он предназначен для создания моделей бизнес-процессов, их документирования и анализа. Данный инструмент имеет удобный и понятный интерфейс для создания моделей.

Одним из преимуществ ARIS является возможность указания трудозатрат (временных и денежных затрат) в разных единицах измерения; при создании модели можно распределять роли.

Возможность проверки модели – одно из достоинств ARIS. Данная функция позволяет легко найти недочеты модели и привести составленную модель в соответствие элементарным требованиям нотации BPMN 2.0. Однако, данная проверка, не может отвечать требованиям контроля на соответствие регламентам процесса и проверке на смысловую нагрузку модели процесса.

2.5 Основные компоненты модели

Определим основные компоненты, необходимые для отражения в модели применительно к проекту СМЭВ: 1) участники процесса (ведомства-потребители и ведомства-поставщики информации), отражаемые в рамках модели как роли (зоны ответственности) - пулы и дорожки; 2) подуслуги7 и их детализация, отражаемые в рамках модели как объекты потока управления: события, действия и логические операторы; 3) документы и другие потоки информации, отражаемые в рамках модели как соединяющие объекты: поток управления, поток сообщений и ассоциации; 4) трудозатраты, группы задач и иные характеристики процесса, отражаемые в рамках модели как артефакты: данные, группы и текстовые аннотации. Рассмотрим подробнее каждый из пунктов.

1) Участники процесса (ведомства-потребители и поставщики информации), отражаемые в рамках модели как роли (зоны ответственности) - пулы и дорожки

7 Подуслуга - сценарий предоставления услуги, характеризуемый уникальными требованиями к заявителю и/или составом пакета «входных» документов и/или результатом предоставления услуги

8

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

В BPMN для этого предназначены специальные элементы – пулы и дорожки.

Для того чтобы создать пулы и дорожки на диаграмме, необходимо в административном регламенте выделить ведомства, участвующие в предоставлении услуги. Такая информация обычно представлена в разделе регламента «Наименование государственного органа, предоставляющего государственную услугу» или в пунктах, отвечающих за описание взаимодействия ведомства-потребителя с территориальными органами федеральных органов исполнительной власти. Так же информация о ведомствах, участвующих в предоставлении услуги отражается в ТКМВ на вкладке «Общие сведения», которая должна быть полностью идентична представленному в модели взаимодействию. 2) Подуслуги и их детализация, отражаемые в рамках модели как объекты потока управления: события, действия и логические операторы

2.1) Степень детализации модели полностью зависит от целей моделирования, которые, как и иные аспекты моделирования, должны быть оглашены и согласованны с заказчиком в рамках документа «Соглашение о моделировании», где расписывается подробно, как и какими средствами будут описываться моделируемые процессы (услуги). Таким образом, если целью моделирования является не более чем схема, отображающая взаимодействие заявителя и ведомств в процессе оказания первому услуги, то, возможно, будет достаточно отображения участников процесса, основных вех (обобщенных задач) каждого их них, трудозатрат на процесс и документов, таких как пакет документов заявителя и, отдельно, документов, подготовленных для перевода на межведомственное взаимодействие. Однако, в случае, если на основе модели процесса оказания услуги планируется разработка регламента процесса, то модель процесса приобретает совершенно иной вид. В этом случае необходимо максимально отразить на модели всю собранную информацию согласно постановлению Правительства РФ от 16 мая 2011 г. N 373 "О разработке и утверждении административных регламентов исполнения государственных функций и административных регламентов предоставления государственных услуг"9.

8 В рамках проекта СМЭВ разбивка задач по ролям, таким как заявитель, ведомство-потребитель и ведомства-поставщики данных, является основополагающим критерием выбора как нотации моделирования в целом, так и способа размещения задач на диаграмме

9 Постановление Правительства РФ от 16 мая 2011 г. №373 http://www.consultant.ru/online/base/?req=doc;base=LAW;n=114205

9

В целях разгрузки модели возможно использование свернутых пулов, групп в пуле/дорожке и подпроцессов. Однако, данные элементы модели не всегда удобны в использовании и, как правило, только отягощают чтение модели применительно к проекту СМЭВ. 2.2) Отображение задач на диаграмме процесса

Для отображения задач на диаграмме процесса необходимо: - выделить в Административном регламенте (Описании процедуры) основные действия (этапы), необходимые для оказания услуги ведомствами и действия заявителя; - разместить задачи на диаграмме процесса в соответствии с выделенными в ТКМВ подуслугами и ответственными исполнителями каждой из задач (действия). В соответствии с возможными вариантами выполнения той или иной задачи в модели применяются такие объекты, как события разных видов и логические операторы (см. нотация BPMN10).

3) Документы и другие потоки информации, отражаемые в рамках модели как соединяющие объекты: поток управления, поток сообщений и ассоциации

Последовательность и параллельность выполнения задач достигается соединением действий (задач) потоками управления, которые показывают порядок выполнения действия. Однако, потоки управления применяются только в рамках одного пула.

Взаимодействие между пулами возможно только посредством использования потока документов, сообщений и ассоциаций.

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

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

Важно отметить, что нотация моделирования BPMN не диктует жесткой привязки того или иного вербального объекта к тому или иному объекту структурному.

10 Нотация BPMN 1.1 http://khpi-iip.mipk.kharkiv.edu/library/sotii/labs/BPMN_Info/

10

3. Методика моделирования процессов межведомственного взаимодействия

Рассмотрим построение модели процесса межведомственного взаимодействия в нотации BPMN с использованием продукта Aris Business Architect 7.1.

3.1 Создание и настройка нового проекта моделирования

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

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

3.1.3 При необходимости создайте новую группу (папку) для хранения модели (кнопка «Новая группа…»). После выбора нажимаем кнопку «Далее».

3.1.4 На следующей форме выберите тип и назначение модели. Выберите пункт Диаграмма процессов BPMN (2.0 Beta) (в разных версиях продукта – разные версии аннотации, выбираем наиболее подходящую).

3.1.5 На этой же форме введите имя модели.

11

3.1.6 После ввода имени активируется кнопка «Закончить» – нажмите ее.

3.2 Создание диаграммы процесса

Рассмотрим основные объекты нотации BPMN на примере описания процесса предоставлении консультации по услуге «Лицензирование образовательной деятельности образовательных учреждений, расположенных на территории Республики Башкортостан (за исключением образовательных учреждений, лицензирование образовательной деятельности которых относится к полномочиям федеральных органов государственной власти), лицензирование образовательной деятельности организаций, которые расположены на территории Республики Башкортостан, и структурные подразделения которых осуществляют реализацию программ профессиональной подготовки».

3.2.1 Продукты Aris Platform имеют удобную настраиваемую панель отображения модулей, для изменения набора отображаемых модулей достаточно поставить или убрать галку напротив соответствующего пункта панели.

3.2.2 Для добавления объектов в Aris Platform существует панель Символов. Одинарным щелчком выбираем объект и размещаем его на рабочей области модели.

12

3.2.3 Для начала работы необходимо определить пулы и дорожки модели. Применительно к проекту СМЭВ: пулы - это стороны, взаимодействующие в рамках услуги (министерства, ведомства, заявитель), а дорожки это ответственные исполнители (роли) внутри отдельного пула.

1) добавим пул заявителя и пул ведомства на модель. В русифицированной версии Aris Pool-ом называется объект Полоса

2) при добавлении пула необходимо задать ему соответствующее имя

3) в каждом пуле может быть несколько дорожек. Добавлять дорожки можно двумя способами:

3.1) добавьте объект Полоса в границы уже существующего пула (рис. 1)

13

рис. 1

3.2) щелкните правой кнопкой по целевому пулу и выберите пункт BPMN – Добавить новую полосу, в открывшейся форме введите необходимое количество полос (рис.2), либо нажмите кнопку в левом верхнем углу пула при его выделении (рис.3).

рис. 2

рис. 3

Заметим, что удобнее использовать 2ой способ, потому как при перетаскивании третьей полосы в пул с 2мя полосами, новая полоса может добавиться внутрь одной из 2-х уже существующих полос, а не встать рядом с ними (как показано на рис. 4).

14

рис. 4

4) при добавлении полос внутрь пула каждая также именуются. Добавим и назовем все необходимые пулы.

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

3.2.4 Основные объекты Aris Platform в нотации BPMN.

Объекты Aris Platform представлены в панели символов на рабочей области модели

Начальное событие – событие определяющее старт любого процесса.

Обозначает конец какого-либо процесса на модели.

Промежуточное событие

Действие (задача) – отражает действие (процесс), осуществляемое ответственным лицом.

Подпроцесс это составное действие, т.е. действие состоящее из нескольких.

Использование данного объекта в рамках СМЭВ нежелательно, т.к. приводит к утяжелению и нечитабельности модели.

Шлюз (логический оператор) – объект управления потоками данных.

15

Объект данных – данные в виде документа, журнала, реестра и т.п.

Хранилище данных – совокупность данных (база данных, архив документов)

Группа – инструмент для объединения нескольких объектов по какому-либо признаку.

Связь – объект связывающий объекты и определяющий последовательность их выполнения.

Текстовое примечание.

Рассмотрим наиболее часто используемые типы объектов более подробно. Вне зависимости от того начальное, конечное или промежуточное событие его тип может быть:

Получение и отправка сообщений.

Событие таймера – Регулярные события, моменты времени, временные периоды и таймауты. Зачастую событие таймера подразумевает ожидание выполнения какого-либо действия (группы дейсвтий).

Событие ошибки – генерация и обработка ошибок. Активируется при наличии ошибки в действии (промежуточное событие). Окончанием процесса является ошибка (для конечного события).

Событие прерывания - Вызывает немедленное завершение всего процесса.

Основные типы шлюзов:

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

Оператор И. При разделении на параллельные потоки, все ветви активируются одновременно. При синхронизации параллельных ветвей оператор ждет завершения всех входящих ветвей и затем активирует выходной поток.

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

16

Типы действий (задач):

Задача получения – отражает процесс получения чего-либо.

Задача отправки – отражает процесс отправки чего-либо.

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

Тип объектов данных:

Ввод данных

Вывод данных

3.2.5 Работа с объектами и атрибутами объектов

Некоторые удобности и особенности: - при добавлении объекта на рабочую область модели справа появляется меню для выбора типа объекта – так можно быстро выбрать тип; - после именования объекта при одинарном щелчке на него появляется меню выбора следующего объекта модели, если добавить любой объект – предыдущий свяжется с ним автоматически; - для изменения типа объекта необходимо кликнуть на нем правой кнопкой мыши, выбрать пункт меню BPMN и указать нужный тип.

3.2.6 Атрибуты объекта

Каждый объект Aris Platform имеет набор атрибутов, как то: Имя, Описание, Время и т.п. Для каждого объекта набор атрибутов свой.

17

1) для Добавления/Изменения значений атрибутов необходимо: - щелкнуть правой клавишей на объекте и выбрать пункт Свойства, или же вызвать свойства сочетанием клавиш Alt + Enter; - появившейся форме выбрать пункт Атрибуты; - здесь можно добавлять атрибуты (кнопка «Больше атрибутов») и изменять значение атрибутов (ввести значения в правую часть, напротив имени атрибута)

2) в форме «Свойства» существует возможность определить расположение отображения атрибутов относительно объекта, которому атрибут принадлежит. За это отвечает пункт свойств «Расположение атрибутов (объекты)». Здесь можно добавлять отображаемые на модели атрибуты объекта и указывать их расположение путем установки галочки в нужном месте относительно объекта, как показано на рисунке ниже.

Также размещение отображаемых атрибутов можно регулировать перетаскиванием мышки уже после размещения объекта в рабочей области.

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

18

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

3.2.7 Размещение событий и задач на диаграмме процесса

Напомним, что рассматривается процесс предоставление консультации.

Итак, в нашем примере 2 пула – «Соискатель» и «Управление по контролю и надзору в сфере образования Республики Башкортостан».

1) рассмотрим пул Соискатель

1.1) каждый процесс имеет начальное событие.

Начальным событием для соискателя является «Возникновение потребности в получении консультации». Обозначим его.

1.2) соискатель может обратиться за консультацией в Управление 3мя способами: по телефону, лично и в письменной форме. Отразим это на модели.

Разделим поток на три с помощью Шлюза Исключающего ИЛИ (т.к. поток может идти только по одному из трех путей) и добавляем 3 действия – каждый для своего типа обращения.

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

Если дополнительной информации не требуется, то соискатель, в случаях обращения по телефону и лично, получает консультацию – процесс в пуле соискателя завершается. Обращение отражаются на модели объектами «Событие». Т.к. итог у обращений по телефону и лично один, объединяем потоки шлюзом и завершаем процесс (используем шлюз исключающего ИЛИ, так как выполняется либо одно, либо другое действие).

Отразим описанный процесс на модели.

19

1.4) в случае письменного обращения соискатель направляет письмо в адрес Управления, после чего ждет ответа в течение 30 дней. Письмо отражается в виде объекта данных и соединяется с Действием в пуле Соискатель и с действием в пуле Управление.

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

Отразим вышеописанное в пуле соискателя.

2) перейдем к пулу Управление Обрнадзора.

2.1) выделим ответственных, участвующих в услуге – это Начальник Обрнадзора и Отдел лицензирования и аккредитации.

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

Создадим действие Прием обращения (задача получения), далее поток делится на 2 – Ответ устный и Ответ письменный.

20

Отметим на дорожке Начальника Обрнадзора получение письма для согласования и действие согласования письма.

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

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

2.3) сотрудник отдела лицензирования при необходимости оповещает соискателя об увеличении срока реакции. Получает согласованный ответ от Начальника Обрнадзора и, наконец, отправляет письменный согласованный ответ соискателю.

На модели в дорожке Отдела лицензирования поток делим на 2 (если необходимы доп. проверки и если такой необходимости нет), добавим все вышеописанные действия Отдела лицензирования для каждого из потоков.

2.4) начальник Обрнадзора в свою очередь при необходимости делает дополнительные проверки по обращению соискателя и согласовывает ответ.

Добавим действия Доп. проверки и Согласование к ветке события Ошибка.

На этом процессы Управления заканчиваются.

2.5) конечный вариант пула Управление должен выглядеть следующим образом:

21

3) отразим связи между Действиями и Событиями разных пулов: Соискатель и Управление Обрнадзора. Также отметим все Объекты данных. Конечная схемы будет выглядеть следующим образом:

3.2.8 В Aris Business Architect 7.1. существует удобный инструмент для семантической проверки модели на наличие ошибок. При его использовании система отмечает все ошибочные места в модели с комментариями к ним. Для такой проверки необходимо нажать кнопку «Выполнить семантическую проверку BPMN» на панели инструментов.

22

Один из вариантов результата проверки представлен на рисунке ниже.

3.2.9 Aris Business Architect 7.1. позволяет формировать ряд стандартных преднастроенных отчетов по моделям. Для формирования такого отчета необходимо: - выбрать пункт меню Обработка – Запустить отчет; - в появившейся форме выбрать подходящий отчет и нажать Далее;

- затем выбрать параметры вывода отчета и нажать кнопку Закончить.

Отчет выводится в формате PDF.

23

Список использованных источников

1.

2.

3.

24

Составители: НАВАЛИХИН ПАВЕЛ ИВАНОВИЧ ТОРОПОВА НАДЕЖДА ДМИТРИЕВНА

РАЗРАБОТКА МОДЕЛИ ПРОЦЕССА ОКАЗАНИЯ УСЛУГИ В ARIS BUSINESS ARCHITECT 7.1 (ARIS BUSINESS DESIGNER 7.1)

Методические указания по моделированию процессов межведомственного взаимодействия

Подписано в печать хх.хх.2011. Формат 60х84 1/16. Бумага офсетная. Печать плоская. Гарнитура Таймс. Усл. печ. л. 3,1 . Усл. кр. – отт. 3,1 . Уч. – изд. л. 3,0 .

Тираж 100 экз. Заказ № _______________________________________________________________________________________________________________________________

Центр оперативной полиграфии ________________________________________________________________