Mistä on hyvä palvelukonsepti tehty?

Otsikossa asetettuun kysymykseen vastatakseen pitää ensin selvittää mitä tarkoitetaan termillä ”palvelukonsepti”. Internetistä hakemalla löytyy kyllä paljon erillaisia osumia, joissa aihetta on kuvattu monelta eri kantilta. Mutta yritänpä silti itse:

Palvelukonsepti kuvaa palvelutehtaan eli palvelutuottajan tarjoamat palvelut ja niiden ominaisuudet sekä niitä tuottavan palvelujärjestelmän, sisältäen toimintamallit, prosessit, ihmiset, työkalut ja teknologian.

Huh, tulipa siitä jargonia… Kokeillaan toista lähestymistapaa:

Palvelukonsepti määrittelee tarjoamamme palvelut ja niiden ominaisuudet sekä miten niitä myydään, toimitetaan, tuotetaan ja käytetään.

Hmmm…. parempi! Piirretäänpä vielä kuva:

Luetaan kuvaa epälänsimaalaisesti oikealta vasemmalle. Selvää on, että tarkoitus on tarjota palveluita asiakkaille ja palvelun käyttäjille. Pitänee myös miettiä palveluiden sisältöä,  ja miksi ne ovat asiakkaan näkökulmasta parempia ja kilpailukykyisempiä kuin vaihtoehtoiset palvelut, kuten esimerkiksi kilpailijan tarjoamat palvelut. Olennaista on myös ymmärtää palveluiden mittakaava ja suhde toisiinsa, palvelut kun voivat sisältää toisia palveluita tai olla riippuvaisia toisistaan.

Esimerkiksi:

Jos halutaan määritellä tukipyyntöjen käsittelypalvelu tyyliin ”Asiakas voi soittaa palvelupisteeseen saadakseen tukea palveluiden käyttöön liittyen”. Kyseessä on siis palvelu, jonka toimitus alkaa siitä kun asiakas ottaa yhteyttä palveluntarjoajan tukeen ja päättyy siihen kun pulma on ratkaistu ja muuten suljettu. Mutta entä jos puhutaan laajemmasta palvelusta, esim. ”ICT ylläpito ja tuki”, joka sisältää edellä mainitun tukipyyntöjen käsittelypalvelun, mutta myös kymmeniä muita palveluita, joista osa on kertasuoritteisia, osa jatkuvia palveluita, kuten esimerkiksi palvelinten ylläpito ja varmistukset. Peli muuttuukin välittömästi toisenlaiseksi. Vaatimukset jälkimmäisen palvelun tapauksessa ovat huomattavasti kovempia palvelutehtaan kannalta.

Palveluiden tuottamiseen ja toimittamiseen tarvitaan ihmisiä joilla on oikeanlaiset tiedot ja taidot toimia erilaisissa tehtävissä. Tehtävät taas määräytyy prosessien ja toimintamallien myötä… Samat ihmiset myös suunnittelevat ja kehittävät prosesseja. Tästä muodostuu yhteinen toimintakulttuuri, mutta ei mennä tällä kertaa siihen keskusteluun.

Sitten tarvitaan myös erilaisia työkaluja ja teknisiä vempeleitä, teknologiaa, että saadaan palvelut toimitettua, laskutettua asiakkailta, raportoitua (tylsää mutta kai sekin pitää jotenkin hoitaa) ja niin edelleen. Edellä mainittuja toimia mahdollistavat tietojärjestelmät käsittelevät tietoa, jota ihmiset ja prosessit tuottavat, eli on hyvä miettiä tiedonhallinnan käytäntöjä ja tietomalleja, jotta arvokas tieto on hyödynnettävässä muodossa joka mahdollistaa esim asiakkaalta laskuttamisen.

Ihmiset tarvitsevat tilat, jossa työskennellä ja tuottaa/tarjota palveluita. Myös teknologialle tarvitaan tilaa joko omasta konesalista tai pilvestä. Toisaalta teknologian avulla voidaan luoda virtuaalisia tiloja, missä ihmiset voivat työskennellä – esimerkiksi itsepalveluportaali ja sen chat -toiminnallisuus.

Palvelutehtaan väki on ihan hukassa kun ei tiedetä että yritetäänkö viljellä uusia perunoita lapissa keskellä talvea ja toimittaa niitä Kreikan markkinoille koirarekikuljetuksina – tai jotain muuta

Sitten on tietysti vielä tuo kuvan vasen laita… Ihan kaikkea ei kannata itse tehdä, joten kumppaneilta voidaan hankkia tuotteita ja palveluita joko täydentämään omaa tarjoomaa tai ihan ydinominaisuuksia tuomaan. Tästä voitaisiinkin kirjoittaa ihan oma postaus joku päivä, erilaisista palvelutyypeistä  ja minkälaisen härdellin ne muodostaa. Note to self!

Lisäyksenä vielä, että sopimukset ja palvelulupausasiat pitää olla kunnossa ja sovittuna kumppanien kanssa, ja sama juttu asiakkaiden ja palvelutehtaan välillä myös.

Ylhäältä unohtui tuo yksi laatikko… Aina kun näen ”strategia” –sanan, alkaa huimata. Voi helvetti, toivottavasti mun ei tarvitse lausua sitä ainakaan englanniksi! Vakavasti puhuttuna ”SträzegZi” on kyllä tärkeä juttu. Muutenhan palvelutehtaan väki on ihan hukassa kun ei tiedetä että yritetäänkö viljellä uusia perunoita lapissa keskellä talvea ja toimittaa niitä Kreikan markkinoille koirarekikuljetuksina – tai jotain muuta.

No niin, siinähän se olisi kuvattuna, palvelukonseptikonsepti. Mutta vähän huolestuttaa, kun tämä muistuttaa aika paljon palveluarkkitehtuurin määrittelyä! Voisiko ajatella niin, että palvelukonseptointi on laajempi ja karkeampi linjauksia määrittelevä prosessi ja arkkitehtuurityö sitten tarkentaa suunnitelmia ja johtaa toteutusta palvelunkonseptoinnin määrittelyjen mukaisesti?

Taas lipsahti konsulttijargonia. Yritetään selittää kuvalla:

Tämä tässä on meidän palvelumuotoilun kehitysmalli. Luvataan nyt, että tästäkin voidaan kirjoittaa jossain vaiheessa tarkemmin, mutta keskitytään nyt tuohon rajattuun alueeseen kuvassa:

Kun on idea(t) olemassa, konseptointi piirtää, kuvaa ja  visualisoi tarkemman kuvauksen palvelukonseptista sisältäen palvelukuvaukset ja palvelujärjestelmän, jolla ideoiden mukaisia palveluita aiotaan tuottaa.

Hyvä konsepti on kuvattu niin, että apinakin tajuaa mistä hommassa on kyse ja miten palvelujärjestelmä toimii.

Ei sillä, että pitäisin palveluekosysteemeissä työskenteleviä ihmisiä apinoina! Ymmärrettävä kuvaus auttaa palvelukonseptin  läpikäynnissä ja testauksessa eri sidosryhmien kanssa.

Kun konsepti on riittävän pitkälle sovittuna voidaan aloittaa varsinaisen palvelumallin miettiminen. Tämä vaihe onkin sitten jo ihan palveluarkkitehdin heiniä. Tässä vaiheessa on lupa piirtää UML kuvia ja määritellä prosesseja sekä puhua KPI:stä ja muista kivoista lyhenteistä. Kunhan tulee riittävän tarkat suunnitelmat tehtyä tulevan käyttöönoton tueksi ja pohjaksi.

Eräs kollega oikeutetusti huomautti, että kyseessä ei ole vesiputousmalli, vaikka ympyrä saattaa tällaisen kuvan antaakin. Konseptia voidaan siis tuunata vielä palvelumallin suunnitteluvaiheessakin ja sama toisin päin.

Lopuksi voi osalla lukijoista nousta mieleen kysymys, että milloin tai missä tilanteissa tälläistä konseptointia voisi käyttää?

Esimerkiksi seuraaviin:

• Konsepti- ja tarvekuvaukset erillaisten tarjouspyyntöjen yhteyteen
• Tavoitetilan määrittely ja kirkastaminen esimerkiksi uuden palvelun lanseerauksen yhteydessä
• Uusien prosessien määrittely tai olemassa olevien prosessien parantaminen
• Olemassa olevan prosessin kuvaaminen esimerkiksi kommunikointitarkoituksiin

Eli jos on vaikka kilpailutuskierros lähdössä käyntiin ja haluaa varmistaa, että ulkoistuskumppanikandidaatit ymmärtävät mitä halutaan ostaa, niin tässähän on oiva tapa varmistaa sujuva kommunikointi ja tavoitteiden määrittely. Saatte toki kirjoittaa sen 567 rivisen vaatimusexcelin myös (pisteytyksineen), mutta hyvä palvelukonsepti kertoo enemmän kuin 10 000 vaatimusriviä excelissä.

Haluatko tietää lisää?

Tutustu Digitaalisen palvelukatalogin suunnittelu -koulutukseemme ja lue alta aiheeseen liittyviä muita kirjoituksiamme.

Julkaistu 04.09.2015