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

Vuoden 2012 suosituimmat jutut ja hakusanat

Luetuimmat jutut

  1. Työkalututkimus 2012
  2. Service Desk 2.0, the new support function
  3. BYOD Suomessa
  4. Service deskin tulevaisuus
  5. Vuoden 2012 teemat
  6. ITIL V3 pähkinänkuoressa
  7. Asiakassuhteen hoito ja palvelusopimukset
  8. Service Desk 2.0
  9. 20 miljonaa käyttäjää, 50.000 tukipyyntöä kuukaudessa ja 10 henkeä tuessa.
  10. IT palvelun toimivuus

ITIL V3 pähkinänkuoressa sinnittelee listalla edelleen, vaikka se on alkujaan kirjoitettu jo vuosia sitten.

 

Suosituimmat hakusanat

hakusanat12

Hakusanoissa ITIL pysyy yhä kärjessä, mutta hakujen määrä on pudonnut. Uusi ITIL 2011 ei tunnu kiinnostavan ketään, ISO 20000:n uusi versio sensijaan on nousussa. Sosiaalinen media alkaa ilmeisesti kiinnostaa, koska hashtag on yllättävässä nousussa. Vanha juttuni Tiedätkö mikä on hashtag on 17. luetuin.

Huom, hakusanoja on luokiteltu aiheen mukaan ja olen luokitellut hakusanoja vähän eri tavalla kuin vuosi sitten tehdyssä vertailussa, nyt yhdistin kaikki itil-haut yhteen, edellisessä ne on eroteltuna, esim itil koulutus jne.

Tässä vielä hakusanojen sijoitus listoilla. BYOD ei esiintynyt vuonna 2011 kertaakaan.

aihe v2012 v2011
itil 1 1
iso 20000 2 3
merimerkit 3 19
itil v3 4 2
hashtag 5 11
palvelukatalogi 6 6
pohjoisviitta 7 4
ISO 20000:2011 8 18
muutoksenhallinta 9 8
byod 10
insidentti 11 5
prosessit 12 16
service desk 13 12
aale roos 14 13
häiriönhallinta 15 17
elinkaari 16 21
ongelmanhallinta 17 8
konfiguraationhallinta 18 15
itil 2011 19 18

 

 

Onko incident suomeksi häiriö?

Huomasin että useampi henkilö oli päätynyt sivuilleni otsikon kysymyksellä. Lyhyt vastaus on: kyllä, sillä itil on muuttanut käsitteiden sisältöä.

Pitempi vastaus on, että riippuu versiosta ja ei kannata uskoa mitä itil sanoo. Alkujaan insidentti oli yleistermi kaikille käyttäjien pulmille. Sitten siihen lisättiin myös tekniset häiriöt, joilla ei välttämättä ole mitään kytkentää johonkin nimettyyn käyttäjään ja lopulta siitä tuli puhdas häiriönhallinta. Tekninen häiriönhallinta on aivan eri prosessi kuin asiakastuki ja tämä on unohtunut itilin päivittäjiltä. Tämä on siis itilin uusimman version pulma.

Rhett Glauser ServiceNowlta sanoo: ”ITIL has hampered tool innovation and real vision for years” ja tämä on iso ongelma juuri asiakastuen kannalta. Itil 2011 mukainen työkalu ei toimi.

Help desk hengissä

Olen havainnut että help deskit ovat alkaneet taas kiinnostamaan, kursseilla on kysyntää ja toimeksiannot liittyvät tuen kehittämiseen. Keksin tarkastaa asian Googlesta ja sain vahvistuksen. Alla olevassa kuvassa on kolmen hakusanan vertailu. Sininen on help desk, punainen on ITIL, ja keltainen service desk. (Huom. kohteena on USA koska itil tarkoittaa indonesiaksi erästä naisen elintä ja se on liian kiinnostava.)

Kuva kertoo kaksi mielenkiintoista asiaa. Ensinnäkin, itilin service desk ei ole lainkaan niin kiinnostava kuin perinteinen help desk. Tämä yllätti minut. luulin että service desk on ollut korvaamassa vanhaa termiä.

Toinen havainto on että itilin ja help deskin kiinnostavuus ovat kuin peilikuvat. Itil oli kasvussa vuoteen 2007 asti, josta alkoi jyrkkenevä alamäki. Help desk taas oli laskussa vuoteen 2008 asti, mutta on nyt hienoisessa nousussa.

Oma tulkintani on se, että ihmiset alkavat tajuavan totuuden itilistä, eli parhaat käytännöt eivät täytä lupauksiaan. Uusi 2011 edition taas sisälsi sen myönnytyksen että V3 oli täynnä virheitä.

Toisaalta taas help deskiin kohdistuu uusia haasteita ja niihin kaivataan uusia ratkaisuja. Asiakkaiden vaatimukset muuttuvat ja niihin on vaikea vastata vanhalla mallilla.

Service Desk 2.0 -malli, jota olen kehittelemässä, on yritys vastata muuttuneeseen tilanteeseen. Pitäisiköhän alkaa sittenkin puhua Help Desk 2.0;sta?

 

ITSMF konferenssi

Oli hauska tavata paljon tuttuja ihmisiä hyvin järjestetyssä konferenssissa, kiitokset vain järjestäjille.

Oma esitykseni meni omasta mielestäni hyvin. En ole koskaan saanut niin paljon spontaania positiivista palautetta esityksestäni. Kerroin että itilissä on jotain hyvää, mutta todella paljon puutaheinää. Ilmeisesti moni on tajunnut sen, mutta ei ole uskaltanut väittää vastaan ja koki nyt helpottavana kuulla, että ei ole yksin epäilyksissään. Eräs tuttu kertoi tulleensa koko tilaisuuteen esitykseni takia. Hän opiskeli itilin jatkokursseja kohti Expert-tasoa ja sanoi alkaneensa epäillä saamaansa oppia ja halusi kuulla mitä sanoin. Tässä esitykseni (pdf) itSMF 2011 esitys v21 Siinä leikkaan läskin pois itilistä ja katson mitä jää jäljelle.

Minulla oli kiinnostava keskustelu Mark Smalleyn kanssa. Hän edustaa organisaatiota, joka yrittää kehittää linkkiä it palvelunhallinnan ja it:n välille. He tekevät hyvää työtä, mutta näin pulmana miten ihmeessä näihin ei-it ihmisiin saisi yhteyden. Tarkoitan siis niitä ihmisiä, jotka tekevät it-päätöksiä it:n ulkopuolella. Minulla oli ajatus siitä miten asiaa voisi lähestyä ja Markin mielestä ajatukseni olivat niin kiinnostavia että hän lupasi oman esityksensä aluksi siitä jo white paperin yhdessä kanssani  (joka siis tuli minulle yllätyksenä). Kirjoituksemme tulee perustumaan tutkimukseen, jonka teemme Suomessa. Tulen siis tarvitsemaan apuanne sen kanssa mutta siitä lisää myöhemmin.

 

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: