Service Desk -mallin toimivuus

1 Tutkimus

Silmiin osui väite, että itil on tappanut palveluinnovaatiot tarjoamalla pohjimmiltaan 30 vuotta vanhaa malliaan parhaana käytäntönä. Itilin yhden pisteen SPOC-malli on toki toiminut hyvin ja on varmasti paraskin joissakin tilanteissa, mutta onko todella niin, ettei ole parempia malleja. Näyttää siltä että monet soveltajat ovat kehittäneet uusia, innovatiivisia ratkaisuja, jotka poikkeavat itilin suosituksista. Olen kokeillut esimerkiksi Elisan OmaGuru-palvelua, jonka avulla pääsee ohittamaan ykköstason maksua vastaan.

Pikakyselyn tarkoituksena oli selvittää näkemyksiä aiheesta. Tällä kertaa kysymykset olivat helppoja, vastaajat saivat valita annetuista vaihtoehdoista ja sai jopa valita useita vaihtoehtoja. Vastauksia tulikin paljon, eikä tällä kertaa tarvinnut tehdä uusintakyselyä.

Kohdejoukkona olivat keräämäni kontaktirekisteri. Kysymys oli seuraava:

Help/Service Desk tukipalvelu oli aikoinaan uusi ajatus. Keskitetty palvelupiste, joka ratkoo asiakkaiden ongelmat ja ottaa vastaan palvelutilauksia. Malli on kohta 30 vuotta vanha ja on esitetty väitteitä, että se on vanhentunut. Tässä kolme kysymystä tukipalvelusta.

1 Miten hyvin Help/Service Desk -malli toimii mielestäsi?

a) malli toimii erittäin huonosti

b) malli toimii melko huonosti

c) malli toimii kohtalaisesti

d) malli toimii melko hyvin

e) malli toimii erittäin hyvin

2 Mihin suuntaan tukipalvelua pitäisi kehittää (voit valita useita vaihtoehtoja)

a) toimimaan enemmän Service Desk -mallin mukaisesti

b) asiakkaille pitäisi tarjota yksilöllisempää palvelua

c) tukea pitäisi keskittää enemmän yhteen pisteeseen

d) tuen osaamistasoa pitäisi kohentaa

e) tuen kustannuksia pitäisi leikata

f) tukea pitäisi automatisoida

g) tuki pitäisi ulkoistaa

h)ulkoistettu tuki pitäisi tuoda takaisin

i) jotenkin muuten, miten?

3) Mikä on oma roolisi HD/SD:n suhteen

a) olen asiasta päättävä henkilö

b) olen sen esimies, tiiminvetäjä tai kehittäjä

c) työskentelen siinä

d) en työskentele siinä, mutta ratkon joskus HD/SD:n välittämiä tikettejä

e) en ole tekemisissä tuen kanssa muuten, kuin sen asiakkaana

2 Vastaukset

Vastauksia tuli 75 kpl.

Vastaajien roolit olivat seuraavat: (klikkaamalla kuvaa saat siitä isomman)

Eniten vastauksia tuli deskien esimiehiltä ja seuraavaksi ylemmiltä johtajilta. Tämä on normaali jakauma kyselyissäni ja johtunee omista taustoistani. Tunnen paljon SD väkeä. Varsinaisten työntekijöiden osuus on pieni, se selittynee suurella vaihtuvuudella.

SD malli toimii melko hyvin. Karkeasti arvioituna kolme neljäsosaa on tyytyväisiä ja neljännes hiukan kriittisiä. Roolilla ei ole kovin suurta vaikutusta näkemyksiin. SD johto on tyytyväisintä, mutta ylempi johto on vähän kriittisempää. Ero lienee täysin luonnollinen.

Kehittämiskohteissa löytyi sitten eroja. Erot ovat aika suuria. Osaamistahon kohentaminen on ainoa joka ylitti 50% rajan eli joka toinen valitsi sen. Automatisointi ja yksilöllisyyden lisääminen olivat 40% tasolla.

Vastaajat saivat valita useita vaihtoehtoja. Alla oleva kuvaa mitä muita valintoja vastaajat tekivät. Esimerkiksi reilu 60% niistä, joiden mielestä tukea pitäisi automatisoida, haluaisi myös kohentaa tuen osaamistasoa. Yksilöllistä palvelua kaivattiin eniten niiden kesken, jotka haluisivat lisätä automatisointia. Yksilöllisyyttä haluavat vähiten ne, jotka haluavat keskittää ja toimia Service Desk mallin mukaisesti. (Pienet tolpannysät ovat yksi-yhteen vaihtoehtojen kohdalla, esim ylin on f-f. Oikeastaan siinä ei pitäisi olla mitään, mutta huomasin pienen nysän helpottavan kuvan lukemista)

Huomasin että keskittäminen tai yksilöllisyys jakoi vastaukset melko täydellisesti kahteen ryhmään.

Vain 5% halusi molempia ja 10% ei kumpaakaan. Tässä asiassa palveluyritykset ja sisäinen it poikkeavat toisistaan selvästi. Yksilöllinen SD on sisäisen it:n toive.

On mielenkiintoista havaita että keskitettyä SD:tä haluavat ovat tyytymättömämpiä malliin kuin muut. Tämä on hiukan ristiriitainen havainto. Olisi voinut kuvitella että yksilöllisyyttä kaipaavat olisivat olleet kriittisempiä.

3 Kommentit

Vapaita kommentteja tuli aika paljon. Tunnen useimmat kommentoijat ja tiedän että kritiikin takana on asiantuntemusta ja kokemusta.

1-tason tuki pitäisi voida ohittaa silloin kun se ei tuota lisäarvoa loppukäyttäjälle
hajauttaa tukea enemmän asiakkaiden luokse. ns. onsite palvelu. Ongelmat ratkeavat niin nopeammin.
hieman ristiriitaiset vastaukset, eli mielestäni sekä tehostusta automatisoinnin ja itsepalvelun kautta silloin kun mahdollista ja tarpeen, mutta tulee myös tarjota mahdollisuus yksilöllisemmälle palvelulle silloin kun asiakas sitä tarvitsee. Isoille asiakkaille nimetty/nimetyt palveluneuvojat –> asiakaskohtaisuus
Ja sitten ihan kommenttina, ulkoistaminen ei ole mikään ratkaisu, se on kuin aspiriinia syöpään. Ensin homma kuntoon, sitten voidaan katsoa kuka tai mikä on se taho, joka työn tekee.
liika automatisointi johtaa siihen, että statuskyselystä generoituu uusi tiketti, ja luuppi on valmis
Noin yleensäkin minä en usko keskitetyn helpparin kaikkivoipaisuuteen – se on aivan mahdoton asia ja turhaan mainostettu, että SD ratkoo niin ja niin paljon ongelmia, ei varsinkaan ulkoistettu keskitetty SD. Osaaminen ei kerta kaikkiaan riitä monissa tapauksissa kuin löytämään suurin piirtein oikea resolver. Esim. lähellä businesta oleva asia, ei siinä voi auttaa kuin oma, omista puoliksi business-ihmisistä koostuva SD. En siis ole keskitettyä helpparia vastaan, kyllä se pitää olla, mutta tyypillinen ylenmääräinen kehuminen että hoitaa niin ja niin paljon asioita on puuta heinää, pystyy yleensä vain std-Office  –pulmia ratkomaan. Ja sen tukena pitää olla osittain oma ”biz-helppari”.
Service Desk pitää edelleen organisoida pienempiin osiin
tehokkaammin hyödyntää etäyhteyksiä, jolloin voidaan palvelulla laajempaa asiakaskuntaa
Toki kustannukset täytyy pitää kurissa, mutta se ei ole päätavoite. Keskittämistä ja yksilöllistä palvelua ei pidäkään nähdä toistensa vastakohtina.
tukipalvelun resurssit pitää mitoittaa asiakasmäärän suhteen. Vähintään tukihenkilö / 100 asiakasta?
Täydellinenhän spoc sdmalli ei ole, vaan poloiset sdkaverit joutuu vastaamaan kysymyksiin sataan eri sovellukseen liittyen.
vaikea vastata koska helpdesk/servicedesk eroa ei ole määritelty – käytännössä oma mielipiteeni on että help/servicedesk on firman asiakasrajapinnan hermokimppu, paikka jossa pitää osata kaikkea mitä firma tekee ja palvella asiakasta alusta loppuun, oli kyse puutteesta, valituksesta, lisätarpeesta, muutoksesta tai palautteesta. firman haastavin positio jossa maksetaan vähiten palkkaa.
Helpdesk malli jossa oli useita yhden asian helppareita, oli loppukäyttäjälle tosi hyvä.  Näitä minullakin on ollut.  Eli yksi helppari hoiti esim. yhtä sovellusta. 80/20 sääntö piti ja loppukäyttäjät saivat hyvää palvelua jne.. Toki oli ongelmiakin esim. helppari henkilöiden väsyminen samoihin ja toistuviin tukipyyntöihin. 

Nykyinen SPOC malli joka parhaimmillaan ja pahimmillaan tuo esim. ulkoistettuun Service Deskiin kaikki mahdolliset tukipyynnöt ja tilaukset. Tällaisissa tapauksissa SD:n oma ratkaisuprosentti saattaa jäädä jopa alle 30 % (ei hyvä kenellekään).  Tämä johtuu siitä että tulee niin paljon eskalointeja eteenpäin (erikoissovellukset, tilaukset,  tietoliikenne, palvelin jne.).   Jos seuraamme kahta SD:n ratkaisuprosenttia saamme hyvin erilaisia tuloksia

SD :n ratkaisemat kaikista tukipyynnäistä. Saattaa olla alle 30 %

SD:n ratkaisemat sen vastuulla olevista tukipyynnöistä. Saattaa olla yli 90 %

Luulen että SPOC kehittyy siihen suuntaan että hyvät ominaisuudet jäävät

  • Helppo tavoitettavuus eli SPOC
  • Kaikki tukipyynnöt ja tilaukset tulee kirjattua ja raportoitua
  • Yhteiset prosessit
  • Yhteiset työkalut (tikettijärjestelmä ja puhelinjärjestelmä)
  • Jne.

Huonoihin ominaisuuksiin kehitetään ja löydetään ratkaisuja. Loppukäyttäjä ei koe hyvää palvelua jos tiketti vain kirjataan ja eskaloidaan eteenpäin. SD henkilölle työ raskasta kun ei osaa auttaa kuin osassa tukipyyntöjä

Näitä asioita ratkotaan ja uskon että teknologia ja uudet toimintatavat ratkaisevat nämä asiat ja Service Desk maine paranee entisestään. Tässä joitakin ajatuksiani:

  • Puheluiden ohjaus oikealle henkilölle mahdollisesti ohi SD:n kehittyy
  • ”asiantuntijoiden” työhön tulee SD työn piirteitä
  • Loppukäyttäjät tekevät entistä  suuremman osan tukipyynnöistä web-lomakkeiden kautta ja nämä tukipyynnöt ohjataan tarvittaessa ohi varsinaisen SD:n
  • Itsepalvelu varsinkin tilauksissa ja salasanan lukitus -tyyppisissä asioissa

4 Johtopäätökset

Help desk oli tosiaan aikoinaan uusi ja vallankumouksellinenkin ajatus. Olen ollut perustamassa useita kymmeniä helppareita ja malli on toiminut aina. Itil ei tuonnut service deskillään uutta sisältöä malliin vaikka itil-kirjoissa help desk kuvataan vain teknisenä tukena ja service deskin sanotaan olevan enemmän. Help Desk Instituten oppien mukaan help deskillä oli kyllä jo kaikki service deskin piirteet.

Kyselyn mukaan yhden pisteen SD malli toimii edelleen, mutta se ei ole täydellinen. Mallin suurin pulma on sama, joka siinä havaittiin jo toistakymmentä vuotta sitten: arvostuksen puute. En usko että tilanne tulee muuttumaan. It-johto pitää tukipalvelua kalliina ja tuottamattomana palveluna. Tuen osaamistason kohottaminen, on ykköstoive, mutta pelkään että se jää haaveeksi sillä osaajat hakeutuvat paremmalle palkalle. Tätä asiaa on jauhettu jo niin monta vuotta että en jaksa uskoa sen muuttuvan.

