Service Deskin laskutus

Sain tällaisen kysymyksen ja päätin vastata siihen blogilla: ”Mitä etuja tai riskejä näet Service Deskin tikettipohjaisessa tai loppukäyttäjämääräisessä laskutuksessa?” Oletan että kyseessä on ulkoistetun service deskin laskutusvaihtoehdot. Joko laskutetaan kirjattujen tikettien mukaan, tai käytössä on kiinteä kuukausilasku, joka perustuu käyttäjien lukumäärään.

Pidin juuri TIVI Service Desk-päivillä esityksen: ”Miten Service Desk tuottaa arvoa?”, jossa käsittelin aihetta. On tärkeä ymmärtää, miten IT:n tuottama arvo muodostuu. Arvoa syntyy kun asiakas käyttää tietotekniikkaa omassa työssään, luodakseen organisaation tuottamaa arvoa. Joskus tietotekniikka voi tuottaa suoraan arvoa, mutta yleensä se on mukana muodostamassa sitä. Erilaiset pulmatilanteet vähentävät tätä arvon tuottamista, ja service deskin tehtävänä on minimoida arvon tuottamisen menetys.

Nykyaikainen deski toimii monien kanavien kautta. Itsepalvelu, tietopankki ja keskusteluforumit ovat esimerkkejä tukikanavista, jotka eivät tuota tikettejä. Monet tutkimukset ovat osoittaneet, että service desk on melko harvoin asiakkaitten ensisijainen tukivaihtoehto. Ihmiset etsivät tietoa, kysyvät kavereilta ja pääkäyttäjiltä, ennekuin he ottavat yhteyttä tukeen. Hyvä service desk toimii kaikilla kanavilla ja pyrkii minimoimaan asiakkaitten menettämän työajan.

Ajatellaan esimerkiksi, että käyttäjiä on 10.000 ja yhden yhteydenoton hinta on 50€ ja jokainen käyttäjä on keskimäärin kerran kuukaudessa yhteydessä deskiin. Tuen hinta voisi silloin olla joko 500.000€ per kk tai 50€ per tiketti, jolloin kokonaisveloitus olisi kummallakin tavalla sama.

Kuvitellaan, että service deskissä havaitaan, että jokin asia, vaikka epäselvä ohje, aiheuttaa 2.000 yhteydenottoa vuodessa. Tikettipohjaisessa laskutuksessa tämä tarkoittaisi 100.000€ laskutusta vuodessa. Tikettipohjaisesti laskuttavan service deskin kannalta olisi järjetöntä pyrkiä korjaamaan yhteydenottojen aiheuttajaa. Toisaalta jokainen yhteydenotto todennäköisesti edustaa keskimäärin puolen tunnin työmäärää, kun henkilö on yrittänyt selvittää asiaa itse ja mahdollisesti kysynyt kollegoiltaan. Menetetty työaika olisi siis asiakkaalle 1.000 tuntia vuodessa ja siitä aiheutuisi vielä 100.000€ lisälasku.

Kiinteän kuukausilaskutuksen ongelma on taas se, että service deskin kannattaa minimoida asiakkaiden yhteydenottoja kaikin tavoin. Valitettavasti helpoin tapa on tarjota huonoa palvelua. Pitkät jonotusajat, ärsyttävä jonotusmusiikki, töykeä palvelu, osaamattomat työntekijät jne. ovat valitettavan tuttuja keinoja yhteydenottojen minimointiin.

Kummassakin laskutustavassa on huonot puolensa, mutta mielestäni tikettipohjainen laskutus on ehdottomasti kelvoton vaihtoehto. Se mittaa ainoastaan yhteydenottoja eli aktiviteetteja, ei arvoa. Käyttäjämääriin perustuva laskutus mahdollistaa service deskille pyrkimyksen tuottaa aidosti arvoa.

Suosittelisin kuitenkin service deskin ottamista omaan organisaatioon. Tässä esimerkiksi menestystarina, jossa onnistuttiin tekemään samalla kustannuksella parempi deski. http://www.tivi.fi/Kaikki_uutiset/if-otti-tiedolle-ulkoistetun-palvelun-omiin-kasiin-samalla-rahalla-enemman-6247634

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.

%d bloggers like this: