Moderni tiedolla johtaminen ei ole pelkästään työkaluja ja raportteja. Pelkkä höylän omistaminen ei tee vielä kenestäkään puuseppää, eivätkä myöskään data-alustat ja raportoinnin työkalut yksin takaa onnea ja autuutta tiedolla johtamisessa.
Törmäämme toistuvasti asiakasyrityksissämme tilanteisiin, joissa datan hyödyntämisen välineistö on sinänsä kunnossa, mutta toiminnan niiden ympärillä todetaan olevan tavalla tai toisella hallitsematonta. Tämä voi heijastua tekemiseen ja saavutuksiin monin tavoin:
Hallintamallilla tarkoitamme tässä yhteydessä kaikkia datan ja tiedon parissa toimimiseen liittyviä rakenteita, käytäntöjä ja edellytyksiä. Malli edistää kattavaa ja tehokasta tiedon tuottamista ja hyödyntämistä niin, että tarvittavat henkilöt tiedostavat roolinsa ja kussakin tilanteessa tiedetään miten toimia.
Puhumme tarkoituksella myös tiedon hallinnasta viitaten loppukäyttäjien omaksumaan tietoon. Tyypillisesti datanhallinta (Data Governance) ottaa kantaa lähinnä lähdejärjestelmissä olevan datan omistajuuksiin, datan laatuun ja dataan liittyviin käyttöoikeuksiin. Näemme kuitenkin äärimmäisen tärkeänä hallita myös sitä, miten datasta tuotettu informaatio omaksutaan käyttäjien toimesta tiedoksi, jota voidaan hyödyntää päätöksenteossa.
Alle olen listannut teemoja, joita olemme työstäneet tiedonhallintahankkeiden yhteydessä. Seuraavaksi käyn läpi kutakin teemaa hieman tarkemmin:
Aivan ensimmäiseksi on hyvä käydä läpi roolit, joita tiedon ympärillä tarvitaan, koska ne tulevat joka tapauksessa vastaan erilaisia tilanteita ja toimenpiteitä määriteltäessä. Tyypillisesti törmäämme datalähteiden omistajiin, integraattoreihin, data-asiantuntijoihin, data scientisteihin, tietosuojavastaaviin ja erilaisiin liiketoiminnan edustajiin – ja moniin muihin.
Melko usein havaitaan, että jokin oleellinen rooli puuttuu. Esimerkiksi taannoisessa hallintamalliprojektissa nähtiin tarve datajohtajalle, joka koordinoi kaikkea dataan liittyvää tekemistä. Toisaalta havainto voi liittyä myös olemassa olevien roolien osaamisten kasvattamiseen. Esimerkiksi erään organisaation oli lisättävä asiantuntijoiden konsultatiivista osaamista tukemaan ulkoisille asiakkaille tarjottaviin tietotuotteisiin liittyvää palvelua.
Yhtä lailla yleishyödyllistä on miettiä jo alkuvaiheessa tarvittavia kommunikaation muotoja. Tapaamisfoorumit ovat yksi kommunikaation muoto, joka voi ilmentyä esimerkiksi tietotarpeiden arviointikokousten tai erilaisten koulutus- ja tiedotustilaisuuksien muodossa. Lisäksi on syytä miettiä millaisia kanavia pitkin kerätään liiketoiminnan tarpeet uudelle tiedolle tai käydään keskustelua teknisistä tai sisällöllisistä asioista.
Vaikka hallintamallin määrittäminen ei ole varsinaista arkkitehtuurin kehittämistä tai teknologiavalintojen tekemistä, ne vaikuttavat hallintamalliin. Ensinnäkin on syytä määritellä, missä, miten ja kenen toimesta päätökset arkkitehtuuriin ja teknologioihin liittyen tehdään. Onko esimerkiksi syytä olla tietty kokousfoorumi, jossa käsitellään arkkitehtuurin linjauksia tai uusien teknologioiden hankintaa ja suunnitellaan tiekarttaa eteenpäin.
Toiseksi arkkitehtuuri ja teknologiat liittyvät moniin käytännön tason hallinnollisiin asioihin. Esimerkiksi datan omistajuuteen ja hallintaan (ks. seuraava alaluku) liittyvät tehtävät ja roolit voivat riippua siitä, miten ja millaisilla välineillä data-alusta on rakennettu.
Hallintamallin ytimessä on data – sen omistajuus, mutta myös siihen liittyvät toimenpiteet. Jonkun on omistettava lähdejärjestelmissä oleva data. Oli kyseessä sitten ERP-järjestelmä, CRM-järjestelmä tai ulkopuolelta ostettavat asiakastiedot, omistaja vastaa viime kädessä datavarantojen olemassaolosta, lähteisiin tulevista muutoksista tai jopa lähteen korvaamisesta.
Omistajuus ei kuitenkaan vielä riitä. Dataan liittyvät toimenpiteet vaativat myös muita tahoja, jolloin on hyödyllistä ottaa avuksi RACI-matriisin mukaiset roolit (R = Responsible, ”Toteutusvastuullinen”; A = Accountable, ”Päätöksentekovastuullinen”; C = Consulted, ”Neuvoja”; I = Informed, ”Tiedotettava”). Kun esimerkiksi datalähteeseen liittyen tulee muutoksia, datalähteen omistaja (A) tekee päätöksen muutosten toteuttamisesta, integraattori (R) toteuttaa muutokset datalatauksiin hyödyntäen lähdejärjestelmän asiantuntijaa (C) ja informoi sisältömuutoksista datan hyödyntäjiä (I).
Samaan tapaan voidaan kuvata toimenpiteet erilaisissa tilanteissa ”dataputken” varrella. Mitä esimerkiksi tapahtuu kun ladatussa datassa havaitaan virheitä, tietovarastossa tapahtuvaan mallinnukseen tarvitaan muutoksia tai raportille halutaan uusi mittari?
Tuotettavan tiedon pitää perustua liiketoiminnan tarpeisiin, ja ne luonnollisesti kehittyvät ajan myötä. Uutta tietoa voidaan tuottaa organisaatiosta riippuen monin tavoin: keskitetysti IT:ltä tilaamalla tai hajautetusti itsepalveluna.
Jotta rönsyilyä ja tehottomuutta tiedontuotannossa vältettäisiin, uuden tiedon tuottamisen on syytä olla systemaattista. Näkemyksemme mukaan tämä tarkoittaa, että on oltava prosessi, jonka mukaisesti tietotarpeet kerätään ja arvioidaan. Tämän prosessin määritteleminen on tietotarpeiden keruun ja arvioinnin ensimmäinen toimenpide.
Prosessin varrella tarvitaan tapa kuvata ja kerätä tarpeita. Tähän muodostetaan yleensä lomake tai muu tapa kuvata tarve ja siitä saatavat hyödyt. Samalla päätetään lomakkeen välittämisen kanava – esimerkiksi tiketöintijärjestelmä tai sähköposti. Tarpeiden arviointi vaatii yleensä yhteistyötä, ja usein sitä varten perustetaankin kokousfoorumi. Foorumi arvioi tarpeet sekä niiden toteuttamisen edellytykset ja vaadittavat panostukset. Tuloksena syntyy toteutuskelpoisten tarpeiden priorisointi.
Kun tarve on päätetty täyttää, se on toteutettava – ja mielellään suunnitelmallisesti ja systemaattisesti, ei puuhastellen. Siksi on oltava tavat päättää projektien priorisoinnista ja aikataulutuksesta sekä omien resurssien käytöstä tai ulkopuolisten toimittajien hyödyntämisestä. Samoin projektimallit ja projektien käytännöt ohjausryhmistä riskiarviointeihin ja dokumentointiin on hyvä määritellä yhtenäisesti.
Testauksen tehtävänä on varmistaa, että toteutuksesta saadaan haluttu lopputulos. Testauksen hallinnollisesta näkökulmasta on tärkeää määritellä testauksen kulku vaiheineen sekä vaiheista vastaavat tahot. Esimerkkejä hyvistä käytännöistä ovat esimerkiksi testaussuunnitelma sekä testauspöytäkirja, johon havainnot kirjataan. Myös teknisestä näkökulmasta on määriteltävä periaatteet kehitys-, testaus- ja tuotantoympäristöjen hyödyntämiseen ja esimerkiksi DevOps-tyyppisten työkalujen käyttö.
Dokumentointi on lähes poikkeuksetta laiminlyöty alue organisaatioiden tiedonhallinnassa. Se on kuitenkin organisaation muisti, johon voidaan turvautua, vaikka henkilöt vaihtuisivatkin.
Tiedonhallintaan voi liittyä monenlaista dokumentaatiota. Yksi keskeisimmistä hallintamallien yhteydessä nykyään vastaantulevista ilmentymistä on datakatalogit. Parhaimmillaan datakatalogiin dokumentoidaan käytettävissä oleva data alustan eri kerroksissa, mutta kyetään myös visualisoimaan tietovirtaa arkkitehtuurin eri kerrosten läpi lähteiltä raportin mittareihin asti.
Toinen keskeinen dokumentaation muoto koskee raportteja. Dokumentaatiota voidaan tehdä raporttien yhteyteen infosivuille tai erillisenä Wiki-tyyppisenä dokumentaationa. Pääasia on, että käyttäjä pystyy mahdollisimman helposti käyttämään raporttia itsenäisesti. Dokumentaatioon on hyvä kehittää yhtenäiset käytännöt, esimerkiksi standardoitu dokumentointipohja, jotta tiedon hakeminen on käyttäjille sujuvaa.
Tiedon hyödyntäminen nykyaikaisilla raportointivälineillä on yleensä hyvin intuitiivista. Siitä huolimatta on syytä varautua tarjoamaan raportoinnin käyttämiseen koulutuksia ja neuvontaa. Niissä voidaan käsitellä sekä teknisiä asioita (”miten poraudun tietoon”) että sisällöllisiä asioita (”miten markkinoinnin konversio on laskettu”). Siinä missä koulutuksia tarjotaan useimmiten keskitetysti, henkilökohtaista neuvontavastuuta voidaan helpommin hajauttaa esimerkiksi liiketoimintayksiköiden ”super usereille”.
Toki koulutuksia ja neuvontaa on hyvä tarjota myös muista kuin raportoinnin näkökulmista. Tietosuoja ja tietoturva ovat kriittisiä jokaiselle organisaatiolle, mutta yhä useampi ottaa kantaa myös tiedon eettiseen hyödyntämiseen. Myös tekninen neuvonta siitä, mitä tapahtuu ”konepellin alla”, voi olla toisinaan tärkeää. Hallintamallin osana on määriteltävä miten ja kenen toimesta koulutuksia ja neuvontaa tarjotaan.
Tietosuoja ja tietoturva ovat laajoja aiheita. Hallintamalli ei ota kantaa esimerkiksi yksittäisten aineistojen salaamiseen, vaan ylätason periaatteisiin ja roolitukseen. On syytä käydä läpi, ketkä organisaatiossa vastaavat tietosuojasta ja tietoturvasta ja miten heiltä saadaan tukea käytännön toimintaan. Koulutusten tarve todettiinkin jo edellä, ja ne ovat oleellisia sekä uuden työntekijän perehdyttämisessä että myös olemassa olevalle henkilöstölle uusien säädösten tai käytäntöjen ilmetessä.
Käytännön tasolla tietosuojaa voidaan hallintamallissa käydä läpi samaan tapaan kuin datan hallintaa yleisestikin. Miten minun pitää esimerkiksi ottaa tietosuoja huomioon kehittäessäni uutta raporttia tai hyödyntäessäni raportin tietoja? Erityisen tärkeää on tunnistaa tilanteet, jotka vaativat erityisen riski- tai vaikutusarvioinnin tekemistä.
Hallintamalli on laaja kokonaisuus ja siksi sitä voi olla järkevää lähestyä paloissa. Jotta tunnistetaan keskeisimmät kehityskohteet, on tärkeää tunnistaa toiminnan nykytila ja sen ongelmakohdat. Aloitamme usein hallintamallityön sidosryhmähaastatteluilla. Tiedon hyödyntäjät ovat oleellisin lähde sen ymmärtämiseen, mikä uuden tiedon kehittämisessä tai nykyisten tietovarantojen hyödyntämisessä toimii tai ei toimi.
Haastattelukierroksen jälkeen varsinainen hallintamallin työstäminen sujuu tehokkaimmin tiiviin ydinryhmän työpajatyöskentelynä. tarvittaessa voidaan hyödyntää pistemäisesti eri alojen asiantuntijoita. Työpajat kannattaa jäsentää yllä mainittujen teemojen ympärille. Teemat vaativat tyypillisesti iterointia ja niihin on syytä varata riittävästi aikaa.
Hyvin oleellinen osa hallintamallin määrittelyä on tiekartan muodostaminen eteenpäin. Määrittelyprojektista kumpuaa kymmeniä toimenpiteitä, joiden avulla malli on tarkoitus saada käytäntöön. Nämä tarkoittavat ennen kaikkea tiedottamista ja jalkautusta, mutta mahdollisesti myös lomakepohjien muodostamista, työkalujen arviointia ja käyttöönottoa ja muuta teknisempää työtä. Toimenpiteet on priorisoitava, aikataulutettava ja vastuutettava, jotta varmistutaan niiden eteenpäin viennistä järkevässä järjestyksessä.
Kaikkein tärkeintä hallintamallityössä on kuitenkin jalkauttaminen. Malli toimii vain, jos sen ympärillä toimivat ihmiset toimivat mallin mukaisesti. Alussa tehtävä haastattelukierros edistää sitoutumista hallintamalliin, mutta sille on myös syytä saada hyväksyntä määrittelytyön jälkeen. Hyväksynnän jälkeen tiedottaminen ja opastus auttavat omaksumaan mallin käytännössä. On oltava myös valmis muokkaamaan hallintamallia soveltuvin osin, mikäli sen käyttöönotossa ilmenee haasteita.
Lue lisää:
CASE OULUN YLIOPISTO - Toimiva tiedonhallintamalli luodaan yhteistyöllä ja ammattiaisella fasilitoinnilla
Klikkaa asiakastarinaan tästä >
CASE TRAFI - BI-palvelun toimintamallin sekä arkkitehtuurin suunnittelu ja pilotointi
Klikkaa asiakastarinaan tästä >