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

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

Рисунок 1.2. Проектирование деловой игры

Рисунок 1.3. Процесс перехода от реального бизнес-процесса к учебному

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

1.4 Разработка языка описания учебных бизнес-процессов

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

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

Рисунок 1.4. Модель абстрактного бизнес-процесса

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

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

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

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

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

Рисунок 1.5. Модель учебного бизнес-процесса

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

Рисунок 1.6. Декомпозиция точки принятия решения

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

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

Рисунок 1.7. Модель оцененного учебного бизнес-процесса

При выставлении этой оценки учитывался порядок действий игрока. Неверные по порядку операции получали «штрафные баллы». Таким образом, верная последовательность действий «АВС» получит ноль баллов, а результатом неверной последовательность, например, «BACABC» станет 1+0+2+0+0+0=3 штрафных балла. Кроме того, как только верная последовательность действий была выполнена в нужном порядке, при чем между правильными шагами могли находиться неправильные («bAcaBC»), то бизнес-процесс может считаться завершенным, так как достиг требуемого от него результата. Следует отметить, что подобная оценка действий игрока может отличаться в зависимости от бизнес-процесса и от набора компетенций и критериев.

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

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

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

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

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

Рисунок 1.8. Декомпозиция оцененной точки принятия решения

В итоге, разработанный для описания учебных бизнес-процессов язык состоит из следующих объектов:

)         «Начало БП» - означает начало активности бизнес-процесса;

)         «Конец БП» - означает завершение активности бизнес-процесса и то, что все необходимые для достижения цели бизнес-процесса операции были выполнены;

)         «Операция» - некоторое действие, необходимое для достижения цели бизнес-процесса.

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

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

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

Выделены следующие требования:

.         УБП должен основываться на описании нескольких реальных бизнес-процессов;

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

.         УБП должен предоставлять игроку возможность управлять развитием бизнес-процесса и учитывать различные варианты развития бизнес-процесса;

.         УБП должен предоставлять возможность оценки действий игрока;

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

Чтобы данные требования выполнялись, язык описания УБП должен содержать объекты и связи, описанные в разделе 1.4. Однако в рамках проекта СКДИ от учебного бизнес-процесса также требуется учитывать показатели реального бизнес-процесса, поэтому при реализации языка необходимо будет использовать язык описания реальных бизнес-процессов, разработанный для проекта СКДИ.

Глава 2. Реализация языка описания учебных бизнес-процессов

Разработанное описание языка будет реализовано при помощи DSM-платформы MetaEdit+. Тем не менее, в предыдущей главе был разработан язык, абстрагирующийся от различных экономических, временных и прочих характеристик бизнес-процесса. Однако в рамках проекта СКДИ подобной абстрагирование недопустимо, чтобы учесть эти характеристики, необходимо совместить язык описания учебных бизнес-процессов с разработанным в рамках проекта СКДИ языком описания реальных бизнес процессов. Поэтому будет добавлено подробное описание каждой операции в бизнес процессе, что позволит выделить все необходимые экономические параметры.

.1 Разработка метамоделей

Разработанное описание языка будет реализовано при помощи DSM-платформы Metaedit+. Поскольку язык достаточно сложен, то его описание разделяется на три уровня, выполненных при помощи трех связанных метамоделей: «Карта операций», «Операция» и «Точка принятия решения». В этой части будет подробно рассмотрено описание каждой метамодели. Для этого нам необходимо проделать следующие шаги:

)        создать графы для каждой метамодели;

)        добавить объекты в модели;

)        создать связи между объектами метамоделей;

)        определить визуальное представление объектов.

.1.1 Создание графа метамодели

Сначала необходимо создать граф для метамодели, для этого правой кнопкой в окне «Graphs» вызовем контекстное меню и выберем «Create Graph». Затем из предложенного списка имеющихся метамоделей выберем Metamodel [GOPRR] и нажмем кнопку «OK» (рис 2.1.):

Рисунок 2.1. Диалоговое окно при создании графа

После проделанных действий нам откроется диалоговое окно (рис. 2.2), в котором необходимо ввести имя создаваемого графа. Помимо имени можно определить некоторые свойства. Для этого необходимо в окне «Properties» правой кнопкой вызвать контекстное меню и выбрать «Add Element». Откроется новое диалоговое окно для ввода значений для каждого свойства. Теперь можно вводить такие детали для свойства, как его обязательное имя и необязательное локальное имя, которые будут использоваться в инструментах моделирования. Также можно указать необходимый тип данных для каждого свойства путем выбора из списка возможных типов данных.

После того, как проделаны соответствующие действия, в разделе «Graphs» появится созданный граф «Имя_графа: Metamodel [GOPRR]».

Рисунок 2.2. Диалоговое окно для ввода значений свойств

2.1.2 Добавление нового объекта в модель

Далее определяют объекты, которые необходимо использовать в языке моделирования в данной метамодели. В первую очередь нужно создать конкретные объекты. Для создания таких объектов нужно выбрать кнопку «Object [GOPRR]» на панели инструментов, а затем щелкнуть по диаграмме. Откроется диалоговое окно для уточнения деталей объекта (рис. 2.3).

Прежде всего, необходимо ввести имя объекта в поле «Object name». Затем указать свойства, которыми обладает объект. В окне раздела «Properties» правой кнопкой вызывают контекстное меню и выбирают «Add Element». Откроется окно (рис. 2.4), в котором необходимо указать имя атрибута и его тип. Помимо этих свойств можно также указать его локальное имя, описание, уникальность этого свойства. Далее нажимают кнопку «ОК».