Tarkoituksena artikkelissa ei ole arvostella ICT-palvelunhallinnan kehysmalleja kuten ITIL ja COBIT, eikä tuoda esiin niiden epäkohtia. Huomiota kaipaa mielestämme enemmän tapa, jolla malleja jalkautetaan organisaatioissa. Syitä ottaa eri palvelunhallintamalleja käyttöön on monia. Yleisimpinä ovat laadunparannus ja kustannusten lasku, koska uskomuksen mukaan prosessinmukainen tekeminen luo tehokkuutta. Yleinen muotti on, että yrityksen kehityspäällikkö lähetetään suorittamaan ITIL-sertifiointeja ja liittymään aihetta koskeviin verkostoihin, jotta yrityksen ponnistukselle saadaan uskottavuutta, näkyvyyttä ja vertaistukea. Huom. tässä ei ole mitään väärää, esim. itSMF on yhdistys, joka auttaa yrityksiä palvelunhallinnan alueilla, tarkoituksenaan yhteistyön edistäminen, tiedonjakaminen sekä tutkimustoiminta.
Kun ensimmäinen osaamisvalidointi on suoritettu, tulee kehityspäällikön aloittaa mittava kehysmallin implementointi ja kouluttaminen. Tietenkin kaikki toiminnot kerralla ja ”by the book”, että mitään ei varmasti jää välistä ja voidaan sanoa, että meillä on ITIL kokonaan käytössä. Ensimmäiseksi mietitään mistä saadaan jokaiselle toiminnolle ja prosessille omistaja. Kun todetaan, että kustannus nousee liian kovaksi rekrytoimalla, aletaan organisaatiosta nimittää ja kouluttaa henkilöitä oman tehtävänsä ohella ko. tehtäviin. Talo alkaa täyttyä uusista managereista ja vanhojen tehtäväsisältö tulee samalla prosessoitua uudelleen. Tulee change manageria, problem manageria, risk, capacity, availability manageria jne. Joku vähemmän onnekas saattaa saada useamman hatun samalla kertaa. Ei muuta kuin kick off -bileet käyntiin ja käyntikortteihin uudet tittelit.
Hallitse palveluitasi tai ne hallitsevat sinua
No niin, ITIL on nyt implementoitu. Nyt vain odotetaan, että tehokkuus ja palvelutasot nousevat räjähdysmäisesti ja että kustannustaso laskee vielä jyrkemmällä käyrällä. Tässä vaiheessa kehityspäällikkö tuskailee, koska hänestä tuntuu, että organisaatio ei ymmärrä muutoksen tarkoitusta, eikä ainakaan sitoudu siihen vaaditulla intensiteetillä. Prosessinomistajat kyynistyvät todetessaan, että heidän prosessiaan ei ymmärretä saati noudateta. Jokaisella henkilöllä yrityksessä tuntuu olevan oma näkemyksensä siitä kuinka projekti olisi oikeasti pitänyt hoitaa, jotta tuotantovaiheessa asiat toimisivat oikein.
Totuus usein iskee hyvin lyhyellä varoitusajalla. Tehokkuus laskee, tuotantokustannukset nousevat, virheiden määrä kasvaa, ihmiset turhautuvat, henkilöstötyytyväisyys laskee radikaalisti. Organisaatio alkaa pahimmillaan palata kohti tilaa, josta alunperin lähdettiin liikkeelle. On vaikeaa ymmärtää miksi, koska projekti oli hieno ja iso, rahaa paloi paljon. Nyt kuitenkin aikaa kuluu uusien toimintatapojen opetteluun, jotka jostain syystä tuntuvat paljon raskaammilta ja joita kukaan ei tunnu oikein tajuavan. Lisäksi tulevat vielä lukuisat palvelupalaverit. Näissä usein kutsuttuna ovat suurelta osin väärät henkilöt ja yleiseksi mielipiteeksi käytäväkeskusteluissa muodostuu palaverien ja prosessien turhuus sekä tietenkin se, kuinka asiat olisi pitänyt hoitaa. Palavereista tulee hiljaisia ITIL-retriittejä, joissa prosessinomistajat alkavat etsiä työhönsä uutta suuntaa internetin työvoimapalveluiden parista.
Vauhdikas tietomassavyöry
Liian paljon, liian nopeasti, vääristä lähtökohdista ja vähäisin resurssein. Tutkimusten mukaan ihminen vaatii keskimäärin noin 15 toistokertaa oppiakseen ja sisäistääkseen uuden asian. Edellyttäen, että hän ymmärtää miksi hänen täytyy oppia, hänen täytyy olla myös kiinnostunut aiheesta, lisäksi oppimiselle tulee olla tarpeeksi aikaa sekä häiriötön ympäristö. Kuinka monella nämä edellytykset toteutuvat työelämässä, ainakaan kaikki kerralla? Esimerkkinä ITIL v3 pitää sisällään 4 perspektiiviä palvelujohtamiseen, 4 suurta palvelutuotannon toimintoaluetta, 5 palvelutuotannon keskeistä pääprosessia (joilla omat lukuisat aliprosessinsa). Näiden lisäksi on vielä useita konsepteja palveluiden laadunvalvontaan, kehitykseen, hallintomalleihin, toimintojen ja prosessien riippuvuuksiin jne. Vakiomauste edellä mainituille on ihmiselle luontainen muutosvastarinta, jota hyvä viestintä tosin liennyttää, mutta koskaan se ei kokonaan katoa. Ihan vaikka periaatteen vuoksi.
Paloittele, pilko, osita
Mieti mitä yrityksesi todellisuudessa tarvitsee palveluidensa hallintaan. Tee sitten riittävä realistinen analyysi odotuksista, joita sinulla on aikataulua, saavutuksia ja lopputulosta kohtaan. Kaikkea et tarvitse, et ainakaan kerralla. Kehysmallit ovat hyviä käytäntöjä, jotka täytyy jalostaa parhaiksi käytännöiksi jokaiselle yritykselle erikseen. Perehdy toimintojen ulkoistusmahdollisuuksiin. Usealla palveluntarjoajalla kehysmallien jalkautus on hyvällä tolalla ja ne pystyvät myymään mallin mukaisesti hallinnoituja palveluja (lue kuitenkin ensin kirjoituksemme Paras sopimus, mutta kenelle?). Älä tee kehysmallien jalkautusta siitä syystä, että muutkin tekevät niin, vaan etsi konkreettiset syyt, joilla saat itsellesi aitoa hyötyä.
Etsi ensin nykyisen toimintatapasi ongelmakohdat ja määrittele tavoitteet. Sen jälkeen kartoita kehysmallien tuomat käytännöt, joilla toimintaasi saisi tehostettua. Älä lähde kriittisimmästä liikkeelle. Testaa ensin organisaatiosi kykyä uusien mallien jalkauttamiseen ja anna henkilöstölle riittävä aika ymmärtää viesti, tarkoitus ja päämäärä. Kysy ensin heiltä missä he näkevät ongelmat ja selvitä eri ongelmien riippuvuudet. Joskus todellisen ongelman vaikutukset näkyvät aivan eri paikassa, eikä niitä siksi osata korjata.
Kolikot on helppo kaataa ämpärillä kaivoon ja esittää suuria toiveita. Palvelunhallinnan parannuksien ja investointien lähtökohdat, tavoite, toteutustapa ja aikaväli tulee kuitenkin olla realistinen. Muuten saatat joutua kaivamaan kolikoitasi takaisin vielä pitkään.
