Positiivinen kehitys

Tällä kertaa yritin etsiä positiivisen kehityksen trendejä. Ajattelin ensin uusia reilu vuosi sitten tekemäni  haastekyselyn,  mutta päädyin sitten pohtimaan asiaa toisesta näkökulmasta. Kysymykseni oli:

Mitkä ovat it-palvelun saavutukset, eli mitkä asiat ovat käyttäjän tai palvelun toimittajan näkökulmasta parantuneet selvästi parin viime vuoden aikana?
 Jos et näe mitään merkittävää parannusta, niin sekin on kiinnostava vastaus eikä välttämättä mikään negatiivinen asia.
 Voit vastata yhtä hyvin asiakkaan, palveluntarjoajan, tekijän tai päättäjän roolista.

Jostain syystä kysymystä pidettiin vaikeana. Osa vastasi että positiivinen näkökulma tuntui vaikealta, mikä lienee normaalia. Lehtiä lukemalla saa helposti sen kuvan, että olemme kuilun partaalla liukumassa kohti tuhoa, ja vain harvoin sitten todetaan, kuinka asiat ovat kehittyneet positiiviseen suuntaan viimeisten vuosikymmenien aikana.

Kun mietin mitä itse vastaisin niin päällimmäiseksi nousi tietotekniikan parantunut luotettavuus ja häiriöttömyys. Uudet työkalut ovat parempia ja olen saanut loistavaa palvelua kahdesta tukipalvelusta, joiden avulla aiemmin esiintyneet pulmat ovat kadonneet (kiitos Elisalle ja Datacenterille). Kotona iPadin hankinta on vapauttanut minut lähituen tehtävistä. (Niin ja vasta nyt tulee mieleen että ostin reilu kaksi vuotta sitten Soneralta miniläppärin 3G-yhteydellä, enkä ole kertaakaan ollut yhteydessä Soneraan sen takia.)

Kyselyyn vastasi 56 henkilöä ja heidän vastauksistaan poimin 140 kommenttia.

Vastauksista löytyi selvä trendi. Joka kolmas kommentti käsitteli ymmärryksen lisääntymistä. IT palveluja ymmärretään paremmin, samoin prosesseja. Lisäksi myös asiakkaan ymmärrys on parantunut. IT-palvelunhallinta, ITIL, ISO 20000 ja COBIT ovat toimineet oikein. ITILin positiiviset vaikutukset näkyvät selvästi, se on tuonut yhtenäisyyttä terminologiaan ja auttanut hahmottamaan tekemistä. Kehitys ei kuitenkaan tapahdu nopeasti.

Toinen merkittävä kehityskohde on parantuneet työkalut jotka mm. parantavat palvelun joustavuutta, hallintaa, viestintää ja mittaamista. Etätyöskentely ja -kokoukset ovat helpottaneet monien elämää.

Osin näiden seurauksena palvelun laatu ja saatavuus on parantunut juuri niin kuin itsekin olin havainnut. Pienten ja suurtenkin pulmien vähittäistä poistumista on vaikea havaita mutta mielestäni se on todellinen ja merkittävä kehitys.

Seuraavassa esimerkkejä kommenteista (osaa on muokattu selkeyden takia)

Kommentteja palvelujen paremmasta ymmärtämisestä:

  • Käyttäjän näkökulmasta isoin asia on konsernitasoinen palveluluettelo, josta voi tilata kaikki tarvitsemansa työvälineet, käyttöoikeudet, sovellukset ja toisaalta pyytää apua/neuvoa edellä mainittujen käytössä.
  • Ehkä palvelun toimittajan ja asiakkaan välinen dialogi on parantunut, koska terminologia on yhdenmukaistunut
  • Kyllä tärkein asia on varmaan palvelu- ja liiketoimintalähtöisyyden sisäänajo ja sitä kautta palveluiden käyttäjien ja tilaajien parempi huomiointi palvelun toimituksessa. Eli siitä vanhasta teknologialähtöisestä ”me tiedetään paremmin kuin te” mentaliteetista on siirrytty pikkuhiljaa asiakasystävällisempään ja myös nöyrempään, kuuntelevampaan asenteeseen.
  • Uusi ympäristö on parantanut myös it:n kykyä tuottaa oikeasti etua liiketoiminnalle ja meillä yleensä jo keskustellaan sisäisestä it:stä mahdollistajana ja ketteränä liiketoiminnan kumppanina kehittämässä liiketoimintaa.

Kommentteja prosessien ymmärryksen kehittymisestä:

  • Täällä palvelutoimittajan sisällä hyvää kehitystä on ollut se, että prosessimainen tapa työskennellä ja tuottaa palveluja on tullut osaksi organisaation toimintaa. Aikaisemmin prosessien mukaan työskentelyä vierastettiin ja jopa kartettiin, nyt prosesseja oman työn avuksi jo vaaditaan ja saatetaan joskus mennä jopa vähän liian pitkälle prosessien kuvaamisessa.
  • Olemme kehittäneet/muuttaneet toimintaamme ITSM periaatteiden mukaisesti 4,5 vuoden ajan. Alussa ei ymmärretty eikä osattu paljon mitään, ja sen jälkeen on opittu lisää koko ajan.
  • Palvelutuotannon osalta isoin parannus on se, että meillä ”kaikki” palvelutuotantoon osallistuvat (sisäiset ja ulkoiset) käyttävät yhteistä terminologiaa/informaatiota/järjestelmää palvelutuotantoon osallistuessaan. Eli tekeminen on hajautettua, mutta informaatio on keskitetty. Helpottaa/tehostaa merkittäväsi eri osapuolien tekemistä.
  • Yleinen muutoshallinnan tiedostaminen on parantunut eli niin toimittajan kuin asiakkaankin näkökulmasta katsottuna noudatetaan määrämuotoisia menettelyjä ja prosesseja, joista seurauksena ollut parantunut laatu tuotantoon
  • Sitten on ITIL, Cobit yms parhaiden käytäntöjen myötävaikutuksella parantunut tiketöinti (kirjauskäytännöt), mittaus ja raportointi joka on tuonut varmasti lisää läpinäkyvyyttä. Tosin näissäkin ollaan monessa organisaatiossa vielä todella kaukana siitä haavemaailmasta jota esim. ITIL piirtää.

Kommentteja asiakkaan ymmärryksen parantumisesta

  • Asiakkaiden kyvykkyys tehdä tiekarttoja on parantunut ja niitä näkee
  • Realismi palvelutasoista on parantunut
  • Business ymmärtää paremmin it:n luonnollisena osana liiketoimintaa – myös riskimielessä.
  • Palvelun tuottajan näkökulmasta positiivista kehitystä on tapahtunut palvelun osto-osaamisessa eli asiakkaat tietävät paremmin mitä haluavat ja osaavat paremmin määritellä tarpeensa (tosin tässä on edelleen paljon eroja asiakkaasta riippuen).

Lähes yhtä moni kommentti liittyi työkaluihin ja tekniikkaan:

  • Erityisesti tikettijärjestelmät ovat ottaneet aimo harppauksen kohti itsepalvelua ja automatisointia. Tämä on mielestäni positiivinen asia kahdesta syystä: a) se ohjaa tukipalvelua enemmän insidenttien hallintaan eli siihen akuuttiin apuun käyttäjille ja b) tuo aidon vaihtoehdon offshoringille.
  • Etäkäytön ja -tuen kehittyminen merkittävästi. Nykyisin lähituen tarve on harvinaista
  • Ohjelmisto- ja laitetarjonta nykyisin ”kaiken kattavaa”. Joka lähtöön löytyy tarjontaa, ei useinkaan tarvetta räätälöityyn tuotteeseen (pl. käyttöliittymä)
  • Itselle iPad on ollut merkittävä asia, joka on muuttanut henkilökohtaista käyttäytymistäni ja parantanut huomattavasti verkon käyttöä.
  • Käyttöjärjestelmä- ja ohjelmistopäivitykset käyttäjille automatisoitu

Omaksi ryhmäkseen nousivat viestintävälineiden kehitys ja mittaaminen:

  • Sähköiset kommunikaatio- ja kokouspalvelut
  • tapahtumiin perustuva moniulotteinen raportointi on kehittynyt (enpä ole tällaisia firman läpivalaisuvälineitä ennen nähnytkään), joskin työmaata on vielä jäljellä.

Lisäksi 15 % kommenteista liittyi parempaa palvelun laatuun, erityisesti saatavuuteen. Nämä kolme aihetta kattoivat 90 % positiivista kommenteista (n. 10 % kommenteista kuvasi negatiivista kehitystä mutta en käsittele niitä tässä, koska tavoitteena oli hakea positiivisia ilmiöitä).

Kymmenen kärki

Alla viimeisen 12 kuukauden aikana useimmin haetut jutut. Kertovat ehkä jotain siitä mitkä asiat kiinnostavat.  (oikeassa reunassa on tällä hetkellä suosituimpien juttujen luettelo, mutta se perustuu aika lyhyeen ajanjaksoon)

Alla linkit juttuihin.

Service Desk -mallin toimivuus 
Työkalututkimus 
Miten muutoksenhallinta toimii 
ITIL V3 pähkinänkuoressa
Palveluluettelo ja palvelujen määrittely
Uusi versio ISO 20000:2011 on julkaistu 
Asiakassuhteen hoito ja palvelusopimukset
Service Deskin kehittäminen
Haasteet – pidempi versio
Tutkimus palveluluetteloista

Alla viimeisen 12 kuukauden aikana useimmin käytetyt hakusanat.

pohjoisviitta
itil v3
insidentti
prosessikaavio
itil koulutus
mikä on hashtag
ongelmanhallinta
palveluluettelo itil
aale roos
iso 20000 koulutus
itil service desk

 

Asiakastuki ja häiriönhallinta

Asiakastuki on prosessi, jossa asiakas esittää jonkin asian ja palveluorganisaatio hoitaa sen. Olen kuvannut tämän puolen aiemmin, mutta tässä tiivistelmä:

  • Asiakas voi haluta jonkun palvelun tai tuotteen, jolloin kyseessä on tilauksen käsittely. Asiakas esimerkiksi haluaa ajaa eräajon tai tarvitsee uuden kännykän. Asiakaspalvelu käynnistää tilauksen vaatimat toimenpiteet ja varmistaa että tilaus tehdään.
  • Asiakkaalla voi olla pulma, esimerkiksi kirjautuminen ei toimi tai raportin tekeminen ei onnistu. Silloin asiakaspalvelu huolehtii siitä, että pulmatilanne hoidetaan. Pulma saattaa johtua häiriöstä tai viasta. Tällöin asiakaspalvelu yrittää etsiä jonkin kiertotien palauttaakseen palvelun, mutta käynnistää myös häiriönhallinnan,
  • Asiakkaalla voi myös antaa palautetta ja palaute kirjataan ja hoidetaan eteenpäin. Joskus palaute edellyttää myös toimenpiteitä.

Erityyppiset asiat vaativat omat proseduurinsa. Yksinkertaisen tukipyynnön hoitaminen on eri asia kuin monimutkaisen tilauksen käsittely.

Tämä prosessi lähtee asiakkaasta ja päättyy asiakkaalle. Asiakas esittää asian ja saa vastauksen. Jokainen pyyntö pitää kirjata ja luokitella.

Järjestelmän valvonta ja ylläpito on toiminto, joka huolehtii siitä että järjestelmä toimii halutulla tavalla. Se valvoo järjestelmää ja käynnistää korjaustoimenpiteet havaittuaan häiriöitä ja vikoja. Tavoitteena on korjata viat ennen kuin ne aiheuttavat häiriöitä asiakkaille, mutta aina tämä ei onnistu. Häiriönhallinta käynnistyy kun on havaittu vika tai häiriö ja päättyy kun vika tai häiriö on korjattu ja palvelu on palautettu.

Prosessi lähtee siis häiriöstä ja päättyy korjattuun vikaan. Jokainen häiriö pitää kirjata ja luokitella.

Ongelmanhallinta on taas prosessi, joka yrittää estää pulmien ja häiriöiden esiintymistä. Se on eri asia kuin häiriönhallinta.

Miksi jauhan näin yksinkertaista asiaa? Siksi, että se on ongelma, kun incident pitäisi kääntää suomeksi. Vuoteen 2007 asti insidentinhallinta tarkoitti asiakastuen prosessia, sitä pyöritti service desk. Incident tarkoitti palvelutilauksia ja asiakkaan pulmia ja se käännettiin tapahtumaksi tai insidentiksi. Vanha itil ei kuvannut palvelutuotannon kaikkia prosesseja ja toimintoja, se ei esimerkiksi kuvannut valvontaa ja ylläpitoa.

Sitten itilin 2007-version mukaan tapahtumanhallinnasta tulikin häiriöhallinta, joskin määritelmä oli hyvin sekava. Nyt sitten 2011 versiossa sekoilua on karsittu ja incidentin merkitys on selvemmin häiriö. Periaatteessa ok, mutta häiriönhallinta ei ole service deskin prosessi eli nyt itil on unohtanut asiakastuen prosessin.

Haluatko Google+ kutsun

Google+ on siis mahdollinen Faceboookin tappaja, jonka kävijämäärä kasvaa rajusti vaikka siihen pääsee vain kutsuttuna. Sen hienous on, että voit rajata tarkasti kenelle julkaiset mitäkin. Päätät itse keitä kutsuit piireihisi ja mille piirille julkaiset minkäkin jutun. Piirit ovat ihan mitä haluat, voit vaikka erotella naapurit, sukulaiset ja työkaverit. Voit liittää saman henkilön useaan piiriin tai jättää piirien ulkopuolelle. Toiset eivät näe piirejäsi.

Olen kokeillut sitä jonkin verran ja ajatellut  olla huolellinen piirien rakentamisessa. En nyt tiedä olenko vakuuttunut, mutta jos olet kiinnostunut niin minulla on kutsuja. Lähetä sähköpostiosoite, mihin haluat kutsusi.

Toiminnan kehittämisestä

Kävin kesällä kylässä pitkästä aikaa eräiden ystävien luonna. Huomasin että heille oli ilmestynyt kuntopyörä. Isäntäni kertoi että sitä oli käytetty vain kerran kauan sitten. Vaimo halusi sen, mutta selkä kipeytyi ensimmäisellä käyttökerralla. Toiset ystävät olivat tehneet ison remontin kerrostaloasunnossa. Remontin aikana paljastui että seinistä löytyneet putket eivät olleet piirustusten mukaisia. Töitä tuli lisää ja muutoksesta tuli paljon oletettua vaikeampi. Jälkimmäinen muutos vietiin läpi hammasta purren, ensimmäinen muutos jäi kalkkiviivoille.

Nämä kuviot toistuvat usein it-palvelunhallinnassa. It-johdolla on visio paremmin toimivasta organisaatiosta, jossa asiat ovat hallinnassa. Visiota ovat usein maalailleet ohjelmistotoimittajat, jotka kuvailevat miten heidän työkaluillaan saavutetaan asioiden hallinta. Joku ostaa työkalut, mutta niiden käyttö jää vähäiseksi. Työkalu yksinään ei ratkaise mitään, sitä pitää myös osata käyttää.

Valveutuneempi johtaja ymmärtää, että työkalut on tarkoitettu tukemaan prosesseja ja tilaa myös prosessien määrittelyn. Silti hanke voi epäonnistua. Prosessien määrittelyn yhteydessä voi paljastua kaikenlaisia ongelmia. Töiden järjestely ja ohjaus ei ehkä tue prosessityöskentelyä. Johto voi itse olla haluton noudatamaan prosesseja. Joskus olisi tarpeen organisoida koko yksikkö uudestaan. On ymmärrettävää, että koko hankkeen lopettaminen houkuttelee, mutta paremman hallinnan saa aikaan vain hallitsemalla paremmin.

Maltti on valttia toiminnan kehittämisessä. Liian suuret hankkeet epäonnistuvat herkemmin. Epäonnistuminen ruokkii epäonnistumista. Organisaatio oppii nopeasti että muutoshankkeista luovutaan aikanaan joten mikään ei muutu.Vähän kerrallaan toimii paremmin. Muutos pitää jaksaa ajaa läpi, mutta on toki oltava varma siitä, että muutos ei johda katastrofiin. Muutoksen vastustajia ei pidä väheksyä, vastustuksella voi olla hyvät perustelut. Silti hyviäkin muutoksia useinvastustetaan aluksi. Viitekehyksiin ei pidä luottaa sokeasti, niissä on hyviä ja huonoja neuvoja.

Toiminnan kehittämisellä pitää olla hyvä syy. It-palveluhallinnassa se on yleensä palvelun häiriöt, kankeus tai hinta. Jos niihin ei puututa, asiakas saattaa vaihtaa/ulkoistaa palveluntarjoajan. Johto usein toivoo, että pulmat voidaan poistaa ns. lattiatasolla, mutta joskus työ pitäisi päästä aloittamaan nurkkahuoneesta.

Joidenkin kollegoiden mielestä avain on ohjauksen kehittäminen, on turha parantaa prosesseja jos governance ei ole kunnossa. Ideaalisti siis muutoshanke etenee näin:

  1. Tarkastetaan että it:n ohjaus on kunnossa, että asiakas asettaa riittävän selkeät tavoitteet siitä, mitä pitää saada aikaan
  2. Järjestetään it:n sisäinen organisaatio tukemaan tavoitteita, mietitään painopisteet ja tärkeimmät toiminnot
  3. Määritellään palvelut, joilla tavoitteet saavutetaan
  4. Määritellään prosessit, joilla palvelut tuotetaan
  5. Hankitaan työkalut tukemaan prosesseja
  6. Varmistetaan että työt tehdään sovitusti
  7. Tehdään tarvittavat korjaustoimenpiteet, tarvittaessa vaiheeseen 1 asti.

No, Dilbertissä esiintyi kerran consultick, jonka taktiika on pureutua organisaation ja jäädä sinne pysyvästi. En ihmettele, jos asiakas suhtautuu epäluuloisesti hankkeen rajojen laajentumiseen.

Ketä kiinnostaa ITIL V3 2011 Edition

Uusi ITIL V3.1, oh anteeksi Edition 2011 on ilmestynyt 29.7. Eepos on turvonnut lähes 2000 sivuun, entisessä oli reilu 1300. Ben Kalland on tehnyt supertyön, jo pari päivää julkaisun jälkeen hän oli analysoinnut uudet kirjat ja verrannut niitä entiseen versioon: Kirjojen sisältö tai oikeammin niistä ammennettava tietämys ei sinänsä ole muuttunut, mutta tapa millä asiat esitetään kirjoissa on selkeytynyt. Huima suoritus päivän paneutumisen perusteella.

James Finister on taas lukenut APMG:n kehut uudesta versiosta ja kääntänyt ne kommenteiksi edeltävästä V3 versiosta, niistä tulee hilpeitä esim.: ITIL Service Operation ’ is ambiguous, and inconsistent especially around roles and responsibilities, particularly in technical management, IT operations and applications management.’ Lisää löytyy täältä: http://coreitsm.blogspot.com/2011/06/to-put-it-another-way.html

Mutta oikeasti, ketä kiinnostaa. En usko että kovin moni on jaksanut lukea edellisenkään version kirjoja. Väittiväthän jotkut että V3 sisälsi V2 prosessit sellaisenaan, vaikka eroja oli paljon. Ben Kallandinkin myöntää nyt että; Insidentin ja insidenttiprosessin määritelmissä oli 2007 –versiossa älytön ristiriita. Kurssimateriaalit ovat kai se tavallisin lähde minkä pohjalta ITILiin tutustutaan ja niiden V3 versiot tehty kovalla kiireellä vanhojen materiaalien pohjalta. No, nyt niitä kursseja varmaan päivitetään kovaa vauhtia 2011 version mukaiseksi.

Elina Kotilainen kommentoi kesäkuun Reittisuunnittelu-juttuani hyvin: Koen, että kaikissa viitekehyksissä on puutteensa, mutta se ei loppuviimeksi juurikaan haittaa, koska viitekehyksiä kuitenkin aina sovelletaan organisaatioon mukauttaen – varsinaiset ongelmat syntyvät aivan jostain muusta kuin esimerkiksi ITILin tai CobITin puutteista. Olen aika lailla samaa mieltä ja erityisesti, jos puhutaan puutteista, eli siitä mitä ei ole. Viitekehyksistä on hyötyä jossakin vaiheessa ja joissakin asioissa, mutta eivät ne ole täydellisiä. ITILin ongelma on se, että siellä on paljon huonoja neuvoja ja suoranaisia virheitä.  ITILin sokeasta soveltamisesta voi kyllä tulla haittaakin, jos ei älyä mikä siinä on älytöntä.

%d bloggers like this: