AAMUKAHVIEN JÄLKILÖYLYT: ITSM-työkalut ja ITIL – miten ne sopivat yhteen?

Justin järjestää kuukausittain ilmaisia aamukahviwebinaareja. Kahvia on tarjolla sen mukaan, miten kukin kuulija sitä itselleen keittää, ja vakioaika – perjantai-aamu klo 8.30 – sopii webinaariosallistumiseen paremmin kuin hyvin. Elokuun aiheena oli ITSM-työkalut ja ITIL ne yhteen soppii?

Elokuun webinaariaiheena oli ITSM-työkalujen ja ITIL-prosessien yhteensopivuus. Aihe oli webinaaripuhuja Aleksi Airaksista mietityttänyt jo pidempään. Tukevatko työkalut haluttua tapaa toimia? Jos eivät, niin miten tämän ristiriidan voisi ratkaista?

ITIL-prosessit ja ITSM-järjestelmät ovat IT-palveluiden perusleipää. Ensimmäinen määrittelee, mitä suositellaan tehtäväksi ja toinen, miten asiat käytännössä toimivat. Palveluitten toimitukseen liittyvien tehtävien suurin massa on erilaisia tikettejä: tukipyyntöjä, häiriöitä, palvelupyyntöjä. Tarkoituksena on ratkaista IT-palveluun liittyvät asiakas- ja käyttäjäyhteydenotot nopeasti ja tehokkaasti.

Ihannetilanteessa prosessit ja työkalut ohjaavat tekemistä siten, että asiat saadaan ratkaistua nopeasti ja tehokkaasti. Suurin ristiriita prosessien ja työkalujen yhteensopivuudessa syntyy, jos työkalujen toiminnallisuus ei vastaa prosessissa määriteltyä haluttua tapaa edetä.

ITILin lyhyt historia

Kun puhutaan ITILin ja ITSM:n yhteensopivuudesta, lienee paikallaan raottaa myös historian arkkua. ITIL syntyi 1980-luvulla, ja yleistyi 1990-luvulla maailmanlaajuisesti. Keski-ikäisen ITILin tuorein versio, ITIL v4, on vuodelta 2019. Help Deskienkin historia juontaa kultaiselle 80-luvulle. Mitä pidemmälle aika on kulunut, sitä enemmän toiminnallisuuksia ja monimutkaisuutta on tullut järjestelmiin.

ITIL on ainakin terminologian tasolla käytössä lähes kaikilla. Terminologiaa ja määritelmiä tulkitaan hyvin kirjaimellisesti. Kaikelle on oma prosessinsa ja tikettityyppinsä, jopa oma työkalunsa. Tehokkuuden mittaus perustuu sopimuksissa määriteltyihin SLA:hin, joista suuri osa tukeutuu tikettien aikaleimoihin. Incident on häiriö ja request palvelupyyntö. Kaikilla on oma moduulinsa. Kaikki rokkaa. Missä siis tulee se mutta?

“Kun sopimus kohtaa oikean elämän, alkavat ongelmat”

Niin, mistä ongelmat siis alkavat? Kurkistetaan hetki palvelun käyttäjän ja palveluntarjoajan rooliin ja työkalurajapintaan.

IT-palveluita käyttävät ihmiset. Käyttäjien, asiakkaiden, ei tarvitse tuntea ITILiä tai ITSM-työkaluja syvällisesti voidakseen ottaa yhteyttä IT-palveluntarjoajaan. Palvelun käyttämisestä pyritään asiakaslähtöisesti tekemään heille mahdollisimman helppoa. Tarjotaan erilaisia yhteydenottokanavia matalalla kynnyksellä. On portaalia, chattia, puhelinpalvelua ja sähköpostivaihtoehtokin.

“Kanavat, paitsi portaali, eivät tarjoa mitään mahdollisuutta määrämuotoiselle yhteydenotolle. Yhteydenoton luonteen arviointi jää asiantuntijan vastuulle. Käyttäjä ei välttämättä edes erota vikatilannetta siitä, ettei vain osaa käyttää jotakin ominaisuutta – eikä hänen tarvitsekaan. Mutta palvelupyyntöön vastaavan asiantuntijan pitäisi pystyä näkemään tämän taakse välittömästi esimerkiksi puhelun alussa, jotta yhteydenotto voidaan luokitella oikein. Tässä leikitään tiukalla rajauksella, jotta saadaan SLA:ssa määritellyt vaatimukset täytettyä, ja samalla lisätään asiantuntijan kuormaa”, Aleksi kuvaa.

ITILiin pohjautuvat SLA:t perustuvat tiukkarajaiseen määrittelyyn, jossa incident-puolella on pelkästään häiriöt, ja niiden ratkaisuille on sopimuksellisesti tarkkaan määritellyt kriteerit ja tavoitteet. Tyypillisesti häiriöihin ei ole olemassa kaavamaisia ratkaisuja.

Asiantuntijoiden käyttämillä ITSM-työkaluilla taas on oma logiikkansa. Incident-moduuli pitää sisällään vapaamuotoiset yhteydenotot, jotka on mahdollista ratkaista kevyestikin. Request- eli palvelupyyntömoduuli puolestaan on todella hyvä ratkaisemaan ennaltamääritettyjä työpyyntöjä, kuten vaikkapa tilauksia.

“Se, että ITIL ja ITSM-työkalut eivät sovikaan niin saumattomasti yhteen, johtaa käytännössä siihen, että päivittäisessä tekemisessä työkalu on kömpelö. Työkalun automatisointimoottorin avun sijaan joudutaan heittämään epämääräiset työpyynnöt eteenpäin saatesanoilla “tuotanto hoitaa”. Se on kiitos ja hei asiantuntijan työmukavuudelle ja tehokkuudelle. Laitetaan ihminen työntämään robottia sen sijaan, että robotti auttaisi ihmistä“, Aleksi kuvaa ongelmatiikkaa.

Villakoiran ydin

Sopimuksiin viedään incidentit ja requestit, ja niitä käytetään ITILin tyypillisen määrittelyn mukaan. Incident on häiriö, vika, eikä mikään yksittäinen incident ole kaavamainen. Joku asia ei toimi. Incidenteille on tyypillisesti määritelty tarkasti ratkaisutavoitteet. Requestit ovat sitten kaikki muu, mikä jää häiriötilanteiden ulkopuolelle. Requesteille on usein kaavamainen ratkaisuketju, kuten vaikkapa tilauksissa, mutta yhtä usein ei: kyselyt, utelut ja käyttöapu.

Työkaluissa ero indicentin ja requestin välillä näyttääkin erilaiselta. Incidentille on työkalupuolella vapaamuotoinen prosessi. Se voi koskea mitä vain, ja on mahdollista ratkaista nopeasti. Requesteille puolestaan on määritelty tarkka työnkulku, ja requestien käsittely toimii parhaiten määrämuotoisella syötteellä.

“Tässä ollaan nyt konfliktin ytimessä: requestiin (työkalu, määrämuotoinen) siirrellään vapaamuotoisesta moduulista epämääräisiä kysymyksiä. Tätä yritetään ratkoa eri tavoin, kuten generic request- tai help button -tyyppisesti. Työkalut eivät niitä tue, eikä niitä mielestäni pitäisi ottaa käyttöön. Kun vapaamuotoinen kysymys tungetaan määrämuotoiseen requestiin, käsittelystä tulee väkisinkin asiantuntijalle työläämpää. Toinen vaihtoehto generic requestille on tukahduttaa portaali sillä, että ihan jokaiselle asialle on oma määrämuotoinen lomakkeensa. Arvaat varmaan, että käyttäjäkokemus ei tästä hirveästi parane. Lisäarvo palvelunhallinnallekin on täysi nolla. Ratkaisu on, että request-puolella vapaamuotoisuutta olisi hyvä välttää“, Aleksi sanoo.

Nykyisin incident on suojattu, kaikki muut ovat requesteja. Miksi? Tätä kysymystä kannattaa tarkastella myös sopimussanktioiden valossa.

Miten ristiriitatilanteen sopimusten ja käytännön elämän välillä voisi ratkaista?

“Mitä jos muutettaisiinkin ajattelua? Entä jos tulevaisuudessa suojattu puoli olisikin määrämuotoisesti tehokkuutta ja automaatiota varten? Olisi määritelty määrämuotoinen työnkulku ja lopputulos. Kaikki muu olisi sitten vapaamuotoisella puolella”, Aleksi haastaa.

Käyttäjälle malli näyttäisi yksinkertaisemmalta. Prosessitekeminen siirtyisi pois käyttäjän näköpiiristä, jota ohjaisivat käyttökanavat. Siellä, missä määrämuotoisuuteen voidaan ohjata, kuten portaalissa, tehdään niin. Kaikki muu voi olla ketterässä prosessissa vapaamuotoisten tikettien käsittelyssä. Jos vapaamuotoiseen tikettiin on olemassa määrämuotoinen lomake, ohjataan vapaamuotoisen palvelupyynnön tekijä oikeaan kanavaan.

Palvelunhallinnan näkökulmasta hyötyä tulisi selkeästä raportoinnista ja tehokkuuteen liittyvistä mittareista sekä määrämuotoisille palveluille ennalta sovitusta toimitusajasta. Vapaamuotoisille tiketeille voitaisiin sopia reagointiaika, ei tavoiteratkaisuaika (joka voisi olla olemassa toiminnan kehittämistä varten). Palveluiden saatavuuteen liittyvät mittarit ja asiakas-/käyttäjätyytyväisyysmittarit ovat edelleen valideja mittareita tässäkin luokittelussa.

“Miten työkalu haluaa toimia, miten meidän ihmisten prosessiymmärrys haluaa toimia… tässä on ristiriitaa arkiymmärryksen kanssa. ITSM-työkalu tarjoaa toiminnallisuuksia, jotka voivat perustua luokitteluun. On hyvä miettiä, mitä se tarkoittaa kunkin organisaatiossa – ja jos ristiriitaa on olemassa, miten se organisaatiossa voitaisiin ratkaista”, Aleksi summaa.

Arkkitehdin vinkit

1. ITIL on edelleen validi ja antaa hyvän yhteisen kielen.

2. Laajennetaan incidentin määrittelyä: ITIL:in kanssa on mahdollista jäädä jumiin: työkalut eivät tue tehokkaasti nyky-ymmärrystä. ITSM-työkalujen tehokas käyttö on häiriöiden ja ei-häiriöiden välillä – incident on tulkittu liian suppeasti vikatilana. Palvelun normaalin kulun ja tilattavien asioiden ulkopuolinen tarve olisi parempi määrittely.

3. Kun incidentit ovat palvelun normaalin kulun ja tilattavien asioiden ulkopuolinen tarve, muut tarpeet eivät enää ole palvelupyyntöjä, vaan ITILin mukaisia requesteja: palvelun tai asian tilaamista määrämuotoisesti, ennalta määritellysti, määrämuotoisella toimituksella.

4. Työkaluista pitäisi puhua uusilla nimillä. esimerkiksi issue management ja order management.

5. Tehdään SLA:t sen mukaan, miten määrämuotoinen / vapaamuotoinen on määritelty. Esimerkiksi: Jos soitat, vastausaika on minuutti. Jos lähetät sähköpostin, saat vastauksen 30 minuutissa. Ratkaisuaikatavoitteet määritellään erikseen.