Matti Grönroos

Muutoksen seitsemän ärrää

Merkittävä osa tietotekniikan häiriötilanteista johtuu jonkin muutoksen toteuttamisesta. Tästä kielii muun muassa se, että laatutaso on korkein yleensä silloin, kun asiantuntijaväki on kesälomilla.

Toisaalta, maailma pysähtyy nopeasti ilman muutoksia.

Tasapainoa realiteettien välillä hakee ITILin muutoshallinta, Change Management. Sitä eri organisaatiot toteuttavat vaihtelevalla painoarvolla ja menestyksellä. Siinäkin kultaisen keskitien hakeminen auttaa. Överiksi viety muutoshallinto jäykistää ketterimmänkin organisaation ja yllyttää ihmisiä etsimään menettelyjä kiertää mokoma este.

ITIL auttaa asiaa systematisoimalla muutoksen valmistelua esittämällä muistilistaksi seitsemän R-kirjaimen käytännön.

Muutoksen läpivienti on periaatteessa helppoa:

Teorian ja käytännön ero tässä on kuitenkin mittava.

Vaikein osa muutoshallintoa on vaikutusanalyysi, jonka täydellinen tekeminen on käytännössä mahdotonta. Se edellyttää varsin laajaa ymmärrystä tietotekniikan kokonaisuudesta ja usein myös liiketoiminnasta, jonka tietotekniikka mahdollistaa.

Usein esitetty hokema kuuluu: Eihän tämä vaikuta mihinkään. Jos se ei vaikuta, miksi se sitten tehtäisiin?

ITIL on lanseerannut käsitteen CAB, Change Advisory Board. Terminä se on aika juhlallinen, varsinkin kun se useinkaan ei anna ohjeita, eikä ole johtokuntatasoinen elin. CABille esitetään muutossuunnitelma, joka sitten hylätään, hyväksytään, tai jotain muuta. CAB käytännössä joutuu pitkälti luottamaan valmistelijan esitykseen; sitä enemmän, mitä korkeamman profiilin väestä on kyse. Sen arvo ei olekaan päätöksentekokyvyssä, vaan siinä, että se pakottaa tekemään kunnollisen muutosesityksen.

Muutoksen systematisointiin ITIL tarjoaa työkalun, Seven Rs. Jokaisessa muutoshankkeessa pitää hakea vastaus vähintään seitsemään kysymykseen, joita yhdistää Sumujen Saarten kielen R-kirjain.

Muutoshallinnossakin on syytä välttää yhden koon sukkahousut ‑ajattelua. Pikkuasioihin on hyvä suhtautua kuten pikkuasioihin pitää, ja pääpaino kannattaa pitää suuren riskin muutoksissa.

Muutoksissa usein ITILin pohjalta erotetaan pari poikkeusta: