Duplicitný záznam o dodávateľovi nie je len problémom kvality údajov. Môže viesť k duplicitným platbám, nepresnej analýze výdavkov, zlyhaniu smerovania pracovných postupov a týždňom ručného zosúlaďovania. Stratégia integrácie kmeňových údajov rieši tento prevádzkový problém priamo pri zdroji: definuje, ako sa kľúčové obchodné entity identifikujú, spravujú, zdieľajú a ako sa zabezpečuje ich konzistentnosť vo všetkých systémoch, ktoré riadia podnik.
Pre organizácie s vysokou prevádzkovou náročnosťou predstavujú kľúčové údaje spoločný jazyk, na ktorom funguje obstarávanie, financie, zákaznícky servis, výroba, predaj a dodržiavanie predpisov. Ak sa tento jazyk líši v závislosti od systému alebo obchodnej jednotky, každá automatizácia a každý riadiaci panel preberá túto nekonzistentnosť. Výsledok je predvídateľný: lokálne provizórne riešenia sa rozširujú, tímy strácajú dôveru vo výkazníctvo a transformačné programy prinášajú skôr izolované zlepšenia ako škálovateľný výkon.
Prečo zlyháva integrácia kmeňových údajov v podnikových programoch
Väčšine organizácií nechýbajú systémy. Chýba im však riadený spôsob, ako zabezpečiť, aby sa systémy zhodovali v otázkach zákazníkov, dodávateľov, produktov, lokalít, majetku, zamestnancov a štruktúr účtovných osnov, ktoré majú spoločné. ERP platformy, CRM aplikácie, systémy na riadenie nákupu, skladové systémy, nástroje na plánovanie a staršie databázy si v priebehu času vytvárajú svoje vlastné verzie tej istej entity.
Bežným riešením je vytvorenie ďalšieho rozhrania typu „point-to-point“. To síce môže vyriešiť bezprostredný problém s integráciou, zriedka však vyrieši problém s definíciami. Ak jedna aplikácia považuje zákazníka za právnickú osobu, iná ho považuje za miesto doručenia a tretia používa hierarchiu obchodných účtov, rýchlejší prenos údajov ešte neznamená, že budú porovnateľné alebo použiteľné.
Druhým typom zlyhania je prístup k integrácii údajov ako k čisto technickému procesu. Podnikoví architekti síce môžu vybrať integračnú platformu a nastaviť rozhrania API, avšak riešenie sa zastaví, ak sa v rámci podniku nerozhodne, kto je vlastníkom záznamu o dodávateľovi, kedy sa produkt stáva aktívnym alebo ktoré atribúty sú povinné na to, aby bolo možné spracovať faktúru. Technológia môže vynútiť dodržiavanie pravidla, nemôže však rozhodovať o pravidle v mene organizácie.
Kompromis je jasný. Centralizácia každého rozhodnutia môže spomaliť miestne operácie, zatiaľ čo umožnenie každej obchodnej jednotke spravovať záznamy nezávisle vytvára dlhodobý problém s kontrolou. Škálovateľný model centralizuje štandardy, riadenie a spoločné definície, pričom miestnym tímom umožňuje zachovať schválené atribúty, ktoré odrážajú skutočné prevádzkové potreby.
Základy stratégie integrácie kmeňových údajov
Praktická stratégia začína od obchodných výsledkov, nie od výberu platformy. Vedúci pracovníci by mali určiť, ktoré prevádzkové nedostatky musí program odstrániť a ako sa bude merať výkonnosť. Pre jednu organizáciu môže byť prioritou zníženie počtu zablokovaných faktúr spôsobených nekonzistentnosťou dodávateľov. Pre inú organizáciu to môže byť vytvorenie spoľahlivej hierarchie produktov na účely analýzy marží alebo zavedenie automatizácie procesu zapájania nových zákazníkov vo všetkých regiónoch.
Toto zameranie vytvára jasne vymedzený rozsah. Nie je potrebné v prvej verzii riešiť všetky oblasti kmeňových údajov. Začnite tam, kde nekvalitné údaje spôsobujú podstatné náklady, ohrozujú dodržiavanie predpisov, spôsobujú oneskorenie tržieb alebo zlyhanie automatizácie. Úspešná počiatočná oblasť buduje dôveru a vytvára prevádzkový model potrebný na širšie zavedenie.
Definujte obchodné subjekty a ich účel
Prvým rozhodnutím pri návrhu je identifikovať dôležité entity a zdokumentovať, ako sa každá z nich využíva. Dodávateľ môže napríklad slúžiť na zabezpečovanie zdrojov, objednávky, platby, daňové hlásenia, posudzovanie rizík a správu zmlúv. Tieto spôsoby využitia určujú požadované atribúty, validačné pravidlá, vlastníctvo a integračné cesty.
V tejto súvislosti je tiež potrebné rozlišovať medzi kmeňovými údajmi, transakčnými údajmi a referenčnými údajmi. Objednávka je transakčný údaj. Dodávateľ je kmeňový údaj. Kód krajiny alebo platobné podmienky môžu byť referenčnými údajmi. Toto rozlíšenie je dôležité, pretože každá kategória si vyžaduje odlišné kontroly, cykly aktualizácie a spôsoby distribúcie.
Zaviesť systém evidencie a systém využívania
Každá doména potrebuje jasný zdroj autority. To však neznamená, že všetky atribúty sú vždy spravované jednou aplikáciou. Záznam o zákazníkovi môže byť vytvorený v systéme CRM, jeho úverová bonita môže byť spravovaná v systéme ERP a obohatené atribúty týkajúce sa rizika môže získavať zo služby tretej strany. Stratégia musí špecifikovať, ktorý systém je pre každý atribút autoritatívny a ako sa riešia konflikty.
Rovnako dôležité je zdokumentovanie systémov používania. Platforma na správu skladu síce môže využívať rozmery produktov, nemala by však prepisovať komerčnú hierarchiu produktov. Bez tohto rozlíšenia sa integrácie štandardne stávajú obojsmernými a kvalita údajov sa zhoršuje v dôsledku navzájom si konkurujúcich aktualizácií.
Vytvorte spoločný model bez vynucovania falošnej jednotnosti
Kanonický dátový model poskytuje spoločnú štruktúru pre výmenu informácií medzi systémami. Znižuje potrebu, aby každá aplikácia rozumela formátu každej inej aplikácie. Kanonický model by však nemal potláčať obchodný význam len preto, aby údaje vyzerali jednotne.
Napríklad globálny model produktu môže definovať spoločné identifikátory, popisy, jednotky merania a stavy životného cyklu. Zároveň však môže zohľadňovať špecifické charakteristiky daného odvetvia, ako sú kontroly šarží, technické revízie, klasifikácia nebezpečných materiálov alebo regionálne požiadavky na označovanie. Najprv štandardizujte základné prvky a potom explicitne spravujte odôvodnené odchýlky.
Navrhnite integračnú architektúru so zameraním na riadenie
Architektúra integrácie by mala zabezpečiť, aby bol pohyb údajov sledovateľný, obnoviteľný a kontrolovateľný. Dávková synchronizácia môže byť vhodná pre referenčné údaje s nízkym objemom alebo pre systémy s obmedzenými rozhraniami. Integrácia riadená udalosťami je často vhodnejšia v prípadoch, keď následné procesy vyžadujú okamžité upozornenie na schválenie dodávateľa, uvedenie produktu na trh alebo zmenu zákazníckeho účtu.
Architektonické rozhodnutie závisí od časového harmonogramu podnikania, objemov transakcií, schopností systému a dôsledkov oneskorenia. Výmena údajov v reálnom čase nie je automaticky lepšia. Prináša so sebou prevádzkové závislosti a požiadavky na monitorovanie, ktoré nemusia byť opodstatnené vo všetkých oblastiach. Správny návrh využíva spracovanie v reálnom čase tam, kde chráni tržby, dodržiavanie predpisov, zákaznícku skúsenosť alebo automatizáciu veľkých objemov, a využíva plánovanú synchronizáciu tam, kde to postačuje.
Kontrolovaná architektúra by mala zahŕňať správu identít, transformačnú logiku, validáciu, spracovanie chýb, správu verzií a zosúlaďovanie. Fronty chýb musia byť viditeľné pre zodpovedné tímy a nesmú byť skryté v technických protokoloch. Ak adresa neprejde validáciou alebo ak nie je možné distribuovať záznam o produkte, organizácia potrebuje stanovený postup na vyriešenie problému, cieľové časy odozvy a dôkaz o tom, že bola vykonaná oprava.
Vyhnite sa vkladaniu kľúčových obchodných pravidiel do desiatok jednotlivých rozhraní. Opätovne použiteľné validačné služby a centrálne spravované mapovacie pravidlá znižujú nároky na údržbu v prípade zmien v aplikačnom prostredí. To je obzvlášť cenné pri fúziách, modernizácii ERP systémov alebo zavádzaní nových automatizačných nástrojov, keď zložitosť integrácie má tendenciu rýchlo stúpať.
Začleňte riadenie do každodenných činností
Správa dát sa často opisuje ako štruktúra výborov. Výbory sú dôležité, ale nečistia záznamy o dodávateľoch ani neschvaľujú zmeny produktov. Efektívna správa priraďuje konkrétne zodpovednosti v rámci prevádzkového modelu: výkonní sponzori stanovujú zásady a priority; vlastníci dát definujú obchodné pravidlá; správcovia dát riadia kvalitu a výnimky; IT tímy zabezpečujú údržbu platforiem a integrácií; vlastníci procesov zabezpečujú, aby kontrolné mechanizmy zodpovedali pracovnému toku.
Proces musí byť navrhnutý tak, aby zodpovedal skutočnému priebehu práce. Ak údržbársky tím potrebuje nový záznam o náhradnej súčiastke na odstránenie poruchy zariadenia, viacdňový schvaľovací reťazec sa obíde. Namiesto toho vytvorte pracovné postupy založené na riziku. Zmeny s vysokým rizikom, ako sú bankové údaje alebo daňové identifikačné čísla, si vyžadujú dôkladnejšie overenie. Popisné zmeny s nízkym rizikom môžu byť overené automaticky alebo schválené prostredníctvom menej prísnych kontrol.
Ukazovatele kvality by nemali obmedzovať len na úplnosť. Merajte jedinečnosť, platnosť, konzistentnosť, aktuálnosť a súlad s obchodnými pravidlami. A čo je ešte dôležitejšie, prepojte tieto ukazovatele s prevádzkovými výsledkami: mierou výnimiek vo faktúrach, dĺžkou cyklu zapracovania nových zamestnancov, presnosťou vybavovania objednávok, objemom ručných opráv alebo percentom automatizovaných procesov dokončených bez zásahu.
Zavádzajte postupne, nie formou jednorazovej migrácie
Program na správu kmeňových údajov získa na popularite, ak už v počiatočnej fáze prinesie viditeľné zlepšenia a zároveň smeruje k vytvoreniu podnikového modelu. Začnite s vymedzenou oblasťou, obmedzeným počtom systémov, ktoré údaje využívajú, a merateľným výsledkom procesu. Očistite existujúce záznamy, stanovte pravidlá porovnávania a pretrvávania, a až potom zavádzajte riadené pracovné postupy na vytváranie a zmeny údajov, než rozšírite distribúciu.
Osobitnú pozornosť si zaslúži migrácia. Presun nekonzistentných starších záznamov do nového centrálneho systému alebo ERP nevytvára čistý základ. Organizácie potrebujú profilovanie na odhalenie chýb, logiku porovnávania na identifikáciu duplikátov, obohatenie v prípadoch, kde chýbajú polia kritické pre podnikanie, a pravidlá pre výber prevládajúcich hodnôt na určenie, ktoré hodnoty majú prednosť. Niektoré záznamy by sa mali skôr archivovať ako migrovať. Prenesenie zastaraných dodávateľov, neaktívnych materiálov alebo zákazníckych účtov s uplynutou platnosťou do nového prostredia len presúva náklady do nového prostredia.
Každá fáza by mala zahŕňať aktivity zamerané na prijatie zmien. Používatelia musia pochopiť nielen nové obrazovky alebo požiadavky, ale aj to, prečo je dané pole povinné a aký následný proces od neho závisí. Najúspešnejšie programy spájajú v jednom implementačnom pláne prepracovanie procesov, kontrolu údajov, integráciu a zodpovednosť používateľov. Tento integrovaný model realizácie je kľúčovým prvkom prístupu spoločnosti Ective k modernizácii podnikov.
Meranie obchodnej hodnoty po spustení do prevádzky
Spustenie do prevádzky znamená začiatok prevádzkovej kontroly, nie koniec programu. Spoločne sledujte trendy v kvalite údajov, neúspešné integrácie, nevybavené výnimky a ukazovatele obchodných procesov. Ak počet duplicitných záznamov klesá, ale počet výnimiek vo faktúrach nie, problémom môže byť chýbajúce validačné pravidlo, nejasný pracovný postup alebo nadväzujúci systém, ktorý stále používa zastaraný identifikátor.
Správy o vedení by mali obsahovať ako ukazovatele predikcie, tak aj ukazovatele výsledkov. Medzi ukazovatele predikcie patria záznamy spĺňajúce prahové hodnoty kvality, doba riešenia výnimiek a miera úspešnosti rozhraní. Ukazovatele výsledkov zahŕňajú zníženie manuálnej práce, menej pozastavených platieb, rýchlejšie zapojenie nových zamestnancov, vyššiu presnosť prognóz a vyšší podiel priameho spracovania. Vďaka tejto súvislosti sa správa údajov mení z nákladového strediska IT na merateľnú výkonnú schopnosť.
Trvalou hodnotou stratégie integrácie kmeňových údajov nie je len prehľadnejšia databáza. Je ňou schopnosť meniť procesy, zavádzať automatizáciu a prijímať rozhodnutia bez toho, aby sme sa najskôr museli pýtať, či sú základné obchodné údaje spoľahlivé. Ak túto disciplínu zakomponujete do každodenných činností, každá budúca transformačná iniciatíva bude mať pevnejší základ.
