Tämä on toinen artikkeli sarjassa, jossa kerrotaan tiedon elinkaaresta ja tiedonhallinnan viitekehyksestä. Kuten viime artikkelissa kerroin, tiedon elinkaaressa on kolme vaihetta: tiedon suunnittelu, tiedon synty ja tiedon hyödyntäminen Tässä artikkelissa keskitytään Miten tietoa tuotetaan parhaimmin.
Tiedon ominaisuuksiin liittyy se, että tieto syntyy vain kerran, mutta sitä voidaan käyttää useita kertoja. Tästä syystä on tärkeä ymmärtää, että myös tiedon laatu määräytyy sillä hetkellä kun tieto tuotetaan. Tiedon laatu taas vaikuttaa siihen, miten hyvin tietoa voidaan hyödyntää eli tiedon tuottamiseen kannattaa panostaa. Jo tiedon suunnitteluvaiheessa ratkaistaan kyvykkyys, miten tietoa voidaan tuottaa. Kun tarvittavat tiedot on määritetty ja kuvattu, on näille muodostettava liiketoimintasäännöt, miten tieto tullaan tuottamaan. Liiketoimintasäännöt tulee koodata mukaan järjestelmään. Näin voidaan välttää myös inhimillisiä “näppihäiriöitä”, kun on olemassa tarkastussäännöt tiedon tuottamiseen.
Kaikkea tietoa ei organisaatio tuota itse, vaan voidaan hyödyntää jo aikaisemmin syntynyttä tietoa. Tällaista tietoa on mm. julkisista lähteistä saatava tieto kuten digi- ja väestöviraston tiedot. Siksi on tärkeää, että on yhteiset pelisäännöt tietojen osalta myös organisaatiorajojen yli. Julkisista lähteistä saatavalle tiedolle löytyy tietojen käyttöä helpottamaan yhteentoimivuusalusta, josta voidaan löytää tiedoille kuvauksia, joita voidaan käyttää ilman, että tarvitsee itse tehdä määrittelyä.
Myös asiakas itse voi olla tiedon lähde, joten tulee varmistaa, että asiakas saa tuotettua tiedot oikein. Missä muodossa esim. nimi- ja osoitetiedot sekä päivämäärät annetaan. Erityisesti erilaiset koodistot vaativat sääntöjä, miten näitä tulisi käyttää. Itse aina ilahdun, kun syntymäaika alkaa realistisesta vuodesta. Harvoja palveluja voi tarjota 0-vuotiaalle ja silti vuosiluvun peruuttaminen omaan ikään alkaa kuluvasta vuodesta. Sen sijaan, että palvelu huomioisi jo 18 vuoden iän ja tarjoaa ajankohdan alkamaan 18 vuotta aikaisemmalla vuosiluvulla. Taas siis palataan siihen, että palvelun toteuttajalla tulee olla ymmärrys, miten tietoja tulee tuottaa eli varmistaa liiketoimintasäännöillä tiedon laadukas synty.
Syntyvän tiedon luonne
Tiedon syntyyn liittyen on hyvä ymmärtää myös, millaista tietoa tuotamme. Karkeasti tiedot voidaan näiden luonteen mukaan jakaa kahteen luokkaan: pysyviin ja muuttuviin tietoihin.
Pysyviä tietoja ovat harvoin, jos koskaan muuttuvat tiedot, jotka samalla ovat myös organisaation tärkeimmät, strategiset tiedot, koska ilman näitä tietoja ei voida tehdä liiketoimintaa. Muuttuvia tietoja ovat taas tapahtumatason tiedot, jotka liittyvät lähes aina yhteen liiketoiminta-alueeseen. Nämä tiedot ovat kestoltaan lyhytaikaisia tai ne muuttuvat tiheällä aikavälillä. Tapahtumatason tietoja on myös määrällisesti enemmän. Esim IoT-ratkaisut tuottavat tiuhaan tahtiin tapahtumatietoa.
Riippumatta siitä onko tieto pysyvää tai muuttuvaa, niin kaikki tiedonhallinnalliset tekemiset liittyvät näihin molempiin. Pysyvien tietojen osalta on kuitenkin olemassa tiettyjä lainalaisuuksia, joista tässä artikkelissa kerrotaan vielä tarkemmin. Pysyvistä tiedoista voidaan käyttää myös termiä masterdata, ydintieto tai yhteinen tieto. Tässä artikkelissa käytän termiä masterdata, koska se löytyy myös DAMA DMBok 2.0 viitekehyksestä. Tarkalleen ottaen sektorin nimi on Master and Reference data, josta seuraavaksi tarkemmin.
Master- ja referenssitieto
Master- ja referenssitiedot ovat siis joko koko organisaatiolle tai jollekin organisaation osalle yhteisiä tietoja. Koska nämä ovat usealle liiketoimintaprosessille yhteisiä, niin myös tiedon laadun vaikutus näkyy laajasti koko organisaatiossa. Jos esim. asiakkaan tiedoissa on virheitä, kertautuu se kaikkiin liiketoiminta-alueisiin, jossa kyseistä asiakasta käsitellään. Vaikutus näkyy myös laajasti tiedon hyödyntämisessä.
Jos yhteisiä tietoja ei hallita yhteisen toimintamallin, prosessin ja tietoratkaisun kautta, joudutaan myöhemmissä tiedon hyödyntämisvaiheissa tulkitsemaan tietoja. Esim. meillä on kolme organisaatio-osaa, joissa kaikissa on oma tuotekoodistonsa. Kuitenkin raportointi halutaan tehdä yhdestä paikasta huomioiden kaikki tuotteet. Tällöin joudutaan vertaamaan eri lähteistä saatavia tuotetietoja ja tunnistamaan, mitkä näistä ovat samoja tuotteita, vaikka onkin eri tunnisteet. Vastaava työ olisi voitu jo tehdä yhdistämällä tuotetiedot yhtenäiseksi master dataksi, jossa on jo yhdistetty tuotetiedot eli tehty ns. harmonisointi. Tiedon hyödyntäjän ei siis tarvitse enää huolehtia tietojen yhdistelystä.
Masterdatan hallinnointi riippuu siitä, millainen masterdata-arkkitehtuuri organisaatiossa on. Arkkitehtuuri voi olla keskitetty, hajautettu tai näiden yhdistelmä. Myös masteroitavilla tiedoilla voi olla erilaisia arkkitehtuureja liiketoiminnan luonteesta johtuen. Esim yhteinen organisaatio- ja tuotetieto, mutta toiminta-aluekohtaiset asiakastiedot. Isossa organisaatiossa voi olla myös toiminta-aluekohtaisesti masteroitavia tietoja. Otetaan esimerkki finanssiorganisaatiosta, jossa on sekä pankki- että vakuutusliiketoimintaa. Pankkitoiminnassa yksi tärkeimmistä masteroitavista tiedoista on asiakkaiden tilinumerot. Tieto on jopa niin arvokas, ettei kukaan muu kuin asiakas itse saa sitä nähdä tarkassa muodossa ja kaikissa pankin liiketoimintaprosesseissa on käytössä sama tilinumero. Sen sijaan vakuutusliiketoiminnassa tilinumero on tieto, jolla kerrotaan, minne mahdolliset vahingon korvaukset maksetaan.
Eli masteroitava tieto voi liittyä myös vain johonkin organisaation osaan tai jopa liiketoimintaprosessiin. Nämä yksittäisen liiketoiminta-alueen mastertiedot saattavat joskus näyttäytyä koko organisaation tasolla tapahtumatason tietoina. Esim. vakuutuksen vahinkotieto. Organisaatio laskee vahinkoja yhteensä, jolloin tieto on tapahtumatasoista. Samaan aikaan kuitenkin yksittäisen vahingon perustiedot ovat pysyviä tietoja vahingon käsittelyprosessille. Itse olen joskus verrannut masteroitavia tietoja siihen, kun heittää kiven veteen ja putoamiskohdasta lähtee loittonevat aallot. Kuinka laajalle aallot leviävät, kertoo kuinka laajasti tietoa organisaatiossa käytetään.
Masterdatan yksi erityismuoto on referenssitiedot. Referenssitiedot ovat yhteisiä koodistoja. Ne ovat tietoja, joita tarvitaan esim. ERP-järjestelmän perustamisen yhteydessä. Tai ne ovat koodistoja, joita tuodaan organisaatioon laajemmin muista yhteisistä koodistoista kuten postinumero tai Tilastokeskuksen eri koodistot. Osa referenssitiedoista on myös kansainvälisten standardien mukaisia, kun ISO-koodit maa, valuutta ja kieli. Referenssitietoja hyödynnetään, kun syötetään esim. asiakkaan tai tapahtuman tietoja. Mitä enemmän käytetään yhteisiä koodistoja, sitä helpompaa on tietojen hyödyntäminen myös eri organisaatioiden välillä. Tässä kohtaa täytyy vielä kertoa esimerkki koodiston “väärinkäytöstä”. Piti kerran tunnistaa tullikoodi Sous Vide-keittimelle, jotta sai tehtyä tullauksen verkossa. Eihän tällaista koodia suoraan löydy, mutta pienellä selvittelyllä löytyi mahdollisia muu- luokan koodeja loppuen 99:iin. Siispä kokeilin kodinkoneet 99-koodilla ja se toimi. Varsinaisia tietoja syötettäessä koodistokenttiä käytetään siis kovin luovasti, jos ei heti ole tarkkaa tietoa, mikä kooditieto tulee antaa.
Masterdataa voi siis olla monen tasoista, mutta yhteistä sille on, että sitä on osattava hallita liiketoiminnallisena assettina ei teknisenä ratkaisuna.
Käytännön esimerkki
Miten masterdata tunnistetaan
Käytännön esimerkissä tällä kertaa otan esille masterdatan tunnistamisen, koska siitä lähtee liikkeelle koko masterdatan hallinnointiprosessi. Koska masterdataa käytetään laajasti organisaatiossa tulee sen tunnistaminen tehdä yhdessä sitä käyttävien organisaatio-osien kanssa. Ei siis riitä, että mukana tunnistamisessa on vain yksittäinen organisaatio-osa. Itse asiassa masterdatan tunnistamisessa palataankin takaisin tietoarkkitehtuuriin ja tiedon määrittelyyn.
Parhaimmat omakohtaiset kokemukset onnistuneesta masterdata kehityksestä on, kun on lähdetty liikkeelle liiketoiminnan tietotarpeista ja sitä kautta liiketoimintakäsitteistä. Välttämättä ei edes ole tehty erillistä masterdatan tietomallinnusta, vaan liiketoimintaprosesseille tehdyistä tietomalleista on tunnistettu, mitkä tiedot ovat kaikille yhteisiä. Voisi ajatella, että eri liiketoiminta-alueiden käsitemallit ovat kuin piirtoheitinkalvoja, jotka pinoamalla päällekkäin kuvasta näkyy kaikissa niissä olevat yhteiset käsitteet. Yleisesti ottaen masterdata-käsitteet ovat niitä käsitemallin ns. isäkäsitteitä, jotka ovat itsenäisiä ja usein piirretty kuvan yläosaan. Tunnistamalla masteroitavat käsitteet saadaan tehtyä masterdatalle rakenne.
Toinen tärkeä kuvaus on niiden prosessien kuvaaminen, jossa masterdataa syntyy ja hyödynnetään. Prosessin kuvaamistasona riittää ylätaso, koska vasta myöhemmässä vaiheessa tarkennetaan prosessia toiminnallisuuksiin yhdessä käsitteiden tietojen tarkennennuksen kanssa. Lopullinen masterdatan määrittely kuvaa tarkalla tasolla tiedot, jotka kuuluvat masteroitaviin käsitteisiin ja toiminnot, missä tietoa tuotetaan ja hyödynnetään. Nämä kuvaukset yhdistämällä saadaan myös kuvattua liiketoimintasäännöt. Esimerkiksi organisaatio-masterdassa voi eri yksiköillä olla oma näkemyksensä organisaation rakenteeseen. Lopulliseen masterdataan harmonisoidaan yhteinen kuvaus siten, että saadaan yhteinen kuva organisaatiosta.
Masterdataa määriteltäessä on myös määriteltävä masteroitavien tietojen laajuus. Esimerkiksi asiakastietojen osalta eri liiketoiminta-alueilla voi olla erilaisia käyttötapauksia, jolloin myös tietosisältö vaihtelee. Vaihtoehtoina tällöin on muodostaa masteroitavien tietojen kokonaisuus joko vain avaintiedoista, avaintiedoista ja muutamista kaikille yhteisistä tiedoista tai hallita kaikkea asiakastietoa masteroitavana tietona. Jokaisessa näissä on omat etunsa ja haasteensa. Kokemuksesta voin sanoa, että ei voi suoraan sanoa, mikä on paras tapa. Mielenkiintoisin malli on se, jossa kaikki asiakaskäsitteen tiedot nähdään masteroitavina. Tällöin tarvitaan vahva harmonisointi, joka toki voidaan toteuttaa myös hybridinä- tai virtuaalisena eli kaikkea tietoa ei hallita yhdessä paikassa vaan on pelisäännöt, joiden avulla tietoa hallitaan hajautetusti. Joka tapauksessa masteroitavilla tiedoilla on oltava omistajat ja vastuulliset riippumatta siitä hallitaanko suppeampaa vai laajempaa kokonaisuutta.
Viikon vinkit
- Tiedon tuottamiseen tarvitaan liiketoimintasääntöjä varmistamaan tiedon oikeellisuutta
- Liiketoimintasäännöt muodostavat myöhemmin tehtävien laatusääntöjen pohjan
- Laadukas masterdata parantaa eniten organisaation tietojen käytettävyyttä
Master data ei ole tekninen toteutus, vaan se liittyy vahvasti liiketoiminnan strategisiin tietoihin, eli sen tunnistamisessa ja määrittelyssä tulee olla liiketoiminta mukana.
Minna Oksanen
