Lue lisää: |
Matti Grönroos
Alkuperäiskansan kielellä termit ovat Incident, Problem, Change, Service Request. Mukaan voisi laskea vielä termin Event, joka on keksitty suomentaa sanaksi "heräte".
Kullakin termillä on oma paikkansa ekosysteemissä, ja paikat käyvät tutuksi kokemuksen karttuessa.
Heräte on periaatteessa mikä tahansa tilanmuutos, jonka on tarkoitus johtaa johonkin toimenpiteeseen. Herätteitä tuottaa yleensä monitorointi, eli järjestelmien tilaa vahtivat ohjelmistot, joka jotain poikkeavaa havaittuaan tuottavat herätteen. Herätteeseen saatetaan reagoida jollain automaattisesti käynnistyvällä toimenpiteellä, se voidaan kirjata tiedoksi lokiin mahdollista tulevaa selvittelyä silmällä pitäen, tai se voidaan näyttää valvomon ruudulla. Jos on oltu fiksuja, herätteen analyysi voi tarvittaessa automaattisesti luoda häiriötiketin tai sen voi valvoja luoda.
Häiriö on mikä tahansa tilanne, jossa järjestelmän toiminta poikkeaa määrityksistä. Häiriönhallinta on tukiprosesseista ehkä näkyvin. Häiriönhallinnan tehtävä on korjata häiriön aiheuttava tilanne, kehittää kiertomenettely, todeta asia sellaiseksi joka ei vaadi toimenpiteitä tai todeta, että häiriötä ei ole mahdollista korjata häiriönhallinnan puitteissa. Yleensä häiriöt jaotellaan vaikutuksensa laajuuden perusteella muutamaan kriittisyysluokkaan, jolle kullekin on omat ratkaisuaikatavoitteensa. Tiketöintijärjestelmä sitten pitää huolen siitä, että tiketit eivät pääse katoamaan.
Yksi yleinen häiriönhallinnan rajanveto on se, että häiriönhallinta ei koske ohjelmakoodiin. Jos koodiin pitää saada muutoksia, se tehdään asianomaisten muutoshallintomenettelyiden kautta.
Ongelma ei ITIL-kielessä ole sanan "häiriö" synonyymi, vaan häiriön syy. Tästä joskus tehdään se johtopäätös, että jokaista häiriötä kohden pitää käynnistää ongelmanhallinta. Tämä ei kuitenkaan ole tarkoitus, vaan ongelmanhallinta ehkä eniten väärin ymmärretty ITILin toiminto. Ongelmanhallinta astuu kuvioihin silloin, kun kyseessä on vaikeasti selvitettävä ja ehkä usean tahon asiantuntijapanosta edellyttävä tapaus tai kun samankaltainen häiriö toistuu kiusallisen usein. Ongelmanhallintaa voidaan tehdä myös ennakoiden, häiriöitä ennalta torjuen.
Ongelmanhallintaan ryhtyminen ei ole läpihuutojuttu, vaan sen takana tulee olla business case. Työ saattaa vaatia huomattavan työpanoksen ja paljon aikaa usealta osapuolelta. Siksi on hyvä luoda kriteerit sille, millä edellytyksillä ongelmanhallintaan ryhtymistä yleensä edes harkitaan.
Toisin kuin tukimallin alemmille portaille painottuva häiriönhallinta, ongelmanhallinta selvästi painottuu asiantuntijatyöhön.
Ongelmanhallinta myös ohjaa itse toimenpiteitä, mutta ei tee niitä itse. Kyseessä ei siis ole muiden prosessien kanssa päällekkäinen toiminto.
Kaaviosta nähdään, että ongelmanhallinta on luonteeltaan usein iteratiivinen silmukka. Silmukkaa toistetaan, kunnes toimenpiteet katsotaan riittäviksi. On hyvä huomata, että ongelmanhallinta ei välttämättä johda mihinkään toimenpiteisiin, vaan päätökseen sietää vallitsevaa tilannetta.
Muutos puolestaan on mikä tahansa muutos tuotantoympäristöön. (Ohjelmakoodimuutokset yleensä käsitellään omien menettelyjen kautta.) Muutoksen hallinnassa on kaksi keskeistä vaihetta, vaikutusanalyysi ja muutoksen tuotantoon viennin suunnittelu. Nämä voivat ajallisesti olla hyvinkin kaukana toisistaan. Kumpaankin liittyy päätöksentekomenettely, jossa joko annetaan etenemislupa tai ei anneta. Muutoksia sitten jaotellaan eri luokkiin kiireellisyyden ja odotettavissa olevien riskien mukaan.
Palvelupyyntö nähdään usein häiriönhallinnan sisarprosessina, koska sekin pohjautuu tiketteihin ja yleensä samaan tiketöintijärjestelmään. Kyse on ehkä kuitenkin sisarpuolesta tai serkusta; läheisyys on monesta syystä näennäistä.
Yleisesti, palvelupyyntö on mikä tahansa asia, jota käyttäjä pyytää IT-organisaatiolta. Se voi olla standardipyyntö, eli jokin valmiiksi paketoitu asia. Riippuu aivan organisaatiosta, millaisia asioita se haluaa tuottaa palvelupyyntöinä. Samoin on organisaatiokohtainen asia, veloitetaanko pyynnöistä, vaativatko ne esimiehen tai jonkin muun tahon hyväksynnän ja mikä niiden toimitusaika on.