Slogan „Společně jsme silnější!“ provází současné procesy slučování bankovních subjektů působících již řadu let úspěšně na našem trhu. Rozhodnutí o sloučení institucí však kromě nutnosti sjednotit jejich organizační strukturu znamená i nezbytnost zajistit integraci jejich datových zdrojů. Jednotný přístup ke klientským datům bank, který vzniká „pouhým slitím“ jejich datových zdrojů, však automaticky neznamená, že získáme i jednotný pohled na klienta. Brání tomu především různé datové struktury, ve kterých jsou klientská data v jednotlivých systémech udržována, nedostupnost či nedostatečná kvalita některých klíčových údajů, rozdílné metodiky více či méně dodržované při zadávání a správě klientských dat, a zejména pak nemožnost ve všech případech jednoduše, a hlavně dostatečně spolehlivě zjistit, že určité záznamy představují totožného klienta.

Konsolidace dat

Jak spojit zákazníky, kteří opravdu patří k sobě? Je tak definována úloha jako stvořená pro chytrou horákyni: mezi různorodými primárními systémy a napříč oběma bankami vyhledat záznamy představující totožného klienta a přitom dodržet podmínku, že se musí seskupit všechny záznamy, které k sobě patří, a nesmí se seskupit žádné záznamy, které k sobě nepatří. Jak však mezi miliony záznamů spolehlivě poznat, jestli dané záznamy k sobě ještě patří, nebo již ne, pokud se data hemží překlepy a zkratkami a některé klíčové hodnoty, nebo dokonce i atributy u některých záznamů zcela chybí?
Předně je třeba překlepy a zkratky opravit, správnost dat ověřit v referenčních etalonech, údaje rozparsovat do separátních sloupců, jedním slovem prostě vyčistit. Pak se teprve pustíme do vyhledávání záznamů představujících totožného klienta. Dá se tedy říct, že proces konsolidace klientských dat se sestává ze dvou na sebe navazujících kroků:

• čištění dat – standardizace tvarů proti číselníkům, odstranění překlepů, zkratek apod.,
• unifikace – seskupení záznamů patřících k sobě pod jedno nové ID (identifikační kód).

Z hlediska obsahu dat se pak obvykle jedná o dvě separátní úlohy:

• konsolidace klienta – týkající se atributů RČ/IČO, jméno a příjmení, případně název firmy, datum narození, pohlaví, tituly, číslo OP apod.,
• konsolidace adres – týkající se atributů PSČ, obec, ulice, číslo popisné a orientační, kód státu apod.

Bez pokročilé technologie jsou výsledky nevalné

Jako příklad pro čištění a unifikaci klientských a adresních dat uvedeme systém Ataccama DQC (Data Quality Center), známější v českém prostředí spíše pod názvem Purity, který je doma i v zahraničí nasazen již v řadě bank, pojišťoven, telekomunikačních společností a dalších institucí shromažďujících velké množství klientských dat.

Pouhým slitím několika datových zdrojů jednotný pohled na klienta nezískáme.

Kromě sady algoritmů a funkcí zaměřených na práci s daty, se tento systém při své činnosti opírá o sadu číselníků, proti kterým je většina zpracovávaných atributů ověřována. Zdrojem těchto číselníků jsou veřejně dostupné etalony, získatelné zadarmo (PSČ) nebo s vynaložením minimálních nákladů (UIR-ADR – územně identifikační registr adres, RES – registr ekonomických subjektů apod.). Významnou část řešení pak tvoří tzv. replacementy, ve své podstatě „překladové“ slovníky umožňující převedení nesprávných hodnot (zkratky, překlepy) na hodnoty korektní. Účinnost jejich uplatnění je závislá na úplnosti replacementů a metodice jejich použití. Nedílnou součástí Ataccama DQC jsou parsovací algoritmy, které umožňují zpracovávané údaje rozložit na jednotlivé komponenty a tyto komponenty umístit do separátních sloupců (například jméno a příjmení zvlášť). K tomu je potřeba mít k dispozici sadu patternů, tj. vzorů popisujících strukturu parsovaných dat.
Ke každé operaci, která se s daty provádí (například odstranění lomítka z rodného čísla, oprava překlepu ve jméně, nalezení, nebo naopak nenalezení hodnoty v číselníku atd.) lze přiřadit tzv. čisticí skóre, tj. číselnou penalizaci udávající, jak nečistá data jsou. Kromě toho je k dispozici čisticí kód (clearing code), ze kterého lze snadno příčinu penalizace vyčíst.

Spojením dat z více datových zdrojů na jednu platformu můžeme získat více než jen pouhou dostupnost informací z jednoho místa.

Hlavním úkolem při nasazení systému je však seskupit záznamy na základě shody v tzv. párovacím klíči (tj. sadě atributů jednoznačně identifikujících klienta nebo adresu). A to i tehdy, pokud se liší v určitém počtu znaků u některé z komponent klíče, nebo pokud hodnota některé z komponent klíče dokonce zcela chybí (díra v párovacím klíči – například u záznamu není vyplněno rodné číslo). Toto seskupování dat v systému Ataccama DQC obstarávají algoritmy založené na metodě hierarchické unifikace, díky čemuž není nutné se spoléhat na existenci pouze jediného klíče typu RČ/IČO.


Obr. 1: Příklad konfigurace čisticích a slučovacích pravidel v prostředí Ataccama DQC
Vytvořené skupiny představující záznamy téhož klienta či adresy jsou při deduplikaci nahrazovány tzv. reprezentantem, poskládaným z nejlepších hodnot jednotlivých atributů, nebo jejich sad (například adresu musíme brát jako celek, neboť jinak bychom mohli získat nekonzistentní a nesmyslnou adresu vybráním obce od jednoho záznamu a ulice od druhého). Tento reprezentant tak představuje konsolidovaného klienta.
Systém Ataccama DQC je obecně schopen pracovat v dávkovém inkrementálním režimu, kdy ke zpracování denních přírůstků a změněných klientských dat dochází typicky během nočních hodin, či v režimu on-line, kdy se pořizovaná a aktualizovaná klientská data zpracovávají okamžitě. Pokud se systém provozuje v režimu dávkovém a denní přírůstek je například v řádu několika jednotek či desítek tisíc klientských a adresních záznamů, pak je zpracován do třiceti minut.

Cesta ke konsolidovanému klientovi

V rámci procesu konsolidace dat je vždy třeba provést řadu činností, které se dají zhruba shrnout do následujících tří bodů: audit datové kvality, business analýza, implementace řešení.

Audit datové kvality

První obraz o zpracovávaných datech poskytne běžný profiling jednotlivých atributů (určení minima, maxima, frekvenční analýza apod.), který zpravidla následuje detailní audit datové kvality, tj. analýza klíčových atributů popisujících klienta, jako je rodné číslo, datum narození, číslo občanského průkazu, jméno, příjmení, adresa atd. Cílem těchto činností je rychle zmapovat a popsat datové zdroje: zjistit kvalitu, úplnost a dostupnost jednotlivých atributů, provést strukturální analýzu hodnot hlavních atributů používaných při unifikaci klientských dat, tj. zjistit, obsahují-li slova, písmena, čísla, číslice či jiné znaky. Záhy se tak ukáže nejen, jak kvalitní data v kterých primárních systémech jsou, ale také rychle vyplavou na povrch různé chyby vzniklé při přípravě dat (například u všech záznamů pocházejících z jednoho primárního systému není vyplněno PSČ). Proto je důležité provádět tyto analýzy nejen z globálního pohledu, ale také „rozpadlé“ podle důležitých atributů (po primárních systémech, pro fyzické respektive právnické osoby apod.). Chyba v datech, která se jeví jako bezvýznamná vzhledem k celkovému počtu zpracovaných záznamů, může totiž být signifikantní vzhledem k počtu záznamů z příslušného primárního systému.


Obr. 2: Graf znázorňuje úroveň kvality adresních dat. Výstup je pořízen v modulu Ataccama DQC Reporting používaného pro audit datové kvality.

Business analýza

Cílem této fáze je zmapovat business požadavky budoucích uživatelů, především z oblasti marketingu a risku, a dát je do souladu s možnostmi, které poskytují dostupné datové zdroje. Přitom vycházíme z vlastních „best practices“ s přihlédnutím ke specifickým potřebám a požadavkům vzešlých z interview s budoucími uživateli a ze závěrů vyplývajících z provedeného auditu datové kvality. Navržena a odsouhlasena jsou rovněž pravidla pro unifikaci klienta. Na základě těchto informací je „nahrubo“ upravena obvyklá konfigurace systému pro data quality management a provedeno zpracování všech dat (full-load). Dosažené výsledky jsou vyhodnoceny, jsou provedeny potřebné korekce nastavení aplikace či mappingu pro přípravu dat a celý postup se několikrát opakuje.

Implementace

V této fázi je nezbytné, aby data pro proces čištění a unifikace byla připravena a správně namapována ze zdrojových systémů hned na počátku procesu implementace. Nastavení systému vzešlé z „best practices“ se totiž nyní postupně přizpůsobují cílovým požadavkům na řešení a celý proces je zakomponován do worlflow dávkového zpracování. Na vzorcích, a později denních přírůstcích dat se při tom kontroluje kvalita vyčištěných dat a především správnost seskupování klientských dat. Není proto žádoucí, aby v této fázi docházelo k významným strukturálním či obsahovým změnám zpracovávaných dat.

Typické problémy

Při automatizovaném zpracování velkého množství klientských dat lze typicky narazit na řadu problémů, o kterých je dobré vědět. Zastavme se nyní u některých z nich a ukažme si, co je jejich příčinou a jak je jim například možné předcházet.

Nedostatečná znalost datových modelů spojovaných systémů a byznys významů jednotlivých atributů vede často ke ztrátě informace či smíchání „hrušek s jablky“.

Nedostatečná znalost datových modelů spojovaných systémů a byznys významů jednotlivých atributů vede často ke ztrátě informace či smíchání „hrušek s jablky“. Kupříkladu kód státu udržovaný ve dvou primárních systémech ve stejně pojmenovaných sloupcích je v jednom systému vztažen k národnosti klienta, ve druhém k jeho adrese, a má tedy pokaždé jiný význam. Jindy nastává nutnost překódovat hodnoty některých atributů na novou, společnou sadu. Pouhým „bezhlavým“ slitím zdrojů s opačně nastavenými příznaky (např. pohlaví: 1 = muž a 2 = žena v. 2 = muž a 1 = žena) totiž dojde velmi snadno k zanesení chyby, která je přitom snadno odstranitelná převedením původních dat na zcela nový kód (M = male, F = female).
Obecně platí, že informace v datech jsou často nekonzistentní, a je proto vždy vhodné snažit se je nezávisle několika způsoby odvodit, a tím buď původní hodnoty potvrdit, nebo vyvrátit. Na většinu zpracovávaných atributů je tedy nutno pohlížet z různých úhlů pohledu, přičemž je třeba brát v úvahu i vazby mezi obsahově závislými atributy. Výsledná „pravda“ je pak dána kombinací těchto zjištění a bývá vyhodnocena například metodou „hlasování“, často kombinovanou s určitou vahou představující větší či menší míru naší jistoty ohledně pravdivosti jednotlivých zjištění. Příkladem může být ověření pohlaví záznamu nezávislým odvozením z křestního jména hledaného na seznamu mužských, respektive ženských, křestních jmen, analogickým vyhledáním příjmení, ověřením přechýlení křestních jmen a příjmení, odvozením informace o pohlaví z rodného čísla či porovnáním rozdílnosti rodného a současného příjmení.
Rozporné a nejasné případy nebo případy, které se nepodaří spolehlivě určit či dohledat, je třeba vždy označit příznakem (clearing code), který umožní podle míry závažnosti těchto prohřešků jejich další zpracování v rámci metodických postupů banky. I samotné označení záznamů kvalitativním příznakem je obrovským přínosem, neboť do doby nasazení systému, jako je Ataccama DQC, nikdo ve finanční či jiné instituci přesně neví, která data konkrétně a z jakého důvodu jsou nekvalitní, či dokonce chybějící, přestože tuší, že tam „nějaká jsou“. Neví ale, kolik jich je, kde a jakým způsobem patrně vznikají ani jak jsou tyto chyby podstatné. Chybí-li například rodné číslo, jedná se z hlediska unifikace jistě o podstatnější závadu, než když u záznamu není uveden akademický titul.

Pojem	Popis
Data quality management	Řízení kvality dat
Deduplikace	Fyzická náhrada skupiny unifikovaných záznamů jedním reprezentativním záznamem
Identifikace	Ověření, zda zkoumaný záznam existuje v referenčním etalonu
Klient	Fyzická osoba, právnický subjekt, fyzická osoba podnikající
Párovací klíč	Skupina atributů jednoznačně určujících klienta/adresu
Parsing	Rozklad textu na jednotlivé komponenty
Pattern	Symbolická maska popisující strukturu dat rozložených na komponenty
Replacement	Automatická oprava dat využívající uživatelsky spravovaný překladový slovník (původní hodnota -> správná hodnota)
Unifikace	Seskupení záznamů shodujících se v párovacím klíči pod nové společné ID

Seznam základních pojmů vztahujících se k čištění a unifikaci dat
Smyslem fáze čištění dat jistě není opravit beze zbytku a za každou cenu všechny chybné údaje ani označit statisíce podezřelých záznamů, které je nutno následně ručně překontrolovat. Podíl dat určených ke kontrole musí být rozumně velký, jinak celé automatické zpracování nepřináší požadovaný efekt.
Nesprávnou aplikací metodického postupu při zpracování dat může v řadě případů také dojít k „opravě“ údajů, o kterých si systém myslí, že jsou špatně, přestože tomu tak není. Kupříkladu pan Macela, jehož příjmení se díky prohození pořadí křestního jména a příjmení při zadávání dat na přepážce objevilo ve sloupci pro křestní jméno, se nevhodnou aplikací replacementů ženských křestních jmen (Macela – Marcela) rázem změní na Marcela, z čehož bude mít jistě dotyčný klient pramalou radost.
Často ani nejsme vůbec schopni data bez znalosti kontextu opravit. Nejsme například schopni rozhodnout, má-li být poškozené křestní jméno Stanislva opraveno na Stanislav, neboť při jeho zápisu došlo k přehození písmen „v“ a „a“, nebo na Stanislava, neboť při zápisu tohoto jména vypadlo písmeno „a“.
Jak je vidět z uvedených příkladů, některé postupy je nutno při ověřování a opravě dat aplikovat v závislosti na hodnotě jiného atributu, v tomto případě na pohlaví záznamu. Dobře míněná oprava, která v několika případech bez problémů pomůže, totiž může jinak při automatickém zpracování milionů záznamů zanést do dat chybu u stovek nebo tisíců případů. O to větší pozornost musí být věnována kontrole „řídicích“ atributů (pohlaví, typ klienta, kód státu apod.) ovlivňujících metodický postup uplatňovaný při kontrole dat. Ten závisí zejména na zkušenosti a citu implementačního týmu, jeho schopnostech předvídat v datech možné situace a kromě úplnosti a aktuálnosti referenčních etalonů a replacementových číselníků pak zejména na šikovnosti při jejich používání. Zde jsou neocenitelným pomocníkem znalosti obsahu zpracovávaných dat získané při počáteční analýze.

Je třeba zabránit tomu, aby v průběhu implementace docházelo k významným strukturálním či obsahovým změnám zpracovávaných dat.

Přesto je nutno vždycky počítat s tím, že v budoucnu mohou (například vlivem nedodržení metodických pokynů při zadávání dat) kdykoliv přijít data v pozměněné struktuře či určitým způsobem poškozená, a konfigurace systému data quality na to musí být proto do určité míry připravena. Kupříkladu situaci, kdy by se ve sloupci pro pohlaví záznamu mohlo objevit rodné číslo, patrně řešit nebudeme, neboť je poměrně málo pravděpodobná. Že se ale ve sloupci pro jméno může vyskytnout akademický titul navzdory tomu, že je pro něj vyhrazen samostatný sloupec, na to v konfiguraci připraveni být musíme.
Výše zmíněný princip hlasování má tedy za cíl zamezit i vzniku kuriozit typu „Vážená paní Mercedes Benz“, neboť není možné považovat společnost „Mercedes Benz“ za fyzickou osobu pohlaví ženského, které přísluší oslovení „vážená paní“, jenom proto, že byla při pořizování dat chybně zapsána do pole pro jméno a příjmení fyzické osoby namísto do pole pro název společnosti a že se slovo Mercedes našlo na seznamu platných ženských křestních jmen. Je nutno dopředu počítat s tím, že jméno se může vyskytnout ve sloupci pro název společnosti a vice versa, jako se tomu stalo v naznačovaném případě, a tak je při určení oslovení nezbytné se opřít i o další závěry podporující nebo vyvracející původní hypotézu. Obecně lze však bohužel s trochou nadsázky konstatovat, že „všude může být všechno“.
Samostatnou kapitolou jsou pak data zadávaná klienty přes web, jejichž kvalita je samozřejmě podstatně horší než kvalita dat zadávaných „na přepážce“. Klienti jsou líní, nebo dokonce neochotní korektně vyplňovat požadované údaje a používají různých zkratek, nebo za účelem získání nějaké informace úmyslně vkládají nepravdivé údaje. Není proto neobvyklé, že přes web sbíraná data se hemží záznamy brouků Pytlíků a Ferdů Mravenců.

Business přínosy konsolidace dat

Spojením dat z více datových zdrojů do jedné platformy můžeme získat více než jen pouhou dostupnost informací z jednoho místa. Získání jakýchkoliv obchodních benefitů, které sloučení obou bankovních institucí přináší, je však podmíněno skutečností, že všichni uživatelé, ať již působí na kterémkoliv stupni řízení spojené banky, mají při rozhodování k dispozici potřebná data založená na konsolidovaném klientovi. Je nasnadě, že čím dříve jsou klientská data obou bankovních institucí zkonsolidována, tím dříve je možné obchodně těžit z přínosů, které tato konsolidace přináší, od cíleně zaměřených marketingových kampaní až po posuzování rizik při schvalování úvěrů, hypoték apod. V případě správně provedené unifikace klientských dat jsou pak dohledatelné nejen všechny produkty, které jsou na klienta v jednotlivých bankách původně navázané, ale také jeho platební historie, která například právě při poskytování úvěru může sehrát klíčovou roli.
Banka prostě nyní lépe ví, kdo je její klient, kterému již nadále nebude zasílat ty samé materiály a výpisy vícekrát kvůli tomu, že ho ve svých primárních systémech vícekrát má, avšak dosud o tom nevěděla. Tím se jednak zvýší adresnost marketingových kampaní a na druhé straně i důvěryhodnost banky v očích klienta. Z mnoha dalších přínosů, které je možné z konsolidovaného klienta vytěžit, jmenujme alespoň získání podkladů pro marketingové studie zaměřené na demografickou a geografickou segmentaci trhu či informace pro rozhodování o posílení sítě bankomatů a poboček banky v oblasti se zvýšenou koncentrací klientů, které je založeno na využití geografických souřadnic získaných úspěšnou identifikací adresního bodu (klientovy adresy ověřené až na úroveň vchodu do domu).

Lepší data, méně komplikací

Implementací systému pro data quality management dostávají uživatelé do ruky jednotný informační zdroj pro práci s klientem založený na unifikovaném klientovi. Standardizací a ověřováním osobních a adresních údajů lze následně postavit proces identifikace domácnosti (householding), čímž lze dosáhnout ještě větší adresnosti marketingových kampaní a spolehlivěji než dosud stanovit míru bankovních rizik při vyřizování konkrétních žádostí o úvěry.
U většiny implementací se následně celý proces identifikace a unifikace klientských a adresních dat převádí z dávkového do on-line režimu. Tím se nepochybně dále zvyšuje kvalita pořizovaných dat již v samotném zárodku, neboť dojde k zamezení vzniku nekvalitních dat přímo při jejich zadávání v klientských centrech. Nasazením on-line systému pro data quality management je totiž možno na základě několika vyplněných klíčových dat (např. jména, příjmení, rodného čísla nebo čísla občanského průkazu) ve zlomku sekundy klienta identifikovat (pokud je již zákazníkem banky) a doplnit ostatní nezadané údaje (adresu, tituly, pohlaví, datum narození atd.). Pokud daný zákazník klientem banky ještě není, jsou zadávané údaje vyčištěny, ověřeny vůči referenčním etalonům, ze kterých jsou chybějící údaje, pokud to je možné, doplněny, a do systému je založen záznam nový. Nemůže se tak již prakticky stát, že by klient byl v rámci banky veden duplicitně. Lepší data prostě znamenají méně komplikací.

Autor působí jako senior konzultant společnosti Ataccama Software.