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

Parempi laatu, pienemmät kustannukset

Turhan työn poistaminen on avain laadun kehittämiseen kustannuksia vähentämällä. Olen koonnut tähän joukon ideoita, mistä voit löytää hyviä kohteita turhan työn vähentämiselle. Nämä ovat ideoita ja niiden soveltaminen pitää tehdä harkiten. Organisaatiosta varmaan löytyy henkilöitä, jotka vastustavat näitä ehdotuksia. Pyydä vastustajia esittämään saavutetut hyödyt ja tarkista kaikkien osapuolten näkemys. Hyvin toimivia käytäntöjä ei tietenkään kannata purkaa, jos ne toimivat hyvin kaikkien osapuolten mielestä. Asiakkaan mielipide on aina tärkeä.

  1. Unohda palveluluettelo, jos se ei tunnu toimivan. Olen nähnyt lähinnä vain huonoja ja hyödyttömiä palveluluetteloja, joita puolustavat vain niiden kehittäjät. Kaikkea IT-toimintaa ei tarvitse kuvata palveluna. Monissa tapauksissa liiketoiminta ja asiakkaat tekevät yhdessä asioita, ja IT-väen tehtävänä on tarjota asiantuntemusta, osaamista ja tekemistä yhteisten tavoitteiden eteen. Yhteistyö ja palvelu ovat eri asioita.
  2. Unohda SLAt. Keinotekoiset palvelutasot eivät takaa laadukasta palvelua, mutta työllistävät paljon. Kaikkea ei voi mitata hyvin ja huonot mittarit ovat turhia.
  3. Unohda CMDB. Sen rakentaminen ja ylläpitäminen on työlästä. Oletko varma, että siitä saadaan todellista hyötyä. On mahdollista, että CMDB:tä ylläpidetään, koska johto on niin määrännyt mutta kaikki tietävät, ettei sen tietoihin voi luottaa.
  4. Poista turhat tiketit. Automaattivalvonnan hälytyksistä on turha avata tikettejä. Asiat pitää hoitaa mahdollisimman vähillä vaiheilla. Tiketin avaaminen ja sulkeminen ovat turhia työvaiheita.
  5. Poista turhat kentät tiketeistä. Keskity olennaiseen. Palveluluettelon ja CMDB:n poistaminen auttaa, mutta vaikka et poistaisi niitä, on silti turhaa kytkeä kaikkia ongelmia johonkin tiettyyn palveluun tai konfiguraation osaan. Usein niiden määrittely on vaikeaa tai mahdotonta. Pakolliset luokittelut tuottavat roskatietoa.
  6. Unohda turhat prosessit. Prosessi on hyvä apuväline toistuvien rutiinien pyörittämiseen, mutta se ei sovellu kaikkeen tekemiseen.
  7. Unohda turhat mittarit. Prosessiajattelu luo helposti paljon prosessimittareita, joilla ei ole oikeasti mitään järjellistä käyttöä. Älä mittaa aktiviteetteja ja älä ainakaan aseta niille tavoitteita. Keskity tuloksiin, ei puuhasteluun.
  8. Rakenna asiakkaille palvelupisteitä, joissa heitä autetaan tietotekniikan kanssa. Yksi vierailu voi ratkaista monta ongelmaa ja säästää aikaa sekä asiakkailta, että asiakastuelta.
  9. Ole mukana sosiaalisessa mediassa, jos asiakkaasi ovat siellä. Yritä luoda keskusteluforumeita, joissa asiakkaat voivat keskustella palveluihin liittyvistä asioista. Yksi hyvä keskustelu voi ratkaista monen asiakkaan pulman.
  10. Kuuntele asiakkaiden mielipiteitä, mutta älä kiusaa heitä turhilla ja huonoilla kyselyillä.

Roles are more important than processes

A role is a combination of responsibilities which some person can assume. It requires a set of capabilities which the person needs to have. We think that roles are important in a Service Desk. Do not equate roles with processes, while a managers role will include responsibility over some process, there is more as a process is just one tool.

Processes work well in routine situations, where the results are predictable. It is good to have a set of efficient and effective processes running for common ITSM events. But processes will not make a great service or protect you from difficult situations. The real challenge lies in unexpected, complicated, complex or chaotic situations where there are no standard answers and any process is a waste of time.

A role is in charge of all kinds of events, the person acting the role needs to be prepared for unexpected events and reactions. Competense, experience and skills are important. The person needs to be capable of innovating new solutions to new problems when standard processes and procedures fail.

Roles should be defined, but not in a detailed and limiting way. A role is defined by the main value it creates and by the required capabilities. I hope this is obvious to most, but it is easy to misunderstand the ITIL process framework and see the roles limited to the processes.

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.

Sosiaalinen media asiakastuessa

Eräs lukija kommentoi Pohjoisviitan sivujen taustalla näkyvää lumisadetta. Olin itsekin ihmetellyt mistä se sinne oli tullut ja miksei se mene pois. Yritin ensin katsella asetuksia, mutta niitä on niin paljon. Seuraavaksi siirryin tukisivuille ja sieltä keskustelufoorumille. Ei mennyt montaa sekuntia kunnes löysin aihetta käsittelevän keskustelun ja ohjeen lumisateen poistoon.

Keskusteluja käyvät alan harrastajat, eli vastauksen antoi henkilö, joka ei ole töissä Automattic:illa. Toimi hyvin eikä aiheuttanut työtä tuelle.

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.

 

 

Ongelmat

Löysin twitter-arkistosta vanhan twiittini syyskuulta 2009: It was fun to explain the concepts of incident, problem, error KE to a class who had not heard the terms before. They have power! Eli olin selittänyt insidentin, ongelman, virheen ja tunnetun virheen käsitteitä kurssilla ja saanut innostuneen vastaanoton. Nuo käsitteet selkeyttivät monia asioita ja ihmiset tajusivat havaitsemiaan ilmiöitä käsitteiden avulla. Ne auttoivat jäsentämään omaa työtä ja olivat siinä mielessä hyödyllisiä.

Jos määritelmät ovat unohtuneet, niin kertaan niitä tässä nopeasti. Itilin määritelmän mukaan ongelma (problem) on yhden tai useamman häiriön (insidentin) tuntematon perussyy (root cause) ja error tai known error on sitten tunnistettu virhe, joka aiheuttaa insidentin.

Kun itiliä kirjoitettiin, havaittiin että usein häiriöiden korjaaminen vei niin paljon aikaa, ettei niiden syihin ehditty puuttua. (Kun itse olin asiakaspalvelun päällikkö, huomasin että usein syynä ei ollut mikään kiire, vaan ennemmin laiskuus.) Tämän takia päätettiin luoda erillinen ongelmanhallinnan prosessi eli Problem Management. Prosessi osoittautua vaikeaksi ja se sai monta erilaista ja väärää tulkintaa. Ongelmanhallinnasta tuli usein vain tapa käsitellä vaikeita häiriöitä. Versio 3:n kirjoittajat kirjoittivatkin prosessin uusiksi havaitsemiensa käytäntöjen pohjalta eli kirjasivat väärinkäsitykset uudeksi parhaaksi käytännöksi. Tämä sitten korjattiin vuoden 2011 versiossa, mutta lopputulos ei onnistunut vieläkään.

Itilin ongelmanhallinta on epämääräinen käsite. Pohjimmiltaan ongelmanhallinta ja häiriönhallinta ovat samoja prosesseja ja tekevät samoja asioita. Tämä on resurssien tuhlausta ja sotkee toimintaa. On aivan selvää että yksi prosessi riittää häiriöiden ratkomiseen.

Olen aiemmin tässä kirjoitussarjassa erottanut asiakkaan ongelman ja häiriön toisistaan. Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Häiriö on tilanne, jossa joku asia ei toimi halutulla tavalla. Häiriö voi aiheuttaa asiakkaan ongelman, mutta ongelmia voi olla ilman häiriöitä. Häiriön korjaamisen pitää ulottua myös häiriön aiheuttajien käsittelyyn. Emme missään nimessä tarvitse erillistä prosessia vaikeiden häiriöiden korjaamiseen, on vastuutonta toimintaa palauttaa vain palvelu takaisin selvittämättä miksi se häiriintyi.

On selvää, että palveluja pitää kehittää. Tunnetut viat (Known Error) ovat jokapäiväinen ilmiö. Kaikkia vikoja ei kannata korjata. Asiakkaiden ongelmia voi myös ilmetä ilman minkäänlaisia häiriöitä eli asiakas joutuu ongelmiin vaikka palvelut toimivat aivan oikein. Häiriöt voivat toistua vaikka niiden aiheuttajat on korjattu.

Itil tarjoaa liudan ”prosesseja” palvelun kehittämiseen ongelmanhallinnan lisäksi, löytyy jatkuvuuden hallinta, kapasiteetin hallinta tietoturvanhallinta ja tietysti jatkuva palvelun kehittäminen. Jos siis äkilliset tilantarpeet aiheuttavat palvelukatkoja ja tietoturvariskejä niin mikä ”prosessi” ottaa vastuun?

Ehdotan, että nämä kaikki korvataan yhdellä prosessilla. Riskienhallinta on tarpeellinen, suorastaan välttämätön toiminta, joka tunnistaa riskit ja valitsee niiden käsittelytavan. Lisäksi kaikilla organisaatioyksiköillä ja jopa henkilöillä pitää olla vastuu palvelun kehittämisestä. Jokaisen pitää tarttua havaitsemiinsa mahdollisuuksiin parantaa palvelua.

Mielestäni siis ongelmanhallintaa ei tarvita. Se voidaan korvata riskienhallinnalla. Service Deskin vetäjällä ja kaikilla prosessipäälliköillä on vastuu olla aktiivisesti mukana palvelun laadun kehittämisessä.

%d bloggers like this: