Nejlepší kontroly kvality dat pro integrace

Objednávka z e-shopu se ráno ještě jeví jako „zpracovatelná“, ale v systému skladu již není skladem. Fakturační program obdrží neúplnou dodací adresu a zákaznický servis si problému všimne až tehdy, když zákazník podá reklamaci. Často je vina přičítána integraci, i když příčina často spočívá v datech. nejlepší kontroly kvality dat pro integrace nevyhledávají chyby zpětně, ale předcházejí chybám v procesu ještě předtím, než se objeví v několika systémech a v práci několika lidí.

Integrace není jen jednoduché předávání dat mezi dvěma aplikacemi. Přenáší obchodní rozhodnutí: co lze prodat, co je třeba vyrobit, kam je třeba doručit, co je třeba fakturovat, jaký je stav zásob na e-shopu a jaká čísla se objeví v manažerské zprávě. Pokud jsou předávané informace nejisté, automatizovaný proces jen rychleji šíří nejistotu.

Nejprve je třeba vyjasnit, co se považuje za dobrá data

Mnoho společností chybuje tím, že kvalitu dat považuje pouze za technickou otázku. Je pole vyplněno? Je číslo skutečně číslem? Existuje kód produktu? Tyto kontroly jsou nezbytné, ale nedostatečné.

Objednávka může být například technicky kompletní, ale obchodně nezpracovatelná. Zákazník si vybral způsob doručení, který není v dané zemi dostupný. Kód produktu existuje, ale je již vyřazen. Částka slevy má správný formát, ale je vyšší, než co umožňuje obchodní pravidla nebo smlouva se zákazníkem.

Proto by každá kontrola měla být spojena s konkrétním obchodním důsledkem. Otázka není „můžeme validovat toto pole?“, ale „co se stane, pokud tato data předáme chybně do dalšího systému?“. Tam, kde chyba způsobí finanční rozdíl, zpoždění dodávky, zastavení výroby nebo ruční dohledání, je cílená kontrola oprávněná.

Nejlepší kontroly kvality dat pro integrace

Výběr vhodných kontrol závisí na procesu. Integrace objednávek B2B, propojení výrobních dat a předávání mezi finančními systémy nesou různá rizika. Přesto existují některé kontroly, které jsou základní pro většinu obchodních integrací.

Kontrola povinných dat a formátů

To je nejjednodušší úroveň, přesto zde zůstává mnoho chyb. Objednávka může vyžadovat identifikaci zákazníka, dodací adresu, způsob platby, daňové údaje a alespoň jednu položku objednávky. U produktových dat je typicky potřeba kód produktu, jednotka, stav, cena nebo nastavení správy zásob.

Kontrola formátu také ověřuje, že datum je skutečně datum, množství není text, kód země je přijatelná hodnota a e-mailová adresa má použitelnou strukturu. To neřeší všechny obchodní problémy, ale zabraňuje tomu, aby prázdná nebo neinterpretovatelná data tiše pokračovala dál.

Příliš přísná kontrola však může mít svou cenu. Pokud například v kmenových datech starého partnera chybí nově zavedené pole, všechny objednávky se mohou zastavit. V takovém případě není nutné pravidlo vzdát. Může být vytvořen dočasný výjimkový proces, úkol pro opravu dat nebo jasně oddělené zpracování starých dat.

Kontrola referenční integrity

V integracích data zřídka stojí sama o sobě. Položka objednávky odkazuje na produkt, objednávka na zákazníka, dodávka na sklad, faktura na daňovou sazbu nebo nákladové středisko. Pokud odkazovaný záznam neexistuje, je neaktivní nebo má v jiném systému odlišný význam, proces se snadno zkomplikuje.

Častým příkladem je, když kód produktu na e-shopu neodpovídá kódu používanému v ERP. Rozdíl může být způsoben nadbytečnou mezerou, úvodní nulou nebo starým kódem, který někdo stále manuálně používá. Systém pak nenajde produkt, nebo ještě hůře, spojí položku s podobným, ale jiným produktem.

Dobrá kontrola nejen zjišťuje, zda odkaz existuje v cílovém systému, ale také zda je použitelný v dané obchodní situaci. Lze produkt prodat? Je dodací adresa aktivní? Lze dané nákladové středisko použít v daném období?

Kontrola rozsahů a obchodních pravidel

Hodnota může být formálně správná, ale přesto nereálná. Negativní množství objednávky, nulová jednotková cena, datum dodání v příštím roce nebo neobvykle vysoká sleva jsou signály, které stojí za to prozkoumat.

Pravidla by zde měla sledovat skutečný provoz. U výrobní společnosti například může být pracovní list předán do výroby pouze tehdy, pokud má schválenou recepturu, platnou verzi a správné přiřazení surovin. V logistickém procesu může být podmínkou, že pro nebezpečné zboží je povinná správná přepravní klasifikace.

Není vhodné automaticky považovat každou vzácnou hodnotu za chybu. Neobvyklé množství objednávky může být výsledkem rámcové smlouvy s velkou společností. V takovém případě je užitečnější upozornění, úkol pro schválení nebo výjimkové řízení než zablokování celého procesu.

Rozpoznání jedinečnosti a opakování

Duplicitní data často nejsou nápadná, ale přesto způsobují přímé náklady. Znovu odeslaná objednávková zpráva může vytvořit dvě faktury, dva úkoly pro vychystání nebo dvojnásobnou rezervaci zásob. Zákazník může být uveden dvakrát s různým pravopisem jména, což způsobí, že prodej a finance vidí různé obrazy téhož partnera.

Pro kontrolu jedinečnosti jsou potřeba stabilní identifikátory. Ideálně je to externí identifikátor objednávky, identifikátor partnera nebo jednoznačný transakční klíč. Pokud takový není, je třeba zkoumat kombinaci více polí, například partnera, datum, částku a číslo dokladu. To je méně jisté, a proto má větší roli lidská kontrola.

Řešení opakujících se zpráv je obzvláště důležité tam, kde kvůli síťové chybě nebo časovému limitu odesílající systém neví, zda se přenos podařil. Integrace musí být schopna rozpoznat, že obdržela stejnou transakci znovu, nikoli novou obchodní událost.

Srovnání mezi zdrojem a cílem

Úspěšné technické odeslání dat nedokazuje, že proces je obchodně dokončen. Může se stát, že z tisíce objednávek prošlo 998, zatímco dvě mají chybný status. Pokud to nikdo nesrovná, dvě chybějící objednávky se objeví až později při stížnosti zákazníka nebo měsíčním rozdílu.

Srovnání zkoumá, zda je ve zdroji a cíli stejný očekávaný počet, částka, status nebo pohyb zásob. U denní integrace objednávek to může být porovnání počtu objednávek a čisté hodnoty. U předávání zásob je to množství podle skladu, u finančního propojení pak shoda dokladů a částek.

Tato kontrola nemusí nutně vyžadovat složitý systém. Důležité je, aby byl určen odpovědný pracovník, tolerance a proces řešení. Rozdíl v zaokrouhlení 0,01 eura vyžaduje jiný přístup než chybějící faktura s vysokou hodnotou.

Kontrola aktuálnosti a pořadí

Data mohou být chybná z hlediska procesu, pokud dorazí příliš pozdě. Pokud se údaje o zásobách e-shopu aktualizují až o několik hodin později, společnost může prodat produkt, který není skladem. Pokud se stav přepravy nedostane včas k zákaznickému servisu, pracovníci zbytečně hledají odpovědi v několika systémech.

Pořadí je potřeba, pokud lze událost interpretovat pouze po předchozí události. Zrušení objednávky nemůže dorazit před jejím vytvořením. Oprava faktury se nemůže objevit bez původní faktury. Výrobní stavy nemohou přeskočit schválené kroky jen proto, že zpráva dorazila později.

Řešení chyb je stejně důležité jako kontrola

Status „chyba“ sám o sobě není proces. Pokud systém odmítne objednávku, někdo musí vědět, kde je chyba vidět, co znamená, kdo ji může opravit a co se stane po opravě. Bez toho integrace vytváří jen další schránku nebo tabulku, kterou je třeba sledovat.

Dobré řešení chyb je formulováno srozumitelným obchodním jazykem. „HTTP 400“ může být vodítkem pro technický tým, ale pro operační kolegy je důležité vidět, že „pro objednávku nebyla nalezena aktivní dodací adresa“. K chybové zprávě by měl být připojen dotčený identifikátor, čas odeslání, zdroj dat a pokud možno další kroky.

Je vhodné oddělit opravitelné problémy s daty od systémových chyb. V prvním případě může obchodní oblast opravit data partnera nebo kód produktu. V druhém případě musí IT zkoumat připojení, oprávnění nebo výpadek služby. Oba případy nelze efektivně řešit na stejné chybové platformě.

Začněte s nejdražšími chybami

Není nutné budovat kontrolu pro každé možné pole. To by přetížilo proces a často by vytvořilo více výjimek než skutečné hodnoty. Je rozumné nejprve shromáždit chyby, které pravidelně způsobují zpoždění, ruční opravy, finanční ztráty nebo zhoršení zákaznické zkušenosti.

Podívejte se na deset případů, kdy kolegové ručně opravovali data mezi dvěma systémy. Jaká byla chyba? Kde vznikla? Proč nebyla odhalena dříve? Je daná data skutečně potřebná, nebo špatně navržený proces vyžaduje informace, které nejsou potřeba? Tato analýza často zlepší provoz více než další technické pravidlo.

Dobrá kvalita dat v integraci neznamená, že nikdy nedojde k výjimce. Znamená to, že výjimky jsou viditelné, řešitelné, sledovatelné a nevyžadují, aby lidé denně hledali pravdu mezi systémy. Pokud kontrola dosáhne tohoto cíle, zlepší se nejen data, ale i celkový provoz se stane předvídatelnějším.