Datatuote, maistellaanpa sanaa hetki … mmm…. sehän on jotain datasta valmistettua, ehkä jokin kokonaisuus, voisiko sen ostaa vaikka kaupan hyllyltä valmiiksi.
Koska nyt on elokuu ja metsässä näkee sen, niin lähdetäänpä ensin marjametsään poimimaan ämpärillinen mustikoita, jos vaikka niistä leipoisi makoisan piirakan. (tavoitekuva ohessa). Marjaretken jälkeen huomaan, että leipominen ei onnistu suoraan poimituista marjoista, vaan ne on ensin perattava. Montakohan hämähäkkiä ja muuta mielenkiintoista kulkikaan ämpärin mukana kotiin. Onneksi meillä on tuollainen puoliautomaattinen imuriin liitettävä “marjaputsari”, jolla työ hoituu helpommin näin iltahämärissä. Eli ehkä jo huomenna tästä sen piirakan voisi leipoa, kun vielä varmistan, että kaikki muut reseptiin liittyvät ainekset ovat olemassa kuten myös hyvä resepti.
Kuulostaako tutulle? Mustikkapiirakan leivontaprosessi toimii myös vertauskuvana datan jalostamisesta informaatioksi ja siitä ymmärryksen luomiseksi. Olen tätä vertauskuvaa käyttänyt jo jokusen vuoden ja myös leiponut mustikkapiirakkaa Sytyke- lehdessäkin. Tämä prosessi ei ole muuttunut mihinkään, mutta kollegani Essi Halosen kanssa mallia pyöritettäessä, hän tunnisti tarpeen sille, että meillähän pitää olla kuvassa mukana myös resepti. Näin vertauskuva muuttui vielä paremmaksi, koska siihen saatiin mukaan näkökulma tiedon ja tiedolla johtamisen tarpeisiin. Viime aikoina datamaailmaan on putkahtanut uusi hypesana datatuote, jota myös sopii verrata mustikkapiirakkaan. Siis leivotaan taas piirakkaa ja nyt panostetaan siihen, että lopputulos on täydellinen kilpailukykyä edistävä datatuote.
Datatuote mikä se on ja miksi näitä tarvitaan
Organisaatioiden tavoite johtaa tiedolla on kasvanut, koska pelkällä tuotantoprosessilla ei vastata enää kilpailukyvyn parantamiseen. Samanaikaisesti tietoa (dataa) saadaan helpommin ja myös monimuotoisemmin kuin aikaisemmin. Pitäisi siis olla mahdollisuuksiakin enemmän siihen, miten ja mitä tietoa johtamisessa käytetään. Tiedolla johtaminen vaatii ennen kaikkea ymmärrystä tiedoista. Kaksi tärkeintä kysymystä, jotka yleisesti tehdään ovat: “mistä saan tarvitsemani tiedot ja mihin tietoon voin luottaa?” Jos meillä ei ole näkemystä siitä mitä tietoa meillä organisaatiossa on, niin miten voimme ohjata organisaation toimintaa näillä.
Tuotteistamalla tietoprosessia datatuotteiksi saadaan parannettua hyödynnettävän tiedon hallittavuutta. Datatuote on siis se tuote, jota tiedolla johtamisessa hyödynnetään ja sen muodostuksessa tarvitaan tiedon johtamisen kyvykkyyksiä. Pureudun tässä tarinassa siihen, miten datatuote muodostuu eli tiedon johtamisen näkökulmaan.
Aloitetaan siitä perusasiasta, että liiketoimintaa on tarpeen ymmärtää sekä katsoen taaksepäin että ennustaen eteenpäin. Tässähän ei vielä ole mitään uutta, koska aina on ollut tarve arvioida toimintaa ja mahdollisuuksien mukaan tätä on tehty tiedon avulla. Kilpailukykyä parantaaksemme kuitenkin tulisi katsoa siis myös eteenpäin. Esimerkiksi organisaation tärkeä prosessi budjetointi vaatii näkemystä siitä, mitä tulevaisuudessa tapahtuu ja miten tulevaisuutta ennakoidaan. Esimerkiksi Sote-alueella tulee ennustaa tulevan vuoden osalta, millaista hoitoa tullaan tarvitsemaan ja miten hoito saadaan kustannustehokkaasti järjestymään. Kun muistellaan ensimmäisen koronavuoden aikaa, niin kukaan ei ollut voinut ennakoida tätä valmiiksi. Kaikki ennakoidut budjetit menivät parissa viikossa uusiksi ja oli tehtävä nopeita päätöksiä vakavan tilanteen ratkaisemiseksi. Kaikki tämä vaatii tietoa ja kun puhutaan tiedoista, niin tulee ymmärtää mitä tietoa vaatimusten toteuttamiseen tarvitaan. Tietoa tarvitaan oikeaan aikaan ja hyvälaatuisena.
Tiedon saatavuuteen ja hallittavuuteen liittyy vahvasti näkökulma, että tiedolla pitää olla myös omistaja. Kuka on tuotteen omistaja? Hän, joka tuottaa tietoa, vai hän, joka tarvitsee tietoa. Tästä on datatuotteiden osalta eri käytäntöjä, koska organisaatiorakenne ja johtamismalli saattavat asettaa omia vaatimuksiaan. Joka tapauksessa tuotteen omistajan tulee ymmärtää omat tietonsa. Kuten mustikkapiirakan leipojan pitää osata hyödyntää reseptiä oikein.
Useat eri viranomaisvaatimukset asettavat myös tavoitteita ja määräyksiä siihen, miten tietoja tulisi käsitellä. Esimerkiksi vastuullisuusraportointi ja tietosuoja molemmat käyttävät osittain samoja mutta myös osittain eri tietoja. On siis tärkeää ymmärtää, mitä tietoja molemmissa tarvitaan ja miten näitä tietoja hallitaan. Yhteisten tietojen on pysyttävä muuttumattomia, jottei tule ristiriitoja raportointien välille.
Perinteisesti itse raportointi tai tietovaraston kautta tehtävä raportointi on ollut taso, jossa tiedot on yhdistetty ja harmonisoitu yhdenmukaiseksi. Datatuoteajattelussa on paljon vastaavaa prosessimaisuutta kuin tietovarastoinnissa. Kuitenkin siinä on entistä hajautetumpi arkkitehtuuri itse tuotteiden toteutuksen osalta, koska nämä on tuotu lähemmäs sitä liiketoimintaa, joka on vastuussa kyseisestä tietosisällöstä.
Aikaisemmin tietovarasto oli usein oma erillinen yksikkönsä, jonne kerättiin kaikki tiedot eri organisaatio-osista. Tällaisen rakennelman omistajuuden määrittely ei ole aivan helppo tehtävä. Joskus heitettiin ilmaan ajatus, että tietovaraston omistaja voisi olla varatoimitusjohtaja, koska toimitusjohtajalla on muutakin työtä. Koska datatuotteet ovat selkeästi pienempiä liiketoimintaan sidottuja kokonaisuuksia, löytyy näiden omistajakin siitä organisaatiosta, joka on vastuussa kyseisen datan tuottamisesta. Syntyy hajautettu omistajuusrakenne, jossa haasteeksi muodostuvat ne tiedot, joita tuotetaan useassa organisaatio-osassa. Kenellä silloin on vastuu? Näille tiedoille omistajuus voidaan muodostaa myös työryhmänä, jossa on edustaja kustakin alueesta, kuitenkin niin, että jollekulle nimetään päävastuu. Usein nämä datatuotteet ovat master dataan liittyviä. Toinen vaihtoehto on, että harmonisoidaan datatuotteiden muodostus, kuten tietovarastossa tehtiin ja tuotteet jaellaan hyödynnettäväksi vain yhdestä data-alustasta. Datatuotteiden osalta teknisesti puhutaan siis yleensä data-alustoista, jonne tuotteet muodostetaan.
Datatuotteita muodostettaessa on määritettävä datatuotteen rakenne ja tämän määrityksen tekijän tulee olla liiketoimintaa ymmärtävä henkilö. Miksi tämä lause kuulostaa niin tutulle? Aivan: myös käsitemallinnuksessa käytetään tuota sanoitusta. Datatuotteita määritellessä aloitetaankin kuvaamalla käsitteet. Itse datatuote saattaa sisältää useita käsitteitä, joista osa on yhteisiä muidenkin organisaatio-osien kanssa. Jos taas muistetaan, miten perinteistä tietovaraston käsitemallia kuvatiiin kokoamalla koko organisaation käsitteet samaan kuvaan, poikkeaa datatuotteiden malli tästä. Vaikka yhteisiä käsitteitä löytyisikin, kuvataan datatuotteen osalta vain ne käsitteet, jotka suoraan liittyvät tähän. Etuna tässä on, että saadaan hallittava kokonaisuus, mutta haasteeksi jää yhteisten käsitteiden mahdollinen eri merkitys organisaation eri osissa. Sillä on myös merkitystä, mille tarkkuustasolle käsitteet kuvataan. Riittääkö esim. käsitevakuutus, jos sillä tarkoitetaan vakuutussopimusta. Ei riitä, koska vakuutus voi toisessa organisaatio-osassa tarkoittaa vaikka vakuutustuotetta. Käsitteet tarkennetaan myös kuvaamalla näiden tietosisältö ns. attribuutit, jotta saadaan lihaa luiden ympärille. Jotta tämä työ voidaan tehdä hallitusti, on olemassa teknisiä toteutuksia kuten datakatalogeja, jonne datatuotteiden vastuuhenkilöt kuvaavat tiedot ja joista myös hyödyntäjät pääsevät hakemaan tietojen määritykset. Datakatalogi muodostaa siis paikan, josta helposti näkee, mitä tietoa on ja mistä sen saa käyttöön.
Mitaliarkkitehtuuri rakenteellistaa datatuotteita
Datatuotteissa on myös sellainen ominaisuus, että niitä voidaan tuottaa ns. eritasoisista tiedoista. Joissain datatuotearkkitehtuureissa on tästä eri tasoisten tietoalueiden jäsentelystä käytössä mallina mitaliarkkitehtuuri: pronssi-, hopea- ja kultakerrokset, joissa on omat sääntönsä tietojen rakenteelle. Tätä mallia voidaan myös jatkaa esim. platinakerrokseen eli tiedon jakeluun, kuten Goforen omassa mallissa on tehty. Käytän arkkitehtuurin esittelyssä esimerkkinä HR-tietojen tietoaluetta, koska se on usein itsenäinen tietoalue.
Pronssikerros on tietotaso, jossa kaikki tiedot ovat hyvin pitkälti sen muotoisina kuin ne tietojen tuottajalta saadaan. Tässä kerroksessa tiedot ovat pääsääntöisesti rajapintatiedostoissa tai sanomamuotoisina, mutta kuitenkin jo laatutarkistettuina ja mahdollisesti myös historioituina. Näitä tietoja hyödyntävät usein analyytikot ja myös tekoälyratkaisut. Tietoa ei vielä ole harmonisoitu ja jalostettu yhdenmukaisen tietomallin mukaan. HR-tietojen osalta on saatu mm. tuntikirjaus ja palkkahallinnon tiedot rajapinnan kautta alkuperäisten lähdetietojen näköisenä. Mahdollisesti myös samoihin käsitteisiin liittyviä tietoja saadaan eri lähteistä.
Hopeakerros on ns. harmonisointikerros. Tähän kerrokseen tarvitaan koko tietoalueen yhteinen tietomalli sekä käsitteellisellä, loogisella että fyysisellä tasolla. Liiketoiminnan tulee olla vahvasti mukana määrittämässä tietomallin sisältöä, koska ilman tätä hopeakerros ei tuota lisäarvoa. Tarvitaan siis omistajuus ja käsitys siitä, mitä tietoja hyödyntäjät tulevat tarvitsemaan raportoinnissa ja muissa liiketoimintatarpeissaan. Hopeakerroksesta ei jaeta tietoa hyödyntäjille. Esimerkin HR-datan osalta hopeakerrokseen tuodaan yhdenmukaiseen malliin sekä edellä mainitut palkkahallinnon ja tuntikirjausten tiedot. Tämän lisäksi tarvitaan tietomalliin mukaan organisaation henkilö ja työsuhde sekä mahdollisesti myös tarkempi organisaatiohierarkia.
Hopeakerroksen tietoja harvoin hyödynnetään suoraan, vaan tarvitaan hyödyntäjää paremmin palveleva kultakerros. Kultakerros rakentuukin lopullisista datatuotteista. Tietosisältö jäsennellään siihen muotoon, millaisia tarpeita hyödyntäjillä on. Kultakerrokseen voidaan muodostaa fakta-dimensio-malleja, ns. leveitä tauluja analyytikkojen käyttöön sekä ihan perinteisiä relaatiotauluja. Välttämättä kaikki tietosisältö ei ole rakenteellisessa muodossa, niin myös sanomarakenteita ja muita tiedostomuotoja voidaan muodostaa. Kultakerros vastaa siis liiketoiminnan tarpeisiin erilaisten mittarien ja näitä tukevien tietojen avulla. HR-tietojen osalta kultakerroksessa muodostetaan HR-raportoinnin vaatimusten mukaiset tietorakenteet.
Aikaisemmin kerroksia esitellessäni mainitsin myös, että jalometalliarkkitehtuuria voidaan jatkaa eteenpäin, esimerkiksi platinakerrokseen, joka on tietojen jakelukerros. Tässä kerroksessa punnitaan lopullisesti se, kuinka hyvin tuotetut datatuotteet palvelevat liiketoiminnan tarpeita. Jakelutapoja voivat olla fyysiset raportointiportaalit ja API-ratkaisut muutamia yleisimpiä mainitakseni sekä tietysti tekoälykäyttö. Jakelukerroksessa voidaan hakea tuotteita muista eri kerroksista vaikkakin kultakerros on tärkein. HR-esimerkissä voisi olla esimiehille tarkoitettu portaali henkilöiden palkkakehityksestä.
Jotta kerroksellisesta arkkitehtuurista saadaan hallittavaa, tarvitaan myös dokumentaatiota tietojen virtauksesta sekä teknisellä tasolla eri kerrosten ja lähdejärjestelmän välillä että myös tiedon arvovirtoina, josta käy ilmi syntyvät datatuotteen jalostusprosessi. Tämän lisäksi tulee ymmärtää teknisen tietototeutuksen ja käsitteellisen tietomallin välinen yhteys. Esim. HR-tietojen osalta käsite henkilön palkka tulee yhdistää fyysiseen tietosisältöön palkkatietojen osalta.
Tietovirtojen ohella puhutaan myös tiedon arvovirrasta. Itse arvostan tätä näkemystä vahvasti erityisesti, kun mietitään organisaation liiketoiminnallista tarvetta tiedon käytölle. Jos tiedolla ei ole arvoa, niin miksi sitä kannattaa hillota tietokannoissa, koska jo säilyttäminenkin maksaa levytilana tai pilvipalvelun kapasiteettina. Jos tiedolle ei ole tunnistettu arvoa niin onko tiedon laatu huonoa vai eivätkö hyödyntäjät tarvitse sitä. Voisiko sen arvo parantua jos se tieto olisi paremmin ymmärretty ja sen laatu olisi parempaa.
Datatuotteiden laatu ratkaisee näiden hyödynnettävyyden
Miten määritellään tiedon laatu? Tästä voisi kirjoittaa pitkäänkin, koska laatu ratkaisee, kuinka hyvin tiedot ovat hyödynnettävissä. Datatuotteiden näkökulmasta laatuvaatimukset ovat sekä teknisiä että sisältöön liittyviä. Teknisiä siinä mielessä esim. onko kaikki tarvittava tieto saatavilla, onko tieto oikean muotoista tai onko tyhjiä tietoja, jos näitä ei saisi olla. Sisältöön liittyen tiedot “tulee olla oikein” eli sisältö on oikein. Laadukkaan tiedon muodostusprosessissa tärkeimmässä roolissa on tiedon tuottaja. Toki myös tietoalustan eri kerroksissa voidaan laatua parantaa mm. harmonisoimalla tietoa.
Näiden tiedon laadun perusasioiden lisäksi datatuotteilla on ns. subjektiivinen laatuvaatimus, eli niiden tulee vastata liiketoimintasääntöihin. Esim. tieto voi olla oikean muotoista, mutta sillä ei ole arvoa, koska sisältö on virheellinen. Kuulin entiseltä kollegalta hyvän esimerkin. Tilaus tehtiin ennen vuodenvaihdetta vuonna xxx1 ja toimitus oli sovittu 2.1.xxx2. Toimitukseen kuitenkin päivämääräksi oli kirjattu toimituspäivä 31.12.xxx2, jolloin 2.1.xxx2 ei siis saatu toimitusta. Tieto meni läpi kaikista laatutarkastuksista. Liiketoiminta ei vain ollut määrittänyt sitä, että toimituksen tulisi olla seuraavan kuukauden aikana. Näin tuo virhe olisi havaittu. Laatua ei voi koskaan ratkaista vain teknisesti vaan siinä on huomioitava myös liiketoimintavaatimukset. Itseasiassa laadunvarmistus tulee tehdäkin liiketoimintasääntöjen tarkistuksena. Tästä voisi kirjoittaa ihan oman tarinansa, joten palataan takaisin datatuotteisiin ja näiden tekniseen toteutukseen.
Datatuotteet teknisenä toteutuksena
Datatuotteet syntyvät tiedon jalostusprosessin tuloksena. Tässä on paljon yhtäläisyyksiä tietovarastointiin. Ehkä suurin ero on siinä, että kun ymmärrys tiedon jalostamisprosessista on kasvanut, samalla on opittu tuotteistamaan tietotyötä. Myös tekniset ratkaisut ovat kehittyneet tukemaan tietotyötä. Datalätäköt ja pilvialustat mahdollistavat tehokkaampaa tietojen prosessointia, joten yhä suurempi määrä tietoa on hallittavissa.
Aluksi datalätäköiden idea oli, että sinne dumpataan kaikki mahdollinen organisaation tieto. Seuraus oli, ettei kukaan aidosti voinut hyödyntää kerättyä tietoa. Siksi siirryttiin takaisin jäsenneltyyn arkkitehtuuriin. Kuitenkin aikaisemmasta oli opittu, että tulee huomioida eritasoiset tietotarpeet. Joillekin riittää raakadata, toiset tarvitsevat pitkälle pureskeltua informaatiota. Esim. tekoäly on varsin onnellinen saadessaan paljon dataa murskattavaksi, joten sen datan ei tarvitse olla viimeisteltyä, kunhan on ymmärrys datan laadusta. Liiketoiminta taas tarvitsee pitkälle jalostettua informaatiota, jotta saadaan laskettua yhdenmukaisia mittareita.
Pilvialustat vastaavasti mahdollistavat joustavan käsittelypaikan tietojen hyödyntämiseen. Alkuvaiheessa innostus tietojen helposta siirrosta pilvipalveluihin aiheutti vastaavan ongelman. Tietoja vain ladattiin miettimättä näiden todellista tarvetta ja arvoa, kunnes huomattiin, että ei ole ilmaista lounasta. Pilvialustallakin tulee olla hallittu arkkitehtuuri. Tähän kaikkeen, kun yhdistetään tarve tuotteistaa tietotyön tulosten hyödyntämistä, niin on päädytty datatuoteajatteluun. Parasta tässä kehityksessä perinteiseen tietovarastoinnin näkökulmaan on se, että datatuotteilla tulee olla omistajuus ja tuotteet pitää dokumentoida tietomallinnuksen keinoin, ja kuten jo aikaisemmin mainitsin, myös tietojen metadata hallitaan datatuoteratkaisussa keskitetysti datakatalogeissa. Datatuotteiden rakentamisprosessi on myös ketterää, eikä kulu useita vuosia vaikkapa raportin tietojen saamiseen.
Johtopäätöksiä
Otsikossa tuotiin esille selkeä kysymys: “Ovatko datatuotteet hypeä vai aito mahdollisuus tuottaa tietoa, jotta liiketoiminta saa parempaa tietoa päätöksentekoon ja sitä kautta mahdollistaa kilpailukyvyn paranemista?”. Siispä punnitaan vielä lopuksi datatuotteiden haasteita ja mahdollisuuksia.
Haasteeksi voi muodostua hyvin perinteinen tiedonhallinnan ongelma. Kuvattava reaalimaailma on kompleksinen ja tämä heijastuu myös siitä tuotettuun tietoon. Saadaanko siis datatuotearkkitehtuuri pidettyä hallittuna, jottei tiedoista synny ns. duplikaatteja. Haaste voi olla myös, että datatuotteet ovat liiketoiminta-aluekohtaisia. Saadaanko näin säilymään kokonaiskuva ja kenellä on kokonaisvastuu koko datatuoteavaruudesta. Onneksi nämä haasteet ovat hallittavissa hyvillä tiedon ohjauksen ja johtamisen käytännöillä ja sillä, että tiedon arvo ymmärretään osana organisaation pääomaa.
Mahdollisuudet sen sijaan ovat hyvinkin laajoja. Tuotteistaminen tuo hallittavuutta ja luo laadukkaampaa tietosisältöä, joten päätöksenteossa voidaan luottaa paremmin olemassa oleviin tietoihin. Datatuotekonsepti tuo myös tietotyön osaksi arkityötä. Ei ole erillistä paikkaa jonne tiedot siirretään pois omalta vastuualueelta, koska datatuotteiden muodostus ja hallinta kuuluvat osana kunkin liiketoiminta-alueen rutiineihin.
Datatuotteiden avulla meillä on hyvät eväät saada laadukasta tietoa paremman päätöksenteon tueksi ja sitä kautta kehittää organisaation kilpailukykyä. Mutta mikä parasta, tässä kirjoittaessani artikkelia se mustikkapiirakkakin kypsyi uunissa valmiiksi ja juuri tavoitteiden mukaiseksi.
Siispä rakennetaan laadukkaita datatuotteita, sillä liiketoiminnan ruokahalu kasvaa koko ajan.
Bon appetit!
Minna Oksanen on Dama Finlandin puheenjohtaja ja toimii Gofore Leadissa asiantuntijana konsultoiden ja kouluttaen asiakkaita eri tiedonhallinnan osa-alueiden osalta.
