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.

 

Service Deskin kommunikaatiokanavat

Pikakyselyn tavoitteena oli selvittää mitä kommunikaatiokanavia service deskeissä käytetään Suomessa 2016. Kysely oli tämän näköinen.

Tässä on yksi kysymys, johon voi vastata kahdesta näkökulmasta. Ensimmäinen tilanne on kaikille ja toinen niille, jotka ovat töissä tietotekniikkaan liittyvää asiakas- tai tukipalveluja tarjoavassa yksikössä.
Kirjoita vastauksesi kysymyksen perään ja lähetä vastauksesi sähköpostilla.

Mitä kontaktikanavia tietotekniikkapalveluihin liittyvissä kysymyksissä on käytössä?
1) Olen itse käyttänyt näitä kanavia tämän vuoden aikana:

2) Tarjoamme palvelutoimittajana näitä kanavia:

Vastausvaihtoehdot, merkitse kaikki soveltuvat kanavat ylläolevien kaksoispisteiden perään.

 

a) puhelin
b) sähköposti
c) lomake tai sovellus www-sivuilla
d) käynti palvelupisteessä
e) Twitter
f) Facebook
g) avoin keskusteluforum
h) sisäinen (suljettu) keskusteluforum
i) muu, mikä
x) en ole tarvinnut olla yhteydessä tämän vuoden aikana

Vastauksia tuli 50 kpl heti ensimmäisellä kierroksella. Uusintakierros olisi varmasti kasvattanut vastaajamäärä, mutta katsoin, että tämä riitti. Tulos olisi tuskin muuttunut merkittävästi.

dia1

Kanavia on otettu käyttöön hyvin. Keskiarvo on 4,5 kanavaa ja hiukan vajaa puolet vastaajista kertoo käytössä olevan viisi tai enemmän kanavaa. Yleisin vaihtoehto on kuusi kanavaa.

dia2

Perinteiset puhelin ja sähköposti ovat yleisimmät. On myös tavallista, että asiakkaat voivat syöttää tiedot itse järjestelmään. Palvelupisteiden suosio on kasvanut nopeasti ja myös sisäiset eli suljetut forumit ovat yleistyneet. Avoimen sosiaalisen median käyttö on melko harvinaista.

On hyvä pitää mielessä, että tämä ei kerro vielä mitään yhteydenottojen määrästä. Ryhmässä muu yleisin on chat, jonka mainitsi yli 10% vastaajista, ja eräs vastaaja kertoi sen ohittaneen volyymissä puhelinliikenteen. Muita esiin tulleita kanavia olivat Skype, Lync, SMS ja Jira.

On todennäköistä, että chat on paljon yleisempi kuin reilu 10 %, mutta koska se unohtui pois luettelosta, sen osuus jäi vastauksissa vähäisemmäksi.

dia3

Vastaajien oma käyttö ei suuresti poikkea tarjonnasta.

Johtopäätökset

Usean kanavan tarjoaminen on selvästi yleistyvä käytäntö. Tämä on järkevää, sillä perinteinen puhelin on kallis kanava. Monet uudet kanavat säästävät sekä asiakkaan että palveluntarjoajan resursseja.

Kannattaa siis harkita uusien kanavien käyttöönottoa. Kaikki kanavat eivät tietenkään sovi kaikille organisaatioille, mutta asiaa pitää harkita avoimesti. Esteenä voivat olla myös omat ennakkoluulot ja tiedon puute. Sysäyksen tälle selvitykselle antoi tuore ITIL practitioner -kirja, jossa kanavia käsitellään hyvin vähän ja sekin oudosti. Arvion kirjasta löydät täältä.

 

Eri palvelukanavien yhteispeli

Tein kesällä vahinkoilmoituksen OP-Pohjolalle. Kännykkä oli päässyt meriveteen ja lakannut toimimasta. Aurinkolasit päätyivät samalla kertaa meren pohjaan. Vastausta ei kuulunut. Lopulta soitin ja tiedustelin asiaa. Kohtuullisen jonotuksen jälkeen minulle vastattiin ja sain ohjeet, miten toimia. Virkailija pahoitteli, ettei sähköistä ilmoitusta oltu käsitelty ruuhkan takia.

Toimin ohjeiden mukaisesti ja täydensin ilmoitusta kuiteilla kännykän vaihdosta ja uusien aurinkolasien ostosta. Mitään vastausta ei tullut, eivätkä luvatut korvaukset ilmestyneet pankkitilille. Soitin uudestaan. Nyt en jaksanut jonottaa vaan tilasin takaisinsoiton. Se tuli kohtuullisen nopeasti, mutta olin juuri silloin katveessa. Virkailija jätti ääniviestin ja lupasi soittaa uudestaan. Sen hän tekikin. Kerroin pulman, hän tarkisti hakemuksen ja sanoi sen olevan ok. Valitteli taas kiirettä, mutta käsitteli asian saman tien ja laittoi rahat maksuun. Ne olivat tilillä seuraavana päivänä.

Periaatteessa ihan ok palvelutapahtuma, mutta siinä oli mielestäni kaksi aika tavallista virhettä. Oli ilmeistä, että OP-Pohjola suosii puhelinasiakkaita. Puhelimessa asiat hoituvat, sähköisesti eivät. Tämä vastaa aika hyvin aiempia kokemuksiani Tapiolan kanssa, joten ajattelin kirjoittaa ilmiöstä.

Jos sähköinen asiointi olisi toiminut, olisi vältetty kolme puhelua. Toimintaohjeita ei olisi tarvinnut antaa puhelimessa, vaan ne olisi voinut kopioida ohjekirjastosta. Asian käsittelyyn olisi kulunut vain murto-osa nyt kuluneesta ajasta. Sama henkilö olisi voinut käsitellä arviolta viisi asiakasta siinä ajassa mitä heiltä kului kanssani.

Oletan, että kyse on siitä, että OP-Pohjolan johto seuraa palvelumittareita, joissa puhelutilastoilla on suuri paino ja siksi henkilökunta keskittyy tuottamaan mahdollisimman hyvää puhelinpalvelua. Perusteluna on varmaankin se, että valtaosa asiakkaista käyttää puhelinpalvelua mieluummin. Tämä argumentti ei toimi. Todellisuudessa ihmiset ovat valmiita muuttamaan tapojaan nopeasti, jos uusi tapa on parempi. Muistan hyvin, kuinka hauskaa oli ohittaa jono lentokentällä, kun ryhtyi käyttämään itsepalvelua perinteisen palvelutiskin sijaan. Valitettavasti muutkin oppivat sen nopeasti.

Vakuutusyhtiöiden pitäisi tarjota sähköisillä kanavilla nopeampaa palvelua. Sähköiset hakemukset pitäisi käsitellä 15 minuutissa, johdon pitäisi olla kiinnostunut sähköisten kanavien suosiosta ja puhelinkanavan painoarvoa pitäisi pudottaa.

Vakuutusyhtiöillä näyttää myös olevan taipumus tehdä sähköisestä asioinnista mahdollisimman hankalaa. Viestit pitää tehdä heidän suljetun verkkonsa kautta ja kaikki vastaukset tulevat myös samaa reittiä. Ymmärrän toki, että luottamuksellisen tiedon lähettäminen sähköpostilla sisältää riskejä, mutta valtaosa viesteistä on täysin epäluottamuksellisia. On typerää lähettää asiakkaalle sähköposti, jossa kerrotaan, että suljettuun postilaatikkoon on tullut (tyhjänpäiväinen) viesti. Sähköpostissa pitäisi kertoa lähetetyn viestin sisältö.

Vastaavasti sähköiseen viestintään on helppo asettaa turhia rajoituksia ja ehtoja, joita puhelinpalvelussa ei sovelleta. Kyse lienee kaikkiaan siitä, että erilaiset keskijohdon jäsenet pääsevät pätemään järjestelmän määrityksissä, ja asiakasnäkökulma unohtuu.

Where is the customer?

Imagine that you come to a hotel and find a Service Desk where a cheerful person assures you that if there is any incident with your room, one of the service specialists will start fixing it within twenty minutes. Behind her, you can se some plumbers, electricians and carpenters ready with their tools, waiting for the next incident. Wouldn’t you want to find another hotel?

The early years of computing were difficult, technology was new and unreliable. It was understandable that incident management was important. But it is a bit silly that customer service is still missing from current ITSM or that it is so technology centric.

This technology centric view of service can be seen in graphs that describe the support processes. In most cases that I have seen, there is no customer service and actually no customer. It is far more likely to find a CMDB or a service catalog in the center of the picture than a customer. The same thinking seems to carry over from ITIL to all other frameworks, standards and methods. Customer service is seen as the restoration of service after an incident.

The technology centric thinking comes with a price. A lot of effort is lost. Incidents need to be connected to the relevant configuration items and services. Many of my customers have configuration management systems and service catalogs but the logging of incidents with service and configuration information provides no value. My major subject in university was statistics and when I started ITSM consulting I was thrilled that I could start analyzing incident data and find valuable information for my customers. That has never happened. Yes, I have analyzed incident data a few times but every time the data has proven to be rubbish. Garbage in, garbage out is a good rule in statistics.

The ITSM thinking should put the customer in the middle and ask the question how does this process or value stream produce value to the customer. I think that the customer centric framework for ITSM would look completely different.

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.

Fusion14

Fusion on itSFM USA:n ja HDIn yhteinen konferenssi, joka järjestettiin tänä vuonna Wasington DC:ssä. Paikkana on Gaylord National, joka sijaitseen itseasiassa Marylandissa, joen toisella puolella. Minulle näiden konferenssien suurin anti on kavereiden tapaaminen. Tällä kertaa tapasin monta henkilöä, joiden kanssa olen ollut tähän asti tekemisissä vain sosiaalisen median kautta, mutta toki myös monta vanhaa kaveria.

Välillä oli melkein julkkisfiilis. Tämä oli kyllä ehdottomasti huikein tervehdys:Fusion3

En ollut tavannut kaveria aikaisemin muuten kuin sosiaalisesssa mediassa. Olimme jollain VIP vastaanotolla ja hän näkee nimikylttini ja alkaa tosiaan hokea Aale Roos, olet jumala…

Konferenssissa ei ainakaan minulle noussut esiin mitään selkeää teemaa. Ehkä jonkinlainen hämmennys voisi kuvata parhaiten mielentilaa. Internetin ja mobiliteetin tulevasta vallankumouksesta on puhuttu paljon ja hartaasti, mutta nyt kun se lopulta on lähtenyt käyntiin suuressa mittakaavassa niin kaikki ovat ymmällään.

ITIL ja muut vanhat mallit ovat menettäneet viehätysvoimaansa, mutta vakavia kilpailijoita ei ole vielä ilmestynyt tilalle.

Oma esitykseni oli ehkä paras, mitä olen koskaan pitänyt. Sain hyviä kommentteja ja kritiikkiä järjestäviltä. Fusion14 conference photos.

Lisäksi sain puhua täpötäydelle salille, joka on aina innostavaa. Joitakin ihmisiä istui lattialla ja seisoi salin takaosassa.

Fusion14 conference photos.

Olin etukäteen hiukan huolestunut oman esitykseni ajankohtaisuudesta. Tiedän että Service Desk 2.0 on täällä Suomessa etäistä tulevaisuutta monille, mutta en ollut varma siitä missä USAssa mennään. Huoli osoittautui turhaksi, USAssa ei olla meitä edellä tässä suhteessa, mutta oli positiivista huomata, että moni kuulija näytti tajuavan viestini. Monet tulivat kiittelemään jälkeen päin ja kertoivat esityksen herättäneen ajatuksia.

 

 

Palvelupiste

Kun aloitin oman urani IT -tuen piirissä, tuki oli aina lähitukea. Yliopistolla päätteet olivat tietokonekeskuksessa ja käyttäjät tulivat sinne. Oli luontevaa järjestää paikalle tukihenkilö, joka auttoi pulmatilanteissa. Näin käyttäjät eivät häirinneet muuta henkilökuntaa kysymyksillään. Palvelupisteiden tarve katosi, kun päätteet tulivat jokaisen pöydälle. Ei ollut mitään järkevää syytä päivystää tiskin takana, sillä asiakkaat eivät voineet raahata laitteitaan sinne. 

Puhelimessa etänä annettu tuki yleistyi vasta myöhemmin, vielä 90-luvulla oli tavallista että pulmat ratkottiin lähettämällä henkilö paikan päälle. Oikestaan vasta etähallinnan yleistyminen vähensi lähituen tarpeen minimiin. Lähituen ongelma on sen kalleus ja huono ennustettavuus. Lähitukihenkilöiden aika kuluu paikasta toiseen liikkuessa ja etukäteen on vaikea arvioida kuinka kauan joku käynti kestää.

Nyt tilanne on muuttunut. Henkilöillä on usein vain mukana kulkevia laitteita. Kaikilla ei ole omaa työpistettä vaan työpisteet vaihtuvat päivittäin. Nyt on paljon luontevampaa tarjota palvelupiste, jonne asiakas voi tulla laitteensa kanssa. Tietotekniikan merkitys on myös kasvanut, monet meistä eivät pysty tekemään töitään ilman laitteitaan. Jos ne lakkaavat toimimasta, tarvitsemme apua välittömästi. Tämän päivän käyttäjällä ei ole juuri muuta vaihtoehtoa kuin keskeyttää muut työt ja keskittyä toimimattoman laitteen korjaamiseen tai vaihtamiseen.

Kysyin maanantaina lähituen ratkaisuista ja olen nyt saanut 50 vastausta. Kysely oli tällainen:

Olen kiinnostunut IT-lähituesta. Voit vastata joko asiakkaan roolissa tai tuen tarjoajan roolissa. Tässä on vain kolme kysymystä.
 
Lähituella tarkoitan sellaista palvelua, jossa asiakas ja tuen henkilö kohtaavat. Kohtaaminen voi tapahtua joko niin, että lähitukihenkilö tulee asiakkaan luokse tai niin, että asiakas menee tukipalveluun, jossa on palvelupiste.
 
Lähituki ei tietenkään korvaa puhelimella tai muulla viestivälineellä annettua etätukea, mutta tämä kysely koskee ainoastaan lähitukea.
 Tässä kysymykset:
 1) Mikä on roolisi lähituen suhteen?
a) olen asiakas
b) työskentelen tuessa
c) vastaan tuesta (esimies tai esimiehen esimies jne)
 
2)  Mitkä näistä vaihtoehdoista sopivat (voit valita useita, laita tärkein ensimmäiseksi)?
a) service desk lähettää tukihenkilön asiakkaan luokse tarvittaessa
b) meillä on palvelupiste, jonne asiakkaat ovat tervetulleita pisteen aukioloaikoina
c) meillä on palvelupiste, jonne asiakkaat ovat tervetulleita, mutta heidän pitää varata aika
d) meillä ei ole lähitukea
 
3) Anna kouluarvosana (10-4) lähituen toimivuudelle, perustele tarvittaessa.

 Vastaajista enemmistö (61%) edusti asiakkaita. Service deskin henkilökuntaa oli vain muutama henkilö ja yhdistin heidät palvelusta vastaaviin henkilöihin.

Slide1

Selvä enemmistö tarjoaa perinteistä lähitukea, jossa siis tukihenkilö tulee asiakkaan luokse. Reilu kolmannes on ottanut myös palvelupisteen käyttöön ja kymmenellä prosentilla ei ole palvelupisteen lisäksi muuta lähitukea. Muutama vastaaja kertoi, ettei heillä ole lainkaan lähitukea.

Tyytyväisyys lähitukeen riippuu tukiratkaisusta ja vastaajasta. Asiakkaiden mielestä palvelupiste on selvästi parempi ratkaisu kuin asiakkaiden luokse tuleva tukihenkilö. Service Deskistä vastaavat henkilöt eivät nähneet suurta eroa ratkaisujen välillä. Tässä on selvästi kyse näkökulmasta. Service Desk -vastaavat viittasivat usein yleisiin asiakastyytyväisyyskyselyihin koko asiakastuesta, mutta asiakkaan roolissa vastanneet kertoivat omasta kokemuksestaan. Lähituen laatua ei moitittu mutta sen täsmällisyyden kanssa oli ongelmia. On selvää ettei lähituen aikatauluja voi ennustaa kovin tarkkaan.

Slide2

Kuvassa ei näy niitä, joilla ei ole lainkaan lähitukea, sillä heidän tyytyväisyytensä on aivan omilla lukemillaan. Kouluarvosana 5,7 on aika harvinainen keskiarvo missään kyselyssä, mutta vastaajien määrä oli pieni. Sinänsä aika käsittämätöntä, että jotkut päättäjät halveksivat niin paljon henkilökuntaansa, etteivät viitsi järjestää asiallista tietotekniikkatukea. Mitäköhän he kuvittelevat säästävänsä.

Mielestäni lähituen korvaaminen palvelupisteellä, on harkinnan arvoinen asia. Se voi lisätä asiakastyytyväisyyttä ja leikata kustannuksia. Lähituen liikkumiseen käytetty aika voidaan hyödyntää parempaan palveluun.

Ehdoton edellytys on se, että varsinaiset palvelut ovat kunnossa, jos perusasiat ovat pielessä ei kannata yrittää piilottaa ongelmia korean julkisivun taakse. Lisäksi edellytyksenä on, että trpeeksi moni käyttää mobiileja laitteita ja että on olemassa luonteva keskus, tai keskuksia, jonne palvelupisteen voi perustaa.

Olen kirjoittanut samasta aiheesta myös englanniksi ja tämä ei ole suora käännös.

%d bloggers like this: