Cztery sposoby zarządzania danymi podstawowymi
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduł 2 z 6 w rozdziale Dane podstawowe i tożsamość, rozdziale 6 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Jedno źródło prawdy dla każdego atrybutu · Dalej: Dopasowanie, scalanie i reguły przetrwania
Pytanie, na które odpowiada ten moduł: jak organizacje zarządzają danymi podstawowymi i który styl pasuje?
Moduł 1 mówił, że autorytet przypisuje się atrybut po atrybucie. Teraz: co robimy, gdy te atrybuty mieszkają naraz w kilku systemach? Informacje o kliencie w Salesforce, ERP, systemie rozliczeń, systemie wsparcia, może w Data 360, może w hurtowni, każdy z własną wersją. Ten problem próbuje rozwiązać zarządzanie danymi podstawowymi (MDM), a MDM to nie jedna architektura. Usłyszysz o czterech wzorcach: rejestr, konsolidacja, współistnienie i podejście scentralizowane. To nie są ustawienia produktu. To cztery odpowiedzi na jedno pytanie: ile autorytetu ma warstwa zarządzania danymi podstawowymi?
Zacznij od problemu, nie od produktu
Dział zatytułowany „Zacznij od problemu, nie od produktu ”Ludzie słyszą „MDM” i zaczynają szukać produktu MDM. Ja zacząłbym od problemu. Czy potrzebujemy tylko wiedzieć, że kilka rekordów to ten sam klient? Czy potrzebujemy jednego połączonego widoku do analityki? Czy musimy decydować, które wartości są nadrzędne, i wysyłać je z powrotem do innych systemów? Czy chcemy jednego centralnego systemu, który tworzy dane podstawowe dla wszystkich? To bardzo różne wymagania i bardzo różne architektury.
Rejestr: powiedz mi, kto jest kim
Dział zatytułowany „Rejestr: powiedz mi, kto jest kim ”Najlżejszy wzorzec. Rejestr (registry) nie zastępuje źródeł. ERP zachowuje swojego klienta, Salesforce swoje konto, system rozliczeń swojego klienta, a rejestr ustala, że te rekordy odwzorowują ten sam podmiot: konto Salesforce 001…, klient ERP SAP-43821 i klient w systemie rozliczeń BILL-9127 należą do jednego klienta. Źródła zostają tam, gdzie są, i nie są nadpisywane. Teraz pytanie „pokaż mi wszystko, co wiemy o tym kliencie” ma odpowiedź.
Ale zwróć uwagę, na co rejestr nie odpowiada. Salesforce mówi Main Street 123, ERP 125, system rozliczeń „Main St. 123, lokal 200”. Rejestr wie, że należą do siebie. Nie decyduje, który z nich powinien się zmienić. Połączenie to jeszcze nie zarządzanie danymi podstawowymi.
Z mojego doświadczenia rejestr to norma w projektach Salesforce, potem konsolidacja i współistnienie; czyste, scentralizowane MDM jest rzadkie. Rejestr jest częsty, bo jest nieinwazyjny. Nie przeprojektowujesz każdego systemu operacyjnego, zanim zobaczysz wartość. Salesforce dalej robi to, co robi, ERP dalej robi to, co robi, a ty dodajesz warstwę tożsamości. To dużo mniejsza zmiana niż powiedzenie każdemu systemowi: „już nie kontrolujesz danych klientów; robi to nowy centralny system”.
Rejestr odpowiada: które rekordy należą do tej samej encji?
Konsolidacja: zbierz dane razem
Dział zatytułowany „Konsolidacja: zbierz dane razem ”Konsolidacja bierze dane z kilku źródeł i łączy je w centralną reprezentację, na potrzeby raportowania, analityki, segmentacji, wiedzy o klientach. Znanym przykładem jest hurtownia: Salesforce wysyła klienta, ERP dane finansowe, system rozliczeń płatności, a biznes wreszcie może analizować klienta we wszystkich systemach. Źródła nadal istnieją i nadal mogą być nadrzędne. Kierunek ma znaczenie: dane płyną do systemu konsolidującego, który zwykle nie odsyła zmian w danych podstawowych z powrotem. Lepszy obraz klienta, bez stawania się jego operacyjnym autorytetem.
Rejestr i konsolidację łatwo pomylić. Różnica polega na tym, co jest scentralizowane: rejestr centralizuje tożsamość („te należą do siebie”); konsolidacja centralizuje więcej danych („zbierz atrybuty razem, żebyśmy mogli z nich korzystać”). Żadne z nich nie mówi „ten centralny system jest teraz źródłem nadrzędnym, a każda aplikacja musi przyjąć jego wartości”.
Konsolidacja zbiera dane razem, nie odbierając źródłom własności.
Współistnienie: zdecyduj i odeślij
Dział zatytułowany „Współistnienie: zdecyduj i odeślij ”We współistnieniu (coexistence) warstwa zarządzania danymi podstawowymi dostaje prawdziwy autorytet. Dane nadal mieszkają w kilku systemach operacyjnych, ale proces MDM decyduje o wartości nadrzędnej i publikuje ją z powrotem. Salesforce, ERP i system rozliczeń mają każdy inną nazwę prawną; proces MDM ustala tę zarządzaną i rozsyła ją do wszystkich trzech. Systemy współistnieją, ale zbiegają się do wartości nadrzędnej.
To dużo silniejsza forma MDM. Nie mówi „te należą do siebie”; mówi „dla tego atrybutu przedsiębiorstwo używa tej wartości”. To wymaga więcej niż dopasowania: reguł biznesowych, własności, reguł przetrwania, integracji dwukierunkowej, obsługi błędów i zarządzania, bo ktoś musi zdecydować, dlaczego wygrywa jedna wartość.
Współistnienie nie tylko łączy rekordy. Decyduje o wartościach nadrzędnych i odsyła je z powrotem.
Podejście scentralizowane: źródło nadrzędne tworzy prawdę
Dział zatytułowany „Podejście scentralizowane: źródło nadrzędne tworzy prawdę ”Najsilniejszy wzorzec. W scentralizowanym MDM zarządzane dane podstawowe są tworzone i utrzymywane w centralnym źródle nadrzędnym i rozsyłane do wszystkich innych. Zamiast tego, żeby każdy system tworzył własnego klienta, a MDM uzgadniało ich potem, tworzysz zarządzanego klienta w źródle nadrzędnym, a potem wysyłasz go do Salesforce, ERP i systemu rozliczeń. Bardzo silne zarządzanie i bardzo duża zmiana: istniejące procesy tworzą własnych klientów, użytkownicy mają swoje sposoby pracy, integracje zakładają lokalne tworzenie, a jednostki biznesowe mogą nawet nie zgadzać się co do tego, kim jest klient. Dlatego w krajobrazach Salesforce, które widzę, jest rzadkie. Może być właściwe. To dużo większa decyzja niż instalacja narzędzia.
Scentralizowane MDM przenosi tworzenie i autorytet do źródła nadrzędnego.
Cztery obok siebie
Dział zatytułowany „Cztery obok siebie ”| Styl | Co jest scentralizowane | Czy źródła zostają? | Odsyła zarządzane wartości? |
|---|---|---|---|
| Rejestr | Tożsamość i powiązania | Tak | Zwykle nie |
| Konsolidacja | Tożsamość plus połączone dane | Tak | Zwykle nie |
| Współistnienie | Tożsamość, dane i decyzje o wartościach nadrzędnych | Tak | Tak |
| Scentralizowane | Tworzenie i autorytet | Tak, jako odbiorcy | Tak |
Im niżej w tabeli, tym więcej autorytetu ma warstwa zarządzania danymi podstawowymi i tym więcej zwykle musi zmienić się organizacja.
Wiedza egzaminacyjna. Znaj cztery style wdrażania MDM: rejestr (łączy tożsamości; źródła zachowują swoje dane), konsolidacja (zbiera dane razem, zwykle do analizy), współistnienie (decyduje o wartościach nadrzędnych i publikuje je z powrotem do źródeł) i podejście scentralizowane (źródło nadrzędne tworzy dane; źródła z nich korzystają).
Nie ma więc zasady „scentralizowane jest najbardziej dojrzałe, więc wszyscy powinni tam dojść”. Wybierz najlżejszy wzorzec, który rozwiązuje problem. Potrzebujesz wiedzieć, że rekordy należą do siebie? Pomyśl o rejestrze. Połączonego widoku do analityki? Konsolidacja. Zarządzanych wartości synchronizowanych z powrotem do kilku systemów operacyjnych? Współistnienie. Jednego procesu, który tworzy i kontroluje dane podstawowe dla wszystkich? Podejście scentralizowane.
Gdzie pasuje Data 360?
Dział zatytułowany „Gdzie pasuje Data 360? ”Data 360 buduje ujednolicone profile z wielu źródeł, co brzmi bardzo podobnie do MDM, i rzeczywiście rozwiązuje część problemu. Jego rozpoznawanie tożsamości dopasowuje profile źródłowe do ujednoliconej tożsamości i zachowuje powiązania z rekordami źródłowymi (Data 360 Architecture (opens in a new tab), po angielsku). To czyni go najbliższym rejestrowi. Potrafi też pokazywać uzgodnione wartości na ujednoliconym profilu. Ale to nie czyni go scentralizowanym systemem złotego rekordu, który przepisuje źródła. Ujednolicony widok to nie automatycznie zarządzany rekord przedsiębiorstwa. O tej różnicy jest cały moduł 4.
Wspólny model to nie wspólna prawda
Dział zatytułowany „Wspólny model to nie wspólna prawda ”Usłyszysz też o kanonicznym modelu danych. Konto w Salesforce, partner biznesowy w ERP i klient w systemie rozliczeń mapują się na jedno uzgodnione pojęcie przedsiębiorstwa, Klient, z uzgodnionymi identyfikatorami i atrybutami, żeby każda integracja nie musiała rozumieć kształtu każdego innego systemu. Model danych Data 360 to przykład harmonizowania źródeł do wspólnych pojęć. Ale model kanoniczny odpowiada na pytanie, jak to spójnie odwzorować? MDM odpowiada na pytanie, jak to identyfikować, zarządzać tym i utrzymywać jako dane podstawowe w wielu systemach? Zmapuj wszystkie trzy systemy idealnie na jeden kształt Klienta, a Salesforce nadal będzie mówił Main Street 123, a ERP 125. Rozwiązana jest struktura, a nie autorytet. Harmonizacja i zarządzanie danymi podstawowymi nie są wymienne.
Jeden biznes, kilka wzorców
Dział zatytułowany „Jeden biznes, kilka wzorców ”„Steve Trucking potrzebuje MDM” to więc nie jest wymaganie. Dla czego? Partnerzy detaliczni, centra dystrybucyjne, ekipy, ciężarówki, odbiorcy to różne domeny z różnymi autorytetami: partnerzy detaliczni zarządzani w Salesforce i finansowym ERP, tożsamość ciężarówek z FleetLink, każdy odbiorca dostarczany przez partnera dla każdej dostawy. Różne domeny mogą przyjmować różne wzorce, a w obrębie domeny atrybuty mogą mieć różne autorytety. Nie rysuj więc prostokąta z napisem MDM na środku diagramu i nie ogłaszaj, że problem rozwiązany. Zapytaj, co ten prostokąt robi.
Styl zmienia też integrację. Rejestr potrzebuje powiązań tożsamości; konsolidacja niezawodnych przepływów przychodzących; współistnienie danych w obu kierunkach; podejście scentralizowane rozsyłania ze źródła nadrzędnego oraz kontroli, które nie pozwalają innym systemom tworzyć konkurencyjnej prawdy. Gdy rośnie autorytet, rośnie koordynacja, a także obsługa błędów: co, jeśli MDM zmieni nazwę prawną, a ERP ją odrzuci? Dlatego współistnienie i podejście scentralizowane to nie „rejestr z większą liczbą funkcji”. Niosą inne obowiązki operacyjne.
MDM to decyzja biznesowa
Dział zatytułowany „MDM to decyzja biznesowa ”Najważniejsza rzecz: MDM to w gruncie rzeczy nie decyzja technologiczna. To decyzja o autorytecie. Kto tworzy klienta, kto może go zmieniać, kto decyduje, która wartość wygrywa, które systemy muszą ją przyjąć, co się dzieje, gdy się nie zgadzają. Narzędzie może te decyzje zaimplementować; nie może sprawić, że organizacja się na nie zgodzi. Dlatego projekt MDM może mieć znakomitą technologię i mimo to się nie udać: zespół techniczny rozwiązał dopasowanie, a biznes nigdy nie rozwiązał kwestii własności.
Ogólna lekcja, której nauczyłem się na własnej skórze: gdy kilka systemów zarządza tymi samymi danymi jako danymi podstawowymi, Salesforce nie uzgodni tego, czego one same nie uzgodniły. Gdy firma ma dwa ERP, pytam, jak utrzymuje je w synchronizacji. Jeśli nie potrafi, Salesforce też nie potrafi. Moduł 5 opowiada tę historię (Jeden klient, dwa ERP-y).
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Czy problem wymaga powiązań tożsamości, połączonych danych, odsyłania wartości nadrzędnych czy centralnego tworzenia.
- Który wzorzec pasuje do każdej domeny danych, zamiast jednego wzorca dla całego przedsiębiorstwa.
- Ile autorytetu dostaje warstwa zarządzania danymi podstawowymi i które systemy muszą przyjmować jej decyzje.
- Czy potrzebny jest model kanoniczny, bez mylenia harmonizacji z autorytetem.
- Jak wybrany wzorzec zmienia kierunek integracji, własność i obsługę błędów.
Kiedy ktoś umieszcza na diagramie prostokąt MDM, zapytaj, co on robi. Wie, które rekordy należą do siebie? Łączy ich dane? Decyduje, które wartości wygrywają? Odsyła te decyzje? Tworzy dane od początku? Odpowiedzi mówią ci, jaką architekturę naprawdę masz i gdzie mieszka autorytet.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.