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

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: