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ä.

Onko ITIL syvältä?

WordPress näyttää milllä hakusanoilla joku on löytänyt Pohjoisviitan sivut. Luettelossa on parin päivän ajan pistänyt silmään lause ”itil on syvältä”. En ole käyttänyt tuota sanontaa koskaan aikaisemmin, joten haku on tullut tänne todennäköisesti vain sen takia, että olen kirjoittanut aika paljon itilistä suomeksi. Jäin miettimään mitä tuohon vastaisi. Tietyissä olosuhteissa väite on täysin väärä, jossakin tilanteessa taas voin olla samaa mieltä.

Aluksi olin sitä mieltä, että itil on hyvä ja tarpeellinen. Sitten kolmosversio epäonnistui pahan kerran ja itil paisui mahdottomaksi möhkäleeksi. Lisäksi kolmosversiossa oli paljon typeriä virheitä. Nyt olen alkanut kyseenalaistamaan myös alkuperäisen itilin hyötyä. Tämä johtuu osin siitä, että maailma on muuttunut itilin ympärillä. Vanhat 1980-luvun mallit eivät enää istu niin hyvin kuin ennen. Sinänsä mallin ikä ei ole yksinään mikään syy hylätä sitä, mutta itilin tapauksessa käytännöt ovat muuttuneet liikaa. Vanhan mainframe-maailman opit eivät ole tätä päivää.

Mielestäni itil, siis kakkosversio, edustaa yhtä kehitysvaihetta. Kun IT-yksikkö laskeutuu puusta, se tarvitsee itiliä. Itil on parempi kuin ei mitään. Kun itil on hyödynnetty, pitää siirtyä eteenpäin.

Itil puhuu monista hyvistä asioista, mutta sen ratkaisut eivät ole läheskään aina edes käyttökelpoisia. Silti mielestäni IT-ammmattilaisen yleissivistykseen kuuluu tuntea Itil ja ISO 20000. Peruskurssi tai itseopiskelu riittää.

Itilistä on tarjolla runsaasti jatkokursseja ja sertifikaatteja. On huolestuttavaa, jos niiden opiskelija ei tajua viimeistään kolmannen kurssin kohdalla, että itil-koulutusohjelma tosiaankin on syvältä.

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.

Pikakysely kehittämismenetelmistä

Äskeinen CSI-kysely innosti minut kysymään taas kerran kehittämisestä. Tällä kertaa minua kiinnosti miten menestystä mitataan ja onko CSI saanut jalansijaa Suomessa. Vastauksia tuli parissa päivässä 34 enkä katsonut uusintakysymystä tarpeelliseksi.

Slide1

Kehittämisen onnistumista mitataan eri tavoin. Tässä kuvassa on esitetty ensimmäisenä mainittu eli tärkein vaihtoehto. Prosessimittarit ja asiakashyöty mainitaan usein, joten jos laskee mainintoja, vaihtoehdot ovat aika tasoissa. Noin puolet mittaa vain tehtävän suorittamista ja/tai prosessimittareita. Omasta mielestäni kaikella kehittämisellä pitää olla jokin asiakashyöty ja sitä pitäisi mitata. Toki myönnän että joidenkin hyötyjen mittaaminen on mahdotonta.

Slide2

Valtaosa vastaajista näkee kehittämisen sarjana hankkeita ja vain joka neljäs pitää sitä prosessina. Olen samaa mieltä enemmistön kanssa. Kehittäminen on pääosin erilaisia hankkeita, ei prosessi.  Kehittäminen voi olla jatkuvaa ja sille voidaan määritellä käytäntöjä ja mittareita, mutta se ei mielestäni tee siitä prosessia. Havaittujen yksittäisten virheiden korjaaminen voi olla prosessi, mutta itilissä on sille jo oma prosessinsa.

Kehittäminen on vaikeaa ja kehittämishankkeet ovat erilaisia. Usein suurin haaste on saada ihmiset muuttamaan toimintatapojaan. Se tuskin onnistuu jonkun määritellyn prosessin kautta.

Slide3

Tämän kysymyksen laadinnassa tapahtui virhe. En huomannut lisätä vaihtoehtoa: Tunnen CSI:n, mutta emme käytä sitä. Jotkut vastaajat huomauttivat siitä. Ne vastaukset on tässä yhdistetty vaihtoehtoon a).

Pidän Itilin CSI:tä erittäin huonona mallina ja siksi on helpotus nähdä, ettei se ole ainakaan vielä levinnyt tätä laajemmaksi.

Vuoden 2012 suosituimmat jutut ja hakusanat

Luetuimmat jutut

  1. Työkalututkimus 2012
  2. Service Desk 2.0, the new support function
  3. BYOD Suomessa
  4. Service deskin tulevaisuus
  5. Vuoden 2012 teemat
  6. ITIL V3 pähkinänkuoressa
  7. Asiakassuhteen hoito ja palvelusopimukset
  8. Service Desk 2.0
  9. 20 miljonaa käyttäjää, 50.000 tukipyyntöä kuukaudessa ja 10 henkeä tuessa.
  10. IT palvelun toimivuus

ITIL V3 pähkinänkuoressa sinnittelee listalla edelleen, vaikka se on alkujaan kirjoitettu jo vuosia sitten.

 

Suosituimmat hakusanat

hakusanat12

Hakusanoissa ITIL pysyy yhä kärjessä, mutta hakujen määrä on pudonnut. Uusi ITIL 2011 ei tunnu kiinnostavan ketään, ISO 20000:n uusi versio sensijaan on nousussa. Sosiaalinen media alkaa ilmeisesti kiinnostaa, koska hashtag on yllättävässä nousussa. Vanha juttuni Tiedätkö mikä on hashtag on 17. luetuin.

Huom, hakusanoja on luokiteltu aiheen mukaan ja olen luokitellut hakusanoja vähän eri tavalla kuin vuosi sitten tehdyssä vertailussa, nyt yhdistin kaikki itil-haut yhteen, edellisessä ne on eroteltuna, esim itil koulutus jne.

Tässä vielä hakusanojen sijoitus listoilla. BYOD ei esiintynyt vuonna 2011 kertaakaan.

aihe v2012 v2011
itil 1 1
iso 20000 2 3
merimerkit 3 19
itil v3 4 2
hashtag 5 11
palvelukatalogi 6 6
pohjoisviitta 7 4
ISO 20000:2011 8 18
muutoksenhallinta 9 8
byod 10
insidentti 11 5
prosessit 12 16
service desk 13 12
aale roos 14 13
häiriönhallinta 15 17
elinkaari 16 21
ongelmanhallinta 17 8
konfiguraationhallinta 18 15
itil 2011 19 18

 

 

Kypsyydestä

It-organisaation tilaa voi kuvata sen kypsyystasolla. Kypsyystasot ovat usein suhteellisen helppo tunnistaa ja niistä on olemassa lukuisia malleja. Lähtökohtana on yleensä yksilöllinen toiminta, johon tulee ensin valvontaa, sitten hallintaa, ohjausta ja optimointia. On tavallista ajatella että kypsyydessä pitää pyrkiä aina korkeimmalle tasolle, mutta se ei ole välttämättä totta. Olen käyttänyt renkaiden vaihtoa esimerkkinä erilaisista kypsyystasoista.

 0-taso Sakkokuski ei vaihda renkaita kuin pakon edessä.
1-taso Yksityisautoilija tarkistaa renkaiden kunnon kesä/talvi-renkaiden vaihdon yhteydessä ja hankkii uudet kun kulutuspinta alkaa olla vähissä.
2-taso Taksiyritys uusii renkaat 50.000 km välein.
3-taso Bussiyhtiön ajomestari seuraa renkaiden kulumista ja määrää vaihtohetken puoli vuotta aikaisemmin.
4-taso Rekkayhtiö seuraa renkaiden kulumista ja maksaa kuljettajille bonuksia jos renkaat kestävät keskimääräistä paremmin.
5-taso Formula 1 talli arvioi renkaiden keston kierroksen tarkkuudella, mutta muuttaa suunnitelmia, jos olosuhteet vaihtuvat. Renkaan vaihtohetkeen vaikuttavat rata, kierrosajat, sää ja muiden kilpailijoiden toiminta. Tavoiteaika vaihtoon on 4 sek.

 Edellä kuvattu malli korostaa sitä, että tavoiteltava kypsyystaso riippuu tarpeesta, mutta toki jokainen voi toimia tarvittavaa matalammalla kypsyystasolla.

Elokuun kyselyn teemana oli KPMG:n jo vuonna 2000 julkaisema malli IT yksikön kypsyydestä. Mielestäni malli on edelleen osuva.

Mallin kypsyystasot

  1. Teknologialähtöinen. IT taistelee tekniikan kanssa, juuri mitään prosesseja ei ole käytössä. Asiakas saa sitä mitä kyetään tarjoamaan. Toiminta voi sinänsä olla melko asiakaslähtöistä, mutta sen laadun ja luotettavuuden kanssa on ongelmia.
  2. Prosessikeskeinen. Prosessit on saatu toimimaan ja IT kykenee mittaamaan toimintaansa. Prosessit ovat keskeisessä roolissa ja asiakkaan tulee mukautua niihin, muuten palvelu ei toimi.
  3. Palvelukeskeinen. IT on määritellyt palvelunsa ja kykenee tuottamaan niitä ohjaamalla prosessejaan. Palvelut ovat standardoituja. Asiakas voi tilata palveluja, mutta ei voi muokata niitä.
  4. Asiakaskeskeinen. Nyt asiakas pääsee päättämään palveluista ja IT toimii lähellä asiakasta tiiviissä yhteistyössä. Taustalla ovat toimivat prosessit ja standardoidut peruspalvelut. Niitä osataan käyttää hyvin joustavasti.
  5. Liiketoimintakeskeinen. Liiketoiminta ohjaa IT:tä täysin ja IT:n tavoitteet ovat liiketoimintatavoitteita.

Tässä mallissa palvelukeskeisyyden ja asiakaskeskeisyyden välillä on merkittävä kynnys. Alemmilla tasoilla IT päättää ja asiakas saa mitä IT toimittaa, ylemmillä tasoilla vastuu on siirtynyt asiakkaille. Kyse ei ole siis pelkästään IT:n kypsyydestä, vaan myös asiakkaan on kypsyttävä tähän rooliin.

Tämän pohjalta yritin kuvata tilanteita, joissa kukin taso olisi saavutettu.

 
a) Teknologia on hallussa. IT laitteet ja järjestelmät toimivat ja mahdolliset vikatilanteet kyetään korjaamaan.
b) Prosessit toimivat tehokkaasti. Kaikki häiriöt, ongelmat, muutokset jne. kirjataan. Häiriöiden ratkaisuajat tiedetään ja muutosten riskit osataan arvioida.
c) Palvelut pelaavat. Osataan tuottaa pitkälle standardoituja IT palveluja asiakkaan tilausten mukaan. Muutosten vaikutukset tunnetaan ja palvelujen laatu on hallinnassa.
d) Asiakas määrää. Asiakas ohjaa toimintaa ja päättää mitä IT palveluja tuotetaan. IT-organisaatio kykenee mukautumaan joustavasti muuttuviin tarpeisiin.
e) Liiketoiminta ohjaa.  IT on sulautunut liiketoimintaan ja sitä johdetaan liiketoiminnan näkökulmasta. IT pystyy luomaan uusia mahdollisuuksia liiketoiminnalle. 

Pyysin kertomaan miten hyvin vastaajan organisaation nykyinen tila vastaa näitä kuvauksia asteikolla: 1 -5. 1 ei lainkaan, 2 vain vähäisesti, 3 osittain, 4 aika hyvin ja 5 täydellisesti.

Lisäksi pyysin vielä kertomaan mikä näistä kuvauksista vastaa nykyistä tilaa ja mikä on tavoitteena. Tämä kysymys oli ilmeisesti vaikeasti muotoiltu, sillä n. kolmasosa jätti vastaamatta siihen tai vastasi väärin. Oikea vastaus olisi siis ollut jokin kirjain, esim. nyt A ja tavoitteena B. Näin muuten ei yksikään vastannut, vaikka se olisi oikea vaihtoehto aika monelle.

Valtaosassa vastauksissa oltiin tasoilla 4 tai 3 eli aika hyvin tai osittain. Ainoastaan teknologia -tasolla löytyi merkittävä määrä täydellisesti -vastauksia.

Kynnys palvelu- ja asiakastasojen välillä näkyy selvästi, vain alle 20 % arvioi olevansa niillä tasoilla.

Oman tason ja tavoitetason välillä on mielenkiintoinen korrelaatio. Jos omaksi tasoksi arvioitiin teknologia, tavoittetasona oli yleensä palvelu. Jos taas oma taso oli jokin muu, tavoitteeksi tuli asiakas- tai liiketoimintakeskeisyys.

Tein oman tulkinnan kypsyystasoista vastausten perusteella.

Jos vastaaja oli jonkun kypsyystason kuvaavan täydellisesti, hyväksyin sen. Jos vastaaja ei sanonut yhdenkään tason toteutuvan täydellisesti, mutta sanoi useamman toteutuvan aika hyvin, valitsin näistä toiseksi ylimmän. Näin laskin jokaiselle vastaajalle tämän hetken kypsyystason. Periaatteena oli, että alempien kypsyystasojen täytyy toteutua eli kypsyystasoarvioiden piti pysyä samana tai pudota.

Oman tulkintani mukaan vajaa puolet jäi tasolle nolla, eli teknologia ei ole täysin hallussa. Vajaa neljännes on saavuttanut sen tason. Joka viidennes on saavuttanut prosessitason ja yksi kymmenestä palvelutason. Yksi henkilö vastasi 5 joka tasolle.

Johtopäätökset

Tulos on mielenkiintoinen monella tavalla. Tämän mukaan noin puolet it-yksiköistä ei ole päässyt yli teknologiakeskeisyydestä. Mielestäni monet havainnot tukevat tätä tulkintaa.

Teknologian hallinnan tasolle on päässyt joka neljäs ja heillä on edellytykset saada prosessit toimimaan. Joka viides on prosessitasolla ja joka kymmenes päässyt yli seuraavan kynnyksen. ITIL termein 20 % on V2-tasolla ja 10 % V3-tasolla ja lähes 70 % ei ole vielä saavuttanut ITIL V2 -tasoa.

Näyttää siltä että tasoeroja ei tunnisteta. Prosessikeskeisyys ei ole sama asia kuin palvelukeskeisyys. Tämä on mielestäni ITILin kolmosversion ongelma, siitä ei käy ilmi että se kuvaa kaksi kypsyystasoa ikään kuin yhdessä. Asiakaskeskeisyyden haaste sen sijaan tunnistetaan ja valtaosa vastaajista näkee että sinne on vielä matkaa.

Tavoitteiden asetanta on vielä optimistista. Realistinen tavoite on seuraava kypsyystaso. Liiketoimintakeskeisyys tuntuu houkuttelevalta, mutta silloin tosiaankin it:n toimivuutta mitataan samalla tavalla kuin itse liiketoimintaa, siis myyntinä, kannattavuutena jne.

Jokaisen it-yksikön pitäisi tunnistaa oma kypsyystasonsa ja ulkopuolinen tarkkailija voi olla avuksi tässä. Sitten on arvioitava mikä on tarvittava kypsyys ja sen määrää asiakkaan tila. Ei ole lainkaan selvää, että liiketoimintakeskeinen kypsyystaso on oikea tavoite kaikille. Se edellyttää että it:llä on aidosti merkittävä rooli liiketoiminnassa ja näin ei ole läheskään kaikilla aloilla.

Asiakaskeskeisyys edellyttää että asiakas on halukas ottamaan merkittävän roolin it:n ohjaamisessa. Näin ei suinkaan ole aina. Palvelukeskeisyys luo myös raja-aidan asiakkaan ja palveluorganisaation välille, kuten jokainen palvelun ulkoistanut on varmasti havainnut. Voi myös pohtia riittääkö teknologian hyvä hallinta joissakin tapauksissa eli tarvitsevatko kaikki prosesseja?

Oma kypsyystaso määrittää sen, mitä pitää kehittää ja miten palvelua voi mitata. Esimerkiksi prosessien käyttöönotto takeltelee, jos ollaan edelleen vaikeuksissa teknologian kanssa. Palvelujen tason mittaaminen on vaikeaa, jos prosessit eivät toimi jne. Johtamisen täytyy myös olla vastaavalla kypsyystasolla. Kaikki tämä on helpompi sanoa kuin tehdä.

Help desk hengissä

Olen havainnut että help deskit ovat alkaneet taas kiinnostamaan, kursseilla on kysyntää ja toimeksiannot liittyvät tuen kehittämiseen. Keksin tarkastaa asian Googlesta ja sain vahvistuksen. Alla olevassa kuvassa on kolmen hakusanan vertailu. Sininen on help desk, punainen on ITIL, ja keltainen service desk. (Huom. kohteena on USA koska itil tarkoittaa indonesiaksi erästä naisen elintä ja se on liian kiinnostava.)

Kuva kertoo kaksi mielenkiintoista asiaa. Ensinnäkin, itilin service desk ei ole lainkaan niin kiinnostava kuin perinteinen help desk. Tämä yllätti minut. luulin että service desk on ollut korvaamassa vanhaa termiä.

Toinen havainto on että itilin ja help deskin kiinnostavuus ovat kuin peilikuvat. Itil oli kasvussa vuoteen 2007 asti, josta alkoi jyrkkenevä alamäki. Help desk taas oli laskussa vuoteen 2008 asti, mutta on nyt hienoisessa nousussa.

Oma tulkintani on se, että ihmiset alkavat tajuavan totuuden itilistä, eli parhaat käytännöt eivät täytä lupauksiaan. Uusi 2011 edition taas sisälsi sen myönnytyksen että V3 oli täynnä virheitä.

Toisaalta taas help deskiin kohdistuu uusia haasteita ja niihin kaivataan uusia ratkaisuja. Asiakkaiden vaatimukset muuttuvat ja niihin on vaikea vastata vanhalla mallilla.

Service Desk 2.0 -malli, jota olen kehittelemässä, on yritys vastata muuttuneeseen tilanteeseen. Pitäisiköhän alkaa sittenkin puhua Help Desk 2.0;sta?

 

%d bloggers like this: