Itilin virheet

Juttuni itil-managereiden potkuista on herättänyt poikkeuksellisen paljon huomiota ja jopa keskustelua Pohjoisviitan sivuilla, joka on melko harvinaista. Viime perjantaista tuli uusi ennätyspäivä WordPressin liikennetilastojen mukaan. Huomautan, että minä en suositellut itil-managereiden erottamista, ainoastaan referoin mitä Charles Betz sanoi esityksessä, eikä hänkään suositellut sitä, hän vain kertoi mitä eräs pankki oli tehnyt.

Lupasin eräälle kommentoijalle tehdä yhteenvedon itilin virheistä. Ehkä voisin aloittaa sittenkin luettelemalla itilin hyötyjä. Itil on parempi kuin ei mitään, jokin kehikko on hyvä olla, sillä sen avulla on helpompi keskustella aiheesta ja on hyvä joutua pohtimaan it-palvelujen tuottamista. Prosesseilla voidaan saada asioita haltuun, on tärkeää priorisoida asioita ja muutoksia pitää hallita. Itil voi toimia, jos sen soveltamisessa käytetään paljon järkeä ja arvostelukykyä, osataan tehdä itsenäisiä ratkaisuja eikä jäädä väittelemään siitä mitä itil sanoo. Itil tarjoaa terminologian ja vaikka se on vähän horjuva, on se parempi kuin ei mitään.

No sitten luettelo itilin virheistä. En takaa, että tämä on kattava mutta yritän listata tärkeimmät.

  • Turhat prosessit. Itil kuvaa liikaa päällekkäisiä prosesseja. Lukuisten prosessien pyörittäminen johtaa helposti siiloutumiseen, jossa jokainen prosessi keskittyy oman alueensa hoitamiseen ja kokonaisuus kärsii. Turhat prosessit tuottavat taas turhaa työtä ja luovat keinotekoisia raja-aitoja.
  • Integraation puute. Kuten Jarkko Hedman kommentoi tätä, ”ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin.”
  • Toiminnot prosesseina. Itil kuvaa suuren joukon asioita prosesseina, vaikka ne eivät mitenkään omaa prosessin ominaisuuksia. Esimerkiksi saatavuuden ja jatkuvuuden varmistaminen ovat suunnittelua, joka vaatii osaamista. Prosessien kuvaaminen ja keinotekoisten tapahtumien kirjaaminen on turhaa työtä ja tuottaa turhia raportteja.
  • Sertifioidut asiantuntijat. Itil sertifikaatit hankitaan vastaamalla monivalintakysymyksiin, joissa oikean vaihtoehdon tietäminen perustuu muistiin. Kuulopuheiden mukaan osa kouluttajista antaa kysymykset etukäteen ja kertoo niiden oikeat vastaukset. Joka tapauksessa sertifikaatti ei kerro mitään omistajansa kyvyistä palveluhallinnan alueelta. Pahimmillaan sertifioitu asiantuntija ajaa järjettömiä ratkaisuja vedoten siihen, että itil sanoo näin, vaikka kyseessä on k.o. ”asiantuntijan” itse keksimä ja täysin virheellinen tulkinta siitä mitä itil ehdottaa.
  • Virheellinen palvelukäsite. Tämä on aika laaja aihe. Lue keskusteluni Akin kanssa.
  • Häiriöhallinta. Itilin suositus syöttää event managementin eli automaattisen valvonnan kautta tulleita häiriöilmoituksia asiakastuen kirjausten sekaan on järjettömyyden huippu. Asiakastuki on aivan eri asia kuin tekninen valvonta.
  • Ongelmanhallinta on rinnakkainen prosessi häiriönhallinnan kanssa. Saman asian tekeminen kahdessa eri vaiheessa on turhaa. Uusiutuva häiriö on liian aikaisin suljettu häiriö. Sotku johtuu siitä, että asiakastuki ja häiriönhallinta on nivottu yhteen.
  • Jatkuvan palvelunkehittämisen (CSI) mittaripainotteisuus on virhe. Painopiste on toiminnan tuloksellisuuden kehittämisessä, ei prosessien tehostamisessa.
  • En viitsi edes repostella turhien prosessien vikoja, sillä enemmistö itilin prosesseista on turhia.

Mielestäni tässä on aivan riittävästi syitä hylätä suurin osa itilistä.  Mitä sitten tilalle? Se on vaikea kysymys. Olen nähnyt lukuisia vaihtoehto-tarjokkaita, mutta mikään niistä ei ole vakuuttanut. Olen myös osallistunut useampaan yritykseen luoda jotain vaihtoehtoista, mutta kaikki hankkeet ovat luovuttaneet.

Työkalututkimus 2015

Työkalututkimus on nyt julkaistu, tällä kertaa pdf-muodossa. Löydät sen täältä: Työkalukysely 2015

Pidin esityksen työkalujen merkityksestä palvelun kehittämisessä Wakarun ITSM-työkalupäivänä. Löydät esityksen täältä Työkalujen merkitys wp, myös pdf. (olen lisännyt vähän tekstiä, jotta esitys olisi helpompi ymmärtää).

Työkalupäivä oli mielenkiintoinen. Oli virkistävää kuulla kuinka useampi puhuja oli jättänyt ITILin taakseen ja haki uusia ratkaisuja, irti ”parhaiden käytäntöjen” kahleista.

Huom. Tutkimuksessa näyttää olevan painovirhe, joka taitaa olla perua aikaisemmista tutkimuksista. Microsoftin ITSM tuotteen nimen pitäisi olla Microsoft System Center Service Manageria eli SCSM.

Ongelmat

Löysin twitter-arkistosta vanhan twiittini syyskuulta 2009: It was fun to explain the concepts of incident, problem, error KE to a class who had not heard the terms before. They have power! Eli olin selittänyt insidentin, ongelman, virheen ja tunnetun virheen käsitteitä kurssilla ja saanut innostuneen vastaanoton. Nuo käsitteet selkeyttivät monia asioita ja ihmiset tajusivat havaitsemiaan ilmiöitä käsitteiden avulla. Ne auttoivat jäsentämään omaa työtä ja olivat siinä mielessä hyödyllisiä.

Jos määritelmät ovat unohtuneet, niin kertaan niitä tässä nopeasti. Itilin määritelmän mukaan ongelma (problem) on yhden tai useamman häiriön (insidentin) tuntematon perussyy (root cause) ja error tai known error on sitten tunnistettu virhe, joka aiheuttaa insidentin.

Kun itiliä kirjoitettiin, havaittiin että usein häiriöiden korjaaminen vei niin paljon aikaa, ettei niiden syihin ehditty puuttua. (Kun itse olin asiakaspalvelun päällikkö, huomasin että usein syynä ei ollut mikään kiire, vaan ennemmin laiskuus.) Tämän takia päätettiin luoda erillinen ongelmanhallinnan prosessi eli Problem Management. Prosessi osoittautua vaikeaksi ja se sai monta erilaista ja väärää tulkintaa. Ongelmanhallinnasta tuli usein vain tapa käsitellä vaikeita häiriöitä. Versio 3:n kirjoittajat kirjoittivatkin prosessin uusiksi havaitsemiensa käytäntöjen pohjalta eli kirjasivat väärinkäsitykset uudeksi parhaaksi käytännöksi. Tämä sitten korjattiin vuoden 2011 versiossa, mutta lopputulos ei onnistunut vieläkään.

Itilin ongelmanhallinta on epämääräinen käsite. Pohjimmiltaan ongelmanhallinta ja häiriönhallinta ovat samoja prosesseja ja tekevät samoja asioita. Tämä on resurssien tuhlausta ja sotkee toimintaa. On aivan selvää että yksi prosessi riittää häiriöiden ratkomiseen.

Olen aiemmin tässä kirjoitussarjassa erottanut asiakkaan ongelman ja häiriön toisistaan. Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Häiriö on tilanne, jossa joku asia ei toimi halutulla tavalla. Häiriö voi aiheuttaa asiakkaan ongelman, mutta ongelmia voi olla ilman häiriöitä. Häiriön korjaamisen pitää ulottua myös häiriön aiheuttajien käsittelyyn. Emme missään nimessä tarvitse erillistä prosessia vaikeiden häiriöiden korjaamiseen, on vastuutonta toimintaa palauttaa vain palvelu takaisin selvittämättä miksi se häiriintyi.

On selvää, että palveluja pitää kehittää. Tunnetut viat (Known Error) ovat jokapäiväinen ilmiö. Kaikkia vikoja ei kannata korjata. Asiakkaiden ongelmia voi myös ilmetä ilman minkäänlaisia häiriöitä eli asiakas joutuu ongelmiin vaikka palvelut toimivat aivan oikein. Häiriöt voivat toistua vaikka niiden aiheuttajat on korjattu.

Itil tarjoaa liudan ”prosesseja” palvelun kehittämiseen ongelmanhallinnan lisäksi, löytyy jatkuvuuden hallinta, kapasiteetin hallinta tietoturvanhallinta ja tietysti jatkuva palvelun kehittäminen. Jos siis äkilliset tilantarpeet aiheuttavat palvelukatkoja ja tietoturvariskejä niin mikä ”prosessi” ottaa vastuun?

Ehdotan, että nämä kaikki korvataan yhdellä prosessilla. Riskienhallinta on tarpeellinen, suorastaan välttämätön toiminta, joka tunnistaa riskit ja valitsee niiden käsittelytavan. Lisäksi kaikilla organisaatioyksiköillä ja jopa henkilöillä pitää olla vastuu palvelun kehittämisestä. Jokaisen pitää tarttua havaitsemiinsa mahdollisuuksiin parantaa palvelua.

Mielestäni siis ongelmanhallintaa ei tarvita. Se voidaan korvata riskienhallinnalla. Service Deskin vetäjällä ja kaikilla prosessipäälliköillä on vastuu olla aktiivisesti mukana palvelun laadun kehittämisessä.

Itil-projektit

Kysely

Tällä kertaa sain kimmokkeen pikakyselyyn itSMF:n ”ITSM Monitor-tutkimuksesta”, jolla yritetään todistaa itilin erinomaisuutta ties monennenko kerran.

Kysely oli poikkeuksellisen vaikea, huomasin sen itse kun aloin muistella omia projektejani. On vaikea muista esim vuosilukuja. Vastauksia tuli aika vähän, mutta julkaisen tulokset, koska tämä on kuitenkin aika ainutlaatuinen tulos, ja vastaa hyvin sitä käsitystä, joka tuntuu vallitsevan alalla, silloin kun keskustellaan avoimesti, eli ei esitetä virallista kantaa,

Kysely oli tällainen:

itSMF lähetti kyselyn, jossa kysytään itil-projektista, siis ikään kuin olisi yksi itil-projekti, jolla kaikki kymmenet prosessit on otettu käyttöön. Käsitykseni mukaan monissa organisaatioissa on kuitenkin tehty useita hankkeita, eivätkä kaikki hankkeet ole aina johtaneet mihinkään pysyvään toimintatapojen muutokseen.
 Itiliä on Suomessa sovellettu jo kymmenen vuoden ajan. Haluan selvittää kuinka monia itil-projekteja tai hankkeita on tänä aika tehty.
 
1) Kuinka monta päättynyttä, onnistunutta tai epäonnistunutta itil-hanketta muistat nähneesi työpaikallasi näiden kymmenen vuoden aikana? Kerro hankkeiden lukumäärä.
a) Onnistuneita, eli prosessit saatiin toimimaan
b) Osittain onnistuneita, eli jotain saatiin toimimaan
c) Epäonnistuneita, eli prosessit eivät käynnistyneet tai ovat lakanneet toimimasta.
 
2) Kerro jokaisesta hankkeesta tai projektista muutama asia. (Ei ole väliä jos et muista vuosia tarkalleen):
 
Projektin käynnistys-päättymisvuodet:
Itil prosessit, joita yritettiin ottaa käyttöön:
Tulos kouluarvosanana:
Oma roolisi siinä (vetäjä, osallistuja, muu):

Vastauksia tuli parikymmentä ja niissä kuvataan 45 projektia ja 77 prosessin käyttöönotto.

Tulokset

Hankkeiden onnistuminen jakautuu melkein tasan kolmeen ryhmään. Reilu kolmasosa on onnistunut ja vajaa kaksi kolmasosaa on epäonnistunut.

Slide1

 

Vastaajien roolit jakautuvat seuraavasti: Noin puolet vastaajista on hankkeen vetäjiä, joka neljäs on ulkopuolinen, usein hankkeen kohde. Loput vastaajista ovat projektiin osallistuneita tai konsultteja.

Slide2

 

Valtaosa hankkeista on kestänyt vuoden tai kaksi.

Slide3

 

Aktiivisin kausi on ollut 2006-2010. Nyt itil-projektit ovat hiipumassa.

Slide4

 

Yleisin prosessi, jota on otettu käyttöön on insident. Vastaukset on suhteutettu vastaajien määrään ja koska insidenttiä on käynnistetty moneen otteeseen, on arvo lähes 120%. Hyvänä kakkosena tulee muutoksenhallinta. Ainoa kolmosversion tuoma prosessi eli palvelupyyntöjen hallinta on kuudennella sijalla. Sen jälkeen muut prosessit jäävät yhden tai kahden maininnan varaan. Yli puolta nyky-itilin prosesseista ei mainittu lainkaan.

Yksi vastaaja kertoi itil V3 hankkeesta, joka luonnollisesti epäonnistui.

Slide5

 

Hankkeet eivät saa kovin korkeita arvosanoja vastaajilta, keskiarvo on 7½. Ainoastaan vetäjät antavat kahdeksikon. Riippumattomat arvosanat tulevat ulkopuolisilta, jotka antavat 6½.

Slide6

Seuraavassa joitakin kuvauksia epäonnistumisista:

Itil prosessit, joita yritettiin ottaa käyttöön: Useita ITIL-prosesseja (keskittyminen Service Design, Transition ja Operation osuuteen), pääfokus tiputtaa TCO kustannuksia keskittyen Service Design osuuteen.
  Tulos kouluarvosanana: 6-  (jalkautus jätettiin tekemättä kiirellisempien töiden vuoksi, vain ne jotka olivat elinkelpoisia jo tekemisvaiheessa ottivat tulta alleen, kaikki uusi tekeminen kuoli kehtoon).
 
  Ensimmäisessä ITIL prosessien käyttöönotossa olin mukana ns. prosessin käyttäjänä. Käyttöönoton avain henkilöitä olivat insinöörit – tai tyypit jotka olivat erittäin sisällä prosesseissa.
  Mieleen tuosta tilanteesta jäi fiilikset etten tunne enää omaa työtäni – minulle itsestään selviä asioita piti selostaa miehille joilla ei tuntunut olevan lainkaan todellisuustajua ….
  No, kyllä se projekti loppuun saatiin ja prosessit käyttöön, mutta muistaakseni silloinen tikettityökalu ei oikein ollut istuva kaikkiin tarpeisiin.
 
Muutoksen hallintahanke saatiin hyvin speksattua ja käyttöönotettiin yksinkertainen muutoksenhallintatyökalu. Homma nyykähti aika pian
 
–       ensimmäinen yritys epäonnistui, ehkä prosessin kuvaus onnistui mutta käytäntö ei toiminut
–       uusi yritys uusilla henkilöillä onnistui
–       tämän hetken tilanne on byrokratiassa sietokyvyn äärilaidalla, mutta toimii sinänsä (=vähentää ongelmia)
 
Johto ei ole sitoutunut. Sitä myötä ei sitoutumista eikä ymmärrystä asialle myöskään eri IT-yksiköistä. Pelkoa muuttaa asioita. Ei CMDB:tä. Ei systemaattista eikä rakenteista palvelunhallintakulttuuria.
 

Johtopäätökset

Tulos on odotetunlainen. Itilistä on käytössä sen alkuperäiset osat eli itilin kova ydin. Monessa tapauksessa perusasiat on opittu jo 90-luvulla ennen itilin rantautumista Suomeen. Onnistuneessa Itil-projektissa on usein ollut kyse vain vanhan helpparin uusimisesta itilin tyyliin, yleensä päivittämällä ohjelmisto ja terminologia itilin mukaiseksi.

Kuvaukset epäonnistumisista ovat tuttuja. Olen itse nähnyt konsultin roolissa paljon onnistumisia ja useita epäonnistumisia. Epäonnistumisen vaistoaa aika pian, työ alkaa tökkiä, asiat eivät etene, osallistujat eivät paneudu tekemiseen. Silti tuosta on mahdollista päästä yli. Paljon riippuu hankkeen moottorin aktiivisuudesta.

On selvää että itSMF:n monitori tulee näyttämään toisenlaista tulosta. Siinä pyydetään rastia ruutuun kaikista itil ”prosesseista” ja on luonnollista vastata että esim. tietoturva on kunnossa, vaikkei sillä olisi mitään tekemistä itilin kanssa. Tulos voidaan silti tulkita ”itil-projektin” tulokseksi. Lisäksi siinä kysytään yhden itil-projektin toteutuksesta vaikka projekteja on ollut useita. Lisäksi itSMF:n kysely ei kysy vastaajan roolista, mutta on toki selvää, että yrityksen itSMF-yhdyshenkilöt ovat yleensä vastuussa itil-projekteista.

Selkeyttä palveluun

Palvelu on vaikea käsite, joka on aiheuttanut päänvaivaa monille it-palvelunhallinnan harjoittajille. Asia on ikään kuin itsestään selvä, mutta se luiskahtaa otteesta kuin märkä saippuanpala. Yritykset määritellä palvelu  ovat vaikeita, ja on aina helppo keksiä esimerkkejä palveluista, jotka eivät sovi palvelun määritelmään. Esimerkiksi Itil määrittelee palvelun näin: ”Keino tuottaa arvoa asiakkaalle auttamalla asiakasta saavuttamaan tuloksia ilman, että asiakas investoi tiettyjä kustannuksia ja riskejä.”  Määritelmä rajaa pois kaiken sisäisen it-palvelun, joka on suorastaan aika huvittavaa, kun ajattelee millä innolla itiliä on opiskeltu ja sovellettu juuri sisäisen it:n tarpeisiin.

Nyt olen kohdannut viimeinkin määritelmän tai lähestymistavan, joka vaikuttaa järkevältä ja toimivalta. Lyhyesti tiivistettynä palvelu voidaan kuvat kaavalla:

Tarjooma + Järjestelmä(t) + Tapahtuma(t) => Tulos.

Palvelun komponentit ovat: palvelutarjooma, palvelujärjestelmä ja palvelutapahtuma. Näin saadaan aikaan palvelutulos.

Palvelutarjooma on lupaus palvelusta tietyin ehdoin. Tarjooma voi sisältää yhden tai useita vaihtoehtoja. Tarjooma voi olla asiakaskohtaista tai standardoitua.

Palvelujärjestelmä sisältää kaikki ne elementit, resurssit, välineet, menetelmät, prosessit ja ihmiset, joiden avulla palvelu saadaan aikaan.

Palvelutapahtuma on sitten se hetki, jolloin palvelu tapahtuu ja asiakas vastaanottaa tai kokee palvelun tuloksen.

Esimerkiksi Parturi-Kampaamolla on hinnastossaan erilaisia tuotteita. Sen palvelujärjestelmään kuuluvat tilat, sisustus, työkalut, prosessit, infrastruktuuri ja henkilökunta. Tukanleikkuu on palvelutapahtuma ja sen lopputulos on palvelutulos.

Tämä ajattelu selkeyttää monia itilin vaikeita käsitteitä. Esimerkiksi palvelukatalogi on siis kuvaus palvelutarjoomasta eikä mikään kattava kuvaus kaikesta, mitä it tekee. It- yksikön henkilökunta vastaa sekä palvelujärjestelmistä että palvelutapahtumista. Palvelujärjestelmän ylläpito ja kehittäminen eivät siis ole palvelua, vaan ylläpitoa ja kehittämistä. Palvelujärjestelmiä ei kuvata palvelukatalogissa. Asiakkaat eivät yleensä ole kiinnostuneita palvelujärjestelmistä.

Palvelun elinkaaresta ei voi puhua, se on liian epämääräinen käsite, sensijaan palvelujärjestelmillä ja palvelutarjoomalla on omat elinkaarensa. Palvelutarjooman muutokset eivät välttämättä liity mitenkään palvelujärjestelmien muutoksiin ja päinvastoin.  Palvelumuotoilulla kehitetään palvelutapahtumia, mutta palvelumuotoilu ei vaadi välttämättä muutoksia palvelutarjoomaan tai palvelujärjestelmään, kyse voi olla vain siitä, kuinka palvelu toimitetaan asiakkaalle.

Mittaamisen vaarallisuus

Reetta Räty kirjoitti helsingin Sanomissa 16.3. Valitus on kaikkialla sama: Onko tulospalkkioarvioinneista, muutosvalmiusmittareista ja laadunseurantajärjestelmistä mitään hyötyä?

Milloin ehtii tekemään töitä?

Työpaikoille pesiytynyt mittaus- ja valvontavimma turhauttaa. Kaikkea mitataan ja kaikesta pitää tehdä raportti. Tarkoitus on hyvä mutta lopputulos piinaava.

Olen samaa mieltä. Mittaamisen tärkeys on tavallinen hokema, joskus väitetään että Deming sanoi että mitä ei voi mitata, sitä ei voi ohjata. Itse asiassa Deming sanoi väitteen olevan kallis myytti. “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth”.

Miksi mittaaminen voi olla vaarallista? Olemme tottuneet käyttämään mittareita ja luottamaan niihin. Vaarallisuus syntyy siitä, että mittariin luottava henkilö ei ymmärrä mittarin antaman tiedon merkitystä.

Lämpömittari kertoo millaista ulkona on, nopeusmittari kertoo kuinka kovaa mennään jne. Mittarit antavat selkeitä tavoitteita ja raja-arvoja. Nopeusrajoitus on hyvä esimerkki mittareiden vaarallisuudesta. Autoilija saattaa kuvitella ajavansa turvallisesti ajaessaan nopeusrajoitusten mukaisesti liukkaalla tiellä, vaikka hän ehkä ajaakin kuin formulakuski, pidon äärirajoilla. Nopeusmittari kertoo auton nopeuden, mutta se ei kerro tarvittavaa jarrutusmatkaa. Hyvissä olosuhteissa jarrutusmatka riippuu jokseenkin suoraan nopeudesta (sen neliöstä), mutta huonoissa olosuhteissa tienpinnan kunto vaikuttaa hyvin paljon.

Toimivien mittareiden kehittäminen on vaikeaa ja usein käytetään mittareita, joiden tiedetään olevan epätarkkoja tai puutteellisia.

Tietotekniikan toimivuus on vaikeasti mitattava asia. On hyvin vaikea mitata tietotekniikan tuottamaa hyötyä. Sen sijaan on paljon helpompi mitata tietotekniikan komponenttien toimintaa ja ajatella, että se vaikuttaa saatuun hyötyyn. Prosessit tuottavat erilaisia mittareita, joiden avulla voimme seurata prosessien toimintaa. On helppo koota suuri joukko mittareita ja luoda mielikuva, että tilanne on hallinnassa. Ongelmia syntyy jos:

  • mittaamme vääriä asioita
  • satunnaiset tekijät vaikuttavat mittareihin
  • emme ymmärrä miten mittari toimii

On hyvin tavallista, että mitataan prosessin toimintaa. Prosesseissa on erilaisia aktiviteetteja ja niistä saa mittareita helposti. Kun prosessia käynnistetään, on tärkeää alkaa mitata sen toimintaa. Mittaukset varmistavat sen, että prosessi toimii halutulla tavalla. Tässä ei ole mitään väärää. Ongelmia syntyy jos ja kun mittareista tehdään tavoitteita ja tavoitteita asettavat henkilöt, jotka eivät niitä ymmärrä. Prosessin toiminta ei ole tavoite, prosessin toiminta on aktiviteettia, jonka tuloksena pitäisi syntyä jotain hyödyllistä.

Vuoden 2014 teemat

Tämä kysely oli uusinta vuodelta 2012. Siinä kysyttiin kahta asiaa:

1) Mikä tai mitkä tavoitteet/tehtävät tulevat viemään eniten aikaa tänä vuonna?
2) Minkä asian tai asioiden pitäisi parantua IT-toiminnassa tämän vuoden aikana?

Vastauksia tuli 56, kolme enemmän kuin vuonna 2012.

Tunnistin vastauksista 146 aihetta, joka on 10 vähemmän kuin edellisellä kerralla. Selvänä ykkösenä on infra, joka on ennen kaikkea aikaa syövä asia ja kakkosena tulee prosessit. Nämä olivat kärjessä myös vuonna 2012. Kolmantena on muutos, esimerkiksi organisaatiomuutos tai muu vastaava ulkoinen tekijä, johon IT:n on pakko sopeutua. Kustannukset ja laatu ovat tärkeimmät kehittämiskohteet. Alla olevassa kuvassa on esitetty se, kuinka monta kertaa jokin asia mainitaan.

Slide1

On mielenkiintoista katsoa, mikä on muuttunut vuodesta 2012. Muutokset ovat mielestäni yllättävän suuria. Nyt asteikkona on prosenttiluku, joka on laskettu erotuksena siitä, kuinka monta prosenttia vastaajista mainitsi jonkun asian, eli siinä otetaan huomioon pieni ero vastaajamäärissä.

Selvässä kärjessä on muutos, jota ei esiinny lainkaan vuoden 2012 tuloksissa. Toki vuoden 2012 vastauksista löytyy muutama maininta jos tarkkaan etsii, mutta se ei tosiaankaan ollut samanlainen hallitseva teema kuin nyt. On hauska huomata, että laatu, viestintä ja asiakastyytyväisyys ovat nousseet. Nämä kaikki ovat tärkeitä asioita, joihin kannattaa käyttää aikaa ja energiaa.

Pudonneiden asioiden kärjestä löytyvät prosessit eli prosessibuumi alkaa hiipua. Se oli vuonna 2012 selkeästi tärkein kehittämisen kohde, nyt se on lähinnä aikaa syövä kohde. Governance on myös pudonnut. Business tarkoitti lähinnä liiketoiminnan ja IT:n yhteensovittamista. Olen nimennyt sen nyt yhteistyöksi, joka ehkä kuvastaa hienoista painotuseroa. Mittaaminen on samoin pudonnut, varmaankin prosessien myötä. Infra ja service desk ovat säilyneet samoissa asemissa.

Slide2

Tulokset ovat johdonmukaisia ja mielestäni positiivisia. Nyt ollaan vähemmän sisäänlämpiäviä, IT:n sisäiset asiat putoavat ja ulkopuoliset asiat nousevat listalla.

Kysely myös osoittaa mielenkiintoisen ilmiön kyselytutkimuksista. Nyt kärkikolmikkoon nousi asia (muutos), joka ei esiintynyt v. 2012 listalla lainkaan. Jos olisi antanut vastaajille valmiin luettelon niin olisin varmasti valinnut sen edellisen tutkimuksen kärkiaiheista. Tuskin olisin osannut lisätä tätä muutosta sinne ja kokemusten mukaan vastaajat tyytyvät valitsemaan annetuista vaihtoehdoista.  Yksinkertaiset avoimet kysymykset tuottavat yllättävän hyviä tuloksia.

%d bloggers like this: