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 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.


You don’t improve service with mistakes.

The customer wanted to return a tire. Never mind that the Nordstrom department-store chain sells upscale clothing, not automotive parts. According to company lore, the clerk accepted the tire because that’s what the customer wanted. Newsweek 1989

I heard the Nordstrom story years ago (it is probably just a legend, there are many variations about it). Consultant have been telling stories of great service recoveries. At some point the consultants made the next conclusion: If you are perfect, customers don’t notice you. If you make basic mistakes and recover well, they can be delighted! Stuart Rance said this in his presentation few days ago and I commented that I disagree with the idea and this blog is an explanation for my comment.

Of course a good recovery is nice and may lead to short term satisfaction but solid, reliable good service is better.  I specifically disagree with the first part of the sentence and the implied idea that a faulty but well recovered service might be better. Reliability or service warranty is really important and I doubt if people stop appreciating it.

I have worked from home for almost ten years. During that time, I don’t remember a single internet service outage which would have prevented me from working. I may have needed to use my phone as a WLAN provider for a short while once or twice during these years but that backup comes from the same telco. Reading about the difficulties other people have helps me to appreciate this reliability and I definitely don’t wish any basic mistakes to happen with the service.

Some people (including me) have argued that it is not possible to delight customers with ordinary, basic services; that delighting belongs to luxury services. I disagree with my earlier opinions. An ordinary service experience can be delightful if it is well done. As always, the customer expectations are important.

We moved recently and we hired a moving company to do most of the work. I went to pick up extra 20 boxes early so that we would have time pack difficult and time consuming items like fragile glassware. The transaction went like this. I reported at their office that I had arrived to pick up the boxes. They checked the order and printed out a document for their warehouse. Then I drove to the loading bay. The guy was there already waiting with my boxes, then he came down and looked at my car and figured out how to fit the boxes. Then he loaded them in the car and I just watched. It was a smooth operation and the service clearly exceeded my expectations. I had expected to need to wait for the delivery and that I would have to pack the boxes myself.

A simple, well operated, efficient, and seamless service operation is beautiful, just like good design in an object. Of course not all customers appreciate beauty and good design as sometimes it is a matter of taste; but most people do appreciate good service even if they do not understand the hard work behind it.

So, what if nobody appreciates your beautiful service. One reason could be that your service is not as perfect as you think. There might be some elements which are not so well planned. Remember that the service provider’s view of the service is different from the customer’s. You need to consider the customer experience. (Here you need to understand that the people who use your service are your real customers, it is not relevant who pays for the service. If the customers don’t like your service and they walk away, the money will follow.) You need to study the customer journey to your service from the beginning to the end. Details are important. The ITIL Practitioner gives good advice on this: Data is not a substitute for direct observation, page 20.

There is one important element in the Nordstrom story and it is the right to make decisions at the customer interface. It was the clerk who decided to refund the tires. Don’t make recovery a management decision, give your 1st line staff to right to choose the right compensation.


















Eri palvelukanavien yhteispeli

Tein kesällä vahinkoilmoituksen OP-Pohjolalle. Kännykkä oli päässyt meriveteen ja lakannut toimimasta. Aurinkolasit päätyivät samalla kertaa meren pohjaan. Vastausta ei kuulunut. Lopulta soitin ja tiedustelin asiaa. Kohtuullisen jonotuksen jälkeen minulle vastattiin ja sain ohjeet, miten toimia. Virkailija pahoitteli, ettei sähköistä ilmoitusta oltu käsitelty ruuhkan takia.

Toimin ohjeiden mukaisesti ja täydensin ilmoitusta kuiteilla kännykän vaihdosta ja uusien aurinkolasien ostosta. Mitään vastausta ei tullut, eivätkä luvatut korvaukset ilmestyneet pankkitilille. Soitin uudestaan. Nyt en jaksanut jonottaa vaan tilasin takaisinsoiton. Se tuli kohtuullisen nopeasti, mutta olin juuri silloin katveessa. Virkailija jätti ääniviestin ja lupasi soittaa uudestaan. Sen hän tekikin. Kerroin pulman, hän tarkisti hakemuksen ja sanoi sen olevan ok. Valitteli taas kiirettä, mutta käsitteli asian saman tien ja laittoi rahat maksuun. Ne olivat tilillä seuraavana päivänä.

Periaatteessa ihan ok palvelutapahtuma, mutta siinä oli mielestäni kaksi aika tavallista virhettä. Oli ilmeistä, että OP-Pohjola suosii puhelinasiakkaita. Puhelimessa asiat hoituvat, sähköisesti eivät. Tämä vastaa aika hyvin aiempia kokemuksiani Tapiolan kanssa, joten ajattelin kirjoittaa ilmiöstä.

Jos sähköinen asiointi olisi toiminut, olisi vältetty kolme puhelua. Toimintaohjeita ei olisi tarvinnut antaa puhelimessa, vaan ne olisi voinut kopioida ohjekirjastosta. Asian käsittelyyn olisi kulunut vain murto-osa nyt kuluneesta ajasta. Sama henkilö olisi voinut käsitellä arviolta viisi asiakasta siinä ajassa mitä heiltä kului kanssani.

Oletan, että kyse on siitä, että OP-Pohjolan johto seuraa palvelumittareita, joissa puhelutilastoilla on suuri paino ja siksi henkilökunta keskittyy tuottamaan mahdollisimman hyvää puhelinpalvelua. Perusteluna on varmaankin se, että valtaosa asiakkaista käyttää puhelinpalvelua mieluummin. Tämä argumentti ei toimi. Todellisuudessa ihmiset ovat valmiita muuttamaan tapojaan nopeasti, jos uusi tapa on parempi. Muistan hyvin, kuinka hauskaa oli ohittaa jono lentokentällä, kun ryhtyi käyttämään itsepalvelua perinteisen palvelutiskin sijaan. Valitettavasti muutkin oppivat sen nopeasti.

Vakuutusyhtiöiden pitäisi tarjota sähköisillä kanavilla nopeampaa palvelua. Sähköiset hakemukset pitäisi käsitellä 15 minuutissa, johdon pitäisi olla kiinnostunut sähköisten kanavien suosiosta ja puhelinkanavan painoarvoa pitäisi pudottaa.

Vakuutusyhtiöillä näyttää myös olevan taipumus tehdä sähköisestä asioinnista mahdollisimman hankalaa. Viestit pitää tehdä heidän suljetun verkkonsa kautta ja kaikki vastaukset tulevat myös samaa reittiä. Ymmärrän toki, että luottamuksellisen tiedon lähettäminen sähköpostilla sisältää riskejä, mutta valtaosa viesteistä on täysin epäluottamuksellisia. On typerää lähettää asiakkaalle sähköposti, jossa kerrotaan, että suljettuun postilaatikkoon on tullut (tyhjänpäiväinen) viesti. Sähköpostissa pitäisi kertoa lähetetyn viestin sisältö.

Vastaavasti sähköiseen viestintään on helppo asettaa turhia rajoituksia ja ehtoja, joita puhelinpalvelussa ei sovelleta. Kyse lienee kaikkiaan siitä, että erilaiset keskijohdon jäsenet pääsevät pätemään järjestelmän määrityksissä, ja asiakasnäkökulma unohtuu.

Waste of effort

IMG_1615I had an interesting discussion with Mark Smalley when he was visiting Helsinki. We discussed the value of data on the ferry to Suomenlinna island.

System architects like to create beautiful models of operations. The models are based on information that moves between components. The model runs like a clockwork, but the problem is that the data entry is manual. It is quite easy to make mistakes while entering the data and there is no mechanism that corrects the mistakes. Soon the system becomes tainted. As Mark put it, it is like mixing wine and dishwater. Adding a little wine to dishwater doesn’t change the nature of dishwater, but adding a little dishwater to wine certainly does.

There are two major activities that include a lot of manual data entry in ITSM: incident and configuration management. Both suffer from this data quality problem.

In incident management the staff typically add service and configuration information to the ticket. The problem is that in many cases they do not have the required information and therefore have to guess. The result is like dishwater in wine. Nobody trusts the incident data and the reports based on it are therefore generally worthless.

In configuration management all changes must be recorded in the CMDB. It takes a lot of effort to build and maintain the CMDB. Unfortunately, it takes very little effort to ruin the system. Imagine a person making an emergency change at 5 AM to solve a major system outage. After a successful operation, he goes home to sleep. The next day he updates the CMDB but makes a mistake or forgets something. Then people stop trusting the CMDB data, they realize that they need to check the actual situation to be sure. After that it becomes less important to record the changes.

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.

Don’t try to compare ITSM metrics.

It is a waste of time to try to compare typical ITSM metrics. All depends on the definitions and these can vary a lot. Here are a few examples where the same reality but different interpretation.

Number of incidents:

Case A: All user calls are logged as incidents. There are of 10.000 incidents per month.

Case B: Service requests and incidents are logged separately. There are 7.000 service requests and 3.000 incidents per month.

Case C: Some events are logged as incidents. Event management generates 10.000 incidents per month. There are 7.000 service requests and 13.000 incidents per month (or no service requests and 20.000 incidents).


Successful changes:

Company has 200 components which it decides to upgrade. The components are in 10 locations in racks of 20 components. It turns out that four new components fail and need to be replaced.

Case A: There are 200 changes with 98% success rate as each component is considered to be a separate change.

Case B: There are 10 changes with 60% success rate as each rack is considered to be a separate change and all failures occur in different racks.

Where is the customer?

Imagine that you come to a hotel and find a Service Desk where a cheerful person assures you that if there is any incident with your room, one of the service specialists will start fixing it within twenty minutes. Behind her, you can se some plumbers, electricians and carpenters ready with their tools, waiting for the next incident. Wouldn’t you want to find another hotel?

The early years of computing were difficult, technology was new and unreliable. It was understandable that incident management was important. But it is a bit silly that customer service is still missing from current ITSM or that it is so technology centric.

This technology centric view of service can be seen in graphs that describe the support processes. In most cases that I have seen, there is no customer service and actually no customer. It is far more likely to find a CMDB or a service catalog in the center of the picture than a customer. The same thinking seems to carry over from ITIL to all other frameworks, standards and methods. Customer service is seen as the restoration of service after an incident.

The technology centric thinking comes with a price. A lot of effort is lost. Incidents need to be connected to the relevant configuration items and services. Many of my customers have configuration management systems and service catalogs but the logging of incidents with service and configuration information provides no value. My major subject in university was statistics and when I started ITSM consulting I was thrilled that I could start analyzing incident data and find valuable information for my customers. That has never happened. Yes, I have analyzed incident data a few times but every time the data has proven to be rubbish. Garbage in, garbage out is a good rule in statistics.

The ITSM thinking should put the customer in the middle and ask the question how does this process or value stream produce value to the customer. I think that the customer centric framework for ITSM would look completely different.

%d bloggers like this: