Master data: periaatteet ennen työkaluja 

Käsitemalli kertoo, mitä tieto tarkoittaa. Master datan hallinta puolestaan kertoo, kuka tietoa hallitsee, mistä se muodostuu ja miten sitä jaetaan. Sarjan ensimmäisessä osassa käsiteltiin ensimmäistä kysymystä. Tässä toisessa osassa vastataan jälkimmäiseen. Kun sama asiakas löytyy kolmesta järjestelmästä kolmella eri tunnuksella, kuka tiedon omistaa ja mistä virallinen tieto muodostuu? Siihen kannattaa vastata periaatteilla ennen työkaluja. 

Auktoritatiivinen lähde on päätös 

Master datan hallinnassa määritellään kullekin ydinentiteetille auktoritatiivinen lähde, tarvittaessa attribuutin tai elinkaaren vaiheen tarkkuudella: asiakkaan perustiedot voivat tulla eri järjestelmästä kuin laskutustiedot, ja hallittu kokonaiskuva eli golden record kootaan silloin useasta lähteestä. Yhtä tärkeää on määritellä, mistä dataa ei hallita. Nämä dokumentoidaan päätöksinä: entiteetti, omistaja, master-lähde, sallitut kopiot ja jakelutapa. Ensin sovitaan, mistä mikäkin tieto tulee ja miten muut kytkeytyvät siihen, ja vasta sitten valitaan tekninen toteutus. 

Useimmissa tilanteissa en aloittaisi raskaalla MDM-tuotehankinnalla. Suurin osa master datan hyödystä syntyy periaatteista, omistajuuksista ja hallitusta auktoritatiivisesta näkymästä, ei työkalusta. Toimiva tapa on pilotoida periaatteet ensin yhdellä tai kahdella entiteetillä kevyellä toteutuksella ja arvioida työkalutarve vasta pilotista saatujen kokemusten perusteella. Näin vältetään tilanne, jossa työkalu määrittää hallintamallin eikä toisinpäin. 

Miltä tämä näyttää käytännössä? 

Palataan alun esimerkkiin, jossa sama asiakas löytyy kolmesta järjestelmästä kolmella eri tunnuksella. Käsitemalli antaa asiakaskäsitteelle yhden määritelmän. Tämän jälkeen master datan hallinta täsmäyttää nämä kolme tietuetta samaksi asiakkaaksi ja tunnisteet linkitetään hallitusti toisiinsa. Lähdejärjestelmien ei tarvitse luopua omista avaimistaan, kunhan tunnisteiden vastaavuudet ovat hallitusti ylläpidettyjä. Asiakkaan perustiedoille sovitaan master-lähde, esimerkiksi asiakkuudenhallinta, jossa ne syntyvät ja jossa niitä muutetaan. Muille järjestelmille voidaan sallia kopio, jonka muutokset hallitaan sovitun masteroinnin mukaisesti: tässä yksinkertaistetussa esimerkissä asiakkaan perustiedot päivittyvät asiakkuudenhallinnasta muihin järjestelmiin, eivät toiseen suuntaan. Kun seuraava uusi palvelu tarvitsee asiakastietoa, se ei määritä omaa kilpailevaa masteriaan, vaan käyttää yhteisesti sovittua masteria, tunnisteita ja jakeluperiaatteita. 

Pääsynhallinta yli järjestelmien 

Käsitemallin yhteydessä kannattaa määritellä myös käyttöoikeuksien periaatteet: kuka saa lukea ja muuttaa mitäkin master-dataa sekä millä ehdoilla palvelukohtainen käyttö kytkeytyy master-lähteeseen. Entiteetti on luonteva lähtötaso, mutta käytännössä oikeudet tarkentuvat usein myös rivin, attribuutin, roolin ja käyttötarkoituksen mukaan. Keskitetty master-lähde on looginen käsite: ensivaiheessa se voi olla olemassa oleva järjestelmä tai kevyt rekisteri, ei välttämättä erillinen MDM-tuote. Periaatteet toteutetaan myöhemmin valittavan integraatio- ja identiteettiarkkitehtuurin mukaisesti, jolloin pääsynhallinnasta muodostuu yhtenäinen, järjestelmien yli toimiva malli. 

Tämä on olennaista juuri nyt, kun yhä useampi organisaatio avaa tietopääomaansa hallitusti AI-agenttien käyttöön. Agentti ei itse tulkitse, mitä se saa nähdä: se toimii käyttäjän tai palveluidentiteetin oikeuksilla, ja pääsyä valvotaan teknisesti datakerroksessa, identiteetinhallinnassa ja pääsynhallintasäännöissä. Juuri siksi periaatteet kannattaa määritellä entiteettien kielellä jo mallinnusvaiheessa: sama periaate voidaan silloin toteuttaa mahdollisimman yhdenmukaisesti eri järjestelmissä ja kaikille käyttäjille, myös agenteille. 

Omistajien mandaatti ratkaisee 

Master datan periaatteet ovat perustava kyvykkyys, joka avaa muiden hankkeiden etenemisen: integraatiot tarvitsevat yhteisesti määritellyt tai hallitusti toisiinsa linkitetyt tunnisteet kiinnityskohdakseen, ja käsitemalli auttaa rajaamaan datatuotteet ja niiden omistajuudet, vastasipa tuote sitten entiteettiä, prosessia tai käyttötapausta. 

Yksi asia ratkaisee onnistumisen enemmän kuin mikään tekninen valinta: omistajien mandaatti. Data ownerin nimeäminen ei yksin riitä. Omistajalla pitää olla myös päätösvalta. Auktoritatiivisten lähteiden määrittely on ennen kaikkea päätöksentekoa, ei selvitystyötä. Suurin kustannus- ja aikatauluriski ei siksi ole tekninen, vaan päätöksenteon hitaus tai puuttuva mandaatti. Kun liiketoiminnan avainhenkilöt osallistuvat työpajoihin ja johdolta on selkeä mandaatti päätöksille, rajattu ensimmäinen versio saadaan käyttöön kuukausissa. Ilman omistajien sitoutumista hyväkin malli jää helposti dokumentiksi. 

Mistä liikkeelle? 

Listaa kolme organisaatiosi tärkeintä master data -entiteettiä ja kysy kustakin:  

• kuka tiedon omistaa? 

• mistä auktoritatiivinen tieto muodostuu?  

• miten tieto jaetaan muihin järjestelmiin?  

Jos vastaukset ovat epäselviä tai ristiriitaisia, valitse yksi entiteetti pilotiksi. Määrittele sille omistaja, auktoritatiiviset lähteet, tunnisteiden hallinta ja jakeluperiaatteet ennen työkalun valintaa.