IT palvelun elämä olisi niin paljon helpompaa ilman asiakkaita

Siksi kai palveluhallinnan prosessimallit unohtavat asiakkaisiin liittyvät prosessit tai tarkemmin sanottuna, ottavat niistä mukaan vain absoluuttisen minimin. Kätevää kun saa suunnitella palvelun elinkaaren ilman turhia häiritseviä tekijöitä. No ei kai kukaan ota itilin elinkaarimallia ihan tosissaan, eihän? Uusin artikkelini aiheesta ITSM Portalissa julkaistiin juuri.

Huomasin muuten että muutoksenhallintaa käsittelevä tutkimukseni on noussut kolmannelle sijalle luetuimpien juttujen listalla ja että lukukertoja on jopa enemmän kuin vastaavalla artikkelilla Suomessa, vaikka se on täälläkin viimeisen vuosineljänneksen luetuin juttu.

Väärinymmärretty ongelmanhallinta

Minua on viimeaikoina alkanut harmittaa aiemmin pitämäni itil-kurssit. Pahoittelut kaikille osallistujille, mutta uskoin itilin olevan oikeassa. Valitettavasti itilin tapa kuvata insidentin ja ongelmahallinta on yksinkertaisesti väärin.Olen kirjoittanut tästä jo aiemmin mutta en korostanut tätä valuvikaa riittävästi. Itilin mukaan vian aiheuttajan (root cause) etsiminen on aina ongelmanhallintaa. Jos palvelupiste (SD) ei löydä valmista ratkaisua eikä kykene palauttamaan palvelua, se heittää pallon ongelmanhallinnalle joka sitten hakee aiheuttajan ja korjaa sen.

Tässä ei ole mitään järkeä. Tuloksena on kaksi samanlaista prosessia, jotka yrittävät ratkoa samaa tilannetta. Jos esimerkiksi tärkeä järjestelmä juuttuu eikä lähde käyntiin, on pakko tunnistaa mistä vika johtuu. Tätä varten on turha käynnistää toista prosessia. Niinkauan kun vika on päällä, on kiire päästä palauttamaan palvelu ja sehän on itilin tapahtumanhallinnan keskeinen tehtävä. Huono väliaikaisratkaisukaan ei keskeytä tapahtumanhallintaa, sen voi lopettaa vasta kun asiakas on tyytyväinen saamaansa ratkaisuun. Toisin sanoen: tapahtumanhallinnan tehtävänä on tunnistaa häiriön aiheuttaja ja korjata vika tarvittaessa. Tätä ei tietenkään pidä tehdä palvelupisteen ykköstasolla, mutta juuri siksi tarvitaan kakkos- ja kolmostasot. Itil-tentissä tällä vastauksella reputtaisi, mutta se on tentin vika.

Mikä sitten on ongelmanhallinnan tehtävä, tarvitaanko sitä lainkaan?  Ongelmanhallinnan kannattaa keskittyä ennaltaehkäisevään toimintaan, joka on osa riskienhallintaa. Ns. proaktiivinen ongelmahallinta on reaktiivista riskien hallintaa. Tärkeät tuotantojärjestelmät pyritään ”proaktiivisesti” suunnittelemaan niin, että ne eivät pysähdy. Jos näin kuitenkin on päässyt tapahtumaan, pitää miettiä ”reaktiivisesti” miten katkon uusiutuminen estetään jatkossa. Molemmat näkökulmat ovat tarpeen. Tapahtuman- ja ongelmanhallinta voivat siis tutkia saman tapahtuman aiheuttajia, mutta ongelmanhallinta (riskienhallinta) tutkii sitä vasta, kun se on ratkaistu ja palvelu on palautettu. Hyvä analogia tälle on palokunnan ja onnettomuustutkinnan toiminta. Palokunta sammuttaa tulipalon ja tutkijat selvittävät palon aiheuttajan. Prosessit ovat täysin erillisiä ja tapahtuvat eriaikaan, mutta kyllä palokunnankin on usein selvitettävä missä ja mikä palaa, ennenkuin se pystyy sammuttamaan tulen. Aiheuttajan käsite ei myöskään ole yksiselitteinen. Tapahtumanhallinnan kannalta riittää, kun on löydetty sellainen aiheuttaja, jonka korjaaminen palauttaa palvelun. Ongelmanhallinta tutkii myös aiheuttajan aiheuttajaa. Tapahtumilla on usein monia aiheuttajia. Mikäli ongelmanhallinta on osa insidenttien hallintaa, se joutuu toimimaan paineen alla, eikä ehdi miettiä pysyviä ratkaisuja, joka on sen tärkein tehtävä.

Asiakkuudenhallinta

Paljon kehikkoja

Olen viime aikoina törmännyt useaan kilpailevaan IT-palvelunhallinnan kehikkoon ja ihmetellyt niiden eroja ja yhtäläisyyksiä. Kehikot heijastelevat tekijöittensä näkemyksiä ja se tuo niihin erilaisuuksia. Kaikki ovat kuitenkin opiskelleet itilinsä, joka tuo niihin samankaltaisuutta. Niissä on kuitenkin yksi yhteinen puute.  Asiakaspalvelu puuttuu.

ITIL luotiin aikoinaan brittiläisen julkishallinnon puitteissa ja se on aikansa lapsi. Käyttäjäorganisaatio nähdään kahden kerroksen väkenä. Käyttäjä (User) on alaluokkaa ja vain päättäjien kanssa keskustellaan. Mitään myyntiä tai suhteiden hoitoa ei brittien valtionhallinnossa tarvittu. Erikoista mielestäni oli se, ettei palvelua korostava V3 elinkaarimallikaan tuonut asiakkuutta mukaan vaan tuo mieleen Neuvostoliiton 5-vuotissuunnitelmat.

Samanlainen suhtautuminen asiakaspalveluun näkyy useimmissa malleissa. Asiakaspalvelun sijalla on asiakastuki, jonka ykköstehtävä on palvelun palauttaminen. Toisin sanoen lähdetään siitä että jos palvelu ei toimi se korjataan asiakkaan pyynnöstä. Palvelussa on olennaista onko kyseessä oikea vika vai asiakkaan virhe. Asiakaspalvelua katsotaan vain ja ainoastaan palvelun tuottajan näkökulmasta.

Palvelunhallinta koostuu kuitenkin helposti tunnistettavista elementeistä, jotka siis pitäisi löytää jokaisesta kehikosta.

Palvelunhallinnan elementit

Palvelunhallinta seisoo neljällä jalalla. Ne ovat

  • asiakkuus
  • palvelutuotanto
  • suunnittelu
  • johtaminen

Huom. malli ei kuvaa organisaatiota, vaan keskeisiä toimintoja, joiden alle prosessit ja funktiot voidaan ryhmitellä.

Asiakkuus sisältää esim. myynnin, markkinoinnin, asiakassuhteen hoitamisen, sopimushallinnan ja suoran asiakaspalvelun. Itilin palvelutasonhallinta kuuluu tänne, samoin Service Desk, palvelutilausten käsittely ja asiakastuki.

Seuraavaksi tulee palvelutuotanto, joka tuottaa ja/tai hankkii tarjotut palvelut. Tämä tapahtuu yleensä osittain taustalla, mutta asiakas osallistuu siihen jollain tavalla.  Palvelutuotanto pyörittää ja ylläpitää palvelua. Täällä korjataan viat ja tehdään palvelun tarvitsemat muutokset.

Palvelu pitää suunnitella ja sitä pitää kehittää. Palveluun liittyy aina jotain erityisosaamista jota pitää vaalia. Uusien palvelujen käyttöönotto, palvelun kehittäminen, riskienhallinta, tietoturva, kapasiteetin suunnittelu jne. kuuluvat tähän ryhmään. Tämä ei kata oman toiminnan suunnittelua.

Palvelua pitää johtaa ja koordinoida. Johto yhdistää eri suunnista tulevat tarpeet ja ratkoo prioriteetit. Johto ohjaa suunnittelua, tuotantoa ja asiakkuuksia asettamalla tavoitteita, normeja ja vaatimuksia. Johto myös antaa resurssit.

Oman toiminnan suunnittelun tarve riippuu yksikön asemasta ja itsenäisyydestä. Sisäisen yksikön rahoitus, henkilöstöhallinto ja strategia tulee ylemmältä taholta. Itsenäinen yritys joutuu miettimään kaiken itse. Tämä voi olla hyvin laaja kokonaisuus erilaisia asioita, mutta niiden tarkka määrittely it-palvelunhallinnan kehikossa on turhaa, nämä eivät ole ominaisia vain it-palvelunhallinnalle.

Jokaisella alueella on omia prosessejaan, mutta jotkut prosessit ovat kaikille yhteisiä, esim. muutoksenhallinta ja palvelun kehittäminen.

Tässä ei ole mitään ihmeellistä ja uutta, kummallista on vain se, että mikseivät nämä perusasiat näy palvelunhallinnan kehikoissa. Asiakkaan unohtaminen vie kohti napaansa tuijottavaa, sisäänlämpiävää organisaatiota, joka mittailee omaa erinomaisuuttaan.

Tajuatko – Do you get it?

Tämä Pink11 avausvideo kannattaa katsoa. Se kestää 8 minuuttia, eikä sisällä puhetta, vain tekstiä. Panee miettimään.

Yleisin hakusana on insidentti

Olen tämän vuoden aikana alkanut kiinnittää huomiota siihen, että sivuilleni päädytään hakusanalla insidentti, se on yleisin koko historian ajalta että myös viimeisen 30 päivän aikana. Ihmiset ilmeisesti hakevat jatkuvasti sanan määrittelyä. Voisi tietysti ajatella että käsitteen pitäisi jo olla selvä, onhan insidenttienhallinta ollut suosituin itil-prosessi jo vuosien ajan. Miksi sitten sitä etsitään? Yksi selitys voi olla se, että käsite on epämääräinen. Itil-kirjoista löytyy kolme erilaista määrittelyä ja lisäksi määritelmät menevät sekaisin eventin ja palvelupyynnön kanssa.

Itse olen oikeastaan luopunut koko termistä, se on sekä epämääräinen että sisäänlämpiävä. Asiaskaspalvelun näkövinkkelistä keskeinen käsite on asiakkaan yhteydenotto, jonka sisältö voi olla joku palvelutilaus, pulma tai palaute. Asiakkaan kokema pulma johtuu usein asiakkaan tekemästä virheestä tai tiedonpuutteesta. Joskus kyseessä on tunnetun vian aiheuttama tai sellaiseksi epäilty häiriö. Näitä kai voisi kutsua insidenteiksi, jos sitä termiä haluaa käyttää. Viat ovat selviä vikoja jotka pitää korjata. Asiakaspalvelun tehtävänä on ratkoa asiakkaan pulmat. Käytännössä siis itilin insidentinhallinta on oikein ymmärrettynä asiakkaan yhteydenoton hallintaa.

Toinen epämääräinen ja turha termi on itilin ongelma eli yhden tai useamman insidentin aiheuttaja. On turha käynnistää ongelmanhallintaa jos jokin on selvästi rikki, viat pitää korjata jos mahdollista. On kokonaan eri asia miettiä jatkossa miten vastaavat tilanteet voidaan tulevaisuudessa estää.  Tätä varten on olemassa saatavuudenhallinta, jonka yksi tehtävä on miettiä komponettien huollot ja ennakoivat vaihdot. Tunnettujen vikojen hallinta ja korjauspäätösten arviointi on taas osa riskienhallintaa. Jos kuitenkin haluat/joudut pyörittämään ongelmanhallintaa niin pilko se kahteen osaan, ongelmien ratkomiseen ja riskienhallintaan. Ne ovat ihan eri prosesseja. Vikojen korjaaminen on taas oma prosessinsa jossa on samantekevää, onko vika havaittu itse vai asiakkaan aloitteesta. Huomaa että ne saattavat mennä samaan työjonoon muutosten ja muiden palvelutilausten kanssa.

Pink11

Pink Elephantin konferenssista on tosiaan tullut IT palveluhallinnan ykköstapahtuma. Oli hauska tavata vanhat kollegat, tässä kuvassa vasemmalta Pink President David Ratcliffe ja Help Desk Instituten perustaja Ron Muns, jonka kyllä piti olla jo eläkkeellä.

 

 

Kaikkien alan konferenssien ikiliikkuja Malcolm Fry (oik) oli myös paikalla. Malcolmin tavaramerkki ovat kevyesti aiheeseen liittyvät vitsikkäät jutustelut ja sellaista kuultiin taas kerran. Muuten konferenssin anti olikin sitten painavaa tavaraa. Ykkösteema oli teknologian nopea muutos ja sen vaikutukset. Elämme melkoista murroskautta ja on hyvä pysähtyä miettimään sitä.

 

 

Keskeisenä teemana oli mm The IT Skepticin (Rob England) esille tuoma teesi, että loppujen lopuksi IT palvelunhallinnassa on kyse ihmisistä ja heidän käytöksestään. Prosessit ja työkalut ovat vain apuvälineitä. Vieraileva keynote-puhuja oli laivaston kapteeni, joka kertoi omia kokemuksiaan laivaston surkeimman laivan nostamisesta sen parhaaksi. Paul Wilkinsonin ABC (Attitude, Behaviour, Culture) oli myös paljon esillä. Siitä kyllä kuulin täyttä puutaheinää, konsultin pitäisi muka muuttaa ensiksi organisaation kulttuuri. Kerroin esimerkkinä Viron, jonka oma kulttuuri kesti aika hyvin Neuvostoliiton muutosyritykset.

 

Omat esitykseni menivät hyvin ja tässä jälkimmäisessä olin jo onnistunut karistamaan turhat jännitykset pois. Aiheinani oli ISO 20000 ja ongelmanhallinnan vaikeus. Toki osa yleisöstä taisi järkyttyä kun kerroin itilin lukuisista virheistä ja sekavuuksista.

It:n ulkoistaminen tuntuu olevan paljon vähäisempää USAssa kun meillä. Kyselin molempien yleisöjeni taustoja ja paikalla oli yli 90% sisäisen it:n edustajia. Monitoimittajaympäristön pulmat eivät ole lainkaan niin tavallisia, sen sijaan oman yksikön siiloutuminen on tavallista. Tämän turvallisen linnoituksen murtuminen on selvästi tulossa. Vanha it menettää valtaansa. Suomessa sama ilmiö tapahtui 1990-luvulla.

Sosiaalinen media oli mukana tiiviisti. Oli hauska huomata kuinka paljon tuttuja minulla oli siellä. Olen kirjoitellut paljon IT Skepticin sivuille ja saanut Twitter-seuraajia alan vaikuttajista ja nyt sitten tapasimme ensimmäistä kertaa, mutta kuin vanhoina tuttuina. Etsi #Pink11 Twitterissä niin näet kuinka keskustelu toimi.

Vielä yksi merkittävä havainto Charles T Betz’in esityksestä. Prosessien välinen priorisointi ja koordinointi puuttuu itilistä. Se on merkittävä puute ja täytyy myöntää että suorastaan harmitti etten ollut tajunnut sitä. Kyse on siitä, että kun yksi henkilö on mukana useassa prosessissa, miten hän valitsee samanaikaisten tehtävien välillä. Onko tilaus tärkeämpi kuin muutos vai ajaako insidentti ohi? Onko kaikilla tehtävillä prioriteetit ja ovatko ne samalla asteikolla? Valintaa ei pidä jättää tekijän harteille.

Suosittelen matkaa Las Vegasiin, Pink12 ennakkoilmoittautumiset ovat jo käynnissä. Lopuksi vielä kuva Bellagion suihkulähteistä joita kyllä jaksoi katsella.

 

 

 

 

%d bloggers like this: