Palvelujen määrittely

Keskustelu palveluluetteloista jatkuu vilkkaana taas kerran. Hyvän palveluluettelon laatiminen on vaikeaa. Tavallisesti tuloksena on tekninen luettelo asioista, joita it-yksikkö tekee muotoiltuna palveluiksi. Osa palveluista on taas hyvin epämääräisiä.

Alan kallistua sille kannalle, että kattava palveluluettelo on utopiaa. Sen tekemiseen ja ylläpitoon ei kannata uhrata liikaa aikaa. On toki hyvä asia luetella it-yksikön tekemät asiat ja asettaa niille tavoitteita toiminnan laadun suhteen, mutta sellainen luettelo on it:n sisäinen työkalu, harva asiakas on siitä kiinnostunut. Se mitä kannattaa tehdä, on keskustella säännöllisesti asiakkaiden kanssa  ja selvittää mitä asiakkaat haluavat it:ltä. Asiakkaan kannalta voi olla tärkeintä, että hänen laitteensa ja sovelluksensa toimivat niin, ettei siitä aiheudu häiriöitä liiketoiminnalle. Lisäksi asiaks varmaan haluaa, että hänen tilaamansa muutokset palveluun tehdään nopeasti ja virheettömästi.

Tämä on aika yksinkertainen palvelu ja aivan liian epämääräinen ohjauksen kannalta, sillä yhden asiakkaan ”it-palvelun” taustalla on lukuisia järjestelmiä, joista jokainen yksinään voi estää palvelun toiminnan. Tätä voi verrata vaikka auton käynnistämiseen. Jotta autoni käynnistyy, kolmen asian pitää tapahtua samanaikaisesti. Käynnistysmoottorin pitää pyöriä, sylinteriin pitää tulla oikeanlaista polttoaineseosta ja sen pitää syttyä. Näiden tapahtumien taustallla on joukko järjestelmiä, joiden pitää toimia. Minua ei kiinnosta kuinka monta kipinää sytytysjärjestelmä kestää, kuinka monta tuntia käynnistysmoottori toimii jne. Minä vain haluan että auto käynnistyy. Toisin sanoen, auton valmistajan ja käyttäjän näkökulma on erilainen.

Miksi palvelun määrittely sitten on yhtä aikaa yksinkertaista ja vaikeaa. Yksi selitys voi olla koko palvelu-käsitteen epämääräisyys. ITIL määrittelee palvelun näin: Keino tuottaa arvoa asiakkaalle auttamalla asiakasta saavuttamaan tuloksia ilman, että asiakas investoi tiettyjä kustannuksia ja riskejä. Määritelmä on huono koska se korostaa kustannusten ja riskien siirtoa. Se sopii hyvin esim. vuokraamiseen mutta huonosti vaikkapa sisäisen service deskin tarjoamiin palveluihin. Määritelmän kirjoitti aikoinaan  Majid Iqbal eikä hänkään käytä sitä enää. Muutenkaan Service Strategy -kirjan kirjoittaja ei pidä ITILiä kovin korkeassa arvossa, tässä hänen twiittinsä viikko siten:

Majid IqbalMajid Iqbal‏@mxiqbal

This whole “simple enough for this and that” is a red herring; what made#ITIL and #ITSM simplistic and frankly idiotic! 🙂

Palvelun sijaan pitäisi ehkä puhua palvelukomponenteista ja niille asetettavista vaatimuksista. Silloin palvelukomponenttiluettelo on it:n sisäinen dokumentti ja sitä käytetään palvelun ohjaukseen.

Asiakkaiden kanssa sovitaan yhdessä mitä ja miten tehdään asioita ja lähtökohtana ei välttämättä tarvitse olla it-palvelu. Otetaan esimerkki: Laskutus on tärkeä, toistuva prosessi, joka ei onnistu ilman it-toimintoja. Sen sijaan, että määritellään it-palvelut ja niiden SLA, sovitaan yhdessä laskutuksen toimivuudesta. Mittarina on esimerkiksi laskutuksen oikea-aikaisuus ja laskun hinta. Kaikilla osapuolilla on omat velvollisuutensa, mutta tavoitteet ovat yhteisiä.

Asiakastuki on entistä tärkeämpää

Tämä 20 min video on mielestäni hyvä. Siinä Richard White kertoo miksi he järjestivät UserConf -tilaisuuden. Hän etsi konferenssia, jossa puhuttaisiin modernista asiakastuesta. Hän kertoi löytäneensä kahden tyyppisiä tilaisuuksia:

1) ITSM konferensseja, joissa ihmisillä on pakkomielle ITIListä, mutta joiden käsitys asiakastuesta on outo. (No hän ei ollut Kalastajatorpalla, mutta kuvaus sopii hyvin itSMF UK:n konferenssiin.)

2) Call center tilaisuuksia, joissa soitetaan vanhaa ”Puhelusi on tärkeä meille” -levyä.

Molemmat tilaisuudet kuvaavat menneisyyttä. Uusi asiakastuki on erilaista, siinä

  • henkilökunta on erittäin osaavaa
  • tuki toimii kaikilla medioilla
  • tuotteen viat ratkaistaan tunneissa, ei kuukausissa
  • jokainen asiakaskohtaaminen on mahdollisuus

Asiakastuen sijasta pitää puhua asiakaista huolehtimisesta (customer care). Poikkeuksellinen asiakaspalvelu ei ole mitään uutta,  mutta aikaisemmin se on liitetty ylellisyystuotteisiin. Nyt maailma on muuttunut, internet on luonut itsepalveluun perustuvan liiketoimintamallin. Yksinkertaiset asiat hoidetaan itsepalvelulla ja asiakaspalvelua tarvitaan vain vaikeimissa tapauksissa.

Perinteinen myyntimalli korosti kaupan merkitystä, mutta nykyään yhä useammin myydään jatkuvaa palvelua, jossa asiakkaiden pysyvyys ratkaisee. Tässä ei ole mitään uutta mutta kaikki eivät ole vielä tajunneet asiakastuen merkitystä myynnille. Jokainen asiakaskontakti on potentiaalinen myyntitilanne. Siksi joissakin tapauksissa myynti on asiakastuen kakkostaso!

Usein korostetaan että huono asiakaspalvelu on yleisin syy asiakkaan menettämiseen, mutta tuoteen laatu on toiseksi tärkein syy. Asiakastuen pitää olla osa tuotetta.

Muistoja menneisyydestä

Olin maanantain ja tiistain itSMF UK:n 21. konferenssissa. Oli todella upeata nähdä miten hienosti sosiaalinen media toimii. Sosiaalisen median kautta tutustuu erittäin helposti ihmisiin ja kun on keskustellut verkossa, on luonteva jatkaa keskustelua livenä.

Konferenssissa oli muutama erinomainen esitys, joista vaikuttavin oli Simon Wardleyn keynote. Hän kuvasi hienosti luovan tuhon kierrettä. Luova tuho hävittää vanhan ja tilalle tulee jotain uutta ja parempaa. Muutos ei ole pehmeä ja mukava asianomaisille, vaan tuho on todellista tuhoa, sotaa. Sitä edeltää mukava tasaisen elämän vaihe, jolloin kasvu on tasaista ja elämä näyttää varmalta sekä turvalliselta. Näin suomalaisittain Nokia on loistava esimerkki.

Tuhon käynnistää yleensä jokin teknologinen oivallus, joka mahdollistaa uuden tavan toimia. On helppo havaita että printtimedia eli lehdet ovat juuri tässä vaiheessa. Sama koskee myös meitä jotka painimme IT-palvelunhallinnan parissa. Maailma muuttuu vaikka kuinka pyristelisimme vastaan.

Tätä avausta vasten oli piinallista nähdä, miten konferenssissa jauhettiin iänikuisia vanhoja asioita. Valtaosa esityksistä oli ITIL prosesseista, pelkästään incident-problem  -pulmaa käsiteltiin useassa esityksessä. (Incident-problem -pulma ratkeaa heti, kun päätät unohtaa ITILin opetukset). Tuntui kuin ajattelu oli jäänyt junnaamaan menneisyyteen. Tunnelmaa vahvisti se, kuinka esitysten välissä näytettiin videota konkareiden muisteluista.

***

Pidin itse Unlearning ITIL -esityksen ja vastaanotto oli mahtava. Kaikki ITIL ”heavyweights” tulivat etuosaan, joten painetta riitti. Esitys oli pitkälti sama, jonka pidin Suomen itSMF-konferensissa vuosi sitten, ja ne jotka olivat kuuntelemassa muistanevat, että pöllytin ITILiä aika lailla. Se oli helpompaa, kun salissa ei istunut ITILin kirjoittajia 😉

Esitys sai aikaan vipinää Twitterissä ja kannatusta löytyi.  Minut pyydettiin saman tien pitämään esitys Viron itSMF-konferenssissa ja lisäksi tiedusteltiin, voisinko lähteä myös Australiaan pitämään saman esityksen.

***

Konferenssin aikana puhuin riskienhallinnan liian pienestä osuudesta it-palvelunhallinnassa. Asiantuntijat olivat samaa mieltä. Riskienhallinta on tärkeää ja se on jäänyt liian vähälle huomiolle. Tähän mennessä 28.11. pidettävään Riskienhallinnan työpajaan on myös ilmoittautunut liian vähän osallistujia ja todellakin haluaisin pitää sen. Työpaja ei tarkoita pelkästään että tulet opiskelemaan jotain vaan työpaja luo uutta ymmärrystä. Korjaa tilanne ja ilmoittaudu nyt.

Riskienhallinta

Tutustuin riskienhallintaan lähemmin kun yritin selvittää itselleni, miksi ITILin ongelmanhallinta tuntui olevan niin vaikeaa käytännössä. Yksi suunnannäyttäjä oli Jan van Bon, joka kehotti korvaamaan ongelmanhallinnan riskienhallinnalla. Innostuin toimimaan, kun tutustuin riskienhallinnan standardiin. ISO 31000 on tuoreeltaan käännetty suomeksi ja siksi päätin tarjota aiheesta kurssin, jossa kytkisin standardin it-palvelunhallintaan. Kurssimarkkinoin yhteydessä minulle valkeni, että en tiedä miten pitkällä tällä alueella ollaan Suomessa. Siksi päätin tehdä kyselyn aiheesta ja sen tulokset osoittautuivat yllätykseksi.

Oletin, että a) aihe ei olisi kovin kiinnostava, ja b) riskienhallinta olisi harvinaista kohderyhmässäni. Olin väärässä.

Tässä ensin kysely:

Huomasin juuri, että en tiedä miten organisaatiot Suomessa hoitavat riskienhallintaa ja siksi päätin kysyä siitä. Tämä on hyvin yksinkertainen kysely, jossa on vain kaksi kysymystä. Kysymys koskee sitä, miten sinä osallistut riskienhallintaan.
 
Riskienhallinnalla tarkoitan toimintaa, jossa riskejä dokumentoidusti tunnistetaan, analysoidaan, arvioidaan ja pyritään torjumaan. Dokumentoinnin muodolla ei ole tässä väliä, mutta on välttämätöntä, että eri toimenpiteet dokumentoidaan jotta voidaan puhua riskienhallinnasta.
 
Vastaa suoraan tähän sähköpostiin. Voit toki tarkentaa vastaustasi vapaamuotoisesti. Vastaukset ovat luottamuksellisia.
 
Kirjoita vastausvaihtoehtosi numeron perään
1: 
2:
 
1) Mikä on oma roolisi riskienhallinnassa?
 
a) en osallistu siihen mitenkään
b) keskustelemme näistä asioista
c) osallistun riskienhallintaan
d) vastaan joltakin osin riskienhallinnasta
 
2) Jos osallistut riskienhallintaan, liittyykö se
 
a) projekteihin
b) jatkuvaan palveluun
c) molempiin
 

Tulokset

Ensinnäkin arvioin aiheen kiinnostavuuden väärin. Olen saanut alle 24 tunnissa jo 73 vastausta, mikä on ok tulos.

Toiseksi, arvioin riskienhallinnan yleisyyden väärin. Vain 7 % ei osallistu siihen ja 77 % sanoo osallistuvansa dokumentoituun riskienhallintaan. Kysymys ei ollut ehkä muotoilultaan paras mahdollinen, mutta se oli toki vahvempi kuin esim. ITIL kyselyissä käytetty: Onko teillä käytössä prosessi X?

Kolmanneksi, oletin että riskienhallinta liittyisi yleensä projekteihin. Taas väärin, vain 10 vastaajista kytki riskienhallinnan vain projekteihin. Siinä ei toki ole mitään väärää jos oma työ on pääosin projekteja.

Yllättävät tulokset saivat minut epäilemään että vastaajiin olisi valikoitunut normaalista poikkeavia henkilöitä, mutta en saanut sille minkäänlaista vahvistusta. Vastaajista n. 15% oli uusia vastaajia eli suuri enemmistö on vastannut aikaisempiin kyselyihin. Joka kyselyssä tulee aina jonkin verran ensikertalaisia.

Kuten näkyy, myös Service Deskeissä työskentelevät osallistuvat riskienhallintaan mutta toki harvemmin vastaavat siitä.

Palveluyrityksissä ollaan vähän aktiisempia riskienhallinnan kanssa, mutta erot ovat aika pieniä.

Service Desk  henkilöstö osallistuu muita useammin vain jatkuvien palvelujen riskienhallintaan, mutta yli 50% osallistuu myös projektien riskienhallintaan.

Tulos on siis erinomainen riskienhallinnan näkökulmasta tai sitten kysymykseni olivat huonosti muotoiltuja. On mahdollista, että monien vastaajien kosketus riskienhallintaan on silti aika etäinen. Vapaamuotoisia vastauksia tuli vähän, tässä ne kaikki:

Ensimmäinen kommentti heijastelee omia odotuksiani:

  • Luulen että riskienhallinta ei ole kovin yleistä edes yritykselle tärkeiden prosessien osalta, niihin mennään kuten miinakentälle eli ihmetellään kun oman jalan alla räjähtää. Esim. henkilöriskit ovat mielettömiä, liian paljon osaamista ja prosessin kannalta elintärkeää pintaa saattaa olla yhden ihmisen jaksamisen varassa eikä mihinkään äkilliseen sen kummemmin varauduta vaan luotetaan onneen ja tilanteen pysymiseen ennallaan.

Seuraavat kommentit antavat kuvan aika keskitetystä ylätason suunnittelusta.

  • Yhtiössä aina silloin tällöin liiketoimintojen osalta kartoitetaan riskejä ja mahdollisia suojaustoimenpiteitä. Olen itse ollut joissakin hankkeissa mukana arvioimassa IT järjestelmiin liittyviä liiketoimintariskejä. Luultavasti kartoitusten teko on jollain muotoa systematisoitu. Projekteissa riskikartoitus on osa projektitemplatea.
  • valmistelen riskienhallintaraportointia turvallisuusjohtajalle yrityksen hallitukselle liiketoimintariskien raportointia varten
  • Tietohallinnon osalta osallistun organisaation riskienhallintaan sekä it-hankkeiden ohjausryhmässä projektien riskienhallintaan.
  • IT-päällikkömme tiedottaa tarvittavista ohjeistuksista/toimenpiteistä ja niiden mukaan toimitaan

Siis tulos oli yllättävä ja hyvä mutta ehkä vähän optimistinen.

%d bloggers like this: