Logistiikan alalla tietojärjestelmän ja fyysisen maailman rajapinta kulminoituu kuormakirjoihin. Jos tilaukselle ei saada asianmukaisia kuormakirjoja, ei sitä voida lastatakaan. Jotta oikeat asiakirjat voidaan tulostaa, tarvitaan toimivien printtereiden lisäksi oikeat tiedot oikeaan aikaan niin myynnin, varastoinnin kuin logistiikankin järjestelmistä. Jos rahtiasiakirjojen tulostaminen epäonnistuu, autot eivät pääse matkaan, työpäivät venyvät ja toimitukset takkuilevat.
Ongelma voi olla yksittäisen auton tiedoissa, tietyn terminaalin järjestelmissä tai kyseessä voi olla maanlaajuinen häiriö. Kun asiakirjoja ei pystytä tulostamaan, alkaa kilpajuoksu aikaa vastaan. On toimittava nopeasti, sillä kyseessä on suuri operaatio, jossa suunnittelemattomat toimituskatkokset aiheuttavat isoja ongelmia ja vahingot voivat olla pahimmillaan satoja tuhansia euroja.
Koko ekosysteemin kattava häiriöseuranta säästää aikaa
Usein vikaseuranta rajoittuu yhteen järjestelmään ja sen toimivuuteen. Kun kokonaisuudessa havaitaan katkos ja tärkeä prosessi ei enää toimi, syytä aletaan selvittää käymällä läpi useita järjestelmiä. Tähän kuluu valtavasti aikaa. Joskus vikaa ei löydy yhdestäkään järjestelmästä, mutta prosessi ei silti toimi.
Analysoidessamme erään logistiikan toimintaympäristön isompia järjestelmähäiriöitä viime vuodelta, havaitsimme että korjauksen lisäksi, tarkan vikakohdan sekä häiriön laajuuden selvitykseen kului luvattoman paljon kallisarvoista aikaa. Tilannetta voidaan onneksi parantaa huomattavasti seuraamalla liiketoimintaprosessien tilaa kaikkialla asiakkaan tietojärjestelmäympäristössä.
Tällaisella seurannalla voidaan havaita virheitä automaattisesti ennen kuin ne näkyvät käyttäjille, jolloin laajoja häiriötilanteita ei pääse syntymään. Monimutkaisen ympäristön kaikkia mahdollisia vikoja ei voida poistaa, mutta tehokas seuranta leikkaa merkittävästi selvitys- ja korjaustyöhön kuluvaa aikaa.
Monimutkaiset toimintaympäristöt haltuun
Haasteet tehokkaan häiriöseurannan toteuttamisessa monimutkaisessa ympäristössä ovat ilmeisiä. Järjestelmiä on paljon, ja niiden kypsyysasteet vaihtelevia. Joku järjestelmä on aina elinkaarensa päässä ja sen uusiminen käynnissä, mutta hidasta ja tarkkaa työtä. Vanhat järjestelmät kun toimivat erikoisuuksistaan huolimatta oikein, koska suurimmat virheet on vuosien saatossa jo korjattu. Jotkin ovat aina omintakeisia: ne saattavat esimerkiksi toimia vain tietyillä palvelimilla ja tuoda näin mukanaan omat haasteensa.
”Monimutkaisen ympäristön kaikkia mahdollisia vikoja ei voida poistaa, mutta tehokas seuranta leikkaa merkittävästi selvitys- ja korjaustyöhön kuluvaa aikaa.”
Seurannan toteuttamisen haaste onkin prosessin virhekohtien löytäminen vaikuttamatta itse prosessiin ja muuttamatta siihen liittyviä järjestelmiä.
Toimiiko prosessi oikein?
Asiakkaalle kehittämämme ratkaisu käyttää olemassa olevaa tuotetta ja työkaluja seuranta-agenttien käyttöönottamiseksi. Nämä agentit keräävät dataa keskitettyyn hallintatilaan, jossa sitä voidaan edelleen työstää ja analysoida, minkä perusteella voidaan laukaista varoituksia ja hälytyksiä.
Kuva: Keskitetty hallinta on pilvipalveluna toteutettu SaaS-komponentti, jonne kerätty data säilötään. Erityyppiset agentit mahdollistavat datan keräämisen saatavilla olevista lähteistä.
Prosessin toimimisen varmistaminen yksittäisiä virhetilanteita tarkkailemalla on hyvin työlästä, koska kaikkiin tilanteisiin on vaikea ellei mahdoton varautua. Viestiliikenteen tarkkaileminen on kuitenkin osoittautunut tehokkaaksi tavaksi havaita ongelmia järjestelmissä:
Vastaanottavan järjestelmän ongelmat tunnistaa helposti: sisään tuleva liikenne jää jumiin tai päätyy virheeseen. Seurantajärjestelmä tarkkailee keskeisten hakemistojen sisältöä ja huomaa jos tiedostot kasautuvat niihin. Kymmenen viestiä kansiossa keskellä päivää ruuhka-aikaan ei yleensä ole merkki ongelmasta, mutta keskellä yötä se on aihe hälytykseen.
Työkalujemme tilastollisten algoritmien avulla osaamme huomioida yritysliikenteen normaalimäärät eri viikonpäivinä ja vuorokaudenaikoina. Näin yksittäiset poikkeamat sivuutetaan ja puutumme vain todellisiin virhetilanteisiin. Voimme esimerkiksi määrittää, että vain vähintään neljän keskihajonnan ero perustasoon on syy hälytykseen ja että hälytystilan on jatkuttava tietyllä ehdolla viimeisimpien mittausten perusteella, kunnes asiaan on reagoitava.
Lähettävän järjestelmän ongelmia voidaan havaita tunnistamalla liikenteen puuttumisen. Tässä statistiikan keruu liikenteen normaalitilasta on oleellista. Kun tunnistamme lähetetyt viestit, oli se sitten arkistokansioiden, lokitiedostojen tai tietokantarivien perusteella, työkalumme määrittää liikenteelle perustason. Tämän jälkeen voimme tunnistaa tilanteet, joissa liikennettä ei ole, vaikka sitä pitäisi olla.
Virhetilanteen vakavuuden tunnistamisessa avain-asemassa on virheiden luokittelu. Tiettyjä virheitä tapahtuu tämän tästä: jonkun sormet ovat lipsahtaneet näppäimistöllä ja tämän vuoksi yritetään myydä olematonta tuotetta, tai jokin tuote ei ole valmis kuljetettavaksi. Joissakin vanhoissa järjestelmissä tämäntyyppiset virheet on vaikea erottaa järjestelmävirheistä, jollaisia voivat olla esimerkiksi vialliset viestimuodot tai reagoimaton tietokanta. Tämän erityisongelman voimme ratkaista keräämällä virhetiheyden ja määrittämällä sille perustason. Kun perustaso on määritetty muutaman viikon tietojen perusteella, on helppoa havaita virhetiheyden epänormaalit piikit ja saada asianmukaiset tahot tarkistamaan tilanne.
Yksilöllinen näkymä – mitä tapahtui tilaukselleni?
Loppukäyttäjällä harvoin selviää heti, mihin ja miksi prosessi katkesi. Joskus syynä voi olla käyttäjän oman datan virhe, joskus järjestelmävirhe. Tilannetta helpottamaan olemme luoneet ratkaisuun mahdollisuuden ”tilausseurantaan”, jolla käyttäjätuki saa näkyvyyden siihen vaiheeseen, missä prosessi katkesi ja onko kyseessä yksittäinen ongelma vai laajempi vika.
Ratkaisussa tunnistamme prosessin kannalta oleelliset viestit ja asetamme välitysohjelmistot tuottamaan niistä kopioita käyttöömme. Näin pystymme vapaasti käsittelemään viestejä tapahtumaketjuja mallintaessamme, vaarantamatta itse liiketoimintaprosessia.
Kun prosessin vaiheet, viestit ja häiriöt on näin mallinnettu ja niistä tehdyt tapahtumat kerätty hallintatilaan, niitä voidaan myös esittää analytiikan keinoin, tuoden uudenlaista näkyvyyttä kokonaisuuteen.
Ratkaisun ansioista olemme onnistuneet vähentämään vakavia häiriötilanteita ja vääriä hälytyksiä. Sillä mahdollistettiin myös yhteisten näkymien, hälytysten ja datan käyttö eri toimijoiden välillä ongelmatilanteita selvittäessä. Näin on rakentunut sujuva yhteistyö ja kontaktiverkosto joka on vähentänyt merkittävästi vianselvitykseen kuluvia resursseja.
Iteratiivinen ja jatkuvasti kehittyvä prosessi
Seuraamme liiketoimintaprosesseja siellä, missä tarve on suurin. Kun ympäristö on ollut toiminnassa jo tietokoneiden ilmaantuessa alalle, tehtävää on paljon. Tyypillinen tapaus on aina iteratiivinen. Ensiksi meidän on ymmärrettävä, mitä tapahtuu, mitä keskeisiä asioita meidän on seurattava ja miten meidän on toteutettava seuranta. Testiympäristöissä on harvoin realistista tietoa riittävässä määrin, joten yleensä meidän on työskenneltävä suoraan tuotantoympäristössä.
Alustavan analyysin jälkeen toteutamme ensimmäisen prototyypin saadaksemme tärkeimmät mittaukset. Kun mittaukset toimivat, alamme saada tietoa liikennevirrasta ja perustason tietojen kerääminen alkaa. Seuraavaksi meidän on määritettävä käynnistimet: mikä on tavallista ja mikä poikkeaa siitä? Millainen virhe edellyttää järjestelmän tutkimista ja millä tasolla voidaan todeta jonkin olevan pahasti pielessä?
Sopivan tasapainon löytäminen on vaikeaa. Kun päivystäjien sähköpostilaatikot ja puhelimet tulvivat tarpeettomia varoituksia, oikeat hälytykset hukkuvat tulvaan. Toisaalta taas hälytyskynnyksen nostaminen liian korkealle aiheuttaa todellisten vaarojen ohittamisen. Parhaan vasteen varmistamiseksi päivystystiimimme keskustelee säännöllisesti viimeisimmistä hälytyksistä ja läheltä piti tapauksista ja muuttaa tarvittaessa sääntöjä.
Seurannan avulla olemme voineet katsoa liiketoimintaprosessien tilaa uusin silmin ja oppineet ymmärtämään niitä paremmin. Silloin tällöin löydämme ongelmia: viestejä, joita kukaan ei kuluta, kansioita, jotka keräävät viestejä vain täyttääkseen levytilaa, tai viestin kuluttajia, jotka toimivat epäilyttävän hitaasti. Jotta seuranta toimisi luotettavasti, väärät positiiviset on poistettava. Usein toimintamme johtaa kaikenlaisten pienten ongelmien korjaamiseen, mikä tekee asiakasympäristöstä vakaamman ja yksiselitteisemmän.
On sanomattakin selvää, että liiketoiminnan seurantaprosessien kehitystyö ei tule koskaan valmiiksi. Prosessin seurannassa ei ole kyse pelkästään asennettavista ja määritettävistä työkaluista. Meidän on ymmärrettävä prosessit ja analysoitava niiden taustalla toimivat järjestelmät, jotta tunnistamme oikeat tavat ja paikat tutkia liikennettä. Kaiken lisäksi tilanne elää koko ajan. Prosessit kehittyvät ajan myötä, ja taustalla toimivat järjestelmät muuttuvat. Vanhat järjestelmät korvataan nykyaikaisilla, ja samalla myös seurantaa on muutettava. Tärkeintä on pysyä koko ajan tilanteen tasalla.
