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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Аннотация

Данный отчет содержит подробное описание разработки языка для моделирования учебных бизнес-процессов в рамках проекта по разработке «Студии компетентностных деловых игр». Для создания языка использовалась DSM-платформа MetaEdit+. Отчет состоит из двух глав.

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

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

Оглавление

• Введение

Глава 1. Анализ учебных бизнес-процессов

• 1.1 Особенности учебных бизнес-процессов
• 1.2 Требования к учебному бизнес-процессу
• 1.3 Переход от реального бизнес-процесса к учебному
• 1.4 Разработка языка описания учебных бизнес-процессов

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

• 2.1 Разработка метамоделей
• 2.1.1 Создание графа метамодели
• 2.1.2 Добавление нового объекта в модель
• 2.1.3 Создание связей между объектами
• 2.1.4 Создание визуальных представлений объектов
• 2.1.5 Метамодель «Карта операций УБП»
• 2.1.6 Метамодель «Операция»
• 2.1.7 Метамодель «Точка принятия решения»
• 2.2 Визуальное описание бизнес-процесса
• 2.2.1 Модель выдержки из реального бизнес процесса
• 2.2.2 Модель карты операций учебного бизнес-процесса
• 2.2.3 Модель операции
• 2.2.4 Модель точки принятия решения

Заключение

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

Введение

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

• Часто процесс оценки знаний бывает субъективен, поскольку охватывает только часть необходимых компетенций. В настоящее время широкое распространение получило такое явление как «геймификация» обучения. Под самим термином «геймификация» понимается внедрение игровой механики в неигровые процессы, такие как, например, обучение [1]. Внедрение игровой механики подразумевает повышение вовлеченности игрока в процесс обучения, путем моделирования условий, с которыми обучаемому придется столкнуться в реальной жизни, а также последующей оценки действий игрока в соответствии с заданным набором компетенций и критериев. Кроме того, игра позволяет сделать процесс обучения и проверки квалификаций автономным. То есть, компании могут обучать новых сотрудников, не требуя при этом дополнительного вмешательства других сотрудников и объектов внешней среды (поставщиков, клиентов и т.д.), таким образом, сокращая затраты.

В соответствие принципу «геймификации», был создан проект «Студия Компетентностных Деловых Игр» (далее СКДИ), который формировать и проверять компетенции, используя для этого деловые игры, построенные на основе реальных бизнес-процессов.

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

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

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

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

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

Для того чтобы достигнуть данной цели, необходимо выполнить следующие задачи:

1) выявить особенности учебных бизнес-процессов;

2) сформировать требования к учебному бизнес-процессу, используемому в деловой игре;

3) описать процесс перехода от реального бизнес-процесса к учебному;

4) разработать язык описания учебных бизнес-процессов;

5) разработать метамодель языка описания учебного бизнес-процесса в среде MetaEdit+;

6) описать учебный бизнес-процесс в разработанной нотации.

Глава 1. Анализ учебных бизнес-процессов

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

1.1 Особенности учебных бизнес-процессов

язык моделирование учебный игра

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

Рисунок 1.1. Структурная схема СКДИ

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

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

Стоит отметить почему же реальные бизнес-процессы, пусть и описанные в удобной форме, не представляют собой достаточной учебной ценности и не могут быть использованы в подсистеме проектирования. Причиной является то, что они по своей сути - жестко заданные алгоритмы. То есть, взглянув на такой бизнес-процесс, обучаемый сразу видит его «идеальное» состояние, в котором задана верная последовательность действий, позволяющая достичь нужного результата. Таким образом, если в рамках СКДИ будут использованы реальные бизнес процессы вместо учебных, то единственным результатом обучения будет воспроизведение знаний, полученных экспертом на основе исследования некой организации. Безусловно, и это будет являться вполне значимым достижением, однако в тот же момент будет противоречить одной из ключевых концепций СКДИ: использование модели производственной деятельности и «активного» обучения для формирования профессиональных компетенций, а не только лишь для передачи знаний [2].

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

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

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

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

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

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

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

1) унифицированность;

2) идеализированность;

3) различные варианты развития событий;

4) динамическая оценка действий игрока по определенным показателям;

5) ограниченность моделью реального бизнес-процесса и экспертной информацией.

1.2 Требования к учебному бизнес-процессу

Требования к учебному бизнес-процессу должны содержать определенный набор правил и характеристик, который позволит реализовать все выявленные в предыдущей части особенности учебных бизнес-процессов в СКДИ. Напомним эти особенности:

1) унифицированность - использование исключительно инвариантных характеристик бизнес-процесса;

2) идеализированность - отсутствие ошибок и неверных характеристик;

3) различные варианты развития событий - учебный бизнес-процесс предусматривает любой сделанный в рамках бизнес-процесса ход игрока;

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

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

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

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

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

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

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

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

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

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

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

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

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

В УБП разделяется на управляющие и не управляющие учебные бизнес процессы [2]. Ради наглядности данный факт был опущен в процессе разработки учебного бизнес-процесса, он будет рассмотрен в течение дальнейшей разработки СКДИ. Как уже говорилось в предыдущей части, необходимо выделить промежуточный шаг при переходе от реальных бизнес процессов к учебному. В концепции этот шаг отражен системным анализом предметной области. Рассмотрим этот этап более подробно (рис. 1.3).

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



Рисунок 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) «Начало БП» - означает начало активности бизнес-процесса;

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

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

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

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

b. «Вызывающую операцию» - та операция, за которой наступает момент выбора следующей операции;

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

d. «Результирующая операция» - содержит один из возможных при данном стечении обстоятельств вариантов развития событий в бизнес-процессе;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.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), в котором необходимо указать имя атрибута и его тип. Помимо этих свойств можно также указать его локальное имя, описание, уникальность этого свойства. Далее нажимают кнопку «ОК».



Рисунок 2.3. Диалоговое окно при создании объекта

Рисунок 2.4. Добавление атрибута

В поле «Occurrence» необходимо поставить число (1…N), которое отражает, какое количество таких объектов может присутствовать в одной диаграмме. Выбор значения «0» будет означать, что объект абстрактен. Выбор значения «1» будет означать, что объект уникален. После проделанных действий нажимают кнопку «OK». После этого на диаграмме будет создан объект с заданным названием (рис. 2.5):

Рисунок 2.5. Созданный объект "Объект"

2.1.3 Создание связей между объектами

Далее определяют, каким образом объекты метамодели будут соединены. Создаются связи между объектами. На панели инструментов выбирают кнопку «Binding [GOPRR]» и соединяют два объекта, нажав на каждый из них.

Создание отношения связи откроет диалоговое окно спецификации свойств связи (рис 2.6). На закладке связи появившегося диалога можно задать тип связи, ее имя и свойства. Для связи необходимо задать минимум две роли.

Рисунок 2.6. Создание свойств отношений

На вкладке «Binding [GOPRR]» задается название отношения. Затем указывается роль каждого объекта в этой связи. Также необходимо указать кратность связи и возможна ли ситуация, что связь можно протянуть в двух направлениях.

Если в метамодели присутствует связь от объекта к самому себе, то как и в предыдущем случае на панели инструментов выбирают кнопку «Binding [GOPRR]». Поскольку напрямую связь провести нельзя, то действуют по следующей схеме: нажимают на объект «Операция», затем нажимают на свободное место и еще раз на свободное место, а затем снова кликают на объект.

2.1.4 Создание визуальных представлений объектов

На следующем шаге создают визуальное представление для каждого созданного объекта в данной метамодели. Для этого необходимо перейти на вкладку «Metamodel Browser» и выбирать нужный граф. В разделе «Contents: Object types» отобразятся все созданные ранее объекты (рис. 2.7):

Рисунок 2.7. Созданные ранее объекты

Далее задают для каждого объекта уникальную фигуру, которая будет отображаться пользователю на диаграмме, а также будет ему понятна. Для этого нужно два раза кликнуть на объект. После этого откроется диалоговое окно с характеристиками выбранного объекта (рис. 2.8):

Рисунок 2.8. Диалоговое окно с характеристиками объекта "Объект"

Для создания фигуры используют раздел «Symbol Editor». Необходимо нажать на соответствующую иконку и открывается новое окно, в котором присутствуют самые простые функции графического редактора (рис. 2.9).

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

Откроется диалоговое окно (рис. 2.10), в котором необходимо нажать «Property» и из предложенного списка выбрать нужное свойство.



Рисунок 2.9. Редактор представления объекта "Объект"

Рисунок 2.10. Диалоговое окно для добавления свойств

2.1.5 Метамодель «Карта операций УБП»

