Pozor na znečištění… dat

Existuje jen málo IT projektů, které firmy straší více než integrace a sdružování dat. Opravdovou noční můrou je pak scénář datové integrace, která se zvrtne.

Někdy se totiž se špatnými vstupními daty již začne – ať už jde o nechtěnou chybu lidského faktoru či úmyslnou sabotáž. Občas jsou data zpočátku v pořádku, během procesu (při přesunu mezi systémy či databázemi) se však část ztratí, zkomolí nebo jinak pozmění nežádoucím způsobem. Data mohou také zastarat, vyloučeno není ani to, že je uživatelé v organizaci zkrátka odmítají navzájem sdílet a každé oddělení si hraje na vlastním písečku. Nakonec vám úlohu neusnadní ani fakt, že se dnes v naprosté většině firem produkuje stále narůstající objem dat.

Datové projekty se mohou zkazit mnoha různými způsoby. My vám přinášíme pět těch nejčastějších, spolu s popisem toho, co bylo špatně, jaký byl následek a jak předejít tomu, abyste nedopadli stejně. Jména společností jsou ze zřejmých důvodů fiktivní.

1. INICIATIVNÍ ZÁKAZNICKÁ PODPORA

Buďte opatrní s tím, odkud získáváte svá data. Ne vždy jsou taková, jaká byste očekávali. Tento příběh se odehrál v jedné velké finanční instituci, hlavní roli si v něm zahrálo tamní call centrum.

Jako téměř u všech helpdesků také zaměstnanci tohoto vybavovali telefonáty a zadávali zákaznická data do sdílené databáze. Tato konkrétní databáze zahrnovala editovatelné políčko pro oslovení. Namísto omezení na Pan či Paní mohli pracovníci napsat cokoli o délce až třiceti znaků. A jelikož práce v zákaznické podpoře není žádný med, začali někteří frustrovaní zaměstnanci do daného pole zadávat vlastní uštěpačné poznámky typu „nehorázný blbec“, „bláznivý zákazník“ nebo „otravný idiot“.

Roky plynuly, ale nikdo si ničeho nevšiml, neboť žádné jiné oddělení nečerpalo informace z databáze oddělení helpdesku. Jednoho dne se však vedení společnosti kvůli propagaci nové služby rozhodlo spustit přímou marketingovou kampaň pomocí e-mailu. A namísto nákupu adres uživatelů od třetí strany se přiklonilo k tomu sáhnout pro informace právě do databáze vlastního call centra.

Tak zákazníci dostávali e-maily s oslovením „Milý otravný idiot Jan Novák“ nebo „Milý bláznivý zákazník Ladislav Šulc“. Asi se nebudete divit, když vám prozradíme, že kampaň byla naprostý propadák a firma tímto způsobem na novou službu nepřilákala vůbec nikoho. Vedení to bylo divné, a tak se začalo zkoumat proč. Analýza odesílané pošty udělala ve všem jasno. A jaké z tohoto příběhu plyne ponaučení?

„Realita je taková, že už dnes nejsme vlastníky svých dat,“ říká viceprezident řízení výroby a prodeje výrobků a kontrolor kvality dat ze společnosti Informatica Arvind Parthasarathi. „Svět je natolik propojený, že je navýsost pravděpodobné, že se někdo vašich informací zmocní a využije je naprosto jiným než vámi zamýšleným způsobem. A jelikož ve firmě využíváte data z mnoha rozličných zdrojů, musíte se ujistit, že máte správně nastavenou úroveň správy kvality dat, než je v praxi využijete pro cokoli nového.“

Co přesně znamená „správně nastavená úroveň správy kvality dat“, bude záležet na tom, jakým způsobem svá data využíváte. „V oblasti přímého marketingu e-mailem postačí, že je správně nějakých 70 až 80 % vstupních dat. Jinde, například ve zdravotnickém průmyslu, se však toto číslo musí přehoupnout alespoň přes 99 %. Žádná společnost však doopravdy nechce, nepotřebuje a nebude platit za perfektní data. To by totiž bylo příliš drahé. Hlavní otázka tedy zní: K jakým účelům budou data využívána a je pro to jejich úroveň dostačující?“

2. MRTVÍ LIDÉ NEVOLÍ

Čištění dat může být otázkou života a smrti, a to doslova. PR specialistka Nancy Kirková v roce 2006 asistovala jako dobrovolnice u voleb do amerického kongresu. Jejím úkolem tehdy bylo obvolávat registrované voliče a nalákat je k volebním urnám. Tehdy však zjistila znepokojivou věc. Tři z deseti lidí, kterým volala, byli v té době již mrtví.

Problém vlastnictví takto neaktuálních dat, jejichž soubor zahrnuje třeba i již zemřelé, není v komerční sféře ničím neobvyklým. Nadto tento stav obvykle mívá reálné dopady také na sféru živých. Prezident divize komunikačních služeb ve společnosti The Keane Organization Jim Keyster strávil poslední rok mapováním investorů a akcionářů organizací, jako jsou pojišťovny, společné fondy a firmy z žebříčku Fortune Top 500.

Podle Keystera v průměru 8 až 15 % datových záznamů obsahuje anomálie typu špatně zadaného čísla sociálního zabezpečení nebo již neplatných adres. Asi v jedné pětině těchto anomálií pak figuruje osoba, která je již více jak pět let po smrti. Keyster ve svém pátrání narazil dokonce i na případ akcionáře, který zemřel před celými dvaasedmdesáti lety!

„Tady nejde o nedbalost, ale přirozený problém,“ říká Keyster. Soukromé společnosti se stávají veřejnými, mění názvy, jsou skupovány a prodávány… a celým tímto kolotočem sebou stále vláčejí data svých akcionářů, často i po celá desetiletí.

Důsledky mohou být bohužel horší než jen peníze vyhozené za rozesílání pošty již zemřelým. Největší obavy vzbuzují samozřejmě podvody a krádeže identit. Cizí člověk by tak mohl za mrtvého inkasovat dividendy, bránit právoplatným dědicům v nárokování pozůstalosti či neoprávněně přistupovat k důvěrným datům společnosti.

Jaké je řešení tohoto problému? Na trhu je již k dostání software, který dokáže identifikovat datové anomálie napříč různými systémy a označit je k přezkoumání. To ale samo o sobě nestačí. Společnosti, které se rozhodnou jej nasadit, však zároveň musejí o data náležitě pečovat, mít dobré interní kontroly a provádět pravidelné ověřování všech záznamů.

„V praxi se s tímto problémem do určité míry potýká téměř každá firma,“ upozorňuje Keyster. „Z hlediska správy rizik je tím nejlepším, co můžete udělat, pravidelná kontrola záznamů. Porozumění tomu, v jakých souvislostech tento fenomén vaši organizaci reálně ovlivňuje, je dobrým prvním krokem.“

3. ZAPLAVENÍ DUPLICITNÍMI ZÁZNAMY

Chyba lidského faktoru je nepříjemná. Vynalézavost uživatelů ovšem může být ještě horší. Podívejme se na příklad velké pojišťovny, která uchovávala většinu zákaznických dat v mainframové aplikaci z osmdesátých let. Pracovníci zadávající data byli instruováni k tomu, aby vždy nejprve databázi prohledali a zjistili, zda v ní daný klient již nefiguruje. Protože však vyhledávání bylo velice pomalé a často nepřesné, většina zaměstnanců tento krok zkrátka přeskakovala a raději data vložila znovu. A výsledek? Někteří zákazníci v databázi figurovali až 700 či 800krát, díky čemuž byl systém ještě pomalejší a méně přesný než kdykoli předtím.

Jelikož aplikace byla zabudovaná tak hluboko v rámci firemní IT infrastruktury, zdráhalo se nejprve vedení vydat nemalé finance na její odstranění a nahrazení něčím kvalitnějším. Alespoň do doby, než IT oddělení vypracovalo obchodní studii, která ukazovala, že neschopnost lokalizovat v databázi existující zákazníky firmu denně může přijít až na 750 000 dolarů v příjmech. To rozhodlo a vedení dalo změnám zelenou. Tehdy společnost použila software SSA-Name3 firmy Identity Systems k pročištění dat. Ve finále bylo odstraněno na 36 000 duplicitních záznamů.

„Duplicitní záznamy jsou na seznamu problémů, které u IT správců vyvolávají noční můry. A obecně platí, že čím větší databáze, tím horší je stav,“ vysvětluje ředitel společnosti Identity Systems Ramesh Menon. „Většina lidí však nemá ponětí o tom, jak rozsáhlému problému vlastně čelí. Pokud vám někdo řekne něco ve stylu, že se v jeho databázi nachází přesně 2,7 % duplicitních záznamů, nevěřte mu. Pravděpodobně se mýlí a situaci nechtěně bagatelizuje.“

Proti „duplikátům“ neexistuje žádná kouzelná formulka. Podle Menona řešení začíná u využití technologie pro párování dat (data matching) k izolování a vyfiltrování jednotného přehledu informací ze všech datových zdrojů organizace. I poté však budete čelit úloze přimět všechny zúčastněné strany (různé divize a oddělení) k dohodě na rozsahu poskytovaných dat a definici toho, jak vlastně takový duplicitní záznam vypadá.

„Dvě různá oddělení stejné organizace mohou mít například diametrálně odlišné představy o vymezení duplikátů. Tyto druhy integračních snah často padají právě s neschopností organizačních jednotek v rámci organizace usnést se na nějakém konsenzu – ať už ohledně definice duplikátů nebo toho, které informace navzájem sdílet a které nikoli.“

4. DATA S PROŠLOU LHŮTOU SPOTŘEBY

Vzpomínáte na staré textové hry jako Zork, kde jste pomocí příkazového řádku zkoumali zatuchlé kobky zhmotnělé jen ve vaší fantazii? Podle všeho jsou i dnes, po x letech, na světě lidé, kteří se zabývají programováním obdobných záležitostí. Co je však horší, k propagaci svých „děl“ využívají data, která byla stěží aktuální před nějakými deseti lety.

Spoluzakladatel mailingové služby MailChimp Ben Chestnut se s námi podělil o historku o jednom herním vývojáři ze staré školy. Když dokončil druhý díl své úžasné hry, rozhodl se vykřičet to do světa právě pomocí e-mailu a služby MailChimp. Iniciativní vývojář měl sice k dispozici asi 10 000 adres, problém však byl, že stáří většiny z nich přesahovalo deset let. Dekáda je v tomto směru velice dlouhá doba, a tak není divu, že mnohé z adres již vůbec neexistovaly. Krom toho Microsoft na své e-mailové službě Hotmail některé již používal jako spamové pasti (spam traps). Den nato se tedy e-mailový účet MailChimpu objevil na blacklistu Hotmailu.

Naštěstí pro MailChimp měl vývojář k dispozici původní záznamy i s jednotlivými IP adresami, které dokazovaly, že si uživatel každé z adres kdysi dávno první díl jeho hry skutečně stáhnul. „A to nás zachránilo,“ říká Chestnut. „Veškeré získané důkazy jsme ihned poslali Microsoftu. Den nato byl náš účet z blacklistu odstraněn. To se jen tak nevidí, byla to pro nás velká výhra.“

Všechna data zastarávají závratnou rychlostí, u kontaktních informací to však platí dvojnásobně. „Data bych přirovnal k radioaktivním vzorkům. Postupně se také rozkládají,“ říká Parthasarathi ze společnosti Informatica. „Proto musíte pravidelně přistupovat do všech systémů a informace stále aktualizovat. Opravdová hodnota totiž netkví v samotných datech, nýbrž ve schopnosti udržovat je stále korektní a čistá.“

5. VÁLKA S CHYBAMI

Rozdíl mezi „dobrými“ a „špatnými“ daty může být v jedné jediné tečce velikosti pixelu. Přesvědčila se o tom také Penny Quirková, hlavní konzultantka společnosti Robbins-Gioia‘s Records Optimization Solutions. Jednou byla pověřena rolí konzultantky v projektu datové integrace. Vše tehdy probíhalo bez sebemenších problémů a projekt byl „zdárně“ ukončen. O šest měsíců později však jeden uživatel otevřel datovou tabulku, v níž našel jen změť různých symbolů, ale žádná použitelná data.

„Šlo o chybu v kódování,“ vzpomíná Quirková, „Když se v některém z polí nacházely dvě tečky za sebou, stal se po integraci nepoužitelným celý daný řádek.“ Společnost tedy musela celou databázi vytvořit znovu ze záložních kopií. Ty předtím musely být ještě prohledány a vyčištěny od symbolů, které při konverzi způsobovaly problémy.

„Nejčastějším problémem nejsou jen špatně zapsané údaje. Spíše jde o to, že většina organizací zanedbá fázi plánování při migraci dat mezi různými operačními systémy či databázemi,“ domnívá se Quirková. „Firmy se snaží o co nejrychlejší završení celého procesu. Využívají tedy všech datových zdrojů a doufají, že se jim výsledná sada podaří pročistit později. Ještě horší je, že testovací prostředí v mnoha případech neodpovídá tomu produkčnímu, nebo firmy k testování využívají jen malou část dat a po migraci zjistí, že se zbytek neřídí stejnými pravidly.“

„Organizace, které provádějí dramatické technologické změny, aniž by vyvinuly potřebné úsilí a vyhradily si čas nezbytný na kvalitně provedené sdružování, integraci a konverzi dat, ve výsledku velice často dostanou nepoužitelná data,“ varuje Quirková. „Šance, že se data v průběhu procesu jejich přesouvání mezi různými zdroji ‚znečistí‘ je ohromná.“

Co tedy Quirková doporučuje? „Rozhodně nepočítejte s tím, že za vás IT oddělení ověří platnost datové sady. Do plánování a testovací integračního procesu se pokuste zapojit také zkušenější uživatele, kteří s danými daty normálně pracují. Než se rozhodnete pro konsolidaci, podívejte se na všechna datová pole a popřemýšlejte nad tím, které aplikace by z nich mohly čerpat. Je-li to možné, používejte v testovací fázi kompletní datový set, nikoli jen náhodně zvolený vzorek. I nepatrná chybička se v tomto případě může rovnat stovkám ztracených hodin a spoustě zbytečně vynaložených finančních prostředků.“ Poslední větu Quirkové ostatně dokládá i následující příběh.

Prezident a CTO (Chief Technology Officer) společnosti Keane Business Risk Management Solutions Peter Teuten vypráví o jednom klientovi, který chtěl pomocí kontroly na serveru a databáze SQL zjistit, zda sítí nekolují porušené soubory CAD. Kdyby počet porušených paketů překročil určenou prahovou hodnotu, implementovala by společnost nástroje pro data mining a čištění dat.

Kde byl tedy problém? Při zadávání pravidla pro kontrolu pracovníci omylem převrátili jeho definici. Čím více porušených packetů, tím lépe, vypadaly výsledné reporty. „Nakonec byla celá síť firmy napadena červem, který porušil i hlavní inženýrské soubory CAD a na celý problém se přišlo. Společnost musela udělat většinu návrhů znovu a začít v podstatě od nuly. To jí stálo miliony dolarů. A vše začalo ‚nevinným‘ přehozením dvou hodnot…“ A pokud vás ke zvýšené opatrnosti při implementaci příštího integračního projektu nepřiměje ani tento příklad, pak už asi nic.