Správa telefonních seznamů není triviální záležitost Pavel Kmínek Ataccama Software
1. S konsolidovanými daty jsme silnější Správa telefonních seznamů představuje pro telekomunikační společnosti nesnadný úkol zajistit, aby informace uvedené v elektronické nebo tištěné podobě seznamu, byly vždy korektní a aktuální, neboť to je klíčové pro business každé firmy uvedené v seznamu. Informace však rychle zastarávají, protože firmy vznikají a zanikají, slučují se a rozpadají, stěhují se, zřizují a ruší pobočky apod. Jak tyto nesrovnalosti a nekonzistence v datech dostatečně spolehlivě rozpoznat a jak je napravit přiblíží případová studie společností Ataccama a Mediatel.
2. Konsolidace dat - neboli 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 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 přitom seskupit žádné záznamy, které k sobě nepatří. Jak však mezi desítkami tisíc až 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ů jméno a příjmení, respektive název firmy a IČO, telefonní číslo, apod., a konsolidace adres, týkající se atributů PSČ, obec, ulice, č.p., č.o., kód státu, apod.
3. 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. Kromě sady algoritmů a funkcí zaměřených na práci s daty, se systém Ataccama DQC 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ě SYSTÉMOVÁ INTEGRACE 1/2008
53
Ataccama Software
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 paternů, tj. vzorů popisujících strukturu parsovaných dat. Ke každé operaci, která se s daty provádí (např. oprava překlepu ve jménu, nalezení nebo naopak nenalezení hodnoty v číselníku, atd.) lze přiřadit tzv. čisticí skóre, tj. vlastně čí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. Hlavním úkolem při nasazení Ataccama DQC 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). 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ř. u záznamu není vyplněno ICO). Toto seskupování dat v 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 IČO.
Obrázek 1:. Příklad - konfigurace čistících a slučovacích pravidel v prostředí Ataccama DQC Vytvořené skupiny, představující záznamy téhož klienta/adresy jsou při de-duplikaci 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 54
SYSTÉMOVÁ INTEGRACE 1/2008
Správa telefonních seznamů není triviální záležitost
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 Ataccama DQC 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ů, tak je zpracován do 30 minut.
4. 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 jeho telefonní číslo, název firmy/jméno a příjmení, adresa.
Obrázek 2:. Příklad - graf znázorňuje úroveň kvality adresních dat. Výstup je pořízen v modulu Ataccama DQC Reporting, používaného pro auditu datové kvality. Cílem těchto činností je za pomoci Ataccama DQC rychle zmapovat a popsat datové zdroje: zjistit kvalitu, úplnost a dostupnost jednotlivých atributů, provést SYSTÉMOVÁ INTEGRACE 1/2008
55
Ataccama Software
strukturální analýzu hodnot hlavních atributů používaných při unifikace 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ř. 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ímu systému. 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 "na hrubo" upravena obvyklá konfigurace Ataccama DQC a provedeno zpracování všech dat (full-load). Dosažené výsledky jsou vyhodnoceny, provedeny potřebné korekce nastavení Ataccama DQC či mappingu pro přípravu dat a celý postup se několikrát opakuje. Implementace Ataccama DQC 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í Ataccama DQC 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.
5. Typické problémy Typickým úkolem je telefonní seznam pročistit, nalézt a opravit překlepy, odstranit duplicitní záznamy. Zjistit, zda-li jedno telefonní číslo není přiřazeno dvěma nebo dokonce i více různým subjektům, či přiřazeno na různé adresy a správně detekovat pobočky firem. Většina firem má navíc kromě názvu, adresy a telefonního čísla i vlastní inzertní část, kde lze dohledat další kontaktní a obchodní informace, jako jsou otevírací doby, odkazy na webové stránky apod.), které jsou pak uvedeny v tištěné podobě seznamu. 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. 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 56
SYSTÉMOVÁ INTEGRACE 1/2008
Správa telefonních seznamů není triviální záležitost
s určitou vahou, představující větší či menší míru naší jistoty v pravdivost jednotlivých zjištění. Příkladem může být ověření typu klienta (fyzická osoba/firma) nezávislým odvozením založeným na kontrole obsahu jména a příjmení, názvu firmy a IČO. 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ů té či oné organizace. 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 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 telefonní číslo, jedná se z hlediska unifikace jistě o podstatnější závadu, než když u jména není uveden akademický titul. 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 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', nebo na Stanislava, neboť při zápisu tohoto jména vypadlo písmeno 'a'. Jak je vidět z uvedených příkladů, je nutno některé postupy 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. 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 Ataccama DQC na to musí být proto do určité míry připravena. Kupříkladu situaci, kdy by se ve sloupci pro telefonní číslo mohlo objevit jméno nebo název firmy 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. Obecně lze však bohužel s trochou nadsázky konstatovat, že "všude může být všechno".
SYSTÉMOVÁ INTEGRACE 1/2008
57
Ataccama Software
Samostatnou kapitolou je pak čištění ostatních "operativních" dat, které vznikají především při komunikaci se zákazníkem, většinou prostřednictvím call center či pří různých cílených marketingových kampaních. Kvalita těchto dat je mnohem horší, než kvalita vlastních klientských dat. Operátoři call center často píší různé poznámky a to mnohdy rovnou do toho pole, kde mají na kontaktním formuláři monitoru právě kurzor, tedy klidně do pole určeného třeba pro jméno a příjmení nebo adresu. Lze se tak dozvědět řadu "zajímavých" informací, jako například "nevolat před desátou!", "pozor, hulvát!", "nemluví česky", apod., které je však neradno, aby se dostaly do vytištěného telefonního seznamu. Proto je třeba nasazením on-line čištění a unifikace zamezit vzniku chybných nebo nesprávně uložených údajů již při jejich zadávání.
6. Business přínosy konsolidace dat 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. Získání jakýchkoliv obchodních benefitů, které sloučení datových zdrojů přináší, je však podmíněno skutečností, že všichni uživatelé, ať již působí na kterémkoliv stupni řízení organizace, 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 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 klientovu platební historii. Organizace prostě nyní lépe ví, kdo je její klient, kterému již nadále nebude zasílat ty samé materiály 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 organizace v očích klienta. Z mnoha dalších přínosů, které je možné z konsolidovaného klienta vytěžit, jmenujme například získání podkladů pro marketingové studie zaměřené na demografickou a geografickou segmentaci trhu.
7. Lepší data, méně komplikací Implementací systému jako je například Ataccama DQC dostávají uživatelé do ruky jednotný informační zdroj pro práci s klientem, založený na unifikovaném klientovi. 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. On-line nasazení Ataccama DQC je totiž schopno na základě několika vyplněných klíčových dat (název firmy / jméno a příjmení, IČO, telefonní číslo, ...) ve zlomku sekundy klienta identifikovat (pokud je již zákazníkem organizace) a doplnit ostatní nezadané údaje (adresu, tituly, atd.). Pokud daný zákazník klientem organizace ještě není, jsou zadávané údaje v Ataccama DQC 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 organizace veden duplicitně. Lepší data prostě znamenají méně komplikací . . . Seznam pojmů: Následující tabulka shrnuje základní pojmy vztahující se k čištění a unifikaci dat, které jsou používány v tomto článku. 58
SYSTÉMOVÁ INTEGRACE 1/2008
Správa telefonních seznamů není triviální záležitost
Pojem Deduplikace Identifikace Klient Párovací klíč Parsing Patern ATACCAMA DQC Replacement Unifikace
Popis Fyzická náhrada skupiny unifikovaných záznamů jedním reprezentativním záznamem Ověření, zda zkoumaný záznam existuje v referenčním etalonu Fyzická osoba, právnický subjekt, fyzická osoba podnikající Skupina atributů jednoznačně určujících klienta / adresu Rozklad textu na jednotlivé komponenty Symbolická maska popisující strukturu dat rozložených na komponenty SW nástroj společnosti Adastra pro Data Quality Management (čištění a unifikace dat) Automatická oprava dat využívající uživatelsky spravovaný "překladový slovník" (původní hodnota -> správná hodnota) Seskupení záznamů shodujících se v párovacím klíči pod nové společné ID
Highlights / Klíčové hlášky (na okraj):
Pouhým slitím několika datových zdrojů jednotný pohled na klienta nezískáme. 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. Nedostatečná znalost datových modelů spojovaných systémů a business významů jednotlivých atributů vede často ke ztrátě informace či smíchání "hrušek s jablky". 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ávných dat. Smyslem 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. Organizace prostě nyní lépe ví, kdo je její klient. Nemůže se tak již prakticky stát, že by klient byl v rámci organizace veden duplicitně.
SYSTÉMOVÁ INTEGRACE 1/2008
59
