Puolustuksen toimitusketjuohjelmisto: Arkkitehtuuri sotilaslogistiikkaan

Sotilaalliset toimitusketjut eivät ole hitaampia tai tehottomampia versioita kaupallisista toimitusketjuista. Ne toimivat perustavanlaatuisesti erilaisten rajoitusten alla: asiakkaat ovat taisteluyksiköitä, joiden sijainti saattaa olla luokiteltu, kysynnän signaalit tulevat taistelukäytöstä eikä myyntipisteistä, kuljetusreitit saattavat olla kiistettyjä, ja puutteen seuraus ei ole menetetty myynti vaan heikentynyt taistelukyky tai tehtävän epäonnistuminen.

Puolustuksen toimitusketjuohjelmisto on suunniteltava näitä rajoituksia varten. Tässä artikkelissa käsitellään kaupallisten ja puolustuksen toimitusketjujärjestelmien keskeisiä arkkitehtuurieroja, DLMS-datastandardeja sotilaslogistiikan transaktioita varten, etujoukkojen moniportaista varastonhallintaa sekä offline-toimintavarmuusvaatimuksia, jotka pitävät järjestelmän toiminnassa verkkoyhteyden katketessa.

Moniportainen toimitusarkkitehtuuri

Sotilaalliset toimitusketjut on organisoitu portaisiin — hierarkkisiin kerroksiin, joista kukin vastaa osasta kokonaishuoltotaakkaa. Tyypillisessä maavoimien toimitusketjussa on neljä porrasta: joukko-osastotaso (komppanian ja pataljoonan huoltohenkilöstö hallitsee päivittäistä kulutusta), välitön tuki (prikaatin tai divisioonan huoltopataljoona pitää nopeasti kiertävää varastoa), yleinen tuki (teatteritason varastot pitävät massavarastoa ja erikoisnimikkeitä) sekä strateginen taso (kansalliset varastot ja teollinen tuotanto).

Toimitusketjuohjelmiston on mallinnettava tämä moniportainen rakenne eksplisiittisesti. Täydennystilaukset kulkevat ylöspäin portaiden kautta: joukko, jonka käsivarasto on loppunut, lähettää pyynnön välitöntä tukea tarjoavalle elementille, joka joko toimittaa omasta varastostaan tai siirtää pyynnön yleiselle tuelle. Ohjelmisto seuraa pyyntöjä kaikissa portaissa tarjoten näkyvyyttä koko kysyntäputkeen joukko-osastotasolta teatteritasolle.

DLMS: Defense Logistics Management Standards

DLMS on datastandardi logistiikan transaktioihin Yhdysvaltain armeijassa ja NATO-kumppaneilla. DLMS-transaktiot ovat strukturoituja viestejä, jotka edustavat huoltotoimia: tilaukset (huoltopyynnöt), materiaalin vapautustilaukset (valtuutus lähettää varastosta), lähetysten tilanteet, vastaanottovahvistukset ja varastonkorjaukset. DLMS-transaktiot lähetetään X12 EDI -muodossa tai modernissa toteutuksessa XML:nä tai JSON:na web-palveluiden kautta.

Ohjelmiston, joka integroituu Yhdysvaltain armeijan toimitusketjuun tai liittolaisten toimitusketjuihin, on toteutettava DLMS-transaktioiden käsittely. Eurooppalaiset NATO-maat käyttävät vastaavia standardeja — NATO STANAG 4329 (Logistics Data Exchange) tarjoaa kehyksen logistiikkadatan yhteentoimivuudelle liittoutuman jäsenten välillä. Pan-NATO-toimitusketjusovelluksen on käsiteltävä sekä DLMS- että STANAG 4329 -transaktioformaatteja tai toteutettava käännöskerros niiden välille.

Kysynnän ennustaminen operatiivisen epävarmuuden alla

Kaupallinen kysynnän ennustaminen nojautuu historialliseen myyntidataan tulevan kysynnän projisoimiseksi. Sotilaallisen kysynnän ennustamisen on projisoitava kulutus suunnitellun operatiivisen tempon, asejärjestelmätiheyden, ympäristöolosuhteiden ja odotettujen taistelusuhteiden perusteella. Luokka III (polttoaine), luokka V (ampumatarvikkeet) ja luokka IX (varaosat) -kulutusta ohjaa operatiivinen toiminta, joka voi muuttua radikaalisti tuntien sisällä komentajan päätösten tai vihollisen toiminnan perusteella.

Puolustuksen toimitusketjuohjelmisto toteuttaa kysynnän ennustamismallit, jotka yhdistävät operatiiviset suunnittelutiedot (operaatiokäskyn suunnitellut liikeetäisyydet ja taisteluketjut) historiallisiin kulutuskertoimiin laitetyypeittäin ja operatiivisittain. Telattu ajoneuvo jatkuvissa hyökkäysoperaatioissa kuluttaa varaosia moninkertaisesti rauhan ajan harjoittelutasoon verrattuna.

Ohjelmiston on myös tuettava nopeaa uudelleenennustamista operatiivisten suunnitelmien muuttuessa. Kun yksikön tehtävä muuttuu puolustuksesta hyökkäykseen, toimitusketjun on laskettava varastovaatimukset uudelleen ja sovitettava täydennysputkea tuntien — ei päivien tai viikkojen — kuluessa.

Kuljetus ja reitinhallinta

Tarvikkeiden siirtäminen varastoista etujoukoille edellyttää kuljetusverkon hallintaa, johon saattaa kuulua kiistettyjä reittejä, rajoitettuja siltakapasiteetteja ja joukkojen suojaan liittyviä aikarajoituksia. Puolustuksen toimitusketjuohjelmisto sisältää kuljetushallintamoduulin, joka suunnittelee saattuekaavoja, hallitsee ajoneuvo- ja kuljettajamäärityksiä, seuraa lähetyksiä kuljetuksen aikana ja reitittää saattueet uudelleen, kun ensisijaiset reitit eivät ole käytettävissä.

Reitityssuunnittelu kiistellyissä ympäristöissä edellyttää integraatiota yhteisen operatiivisen kuvan (Common Operational Picture) kanssa — toimitusketjuohjelmiston on saatava reittien turvallisuusarvioinnit tiedustelujärjestelmältä ja otettava ne huomioon reittivalinnassa. Fyysisesti lyhin reitti ei usein ole nopein tai turvallisin, kun tien varrella olevat IED-uhkadatat tai viholliskontaktiraportit otetaan huomioon.

Offline-toimintavarmuus ja eriytetty toiminta

Etutukipisteet toimivat usein rajoitetulla tai ilman yhteyttä ylempään portaaseen. Etutukikomppania, joka suorittaa täydennystoimintaa, saattaa olla täysin erillään prikaatin huoltopataljoonan huoltohallintajärjestelmästä tunteja tai päiviä. Etutukipisteellä olevan mobiililaitteen tai kannettavan tietokoneen huoltohallintasovelluksen on pystyttävä itsenäiseen toimintaan erillisjakson aikana.

Offline-toimintavarmuusarkkitehtuuri käyttää samoja malleja kuin offline-ensin-mobiilisovellukset: kaikki data kirjoitetaan ensin paikalliseen tietokantaan (SQLite mobiilissa, PostgreSQL WAL-lokilla palvelininfrastruktuurissa), transaktiot asetetaan jonoon lähetystä varten yhteyden palautuessa, ja konfliktiratkaisu käsittelee tapaukset, joissa sama varasto on jaettu kahdesti irrallisten solmujen itsenäisten päätösten vuoksi.