Datové procesy / 07
Dva systémy. Jasná pravidla pro stejný záznam.
Zákazník se změní v CRM i ERP. Který stav platí? Synchronizaci stavíme na obchodních odpovědnostech a stabilních identitách, aby pravidelné přenosy nevytvářely skryté konflikty dat.
Výchozí stav
Obousměrnost neznamená, že každé pole má oba směry.
CRM spravuje kontaktní osoby, ERP fakturační adresu a platební podmínky. Oba ukládají stejného zákazníka s vlastním ID. Plošné pravidlo „nejnovější časové razítko vyhrává“ může nahradit schválenou ERP adresu starším obsahem CRM.
Pole a procesy posuzujeme samostatně. Stabilní ID, značky změn a informace o mazání jsou rozhodující. Bez spolehlivého delta přístupu je kontrolované úplné porovnání často poctivější než zdánlivý provoz v reálném čase.
Co zajišťuje DataSource
Detekovat změny. Rozhodovat konflikty.
Identita
Přiřazení lokálních ID a detekce obchodních duplicit. Nové, sloučené a smazané záznamy mají každý definovaný postup.
Směry
Pro každé pole určit autoritativní systém. Změny opatřit verzí nebo původem, pokud to systémy podporují, pro omezení zpětných vazeb.
Porovnání
Zpracování delt, ukládání potvrzeného postupu a pravidelné porovnávací běhy jako korekce. Konflikty vyjasnit s odpovědným týmem.
Kunde 004218
ERP → CRM: billingAddress, paymentTerms
CRM → ERP: contactName, contactPhone
Version passt → definierte Felder aktualisieren
Version weicht ab → erneut lesen / Konflikt klären
Datensatz gelöscht → vereinbarte Löschregel anwendenTechnický scénář / ilustrativní příklad
Cílená distribuce změny adresy.
Ilustrativní plán stavů. ERP spravuje fakturační adresu, CRM kontakt. Konflikt verzí se zviditelní namísto slepého přepsání celého zákaznického záznamu.
Vzorová data a navržená pravidla. Konkrétní rozhraní a obchodní pravidla se prověří pro váš projekt.
Ošetření chyb, bezpečnost a provoz
Konflikt, smazání a postup.
Mazání
Absence v neúplné odpovědi není oznámení smazání. Význam musí dodat tombstones, archivace nebo potvrzený úplný stav.
Přerušení
Po výpadku pokračovat od posledního potvrzeného stavu. Pokud data změn expirovala, provést definované nové porovnání.
Aktuálnost
Dohodnout časová okna a přípustné zpoždění. „Reálný čas“ není podložený příslib bez vhodného zdroje, cílové kapacity a provozní odpovědnosti.
Odborné otázky
Detaily důležité před implementací.
Delta · Porovnání · Odpovědnost za pole · Konflikty · Mazání
Může se stejné pole měnit v obou systémech?
Ano, pak potřebuje pravidlo konfliktu nebo schvalovací proces. Pravidlo časového razítka má smysl jen tehdy, pokud odpovídá jeho obchodní účinek a časová základna.
Zabrání webhooky všem chybějícím aktualizacím?
Ne. Události mohou přijít opakovaně, opožděně nebo v jiném pořadí. Podle poskytovatele je vhodné doplňující porovnání.
Jak řešíme duplicity?
Nejprve vyjasnit pravidla identit a stávající kvalitu dat. Nejistá přiřazení patří k ověření, ne do automatického merge.
Pro technické vyjasnění
Začít vaším konkrétním procesem.
Popište systémy, datové objekty, příklady ID, požadované směry a přijatelné zpoždění. Zvlášť cenné jsou příklady konfliktů a smazání.
V prvním rozhovoru vyjasníme dostupné přístupy, odpovědnost za data a omezený první datový tok. Poté dohodneme rozsah, odpovědnosti a podmínky.
Pro začátek stačí anonymizované příklady. V prvním dotazu neposílejte hesla, tokeny ani produkční data s osobními údaji.
Související úlohy
Další propojení v kontextu.
Rozhraní ERP a CRM
Obchod a účetnictví pracují se stejným zákazníkem s různými úkoly. DataSource propojí podporovaná rozhraní a vyjasní, jaká data se kdy přenášejí mezi zájemcem, zákazníkem a odběratelským účtem.
Synchronizovat objednávky a stavy
Shop hlásí zaplaceno, ERP ještě nezná objednávku a expedice už má tracking číslo. Propojíme tyto kroky s definovanými stavy, jednoznačnými referencemi objednávek a plánovaným obnovením běhu.
Spolehlivě zpracovat webhooky
Přijde událost a má vyvolat akci v dalším systému. Opakované doručení, zpoždění nebo výpadek cílového API z toho dělají provozní proces. Vyvineme jej s jednoznačnými událostmi a ověřitelnými účinky.