Kvalita dat v datovém skladu nezbytný předpoklad reportingu

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Kvalita dat v datovém skladu nezbytný předpoklad reportingu Diplomová práce Autor: Vedoucí práce: Bc. Jana Hendrichová Informační Technologie a Management doc. Ing. Bohumil Miniberger, CSc. Praha Duben, 2011

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracovala samostatně a v seznamu uvedla veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámena se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, dne 28. 4. 2011 Jana Hendrichová

Poděkování Ráda bych touto cestou poděkovala vedoucímu diplomové práce panu docentu Ing. Bohumilu Minibergerovi za metodické vedení a odborné konzultace, které mi poskytl při zpracování mé diplomové práce.

Anotace Diplomová práce s názvem Kvalita dat v datovém skladu nezbytný předpoklad reportingu je zaměřena na problematiku důleţitosti kvality dat v datových skladech. Jednotlivé kapitoly popisují nejdůleţitější témata vztahující se k cíli práce strukturu a funkci datového skladu, stávající koncept datové kvality a proces reportingu v konkrétní společnosti. V závěrečné kapitole jsou uvedeny návrhy a doporučení ke zlepšení datové kvality a následnému zkvalitnění reportingu. Navrţená opatření zahrnují zejména optimalizaci procesů souvisejících se zpracováním dat a kontrolou jejich kvality a dále upřesnění a nastavení nových rolí ve společnosti včetně jejich adekvátního organizačního zařazení. Annotation Dissertation called Data Quality in Data Warehouse Necessity for Reporting is focused on issue of importance of data quality in data warehouses. Particular chapters describe most important areas with relationship to the target of this dissertation structure and functions of data warehouse, existing concept of data quality and reporting process in concrete company. In final chapter, there are proposals and recommendations for improvement of data quality and consequently leading to enhancement of reporting. Proposed measures include mostly optimization of processes related to data processing and data quality control, further corrections and setting of new roles in the company including their adequate positioning in organizational structure.

Obsah Úvod... 7 1. Datová kvalita... 10 1.1 Řízení kvality dat... 11 1.2 IT Governance a CobiT... 12 2. Datový sklad... 21 2.1 Definice datového skladu... 21 2.2 Výhody datového skladu... 21 2.3 Systémy OLTP x Datové sklady... 21 2.4 OLAP... 23 2.4.1 OLAP operace... 24 2.5 Schéma uloţení dat... 26 2.5.1 Schéma hvězda (star)... 26 2.5.2 Schéma sněhová vločka (snowflake)... 27 2.6 Datová trţiště (Data Marts)... 29 2.7 Dolování dat (Data Mining)... 29 2.8 ETL... 29 2.8.1 Extrakce... 31 2.8.2 Transformace... 31 2.8.3 Čištění dat... 32 2.8.4 Load... 33 2.8.5 Výhody ETL nástrojů... 34 2.8.6 Přehled ETL nástrojů... 34 2.8.7 Chyby a problémy ETL procesu... 36 2.9 Základní moduly datového skladu ve společnosti [10]... 37 2.9.1 Matrix... 37 2.9.2 EDW (Enterprise Data Warehouse)... 39 2.9.3 ODS (Operational Data Store)... 40 2.9.4 DTS (Decision Tables System)... 41 2.9.5 Ostatní aplikace prostředí BI/DWH... 41 3. Koncept datové kvality ve společnosti... 43 3.1 Business Intelligence (BI)... 43 3.1.1 Nástroje BI pro zajištění datové kvality... 44 4. Reporting... 53 4.1 Proces reportingu... 53 5

4.1.1 Stávající proces ţádosti o report... 53 4.2 BI Reporting, SAP Business Object, Hyperion... 56 4.2.1 ROLAP BI analytický reporting... 56 4.2.2 Multidimenzionální OLAP reporting... 57 4.3 ARDW (Analytical and Reporting Data Warehouse)... 58 4.4 Chordiant (Campaign Management Tool)... 59 4.5 Katalog Reportů... 59 4.5.1 Typy reportů... 60 4.6 Reporting a kvalita dat... 61 5. Návrhy a doporučení... 62 5.1 Nový proces reportingu... 62 5.2 Klíčová role vlastníka dat... 65 5.3 Katalog reportů... 65 5.4 Business Analytik Expert... 65 5.5 Vlastník reportu... 65 5.6 Manaţer datové kvality... 66 5.7 Kritéria úspěšnosti implementace... 66 Závěr... 67 Seznam použité literatury... 68 Seznam použitých zkratek (obrázků, grafů, tabulek, příloh)... 72 6

Úvod Diplomovou práci jsem zpracovala za pouţití podkladů a interních dokumentů mezinárodní telekomunikační společnosti, u které pracuji. Z důvodu ochrany firemního tajemství nemohu jméno společnosti uvést, v celé diplomové práci je proto uvedeno, ţe se jedná o společnost. Taktéţ jsem upravila některé obrázky, které jsou převzaty z interní dokumentace společnosti, je odstraněno logo a název společnosti. Cílem mé diplomové práce je návrh na zlepšení datové kvality v podniku. Konkrétně se budu po celou dobu práce zabývat datovou kvalitou ve velké mezinárodní telekomunikační společnosti a zaměřím se zejména na kvalitu dat v datovém skladu, neboť data z datového skladu se pouţívají pro jednotný celofiremní reporting. Základní problémy datové kvality ve společnosti souvisejí s nekoncepčním vývojem v posledních letech. Pozitivním faktem je, ţe ve společnosti existují základy řešení datové kvality z minulosti. Společnost má v rámci oddělení Informačních Technologií (IT) ustanovený tým Business Inteligence (BI), který řeší problém datové kvality v datovém skladu (DWH) tím, ţe se snaţí zajistit datovou kvalitu jiţ ve zdrojových systémech a také při transformaci dat ze zdrojových systémů do datového skladu. Tým BI má uzavřené tzv. DQA (Dohody o kvalitě dat) s osobami odpovědnými za kaţdý zdrojový systém, které je zavazují provádět neustálou kontrolu kvality dat na zdrojových systémech a na rozhraních mezi systémy. V posledních letech však v důsledku celosvětové krize došlo ve společnosti k redukci stavu pracovníků, v rámci které odešli někteří pracovníci, kteří měli na starosti kontrolu dodrţování uvedených dohod a také uzavírání nových. V důsledku toho se začala zhoršovat kvalita dat ze zdrojových systémů, neboť nikdo nebyl motivován k jejímu udrţování v průběhu zavádění nových obchodních iniciativ. Také při vzniku nových aplikací či nových rozhraní mezi aplikacemi jiţ nedocházelo k analýze dat s ohledem na datovou kvalitu, coţ ve výsledku znamenalo sníţení kvality dat v těchto systémech a následně v datovém skladu. Postupem času se nízká datová kvalita začala projevovat chybnými či nekonzistentními daty v různých reportech pouţívaných ve společnosti, aţ si závaţnost těchto nepřesností vyţádala potřebu se znovu na datovou kvalitu soustředit. 7

Jako první krok k naplnění cíle mé práce budu muset provést detailní analýzu aktuálního stavu datové kvality ve společnosti a následně navrhnout kroky a postupy, které povedou ke zlepšení datové kvality v datovém skladu a následně i ke zlepšení kvality reportingu. 8

Volba metodologie Pro zpracování diplomové práce (DP) jsem zvolila metodologii, která je v souladu s cílem DP. Nejprve popisuji současný stav zabezpečení procesu řízení kvality dat a pak nastíním způsob jeho zlepšení, konkrétně změny v procesu reportingu a ustanovení rolí manaţera kvality business experta. Při tom jsem vycházela ze známých postupů pro Business Process Reengineering. Nejprve je nutné analyzovat a vybrat rozhodující oblast, poté popsat a vyhodnotit současný proces, navrhnout a popsat proces nový, a následně vyhodnotit jeho přínos. Cílem je zjednodušení, automatizace, eliminace redundantních činností a taktéţ standardizace. 1 1 MINIBERGER, Bohumil, BUDIŠ, Petr. Strategické řízení informačních systémů [online]. 2009. [cit. 2011-02-24]. Dostupný z WWW:< https://is.bivs.cz/auth/el/6110/zima2010/m101srs/miniberger_a_budis_strategicke_rizeni_informacnich_syst emu_2009.ppt 9

1. Datová kvalita Datová kvalita se v poslední době stává velmi diskutovaným pojmem světa informačních systémů. Všechna odvětví průmyslu a obchodu vyţadují stále více přesných a spolehlivých informací. Data, která poţadujeme, jsou často pořizovaná a ukládaná v rámci rozsáhlé architektury informačních systémů. Data zde vystupují jako surovina ve výrobním procesu a jsou dána do určitého kontextu za pouţití specifické znalosti uţivatele. Výstupem z tohoto procesu dostaneme informaci, která slouţí pro podporu rozhodování. 2 Pokusme se vymezit pojem kvalita dat. Jelikoţ existuje řada definic, nejvýstiţnější je asi ta, kterou uvádí David Loshin ve své knize o Business Intelligence: Datová kvalita je více než jména a adresy. 3 Podle Davida Loshina je moţno vlastnosti, které souvisí s datovou kvalitou uspořádat podle dimenzí kvality a typů chyb. Dimenze kvality: přesnost úplnost konzistentnost včasnost Typy chyb: nestejná granularita překlepy při pořizování dat chybná metadata implicitní a explicitní hodnoty Null smíšení formátů struktur 2 TOBIŠEK, Roman. Kudy na řízení kvality dat. IT Systems [online]. 2009, 03. [cit. 2011-01-25]. Dostupný z WWW: < http://www.systemonline.cz/business-intelligence/kudy-na-rizeni-kvality-dat.htm>. 3 LOSHIN, David. Business Intelligence. San Francisco, CA 94111 : Morgan Kaufmann Publishers, 2003. 270 s. ISBN -13:978-1-55860-916-7. 10

transformační chyby překombinování (overloading) atributů Další podrobnější výklad je v jiţ ve zmiňované knize. Problém kvality dat je zde pojat z procesního pohledu, který nám umoţňuje lepší pochopení problematiky datové kvality, včetně rizik, které mohou nastat. Vzhledem k tomu, ţe ztráty, které jsou způsobeny nekvalitními daty, se dle poradenských firem odhadují v USA na stovky miliard ročně, je třeba datové kvalitě věnovat náleţitou pozornost. 4 1.1 Řízení kvality dat Poloţme si otázku, proč je důleţité řídit kvalitu dat. V dnešní době jsou nejcennějším nástrojem data, které přeměnou v informace slouţí pro podporu rozhodování. Nejedná se pouze o to mít data kvalitní, ale také dostupné ve správný čas a na správném místě. Pro řízení kvality dat je nutno definovat procesy a postupy, které umoţní kompletní kontrolu dat jiţ v primárních systémech, konkrétně kdo a kdy má data kontrolovat a také návaznost spuštění dalších procesů. Kontrola kvality dat by měla být řešena jiţ v návrhu BI řešení, ale většina společností řeší kvalitu dat aţ jako součást ETL procedur. 5 Získat kvalitní data lze dosáhnout pouze spoluprácí na mnoha úrovních, jelikoţ kvalita dat v datovém skladu je podmíněna: Kvalitou dat v primárních systémech Kvalitou ETL procesů a jejich zabezpečením Kvalitou dat v externích souborech (například převzaté číselníky z ČNB či ČSÚ) Procesním zabezpečením kvality dat Pro zajištění kvality informačních systémů a taktéţ kvality dat je nutno definovat organizační strukturu útvaru IT, její role a činnosti, na jejichţ základě mohou být definovány pravomoci 4 MINIBERGER, Bohumil. Kvalita dat datových skladů nezbytný předpoklad předcházení rizik manaţerského rozhodování. Sborník z 11. Ročníku mezinárodní konference Současnost a budoucnost krizového řízení. Praha 2009, ISBN 978-80-254-5912-6. 5 NOVOTNÝ, O., POUR, J. a SLÁNSKÝ, D. Business Intelligence, Jak vyuţít bohatství ve vašich datech. Praha : Grada Publishing, 2005. 254 s. ISBN 80-247-1094-3 11

jednotlivých útvarů a jejich pracovníků. Nejlépe toho lze dosáhnout za pouţití metodiky CobiT a procesního rámce ITIL spadající pod ISACA 6. 1.2 IT Governance a CobiT IT Governance je jedna ze součástí korporátního řízení zaměřená na informační technologie (IT), systémy a jejich výkonnost a na řízení rizik. Jeho nedílnou součástí je i zajišťování kvality dat. Jedním z nejčastěji pouţívaných nástrojů strategického řízení je metodika CobiT, podle níţ se v dnešní době řídí především velké společnosti. Tato metodika se také nejčastěji pouţívá jako nástroj auditu IT. CobiT neboli Control Objectives for Information and Related Technology je metodika, která vznikla v 80. letech ve společnosti ISACA, která sdruţuje auditory informačních systémů. Tato metodika obsahuje návod na provádění auditu pro jednotlivé oblasti řízení IT (IT Governance). Metodika komplexně mapuje jednotlivé IT procesy a určuje pro ně referenční hodnotu. Je třeba si uvědomit, ţe společnost potřebuje spolehlivé informace, aby je mohla spravovat, je nutno podnik řídit a kontrolovat IT zdroje. Pro poskytování relevantních sluţeb je nutno zdroje strukturovat do procesů. CobiT je metodika zaloţená na kontrolách a je řízená metrikami. CobiT popisuje model zralosti CMM (Capability Maturity Model), který umoţňuje porovnat úroveň procesů v jednotlivé organizaci a následně pak provádět jejich zlepšování. Model zralosti se skládá z 5 úrovní: 7 1. Initial počáteční (nahodilé procesy) 2. Repeteable opakovaná 3. Defined definovaná 4. Managed řízená (jasná definice všech procesů) 6 ISACA (Information Systems Audit and Control Association) - mezinárodní profesní asociace, která je zaměřená na oblast auditu, řízení, kontroly a bezpečnosti informačních systémů, zaloţená v USA v roce 1969. 7 Vítá vás portál ManagementMania.com [online]. 2010 [cit. 2011-03-30]. Model zralosti CMM (Capability Maturity Model. Dostupné z WWW: < http://managementmania.com/index.php/zakladni-pojmy/322-cmmcapability-maturity-model>. 12

5. Optimized optimalizovaná Někdy se taktéţ uvádí úroveň 0, neboli neexistující řízení, procesy a jejich řízení je zcela chaotické. Obrázek 1: Model zralosti organizace (Capability Maturity Model) Zdroj: Autor Cílem metodiky CobiT je zastřešit a integrovat standardy. Je to nástroj, který se dá přizpůsobit potřebám kterékoliv firmy, záleţí pouze na tvořivosti manaţerů, jakým způsobem ho pojmou. CobiT umoţňuje certifikovat oblast IT na normu ISO 9001:2000. Důvody pro použití metodiky CobiT: Formalizace IT procesů do jednoduché struktury 13

snadná implementace základní struktury procesů Certifikace na normu ISO 9001:2000 Definice odpovědností IT vazby na kritické faktory a cíle podniku Vazba mezi podnikovou a informační strategií Návrhy výkonnostních a výsledkových ukazatelů Jednoduchá definice struktury poţadavků na IT pochopitelná i pro jiná oddělení mimo IT. Obrázek 2: Multidimenzionální kostka CobiT Zdroj: Převzato z [25], vlastní úprava Procesní orientace CobiT 8 CobiT se skládá z 34 procesů rozdělených do 4 kategorií, poskytuje měřítka, jaká má daný proces splňovat. Tato metodika nám, ale neříká, jakými konkrétními opatřeními lze stanovených výsledků dosáhnout. 8 CleverAndSmart - ICT management [online]. 2011 [cit. 2011-04-11]. COBIT tajemství zbavený - CleverAndSmart. Dostupné z WWW: <http://www.cleverandsmart.cz/cobit-tajemstvi-zbaveny/>. 14

Plánování a organizace (Plan and Organize) 10 procesů PO1 Definování strategického IT plánu PO2 Definování informační architektury PO3 Určení technologického směru PO4 Definování IT procesů, organizace a vztahů PO5 Řízení IT investic PO6 Komunikování manaţerských cílů a směrů PO7 Řízení lidských zdrojů IT PO8 Řízení kvality PO9 Vyhodnocování a řízení IT rizik PO10 Řízení projektů Akvizice a implementace (Acquire and Implement) 7 procesů AI1 Identifikace automatických řešení AI2 Pořizování a údrţba aplikačního software AI3 Pořizování a údrţba technologické infrastruktury AI4 Umoţnění provozu a pouţívání AI5 Obstarání IT zdrojů AI6 Řízení změn AI7 Instalace a schválení řešení a změn Dodání a podpora (Deliver and Support) 13 procesů DS1 Definice a řízení úrovně sluţeb DS2 Řízení sluţeb třetích stran DS3 Řízení výkonu a kapacity DS4 Zajištění nepřetrţitého fungování DS5 Zajištění bezpečnosti systémů DS6 Identifikace a alokace nákladů DS7 Vzdělávání a školení uţivatelů DS8 Řízení service desku a incidentů DS9 Řízení konfigurace DS10 Řízení problémů DS11 Řízení dat DS12 Řízení fyzického prostředí 15

DS13 Řízení provozu Monitorování a vyhodnocování (Monitor and Evaluate) 4 procesy ME1 Monitorování a řízení výkonnosti IT ME2 Monitorování a vyhodnocení vnitřní kontroly ME3 Zajištění shody s vnějšími poţadavky ME4 Zajištění IT governance Informační kritéria, kterými jsou procesy poměřovány: 1. efektivnost 2. výkonnost 3. důvěrnost 4. dostupnost 5. integrita 6. soulad 7. spolehlivost Výsledná zjištění jsou přiřazována pěti zdrojům: 1. personál 2. aplikace 3. technologie 4. vybavenost 5. data Pokud zmiňujeme metodiku CobiT, nelze se nezmínit taktéţ o procesní rámci ITIL (Information Technology Infrastructure Library). Jedná se o celosvětový veřejně dostupný rámec, který popisuje best practices (nejlepší praktiky) v řízení IT sluţeb. ITIL se zaměřuje na neustále zlepšování a měření kvality dodávaných IT sluţeb nejen z pohledu zákazníka, ale také businessu. ITIL verze 3 se skládá z 5 knih, které mapují všechny fáze ţivotního cyklu sluţeb od počáteční fáze definice poţadavků aţ po implementaci do provozního prostředí. ITIL v3 se skládá z 5 základních publikací, které níţe uvádím. Publikace na sebe logicky navazují a vycházejí ze ţivotního cyklu sluţeb. 16

1. Service Strategy poskytuje návrh, vývoj a implementaci 2. Service Design poskytuje návrh a vývoj IT sluţeb a procesů 3. Service Transition zajištění provozu a podpory sluţeb 4. Service Operation odpovědnost za běh sluţeb, kontrola a řízení provozních procesů 5. Continual Service Improvement návody pro vytvoření a udrţení hodnoty sluţeb pro zákazníky Jmenujme alespoň některé přínosy zavedení procesního rámce ITIL: navýšení spokojenosti uživatelů a zákazníků se službami IT zkrácení času pro uvedení nových produktů a služeb na trh zlepšení podkladů pro rozhodování a optimalizace rizik. zlepšení dostupnosti služeb, což přímo vede ke zvýšeným ziskům a obratu businessu finanční úspory plynoucí ze snížení opakovaných prací, ztraceného času, zlepšené správy a využití zdrojů 9 CobiT a ITIL se navzájem nevylučují. Pro CobiT někdy nehovoří to, ţe je pro IT méně pochopitelný, jelikoţ byl vytvořen auditory. CobiT je, na rozdíl od ITIL, k dispozici zdarma. 9 ITIL - Homepage [online]. 2007 [cit. 2011-03-30]. Dostupné z WWW: <http://www.itil.cz/>. 17

Obrázek 3: ITIL v3 Zdroj: Převzato z [28] 1.2.1.1 PDCA Model Pro dosaţení cíle mít spolehlivá data nesmíme opomenout zmínit nekonečný zlepšovací proces dle Demingova PDCA modelu. Autorem této metody je Demingův duchovní otec Walter A. Shewhart. PDCA model je metoda postupného zlepšování se probíhající formou opakovaného provádění 4 neustále po sobě jdoucích činností: 10 P = Plan - naplánování všech aktivit D = Do rozhodnutí a realizace plánu C = Check výsledku realizace oproti původnímu záměru, sledovat dopady A = Act nadále zlepšovat Nelze si nevšimnout podobnosti mezi CobiT a Demingovým PDCA modelem. U Demingova modelu fáze PLAN odpovídá Plánování a organizace (Plan and Organize), fáze DO je v doménách Akvizice a implementace (Acquire and Implement) 10 Vítá vás portál ManagementMania.com [online]. 2010 [cit. 2011-03-30]. Demingův cyklus (PDCA). Dostupné z WWW: <http://managementmania.com/index.php/kvalita/38-ostatni/146-deminguv-cyklus>. 18

a Dodání a podpora (Deliver and Support) a posledním dvěma fázím CHECK+ACT se vztahuje doména Monitorování a vyhodnocování (Monitor and Evaluate). 11 Obrázek 4: CobiT framework Zdroj: Převzato z [17] 1.2.1.2 Audit datového skladu Auditem datového skaldu se rozumí posouzení stávajícího řešení datového skladu. Kvalitně provedený audit by měl být realizován nezávislou společností, a pokud je řešení dodáváno externí firmou, pak by auditor měl být nezávislý i na této firmě. Společnost, která bude provádět audit, by měla mít dostatečné mezinárodní zkušenosti a také znalosti z oblasti Business Intelligence a datawarehousingu. O auditu uvaţujeme, pokud se domníváme, ţe: Data v datovém skladu jsou nepřesná a nekvalitní Vývoj datového skladu se neubírá tím správným směrem 11 CleverAndSmart - ICT management [online]. 2011 [cit. 2011-04-06]. COBIT tajemství zbavený - CleverAndSmart. Dostupné z WWW: <http://www.cleverandsmart.cz/cobit-tajemstvi-zbaveny/>. 19

Zajímá nás porovnání s konkurencí Datový sklad neodpovídá best practices Architektura datového skladu nereflektuje obchodní potřeby Oblasti pro provedení auditu dle Slánského jsou následující: obsah řešení jaká data a informace řešení poskytuje, funkcionalita řešení jaké prostředky pro získání informací řešení poskytuje, např. statické, dynamické či ad hoc reporty, rozesílání informací e-mailem, publikace reportů na intranetu apod., strategické a plánovací řídící procesy zahrnující řízení a plánování rozsahu řešení, strategické a metodické řízení provozu a vývoje řešení, řízení finančních atributů řešení apod., dodavatelé řešení hodnocení jejich schopností, efektivity apod., architektura a komponenty řešení včetně technologií a to nejen na úrovni zařazení řešení BI do celkové architektury IS/ICT, ale i na úrovni jednotlivých komponent řešení (ETL, databáze, analytické a prezentační nástroje apod.) a procesů běžících na pozadí (řízení kvality dat, konsolidace, správa metadat apod.), detailní proces řízení projektů vývoje jednotlivých částí (přírůstků) DW, detailní procesy řízení provozu DW zahrnující řízení termínů DW (aktualizace dat, publikace dat apod.), řízení problémů a chyb, uživatelskou podporu, řízení požadavků rozvoje a změn. 12 12 SLÁNSKÝ, David. Audit řešení datového skladu. IT Systems [online]. 2006 [cit. 2011-04-17]. Dostupný z WWW: <http://www.systemonline.cz/business-intelligence/audit-reseni-datoveho-skladu-1.htm>. 20

2. Datový sklad 2.1 Definice datového skladu Podle definice Billa Inmona, který byl jedním ze zakladatelů Data Warehousingu, je datový sklad (DataWarehouse nebo DWH) integrovaný, subjektově orientovaný a také stálý a časově rozlišený souhrn dat pro podporu rozhodování managementu. 13 Datový sklad je zvláštní typ relační databáze, která umoţňuje řešit úlohy zaměřené převáţně na analytické dotazování nad rozsáhlými soubory dat. Hlavním důvodem pro vytváření datových skladů je fakt, ţe v primárních systémech nejsou data uspořádaná tak, aby byla přímo pouţitelná pro analýzu. Struktury dat v primárních systémech nejsou pro manaţera (analytika) z hlediska analýzy dostatečně srozumitelné a čitelné a bohuţel data v primárních systémech mívají i různorodou kvalitu. 2.2 Výhody datového skladu Datový sklad má nesporně celou řadu výhod, jmenujme alespoň některé z nich: Rychlý přístup k informacím Zdroj dat shromáţděných z firemních systémů Nástroj pro podporu manaţerského rozhodování Zvýšení produktivity v oblasti analýz podnikových dat Podpora strategického řízení podniku 2.3 Systémy OLTP x Datové sklady Datový sklad můţeme chápat také jako komplexní úloţiště pro data, která jsou ve struktuře, která nám umoţňuje efektivní vytváření analýz a dotazů. Někdy také bývá synonymem pro datové sklady zkratka OLAP (Online Analytical Processing) neboli okamţité zpracování dat. Na straně druhé pak máme OLTP (Online Transaction Processing) neboli okamţité zpracování transakcí. 13 NOVOTNÝ, O., POUR, J. a SLÁNSKÝ, D. Business Intelligence, Jak vyuţít bohatství ve vašich datech. Praha : Grada Publishing, 2005. 254 s. ISBN 80-247-1094-3 21

Datový sklad se vyuţívá výhradně k potřebám nejrůznějších analýz, ke čtení dat, na rozdíl od OLTP modelu. V běţném provozu není obsah datového skladu měněn. Jedinou výjimkou je přidávání/odebírání datových agregátů, které probíhají periodicky, coţ je ale součástí pravidelné údrţby DWH. 14 Součástí OLTP jsou TPS (TPS-Transaction Processing System), mezi které počítáme podnikové informační systémy - ERP (Enterprise Resource Planning), SCM (Supply Chain Management) - systém pro řízení dodavatelského řetězce, nebo CRM (Customer Relationship Management) - systém řízení vztahů se zákazníky. 15 Do kategorie OLAP systémů se obvykle zahrnují i systémy slouţící pro manaţerské řízení (MIS-Management Information System) a také i systémy pro rozhodování EIS (Executive Information Systems). Spolupráce mezi systémy OLTP a OLAP je znázorněna na následujícím obrázku. Obrázek 5: Hierarchická struktura informačního systému podniku, zaloţená na vzájemně propojených datech Zdroj: Převzato z [9], vlastní úprava V tabulce níţe jsou pro lepší přehlednost popsány základní znaky OLTP a OLAP. 14 Data Mining [online]. 2002 [cit. 2011-02-20]. Datové sklady a OLAP. Dostupné z WWW: <http://datamining.xf.cz/view.php?cisloclanku=2002102808>. 15 MINIBERGER, Bohumil. Kvalita dat datových skladů nezbytný předpoklad předcházení rizik manaţerského rozhodování. Sborník z 11. Ročníku mezinárodní konference Současnost a budoucnost krizového řízení. Praha 2009, ISBN 978-80-254-5912-6. 22

Tabulka 1: Rozdíly mezi OLTP a OLAP Znak OLTP OLAP Charakteristika Provozní zpracování Informační zpracování Orientace Transakční Analytická Uživatel Úředník, databázový administrátor Znalostní pracovník (manažer, analytik) Funkce Každodenní operace Dlouhodobé informační požadavky, podpora rozhodování Návrh databáze Entitně-relační základ, aplikačně orientovaný Hvězda/sněžná vločka, věcná orientace Data Současná, zaručeně aktuální Historická Sumarizace dat Základní, vysoce detailní Shrnutá, kompaktní Náhled Detailní Shrnutý, multidimensionální Jednotky práce Krátké, jednoduché transakce Komplexní dotazy Přístup Číst a zapisovat Většinou pouze číst Zaměření Vkládání dat Získávání informací Počet dostupných záznamů Desítky Miliony Počet uživatelů Tisíce Stovky Velikost databáze 100 MB až GB 100 GB až TB Vysoká flexibilita, nezávislost Přednosti Vysoký výkon, vysoká přístupnost koncového uživatele Míry hodnocení Propustnost transakcí Propustnost dotazů a doba odezvy Zdroj: Převzato z [19], vlastní úprava 2.4 OLAP Jak jiţ bylo zmíněno, zkratka OLAP znamená On-line Analytical Processing neboli okamţité zpracování dat. Tento termín zavedl Dr. E. F. Codd 16 a níţe uvádím jeho původních 12 pravidel OLAP. 17 Pravidlo 1 multidimenzionální konceptuální pohled Pravidlo 2 transparentnost Pravidlo 3 dostupnost Pravidlo 4 konzistentní reportování Pravidlo 5 architektura klient/server Pravidlo 6 generická dimenzionalita 16 Dr. Edgar Frank Codd britský počítačový vědec známý především pro relační databázový model, drţitel Turingovy ceny (nejvyšší světové ocenění v oblasti počítačové vědy) 17 Foundation for Performance Measurement Home Page [online]. 1993 [cit. 2011-04-16]. Providing OLAP to User-Analysts. Dostupné z WWW: <http://www.fpm.com/refer/codd.html>. 23

Pravidlo 7 dynamické ošetření řídkých matic Pravidlo 8 podpora více uţivatelů Pravidlo 9 neomezené kříţové dimenzionální operace Pravidlo 10 intuitivní manipulace s daty Pravidlo 11 flexibilní reporting Pravidlo 12 neomezené dimenze a úrovně agregace 2.4.1 OLAP operace 2.4.1.1 Agregace je předpřipravená sumace, na základní úrovni 2.4.1.2 Pivoting rotace kostky, změna vizualizace, přeorientování pohledu na data 2.4.1.3 Roll-up Vzrůst úrovně, sumarizace (od prodeje podle jednotlivých měsíců na prodej podle čtvrtletí) Obrázek 6: Operace Roll up Zdroj: Autor 24

2.4.1.4 Drill-down rozpad, od sumace k větším detailům (od prodeje podle města na prodej podle městských částí) Obrázek 7: Operace Drill down Zdroj: Autor 2.4.1.5 Slice and dice Seříznutí, výběr projekce (redukce dimenzionality dat) 25

Obrázek 8: Operace slicing - dicing Zdroj: Autor 2.5 Schéma uložení dat 2.5.1 Schéma hvězda (star) Ralph Kimball významně přispěl k návrhu mechanismů ukládání dat v OLAP systémech a pro ukládání dat do datového skladu vyvinul speciální databázovou strukturu, kterou označujeme pojmem hvězdicové schéma. 18 Hvězdicové schéma se skládá z tabulky faktů, coţ je rozsáhlá centrální tabulka, a řady menších tabulek pro kaţdou dimenzi. Kaţdá dimenze je jedna tabulka, která můţe mít různé atributy. Příkladem můţe být dimenze Zboţí, která má Název_Zboţí, 18 OPPEL, Andrew. Databáze bez předchozích znalostí. Brno : Computer Press, 2006. 319 s. ISBN 80-251-1199-7. 26

Název_Výrobce, Adresa, IČO, DIČ. Primární klíč (PK) v kaţdé dimenzi je vztaţen k cizímu klíči (CK) v tabulce faktů. Obrázek 9: Schéma hvězda Zdroj: Autor 2.5.2 Schéma sněhová vločka (snowflake) Schéma Snowflake neboli sněhové vločky je rozšířením schématu hvězda. V tomto schématu jsou tabulky dimenzí normalizovány, neboli data jsou dělena dále do dalších tabulek. Výsledné grafické znázornění pak připomíná sněhovou vločku. 19 Hlavním rozdílem mezi schématem sněhové vločky a hvězdy je v tom, ţe ve schématu sněhové vločky jsou tabulky normalizovány, abychom zamezili redundanci dat. Normalizované tabulky jsou snadněji udrţovatelné a také šetří diskový prostor, ale v porovnání s velikostí tabulky faktů je tato úspora zanedbatelná. 19 Data Warehousing: A Look at Business Intelligence and Data Warehouse [online]. 2011 [cit. 2011-02-11]. Snowflake Schema. Dostupné z WWW: <http://www.1keydata.com/datawarehousing/snowflakeschema.html>. 27

Toto schéma je méně časté neţ schéma hvězda, jelikoţ je při analýze nutné více spojovat tabulky, coţ klade větší nároky na výkonnost systému. 20 Obrázek 10: Schéma sněhová vločka Zdroj: Autor Tabulka 2: Ukázka tabulky faktů Zdroj: Autor PRODEJ Prodejka_ID Zboží_ID Účetní_období_ID Prodejna_ID Prodejce_ID Poč_KS Cena 1 13 8 3301 4711 10 12500 2 22 8 3302 4563 35 165270 3 18 8 3305 5799 47 1316 4 13 8 3307 3566 6 53940 5 54 8 3301 4711 21 9870 6 17 8 3307 3566 7 111860 20 DWHWorld, Online Data warehouse resource [online]. 2010 [cit. 2011-02-03]. DWH Schemas DwhWorld. Dostupné z WWW: <http://www.dwhworld.com/dwh-schemas/>. 28

2.6 Datová tržiště (Data Marts) Vhodnou podmnoţinou datového skladu bývají datová trţiště. Datové trţiště se zaměřuje na podporu poţadavků konkrétního oddělení nebo činnosti firmy. Datové trţiště má několik charakteristických znaků, které uvádím níţe: Neobsahuje provozní data Je zaměřen pouze na jednu oblast oddělení nebo proces ve firmě Obsahuje menší mnoţství informací neţ klasický datový sklad Datová trţiště mohou existovat jako subsystémy datových skladů nebo i samostatně jako jednoduchý datový sklad. 2.7 Dolování dat (Data Mining) Dolování dat (data mining) je proces, jehoţ cílem je získávání skrytých a potenciálně dále vyuţitelných informací o datech. Zcela zřejmou výhodou tohoto procesu je odhalení dosud neznámých spojitostí, na které bychom běţným způsobem nepřišli. Vyuţívá statistické metody a také metody hraničící s oblastí umělé inteligence. Pomáhá sledovat a analyzovat trendy a předvídat události. Dolování dat se nejčastěji pouţívá v komerční sféře, například v marketingu pro oslovování potenciálních zákazníků dopisem nebo jinou formou. Komerčních nástrojů na dolování dat je v dnešní době na trhu dostatek, zmínila bych nejznámější, mezi něţ patří Enterprise Miner od společnosti SAS a STATISTICA Data Miner od společnosti StatSoft. Mezi nepouţívanější nekomerční nástroje patří software WEKA a ORANGE. 21 Ve společnosti, na kterou je aplikovaná tato diplomová práce, je vyuţíván nástroj Enterprise Miner od společnosti SAS. 22 2.8 ETL Proces plnění datového skladu je označován zkratkou ETL (Extraction -Transformation - Load). Tato zkratka vystihuje postup operací prováděných při plnění datového skladu. 21 Wikipedie, otevřená encyklopedie [online]. 2011 [cit. 2011-04-17]. Data mining - Wikipedie. Dostupné z WWW: <http://cs.wikipedia.org/wiki/data_mining>. 22 SAS Business Analytics and Business Intelligence Software [online]. 2011 [cit. 2011-04-17]. Model Development and Deployment, Data Mining Software, SAS Enterprise Miner SAS. Dostupné z WWW: <http://www.sas.com/technologies/analytics/datamining/miner/>. 29

O plnění dat do datového skladu se starají tzv. datové pumpy, neboli jiţ zmiňované ETL nástroje. Tyto nástroje pracují v dávkovém reţimu a zpracovávají data v určených časových intervalech (např. den, týden, měsíc). Jelikoţ jsou data získávány z různých vzájemně nekompatibilních systémů, je velmi důleţité, jak kvalitními ETL nástroji daná společnost disponuje. Kvalita ETL nástrojů přímo ovlivňuje kvalitu dat informací v datovém skladu. Obrázek 11: ETL Proces Zdroj: Převzato z [3], vlastní úprava 30

Obecně bychom mohli kroky ETL procesu popsat takto: 23 Extrakce dat ze zdrojových systémů Profilování Validace a čištění dat Aplikace business pravidel Konverze hodnot null Přesun dat do úloţiště Načtení dat do DWH 2.8.1 Extrakce Extrakce znamená získání dat z primárních systémů a také zahrnuje načítání dat z nejrůznějších zdrojů, nejen z databází, ale také například z textových souborů, XML dokumentů apod. V typickém podniku je primárních systémů, které zajišťují ţivotně důleţité operace, velké mnoţství. Získávání dat z těchto systémů není jednorázová záleţitost, ale periodicky se opakující činnost, jejímţ hlavním cílem je poskytnout aktuální data pro další zpracování. Pro extrakci dat jsou k dispozici různé postupy, technologie a nástroje. U správně navrţené etapy ETL procesu jsou k dispozici metadata (data o datech) pro všechny fáze etap a tato metadata obsahují informace o místě, typu, také o přístupových oprávněních a struktuře zdroje dat. 24 2.8.2 Transformace Samotná transformace v rámci ETL procesu je sada úkonů, které vedou ke zvýšení hodnoty dat získaných z OLTP systémů. Data z primárních systémů se přeměňují na metriky, které jsou uloţeny v tabulkách faktů a na atributy v tabulkách jednotlivých dimenzí. Prvky dimenzí vytvářejí hierarchické struktury (například den / týden / měsíc /čtvrtletí /rok), které mapují obchodní hlediska pouţívaná při analýze ukazatelů. 23 LOSHIN, David. Business Intelligence. San Francisco, CA 94111 : Morgan Kaufmann Publishers, 2003. 270 s. ISBN -13:978-1-55860-916-7. 24 LACKO, Luboslav. Business Intelligence v SQL Serveru 2008 : Reportovací, analytické a další datové sluţby. Brno : Computer Press, 2009. 456 s. ISBN 978-80-251-2887-9. 31

Kromě obecných dimenzí (např. čas) se vytvářejí i dimenze, ve kterých jsou uloţeny i další popisné atributy (například dimenze výrobce + atributy název, adresa, IČO). Transformace zahrnuje celou škálu operací od konverzí, matematických operací, filtrování, normalizace a denormalizace, aţ po sofistikované metody vytváření multidimenzionálních struktur. Transformace mohou probíhat sériově nebo paralelně. Při sériovém postupu se transformace uskuteční před zavedením dat do datového skladu, při paralelním zpracování se transformace vykonává souběţně se zaváděním dat do datového skladu. 25 2.8.3 Čištění dat Čištění dat je součástí procesu transformace, kde je zavedený mechanizmus pro kontrolu kvality dat a čištění dat. Data z primárních transakčních systémů mají velmi různorodou kvalitu. Kvalita dat do značné míry proměnlivá, která je způsobena například nepozorností při ručním zadávání dat. Příčinou špatné kvality dat je primárně člověk (nevyplní všechna pole formuláře, překlepy při zadávání dat, nedodrţování jednotných formátů, aj.) Předmětem čištění mohou být prakticky všechny atributy datových objektů. Například v datech o zákaznících firmy se obvykle prověřuje a čistí identifikační údaje, adresy, kontakty. Další chyby se vyskytují v atributech transakcí. Precizně navrţený systém ETL zaznamenává chyby do chybového ţurnálu. Některé opravy se provádějí automaticky, jiné, především kritické chyby, je třeba opravit ručně, nejlépe jiţ v primárních systémech a je nutno taktéţ o nich informovat správce datového skladu a ostatní zainteresované uţivatele Nejčastější problémy při transformaci dat: Chybějící hodnoty (Null) Chybějící datum Duplicitní záznamy Nejednotnost v názvech pojmů a objektů Nejednotné číselné formátování Nejednoznačná data (například údaje o pohlaví mohou být uloţeny jako ţena/ţ/ţenské). 25 LACKO, Luboslav. Business Intelligence v SQL Serveru 2008 : Reportovací, analytické a další datové sluţby. Brno : Computer Press, 2009. 456 s. ISBN 978-80-251-2887-9. 32

Se špatnou kvalitou dat, které ve velké míře způsobuje lidský faktor, musíme bojovat adekvátními nástroji pro čištění dat, kterým můţe být například nástroj firmy Harte-Hanks Trillium. 26 Trillium - nástroj pro čištění dat Trillium je nástroj firmy Harte-Hanks pro čištění dat o zákaznících. Trillium se skládá z modulů, ve kterých jsou data analyzována a transformována, a z databází zeměpisných údajů, katalogů jmen, titulů apod., pomocí nichž se opravují chyby. V procesu čištění se nejprve analyzují všechny vstupní údaje a určí se jejich význam - jméno, příjmení, název ulice, název města apod. Drobné chyby v datech se opravují za pomoci zeměpisných a jmenných katalogů. V analyzovaných a setříděných datech se dále vyhledávají významné shody a přiděluje se jim skóre podle pravděpodobnosti. Nakonec se identifikují jednotliví klienti. S použitím dodatečných informací, které lze získat z úvěrových žádostí a některých transakcí, je možné s určitou mírou pravděpodobnosti identifikovat domácnosti. V systému Trillium jsou obsaženy dlouholeté zkušenosti s identifikací. Tvůrci Trillia se začali zabývat čištěním a identifikací poštovních adres koncem šedesátých let minulého století. Od té doby vyvinuli celou řadu technologií, jež jsou dnes integrovány v robustním, škálovatelném a multiplatforním řešení. Systém Trillium v ČR distribuuje firma Data To Information (D2I). 27 Ve společnosti je pouţíván jako nástroj pro čištění a validaci dat komponenta Data Profiler od společnosti Ab Initio. 2.8.4 Load Fáze Load je završením celého ETL procesu, jedná se o fyzický přenos dat od zdroje do cílové databáze nebo datového skladu. Tato fáze by měla být plánovaná a plně automatizovaná. Pro uloţení dat jsou často vyuţívány specializované technologie, které předpokládají pouţití různých mechanizmů pro optimalizované vkládání dat. 26 LACKO, Luboslav. Business Intelligence v SQL Serveru 2008 : Reportovací, analytické a další datové sluţby. Brno : Computer Press, 2009. 456 s. ISBN 978-80-251-2887-9. 27 VAVRUŠKA, Jindřich. ETL a kvalita dat. IT Systems [online]. 2003, 03, [cit. 2011-01-21]. Dostupný z WWW: <http://www.systemonline.cz/clanky/etl-a-kvalita-dat.htm>. 33

Metadata Metadata jsou strukturovaná data o datech jedná se o názvy tabulek a sloupců, datových typů aj. Kaţdá databáze nebo systém obsahuje svá vlastní metadata. Metadata v ETL procesech popisují data z primárních zdrojů i data v cílové databázi, umoţňují taktéţ popsat definované transformace. Centrální úpravu metadat řeší specializované produkty, v naší společnosti se pouţívá nástroj od firmy Ab Initio a pro správu metadat konkrétně EME (Enterprise Metadata Repository), o kterém je více uvedeno v kapitole 2.9.1. 2.8.5 Výhody ETL nástrojů Mezi hlavní výhody nástrojů ETL bych zmínila repozitář a správu transformací v repozitáři, který je většinou uloţený v databázi. ETL nástroje také umoţňují vytvářet a spravovat metadata, v tomto případě o předpisech a definicích pro přenos a správu dat a taktéţ umoţňují řízené plánování a spouštění transformací. 2.8.6 Přehled ETL nástrojů Velká společnost zpracovávající denně veliké objemy dat se bez kvalitního ETL nástroje jiţ neobejde. Malá řešení je moţno realizovat za pouţití SQL a dávkových skriptů. Ale tento způsob lze volit jen pro velmi malá řešení za cenu náročnější údrţby. Dnes je na trhu několik ETL nástrojů, které se liší rozsahem funkcionality, architekturou, výkonem a v neposlední řadě taky cenou. Při budování nebo provozu datového skladu se investice do kvalitního ETL nástroje vrátí v časovém horizontu několika let. Ab Initio Ab Initio, ETL nástroj, který je pouţíván ve společnosti, a o kterém se taktéţ zmiňuji v kapitole 2.9.1.1, je dosti nákladný, ale velmi výkonný prostředek. Jeho specifikem je podpora paralelního zpracování dat, dále pak: Vysoký výkon Jednoduchá udrţovatelnost Maximalizace a kontrola vyuţití zdrojů Paralelní zpracování dat Schopnost rychle vytvářet aplikace Jasný a srozumitelný design procesu 34

Vše je vytvořeno uvnitř ETL produktu Tento nástroj se zejména pouţívá ve velkých finančních institucích a v telekomunikacích. Níže jsou uvedeny další používané nástroje, mezi něž patří: Warehouse Builder (Oracle) Oracle Warehouse Builder (OWB) je nástroj určený primárně pro použití s databázemi Oracle. Poskytuje prostředky pro návrh, správu a spouštění dávek a transformací a metadat. Samozřejmostí je grafické uživatelské rozhraní a u Oraclu obvyklá robustnost a škálovatelnost. OWB podporuje transformace řízené metadaty. Tím, že programový kód transformací lze generovat z metadat, se snižuje pracnost a chybovost programování transformací. Nástroj podporuje opakovatelnost využití kódu - v repozitáři lze vytvářet knihovny transformací importem vlastních transformačních procedur. Oracle Warehouse Builder zpřístupňuje metadata širšímu okruhu uživatelů prostřednictvím webové aplikace. K výsledkům datového auditu je přístup prostřednictvím speciální aplikace. Data Transformation Services (Microsoft) Tento software je součástí Microsoft SQL Server 2000. DTS umožňují přesouvat data mezi různými databázovými servery, ale celkem logicky fungují nejlépe a nejrychleji, je-li alespoň jedním z nich Microsoft SQL Server. DTS poskytují příjemné grafické rozhraní. Software umožňuje mapování jednoduchých transformací přímo, složitější transformace lze naprogramovat v jazyce Visual Basic, ale i v JavaScriptu nebo Perlu. Skripty v jiných jazycích než Visual Basic jsou ale v prostředí DTS pomalejší. Nástroje Informatica ETL nástroje Informatica zahrnují: PowerMart, PowerCenter a PowerCenterRT. Transformace navrhované v prostředí Informatiky jsou plně řízené metadaty. Tento koncept Informatica nazývá "Active Metadata". Bohatá výbava nástrojů umožňuje konektivitu nejrůznějších datových zdrojů - databázových serverů všech významných výrobců, souborů 35

odpovídajících otevřeným standardům apod. Informatica PowerCenterRT umožňuje aktualizaci v reálném čase technologií Zero Latency. 28 2.8.7 Chyby a problémy ETL procesu ETL proces ne vţdy končí úspěšně. Problémy mohou být různé, od výpadků spojení, přejmenování zdrojů dat aţ k spolehlivosti úloţiště dat. Největší důraz by měl být kladen na ověření dat. Pokud data nejsou validována, můţe docházet k problémům při extrakci a následnému přesunu dat. Vzhledem k tomu, ţe nepřesná či neúplná data zkreslují výsledné analýzy, můţe dojít k nesprávným obchodním či strategickým rozhodnutím. 29 Pokud je ETL systém navrţen správně, zaznamenává všechny chyby do chybového ţurnálu. Část chyb je opravena automaticky, ale chyby, které vyţadují ruční opravy a chyby kritické by měly být hlášeny správci datového skladu a odpovědným uţivatelům, například notifikačním e-mailem nebo SMS zprávou. Chyba by měla být opravena v systému výskytu, ale ne vţdy je to moţné pak je nutné opravu chyby zahrnout do ETL procesu. 28 VAVRUŠKA, Jindřich. ETL a kvalita dat. IT Systems [online]. 2003, 03, [cit. 2011-01-21]. Dostupný z WWW: <http://www.systemonline.cz/clanky/etl-a-kvalita-dat.htm>. 29 LACKO, Luboslav. Business Intelligence v SQL Serveru 2008 : Reportovací, analytické a další datové sluţby. Brno : Computer Press, 2009. 456 s. ISBN 978-80-251-2887-9. 36

2.9 Základní moduly datového skladu ve společnosti [10] Prostředí BI/Datawarehousingu ve společnosti je různorodé a ve velké míře customizované. Na obrázku níţe je zobrazeno prostředí Business Intelligence /Datawarehousingu. Obrázek 12: Prostředí BI/DWH Zdroj: Interní dokumentace společnosti (vlastní úprava) 2.9.1 Matrix Matrix je vstupní část datového skladu, kde dochází k načtení dat do datového skladu. Hlavním úkolem je transformovat a vyčistit vstupní data (na základě business pravidel), která přicházejí do datového skladu a uloţit je do cílového úloţiště (ODS, EDW, ARDW, atd.). Matrix běţí na platformě ETL Ab Initio a databázi ORACLE RAC (DTW2). Matrix zpracovává denně přibliţně 400 miliónů záznamů v celkovém čase cca 14 hodin. 37

2.9.1.1 Ab Initio Většina procesů v DWH je implementována v ETL nástroji Ab Initio. Sloţenina slova Ab Initio pochází z latiny a znamená od počátku 30. Společnost vlastní níže uvedené licence od AB Initio: Co-Operating system (server side) Continuous Flow (server side add-on) GDE (graphical development environment) Data Profiler (data validation & profiling tool) EME (metadata repository and version control) Hlavní funkce nástroje AB Initio Vysoký výkon Jednoduchá udrţovatelnost Maximalizace a kontrola vyuţití zdrojů Paralelní zpracování dat Schopnost rychle vytvářet aplikace Jasný a srozumitelný design procesu Vše je vytvořeno uvnitř ETL produktu Moţnost integrace čehokoliv s čímkoliv Soubory binární, textové, XML, ASN1 Excel Databáze Oracle, DB2, NTZ On-line WS, JMS, MQ 30 Ab Initio: About AB Initio [online]. 2010, 02. [cit. 2011-02-11]. Dostupný z WWW: <http://www.abinitio.com/about_abinitio.html> 38

Obrázek 13: Ab Initio základní komponenty Zdroj: Interní dokumentace společnosti 2.9.2 EDW (Enterprise Data Warehouse) Enterprise Data Warehouse je hlavní datový sklad (úloţiště), který slouţí pro centrální uloţení integrovaných dat/informací v rámci společnosti, primárně slouţících pro analytický reporting. Toto úloţiště obsahuje historická data, která jsou pouţívána dalšími systémy jako CMD (Chordiant Marketing Director), ARDW, Hyperion Essbase nebo Optimalizátor. Použitá technologie: Databázová část Netezza Performance Server 31 na konci roku 2010 proběhla migrace z Oracle na Netezzu, ale Oracle je ještě stále pouţíván pro speciální účely. Zároveň se změnou z Oracle na Netezzu se změnila i reportovací platforma a nově je ve společnosti vyuţíván SAP Business Object, o kterém se více zmiňuji v kapitole 4.2.1. 31 Netezza Performance Server - přináší jednoduché řešení pro celou řadu komplexních problémů z oblasti Data Warehousingu a dalších analytických oblastí. Společnost Netezza je součástí IBM Company. 39

Velikost dat v databázi přibliţně 1000 tabulek, 3,5 TB dat Část CDR store 32 AB Initio MultiFileStorage Obrázek 14: Netezza Performance Server Zdroj: Interní dokumentace společnosti 2.9.3 ODS (Operational Data Store) Operational Data Store slouţí k uloţení aktuálních a klíčových dat v prostředí s vysokou dostupností, na rozdíl od EDW jsou zde pouze aktuální data bez historie a jeho klíčovým konzumentem dat jsou interní aplikace společnosti (DTS, CCM, CVW, ) a externí aplikace (VCC). 32 CDR store Call Detail Record Store úloţiště záznamů o hovorech 40

2.9.4 DTS (Decision Tables System) DTS neboli Decision Tables System je soubor rozhodovacích tabulek, které umoţňují integraci business pravidel na jednom místě. Tato pravidla jsou dostupná za pouţití standardního Oracle API rozhraní. Pravidla jsou souhrnem rozhodovacích tabulek, které mohou být různě vkládány a kombinovány za pouţití technologie Oracle PL/SQL. Příkladem pravidla můţe být například kompatibilita telefonních tarifů nebo kontrola zůstatku kreditu. 2.9.5 Ostatní aplikace prostředí BI/DWH 2.9.5.1 Call Viewer a Charge Viewer Aplikace Call Viewer umoţňuje pohled na oceněné zákaznické události (např. hovory, SMS). Je vyuţívána oddělením sluţeb zákazníků pro případy zákaznických reklamací popř. oddělením zabývajícím se podvody. Sluţba má logické členění na CallViewer (oceněné události ze systému Amdocs Enabler 33 a RTSP/IN 34 ) a Charge Viewer (Charge Extrakt z Amdocsu). 2.9.5.2 Investigation Investigation je sluţba slouţící primárně pro potřeby splnění zákonných závazků vůči státu, zejména v oblasti spolupráce s policií. 2.9.5.3 Optimalizátor Tato sluţba je určená pro optimalizaci tarifů zákazníků společnosti a ostatních operátorů. Na základě historie chování zákazníka doporučuje tarif s nejniţší moţnou cenou. 2.9.5.4 EI Store (Electronical Invoices Store) EI Store slouţí k uloţení vybraných atributů zákaznických faktur. Poskytuje rozhraní pro přístup na tato data. 33 Amdocs Enabler systém pro účtování zákazníkům na fakturu 34 RTSP/IN Real Time Service Platform/Intelligent Network systém pro on-line účtování předplacených karet 41

2.9.5.5 CLV (Customer Lifecycle Value) Aplikace Custome Lifecycle Value slouţí pro výpočet návratnosti zákazníka, porovnává náklady a výnosy. Vstupem je historie chování zákazníka (hovory, SMS, MMS) Části DWH sloužící pro reporting (BI Reporting, Hyperion, ARDW a CMD) jsou popsány v kapitole číslo 4 - Reporting. 42

3. Koncept datové kvality ve společnosti Cílem konceptu datové kvality ve společnosti je zajištění datové kvality napříč všemi systémy podporovanými oddělením Informačních Technologií. Tento trend je plně v souladu s uznávanými systémy řízení jakosti ISO (9000) a nezahrnuje pouze technologické řešení problémů a implementaci software, ale také ve stejné míře postihuje nastavení nezbytných firemních procesů, definici rolí a odpovědností konkrétních osob, které na těchto procesech participují. Problematikou datové kvality se zabývá oddělení Business Intelligence. V tomto oddělení původně byla ustavena role specialisty na datovou kvalitu, ale v rámci úsporných opatření po nástupu ekonomické krize byla zrušena. Následkem bylo zhoršení kvality dat ve zdrojových systémech, neboť jiţ nebyly uzavírány a updatovány DQA (dohody o kvalitě dat). Sníţení kvality dat se následně projevilo chybnými a nekonzistentními daty v reportech a proto oddělení IT opět začalo aktivně prosazovat opětovné ustanovení role specialisty/manaţera datové kvality. 3.1 Business Intelligence (BI) Oddělení Business Intelligence plní následující role: Monitorování kvality reportů Rozšiřování validačních business pravidel (přímá souvislost se správností dat) Zpřesňování metadat Kontrola formální správnosti dat Statistika vývoje datové kvality v rámci DWH Hlavním cílem je dosáhnout spolehlivosti dat, tj. přesnosti a důvěryhodnosti. Jelikoţ spolehlivost dat je dána spolehlivostí zdrojů, je nutná pravidelná kontrola a monitoring. 43

3.1.1 Nástroje BI pro zajištění datové kvality Vzhledem k tomu, ţe data pro pokročilé analýzy pocházejí většinou z DWH, je datová kvalita DWH pro společnost zcela zásadní. Oddělení Business Intelligence má k dispozici pro zajištění kvality dat Data Quality Agreements, Alerting Systém a také Metadata repository. Prvotně je třeba začít se zavedením Data Quality Agreements. Jde o metodikami doporučovanou praxi data stewardship, tj. ustanovení správců či vlastníků okruhu datových objektů. Toto slouţí jako základ pro to, co chceme měřit a jak budeme měření vyhodnocovat (základ Alerting Systému). Následuje měření a vyhodnocení datových objektů v Alerting Systému a vizualizace vyhodnocení pro uţivatele. 3.1.1.1 Data Quality Agreements (DQA) Data Quality Agreements je písemná dohoda, která potvrzuje zodpovědnosti a specifikuje kritéria pro vyhodnocování kvality dat při přenosu z primárního systému do cílového systému, specifikuje vztahy mezi vlastníky, jejich rolemi a objekty, postupy pro odstraňování chyb, kontrolní a eskalační mechanizmy. Pro objekty definuje metriku, která je základem měření datové kvality. Písemné dohody jsou evidovány v databázi, ve které jsou dále udrţovány a vizualizovány. Je nutné si uvědomit, ţe DQA je standardem pro procesy, které transformují a dopravují informace uţivatelům. 44

Obrázek 15: Architektura DQA Zdroj: Interní dokumentace společnosti, vlastní úprava 45

Obrázek 16: Proces tvorby Data Quality Agreement Zdroj: Autor 46

DQA vytváří datový architekt ve spolupráci s vlastníkem dat v primárním systému a to vţdy, kdyţ vznikne nové rozhraní mezi primárním a cílovým systémem (datovým skladem). Termín pro finalizaci DQA je ukončení pilotního provozu nově vzniklého rozhraní. DQA se nevytváří v případě, ţe pro danou oblast jiţ DQA existuje, v tomto případě se pouze vytváří update stávající DQA. Data Quality Agreements jsou centrálně evidovány v oddělení Business Intelligence u metodika datové kvality. Pro vlastníky objektů se vytváří tzv. Karta vlastníka. Tuto kartu generuje aplikace na intranetových stránkách společnosti ve Wiki 35. Vlastník stvrzuje Kartu svým podpisem. V případě změny vlastnictví se generuje karta nová. Pro snazší vyplňování DQA vytvořilo oddělení BI pokyny, jak formuláře vyplnit. Vyplnění DQA je vedeno logicky tak, aby byly uvedeny všechny objekty v cílovém systému, které s rozhraním souvisí, včetně všech poţadavků na kvalitu přijímaných dat. Obrázek 17: Karta vlastníka pro Genesys systém Zdroj: Stránky společnosti, výstup provedený autorem (upraveno) 3.1.1.2 Alerting Systém [10] Software Alerting Systému je původním návrhem oddělení Business Intelligence a umoţňuje automatickou detekci nekvalitních dat. Měří datovou kvalitu na objektech databázového typu, kterými jsou např. číselníky, faktová data, atp. a také na objektech nedatabázového typu, coţ 35 Wiki jedná se o označení webů nebo hypertextových dokumentů umoţňující přidávat a měnit obsah podobně jako u internetových diskuzí, název wiki pochází z havajštiny a znamená rychlý 47

jsou vlastníci DQA změna jejich pozice či statusu. Alerting Systém měří i jednotlivé úrovně hierarchického systému (jednotlivé DQA jako celek, Reporty, ) 3.1.1.2.1 Objekty a charakteristiky Nejprve se z DQA přepisuje seznam objektů do definovaných schémat (např. seznam číselníků, faktových dat, error tables, jobů, souborů, atd.). Poté se naplňují tabulky, které zaznamenávají vztahy mezi objekty. 3.1.1.2.2 Parametry a pravidla Po naplnění tabulek následuje nastavení parametrů měření na základě DQA. Podle nadefinovaných pravidel zapisujeme do schémat parametry. Pro objekty databáze to jsou parametry pro správnost, včasnost a kompletnost dat. Pro měření můţeme vyuţít jiţ vytvořená pravidla a zároveň můţeme vytvářit pravidla nová. 3.1.1.2.3 Vizualizace Jednotlivá měření se ukládají do Measurement. Z něho systém vybírá jednotlivá měření na základě stanovených pravidel. Vyhodnocení je uţivateli zobrazeno ve Wiki, který je standardem pro zobrazování informací v prostředí internetu. Funguje na principu semaforu (zelená hodnoty v normě, ţlutá varování (warning), červená chyba (error)). Objektům, na které se měření vztahuje, jsou nastaveny parametry (pro kombinaci objekt x pravidlo), jsou prahové hodnoty: 2 hodnoty pro warning internal, pro interní pouţití IT, a external, business value pro uţivatele (ţlutá) 1 prahová hodnota pro error oblast (červená) 1 prahová hodnota pro OK business oblast (zelená) Vizualizace vyhodnocení naměřených hodnot je dána barevným označením (červená, ţlutá, zelená). Data, která jsou prezentována koncovému uţivateli, jsou vţdy spojena s údajem o jejich kvalitě. Uţivatel svojí volbou rozhoduje, zda jsou data s měřenými hodnotami pro jeho práci dostačující. Alerting Systém můţe být vyuţit v hierarchických systémech, takţe 48

můţeme měřit DQA jako celek nebo i Reporty. To znamená, ţe Alerting Systém šetří čas uţivatelům, kteří nemusí opakovaně spouště reporty, které jsou neúplné ale také zpracovatelům, kteří mohou lépe a cíleně řešit detekované problémy nebo těm, kteří vyuţívají data k dalšímu zpracování. Smyslem vizualizace Alerting Systému je monitorování datové kvality, signalizace problému směrem k primárním poskytovatelům dat i směrem ke zpracovatelům. 3.1.1.2.4 Metriky pro objekty Stav dat Správnost Včasnost Kompletnost DQA vlastníci Status Změna pozice vlastníka DQA 3.1.1.2.5 Měření datové kvality Měření datové kvality dělíme podle oblastí, veličin měření a výsledků vyhodnocení. Veškerá data ze seznamu je moţné si jednotlivě rozkliknout a zobrazit na stránkách společnosti ve wiki. Oblasti, na kterých je měření prováděno Zákaznická data Data ze zákaznických procesů Data o pouţití sluţeb Aktivace a nastavení sluţeb Finanční a fakturační data Informace o síti Měřené veličiny Správnost dat Úplnost dat 49

Včasnost dat Seznam měřených DQA Seznam otevřených výstrah alerting systému Seznam problémů Seznam upozornění (červená, ţlutá, zelená) Seznam splněných kontrolních pravidel Obrázek 18: Detaily objektu charakteristika včasnost pro systém REPA Zdroj: Stránky společnosti, výstup provedený autorem 50

Obrázek 19: Alerting Systém vizualizace ve wiki Zdroj: Stránky společnosti, uţivatelský výstup provedený autorem 3.1.1.3 Metadata Repository Současně s Alerting Systémem vytváříme Metadata Repository (popisy datových objektů včetně dalších podrobností). Správná a kompletní metadata jsou základem pro zajištění kvality dat. Enterprise Metadata Environment (EME) je součástí nástroje AB Initio a uchovává logy ze zpracování a můţe být customizován přidáním nových kategorií a pohledů. Analýza dopadů je významnou součástí ETL, abychom pochopili, jak ETL proces funguje. Výhody Enterprise Metadata Environment EME nám umoţňuje zjistit zpracování příslušných datasetů nebo souborů Zobrazení grafů se zvýrazněnými komponentami a datovými toky Inteligentní zobrazení analýz v grafickém módu Společně s instalačními procesy umoţňuje identifikovat, kdo a proč učinil příslušnou změnu 51

Obrázek 20: Enterprise Metadata Environment v nástroji Ab Initio Zdroj: Interní dokumentace společnosti 52

4. Reporting K vypracování této kapitoly jsem primárně vycházela z interních materiálů společnosti a informací od pracovníků oddělení Business Intelligence a také ze svých znalostí, jelikoţ jsem v minulosti pracovala jako analytik oddělení Demand Managementu a měla ve své odpovědnosti správu poţadavků na IT podporu. 4.1 Proces reportingu Poţadavky na vytvoření reportů jsou zadávány prostřednictvím formuláře Žádost o IT podporu neboli Request for Support to IT (dále jen RfS). Tento formulář neslouţí pouze pro poţadavky na nové reporty, ale pouţívá se také na jakékoliv jiné ţádosti na oddělení IT, které nepřesahují pracnost 40 MD 36, například se můţe jednat o poţadavek na novou aplikaci nebo úpravu stávajících systémů. Poţadavky, které překročí definovaný počet člověkodnů, se dále řeší jako projekty dle postupů a pravidel v rámci projektového řízení. Stávající proces ţádosti o IT podporu je popsán a vymodelován níţe. Jak je zřejmé, chybí v něm klíčová role schvalovatele business experta daného oddělení, který by měl poţadavek schválit ještě před Vice Presidentem (VP). 4.1.1 Stávající proces žádosti o report Zadavatel vytvoří poţadavek, který bude specifikován ve standardním formuláři, a poté jej e-mailem zašle ke schválení na svému VP, který mu poţadavek e-mailem schválí nebo neschválí. Pokud je poţadavek neschválen, vrací se zpět k zadavateli, pokud je schválen, zadavatel zašle RfS e-mailem na oddělení Demand Managementu (dále jen DM), o tomto kroku informuje svého VP. Analytik DM zkontroluje formální správnost daného poţadavku, pokud RfS nesplňuje definované náleţitosti, poţadavek je vrácen zadavateli k přepracování. O této skutečnosti Analytik DM informuje VP zadavatele. 36 MD = man-day neboli člověkoden znamená čas odpovídající práci jedné osoby po dobu jednoho pracovního dne 53

V případě formální shody je poţadavek zaregistrován v nástroji IBM Rational ClearQuest (dále jen ClearQuest) 37. Poté je uţivatel informován o registraci svého RfS. Na proces registrace navazuje proces Evaluace poţadavku na IT podporu. 37 IBM Rational ClearQuest je nástroj pro komplexní řízení změn softwaru. Nabízí sledování změn, automatizaci procesů, vytváření sestav a sledovatelnost ţivotního cyklu pro lepší viditelnost a řízení celého ţivotního cyklu vývoje softwaru". [on-line] [cit. 2011-04-01]. Dostupný z WWW: <http://www-142.ibm.com/software/products/cz/cs/clearquest/>. 54

Obrázek 21: Stávající proces ţádosti o IT podporu (Request for Support to IT - RfS) RfS vytvořen provádí zadavatel RfS Zaslání RfS VP útvaru zadavatele provádí zadavatel RfS Microsoft Outlook XOR RfS schválen VP RfS neschválen VP V Zaslání RfS na útvar DM provádí zadavatel RfS Microsoft Outlook RfS přijat na DM musí být informován VP útvaru zadavatele Kontrola správnosti RfS provádí analytik útvaru DM RfS splňuje definované náležitosti XOR RfS nesplňuje definované náležitosti Registrace RfS provádí analytik útvaru DM Vrácení požadavku zpět zadavateli k přepracování provádí analytik útvaru DM ClearQuest musí být informován VP útvaru zadavatele RfS zaregistrován musí být informován zadavatel RfS EVALUACE RfS Zdroj: Autor 55

4.2 BI Reporting, SAP Business Object, Hyperion V průběhu roku 2010 změnila společnost reportovací platformu a původní Oracle Discoverer byl nahrazen SAP Business Object. Při přechodu z původní Oracle platformy na Neteezu došlo k masivnímu zrychlení generování reportů. 4.2.1 ROLAP BI analytický reporting 4.2.1.1 SAP Business Objects SAP Business Objects 38 se pouţívá na přístup k datům uloţeným v EDW a umoţňuje analytický reporting za pouţití metody ROLAP (Relational On Line Analytical Processing). Tato metoda pracuje s daty jako v relační databázi, za pouţití SQL. V současnosti je na této platformě 240 aktivních reportů, které vyuţívá přibliţně 300 uţivatelů. Výhody SAP Business Objects Dokáţe zpracovávat velké objemy dat: Omezení ROLAP technologie je dáno omezením relační databáze, nad níţ ROLAP pracuje. Jinými slovy, ROLAP nemá ţádné omezení zpracovávaných objemů dat, Dokáţe posílit vyuţití funkcionalit, které jsou součástí relační databáze. Relační databáze jsou často dodávány s tzv. hostováním funkcionalit, jeţ umí ROLAP vyuţít s ještě větším účinkem, neţ relační databáze. Nevýhody SAP Business Objects Limitován funkcionalitou SQL, protoţe ROLAP se primárně opírá o SQL, můţe přinášet dlouhé generování odpovědí na dotaz 38 SAP Business Objects poskytuje komplexní řešení BI. Dostupný z WWW: <http://www.sap.com/cz/campaign/2010_05_cross_business_intelligence_rc/index.epx?url_id= CRM-CZ10-RDC-BBA>. 56

Obrázek 22: Aplikace SAP Business Object Zdroj: Interní dokumentace společnosti 4.2.2 Multidimenzionální OLAP reporting 4.2.2.1 Hyperion Essbase Hyperion Essbase (nyní Oracle) je pouţíván pro multidimenzionální OLAP reporting. V technologii MOLAP jsou data ukládána ve formě kostek, které mají mnoho dimenzí. Data nejsou ukládána ve formě relačních tabulek, ale v příslušném formátu. Pouţitá technologie je Hyperion Essbase a Hyperion Analyser. Přístup do Hyperionu vyuţívají především uţivatelé z oddělení financí (25 koncových uţivatelů). Výhody Velmi vysoce výkonné kostky jsou vytvořeny kvůli rychlému přístupu k informacím a jsou optimální pro operace slicing and dicing Dokáţe vykonávat komplexní výpočty: všechny výpočty jsou předgenerovány jiţ v době, kdy je kostka vytvářena 57

Nevýhody Má určitá omezení na mnoţství dat, které dokáţe zpracovávat: protoţe veškeré výpočty jsou prováděny v době, kdy se kostka vytváří, není moţné zahrnout velké objemy dat do kostky samotné Vyţaduje dodatečné investice: technologie kostek jsou často proprietární, vyţadují dodatečné diskové kapacity a další finanční investice a taktéţ investice do lidských zdrojů Obrázek 23: Princip multidimenzionální kostky Zdroj: Autor 4.3 ARDW (Analytical and Reporting Data Warehouse) ARDW je analytická část datového skladu vyuţívaná pro sloţitější analýzy. Umoţňuje uţivatelům vyuţívat sofistikované matematické/statistické metody pro sloţité analýzy dat. Pouţitou technologií je SAS Enterprise Guide a SAS Enterprise Miner. Tuto část datového skladu vyuţívá přibliţně 40 koncových zákazníků ze všech oddělení společnosti. 58

4.4 Chordiant (Campaign Management Tool) Chordiant Marketing Director (CMD) je sluţba pro plánování, řízení a vyhodnocování marketingových kampaní. Společně s ARDW umoţňuje uţivatelům vybrat vhodný seznam zákazníků, kteří mají být zahrnuti ve specifické kampani (na základě dat z EDW) a také zrealizovat kampaň s vyuţitím definovaných výstupních kanálů (SMS, MMS, e-mail, atd.) Po ukončení je moţno kampaň vyhodnotit a následně vykonat další kroky (například navýšit kredit na telefonu). V roce 2010 bylo v tomto nástroji provedeno 950 kampaní. Jelikoţ je nástroj na plánování a vyhodnocování kampaní jiţ zastaralý, rozhodla se společnost pro koupi nového produktu, který plně odpovídá současným trendům. Jedná se o nástroj SAS Marketing Automation, od společnosti SAS, který umoţní uţší propojení s ARDW. 4.5 Katalog Reportů Seznam všech pravidelně prováděných reportů je moţno nalézt v katalogu reportů ve wiki. Katolog reportů v současné době obsahuje přibliţně 1200 reportů, z nichţ zhruba jedna třetina je jiţ zrušených a jedna třetina se jiţ nevyuţívá, coţ znamená, ţe aktivních je cca 400 reportů. Reporty jsou rozděleny do kategorií, z nichţ majoritní část představují reporty finanční. 59

Obrázek 24: Katalog Reportů ve wiki Zdroj: Stránky společnosti, výstup provedený autorem (upraveno) Status reportů logika vyhodnocování Report se skládá z různých tabulek, které se měří v Alertingu. Z vyhodnocení stavu charakteristik jednotlivých tabulek se určí i stav reportu a to tak, ţe se propaguje ta nejhorší barva. Například je-li některá tabulka červená- pak i report je červený. 4.5.1 Typy reportů Poţadavky na reporty můţeme rozdělit do dvou skupin. Ad-hoc reporty pro jednorázový výběr dat bez opakování, většinou se jedná o sloţité komplexní analýzy, které jsou zpracovávány na základě poţadavků businessu Pravidelné reporty reporty, které si uţivatelé mohou spouště na pravidelné bázi, například provolané částky za měsíc pro určitý segment zákazníků 60