Miten ketteriä menetelmiä voisi hyödyntää asiakaskokemuksen mittaustulosten käsittelyssä? Tätä mietin tässä blogissa, mikä pohjautuu tämän kesän neljännen ja viimeisen kurssini, Ketterät menetelmät palvelumuotoilussa, ennakkotehtävään. Tämän toisen esseen aiheena oli miettiä, että miten ketteriä menetelmiä voisi hyödyntää palvelumuotoilussa.
Valittu ketterä menetelmä on Kanban. Valitsin tämän menetelmän siitä syystä, että olen siitä kuullut puhuttavan Leanin yhteydessä ja siksi, että olen kuullut monen yrityksen käyttävän Kanban -tauluja toiminnassaan.
Tämä blogi koostuu osiosta, missä käydään läpi Kanban- menetelmän keskeiset piirteet sekä osiosta, missä käsitellään konkreettisia tapoja soveltaa menetelmää palveluiden kehittämisessä. Lopuksi on lyhyt yhteenveto.
Kanban- menetelmän keskeiset piirteet
Ennen kuin voidaan käsitellä Kanban -menetelmän keskeisiä piirteitä, on hyvä määritellä, että mikä Kanban on. Tämän työkalun on alun perin luonut Toyota. He käyttivät sitä tasapainottamaan kysyntää ja kapasiteettia koko arvoketjun läpi. Ajatus sen takana on melko yksinkertainen, kun on tarve jollekin tietylle osalle, se tilataan arvovirrasta ylempää. Vasta kun tilaus saadaan, tarvittavan osan valmistus aloitetaan. Tilauksia voidaan kuitenkin tehdä vain rajoitettu määrä, millä ehkäistään ylituotantoa ja vähennetään tuotantoon tarvittavien osien määrää. Vie paljon kustannuksia, jos puolivalmiita osia varastoidaan. (Skarin 2015, 4)
Skarinin (2015, 5) mukaan Kanban auttaa luomaan yksinkertaisen prosessin, minkä avulla ei tarvitse edes miettiä itse prosessia, vaan tilanteen näkee pelkästään vilkaisemalla sitä. Koska ihmiset tietävät, että mitä pitää tehdä, niin se myös vähentää väärinymmärryksiä ja virheitä kiireellisinä aikoina. Toinen etu on joustavuus, mikä tarkoittaa sitä, että kaikki muutokset tuotantolinjaan voidaan tehdä helposti ja paikallisesti. Hän (2015, 5) listaa myös viisi Kanban -sääntöä, joita on käytetty valmistavassa teollisuudessa. Nämä säännöt ovat:
Myöhempi prosessi kertoo aiemmalle prosessille, milloin uusia tavaroita tarvitaan.
Aiempi prosessi tuottaa sitä, mitä myöhempi prosessi tarvitsee.
Mitään tavaroita ei voida tehdä tai siirtää ilman Kanbania.
Havaittuja puutteita ei siirretä seuraavaan vaiheeseen.
Kanbaneiden lukumäärää vähennetään varovaisesti, jotta voidaan vähentää varastoja ja paljastaa ongelmia.
Vaikka Kanbania on perinteisesti käytetty valmistavassa teollisuudessa, niin sen ydinajatuksia voidaan hyödyntää myös tietotyössä. Skarin (2015, 6) listaa kuusi Kanbanin ydinajatusta, joita soveltamalla sitä voidaan hyödyntää myös tietotyön kehittämisessä. Nämä ydinajatukset ovat:
Visualisoi työjono. Kun työjonon visualisoi, se auttaa saamaan jaetun näkymän kokonaisuudesta, sen sijaan, että tieto olisi piilotettuna kovalevyille ja sähköpostilaatikoihin. Visualisoimalla työjonon, osallisilla on mahdollisuus oppia kokonaisuudesta ja tehdä toimenpiteitä sen pohjalta. Sen avulla pystytään myös tunnistamaan prosessien pullonkauloja sekä toistuvia laatuongelmia.
Rajoita WIPiä (Work-In-Progress), keskeneräistä työtä. Rajoittamalla keskeneräistä työtä, pystytään tasapainottamaan kysyntää ja toimituskapasiteettia. Tällä tavoin pystytään tuottamaan laadukkaita tuotoksia ja mahdollistamaan työntekijöiden työskentely kestävällä tavalla.
Johda arvovirtaa. Jotta voidaan parantaa toimintaa, tulee johtaa rajoitteita sekä mitata arvovirtaa. Yleisimmät mittarit, millä arvovirtaa voidaan mitata ovat läpimenoaika ja suoritusteho.
Tee prosessikäytännöistä täsmällisiä. On todella tärkeää, että tiimin jäsenet ymmärtävät käytännöt samalla tavalla. Jos käytännöt eivät ole selviä kaikille, on todella vaikeaa kehittää toimintaa, kun jokaisella tiimin jäsenellä on eri vaatimustaso. Tästä syystä käytäntöjen tulee olla täsmällisiä.
Toimeenpane palautesilmukat. Koska Kanban-järjestelmä näyttää vain organisaation oman näkemyksen laadusta, on tosi tärkeää saada palautetta myös eri sidosryhmiltä. Kun saadaan säännöllistä palautetta, se auttaa organisaatiota oppimaan, että miten päästään oikeaan suuntaan tuotekehityksessä.
Paranna yhteistyössä, kehitä kokeilemalla. Kanban-menetelmän tärkein ajatus on, että nykytilannetta kehitetään pienten askelten avulla. Tässä kehittämisessä voidaan hyödyntää esimerkiksi ongelmanratkaisua, kokeiluja ja tieteellisiä menetelmiä.
Eräs yleisimmistä virheistä, mitä tuotekehityksessä tehdään, on panostaa tuotekehityksen arvovirran kehittämiseen eikä tiedonkulun kehittämiseen. On todella tärkeää, että asiakasymmärrys (palautteet, havaitut puutteet, kehitysideat yms.) liikkuu nopeasti organisaation sisällä. Ne ovat asiakkaat, jotka lopulta päättävät, että onko organisaatio onnistunut tuotekehityksessä, ei organisaatio itse. (Skarin 2015, 7)
Konkreettisia tapoja soveltaa menetelmää palveluiden kehittämisessä
Tehtävänantona oli miettiä otsikon aihetta liittyen omaan työhön. Koska opiskelen tällä hetkellä päätoimisesti, niin mietin tätä hieman erilaisesta näkökulmasta. Opparini aiheena oli luoda uusi tapa mitata asiakaskokemusta ja hallinnoida tuloksia systemaattisesti kiinteistöalan IT-palveluiden yrityksessä. Käsittelen esseessä sitä, että miten Kanbania voisi hyödyntää saatujen tulosten käsittelyssä ja sitä kautta palveluiden kehittämisessä ja koko organisaation pitemmän tähtäimen kehittämisessä pikavoittojen sijasta.
Opinnäytetyöprojektin jälkeinen lähtötilanne on siis se, että asiakaspalautetta kerätään neljästä eri kohtaamisesta ja tulosten käsittelylle on luotu yhteiskehittämisen keinoin follow-up prosessit. Nämä kohtaamispisteet ovat tukipuhelut, tuotteiden käyttö, projektien implementointi ja asiakassuhteen hoitaminen. Seuraava vaihe olisi miettiä, että miten sellaisia havaittuja ongelmia/kehitysideoita, jotka vaativat useamman yksikön panosta, voitaisiin käsitellä nopeammin ja laadukkaammin.
Sarkin (2015, 23-55) esittelee kirjassaan casen, joka soveltuu mielestäni myös tähän tilanteeseen. Tästä casesta poimittuja ideoita soveltamalla voitaisiin kehittää myös saatujen asiakaspalautteiden käsittelyä ketterämmäksi. Tarkastelen tätä hänen aiemmin esittelemänsä kuuden Kanbanin ydinajatuksen kautta (2015, 6), joita soveltamalla sitä voidaan hyödyntää myös tietotyön kehittämisessä.
Työjonojen visualisointi
Ensimmäisenä voitaisiin lähteä siitä, että visualisoidaan eri yksiköiden työjonot, niin saadaan kokonaisnäkemys tilanteesta. Tällä tavoin voidaan löytää prosessigappeja, visualisoida ja ymmärtää eli vaiheiden välisiä asiakkaiden/yksiköiden odotusaikoja, sekä ymmärtää monimutkaisia ongelmia ja prosesseja niiden visualisoinnin avulla. (Sarkin 2015, 11)
Lähtisin siitä, että jokaiselle yksikölle tulisi oma yksikkötasoinen Kanban-taulu, millä visualisoida oma työjono, mutta sen lisäksi yksi yhteinen Enterprise-tason taulu. Tulisi siis neljä yksikkötasoista taulua, yksi asiakastuelle, yksi tuotehallinnalle, yksi projektihallinnalle sekä yksi asiakkuuksien hallinnalle. Näiden neljän yksikkötasoisen taulun lisäksi yksi Enterprise-tason taulu, mihin tuodaan saadun palautteen pohjalta havaitut kehitysideat/ongelmat, jotka vaativat useamman eri yksikön työpanosta. Enterprise Kanban-taulun avulla (Skarin 2015, 25-26) visualisoida arvovirta alusta loppuun ja luoda yhteinen jaettu näkemys eri sidosryhmien välille.
Jokaisella neljällä yksilöllä olisi oikeus tuoda ongelmia/kehitysideoita, joita on tullut kerätyn palautteen pohjalta, Kanban-taulun ensimmäiseen vaiheeseen. Edellyttäen, että kyseinen ongelma/kehitysidea on tarpeeksi hyvin määritelty. Se henkilö, ketä eniten kiinnostaa kyseisen ongelman ratkaisu, hänestä tulisi sen omistaja. Hänen vastuullaan olisi ongelman/kehitysidean avaaminen niin, että muut tiimit ymmärtävät, että mistä on kyse, sekä sen edistäminen. (Sarkin 2015, 29)
Keskeneräisen työn rajoittaminen
Tässä johdon esimerkillä on kriittinen rooli. Sen sijaan, että pidettäisiin kiinni tarkkaan määritellyistä prosesseista ja hyväksymisjonoista, tulisi myöntää mandaatti tehdä päätöksiä niille henkilöille, kenellä on paras tieto ongelmasta (Skarin 2015, 18). On todella tärkeää pystyä luomaan järjestelmä, jonka avulla työntekijät voivat luoda arvoa ja korjata laatuongelmia (Skarin 2015, 10) sekä keskittyä yhden ongelman ratkaisuun kerralla (Skarin 2015, 16).
Kuten Skarinin (2015, 47) mainitsemassa casessa, tulisi sopia yhdessä eri yksiköiden välillä siitä, että miten ja milloin versiopäivityksiä tehdään. Näin päivityksiä tekevä kehitystiimi pystyy todennäköisestä priorisoimaan paremmin työjonoaan, eikä tarvitsi tehdä kompromisseja laadun suhteen, kun aikataulut puskevat päälle. Tulisi siis sopia ennakkoon sovitut vasteajat muutoksille ja varmistaa, että niistä myös pidetään kiinni. Hyvä lisäys tähän voisi olla se, mitä Skarin (2015, 48-50) käytti, eli myönnetään mandaatti julkaista pienempiä tuotoksia heti kun ne on laadukkaasti saatu valmiiksi.
Koska jokaisella yksiköllä on todennäköisesti myös paljon tehtävää, mikä ei liity siihen työhön, mitä Kanban-tauluilla käsitellään, niin tulee miettiä, että miten työkuormat näiden eri tasoisten tehtävien välille jaetaan. Oppariprojektissa luoduissa follow-up prosesseissa palautteet on jaoteltu kolmeen tasoon, hyvään (NPS 9-10), Ok (NPS 7-8) ja huonoon (NPS 0-6), mutta ne eivät vielä kerro sitä, että miten kauan ongelman ratkaisemiseen menee aikaa. Työkuorman mukaan tehtävät voisi jakaa esimerkiksi seuraavalla tavalla:
50 % sellaisten tehtävien hoitamiseen, jotka vaativat yhteistyötä useamman eri yksikön kanssa. Ongelmalle ei ole valmista ratkaisua, vaan se pitää kehittää yhdessä ja se vaatii aikaa yhteiskehittämiselle (Enterprise Kanban-taululta)
20 % sellaisten tehtävien hoitamiseen, asiakkaiden ongelmat mitkä vaativat vähän enemmän aikaa ja vaivaa, mutta palautteen vastaanottanut yksikkö pystyy ne itse hoitamaan saatuaan lisätietoa toiselta yksiköltä (yksikön omalta Kanban-taululta)
20 % sellaisten tehtävien hoitamiseen, jotka ovat asiakaspalautteen pohjalta tulleet kehitysideat, jotka palautteen vastaanottanut yksikkö pystyy itse toteuttamaan (yksikön omalta Kanban-taululta)
10 % sellaisten tehtävien hoitamiseen, asiakkaiden ongelmat, jotka pystytään nopeasti hoitamaan palautteen käsitelleen tiimin toimesta. Esimerkiksi vastaukset kysymyksiin, ohjaus jo olemassa oleviin ohjeistuksiin tai johonkin muuhun sijaintiin, mikä vastaajalla on jo tiedossa jne.
Arvovirran johtaminen
Mielestäni tässä voitaisiin käyttää myös toista samaa mittaria, kuin Skarin (2015, 40) käyttää casessaan, eli läpimenoajan mittaamista. Tarkoittaen sitä, että kuinka kauan kestää, että yksi ongelma/kehitysidea menee koko prosessin läpi. Toinen mittari voisi olla se, että kun luotu ratkaisu on esitetty asiakkaalle, niin ratkaiseeko se asiakkaan ongelman vai, eli onko asiakas tyytyväinen ratkaisuun vai ei.
Säännölliset lyhyet 15 min Kanban-tapaamiset viikoittain, missä eri yksiköiden edustajat olisivat paikalla. Jokaisesta palautetta keräävästä yksiköstä olisi yksi edustaja, osallistuja, joka kiertäisi säännöllisesti. Sen lisäksi jokaisesta tuotekehitysyksiköstä olisi vaihtuva edustaja tarpeen mukaan. Tämä toimintatapa todennäköisesti lisäisi omistajuutta ja osallisuuden tunnetta osallistujissa. Jos jotain muita resursseja tarvitaan, silloin heidät pyydettäisiin mukaan tapauskohtaisesti. Joka tapauksessa on tärkeää, että tässä lyhyessä tapaamisessa olisi mandaatti tehdä päätöksiä. Jos päättäjä ei itse pääse paikalle, niin silloin hän luovuttaisi päätösvallan edustajalleen. Kuten Skarin (2015, 37-38) kertoo tehneensä kuvaamassaan casessa.
Täsmälliset prosessikuvaukset
Jotta tämä uusi toimintapa tulisi onnistumaan, pitää luoda yhteiset pelisäännöt, minkä mukaan toimitaan. Tässä ei mielestäni toimi se, että johto ylhäältä päättää, että miten toimitaan, vaan on kriittistä, että ne luodaan yhdessä eri yksiköiden kesken. Niiden tulee kuitenkin olla mahdollisimman yksinkertaisia ja ”yhteisellä” kielellä kirjoitettuja, että kuka vain uusikin työntekijä ymmärtää ne.
Kun ihmiset pääsevät itse vaikuttamaan siihen, että miten toimitaan, sitouttaa se yleensä heidät paremmin siihen, koska he ovat sen itse olleet luomassa. Tämä on muutosjohtamisen kannaltakin oleellinen asia, että uusi toimintatapa saadaan vietyä helpommin ja nopeammin läpi yrityksen.
Palautteen kerääminen
On tärkeää mitata sitä, että onko uusi toimintatapa kehittänyt asiakaspalautteiden käsittelyä ja nopeuttanut ongelmien/kehitysideoiden ratkaisua. Kuten Skarin (2015, 40) sanoo, faktapohjaista palautetta tarvitaan päätösten tueksi ja siksi, että voidaan todistaa, että ollaan menossa oikeaan suuntaan. Ei niinkään tulisi mitata sitä, että onko onnistuttu täydellisesti, vaan sitä, että kehitystä tapahtuu. Kuten mainittu osiossa Arvovirran johtaminen, mittareina voisi käyttää läpimenoaikaa ja sitä, että onko asiakas tyytyväinen ratkaisuun.
Kun mitataan sekä omaa onnistumista, sekä asiakkaan näkökulmaa siitä, se auttaa välttämään puolueellisen näkemyksen ja sen harhakuvan, että olisi onnistuttu, vaikka asiakas onkin eri mieltä. Sinkkonen et al. (2009) mukaan on aina hyvä pitää miehessä se, että asiakkaiden panos on aina paljon arvokkaampi, kuin asiantuntijoiden mielipide asiakkaiden panoksesta ja tarpeista.
Yhteiskehittäminen ja nopeat kokeilut
Skarinin (2015, 10, 13) mukaan on todella tärkeää valtuuttaa työntekijöitä korjaamaan asioita, jotka eivät heidän omassa työssään toimi. Se todennäköisesti johtaisi korkeampaan motivaatioon, tehokkaampaan työskentelyyn ja parempaan laatuun. Yksi tärkeä tekijä on lisätä nopeita kokeiluja raakaideoista/muutoksista ennen niiden toteuttamista oikeiden käyttäjien kanssa. Rohkeasti vaan kokeilemaan ja validoimaan tuotos (Skarin 2015, 12-13).
Saadun palautteen pohjalta idean iterointi ja jatkokehitys tai tarvittaessa hylkääminen. Kun saadaan organisaatioon istutettua jatkuvan parantamisen malli erillisten pamuprojektien sijaan (Skarin 2015, 9, 38-40), saataisiin lisättyä systeemiajattelua organisaatiossa (Skarin 2015, 16) minkä avulla voidaan nähdä muutoksen vaikutukset koko organisaatioon, ei vain yhteen yksikköön tai osa-alueeseen (Skarin 2015, 11, 12, 16). Tämä myös todennäköisesti vähentäisi päällekkäisiä projekteja ja auttaisi optimoimaan käytössä olevia resursseja.
Kun on saatu asiakkaalta palautetta, esimerkiksi että jokin tuote on vaikea käyttää, mutta käyttäjä ei osaa sitä tarkemmin kuvailla, että miksi, lähdettäisiin kokeilemaan erilaisia ratkaisuja yhteiskehittämällä nopeasti kokeillen niitä käyttäjien kanssa. Tässä nousee ratkaisevaan rooliin se, että pystytään yhdessä eri yksiköiden kanssa luomaan prototyyppejä asiakaspalautteen pohjalta nousseisiin ongelmiin/kehitysideoihin. Näitä voidaan luoda esimerkiksi fasilitoiduissa työpajoissa, missä olisi vaihtuvat osallistujat eri tiimeistä, mikä todennäköisesti lisäisi osallisuuden ja omistajuuden tunnetta. Näissä työpajoissa mietittäisiin yhdessä ratkaisuja joskus todella karkeisiinkin ideoihin (Skarin, 28-31) ja luoda niihin MVP (Minimun Viable Product), mistä käyttäjä näkisi idean takana olevan logiikan ja pystyisi testaamaan ratkaisun rautalankamallia käytännössä.
Yhteenveto
Tämän lyhyen analyysin perusteella Kanban-menetelmä soveltuisi mielestäni oikein hyvin kerätyn asiakaspalautteen käsittelyyn. Mutta se edellyttää johdolta esimerkin näyttämistä ja sitä, että uskalletaan siirtyä resurssien käytön tehokkuudesta, arvovirran tehokkuuden kautta arvon optimointiin (Skarin 2015, 8). Tarvitaan myös päätösvallan lisäämistä niille henkilöille, jotka havaittujen ongelmien kanssa työskentelevät, että pystytään toimimaan ketterästi eikä tarvitse odottaa hyväksyntää aina ylempää. Ja tälle toiminnalle pitää varata aikaa, että työntekijät pystyvät oikeasti keskittymään sellaiseen työhön, joka tuottaa arvoa asiakkaille. Uskoisin myös, että tämä toimintatapa lisäisi yhteistyötä eri yksiköiden välillä, tehostaisi tiedonkulkua, lisäisi läpinäkyvyyttä ja sitä kautta parantaisi työn laatua, mistä asiakas nauttisi.
Edellytyksenä on kuitenkin se, että luodaan yhdessä selkeät toimintatavat, mitkä kaikki sidosryhmät ymmärtävät, eli on yhteinen kieli, ja näistä pidetään kiinni. Toinen edellytys on se, että pystytään ajattelemaan pidemmällä tähtäimellä eikä tavoitella pelkkiä nopeita voittoja (Skarin 2015, 13-16) ja se, että parannetaan toimintaa pienin askelin eikä yritetä rykäistä kerralla isoa muutosta läpi. Kanban-menetelmän avulla voidaan päästä jatkuvan parantamisen toimintatapaan yksittäisen palvelumuotoiluprojektien sijaan.
Tämä on tosiaan ensimmäinen kirjoitukseni ketteristä menetelmistä. Mitä olet mieltä, voisiko Kanbania hyödyntää tällä tavoin asiakaskokemuksen mittaustulosten käsittelyssä?
Lähteinä käytetty:
Sinkkonen, I., Nuutila, E. and Törmä, S. 2009. Helppokäyttöisen verkkopalvelun suunnittelu. Helsinki: Tietosanoma.
Skarin, M. 2015. Real-world Kanban: Do less, accomplish more with lean thinking. [Place of publication not identified]: Pragmatic Bookshelf.