Palveluyksikön toiminnan kehittäminen

Palvelun erityisluonne

Joskus näyttää siltä että palvelutoiminnan erityisluonne unohtuu kun suunnitllaan muutoksia. Palvelu on tässä ja nyt, sitä ei voi varastoida ja usein asiakas osallistuu toimintaan. Finnairin matkatavarashow on hyvä esimerkki siitä, miten näkyvä vaikutus pienen palveluyksikön henkilökunnan tunteilla voi olla koko yrityksen kannalta. Palveluyksikön toiminnan kehittämiseen liittyy aina joitakin erityisiä haasteita. Palveluyksiköllä tarkoitan sellaista organisaatiota, joka suoranaisesti palvelee sisäisisä tai ulkoisia asiakkaita. Tässä tavallisempia karikoita:

  1. Asiakkaat ovat tottuneet nykyiseen tapaan toimia. Tämä ei ole suuri pulma, jos asiakkaat ovat tyytymättömiä, mutta on iso haaste, jos merkittävä osa heistä on tyytyväisiä nykyiseen käytäntöön.
  2. Muutoksen aiheuttama vastustus ja mielipaha henkilöstön keskuudessa näkyy palvelun laadussa. Ensivaikutelma on tärkeää ja siitä ei tule hyvä, jos asiakas kohtaa vihaisen tai järkyttyneen palveluhenkilökunnan.
  3. Palvelun on jatkuttava muutoksen valmistelun aikana. Voi olla vaikeaa kouluttaa henkilökuntaa uuteen toimintatapaaan jos palvelulla on jatkuva korkea kuormitus.

Palvelun kehittämistä ei voi johtaa suoraan asiakkaiden tyytyväisyyden perusteella. Joskus kehittämisen moottorina on jokin pätevä sisäinen tai ulkoinen syy. Kustannuspaine on erittäin tavallinen syy. Jos loppukäyttäjille on tarjottu luksuspalvelua, voi käydä niin että palvelun maksaja ilmoittaa että luksuksesta on luovuttava. Toinen aika tavallinen tilanne on ympäristön muuttuminen. Vanha tapa palvelee ehkä vain vanhoja asiakkaita, mutta uusi ympäristö edellyttää toisenlaista tapaa toimia. Asiakkaat eivät useinkaan ole mikään yhtenäinen ryhmä. Hyvä tiedottaminen auttaa mutta ei ratkaise ongelmaa.

Henkilöstön tuki muutokselle on ensiarvoisen tärkeää. Muutoksen onnistumisen todennäköisyys ei ole kovin korkealla, jos sekä asiakas että asiakaspalvelija liittoutuvat vastustamaan sitä. Varma tapa saada henkilöstö takajalloilleen on sanelujohtaminen. Henkilökunnan on osallistuttava uuden palvelun suunnitteluun ja heidän on ymmärrettävä muutoksen perusteet.

Jatkuvan palvelun tuottaminen on haaste. Monissa tapauksissa on vaikea järjestää rauhallisia koulutustilaisuuksia, jossa uutta palvelua perusteltaisiin, suunniteltaisiin tai koulutettaisiin. Työ joudutaa pilkkomaan pieniin palasiin ja se vie aikaa. Nopeisiin muutoksiin liittyy suuria riskejä.

Tavoitteiden merkitys

Toinen näkökulma toiminnan kehittämiselle on selkeiden tavoitteiden merkitys. Allaolevassa kuvassa esitetään kartoitukseni tuloksia. Kysyin haastattelussa oli prosessin kehittämishankkeella ollut joki erityinen tavoite. Luokittelin vastaukset kolmeen ryhmään 1) vastaaja ei tiennyt, 2) tavoitteena oli itil-prosessin käyttöönotto 3) tavoitteena oli jokin selvä toiminnallinen tavoite.

Onnistumista mitattiin prosessin kypsyysarviolla, mittarina oli ISO 20000 kypsyysarvio. Tulokset osoittavat selvästi, että tavoitteiden olemassaolo johtaa suurempaan kypsyyteen (tai sitten se osoittaa että ne jotka onnistuvat kehittämisessään, määrittelevät myös tavoitteita). Oli miten oli, kehittäminen ei näytä onnistuvan ilman tavoitteita.

Onko kaikkien tavoitteiden oltava mitattavia? Olen alkanut hiukan epäillä sitä vanhaa sanontaa, jonka mukaan jos ei voi mitata, ei voi johtaa. Monia asioita voi aistia nopeasti ja monia asioita voi mitata huonosti. Luin artikkelin (tänä nettiaikana alkaa olla mahdotonta muistaa lähteitä, olisiko ollut Harward Business Review), jossa varoitettiin että vaikeimmin mitattava asia saattaa olla se tärkein tavoite.

Yhteenveto

Kehittäminen asiakasrajapinnassa on haasteellista ja riskialtista. Siksi sitä pitää lähestyä varoen. Kehittämisellä pitää olla selkeä tavoiteltu vaikutus, pelkkä mallin soveltaminen tai sertifikaatin hankkiminen on huono tavoite. Ei kuitenkaan tarvitse lannistua, jos tavoitteen mittaaminen on vaikeaa.

Palvelukyselyn tulokset

Tein vuodenvaihteen aikaan pikakyselyn ulkoistetun palvelun laadusta. Halusin vastauksen kolmeen väitteeseen:

1) Olen törmännyt väitteisiin, jonka mukaan SLA tavoitteiden toteutuminen ei tarkoita että palvelu olisi hyvää.

2) Epäilen että asiakastyytyväisyysmittauksia vääristellään

3) Minulle on kerrottu että palvelu on kehnoa ISO 20000 sertifikaatista huolimatta.

Vain yksi noista väitteistä näyttäisi pitävän paikkansa kyselyn valossa, lataa pdf-raportti tästä: palvelukysely. (Ei edellytä rekisteröintymistä tms).

Kyllä ITIL on vaikeaa, osa 2

Täytyy jatkaa tätä sarjaa kun eteen tuli taas hyvä case. Eräs suomalainen itil-kouluttaja esittää LinkedInissä seuraavan kysymyksen:

Kysynnänhallinnan ja kapasiteetinhallinnan ero (demand vs. capacity)

ITIL esittää nämä kaksi rinnakkaista prosessia, demand on strategiakirjassa ja capacity design-kirjassa. Ajattelin kirjoittaa niistä enemmänkin mutta onko kukaan muu hahmottanut niiden eroa? Eläköön – on niissä se pienoinen ero!

Kysymys oli niin outo, että minun oli pakko kaivaa tekstit esiin. Ensinnäkin ero on kaikkea muuta kuin pienoinen, kysynnän hallinta on aivan eri asia kuin kapasiteetin hallinta. ITIL V2 tai ISO 20000 Foundation kurssilla kerrotaan että kysynnänhallinta on yksi kapasiteetinhallinnan aktiviteetti. Kapasiteetinhallinta on hyvin konkreettista toiminnan suunnittelua ja varautumista tuleviin muutoksiin. Kysynnänhallinta on taas ensisijaisesti yritys vaikuttaa asiakkaiden käyttäytymiseen. Esimerkiksi Finnair harjoittaa kapasiteetinhallintaa tilaamalla uusia lentokoneita ja kysynnänhallintaa vaihtamalla lentolipun hintoja. It-yksikön on pakko harjoittaa kapasiteetin suunnittelua ostamalla levytilaa ja servereitä, mutta kysynnänhallinta on monille vaikeampaa. Toki käyttäjille voi asettaa esim. levytilarajoituksia yms. mutta eteenkin sisäisen yksikön kannalta toiminta on aika teoreettista.

Esiin noussut virhe on se, että ITIL kuvaa kysynnänhallinnan kahteen kertaan, strategiakirjassa on vähän sekava luku 5.5 Demand Management, joka lähtee kysynnän hallinnasta ja päättyy palvelupaketteihin. Service design-kirjasssa on taas luku 4.3.5.6 Demand Management, joka kuvaa kysynnänhallinnan yhtenä kapasiteetinhallinnan aktiviteettinä. Mitään ristiviittauksia ei osunut silmään. Näin tulkiten voi ymmärtää hämmentyneen kouluttajan kysymyksen paremmin. Hän siis kysyy oikeastaan: Mitä eroa on strategiakirjan kysynnänhallinnalla ja service design -kirjan kapasiteetinhallinnalla, joka sisältää kysynnänhallinnan yhtenä aktiviteettina? Vastaus on tietysti: Eri kirjoittaja.

Tämä on vielä yksi esimerkki niistä syistä, jotka ovat johtaneet siihen että strategiakirja kirjoitetaan kokonaan uusiksi itilin uuden version myötä.  Esimerkki kuvaa hyvin myös sitä, miten huonosti vanha ja uusi itil integroituvat toisiinsa. Kysynnänhallinta ei ole useinkaan strateginen kysymys it-yksikölle eikä sitä kannattaisi käsitellä strategiakirjassa. Sensijaan kapasiteettitarpeiden ennustaminen ja niihin varautuminen on it-strategian ydintä. Esimerkiksi konesalin vaihtaminen on useimmiten strateginen päätös.

Kyllä ITIL on vaikeaa

Tämä syksy on ollut mielenkiintoinen. En ole aiemmin tajunnut miten vaikeaa itil voi olla. Perusasioista paisuu valtavia keskusteluja ja niissä annetaan mitä kummallisempia neuvoja, kuten jo kirjoitin aiemmin.

Touhu jatkuu edelleen. Eräskin asiantuntija kuvasi kuinka lääkärilläkäynti on ongelmanhallintaa ja sitten kun lääkäri kirjoittaa reseptin, se on muutospyyntö, jonka apteekin farmaseutti sitten hyväksyy tai hylkää. Uskomatonta, luulisi nyt tollommankin tajuavan että kipeä potilas on insidentti ainakin niin kauan kun on elossa. Lääkäri tutkii potilasta ja vertaa tätä tunnettuihin tauteihin. Kun tauti löytyy on hoitokin selvillä eikä siihen pyydetä lupaa apteekkarilta.

Tauti on ongelma jos se on ennalta tuntematon uusi tauti tai tunnettu tauti alkaa lisääntyä yllättäen. Potilaan yllättävä kuolema käynnistää useimmiten kuolinsyytutkimuksen eli ongelmanhallinnan.

Olen usein puhunut siitä, että ongelmanhallinta on eniten väärinymmärretty prosessi kaikista itilin prosesseista. Havainto on perustunut omiin ISO 20000 arviointeihini. Sain tänään kuulla että Pink Elephant on tehnyt saman havainnon tekemiensä 2000 arvion perusteella. On aivan ilmeistä että monet luulevat tekevänsä ongelmanhallintaa, mutta eivät ole täysin ymmärtäneet sen merkitystä.

Insidentin- ja ongelmanhallinta muodostavat yhdessä tärkeän asiakaspalvelukoneen, joka hoitaa pulmatilanteet ja estää niiden uusiutumisen. Tämän toiminnan käynnistämiseen kannattaa käyttää vähän aikaa ja ajatusta. Ota yhteyttä niin keskustellaan aiheesta. Ensimmäinen askel saattaa olla insidenttien kirjausten kehittäminen.

IT-palvelunhallinnan vuosikymmen päättyi

IT palveluhallinnan alalla vuosi 2009 oli levoton ja tulevaisuus on samalla tavalla hämärän peitossa. ITIL 3 kritiikki yltyi niin kovaksi että OGC taipui ja lupasi kirjoituttaa kirjat uusiksi. Uusi versio (Edition, virallisesti) valmistunee vasta vuonna 2013 (se on luvattu vuotta aiemmin mutta se näyttäisi olevan jo pari kuukautta myöhässä aikataulustaan), joten ensi vuodet eletään epätietoisuudessa. Itse olen tyytyväinen siihen, että virheet ja ristiriitaisuudet myönnetään, mutta aika skeptinen sen suhteen että virheet kyetään korjaamaan tekemättä suuria muutoksia kirjoihin.

ITIL-koulutusbuumi käynnistyi meillä 2003 joten nyt alkaa jo kahdeksas vuosi. Quintin silloinen toimitusjohtaja Frank Grift ennusti että se kestää juuri kahdeksan vuotta, joten ensi vuosi saattaa olla jo hiipumisen alkua. Help Desk buumi kesti aikoinaan samat kahdeksan vuotta, joten se voi olla aika hyvä arvio. Tässä välissä on hyvä todeta se, että buumin loppuminen ei tarkoittanut että helppareista olisi luovuttu, kyse oli lähinnä konsultointi- ja koulutuskysynnän hiipumisesta.

 

Kuvassa näkyy ensimmäinen ITIL buumi, joka alkoi 1993 ja huipentui 1998. Tämä oli lähinnä hollantilainen buumi. Seuraava alkoi 2002 ja saavutti huippunsa 2004. Huom. kuvan luvut ovat kasvuprosentteja, vuoden 1998 volyymi on alle 10% vuoden 2004 volyymistä. Kasvu myös jatkuu edelleen, mutta kasvunopeus hidastuu ripeästi. Kuvan perusteella voisi epäillä että kun ITIL 3.5 julkaistaan joskus 2013, kukaan ei ehkä enää ole kiinnostunut. 

Välillä tuntuu siltä että palvelunhallinnan ydin on unohtunut. Palvelujen elinkaaria strategiaseminaareissa piirrellessä perusasiat unohtuvat helposti. It palvelunhallinnan ydin on yksinkertainen:

  • insidentit pitää hoitaa nopeasti,
  • viat pitää korjata pysyvästi  
  • hallitsemattomat muutokset ovat rikos!

Näiden tavoitteiden saavuttaminen on työlästä mutta niihin kannattaa pyrkiä. ITIL antaa joitakin vinkkejä hyvistä keinoista ja muitakin lähteitä on.

%d bloggers like this: