Integracja JDLM i LOGFAS dla planowania zaopatrzenia koalicji

Operacje koalicyjne stoją lub upadają na zaopatrzeniu. Wielonarodowa grupa zadaniowa może być taktycznie znakomita, a mimo to stanąć w miejscu, ponieważ paliwo nie dotarło do właściwego węzła, ponieważ medyczna klasa VIII przeniosła się niezauważona pomiędzy dwoma narodowymi magazynami albo ponieważ plan transportu jednego państwa zakładał drogę, której inżynierowie drugiego państwa jeszcze nie naprawili. Koszt źle zaplanowanego wielonarodowego zaopatrzenia mierzy się utratą zdolności bojowych — nie błędami w arkuszach kalkulacyjnych.

Odpowiedzią NATO na ten problem jest LOGFAS — pakiet Logistics Functional Area Services — oraz niewielka konstelacja narzędzi wspierających. Amerykańską odpowiedzią, o szerszym zasięgu połączonym i międzyresortowym, jest JDLM. W praktyce każde wdrożenie koalicyjne musi integrować oba systemy, a do tego rodzime ERP-y państw uczestniczących. Ten artykuł jest inżynierskim przewodnikiem po tym, jak ta integracja naprawdę działa, co się psuje i co wytrzymuje.

Problem zaopatrzenia koalicyjnego

Armie narodowe nie federują się automatycznie. Każda prowadzi własny ERP — w jednych SAP, w innych Oracle EBS, gdzieniegdzie IFS, w większej liczbie przypadków niż się przyznaje — własne starsze, dedykowane systemy. Każda ma własny katalog materiałowy, własne mapowanie NSN na kody lokalne, własny schemat transportu, własne zasady klauzul tajności. Gdy dwa państwa powołują połączoną wielonarodową grupę zadaniową, nic z tego nie układa się samo.

Historycznym obejściem był LOGREP — LOGistics REPort — wymieniany jako płaski plik na konferencjach planistycznych. LOGREP stał się walutą koalicji: niedoskonałą, stratną, ale uzgodnioną. Force List danego państwa, gotowość zasobów, prognoza zużycia oraz plan ruchu wszystko sprowadza się do wpisów LOGREP, które inni partnerzy koalicyjni mogą odczytać. Dziś LOGREP wciąż jest lingua franca, ale wymiana przeniosła się z papieru i poczty elektronicznej do LOGFAS i protokołów wokół niego.

Głębszym problemem jest to, że narodowe ERP-y nigdy nie były budowane po to, by udostępniać swoje wnętrze koalicji. Ich dane są wrażliwe, ich schematy są tajemnicą handlową, a ich operatorzy nie są upoważnieni do ich publikowania. Federację trzeba zaprojektować — sama się nie pojawia.

Przegląd komponentów LOGFAS

LOGFAS to nie jedna aplikacja. To pakiet rozprowadzany przez NATO Communications and Information Agency (NCIA), z czterema komponentami istotnymi dla każdego projektu integracyjnego.

LOGREP to model danych i baza danych. Definiuje encje — Force Modules, Holdings, Requirements, Stockpiles, Movement Requirements — oraz relacje między nimi. Każdy inny komponent LOGFAS odczytuje lub zapisuje LOGREP. Kiedy inżynierowie mówią „zintegruj z LOGFAS”, prawie zawsze mają na myśli „wyprodukuj lub konsumuj zawartość bazy LOGREP”.

ADAMS (Allied Deployment and Movement System) to powierzchnia planistyczna. ADAMS konsumuje LOGREP, nakłada sieć tras, środków transportu i zasobów transportowych, a w wyniku produkuje plany ruchu — kto co przewozi, jakim środkiem, do którego węzła pośredniego, w którym dniu. To w ADAMS planiści koalicyjni spędzają godziny w fazie wdrożenia.

EVE (Effective Visible Execution) to warstwa monitorowania realizacji. Tam, gdzie ADAMS planuje, EVE śledzi rzeczywistość: gdzie naprawdę jest konwój, czy samolot rzeczywiście wystartował, czy zapas rzeczywiście dotarł. EVE jest najbliżej obrazu czasu rzeczywistego w LOGFAS — choć „czas rzeczywisty” w logistyce często oznacza „dzisiejsze pozycje zaraportowane o 07:00”.

SDM (System Data Management) to administracyjny kręgosłup — użytkownicy, role, klauzule udostępniania, synchronizacja baz, zarządzanie katalogiem. SDM jest niewidoczny dla planistów i kluczowy dla integratorów. Każda międzybazowa synchronizacja, każda harmonizacja katalogu, każda reguła udostępniania mieszka tutaj.

Czwórka współpracuje przez wspólną bazę LOGREP. Zmiana Force Module w jednym komponencie pojawia się w pozostałych po kolejnej synchronizacji. Większość projektów integracyjnych celuje bezpośrednio w schemat LOGREP, traktując ADAMS i EVE jako widoki nad wspólnym substratem.

JDLM (Joint Deployment and Logistics Model)

JDLM to system modelowania US Transportation Command (USTRANSCOM) dla połączonego wdrożenia i zaopatrzenia. Tam, gdzie LOGFAS koncentruje się na planowaniu koalicyjnym, JDLM koncentruje się na amerykańskich połączonych i międzyresortowych przemieszczeniach — coraz mocniej na modelowaniu wymaganym do oceny alternatywnych wariantów działań pod ograniczeniami.

JDLM konsumuje inne źródła: kanały TPFDD (Time-Phased Force and Deployment Data) z JOPES i systemów następczych, natywne wejścia modelowania JDLM od planistów oraz nakładki wywiadowcze. Jego wyjściem są warianty wdrożenia ocenione pod kątem czasu, przepustowości środków i ryzyka. Historia interoperacyjności z LOGFAS to nie symetria — oba systemy nie wymieniają baz danych. To translacja. Amerykański plan wymodelowany w JDLM trzeba przełożyć na rekordy ruchu i stanów zgodne z LOGREP, aby partnerzy koalicyjni mogli je przyjąć.

W praktyce oznacza to węzeł translacyjny stojący między nimi — niewielką usługę, która odczytuje eksporty JDLM, stosuje mapowania pól, stosuje zasady klauzul tajności i zapisuje wyjście w kształcie LOGREP do warstwy pośredniej, z której LOGFAS może pobrać dane. Każde wdrożenie koalicyjne z udziałem USA uruchamia jakąś wersję tego węzła.

Rodzina STANAG 2406

STANAG-i raportowania logistycznego leżą u podstaw wszystkiego. STANAG 2406 obejmuje raportowanie logistyczne w szerokim sensie, a powiązane STANAG-i z serii 2400 definiują konkretne formaty wymiany — raportowanie paliwa, raportowanie amunicji, raportowanie strat i logistyki medycznej, raportowanie ruchu transportowego.

Rozszerzenie MEDLOG — logistyka medyczna — to część, którą zespoły najczęściej niedoceniają. Klasa medyczna VIII ma inne reguły terminu ważności, inne ograniczenia temperaturowe, inne profile udostępniania międzynarodowego i inną kadencję raportowania niż zaopatrzenie ogólne. Integracja LOGFAS poprawnie obsługująca klasy od I do V i tak nie przejdzie audytu klasy VIII, jeśli MEDLOG nie został zamodelowany prawidłowo. Planuj go od pierwszego sprintu.

STANAG-i definiują format „na drucie”. Implementatorzy powinni traktować je jako kontrakt: wszystko, co platforma produkuje, musi przejść w obie strony przez eksport zgodny z STANAG bez strat. Sama ta zasada wyłapuje więcej błędów niż jakakolwiek inna dyscyplina.

Wzorce integracji

Dominują trzy wzorce.

Pull (odpytywanie LOGREP). System zewnętrzny odpytuje replikę LOGREP według harmonogramu — co piętnaście minut, co godzinę — porównuje ze swoim ostatnim snapshotem i reaguje na zmiany. Pull jest prosty, przewidywalny i łatwy w eksploatacji. Jest też stratny: jeśli rekord powstanie i zostanie usunięty między odpytaniami, pullujący nigdy go nie zobaczy. Dla danych planistycznych — które zmieniają się w kadencji konferencji, nie sekundowej — pull jest właściwy.

Push (strumień zdarzeń do LOGFAS). Systemy nadrzędne emitują zdarzenia zmiany — zapas zaktualizowany, ruch wykonany — na magistralę komunikatów, a adapter LOGFAS je konsumuje i zapisuje do LOGREP. Push jest bliższy czasowi rzeczywistemu i bezstratny, ale wymaga solidnej kolejki komunikatów i starannej idempotencji. Dla danych wykonawczych push jest właściwy.

Staging (węzeł translacyjny z bramą klauzul). Kanoniczny projekt koalicyjny. Narodowe ERP-y publikują do narodowej warstwy pośredniej. Węzeł translacyjny — należący do zespołu integracyjnego, często odcięty fizycznie od strony nadrzędnej — czyta z warstwy pośredniej, stosuje mapowania pól, stosuje zasady udostępniania i zapisuje do LOGREP po stronie koalicji. Węzeł translacyjny to jedyne wąskie gardło, w którym zbiegają się klauzule, udostępnianie i schemat. Buduj go jawnie. Nie pozwól, by powstał samoistnie.

Klauzule tajności i udostępnianie

Narodowe dane logistyczne są domyślnie narodowe. NATO RESTRICTED jest poziomem podłogowym, na którym leży większość wymian koalicyjnych, ale ten sam rekord może być udostępnialny dla NATO i nieudostępnialny dla konkretnego państwa partnerskiego, albo udostępnialny dla jednej misji i nie dla innej. Udostępnianie (releasability) nie jest klauzulą — to ortogonalna oś, która określa, kto co widzi w obrębie danego poziomu klauzuli.

Wzorzec, który działa, to sanityzacja na wyjściu. Każdy rekord niesie wektor udostępniania — zbiór państw i misji, dla których jest zatwierdzony. Węzeł translacyjny odmawia zapisu rekordu, którego wektor nie obejmuje miejsca docelowego. Pola wrażliwe narodowo (konkretne numery partii, nazwy dostawców, numery seryjne końcowych elementów) są usuwane lub haszowane przed przejściem przez bramę. Dyscyplina interoperacyjności koalicji wymaga, by było to egzekwowane w kodzie, nie w polityce. Polityka zawodzi przy tempie operacyjnym.

Brama także loguje. Każdy rekord, który przeszedł, każdy odrzucony, każde pole oczyszczone — logowane z pochodzeniem. Audyty udostępniania przyjdą. Bądź gotowy.

Federacja narodowych ERP-ów do LOGFAS

SAP, Oracle EBS, IFS i Maximo to cztery źródła nadrzędne, z którymi najczęściej się spotykamy. Każdy mapuje się do LOGREP inaczej.

SAP MM (Materials Management) niesie stany i zużycie z wysoką wiernością, ale używa narodowych kodów materiałowych — ich mapowanie do NSN-ów to połowa pracy integracyjnej. Mapowanie rzadko jest jeden-do-jeden; spodziewaj się kuratorowanej tablicy cross-walk utrzymywanej przez organ materiałowy. Wzorce integracji obronnego ERP mają tu bezpośrednie zastosowanie.

Oracle EBS Inventory i IFS Supply mają podobne kształty, ale różną semantykę pól — „on hand” w jednym to „available” w drugim, z rezerwacjami i w-tranzycie traktowanymi niekonsekwentnie. Czytaj definicje pól, nie nazwy pól.

Maximo, używany intensywnie do utrzymania floty, dostarcza danych o gotowości — statusu pojazdów, odroczonego utrzymania, wskaźników gotowości misyjnej. Maximo zasila kolumny gotowości rekordu Force Module w LOGREP. Źle zamodelowana gotowość — i plan koalicyjny zbudowany jest na fikcji.

Dla potoku odpowiedni kształt to change-data-capture (CDC). Uruchom CDC na ERP, zmaterializuj projekcję po stronie narodowej, przetransformuj do kształtu LOGREP, zaramkuj klauzulami, zapisz po drugiej stronie. Replikacja wsadowa rozpada się na przypadkach brzegowych; dyscyplina CDC per-rekord je wyłapuje.

Lekcje operacyjne

Ćwiczenia Steadfast Defender i Trident Juncture obciążały logistykę koalicyjną od końca do końca, w skalach bliskich realnej wojny. Wzorzec awarii jest spójny.

Pierwsze pęka katalog. Lokalny katalog państwa odjeżdża od uzgodnionego cross-walku NSN — nowy przedmiot wchodzi do służby, aktualizacja cross-walku jest odroczona, a z dnia na dzień kanał LOGREP produkuje wiersze „nieznany materiał”, które konsumenty po stronie odbiorczej cicho odrzucają. Wbuduj wykrywanie dryfu katalogu w potok. Alarmuj tę samą zmianę.

Drugi pęka czas. Znaczniki czasu LOGREP raportowane są w czasie lokalnym bez strefy w starszych kanałach, w UTC w nowszych i w czasie misji w niektórych kontekstach operacyjnych. Jedna integracja, która je miesza, produkuje plany ruchu, w których konwoje przybywają zanim wyruszą. Normalizuj do UTC na wejściu. Nigdy nie ufaj znacznikowi czasu zegara ściennego.

Trzecie pęka udostępnianie. Pole udostępnialne wczoraj staje się narodowo wrażliwe dzisiaj — nazwa dostawcy, numer partii, szczegół trasy. Jeśli udostępnianie jest zaszyte w regułach translacji, a nie niesione per-rekord, każda zmiana staje się wydaniem kodu. Zrób z udostępniania dane, nie kod.

Czwarty pęka człowiek w pętli. Planiści ADAMS i operatorzy EVE pracują w rotacjach zmianowych, a przekazanie zmiany to miejsce, gdzie wchodzi większość regresji jakości danych. Ruch jest częściowo zaktualizowany przez wychodzącą zmianę, wchodząca zakłada, że rekord jest finalny, a konsumenci po drugiej stronie połykają plan napisany w połowie. Lekarstwem nie jest szkolenie. Lekarstwem jest wymuszanie atomowości na poziomie rekordu na granicy LOGREP — zapisy częściowe są odrzucane, pełne aktualizacje przechodzą. Wepchnij ograniczenie do warstwy schematu, gdzie zmęczenie zmianowe nie może go obejść.

Co przetrwa między ćwiczeniami, to zespół, który posiada węzeł translacyjny od początku do końca — schemat, mapowanie, udostępnianie, brama, dziennik audytu. Ta odpowiedzialność nie może być dzielona między państwa lub kontraktorów bez tego, by szwy stały się powierzchnią awarii. Jeden zespół, jedna brama, jeden odpowiedzialny właściciel. Wszystko inne jest drugorzędne.

Dyscypliną, która przetrwa, jest jakość danych. Logistyki koalicyjnej nie uratuje sprytniejszy optymalizator. Uratują ją czyste katalogi, uczciwa gotowość, wierne znaczniki czasu i bramy translacyjne, które odmawiają kłamstwa. Buduj pod to, a reszta pójdzie sama. Szerszy obraz operacyjny pokrywają nasze artykuły o oprogramowaniu łańcucha dostaw dla obronności i predykcyjnym utrzymaniu. Dla architektury fuzji, która konsumuje sygnały logistyczne obok ISR i danych operacyjnych, zobacz nasz przewodnik po fuzji danych obronnych.