Muutos – sen johtaminen ja hallinta
IT Service Management Symposium 2005, Royal at Crowne Plaza, Helsinki 6.10.05
Artikkelin on kirjoittanut Eija Kalliala. (Symposiumin esitykset ovat itSMF:n verkkosivuilla (http://www.itsmf.fi/) kirjautuneiden käyttäjien nähtävillä).
Symposiumin avauspuheessaan itSMF Finland’in puheenjohtaja Jaakko Kuosmanen kysyi organisaatioiden kokemuksia ITIListä (Information technology infrastucture library): Mitä on opittu? Millaisiin sudenkuoppiin on törmätty ja miten niitä voitaisiin välttää?
ITILin ytimen muodostavat palvelun jakelu (service delivery) ja palvelun tuki (service support). Miten nämä viedään organisaatiossa varsinaiseen toimintaan? Miten it-palvelujen hallinta tuo lisäarvoa bisnekseen? ITIL voisi tarjota hyviä työvälineitä esimerkiksi kunnalliselle sektorille yhteiseen työskentelyyn.
ITIL-sanasto on ilmestynyt suomeksi viime kevään aikana. Muutamat suuret yritykset haluavat käyttää suomenkielisiä termejä, joten oli järkevää kääntää termistö kerralla eikä antaa sen paisua erilaisin käännösversioin.
ITIL on lähtöisin Englannista ja levinnyt nopeasti pariinkymmeneen maahan, mm. Intiaan. Yhdysvalloissa se on de facto -standardi, joten siellä hiljan pidetyssä seminaarissa pohdittiin ITILin käyttöönottoa ja sen aikataulua.
Ken Turbitt, BMC Softwarelta kysyi, kontrolloitko muutosta vai kontrolloiko muutos sinua. Muutokseen pitää reagoida päivittäin, ja se onnistuu, kun suunnitelmat ovat kunnossa. Esimerkkejä päinvastaisesta tilanteesta on liikaakin: Kun uusi järjestelmä ei toimi, liiketoiminta pysähtyy. Huono verkkopalvelu taas on lahja kilpailijalle.
Liiketoiminta ja IT liittyvät olennaisesti toisiinsa. Niiden yhteys arvoidaan liiketoiminnan näkökulmasta. Tapahtumaimpulssit lähtevät liiketoiminnasta, jota IT tukee. Julkisivun ja verkkopalvelun taustalla ovat yrityksen tukijärjestelmät. Jos ne eivät toimi, ei julkisivukaan toimi. Menestyksen salaisuus on kaikkien prosessien vaiheistus ja hallinta.
Ken Turbitt vertasi ITILin käyttöönottoa sairaan potilaan hoitamiseen:
1. Vakiinnuta potilaan tila hallitusti.
2. Etsi heikot kohdat ja määrittele, millä on vaikutusta potilaaseen.
3. Huolehdi siitä, että standarditilanteet ovat hallinnassa.
4. Paranna prosessia jatkuvasti.
Ken Turbitt näytti videon kolmesta vaihtoehtoisesta uuden järjestelmän käyttöönottotilanteesta: ensimmäisessä järjestelmävirhe aiheutti kaaoksen, toisessa kuvaukset auttoivat tilanteen hallinnassa ja virhetilanne korjattiin ilman paniikkia, kolmannessa virhettä ei edes syntynyt, kun kaikki tehtiin suunniteltujen prosessien mukaisesti. Video konkretisoi, mutta myös liioitteli kuvausten merkitystä.
Timo Knuuttila WM-datalta totesi, että oman muutoksen hallinta on helpompaa kuin organisaation koko henkilöstön muutoksenhallinta. Hän kysyi osuvasti: ”Change people or change people?” eli: Muutetaanko ihmisiä vai vaihdetaanko heidät?
Johtamisen haasteita ovat moniasiakas- ja monitoimittajaympäristö, mittaaminen ja päätöksenteon edellytykset sekä muutoksen johtaminen. Miten nykyisestä toimintatavasta siirrytään uuteen, miten motivoidaan ihmisiä, mitkä ovat heidän roolinsa ja tehtävänsä? Epäjatkuvuuskohdissa mitataan johtamisen onnistuminen.
Ihmiset ovat haastavin osa ITILin käyttöönottoa. Miten nyökyttelystä päästään toimintaan? Miten vähennetään henkilöriippuvuutta ja kuitenkin otetaan huomioon yksilöt ja heidän asiantuntemuksensa?
ITILin käyttöönotossa tarvitaan heikkojen signaalien tunnistamista, tiedotusta ja koulutusta. Työvälineitäkin tarvitaan, mutta ne eivät muuta ihmisten työtapoja toisin kuin Turbittin videossa esitettiin.
Tavoitteiden pitää olla haastavat, mutta realistiset. Henkilökohtainen sitoutuminen ja sen johdolta saama tuki on ensisijaisen tärkeää.
Timo Knuuttila painotti, että paras johtamis- ja kehittämiskeino on oma esimerkki. Sertifikaatteja tärkeämpää on ymmärtää, mistä on kysymys.
Juha Vanonen Kelan kolmen vuoden ITIL-kokemuksella painotti, että prosessit ovat tärkeitä, eivät välineet. Palvelunhallinta näkyy käyttäjille, järjestelmänhallinta toimii taustalla. Ongelmatilanteissa on turha odottaa ”deus ex machinaa”: ongelmat on aiheutettu itse ja ne pitää myös itse korjata – kuten kahdenkymmenen vuoden ajan on tehty.
Muutosta ei pitäisi tuoda taloon niin, että ensin tehdään päätös ja sitten ruvetaan motivoimaan ihmisiä. Parempi olisi selvittää ensin perustelut ja käsitellä niitä yhdessä. Muutoksen perustelujen pitää olla olemassa ennen eikä vasta jälkeen päätöksenteon.
Miten toimintaa voitaisiin kehittää proaktiivisesti?
Vakiintuneessa organisaatiossa, jossa samat ihmiset ovat pitkään tehneet samoja töitä, ohjeistus on usein kirjoittamatta vain nahkakansien sisällä: riittää, kun itse hallitsee hommat. Tällöin yhdelle ihmiselle sälytetään liian suuri vastuu. Uudet työtavat edellyttävät muutosta.
ITIL-prosessien käyttöönotossa kartoitetaan ensin nykytila, sitten määritellään tavoitteet ja sitoudutaan niihin. Johdon sitoutuminen on ehdottoman tärkeää. Jos joku neljästäsadasta työntekijästä epäilee, sillä ei ole niin suurta merkitystä kuin sillä, että yksi kahdestakymmenestä pomosta epäilee.
Juha Vanonen näytti Qualitus Fennicasta poimimiaan muutosvastarinnan lauseita, jotka kuvastavat pelkoa luopua tutusta ja turvallisesta kuviosta ja ihmettelyä siitä, mitä hyötyä uusi toisi tullessaan:
* Miten muutos vaikuttaa asemaani?
* Muutos ei ole sen suuntainen, mitä haluaisin.
* Miten täytän muutoksen mukanaan tuomat vaatimukset?
* Jos en onnistu, menetänkö uskottavuuteni?
* Tuon kaverin puheisiin en ole ennenkään luottanut.
Työmenetelmät ovat eri asioita kuin prosessit. Työmenetelmät voivat olla hyviä, mutta jos ne ovat irrallisia, eri tiimit puuhastelevat eri asioiden parissa toisistaan tietämättä. Prosessit syntyvät vasta kun yksittäiset työmenetelmät yhdistetään.
Muutostilanne saattaa tuntua elefantin syömiseltä.
Juha Vanonen kyseenalaisti ajatuksen tapahtumahallinnan (incident management) hajauttamisesta niin, että jokainen työntekijä kirjaa välineeseen havaitsemansa poikkeamat. Haluaako jokainen työntekijä sen tehdä, kun se oman työn kannalta on vain ylimääräistä tekemistä? Jos poikkeamien kirjaaminen olisi keskitetty, kirjaus sujuisi paremmin, koska tekijä tuntisi sen olevan olennainen osa omaa työtään.
Jouko Ikonen IBM:ltä kaipasi tarjouspyyntöön organisaation kuvausta, koska organisaation luonne vaikuttaa kehittämisprojektiin. Onko kyse prosessikeskeisestä vai hierarkkisesta organisaatiosta? Onko projekti it-vetoinen vai liiketoimintavetoinen? Näistä asioista keskustellaan aivan liian vähän. Järjestelmätoimittajan pitäisi tietää, haetaanko liiketoimintahyötyjä vai vain uutta järjestelmää. Samoin hänen pitäisi tietää, onko kyse yhden osaston vai kansainvälisen konsernin laajuisesta järjestelmästä.
Toteutusmallissa voi olla useita vaihtoehtoja. Käytetäänkö omia prosesseja vai ITIL-kehikkoa? Haetaanko räätälöityä vai vakioitua ratkaisua? Tehdäänkö itse vai ostetaanko ulkoa? Onko kyse suppeasta projektista vai laajasta osallistumisesta? Usein asiakas ei uskalla sanoa, kuinka laajasta hankkeesta on kysymys. Tällöin lähdetään liikkeelle suppeasta projektista, joka ei ole kovin kallis. Vasta matkan varrella huomataan, että projekti vaikuttaa toimintaan oletettua laajemmin.
Eri organisaatioilla on erilainen muutosvalmius ja se pitää ottaa huomioon projektisuunnitelman tavoitteissa. Uuden toimintatavan jalkauttaminen pitää varmistaa.
ITILin muutoksenhallintaprosessin käyttöönotossa on omat ongelmansa. Soveltamisalue pitää määrittää ja rajata järkevästi niin, että se on tarpeeksi laaja, jotta prosessista saadaan riittävästi hyötyä, mutta ei liian laaja, jotta se pystytään kuitenkin tekemään. IT-organisaation pitää sitoutua muutoksenhallintaprosessiin.
Viestintä ja tietoisuuden ylläpitäminen ovat kriittisiä menestystekijöitä. Nykytilan kypsyystason arvioiminen ITIL-käytäntöjä vasten auttaa asettamaan realistiset tavoitteet käyttöönotolle ja vaiheistukselle. Alhaista kypsyystasoa ei pidä pitää ongelmana vaan muutoksen realistisena lähtökohtana.
Kannattaa pyrkiä mieluummin pienellä alueella maksimitarkkuuteen kuin päinvastoin. Liiketoiminnan riskit toimivat hyvinä kannustajina (driver). Miten palvelukatkokset vaikuttavat liiketoimintaan? Millaisia suoria ja epäsuoria vaikutuksia niillä on? Mitkä ovat suorat taloudelliset vaikutukset? Entä vaikutukset asiakkaiden ja työntekijöiden tyytyväisyyteen? Yrityksen maineeseen? Uskottavuuteen?
Ylimmän johdon tuki, tavoitteiden viestintä alaspäin niin liikkeellelähdössä kuin matkan varrella, rahoitus ja resurssointi sekä roolien ja vastuiden vieminen käytäntöön ovat kriittisiä menestystekijöitä. Uudet vastuut lisäävät työmäärää, joten toimenkuvia voidaan joutua järjestelemään: jos uusia tehtäviä lisätään, niin vanhoja on siirrettävä eteenpäin – eikä vain lisättävä yhden ihmisen työmäärää.
ITILin aloittaminen vaatii lisää resursseja, mutta vapauttaa niitä toisaalta jatkossa. ITILin käyttöönotto ei ole sama kuin ITIL-koulutus: vaikka henkilöstö olisi käynyt ITIL-kurssit, niin siitä ei vielä seuraa, että ITIL olisi organisaatiossa käytössä.
ITIL-prosessi sinänsä ei vaadi teknologiaa, mutta sen käyttöönotto vaatii. Viestintää on hyvä automatisoida, jotta toiminta tehostuisi. Järkevää tilastotietoa tuskin saadaan ilman työvälineitä.
Muutoksenhallinnan tietokanta CMDB kytkee tapahtuman-, ongelman-, konfiguraation ja muutoksenhallinnan tiedot yhteen, mikä helpottaa prosessien integroimista. Konfiguraation laiteosat (CI, configuration item) sekä häiriö- ja muutoshistoria ovat olennaisia tietoja vaikutusanalyysin laadinnassa. Kustannuslaskennalla osoitetaan hyödyt ja perustellaan koko prosessin olemassaolo.
Jokaiselle prosessille tarvitaan omistaja, jolla on valtuudet ja taloudellinen vastuu.
Käyttöönotossa pitää ottaa huomioon kulttuurierot liiketoimintayksiköiden, maiden ja maanosien välillä.
Jos ITIL otetaan käyttöön liian laajalla alueella, näkyvien hyötyjen aikaansaanti saattaa kestää liian kauan, jolloin luottamus projektiin katoaa. Puuttuva tai puutteellinen konfiguraation hallinta taas johtaa siihen, että muutosten vaikutusta (taloudellinen, tekninen, palvelutasot, riskit) on mahdotonta arvioida riittävällä tarkkuudella. Tällöin ei saavuteta muutostenhallinnan tärkeää perustavoitetta: palvelujen suojaamista muutoksista johtuvilta häiriöiltä.
Esimerkkejä ongelmista, jotka seuraavat siitä, että muutosten kaikkia vaikutuksia ei osata ennakoida, on runsaasti.
* Käyttäjä ei pääse työasemalleen. Epäillään linjavikaa. Todellisuudessa syy on vasta toteutetussa järjestelmämuutoksessa.
* Yritys ei enää saa tilauksia. Pieni välittäjäpalvelin, jonka roolia järjestelmässä kukaan ei oivaltanut, meni pois päältä.
ITILin käyttöönotossa on usein esiintynyt mm. seuraavia ongelmia:
* Byrokratia ottaa vallan ja vie hyödyt ja pohjan muutokselta.
* Roolit ja vastuut määritellään tai viedään käytäntöön puutteellisesti.
* Palvelujen ja konfiguraation osien omistajuudet ovat epäselvät (vastuu ja sen merkitys ovat abstrakteja asioita).
* Prosessi ohitetaan.
Jaakko Kuosmanen kertoi tähän liittyvän tositarinan yrityskulttuureista. Isossa organisaatiossa päällikkö totesi, että kyllähän asiasta oli keskusteltu, mutta hän ei ollut saanut sitä kirjallisena. Pienessä organisaatiossa taas päällikkö totesi, että kyllähän tästä joku lappu oli tullut, mutta kukaan ei ollut kertonut hänelle asiasta. Kummassakaan tapauksessa muutos ei käynnistynyt. Uusi henkilö tarvitsee hiukan aikaa yrityskulttuurin itsestäänselvyyksien omaksumiseen.
Risto Pätsi TeliaSonerasta kertoi urbaanilegendan viiden vuoden takaa, jolloin ITILiä käynnistettiin. Koulutuksen jälkeen yhtiön unix-guru laittoi ovelleen lapun: ”Prosessi hoitaa”. Muuten kokemukset ITIL-koulutuksesta olivat myönteisiä. Ensimmäiseen koulutukseen osallistuneet siirtyivät yrityksen sisäisiksi ITIL-kouluttajiksi.
Risto Pätsi esitti konkreettisen esimerkin ITILin toiminnasta. Yhtiöön tuli asiakas, jonka nimen pituus oli 101 merkkiä. Asiakasjärjestelmässä asiakkaan nimelle oli varattu vain 85 merkkiä. Ensimmäinen ajatus oli pidentää kenttää. Kun selvitettiin järjestelmän kaikki yhteydet, päädyttiin siihen, ettei asiakkaan koko nimen tarvitse näkyä kentässä.
Laitteiden sijaan pitäisi ajatella asiakkaan saamia palveluita ja niitä tuottavia järjestelmiä. Liiketoiminnan kehittämisen pitäisi priorisoida työvälineiden kehitystarpeet.
Käyttöliittymän käytettävyyteen kannattaa kiinnittää huomiota. Jos tehtävän suoritukseen tarvittavien näpäytysten määrää voidaan merkittävästi vähentää, voidaan kuukaudessa säästää monta henkilötyöpäivää.
Asiakas- ja palvelutuotteet tarjoavat omat haasteensa työnkulkujen kehittämiselle. Asiakkalle luvattu palvelu, jonka toteutusmahdollisuuksia ei ole varmistettu, on kuin viritetty pommi.
Jatkuvia haasteita syntyy sokeasta luottamuksesta tietojärjestelmiin. Jos jonkin laitteen sijaintia ei ole päivitetty järjestelmään, niin laitteen noutaja saattaa tehdä hukkamatkan halki Suomen. Jostain kuitenkin voisi löytyä oikea tieto laitteen sijainnista. Kun nimeämiskäytännöt ovat kirjavat, sama nimi, esim. TeliaSonera, voidaan kirjoittaa monin eri tavoin, mikä hankaloittaa tiedonhakua.
Tulevaisuuden haasteena on siirtyminen elementtienhallinnasta palvelunhallintaa, sovellusten yhtenäistäminen ja määrän vähentäminen, verkko-, mobiili- ja it-komponenttien linkittäminen e-to-e-palvelunäkymäksi.
Tuomo Riekkinen kertoi TietoEnatorin vetämästä 140 päivää kestäneesät koordinointiprojektista, jonka lähtötilanteena oli yritysfuusio kesäkuussa 2004. Projekti jaettiin joukkoon osaprojekteja. Laitteidensiirtoprojektit olivat helpoimpia ja niillä oli selkeä aikataulu: laitteiden piti olla siirrettyinä ja toiminnassa lokakuussa 2004, koska asiakkaan omia järjestelmiä muutettiin marraskuusta helmikuuhun, eikä sinä aikana sallittu laitteistomuutoksia. Menetelmäprojektit olivat vaikeampia, koska niissä puututtiin muutokseen ja toimintatapoihin ja piti päättää, miten jatkossa toimitaan.
Koordinointiprojekti aloitettiin nykytilan selvityksellä ja muutosprosessin kuvaamisella. Molemmissa asiakasorganisaatioissa oli ITIL-prosessit käynnissä, toisin omilla murteilla, mutta pienin muutoksin päästiin yhtenäiseen kieleen. Luokitteluissa oli myös hiukan eroja ja hallintajärjestelmät olivat erilaiset. Loppukäyttäjät pitivät tiukasti kiinni omista prosesseistaan.
Suunnittelu jaettiin prosesessien ja muutostenhallinnan suunnitteluun sekä organisaation ja roolien suunnitteluun. Jälkimmäistä helpotti se, että ITIL oli molemmissa organisaatioissa käytössä. Silti kuvaamista riitti.
Projekti pysyi aikataulussa, jota muutoskielto vauhditti, mutta seuraavana vuonna projekti keskeytettiin. Laajoista koulutus- ja tiedotustilaisuuksista huolimatta yhteisiin hallintajärjestelmiin ei päästy. Loppukäyttäjien monet järjestelmät, kuten laskutusjärjestelmä, oli integroitu liian tiukasti omaan hallintajärjestelmään.
Projektista saatu kokemus oli hyvä, mutta harmitti, kun päällekkäisen työn karsiminen ei onnistunut odotusten mukaisesti.
Sivu päivitetty 30.11.05
Eija Kalliala, [email protected]