Kuinka johdan prosesseja tiedolla OSA 3

Mittarin tulosten tulkitseminen ja jatkotoimenpiteet

No miten niitä mittarin antamia tietoja voi ja kannattaa hyödyntää? Tietysti jos tulokset ovat hyviä, niin niiden antamasta palautteesta ja tavoitteiden saavuttamisesta kannattaa iloita ja nauttia yhdessä. Lähestyn asiaa kahdesta näkökulmasta; kun tavoitteita ei olla vielä saavutettu tai tilanne, jossa on saavutettu tavoitetaso, mutta sitten tulokset huononevat.

Jos prosessin tavoitteet on saavuttamatta

Jos prosessi on vielä uusi tai mittaaminen vasta aloitettu, on tyypillistä, ettei tavoitteisiin välttämättä päästä heti. Mittarin antamaa tietoa kannattaa seurata tiiviisti, mutta aikaa datan keräytymiselle kannattaa antaa, ettei tehdä vääriä johtopäätöksiä aineiston pienuuden perusteella.

Kyseenalaista mittari ja mitattava toiminta

Ihan ensimmäiseksi kannattaa kyseenalaistaa mittari sekä mitattava prosessi, jos prosessin tavoitteet tuntuvat pysyvän yhtä kaukana kuin Jupiter. Mittarin tarkkuus kannattaa tarkistaa, että mittari varmasti mittaa haluttua asiaa ja ettei laskentakaavoissa tai graafeissa ole virheitä.

Tarkasta käytettävän datan laatu

Jos virheitä ei löydy, kannattaa seuraavaksi tarkastaa käytettävä data, että sen laatu on riittävän hyvä. Jos puutteita ei löydy datan laadustakaan, niin katsetta tulisi suunnata kohti prosessia, johon mittaus kohdistetaan.

Datan laatua on syytä epäillä aina silloin, kun käytettävä data koostuu ihmisen kirjoittamista tiedoista. Aikanaan laadin raporttia yritykselle ja halusin suodattaa laatupoikkeamien määrän maittain. Ihmettelin erikoisia tuloksia ja kaivelin exceliä, josta dataa käytin ja huomasin, että sana ”Suomi” esiintyi taulukossa kolmellatoista eri tavalla. Tämä taas johtui siitä, että laatuvirheen raportointiohjelmaan tapahtumamaa-tietoa keräävä kenttä oli vapaa tekstikenttä eikä valmis valintalista.

Edellisessä artikkelissani kertomassani esimerkissä oli juuri se tilanne, että itse mittari oli laadittu oikein, data oli hyvälaatuista, mutta syyksi löytyi prosessivirhe – eli päivämäärä kirjattiin järjestelmään väärin perustein.

Yksi tapa selvittää vikaa on juurisyyanalyysi. Aikaisemman esimerkin oikeita mittarituloksia alettiin selvittämään, miksi 5 % lähetyksistä on myöhässä yli yhden päivän. Tutkimme dataa eri näkökulmista ja haastattelimme myynnin ja varaston henkilökuntaa selvittääksemme heidän näkemystänsä myöhästymisten johtumissyystä. Lopulta huomasimme erään asiakkaan tilaavan toistuvasti sellaisia osia, joita ei ollut luokiteltu suositelluiksi varaosiksi, eikä näitä pidetty keskusvarastossa.

Asiakkaan kanssa käytyjen keskusteluiden johdosta löydettiinkin syy, että laitetta, johon osia on tilattu, käyttää aivan eri henkilöt, jotka ovat alun perin saaneet käyttäjäopastuksen valmistajalta.

Epätavanomaisten osien rikkoutuminen johtui siis käyttäjävirheistä. Ratkaisuksi tilanteelle saatiin järjestettyä lisäkoulutus laitteen käyttäjille. Vaikka mittari oli tarkoitettu yrityksen sisäiseen laadunohjaukseen, niin päästiin asiakkaan suorituskyvyn parantamiseen ja saatiin vielä myytyä koulutusta asiakkaalle.

Jos prosessin tavoitteet alkaa loitontua ja mittarit huutavat punaisella

Jos mittari on ollut jo jonkin aikaa käytössä ja tavoitteissakin on oltu, mutta yhtäkkiä tilanne huononee, on syytä reagoida pikaisesti.

Otetaan esimerkki asiakaspalvelusta, jonka tavoitteena oli tarjota vikkelä palvelu yhden kontaktin taktiikalla asiakkailleen.  Asiakaspalvelulla oli käytössään mm. seuraavat mittarit:

• NPS-mittari
• Mittari, joka kuvasi asioiden hoitajien lukumäärää / asiakkaan ongelmatapaus
• Kirjattujen asiakaspalautteiden määrä

Yhtäkkiä käykin niin, että toista viikkoa NPS ja – Asiakkaan asianhoitajien lukumäärä enintään 2 henkilöä / asiakkaan ongelma – mittarin tulokset heikkenevät. NPS näyttää jo toista viikkoa lukemaa 8, ja useammalla asiakkaalla on ollut yli kaksi kontaktia asianhoitamisessa. Lisäksi asiakaspalautteita ei ole kirjattu riittävästi palautejärjestelmään.

Mittareista saatavaa tietoa on syytä seurata riittävän usein, jotta ongelmiin voidaan puuttua mahdollisimman varhaisessa vaiheessa.

Yritetäänpä yhdessä selvittää, mistä kiikastaa, käydään mahdollisuudet systemaattisesti läpi:

1. Tässä tuskin on kyse mittarin virhetilanteesta.
2. Datan laatu on syytä tarkastaa, mutta tässä tapauksessa sekin on kunnossa.
3. Käännetään katsetta prosessipuolelle ja mietitään yhdessä tiiminvetäjän kanssa, mitä sellaista on tapahtunut viikko sitten, että mittarit alkavat painua keltaiselle. Ah, kappas, heidän uusi työntekijänsä on työskennellyt viime viikosta lähtien itsenäisesti perehdytysjaksonsa jälkeen.

Kun tiiminvetäjä kävi keskustelua uuden työntekijän kanssa, niin ilmeni, että uusi työntekijä koki, ettei löytänyt tietoja riittävän helposti – ja sen vuoksi ohjasi asiakkaan soittamaan toiselle henkilölle, niinhän edellisessäkin työpaikassa oli tapana tehdä.

Uusi työntekijä kertoo, että perehdytysjaksolla ei ollut tullut kaikenlaisia tapauksia eteen, jotta hänelle olisi niistä vielä kerääntynyt kokemusta ja muistijälkiä (tässä yrityksessä oli nimenomaan sovittu, että selvittelytyö tehdään sisäisesti, jotta ongelman ratkaiseminen olisi asiakkaalle mahdollisimman yksinkertaista).

Valveutunut tiiminvetäjä keskusteli vielä lisää uuden työntekijän kanssa ja he päätyivät ratkaisuun, että kokoavat hakemiston, jonka avulla tietoja ja henkilöitä oli helpompi löytää. Lisäksi tiiminvetäjä teroitti, että uusi työntekijä voi kysyä häneltäkin neuvoja, ennen kuin viestii asioita asiakkaan suuntaan, kunnes työn tekeminen hieman rutinoituu. Mittarit palasivat näin ollen takaisin tavoitteisiin.

Lopuksi

Olemme päässeet yhdessä artikkelitrilogian loppuun. Toivon, että alla oleva kuva, joka on oma tulkintani Hemingin PDCA-ympyrästä, kiteyttää  ajatuksen prosessien suunnittelusta ja prosessien kyvykkyyttä kuvaavien mittareiden suunnittelusta.