Lyhennä toimitusaikaa kohdennetulla parannusprojektilla (2/2)

(lue osa 1. täältä)

Kohdennetun toimitusketjun parannusprojektin käytännön vaiheet:

Ennen projektin aloitusta pitää olla olemassa todellinen tarve, ongelma ja halu parantaa tiettyä logistiikkaprosessia. Tarpeen ja ongelman tulee olla sellainen joka vaikuttaa merkittävästi liiketoimintaan (tulos, myynti, varastot, kustannukset) tai tärkeään (tai potentiaalisesti jatkossa tärkeään) asiakkaaseen. Kohde voi olla esim. jokin tärkeä asiakas ja hänen toimituksiansa viivyttävä tuote tai jokin kriittinen toimittaja jonka viiveet aiheuttavat ongelmia tuotannolle materiaalipuutteina. Jollain tasolla pitää pystyä hahmottamaan ongelman taloudelliset vaikutukset jo alkuvaiheessa. Mikäli useita arvoketjuja on ehdokkaina parannuksen kohteeksi, kannattaa valita ensiksi niistä se liiketoiminnan kannalta kriittisin ja jossa parannuksen perusedellytykset olemassa. Sen osalta tulee tarkemmin kartoittaa ongelma, sen taloudelliset sekä muut vaikutukset liiketoimintaan, dokumentoida nämä ja tehdä ehdotus päätettäväksi, aloitetaanko projekti ko. alueella. Tässä vaiheessa ei kannata vielä tehdä tarkempia analyysejä, tutkia asiaa vain sen verran että pystytään päättämään kannattaako ko. alue tutkia tarkemmin ja toteuttaa parannukset vaiko ei.

Jos päätös jatkosta on myöntävä, pistetään projekti pystyyn, kootaan tiimi ja ohjausryhmä, suunnitellaan, kommunikoidaan perusasiat riittävän laajasti ja lähdetään liikkeelle. Raskasta ylisuunnittelua kannattaa välttää koska moni asiaa selviää vasta seuraavassa vaiheessa prosessin nykytilan analysoimisella. Voi olla että projektin mitattavat tavoitteetkin voidaan asettaa vasta nykytilan analyysin jälkeen, kun prosessin asiakkaan tarpeet ja todelliset ydinongelmat paljastuvat.

Prosessin nykytila, ongelmat, syyt niiden taustalla, suorituskykyä ja tehokkuutta rajoittavat tekijät, selviävät tehokkaasti arvoketjun analysoinnilla ja kuvauksella (engl. Value Stream Mapping) ja tähän kuuluvilla ja tarvittavilla tietoanalyyseillä. Käytännössä tämä tarkoittaa tilaus-toimitusprosessin läpikävelyä haastattelemalla prosessin käytännön tason tekijät vaihe vaiheelta. (Mukaan tulee ottaa myös ennustamisprosessi mikäli ennustaminen on käytössä ja sillä on todellista vaikutusta tilaus-toimitusprosessiin ja sen suorituskykyyn.) Tämä tapa toimii erityisesti kun prosessi kulkee henkilöiden kautta jotka sijaitsevat eri paikoissa ja halutaan optimoida matkakustannukset. Mahdollisesti tulee kehittää uusia mittareita jos esim. selviää etteivät olemassa olevat mittarit mittaa toimitusprosessin suorituskykyä asiakkaan näkökulmasta. Mittarien ei tarvitse olla täydellisiä ja kattavia vaan “oikeaan suuntaan”, tarvittaessa jatkossa voidaan kehittää mittaristoa pysyvämmin ja kiinteämmin osaksi normaalia raportointia tietojärjestelmistä. Mittariston muutostarve yksistään voi olla yksi projektin merkittävä tulos. Arvoketjun kuvauksen ja analysoinnin keskeinen tarkoitus on YMMÄRTÄÄ PROSESSI perinpohjin, tämä mahdollistaa tehokkaaat toimenpiteet ja hyvät lopputulokset suurella todennäköisyydellä ja vältytään arvailuilta ja oletuksilta.

Kun prosessi on analysoitu ja kuvattu, tulee koota sopiva tiimi 1-2 päivän työpajaan. Tiimin tulee olla sellainen, joka kattaa mielellään prosessin alusta loppuun ja pystyy päättämään ja tekemään tarvittavat käytännön parannustoimenpiteet. Ensiksi käydään läpi prosessin kulku ja analyysin keskeiset tulokset, ongelmat, syyt, rajoittavat tekijät. Tämän jälkeen siirrytään systemaattiseen ongelman ratkaisuun, jossa ensiksi tulee määrittää ja sopia yhdessä mikä tai mitkä ovat (1) prosessin ydinongelma(t) (1-3kpl) erityisesti liiketoiminnan ja asiakkaan näkökulmasta(!). Tämä on erittäin tärkeä vaihe ja tähän kannattaa varata aikaa(1-2tuntia) ja valmistella jo etukäteen eri osapuolten kanssa ajan säästämiseksi varsinaisessa työpajassa. Tämän jälkeen tulee hakea tiimissä (2) syyt ydinongelmalle. Tämä onnistuu esim. ideariihen avulla, jokainen merkitsee esim. post-it-lapuille tietämiään syitä. Tämän jälkeen syiden ryhmittely, otsikointi ja mahdollinen priorisointi. Tämän jälkeen tunnistetuille syille pitää määrittää (3) ratkaisut otsikkotasolla. Ratkaisut pitää vielä purkaa (4)  toimenpiteiksi, joille merkitään myös vastuullinen koordinoija tai tekijä, sekä aikataulu, koska toimenpiteen tulee olla tehtynä. Tämän konkreettisen toimintasuunnitelman luominen on tärkeää ja vaatii joskus vääntöä, mutta muuten hyötyjen ulosmittaaminen voi jäädä haaveeksi. Tuloksena voi myös olla laajempia parannustarpeita joita ei voida ko. ryhmällä päättää tai toteuttaa 1-3kk ajassa, mutta nämä kannattaa eriyttää erikseen tehtäviksi ehdotuksiksi esim. projektin ohjausryhmälle. Näiden ei tule estää parannusten tekemistä kohdealueella välittömästi. Liian helppoa on jäädä odottamaan sitä ja sitä isompaa muutosta, tietojärjestelmän uudistamista tai päivitystä jonka jälkeen (kaikki) asiat (oletettavasti) paranevat. Useimmiten on mahdollista parantaa prosessin suorituskykyä välittömästi muutamilla melko yksinkertaisilla toimenpiteillä.

Työpajan jälkeen seuraa tekeminen ja sen tiivis seuranta. Tässä tulee jonkun toimia aktiivisena “orjapiiskurina” jotta tehtävät tulee tehtyä, tehtävien eteenpäin menon ja tulosten seuranta vähintään viikoittain esimerkiksi 30-60min palavereissa. Tämä on välttämätöntä koska monesti ko. henkilöillä on rooli operatiivisessa toiminnassa ja tämä ajaa usein kehitystyön ohi ellei joku hieman muistuta ja tue tekemisessä ja mahdollisissa ongelmatilanteissa. Tarvittavien mittarien seurannan pitää tässä vaiheessa toimia, jotta nähdään milloin tekemiset vaikuttavat käytännössä ja koska tavoitteet saavutetaan. Jos toimenpiteet eivät vaikuta mittareiden tuloksiin, jossain on korjattavaa. Tekemisvaiheessa viimeistään selviää mikäli jokin osapuoli ei halua tarvittavaa muutosta, tähän kannattaa varautua. Lopuksi tulee varata aikaa projektin tulosten dokumentointiin ja oppien jakamiseen sekä mahdollisten jatkokehitysprojektien alustamiseen tai suunnitteluun. Sekä tietysti tiimin kovan työn palkitsemiseen ja huomioimiseen! Hyviä saavutuksia kannattaa jollain tavalla juhlistaa ja tässä kohtaa johdon pienemmätkin huomionosoitukset tiimille ja sen tuloksille voivat kantaa suurtakin hedelmää jatkossa parantamismyönteisemmän ilmapiirin syntymisen kautta. Ja päinvastoin.

Oliko tästä kirjoituksesta apua sinulle? Jäikö jotain oleellista epäselväksi? Koetko ettei tämä lähestymistapa toimi sinun ympäristössäsi, miksi ei? Onko sinulla parannusehdotuksia lähestymistapaan tai muita kommentteja, kysymyksiä? Olen suunnittelemassa tarkemman ohjeen luontia tästä aiheesta, olisiko sinulla tarvetta tai kiinnostusta sellaiselle, minkälainen sen sisällön tulisi olla? Kaikenlainen palaute tervetullutta ja artikkelia saa jakaa jos koet että siitä voi olla muillekin hyötyä.

2 comments

  1. Rauno Hoikkala

    Näin juuri, pienistä ja yksinkertaisista asioista muodostuu suuri kokonaisuus. Olen samaa mieltä toimenpiteistä ja käytännön toimista. Ongelma tässäkin asiassa tahtoo olla liian usein jälkiseurannan pettäminen ja jatkuvan kehittämisen laiminlyönti.

    Oman käsitykseni mukaan toimitusketjuprosessi täytyy poiketa paljon pienten ja suurten yksiköiden välillä, vaikka toimitusketjun perusrunko ja asiakkatkin voivat olla samoja. Pelkästään fyysiset mittasuhteet tekevät näistä eriarvoisia. Onhan kukin case tapauskohtainen ja aina räätälöitävissä, oli sitten kyseessä pieni tai suuri yksikkö.

    Toinen seikka, joka mietityttää on mittareiden asettaminen. Kun niitä perustetaan, niin mietitäänkö aina riittävän tarkkaan ketä ja mitä ne parhaiten palvelevat? Ohjataanko yritystä mittareilla oikein ja yrityksen etua ajatellen eli mitataanko oikeita asioita? Jos mittarit ovat esim. osa tulospalkkiota, niin voidaan olla vaarallisilla aluiella, mittareiden ohjatessa yritystä.

    • Kiitos Rauno kommentista! Mittarit ovat haasteellisia ja juuri näin, voivat johtaa pahimmillaan harhaan kokonaisuuden kannalta. Kiitos vinkistä, kirjoitan näistä blogia lähitulevaisuudessa, tärkeä aihe. Esim. kun mitataan toimitusvarmuutta, se voi monesti olla enemmän omasta kuin asiakkaan näkökulmasta mitattuna. Toisaalta hyvä jos on edes jotkut perusmittarit, voi olla vielä huonompi jos niitä ei ole lainkaan. Kun on joku pohja, mittareita voi kehittää parempaan suuntaan.

Leave a Reply