Matti Grönroos

Monitoimittajatikettien ohjaus

Häiriönhallintaan ja palvelupyyntöihin liittyvät tiketit saattavat elinkaarensa aikana hypätä vastuullisesta tiimistä toiseen useita kertoja. Tämä on sinänsä normaalia, koska tapaus saattaa edellyttää usean osapuolen toimenpiteitä.

Tikettihyppelyä pitää kuitenkin ohjata ja valvoa.

Se, kuinka paljon kullekin toimijalle annetaan aikaa tiketistä huolehtimiseen, on yleisesti ratkaisematon kysymys. Jos koko tapauksen ratkaisuaika on vaikkapa kahdeksan tuntia, jokaisen osa-askeleen pitää suoriutua tehtävästä oleellisesti nopeammin.

Yksinkertaisimmillaan häiriöilmoitus tai palvelupyyntö johtaa "ilmoita-ratkaise-kuittaa" ‑malliin, jossa tiketti ratkaistaan yhdessä vaiheessa.

Tavanomaista kuitenkin on, että tiketti kulkee usean tiimin kautta, joko analysoitavana tai toimenpiteitä varten tai sekä-että. Kun siirtymisiä, "hyppyjä" on paljon, nousee riski siitä, että tikettiä ei saada ratkaistuksi tavoiteajassa.

Eritoten monitoimittajaympäristössä palvelusopimukset on aiheellista laatia siten, että hyppelymahdollisuus otetaan huomioon. Yksinkertaisimmillaan tämä on sitä, että palvelutoimittajien toimitusaikatavoitteiden tulee olla olennaisesti lyhyempiä kuin mitä on palvelunsaajien suuntaan sitouduttu. Jos esimerkiksi yllä olevassa kaaviossa kokonaistavoite on kahdeksan tuntia, palvelutoimittajille ei tietenkään voi antaa kahdeksaa tuntia kullekin. Sekin on otettava huomioon, että tiketin siirtymiseen palvelutoimittajalta toiselle kestää aikansa jo pelkästään teknisistä syistä.

Mitään yleispätevää ratkaisua tähän ei ole. Viime kädessä kyse on tilastollisesta riskianalyysistä, jossa arvioidaan sitä, kuinka usein sattuu tilanne, jossa palvelutoimittajat tarvitsevat yhteensä aikaa enemmän kuin mihin on palvelunsaajan suuntaan sitouduttu.

Yksi ratkaisumalli on, että kukin vastaa vain omastaan. Tällaisten palvelusopimusten aika vain tuntuu olevan ohitse.

Varsin tärkeää on istuttaa joku vastuuseen "tikettitehtaan" työnkulusta: seuraavalla etenemistä, tunnistamalla pompottelu ja puuttumalla ennen kuin on myöhäistä. ITIL tuntee roolin nimellä "incident manager". Rooli sopii esimerkiksi service deskin tai SIAM-operaattorin harteille.