UNICORN COLLEGE. Bakalářská práce

UNICORN COLLEGE

Katedra informačních technologií

Bakalářská práce

Master Data Management - Teorie unifikace dat

Autor BP: Rostislav Česnek Vedoucí BP: Ing. Miroslav Žďárský

2014 Praha

Čestné prohlášeni Prohlašuji, že jsem svou bakalářskou práci na téma Master Data Management – Teorie unifikace dat vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne 26. 4. 2014

………………………… Rostislav Česnek

Poděkování Děkuji vedoucímu bakalářské práce Ing. Miroslavovi Žďárskému za odbornou pomoc při zpracování mé bakalářské práce.

Master Data Management - Teorie unifikace dat Master Data Management – Data unification theory

4

Abstrakt Cílem bakalářské práce je popsat a přiblížit čtenáři základní pojmy a problematiku Master Data Managementu. V bakalářské práci jsou zachyceny základní pojmy, způsoby implementace Master Data Managementu a obecné principy a postupy při unifikaci klientských dat. Dále jsou popsány reálná unifikační pravidla nastavená ve společnosti Equa bank a.s. Při zpracování práce bylo čerpáno nejenom z informačních zdrojů, tištěných a elektronických, ale také z osobních konzultací se spolupracovníky ve společnosti Equa bank a.s. Hlavní přínos je ve zmapování reálných unifikačních pravidel a zpracování těchto informací v ucelené formě. Práce je rozdělena do dvou celků, teoretické a praktické části. Teoretická část popisuje základní pojmy, přibližuje jednotlivé implementační styly a zmiňuje obecné principy a doporučené postupy, které se využívají při unifikaci klientských záznamů. Praktická část popisuje unifikační pravidla, jak jsou nastavena ve společnosti Equa bank a.s. Klíčová slova Master Data Management (MDM), Operational Data Store (ODS), Data warehouse (DWH), master data, Jaro-Winkler, unifikace, informace

5

Abstract The aim of the thesis is to describe and familiarize the reader with the basic concepts and problems of Master Data Management. The thesis captures basic concepts, ways of implementations of Master Data Management and general principles and procedures for the unification of client data. The thesis also describes the real unification rules set at Equa bank a.s. During elaboration information were drawn not only from printed and electronic sources, but also from personal consultations with colleagues at Equa bank a.s. Main contribution of this work is to describe the real unification rules and processing of such information in a concise form. The work is divided into two parts, theoretical and practical part. The theoretical part describes the basic concepts, approaches and different implementation styles, mentions general principles and best practices that are used in the unification of client records. The practical part describes the unification rules as they are set at Equa bank a.s. Keywords Master Data Management (MDM), Operational Data Store (ODS), Data warehouse (DWH), master data, Jaro-Winkler, unification, information

6

Obsah 1

2

Úvod............................................................................................................................... 9 1.1

Struktura práce ........................................................................................................ 9

1.2

Omezení práce ......................................................................................................... 9

Master Data Management ............................................................................................ 10 2.1

Definice master dat ............................................................................................... 10

2.2

Definice Master Data Managementu .................................................................... 11

2.3

Definice Master Data Management systému ........................................................ 12

2.3.1

Master Data domény ...................................................................................... 13

2.3.2

Způsoby použití ............................................................................................. 15

2.3.3

Systém záznamu vs Systém odkazu............................................................... 18

2.3.4

Konzistence dat .............................................................................................. 19

2.4 3

Shrnutí kapitoly ..................................................................................................... 20

Realizace Master Data Managementu ......................................................................... 21 3.1

Master Data Management Implementační styly ................................................... 21

3.1.1

Konsolidace ................................................................................................... 21

3.1.2

Registr ............................................................................................................ 22

3.1.3

Koexistence .................................................................................................... 23

3.1.4

Transakce ....................................................................................................... 24

3.1.5

Výhody a nevýhody implementačních stylů .................................................. 26

3.2

Best practises ......................................................................................................... 27

3.3

Shrnutí kapitoly ..................................................................................................... 28

4

Přínosy Master Data Managementu ............................................................................. 29

5

Teorie unifikace klientských dat .................................................................................. 31 5.1

Unifikační pravidla................................................................................................ 31

5.2

Atributy a kategorie atributů ................................................................................. 31

5.3

Identifikace zákazníka, porovnávání záznamů ..................................................... 32

5.3.1

Porovnávání záznamů .................................................................................... 32

5.4

Jaro-Winklerova vzdálenost .................................................................................. 34

5.5

Shrnutí kapitoly ..................................................................................................... 36

7

6

Unifikace klientských dat ve společnosti Equa bank a.s. ............................................ 37 6.1

Equa bank a.s. ....................................................................................................... 37

6.2

Představení části prostředí DWH ve společnosti .................................................. 37

6.3

Unifikační algoritmus............................................................................................ 39

6.3.1

Standardizace atributů.................................................................................... 39

6.3.2

Identifikace FO/FOP/PO................................................................................ 40

6.3.3

Vytvoření kandidátských skupin ................................................................... 40

6.3.4

Unifikační mechanismus kandidátských skupin ............................................ 41

6.4

Aktuální stav a výhled do budoucna ..................................................................... 50

6.5

Shrnutí kapitoly ..................................................................................................... 50

7

Závěr ............................................................................................................................ 51

8

Literatura a použité zdroje ........................................................................................... 52

9

Seznam obrázků ........................................................................................................... 54

10

Seznam tabulek ............................................................................................................ 55

8

1

Úvod

Každá organizace potřebuje ke svému správnému fungování a rozhodování kvalitní data. Základními požadavky na tato data je jejich kvalita a zajištění jejich dostupnosti. Těmito požadavky se zabývá Master Data Management (dále jen MDM). Ať se jedná o data o zákaznících, produktech nebo službách, MDM na tato data poskytuje ucelený pohled. V poslední době o MDM začíná projevovat zájem stále více organizací, jelikož svá data chtějí efektivně spravovat. Cílem bakalářské práce je přiblížit a popsat problematiku MDM. Bude blíže popsána unifikace klientských dat (obecné principy a doporučené postupy), jako jedna z částí MDM. Následně budou popsána pravidla tak, jak mohou být nastavena v praxi.

1.1 Struktura práce Práce je rozdělena do dvou celků, teoretické a praktické části. Teoretická část se skládá ze čtyř kapitol. Kapitola 2 (Master Data Management) popisuje základní pojmy MDM, MDM systém a způsoby použití. Kapitola 3 (Realizace Master Data Managementu) přibližuje jednotlivé implementační styly, jaké jsou v MDM systémech využívány, a jejich srovnání. Kapitola 4 (Přínosy Master Data Managementu) popisuje jednotlivé přínosy MDM. Kapitola 5 (Teorie unifikace klientských dat) zmiňuje obecné principy a doporučené postupy, které se využívají při unifikaci klientských záznamů. Praktická část se skládá pouze z jedné kapitoly. V kapitole 6 (Unifikace klientských dat ve společnosti Equa bank a.s) jsou zmapována unifikační pravidla, jak jsou nastavena ve společnosti Equa bank a.s.

1.2 Omezení práce Pro čtení této práce se předpokládá znalost základních pojmů z oboru datových skladů. Práce není určena pro úplné začátečníky v tomto odvětví.

9

2

Master Data Management

V této kapitole budou popsány základní pojmy a principy Master Data Managementu. Cílem je pochopení veškerých základních informací z poměrně obsáhlé oblasti dané problematiky.

2.1 Definice master dat Řízení klíčových dat bylo pro organizace vždy důležité. Pro danou společnost je nutné vědět, kdo jsou její zákazníci, jaké produkty a služby nabízí, jaké má vztahy s dodavateli a zákazníky. Ať se jedná o banku, prodejce nebo vládní organizaci, každá organizace využívá základní data v rámci celého podniku. Zpravidla se tato data využívají k otevírání nových účtů, zavádění nových produktů na trh nebo ke zjištění které výrobky můžeme jakým zákazníkům nabídnout. Tento soubor základních dat se nazývá master data. Master data jsou nejcennější informace, které podnik vlastní. Mezi typické oblasti master data patří: •

zákazníci,

•

zaměstnanci,

•

produkty,

•

adresy (lokality),

•

dodavatelé. Dále je součástí master dat i vztah mezi výše uvedenými oblastmi. Každá z těchto

oblastí reprezentuje informace, které jsou potřebné v různých podnikových procesech, přes organizační jednotky, mezi operačními systémy a v systémech pro podporu rozhodování. Master data v podstatě definují podnik jako takový. Master data zachycují klíčové informace, na kterých se musí všechny části organizace dohodnout, a to jak na významu, tak i využití. Například je důležité, aby všechny části organizace sdílely informaci o tom, co definuje zákazníka, jací zákazníci existují, kde mají zákazníci bydliště (sídlo), a jaké produkty nebo služby si zákazníci koupili, nebo jaké jim byly nabídnuty. Porozuměním těmto informacím vede k prevenci neúmyslného jednání, jako například k zaslání účtu nebo výpisu na špatnou adresu, nebo naopak může poskytnout významnou obchodní příležitost.

10

2.2 Definice Master Data Managementu Níže bude popsáno několik definic od společností na trhu, které se problematikou MDM zabývají. Dle společnosti Adastra [1]: „Master Data Management je souhrnnou sadou business procesů, přístupů, metodologií a nástrojů IS/ICT, která centrálně a stabilně definuje a spravuje klíčová data organizace (také nazývána Master Data). Úkolem MDM je zajistit, aby se nejdůležitější data pocházející z různých zdrojů dostala včas, spolehlivě a v potřebné kvalitě na všechna místa, kde jsou potřebná či užitečná“ Dle firmy IBM [2]: „MDM je disciplína, která poskytuje konzistentní porozumění klíčových datových entit a jejich vztahů a hierarchií. MDM je klíčovým prvkem pro řešení problémů s velkými daty.“ Dle společnosti Oracle [3]: „Master Data Management (MDM) je kombinace aplikací a technologií, které konsolidují, čistí, a zvyšují význam master dat. Synchronizuje jej se všemi aplikacemi, obchodními procesy a analytickými nástroji. To má za následek významné zlepšení provozní efektivity, reporting, a rozhodování založené na faktech.“ Dle firmy Microsoft [4]: „Správa kmenových dat je soubor zásad a postupů, které se používají k vytvoření a udržení master dat ve snaze překonat mnoho problémů spojených se správou master dat“ Z výše uvedených definic lze odvodit, že MDM je klíčovým prvkem širší podnikové informační strategie řízení. MDM hraje klíčovou roli v informační architektuře jako poskytovatel a správce master dat v podniku. Tato strategie musí vycházet z obchodních potřeb společnosti od současného stavu až po budoucí vývoj IT prostředí. Například, v rámci podnikání je potřeba, aby byl umožněn cross-sell mezi různými podnikatelskými činnostmi dané společnosti. Ve velké organizaci může být toto řízeno MDM systémem. V ostatních případech (například v bankách) je například nutné dodržovat zásady proti praní špinavých peněz, kdy je potřeba, aby systém detekoval potenciálně podvodné aktivity a aktuálně na ně reagoval. V rámci této preventivní aktivity mohou do MDM systému vstupovat data z World-Check databáze, kde jsou uchovávány informace o potenciálně podezřelých subjektech. Z těchto příkladů lze odvodit potřeby, které by měl MDM systém zajišťovat. MDM systém by měl: •

poskytovat konzistentní, srozumitelná a důvěryhodná master data o jednotlivých subjektech,

11

•

poskytovat mechanismus pro konzistentní používání master dat v celé organizaci,

•

být navržen tak, aby se dokázal přizpůsobit a zvládal spravovat případné změny. K dosažení těchto cílů je zapotřebí mít správně navržen MDM systém tak, aby byl

schopen řídit master data a poskytovat tato data uživatelům a ostatním systémům. Při dosažení těchto cílů může nastat i změna uvnitř organizace.

2.3 Definice Master Data Management systému Master Data Management Systémy zpravidla poskytují organizaci spolehlivá data. Je potřeba si ale říci o jaký druh dat jde, jak bude s těmito daty pracováno, a jak MDM systém bude integrován do stávajících systémů v dané organizaci. Následující informace jsou čerpány z [5]. MDM řešení obsahuje tři základní dimenze. Tyto dimenze jsou: •

master data domény,

•

metody užití,

•

implementační styly.

V této části budou popsány první dvě jmenované. Implementační stylům bude věnována následující samostatná kapitola. Je důležité ale zmínit, že daná organizace zpravidla nenasadí MDM systém, který by od spuštění pracoval se všemi doménami napříč všemi metodami užití. Organizace obecně nejdříve pracují s daty v omezeném rozsahu, který poskytuje největší návratnost investice v relativně krátkém časovém měřítku. Postupně jsou do MDM systému zahrnuty další domény, metody užití se mohou rozšiřovat a implementační styly mohou změnit přidanou obchodní hodnotu. Někdy je možné se setkat s termínem „Multiform MDM“, který je používán k popsání MDM systémů podporujících tyto tři dimenze. Na následujícím obrázku jsou tyto tři dimenze graficky znázorněny.

12

Obrázek 1: Dimenze Master Data Systému Zdroj: [5]

2.3.1 Master Data domény V rámci vývoje Master Data Managementu došlo v posledních několika letech k rozdělení a vytvoření dvou klíčových částí Master Data Managementu: •

zákaznická data – Customer Data Integration (CDI),

•

produktová data – Product Information Management (PIM). CDI a PIM mají hodně společného ale také hodně rozdílného. CDI systém se

zaměřuje na vedení lidí a organizací. Systém CDI může agregovat data z ostatních systémů, spravovat tato data a předávat do dalších systémů jako například účetní systémy, systémy pro řízení kampaní nebo CRM systémy. PIM systém spravuje definice a životní cyklus hotových produktů nebo služeb. Sbírá informace o produktech z většího množství zdrojů, dostává schválené definice produktů a ty poté může publikovat na webové stránky společnosti, do marketingových systémů atd. Je třeba podotknout, že v organizacích se také často využívá Product Lifecycle Management (PLM) systém. Ten je ale od PIM odlišný. PLM se spíše využívá na design a vývoj produktů, než na přípravu informací o produktech pro podporu prodeje a distribuci. Nachází se zde přirozený tok informací z PLM do PIM při přechodu informací z vývoje produktů do marketingu a prodeje. S postupným vývojem těchto dvou klíčových částí se často začaly objevovat vztahy mezi nimi. I když se CDI zaměřuje na data o zákaznících, je výhodné, aby obsahoval reference na produkty nebo účty, které zákazník má. Stejně tak PIM potřebuje obsahovat 13

reference na zákazníky a dodavatele produktů a služeb. Tyto vztahy napříč jednotlivými oblastmi se staly významným aspektem MDM systémů. Každá společnost má zájem uchovávat jiná master data, která jsou odvozená od jejích cílů podnikání. Finanční instituce bude požadovat uchovávat jiné informace než například stavební firma. Obecně ale platí, že master data jsou rozdělena podle tří základních otázek: kdo, co a jak. Každá z těchto otázek je spojena s jednou ze tří domén master dat (subjekt, produkt a účet). Všechny tyto domény obsahují určitou třídu informací. Doména „subjekt“ (anglicky se označuje jako „party“) obsahuje informace o jakýchkoliv osobách nebo organizacích. Doména „produkt“ může obsahovat informace o produktech, jaké subjekty jej nabízejí nebo používají. Doména „účet“ popisuje, jak je subjekt spojen s produktem, který nabízí nebo vlastní. Dále mezi daty mohou být informace o umístění (lokalita). Toto je často spojeno s jednou ze tří domén. Společnosti zpravidla zajímá, kde zákazník bydlí, kde se produkt nabízí atd. Na následujícím obrázku je ukázáno, jak se jednotlivé domény překrývají, a jak je s nimi propojena informace o lokalitě.

Obrázek 2: Domény master dat Zdroj: [5]

Master data domény mohou být vytvořeny specificky pro jednotlivá odvětví pomocí standardů a modelů určených pro dané odvětví. Použití těchto informací může výrazně snížit náklady na integraci. V následující tabulce je uveden seznam některých standardů a modelů využívaných v několika odvětvích.

14

Standard or Industry Industry model Banking IBM Information Framework (IFW) Interactive Financial eXchange (IFX) Insurance IBM Insurance Application Architecture (IAA) Association for Cooperative Operations Research and Development (ACORD) Telecoms Shared Information/Data Model (SID) IBM Telecommunications Data Warehouse

Web Resources www-306.ibm.com/software/data/ips/products/ industrymodels/ www.ifxforum.org www-306.ibm.com/software/data/ips/products/ industrymodels/ www.acord.org

www.tmforum.org www-306.ibm.com/software/data/ips/products/ industrymodels/telecomm.html

Retail

Association for Retail www.nrf-arts.org Technology Standards (ARTS) IBM Retail Data Warehouse www-306.ibm.com/software/data/ips/products/ industrymodels/retail.html Healthcare Health Level 7 (HL7) www.hl7.org Tabulka 1: Některé průmyslové standardy a modely Zdroj: [5]

MDM systém podporuje jednu nebo více master data domén. Domény mohou být využívány na základě standardů, nebo mohou být vytvořeny nebo upraveny specificky pro určité odvětví.

2.3.2 Způsoby použití U MDM se rozlišují tři způsoby použití. Dle [5] je lze definovat jako: •

operational (provozní),

•

analytical (analytický),

•

collaborative (kolaborativní). Pod kolaborativním způsobem použití si lze představit, jak MDM systém

koordinuje skupinu uživatelů a systémů ve snaze dosáhnout schválené sady master dat. Při provozním použití se MDM systém podílí na transakcích a provozních procesech společnosti, kdy interaguje s ostatními systémy a uživateli. Při analytickém použití je MDM systém používán jako zdroj informací pro ostatní analytické systémy, někdy také jako zdroj sám sobě.

15

Obrázek 3: Znázornění MDM domén a metod použití Zdroj: [5]

2.3.2.1 Kolaborativní MDM Kolaborativní MDM se zabývá procesy podporující autorizaci master dat, jako například vytváření, definování, pozměňování nebo schvalování master dat. Klasickým příkladem použití je v PIM systému. Asi nejtypičtějším případem je zavedení nového produktu na trh, kdy se definují jednotlivé vlastnosti produktu, kde bude prodáván, jak je produkt klasifikovaný, jaké má například bezpečnostní informace atd.

2.3.2.2 Provozní MDM V rámci provozního MDM se MDM server chová jako Online-Transaction Procesing (OLTP) systém, který reaguje na požadavky různých aplikací a uživatelů. Provozní MDM se zaměřuje na poskytování jednotného pohledu na master data v jednotlivých transakčních systémech v prostředí s vysokým výkonem. Typickým příkladem použití provozního MDM je proces otevírání nového účtu. Ať se jedná o účet bankovní nebo například o účet u společnosti poskytující kabelovou televizi, přes MDM služby se zkontroluje, jaké informace o zákazníkovi má již organizace k dispozici. Účet mu mohl být nabídnut třeba v rámci speciální nabídky, dle které by byly

16

poté nastaveny parametry účtu. Pokud nejsou informace o zákazníkovi k dispozici, tento zákazník je v MDM systému vytvořen a následně je mu založen nový účet. Pro provozní MDM je široká škála možností využití. V rámci řízení MDM dat může být používáno stovky služeb poskytující přístup k jednotlivým druhům.

2.3.2.3 Analytické MDM V rámci analytického MDM se jedná o průsečík mezi Business Intelligence (BI) a MDM. BI je široká oblast, která v sobě zahrnuje reporting pro různá oddělení, datové sklady, datamarty a mnoho dalších oblastí. Je třeba, aby BI mělo vždy smysluplná a důvěryhodná data. Mezi MDM a BI jsou důležité tři hlavní průsečíky: •

MDM jako důvěryhodný zdroj dat - klíčovou rolí MDM systému je poskytování čistých a konzistentních dat pro BI systémy.

•

Analýzy na MDM datech - MDM systémy samy o sobě mohou integrovat reporting a analýzy pro poskytování informací nad daty spravovaných v rámci MDM systému.

•

Analýzy jako klíčové funkce v MDM systému - klíčovým rysem některých MDM systémů mohou být specializované druhy analýz. Jedním ze společných důvodů pro čisté a konzistentní master data je potřeba

neustále zlepšovat kvalitu rozhodování. Používání MDM systémů jako zdroj dat pro BI systémy je běžný ale hlavně důležitý způsob užití. Data, která BI systém využívá, musí být vysoce kvalitní, pokud mají být důvěryhodná výsledná zpracování dat v podobě analýz a reportů. Z tohoto důvodu jsou MDM systémy často klíčovým zdrojem informací pro datové sklady, datamarty, Online Analytical Processing (OLAP) kostky, a další BI struktury. Běžné datové modely (schémata), které se využívají v datových skladech, se nazývají „hvězda“ nebo „sněhová vločka“. Tato schémata reprezentují vztah mezi fakty a dimenzemi, přes které se vytvářejí různé analýzy. Velice často jsou master data domény stejné jako dimenze, které se používají v analytických nástrojích. Tato skutečnost dělá z MDM systému přirozený zdroj dat pro BI systémy. Výsledné analýzy nebo reporty z BI systémů mohou být na druhou stranu použity jako zdroj dat pro MDM systém. Poté může být například zákazníkovi při objednání nebo rezervaci nějaké služby rovnou nabídnuta kombinace produktů, která je vydefinovaná na základě reportů nad daty jeho nákupů produktů nebo využívání služeb.

17

Reporting může být také prováděn přímo samotným MDM systémem. Některé MDM systémy mají v sobě integrována pravidla, pomocí kterých mohou detekovat různé události. Pokud si třeba zákazník za dobu posledních pěti měsíců změnil vícekrát svoji kontaktní adresu, může na tuto skutečnost MDM systém upozornit, aby společnost kontaktovala častěji daného zákazníka pro ověření jeho adresy. Posledním druhem analýzy v MDM systému je případ, kdy má MDM systém k dispozici některé klíčové informace. Na základě analýzy jmen, adres nebo telefonních kontaktů může zjišťovat vztahy mezi entitami v master datech. Tímto mohou být například odhaleny potencionální pokusy o podvod. Analytické MDM zahrnuje celou řadu možností. Naplnění externích analytických prostředí, jako jsou datové sklady, s daty z MDM systému vyžaduje integraci informačních nástrojů pro efektivní přenos a transformaci informací z MDM systému. Integrace s analytickými nástroji je nutná, pokud je požadováno zobrazení klíčových ukazatelů výkonnosti a jejich změn v průběhu času.

2.3.3 Systém záznamu vs Systém odkazu Cílem MDM systému je poskytnout organizaci spolehlivá master data. Ideálně by měla být jediná kopie master dat řízená MDM systémem. Všechny aplikace, které potřebují master data by měly být obsluhovány tímto systémem a všechny aktualizace master dat by měly být prováděny taktéž přes tento systém. Takto ideální stav se nazývá systém záznamu „System of Record“. V tomto případě jsou data zpracovávaná MDM systémem brána jako nejlepší zdroj informací.

Jednotlivé aplikace si svoje informace ověřují vůči datům

v MDM systému. V praxi je ale tohoto stavu velmi těžké dosáhnout. Zpravidla tomu brání: •

Složitost a investice do stávajícího IT prostředí.

•

Master data jsou uzamčena v „zabalených“ aplikacích.

•

Požadavky na výkon, dostupnost a škálovatelnost v komplexním a geograficky distribuovaném světě.

•

Právní omezení, která omezují pohyb dat přes geopolitické hranice.

Všechny tyto faktory přispívají k potřebě mít kopie master dat, někdy dílčí sady, někdy zcela redundantní repliky dat. Tyto kopie master dat mohou být použity jako integrované a synchronizované rozšíření MDM systému. Když je známo, že jsou tyto kopie master dat synchronizovány se systémem záznamu (tato synchronizace je řízená v souladu se zachováním kvality a integrity dat v obou kopiích dat a systému záznamu), tak tuto

18

kopii nazýváme systém odkazu – „Systém of Reference“. I když je kopie synchronizována se systémem záznamu, nemusí být vždy aktuální. Změny v systému záznamu mohou probíhat pravidelně v dávkách, a poté jsou distribuovány do systému odkazu. Systém odkazu je brán jako spolehlivý zdroj dat, jelikož je pravidelně synchronizován se systémem záznamu. Systém odkazu má nejlepší využití jako read-only zdroj informací se všemi aktualizacemi, které přicházejí ze systému záznamu. Na následujícím obrázku je zobrazeno jednoduché prostředí, kde systém záznamu agreguje, čistí a řídí data z více zdrojů a dále data poskytuje systému odkazu. V této souvislosti se v rámci prostředí používají dva výrazy Řízené - „Managed“ a Neřízené – „Unmanaged“, pomocí kterých se definuje rozsah jednotlivých MDM prostředí. V řízeném prostředí by každý zdroj měl plnit pouze jeden systém a každý konzument informací by měl tyto informace dostávat pouze z jednoho systému.

Obrázek 4: Systém záznamu a Systém odkazu Zdroj: [5]

2.3.4 Konzistence dat Při popisu kopírování dat, jak je zmíněno v předchozí podkapitole, vyvstane ihned otázka, jak je zajištěna konzistence kopírovaných dat. Lze rozlišit dva základní typy konzistencí: •

absolutní konzistence,

•

konvergentní konzistence. Absolutní konzistencí je myšlen případ, kdy je informace identická napříč všemi

kopiemi po celou dobu, kdy je systém dostupný. V distribuovaném prostředí se absolutní

19

konzistence běžně dosahuje pomocí dvoufázového potvrzovacího protokolu, který se používá ve většině distribuovaných databází nebo v transakčních systémech. Nevýhodou tohoto typu je, že pokud je potřeba při nějaké transakci replikovat informaci do několika systému, a jeden z těchto systémů není dostupný, neprovede se replikace dat do žádného ze systémů. I když je tento způsob široce rozšířen, není vždy žádaný. Konvergentní konzistence je alternativní způsob, jak poskytovat konzistentní data napříč systémy. Základní myšlenka je taková, že se změnou dat v nějakém systému se tato data následně odešlou do dalších systému. Tyto změny mohou být distribuovány v jednotlivých dávkách, které mohou být nastaveny v určitém časovém intervalu. Při odesílání těchto dávek, mohou být aktualizace informací v ostatních systémech opožděny v závislosti na frekvenci odesílání dávek. Jakmile přestanou přicházet aktualizace dat, měly by všechny systémy mít stejná data. Výhoda tohoto způsobu je, že každý systém může pracovat nezávisle a zpracuje přeposílanou aktualizaci ke spokojenosti příjemce. Zpoždění změny propagované skrz systémy se může změnit nastavením frekvence posílání dávek s aktualizacemi. Na druhou stranu je ale třeba zajistit prevenci nechtěného chování při konfliktu s aktualizací dat. Každá z těchto strategií má svá pro a proti a je třeba zvážit, v jakém případě je lepší použít jednu z nich.

2.4 Shrnutí kapitoly V úvodu kapitoly byly vysvětleny základní pojmy Master Data Managementu. Následně byl popsán Master Data Management Systém, jeho základní domény a způsoby použití. Dále byla rozebrána problematika distribuování dat v MDM systémech a způsoby zajištění jejich konzistence.

20

3

Realizace Master Data Managementu

Tato kapitola bude (po vysvětlení teoretických základních pojmů z předchozí kapitoly) zaměřena na samotnou implementaci MDM. Budou zde popsány základní implementační styly.

3.1 Master Data Management Implementační styly Dle [6] se v souvislosti s MDM nejedná přímo o systém, ale spíše způsob jakým jsou data udržována, přetvářena, spravována a předávána jejich konzumentům. Tyto implementační styly se mohou vyskytovat samostatně ale také v kombinaci. V praxi se vyskytují čtyři hlavní styly: •

konsolidace,

•

registr,

•

koexistence,

•

transakce.

3.1.1 Konsolidace V souvislosti s tímto implementačním stylem se jedná o klasického zástupce analytického MDM. Master data jsou určeny pro potřeby BI, pro vytváření analýz nad nimi. Data z transakčních systémů se kopírují na jedno úložiště tzv. „MDM hub“. Data jsou následně zpravidla distribuována do datového skladu. Při získávání master dat dochází k jejich konsolidaci a očištění případných chyb. Pokud je známo, že jsou data v primárních systémech nekvalitní, mohou se pomocí nastavených pravidel tato data v rámci MDM hubu očistit. MDM hub se v tomto případě stává zdrojem „jediné pravdy“. Při tomto stylu implementace se vytváří tzv. „zlatý záznam“. Jedná se například o záznam zákazníka, kde jsou zkonsolidovány informace o něm z primárních systémů. Tento záznam se pak používá jako ověřený zdroj dat pro různé analýzy nebo reporty. Na obrázku níže je MDM systém zobrazen uprostřed. Získaná data zapíše do datových skladů, ale nezapisuje zpět do primárních systémů. V rámci tohoto stylu však nedochází k očištění dat ve zdrojových systémech, což může být bráno jako nevýhoda. Za datovou kvalitu odpovídají primární systémy.

21

Obrázek 5: Implementační styl Konsolidace Zdroj: [5]

Většina organizací si při prvních fází implementaci MDM systému vybírá přirozeně tento styl. Implementační styl Konsolidace poskytuje hodnotné zdroje pro analytické systémy a dále základ pro styly Koexistence a Transakce.

3.1.2 Registr Registr představuje jednoduchý koncept read-only zdroje master dat v podobě referencí. MDM systém udržuje pouze odkazy na master data v primárních systémech. Drží v sobě minimum informací a jediné, co potřebuje, je unikátní identifikátor (klíč) k záznamům ve zdrojových systémech. Nemusí se jednat o jednoznačné číslo (řetězec), ale může jít o kombinaci určitých polí, jak je zobrazeno na obrázku 7. Registr spravuje pouze tyto identifikátory master dat. Na obrázku 6 je MDM systém vyobrazen opět uprostřed. Nyní však komunikace oproti konsolidaci již probíhá obousměrně.

Obrázek 6: Implementační styl Registr Zdroj: [5]

22

Dotazování v tomto stylu probíhá dynamicky ve dvou krocích. Nejdříve jsou informace vyhledány v registru a je získán identifikátor, pomocí kterého se MDM systém dotazuje již přímo do zdrojových systémů a poskytne uživateli kompletní sadu informací složenou z informací v registru a dodatečných informací z primárních systémů.

Obrázek 7: Názorná ukázka při dotazování při použití stylu Registr Zdroj: [5]

Výhodou tohoto řešení je, že uživatel dostane vždy aktuální data, jelikož jsou získány přímo ze zdroje. Tento styl je poměrně jednoduchý na implementaci, jelikož za kvalitu dat zodpovídají zdrojové systémy. Na druhou stranu je třeba zmínit, že jakýkoliv výpadek některého ze zdrojových systémů postihne i MDM systém, protože nebude schopen dodat kompletní data napříč systémy. Dále je třeba mít na paměti, že jakékoliv změny ve zdrojových systémech musí být zohledněny i v MDM systému. Pokud dojde ke změně struktury, musí být tato změna promítnuta i do MDM systému, aby získávání informací nezpůsobovalo pád systému.

3.1.3 Koexistence Styl koexistence vyžaduje, aby byla master data aktuální napříč všemi systémy. Vytváří se zde také zlatý záznam stejně jako v rámci stylu konsolidace. Zlatý záznam je ale v tomto případě distribuován zpět do zdrojových systémů. Tímto je zajištěno, že budou ve všech systémech stejná master data. Koexistence je vyobrazena na obrázku 8.

23

Obrázek 8: Implementační styl Koexistence Zdroj: [5]

Za kvalitu dat zodpovídá MDM systém. V tomto případě se stává „zdrojem pravdy“. Stará se o správu master dat a jejich distribuci do zdrojových systémů. Nevýhodou tohoto stylu je, že může dojít ke konfliktům při aktualizaci dat, kdy je jeden údaj v různých zdrojových systémech zároveň nahrazen rozdílnou hodnotou. Je potřeba tomuto předcházet pomocí nastavené automatické kontroly a správně navrženého rozhodovacího algoritmu. Dále se může stát, že v jeden okamžik nebudou ve zdrojových systémech stejná data, protože aktualizace dat probíhá zpravidla v dávkách. Dá se tomu bránit větší frekvencí zasílání dávek. Tento styl je proto také náročnější na přenos dat. Výhodou stylu je, že pokud jsou data ve všech systémech aktuální, není zde potřeba dodatečných přenosů dat při práci v systémech.

3.1.4 Transakce Tento styl je nejnáročnější na implementaci. Je zde jedno velké centrální uložiště master dat. Ostatní systémy se k němu připojují. Master data jsou vytvářena a spravována centrálně. Transakční hub je součástí provozní infrastruktury IT prostředí. K tomuto centrálnímu úložišti je připojen frontend, který společnosti využívají pro správu master dat. Zpravidla bývá součástí velkých CRM systémů. Jakákoliv změna master dat provedená přes frontend je pomocí webových služeb distribuována do ostatních systémů.

24

Obrázek 9: Implementační styl Transakce Zdroj: [5]

Výhodou transakčního stylu je, že master data jsou uložena a spravována na jednom místě a tím zajištěna jejich správnost a aktuálnost. Nevýhodou jsou velké náklady při implementaci, kdy při zavádění tohoto implementačního stylu se musí stávající systémy v organizaci upravit tak, aby se staly příjemci master dat z centrálního úložiště.

25

3.1.5 Výhody a nevýhody implementačních stylů Každý ze zmiňovaných stylů má samozřejmě své výhody a nevýhody. Ty dle [5] přehledně zachycuje tabulka 2. Styl Co nabízí

Konsolidace Agregace master dat do společného úložiště pro potřeby reportingu.

Registr Udržuje jednoduchý systém záznamů s odkazy na kompletní data v dalších systémech. Výhodný pro real-time reference.

Koexistence Poskytuje jednotný pohled na master data. Synchronizace změn v ostatních systémech.

Přínosy

Příprava dat pro Kompletní přehled je Předpoklad, že analytické systémy. vytvořen podle potřeby, zůstanou stávající rychlé na vybudování. systémy beze změny. Zaleží na prostředí společnosti. Poskytuje možnost čtení i zápisu.

Transakce Správa jednotného pohledu na master data. Poskytuje přístup ostatním systémům pomocí služeb. Centrální úložiště master dat. Podpora nových systémů.

Nedostatky Pouze pro čtení, ne vždy aktuální data s provozními systémy. Metody Analytické použití

Především na čtení, komplexnější pro správu.

Ne vždy aktuální data Vyžaduje změnu s provozními stávajících systémy. systémů.

Provozní

Kolaborativni, Kolaborativni, Provozní, Analytické Provozní, Analytické

Systém

odkazu

odkazu

odkazu

Tabulka 2: Výhody a nevýhody MDM implementačních stylů Zdroj: [5]

26

záznamu

3.2 Best practises Zavedení MDM systému v praxi tak, aby bylo dosaženo nastavených cílů, není jednoduché. Mnohdy je třeba změnit procesy a integrovat stávající systémy na nový MDM systém. Dle [7] se „best practices“ master data managementu snaží maximalizovat obchodní hodnotu a minimalizovat rizika a nejistoty. Za hlavní součástí je považováno porozumění lidem, procesům a technologiím. Zde jsou uvedeny jednotlivé body best practices dle [7]: 1. Definujte misi, cíle a popište přidanou hodnotu projektu v souvislosti s obhájením rozpočtu, motivací organizace a určení rozsahu. 2. Dohodněte se nejdříve na modelu řízení, než implementujete nějaké nové IT řešení. To umožní, aby se následné problémy řešily snáze, a určíte jasný směr pro business analytiky při nastavování a taxonomii řešení. 3. Business uživatelé musí vlastnit MDM projekt. IT oddělení by mělo v projektu pouze působit jako podpora. 4. Organizační změna a předávání znalostí je největší výzvou master data managementu. Tým, který má na starosti změnu řízení, by měl mít dobře nastavený plán. Měl by dobře znát prostředí zákazníka. Tento skrze řízení a komunikaci řeší problémy v rámci celé organizace. 5. Doporučená IT strategie bude vyžadovat vhodné real-time řízení a nástroje pro zajištění kvality dat. Tyto nástroje musí být schopny čistit data, validovat, provádět integraci a měly by mít pro zákazníka přínos. 6. Workshopy s business uživateli a zajištění pochopení grafických modelových nástrojů je silně doporučeno pro zlepšení komunikace analytické fáze v rámci MDM projektu. 7. Doporučené IT řešení musí brát v úvahu, které softwarové aplikace nejlépe splňují cíle organizace a efektivně využijí náklady na ně. Musí být dobře zvážená pro a proti „standardizovaného“ a „toho nejlepšího“ softwaru. Při posuzování životaschopnosti MDM by měly být brány na zřetel trendy v hardwaru a síťové technologii. Mělo by být myšleno na dopad při dimenzování, řešení výkonosti, zálohování a zabezpečení. Uvedené best practices nejsou samozřejmě jediné. Jedná se spíše o výčet hlavních bodů, na které je třeba myslet. Na internetu je k dispozici vícero blogů, které se problematikou MDM zabývají.

27

3.3 Shrnutí kapitoly V této kapitole byly přiblíženy jednotlivé implementační styly, které se využívají při integraci MDM systému do IT prostředí společnosti. Tyto styly jsou typickými zástupci implementačních stylů, ale ve skutečnosti jich může být mnohem více. Mohou být použity jejich různé kombinace. Na konci kapitoly byly shrnuty jejich výhody a nevýhody a dále byly uvedeny best practices doporučované při implementaci MDM systému.

28

4

Přínosy Master Data Managementu

Dle [5] je jedním z hlavních přínosů zlepšení kvality a konzistence jednotlivých prvků master dat. MDM systém poskytuje jednotný pohled na zákaznická data stejně jako na data o produktech společnosti. Dále poskytuje podporu pro následnou inovaci produktů a služeb společnosti. Některé hlavní přínosy zde budou popsány podrobněji: •

Zvýšení přesnosti informací – Vysoce přesná data jsou důležitá pro lepší rozhodování společnosti. Data z MDM systému se stanou důvěryhodným zdrojem „jediné pravdy“.

•

Zajištění konzistence dat – MDM systém má jedinečnou pozici ve zlepšení konzistence dat napříč všemi systémy v organizaci.

•

Soulad s regulacemi, předpisy a normami – Sníží se hrozba udělení pokut při nedodržení regulatorních požadavků např. od České národní banky.

•

Zajištění „čerstvosti“ dat – Při zpracování zákaznických dat z více systémů může nastat situace, kdy má zákazník v různých systémech uvedeny různé kontakty (adresa, telefonní číslo). MDM systém při zpracování těchto dat určí, která data jsou aktuální.

•

Snížení nákladů a zvýšení efektivity – Snížení nákladů se hlavně promítne ve snížené potřebě distribuci stejných dat do více systémů. S úkony souvisejícími se správou těchto dat bývají často spojeny náklady (infrastruktura, licence).

•

Lepší inovace produktů nebo služeb.

•

Dosažení přesnějších a spolehlivějších reportů – Při používání MDM systému jako zdroje „jediné pravdy“ se stanou reporty vytvářené napříč organizací spolehlivější, než když každé oddělení využívá k reportům rozdílné systémy, v kterých nejsou data očištěna.

•

Lepší informace o zákaznících – Zpracování zákaznických dat probíhá ve více systémech. Při konsolidaci klientských dat v MDM systému je zajištěna lepší informovanost napříč celou organizací. Systém data o zákaznících předává v jednotné formě.

•

Zvýšení

efektivity

marketingových

kampaní

–

Tento

přínos

vychází

z předchozího bodu. Pokud má společnost lepší informace o zákaznících, může

29

lépe cílit jednotlivé marketingové kampaně dle zaznamenaných aktivit jejich klientů. •

Snazší vývoj aplikací. Je třeba si uvědomit, že proces zavedení MDM systému není jeden malý projekt.

Jedná se o běh na dlouhou trať. Uvedené přínosy nejsou jediné. Pro každou organizaci se mohou lišit v závislosti na jejím odvětví a způsobech, jakým chtějí prodávat své produkty a služby.

30

5

Teorie unifikace klientských dat

V této kapitole budou popsány obecné principy, které se používají při unifikaci klientských dat. Budou zde uvedeny jednotlivé atributy, které se při unifikaci používají, a doporučené postupy.

5.1 Unifikační pravidla Konkrétní pravidla při unifikaci klientských dat se liší dle prostředí. Pravidla, která se používají v České republice, mohou být odlišná od těch, která se požívají třeba v USA. Je to dáno lokálním nastavením zápisu jmen, dat narození, rodných čísel apod. V další řadě se může jednat o rozdíly, pro jaký účel jsou unifikovaná data připravována. Tato data se poté mohou distribuovat do různých systémů. Každá společnost pravděpodobně používá jiný systém pro styk se zákazníky. Dále může být rozdíl v know-how firmy. Každá firma má již svá osvědčená pravidla a ty také používá. Podrobněji se pravidlům unifikace věnuje kapitola 6, kde jsou popsána pravidla ve společnosti Equa bank a.s. Následující obecné informace jsou čerpány z [8] stránky 250 až 290.

5.2 Atributy a kategorie atributů Pole, která se používají pro porovnávání zákaznických záznamů, se mohou rozdělit do tří kategorií: •

Identifikační atributy – Identifikační atributy jsou hlavními atributy, pomocí kterých unifikační algoritmus přímo identifikuje zákazníka. Pokud se tyto atributy u dvou nebo více záznamů shodují, je velká pravděpodobnost, že tyto záznamy budou patřit stejnému zákazníkovi. Jedná se zpravidla o RČ, IČO, jméno apod.

•

Diskriminační atributy – Diskriminační atributy se naopak používají k tomu, aby se jednotlivé záznamy nespárovaly. V případě, že otec a syn mají stejné jméno, může se podle rozdílného data narození určit, že tyto záznamy k sobě nepatří.

•

Atributy typu záznamu – V případě těchto atributů se jedná o typ zákazníka u daného záznamu. Nejčastěji se používá rozdělení na fyzickou osobu (FO), fyzickou osobu podnikatel (FOP) a právnickou osobu (PO). Dále se může používat rozdělení

31

dle států, využíváno hlavně u konsolidací klientských adres. Na každý záznam se pak dle jeho typu používají rozdílná unifikační pravidla.

5.3 Identifikace zákazníka, porovnávání záznamů Každý ze záznamů by měl splňovat minimální požadavky na vyplněnost, aby mohl být porovnáván s ostatními v rámci unifikačního procesu. Pokud tomu tak u některého ze záznamu není, může být úplně vyřazen z procesu unifikace, nebo je mu přidělen klíč, pomocí kterého se jednotlivé záznamy spojují dohromady (jedná se z pohledu unifikace o unikátního zákazníka). Zpravidla je vznesen požadavek na doplnění chybějících údajů a v následné unifikaci je tento záznam přidružen k jiné skupině již unifikovaných záznamů. Jak bude s těmito málo vyplněnými záznamy nakládáno, zaleží na požadavcích a nastavení unifikačního procesu v dané organizaci. Cílem porovnávání záznamů je vytvořit skupiny, kde se dle nastavených pravidel shodují jednotlivé atributy. Záznamům v této skupině je pak přiděleno unikátní číslo (klíč), přes které jsou tyto záznamy spojeny. Může být také vyžadováno odstranění duplicit a vytvoření „zlatého záznamu“. Záleží, zda organizace vyžaduje „zlatý záznam“ vytvářet.

5.3.1 Porovnávání záznamů V [8] jsou popsány tři možné varianty porovnávání záznamů. Neporovnávají se pouze atributy, ale také celé záznamy. Nelze říci, že když se u dvou záznamů rovná jméno a příjmení, že se jedná o stejnou osobu. Je třeba kontrolovat i jiné atributy z jednotlivých záznamů. Je třeba se podívat i na RČ nebo datum narození. K porovnávání se primárně používají následující dvě metody: •

Binární porovnávání – U binárního porovnávání platí pouze, zda se porovnávané atributy (záznamy) rovnají, nebo ne. Výsledná hodnota může být pouze True nebo False.

•

Scoring – Shoda dvou atributů nebo záznamů je vyjádřena zpravidla procentuálním ohodnocením, jak moc se porovnávané objekty rovnají. K tomuto se často používá Levenshteinova nebo Jaro-Winklerova vzdálenost. Jaro-Winklerova vzdálenost je popsána v podkapitole 5.4. Může se využívat dále porovnávání oproti „vědomostní“ databázi jako třeba

rejstříku ulic. Tato metoda ale není moc častá, jelikož málo firem má přístup k nějaké obsáhlejší databázi.

32

Jak již bylo zmíněno výše, v [8] jsou popsány tři možné varianty porovnávání záznamů: •

Binární porovnávání jednotlivých atributů a celých záznamů – Atributy se porovnávají na přesnou shodu a záznamy se porovnávají dle nastavených pravidel. Vyhodnocením těchto pravidel pak následně dostaneme hodnotu True nebo False. Musí se třeba rovnat skupina vybraných atributů z jednotlivých záznamů (RČ, Jméno, Příjmení).

•

Binární porovnávání jednotlivých atributů a scoring pro celé záznamy – Atributy se porovnávají na přesnou shodu. Porovnávání atributů je prováděno skrze score. Jednotlivé atributy mají nastaveny váhy a dle jejich shody se poté vypočítá score celého záznamu. Výsledné score se pak porovná s nastavenou mezí (hodnotou), zda je možné tyto záznamy označit jako shodné nebo ne. Nastavení jednotlivých mezí záleží na požadavcích dané organizace.

•

Scoring pro jednotlivé atributy a celé záznamy – Je vypočítáno score podobnosti jednotlivých atributů. Následně se z tohoto vypočítá score celého záznamu. Zde se také nastavují meze, zda jsou tyto záznamy shodné či nikoliv. Nastavení těchto mezí je vidět na obrázku.

Obrázek 10: Definice mezí pro označení shodných záznamů Zdroj: [8]

Je potřeba zde také zmínit jednu situaci, která při unifikaci nastává. Jedná se o tzv. „řetězení“. Pod tímto označením si můžeme představit situaci, kdy se spárují dva záznamy, které by se navzájem nikdy při porovnávání nespojily. Spojí se pomocí třetího záznamu, který se připojí pří porovnávání ke každému z nich. Situace je znázorněna v následující tabulce.

33

Číslo záznamu 1 2 3

Jméno Tomáš Tomáš Tomáš

Příjmení Bezinka Bezinka Bezinka

Adresa Datum narození Nádražní 23, Praha 5 Za skládkou 10, Brno - město 15.9.1975 Nádražní 23, Praha 5 15.9.1975

Tabulka 3: Ilustrace řetězení při unifikaci Zdroj: Vlastní zpracování

První a druhý záznam z tabulky by se při unifikaci nikdy nespojily, jelikož mají stejné pouze jméno a příjmení. Objeví se ale třetí záznam, který se s předchozími dvěma záznamy spojí přes adresu a datum narození. Tímto spojí zároveň i tyto dva záznamy.

5.4 Jaro-Winklerova vzdálenost V popisu unifikačních pravidel v kapitole 6 je zmiňován Winklerův algoritmus. Ten bude v krátkosti nyní popsán blíže. Vychází z Jarovi vzdálenosti. Nejdříve je tedy nutné uvést následující vzorec: Dle [9]: „Jarova vzdálenost dvou řetězců s1 a s2 je definována vzorcem: =

1 + + 3 | 1| | 2|

−

Zdroj:[9]

kde m je počet znaků, které si v obou řetězcích odpovídají, t je počet transpozicí potřebných pro transformaci s1 na s2 a |s1|, |s2| jsou délky porovnávaných řetězců. Počet transpozicí je definován jako počet neodpovídajících si znaků v řetězci dělený číslem 2. Dva řetězce jsou označeny jako shodné, pokud Jarova vzdálenost nepřesáhne práh definovaný jako:“

( | 1|, | 2| −1 2 Zdroj: [9]

Výsledek Jarovi vzdálenosti může nabývat reálných hodnot mezi 0 a 1, kdy 0 znamená, že si řetězci neodpovídají, a 1 znamená absolutní shodu. Výsledné číslo odpovídá procentuální shodě dvou řetězců. Toto lze popsat na jednoduchém příkladu. Mějme s1 = „beoing“, s2 = „boeing“. Z těchto řetězců je možné odvodit m. Jedná se o počet odpovídajících si znaku, tedy m = 6. Délka obou řetězců je shodná |s1| = |s2| = 6. Pro transformaci s1 na s2 je třeba zaměnit E za O a O za E. Z tohoto lze vypočítat t = 2/2 =1. =

1 6 6 6−1 + + = 0,944 3 6 6 6 34

Hodnota prahu je:

( |6|, |6| −1=2 2

Porovnání těchto dvou hodnot ukazuje na shodu těchto dvou řetězců: 0,944 < 2

Dle [10] William Winkler tuto vzdálenost definuje trochu odlišně: ( 1, 2) =

1 + + 3 | 1| | 2| 2

Zdroj: [10]

kde m je m je počet znaků, které si v obou řetězcích odpovídají, t je počet transpozicí potřebných pro transformaci s1 na s2. V tomto případě se ale již t nedělí číslem 2. Dle [9]: „Jarova-Winklerova vzdálenost se od původní Jarovy liší zakomponováním tzv. škálovacího faktoru p, který zvýhodňuje shodu prvních l znaků. Vzorec pro výpočet má tedy tvar:

+ ( (1 −

=

))

Zdroj: [9]

Škálovací faktor je zpravidla nastaven na 0,1“ Opět je nejsnazší uvést na příkladu. Pro výpočet dj bude využit vzorec dle [9]. Mějme s1 = „MARTHA“, s2 = „MARHTA“. Z těchto řetězců lze odvodit m. Jedná se o počet odpovídajících si znaků, tedy m = 6. Délka obou řetězců je shodná |s1| = |s2| = 6. Pro transformaci s1 na s2 je třeba zaměnit T za H a H za T. Z tohoto vyplývá t = 2/2 = 1. Výsledek dle Jarova je tedy: =

1 6 6 6−1 + + = 0,944 3 6 6 6

Tento výsledek bude dále vložen do vzorce Jaro-Winklerovi definice a určí se p = 0,1 a l = 3, jelikož tyto dva řetězce mají shodné první tři znaky. = 0,944 + 3 ∗ 0,1(1 − 0,944)" = 0,961 ⇒ 96,1 % Dle Jaro-Winklerovi definice jsou tyto dva řetězce shodné více jak z 96 %.

35

5.5 Shrnutí kapitoly Na začátku kapitoly byly popsány obecné principy užívané při unifikaci klientských dat. Ve druhé části byl přiblížen výpočet Jaro-Winklerovi vzdálenosti dvou řetězců, který se využívá ke zjištění shody dvou řetězců ve společnosti Equa bank a.s., jak je popsáno v následující kapitole.

36

6

Unifikace klientských dat ve společnosti Equa bank a.s.

V předchozí kapitole byly popsány metody, jakými lze zpracovávat klientská data. V této kapitole, po krátkém představení společnosti Equa bank a.s. bude znázorněno, jak je unifikační algoritmus v této společnosti nastaven.

6.1 Equa bank a.s. Equa bank a.s. je relativně nováčkem na českém bankovním trhu. Na českém trhu je pod tímto jménem známá od roku 2011. Transformovala se z italské banky Banco Popolare. Momentálně má zhruba 300 zaměstnanců a její portfolio zákazníků neustále roste. S rostoucí nabídkou produktů se také zvyšuje počet systémů, v kterých jsou uložena zákaznická data.

6.2 Představení části prostředí DWH ve společnosti Ve společnosti Equa bank a.s. se nepoužívá přímo MDM systém, jak byl popsán v kapitolách výše. Unifikace klientů zde probíhá na úrovni Operational Data Store (ODS). Data se poté synchronizují do Data warehouse (DWH). Nad daty z DWH se následně vytvářejí reporty a analýzy pro potřeby jednotlivých oddělení. V celé společnosti se využívá technologie od společnosti Oracle. V ODS i DWH se nachází tabulka INST_PT (Instance Party), v které se nacházejí data o klientech. Tato tabulka se plní z více systémů, které ale zde není třeba popisovat. Na obrázku je znázorněna tabulka s atributy, které se při unifikaci využívají, a k nim přidružen číselník PT_TP. Jedná se o číselník typů určený k rozdělení typu zákazníka: •

FO – Fyzická osoba,

•

FOP – Fyzická osoba podnikatel,

•

PO – Právnická osoba. Dále jsou na obrázku znázorněny tabulky s poli, které se při unifikaci také

používají.

37

class Domain Mo...

PT_TP

INST_ID_CARD

«column» *PK PT_T P_KEY: NUMBER(19) * ID: VARCHAR2(255) * DESC: VARCHAR2(255) «PK» + PK_INST _PT_T P(NUMBER) «unique» + UQ_INST_PT_TP_ID(VARCHAR2) + UQ_INST_PT_TP_PT _TP_KEY(NUMBER)

INST_PT «column» +PK_INST_PT _TP *PK INST_PT _KEY: NUMBER(19) * UNI_PT_KEY: NUMBER(19) 1 *FK PT_TP_KEY: NUMBER(19) (PT _TP_KEY = PT_TP_KEY) *FK CNTRY_KEY: NUMBER(19) FIRST_NAME: VARCHAR2(50) FAMILY_NAME: VARCHAR2(50) +FK_INST_PT_TP_KEY BUSINESS_NAME: VARCHAR2(255) RC: VARCHAR2(255) 1..* ICO: VARCHAR2(255) DIC: VARCHAR2(255) ZIP: VARCHAR2(255) BIRTH_DATE: DATE ZECO: VARCHAR2(255) +FK_CNT RY_KEY * SRC_ID: VARCHAR2(255) * SRC_SYS_ID: VARCHAR2(255) 1..* (CNTRY_KEY = CNT RY_KEY)

CNTRY +PK_CNT RY «column» *PK CNTRY_KEY: NUMBER(19) * ID: VARCHAR2(255) * DESC: VARCHAR2(255)

«column» *PK INST_ID_CARD_KEY: NUMBER(19) *FK INST_PT_KEY: NUMBER(19) * ID_CARD_TP_KEY: NUMBER(19) * ID: VARCHAR2(255) * SRC_ID: VARCHAR2(255) * SRC_SYS_ID: VARCHAR2(255)

1

«FK» + FK_CNTRY_KEY(NUMBER) + FK_INST_PT_TP_KEY(NUMBER) «PK» + PK_INST _PT(NUMBER) «unique» + UQ_INST _PT_INST_PT_KEY(NUMBER)

«PK» + PK_CNTRY(NUMBER)

+FK_INST _PT_KEY «FK» + FK_INST_PT_KEY(NUMBER) 1..* (INST_PT _KEY = INST_PT_KEY) «PK» + PK_INST_ID_CARD(NUMBER) «unique» + UQ_INST _ID_CARD_INST_ID_CARD_()

+PK_INST_PT 1

+PK_INST_PT 1 INST_PHONE

(INST_PT_KEY = INST _PT_KEY)

«column» +FK_INST_PT_KEY *PK INST _PHONE_KEY: NUMBER(19) *FK INST _PT_KEY: NUMBER(19) 1..* * PHONE_TP_KEY: NUMBER(8,2) PHONE_NUM: NVARCHAR2(50) * SRC_ID: VARCHAR2(255) * SRC_SYS_ID: VARCHAR2(255) «FK» + FK_INST_PT _KEY(NUMBER)

«unique» + UQ_CNTRY_CNTRY_KEY(NUMBER) + UQ_CNTRY_ID(VARCHAR2)

«PK» + PK_INST_PHONE(NUMBER) «unique» + UQ_INST_PHONE_INST_PHONE_KEY()

Obrázek 11: Datový model tabulek INST_PT a PT_TP Zdroj: Vlastní zpracování

Název tabulky

INST_PT

INST_ID_CARD

Název atributu INST_PT_KEY UNI_PT_KEY PT_TP_KEY CNTRY_KEY FIRST_NAME FAMILY_NAME BUSINESS_NAME RC ICO DIC ZIP BIRTH_DATE ZECO SRC_ID SRC_SYS_ID

Popis Primární klíč Číslo unifikovaného záznamu Klíč k propojení do tabulky PT_PT Klíč k propojení do tabulky CNTRY Křestní jméno Příjmení Název společnosti Rodné číslo Identifikační číslo Daňové identifikační číslo Poštovní směrovací číslo Datum narození Zahraniční evidenční číslo Interní číslo záznamu ze zdrojového systému Označení zdrojového systému

INST_ID_CARD_KEY INST_PT_KEY ID_CARD_TP_KEY ID SRC_ID SRC_SYS_ID

Primární klíč Klíč k propojení do tabulky INST_PT Klíč k propojení do tabulky s typem dokladu Číslo dokladu Interní číslo záznamu ze zdrojového systému Označení zdrojového systému

38

INST_PHONE_KEY INST_PT_KEY PHONE_TP_KEY PHONE_NUM SRC_ID SRC_SYS_ID

Primární klíč Klíč k propojení do tabulky INST_PT Klíč k propojení do tabulky s typem telefonu Telefonní číslo Interní číslo záznamu ze zdrojového systému Označení zdrojového systému

PT_TP

PT_TP_KEY ID DESC

Primární klíč ID typu Popis

CNTRY

CNTRY_KEY ID DESC

Primární klíč ID země Popis

INST_PHONE

Tabulka 4: Popis atributů datového modelu dle obrázku 11 Zdroj: Vlastní zpracování

Uvedené databázové tabulky obsahují samozřejmě více atributů, ale v rámci rozsahu práce není potřeba tyto atributy zmiňovat. Na obrázku a v tabulce jsou uvedeny atributy, které se využívají v rámci unifikačního procesu.

6.3 Unifikační algoritmus Unifikace klientů probíhá v několika krocích, které budou popsány níže. Unifikační pravidla se používají odděleně na jednotlivé typy (FO, FOP, PO).

6.3.1 Standardizace atributů Standardizace se provádí z důvodu snazšího porovnávání atributů zákaznických dat při unifikaci. Dochází tím k prvotnímu očištění dat, kdy může být omylem například ve jménu nebo příjmení uvedena číslice. Standardizace probíhá u atributů FIRST_NAME, FAMILY_NAME a BUSINESS_NAME. Jedná se o tyto úpravy: •

Text je převeden na velká písmena.

•

Text je zbaven diakritiky.

•

U FIRST_NAME a FAMILY_NAME se z těchto atributů odstraní číslice. U BUSINESS_NAME se číslice neodstraňují, jelikož se často vyskytují v názvech firem.

39

6.3.2 Identifikace FO/FOP/PO Základní identifikace, během které jsou data rozdělena do tří skupin, probíhá na základě číselníku PT_TP. Na každou z těchto skupin jsou poté uplatňována rozdílná pravidla unifikace. Pokud není u nějakého záznamu z tabulky INST_PT znám typ zákazníka (ze zdrojového systému přišla data bez vyplněného typu nebo s chybovou hodnotou, která není obsažena v číselníku), určí se typ zákazníka dle následujících pravidel: •

Když je vyplněno jen RC, jedná se o FO.

•

Když je vyplněno RC a zároveň ICO nebo DIC, jedná se o FOP.

•

Když je vyplněno jen ICO nebo DIC, jedná se o PO.

6.3.3 Vytvoření kandidátských skupin Na začátku unifikačního procesu se vytvářejí kandidátské skupiny. Tyto skupiny se vytvářejí, dle typu zákazníka, podle určitého atributu, jak je popsáno níže. Poté se dle nastavených pravidel vytvoří konečná kandidátská skupina.

6.3.3.1 Vytvoření primárních kandidátských skupin Vytváří se dle následujících pravidel: •

U FO se vytváří přes RC.

•

U FOP se vytváří přes RC.

•

U PO se vytváří přes ICO nebo DIC.

6.3.3.2 Vytvoření sekundárních kandidátských skupin Vytváří se dle následujících pravidel: •

U FO se vytváří přes FAMILY_NAME.

•

U FOP se vytváří přes ICO nebo DIC.

•

U PO se vytváří přes BUSINESS_NAME.

6.3.3.3 Vytvoření terciálních kandidátských skupin Vytváří se dle následujících pravidel: •

U FO se tato skupina nevytváří.

•

U FOP se vytváří přes FAMILY_NAME.

•

U PO se tato skupina nevytváří.

40

6.3.3.4 Vytvoření konečné kandidátské skupiny Pokud někteří členové sekundární nebo terciální skupiny spadají do některé primární skupiny, a tato primární skupina je právě jedna, tak se do primární skupiny přiřadí i členové sekundární nebo terciální skupiny, které do žádné primární skupiny nepatří. Pokud se některé členy sekundárních nebo terciálních skupin nepodaří přiřadit do primárních skupin, vzniknou pro ně samostatné primární skupiny. Tímto sloučením dat ze sekundární nebo terciální skupiny do primární skupiny vznikne klientská skupina.

6.3.3.5 Spojení kandidátských skupin (platí pouze pro FO a FOP) Může dojít také ke spojení dvou různých kandidátských skupin do jedné. Toto spojení nastane, pokud jsou splněny následující podmínky: •

Skupiny mají stejný typ zákazníka dle číselníku PT_TP.

•

Slučované záznamy nemají vyplněno RC.

•

Záznamy mají shodné FIRST_NAME a FAMILY_NAME.

•

Shoduje je alespoň jedno z PHONE_NUM nebo BIRTH_DATE.

6.3.4 Unifikační mechanismus kandidátských skupin Záznamy se mezi sebou unifikují vždy jen v rámci vzniklých klientských skupin. To znamená, že se nikdy nesloučí záznamy ze dvou různých skupin. Sloučení probíhá pomocí identifikátoru UNI_PT_KEY, který je přidělen všem záznamům v dané klientské skupině. Níže je popsán unifikační mechanismus, v němž jsou teprve aplikována jednotlivá unifikační pravidla.

6.3.4.1 Penalizace záznamů Každý záznam se penalizuje z důvodu potřeby vybrat master záznam v klientské skupině. Každý záznam je penalizován maximální penalizací nebo dle vyplněnosti. Záznam je penalizován maximální penalizací, pokud se jedná o nový záznam, který ještě neměl přiděleno UNI_PT_KEY. Toto se děje z toho důvodu, aby se nestal masterem, který dostane nové UNI_PT_KEY a k němu by se pak přiřadili záznamy, které mají již UNI_PT_KEY přiřazeno. Tímto se zamezí změně UNI_PT_KEY již unifikovaným záznamům, aniž by se na nich cokoliv změnilo. UNI_PT_KEY se tak stává mnohem stabilnějším záznamem.

41

Penalizace dle vyplněnosti probíhá na základě následující tabulky. FO

FOP

PO

FIRST_NAME

1

1

0

INST_ID_CARD.ID

1

0

0

PHONE_NUM

1

0

0

BUSINESS_NAME

0

2

2

FAMILY_NAME

2

2

0

ZIP

0

1

1

RC

3

3

0

ICO

0

3

3

BIRTH_DATE

0

1

1

ZECO

0

1

1

CNTRY.ID

0

1

1

Tabulka 5: Hodnoty penalizace pro vyplněné pole jednotlivých záznamů Zdroj: Vlastní zpracování

Každý záznam je poté penalizován součtem hodnot z této tabulky dle toho, jaká pole má vyplněna. Čím je součet vyšší, tím je penalizace záznamu nižší a naopak.

6.3.4.2 Určení Master záznamu Masterem se stává záznam s nejnižší penalizací (má nejvyšší součet hodnot dle tabulky penalizací). Pokud master nemá přiřazeno UNI_PT_KEY, bude mu vygenerováno nové. Další záznamy se poté pokoušejí spárovat dle unifikačních pravidel na master záznam. V případě, že se spárují, je záznamu přiděleno stejné UNI_PT_KEY. V opačném případě se záznam stane druhým masterem. Další záznamy se párují na mastery dle pořadí atd., až se zpracují všechny záznamy skupiny. Na konci má každý záznam ze skupiny přiděleno své UNI_PT_KEY.

6.3.4.3 Unifikační pravidla Pro lepší přehlednost byla unifikační pravidla zapsána do tabulek rozdělených dle typu zákazníka (FO, FOP, PO). V každé tabulce je uvedeno i číslo pořadí, v kterém se jednotlivá pravidla na záznamy skupiny aplikují.

42

Unifikační pravidla FO Popis pravidla

Pořadí

RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být validní (modulo 11)

1

FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 75 % Pouze pro ženské pohlaví zjištěného dle RC (Rodné číslo) RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být validní (modulo 11) FAMILY_NAME (Příjmení)

2

Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % Příklad ‘Jana Nováková, RČ 1234567890’ = ‘Jana Axmanová, RČ 1234567890’ (vdaná žena) RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být validní (modulo 11) FAMILY_NAME x FIRST_NAME

3

Nesmí být prázdné Přesná shoda FAMILY_NAME záznamu je shodné s FIRST_NAME jiného záznamu a naopak Příklad Michal Petr = Petr Michal RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být validní (modulo 11) FIRST_NAME (Křestní jméno)

4

Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % FAMILY_NAME (Příjmení) Nesmí být prázdné

43

PHONE_NUM Nesmí být prázdné Přesná shoda FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno

5

90 % FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % INST_ID_CARD.ID Nesmí být prázdné Přesná shoda FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno

6

90 % FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % FAMILY_NAME (Příjmení)

7

Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % BIRT_DATE Nesmí být prázdné FIRST_NAME (Křestní jméno) Musí být prázdné FAMILY_NAME (Příjmení) Musí být prázdné

8

RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být validní (modulo 11) Tabulka 6: Unifikační pravidla pro FO Zdroj: Vlastní zpracování

44

Unifikační pravidla FOP Popis pravidla

Pořadí

RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11)

1

FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 75 % ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno

2

90 % FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % Pouze pro ženské pohlaví zjištěného dle RC (Rodné číslo) RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11) FIRST_NAME (Křestní jméno)

3

Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % Příklad ‘Jana Nováková, RČ 1234567890’ = ‘Jana Axmanová, RČ 1234567890’ (vdaná žena)

45

RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11) ICO (Identifikační číslo) Nesmí být prázdné

4

Přesná shoda Musí být platné FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % Pouze pro ženské pohlaví zjištěného dle RC (Rodné číslo) RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11) ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda

5

Musí být platné FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % Příklad ‘Jana Nováková, RČ 1234567890’ = ‘Jana Axmanová, RČ 1234567890’ (vdaná žena) ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné

6

FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 %

46

FIRST_NAME (Křestní jméno) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 % FAMILY_NAME (Příjmení) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 90 %

7

BUSINESS_NAME (Název společnosti) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % ZIP (PSČ) Nesmí být prázdné Bez shody ICO (Identifikační číslo) Musí být prázdné ZECO (Zahraniční evidenční číslo)

8

Nesmí být prázdné Přesná shoda ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné

9

BUSINESS_NAME (Název společnosti) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % FIRST_NAME (Křestní jméno) Musí být prázdné FAMILY_NAME (Příjmení) Musí být prázdné

10

RC (Rodné číslo) Nesmí být prázdné Přesná shoda Musí být platné BUSINESS_NAME (Název společnosti) Musí být prázdné ICO (Identifikační číslo)

11

Nesmí být prázdné Přesná shoda Musí být platné

47

ICO (Identifikační číslo) Musí být prázdné DIC (Daňové identifikační číslo)

12

Nesmí být prázdné Přesná shoda ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11) DIC (Daňové identifikační číslo)

13

Nesmí být prázdné Přesná shoda ZECO (Zahraniční evidenční číslo) Nesmí být prázdné Přesná shoda DIC (Daňové identifikační číslo) Nesmí být prázdné Přesná shoda

14

BUSINESS_NAME (Název společnosti) Nesmí být prázdné Bez shody Tabulka 7: Unifikační pravidla pro FOP Zdroj: Vlastní zpracování

48

Unifikační pravidla PO Popis pravidla

Pořadí

ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné

1

BUSINESS_NAME (Název společnosti) Nesmí být prázdné Shoda pomocí Winklerova algoritmu více nebo rovno 80 % DICO Nesmí být prázdné Přesná shoda

2

BUSINESS_NAME (Název společnosti) Nesmí být prázdné Bez shody BUSINESS_NAME (Název společnosti) Nesmí být prázdné Přesná shoda

3

ZIP (PSČ) Nesmí být prázdné Přesná shoda ICO (Identifikační číslo) Musí být prázdné ZECO (Zahraniční evidenční číslo)

4

Nesmí být prázdné Přesná shoda BUSINESS_NAME (Název společnosti) Musí být prázdné ICO (Identifikační číslo)

5

Nesmí být prázdné Přesná shoda Musí být platné ICO (Identifikační číslo) Musí být prázdné DIC (Daňové identifikační číslo)

6

Nesmí být prázdné Přesná shoda

49

ICO (Identifikační číslo) Nesmí být prázdné Přesná shoda Musí být platné (modulo 11) DIC (Daňové identifikační číslo)

7

Nesmí být prázdné Přesná shoda ZECO (Zahraniční evidenční číslo) Nesmí být prázdné Přesná shoda Tabulka 8: Unifikační pravidla pro PO Zdroj: Vlastní zpracování

6.4 Aktuální stav a výhled do budoucna V současné době se unifikace provádí pouze na úrovni ODS. Využívá se toho primárně pro správné načtení a zobrazení produktů zákazníka v internetovém bankovnictví, kdy se přes UNI_PT_KEY načtou instance zákaznických záznamů z jednotlivých systémů a následně k nim zákazníkovi produkty. V následujících letech ve společnosti Equa bank a.s. bude startovat projekt, jehož cílem bude nastavení vytváření „zlatého záznamu“ v rámci klientské unifikace.

6.5 Shrnutí kapitoly V této kapitole byla krátce představena společnost Equa bank a.s. a popsáno DWH řešení, kde se uchovávají data o zákaznících. Tato data se nadále využívají při unifikaci zákazníků. Poté byla představena jednotlivá pravidla, která se využívají při samotné unifikaci.

50

7

Závěr

Master Data Management je komplexní záležitostí. Svým rozsahem ovlivňuje většinu procesů v dané organizaci. Nejedná se o samostatný projekt, ale postupně se vyvíjející proces z pohledu vznikaní nových pravidel při práci s daty nebo při zavádění nových systémů. S MDM je potřeba také myslet na datovou kvalitu, aby byla zajištěna jednotná verze dat. V teoretické části byly vysvětleny základní pojmy a problematika MDM, od způsobu použití k implementačním vzorcům. Dále byly popsány obecné postupy při unifikaci klientských dat. V praktické části byly zmapovány pravidla unifikace klientských dat, jak jsou nastavena ve společnosti Equa bank a.s. Využití této práce je především v přiblížení problematiky MDM a představení možných pravidel použitelných pro unifikaci klientů. Závěrem je nutné zmínit, že pro každou organizaci je důležitý konsolidovaný pohled na data. Z tohoto důvodu je potřeba mít na paměti správu daného řešení, aby i v budoucnu mělo požadovanou přidanou hodnotu.

51

8

Literatura a použité zdroje

1. Adastra

s.r.o.:

Master Data Management [online]. Adastra s.r.o [cit. 2014-04-12].

Dostupný z WWW: . 2. IBM: An overview of MDM. [online]. [cit. 2014-04-12]. Dostupný z WWW: . 3. BUTLER, D.: Oracle Master Data Management: Executive Overview. [online]

Redwood Shores, California: Oracle Corporation. 2009-06. [cit. 2014-04-12]. Dostupný z WWW: http://www.oracle.com/us/bea/index.html?IdcService=GET_FILE&dID=19278&dDoc Name=018875>. 4. MISTRY, R., MISNER, S.: Introducing Microsoft SQL Server2008 R2. [online] Redmond, Washington: Microsoft Press, Microsoft Corporation, 2010. [cit. 2014-04-12]. Dostupný z WWW: .

5. DREIBELBIS, A., HECHLER, E.: Enterprise Master Data Management: An SOA Approach to Managing Core Information, IBM Press 1. edice, 2008. ISBN-10: 0132366258 6. TOBIŠEK, R. Čtyři tváře master data managementu aneb Různé implementační styly MDM. [online] Systém On Line. 2010, [cit. 2014-04-12]. Dostupný z WWW: . 7. FERRAIOLI, J., Utopia, Master Data Management Best Practices [online]. Utopia Global,Inc., 16. 8. 2012, [cit. 2014-04-12]. Dostupný z WWW: . 8. BERSON, A., DUBOV, L.: Master Data Management and Customer Data Integration for a Global Enterprise, 2007, McGraw-Hill Osborne Media; 1. edice, 2007. ISBN10: 0072263490 9. PEČOJCH, D.: Využití Fuzzy Match algoritmu pro čištění dat, str. 6 [online]. Katedra informačního

a

znalostního

inženýrství,

FIS-VŠE

Praha,

[cit. 2014-04-12]. Dostupný z WWW: .

52

2008,

10. WINKLER, W.: The state of record linkage and current research. Statistics of Income Division, Internal Revenue Service Publication R99/04 [online]. 1990 [cit. 2014-0412]. Dostupný z WWW: .

53

9

Seznam obrázků

Obrázek 1: Dimenze Master Data Systému ......................................................................... 13 Obrázek 2: Domény master dat ........................................................................................... 14 Obrázek 3: Znázornění MDM domén a metod použití ........................................................ 16 Obrázek 4: Systém záznamu a Systém odkazu .................................................................... 19 Obrázek 5: Implementační styl Konsolidace ....................................................................... 22 Obrázek 6: Implementační styl Registr ............................................................................... 22 Obrázek 7: Názorná ukázka při dotazování při použití stylu Registr .................................. 23 Obrázek 8: Implementační styl Koexistence ....................................................................... 24 Obrázek 9: Implementační styl Transakce........................................................................... 25 Obrázek 10: Definice mezí pro označení shodných záznamů ............................................. 33 Obrázek 11: Datový model tabulek INST_PT a PT_TP...................................................... 38

54

10 Seznam tabulek Tabulka 1: Některé průmyslové standardy a modely .......................................................... 15 Tabulka 2: Výhody a nevýhody MDM implementačních stylů .......................................... 26 Tabulka 3: Ilustrace řetězení při unifikaci ........................................................................... 34 Tabulka 4: Popis atributů datového modelu dle obrázku 11 ............................................... 39 Tabulka 5: Hodnoty penalizace pro vyplněné pole jednotlivých záznamů ......................... 42 Tabulka 6: Unifikační pravidla pro FO................................................................................ 44 Tabulka 7: Unifikační pravidla pro FOP ............................................................................. 48 Tabulka 8: Unifikační pravidla pro PO................................................................................ 50

55