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ä.

 

Turhan monimutkaista

Kaksi vuotta sitten Rik Maes piti loistavan esityksen itSMF Finlandin konferenssissa Kalastajatorpalla. Hän näytti mm. hollantilaisen potilastietojärjestelmän kaaviota. Hän antoi meidän katsella sitä hetken. Se oli hyvin monimutkainen, paljon laatikoita ja viivoja, eikä kukaan ymmärtänyt siitä mitään. Sitten hän näytti yhtä laatikkoa alanurkassa, siinä oli potilas. Potilaasta oli tullut sivuseikka.

Sain hiukan samanlaisen tunteen kun katsoin hyvämaineisen konsultin laatimaa kaaviota it-palvelunhallintajärjestelmästä service deskin perustamista varten. Ainoa ero oli, että tästä kaaviosta ei löydy sitä potilasta eli asiakasta edes alanurkasta. On varmaankin helppoa arvata että keskiössä on konfiguraationhallinnan tietokanta CMDB, jonka ympärillä järjestelmä pyörii. Järjestelmä on tehty itilin mukaisesti ja tulos on varsin monimutkainen.

Service deskin keskeinen tehtävä on asiakaspalvelu, hyvä service desk lisää asiakkaitten tuottavuutta poistamalla heidän työtään haittaavia esteitä. Esteet voivat olla monenlaisia, myös henkisiä. Asiakas voi esimerkiksi pelätä tai inhota tietotekniikkaa ja niiden esteiden voittaminen on aivan yhtä tärkeätä kuin jonkin viallisen nippelin korjaaminen. Siksi Service Desk järjestelmän pitää rakentua asiakkaan ja tämän pulman tai tarpeen ympärille. Toki konfiguraationhallinta on tarpeellista, mutta sillä ei ole mitään osaa asiakaspalvelussa. Service deskin tarpeet ovat erilaiset kuin järjestelmäasiantuntijoiden tarpeet.

Toinen vastaava monimutkaistaja on palveluluettelo. Kuten hyvin tiedämme, asiakkaiden näkemys palveluista on varsin erilainen kuin niitä tuottavan it-organisaation näkemys. Asiakas niputtaa asiat yhteen omien kokemustensa kautta, palvelun tuottaja taas katsoo samaa asiaa omien vastuittensa kautta. Asiaa mutkistaa vielä se, että koko palvelukäsite on hyvin hankala, esimerkiksi itilin määritelmä on puuta heinää, ei sisäinen it poista emo-organisaation kustannuksia ja riskejä, kuten itil väittää. Olen kirjoittanut tästä aiemmin katso: Selkeyttä palveluun.

Kun asiakaspalvelujärjestelmä kytketään palveluluetteloon ja CMDB:een tuloksena on monimutkainen ja vaikeasti hallittava kokonaisuus. Mitään lisäarvoa kytkennästä ei saada. Tai siis toki järjestelmän rakentavat konsultit saavat.

Unohda siis CMDB ja palveluluettelot, kun rakennat service deskin järjestelmää. Keskity asiakkaaseen ja tämän asiaan. Muista, että asiakkaan ongelman ratkaiseminen ei ole sama asia kuin jonkin vian korjaaminen, ne ovat kaksi ihan eri asiaa. Unohda itil, käytä järkeä.

%d bloggers like this: