ITIL Practitioner critical review

This review is aimed to the ITSM professionals who know the Practitioner book and it will concentrate on some critical observations. Before I go in to the critical observation, I must say that the book was a pleasant surprise. The Guiding Principles are good; I wish I had written them myself.

Here are some problem areas:

The user versus customer discussion is an old dispute. This would have been a good opportunity to leave the ancient class-system thinking behind. The people who use a service, are the customers. If they don’t like it and walk away, the money will follow.

In many organizations there is a professional procurement organization, which handles the contractual negotiations and acts as a buying customer for the vendor. The real customers are those who need the service, but they do not get to sign the contract. It would be a major mistake to concentrate on fulfilling the procurement organization’s needs as they know very little of the real use of the service.

The danger in the user-customer differentiation is that people may start applying it in practice. Any issue reported by a mere user may become automatically low priority even though the ”user” could be the real decision maker for the service.

The problem with the old class model stands out in the Guiding Principles as the discussion on customer experience clashes very clearly with the definition of the buyer being the customer.

CSI looks almost like it has been rewritten. The seven steps are gone and replaced by an old model which I remember using back in the ´90’s. It is valid but rather heavy for normal improvement. Actually the guiding principle 2.5: Progress Iteratively is much better guidance for CSI than the CSI chapter.

The CSI chapter does mention that CSI is for small and large initiatives but the focus seems to be on the heavy side. A lot of opportunities will be missed if CSI is seen as a programme; trying to fulfill a vision; using a scientific method. Continual service improvement is more a culture than a program. It is the ability to continually make small adjustments, corrections and refinements to existing service components. It is less about visions and more like the CEO who bends down to pick some rubbish from the shop floor during a factory visit. At the end, the CSI chapter mentions it.

In my opinion the integration of CSI to normal work practices should have been more central subject.

CSF’s have been misunderstood. A critical success factor is something you need to have in order to be able to succeed. The CSF example in the book is an outcome, not a success factor: The new IT service enables sales people to spend more time with clients.

A classical book example of a success factor is to have water if you set up your operation in a desert. Water is something you must have but which is not automatically available in a desert. Here is an example, I know that Kaimar Karu is an expert on beer, so I gave him the role of a beer master.

Mr Karu has a successful micro brewery in the old town of Tallinn. He wants to build a new brewery as the capacity of the old one does not cover all demand. There are two important qualifications for the new brewery location: good water and easy access by trucks. These are the CSF’s as Mr Karu knows that he has everything else available to guarantee the continuing success. 

The key performance indicators are not related to the CSF:s. Mr. Karu knows from experience that it takes some time for the new brewery to start working on full capacity with high quality output. Therefore, the KPI is the monthly production volumes of high quality beer.

The CSF depends on the situation. In the Practitioner example let’s imagine that previously the sales staff have been too busy to attend any training. In that case, a valid CSF would be: The sales staff are willing to learn to use the new IT system. Another critical factor might be the devices the sales staff use. Let’s assume some of the staff use devices which won’t work with the new service. In that a CSF would be: The Sales staff will upgrade their devices to support the new IT system. The CSF’s and the KPI’s are not directly related. Actually the book’s CSF’s are KPI’s and the KPI’s are associated metrics.

In my experience the most common CSF in ITSM projects is management support. Without it, the project will fail.

The use of social media is missing. There is a brief mention in the header of 5.3.3.4 Short messaging systems, instant messaging and social tools. The book misses the point that social tools are quite different from the closed communication via SMS or IM. The value in social tools is that the communications are open. Other people can read the discussions and comment on them while SMS and IM are closed communications.

The social tools can be a very valuable channel of communications and it is silly that is overlooked in the Practitioner guidance.

 

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.

Pikakysely kehittämismenetelmistä

Äskeinen CSI-kysely innosti minut kysymään taas kerran kehittämisestä. Tällä kertaa minua kiinnosti miten menestystä mitataan ja onko CSI saanut jalansijaa Suomessa. Vastauksia tuli parissa päivässä 34 enkä katsonut uusintakysymystä tarpeelliseksi.

Slide1

Kehittämisen onnistumista mitataan eri tavoin. Tässä kuvassa on esitetty ensimmäisenä mainittu eli tärkein vaihtoehto. Prosessimittarit ja asiakashyöty mainitaan usein, joten jos laskee mainintoja, vaihtoehdot ovat aika tasoissa. Noin puolet mittaa vain tehtävän suorittamista ja/tai prosessimittareita. Omasta mielestäni kaikella kehittämisellä pitää olla jokin asiakashyöty ja sitä pitäisi mitata. Toki myönnän että joidenkin hyötyjen mittaaminen on mahdotonta.

Slide2

Valtaosa vastaajista näkee kehittämisen sarjana hankkeita ja vain joka neljäs pitää sitä prosessina. Olen samaa mieltä enemmistön kanssa. Kehittäminen on pääosin erilaisia hankkeita, ei prosessi.  Kehittäminen voi olla jatkuvaa ja sille voidaan määritellä käytäntöjä ja mittareita, mutta se ei mielestäni tee siitä prosessia. Havaittujen yksittäisten virheiden korjaaminen voi olla prosessi, mutta itilissä on sille jo oma prosessinsa.

Kehittäminen on vaikeaa ja kehittämishankkeet ovat erilaisia. Usein suurin haaste on saada ihmiset muuttamaan toimintatapojaan. Se tuskin onnistuu jonkun määritellyn prosessin kautta.

Slide3

Tämän kysymyksen laadinnassa tapahtui virhe. En huomannut lisätä vaihtoehtoa: Tunnen CSI:n, mutta emme käytä sitä. Jotkut vastaajat huomauttivat siitä. Ne vastaukset on tässä yhdistetty vaihtoehtoon a).

Pidän Itilin CSI:tä erittäin huonona mallina ja siksi on helpotus nähdä, ettei se ole ainakaan vielä levinnyt tätä laajemmaksi.

CSI – itilin huonoin idea

Juuri joulun alla postilaatikkooni tupsahti CSI-kysely. Kyselyn lähetti itSMF:n CSI-ryhmä  itSMF:n ja Tietotekniikan liiton nimissä. Ymmärrän että nämä työryhmät tekevät vapaaehtoista työtä ja pyrkivät viemään alaa eteenpäin. Silti päätin kritisoida tutkimusta.

Ensinnäkin, koko CSI on todella huono idea. Lainaan tässä aiemmin kirjoittamaani kuvausta siitä.

CSI tuo jatkuvan laadunkehityksen mallin ITILiin. Pink Elephantin kirjoittama kirja kuvaa seitsemänvaiheisen ydinprosessin, joka kattaa tiedon keruun. Prosessin vaiheet ovat:

1.      Tunnista kehittämisstrategia
2.      Määrittele mitä mittaat
3.      Kerää tieto
4.      Käsittele tieto
5.      Analysoi tieto
6.      Esittele ja hyödynnä tieto
7.      Suorita korjaavat toimenpiteet

Malli perustuu mittaamiseen ja analysointiin tilanteessa, jossa tietoa on yleensä liiankin paljon käytössä. Jatkuva parantaminen nähdään ensisijaisesti mittaamisen ongelmana. Näkökulma on erikoinen. Usein tilanne on toki se, että ongelmat tiedetään liiankin tarkkaan, mutta tarvittaisiin keinoja vaiheen 7 suorittamiseen. Koko kirjassa on kaksi (2) sivua, joissa käsitellään tuota vaihetta 7 eli toiminnan kehittämistä.

Pahinta kirjassa on, että se esittelee oman, päällekkäisen organisaation jatkuvalle kehittämiselle. Suositukseni on, unohda tämä kirja.

Itse kysely oli turhan pitkä, joskin tekijöiden mielestä lyhyt, vain 16 kysymystä.

Ensimmäinen asia, joka kyselyssä ärsytti, oli kysymysten pakollisuus. On virhe pakottaa vastaajat vastaamaan kaikkiin kysymyksiin. Ymmärrän toki, että on ikävää jos vastauksia tulee huonosti, mutta se on osoitus siitä että kysymykset ovat olleet huonoja.

Kysymyksistä poimin kolme esimerkkiä:.

9. Organisaatiomme kolme (3) merkittävintä CSI-haastetta *

                      CSI-tietoisuuden puute

                      Epäselvät vastuut

                      CSI-prosessin jalkautus

                      CSI-prosessin tehokkuuden ja suorituskyvyn mittaaminen

                      Monitorointi- ja raportointityökalujen puute

                      Johdon tuen puute

                      Henkilöstöltä puuttuu CSI-taitoja ja -kyvykkyyksiä

                      CSI-johtamistaitojen ja -kyvykkyyksien puute

                      Tiedonhallinnan puute

                      Muu (tarkenna)

Huonosti muotoiltu kysymys CSI-haasteista. Vaikuttaa että CSI nähdään itseisarvona. Näistä vaihtoehdoista vastaajan oli pakko poimia kolme! Mitä muuten tarkoittaa CSI-johtaminen?

12. Käytämme seuraavia palvelun parantamisen mittareita *

                      Asiakas- ja käyttäjätyytyväisyys

                      Palvelutasot, SLA-tavoitteet

                      Palvelun saatavuus

                      Palvelun luotettavuus

                      Palvelun suorituskyky

                      Toimittajien suorituskyky

                      Palvelunhallinnan prosessin noudattaminen (KPI-mittari)

                      Palvelunhallinnan prosessin laatu (KPI-mittari)

                      Palvelunhallinnan prosessin arvo (KPI-mittari)

                      Palvelunhallinnan prosessin suorituskyky (KPI-mittari)

                      Henkilöstön tyytyväisyys

                      Liiketoimintavaikutus

                      Sijoitetun pääoman tuotto / palvelun parannus

                      Muu (tarkenna)

                      Emme käytä palvelun parantamisen mittareita

Tässä kysymyksessä on outoja termejä. Mitä tarkoittaa Palvelunhallinnan prosessin laatu tai arvo? Eihän sellaista prosessia ole olemassa!

14. Mielestäni CSI-prosessimme tehostamiseksi organisaatiossamme tulisi *

                      Aloittaa CSI-prosessin työstäminen alusta

                      Luoda kehityssuunnitelma / tiekartta

                      Määrittää CSI-prosessille tavoitteet ja mitata tuloksia

                      Kouluttaa henkilöstöä

                      Käyttää ulkoisia konsultteja

                      Saada johdolta enemmän tukea

                      Ulkoistaa prosessien hallinta

                      Antaa enemmän valtaa prosessipäälliköille

Tämä on todella vaikea. Näistä vaihtoehdoista oli siis pakko valita yksi. Oma vastaukseni on: Ei mitään näistä.

Tässä ehdotukseni miten kysely olisi kannattanut tehdä kolmella avoimella kysymyksellä.

1) Miten IT-palvelun kehittäminen toimii teillä?

2) Mikä siinä on parasta?

3) Mitä asioita kehittämisessä pitäisi tehdä paremmin?

Avoin kysely on hyvin yksinkertainen ja antaa pohjaa keskustelulle. Siinä on vaikeampi epäonnistua.

%d bloggers like this: