Master data management

Důsledkem členění společnosti do business unit a segmentace produktů je to, že ta samá business entita (jako Zákazník, Dodavatel, Produkt) bude obsluhována různými business unitami či produktovými liniemi. To často vede k zakládání redundantních záznamů o těchto entitách v rámci zpracování obchodních případů, kterými se business unity zabývají odděleně a nezávisle.

Typickým příkladem je případ klienta, který již dříve získal od banky hypoteční úvěr. Zároveň mu banka začne posílat nabídky hypotečního úvěru, které neberou v úvahu fakt, že klient již hypoteční úvěr má a o druhý nemusí mít zájem nebo by mu ho banka ani nebyla ochotná poskytnout. K tomu dojde například kvůli tomu, že marketingové oddělení rozesílající nabídky na nové hypotéky pracuje s externí databází potenciálních klientů a nekontroluje, zda klient z tohoto seznamu není již náhodou klientem banky. To může vést k nepříjemným situacím, kdy klient začne pochybovat o serióznosti zasílaných nabídek a banky jako takové. Problému by se dalo předejít, kdyby se banka pokusila propojit záznamy z obou seznamů.

Běžným případem, kdy se velké společnosti setkají s velkými problémy souvisejícími s řízením master dat jsou fúze nebo akvizice. Každá spojující se organizace většinou vytvoří duplicitní master data, protože obě ze spojujících se firem měly před spojením alespoň jednu databázi s master daty. V ideálním případě se problém vyřeší deduplikací dat ještě během procesu spojování. V praxi ale rekonciliace různých master dat představuje problém kvůli závislostem aplikací na databázích s master daty. V důsledku toho systémy obou spojujících se organizací často zůstávají v provozu a je zaveden zvláštní systém pro rekonciliaci dat, tak aby oba systémy byly konzistentní. V průběhu času však dochází k dalším fúzím a akvizicím, přibývají nové a nové databáze master dat a rekonciliace nabývají komplexity, stávají se de facto neřiditelnými a nespolehlivými.

Další problém spočívá v určení odpovídajícího stupně detailu a normalizace dat. Např. v jednotném HR systému se společnost rozhodne udržovat pouze základní data jako datum nástupu, datum posledního povýšení atd. Tento jednoduchý přístup nemusí vyhovovat závislým systémům, které potřebují mnohem detailnější informace k procesu nástupu uživatelů, plánům odchodu do penze apod. Vlastníkům těchto závislých systémů pak nezbyde nic jiného než začít budovat paralelní síť rozhraní pro získávání těchto dat, což povede proti cílům master data managementu.

V procesu řízení master dat se můžeme setkat s několika rolemi. Dvě hlavní role, které je dobré rozlišovat jsou Vlastník dat a Správce dat. V praxi funguje v těchto rolí často v organizaci více lidí. Každý z nich se může zaměřovat na různou podskupinu dat (např. zákaznická data, data o zaměstnancích).

Vlastník dat je zodpovědný za kvalitu dat, jejich bezpečnost, soulad s legislativními požadavky a procesy pro řízení dat.

Správce dat zajišťuje aktualizaci dat jménem Vlastníka.

Master data management může být chápán jako "disciplína zlepšování kvality"[3], které je definované v předpisové základně týkající se řízení dat v organizaci. Jeho cílem je poskytovat procesy pro sběr dat, jejich agregace, spojování, konsolidaci, zajištění kvality a distribuci master dat napříč organizací pro zajištění stejného chápání, konzistence, přesnosti a kontroly[4] v údržbě dat a jejich použití aplikacemi.

Nástroje master data managementu mohou podporovat deduplikaci dat, jejich standardizaci[5] a pravidla pro eliminaci nesprávných dat ještě před jejich zadáním do systému pro vytvoření autoritativního zdroje master dat. Master daty jsou např. produkty, účty a subjekty, pro které se pořizují transakční záznamy.

Existuje řada modelů pro implementaci řešení pro řízení master dat. Jedná se např. o:

1. Zdroj záznamu
2. Registr
3. Konsolidace
4. Koexistence
5. Transakce

V tomto modelu identifikujeme jednu aplikaci, databázi nebo jiný zdroj (např. list tabulkového procesoru) jako "zdroj záznamu" (nebo "systém záznamu", na nějž aplikační databáze výhradně spoléhají). Výhodou tohoto modelu je jeho jednoduchost. Ne vždy ale může vyhovovat složitějším situacím distribuce master dat ve větších organizacích.

Zdroj záznamu může být federovaný, např. ve smyslu skupin atributů záznamu (kde různé atributy přicházejí z různých zdrojů záznamu) nebo geograficky (kde různé části organizace mají různé zdroje záznamu). Federovaný přístup je možný pouze v těch případech, kde je jasné vymezení toho, jaké části záznamů budou nalezeny v jakých zdrojích.

Model zdroje záznamu může být uplatněn např. i na referenční data.

V tomto modelu existuje centrální registr spojující záznamy z různých zdrojových systémů. Identifikuje duplicity pomocí čistících a ztotožňujících algoritmů, přiřazuje unikátní globální identifikátory k propojeným záznamům pro identifikaci "jedné verze pravdy". V tomto modelu nejsou data zasílána zpět do zdrojových systémů, takže změny dat se dále pořizují v existujících zdrojových systémech. Když je třeba jeden celkový pohled na data, systém referencí je použit pro vytvoření tohoto view v reálném čase.

Tento model je výhodný, pokud organizace má velké množství zdrojových systémů a je obtížné vytvořit autoritativní zdroj. Umožňuje analyzovat data bez rizika přepsání dat ve zdrojových systémech.

V tomto modelu se master data obecně konsolidují z několika zdrojů pro vytvoření jedné verze pravdy, často nazývané "golden record". Jakékoli aktualizace master dat proběhnou primárně v centrálním systému a následně se aplikují i do zdrojových systémů.

Tento model poskytuje "golden record" stejným způsobem jako model Konsolidace, ale změny master dat se mohou udát jak v systému pro řízení master dat (MDM), tak v jednotlivých aplikacích. Tento rys vede k nákladnější implementaci.

Hlavní výhodou tohoto přístupu je, že data mohou být spravována ve zdrojových systémech a následně synchronizována s centrálním systémem, přičemž je stále zaručena jedna verze pravdy.

V tomto modelu jsou atributy master dat udržovány pomocí algoritmů propojování, čištění, ztotožňování a obohacování k zlepšení kvality dat. Obohacená data mohou být publikována zpět do zdrojových systémů. Toto vyžaduje oboustranou interakci se zdrojovými systémy. Zdrojové systémy mohou odebírat aktualizace publikované centrálním systémem pro zajištění úplné konzistence dat.

Hlavní výhodou tohoto přístupu jsou přesná a úplná master data v každém okamžiku.

Existuje řada způsobů jak mohou být master data skládána a distribuována do dalších systémů.[7] Příkladem jsou:

1. Konsolidace dat – Proces získání dat z mnoha zdrojů a jejich integrace do centrálního systému (Operativní úložiště dat) pro replikaci do cílových systémů.
2. Federace dat – Proces poskytnutí jednoho pohledu na master data pocházejících z mnoha zdrojů pro mnoho cílových systémů.
3. Propagace dat – Proces kopírování master dat z jednoho systému do dalšího, typicky prostřednictvím legacy rozhraní bod-bod.