Trust is the solution

It is a common practice to measure incident resolution times and have SLA limits for different priorities. For example, a typical SLA can state that 90% of priority level 2 incidents must be resolved within 8 business hours. One complication is that sometimes resolution must wait for some information or third party act. Usually this waiting time is subtracted from the resolution time which means that the actual resolution time can be anything but be still within the SLA limit.

Another problem is the priority. It is hard to define the right priority and sometimes there is a need to change the priority as there is more information available concerning the nature of the incident. There was recently a discussion on the subject of changing priority where I commented that I consider the whole concept to be a bad ITIL practice. A few commentators disagreed. One person wrote:

… I very much disagree regarding ”bad practice”. Without a measurement for timing – and logically, the timing to resolve something more damaging would be shorter – one has only chaos and is at the mercy of whoever decides timing was not what it should have been.

 In this article, I will explain the reasons why I consider it as a bad ITIL practice and what would be a better practice. The above comment is basically right; it makes sense to measure timing and it is true that important matters should be resolved faster. I disagree that it leads to chaos if customers can decide what is the right timing. But this is not the real problem, the core problem lies in the SLA connection. When resolution times are set as a SLA target the timing easily becomes dominant and it will override common sense and customer value.

Any metric can be harmful if it used incorrectly. Usually management wants to have numbers and easily defined targets but metrics can be toxic.

Road side speed measurements do not show high speeds, if they did, some drivers would try to get record numbers and the safety measure would become a source of danger.

Firstly, the measurements are very easy to manipulate. If you haven’t seen cases where all SLA’s are met but customers are quite dissatisfied, you do not know much about real life in ITSM. It is far too easy to play with the measurements as so many things are hard to define. Here are some techniques:

  • ask difficult questions from the customer and stop the clock while they try to answer the questions
  • give low priority to difficult cases, or change the priority if the deadline approaches
  • classify more automatically generated events as incidents and solve them fast

All these tricks will help to fulfill the SLA promise without providing any value to the customer.

The second major problem is the setting of priorities. It is difficult and usually there are simple rules, which give a ticket a priority based on the affected service. The given priorities do not necessarily reflect the true business value related to the case. One thing is sure, any mechanical, automatic priority system will fail.

Here is an example, I’m sure many have seen similar cases:

IT service provider ITSP has a culture of fast responses and close cooperation with their customers. They know when they need to drop everything and jump to prevent a potential failure. They have processes and use a ticketing system to make sure that things are not forgotten, but they are not orthodox about it and do not always create tickets. They have no SLA’s.

 One day ITSP management decides to implement best practices. All incidents need to be handled following SLA requirements and it is a severe error to let SLA times slip.

 So, when next time there’s a potential failure, the IT staff concentrate on following orders and refrain from jumping to prevent the failure. The staff closes a group of minor tickets which are close to breaching the SLA limit before they start working on the major failure and resolve it just within the SLA.

 Everything is ok, there has been no SLA breaches but the customer is mad because they could see that the IT people were closing insignificant tickets while their business ground to halt due to a major IT failure which was waiting.

The solution to the priority and SLA problem is simple; trust. If you can trust your service provider, you do not need to set SLA penalties. If you can trust your staff to make good decisions, you do not need rigid prioritization.

This far from easy, trust needs to be earned and it is easy to lose it. On the other hand, it is very rewarding and it is good for business.

 

Arvon mittaaminen service deskissä

Arvon mittaaminen on periaatteessa helppoa. Teemme joka päivä arvomittauksia kun päätämme ostaa jotain tai käyttää jotain palvelua. Yleensä päätöksemme perustuvat aikaisempiin kokemuksiin, valitsemme tuotteita ja palveluja, jotka ovat hintansa tai vaivansa arvoisia. Arvoa lisää kohteen antama hyöty ja mielihyvä. Arvoa vähentävät kohteen hinta, mahdolliset laatuongelmat, siihen liittyvä vaiva ja epävarmuus. Avoimilla markkinoilla kilpailu pitää yleensä huolen siitä, että tuotteet ja palvelut tuottavat arvoa. IT palvelu ja service desk eivät toimi avoimilla markkinoilla. Palvelun vaihtaminen on vaikeaa tai mahdotonta. Asiakkaat ovan yhden palvelutoimittajan vankeja.

IT palvelun tai service deskin toimintaa mitataan yleensä aktiviteettien perusteella eli SLA-mittareilla: palvelujen päälläoloaika, vastausaika, tikettien käsittely jne.  SLA mittarit ovat vain harvoin kytköksissä arvoon. Jos katko estää työnteon kokonaan, niin silloin katkon pituus voi olla suoraan verrannollinen menetettyyn arvoon. Valitettavasti useimmat näistä tavallisista mittareista ei mittaa todellista arvoa. Otetaan pari esimerkkiä.

Jos sähköpostipalvelin on nurin 15 minuuttia keskellä työpäivää, mitä arvoa menetetään? Toki voi laskea että kaikki 10.000 käyttäjää menettivät 15 minuuttia, ja näin saadaan kova hinta, pari miestyövuotta, mutta se on älytöntä. Ei taatusti kannata maksaa edes yhden miestyövuoden hintaa siitä että varmistetaan 100% käytettävyys. Todennäköisesti palvelukatkosta ei ole juuri mitään haittaa. 

Käyttäjällä on ongelma. Sen sijaan että service desk hakisi ratkaisun ongelmaan, tukihenkilö opettaa asiakkaalle helpomman tavan tehdä asia. Puhelu kestää puoli tuntia ja varsinaista vikaa ei ratkaista, mutta käyttäjä hyötyy neuvosta joka päivä 15 min.

On helppoa mitata katkon kesto ja on helppoa mitata puhelun kesto. Kumpikaan ei kerro juuri mitään arvosta. Lähes kaikki mittarit, joita olemme tottuneet käyttämään Service Deskeissä, mittaavat aktiviteetteja. Vastaaminen on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Tiketin käsittely on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Asiakkaan tyytyväisyys puhelinkeskusteluun on aktiviteetin ominaisuus. Kaikki prosessimittarit keskittyvät prosessin toiminnan mittaamiseen, mutta toimiva prosessi ei välttämättä tuota arvoa.

Oma käsitykseni on, että service deskin arvo voidaan jakaa kahteen osaan:

1) tietotekniikasta johtuvan menetetyn työajan vähentäminen

2) työn tehostaminen tai helpottaminen tietotekniikan avulla

Nämä molemmat vaikuttavat asiakkaiden saamaan arvoon. Niiden mittaaminen ei ole ihan yksinkertaista.

Ohjaako SLA väärään suuntaan?

Yleisin valitus SLAista on, että ne eivät toimi. Palvelu on huonoa, vaikka SLAt saavutetaan. Toinen, vielä tavallisempi murhe on, että SLA-raportit ovat täysin hyödyttömiä. ne eivät kerro mitään kiinnostavaa, eikä palvelun  kehittäminen onnistu niiden pohjalta.  SLA voi olla hyödyllinen, jos sen pystyy mittaamaan yksiselitteisesti ja sillä on suora vaikutus liiketoimintaan. Usein kuitenkin käytetään vaikeasti mitattavia ja hiukan epämääräisiä tavoitteita.

SLA voi olla kuitenkin suoranaisen haitallinen. Olen kuullut joitakin esimerkkejä siitä, kuinka SLA on ohjannut toimintaa väärään suuntaan. On keskitytty SLA-tavoitteiden saavuttamiseen eikä siihen, mikä olisi asiakkaalle tärkeää. Osin on mielestäni kyse ITILin virheistä. Esimerkiksi ITILin kuvaama priorisointi on liian karkea ja kaavamainen, asioiden kiireellisyys ja tärkeys riippuvat monesta seikasta, eikä niitä voi  määritellä yksinkertaisella kaavalla.

Uskon, että olisi hyvä idea luopua suuresta osasta SLAita ja antaa asiakkaiden ohjata priorisointia enemmän. Pohjimmiltaan kyse on luottamuksesta. Jos asioita tehdään yhdessä, hyvässä yhteistyössä niin tulos on parempi kuin jokin sopimuspohjainen ohjaus.

Sisäiset SLAt eli OLAT ovat mielestäni erittäin huono idea. Niillä voi konsultti tienata rahaa, mutta toiminnan kannalta ne ovat vain ja ainoastaan haitallisia. Jos välit ovat niin huonot, että OLAlla saadaan aikaan parannuksia niin vika on organisaatiossa, kulttuurissa ja/tai johdossa.

Tarvitsetko palveluluettelon?

Kirjoitin service desk-järjestelmän turhasta monimutkaisuudesta  ja olen käynyt siitä keskustelua eri kollegoiden kanssa. Aluksi ajattelin, että itilin CMDB-palvelu-SLA malli (eli malli joka kytkee palvelusopimukset palveluluettelon kautta konfiguraatiotietoihin) aiheuttaa vain tarpeetonta monimutkaisuutta service desk-järjestelmiin. Keskustelujen perusteella olen päätynyt siihen johtopäätökseen, että palveluluettelon ja palvelusopimusten laatiminen itilin oppien mukaan voi olla turhaa ja jopa haitallista. Alleviivasin sanan ”voi”, koska itilin malli toimii joissakin tapauksissa. Parhaiten se toimii silloin kun sekä ostaja että myyjä ovat it-ammattilaisia. Valitettavasti it-palveluja tarvitsevat henkilöt eivät yleensä ole alan ammattilaisia. Valaisen asiaa esimerkillä.

Matkustajalaiva on monimutkainen palvelujärjestelmä. Se on suuri hotelli, jossa on useita ravintoloita, baareja, kauppoja jne. Lisäksi se on kulkuväline. Laivaa pyörittää organisaatio, jolla on kolme päätehtävää:

  1. kapteeni vastaa laivan kuljettamisesta ja turvallisuudesta
  2. purseri johtaa hotelli- ja ravintolapalveluja
  3. konemestari vastaa laivan tekniikan ylläpidosta ja valvonnasta

Lisäksi maissa on varustamon johto, myynti ja markkinointi. Strategiset päätökset tehdään siellä.

Kaikki laivan toiminnot ovat riippuvaisia tekniikan toimivuudesta, mutta niiden kriittisyys vaihtelee ajankohdasta riippuen.

Kuvittele nyt, että laivan konemestari saa itil-herätyksen ja alkaa rakentaa palveluluetteloa. Hänellä toki on varmasti olemassa hyvä kuvaus laivan konfiguraatiosta, mutta mieti miten ja kenen kanssa hän voisi neuvotella palveluluettelosta ja vaikka ilmastointilaitteiden SLA tavoitteista! Ei purseri tai edes kapteeni osaa ottaa kantaa joidenkin teknisten viritysten vaikutuksiin. Laivan palvelujen elinkaari ei ole mitenkään kytköksissä laivan tekniikan elinkaareen. Laitteita huolletaan ja korjataan tarpeen mukaan, mutta laivan palvelut kehittyvät niistä riippumatta. 

Jos laivan konemestari kuitenkin on luja uskossaan ja painostaa purserin tekemään palvelutasosopimukset, tilanne todennäköisesti vain kärjistää suhteita laivalla. Jos purseri esimerkiksi valittaa että keittiön liesituuletus on puutteellista ja sen johdosta ravintolaan tulee ajoittain käryä, niin konemestari voi mitä suurimmalla todennäköisyydellä vakuuttaa tuuletuksen täyttävän palvelutasovaatimukset.

Mitä siis pitää tehdä, jos palveluluettelon laatiminen tuntuu vaikealta ja/tai liiketoiminnan kanssa on vaikea löytää yhteistä säveltä? Mielestäni kannattaa unohtaa itilin opit. Palveluluetteloa ei vain voi laatia niin, että se kytkeytyisi liiketoiminnan palveluihin. Kyse on pitkälti ammattitaidosta. Tekniikasta vastaavan henkilöstön pitää osata huolehtia vastuullaan olevista järjestelmistä ja heidän pitää ymmärtää niiden merkitys.  SLA on oikeastaan vain yritys vyöryttää vastuu asiakkaan harteille ja niin ei pidä tehdä, ellei asiakas sitä halua.

 

Miten sitten tekniikan toimivuutta pitää mitata? Mieti laivaa. Tärkeintä on varmasti se, että tekniikan ongelmat eivät haittaa liiketoimintaa. Hyötyjä voi syntyä myös erilaisista säästöistä, vaikka energian kulutuksessa. Oleellista on, että toimintaa mitataan liiketoiminnan mittareilla, ei sisäisillä SLA-mittareilla. Lopuksi pitää vielä kerran korostaa, että on myös tilanteita, joissa asiakas haluaa ja tarvitsee palvelulettelon ja SLA:n.

Jos et ole lukenut aiempaa kirjoitustani palvelukäsitteen selkeyttämisestä, käy lukemassa myös se.

PS Kun testasin linkkejä, sain turvavaroituksen siitä, että linkki johtaa wordpress.com palvelimme, vaikka linkissä on osoitteena pohjoisviitta.fi. Olen siirtänyt pohjoisviitta.fi domainin wordpressille jo useita vuosia sitten, joten varoitus on aiheeton.

Sanktiot ja bonukset

Olen täydentänyt raporttia 17.9.

Tämän kyselyn tarkoituksena oli selvittää kuinka yleisiä sanktiot ja bonukset ovat palvelusopimuksissa ja miten hyvin niiden koettiin toimivan. Kysely oli tämän näköinen:

Tällä kertaa kysyn sanktioista ja bonuksista palveluntasosopimuksissa (SLA). SLA:lla tarkoitan palvelun toimittajan ja asiakkaan välistä sopimusta, jossa palvelun laadun mittarille asetetaan jokin raja-arvo tai väli. Sanktio on rangaistus laadun alituksesta, bonus taas palkkio laadun ylityksestä.
 
Kysymykset:
A Onko teillä käytössä palvelutasosopimus (SLA)? Jos on, vastaa myös kysymyksiin B ja C
B Onko sopimuksessa sanktioita?
C Onko sopimuksessa bonuksia?
 
Vastaa jokaiseen kysymykseen kyllä tai ei (k/e) ja kerro mitä mieltä olet nykyisen ratkaisun toimivuudesta 1-5 asteikolla, jossa
5 erittäin hyvä
4 hyvä
3 ei hyvä eikä huono
2 huono  
1 erittäin huono
 
Voit antaa useampia vastauksia, jos teillä on useita SLA-sopimuksia. Bonusten ja sanktioiden kuvaukset olisivat myös kiinnostavia.

Vastauksia on tullut 47 kpl.

Oletin että bonukset olisivat harvinaisia, mutta yllättävän paljon niitä oli.

Slide1

Vastanneista 90 % oli käytössä SLA sopimuksia ja näistä yli 90 % sovelsi sanktioita. Bonuksia oli melkein joka toisella. Tämä yllätti minut, luulin että ne olisivat harvinaisempia.

Kysyin myös miten tyytyväisiä niihin ollaan. Vastaukset olivat taas yllättäviä. Jaoin vastaajat kahteen ryhmään, sisäiset it-yksiköt ja kaupalliset palveluntarjoajat. Käytännössä sisäiset yksiköt yleensä edustavat palvelun ostajaa.

Asteikolla 3 edusti neutraalia, joten tolpat alkavat siitä. Ostajan ja myyjän näkemykset eroavat selvästi. Ostajat eli sisäisen IT:n edustajat ovat yleensä tyytyväisiä kun taas myyjien arvio jää hiukan pakkasen puolelle.  Tässä muuten keskiarvo toimii huonosti sillä yksikään palveluyksikön edustaja ei vastannut 3 vaan mielipiteet jakautuivat jokseenkin kahtia.

Slide2

Tästä alkaa täydennys: 

SLAt jakavat mieliä. Hyvin harva suhtautuu neutraalisti niihin. Selvä enemmistö suhtautuu niihin positiivisesti. On mielenkiintoista, että vastausten jakauma näyttää varsin erilaiselta verrattuna viime tammikuussa tekemääni kyselyyn. jossa vastaajat olivat kriittisempiä SLAn toimivuuden suhteen. Ilmeisesti kyselyn muotoilu vaikutti vastaamiseen, nyt kysyttiin sanktioita ja bonuksia eli konkreettisia asioita SLA:n soveltamisesta ja monet ohittivat kysymyksen SLAn toimivuudesta.

Slide1

Palveluntarjoajat ovat selvästi kriittisempiä kuin palvelun ostajat.

Slide2

Sanktioissa neutraaleja on enemmän.

Slide3

Bonuksien suhteen lähes puolet ovat neutraaleja.

Slide4

Tässä on muuten hyvä esimerkki siitä kuinka älytön on se ”viisaus” että kyselyissä ei pitäisi olla neutraalia keskikohtaa vaan vastaajat pitäisi pakottaa valitsemaan. On selvää että neutraalien vastausten määrällä on oma merkityksensä, tässä tapauksessa vastaajat eivät osaa sanoa ovatko bonukset hyviä vai huonoja.

bonukset

Jäin miettimään tätä kuvaa ja sitten välähti, että osa vastaajista sovelsi bonuksia ja osa ei. Kuten näkyy, sillä on iso vaikutus mielipiteeseen – tai päinvastoin. Enemmistö soveltajista suhtautuu niihin positiivisesti.

Tässä kommentit.

laji kommentti
sla Konsultit virittävät monimutkaiset ja tiukat SLA:t.  Asiakkaat eivät välttämättä halua sellaisia SLA sopimuksia kun tarkemmin kysytään.  Tehdään myös SLA sopimuksia joita ei voida raportoida tai jotka eivät kuvaa asiakkaan haluamaa asiaa.
sla oman yksikön sisäinen suullisesti sovittu SLA
sla SLA-sopimus ei koskaan saisi olla itsetarkoitus ja oma tavoitteeni onkin, ettei niitä olisi yhtään
sla Melkein kaikissa on SLA, mutta – seurataanko sitä – antaako se aihetta toimenpiteisiin – kerätäänkö sakot on jo sitten toinen kysymys
sanktio kovat sanktiot, eg. jos yksi serveri alle kuukauden SLA-availabilityn, sanktio = koko serveriparkin kuukauden hinta
sanktio Sanktiointi ei sinällään ohjaa toimintaa. Sopimuksissa voi olla sisarussuhteita, joissa alihankkija kalliimmalla sopimuksella saa jokin  sopimuksen , mutta rinnalla tulee halvalla ”tehtävä” oheistoiminne. Oheistoiminne/oheissopimus otetaan ”pakkohintaan” että saadaan kalliimpi sopimus , jossa siis focus. Pienemmän sopparin sanktiot ovat silloin ”hukkuva” erä kokonaiskustannuksessa.
sanktio siinä mielessä, että on olemassa, mutta käytännössä korjauksia maksuihin tehdään kuitenkin vain vuositasolla. Yleensä mitään suurta poikkeamaa ei ole ja vaikka olisikin, siitä keskustellaan ensin ja viedään vuosittaiseen ”tasauskoriin”. Näin ainakin pari vuotta sitten.
sanktio Tämä siis yleisesti. Meillä on SLA:t ja sanktiot sovittu kumpaankin suuntaan (meidän ja toimittajan välillä, meidän ja asiakkaan välillä). Kaikki sanktioitu tavalla tai toisella. Bonus –järjestelmiä emme ole ottaneet käyttöön
sanktio Yleensä jonkin tyyppinen alennus palvelumaksuissa jos määrätyt palvelutasomittarit lipsuvat punaisen puolelle.
sanktio välillä sanktio ohjaa liikaa toimintaa ja pro-aktiivisuus jää vähälle
sanktio Alla vastauksiani koskien ulkoisia SLA sopimuksia. Sisäiset SLA:t eivät sisällä sanktioita. Vastaukset koskevat keskimäärin tilannetta SLA sopimusten kohdalla, mutta tietysti vaihteluita on sopimusten luonteeseenkin liittyen. Aika monesti ulkoisen palvelun suhteen on melko tiukat vaatimukset palvelun käytettävyyteen liittyen ja niihin sidottu sanktiot. Voi olla, että pienissä rikkeissä ei aina mennä sanktioihin, mutta suuremmissa tapauksissa korvauksiin yleisesti mennään.
sanktio Ongelmana mittarointi ja seuranta
sanktio Me olemme se osapuoli joka saa sanktioita tai bonuksia. Sanktioiden ikävä puolihan on rahan menetys, mutta toisaalta sillä on myös motivoiva vaikutus pitää SLA hyvällä tasolla, siksi neutraali 3 pistettä sille.
bonus siinä mielessä, että porkkana toisi ehkä ryhtiä lisää
bonus Joissakin tapauksissa on käytössä ja ne ovat yleensä sidottuja myös asiakastyytyväisyyteen muiden mittareiden lisäksi
bonus poistimme bonukset, sillä johti yleensä liikayrittämiseen

PS. Jos haluat päästä vastaamaan näihin tutkimuksiin niin tilaa Reittisuunnittelu-tiedote. Tilauspainike löytyy oikeasta reunasta.

Palveluintegrointi

It-palvelu muodostuu palveluketjuista,  joissa eri organisaatiot yhdessä rakentavat lopullisen palvelun. Asiakkaat pelkäävät, ehkä aiheellisesti, yhden toimittajan armoille joutumista. Siksi suuret ulkoistukset pyritään pilkkomaan monille toimittajille ja sisäisen it:n tehtäväksi jää palvelujen yhteensovittaminen. Ulkoistuksessa on tavallista, että osa henkilöstöä siirtyy palveluntarjoajan leipiin ja jäljelle jää vain ”jäännös it”, joka valvoo ja ohjaa palvelun tuottajia. Tehtävä ei ole helppo ja monissa tapauksissa on havaittu, että ulkoistuksen jälkeen sisäisen it:n osaaminen ja resurssit eivät riitä tehtävään. Usein on päädytty rakentamaan sisäinen it ikään kuin uudestaan, tosin niin että sen tehtävät ovat erilaiset kuin lähtötilanteessa. Tämä prosessi on pitkällä Englannissa, jossa palvelujen ulkoistus lähti liikkeelle jo 80-luvulla. Siellä puhutaan jo kolmannen sukupolven ”jäännös it:stä, 3rd generation retained IT”.

Palvelumarkkinoilla syntyy helposti epätasainen asetelma. Suuriin palveluhankkeisiin kykenee vain rajallinen määrä toimijoita. Palvelun tuottajista tulee voimakkaita ja asiakkaat ovat alakynnessä. Palvelun tuottajilla on pieni määrä avainasiakkaita, joista pidetään kiinni. Erityisvaatimuksia esittävät pienet asiakkaat ovat häiriötekijöitä, joiden menetystä ei surra. Pulmaa voidaan ratkoa eri keinoin. Yksi tapa on hakeutua avainasiakkaaksi, eli löytää riittävän pieni palveluntarjoaja. Tässäkin on omat riskinsä. Toinen keino on ottaa palveluja takaisin sisään.  Kolmas keino on ostaa palveluintegrointi palveluna.

Palveluintegrointi eli Service Integration on eri asia kuin järjestelmäintegrointi eli Systems Integration, jossa eri järjestelmät laitetaan keskustelemaan keskenään. Palveluintegrointi tarkoittaa sitä että yksi osapuoli ottaa vastuulleen muiden palvelutuottajien palvelut. Tämä voi tuntua turhan monimutkaiselta, mutta samaa mallia käytetään kaikkialla. Yksi palvelun tuottaja myy lopputuloksen asiakkaalle ja hankkii tarvittavat alihankkijat tekemään työn.

Palveluintegrointi on melko uusi asia Suomessa. Googlauksen perusteella näyttää siltä, että ainoastaan Fujitsu on oivaltanut mistä on kyse. Malli on kuitenkin tulossa hyvää vauhtia Suomeen. Englannissa se on menestynyt ja tietoni perustuvatkin englantilaisten kollegoiden kokemuksiin. Yksi tärkeä peluri alalla on TCS, TATA Consulting Services, joka toimii myös Suomessa. Ilmeisesti myös muut intialaiset suuret palvelutalot ovat palveluintegroinnin edelläkävijöitä.

TCS:n mukaan termi on vielä epämääräinen, sillä voidaan tarkoittaa vain monitorointia, operationaalista valvontaa, palvelujen yhdistämistä jne. TCSn mukaan siinä on kuitenkin kyse syvemmästä yhteistyöstä, uudesta tavasta hallita it-palveluja. Tämä liittyy läheisesti äskeiseen SLA-keskusteluun. On tavallista, että it-yksikkö neuvottelee palvelun toimittajien kanssa tekniikkalähtöiset SLAt. Liiketoiminnan tarpeet jäävät helposti taustalle. Kerran neuvoteltu palvelusopimus voi olla pahimmillaan kehityksen jarru. Palveluintegroinnin tulee lähteä liiketoiminnan tarpeista, integraattorin tulee ymmärtää liiketoiminnan tavoitteet ja sen tulee kyetä tarjoamaan innovaatioita toiminnan kehittämiselle.

Äskeisessä tutkimuksessa tuli esille tyypillisiä ongelmia asiakas-toimittajasuhteissa:

Ulkoisen palveluntuottajan heikko laatu toiminnassaan; suunnattomasti virheitä, viesteihin ei vastata,  ei tehdä mitä sovitaan vaan tehdään ihan jotain muuta,….

Ei varsinaisesti mitään uutta. Palveluntarjoajien asiakkaalle näkyvät, jäsentymättömät prosessit ja tilaajan kannalta epämääräiset toimitusajat.

Vastaavia kommentteja kuulee paljon. Yksi selitys voisi olla, että it-yksiköt ja palvelutuottajat eivät ymmärrä toisiaan. Eräs palveluntuottajan edustaja kommentoi kerran, että on onnetonta miten asiakassuhteet aina muuttuvat hyvän alun jälkeen jankkaamiseksi. Toisessa tapauksessa yritin selittää asiakkaalleni, eli sisäisen it:n edustajalle, että heidän pitäisi kytkeä oma muutoksenhallinnan prosessinsa toimittajan muutoksenhallintaan ja perustelin sitä sillä, että toimittajankin on tehtävä muutoksia heidän ympäristöönsä. Asiakkaani vastasi painokkaasti että toimittaja ei tee mitään muutoksia. Asiakas siis ajatteli että toimittajan pitää jäädyttää ympäristönsä heidän sopimuskautensa ajaksi.

Palveluintegraattorin rooli on siis vaativa, integraattorin on ymmärrettävä palveluntarjoajien toiminta ja kyettävä ohjaamaan näitä. Toisaalta integraattorin on ymmärrettävä asiakkaiden tarpeet. Palveluintegraatio ei onnistu, jos osapuolet eivät luota toisiinsa. Onnistunee palveluintegraation avaintekijät ovat luottamus, keskinäinen kunnioitus  ja hyvä suhteiden hallinta.

Miten SLAt saa toimimaan

Eräs vastaaja vastasi äskeisessä pikakyselyssä näin :”minua on harmittanut epäpätevä keskustelu SLA:n hyödyistä ja sen kyvyistä ohjata prosessien priorisointia. Keskustelu on mielestäni sivuraiteella”

Vastaaja on varmasti oikeassa. SLA eli palvelutasosopimus tai -lupaus on hyvä työkalu kun sitä käytetään oikein. Väärin käytettynä siitä sen sijaan voi olla haittaa. Tässä näkemykseni siitä miten SLAt saa toimimaan oikein.

SLA toimii silloin kun:

  1. asiakas tietää tarkalleen mitä haluaa ja on valmis maksamaan siitä
  2. toimittaja kykenee säätämään palvelun halutulle tasolle

Ensimmäinen edellytys on siis, että puhutaan melko vakiintuneesta palvelusta, joka on kuvattu täsmällisesti. Esimerkiksi matkatoimiston käyttämä hotelliluokitus on aika hyvä esimerkki toimivasta SLAsta palveluissa. Viiden tähden hotelleja haluavat matkailijat ovat matkatoimiston kannalta ihanneasiakkaita, eikä heille kannata tuottaa pettymystä.

Asiakkaan vaatimukset

It-palveluissa ensimmäinen pulma tulee siitä, että asiakas ei osaa sanoa mitä tarvitsee. Tai tarkemmin sanottuna: asiakas ei osaa sanoa riittävän tarkasti mitä haluaa. Palvelusopimuksen neuvottelijat eivät ehkä itse käytä palveluja, eivätkä osaa tarkalleen määritellä vaatimuksia. Toinen pulma tulee siitä, että palvelujen sisältö muuttuu kaiken aikaa. Asiakas ei voi tietää omia tulevia tarpeitaan kun palvelun sisältö muuttuu ja it-palvelut usein muuttuvat jatkuvasti.

Huono esimerkki SLAsta on käytettävyysprosentti. Äskeisen SuperBowl ottelun aikana oli puolen tunnin sähkökatko. Jos katko oli ainoa, käytettävyys oli silti vuositasolla 99,99% ja kuukausitasollakin 99,9%. Ysien määrä ei auta, jos palvelu pettää kriittisellä hetkellä. Jotkut tarjoavat vastaukseksi 100%  palvelutasovaatimusta, mutta se voi olla usein turhaa ja kallista.

Pitäisikö palvelutaso aina mitata asiakkaan hyötyjen kautta kuten Stuart Rance esitti aiemmin. Mielestäni kyllä jos mahdollista, mutta usein se lienee mahdotonta. Lisäksi meillä Suomessa hyvin suuri osa it-palveluista on ulkoistettuja, eikä palvelun tuottajalla ole edes suoraa yhteyttä palvelua hyödyntävään liiketoimintaan.

Toimittajan kypsyys

Palvelutason säätäminen edellyttää paljon toimittajalta. Toimittajalla on oltava hyvä hallinta palveluista ja toimittajan tulee kyetä säätämään palvelutasoa. Palvelusopimusten tulee vastata täsmälleen sitä, mitä tuotetaan. Häiriötekijöiden syyt pitää tuntea ja niihin pitää voida vaikuttaa.

Priorisoinnin pitää toimia hyvin ja yli prosessirajojen. Henkilöstön pitää tietää missä järjestyksessä työt tehdään.  Osa palveluntuottajista varmasti pystyy tähän, mutta se ei tarkoita sitä, että palvelu onnistuisi sen käyttäjien kannalta. Palvelun tuottajan on hyvin vaikea tietää esimerkiksi asioiden todellisia prioriteetteja, jos he toimivat etäällä palvelun käyttäjistä.

Vaihda toimittajaa, mutta katso ensiksi peiliin  

Sanktiot koetaan tärkeiksi, koska ilman niitä palvelu ei toimi. Sanktiot ovat kuitenkin huono väline yhteistyössä. Parempi vaihtoehto olisi vaihtaa toimittajaa kunnes löytyy sellainen, joka palvelee hyvin ilmankin sanktioita.

Mikäli palvelussa on ongelmia, pitää selvittää ongelmien syyt. Palvelun tuottaja on hyvä syntipukki omille virheille. Palvelussa voi myös olla rakenteellisia ongelmia, jotka aiheuttavat ongelmia palveluntuottajasta riippumatta.

Helsingin Sanomien mielipidekirjoituksessa toivottiin VR:lle kilpailua ja kirjoittajan mukaan sanktioilla saadaan paremmin toimiva junaliikenne. Mielestäni toive on tuulesta temmattu. Helsingin aseman ohjausjärjestelmä ei tottele sanktioita sen enempää kuin lumipyrytkään. VR:n pilkkomisen seurauksena kokonaisvastuu on kadonnut ja sama pätee moniin it-palveluihin.

%d bloggers like this: