Legjobb adatminőségi ellenőrzések integrációkhoz

Egy webshop rendelése reggel még „feldolgozható” állapotban látszik, de a raktári rendszerben már nincs hozzá készlet. A számlázóprogram hiányos szállítási címet kap, az ügyfélszolgálat pedig csak akkor veszi észre a problémát, amikor a vevő reklamál. Ilyenkor gyakran maga az integráció kapja a hibát, pedig a kiváltó ok sokszor az adatban volt. A legjobb adatminőségi ellenőrzések integrációkhoz nem utólag keresik a hibást, hanem még azelőtt megakadályozzák a hibás folyamatot, hogy az több rendszerben és több ember munkájában is megjelenne.

Az integráció nem egyszerű adatátadás két alkalmazás között. Üzleti döntéseket továbbít: mit lehet értékesíteni, mit kell legyártani, hová kell szállítani, mit kell kiszámlázni, milyen készletet mutat a webshop, és milyen számok kerülnek a vezetői riportba. Ha az átadott információ bizonytalan, az automatizált folyamat csak gyorsabban terjeszti a bizonytalanságot.

Először azt kell tisztázni, mi számít jó adatnak

Sok vállalat ott hibázik, hogy az adatminőséget kizárólag technikai kérdésként kezeli. Van-e kitöltve a mező? Szám-e a szám? Létezik-e a termékkód? Ezek szükséges vizsgálatok, de nem elegendők.

Egy rendelés például technikailag lehet teljes, miközben üzletileg feldolgozhatatlan. A vevő kiválasztott egy szállítási módot, amely az adott országba nem elérhető. A termék cikkszáma létezik, de már kivonás alatt áll. A kedvezmény összege helyes formátumú, mégis nagyobb, mint amit a kereskedelmi szabályzat vagy az ügyfél szerződése enged.

Ezért minden ellenőrzésnek egy konkrét üzleti következményhez kell kapcsolódnia. Nem az a kérdés, hogy „tudjuk-e validálni ezt a mezőt?”, hanem az, hogy „mi történik, ha ezt az adatot hibásan adjuk át a következő rendszernek?”. Ahol a hiba pénzügyi eltérést, szállítási késést, termelési leállást vagy kézi utánajárást okoz, ott indokolt a célzott kontroll.

A legjobb adatminőségi ellenőrzések integrációkhoz

A megfelelő ellenőrzések kiválasztása folyamatfüggő. Egy B2B rendelési integráció, egy gyártási adatkapcsolat és egy pénzügyi rendszer közötti átadás más kockázatokat hordoz. Mégis van néhány kontroll, amely a legtöbb üzleti integrációban alapvető.

Kötelező adatok és formátumok vizsgálata

Ez a legegyszerűbb szint, mégis itt marad át sok hiba. Egy rendeléshez szükség lehet vevőazonosítóra, szállítási címre, fizetési módra, adózási adatokra és legalább egy rendelési sorra. Egy termékadatnál tipikusan cikkszámra, egységre, státuszra, árra vagy készletkezelési beállításra.

A formátumvizsgálat azt is ellenőrzi, hogy a dátum valóban dátum, a mennyiség nem szöveg, az országkód elfogadott érték, az e-mail-cím pedig használható szerkezetű. Ez nem védi ki az összes üzleti problémát, de megakadályozza, hogy egy üres vagy értelmezhetetlen adat csendben továbbmenjen.

A túl szigorú ellenőrzésnek azonban ára lehet. Ha például egy régi partner törzsadataiban hiányzik egy újonnan bevezetett mező, az összes rendelés megállhat. Ilyenkor nem feltétlenül a szabályt kell feladni. Lehet átmeneti kivételi folyamatot, adatjavítási feladatot vagy világosan elkülönített régi adatkezelést kialakítani.

Hivatkozási integritás ellenőrzése

Az integrációkban az adatok ritkán állnak önmagukban. Egy rendelési sor termékre hivatkozik, a rendelés ügyfélre, a szállítás raktárra, a számla adókulcsra vagy költséghelyre. Ha a hivatkozott rekord nem létezik, inaktív, vagy más rendszerben eltérő jelentése van, a folyamat könnyen félremegy.

Gyakori példa, amikor a webshopban szereplő termékkód nem egyezik az ERP-ben használt cikkszámmal. Az eltérés lehet egy felesleges szóköz, egy vezető nulla vagy egy régi kód, amelyet valaki manuálisan még használ. A rendszer ilyenkor nem talál terméket, vagy rosszabb esetben hasonló, de másik termékhez kapcsolja a sort.

A jó ellenőrzés nemcsak azt nézi, hogy a célrendszerben létezik-e a hivatkozás, hanem azt is, hogy használható-e az adott üzleti helyzetben. Értékesíthető-e a termék? Aktív-e a szállítási cím? Használható-e az adott költséghely a tárgyidőszakban?

Tartományok és üzleti szabályok vizsgálata

Az érték lehet formailag helyes, mégis életszerűtlen. Negatív rendelési mennyiség, nulla egységár, jövő évi szállítási dátum vagy szokatlanul magas kedvezmény mind olyan jel, amelyet érdemes vizsgálni.

A szabályoknak itt a tényleges működést kell követniük. Egy gyártó cégnél például egy munkalap csak akkor adható át termelésre, ha rendelkezik jóváhagyott receptúrával, érvényes verzióval és megfelelő alapanyag-hozzárendeléssel. Egy logisztikai folyamatban lehet feltétel, hogy a veszélyes áruhoz kötelező a megfelelő szállítási besorolás.

Nem célszerű minden ritka értéket automatikusan hibának minősíteni. A szokatlan rendelési mennyiség lehet nagyvállalati keretszerződés eredménye is. Ilyen esetben a figyelmeztetés, jóváhagyási feladat vagy kivételkezelés hasznosabb, mint a teljes folyamat blokkolása.

Egyediség és ismétlődések felismerése

A duplikáció gyakran nem látványos, mégis közvetlen költséget okoz. Egy újraküldött rendelési üzenet két számlát, két kiszedési feladatot vagy kétszeres készletfoglalást hozhat létre. Egy ügyfél kétszer szerepelhet eltérő névírással, ezért az értékesítés és a pénzügy más képet lát ugyanarról a partnerről.

Az egyediség ellenőrzéséhez szükség van stabil azonosítókra. Ideális esetben ez külső rendelésazonosító, partnerazonosító vagy egyértelmű tranzakciós kulcs. Ha ilyen nincs, több mező kombinációját kell vizsgálni, például partner, dátum, összeg és bizonylatszám alapján. Ez kevésbé biztos, ezért nagyobb szerepe lesz az emberi felülvizsgálatnak.

Az ismétlődő üzenetek kezelése különösen fontos ott, ahol hálózati hiba vagy időtúllépés miatt a küldő rendszer nem tudja, sikerült-e az átadás. Az integrációnak ilyenkor képesnek kell lennie felismerni: ugyanazt a tranzakciót kapta újra, nem egy új üzleti eseményt.

Egyeztetés a forrás és a cél között

A sikeres technikai adatküldés nem bizonyítja, hogy a folyamat üzletileg is teljesült. Előfordulhat, hogy ezer rendelésből 998 átment, kettő pedig hibás státuszba került. Ha ezt senki nem egyezteti, a két hiányzó rendelés csak később, ügyfélpanasz vagy havi eltérés során kerül elő.

Az egyeztetés azt vizsgálja, hogy a forrásban és a célban azonos-e a várt darabszám, összeg, státusz vagy készletmozgás. Napi rendelési integrációnál ez lehet a rendelési darabszám és nettó érték összevetése. Készletátadásnál a raktárankénti mennyiségek, pénzügyi kapcsolatnál pedig a bizonylatok és összegek egyezése.

Ez a kontroll nem feltétlenül igényel bonyolult rendszert. A lényeg, hogy legyen kijelölt felelős, tűréshatár és rendezési folyamat. Egy 0,01 eurós kerekítési különbség más kezelést igényel, mint egy hiányzó, nagy értékű számla.

Időszerűség és sorrendiség ellenőrzése

Az adat akkor is hibás lehet a folyamat szempontjából, ha túl későn érkezik. Ha a webshop készletadata csak órákkal később frissül, a cég már olyan terméket is eladhat, amely nincs raktáron. Ha a fuvarstátusz nem jut vissza időben az ügyfélszolgálathoz, az ügyintézők feleslegesen keresik a választ több rendszerben.

Sorrendiségre akkor van szükség, ha egy esemény csak egy korábbi esemény után értelmezhető. Egy rendelés lemondása nem érkezhet meg a létrehozása előtt. Egy számlakorrekció nem jelenhet meg az eredeti számla nélkül. A gyártási állapotok sem ugorhatnak át jóváhagyott lépéseket csak azért, mert egy üzenet később érkezett meg.

A hibakezelés legalább olyan fontos, mint az ellenőrzés

A „hibás” státusz önmagában nem folyamat. Ha a rendszer elutasít egy rendelést, valakinek tudnia kell, hol látszik a hiba, mit jelent, ki javíthatja, és mi történik a javítás után. Enélkül az integráció csak egy újabb figyelendő postaládát vagy táblázatot hoz létre.

A jó hibakezelés érthető üzleti nyelven fogalmaz. A „HTTP 400” a technikai csapatnak adhat támpontot, de az operációs kollégának azt kell látnia, hogy „a rendeléshez nem található aktív szállítási cím”. A hibaüzenethez kapcsolódjon az érintett azonosító, a beküldés ideje, az adat forrása és lehetőség szerint a következő teendő.

Érdemes elkülöníteni a javítható adatproblémákat a rendszerhibáktól. Előbbinél az üzleti terület korrigálhatja a partneradatot vagy a termékkódot. Utóbbinál az IT-nak kell vizsgálnia a kapcsolatot, jogosultságot vagy szolgáltatáskimaradást. A két eset ugyanazon a hibajelző felületen nem kezelhető hatékonyan.

Kezdje a legdrágább hibákkal

Nem szükséges minden lehetséges mezőre ellenőrzést építeni. Az túlterheli a folyamatot, és gyakran több kivételt termel, mint valódi értéket. Célszerű először azokat a hibákat összegyűjteni, amelyek rendszeresen késést, manuális javítást, pénzügyi veszteséget vagy ügyfélélmény-romlást okoznak.

Nézzen meg tíz olyan esetet, amikor a kollégák kézzel javítottak adatot két rendszer között. Mi volt a hiba? Hol keletkezett? Miért nem derült ki korábban? Valóban szükséges-e az adat, vagy egy rosszul kialakított folyamat kér be olyan információt, amelyre nincs szükség? Ez a vizsgálat gyakran többet javít a működésen, mint egy újabb technikai szabály.

A jó integrációs adatminőség nem azt jelenti, hogy soha nincs kivétel. Azt jelenti, hogy a kivételek láthatók, kezelhetők, visszakövethetők, és nem kényszerítik az embereket arra, hogy naponta rendszerek között kutassanak az igazság után. Ha egy ellenőrzés ezt eléri, nem csak az adat lesz jobb - a teljes működés válik kiszámíthatóbbá.