Palvelut ja yhteystiedot

Olen kokenut asiantuntija ja vuoden 2012 ITSM-henkilö. Erityisalueitani ovat IT palvelunhallinta, ISO 20000, service ja help deskit, asiakastyytyväisyyden ja prosessien mittaaminen. Tarjoan konsultointia, koulutusta ja tutkimuspalveluja.

Esiintymisiä
2011: PINK 11, Las Vegas, itSMF Finland  Espoo
2012 itSMF Russia, Moskova, itSMF UK, Lontoo, itSMF Estonia, Tallinna
2013 LeadIT (itSMF Australia), Canberra, itSMF Finland, Helsinki, itSM(F) Belarus, Minsk, itSMF Estonia, Tallinna, itSMF Sweden, video panel
2014: Service Desk Forum , Stockholm
Tulossa
 FUSION14 (itSMF USA), Washington DC  

Tässä erään kuulijan kommentti: I have attended itSMF Estonia conferences 2012, 2013 and you’re presentations really impressed and motivated me.

aale.roos@pohjoisviitta.fi

Pohjoisviitta Oy, Alankotie 29, 00750 Helsinki
GSM +358 (o)5o-5544733
Twitter: @aalem

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

Onko ITIL syvältä?

WordPress näyttää milllä hakusanoilla joku on löytänyt Pohjoisviitan sivut. Luettelossa on parin päivän ajan pistänyt silmään lause ”itil on syvältä”. En ole käyttänyt tuota sanontaa koskaan aikaisemmin, joten haku on tullut tänne todennäköisesti vain sen takia, että olen kirjoittanut aika paljon itilistä suomeksi. Jäin miettimään mitä tuohon vastaisi. Tietyissä olosuhteissa väite on täysin väärä, jossakin tilanteessa taas voin olla samaa mieltä.

Aluksi olin sitä mieltä, että itil on hyvä ja tarpeellinen. Sitten kolmosversio epäonnistui pahan kerran ja itil paisui mahdottomaksi möhkäleeksi. Lisäksi kolmosversiossa oli paljon typeriä virheitä. Nyt olen alkanut kyseenalaistamaan myös alkuperäisen itilin hyötyä. Tämä johtuu osin siitä, että maailma on muuttunut itilin ympärillä. Vanhat 1980-luvun mallit eivät enää istu niin hyvin kuin ennen. Sinänsä mallin ikä ei ole yksinään mikään syy hylätä sitä, mutta itilin tapauksessa käytännöt ovat muuttuneet liikaa. Vanhan mainframe-maailman opit eivät ole tätä päivää.

Mielestäni itil, siis kakkosversio, edustaa yhtä kehitysvaihetta. Kun IT-yksikkö laskeutuu puusta, se tarvitsee itiliä. Itil on parempi kuin ei mitään. Kun itil on hyödynnetty, pitää siirtyä eteenpäin.

Itil puhuu monista hyvistä asioista, mutta sen ratkaisut eivät ole läheskään aina edes käyttökelpoisia. Silti mielestäni IT-ammmattilaisen yleissivistykseen kuuluu tuntea Itil ja ISO 20000. Peruskurssi tai itseopiskelu riittää.

Itilistä on tarjolla runsaasti jatkokursseja ja sertifikaatteja. On huolestuttavaa, jos niiden opiskelija ei tajua viimeistään kolmannen kurssin kohdalla, että itil-koulutusohjelma tosiaankin on syvältä.

Häiriöistä palveluun

Tämä on toinen osa asiakastuen uudistamista käsittelevässä artikkelisarjassa.

Asiakastuen ympäristö on muuttunut valtavasti viimeisten vuosikymmenten aikana. Muinaiset suurtietokoneet ovat kutistuneet ja sujahtaneet ihmisten taskuun. Peruskäyttäjien osaamistaso on noussut merkittävästi. On selvää että sekä asiakastuen, että sen prosessien pitää uusiutua.

Asiakastuen käyttämä häiriöhallinta, incident management on ensimmäinen prosessi, jonka itilin soveltaja ottaa käyttöön ja usein myös ainoa prosessi, joka saadaan toimimaan kunnolla. Prosessin tukena on käytetty tikeitöintijärjestelmiä, joista ensimmäiset otettiin käyttöön 1980-luvulla. Niiden perusperiaatteissa ole juurikaan tapahtunut muutoksia, tiketit avataan, luokitellaan, käsitellään ja suljetaan.

Häiriönhallinnan ensisijaisena tavoitteena on palauttaa palvelu ennalleen. Tämä juontaa juurensa historiasta, jossa palvelut olivat epäluotettavia ja hyvin häiriöalttiita. Nykyaikaisen asiakastuen tehtävänä on tuottaa arvoa auttamalla asiakkaita, joten häiriöiden hoitaminen ja palvelun palauttaminen ei riitä.

Nykyaikainen asiakastuki ei sotke asiakkaan pulmaa ja teknistä häiriöitä toisiinsa, koska ne ovat eri asioita. Palvelun palauttaminen ei ole sama asia kuin asiakkaan ongelman ratkaisu. Asiakastuki keskittyy ensisijaisesti ratkaisemaan asiakkaiden ongelmia. Tarvittaessa se voi myös ratkoa teknisiä häiriöitä, mutta nämä ovat kaksi eri prosessia. Tässä hyvin yksinkertainen esimerkki:

Tärkeä järjestelmä kaatuu kriittisenä hetkenä. Asiakaspalvelun henkilöillä on kaksi vaihtoehtoa, joko he ryhtyvät korjaamaan järjestelmää ja palauttamaan palvelua ennalleen, tai he jättävät järjestelmän korjaamisen seuraavaan aamuun ja keskittyvät häiriön kohteeksi joutuneiden asiakkaiden auttamiseen. Kumpi vaihtoehto on oikea?

Kuvittele että olet illalla kaupan kassalla jonottamassa, kun jonottamasi kassan järjestelmä kaatuu. Varmasti arvostat toimenpiteitä, joiden ansiosta pääset maksamaan ostoksesi mahdollisimman nopeasti. Epäkunnossa olevan kassakoneen ehtii kyllä korjata seuraavana aamuna.   

Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Yleensä esteenä on jokin tietotekninen järjestelmä, joka ei tunnu toimivan halutulla tavalla. Taustalla voi olla jokin häiriö, mutta usein pulma johtuu siitä, että asiakas ei ole osannut käyttää järjestelmää tai että asiakkaalla on virheellinen käsitys järjestelmän toiminnoista. Asiakastuen tehtävänä on ratkaista asiakkaan ongelma. Hyvä tulos voidaan saavuttaa monella tavalla. Asiakkaalle voidaan vaikka neuvoa parempi tapa saavuttaa haluttu tavoite. Asiakkaan ongelma ei välttämättä liity mihinkään infrastruktuurin komponenttiin.

Häiriö on tilanne, jossa jokin järjestelmä ei toimi halutulla tavalla. Häiriö ei välttämättä liity mihinkään asiakkaaseen tai palveluun, mutta se voi haitata useita asiakkaita ja palveluja. Häiriö sen sijaan liittyy johonkin tiettyyn infrastruktuurin komponenttiin. Sama häiriö voi vaikuttaa asiakkaisiin hyvin eri tavoin. Yksi asiakas ei ehkä huomaa sitä ja toinen joutuu suoranaisiin vaikeuksiin sen takia. Kehittynyt palveluntuottaja valvoo palvelujaan ja kykenee havaitsemaan ja korjaamaan useimmat häiriöt ennen kuin ne näkyvät asiakkaille. Häiriöiden korjaamisessa nopeus on tärkeää

Asiakkaiden ongelmien käsittely häiriöinä ohjaa toimintaa väärään suuntaan. Asiakkaan neuvominen vie enemmän aikaa kuin yksinkertaisen ratkaisun antaminen. Uuden toimintatavan opettamisesta voi kuitenkin olla paljon hyötyä.

Lisäksi asiakastuki vastaanottaa tilauksia ja palautetta asiakkailta. Hyvin toimivalla asiakastuella on siis toimiva menettely häiriöiden, ongelmien, palautteen ja tilausten käsittelyyn.

Tämä ei ole mikään suuri muutos, mutta se tuntuu olevan monille silti vaikea ymmärtää, jos oma ajattelu on tiukasti kiinni itilissä. Kannattaa kuitenkin yrittää, koska uudesta mallista on paljon hyötyä. Kirjaaminen muuttuu helpommaksi, koska asiakkaan ongelmia ei tarvitse kytkeä konfiguraatiotietoihin. Niiden priorisointikin voi olla turhaa, edellyttäen että ne pystytään ratkaisemaan nopeasti. Asiakkaan ongelmien lukumäärä, luonne ja kesto ovat hyödyllistä tietoa palvelun kehittämiselle.

Häiriöt ovat vikoja, joiden korjaamisessa tarvitaan täsmällistä tietoa ja jotka on syytä priorisoida. Häiriöitä on normaalisti vähemmän kuin asiakkaiden ongelmia, joten häiriökirjauksia tarvitaan vähemmän.

Seuraavassa artikkelissa pohdin häiriöiden aiheuttajien käsittelyä.

On aika uudistaa asiakastuki

Viimeistelin esitystäni USA:n itSMF:n FUSION konferenssiin, joka on parin viikon päästä Washington DC:ssä. Huomasin samalla, että en ole kirjoittanut asiakastuen uusimisesta juurikaan suomeksi. Siksi ajattelin kirjoittaa muutaman artikkelin aiheesta. Tämä on ensimmäinen sarjassa.

WP_20141005_003

Ihmisten vaatimustaso kasvaa ja toimintamallit muuttuvat. Vanhat palvelumallit eivät aina toimi muuttuneessa ympäristössä. Toivoisin että Helsingin Silakkamarkkinat pysyisivät hengissä, mutta pahalta näyttää. Kalastajaveneiden määrä hiipuu. Ihmiset eivät enää osta talven suolasilakoita kerralla. Silakkamarkkinoiden alkuperäinen syy ja tarkoitus ovat jo kadonneet.

Service desk -toimintamalli on paljon nuorempi kuin 1700-luvulta peräisin olevat Silakkamarkkinat, mutta senkin ympäristö muuttuu. Pilvipalvelut, tabletit, älypuhelimet ovat muuttaneet vuonna 1989 kuvatun Service Desk -mallin ympäristön.

Asiakastuen toimintamalli on tai oli alkujaan häiriökeskeinen puhelinpalvelu. Käyttäjä soittaa kun jokin ei toimi. Asiakastuki sitten ratkaisee ongelman tai välittää sen edelleen. Häiriö kirjataan, luokitellaan, käsitellään ja suljetaan kun häiriö on hoidettu ja palvelu on palautettu ennalleen.

Standardointi on ollut keskeinen elementti häiriökeskeisessä toimintatavassa. Häiriöt on helppo korjata kun kaikki käyttävät standardoituja työkaluja. Kaikki laitteet löytyvät laiterekisteristä ja laitteiden viat kirjataan sinne. Asiakastuella on korjausohjeet ja varaosat tavallisimpien häiriöiden varalta. Toimintaa mitataan ja arvioidaan häiriöiden käsittelyn perusteella.

Uuden asiakastuen maailmassa ei ole standardeja, ei ole välttämättä laiterekisterejä, eikä toiminta keskity häiriöihin. Laitteet kehittyvät ja vaihtuvat liian nopeasti. Palvelut ovat pilvessä. Perustekniikka on paljon vakaampaa kuin 1990-luvulla. Asiakkaat ovat entistä taitavampia hallitsemaan omia laitteitaan ja selvittämään yksinkertaiset ongelmat. Asiakastukea tarvitaan sitten kun omat taidot eivät enää riitä. Jos asiakastuen osaaminen ei riitä, apu haetaan muualta. Sosiaalinen media ja erilaiset verkosta löytyvät lähteet tarjoavat usein ratkaisun hankaliinkin pulmiin.

Perinteisiin juuttunut asiakastuki ei välttämättä huomaa muutosta itse. Jos asiakkaat näkevät että asiakastuesta ei ole apua, he eivät ota yhteyttä. Vielä löytyy niitä asiakkaita, jotka toimivat perinteisen mallin mukaan ja asiakastuki voi huomaamattaan keskittyä palvelemaan vähemmistöä.

Uuden asiakastuen pitää keskittyä asiakkaisiin ja heidän auttamiseen. Auttaminen ei ole välttämättä sama asia kuin asiakkaan ongelman tekninen ratkaiseminen. Asiakkaalle voidaan myös tarjota uusi tapa tehdä asioita tai vaikka kokonaan uusi työkalu.

Häiriötikettien käsittelyn mittaaminen on vanhentunut tapa arvioida asiakastuen toimintaa. Hyvän ratkaisun tarjoaminen sosiaalisessa mediassa voi poistaa satoja ”häiriöitä”, mutta luotu arvo ei näy millään häiriökeskeisellä mittarilla mitattuna.

Uusi asiakastuki ei istu luurit päässä odottamassa puheluja. Sen sijaan asiakastuki on aktiivinen, opiskelee uusia ratkaisuja, esittelee vaihtoehtoja, näkyy sosiaalisessa mediassa ja keskittyy asiakkaaseen.

Tärkeä elementti uudessa asiakastuessa on erilaisten palvelukanavien avaaminen. Palveluportaali on tärkeä elementti. Sieltä asiakkaat löytävät tiedotteet, voivat tilata asioita ja olla yhteydessä asiakastukeen muutenkin kuin puhelimella. Sosiaalinen media on hyvä kanava ja siellä pitää olla aktiivisesti mukana. Kannattaa myös avata fyysinen palvelupiste, jos se vain on mahdollista, koska asiakkaat ja heidän tietotekniikkansa ovat mobiileja. Asiakkaan on helppoa tulla palvelupisteeseen näyttämään ongelma. Palvelupiste on myös hyvä paikka auttaa asiakas alkuun esimerkiksi uuden laitteen kanssa.

Tässä luettelo toimenpiteistä:

  • Siirry arvopohjaiseen mittaamiseen, lopeta aktiviteettien mittaaminen. Arvon mittaaminen on vaikeampaa, mutta aktiviteettien mittaaminen voi ohjata toimintaa väärään suuntaan.
  • Ota sosiaalinen media käyttöön.
  • Perusta palvelupiste tai -pisteitä. Etsi niille sopivat aukioloajat ja toimintatavat. Sijoita piste paikkaan, jonne asiakkaiden on helppo tulla.
  • Uusi kirjausjärjestelmä sellaiseksi, että pystyt helposti erottelemaan erilaiset asiat. Varo itilin kangistamia järjestelmätoimittajia.
  • Kuuntele asiakkaita ja kysy heidän toiveitaan. Ole aktiivinen ja mieti ennakkoluulottomasti miten tietotekniikka voisi auttaa heitä heidän työssään.

Tämä on ensimmäinen osa artikkelisarjasta, joka käsittelee asiakastuen uudistamista. Kommentit ovat tervetulleita.

 

Työkalututkimus 2014

Työkalututkimus on tehty vuosina 2007, 2010 ja 2012 -2014. Vastauksia tuli tällä kertaa vähemmän kuin viime vuonna ja huomasin, että vastaajat vaihtuivat vuodesta toiseen. Viime vuonna vastaajia oli n. 100 ja vain 9 henkeä näistä vastasi tänä vuonna. Tein sen johtopäätöksen, että vastaajat eivät ole kiinnostuneita vastaamaan, jos tilanne ei ole muuttunut. Todennäköisesti vastaaminen kiinnostaa eniten niitä, joille asia on ajankohtainen esim. uuden työkalun käyttöönoton takia.

Menetelmä on pysynyt ennallaan, kysely tehtiin sähköpostilla ja siinä kysyttiin työkalun nimeä, kouluarvosanaa soveltuvuudesta ja työkalun käyttötarkoitusta.

Päätin yhdistää kolmen viimeisen vuoden aineistot, koska on ilmeistä, ettei ohjelmistoja vaihdeta kovin usein. Poistin päällekkäiset vastaukset ja kokosin yhteensä 183 vastausta, joista 42 on vuodelta 2014, 95 vuodelta 2013 ja 46 vuodelta 2012. Nämä sisältävät yhteensä 207 työkaluarviota.

Slide1

ServiceNow, Efecte ja BMC ovat selvästi omilla lukemillaan. Ryhmä muut sisältää yksittäisiä työkaluja, usein eritystarkoituksiin.

Slide2

Käyttäjät eivät ole kovin tyytyväisiä työkaluihinsa, arvosanat vaihtelevat 7½:n ympärillä. Poikkeuksena ovat HD Service Manager huonoilla arvosanoilla ja ryhmä ”muut” hyvillä arvosanoilla.

 

Luokittelin sovellusten käytön viiteen ryhmään:

SD                   pelkkä service desk

SD+                lisäksi esim. CMDB, muutoksenhallinta ja/tai ongelmanhallinta

ITSM             Service desk ja esim. palvelutasonhallinta

hallinta        ei service desk mutta esimerkiksi muutoshallinta, sovellushallinta yms.

etähallinta  työasemien etähallinta

Slide3

Kuten näkyy, työkaluja käytetään pääasiallisesti service deskin toimintaan. Vain 16 % vastaajista kattaa laajemman it-palveluhallinnan alueen ja tässä on rima ollut varsin alhaalla. Tilanne ei näytä juurikaan muuttuvan.

 

Slide4

Käyttökohde vaikuttaa tyytyväisyyteen, mutta silti vain etähallintaan ollaan tyytyväisiä.

Slide5

Tässä graafissa ovat mukana kaikki tehdyt tutkimukset ja luvut ovat sen vuoden vastauksia. Se heijastaa markkinaosuuksien kehitystä, toki sillä varauksella että uudet työkalut voivat ylikorostua. ServiceNow näyttää olevan edelleen hyvässä kasvussa, mutta kotimaiset Efecte ja Requeste näyttävät pitävän osuutensa ennallaan.

 

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.

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

Seuraa

Get every new post delivered to your Inbox.

Liity 72 muun seuraajan joukkoon

%d bloggers like this: