Hierarchie i dane dwukierunkowe

🌐 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)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 5 z 6 w rozdziale Dane podstawowe i tożsamość, rozdziale 6 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Mapa to nie decyzja · Dalej: Punkt kontrolny 1: Steve Trucking

Pytanie, na które odpowiada ten moduł: jak zarządzać danymi, które utrzymuje więcej niż jeden system?

Łatwa architektura: ERP jest właścicielem klienta, Salesforce dostaje kopię, gotowe. Prawdziwe przedsiębiorstwa nie są tak schludne. ERP jest właścicielem klienta w sensie prawnym, a Salesforce relacji handlowej; jeden dział żyje w SAP, przejęty w innym ERP; potencjalni klienci istnieją tylko w Salesforce. Potem ktoś chce, żeby użytkownicy Salesforce aktualizowali pole kontrolowane przez ERP, i strzałki zaczynają wskazywać w obie strony. Jak mówię, ucząc tego: „Najtrudniejsze są te dwukierunkowe”. Nie dlatego, że wysyłanie danych w obie strony jest technicznie trudne, ale dlatego, że gdy oba systemy biorą udział w zmianie, trzeba być niezwykle precyzyjnym co do autorytetu.

Dane dwukierunkowe to nie dwa źródła nadrzędne

ERP jest właścicielem adresu rozliczeniowego, kopiowanego do Salesforce. Handlowiec dowiaduje się od klienta, że adres się zmienił, a biznes chce, żeby mógł go zaktualizować bez wychodzenia z Salesforce. Rozsądne. Teraz dane płyną ERP → Salesforce i Salesforce → ERP. Czy Salesforce jest teraz współwłaścicielem adresu rozliczeniowego? Nie. Kierunek integracji nie decyduje o autorytecie. Handlowiec nie zmienia kopii w Salesforce. Architektonicznie prosi o zmianę wartości nadrzędnej. Nie zmieniasz pola w ERP; prosisz o jego zmianę. Salesforce jest interfejsem; ERP nadal jest źródłem nadrzędnym.

To zmienia projekt. Gdyby właścicielem pola był Salesforce, zapisz i gotowe. Jeśli właścicielem jest ERP, „zapisz” znaczy, że Salesforce wysyła proponowany adres, ERP go weryfikuje i przyjmuje, aktualizuje swoje dane nadrzędne i odsyła wartość nadrzędną. Dopiero wtedy zarządzana wartość się zmieniła: prośba → weryfikacja → przyjęcie → publikacja, a nie „zaktualizuj oba systemy i miej nadzieję, że pozostaną zsynchronizowane”.

Click to enlarge

Integracja dwukierunkowa nie tworzy dwukierunkowego autorytetu.

Gdy źródło nadrzędne mówi „nie”

ERP odrzuca zmianę: klient jest nieaktywny, adres narusza regułę ERP, użytkownik nie może zmieniać adresów prawnych, ERP nie działa albo ktoś w międzyczasie zmienił klienta. Jeśli Salesforce już pokazał nowy adres, mamy dwie prawdy, a moduł 1 już nam powiedział, która wygrywa: ta z ERP. Architektura potrzebuje więc stanu zgłoszone, jeszcze nie przyjęte: osobnej proponowanej wartości, flagi „zmiana w toku” albo czekania na potwierdzenie przed jej pokazaniem. Mechanizm zależy od przypadku użycia. Zasada nie: nigdy nie pozwól, żeby odrzucona prośba zamieniła się w konkurencyjną prawdę.

Pętle i kolizje

Oto klasyka. ERP aktualizuje Salesforce; integracja Salesforce widzi zmianę i wysyła ją do ERP; ERP widzi aktualizację i odsyła ją z powrotem. Powstała bardzo kosztowna pętla. Dobry projekt dwukierunkowy wie, gdzie zaczęła się zmiana, czy źródło nadrzędne ją przyjęło i czy to nowa zmiana biznesowa, czy tylko echo już przetworzonej: identyfikatory źródła, znaczniki czasu, metadane integracji, przetwarzanie idempotentne. Rozdział o integracji wchodzi w to głęboko. Zasada danych podstawowych jest prosta: wiedz, czy zmianę inicjujesz, czy tylko ją odbijasz.

Potem kolizje. Jedną poznaliśmy w rozdziale 5: handlowiec prosi o Steve’s Plumbing LLC, podczas gdy ktoś w ERP wpisuje Steve’s Plumbing L.L.C. (Chroń zarządzany rekord). Oto kolejna. Salesforce proponuje Main Street 125; niemal w tej samej chwili użytkownik ERP zmienia adres na 130. Co wygrywa? Nie ma uniwersalnej odpowiedzi technicznej. Może zawsze wygrywa ERP, bo jest właścicielem pola; może prośba z Salesforce trafia do kolejki przeglądu; może wygrywa późniejsza przyjęta zmiana; może ERP odrzuca każdą aktualizację, której wartość wyjściowa się zmieniła. To współbieżność, ale pod nią leży decyzja o autorytecie, a żaden wzorzec integracji cię nie uratuje, jeśli nikt nie zdecydował, kto może dokonać nadrzędnej zmiany.

A pojedyncze pole to prosty przypadek. Adres to ulica, miasto, kod pocztowy. Salesforce wysyła nową ulicę, a ERP właśnie zmienił miasto. Przepuszczasz samą ulicę? Czy traktujesz adres jako jedną transakcję, w której pola idą wszystkie razem albo żadne, i odrzucasz całą zmianę? Zdecyduj, które pola podróżują jako grupa, przed pierwszą kolizją, a nie po niej.

Kiedy widzę integrację dwukierunkową, pytam: co się dzieje, gdy obie strony zmieniają te same dane? Jeśli odpowiedź brzmi „pewnie się nie zdarzy”, nie skończyliśmy. Co wygrywa, czy odrzucamy, kolejkujemy, porównujemy wersje, przeglądamy? Czy pole w ogóle powinno być edytowalne w obu miejscach? Czasem najlepszy projekt dwukierunkowy usuwa jeden kierunek dla danego atrybutu: Salesforce może prosić; tylko ERP publikuje przyjętą wartość. Dane nadal płyną w obie strony, ale tylko jeden system zarządza polem. Ta różnica jest wszystkim.

Hierarchie to też dane podstawowe

Relacje też mogą być danymi podstawowymi. Globalna spółka matka z regionami Ameryki Północnej i Europy, każdy ze spółkami zależnymi w krajach: sama hierarchia niesie znaczenie. Kto jest rodzicem? Która spółka zależna jest pod którym podmiotem prawnym? Które konta sumują się do klienta globalnego? To napędza raportowanie, terytoria, ceny, umowy, ekspozycję kredytową, serwis, dostęp do danych i analitykę. Hierarchia może mieć takie samo znaczenie jak rekordy w niej i potrzebuje takiego samego zarządzania. (Egzamin wymienia zarządzanie hierarchiami; łatwo o tym zapomnieć).

W Salesforce hierarchie kont buduje się polem Konto nadrzędne (Parent Account). Widok hierarchii w Lightning pokazuje do 2000 kont, i to tylko te, które użytkownik może widzieć; konta osób nie są obsługiwane w hierarchii; a Lokalizacja konta (Account Site) odróżnia lokalizacje firmy (Considerations for Using Account Hierarchy (opens in a new tab), po angielsku). Ale pole Konto nadrzędne nie odpowiada na pytanie architektoniczne: kto jest właścicielem hierarchii?

Wiedza egzaminacyjna. Znaj podstawy hierarchii kont: buduje się ją polem konto nadrzędne (Parent Account); widok Lightning pokazuje do 2000 kont, tylko te, które użytkownik może widzieć; konta osób nie są obsługiwane; a lokalizacja konta (Account Site) odróżnia placówki firmy.

Jedna hierarchia, kilka źródeł nadrzędnych

Z mojego doświadczenia hierarchie mają podzielony autorytet. Podmioty z Ameryki Północnej pochodzą z SAP, europejskie z innego ERP, nowi potencjalni klienci są budowani w Salesforce, a przejęta spółka zależna jeszcze nie przeszła migracji. Kto jest właścicielem hierarchii? To zależy od gałęzi. Każdy ERP kontroluje swoją gałąź; Salesforce kontroluje relacje potencjalnych klientów, dopóki nie zostaną skonwertowani. To uprawniona architektura, o ile wszyscy wiedzą, gdzie są granice. Decyduj gałąź po gałęzi.

Click to enlarge

Autorytet w hierarchii można przypisywać gałąź po gałęzi.

Nie pozwól więc, żeby pole Konto nadrzędne ukrywało autorytet. Użytkownik w Salesforce przenosi spółkę zależną pod innego rodzica. Technicznie trywialne. Architektonicznie: czy właśnie zmienił strukturę prawną firmy? Jeśli tą gałęzią zarządza ERP, raczej nie, więc Salesforce powinien to zablokować albo zamienić w prośbę o zmianę. A może Salesforce w uprawniony sposób utrzymuje hierarchię handlową, a ERP prawną. Wtedy może nie powinny być tą samą relacją.

Firma może mieć kilka prawidłowych hierarchii: prawną, rozliczeniową, sprzedażową, serwisową, geograficzną. Globalna spółka matka podpisuje umowę, regiony mają własny serwis, rozliczenia idą przez wspólny podmiot finansowy, sprzedaż zarządza regionami. Która hierarchia jest prawdziwa? Wszystkie; odpowiadają na różne pytania. Błędem jest założenie, że musi być jedna. Powinien być jasny autorytet dla każdego rodzaju relacji: zasada atrybutu z modułu 1 zastosowana do relacji.

I nie każda relacja rodzic-dziecko to dane podstawowe. Zgrupowanie dzisiejszych dostaw na jednej trasie to relacja, ale transakcyjna, zdarzenie operacyjne. Hierarchia klientów opisuje trwałą relację biznesową. W modelu obie wyglądają jak rodzic-dziecko; nie mają wspólnego cyklu życia. Zapytaj, co relacja znaczy i jak długo to znaczenie trwa.

Jeden klient, dwa ERP-y

Kiedy tego uczę, pytam salę: kto pracował z klientem, który ma jeden Salesforce i więcej niż jeden ERP? Ręce idą w górę za każdym razem. Zapytaj dlaczego, a okaże się, że ERP-y są podzielone regionalnie (jeden dla Ameryki Północnej, jeden dla Europy), funkcjonalnie (firma hydrauliczna kupuje firmę elektryczną i każda zachowuje własny ERP) albo po prostu historycznie: biznes został przejęty i nikt go jeszcze nie zmigrował.

Weźmy Steve’s Plumbing jako klienta. Prowadzi działalność w Ameryce Północnej, więc północnoamerykański ERP ma dla niego rekord klienta. Potem otwiera biuro w Monachium, a europejski ERP tworzy własny rekord klienta, z własnym numerem klienta. Ta sama firma, dwa rekordy, dwa identyfikatory. Jak przedstawić to w jednym orgu Salesforce? Widziałem trzy sposoby.

Hierarchia kont. Steve’s Plumbing jest kontem nadrzędnym, a Steve’s Plumbing North America i Steve’s Plumbing Europe to konta podrzędne, każde odpowiadające rekordowi z jednego ERP. Haczyk: konta podrzędne to już nie do końca Steve’s Plumbing. To Steve’s Plumbing prowadzący działalność w danym regionie, a jak właśnie widzieliśmy, hierarchia niesie znaczenie.

Konta równorzędne. Dwa konta obok siebie, każde z polem mówiącym, do którego ERP należy: kod spółki, region. Nic nie jest ukryte. Koszt wychodzi w raportowaniu: żeby zobaczyć Steve’s Plumbing na całym świecie, potrzebujesz czegoś, co mówi, że te dwa konta to ta sama firma.

Jedno konto z rekordem podrzędnym dla każdego ERP. Jeden Steve’s Plumbing i obiekt podrzędny z rekordem dla każdego ERP, przechowującym identyfikator klienta z tego ERP. Dwa ERP-y albo dziesięć. Handlowcy widzą jednego klienta i składają jedno zamówienie; za kulisami przepływy decydują, do którego ERP idzie każda pozycja: prace elektryczne do ERP elektrycznego, hydrauliczne do ERP hydraulicznego. Ale teraz musisz zdecydować, który ERP jest główny dla wspólnych wartości, takich jak nazwa i adres, i co się dzieje, gdy klient istnieje w jednym ERP, a w drugim nie.

Click to enlarge

Jeden klient, dwa ERP-y: trzy sposoby przedstawienia go w Salesforce.

Zapytaj, jak synchronizują swoje ERP-y

Który więc wybrać? Najpierw: ile struktury ERP powinni widzieć handlowcy? Jeśli zawsze wiedzieli, że Ameryka Północna i Europa to osobne biznesy, bo logują się do jednego albo drugiego ERP, nie ukrywaj tego przed nimi. Przenieś tę strukturę do Salesforce jako konta równorzędne. Jeśli biznes chce mieć przed działem sprzedaży jeden Steve’s Plumbing, patrzysz na jedno konto z rekordem podrzędnym dla każdego ERP.

Potem pytanie, które naprawdę rozstrzyga, i nie rozstrzyga się go w Salesforce. Pytam klienta: jak utrzymujecie synchronizację tych dwóch rekordów między waszymi ERP-ami? Nie chodzi o rzeczy lokalne dla każdego ERP, jak saldo; to dane transakcyjne. Mam na myśli dane podstawowe: nazwę prawną, adresy. Jeśli mają zespół, który utrzymuje oba ERP-y w synchronizacji, możemy połączyć je w jedno konto. Jeśli nie potrafią utrzymać synchronizacji we własnych ERP-ach, jak mogą oczekiwać, że my utrzymamy ją w Salesforce? Wtedy to konta równorzędne albo hierarchia.

Pamiętaj, czym jest ERP. To ogromne systemy, których wdrożenie zajmuje lata, i mają własny sposób zarządzania danymi podstawowymi. Salesforce nie będzie nimi sterował. Nie kontrolujemy ERP-ów. Kontrolujemy to, jak reprezentujemy je w Salesforce.

MDM pośrodku

Niektórzy klienci rozwiązali to, zanim się pojawiliśmy. Duża firma, wiele lat na rynku, kilka ERP-ów: trafili na ten problem na długo przed Salesforce i postawili pośrodku dedykowany produkt MDM, który pośredniczy między ERP-ami. To MDM we współistnieniu albo scentralizowane z modułu 2. Teraz Salesforce nie podłącza się do każdego ERP. Wskazuje jedno miejsce, hub MDM, i dostaje jedną reprezentację klienta. Nie spodziewaj się jednak, że często na to trafisz. To duże wdrożenia same w sobie; przez wszystkie lata pracowałem z takim tylko dwa czy trzy razy. A nawet z hubem może nadal być potrzebny ten obiekt podrzędny, żeby każde zamówienie wiedziało, do którego ERP idzie.

Click to enlarge

MDM pośrodku: Salesforce wskazuje jedno miejsce.

Steve Trucking: czyja hierarchia?

Partner detaliczny ma własną strukturę: spółkę matkę, regionalne oddziały, centra dystrybucyjne, sklepy. Czy Steve Trucking jest właścicielem tej hierarchii? Nie; partner jest autorytetem dla własnej organizacji. Ale Steve Trucking może potrzebować własnego, handlowego widoku tych samych lokalizacji, dla umów, opieki nad kontem, serwisu i raportowania, na przykład konta podrzędnego dla każdego CD pod partnerem. Dwie uprawnione hierarchie, dwa autorytety. Nazwij je i nie udawaj, że jedno drzewo odwzorowuje każdą relację.

Pokaż granice

Zawsze gdy autorytet jest podzielony, chcę, żeby granica była widoczna: nazewnictwo pól, metadane rekordów, identyfikatory systemów źródłowych, uprawnienia, zachowanie integracji, dokumentacja. Nie chcę, żeby programista czytał pięć integracji, żeby odkryć, że „te wartości Konta nadrzędnego pochodzą z SAP, oprócz potencjalnych klientów, oprócz Europy”. To nie jest model autorytetu, który da się utrzymać. Jeśli hierarchia ma podzielony autorytet, udokumentuj podział. Jeśli autorytet zmienia się przy konwersji, udokumentuj zmianę. Jeśli Salesforce może prosić o zmianę, ale nie może jej wprowadzić, zrób to oczywistym w doświadczeniu użytkownika.

W Salesforce zaczyna się to od jednego pola. Musi istnieć pole, które jasno mówi, że to dane podstawowe: klucz z ERP albo flaga „to dane podstawowe”. Od tego pola uzależnij możliwość edycji pól, a nie od typu rekordu; z Dynamic Forms nie potrzebujesz już typu rekordu, żeby pokazać pola z ERP tylko do odczytu (rozdział 5, Typ rekordu dla każdego przepływu). Możesz pozwolić na tworzenie rekordów poza źródłem nadrzędnym, ale pilnuj edycji.

Poza egzaminem: co zmienia AI. Klient mówi agentowi: „zmień nasz adres rozliczeniowy na Main Street 125”. Pole jest tuż przed nim w Salesforce. Czy agent powinien je zaktualizować? Nie, jeśli właścicielem jest ERP. Agent potrzebuje uprawnienia do zapisu, a nie tylko dostępu do pola: jego akcja powinna kodować zatwierdzoną ścieżkę, czyli zgłoszenie prośby o zmianę i odpowiedź „Zmiana została przekazana do realizacji”, a nie fałszywe „Twój adres rozliczeniowy został zaktualizowany”.

Co tu decyduje architekt

• Czy edycja w Salesforce zmienia dane nadrzędne, czy prosi o zmianę system, który jest ich właścicielem.
• Jak przepływy dwukierunkowe odróżniają zmiany inicjowane od ech i obsługują odrzucenia, kolizje, opóźnienia i awarie.
• Kto jest właścicielem każdej hierarchii, w razie potrzeby gałąź po gałęzi.
• Dla jednego klienta trzymanego w kilku ERP: hierarchia, konta równorzędne albo jedno konto z rekordem podrzędnym dla każdego ERP, a decyduje o tym to, jak dobrze klient utrzymuje synchronizację swoich ERP-ów.
• Czy konkurujące hierarchie to w rzeczywistości różne uprawnione relacje: prawna, rozliczeniowa, sprzedażowa, serwisowa.
• Jak granice autorytetu i zatwierdzone ścieżki zapisu są pokazywane użytkownikom, integracjom, programistom i agentom.

Dzielony autorytet to nie problem. Problemem jest niejasny autorytet. Kilka ERP może zarządzać różnymi gałęziami, Salesforce może zarządzać częścią atrybutów i prosić o zmiany innych, a kilka hierarchii może opisywać jedno przedsiębiorstwo. Wszystko to działa, o ile dla każdego ważnego atrybutu i relacji potrafisz powiedzieć, kto jest właścicielem, kto może zmieniać, gdzie dokonuje się nadrzędnej zmiany i co się dzieje, gdy systemy się nie zgadzają. Jeśli nie potrafisz, kolejna dwukierunkowa strzałka na diagramie tego nie naprawi.

Do zgłębienia

• Pomoc Salesforce, Considerations for Using Account Hierarchy (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.