Itilin virheet

Juttuni itil-managereiden potkuista on herättänyt poikkeuksellisen paljon huomiota ja jopa keskustelua Pohjoisviitan sivuilla, joka on melko harvinaista. Viime perjantaista tuli uusi ennätyspäivä WordPressin liikennetilastojen mukaan. Huomautan, että minä en suositellut itil-managereiden erottamista, ainoastaan referoin mitä Charles Betz sanoi esityksessä, eikä hänkään suositellut sitä, hän vain kertoi mitä eräs pankki oli tehnyt.

Lupasin eräälle kommentoijalle tehdä yhteenvedon itilin virheistä. Ehkä voisin aloittaa sittenkin luettelemalla itilin hyötyjä. Itil on parempi kuin ei mitään, jokin kehikko on hyvä olla, sillä sen avulla on helpompi keskustella aiheesta ja on hyvä joutua pohtimaan it-palvelujen tuottamista. Prosesseilla voidaan saada asioita haltuun, on tärkeää priorisoida asioita ja muutoksia pitää hallita. Itil voi toimia, jos sen soveltamisessa käytetään paljon järkeä ja arvostelukykyä, osataan tehdä itsenäisiä ratkaisuja eikä jäädä väittelemään siitä mitä itil sanoo. Itil tarjoaa terminologian ja vaikka se on vähän horjuva, on se parempi kuin ei mitään.

No sitten luettelo itilin virheistä. En takaa, että tämä on kattava mutta yritän listata tärkeimmät.

  • Turhat prosessit. Itil kuvaa liikaa päällekkäisiä prosesseja. Lukuisten prosessien pyörittäminen johtaa helposti siiloutumiseen, jossa jokainen prosessi keskittyy oman alueensa hoitamiseen ja kokonaisuus kärsii. Turhat prosessit tuottavat taas turhaa työtä ja luovat keinotekoisia raja-aitoja.
  • Integraation puute. Kuten Jarkko Hedman kommentoi tätä, ”ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin.”
  • Toiminnot prosesseina. Itil kuvaa suuren joukon asioita prosesseina, vaikka ne eivät mitenkään omaa prosessin ominaisuuksia. Esimerkiksi saatavuuden ja jatkuvuuden varmistaminen ovat suunnittelua, joka vaatii osaamista. Prosessien kuvaaminen ja keinotekoisten tapahtumien kirjaaminen on turhaa työtä ja tuottaa turhia raportteja.
  • Sertifioidut asiantuntijat. Itil sertifikaatit hankitaan vastaamalla monivalintakysymyksiin, joissa oikean vaihtoehdon tietäminen perustuu muistiin. Kuulopuheiden mukaan osa kouluttajista antaa kysymykset etukäteen ja kertoo niiden oikeat vastaukset. Joka tapauksessa sertifikaatti ei kerro mitään omistajansa kyvyistä palveluhallinnan alueelta. Pahimmillaan sertifioitu asiantuntija ajaa järjettömiä ratkaisuja vedoten siihen, että itil sanoo näin, vaikka kyseessä on k.o. ”asiantuntijan” itse keksimä ja täysin virheellinen tulkinta siitä mitä itil ehdottaa.
  • Virheellinen palvelukäsite. Tämä on aika laaja aihe. Lue keskusteluni Akin kanssa.
  • Häiriöhallinta. Itilin suositus syöttää event managementin eli automaattisen valvonnan kautta tulleita häiriöilmoituksia asiakastuen kirjausten sekaan on järjettömyyden huippu. Asiakastuki on aivan eri asia kuin tekninen valvonta.
  • Ongelmanhallinta on rinnakkainen prosessi häiriönhallinnan kanssa. Saman asian tekeminen kahdessa eri vaiheessa on turhaa. Uusiutuva häiriö on liian aikaisin suljettu häiriö. Sotku johtuu siitä, että asiakastuki ja häiriönhallinta on nivottu yhteen.
  • Jatkuvan palvelunkehittämisen (CSI) mittaripainotteisuus on virhe. Painopiste on toiminnan tuloksellisuuden kehittämisessä, ei prosessien tehostamisessa.
  • En viitsi edes repostella turhien prosessien vikoja, sillä enemmistö itilin prosesseista on turhia.

Mielestäni tässä on aivan riittävästi syitä hylätä suurin osa itilistä.  Mitä sitten tilalle? Se on vaikea kysymys. Olen nähnyt lukuisia vaihtoehto-tarjokkaita, mutta mikään niistä ei ole vakuuttanut. Olen myös osallistunut useampaan yritykseen luoda jotain vaihtoehtoista, mutta kaikki hankkeet ovat luovuttaneet.

11 vastausta

  1. Kiitos mielenkiintoisesta artikkelista! ITILissä itseäni häiritsee erityisesti lukuisat päällekäiset prosessit ilman selkeästi kuvattua integraatiota. ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin. IT4IT oli piristävä uutuus ja poistaa puolet mainitsemistasi virheistä. (En aio kuitenkaan vielä piilottaa vaivalla hankkimiani ITIL-sertifikaatteja.)

    • Moi, ihan hyvää pohdintaa kolikolla on aina kaksi puolta ja sitten kun kolikkoja on paljon niin tapoja toimia on yhtä paljon kuin yrityksia. Oma pointti on aina ollut että ITIL tarjoaa yhteisen sanaston/termistön tämä seikka tuo keskeisen lisäarvon IT prosessimaailmaan. Loppu käytännön työ siis ITILin soveltaminen kannattaa jättää meille ITIL/prosessi-ammattilaisille.

  2. Mielenkiintoista, mikä on todennäköisyys että molempien kommentoijien nimi on Jarkko 🙂

    Tuo Jarkko H:n mainitsema integraation puute on niin hyvä kommentti, että pitää lisätä se listalle.

    Jarkko L:n kanssa olen jokseenkin samaa mieltä. Ainoa ryppy tuossa on se, että itilin terminologia on vähän horjuvaa ja se aiheuttaa väärinkäsityksiä. Päivitän tekstiä myös hyötyjen osalta.

    Kiitokset hyvistä kommenteista.

  3. Mielestäni on järkevää, että Incident ja Problem Management on
    tunnistettu omiksi osa-alueikseen. Häiriön (Incident) sattuessa
    on tärkeää saada ongelmatilanne mahdollisimman nopeasti ratkaistua mutta ratkaisu voi olla ns. tilapäinen. Häiriön varsinaisen juurisyyn ja sen korjaaminen vaatii yleensä tarkempaa analyysiä ja toimenpiteitä, joita ei ole aina mahdollista/järkevää lähteä heti tekemään, jos ns. pikakorjaus ongelmaan on saatavissa.

    Incident voidaan siis ratkaista asiakasta tyydyttävällä tavalla ja Inc
    sulkea vaikka ongelman juurisyy on vielä olemassa (ja tätä varten luodaan tarvittaessa Problem).

    • Joo, olen pitänyt lukemattomia ITIL-kursseja Foundationista Service Manageriin ja toki olen juuri noin opettanut. En enää. Tuosta puuttuu asiakaspalvelu ja asiakkaan pulman ratkaisu. Häiriön pikakorjaus on osa ongelman ratkaisua ja niiden erottaminen eri prosesseiksi on keinotekoista.

  4. Puutun myös ongelman- ja häiriönhallintaan. Mielestäni on hyvä nosto tuo asiakaspalvelun ja teknisen häiriön ratkaisun erottaminen toisistaan – innostuin jopa katselemaan pari vuotta sitten nauhoitetun Brighttalkin webcastisi aiheesta. Vastaavanlaisia käytännön implementaatioita olen jonkun verran nähnytkin asiakkailla, mutta eikö tuossa ole myös se vaara, että asiakaspalvelusta muodostuu helposti kädetön call center, joka ei tee muuta kuin kirjaa tikettejä tekniselle porukalle ilman varsinaista lisäarvon tuottamista asiakkaalle (ts. nimenomaan sen pulman ratkaisua luovalla tavalla)? Jos tämä on relevantti ongelma, niin mitkä ovat vinkkisi sen estämiseen? Entä onko sinulla jotain hyviä käytännön esimerkkejä, joita voisit avata ja joissa on saatu tuotetuksi aitoja hyötyjä tällä mallillasi?

    • Hei Jussi V
      Tuo oli hyvä kysymys ja täytyi vähän miettiä mitä vastaisin. Kyllä tavoitteena on edelleen se, että asiakaspalvelu ratkaisee lähes kaikki asiakkaan ongelmat itse. Tekniselle porukalle niitä pitäisi mennä harvoin. Tämä edellyttää että aitoja teknisiä häiriöitä, jotka havaitaan asiakkaiden ilmoitusten perusteella, on aika harvoin. Pitää siis olla hyvä monitorointi ja ennaltaehkäisevät toimet. Silloin asiakkaiden ongelmat ovat enemmän ’miten tämä tehdään’ -sarjaa ja johtuvat osin nopeasta kehityksestä ja uusien välineiden käyttöönotoista.

  5. Eikös tuo sinun ja Akin keskustelu (virheellinen palvelukäsite) ole suoraan IT4IT:sta, eikä teidän omaa pohdintaa niinkään?

Vastaa

Please log in using one of these methods to post your comment:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google photo

Olet kommentoimassa Google -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggers like this: