Mikä niissä luotettavissa raporteissa oikein kestää?!

Tiistai 21.6.2011 - Tommi Noro

Mikä on keskitetty tietovarasto (EDW)?

Keskitettyyn tietovarastoon kootaan mahdollisimman kattavasti kaikki se data, jota operatiivisessa, taktisessa ja strategisessa päätöksenteossa tarvitaan tänään ja huomenna. Koska me emme vielä tänään tiedä, mitä informaatiota huomenna tarvitaan, EDW:hen kannattaa tallentaa sellaistakin transaktiotason dataa, joka on tänään edullisesti prosessoitavissa ja jolla todennäköisesti on liiketoiminta-arvoa tulevaisuudessa.

Esimerkki tällaisesta laatuseurantaan ja takuuhallintaan liittyvästä "molekyylitason datasta" on tieto yksittäisen valmistettavan tuotteen keskeisimmistä komponenteista. Keneltä toimittajalta osat ovat tulleet? Mitkä ovat osien sarjanumerot? Ja mitkä ovat kyseisen tuotteen valmistusprosessin aikaleimat? Kun yritys mahdollisesti jonakin päivänä kokee normaalia korkeamman reklamaatiopiikin, EDW:n avulla saadaan tietää, mikä laadussa poikkesi, milloin ja miksi. Ja mihin asiakkaisiin ja toimittajiin meidän kannattaa ottaa yhteyttä heti?

Keskitetyn tietovaraston avulla tiedon tarvitsijalla on vain yksi tietolähde. Kaikki tarvittava informaatio löytyy luotettavasti ja nopeasti yhdestä paikasta. Raportointiportaalit tarjoavat käyttäjille pääsyn tietovaraston sisältöön valmiiksi jäsenneltyjen ja organisoitujen raporttien, dashboardien ja analyysien avulla. Mikäli tarvittavaa tietoa ei EDW:ssä vielä ole, ko. tieto tulee integroida olemassa olevaan tietovarastoon.

Käytännössä tämä lähestymistapa tarkoittaa, että kun jokin liiketoimintafunktio tarvitsee uuden kyvykkyyden, IT-osaston ei tarvitse toteuttaa täysimittaista IT-projektia; riittää, kun tarvittava data integroidaan EDW:hen ja raporttinäkymä muokataan vastaamaan uutta tarvetta. Uuden kyvykkyyden rakentaminen voidaan toteuttaa parhaimmillaan viikoissa tai jopa päivissä.

Keskitetty tietovarasto kuulostaa ratkaisuna järkevältä, helpolta ja yksinkertaiselta. Sitä se onkin, kun tietovarasto on ensin saatu pystytettyä, spagettiarkkitehtuuria vähennettyä, "DDT:tä aiheuttavat" data- ja prosessivirheet minimoitua ja yritykseen rakennettua datan jalostamisen kulttuuri. Ideaalitilanteessa liiketoiminnalle tarjotaan koska tahansa ja mihin tahansa kysymykseen luotettava vastaus, niin tänään kuin huomennakin.

Vain harvoissa yrityksissä on kuitenkin näin hyvä tilanne. Miksi? Käytännössä kaikkia yrityksen prosesseja ohjaavat ja tukevat useat tietojärjestelmät, johin kertyy massiivinen määrä tietoa joka hetki ympäri vuorokauden. Miten siis voi olla mahdollista, että tarvittavaa tietoa ei ole luotettavasti saatavilla? Onko syy spagettiarkkitehtuurissa – siis tekniikassa? Vai sittenkin ihmisissä?

Nurkat täynnä dataa, mutta missä on informaatio?

	Keskitetty tietovarasto yksinkertaistaa IT-arkkitehtuuria (spagetti->lasagne) ja edesauttaa samalla datavirheiden ("DDT") tunnistamista ja hallintaa.

Ongelman ydin löytyy tästä: dataa kertyy informaatiopyramidissa lukuisiin järjestelmiin eri puolilla maailmaa, eri aikavyöhykkeillä ja eri kielillä. Usein tietoa tarvitaan myös kumppaneiden ja toimittajien järjestelmistä. Tiedon tarve ei juuri koskaan rajoitu vain yhteen yrityksen oman toiminnan alueeseen. Useimmiten halutaan saada kokonaisvaltaisempi kuva, jossa molekyylitason tiedot yhdistyvät yli toimintojen, prosessien, tuoteperheiden, asiakastiimien ja aikavyöhykkeiden. Dataa on  siis yksinkertaisesti liikaa!

Tekniikan lisäksi haasteita aiheuttavat myös ihmiset. "Systeemin omistaja" / IT-manageri saattaa kokea oman arvonsa organisaatiossa uhatuksi, jos ”minun suunnittelemani, rakentamani ja ylläpitämäni järjestelmä voitaisiin korvata keskitetyllä tietovarastolla”. Spagetilla on siis paljon kannattajia.

Kokonaiskuvan muodostaminen edellyttää tietojen tehokasta yhdistelyä eri järjestelmien välillä. Raportointi- ja analytiikkapuolella ongelma on ratkaistavissa keskitetyn tietovaraston (EDW) avulla. Ongelman edessä ollaan, kun tietovarastoa ei ole olemassa, varastosta puuttuu jokin oleellinen tieto tai kun tiedon jalostusketjuun on päässyt runsaasti virheellistä dataa – siis "DDT:tä". Myös puuttuva tieto on informaation jalostusketjuun vaikuttava DDT-hitunen.

Keskitetyn tietovarastoinnin TOP 6 haasteet

Tietovarastojen rakentamisessa on kiinnitettävä huomiota seuraaviin kysymyksiin:

1) Mistä data löytyy?

On selvitettävä, mistä järjestelmästä tai järjestelmistä tarvittavat tiedot löytyvät, missä muodossa ne siellä ovat, ja missä muodossa ja millä keinolla ne ovat sieltä saatavissa. Entä jos samat tiedot löytyvät useista eri järjestelmistä, ja kaikissa järjestelmissä voidaan tehdä ko. tietoihin lisäyksiä, muutoksia ja korjauksia? Tyypillinen esimerkki tästä on asiakastietojen ylläpitäminen esimerkiksi myynti-, laskutus- ja CRM-järjestelmissä. Onko järjestelmä, josta löytyy kattavimmat tiedot asiakkaista, myös luotettavin ja ajantasaisin? Entä jos tietoa ei saada mistään järjestelmästä? Voidaanko se päätellä tai johtaa joidenkin muiden tietojen avulla? Vai voidaanko tieto ostaa yrityksen ulkopuolelta?

2) Miten on datan laadun laita – emme halua DDT:tä EDW:hen!

Seuraavaan ja ylivoimaisesti hankalimpaan ongelmaan törmätään, kun tiedetään, mistä tarvittavat tiedot on saatavilla, ja kuinka ne sieltä saadaan. Ongelman nimi on tiedon luotatettavuus ja laatu. Tietovarastolla on "ilkeä kyky" paljastaa puutteita lähdejärjestelmien tiedon rakenteellisessa ja sisällöllisessä laadussa. Jos käyttäjä X on vahingossa lisännyt myyntijärjestelmään tuotteen, jota ei oikeasti ole olemassa, se tulee esiin jokaisessa tuotteita tavalla tai toisella seuraavassa raportissa.

Puhtaiden vahinkojen lisäksi moni tieto lisätään järjestelmiin hyvässä uskossa:  ymmärtämättä, että jotakin virheellistä on tapahtumassa. Tyypillisiä esimerkkejä ovat pienet erot henkilöiden nimissä, osoitteissa ja tuotetiedoissa. Jokainen voi helposti arvata, että A1, a1, A 1, A-1, A_1 ja a-1 ovat yksi ja sama tuote. Kun tiedot on tallennettu relaatiotietokantaan, jokaisesta variantista muodostuu kuitenkin oma "tuotteensa". Kun näistä tiedoista ajetaan raportteja, raporteissa näkyy kuusi eri tuotetta yhden sijaan.

Vielä haastavampia ovat realistiseen haarukkaan osuvat datan sisältövirheet. Tällaisesta virheestä on kyse esimerkiksi silloin, kun tuotteen sisäiseksi siirtohinnaksi on merkitty lähdejärjestelmässä 34 euroa, kun oikea siirtohinta on 43 euroa. Tämän tyyppisissä tilanteissa fiksuinkaan virhesuodatin ei kykene tunnistamaan kaikkea DDT:tä.

3) Löytyykö yhteistä nimittäjää?

Seuraava kompastuskivi on eri järjestelmistä saatavien tietojen yhdistäminen ja yhdenmukaistaminen. Järjestelmissä on valtava määrä erilaisia avaintietoja, joita käyttäjät eivät välttämättä koskaan näe, joiden olemassaolosta he eivät tiedä, ja joista heidän ei tarvitsekaan välittää. Järjestelmien välisten tietojen yhdistelyssä nämä avaintiedot ovat kuitenkin ensiarvoisen tärkeässä asemassa.

Voisi kuvitella, että kun yrityksellä on joukko valmistettavia ja myytäviä tuotteita, tuotteille olisi vähintäänkin samat tuotekoodit järjestelmästä riippumatta. Yllättävän usein totuus on kuitenkin toinen. On hyvin tavallista, että ‘Ruuvi 30/20mm’ löytyy yhdestä järjestelmästä numeerisella koodilla 1043567 ja toisesta järjestelmästä alfanumeerisella koodilla R45TSF5. Lisäksi lyhytkin tuotenimi voidaan kirjoittaa usealla eri tavalla, kuten aikaisemmassa esimerkissä nähtiin.

Kysymys kuuluu: minkä tiedon pohjalta eri järjestelmissä olevat tuotetiedot voidaan yhdistää toisiinsa, jos tuotekoodeja tai nimiä ei voida käyttää? Vastaavat avain- ja koodiongelmat liittyvät muihinkin tietoihin, kuten asiakas-, toimipaikka-, kustannuspaikka- ja toimittajatietoihin. Virheellinen – tai puuttuva – linkitys eri lähdejärjestelmien välillä tuottaa datan eheysvirheitä EDW:hen. Siis lisää DDT:ä!

4) Riittäkö kaistaa?

Neljäs haaste liittyy tietojen liikutteluun: lähdejärjestelmästä hakemiseen ja tietovarastoon lataamiseen. Tämä muodostuu ongelmaksi, jos siirrettävää tietoa on paljon, mutta yhteydet ovat huonot, kuten esimerkiksi osaan Aasian ja Etelä-Amerikan maista on. Miten varmistetaan, että tieto on käyttäjän saatavilla ajoissa ja kattavasti? Entä jos tietovaraston lataus tukkii yrityksen verkon, jota asiakkaat tai tuotannonohjausjärjestelmä käyttävät samanaikaisesti? Tai yksittäinen lataus ei vain onnistu?

Usein ajatellaan, että tietojen siirtoon käytetään hiljaista yöaikaa, jolloin haitat ja häiriöt muille käyttäjille ovat mahdollisimman pienet. Globaali yritys ei kuitenkaan nuku hetkeäkään, sillä aktiivisia lähdejärjestelmiä ja käyttäjiä on aina jossakin päin maailmaa. Väliin jäänyt tiedonsiirtoeräajo jättää informaation eheyteen aukkoja – eräs muoto DDT:stä tämäkin! 

5) Mihin jäljet loppuvat?

Viides haaste liittyy tietojen jäljitettävyyteen. Käyttäjät haluavat tietää, mistä raportissa olevat tiedot ovat peräisin, miten tietoja on mahdollisesti muokattu, minkä hetken tiedot raporteilla näkyvät, koska tiedot on tuotu tietovarastoon, ja mitkä tiedot ovat jääneet päivittymättä. Myös järjestelmän ylläpidon kannalta on tärkeää, että eri järjestelmistä tulleet tiedot ja näiden latausaikataulut on kirjattu ja jälkikäteen tutkittavissa. Ongelma korostuu erityisesti silloin, kun tietoja summataan ja yhdistellään. Kuinka voidaan todentaa tai osoittaa, mitkä lähdejärjestelmistä saadut tapahtumat sisältyvät esimerkiksi tiettyyn tunti-, päivä- tai viikkotasolle laskettuun summaan? Jälleen ilmeinen paikka DDT:n synnylle!

6) Kuka omistaa datan? Entä tietoturva?

Keskitetyn tietovaraston rakentaminen on poikkeuksetta vastarintaa aiheuttava iso muutosohjelma. Tiedon omistajuus on kysymys, johon EDW-hankkeen myötä herätään ennemmin tai myöhemmin.

Tiedon arvoketjua parhaiten hyödyntävät yritykset ovat jo ohittaneet kysymyksen datan omistajuudesta:

"Tiimimme tavoitteena on tuottaa omissa lähdejärjestelmissämme mahdollisimman luotettavaa dataa. Vastaamme siitä, että data on EDW:ssä nopeasti ja oikein. Jos näin ei ole, haluamme kuulla siitä välittömästi, jotta voimme korjata tilanteen. Haluamme, että tiimimme tuottama data on yrityksen kaikkien muiden funktioiden ja tiimien hyödynnettävissä. Se on meidän etumme ja koko yrityksen etu! Samanlaista ajattelua ja toimintaa edellytämme myös muilta."

Kokemus on osoittanut, että tiedon jakaminen ja käyttöoikeuksien hallinnointi yhdessä keskitetyssä paikassa on helpompaa kuin tietoturvan ylläpito IT-spagetissa.

Kyllä kaikki järjestyy!

Edellä kuvatut seikat ovat osa niistä haasteista, joihin tietoja päätöksenteon tueksi jalostettaessa törmätään. EDW-hankkeessa, jos missä, korostuu kokemus, avoimuus, asiantuntemus, sponsorien osallistuminen muutoksen johtamiseen sekä organisaatiosiilojen rajat ylittävä tiimityö.

Kaksi kolmasosaa liiketoiminnan isoista hankkeista epäonnistuu. Holistinen EDW-hanke on muutosohjelmana yritysmaailman haastavimmasta päästä, ja panosten on oltava sen mukaiset.

Onnistumistodennäköisyys on mahdollisimman suuri, kun EDW-hankkeen ytimeen valitaan ja valmennetaan High Performance Team – Huipputiimi, jossa yllä kuvattu ominaisuuksien lista yhdistyy energiaan ja intohimoon tärkeän muutoksen tekemiselle (lisää aiheesta Petrin artikkelissa High Performance Team onnistuneen muutoksen ytimessä).

Myös luova ongelmanratkaisukyky ja tietovarastointiin liittyvä erityinen ajattelumalli ovat asiantuntevan tietovarastotiimin keskeisiä ominaisuuksia. EDW-hankkeessa tulisikin varmistaa, että ko. asiantuntemusta on käytettävissä hankkeen alusta alkaen. Realistisuus aikataulujen laadinnassa sekä hankkeen selkeä rajaaminen ja jaksottaminen ovat ehdottomia edellytyksiä onnistuneelle tietovarastoprojektille.

Sponsorit tulee sitouttaa EDW-muutosmatkaan alusta lähtien: hyötyjä pyritään hakemaan hankkeen jokaisesta vaiheesta. Myös järjestelmän loppukäyttäjien eli tietojen hyödyntäjien odotusten hallinta on hankkeen kuluessa tärkeää. Liian optimistiset lupaukset kääntyvät antajaansa vastaan viimeistään silloin, kun aikataulut eivät pidä ja käyttäjät alkavat kysellä: ”Mikä niissä luotettavissa raporteissa oikein kestää?”