Lue lisää: |
Matti Grönroos
Palvelupyyntöjen tuotteistaminen
ITIL määrittää käsitteen standardipalvelupyyntö, joka on valmiiksi tuotteistettu palvelupyyntö, joka usein voidaan hoitaa nopeasti. Nopeus ei tarkoita kontrollin ulkopuolelle jäämistä: myös standardipyyntöihin voidaan liittää hyväksyntävaatimus.
Organisaatiot eivät aina ole kovin innokkaita palvelupyyntöjensä tuotteistamiseen, mikä on verraten lyhytnäköistä.
Palvelupyyntöjen standardoinnilla pyritään sekä palvelemaan käyttäjiä paremmin että luomaan parempi näkyvyys siihen kaikkeen, mitä IT:ltä halutaan. Usein lähtötilanne on varsin heikko, mutta tuotteistamistyöllä on taipumus palkita itsensä.
Palvelupyyntöjen tuotteistaminen kohti standardipyyntöjen suurempaa osuutta
Palvelupyyntö voi olla periaatteessa mitä tahansa, salasanan vaihtopyynnöstä uuden tietokoneen tilaamiseen. On aivan organisaatiosta itsestään kiinni, mitä se haluaa tuottaa nopeasti saataville ja missä asioissa sitten noudatetaan jäykempiä menettelytapoja.
Standardipalvelupyyntöihin usein liitetään seuraavanlaisia attribuutteja:
- Kiinteän hinnaston mukainen veloitus (tai ei veloitusta)
- Palvelutasolupaus
- Palvelukuvaus
- Mahdollisesti palvelupyyntö tilauslomakkeella
- Hyväksyntämenettely, jos merkittäviä kustannusvaikutuksia
- Toistettavuus
Tuotteistuksessa kannattaa suosia käyttäjän ymmärtämää kieltä: Kerrotaan mitä palvelulla saa, nimetään ne ymmärrettävästi, vältetään teknojargonia, ei nosteta oleellisena esiin, miten palvelut tuotetaan, fokusoidaan tuotoksiin ja hyötyihin. Oleellista on piilottaa monimutkaisuus: Ei käyttäjä useinkaan tiedä, mikä on häiriö, mikä on muutos, mikä on palvelupyyntö. Ei kurmooteta käyttäjää vain siksi, että hän on esittänyt pyynnön väärin.
Koska kyseessä ei ole asia, joka pitää saada kuntoon yhdellä rysäyksellä, on hyvä olla ketterä ja syödä elefantti kuin se pitää syödä: pala kerrallaan. Lähdetään pienestä, mutta tavoitellaan suurta. Tuodaan uutta markkinoille parin-kolmen kuukauden välein ja lyödään välillä markkinointirumpua. Varaudutaan muutoksiin ja hienosäätöön, jos ei kerralla osu kohdalleen. Samalla suljetaan ei-toivotut kanavat ja ohjataan käyttäjiä ystävällisesti kohti tilauslomakkeita tai muita kanavia.
Kaiken kaikkiaan käyttäjistä ei kannata tehdä integraattoreita, vaan tuotetaan palveluita niin isoina kokonaisuuksina kuin on järkevää.
Tuotantokustannuksista kannattaa olla hajulla. Jos et ole, miten tiedät, tuotatko kannattavia ja oikein hinnoiteltuja palveluita?
Pitkäkestoisissa toimituksissa on hyvä luoda toiminto, jolla asiakas näkee, missä mennään. Pelkkä tilaustiketin statuskenttä "In Progress" ei tuota mitään arvoa: Ikään kuin asiakas ei sitä muutenkin tietäisi. Muutenkin automaatiota kannattaa suosia, jos siihen on business case. Jos pohditaan palvelupyyntöjen toteuttamista kokonaan tai osittain offshoresta, business casea on syytä arvioida syvemmin: Offshore saattaa olla halvempi, mutta nopeus ja tasalaatuisuus syntyvät automaation kautta.