ITIL V3 pähkinänkuoressa

23.9.2011Olen kirjoittanut myös analyysin uusimmasta ITIL V3 2011 Edition versiosta
26.2.2010 Huomasin juuri että juttu oli katkennut viime päivityksen yhteydessä. Deletoin ja julkaisin uudestaan.

Juttua päivitetty 18.1.2010, asiana demand management ja problem management.

Tätä alkujaan 2008 julkaistua juttua luetaan yllättävän paljon vieläkin. Täydentävänä tietona lisään tähän sen että lopulta OGCkin on myöntänyt että V3 sisältää koko joukon pulmia. Refresh the refresh on käynnissä ja V3.1 on tulossa. V4 aikataulua ei ole toistaiseksi päätetty.

ITIL V 3 on laaja ja monimutkainen kokonaisuus. Se sisältää 25 prosessia, 22 näiden ulkopuolella olevaa aktiviteettia ja 4 funktiota. Valitettavasti kokonaisuus on sekava soppa.

Service Strategy

Service Strategy selvittää kuinka palvelunhallintaa kehitetään strategisena voimavarana. Se antaa ohjeita kuinka palvelunhallintaa johdetaan ja kehitetään palvelun elinkaaren ajan. Kirja luo pohjaa muille v3 ydinjulkaisuille määrittelemällä markkinat, palvelun voimavarat, palveluluettelon ja strategian jalkauttamisen. Pääosin Accenturen vastuulla ollut kirja kokoaa alan teoriat yhteen, sitä voisi kutsua IT-MBAksi tiivistettynä yhteen kirjaan.

Näkökulma on selvästi markkinalähtöinen ja perustuu pitkälti markkinoinnin teoriaan. Aluksi kirja kuvaa laajasti peruskäsitteitä. Palvelunhallinta -luku kuvaa palvelun peruskäsitteet, mitä on palvelu, mitä ovat liiketoimintaprosessit ja mikä on palvelun elinkaari. Kappaleessa kytketään muut elinkaaren osat kokonaisuudeksi.

Palvelustrategian periaatteet -luku kuvaa strategian käsitteitä kuten arvonmuodostusta, palvelun voimavaroja ja rakenteita.  Palveluntarjoajat ja palvelurakenteet ryhmitellään perustyyppeihin. Lopuksi keskitytään Clausewitzin johdolla strategian määrittelyn ydinkohtiin.

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.

IT taloushallinto

Taloushallinto tuntuu hiukan oudolta elementiltä strategiakirjassa. Ilmeisesti se ei oikein sopinut mihinkään osaan luontevasti. Luvussa käsitellään monia asioita kirjanpidosta kysynnän hallintaan. Tason nosto v2 ja v3 välillä on huima. Vanhempi versio kuvaa hyvin perustason asioita, lähtötilanne tuntuu olevan kirjanpidon ja budjetoinnin puuttuminen kokonaan. Uusi versio käsittelee pikaisesti perusasioita, mutta fokus on enneminkin investointien kannattavuuden laskemisessa ja palveluportfolion hallinnassa.

Demand management kuvaa kysynnänhallinnan. Kirjassa on vähän sekava luku 5.5 Demand Management, joka lähtee kysynnän hallinnasta ja päättyy palvelupaketteihin. Service design-kirjasssa on taas luku 4.3.5.6 Demand Management, joka kuvaa kysynnänhallinnan yhtenä kapasiteetinhallinnan aktiviteettinä. Mitään ristiviittauksia ei osunut silmään.

Strategia ja organisaatio käsittelee erilaisia organisaatiomalleja ja yrityskulttuuria. Näkökulma on lähempänä yritys- kuin it-johtoa. Osin käsittely on aika pinnallista, ongelmat mainitaan pikaisesti. Ulkoistamisstrategia ja ulkoistamisen hallintaa käsitellään myös.

Strategia, taktiikka ja operaatiot kytkee eri kirjoja yhteen ja näyttää strategian kytkennät eri elinkaaren vaiheisiin. Tässä kappaleessa palataan esim. palvelustruktuureihin ja hinnoittelumalleihin. Strategian jalkauttamisesta se ei kerro paljoa.

Teknologia ja strategia on 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.

Haasteet, kriittiset menestystekijät ja riskit.

Otsikossa luvataan käsitellä myös kriittisiä menestystekijöitä. Aihe on kuitenkin unohtunut kirjoittajilta. Kirjan kaikissa luvuissa on useita case –esimerkkejä ja niiden ratkaisuja. Monet kirjan esimerkit tuntutuvat kovin kaukaa haetuita, mutta tässä kappaleessa löytyy pohjanoteeraus. Esimerkissä kuvataan call center, joka on vaikeuksissa liian suuren työkuorman kanssa. Ratkaisuna on ohjata osa puheluista toiseen identtiseen call centeriin. Julkisuudessa moitittujen puhelinoperaattorien asiakaspalvelujen johto varmaankin potkaisee itseään nilkkaan ja ihmettelee miksi tuo näppärä ratkaisu ei ole juolahtanut mieleen. Kirjoittajat olisivat toki voineet vielä lisätä ohjeet siitä, miten löydetään sateenkaaren päässä oleva kultapata, jolla uusi call center rahoitetaan.

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. Kirjasta vastasi pieni kahden hengen yritys, IT Enterprise Service Management Ltd.,ITEMS.

Kirjaa selatessa huomaa että V3 kirjojen synkronointi ei ole onnistunut kovin hyvin. Hyvä esimerkki tästä ovat Service Strategy –kirjan Service sourcing structures –taulukko ja Service Design –kirjan Main service delivery strategies –taulukko. Eri nimistä huolimatta molemmat kuvaavat samaa asiaa. Jälkimmäinen on kattavampi ja parempi, mutta se on väärässä kirjassa.

Service design kuvaa seitsemän prosessia.

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.

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
  • palvelujen katselmointi ja kehittämisohjelmien käynnistäminen
  • asiakassuhteiden ylläpito

Kapasiteetin hallinta

Prosessin tavoitteena on varmistaa kapasiteetin optimaalinen riittävyys. Prosessi ei ole suuresti muuttunut aiemmasta versiosta.

Saatavuuden hallinta

Saatavuuden hallinta on laajentunut kattamaan jossain määrin myös ongelmanhallinnan aluetta. Muuten tämän prosessin keskeiset päämäärät eivät ole muuttuneet.

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 uusi prosessi jonka tarkoituksena on hallinnoida toimittajia ja heidän palvelujaan niin että palvelun laatutavoitteet saavutetaan ja että ostetut palvelut tuottavat lisäarvoa.

Kirjoittajat eivät tunnu oikein päässeen yksimielisyyteen siitä mitkä ovat prosessin aktiviteetit. Seuraavat aktiviteetit on kuvattu yksityiskohtaisesti, mutta muitakin mainitaan.

  • toimittajien ja sopimusten arviointi
  • toimittajien luokittelu ja toimittajatietojen ylläpito
  • uusien toimittajien käyttöönotto
  • toimittajien toiminnan arviointi
  • sopimusten uusiminen tai päättäminen

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. Kirjasta vastasi Connectsphere, joka on pieni englantilainen konsultti – ja koulutusyritys. 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 uusi prosessi, joka sisältää osia aiemmasta Release management –prosessista. Siinä käsitellään mm. muutosstrategia ja release policy.

Change management on pitkälti entinen muutostenhallinta. Sen kytkentä edeltävään prosessiin on jäänyt tämän kirjoittajalle hiukan hämäräksi. .

Service Asset and Configuration Management SACM on laajennettu versio aiemmasta konfiguraationhallinnasta. Sen tukena on uusi järjestelmä, CMS eli Configuration Management System. Uusi nimi on jäänyt vieraaksi jopa tämän kirjan kirjoittajille, muissa kappaleissa käytetään systemaatisesti vanhaa V2 nimeä. Uusi prosessi on myös tuntematon Service Operation –kirjan kirjoittajille.

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

Service Validation and Testing on uusi 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ä.

Evaluation process on uusi geneerinen prosessi, jonka tehtävänä on arvioida suunniteltuja muutoksia. Sitä pitäisi siis käyttää muiden prosessien tukena, mutta siihen ei viitata missään muussa prosessissa, joten sen rooli jää aika hämäräksi.

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.

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 uusi prosessi, joka käsittelee erilaisten valvontajärjestelmien antamia varoituksia. Prosessin tavoite lienee epäselvä kirjoittajallekin koska Event managementin sanotaan olevan pohja operational monitoring ja control toiminnalle, mutta sellaista prosessia V3:ssa ei ole.

Incident Management on sama prosessi kuin aiemmassa versiossa, joskin siitä on poistettu palvelupyyntöjen käsittely omaksi prosessikseen. Ikävää on että insidentin käsite on muutettu, aiemmin insidentti oli mikä tahansa normaaliin toimintaan kuulumaton tapahtuma joka haittasi tai saattoi haitata palvelua. Uusi insidentin määritelmä on hiukan hämmentävä. sillä siinä kuvataan myös itse prosessi, liekö prosessin kuvaus jäänyt vahingossa määritelmään:

An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.

 

Incident Management is the process for dealing with all incidents; this can include failures, questions or queries reported by the users (usually via a telephone call to the Service Desk), by technical staff, or automatically detected and reported by event monitoring tools.


Kirjoittavat esittävät määritelmän ikään kuin nykyisenä, jää vaikutelma ettei kirjoittajalla ollut mahdollisuutta tarkistaa, mikä se insidentin määritelmä olikaan ja sitä on koetettu muistella omin sanoin. Kaiken kaikkiaan Incident Management ja Service Desk on käsitelty kevyesti.

Problem Management

Ongelmanhallinnan prosessia on muutettu melko radikaalista. Prosessi koostuu nyt kahdesta ”pääprosessista”, jotka ovat ennakoiva ongelmien hallinta ja reaktiivinen ongelman hallinta. Ennakoivan ongelmanhallinnan osalta viitataan CSI-kirjaan, josta löytyy viittaus takaisin. Proaktiivinen problem management on siis unohtunut. Virheiden hallinta on siis jätetty pois, mutta on vaikea nähdä mitään hyvää syytä tälle poistolle.

Request Fulfilment

Palvelupyyntöjen käsittely on uusi prosessi, aiemmin se oli osa insidentttien käsittelyä. Palvelupyynnön ja insidentin raja on hiukan häilyvä. Asiakkaalla voi olla mielestään ongelma mutta todellisuudessa asiakas ei ole lukenut ohjeita ja asiakastuen kannalta kyse on joko neuvonnasta tai täsmäkoulutuksesta. Geneerinen palvelupyyntöjen käsittely on yksinkertainen proseduuri.

Access Management

Käyttöoikeuksien hallinta on uusi prosessi.

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 (tässä vaiheessa kirjassa ryhdytään kuvaamaan yllättäen organisaation sijasta Application Management –prosessia!).

Continual Service Improvement CSI

CSI tuo jatkuvan laadunkehityksen mallin ITILiin. Pink Elephantin kirjoittama kirja kuvaa seitsemänvaiheisen ydinprosessin, joka kattaa tiedon keruun. Prosessin vaiheet ovat:

1 Määrittele mitä pitäisi mitata

2 Määrittele mitä voi mitata

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 tarkkaa mutta tarvittaisiin keinoja vaiheen 7 suorittamiseen. Kirjassa kuvataan myös prosessit Service reporting ja Service Measurement, tosin Service Reporting ohitetaan yhdellä sivulla.

Versio 3 käyttöönotto

On vaikeaa suositella ITIL V3 suomalaisille it-organisaatioille. Sinänsä uudet laajennukset ovat tarpeellisia asioita. Palveluntarjoajana pitää miettiä strategiansa, markkinansa ja tarjoomansa. Uusien palvelujen kehittäminen ja käyttöönotto on tärkeää. Palvelujen jatkuva kehittäminen on välttämätöntä. Version suunnittelijoilla on ollut hyviä ajatuksia. Aika näyttää mitä tässä tapahtuu. Voi olla virheistä huolimatta uusi versio saavuttaa suosiota sillä monikaan ei jaksa oikeasti lukea näitä kirjoja. Useimmat käyvät kursseilla ja tutustuvat kurssimateriaaliin, joka tiivistettynä esittää loogisemman tulkinnan siitä, mitä kirjoittajat ehkä olisivat halunneet sanoa.

Version 3 kirjoja ei todellakaan voi suositella kenellekään luettavaksi. Kirjat on kirjoitettu huonosti, eikä niitä ole koordinoitu. Toki uudessa versiossa on hyvääkin ja monet havaitsemani virheet ovat korjattavissa, mutta en suosittele uutta versiota tässä muodossa kenellekään.

Olen nyt ITIL V3 Expert

Aivan ensimmäiseksi pitää sanoa että tutkinto on älytön. Jos joku vakuuttaa olevansa it-palveluhallinnan asiantuntija koska on suorittanut ITIL V3 Expert tutkinnon niin sopii nauraa. Tutkinto on vitsi ja sen läpäisyyn tarvitaan vain ulkoa opiskelua.

Ajattelin kuitenkin että ehkä minun pitää hankkia tuokin sertifikaatti. Olen käynyt keskusteluja ITIListä LinkedInin palstoilla ja huomasin siinä että olen paremmin perillä V3:sta kuin monet ITIL Expertit. Opiskelu oli vähän takkuista kun V3 lukemattomat virheet ja sekoilut nousivat esiin. En kertakaikkiaan ymmärrä että kukaan, joka on lukenut kirjat ja omaa vähänkin ymmärrystä ja arvostelukykyä, lähtee toteuttamaan kirjan oppeja käytäntöön.

Jos nyt kuitenkin haluaa saada tuon sertifikaatin ja on suorittanut V2 Service Managerin niin alkaa olla kiire. Bridge-tentti V2-V3 lopetetaan ensi vuonna ja sen jälkeen ainoa vaihtoehto on järjettömän monen kurssin suorittaminen. Tässä kartta kurssiviidakosta: http://www.itil-officialsite.com/itilservices/v1/map.asp

Tenttiä varten on käytävä kurssi, tein The Art of Service:n e-learningin kautta  http://www.theartofservice.org/. Suositttelen reittiä. Kurssi on ihan mukava ja sen myötä saa jonkin verran hyödyllistää materiaalia.

Jos kiinnostuneita löytyy, voin järjestää tentit ja yhden lähiopintopäivän tenttiin valmistautumiselle. Säästät paljon aikaa ja 1600 €. Ota yhteyttä jos asia kiinnostaa.

Paljon suunnittelua

Olen taas lueskellut ITIL V3 kirjoja ja jossain vaiheessa alkoi ärsyttää jatkuvasti toistuvat erilaiset strategiat. Lopulta päätin laskea niiden lukumäärän. Sitten huomasin että niiden lisäksi siellä kuvataan myös monta policy:a. Nämä eivät ole suinkaan synonyymejä. Yhteensä näitä on 44 kappaletta, saattaa olla että joku jäi huomaamatta, mutta kyllähän noissakin urakkaa riittää. Toisaalta näiden väsääminen työllistää mukavasti ja innokkaat V3 konsultit auttavat varmaan mielellään.

Jos satut tapaamaan jonkun oikean ITIL gurun, pyydä häntä muutamalla sanalla selittämään vaikka asset disposal policyn ja retention policyn erot ja miten ne istuvat transition strategiaan.

Tässä lista, arvioi itse miten järkevää näiden kaikkien väsääminen olisi:

SD access control policy
SD anti-virus policy
SD asset disposal policy
ST Asset Management policy
SD backup and recovery strategy,
SO Backup and Restore strategy
ST Change Management policy
CSI communication strategy
ST Communication Strategy
ST Configuration Management policy
CSI continual improvement strategy
SO cost strategy
SD delivery strategy
SD document classification policy
SD e-mail policy
SD environmental strategy
SD information classification policy
SD internet policy
SD IT Service Continuity Strategy
SD ITSCM policy
ST Knowledge Management strategy
SO Operations Strategy
SD password control policy
SD procurement and contract policy
ST release policy
SD remote access policy
CSI Reporting policy
ST retention policy
SD Risk Management Policy
SD Security Policy
SD security strategy.
ST Service Asset and Configuration Management strategy.
ST service quality policy
SO Service Strategy
ST Service Transition policy
SS sourcing strategy
ST Stakeholder management strategy
SD strategy for the acquisition and management of IT assets
SD Supplier and contracts strategy
SD supplier policy
SD supplier strategy
ST Test strategy
ST Transition strategy
SD virus policy

Sisältäpäin vai ulkoapäin

Kuluttajaviraston mukaan on ”turha soittaa, asiakaspalvelu ei kuitenkaan vastaa”. Yritysten asiakaspalvelu siirtyy yhä enemmän internetiin. Samalla henkilökohtainen asiakaspalvelu esimerkiksi puhelimella vähenee. Kuluttajaviranomaisen mukaan yritysten tavoittaminen on käytännössä vaikeutunut, ja asiakkaiden yhteydenottoihin saatetaan suhtautua jopa piittaamattomasti.

Käsitepari inside-out – outside-in eli sisältäpäin tai ulkoapäin on tosi käyttökelpoinen ja sillä voi selittää monia ilmiöitä. Sisältäpäin katsova keskittyy siihen, miten asiat tehdään ja yrittää luoda tehokkaan tavan toimia. Prosessien käyttöönotossa on  usein kyse tästä. Keskitytään prosessien käyttöönottoon ja työkalujen virittämiseen. Omalle toiminnalle asetetaan mittareita ja pyritään kehittämään toimintaa niiden mukaan. Ulkoapäin katsottuna asiat näyttävät erilaiselta. Lähtökohdaksi pitää ottaa asiakkaan tarpeet. Ne ovat varsin yksinkertaisia. Asiakas ostaa palvelua voidakseen luoda itselleen arvoa palvelun kanssa. Palvelun toimivuutta ja tehokkuutta mitataan asiakkaan kannalta. Esimerkiksi kun vuokraan auton liikkuakseni sillä, saan vastinetta rahalleni vain jos pystyn käyttämään autoa. Kaikki esteet ja häiriöt haittaavat arvon luomista. Kaikki ylimääräinen puuha lisää palvelun hintaa asiakkaan näkökulmasta.  Palveluorganisaation tehtävän on huolehtia, että asiakas saa sen mitä hänelle on luvattu. Asiakaspalvelun tärkein tehtävä on auttaa asiakasta käyttämään palvelua ja selviytymään erilaisista pulmatilanteista. 

Palveluntuottajan on helppo sortua sisältä lähtevään ajatteluun. Asiakaspalvelun siirtäminen nettiin on hyvä esimerkki tästä. Otetaan lähtökohdaksi oma toiminta ja yritetään saada asiakkaat mukautumaan siihen vaikka väkisin. Asioiminen verkkosivuilla säästää toiminnan kustannuksia kun puhelujen määrä laskee. Siirretään palvelu sinne ja vähennetään resursseja asiakaspalvelusta.

Asiakkaan kannalta asiakaspalvelun siirtäminen verkkoon voi olla hyvä asia. Joitakin asioita on helppoa tehdä verkossa, on aikaa vertailla vaihtoehtoja ja pohtia asiaa. Itsepalvelu on oikeastaan paljon mukavampaa kuin tiskillä asiointi, mieti vaikka Alkossa käyntiä tai käteisen nostamista, joskus ennen ne piti tehdä tiskillä. Jos verkkopalvelu tehdään hyvin, monet asiakkaat siirtyvät sinne ja kustannuksia säästyy. Valitettavasti hyvän verkkopalvelun tekeminen ei ole niin helppoa. Joskus tuloksena on hyvin vaikea verkkopalvelu, joka lisää palvelun kustannuksia asiakkaan kannalta. Jos tähän lisätään surkea puhelinpalvelu on tuloksena surkea kokonaisuus.  

Palvelun kehittäjän on tärkeä pitää mielessä tuo näkökulma. Kun kerran itse istuu sisällä organisaatiossa, on niin helppoa alkaa katsoa asioita sieltä päin. Näkökulman kääntäminen ei tapahdu itsestään tai vaivatta. ITIL, jos mikä on kaunis esimerkki sisältäpäin katsovasta mallista. Lähinnä myyntiä ITILissä taitaa olla Demand Management eli kysynnän hallinta. Kannattaa pitää mielessä tämä kun soveltaa ITILiä.  ISO 20000 sentään pakottaa hoitamaan asiakassuhdetta eli tässä mielessä se on kaukana ITILin edellä.

Event management

Event management eli herätteiden hallinta on hyvä lisäys itil-prosesseihin. Herätteet ovat erilaisia ilmoituksia, joihin pitää reagoida eri tavoin. Monet voidaan suodattaa automaattisesti, mutta jotkut vaativat käsittelyä. Kriittisiä järjestelmiä valvotaan usein juuri event managementin avulla. Itilin mukaan herätteeseen voidaan reagoida monella tavalla, voidaan tehdä manuaalinen interventio tai sitten voidaan käynnistä insidentinhallinta, ongelmanhallinta tai muutoksenhallinta.

Tyypillinen, käsittelyä vaativa event on vaikka tyhjenevän mustesäiliön vaihtaminen tai jonkin kahdennetun komponentin rikkoontuminen. Tilanne ei vielä näy asiakkaalle, mutta lisää katkon tai häiriön riskiä. Normaali toimenpide on käydä vaihtamassa kulunut tai rikkinäinen komponentti. Esimerkiksi yhden levyn hajoaminen voi olla niin rutiini operaatio ettei yksittäisiä levyjä edes määritellä CI:ksi. Tässä törmätään sitten taas näihin itil-käsitteisiin. Peilatun levyn hajoaminen on itilin mukaan insidentti eli event managementin pitäisi kirjata se insidentiksi ja antaa siten insident managementin vastata toiminnan ohjauksesta. Onko tämä järkevä toimintamalli?

Pulmaksi voisi muodostua työjono ja priorisointi. Työjonossa voi olla joukko vanhempia insidenttejä odottamassa käsittelyä, uusi insidentti ei mene kärkeen vaan jää odottamaan vuoroaan. Ennaltaehkäisevää tärkeää toimenpidettä ei ehditä tehdä, koska työjonossa on joukko muita tehtäviä, joiden SLA aika on umpeutumassa. Tämä ei ole mikään teoreettinen tilanne vaan eräs it-päällikkö purnasi minulle  tällaisesta ulkoistetun palvelukeskuksen toimintatavasta.

Oma tulkintani hyvästä käytännöstä on antaa event managementin hoitaa kaikki ne tapaukset, jotka eivät näy asiakkaalle. Insidentteihin taas liittyy aina asiakas. Näin saadaan näille kahdelle prosessille järkevä työnjako.

Haltiakieltä

Sain hauskaa palautetta viime perjantaina. Olin vetänyt it-palvelunhallinnan seminaaria yksikön johtoryhmälle. Seminaarin jälkeen eräs osallistuja kiitti tilaisuutta ja sanoi että tämä ei ollut sellaista haltiakieltä, mitä näissä on tottunut odottamaan.

Haltiakieli on hauska termi korkealentoiselle ja vaikeatajuiselle konsulttikielelle. Kielen tehtävänä on osoittaa puhujan oppineisuutta ja erikoisosaamista. Toki erikoistermeistä on hyötyä joissakin tilanteissa, mutta kielellä voi myös peitellä osaamisen ja ymmärryksen puutetta.

Tässä Pohjoisviitan suositus haltiakielen kohdalla. Esitä tyhmiä kysymyksiä. Pyydä selittämään asia suomeksi, jos konsultti puhuu kovin korkelentoisia. Pyydä kertomaan mikä on eri käsitteiden ero. Kysy vielä mitä konkreettista hyötyä asiasta on. Instant-expertin yksi tuntomerkki on, että tämä ei pidä kysymyksistä.

Uudet asiat synnyttävät myös uudet asiantuntijat. Olen usein sanonut että helpparissa ei tarvitse olla huippuasiantuntija, riittää kun tietää vähän enemmän kuin asiakkaat. Sama sääntö pätee konsultoinnissa. Sertifiointikoulutus synnyttää instant-asiantuntijoita, vaikka sertifikaatti olisi hankittu opettelemalla vastaamaan monivalintakysymyksiin. Jokainen toki tajuaa että muutaman päivän päntäämisellä ei tule asiantuntijaksi. Todellinen asiantuntijuus edellyttää perusteellista teoreettista koulutusta ja laajaa kokemusta. Valitettavasti uusista ilmiöistä ei ole olemassa kunnollista teoriaa, jolloin kokemuksen merkitys korostuu. Toisaalta kokemuksen on oltava laaja-alaista, yhden talon opit eivät kanna pitkälle.

Akkreditointeja

Olen akkreditoitu kouluttamaan seuraavia kursseja. Huom myös siis ITL V3 vaikka en ole sitä vielä halunnut tehdä.

  • Foundation Exam in IT Service Management according to ISO/IEC 20000
  • Foundation BridgeExam in IT Service Management according to ISO/IEC 20000
  • IT Service Management Foundation (based on ITIL®)
  • ITIL®V3 Foundation
  • ITIL®V3 Foundation Bridge
  • ISO/IEC 20000 Professional Align
  • ISO/IEC 20000 Professional Control
  • ISO/IEC 20000 Professional Delivery
  • ISO/IEC 20000 Professional: Management & Improvement of ITSM processes
  • ISO/IEC 20000 Professional: Support of IT Services
  • IT Service Management Practitioner: Agree and Define (based on ITIL®)
  • IT Service Management Practitioner: Plan and Improve (based on ITIL®)
  • IT Service Management Practitioner: Release and Control (based on ITIL®)
  • IT Service Management Practitioner: Support and Restore (based on ITIL®)
%d bloggers like this: