Hierarchie a obousměrná data

🌐 K dispozici také v 29 jazycích

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 · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 5 z 6 kapitoly Kmenová data a identita, kapitoly 6 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Mapa není rozhodnutí · Další: Kontrolní bod 1: Steve Trucking

Otázka, na kterou tento modul odpovídá: Jak spravovat data, která udržuje víc než jeden systém?

Snadná architektura: zákazníka vlastní ERP, Salesforce dostane kopii, hotovo. Skutečné podniky tak čisté nejsou. ERP vlastní právního zákazníka a Salesforce obchodní vztah; jedna divize žije v SAP, koupená divize v jiném ERP; potenciální zákazníci existují jen v Salesforce. Pak někdo chce, aby uživatelé Salesforce aktualizovali pole řízené ERP, a šipky začnou ukazovat oběma směry. Jak říkám, když to učím: „Nejtěžší jsou obousměrné toky.“ Ne proto, že by posílání dat oběma směry bylo technicky těžké, ale protože jakmile se na změně podílejí oba systémy, musíte být nesmírně přesní v autoritě.

Obousměrná data neznamenají dva mastery

ERP vlastní fakturační adresu, zkopírovanou do Salesforce. Obchodník se od zákazníka dozví, že se změnila, a byznys chce, aby ji aktualizoval, aniž by opustil Salesforce. Rozumné. Teď data proudí ERP → Salesforce i Salesforce → ERP. Spoluvlastní teď Salesforce fakturační adresu? Ne. Směr integrace o autoritě nerozhoduje. Obchodník nemění kopii v Salesforce. Architektonicky žádá o změnu autoritativní hodnoty. Neměníte pole ERP; žádáte o jeho změnu. Salesforce je rozhraní; ERP je pořád master.

To mění návrh. Kdyby pole vlastnil Salesforce, uložit a hotovo. Pokud ho vlastní ERP, „uložit“ znamená, že Salesforce pošle navrženou adresu, ERP ji ověří a přijme, aktualizuje svůj master a pošle autoritativní hodnotu zpět. Teprve pak se řízená hodnota změnila: požadavek → ověření → přijetí → zveřejnění, ne „aktualizovat oba systémy a doufat, že zůstanou v souladu“.

Kliknutím zvětšíte

Obousměrná integrace nevytváří obousměrnou autoritu.

Když master řekne ne

ERP změnu odmítne: zákazník je neaktivní, adresa porušuje pravidlo ERP, uživatel nesmí měnit právní adresy, ERP nejede, nebo mezitím zákazníka změnil někdo jiný. Pokud Salesforce už novou adresu ukázal, máme teď dvě pravdy, a modul 1 nám už řekl, která vyhrává: ta z ERP. Architektura proto potřebuje stav vyžádáno, zatím nepřijato: samostatnou navrženou hodnotu, příznak „čekající změna“ nebo čekání na potvrzení, než se hodnota ukáže. Mechanismus závisí na případu použití. Pravidlo ne: nikdy nenechte odmítnutý požadavek proměnit se v konkurenční pravdu.

Smyčky a kolize

Tady je klasika. ERP aktualizuje Salesforce; integrace Salesforce vidí změnu a pošle ji do ERP; ERP vidí aktualizaci a pošle ji zpátky. Postavili jste velmi drahou smyčku. Dobrý obousměrný návrh ví, kde změna začala, jestli ji master přijal a jestli jde o novou obchodní změnu, nebo jen ozvěnu té, která už byla zpracovaná: zdrojové identifikátory, časová razítka, integrační metadata, idempotentní zpracování. Kapitola o integraci jde do hloubky. Princip kmenových dat je jednoduchý: vězte, jestli změnu zahajujete, nebo jen odrážíte.

Pak kolize. Jednu jste potkali v kapitole 5: obchodník žádá o Steve’s Plumbing LLC, zatímco někdo v ERP píše Steve’s Plumbing L.L.C. (Chraňte řízený záznam). Tady je další. Salesforce navrhne 125 Main Street; téměř ve stejnou chvíli ji uživatel ERP změní na 130. Co vyhraje? Univerzální technická odpověď neexistuje. Možná vždycky vyhrává ERP, protože pole vlastní; možná jde požadavek ze Salesforce do fronty k revizi; možná vyhrává později přijatá změna; možná ERP odmítne každou aktualizaci, jejíž výchozí hodnota se změnila. To je souběžnost, ale pod ní je rozhodnutí o autoritě a žádný integrační vzor vás nezachrání, pokud nikdo nerozhodl, kdo smí autoritativní změnu provést.

A jedno pole je ten jednoduchý případ. Adresa je ulice, město, PSČ. Salesforce pošle novou ulici, zatímco ERP právě změnilo město. Pustíte ulici samotnou? Nebo budete s adresou zacházet jako s jednou transakcí, takže pole projdou všechna dohromady, nebo žádné, a celou změnu odmítnete? Rozhodněte, která pole cestují jako skupina, před první kolizí, ne po ní.

Kdykoli vidím obousměrnou integraci, ptám se: co se stane, když obě strany změní stejná data? Pokud zní odpověď „to se asi nestane“, nejsme hotoví. Co vyhraje, odmítáme, řadíme do fronty, porovnáváme verze, revidujeme? Má být pole vůbec upravitelné na obou místech? Někdy nejlepší obousměrný návrh odstraní u daného atributu jeden směr: Salesforce může žádat; přijatou hodnotu zveřejňuje jen ERP. Data se pořád přesouvají oběma směry, ale pole spravuje jen jeden systém. V tom rozdílu je všechno.

I hierarchie jsou kmenová data

Kmenovými daty mohou být i vztahy. Globální mateřská společnost se severoamerickým a evropským regionem, každý s dceřinými společnostmi v zemích: význam nese sama hierarchie. Kdo je mateřská společnost? Která dceřiná společnost spadá pod kterou právnickou osobu? Které účty se sčítají pod globálního zákazníka? To řídí sestavy, teritoria, ceny, smlouvy, úvěrovou expozici, servis, přístup k datům i analytiku. Hierarchie může být stejně důležitá jako záznamy v ní a potřebuje stejné řízení. (Zkouška správu hierarchií jmenuje; snadno se na ni zapomene.)

V Salesforce se hierarchie účtů stavějí polem Parent Account (nadřazený účet). Zobrazení hierarchie v Lightning ukazuje až 2 000 účtů, a jen ty, které uživatel smí vidět; osobní účty v hierarchii nejsou podporované; a Account Site rozlišuje pobočky firmy (Considerations for Using Account Hierarchy (otevře se v nové kartě)). Pole Parent Account ale neodpovídá na architektonickou otázku: kdo vlastní hierarchii?

Ke zkoušce. Znejte základy hierarchie účtů: staví se polem Parent Account; zobrazení v Lightning ukazuje až 2 000 účtů, jen ty, které uživatel vidí; osobní účty nejsou podporované; a Account Site rozlišuje pobočky firmy.

Jedna hierarchie, několik masterů

Podle mých zkušeností mají hierarchie rozdělenou autoritu. Severoamerické subjekty přicházejí ze SAP, evropské z jiného ERP, noví potenciální zákazníci se stavějí v Salesforce a koupená dceřiná společnost ještě nebyla migrovaná. Kdo vlastní hierarchii? Záleží na větvi. Každé ERP řídí svou větev; Salesforce řídí vztahy potenciálních zákazníků, dokud nekonvertují. To je legitimní architektura, pokud všichni vědí, kde jsou hranice. Rozhodujte po větvích.

Kliknutím zvětšíte

Autoritu nad hierarchií lze přidělovat větev po větvi.

Nenechte tedy pole Parent Account autoritu skrýt. Uživatel v Salesforce přesune dceřinou společnost pod jiného rodiče. Technicky triviální. Architektonicky: změnil právě právní strukturu firmy? Pokud tu větev spravuje ERP, nejspíš ne, takže by to Salesforce měl zablokovat, nebo z toho udělat požadavek na změnu. Nebo si možná Salesforce legitimně drží obchodní hierarchii, zatímco ERP drží tu právní. Pak by to možná vůbec neměl být stejný vztah.

Firma může mít několik platných hierarchií: právní, fakturační, prodejní, servisní, geografickou. Globální mateřská společnost podepisuje smlouvu, regiony dostávají servis samostatně, fakturace běží přes sdílený finanční subjekt, obchod řídí podle regionů. Která hierarchie je ta pravá? Všechny; odpovídají na různé otázky. Chybou je předpokládat, že musí být jedna. Pro každý druh vztahu by měla existovat jasná autorita: princip atributů z modulu 1 použitý na vztahy.

A ne každý vztah nadřazený-podřízený jsou kmenová data. Seskupení dnešních doručení na jednu trasu je vztah, ale transakční, provozní událost. Hierarchie zákazníka popisuje trvalý obchodní vztah. Obojí v modelu vypadá jako nadřazený-podřízený; nesdílejí ale životní cyklus. Ptejte se, co vztah znamená a jak dlouho ten význam vydrží.

Jeden zákazník, dvě ERP

Když tohle učím, ptám se místnosti: kdo pracoval s klientem, který má jeden Salesforce a víc než jedno ERP? Ruce se zvednou pokaždé. Zeptejte se proč a ukáže se, že ERP jsou rozdělená regionálně (jedno pro Severní Ameriku, jedno pro Evropu), funkčně (instalatérská firma koupí elektrikářskou a každá si nechá své ERP), nebo prostě historicky: byznys byl koupen a nikdo ho ještě nemigroval.

Vezměte si jako zákazníka Steve’s Plumbing. Podniká v Severní Americe, takže pro ni má záznam zákazníka severoamerické ERP. Pak otevře kancelář v Mnichově a evropské ERP vytvoří vlastní záznam zákazníka s vlastním zákaznickým číslem. Stejná firma, dva záznamy, dvě ID. Jak to reprezentovat v jednom orgu Salesforce? Viděl jsem tři způsoby.

Hierarchie účtů. Steve’s Plumbing je nadřazený účet a Steve’s Plumbing North America a Steve’s Plumbing Europe jsou podřízené účty, každý zastupuje záznam jednoho ERP. Háček: podřízené účty už nejsou doopravdy Steve’s Plumbing. Jsou to Steve’s Plumbing podnikající v nějakém regionu, a jak jsme právě viděli, hierarchie nese význam.

Rovnocenné účty. Dva účty vedle sebe, každý s polem, které říká, ke kterému ERP patří: kód společnosti, region. Nic není skryté. Cena se projeví v sestavách: abyste viděli Steve’s Plumbing po celém světě, potřebujete něco, co říká, že tyto dva účty jsou stejná firma.

Jeden účet s podřízeným záznamem pro každé ERP. Jeden Steve’s Plumbing a podřízený objekt se záznamem pro každé ERP, který drží zákaznické ID daného ERP. Dvě ERP, nebo deset. Obchodníci vidí jednoho zákazníka a zadávají jednu objednávku; v pozadí flow rozhodují, do kterého ERP jde který řádek: elektrikářské práce do elektrikářského ERP, instalatérské do instalatérského. Teď ale musíte rozhodnout, které ERP je primární pro sdílené hodnoty, jako je název a adresa, a co se stane, když zákazník existuje v jednom ERP a v druhém ne.

Kliknutím zvětšíte

Jeden zákazník, dvě ERP: tři způsoby, jak ho reprezentovat v Salesforce.

Zeptejte se, jak udržují ERP v souladu

Který tedy? Zaprvé: kolik ze struktury ERP mají obchodníci vidět? Pokud vždycky věděli, že Severní Amerika a Evropa jsou samostatné byznysy, protože se přihlašují do jednoho nebo druhého ERP, neskrývejte to před nimi. Přeneste tu strukturu do Salesforce jako rovnocenné účty. Pokud byznys chce mít před obchodem jednu Steve’s Plumbing, díváte se na jeden účet s podřízeným záznamem pro každé ERP.

Pak otázka, která to doopravdy rozhoduje, a nerozhoduje se v Salesforce. Ptám se klienta: jak udržujete tyto dva záznamy v souladu mezi svými ERP? Ne věci, které jsou pro každé ERP lokální, jako zůstatek; to je transakční. Myslím kmenová data: oficiální název, adresy. Pokud mají tým, který obě ERP udržuje v souladu, můžeme je spojit do jednoho účtu. Pokud je nedokážou udržet v souladu ve vlastních ERP, jak mohou čekat, že je v souladu udržíme my v Salesforce? Pak jsou to rovnocenné účty, nebo hierarchie.

Pamatujte, co je ERP. Jsou to obrovské systémy, jejichž zavedení trvá roky, a přicházejí s vlastním způsobem správy kmenových dat. Salesforce je řídit nebude. ERP nemáme pod kontrolou. Pod kontrolou máme, jak je reprezentujeme v Salesforce.

MDM uprostřed

Někteří klienti už tohle vyřešili, než přijdeme. Velká firma, mnoho let v byznysu, několik ERP: na tento problém narazili dávno před Salesforce a dali doprostřed vyhrazený produkt MDM, který mezi ERP zprostředkovává. To je koexistence nebo centralizovaná MDM z modulu 2. Teď se Salesforce nemusí napojovat na každé ERP. Ukazuje na jedno místo, hub MDM, a dostává jedinou reprezentaci zákazníka. Nečekejte ale, že ho potkáte často. Jsou to samy o sobě velké implementace; za všechna ta léta jsem s jedním pracoval jen dvakrát nebo třikrát. A i s hubem můžete pořád potřebovat ten podřízený objekt, aby každá objednávka věděla, do kterého ERP jde.

Kliknutím zvětšíte

MDM uprostřed: Salesforce ukazuje na jedno místo.

Steve Trucking: čí hierarchie?

Maloobchodní partner má vlastní strukturu: mateřskou společnost, regionální divize, distribuční centra, prodejny. Vlastní Steve Trucking tuto hierarchii? Ne; autoritou pro svou vlastní organizaci je partner. Steve Trucking ale může potřebovat vlastní obchodní pohled na tatáž místa, kvůli smlouvám, péči o účet, servisu a sestavám, třeba podřízený účet pro každé DC pod partnerem. Dvě legitimní hierarchie, dvě autority. Pojmenujte je a nepředstírejte, že jeden strom reprezentuje každý vztah.

Udělejte hranice viditelnými

Kdykoli je autorita rozdělená, chci, aby byla hranice vidět: pojmenování polí, metadata záznamů, identifikátory zdrojových systémů, oprávnění, chování integrací, dokumentace. Nechci vývojáře, který čte pět integrací, aby zjistil, že „tyto hodnoty Parent Account přicházejí ze SAP, kromě potenciálních zákazníků, kromě Evropy“. To není udržovatelný model autorit. Pokud má hierarchie rozdělenou autoritu, zdokumentujte rozdělení. Pokud se autorita mění při konverzi, zdokumentujte změnu. Pokud Salesforce může o změnu žádat, ale nemůže ji provést, dejte to v zážitku jasně najevo.

V Salesforce to začíná jedním polem. Musí existovat pole, které jasně říká, že jde o kmenová data: klíč z ERP nebo příznak „je kmenový údaj“. Upravitelnost polí řiďte tímto polem, ne typem záznamu; s Dynamic Forms už nepotřebujete typ záznamu, abyste pole z ERP ukázali jen pro čtení (kapitola 5, Typ záznamu pro každý tok). Můžete dovolit vytvářet záznamy mimo master, ale hlídejte úpravy.

Nad rámec zkoušky: co mění AI. Zákazník řekne agentovi: „změňte naši fakturační adresu na 125 Main Street.“ Pole je přímo tam v Salesforce. Má ho agent aktualizovat? Ne, pokud ho vlastní ERP. Agent potřebuje oprávnění k zápisu, ne jen přístup k poli: jeho akce by měla kódovat schválenou cestu, odeslat požadavek na změnu a říct „odeslal jsem změnu ke zpracování“, ne falešně hlásit „aktualizoval jsem vaši fakturační adresu“.

Co tady rozhoduje architekt

• Zda úprava v Salesforce mění autoritativní data, nebo žádá o změnu systém, který je vlastní.
• Jak obousměrné toky rozlišují zahájené změny od ozvěn a jak řeší odmítnutí, kolize, latenci a selhání.
• Kdo vlastní každou hierarchii, v případě potřeby větev po větvi.
• U jednoho zákazníka vedeného v několika ERP: hierarchie, rovnocenné účty, nebo jeden účet s podřízeným záznamem pro každé ERP, rozhodnuto podle toho, jak dobře klient udržuje svá ERP v souladu.
• Zda soupeřící hierarchie nejsou ve skutečnosti různé legitimní vztahy: právní, fakturační, prodejní, servisní.
• Jak se hranice autorit a schválené cesty zápisu zviditelní uživatelům, integracím, vývojářům a agentům.

Problémem není sdílená autorita. Problémem je nejasná autorita. Několik ERP může spravovat různé větve, Salesforce může spravovat některé atributy a o změnu jiných žádat a několik hierarchií může popisovat jeden podnik. To všechno funguje, pokud u každého důležitého atributu a vztahu umíte říct, kdo ho vlastní, kdo ho smí měnit, kde se autoritativní změna provádí a co se stane, když se systémy neshodnou. Pokud to neumíte, další obousměrná šipka na diagramu to nespraví.

K prozkoumání

• Salesforce Help, Considerations for Using Account Hierarchy (otevře se v nové kartě), ověřeno 2026-10-17.