Mitä itilin tilalle

Kuten äskeinen prosessitutkimus osoitti, prosessien käyttöönotto on edennyt hitaasti. Help deskit toivat prosessit käyttöön jo 1990-luvulla, mutta silti ne ovat vielä 2013 ainoat toimivat prosessit monille. Vain harva on saanut vanhan itilin kymmenen prosessia toimimaan. Toisaalta koetaan että prosesseista on hyötyä ja niihin pitää panostaa.

Itil ei ole ratkaisu parempiin it-palveluihin. Se voi auttaa henkilöä jäsentämään it-palvelujen kokonaisuutta paremmin, jos tämä näkee palvelut vain teknologian silmälappujen välistä. Osa itilistä on käyttökelpoista, mutta suuri osa ei. Itilin määritelmä palveluille on heikko, määritelmä sopii vuokraamiseen mutta ei it-palveluihin. It ei todellakaan hallitse palvelujen elinkaaria. Prosesseja on aivan liian paljon eivätkä ne ole prosesseja.

Monet kysyvät mitä itilin tilalle. Alkemistit etsivät turhaan viisasten kiveä, joka muuttaisi metallin kullaksi. Hienoja menestystarinoita riitti ja aina löytyi niitä, jotka uskoivat tarinoihin. Karu totuus on, että it-palvelujohtamiseen ei olemassa kaiken kattavia parhaita käytäntöjä sen enempää kuin muuhunkaan johtamiseen. Steve Jobs epäonnistui ja onnistui, Jorma Ollilla onnistui ja epäonnistui. Heidän toimintatavoissaan tuskin oli juuri mitään yhteistä. Siksi on turha toivoa löytävänsä jotain kaikenkattavaa ohjeistusta it-palvelujen hallintaan.

Koko it-käsite on hämärtynyt ja it-palvelua voi tuottaa monilla tavoilla. Olen käyttänyt losseja ja siltoja kuvaamaan erityyppisiä palveluja. Perustarve on sama, asiakas haluaa ylittää veden ja molemmat tuottavat halutun palvelun. Silta on kallis, lossi on halvempi. Vene on vielä halvempi ja sillä pääsee jopa merkittyjen reittien ulkopuolelle. Riippuu asiakkaan tarpeesta mikä ratkaisu palvelee parhaiten. Palvelun tuottamisen kannalta palvelut ovat täysin erilaisia ja vaativat erilaiset toimintamallit.

Kuten alussa sanoin, palvelujen jäsentäminen ohi teknologian on tarpeen. Tässä on it-palvelunhallinnan ydin

  • It-organisaatio tukee asiakkaita heidän liiketoiminnassaan toimittamalla asiakkaiden käyttöön tietotekniikan varaan perustuvia välineitä
  • on tärkeää keskustella asiakkaiden kanssa heidän tarpeistaan ja odotuksistaan
  • koko toiminta pitää suunnitella kunnolla, ettei aiheuteta asiakkaille ikäviä yllätyksiä
  • on tärkeää organisoida asiakastuki,
  • pitää huolehtia häiriöiden hallinnasta
  • pitää muistaa myös poistaa häiriöiden aiheuttajat
  • muutosten koordinointi ja hyvä suunnittelu vähentää häiriöitä.

ISO 20000 tarjoaa hyviä listoja yksityiskohdista. Itil kirjoissa on erilaisia ehdotuksia siitä, miten asiat voisi tehdä. Ehdotuksia voi noudattaa soveltaen.  Uskon, että kokemusten vaihto olisi hyödyllistä. Kurssien sijaan kannattaisi järjestää työpajoja, joissa osallistujat voisivat keskustella kokemuksistaan ja kertoa omista ratkaisuista.

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

 

 

Kehittämisen organisointi

Aineisto

Tällä kertaa kyselyn kohteena oli toiminnan kehittäminen. Kysely lähetettiin Pohjoisviitan kontaktilistalle ja siihen on tähän mennessä tullut 66 vastausta. Tässä ensin kysymykset:

Tämän kyselyn kohteena on toiminnan kehittäminen. Tarkoitan sillä toimenpiteitä, joita organisaatio tekee ilman maksavaa asiakasta ja joiden tarkoituksena on parantaa tuotetun palvelun laatua joko suoraan tai välillisesti. Nyt olen kiinnostunut siitä miten kehittämistä tehdään ja johdetaan.
 
KYSYMYKSET
1 Miten oman toiminnan kehittäminen toimii?
a) meillä ei juuri ole aikaa siihen
b) tiimit kehittävät omaa toimintaansa itsenäisesti
c) meillä on erityinen kehittämisorganisaatio/henkilö, joka vastaa kehittämisestä
 
2 Millaisia tuloksia olet nähnyt tämän vuoden aikana?
a) lähinnä epäonnistumisia
b) en juuri mitään
c) onnistuneita hankkeita
d) selvää parannusta palvelun laadussa kehittämisen tuloksena
 
3 Oletko itse osallistunut johonkin kehittämishankkeeseen tämän vuoden aikana?
a) en ole
b) olen osallistunut
c) olen vetänyt hanketta
 
4 Miten esimiehet suhtautuvat kehittämisehdotuksiin?
a) en tiedä
b) niille on vaikea saada lupaa
c) niitä tuetaan
 
5 Miten organisaatio suhtautuu kehittämishankkeisiin?
a) en tiedä
b) niitä vastustetaan usein
c) passiivisesti
d) yleensä positiivisesti

Tulokset

Tällä kertaa minua kiinnosti erityisesti miten kehittämisen organisointi vaikuttaa kehittämisen tuloksiin ja siksi aloitin kysymällä, onko organisaatiossa nimetty kehittämisvastaava.

Tässä vaihtoehto a) oli mukana, koska se on kovin tavallinen vastaus, kun ehdotan jotain kehittämishanketta 🙂 Oman kehitysorganisaation osalta vastaukset menivät tasan. Monissa organisaatioissa on sekä itsenäistä kehittämistä että oma kehitysorganisaatio. Nämä on luokiteltu ryhmään c) koska olin kiinnostunut kehitysorganisaation vaikutuksesta.

Vastaajien mielestä hankeet yleensä onnistuvat, mutta vain vajaa 30% sanoi niiden johtaneen selvää parannukseen palvelun laadussa. Toki hankkeilla voidaan pyrkiä myös esim.kustannussäästöihin.

Lähes kaikki vastaajat olivat joko osallistuneet tai vetäneet jotain kehittämishanketta. Monet ovat tehneet molempia jolloin heidät on luokiteltu vetäjien ryhmään.

Johto suhtautuu yleensä kehittämishankkeisiin myötämielisesti.

Organisaation asenne on samoin yleensä myötämielinen, mutta vastustusta tai pasiivisuutta esiintyy 40% vastaajista. Mielenkiintoista oli, ettei kukaan valinnut vaihtoehtoa: ”en tiedä”.

Oma kehittämisorganisaatio näyttää saavan aikaan parempia tuloksia kuin tiimien itsenäinen kehittäminen. Luonnollisesti toimintaa kehittävät saavat aikaan enemmän kuin ne, joilla ei ole siihen aikaa. (Klikkaa kuvaa, niin näet sen suurempana, kuvan ja pitkien tekstien asettelu oli haastavaa)

Vetäjät suhtautuvat hiukan opitimistisemmin saavuttamiinsa tuloksiin kuin osallistujat . Kaikkein optimistisimpia ovat ne, jotka eivät ole osallistuneet hankkeisiin, mutta tämä ryhmä oli hyvin pieni.

Henkilöstön suhtautuminen kehittämiseen on positiivisempaa silloin kun ei ole erityistä kehittämisorganisaatiota. On mielenkiintoista että ne, jotka sanovat että kehittämiseen ei ole aikaa, olettavat myös että henkilöstö suhtautuu kehittämiseen kielteisesti.

Henkilöstön suhtautumisella on selvä vaikutus hankkeiden onnistumiseen. Kun organisaatio suhtautuu positiivisesti, hankkeista epäonnistuu 15%, silloin kun henkilöstö vastustaa tai on passiivinen hankkeista epäonnistuu n. 40%.

Lopuksi jaoin vastaukset kahteen ryhmään sen mukaan edustaako vastaaja sisäistä it:tä vai palveluyritystä. Vastauksista löytyi selviä eroja. Palveluorganisaation kehittämishankkeet onnistuvat useammin ja niistä 40% tuottaa parannuksia palvelun laatuun. Palveluyrityksissä myös näytetään tietävän kehittämisen tulokset paremmin.

Kehittämisorganisaatio on tavallisempi palveluyrityksissä.

Tulkinta

Tutkimuksen tuloksia arvioidessa pitää muistaa, että vastaajat ovat henkilöitä, jotka arvioivat osin omaa työtään. Toisaalta Pohjoisviitan tutkimuksissa on tavallista, että vastaajat ovat kriittisiä oman organisaationsa toiminnan suhteen.

Näyttää siltä, että omasta kehittämisorganisaatiosta on hyötyä ja että palveluyritykset pystyvät ohjaamaan oman toimintansa kehittämistä paremmin kuin sisäiset yksiköt. Olen itse suhtautunut sisäiseen kehittämiseen aika epäillen, (ehkä osin siksi, että näin konsultin näkökulmasta sisäiset kehittäjät ovat joissakin tapauksissa kilpailijoita tai ainakin jarruja konsultoinnin myynnin kannalta). Odotin heikompaa tulosta sisäisten kehittäjien työlle, mutta tulos kertoo päinvastaista. Kehittämisvastuun määrittely on suositeltava käytäntö. Esimerkiksi ISO 20000 asettaa paljon vaatimuksia toiminnan jatkuvan kehittämisen suhteen ja ne vaatimukset on varmasti helpompi täyttää, jos tehtävään on nimetty erityinen henkilö.

Henkilöstön ottaminen mukaan kehittämiseen on tärkeää ja joissakin tapauksissa oma kehittämisorganisaatio voi vähentää henkilöstön roolia. Koska henkilöstön vastus tai pasiivisuus lisää epäonnistumisen riskiä, on tärkeä huolehtia siitä, että kehittäjät eivät pääse etääntymään käytännön työstä.

Riskienhallinta

Riskienhallinta on meidän kaikkien vastuulla. Se ei ole mikään salaperäinen asia, jota vain siihen vihkiytyneet henkilöt harjoittavat. Esimerkiksi jokainen muutos infrastruktuurissa ja jokainen yhteydenotto service deskiin sisätää jonkin määrän riskiä. Riskin luonteen ja määrän arvioiminen ei ole helppoa, mutta parhaiten sen voi tehdä se, joka tuntee tehtyjen toimenpiteitten sisällön. Riskienhallinnan pitäisi olla osa jokaista it-palvelunhallinnan prosessia ja toimintoa sillä it-palvelu on melkoinen riskien lähde.

Riskienhallinnan tulisi olla arkipäiväistä toimintaa, se toimii vain jos sitä tehdään jatkuvasti. Ympäristö muuttuu koko ajan ja riskejä pitää arvioida uudestaan.  ITIL puhu ennakoivasta ongelmahallinnasta mutta se on liian suppea käsite.

Riskienhallinnalla on ollut oma standardi jo pari vuotta, ISO 31000. Standardi on myös käännetty suomeksi. Standardin ansiosta riskienhallinalle on olemassa selkeä malli ja ohjeistus.

Järjestän työpajan riskienhallinnasta 28.11. Vantaan Leijassa.

OHJELMA

0900 Avaus
0930 Termit ja määritelmä
1030 Riskienhallinnan suunnittelu
1130 Lounas
1230 Riskienhallinnan prosessi 
1330 Kahvi
1400 Riskien arviointi
1500 Riskien käsittely
1530 Toiminnan kehittäminen
1600 Työpaja päättyy

Työpajan hinta on 480 € + alv. Materiaali toimitetaan pdf-muodossa ja saat myös työpajan tulokset käyttöösi tilaisuuden jälkeen. Ilmoittaudu heti tästä linkistä.

Hidasta edistystä edelleen

Työkalututkimuksen tulosten mukaan n. 20% on edistynyt prosessien käyttöönotossa, mutta 80% käyttää työkalua lähinnä Service Deskissä. Tämä tulos vastaa sitä yleistä käsitystä, että itilin mukaisten prosessien todellinen käyttöönotto ei ole edennyt kovin pitkälle. Perinteinen malli on, että opiskellaan itiliä, kuvataan prosessit ja hankitaan työkalu tukemaan niitä. Joskus menetelmä tuottaa hyviä tuloksia, mutta yleensä ei. On tavallista että kehitys pysähtyy ja prosessit rapistuvat.

Jos prosessit ovat kunnossa, ne näkyvät. Tässä testikysymyksiä. Prosessit ovat hallinnassa, jos teillä käydään tällaisia keskusteluja:

  • Järjestelmän X tikettien määrä on kasvanut 27% ja sen takia sitä pitää kehittää.
  • Muutosten läpivienti vie keskimäärin 14 vrk ja se halutaan pudottaa 5 vuorokauteen.

Itil buumi alkoi Alankomaissa 10 vuotta aiemmin kuin Suomessa. Silti siellä tuskaillaan saman ilmiön kanssa. Prosesseja on vaikea saada toimimaan. Jan van Bon kertoo kehittäneensä menetelmän, jolla prosessit saadaan oikeasti toimimaan. Ytimenä on  palvelunhallinnan ohjausjärjestelmä (Service Management System), jonka mm. ISO 20000 vaatii. Prosesseja on paljon vähemmän kuin itilissä, mutta ne kattavat samat alueet.

Kiinnostaisi päästä kokeilemaan Janin metodia. Siihen tarvittaisiin asiakas, joka on todennut, että kovasta yrittämisestä huolimatta itilin käyttöönotto ei etene ja että tarvitaan uusi lähestymistapa.

 

Viides ISO 20000 sertifikaatti Suomeen

Tietojeni mukaan Suomessa on nyt viisi ISO/IEC 20000 sertifikaatin saanutta yritystä.

Crescom
Descom
Fujitsu
Istekki
Nice

Kertokaa jos niitä on enemmän.

Kanasainvälisiä lukuja ei ole saatavissa. APMG:n luettelo sertifikaateista on puutteellinen. Siinä esim. mainitaan vain kaksi suomalaista sertiä ja 17 espanjalaista, vaikka molemmissa maissa niitä on huomattavasti enemmän.

 

Vuoden 2011 ja 2010 hakusanat

Tässä vertailua hakusanoista vuonna 2011 ja 2010.

Insidentti on pudonnut selvästi, mutta aiheuttaa silti edelleen päänvaivaa. Itil V3 on pompannut kärkeen mutta itil kirjallisuus ja -prosessit ovat kadonneet. Palvelukatalogi (-luettelo) on nousussa. ISO 20000 näyttäisi olevan myös nousemassa, uusi 2011 versio ainakin on herättänyt kiinnostusta paljon enemmän kuin ITIL 2011.

Klikkaa kuvaa, jottaa siitä saa selvää.

Tässä vuoden 2011 yleisimmät hakuaiheet, tällä listalla  joitakin samankaltaisia hakusanoja kuten ITIL ja ISO 20000 on yhdistelty, jotta aiheet näkyisivät selvemmin.

itil
iso 20000
pohjoisviitta
insidentti
palvelukatalogi
ongelmanhallinta
muutoksenhallinta
asiakaspalaute
it palvelunhallinta
hashtag
service desk
aale roos
konfiguraationhallinta
prosessikaavio
palvelujen määrittely
häiriönhallinta
merimerkit
cobit
palvelun elinkaari
accenture + india + finnish rail
hp service manager
asiakastyytyväisyys
herätteiden hallinta
spoc
saatavuuden hallinta
remedy ars
tapiola
asiakassuhde
omaguru
kapasiteetin hallinta
google+ kutsu
request fulfillment
help desk tiketti ohjelma
polvi
bmc itsm
ipad
asiakaspalvelu
vanha pohjoisviitta
palvelupyyntöjen hallinta
exinon
reklamaatioprosessi
tekninen palveluluettelo
atk palvelut ja niiden haasteet
otrs konsultti
ars remedy suomi
helpdesk tukipalvelu
ulkoistus viitekehys
altiris+bmc+service-now+service+manager
tiketti itil
tedx helsinki 2011
palvelun mittarit
yleisin hakusana
stockmann it
marko jäntti
geneerinen prosessi
nomis helpdesk vai altiris
incident määritelmä
valtion it palvelukeskus iso 20000
exin
mitä on palvelulähtöisyys
erkki viitanen
reklamaatio prosessi
help desk asiakastuen käsikirja.
mitä haasteita palvelujen myynnissä on?
mikä on palvelupyyntö prosessin (request fulfilment) tarkoitus
%d bloggers like this: