Lossit ja sillat

Lossi ja silta antavat saman hyödyn, niiden ansiosta voi ylittää salmen. Lossi on selkeä palvelu, sillä on palveluajat, henkilökuntaa ja palvelumalli. Jotkut lossit kulkevat aikataulun mukaan ja toiset vain silloin kun niitä tarvitaan. Jos lossiin tulee jokin vika, se vaikuttaa lossin käyttäjiin. Lossi tarvitsee johtamista ja hallintaa ja sen toiminnan tulee olla asiakaskeskeistä, lossi toimii käyttäjien takia.

Silta vain on, sen ylittäminen ei poikkea muusta tiestä millään tavoin, se on osa tien infrastruktuuria. Siltaa pitää huoltaa ja ylläpitää mutta huolto lähtee sillan tarpeista. Sillan ylläpito on teknologialähtöistä.

IT palvelujen määrittely tuottaa monille päänsärkyä. Mikä on järkevä tapa kuvata palvelut? Kaiken tekemisen pitäisi liittyä asiakkaaseen mutta kytkentä ei ole aina kovin selvä. Ehkä olisi järkevä määritellä mikä osa toiminnasta on infrastruktuuria ja mikä palvelua. Infrastruktuurin tulee olla vakaata ja suhteellisen muuttumatonta. Pilvipalvelu on esimerkki infrasta. Kirjoitan parhaillaan tätä artikkelia pilvessä. Ennen kuin opin käyttämään WordPressiä tarvitsin apua www-sivujen ylläpidossa, nyt se hoituu ilman tilauksia.

Olen nyt miettinyt voisiko palveluluettelon tekeminen helpottua, jos infrastruktuuri kuvattaisiin erikseen. Ehdottomana edellytyksenä olisi se, että infra on vakaata ja sen muutokset tai häiriöt eivät näy asiakkaille kuin ani harvoin. Ilmeisesti osa IT-palveluista täyttää nämä vaatimukset. Tuntuu ilmeiseltä että aidon infrastruktuurin hallinta on aika erilaista kuin palvelun hallinta. Uuteen malliin kuuluu myös ketteryys. Sen osalta silta-analogia ei oikein pure. Ketteryys on tärkeä elementti laadukkaan IT infran toteuttamisessa. Kerroin aiemmin että tämä WordPress julkaisee keskimäärin 16 versiota päivässä eli työkaluni on ehkä päivitetty tämän kirjoittamisen aikana.

VMware on kehittämässä uutta mallia pilvipalvelun hallintaan ja sen ajatuksena on siis korvata ITIL. Mallia kehittämään on koottu yhteisö, joka kerää ja dokumentoi uusia parhaita käytäntöjä.  Saa nähdä mihin CloudOps johtaa ja syntyykö siitä mitään. Olen kuitenkin vakuuttunut siitä että parhaat käytännöt kehittyvät kaiken aikaa ja jos haluaa olla hyvä, kannattaa opiskella uutta tietoa. ITIL toki kuuluu yleisivistykseen, mutta kovin syvällisesti siihen ei kannata paneutua.

 

 

Asiakastuen kehittämisen työpaja 30.10.2012 klo 9-16, Vantaan Leija

IT palvelu ja asiakkaiden toiminta muuttuu jatkuvasti. IT:n tavoitteena on mukautua asiakkaitten muuttuviin tarpeisiin, mutta myös tarjota uusia ratkaisuja, jotka auttavat asiakkaita kehittämään omaa toimintaansa. Muutokset ja niiden aiheuttamat jännitteet näkyvät ensimmäiseksi asiakkaan ja IT:n rajapinnassa. Asiakaspalvelun ja -tuen toiminnan pitää kehittyä jatkuvasti.

Tämä työpaja keskittyy erityisesti asiakastuen kehittämiseen.  Työpaja on suunniteltu henkilöille, jotka toimivat IT:n ja sen asiakkaiden rajapinnassa. Työpajassa käsitellään mm. asiakastuen henkilöstöä, prosesseja, työkaluja ja mittaamista.

Tämä on siis aidosti työpaja, ja siksi osallistujia pyydetään esittämään kysymyksiä, joita työpajassa käsitellään. Ohjelman painotus tarkentuu osallistujien toiveiden mukaisesti.

ALUSTAVA OHJELMA, tämä voi vielä muuttua tai täsmentyä

0845 Aamukahvi
0900 Esittäytyminen ja päivän aiheet
0930 Asiakaspalvelu ja häiriöhuolto, älä sotke niitä
1030 Rutiini ja poikkeus, miksi prosessi ei vain aina toimi
1100 Miten yhdistää syvä osaaminen ja tehokkuus
1130 Lounas
1230 Ongelmia ja ratkaisuja
1330 Kahvi
1400 Miksi prosessimittarit eivät riitä
1430 BYOD ja SD
1500 Sosiaalinen media Service Deskissä
1530 Kehittäminen
1600 Päivä päättyy

Työpajan hinta on 480 € + alv. Materiaali toimitetaan pdf-muodossa ja saat myös työpajan tulokset käyttöösi tilaisuuden jälkeen.

Ilmoittaudu pikaisesti niin ehdit mukaan sisällön määrittelyyn.

ITSM lista

ITSM Review julkaisi listan ITSM vaikuttajista, mukaan mahtui yksi suomalainenkin, olen sijalla 15 😉

 

Hidasta edistystä edelleen

Työkalututkimuksen tulosten mukaan n. 20% on edistynyt prosessien käyttöönotossa, mutta 80% käyttää työkalua lähinnä Service Deskissä. Tämä tulos vastaa sitä yleistä käsitystä, että itilin mukaisten prosessien todellinen käyttöönotto ei ole edennyt kovin pitkälle. Perinteinen malli on, että opiskellaan itiliä, kuvataan prosessit ja hankitaan työkalu tukemaan niitä. Joskus menetelmä tuottaa hyviä tuloksia, mutta yleensä ei. On tavallista että kehitys pysähtyy ja prosessit rapistuvat.

Jos prosessit ovat kunnossa, ne näkyvät. Tässä testikysymyksiä. Prosessit ovat hallinnassa, jos teillä käydään tällaisia keskusteluja:

  • Järjestelmän X tikettien määrä on kasvanut 27% ja sen takia sitä pitää kehittää.
  • Muutosten läpivienti vie keskimäärin 14 vrk ja se halutaan pudottaa 5 vuorokauteen.

Itil buumi alkoi Alankomaissa 10 vuotta aiemmin kuin Suomessa. Silti siellä tuskaillaan saman ilmiön kanssa. Prosesseja on vaikea saada toimimaan. Jan van Bon kertoo kehittäneensä menetelmän, jolla prosessit saadaan oikeasti toimimaan. Ytimenä on  palvelunhallinnan ohjausjärjestelmä (Service Management System), jonka mm. ISO 20000 vaatii. Prosesseja on paljon vähemmän kuin itilissä, mutta ne kattavat samat alueet.

Kiinnostaisi päästä kokeilemaan Janin metodia. Siihen tarvittaisiin asiakas, joka on todennut, että kovasta yrittämisestä huolimatta itilin käyttöönotto ei etene ja että tarvitaan uusi lähestymistapa.

 

Työkalut kiinnostavat

Perjantaina iltapäivällä julkaistu Työkalututkimus 2012 https://pohjoisviitta.wordpress.com/2012/08/17/tyokalututkimus-2012/ on luettu jo 472 kertaa maanantaihin klo 9 mennessä. Se on puolet jakelulistan määrästä ja aika monet olivat vielä lomilla.

Työkalututkimus 2012

Tämä IT palvelunhallinnan ohjelmistoja koskeva tutkimus tehtiin elokuussa 2012. Kysely lähetettiin Pohjoisviitan kontaktiryhmälle ja vastauksia on tähän mennessä tullut 81 kpl, joka on suunnilleen saman verran kuin 2010 ja 2007 tehdyissä kyselyssä. Samoja vastaajia tässä ja edellisessä kyselyssä on n. 20%.

On vaikea sanoa miten hyvin tutkimus edustaa suomalaista IT alaa, mutta toisaalta olisi hyvin vaikea kohdentaa tutkimusta paremminkaan, sillä ei ole olemassa tietokantaa, josta löytyisivät IT palvelunhallinnan harrastajat. Lisäksi on vaikea saada ihmisiä vastaamaan tällaisiin kyselyihin. Kyselyn uskottavuutta taas parantaa se, että vastaajat esiintyvät omilla nimillään. Toisaalta tulokset näyttävät kiinnostavan, edellisen raportin on lukenut arviolta kymmenkertainen määrä vastaajiin verrattuna.

Tutkimuksessa kysyttiin kolme asiaa: käytössä olevan ohjelmiston nimi, käyttötarkoitus ja kouluarvosana.

Tiesin että markkinoilla on tapahtumassa muutoksia, olin kuullut usealta yritykseltä, että he ottavat käyttöön ServiceNow’n. Minua kiinnosti kuinka suuren osuuden se on saavuttannut, mikä tuote on menettänyt ja kuinka tyytyväisiä tähän tulokkaaseen ollaan.

Kuten kuvasta näkyy, ServiceNow on kiivennyt heti kakkosijalle, mutta se ei näytä syöneen muiden markkinaosuuksia, koska samaan aikaan on luovuttu itsetehdyistä ratkaisuista, lisäksi Sharepointin suosio on romahtanut. Efecte  on säilyttänyt markkinajohtajuutensa, Remedy on romahdettuaan aikaisemmin pysynyt kolmosena ja Altiris kavunnut neljännelle sijalle. Nimeltä mainittujen tuotteiden määrä on kasvanut edellisestä tutkimuksesta, siinä mainittiin 25 ohjelmistoa, nyt mainittiin 31 kpl.

Tyytyväisyys tuotteisiin näyttäisi olevan laskussa, sillä kaikkien arvosanojen keskiarvo putoaa tasaisesti, tosin muutos on pientä ja mahtuu hajonnan sisään. Requeste on säilyttänyt ykköstilansa ja on ainoa, jonka arvosanojen keskiarvo on yli 8. Remedy on noussut tasoihin Efecten kanssa jaetulle kakkossijalle. ServiceNow ei erotu hyvillä arvosanoilla, se on samalla tasolla kuin kaikkien arvosanojen keskiarvo. Jotenkin odotin parempia tuloksia.

Tällä kertaa päätin analysoida myös työkalujen käyttötarkoitukset. Poimin vastauksissa mainitut asiat ja ryhmittelin ne yhteisten otsikoiden alle. Alla olevassa kuvassa esitetään, kuinka usein jokin käyttötarkoitus mainitaan. Prosenttien summaksi tulee yli sata, koska monet mainitsivat useita tarkoituksia.

Valtaosa on maininnut service deskin tiketit,  insidenttien tai palvelupyyntöjen hallinnan. Nämä kaikki on yhdistetty otsikon tiketit alle. Cmdb:n tai vastaavan mainitsi vajaa 20% vastaajista. Asset management esiiintyi myös jonkun kerran, mutta niitä en yhdistänyt tähän. Kuvassa ei esitetä kaikkia käyttötarkoituksia, ainoastaan yleisimmät. Muutoksenhallinnan mainitsi reilu 10 % ja toiset 10% mainitsi palvelunhallinnan yleensä (itsm). Tulos vastaa hyvin aiemmin syntynyttä mielikuvaa, että aika harvat ovat päässeet kovin pitkälle palvelunhallinnan kanssa.

Tein mielenkiintoisen havainnon, kun vertasin tuotteesta annettuja arvosanoja tuoteen käyttöön.

Erot ovat aika suuria ja niissä on hyvin mielenkiintoinen logiikka. Ne jotka hyödyntävät itsepalvelua ja tietämyshallintaa, ovat huomattavasti tyytyväisempiä tuotteeseen kuin ne, jotka käsittelevät tikettejä ja muutoksia. Erot tuotteiden välillä voivat selittyä osin näillä tekijöillä. Toisaalta työkalun tuomat hyödyt varmasti kasvavat, kun tuotetta kyetään käyttämään edistyneellä tavalla.

Kypsyydestä

It-organisaation tilaa voi kuvata sen kypsyystasolla. Kypsyystasot ovat usein suhteellisen helppo tunnistaa ja niistä on olemassa lukuisia malleja. Lähtökohtana on yleensä yksilöllinen toiminta, johon tulee ensin valvontaa, sitten hallintaa, ohjausta ja optimointia. On tavallista ajatella että kypsyydessä pitää pyrkiä aina korkeimmalle tasolle, mutta se ei ole välttämättä totta. Olen käyttänyt renkaiden vaihtoa esimerkkinä erilaisista kypsyystasoista.

 0-taso Sakkokuski ei vaihda renkaita kuin pakon edessä.
1-taso Yksityisautoilija tarkistaa renkaiden kunnon kesä/talvi-renkaiden vaihdon yhteydessä ja hankkii uudet kun kulutuspinta alkaa olla vähissä.
2-taso Taksiyritys uusii renkaat 50.000 km välein.
3-taso Bussiyhtiön ajomestari seuraa renkaiden kulumista ja määrää vaihtohetken puoli vuotta aikaisemmin.
4-taso Rekkayhtiö seuraa renkaiden kulumista ja maksaa kuljettajille bonuksia jos renkaat kestävät keskimääräistä paremmin.
5-taso Formula 1 talli arvioi renkaiden keston kierroksen tarkkuudella, mutta muuttaa suunnitelmia, jos olosuhteet vaihtuvat. Renkaan vaihtohetkeen vaikuttavat rata, kierrosajat, sää ja muiden kilpailijoiden toiminta. Tavoiteaika vaihtoon on 4 sek.

 Edellä kuvattu malli korostaa sitä, että tavoiteltava kypsyystaso riippuu tarpeesta, mutta toki jokainen voi toimia tarvittavaa matalammalla kypsyystasolla.

Elokuun kyselyn teemana oli KPMG:n jo vuonna 2000 julkaisema malli IT yksikön kypsyydestä. Mielestäni malli on edelleen osuva.

Mallin kypsyystasot

  1. Teknologialähtöinen. IT taistelee tekniikan kanssa, juuri mitään prosesseja ei ole käytössä. Asiakas saa sitä mitä kyetään tarjoamaan. Toiminta voi sinänsä olla melko asiakaslähtöistä, mutta sen laadun ja luotettavuuden kanssa on ongelmia.
  2. Prosessikeskeinen. Prosessit on saatu toimimaan ja IT kykenee mittaamaan toimintaansa. Prosessit ovat keskeisessä roolissa ja asiakkaan tulee mukautua niihin, muuten palvelu ei toimi.
  3. Palvelukeskeinen. IT on määritellyt palvelunsa ja kykenee tuottamaan niitä ohjaamalla prosessejaan. Palvelut ovat standardoituja. Asiakas voi tilata palveluja, mutta ei voi muokata niitä.
  4. Asiakaskeskeinen. Nyt asiakas pääsee päättämään palveluista ja IT toimii lähellä asiakasta tiiviissä yhteistyössä. Taustalla ovat toimivat prosessit ja standardoidut peruspalvelut. Niitä osataan käyttää hyvin joustavasti.
  5. Liiketoimintakeskeinen. Liiketoiminta ohjaa IT:tä täysin ja IT:n tavoitteet ovat liiketoimintatavoitteita.

Tässä mallissa palvelukeskeisyyden ja asiakaskeskeisyyden välillä on merkittävä kynnys. Alemmilla tasoilla IT päättää ja asiakas saa mitä IT toimittaa, ylemmillä tasoilla vastuu on siirtynyt asiakkaille. Kyse ei ole siis pelkästään IT:n kypsyydestä, vaan myös asiakkaan on kypsyttävä tähän rooliin.

Tämän pohjalta yritin kuvata tilanteita, joissa kukin taso olisi saavutettu.

 
a) Teknologia on hallussa. IT laitteet ja järjestelmät toimivat ja mahdolliset vikatilanteet kyetään korjaamaan.
b) Prosessit toimivat tehokkaasti. Kaikki häiriöt, ongelmat, muutokset jne. kirjataan. Häiriöiden ratkaisuajat tiedetään ja muutosten riskit osataan arvioida.
c) Palvelut pelaavat. Osataan tuottaa pitkälle standardoituja IT palveluja asiakkaan tilausten mukaan. Muutosten vaikutukset tunnetaan ja palvelujen laatu on hallinnassa.
d) Asiakas määrää. Asiakas ohjaa toimintaa ja päättää mitä IT palveluja tuotetaan. IT-organisaatio kykenee mukautumaan joustavasti muuttuviin tarpeisiin.
e) Liiketoiminta ohjaa.  IT on sulautunut liiketoimintaan ja sitä johdetaan liiketoiminnan näkökulmasta. IT pystyy luomaan uusia mahdollisuuksia liiketoiminnalle. 

Pyysin kertomaan miten hyvin vastaajan organisaation nykyinen tila vastaa näitä kuvauksia asteikolla: 1 -5. 1 ei lainkaan, 2 vain vähäisesti, 3 osittain, 4 aika hyvin ja 5 täydellisesti.

Lisäksi pyysin vielä kertomaan mikä näistä kuvauksista vastaa nykyistä tilaa ja mikä on tavoitteena. Tämä kysymys oli ilmeisesti vaikeasti muotoiltu, sillä n. kolmasosa jätti vastaamatta siihen tai vastasi väärin. Oikea vastaus olisi siis ollut jokin kirjain, esim. nyt A ja tavoitteena B. Näin muuten ei yksikään vastannut, vaikka se olisi oikea vaihtoehto aika monelle.

Valtaosassa vastauksissa oltiin tasoilla 4 tai 3 eli aika hyvin tai osittain. Ainoastaan teknologia -tasolla löytyi merkittävä määrä täydellisesti -vastauksia.

Kynnys palvelu- ja asiakastasojen välillä näkyy selvästi, vain alle 20 % arvioi olevansa niillä tasoilla.

Oman tason ja tavoitetason välillä on mielenkiintoinen korrelaatio. Jos omaksi tasoksi arvioitiin teknologia, tavoittetasona oli yleensä palvelu. Jos taas oma taso oli jokin muu, tavoitteeksi tuli asiakas- tai liiketoimintakeskeisyys.

Tein oman tulkinnan kypsyystasoista vastausten perusteella.

Jos vastaaja oli jonkun kypsyystason kuvaavan täydellisesti, hyväksyin sen. Jos vastaaja ei sanonut yhdenkään tason toteutuvan täydellisesti, mutta sanoi useamman toteutuvan aika hyvin, valitsin näistä toiseksi ylimmän. Näin laskin jokaiselle vastaajalle tämän hetken kypsyystason. Periaatteena oli, että alempien kypsyystasojen täytyy toteutua eli kypsyystasoarvioiden piti pysyä samana tai pudota.

Oman tulkintani mukaan vajaa puolet jäi tasolle nolla, eli teknologia ei ole täysin hallussa. Vajaa neljännes on saavuttanut sen tason. Joka viidennes on saavuttanut prosessitason ja yksi kymmenestä palvelutason. Yksi henkilö vastasi 5 joka tasolle.

Johtopäätökset

Tulos on mielenkiintoinen monella tavalla. Tämän mukaan noin puolet it-yksiköistä ei ole päässyt yli teknologiakeskeisyydestä. Mielestäni monet havainnot tukevat tätä tulkintaa.

Teknologian hallinnan tasolle on päässyt joka neljäs ja heillä on edellytykset saada prosessit toimimaan. Joka viides on prosessitasolla ja joka kymmenes päässyt yli seuraavan kynnyksen. ITIL termein 20 % on V2-tasolla ja 10 % V3-tasolla ja lähes 70 % ei ole vielä saavuttanut ITIL V2 -tasoa.

Näyttää siltä että tasoeroja ei tunnisteta. Prosessikeskeisyys ei ole sama asia kuin palvelukeskeisyys. Tämä on mielestäni ITILin kolmosversion ongelma, siitä ei käy ilmi että se kuvaa kaksi kypsyystasoa ikään kuin yhdessä. Asiakaskeskeisyyden haaste sen sijaan tunnistetaan ja valtaosa vastaajista näkee että sinne on vielä matkaa.

Tavoitteiden asetanta on vielä optimistista. Realistinen tavoite on seuraava kypsyystaso. Liiketoimintakeskeisyys tuntuu houkuttelevalta, mutta silloin tosiaankin it:n toimivuutta mitataan samalla tavalla kuin itse liiketoimintaa, siis myyntinä, kannattavuutena jne.

Jokaisen it-yksikön pitäisi tunnistaa oma kypsyystasonsa ja ulkopuolinen tarkkailija voi olla avuksi tässä. Sitten on arvioitava mikä on tarvittava kypsyys ja sen määrää asiakkaan tila. Ei ole lainkaan selvää, että liiketoimintakeskeinen kypsyystaso on oikea tavoite kaikille. Se edellyttää että it:llä on aidosti merkittävä rooli liiketoiminnassa ja näin ei ole läheskään kaikilla aloilla.

Asiakaskeskeisyys edellyttää että asiakas on halukas ottamaan merkittävän roolin it:n ohjaamisessa. Näin ei suinkaan ole aina. Palvelukeskeisyys luo myös raja-aidan asiakkaan ja palveluorganisaation välille, kuten jokainen palvelun ulkoistanut on varmasti havainnut. Voi myös pohtia riittääkö teknologian hyvä hallinta joissakin tapauksissa eli tarvitsevatko kaikki prosesseja?

Oma kypsyystaso määrittää sen, mitä pitää kehittää ja miten palvelua voi mitata. Esimerkiksi prosessien käyttöönotto takeltelee, jos ollaan edelleen vaikeuksissa teknologian kanssa. Palvelujen tason mittaaminen on vaikeaa, jos prosessit eivät toimi jne. Johtamisen täytyy myös olla vastaavalla kypsyystasolla. Kaikki tämä on helpompi sanoa kuin tehdä.

%d bloggers like this: