3.1 DSM и DSL

DSM-платформы (Domain Specific Modeling), как правило направлены на создание высокоуровневых предметно-ориентированных языков или DSL (Domain Specific Language). При этом DSM используются для реализации мультиязыковых систем, а DSL для создания моделей, способных решать задачи разного спектра направления, с возможностью ориентироваться на компетентность конечного пользователя. Необходимо отметить, что первым этапом, при создании предметно-ориентированного языка, определяется синтаксис в терминах языка реализации, далее с помощью имеющихся паттернов происходит реализация нового DSL, и использование средств метамоделирования для реализации в рамках базового языка.

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

Однако, при создании DSM - платформ, необходимо учитывать ряд поставленных требований:

- Гибкость в выборе областей применения в построении языков моделирования.

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

- Возможность исполнения мультиязыкового и многоуровневого моделирования.

- Возможность динамического изменения языков.

- Возможность экспорта и импорта.

При этом, главным требованием отмечается - доступность в использовании для всех категорий пользователей [19].

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



3.2 MetaLanguage

MetaLanguage - это инструментальное средство, созданное с целью решения поставленных задач [18][19]. Данная система позволяет разрабатывать новые языки моделирования и выполнять их трансформацию. Ключевыми достоинствами выделяют:

- Гибкость изменения настроек языка.

- Возможность использовать существующий DSL в схожих задачах.

- Сохранение терминов и определений источников.

- Возможность внедрения нескольких языков. [20]

Первым шагом, направленным на создание нового языка - является построение его модели. Она реализовывается при помощи метаязыка, как было упомянуто ранее, благодаря ему пользователь в дальнейшем может вносить изменения или создавать новые языки. Поэтому, при разработке DSL в Metalanguage, сначала разрабатывается новый предметно-ориентированный язык моделирования, который послужит основой для разработки моделей, с помощью которых будет решаться ряд поставленных задач. [21]

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

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

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

3.3 Общая схема процесса трансформации моделей

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

Под метамоделями принято принимать такие модели, которые описывают конструкцию нотации или взаимосвязь между элементами и их атрибутами.

Для описания правил трансформации производится сопоставление элементов исходной и целевой метамодели. В рамках данной работы трансформация будет произведена на бизнес-процессе проведения государственной закупки в нотации BPMN в метамодель сетей Петри.

3.4 Метамодель языка BPMN, дополненная угрозами

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

Таблица 3.1- Сущности метамодели языка BPMN

Сущность	Атрибут	Тип данных атрибута
СтартПроцесса	Имя	Строковый
Пул	Имя	Строковый
Дорожка	Имя	Строковый
Задача	Имя	Строковый
	ТипЗадачи	Строковый
Развилка	Тип	Строковый
ОбъектДанных	Имя	Строковый
ХранилищеДанных	Имя	Строковый
Артефакт	Имя	Строковый
	Тип	Строковый
Событие	Тип	Строковый
Завершение	Имя	Строковый
Угроза	Имя	Строковый

Следующим шагом опишем связи между существующими сущностями. (табл. 3.2).

Таблица 3.2. Связи между сущностями метамодели языка BPMN, дополненного угрозами

Связь	Тип связи	Направление
СтартПроцесса_Задача	Ассоциация	Однонаправленная
СтартПроцесса_Развилка	Ассоциация	Однонаправленная
Пул_Дорожка	Агрегация	Однонаправленная
Пул_Событие	Агрегация	Однонаправленная
Дорожка_Задача	Агрегация	Однонаправленная
Задача_Развилка	Ассоциация	Однонаправленная
Задача_Задача	Ассоциация	Однонаправленная
Развилка_Развилка	Ассоциация	Однонаправленная
Развилка_Завершение	Ассоциация	Однонаправленная
Задача_ОбъектДанных	Ассоциация	Однонаправленная
ХранилищеДанных_Задача	Ассоциация	Однонаправленная
Артефакт_Задача	Ассоциация	Однонаправленная
Событие_Задача	Ассоциация	Однонаправленная
Событие_Завершение	Ассоциация	Однонаправленная
Событие_Развилка	Ассоциация	Однонаправленная
Угроза_Задача	Ассоциация	Однонаправленная
Задача_Завершение	Ассоциация	Однонаправленная

Для наглядного представления связей между сущностями была построена матрица связей между сущностями метамодели [18]. (см. табл. 3.3). В матрице элементы строки считаются «выходными», а элементы столбцов - «входными»

Таблица 3.3 Матрица связей между сущностями метамодели языка BPMN, дополненного угрозами

Сущность

СтартПроцесса

Пул

Дорожка

Задача

Развилка

ОбъектДанных

ХранилищеДанных

Артефакт

Событие

Завершение

Угроза

СтартПроцесса

-

+

-

+

+

-

-

-

-

-

-

Пул

-

-

+

-

-

-

-

-

+

-

-

Дорожка

-

-

-

+

-

-

-

-

-

-

-

Задача

-

-

-

+

+

+

-

-

-

+

-

Развилка

-

-

-

+

+

-

-

-

-

+

-

ОбъектДанных

-

-

-

-

-

-

-

-

-

-

-

ХранилищеДанных

-

-

-

+

-

-

-

-

-

-

-

Артефакт

-

-

-

+

-

-

-

-

-

-

-

Событие

-

-

-

+

+

-

-

-

-

+

-

Завершение

-

-

-

-

-

-

-

-

-

-

-

Угроза

-

-

-

+

-

-

-

-

-

-

-

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

После того как были рассмотрены сущности и их связи, можно построить метамодель языка BPMN (рис. 3.1).



Рисунок 3.1- Метамодель языка BPMN, дополненная угрозами

С помощью построенной метамодели можно реализовать модели интересующего нас бизнес-процесса - проведение государственных закупок (см. рис. 3.2).

Рисунок 3.2-Бизнес-процесс проведения государственных закупок на основе построенной метамодели BPMN, дополненной угрозами



3.5 Метамодель сетей Петри

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

Все сущности метамодели языка сетей Петри представлены ниже в таблице (табл. 3.4).

Таблица 3.4 - Основные сущности метамодели языка сети Петри

Сущность	Атрибут	Тип данных атрибута
Позиция	Имя	Строковый
Переход	Имя	Строковый
Маркер	Позиция	Строковый

В таблице ниже представлены все возможные связи между имеющимися сущностями (3.5).

Таблица 3.5 - Связи между сущностями метамодели языка сети Петри

Связь	Тип связи	Направление
Позиция_Переход	Потоковая	Однонаправленная
Переход_Позиция	Потоковая	Однонаправленная
Переход_Переход	Потоковая	Однонаправленная
Маркер_Позиция	Агрегация	Однонаправленная

После того, как основные шаги по реализации метамодели языка выполнены - можно приступить к ее реализации. Ниже представлена метамодель языка сетей Петри (см. рис. 3.3).

Рисунок 3.3-Метамодель языка сети Петри



Используя построенную метамодель, была построена построена модель бизнес-процесса проведения государственных закупок на сетях Петри. На рисунке 3.4 изображено начало бизнес-процесса, на рисунке 3.5 - середина и на рисунке 3.6 завершающие этапы процесса проведения государственных закупок.

Рисунок 3.4-Начало бизнес-процесса проведения государственных закупок на основе построенной метамодели сети Петри

Рисунок 3.5-Середина бизнес-процесса проведения государственных закупок на основе построенной метамодели сети Петри



Рисунок 3.6 -Конец бизнес-процесса проведения государственных закупок на основе построенной метамодели сети Петри

3.6 Правила трансформации моделей

Так как одной из задач является трансформация бизнес-процесса из BPMN в сети Петри - необходимо не только произвести построение метамоделей языков, но и обозначить правила, которые необходимо соблюдать.

В таблице ниже представлены правила трансформации из BPMN в сети Петри (табл. 3.7).

Таблица 3.7- Правила трансформации нотации BPMN, дополненной угрозами в сети Петри

Название правила	Левая часть правила	Правая часть правила
Сущность
СтартПроцесса_Позиция	СтартПроцесса	Позиция
Дорожка_Маркер	Дорожка	Маркер
Задача_ПозицияПереходПозиция	Задача	ПозицияПереходПозиция
Название правила	Левая часть правила	Правая часть правила
Событие_Переход	Событие	Переход
Завершение_Позиция	Завершение	Позиция
Угроза_Ловушка	Угроза	Ловушка
Артефакт_условие	Артефакт	Условие
Связь
ЗадачаЗадача_ПозицияПереходПозицияПереходПозиция	ЗадачаЗадача	ПозицияПереходПозицияПереходПозиция
СтартПроцессаРазвилка_ПозицияПереходПозиция1Переход1Позиция2Переход1	СтартПроцессаРазвилка	ПозицияПереходПозиция1Переход1Позиция2Переход1
СтартПроцессаЗадача_ПозицияПереходПозицияПереходПозиция	СтартПроцессаЗадача	ПозицияПереходПозицияПерехожПозиция
ДорожкаЗадача_МаркерПозиция	ДорожкаЗадача	МаркерПозиция
ЗадачаЗавершение_ПозицияПереходПозицияПереходПозиция	ЗадачаЗавершение	ПозицияПереходПозицияПереходПозиция
СобытиеЗавершение_ПереходПозиция	СобытиеЗавершение	ПереходПозиция
СобытиеЗадача_ПереходПозицияПереходПозиция	СобытиеЗадача	ПереходПозицияПереходПозиция
СобытиеРазвилка_ПереходПозиция1Переход1Поизиция2Переход1	СобытиеРазвилка	ПереходПозиция1Переход1Поизиция2Переход1
УгрозаЗадача_ЛовушкаПозиция	УгрозаЗадача	ЛовушкаПозиция

Так как после того, как бизнес-процесс проведения государственной закупки будет реализован в сетях Петри и оптимизирован, необходимо будет вернуть бизнес-процесс в исходную нотацию. Для этого были разработаны правила трансформации из сетей Петри в BPMN (см. табл. 3.8).

Таблица 3.8 -- Правила трансформации нотации сети Петри, в нотацию BPMN, дополненной угрозами

Название правила	Левая часть правила	Правая часть правила
Сущность
Позиция_ СтартПроцесса	Позиция	СтартПроцесса
Маркер_ Дорожка	Маркер	Дорожка
ПозицияПереходПозиция_ Задача	ПозицияПереходПозиция	Задача
Позиция1Переход1Позиция2Переход1_Развилка	Позиция1Переход1Позиция2Переход1	Развилка
Переход_Событие	Переход	Событие
Позиция_ Завершение	Позиция	Завершение
Ловушка_Угроза	Ловушка	Угроза
Условие_Артефакт	Условие	Артефакт
Название правила	Левая часть правила	Правая часть правила
Связь
ПозицияПереходПозиция1Переход1Позиция2Переход1_ СтартПроцессаРазвилка	ПозицияПереходПозиция1Переход1Позиция2Переход1	СтартПроцессаРазвилка
ПозицияПереходПозицияПереходПозиция _ СтартПроцессаЗадача	ПозицияПереходПозицияПереходПозиция	СтартПроцессаЗадача
МаркерПозиция _ ДорожкаЗадача	МаркерПозиция	ДорожкаЗадача
ПозицияПереходПозицияПереходПозиция _ ЗадачаЗавершение	ПозицияПереходПозицияПереходПозиция	ЗадачаЗавершение
СобытиеЗадержкаТерминатор_ СобытиеЗавершение_	СобытиеЗадержкаТерминатор	СобытиеЗавершение
Событие1ЗадержкаСобытие2_ СобытиеЗадача	Событие1ЗадержкаСобытие2	СобытиеЗадача
ПереходПозиция1Переход1Поизиция2Переход1_СобытиеРазвилка	ПереходПозиция1Переход1Поизиция2Переход1	СобытиеРазвилка
ЛовушкаПозиция _ УгрозаЗадача	ЛовушкаПозиция	УгрозаЗадача

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

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



Глава 4. Оценка бизнес-процесса проведения государственных закупок

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

4.1 Отображение бизнес-процессов в сетях Петри

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

Рисунок 4.1 - Ловушка

На рисунке 4.1 показан набор позиций и переходов, которые называются -- ловушка [25]. В данной ситуации любой маркер попавший в ловушку не может ее покинуть, а следовательно, и продолжить выполнение процесса, при этом ловушка может «поймать» любое количество маркеров. При этом если в ловушке изначально нет маркера, то переход Т0 окажется тупиковым и никогда не сможет сработать. Набор позиций и переходов, при котором каждый переход, забирающий маркер в это множество и возвращает его обратно -- называется сифон (см. рис. 4.2).

Рисунок 4.2 - Сифон

Так же как угрозу для бизнес-процесса можно расценивать ситуацию, при которой маркер попал в цикл (рис. 4.3)

.

Рисунок 4.3 - Цикл



4.2 Выявление рисков в бизнес-процессе проведения государственных закупок

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

Рисунок 4.4 - Фрагмент бизнес-процесса проведения государственных закупок -- «Формирование плана закупок»

Таблица 4.4 -- Описание сущностей фрагмента бизнес-процесса проведение государственных закупок -- «Формирование плана закупок»

Имя сущности	Значение
Т0	Принято решение о проведении госзакупки
Р0 - Принято решение о проведении госзакупки	Принято решение о проведении госзакупки
Т1	Формирование предельных объемов финансирования
Р0	Предельные объемы финансирования сформированы
Т2	Формирование плана закупок
Р1	План закупок сформирован
Т3	Согласование плана закупок в части потребности и правильности
Р2	Региональная (муниципальная) информационная система в сфере закупок (РМИС) доступна для загрузки плана.

На рисунке 4.4 изображён фрагмент бизнес-процесса проведения государственных закупок, на котором производится формирование и согласование плана закупок. В таблице 4.1. даётся описание к каждому элементу сети Петри для данного фрагмента.

Рисунок 4.5 - Фрагмент бизнес-процесса проведения государственных закупок -- «Формирование плана закупок» в состоянии риска

На рисунке 4.5 траектория Р0--Т2--Р1--Т3--Р2 представляет собой ситуацию «ловушки», т.е. событие Т3 не может произойти так как условие Р2 не соблюдено. Для конечного пользователя -- это значит, что согласование плана закупок, может быть под угрозой в случае недоступности РМИС для загрузки плана.

Рисунок 4.6 - Фрагмент бизнес-процесса проведения государственных закупок -- «Согласование плана закупок»



Таблица 4.2 -- Описание сущностей фрагмента бизнес-процесса проведение государственных закупок -- «Согласование плана закупок»

Имя сущности	Значение
Т3	Согласование плана закупок в части потребности и правильности
Р3	РМИС доступен для согласования
Р4	План закупок согласован
Р5	План закупок не согласован
Т5	Уточнение плана закупок
Р6	План закупок уточнен
Т4	План закупок согласован

Рисунок 4.7 изображает фрагмент, на котором происходит согласование плана закупок. Описание элементов сети Петри представлено в таблице ниже. Исходя из сети, видно, что согласование плана закупок происходит при условии работоспособности РМИС. На рисунке ниже изображена ситуация, при которой согласование не происходит.

Рисунок 4.7 - Фрагмент бизнес-процесса проведения государственных закупок -- «Согласование плана закупок» в состоянии риска



Рисунок 4.8 - Фрагмент бизнес-процесса проведения государственных закупок -- «Публикация плана и плана-графика»

Таблица 4.3 -- Описание сущностей фрагмента бизнес-процесса проведение государственных закупок -- «Публикация плана-графика»

Имя сущности	Значение
Т4	План закупок согласован
Р7	Публикация плана закупок в единой информационной системе (ЕИС)
Р9	РМИС доступен для публикации
Р10	ЕИС доступен для публикации
Т6	План закупок опубликован
Р15	План опубликован
Т9	Планирование закупок закончено
Р8	Сформирован и уточнён план-график
Р11	РМИС доступен
Т7	План-график сформирован
Р12	Публикация плана-графика в ЕИС
Р13	ЕИС доступен для публикации
Т8	План-график опубликован
Р14	План-график опубликован

На рисунке 4.8 изображён процесс публикации данных о закупке в системах. Здесь маршрут Т4 -- Р7 --Т6 отображает процесс публикации плана-закупок в информационных систем. Условия Р9 и Р10 -- показывают, что публикация (Т6) может произойти только при их выполнении. Здесь Р9 -- единая информационная система -- доступна, Р10 -- РМИС - доступна. Т.е. как и в предыдущем этап появляется угроза технического характера. Такие же условия накладываются на формирование и публикацию плана-графика -- Т4 -- Р8 -- Т7 -- Р12 -- Р14.

Рисунок ниже представляет ситуацию, при которой фрагмент процесса находится в состоянии риска.

Рисунок 4.9 - Фрагмент бизнес-процесса проведения государственных закупок -- «Публикация плана и плана-графика» в состоянии риска

Рисунок 4.10 - Фрагмент бизнес-процесса проведения государственных закупок -- «Проведение общественного обсуждение»



Таблица 4.4 -- Описание сущностей фрагмента бизнес-процесса проведение государственных закупок -- «Проведение общественного обсуждения»

Имя сущности	Значение
Т9	Планирование закупок закончено
Р16	Общественное обсуждение не требуется
Т12	Выбор способа проведение государственных закупок
Р17	Общественное обсуждение требуется
Т10	Проведение общественного обсуждения
Р18	Общественное обсуждение проведено
Т11	Общественное обсуждение согласовало проведение гос. закупки
Р19	Общественное обсуждение согласовало проведение закупки
Р20	Общественное обсуждение согласовало проведение гос. закупки

На рисунке 4.10 показана часть бизнес-процесса проведения государственных закупок. Путь Р17 -- Т10 -- Р18 --Т11 демонстрирует процесс проведения общественного обсуждения с положительным решением. Т.е. событие Р20 -- проведение государственной закупки согласовано, произойдёт при соблюдении условий Р18 -- «Общественное обсуждение проведено» и Р19 --«Общественное обсуждение согласовало проведение закупки». На этом этапе появляется угроза для осуществления закупки, которая может быть основана на решении о ненадобности данного проекта.

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



Рисунок 4.11 - Фрагмент бизнес-процесса проведения государственных закупок -- «Проведение общественного обсуждение» в состоянии риска

Помимо рисков, которые могут возникнуть на подготовительных этапах, есть риски, связанные с выбором поставщика. Так на рисунке 4.12 изображён фрагмент проведения государственной закупки, в котором было принято решение о проведении закупки у единого поставщика. Событие Т16 -- исполнитель определен -- произойдёт при соблюдении условия Р28 --поставщик, удовлетворяющий требования найден. Для конечного пользователя -- это означает, что существует риск не найти единого поставщика, который может в полной мере удовлетворить все требования заказчика.

Рисунок 4.12 - Фрагмент бизнес-процесса проведения государственных закупок -- «Выбор единого поставщика»

Таблица 4.5 -- Описание сущностей фрагмента бизнес-процесса проведение государственных закупок -- «Выбор единого поставщика»

Имя сущности	Значение
Т12	Выбор способа проведение государственных закупок
Р22	Принято решение о закупки у единого поставщика
Т15	Выбор единого поставщика
Р25	Выбор единого поставщика
Т16	Исполнитель определен
Р28	Поставщик, удовлетворяющий всем требованиям найден

Рисунок 4.13 - Фрагмент бизнес-процесса проведения государственных закупок -- «Выбор единого поставщика» в состоянии риска

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



Таблица 4.6 -- Описание выявленных рисков, их последствий и способов минимизации последствий бизнес-процесса проведение государственных закупок

Путь риска	Интерпретация риска со стороны конечного пользователя	Потенциально связанные риски, которые могут возникнуть в случае реализации рисков	Минимизация последствий
Р0--Т2--Р1--Т3--Р2	План закупок не сформирован из-за недоступности РМИС	- Риск нарушения сроков формирования планов, планов-графиков закупок - Риск нарушения сроков согласования планов, планов-графиков закупок	- Сокращение длительности проведения последующих этапов закупки - Создание зеркала ИС
Т3 -- Р4 -- Т4 -- Р3	План закупок не согласован из-за недоступности РМИС	- Риск нарушения сроков согласования планов, планов-графиков закупок - Риск нарушения сроков публикации планов, планов-графиков закупок	- Оперативное вмешательство вышестоящих органов с целью скорейшего внесения изменений в план закупок - Создание зеркала ИС
Путь риска	Интерпретация риска со стороны конечного пользователя	Потенциально связанные риски, которые могут возникнуть в случае реализации рисков	Минимизация последствий
T4 -- P7 -- T6 --P9 --P10	План закупок не опубликован из-за недоступности РМИС и ЕИС	- Риск нарушения сроков публикации планов, планов-графиков закупок	- Осуществление закупки у единственного поставщика (подрядчика, исполнителя) - Оперативное вмешательство вышестоящих органов с целью скорейшего внесения изменений в план закупок - Сокращение длительности проведения последующих этапов закупки - Создание зеркала ИС
T4 --P8 -- T7 --P11-- P12-- T8--P13	План-график не опубликован из-за недоступности РМИС и ЕИС	- Риск нарушения сроков публикации планов, планов-графиков закупок	- Осуществление закупки у единственного поставщика (подрядчика, исполнителя) - Оперативное вмешательство вышестоящих органов с целью скорейшего внесения изменений в план закупок - Сокращение длительности проведения последующих этапов закупки - Создание зеркала ИС
Т10 -- Р18 -- Т11 -- Р19	Общественное обсуждение не подтвердило необходимость государственной закупки	- Риск потребности внесения изменений в планы, планы-графики закупок - Риск дополнительных затрат на проведение конкурсной процедуры выбора поставщика (подрядчика, исполнителя) не в соответствии с первоначальными планом и планом-графиком закупок - Риск невозможности провести закупку по причине длительного общественного обсуждения закупки - Риск потребности дополнительных затрат на продление процедуры закупки	- Учет возможной необходимости дополнительных временных затрат - Учет возможной необходимости дополнительных человеческих ресурсов - Переформирование плана закупок в закупки, не требующие общественного обсуждения
Путь риска	Интерпретация риска со стороны конечного пользователя	Потенциально связанные риски, которые могут возникнуть в случае реализации рисков	Минимизация последствий
Т15 -- Р25 -- Т16 -- Р28	Отсутствие исполнителя, удовлетворяющего всех условий	- Риск нарушения сроков разработки проекта контракта - Риск нарушения сроков размещения контракта в ЕИ - Риск нарушения регламента осуществления закупки у единственного поставщика (подрядчика, исполнителя) - Уплата штрафов участниками процесса - Риск не осуществления закупки	- Продление сроков закупки



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

Рисунок 4.14 - Фрагмент бизнес-процесса проведения государственных закупок -- «Формирование плана закупок» с минимизацией последствия рисков

На рисунке 4.14 показана ситуация, при которой информационная система не доступна для формирования плана закупок (условие Р2 не соблюдены), однако маркеры двигаются по траектории Р0 - Т18 - Р29 -Т3, что со стороны конечного пользователя означает, что в случае неработоспособности РМИС, формирования плана будет осуществлено с помощью зеркала информационной системы, здесь событие Т18 -- использование зеркала РМИС для формирования плана закупок.

Аналогичное дополнение введём для минимизации рисков: план закупок не согласован из-за недоступности РМИС, план закупок не опубликован из-за недоступности РМИС и ЕИС, план-график не опубликован из-за недоступности РМИС и ЕИС.



Рисунок 4.15 - Фрагмент бизнес-процесса проведения государственных закупок -- «Согласование плана закупок» с минимизацией последствия рисков

Рисунок 4.16 - Фрагмент бизнес-процесса проведения государственных закупок -- «Публикация плана и плана-графика» с минимизацией последствия рисков



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

На рисунке 4.18 показана ситуация, при которой общественное обсуждение не согласовало проведение закупок. Здесь траектория Р17 -- Т33 --Р43 -- Т1 -- является решением переформировать проведения государственной закупки, в закупку не требующую общественного обсуждения, который возвращает маркер в начала бизнес-процесса, для формирования, согласования и публикации нового плана и плана--графика закупок.

Рисунок 4.18 - Фрагмент бизнес-процесса проведения государственных закупок -- «Проведение общественного обсуждение» с минимизацией последствия рисков



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

4.3 Использование iWebSim для предотвращения рисков в бизнес-процессе

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

Все сущности метамодели языка iWebSim представлены ниже в таблице (табл. 4.7).

Таблица 4.7 -- Основные сущности метамодели языка IWebSim

Сущность	Атрибут	Тип данных атрибута
Генератор	Имя	Строковый
	Имя коллекции	Строковый
	Приоритет	Числовой
	Предельное число срабатывания	Числовой
	Единица измерения длительности паузы между соседними срабатываниями	Строковый
	Закон распределения	Строковый
	Параметры закона распределения	Числовой
	Параметры транзактов	числовой
Задержка	Имя	Строковый
	Единица длительности измерения	Строковый
	Тип закона распределения	Строковый
	Параметры закона распределения	Числовой
	Методы	Строковый
Событие	Имя	Строковый
	Приоритет	Числовой
Очередь	Имя	Строковый
	Тип	Строковый
Сущность	Атрибут	Тип данных атрибута
Ресурс	Имя	Строковый
	Кол-во	Числовой
Брокер	Имя	Строковый
	Объем партии	Числовой
	Параметры скорости выходного потока	Числовой
Терминатор	Имя	Строковый
	Приоритет	Числовой
Динамическая переменная	Имя	Строковый

В таблице ниже представлены все возможные связи между имеющимися сущностями (4.8).

Таблица 4.8 -- Связи между сущностями метамодели языка IWebSim

Связь	Тип связи	Направление
Генератор_Задержка	Потоковая	Однонаправленная
Генератор_Очередь	Потоковая	Однонаправленная
Генератор_Ресурс	Потоковая	Однонаправленная
Генератор_Брокер	Потоковая	Однонаправленная
Задержка_Событие	Потоковая	Однонаправленная
Задержка_Терминатор	Потоковая	Однонаправленная
Событие_Задержка	Потоковая	Однонаправленная
Событие_ресурс	Потоковая	Однонаправленная
Событие_Брокер	Потоковая	Однонаправленная
Очередь_Событие	Потоковая	Однонаправленная
Очередь_Терминатор	Потоковая	Однонаправленная
Ресурс_Событие	Потоковая	Однонаправленная
Ресурс_Терминатор	Потоковая	Однонаправленная
Брокер_Событие	Потоковая	Однонаправленная
Брокер_Терминатор	Потоковая	Однонаправленная
ДинамическаяПеременная_Генератор	Ингибиторная	Однонаправленная
ДинамическаяПеременная_ Очередь	Ингибиторная	Однонаправленная
ДинамическаяПеременная_Ресурс	Ингибиторная	Однонаправленная

Потоковая связь служит отображение направлением перемещения транзактов между сущностями. Ингибиторная связь по своей сути является проверкой «на ноль», то есть осуществляет проверку того, что во входной ее сущности нет транзактов.

В виде матрицы отобразим связи между сущностями в метамодели iWebSim. (табл. 4.9).

Таблица 4.9-- Матрица связей между сущностями метамодели IWebSim

Сущность	Генератор	Задержка	Событие	Очередь	Ресурс	Брокер	Терминатор	Динамическая переменная
Генератор	-	+	-	+	+	+	-	-
Задержка	-	-	+	-	-	-	+	-
Событие	-	+	-	-	+	+	-	-
Очередь	-	-	+	-	-	-	+	-
Ресурс	-	-	+	-	-	-	+	-
Брокер	-	-	+	-	-	-	+	-
Динамическая переменная	+	-	-	+	+	-	-	-
Терминатор	-	-	-	-	-	-	-	-

После того, как основные шаги по реализации метамодели языка выполнены - можно приступить к ее реализации. Ниже представлена метамодель языка IWebSim (см. рис. 4.19).



Рисунок 4.19 -- Метамодель языка IWebSim

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

Рисунок 4.20 -- Фрагмент модели проведения государственной закупки -- «Выбор единого поставщика»

В данной модели в элемент «Формирование_ согласование_публикация_плана_планаграфика» были передана следующие свойства (рис. 4.21):

Рисунок 4.21 -- Свойства элемента «Формирование_согласование_публикация_плана_планаграфика»

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

Рисунок 4.22 -- Среднее время, затраченное на подготовительный этап формирования государственной закупки

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

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

4.4 Трансформация безрисковой модели проведения государственных закупок в нотацию BPMN

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

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

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



Заключение

В рамках данной работы был проведён полный цикл процесса минимизации рисков в бизнес-процессе проведения государственных закупок.

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

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



Библиографический список

1. Jakoubi S., Tjoa S., Quirchmayr G. Rope: A Methodology for Enabling the Risk-Aware Modelling and Simulation of Business Processes // 15^th European Conf. Information Systems - 2007. - рр. 1596-1607.

2. Ушакова Д.Е. Разработка визуального языка для управления рисками бизнес-процессов - 2018 - стр. 67.

3. Barbieri M., Cibrario Bertolotti I., Cheminod M., Christou I., Durante L., Efremidis S., Gentile G., Kieseberg P., Lehmann S., Paci P., Pesce M., Ronge A., Tanas M., Taverner C., and Zechner L. Inmotos project. // In Conference on Critical Information Infrastructures Security 2012. - CRITIS'12. - 2012. - pp. 272 - 277.

4. Zechner L., Kieseberg P., Weippl E.. INMOTOS: Extending the ROPE-methodology//IIWAS '12 Proceedings of the 14th International Conference on Information Inte...