Последовательно выполняя действия описанные в разделе «Создание графа метамодели» была создана метамодель «Карта операций УБП» (рис. 2.11), которая позволяет описать учебный бизнес-процесс в виде многовариантной последовательности операций и моментов принятия решения игроком.



Рисунок 2.11. Метамодель "Карта операций УБП"

Визуально объекты метамодели «Карта операций» будут представлены следующим образом:

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

2) «Начало БП» - равнобедренный треугольник с зеленой заливкой и черным контуром, основание которого находится сверху. Данный треугольник содержит в себе текст «Начало».

3) «Завершение БП» - равнобедренный треугольник с зеленой заливкой и черным контуром, основание которого находится снизу. Данный треугольник содержит в себе текст «Конец».

4) «Точка принятия решения» - круг, с голубой заливкой и черным контуром, содержащий внутри текст, отражающий его свойство объекта «Точка принятия решения» - «Номер».

Визуально связи метамодели «Карта операций» будут представлены следующим образом:

1) «Начальный выбор» - стрелка, выходящая из объекта «Начало БП» к объекту «Точка принятия решения».

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

3) «Результат выбора» - стрелка, выходящая из объекта «Операция» к объекту «Точка принятия решения».

4) «Конец операций» - стрелка, выходящая из объекта «Точка принятия решения» к объекту «Завершение БП».

2.1.6 Метамодель «Операция»

Последовательно выполняя действия описанные в разделе «Создание графа метамодели» была создана метамодель «Операция» (рис. 2.12), которая позволяет описать каждую операцию отдельно.



Рисунок 2.12. Метамодель "Операция"

Визуально объекты метамодели «Карта операций» будут представлены следующим образом:

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

2) «Информационный ресурс» - прямоугольник, с синим контуром и без заливки, буквой «i» и текстом внутри.

3) «Трудовой ресурс» - прямоугольник, с зеленым контуром и без заливки, зеленой каской и текстом внутри.

4) «Финансовый ресурс» - прямоугольник, с золотистым контуром и без заливки, с изображением монеток и текстом внутри.

5) «Оборудование» - прямоугольник, с красным контуром, без заливки, черной шестерёнкой и текстом внутри.

6) «Услуга (работа)» - прямоугольник, с серым контуром, без заливки, с изображением инструментов и текстом внутри.

7) «Товары» - прямоугольник, без заливки, с оранжевым контуром, изображением ящика и текстом внутри.

8) «Контрагент» - прямоугольник, без заливки, с черным контуром, желтой заливкой, фигуркой человечка и текстом внутри.

9) «Поток» - стрелка, с голубым контуром и текстом внутри.

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

2.1.7 Метамодель «Точка принятия решения»

Последовательно выполняя действия, описанные в разделе «Создание графа метамодели» была создана метамодель «Точка принятия решения» (рис. 2.13), которая позволяет описать принятие решения игроком, раскрывая его посредством последовательности реакций.

Визуально объекты метамодели «Точка принятия решения» будут представлены следующим образом:

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

2) «Начало БП» - равнобедренный треугольник с зеленой заливкой и черным контуром, основание которого находится сверху. Данный треугольник содержит в себе текст «Начало».

3) «Завершение БП» - равнобедренный треугольник с зеленой заливкой и черным контуром, основание которого находится снизу. Данный треугольник содержит в себе текст «Конец».

4) «Точка принятия решения» - круг, с голубой заливкой и черным контуром, содержащий внутри текст, отражающий его свойство объекта «Точка принятия решения» - «Номер».



Рисунок 2.13. Метамодель "Карта операций УБП"

Визуально связи метамодели «Карта операций» будут представлены следующим образом:

5) «Начальный выбор» - стрелка, выходящая из объекта «Начало БП» к объекту «Точка принятия решения».

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

7) «Результат выбора» - стрелка, выходящая из объекта «Операция» к объекту «Точка принятия решения».

8) «Конец операций» - стрелка, выходящая из объекта «Точка принятия решения» к объекту «Завершение БП».

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

2.2 Визуальное описание бизнес-процесса

2.2.1 Модель выдержки из реального бизнес процесса

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

Рисунок 2.14. Выдержки из реального бизнес-процесса

2.2.2 Модель карты операций учебного бизнес-процесса

Данная модель реального бизнес-процесса позволяет перейти к учебному бизнес-процессу. На рисунке 2.15 представлена так называемая карта операций для учебного бизнес-процесса, выполненная на основе метамодели «Карта операций».

Рисунок 2.15. Карта операций

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

2.2.3 Модель операции

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

Приведем пример описания одной из операций рассматриваемой выдержки из бизнес-процесса. Операция «Составление плана звонков на день» выполняется телемаркетологом. На вход поступает утвержденный план продаж, в соответствие с которым составляется план звонков на каждый день. Для составления такого плана телемаркетологу понадобится персональный компьютер, на котором должна быть установлена информационная система «1С: Управление небольшой фирмой», в которую заносится вся информация о потенциальных и реальных клиентах. Поиск информации о потенциальных клиентах производится с помощью информационной системы «2GIS». Телемаркетолог действует в соответствие с должностной инструкцией №10. После выполнения данной операции в качестве выходного потока выступает новый информационный ресурс - план звонков на день. Описание операции «Составление плана звонков на день» на основе метамодели «Операция» приведено на рисунке 2.16:

Рисунок 2.16. Описание операции "Составление плана звонков на день"

2.2.4 Модель точки принятия решения

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

Первой рассмотрим ТПР под номером 0. Данная точка представляет собой начальный выбор, с которым сталкивается игрок. В ней он выбирает самую первую операцию бизнес-процесса. На рисунке 2.17 представлены реакции игрока, а также оценка их согласованности с моделью реального бизнес-процесса:

Рисунок 2.17. Декомпозиция ТПР №0

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

Рисунок 2.18. Декомпозиция ТПР №4

Последней рассмотренной точкой принятия решения стала ТПР №5 (рис. 2.19). Она отражает такую точку, в которой возможно завершений текущего бизнес-процесса. В описании реального бизнес-процесса руководитель отдела продаж может завершить работу после передачи плана продаж телемаркетологам для составления плана звонков на день. Данная точка принятия решения предлагает игроку самостоятельно решить, закончена ли его работа в текущем бизнес-процессе. В соответствие с этим выставляются оценки его решениям.

Рисунок 2.19. Декомпозиция ТПР №5

В данной главе описан процесс реализации разработанного языка описания учебных бизнес-процессов на DSM-платформе MetaEdit+. Данный язык был дополнен и расширен, благодаря слиянию с языком описания реальных бизнес-процессов, разработанным в рамках работы над проектом СКДИ. Были формально определены правила языка описания учебных бизнес-процессов путем явного описания метамоделей языка.

Таким образом, при реализации языка были выделены следующие конструкции:

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

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

3) «Операция» - некоторое действие, необходимое для достижения цели бизнес-процесса, декомпозиция которой содержит следующие объекты:

a. «Информационный ресурс» - ресурс, который может регламентировать операцию, изменяться или создаваться в процессе ее выполнения;

b. «Трудовой ресурс» - ресурс обеспечивающий выполнение операции;

c. «Финансовый ресурс» - отражает изменения в денежных потоках;

d. «Оборудование» - отражает необходимое для выполнения операции оборудование;

e. «Услуга (работа)» - может быть произведена при выполнении операции, а также потреблена или продана;

f. «Товар» - может быть получен, произведен или потреблен в процессе выполнения операции;

g. «Контрагент» - отражает объекты внешней среды;

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

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

b. «Вызывающую операцию» - та операция, за которой наступает момент выбора следующей операции;

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

d. «Результирующая операция» - содержит один из возможных при данном стечении обстоятельств вариантов развития событий в бизнес-процессе;

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

В дальнейшем планируется усовершенствование данного языка. Помимо этого, язык будет использован в среде разработки деловых игр, которая будет создана другими участниками проекта СКДИ.

Заключение

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

В дальнейшем планируется усовершенствование данного языка. Помимо этого, язык будет использован в среде разработки деловых игр, которая будет создана другими участниками проекта СКДИ.

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

1. Zichermann G. and Cunningham C. Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps [Book]. - Sebastopol, California: O'Reilly Media, 2011.

2. Викентьева О.Л., Дерябин А.И., Шестакова Л.В. Концепция студии компетентностных деловых игр [Статья] // Современные проблемы науки и образования. - Москва: НИУ ВШЭ Москва, 2013 г. - №2.

3. Викентьева О.Л., Дерябин А.И., Шестакова Л.В. Функциональные требования к студии компетентностных деловых игр [Статья] // Вестник Пермского национального исследовательского политехнического университета. Электротехника, информационные технологии, системы управления. - Пермь: ПНИПУ, 2013 г.. - №8.

Размещено на Allbest.ru