Формализованные с помощью онтологий FEO и UFO-C бизнес-концепты и их взаимосвязи образуют новую метамодель (рис.10), описывающую бизнес-знания организаций в универсальном формате, доступном для понимания представителям бизнес-сегмента и удобном для интерпретации на машинном языке описания онтологий.

Рис.10. Графическое представление метамодели бизнес-знаний организации.

3.4 Описание формализованных бизнес-знаний на языке OWL

Итак, мы формализовали основные бизнес-концепты и взаимосвязи между ними и представили формализованные бизнес-знания в виде метамодели. Теперь нам нужно представить полученную метамодель в таком формате, чтобы можно было передать ее в качестве входного параметра для программного продукта, который бы легко и оперативно интерпретировал ее содержимое. Для реализации поставленной задачи был выбран OWL (Ontology Web Language) - язык для описания веб-онтологий на основе XML/Web стандарта [20].

Язык веб-онтологий OWL может быть использован для описания классов и отношений между ними, которые присущи для веб-документов и приложений. OWL базируется на более ранних языках OIL и DAML+OIL, и сейчас является рекомендуемым W3C. В основе языка лежит представление действительности в модели данных объект -- свойство. OWL используется не только для описания web страниц, но и любых объектов действительности. Каждому элементу описания в этом языке ставится в соответствие URI, связи между элементами организуются с помощью механизма reference системы на базе модели объект -- свойство.

Основные компоненты OWL включают классы, свойства и индивидуальные элементы.

1) Классы

Классы - это основные блоки онтологии OWL. Класс - это концепция в домене. Классы обычно образуют таксономическую иерархию (т.е. систему подкласс-надкласс). Классы определяются с помощью элемента owl:Class. В языке OWL существует два заранее определенных класса: owl:Thing и owl:Nothing. Первый из них является наиболее общим и включает все, второй - это пустой класс. Любой класс, определяемый пользователем, является подклассом класса owl:Thing и надклассом класса owl:Nothing.

OWL поддерживает шесть основных способов описания классов. Самый простой - это класс с именем (named). Другие типы - это классы пересечений (intersection), объединений (union), дополнений (complement), ограничений (restrictions) и классы перечислений (enumerated).

2) Свойства

Свойства включают две основные категории:

· свойства объекта (Object properties), которые связывают индивидуальные элементы между собой;

· свойства типов данных (Datatype properties), которые связывают индивидуальные элементы со значениями типов данных, такими как целые числа, числа с плавающей запятой и строки. Для определения типов данных OWL использует схему XML.

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

· функциональная: для любого объекта свойство может принимать только одно значение;

· обратно-функциональная: два различных индивидуальных элемента не могут иметь одно и то же значение;

· симметричная: если свойство связывает элемент А с элементом В, то из этого можно сделать вывод, что оно также связывает элемент В с элементом А;

· транзитивная: если свойство связывает элемент А с элементом В, а элемент В с элементом С, то можно предположить, что оно также связывает элемент А с элементом С.

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

3) Индивидуальные элементы

Индивидуальные элементы - это элементы классов; свойства могут связывать их друг с другом. Индивидуальный элемент связывается с тем классом, к которому он принадлежит, с помощью элемента rdf:type (свойство RDF).

В качестве среды для создания метамодели в формате OWL был выбран Protйgй - редактор онтологий и фреймворк для построения баз знаний. Платформа Protйgй поддерживает два основных способа моделирования онтологий посредством редакторов Protйgй-Frames и Protйgй-OWL. Онтологии, построенные в Protйgй, могут быть экспортированы во множество форматов, включая RDF (RDF Schema), OWL и XML Schema. Protйgй имеет открытую, легко расширяемую архитектуру за счёт поддержки модулей расширения функциональности.

В соответствии с описанной выше метамоделью с помощью редактора онтологий Protйgй был создан документ (Приложение 1), описывающий на языке web-онтологий OWL следующие классы и свойства (Object Properties).



Классы:

· Mission.	· Indicator.
· Vision.	· Action.
· DesiredResult.	· Agent.
· Goal.	· Plan.
· Strategy.	· NormativeDescription.
· Actor.	· Proposition.
· Transaction.	· Intention.
· Directive.	· Desire.
· BusinessPolicy.	· IntentionalMoment.
· BusinessRule.	· Indicator.

Свойства (связи между классами):

· hasPart.	· isAdjusting.
· hasWhole.	· isCausedBy.
· hasPropositionalContent.	· isCausing.
· isPropositionalContent.	· isDescribedBy.
· hasSetPart.	· isDescribing.
· hasSetWhole.	· isPerformedBy.
· isAdjustedBy.	· isPerforming.

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



4. ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ С ПОМОЩЬЮ МЕТОДОЛОГИИ DEMO

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

4.1 Процесс доставки в логистической сети в модели SCOR

Supply Chain Operations Reference model (SCOR) - референтная модель операций в цепях поставок, разработана международным Советом по цепям поставок (Supply Chain Counsil, сокращенно - SCC) в качестве межотраслевого стандарта управления цепями поставок.

Международный Совет по цепям поставок был создан в 1996 году как независимая некоммерческая организация; на сегодняшний день в него входят уже 800 ведущих компаний мира, среди которых производители, дистрибьюторы, провайдеры логистических услуг, разработчики программного обеспечения [24].

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

SCOR основана на:

· стандартном описании процессов управления цепями поставок,

· стандартизации взаимоотношений между бизнес-процессами,

· стандартных метриках, позволяющие измерить и сравнить показатели эффективности (производительности) процессов,

· практиках управления цепями поставок, которые помогают достичь «best-in-class» результатов.

Формализм SCOR основан на выделении пяти базисных бизнес-процессов: Plan, Source, Make, Deliver, Return. В рамках данной работы будет рассмотрен только процесс доставки - Deliver. Согласно модели SCOR этот процесс состоит из управления заказами, управления складом и транспортировкой.

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

Управление складом. Такие действия как подборка и комплектация, упаковка, создание специальной упаковки/ярлыка для клиента и отгрузка товаров входят в понятие управление складом в рамках “deliver”.

Управление транспортировкой и доставкой. Под управлением транспортировкой понимаются управление перевозками. Инфраструктура доставки определяется правилами управления каналами, правилами управления заказами, управлением товарами для доставки и управлением качеством доставки.

В соответствии с моделью SCOR процесс доставки включает следующие этапы:

· Запас ресурсов и планирование даты доставки.

· Выбор транспорта.

· Выбор маршрута.

· Упаковка груза.

· Загрузка транспорта.

· Транспортировка.

· Получение и валидация полученного груза.

4.2 Описание бизнес-процесса доставки с помощью методологии DEMO

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

Вариация 1. Продукт находится на промежуточном складе

В этом случае логистическая цепочка имеет вид:

Получение продукта с промежуточного склада -> Погрузка продукт на товарный поезд -> Транспортировка -> Верификация -> Оплата

Вариация 2. Продукт находится на основном складе

Получение продукта с основного склада -> Погрузка продукта на грузовой автомобиль -> Транспортировка -> Верификация -> Оплата

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

Получение продукта из производственного цеха -> Упаковка -> Погрузка продукт на товарный поезд -> Транспортировка -> Верификация -> Оплата

Вариация 4. Продукт получен от внешнего поставщика

Получение продукта от внешнего поставщика -> Конфигурация -> Валидация -> Упаковка -> Погрузка продукт на товарный поезд -> Транспортировка -> Верификация -> Оплата

На основании проведенного анализа ключевых типов транзакций в бизнес-процессе доставки в логистической сети была построена одна аспектная модель - модель взаимодействия, которая представляет онтологическое знание организации - для различных вариаций бизнес-процесса. Модель была построена с помощью среды моделирования Xemod 2010 v2.0 (1.2.0.100) в соответствии со стандартом DEMO-3, финальная версия которого была представлена автором методологии, профессором J.L.Dietz, 11 мая 2012 года в университете Технологий города Дельфта для всех членов института Enterprise Engineering institute, носящих звание DEMO Master.

На диаграммах Actor Transaction Diagram (ATD) видны интерфейсные транзакции, а также акторы, которые либо инициируют эти транзакции, либо их выполняют (рис. 11 - 14).

Рис.11. ATD для бизнес-процесса доставки, вариация 1.

Рис.12. ATD для бизнес-процесса доставки, вариация 2.



Рис.13. ATD для бизнес-процесса доставки, вариация 3.

Рис.14. ATD для бизнес-процесса доставки, вариация 4.

Результаты выполнения транзакций, производственные факты, представлены в таблице (Табл.2). Для каждого производственного факта указано наименование, которое будет являться его идентификатором при описании на языке OWL.

Таблица 2.

Transaction Results Table & Production Facts additional names.

Transaction Kind	Result Kind	Production Fact additional name
B-T01 - Receive product from external supplier	B-R01 - [product] is received from external supplier	PF-Receive product from ext supplier
B-T02 - Configure product	B-R02 - [product] is configured	PF-Configure product
B-T03 - Validate product	B-R03 - [product] is validated	PF-Validate product
B-T04 - Pack product	B-R04 - [product] is packed	PF-Pack product
B-T05 - Load product to truck	B-R05 - [product] is loaded to truck	PF-Load product to truck
B-T06 - Transfer product	B-R06 - [product] is transferred	PF-Transfer product
B-T07 - Verify product	B-R07 - [product] is verified	PF-Verify product
B-T08 - Payment	B-R08 - [product] is paid	PF-Payment
B-T09 - Receive product from Make	B-R09 - [product] is received from Make	PF-Receive product from Make
B-T10 - Pick product form main warehouse	B-R10 - [product] is picked from main warehouse	PF-Pick product from main warehouse
B-T11 - Pick product from intermediate warehouse	B-R11 - [product] is picked from intermediate warehouse	PF-Pick product from int warehouse
B-T12 - Load product to train	B-R12 - [product] is loaded to train	PF-Load product to train

4.3 Описание бизнес-процесса доставки на языке OWL с помощью онтологии FEO

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

К существующим элементам были добавлены новые сущности типа IndividualType, представляющие конкретные транзакции и производственные акты, а также добавлен новый подкласс класса TupleType стандарта IDEAS - productionFactBeforeAfter, для описания отношений «parent-child» между производственными фактами. Графическая интерпретация полученной модели представлена и описание модели на языке owl - в приложении (Приложение 2).



5. РАЗРАБОТКА АЛГОРИТМА ПОИСКА НАИЛУЧШИХ ПАРТНЕРОВ В ЛОГИСТИЧЕСКОЙ СЕТИ

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

5.1 Сведение к задаче о поиске кратчайшего пути в нагруженном графе

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

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

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

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

Smax = ?cv(Initiator_i,Executor_i)>max, i:1..n, (1)

где n - количество транзакций в выбранной цепочке.

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

Smin = ?(max - cv(Initiator_i,Executor_i))>max, i:1..n, (2)

где n - количество транзакций в выбранной цепочке;

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

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

Например, если рассматривать логистическую сеть и процесс доставки груза, {A₁, A₂, .., A_n} - компании, которые могут выполнять транзакцию «Упаковка груза», а компании {Z₁, Z₂, .., Z_n} - транзакцию «Оплата груза».

Рис.15. Задача поиска наилучших партнеров в сети.

Если определенным образом добавить веса, то данную задачу можно свести к задаче о нахождении кратчайшего пути в нагруженном графе, решением которой и будет наилучшая комбинация компаний (A_i, B_j, …, Z_k) для данного клиента.

Обозначим вес ребра между двумя вершинами vi и vj через w(vi, vj). Необходимо выбрать веса таким образом, чтобы минимальное суммарное значение веса, равное сумме весов w(A_i, B_j), w(B_j, C_l), и т.д. соответствовало наиболее взаимовыгодной конфигурации компаний-участников сети.

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

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

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

В стандарте SCOR выделяется ряд показателей KPI, характеризующих качество выполнения транзакций, сгруппированных по категориям: Reliability, Responsiveness, Costs и др. [23]. Для вычисления степени выгодности сотрудничества двух компаний, или степени связанности, в рамках указанной транзакции будем использовать следующий алгоритм:

1) Просуммировать количество показателей KPI по каждой категории (вес категории) для данной транзакции. Повторить для каждой компании.

2) Рассчитать степень связанности двух компаний как сумму совпадающих весов категорий по всем категориям.

Таким образом, первый шаг к определению весов на ребрах графа это вычисление так называемой степени связанности (connectivity degree). Например, рассмотрим логистическую сеть, ребро (A_i, B_j). Данное ребро соответствует следующему утверждению: «Инициатором транзакции типа B выступает компания A₁, исполнителем - компания B₂». Мы с помощью SPARQL запросов к моделям бизнес-знаний обеих компаний, описанных в формате OWL, можем получить информацию о показателях, которые компании A₁ и B₂ используют, для оценки качества выполняемых действий. Далее, используя описанный ранее алгоритм, мы вычисляем степень выгодности сотрудничества этих компаний в рамках транзакции B и записываем его в показатель степени связанности (connectivity degree), обозначенный нами ранее в виде cv(A_i,B_j). Важно отметить, что ребрам, направленным к вершине Fin, мы присваиваем нулевое значение.

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

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

1) Найти ребро с максимальным весом и записать его значение в max.

2) Чтобы избежать операций с нулем, увеличиваем значение max на единицу.

3) Присваиваем ненулевым ребрам новые веса, равные разнице между максимальным значением и исходным значением веса.

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

Рис.16. Задача о минимальном пути в нагруженном графе

5.2 Алгоритм Дейкстры поиска кратчайшего пути

Алгоритм Дейкстры (англ. Dijkstra's algorithm) -- алгоритм на графах, изобретённый нидерландским ученым Э. Дейкстрой в 1959 году. Находит кратчайшее расстояние от одной из вершин графа до всех остальных. Алгоритм работает только для графов без рёбер отрицательного веса. Алгоритм широко применяется в программировании и технологиях.

В ориентированном взвешенном графе G = (V, E), вес рёбер которого неотрицателен и определяется весовой функцией w: E > R, алгоритм Дейкстры находит длины кратчайших путей из заданной вершины s до всех остальных [27]. Графическая интерпретация алгоритма представлена в виде блок-схемы (рис.17), неформальное описание алгоритма представлено далее.

Каждой вершине из V сопоставим метку -- минимальное известное расстояние от этой вершины до заданной, обозначим ее a. Алгоритм работает пошагово -- на каждом шаге он «посещает» одну вершину и пытается уменьшать метки. Работа алгоритма завершается, когда все вершины посещены.

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

Рис.17. Блок-схема алгоритма Дейкстры.

Если все вершины посещены, алгоритм завершается. В противном случае, из ещё не посещённых вершин выбирается вершина u, имеющая минимальную метку. Мы рассматриваем всевозможные маршруты, в которых u является предпоследним пунктом. Вершины, в которые ведут рёбра из u, назовем соседями этой вершины. Для каждого соседа вершины u, кроме отмеченных как посещённые, рассмотрим новую длину пути, равную сумме значений текущей метки u и длины ребра, соединяющего u с этим соседом. Если полученное значение длины меньше значения метки соседа, заменим значение метки полученным значением длины. Рассмотрев всех соседей, пометим вершину u как посещенную и повторим шаг алгоритма.

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



6. ПРИМЕНЕНИЕ АЛГОРИТМА ПОИСКА НАИЛУЧШИХ ПАРТНЕРОВ В ЛОГИСТИЧЕСКОЙ СЕТИ НА ПРИМЕРЕ БИЗНЕС-КЕЙСА

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

6.1 Бизнес-кейс

Итальянская компания General Ricambi S.p.A. владеет сетью магазинов, предлагающих широкий ассортимент запчастей для автомобилей. Недавно General Ricambi стала участником логистической сети и теперь может пользоваться услугами своих партнеров для доставки своего товара в другие регионы.

Другими участниками логистической сети являются компании, представленные далее.

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

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

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

d-Pack Engineering GmbH является преемником и последователем компании Pees Engineering, которая уже на протяжении 40 лет успешно производит упаковочные машины. Компания продает и предоставляет в аренду специальные машины для автоматической упаковки продукции в транспортные пакеты.

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

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

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

Road Carriers осуществляет перевозку грузов с помощью грузовиков по демократичным ценам.

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

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

6.2 Формализация взаимосвязей между бизнес концептами в бизнес-кейсе

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

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

Таблица 3.

Транзакции и KPI.

Транзакция	Категория	KPI	Описание
Получение продукта от внешнего поставщика	RL	Delivery Item Accuracy	Процент заказов, в которых все компоненты продукта доставлены полностью, т.е. нет недостающих и нет лишних
	RL	Delivery Quantity Accuracy	Процент заказов, в которых количество доставленных единиц товара соответствует количеству единиц товара, указанному в заказе
	RL	Orders Delivered Damage Free Conformance	Количество заказов, доставленных в целостности, без повреждений
	RL	% correct material	Процент заказов, содержащих необходимую документацию
Конфигурация продукта	RS	Configuration Product Cycle Time	Среднее время, затрачиваемое на конфигурацию продукта
	CO	Cost to Configure Product	Суммарное количество затрат на выполнение конфигурации продукта
Валидация продукта	CO	Cost to Validate Product	Суммарное количество затрат на выполнение валидации продукта
	RS	Validation Product Cycle Time	Среднее время, затрачиваемое на валидацию продукта
Получение продукта из производственного цеха	RL	% correct material	Процент заказов, содержащих необходимую документацию
Упаковка	RL	% correct material	Процент заказов, содержащих необходимую документацию
	RS	Pack Product Cycle Time	Среднее время, затрачиваемое на упаковку продукта
	CO	Cost to Pack Product	Суммарное количество затрат на выполнение упаковки продукта
Получение товара с основного склада	RL	Fill Rate	Процент заказов, полученных со склада и доставленных в течение 24 часов с момента заказа
	RS	Pick Product Cycle Time	Среднее время, затрачиваемое на получение товара со склада
	CO	Cost to Pick Product	Суммарное количество затрат на выполнение операции получения товара со склада
Погрузка на товарный грузовик	RS	Loading Product Cycle Time	Среднее время, затрачиваемое на погрузку товара
	CO	Cost to Load Product	Суммарное количество затрат на выполнение погрузки товара
Получение товара с промежуточного склада	CO	Cost to Pick Product	Суммарное количество затрат на выполнение процедуры получения товара со склада.
	RL	Fill Rate	Процент заказов, полученных со склада и доставленных в течение 24 часов с момента заказа
	RS	Pick Product Cycle Time	Среднее время, затрачиваемое на получение товара со склада
Погрузка товара на товарный поезд	RS	Loading Product Cycle Time	Среднее время, затрачиваемое на погрузку товара
	CO	Cost to Load Product	Суммарное количество затрат на выполнение погрузки товара
Транспортировка	RL	Delivery Item Accuracy	Процент заказов, в которых все компоненты продукта доставлены полностью, т.е. нет недостающих и нет лишних
	RL	Delivery Quantity Accuracy	Процент заказов, в которых количество доставленных единиц товара соответствует количеству единиц товара, указанному в заказе
	RL	Orders Delivered Damage Free Conformance	Количество заказов, доставленных в целостности, без повреждений
	RS	Ship Product Cycle Time	Среднее время, затрачиваемое на транспортировку
	CO	Cost to Ship Product	Суммарное количество затрат на выполнение транспортировки
	RL	Customer Commit Date	Процент заказов, доставленных вовремя
Установка и верификация товара	RL	% Of Faultless Installations	Процент повреждений, произошедших в процессе установки и верификации товара
	RS	Installation Product Cycle Time	Среднее время, затрачиваемое на установку и верификацию продукта
	CO	Cost to Install Product	Суммарное количество затрат на выполнение установки и верификации продукта

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

Таблица 4.

Перечень транзакций и KPI по каждой компании.

Компания	Выполняемые транзакции	Список показателей
BF Germany	Получение продукта из производственного цеха	-
	Получение продукта с основного склада	Fill Rate, Pick Product Cost, Pick Product Cycle Time
CS Germany	Получение продукта с основного склада	Fill Rate, Pick Product Cost
	Верификация и инсталляция продукта	Percent of Faultless Installations
Agopex gmbh	Верификация и инсталляция продукта	Installation Product Cost, Installation Product Cycle Time, Percent of Faultless Installations
d-Pack Engineering GmbH	Упаковка	Fill Rate, Pack Product Cycle Time, Pack Product Cost
	Погрузка на товарный поезд	Load Product Cost, Load Product Cycle Time
	Погрузка на товарный грузовик	Load Product Cost, Load Product Cycle Time
GTS Rail	Получение продукта с основного склада	Fill Rate
	Погрузка на товарный поезд	Load Product Cost, Load Product Cycle Time
	Транспортировка	Customer Commit Date, Ship Product Cost, Ship Product Cycle Time, Orders Delivered Damage Free Conformance
Road Carriers	Транспортировка	Customer Commit Date, Orders Delivered Damage Free Conformance
IFB	Упаковка	Fill Rate, Pack Product Cycle Time, Pack Product Cost, Percent of Correct Material
DHL	Транспортировка	Customer Commit Date, Ship Product Cost, Ship Product Cycle Time, Orders Delivered Damage Free Conformance, Delivery Item Accuracy, Delivery Quantity Accuracy
	Погрузка на товарный поезд	Load Product Cost, Load Product Cycle Time
MDF-Group	Верификация и инсталляция продукта	Installation Product Cost, Installation Product Cycle Time, Percent of Faultless Installations
EBF	Погрузка на товарный грузовик	Load Product Cost
	Транспортировка	Customer Commit Date, Delivery Item Accuracy, Delivery Quantity Accuracy
General Ricambi S.p.A.	Оплата товара	Customer Commit Date, Ship Product Cost, Ship Product Cycle Time, Orders Delivered Damage Free Conformance, Delivery Item Accuracy, Delivery Quantity Accuracy, Load Product Cost, Load Product Cycle Time, Fill Rate, Pack Product Cycle Time, Pack Product Cost, Percent of Correct Material, Installation Product Cost, Installation Product Cycle Time, Percent of Faultless Installations, Pick Product Cost, Pick Product Cycle Time



6.3 Построение графа для бизнес-кейса

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

Из описания кейса нам известна, что компания General Ricambi S.p.A. является производителем определенного вида продукта, и единственная транзакция, которую она выполняет - это получение оплаты за товар. Следовательно, необходимо рассматривать последовательности производственных фактов, содержащие производственный факт «PF-Payment».

Как видно на рис.18, производственный факт «PF-Payment» содержится во всех существующих последовательностях. Теперь, зная последовательности производственных фактов, мы можем получить цепочки транзакций.

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



Рис.18. Дерево производственных фактов.

Таким образом, в рамках данного кейса доступны две цепочки транзакций:

Вариация 2. Продукт находится на основном складе

Получение продукта с основного склада -> Погрузка продукта на грузовой автомобиль -> Транспортировка -> Верификация -> Оплата

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

Получение продукта из производственного цеха -> Упаковка -> Погрузка продукт на товарный поезд -> Транспортировка -> Верификация -> Оплата

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

Рис.19. Дерево производственных фактов с выделенными доступными последовательностями.

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

Транзакция «Получение товара с основного склада»: BF Germany (A₁), CS Germany (A₂); GTS Rail (A₃).

Транзакция «Погрузка продукта на товарный грузовик»: d-Pack Engineering GmbH (B₁); EBF (B₂).

Транзакция «Транспортировка»: GTS Rail (C₁), Road Carriers (C₂), EBF (C₃), DHL (C₄);

Транзакция «Верификация и инсталляция продукта»: Agopex gmbh (D₁), MDF-Group (D₂), CS Germany (D₃).

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

cv(Source, A₁) = cv(Source, BF Germany) = 2

cv(Source, A₂) = cv(Source, CS Germany) = 1

cv(Source, A₃) = cv(Source, GTS Rail) = 1

cv(A₁, B₁) = cv(BF Germany, Pack Engineering GmbH) = 3

cv(A₂, B₁) = cv(CS Germany, Pack Engineering GmbH) = 2

cv(A₃, B₁) = cv(GTS Rail, Pack Engineering GmbH) = 3

cv(A₁, B₂) = cv(BF Germany, EBF) = 1

cv(A₂, B₂) = cv(CS Germany, EBF) = 1

cv(A₃, B₂) = cv(GTS Rail, EBF) = 1

cv(B₁, C₁) = cv(Pack Engineering GmbH, GTS Rail) = 6

cv(B₂, C₁) = cv(EBF, GTS Rail) = 5

cv(B₁, C₂) = cv(Pack Engineering GmbH, Road Carriers) = 3

cv(B₂, C₂) = cv(EBF, Road Carriers) = 3

cv(B₁, C₃) = cv(Pack Engineering GmbH, EBF) = 3

cv(B₂, C₃) = cv(EBF, EBF) = 4

cv(B₁, C₄) = cv(Pack Engineering GmbH, DHL) = 6

cv(B₂, C₄) = cv(EBF, DHL) = 6

cv(C₁, D₁) = cv(GTS Rail, Agopex gmbh) = 5

cv(C₂, D₁) = cv(Road Carriers, Agopex gmbh) = 3

cv(C₃, D₁) = cv(EBF, Agopex gmbh) = 4

cv(C₄, D₁) = cv(DHL, Agopex gmbh) = 5

cv(C₁, D₂) = cv(GTS Rail, MDF-Group) = 5

cv(C₂, D₂) = cv(Road Carriers, MDF-Group) = 3

cv(C₃, D₂) = cv(EBF, MDF-Group) = 4

cv(C₄, D₂) = cv(DHL, MDF-Group) = 5

cv(C₁, D₃) = cv(GTS Rail, CS Germany) = 2

cv(C₂, D₃) = cv(Road Carriers, CS Germany) = 2

cv(C₃, D₃) = cv(EBF, CS Germany) = 2

cv(C₄, D₃) = cv(DHL, CS Germany) = 2

cv(D₁, End) = cv(Agopex gmbh, End) = -1

cv(D₂, End) = cv(MDF-Group, End) = -1

cv(D₃, End) = cv(CS Germany, End) = -1

На втором шаге выбираем максимальный вес: Max = 6 + 1 = 7 и выполняем операцию вычитания:

cv(Source, A₁) = cv(Source, BF Germany) = 5

cv(Source, A₂) = cv(Source, CS Germany) = 6

cv(Source, A₃) = cv(Source, GTS Rail) = 6

cv(A₁, B₁) = cv(BF Germany, Pack Engineering GmbH) = 4

cv(A₂, B₁) = cv(CS Germany, Pack Engineering GmbH) = 5

cv(A₃, B₁) = cv(GTS Rail, Pack Engineering GmbH) = 4

cv(A₁, B₂) = cv(BF Germany, EBF) = 6

cv(A₂, B₂) = cv(CS Germany, EBF) = 6

cv(A₃, B₂) = cv(GTS Rail, EBF) = 6

cv(B₁, C₁) = cv(Pack Engineering GmbH, GTS Rail) = 1

cv(B₂, C₁) = cv(EBF, GTS Rail) = 2

cv(B₁, C₂) = cv(Pack Engineering GmbH, Road Carriers) = 4

cv(B₂, C₂) = cv(EBF, Road Carriers) = 4

cv(B₁, C₃) = cv(Pack Engineering GmbH, EBF) = 4

cv(B₂, C₃) = cv(EBF, EBF) = 3

cv(B₁, C₄) = cv(Pack Engineering GmbH, DHL) = 1

cv(B₂, C₄) = cv(EBF, DHL) = 1

cv(C₁, D₁) = cv(GTS Rail, Agopex gmbh) = 2

cv(C₂, D₁) = cv(Road Carriers, Agopex gmbh) = 4

cv(C₃, D₁) = cv(EBF, Agopex gmbh) = 3

cv(C₄, D₁) = cv(DHL, Agopex gmbh) = 2

cv(C₁, D₂) = cv(GTS Rail, MDF-Group) = 2

cv(C₂, D₂) = cv(Road Carriers, MDF-Group) = 4

cv(C₃, D₂) = cv(EBF, MDF-Group) = 3

cv(C₄, D₂) = cv(DHL, MDF-Group) = 2

cv(C₁, D₃) = cv(GTS Rail, CS Germany) = 5

cv(C₂, D₃) = cv(Road Carriers, CS Germany) = 5

cv(C₃, D₃) = cv(EBF, CS Germany) = 5

cv(C₄, D₃) = cv(DHL, CS Germany) = 5

cv(D₁, End) = cv(Agopex gmbh, End) = 8

cv(D₂, End) = cv(MDF-Group, End) = 8

cv(D₃, End) = cv(CS Germany, End) = 8

В результате получаем нагруженный граф, представленный на рис. 20.

Рис.20. Нагруженный граф.

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

Для заданного бизнес-кейса наилучшая конфигурация сети предполагает назначение следующих исполнителей для указанных транзакций:

1) Транзакция «Получение продукта с основного склада», исполнитель - компания BFGermany,

2) Транзакция «Погрузка продукта на товарный грузовик», исполнитель - компания PackEngineeringGMBH,

3) Транзакция «Транспортировка», исполнитель - DHL,

4) Транзакция «Верификация продукта», исполнитель - MDFGroup.

Рис.21. Решение задачи о поиске кратчайшего пути в нагруженном графе.

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

Для программной реализации алгоритма поиска партнеров для взаимовыгодного взаимодействия в логистической сети был выбран объектно-ориентированный язык Java и среда разработки Eclipse Kepler. Код программы представлен в приложении (Приложение 3).

Для обработки и получения информации из owl файлов в коде использовался язык SPARQL (SPARQL Protocol and RDF Query Language) -- язык запросов к данным, представленным по модели RDF, а также протокол для передачи этих запросов и ответов на них. SPARQL является рекомендацией консорциума W3C и одной из технологий семантической паутины.

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

Рис.22. Загрузка файла с данными клиента.

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

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

1) Транзакция «Получение продукта с основного склада», исполнитель - компания BFGermany,

2) Транзакция «Погрузка продукта на товарный грузовик», исполнитель - компания PackEngineeringGMBH,

3) Транзакция «Транспортировка», исполнитель - DHL,

4) Транзакция «Верификация продукта», исполнитель - MDFGroup.

Рис.23. Полученное решение.



ЗАКЛЮЧЕНИЕ

В заключение следует подвести итоги по проведенной научно-исследовательской работе.

В ходе выполнения работы были рассмотрены метамодель OMG Business Motivation Model и метамодель DEMO, на основе которых были выделены основные бизнес-концепты и их взаимосвязи.

Также были рассмотрены фундаментальная онтология Unified Fundamental Ontology и формальная онтология Formal Enterprise Ontology. С помощью концептуальных схем данных онтологий были формализованы ключевые бизнес-концепты метамодели OMG BMM. Полученная в результате формализации метамодель бизнес-знаний была описана на языке OWL.

Кроме того, в рамках дан...