Ilustracja modelu MAPR

Można wyobrazić sobie sytuację, w której pewien klient chce kupić 500 komputerów przenośnych typu notebook (100 dla kadry wyższego szczebla, 100 dla średniego szczebla, 300 dla pozostałych pracowników) i 2000 komputerów stacjonarnych (1800 dla pracowników administracji, 190 dla informatyków, 10 dla grafików). Z uwagi na zróżnicowane potrzeby poszczególnych grup odbiorców komputery będą miały różne parametry. Przykładowo, menedżerowie potrzebują jednocześnie lekkich i wydajnych komputerów, natomiast informatycy komputerów z szybkim procesorem, a graficy z najlepszą kartą graficzną i pojemnym twardym dyskiem. Klient ma preferencje odnośnie do ceny (ma być konkurencyjna w stosunku do innych na rynku), terminu dostawy (7 dni roboczych), miejsca dostawy (oddziały zlokalizowane w 5 miastach Polski) i płatności (14 dni po odebraniu towaru). Mimo że przedstawiony scenariusz wydaje się pozornie prosty, to w rzeczywistości jest bardziej skomplikowany. Wymaga on zaangażowania różnych podmiotów, takich jak: producent sprzętu komputerowego, dostawcy komponentów (procesorów, płyt głównych, pamięci RAM itp.) i urządzeń peryferyjnych (klawiatura, myszka itp.), operator logistyczny, firma kurierska, ubezpieczeniowa itp.

Klient wprowadza zamówienie za pomocą specjalnego formularza umieszczonego na stronie internetowej. Korzyści z takiej formy składania zamówienia są obopólne. Z jednej strony, klient oszczędza czas, ponieważ nie musi być fizycznie obecny przy zakupach i ma możliwość skonfigurowania modelu komputera według własnych życzeń. Z drugiej strony, firma sprzedająca komputery ma w swoim systemie zamówienie w formie ustrukturyzowanej, które w bardzo prosty sposób może być przekazane za pomocą EDI (między dużymi firmami)

276 Fuks K., Kawa A., Wieczerzycki W., Dynamic Configuration and Management of e-Supply Chains… op. cit. s. 281-292; Wieczerzycki W., Obiektowe bazy danych do komputerowego wspomagania prac zespołowych, Wydawnictwo UEP, Poznań 1999, s. 82-84.

lub ebXML (między mniejszymi organizacjami) do innych podmiotów zaangażowanych w realizację zamówienia.277

Poniżej zostały opisane poszczególne kroki budowania łańcucha dostaw, który odpowiada powyższemu scenariuszowi. Warto zauważyć, że procedura ta jest na tyle uniwersalna, iż może być z powodzeniem stosowana w innych branżach (patrz rys. 4.1).

1. W pierwszej kolejności agent SA firmy przyjmującej zlecenie rozpoczyna poszukiwanie potencjalnych partnerów biznesowych (TP), którzy mogliby zrealizować zadanie według powyżej przedstawionego scenariusza. W tym celu przeglądane są ich profile, zawierające szczegółowe informacje o ich działalności. 2. Jeśli proces poszukiwania kończy się sukcesem, to SA informuje LA o potrzebie

utworzenia klastra w ramach PRH.

3. W kolejnym kroku LA buduje nowy klaster.

4. LA wyznacza agenta CA na lidera nowoutworzonego klastra.

5. CA zaprasza OA reprezentujących potencjalnych partnerów biznesowych do klastra.

Rys. 4.1. Budowanie łańcucha dostaw z wykorzystaniem technologii agentowej i rejestru publicznego

Źródło: Opracowanie własne.

277 Kawa A., Organizowanie łańcuchów dostaw z wykorzystaniem technologii agentowej na przykładzie branży

komputerowej, w: Współczesne wyzwania transportu w logistyce, Oficyna Wydawnicza Politechniki

Agenty OA, które nie konkurują ze sobą, mogą zacząć współpracować, aby zaproponować najlepszą ofertę dla lidera klastra. Przykładowo, firma która zajmuje się organizacją produkcji komputerów i ich projektowaniem dla firm flagowych, może zaprosić do współpracy innych dostawców. Agenty łączą więc swój potencjał w celu zbudowania tymczasowego i dynamicznego subklastra, który jest w stanie konkurować z innymi agentami przedsiębiorstw lub grupy przedsiębiorstw. Każdy subklaster ma swojego własnego koordynatora (CA), który zarządza procedurami i procesami selekcji oraz integruje potencjalnych OA w ramach konkretnego klastra. Dowolny OA może zainicjować utworzenie subklastra i objąć funkcję CA. Oferty poszczególnych agentów OA mogą się łączyć, ale także dzielić, w zależności od zmian szczegółów ofert innych klastrów, np. ceny, warunków dostawy. Jeśli po negocjacjach inne przedsiębiorstwo zaproponuje podobną cenę, ale lepsze warunki dostawy, wtedy CA tego klastra i jego subklastrów muszą zareagować na te nowe okoliczności i szukać alternatywnych OA, które zaproponują nowe warunki współpracy. Poszczególne OA i subklastry OA, które podlegają CA, pracują niezależnie w ramach swoich zadań. Przykładowo, OA działający w imieniu firmy logistycznej szuka do współpracy innych OA reprezentujących podmioty dysponujące wolnymi środkami transportowymi i przestrzenią na składowanie towarów w magazynach czy centrach dystrybucyjnych. Przed rozpoczęciem procesu negocjacji między CA klastra / subklastrów i niezależnych OA, CA musi zebrać wszystkie oferty od OA i wybrać z nich najlepszą.

Następna część konfigurowania łańcucha dostaw jest bardziej techniczna. Składa się ona z kilku etapów operacji przeprowadzanych przez agentów w rejestrze publicznym, które mają na celu ujednolicenie wspólnych scenariuszy współpracy (patrz rys. 4.2).

1. W pierwszym kroku Agent Walidator (VA) jednego partnera handlowego (TP-A) komunikuje się z VA drugiego partnera handlowego (TP-B) i informuje, które BSDM są wymagane do podjęcia współpracy (np. powiadomienie o potwierdzeniu wysłania przesyłki przez operatora logistycznego – ang. Notify of Shipping Order Confirmation278).

2. Następnie VA zleca liderowi (LA) utworzenie tymczasowego rejestru dla ujednoliconego BSDM.

3. LA buduje tymczasowy rejestr i nadaje uprawnienia administracyjne liderowi subklastra.

4. VA grupuje BSDM w aktualnych subrejstrach (ang. subregistries). Może to być np. wspomniany subrejestr z powiadomieniem o potwierdzeniu wysłania przesyłki.

278 Opis dokumentu “Notify of Shipping Order Confirmation” znajduje się w dokumentacji “Clusters, Segments and

PIPs. Version 02.06.00, 09 January 2009, RosettaNet Program Office”, http://www.rosettanet.org, dostęp

5. W kolejnym kroku wszystkie BSDM są ze sobą porównywane i modyfikowane tak, aby wypracować jedną, ujednoliconą wersję. Zadanie to polega na sprawdzeniu dokumentów przygotowanych w języku XML i wykryciu nieścisłości między nimi. Na rys. 4.3 i 4.4 pokazano przykładowe dokumenty, w których wykryto rozbieżności. W dokumencie 1 (patrz rys. 4.3) brakujące pole zostało zakreślone szarym kolorem. W tym przypadku VA poszczególnych właścicieli BSDM są proszeni o usunięcie lub dodanie brakujących danych (pole „UnitOfMeasure”). 6. Jeśli BSDM został zmieniony lub wykryto w nim braki, to musi być zweryfikowany

przez VA rezydującego w PRH. VA wykorzystuje do tego narzędzie RosettaNet

Validation Tool.

7. Następnie VA informuje agentów NA i EHA o efektach weryfikacji.

8. Jeśli weryfikacja zakończyła się sukcesem, to NA zawiadamia wszystkich partnerów handlowych zainteresowanych tą informacją.

9. Jeśli weryfikacja nie była pomyślna, to EHA przekazuje informację o tym do partnerów handlowych i umieszcza ją w rejestrze błędów. W tym przypadku VA przedsiębiorstwa A musi zacząć reorganizację procesu, biorąc pod uwagę powstałe błędy.

Rys. 4.2. Operacje przeprowadzane przez agentów w rejestrze publicznym Źródło: Opracowanie własne.

Dokument 1. (...) <ShippingConfirmation schemaVersion=""> (...) <ReportDateTime>2009-02-15T08:30:00+08:00</ReportDateTime> <ShipmentIdentifier>String</ShipmentIdentifier> <ShipmentReceiptLineItem schemaVersion=""> (...) <uuom:UnitOfMeasure (...)>1BF</uuom:UnitOfMeasure> </ShipmentReceiptLineItem> <dl:TrackingReference schemaVersion=""> (...) </dl:TrackingReference> <TransportedBy schemaVersion=""> (...) </TransportedBy> </ShippingConfirmation> (...)

Rys. 4.3. Przykład dokumentu “Notify of Shipping Order Confirmation” przygotowanego w języku, XML zgodnie z Partner Interface Processes (PIP 3B13), RosettaNet Standard

Źródło: Opracowanie własne na podstawie: Clusters, Segments and PIPs. Version 02.06.00, 09 January 2009, RosettaNet Program Office, http://www.rosettanet.org, dostęp 29.01.2009.

Dokument 2. (...) <ShippingConfirmation schemaVersion=""> (...) <ReportDateTime>2009-02-15T08:30:00+08:00</ReportDateTime> <ShipmentIdentifier>String</ShipmentIdentifier> <ShipmentReceiptLineItem schemaVersion=""> (...) </ShipmentReceiptLineItem> <dl:TrackingReference schemaVersion=""> (...) </dl:TrackingReference> <TransportedBy schemaVersion=""> (...) </TransportedBy> </ShippingConfirmation> (...)

Rys. 4.4. Przykład dokumentu “Notify of Shipping Order Confirmation” przygotowanego w języku XML, zgodnie z Partner Interface Processes (PIP 3B13), RosettaNet Standard, z brakującym polem

Oczywiście wszystkie procesy i procedury przedstawione wyżej odbywają się zgodnie ze standardami RosettaNet. Agenty komunikują się między sobą za pomocą języka programowania agentowego ACL (patrz punkt 4.2.6). Warto również zaznaczyć, że te „jednorazowe” łańcuchy dostaw i związane z nimi scenariusze współpracy mogą być użyte ponownie, zarówno między tymi samymi partnerami biznesowymi, jak również nowymi. Jest to możliwe dzięki zapisywaniu po zakończeniu współpracy wszystkich tymczasowych rejestrów w rejestrze partnerów (ang. Trading Partner Level Registry).

Proponowane podejście pokazuje, że bez konieczności dysponowania rozbudowanymi systemami informatycznymi, każdej wielkości przedsiębiorstwo może brać udział w dynamicznym łańcuchu dostaw. Chociaż zaprojektowany model obejmuje tyko przedsiębiorstwa stosujące standardy RosettaNet, to jest on na tyle uniwersalny, że może być z powodzeniem zaadaptowany przez inne organizacje gospodarcze.

4.2. Model systemu wieloagentowego zdecentralizowanego – ograniczonego,