Pohjoismainen malli ja parhaat käytännöt

Helsingin Sanomat kertoi aamun lehdessä että ruotsalaiset demarit ovat rekisteröineet pohjoismaisen mallin. Kirjoittaja kritisoi toimenpidettä: Pohjoismainen malli on aina muuttunut ja muuttuu koko ajan. Sen sisältö saa eri muotoja ajankohdan ja maan mukaan. Mielestäni tämä osuu myös ITILin ytimeen. It-palvelunhallinta muuttuu ja kehittyy koko ajan. ITIL-kirjat esittävät yhden näkemyksen yhdestä vaiheesta.

Merkkisuojahanke todistaa, että puolue elää liiaksi menneisyydessä eikä pysty tarjoamaan yhteiskuntapoliittista ohjelmaa tulevasta. Historiasta voi oppia, mutta sitä ei kannata patentoida eikä siinä ole syytä elää. Sama sopii hyvin ITILiin. ITIL on historiaa, siihen ei pidä takertua.

It-palvelunhallinnalla on edessä joukko suuria haasteita, tässä joitakin:

1) Teknologia kypsyy kovaa vauhtia, kuluttajille suunnatut laitteet ovat vaivattomia ja helppoja käyttää.

2) Pilvipalvelut laskevat palvelutuotannon hinnan sietämättömän halvaksi.

3) Asiakkaat pystyvät tekemään itse asioita, joihin ennen tarvittiin ammattilainen.

Perinteinen it-yksikkö toimi kuin sosialistinen diktatuuri. Viisivuotissuunnitelmat ohjasivat toimintaa ja ylhäältä kerrottiin massoille, minkä harmaan sävyisellä laatikolla tehdään töitä seuraavat kolme vuotta. Nyt rautaesirippu on murtunut ja vapaus voittaa. Keskitetty ohjaus romahtaa ja asiakkaat saavat valita itse mitä tekevät. Vapaudella on toki kääntöpuolensa ja ongelmia tulee. Niiden liioittelu ei kuitenkaan estä muutosta.

Nyt pitää olla ketterä ja aktiivinen. On autettava asiakkaita löytämään uusia mahdollisuuksia, on mentävä lähemmäs liiketoimintaa ja kyettävä luomaan todellista hyötyä. Mikään it:ssä ei omaa itsearvoa, mutta tähän harhaan on helppoa erehtyä, jos elää suljetussa konesalissa. Voi toki perustella järjestelmän viilaamista asiakkaan hyödyllä, mutta entä jos asiakkaan kannalta olisikin parempi romuttaa koko järjestelmä. Tätä ei voi nähdä, jos elää järjestelmän sisällä ja katselee asiakkaita etäältä.

Tämä ei ole sanahelinää. Tämä on tekemistä. Et varmaan voi tehdä kaikkia näitä asioita, mutta voit varmasti tehdä jonkun näistä:

  • Opiskele uusia laitteita ja palveluja, anna niitä asiakkaille, ideoi heidän kanssaan käyttökohteita vaikka iPadille.
  • Onhan sinulla jo ilmainen serveri pilvessä?
  • Jos asiakkailla on kotona heidän mielestään paremmat laitteet, kytke ne firman verkkoon ja junaile tuki.
  • Tutustu verkon palveluihin, jos CRM on jäykkä kokeile verkkovaihtoehtoa http://www.webcrm.com/fi/. Ontuuko dokumentinhallinta, voisiko http://www.sopima.fi/ pitää edes sopimukset järjestyksessä, jne.
  • Muista että tehtäväsi ei ole pyörittää nykyisiä järjestelmiä tehokkaasti, vaan auttaa liiketoimintaa parempaan tulokseen. Miten voit tehdä sen, jos et ymmärrä mitä he tekevät. Älä haaveile tulevasi paremmaksi Active Directory -asiantuntijaksi, vaan haaveile miten tulet paremmaksi toimialasi asiantuntijaksi. Miten voisit oppia tänään jotain uutta asiakkaistasi?
  • Osaathan Facebookin, Twitterin Google+, LinkedIn’in jne. Kai tiedät miten FaceBookia käytetään vaikka Service Deskin tukisivuina.

Monet ovat jo varmasti tehneet näitä asioita, nyt pitäisi alkaa kerätä kokemuksia ja vertailla käytäntöjä. Sillä tavalla syntyy uusia parhaita käytäntöjä. Niitä vain ei sitten opeteta sertifiointikursseilla.

Älä mittaa asiakastyytyväisyyttä näin.

Saavut illalla hotelliin. Kaikki on hyvin kunnes istahdat huoneesi sängylle, joka pettää altasi. Soitat respaan ja muutamassa minuutissa paikalle singahtaa reipas tiimi, joka vaihtaa sängyn ja pahoittelee kovasti häiriötä. Saat jopa pikkupullon kuohuviiniä hyvitykseksi. Kun avaat pulloa, puhelin soi ja sinulta kysytään miten hyvin tapaus hoidettiin. Annat vitosen asteikolla 1-5.

Seuraavana aamuna kun olet lähdössä pois, oven kahva jää käteesi. Soitat taas apua ja kerrot että nyt on kiire. Ei kestä kuin 60 sekuntia ja ovesi aukeaa ja korjaaja pahoittelee tapausta. Hän ojentaa sinulle 50% alennuskupongin hyvitykseksi. Poistuessasi vastaanottovirkailija vielä kysyy miten hyvin tapaus hoidettiin. Vastaat taas 5/5, mutta samalla rypistät tarjouskupongin ja pudotat sen roskiin. Tähän hotelliin et taatusti tule toista kertaa ja päätät varoittaa kaikkia muitakin.

Hassuinta on, että juuri näin monet Service Deskit mittaavat asiakastyytyväisyyttä ja kaikki raportoivat loistavia tuloksia. Tässä suositukseni:

1) lopeta tuollaiset mittaukset heti, ja

2) ala mitata palvelun laatua, ei Service Deskin palvelun laatua ja kysy kaikilta asiakkailta (tai satunnaisotokselta), ei vain niiltä, jotka ovat olleet yhteydessä deskin kanssa.

Ovatko huonot työkalut syynä it-palvelunhallinnan epäonnistumisiin

Luottamuksellisissa keskusteluissa alan ihmisten kanssa nousee esiin it-palvelunhallinnan hankkeiden epäonnistuminen. Tutkimuksissa ja seminaariesityksissä näistä ei kuitenkaan puhuta. Tarjosin IKEA-efektiä syyksi edellisessä artikkelissa ja se voi selittää ristiriidan raportoinnissa, mutta ei kuitenkaan kerro miksi hankkeet epäonnistuvat niin usein. Huonot työkalut sen sijaan voisivat olla epäonnistumisten takana.

On vähän irvokasta, mutta toki hyvin ymmärrettävää, että it-väen oma prosessikehitys kaatuu juuri huonoihin työkaluihin. ITILin mukainen prosessimalli on haastava kokonaisuus ja sitä tukeva työkalu on lähes yhtä monimutkainen kuin ERP- tai CRM-järjestelmä. On selvää, ettei sisäiseen työkaluun voi satsata kovin paljoa resursseja ja siksi tulos jää helposti puolinaiseksi.

Tämä herättää kaksi kysymystä.

1) Pitääkö tulos paikkansa?

Olen saanut jonkin verran palautetta, joka vahvistaa tulosta, mutta lisää havaintoja olisi hyvä saada. Paras tapa olisi tehdä tutkimus yrityskohtaisena ja suunnata se niille, jotka käyttävät  tai joiden pitäisi käyttää järjestelmää.

2) Miten ongelman voisi ratkaista?

Tuskin rahalla. Järjestelmän räätälöiminen toimivaksi on varmasti huonoin ratkaisu. Se on kallista ja version vaihdot tuottavat ongelmia. Järjestelmän vaihto voisi auttaa, jos markkinoilta löytyy parempia vaihtoehtoja.

Keventäminen voi olla paras vaihtoehto. Turhan tiedon kirjaaminen pitää lopettaa. Jokainen järjestelmän kenttä ja ominaisuus kannattaa arvioida kriittisesti. Käytetäänkö tietoa, käytetäänkö ominaisuuksia?

On myös tärkeää, että järjestelmä auttaa käyttäjiä, esimerkiksi rutiinien automatisointi ja kätevä tiedonhaku voivat lisätä järjestelmän suosiota.

Suositukseni: 1) Tutki asia 2) Kevennä ja automatisoi järjestelmää mahdollisimman paljon.

IT palvelun toimivuus

Lähetin viime viikolla kyselyn it-palvelujen laadusta. Siihen on nyt vastannut 60 henkeä ja esittelen joitakin tuloksia. Tämä kysely on toki tarkoitettu organisaation sisäiseksi, jolloin sillä voidaan vertailla palvelua eri osa-alueilla.Kysely on mielestäni nyt valmis ja toimiva. Sitä voi käyttää esimerkiksi eri palvelujen vertailuun, mutta myös vaikkapa yksiköiden väliseen vertailuun tai kehityksen seurantaan.

Tässä esittelykyselyssä verrataan erityyppisiä palveluja.  Tulokset ovat mielenkiintoisia, ja raportoin osan tuloksista tässä.

Tukee työssä
aiheuttaa merkittävästi ylimääräistä työtä 4 %
aiheuttaa ylimääräistä työtä 38 %
neutraali 14 %
säästää minulta aikaa 27 %
säästää minulta paljon aikaa 18 %

Peräti 42 % vastaajista raportoi että jokin it-palvelu aiheuttaa lisää töitä ja vain 45 % raportoi palvelun säästävän aikaa. Tämä on aika tyly vastaus, eteenkin kun lukijani koostuvat pääosin it-väestä.

Kilpailukyistä
on paljon huonompaa kuin muualla 2 %
on huonompaa kuin muualla 25 %
on yhtä hyvä kuin muualla 37 %
on parempi kuin muualla 28 %
on paljon parempi kuin muualla 9 %

Ruoho ei näytä olevan vihreämpää aidan takana vaan kolme neljästä sanoo, että omat järjestelmät ovat yhtä hyviä tai parempia kuin muiden. Tässä kannattaa taas muistaa, keitä vastaajat ovat.

Vaikeuksia
päivittäin 5 %
viikoittain 18 %
kuukausittain 14 %
muutaman kerran vuodessa 37 %
harvemmin 26 %

Alle 40% kokee vaikeuksia kuukausittain tai useammin, joskin melkein neljänneksellä on vaikeuksia viikoittain tai useammin.

Palvelujen välillä on mielenkiintoisia eroja.Vastauksista löytyi viisi palvelutyyppiä, joihin tuli riittävästi vastauksia vertailun kannalta. Vertailun tulos oli yllätys. Tuntikirjanpitoa osasin epäillä, mutta tikettien käsittelyn epäsuosio yllätti. Alla olevassa kuvassa ovat vastaukset kysymykseen: Miten hyvin organisaatiosi tarjoama IT-palvelu tukee sinua työssäsi?

Tässä graafissa asteikon keskikohta on neutraali 3 ja mahdolliset vastaukset ovat välillä-2 – +2

Luokittelin vastaukset kolmeen ryhmään.

Yli +0,2      = hyvä
-0,2 – +0,2 = keskinkertainen
Alle -0,2     = huono

Näin tulkittuna jokainen sovellus menee omaan lokeroonsa. Matka/kululaskutus on joka suhteessa hyvä. Laskujen käsittely tekee tehtävänsä. Tuntikirjanpito ei ole hyvä mutta toimii ok. Kokouspalvelut ovat keskinkertaisia. Yllättävin tulos minulle on, että ITIL tikettien käsittely on huono kaikilla mittareilla.

laji tukee kilpailukyky vaikeuksia
 matka/kululaskutus hyvä hyvä hyvä
 laskujen käsittely hyvä keskinkertainen hyvä
 tuntikirjanpito keskinkertainen keskinkertainen hyvä
 kokouspalvelu, videoneuvottelu yms. keskinkertainen keskinkertainen keskinkertainen
 tikettien käsittely (ITIL-prosessit) huono huono huono

Tulos on jonkin verran ristiriitainen ITSMF:n tuoreen jäsenkyselyn ennakkotuloksiin verrattuna. Siinä mm. kysyttiin vastaajilta kuinka hyvin ITIL palvelee heitä ja tutkimuksen tulosten mukaan se palvelee hyvin

ITSMF:n kyselyssä taitaa olla kyse ns. IKEA-efektistä.  IKEAn nerokas oivallus on ulkoistaa kalusteiden kokoaminen asiakkaille. Se tuo mahtavia säästöjä,  kun työläs kokoonpano jää pois ja puolivalmiit tuotteet vievät vähän tilaa. Lisäksi asiakas suhtautuu itse koottuun kalusteeseen eri tavalla. IKEA-efekti tarkoittaa sitä positiivista tunnetta, joka syntyy johonkin tulokseen silloin, kun sen eteen on nähnyt paljon vaivaa. Itse koottu ei ole ehkä ihan täydellinen, mutta se ei haittaa.

Sama ilmiö on nähtävissä toiminnan kehittämisessä. Johto kehittää toimintaa jollakin menetelmällä. Kehittäminen osoittautuu työlääksi ja lopputulos on kaikkea muuta kuin täydellinen, mutta koska siihen on uhrattu niin paljon vaivaa, sen on pakko olla hyvä. Tämä harhakuva elää sitten aikansa, kunnes joko johto vaihtuu tai avaa silmänsä.

ITSMF:n kyselyyn valikoituu vastaajiksi innokkaita ITIL-kehittäjiä ja he eivät pysty katsomaan lopputulosta objektiivisesti.Tulee mieleen vanha episodi. Osallistuin aikoinaan tuotannonohjauksen kehittämiseen Tietotehtaalla. Kollegat kertoivat tarinan jostain aiemmasta yrityksestä ratkaista sama pulma. Järjestelmä oli perustunut suureen tauluun, johon aseteltiin ajettavat työt. Menetelmä oli susi ja jäi pian käytöstä, mutta kukaan ei kertonut sitä keskuksen johtajalla. Lopulta operaattorit keksivät käyttää ohjaustaulua pingispöytänä ja sitten eräänä päivänä tietokonekeskuksen johtaja sattui paikalle, kun peli oli käynnissä. Hän katsoi hienoa ohjaustauluaan ja oli hetken hiljaa ja sanoi sitten: ”No, voihan sitä tuohonkin käyttää”. Sen jälkeen aihetta ei käsitelty.

Jos prosessityökaluihin suhtaudutaan noin kielteisesti, voi ennustaa että niiden käyttö tullee hiipumaan, kunhan johdon painostus hellittää. En usko että käskemiseen ja hierarkiaan nojaava prosessikehitys tuottaa positiivisia tuloksia pitemmän päälle.

Mitenköhän teillä niihin suhtaudutaan? Ota yhteyttä, jos haluat teettää kyselyn, tämä on todella helppo ja nopea tehdä.

Adaptive Case Management

Joustava tapaustenhallinta on menetelmä, jota voidaan soveltaa monenlaisiin asioihin. Potilaat, oikeusjutut, yrityskaupat, monimutkaiset vakuutuskorvaukset ja erilaiset ongelmat ovat esimerkkejä tapauksista, joiden käsittelyä voi olla vaikea määritellä suoraviivaiseksi prosessiksi. Näille on ominaista yllättävyys ja monenlaiset kytkennät. Asiaan saattaa liittyä uusia asioita ja kokonaisuudesta kasvaa monimutkainen vyyhti.  Luin aiheesta kirjan: Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done.

Kirja herätti pohtimaan asiaa it-palvelunhallinnan kannalta. Ensinnäkin kirjan kuvaama tilanne on varmasti tuttu monelle it-pulmien kanssa painiville.

Asiakkaan kokema häiriö liittyy vähän aikaisemmin tehtyyn muutokseen, joka liittyy taas aiemmin havaittuun ongelmaan. Nyt tehty muutos on aiheuttanut uuden ongelman ja molempiin liittyy erilaisia häiriöitä. Muutoksen palauttaminen ei ole yksiselitteistä. Tapahtumaketjun kuvaaminen ja kirjaaminen johonkin järjestelmään on hankalaa, eikä niiden käsittely mene prosessin mukaisesti. Käsittelyyn liittyy ulkopuolisia henkilöitä ja sitä puidaan kokouksissa ja asiasta kirjoitetaan paljon sähköposteja. Millaisen tiketin siitä voi tehdä?

Joustava tapaustenhallintaan tarvittaisiin myös joustava työkalu, jonka avulla tapaus voidaan dokumentoida ja joka auttaa sen käsittelyssä. Asiantuntijat harvoin lähtevät tyhjältä pöydältä, vaan hyödyntävät jotain aikaisempaa tapausta pohjana. Työkalun pitäisi myös tukea käsittelyssä käytettäviä prosesseja ja siihen liittyviä sääntöjä.

It-palvelunhallinnan kannalta kirjasta nousi esiin muutama erityistä mietintää aiheuttava väite:

  • Prosessit eivät sovi hyvin tietotyöhön. Tietotyön tekijä on luova ja juuri luovuus tuo työlle lisäarvoa. Rutiininomainen prosessityöskentely rajoittaa luovuutta ja heikentää työn tuottavuutta.
  • Prosessi soveltuu ennustettaviin ja toistuviin vaiheisiin ja prosessityökalu tukee vain niitä vaiheita.

Kirjan nimen mukaan kyseessä on vallankumouksellinen menetelmä. Prosessien rajaaminen vain yksinkertaisiin rutiineihin olisi it-palvelunhallinnan kannalta todella aikamoinen mullistus. Olen itse ollut opettamassa prosessiajattelua jo toistakymmentä vuotta ja täytyy myöntää että tämä vallankumous tuntuu aika rajulta. Suoranaista poisoppimisen tuskaa…

Menetelmä kuuluu toksi Service Desk 2.0 työkaluihin. Tervetuloa kuuntelemaan.

 
 

Poisoppimisen tuska

Poisoppiminen on tärkeä osa uuden oppimista. Kerran opittu malli jäykistää ajattelua ja kun ympäristö muuttuu, voidaan jäädä vanhan mallin vangiksi. Alla muutama lainaus asiasta:

“The illiterate of the twenty-first century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn.” Alvin Toffler
 “In a time of drastic change, it is the unlearners who inherit the future. The learned find themselves equipped to live in a world that no longer exists”. Eric Hoffer
 “In some sense our ability to open the future will depend not on how well we learn anymore but on how well we are able to unlearn”. Alan Kay
 “The difficulty lies, not in new ideas, but in escaping from the old ones, which ramify, for those brought up as most of have been, into the corners of our minds.” John Maynard Keynes

Minähän en tahdo poisoppia mitään

 

Kirjoitan tästä koska sanoin Service Desk 2.0 esitykseni yhteydessä, että on aika alkaa poisoppia itiliä. Tämä kommentti herätti yllättävän tunteellisia reaktioita monissa. Tuntuu siltä, että itilistä on tullut joillekin itseisarvo, jolloin puhe sen poisoppimisesta on todella järkyttävää.  Poisoppiminen on kuitenkin tärkeä osa oppimista. Yhteen menetelmään juuttuminen on vaarallista. Muistan kuinka aikoinaan kun IBM voitti kilpailun suurkoneiden markkinoilla ja kilpailevat järjestelmät katosivat Suomesta nopeasti. Yhtäkkiä niiden asiantuntijoiden ammattitaidolta katosivat markkinat hetkessä. Minulle tapaus antoi sen opetuksen, ettei pidä jäädä jonkin menetelmän tai tekniikan vangiksi.

Näyttää siltä että osa it-palvelunhallinnan ammattilaisesta on rakentanut koko osaamisensa itilin varaan, ja he väittävät ettei tietotekniikan muutokset vaikuta ns ”parhaisiin käytäntöihin”. Itse olen eri mieltä. Ala on monen suuren murroksen keskellä, pilvestä tulee halpaa prosessivoimaa ja päätelaitteet ovat lähteneet liikkeelle. Vaatii uskomattoman peittäviä silmälappuja jotta ei näe, että tämä vaikuttaa it-palvelujen hallintaan monella tavalla. Uudessa  maailmassa tarvitaan uudet parhaat käytännöt.

Missä sitten ne uudet parhaat käytännöt keksitään? Tietysti siellä missä it-palveluja tuotetaan eli siellä kentällä. Uusi käytäntö voi rakentua vanhan mallin varaan tai sitten voi olla pakko purkaa vanha ja rakentaa uusi. En tarkoita että kaikki mitä itil kertoo olisi väärin ja ettei sitä kannattaisi hyödyntää. Tärkeintä on katsoa sen opetuksia kriittisesti ja olla valmis hylkäämään huonosti toimiva prosessi.

Tulin kirjoittaneeksi vahingossa hyvän esimerkin poisoppimisen vaikeudesta kirjoittaessani sanan prosessi kun oikeastaan tarkoitin jotain muuta. Olen oppinut prosessiajattelun itilin myötä ja huomaan että se istuu aika syvällä. Nyt olen tutustunut uuteen menetelmään, jonka mukaan tietotyöläisiä ei pidä pakottaa toimimaan prosessien orjana. Joustava tapausten hallinta (Adaptive Case Management) on työskentelytapa, joka sopii muuttuviin ja monimutkaisiin tapauksiin. En ole vielä ihan varma olenko valmis hylkäämään prosessit, mutta kirjoitan lisää menetelmästä myöhemmin. Se ilmeisesti soveltuu hyvin hankalien pulmien käsittelyyn ja siksi on varmasti osa Service Desk 2.0:n työkalupakkia.

%d bloggers like this: