Palvelukatalogin tarkoitus on palvella liiketoimintayksiköitä kuvaamalla IT:n tarjoamat palvelut. Katalogiin lisätyt palvelut on kyettävä perustelemaan sekä toiminnallisuuden että kustannustehokkuuden näkökulmasta. Palvelut on myös kuvattava loppukäyttäjille tavalla, joka on selkeä ja helposti ymmärrettävissä.
Jotta tämä olisi mahdollista, palvelut mallinnetaan useammassa kerroksessa, joista loppukäyttäjille näytetään vain yksinkertaistettu näkymä.
Alla kuvassa 10 on esitetty (Sauve et al., 2006) tulkinta palvelukatalogin mallintamisesta. Teknisessä osassa (IT Services Layer) kuvataan kaikki taustalla oleva infrastruktuuri, kuten palvelimet, reitittimet, kytkimet, ohjelmistot, tietokannat jne., joiden varassa palvelut pyörivät ja jotka vikaantuessaan aiheuttavat palvelujen häiriintymisen. Käyttäjä pääsee käyttämään määritettyjä palveluja liiketoimintaprosesseja kuvaavan käyttöliittymän kautta (BP Layer).
Käyttäjä ei ole kiinnostunut kaikesta siitä, mitä taustalla pyörii – hän vain yksinkertaisesti käyttää palveluita.
Kuva 10 Palvelukatalogin mallintaminen (Sauve et al., 2006).
Business Layer ilmentää sitä osuutta, jossa liiketoiminnan palvelut mallinnetaan ja niihin linkitetään erilaisia mittareita, kuten kustannuslaskennan analyyseja tai Balance Scorecardin pohjalle rakennettua raportointia. Business Layer -mallintaminen auttaa pureutumaan palvelujen ytimeen ja laskemaan joko taloudellista hyötyä tai menetystä liiketoiminnalle. (Sauve et al., 2006).
ITIL-kirjallisuus kuvaa palvelukatalogin hieman eri tavalla, mutta ajatus on molemmissa sama. Alla kuvassa 11. on esitetty ITILin versio vastaavan katalogin mallintamisesta. Alimmaisella rivillä kuvassa on Sauven (2006) mallia vastaava IT Service Layer, joka muodostaa teknisen rajapinnan eri palveluihin. Palvelut näytetään käyttäjille palvelukatalogin (Business Service Catalogue) kautta ja ne linkitetään liiketoiminnan käyttämiin prosesseihin, joita mitataan ja joista raportoidaan liiketoiminnalle päin. Mallintamisen tarkoituksena on tuoda eri sidosryhmille näkyviin vain se osa palveluista, josta he ovat kiinnostuneet oman toimenkuvansa kannalta.
Kuva 11. Liiketoiminnan palvelukatalogi ja tekninen palvelukatalogi (OGC. 2007b.) Mendesin et al. (2010) mukaan palvelukatalogin rakentamisen jälkeen yritykset ovat saavuttaneet selkeitä kustannushyötyjä mm. automatisoimalla prosesseja, lisäämällä kustannusten läpinäkyvyyttä, yhtenäistämällä palveluja ja käytettyjä toimitusmalleja sekä nopeuttamalla palveluiden palauttamista. Myös asiakastyytyväisyys on parantunut. Käyttäjien osalta suuri tyytyväisyyttä lisännyt tekijä oli odotusarvojen parempi hallinta toimintojen lisääntyneen läpinäkyvyyden myötä. Selkeästi kuvatut prosessit helpottivat päivittäistä työskentelyä ja IT:n tarjoamat palvelut olivat kaikkien saatavilla ymmärrettävässä muodossa.
IT Palvelunhallintajärjestelmää implementoineille yrityksille tehdyssä tutkimuksessa vain 57 % kertoi projektin päässeen onnellisesti maaliin. 12 % vastasi, että projekti oli täysin epäonnistunut, ja jopa 34 % edellä mainitusta joukosta ilmoitti suurimmaksi riskiksi juuri onnistuneen palvelukatalogin määrittelemisen. (Cole, 2008). Vaikka ITIL ja useat muut viitekehykset kuvaavat kuinka palvelunhallintajärjestelmä toimii, on järjestelmien implementointi silti projektin vaativin vaihe ja toteutus aina erilainen. IT voi auttaa liiketoimintaa parhaiten hyödyntämällä hankittuja järjestelmiä mahdollisimman tehokkaasti ja tarjoamalla niiden avulla liiketoiminnalle mahdollisuuden seurata toimintoja tavalla, joka tukee päivittäisiä toimintoja. Reagointikykyyn vaikuttaa yrityksen IT-palvelujen kypsyysaste. Mitä kypsemmällä tasolla palvelut yrityksessä ovat, sitä paremmin se kykenee reagoimaan yllättäviin muutoksiin (Intacs.Info, 2014).
Ensimmäinen askel palvelukatalogin kuvaamisessa (Kuva 12) on määritellä ne palveluiden pää- ja alakategoriat, joita IT tarjoaa käyttäjille. Tässä vaiheessa ei ole syytä vielä määritellä itse palveluja, vaan ne tulisi tehdä yhdessä liiketoiminnan kanssa. Seuraavassa vaiheessa palveluiden sisällöstä keskustellaan liiketoiminnan eri yksiköiden kanssa ja määritellään tarkempi palvelun nimi ja kuvaus, mahdolliset aiemmat vastaavat palvelut, liiketoiminnan prosessit, joihin palvelu liittyy, sekä haluttu palvelutaso että mahdolliset kehitystarpeet.
Kuva 12. Palvelukatalogin rakentaminen. (Mendes, 2006).
Tämän jälkeen IT johdon tehtävänä on arvioida kykeneekö IT hoitamaan liiketoiminnan tarvitsemat palvelut nykyisten resurssien ja kyvykkyyksien turvin, minkälaisia sopimuksia toimittajien kanssa on tehty, minkälaisiin järjestelmiin palvelut ovat kytköksissä ja mikä on prosessien kypsyystaso. Suunnittelun seuraavassa vaiheessa verrataan liiketoiminnan tarpeita IT:n kykyyn tuottaa haluttuja palveluja ja dokumentoidaan toteutettavissa oleva palvelujen sisältö.
Suunnittelun viimeisessä vaiheessa tuotettu palvelukatalogi esitellään liiketoiminnalle. Tämän jälkeen tarpeellisin muutoksin hyväksytty palvelukatalogi voidaan siirtää tuotantoon. Palvelukatalogin kautta tuotetuille palveluille on aina merkittävä omistaja, jolla on oikeus hyväksyä palvelu tuotantoon tai ottaa se pois tuotannosta. Kaikki palveluun tehtävät muutokset on hyväksytettävä palvelun omistajalla. Liitteissä 2 & 3 on esitetty toiminnot, jotka palvelukatalogin rakentamisessa tulisi huomioida palvelujen elinkaaren aikana. (Mendes, 2008.) Mikäli edellisten vaiheiden mukaistaa analyysiä ei toteuteta yhdessä liiketoiminnan kanssa, on vaarana, että odotusarvo liiketoiminnan tarpeiden ja
Palvelukategoriat Liiketoiminnan tarpeet
IT Resurssit
Katalogin dokumentointi Katalogin hyväksyntä
tuotetun palvelutason välillä muodostuu liian suureksi. Palvelun laatu voidaan jakaa karkeasti kahteen eri osa-alueeseen jos mietitään palvelun toimitusta:
tekniseen ja toiminnalliseen laatuun (Mendes & Mira da Silva, 2011). Teknisellä laadulla tarkoitetaan tässä yhteydessä tuotetta/kokemusta, joka asiakkaalle jää toimituksen jälkeen. Toiminnallinen laatu puolestaan kuvaa tapaa, jolla palvelu toimitetaan asiakkaalle.
Alla kuvassa 13 on esitetty erilaisia ongelmakohtia asiakkaiden tyytyväisyydessä suhteessa palvelun laatuun. Mallia käytetään usein kuvaamaan niitä ongelmakohtia, joita voi syntyä kun saatu palvelu ei vastaa asiakkaan odotusarvoa.
Tätä eroa kutsutaan kuvassa nimellä Gap 5, sillä se on seurausta kaikista sitä aiemmin ketjussa havaituista ongelmakohdista.
Kuva 13. Gaps Model of Service Quality. (Mendes & Mira da Silva, 2011.)
Gap1 kuvaa sitä eroa, joka syntyy kun palveluntarjoajan näkemys tuotetuista palveluista eroaa asiakkaan odotusarvoista. Palveluntarjoajalla on siis erilainen käsitys asiakkaan kanssa siitä, miten palvelut on tuotettu, jolloin molemmilla on erilainen käsitys tarjottavista palveluista. Tämä tarkoittaa käytännössä sitä, että vaikka palveluntarjoaja omasta mielestään tarjoaisi sopimuksenmukaista palvelua asiakkaalleen, voi asiakkaan näkemys tuotetusta palvelusta silti erota palveluntarjoajan näkemyksestä. Gap 2 puolestaan kuvaa tarkemmin sitä
eroavaisuutta, joka syntyy kun palveluntarjoajan tekemä määritelmä palvelun toimituksesta ei vastaa sitä odotusarvoa, joka palveluntarjoajalla on toimituksesta eli miten palveluntarjoaja haluaisi palvelun toimivan. Palveluntarjoaja on voinut määritellä tavoitteet selkeästi omassa palvelustrategiassaan, mutta ne kuvataan eri tavalla palvelukuvaukseen ja prosesseihin. Tähän syynä voivat olla ymmärryksen puute tavoitteen asettajan ja toteutuksen kuvaavan henkilön välillä tai inhimilliset virheet palvelukuvauksissa.
Gap 3 syntyy kun palvelu toimitetaan eri tavalla kuin sen toimitus on kuvattu.
Tästä esimerkkinä voisi käyttää tapausta, jossa palveluntarjoajan määritelmä tarjottavasta palvelusta niin toteutuessaan vastaisi myös palveluntarjoajan odotuksia ja palvelu on kuvattu oikein, mutta palvelua ei kuitenkaan toimiteta kuvausta vastaavalla tavalla, jonka vuoksi asiakas saa palvelukuvauksesta poikkeavaa palvelua. Ratkaisuna tähän on joko muuttaa tarjottavan palvelun kuvausta tai tuoda palvelun laatu kuvausta vastaavalle tasolle. Tämä on selkeä laatuongelma tuotetussa palvelussa. Gap 4 syntyy erosta palvelun kommunikoinnin ja toteutuneen palvelun toimituksen välillä eli käytännössä, vaikka palvelu olisi kuvattu oikein, mutta se kommunikoidaan väärin, käyttäjien odotusarvo palvelua kohtaan muodostuu vääräksi. (Mendes & Mira da Silva, 2011.)
Perinteisesti juuri Gap 1 on tunnistettu ongelma-alueeksi IT-palvelutuotannossa.
(Mendes & Mira da Silva, 2011). Tämä johtuu usein siitä, että käyttäjien on vaikea pyytää palvelua oikealla tavalla ja osittain myös väärinymmärretyistä pyynnöistä johtuen he saavat erilaista palvelua kuin odottavat. Ongelmat ovat usein tunnistettavissa myös muissa mallin kuvaamissa osissa, joka johtaa asiakkaan tyytymättömyyteen toimitettua palvelua kohtaan. Tämä on korjattavissa huolellisella palvelukatalogin suunnitellulla yhdessä liiketoiminnan kanssa.