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

Аннотация

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

Отчет состоит из двух глав.

Глава 1 содержит описание выбранной предметной области в текстовом представлении, а также в визуальном представлении с помощью нотаций IDEF0, DFD, ERD, Use Case Diagram, Sequence Diagram, Class Diagram.

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

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

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

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

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

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

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

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

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

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

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

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

2) описать бизнес-процесс с помощью уже существующих нотаций;

3) выполнить анализ возможности использования рассмотренных нотаций для достижения поставленной цели;

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

5) разработать язык в среде MetaEdit+;

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

Глава 1. Моделирование и анализ бизнес-процесса «Продажа товаров/услуг/работ»

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

1.1 Текстовое описание бизнес-процесса

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

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

ООО «ДВК АйТи» состоит из двух структурных подразделений: главный офис в г. Перми и дополнительное подразделение в г. Соликамске. Тем не менее, оба подразделения работают в рамках единой организационной иерархии, представленной на рисунке 1.2.

В рассматриваемом бизнес-процессе «Продажа товаров/услуг/работ» компании «ДВК АйТи» участвуют следующие лица:

1) телемаркетолог;

2) менеджер по продажам;

3) офис-менеджер;

4) руководитель отдела продаж;

5) программист-консультант;

6) финансовый директор.

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

1.1.1 Планирование продаж

Для того чтобы продать товар/услугу/работу изначально необходимо спланировать продажи. Процесс «Планирование продаж» также может быть разбит на подпроцессы: «Составление плана продаж» и «Утверждение плана продаж».

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

Рассмотренный бизнес-процесс регулируется стандартом качества «Система менеджмента качества стандарта предприятия 05» (далее именуемый СМК СТП 05).

1.1.2 Поиск клиентов

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

1) название организации (обязательно);

2) контактный телефон (обязательно);

3) сфера деятельности (обязательной);

4) имя контактного лица (если таковое указано в навигационной системе);

5) адрес электронной почты (если таковой указан в навигационной системе);

6) дополнительные данные (если таковые указаны в навигационной системе).

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

При «Выяснении требований клиента» телемаркетолог должен получить следующую информацию:

1) информацию об интересующем продукте;

2) подробное описание деятельности компании;

3) карточку компании;

4) имя контактного лица;

5) контактный телефон.

Полученные данные телемаркетолог передает менеджеру по продажам. Данный процесс регулируется должностной инструкцией № 10 (далее именуемой ДИ-10).

1.1.3 Продажа товаров/услуг/работ

На следующем этапе менеджер по продажам составляет договор в соответствие с СМК СТП 05 и отправляет его на подписание заказчику.

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

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

Если клиент заказывал товар, то на следующем шаге менеджер по продажам оформляет заказ поставщику и передает данные офис-менеджеру для оплаты счета. Затем офис-менеджер принимает товар от поставщика, доставленный, как правило, курьером, и передает его заказчику и составляет отчет о продаже. Данный процесс полностью регулируется СМК СТП 05, который содержит визуальное представление бизнес-процесса, приведенное на рисунке 1.3.

1.2 Описание бизнес-процесса с помощью существующих нотаций

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

В данном разделе бизнес-процесс «Продажа товаров/услуг/работ» будет описан с помощью следующих нотаций:

1) IDEF0.

2) Data Flow Diagram (диаграмма потоков данных).

3) Entity-Relationship Diagram (диаграмма «сущность-связь»).

4) Use Case Diagram (диаграмма вариантов использования).

5) Class Diagram (диаграмма классов).

6) Sequence Diagram (диаграмма последовательностей).

1.2.1 Описание бизнес-процесса с помощью IDEF0

IDEF0 — это методология функционального моделирования, позволяющая описать процесс в виде иерархической системы взаимосвязанных функций [3].

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

Из рисунков приложения № 1 видно, что IDEF0 позволяет описать бизнес-процесс на разных уровнях с помощью возможности декомпозирования операция. Данная нотация позволяет определить исполнителей процесса, элементы управления, а также входы и выходы для каждой операции. Однако с помощью данной модели достаточно сложно углубиться в детали предметной области. Еще одним большим недостатком IDEF0 является то, что она не отражает реакцию участников процесса на события внешней среды. Данная нотация предоставляет возможность только линейного описания процессов — на диаграмме невозможно отразить действия, выполняемые в случае, если процесс отклонился от своего идеального варианта.

Описание данной диаграммы представлено в приложении B.

1.2.2 Описание бизнес-процесса с помощью Data Flow Diagram

Data Flow Diagram (диаграмма потоков данных) обеспечивает анализ требований и функциональное проектирование информационных систем [3].

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

Основными элементами DFD являются:

1) Внешние сущности — объекты, находящиеся за границами системы и являющиеся источником или получателем данных.

2) Подсистемы — группирующие сущности. Подсистема не обрабатывает никаких данных и содержит внутри себя процессы и накопители данных.

3) Процессы — сущности, преобразующие входные потоки данных в выходные в соответствии с определенным алгоритмом.

4) Накопители данных — сущности, предназначенные для хранения и предоставление данных.

5) Потоки данных — информация, передаваемая от источника приемнику.

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

Описание данной диаграммы представлено на рисунке 1.4:

1.2.3 Описание бизнес-процесса с помощью Entity-Relationship Diagram

Entity-Relationship Diagram (диаграмма «сущность-связь») предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).

Описание данной диаграммы представлено на рисунке 1.5

1.2.4 Описание бизнес-процесса с помощью Use Case Diagram

Use Case Diagram (диаграмма вариантов использования) отображает взаимодействие между вариантами использования, представляющими функции системы, и акторами, представляющими людей или внешние системы.

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

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

Описание данной диаграммы представлено на рисунке 1.6

1.2.5 Описание бизнес-процесса с помощью Class Diagram

Class Diagram (диаграмма классов) отражает статическую структуру понятий, типов и классов системы.

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

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

Описание данной диаграммы представлено на рисунке 1.7

1.2.6 Описание бизнес-процесса с помощью Sequence Diagram

Sequence Diagram (диаграмма последовательности) — это диаграмма, чаще всего, описывающая один сценарий системы. На диаграмме изображаются экземпляры объектов и сообщения, которыми они обмениваются в рамках одного прецедента. Каждый объект имеет свою линию жизни, которая определяет жизненный цикл объекта в процессе взаимодействия.

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

Описание данной диаграммы представлено в приложении С.

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

2.1 Составление требований к разрабатываемому языку

Рассмотрев возможности нотаций IDEF0, DFD, ERD, Class Diagram, Use Case Diagram, Sequence Diagram, было выявлено, что ни одна из данных нотаций не подходит в полной мере для описания языка, который может быть трансформирован в язык для описания учебных бизнес-процессов. Однако в совокупности эти диаграммы эти диаграммы могут дать достаточно полное описание бизнес-процессов. Поэтому разрабатываемый язык будет создаваться на их основе.

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

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

1) название процесса;

2) реализуемая функция или их последовательность;

3) участники процесса;

4) ответственное лицо — владелец процесса;

5) входные и выходные потоки, а также их поставщики (или потребители);

6) требуемые ресурсы (производственные, технические, материальные, информационные);

7) определяющая цель процесса;

8) метрики процесса, точки и процедуры мониторинга.

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

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

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

Итак, ресурсы можно разделить на следующие виды:

1) Трудовой ресурс. Под трудовым ресурсов понимается сотрудник, который выполняет операцию или ответственен за ее выполнение.

2) Информационный ресурс. Информационный ресурс может регламентировать операцию или быть изменен или добавлен в процессе ее выполнения.

3) Продукт.

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

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

4) Финансовый ресурс. Финансовый ресурс может уменьшаться или увеличиваться с выполнением операции.

5) Оборудование. Отражает оборудование, необходимое для выполнения операции.

2.2 Проектирование языка

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

Первая метамодель будет представлять последовательность операций (карту операций) и включать в себя следующие объекты:

1) Начало БП. Итерация бизнес-процесса конечна, поэтому необходимо выделить начало и конец итерации, для чего используются объекты «Начало БП» и «Завершение БП».

2) Операция. Данный объект отражает активность в бизнес-процессе.

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

4) Завершение БП. Итерация бизнес-процесса конечна, поэтому необходимо выделить начало и конец итерации, для чего используются объекты «Начало БП» и «Завершение БП».

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

1) Контрагент. Данный объект отражает объекты внешней среды.

2) Операция. Данный объект отражает активность в бизнес-процессе.

3) Поток. Потоки отражают используемые и изменяемые ресурсы в операции.

4) Ресурс.

a. Трудовой ресурс. Трудовой ресурс выполняет операцию.

b. Информационный ресурс. Информационный ресурс может регламентировать операцию или быть изменен или добавлен в процессе ее выполнения.

c. Продукт.

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

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

d. Финансовый ресурс. Финансовый ресурс может уменьшаться или увеличиваться с выполнением операции.

e. Оборудование. Отражает оборудование, необходимое для выполнения операции.

2.2.1 Метамодель «Карта операций»

Граф будет включать в себя следующий свойства:

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

2) Цель бизнес-процесса, обозначенную как «Цель БП».

Далее необходимо описать атрибуты. Начнем с описания атрибутов для первой метамодели, которая представляет собой карту операций:

1) Для обозначения начала бизнес-процесса был создан конкретный объект «Начало БП» Итерация бизнес-процесса конечна, поэтому для того, чтобы выделить начало и конец итерации.

2) Для представления операции был создан конкретный объект «Операция». Данный объект содержит в себе следующие атрибуты:

a. «Название»: типа string. Отражает название операции.

b. «Номер»: типа number. Отражает идентификационный номер операции.

3) Для представления условия был создан конкретный объект «Условие». Данный объект содержит в себе атрибут «Вопрос» типа text, отражающий условие перехода.

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

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

6) Так как в начале бизнес-процесса может быть либо операция, либо условие, то создадим еще один абстрактный объект «Абстрактный объект 1», который будет контролировать, чтобы с объектом «Начало БП» мог быть связан только один из объектов «Операция» или «Условие».

Перейдем к описанию связей. В данной метамодели присутствуют два вида связей — ассоциация и наследование.

В первую очередь поговорим о наследовании. Ранее было сказано, что некоторые объекты обладают одинаковыми свойствами, и поэтому было принято решение создать абстрактные объекты с этими атрибутами. Однако для того чтобы конкретные объекты обладали этими свойствами необходимо провести связь наследования от конкретных объектов к абстрактным:

1) От конкретных объектов «Условие» и «Операция» к абстрактному объекту «Абстрактный объект 1».

2) От конкретного объекта «Завершение БП» к абстрактному объекту ««Абстрактный объект».

Помимо вышеперечисленных связей, «Абстрактный объект 1» наследуется от абстрактного объекта «Абстрактный объект». Данная связь необходима для того, чтобы с «Началом БП» мог быть связан только один из объектов «Условие» или «Операция», но при этом эти объекты также должны наследовать свойства «Абстрактного объекта», так как из объекта «Условие» может выходить не более двух связей к объектам «Условие», «Операция», «Завершение БП».

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

1) «Начало БП» и «Абстрактный объект 1». Данная связь отражает первый объект в бизнес-процессе.

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

3) «Операция» и «Завершение БП». Данная связь отражает завершающую операцию.

4) «Операция» и «Условие». Данная связь показывает, что у операции есть несколько выходов, которые при разных условиях приводят к разным операциям.

5) «Условие» и «Абстрактный объект». Данная связь показывает, при каком условии будет выполнена конкретная операция, следующее условие или бизнес-процесс завершится. В данной связи должен присутствовать ответ на заданный вопрос, который задается с помощью свойств связи в виде типа «fixed list», данное свойство содержит в себе два варианта «+» и «-».

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

Теперь перейдем непосредственно к описанию атрибутов объектов метамодели, описывающей каждую операцию отдельно:

1) Для представления операции был создан конкретный объект «Операция». Данный объект содержит в себе атрибут «Номер» типа number, отражающий идентификационный номер операции, который служит для связи двух метамоделей.

2) Для представления трудового ресурса был создан конкретный объект «Трудовой ресурс». Данный объект содержит в себе атрибут: «Зар. плата»: number — заработная плата трудового ресурса.

3) Для представления финансового ресурса был создан конкретный объект «Финансовый ресурс». Данный объект содержит в себе атрибут «Размер» типа number, который отражает необходимое количество финансовых средств.

4) Для представления информационного ресурса был создан конкретный объект «Информационный ресурс». Данный объект содержит в себе атрибут «Дата» типа string, который отражает дату создания/изменения последней версии документа.

5) Для представления товара был создан конкретный объект «Товар». Данный объект содержит в себе следующие данные:

a. «Количество»: number — количество товара в единицах измерения, указанных ниже.

b. «Единица измерения»: fixed list — единица измерения количества товара.

6) Для представления услуги был создан конкретный объект «Услуга». Данный объект содержит в себе следующие атрибуты:

a. «Объем»: number — затрачиваемое количество рабочих часов на выполнение услуги.

b. «Направленность»: fixed list — кому оказывается услуга.

7) Так как для ранее описанных объектов «Товар» и «Услуга» можно выделить один общий атрибут «Стоимость», необходимо создать абстрактный объект «Продукт», который отвечает за соответствующую информацию о продукте, а объекты «Товар» и «Услуга» наследуют ее. Данный объект содержит в себе атрибут «Стоимость» типа number, который отражает стоимость продукта.

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

9) Так как ранее описанные объекты «Продукт», «Трудовой ресурс», «Оборудование», «Финансовый ресурс», «Информационный ресурс» являются ресурсами, то мы решили создать для них общий абстрактный объект «Абстрактный ресурс», который не содержит атрибутов, но необходим для наглядности логики метамодели.

10) Для представления потока, был создан конкретный объект «Поток».

11) Для представления контрагента был создан объект «Контрагент».

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

Перейдем к описанию связей, которые присутствуют в данной метамодели. В первую очередь поговорим о наследовании. Раньше было сказано, что некоторые объекты обладают одинаковыми свойствами, и поэтому было принято решение создать абстрактные объекты с этими атрибутами. Однако для того чтобы наши конкретные объекты обладали этими свойствами необходимо провести связь наследования от конкретных объектов к абстрактным:

1) от объектов «Трудовой ресурс», «Информационный ресурс», «Финансовый ресурс» и «Оборудование» к абстрактному объекту «Абстрактный ресурс»;

2) от объектов «Поток», «Операция», «Контрагент» к абстрактному объекту «Объект абстрактный»;

3) от объектов «Услуга» и «Товар» к абстрактному объекту «Продукт».

Также присутствует связь наследования между абстрактными объектами:

1) от абстрактного объекта «Продукт» к абстрактному объекту «Абстрактный ресурс»;

2) от абстрактного объекта «Абстрактный ресурс» к абстрактному объекту «Объект абстрактный».

Благодаря этому отношению мы сможем создавать новые объекты на основе существующих.

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

1) «Поток» и «Абстрактный ресурс». Данная связь отражает влияние выходящего потока на некоторый ресурс.

2) «Абстрактный ресурс» и «Поток». Данная связь показывает участие некоторого ресурса в операции в виде входящего потока.

3) «Операция» и «Поток». Данная связь отражает выходящий поток

4) «Поток» и «Операция». Данная связь отражает входящий поток.

5) «Операция» и «Контрагент». Данная связь отражает взаимодействие с неким контрагентом.

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

7) «Трудовой ресурс» и «Операция». Данная связь показывает, кем выполняется операция.

8) «Операция» и «Оборудование». Данная связь показывает, какое оборудование используется в операции.

2.3 Правила разработки метамодели

В данном разделе будет подробно рассмотрен процесс создания метамодели при помощи DSM-платформы Metaedit+. Для этого нам необходимо проделать следующие шаги:

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

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

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

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

2.3.1 Создание графа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажимают на «Property» и из предложенного списка выбирают свойство.

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

моделирование язык бизнес процесс

В данном разделе будут представлены разработанные метамодели создаваемого языка. Метамодели создаются в соответствие с правилами, описанными в разделе 2.3.

2.4.1 Метамодель «Карта операций»

Последовательно выполняя действия описанные в разделе 2.3. была создана метамодель «Карта операций» (см. рис. 2.11), которая позволяет описать бизнес-процесс в виде последовательности операций.

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

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

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

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

4) «Условие» — ромб, с желтой заливкой и черным контуром, содержащий внутри текст, отражающий его свойство объекта «Условие» — «Вопрос».

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

1) «Старт» — стрелка, выходящая из объекта «Начало БП» к одному из объектов «Условие» или «Операция».

2) «Проверка условия» — стрелка, выходящая из объектов «Операция», «Начало БП» или «Условие» к объекту «Условие».

3) «Последовательность» — стрелка, выходящая из объекта «Операция» к самому себе.

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

5) «Результат проверки» — стрелка, выходящая из объекта «Условие» к объектам «Условие», «Операция» или «Завершение БП», на перегибе которой расположен круг с желтой заливкой и черным контуром. Внутри этого круга находится один из вариантов ответа «+» или «-».

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 Моделирование бизнес-процесса «Продажа товаров/услуг/работ» с помощью созданного языка

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

Модель бизнес-процесса представлена на рис 2.13 и 2.14.

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

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

Далее опишем операцию «Передача товара заказчику», в которой присутствует большее количество ресурсов. Данная операция выполняется менеджером по продажам, который руководствуется правилами СМК СТП 05 и закона о защите прав потребителей. В качестве входного потока выступает объект товар, а именно «1С:Бухгалтерия». Данный товар доставляется клиенту с помощью автотранспорта, в качестве выходного потока выступают два ресурса:

1) «1С:Бухгалтерия», количество которого уменьшилось.

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

Описание данной операции представлено на рисунке 2.16.

Заключение

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

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

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

1) Zichermann G. Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps / G. Zichermann, C. Conningham. Sebastopol. CA: O’Reilly Media, 2012.

2) Лядова Л. Н., Сухов А. О Курс по моделированию // Learning Management System. [Электронный ресурс] [Режим доступа: http://lms.hse.ru/userpage.php] [Проверено: 25.03.2014]

3) Громов А. И. «Анализ и моделирование бизнес-процессов»: учебно методический комплекс / А. И. Громов, В. Г. Чеботарев, Я. В. Горчаков, О. И. Бойко. М.: 2007.

4) Калянов Г. Н. Диаграммы «сущность-связь». Консалтинг при автоматизации предприятий: подходы, методы, средства. М.: ДМК-Пресс, 1997.

5) Викентьева О. Л., Дерябин А. И., Шестакова Л. В. КОНЦЕПЦИЯ СТУДИИ КОМПЕТЕНТНОСТНЫХ ДЕЛОВЫХ ИГР // Современные проблемы науки и образования — М.: НИУ ВШЭ, 2013.

6) Виды бизнес-процессов // Элсофт. [Электронный ресурс] [Режим доступа: https://sites.google.com/site/penzacons/stati/vidy-biznes-processov] [Проверено: 19.03.2014].

7) Ситникова, О. Нотация IDEF0, или матрёшка для бизнес-аналитика // ECM-Journal.ru. [Электронный ресурс] [Режим доступа: http://ecm-journal.ru/post/Glava-2-Notacija-IDEF0-ili-matrjoshka-dlja-biznes-analitika.aspx] [Проверено: 10.03.2014].

8) Буч Г. [Booch G.]. UML: руководство пользователя / Г. Буч [G. Booch], Д. Рамбо [J.Rambaugh]. Москва: ДМК-Пресс, 2001.