Epäonnistumiset

Tällä kertaa pikakyselyn aiheena olivat epäonnistumiset:

Edellinen pikakyselyni keskittyi positiiviseen kehitykseen. Nyt aiheena ovat epäonnistumiset. Tehdyistä virheistä oppii ja sitäkin oppia olisi hyvä jakaa toisille. Tässä maassa on vielä yllättävän paljon organisaatioita, jotka vasta ottavat ensiaskeliaan palvelunhallinnan alueella. Kysymykseni on siis:

 Millaisia epäonnistumisia tai virheitä olet nähnyt it-palvelunhallinnan tai asiakastuen kehittämisessä?

 Voit vastata yhtä hyvin asiakkaan, palveluntarjoajan, tekijän tai päättäjän roolista. Kaikki vastaukset ovat luottamuksellisia, enkä mainitse vastaajien tai heidän edustamiensa yritysten nimiä missään.

Kyselyyn tuli 60 vastausta, joskin jotkut vain onnittelivat 60-vuotispäiväni johdosta. Yksittäiset vastaukset on tarvittaessa pilkottu osiin, jos niissä kuvataan useita epäonnistumisia.

Epäonnistumiset

Vastausten luokittelu ei ollut helppoa, mutta mielestäni kuvauksissa löytyi tiettyä samanlaisuutta. Toki vastauksia voisi luokitella muillakin tavoilla. Koska vastaukset ovat yksilöllisiä, julkaisen ne kaikki pdf-liitteenä. Osaa teksteistä on hiukan muokattu. Olen nostanut muutaman kommentin tekstin sekaan, tunnistat ne kursiivista. Kannattaa lukea kaikki vastaukset, siellä on todella paljon hyviä huomioita.

Kärkeen nousivat suunnittelun ongelmat.  Seuraavina ovat johtaminen, jalkautuksen epäonnistuminen ja asiakasnäkökulman unohtuminen.

Suunnittelu

Lähes puolet epäonnistumisista liittyy hankkeen suunnitteluun. Sitä ei tehdä tai se tehdään liian kevyesti. Yritetään haukata liian suurta palaa tai uskotaan että ostettu työkalu ratkaisee ongelmat. Asiaa ei varmastikaan auta itilin paisuminen. Ydinasia katoaa kymmenien prosessien sekaan. Liian paljon yrittäminen yhdellä kertaa on melko tavallista ja tähän tavallaan myös kannustetaan. Itil sisältää lukuisia prosesseja ja erilaisten tutkimusten mukaan ne ovat mukamas monilla käytössä. Syntyy helposti sellainen harha, että ne kaikki prosessit pitäisi ottaa nopeasti käyttöön. Riman nostaminen itilin innoittamana liian korkealle, jolloin ei tapahdu mitään

Tekniikan ylikorostaminen on virhe, johon olen itse törmännyt usein ja oikeastaan hämmästelen sitä, kuinka harvoin se mainitaan. Luulen, että tämä on todellisuudessa yleisempää. Hankitaan konsultti määrittelemään prosessit ja räätälöimään työkalut. Sitten ihmetellään miksi prosessi ei toimi. Työkalut ja prosessit ovat ihan yhtä hyödyllisiä kuin vaikka kuntoiluvälineet ja laihdutusoppaat, niiden ostaminen ja asentaminen eivät auta, ellei niitä myös käytetä. Kyllä epäonnistumiset ovat olleet minun kohdallani liikaa keskittyminen tekniikkaan. Prosessit pitää olla kunnossa ja ihmisten osaaminen myös.

Ulkoistamisella on aika huono maine, mutta tässä kyselyssä se ei noussut kovin korkealla. Näissä esimerkeissä näkyy lisäksi se totuus, että kun kahden osapuolen yhteistyö epäonnistuu, niin syytä on usein molemmissa. Sopimisen ja toimittajan valinnan merkitys nousee hyvin esille ulkoistusta käsittelevässä pitkässä vastauksessa (on taulukossa viimeisenä, linkki tämän jutun lopussa). On mielenkiintoista että palvelu ensiksi ei toimi yhden kumppanin (iso, valtakunnallinen) kanssa ja sitten toimii samalla henkilöstöllä, mutta eri toimintamallilla ja eri kumppanin (pieni, paikallinen) kanssa.

Tähän pitää nostaa erään asiakkaani lausunto: Joskus on tullut tehtyä myös sellaisia virheitä, että pidempään puuhaillaan yrityksen sisällä.  Asiat eivät tahdo kehittyä.  Verkostoitumalla ulospäin ja pyytämällä ulkopuolista apua (tämä aito mielipide eikä syntymäpäiväsankarin lahja) saadaan monesti nopeammin kehitystä aikaan.  Suunnittelu on juuri se vaihe, jossa kannattaa käyttää ulkopuolista apua, pienellä vaivalla voi välttää suuren virheen.

 

Johtaminen

Johtamisen ongelma on johtamisen puute. Eräs virhe: unohdetaan normaali esimiestyö eli asiakastukea tekevien työntekijöiden normaali esimiestyö eli esimerkiksi ”päivittäinen lätinä esimiehenkin kanssa”, säännölliset ryhmäpalaverit, säännölliset kehittämispäivät ja säännölliset kehityskeskustelut. Meillä insinööreillä on taipumus luulla, että kunhan prosessikuvaukset ja palveluprosessit ovat kunnossa, se riittää. Mutta ihmisten työn johtaminen vaatii muutakin.

Palveluhallinnan kehittäminen on haastava muutosprojekti, eikä se onnistu ilman johdon panosta. Itse näen johtamisen olevan suurin ja yleisin este kehittämisen onnistumiselle. Jos konsultti on palkattu, niin suunnitteluun yleensä halutaan panostaa, mutta silti hanke voi epäonnistua. Johto käynnistää hankkeita, mutta ei vie niitä loppuun asti.

 

Jalkautus

Jalkautus on prosessin käyttöönoton hankalin vaihe. Tiedämme, että itil-prosessien jalkautus on osoittautunut vaikeaksi. Jalkautus jää kesken, sen vaikeus aliarvioidaan.  Suunnitelmien toteuttaminen epäonnistuu erilaisista syistä johtuen. Jalkautusta ei mielestäni voi ostaa palveluna, konsultin käyttö kertoo, ettei organisaatio ota asiaa tosissaan. Prosessien jalkauttamisessa pahimmat virheet on tapahtunut esimerkiksi itil – sanan korostamisella. Huonosti hoidettu ja turhaan itil:iä korostava jalkautus sai jossakin vaiheessa aikaan koko sanalle todella huonon maineen. Henkilöstön luottamus prosessien kehittämisen perimmäiseen syyhyn ei päässyt kasvamaan tämän esteen vuoksi.

 

Asiakasnäkökulma

Asiakasnäkökulman unohtaminen on paha virhe palveluorganisaatiolle, tosin kyllähän se unohtui itilin kolmosversiostakin. On helppoa sukeltaa liian syvälle it-maailman hienouksiin ja alkaa nähdä asiakkaat vain häiriötekijänä. Joskus törmää jopa vihamielisiin asiakassuhteisiin. Palveluasenteen unohtuminen on samaa asiaa. Kysymykseesi vastauksena tuli ensimmäisenä mieleen it:n itsekeskeisyys – eli luodaan palveluita ja prosesseja, joiden tarpeellisuutta tai käytännöllisyyttä suhteessa palvelun hintaan ei ole asiakkailta tai palvelun käyttäjiltä kysytty tai tarvetta määritelty. Eli toteutetaan it:n omaa käsitystä millaista palveluntuottamisen pitäisi olla.

 

Vastaukset

Tässä kaikki vastaukset sisällön mukaan lajiteltuna (pdf): epäonnistumiset

60 vuotta

Tänään tuli 60 mittariin, jotenkin tuntuu kuin sisällä asuisi vielä se parikymppinen, joka on sitä mieltä että vanheneminen on jotain sellaita mikä tapahtuu muille.

En aio juhlia mitenkään erityisesti, normaali työpäivä siis. Ajattelin kuitenkin muistella vähän menneitä tämän it-maailman näkövinkkelistä.

Oma urani tietotekniikan parissa alkoi tietojenkäsittelyn opiskelulla. Se oli reikäkorttien ja teletypen aikaa. Varsinainen työnteko alkoi kun olin kesätöissä Wärtsilällä analysoimassa jäänmurtamiskokeiden tuloksia. Valitsin laboratorioomme ensimmäisen pöytätietokoneen ja plotterin ja aloin vääntää koodia Basicilla. Graafista tietojenkäsittelyä 70-luvun alkupuolella siis. It-palvelutoimintaan tutustuin sitten Jyväskylän yliopiston laskentakeskuksessa, kun autoin tutkijoita ja opiskelijoita tietokoneen käytössä. Sieltä siirryin VTT:lle jossa vastasin tilastollisesta tietojenkäsittelystä. Tämän jälkeen lähdin Tietotehtaalle, jossa minut nimitettiin muutaman vuoden jälkeen asiakaspalvelun päälliköksi ja perustin ensimmäisen help deskini 80-luvun puolivälissä. Silloin olimme jo siirtyneet näyttöpäätteiden aikaan ja meillä oli myös ensimmäinen PC käytössä.

Help deskin perustaminen ei mennyt kovin mallikkaasti, keskityin liikaa tekniikkaan ja liian vähän ihmisiin. Puhelinjärjestelmän käyttöönotto meni kompuroinniksi ja ostamani help desk ohjelmisto taisi olla virhehankinta, mutta perustamani help desk toki toimii edelleen. Itse en jäänyt sitä katselemaan, vaan loikkasin konsultiksi. Konsultointi DPM Consulting Oy:ssä keskittyi heti alusta vain it-palvelunhallintaan. Olimme silloin uranuurtajia alalla Suomessa. Pari vuotta myöhemmin perustimme myös Help Desk Institute Nordicin ja keskityin konsultoimaan ja kouluttamaan help deskejä.

90-luvun aikana yhteydenpito asiakkaitten kanssa muuttui. Aluksi lähetimme kirjeitä, palkkasin yleensä koululaisia kirjeiden postituksiin, mutta tuli sitä tehtyä itsekin. Jossain välissä faxaaminen tuli muotiin ja opettelin lähettämään faxeja suoraan PC:ltä. Sähköposti ja internet yleistyivät 90-luvun loppupuolella. Pystyin olemaan tässä edelläkävijä, koska asiakaskuntani oli myös edellä muita. Fax menetti pian merkityksensä ja samoin kirjeet. Tiedottaminen ja markkinointi siirtyi verkkoon.

Jotenkin tuntuu siltä, kuin kehityksen vauhti olisi hiipunut vuosituhannen vaihteen jälkeen. Jos vertaa vuosia 1990, 2000 ja 2010 niin kyllä harppaus 1990-2000 on paljon suurempi kuin sitä seurannut kehitys. Olemme toki saaneet älypuhelimet, sosiaalisen median ja tabletit, mutta työni kannalta niillä ei ole ollut samanlaista vaikutusta kuin siirtymisellä paperista nettiin. Vuonna 1990 viestintä tehtiin lankapuhelimella ja kirjeillä.

It-palvelunhallinnassa nämä vuodet ovat olleet tosiaan ymmärryksen hidasta kehitystä, kuten viimeisin kyselyni positiivisesta kehityksestä kertoo. Ensiksi toin help desk -toimintamallia Suomeen. Se rantautui hyvin, käytännöllisesti katsoen kaikki hankkeet onnistuivat. Vaikka helppareita on kritisoitu paljon, niin ne olivat kuitenkin merkittävä kehitysaskel parempaan palveluun. Seuraava isompi kehitysaskel oli itil. Se kolahti lopulta 2000-luvun alkupuolella, mutta sen tulokset ovat olleet paljon vaatimattomampia. Itilin todellinen soveltaminen on osoittautunut vaikeaksi ja työ on vielä kesken.

Tästä eteenpäin jatkan konsultointia, koulutusta ja tutkimusten tekemistä mutta haen uusia näkökulmia. Olisi esimerkiksi mielenkiintoista kehitellä parempia asiakastyytyväisyystutkimuksia tai menetelmiä potentiaalisten ongelmien löytämiseen. Ota yhteyttä jos tällainen asia kiinnostaa.

 

Ongelmanhallintaa

Pidän ensi tiistaina 20.9. klo 15 webinaarin ongelmanhallinnasta Brightalkilla. Siihen on ilmoittautunut jo 75 kuulijaa. Tervetuloa kuuntelemaan, webinaari on maksuton ja englanninkielinen.

Olen pitänyt yhden webinaarin Brighttalkilla aiemmin. Kokemus on vähän outo, kun yleisöä ei näe. Auttaa ymmärtämään paremmin miksi tv-ohjelmissa käytetään studioyleisöä.

 

 

Kompurointia

Tämän päivän Hesarissa huomasin kolme juttua tietojärjestelmien käyttöönoton vaikeuksista. Kohteena olivat VR:n uusi lipunmyyntijärjestelmä, Helsingin kaupungin AHJO ja potilastietojärjestelmien yhdistäminen. Näistä vain AHJO eli Helsingin kaupungin asianhallintajärjestelmä vaikuttaa it-palvelunhallinnan tontille kuuluvalta asialta.

VR:n järjestelmä näyttää toimivan nyt seuraavana päivänä hyvin ja VR sai paljon julkisuutta lippu-uudistukselleen. Ruuhkaa syntyi osin siitä, että joulun-ja hiihtolomien aikaiset liput laitettiin myyntiin samalla kertaa ,eli aiheutettiin kuormituspiikki juuri uuden järjestelmän opiskeluvaiheeseen. Lisäksi verkkomyynnin kävijämäärää kuormittivat monet uteliaat. Päätöksen takana lienee (huonosti harkitut?) kaupalliset syyt. (syytä päivittää*)

Kuntien potilastietojärjestelmä on taas poliittinen asia ja seurausta kuntien autonomiasta. Sama näkyy kaikissa vastaavissa organisaatioissa. Eräällä pankilla oli aikoinaan käytössä lukuisia erilaisia help desk-järjestelmiä, koska keskitetty ohjaus puuttui. Itsenäiset päättäjät halauvat tehdä itsenäisä päätöksiä. Eräs asiakkaani tarjoaa kohderyhmälleen ilmaiseksi yhteisen ratkaisun. Silti se ei kelpaa kaikille, vaan jotkut pienet, köyhät yksiköt maksavat saadakseen oman, vastaavan tuotteen. Kuntien erilaisten järjestelmien yhdistämisestä tulee kallis sotku, kun parempi vaihtoehto olisi pakottaa kaikki käyttämään yhtä järjestelmää, mutta se olisi poliittinen päätös.

AHJOn ongelmat nousivat esiin jo elokuussa ympäristölautakunnan kokouksessa, mutta silti varsinainen käyttöönotto epäonnistui hyvin näkyvästi.Vaikea sanoa syytä miksi AHJOn käyttöönotto epäonnistui, mutta ehkä perääntyminen on liian vaikeaa. Olin koekäyttäjänä EXINin uudelle tenttientilausjärjestelmälle pari vuotta sitten. Kokeilu epäonnistui täysin, en kyennyt edes testaamaan järjestelmää, koska se oli niin vaikea. Raporttini ei vaikuttanut mitenkään EXINin suunniteltuun aikatauluun vaan uusi järjestelmä otettiin käyttöön maailmanlaajuisasti. Käyttöönotto oli täysi floppi. EXIN ei kyennyt itsekään käyttämään järjestelmäänsä ja tenttien tulosten saanti viivästyi. Soppa johti lopulta toimitusjohtajan vaihtoon ja kokonaan uuden järjestelmän tilaamiseen. EXIN olisi säästynyt paljolta murheelta, jos uusi järjestelmä olisi vain hylätty.

Huonojen päätösten peruminen on vaikeaa. Jos testi epäonnistuu, käyttöönotto pitäisi perua vaikka siitä seuraisi ikäviä asioita. Lokomotivin lentokone lähti liikkeelle ilmeisesti käsijarru päällä eikä keskeyttänyt lentoonlähtöä kun virhe havaittiin.

*) Nyt VR:n sekoilu on jatkunut jo melkein viikon ja paljastaa että kyseessä on tosiaankin it-palvelunhallinnan täydellinen ja näyttävä mahalasku. Accenture ja Tieto pahoittelevat ja VR selittää häiriön aiheutuneen volyymeistä. Hanke tilattiin Accenturelta 2008 joten kyseessä on ollut mittava työ. Ihmeellinen juttu, eikö nyt maailmalla olisi ollut lukuisia valmiita järjestelmiä, pitääkö rakennuttaa oma monen vuoden projektina.

Kiitos Twitterin, löysin henkilön, jonka CV:ssä kerrotaan että VR:n järjestelmän testaaminen ja käyttöönoton hallinta oli ulkoistettu ilmeisesti Intiaan. Näin ko. henkilö kuvaa tehtäviään:

Working as Transition Test Consultant/Manager for VR New Sales System which is slated to Go Live in Jan 2011

 Primary Responsibilities:

 Establish the Test Process in Finnish Rail

  • Define the Test Strategy and Test Plan
  • Establish the Onshore and Offshore Communication Channels
  • Effort Estimation and Budgeting
  • Build Onsite and Offshore Team
  • Define a Work Plan and Monitor the Progress
  • Transition Work to Offshore
  • Establish the Test Environment and Connectivity to Offshore
  • Identify the Automation Scope and
  • Coordinate and Manage Overall Testing Activities

My Role is to establish the Test Process and Team in Finnish Rail and transition the Testing Activities to Offshore. And manage the project delivery from offshore. 

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.

Luovuus

Olen yrittänyt usean päivän ajan saada syksyn itSMF -esitystäni valmiiksi pääsemättä alkua pidemmälle. Tuntui siltä että esitykseni aihe oli vähän liiankin haastava:  Pyhä ITIL – mikä toimii ja mikä ei. Ei ole ihan helppoa mennät tekemään tuollainen rajaus. Nyt sitten tänään yhtäkkiä ajatukset loksahtivat paikoilleen ja esitys syntyi hienossa flow-tilassa muutamassa tunnissa.  Ainakin nyt tulos tuntuu todella hyvältä.

Huomasin että olen pyörinyt jotenkin itilin ja omien ajatusteni kanssa, ikäänkuin aidalla osaamatta valita puolta. Tämä tuli hyvin esille asiakasprojektissa, kun materiaalieni termit olivat pahasti solmussa, käytin välillä yhtä sanaa, välillä toista ja asiakas moitti aiheesta.  Asiaa auttoi myös Efecten uuteen tuotteeseen tutustuminen. Kirjoitin tällä viikolla Reittisuunnnittelu-tiedotteessa (jos haluat päästä jakelulistalle, klikkaa ”Reittisuunnittelu-tiedotteen tilaus” oikeassa reunassa) Efecten hienosta oivalluksesta. Heidän uusi tuotteensa (pdf) vauhdittaa palvelujen tilaamista ja säästää kaikilta aikaa. Tuote on näppärä ja hyödyllinen, mutta siinä on  pikku kauneusvirhe. Heidän demomallissaan ensimmäinen tilattava tuote on ongelma. Havainto vahvisti hienosti näkemystäni että itil-mallissa on valuvika.

Efecten innovaatio, asiakkaan kriittisyys ja haastava otsikko pistivät siis ajatukseni liikkeelle. Sain ajatukseni kirkkaaksi ja pystyn selittämään asiat selkeämmin. On hauskaa tehdä töitä, kun saa tulosta aikaiseksi, mutta valitettavasti tuota luovaa tilaa ei ole helppo saada aikaan. Pelkkä aika ja rauha eivät riitä, pitää olla sopivasti ärsykkeitäkin.

 

 

 

%d bloggers like this: