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.

%d bloggers like this: