Nepouštějte dovnitř špatná 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 2 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Správa dat se navrhuje do orgu · Další: Znejte svá data

Otázka, na kterou tento modul odpovídá: Jak udržet data dobrá, a udržet je tak?

Se špatnými daty se dá naložit dvěma způsoby: zastavit je dřív, než se dostanou dovnitř, nebo je uklidit potom. Budete dělat obojí. Když si ale můžu vybrat, raději problému předejdu, než abych kolem jeho věčného uklízení stavěl organizaci. Duplicity, špatné identifikátory, chybějící informace, nestandardní hodnoty, uživatelé měnící pole, která vlastní jiný systém, integrace přepisující dobrá data špatnými: z toho všeho se stane něčí úklidový projekt. Otázka návrhu tedy zní: jaká špatná data můžu rozumně udržet venku hned na začátku? A na slově „rozumně“ záleží, protože odpovědí není zamknout každé pole, dokud se systém nestane nepoužitelným.

„Dost dobré“ je obchodní definice

Než začnete špatným datům předcházet, definujte dobrá. Jedna definice neexistuje. Dobrá mohou znamenat dost úplná, aby proces proběhl, dost přesná, aby se podle nich dalo rozhodovat, dost aktuální pro danou zátěž, dost konzistentní, aby se dala spojit s jinými systémy, dost jedinečná, abychom věděli, kterého zákazníka myslíme, dost standardní pro automatizaci, dost dohledatelná, abychom věděli, odkud přišla. Záleží na datech. Pokud Steve Trucking fakturuje maloobchodnímu partnerovi, musí být právní identita partnera správně. Pokud si obchodník po schůzce dělá poznámky, nikdo nepotřebuje výbor, který schválí každou větu. „Dost dobré“ je obchodní definice; architekt ji dělá měřitelnou a vynutitelnou.

Předcházejte drahým chybám

Ne každé špatné pole si zaslouží stejnou pozornost. Nejvíc mi záleží na chybách s důsledky po proudu. Duplicitní zákazník znamená dvě prodejní historie, dvě servisní historie, dvě sady kontaktů, dvě externí ID, dvě integrace, které synchronizují stejnou firmu, dvě verze v datovém skladu a v Data 360 a nakonec agenta, který rozhoduje, který zákazník je skutečný. To je mnohem dražší než překlep v popisu. Nezačínejte tedy otázkou „jak ověříme každé pole?“ Začněte otázkou jaká špatná data vytvářejí největší obchodní nebo architektonický problém? a dejte nejsilnější kontroly tam.

Otevřeno, nebo zamčeno?

Klasickým příkladem je vytváření účtů. Má mít každý obchodník možnost vytvořit účet? Moje odpověď: záleží na správě dat kolem nich. Pro většinu malých a středních orgů je volné vytváření v pořádku. Obchodník se setká s potenciálním zákazníkem, vytvoří účet a pustí se do práce; k tomu je CRM. Kvalitu řídí pravidla duplicit, povinné informace a péče o data. Nepřidávám těžkopádný schvalovací proces jen proto, že správa dat zní zodpovědně.

Teď změňte krajinu. Právní zákazník se spravuje v ERP, proudí do Salesforce s identifikátorem z ERP a ERP je autoritativní. Teď volné vytváření znamená dvě cesty, jak vytvořit stejnou řízenou entitu. Když stejnou firmu vytvoří ERP i obchodník, co vyhraje, který identifikátor používají integrace, který záznam drží historii? Volné vytváření přestane být otázkou použitelnosti a stane se otázkou kmenových dat. Když se účty spravují v ERP nebo se s ním synchronizují, vytváření zamkněte.

Úplné zamčení ale také selže. Obchodník potkal potenciálního zákazníka, který v ERP není, a chce otevřít příležitost, a model správy dat řekne „žádný účet pro vás“. Tak čeká tři dny na Finance, nebo příležitost připojí ke špatnému účtu, nebo si potenciálního zákazníka drží v poli poznámek nebo v tabulce. Ochránili jsme datový model a poškodili byznys.

Střední cesta: prozatímní typ záznamu

Tady je střední cesta, kterou mám rád. Nechte obchod vytvořit účet pod konkrétním typem záznamu, typem pro potenciálního zákazníka nebo prozatímním, a řiďte jeho převod na řízený typ. Obchod zachytí firmu a začne prodávat. Záznam jasně říká: zatím nezavedený v autoritativním systému. Pak ho řízený proces převede: Finance ho schválí, nebo ho integrace předá do ERP, které ho buď spáruje s existujícím zákazníkem, nebo vytvoří nového a pošle zpět autoritativní identifikátor. Teď záznam překročí hranici, prozatímní → řízený, což je něco úplně jiného než dva systémy, z nichž každý vytvoří to, co považuje za kmenový záznam.

Typ záznamu je mechanismus, který učím. Ať použijete cokoli, udělejte stav viditelným v datech: odkud záznam přišel, jestli překročil hranici, kdo ho teď smí měnit, a identifikátor, který ho váže na autoritativní systém. Zákaznické ID z ERP, které existuje až po převodu, je ze všech signálů nejjasnější.

Typ záznamu pro každý tok

Dejte celý tok na jeden obrázek a uvidíte, proč to funguje. Zákazníci a produkty přicházejí dovnitř z ERP. Příležitosti a jejich řádkové položky jdou ven a stávají se objednávkami v ERP. A účty? Některé přicházejí dovnitř, některé jdou ven. Běžný vzor, který jsem viděl napříč implementacemi, jsou proto dva typy záznamu na Account, jeden pro každý směr. Účet Sales se rodí v Salesforce: obchodníci ho vytvářejí, upravují, prodávají mu, a když se z něj stane zákazník, pošle se ven do ERP. Účet ERP (říkal jsem mu Customer, nebo prostě SAP) se rodí v ERP a přichází dovnitř přes integraci. Tento typ záznamu nevytváří nikdo kromě integrace a jeho pole kmenových dat (oficiální název, adresy, platební podmínky) jsou pro uživatele jen pro čtení. Typ záznamu vám říká, kterým směrem záznam proudí, takže směr správy kmenových dat je vidět přímo na záznamu.

Kliknutím zvětšíte

Typ záznamu pro každý tok: účty Sales jdou ven, účty ERP přicházejí dovnitř.

Těžký případ to neodstraní. Obchodník převede zájemce za Steve’s Plumbing, ale Steve’s Plumbing už existuje jako účet ERP a kontrola duplicit to nějak nezachytila. Teď slučujete, přesouváte podřízené záznamy a rozhodujete, který záznam přežije (kapitola 6, modul 3).

A neulpívejte na samotném typu záznamu. Normálně se typům záznamu vyhýbám, pokud pro ně není silný důvod. Tady jsem je použil proto, že před Dynamic Forms vybíral typ záznamu rozvržení stránky a jedno rozvržení ukazovalo pole ERP jen pro čtení. S Dynamic Forms mohou pravidla viditelnosti ukazovat a skrývat pole podle hodnoty pole, pole může být na dané stránce jen pro čtení a sám Salesforce říká, že Dynamic Forms snižují počet rozvržení stránek a typů záznamu, které potřebujete (Break Up Your Record Details with Dynamic Forms (otevře se v nové kartě); Required and Read-Only Fields in Dynamic Forms (otevře se v nové kartě)). Jen pro čtení na stránce je ale jen pro čtení na té stránce: API, nahrávání dat nebo integrace mohou do pole pořád zapisovat. Skutečným vynucením je zabezpečení na úrovni polí nebo ověřovací pravidlo; ověření v rozhraní není ověření dat (kapitola 3, modul 9). Typy záznamu si své místo pořád zaslouží, když dva druhy účtů potřebují různé hodnoty výběrových seznamů nebo obchodní procesy. Na čem ale opravdu záleží, je, aby nějaké pole jasně říkalo, odkud záznam přišel: samotný klíč z ERP, příznak kmenových dat, nebo výběrový seznam zdroje. Pak upravitelnost řiďte tímto polem.

Kliknutím zvětšíte

Od prozatímního k řízenému: obchod začne prodávat hned; řízeným záznam udělá jen autoritativní proces.

Chraňte řízený záznam

Jakmile se zákazník vrátí z ERP, jsou jeho ID z ERP, oficiální název, daňový identifikátor a fakturační údaje řízenými atributy. Má je obchodník měnit? Ne, pokud je vlastní ERP. To je zásada z modulu 1, která potřebuje své místo vynucení: ID z ERP jen pro čtení, právní identita řízená, zatímco obchodník dál upravuje teritorium, poznámky ke vztahu a vlastní klasifikace Salesforce. Cílem není nedotknutelný účet. Je to jasná hranice mezi daty, která Salesforce vlastní, a daty, na která Salesforce jen odkazuje. (Předpona erp_ z kapitoly 4 tuto hranici ve schématu zviditelňuje.)

Skončíte se zlatým záznamem, který je ve skutečnosti hybrid. Pole kmenových dat z ERP přicházejí dovnitř: oficiální název, fakturační a dodací adresa, platební podmínky. Pak Salesforce přidá vlastní pole, která se nikdy nevracejí: obchodní hodnocení, datum poslední objednávky, prakticky cokoli, co používá marketing. Stejný účet, dva druhy polí a každý druh má jeden zdroj.

Nejtěžší jsou obousměrné toky. Řekněme, že obchodník potřebuje změnit oficiální název v ERP ze Steve’s Plumbing na Steve’s Plumbing LLC. V tytéž pět minut ho někdo v ERP změní na Steve’s Plumbing L.L.C. Čí změna vyhraje? Tady je způsob myšlení: pokud je pole spravované v ERP, pole neměníte, žádáte o jeho změnu. Rozhodněte, co se stane, když se požadavek srazí: vyhraje ERP, požadavek se odmítne, pokud se hodnota mezitím změnila, nebo počká, až to vyřeší člověk. A rozhodněte, jestli související pole cestují společně jako jedna změna, nebo jedno po druhém. Kapitola 6 jde s kolizemi dál (Smyčky a kolize).

Zastavte duplicity u dveří

Duplicity se nabalují. Zachyťte jednu dřív, než vznikne, a je to malý problém. Najděte ji o dva roky později, s příležitostmi, případy, kontakty, fakturami, integracemi a analytikou visícími na obou, a je to velký problém. Mechanismy (pravidla shody, pravidla duplicit, jedinečná External ID) pokryl modul 7 kapitoly 3, takže je nebudu učit znovu. Otázka správy dat zní: kde musíme duplicitám zabránit a kde je tolerujeme a vyřešíme později? Příležitostný marketingový zájemce s nejasností žít může. Zákazník řízený ERP s finančními transakcemi ne.

Standardizujte, co čtou stroje

Volný text je skvělý pro lidi a hrozný, když ho musí interpretovat systém. Dejte Arizona, AZ, Ariz., Phoenix area a Southwest do pole, které řídí plánování tras, a máte problém s kvalitou. Pokud hodnota řídí automatizaci, integraci, sestavy, zabezpečení, přiřazení nebo akci agenta, dobře promyslete, jak standardní musí být. Ne z každého textového pole se stane výběrový seznam, ale rozlišujte informace, které čtou lidé, od informací, podle kterých rozhodují stroje. Ty druhé si zaslouží silnější kontrolu.

Nenechte povinná pole vytvářet falešná data

Rozhodneme, že pole je důležité, a uděláme ho povinným. Uživatel odpověď nezná, systém ho nepustí dál, a tak napíše N/A, Unknown, 999999 nebo test@test.com. Pole je vyplněné; data jsou nesmysl. Než něco uděláte povinným, zeptejte se, jestli to uživatel v tu chvíli skutečně ví. Pokud ne, vyžadujte to později v procesu, nechte to dodat jiný systém, použijte prozatímní stav, nebo nabídněte výslovnou hodnotu Unknown, když je „neznámé“ legitimní odpovědí. Ověřovací pravidlo dokáže vynutit zásadu. Nedokáže někoho přimět vědět, co neví.

Každá hranice dat potřebuje rozhodnutí o kvalitě

Lidé nejsou jediným zdrojem špatných dat; integrace je produkují rychleji. Přijde manifest maloobchodního partnera s pár sty řádky. Hrstka má neplatná PSČ, pár jmenuje neznámé distribuční centrum, dva opakují stejnou referenci objednávky. Co se stane? Odmítnout celý soubor? Přijmout dobré řádky a špatné vrátit? Nahrát všechno a uklidit později? Výjimky dát do karantény? Komu se to oznámí a jak se partner dozví, co selhalo? Univerzální odpověď neexistuje, ale nějaká být musí. Kapitola 4 řekla, že každá šipka potřebuje mechanismus. Přidejte: každá hranice dat potřebuje rozhodnutí o kvalitě: co přijmeme, odmítneme nebo dáme do karantény a kdo vlastní výjimku.

Kliknutím zvětšíte

Každá hranice dat potřebuje rozhodnutí o kvalitě.

Historická data jsou jiná

RouteDesk drží osm let historie Steve Trucking a její kvalita se liší podle distribučního centra. Máme vyčistit všech osm let na dnešní standard, než je přesuneme? Nejspíš ne automaticky. K čemu jsou: ke každodennímu provozu, jako reference, kvůli reklamacím, pro sestavy, pro analýzu trendů? Musí být všechna v Salesforce, nebo některá mohou zůstat jinde? Kapitola o migraci jde do hloubky. Pointa správy dat: historie automaticky nepotřebuje stejný standard jako aktivní data. Pokud se podle ní budete rozhodovat, na kvalitě záleží. Pokud ji držíte jako referenci, může stačit jiný standard. Znejte účel dřív, než utratíte majlant za čištění minulosti.

Měřte, podle čeho bude někdo jednat

Správa dat nikdy nekončí, takže potřebujete vidět, kdy kvalita klesá: rostoucí míra duplicit, víc záznamů v karanténě, víc odmítnutí v integracích, šířící se zástupné hodnoty, víc žádostí o výjimky, sestavy, které už nesedí. Nestavte ale 150 metrik, abyste 143 z nich ignorovali. Pro Steve Trucking to mohou být doručení bez platné reference partnera, doručení bez použitelné adresy, opakované reference objednávek, odmítnuté zprávy od partnerů, účty uvízlé v prozatímním stavu. Řídicí panel plný zelených koleček neznamená, že jsou data dobrá. Měřte, podle čeho je někdo připravený jednat.

Nad rámec zkoušky: co mění AI. Ze špatných dat se čím dál častěji stávají špatné akce. Člověk si může všimnout, že telefonní číslo vypadá divně, než na něj zavolá; agent prostě použije hodnotu, kterou dostane. Duplicitní zákazníci, zastaralé stavy, falešné povinné hodnoty a špatné identifikátory se rovnou mění ve špatnou zprávu nebo špatnou aktualizaci. To zvyšuje hodnotu prevence. Neodstraňuje to potřebu péče o data.

Co tady rozhoduje architekt

• Která selhání kvality škodí natolik, že ospravedlňují preventivní kontroly.
• Zda se řízené záznamy vytvářejí volně, jen autoritativním systémem, nebo cestou od prozatímního k řízenému.
• Které atributy Salesforce vlastní a na které jen odkazuje.
• Co se stane s příchozími daty, která neprojdou kontrolami (přijmout, odmítnout, nebo dát do karantény), a kdo vlastní výjimku.
• Které signály kvality se měří, aby správci viděli, když kvalita klesá.

Nikdy nezabráníte každému špatnému záznamu. Úkolem nejsou dokonalá data; je to nedovolit, aby se z odvratitelně špatných dat stala drahá data. Zastavte duplicitu dřív, než má dva roky historie. Chraňte identifikátor dřív, než na tom špatném závisí deset integrací. Nechte obchod vytvořit potenciálního zákazníka, ale nepředstírejte, že je to řízený zákazník, dokud jím není. A když se něco špatného dostane dovnitř, zajistěte, aby to někdo viděl, vlastnil a opravil.

K prozkoumání

• Salesforce Help, Things to Know About Duplicate Rules (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (otevře se v nové kartě) a Required and Read-Only Fields in Dynamic Forms (otevře se v nové kartě), ověřeno 2026-10-17.