Toimitusketjun hallinta muutostilanteissa – turvaa ja optimoi asiakaskokemus

September 24, 2020

Matti Ketonen

Edellisessä blogissani kuvailin sellaisia yleisiä piirteitä, joita tuottavan teollisuuden toimitusketjun suunnittelussa esiintyy. Nämä piirteet ovat pysyneet varsin pitkään aivan samanlaisina, vaikka kaiken tekemisen nopeus on kiihtynyt huomattavasti. Luinpa joskus historiallista toimitussopimusta, jossa kemiläisen sahalaitoksen toimitusaika oli ”First open water”. Tarkemmin tämä taisi tarkoittaa ”EXW-ehdoin”.

Suunnittelu on siis toimitusketjun menestyksellisen juoksutuksen ja asiakaskokemuksen hallinnan kannalta olennaista. Mutta mitä sitten tehtäisiin, jos joskus kävisi niin, että suunnitelmat eivät toteudu? Mitkä olisivat nykyaikaisia keinoja häriötilanteisiin reagoimiseksi? Entä voiko korjaustoimenpiteillä vaikuttaa asiakaskokemukseen?

Aikajänteiden käsittelystä

Perinteisesti toimitusketjun suunnittelu on jaettu eri aikaväleille, jotta on helpompi hahmottaa, mitä päätöksiä on tärkeää tehdä nopeasti ja mitkä voidaan tehdä pidemmän ajan kuluessa ja lähtötietojen tarkkuuden parantuessa. Puhutaan siis strategisesta, pitkästä, keskipitkästä ja lyhyestä aikavälistä. Näillä tehtävillä on usein omat organisaationsa, vastuunsa, tavoitteensa, dokumentointinsa ja niin edelleen. Suunnittelun lähtötietoinakin käytetään omia tietojoukkojaan, ”datasettejä”. Kaikki toimintamallit ovat muotoutuneet vuosikymmenten, ellei -satojen, aikana perustuen ihmisen parhaaseen ymmärrykseen siitä, miten tulevaisuudessa menestytään. Tämä jako on lähes kaikissa yrityksissä rakennettu niin syvälle, että sitä on hyvin vaikea haastaa – puhutaan siis yrityksen DNA:sta.

Jos suunnittelua kuitenkin tarkastellaan ”akateemisesti”, ei ole syytä jättää mitään lähtötietoa käyttämättä millään sunnittelun aikavälillä. Pitkä aikaväli ei myöskään ole rakenteellisesti erilainen kuin joku toinen. Aikajänteiden ymmärtäminenhän perustuu ”ainoastaan” ihmisen kollektiiviseen aikakäsitykseen.

Tänä päivänä kaikkien aikajänteiden lähtötietoja voidaan tuoda entistä paremmin suunnittelutehtävien käyttöön riippumatta siitä, mille aikajänteelle suunnittelua – tai ennustetta – ollaan tekemässä. Luonnollisesti fysiikan lait ja aikajatkumo pysyvät edelleen määräävinä. Esimerkiksi tuotantosuunnitelman pitää valmistua ja se pitää jäädyttää riittävän ajoissa, jotta tarpeelliset valmistelut ehditään tehdä. Muuta syytä tehdä tarkkoja suunnitelmia pitkälle eteenpäin ei sitten olekaan, kunhan on kyky jatkuvasti tuottaa sitä suunnitelmaa, joka viedään reaalimaailman toteutukseen.

Esimerkki: Useissa yrityksissä make-to-order-mallin asiakastilaukset sijoitetaan suoraan karkeaan tuotantosuunnitelmaan, joka siten vähitellen jäätyy. Ihmiselle tämäntyyppinen prosessi näyttäytyy järjestäytyneenä. Se myös ”pilkkoo elefantin” hallittavan kokoisiin ongelmiin. Jatkuvan optimoinnin avulla edellä kuvattua prosessia voitaisiin muuttaa vaikkapa siten, että:

Pidetään ensinnäkin huolta siitä, että riittävä – eli lyhin mahdollinen – tuotanto- ja hankintasuunnitelma on jäädytetty, jotta valmistelutoimenpiteet voidaan tehdä ajoissa.
Uusia tilauksia otetaan asiakkailta esimerkiksi pitkäaikaisiin hankintasopimuksiin tai ennalta annettuihin allokaatiohin perustuen eri aikajaksoille, mutta niitä ei kiinnitetä mihinkään suunnitelmaan tilauksen vahvistamishetkellä.
Optimoidaan jäädytetyn suunnittelujakson ulkopuolinen operatiivinen suunnitelma uudestaan esimerkiksi kerran vuorokaudessa kunnioittaen asiakaslupausta sekä tuotannon tehokkuuden vaatimuksia. Suunnittelun lähtökohtana ovat ajantasaiset lähtötiedot, sisältäen aikaisemmat poikkeamat ja toimitusputken päivitetyn tilan.

Teoria kuvatun kaltaiseen optimointiin on ollut olemassa pitkään. Moni kenties muistaa opinnoistaan, miten sakkofunktioita muodostettiin ja rajoitteita käsiteltiin. Moniulotteisessa optimoinnissa tavoitefunktion ja rajoitteiden epälineaarisuus muodosti kuitenkin käytännön ongelman. Oli vaikea vakuuttua siitä, että algoritmin saavuttama tulos oli varmasti optimi.

Nykyinen konekapasiteetti mahdollistaa useissa tapauksissa ”brute force” -menetelmän käytön, jossa lasketaan kaikki reaalimaailman mahdolliset kombinaatiot ja haetaan näistä paras lopputulos. Tällainen toimintamalli mahdollistaa myös uusien rajoitteiden lisäämisen ja optimointifunktion muuttamisen varsin helposti, vaikkei olekaan menetelmistä elegantein.

Häiriöiden priorisointi

Kun Taina tulee aamulla töihin, on hänellä edessään reilun kymmenen sellaisen asiakastilauksen lista, jotka ovat myöhässä. Varmon tehtaalla on ollut yllättävä tuotantokatkos. Sehän vastaa noin 1% päivittäisestä kokonaistuotannosta, joten tilanne on kuitenkin ihan hyvä. Joskushan sitä on tilanteita, että kaikki on myöhässä! Taina toimii logistiikkatiimin vetäjänä ja tekee tietysti myös itse pääosan ajastaan kuljetussuunnittelua. Tiimi suunnittelee muun muassa yli 1000 asiakastoimitusta päivässä.

Hän tietää jo aamulla, että ehtii puuttua ehkä vain yhden tai kahden myöhässä olevan tilauksen suunnitelmiin. Kätevää olisi tietää, mitkä tilauksista ovat ne, joilla on eniten merkitystä. Tainan päässä ei ole kaikkia taustatietoja, jotka vaikuttaisivat tärkeimpien korjausten tunnistamiseen. Jossakin tietojärjestelmissä ne kyllä olisivat. Mitäköhän asiaa sitä pitäisi milloinkin eniten painottaa:

Vaikka tilaus onkin myöhässä tuotannosta, ehtiikö se samaan junaan tai rekkaan kuin oli aiottukin?
Ehtiikö seuraava juna tai rekka oikeaan laivaan?
Onko samalle asiakkaalle toimitettu tätä tuotetta jo aikaisemmin? Ja jos on, missä edellinen toimitus etenee?
Mikä on asiakkaan oma varastotilanne?
Koska asiakas viimeistään tarvitsee tuotteen niin, että ei joudu muuttamaan omia suunnitelmiaan?
Voidaanko tuote korvata?
Onko lähellä asiakasta samaa tuotetta jossakin muussa toimitusketjussa vapaana tai irrotettavissa?
Kuinka tärkeä kyseinen asiakas on tulevaisuudessa?
Mikä on todennäköisyys, että asiakas reklamoi myöhästymisestä?
Mikä on tuotteesta saatava kate?

Entä sitten ne tilaukset, joille ei ehdi tehdä mitään? Pitäisikö asiakkaalle jo ilmoittaa, että toimitus saattaa olla myöhässä? Vaikka varmuutta myöhästymisestä läpi toimitusketjun ei olekaan? ”Voi miten hienoa olisikaan, jos tuohon näytölle saisi kaikki vaikuttavat asiat näkyviin vaikka yhden klikkauksen päähän. Eikä olisi pahitteeksi, että kone laittaisi nuo virheet myös prioriteettijärjestykseen.”

Pitäisiköhän meidän auttaa Tainaa?

Asiakaskokemuksen hallinta

Koneoppiminen jo olemassa oleviin tietokantoihin perustuen tuo paljon mahdollisuuksia asiakassuhteen pitkäjänteiseen kehittämiseen. Kun yhdistellään tietoja erilaisista lähteistä, voidaan asiakaskokemusta hallita hyvin syvällisesti. Esimerkkejä:

Edellisessä kappaleessa voidaan yhdeksi priorisointiehdoksi laittaa asiakkaan luokittelu CRM:ssä. Luokittelu CRM:ssä taas voidaan tehdä automaattisesti ja ”tunteettomasti”. Eipä tarvitsisi enää kysellä myyntihenkilöltä, että onko ”sinun asiakkaasi yritykselle tärkeä”. Määritelmän mukaanhan jokainen on – joku vain vielä tärkeämpi kuin toinen.
Asiakkaan tuotantojärjestelmän tehokkuuslukuja voidaan käyttää arvioitaessa oman tuotteen sopivuutta asiakkaan käyttöön. Minkälaiset tuoteominaisuudet tuottavat asiakkaalla parhaan tuloksen?
Kaikkea tietoa toimituksista ja tuoteominaisuuksista voidaan tarkastella yhdessä asiakastyytyväisyyskyselyn tulosten kanssa, jolloin syntyy ymmärrys siitä, mitkä poikkeamat ovat asiakkaalle kaikista hankalimmat.
Yleisesti tunnettu sovelluskohde on myös tekoälyn käyttäminen todennäköisesti lähtevien asiakkaiden tunnistamiseen.

Yrityksen pitkäaikaisen menestyksen kannalta asiakastyytyväisyys on tietenkin keskeistä. Tuotteen tulee tehdä sitä, mitä se lupaa. Koska näin on, yrityksen eri osastot ovat keränneet oman toimintansa kannalta tärkeää tietoa asiakkaaseen liittyen. Tietoa on siis saatavissa. Tiedon aukottoman käytön osalta ongelmana on ollut, että kuten organisaatiot itse, myös tieto on siiloutunutta, ja yksittäisistä tietokannoista tehdyt johtopäätökset ovat puutteellisia ja joskus ristiriitaisiakin.

Uusien työvälineiden avulla tietoja erilaisista tietolähteistä voidaan sujuvasti yhdistellä yrityksen rakenteesta tai inhimillisistä rajoitteista riippumatta. Voidaan tuottaa todellista kokonaiskuvaa asiakkuudesta. Ongelmana ei enää ole myöskään tiedon numeerisuus tai verbaalisuus, eivätkä välttämättä myöskään aukot tietokannoissa. Sellaista myllyä ei kuitenkaan vielä ole keksitty, johon voitaisiin kaataa kaikki tieto ja joka antaisi oikean vastauksen itsekseen. Asiantuntijoita tarvitaan järjestelmien rakentamiseen sekä teknisessä toteutuksessa, että liiketoiminnan ja toimialojen tuntemuksessa.