Juoksevan arvion automatisointi: pitää esikuntien tilannetietoisuus reaaliajassa

Jokainen esikuntaosasto ylläpitää juoksevaa arviota: jatkuvasti päivitettyä arviota nykytilanteesta ja siitä, kuinka hyvin operaatio etenee komentajan tavoitteiden mukaisesti. Tiedusteluupseeri arvioi vihollisen vahvuuden ja aikomukset; logistiikkahpseeri arvioi kuinka monta huoltopäivää on jäljellä; operaatioupseeri arvioi joukkojen taisteluvoimaa. Doktriinissa nämä arviot kuvataan "juokseviksi" — niiden pitäisi olla ajan tasalla koko ajan. Käytännössä ne eivät useinkaan ole, koska niitä ylläpidetään käsin ja päivitetään vain silloin kun esikuntaupseeri ehtii tehdä sen. Tässä artikkelissa käsitellään tämän kuilun kuromista automaatiolla: reaaliaikaisen datan hakeminen taisteluvoima-, huolto- ja riskikuviin niin, että komentaja näkee nykytilanteen eikä jo tunteja vanhaa tilannekuvaa.

Mitä juokseva arvio on ja miksi se vanhenee

Juokseva arvio ei ole kertatuote kuten operaatiokäsky. Se on elävä arvio, jota jokainen taistelutoiminto pitää ajan tasalla koko operaation ajan. Sen rakenne on yhtenäinen eri toimintojen kesken: nykyinen omien joukkojen tilanne, nykyinen vihollisen tilanne, siviiliasiat, kaikkien kolmen vaikutus suunniteltuihin ja mahdollisiin operaatioihin sekä niistä seuraavat suositukset. Komentaja käyttää näiden arvioiden kokonaisuutta tilannetietoisuuden ylläpitämiseen ja päätösten tekemiseen.

Doktriinin ihanne on, että arvio heijastaa tilannetta juuri nyt. Operatiivinen todellisuus on, että manuaalisesti ylläpidetty arvio heijastaa tilannetta viimeisen päivityksen hetkestä. Aamuisen synkronointikokouksen yhteydessä päivitetty taisteluvoimakaavio on jo väärässä siinä vaiheessa, kun komentaja katsoo sitä ennen lounasta, koska tappiot, ammusten kulutus, polttoaineen kuluminen ja ajoneuvoviat kaikki muuttuvat jatkuvasti ja epäsynkronisesti. Arvio vanhenee heti julkaisemisen jälkeen, ja vanhentumistahti on kaikkein nopein juuri silloin kun tempo on kaikkein korkein — mikä on juuri se hetki kun komentaja eniten tarvitsee sen olevan oikein.

Toisena, hiljaisempana kustannuksena on manuaalinen koostaminen, joka kuluttaa esikuntahenkilöstön tunteja. Logistiikkaupseerin apulainen, joka käyttää kaksi tuntia per sykli LOGSTAT-raporttien keräämiseen, niiden kirjoittamiseen pääarkkitaulukkolaskentaan ja huoltopäivien uudelleenlaskemiseen, on kaksi tuntia jäljessä analyysista, joka todella vaikuttaa päätökseen. Automaatio ei korvaa esikuntaupseerin harkintaa; se poistaa sen kirjanpitotyön, joka seisoo upseerin ja harkinnan välissä.

Manuaalisista kaavioista reaaliaikaiseen dataan: arkkitehtuuri

Juoksevan arvion automatisointi tarkoittaa sellaisen putkiston rakentamista, joka syöttää auktoritatiivisia raportteja, normalisoi ne yhteiseen tilamalliiin, laskee johdetut luvut uudelleen syötteiden muuttuessa ja esittää tuloksen alkuperätietoineen. Arkkitehtuuri vastaa yhteisen operatiivisen tilannetiedon kerrostettua mallia, mutta tuloksena on arvio eikä sijainti.

Perustana on taistelutoiminnoittain määritelty tilamalli. Operaatioarviossa malli kantaa taisteluvoimaa yksikkökohtaisesti — tyypillisesti prosenttiosuutena henkilöstön ja avainkaluston valtuutetusta vahvuudesta. Huoltoarviossa se kantaa tasoja tarvikelajeittain, jäljellä olevia huoltopäiviä ja kriittisten järjestelmien valmiustilaa. Suojaamisarviossa se kantaa riskinilmaisimia ja voimansuojatoimenpiteiden tilaa. Jokainen mallin kenttä nimeää auktoritatiivisen lähteensä, odotetun päivitystahdinsa ja — johdettujen lukujen osalta — sen laskentakaavan. Tämä malli on sopimus, johon jokainen alavirran vaihe nojautuu; sen virheiden korjaaminen levittää virheet jokaiseen koontinäyttöön.

Mallin yläpuolella ovat syöteadapterit, yksi kullekin lähteelle. Omien joukkojen seurantasyöte toimittaa yksikköjen sijainnit ja tilan, yleensä NFFI- tai CoT-viesteinä. Huolto saapuu LOGSTAT-raportteina tai niiden kansallisina vastineina. Kunnossapidolla ja määräaikaisilla, tappioraportoinnilla ja vihollisen vahvuuden tiedusteluarviolla on kullakin oma formaattinsa ja tahtinsa. Jokaisen adapterin tehtävä on kapea ja tiukka: muunna lähdeformaatti tilamalliiksi, validoi se uskottavuusalueiden suhteen ja karanteerroi kaikki väärin muodostetut tiedot sen sijaan, että annat vioittuneen raportin myrkyttää koosteet. Yksittäinen väärin kirjoitettu ammusmäärä, joka hiljaisesti puolittaa raportoidun peruslastin, on pahempi kuin ei raporttia lainkaan.

Taisteluvoimaen ja huollon jatkuva laskeminen

Johdetut luvut ovat arvion ydin. Taisteluvoimaprosentti, jäljellä olevat huoltopäivät ja joukkojen ennakoitu toimintasäde eivät tule suoraan raporteista — ne lasketaan taustalla olevista raporteista. Tärkein suunnitteluratkaisu on se, milloin laskeminen tehdään uudelleen.

Naiivi toteutus laskee kiinteällä kellolla — sanotaan viidentoista minuutin välein. Tämä takaa, että arvio on vähintään viisitoista minuuttia vanha koko ajan ja tuhlaa laskentatehoa laskemalla uudelleen luvut, jotka eivät ole muuttuneet. Parempi malli on tapahtumalähtöinen uudelleenlaskenta: kun LOGSTAT-raportti muuttaa yksikön polttoainetilannetta, laske kyseisen yksikön huoltopäivät ja sen ylemmän yhtymän kooste heti uudelleen, ja jätä kaikki muut luvut koskemattomiksi. Tapahtumalähtöinen uudelleenlaskenta pitää viiveen lähes nollassa muuttuneiden lukujen osalta ja välttää turhaa työtä muuttumattomien lukujen osalta.

Jokaisen laskennan tuloksen on kannettava mukanaan alkuperätieto. Taisteluvoimaluku 78 % on komentajalle merkityksetön ilman vastausta kahteen kysymykseen: mistä hetkestä ja mistä lähteestä. Järjestelmän pitää leimata jokainen johdettu luku sen laskemiseen käytettyjen raporttien aikaleimalla ja lähde-identiteetillä, jotta alkuperätieto kulkee luvun mukana aina näyttöön saakka. Tämä on ero sen välillä, onko kyseessä arvio, jota komentaja voi tarkastella kriittisesti, vai luku, johon komentajan on vain luotettava.

Koostaminen ja koontilaskenta

Taisteluvoima- ja huoltoluvut koostetaan tehtäväorganisaatiossa ylöspäin: ryhmistä joukkueisiin, joukkueista komppanioihin, komppanioista pataljoonan kokonaislukuun. Tämän koontilaskennan automatisointi on periaatteessa suoraviivaista mutta yksityiskohdissa vaarallista. Alistussuhteet muuttuvat operaation aikana, ja koontilaskenta, joka käyttää vanhentunutta tehtäväorganisaatiota, laskee vääriä yksiköitä yhteen. Tilamallin on siksi kohdeltava tehtäväorganisaatiota itseään reaaliaikaisena syötteenä eikä staattisena konfiguraationa, jotta taisteluvoima seuraa yksiköitä niiden alistussuhteiden muuttuessa. Kun komppania alistetaan eri pataljoonalle, sen taisteluvoimaa on koostettava vastaanottavan yksikön alaisuudessa siitä hetkestä alkaen kun alistus astuu voimaan.

Arvion luotettavuuden ylläpito: vanhentuminen, varmuus ja korvaus

Automatisoidun arvion vaarallisin vikatila ei ole se, että se on väärässä — vaan se, että se näyttää varmalta ollessaan väärässä. Siisti koontinäyttö, jossa lukee selkeä 78 %, herättää enemmän luottamusta kuin käsinpiirretty kaavio näkyvin pyyhkimisjälkineen, vaikka käsinpiirretty kaavio olisi ajantasaisempi. Luottamuksen rakentaminen tarkoittaa rehellisen epävarmuuden rakentamista.

Vanhentumiskäsittely on ensimmäinen vaatimus. Jokaisella syötteellä on odotettu tahti; mikä tahansa raportti, joka on konfiguroitavaa kynnystä vanhempi sen tahdista, merkitään vanhentuneeksi ja esitetään visuaalisesti — harmautettuna, merkittynä tai kommentoituna — eikä käytetä hiljaisesti. Polttoaineraportista laskettu huoltopäiväluku, joka on kahdeksantoista tuntia vanha korkean tempon taistelussa, pitäisi huutaa ikänsä, ei piilottaa sitä. Tästä seuraa, että johdettu luku perii vanhentuneisuuden vanhimmasta syötteestään: koontilaskenta on vain niin tuore kuin sen vanhin osatekijä.

Varmuus on toinen vaatimus. Siellä missä raportointi on osittaista — esimerkiksi kun vain kaksi kolmesta alaisesta yksiköstä on raportoinut — koosteen pitäisi kantaa mukanaan nimenomainen varmuus- tai kattavuusindikaattori eikä esittää osittaista summaa ikään kuin se olisi täydellinen. Tämä yhdistää juoksevan arvion laajempaan tekoäly-päätöksentuen tieteenalaan, jossa suosituksen perustan ja epävarmuuden esittäminen on se, mikä tekee siitä käyttökelpoisen eikä pelkästään vaikuttavan.

Korvauksen käsittely on kolmas. Esikuntaupseeri tietää joskus jotain, mitä syötteet eivät tiedä — radiolla raportoinut yksikkö, joka ei ole vielä jättänyt rakenteellista raporttia, tai tunnetusti viallinen sensori, joka pitäisi jättää huomiotta. Järjestelmän on sallittava upseerin korvata automatisoitu arvo, sen on kirjattava kuka teki muutoksen ja miksi, eikä se saa koskaan antaa myöhemmän automaattisen päivityksen hiljaisesti pyyhkiä kyseistä korvausta. Korvausten pitäisi vanhentua tai pyytää uudelleenvahvistusta eikä jäädä näkymättömästi voimaan ikuisesti, jotta eilinen manuaalinen korjaus ei hiljaisesti vääristä tämän päivän kuvaa.

Arvion esittäminen: reaaliaikaiset näkymät komentajalle ja henkilöstölle

Viimeinen vaihe muuntaa lasketun tilan näkymiksi, joita ihmiset todella käyttävät. Juokseva arvio ei ole yksi näyttö vaan useita roolisuodatettuja: taisteluvoimanäkymä operaatioupseerille ja komentajalle, huoltonäkymä logistiikalle, riski- ja suojausnäkymä sekä kooste komentoa varten. Jokainen on vain luettava projektio samasta auktoritatiivisesta tilasta, mikä takaa, ettei logistiikkanäkymä ja koostekooste voi olla eri mieltä saman yksikön polttoainetilasta. Tämä yksittäisen totuuslähteen kurinalaisuus on sama, joka ohjaa vankkaa C2-koontinäyttöarkkitehtuuria: näytöt ovat tilatietokannan kuluttajia, eivät koskaan sen muokkaajia.

Reaaliaikaiset näkymät pitäisi lähettää muutokset heti kun ne tapahtuvat eikä odottaa päivitystä, ja niiden pitäisi ohjata katse siihen mikä muuttui. Koontinäyttö, joka piirtää jokaisen luvun uudelleen jokaisella päivityksellä, opettaa komentajan jättämään sen huomiotta; sellainen, joka korostaa muutoksia — komppanian, jonka taisteluvoima juuri laski alle 70 %, tai tarvikelajin, joka juuri ylitti päätöskynnyksen — ohjaa huomion niihin harvoihin tosiasioihin, jotka vaativat sitä. Tavoitteena ei ole näyttää kaikkea mikä on ajan tasalla, vaan näyttää mikä juuri tuli todeksi ja mitä se tarkoittaa suunnitelman kannalta.

Päätöskynnykset ansaitsevat nimenomaisen käsittelyn. Komentajat asettavat kriteerejä — taisteluvoima alle tietyn prosentin, huoltopäivät alle tietyn luvun — jotka laukaisevat päätöksen. Automatisoitu arvio voi seurata näitä kynnyksiä jatkuvasti ja hälyttää kun yksi ylitetään, muuttaen arvion henkilöstön lukemasta kohteeksi, joka kertoo henkilöstölle milloin toimia. Varovaisuutta tarvitaan: kynnysvaroitukset, jotka laukeavat yhdestä vanhentuneesta tai karanteenoidusta raportista, nakertavat luottamusta nopeasti, joten varoituksen pitäisi laueta samoilla alkuperätietoisilla, vanhentumistietoisilla luvuilla, joita koontinäytöt näyttävät, ei raakasyötteiden perusteella.

Miten automaatio sopii laajempaan C2-kuvaan

Juokseva arvio ei seiso yksin. Se käyttää samoja syötteitä kuin yhteinen operatiivinen tilannetieto ja laajempi moniulotteisten operaatioiden koontinäyttö, ja se syöttää suositukset, joita päätöksentuenvälineet tuottavat. Kartta vastaa kysymykseen missä joukot ja uhat ovat; arvio vastaa kysymykseen kuinka kykyisiä kyseiset joukot ovat ja mitä se tarkoittaa tehtävälle. Kun molemmat on rakennettu näkymiksi yhden auktoritatiivisen tilatietokannan päälle, komentajan ei tarvitse sovittaa yhteen karttaa, joka näyttää yksikön etulinjassa, ja arviota, joka näyttää sen taistelukyvyttömänä — molemmat on laskettu samoista raporteista ja ne ovat yhteneväiset rakenteellisesti.

Tämä yhdenmukaisuus on automaation todellinen palkinto. Juoksevan arvion pitäminen reaaliaikaisena ei ole ensisijaisesti esikuntahenkilöstön tuntien säästämistä, vaikka se tekeekin niin. Kyse on sen varmistamisesta, että kun komentaja kääntyy kartasta arvioon, molemmat kertovat saman, nykyisen totuuden — jotta päätös perustuu tilanteeseen sellaisena kuin se on nyt, eikä sellaisena kuin se oli viimeisessä synkronoinnissa.