Toivottavasti insidentin määritelmä korjataan uudessa versiossa.

Huomasin eräässä keskustelussa että jotkut kollegani eivät ole tajunneet ITIL V3 insidentinhallintaan putkahtaneita kömmähdyksiä, olen jopa kuullut väitteitä että V3 sisältää V2 prosessit lähes muuttumattomina. Yritän avata asiaa tässä.

V2 mukaan insidentti on: Mikä tahansa normaalista palvelutoiminnasta poikkeava tapahtuma, joka aiheuttaa tai voi aiheuttaa keskeytyksen tai heikennyksen palvelun laatuun.

V3 lyhennetty määritelmä on sanaston mukaan: Suunnittelematon keskeytys it-palveluun tai it-palvelun laadun laskeminen. Konfiguraation rakenneosan toimintahäiriö, joka ei ole vielä vaikuttanut palveluun on myös insidentti. Esim. yhden peilatun levyn toimintahäiriö.

Näissä määritelmissä on selvä ero. Vanha määritelmä on joustava, sillä se kattaa monenlaiset asiat. Siksi prosessi käännettiin tapahtumanhallinnaksi. Uusi määritelmä edellyttää että jokin häiriö on tapahtunut. Toisin sanoen, jos mitään häiriötä ei ole, ei ole myöskään insidenttiä. Jos näin on niin prosessin nimeksi pitäisi varmaankin vaihtaa häiriönhallinta. Ero on aika suuri.

Tämä ei ehkä ole ollut kirjoittajan tarkoitus sillä alkuperäisestä määritelmästä on jätetty viimeinen lause pois. Kirjan määritelmän viimeisessä lauseessa määritellään koko prosessi ja se on ristiriidassa tuon alun kanssa. Viimeinen lause insidentin määritelmässä kuuluu näin (englanniksi sillä sitä ei löydy suomenkielisestä sanastosta): Incident Management is the process for dealing with all incidents; this can include failures, questions or queries reported by the users (usually via a telephone call to the Service Desk), by technical staff, or automatically detected and reported by event monitoring tools.

Meillä on siis nyt kolme erisisältöistä määritelmää insidentille, V2, V3 alkuperäinen ja V3 lyhennetty ja ongelmallisin on tämä V3 lyhennetty, koska se jättää kaikki näppiksen ja penkin välissä olevat pulmatilanteet kokonaan pihalle. Ne eivät ole insidenttejä eivätkä ne sovi palvelupyyntöjen käsittelyynkään. V3 alkuperäinen on taas sekava ja ristiriitainen.

Uusi V3 määritelmä tuo insidentinhallintaan myös ennaltaehkäisevän toiminnan, tämä nostetaan korostetusti esiin esimerkillä peilatun levyn toimintahäiriöstä. Mielestäni tämä on huono idea. Otetaan esimerkki. Erään yksikön tietoliikenne on hidastunut ja syyksi on havaittu että yksi kolmesta identtisestä rinnakkaisesta tietoliikennelaitteesta on hajonnut. Laitteenvaihto on rutiinioperaatio ja asentaja käy tekemässä sen. Paikanpäällä hän havaitsee toisenkin laitteen vilkuttavan punaista. Hänellä on autossa mukana varalaite. Pitäisikö hänen nyt käynnistää insidentinhallinta esim. soittamalla Service Deskiin tai ottamalla muuten yhteyden insidentinhallintaan?

Pulmaksi tulee se, että nyt sitten pitäisi noudattaa insidentinhallinnan pelisääntöjä. Uusi insidentti ei tietenkään voi ohittaa jo jonossa olevia insidenttejä, joten asentajan pitäisi sitten jatkaa matkaansa. Mielestäni ei ole mitään järkeä käynnistää insidentinhallintaa normaalin rutiinihuollon takia. Toki huoltotoimenpide pitää kirjata, mutta sen voi tehdä jälkikäteen.

Vanhan itilin yksi vahvuus oli siinä, että se ei yrittänyt määritellä tuotantoprosesseja. Siinä on varmasti yksi syy siihen, että itil on ollut niin pitkäikäinen. Itil keskittyi niihin yleisiin prosesseihin, jotka pääsääntöisesti liittyivät palvelun käytettävyyden varmistamiseen ja siitä sopimiseen. Uusi itil yrittää mennä paljon pitemmälle. Peilattu levy on hyvä esimerkki tästä. Vanha itil ei onneksi käsittele reikäkorttien lävistystä ja nauhaoperaatioita, jotka olivat ajankohtaisia 80-luvulla.

%d bloggers like this: