Kun asiakaskokemuksella tarkoitetaan yleensä asiakkaan kokonaisvaltaista tyytyväisyyttä yritystä kohtaan, mittaa palvelukokemus asiakkaan kokemusta palvelun laadusta. Tällöin palvelun lopputulos (esim. it-alalla tietojärjestelmä) jätetään vähemmälle huomiolle. Tässä kirjoituksessa pohdin sitä, voisiko pelillistämisellä parantaa palvelun aikana koettua palvelukokemusta.
Helsingin yliopiston tutkija Mika Hyötyläinen on kirjoittanut, että ICT-palvelun käyttöönottopalvelu on sosiaalinen prosessi. Käytännössä siis teknologia ja innovaatiokeskeinen ajattelu eivät yksistään riitä teknisen järjestelmän käyttöönottoprosessin laadukkaaseen toteutukseen. Palvelu- ja asiakassuhdemarkkinoinnin professori Christian Grönroos mainitsee kirjassaan, että mikäli asiakas kokee palvelun aikaisen vuorovaikutuksen monimutkaisena, vaikeana tai epämiellyttävänä, saattaa lopputulokseltaan erinomaisen palvelupaketin koettu laatu jäädä heikoksi.
Tietojärjestelmän käyttöönotto vaatii paljon resursseja myös tilaajalta. Projektipäällikkönä olen useamman kerran kuullut kysyttävän, että miksi projekti vaatii asiakkaalta niin paljon työtä. Asiakashan maksaa projektista toimittajalle - eikö toimittajan tulisi tehdä kaikki työt?
Koko projektia on tuskin koskaan mahdollista ulkoistaa it-toimittajalle. Kuten Mika Hyötyläinenkin kirjoittaa, tarvitaan ICT-palvelun suunnittelussa paljon tietoa organisaation prosesseista. Tämä tieto on harvoin dokumentoitua ja se on hyvin kontekstiriippuvaista. Projektiin on löydettävä oikeat henkilöt ja tunnistettu tieto on perusteltava ja sovellettava ICT-palvelun tarpeisiin.
Olennaista onnistuneen käyttöönottoprojektin toteutuksessa on se, että asiakas tietää etukäteen, mitä tältä odotetaan. Yksi onnistuneen palvelukokemuksen avaimista on oikeanlaisen projektiryhmän muodostaminen. Jokaisen projektiryhmäläisen tulee tietää oma rooli ja vastuualueet projektissa. Projektiryhmäläisellä tulee myös olla työaikojensa puitteissa mahdollisuus ottaa se vastuu, jota häneltä odotetaan. Oma mutu-tuntumani on, että silloin tällöin projektiryhmään otetaan mukaan henkilöitä "varmuuden vuoksi". Tällöin tehtävät ja vastuualueet voivat projektin alussa jäädä epämääräisiksi ja henkilön rooli jää hyvin vähäiseksi.
Kehittämäni projektipeli on perinteinen, lautapelimaailmasta tuttu resurssienhallintapeli, jossa tarinana toimii tietojärjestelmän käyttöönottoprojekti. Pelin alussa pelaajat jaetaan asiakkaan ja toimittajan projektiryhmiin. Asiakkaan ja toimittajan projektipäälliköillä on erikseen omat roolinsa. Pelin tavoitteena on saattaa projekti valmiiksi tietyssä aikataulussa, tietyillä resursseilla. Pelissä projektiryhmät tekevät yhteistyötä ja molemmat projektiryhmät joko voittavat tai häviävät pelin yhdessä.
Olen pelannut projektipeliä asiakkaideni kanssa projektin alussa. Käytännössä tämä on joissain projekteissa korvannut projektisuunnitelman läpikäynnin. Näin toimittuna asiakas tutustuu projektin eri vaiheisiin ja pystyy etukäteen arvioimaan tehtäviään ja niihin kuluvaa aikaa. Pelin ohjaajana olen kertonut erityisen haastavista vaiheista ja niistä voidaan keskustella jo etukäteen. Toisaalta pelaaminen projektin aluksi tutustuttaa projektiryhmäläiset vapaamuotoisessa tilanteessa toisiinsa.
Olennaista on, että jokainen projektiryhmän jäsen voi pohtia omaa roolia ja vastuualueita projektissa. Vastuun ottaminen niin toimittajan kuin asiakkaankin puolelta on mielestäni yksi tärkeimmistä asioista, joka mahdollistaa onnistuneen projektin. Mikäli henkilö kokee, ettei hänellä ole järkevää roolia projektissa, tulisi projektiryhmäisten määrää rohkeasti supistaa. Muuten pahimmillaan voi käydä niin, että projektissa on mukana henkilö, joka projektipalaverista toiseen käyttää aikansa sähköpostien ja Facebookin selaamiseen.
Mikään it-projekti ei taida olla turvassa yllätyksiltä. Yllätyksiin varautuminen on projektipelissä huomioitu tapahtumakorttien avulla. Tällä tarkoitetaan sitä, että pelin tarinassa esiintyy ns. kriittisiä pisteitä, jossa pelaaja nostaa tapahtumakortin, jossa ongelma on esitetty. Ongelmaan ei ole yhtä oikeaa ratkaisua, vaan sopiva ratkaisu pyritään löytämään yhteisen keskustelun kautta. Tapahtumakortissa annetaan erilaisia ratkaisuvaihtoehtoja, mutta ne saattavat tarkoittaa esimerkiksi lisäresussien käyttöä tai aikataulun viivästymistä.
Lähteet ja lisämateriaalit:
Grönroos, C. 2009. Palvelujen johtaminen ja markkinointi.
Hyötyläinen, M. 2010. Towards “Service Factory” – Managing the Complexity of ICT Services.
Olen kehittänyt projektipelin alun perin osana YAMK-tasoista opinnäytetyötäni.
Helsingin yliopiston tutkija Mika Hyötyläinen on kirjoittanut, että ICT-palvelun käyttöönottopalvelu on sosiaalinen prosessi. Käytännössä siis teknologia ja innovaatiokeskeinen ajattelu eivät yksistään riitä teknisen järjestelmän käyttöönottoprosessin laadukkaaseen toteutukseen. Palvelu- ja asiakassuhdemarkkinoinnin professori Christian Grönroos mainitsee kirjassaan, että mikäli asiakas kokee palvelun aikaisen vuorovaikutuksen monimutkaisena, vaikeana tai epämiellyttävänä, saattaa lopputulokseltaan erinomaisen palvelupaketin koettu laatu jäädä heikoksi.
Tietojärjestelmän käyttöönotto vaatii paljon resursseja myös tilaajalta. Projektipäällikkönä olen useamman kerran kuullut kysyttävän, että miksi projekti vaatii asiakkaalta niin paljon työtä. Asiakashan maksaa projektista toimittajalle - eikö toimittajan tulisi tehdä kaikki työt?
Koko projektia on tuskin koskaan mahdollista ulkoistaa it-toimittajalle. Kuten Mika Hyötyläinenkin kirjoittaa, tarvitaan ICT-palvelun suunnittelussa paljon tietoa organisaation prosesseista. Tämä tieto on harvoin dokumentoitua ja se on hyvin kontekstiriippuvaista. Projektiin on löydettävä oikeat henkilöt ja tunnistettu tieto on perusteltava ja sovellettava ICT-palvelun tarpeisiin.
Olennaista onnistuneen käyttöönottoprojektin toteutuksessa on se, että asiakas tietää etukäteen, mitä tältä odotetaan. Yksi onnistuneen palvelukokemuksen avaimista on oikeanlaisen projektiryhmän muodostaminen. Jokaisen projektiryhmäläisen tulee tietää oma rooli ja vastuualueet projektissa. Projektiryhmäläisellä tulee myös olla työaikojensa puitteissa mahdollisuus ottaa se vastuu, jota häneltä odotetaan. Oma mutu-tuntumani on, että silloin tällöin projektiryhmään otetaan mukaan henkilöitä "varmuuden vuoksi". Tällöin tehtävät ja vastuualueet voivat projektin alussa jäädä epämääräisiksi ja henkilön rooli jää hyvin vähäiseksi.
Projektipeli tukemaan projektiryhmää
Projektin kulku ja projektiryhmäläisten tiedot käydään yleensä läpi projektin alkaessa ja nämä voidaan mainita myös projektisuunnitelmassa. Usein tämä vaihe saatetaan ohittaa liiankin nopeasti, eikä keskustelulle ole varattu riittävästi aikaa. Pahimmillaan projektiin valitut henkilöt ovat vääriä tai he eivät tiedä omaa rooliaan projektissa. Tällöin henkilöillä ei ole mahdollisuutta ottaa vastuuta projektin aikaisista tehtävistä. Omassa työssäni olen käyttänyt pelillistämisen menetelmiä tukemaan projektiin osallistuneita henkilöitä omien roolien ja vastuualueiden tunnistamisessa.Kehittämäni projektipeli on perinteinen, lautapelimaailmasta tuttu resurssienhallintapeli, jossa tarinana toimii tietojärjestelmän käyttöönottoprojekti. Pelin alussa pelaajat jaetaan asiakkaan ja toimittajan projektiryhmiin. Asiakkaan ja toimittajan projektipäälliköillä on erikseen omat roolinsa. Pelin tavoitteena on saattaa projekti valmiiksi tietyssä aikataulussa, tietyillä resursseilla. Pelissä projektiryhmät tekevät yhteistyötä ja molemmat projektiryhmät joko voittavat tai häviävät pelin yhdessä.
 |
| Projektipeli |
Olen pelannut projektipeliä asiakkaideni kanssa projektin alussa. Käytännössä tämä on joissain projekteissa korvannut projektisuunnitelman läpikäynnin. Näin toimittuna asiakas tutustuu projektin eri vaiheisiin ja pystyy etukäteen arvioimaan tehtäviään ja niihin kuluvaa aikaa. Pelin ohjaajana olen kertonut erityisen haastavista vaiheista ja niistä voidaan keskustella jo etukäteen. Toisaalta pelaaminen projektin aluksi tutustuttaa projektiryhmäläiset vapaamuotoisessa tilanteessa toisiinsa.
Olennaista on, että jokainen projektiryhmän jäsen voi pohtia omaa roolia ja vastuualueita projektissa. Vastuun ottaminen niin toimittajan kuin asiakkaankin puolelta on mielestäni yksi tärkeimmistä asioista, joka mahdollistaa onnistuneen projektin. Mikäli henkilö kokee, ettei hänellä ole järkevää roolia projektissa, tulisi projektiryhmäisten määrää rohkeasti supistaa. Muuten pahimmillaan voi käydä niin, että projektissa on mukana henkilö, joka projektipalaverista toiseen käyttää aikansa sähköpostien ja Facebookin selaamiseen.
Mikään it-projekti ei taida olla turvassa yllätyksiltä. Yllätyksiin varautuminen on projektipelissä huomioitu tapahtumakorttien avulla. Tällä tarkoitetaan sitä, että pelin tarinassa esiintyy ns. kriittisiä pisteitä, jossa pelaaja nostaa tapahtumakortin, jossa ongelma on esitetty. Ongelmaan ei ole yhtä oikeaa ratkaisua, vaan sopiva ratkaisu pyritään löytämään yhteisen keskustelun kautta. Tapahtumakortissa annetaan erilaisia ratkaisuvaihtoehtoja, mutta ne saattavat tarkoittaa esimerkiksi lisäresussien käyttöä tai aikataulun viivästymistä.
Lähteet ja lisämateriaalit:
Grönroos, C. 2009. Palvelujen johtaminen ja markkinointi.
Hyötyläinen, M. 2010. Towards “Service Factory” – Managing the Complexity of ICT Services.
Olen kehittänyt projektipelin alun perin osana YAMK-tasoista opinnäytetyötäni.
Kommentit
Lähetä kommentti