Konfiguraationhallinta ja Gordionin solmu

On vanha vitsi, että jos suunnitelmissa on konfiguraationhallinnan prosessin ja CMDB-työkalun käyttöönotto, nopein ratkaisu selvitä tilanteesta ehjänä on unohtaa koko juttu. Aiheesta onkin muodostunut varsinainen Gordionin solmu.

Aihealueesta jotain tietävät ihmiset jakautuvat usein erilaisiin arkkityyppeihin:

  • ITSM PRO: ”Kun katsot vaan ITIL:stä hyvät käytännöt, hankit Gartnerin suositteleman työkalun, jossa tarvittavat vimpaimet on saatavilla OOB (out-of-the-box), määrittelet ja raportoit KPIt, parannat CSI-prosessilla sekä huolehdit kunnollisesta jalkautuksesta, niin kaiken pitäisi olla ihan no problem!”
  • CMDB GURU: ”Se on kuule monimutkainen juttu, mutta mahdollista tehdä kun ymmärtää monimutkaisia teknisiä juttuja, kysy vaan multa!”
  • KYYNINEN KONSULTTI: ”Yritetty on ja aina tullut pelkkää kuraa lopputuloksena, unohda koko juttu. Keskity mieluummin parantamaan asiakaskokemusta!”
  • BUSINESS MAN: ”Meilläkin ne yritti, puhui jostain business impact analyyseistä, työtunteja ja rahaa paloi ja tosi hyvää dataa on nyt kuulemma jossain BCMD-järjestelmässä?”

Kun katson omaa työhistoriaa ajassa taaksepäin, tunnistan itseni ainakin kolmesta ensimmäisestä arkkityypistä. Viitekehyksillä on tullut brassailtua, teknologiapornossa on pyöriskelty ja kyynisyyskin on joskus työntynyt ihon alle.

Miksi aihe sitten on niin haastava? Yksinkertainen vastaus on konfiguraationhallinnan prosessin monimutkaisuus verrattuna muihin tyypillisiin palvelunhallinnan prosesseihin. ITIL-kirjojen konfiguraationhallinnan prosessi on vaikeaselkoisesti kuvattu ja prosessi jääkin harmittavan usein vähemmälle huomiolle.

  • Työkalu- ja teknologiaspekti on korostunut. Käytännössä prosessia ei voi ottaa käyttöön ilman soveltuvaa työkalua, joka tukee kaikkia alla mainittuja vaatimuksia.
  • Vaadittava datamalli relaatioineen ja viittauksineen liiketoimintatietoihin kuten asiakas- ja sopimustietoihin on usein hyvin monimutkainen ja vaatii hyvää suunnittelua ja kommunikaatiota organisaatiossa.
  • Prosessilla on monimutkaiset sidokset sisarprosesseihin. Konfiguraationhallinnan prosessi yksin ei pysty ylläpitämään tietoja CMDB:ssä, vaan se tarvitsee tukea muilta prosesseilta kuten muutoshallinnalta ja palvelupyyntöjenhallinnalta. Prosessin hyödyt eivät myöskään realisoidu, mikäli konfiguraatiotietoja ei käytä kukaan (tai tiedot eivät ole hyödyllisiä muille prosesseille).
  • Asetetut tavoitteet ja odotukset prosessille johtavat usein hyvin siihen, että toteutuksen laajuus paisuu. Toteutus taas täytyy tehdä pienissä askelissa, jotta pysytään järjellisissä aikatauluissa. Kehityssuunnitelman teko onki kaiken A ja O kun mietitään, mitä asioita halutaan ja voidaan nostaa toiveiden tynnyristä ensimmäisenä.
  • Niin kuin kollega Peltoniemi osuvasti aiemmin kuvasi, CMDB ja konfiguraationhallinta ei koskaan tule valmiiksi, se elää ja kehittyy palveluorganisaation ja sen palveluiden mukana. Tämä edellyttää, että prosessi on kyvykäs kommunikoimaan eri sidosryhmien kanssa, tunnistamaan uudet tarpeet ja vaatimukset ja viemään muutokset käytäntöön. Päivästä ja vuodesta toiseen.

Eli pitäisikö kyynistä konsulttia kuulla ja jättää konfiguraationhallinta väliin ja keskittyä muihin prosesseihin? Konfiguraatiotietoa ylläpidetään palvelutehtaassa joka tapauksessa erilaisissa tietojärjestelmissä, excel–lomakkeilla, jne. Kyse on yksinkertaisesta päätöksestä:

  • Halutaanko konfiguraatiotietoja ylläpitää keskitetyssä tietovarastossa yhdenmukaisten prosessien mukaisesti?
  • Vai annetaanko sidosryhmien organisaatiossa hoitaa tietojen ylläpito haluamallaan tavalla?

Jos päädytään ensin mainittuun vaihtoehtoon, oikotietä onneen ei ole. Konfiguraationhallinnan kehittäminen tulee aloittaa suunnittelutyöllä, joka kattaa käytettävät teknologiat, prosessit, datamallin sekä kehityksen tiekartan suunnittelun jossa kunkin vaiheen tuotokset ja saavutettavat hyödyt ovat selkeästi tunnistettuna, sovittuna ja kuvattuna.

Justin Group Oy kouluttaa käytännön konfiguraationhallintaa ja kuuluu Oppia.fi-verkostoon. Uusimmat kurssitoteutukset nähtävissä täältä.

 

aki

Aki Lähteenmäki

Kirjoittaja on vuodesta -98 työskennellyt monissa eri rooleissa palvelunhallinnan ympärillä.

Ennen JustInin perustamista Aki työskenteli 8 vuotta konsulttina eri yrityksissä. Hän on myös suomen ITSMF:n CMDB ja palveluportfolio SIG:n (special interest group) puheenjohtaja.

 

 

LinkedIn

 

Koska CMDB on valmis?

Olin juuri pitänyt onnistuneen CMDB-workshopin ja kävelin samaa matkaa taksille asiakasorganisaation kollegan kanssa, kun sain mielenkiintoisen kysymyksen: ”Oletko koskaan nähnyt CMDB:tä, joka olisi valmis?”. Vastasin, että en ole, koska mielestäni määritelmänsä mukaan CMDB ei ole koskaan valmis. Kollegani oli tullut samaan lopputulokseen.

Konfiguraationhallintatietokanta eli tuttavallisemmin CMDB on tapa hallita palveluiden johtamiseen liittyvää tietoa strukturoidussa muodossa. Se on keksitty, koska on tarve hallita palveluihin liittyvää tietoa loogisesti jäsennellysti siten, että tietoa voidaan paitsi löytää niin myös hyödyntää automatisoiduissa toimenpiteissä. Perinteinen Sharepoint kansioineen ja tiedostoineen ei palvele tätä tarvetta, koska tietoa on vaikeampi normalisoida samaan muotoon ja toisaalta käyttää automaattisissa toimenpiteissä kuten raporteissa. Siksi tarvitaan määriteltyyn rakenteeseen jäsenneltyä tietoa.

CMDB ei ole päämäärä. Se on keino saavuttaa tavoitteita. Hyvän CMDB:n ensisijainen tunnusluku ei mielestäni ole 100 % määritellystä tiedosta, vaan 100% tai 95% sen tavoitteen saavuttamisesta, mitä varten määritelty tieto on CMDB:ssä alunperin haluttu hallita. Ensimmäinen tunnusluku yleensä kyllä korreloi jälkimmäisen kanssa ja sitäkin tarvitaan.

Konfiguraation rakenneosien eli CI:den ilmentymäkohtainen tieto sekä CI:den ilmentymien suhteet mahdollistavat nopeamman ja laadukkaamman vianselvityksen, assettien tehokkaamman hallinnan, kustannusten tarkoituksenmukaisemman jyvittämisen sekä palveluiden kustannuksien hallinnan ja laskuttamisen tarkemmin, mutta vähemmällä työllä. Niistä saavutetut hyödyt konkretisoituvat viimekädessä rahaksi ja siksi CMDB:n olemassaolo on perusteltua.

CMDB ei ole mielestäni koskaan valmis. Syitä on pääpiirteissään kaksi. Ensinnäkin maailma muuttuu sitä tahtia, että säännöllisen epäsäännöllisesti syntyy tarvetta muuttaa olemassa olevaa tietoa CMDB:ssä. Tulee uusia teknologioita, organisaatiot muuttuvat, laskutus muuttuu jne. Toinen tärkeämpi syy on se, että ainakin minun silmissäni on ääretön määrä mahdollisuuksia parantaa toimintaa CMDB:tä kehittämällä. Itse olen tehnyt CMDB:tä liki 10 vuotta ja kyseisen CMDB:n elinkaaren aikana on tullut koko ajan enemmän asioita, joiden suhteen syntyy positiivinen business case hallita asiaan liittyvää tietoa kunnolla CMDB:n filosofiaa ja periaatteita noudattaen. Jossain vaiheessa tahti voi hiipua, mutta liike ei pysähdy koskaan.

Vaikka CMDB ei koskaan olisi muodollisesti valmis, se kannattaa silti toteuttaa. Se mahdollistaa IT-palvelujohtamiseen liittyvien ongelmien ratkaisun ja tuottaa arvoa. Määritellyn osan tavoitteet voidaan saavuttaa CMDB:n avulla, mistä syystä se kannattaa kyseiseltä osaltaan toteuttaa.

Tule keskustelemaan aiheesta kursseille! Oppia.fi – Oppimisen verkkokaupasta löydät CMDB Foundation ja Käytännön konfiguraationhallinta -toteutuksia. 

 

aaeaaqaaaaaaaal8aaaajdjimgq0nzmxltewn2utngi1yi05ndm2lwu0ngixmzm2mdyyna

Lari Peltoniemi

Kirjoittaja on työskennellyt prosessien ja toiminnan kehittämisen ja arvioinnin alueella yli 10 vuotta. Päätoimisesti IT-palveluiden prosessien määrittelyn, kehittämisen ja johtamisen alueella hän on toiminut vuodesta 2005.

Lari on konsultoinut ja valmentanut useita suomalaisia ja kansainvälisiä yrityksiä ja organisaatioita ITIL/ITSM prosessien määrittelyihin, käyttöönottoon ja kehittämiseen liittyen. Lari on sertifioitu ITIL Foundation ja CMDB Foundation valmentaja.