MENESTYKSEKKÄÄN CMDB-KEHITYSHANKKEEN SUUNNITTELU JA TOTEUTUS

Justinin Jani Palmu puhui toukokuun webinaarissa menestyksekkään CMDB-kehityshankkeen suunnittelusta ja toteutuksesta. Webinaaria valmistellessaan hän toteutti kyselyn, jossa omia kokemuksiaan CMDB-kehityshankkeista jakoi 58 henkilöä 38 eri organisaatiosta. Webinaarin kulma olikin teknisten asioiden sijaan siinä, millaisia hyötyjä ja haasteita kyselyyn vastanneet sekä justinlaiset ovat kohdanneet vuosien varrella.

CMDB:n hyvin lyhyt oppimäärä a.k.a. teoriapläjäys

CMDB itsessään ei tarjoa mitään. Se on tietovarasto, joka on riippuvainen käyttäjistään ja heidän tarpeistaan: tietoa hyödyntävistä ja sitä tuottavista prosesseista, ihmisistä ja järjestelmistä. Se on myös kokonaisuus, joka tarvitsee omistajuutta toimiakseen: tietosisällön, mallin, luokittelun ja hallintaprosessin omistajuutta. On yleinen väärinkäsitys, että konfiguraationhallintaprosessi itse päivittäisi tietoja millään tavalla – tietojen päivittäminen on aina tiedontuottamisprosessin vastuulla.

CMDB  ei myöskään ole saari, muusta irrallaan. Se on osa palveluiden elinkaarenhallintaan ja johtamiseen liittyvää kokonaisuutta. Usein CMDB ja konfiguraationhallinnan tarkoitus onkin hyvä kuvata palvelusalkunhallinnan avulla. Palvelusalkku ja -katalogit kuvaavat palvelut, joita palveluorganisaatio tuottaa. CMDB pitää sisällään tiedot käyttöönotetuista palveluista ja niiden palvelukonfiguraatiosta. Kun puhutaan palvelukonfiguraatiosta, puhutaan taustapalveluista, laitteistoista, ohjelmistoista ja integraatioista, joista asiakkaan kokema palvelu koostuu.

Palvelukonfiguraatioiden välillä on riippuvuuksia ja suhteita toisiinsa. Näiden suhteiden hallinta edellyttää, että organisaatio on määritellyt tietomallin, jonka mukaisesti tietoja hallinnoidaan keskitetysti. Lisäinfoa tietomalleista, niiden luokittelusta ja eri teknologioihin liittyvistä spesifisistä malleista löydät mm. webinaaritallenteesta. Kannattaa myös tutustua Justinin PDMC-malliin, joka ladattavissa organisaatioiden hyödynnettäväksi ilmaiseksi.

Minkälaisia haasteita CMDB:n ja konfiguraationhallintaprosessin käyttöönotossa on tunnistettavissa?

CMDB-kehityshankkeiden haasteet voidaan tyypillisesti jakaa muutamaan alueeseen:

1. Ylioptimistinen laajuus – korjattavia asioita otetaan työn alle aivan liian paljon kerrallaan.
2. Puutteellinen hyötyjen ymmärtäminen ja tuotettavan arvon kuvaaminen. Kuinka perustella jotain, mikä näyttäytyy muille hyvin epäkonkreettisena tekemisenä?  
3. Epäselvät omistajuudet ja vastuut. Toimintaa ei pystytä johtamaan tehokkaasti ja läpinäkyvästi.
4. Heikosti kuvatut tai toimimattomat tiedontuottajaprosessit. Ajantasainen Konfiguraationhallinnan ja CMDB:n tietosisältö edellyttää, että joku pitää yllä tietoja. Vaikka CMDB työkaluna toimisikin hyvin, mutta tiedot eivät ole ajantasalla, ei tehdyistä kehitysponnisteluista synny hyötyä..
5. Uskotaan, että teknologia ratkaisee prosessin ja organisaation puutteet ja ongelmat. CMDB:tä on vuosikaudet pidetty erittäin teknisenä asiana, mutta onneksi viime vuosien aikana tästä mielikuvasta ollaan päästy pyristelemään irti. Tekniset ratkaisut eivät yksinään tuota arvoa, mutta niiden tehokas ja älykäs käyttö tuottaa.

Olivatko kyselyyn vastanneet suomalaiset organisaatiot samaa mieltä? Koettujen haasteiden listalta vastaajat valitsivat kolme suurinta haastetta, joita he ovat kohdanneet tai uskovat kohtaavansa CMDB:n kehittämisen yhteydessä. Suurimmiksi haasteiksi nousivat

1. priorisointi (muut prioriteetit, kuten operatiiviset tai muut kehittämistehtävät ajavat yli CMDB:n kehittämisen)
2. liian vähäinen tai osaamaton henkilöresursointi sekä
3. sidosryhmien epäselvät vastuut ja velvollisuudet.

Top 3 -vastaukset pysyivät samoina, kun tuloksia tarkasteltiin vastaajan aseman mukaan, mutta suuruusjärjestyksessä oli eroja. Ylemmän johdon vastauksissa suurin haaste oli korostuneesti liian vähäinen tai osaamaton henkilöresursointi. Asiantuntijoiden vastauksissa nousi hieman muita ryhmiä enemmän esille myös kehittämisen hyödyt, joita ei nähdä riittävän suureksi käytettyyn aikaan ja rahaan nähden. CMDB:n ja kofiguraationhallinnan kehittämishankkeiden arvoa ei ole välttämättä osattu perustella asiantuntijatehtävissä toimiville.

Palveluntarjoajat eli yritykset / organisaatiot, jotka tekevät IT-palveluiden tuottamista liiketoimintana, nostivat esille samat kolme haastetta. Sisäiset palveluntarjoajayksiköt sen sijaan korostivat haasteena sitä, että hyötyjä ei nähdä riittävän suureksi käytettyyn aikaan ja rahaan nähden.

Avoimissa vastauksissa esiin nousivat hyödyn ja arvon ymmärtämisen puute, organisaation kulttuuri ja osaaminen (”Ympäröivä organisaatio ei innostunut asiasta”) sekä tietojen päivittämiseen liittyvät haasteet (tekniset tai prosessiin liittyvät vaikeudet, datan heikko laatu). Esiin nousivat myös resurssien ja vastuiden puute sekä työkalujen ja prosessien puute.

Samankaltaisiin haasteisiin Justinin asiantuntijatkin törmäävät toimeksiannoissaan. Omassa organisaatiossa kannattaakin syventyä hetkeksi miettimään, löytyykö keinoja vastata näihin haasteisiin etukäteen tai ainakin lieventää niitä, jos ja kun CMDB-kehityshankkeelle on tarvetta.

Läpi tuskien taipaleen: miksi se kuitenkin kannattaa?

Yleisellä tasolla CMDB:n käyttäminen ja hyödyntäminen kannattaa muun muassa sen takia, että IT-palveluorganisaation raportointikyvykkyydet kasvavat. CMDB:n myötä saadaan tietovarasto, josta pystytään tekemään tietojen luokittelua ja analysointia, operatiivista tai tietoturvaan liittyvää raportointia,  viranomaisvaatimuksiin vastaamista tai johdon raportointia.

CMDB mahdollistaa kokonaisuuden hallinnan ja tärkeän yleisen viestinnän. CMDB:n avulla voidaan tehdä erilaisia analyysejä prosessien tueksi. Voidaan ajatella, että CMDB, ja hyvä toimiva sellainen, auttaa häiriötilanteiden hallinnassa juurisyyanalyysin tai muutoksenhallinnassa vaikutusanalyysin tekemisen kautta, puhumattakaan tuikitärkeästä haavoittuvuuksia hallinnasta.

CMDB  auttaa ymmärtämään inventoinnin näkökulmasta paremmin, mitä omistetaan ja mitä pitää hallita. Myös talouden hallintaan liittyviä käyttötapauksia, kuten kulujen jyvittämistä, kulujen koontia, laskutusta tai volyymitietojen keräilyä, pystytään ratkaisemaan CMDB:n avulla.

Miten suomalaiset organisaatiot ovat kokeneet saavuttaneensa hyötyä laadukkaamman CMDB:n avulla?

Tehdyssä kyselyssä myös hyötypuolen vastauksista esiin nousi kolme hyötyä ylitse muiden:

1. Häiriötikettien ratkaisu nopeutui.
2. Tuotantoinfrastruktuuriin kohdistuvat muutokset onnistuivat paremmin.
3. Palvelutuotannon automaatioaste nousi.

Nämä ovat toki saattaneet olla ensimmäiset asiat, jotka on haluttu laittaa CMDB-kehityshankkeissa kuntoon.

Kun vastauksia tarkastellaan vastaajien aseman perusteella, löydetään jotain mielenkiintoista. Ylemmän johdon kokemissa hyödyissä asiakastyytyväisyyden paraneminen korostuu, mutta onnistuneiden muutosten määrä ei puolestaan yltänyt johdon TOP 3 -listalle. Mielestäni näiden hyötyjen välillä on selvä korrelaatio: jos tuotantoon tehtävät muutokset onnistuvat paremmin, se korreloi varmasti häiriöiden määrään. Kun häiriöitä on vähemmän, oletan asiakastyytyväisyyden parantuvan. Toki asiakastyytyväisyyteen vaikuttaa moni muukin asia, mutta CMDB:n hyötyjä voi varmasti perustella myös asiakastyytyväisyyden kautta.

Toinen mielenkiintoinen löydös oli tietoturvallisuuden paraneminen, joka esiintyy jossain määrin ylemmän ja keskijohdon vastauksissa CMDB:n hyötynä, mutta asiantuntijoiden vastauksissa sitä ei näy ollenkaan.  

Kun vastauksia tarkastellaan organisaatioityypeittäin, huomataan, että merkitystä on myös sillä, minkälaiseen organisaatioon CMDB:tä ollaan rakentamassa. Häiriötiketit, muutosten onnistuminen ja automaatioaste ovat edustettuna myös organisaatiotyypeittäin tehdyssä analyysissä, mutta asiakastyytyväisyyden paraneminen nousee selkeästi enemmän esille palveluntarjoajaorganisaatioissa. Yrityksen sisäistä IT-yksikköä ei välttämättä tunnisteta palvelun toimittajaksi, eikä yrityksen omaa henkilöstöä IT:n asiakkaaksi.

Avoimissa vastauksissa mainittiin myös tietoturvallisuuden ja asiakastyytyväisyyden paraneminen. Näkyvyys kokonaisuuteen ja arkkitehtuuriin paranee –  se on arvo sinänsä. Palvelutuotannon henkilöstön työtyytyväisyyden paraneminen, tiedon hakemisen nopeutuminen ja liikevaihdon kasvu laskutuksen tarkkuuden parannuttua olivat muita koettuja hyötyjä.  

Menestysresepti ja onnistumisen ainesosat

Jotta CMDB-kehityshanke suunnitellaan ja toteutetaan onnistuneesti, tarvitaan hyvä resepti ja siihen hyvät raaka-aineet:

1. Määrittele tavoitetila
2. Suunnittele käyttöönotto
3. Viesti fiksusti ja paljon.

Lähdetään tällä kertaa siitä olettamuksesta, että meillä on jonkun verran puolivalmisteita käytössä – kuten asialliset tekniset järjestelmät ja tietolähteet, sekä taito kuvata tieto hyvin ja kyky tehdä projektia.

Ensimmäisenä tärkeänä, ja jopa itsestään selvänä asiana, joka jostain syystä tuntuu jäävän välillä vähän puutteelliseksi, on tavoitetilan määrittäminen. Sitä voisi verrata pilvenpiirtäjän rakennusprojektiin: pitää miettiä, kuinka korkea pilvenpiirtäjä halutaan tehdä, kuinka monta kerrosta siellä on, mikä sen käyttötarkoitus ja sijainti on sekä minkälaiset ihmiset sitä tulevat käyttämään. Sama pätee CMDB:hen.

Tavoitetilan määrittämistä varten on olemassa hyviä työkaluja ja valmiita listoja. Esimerkiksi kannattaa tutustua ja ladata JustinShopin ilmainen SACM Scope planning checklist.

Suunnittele käyttöönotto

CMDB-kyselyn tulosten haasteissa oli maininta siitä, että kokonaisuus on niin laaja, ettei alkuun tahdo päästä millään. Kyse ei kuitenkaan ole salatieteistä, vaan ihan perinteisen projektin tai hankkeen suunnittelusta. CMDB-hankkeen ’kulmakivet’ ovat prosessit ja hallintamallit, teknologiaan liittyvät kysymykset, ihmiset ja heidän osaamisensa sekä tieto ja integraatiot.  

On tärkeää ymmärtää, että näiden osa-alueiden kanssa pitää mennä eteenpäin tasapainossa. Jokaisesta kulmakivestä löytyy niitä asioita, jotka on pakko tehdä, mutta millä laajuudella ja missä vaiheessa, se on projektissa aina erikseen päätettävä asia. 

Kokemustemme perusteella haaste on vuosikausia ollut se, että hankkeet ovat olleet hyvin teknologiapainotteisia. Onneksi nykyään yhä enenevässä määrin kulmakivien nelikenttä on ymmärretty suomalaisissa organisaatioissa paremmin.

Käyttöönotosta puhuttaessa on hyvä muistaa systemaattinen tapa viedä työtä eteenpäin.  Suunnitellaan, rakennetaan, käyttöönotetaan ja sitten arvioidaan. Vaiheistaminen ja jatkuva priorisointi ovat tämän reseptinosasen kohdalla ne tärkeät muistettavat asiat neljän kulmakiven lisäksi.

Hyviä työkaluja on olemassa myös suunnittelun tueksi. Esimerkiksi kannattaa tutustua ja ladata JustinShopin ilmainen 4×4 Matriisi.

Viesti fiksusti ja paljon

Menestysreseptiin viimeinen osio littyy viestintään ja hyötyjen kommunikointiin.

CMDB:n ja konfiguraationhallintaprosessin kehittäminen on aina prosesseja, organisoitumista, työtapoja ja usein kulttuuriakin muuttavaa tekemistä. Se vaatii ihmisiltä laajasti osallistumista tekemiseen eri tasoilla, jonka vuoksi hankkeelle pitää saada tarvittava prioriteetti. Jatkuva ja oikea-aikainen viestintä on yksi kriittisimmistä onnistumisen mahdollistajista.

Viestinnässä ei ole kyse siitä, että julkaistaan intraan tiedotteita ja odotetaan ihmisten lukevan ne läpi. Kyse on aktiivisesta ja kohderyhmäkohtaisesti suunnitellusta viestinnästä, jota tehdessä asetutaan kohderyhmän asemaan. Kukaan muu ei tule myymään hanketta puolestasi. Viesti, viesti, viesti. Ja toista.   Vinkkejä viestin valintaan, erilaisia käyttötapauksia ja kohderyhmiä käsitellään webinaarissa laajemmin. Voit katsoa tallenteen täältä.

Muita vinkkejä CMDB-hankkeen suunnitteluun

Sitoudu ja verkostoidu.

Vastoinkäymisiä tulee, ja suunnitelmat tuskin toteutuvat sellaisenaan. Samankaltaisia kokemuksia on muillakin. Etsi verkostosta palloseinä ajatuksillesi ja opi muiden kokemuksista. Älä luovuta.
Kyselyn perusteella vastaajat osoittavat vahvaa sitoutumista CMDB:n jatkokehittämiseen, joten palloseinäpintaa varmasti löytyy verkostoista jatkossakin. Esimerkiksi itSMF (Tervetuloa – itSMF Finland) on hyvä paikka verkostoitua. Suosittelen!

Etsi pienet voitot.

Kokonaisuus on eittämättä iso ja laaja, mutta pikkuvoittoja löytyy varmasti. Hankkeen voi käynnistää ilman suuria investointejakin. Esimerkiksi hallintamallin ja sen olennaisen ytimen CCB:n (Configuration Control Board), pystyyn laittaminen auttaa tunnistamaan tietoa käyttävien tahojen tarpeet, ja sen saa käyntiin ihan vain sopimalla.
Säännöllisesti tehtävä CMDB Trust Index on organisaatiossa toteutettu kysely ihmisten luottamuksesta CMDB:n toimintaan. Mittaamiseen ei tarvita erillistä työkalua, vaan homma hoituu vaikka Excelillä tai Formsilla.  Pistokoemaisesti tehty FAM (Friday Afternoon Measurement) -auditointi tietylle tietojoukolle puolestaan vaatii käytännössä vain Excelin ja muutamia ihmisiä mukaan.

Varmista osaaminen.

CMDB:n kehittäminen ei ole salatiedettä, vaikka se ehkä joskus tuntuu siltä. On todella tärkeää, että kehittämisestä vastaavat henkilöt ymmärtävät siihen liittyvät perusperiaatteet. Siihen valmistavaa, suunnittelua materiaalia on tarjolla paljon. Justin jakaa  JustinShopin kautta ilmaista sisältöä, jota voi ladata Creative Commons lisenssillä omaan käyttöön. Aiheesta löytyy hyvin paljon myös koulutusta esimerkiksi Oppia.fi:n kautta.

Käytä konsulttia.

Joku on varmasti tehnyt kehittämishankkeita aiemminkin. Kysy kokemuksia verkostoltasi. Konsulttiapua löytyy teknisestä toteutuksesta prosessi- ja muutosjohtamiseen, kouluttamiseen ja sparraamiseen.

Halutko tietää lisää?

Julkaistu 27.06.2024