Tuen automaatio varmasti kehittyy. Olin eilen kuuntelemassa esityksiä aiheesta Atean Focus -tapahtumassa ja siellä esiteltiin varsin edistyneitä malleja palvelupyyntöjen käsittelyn automatisointiin. Sen sijaan en usko että kaikesta henkilökohtaisesta tukipalvelusta päästään kovinkaan pian eroon.

Osa soveltajista on vielä kehityksen alkuvaiheissa ja pyrkii saamaan tukensa toimimaan yhden pisteen mallin mukaisesti. Heille on tärkeää saada tukipalvelupyynnöt pois asiantuntijoilta. Osa soveltajista taas kaipaa lisää yksilöllisyyttä palveluun. Uskon että tässä on kyse kehitysvaiheista, joiden kautta pitää kulkea. Vaiheet ovat:

1.       Jokainen hoitaa oman tonttinsa. Ei keskitettyä tukea vaan käyttäjien pitää etsiä oikea asiantuntija. Tuki on periaatteessa laadukasta, mutta asiantuntijan tavoittaminen työlästä. Väki tekee paljon tilastoimatonta työtä, josta ei voi laskuttaa.

2.       Paljon helppareita. Tavoitettavuutta parannetaan perustamalla eri osa-alueille omia tukipalveluja. Tuki on laadukasta mutta kallista. Pienen helpparin toiminta ei ole tehokasta ja asiat voivat jäädä väliin. Toiminnan kehittäminen on työlästä, koska tukiryhmät ovat toisistaan riippumattomia eivätkä käytä yhteisiä välineitä.

3.       Yksi keskitetty palvelupiste. Tavoitettavuus ja tehokkuus yhdistyvät, mutta tuen laatu heikkenee, koska osaaminen vähenee. Tuesta tulee pyyntöjen välittäjä, eivätkä asiakkaat saa ratkaisuja yhtä nopeasti kuin aiemmin. Toisaalta tuelle voidaan hankkia parempia apuvälineitä ja toimintaa voidaan kehittää, mikä kompensoi mallin ongelmia.

4.       Siirrytään yksilölliseen ja tarkemmin ohjautuvaan tukeen, jossa ykköstaso automatisoidaan ja tukipyynnöt ohjataan suoraan asiantuntijalle. Palveluista tehdään helppokäyttöisiä ja niihin rakennetaan tuki sisään. Palvelulla on oma tukisivusto, josta löytää uusimmat neuvot eri tilanteisiin.

Olen siis samaa mieltä kehityksestä viimeisen, pitkän kommentin kirjoittajan kanssa. Kommentoija on asiakaspalvelujohtaja it-palveluyrityksestä ja tuntee aiheen hyvin. Parhaita käytäntöjä tuen kehittämiseen ei löydy ainakaan itil-kirjoista, itilin ohjeet soveltuvat niille, jotka ovat vasta käynnistämässä Service Desk -toimintaansa ja se vaihe toki pitää kulkea ennen kuin voi siirtyä seuraavalle tasolle. Itilistä on paljon hyötyä vaiheessa 1-2 ja hiukan hyötyä vaiheessa 2-3 mutta siihen se sitten jää.

5 Tutkimuksesta

Tein tämän tutkimuksen kolmen kysymyksen tekniikalla. Kuten huomaat, kolmen kysymyksen tutkimuksesta saa aika paljon pureskeltavaa. Menetelmä toimii varsin hyvin. Tässä yksi soveltajakommentti:

..Se toimi älyttömän hyvin, me laitettiin toi 60 aktiivisimman ryhmän kaikille käyttäjille (n. 400) ja saatiin yli 60 vastausta.

Suosittelen lämpimästi vanhojen asiakastyytyväisyyskyselyjen arviointia. Turhasta monimutkaisuudesta ei ole kuin haittaa. Linkki menetelmän kuvaukseen (englanniksi) on linkkiluettelossa.

Kommentit ja palaute ovat tervetulleita ja klikkaa vaikka tykkäämistä tuossa alla, siis jos tämä oli mielestäsi kiinnostava. (Facebookin tykkää-nappi näkyy ilmeisesti vain, jos olet avannut artikkelin. Kokeilin itse tykätä tästä artikkelista ja se toimi, mutta en näe missään viittausta että se olin minä. Se kuitenkin vaatii Facebook-tilin. WordPress-rekisteröityneet saavat toisenkin tykkää napin, kokeilin sitäkin mutta oletan että tosi harvalla on WordPress-tili)

iPad

Kävin poikani kanssa Englannissa katsomassa Aston Villa – Chelsea ottelun Birminghamissa. Täysi Villa Park oli hieno kokemus, kotikatsomon laulut vaikuttivat.

Birminghamin Bullringistä löytyi Applestore, josta mukaan tarttui toinen hieno kokemus. iPad on vakuuttava laite. Kolmen päivän käyttökokemuksella ei pitäisi kehua liikaa, mutta keittiönpöydällä lojuva, välittömästi käynnistyvä pankki, kartta, Twitter, facebook, sähköposti, elokuvaopas, tv-ohjelma (emme katso ohjelmia enää lehdestä vaan Elisa-viihteestä, siitä kun voi samalla päättää tallentaa ohjelman sormen näpäyksellä) jne. on yksinkertaisesti nerokas keksintö. Vaimolleni Quintin jäämistöstä ostamani uudehko Lifebook on hylätty ja valitus on katkennut leikaten. Enää ei tarvitse yhtenään kiivetä yläkertaan setvimään uutta pc-ongelmaa.

Mikromaksut näyttävät myös toimivan hyvin. En ole vielä ostanut kovin montaa appsia (sovellusta), mutta kynnys on ylitetty. Ostaminen on helppoa ja vaivatonta, sovelluskaupan selaaminen on näppärää ja huoletonta verrattuna pc-maailmaan. Uskon että iPad-tyyppinen käyttöliittymä tulee yleistymään Windowsin tavoin. Nettisivujen suunnittelijoille se asettaa uusia vaatimuksia. Tiuhassa olevat pienet klikattavat kohteet ovat hankalia, joten ne kannattaa korvata jollain muulla ratkaisulla.

Ongelmanhallinta

Mitä oikein ongelmanhallinta tarkoittaa ja miksi se on vaikeaa? Itil määrittelee ongelman yhden tai useamman insidentin tuntemattomaksi aiheuttajaksi. Määritelmä on hankala, eikä vastaa normaalia tulkintaa. Lisäksi yhden aiheuttajan etsiminen on harhaanjohtavaa ja johtaa suppeaan ajattelumalliin. On tavallista että ongelmilla on useita aiheuttajia. Luontevampi määritelmä on: Ongelma on epätyydyttävä tila, jonka muuttaminen ei ole helppoa. Siis ongelma on kokonaisuus eikä vain sen tuntematon aiheuttaja.

Ongelmiahan on kaikkialla ja niitä on opittu ratkomaan paljon ennen kun ensimmäiset tietokoneet olivat keksitty. Lisäksi ongelmien merkitys esimerkiksi terveydenhuollossa on paljon suurempi kuin tietotekniikassa. Vastaavasti prosessiteollisuudella on paljon enemmän resursseja käytettävissään, kun se haluaa estää tuotannon keskeyttävien ongelmien esiintymisen. Siksi ongelmanhallinta pitää opiskella muualta.

Ensimmäinen havainto on, että koko termiä ei juuri käytetä Itilin ulkopuolella. Ongelmanhallintaprosessien sijaan muilla aloilla puhutaan ongelman ratkaisuprosessista. Toinen asiaan liittyvä yleinen toiminto on riskienhallinta. Itilin ongelmanhallinta näyttää siis sisältävän elementtejä ongelmanratkaisusta ja riskienhallinnasta.

Itilin kakkosversiossa erotettiin toisistaan ongelman ratkaisu (ongelmakontrolli) ja riskienhallinta (virhekontrolli). Kolmosversio hävitti tämän eron. Kakkosessa määriteltiin myös proaktiivinen ongelmahallinta, joka taas unohtui kolmosversiossa.

Ongelmien ratkominen on pitkälti it:n sisäistä puuhaa ja usein varsin teknistä. Riskienhallinta on taas ylemmän johdon ja/tai asiakkaiden tehtävä. It-yksikön ja erityisesti tuotannon tehtävä on tunnistaa riskejä ja pyrkiä estämään niitä, mutta riskien arvioiminen ja varsinaiset päätökset ovat asiakkaiden vastuulla.  Nämä prosessit ovat varsin erilaisia.

Ongelmanratkaisuprosessi

Prosessin vaiheet ovat seuraavat:

1 Tunnista ja määrittele ongelma

Oikean ongelman tunnistaminen on ehkä tärkein vaihe. Jos vaikka asiakkaat valittavat järjestelmän hitaudesta ja hitauden syyksi paljastuu tietoliikenteen vaatima aika, voi olla virhe ryhtyä nopeuttamaan tiedonsiirtoa. Ongelma ei siis ole tietoliikenteen hitaus vaan asiakkaan kokema odotusaika. Ehkä kannattaisi tutkia, miksi pitää siirtää niin paljon tietoa.

2 Ongelman analysointi.

Tässä vaiheessa analysoidaan vaikutuksia. Ytimenä on ongelmanaiheuttajien etsiminen. Ongelmilla on tavallisesti useita aiheuttajia, joiden välillä on riippuvuuksia. Aiheuttajan etsimiseen on olemassa paljon menetelmiä, jotka ovat lähtöisin eri aloilta.  Näistä lisää myöhemmin.

3 Ratkaisujen luominen

Ongelmalle voi olla useita eri ratkaisuja. Ensimmäiseksi kannattaa pohtia, onko koko ongelma edes tarpeellinen, ts. tarvitaanko ongelmallista vaihetta lainkaan. Ratkaisun mahdollisia sivuvaikutuksia pitää myös tutkia. Esimerkkitapauksessa tiedonsiirron nopeuttaminen kuormittaisi palvelimia enemmän.

4 Ratkaisun valinta ja suunnittelu

Vaiheet 4-6 ovat itse asiassa muutoksenhallintaa mutta esitän ne tässä täydellisyyden vuoksi. On tärkeää että asiakkaan edustaja osallistuu muutoksenhallintaan.

Valitaan se ratkaisu tai ratkaisut, jotka toteutetaan. Suunnitellaan toteutus huolella. Suhteellisuustaju on tärkeää. Pienen ongelman ratkaisu ei saa aiheuttaa suurta haittaa.

5 Ratkaisun toteutus

Toteutetaan ratkaisu suunnitelman mukaisesti.

6 Ratkaisun arviointi

Arvioidaan miten hyvin ratkaisu toimi ja onko se aiheuttanut mahdollisesti uusia häiriöitä.

Ongelman analysointi (Root Cause Analysis)

RCA on ongelman ratkaisun varsinainen ydin. Se vaatii tietoa ja taitoa. Systemaattisuus on tärkeä elementti. Nopea RCA saattaa paljastaa yhden aiheuttajan ja siten ratkaista havaitun insidentin mutta se voi jättää todelliset aiheuttajat piiloon. Seuraavassa muutama menetelmä:

5X miksi

Kysy viisi kertaa miksi, niin löydät todellisen aiheuttajan. Tämä on nopea ja helppo ajatusharjoitus.

Ongelmapuu (kalanruoto)

Piirretään puu kaikista vaikuttavista tekijöistä. Tämä on laajennus viidestä kysymyksestä.

Muutosanalyysi

Verrataan ongelmaa ja tilannetta ilman ongelmaa. Kirjataan kaikki erot. Tapahtumat kuvataan aikajanalla, joka on ratkaiseva ero edelliseen.

Tarinan kertominen

Ongelma kuvataan tarinana, jonka avulla löydetään aiheuttaja. Tämä ei ole kovin systemaattinen menetelmä mutta kirjoittaminen ja dokumentointi auttavat.

Suoja-aita-analyysi

Control barrier on suojamekanismi, jonka tehtävänä on estää vahingon tapahtuminen, esim. salasana, palomuuri, lukko, varmistus jne. Jos vahinko on kuitenkin tapahtunut, on syytä tutkia, mikseivät suojamekanismit toimineet.

Ongelmakartoitus

Kartoitetaan kaikki asiaan vaikuttavat tekijät. Jokaiseen tekijään vaikuttavat tekijät käydään läpi, kunnes saadaan aikaan täydellinen kartta vaikutuksista ja niiden riippuvuuksista. Tulos esitetään karttana. Tähän on olemassa erilaisia kaupallisia työkaluja.

Riskienhallinta

Riskienhallinta on tärkeä osa normaalia johtamista. COSO määrittelee sen seuraavasti:

Enterprise risk management is a process, effected by an entity’s board of directors, management and other personnel, applied in strategy setting and across the enterprise, designed to identify potential events that may affect the entity, and manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of entity objectives.

Riskienhallinta on siis yrityksen hallituksen hallussa oleva prosessi. Lainaan tähän esimerkiksi Stockmannin kuvauksen konsernin riskienhallinnasta:

Riskienhallinta

Tavoitteena on turvata konsernin tuloskehitys ja varmistaa liiketoiminnan häiriöttömyys toteuttamalla riskienhallintaa kustannustehokkaasti ja systemaattisesti eri liiketoimintayksiköissä. Tavoitteiden saavuttamiseksi riskienhallinta on Stockmann-konsernissa järjestetty siten, että

  • se on osa normaalia liiketoimintaa ja johtamista.
  • se on prosessi, jossa tunnistetaan, arvioidaan ja hallitaan niitä liiketoimintariskejä, jotka voivat estää tai vaarantaa liiketoiminnan tavoitteiden saavuttamisen.
  • sitä tukevat sisäiset kontrollijärjestelmät (ohjeet, rutiinit ja menettelytavat). Riskienhallintaohjeistusta on erikseen laadittu mm. seuraaville osa-alueille: IT ja tietoturva, rahoitustoiminto, ympäristöasiat, väärinkäytökset, turvallisuus ja vakuutukset.

Stockmannilla it-johto ei kuulu riskienhallinnan johtoryhmään.  Riskienhallinta ei siis ole it-yksikön toimivaltaan kuuluva asia, joskin it-yksikkö toki vastaa oman alueensa riskienhallinnasta. Riskienhallinnan vaiheet ovat:

  1. uhkien tunnistaminen, luokittelu ja arviointi
  2. kriittisten järjestelmien haavoittuvuuden arviointi
  3. mahdollisen vahingon arviointi
  4. riskien välttämiskeinojen etsiminen
  5. riskien vähentämisen priorisointi strategian pohjalta

On tärkeää, että asiakkaat osallistuvat sekä riskien vaikutusten arviointiin, että korjaavien toimenpiteitten priorisointiin.

Tunnistettu ongelma on siis myös tunnistettu riski.

Asiakkaan ongelmasta riskiin

Kun asiakas kohtaa ongelman, hän yleensä yrittää ratkoa sitä monin tavoin ennen kuin pyytää apua tukipalvelusta. Onnellisessa tapauksessa tukipalvelu tunnistaa pulman ja osaa ratkaista sen. Kyseessä voi olla esimerkiksi asiakkaan tekemä tavallinen virhe, joidenkin järjestelmien yhteensopimattomuus tai tunnettu vika johon on olemassa toimiva kiertotie.

Mikäli tukipalvelu ei tunnista ongelmaa, sen pitää ryhtyä ratkomaan sitä. Tässä vaiheessa käynnistetään ongelmanratkaisuprosessi, mutta sen on tapahduttava insidentinhallinnan alaisuudessa, koska insidentti on edelleen auki. Insidentti voidaan sulkea kun ratkaisu on löytynyt ja asiakas on tyytyväinen.

Löydetty ratkaisu ei ole aina kovin hyvä, se voi esim. edellyttää manuaalisia toimenpiteitä. On myös mahdollista, ettei ongelman syitä ymmärretä täysin vaikka se kyettiinkin poistamaan. Tällöin on selvästi riski ongelman uusimiselle. Näissä tapauksissa ongelman ratkomista pitää jatkaa.

Kyky ratkoa ongelmia on rajallinen. On mietittävä mitkä ongelmat kannattaa ratkaista. Tämä on osa riskienhallintaa, jokainen avoin ongelma on myös riski. Pieni it-ongelma voi olla iso riski organisaatiolle. Esimerkiksi Stockmannin Hullujen Päivien avaus vaarantui kun tietoliikenneyhteydet eivät toimineet.

Visa ja Mastercardien toimimattomuus johtui Stockmannin Hullujen Päivien aiheuttamasta tietoliikenteen ylikuormittumisesta. Ylikuormitus jumitti tietoliikennelinjan, joka välittää korttivarmennuksia luottokuntaan. Stockmannin tietoliikennettä hoitaa Fujitsu.  Maksuliikenne Luottokunnan ja Stockmannin välillä keskeytyi keskiviikkoaamuna reiluksi tunniksi.

”Positiivinen ongelma sinänsä, että myynti vetää niin hyvin. Selvitämme asiaa kovasti Fujitsun kanssa ja teemme yölläkin muutostöitä varmennusyhteyksiin, jotta saamme linjat varmasti toimimaan loppuviikoksi”, luottokunnan kauppiaspalveluiden johtaja Björn Ulander sanoo. http://www.kaleva.fi/uutiset/nordean-kortit-eivat-toimi/872691

Vaikka vika korjattiin pian, se saattoi vähentää myyntiä ja konsernin tulosta ja kuuluu edellä kuvatun konsernitasoisen riskienhallinnan alaisuuteen.

Mikä on sitten tukipalvelun ja riskinhallinnan välinen yhteys ja mikä on ongelmanhallinnan rooli siinä. Pitää hallita ongelmanratkaisuprosessi, mutta sitä tarvitaan monessa paikassa. Ongelmanratkaisuprosessi on siis alaprosessi, jota monet funktiot käyttävät päivittäisessä työssään.

Malli toimii siis näin. Tukipalvelu ratkoo asiakkaan ongelmia ja saattaa havaita mahdollisia riskejä. Riskit raportoidaan riskienhallinnalle, joka tarvittaessa ratkoo ja hallitsee niitä. Ongelmanratkaisuprosessi toimii sekä tukipalvelun sisällä, 2-tai 3-tasolla että riskienhallinnan sisällä. Ongelmanhallinta ja erityisesti  proaktiivinen ongelmanhallinta on osa riskienhallintaa. Riskienhallinta on laaja prosessi, kapasiteetin-, käytettävyyden, jatkuvuuden ja tietoturvanhallinta ovat myös osa sitä. Organisaation koosta riippuen voi olla järkevää joko jakaa riskienhallinta osaprosesseihin itilin tapaan tai sitten pitää se yhtenä prosessina.

PS Kannattaa lukea Marko Jäntin erinomainen komentti tähän artikkeliin.

Toisenlaisetkin näkemykset ovat sallittuja.

Pink Elephantin vuotuinen konferenssi lähestyy. Tässä tuore tiedote.  Otsikko viittaa siihen, että Pink Elephant samalla kertaa nostaa Rob Englandin profiilia ja markkinoi ITIL-kurssejaan. Rob England on tunnetuin ITIL ja APMG -kriitikko. On hienoa että yksityinen yritys pystyy hyväksymään erilaisia näkemyksiä kun taas itSMF:n tilaisuudet näyttävät olevan pelkkää ITIL V3 korkeaa veisua.

Suosittelen konferenssia. Olen siellä nyt puhumassa, mutta olin suunnitellut osallistuvani sinne joka tapauksessa. USA on riittävän iso yksikielinen markkina, jolloin siellä pystytään kokoamaan kiinnostavia konferensseja, joissa on oikeasti asiaa ja näkemyksiä.

%d bloggers like this: