maanantai 7. joulukuuta 2009

IT Service Balanced Scorecard

Viime perjantaina ITIL-koulutuksessa esitettiin kysymys, voiko IT-palveluille tai palveluille ylipäätään määritellä tuloskorttia. Lupasin koota jotain aiheesta - tässä asiasta lyhyesti.

BSC - Balanced Scorecard
 
Tuloskorttiinhan kerätään seuraavia ristikkäisiä mittareita:

- Talous
- Asiakas
- Sisäiset prosessit
- Oppiminen ja kasvu

Tällä tavoitejohtamisen mallilla ohjataan toimintaa haluttuun suuntaan, ja mittarit määritellään sen halutun suunnan mukaan. Mallihan ei ole kovin vanha, sen esitteli Kaplan 1992.

Miten ne mittarit sitten löydetään?

Mittarit kannattaa määrittää järjestelmällisesti. Selkeyttä antaa 7-step improvement prosessi - määritä ensin mitä pitäisi mitata ja sitten valitse niistä mittareista ne joita voi mitata järkevällä kustannuksella.

Continual Service Improvement antaa yksinkertaisen mallin mittareiden määrittelyyn visiosta konkreettiseen mittariin. Esimerkki:

Visio - esim. olla se halutuin palvelutoimittaja
Missio - miten visio toteutetaan - esim. saavuttamalla keskiarvoa parempi asiakastytyyväisyys
Tavoitteet - millä missio saavutetaan, vaikkapa korkeampi prosessimaturiteetti ja ITIL Service Level Management -prosessin käyttöönotto
Kriittiset menestystekijät - luoda liiketoiminnan ja IT:n yhteinen suunnittelumalli, saavuttaa korkeampi maturiteetti ainakin parissa ITIL-prosessissa ja ottaa käyttöön järjestelmällinen palvelutasojen hallinta (ja SLA:t) pääpalveluissa
Menestyskriteerit (KPI) - liiketoiminnan ja IT:n yhteiset suunnittelukokoukset, ITIL-maturiteettitaso ja SLA:t tehtynä
Mittarit - 2 vuodessa, maturiteetti 2,5, 2 SLA:ta
Mittaus - suunnittelukokousten pöytäkirjat, arviontiraportti, allekirjoitetut SLA:t

Viemällä nuo mittarit aivan käytännön tasolle, ne saattavat jopa toimiakin. Jonkun henkilön täytyy vielä olla kiinnostunut siitä, että mittari toteutuu - selkeät roolit ja vastuut pitää osoittaa.

Sopivia palvelumittareita tuloskorttiin
Keräilin nyt muutaman sopivan PALVELUmittarin esimerkiksi - tältä ne voisivat näyttää:


Talous
- Palvelun liikevaihto
- Budjetti / todellinen kustannus

Asiakas
- palvelun saatavuus asiakkaalle (päästä päähän -mittaus)
- palvelun laatu (reklamaatiot, käyttäjätyytyväisyys..)
- palvelun suorituskyky
- palvelukatalogin kattavuus vs. liiketoiminnan tarpeet

 Sisäinen
- palvelun toimitusajat - palvelutasojen saavuttaminen
- prosessikyvykkyys
- henkilöstön käyttöaste

Oppiminen ja kasvu
- IT-henkilöstön ja käyttäjien koulutustoteuma
- uusien teknologioiden havaitseminen ja hyödyntäminen
- ratkaisutietokantojen kehittäminen, hyödyntäminen

 Lähtisikö se siitä?

maanantai 30. marraskuuta 2009

EVA-raportti osuu ja upottaa - nyt tarvitaan Palveluita

Viime viikolla julkaistu Elinkeinoelämän valtuuskunnan raportti Suomen yhteiskunnan tietoteknisestä tilasta osuu aika hyvin kohdilleen. Jostain syystä tietoyhteiskuntakehitys on suuntautunut vahvasti infran rakentamiseen.  Varsinaiset palvelut ovat jääneet vähemmälle huomiolle tai niitä on rakennettu sirpaleina. Perustaa on siis rakennettu kovaa tahtia mutta tavoiteltua lopputulosta, palveluita, ei ole mietitty riittävästi. Yksi parhaista esimerkeistä on HST-kortti, jossa tunnistautumiseen rakennettiin hieno tekninen ratkaisu. Harmi vain, ettei oikein ole ollut mitään palvelua, jota kortin tunnistautumisella voisi käyttää.

Olen seurannut yrityksemme kautta Saksan valtionhallinnon Bundonline 2005 -hanketta. Siellä valtio panosti tosissaan yksinkertaisten peruspalveluiden rakentamiseen ja esim. suuri osa julkishallinnon toimijoista - virastoista, kunnista, toimialueista kuten oikeuslaitos eri haaroineen - käyttää yhtenäistä sisällöntuotantoalustaa. Aika triviaalia? Säästö erillisiin projekteihin verrattuna on kuitenkin huikea. Ja kuten EVA-raportissakin kannustetaan - näitä jaetaan hallintokunnille maksutta.

Miten tilannetta sitten voisi lähteä pelastamaan? Jos visio vaikka olisi nostaa Suomi e-demokratiassa ensin Kiinan ja Mosambikin ohi tai vaikkapa kehittää oikeasti tarpeellisia ja käyttökelpoisia palveluita, pitää tietenkin tarkistaa ensin nykytilanne. sen pohjalta voi päättää tavoitetilan ja keinot sinne pääsemiseen. Tärkeää on asettaa mittarit - päästiinkö - muuten rämmitään suossa ja lopulta saapas tarttuu kiinni ja tappaa innovaation.

Mikä pitäisi olla valtion palveluportfolio? Kehittämiseen löytyy jälleen toimivia työkaluja - tiedätte kyllä mistä. Define, analyse, approve, charter - palveluportfolion hallintaa! Kehitetään järjestelmällisesti uusia palveluita asiakkaiden - siis kansan - tarpeisiin. Varmaan noista raporttiin kirjatuista kärkimaista löytyy hyviä valmiita ehdokkaita näin alkuun, innovoidaan sitten vielä parempia kun perusasiat ovat kohdillaan.

maanantai 23. marraskuuta 2009

Mitä ihmettä - ITIL loppui?!

Jokunen aika sitten OGC julkisti ITILv2-tuen loppumisaikataulun - ei se ITIL oikeasti mihinkään katoa. Mitä tämä nyt sitten oikein tarkoittaa käytännössä?

Käytännön prosessityössä muutoksella ei ole pahemmin vaikutusta, vaan se kohdistuu lähinnä koulutuksiin. ITILin versioiden väliset prosessien erot ovat hienosäätöä ja uudet kirjat tarjoavat paljon lisää työkaluja, templateja, roolikuvauksia, tukea organisointiin jne.

Käytännössä muutos näkyy oikeastaan eniten niin, että ITIL Foundation -kursseja ei enää järjestetä versiosta 2. En kyllä ole kuullut enää hetkeen kenenkään niitä käyneenkään, vaan kysyntä on kohdistunut v3 Bridge-kursseihin ja v3 Foundation -kursseihin, eli vaikutus on tältä osin pieni.

Merkittävämpi on ehkä tuo Manager Bridge -kurssien loppuminen, ei toisin ihan heti. "Helppo tie" ITIL Expertiksi umpeutuu ja tittelin halutessaan JOUTUU käymään ITILv3 Intermediate -kursseja. Kursseissa on tietenkin se hyvä puoli, että niillä yleensä oppii asioita - niin näilläkin. Foundation-kurssi on nimensä mukaisesti perusteita - 2,5 päivässä ei kovin syvälle mennä mihinkään asiaan - ja nämä intermediatet antavat jo valmiuksia soveltaa malleja käytäntöön. Palvelulähtöinen ajattelu tosiaan avaa uusia näköaloja, suosittelen.

Miksi sitten edes tarjotaan Manager Bridgejä? Yleensä Service Manager -kurssin käyneet ovat jo hyödyntäneet oppejaan käytännössä, ja näin oppineet soveltamaan perusprosessimalleja. Manager Bridge on nopea sukellus v3:n tuomiin uudistuksiin ja tentti on vaikea. Motivaation täytyy olla kohdallaan ja asiaan pitää keskittyä kurssin aikana, tentti ei ole helppo.

ITIL-koulutus kokonaisuutena on n. 27 luokkapäivää tentteineen, lisäksi jonkin verran kotiopiskelua. Onko se sitten paljon vai vähän - 8-12 opintopistettä eli vanhan maailman opintoviikkoina 5-8. Jo perusmatematiikan kurssit ovat laajempia.

Tietenkin kursseja voi käydä vasta kun työkokemusta on kertynyt ja firma pystyy niitä kustantamaan. Tähän mennessä minulle on kyllä ollut näistä kursseista enemmän hyötyä kuin TKK:n phuksimatematiikasta, jonka jätinkin varmuuden vuoksi aikanaan viimeiseksi tentikseni.

Seuraavan kerran pidän ITIL Service Manager Bridge -kurssia 18.-22.1.2010 - tule mukaan tai tsekkaa jokin toinen pitämäni kurssi täältä


 Tässä vielä ITIL-kurssirakenne - voila!


perjantai 13. marraskuuta 2009

Voisiko IT-tuotanto olla Suomen ydinteollisuutta?

Paperit ja vaatteet tehdään jo melkein täysin Kiinassa tai muussa Intiassa. Tuotannollinen työ ja teollisuus siirtyy kovaa vauhtia kohti halpamaita.

Jostain syystä Google osti yhden paperitehtaan ja alkoi tuottaa siellä hakupalveluita. Voisiko IT-tuotanto olla se seuraava suomen tuotantotyö? Tämä vaatisi tietenkin valmiutta tehdä sitä tuotantotyötä tehokkaasti ja taidolla - käytännössä siis näitä tuotantotyöntekijöitä pitää kouluttaa.

Tämä teksti julkaistiin myös tämän päivän Tietoviikossa

IT-tuotannon osaajia pitää kouluttaa

Suomi on IT-innovaation huippu. Suomessa kehitetään maailman parhaita ohjelmistoja ja tuotetaan korkeatasoisia osaajia ohjelmistoliiketoiminnan tarpeisiin . asiantuntijoista johtajiin. Tämä kyvykkyys on luonut useita globaaleja menestystarinoita - SSH, F-Secure, Solid, BaseN, Basware, Mysql, Linux ja mahtava Nokia. Uusi Aalto-yliopisto on perustanut tämän innovaation edelleen kehittämistä varten oman Service Factoryn, joka tuottaa jatkossa yhä kyvykkäämpiä
huippuosaajia. Tulevaisuus on tältä osin valoisa.

Nykyään Suomen kaikki liiketoiminnat ovat riippuvaisia tietotekniikasta. Paperikoneita on pyöritetty jo vuosikymmeniä tietotekniikan optimoimana. Pankit toivat tietokoneet Suomeen, ja nyt suurin osa tapahtumista hoidetaan tietokoneiden välityksellä. Junia ja lentokoneita ohjataan tietokoneilla ja jos logistiikkaratkaisu ei toimi, on Turun moottoritie rekkojen tukkima . ei vain tunnelien sulkemisen vuoksi.

Suomalaisen yhteiskunnan koko toiminta on siis riippuvaista IT-ratkaisujen luotettavasta tuotannosta ja tietoteknisten ratkaisujen toimivuudesta. Suomessa ei kuitenkaan kouluteta riittävästi tietotekniikan tuotantoa. Käytännössä kaikki osaajat ovat itseoppineita, alansa käsityöläisiä. Eivät he syyttä ole osamisestaan ylpeitä, nykyaikainen IT-infrastruktuuri on niin monimutkainen, ettei sitä ihan kuka tahansa saakaan pysymään toiminnassa.

Tämä ei voi jatkua näin. Osaajia ei ole riittävästi jokaisen hätätilanteen sankarilliseen pelastamiseen. Sankaritekoja ei pitäisi edes tarvita, vaan tietotekniikan pitäisi vain toimia. Kukapa nyt olisi vielä viisi vuotta sitten uskonut, että moottoritie ei toimi kun se pitää bootata?
Vai hyväksymmekö tosiaan sen, että tietotekniset palvelut ovat aina hyvin epävarmoja?

Tietotekniikan tuotantoon on olemassa hyviä, valmiita malleja. Peruskehyksenä löytyy ITIL, jonka malleja hyödyntämällä voidaan välttää IT-tuotannon pyörän uudelleen keksiminen. Muitakin malleja toki on . COBIT auttaa sopimaan rajapintoja, ISO20000 osoittaa
jo jotain IT-palveluorganisaation kyvykkyystasosta.

Näitä metodeja ja yleisesti tuotantotoimintaa on nyt alettava kouluttaa Suomessakin. Viimeisten vuosien aikana koulutusohjelmia on pullahdellut maailman yliopistoihin tarjolle paljon. Tanskassa (Kööpenhaminan yliopisto) koulutetaan ITIL-koulutusrungon mukaisesti tieteellisellä
tasolla, Saksassa korkeakoulut mahdollistavat jopa sertifiointitentin ja Englannista löytyy jo Master-tason tutkinto IT-palvelunhallinnasta. Yhdysvalloissa näitä ohjelmia ja tutkintoja
löytyy jo kymmenittäin.

Palvelutuotannon kehitys on tällä nuorella teollisuudenalalla saanut viime aikoina paljon vauhtia. Yritykset ovat kouluttaneet henkilöstöään kaupallisilla kursseilla, mutta jatkokehityksen varmistamiseksi pohja täytyy luoda jo peruskoulutuksen aikana. Tämä on itsestään selvyys
monilla aloilla - tuskin meistä kukaan hyväksyisi kirjavasti koulutettuja, itseoppineita lääkäreitä tai lakimiehiä.

Suomen teollisuus perustuu tietotekniikkaan ja hyvällä koulutuksella tietotekniikan tuotannosta voi tulla Suomelle merkittävä teollisuus. Perustetaan siis Suomeen tietotekniikan tuotannon koulutus, mieluiten heti.

Timo Hyvönen
itSMF Finland
Tutkimustyöryhmän johtaja
IT-ammattilainen (sattumalta) vuodesta 1989
DI, ITIL Expert

IT Service Management Forum Finland ry on itsenäinen, voittoa tavoittelematon yhdistys. Tavoitteenamme on edistää parhaiden toimintatapojen (ITIL Best Practices) käyttöä it-palvelujohtamisessa (IT Service Management) ja palveluiden kehittämisessä. Suomen lisäksi itSMF toimii yli 50 maassa ja on ainoa riippumaton it-palvelujohtamisen toimija.

tiistai 13. lokakuuta 2009

Create problem!

Niin, tuollainen nappula löytyi (* aikanaan Remedyn ITSM-suiten Service Desk -työkalusta. Vaikka sanamuoto on hassu, se on oikeasti hyvä nappula. SD:n pitää tietenkin vain tietää ensin, mikä on insidentin ja ongelman ero. Jääköön se nyt vielä jännitettäväksi.

Olen monesti kannustanut yrityksiä aloittamaan ongelmanhallinnan, jos sitä ei vielä tehdä (useinkaan sitä ei kyllä tehdä kun on niin kiire sammuttaa tulipaloja..). Esimerkkinä käytän mm. erästä suomalaista suuryritystä, jonka CIO käynnisti toiminteen yksinkertaisesti perkaamalla alkuun itse niitä tikettitrendejä - "Hei Jaska, tossa on 20 samannäköistä insidenttiä, tsekkaatko löytyykö taustalta jokin perussyy?". Ken Goff kertoi itSMF-konferenssissa mainion esimerkin, miten pienellä vaivalla vähennettiin 50 major insidenttiä / kk viiteen - resursoimalla ongelmanhallintaan.

Olen myös usein viitannut ITIL-kirjojen työkaluihin - niin, sieltä löytyy monta hyvää, yksinkertaista tapaa tehdä järjestelmällistä ongelmanhallintaa. Eivät ne mitään uusia ole vaan jo vakiintuneita malleja. Hyvä puoli tässä on se, että ne työkalut löytyvät nyt siitä samasta pakista niiden prosessimallien kanssa.

Kokosin nyt tähän niitä työkaluja esimerkeiksi vapaasti kääntäen ITIL Service Operation -kirjasta.

Kronologinen analyysi

Kun työskentelee vaikean ongelman parissa, löytyy usein ristiriitaisia kirjauksia tai raportteja siitä, mitä tapahtui ja milloin. Silloin on hyvin hyödyllistä listata tapahtumat aikajärjestyksessä niin, että saa selkeän aikajanan tapahtumista. Tämän avulla on mahdollista nähdä, mitkä tapahtumat ovat johtaneet mihinkin ja mitkä eivät selvästikään kuulu joukkoon.

Kipuarvoanalyysi

Onpas suomennos. Pain value analysis on siis kyseessä.

Tässä tarkastellaan insidenttien tai ongelmien (tai ongelmatyyppien) vaikutusta laajemmin. Pelkän tiettynä aikana tapahtuneiden asioiden lukumäärän tarkastelun sijaan tutkitaan tarkemmin sitä, miten paljon organisaatio tai liiketoiminta kärsii näistä insidenteistä/ongelmista. Kipuarvon laskemiseen voidaan muodostaa kaava esimerkiksi ottaen huomioon seuraavioa asioita:
- ihmismäärä, johon asia vaikuttaa
- häiriön kestoaika
- kustannus liiketoiminnalle (jos mahdollista määrittää)

Näiden tekijöiden summana saadaan yksityiskohtaisempi kuva vaikutuksesta ja päästään keskittymään merkittävimpiin asioihin. Siis priorisoidaan.

Kepner ja Tregoe

Charles ja Benjamin kehittivät aikanaan hyvän tavan analysoida ongelmia ja saivat nimensä kirjoihin. Malliin kuuluvat seuraavat vaiheet:
- määritä ongelma
- kuvaa ongelman yksityiskohdat - sijainti, aika, koko...
- arvioi mahdolliset syyt
- kokeile todennäköisimpien syiden ratkaisua
- todenna todellinen syy.

Brainstorming

Tämäkin on hyvä tapa ongelmanratkaisuun. Kootaan oikeati ihmiset palaveriin ja pyöritellään ongelmaa ideoiden mahdollisia syitä ja niiden ratkaisuja. Brainstorming voi olla hyvin tehokas ja innovatiivinen tilaisuus mutta jonkun pitää dokumentoida tuotokset ja ylläpitää etenemistä - ongelmapäällikölle hyvä tehtävä!

Ishikawa-kaaviot

Japanilainen laatuguru Kaoru Ishikava kehitti kalanruotometodin mahdollisten vikatilanteiden syiden ja seurausten dokumentoimiseen. Mallin avulla voidaan myös ohjata kehitystyötä. Kaavio voi olla tuotos brainstorming-sessiostakin. Päätavoite esitetään selkäruotona ja sen päätekijät haaroina, joihin piirretään ruotoja lisätekijöille. Monimutkaisetkin ongelmat voidaan saada näin avattua yksityiskohtia myöten.


Tältä se siis näyttää (Wikipedia)

Pareto-analyysi

Tällä tekniikalla voidaan erottaa ne suurimmat ongelmien lähteet yksinkertaisemmista asioista. Teorian mukaan 80% ongelmista aiheutuu 20% syistä.

Analyysin askeleet ovat seuraavat:

- tee lista ongelmalähteistä ja niiden aiheuttamien ongelmien prosentuaalisesta osuudesta
- sorttaa lista niin, että todennäköisimmät syyt ovat ensin
- lisää sarake kumulatiivista prosenttiosuutta varten
- tee palkkidiagrammi jossa ongelmalähteet ovat vaikutusjärjestyksessä
- lisää viivadiagrammi kumulatiivisesta vaikutuksesta
- erota 80% aiheuttavat ongelmalähteet ja lähde ratkaisemaan

Siis näin:


Lähde: http://erc.msh.org/quality/pstools/pspareto.cfm

Yksinkertaisempiakin työvälineitä löytyy - vikapuuanalyysi (Fault Tree Analysis FTA) jossa piirretään infra puun muotoon lähtien palvelusta. Komponenttien vika-analyysi (Component Failure Impact Analysis CFIA) auttaa varautumaan ja varmistamaan tärkeimpien infrakomponenttien toiminnan.

Nämä työkalut kuvauksineen löytyvät siis ITIL Service Operation -kirjasta sivulta 62 ja liitteistä C ja D. Hyvä alku - kokeile!

(* on siellä kai vieläkin joku tuollainen nappula, taitaa jopa olla samalla tekstillä.

perjantai 25. syyskuuta 2009

Palveluportfolion hallintaa

Olen viime viikkoina työskennellyt palveluportfolion hallinnan parissa useassa eri ympäristössä palveluiden käyttäjistä niiden tarjoajiin. ITILin palveluportfolion hallinta antaa mainion, yksinkertaisen mallin saada kiinni kokonaisuudesta ja kehittää sitä.

Olen työskennellyt aiemmin erilaisissa myynti- ja palvelukehitystehtävissä ja yleensähän kehitysputkea kuvataan suppilona, funnelina joka päättyy myyntiin tai palvelun siirtämiseen tuotantoon. Tuotannossa palvelulle sitten tehdään .. niin, jotain. Sitä varmaan tuotetaan jotenkin?

Service Portfolio Management lähtee palvelun elinkaaren kokonaishallinnasta. Sen sijaan, että se kehitetty palvelu lykättäisiin vain tuotantoon, sitä seurataan ja kehitetään edelleen. Tuotannossa olevat palvelut listataan palvelukatalogissa, tulossa olevia siirretään eteenpäin kehitysputkessa (pipeline) ja myös jo poistumassa olevien ja poistuneiden palveluiden dokumentaatiota ylläpidetään Retired Services - poistuneet palvelut-osiossa.

Aikanaan Soneran NCS:ssä (R.I.P.) piirsimme funnelin valkotaululle ja ylläpidimme kehitysnäkymää putkessa olevia palveluita kuvaavilla magneettinappuloilla. Pitäisiköhän joskus kokeilla samaa tämän portfoliokuvan kanssa - kerralla näkymä tilanteeseen?

Kiinnostus ja paneutuminen aiheeseen on ollut viime aikoina todella suurta ja vakavaa. Näyttääkin lupaavalta - palvelulähtöinen IT-tuotanto ja -palvelunhallinta on saapumassa yhä järjestelmällisemmin johdettuna Suomeenkin!

itil.org -sivustolta löytyy tämä mainio kuva Palveluportfoliosta (kirjoitusvirheistä huolimatta)

tiistai 22. syyskuuta 2009

ITSM-koulutusta yliopistotasolla

Kirjoittelin aikanaan tietotekniikan tuotannon koulutuksesta Suomessa.

Kovin paljon ei alueella ole tapahtunut. Aalto-yliopisto virittelee hiljalleen Service Factory -opetusohjelmaa palvelutuotteistuksen ja -kehityksen alueelle, mutta esim. valmiita metodologioita ei lähdetä kouluttamaan vaan kehitetään omaa ohjelmarunkoa palveluiden liiketoiminnan ja innovaation alalta. Yksi kurssi löytyy jo täältä.

Kuopion yliopistossa asiaa on tutkittu ja perustettu Maissi-projekti. Turussakin projektoitiin itLEPOa mutta hyvistä aluista huolimatta ei varsinaista IT-palvelutuotannon akateemista tai ammattikorkeatasoista peruskoulutusta ole syntynyt.

Maailmalta löytyy kuitenkin jo hyviä akateemisia koulutusohjelmia IT-palvelutuotannon ammattilaisille. Näissä keskitytään enemmän tai vähemmän siihen oleelliseen eli tietotekniikan tuotantoon ja ovat ihan relevantteja vaihtoehtoja suomalaisillekin.

Näissä yliopistoissa kouluttajapuoleltakin löytyy jo ITIL-sertifioituneita, kokeneita kouluttajia - Suomessa näitä löytyy vasta kaupallisilta yrityksiltä (mm. meiltä MATERNAlta! :)

Tässä muutamia esimerkkejä.

The University of Northampton

Ehkä puhtain ITSM/ITIL-koulutusohjelma löytyy Northamptonin yliopistosta ja ensimmäiset valmistuneetkin on juhlittu. M.Sc-tutkinno voi suorittaa jopa etäopiskeluna, hyvä esite löytyy Northamptonin webistä.

University of Bolton

Boltonissa koulutetaan IT-ammattilaisia ITIL Service Management -tutkintoon neljän moduulin kautta: Palvelustrategia ja -suunnittelu, Palvelutransitio ja -tuotanto, Enterprise-järjestelmät sekä liiketoiminnan ja johtamisen tutkimus. Lopputyö on 14-20 000 sanan kirjanen.

http://www.bolton.ac.uk/GCCT/Postgraduate/ITIL.aspx

Sheffield Hallam University
Sheffield Hallamissa on rakennettu aika järjestelmälähtöistä koulutusohjelmaa, joka loogisesti siirtyy vuosien mittaan kohti IT-palvelunhallintaa ja jopa ITILiä. Mahdollisuus foundation-perussertifiointiin sisältyy opetusohjelmaan

http://www.shu.ac.uk/

Carnegie Mellon (USA)

Carnegie Mellon julkisti ITSM-koulutusohjelmansa jo 2008 mutta on ilmoittanut lykänneensä koulutuksen aloittamista "finanssikriisin" takia. Intoa oli kyllä ilmassa, kuten tiedotteesta näkyy.

Muita yliopistoja ja tutkimuksia

Monet yliopistot tarjoavat jatkokoulutuskeskuksissaan ITIL-sertifiointikoulutuksia, esim. St. Edwards University ja University of Dallas mutta näitä alkaa olla jo hyvin paljon.

Saksasta löytyy jo paljon linkkejä korkeakoulujen tutkimus- ja kehityshankkeisiin googlettamalla "ITIL Hochschule" ja Sveitsissäkin koulutetaan ITILeitä - pikahaulla löytyi mm. tämä ammattikorkeakoululinkki.

Tilanne maailmalla näyttää kehittyvän kovaa tahtia ja pohjustamalla parhailla käytännöillä loikataan valmiiksi portaiden puoliväliin.

Seuraan ja pyrin edistämään tilannetta Suomessa, vaikka tilanne onkin vielä hieman alkutekijöissään. Yrityksillä ja varsinkin itSMF:llä on kuitenkin jo isot intressit koulutuksen edistämiseen.

tiistai 25. elokuuta 2009

ITIL strategiakehyksenä

Kesätauon jälkeen syksy näyttää vilkkaalta. Varsinkin strategia- ja palvelunäkemys ovat olleet esillä keskusteluissa. IT- ja palvelustrategiaanhan vihreästä kirjasta löytyy oivia apukeinoja mutta myös jatkuvan parantamisen perusrunkoa kannattaa muistaa kehitystä miettiessä:

- Missä ollaan nyt?
- Mihin halutaan päästä?
- Miten sinne päästään?
- Päästiinkö tavoitteeseen?
- Mitäs sitten tehtäisiin - eli miten kehitys pysyy käynnissä?

Myös asiakkaan hyödyt siitä, että palveluntarjoaja noudattaa ITILiä kiinnostavat. Muutama selkeä etu tässä:

- prosessirajapinnat voidaan sopia
- prosessirajapinnat myös toimivat kun termistö on sama
- sovitulla syötteellä saadaan sovittuja tuotoksia
- ennustettavuus lopputuloksissa, budjeteissa, ajassa...

Haasteellisinta on saada molemmat organisaatiot ymmärtämään hyödyt ja noudattamaan sovittuja toimintamalleja. Tämä on tietenkin lähinnä johtamiskysymys. Olisihan niin helppo vähän oikaista tällä kertaa - "kun tämähän on vain verkkokortti, mitä sen vaihdosta RFC:tä tekemään". Kirjoitan joskus lisää mitä selvisi savun hälvettyä.

lauantai 20. kesäkuuta 2009

ITIL-koulutuslukemia

Sain APMG:ltä tietoa lokakuu 08 - maaliskuu 09 koulutuksista. Näköjään nuo vanhat koulutukset ovat nyt hiipumassa ja varsinkin Foundation-tasolla koulutus on siirtynyt v3-syllabukseen. Helmikuussa näytti jo siltä, ettei v2 Foundatioita enää maaliskuussa tentitä, mutta ilmeisesti jossain päin maailmaa maaliskuu on hyvä koulutuskuukausi. Taulukossa keltainen on yhteenlaskettu v3-tenttien lukumäärä.



Yhteensä v3 Foundationeja tehtiin tänä aikana 86550 kpl ja v2 Foundationeja 34200 kpl.

Jatkokurssit - Intermediate & Service Manager

Jatkokurssit tulivat käytännössä tarjolle tammikuussa 2009. Syksyn tenttinumerot ovat todennäköisesti enimmäkseen konsultteja ja kouluttajia. Intermediate-kurssit ovat lähteneet vuoden alussa jyrkkään nousuun. Service Manager -tenttejä on vielä tehty aika paljon, koska sillä tavalla voi saavuttaa edullisesti ITIL Expert -tason. Intermediate-kursseista on kuitenkin paljon hyötyä, sillä ne antavat hyvän valmiuden kehittää asioita käytännössä ITIL-mallin avulla.



Suosituimpia Intermediate-kursseja ovat olleet Service Operations (590 suoritusta), Operational Support & Analysis (580), Release, Control & Validation (560) ja Service Transition (540). TÄnä aikana Intermediate-kursseja suoritettiin yhteensä 3901 kpl, Manager Bridgejä 2000 ja Service Manager -kursseja 5900 kpl. Vanhoja Practitioner-kurssejakin tehtiin vielä 4250 kpl, tosin suunta on jyrkästi alaspäin.

Expert-suoritusten määrää tuossa tilastossa ei ollut. Jos jokin luku kiinnostaa erityisesti, ota ihmeessä yhteyttä niin katson tarkemmin.

keskiviikko 29. huhtikuuta 2009

Miksi kouluttautua ITILiin?

ITIL on best practice, kokoelma parhaita käytäntöjä teollisuudestamme. Taitavat ja kokeneet ihmiset tuntevat kyllä yleensä toimintakenttänsä hyvinkin, ja saattavat pitää jotain ITIL-koulutusta aivan turhana. Miksi sitten kannattaisi kouluttautua ITILiin?

Nolot tilanteet

Yhteisellä kielellä ja vakiintuneen käytännön termeillä vältetään noloja tilanteita. Henkilöstö antaa toiminnastaan ammattitaitoisen kuvan ja - mikä parasta - toimii tehokkaasti ja kustannuksia minimoiden. Tässä muutamia vertailevia esimerkkejä.

Oikea terminologia ja konfiguraationhallinta

Puhumalla vakiintuneilla termeillä, voi välttää noloja tilanteita. ITIL Service Asset & Configuration Management sisältää mm. ohjeistusta nimeämiskäytäntöjen määrittelyyn. Jos epähuomiossa nimeät esim. jonkin varaosan CMDB:hen väärin, sitä ei välttämättä osata käyttää silloin kun sille olisi tarvis tai se ei auta jossain toisessa tilanteessa.


"Fire! Fire! Where is my hand grenade?"

Projektien koordinaatio ja palveluiden suunnittelu

ITIL Service Design antaa hyviä malleja suunnitella palveluita kokonaisuutena ja vaatimusten linkkaamista testaukseen. Ei olisi mitenkään hauskaa huomata valmiissa palvelussa jotain yksinkertaisia suunnitteluvirheitä tai että kaksi projektia sotkevat pahasti toistensa tuloksia. Olikohan tässä katuosastolla ja energialaitoksella yhteistä CABia lainkaan?




Politiikat

Kouluttautumalla oppii soveltamaan ITILin antamia malleja käytäntöön paremmin. Kirjaa orjallisesti lukemalla voi tulla tilanne, jossa mennään harhaan - tehdään sellaisia politiikkoja tai ohjeistuksia esim. muutoshallintaan, joita ei voi mitenkään noudattaa tai jotka ovat muuten vain järjettömiä. Tällainen vie helposti pohjan koko kehitystyöltä, kun kaikkea aletaan kiertää ja kyseenalaistaa.


Kuole jossain muualla

Palveluiden nimeäminen ja portfolionhallinta

Palveluportfolion hallinnassa mietitään, millä palveluilla kysyntää tulevaisuudessa tyydytetään ja mitä taas voitaisiin poistaa. Palvelukatalogissa listataan tarjolla olevat palvelut. Nimemäminen ja suunnittelu on tärkeää - Business Service Catalogue pitää kirjoittaa käyttäjän kielellä ja oikein niin, että käyttäjä myös löytää palvelun helposti.



Herpes? Mutta missä on Herbs!

Monitorointi ja valvonta

Event Management antaa hyvän mallin infran tilanteiden käsittelyyn. Suunnitteluun löytyy myös tukea niin, ettei esim. vahingossa valvota valvontaa suljettuna silmukkana. Toisaalta, Information Security Management antaa malleja holistiseen ja jatkuvaan turvasuunnitteluun ja -kehitykseen. Kouluttautumalla näistäkin saa eniten irti.


"Valvo sää mua niin mää valvon sua. Tää on kylä turvallista!!"

Information Security Management

Information Security Management prosessina tosiaan pakottaa ottamaan huomioon, arvioimaan ja auditoimaan riskejä ja turvatoimien riittävyyttä. Tässä on esimerkki huonosta politiikasta, jonka vaikutusta käytäntöön ei ole testattu riittävästi. Mikähän tämä turvatoimi olisi - preventive/reductive, directive/repressive vai corrective/recovery - ehkäpä symbolic?


Et muuten vie mun skeboja!

Jatkuvuuden hallinta ja linkki muutoshallintaan

On yllättävän yleistä, että prosesseja kehitetään joko yksittäin tai irrallisina toisistaan tietämättä. Toisaalta, joskus tehdään hyviä ratkaisuja jälleen kerran miettimättä kokonaisuutta. Varsinkin vanhat ITIL-versiot ohjaavat tähän ajatteluun, kun v3 pukkaa kohti kokonaispalveluajattelua.

Tässä esimerkissä hieno jatkuvuushallintaratkaisu on käynyt turhaksi, kun sitä ei ole linkitetty kokonaisuuteen tai muutoshallintaan - kuka piru sen oven nyt muurasi kesken kaiken umpeen?

'
TÖKS

Palveluelinkaaren hallinta

ITIL perustuu palvelun elinkaarimalliin ja sen hallintaan. Sen avulla pystytään arvioimaan palveluiden tarve, niiden käyttömahdollisuudet ja suunnittelemaan ne liiketoimintaa mahdollisimman hyvin hyödyttävällä tavalla. Tämä auttaa myös havaitsemaan ne palvelut, jotka ovat tarpeettomia liiketoiminnan kannalta. Vältetään siis turhaa työtä, kohdistetaan muutokset oikein ja näin alennetaan kustannuksia.

Ehkäpä sen muurin piti tulla tänne.



Hauskaa vappua!

sunnuntai 19. huhtikuuta 2009

ITIL ja sovelluskehitys

ITILin ja sovelluskehityksen linkkaamisesta riittää keskustelua. Sovelluskehitykseen on tarjolla monenlaisia agiileja ja jo pitkälle evolvoituneita malleja. Miten nämä sitten saataisiin yhdistettyä ITILiin ja palvelun elinkaareen?

ITIL on koottu palvelun elinkaaren ympärille. Yksinkertaisesti ajatellen sovelluskehitys osuu Release & Deployment Managementin kohtaan Build/buy solution osana kokonaisvaltaista palvelukehitystä. Vaihe voi olla esim. 3 vuoden softaprojekti. Muutoshallinnasta tulleet ideat linjataan strategian mukaan ja ne arvioidaan Service Design -vaiheessa, speksit kootaan Service Design Packageen. Service Design Package sisältää toiminnalliset ja teknologiaspeksit, jotka ohjaavat sovelluskehitystäkin.

Build/buy Solution -vaiheessa voi hyvin soveltaa ITIL-elinkaarimallia kokonaisuutena sovelluskehitykseen ja niinhän Application Management -funktion pitäisi tehdäkin - hallita sovelluksen koko elinkaarta. Rudy Stubler linkkaa esityksessään aika nätisti nämä asiat, vaikka ei kovin syvälle kaivaudukaan.

Elinkaarimallin käyttö voisi sovelluskehityksessä mennä näin:

ITIL Service Strategy

- käynnistä sovelluskehitys
- määrittele sopivuus portfolioon, analysoi
- tee business case liiketoiminnan kannalta - miksi tämä sovellus, mihin palveluun se liittyy jne.

ITIL Service Design
- analysoi Warranty-vaateet (saatavuus, kapasiteetti, jatkuvuus, turva)
- analysoi Utility-vaateet (toiminnallisuudet)
- mieti hallintaprosessit, teknologiat, ihmisten koulutus, mittarit
- kokoa Service Design Package = speksi

ITIL Service Transition
- Kehitä sovellus, linkitä ratkaisuun
- Kokoa jakelupaketti (Release Package)
- Asenna, testaa (V-malli), implementoi, kouluta, implementoi prosessit
- Muista alkuajan tuki (Early life support)

ITIL Service Operation
- Operoi sovellusta
- Tee kehitysehdotuksia
- Tuota lisäarvoa!

ja sitten vielä CSI - Continual Service Improvement
- Mittaa ja raportoi
- Kehitä jatkuvasti eli arvioi säännöllisesti - missä ollaan nyt, mihin ollaan menossa, miten sinne päästään, miten todennetaan...ja miten tämä kehitys pysyy käynnissä.

ITIL on moniulotteinen kehys ja se ohjaa kokonaisvaltaiseen, palvelusta lähtevään ajatteluun - tulinko ottaneeksi huomioon kaikki oleelliset asiat palvelun kannalta. Sitä voi siis soveltaa sovelluskehitykseen, mutta varsinaisen ohjelmiston kehittämiseen on olemassa siihen varsinaisesti tarkoitettuja malleja.

Sovelluksen elinkaarenhallintaan ITIL toimii hyvin. Muista kuitenkin ajatella end-to-end -palvelua, se ratkaisee.

maanantai 30. maaliskuuta 2009

Ongelmanhallinta helposti käyttöön - miten?

Viime viikkoina olen törmännyt useammassakin yhteydessä ongelmanhallintaan. Toisaalla on kysytty, voiko sitä tosiaan tehdä jotenkin - toisaalla taas kerrottu, miten homma toimii käytännössä.

Eräs kysyjä esitti hyvin tavallisen tilanteen. Helpparissa kilisee ja kaveri kertoo kuinka uusi softa ei toimi hänen läppärissään. Teuvo Tukihenkilö ottaa etäyhteyden työasemalle, fiksaa pari juttua ja homma lentää taas. Samaan aikaan toisaalla, Anne Apuystävä vastaa samanlaiseen kyselyyn ja tekee saman fiksin. Ja niin edelleen.

Miten näistä turhista insidenteistä pääsee eroon? Eikös ne ole mahdotonta yhdistää? No ei, jos joitain perusasioita on kunnossa.

Ensimmäisenä on syytä pitää huolta siitä, että nämä insidentit kirjataan ylös. Monesti tähän tarkoitukseen on hankittu jokin järjestelmä (tai ladattu vaikkapa jokin ilmainen netistä). Joskus näitä kirjataan Exceliin mutta olen nähnyt käytössä ruutupaperivihkojakin. Käytetty työkalu riippuu paljon sekä toiminnan luonteesta että sen skaalasta ja kapasiteetista.

Tämän jälkeen ongelmia onkin helppo lähteä etsimään. Ongelmahan on yhden tai useamman insidentin taustalla oleva perussyy. Yksinkertaisen esimerkin käytännön ongelmanhallinnasta kertoi lounaspöydässä erään suomalaisen suuryrityksen IT-johtaja. Hän otti itse tikettijärjestelmästä viimeisen parin viikon tikettiraportin ja pyöritti niitä excelissä eri parametreilla. Sieltä löytyi melko pienellä vaivalla suurempia kasaantumia, joita pystyi sitten yhdistelemään.

Näin se toimisi myös tuossa alkuperäisessä esimerkissä. Kirjatuista tiketeistä pystytään luokittelun avulla yhdistämään samanlaisia tapauksia ja etsimään niiden perussyitä. Tätä kannattaa kokeilla, se toimii! Jonkun se on pakko kuitenkin aloittaa, miksipä et siis sinä?

Ongelmanhallintaa helpottaa myös koulutus. Siinä vaiheessa, kun organisaatio ymmärtää insidentin ja ongelman eron, ollaan jo aika pitkällä. Ei pyritä Service Deskissä korjaamaan kaikkea vaan palautetaan palvelu - korjataan insidentti. Toisaalta, kun SD ymmärtää, mitä ongelmanhallinta on, ovat he avainasemassa näiden ongelmatikettien luomisessa - "nyt tämä tuli jo neljännen kerran tänään, pannaanpa tästä pojille tutkittavaksi..." ja vastataan seuraavaan puheluun. Formaalit ITIL-koulutukset antavat hyvää pohjaa, oikoteitä on vähän.

Edelleen toimintaa tehostaa ja helpottaa, jos näiden ongelmien korjaaminen tehdään formaalin muutoshallinnan kautta. Priorisointi, kustannusten arviointi ja varsinkin muutosten vaikutus muuhun palvelutuotantoon (suhteet palveluiden välillä) tulevat tarkasteltua kunnolla ja näin vältetään uusia insidenttejä. Taidan kirjoitella tästä joskus myöhemmin.



Pihasaunallamme ilmeni pieniä insidenttejä, joten päätin poistaa root causen ongelmanhallinnan keinoin. Mitä mainioin työkalu tähän löytyi Prismasta hintaan 90c. IT-ongelmanhallinnan työkalut saattavat välillä maksaa hieman enemmän, mutta ROIkin on helposti paljon parempi.

perjantai 6. maaliskuuta 2009

Ihmiset, prosessit, TYÖKALUT!

ITILeitäkään ei ohjailla ilman työkaluja. Otsikko on yksi parhaita oppimisiani ITIListä. Ei se ITIListä alunperin ole peräisin, mutta hyvä se on silti. Kokosin nyt pienen listan näistä työkaluista - tuskin täydellisen, mutta edes esimerkin.

Markkinoilla on nykyisin jo paljon "ITIL-yhteensopivia" työkaluja. Termi saattaa tarkoittaa melkein mitä vain mainoslauseesta todelliseen ITIL-prosessikehyksen tukeen. Kannattaakin tsekata tarkkaan, mitä järjestelmä oikeasti tekee.

Gartner on tutkaillut palvelunhallinnan työkaluja vuosikausia ja Service Deskistä löytyy vuoden 2007 raportti ja myös vuoden 2008 tilanne netistä - BMC (Suomessa edustaja Materna), CA ja HP (Suomessa toimittaa Rubik Solutions) johtavat siellä kokonaisuutta. 2008 yllättäen Service-now.com on alkanut hiipiä yläluokkaan vaikka tarjoaakin aika bulkkia - perusprosessit ovat siis vakioitumassa! Kärkikaartin Axiossystems ei ole paikalla Suomessa.

Suomalaisia softia ei Gartnerista löydy. Ainoa suomalainen alan firma lieneekin Efecte, joka on suomenkielisenä melko suosittu varsinkin pk-yrityksissä ja julkishallinnossa. Kilpailu on tosin kiristynyt, kun ainakin Remedystä löytyy jo suomalainen versio. Sysartin Requestea en tunne.

Suomalaisille pk-yrityksille saattaakin sopia hyvin jokin muukin pienempi softa tarpeeseen. Vaikka yrityksemme myykin BMC:n sovelluksia, mainitsen ensin Service Desk Expressin, koska käytimme sitä Logiswaren aikaan - silloin nimi tosin oli Magic. Näppärä ja edullinen softa, ITIL-yhteensopivakin sanoo Pink Elephant.

Suomessa on myyty myös PK-sektoriin sopivaa Symantecin Altirista jolla on pari mukavaa referenssiäkin, julkisena ainakin Stockmann. IBM osti hiljattain Maxximon johon osittain pohjautuu Tivoli Service Request Manager joka on myös CMDB-pohjainen ja ITIL-softa sinällään.

Kokeilin itsekin ManageEngineä mutta en saanut sitä oikein toimimaan - ajanpuutetta. Easit myy ainakin Ruotsissa jotain Service Desk -softaa, näköjään myös Ahvenanmaalle (Crosskey).

Ilmaisiakin softia löytyy. http://www.opensourcehelpdesklist.com/ listaa niitä paljon, Google auttaa myös - "Open source helpdesk software" tai jotain. Avoimen koodin Jira on käytössä useissa suomalaisissakin firmoissa, mutta mielestäni se on enemmän softakehityksen release-softa.

Miten se sitten valitaan?

Softa on aika pieni osa ITILiä, oikeasti. Gartnerin top-softat auttavat ja tukevat palveluntoimittajaa täydellisesti, kysymys on paljon enemmän ihmisistä ja prosesseista. Sama pätee näihin muihinkin softiin, kokonaisuus ratkaisee. Jos firmassa on taitavaa teknistä väkeä vapaana, voi keskittyä hankkimaan prosessiosaamista ja asentaa softan itse. Kaikki riippuu sisällöstä - ei Wordin ostaminenkaan kirjaa tee.

Toimittajavalinnan tueksi löytyy ITIListä hyvä esimerkki. Tässä lyhyt tarjouspyynnön pohja, lisää löytyy helposti ITIL-kirjoista:

------------------

Yleistä

- Toimittajan perustiedot (taloustilanne, henkilöstö, osaaminen..)
- Sovelluksen perustiedot
- Referenssit
- Käyttöönotto
- Koulutustarjonta
- Hinnoittelu ja sopimukset
- Tuki ja ylläpito
- Sopimusehdot
- Muut mahdolliset kustannukset

Sovelluksen yksityiskohdat

- Perusasiat ja -olettamukset
- Käyttäjämäärät ja -profiilit
- Service Desk
- muut käyttäjät
- loppukäyttäjät
- johto
- Integraatiot
- Henkilöstödatan import

Käyttöönotettavat funktiot ja prosessit

- Service Desk, Incident, Request
- Asset & Configuration, Change, Problem
- Service Level, Event, Etähallinta

------------

Lopuksi vielä lista toimittajista - näitähän kannattaa vertailla:

Computer Associates - http://www.ca.com/fi/
Materna - http://www.materna.com/fi/ - BMC:n Remedy- ja IBM:n ITSM-tuotteet
Pedab - http://www.pedab.fi/ - IBM Tivoli
Efecte - http://www.efecte.fi/
Rubik - http://www.rubik.fi/ - HP:n tarjonta
Sysart - http://www.sysart.fi/ - Requeste, www.requeste.com
UBM (United Business Machines) - http://www.ubm.fi/
Altiris / http://www.altiris.com/

torstai 26. helmikuuta 2009

Tietotekniikan tuotantoa

Kävin mielenkiintoisen keskustelun erään TKK:n professorin kanssa alkuviikosta. Löysin jälleen yhden kiusattavan tämän IT-palvelunhallinnan koulutuksen tiimoilta, enkä tällä kertaa ollut enää edes ensimmäinen! Asia tuntuu kiinnostavan jo muitakin.

Keskustelimme siitä, pitäisikö korkeakoulutasolla opettaa tietotekniikan tuotantoa. Tietotekniikan opetushan alkoi TKK:lla vuonna 1986 ja oli aluksi hyvin pitkälti sähkötekniikan osaston ohjauksessa. Senkin takia se on suuntautunut hyvin pitkälti ohjelmointiin ja sähköteknismäiseen tarkkaan kolvaamiseen, bitin vääntelyyn.

Muutaman viime vuoden aikana on perustettu tietenkin hyviä hankkeita, SoberIT ja Software business tähtäävät menestyvän ohjelmistoliiketoiminnan perustamiseen ja johtamiseen. Kyseessä on kuitenkin aivan eri asia kuin tämä päivittäinen tuska, IT-palvelutuotanto.

Kävimme keskustelun aikana läpi muutkin TKK:n osastot. Kaikilla muilla osastoilla opetetaan tuotantoa - rakennustekniikassa, kemiassa, sähkölläkin ja erityisesti konetekniikassa. Tietotekniikasta se puuttuu.

Viittasin jo aiemmin Aalto-yliopiston tuomiin mahdollisuuksiin. Uusi rehtori astuu remmiin 1.4. ja alkaa organisoida toimintaa, varsinainen tsunami tulee sitten 2010 alussa. Kauppakorkean puolella professori Dahlbergilla on jotain IT governance -aiheita hallussaan, mutta kyllähän nyt IT-johtajilla pitää olla jonkinlainen tekninen osaaminen - siksikin pidän TKK:ta oikeana paikkana tälle koulutukselle!

No, jatketaan puskemista vaikka sitten Aallon harjalla - toivottavasti yhtä menestyksekkäästi kuin tuossa alla olevassa aallossa kävi.



Aaltolentoa purjekoneella Kebnekaisella 2007 - tällä aallolla pääsi yli 6 km korkeuteen.

torstai 12. helmikuuta 2009

Wanted: PROBLEM MANAGER

Eräässä keskustelussa tuli esiin se, millaisia haasteita ITIL-managerien nimittämisessä/valinnassa tulee vastaan. Kysymys tuli hieman yllättäen, ja ensimmäisenä mieleeni tuli vain se yleisin käsitys - ITILin myötä tarvitaan paljon uusia ihmisiä managerien paikalle. Eihän asia näin ole, vaan kyseessä on vastuutus ja roolitus - sama henkilö voi toimia monen prosessin valtiaana.

Käytännön haasteitakin on tullut vastaan. Yleisiä ominaisuuksia näille ITIL incident-problem-change-configuration-whatnot managereille kyllä löytyy:

- tuntevat hyvin organisaation ja henkilöiden kompetenssit
- voivat hierarkisen positionsa pohjalta vaikuttaa resursointiin
- ovat toimialan ja tietotekniikan ammattilaisia
- tuntevat ITIL-kehyksen ja omaan alueeseensa liittyvät prosessit

Tuo hierarkinen positio tarkoittaa myös sitä, että nimensä mukaan managerin rooli on managerointia. Yleensä se tarkoittaa töiden jakamista, resurssien nimeämistä ja hankkimista, johtamista! Olen nähnyt yrityksiä nimittää linjasta ihmisiä tekemään "tätä change managerin hommaa kun sehän nyt on vain pieni lisä.." mutta ei asiantuntijalla ole sitä resursointi- ja johtamisvaltaa, joka näihin tehtäviin tarvitaan.

Tässäpä yksi quick&dirty ehdotus siitä, miten nuo roolit voisi organisaatiossa jakaa:

Incident Manager
Yleensä Service deskin vetäjä, mutta voisi olla kokenut SD-asiantuntijakin. Vastaa prosessin sujuvuudesta, joskus myös töiden jonotuksista, priorisointien toimivuudesta ja trendiseurannasta niin, että Problem Managerillekin löytyy hommia. Vastaa monesti samalla Request Fulfillment -prosessista ja on yleensä aika hyperaktiivinen ihminen. Pohjois-Karjalasta.

Problem Manager
Kuin viilipytty, harkitseva seniorimanageri sieltä verkko/palvelin/mainframe-tiimistä joka tuntee ihmiset ja organisaation kuin omat taskunsa. Tuntee Infrastruktuurin niin, että osaa tunnistaa allokoida ongelmatutkintaa oikeisiin ryhmiin. Pystyy keskustelemaan ja viestimään kollegojen kanssa niin, että ongelmanhallinta toimii ja prioriteetit pysyvät hallussa. Juttelee Incident Managerin kanssa aktiivisesti, seuraa itsekin trendejä ja tekee perusteltuja muutospyyntöjä Change Managerille, joka joskus saattaa istua samalla tuolilla. Pohjanmaalta

Change Manager
Kova puurtaja viemään asioita läpi, osaa myös sanoa EI kun joku haluaa välttämättä jatkossa punaisia työasemia. Seuraa muutosten kulkua, allokoi niitä oikeisiin ryhmiin ja pitää huolta laadukkaasta toiminnasta. Monesti kokenut infra-yksikön päällikkö, muutokset kun vaativat resursointia nekin. Saattaa olla hyvin läheinen Problem- tai Configuration Managerin kanssa. Asikkalasta.

Configuration Manager
Järjestelmällinen ja pitkäjänteinen ihminen, kova kokemus IT-infran hallinnasta. Tähän toimeen sopii hyvin kokenut asiantuntija, IT-arkkitehti. Portinvartija ja vahtikoira, CMDB:n on pysyttävä ajan tasalla. Saksasta.

Nämä esimerkit ovat suoraan käytännöstä ja hyvin konkreettisia. Muitakin managereita ja vastuita tietenkin on.

Design-puolella on paljon alueita, joiden vastuut voivat hyvinkin löytyä infran ylläpidon tai kehityksen henkilöstöstä. Transition vastuut kolahtavat joskus jopa projekteille, vaikka prosessituki olisi syytä pitää stabiilina. Operaatioita manageroidaan valvontahuoneessa ja jatkuvaa kehitystä potkitaan kaikkien ryhmäpäälliköiden bonustavoitteilla. Strategiapuolella vastuut ovat paljon hallinnollisella puolella, CIO:lla ja talousjohtajalla/kontrollerilla.

Iso kasa hattuja, ei niille välttämättä tarvita yhtää montaa päätä. Voihan niitä hattuja vaihdella. Se vanha suomalainen sananlasku "Kahta en vaihda..." - sehän viittaa sukkiin.


Sukat

sunnuntai 8. helmikuuta 2009

Missä järjestyksessä CMDB rakentuu parhaiten?

Vaihdoimme tuossa kollegan kanssa hiljattain ajatuksia CMDB:stä. Tämä taikakaluhan on ollut ilonamme jo vuosia, kun se ITILin kakkosversiossa lanseerattiin ajatuksena. Käytäntö on ruhjonut konseptia eteenpäin ja nykyään ITILikin tietää, että yleensä näitä tietokantoja on useampia ja niistä koostuu CMS, Configuration Management System.

Mitä sinne sitten pitäisi laittaa? Mistä olisi eniten hyötyä?

Monestihan CMDB:n populointi alkaa työasemista. Hankitaan Discovery, joka syöttää tietoa pienellä vaivalla CMDB:hen. Työmäärä on melkoinen mutta työasemien ikä, malli, softat jne. löytyvät sitten helposti eri ITSM-työkaluista. Tästähän hyödytään Service Deskissä paljonkin - totta.

Kokonaisuuden kannalta hyöty jää kuitenkin aika laimeaksi. Tietenkin tällä avustetaan Incident Managementia ja ehkä jonkin verran rahojenkin laskentaa, mutta IT-palvelunhallinnan kannalta fiksumpaa olisi ajatella palveluita.

Aluksi voidaan ottaa vaikkapa vain yksi kappale liiketoiminnan kannalta kriittisiä palveluita ja mallintaa se CMDB:hen. Näin helpotetaan insidenttien ja muutosten hallintaa paljon enemmän kuin tietämällä, mikä työasema työntekijällä kulloinkin on käytössään. Toinen ja kolmas palvelu ovatkin jo paljon helpompia, jossain vaiheessa tulee jo rajakin vastaan - mitä kaikkea sinne CMDB:hen edes viedään. Tämä on syytä päättää hallitusti, kaikkea sinne ei tarvita.

Toki työasemat ja jopa matkapuhelimet - ne pikkuiset tietokoneet siellä rintataskussa - kannattaa viedä ajan mittaan CMDB:hen, mutta 80% hyödystä saavutetaan 20% vaivalla mallintamalla ensin palvelut sinne tietokantaan. Lisenssienhallinnan ja auditointien kannalta tehokkaampi tapa saattaa olla jopa käyttää sitä Discovery-työkalujen omaa raportointia sen sijaan että kaikki tieto olisi CMDB:ssä.

Silti, CMDB on hieno juttu. Aikanaan koulutin lentokenttäsimulla erään suurehkon (n. 56000 työntekijää) serveritiimiä. Yksi osallistujista - ainoita, joilta olen saanut ko. koulutuksesta negatiivista palautetta - tuli yrmeänä simulaation jälkeen antamaan palautetta. "Minä en kyllä usko lainkaan siihen, että tällaisilla leikeillä mitään oikeasti oppisi. No, ymmräsinhän kuitenkin lopultakin, mitä se CMDB käytännössä tarkoittaa!". Kaveri oli työskennellyt luolassa jo 70-luvulta lähtien ja oli kyllä muuten hyvä tyyppi, ei vaan tykännyt leikeistä!



Mainittu CMDB-tiimi työssään

perjantai 6. helmikuuta 2009

ITIL-keskustelua suomeksi Linkedinissä

Loin Linkediniin (www.linkedin.com) ryhmän suomenkieliselle ITIL-keskustelulle. Ryhmän nimi on innovatiivisesti ITIL Suomi - tervetuloa mukaan keskusteluun!

Tänään ryhmässä on jo 58 jäsentä, keskustelukin on lähtenyt käyntiin!

http://www.linkedin.com/groups?gid=1767747

tiistai 3. helmikuuta 2009

v2 hiipuu mutta hitaasti

Epätietoisuuden lopettamiseksi kirjoitin APMG:lle ja pyysin lisätietoa v2:n lopettamisaikataulusta. Muista ITIL-keskusteluista olen bongaillut tilannetta muualla maailmassa, ja kypsyystaso tosiaan on kovin erilainen. Joissain kehittyvissä maissa jopa kielisyys on merkittävä asia, koska englantia ei osata - tämä lienee tilanne varsinkin ranskankielisessä Afrikassa.

Sain APMG:tä ympäripyöreän vastauksen. Ainoa päätös tällä hetkellä on se, että tenttien lopettamisesta tiedotetaan 6 kuukautta etukäteen ja kirjojen poistamisesta 4 kuukautta ennen opetuspäivää. Foundation-tentit lopetataan ensin, sen jälkeen Practitioner- ja Service Manager -tentit. Sen jälkeen bridge-kurssien lakkauttamisaikataulut päätetään tilanteen mukaan.

Asiaan vaikuttaa paljon eri maiden itSMF:ien tekemät suositukset. Suomessahan tilanne on siinä mielessä hyvä, että lähes kaikki tunnistavat v3:n, 14% käytti sitä jo kehyksenä ja 56% aikoi kehittää prosesseja sen mukaan. Lausuntoja pyydetään varmaan lähitulevaisuudessa, Suomen valmius tässä asiassa on erinomainen.

Näen ITILv3:n antavan paljon kilpailuetua palveluntarjoajille ja -yksiköille. Palvelun elinkaariajattelu tuntuu paljon fiksummalta kuin yksittäisiin prosesseihin keskittyminen, vaikka käytännössä mennäänkin prosessi kerrallaan. Ei anneta puiden peittää metsää.

Tässä voisi nyt olla sauma käyttää tämä kilpailuetu ensilinjassa - palvelulähtöinen ajattelu auttaa keskittymään oikeisiin asioihin. Käytännössähän uusi versio näkyy vain siinä, että Incident Managementin sijaan ensimmäisenä käydäänkin Service Cataloguen kimppuun.

Keskustelimme muuten eilen kollegan kanssa pitkään mielenkiintoisesta aiheesta - "Mitä hyötyä on siitä, että työasema on CMDB:ssä". Tästä varmaan seuraavana.

perjantai 23. tammikuuta 2009

Kyvykkyyttä nostamaan

Istuskelen tässä valvomassa Foundation-tenttiä Malmin lentoasemalla. Järjestämme ITIL-kursseja täällä oikeastaan sattumalta - aikanaan pidimme jokusen Airport Simulaation täällä ja havaitsimme tilan hyväksi: ei verkkoyhteyksiä, ravintola vieressä, poissa toimistolta.

Keskustelimme kurssilaisten kanssa jatkomahdollisuuksista. Intermediate-kurssithan jakautuvat kahteen polkuun, kurssi/kirja Lifecycle-puoleen ja kokonaisuuksia halaavaan Capability-puoleen.

Joku on verrannut jälkimmäistä vanhaan practitioner-polkuun, mutta asia on hieman monimutkaisempi. Kirjakurssit sopivat parhaiten konsulteille ja jonkin yksittäisen prosessin omistajalle, mutta esim. palvelupäälliköille ja IT-managereille pidän noita Capability-kursseja paljon hyödyllisempinä kuin vanhoja practitioner -kursseja - nehän koostavat tietyn aihealueen kokonaisuuden yhteen koko kirjasarjasta.

Päätimme järjestää keväällä Operational Support and Analysis- ja Release, Control & Validation -kurssit ja jatkaa syksyllä Planning, Protection & Optimization- ja Service Offerings & Agreements -kursseilla. Yllättäen tältä kurssilta ilmaantui tuohon viimeisimpään eniten kiinnostuneita, OSA on tietenkin lähimpänä operaatioita.

Jokohan siellä alkaisi kypsyystaso olla jo sitä luokkaa, että olisi tarkoituksenmukaista lähteä puskemaan eteenpäin?

Koulutan näillä kursseilla tämän kevään aikana - ota yhteyttä jos kiinnostaa tai haluat lisätietoja:

9.-13.2. Service Manager Bridge
23.-25.2. Foundation (private)
4.-6.3. Foundation
16.-20.3. Operational Support & Analysis
7.-8.4. Foundation Bridge
16.4. Simu (CIO, by invitation)
20.-24.4. Release, Control & Validation
4.-6.5. Foundation
13.-14.5. Foundation Bridge
25.-29.5. Service Manager Bridge
8.-10.6. Foundation
11.-12.6. Foundation Bridge
22.-26.6. Operational Support & Analysis

keskiviikko 14. tammikuuta 2009

ITIL Foundation tarkentuu

ITIL Foundation -kurssin opetussuunnitelma tarkentuu. Ensimmäinen versio lanseerattiin samaan aikaan varsinaisen julkistuksen yhteydessä kesäkuussa 2007 ja sitä tarkennettiin helmikuussa 2008.

Nyt virallinen katselmointi on tehty ja kurssisuunnitelmaa hieman tarkennettu. Tarkennukset tehtiin käyttäjä- ja kouluttajakommenttien pohjalta ja otetaan käyttöön toukokuussa 2009.

Muutokset ovat aikalailla kosmeettisia. Painopistettä siirretään hieman enemmän elinkaariprosessien suuntaan, strategiasta nipistellen. Kirjoitusvirheitä on myös korjattu.

Kävin läpi tuon muutoslokin. Nykyinen akkreditoitu koulutusmateriaalimme näyttää jo vastaavan uutta speksiä 98-prosenttisesti. Olen siis kouluttanut jo nyt tulevan mallin mukaisesti.

Opetussuunnitelmasta poistuu strategian teoriaosuuksia jonkin verran joten tilaa on lisäyksille. Näyttää siltä, ettei kurssin tahti jatkossa ole enää niin hektinen - toisaalta, jotain jää nyt sitten käymättä läpi eikä sitä vaaditakaan. Tämähän on foundation-taso ja tarkoituksena on saada yleiskuva, Intermediate-kursseilla sitten paneudutaan detaljeihin.

ITIL v3 Foundation Syllabus v3.1 - lisäykset vanhaan opetussuunnitelmaan

-

Palveluomaisuuden määritys (Service Asset)
- Jakelupolitiikat (Release policy)
- Mittareiden (KPI) merkitys parannusprosessissa
- Kysynnän hallinnan (Demand management) ja talouden hallinnan (Financial management) muutamia yksityiskohtia
- Palvelutasojen hallinnassa opitaan nyt tarkemmin erilaisia SLA-malleja: Service based SLA, Multi-level SLA, Service Level Requirements, SLAM chart, Service review ja Service improvement plan (SIP) käsitellään tarkemmin
- Saatavuuden hallintaan yksityiskohtia
- Tietoturvan hallinnassa Security framework ja tietojärjestelmä (ISMS) käydään läpi
- Kapasiteetinhallinnassa vaaditaan business, service ja component capacity management -tietämys
- Jatkuvuudenhallinnassa hieman yksityiskohtia liiketoiminnan jatkuvuushallinnasta
- Muutoshallinnassa muutostyyppejä, muutosprosessi ja CAB-roolia tarkemmin
- Konfiguraationhallinnassa samoin muutamien termien tuntemusta lisätään (CI, Definitive Media Library, Configuration Management System, Configuration Baseline)
- Tietämyksenhallinnassa enemmän yksityiskohtia

sunnuntai 11. tammikuuta 2009

Miten ITIL auttaa prosessien parantamiseen?

Eräs simulaatiokurssilainen pyysi lyhyttä yhteenvetoa siitä, miten ITIL auttaa prosessien parantamiseen. Lentokenttäsimulaatiossa käytetään prosesseja käytännössä ja teoriaan ei mennä kovinkaan syvälle, joten listasin niitä muutamia käytännön hyötyjä tähän.

Törmäsin itse ensimmäisen kerran ITILiin juuri v2:n valmistuttua n. 2002. Vastasin globaalin infran tuotannosta ja vertasimme kehystä omaan prosessikarttaamme. Silloin totesimme, että vanha riittää meille. Firma oli kehittänyt prosesseja 70-luvulta lähtien ja hyvinhän ne olivat kohdallaan.

Kun nyt katselen ko. vanhaa prosessikarttaa, olisin voinut vilkaista aikanaan sitä ITIL-kehystä vähän tarkemminkin. ITIL antaa hyviä ohjeita kokonaisuuden kehittämiseen - siirtymiseen incident managementista eteenpäin. Yleensä Problem Management -prosessin käyttöönotto vähentää jo radikaalisti sitä tulipalojen perässä juoksemista - muistathan miten simulaatiossakin se ratkaisutietokanta alkoi vaikuttaa parin rundin jälkeen siihen teknisen henkilöstön työmäärään. Siihen asti kaikki olivat juosseet insidenttien perässä.

Käytännön hyötyjä ITIListä siis

- paljon valmiita malleja prosesseille. Nämä ovat suoraan käytännöstä ja niitä on hyvä käyttää omien prosessien arviointiin voisiko jotain tehdä VIELÄ paremmin.
- kattava kokonaisuus - uusia ideoita toiminnan kehittämiseen ja validointiin, jotain, mitä vasten verrata. Elinkaarimalli on mainio, panee ajattelemaan kokonaisuutta, esim. jatkuvuus, saatavuus...
- yleisesti tunnettu & hyväksytty. Jos palkkaat kaverin, joka on tehnyt ITIL-kurssin/kursseja, tiedät mitä hän tietää. Vrt teekkari vs DI.

ITIL on käytännössä ainoa malli, jossa annetaan IT-palvelutuotannolle valmiita työkaluja. Mittaukseen löytyy kyllä COBIT ja laatuun 6 Sigma ja maturiteettiin CMMI mutta ITIL antaa oikeita käytännön työkaluja. ITIL Foundation-kurssilla saa käsityksen siitä, mitä kussakin 5 kirjassa on. Lyhyt yhteenveto löytyy itsmf:n vepistä, http://www.itsmfi.org/content/introductory-overview-itil-v3-pdf

ITILiähän potkivat eteenpäin aina vain enenevät compliance-vaatimukset ja säännökset - Basel II pankkipuolella, SOX ehkä näkyvimpänä, ISO 20000 IT-palveluiden laadussa. ITIL antaa hyviä valmiita malleja siihen, miten organisaatio voi täyttää nämä vaatimukset.

Aika monessa paikassa on myös herätty siihen, että IT-palvelut pitäisi pystyä kuvaamaan selkeästi - niin, että siellä liiketoiminnan päässä ymmärretään, mitä tässä oikeasti tehdään. Esimerkiksi lentokentällä, jota mainitsemassani simulaatiossa kuvataan, oleellisia palveluita ovat Tutka, Flight Catering (eikä vain pyöritetä Dickensiä ja Shakespearea, hienoja sovelluksia ja palvelimia).

Tähänkin ITIListä löytyy apuja - palveluiden hahmottamiseen selväkielisesti ja niiden toimittamiseen luvatuilla tasoilla. Itse olen käyttänyt sitä Design-kirjan esimerkkiä palvelukataloogista jo useasti runkona - se listaa hyvin asioita, jotka palveluista PITÄISI hahmottaa.

IT-käyttäjäorganisaatiot ovat huomanneet ITILin merkityksen hyvin ja lisäävätkin nykyään jo lauseen "toimintanne tulee olla ITILin mukaista" IT-palveluiden tarjouspyyntöihin. Aika helppoa pyytäjälle, tosin silloin pyytäjänkin olisi hyvä tuntea ITIL että rajapinnat toimisivat kunnolla organisaatioiden välillä.

Template by - Abdul Munir | Daya Earth Blogger Template