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:
Bc. Jana Hendrichová Informační Technologie a Management
Vedoucí práce:
Praha
doc. Ing. Bohumil Miniberger, CSc.
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
2.5
OLAP operace ................................................................................................... 24
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.9
3. 3.1
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
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
Koncept datové kvality ve společnosti .......................................................................... 43 Business Intelligence (BI) .......................................................................................... 43 3.1.1
4. 4.1
Nástroje BI pro zajištění datové kvality ............................................................ 44
Reporting ......................................................................................................................... 53 Proces reportingu ....................................................................................................... 53 5
4.1.1 4.2
Stávající proces ţádosti o report ........................................................................ 53
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
4.6 5.
Typy reportů ...................................................................................................... 60
Reporting a kvalita dat ............................................................................................... 61 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. 201102-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:
2
3
nestejná granularita
překlepy při pořizování dat
chybná metadata
implicitní a explicitní hodnoty „Null“
smíšení formátů struktur
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>. 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
5
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. 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 ISACA6.
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
7
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. 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 CobiT8 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:
.
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:
.
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:
.
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:
11
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
CleverAndSmart - ICT management [online]. 2011 [cit. 2011-04-06]. COBIT tajemství zbavený CleverAndSmart. Dostupné z WWW: .
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: .
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
15
Data Mining [online]. 2002 [cit. 2011-02-20]. Datové sklady a OLAP. Dostupné z WWW: . 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
Funkce Návrh databáze
Každodenní operace Entitně-relační základ, aplikačně orientovaný
Znalostní pracovník (manažer, analytik) Dlouhodobé informační požadavky, podpora rozhodování
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
Přednosti
Vysoký výkon, vysoká přístupnost
100 GB až TB Vysoká flexibilita, nezávislost koncového uživatele
Míry hodnocení
Propustnost transakcí
Propustnost dotazů a doba odezvy
Hvězda/sněžná vločka, věcná orientace
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. Codd16 a níţe uvádím jeho původních 12 pravidel OLAP.17
16
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
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) Foundation for Performance Measurement Home Page [online]. 1993 [cit. 2011-04-16]. Providing OLAP to User-Analysts. Dostupné z WWW: .
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: .
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ů PRODEJ Prodejka_ID
Zboží_ID
Účetní_období_ID
Prodejna_ID
Prodejce_ID
Poč_KS
Cena
1 2 3 4 5 6
13 22 18 13 54 17
8 8 8 8 8 8
3301 3302 3305 3307 3301 3307
4711 4563 5799 3566 4711 3566
10 35 47 6 21 7
12500 165270 1316 53940 9870 111860
Zdroj: Autor
20
DWHWorld, Online Data warehouse resource [online]. 2010 [cit. 2011-02-03]. DWH Schemas | DwhWorld. Dostupné z WWW: .
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
22
Wikipedie, otevřená encyklopedie [online]. 2011 [cit. 2011-04-17]. Data mining - Wikipedie. Dostupné z WWW: . 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: .
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
24
LOSHIN, David. Business Intelligence. San Francisco, CA 94111 : Morgan Kaufmann Publishers, 2003. 270 s. ISBN -13:978-1-55860-916-7. 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: .
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
29
VAVRUŠKA, Jindřich. ETL a kvalita dat. IT Systems [online]. 2003, 03, [cit. 2011-01-21]. Dostupný z WWW: . 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
30
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
Ab Initio: About AB Initio [online]. 2010, 02. [cit. 2011-02-11]. Dostupný z WWW:
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 Server31 – 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 Enabler33 a RTSP/IN34) 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í
a monitoring.
43
zdrojů,
je
nutná
pravidelná
kontrola
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 Wiki35. 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 MD36, 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: .
54
Obrázek 21: Stávající proces ţádosti o IT podporu (Request for Support to IT - RfS) provádí
RfS vytvořen
zadavatel RfS
Zaslání RfS VP útvaru zadavatele
provádí zadavatel RfS
Microsoft Outlook XOR
RfS schválen VP
RfS neschválen VP
V
provádí
Zaslání RfS na útvar DM
zadavatel RfS
Microsoft Outlook
musí být informován
VP útvaru zadavatele
RfS přijat na DM
Kontrola správnosti RfS
RfS splňuje definované náležitosti
provádí
analytik útvaru DM
RfS nesplňuje definované náležitosti
XOR
Vrácení požadavku zpět zadavateli k přepracování
provádí Registrace RfS
analytik útvaru DM
provádí
analytik útvaru DM
ClearQuest musí být informován
RfS zaregistrován
musí být informován zadavatel RfS
EVALUACE RfS
Zdroj: Autor 55
VP útvaru zadavatele
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 Objects38 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:
.
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
4.6 Reporting a kvalita dat Kvalita dat je nezbytným předpokladem reportingu. Data pouţívaná pro analýzy a následné reporty pocházejí z primárních systémů a jsou prostřednictvím ETL procesů převáděna do datového skladu ve strukturách vhodných pro analytické dotazování a tvorbu reportů. Kvalita dat v primárních systémech je různorodá a je zcela logické, ţe pokud data v primárních systémech jsou neúplná, obsahují duplicity a chybné údaje, pak i data v reportech nebudou validní. Reporty slouţí především pro podporu rozhodování managementu a chybnými údaji v reportech můţe dojít k nesprávným rozhodnutím. Kvalita reportů ve společnosti je zajištěna prostřednictvím:
dohod o kvalitě dat (DQA), které určují vlastníky či správce okruhu jednotlivých datových objektů v primárních systémech, definují pro ně metriky, které jsou pravidelně vyhodnocovány
alerting systému, který nám umoţňuje sledovat zpracování jednotlivých reportů a také kontroluje, zda jsou data v primárních systémech kompletní a byly v rámci ETL procesu zpracovány včas a bez chyb
automatizovaných a ručních kontrol v datovém skladu
tvorbou metadata repositáře, který umoţňuje zjistit detaily o zpracování příslušných datasetů nebo souborů v rámci ETL procesu
pravidelné aktualizace Katalogu reportů
definice a jednotného pouţívání údajů z datového slovníku v rámci různých reportů
61
5. Návrhy a doporučení Cílem této práce bylo navrhnout změny, které povedou ke zvýšení kvality reportingu ve společnosti. Nedílnou součástí těchto změn musejí být i kroky vedoucí k zajištění kvality dat v datovém skladu. Níţe uvádím stručný přehled konkrétních návrhů na zlepšení datové kvality a reportingu, jednotlivé návrhy jsou detailněji rozepsány v samostatných kapitolách.
Nový proces reportingu
Klíčová role vlastníka dat
Katalog reportů a jeho efektivní vyuţití
Business Analytik – Expert – v kaţdém oddělení společnosti
Vlastník reportu a jeho odpovědnost za další rozvoj reportu a korektnost dat
Zřízení role manaţera odpovědného za datovou kvalitu – klíčové v rámci zajištění kvality dat ve společnosti
Kritéria pro vyhodnocení úspěšnosti implementace daných změn
5.1 Nový proces reportingu Nový proces reportingu by měl splňovat tyto cíle:
Jasně srozumitelné reporty
Měl by se vyvarovat chybné interpretace informací
Opětovné vyuţívání reportů, eliminace duplicit, z čehoţ plyne důsledné dodrţování a updatování katalogu reportů
Větší sdílení informací – širší vyuţití reportů
Jednoduchá procedura ţádosti o report
Zvyšování kvality dat
Navýšení bezpečnosti informací
Datový sklad není jediný, kdo produkuje reporty. Z datového skladu se tvoří přibliţně 60% reportů, které vytváří IT oddělení. Zbytek reportů, 40%, si vytváří ostatní oddělení společnosti, buď přímo z primárních systémů nebo z externích zdrojů.
62
Kvalita dat je nezbytným předpokladem
reportingu. Veškerá data musí mít svého
vlastníka na straně businessu. Kvalita dat by měla být zajištěna skrz:
Data Quality Agreement, za podpory vlastníka dat, který garantuje obsah
administrátora aplikace, který zaručí korektní načtení dat
analytika datového skladu, který garantuje, ţe data v DWH jsou konzistentní
Na následující straně jsem vymodelovala návrh nového procesu reportingu, ve kterém je jiţ zahrnuto schvalování reportu business analytikem - expertem z jednotlivých oddělení. Pro lepší přehlednost jsem vloţila pouze část procesu s dopadem změn – aţ do schválení poţadavku VP, zbytek procesu je totoţný s původním. Celkové znázornění daného procesu je na přiloţeném CD.
63
Obrázek 25: Návrh nového procesu reportingu (část procesu s dopadem změn) Kontrola v Report Katalogu
provádí
Potenciální zadavatel RfS
XOR
Report v Katalogu již existuje
Report není obsažen v Katalogu
Žádost o přístup k datům
Specifikace požadavku na nový report (RfS)
provádí Zadavatel RfS
RfS vytvořen
Zaslání RfS na business experta ke schválení
provádí zadavatel RfS
Microsoft Outlook
XOR RfS schválen business expertem
RfS neschválen business expertem
Zaslání RfS VP útvaru zadavatele
V
provádí zadavatel RfS
Microsoft Outlook XOR
RfS schválen VP
RfS neschválen VP
Zdroj: Autor 64
V
5.2 Klíčová role vlastníka dat Vlastník dat je nominován na základě svých pracovních odpovědností a tato role musí být nezbytnou součástí jeho pracovní náplně. Vlastník dat poskytuje popis dat a ověřuje jejich správnost (pokud je to moţné), spolupracuje na řešení problémů s daty, ale nevytváří reporty.
5.3 Katalog reportů Veškerá data pouţívaná v reportingu musí být popsána v Datovém Slovníku. Veškeré reporty musí být popsány v Katalogu Reportů, vlastník reportu popíše report před jeho vlastní distribucí. Pokud někdo bude chtít nový report, nejdříve by se měl podívat do Katalogu Reportů, zda jiţ nějaký obdobný neexistuje. Velmi často se stává, ţe zadavatelé reportů posílají svoje poţadavky, aniţ by si ověřili, zda jiţ podobný report nebyl vytvořen.
Tím
zbytečně vyčerpávají zdroje oddělení reportingu, které by se mohly vyuţít na jiné aktivity.
5.4 Business Analytik – Expert Kaţdé oddělení společnosti by mělo mít minimálně jednoho experta - guru na DWH, coţ by měl být nejzkušenější business analytik v rámci oddělení. Jeho rolí by mělo být poskytování konzultací ohledně interpretace informací, poskytování pomoci se specifikací reportů a taktéţ by měl schvalovat poţadavky na nové reporty. Samozřejmě by měl také úzce spolupracovat s analytikem datového skladu. V současné době ne kaţdé oddělení takového guru má a poţadavky na reporty schvaluje pouze příslušný VP daného oddělení, coţ je v některých případech pouze formalita.
5.5 Vlastník reportu Vlastníkem reportu by měla být osoba, které definuje report a publikuje jeho definici v Katalogu Reportů. Je také odpovědný za další změny nebo další rozvoj daného reportu. Vlastník reportu taktéţ zajišťuje korektnost interpretace reportu.
65
5.6 Manažer datové kvality Společnost v současné době nemá obsazenou roli manaţera/specialisty na datovou kvalitu. Tato pozice byla před dvěma lety zrušena v rámci úsporných opatření a reorganizace organizační struktury oddělení Informačních technologií. Tento krok jistě nebyl šťastnou volbou, jelikoţ tato role je v rámci zajištění kvality dat velice důleţitá. Nyní se tato otázka začala opět diskutovat a tato role byla zřízena v útvaru IT Architektury a Bezpečnosti. Dle mého názoru by bylo vhodnější, aby tuto úlohu zastával pracovník z jiného oddělení a nikoliv z IT, aby byla zajištěna nezávislost. Doporučením můţe být útvar Financí nebo Controllingu. Manaţer datové kvality by měl mít odpovědnost za:
Dohlíţení na stávající DQA
Zajištění tvorby nových DQA
Komunikaci s vlastníky reportů
Vyuţívání a správu nástroje pro datovou kvalitu (wiki)
Kontrolu a vyhodnocování správnosti dat
5.7 Kritéria úspěšnosti implementace Podle pouţité metodiky pro Business Process Reengineering (BPR) bude potřeba po určité době od implementace navrhovaných změn vyhodnotit jejich přínos. K tomuto hodnocení budou pouţity následující nástroje a metriky:
Dotazníky spokojenosti uţivatelů – provedení dotazníku se stejnými otázkami před a po implementaci změn s předpokládaným zvýšením spokojenosti zákazníků o 5 procentních bodů
Statistika servisních poţadavků – očekáváme sníţení servisních poţadavků 3 měsíce po implementaci na méně neţ 50% hodnoty před implementací
Sníţení počtu poţadavků na nové reporty – efektivní vyuţívání jiţ vydefinovaných reportů obsaţených v katalogu reportů vedoucí k poklesu poţadavku na nové reporty o 20%
66
Závěr V této diplomové práci je zpracovávána problematika kvality dat v datovém skladu jako nezbytném předpokladu reportingu. Cílem této práce byl návrh na zlepšení datové kvality v podniku. V první části jsem se zaměřila na datovou kvalitu a její zabezpečení z hlediska procesního, další kapitola se zabývá komplexně datovým skladem. Ve třetí části popisuji koncept datové kvality ve společnosti včetně prostředků, kterými je kvalita dat zajišťována. Kapitola čtvrtá pojednává o reportingu jako takovém včetně procesu ţádosti o reporty, dále jaké druhy reportingu se ve společnosti provádějí a jaké konkrétní nástroje jsou k tomu vyuţívány. V poslední kapitole identifikuji konkrétní návrhy na zlepšení a následné kroky, které povedou k vyhodnocení úspěšnosti implementace. Cíl práce se podařilo naplnit v části analýzy stávajícího stavu datové kvality ve společnosti, kde byla identifikována slabá místa stávajícího stavu – jedná se zejména o neoptimální nastavení procesů, chybějící role, jejich obsazení a postavení ve společnosti. Dále se podařilo navrhnout postupy a aktivity, které povedou ke zlepšení datové kvality nejen v datovém skladu, ale i v primárních systémech společnosti. Navrţené změny ve finále povedou i ke zrychlení a zkvalitnění celofiremního reportingu, coţ je de facto primární cíl celé aktivity. Jako poslední krok jsem navrhla i metriky vedoucí k vyhodnocení úspěšnosti změn, jejichţ vyhodnocení by mělo být provedeno v horizontu 3 aţ 6 měsíců po implementaci změn. Z výše uvedených důvodů povaţuji celkový cíl práce za splněný. Vzhledem k tomu, ţe se v naší společnosti jedná o aktuální problém a existuje skutečná poptávka na řešení stávající neuspokojivé situace, povaţuji za reálné, ţe většina návrhů bude v nejbliţších měsících skutečně implementována a bude tak moţné po určité době přikročit i k reálnému vyhodnocení přínosu navrţených změn.
67
Seznam použité literatury Tištěné monografie [1]
KIMBALL, Ralph, CASERTA, Joe. The Data Warehouse ETL Toolkit. Indianapolis, IN 46256 : Wiley Publishing, 2004. 491 s. ISBN 0-7645-6757-8.
[2]
LACKO, Luboslav. Business Intelligence v SQL Serveru 2008 : Reportovací, analytické a další datové sluţby. Brno : Computer Press, 2009. 456 s. ISBN 978-80251-2887-9.
[3]
LOSHIN, David. Business Intelligence. San Francisco, CA 94111 : Morgan Kaufmann Publishers, 2003. 270 s. ISBN -13:978-1-55860-916-7.
[4]
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
[5]
OPPEL, Andrew. Databáze bez předchozích znalostí. Brno : Computer Press, 2006. 319 s. ISBN 80-251-1199-7.
[6]
UČEŇ, Pavel, et al. Metriky v informatice. Praha : Grada Publishing, 2001. 139 s. ISBN 80-247-0080-8.
[7]
VOŘÍŠEK, Jiří. Informační systémy a jejich řízení. Praha : Bankovní institut vysoká škola, 2007. 278 s. ISBN 978-80-7265-100-9.
Části tištěných monografií [8]
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-80254-5912-6.
[9]
MINIBERGER, Bohumil, SLAVÍK, Milan. Kvalita dat informačních systémů z pohledu jejího procesního zabezpečení. Sborník příspěvků Mezinárodní konference: Liberecké informatické fórum, Technická univerzita v Liberci, str. 65-75. Liberec 2010, ISBN 978-80-7372-656-0 68
[10] Interní dokumentace společnosti
Online zdroje (s uvedením autorů) [11] KYJONKA, Vladimír. Datová kvalita pod lupou. IT Systems [online]. 2006, 01. [cit. 2011-01-21]. Dostupný z WWW: < http://www.systemonline.cz/businessintelligence/datova-kvalita-pod-lupou-1.htm>. [12] 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_ri zeni_informacnich_systemu_2009.ppt [13] SLÁNSKÝ, David. Audit řešení datového skladu. IT Systems [online]. 2006 [cit. 201104-17]. Dostupný z WWW: . [14] TOBIŠEK, Roman. Kudy na řízení kvality dat. IT Systems [online]. 2009, 03. [cit. 2011-01-25]. Dostupný z WWW: < http://www.systemonline.cz/businessintelligence/kudy-na-rizeni-kvality-dat.htm>. [15] VAVRUŠKA, Jindřich. ETL a kvalita dat. IT Systems [online]. 2003, 03, [cit. 2011-0121]. Dostupný z WWW: .
Online zdroje (bez uvedení autora) [16] Ab Initio: About Ab Initio [online]. 2010 [cit. 2011-01-20]. What does AB Initio mean?. Dostupné z WWW: . [17] CleverAndSmart - ICT management [online]. 2011 [cit. 2011-04-06]. COBIT tajemství zbavený - CleverAndSmart. Dostupné z WWW: .
69
[18] Information Technology - Information Security – Information Assurance | ISACA [online]. 2009 [cit. 2011-04-06]. COBIT - IT Governance Framework - Information Assurance Control | ISACA. Dostupné z WWW: . [19] Data Mining [online]. 2002 [cit. 2011-02-20]. Datové sklady a OLAP. Dostupné z WWW: . [20] Data Warehousing: A Look at Business Intelligence and Data Warehouse [online]. 2011 [cit. 2011-02-11]. Snowflake Schema. Dostupné z WWW: . [21] Data Warehousing: A Look at Business Intelligence and Data Warehouse [online]. 2011 [cit. 2011-02-11]. Star Schema. Dostupné z WWW: . [22] DWHWorld, Online Data warehouse resource [online]. 2010 [cit. 2011-02-03]. DWH Schemas | DwhWorld. Dostupné z WWW: . [23] Foundation for Performance Measurement Home Page [online]. 1993 [cit. 2011-04-16]. Providing OLAP to User-Analysts. Dostupné z WWW: . [24] IBM - United States [online]. 2011 [cit. 2011-04-01]. IBM Rational Clerquest - Česká Republika. Dostupné z WWW: . [25] ITIL - Homepage [online]. 2007 [cit. 2011-03-30]. Dostupné z WWW: . [26] SAP Česká republika - SAP – Business Management Software Solutions Applications and Services [online]. 2011 [cit. 2011-04-11]. SAP Česká republika - ŘEŠENÍ BUSINESS INTELLIGENCE. Dostupné z WWW: .
70
[27] SAS | Business Analytics and Business Intelligence Software [online]. 2011 [cit. 201104-17]. Model Development and Deployment, Data Mining Software, SAS® Enterprise Miner™ | SAS. Dostupné z WWW: . [28] Sharper Focus Training -- ITSM and Business Process training on YOUR schedule!.[online]. 2010 [cit. 2011-04-01]. Dostupné z WWW: . [29] Vítá vás portál ManagementMania.com [online]. 2010 [cit. 2011-03-30]. Demingův cyklus (PDCA). Dostupné z WWW: . [30] 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-cmm-capabilitymaturity-model>. [31] Wikipedie, otevřená encyklopedie [online]. 2011 [cit. 2011-04-17]. Data mining Wikipedie. Dostupné z WWW: .
71
Seznam použitých zkratek (obrázků, grafů, tabulek, příloh) Seznam zkratek 1)
ARDW – Analytical and Reporting Data Warehouse
2)
BI – Business Intelligence
3)
CLV – Customer Lifecycle Value
4)
CMD – Chordiant Marketing Director
5)
CMM – Capability Maturity Model
6)
CobiT – Control Objectives for Information and Related Technology
7)
CRM – Customer Relationship Management
8)
DQA – Data Quality Agreement
9)
DWH – Data Warehouse
10)
EDW – Enterprise Data Warehouse
11)
EIS – Executive Information System / Electronical Invoices Store
12)
ERP – Enterprise Resource Planning
13)
ETL – Extraction Transformation Load
14)
ITIL – Information Technology Infrastructure Library
15)
HYP – Hyperion
16)
INV - Investigation
17)
MOLAP – Multidimensional On Line Analytical Processing
18)
ODS – Operational Data Store
19)
OLAP – On Line Analytical Processing
20)
OLTP – On Line Transaction Processing
21)
OPT - Optimalizer
22)
ROLAP – Relational On Line Analytical Processing
23)
MIS – Management Information System
24)
TPS – Transaction Processing System
72
Seznam obrázků Obrázek 1: Model zralosti organizace (Capability Maturity Model) Obrázek 2: Multidimenzionální kostka CobiT Obrázek 3: ITIL v3 Obrázek 4: CobiT framework Obrázek 5: Hierarchická struktura informačního systému podniku, zaloţená na vzájemně propojených datech Obrázek 6: Operace Roll up Obrázek 7: Operace Drill down Obrázek 8: Operace slicing - dicing Obrázek 9: Schéma hvězda Obrázek 10: Schéma sněhová vločka Obrázek 11: ETL Proces Obrázek 12: Prostředí BI/DWH Obrázek 13: Ab Initio – základní komponenty Obrázek 14: Netezza Performance Server Obrázek 15: Architektura DQA Obrázek 16: Proces tvorby Data Quality Agreement Obrázek 17: Karta vlastníka pro Genesys systém Obrázek 18: Detaily objektu – charakteristika včasnost pro systém REPA Obrázek 19: Alerting Systém – vizualizace ve wiki Obrázek 20: Enterprise Metadata Environment v nástroji Ab Initio Obrázek 21: Stávající proces ţádosti o IT podporu (Request for Support to IT - RfS) Obrázek 22: Aplikace SAP Business Object Obrázek 23: Princip multidimenzionální kostky Obrázek 24: Katalog Reportů ve wiki Obrázek 25: Návrh nového procesu reportingu (část procesu s dopadem změn)
73
Seznam tabulek Tabulka 1: Rozdíly mezi OLTP a OLAP Tabulka 2: Ukázka tabulky faktů
Seznam příloh Příloha 1: Proces tvorby Data Quality Agreement Příloha 2: Stávající proces ţádosti o IT podporu (Request for Support to IT - RfS) Příloha 3: Návrh nového procesu reportingu
74
