Olen innoissani! Olen nimittäin viime kuukausina törmännyt hämmästyttävän monta kertaa keskusteluun siitä, mitä Master Data oikein on. Ari Hovi tarkasteli Master Dataa käsitemallinnuksen ja tietovarastoinnin näkökulmasta blogikirjoituksessaan Mitä on Master Data ja sai aikaan aktiivisen keskustelun muun muassa LinkedIn:ssä. Myös jokaisella pitämälläni MDM käytännössä –kurssilla aihe on takuuvarma keskustelun herättäjä.
Master Datan olemuksesta puhuttaessa tykkään pilkkoa aiheen kolmeen osaan: 1. mitä Master Data on, 2. mitä Master Data sisältää ja 3. mikä on oikea määrä Master Dataa. Tässä kirjoituksessa avaan näitä näkökulmia – en siksi, että haluaisin viilata määritelmiä, vaan muistuttaakseni, kuinka monisyisestä asiasta on kyse.
Miksi ja miten Master Dataa pitäisi hallita, ovat sitten oma tarinansa, joka käydään perusteellisesti läpi muun muassa seuraavalla MDM käytännössä -kurssillani.
Mitä Master Data on?
Helppo lähestymistapa Master Datan määrittelyyn on kertoa, mitä todellisen elämän asioita Master Data sisältää: ihmisiä, organisaatioita, asioita ja paikkoja. Ja edelliset muuttuvat kiinnostaviksi, kun lisäämme niihin kontekstin: asiakkaita, toimittajia, yhteistyökumppaneita, tuotteita, palveluita, sopimuksia, myyntipisteitä, toimipaikkoja, henkilöstöä. Yhtä lailla on hyvä selvittää, mitä Master Data ei pidä sisällään. Se ei pidä sisällään tapahtuma- tai toimintatietoa eli transaktiodataa kuten sitä myös kutsumme. Esimerkkeinä transaktiodatasta ovat vaikkapa maksutapahtumat, osto- sekä myyntitilaukset, toimitukset, kontaktoinnit, reklamaatiot ja niin edelleen. Tiivistettynä Master Data kuvaa organisaation strategista perustaa, jonka ympärille liiketoiminta rakentuu, ja joihin transaktiot kiinnittyvät. Tässä vaiheessa homma tuntuu vielä varsin yksinkertaiselta, joten jatketaan eteenpäin.
Master Data on ennen kaikkea liiketoimintakriittistä tietoa. Kaikki toiminnot hyödyntävät jotain Master Dataa prosesseissaan. Master Dataa tarvitaan strategisessa suunnittelussa, taktisessa johtamisessa ja jokapäiväisessä operatiivisessa toiminnassa. Arkkitehtuurin näkökulmasta Master Data kytkeytyy edellisten tueksi tietovarastoihin sekä operatiivisiin järjestelmiin.
Lisäksi Master Data on organisaation läpi jaettua tietoa. Sillä on yhteisesti sovitut määritelmät, rakenteet ja laatusäännöt. Tällä pyritään siihen, että kaikissa prosesseissa saamme kiinnitettyä transaktiot samaan Master Data -esiintymään. Esimerkiksi asiakkuuksien johtamisen kannalta on tärkeää, että ymmärrämme asiakkaiden todellisen arvon. Sitä varten meidän pitää pystyä kiinnittämään eri toiminnoista kerätyt tiedot kuten toteutuneet myynnit, maksetut suoritukset, ostovelat, myynnin edistämisen kustannukset, avoinna olevat tarjoukset ja tunnistettu myyntipotentiaali samaan asiakkaan ilmentymään. Yhtä lailla kyse voi olla jokapäiväisen toiminnan tarpeiden palvelemisesta. Puhelinoperaattorin asiakaspalvelijan pitää pystyä epäselvää laskua asiakkaalle puhelimessa selvittäessään näkemään mitä tuotteita ja palveluita sama asiakas on tilannut operaattorin eri yksiköistä.
Mitä kaikkea Master Data sisältää?
Yksinkertainen liiketoiminnan fundamentti kuten asiakas, toimittaja tai tuote voi muuttua monimutkaiseksi, kun rupeamme tarkastelemaan, mistä se tarkalleen muodostuu. Itse jaan Master Datan osat seuraavasti: asiat eli entiteetit, entiteettien väliset relaatiot, entiteettejä kuvaavat attribuutit ja edellisiä määrittävät meta- ja referenssidatat. Tässä vielä lyhyesti kuvaus kaikista viidestä:
Entiteetit eli asiat, joista käsiteltävä Master Data -kokonaisuus muodostuu. Esimerkiksi asiakas voi muodostua kontaktihenkilöstä, toimipaikasta ja oikeushenkilöstä. Koska näitä kaikkia entiteettejä kuvaa aivan eri faktat (attribuutit), jaetaan ne omiksi entiteeteikseen.
Relaatiot eli asioiden väliset suhteet. Miten kontaktihenkilöt liittyvät toimipaikkaan, entä liittyvätkö ne oikeushenkilöön? Ovatko edelliset suhteet pakollisia ja voiko niitä olla useita yhden henkilön kohdalla? Relaatiot luovat laatusääntöjä datan luomiseen ja ylläpitoon sekä mahdollistavat asioiden tarkastelut entiteettiä suurempina kokonaisuuksina.
Attribuutit eli faktat, joilla kuvaamme, luokittelemme ja tunnistamme masteroitavan entiteetin kuten kontaktihenkilön. Kontaktihenkilöä kuvaavia attribuutteja on helppo keksiä, mutta Master Datasta puhuttaessa tulee attribuutit rajata yhteisiin, toimintojen kesken jaettaviin attribuutteihin. Pelkkien attribuuttien listaaminen ei riitä, vaan pitää myös sopia niiden määritelmät sekä sisältö- ja laatusäännöt. Tämä on työläin osa Master Datan määrittämistä ja ilman tätä Master Datan yhteinen jakaminen ja hyödyntäminen ei tule onnistumaan.
Referenssidata luokittelee muita datoja ja näkyy järjestelmissä useimmiten arvolistoina. Referenssidata on kriittistä tietosisältöjen yhdenmukaisuuden vuoksi. Suurin osa referenssidatasta on organisaation itsensä muodostamaa, mutta myös ulkoisia hyviä referenssidatoja on saatavilla kuten ISO:n maalistat. Esimerkkejä oikeushenkilön referenssidatasta voisi olla toimiala- ja kotimaalista samannimisten attribuuttien sisältönä. Referenssidata helpottaa datan ylläpitäjän työtä tarjoamalla sisältöön vaihtoehdot, joista valita. Samalla se poistaa ylläpitäjältä “luovuuden” parantaen datan laatua.
Metadata on entiteettien, relaatioiden ja attribuuttien sääntöjä sekä asetuksia. Myös määritelmät ovat metadataa, vaikka usein metadata nähdään vain teknisinä täsmennyksinä datalle. Metadataa kutsutaan usein ylimalkaisesti tiedoksi tiedosta. Oikeushenkilön kohdalla teknisempää metadataa on esimerkiksi yritystunnisteen formaatti ja semanttisempaa metadataa asiakassegmenttien arvojen määritelmät ja säännöt. Datan laadun näkökulmasta metadata on erittäin tärkeässä roolissa: sen avulla voidaan toteuttaa sisällön validointisääntöjä käyttöliittymiin tai integraatioihin sekä yksikertaisimmillaan vain ohjeistaa tiedon syöttäjiä.
Tietomallintaja lähestyy asiaa kuvaamalla entiteetit, relaatiot ja keskeisimmät attribuutit käsitemalliin sekä tarkentaa attribuutit meta- ja referenssitietoineen loogiseen tietomalliin. Sama lähestymistapa toimii Master Datojen määrittämiseen. Jotta saamme mukaan liiketoimintakontekstin ja liiketoiminnan edustajat, pitää kuvaaminen aloittaa ylätasolta (entiteetit, relaatiot, keskeiset attribuutit), jolle heidän asiantuntemuksensa keskittyy. Vasta tämän jälkeen voidaan hypätä yksityiskohtiin (attribuuttien täsmennys, referenssi- ja metadata), joissa meidän tietomallintajien osaaminen on keskeisessä roolissa. Yksityiskohtien määrittely vaatii myös olemassa olevan datan perusteellista analyysia.
Master Data on organisaation toiminnan kannalta keskeistä tietoa, johon transaktiot liittyvät. Ilman referenssi- ja metadataa jää Master Datan laatu alhaiseksi.
Mikä on oikea määrä Master Dataa?
Vaikka otsikon kysymys tuntuu aavistuksen hassulta, tämä kysymys tulee poikkeuksetta vastaan sekä koulutuksissani että asiakasprojekteissa. Tässä ei tarkoiteta rivitasolla olevaa datan määrää kuten tuotteiden lukumäärää vaan sitä, kuinka paljon koko organisaation läpi jaettuja attribuutteja meillä voi olla yhdestä Master Data -entiteetistä.
Osa esimerkiksi toimittajaa kuvaavista attribuuteista on sellaisia, joita tarvitaan kaikissa toiminnossa ja ne ovat ilman muuta organisaation yhteistä Master Dataa. Mutta miten toimia sellaisten tietojen kanssa, joita tarvitsee vain rajallinen osa toiminnoista. Ovatko ne osa organisaation yhteistä Master Dataa? Tähän ei ole patenttiratkaisua, vaan jokaisen organisaation tulee itse määrittää, milloin tiedot jaetaan yhteisenä Master Datana ja milloin ei. Ääripäävaihtoehdot ovat:
- ”Aina kun tietoa hyödyntää enemmän kuin yksi toiminto”. Tällöin on riskinä, että Master Data -attribuuttien määrä voi kasvaa hankalasti hallittavaksi.
- ”Vain kun tietoa hyödyntää kaikki toiminnot”. Tässä on riskinä, että yhteisten Master Datojen ulkopuolelle jäävien tietojen jakamiseksi pitää rakentaa manuaalisia prosesseja tai ylimääräisiä järjestelmien välisiä integraatioita.
Totuus on jossain kahden ylempänä esitetyn mallin välimaastossa ja ratkaisu tulee määrittää osana Master Datan hallintamallia. Juuri Master Datan jaettavuus tekee Master Datasta niin monisyisen. Tästä kumpuaa myös toisinaan tunteitakin kuumentava kysymys: Mitä on se data, joka kuvaa liiketoiminnan fundamenttia, mutta jonka jakamiselle ei ole suurempaa tarvetta? Asia on ratkaistavissa ja usein kompromissi löytyy jakamalla Master Datat koko organisaation yhteisiksi Enterprise Master Datoiksi ja toimintokohtaisiksi Master Datoiksi. Tästäkin aiheesta puhutaan tulevissa Master Data -koulutuksissa.
Alkuperäinen blogikirjoitus on julkaistu syyskuussa 2015 Ari Hovin blogissa.
Kirjoittaja Tero Laatikainen on Talent Basen informaationhallinnan palvelualueen johtaja ja pitkän linjan MDM-konsultti ja -kouluttaja. Hänen huippusuosittu Master Data Management käytännössä -koulutus on seuraavan kerran Ari Hovin kurssitarjonnassa 14.-15. joulukuuta. Joulukuun huipputarjouksena tämä koulutus nyt -50% normaalihinnasta. Lisätiedot ja ilmoittautuminen Ari Hovin sivuilta. Lisätietoja yrityskohtaisista MDM-koulutuksistamme löydät Talent Basen verkkosivuilta.
Ei kommentteja:
Lähetä kommentti