Itilin virheet

Juttuni itil-managereiden potkuista on herättänyt poikkeuksellisen paljon huomiota ja jopa keskustelua Pohjoisviitan sivuilla, joka on melko harvinaista. Viime perjantaista tuli uusi ennätyspäivä WordPressin liikennetilastojen mukaan. Huomautan, että minä en suositellut itil-managereiden erottamista, ainoastaan referoin mitä Charles Betz sanoi esityksessä, eikä hänkään suositellut sitä, hän vain kertoi mitä eräs pankki oli tehnyt.

Lupasin eräälle kommentoijalle tehdä yhteenvedon itilin virheistä. Ehkä voisin aloittaa sittenkin luettelemalla itilin hyötyjä. Itil on parempi kuin ei mitään, jokin kehikko on hyvä olla, sillä sen avulla on helpompi keskustella aiheesta ja on hyvä joutua pohtimaan it-palvelujen tuottamista. Prosesseilla voidaan saada asioita haltuun, on tärkeää priorisoida asioita ja muutoksia pitää hallita. Itil voi toimia, jos sen soveltamisessa käytetään paljon järkeä ja arvostelukykyä, osataan tehdä itsenäisiä ratkaisuja eikä jäädä väittelemään siitä mitä itil sanoo. Itil tarjoaa terminologian ja vaikka se on vähän horjuva, on se parempi kuin ei mitään.

No sitten luettelo itilin virheistä. En takaa, että tämä on kattava mutta yritän listata tärkeimmät.

  • Turhat prosessit. Itil kuvaa liikaa päällekkäisiä prosesseja. Lukuisten prosessien pyörittäminen johtaa helposti siiloutumiseen, jossa jokainen prosessi keskittyy oman alueensa hoitamiseen ja kokonaisuus kärsii. Turhat prosessit tuottavat taas turhaa työtä ja luovat keinotekoisia raja-aitoja.
  • Integraation puute. Kuten Jarkko Hedman kommentoi tätä, ”ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin.”
  • Toiminnot prosesseina. Itil kuvaa suuren joukon asioita prosesseina, vaikka ne eivät mitenkään omaa prosessin ominaisuuksia. Esimerkiksi saatavuuden ja jatkuvuuden varmistaminen ovat suunnittelua, joka vaatii osaamista. Prosessien kuvaaminen ja keinotekoisten tapahtumien kirjaaminen on turhaa työtä ja tuottaa turhia raportteja.
  • Sertifioidut asiantuntijat. Itil sertifikaatit hankitaan vastaamalla monivalintakysymyksiin, joissa oikean vaihtoehdon tietäminen perustuu muistiin. Kuulopuheiden mukaan osa kouluttajista antaa kysymykset etukäteen ja kertoo niiden oikeat vastaukset. Joka tapauksessa sertifikaatti ei kerro mitään omistajansa kyvyistä palveluhallinnan alueelta. Pahimmillaan sertifioitu asiantuntija ajaa järjettömiä ratkaisuja vedoten siihen, että itil sanoo näin, vaikka kyseessä on k.o. ”asiantuntijan” itse keksimä ja täysin virheellinen tulkinta siitä mitä itil ehdottaa.
  • Virheellinen palvelukäsite. Tämä on aika laaja aihe. Lue keskusteluni Akin kanssa.
  • Häiriöhallinta. Itilin suositus syöttää event managementin eli automaattisen valvonnan kautta tulleita häiriöilmoituksia asiakastuen kirjausten sekaan on järjettömyyden huippu. Asiakastuki on aivan eri asia kuin tekninen valvonta.
  • Ongelmanhallinta on rinnakkainen prosessi häiriönhallinnan kanssa. Saman asian tekeminen kahdessa eri vaiheessa on turhaa. Uusiutuva häiriö on liian aikaisin suljettu häiriö. Sotku johtuu siitä, että asiakastuki ja häiriönhallinta on nivottu yhteen.
  • Jatkuvan palvelunkehittämisen (CSI) mittaripainotteisuus on virhe. Painopiste on toiminnan tuloksellisuuden kehittämisessä, ei prosessien tehostamisessa.
  • En viitsi edes repostella turhien prosessien vikoja, sillä enemmistö itilin prosesseista on turhia.

Mielestäni tässä on aivan riittävästi syitä hylätä suurin osa itilistä.  Mitä sitten tilalle? Se on vaikea kysymys. Olen nähnyt lukuisia vaihtoehto-tarjokkaita, mutta mikään niistä ei ole vakuuttanut. Olen myös osallistunut useampaan yritykseen luoda jotain vaihtoehtoista, mutta kaikki hankkeet ovat luovuttaneet.

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

Vuoden 2012 suosituimmat jutut ja hakusanat

Luetuimmat jutut

  1. Työkalututkimus 2012
  2. Service Desk 2.0, the new support function
  3. BYOD Suomessa
  4. Service deskin tulevaisuus
  5. Vuoden 2012 teemat
  6. ITIL V3 pähkinänkuoressa
  7. Asiakassuhteen hoito ja palvelusopimukset
  8. Service Desk 2.0
  9. 20 miljonaa käyttäjää, 50.000 tukipyyntöä kuukaudessa ja 10 henkeä tuessa.
  10. IT palvelun toimivuus

ITIL V3 pähkinänkuoressa sinnittelee listalla edelleen, vaikka se on alkujaan kirjoitettu jo vuosia sitten.

 

Suosituimmat hakusanat

hakusanat12

Hakusanoissa ITIL pysyy yhä kärjessä, mutta hakujen määrä on pudonnut. Uusi ITIL 2011 ei tunnu kiinnostavan ketään, ISO 20000:n uusi versio sensijaan on nousussa. Sosiaalinen media alkaa ilmeisesti kiinnostaa, koska hashtag on yllättävässä nousussa. Vanha juttuni Tiedätkö mikä on hashtag on 17. luetuin.

Huom, hakusanoja on luokiteltu aiheen mukaan ja olen luokitellut hakusanoja vähän eri tavalla kuin vuosi sitten tehdyssä vertailussa, nyt yhdistin kaikki itil-haut yhteen, edellisessä ne on eroteltuna, esim itil koulutus jne.

Tässä vielä hakusanojen sijoitus listoilla. BYOD ei esiintynyt vuonna 2011 kertaakaan.

aihe v2012 v2011
itil 1 1
iso 20000 2 3
merimerkit 3 19
itil v3 4 2
hashtag 5 11
palvelukatalogi 6 6
pohjoisviitta 7 4
ISO 20000:2011 8 18
muutoksenhallinta 9 8
byod 10
insidentti 11 5
prosessit 12 16
service desk 13 12
aale roos 14 13
häiriönhallinta 15 17
elinkaari 16 21
ongelmanhallinta 17 8
konfiguraationhallinta 18 15
itil 2011 19 18

 

 

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.

Onko incident suomeksi häiriö?

Huomasin että useampi henkilö oli päätynyt sivuilleni otsikon kysymyksellä. Lyhyt vastaus on: kyllä, sillä itil on muuttanut käsitteiden sisältöä.

Pitempi vastaus on, että riippuu versiosta ja ei kannata uskoa mitä itil sanoo. Alkujaan insidentti oli yleistermi kaikille käyttäjien pulmille. Sitten siihen lisättiin myös tekniset häiriöt, joilla ei välttämättä ole mitään kytkentää johonkin nimettyyn käyttäjään ja lopulta siitä tuli puhdas häiriönhallinta. Tekninen häiriönhallinta on aivan eri prosessi kuin asiakastuki ja tämä on unohtunut itilin päivittäjiltä. Tämä on siis itilin uusimman version pulma.

Rhett Glauser ServiceNowlta sanoo: ”ITIL has hampered tool innovation and real vision for years” ja tämä on iso ongelma juuri asiakastuen kannalta. Itil 2011 mukainen työkalu ei toimi.

Kuka sanoo että Service Desk on kuollut?

Sain eilen Twitterissä tällaisen viestin: @Windupbird_ITSM @sitare21 @Karen_Ferris @barclayrae @aalem @simonejomoore @patb0512 Congratulations! You are the first #TFT12. TFT 12 on Service Desk Instituten järjestämä kansainvälinen web-konferenssi, jonka puhujat valitaan crowd sourcing tyyliin äänestyksellä ja minut (@aalem) on valittu nyt ensimmäisessä erässä puhujaksi Service Deskin tulevaisuudesta. Konferenssi kiertää maapallon 24 tunnissa ja siellä tulee olemaan 24 puolen tunnin esitystä ja niiden välissä voi käydä keskusteluja. Esitykset voi toki katsoa jälkeenpäin omassa aikataulussa.

Hetkeä myöhemmin kännykkään pukkasi mainosposti, jonka otsikkona on ”Service Desk on kuollut” ja jossa sanotaan että jotkut esittävät ”on naurettava ajatus että ”yhden luukun periaate” toimisi enää missään”.  Jutussa ei mainita ketkä esittävät tällaisia mielipiteitä, mutta jotenkin minusta tuntuu, että minä olen ainoa henkilö täällä Suomessa, joka esittää yleensä minkäänlaisia uusia näkemyksiä Service Deskistä. Siksi ajattelin että tuota pitää kommentoida.

Service Desk ei tosiaankaan ole kuollut, mutta se kehittyy. Koulutin 1990-luvulla sadoille ihmisille help desk -työskentelyä ja olen huomannut että jotkut käyttävät vielä vanhoja materiaalejani tämän päivän service desk koulutuksessa. Kirjoitin ne paljon ennen kuin olin edes kuullut ITIListä. No, eiväthän perusasiat miksikään muutu, mutta kyllä toimintakenttä on vuonna 2012 aika erilainen kuin 90-luvun puolivälissä. Silloin vasta opiskeltiin tietotekniikan alkeita eivätkä kuluttajat ostaneet tietokoneita. Nyt melkein jokainen käyttää tietotekniikkaa monipuolisemmin kuin 90-luvun nörtit.

ITILin SPOC ja incident management ovat pääosin vanhaa kauraa. Ne alkavat olla vanhentuneita ja niissä on muutama paha virhe. Asiakaspalvelun ja sisäisen häiriöhuollon sotkeminen toisiinsa on todella hölmöä. Yhden luukun periaate natisee entistä enemmän. On toki hieno ajatus, että kaikki pulmat voisi selvittää yhden luukun kautta, mutta asiakkaiden osaamisen lisääntyessä siitä tulee entistä vaikeampaa.

Service Deskin tehtävä muuttuu ja siksi Service Deskin pitää muuttua, ihan samalla logiikalla kuin vanhat bensa-asemat ovat korvanneet rasvamontut ravintolalla ja ruokakaupalla. Menneisyyteen takertuminen on huono ajatus. Tule työpajaani 30.10. kuulemaan ja keskustelemaan siitä, minne Service Deskit ovat matkalla,  Olen nyt julkaissut työpajan ohjelman.

Jos taas haluat oppia 1980-luvun niksejä, mene ITIL kurssille 😉

Insidentinhallinta ei ole Service Deskin prosessi

Väite voi olla vähän hämmentävä, mutta jos itiliä lukee, niin se on looginen johtopäätös, eihän service desk vahdi levypakkoja ja ja muita kahdennettuja laitteita voidakseen korjata ne ennen kuin niiden viat näkyvät asiakkaalle.Vai kuinka?

No, kirjoitin aiheesta artikkelin ITSMportaliin http://www.itsmportal.com/columns/incident-management-not-service-desk-process Siihen on jo tullut hyvä kommenttikin.

Näkyy olevan edellinen juttuni eniten luettujen artikkeleiden listan ykköseni, katso samalla se.

%d bloggers like this: