Itilin karikot v2

Tämä juttu ilmestyi aikanaan seminaarin esitteenä ja on edelleen suosituin kirjoitukseni. Olen nyt päivittänyt sen ja tuon sen muiden artikkelien joukkoon.

Monet itilin soveltajat ovat huomanneet, että itilin parhaita käytäntöjä on joskus vaikea soveltaa käytäntöön. Itil sisältää paljon neuvoja, joita ei ole testattu tai jotka ovat yksinkertaisesti väärin. Jan van Bon, joka on toimittanut useita IT Service Management -kirjoja kuvaa, kuinka ITSM Libraryn kirjoista koitettiin jättää virheet pois jättämällä virheellinen teksti pois, mutta tilaaja yleensä pakotti heidät lisäämään virheet takaisin.

Missä sitten ovat itilin karikot. Tein aiheesta kyselyn  ja olen nyt täydentänyt sitä uusilla havainnoilla, jotka kattavat sekä kakkos- että kolmosversion.

Kokonaisuuden hallinta

Olen lukenut ja kuullut paljon kommentteja siitä kuinka kakkosversio käsittelee vain prosesseja ja kolmosversio korostaa palveluja. Itse en ole koskaan mieltänyt etteikö jo kakkosversion prosessit tuottaneet palveluja. Tärkein tavoite on pitää palvelut pyörimässä ja vältää asiakkaita häiritseviä katkoja ja häiriöitä. Luulen että monille Itil on sitä miten se on opittu kursseilla ja siksi siitä on paljon tulkintoja.  Selvää on, että kakkosversio yrittää opettaa miten olemassaolevat (staattiset) palvelut pitää tuottaa ja kolmosversio yrittää tuoda tähän koko palvelun elinkaaren hallinnan.

Kumpikin versio käsittelee johtamista puutteellisesti. Itil luo haastavan matriisiorganisaation, mutta ei kerro miten sen luomat konfliktit pitää hoitaa. Itil käyttöönotto lässähtää ilman johdon aktiivista roolia, mutta johdon roolia ei kuvata. ISO 20000 on paljon parempi tässä mielessä.

Kolmosversion strategialähtöisyys toimii lähinnä ulkoisella palvelutuottajalla. Tiukasti asiakkaiden ohjauksessa toimivan infra-palvelun on turha satsata liikaa resursseja hienojen strategioiden suunnitteluun.  Päättäjillä on harvoin aikaa istua itil-kursseilla. Kolmosversion kokonaishallinnan mallin suurin heikkous on siinä, että se ei kiinnosta niitä ihmisiä, jotka tekevät päätökset. Pahimmassa tapauksessa päättäjä innostuu konsultin pikaisen PP-sulkeisten jälkeen ja käynnistää prosessien käyttöönoton, mutta ei ehdi selvittää omaa rooliaan eikä ota huomioon prosessien toimintatapoja omissa päätöksissään.

Suomessa niin tavallinen monitoimittajaympäristö on käsitelty heikosti. It-palvelun rooli nähdään keskeisenä pelurina, joka ohjaa palvelukehitystä ja pitää toimittajat kurissa SLA-sopimuksin. Todellisuudessa liiketoiminta tekee itsenäisiä päätöksiä ja ostaa it-palveluja haluamaltaan taholta. IT-palvelutoimittaja on vain yksi alihankkija laajemmassa kokonaisuudessa. Tämä ei mitenkään poista it-palvelunhallinnan tarvetta, mutta se tuo siihen paljon haasteita, joita itil ei käsittele.

Käyttöönoton ja kehittämisen pulmat

Tämä on iso haaste jota ei tuoda riittävän hyvin esille. Kakkosversion Planning to Implement Service Management antaa hyviä neuvoja, mutta sitä ei kouluteta. Itil-kirjoissa puhutaan hyvin vähän muutoksen aikaansaamisesta ja siitä, kuinka kaikki lähtee ihmisten asenteista. Kolmosversion CSI-kirja on lähes koominen tässä suhteessa. 7-step mallin mukaan riittää kun raportoi virheet, niin voi tehdä korjaavat toimenpiteet. Mallin mukaan haasteet ovat mittaamisessa ja tiedonkäsittelyssä, vaikka todellisuudessa on yleensä kyse ihmisten asenteista ja käyttäytymisestä.

Prosessin käyttöönoton ja kehittämisen suurin haaste on saada ihmiset muuttamaan tapaansa tehdä töitään.  Ihmiset pitää pystyä vakuuttamaan siitä, että uusi tapa on parempi heille eikä siihen liity haittoja tai vaaroja. Sen jälkeen heitä pitää valmentaan toimimaan uudella tavalla ja toimintaa on jaksettava seurata ja ohjata tarvittaessa. Positiivinen palaute on tärkeää. 

Asiakastuki

Service Desk on käsitelty ohuesti ja asiakassuhteen hoito puuttuu kokonaan. Palvelutasonhallinta on kapea osa asiakassuhdetta.  Tämä on se rajapinta, jossa suurin osa päätöksistä tehdään. Asiakas ja palvelutoimittajan yhteyshenkilö keskustelevat ja sopivat muutokset. Itil-prosesseista vastaavia henkilöitä ei oteta välttämättä edes mukaan kokouksiin.

Muutoksen ja konfiguraationhallinta

Muutoksenhallinnan rooli ja toiminta-alue on itilin mukaisena liian laaja. Jos business omistaa sovellukset ja teettää muutokset alihankkijalla niin alistaako se päätöksensä konehuoneen muutospäällikölle? Mikä on oikeastaan järkevä muutoksenhallinnan rooli? Itil ja ISO 20000 antavat muutoksenhallinnalle hyvin keskeisen roolin, mutta se vaikuttaa hyvin epärealistiselta. Muutoksenhallinta pitää pilkkoa alueisiin ja rajata järkevästi. Varsinaisella tuotekehityksellä on omat prosessinsa. Google haku ”product development process” tuo 750 miljoonaa osumaa, ”itil process” 0,5 miljoonaa osumaa. ”Change Management” antaa 128 miljonaa hittiä mutta jos hakuun lisätään sana itil, putoaa osumien määrä alle 0,4 miljoonaan.

Alkuperäinen CI:n määritelmä on sekava, kolmosversio on tässä paljon parempi. Tiketit ja muutospyynnöt eivät ole CI:tä. Suuri osa konfiguraationhallinnan hyödyistä saavutetaan omaisuudenhallinnalla ja tässäkin kolmosversio on parempi kun se pilkkoo nämä kahdeksi eri prosessiksi. Läheskään kaikkia assetteja ei tarvita CMDB:ssä, riittää kun tietää mihin palveluun eri pääkomponentit liittyvät.

On hyvä kysymys kannattaako CMDB:hen panostaa? Itilin kuvaama CMDB, joka kattaa kaikki CIt ja niiden riippuvuudet, on haastava tavoite. Kolmosversion modulaarinen CMS on ehkä järkevämpi kuin kaiken nielevä CMDB mutta tähän ei kannata mennä väline edellä. CMS tai CMDB ovat turhia, jos muutoksenhallinta ei ole kunnossa ja palveluluettelo ajantasalla. 

Prosessit, aktiviteetit ja puuttuvat funktiot.

Itil kyllä määrittelee prosessin mutta ei noudata omaa määritelmäänsä. Monet itilin prosessit eivät ole prosesseja vaan vastuualueita eli funktioita. Event Management ei ole prosessi vaan tuotannon valvonnan aktiviteetti. MOF puhuu prosessien sijaan Service Management Funktioista, joka on kyllä parempi ratkaisu.

  • Insidentin ja ongelman lajit ovat liian yksinkertaisia, itilistä puuttuu tarpeellisia luokkia kuten esim. asiakaspalaute, reklamaatio, vika.
  • Konfiguraationhallinta on funktio, jolla on joukko aktiviteetteja.

 Itil koulutus ja sertifikaatit

Ehkä pahin ongelma uudessa itilissä on sen häikäilemätön rahastusmentaliteetti. Monimutkainen koulutusjärjestelmä ei palvele kenenkään muun kuin koulutus- ja sertifiontibusineksen etuja. Huonosti laaditut monivalintatentit eivät mittaa osaamista, erityisesti ylemmän tason practitioner ja expert sertifikaatit eivät kyllä mittaa mitään muuta kuin löyhää johtamista. Jos organisaatiolla on resursseja kouluttaa ihmisiä V3 Practitioner ja Expert tasoille, sillä on liikaa resursseja. 

Uusi ohjelmistosertifikaatti jatkaa samalla linjalla, se on yksinkertaisesti rahastusta, jonka loppukädessä maksavat asiakkaat.

Mitä järkeä Iitilissä sitten on?

Tästä voisi helposti vetää sen johtopäätöksen, että Itilissä on niin paljon vikoja, ettei siitä ole mitään hyötyä.  Näin ei ole, itil sisältää paljon hyvää ja käyttökelpoista materiaalia mutta sitä pitää soveltaa. SD, insidentin -, ongelman-, konfiguraation, muutoksen-, jakelun- ja palvelutasonhallinta ovat asioita, joiden pitää toimia ja niistä itil antaa hyviä ohjeita. Valitettavasti joiltakin osilta V2 on parempi ja joiltakin osilta V3. Nämä ovat prosesseja, jotka koskettavat kaikkia palvelutuotannossa. Kaikki muut prosessit (= funktiot) ovat ehkä yleissivistäviä, mutta niiden opiskeluun ei kannata käyttää paljoa aikaa, elleivät ne kuulu omalle vastuualueelle.  

 

%d bloggers like this: