Kehityshankkeet

Tässä tutkimuksessa kysyttiin kehittämishankkeiden onnistumisesta. Vastauksia on saatu 47 hankkeesta. Muutama vastaus on saatu puhelinkeskustelussa. Aihe oli ilmeisen arkaluontoinen ja siksi vastauksia tuli vähemmän.

Vastaajista 80% edusti hankkeen tekijöitä ja vain 20% oli hankkeiden kohteita.

Hankkeista tehtiin pääosin omin voimin n. 40%, reilussa neljänneksessä oli konsultti neuvomassa ja vajaassa kolmanneksessa konsulttien osuus oli suuri. Jatkossa tulkitsen vaihtoehdot a), b) ja c) omin voimin tekemiseksi.

Näistä vajaa puolet on onnistunut, vajaa kolmannes onnistunut osittain. Hankkeista 15 % on sellaisia, joiden onnistumista ei tiedetä koska sitä ei ole mitattu ja 12% on epäonnistunut. Onnistumisten määrään pitää suhtautua varovaisuudella, kuten kohta nähdään.

Tässä syy miksi onnistumisten osuuteen pitää suhtautua varovaisesti. Arvio hankkeen onnistumiseta riippuu suuresti keneltä kysyy. Yksikään vetäjä ei raportoi hankkeensa epäonnistuneen. Hankkeista n. puolet onnistuu kun kysytään niihin osallistuneilta henkilöiltä. Silloin kun vastaajana on henkilö, jonka työhön hankkeen olisi pitänyt vaikuttaa, onnistumisia on vain 10 %. Tässä onnistumisiksi on laskettu vaihtoehdot a) ja b). Joissakin vastauksissa annettiin useita vaihtoehtoja ja olen valinnut yhdistelmistä ”huonoimman”, näitä oli vain 10% vastauksista.

Tässä vielä tarkemmin eri tulosvaihtoehdot. Lähes 40% hankkeen kohteena olleista sanoo, että hanke on epäonnistunut, mutta sen väitetään onnistuneen, 15% osallistujista myöntää hankkeen epäonnistuneen, mutta yksikään hankkeen vetäjä ei kerro epäonnistuneesta hankkeesta.

Konsulteista ei näiden tulosten valossa ole hyötyä. Konsulttien osallistuminen ei vaikuta onnistumisiin paljoakaaan, mutta epäonnistumisten määrä kasvaa huomattavasti kun konsulttien osuus on suuri. On toki mahdollista että konsultteja on käytetty vaikeissa hankkeissa ja helpot on tehty omin voimin.

Omien konsulttikokemusteni mukaan selkeät, rajatut toiminalliset hankkeet ovat onnistuneet hyvin. Service Deskien perustamiset ja kehittämiset ovat yleensä menneet putkeen, kunhan on vältetty pahimmat virheet. Näissä hankkeissa konsultista on ollut taatusti apua, mutta toki on totta että kaikki hankkeet eivät aina onnistu. Jostain syystä kipinä ei ole syttynyt eivätkä asiat lähteneet liikkeelle.

Muiden tekemissä hankkeissa tavallisin virhe on omien havaintojeni mukaan liiallinen keskittyminen välineisiin. Työkalut eivät yksin ratko ongelmia. Ihmettelen sitä että monet ovat halukkaita ostamaan kehittämishankkeen konsultoinnin järjestelmätoimittajalta tai koulutusyritykseltä, sillä juuri ohjelmistokauppiaat helpoiten näkevät muutoshankkeet pelkkinä asennusprojekteina ja koulutusyrityksen konsulttien tehtävänä on usein koulutuksen myyminen.

Oma konsultointityylini on Pohjoisviitan filosofian mukainen, yritän opastaa oikealle reitille ja varoittaa hankkeen riskeistä. Uskon että muutokset onnistuvat parhaiten, kun oma väki suunnittelee ja toteuttaa ne.

Palvelun elinkaari

Charles T. Betz on kirjoittanut mielenkiintoisen kirjan: Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler’s Children 2nd ed.  Kirja on ennakkotilattavissa Amazonissa, huomaa ostaa toinen painos. Arvioin hänen pyynnöstään kirjan käsikirjoituksen. Kirjan monista oivalluksista yksi on jäänyt erityisesti mieleen. Betz tuo uuden näkökulman palvelun elinkaarelle.

Palvelun elinkaari on keskeinen käsite itil-kehikossa. Palveluja tulee ja menee ja niitä hallitaan palveluportfoliolla. Ajatuksena on, että palvelun tuottaja suunnittelee palvelujensa elinkaaren markkinoiden tarpeitten mukaisesti. Nopeasti ajateltuna elinkaarimalli on loistava lisäys itiliin. Pulmana mallissa on se, että it-palvelun tuottaja ei ole yleensä siinä asemassa, että kykenisi moiseen suunnitteluun. Sisäinen it ei pysty ennustamaan liiketoiminnan tarpeita ja kaupallisessa it:ssä asioista vastaavat myynti ja markkinointi, joilla ei ole sijaa itil-mallissa. Itilin kuvailema palveluportfolio tuo mieleen muinaisen Neuvostoliiton viisivuotissuunnitelmat. Keskushallinto arvioi tarpeen ja tilasi tuotannon viideksi vuodeksi kerrallaan, ei tarvinnut murehtia markkinoiden heilahduksia vaan voitiin pyörittää tuotantoa rauhassa. Ongelmana oli toki se, että malli ei toiminut. Kaupat täyttyivät tavarasta, jota kukaan ei halunnut. Palveluportfolion hallinta ei ole uskottava malli tilanteessa, jossa asiakas päättää sovelluksista tai palveluista päättävät myynti ja asiakkaat.

Betzin mukaan elinkaaria on itse asiassa neljä ja ne toimivat pitkälti toisistaan riippumatta eri tasoilla. Elinkaarien tasot ovat

  • sovelluspalvelu
  • infrapalvelu
  • teknologiatuote
  • it-omaisuus

Nimet ovat vähän hankalia, mutta niiden takana on looginen näkemys it-palvelun kerroksista. Palvelun tuottaja voi siirtää sovelluksen uuteen konekeskukseen, uuden teknologian varaan ilman, että asiakas huomaa omassa palvelussaan mitään eroa. Myynti voi luoda ”uuden palvelun” hinnoittelun ja mielikuvamarkkinoinnin avulla. Asiakkaan sovelluspalvelu voi muuttua asiakkaan näkökulmasta merkittävästi, ilman että infrapalvelu havaitsee mitään muutosta. Teknologia kehittyy ja asiakkaiden tarpeet muuttuvat. It-yksikkö ei voi ohjata kumpaakaan. Siksi itilissä kuvattu palvelun elinkaari on liian epämääräinen käsite, jotta sitä voisi hyödyntää.

Tasojen elinkaaret ovat sen sijaan riittävän täsmällisiä, jotta ne voidaan hahmottaa. Elinkaaria ei voi kuitenkaan suoraan ohjata sen enempää kuin voi estää jokea tulvimasta keväällä, vaan niiden muutoksiin joudutaan enneminkin varautumaan ja reagoimaan. IT palvelutuotannon kyky hallita näitä elinkaaria riippuu elinkaaren tasosta. Alempien tasojen muutokset ovat parhaiten ennakoitavissa, sovelluspalvelun kaikkein heikoiten, ainakin jos asiakas vastaa sovelluksista, kuten usein on asian laita.

Olen kirjoittanut samasta aiheesta myös ITSM-Portalissa

Onko itilistä tullut vitsi?

Twitter-virtani on viime päivinä täyttänyt #know11, joka on Service-now käyttäjien kokous San Diegossa. Paikalla on tuntunut olevan huomattava osa alan vaikuttajista ja hyviä esityksiä on hehkutettu. En ole nähnyt mitään vastaavaa minkään muun tuotteen tilaisuuksista. Tämä tweetti kiinnitti erityisesti huomiota. Rhett, joka kävi Suomessakin puhumassa itSMF:n tilaisuudessa sanoi näin:
Rhett Glauser
rglauserRhett Glauser
Why did a mention of the #ITIL books get the biggest laugh now in 2 out of 3 #know11 keynotes? #rhetoricalquestion
ITIL kirjojen mainitsemisella saa siis parhaat naurut eli ilmeisesti edelläkävijöiden parissa kirjoista on tullut vitsi. Ei tietenkään ole ennenkuulumatonta että eliitti ja suuri yleisö näkevät asian eri tavalla, mutta tässä asiassa ”suuri yleisö” on itilin opiskelijoita, jotka kai haaveilevat pääsystä ITSM-asiantuntijaksi eli eliittiin. On toki syytä mainita, että tilaisuuden ohjelma pyöri itil-käsitteiden ympärillä, sen sijaan parhaat käytännöt olivat itse kehitettyjä.
Mielestäni kehityssuunta on oikea, ala kehittyy ja parhaita käytäntöjä vasta luodaan.

Olen nyt EXIN Champion

Olen ollut mukana EXINin työssä kehittämässä tenttikysymyksiä ja jäsenenä Exin Professional Groupissa. Nyt EXIN on pyytänyt pienen ryhmän asiantuntijoita perusteilla olevaan EXIN Champion ryhmään, joka koostuu EXINin arvostamista alan asiantuntijoista.  An EXIN Champion is a Subject Matter Expert (SME) who has made a positive contribution to the IT industry, and who provides significant added value to EXIN. One becomes a champion upon invitation only. EXIN on alan tenttien uranuurtaja, joka aloitti testaamisen jo 26 vuotta sitten. Nimi tulee sanoista Examen Instituut, joka perustettiin riippumattomaksi testaajaksi Alankomaiden valtionvarainministeriön kehittämälle koulutusohjelmalle.

Tämä on ihan mukava tunnustus ja säästää rahaakin. Konsultin pitää osoittaa asiantuntemuksensa ja siksi näitä sertifikaatteja on tullut hankittua, mutta pelkkä sertifikaatti ei vielä takaa asiantuntemusta. Vinod Agrasala kertoo blogissaan sertifioiduista itil-osaajista, jotka eivät näytä ymmärtäneen paljoakaan opiskelemastaan asiasta. Ihan samanlaisia itil-asiantuntijoita löytyy kyllä meiltäkin. Ongelma on tunnistettu laajasti, priSM on itSMFn kehittämä uusi ”sertifikaatti”. Tarkistin että pisteiden mukaan olisin oikeutettu Distinguished Professional -tasolle. Vaatimukset eivät kuitenkaan olleet kovin kummoisia ja ilosta pitäisi maksaa $400.

You can’t manage what you can’t measure

Sitä mitä et voi mitata, et voi johtaa(hallita). Tuota väitettä kuulee toistettavan aina silloin tällöin ja usein väitteen esittäjä myy jotain mittaustuotetta tai -palvelua. Vaikka itse pidän mittaamisesta, niin on pakko todeta että väite ei pidä paikkaansa. Esimerkiksi luottamusta ja luovaa ilmapiiriä ei voi mitata, mutta niistä on pidettävä huolta. On oikeastaan iso virhe keskittyä vain mitattaviin asioihin ja mittareihin.

Tämä ei tarkoita että mittarit eivät ole tärkeitä, kaikki saatavilla oleva tieto kannattaa käyttää. Ongelmana on se, että mittaaminen on vaikeaa tai mahdotonta. Esimerkiksi asiakastyytyväisyyden mittaamisessa on paljon sudenkuoppia. Palvelun komponentteja ei voi erottaa toisistaan. Laitteet, alusta, sovellukset ja tuki ovat yksi kokonaisuus ja jokainen osa vaikuttaa myös muihin. Voit yrittää mitata niitä erikseen, mutta todellisuudessa mittaat asiakkaan näkemystä, joka muodostuu eri asioiden summana.

Palvelutason mittaaminen voi olla hyvin hankalaa. Palvelun tuottajalla on omat sisäiset mittarinsa, mutta niiden tulokset eivät vastaa asiakkaan kokemusta. Palvelun tuottajan on paras ymmärtää, että asiakkaan pettymys palveluun on tärkeämpi fakta kuin vihreätä näyttävät palvelutasomittarit.

Yhtä vaikea on mitata monien investointien kannattavuutta. ROI(Return On Investment) mainitaan usein päätöksenteon tärkeänä mittarina, mutta kuinka helppoa se on laskea, jos vaikka parannetaan prosessia. Pulmana on se, että organisaatio tekee aina useita asioita kerrallaan ja ympäröivä maailma muuttuu. Usein on yksinkertaisesti mahdotonta mitata jonkin yksittäisen toimen taloudellista vaikutusta, ja vaikka se olisi mahdollista, mittaaminen voi olla niin työlästä, ettei se ole taloudellisesti järkevää.

Viesti on siis vähän ristiriitainen. Mitata pitää, mutta pitää ymmärtää mittarien rajoitukset.

%d bloggers like this: