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 box your thinking

I have seen several examples where people are locked to old thinking in ITSM. That happens to all of us and not just in ITSM. Old thinking habits and beliefs are hard to change.

One important source for artificial limits in thinking can be a framework like ITIL. I have commented on this in a few discussions on Back2ITSM and LinkedIn but I want to discuss this a bit more seriously as Bart van Brabant asked.

It seems that many practitioners are hampered by ITIL models and concepts and waste their time in trying to fit reality in an ITIL box. These barriers are completely artificial and should be removed.

Here are some examples:

ITIL does not handle feedback well. It is clear that customers will give feedback via various channels and it is valuable information which should be collected. Do not waste time in trying to fit it in ITIL processes, feedback is not incidents or requests.

ITIL does not describe production. It is the nature of production to change things. Production can be a bit messy, especially if humans are involved. Do not use change management in normal production work, David Nottingham.

Incident-Problem model is very primitive. When a customer has a problem, he wants to have a solution to the problem. This is not the same as restoration of service. You need to fix the customer and you need to fix the service and these are two different things.  When you fix the service, you need to do it well, not just hash it and leave it to Problem management for proper fixing.

The whole idea of Problem Management as a process is wrong. The activity is risk management and problem solving is a capability.

ITIL service definition describes leasing or renting. Leasing is a simple service which can easily be described in a service catalog. IT services are much more complex. You need to manage service proposals, service systems and service acts. ITIL won’t guide you there.

If your IT service has huge amounts of incidents and most of your energy goes to restoring service it is clear that the root cause is incompetence. The best solution is not implementing ITIL but to fire the staff and outsource the service. Contact James Finister. (I won’t say no to finders fees, James 😉

ITIL was a great idea and it has helped many of us to understand ITSM and see some basic structures in the field. Now you must move forward. There are no simple solutions in a box or book. Do not look for a new ITIL.

What did I get from itSMFest?

Well, I didn’t leave empty handed as I got a nasty flu which has kept me pretty low for almost a week, but was there something else too? I think there was a vision about the future; it was not clear but it sure was not this beautiful Soviet era ad that was lying on tables there 🙂  RTIE-300

The Estonian Conference was again good. Kaimar Karu had invited an interesting crowd of speakers and the one day, one stream concept is powerful but it has grown too popular for the venue. As I came in a bit late, I had to sit in the back where sound quality was bad and slides invisible, especially those with small text.

Adrian Cockcroft was for me one of the most interesting speakers. He spoke about his experiences with Netflix and I picked a few points from him:

–  “Don’t do undifferentiated heavy lifting” i.e. don’t do anything heavy standard stuff. There are specialized companies for that.

– “Organizations build slow, complex scar tissue processes” when they should be lean and fast.

We were saved from ITIL sessions, the only session which could have been one was done by my favorite ITIL skeptic, Stuart Rance. (Now I can see Stuart reaching for his quill and ink, or more likely his iPhone as he does not consider himself as a skeptic but actually he is). Stuart started his presentation by asking who of us think that CSI is a stage in the service lifecycle or a process or a model. Then he explained that it is about attitudes, behavior and culture.  So, bye bye 7-step process.

Many speakers had as their key message to concentrate on what brings value and forget the processes. Patrick Bolger smashed the ITIL tool certifications to pieces, and both he and Bartosz made fun of the full ITIL process chart. Bartosz Gorczynski gaves us a presentation about how to guarantee failure in an ITSM project. It was really funny and so real. I was attending a tools workshop in last September, where the consultants were trying to follow almost all Bartosz’ advice to the letter.

Tobias Nyberg spoke about problems and he also had a fresh, non-process approach. Paul Wilkinson did his ABC sermon and it became clear how the same message came up in many presentations.

I told Paul that I had a lovely real life example of the ABC problem which happened last week. A customer of mine had a minor catastrophe, which might have been much worse. After it had been worked out she said that finding the root cause is not the point. “We know exactly the root cause and we have described the solution before but it just happens again.”

I had a surprise visit to the stage, Kaimar asked me to join a group of people to answer audience’s questions. People had been asked to write their questions so I was able to have peek at them before the start. Some of them were quite hard. I wrote down some of my answers beforehand:

How to start?

  • talk with the customers

What is your best advice?

  • listen to customers

How to influence management

  • use customers voice/message

Stephen Mann talked about commercialization of services which is a good insight. The internal IT competes with web services and it is not an easy race. Kaimar himself ended the conference and left me a tiny bit disappointed. We heard nothing about the future of ITIL.

So what was the vision and message. I´d say it is this: New technology happens fast and IT needs to be prepared to help business with it. There are no easy solutions or simple models, you need to know what creates value and how it is done. You are in a race and the people are the problem and the solution. But you cannot win without good technology.

The full set of presentations are available here http://konverents2014.itsmf.ee/program

Ongelmat

Löysin twitter-arkistosta vanhan twiittini syyskuulta 2009: It was fun to explain the concepts of incident, problem, error KE to a class who had not heard the terms before. They have power! Eli olin selittänyt insidentin, ongelman, virheen ja tunnetun virheen käsitteitä kurssilla ja saanut innostuneen vastaanoton. Nuo käsitteet selkeyttivät monia asioita ja ihmiset tajusivat havaitsemiaan ilmiöitä käsitteiden avulla. Ne auttoivat jäsentämään omaa työtä ja olivat siinä mielessä hyödyllisiä.

Jos määritelmät ovat unohtuneet, niin kertaan niitä tässä nopeasti. Itilin määritelmän mukaan ongelma (problem) on yhden tai useamman häiriön (insidentin) tuntematon perussyy (root cause) ja error tai known error on sitten tunnistettu virhe, joka aiheuttaa insidentin.

Kun itiliä kirjoitettiin, havaittiin että usein häiriöiden korjaaminen vei niin paljon aikaa, ettei niiden syihin ehditty puuttua. (Kun itse olin asiakaspalvelun päällikkö, huomasin että usein syynä ei ollut mikään kiire, vaan ennemmin laiskuus.) Tämän takia päätettiin luoda erillinen ongelmanhallinnan prosessi eli Problem Management. Prosessi osoittautua vaikeaksi ja se sai monta erilaista ja väärää tulkintaa. Ongelmanhallinnasta tuli usein vain tapa käsitellä vaikeita häiriöitä. Versio 3:n kirjoittajat kirjoittivatkin prosessin uusiksi havaitsemiensa käytäntöjen pohjalta eli kirjasivat väärinkäsitykset uudeksi parhaaksi käytännöksi. Tämä sitten korjattiin vuoden 2011 versiossa, mutta lopputulos ei onnistunut vieläkään.

Itilin ongelmanhallinta on epämääräinen käsite. Pohjimmiltaan ongelmanhallinta ja häiriönhallinta ovat samoja prosesseja ja tekevät samoja asioita. Tämä on resurssien tuhlausta ja sotkee toimintaa. On aivan selvää että yksi prosessi riittää häiriöiden ratkomiseen.

Olen aiemmin tässä kirjoitussarjassa erottanut asiakkaan ongelman ja häiriön toisistaan. Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Häiriö on tilanne, jossa joku asia ei toimi halutulla tavalla. Häiriö voi aiheuttaa asiakkaan ongelman, mutta ongelmia voi olla ilman häiriöitä. Häiriön korjaamisen pitää ulottua myös häiriön aiheuttajien käsittelyyn. Emme missään nimessä tarvitse erillistä prosessia vaikeiden häiriöiden korjaamiseen, on vastuutonta toimintaa palauttaa vain palvelu takaisin selvittämättä miksi se häiriintyi.

On selvää, että palveluja pitää kehittää. Tunnetut viat (Known Error) ovat jokapäiväinen ilmiö. Kaikkia vikoja ei kannata korjata. Asiakkaiden ongelmia voi myös ilmetä ilman minkäänlaisia häiriöitä eli asiakas joutuu ongelmiin vaikka palvelut toimivat aivan oikein. Häiriöt voivat toistua vaikka niiden aiheuttajat on korjattu.

Itil tarjoaa liudan ”prosesseja” palvelun kehittämiseen ongelmanhallinnan lisäksi, löytyy jatkuvuuden hallinta, kapasiteetin hallinta tietoturvanhallinta ja tietysti jatkuva palvelun kehittäminen. Jos siis äkilliset tilantarpeet aiheuttavat palvelukatkoja ja tietoturvariskejä niin mikä ”prosessi” ottaa vastuun?

Ehdotan, että nämä kaikki korvataan yhdellä prosessilla. Riskienhallinta on tarpeellinen, suorastaan välttämätön toiminta, joka tunnistaa riskit ja valitsee niiden käsittelytavan. Lisäksi kaikilla organisaatioyksiköillä ja jopa henkilöillä pitää olla vastuu palvelun kehittämisestä. Jokaisen pitää tarttua havaitsemiinsa mahdollisuuksiin parantaa palvelua.

Mielestäni siis ongelmanhallintaa ei tarvita. Se voidaan korvata riskienhallinnalla. Service Deskin vetäjällä ja kaikilla prosessipäälliköillä on vastuu olla aktiivisesti mukana palvelun laadun kehittämisessä.

Onko ITIL syvältä?

WordPress näyttää milllä hakusanoilla joku on löytänyt Pohjoisviitan sivut. Luettelossa on parin päivän ajan pistänyt silmään lause ”itil on syvältä”. En ole käyttänyt tuota sanontaa koskaan aikaisemmin, joten haku on tullut tänne todennäköisesti vain sen takia, että olen kirjoittanut aika paljon itilistä suomeksi. Jäin miettimään mitä tuohon vastaisi. Tietyissä olosuhteissa väite on täysin väärä, jossakin tilanteessa taas voin olla samaa mieltä.

Aluksi olin sitä mieltä, että itil on hyvä ja tarpeellinen. Sitten kolmosversio epäonnistui pahan kerran ja itil paisui mahdottomaksi möhkäleeksi. Lisäksi kolmosversiossa oli paljon typeriä virheitä. Nyt olen alkanut kyseenalaistamaan myös alkuperäisen itilin hyötyä. Tämä johtuu osin siitä, että maailma on muuttunut itilin ympärillä. Vanhat 1980-luvun mallit eivät enää istu niin hyvin kuin ennen. Sinänsä mallin ikä ei ole yksinään mikään syy hylätä sitä, mutta itilin tapauksessa käytännöt ovat muuttuneet liikaa. Vanhan mainframe-maailman opit eivät ole tätä päivää.

Mielestäni itil, siis kakkosversio, edustaa yhtä kehitysvaihetta. Kun IT-yksikkö laskeutuu puusta, se tarvitsee itiliä. Itil on parempi kuin ei mitään. Kun itil on hyödynnetty, pitää siirtyä eteenpäin.

Itil puhuu monista hyvistä asioista, mutta sen ratkaisut eivät ole läheskään aina edes käyttökelpoisia. Silti mielestäni IT-ammmattilaisen yleissivistykseen kuuluu tuntea Itil ja ISO 20000. Peruskurssi tai itseopiskelu riittää.

Itilistä on tarjolla runsaasti jatkokursseja ja sertifikaatteja. On huolestuttavaa, jos niiden opiskelija ei tajua viimeistään kolmannen kurssin kohdalla, että itil-koulutusohjelma tosiaankin on syvältä.

Tarvitsetko palveluluettelon?

Kirjoitin service desk-järjestelmän turhasta monimutkaisuudesta  ja olen käynyt siitä keskustelua eri kollegoiden kanssa. Aluksi ajattelin, että itilin CMDB-palvelu-SLA malli (eli malli joka kytkee palvelusopimukset palveluluettelon kautta konfiguraatiotietoihin) aiheuttaa vain tarpeetonta monimutkaisuutta service desk-järjestelmiin. Keskustelujen perusteella olen päätynyt siihen johtopäätökseen, että palveluluettelon ja palvelusopimusten laatiminen itilin oppien mukaan voi olla turhaa ja jopa haitallista. Alleviivasin sanan ”voi”, koska itilin malli toimii joissakin tapauksissa. Parhaiten se toimii silloin kun sekä ostaja että myyjä ovat it-ammattilaisia. Valitettavasti it-palveluja tarvitsevat henkilöt eivät yleensä ole alan ammattilaisia. Valaisen asiaa esimerkillä.

Matkustajalaiva on monimutkainen palvelujärjestelmä. Se on suuri hotelli, jossa on useita ravintoloita, baareja, kauppoja jne. Lisäksi se on kulkuväline. Laivaa pyörittää organisaatio, jolla on kolme päätehtävää:

  1. kapteeni vastaa laivan kuljettamisesta ja turvallisuudesta
  2. purseri johtaa hotelli- ja ravintolapalveluja
  3. konemestari vastaa laivan tekniikan ylläpidosta ja valvonnasta

Lisäksi maissa on varustamon johto, myynti ja markkinointi. Strategiset päätökset tehdään siellä.

Kaikki laivan toiminnot ovat riippuvaisia tekniikan toimivuudesta, mutta niiden kriittisyys vaihtelee ajankohdasta riippuen.

Kuvittele nyt, että laivan konemestari saa itil-herätyksen ja alkaa rakentaa palveluluetteloa. Hänellä toki on varmasti olemassa hyvä kuvaus laivan konfiguraatiosta, mutta mieti miten ja kenen kanssa hän voisi neuvotella palveluluettelosta ja vaikka ilmastointilaitteiden SLA tavoitteista! Ei purseri tai edes kapteeni osaa ottaa kantaa joidenkin teknisten viritysten vaikutuksiin. Laivan palvelujen elinkaari ei ole mitenkään kytköksissä laivan tekniikan elinkaareen. Laitteita huolletaan ja korjataan tarpeen mukaan, mutta laivan palvelut kehittyvät niistä riippumatta. 

Jos laivan konemestari kuitenkin on luja uskossaan ja painostaa purserin tekemään palvelutasosopimukset, tilanne todennäköisesti vain kärjistää suhteita laivalla. Jos purseri esimerkiksi valittaa että keittiön liesituuletus on puutteellista ja sen johdosta ravintolaan tulee ajoittain käryä, niin konemestari voi mitä suurimmalla todennäköisyydellä vakuuttaa tuuletuksen täyttävän palvelutasovaatimukset.

Mitä siis pitää tehdä, jos palveluluettelon laatiminen tuntuu vaikealta ja/tai liiketoiminnan kanssa on vaikea löytää yhteistä säveltä? Mielestäni kannattaa unohtaa itilin opit. Palveluluetteloa ei vain voi laatia niin, että se kytkeytyisi liiketoiminnan palveluihin. Kyse on pitkälti ammattitaidosta. Tekniikasta vastaavan henkilöstön pitää osata huolehtia vastuullaan olevista järjestelmistä ja heidän pitää ymmärtää niiden merkitys.  SLA on oikeastaan vain yritys vyöryttää vastuu asiakkaan harteille ja niin ei pidä tehdä, ellei asiakas sitä halua.

 

Miten sitten tekniikan toimivuutta pitää mitata? Mieti laivaa. Tärkeintä on varmasti se, että tekniikan ongelmat eivät haittaa liiketoimintaa. Hyötyjä voi syntyä myös erilaisista säästöistä, vaikka energian kulutuksessa. Oleellista on, että toimintaa mitataan liiketoiminnan mittareilla, ei sisäisillä SLA-mittareilla. Lopuksi pitää vielä kerran korostaa, että on myös tilanteita, joissa asiakas haluaa ja tarvitsee palvelulettelon ja SLA:n.

Jos et ole lukenut aiempaa kirjoitustani palvelukäsitteen selkeyttämisestä, käy lukemassa myös se.

PS Kun testasin linkkejä, sain turvavaroituksen siitä, että linkki johtaa wordpress.com palvelimme, vaikka linkissä on osoitteena pohjoisviitta.fi. Olen siirtänyt pohjoisviitta.fi domainin wordpressille jo useita vuosia sitten, joten varoitus on aiheeton.

%d bloggers like this: