Neljä tapaa hallita perustietoja
Saatavilla myös 28 kielellä
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduuli 2/6 luvussa Perustiedot ja identiteetti, Data Architect -kurssin luku 6. Jokainen moduuli on itsenäinen. Edellinen: Yksi totuuden lähde kutakin attribuuttia kohden · Seuraava: Täsmäytys, yhdistäminen ja säilymissäännöt
Kysymys, johon tämä moduuli vastaa: Miten organisaatiot hallitsevat perustietoja, ja mikä tyyli sopii?
Moduuli 1 sanoi, että auktoriteetti määrätään attribuutti kerrallaan. Nyt: mitä teemme, kun nuo attribuutit elävät useassa järjestelmässä yhtä aikaa? Asiakastietoja Salesforcessa, ERP:ssä, laskutuksessa, tuessa, ehkä Data 360:ssa, ehkä tietovarastossa, kussakin oma versionsa. Sitä ongelmaa perustietojen hallinta (master data management, MDM) yrittää ratkaista, eikä MDM ole yksi arkkitehtuuri. Kuulet neljä mallia: rekisteri (registry), konsolidointi, rinnakkaiselo (coexistence) ja keskitetty. Ne eivät ole tuotteen asetuksia. Ne ovat neljä vastausta yhteen kysymykseen: kuinka paljon auktoriteettia hallintakerroksella on?
Aloita ongelmasta, älä tuotteesta
Osio nimeltä “Aloita ongelmasta, älä tuotteesta ”Ihmiset kuulevat sanan MDM ja alkavat ostoksille MDM-tuotetta etsimään. Minä aloittaisin ongelmasta. Tarvitseeko meidän vain tietää, että useat tietueet ovat sama asiakas? Tarvitsemmeko yhden yhdistetyn näkymän analytiikkaa varten? Pitääkö meidän päättää, mitkä arvot ovat auktoritatiivisia, ja työntää ne takaisin muihin järjestelmiin? Vai haluammeko yhden keskitetyn järjestelmän, joka luo perustiedot kaikille? Hyvin erilaiset vaatimukset, hyvin erilaiset arkkitehtuurit.
Rekisteri: kerro, kuka on kuka
Osio nimeltä “Rekisteri: kerro, kuka on kuka ”Kevein malli. Rekisteri ei korvaa lähteitä. ERP pitää asiakkaansa, Salesforce tilinsä, laskutus asiakkaansa, ja rekisteri päättelee, että nämä tietueet edustavat samaa entiteettiä: Salesforcen tili 001…, ERP:n asiakas SAP-43821 ja laskutuksen asiakas BILL-9127 kuuluvat yhdelle asiakkaalle. Lähteet pysyvät paikoillaan, eikä niitä kirjoiteta yli. Nyt kysymykseen ”näytä kaikki, mitä tiedämme tästä asiakkaasta” on vastaus.
Mutta huomaa, mihin rekisteri ei vastaa. Salesforce sanoo Pääkatu 123, ERP 125, laskutus ”Pääk. 123, krs 2”. Rekisteri tietää, että ne kuuluvat yhteen. Se ei päätä, minkä niistä pitäisi muuttua. Linkittäminen ei ole hallitsemista.
Kokemukseni mukaan rekisteri on normi Salesforce-projekteissa, sitten konsolidointi ja rinnakkaiselo; puhdas keskitetty MDM on harvinainen. Rekisteri on yleinen, koska se ei kajoa järjestelmiin. Sinun ei tarvitse suunnitella jokaista operatiivista järjestelmää uudelleen ennen kuin saat arvoa. Salesforce jatkaa tekemistään, ERP jatkaa tekemistään, ja sinä lisäät identiteettikerroksen. Se on paljon pienempi muutos kuin sanoa jokaiselle järjestelmälle: ”et enää hallitse asiakastietoja; tämä uusi keskitetty järjestelmä hallitsee.”
Rekisteri vastaa: mitkä tietueet kuuluvat samalle entiteetille?
Konsolidointi: tuo tiedot yhteen
Osio nimeltä “Konsolidointi: tuo tiedot yhteen ”Konsolidointi ottaa tietoja useista lähteistä ja yhdistää ne keskitetyksi esitykseksi raportointia, analytiikkaa, segmentointia ja asiakasymmärrystä varten. Tietovarasto on tuttu esimerkki: Salesforce lähettää asiakkaan, ERP taloustiedot, laskutus maksut, ja liiketoiminta voi vihdoin analysoida asiakasta järjestelmien yli. Lähteet ovat edelleen olemassa ja voivat yhä olla auktoritatiivisia. Suunnalla on väliä: tiedot virtaavat konsolidoituun järjestelmään sisään, eikä se yleensä työnnä hallittuja muutoksia takaisin. Parempi kuva asiakkaasta ilman, että siitä tulee asiakkaan operatiivinen auktoriteetti.
Rekisterin ja konsolidoinnin sekoittaa helposti. Ero on siinä, mitä keskitetään: rekisteri keskittää identiteetin (”nämä kuuluvat yhteen”); konsolidointi keskittää enemmän tietoja (”tuodaan attribuutit yhteen, jotta voimme käyttää niitä”). Kumpikaan ei sano: ”tämä keskitetty järjestelmä on nyt master, ja jokaisen sovelluksen on hyväksyttävä sen arvot.”
Konsolidointi tuo tiedot yhteen viemättä omistajuutta lähteiltä.
Rinnakkaiselo: päätä ja lähetä takaisin
Osio nimeltä “Rinnakkaiselo: päätä ja lähetä takaisin ”Rinnakkaiselossa hallintakerros saa todellista auktoriteettia. Tiedot elävät yhä useassa operatiivisessa järjestelmässä, mutta MDM-prosessi päättää hallitun arvon ja julkaisee sen takaisin. Salesforcessa, ERP:ssä ja laskutuksessa kussakin on eri virallinen nimi; MDM-prosessi määrittää hallitun nimen ja jakelee sen kaikille kolmelle. Järjestelmät elävät rinnakkain, mutta ne lähentyvät kohti hallittua arvoa.
Se on paljon vahvempi MDM:n muoto. Se ei sano ”nämä kuuluvat yhteen”; se sanoo ”tämän attribuutin osalta yritys käyttää tätä arvoa.” Se vaatii enemmän kuin täsmäytystä: liiketoimintasääntöjä, omistajuutta, säilymissääntöjä, kaksisuuntaista integraatiota, virheiden käsittelyä ja hallintaa, koska jonkun on päätettävä, miksi yksi arvo voittaa.
Rinnakkaiselo ei vain linkitä tietueita. Se päättää hallitut arvot ja lähettää ne takaisin.
Keskitetty: master luo totuuden
Osio nimeltä “Keskitetty: master luo totuuden ”Vahvin malli. Keskitetyssä MDM:ssä hallitut perustiedot luodaan ja niitä ylläpidetään keskitetyssä masterissa, josta ne jaellaan kaikille muille. Sen sijaan, että kukin järjestelmä loisi oman asiakkaansa ja MDM sovittaisi ne jälkikäteen, luot hallitun asiakkaan masteriin ja lähetät sen sitten Salesforceen, ERP:hen ja laskutukseen. Hyvin vahva hallinta, ja hyvin merkittävä muutos: nykyiset prosessit luovat omat asiakkaansa, käyttäjillä on omat työnkulkunsa, integraatiot olettavat paikallisen luonnin, eivätkä liiketoimintayksiköt välttämättä ole edes samaa mieltä siitä, mikä asiakas on. Siksi se on harvinainen näkemissäni Salesforce-järjestelmäkartoissa. Se voi olla oikea ratkaisu. Se on paljon isompi päätös kuin työkalun asentaminen.
Keskitetty MDM siirtää luonnin ja auktoriteetin masteriin.
Neljä mallia rinnakkain
Osio nimeltä “Neljä mallia rinnakkain ”| Tyyli | Mitä keskitetään | Säilyvätkö lähteet? | Työnnetäänkö hallitut arvot takaisin? |
|---|---|---|---|
| Rekisteri | Identiteetti ja linkit | Kyllä | Yleensä ei |
| Konsolidointi | Identiteetti ja yhdistetyt tiedot | Kyllä | Yleensä ei |
| Rinnakkaiselo | Identiteetti, tiedot ja hallintapäätökset | Kyllä | Kyllä |
| Keskitetty | Luonti ja auktoriteetti | Kyllä, kuluttajina | Kyllä |
Taulukossa alaspäin mentäessä hallintakerros saa enemmän auktoriteettia, ja organisaation on yleensä muututtava enemmän.
Koetieto. Tunne neljä MDM:n toteutustyyliä: rekisteri (linkittää identiteetit; lähteet pitävät tietonsa), konsolidointi (tuo tiedot yhteen, yleensä analyysia varten), rinnakkaiselo (päättää hallitut arvot ja julkaisee ne takaisin lähteisiin) ja keskitetty (master luo tiedot; lähteet kuluttavat niitä).
Joten ei ole niin, että ”keskitetty on kypsin, joten kaikkien pitäisi päästä sinne”. Valitse kevein malli, joka ratkaisee ongelman. Pitääkö tietää, että tietueet kuuluvat yhteen? Ajattele rekisteriä. Yhdistetty näkymä analytiikkaa varten? Konsolidointi. Hallitut arvot synkronoituna takaisin useaan operatiiviseen järjestelmään? Rinnakkaiselo. Yksi prosessi, joka luo ja hallitsee perustietoja kaikille? Keskitetty.
Mihin Data 360 sopii?
Osio nimeltä “Mihin Data 360 sopii? ”Data 360 rakentaa yhtenäisiä profiileja monista lähteistä, mikä kuulostaa kovasti MDM:ltä, ja se ratkaiseekin osan ongelmasta. Sen identiteetin selvitys täsmäyttää lähdeprofiilit yhtenäiseksi identiteetiksi ja säilyttää linkit takaisin lähdetietueisiin (Data 360 Architecture (opens in a new tab)). Siksi se on lähimpänä rekisteriä. Se voi myös näyttää sovitettuja arvoja yhtenäisessä profiilissa. Mutta se ei tee siitä keskitettyä golden record -järjestelmää, joka kirjoittaa lähteet uudelleen. Yhtenäinen näkymä ei automaattisesti ole hallittu yrityksen tietue. Moduuli 4 käsittelee kokonaan tätä eroa.
Yhteinen malli ei ole yhteinen totuus
Osio nimeltä “Yhteinen malli ei ole yhteinen totuus ”Kuulet myös termin kanoninen tietomalli (canonical data model). Salesforcen tili (Account), ERP:n liikekumppani ja laskutuksen asiakas kuvautuvat kaikki yhteen sovittuun yrityksen käsitteeseen, asiakkaaseen, jolla on sovitut tunnisteet ja attribuutit, jotta jokaisen integraation ei tarvitse ymmärtää jokaisen muun järjestelmän muotoa. Data 360:n tietomalli on esimerkki lähteiden harmonisoinnista yhteisiksi käsitteiksi. Mutta kanoninen malli vastaa kysymykseen miten esitämme tämän johdonmukaisesti? MDM vastaa kysymykseen miten tunnistamme, hallinnoimme ja hallitsemme sitä järjestelmien yli? Kuvaa kaikki kolme järjestelmää täydellisesti yhteen asiakkaan muotoon, ja Salesforce sanoo silti Pääkatu 123, kun ERP sanoo 125. Olet ratkaissut rakenteen, et auktoriteettia. Harmonisointi ja hallitseminen eivät ole keskenään vaihdettavissa.
Yksi yritys, useita malleja
Osio nimeltä “Yksi yritys, useita malleja ”Siksi ”Steve Trucking tarvitsee MDM:n” ei ole vaatimus. Minkä suhteen? Vähittäiskauppakumppanit, jakelukeskukset, tiimit, kuorma-autot ja vastaanottajat ovat eri alueita, joilla on eri auktoriteetit: vähittäiskauppakumppaneita hallitaan Salesforcessa ja taloushallinnon ERP:ssä, kuorma-auton identiteetti tulee FleetLinkistä, ja kumppani toimittaa jokaisen vastaanottajan kunkin toimituksen yhteydessä. Eri alueet voivat käyttää eri malleja, ja alueen sisälläkin attribuuteilla voi olla eri auktoriteetit. Älä siis piirrä kaavion keskelle laatikkoa nimeltä MDM ja julista asiaa ratkaistuksi. Kysy, mitä laatikko tekee.
Tyyli muuttaa myös integraatiota. Rekisteri tarvitsee identiteettilinkit; konsolidointi luotettavat sisääntulevat virrat; rinnakkaiselo tietoja molempiin suuntiin; keskitetty jakelun masterista sekä kontrollit, jotka estävät muita järjestelmiä luomasta kilpailevaa totuutta. Kun auktoriteetti kasvaa, kasvaa myös koordinointi, ja samoin virheiden käsittely: entä jos MDM muuttaa virallisen nimen ja ERP hylkää sen? Siksi rinnakkaiselo ja keskitetty eivät ole ”rekisteri lisäominaisuuksilla”. Niihin liittyy erilaisia operatiivisia vastuita.
MDM on liiketoimintapäätös
Osio nimeltä “MDM on liiketoimintapäätös ”Tärkein pointti: MDM ei pohjimmiltaan ole teknologiapäätös. Se on päätös auktoriteetista. Kuka luo asiakkaan, kuka saa muuttaa sitä, kuka päättää, mikä arvo voittaa, minkä järjestelmien on hyväksyttävä se ja mitä tapahtuu, kun ne ovat eri mieltä. Työkalu voi toteuttaa nuo päätökset; se ei voi saada organisaatiota sopimaan niistä. Siksi MDM-projekti voi epäonnistua erinomaisesta teknologiasta huolimatta: tekninen tiimi ratkaisi täsmäytyksen, eikä liiketoiminta koskaan ratkaissut omistajuutta.
Yleinen opetus, jonka olen oppinut kantapään kautta: kun useat järjestelmät hallitsevat samoja tietoja, Salesforce ei voi sovittaa sitä, mistä ne eivät ole samaa mieltä. Kun yrityksellä on kaksi ERP:tä, kysyn, miten ne pidetään synkronissa. Jos he eivät pysty siihen, ei pysty Salesforcekaan. Moduuli 5 kertoo sen tarinan (Yksi asiakas, kaksi ERP:tä).
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Tarvitseeko ongelma identiteettilinkkejä, yhdistettyjä tietoja, takaisin työnnettyjä hallittuja arvoja vai keskitettyä luontia.
- Mikä malli sopii kullekin tietoalueelle, eikä yksi malli koko yritykselle.
- Kuinka paljon auktoriteettia hallintakerros saa ja minkä järjestelmien on hyväksyttävä sen päätökset.
- Tarvitaanko kanonista mallia, sekoittamatta harmonisointia auktoriteettiin.
- Miten valittu malli muuttaa integraation suuntaa, omistajuutta ja virheiden käsittelyä.
Kun joku laittaa kaavioon MDM-laatikon, kysy, mitä se tekee. Tietääkö se, mitkä tietueet kuuluvat yhteen? Yhdistääkö se niiden tiedot? Päättääkö se, mitkä arvot voittavat? Työntääkö se nuo päätökset takaisin? Luoko se tiedot alun perin? Vastaukset kertovat, mikä arkkitehtuuri sinulla todella on ja missä auktoriteetti asuu.
Lue lisää
Osio nimeltä “Lue lisää ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).