Kvalita dat souvisí s péčí, která se jim věnuje. Primárně jde o procesní záležitost. Ale bez dobré softwarové podpory to nejde. Projekty v překrývajících se oblastech DQ (datová kvalita) a MDM (master data management – centrální správa referenčních údajů) ukazují postupný vývoj řešení. Rozdělíme jej do čtyř fází pojmenovaných jako:

• seznam zákazníků,
• zákaznická dimenze,
• úpravy v dimenzi zákazníků,
• centrální správa zákaznických dat.

Jednotlivé fáze ukážeme na příkladu fiktivní pojišťovny – ABC Insurance. ABC Insurance je firma s dlouhou tradicí, nejvýznamnějším produktem je životní pojištění. Pro něj společnost používá systém Life. O něco novější jsou systémy Car pro pojištění vozidel, Med pro zdravotní pojištění a House pro pojištění nemovitostí.
Ve všech systémech jsou data o klientech. Jeden člověk se v nich může vyskytovat vícekrát, a to dokonce v různých rolích (pojištěný, pojistitel, oprávněná osoba atd.). Roztříštěnost zákaznických údajů do různých systémů nevadí běžnému provozu (sjednávání pojištění, vyplácení plnění) – nestačí ale pro jednotný pohled na zákazníky přes celou firmu.

Obr. 1

Seznam zákazníků

První otázka, která se objevuje hned od počátku, zní: Kolik máme zákazníků? Poměrně triviální otázka. Její odpověď se však v každé větší společnosti hledá těžko. Souvisí to také s tím, že pojem zákazník se chápe v každém oddělení jinak (finance – zákazník je ten, komu se posílá faktura; obchod – zákazník je ten, kdo podepisuje objednávku; provoz – zákazník je ten, kdo využívá konkrétní službu; marketing – zákazník je ten, koho má cenu oslovit). Je to způsobeno i tím, že každý systém může mít různě úplná a aktuální data o konkrétním člověku nebo firmě. Podívejme se třeba na příklad z obrázku 1. Klient Michal Klaus je v jednotlivých systémech uveden s následujícími atributy:

Tab. 1

Všimněme si, že žádné dva záznamy o klientovi Michal Klaus nejsou zcela stejné. Prostým porovnáním údajů (na shodu) můžeme dojít k závěru, že jde o čtyři různé osoby. To, že se jedná o tutéž osobu z údajů uvedených v příkladu, jasně říci nelze. Mohli bychom konstatovat, že jde o osoby mající stejnou adresu a značně podobné (nebo ve dvou případech dokonce shodné) jméno. V reálné situaci pro rozhodnutí o tom, zda jde o stejnou osobu (nebo firmu), slouží pravidla definovaná nad mnoha dalšími atributy (rodné číslo, číslo občanského průkazu, IČO, název obchodní firmy, datum narození).
Technické řešení této úlohy vypadá tak, že všem záznamům z produktových systémů, které odpovídají jednomu a témuž člověku, přiřadíme jedno a to samé číslo. Takto vzniklá skupina představuje jednoho člověka, z této skupiny můžeme vytvořit nový záznam. Ten se obvykle nazývá jako zlatý záznam (golden record), reprezentativní záznam nebo survivor.

Zákaznická dimenze

Získat seznam zákazníků je dostačující například pro jednorázovou marketingovou kampaň. Máme zajištěno, že nebudeme posílat stejnému klientovi ten samý dopis vícekrát. Budeme-li chtít využít zákaznická data, které nám poskytují produktové systémy pro další věci, s prostým seznamem dlouho nevystačíme. Zjistit, jaká je profitabilita, jaké jsou příležitosti pro cross-sell nebo up-sell, jaká je dlouhodobá hodnota zákazníka – k tomu všemu budeme potřebovat více dat. A to v nějakém systému – již dlouho tuto roli dobře plní datové sklady a nad nimi budovaná analytická datová tržiště (data marts).
Datový sklad potřebuje zákaznickou dimenzi – ideálně takovou, kde je každý zákazník právě jednou. Duplicity v dimenzích datového skladu výrazně snižují jeho přínos. Údržba dimenze je vlastně opakovaná tvorba seznamu zákazníků. Od předchozí úlohy se však liší tím, že potřebujeme udržet stabilitu přiřazených čísel. Jde o to, aby reprezentativní záznam o klientovi (Michal Klaus) dostal při každém dalším (inkrementálním) zpracování to samé číslo.

Modifikace zákaznické dimenze

Dalším požadavkem je potřeba změn v této zákaznické dimenzi. Problém zde představuje skutečnost, že při každodenním inkrementálním zpracování může dojít k přepisu změněných hodnot údaji z produktových systémů. Důvodem změn mohou být ruční opravy dat, které nelze provést automaticky, nebo aktualizace dat dle skutečnosti (např. přidání akademického titulu – obr. 2). Řešení spočívá v přidání další tabulky, do které se ukládají instance upravených master záznamů.

Obr. 2

Master data management

Úplné řešení představuje systém, který umožňuje změny provedené v zákaznické dimenzi propagovat zpět do produktových systémů. Představte si, že jako klient přijdete do ABC Insurance s oznámením, že jste se přestěhovali, změnili příjmení nebo získali akademický titul. V mnoha skutečných firmách se vás pracovník pobočky zeptá, jaká máte pojištění, a potom provede úpravy postupně ve všech produktových systémech, kterých se změna týká. Samozřejmě ideální stav je, aby takovou změnu provedl pouze jednou. Nejen, že ho to bude stát méně času, ale hlavně se tím zajistí konzistence změny, protože nedojde k překlepům (přesněji k různým překlepům v různých systémech). Abychom mohli takový stav realizovat, musíme vyřešit úlohu „zpětné propagace“. Tedy zajistit to, aby se změny zákaznické dimenze dostaly zpět do produktových systémů (obr. 3).
Pochopitelně to není snadné, a ani to nemusí být pokaždé možné. Produktové systémy nemohou vždy akceptovat změny přicházející z master dimenze, například z důvodu pevně dané velikosti jednotlivých atributů. Nebo i z důvodů organizačně právních. Změna zákaznických údajů může znamenat změnu smlouvy, přičemž takovou změnu lze provést až po formálním podepsání změnových dodatků ke smlouvě.

Obr. 3

CDI hub

Systém, který takovou úlohu řeší, se nazývá MDM hub (pro zákaznická data CDI hub). CDI je zde zkratka slov customer data integration (integrace zákaznických dat), hub evokuje obraz kola s paprsky, kdy ve středu je náboj kola (hub), ze kterého vycházejí paprsky držící ráfek. CDI hub tvoří centrální místo, kde se setkávají všechny aktualizace zákaznických dat a podle přesně definovaných pravidel se rozšiřují do systémů okolo.

Obr. 4

Příkladem technologie, která řeší úlohu CDI hubu, je Ataccama Master Data Center. Konceptuální schéma MDC znázorňuje na obrázek 4. Vůči okolnímu světu IT systémů je rozhraní MDC tvořeno vrstvou služeb (MDC services) a dávkových rozhraní (MDC connectors). Konektory umožňují přečíst data ze systémů a umožnit jádru MDC vytvoření centrálních „master dat“. Integrální součástí je nástroj pro datovou kvalitu DQC – Data Quality Center. Aplikace využívají služeb MDC přes rozhraní webových služeb (v konceptu SOA – service oriented architecture). Takovou službou může být právě aktualizace vaší adresy v centrálních datech. MDC server pak sám zajistí propagaci všech změn do dotčených systémů podle nakonfigurovaných pravidel, nebo přípravu dat (např. ve formě tzv. žádanek) pro manuální vstup.
MDC poskytuje pro jednotlivé úrovně řešení příslušnou podporu:

Tab. 2

Autor je produktovým ředitelem společnosti Ataccama.