Jedno źródło prawdy dla każdego atrybutu
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ł 1 z 6 w rozdziale Dane podstawowe i tożsamość, rozdziale 6 kursu Data Architect. Każdy moduł jest samodzielny. Dalej: Cztery sposoby zarządzania danymi podstawowymi
Pytanie, na które odpowiada ten moduł: co naprawdę znaczy „jedno źródło prawdy”?
Jest zdanie, które słyszę bez przerwy: „Potrzebujemy jednego źródła prawdy”. Dobrze. Dla czego? Dla klienta? To za mało konkretne. Weźmy konto. Kto jest właścicielem nazwy klienta, adresu rozliczeniowego, limitu kredytowego, opiekuna handlowego, poziomu wsparcia, preferencji marketingowych? Te odpowiedzi nie wskazują na ten sam system. ERP może kontrolować nazwę prawną, adres rozliczeniowy i status kredytowy; Salesforce opiekuna relacji i atrybuty sprzedażowe; inna platforma zgody. Kiedy więc ktoś mówi mi „Salesforce to nasze jedno źródło prawdy o kliencie”, moje następne pytanie brzmi: która prawda?
Prawda należy do atrybutu
Dział zatytułowany „Prawda należy do atrybutu ”Pierwsza zasada danych podstawowych brzmi tak: autorytet przypisuje się do atrybutu, a nie do rekordu. Konto może mieszkać w Salesforce, a Salesforce nie musi być nadrzędny dla każdego pola na nim. Siedem pól na jednym rekordzie, dwa autorytety:
| Atrybut | System nadrzędny |
|---|---|
| Nazwa prawna, adres rozliczeniowy, identyfikator klienta w ERP, limit kredytowy | ERP |
| Opiekun handlowy, flaga konta strategicznego, poziom obsługi | Salesforce |
Jeden rekord; prawda jest rozproszona. To normalne. „System ewidencji = Salesforce” tego nie opisuje. Opisuje to model autorytetu.
Tworzone, edytowane, wskazywane i jak szybko?
Dział zatytułowany „Tworzone, edytowane, wskazywane i jak szybko? ”Kiedy uczę o danych podstawowych, wciąż wracam do tych samych pytań o każdy ważny element danych: gdzie jest tworzony, gdzie edytowany, gdzie wskazywany i jakie ma opóźnienie zmian? Szybko odsłaniają architekturę. (Pierwsze trzy poznaliśmy w rozdziale 4, przy porządkowaniu rodzajów danych; tutaj wykonują swoją prawdziwą pracę).
Weźmy zasób. Klient zamawia trzy rowery. Salesforce ma szansę sprzedaży i jej pozycje, a zamówienie trafia do ERP. ERP je realizuje i to tam zasoby są tworzone: trzy rowery, trzy numery seryjne, odesłane do Salesforce. Kilka miesięcy później klient dzwoni w sprawie jednego z nich, a wsparcie wskazuje zasób w zgłoszeniu. Teraz ktoś musi poprawić atrybut. Które z nich Salesforce może edytować, a które należą do ERP, który je utworzył? A kiedy ERP jeden z nich zmieni, jak szybko Salesforce musi się o tym dowiedzieć? Jeden zasób, cztery pytania, a odpowiedzi nie są takie same dla każdego pola.
Powiedzmy, że nazwa prawna jest tworzona w ERP i wskazywana w Salesforce, a handlowiec zauważa, że jest błędna. Czy powinien poprawić ją w Salesforce? Jeśli właścicielem pola jest ERP, zmiana kopii niczego nie naprawia. W najlepszym razie następna synchronizacja ją nadpisze; w najgorszym oba systemy się nie zgadzają i nikt nie wie, któremu ufać. Jeśli biznes chce, żeby handlowiec rozpoczął poprawkę, to co innego: Salesforce daje doświadczenie, wysyła prośbę do ERP, ERP wprowadza albo zatwierdza zmianę, a wartość nadrzędna wraca. To zupełnie inna architektura niż pozwolenie Salesforce na samodzielną edycję pola.
Opóźnienie też jest częścią prawdy. ERP zmienia status kredytowy klienta o 10:00; Salesforce synchronizuje go w nocy; o 15:00 handlowiec patrzy w Salesforce. Czy wartość jest błędna? Jest nieaktualna. Jeśli wartość zmienia się raz w roku, a dzień opóźnienia nic nie kosztuje, nocna synchronizacja wystarczy. Jeśli decyduje o tym, czy przyjąć dziś zamówienie za milion dolarów, nie wystarczy. Autorytet mówi, skąd pochodzi prawda; opóźnienie mówi, jak szybko inni muszą się dowiedzieć, że się zmieniła. To dwie osobne decyzje.
System ewidencji, zaangażowania, referencyjny
Dział zatytułowany „System ewidencji, zaangażowania, referencyjny ”Pomaga tu słownictwo z rozdziału 4. System ewidencji (system of record) utrzymuje wersję nadrzędną. System zaangażowania to miejsce, gdzie ludzie z nią pracują. System referencyjny dostarcza dane, których inny system używa, ale których nie jest właścicielem. Salesforce może być systemem zaangażowania dla relacji z klientem, a ERP pozostaje systemem ewidencji dla jego atrybutów prawnych i finansowych. To nie słabość architektury; to jest architektura. Błędem jest udawanie, że jeden system musi być właścicielem wszystkiego, żeby diagram wyglądał prościej.
Hybrydowy złoty rekord
Dział zatytułowany „Hybrydowy złoty rekord ”To zmienia znaczenie „złotego rekordu” (golden record). Rozdział 5 wprowadził tę ideę przy zatrzymywaniu złych danych; tutaj jest sercem projektu. Ludzie wyobrażają sobie jeden magiczny rekord, w którym każde pole jest zarządzane w jednym miejscu. Czasem taki jest projekt. W Salesforce częściej widzę hybrydę: część konta zarządzana gdzie indziej i kopiowana do środka (nazwa prawna, numer klienta w ERP, adres rozliczeniowy, status kredytowy) i część, która istnieje tylko dlatego, że potrzebuje jej Salesforce (opiekun handlowy, strategia szans sprzedaży, poziom obsługi, notatki o relacji). Pola ERP przychodzą, żeby ludzie mogli z nich korzystać. Pola Salesforce nigdy nie wracają, bo ERP ich nie potrzebuje. To całkowicie rozsądne, o ile wszyscy wiedzą, które są które.
Pokaż autorytet
Dział zatytułowany „Pokaż autorytet ”Dlatego zewnętrzny autorytet robię oczywistym w schemacie. Jeśli pole kontroluje SAP, dostaje prefiks: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. To ta sama idea co prefiks erp_ z rozdziału 4. Używaj nazwy systemu, gdy autorytet jest konkretny i stabilny, a prefiksu ogólnego, gdy znaczenie jest ważniejsze niż dzisiejszy dostawca. Chodzi o to, żeby pół roku później ktoś czytający model widział: to nie jest po prostu kolejne pole Salesforce; właścicielem tej wartości jest inny system. Nie każ ludziom odkrywać autorytetu na nowo przez inżynierię wsteczną integracji.
Zbuduj mapę autorytetów
Dział zatytułowany „Zbuduj mapę autorytetów ”Dla ważnych danych podstawowych chcę mieć mapę autorytetów: dla każdego kluczowego atrybutu kto go tworzy, kto jest właścicielem decyzji biznesowej, który system jest nadrzędny i kto albo co może go zmieniać. Cztery różne pytania:
| Atrybut | Tworzy | Właściciel biznesowy | System nadrzędny | Może zmieniać |
|---|---|---|---|---|
| Nazwa prawna | Finanse | Finanse | ERP | Proces finansowy |
| Limit kredytowy | Finanse | Finanse | ERP | Zespół kredytowy |
| Opiekun handlowy | Operacje sprzedaży | Sprzedaż | Salesforce | Kierownictwo sprzedaży |
| Poziom wsparcia | Operacje serwisu | Serwis | Salesforce | Kierownictwo serwisu |
| Zgoda | Klient | Prywatność | Platforma zgód | Klient, zatwierdzony proces |
Zwróć uwagę, że właściciel biznesowy i system nadrzędny to nie to samo. System nie jest właścicielem polityki; ludzie są. System przechowuje i egzekwuje wynik. To znowu rozdział 5: właściciele ustalają politykę; architekci ją egzekwują.
Jeden klient. Wiele atrybutów. Jeden autorytet dla każdego.
Autorytet zmienia się w cyklu życia
Dział zatytułowany „Autorytet zmienia się w cyklu życia ”Handlowiec poznaje potencjalnego klienta, o którym ERP nigdy nie słyszał, i tworzy konto w Salesforce. W tym momencie Salesforce jest nadrzędny dla nazwy, adresu, kontaktów i kwalifikacji. Potencjalny klient staje się klientem; ERP tworzy oficjalnego klienta i nadaje numer klienta, nazwę prawną, adres rozliczeniowy i kredyt. Autorytet się przesunął. Salesforce wcześniej się nie mylił; zmienił się cykl życia. To wzorzec z rozdziału 5, od tymczasowego do zarządzanego: przed konwersją Salesforce jest właścicielem potencjalnego klienta; po niej ERP jest właścicielem zarządzanych atrybutów, a Salesforce nadal jest właścicielem swoich. Pytanie „który system jest właścicielem konta?” jest więc słabe. Zapytaj: który system jest właścicielem tego atrybutu na tym etapie cyklu życia?
Kopia to nie autorytet
Dział zatytułowany „Kopia to nie autorytet ”Kopiujemy dane z ERP do Salesforce, bo ludzie ciągle ich potrzebują. To czyni z Salesforce wygodną lokalną kopię, a nie źródło nadrzędne, i architektura powinna się odpowiednio zachowywać: tylko do odczytu dla użytkowników, odświeżana przez integrację, opisana źródłem, zmieniana wyłącznie przez prośbę, sprawdzana przez uzgadnianie, gdy kopia się rozjedzie. Kopia jest przydatna. Autorytet się nie przesunął.
Zaufanie potrzebuje więcej niż wartości
Dział zatytułowany „Zaufanie potrzebuje więcej niż wartości ”„Adres rozliczeniowy: Main Street 123”. Czy można mu ufać? Chcę sygnałów zaufania: skąd pochodzi, kiedy ostatnio go potwierdzono, który system go dostarczył i kto albo co go ostatnio zmienił: człowiek, integracja, agent? Teraz ERP mówi Main Street 123, Salesforce mówi 125, a plik partnera mówi „Main St. 123, lokal 200”. Który jest dobry? Nie odpowiadaj „użyj najnowszego”. Może. Ale „najnowszy” to sam w sobie reguła, która zakłada, że ten, kto zmienił coś ostatni, zasługuje na wygraną. To może być prawda albo katastrofa. Moduł 3 się tym zajmuje. Zaufanie bierze się z autorytetu i pochodzenia, a nie ze znalezienia wypełnionego pola.
Steve Trucking: czyja to prawda?
Dział zatytułowany „Steve Trucking: czyja to prawda? ”Partner detaliczny wysyła dostawę, a w tej jednej transakcji kryje się kilka prawd. Numer zamówienia partnera należy do partnera; Steve Trucking przechowuje go, żeby dopasowywać aktualizacje, ale nie staje się jego źródłem nadrzędnym. Status dostawy (na miejscu, dostarczona, zainstalowana, wyjątek) należy do Steve Trucking; partner go otrzymuje, ale otrzymanie statusu nie czyni partnera nadrzędnym dla tego, co wydarzyło się na ciężarówce. A odbiorca to klient partnera. Partner podaje imię i nazwisko, adres, telefon i uwagi do dostawy, bo Steve Trucking potrzebuje ich, żeby dostarczyć. To nie czyni Steve Trucking źródłem nadrzędnym tożsamości tej osoby, a to rozróżnienie decyduje o projekcie odbiorcy w punkcie kontrolnym.
Jedna dostawa, dwa autorytety.
To, gdzie mieszkają dane, i to, kto jest właścicielem ich prawdy, to różne pytania. Salesforce może przechowywać numer klienta z ERP, nie będąc jego właścicielem; Snowflake może przechowywać status dostawy, nie będąc jego operacyjnym źródłem nadrzędnym; platforma danych klientów może ujednolicać tożsamości, nie będąc właścicielem każdego atrybutu. Agent może czytać wszystkie trzy, a to na pewno nie pozwala agentowi decydować, co jest prawdą.
Poza egzaminem: co zmienia AI. Agenci zamieniają autorytet atrybutu w regułę wykonania. Człowiek widzi błędny adres rozliczeniowy i wie: „to pochodzi z SAP; nie zmienia się tego tutaj”. Agent, któremu każe się „zaktualizować adres rozliczeniowy klienta”, nie będzie tego wiedział, jeśli tego nie zaprojektujemy. Potrzebuje tej samej mapy autorytetów, którą ma architekt: dostęp do pola nie czyni tego pola właściwym miejscem zapisu.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Który system jest nadrzędny dla każdego ważnego atrybutu, zamiast jednego systemu dla całego rekordu.
- Gdzie każdy atrybut jest tworzony, edytowany i wskazywany oraz jak szybko muszą się rozchodzić jego zmiany.
- Kto ustala politykę dla każdego atrybutu i którzy ludzie, integracje albo agenci mogą go zmieniać.
- Jak zewnętrzny autorytet jest widoczny w modelu: prefiksy nazw, uprawnienia, zachowanie integracji.
- Jak autorytet przesuwa się w cyklu życia, na przykład gdy potencjalny klient staje się klientem zarządzanym przez ERP.
Jedno źródło prawdy nie oznacza jednego orgu, jednego ERP, jednej platformy MDM ani jednego gigantycznego rekordu. Oznacza, że dla każdego zarządzanego elementu informacji architektura potrafi powiedzieć, gdzie jest wartość nadrzędna, a każdy inny system wie, jak się z tego powodu zachować. To nie jest jedno źródło prawdy. To architektura prawdy.
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.