ITIL 2011 pähkinänkuoressa

ITIL V3 on siis nyt ITIL 2011. Nelosversiota ei tullut vaikka käytännössä tämä on uusi versio. Kolmosversion kirjat kannattaa panna paperinkeräykseen.

Tätä alkujaan 2008 julkaistua juttua luetaan yllättävän paljon vieläkin. Päivitän sen nyt koskemaan ITIL 2011 Editionia. ITIL 2011 on edelleen laaja ja monimutkainen kokonaisuus. Se sisältää nyt selkeän listan prosessista, ennenhän se oli vähän tulkinnallista. Prosesseja on nyt 26 ja lisäksi lukemattoman määrän näiden ulkopuolella olevaa aktiviteettia.

1 Service Strategy

Uusi versio on selvästi parempi kuin aiempi ja se on kirjoitettu kokonaan uudestaan. Huomautin edellisessä kritiikissä että eräät asiat käsiteltiin kahteen kertaan, ensin strategiassa ja sitten Service Design kirjassa. Syynä oli ilmiselvästi se, ettei kukaan koordinoinut kokonaisuutta.

Nyt kirja keskittyy IT-palveluihin, eikä ole liian yleinen. Lisäksi kirjoittajille on valjennut että monet it-palveluyksiköt ovat sisäisiä. Monet kolmosversion kirjan esimerkit tuntuivat kovin kaukaa haetuita ja onneksi niitä on poistettu. Strategia määritellään markkinalähtöisesti, eli ensin kuvataan markkinapaikka ja sitten tarjooma. Näiden varaan rakennetaan strategiset voimavarat. Toteutuksen valmistelu käsittelee nykytilan arviointia, menestystekijöiden määrittelyä ja strategisten askelten suunnittelua.

Strategian ylläpito yläpito kuvataan prosessina, joka on aika epärealistista useimmille. Jos strategia on tarpeen tehdä, siitä ei silti tule luontevasti prosessia.

Palveluportfolion hallinta on myös mielestäni älytön prosessi. Johdon tehtävänä on miettiä palveluportfoliota ajoittain, mutta harva siihen tarvitsee prosessia. Lisäksi asia menee päällekkäin Service Design -kirjan kanssa.

IT taloushallinto tuntuu edelleen oudolta elementiltä strategiakirjassa. Ilmeisesti se ei oikein sopinut mihinkään osaan luontevasti, tosin mielestäni Service Design olisi oikea paikka sille. Kolmosversion sfääreistä on nyt palattu ryminällä arkeen. Tuskin kirjassa on paljoakaan uutta, taloushallinto tuntuu yleensä toimivan tyydyttävällä tasolla. Sen sijaan on älytöntä että taloushallinnolle esitellään 25 KPI-mittaria.

Demand management kuvaa kysynnänhallinnan. Tämä oli täysi sekametelisoppa vanhassa kolmosversiossa. Ajatus oli karannut kirjoittajilta täydellisesti ja lisäksi sama prosessi kuvattiin uudestaan Service Design -kirjassa. Nyt tarinassa on jotain tolkkua ja demand -prosessia ei enää kuvata kahteen kertaan.

Business Relationship Management Tämä on kokonaan uusi prosessi, jonka puuttuminen oli kolmosversion suurin moka. Tietenkään asiakassuhteen hallinta ei ole prosessi vaan funktio. Suhteen hallinta on pitkälti henkilösidonnaista, mutta jos unohdetaan tuo prosessikäsitteen pahoinpitely, niin kappaleessa on asiaa.

Service strategy, governance, architecture and ITSM implementation strategies on pitkä ja sekava nimi kappaleelle, jossa käsitellään mm. strategian jalkauttamista ja pohdinta vaikuttaa fiksulta.

Organizing for service strategy käsittelee erilaisia organisaatiomalleja ja yrityskulttuuria. En oikein tiedä, onko tästä olemassa parasta käytäntöä.

Technology considerations on edelleen outo luku. Siinä käsitellään palveluautomaatioita ja valvontajärjestelmiä. Tämän kirjoittajalle ei oikein auennut näiden sinänsä hyvien asioiden strateginen ulottuvuus.

Implementing service strategy on uusi luku, asiaa ei juurikaan käsitelty viimeksi. On vähän hassua että strategian jalkauttamista käsitellään uudestaan, kun se tuli jo kertaalleen käsiteltyä .

Haasteet, kriittiset menestystekijät ja riskit.Tämä on vähän turha kappale, mutta onneksi lyhyt. Kaikkia kappaleen asioita on jo käsitelty useaan kertaan.

Parannuksista huolimatta pidän kirjaa turhana useimmille. Sisäinen it yksikkö ei laadi strategioita, vaan suunnittelee miten toteuttaa johdon sille asettamia tavoitteita.

2 Service Design

Kirja käsittelee palvelujen suunnittelemista ja kehittämistä. Se kattaa strategisten tavoitteiden muuntamisen palveluiksi. Kohteena ei ole pelkästään uudet palvelut vaan myös olemassa olevien palvelujen kehittäminen liiketoiminnan ja ympäristön vaatimusten mukaisesti. Siihen kuuluu myös palvelujen laadun, jatkuvuuden ja yhdenmukaisuuden varmistaminen. Service design kuvaa kahdeksan prosessia eli prosessien määrä on kasvanut yhdellä.

Service design management Tämä on aika uskomaton uusi ”prosessi”. Se tuottaa Service Design Package (SDP) -määrittelyjä. Nämä SDPt ovat ylätason palvelukuvauksia. Tämä on älyttömän raskas lähestymistapa.

Palveluluettelon hallinta. Prosessin tehtävänä on ylläpitää palveluluetteloa ja tuoda se kaikkien saataville. Tämä oli aiemmin Palveluntasonhallinnan aktiviteetti, joka on nyt nostettu omaksi prosessiksi. Tämäkin on turha prosessi.

Palveluntason hallinta Palvelutasonhallinnan tavoitteena on varmistaa että asiakkaat saavat sovittujen tavoitteiden mukaista palvelua ja että tarvittaessa palvelua myös kehitetään. Prosessi varmistaa sen, että palvelutaso mitataan ja tulokset raportoidaan asiakkaalle. Prosessin aktiviteetteja ovat mm:

  • vaatimusten määrittely ja kirjaaminen
  • palvelutason seuranta ja valvominen
  • asiakastyytyväisyyden mittaaminen ja palautteiden käsittely
  • arvioida ja päivittää hankintasopimukset yhteistyössä supplier managementin kanssa
  • palvelujen katselmointi ja kehittämisohjelmien käynnistäminen
  • asiakassuhteiden ylläpito yhteistyössä business relationship managementin kanssa.

Saatavuuden hallinta Saatavuuden hallinta on laajentunut kattamaan ongelmanhallinnan ja palvelun kehittämisen aluetta. Sinne on esimerkiksi ilmestynyt käsittämätön termi, proaktiivinen saatavuuden hallinta. Mitäköhän reaktiivinen saatavuudenhallinta sitten olisi? Täällä esitellään myös ongelmanratkaisumenetelmiä.

Kapasiteetin hallinta Prosessin tavoitteena on varmistaa kapasiteetin optimaalinen riittävyys. Hyvä kysymys on se, miksi demand management on erotettu omaksi prosessikseen.

IT palvelun jatkuvuuden hallinta Aiemmassa ITIL versiossa käsiteltiin varsin vähän strategiatason asioita. Oikeastaan ainoa selvä poikkeus oli jatkuvuudenhallinta, jossa täytyy pohtia sitä, kuinka paljon ollaan valmiita maksamaan it-palvelujen turvaamisesta. Esimerkiksi tietojärjestelmien täydellinen kahdentaminen on kallis toimenpide, joka varmasti perustuu yrityksen strategiaan. Olisi ollut johdonmukaista sisällyttää tämä osuus Service Strategy –kirjaan, jonne se olisi luontevasti kuulunut. Kirjoittajat ovat kuitenkin säilyttäneet tämän prosessin ennallaan.

Tietoturvanhallinta Prosessin tehtävänä on sovittaa tietoturva liiketoiminnan tarpeisiin ja vastata sen toiminnasta. Kirjassa viitataan moneen otteeseen ISO 27001 –standardiin.

Toimittajien hallinta Toimittajien hallinta on prosessi jonka tarkoituksena on hallinnoida toimittajia ja heidän palvelujaan niin että palvelun laatutavoitteet saavutetaan ja että ostetut palvelut tuottavat lisäarvoa. Aktiviteetteja ovat mm.

  • tarpeiden määrittely
  • toimittajien ja sopimusten arviointi
  • toimittajien luokittelu ja toimittajatietojen ylläpito (uusi lyhenne SCMIS)
  • uusien toimittajien käyttöönotto
  • toimittajien toiminnan arviointi
  • sopimusten uusiminen tai päättäminen

3 Service Transition

Palvelun muutosten hallinta käsittelee uusien ja muuttuneiden palvelujen käyttöönottoa. Elinkaarimallin mukaisesti uudet palvelut suunnitellaan strategian ohjaamina ja sitten ne otetaan hallitusti käyttöön. Kirjassa esitellään seuraavat prosessit:

  • Transition Planning and Support
  • Change Management
  • Service Asset and Configuration Management
  • Release and Deployment Management
  • Service Validation and Testing
  • Evaluation
  • Knowledge Management.

Transition planning and support on ylätason prosessi, joka luo mm. muutosstrategian ja release policyn.

Change management on pitkälti entinen muutostenhallinta mutta samalla alueella hääräävät myös mm. Portfolio Management, Transition planning and support ja Change Evaluation.

Service Asset and Configuration Management SACM on laajennettu versio aiemmasta konfiguraationhallinnasta. Sen tukena on uusi järjestelmä, CMS eli Configuration Management System.

Release and Deployment Management on pääosin vanha Release management. Hiukan hämmentävästi tekstiin on jätetty edelleen myös jakelupolitiikan eli release policyn suunnittelu, vaikka siihen tarkoitukseen on määritelty kokonaan uusi prosessi.

Service Validation and Testing on prosessi, jonka tehtävänä on varmistaa että suunniteltu muutos tuottaa halutun hyödyn. Prosessin on ajateltu toimivan korkeammalla tasolla kuin Change ja Release managementin testaaminen. Miten tämä sitten tapahtuisi käytännössä, herättää kyllä kysymyksiä.

Change Evaluation process on prosessi, jonka tehtävänä on arvioida muutoksia. Sen roolia on nyt tarkennettu tähän muutosten arviointiin.

Knowledge Management on uusi prosessi, jonka tehtävänä on huolehtia siitä että tarvittavat tiedot ovat saatavilla. Kirjassa aihetta lähestytään hyvin pinnallisesti. Aihe lienee ollut melko vieras kirjoittajille. Uudessa 2011 versiossa aihe ei ole vieläkään valjennut. Tähän on parempia lähteitä.

4 Service Operation

Kirja kuvaa varsinaisen palvelujen tuotantovaiheen. Kirjassa kuvataan seuraavat prosessit

■ Event Management

■ Incident Management

■ Problem Management

■ Request Fulfillment

■ Access Management

Kirjassa käsitellään myös varsinaisia tuotantoprosesseja, jotka puuttuivat V2:sta sekä tuotannon organisointia.

Event management on prosessi, joka käsittelee erilaisten valvontajärjestelmien antamia varoituksia. Varoitus voi olla exception (poikkeama) ja ne voidaan käsitellä automaattisesti. Esimerkkinä mainitaan serverin kaatuminen. Tässä on hyvä muistaa, että levypakan hajoaminen taas on insidentti. Tämä käsitesoppa on siis saanut jatkua, mitään tolkkua tästä ei tule. Exception-termiä ei selitetä sanastossa.

Incident Management on sama prosessi kuin aiemmassa versiossa, joskin siitä on poistettu palvelupyyntöjen käsittely omaksi prosessikseen. Insidentin käsitettä on taas hiukan muutettu, aluksi insidentti oli mikä tahansa normaaliin toimintaan kuulumaton tapahtuma joka haittasi tai saattoi haitata palvelua. Väliversiossa määritelmä oli hyvin sekava, insidentti oli häiriö mutta insidenttienhallinta oli asiakastukea. Nyt uusi insidentin määritelmä on nyt täsmentynyt häiriöksi. Insidentin ja poikkeaman ero jää hämäräksi.

Request Fulfilment käsittelee erilaisia tilauksia. 2011 edition jättää neuvonnan kokonaan Itilin ulkopuolelle. Edellinen kolmosversio sisällytti sen insidenttien hallintaan, melko sekavasti tosin mutta kuitenkin. Nyt nämä käsitteet on selkeytetty ja varsinaiset tukipyynnöt on jätetty kokonaan pois. Insidentit ovat yllättäviä tapahtumia, mutta palvelupyynnöt pitäisi voida suunnitella.

Problem Management Ongelmanhallinnan prosessia on muutettu taas. Prosessi koostuu nyt kahdesta ”aspektista”, jotka ovat ennakoiva ongelmien hallinta ja reaktiivinen ongelman hallinta. Reaktiivinen ongelmanhallinta on käytännössä sama kuin insidenttien hallinta, pienenä erona että ongelmanhallinta yrittää selvittää insidentin aiheuttajan. Käytännössä nämä ovat samoja prosesseja eli asia ei ole vieläkäään valjennut itilin kirjoittajille.

Ennakoiva ongelmanhallinta on nyt tuotu takaisin sillä se unohtui kolmosversiosta. Virheiden hallinta on edelleen jätetty pois, mutta on vaikea nähdä mitään hyvää syytä tälle poistolle.

Access Management Käyttöoikeuksien hallinta kuvataan omana prosessina, vaikka se on muiden prosessien ylläpitämä palvelu. Palvelu käynnistyy palvelupyynnöstä ja muuttaa konfiguraatiotietoja.

Tuotantoprosessit. Jostain syystä näitä ei kirjassa kuvata prosesseina vaan aktiviteetteina. Ehkä prosessien määrää haluttiin karsia. Tuntuisi loogiselta että esim. Event management voisi olla Monitor ja control –prosessin yksi aktiviteetti mutta näin ei ole. Aktiviteetit ovat:

  • monitor and control
  • IT operations
  • mainframe management
  • server management & support
  • network management
  • storage and archive
  • storage administration
  • database administration
  • directory service management
  • desktop support
  • middleware management
  • internet /web management
  • facilities and data centre management

Organisaatiosta kuvataan Service Deskin lisäksi Technical Management, IT Operations Management ja Application Management. Sovellushallinnan prosesseja kutsutaan ovelasti sovelluksen elinkaaren vaiheiksi (stage, ei löydy sanastosta)

Service deskin kuvaus on vanhanaikainen, faksit ja videot kummittelevat edelleen. Esimerkiksi pääkäyttäjät nähdään vain Service Deskin jatkeena, eikä tajuta että näillä voi olla merkittävä rooli lukuisissa prosesseissa, asiakassuhteen hoitamisesta alkaen.

5 Continual Service Improvement CSI

CSI tuo jatkuvan laadunkehityksen mallin ITILiin. Pink Elephantin kirjoittama kirjaa on muokattu aika paljon. Siitä on poistettu kaksi prosessia ja se kuvaa seitsenvaiheisen ydinprosessin, joka kattaa tiedon keruun. Prosessin vaiheet ovat:

  1. Tunnista kehittämisstrategia
  2. Määrittele mitä mittaat
  3. Kerää tieto
  4. Käsittele tieto
  5. Analysoi tieto
  6. Esittele ja hyödynnä tieto
  7. Suorita korjaavat toimenpiteet

Malli perustuu mittaamiseen ja analysointiin tilanteessa, jossa tietoa on liiankin paljon käytössä. Jatkuva parantaminen nähdään ensisijaisesti mittaamisen ongelmana. Näkökulma on erikoinen. Usein tilanne on toki se, että ongelmat tiedetään liiankin tarkkaan, mutta tarvittaisiin keinoja vaiheen 7 suorittamiseen. Koko kirjassa on kaksi (2) sivua, joissa käsitellään tuota vaihetta 7 eli toiminnan kehittämistä.

Pahinta kirjassa on, että se esittelee oman, päällekkäisen organisaation jatkuvalle kehittämiselle. Suositukseni on, unohda tämä kirja.

6 Arvio

Version 2011 kirjat ovat selvästi paremmat kuin edelliset. On makuasia, pitääkö muutoksia suurena vai pienenä ja ilmeisesti peruskursseihin ne eivät vaikuta, osin siksi että peruskurssit ovat niin pinnallisia.

Hyviä niistä ei ole tullut vieläkään. En suosittele.

%d bloggers like this: