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

Discussion: Definition of Service and Service Catalogs

 

This is a discussion between Aale Roos and Aki Lähteenmäki. We met some time ago and we discussed ITSM matters. We got to know each other many years ago when Aki attended ITIL Service Manager course where Aale was the a trainer. Aki has worked previously in his career in tool & process consultancy roles in various companies. In 2014 Aki started a consulting company www.justin.fi with his colleagues. Aale is internationally recognized expert on ITSM and Service Desks. Aale has his own consultancy company pohjoisviitta.fi.

We share a common view that ITSM is yet quite immature and there is a lot of work ahead in improving models and practices. Our different backgrounds give us different viewpoints on possible solutions.

We decided to have a written dialog about some areas where we see major problems in current practices but are not quite sure what would be the right approach. We do this in English in the hope that other people might find this approach useful

Aale1

The subject of this blog discussion is the Service Catalog for the internal IT. It is a key concept in ITIL and in IT service management but there is silly problem in it. ITIL books state that service is A means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.

 That is obviously not true for most IT organizations. A typical corporate IT is part of the corporation which is the customer, so it definitely does not free the customer of the ownership of the risks and costs of the IT infrastructure it owns.

So this leaves us with two choices:

  • either the concept of service is right and then internal IT is not a service provider
  • or the definition is wrong,

The first choice is quite interesting but not very useful for our discussion.

I have come to the conclusion that it would be better to stop talking about service and assuming that everybody understands it the same way. It is a better idea to split the term in three parts: promise, act and system.

  • Service promise is what we promise to do, it is not necessary very detailed
  • Service systems are all the systems we operate or buy on behalf of the customer. Service systems may contain hardware, software, processes, people, resources etc.
  • Service acts are what the customer gets. They fulfill the promises and they are the results of the service system working.

What do you think about this model, Aki?

Aki 1

I agree with you that ITIL definition is applicable only for certain cases and therefore it is not good way to describe what generic term “service” means.

I have used to understand term “service” as generic term for something which brings value for service consumer. In this context consumer can be service end user, other company, service provider’s organization or even service organization itself.

Depending on the case, service can be “pure” service like IT Service desk which provides support for service users or it can be combination of services and products. For example “Workspace service” can contain certain set of available/orderable products like workstations, mobile devices or software. Same service can contain services like service desk, control desk (monitoring), etc.

So therefore there is different kind of services and maybe we should make definitions for those instead of trying to resolve service definition problem?

For example: We could have definition for:

Service package (containing different services and/or products)

Customer facing service (service visible for customer, can contain service package(s) and defines e.g. SLA for the specific customer)

Supporting service (IT providers internal service which is not visible for service consumers but is necessary, critical enabler for service delivery, e.g. service platform backup or monitoring service)

Etc.

What comes to your idea about those three dimensions; promise, act and system, I like it. But what does it mean in practice, from service definition point of view, Aale?

Aale 2

Writing a service definition is hard. The problem is that all the different service definitions you described still contain the word service. It is difficult to avoid it.

The split in three elements makes it a bit easier. For example, I would say that a Service Desk is three things:

  • a promise to help in all kinds of problems and questions regarding the IT infrastructure
  • a system with people, processes and tools
  • an act of responding to a customer and finding a solution to the customer’s problem

I think the benefits come when you create service catalogs. While there would be three of them, they should be easier to create. Could you try this approach just as a thought experiment, Aki?

Aki 2

I think I understand what you mean by this “PSA” model. If I try to combine your approach and portfolio thinking I have used to use, I can find at least two options to mix those:

PSA service model:

a promise -> Customer facing service which defines agreed price/costs elements, SLAs, other service content and commitments (between service provider and service consumer)

a system -> Supporting service, containing all necessary people, processes, knowledge and tools to deliver services.

an act -> can be process activity or CI/Asset fulfilling the promise defined in customer facing service.

PSA1

Or PSA model as service modelling matrix:

table
For me that is the perfect match! What do you think Aale?

Aale 2

Aki, I think we are pretty close. But remember that all customer facing services are based on service systems too. The difference is that some service systems are visible to the customer and some become visible only if they fail. There are usually many service systems behind one promise. There can be also many acts.

Aki 3

Well in my mind service system is system of people, processes, tools and knowledge which will produce and deliver tasks, activities and service assets like business applications, servers, workstations, workstation software, etc. But I think tools & technology used as a part of service systems should be part of the supporting services (service system).

PSA2

How does that sound, Aale?

I also started to wonder where in this picture external vendor’s are? For example software/hardware vendors or outsourcing partners? Can supporting service describe external actor’s service as well?

Aale 4

I like your picture Aki. I had never thought that an asset like a laptop would be a service act but of course it is.

Let’s take an example. The IT provides workstations including laptops, tablets etc. to the corporate customers. This service has a price list and a promises of service quality. For example, customers are guaranteed that if their device is broken, it will be replaced within two hours.

IT outsources the procurement, installation, delivery and maintenance of all devices to vendor ZZZ. The IT provides service desk, network, email, backups etc.

Now there are several customer facing service systems within one promise. The service desk and the device delivery are service systems under the service promise. Then there are also many supporting service systems like network, backup servers, device and software procurement which are not usually visible to the customer.

Aki 4

Good! So it looks like that it is possible to mix your PSA model and service portfolio modelling thinking successfully. PSA model provides nice framework to identify service type and purpose in service ecosystem. Service portfolio modelling enables concrete understanding how services can be defined in support tool as a configuration items or other service records.

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: