Palveluiden digitalisointi on jo pitkään ollut niin otsikoissa kuin kehittämisen kohteena. Olemme hiljalleen alkaneet ymmärtää palvelua tuotteen muodossa. Palvelussa on kosolti tuotetta, kun palvelu on tarjolla omatoimisuutta lisäävänä sovelluksena. Sovellukset pyrkivät vähentämään kasvokkaista palvelua ja etäännyttävät niin palvelun ammattilaiset kuin palvelun asiakkaat toisistaan. Osaamista digitalisoidaan. Näin on tehty käytännössä siitä alkaen, kun automaattisia tietojärjestelmiä, isoja tietomassoja käsitteleviä systeemejä on alettu rakentaa. Verkossa on paljon palveluita, verkkopankki ja -kauppa hyvinä esimerkkeinä. IoT-ratkaisut tunnistavat entistä tehokkaammin ostokäyttäytymistämme ja tarjoavat asiakkuuden hankkineelle toimituslupauksia ja tarjouksia. Viime kädessä on kyse arvon tuottamisesta palveluketjun eri osapuolille ja näkökulman skaalautuvuudesta.

Istuimme keskustelemaan vuosikymmenten kokemuksistamme tietojärjestelmätyöstä ja sen opettamisesta. Voisiko eletty historia auttaa ymmärtämään nykykehitystä? Tänään on historiaa huomenna!

Anne: Olen jonkin aikaa pohtinut, mitä meillä oli ennen palvelumuotoilua. Tiedän. Meillä oli selvitys- ja vaatimusmääritystyötä. Kuin taannoinen mainos, missä lapsi kysyi äidiltään: ”Mitäs me pantiin leivälle ennen Flooraa?”, juolahti mieleeni metaforana ihra, voi, kevytlevite ja öljy! Eli isot legacy-järjestelmät, verkkokauppapaikat, mobiilisovellukset ja IoT:t. Onko kyse tunnettujen ja tuttujen menetelmien ja käytäntöjen uudelleen nimeämisestä, mittakaavamuunnoksesta vai näkökulmasta?

Eija: Ennen tosiaan käytettiin paljon aikaa keskustelemalla asiakkaan kanssa, haastateltiin ja havainnoitiin, jäsennettiin tarpeita, priorisoitiin niitä ja hylättiin joitakin. Joskus päästiin kuulemaan asiakkaan asiakkaankin ajatuksia oman toimintansa tai kokemuksensa parantamishaaveista. Opettelimme ymmärtämään eri toimialojen kieliä ja liiketoimintatarpeita – ja rakentamaan niitä tukevia ja palvelevia toimivia tietojärjestelmiä.

Keskustelun lomassa simuloimme tilannetta, jossa kaupan ovesta astuu sisään asiakas, joko uteliaisuuttaan tai ostoaikeissa. Mitä kaupan palvelua hän silloin hakee?

Eija: Voimme tarkastella tilannetta kauppiaan näkökulmasta. Hän tarvitsee liiketoimintaansa ja palveluaan tukevaa sovellusta tai tietojärjestelmää. Lisäksi voimme suunnitella hänen kanssaan vaikka laajennetun todellisuuden sovelluksia, jotka syventäisivät asiakkaan palvelukokemusta. Voimme tarkastella tilannetta myös asiakkaan näkökulmasta. Hänellä voisi olla mukanaan kapula tai kanta-asiakaskortti, josta hylly tunnistaisi hänet ja tarjoaisi hänen asiakasprofiilinsa mukaisia tuotteita tai edullisia kampanjatuotteita. Hyllyssähän voisi olla jokin IoT-sovelluksen RFID-tunniste. Niitä tulee kirjastoihinkin niin, että kirjojen palautus helpottuu, kun kirjan viivakoodia ei enää tarvitse asetella lukijan alle vaan palautuva teos tunnistetaan RFID:n avulla metrin säteellä.

Anne: Tavaraa, tuotetta, voi kohdella noin. Entä ihmisiä? Ihmisillä on niin erilaisia tarpeita. Mistä kaupan asiakas saa lohtua, mielihyvää, arvon tunteen tai kokemuksen. Sen pitäisi kiinnostaa palvelun kehittäjää ja kehittämisen maksajaakin.

Eija: Hyvä kysymys. Mistä tiedämme, mitä tarpeita kauppaan tulevalla ihmisellä on? Haluaako hän vain katsella vai etsiikö hän jotain tiettyä tuotetta? Haluaako hän tietyn merkkisen tuotteen, tarttuuko kampanjatuotteeseen tai onko hän kiinnostunut tuotteen ekologisista arvoista? Vai haluaako hän vain itselleen sopivan ja sellaisenaan toimivan tuotteen?

Anne: On selvitettävä ensin: Mikä on todellinen tarve? Turhaa työtä olisi tehdä sovellus, joka reagoisi kanta-asiakkuuteen jonkin sensorin ja tunnisteen avulla. Olisi se kai palvelu, mutta onko se sitä kaupan asiakkaalle? Kaikille asiakkaille?

Olimme samaa mieltä siitä, että asiakkaiden käyttäytymistä on havainnoitava, tutkittava myyntitilastoja ja asiakasprofiileja, haastateltava kaupan asiakkaita ja asiakaspalvelijoita. Mitä kauppa tavoittelee? Haluaako se myydä kampanjatuotteita vai heräteostoksia? Onko kaupassa asiakaspalvelua vai toimiiko kaikki sensoreilla itsepalveluna? Mikä on kaupan imago? Lienee ihanteellista ajatella, että molemmilla osapuolilla on sama tavoite. Arvon tuottaminen on molemmille tärkeää. Kaupan tai kauppiaan imagolle on eduksi, että kaupan, kauppiaan ja asiakkaiden etu saavutetaan.

Eija: Viime vuosituhannen lopulla pankkipalvelut muuttuivat niin, että valtaosa “bulkki”-palveluista muutettiin itsepalveluksi ja tietyille asiakkaille tarjottiin sitten asiantuntijoiden tarjoamia  sijoituspalveluita.

Anne: Pitää siis ymmärtää, että verkkoon on siirretty sellainen palvelu, josta asiakas selviää itsekseen. Mutta mikä ero asiakkaalle on verkkokauppapaikalla ja IoT-hyllyllä?

Eija: IoT-hyllystä asiakas saa haluamansa tuotteen heti, voi tunnustella tai sovittaa sitä. Toisaalta voi olla, ettei IoT-hyllystä juuri sillä hetkellä löydy hänelle sopivaa tuotetta.

Anne: Eli palvelu voidaan nähdä aikatilana: heti, paikan päällä tai postitse, ehkä palautettuna ja uutta odottaen. Palataan alkuun: Onko nyt kyse palvelumuotoilusta vai vaatimusten asettamisesta palvelulle?

Eija: Mitä on palvelumuotoilu? Viime vuosituhannella olisimme selvitysvaiheessa haastatelleet asiakaspalvelijoita ja heidän esimiehiään, antaneet heidän kertoa yrityksensä visiosta ja missiosta, yrityksen imagosta, nykytilan ongelmista ja tavoitetilasta. Sitten olisimme yhdessä ideoineet ja selvittäneet, miten nykyisestä tilanteesta päästäisiin tavoiteltuun.

Vaatimusten määrittelyn roolit (JHS 165 ICT-palvelujen kehittäminen: Vaatimusmäärittely)

Anne: Palvelun yhtenä osapuolena on palvelua hakeva asiakas. Hänetkin pitää huomioida. Käyttäjälähtöisyyttä ja osallistavaa suunnittelua tarvitaan.

Eija: Selvitysvaiheessa asiakaspalvelijat kokoontuivat yhteen simuloimaan asiakkaan käyttäytymistä ja sen eri vaihtoehtoja: käyttötapauksia ja -tilanteita.

Anne: Eikö tuossa ollut riskinä, että kauppa mallinsi oman ajattelunsa asiakkaan käyttäytymisestä erilaisissa käyttötilanteissa, joihin kauppa oli valmis?

Eija: Toki simuloinnissa otettiin huomioon kaikki se tieto, mitä asiakaspalvelijat olivat asiakkaista saaneet. Parhaimmillaan simulointiin meni koko päivä, kun yhdessä pohdittiin eri vaihtoehtoja. Ulkopuolinen konsultti tai järjestelmäsuunnittelija yleensä esitti “tyhmiä kysymyksiä”, jotka herättivät asiakaspalvelijat miettimään erilaisia vaihtoehtoja. Parhaimmillaan – kun silloin joskus oli aikaa – tästä seurasi ideamyrsky, valtava määrä uusia ideoita, joista vain pieni osa pääsi jatkoon. Parhaat. Niin, kenen mielestä? Ensin simulointiin osallistuneet karsivat ideoita, sitten projektin johtoryhmä, jossa oli edustajia yrityksen eri sektoreilta, asiakaspalvelusta, tuotekehittelystä, markkinoinnista ja taloushallinnosta.

Anne: Kuulostaa ison organisaation ison kehittämistyön toimintatavalta. Onkohan syytä skaalata vähän alaspäin? Asiakkaan tarve mennä kauppaan ostoksille oli tässä esimerkissämme ydinkysymys, jossa palvelun erilaisia puolia ja sen mukaisesti palvelun laatua olisi tarpeen tarkastella. Toki, ennen tietojärjestelmät olivat isoja, ja niillä oli useita käyttäjiä, ehkä suljetuissa ympäristöissäkin. Nyt meillä on verkko ja kaikkialle ulottuva mobiilimaailma. Kilpailu on kovaa ja asiakkaista kiinni pitäminen entistä haastavampaa. Asiakas vaihtaa nopeasti palvelusta toiseen, etujen ja mieltymysten mukaan. Onko nopeasyklisempi kehittämisen muoto vallalla? Onko mallinnustyö menettänyt otettaan?

Eija: Kyllähän tietojärjestelmien kehittämisessä, pienten tai isojen, pitäisi ottaa huomioon kaikki nuo eri tahot, vaikka niistä kaikista vastaisikin yrittäjä yksin. Pitäähän hänenkin miettiä, miten tuotetta tai palvelua kehitetään ja markkinoidaan ja millaista palvelua asiakas saa ja miten raha kulkee. Mallinnusta tarvitaan aina. Vaikka järjestelmiä tehtäisiin kuinka ketterästi, pitää olla jokin kokonaiskuva siitä, mitä ollaan tekemässä ja mihin tarpeeseen. Sen jälkeen yksityiskohtia voidaan hioa protoilemalla ja iteroimalla.

Anne: Meillä on siis edelleen tarve kotiläksynsä tehneille speksaajille ja skouppaajille, jotka uskaltavat kohdata eri osapuolet ja perehtyä todellisiin arvoa tuottaviin tarpeisiin. Edelleen on osattava haastatella, kartuttaa tarpeita, jäsentää niitä ja asettaa tärkeysjärjestykseen, karsia ja tehdä päätöksiä, laatia kuvauksia, mockuppeja, demoja ja prototyyppejä, muotteja tai käsin kosketeltavaa muotoa. Yhä on osattava kuvata sovittuja asioita ja selostaa laaditut kuvaukset yksiselitteisesti niitä tarvitseville ja jatkokehittämisestä vastaaville. Siitäkin huolimatta, että joku tahtoo vain MVP:n (minimum viable product).

Eija: Kyllä. Tietojärjestelmien kehittäminen on vuorovaikutusta, kuuntelemista, kysymistä, yhteisen kielen, käsitteiden ja ymmärryksen löytämistä.

Onko palvelumuotoilu jotain muuta?


Anne Valsta on aloittanut uransa Tilastokeskuksessa isojen järjestelmien ja tietovarastojen parissa, opettanut 30 vuotta ohjelmistokehityksen ja projektinjohtamisen menetelmiä, parhaita käytäntöjä, niin ATK-instituutissa kuin Haaga-Helia ammattikorkeakoulussa.

Eija Kalliala on ollut mukana kehittämässä vakuutusalan tietojärjestelmiä kymmenen vuotta ja opettanut tietojärjestelmien kehittämistä ammattikorkeakoulussa lähes 20 vuotta. Hän on osallistunut useiden tietojärjestelmäalan Sytyke-raporttien kirjoittamiseen ja toiminut Sytyke-lehden päätoimittajana 2013–2015.