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

Управление складом. Такие действия как подборка и комплектация, упаковка, создание специальной упаковки/ярлыка для клиента и отгрузка товаров входят в понятие управление складом в рамках “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) видны интерфейсные транзакции, а также акторы, которые либо инициируют эти транзакции, либо их выполняют.

Результаты выполнения транзакций, производственные факты, представлены в таблице. Для каждого производственного факта указано наименование, которое будет являться его идентификатором при описании на языке 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 - в приложении.



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} - транзакцию «Оплата груза».

Если определенным образом добавить веса, то данную задачу можно свести к задаче о нахождении кратчайшего пути в нагруженном графе, решением которой и будет наилучшая комбинация компаний (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) Присваиваем ненулевым ребрам новые веса, равные разнице между максимальным значением и исходным значением веса.

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

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

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

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

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

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

Если все вершины посещены, алгоритм завершается. В противном случае, из ещё не посещённых вершин выбирается вершина 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 файлы и, в частности, были выделены возможные показатели, характеризующие качество выполнения транзакций.

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

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

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

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

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

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

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

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

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

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

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

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

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

Транзакция «Получение товара с основного склада»: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Заключение

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

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

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

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

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

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

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



Список используемой литературы

1. В.И. Носов, Т.В. Бернштейн. Элементы теории графов. Учебное пособие. - Новосибирск, 2008. - 107с.

2. Информационный сайт DEMO [Электронный ресурс]. - Режим доступа: http://www.demo.nl/

3. Информационный сайт Xemod Wiki [Электронный ресурс]. - Режим доступа: http://www.wiki.xemod.eu/wiki/Main_Page/

4. Dietz J.L.G DEMO Professional Course Material, 2010.

5. Dietz J.L.G. DEMO-3 Way of working, 2009.

6. Dietz J.L.G. DEMO-3 Models and representations, 2009.

7. Dietz J.L.G. Enterprise Ontology. Theory and Methodology, 2006.

8. G. Guizzardi, An Ontology-Based Semantics for the Motivation Extension to ArchiMate, Ph.D. Thesis. University of Twente, The Netherlands, 2005.

9. G. Guizzardi, Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The case of the ODE Software Process Ontology, Ph.D. Thesis. University of Twente, The Netherlands, 2008.

10. G. Guizzardi, Ontological Foundations for Structural Conceptual Models, Ph.D. Thesis. University of Twente, The Netherlands, 2011.

11. G. Guizzardi Some Applications of a Unified Foundational Ontology in Business Modeling, Ph.D. Thesis. University of Twente, The Netherlands, 2005.

12. G. Guizzardi Towards a Semantic Alignment of the ArchiMate Motivation Extension and the Goal-Question-Metric Approach, Ph.D. Thesis. University of Twente, The Netherlands, 2013.

13. G. Guizzardi Towards Ontological Foundations for Agent Modeling Concepts using UFO, Ph.D. Thesis. University of Twente, The Netherlands, 2004.

14. i-Cargo D1.3: i-Cargo Vision [Электронный ресурс]. - Режим доступа: http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D1.3%20iCargo%20Vision%20v1.0.pdf

15. i-Cargo D5.1: Business Cases Specifications [Электронный ресурс]. - Режим доступа: http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D5.1%20Business%20Cases%20Specification.pdf

16. i-Cargo D5.2: Pilot User Requirements [Электронный ресурс]. - Режим доступа:http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D5.2%20Pilot%20User%20Requirements.pdf

17. i-Cargo D7.1: Market Analysis [Электронный ресурс]. - Режим доступа:http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D7.1%20Market%20Analysis.pdf

18. i-Cargo D7.2: iCargo Reference Business Models [Электронный ресурс]. - Режим доступа: http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D7.2%20iCargo%20Reference%20Business%20Model.pdf

19. i-Cargo D7.3: Validation Approach and Metrics [Электронный ресурс]. - Режим доступа: http://i-cargo.eu/sites/i-cargo.eu/files/content-uploads/publications/iCargo_D7.3%20Validation%20Approach%20And%20Metrics.pdf

20. M. Horridge, H. Knublauch. A practical guide to building OWL ontologies using the Protйgй-OWL plugin and CO-ODE tooles, Edition 1.0, 2004.

21. OMG Business Motivation Model [Электронный ресурс]. - Режим доступа: http://www.omg.org/spec/BMM/1.1/

22. SPARQL Query Language for RDF [Электронный ресурс]. - Режим доступа: http://www.w3.org/TR/rdf-sparql-query/

23. Supply Chain Operations Reference Model, Section2, Metrics. [Электронный ресурс]. - Режим доступа: https://supply-chain.org/f/SCOR%209.0%20Metrics.pdf

24. Supply Chain Operations Reference Model, Overview Booklet. [Электронный ресурс]. - Режим доступа: https://supply-chain.org/f/SCOR%2090%20Overview%20Booklet.pdf

25. Poletaeva T., Babkin E. A., Abdulrab H. Ontological Framework Aimed to Facilitate Business Transformations, in: CEUR Workshop Proceedings (T.1301, 1st Joint Workshop ONTO.COM / ODISE on Ontologies in Conceptual Modeling and Information Systems Engineering co-located with 8th International Conference on Formal Ontology in Information Systems (FOIS 2014). Rio de Janeiro, Brazil, September 21, 2014) Vol. 1301: Ontologies in Conceptual Modeling and Information Systems Engineering (ONTO-COM-ODISE 2014). , 2014.

26. Wang Y., Transformation of DEMO models into exchangeable format, 2009.

27. Wiki: Алгоритм Дейкстры [Электронный ресурс]. - Режим доступа: https://ru.wikipedia.org/wiki/Алгоритм_Дейкстры

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

...