Trust is the solution

It is a common practice to measure incident resolution times and have SLA limits for different priorities. For example, a typical SLA can state that 90% of priority level 2 incidents must be resolved within 8 business hours. One complication is that sometimes resolution must wait for some information or third party act. Usually this waiting time is subtracted from the resolution time which means that the actual resolution time can be anything but be still within the SLA limit.

Another problem is the priority. It is hard to define the right priority and sometimes there is a need to change the priority as there is more information available concerning the nature of the incident. There was recently a discussion on the subject of changing priority where I commented that I consider the whole concept to be a bad ITIL practice. A few commentators disagreed. One person wrote:

… I very much disagree regarding ”bad practice”. Without a measurement for timing – and logically, the timing to resolve something more damaging would be shorter – one has only chaos and is at the mercy of whoever decides timing was not what it should have been.

 In this article, I will explain the reasons why I consider it as a bad ITIL practice and what would be a better practice. The above comment is basically right; it makes sense to measure timing and it is true that important matters should be resolved faster. I disagree that it leads to chaos if customers can decide what is the right timing. But this is not the real problem, the core problem lies in the SLA connection. When resolution times are set as a SLA target the timing easily becomes dominant and it will override common sense and customer value.

Any metric can be harmful if it used incorrectly. Usually management wants to have numbers and easily defined targets but metrics can be toxic.

Road side speed measurements do not show high speeds, if they did, some drivers would try to get record numbers and the safety measure would become a source of danger.

Firstly, the measurements are very easy to manipulate. If you haven’t seen cases where all SLA’s are met but customers are quite dissatisfied, you do not know much about real life in ITSM. It is far too easy to play with the measurements as so many things are hard to define. Here are some techniques:

  • ask difficult questions from the customer and stop the clock while they try to answer the questions
  • give low priority to difficult cases, or change the priority if the deadline approaches
  • classify more automatically generated events as incidents and solve them fast

All these tricks will help to fulfill the SLA promise without providing any value to the customer.

The second major problem is the setting of priorities. It is difficult and usually there are simple rules, which give a ticket a priority based on the affected service. The given priorities do not necessarily reflect the true business value related to the case. One thing is sure, any mechanical, automatic priority system will fail.

Here is an example, I’m sure many have seen similar cases:

IT service provider ITSP has a culture of fast responses and close cooperation with their customers. They know when they need to drop everything and jump to prevent a potential failure. They have processes and use a ticketing system to make sure that things are not forgotten, but they are not orthodox about it and do not always create tickets. They have no SLA’s.

 One day ITSP management decides to implement best practices. All incidents need to be handled following SLA requirements and it is a severe error to let SLA times slip.

 So, when next time there’s a potential failure, the IT staff concentrate on following orders and refrain from jumping to prevent the failure. The staff closes a group of minor tickets which are close to breaching the SLA limit before they start working on the major failure and resolve it just within the SLA.

 Everything is ok, there has been no SLA breaches but the customer is mad because they could see that the IT people were closing insignificant tickets while their business ground to halt due to a major IT failure which was waiting.

The solution to the priority and SLA problem is simple; trust. If you can trust your service provider, you do not need to set SLA penalties. If you can trust your staff to make good decisions, you do not need rigid prioritization.

This far from easy, trust needs to be earned and it is easy to lose it. On the other hand, it is very rewarding and it is good for business.

 

ITIL Practitioner pähkinänkuoressa

ITIL Practitioner on uusi julkaisu ITIL sarjassa. Se on kädessä ilahduttavan kevyt, vain 112 sivua ja liitteet. Sisältö on kuitenkin painavaa.

Kirja alkaa lyhyellä johdannolla, jossa avataan keskeisiä käsitteitä. Nämä ovat osin perinteistä ITILiä, mutta pohdinta on parempaa ja arvon merkitystä korostetaan.

Ohjaavat periaatteet

Kirjan todellinen helmi on sitten 2. kappaleessa. Guiding principles eli ohjaavat periaatteet luettelee 9 periaatetta, joiden mukaan pitää toimia. Periaatteet ovat:

Keskity arvoon. Kaikin toiminnan pitää kytkeytyä asiakkaan saamaan arvoon. Asiakas on arvon määrittäjä ja toiminnan kehittämisen pitää tähdätä tuotetun arvon lisäämiseen.

Toki tämän pitäisi olla itsestään selvää mutta prosesseja kehitettäessä on helppoa unohtaa arvo ja sen mittaaminen ja näin on usein käynyt.

Suunnittele asiakaskokemus. On tärkeää suunnitella asiakkaiden ja käyttäjien kokema palvelu.

Palvelujen asiakaskokemuksen suunnittelu on nopeasti kehittyvä ala ja oli ITILin kannalta noloa, että ITIL kirjat ohittivat sen täysin. ITIL Service Design käsittelee kaikkea muuta kuin palvelumuotoilua. Tämä on merkittävä näkökulman vaihto.

Aloita siitä missä olet. Tämä periaate kehottaa välttämään vanhan hylkäämistä ja puhtaalta pöydältä aloittamista.

Työskentele kokonaisvaltaisesti. Mikään palvelu tai komponentti ei toimi yksin. Asiakkaan saama arvo kärsii, jos palvelun tuottaja ei katso kokonaisuutta vaan keskittyy joihinkin osiin. Parhaat tulokset saadaan, kun koordinoidaan laitteita, ohjelmistoja, tietoa, prosesseja, arkkitehtuureja, mittareita, työkaluja, henkilöstöä ja partnereita.

Tämä on aika iso suupala, varmasti oikea ohje mutta hyvin haastava.

Etene pienin askelin. Suuret hankkeet täytyy toteuttaa pala kerrallaan iteroiden. Näin on helpompi säilyttää selkeä kuva asioiden etenemisestä.

Havainnoi suoraan. Jotta tiedät missä mennään, havainnoi ja mittaa tapahtumia suoraan. Varmista että päätökset perustuvat mahdollisimman luotettavaan tietoon.

Tämä on erinomainen ohje. Tutkiminen ja tulosten tilastollinen käsittely on haastavaa, suorat havainnot ovat hyvä keino lisätä ymmärrystä palvelusta ja sen elementeistä.

Ole läpinäkyvä. On tärkeää toimia avoimesti. Toiminnasta ja sen kehittämisestä pitää kertoa kaikilla mahdollisilla kanavilla.

Tee yhteistyötä. On tärkeää tehdä yhteistyötä ja olla aktiivinen yhteistyökumppani. Tämä on oikein ja tärkeä asia, mutta tässä vaiheessa minua alkaa tosissaan ärsyttää kirjoittajien tapa ohittaa sosiaalinen media työkaluna. Kirjan mukaan yhteistyö edellyttää kokouksia, olen osittain eri mieltä.

Yksinkertaista. Tämä on hyvä ohje, kuten kirjassa sanotaan, kokemukset osoittavat, että näin ei yleensä toimita. Olen itse ajatellut viime aikoina, että omaa konsultointiani voisi alkaa kutsua yksinkertaistamiskonsultoinniksi. On hyvin tavallista, että asioita tehdään liian monimutkaisiksi. Usein syynä voi olla oman osaamattomuuden piilottelu sanahelinän taakse.

Jatkuva kehittäminen (CSI)

Jatkuva kehittäminen on tärkeä toimintamalli, jolla palvelut pidetään kunnossa. CSI esiteltiin ITILin kolmosversiossa, mutta sen toteutus oli erikoinen. Nyt lähestyminen on toimivampi, joskin aika raskas. Enää painopiste ei ole mittaamisessa, vaan muutoksen aikaansaamisessa. CSI nähdään eräänlaisena strategiaprosessina, joka lähtee visiosta ja pyrkii kuvaamaan strategiset askeleet vision toteuttamiseen.

CSI luvun viimeinen kappale on tärkeä, se käsittelee CSI:n integroimista normaaliin toimintaan. Mielestäni onnistunut CSI on enemmän kulttuuri kuin ylhäältä johdettu muutosprosessi.

Mittarit ja mittaaminen

Tässä luvussa minua hiukan häiritsee termin CSF käyttö. Critical Success Factor. Se määritellään asiana, joka pitää saavuttaa. Oppikirjan mukaan CSF on asia, jota ilman ei voi menestyä. Esimerkiksi, jos päätät sijoittaa suunnittelutoimiston Saimaan saareen, toimiva tietoliikenneyhteys ja luotettava sähkö ovat varmasti kriittisiä menestystekijöitä. Kirja kuitenkin esittää CSF:t tärkeiksi tuloksiksi, jotka pitää saavuttaa. Niiden oikea nimi on menestymiskriteeri, success criteria, Niitä mitataan suoritusindikaattoreilla, Key Performance Indicators KPI.

Kirjassa on hyvä, kriittinen ote huonojen mittareiden riskeihin ja kirja suosittelee tasapainoista lähestymistä.

Kommunikointi

Kommunikointi on uusi asia ITILissä ja on hyvä, että sen merkitys tuodaan esiin. Käsittely on melko yleistä ja pinnallista. Tämä luku on kirjan heikoin. Varsinainen pohjakosketus tulee kuuden rivin mittaisessa kappaleessa 5.3.3.4 Short messaging systems, instant messaging and social tools. Siinä siis rinnastetaan SMS ja sosiaalinen media. Kirjoittajalle molemmat lienevät vieraita. Minulta kesti hetken edes tajuta, että short messaging systems on SMS, olisiko siitä jo vuosikymmen kun viimeksi olen nähnyt termin avattuna.

On outoa, että vaikka kirjoittajien joukossa on henkilöitä, jotka ovat hyvin taitavia sosiaalisen median käytössä, se käytännössä ohitetaan kirjassa muutamalla hyvin pinnallisella kommentilla.

Toiminnan muutos

Tämä on erittäin tärkeä lisäys muutoksen hallintaan. Organizational change management tunnustaa, että on olemassa erityyppisiä muutoksia ja että toiminnan muutoksen hallinta on suuri haaste.

Kirja kuvaa erilaisia malleja ja käytäntöjä muutoksen aikaansaamiseen. Teksti on pitkälti lainauksia alan huipuilta.

ITIL Practitioner on hyvä kirja, siinä on enemmän viisaita neuvoja kuin aiemmissa viidessä ITIL raamatussa yhteensä. Käytännössä se kumoaa suuret osat aiemmasta ITIL-opetuksesta, joskin ITIL kouluttajat ja konsultit tuskin tätä myöntävät. Kirjan suurin virhe on sosiaalisen median ohittaminen.

 

 

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.

 

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.

ITIL managereille potkut

Pidin viisi vuotta sitten esitelmän ”Unlearning ITIL” Espoossa (eri nimellä), Lontoossa ja Canberrassa. Sen keskeinen sanoma oli, että ITILissä on vaarallisia vikoja ja ihmisten pitäisi torjua ITIL suurelta osin, unohtaa kurssilla opitut asiat. Esitys herätti aikalailla vastustusta, mutta sain myös paljon kiitoksia kuulijoilta. Olen jatkanut saman viestin kertomista osana useimpia esityksiäni sen jälkeen. Nyt viimeinkin alkaa näyttää siltä, että myös päättäjät ovat heränneet näkemään ITILin ja muiden raskaiden ja byrokraattisten menetelmien haitat.

Charles Betzt puhui eilen Hollannissa Service Manager konferenssissa ja kertoi uutisia USAsta.

potkut itil

Tulkintaa lyhenteistä: PMO Project Management Office, BRM, Business Relationship Managers, BA, lienee Business Administration, COE Center Of Excellence.

Ilmeisesti DevOps on nyt uusi hopealuoti ja lienee varmaa että myös sen tuloksiin tullaan pettymään. Joka tapauksessa ITILin tulevaisuus näyttää olevan vaarassa. Nyt viimeistään kannattaa ottaa kovalla työllä hankitut ITIL sertifikaatit pois näkyvistä.

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.

%d bloggers like this: