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 Úvod... 9 1.1 Struktura práce... 9 1.2 Omezení práce... 9 2 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 Shrnutí kapitoly... 20 3 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
2.3.1 Master Data domény Obrázek 1: Dimenze Master Data Systému Zdroj: [5] 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
2.3.2.1 Kolaborativní MDM Obrázek 3: Znázornění MDM domén a metod použití Zdroj: [5] 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. 2.3.4 Konzistence dat Obrázek 4: Systém záznamu a Systém odkazu Zdroj: [5] 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 Konsolidace Registr Koexistence Transakce Co nabízí Agregace master dat do společného Udržuje jednoduchý systém záznamů s Poskytuje jednotný pohled na master Správa jednotného úložiště pro potřeby odkazy na kompletní data. Synchronizace pohledu na reportingu. data v dalších systémech. Výhodný pro real-time reference. změn v ostatních systémech. master data. Poskytuje přístup ostatním systémům pomocí služeb. Přínosy Příprava dat pro analytické systémy. Kompletní přehled je vytvořen podle potřeby, rychlé na vybudování. Předpoklad, že zůstanou stávající systémy beze změny. Zaleží na prostředí společnosti. Poskytuje možnost čtení i zápisu. 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 použití Především na čtení, komplexnější pro správu. Ne vždy aktuální data s provozními systémy. Analytické Provozní Kolaborativni, Provozní, Analytické Vyžaduje změnu stávajících systémů. Kolaborativni, Provozní, Analytické Systém odkazu odkazu odkazu záznamu Tabulka 2: Výhody a nevýhody MDM implementačních stylů Zdroj: [5] 26
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 Jméno Příjmení Adresa Datum narození 1 Tomáš Bezinka Nádražní 23, Praha 5 2 Tomáš Bezinka Za skládkou 10, Brno - město 15.9.1975 3 Tomáš Bezinka 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 3 6 6 +6 6 +6 1 6 = 0,944 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 3 6 6 +6 6 +6 1 6 = 0,944 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 «column» *PK PT_TP_KEY: NUMBER(19) * ID: VARCHAR2(255) * DESC: VARCHAR2(255) «PK» + PK_INST_PT_TP(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) 1..* RC: VARCHAR2(255) ICO: VARCHAR2(255) DIC: VARCHAR2(255) ZIP: VARCHAR2(255) BIRTH_DATE: DATE ZECO: VARCHAR2(255) +FK_CNTRY_KEY * SRC_ID: VARCHAR2(255) * SRC_SYS_ID: VARCHAR2(255) 1..* INST_ID_CARD «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) +FK_INST_PT_KEY «FK» + FK_INST_PT_KEY(NUMBER) 1..* (INST_PT_KEY = INST_PT_KEY) «PK» + PK_INST_ID_CARD(NUMBER) +PK_INST_PT «unique» + UQ_INST_ID_CARD_INST_ID_CARD_() 1 +PK_INST_PT 1 (CNTRY_KEY = CNTRY_KEY) «FK» (INST_PT_KEY = INST_PT_KEY) INST_PHONE CNTRY «column» *PK CNTRY_KEY: NUMBER(19) +PK_CNTRY 1 + FK_CNTRY_KEY(NUMBER) + FK_INST_PT_TP_KEY(NUMBER) «PK» + PK_INST_PT(NUMBER) «column» +FK_INST_PT_KEY *PK INST_PHONE_KEY: NUMBER(19) *FK INST_PT_KEY: NUMBER(19) 1..* * PHONE_TP_KEY: NUMBER(8,2) * ID: VARCHAR2(255) «unique» PHONE_NUM: NVARCHAR2(50) * DESC: VARCHAR2(255) + UQ_INST_PT_INST_PT_KEY(NUMBER) * SRC_ID: VARCHAR2(255) * SRC_SYS_ID: VARCHAR2(255) «PK» + PK_CNTRY(NUMBER) «FK» «unique» + FK_INST_PT_KEY(NUMBER) + UQ_CNTRY_CNTRY_KEY(NUMBER) «PK» + UQ_CNTRY_ID(VARCHAR2) + 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 Název atributu Popis INST_PT_KEY Primární klíč UNI_PT_KEY Číslo unifikovaného záznamu PT_TP_KEY Klíč k propojení do tabulky PT_PT CNTRY_KEY Klíč k propojení do tabulky CNTRY FIRST_NAME Křestní jméno FAMILY_NAME Příjmení BUSINESS_NAME Název společnosti INST_PT RC Rodné číslo ICO Identifikační číslo DIC Daňové identifikační číslo ZIP Poštovní směrovací číslo BIRTH_DATE Datum narození ZECO Zahraniční evidenční číslo SRC_ID Interní číslo záznamu ze zdrojového systému SRC_SYS_ID Označení zdrojového systému INST_ID_CARD INST_ID_CARD_KEY Primární klíč INST_PT_KEY Klíč k propojení do tabulky INST_PT ID_CARD_TP_KEY Klíč k propojení do tabulky s typem dokladu ID Číslo dokladu SRC_ID Interní číslo záznamu ze zdrojového systému SRC_SYS_ID Označení zdrojového systému 38