Palvelujen määrittely

Yksi vai kahdeksan katalogia

Kesäloman jälkeen olen törmännyt takaisin palvelujen määrittelyn vaikeuteen, joka nousi esiin 17.5. julkaisemassani Haasteet-raportissa (löytyy tuolta alempaa). Mark O’Loughlin on julkaissut kirjan, jossa hän esittää kahdeksan erityyppistä palvelukatalogia ja Rob England perustelee monisanaisesti miten on olemassa vain yksi palvelukatalogi ja että business ja tekniset katalogit ovat vain eri näkymiä siihen. Kumpikaan malli ei ole kovin yksinkertainen, koska O’Loughlin kuvaa jopa palveluportfoliopyramidin ja England sanoo että palvelut voivat olla fraktaalisia siten, että palvelulla on useita tuottajia, joilla jokaisella on oma palvelukataloginsa. Molemmat käyttävät itiliä viitekehyksenä, joten viitekehys ei ole kovin selkeä, kun sitä tulkitaan näin eri tavoin.

Yksi asia tässä ainakin on varmaa, konsultti saa paljon töitä jos onnistuu myymään O’Loughlinin palveluportfoliopyramidin asiakkaalleen. Siinä tarvitaan paljon kalliita konsulttipäiviä, ennen kuin pyramidit ovat pystyssä. Pelkään kyllä että businessasiakkaiden kiinnostus lopahtaa nopeasti ja pyramidin rakentelu jää it-yksikön sisäiseksi puuhasteluksi.

Usein esiintyvä hämmennys on sekoittaa tilattavien palvelujen tai ominaisuuksien luettelo palvelukatalogiin. Toki näiden asioiden nimet ovat samat mutta merkitys on eri. It-yksikön tarjoama ”verkkokauppa” on yksi palvelu, josta voi tilata joitakin palvelutapahtumia, kuten salasanan vaihdon, uuden työaseman jne. Nämä tilattavat palvelut eivät kuitenkaan yleensä muodosta kokonaista palvelukatalogia tai edes merkittävää osaa siitä. Palvelukatalogin tehtävä on kuvata sitä kokonaisuutta, jota it-yksikkö tekee asiakkaiden hyödyksi.

Palvelun rajapinta on usein selkeämpi, kun on kyseessä ulkoinen palvelutuottaja verrattuna sisäiseen it-yksikköön. Nämä ovat hyvin erilaisia tilanteita ja on varsin outoa että itil ei tee selvää eroa niiden kanssa. Itilin kakkosversio oli tarkoitettu sisäisille palveluntuottajille, mutta kolmosversio ei tee selvää eroa kummasta tilanteesta se puhuu.

Ongelmana on se, että palvelujen täsmällinen määrittely voi olla vaikea tehdä niin, että se olisi käyttökelpoinen sekä asiakkaalle että palvelun tuottajalle. Tyypillinen keskustelu voi mennä näin:

–       Olette kuvanneet palvelunne olevan: Tietoliikennepalvelu, Palvelinpalvelu ja Työasemapalvelu. Nämä eivät ole asiakkaan näkökulmasta helposti tunnistettavia palveluja, asiakkaat puhuvat yleensä sovelluksista palveluina.

–       Niin, mutta meillä on 150 sovellusta emmekä me vastaa kaikista niistä, asiakkaat sopivat usein muutoksista suoraan sovelluksen toimittajan kanssa.

Helppo ratkaisu on tehdä erillinen tekninen katalogi omaan käyttöön ja toinen katalogi sitten asiakkaita varten. Epäilen että helppo ratkaisu ei juurikaan hyödytä ketään ja siinä mielessä England on oikeassa. Vaarana on, että it-yksikkö keskittyy itse määrittelemiensä palvelujen tuottamiseen. Tässä tapauksessa palvelut toimivat, SLAt täyttyvät mutta asiakkaat ovat tyytymättömiä.

Palvelu- vai asiakaslähtöisyys

Palvelun elinkaarimalli nostaa palvelulähtöisyyden it-palvelunhallinnan keskelle. Kaikki pyörii palvelujen ympärillä. Palveluportfolio kertoo lisäksi mitä palvelut ovat poistumassa ja mitä uusia palveluja on suunnitteilla. Jotenkin tuo elinkaarimalli tuo mieleen neuvostoaikaiset viisivuotissuunnitelmat. It-Kreml suunnittelee tulevaisuuden, mutta liiketoiminta vain ei tottele.

Palvelulähtöisyys ei ole sinänsä huono asia. Mielestäni Fujitsun Patja on hyvä esimerkki kehittyneestä palvelulähtöisyydestä. Kysymys on siitä sopiiko Patjan tyyppinen standardoitu palvelu kaikille ja kaikkiin tilanteisiin. Kauniisti sanottuna Patja edellyttää kypsyyttä myös asiakkaalta. Standardoitu palvelu ei voi olla kovin yksilöllistä.

Asiakaslähtöisyys on jossain mielessä palvelulähtöisyyden vaihtoehto. Aito asiakaslähtöisyys sovittaa tekemisen asiakkaan tarpeiden mukaan. Standardoituja palveluja ei ole vaan eri asiakkaat saavat yksilöllistä palvelua. Yksilöllinen palvelu on selvästi kalliimpaa kuin standardoitu palvelu.

McDonalds tarjoaa selkeän valikoiman palvelutuotteita, tiedät mitä saat kun tilaat jonkin aterian tai yksittäisen tuotteen. Kotiruoka taas on sitä mitä tekijä on päättänyt tehdä. Perheenäiti (tai huoltaja) voi noudattaa reseptejä tai tehdä ruuan omasta päästään. Toiveita ehkä kuunnellaan, mutta tilauksia tuskin otetaan vastaan. Lasten kannalta kotiruoka on varmasti terveellisempi vaihtoehto. Joissakin tapauksissa it-yksikön palvelu voi muistuttaa tuota kotiruokaa. Malli toimii hyvin jos it-yksikkö ymmärtää hyvin organisaation tavoitteet ja työskentelee niiden eteen. Se toimii huonosti, jos it-ihmiset tekevät asiat oman päänsä mukaan eivätkä kykene reagoimaan asiakkaiden tarpeisiin.

On tavallista että it-yksikkö haluaisi määritellä palvelut ja ottaa käyttöön selkeät sopimukset, mutta asiakas on haluton siihen. Kannattaako sitten palvelujen määrittelyyn käyttää aikaa ja vaivaa?

Vaihtoehtoinen malli

Mitkä sitten ovat ”parhaat käytännöt” jos palveluportfolio unohdetaan?  Siinä tapauksessa lähtökohtana pitää olla asiakas ja tämä tarkoittaa sitä, että asiakkaita pitää olla hallittavissa oleva määrä. Jokaisen asiakassopimuksen pitää määritellä tietysti toiminnan tavoitteet ja varmasti joitakin mittareita palvelulle. Ero tulee lähinnä siitä, että palvelun kuvaaminen ja siitä sopiminen voi olla helpompaa, kun ei tarvitse luoda monia palvelukuvauksia omine mittareineen.

Asiakaslähtöisessä mallissa voidaan palveluluettelo jättää vähemmälle huomiolle. Palveluja ei ole standardoitu vaan jokaisella asiakkaalla on omat palvelut. Palvelusopimukset ja palvelutasonhallinta ovat toki mahdollinen keino hallita palvelun laatua. On myös mahdollista että jotkin osat palvelua on standardoitu ja voidaan kuvata.

Pitkälle viedyn asiakaslähtöisyyden ongelma on sen tehottomuus it:n näkökulmasta. Liiketoiminnan muutokset näkyvät suoraan it-palveluissa. It-palvelut muuttuvat kaiken aikaa ja niiden tehostaminen on vaikeaa. Tämä ei ole välttämättä mikään merkittävä haitta, jos liiketoiminta tehostuu.

%d bloggers like this: