Yhteistyömalli

Nykyään puhutaan it-palvelunhallinnasta ikään kuin se olisi ainoa mahdollinen toimintamalli. Palvelutoimittajan rooli ei kuitenkaan ole ainoa tapa. Tietotekniikalla voi olla erilaisia rooleja liiketoiminnan suhteen. Roolit riippuvat tietotekniikan ja liiketoiminnan yhteydestä. Yhteys voi olla läheinen tai etäinen. Tässä esimerkkejä:

  1. Teknologian ylläpitäjä. It toimii kuin ydinvoimalaitos, se toimittaa palveluja usealle asiakkaalle, mutta sen toiminnassa ei ole mitään asiakaslähtöisyyttä. Toimintaa ohjaa vahva turvallisuusajattelu ja korkea käyttöaste on tärkein tavoite. Iso tietokonekeskus voi toima samalla tavalla.
  2. Palvelutoimittaja. It tuottaa tarkkaan määriteltyjä palveluja asiakkailleen. Palvelut on sovittu asiakkaan vaatimusten mukaiseksi. Palvelutoimittaja pyrkii tuottamaan sovitut palvelut mahdollisimman tehokkaasti SLA-sopimusten puitteissa. Palvelutoimittaja on lähempänä asiakasta kuin teknologian ylläpitäjä, mutta palvelu luo selkeän rajapinnan asiakkaan ja palvelutoimittajan väliin.
  3. Yhteistyökumppani. It:llä on samat tavoitteet kuin liiketoiminnalla ja niiden eteen tehdään töitä yhdessä. Rajapinta on joustava ja työnjako määräytyy tilanteen mukaan. Tämä on luontevaa eteenkin pienissä yrityksissä, joiden liiketoiminta rakentuu it:n varaan.

ITIL kuvaa palvelutoimittajan roolia ja nykyään tavoitteena on saada kaikki it-organisaatiot toimimaan tämän mallin mukaisesti. Tämä on osin perusteltua, sillä joissakin tilanteissa it voi yrittää vetäytyä teknologian ylläpitäjän rooliin, vaikka sen pitäisi olla lähempänä asiakasta.

Epämääräisesti määritelty yhteistyö voi olla sekavaa ja pahimmassa tapauksessa rakentuu täysin yksilöiden varaan. Ilman tehokkaita prosesseja ja vakaata teknologiaa, ei saada aikaan toimivaa yhteistyötä. Luottamuksen puutetta voidaan yrittää paikata sopimuksilla, mutta kokemukset opettavat etteivät SLA-sopimukset aina toimi halutulla tavalla.

Väitän, että yhteistyökumppani-malli on tavoiteltava ja mahdollinen. Se on mielestäni seuraava kehitysaskel palvelutoimittajamallista. Tämä voi tuntua utopistisella, mutta tässä yksi esimerkki sen suuntaisesta toiminnasta.

Case MetLife

MetLife on suuri vakuutusyhtiö, työntekijöitä on 64.000, vertailun vuoksi esimerkiksi OP-Pohjolassa on 13.000. Aiemmin tänä vuonna MetLife otti käyttöön FaceBookin kaltaisen sovelluksen, jonka rakentaminen vei 90 päivää. Uusi sovellus The Wall antaa asiakaspalvelun työntekijöille kokonaisnäkemyksen asiakkaasta, se näyttää kaikki vakuutukset ja kaikki tapahtumat. Aiemmin tiedot piti hakea 70 erillisestä sovelluksesta tai tietokannasta.

MetLife pyrkii leikkaamaan kulujaan palkkaamalla 1.000 teknologia-asiantuntijaa, joiden tehtävänä on kehittää uusia tapoja parempaan asiakaspalveluun. Teknologia-asiantuntijoita kannustetaan tuottamaan liikevaihtoa kasvattavia ehdotuksia. ”Teknologia ei ole vain mahdollistaja, se on tämän yrityksen kudos ja tulevaisuus” sanoo MetLifen CIO Gary Hoberman. http://money.cnn.com/2013/10/31/news/companies/metlife-wall-app.pr.fortune/

Vaatimusten haitallisuus

Palvelutoimittajamalli lähtee asiakkaan vaatimusten tunnistamisesta. Capgeminin CTO Ron Tolido kirjoittaa, että vaatimusmäärittely voi olla haitallista. Vaatimukset perustuvat usein siihen tuttuun entiseen ratkaisuun, käyttäjät eivät osaa kuvitella mikä olisi mahdollista. Tarkat vaatimukset vaativat räätälöintiä ja se on kallista. Tuloksena on kallis ja huonosti toimiva ratkaisu.

On parempi lähteä liikkeelle valmiista komponenteista ja tehdä nopeasti prototyyppejä, sen sijaan että mietittäisiin yksityiskohtaisia tarpeita. Tietotekniikan pitää tarjota mahdollisuuksia, joita voi kokeilla. http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-no-requirements

Yhteistyömallin periaatteet

PartnershipYhteistyö rakentuu yhteisten tavoitteiden varaan ja niiden muodostamat tiimit ovat mallin ydin. Tiimin muodostavat kaikki siihen osallistuvat toimijat ja tiimin täytyy toimia kaikilla tasoilla: strategisella, taktisella ja operationaalisella. Keskinäinen luottamus on tärkeää, jokaisen osapuolen on otettava vastuu omasta panoksestaan yhteisen tavoitteen hyväksi. Toimivat tiimit vaativat jatkuvaa ylläpitoa ja huolehtimista.

Yhteistyö ei rakennu etukäteen sovittujen SLA-tavoitteiden varaan, siksi palvelujen määrittely ei ole olennaista ja palveluluettelot eivät ole välttämättömiä. On toki mahdollista, että joillakin osa-alueilla voidaan sopia hyväksi havaittua palvelumallia. Yhteistyöhön osallistuu usein monia osapuolia ja näiden toiminnan integrointi on tärkeä osa yhteistyön hallintaa.

Yhteistyömalli ei sulje pois toimivaa asiakaspalvelua ja -tukea. Sitä tarvitaan rutiinitoimeksiantojen tehokkaaseen käsittelyyn. Aiemmin kuvaamani Service Desk 2.0 kuvaa tähän soveltuvaa asiakaspalvelua. Painopiste on mahdollisuuksien ja kyvykkyyksien tarjonnassa ”insidenttien” sijaan.

Kokonaisvaltainen muutoksenhallinta on tärkeää, koska toiminta voi koostua monista yhteistyökumppanuuksista, jotka jakavat yhteisiä elementtejä. On kuitenkin suositeltavaa, että muutoksenhallinta kykenee käsittelemään suuria muutosvolyymejä nopeasti.

Operatiivinen tuotanto kattaa alustat, laitteet, sovellukset ja verkot. Siihen voi osallistua sisäisiä yksiköitä, palvelun tarjoajia ja vaikka julkisia pilvipalveluja. Tuotanto valvoo eri komponenttien toimintaa ja korjaa viat.

Riskienhallinta on myös tarpeellinen osa toimivaa yhteistyötä. Luottamus on keskeinen elementti ja siksi riskit pitää hallita hyvin. Riskienhallinta ei ole erillinen toiminto vaan tärkeä elementti kaikessa päätöksenteossa.

Yhteistyömallissa tietotekniikan ja asiakkaan roolit muuttuvat pois perinteisestä palvelumallista, jossa asiakas määrittelee haluamansa palvelut ja it toteuttaa ne. It-palvelunhallinta on ollut liian kauan vanhan vesiputousmallin lumossa. Ajatellaan että liiketoiminta määrittelee tulevat tarpeensa vuosiksi eteenpäin ja tietotekniikka sitten toteuttaa ne. Unohdetaan että näin varmistetaan, että ratkaisut ovat varmasti vanhentuneita, jos ne joskus toteutetaan. Aikaa tuhlataan suunnitteluun ja valmisteluun.

Mielestäni keskeinen oivallus tässä on siirtyminen kohti liiketoiminnan tavoitteita. It:n pitää unohtaa omat tavoitteensa ja lähteä liiketoiminnan kanssa yhteistyössä hakemaan ratkaisuja, jotka tuottavat todellista hyötyä.

Yhteistyömalli ei ole käsitteellisesti monimutkainen eikä sen oivaltamiseen tarvita useiden päivien koulutuksia. Se ei sisällä valtavaa määrää toimintoja tai prosesseja. Sen toteuttaminen käytännössä vaatii kypsyyttä, kyvykkyyttä ja molemminpuolista luottamusta.

Tavoitteet, mittarit ja hyöty

Päätin jatkaa vielä edellisen kyselyni herättämää pohdintaa. Kyse on oikeastaan aika isosta asiasta, ei pelkästään mittaamisesta vaan siitä miten tietotekniikkaa ohjataan.

Kommentit kyselyyn

Sain muutaman mielenkiintoisen kommentin tavoitteita ja mittareita koskevasta tutkimuksesta. Pekka Sipola kertoo samanlaisista havainnoista täällä:

https://pohjoisviitta.fi/2013/11/08/mittarit-ja-tavoitteet/#comments

Referoin tutkimusta myös englanniksi ja sain siihen pari hyvää kommenttia, aika arvovaltaislta tahoilta!

Jeffrey Brooks (Research Director, Gartner) Very cool. We have very similar data results…unfortunately!

 Robert Stroud (VP Strategy & Innovation, CA) Doesn’t matter how many time we talk about it, the business is the critical factor, not IT

Lisäksi pari henkilöä kommentoi yksityisesti, ja koska niiden sisältö on mielenkiintoinen, niin julkaisen ne tässä anonyymisti.

Kiitoksia tästä raportista! Minä sain tästä itselleni aika paljon uskonvahvistusta.

 En osannut itse vastata tähän kyselyyn, koska tässä nykyisessä tehtävässäni mittarointia vasta käynnistetään. Olen itse siinä vahvasti mukana ja juurikin puhumassa näistä asioista, mitä sinä tuot tässä esiin. Eli tavoitteet pitää määritellä lähtökohtaisesti yksikkörajojen yli ja toisaalta tätä vasten meillä tulee olla hyvin tarkka käsitys asioiden syy-seuraussuhteista. Pitää ymmärtää, mikä minkäkin asian todellinen vaikutus on.

Mielestäni tavoitteiden määrittely yli yksikkörajojen on loistava periaate. Se ei vielä takaa asiakkaan saaman hyödyn mittaamista, mutta on varmasti askel oikeaan suuntaan.

Muutama havainto tähän omien kokemuksieni pohjalta. Erityyppisten mittausten parissa on nyt vierähtänyt kuutisen vuotta ja tutkimuksesi tulokset tukevat täysin kokemuksiani.

 Tyypillisesti mittarin ovat ns. ”output” mittareita, eikä niiden perusteella voi sanoa mikä prosessissa/palvelussa menee pieleen. Output mittarin avulla ei pysty juurikaan korjaamaan/parantamaan mitään vaan tarvitaan mittaussysteemi, jolla pystytään selittämään prosessin toiminnan vaiheita ja tulosta (outputtia), prosessin ”input” mittareista puhumatta (vertaa autoteollisuus; jos moottorin koontilinjalle tulevat osat ovat kaikki vähän liian suuria, niin viimeiset ei luultavasti mahdu paikalleen J)

 Tärkein mainitsemasi asia lienee juuri tuo palvelun/prosessin arvon tuotto. Se ymmärtäminen näyttää jäävän yleensä lähes kokonaan huomiotta. On vaikea parantaa suorituskykyä tai palvelukokemuksia ymmärtämättä hyödyn määrää.

 Lopuksi; Availability lienee lähtöisin ITIListä ja henkilökohtainen mielipiteeni on, että kehittäjän näkökulmasta availability se vasta on huono mittari onkin, vaikkakin se on yleisesti helppo ymmärtää. Se sisältää määrittelemättömän määrän katkoja, eikä niiden ajasta ole mitään tietoa ja johtopäätökset ovat usein väärin. Asiakas on usein tyytymätön palveluun vaikka availability mittari näyttää 99,9%. 

Yleinen käsitys on, että availability on kokonaisvaltainen mittari ja oletan sen johtuvan siitä, että availabilityä on hoettu yli kymmenen vuotta.

Olen samaa mieltä tuosta saatavuudesta (availability). Eräs palveluntarjoaja harmitteli minulle, että jotkut konsultit usuttavat asiakkaat vaatimaan 100 % saatavuutta, jonka tuottaminen on mahdollista mutta kallista. Miksi esimerkiksi sähköpostin pitäisi toimia keskeytymättä. Kuka huomaa jos palvelussa on muutaman minuutin katkoja päivittäin? Saatavuus on ongelma, jos se on huono, mutta 100 % saatavuus on harvoin tarpeellinen. Kaikki riippuu katkojen vaikutuksista suhteessa korkean saatavuuden lisähintaan. Viimeisen promillen pusertaminen voi nostaa reippaasti palvelun hintaa, saavutetaanko sillä vähintäänkin vastaava tulosparannus?

Paremmat tavoitteet

Mistä sitten löytyvät ne paremmat tavoitteet. Se on vaikea kysymys. On toki helppoa sanoa miten pitäisi toimia. Pitää vain keskustella liiketoiminnan kanssa ja valita yhdessä ne yhteiset tavoitteet. Käytännössä tämä voi olla vaikeaa. Tarvitaan luottamusta, sillä yhteisten tavoitteiden taakse voi piiloutua.  Toisaalta palvelusopimusten taakse on myös erittäin helppo piiloutua. Sovitut tavoitteet saavutetaan, mutta asiakas ei ole tyytyväinen.

Andrea Kis ( Service Management and Integration Consultant at Tata Consultancy Services) twiittasi näin eilen: Managed sow the seed again: convinced client to think of aligning their IT objs to the objectives of the business to understand them. Suositukseni on tämä, alkakaa keskustella asiakkaittenne kanssa siitä, voisiko tavoitteita muuttaa. Se ei ole mahdotonta. 

Mittarit ja tavoitteet

Kysely

Kysyin tavoitteista ja mittareista marraskuussa 2013.

Olen viime aikoina pohtinut it-palvelutoiminnan mittaamista. Haluaisin erityisesti tietää millaisia tavoitteita on asetettu, mutta olen kiinnostunut myös käytössä olevista mittareista, vaikka niille ei ole asetettu täsmällisiä tavoitteita.

 Olen luokitellut tavoitteet kolmeen ryhmään:

  •  Volyymitavoite mittaa esimerkiksi käsiteltyjen asioiden lukumääriä
  • Laatutavoite mittaa esimerkiksi it-toiminnan nopeutta tai virheettömyyttä.
  • Tuloksellisuustavoite on vaikein mittari. Sen pitäisi mitata asiakkaan toiminnan onnistumista, esimerkiksi myyntiä tai asiakastoimitusten onnistumista.

 Kysymyksen muotoilu tuntuu yllättävän vaikealta, koska mittareita ja tavoitteita on niin monenlaisia.  Siksi kysymys 2 on avoin, toivon että kerrot tärkeimmät käytössä olevat mittarit, joilla it-toimintaa mitataan. Vastaa siihen riippumatta siitä, onko teillä niille täsmällisiä tavoitteita.

 1)      Onko teillä käytössä jokin määritelty tavoite, voit valita useita vaihtoehtoja?

  1. a.      ei
  2. b.      meillä on volyymitavoitteita
  3. c.       meillä on laatutavoitteita
  4. d.      meillä on tuloksellisuustavoitteita

 2)      Kuvaa miten it-palvelutoimintaa teillä mitataan. 

Tulokset

Kysymys koettiin ilmeisesti melko vaikeaksi, koska vastauksia tuli vain 20 kpl. Toisaalta tämä ei ollut internetkysely vaan pikemminkin sähköpostihaastattelu, jonka vastaajat ovat luotettavia ja asiantuntevia henkilöitä. Päätin olla lähettämättä uusintakyselyä, sen sijaan mietin voisinko muotoilla kysymykset toisella tavalla näiden tulosten perusteella. Tuloksia ei voi pitää edustavina, mutta toisaalta ne eivät ole mitenkään yllättäviä ja vahvistavat näkemyksiäni siitä mitä mitataan.

Slide1

Vastaajista 85 % kertoi että käytössä on tavoitteita, ja jokaisella heistä on laatutavoitteita ja melkein kaikilla volyymitavoitteita. Tuloksellisuustavoitteet ovat melko harvinaisia. Vain 15 %vastaajista kertoi, että heillä ei ole käytössä mitattavia tavoitteita.

Pyysin myös kuvaamaan käytössä olevia mittareita.

Slide2

Yleisin on käytettävyys, johon usein liittyy tavoite. Seuraavaksi tavallisin on tikettien määrät. Yleisiä mittareita ovat myös ratkaisukyky ja asiakas- ja tai käyttäjätyytyväisyys. Nopeuden ja SLAt mainitsi 30 % vastaajista. Oletan että SLA-tavoitteet ovat yleisempiä mutta monet eivät vain maininneet että tavoitteet ovat osa SLAta. Puhelutilastojen merkitys näyttää vähenneen.

Raha mittarina liittyi aina tuloksellisuuteen. Tavallisin tuloksellisuuden mittari olikin palvelujen kustannukset laatuun suhteutettuna. Toinen tuloksellisuuden mittari on jonkin asian onnistuminen.

Olen hiukan eri mieltä vastaajien kanssa tuloksellisuusmittareista. Kustannuspito tai kustannustehokkuus eivät mielestäni vielä mittaa tuloksellisuutta. Ne ovat hyviä laatumittareita, mutta tuloksellisuus olisi jotain, joka yhdistäisi liiketoiminnan ja it:n tavoitteet.

Osa vastaajista suhtautuu terveen kriittisesti mittaamiseen:

  • Joukossa on minusta liian vähän palvelun hyötyä ja arvoa mittaavia asioita. Tähän on toki useita malleja MOV, Cobit 5 / ValIT jne.. Silti meidän tapauksessa asiakkaat eivät ole tähän mennessä ole vaatinut kuin perinteisiä mittareita, joita on raportoitu vuosia.
  • …mittauksia joilla meidän pitäisi ohjata toimintaamme, emme välttämättä kuitenkaan tässä aina onnistu
  • käymme läpi projektien onnistumisia ja epäonnistumisia, näistäkin otetaan opikseen harvemmin koska aikaa ei vain riitä reaktiivisesta toiminnasta proaktiiviseen siirtymiselle.
  • Mittareita on monenmoisia, mutta avainkysymys on se miten niihin reagoidaan, jos niitä ylipäätänsä seurataan.
  • Etenkin yksilön suorituksen mittaaminen on jopa vaarallista ja voi johtaa ihmeelliseen tulokseen. Yleisesti mittareiden kanssa on oltava avoimia, varovaisia ja perusteltava mitä mitataan ja miksi. Lisäksi mittareiden asettelussa on mietittävä, että mittaamme asioita joiden avulla voimme kehittyä. Usein kuulen mittareista puhuttavan ja usein myös kauhistun mitä kaikkea sitä mitataankaan ja miksi.

Johtopäätökset

Olen pohtinut tavoitteiden asettamista ja mittaamista jonkun aikaa. Perinteisesti it:n mittaaminen keskittyy oman toiminnan mittaamiseen ja pahimmillaan omien aktiviteettien mittaamiseen. Mittaamisen tärkeys on tavallinen hokema, joskus väitetään että Deming sanoi että mitä ei voi mitata, sitä ei voi ohjata. Todellisuudessa 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”.

Toimivien mittareiden kehittäminen on vaikeaa ja usein käytetään mittareita, joiden tiedetään olevan epätarkkoja tai puutteellisia. Ongelmia syntyy jos ja kun mittareista tehdään tavoitteita ja tavoitteita asettavat henkilöt, jotka eivät niitä ymmärrä. 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.

On hyvin tavallista, että mitataan prosessin toimintaa. Prosesseissa on erilaisia aktiviteetteja ja niistä saa mittareita helposti. Kun prosessia käynnistetään, on tärkeää mitata sen toimintaa. Mittaukset varmistavat sen, että prosessi toimii halutulla tavalla. Tässä ei ole mitään väärää. Prosessien toiminta ei kuitenkaan ole varsinainen tavoite. On helppoa koota suuri joukko prosessimittareita ja luoda mielikuva, että tilanne on hallinnassa.

Liiketoiminnalla on yleensä kaksi tavoitetta, kasvu ja tulos. Voittoa tavoittelemattoman organisaation tehtävänä on yleensä tuottaa jotain palvelua mahdollisimman tehokkaasti ja vaikuttavasti. Laatu on näitä tukeva tavoite. Tietotekniikkaan tehdyn investoinnin perusteena on joko toiminnan kehittäminen tai kustannusten säästö. It-toiminnan tuloksellisuuden pitäisi vaikuttaa näihin tavoitteisiin.

Esimerkiksi emo-organisaation tavoitteena voi olla kustannusten alentaminen, tämä voisi olla myös it:n tavoite. Joskus it tuottaa yrityksen myymän palvelun, silloin olisi luontevaa ottaa palvelun myynti myös it:n tavoitteeksi.

Tämä tarkoittaa sitä, että it:n tavoitteiksi pitää ottaa koko organisaation tavoitteet. Esimerkiksi pankin tai vakuutusyhtiön it-yksikön tavoite on emon markkinaosuuden kasvattaminen ja tuloksen parantaminen, edellyttäen toki, että ne ovat emon tavoitteet.  Voin kuulla vastaväitteen: ”Emmehän me pysty siihen vaikuttamaan”. Olen eri mieltä. It-toiminta vaikuttaa emon toimintaan monella tavalla. Yhteiset tavoitteet yhdistävät ja purkavat tarpeetonta raja-aitaa it:n ja liiketoiminnan väliltä. It:n toimintaan liittyvät tavoitteet voivat olla jopa haitallisia.

Tutkimuksessani ei tullut esiin yhtään esimerkkiä jossa it olisi käyttänyt suoraan emon tavoitteita, mutta olisi mielenkiintoista kuulla onko kukaan yrittänyt tätä käytännössä.

Liite: Avoimet vastaukset

Mittareiden kuvaus
Palvelutuotantoa mitataan työnohjausjärjestelmien (tiketöinti) kautta, sekä käyttöpalveluiden ja tietoliikenteen osalta käytettävyysmittauksena.
it- palvelutoimintaa mitataan prosessien läpimenoajoilla, asiakastyytyväisyyskyselyillä, Kerralla kuntoon asteella, kustannustehokkuudella. Tulleet kontaktit vs. palvelun laatu.Tärkein kriteeri on palvelujen käytettävyys ja performance asiakkaan E to E kokeman perusteella. EtoE mittausta tehdään reaaliaikaisesti toistamalla palvelusekvenssejä virtuaalisilla palvelutapahtumilla.
IT Servicedesk:

  • tapahtumakohtainen asiakastyytyväisyyskysely lähtee jokaisesta tulleesta tiketistä, maksimi asiakastyytyväisyys on 3, meillä on 2,8 (tavoite 2,3)
  • tulleet puhelut ja luovuttaneet
  • mediaani miten nopeasti asiakkaalle vastataan, tällä hetkellä 17s
  • SD ratkaisuaste, tällä hetkellä kaikista tulleista tiketeistä 83%
  • tiimien ratkaisuaste, asiakaspalvelut-tiimin (oma tiimini) ratkaisuaste on yli 90%
  • tulleet tiketit ja SLA:n ylittäneet (volyymitieto ja palvelutasorikkomukset)

Työasemapalvelut:

  • tilaus-toimitusprosessi (tilauksesta asiakkaan työpöydälle 10tp)
  • tulleet tiketit ja SLA:n ylittäneet (volyymitieto ja palvelutasorikkomukset)

Käytettävyys:

  • tietoliikenne
  • palvelimet
  • tietojärjestelmät

Joka toinen vuosi lähetettävä asiakastyytyväisyyskysely, kysely lähtee noin 35.000 asiakkaalle.

Tärkein mittari meillä on Menetetyt käyttäjätunnit, joka mittaa sitä kuinka järjestelmät ovat olleet meidän käyttäjien käytettävissä. Sille on asetettu tietty tavoite. Tätä voidaan pitää päämittarina ja sille on sitten erilaisia alitavoitteita kuten esim. kulutettujen MIPS:ien  pysymisen MF-puolella alle tietyn tason ja verkon pystyssä pysyminen.
Yksi tärkeimmistä mittareista on NPS (suositteluaste), jota kysytään loppukäyttäjiltä ja päättäjiltä erikseen. Tämän alla on sitten useita eri mittareita (minusta liikaa), joita sitten asiakaskohtaisesti raportoidaan. Joukossa on minusta liian vähän palvelun hyötyä ja arvoa mittaavia asioita. Tähän on toki useita malleja MOV, Cobit 5 / ValIT jne.. Silti meidän tapauksessa asiakkaat eivät ole tähän mennessä ole vaatinut kuin perinteisiä mittareita, joita on raportoitu vuosia.
  • Palvelutason sopimusten pito (asiakas & palvelukohtaiset)
  • Asiakaskokemus operatiivisella, taktisella ja strategisella tasolla (kk/4 vuosi/vuosisyklillä kyselyt), loppukäyttäjäkokemus, otoskyselyt suljetuista palvelupyynnöistä
  • Benchmarking, kustannustehokkuus
  • Suunnittelemattomien palvelukatkojen lukumäärät ja kestot trendikehitys
  • Offshoring aste <> tavoitteet
  • Toimitus/palvelukohtainen kannattavuus
  • Cost of poor quality- teemalla, vaihtelevasti erilaisia mittareita, esim kuinka paljon saadaan ratkaistua 1. Tierillä tai joudutaan uudelleen avaamaan suljettuja palvelupyyntöjä

 

  • palvelutaso: useita mittareita, ml. end-to-end-SLA ja asiakastyytyväisyys
  • suorituskyky & laatu: hanke- ja projektitasoiset mittarit
  • kustannuspito: palvelut, toimitukset, kokonaiskustannukset
  • volyymina mitataan transaktiomääriä, tikettimääriä, puhelumääriä
  • laadun suhteen meillä mitataan uudelleenkäsittelyjen määrää, tämä koskee sekä transaktioita että tikettejä jotka ”uudelleenaukeaa”, tämä on tosin hyvin hankalaa mitata, koska keikat voivat aueta uudelleen syystäkin, prosessit eivät tue välttämättä sitä että keikka menee ”lepotilaan” koska asiakas ei voi aloittaa projektia ennen kesän loppua esim.
  • teemme employee satisfaction survey sekä customer satisfaction survey mittauksia joilla meidän pitäisi ohjata toimintaamme, emme välttämättä kuitenkaan tässä aina onnistu
  • käymme läpi projektien onnistumisia ja epäonnistumisia, näistäkin otetaan opikseen harvemmin koska aikaa ei vain riitä reaktiivisesta toiminnasta proaktiiviseen siirtymiselle.
Ihan kaikista mittareista en ole tietoinen, mutta ainakin mittaamme laatutavoitteella SD:n ratkaisuastetta. SD:n ratkaisuasteen tulee olla 75-90%.Mittaamme tosin myös volyymiä eli kuinka paljon tulee palvelupyyntöjä/häiriöitä ja kuinka paljon puheluita, mutta näille ei ole mitään tavoitteita.Tuloksellisuustavoitteeksi voitaneen laske tietojärjestelmien saatavuus tavoite, joka on järjestelmäkohtaisesti sovittu, mutta yleensä saatavuuden tulee olla 95%.IT palvelutoiminnan mittarointi esim.

  • insidenttien luokittelun mukaiset SLA:t joita mitataan (työn alle ottaminen, ratkaisuaika %:t SLA tavoitteisiin verrattuna)
  • järjestelmien käytettävyys %
  • Support Desk level mittarointi (1st level, 2nd level, 3rd level) ratkaisuprosentit eri leveleillä
  • RFC mittarointi SLA:n mukaisesti, RFC:t myös luokiteltu, %:t SLA ratkaisutavoitteen mukaisesti

Projektien mittarointi erikseen

  • aikataulut, kustannukset + status mittarointi projektin aikana (kustannukset, aikataulu, resursointi, scope jne)
Mittareita on monenmoisia, mutta avainkysymys on se miten niihin reagoidaan, jos niitä ylipäätänsä seurataan.
Tärkein mittari on tuloksellisuus, joka mitataan suoraan myyntieuroina, toimitusten eurot naksutetaan laskutuspostien tahdissa, joka lienee reiluin tapa.Koska iso osa palvelutuotantoa on spesifien transaktiotyyppisten asioiden hoitamista, niistä mitataan myösvolyymiä vs tavoite (jolla valvotaan markkinaosuutta ja palvelutuotteen kysyntää)laatua eli palvelunkeskeytyksiä tai korjaustoimia edellyttäviä virheitä
Palvelutoimintaa mitataan päämiesten ja asiakkaiden asettamilla tavoitteilla (SLA), jotka ovat kaikilla erilaiset. Eniten on painoa toimitusaikatavoitteilla, mutta usein seurataan myös uusintakorjauksia, varaosien kulutusta ja vikakoodien raportoinnin oikeellisuutta.
Käytämme vuosittain kyselyä henkilökunnalle. Olemme tehneet tätä 3 vuoden ajan samoilla kysymyksillä jolloin saamme vertailupohjaa.
meillä on volyymitavoitteita

  • palvelujen käyttövolyymejä; esim. tiketit, puhelut

meillä on laatutavoitteita

  • palveluiden saatavuus , häiriöiden määrä vs. tavoitteet, muutoksenhallinta osalta esim. muutos aiheutti  uuden ongelman tai paluun, vasteaika puheluille, loppukäyttäjätyytyväisyys, asiakastyytyväisyys, suositteluindeksi

tuloksellisuustavoite

  • liittyy meillä usein aikaisemmin tehdyn projektin tulosten myöhempää käyttöä; esim. tavoitteena on muuttaa lankapuhelimet IP-puhelimiksi x-vuodessa. Projektissa luodaan IP-puhelininfra ja mallit miten käyttäjät voivat palvelulla korvata lankapuhelimet (esim. puhelimen elinkaaren päättyessä). Näitä / vastaavia on noin7-8 erilaista.
Tällä hetkellä vasta mietimme käsittääkseni mittareita. Olen huomioinut vuosien saatossa, että mittareilla on usein kääntöpuoli. Esimerkiksi se, että ajattelematon mittaaminen alkaa ohjata helposti työntekijän suorittamista, joskus työlaadun kustannuksella.Joskus mittasimme esim. suljettujen palvelupyyntöjen määrää ja se johti ainakin osittain siihen, että tikettejä suljettiin huolimattomasti keskeneräisenä, niitä haalittiin itselle työjonoon enemmän kuin ehdittiin tehdä ja näin asiakas kärsi palvelun muuttumisesta tehottomammaksi, vaikka aikomus oli toinen.Lisäksi ilmeni outousJ sillä tikettejä tehtiin mittarin luonnin jälkeen hurja määrä omin voimin, eli ne eivät tulleet ollenkaan asiakkaalta ja jo suljetusta työjonosta otettiin töitä omalle vastuulle, jotta henkilökohtainen panostus näyttäisi mittarissa /raportissa paremmaltaJEtenkin yksilön suorituksen mittaaminen on jopa vaarallista ja voi johtaa ihmeelliseen tulokseen. Yleisesti mittareiden kanssa on oltava avoimia, varovaisia ja perusteltava mitä mitataan ja miksi. Lisäksi mittareiden asettelussa on mietittävä, että mittaamme asioita joiden avulla voimme kehittyä. Usein kuulen mittareista puhuttavan ja usein myös kauhistun mitä kaikkea sitä mitataankaan ja miksi.
Help Deskimme kerää tietoa palvelupyynnöistä. Kaikki palvelupyyntömme tulevat kulkemaan Help deskin kautta vuoden 2014 aikana. It-palvelutoiminnalle yleisiä volyymi- ja laatumittareita työstetään raporttien muotoon parhaillaan. Tavoitteena on, että mittarit tukisivat laatu- ja tuloksellisuustavoitteitamme.
Tärkein mittarimme on palvelumme saatavuus, joka on sopimuksissamme sanktioitu.Mittaamme palvelupisteessä reagointiaikaa, jolla on sopimuksellinen velvoitetaso asiakkaalle.Tiketeistä mitataan myös tapahtumamääriä palveluittain (lue tuotteittain) tuotekehitystämme varten.
Ratkaistujen keikkojen määrä, Nopeus, Asiakastyytyväisyys, First call resolution (tulossa)
%d bloggers like this: