Onko ITIL syvältä?

WordPress näyttää milllä hakusanoilla joku on löytänyt Pohjoisviitan sivut. Luettelossa on parin päivän ajan pistänyt silmään lause ”itil on syvältä”. En ole käyttänyt tuota sanontaa koskaan aikaisemmin, joten haku on tullut tänne todennäköisesti vain sen takia, että olen kirjoittanut aika paljon itilistä suomeksi. Jäin miettimään mitä tuohon vastaisi. Tietyissä olosuhteissa väite on täysin väärä, jossakin tilanteessa taas voin olla samaa mieltä.

Aluksi olin sitä mieltä, että itil on hyvä ja tarpeellinen. Sitten kolmosversio epäonnistui pahan kerran ja itil paisui mahdottomaksi möhkäleeksi. Lisäksi kolmosversiossa oli paljon typeriä virheitä. Nyt olen alkanut kyseenalaistamaan myös alkuperäisen itilin hyötyä. Tämä johtuu osin siitä, että maailma on muuttunut itilin ympärillä. Vanhat 1980-luvun mallit eivät enää istu niin hyvin kuin ennen. Sinänsä mallin ikä ei ole yksinään mikään syy hylätä sitä, mutta itilin tapauksessa käytännöt ovat muuttuneet liikaa. Vanhan mainframe-maailman opit eivät ole tätä päivää.

Mielestäni itil, siis kakkosversio, edustaa yhtä kehitysvaihetta. Kun IT-yksikkö laskeutuu puusta, se tarvitsee itiliä. Itil on parempi kuin ei mitään. Kun itil on hyödynnetty, pitää siirtyä eteenpäin.

Itil puhuu monista hyvistä asioista, mutta sen ratkaisut eivät ole läheskään aina edes käyttökelpoisia. Silti mielestäni IT-ammmattilaisen yleissivistykseen kuuluu tuntea Itil ja ISO 20000. Peruskurssi tai itseopiskelu riittää.

Itilistä on tarjolla runsaasti jatkokursseja ja sertifikaatteja. On huolestuttavaa, jos niiden opiskelija ei tajua viimeistään kolmannen kurssin kohdalla, että itil-koulutusohjelma tosiaankin on syvältä.

Muistoja menneisyydestä

Olin maanantain ja tiistain itSMF UK:n 21. konferenssissa. Oli todella upeata nähdä miten hienosti sosiaalinen media toimii. Sosiaalisen median kautta tutustuu erittäin helposti ihmisiin ja kun on keskustellut verkossa, on luonteva jatkaa keskustelua livenä.

Konferenssissa oli muutama erinomainen esitys, joista vaikuttavin oli Simon Wardleyn keynote. Hän kuvasi hienosti luovan tuhon kierrettä. Luova tuho hävittää vanhan ja tilalle tulee jotain uutta ja parempaa. Muutos ei ole pehmeä ja mukava asianomaisille, vaan tuho on todellista tuhoa, sotaa. Sitä edeltää mukava tasaisen elämän vaihe, jolloin kasvu on tasaista ja elämä näyttää varmalta sekä turvalliselta. Näin suomalaisittain Nokia on loistava esimerkki.

Tuhon käynnistää yleensä jokin teknologinen oivallus, joka mahdollistaa uuden tavan toimia. On helppo havaita että printtimedia eli lehdet ovat juuri tässä vaiheessa. Sama koskee myös meitä jotka painimme IT-palvelunhallinnan parissa. Maailma muuttuu vaikka kuinka pyristelisimme vastaan.

Tätä avausta vasten oli piinallista nähdä, miten konferenssissa jauhettiin iänikuisia vanhoja asioita. Valtaosa esityksistä oli ITIL prosesseista, pelkästään incident-problem  -pulmaa käsiteltiin useassa esityksessä. (Incident-problem -pulma ratkeaa heti, kun päätät unohtaa ITILin opetukset). Tuntui kuin ajattelu oli jäänyt junnaamaan menneisyyteen. Tunnelmaa vahvisti se, kuinka esitysten välissä näytettiin videota konkareiden muisteluista.

***

Pidin itse Unlearning ITIL -esityksen ja vastaanotto oli mahtava. Kaikki ITIL ”heavyweights” tulivat etuosaan, joten painetta riitti. Esitys oli pitkälti sama, jonka pidin Suomen itSMF-konferensissa vuosi sitten, ja ne jotka olivat kuuntelemassa muistanevat, että pöllytin ITILiä aika lailla. Se oli helpompaa, kun salissa ei istunut ITILin kirjoittajia 😉

Esitys sai aikaan vipinää Twitterissä ja kannatusta löytyi.  Minut pyydettiin saman tien pitämään esitys Viron itSMF-konferenssissa ja lisäksi tiedusteltiin, voisinko lähteä myös Australiaan pitämään saman esityksen.

***

Konferenssin aikana puhuin riskienhallinnan liian pienestä osuudesta it-palvelunhallinnassa. Asiantuntijat olivat samaa mieltä. Riskienhallinta on tärkeää ja se on jäänyt liian vähälle huomiolle. Tähän mennessä 28.11. pidettävään Riskienhallinnan työpajaan on myös ilmoittautunut liian vähän osallistujia ja todellakin haluaisin pitää sen. Työpaja ei tarkoita pelkästään että tulet opiskelemaan jotain vaan työpaja luo uutta ymmärrystä. Korjaa tilanne ja ilmoittaudu nyt.

Kypsyydestä

It-organisaation tilaa voi kuvata sen kypsyystasolla. Kypsyystasot ovat usein suhteellisen helppo tunnistaa ja niistä on olemassa lukuisia malleja. Lähtökohtana on yleensä yksilöllinen toiminta, johon tulee ensin valvontaa, sitten hallintaa, ohjausta ja optimointia. On tavallista ajatella että kypsyydessä pitää pyrkiä aina korkeimmalle tasolle, mutta se ei ole välttämättä totta. Olen käyttänyt renkaiden vaihtoa esimerkkinä erilaisista kypsyystasoista.

 0-taso Sakkokuski ei vaihda renkaita kuin pakon edessä.
1-taso Yksityisautoilija tarkistaa renkaiden kunnon kesä/talvi-renkaiden vaihdon yhteydessä ja hankkii uudet kun kulutuspinta alkaa olla vähissä.
2-taso Taksiyritys uusii renkaat 50.000 km välein.
3-taso Bussiyhtiön ajomestari seuraa renkaiden kulumista ja määrää vaihtohetken puoli vuotta aikaisemmin.
4-taso Rekkayhtiö seuraa renkaiden kulumista ja maksaa kuljettajille bonuksia jos renkaat kestävät keskimääräistä paremmin.
5-taso Formula 1 talli arvioi renkaiden keston kierroksen tarkkuudella, mutta muuttaa suunnitelmia, jos olosuhteet vaihtuvat. Renkaan vaihtohetkeen vaikuttavat rata, kierrosajat, sää ja muiden kilpailijoiden toiminta. Tavoiteaika vaihtoon on 4 sek.

 Edellä kuvattu malli korostaa sitä, että tavoiteltava kypsyystaso riippuu tarpeesta, mutta toki jokainen voi toimia tarvittavaa matalammalla kypsyystasolla.

Elokuun kyselyn teemana oli KPMG:n jo vuonna 2000 julkaisema malli IT yksikön kypsyydestä. Mielestäni malli on edelleen osuva.

Mallin kypsyystasot

  1. Teknologialähtöinen. IT taistelee tekniikan kanssa, juuri mitään prosesseja ei ole käytössä. Asiakas saa sitä mitä kyetään tarjoamaan. Toiminta voi sinänsä olla melko asiakaslähtöistä, mutta sen laadun ja luotettavuuden kanssa on ongelmia.
  2. Prosessikeskeinen. Prosessit on saatu toimimaan ja IT kykenee mittaamaan toimintaansa. Prosessit ovat keskeisessä roolissa ja asiakkaan tulee mukautua niihin, muuten palvelu ei toimi.
  3. Palvelukeskeinen. IT on määritellyt palvelunsa ja kykenee tuottamaan niitä ohjaamalla prosessejaan. Palvelut ovat standardoituja. Asiakas voi tilata palveluja, mutta ei voi muokata niitä.
  4. Asiakaskeskeinen. Nyt asiakas pääsee päättämään palveluista ja IT toimii lähellä asiakasta tiiviissä yhteistyössä. Taustalla ovat toimivat prosessit ja standardoidut peruspalvelut. Niitä osataan käyttää hyvin joustavasti.
  5. Liiketoimintakeskeinen. Liiketoiminta ohjaa IT:tä täysin ja IT:n tavoitteet ovat liiketoimintatavoitteita.

Tässä mallissa palvelukeskeisyyden ja asiakaskeskeisyyden välillä on merkittävä kynnys. Alemmilla tasoilla IT päättää ja asiakas saa mitä IT toimittaa, ylemmillä tasoilla vastuu on siirtynyt asiakkaille. Kyse ei ole siis pelkästään IT:n kypsyydestä, vaan myös asiakkaan on kypsyttävä tähän rooliin.

Tämän pohjalta yritin kuvata tilanteita, joissa kukin taso olisi saavutettu.

 
a) Teknologia on hallussa. IT laitteet ja järjestelmät toimivat ja mahdolliset vikatilanteet kyetään korjaamaan.
b) Prosessit toimivat tehokkaasti. Kaikki häiriöt, ongelmat, muutokset jne. kirjataan. Häiriöiden ratkaisuajat tiedetään ja muutosten riskit osataan arvioida.
c) Palvelut pelaavat. Osataan tuottaa pitkälle standardoituja IT palveluja asiakkaan tilausten mukaan. Muutosten vaikutukset tunnetaan ja palvelujen laatu on hallinnassa.
d) Asiakas määrää. Asiakas ohjaa toimintaa ja päättää mitä IT palveluja tuotetaan. IT-organisaatio kykenee mukautumaan joustavasti muuttuviin tarpeisiin.
e) Liiketoiminta ohjaa.  IT on sulautunut liiketoimintaan ja sitä johdetaan liiketoiminnan näkökulmasta. IT pystyy luomaan uusia mahdollisuuksia liiketoiminnalle. 

Pyysin kertomaan miten hyvin vastaajan organisaation nykyinen tila vastaa näitä kuvauksia asteikolla: 1 -5. 1 ei lainkaan, 2 vain vähäisesti, 3 osittain, 4 aika hyvin ja 5 täydellisesti.

Lisäksi pyysin vielä kertomaan mikä näistä kuvauksista vastaa nykyistä tilaa ja mikä on tavoitteena. Tämä kysymys oli ilmeisesti vaikeasti muotoiltu, sillä n. kolmasosa jätti vastaamatta siihen tai vastasi väärin. Oikea vastaus olisi siis ollut jokin kirjain, esim. nyt A ja tavoitteena B. Näin muuten ei yksikään vastannut, vaikka se olisi oikea vaihtoehto aika monelle.

Valtaosassa vastauksissa oltiin tasoilla 4 tai 3 eli aika hyvin tai osittain. Ainoastaan teknologia -tasolla löytyi merkittävä määrä täydellisesti -vastauksia.

Kynnys palvelu- ja asiakastasojen välillä näkyy selvästi, vain alle 20 % arvioi olevansa niillä tasoilla.

Oman tason ja tavoitetason välillä on mielenkiintoinen korrelaatio. Jos omaksi tasoksi arvioitiin teknologia, tavoittetasona oli yleensä palvelu. Jos taas oma taso oli jokin muu, tavoitteeksi tuli asiakas- tai liiketoimintakeskeisyys.

Tein oman tulkinnan kypsyystasoista vastausten perusteella.

Jos vastaaja oli jonkun kypsyystason kuvaavan täydellisesti, hyväksyin sen. Jos vastaaja ei sanonut yhdenkään tason toteutuvan täydellisesti, mutta sanoi useamman toteutuvan aika hyvin, valitsin näistä toiseksi ylimmän. Näin laskin jokaiselle vastaajalle tämän hetken kypsyystason. Periaatteena oli, että alempien kypsyystasojen täytyy toteutua eli kypsyystasoarvioiden piti pysyä samana tai pudota.

Oman tulkintani mukaan vajaa puolet jäi tasolle nolla, eli teknologia ei ole täysin hallussa. Vajaa neljännes on saavuttanut sen tason. Joka viidennes on saavuttanut prosessitason ja yksi kymmenestä palvelutason. Yksi henkilö vastasi 5 joka tasolle.

Johtopäätökset

Tulos on mielenkiintoinen monella tavalla. Tämän mukaan noin puolet it-yksiköistä ei ole päässyt yli teknologiakeskeisyydestä. Mielestäni monet havainnot tukevat tätä tulkintaa.

Teknologian hallinnan tasolle on päässyt joka neljäs ja heillä on edellytykset saada prosessit toimimaan. Joka viides on prosessitasolla ja joka kymmenes päässyt yli seuraavan kynnyksen. ITIL termein 20 % on V2-tasolla ja 10 % V3-tasolla ja lähes 70 % ei ole vielä saavuttanut ITIL V2 -tasoa.

Näyttää siltä että tasoeroja ei tunnisteta. Prosessikeskeisyys ei ole sama asia kuin palvelukeskeisyys. Tämä on mielestäni ITILin kolmosversion ongelma, siitä ei käy ilmi että se kuvaa kaksi kypsyystasoa ikään kuin yhdessä. Asiakaskeskeisyyden haaste sen sijaan tunnistetaan ja valtaosa vastaajista näkee että sinne on vielä matkaa.

Tavoitteiden asetanta on vielä optimistista. Realistinen tavoite on seuraava kypsyystaso. Liiketoimintakeskeisyys tuntuu houkuttelevalta, mutta silloin tosiaankin it:n toimivuutta mitataan samalla tavalla kuin itse liiketoimintaa, siis myyntinä, kannattavuutena jne.

Jokaisen it-yksikön pitäisi tunnistaa oma kypsyystasonsa ja ulkopuolinen tarkkailija voi olla avuksi tässä. Sitten on arvioitava mikä on tarvittava kypsyys ja sen määrää asiakkaan tila. Ei ole lainkaan selvää, että liiketoimintakeskeinen kypsyystaso on oikea tavoite kaikille. Se edellyttää että it:llä on aidosti merkittävä rooli liiketoiminnassa ja näin ei ole läheskään kaikilla aloilla.

Asiakaskeskeisyys edellyttää että asiakas on halukas ottamaan merkittävän roolin it:n ohjaamisessa. Näin ei suinkaan ole aina. Palvelukeskeisyys luo myös raja-aidan asiakkaan ja palveluorganisaation välille, kuten jokainen palvelun ulkoistanut on varmasti havainnut. Voi myös pohtia riittääkö teknologian hyvä hallinta joissakin tapauksissa eli tarvitsevatko kaikki prosesseja?

Oma kypsyystaso määrittää sen, mitä pitää kehittää ja miten palvelua voi mitata. Esimerkiksi prosessien käyttöönotto takeltelee, jos ollaan edelleen vaikeuksissa teknologian kanssa. Palvelujen tason mittaaminen on vaikeaa, jos prosessit eivät toimi jne. Johtamisen täytyy myös olla vastaavalla kypsyystasolla. Kaikki tämä on helpompi sanoa kuin tehdä.

Help desk hengissä

Olen havainnut että help deskit ovat alkaneet taas kiinnostamaan, kursseilla on kysyntää ja toimeksiannot liittyvät tuen kehittämiseen. Keksin tarkastaa asian Googlesta ja sain vahvistuksen. Alla olevassa kuvassa on kolmen hakusanan vertailu. Sininen on help desk, punainen on ITIL, ja keltainen service desk. (Huom. kohteena on USA koska itil tarkoittaa indonesiaksi erästä naisen elintä ja se on liian kiinnostava.)

Kuva kertoo kaksi mielenkiintoista asiaa. Ensinnäkin, itilin service desk ei ole lainkaan niin kiinnostava kuin perinteinen help desk. Tämä yllätti minut. luulin että service desk on ollut korvaamassa vanhaa termiä.

Toinen havainto on että itilin ja help deskin kiinnostavuus ovat kuin peilikuvat. Itil oli kasvussa vuoteen 2007 asti, josta alkoi jyrkkenevä alamäki. Help desk taas oli laskussa vuoteen 2008 asti, mutta on nyt hienoisessa nousussa.

Oma tulkintani on se, että ihmiset alkavat tajuavan totuuden itilistä, eli parhaat käytännöt eivät täytä lupauksiaan. Uusi 2011 edition taas sisälsi sen myönnytyksen että V3 oli täynnä virheitä.

Toisaalta taas help deskiin kohdistuu uusia haasteita ja niihin kaivataan uusia ratkaisuja. Asiakkaiden vaatimukset muuttuvat ja niihin on vaikea vastata vanhalla mallilla.

Service Desk 2.0 -malli, jota olen kehittelemässä, on yritys vastata muuttuneeseen tilanteeseen. Pitäisiköhän alkaa sittenkin puhua Help Desk 2.0;sta?

 

Tenttikysymyksiä tekemässä

EXIN päivittää ISO 20000 koulutusohjelmansa tenttikysymyksiä standardin uuden version mukaiseksi ja olen muokannut kysymyksiä uuteen uskoon. Standardin muutokset eivät vaikuta niinkään paljon kuin tentin rakenteen muutokset. Tentti on vanhaa Service Manageria vastaava ISO 200000 Consultant/Manager, joten kysymysten pitäisi olla aika vaikeita. Hauskaa puuhaa, paljon hauskempaa taatusti kuin niihin vastaaminen.

En ole silti monivalintatenttien ystävä. Sertifikaatit soveltuvat perustasolle, jossa on kohtuullista edellyttää että henkilö tuntee terminologia ja peruskäsitteet. Ylemmillä tasoilla tarvitaan mielestäni esseevastauksia. Toki EXIN harrastaa niitäkin eli tenttiä ei läpäise pelkästään monivalinnoilla.

Itil Expertiksi kuitenkin pääsee vain harjoittelemalla monivalintoihin vastaamista. Se on sitä helpompaa, mitä enemmän saa treenata oikeilla kysymyksillä, niinkuin maailmalla kuuluu olevan tapana. Tässä helppo testi, jolla voi tarkistaa onko itil ekspertti ymmärtänyt mitään oppimastaan, vai onko opiskelu ollut pelkää ulkoaoppimista. Kysy mitä virheitä itilissä on. Todellisen asiantuntijan pitäisi kyetä luettelemaan helposti paljon virheitä.

ITSMF konferenssi

Oli hauska tavata paljon tuttuja ihmisiä hyvin järjestetyssä konferenssissa, kiitokset vain järjestäjille.

Oma esitykseni meni omasta mielestäni hyvin. En ole koskaan saanut niin paljon spontaania positiivista palautetta esityksestäni. Kerroin että itilissä on jotain hyvää, mutta todella paljon puutaheinää. Ilmeisesti moni on tajunnut sen, mutta ei ole uskaltanut väittää vastaan ja koki nyt helpottavana kuulla, että ei ole yksin epäilyksissään. Eräs tuttu kertoi tulleensa koko tilaisuuteen esitykseni takia. Hän opiskeli itilin jatkokursseja kohti Expert-tasoa ja sanoi alkaneensa epäillä saamaansa oppia ja halusi kuulla mitä sanoin. Tässä esitykseni (pdf) itSMF 2011 esitys v21 Siinä leikkaan läskin pois itilistä ja katson mitä jää jäljelle.

Minulla oli kiinnostava keskustelu Mark Smalleyn kanssa. Hän edustaa organisaatiota, joka yrittää kehittää linkkiä it palvelunhallinnan ja it:n välille. He tekevät hyvää työtä, mutta näin pulmana miten ihmeessä näihin ei-it ihmisiin saisi yhteyden. Tarkoitan siis niitä ihmisiä, jotka tekevät it-päätöksiä it:n ulkopuolella. Minulla oli ajatus siitä miten asiaa voisi lähestyä ja Markin mielestä ajatukseni olivat niin kiinnostavia että hän lupasi oman esityksensä aluksi siitä jo white paperin yhdessä kanssani  (joka siis tuli minulle yllätyksenä). Kirjoituksemme tulee perustumaan tutkimukseen, jonka teemme Suomessa. Tulen siis tarvitsemaan apuanne sen kanssa mutta siitä lisää myöhemmin.

 

ITIL 2011 pähkinänkuoressa

ITIL V3 on siis nyt ITIL 2011. Nelosversiota ei tullut vaikka käytännössä tämä on uusi versio. Kolmosversion kirjat kannattaa panna paperinkeräykseen.

Tätä alkujaan 2008 julkaistua juttua luetaan yllättävän paljon vieläkin. Päivitän sen nyt koskemaan ITIL 2011 Editionia. ITIL 2011 on edelleen laaja ja monimutkainen kokonaisuus. Se sisältää nyt selkeän listan prosessista, ennenhän se oli vähän tulkinnallista. Prosesseja on nyt 26 ja lisäksi lukemattoman määrän näiden ulkopuolella olevaa aktiviteettia.

1 Service Strategy

Uusi versio on selvästi parempi kuin aiempi ja se on kirjoitettu kokonaan uudestaan. Huomautin edellisessä kritiikissä että eräät asiat käsiteltiin kahteen kertaan, ensin strategiassa ja sitten Service Design kirjassa. Syynä oli ilmiselvästi se, ettei kukaan koordinoinut kokonaisuutta.

Nyt kirja keskittyy IT-palveluihin, eikä ole liian yleinen. Lisäksi kirjoittajille on valjennut että monet it-palveluyksiköt ovat sisäisiä. Monet kolmosversion kirjan esimerkit tuntuivat kovin kaukaa haetuita ja onneksi niitä on poistettu. Strategia määritellään markkinalähtöisesti, eli ensin kuvataan markkinapaikka ja sitten tarjooma. Näiden varaan rakennetaan strategiset voimavarat. Toteutuksen valmistelu käsittelee nykytilan arviointia, menestystekijöiden määrittelyä ja strategisten askelten suunnittelua.

Strategian ylläpito yläpito kuvataan prosessina, joka on aika epärealistista useimmille. Jos strategia on tarpeen tehdä, siitä ei silti tule luontevasti prosessia.

Palveluportfolion hallinta on myös mielestäni älytön prosessi. Johdon tehtävänä on miettiä palveluportfoliota ajoittain, mutta harva siihen tarvitsee prosessia. Lisäksi asia menee päällekkäin Service Design -kirjan kanssa.

IT taloushallinto tuntuu edelleen oudolta elementiltä strategiakirjassa. Ilmeisesti se ei oikein sopinut mihinkään osaan luontevasti, tosin mielestäni Service Design olisi oikea paikka sille. Kolmosversion sfääreistä on nyt palattu ryminällä arkeen. Tuskin kirjassa on paljoakaan uutta, taloushallinto tuntuu yleensä toimivan tyydyttävällä tasolla. Sen sijaan on älytöntä että taloushallinnolle esitellään 25 KPI-mittaria.

Demand management kuvaa kysynnänhallinnan. Tämä oli täysi sekametelisoppa vanhassa kolmosversiossa. Ajatus oli karannut kirjoittajilta täydellisesti ja lisäksi sama prosessi kuvattiin uudestaan Service Design -kirjassa. Nyt tarinassa on jotain tolkkua ja demand -prosessia ei enää kuvata kahteen kertaan.

Business Relationship Management Tämä on kokonaan uusi prosessi, jonka puuttuminen oli kolmosversion suurin moka. Tietenkään asiakassuhteen hallinta ei ole prosessi vaan funktio. Suhteen hallinta on pitkälti henkilösidonnaista, mutta jos unohdetaan tuo prosessikäsitteen pahoinpitely, niin kappaleessa on asiaa.

Service strategy, governance, architecture and ITSM implementation strategies on pitkä ja sekava nimi kappaleelle, jossa käsitellään mm. strategian jalkauttamista ja pohdinta vaikuttaa fiksulta.

Organizing for service strategy käsittelee erilaisia organisaatiomalleja ja yrityskulttuuria. En oikein tiedä, onko tästä olemassa parasta käytäntöä.

Technology considerations on edelleen outo luku. Siinä käsitellään palveluautomaatioita ja valvontajärjestelmiä. Tämän kirjoittajalle ei oikein auennut näiden sinänsä hyvien asioiden strateginen ulottuvuus.

Implementing service strategy on uusi luku, asiaa ei juurikaan käsitelty viimeksi. On vähän hassua että strategian jalkauttamista käsitellään uudestaan, kun se tuli jo kertaalleen käsiteltyä .

Haasteet, kriittiset menestystekijät ja riskit.Tämä on vähän turha kappale, mutta onneksi lyhyt. Kaikkia kappaleen asioita on jo käsitelty useaan kertaan.

Parannuksista huolimatta pidän kirjaa turhana useimmille. Sisäinen it yksikkö ei laadi strategioita, vaan suunnittelee miten toteuttaa johdon sille asettamia tavoitteita.

2 Service Design

Kirja käsittelee palvelujen suunnittelemista ja kehittämistä. Se kattaa strategisten tavoitteiden muuntamisen palveluiksi. Kohteena ei ole pelkästään uudet palvelut vaan myös olemassa olevien palvelujen kehittäminen liiketoiminnan ja ympäristön vaatimusten mukaisesti. Siihen kuuluu myös palvelujen laadun, jatkuvuuden ja yhdenmukaisuuden varmistaminen. Service design kuvaa kahdeksan prosessia eli prosessien määrä on kasvanut yhdellä.

Service design management Tämä on aika uskomaton uusi ”prosessi”. Se tuottaa Service Design Package (SDP) -määrittelyjä. Nämä SDPt ovat ylätason palvelukuvauksia. Tämä on älyttömän raskas lähestymistapa.

Palveluluettelon hallinta. Prosessin tehtävänä on ylläpitää palveluluetteloa ja tuoda se kaikkien saataville. Tämä oli aiemmin Palveluntasonhallinnan aktiviteetti, joka on nyt nostettu omaksi prosessiksi. Tämäkin on turha prosessi.

Palveluntason hallinta Palvelutasonhallinnan tavoitteena on varmistaa että asiakkaat saavat sovittujen tavoitteiden mukaista palvelua ja että tarvittaessa palvelua myös kehitetään. Prosessi varmistaa sen, että palvelutaso mitataan ja tulokset raportoidaan asiakkaalle. Prosessin aktiviteetteja ovat mm:

  • vaatimusten määrittely ja kirjaaminen
  • palvelutason seuranta ja valvominen
  • asiakastyytyväisyyden mittaaminen ja palautteiden käsittely
  • arvioida ja päivittää hankintasopimukset yhteistyössä supplier managementin kanssa
  • palvelujen katselmointi ja kehittämisohjelmien käynnistäminen
  • asiakassuhteiden ylläpito yhteistyössä business relationship managementin kanssa.

Saatavuuden hallinta Saatavuuden hallinta on laajentunut kattamaan ongelmanhallinnan ja palvelun kehittämisen aluetta. Sinne on esimerkiksi ilmestynyt käsittämätön termi, proaktiivinen saatavuuden hallinta. Mitäköhän reaktiivinen saatavuudenhallinta sitten olisi? Täällä esitellään myös ongelmanratkaisumenetelmiä.

Kapasiteetin hallinta Prosessin tavoitteena on varmistaa kapasiteetin optimaalinen riittävyys. Hyvä kysymys on se, miksi demand management on erotettu omaksi prosessikseen.

IT palvelun jatkuvuuden hallinta Aiemmassa ITIL versiossa käsiteltiin varsin vähän strategiatason asioita. Oikeastaan ainoa selvä poikkeus oli jatkuvuudenhallinta, jossa täytyy pohtia sitä, kuinka paljon ollaan valmiita maksamaan it-palvelujen turvaamisesta. Esimerkiksi tietojärjestelmien täydellinen kahdentaminen on kallis toimenpide, joka varmasti perustuu yrityksen strategiaan. Olisi ollut johdonmukaista sisällyttää tämä osuus Service Strategy –kirjaan, jonne se olisi luontevasti kuulunut. Kirjoittajat ovat kuitenkin säilyttäneet tämän prosessin ennallaan.

Tietoturvanhallinta Prosessin tehtävänä on sovittaa tietoturva liiketoiminnan tarpeisiin ja vastata sen toiminnasta. Kirjassa viitataan moneen otteeseen ISO 27001 –standardiin.

Toimittajien hallinta Toimittajien hallinta on prosessi jonka tarkoituksena on hallinnoida toimittajia ja heidän palvelujaan niin että palvelun laatutavoitteet saavutetaan ja että ostetut palvelut tuottavat lisäarvoa. Aktiviteetteja ovat mm.

  • tarpeiden määrittely
  • toimittajien ja sopimusten arviointi
  • toimittajien luokittelu ja toimittajatietojen ylläpito (uusi lyhenne SCMIS)
  • uusien toimittajien käyttöönotto
  • toimittajien toiminnan arviointi
  • sopimusten uusiminen tai päättäminen

3 Service Transition

Palvelun muutosten hallinta käsittelee uusien ja muuttuneiden palvelujen käyttöönottoa. Elinkaarimallin mukaisesti uudet palvelut suunnitellaan strategian ohjaamina ja sitten ne otetaan hallitusti käyttöön. Kirjassa esitellään seuraavat prosessit:

  • Transition Planning and Support
  • Change Management
  • Service Asset and Configuration Management
  • Release and Deployment Management
  • Service Validation and Testing
  • Evaluation
  • Knowledge Management.

Transition planning and support on ylätason prosessi, joka luo mm. muutosstrategian ja release policyn.

Change management on pitkälti entinen muutostenhallinta mutta samalla alueella hääräävät myös mm. Portfolio Management, Transition planning and support ja Change Evaluation.

Service Asset and Configuration Management SACM on laajennettu versio aiemmasta konfiguraationhallinnasta. Sen tukena on uusi järjestelmä, CMS eli Configuration Management System.

Release and Deployment Management on pääosin vanha Release management. Hiukan hämmentävästi tekstiin on jätetty edelleen myös jakelupolitiikan eli release policyn suunnittelu, vaikka siihen tarkoitukseen on määritelty kokonaan uusi prosessi.

Service Validation and Testing on prosessi, jonka tehtävänä on varmistaa että suunniteltu muutos tuottaa halutun hyödyn. Prosessin on ajateltu toimivan korkeammalla tasolla kuin Change ja Release managementin testaaminen. Miten tämä sitten tapahtuisi käytännössä, herättää kyllä kysymyksiä.

Change Evaluation process on prosessi, jonka tehtävänä on arvioida muutoksia. Sen roolia on nyt tarkennettu tähän muutosten arviointiin.

Knowledge Management on uusi prosessi, jonka tehtävänä on huolehtia siitä että tarvittavat tiedot ovat saatavilla. Kirjassa aihetta lähestytään hyvin pinnallisesti. Aihe lienee ollut melko vieras kirjoittajille. Uudessa 2011 versiossa aihe ei ole vieläkään valjennut. Tähän on parempia lähteitä.

4 Service Operation

Kirja kuvaa varsinaisen palvelujen tuotantovaiheen. Kirjassa kuvataan seuraavat prosessit

■ Event Management

■ Incident Management

■ Problem Management

■ Request Fulfillment

■ Access Management

Kirjassa käsitellään myös varsinaisia tuotantoprosesseja, jotka puuttuivat V2:sta sekä tuotannon organisointia.

Event management on prosessi, joka käsittelee erilaisten valvontajärjestelmien antamia varoituksia. Varoitus voi olla exception (poikkeama) ja ne voidaan käsitellä automaattisesti. Esimerkkinä mainitaan serverin kaatuminen. Tässä on hyvä muistaa, että levypakan hajoaminen taas on insidentti. Tämä käsitesoppa on siis saanut jatkua, mitään tolkkua tästä ei tule. Exception-termiä ei selitetä sanastossa.

Incident Management on sama prosessi kuin aiemmassa versiossa, joskin siitä on poistettu palvelupyyntöjen käsittely omaksi prosessikseen. Insidentin käsitettä on taas hiukan muutettu, aluksi insidentti oli mikä tahansa normaaliin toimintaan kuulumaton tapahtuma joka haittasi tai saattoi haitata palvelua. Väliversiossa määritelmä oli hyvin sekava, insidentti oli häiriö mutta insidenttienhallinta oli asiakastukea. Nyt uusi insidentin määritelmä on nyt täsmentynyt häiriöksi. Insidentin ja poikkeaman ero jää hämäräksi.

Request Fulfilment käsittelee erilaisia tilauksia. 2011 edition jättää neuvonnan kokonaan Itilin ulkopuolelle. Edellinen kolmosversio sisällytti sen insidenttien hallintaan, melko sekavasti tosin mutta kuitenkin. Nyt nämä käsitteet on selkeytetty ja varsinaiset tukipyynnöt on jätetty kokonaan pois. Insidentit ovat yllättäviä tapahtumia, mutta palvelupyynnöt pitäisi voida suunnitella.

Problem Management Ongelmanhallinnan prosessia on muutettu taas. Prosessi koostuu nyt kahdesta ”aspektista”, jotka ovat ennakoiva ongelmien hallinta ja reaktiivinen ongelman hallinta. Reaktiivinen ongelmanhallinta on käytännössä sama kuin insidenttien hallinta, pienenä erona että ongelmanhallinta yrittää selvittää insidentin aiheuttajan. Käytännössä nämä ovat samoja prosesseja eli asia ei ole vieläkäään valjennut itilin kirjoittajille.

Ennakoiva ongelmanhallinta on nyt tuotu takaisin sillä se unohtui kolmosversiosta. Virheiden hallinta on edelleen jätetty pois, mutta on vaikea nähdä mitään hyvää syytä tälle poistolle.

Access Management Käyttöoikeuksien hallinta kuvataan omana prosessina, vaikka se on muiden prosessien ylläpitämä palvelu. Palvelu käynnistyy palvelupyynnöstä ja muuttaa konfiguraatiotietoja.

Tuotantoprosessit. Jostain syystä näitä ei kirjassa kuvata prosesseina vaan aktiviteetteina. Ehkä prosessien määrää haluttiin karsia. Tuntuisi loogiselta että esim. Event management voisi olla Monitor ja control –prosessin yksi aktiviteetti mutta näin ei ole. Aktiviteetit ovat:

  • monitor and control
  • IT operations
  • mainframe management
  • server management & support
  • network management
  • storage and archive
  • storage administration
  • database administration
  • directory service management
  • desktop support
  • middleware management
  • internet /web management
  • facilities and data centre management

Organisaatiosta kuvataan Service Deskin lisäksi Technical Management, IT Operations Management ja Application Management. Sovellushallinnan prosesseja kutsutaan ovelasti sovelluksen elinkaaren vaiheiksi (stage, ei löydy sanastosta)

Service deskin kuvaus on vanhanaikainen, faksit ja videot kummittelevat edelleen. Esimerkiksi pääkäyttäjät nähdään vain Service Deskin jatkeena, eikä tajuta että näillä voi olla merkittävä rooli lukuisissa prosesseissa, asiakassuhteen hoitamisesta alkaen.

5 Continual Service Improvement CSI

CSI tuo jatkuvan laadunkehityksen mallin ITILiin. Pink Elephantin kirjoittama kirjaa on muokattu aika paljon. Siitä on poistettu kaksi prosessia ja se kuvaa seitsenvaiheisen ydinprosessin, joka kattaa tiedon keruun. Prosessin vaiheet ovat:

  1. Tunnista kehittämisstrategia
  2. Määrittele mitä mittaat
  3. Kerää tieto
  4. Käsittele tieto
  5. Analysoi tieto
  6. Esittele ja hyödynnä tieto
  7. Suorita korjaavat toimenpiteet

Malli perustuu mittaamiseen ja analysointiin tilanteessa, jossa tietoa on liiankin paljon käytössä. Jatkuva parantaminen nähdään ensisijaisesti mittaamisen ongelmana. Näkökulma on erikoinen. Usein tilanne on toki se, että ongelmat tiedetään liiankin tarkkaan, mutta tarvittaisiin keinoja vaiheen 7 suorittamiseen. Koko kirjassa on kaksi (2) sivua, joissa käsitellään tuota vaihetta 7 eli toiminnan kehittämistä.

Pahinta kirjassa on, että se esittelee oman, päällekkäisen organisaation jatkuvalle kehittämiselle. Suositukseni on, unohda tämä kirja.

6 Arvio

Version 2011 kirjat ovat selvästi paremmat kuin edelliset. On makuasia, pitääkö muutoksia suurena vai pienenä ja ilmeisesti peruskursseihin ne eivät vaikuta, osin siksi että peruskurssit ovat niin pinnallisia.

Hyviä niistä ei ole tullut vieläkään. En suosittele.

%d bloggers like this: