Koncept datové kvality v bance

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Koncept datové kvality v bance Diplomová práce

Autor:

Bc. Martin Vágner Informační technologie a management

Vedoucí práce:

Praha

doc. Ing. Bohumil Miniberger, CSc.

Duben, 2010

Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury.

V Praze, dne 12.4.2010

Bc. Martin Vágner

Poděkování Na tomto místě bych rád poděkoval doc. Ing. Bohumilu Minibergerovi, CSc., vedoucímu této diplomové práce, za cenné podněty a připomínky a za moţnost volby tohoto tématu diplomové práce. Dále chci poděkovat Ing. Petru Kubátovi, projektovému manaţerovi odboru IT governance a procesy v České spořitelně, a.s. za konzultace a názorové výměny, které přispěly ke vzniku této práce.

V Praze, dne 12.4.2010

Bc. Martin Vágner

Anotace Tato diplomová práce se zabývá problematikou datové kvality se zaměřením zejména na bankovní sektor. Je zde vysvětlen pojem datová kvalita tak, jak je chápán obecně a pro potřeby této práce. Popisuje současný stav datové kvality v bance, mapuje konkrétní data z hlediska jejich důleţitosti pro banku ve vazbě na její hlavní předmět podnikání. Zabývá se způsoby zjišťování datové nekvality, jejím měřením a zjišťováním poţadavků na její úroveň. Navrhuje konkrétní způsoby jejího koncepčního řešení.

Anotation This thesis deals with data quality, focusing in particular on the banking sector. The concept of data quality is explained, as understood in general and for the purposes of this paper. The thesis describes the current state of data quality in the bank, mapping specific data in terms of their importance for the bank in relation to its core business. It discusses the modalities of monitoring bad quality data, its measurement and detection of the requirements for its level. It proposes specific ways of its conceptual solutions.

Obsah Obsah ..................................................................................................................................... 5 Úvod ...................................................................................................................................... 7 1. Co je to datová kvalita? ................................................................................................. 8 1.1 Základní terminologie ......................................................................................... 10 1.1.1 Co jsou to vlastně data? ............................................................................... 10 1.1.2 A co metadata? ............................................................................................ 10 1.2 Kdy jsou data kvalitní? ........................................................................................ 11 1.3 Proč jsou data nekvalitní? .................................................................................... 12 1.4 Vydefinované problémy v oblasti datové kvality ................................................ 13 1.5 Datová kvalita ve srovnání s kvalitou informační ............................................... 13 1.6 Moţné přístupy k řešení datové kvality v organizaci pomocí tzv. frameworks .. 15 2. Která data jsou pro banku důleţitá? ............................................................................ 19 2.1 Která data jsou klientská? .................................................................................... 20 2.2 K čemu ID?.......................................................................................................... 23 2.2.1 Typické problémy, které s sebou identifikace dle RČ přináší: .................... 23 2.3 Kvalitní řízení ...................................................................................................... 25 2.3.1 Řízení finančních institucí a jejich dělení.................................................... 26 3. Způsoby zjišťování poţadavků na datovou kvalitu ..................................................... 28 3.1 Co je DQA? ......................................................................................................... 28 3.2 Dotazník a jeho pravidla ...................................................................................... 30 3.2.1 Technika dotazníku – jednotlivé etapy při jeho tvorbě ............................... 30 3.2.2 Druhy otázek a odpovědí, které jsou v dotazníku pouţity .......................... 31 3.2.3 Po sběru dat následuje vyhodnocení dotazníku ........................................... 31 3.2.4 Dotazník ADASTRA................................................................................... 32 3.2.5 Dotazník pouţitý pro konkrétní zjišťování v bance .................................... 42 3.2.6 Implementace výsledků dotazníkového šetření do frameworku ................. 45 4. Vyhodnocování dopadů nekvality v datech na samotný předmět podnikání banky ... 47 4.1 Objektivní metoda nebo potenciál zlepšení? ....................................................... 47 4.2 Analýza nákladů na nekvalitu.............................................................................. 50 5. Návrhy a způsoby řešení datové nekvality v bance..................................................... 51 5.1 Definice datových standardů ............................................................................... 52 5.1.1 Pravidla uţití datových standardů................................................................ 53 5.1.2 Prvky datových standardů ........................................................................... 54 5.1.3 Role v datových standardech ....................................................................... 54 5.1.4 Obecná část definice standardu ................................................................... 55 5.2 Školení datové kvality ......................................................................................... 55 5.3 Útvar datové kvality ............................................................................................ 56 5.4 On-line prevence.................................................................................................. 57 5.4.1 SAS DataFlux .............................................................................................. 58 5.5 Čištění dat ............................................................................................................ 61 5.5.1 Etapy procesu čištění dat ............................................................................. 62 5.5.2 Ataccama ..................................................................................................... 64 5.6 Statická data......................................................................................................... 65 5.6.1 Unifikace klientů ......................................................................................... 66 5.6.2 Unifikace číselníků ...................................................................................... 67 5.7 Metriky pro měření datové kvality ...................................................................... 68

5.8 KPI a Balanced scorecard .................................................................................... 69 5.9 Měření datové kvality .......................................................................................... 70 Závěr a doporučení .............................................................................................................. 73 Seznam pouţité literatury .................................................................................................... 74 Seznam pouţitých obrázků .................................................................................................. 77 Seznam pouţitých tabulek ................................................................................................... 79

Úvod Cílem práce je podat čtenáři ucelenou informaci o rozsahu, způsobech a oblastech měření kvality rozhodujících klientských dat, které banka vyuţívá ke své činnosti. Definovat, která data jsou pro banku rozhodující a z jakého pohledu a zabývat se moţnostmi koncepčního řešení udrţení jejich kvality. Při zpracování je vycházeno z konkrétní situace v konkrétní bance.

1. Co je to datová kvalita? K nejcennějším aktivům všech současných společností, patří vedle jejich vlastního know-how zejména data a z nich plynoucí informace a znalosti. Pokud data, se kterými společnost pracuje, jsou jakýmkoli způsobem znehodnocena nekvalitou, je obvykle velmi obtíţné aţ nemoţné z nich získat potřebné informace a znalosti. Respektive získané informace a znalosti jsou pak neúplné, značně zkreslené či dokonce zcela chybné a vůbec nemusejí odráţet skutečnost reálného světa. Několik příkladů z praxe, které názorně ukazují, proč je nutné se zabývat datovou kvalitou. Příklad 1.1: Hotel nepředvídaně nabízel rezervace svých pokojů pro pobyt přes Nový rok za zlomek jejich normální ceny z důvodu závady v počítači. Šťastní zákazníci tak platili pouhé 2 Lstg. místo 200 Lstg. za pokoj ve čtyřhvězdičkovém hotelu Marriott v Huntingdonu, Cambs. Manaţer Ian Pask řekl, ţe kdyţ hotel přijal rezervace, musí je respektovat. Přijali jsme rozhodnutí, ţe jsme udělali chybu. Zvedli jsme ruce a respektovali to. Příklad 2.1: Systém Tokijské burzy selhal, kdyţ nezabránil zrušení nákupu akcií za obrovskou sumu 27 miliard yenů. Chyba vznikla týden předtím, kdyţ zaměstnanec obchodníka s cennými papíry, firmy Mizuho Securities chybně natypoval prodej akcií firmy J-Com. Místo prodeje jedné akcie za 610.000 yenů, natypoval prodej 610.000 akcií za 1 yen. Tokijská burza přiznala, ţe díky selhání jejího systému, nemohla tato chyba být včas stornována. Příklad 3.2: Při e-mailové kampani jedné britské maloobchodní společnosti se ukázalo, ţe jedna pětina oslovených uţ zemřela. Přesto (nebo pro to?) byli obesláni s pozdravným oslovením „Drahý pane Zesnulý“. Příklad 4.2: 44 000 - 98 000 Američanů ročně umírá na základě odvratitelné medicínské chyby jako přepsání při psaní receptu, špatně popsaný výsledek krevní 1 2

KUČERA, Milan; NOVOTNÝ, Marek: Kvalita dat. TietoEnator, elektronická prezentace, 2009 SNÍDANĚ SE SASem: Datová kvalita. SAS, elektronická prezentace, 2009

8

zkoušky, nečitelná informace v pacientských záznamech atd. Je to osmá nejčastější příčina úmrtí v USA. A na závěr několik konkrétních případů z praxe české banky (vlastní zdroj, z důvodu zachování bankovního tajemství záměrně pozměněna jména a data): Příklad 1.: Klient neobdrţel za měsíc červen 2006 výpis ze svého účtu. Na výpisech, které obdrţel, si všiml, ţe mu byla změněna z pro něj neznámého důvodu adresa. Správná adresa je Jugosl. partyzánů 1262/1, nyní mu chodí pouze Jugosl. partyzánů 12 a proto se obává, ţe jeho výpisy můţe obdrţet jiná osoba. Příklad 2.: Klientka si na pobočce přejmenovala účet z Šulcové na Pencovou z důvodu změny klientčina příjmení. Po roce jí stále chodí domů výpis v obálce na jméno Šulcová, uvnitř na výpise je uvedeno jméno Pencová. Příklad 3.: Banka měsíčně nedoručí cca 5000 výpisů, coţ představuje ztrátu 540 000 Kč za tisky a poštovné. Příklad 4.: Za sledované čtvrtletí bylo v bance k manuálnímu čištění předáno na pobočky banky 102 661 chyb. To představuje při průměrné pracnosti 5 minut na jednu chybu celkovou pracnost 1069 dní, tj. 4 277 000 Kč. Při stejném trendu za celý rok by to znamenalo náklady 17 110 164 Kč ročně. Příklad 5.: Velká česká banka B, která má expozici u zkoumané banky A, se podle údajů v informačním systému banky A náhle ocitla v konkurzu. Při zkoumání bylo zjištěno, ţe chyba vznikla v celostátní veřejné databázi OVEL, která shromaţďuje údaje o konkurzech z celé ČR na základě soudních usnesení a ze které je příznak konkurzu určován. Soudní úřednice na Krajském soudu Brno udělala chybu v zápise, kdyţ zaměnila IČ povinného s IČ navrhovatele ve věci projednávaného konkurzu. A rázem se z navrhovatele stal povinný, coţ mělo v konečném důsledku v bance A za následek poplach nejvyššího stupně, protoţe bance náhle vyvstala potřeba tvorby opravných poloţek v řádu stovek milionů korun. Tento případ jsem řešil osobně a za dobu, kdy se datovou kvalitou zabývám, nastal v rozmezí 2 let 2x a pokaţdé na stejném Krajském soudu.

9

Chybná interpretace závěrů, které jsou vyvozeny z nekvalitních dat můţe vést později k chybným rozhodnutím, která mohou mít pro danou společnost fatální důsledky, mohou poškodit její vnímání vnějším okolím tím, ţe poškodí její image, v důsledku čehoţ můţe společnost pocítit odliv klíčových zákazníků a partnerů a můţe tak být silně ovlivněna její pozice na trhu. Jinými slovy,, nesprávná data vedou k nesprávným výsledkům jejich zpracování a v důsledku ke špatnému fungování podnikových procesů s následkem ekonomických ztrát. Další ekonomické ztráty pak představují náklady, vynaloţené na boj s datovou nekvalitou, zvlášť, pokud jsou vynaloţeny nesystémově. Ale o tom bude řeč později. Na základě provedených analýz a vyhodnocených projektů, zabývajících se informační kvalitou (více neţ 200 zákazníků společnosti Information impact international, Inc. USA) je patrné, ţe náklady, způsobené nekvalitními daty a informacemi dosahují 15% aţ 25% podíl na výnosech respektive trţbách těchto společností3.

1.1 Základní terminologie 1.1.1 Co jsou to vlastně data? Definic existuje více, ale z pohledu a pro potřeby této práce definuji data jako odraz reality v databázi. Data mají své atributy, které určují jejich vlastnosti. Jsou definovány vzájemné vztahy mezi daty. Data jsou organizována a uchovávána v databázích. Nejčastějším druhem databáze jsou databáze relační, které umoţňují nejsrozumitelněji definovat formáty dat, jednotlivé vztahy mezi daty, definovat primární a cizí klíče a kardinalitu vazeb mezi nimi tak aby v databázi nedocházelo ke zbytečné redundanci dat a data byla jednoznačně určena.

1.1.2 A co metadata? Sklenák4 ve své publikaci definuje metadata jako objekty slouţící k popisu informační jednotky, pro potřeby popisu WWW dokumentů se prosazuje iniciativa Dublin Core. Účel spočívá ve snazším nakládání s danou informační jednotkou. Tato definice, či 3 4

ENGLISH, Larry: Improving data warehouse and business information quality, JWS, 1999 SKLENÁK, Vilém a kolektiv: Data, informace, znalosti a Internet, C.H.Beck Praha, 2001

10

lépe řečeno stručný popis je příliš úzce zaměřený a nevystihuje obecnou definici metadat. Podle jiné literatury, která metadata vztahuje k datovému skladu, coţ je přesně to umístění, kde vidím metadata pro účely této práce, metadata popisují obsah datového skladu, udávají, odkud jsou data získávána a dokumentují pravidla pro transformaci dat, respektive pro řízení extrakce, čištění a ukládání dat.5 Poměrně podrobně se oblasti metadat věnuje David Loshin6. Říká, ţe dle standardní definice jsou to data o datech. Dělí metadata na technická a business, přičemţ technická podrobněji rozděluje podle účelu jejich pouţití (indexová, datového modelu, tabulkové informace, informace o struktuře záznamů, metadata o síťové konektivitě, informace o manipulaci se záznamy, metadata o bezpečnosti a přístupu, fyzické vlastnosti, referenční metadata, řídící, transformační, procesní a dodávková metadata). Metadata se nacházejí v metadata repository, coţ je samostatný prostor informačního systému, kde jsou metadata fyzicky uchovávána, aktualizována a udrţována a odtud jsou distribuována napříč celým systémem. Existence metadata repository je základním předpokladem pro jednotnou a efektivní správu metadat. Metadata jsou zkrátka data o datech. Slouţí k popisu dat, čili poskytují informačním systémům a jejich uţivatelům údaje o jejich obsahu, významu a dalších vlastnostech.

1.2 Kdy jsou data kvalitní? Tento pohled je vţdy subjektivní a je ovlivněn několika faktory: 

faktor konzumenta - kdo data potřebuje,



faktor granularity – do jaké hloubky a v jaké úrovni je na data pohlíţeno a pracováno s nimi,



faktor potřeby - jaké poţadavky jsou na data vznášeny.

Obecně tvrdím, ţe data jsou kvalitní tehdy, kdyţ splňují poţadavky zákazníků, kteří je konzumují. Z tohoto pohledu je tedy moţno říct, ţe například pro oddělení marketingu 5

NOVOTNÝ, Ota; POUR, Jan; SLÁNSKÝ, David. Business Inteligence Jak využít bohatství ve vašich datech, Grada Praha, 2005 6 LOSHIN, David: Business Inteligence THE SAVVY MANAGER´S GUIDE, Morgan Kaufmann Publisher, 2003

11

budou data z hlediska kvality naprosto v pořádku, zatímco ta samá data pro oddělení např. credit risku budou zcela nevyhovující. Při hodnocení datové kvality je nutné vycházet z předpokladu negativní zpětné vazby. Coţ znamená, ţe osoba zabývající se ve firmě datovou kvalitou, se nikdy nedozví, ţe data jsou v pořádku, ale dozví se kdy data v pořádku nejsou. To, ţe nejsou v pořádku uţ od prvopočátku jejich shromaţďování, ale doposud se s nimi nijak nepracovalo, je ten horší případ datové nekvality. Shrneme-li to, můţeme říci, ţe data jsou kvalitní v okamţiku, kdy: 

data splňují zadané specifikace,



lze zaručit správnou interpretaci dat,



data jsou vhodná pro řešení našich obchodních problémů.

1.3 Proč jsou data nekvalitní? Důvody, proč vznikají nekvalitní data, jsou v zásadě dva: 1.

pro veškeré systémy, které s daty pracují, musí být splněn základní předpoklad, kterým je pořízení dat. Data jsou buď dodávána jako automatizované vstupy například z nějakých digitálních snímačů, které data dodávají naprosto bezchybně do doby, neţ dojde k jejich poruše nebo nepředvídatelné okolnosti, se kterou nepočítal ani výrobce, ani operátor, který měřící zařízení instaloval. Nebo jsou data

pořizována jako ruční

vstupy, kde hraje významnou roli lidský faktor. A člověk dělá chyby. Ty se mohou projevit jako překlepy, zápisy do nesprávných polí, neznalost, vlastní tvořivost a podobně, 2.

informační systémy podniků v dnešní době tvoří více autonomních modulů obsluhujících oddělené agendy. Autonomní moduly jsou zaměřeny na různé oblasti, mají své vlastní rozhraní, svůj vlastní způsob evidence, poplatný době svého vzniku a vzájemná koordinace a propojení mezi těmito moduly je téměř nemoţná respektive velmi omezená. Data která jsou v jednotlivých modulech bezchybně uloţena, nejsou jednotně interpretována. Například modul práce a mzdy vede kaţdého zaměstnance pod jeho osobním číslem,

12

naopak modul skladové hospodářství vede zaměstnance pod jeho rodným číslem.

1.4 Vydefinované problémy v oblasti datové kvality Z hlediska mnou definované datové kvality musí data splňovat následující atributy: 

přesnost dat - například slovně specifikované parametry produktové instance,



úplnost dat - například neúplné adresní informace o zákazníkovi,



včasnost – kvalita z hlediska časového měřítka, včasně dodaná data jsou relevantní pro dané období,



jedinečnost dat - například duplicita zákazníka,



konzistence dat - například různá adresa zákazníka v různých systémech,



stáří dat – některá data mohou stárnout a se svým stářím mohou ztrácet svou věrohodnost a aktuálnost; například datum narození je údaj, který se v čase nemění, ale korespondenční adresa, rodinný stav či povolání se měnit mohou.

Datová kvalita zahrnuje nejen fyzický stav dat, ale i procesy nakládání s nimi.

1.5 Datová kvalita ve srovnání s kvalitou informační Dílčí projekty, které jsou na datovou kvalitu zaměřené, se zabývají řešením problémů na úrovni vlastních dat, například záznamů v databázích, respektive dat zpracovávaných během vnitropodnikových procesů, které v podniku probíhají. Řešení datové kvality je pak povětšinou realizováno v rámci integrace stávajícího standardního softwarového produktu do podnikových procesů a databází nebo vývojem vlastního řešení přímo na přání zákazníka. Jako příklad standardního softwarového řešení lze uvést produkty firem Trillium Software7 či Informatica8. S nástrojem Informatica Data

7 8

http://www.trilliumsoftware.com/home/index.aspx http://www.informatica.com/Pages/index.aspx

13

Quality 8.6 jsem se seznámil na pracovní snídani, kterou pořádala společnost Profinit. Součástí projektů orientovaných na datovou kvalitu bývají i zcela nové prvky v komplexní systémové architektuře včetně jejich integrace do existujících informačních systémů. Řešení problémů s informační kvalitou v sobě zcela jistě musí zahrnovat i řešení datové kvality, ale primárně je zaměřeno spíše na procesy. Velkou část řešení tohoto typu projektu tvoří pracovní workshopy a interview se zaměstnanci, analýza problémových míst a návrhy řešení. Výstupem projektu je pak zejména dokumentace s navrţenými přepracovanými firemními procesy a návrh takového technického řešení, které takovéto změny podpoří a umoţní. Uvedený vztah informací a dat názorně popisuje následující obrázek.

Obrázek 1: Vztah informací a dat (zdroj Kalvoda)9 Podle tohoto obrázku jsou pak informace tvořeny funkcí dat, definice a prezentace: informace = f(data, definice, prezentace)9.

9

KALVODA, Jaroslav:Information duality return on investment. PROFINIT, pracovní snídaně 24.11.2005

14

1.6 Moţné přístupy k řešení datové kvality v organizaci pomocí tzv. frameworks Zatímco objektově orientovaný přístup zlepšil koncept modulů, protoţe díky principu předávání usnadňuje změny, aniţ vznikají nové varianty modulů, koncept framework jde ještě dále. Obsahuje sbírku komponent a skládá je pro konkrétní pouţití.10 Obecně je framework struktura, která slouţí jako podpora při analýze, řešení, vývoji a organizaci daného projektu. Namísto objektově orientovaného principu předávání nastupuje i kompoziční princip, tedy ţe komponenty jsou skládány do frameworku podle účelu pro konkrétní pouţití, nikoli podle příslušnosti k objektům.

Obrázek 2: Architektura ARIS-Business Framework (zdroj ARIS)10 Při studii způsobů a náhledů na řešení datové kvality jsem se setkal s několika frameworky, z nichţ tři nejzajímavější zde přímo cituji a čtvrtý uvádím jako ten, podle kterého budu provádět konkrétní řešení.

10

SCHEER, August-Wilhelm: ARIS - od podnikových procesů k aplikačním systémům. IDS Scheer ČR s.r.o., Brno, 2002

15

Framework dle metodologie TIQM11, jehoţ autorem je jeden ze dvou celosvětově nejuznávanějších odborníků na datovou kvalitu a nositel hlavních myšlenek metodologie TIQM, Larry English. Jedná se o celosvětově uznávaný, komplexní standard v oblasti řízení kvality dat, který je nezávislý na konkrétních nástrojích. Vlastní podrobný popis této metodologie by vydal na samostatné téma bakalářské či diplomové práce, protoţe Larry English o tomto frameworku napsal celou knihu. Jednotlivé oblasti, označené jako P1 – P6 potom dále rozvádí podrobněji do větších detailů a konkrétnějších frameworků spolu s obecnými postupy řešení. Proto zde uvádím pro ilustraci a konkrétní představu pouze samotný základní framework.

Obrázek 3: Základní framework TIQM metodologie (zdroj English)11 Z obecné metodologie TIQM vychází následující příklad frameworku, který byl vytvořen pro potřeby velké bankovní instituce v rámci komplexního řešení projektu datové kvality. Framework zahrnuje analýzu poţadavků, koncept řešení kvality dat, gap analýzu a návrh řešení.

11

ENGLISH, Larry: Improving data warehouse and business information quality, JWS, 1999

16

Obrázek 4: Framework projektu řešení datové kvality v bance (zdroj TietoEnator)12 Jako další vhodnou a inspirativní ukázku hotového pohledu na komplexní řešení DQ uvádím framework od firmy Adastra, který představila ve svém příspěvku v rámci konference Business Briefing „Data Governance“ dne 23.5.2008 v hotelu Corinthia Towers v Praze.

Obrázek 5: Framework Data Governance (zdroj Adastra)13

12 13

KUČERA, Milan; NOVOTNÝ, Marek: Kvalita dat. TietoEnator, slide z přednášky 2006 SLÁNSKÝ, David; GRATTON, Simon: Data Governance. ADASTRA,slide z přednášky 2008

17

Poslední framework je sestaven přímo pro účel této diplomové práce. Jedná se o framework, sestavený na míru pro konkrétní řešení situace v oblasti datové kvality v konkrétní české bankovní instituci, jejíţ analýzou a řešením se v této práci zabývám pouţívám.

Framework bude slouţit jako základní stavební kámen pro řešení datové

kvality a vycházím z něj v poslední části práce s názvem „Návrhy a způsoby řešení datové nekvality“.

Obrázek 6: Framework této práce (zdroj vlastní)

Jako doplnění posledně jmenovaného frameworku a upřesnění pohledu na datovou kvalitu z hlediska nákladů uvádím ilustrativní graf, který popisuje ztráty z podnikání, souvisejících s nekvalitou dat a náklady na její prevenci odstraňování chyb versus celkové náklady. Z grafu je zřejmá souvislost a vzájemná závislost mezi prevencí a inspekcí dat neboli mezi tím, kolik stojí čištění dat, opravné procesy, evidence chyb, vývoj a implementace kontrol, chybové reporty versus školení lidí, jednotná unifikace, správně nastavená metadata, data governance, správně nastavené business procesy (kontroly na vstupu), nastavená klíčová měřítka kvality (KPI) a pravidelné vyhodnocování.

18

Obrázek 7: Graf prevence versus inspekce (zdroj Profinit)14

2. Která data jsou pro banku důleţitá? Cílem jakéhokoli podnikání a tedy i bankovnictví, je dosahování zisku. Toho dosahuje banka nabídkou a prodejem finančních produktů a sluţeb. Pro optimální chod bankovní instituce a dosahování vytyčených cílů jsou zapotřebí dva základní předpoklady: 

úspěšný prodej bankovních produktů jako trvalé a cílevědomé

uspokojování finančních potřeb klientů, 

kvalitní řízení.

14

KALVODA, Jaroslav:Information duality return on investment. PROFINIT, slide z pracovní snídaně 2005

19

Uspokojení potřeb klientů se ziskem a vytváření pozitivního vztahu klientů k bance jsou předpokladem pro dlouhodobou stabilitu, konkurenceschopnost a ziskovost banky, a proto je jim podřizována volba cest a nástrojů při řízení všech bankovních činností. Nabídka bankovních domů na trhu je vyrovnaná, nabízené produkty mají srovnatelné parametry a jsou snadno zaměnitelné. Pro udrţení stávajících klientů a získání nových klientů jsou proto rozhodující kvalita sluţeb a poradenství a to, zda je vzájemný vztah k bance pro klienta něčím unikátní. Zkušenosti ukazují, ţe pro identifikaci prodejních příleţitostí a jejich vyuţití jsou nezbytná důkladná analýza klientových potřeb a jim přizpůsobená nabídka řešení. Stále většího významu nabývá rozvoj vztahu klient banka a klient-poradce. Banky zavádějí samostatné koncepty péče o klienta, které jsou v podstatě souhrnem zásad a pravidel, která uplatňují pro řízení vztahu klienta a banky na všech úrovních s cílem dosáhnout vysokého stupně loajality klienta při současném zachování a zvyšování ziskovosti. Trendy a aktivity spojované s tímto úsilím jsou například klientský přístup, segmentace klientů či měření indexu spokojenosti zákazníka. Předpokladem pro úspěšnou realizaci všech těchto myšlenek jsou opět kvalitní dat pro daný účel. Z hlediska datové kvality je proto bezpodmínečně nutné mít pro úspěch tohoto konceptu k dispozici kvalitní klientská data.

2.1 Která data jsou klientská? Z fundamentálního pohledu jsou pro kaţdou banku tato data stejná. Je to základní identifikace vlastní osoby, jejího bydliště a atributů popisujících její vztah k okolí. K tomuto základnímu souboru dat pak podle potřeby a granularity náleţí další, takzvané doplňující atributy. Klientská data si definuje kaţdá banka individuálně, pokud má více neţ jeden klientský IT systém, pak je nezbytně nutné, aby to udělala. Děje se tak prostřednictvím firemního datového modelu (dále FDM) respektive datového slovníku. FDM udává výčet základních datových entit a vazby mezi nimi. Datové

20

entity jsou definovány jednoznačně určenými definicemi obdobně jako výklad hesla ve slovníku či encyklopedii. Vztahy mezi entitami jsou dány schématem, ve kterém jsou vyznačeny pouze přípustné vazby mezi relevantními entitami. Entity FDM jsou po jeho schválení a publikaci v bance standardem pro design databází nových systémů a směr změn stávajících databází. Výrazně usnadňuje integraci systémů. Entitami mohou například být: adresní bod - adresní bod je charakterizován zpravidla PSČ, jménem ulice nebo obce a číslem popisným; je moţné adresy rozdělit na čisté adresy, zahraniční adresy a ostatní adresy; entita můţe obsahovat GPS souřadnici, územní celek, doručovací poštu, běţný účet - účet klienta který banka vede; zachycuje klientovy výběry a vklady; výpisy z účtu jsou zasílány klientovi v dohodnutých intervalech; ve prospěch účtu přijímá banka vklady nebo platby a dnem připsání je úročí. FDM je jednotný jazyk v babylonském prostředí IT systémů banky. Při tvorbě této práce jsem měl k dispozici konkrétní FDM banky, jedná se však o interní materiál, k jehoţ publikaci v této práci nemám souhlas. Základní klientská data: 

jedinečný identifikátor klienta,



rodné číslo,



datum narození,



jméno,



druhé jméno,



příjmení,



druhé příjmení,



titul před jménem,



druhý titul před jménem,



titul za jménem,



druhý titul za jménem,



třetí titul za jménem,



právní forma, 21



adresa trvalého pobytu, o ulice, o číslo popisné, o číslo orientační, o PSČ, o název obce/města,



kontaktní adresa, o ulice, o číslo popisné, o číslo orientační, o PSČ, o název obce/města.

Doplňkové klientské údaje: 

klientský segment,



nejvyšší dosaţené vzdělání,



mobilní telefon,



pevná linka,



e-mail,



název zaměstnavatele,



adresa zaměstnavatele,



výše příjmu,



strukturovaná výše výdajů,



a další…

Kvalita dodaných dat je závislá na kvalitě zdrojových systémů, které tato data dodávají. Údaje, které mají povahu číselníku, není vhodné vypisovat ručně, ale vybírat z předem připraveného datového souboru. Dále je vhodné specifikovat, které poloţky je nutno vyplnit jakoţto mandatorní a systémově tuto povinnost ošetřit. O těchto konkrétních kontrolách bude řeč v dalších kapitolách. V dnešní době jiţ zdrojové systémy mají tyto vstupy ošetřeny kontrolami, ale historicky existuje velké mnoţství nepřesností, omylů, překlepů apod., které se do systémů dostaly dříve.

22

2.2 K čemu ID? Zastavme se nyní u čtyřech nejzákladnějších klientských identifikátorů a sice rodného čísla, jména, příjmení a tzv. ID. Proč zrovna ID a k čemu slouţí? Z praxe vyplynul poznatek, ţe ne vţdy je rodné číslo jedinečným identifikátorem osoby, ačkoliv v reálném ţivotě tomu tak je. A s tímto poznatkem vyvstala potřeba jednoznačné identifikace klienta pro vnitřní potřeby banky.

2.2.1 Typické problémy, které s sebou identifikace dle RČ přináší: 

moţný vznik duplicity – tj. případ, kdy dvěma osobám je přiděleno stejné rodné číslo,



problém

s cizinci

–

cizinci

nemají

rodné

číslo,

v případě

dlouhodobého pobytu je jim přidělováno aţ dodatečně; banky toto překlenovací období řeší pomocí jednotné konvence např. 9999999999 nebo RRMMDD9999 kde RR je rok narození, MM měsíc narození a DD den narození klienta, 

změna pohlaví osoby,



různá interpretace devítimístného RČ a desetimístného RČ; konkrétně

v době

před

rokem

1989

existoval

v Československé státní spořitelně příkaz, aby byla devítimístná rodná čísla, která byla přidělována občanům narozeným do roku 1954, doplněna na desetimístná přidáním jedné nuly; nejednoznačně definovaný a špatně kontrolovaný pokyn vyústil v problémy,

kdy

rodné

číslo

545512/398

bylo

interpretováno jednou jako 545512/0398 a podruhé jako 545512/3980 přestoţe v obou případech se jednalo o tutéţ osobu,

23



problém s úřadem na ochranu osobních údajů – ještě před dvěma roky bankám reálně hrozilo, ţe budou muset přestat uchovávat rodná čísla svých klientů.

Jednoznačná identifikace podle jedinečného ID pak s sebou nese potřebu unifikace jednotlivých klientských instancí v datovém skladu. Konstrukce jedinečného ID můţe být různá. Například můţe být odvozena od data, kdy dojde k zapsání záznamu o klientovi do databáze, k němu se přiřadí otisk časového razítka a vypočítá kontrolní součet. Takto vzniklé jedinečné identifikační číslo je klientovi přiděleno interně a nese jej s sebou unifikovaný záznam o klientovi v datovém skladu. Problémy s unifikací klientů názorně přibliţuje následující obrázek, který znázorňuje hypotetický, ale nikoli přehnaný příklad spojování údajů o klientovi z několika zdrojových systémů do jednoho unifikovaného záznamu:

Obrázek 8: tabulka problémů při unifikaci klientů (zdroj vlastní) Pro další, tentokráte konkrétní případ problémů nyní nikoli s unifikací, ale se správným zápisem jednoho a téhoţ údaje v několika různých systémech, různými lidmi a pro různé klienty uvádím na následujícím obrázku výsledky analýzy, která byla v konkrétní bance provedena v roce 2005 nad daty v datovém skladu kontrola relevance poštovního směrovacího čísla a názvu obce. Název města Ústí nad Labem zde existoval celkem v 92 mutacích(!):

24

Obrázek 9: Mutace zápisu Ústí nad Labem (zdroj vlastní) Pro některé ze zmiňovaných údajů, pro banku důleţitých, existují uţ dnes veřejně dostupné etalony, jejichţ implementací do zdrojových systémů, ve kterých jsou data primárně pořizována, lze efektivně docílit potlačení rizika chyby z ručního pořízení dat. Na druhou stranu je ale i zde stálé riziko plynoucí ze zastarávání stavové informace v čase, takţe kdyţ například klient změní místo trvalého bydliště, je vypovídací schopnost správně napsané adresy bývalého trvalého bydliště nulová. Tomuto způsobu řešení včetně výhod a nevýhod se ale budu věnovat v jiné kapitole.

2.3 Kvalitní řízení V úvodu této kapitoly bylo řečeno, ţe pro optimální chod bankovní instituce a dosahování vytyčených cílů jsou zapotřebí dva základní předpoklady a sice úspěšný prodej bankovních produktů jako trvalé a cílevědomé uspokojování finančních potřeb klientů. Tomu se tato část práce v kapitole tři věnovala doposud. Jako další předpoklad je kvalitní řízení.

25

2.3.1 Řízení finančních institucí a jejich dělení Řízení finančních institucí je moţno rozdělit do několika základních kategorií a podkategorií. Je to: 



finanční řízení, o

finanční výkazy organizačních jednotek,

o

detailní profitabilita klientů, produktů, segmentů,

o

regulatorní reporting,

řízení rizik, o

plnění poţadavků regulátora dle evropské směrnice Basel II,

o

řízení kreditního rizika,

o

řízení trţního rizika,

o

řízení operačního rizika,

o

práce s externími databázemi dluţníků tzv. registry jako jsou CBCB/BRKI, SOLUS, overdue monitoring pro sledování pohledávek po lhůtě

o

splatnosti a jejich účinné vymáhání, 

marketing, o

data monitorující dlouhodobé chování klientů během trvání vztahu banka-klient pro potřeby behaviorálního skóringu,

o

provádění analýz podle jednotlivých klientských segmentů a provádění odvětvových analýz,

o

měření response rate neboli úspěšnosti marketingových kampaní na základě odezvy klientů ,



obchod, o

měření

výkonnosti

prodejní

sítě

motivačního systému, 

provoz, o

provozní reporting,

o

podklady pro fakturaci či poplatkování,

o

měření výkonnosti.

26

včetně

nastavení

Z výše uvedeného plyne, ţe pro banku jsou důleţitá i další, takzvaná neklientská data. Tato data, stejně jako data klientská, jsou pořizována ve zdrojových systémech a následně sbírána, organizována a uchovávána v datovém skladu. Konsolidovaná data o klientech pak putují z DWH do analytického a transakčního CRM15, kde s nimi aktivně pracují obchodní jednotky banky. Mají zde k dispozici i základní informace o klientských obchodech, ovšem platí, ţe detailní informace jsou k dispozici ve zdrojových systémech. Datový sklad, postavený na databázi Oracle16, se skládá ze dvou základních komponent. Jsou to databáze ODS a databáze DWH. V databázi ODS dochází k načítání všech vstupních dat, provádí se zde jejich čištění a unifikace a následně jsou přenášeny do databáze DWH, kde jsou uloţena trvale. DWH databáze je zdrojem dat pro další analytické nástroje, které podporují činnosti, potřebné pro kvalitní řízení banky, viz. výše vyjmenované. Například do Cognos reporting toolu17 pro tvorbu obchodních reportů a manaţerských výkazů, do dataminingového nástroje pro podporu cross-sellingových obchodních příleţitostí pro jednotlivé klienty a podobně. Logickou architekturu datového skladu na obecné úrovni včetně vyznačení probíhajících procesů a datových toků uvnitř a směrem ven popisuje následující obrázek:

Obrázek 10: Schéma datového skladu a ETL procesů (zdroj Miniberger)18

15

http://www.oracle.com/siebel/index.html http://www.oracle.com/us/solutions/datawarehousing/index.htm 17 http://www-01.ibm.com/software/data/cognos/products/cognos-8-business-intelligence/reporting.html 18 MINIBERGER, Bohumil: Modelování a návrh datových skladů. Slide z přednášky na BIVŠ, 2010 16

27

Je zřejmé, ţe jde o poměrně sloţitý systém navzájem propojených komponent, mezi něţ jsou včleněny procesy, které mají za úkol provádět výše uváděné konsolidace a unifikace, dopočítávají některé hodnoty, poţadované uţivateli nebo nutné pro lepší podporu dalších procesů. ETL procesy mají významnou funkci také při čištění dat – více v kapitole o čištění dat.

3. Způsoby zjišťování poţadavků na datovou kvalitu Drţet se při řešení datové kvality slepě procesů, uvedených ve frameworku, není vhodné. I po DQ framework platí: „Dobrý sluha, špatný pán“. Framework ve své iniciační verzi musí zůstat ţivým dokumentem, který se dále zpřesňuje na základě zjištěných konkrétních potřeb organizace, ve které je datová kvalita řešena. Obecný rámec zůstává v nezměněné podobě, mění respektive upřesňují se jen dílčí poţadavky na řešení datové kvality. Cílem je vyhnout se stavu, kdy by došlo přímo k implementaci konkrétního nástroje slouţícího k opravě datových chyb, který by opravoval data, jeţ nejsou pro organizaci důleţitá a naopak opomněl data, kvůli kterým byl projekt datové kvality vyvolán.

3.1 Co je DQA? Hodnocením kvality dat se zabývá Data quality assessment, které je objektivní a měřitelné a provádí se automaticky pomocí vhodně zvoleného DQ nástroje. Na straně zákazníka se nejprve provádí zjišťování aktuálního stavu dat a následná analýza moţností zvyšování jejich kvality, která přinese jednak identifikaci a kvantifikaci největších chyb v datech a je opakovatelně vyuţitelná pro monitoring a reporting kvality dat. Pro získání těch správných dat je nutné oslovit všechny útvary banky, které s daty pracují a vhodně zvolenou formou získat potřebné informace o datech samotných a o jejich důleţitosti.

28

získání dat

základní analýza

data profiling upřesnění poţadavků hodnocení kvality atributů

detailní analýza

hodnocení kvality entit další analýzy interpretace výsledků

zpracování výstupů

hodnocení dopadů doporučení dalšího postupu Tabulka 1: Schéma DQA (zdroj vlastní) Nejvhodnější způsob pro tato zjišťování je forma dotazníku, která je součástí jednoho druhu z takzvaných neúplných zjišťování a sice ankety. Anketa je takový způsob zjišťování, při kterém se určitému okruhu osob rozešlou dotazníky s pečlivě sestavenými otázkami a s ţádostí o jejich vyplnění a vrácení. Ţádosti vyhoví zpravidla jen určitá část někdy dokonce jen část poměrně malá – ze všech dotázaných. (V průměru asi jedna třetina.) Charakteristiky, jako průměry, různé poměrné hodnoty a jiné shrnující veličiny, které se vypočtou na základě údajů z obdrţených odpovědí, nelze však povaţovat za obecně platné, protoţe mezi odpovědí nebo jejím odmítnutím na jedné straně a dotazovanou skutečností na druhé straně bývá dosti úzký vztah (souvislost, asociace). Například dotazník o výši příjmů často nevyplní a nevrátí osoby s relativně vysokými (nebo utajovanými příjmy), dotazník o čtenářských zájmech nevrátí spíše čtenáři zábavné literatury apod. Klasická anketa, u které uţ dopředu předkladatel počítá s návratností menší neţ 100% (v praxi zmiňovaných 33%), není proto vhodná, nicméně je vhodná její forma a to dotazník. Je jasné, ţe kvalitní podklady jsou základem pro kvalitní zjištění a proto je cílem obdrţet 100% vyplněných dotazníků zpět pomocí tzv. dotazníkového šetření.

29

Obrázek 11: Formy komunikace a jejich efektivnost (zdroj Buchalcevová)19

3.2 Dotazník a jeho pravidla 

jasná hlavní myšlenka dotazníku, tzn. na koho se s dotazníkem

budeme obracet a co je jeho cílem, 

krátké, jasně a stručně formulované dotazy,



psychologické faktory – dotazování budou mít často tendenci

odpovídat způsobem, který oni povaţují za správný, i kdyţ nemusí být pravdivý 

kontrolní otázky.

3.2.1 Technika dotazníku – jednotlivé etapy při jeho tvorbě

19



úvodní rozhodnutí,



zařazení jednotlivých otázek,



forma a tvar otázek,



tvar odpovědí,



sled otázek,

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. Grada, Praha, 2005

30



tvar dotazníku,



předběţné testování.

3.2.2 Druhy otázek a odpovědí, které jsou v dotazníku pouţity 

uzavřené – dotázaný volí jednu či více z nabízených odpovědí,



otevřené – dotázaný pouţije své vlastní formulace,



polouzavřené – nabízené moţnosti + alternativa odpovědět volně mimo,



filtry – zvláštní typ otázek, který rozděluje dotázané na ty, kterým budou poloţeny následující otázky a ostatní, kteří na ně odpovídat nebudou (muţi/ţeny, manaţeři/specialisté...),



alternativní,



výčtové,



škálové.

Tabulka 2: Škála důleţitosti moţných odpovědí (zdroj Projekt 0380)20

3.2.3 Po sběru dat následuje vyhodnocení dotazníku 

editace, logická kontrola dotazníků, výběru, kvót,



kódování dotazníků,



zpracování dotazníků, analýza,



výstup.

Aby byla další práce s dotazníkem efektivní, provádí zadavatel dotazníku v případě potřeby interview s jednotlivými respondenty, na kterých si dovyjasní odpovědi, které nejsou jednoznačné, nezodpovězené nebo které si vyţadují další upřesnění pro lepší pochopení. Výsledky dotazníků jsou pak implementovány do frameworku.

20

http://www.inovace-dmt.fs.cvut.cz/index.php

31

3.2.4 Dotazník ADASTRA21 Níţe uvádím dotazník, jehoţ autorem je firma Adastra a který je postaven pro zjišťování údajů podle frameworku, jeţ představila Adastra ve svém příspěvku v rámci konference Business Briefing „Data Governance“ dne 23.5.2008 v hotelu Corinthia Towers v Praze (framework byl jiţ zmiňován v kapitole s názvem Moţné přístupy k řešení datové kvality v organizaci):

HODNOTÍCÍ DOTAZNÍK Data Governance Oddělení

Dotazované osoby

Vyplnil

Datum

Prosíme při vyplnění dotazníku vždy odpovídejte z pozice organizační jednotky, kterou zastupujete, nikoliv z celkové pozice organizace, pokud otázka přímo nesměřuje jinak. Smyslem tohoto dotazníku je poskytnout základní informace o stavu, principech a vnímání komponent programu Data Governance jednotlivými odděleními banky pro potřeby zhodnocení aktuálního stavu programu. Otázky jsou rozděleny do tématických okruhů odpovídajících struktuře programu Data Governance.

Obrázek 12: Struktura programu Data Governance (zdroj Adastra)21

21

ADASTRA: Data Governance, konference Business Briefing, 23.5.2008 hotel Corinthia Towers, Praha

32

Strategie Strategie pro datovou kvalitu Jakou hodnotu pro vás mají vaše data? Je explicitně vyčíslená či pro Vás vyčíslitelná? Máte vyčíslenu hodnotu kvality / nekvality dat? Věnujete datům takovou pozornost, jakou si zasluhují vzhledem ke své hodnotě? (Uveďte prosím konkrétní příklady a čísla, pokud je to moţné) Jaká konkrétní opatření děláte pro udrţení či zvýšení hodnoty dat? (Vyjmenujte konkrétní příklady či projekty, které jste v tomto směru realizovali.) Máte pocit, ţe vaše data jsou dostatečně kvalitní? Ano Ne Máte formálně definovanou strategii pro řízení datové kvality? Ano Ne Kdo je zodpovědný za správu (formulaci, aktualizaci) této strategie? Kdo je zodpovědný za její dodrţování? (Jmenujte konkrétní osoby a jejich funkce)

33

Strategie pro metadata Jaká konkrétní opatření děláte pro sdílení významu dat (data o datech metadata)? (Publikované popisy reportů, sdílený slovník business pojmů apod.)

Jaký vnímáte přínos sdíleného významu dat? Máte pocit, ţe sdílení významu dat a shoda tohoto významu napříč firmou je dostatečná? (Jsou všichni dostatečně seznámeni s významem dat / reportů a je toto porozumění shodné pro všechny zúčastněné osoby?)

Máte formálně definovanou strategii pro řízení metadat? Ano Ne Kdo je zodpovědný za správu (formulaci, aktualizaci) této strategie? Kdo je zodpovědný za její dodrţování? (Jmenujte konkrétní osoby a jejich funkce)

Jsou součástí strategie metadat datové standardy?

34

Politiky / přepisy / směrnice Politiky / předpisy / směrnice datové kvality Máte formálně definované politiky / předpisy / směrnice datové kvality? Na jaké úrovni? (oddělení, pobočka, divize, dceřiná společnost, firma)? Ano Ne

Máte formálně definované politiky / předpisy / směrnice pro opravy dat? Na jaké úrovni? (oddělení, pobočka, divize, dceřiná společnost, firma)? Ano Ne Pokud na úrovni vyšší, neţ vaše organizační jednotka, do jaké míry jsou politiky / předpisy / směrnice / metodiky vaší organizační jednotky shodné s dokumenty nadřízenými?

O jaké politiky / předpisy / směrnice / metodiky datové kvality se v případě vaší organizační jednotky jedná? (Vyjmenujte prosím konkrétní dokumenty) Jakým způsobem jsou zpřístupněny / sdíleny / komunikovány? (Komunikační matice, společný portál, oběţník, školení apod.) Jak je zajištěno jejich dodrţování? Kdo je zodpovědný za jejich dodrţování? (Vyjmenujte konkrétní osoby a jejich funkce) Kdo je zodpovědný za správu politik / předpisů / směrnic (formulaci, aktualizaci)? (Vyjmenujte konkrétní osoby a jejich funkce) Co je hnacím motorem změn a jak často se politiky / předpisy / směrnice mění? (Jaké jsou hlavní důvody změny, kdo je iniciuje, kdo se na formulaci změn podílí?)

35

Politiky / předpisy / směrnice metadat Máte formálně definované politiky / předpisy / směrnice metadat? Na jaké úrovni? (oddělení, pobočka, divize, dceřiná společnost, firma)? Ano Ne Pokud na úrovni vyšší, neţ vaše organizační jednotka, do jaké míry jsou politiky / předpisy / směrnice / metodiky vaší organizační jednotky shodná dokumenty nadřízenými? O jaké politiky / předpisy / směrnice / metodiky datové kvality se v případě vaší organizační jednotky jedná? (Vyjmenujte prosím konkrétní dokumenty) Jakým způsobem jsou zpřístupněny / sdíleny / komunikovány? (Komunikační matice, společný portál, oběţník, školení apod.) Jak je zajištěno jejich dodrţování? Kdo je zodpovědný za jejich dodrţování? (Vyjmenujte konkrétní osoby a jejich funkce, případně postup při nedodrţování.) Kdo je zodpovědný za správu politik / předpisů / směrnic (formulaci, aktualizaci)? (Vyjmenujte konkrétní osoby a jejich funkce) Co je hnacím motorem změn a jak často se politiky / předpisy / směrnice mění? (Jaké jsou hlavní důvody změny, kdo je iniciuje, kdo se na formulaci změn podílí?) Máte formálně definovány datové standardy a strategii jejich rozvoje? Ano Ne Na jaké úrovni jsou datové standardy definovány? (Uveďte organizační úroveň) Jak je zajištěno jejich dodrţování: Kdo je zodpovědný za její dodrţování? Do jaké míry jsou pro vás datové standardy přínosné a v čem vás omezují?

36

Organizace a procesy Organizace a procesy datové kvality Máte zavedené role spojené s řízením datové kvality? Ano, částečně Ne Jsou tyto formálně popsány a popis zveřejněn / odsouhlasen? Ano Ne Jsou role naplněny a funkční? Ano Ne Pokud ne, kde jsou problémy a jaké mohou mít příčiny?

Kolik FTE je věnováno těmto rolím? Jaký je průměrný poměr úvazku / aktivit souvisejících s řízením datové kvality a ostatními činnostmi ve vaší organizační jednotce? Jaké jsou náklady na řízení datové kvality spojené s rolemi/FTE? (Uveďte prosím konkrétní hodnoty)

Jakým způsobem hodnotíte úspěšnost pracovníků v těchto rolích?

Jaké máte procesy řízení datové kvality? (Prosím, popište procesy a zapojené role)

Jsou tyto procesy funkční? Ano Ne Pokud ne, kde jsou problémy a jaké mohou mít příčiny?

Jakým způsobem hodnotíte úspěšnost procesů řízení datové kvality?

37

Organizace a procesy metadat Máte zavedené role spojené se správou metadat? Ano Ne Jsou tyto formálně popsány a popis zveřejněn / odsouhlasen? Ano Ne Jsou role naplněny a funkční? Ano Ne Pokud ne, kde jsou problémy a jaké mohou mít příčiny?

Kolik FTE je věnováno této roli? Jaký je průměrný poměr úvazku / aktivit souvisejících se správou metadat a ostatními činnostmi ve vaší organizační jednotce? Jaké jsou náklady správu metadat spojené s rolemi/FTE? (Uveďte prosím konkrétní hodnoty)

Jakým způsobem hodnotíte úspěšnost pracovníků v těchto rolích?

Jaké máte procesy správy metadat? (prosím, popište proces, zapojené role, výčet procesů a vstupy / výstupy procesů)

Jsou tyto procesy funkční? Ano Ne Pokud ne, kde jsou problémy a jaké mohou mít příčiny?

Jakým způsobem hodnotíte úspěšnost těchto procesů? (prosím uveďte způsob hodnocení a použité metriky / KPI)

38

Procesy sdílení dat Je formálně popsán proces sdílení informací a dat? Kdo je za popis zodpovědný a jakým způsobem je vyţadováno/kontrolováno formální naplnění? (Je popsána výměna a poskytování reportů mezi uţivateli a odděleními) Ano Ne

Je formálně popsáno vlastnictví dat? Kdo je za definici zodpovědný?

Víte nebo rozumíte tomu, jakým způsobem jsou získávány či vytvářeny informace, které dostáváte? Jsou pro vás spolehlivé a důvěryhodné?

Sdílíte definice informací (reportů) s ostatními odděleními? Je vaše chápání informací shodné s ostatními odděleními? (Např. definice zákazníka, popis reportů apod.) Ano Ne

Víte, kdo je zodpovědný za kvalitu dat, se kterými pracujete? Jak je jeho zodpovědnost ověřována?

39

Metriky, KPI Metriky, KPI datové kvality Jaké jsou úkoly vašeho oddělení? Jakým způsobem je měřeno jejich naplňování? Máte definovány KPI pro plnění vašich úkolů? Je v úkolech vašeho oddělení zahrnuta kvalita dat? Jakým způsobem hodnotíte kvalitu dat? Máte definovány KPI pro datovou kvalitu? Mají KPI pozitivní efekt na kvalitu dat?

Máte k dispozici nezbytné informace pro plnění vašich úkolů a KPI souvisejících s datovou kvalitou? Jsou tyto informace úplné, správné, konzistentní, včasné a dostupné?

Co se stane, pokud KPI nejsou splněny?

Metriky, KPI metadat Je v úkolech vašeho oddělení zahrnut popis dat (vytváření metadat)? Jakým způsobem hodnotíte existenci / korektnost metadat? Máte definovány KPI pro správu metadat? Mají KPI pozitivní efekt na kvalitu metadat?

Máte k dispozici nezbytné informace pro plnění vašich úkolů a KPI souvisejících se správou metadat? Jsou tyto informace úplné, správné, konzistentní, včasné a dostupné?

Co se stane, pokud KPI nejsou splněny?

40

Podpůrné nástroje Máte implementován nástroj pro kontrolu/zlepšování kvality dat? Jaký nástroj? Na jaké úrovni? Jak plní svůj účel? (Uveďte aplikaci, procedury či systémy, které souvisí s datovou kvalitou) Ano Ne Pokud ano, kdo rozhoduje o jeho implementaci/aktualizaci? Jakými pravidly se implementace řídí, kdo určuje klíčové poţadavky na funkcionalitu? Máte implementován nástroj pro vytváření, sdílení a uchovávání metadat? Jaký nástroj? Na jaké úrovni? Jak plní svůj účel? (Uveďte, jaký je rozsah uvedeného nástroje v rámci organizační struktury) Ano Ne Pokud ano, kdo rozhoduje o jeho implementaci/aktualizaci? Jakými pravidly se implementace řídí, kdo určuje klíčové poţadavky na funkcionalitu? Umoţňují implementované nástroje tvorbu a distribuci reportů (o datové kvalitě a metadatech)? Máte k dispozici nástroj na podporu workflow spojeného s řízením datové kvality? Jaký nástroj? Na jaké úrovni? Jak plní svůj účel? Ano Ne Pokud ano, kdo rozhoduje o jeho implementaci/aktualizaci? Jakými pravidly se implementace řídí, kdo určuje klíčové poţadavky na funkcionalitu? Máte k dispozici nástroj na podporu workflow řízení metadat spojeného se změnovým řízením systémů? Jaký nástroj? Na jaké úrovni? Jak plní svůj účel? Ano Ne Pokud ano, kdo rozhoduje o jeho implementaci/aktualizaci? Jakými pravidly se implementace řídí, kdo určuje klíčové poţadavky na funkcionalitu? Jaké ostatní formální nástroje pouţíváte pro podporu dané oblasti?

Další poznámky:

41

3.2.5 Dotazník pouţitý pro konkrétní zjišťování v bance22 Dotazník je k dispozici, ale konkrétní data zde z důvodu povinnosti zachovat bankovní tajemství uvádět nebudu, pouze vybraná celková obecná zjištění pro účely této práce. Dotazník funguje jako makro v prostředí MS Excel23 v souboru XLS. Na úvodním listu jsou popsány pokyny pro vyplnění a případné nastavení MS Excel tak, aby makro bylo funkční, dále je zde uvedena tabulka oblastí a zodpovědných osob, které za jednotlivé oblasti mají dotazník vyplnit. V průběhu vyplňování dotazníku můţe uţivatel soubor libovolněkrát uloţit. Po vyplnění celého dotazníku odesílá uţivatel dotazník v určeném termínu na určenou emailovou adresu. Tato forma dotazníku umoţňuje získaná data databázově kategorizovat a jednodušeji třídit přímo do připraveného frameworku. Celá fáze vyhodnocování poţadavků je pak rychlejší a komfortnější.

Obrázek 13: Dotazník (str. 1)

22 23

Konkrétní výstup z první etapy řešení datové kvality v bance; vlastní zdroj Microsoft® Office Excel 2003 SP3

42

Obrázek 14: Dotazník – pokračování (str. 2)

Obrázek 15: Dotazník – pokračování (str. 3)

43

Obrázek 16: Dotazník – pokračování (str. 4)

Obrázek 17: Dotazník – pokračování (str. 5)

44

3.2.6 Implementace výsledků dotazníkového šetření do frameworku Implementace výsledků dotazníkového šetření do frameworku je moţná aţ ve chvíli, kdy jsou s dotazovanými povyjasněny všechny jejich připomínky tak, aby jim porozuměl tazatel a vyjadřovaly záměr sdělení, které chtěl dotazovaný vyjádřit. V nejjednodušší formě pak výsledek můţe vypadat jako níţe v tabulce. Pro podrobnější členění by tabulka měla obsahovat zdroj nebo systém, kterého se poţadavek týká, bliţší popis problému a stručně popsaný jejich vliv na chod banky z hlediska obchodních procesů, nákladů či potencionálních hrozeb.

POŢADAVEK/ZJIŠTĚNÍ

DIMENZE FRAMEWORKU

DATOVÁ ARCHITEKTURA DATOVÁ Poţadavek na vytvoření pozice „architekt korporátních obchodních procesů“ ARCHITEKTURA Není definována ţádná role, která by byla odpovědná za provádění analýzy dopadu DATOVÁ nových změn napříč zdrojové systémy ARCHITEKTURA Na úrovni jednotlivých zdrojových systémů nejsou definovány ţádné role pro zajištění DATA kvality dat GOVERNANCE Provádění oprav dat v datawarehouse se nedaří zpětně promítnout do zdrojových ÚTVAR DATOVÉ systémů ARCHITEKTURY DATA Odpovědnost za údaje – nejsou definováni vlastníci údajů GOVERNANCE ŠKOLENÍ DATOVÉ Není stejná znalost zaměstnanců o vlastnostech dat KVALITY STATICKÁ Není vymezena odpovědnost za soulad statických dat a jednotné metodiky DATA DATOVÁ Není stanoven jednotný koncept popisu procesů ARCHITEKTURA Podnikové procesy jsou popsány nedostatečně a bez znalosti o tom, které data a které DATA kroky pouţívají procesy GOVERNANCE Neexistuje ţádné závazné rozhodnutí uvést údaje o pouţívané aplikaci, vkládání údajů DATOVÁ nebo omezení pro vkládání údajů při popisu procesů ARCHITEKTURA Poţadavek na správu klientských dat na jednom místě (CRM) pro všechny typy DATOVÁ klientů ARCHITEKTURA DATOVÁ Poţadavek na řešení duplicitních vstupů klientských dat do více aplikací ARCHITEKTURA Není efektivní proces aktualizace statických dat převzatých z externích zdrojů v rámci STATICKÁ celé společnosti DATA ÚTVAR DATOVÉ Proces řízení změn není nastaven optimálně pro nové typy poţadavků ARCHITEKTURY MAPOVÁNÍ A NÁVRH OPRAVNÝCH Ţádný proces pro řízení datových toků PROCESŮ Poţadavek na vytvoření pozice „architekt korporátního datového modelu“

45

Není stanoven proces pro správu a implementaci datových standardů Není definován proces pro případ porušení nebo porušení regulace při vyuţívání technologických standardů

Komplikovaná pravidla, zásady a postupy pro práci s aplikacemi na pobočkách

Neexistuje jednotný postup pro opravy chybných dat vytvořených jinou pobočkou Neexistuje ţádný proces měření kvality dat Neexistuje ţádný postup pro provádění segmentace zákazníků pro potřeby GPM Poţadavek implementace interního systému monitorování DQ a řešení problémů z ní vyplývajících Poţadavek spustit pravidelné reporty o datové kvalitě Zajištění správnosti obchodních údajů ze zdrojových systémů - automatické reporty pro datawarehouse Audit procesu oprav (kdo, kdy, co hodnotu, jaké hodnoty)

Opravné procesy chybných dat odmítnutých systémem CCB nejsou popsány Neexistuje ţádné centrální úloţiště metadat, které poskytují dostatečné informace o informačním systému banky Neexistuje firemní datový model Ukládání statických dat z centrální správy Není jasná definice struktury adresy platné pro ČR Poţadavek na zavedení a udrţování ER diagramů pro zdrojové systémy Seznam aplikací umístěných na intranetu neposkytuje poţadované informace Problémy s jednotnou definicí klientských entit v jednotlivých zdrojových systémech Chybějící metadata Není jednotná definice atributů, které definují klienta ID, IČ, RČ) Chybějící popisy datových toků pro datawarehouse

DATOVÁ ARCHITEKTURA AUDIT DAT MAPOVÁNÍ A NÁVRH OPRAVNÝCH PROCESŮ MAPOVÁNÍ A NÁVRH OPRAVNÝCH PROCESŮ MĚŘENÍ DATOVÉ KVALITY DATOVÁ ARCHITEKTURA KONCEPT DATOVÉ KVALITY MĚŘENÍ DATOVÉ KVALITY MĚŘENÍ DATOVÉ KVALITY ČIŠTĚNÍ DAT MAPOVÁNÍ A NÁVRH OPRAVNÝCH PROCESŮ DATOVÁ ARCHITEKTURA DATOVÁ ARCHITEKTURA STATICKÁ DATA DATOVÁ ARCHITEKTURA DATOVÁ ARCHITEKTURA DATOVÁ ARCHITEKTURA ČIŠTĚNÍ DAT DATOVÁ ARCHITEKTURA DATOVÁ ARCHITEKTURA ANALÝZA DATOVÝCH EXTRAKTŮ

Tabulka 3: Sběr poţadavků pomocí dotazníku z DQA (zdroj vlastní) Zde jsem uvedl pouze část analyzovaných problémů a poţadavků, které se pomocí dotazníku shromáţdily. Celkem bylo shromáţděno a v rámci konceptu datové kvality

46

vyhodnoceno 113 problémů či poţadavků, které byly roztříděny do jednotlivých dimenzí pouţitého frameworku.

4. Vyhodnocování dopadů nekvality v datech na samotný předmět podnikání banky 4.1 Objektivní metoda nebo potenciál zlepšení? Orientace banky v jejím podnikání je dána její strategií, vizí, posláním a misí. Nicméně tvorba přidané hodnoty pro akcionáře, tedy tvorba zisku, k ní neoddělitelně patří. Nekvalita v datech můţe významným způsobem ovlivnit nákladovou stránku výsledovky a bezprostředně tak ovlivnit hospodářský výsledek banky. Nekvalitní informace významným způsobem zatěţují všechny společnosti, banky nevyjímaje. Náklady, které z důvodu nekvalitních dat společnostem celosvětově vznikají, tvoří podle odhadu 15 – 25 procent24 jejich celkových trţeb. To obrovské číslo, které není nekvalifikovaným odhadem, poukazuje na velké rezervy a vysoký potenciál, který v sobě datová kvalita skrývá. Z důvodu

zajištění

lepší

trţní

pozice

a

s tím

souvisejícím

zvýšením

konkurenceschopnosti, pro potřeby vyšší efektivity procesů v obchodě a v neposlední řadě i pro kvalitnější komunikaci s klienty je důleţité mít vysokou kvalitu dat, které tyto bankovní procesy pro svou činnost vyuţívají. Sledování nákladů na nekvalitu je objektivní metoda monitoringu datové kvality v bance. Zlepšování datové kvality a jeho řízení je postaveno na stejných postulátech, jako běţný quality management. Jednak je to o změnách v bance samotné a dále také je to o investicích v jednotlivých druzích finančního modelu nákladů na datovou nekvalitu: preventivní náklady - jsou náklady související s investicemi do různých preventivních aktivit, jako jsou školení a přeškolování, školení pracovníků v oblasti datové kvality, náklady související s plánováním inspekce kvality dat, reporting kvality; konkrétně pro řešenou banku: o náklady na vývoj a implementaci datových standardů, 24

ENGLISH, Larry: Improving data warehouse and business information quality, JWS, 1999

47

o náklady na úpravu metodických pokynů pro jednotný zápis informací o klientovi, o náklady na školení datové kvality, o náklady na implementaci řešení pro validaci adres proti číselníkům České pošty, inspekční náklady - souvisí s plánováním pravidelných měření kvality dat, čili s inspekcí existujících dat, konkrétně pro řešenou banku: o náklady na pravidelné měření jednotlivých metrik kvality v datovém skladu, o náklady na analýzu chyb obdrţených od externích systémů, náklady na chybně fungující procesy – jsou náklady, které souvisejí s důsledky a dopady nekvalitních dat na podnikání společnosti a jedná se o nevratně vynaloţené finanční náklady, které byly utraceny zbytečně; konkrétně pro řešenou banku: o manuální dočišťování dat v rámci KPI (pojem KPI blíţe vysvětlen v kapitole 5), o náklady na řešení podání a stíţností klientů, souvisejících s nesprávnou adresou bydliště, o náklady na nedoručitelné výpisy z účtů, o náklady na nedoručitelné platební a kreditní karty, o náklady související s opravami chyb odhalených v CBCB (Czech banking credit bureau). Následující řádky se věnují monitoringu nákladů s chybně fungujícími procesy v důsledku datové nekvality. Pro přesné vyčíslení nákladů do ekonomiky banky je stanoven základní model pro náklady nekvality, který vede banku ke kontinuálnímu a pravidelnému monitoringu těchto nákladů. Při budování modelu pro náklady nekvality je vycházeno ze základních principů: kaţdý defekt má svou příčinu vzniku, kaţdou příčinu je moţné odstranit prevencí, prevence vţdy vychází levněji.

48

Obrázek 18: Nákladový model a doporučené trendy (zdroj TietoEnator)25 Model NN je postaven tak, aby jej bylo moţné nadále rozvíjet a zjemňovat ve vertikální struktuře na detailnější pohledy a výpočty nákladů. Protoţe existuje vzájemný vztah mezi počtem chyb a prevencí, pak investicí do prevence eliminujeme vznik nových defektů a zároveň tak sniţujeme náklady na opravu selhání. Navyšování nákladů při inspekci se objeví v případě, kdy by banky neinvestovala do prevence a tudíţ by musela zavést robustní inspekci. Naopak sníţení nákladů na inspekci můţeme dosáhnout tak, ţe lze prodlouţit intervaly mezi inspekcemi v případě implementace preventivních opatření. Mezi druhy nákladů na nekvalitu je pak moţné naleznout stav, při kterém: sniţujeme náklady na datovou nekvalitu ve správném tempu, do prevence investujeme přiměřené náklady, a do inspekce pak vkládáme náklady pouze nezbytně nutné.

Obrázek 19: Mapování modelu pro náklady nekvality na jednotlivé kategorie nákladů z frameworku (zdroj vlastní) 25

KUČERA, Milan; NOVOTNÝ, Marek: Kvalita dat. TietoEnator, slide z přednášky 2006

49

Konkrétní spočtené náklady na datovou nekvalitu podle tohoto modelu se pohybují v řádu desítek milionů a s ohledem na bankovní tajemství zde záměrně nebudou vyčísleny. Nicméně ukazatel návratnosti investic ROI pro investice do datové kvality v 5letém horizontu činí plných 232%(!).

4.2 Analýza nákladů na nekvalitu Na základě provedených interwiev s odpovědnými pracovníky banky v oblastech procesů, na které se nákladový model soustředí pak vznikl nákladový v oblasti pro své fungování potřebují klientská data

Obrázek 20: Model pro náklady nekvality (zdroj vlastní) Takto stanovený model je samozřejmě v hrubém členění. Příslušné náklady je nutno rozklíčovat do detailů tak, aby bylo moţno reálné náklady počítat, vykazovat a sledovat. Sledování a vyhodnocování je vhodné provádět na měsíční bázi. Nevratné finanční náklady se jemněji rozčlení na: náklady související se zasíláním výpisů, související s marketingovými kampaněmi, cena poštovného, náklady související se zasíláním doporučené pošty v členění podle: o počtu odeslaných materiálů, o vrácených z důvodu nepřijato, 50

o vrácených z důvodu nevyzvednuto, o vrácených z důvodu odstěhoval se, o vrácených z důvodu na uvedené adrese nebydlí, o vrácených z důvodu nedostatečné adresy, o vrácených z jiného ověřeného důvodu, o vrácených z jiného neověřeného důvodu. Pro sledování nákladů modelu pak musí být rozhodující, zda náklady na získávání těchto dat nebudou nákladů tvořit významné procento celkových nákladů nekvality. Sniţování nákladů na nekvalitu musí být prioritou pro zdravý vývoj hospodaření banky. Pro veškeré aktivity v oblasti DQ pak musí být prioritní posuzování podle finančních přínosů a nákladů na jejich realizaci. Je ale důleţité zdůraznit ţe právě u konceptů nebo projektů v oblasti datové kvality je toto vyčíslování velmi obtíţné.

5. Návrhy a způsoby řešení datové nekvality v bance

Obrázek 21: Návrh DQ konceptu - procesní pohled (zdroj vlastní)

51

Pohled na koncept řešení datové kvality po procesech jsem se pokusil navrhnout ve schématu na obrázku 22. V boxu číslo 5 je uveden bod, který se týká návrhu oblastí měření v bankovních procesech. Tento bod v hrubém náčrtu rozvádím ve schématu, zachyceném na obrázku 23. Specifikum tohoto konkrétního návrhu spočívá v tom, ţe kromě datového skladu lokálního, který pouţívá banka pro svou činnost, jsou data dále přesouvána do datového skladu mateřské banky, kde jsou shromaţďována data za celou bankovní skupinu, zahrnující několik bank z několika různých zemí.

Obrázek 22: Návrh bodů pro měření datové kvality (zdroj vlastní)

5.1 Definice datových standardů Definice datových standardů slouţí pro vymezení hlavních zásad pro tvorbu, správu a uţití standardů jako doplňujícího a nutného prostředku pro dosaţení a zajištění ţádoucí kvality dat a pro efektivní uţívání informací a dat v bance pro dosahování jejích obchodních a strategických cílů. Je nutné jednoznačně specifikovat základní pojmy, které s touto oblastí souvisí, pro neměnnou terminologii dalších dokumentů, které tyto pojmy budou vyuţívat v systému vnitropodnikového řízení. Datové standardy mají za cíl zavést všeobecně respektované datové vzory, aby nedocházelo ke ztrátě významu a kvality informace způsobené uloţením do datových úloţišť v bance a jejich dalším zpracováváním. 52

Datové standardy musí být závazné pro celou banku a musí být postupně implementovány do všech zdrojových systémů banky, se kterými banky pracuje. Veškeré, zejména rozvojové a procesní aktivity musí být datovým standardům podřízeny a musí se jimi řídit. V rámci datových standardů musí být vysvětleny základní pojmy, se kterými standardy budou operovat tak, aby byly srozumitelné všem osobám, které s dokumentem standardů budou pracovat. Jedná se například o pojmy ENTITA, ATRIBUT, DATOVÝ PRVEK, INFORMAČNÍ SOUSTAVA, DATOVÁ ARCHITEKTURA (z hlediska toho, kým /kterým útvarem/ je v bance reprezentována), DATOVÁ KVALITA (dtto). Datové standardy definuji jako soubor závazných, interně stanovených pravidel v bance, pro vykonávání úkonů spojených se zpracováním, definováním, pouţitím a udrţováním obsahů datových prvků. Datové standardy se musí vytvářet podle jednoznačně daného pravidla, které určuje vlastnost příslušné informace a musí platit v celé bance. Musí být vymezena odpovědnost za tvorbu věcného obsahu, za řízení tvorby a musí být dán postup, jak řešit rozpory při definici nového standardu nebo v případě, kdy prvek nevyhovuje standardu jiţ definovanému. Bude určena perioda, s jakou budou vyhlašovány nové standardy, včetně termínů, do kterých se jim musí stávající prvky přizpůsobit. Tyto termíny budou individuálně upravovány s ohledem na rychlost realizace změn ve zdrojových IT systémech banky. Všechny datové standardy budou uchovávány v Katalogu včetně celé dokumentace.

5.1.1 Pravidla uţití datových standardů V případě, ţe pro daný prvek existuje datový standard, musí být kaţdá změna směřována k jeho naplnění, při vyhlášení nového standardu je započato období jeho implementace, které je plošně dáno, ale s ohledem na individuální podmínky můţe být upraveno, IT systém, který nebude akceptovat daný datový standard, ponese po uplynutí lhůty na implementace náklady na individuální úpravy interfaců ostatních systémů pro zachování jednotné komunikace a tyto náklady budou zakalkulovány do nákladového modelu viz. kapitola 4. Dodrţování definovaných datových standardů bude měřeno vytvořenými metrikami a vyhodnocováno v rámci KPI (o metrikách a KPI více v kapitolách níţe v textu). 53

5.1.2 Prvky datových standardů Datové prvky jednoduché – základní, dále nedělitelný atribut entity (poštovní směrovací číslo), datové prvky sloţené – sloţené z více prvků jednoduchých a dávajících logickou hodnotu (daňové identifikační číslo), datové prvky číselníkové – jednoduché datové prvky, které jsou pevně dány v číselníku, jedná se o unifikované hodnoty (telefon M - mobilní, P pevná domů, Z - pevná do zaměstnání), entity – dány seznamy jednoduchých, sloţených i číselníkových prvků a jejich vzájemnými vazbami, etalony číselníků – datové prvky číselníků, které jsou dány externími číselníky (NACE kód, ISO kód země).

5.1.3 Role v datových standardech Vlastník – odpovídá za prosazování datových standardů a plánování standardizace (přizpůsobování se datovým standardům), metodik datových standardů – vyhlašuje datové standardy a uděluje výjimky z jejich naplňování a dodrţování, správce – v podstatě jde o datového architekta, který má zodpovědnost za zpracování návrhu standardu, jeho zveřejnění a administraci Katalogu datových standardů; kontroluje dodrţování datových standardů, analytik – odpovídá za věcné provádění kontrol dodrţování standardů, správce etalonu – oddělení, zabývající se správou statických dat v bance, zejména číselníků, metodik – odpovídá za věcnou definici datového standardu a za jeho obsahovou stránku, další role – mohou být definovány v závislosti na potřebách banky.

54

5.1.4 Obecná část definice standardu Tato část můţe být ve formě textové tabulky a uloţena je ve speciálně vyčleněné repository datového skladu, stejně jako veškeré datové standardy: identifikátor - jednotné označení pro datové prvky datových standardů, název datového standardu, číslo verze, kategorie datového prvku, definice, komentář, správce, metodik, platnost od, platnost do.

5.2 Školení datové kvality V úvodu jsou vyjmenovány všechny útvary banky, do jejichţ činnosti projekt datová kvalita zasáhne, pracovníci, od nichţ se budou očekávat nějaké výstupy nebo činnosti. Pracovníci těchto útvarů jsou pozvání na školení datové kvality, kde jsou seznámeni s prezentací, která shrnuje současný stav, východiska a způsoby, kterými se kvalita dat bude řešit. Školení je koncipováno jako povinné. Prezentace bude mít toto členění: motivace - proč se zabývat datovou kvalitou, příklady, úvod do řízení datové kvality, stručně seznámení s metodologií, kterou se koncept řídí, vysvětlení významu metadat a datových definic pro datovou kvalitu a jejich další vyuţití, analýza kvality dat, metriky, přístupy, poţadavky na systém měření, nástroje, vyhodnocování nákladů na nekvalitní informace, čištění dat – procesy a technické prostředky, 55

prevence vzniku nekvality, online čištění dat, kvalita dat a zlepšování procesů, prostředí informační kvality v bance, koncept datové kvality – dosavadní zjištění, závěry a navrhovaná doporučení, vize datové kvality v bance do budoucnosti. V podstatě se jedná o zestručněný výtah z materiálu, který obsahuje tato práce. Do velkého detailu není vhodné zabíhat, účastníci školení si musí odnést informaci, o čem datová kvalita v bance je, jaká bude jejich role v procesu jejího zlepšování a kam se celý proces bude ubíhat v dalších etapách.

5.3 Útvar datové kvality Ve strukturách banky bude v rámci divize IT organizace vytvořeno nové oddělení s názvem Datová kvalita. Role oddělení a šíře odpovědnosti v těchto rolích je přiblíţena v následujícím obrázku.

Obrázek 23: Schéma odpovědnosti DQ oddělení (zdroj vlastní)

56

Definice rozsahu odpovědnosti je plně v kompetenci managementu banky, jde pouze o rámcový návrh. Stejně jako v případě ukázky vztahů oddělení k ostatním útvarům banky, kde jsou naznačeny zodpovědnosti směrem „k“ i směrem „od“ DQ oddělení. Přesná specifikace včetně návrhu počtu FTE by pak byla v detailní fázi materiálu pro management board banky.

Obrázek 24: DQ oddělení – vztahy k ostatním útvarům banky (zdroj vlastní)

5.4 On-line prevence Pod pojmem on-line prevence je si představme robustní nástroj, který provádí čištění dat v reálném čase a provádí jej přímo tam, kde chyby v uţším významu slova vznikají, tedy tam, kde data vstupují do databází. Tím uţším významem slova myslím to, ţe ani tento nástroj nemůţe ovlivnit to, ţe operátor natypuje do databáze data, která sice projdou sítem on-line prevenčního nástroje, ale ve skutečnosti jsou chybná. Takţe operátor správně opíše a natypuje do zdrojového systému chybný údaj. Například klient v bance předloţí doklad, ve kterém je chyba, pracovník banky tuto chybu neodhalí a chybu tak zanese do systému a pracuje se s ní jako se správným údajem. Pro nasazení on-line preventivního nástroje musí být v bance vytvořen základní předpoklad a sice jednotný frontend zdrojových systémů pro zadávání a pořizování

57

klientských dat. To v bance v tuto chvíli realizováno není, kaţdý zdrojový systém má svůj vlastní frontend a implementace on-line preventivního nástroje do jednotlivých zdrojových systémů by byla ekonomicky nevýhodná. Nyní banka stojí před rozhodnutím, jaký frontend implementovat spolu s implementací jednotného core systému pro drobné a korporátní bankovnictví. Proto jen stručně popíši, kterým směrem se po úspěšné implementaci jednotného frontendu a core zdrojového systému budou aktivity banky v oblasti prevence v datové kvalitě ubírat.

5.4.1 SAS DataFlux26 Tento robustní nástroj slouţí pro komplexní řešení datové kvality od firmy SAS. On-line prevencí se zabývá část Quality jako takzvanou Real Time Integration - SAP. Nástroj je pouţitelný pro více platforem (dfPower Studio, DataFlux Integration Server, SAP, SAS, SOA, Siebel, OWB…). Systém vyuţívá rozsáhlou znalostní bázi, kterou nadále doplňuje a aktualizuje.

Obrázek 25: Metodika datové kvality SAS DataFlux (zdroj SAS)22 Jak funguje on-line prevence v praxi? Veškeré ručně pořizované vstupy jsou ihned podrobeny kontrole a podle charakteru pole jsou porovnávány se vzorovými etalony. Takţe pokud operátor zapíše do pole, které je určeno pro křestní jméno, slovo PERT,

26

SAS®; SNÍDANĚ SE SASem - Datová kvalita, elektronická prezentace 58

program zobrazí dialog a nabídne opravu na PETR. Podle nastavení můţe být systém oprav prováděn bez zobrazení dialogu a nutnosti potvrzení operátora ihned. Velice jednoduchý, vzdáleně se podobající nástroj tomuto sofistikovanému řešení je implementován např. v MS WORD jako volba Nástroje – Moţnosti automatických oprav27.

Obrázek 26: SAS DataFlux on-line korekce, fáze 1 (zdroj SAS)

27

Microsoft® Office Word 2003 SP3

59

Obrázek 27: SAS DataFlux on-line korekce, fáze 2 (zdroj SAS)

Obrázek 28: SAS DataFlux on-line korekce, fáze 3 (zdroj SAS)

60

DataFlux není jediný ve svém oboru, podobné moţnosti nabízí Ataccama, dříve Adastra Purity, Harte-Hanks Trillium Software či Hewlett Packard. Detailní rozepisování o technických vlastnostech jednotlivých řešení ale není cílem této práce.

5.5 Čištění dat Proč vlastně čistit data o klientech? Je to vůbec nutné? A není to příliš drahé? Takovéto otázky si moţná na začátku klade firma, která má velké rezervy ve vyuţívání potenciálu své klientské databáze anebo její klientská databáze je svým rozsahem malá, zpravidla provozovaná jednouţivatelsky na několika málo počítačích, případně na jednom stroji. V tom případě se vhodnou prevencí jiţ na vstupu dá zabránit vzniku „špinavých“ dat, ale ani to neplatí ve sto procentech případů. Pracovník onemocní, je na dovolené, případně změní zaměstnavatele a své know-how si vezme s sebou. Čištění dat je zejména důleţité pro oblast marketingu, obchodu a risku a regulatorního výkaznictví. To platí zejména ve velkých společnostech, které mají tisíce, statisíce či miliony zákazníků a jedná se zejména o finanční instituce. Jak lze efektivně řídit riziko, kdyţ nejsme schopni identifikovat všechny pohledávky klienta, které za ním banka a její dceřiné společnosti evidují? Špatně. Jak lze nabízet klientovi nový produkt, kdyţ na základě informací z naší databáze nejsme schopni věrohodně říci, zda klient daný produkt má či nemá? Opět špatně. A jak můţeme změnit orientaci z produktového prodeje na zákaznický, kdyţ nejsme schopni jednoznačně segmentovat klienta. Zas a znovu špatně. Čištění dat je klíčová součást procesů informační kvality28. V první řadě je zapotřebí datům porozumět. To v sobě zahrnuje profilaci dat z hlediska jejich důleţitosti pro banku (která data jsou pro banku důleţitá jsem zmiňoval v jedné z předchozích kapitol této práce). Po provedené profilaci se provede bliţší zkoumání existujících metadat tak, aby bylo dobře porozuměno logice jejich definování a na samý závěr této etapy se vydefinují sporné otázky a konkrétní případy. Po uzavření této kapitoly jiţ můţe nastat samotný proces čištění dat neboli data cleansingu. V tomto kroku známe data, která budou předmětem čištění a známe i problémy, které si s sebou nesou.

28

Konference IIR: Řízení datové kvality, ADASTRA, 20.-21.3.2007

61

5.5.1 Etapy procesu čištění dat Celý proces čištění probíhá v několika předem definovaných etapách. V prvé řadě je to parsing dat, čili syntaktická analýza dat. Data v jednotlivých atributech se rozdělí do základních, dále jiţ nedělitelných elementů, které k sobě mají určité vazby, jeţ jsou definovány a zachovány. Dále musí proběhnout korekce datových formátů; předem je stanoven jednotný formát pro datum včetně ošetření krajních extrémů. Ošetřením krajních extrémů rozumíme stav, kdy víme, ţe daná poloţka musí obsahovat datum, ale v databázi u daného záznamu ţádné datum není (buď jej nedodal zdroj nebo se díky špatnému formátu na vstupu tato informace ztratila) a atribut nesmí obsahovat prázdný prvek (NULL hodnota). Nyní záleţí na kvalitní definici metadat, podle níţ je čistící proces schopen zjistit, zda se jedná o nějaké datum v minulosti nebo naopak o datum, které nastane někdy v budoucnu; pak uţ jen stačí mít vydefinovanou podmínku, ţe např. datum v minulosti, které určitě existuje, ale v databázi není známo, bude definováno například jako 1.1.1000 a obdobně datum v budoucnosti, které není známo, bude definováno například jako 1.1.3000. Ale pozor, přípustnost pouţití krajních extrémů se můţe lišit podle pouţitého informačního systému. Problém pak nastává, kdy výstup z jednoho systému se stává vstupem do druhého systému, přičemţ druhý systém má hranice extrémů menší neţ informační systém, ze kterého data načítá a proto je nutné při načítání extrémy ošetřit vhodnou funkcí. Dále se také můţe stát, ţe tak, jak data stárnou, můţe datum označené jako 1.1.3000 jiţ značit nějakou událost, která mezitím nastala. K tomu pak slouţí příznaky, neboli flagy, které označují celý záznam jako ukončený nebo neplatný, takţe ţivý záznam s příznakem „platný“ a datem 1.1.3000 má pro proces stejnou vypovídací schopnost jako záznam s datem 1.1.3000 a příznakem „zrušený“, ale různý význam. Jednotné datové formáty musí být přiděleny všem atributům a pomocí vhodných algoritmů musí být provedena bezeztrátová jednotící konverze: malá písmena budou nahrazena velkými, bude odstraněna veškerá interpunkce, přebytečné mezery na začátku nebo na konci prvku v atributu budou vytrimovány. Pro zvláštní druhy atributů jsou stanovena zvláštní pravidla, například pro rodné číslo, které je moţno zapsat několika různými způsoby (například RR-MM-DD/XXXX, RRMMDD/XXXX, RRMMDDXXXX, DD.MM.RRRR/XXXX). Je připraven zvláštní algoritmus, který si se všemi známými stavy rodného čísla poradí a pamatuje i na situaci, kdy místo rodného čísla je v databázi zapsána jen jeho část v podobě data narození (číslo za lomítkem pak bývá nahrazeno buď 62

implicitní hodnotou nebo v rámci unifikace hodnotou, která má největší četnost v ostatních instancích, které do unifikace vstupují). Více o tomto v podkapitole s názvem K čemu ID? Poté je provedeno vyhodnocení celého datového obsahu na takto stanovených kritériích, aby bylo potvrzeno, ţe kritéria byla vydefinována kompletně, případně zda je nutné doplnit některá další či zjemnit stávající. Po dokončení předešlé fáze uţ následuje automatický proces korekce, který opraví data vyhodnocená jako chybná.

Obrázek 29: Vyčištění křestního jména Přemysl (zdroj vlastní)

Obrázek 30: Vyčištění názvu města (zdroj vlastní)

63

Proces čištění dat můţe probíhat buď: 

automatizovaně, o

dávkově – sekundární proces po načtení dat do databáze,

o

on-line – ihned přímo při načítání dat,

o

jako preventivní proces – tzv. „DQ firewall“, kde jsou definovány přípustné hodnoty dat, které se načtou – navíc tento „DQ firewall“ můţe nabízet v uţivatelském rozhraní (formuláři) správné hodnoty uţivateli,



manuálně, o

zabývá se jimi komplexně vypracovaná metodika řízení kvality dat,

o

zabývají se organizací a probíhajícími procesy v ní,

o

zahrnují kompletní Data Governance.

5.5.2 Ataccama29 Jako příklad specializovaného nástroje pro čištění dat uvádím nástroj Ataccama od společnosti Ataccama Software. Ataccama Software vznikla vyčleněním divize Purity ze společnosti Adastra v roce 2008, která do té doby prodávala tento softwarový nástroj pod názvem Adastra Purity. Tento softwarový nástroj vyuţívá specializovanou technologii pro čištění a unifikaci klientských (ale nejen těch) a adresových dat a zároveň slouţí jako nástroj pro řízení kvality dat a jako prostředek pro verifikaci kvality dat na vstupu do zdrojových systémů a v tom je jeho velká síla. Společnost Ataccama jej dodává společně s bohatou bází čistících pravidel, která vychází z dosavadní praxe při implementaci a best practises a dále včetně číselníků pro daný region, kde je implementace prováděna. Nástroj a jeho implementace je doplněna metodikou pro procesy řízení kvality dat. Důleţité je, ţe nástroj

29

ATACCAMA CORPORATION http://www.ataccama.com/

64

a metodologie Ataccama pokrývá oblasti P2, P4 a P5 z frameworku TIQM dle Larry Englishe.

Obrázek 31: Ataccama – schéma nástroje Master Data Center (zdroj Ataccama) Tvrdím, ţe jednorázové vyčištění dat lze takto realizovat jakýmkoli podobným softwarovým nástrojem, ale poté by měla následovat implementace čistících pravidel do ETL procesů datového skladu. Tato pravidla se pak v datovém skladu projeví tak, ţe v tabulce vedle sebe existují atribut s originálním načteným údajem a vedle něj pak duplikátní atribut se stejným údajem, na který uţ ale byla implementována čistící pravidla. Toto se zejména týká údajů klientských a dat s klientem bezprostředně souvisejících (údaje o bydlišti, produktech podobně).

5.6 Statická data V bance zpravidla existuje útvar, který se zabývá kontrolou a nastavováním statických dat napříč celou bankou. Tento útvar má zodpovědnost za udrţování všech druhů číselníků ve zdrojových systémech banky, ručí za jejich aktuálnost a je-li to vhodné a ţádoucí, porovnává je s dostupnými externími číselníky a provádí jejich korekci. Velmi často je součástí útvaru datové kvality.

65

5.6.1 Unifikace klientů V kapitole o čištění dat jsem popisoval jednorázové vyčištění dat. Ta pak budou slouţit k provedení unifikace klientů, pocházejících z více zdrojových systémů. Proces unifikace zajistí, ţe všechny instance jednoho klienta, pocházející z různých zdrojů, se spojí v jednu unifikovanou instanci, pod kterou budou patřit i instance zdrojové. Unifikační algoritmus musí být navrţen tak, aby postupoval po jednotlivých krocích, které zajistí, aby bylo unifikováno maximální moţné mnoţství shodných klientů, ale zároveň nebyli chybně zunifikováni zcela různí klienti. kaţdá instance ze zdrojového systému dostane jedinečný identifikátor, unifikační algoritmus nepracuje se zdrojovými daty, ale s jejich vyčištěnými duplikáty, ze všech zdrojových systémů se určí jeden, který je prioritní, podle něj se vytvoří virtuální unifikační instance, která dostane jedinečný unifikační identifikátor, zbylé instance se porovnávají podle zvoleného klíče s virtuální instancí; podle počtu shod je vytvářeno tzv. unifikační skóre a podle jeho výše se pak uskuteční/neuskuteční unifikace; v případě úspěšné unifikace obdrţí instance

vedle

vlastního

jedinečného identifikátoru

téţ unifikační

identifikátor virtuální identifikační instance, ETL proces (základní proces implementovaný do datového skladu, který slouţí k extrakci dat ze zdrojových systémů, jejich transformaci do ţádoucího tvaru a konečně k nahrání do struktur datového skladu) musí mít implementovánu funkci pro ruční split a merge zunifikovaných instancí pro případ, kdy unifikační algoritmus nezafungoval správně a buď chybně zunifikoval do sebe dva různé klienty nebo naopak vytvořil dvě různé virtuální instance, které patří ve skutečnosti jednomu a témuţ klientovi, ETL proces zásadně zachovává historii jednotlivých splitů a mergeí unifikovaných klientských instancí tak, aby bylo moţno kdykoli později dohledat změny, které na klientském záznamy nastaly. Způsobů a algoritmů unifikace existuje více, čím větší je databáze dat, podléhajících unifikaci, tím větší jsou nároky na rychlost algoritmu.

66

5.6.2 Unifikace číselníků Unifikace interních číselníků je nutná jednak pro jednotnou identifikaci produktů a sluţeb, segmentaci klientů a zejména jednotné výkaznictví. Pro tyto účely se v jednotlivých číselnících, které banka pro svou činnost pouţívá (např. číselník produktů, číselník typů klienta, číselník účelů úvěru atd.) Praktickým příkladem můţe být stav, kdy různé instance (záznamy - řádky) v daných entitách (tabulkách) mají různé názvy, ze kterých není na první pohled jasné, zda se jedná o běţný korunový účet nebo cizoměnový účet či termínovaný vklad. Unifikací v produktech tak získáme podklad pro regulatorní výkaznictví podle směrnice Basel II, ale i pro vnitřní výkaznictví produktové. Prakticky se unifikace provádí přidáním atributů do tabulek, ve kterých je unifikace ţádoucí. Jsou stanoveny zodpovědné osoby, které na základě číselníků doplňují unifikované hodnoty. Jsou navrţeny a realizovány kontroly (metriky), viz. Následující kapitola.

Obrázek 32: Unifikace druhů produktů (zdroj vlastní)

67

5.7 Metriky pro měření datové kvality Metrika je konkrétně definovaná metoda měření a definovaný rozsah měření30. Jednoduchá definice, která říká, ţe je nutno přesně vymezit, kde a co bude kontrolováno respektive měřeno a hlavně jak to bude měřeno. Pro různé způsoby měření můţe být pouţita různá metodologie, ale z hlediska sledování vývojových trendů výsledků metrik v čase se nesmí metodologie měnit. Je proto pevně stanovena. Konkrétní podobě metriky předchází sběr poţadavků na datovou kvalitu ze strany zákazníků dat. Pro potřeby projektu v bance byly zavedeny dva základní typy metrik: metriky číselníkové, metriky datové. Metriky jsou provozovány ve speciálním nástroji od dodavatele řešení datového skladu banky. Tento nástroj umoţňuje pomocí metadat definovat vztahy mezi jednotlivými atributy (v případě metrik datových) a dále umoţňuje v metadatech definovat domény přípustných hodnot nebo kombinací hodnot, proti kterým jsou kontrolovány unifikované, ale i solitérní hodnoty atributů, mající charakter číselníků (číselníkové kontroly). Funkčnost nástroje, doba jeho běhu, čas spuštění, podmínky pro spuštění, jsou řízeny ETL procesy v datovém skladu. Výsledky ukládá nástroj do připravených tabulek do vyčleněného repository. Výsledný report datové kvality je pak zpracován v prostředí MS Excel31. Výsledkem metrik jsou vţdy následující hodnoty: celkový počet prvků, počet prvků nevyhovujících definici v metadatech, objem prvků nevyhovujících definici v metadatech (pokud je relevantní), DQ level z hlediska počtu prvků, DQ level z hlediska objemu (pokud je relevantní). Pro metriky číselníkové nemá smysl uvaţovat o objemových veličinách, protoţe předmětem metrik jsou číselníky. Zde tedy příslušná hodnota buď vyhovuje 30

UČEŇ, Pavel a kol.: Metriky v informatice. Jak objektivně zajistit přínosy informačního systému. Grada Praha 31 Microsoft® Office Excel 2003 SP3

68

definované doméně přípustných hodnot nebo ne. Reportovány jsou pouze chybové hodnoty. Metriky v předem stanovených termínech a periodách kontrolují jednak přítomnost příslušné unifikované hodnoty a v druhé části porovnávají zjištěnou hodnotu s číselníkem přípustných hodnot. Kontroly nejsou schopny odhalit, zda je unifikovaná hodnota přidělena správně, pouze zda je vůbec přidělena a zda je zvolena přípustná hodnota. Pro sloţitější tabulky, kde je pro jeden záznam pouţito vícero unifikovaných atributů se pak pouţívají tzv. x-násobné kombinace (x-ples combination). To znamená, ţe kromě přípustných solitérních hodnot číselníků jsou definovány i přípustné kombinace n-tic unifikovaných hodnot.

5.8 KPI a Balanced scorecard KPI neboli klíčové výkonnostní ukazatele (key process indicators) jsou základním atributem a účinným prostředkem k motivaci zainteresovaných útvarů banky a konkrétních osob pro účast na datové kvalitě. KPI se pouţívá ve spojení s pojmem Balanced Scorecard. Jedná se o metodu řízení pracovního výkonu tak, ţe směřuje banku ke splnění vytýčených obchodních cílů. Metodu společně vyvinuli Robert S. Kaplan a David P. Norton na základě studie o výzkumu nových metod pro měření výkonnosti podniku. Poprvé byly výsledky jejich studie prezentovány oběma pány v Harvard business Review v roce 1992.32 Část metody Balanced Scorecard se dá pouţít právě pro KPI. Prostředkem pro to je řídící panel, do kterého se zanesou jednotlivé ukazatele KPI, hodnoty, jaké mají být dosaţeny a metrika, jakou se budou měřit. Musí být dát motivační bonus pro případ úplného či částečného splnění kritérií KPI včetně způsobu vyhodnocení všech KPI kritérií a případně malus pro případ nesplnění. Skutečnost se zpravidla v měsíčních intervalech průběţně vyhodnocuje a reportuje oproti plánovanému stavu. Na konci roku se provede závěrečné vyhodnocení. Splnění KPI kritérií pak musí být navázáno na realizaci bonusu pro zainteresované osoby, organizační sloţky banky.

32

http://en.wikipedia.org/wiki/Balanced_scorecard

69

Obrázek 33: Řídící panel Balanced Scorecard (zdroj Učeň)33

5.9 Měření datové kvality Nastavené metriky, jejich metadata a oblasti měření pak umoţňují na měsíční bázi provádět příslušná měření a jejich vyhodnocování včetně tvorby manaţerské prezentace Datové kvality, která v granularitě, která odpovídá vyššímu managementu banky, informuje o vývoji v kvalitě měřených dat. Celý manaţerský report se pak rozpadá do dílčích reportů, kde jsou kromě absolutních hodnot i trendy a zdůvodnění případného poklesu nebo naopak skokového nárůstu datové kvality. Report se záměrně pozměněnými údaji přikládám k práci jako ukázku jednoho z dílčích výstupů realizovaného konceptu datové kvality v bance:

33

UČEŇ, Pavel a kol.: Metriky v informatice. Jak objektivně zajistit přínosy informačního systému. Grada Praha, 2001

70

Obrázek 34: Měření datové kvality, část 1. (zdroj vlastní)

Obrázek 35: Měření datové kvality, část 2. (zdroj vlastní)

Obrázek 36: Měření datové kvality, část 3. (zdroj vlastní) 71

Obrázek 37: Měření datové kvality, část 4. (zdroj vlastní)

72

Závěr a doporučení Slovní spojení datová kvalita je pro mnohé nezasvěcené něčím neuchopitelným, ale aniţ by to věděli, díky kvalitě dat můţe existovat a fungovat řada běţných zařízení, se kterými se dnes a denně setkávají a na kterých jsou do větší či menší míry závislí. V této práci jsem se snaţil skloubit obecné znalosti o této problematice s know-how firem, které se tuto oblastí zabývají nikoli pouze po teoretické stránce, ale naopak teoretické poznatky aplikují do praxe a navzájem je konfrontují. A vedle toho jsem postavil konkrétní problémy datové kvality v bance, kde jsem se přímo aktivně účastnil projektu implementace datové kvality. Osobně jsem tedy mohl teorii a praxi navzájem propojit a popsat řešení. Koncept řešení datové kvality s sebou ale přináší poměrně značné náklady. Zkrocení těchto nákladů velmi dobře popisuje Steve McConnell ve své knize Odhadování softwarových projektů34. Dřív či později se pak projekt datové kvality dostane do určité etapy, kdy se sponzor projektu ptá: jakou datovou kvalitu dosahujeme v současnosti a kolik nás to ještě bude stát, aby byla vyšší? A zjišťuje, ţe vztah mezi náklady na kvalitu a velikostí kvality není lineární, ale také není obecně platný viz. zjištění v kapitole 4. Softwarové firmy se z logiky věci snaţí vnutit zákazníkovi kompletní řešení včetně všech návazných kroků a dalšího servisu, ale zákazník by neměl tomuto trendu podlehnout. Implementace SW nástroje na kontrolu dat na vstupu můţe být nahrazena sofistikovanějším frontendem zdrojových systémů bank. Nástroj na čištění dat zas propracovanějšími ETL procesy uvnitř datového skladu. Proškolení, pravidelné měření datové kvality a správné nastavení KPI pak vede k tomu, ţe vliv lidského faktoru je eliminován na maximální moţnou úroveň. Data nikdy nebudou stoprocentní. Ale jejich kvalita vţdy musí být na takové úrovni, aby neohroţovala a nezasahovala do hlavního předmětu podnikání banky. Proces zlepšování datové kvality v bance musí být procesem trvalým a kontinuálním.

34

MCCONNELL, Steve. Odhadování softwarových projektů. Computer Press, Brno, 2006

73

Seznam pouţité literatury ATACCAMA CORPORATION [online]. [cit. 09.03.2010] Dostupný z WWW . BALANCED SCORECARD [online]. [cit. 09.03.2010] Dostupný z WWW . BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vydání. Grada, Praha, 2005. ISBN 80-247-1075-7. ČSSI: ČESKÁ SPOLEČNOST PRO SYSTÉMOVOU INTEGRACI [online]. [cit. 09.03.2010] Dostupný z WWW . ENGLISH, Larry: Improving data warehouse and business information quality, John Willey & Sons, 1999. ISBN 0-471-25383-9. HARTE-HANKS TRILLIUM SOFTWARE [online]. [cit.09.03.2010] Dostupný z WWW . INFORMATICA The Data Integration Copany [online]. [cit.09.03.2010] Dostupný z WWW . KALVODA, Jaroslav:Information duality return on investment. PROFINIT, slide z pracovní snídaně 24.11.2005. KUČERA, Milan; NOVOTNÝ, Marek: Kvalita dat. TietoEnator, slide z přednášky 2006. LOSHIN, David: Business Inteligence THE SAVVY MANAGER´S GUIDE, Morgan Kaufmann Publisher, 2003. ISBN 1-55860-916-4. MCCONNELL, Steve. Odhadování softwarových projektů. 1. vydání. Computer Press, Brno, 2006. ISBN 80-251-1240-3. MINIBERGER, Bohumil: Modelování a návrh datových skladů. Slide z přednášky na BIVŠ ke stejnojmennému předmětu 2010. 74

NOVOTNÝ, Ota; POUR, Jan; SLÁNSKÝ, David. Business Inteligence Jak využít bohatství ve vašich datech. 1. vydání. Grada, Praha, 2005. ISBN 80-247-1094-3. PROJEKT 0380 [online]. [cit.09.03.2010] Dostupný z WWW REVENDA, Zbyněk; MANDEL, Martin; KODERA, Jan; MUSÍLEK, Petr; DVOŘÁK, Petr; BRADA, Jaroslav. Peněžní ekonomie a bankovnictví. 2. vydání. Management Press, Praha, 1997. ISBN 80-85943-49-2. SAS® Produkty a řešení / SAS® DATA QUALITY SOLUTION Řešení pro kvalitu dat [online]. [cit. 09.03.2010] Dostupný z WWW . SAS®; SNÍDANĚ SE SASem - Datová kvalita,; elektronická prezentace, Praha 17.2.2009. SBORNÍK PŘEDNÁŠEK: DATA SYMPOSIUM 2007, hotel Corinthia Towers v Praze, 16.10.2007. SBORNÍK PŘEDNÁŠEK: DATA SYMPOSIUM 2008, Národní dům na Smíchově, 12.11.2008. SCHEER, August-Wilhelm. ARIS - od podnikových procesů k aplikačním systémům. 1.vydání. IDS Scheer ČR s.r.o., Brno, 2002. ISBN 80-238-4719-8. SKLENÁK, Vilém a kolektiv. Data, informace, znalosti a Internet. 1. vydání. C.H.Beck Praha, 2001. ISBN 80-7179-409-0. SLÁNSKÝ, David; DIEPOLT, Jiří. Business Inteligence a Data Management – vaše palubní deska pro bezpečný průlet současnými turbulencemi. KPMG, slide z přednášky 8.4.2009. SLÁNSKÝ, David; GRATTON, Simon: Data Governance. ADASTRA,slide z Business Briefingu, hotel Corinthia Towers v Praze, 23.5.2008.

75

SYSTEM ON LINE, Datová kvalita pod lupou [online]. [cit.09.03.2010] Dostupný z WWW . UČEŇ, Pavel a kol.: Metriky v informatice. Jak objektivně zajistit přínosy informačního systému. 1.vydání. Grada Praha, 2001. ISBN 80-247-0080-8. VACEK, Jaroslav; KYJONKA, Vladimír: Businessová infrastruktura kvality dat. ADASTRA, slide z Business Briefingu, hotel Palace v Praze, 22.6.2006. VOŘÍŠEK, Jiří a kol.: Principy a modely řízení podnikové informatiky. 1.vydání. Oeconomia Praha, 2008. ISBN 978-80-245-1440-6. ZÝKA, Ondřej; IĽLANOVSKÝ, Lubomír; MATHAUSER, Dominik; JANČA, Pavel: DATOVÁ KVALITA, Pracovní snídaně, PROFINIT 15.7.2009, slide z přednášek.

76

Seznam pouţitých obrázků Obrázek 1: Vztah informací a dat (zdroj Kalvoda) ....................................................... 14 Obrázek 2: Architektura ARIS-Business Framework (zdroj ARIS)10 ......................... 15 Obrázek 3: Základní framework TIQM metodologie (zdroj English)11 ...................... 16 Obrázek 4: Framework projektu řešení datové kvality v bance (zdroj TietoEnator) 17 Obrázek 5: Framework Data Governance (zdroj Adastra) .......................................... 17 Obrázek 6: Framework této práce (zdroj vlastní) .......................................................... 18 Obrázek 7: Graf prevence versus inspekce (zdroj Profinit) .......................................... 19 Obrázek 8: tabulka problémů při unifikaci klientů (zdroj vlastní) .............................. 24 Obrázek 9: Mutace zápisu Ústí nad Labem (zdroj vlastní) ........................................... 25 Obrázek 10: Schéma datového skladu a ETL procesů (zdroj Miniberger) ................. 27 Obrázek 11: Formy komunikace a jejich efektivnost (zdroj Buchalcevová) ............... 30 Obrázek 12: Struktura programu Data Governance (zdroj Adastra)21 ...................... 32 Obrázek 13: Dotazník (str. 1) ........................................................................................... 42 Obrázek 14: Dotazník – pokračování (str. 2) .................................................................. 43 Obrázek 15: Dotazník – pokračování (str. 3) .................................................................. 43 Obrázek 16: Dotazník – pokračování (str. 4) .................................................................. 44 Obrázek 17: Dotazník – pokračování (str. 5) .................................................................. 44 Obrázek 18: Nákladový model a doporučené trendy (zdroj TietoEnator) .................. 49 Obrázek 19: Mapování modelu pro náklady nekvality na jednotlivé kategorie nákladů z frameworku (zdroj vlastní) ............................................................................. 49 Obrázek 20: Model pro náklady nekvality (zdroj vlastní) ............................................ 50 Obrázek 21: Návrh DQ konceptu - procesní pohled (zdroj vlastní) ............................. 51 Obrázek 22: Návrh bodů pro měření datové kvality (zdroj vlastní) ........................... 52 Obrázek 23: Schéma odpovědnosti DQ oddělení (zdroj vlastní) .................................. 56 Obrázek 24: DQ oddělení – vztahy k ostatním útvarům banky (zdroj vlastní) .......... 57 Obrázek 25: Metodika datové kvality SAS DataFlux (zdroj SAS)22 ............................ 58 Obrázek 26: SAS DataFlux on-line korekce, fáze 1 (zdroj SAS) .................................. 59 Obrázek 27: SAS DataFlux on-line korekce, fáze 2 (zdroj SAS) .................................. 60 Obrázek 28: SAS DataFlux on-line korekce, fáze 3 (zdroj SAS) .................................. 60 Obrázek 29: Vyčištění křestního jména Přemysl (zdroj vlastní) .................................. 63 Obrázek 30: Vyčištění názvu města (zdroj vlastní) ........................................................ 63 Obrázek 31: Ataccama – schéma nástroje Master Data Center (zdroj Ataccama) .... 65 Obrázek 32: Unifikace druhů produktů (zdroj vlastní) ................................................ 67

77

Obrázek 33: Řídící panel Balanced Scorecard (zdroj Učeň) ......................................... 70 Obrázek 34: Měření datové kvality, část 1. (zdroj vlastní) ............................................ 71 Obrázek 35: Měření datové kvality, část 2. (zdroj vlastní) ............................................ 71 Obrázek 36: Měření datové kvality, část 3. (zdroj vlastní) ............................................ 71 Obrázek 37: Měření datové kvality, část 4. (zdroj vlastní) ............................................ 72

78

Seznam pouţitých tabulek Tabulka 1: Schéma DQA (zdroj vlastní) ......................................................................... 29 Tabulka 2: Škála důleţitosti moţných odpovědí (zdroj Projekt 0380) ......................... 31 Tabulka 3: Sběr poţadavků pomocí dotazníku z DQA (zdroj vlastní) ........................ 46

79