Tämä artikkeli käsittelee tietojohtamista tukevien IT-ratkaisujen päätöksentekoa ja toteutusmallia. Kerromme, mitä seikkoja päätöksenteossa ja toteutuksessa on syytä ottaa huomioon, ja mitkä ovat onnistumiseen vaikuttavat menestystekijät, myös esimerkkitapauksen kautta.
Lopuksi kiteytämme keskeiset neuvot päätöksentekijöille: liiketoimintajohtajalle, tietohallintojohtajalle ja datavetoisen hankkeen projektipäällikölle.
1. Miksi hajotetaan valmista, jotta se voidaan tehdä uudestaan?
Juuri pidetyssä erään ison organisaation seminaarissa pohdittiin muun muassa erilaisten tietovarastointimetodologien perusteita, hyötyjä ja haittoja. Keskustelu kiteytyi kysymykseen, onko tietojen keräämisen ja käytön vaatima tietotekniikka jo liian monimutkaista.
Alan kokeneet asiantuntijat pohtivat sitä, onko oikeasti jokin liiketoiminnallinen tarve sille, että lähdejärjestelmistä saatavissa olevat tiedot viedään seuraavien vaiheiden läpi:
- Muutetaan tieto ensin johonkin toiseen tekniseen muotoon ja siirretään toiseen tekniseen ympäristöön, esim. tietoaltaaseen, josta:
- Tiedot siirretään uuteen tekniseen ympäristöön (tietovarastointikanta) ja raakatiedot muotoillaan uuteen muotoon, josta:
- Tiedot usein muotoillaan raakatietovaraston monimutkaisen mallin vuoksi yksinkertaisempaan ja ymmärrettävämpään muotoon, esim. kolmannen normaalimuodon mukaisina rakenteina.
Ja vielä lopuksi muotoillaan tiedon jalostusrakenteita, jotka palvelevat pääosin raportointia.
Siis: ensin olemassa olevaa hajotetaan, sitten se kootaan. Sitten kuukausien työn tuloksena tiedot ovat alkuperäistä rakennetta myötäilevässä muodossa uudessa paikassa, tietovarastossa.
Toki hiukan kärjistämme: tämä ei ole tiedon käsittelyn kaava kaikissa tilanteissa, mutta kokemuksemme mukaan kuitenkin edelleen liian yleistä.
2. Tietojohtamisen tarpeita tukeva päätöksentekomalli
Tietojohtamisen IT-ratkaisut perustuvat lähes aina relaatiotietokantapohjaiseen tietovarastointiin.
Tilanteesta riippuen tietovarastointiratkaisu liittyy erilaisiin teknisiin ratkaisuihin ja konsepteihin, esimerkkeinä Data Lake, Data Lakehouse, erilaiset tietovarastointialustat sekä tiedon käsittelyn työkalut, kuten Databricks tai vaikkapa Power BI ja SPSS.
Vaihtoehtoja teknisille ratkaisuille siis on, ja päätöksen valinnasta tekee useimmiten IT tai tietohallinto. Päätöstä edeltävät tarpeiden ja tulevaisuuden näkymien arviointi, vaihtoehtojen punninta ja kustannuslaskelmat. Yleensä hankinta on sen verran merkittävä, että myös hankintaesitys liiketoimintajohdolle on tehty ja hyväksytetty.
Olemme käytännössä huomanneet, että teknisen ratkaisun valintaa ohjaa usein monimutkaisin tai haastavin tarve, olipa se sitten todellinen tai oletettu.
Kokemuksemme mukaan kaksi päätöksentekokriteeriä nousee ratkaiseviksi:
- Onko meillä tarvetta keskitettyyn tietojen keräämisen paikkaan, jonne voidaan tuoda ”mitä tahansa dataa” – eli ns. Big Data -ratkaisu?
- Onko meillä tarvetta tietojohtamisen alueella ”lähes reaaliaikaiseen” tietojen päivittämiseen?
Näitä kysymyksiä pohditaan vaihtoehtoja ja ratkaisumallia suunniteltaessa. Liiketoiminnan ja johdon vastaukset kysymyksiin ovat yleensä selvät: toki meillä on kaikenlaista dataa (asiakirjoja, ääntä, kuvaa, numeerista dataa jne.) ja toki nykyisessä hektisessä ja nopeasti muuttuvassa toimintaympäristössä tarvitsemme mahdollisimman ajantasaista tietoa.
a) Päätöksenteon perusteet
Näiden kahden tarpeen pohjalta rakennettava IT-ratkaisu on kokemuksemme mukaan kuitenkin kallein, monimutkaisin ja hitain toteuttaa, ja pettää monesti johdolle ja liiketoiminnalle annetut lupaukset.
Tämän vuoksi päätöksentekoprosessiin pitää tuoda ”ihannetarpeen toteuttamisen” rinnalle myös vaihtoehtoisia toteutustapoja hintalappuineen.
Johdon päätös voi olla toisenlainen, mikäli tietojohtamisen tarpeisiin riittääkin 80 prosenttisesti esimerkiksi viikkotasolla päivittyvä tavanomainen relaatiokantapohjainen tietovarasto, joka tuo myös 80 prosenttia pienemmät kustannukset ja ehkä 80 prosenttia nopeamman toteutuksen.
Mikäli sekä rakenteisen datan että ei-rakenteisen datan vieminen samaan tietojen keräyspaikkaan ei olekaan välttämätöntä, voidaan johdolle esittää hyvin erilainen business case.
Mikäli puolestaan eri vaihtoehtojen arvioinnin myötä todetaan selkeä liiketoimintatarve viedä kaikenlainen data mahdollisimman reaaliaikaisesti yhteen paikkaan jatkokäsittelyä varten, ovat Data platform- ja tietovarastoratkaisujen State-of-the-art -mallit hyvinkin toimivia.
b) IT-järjestelmäarkkitehtuurin hallinta
Tässä yhteydessä me IT-ammattilaiset voimme soveltaa meille tuttua käsitemallinnusta omaan työhömme: mitä meidän organisaatiossamme tarkoittavat ”data” ja ”tietojohtaminen”.
Nämä käsitteet nimittäin ymmärretään johdossa ja liiketoiminnassa hyvin monella eri tavalla. Mistä ollaan varsinaisesti päättämässä ja mihin tarpeeseen? Mitkä ovat meidän eri IT-järjestelmiemme mahdollisuudet hoitaa erilaisia tietotarpeita?
Seuraavat kysymykset auttavat fiksuimman IT-ratkaisun suunnittelussa:
- Mitä tietoja käyttäjät välttämättä tarvitsevat lähes reaaliaikaisesti?
- Mitä tietoja käytetään tiedolla johtamisessa eri organisaatiotasoilla?
- Mikä on meidän oman organisaatiomme kyky toteuttaa erilaisia IT-ratkaisuja?
Kaikkea ei kannata edes yrittää rakentaa tietovaraston varaan ja tietovarastoinnin keinoin. Monet tietotarpeet ratkeavat seuraavilla tavoilla:
- Reaaliaikaiset tietotarpeet (ml. tiedolla johtamisen tarpeet) toteutetaan ensisijaisesti sinne missä on myös ajantasainen tieto: operatiivisiin tietojärjestelmiin.
- Reaaliaikaiset tietotarpeet, joissa on yhdisteltävä useamman operatiivisen tietojärjestelmän datoja toteutetaan erillisenä ”tietokantasovelluksena”, jossa voidaan tarvittaessa käyttää ja hyödyntää myös samoja ETL-toteutuksia kuin tietovarastoinnissa (ns. ODS-ratkaisu, Operational Data Store).
- Analyyttisen tiedon käsittelytarpeita varten on käsitemallinnettu tietovarasto ja sen ”raakadatakerros”.
- Ne tiedolla johtamisen tarpeet, joissa ei ole tarvetta reaaliaikaiselle tiedolle ja joissa yhdistellään useamman operatiivisen tietojärjestelmän (tai tietolähteen) datoja, hoidetaan tietovarastoinnilla, jossa on eri tiedolla johtamisen tarpeisiin tuotettuja ”infonäkymiä” kuten tähtimalleja, leveitä tauluja tai kolmannen normaalimuodon mukaisia näkymiä.
Olemme myös huomanneet, että usein langetaan niin sanottuun käyttäjäansaan tavoitellun helppokäyttöisyyden vuoksi, esimerkiksi johdolle rakennetaan tietovarastoinnin päälle raportointia, joka olisi suoraan saatavissa operatiivisesta tietojärjestelmästä. ”Helppous” saattaa tulla kalliiksi.
c) Tietoputken osaamisen hallinta
Mitä pidempi ”tietoputkesta” tulee, sitä monimutkaisempi se on ja sitä enemmän tietoputken eri tekniset vaiheet edellyttävät IT-työn erityisasiantuntemusta.
Monessa organisaatiossa ovat erikseen lähdejärjestelmäintegraatio-osaajat, tietoallas-hallintaosaajat, tietovaraston Data Vault -toteutuksen osaajat, tietovaraston hyödyntämiskerroksen toteutusosaajat ja raporttikehittäjät.
Pahimmillaan viisi eri ammattiryhmää tulkitsee ja käsittelee samaa dataa eri vaiheissa, jolloin kokonaisuuden ymmärtäminen hämärtyy ja vastuu pilkkoutuu siiloihin.
Tietoputken eri vaiheet ja monimutkaisuus saattavat johtaa toimittajalukkoon. Mitä monimutkaisempia osia tietoputkessa on, sitä syvempää erityisosaamista yksityiskohdat vaativat. Ja mitä enemmän erityisosaamista vaaditaan, sitä todennäköisemmin tarvitaan toimittajia.
Tietovarastoinnin tärkein tavoite on saada organisaation tietopääoma sen omiin käsiin, jotta tietoihin päästään käsiksi organisaation kaikilla tasoilla. Tähän tavoitteeseen toimittajalukko sopii huonosti.
3. Tarvelähtöisen tietopohjan rakentaminen nopeasti ja ketterästi
Vaikka tietovaraston osia ja sen varaan toteutettavia tietotuotteita ja -palveluita saadaan käyttöön, ei tietovarastoinnin ole tarkoituskaan ”tulla täydellisesti valmiiksi”.
Kyse on organisaation tiedonhallintaprosessista, jossa tietovarastointi muotoutuu ja laajenee osana organisaation tiedonhallinnan kulttuurin ja maturiteetin kehittymistä.
Meillä on kokemusta sekä onnistuneista että epäonnistuneista tietovarastointihankkeista.
Näiden kokemusten myötä meille on syntynyt näkemys siitä, miten onnistunut tietovarasto (tietopohja) rakennetaan. Avaintekijöitä ovat liiketoimintavetoisuus ja tarvelähtöisyys, tietovaraston ottaminen nopeasti hyötykäyttöön sekä sen vaiheittainen ja ketterä kehittäminen.
Seuraavassa käsittelemme tällaisen toteutusmallin menestystekijöitä.
a) Toimittajan rooli on ratkaisevaa lähdejärjestelmän tietorakenteiden osaamisessa
Organisaation data on sen keskeistä tietopääomaa, jonka osaamista ja hallintaa ei ole syytä ulkoistaa toimittajalle tai jättää sitä vain toimittajan haltuun. Jos näin käy, kadotetaan koko tietovarastoinnin ydintavoite tuoda tiedot järjestelmistä organisaation omiin käsiin ja hyödynnettäviksi.
Toimittajan tärkein rooli tietovarastoinnissa on lähdejärjestelmän tietorakenteiden osaaminen. Kun lähdejärjestelmätoimittajalta tilataan datat asiakasorganisaation itse käsitemallintamassa muodossa, säästetään paljon aikaa ja vaivaa.
Tällöin tietoputken ensimmäisen tiedon muotoiluvaiheen tekee se taho, joka sen parhaiten tuntee ja osaa. Asiakasorganisaation tehtävä on luoda käsitemalli, jonka mukaisena tietorakenteena toimittaja integraationsa toteuttaa.
Toimittajalla ei kuitenkaan ole välttämättä intressiä lähteä muotoilemaan integraation sisältöä asiakkaan mallin mukaiseksi, ellei tätä vaihetta ole neuvoteltu selväksi jo järjestelmän hankintavaiheessa, jolloin järjestelmätoimittaja kyllä kuuntelee asiakkaan toiveita.
Mikäli hankinta on jo tehty, tulee työlle enemmän kustannuksia, mutta tämä on rahan laittamista oikeaan kohteeseen. Mikäli järjestelmätoimittajalta on työtä vaikea saada, voi tällaisen käsitemallin mukaisen intregraatiotyön tilata myös järjestelmän (esim. ERP) osaavalta konsulttiyhtiöltä.
Käsitemallin mukaisella integraatiolla tuodaan tietovarastoon ”kaikki rivit”. Näin varmistetaan, että tietovarasto pystyy vastaamaan yksityiskohtaisimpiinkin tietotarpeisiin ja myös, että järjestelmän tiedot on yhdisteltävissä muihin tietolähteisiin ja ydintietoihin (master data).
Tietovaraston toteuttajien on helppo jatkaa tiedon muotoilua ja jalostusta ymmärrettävän ja mallinnetun tietorakenteen pohjalta. Vaihtoehtona tälle on tilanne, jossa tietovaraston toteuttajat yrittäisivät ymmärtää lähdejärjestelmän tietorakenteita, joita ei ole tehty tiedon hyödyntämistä varten, vaan sujuvoittamaan järjestelmän operatiivisen käyttöä.
b) Liiketoiminta on saatava kehitystyön ohjaksiin
Kun tietoputken ensimmäinen vaihe – integraatio – on saatu sen parhaiten tuntevan tahon käsiin, on seuraavana vuorossa tiedon muotoilu ja jalostus kohti tiedon hyödyntämistä, johon liittyvät tarpeet liiketoiminta yleensä tuntee parhaiten.
Tämä vaihe on yleensä hankalin, sillä tietovarastointia pidetään pääsääntöisesti ”IT-hankkeena”, joka on ”IT:n asia”, vaikka oikeasti kysymys on liiketoiminnan kehittämishankkeesta datan avulla,
Liiketoiminnan on otettava omistajuus omista datoistaan. Se ei kuitenkaan yleensä onnistu ”IT:n määräyksellä tai työnnöllä” (esimerkiksi IT:n vetämällä Data Governance -työllä), vaan IT:n on onnistuttava perustelemaan liiketoiminnalle omistajuuden ottamisen merkitys sekä sen liiketoiminnalta vaatima työ.
Vaaditaan, että IT osaa puhutella liiketoimintaa ja puhua sen kieltä, kääntää IT-asiat liiketoiminta-asioiksi.
Kun tämä on onnistunut ja liiketoiminnasta on löytynyt henkilöitä omistajan rooleihin, on huolehdittava siitä, että näillä henkilöillä on suoraan tai välillisesti mahdollisuus vaikuttaa operatiivisten järjestelmien käyttötapoihin ja kirjausten ohjeistuksiin.
Tiedon omistajuuteen liittyy nimittäin aina tiedon laatu, joka puolestaan pohjautuu tiedon lähdejärjestelmien sisältöön. ”Rubbish in, rubbish out” on meille kaikille tietovarastoinnin asiantuntijoille tuttua, mutta ei välttämättä tiedon käyttäjille.
Liiketoiminnan saaminen tietovarastointihankkeen tosiasiallisiin ohjaksiin vaatii muutoksen johtamista ja varmistaa sen, että liiketoiminnan tarpeet ovat kaiken toiminnan lähtökohtana ja että laadunhallinnan prosessit varmistavat tiedon käyttökelpoisuuden.
c) Uusvanha innovaatio tuo pragmaattisuutta tietovarastointiin – ja dataosaamisen omaan organisaatioon
Toteutusketjusta puuttuu enää itse tietovarastoinnin toteutus. Edellä kuvatuilla menettelyillä tietovarastodevaajan työ on jo helpottunut ratkaisevasti seuraavista syistä:
- Lähtödatat ovat sisällöltään organisaation itse kuvaamia sekä teknisesti ymmärrettävässä muodossa (todennäköisimmin jo kolmannen normaalimuodon mukaisessa).
- Liiketoiminnassa on henkilöitä, jotka haluavat ja pystyvät ohjaamaan toteutusta tarvelähtöisesti, hallitsevat niin substanssin kuin lähdejärjestelmien käytön tavat aina tiedon syöttämisen ohjeistuksiin.
Nyt tietovarastodevaaja voi keskittyä itse tietovaraston rakenteen toteuttamiseen ja tiedon jalostamiseen. Hänellä on ”molemmissa päissä” asiantuntijaosaaminen käytettävissään ja tukenaan. Toteutustyö voi mennä jopa ensimmäisellä kierroksella oikein, jolloin ei tarvita aikaa ja rahaa nieleviä iterointikierroksia.
Samalla saadaan pragmaattisuutta itse tietovaraston toteutustapaan. Kysymys kuuluu, onko meillä tarvetta käyttää muita kuin jo pitkään koeteltuja ja yleisesti osattuja toteutusmalleja: relaatiotietokantaa, kolmatta normaalimuotoa ja SQL:ää sekä yhtä lailla näkymiä tarpeeseen ja leveitä tauluja materialisoituna suuriin kyselytarpeisiin. Kaikkia näitä vaiheita ohjattuina käsitemallinnuksen keinoin suunnittelusta toteutukseen.
Näillä tutuilla resepteillä tietovarastointia on tehty pitkään. Näkemyksemme mukaan tämä on mahdollista, mikäli artikkelimme ensimmäinen näkökulma (Tietojohtamisen tarpeita tukevien IT-ratkaisujen päätöksenteko) on sisäistetty ja oivallettu, että tietovarastoinnin ei ole tarve eikä tarkoitus ratkaista kaikkia tietotarpeita, eikä reaaliaikaisimman ja laajimman oletetun tietotarpeen anneta ohjata koko tietoputken toteutusmallia.
Olemme Hovin tiimissä pohtineet pragmaattista toteutusvaihtoehtoa jo pitkään, kun olemme vuosien varrella nähneet ja kokeneet State-of-the-art tietovarasto- ja data platform -toteutusten haasteet.
Olemme kehittäneet mallia, jossa tällaiseen perinteiseen tietovarastoinnin toteutusmalliin otetaan vielä mukaan Data Vault -metodologian ”parhaat palat”.
Uskomme, että tietovarastointi kehittyy edellä kuvattuun, nykyistä pragmaattisempaan suuntaan, kun sitä johdetaan ja ohjataan liiketoiminnasta käsin ja samalla kyetään ymmärtämään kaikki tietoputkeen liittyvät päätökset ja tietotyön luonne.
Tällainen uusvanha tietovarastointi hyödyntää tietoteknisiä ratkaisuja, joita osaa moni IT-ammattilainen. IT-osaajia on helpompi löytää kuin kompleksisiin State-of-the-art -toteutuksiin. Tämä mahdollistaa helpomman osaamisen järjestämisen omaan organisaatioon, jolloin dataosaaminen syntyy itselle eikä toimittajalla. Samalla vältetään toimittajalukko.
Uudenlaisesta kehityksestä on jo olemassa kannustavia käytännön esimerkkejä. Lopuksi kerromme yhdestä ja annamme neuvoja päätöksentekijöille.
4. Case finanssimaailmasta onnistuneesta päätöksenteosta ja tietovarastoinnista
Eräs finanssikonserni oli rakentanut toimivan tietovaraston perinteisen kolmannen normaalimuodon mukaisella tietomallilla. Yhtiö oli aloittanut toteutuksen sen keskeisemmästä osasta: yritysasiakkaiden asiakaskokonaisuuksien, vakuuksien ja luottojen hallinnasta.
Yhtiö oli liiketoiminnan johdolla mallintanut tämän alueen. Ylätason käsitemallissa oli kymmenkunta käsitettä, ja myös tietovarastototeutusta varten astetta syvemmälle suunnitellussa käsitemallissa oli noin kaksikymmentä ydintieto-, tapahtumatieto- ja sopimustietotyyppistä käsitettä yhteyksineen.
Yhtiö oli tilannut tämän käsitemallin mukaisessa rakenteessa tiedonsiirron IT-palveluyhtiöltä, jossa se oli tehty noin kuukaudessa liiketoiminnan asiantuntijoiden antaman käsitemallitarkennuksen tukemana. Tiedonsiirto toteutettiin jo valmiiksi ER-mallisena, joten tietovaraston pohja saatiin hyvin nopeasti käyttöön. Tietovarastossa oli jo valmiina perustiedot kuten organisaatiorakenne.
Liiketoiminta oli käsitemallinnustyön myötä ottanut käytännön omistajuutta tiedoistaan ja sieltä nousi esiin innokkaita substanssiosaajia, jotka olivat tottuneet tuottamaan tietoa Excelillä. He oppivat uuden raportointityökalun käytön nopeasti, ja koska mallinnustyön myötä datat ja datatyö olivat heille tuttuja, ensimmäisiä raportteja syntyi hyvin nopeasti ja he pystyivät tekemään monipuolisesti myös ad hoc -kyselyjä tietovarastoon.
Tietovaraston pohjan päälle rakentui tiedon jalostuskerros, jonka toteutusta ohjattiin myös mallintamisella, mikä varmisti sen, että jalostusta ei tehty vain yksittäisiä käyttötapauksia varten vaan kokonaisvaltaisesti.
Kolmen vuoden kuluttua IT-palveluntuottaja vaihtui ja samassa yhteydessä yhtiö uusi myös pankkitoimintansa perusjärjestelmät. Osana hankintaprosessia tarjouspyyntöasiakirjoissa oli kuvaus uuden järjestelmän tiedonsiirtovaateista eli tuo alkuperäinen tietovarastointia varten laadittu käsitemalli. Toimittajat suostuivat tiedonsiirtoon mielellään, koska kyse oli isosta järjestelmäkaupasta.
Niinpä pankkijärjestelmien vaihdon yhteydessä myös tietovaraston tiedonsiirto oli valmis ja 80 % kaikesta aiemmin tehdystä tietovarastoinnista ja raportoinnista toimi entisellään.
Ja mikä tärkeintä: tiedolla johtamiseen ei tullut katkoksia eikä myöskään oleellisia tietopuutteita tai virheitä.
5. Olemassa olevan tietovaraston jatkokehitys evoluutiona, ei revoluutiona
Monet organisaatiot tuskailevat liian raskaiksi rakentuneiden tietovarastojen ja data platform -ratkaisujen kanssa. Jotkut organisaatiot ovat päätyneet ratkaisemaan haasteet revoluutiona: tehdään kaikki uusiksi, käynnistetään uudistusprojekti.
Tässä artikkelissa kuvatut tietojohtamisen IT-ratkaisujen päätöksenteko- ja toteutusmallimenettelyt tukevat evoluutiona tapahtuvaa uudistamista.
Relaatiotietokanta ja SQL omaavat valtavan voiman: rakenteista tietoa pystyy käsittelemään pragmaattisesti monella eri tavalla. Esimerkiksi nykyisistä tietovarannoista voi tehdä virtuaalisia tai materialisoituja näkymiä, jotka ovat yhdisteltävissä luontevasti kolmannen normaalimuodon mukaisiin tauluihin ja muihin rakenteisiin. Tietovaraston tietolaajennukset voi tehdä uusvanhalla tavalla ja samoin järjestelmävaihdosten yhteydessä on luontevaa yhdenmukaistaa aiemmat tietovaraston rakenteet. Lopuksi uusitaan hallitusti vanha rakenne osa-alue kerrallaan – jos siihen on todellinen tarve.
Näin nykyinen tietovarasto uusiutuu osa kerrallaan, evoluutiona. Prosessi on kuin juustonpalaan reikien tekeminen, reikä kerrallaan kunnes koko juusto on hävinnyt.
Tietovaraston uudistaminen evoluutiona edellyttää tiedonhallintatyön näkemystä ja kokemusta sekä johtamiskykyä organisaation eri tasoilla. Lisäksi uudistusta tulee ohjata jatkuvalla vahvalla mallinnusvetoisella otteella, jotta syntyy eri toimijoiden yhteinen ymmärrys muutoksesta.
6. Neuvot päätöksentekijöille
a) Liiketoimintajohtaja
Pyydä vaihtoehtoisia laskelmia malleista, jotka perustuvat myös muuhun kuin tiedolla johtamisen reaaliaikaiseen tietotarpeeseen. Riittäisikö jopa tiedon viikkotason ajantasaisuus johtamisen tarpeisiinne?
Esitä kysymys, millä eri tavoin mahdolliset reaaliaikaiset tietotarpeet voi hoitaa. Selvitä, olisiko mahdolliset yksittäiset reaaliaikaiset tietotarpeesi saatavissa operatiivisesta tietojärjestelmästä, ja voit säästää paljon. Huolehdi, että sinulle avataan valittavan tietovarastoinnin toteutusmallin perusteet. Pyydä näkemys myös muiden toteutusmallien vahvuuksista ja heikkouksista, jotta voit arvioida ovatko ne relevantteja liiketoiminnan näkökulmasta.
b) IT-johtaja
Ota järjestelmähankinnoissa huomioon myös tietovarastointi, niin säästät aikaa ja rahaa, mutta ennen kaikkea autat liiketoimintaa saamaan tiedolla johtamisen tarpeensa kuntoon ripeästi. Varmista, että olihan eri tyyppisen ja tasoisen tiedon tuottamisen ja käyttämisen järjestelmäarkkitehtuurisi kirkas ja viestitty – kaikkia tietotarpeita ei ole syytä hoitaa tietovarastoinnilla.
Arvioi myös samat seikat kuin liiketoimintajohtaja ja kysy samat kysymykset omilta tietovarastointiratkaisujen asiantuntijoiltasi.
c) Projektipäällikkö
Huolehdi siitä, että edellä kuvatut keskustelut on käyty liiketoiminta- ja IT-johdossa. Uskalla myös kyseenalaistaa erityisesti reaaliaikaisen tiedolla johtamisen tarve, mikäli huomaat sen johtavan raskaisiin toteutustapoihin. Rakenna kehitystiimisi huomioiden tietoputki päästä päähän (tiedon kulku tiedon syöttäjän käsistä aina tiedon käyttäjän käsiin). Valitse tekijöiksi eri tietoputken vaiheisiin henkilö tai taho, joka sen vaiheen parhaiten osaa ja tuntee. Huolehdi, että kehitystyön myötä dataymmärrys ja -osaaminen jää aidosti oman organisaation käsiin.
Jari Ylinen
