Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Sofistikované metody řízení kvality dat v podnikové praxi Diplomová práce
Autor:
Bc. Petr Šmejkal Informační technologie a management
Vedoucí práce:
Praha
doc. Ing. Bohumil Miniberger, CSc.
Leden, 2012
Čestné prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl 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ámen 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 28. června 2012
Petr Šmejkal
Poděkování Děkuji panu doc. Ing. Bohumilu Minibergerovi, CSc., vedoucímu mé diplomové práce, za cenné rady, odborné informace a věcné připomínky. Dále také děkuji svým současným i bývalým nadřízeným za to, že mi umožnili získat jedinečné zkušenosti a dovolili mi podělit se o ně v této práci. A v neposlední řadě děkuji své manželce Pavle za podporu při studiu.
Anotace Diplomová práce začíná vysvětlením významu základních pojmů (data, informace a kvalita). Pokračuje seznámením s principy a metodikami pro řízení informační kvality po procesní a teoretické stránce (TIQM, Kaizen, CoQ, Demingovy body). Práce dále analyzuje prostředky řízení a praktické přístupy k informační kvalitě v podnikových informačních systémech. Analýza je doplněna o vlastní postřehy a řadu příkladů, obrázků a ukázek zdrojových kódů z reálných projektů. Téma je rozděleno podle specifik primárních systémů, datových migrací a sekundárních systémů. Přístupy k datové kvalitě jsou kategorizovány jako proaktivní, restriktivní, reaktivní, represivní a destruktivní. Práce je zakončena zhodnocením rozhodnutí a postupů týkajících se datové kvality uplatněných na pěti reálných projektech. Data, Informace, Kvalita, Kontrola, Řízení, Informační systém. The thesis starts with explanation of basic concepts (data, information, quality) and continues with introduction to theoretical, process-oriented methods and principles of information quality management (TIQM, Kaizen, CoQ, Deming’s points). Further, there is an analysis of means of data quality management and practical approaches to quality in information systems. The analysis is supplemented with own observations, illustrations and source code examples. The topic is split in chapters by specifics related to primary systems, data migrations and secondary systems. Approaches to data quality are categorized as proactive, restrictive, reactive, repressive and destructive. The closing part of the thesis contains evaluation of decisions and actions taken towards data quality during five real projects. Data, Information, Quality, Control, Management, Information system.
Obsah Úvod ...................................................................................................................................................... 7 1 Kvalita dat ...................................................................................................................................... 9 1.1 Data, informace a znalosti ....................................................................................................................9 1.2 Informační a datová kvalita ............................................................................................................. 10 1.3 Významy kvality dat ............................................................................................................................ 11 1.4 Řízení kvality dat a informací.......................................................................................................... 12 2 Metodiky a principy ................................................................................................................ 13 2.1 Total Information Quality Management ..................................................................................... 13 2.2 Kaizen ........................................................................................................................................................ 15 2.3 Cost of Quality ........................................................................................................................................ 18 2.4 Analýza kvality dat ............................................................................................................................... 19 2.5 Demingovy body kvality .................................................................................................................... 20 2.6 CobiT .......................................................................................................................................................... 21 3 Zkoumané projekty ................................................................................................................. 23 3.1 Tesco Stores ČR a.s............................................................................................................................... 23 3.1.1 Competitive Pricing ....................................................................................................................... 23 3.1.2 Trading & Technical Law Pack .................................................................................................. 23 3.1.3 Data Entry Team ............................................................................................................................. 24 3.2 Petrom S.A. .............................................................................................................................................. 24 3.2.1 Master Data Store ........................................................................................................................... 24 3.3 Asekol s.r.o............................................................................................................................................... 24 3.3.1 AsIS ....................................................................................................................................................... 25 4 Kontrola a řízení kvality dat v primárních systémech................................................ 26 4.1 Úvod do problematiky ........................................................................................................................ 26 4.1.1 Informační systém .......................................................................................................................... 26 4.1.2 Evidenčně orientovaný IS ........................................................................................................... 26 4.1.3 Procesně orientovaný IS .............................................................................................................. 27 4.1.4 Časté typy chyb v informačních systémech ......................................................................... 28 4.1.5 Kategorizace přístupů................................................................................................................... 29 4.2 Proaktivní přístupy .............................................................................................................................. 29 4.2.1 Návrh datového modelu .............................................................................................................. 29 4.2.2 Master Data Management ........................................................................................................... 31 4.2.3 Change Request Management ................................................................................................... 32 4.2.4 User Experience............................................................................................................................... 32 4.3 Restriktivní přístupy ........................................................................................................................... 34 4.3.1 Úroveň vyhodnocování ................................................................................................................ 34 4.3.2 Technické prostředky ................................................................................................................... 35 4.4 Reaktivní přístupy ................................................................................................................................ 37 4.5 Represivní přístupy ............................................................................................................................. 38 4.5.1 Zajištění aktuálnosti a správnosti informací ...................................................................... 38 4.5.2 Ochrana osobních údajů .............................................................................................................. 38 -5 -
4.5.3 Hospodářské trestné činy a podvody ..................................................................................... 39 4.6 Destruktivní přístupy ......................................................................................................................... 40 4.6.1 Sběratelský přístup ........................................................................................................................ 40 4.6.2 Zpravodajský přístup .................................................................................................................... 40 4.6.3 Systém zápisníčku .......................................................................................................................... 41 4.6.4 Systém tužky a gumy ..................................................................................................................... 41 4.6.5 Hodnocení kvantity nad kvalitou ............................................................................................. 42 4.6.6 Eroze cílů ............................................................................................................................................ 42 5 Kontrola a řízení kvality dat při migracích ..................................................................... 45 5.1 Úvod do problematiky ........................................................................................................................ 45 5.2 Fáze a procesy datové migrace ....................................................................................................... 45 5.2.1 Analýza a mapování ....................................................................................................................... 45 5.2.2 Nástroje a příprava ........................................................................................................................ 46 5.2.3 Provedení a testování ................................................................................................................... 47 5.3 Data profiling .......................................................................................................................................... 47 5.4 Kontrolní reporty ................................................................................................................................. 50 5.5 Čištění a obohacování dat ................................................................................................................. 52 5.5.1 Automatické opravy ...................................................................................................................... 52 5.5.2 Rozpoznávání informací v nestrukturovaných datech................................................... 53 5.5.3 Obohacování dat z externích zdrojů ....................................................................................... 55 5.5.4 Fuzzy matching ................................................................................................................................ 56 6 Kontrola a řízení kvality dat v sekundárních systémech ........................................... 58 6.1 Úvod do problematiky ........................................................................................................................ 58 6.2 Nové výzvy pro datovou kvalitu .................................................................................................... 58 6.3 Metadata ................................................................................................................................................... 60 6.4 ETL: Extract, Transform, Load ........................................................................................................ 62 7 Vyhodnocení projektů ............................................................................................................ 63 7.1 Competitive Pricing ............................................................................................................................. 63 7.2 Trading & Technical Law Pack........................................................................................................ 63 7.3 Data Entry Team ................................................................................................................................... 64 7.4 Master Data Store ................................................................................................................................. 66 7.5 AsIS ............................................................................................................................................................. 68 Závěr .................................................................................................................................................. 71 Seznam použité literatury .......................................................................................................... 73
-6 -
Úvod Cílem diplomové práce je seznámení s principy a metodikami pro řízení informační kvality. Dále pak analýza prostředků řízení a přístupů k informační kvalitě v podnikových systémech, která je doplněná o vlastní postřehy a příklady. A v neposlední řadě zhodnocení rozhodnutí a postupů uplatněných na projektech, kterých jsem se účastnil. Během své profesní kariéry jsem se podílel na mnoha projektech, které se nějakým způsobem dotýkaly kvality informací. Úspěch některých projektů na kvalitě zpracovávaných informací přímo závisel, jiné projekty se cíleně snažily o zlepšení informační kvality v podniku a další, zejména migrační nebo integrační projekty, byly příležitostí pro zkoumání kvality dat a hledání způsobů nápravy nedostatků. Bez formálního vzdělání zaměřeného na řízení kvality jsem byl odkázán pouze na znalost základních principů informačních technologií, zdravý rozum a poučení od kolegů. Důležitost a význam kvality informací jsem samozřejmě vnímal, ale řešení a řízení kvality jsem prováděl spíše intuitivně než metodicky. V posledních letech jsem se zaměřil na projekty datových migrací a návrhu nebo správy datového modelu operativních informačních systémů. Téma diplomové práce Sofistikované metody řízení kvality dat v podnikové praxi je mi tedy velmi blízké a byla to jasná volba hned z několika důvodů. Mám zkušenosti, které bych mohl při psaní této práce zúročit. Je to příležitost získat nové znalosti v oboru, kterým se zabývám. Chtěl bych nově nabyté vědomosti využít pro vyhodnocení své dosavadní práce a odhalit chyby, kterých jsem se mohl dopustit, nebo naopak potvrdit si svá správná rozhodnutí. A v neposlední řadě je pro mne téma datové kvality natolik zajímavé, že bych v této oblasti chtěl dále rozvíjet svou pracovní kariéru. Paleta typů informačních systémů v podniku je velice široká a popsat všechny aspekty informační kvality z pohledu každého druhu podnikového systému by překročilo stanovený rozsah diplomové práce. Rád bych se tedy zaměřil na řízení kvality při vzniku a pořizování dat a související kontrolu kvality při datových migracích. Řízení kvality v datových skladech a aspekty kvality informací z pohledu business intelligence uvedu pouze okrajově, protože v podchycení kvality informací v primárních systémech vidím největší přínos a také na témata spojená se sekundárními systémy byly v minulých letech vypsány jiné diplomové práce jako např. Kvalita dat v datovém skladu – nezbytný předpoklad reportingu. Při vypracovávání diplomové práce jsem nejprve provedl rešerši dostupných zdrojů informací a literatury. V rejstříku Národní technické knihovny jsem našel odkaz -7 -
na seriál o datové kvalitě od Milana Kučery v časopise Computerworld. Tyto články mě nasměrovaly na další související témata a především na práci Larryho Englishe. Shrnutí nalezených poznatků, principů a metodik je obsahem kapitoly 2. Na základě získaných teoretických poznatků jsem v dalších kapitolách kategorizoval a popsal přístupy k řízení kvality dat. Dílem jsem vycházel z vlastních zkušeností a vlastního pozorování, dílem jsem rozpracoval přístupy zmíněné v použité literatuře, zejména knihách Davida Loshina, a některé jsem doplnil o vlastní příklady z praxe. V závěrečné kapitole jsem popsal a vyhodnotil vybrané projekty, kterých jsem se v různých rolích účastnil. Hodnocení projektů jsem provedl jako porovnání skutečných rozhodnutí a skutečně provedených činností s doporučeními, která vyplývají z metodik a principů řízení kvality informací.
-8 -
1
Kvalita dat Na začátku každého projektu bývá poměrně užitečné vymezit si základní pojmy a
vytvořit tak společný výkladový slovník, aby nedocházelo mezi účastníky projektu k nedorozuměním plynoucím z jejich odlišného pohledu na věc nebo z jejich odlišného profesního původu. Protože tuto diplomovou práci lze také považovat za určitý druh projektu, pokládám za vhodné začít podobným způsobem s vymezením základních pojmů.
1.1 Data, informace a znalosti Slova „data“ a „informace“ bývají často považována za synonyma a stejně tak často se prolíná význam slov „informace“ a „znalosti”. Podíváme-li se do známých anglických výkladových slovníků, zjistíme, že pro výklad jednoho slova je užito druhé. Cambridge Dictionary's definition of data1 information, especially facts or numbers, collected to be examined and considered and used to help decision-making, or information in an electronic form that can be stored and processed by a computer Merriam-Webster's definition of information2 - the communication or reception of knowledge or intelligence - knowledge obtained from investigation, study, or instruction; intelligence, news; facts, data - a signal or character (as in a communication system or computer) representing data; something (as a message, experimental data, or a picture) which justifies change in a construct (as a plan or theory) that represents physical or mental experience or another construct - a quantitative measure of the content of information, specifically: a numerical quantity that measures the uncertainty in the outcome of an experiment to be performed Odlišnost mezi daty, znalostmi a informacemi se projeví, začneme-li uvažovat nad jejich účelem a vzájemnými souvislostmi. Data Pro účely této diplomové práce budeme data chápat jako údaje, které vyjadřují skutečnosti z reálného světa, ve strukturované formě schopné uchování, přenosu, interpretace a zpracování. Budeme o nich uvažovat především na technologické úrovni a
1 2
Cambridge University Press. Data. British English Dictionary & Thesaurus. [online] Merriam-Webster. Information. Dictionary and Thesaurus. [online]
-9 -
zajímavá pro nás bude jejich syntaktická stránka. V rámci této diplomové práce nás budou zajímat data uložená v databázi, zpracovatelná výpočetní technikou. Data jsou surovinou, z níž lze vytvořit nebo získat informace. Hodnotu dat lze stanovit právě na základě hodnoty informace. Informace Informaci budeme chápat jako význam nebo obsah dat, sdělitelný poznatek, který má pro příjemce určitý smysl, snižuje nejistotu a umožňuje rozhodování. Zajímá nás tedy sémantická stránka. Schopnost získat správné a užitečné informace je v dnešní době naprosto klíčová jak pro jednotlivce, tak pro firmy. Znalosti Znalosti můžeme chápat jako zkušenostmi a vzděláním podpořený výsledek pochopení dat a informací, jejich umístění do souvislostí vytvořením abstraktního a generalizovaného modelu. Je zřejmé, že kvalitní data a informace jsou základem pro vznik dobrých a správných znalostí, nicméně proces vytváření znalostí, znalostní management a znalostní systémy jsou nad rámec této diplomové práce.
1.2 Informační a datová kvalita Vzhledem k výše stanovenému vymezení pojmů bychom mohli dovodit rozdíl mezi informační a datovou kvalitou i přesto, že vymezení samotného pojmu „kvalita“ si necháme do další kapitoly. Řízení datové kvality by striktně vzato mohlo být chápáno pouze jako vyhodnocování a ovlivňování způsobu uložení a zpracovatelnosti samotných údajů, hodnocení a řešení problémů např. přesnosti, úplnosti a konzistence dat v databázi. Při projektu zavádění řízení datové kvality se typicky jedná o technologické řešení buď v rámci užívaného informačního systému, nebo integraci s novým specializovaným nástrojem. Řízení informační kvality by potom navíc k řízení datové kvality mohlo přidat řízení firemních procesů pořizování a využívání dat a zahrnovalo by i uživatele a metodiku práce. Typický projekt zavádění řízení informační kvality by pak zahrnoval i reengineering podnikových procesů a návrhy na změny ve způsobu užívání informačního systému. V praxi se však pojem „informační kvalita“ příliš nerozšířil a hovoříme tak pouze o datové kvalitě, i když máme zájem o kvalitu informační. Je zřejmé, že dlouhodobě
- 10 -
kvalitních podkladů pro fungování a rozhodování firmy lze dosáhnout jedině přes efektivní firemní procesy a proto i v této diplomové práci pod pojem „kvalita dat“ zahrnu i kvalitu informací.
1.3 Významy kvality dat Kvalita je podle normy ISO 90003 definována jako stupeň splnění požadavků souborem inherentních charakteristik. Jaké požadavky je třeba klást v případě, že mluvíme o kvalitě dat nebo informací nám nejlépe řeknou osvědčené metodiky. David Loshin uvádí4 čtyři dimenze kvality dat: Accuracy – Přesnost – míra do jaké data souhlasí s reálným zdrojem správné a původní informace. Completeness – Úplnost – předpoklad, že údaj, záznam nebo datový zdroj obsahují všechny očekávané informace. Consistency – Konzistentnost – předpoklad, že vztažené údaje nejsou vzájemně v rozporu z hlediska hodnot, času nebo pravidel. Currency/Timeliness – Včasnost – znamená aktuálnost údajů i jejich dostupnost v okamžik, kdy jsou potřeba. Mluvíme-li o informacích a ne jen o datech, je důležitým kritériem užitečnost informace, která zahrnuje relevantnost (významnost informace pro daný účel), podrobnost (přiměřený detail) a srozumitelnost (vhodnost formy pro daný účel). Pro řízení kvality informací je nutné vnímat rozdíl mezi slovy „přesnost“ a „správnost“ informace5. Údaj považujeme za správný (též užíváme slovo validní) pokud vyhovuje stanoveným pravidlům – vyhodnocujeme jeho formát či obsah a můžeme toto vyhodnocení automatizovat. Validní údaj však ještě nemusí být přesný. Číslo „FD2012001234“ může vyhovovat nastaveným pravidlům pro číslování faktur došlých, ale neznamená to, že taková faktura musí existovat. Obdobně adresa „Petr Šmejkal, Horní 99, 123 45 Dolní Lhota“ vypadá správně, ale neznamená to, že mě na této adrese zastihnete. Přesnost je možné ověřit pouze fyzickým zjišťováním proti původnímu zdroji informace, proti realitě.
ČSN EN ISO 9000:2006 Systémy managementu kvality – Základní principy a slovník LOSHIN David. Business Intelligence. Morgan Kaufmann, 2003. 5 KUČERA Milan. Kvalita informací (3): Přesnost vs. správnost. Computerworld. 2008, č. 13, s. 32-33. 3 4
- 11 -
1.4 Řízení kvality dat a informací Řízení obecně je popisováno jako proces ovlivňování chování soustavy za určitým cílem. Naším cílem bude zvýšení a udržení kvality informací s přiměřenými náklady. Nejprve bude nutné najít vhodné metriky popisující stav soustavy a prvky, na které budeme působit. Na co se zaměřit nám ukáží osvědčené metodiky pro celkové řízení kvality obecně a kvality informací specificky.
- 12 -
2
Metodiky a principy Řízení kvality dat se v mnohých případech omezí na jednorázovou analýzu a
vyčištění dat nebo na trvalé nasazování opravných mechanizmů, protože se takové řešení zdá býti relativně jednoduché, rychlé a levné, avšak neúčinné. Problémy nelze trvale odstranit bez zavedení a dodržování principů řízení kvality a nastavení odpovědnosti každého zaměstnance. Postupnými krůčky lze dosáhnout částečného zlepšení, ale pouze komplexní a holistický přístup, s pomocí osvědčených metodik, poskytne firmě tolik potřebnou úsporu a konkurenční výhodu.
2.1 Total Information Quality Management Metodiku TIQM vytvořil Larry English aplikací v průmyslové výrobě dlouhou dobu úspěšně užívaných principů řízení kvality na produkt „informace“. Jedná se především o principy E. W. Deminga, které jsou shrnuty do tzv. „14 bodů kvality“ a které blíže rozebereme v následující kapitole. Dalším zdrojem inspirace pro TIQM je přístup Kaizen, kterému se také ještě budeme věnovat později. Hlavním odlišujícím faktorem6 metodiky TIQM je, že je vystavěna kolem základních principů řízení kvality dat a jejich aplikaci na informaci a ne nad nějakou konkrétní technologií nebo kolem metod používaných pro zajištění kvality dat. TIQM se zaměřuje na ekonomickou stránku dopadů nekvalitních informací a umožňuje vytvořit business case zdůvodňující potřebu řešení problémů s nekvalitou dat a informací. Vyčíslení ztráty v prodejích nebo ve zbytečných nákladech je mnohem větší motivací než pouhé zjištění, že v databázi je nějaké procento chybných záznamů. Metodika je tvořena pěti základními procesy zaměřenými na analýzu a ohodnocení, opravu a zlepšování a dále zastřešujícím procesem. Schéma procesů a jejich popisy jsou převzaty z anglického článku7.
6 7
KUČERA Milan. Kvalita informací (2): Metodika TIQM. Computerworld. 2008, č. 12, s. 31. ENGLISH Larry. Total Information Quality Management – A Complete Methodology for IQ Management. Information Management. [online]
- 13 -
P6 Vybudování prostředí pro kvalitní informace P4 Oprava a restrukturalizace dat P1
P2
P3
Posouzení kvality definic dat a informační architektury
Analýza kvality informací
Vyčíslení rizik a nákladů z nekvalitních informací
P5 Zlepšování kvality informačních procesů
Obrázek 1: Schéma procesů metodiky TIQM8
P1 Analýza kvality definic a informační architektury Proces popisuje způsob měření kvality definice dat, zda odpovídá potřebám odborných pracovníků9, zda vědí, co potřebují vědět a zda rozumějí významu informací, které potřebují pro svou práci. Dále proces popisuje jak vyhodnotit stálost, pružnost a znovu použitelnost návrhu datového modelu databáze nebo datového skladu. P2 Analýza kvality informací Proces popisuje způsob měření kvality informací, zda odpovídá požadovaným charakteristikám jako přesnost, úplnost, validita, nezdvojenost a konzistentnost. Měří se buď stav informační kvality v databázi nebo v souboru dat, nebo informační kvalita výstupu procesu. P3 Vyčíslení rizik a nákladů z nekvalitních informací Tento proces popisuje jak sestavit business case pro řízení informační kvality. Změřením nákladů ze selhání procesu, mylných informací, nutnosti předělávat práci, znepřátelení zákazníků, ztrátu obchodu a příležitostí dostaneme hodnoty, které můžeme srozumitelně prezentovat vedení společnosti. P4 Oprava a restrukturalizace dat Proces popisuje jak provádět korekce dat, transformace informací nebo jak řídit procesy konverze či přesunu dat do datových skladů. Proces opravy dat není prováděn
Vlastní úprava obrázku z ENGLISH Larry. Total Information Quality Management – A Complete Methodology for IQ Management. Information Management. [online] 9 V originále „knowledge workers“ také překládáno jako „znalostní pracovníci“ 8
- 14 -
samostatně, ale zároveň s procesem P5, aby bylo zamezeno znovu vytváření nekvalitních dat. Korekce dat z pohledu řízení kvality informací by měla být pouze jednorázová. P5 Zlepšování kvality informačních procesů Tento proces je zcela zásadním procesem, abychom mohli metodologii nazývat metodologií pro řízení kvality. Proces je založen na PDCA10 cyklu a popisuje osvědčenou a prověřenou techniku zlepšování popsanou Walterem Shewhartem, kterou ve svých pracích užívá W. Edwards Deming, Joseph Juran, Masaaki Imai (v systému kvality Kaizen) i jiné systémy pro řízení kvality dat. Trvalé opravení vadných obchodních11 a rozhodovacích procesů, které jsou příčinou nekvalitních dat, nutnosti předělávek a dalších ztrát, má pro společnost největší přínos. P6 Vybudování prostředí pro kvalitní informace Zastřešující proces P6 je zaměřen na provádění konkrétních a mnohdy i dost zásadních změn v celé organizaci s cílem postupně implementovat a udržet všech čtrnáct bodů informační kvality (viz kapitola Demingovy body kvality). Změna firemní kultury a způsobu smýšlení zaměstnanců a jejich vztahu ke kvalitě informací je úkol náročný a dlouhodobý.
2.2 Kaizen V Japonštině slovo „kaizen“ (改善) znamená „zlepšení“ nebo „změna k lepšímu“ a do souvislosti s řízením kvality jej roku 1986 uvedl Masaaki Imai ve své knize „Kaizen: The Key to Japan’s Competitive Success“. Kaizen je chápán12 jako proces trvalého pozvolného zlepšování – postupné a soustavné zavádění malých změn vedoucích ke zlepšení, na kterém se podílejí všichni zaměstnanci. Naproti tomu stojí „inovace“ jako náhlá, jednorázová a výrazná změna v organizaci provedená úzkou skupinou lidí.
PDCA – Plan, Do, Check, Act – plánuj, udělej, zkontroluj, jednej Anglické termíny „business rule“ a „business process“ jsem se rozhodl překládat jako obchodní pravidla a obchodní procesy i přes nedokonalost překladu, který plně nevystihuje širší význam slova „business“ zahrnující nejen vlastní činnosti vedoucí ke směně zboží a služeb, ale i všechny ostatní činnosti naplňující účel existence ekonomického subjektu. 12 KUČERA Milan. Kvalita informací (5): Kaizen - proces trvalého zlepšování. Computerworld. 2008, č. 15, s. 31-32. 10 11
- 15 -
Inovace
Kaizen
dace
Kaizen
dace
Inovace
Inovace
degra
Inovace
degra
čas
čas
Obrázek 2: Porovnání vlivu degradace a Kaizen na přínos inovací13
Při dlouhodobějším pozorování přínosu inovací zjistíme, že jejich efekt se v čase snižuje. Samotná inovace tedy neznamená trvalé zlepšení, ale vlivem zastarávání, zapomínání a šíření chyb dochází k postupnému snižování nastaveného standardu. Kaizen mění vnímání pracovní náplně zaměstnanců, protože místo pouhého dodržování postupů je každý zaměstnanec motivován aktivně se podílet na zlepšování kvality. Takový přístup vyžaduje zcela minimální investice do technologií, ale jeho přínos se bude projevovat postupně. Pro zajištění optimálního efektu je tedy vhodné kombinovat inovace a Kaizen. Japonské slovo „gemba“ (現場) značí reálné místo, ve kterém dochází k určité aktivitě. V našem kontextu to je místo vytváření nebo produkce dat, místo, kde např. zaměstnanci primárně sbírají, vytvářejí a aktualizují informace o zákaznících14. Takovéto místo by mělo být ve středu zájmu jak zaměstnanců, tak managementu. Princip Gemba Kaizen říká, že při zjištění problému s kvalitou je nutné jít na místo vzniku informace nebo ke zdroji produktu. Vyhodnocování nebo řešení kvality informací až např. v datovém skladu nevyřeší původní příčinu vzniku nekvalitních dat. Sledování a analýzou aktivit v Gemba je možné získat potřebné podklady k tomu, abychom byli schopni provést odpovídající opatření zamezující vzniku defektů. Podle principu Gemba Kaizen se tedy zaměřujeme na procesní manuály, formuláře, obrazovky počítačů a další prostředky, které se používají k získávání informací. Také je nutné ověřit a zajistit, že jednotlivé části informací jsou obsluze zřejmé, že jsou nastavena jasná pravidla užití a povolené hodnoty, že existují procedury pro zamezení vzniku chyby.
Vlastní úprava obrázku z KUČERA Milan. Kvalita informací (5): Kaizen - proces trvalého zlepšování. Computerworld. 2008, č. 15, s. 31-32. 14 KUČERA Milan. Kvalita informací (6): Gemba Kaizen. Computerworld. 2008, č. 16, s. 33. 13
- 16 -
Analýza příčin je jedním z důležitých nástrojů v oblasti řízení kvality a právě odstranění příčin a ne jen následků, je cestou k úspěchu. Japonské slovo „muda“ (無駄) znamená plýtvání. V rámci různých metodologií řízení15 se rozlišují aktivity na ty, které přinášejí hodnotu a na ostatní, které představují některou z následujících sedmi základních a dalších rozšiřujících kategorií Muda:16 Defects – Vady a chyby – chyby při zadávání dat, chyby při zpracování dat, vadné návrhy systémů. Overproduction – Nadvýroba – vytváření něčeho, co vlastně ani není požadováno nebo se ještě bude měnit, výroba jen podle rozvrhu a ne aktuální poptávky. Inventories – Zásoby – nákup nebo výroba věcí předtím, než jsou potřeba, věci čekající ve frontě nebo přihrádce, nepřečtená pošta, dávkové zpracování. Over-processing – Vícepráce – spoléhání na kontrolu místo eliminace příčiny chyb, zadávání dat do několika systémů, vytváření zbytečných výkazů, těžkopádné firemní procesy, popohánění procesů. Human motion – Pohyb – procházky k tiskárnám, kopírkám, mezi kancelářemi, na cigaretku, hledání chybějících informací, nutnost přepínat mezi mnoha obrazovkami. Transportation and handling – Doprava a manipulace – přesuny papírových nebo elektronických dokumentů, schvalovací kolečka, nadměrné využívání příloh emailů nebo adresátů v kopii. Waiting – Čekání – pomalé počítače nebo aplikace, prostoje a odstávky, čekání na vysvětlení, informace, schválení nebo opravu. Confusion – Zmatení – nejistota, nepřehlednost, chybějící nebo mylné informace, nejasnost nebo nejednoznačnost procesů nebo definic. Unsafe or unergonomic – Nebezpečí nebo nepohodlí – pracovní podmínky v kanceláři vedoucí k bolestem očí, zad nebo jinak vedoucí ke snížení produktivity. Underutilized human potential – omezování vlastní zodpovědnosti zaměstnanců, rutinní práce odborných pracovníků, neposkytování vhodných nástrojů, nedůvěra k podřízeným.
15 16
Toyota Production System, Lean, Six Sigma Systems2win. Muda - The 7 Types of Waste. [online]
- 17 -
Kategorie Muda jsou vhodným začátkem pro hledání příčin problémů s kvalitou informací a zároveň navádějí k řešení.
2.3 Cost of Quality Analýza nákladů na nekvalitní informace17 neznamená pouhou inspekci validity dat – např. že 20% adres vykazuje určité defekty – ale poskytne pro management mnohem zajímavější údaje – např. že z důvodu nepřesnosti 20% adres má firma nadbytečné náklady ve výši půl milionu Kč. Systém ekonomického hodnocení kvality informací navíc dokáže i objektivně vyhodnotit dopady provedených nápravných a preventivních opatření. Systém CoQ je tvořen třemi kategoriemi nákladů: P – Prevention – náklady související s prevencí nekvality informací. A – Appraial – inspekční náklady na zjištění souladu informací. F – Failure – náklady na selhání z nekvalitních informací, dále se dělí na interní (výrobní, před dodáním zákazníkovi) a externí (servisní, po dodání zákazníkovi). Zjištění nám pomohou vytvořit model optimálních nákladů na kvalitu. Podle tradičního modelu18 jsou náklady na selhání inverzní k nákladům na prevenci. Optimální náklady jsou na takové úrovni kvality, kde celkové náklady jsou minimální. Situaci
Minimum
zjednodušeně ilustruje Obrázek 3.
Náklady
Celkové náklady na kvalitu Ná kla d
100% Defektů
ys
elh á
ní
en ev Pr
Úroveň kvality
n ní tiv
lad ák
y
0% Defektů
Obrázek 3: Optimální náklady na kvalitu (vlastní úprava)
KUČERA Milan. Kvalita informací (8): Analýza nákladů na nekvalitní informace. Computerworld. 2008, č. 18, s. 49. 18 Brown a Kane, 1984 17
- 18 -
2.4 Analýza kvality dat Abychom mohli zahájit aktivity vedoucí k eliminaci nekvalitních informací, musíme nejprve zjistit jejich stav. Zjišťování stavu je však nutné založit na celkové analýze prostředí s cílem určení způsobu řízení kvality informací ve společnosti a následné identifikaci dopadů nekvalit na efektivnost firemních procesů19. Zredukování analýzy kvality dat na profiling a nápravných opatření na automatické opravy je v rozporu s Demingovým bodem číslo 3, přináší další náklady a v konečném důsledku nic neřeší. Podle metodiky TIQM je potřeba identifikovat kritické informace a jejich provázanost s procesy, vyhodnotit správnost i přesnost informací, identifikovat dopady nekvalitních informací na procesy, sestavit CoQ systém, provést odhad návratnosti investice do zlepšování kvality informací a zahájit zlepšování kvality informací úpravou firemních procesů a školením. Datový profiling je vhodným nástrojem pro vyhodnocení správnosti dat. Je možné využít některý z dostupných programů nebo jen provést vlastní zjišťování např. několika SQL dotazy do databáze. Surové výsledky je vhodné upravit do formy, kterou je možné prezentovat managementu, nebo do formy vhodné pro uživatele, aby mohli zahájit opravu údajů. Přesnost dat není možné ověřit automaticky, protože ta musí být prováděna fyzickou kontrolou a porovnáním se skutečností. Mezi aktivity patřící k analýze kvality informací se řadí i kontrola kvality referenčních tabulek a číselníků, kontrola definic jednotlivých informací a kontrola popisu obchodních pravidel. Vše s ohledem na překrývání, redundanci, srozumitelnost, jednoznačnost a konzistenci napříč organizací. Analýza kvality informací by měla odpovědět na otázky:20 Jakými chybami jsou dotčeny nefungující procesy? Jaké jsou náklady způsobené nekvalitními informacemi? Jsou rozhraní mezi systémy navrženy a implementovány korektně? Nedochází v některých systémech k nežádoucí erozi dat?
KUČERA Milan. Informační kvalita v praxi (4): Analýza kvality dat a čištění dat. Computerworld. 2009, č. 7, s. 33. 20 KUČERA Milan. Informační kvalita v praxi (5): Korektní přístup k analýze kvality informací. Computerworld. 2009, č. 12, s. 30. 19
- 19 -
2.5 Demingovy body kvality William Edward Deming roku 1986 ve své knize „Out of the Crisis“ formuloval čtrnáct klíčových bodů21 pro manažery, kteří chtějí transformovat společnosti k větší efektivitě a produktivitě. Tyto principy daly základ metodice TQM na níž TIQM navazuje. 1) Vytvořit trvalý zájem na zlepšování kvality produktů a služeb. 2) Přijmout novou filozofii pro nový ekonomický věk a nové výzvy – osvojit si požadavky na vysokou kvalitu sdílených informací jako prostředku pro zajištění efektivnosti a snižování nákladů. 3) Upustit od trvalé kontroly jako nástroje pro dosažení kvality – místo závislosti na nákladné kontrole vytvářet rovnou kvalitní informace. 4) Hodnotit podle celkových nákladů místo pouhé cenovky – při vývoji informačních systémů neklást důraz pouze na cenu a termín na úkor kvality. Následné nutné opravy, korekce a nespokojenost zákazníka domnělé počáteční výhody potlačí. 5) Trvale zlepšovat výrobu, služby a procesy. Zvyšovat kvalitu a produktivitu a tímto způsobem snižovat náklady. 6) Zavést školení kvality na pracovištích pro všechny zaměstnance. 7) Chápat roli manažera jako vůdce a ne dozorce a jasně definovat odpovědnost všech zaměstnanců za kvalitu. 8) Zbavit zaměstnance strachu a umožnit jim efektivně pracovat. 9) Odstranit překážky mezi lidmi a útvary, aby všichni mohli volně komunikovat, rozuměli potřebám druhých a fungovali jako jeden tým. 10) Upustit od sloganů a pobídek k nulové chybovosti a maximální výkonosti budících soupeřivost a pocit, že nízká kvalita je součástí výroby a tudíž mimo vliv pracovníků. 11) Nehodnotit podle výkonnostních norem a množstevních cílů bez ohledu na opravdový přínos a kvalitu. 12) Vytvořte prostředí, kde pracovníci mohou být hrdí na své dovednosti a profesionalitu. Neničte jej striktním dohledem a řízením. 13) Povzbuzujte zaměstnance k účasti na vzdělávacích akcích, školeních a sebevzdělávání. 14) Zapojte do transformace všechny zaměstnance. Ač tyto principy byly navrženy pro zvyšování produktivity a efektivity průmyslové výroby nebo poskytovaných služby, lze je bez problému adaptovat do oblasti dat a informací, pokud informace chápeme jako specifický druh produktu.
21
W. Edwards Deming. Wikipedia. [online]
- 20 -
Při pochopení významu těchto transformačních bodů jsme schopni jednoznačně identifikovat přínosy a nedostatky různých řešení a přístupů v oblasti řízení kvality informací. Dle doporučení22 je vhodné soustředit se na body 1, 2, 3, 7 a 14.
2.6 CobiT Kvalitou informací se zabývají i jiné metodiky s širším zaměřením na informační technologie jako například metodika CobiT23, která je považována za soubor těch nejlepších praktik pro řízení informatiky (IT Governance), které by měly umožnit dosažení strategických cílů organizace díky efektivnímu využití dostupných zdrojů a minimalizaci IT rizik.24
Obrázek 4: Přehledové schéma systému CobiT25
Metodika CobiT je určena především pro executive management a osoby provádějící audit. Rozděluje IT do 4 domén (PO – Plánování a organizace, AI – Akvizice a
KUČERA Milan. Kvalita informací (4): E. W. Deming a kvalita informací. Computerworld. 2008, č. 14, s. 31. 23 Control Objectives for Information and related Technology 24 ČERMÁK Miroslav. CobiT tajemství zbavený. Clever and Smart. [online] 25Převzato z IT Governance Institute. CobiT 4.1. 22
- 21 -
implementace, DS – Dodání a podpora, ME – Monitorování a vyhodnocování), které zároveň tvoří hlavní kapitoly knihy, v rámci kterých je popsáno 34 procesů. Dohromady domény tvoří PDCA cyklus. Dle CobiT mají informace, která IT poskytuje, splňovat tato kritéria26: Effectiveness – Účelnost – včasné doručování relevantních informací ve správném, konzistentním a použitelném tvaru. Efficiency – Hospodárnost – zpracování informací nejekonomičtějším a nejproduktivnějším způsobem při optimálním využití informačních zdrojů a prostředků. Confidentiality
–
Důvěrnost
–
ochrana
důležitých
informací
proti
neautorizovanému použití nebo prozrazení. Integrity – Integrita – přesnost a kompletnost informace ve vztahu k požadavkům a očekávání. Availability – Dostupnost – dostupnost informace pro podnikání nyní i v budoucnosti, ochrana potřebných datových i technologických zdrojů. Compliance – Soulad – udržování souladu se zákony, regulacemi, směrnicemi, kontraktačními podmínkami a procesy. Reliability – Spolehlivost – požadavky vztahující se k přínosu informace pro rozhodování manažerů. V kontextu informační kvality jsou nejzajímavější procesy PO8 a DS11, které mimo jiné obsahují následující cíle řízení: PO8 Řízení kvality ∘
Vytvoření systému řízení kvality (PO8.1)
∘
Standardy pro IT, vývoj a kvalitu (PO8.2 a PO8.3)
∘
Zaměření na zákazníka (PO8.4)
∘
Neustálé zlepšování (PO8.5)
∘
Měření, sledování a vyhodnocování kvality (PO8.6)
DS11 Řízení dat
26
∘
Požadavky na řízení dat (DS11.1)
∘
Ukládání a uchovávání dat (DS11.2)
∘
Likvidace, zálohy a obnova (DS11.4 a DS11.5)
∘
Bezpečnostní požadavky (DS11.6)
IT Governance Institute. CobiT 4.1.
- 22 -
3
Zkoumané projekty Jak název a zadání diplomové práce naznačují, budeme se zabývat řízením datové
kvality v podnikové praxi. Pohled na reálné problémy, se kterými se firmy setkávají, nám zprostředkuje několik vybraných projektů, na kterých jsem se během své profesní praxe podílel. Rád bych v následujících teoreticky zaměřených kapitolách uváděl konkrétní příklady z těchto projektů a považuji tedy za vhodné projekty představit a uvést do souvislostí. Samotné zhodnocení projektů a případné návrhy lepšího přístupu k jejich řešení podané z dnešní perspektivy bude uvedeno v závěrečných kapitolách diplomové práce.
3.1 Tesco Stores ČR a.s. V letech 2000-2004 jsem pracoval jako analytik obchodních systémů na evropské IT centrále obchodního řetězce Tesco. V té době Tesco rozvíjelo svou síť hypermarketů v České Republice, na Slovensku, v Polsku a Maďarsku a my jsme řešili projekty na podporu nebo vůbec umožnění tohoto poměrně rychlého růstu. 3.1.1 Competitive Pricing Můj prakticky první samostatný projekt měl za cíl s pomocí existujících technických prostředků umožnit hromadný a pravidelný sběr cen v konkurenčních obchodech a následné vyhodnocení rozdílů s návrhem nových cen prodávaných ekvivalentních produktů. Projekt po IT stránce zajišťoval novou marketingovou strategii. Během projektu jsem navrhl proces sběru cen pomocí v obchodech běžně užívaných PDCU27 a vytvořil nové programové vybavení pro přípravu a vyhodnocování dat. 3.1.2 Trading & Technical Law Pack Smyslem tohoto projektu bylo vytvořit intranetový portál pro technicko-právní oddělení. Portál mimo jiné umožňoval sběr informací o inspekcích státních kontrolních orgánů na obchodních jednotkách a dále podávání sumárních hlášení a výpočet poplatků za obaly a odpady uvedené na trh.
27
Portable Data Capture Unit – přenosný minipočítač vybavený čtečkou čárových kódů
- 23 -
Má práce začala analýzou a pomocí s formulováním vlastního zadání, pokračovala přes vytvoření datového modelu a programování aplikace až po nasazení a podporu uživatelů. Prakticky ve stejné podobě je aplikace používána dodnes. 3.1.3 Data Entry Team Při rostoucích nárocích na úplnost a kvalitu informací a při rostoucím množství výrobků zařazovaných do prodeje nebylo dále únosné, aby informace o produktech a dodavatelích zadával přímo do systému každý asistent nákupčího. Vedení společnosti proto rozhodlo o vytvoření specializovaného týmu, nástroje a nastavení nových procesů a zodpovědností pro zavádění výrobků do informačního systému. Jako odborný garant části produktových atributů a systémových procesů jsem se podílel na vytváření procesů a podpůrných programových prostředků pro vkládání dat.
3.2 Petrom S.A. Od roku 2008 jsem po dobu necelých dvou let pracoval pro divizi E&P28 největší rumunské
naftařské
společnosti
Petrom.
Společnost
procházela
rozsáhlou
restrukturalizací a modernizací po začlenění do rakouské skupiny OMV. 3.2.1 Master Data Store Cílem několika projektů spojených s implementací Master Data Store v rámci E&P Data Management programu bylo sjednotit silně roztříštěné databáze vrtů, přizpůsobit platformu Seabed29 firmy Schlumberger a stanovit základní procesy pro řízení životního cyklu vrtu. Technologicky i organizačně se jednalo o revoluční skok od papírové evidence a jednoduchých databází FoxPro k nejmodernějšímu systému pro správu oborových dat. Podílel jsem se na projektu nejprve v roli migračního experta a později datového a solution architekta.
3.3 Asekol s.r.o. Od roku 2010 do současnosti pracuji pro kolektivní systém Asekol. Společnost v zastoupení výrobců a dovozců elektrozařízení z jimi odváděných poplatků organizuje a financuje celostátní systém zpětného odběru elektrozařízení, tj. sběr, dopravu a
Exploration and Production – zahrnuje průzkum ropných nalezišť, vrty, těžbu a dopravu surové ropy, též se užívá označení upstream 29 Seabed E&P Open Data Model & Database – http://www.slb.com/services/software/im_technology/seabed.aspx 28
- 24 -
recyklaci. Společnost se připravuje na uvolnění zákonem garantovaného monopolního postavení a expanduje na další oborové i geografické trhy. 3.3.1 AsIS Cílem projektu je postupně nahradit původní informační systém, který již dále nemohl být rozšiřován a upravován, systémem novým, procesně orientovaným a otevřeným i pro partnery společnosti. Zároveň pomáháme s vytvořením, zjednodušením a formalizací firemních procesů. Podílím se na projektu jako migrační expert, datový architekt a specialista na rozhraní mezi systémy.
- 25 -
4
Kontrola a řízení kvality dat v primárních systémech V této stěžejní kapitole diplomové práce se zaměříme na techniky řízení a
zlepšování kvality dat v informačních systémech, ve kterých dochází k pořizování primárních informací, se kterými firma dále pracuje.
4.1 Úvod do problematiky 4.1.1 Informační systém Podle definice30 je informační systém soubor lidí, technických prostředků a metod, zabezpečujících sběr, přenos, zpracování a uchování dat, za účelem prezentace informací pro potřeby uživatelů činných v systémech řízení. Často se vnímání informačního systému omezuje pouze na aplikaci a její případnou databázi a z toho plyne i zúžené vnímání řízení kvality dat pomíjející uživatele a procesy. Součástí každého informačního systému jsou tedy i procesy jeho užití. Bohužel v praxi se často ukazuje, že ty původní, podle kterých byl systém navržen, zůstali v hlavách zadavatelů nebo programátorů, někdy jsou procesy popsány aspoň v uživatelské příručce, ale ta spíše omezuje pouze na postup užití IS a ne na celkový firemní proces. Uživatel tak neví, proč údaje do systému zadává a jaké údaje jsou opravdu důležité. Kvalita informací je tak mizivá. Způsob jakým je uživatel veden k práci s IS a úroveň podpory procesů rozděluje IS na evidenčně orientované a procesně orientované. 4.1.2 Evidenčně orientovaný IS Ukázkovou evidenčně orientovanou aplikací je Notepad (Poznámkový blok). Veškeré podněty pro práci s takovým IS vychází ze strany uživatele, ten musí vědět, co potřebuje a kde to najde. Např. s využitím systému menu vyvolá požadovanou obrazovku, zadá nebo vyhledá údaje a vrátí se opět na výchozí pozici. I takový systém může poskytovat kvalitní informace a být součástí perfektně nastavených firemních procesů – pokud jsou zaměstnanci disciplinovaní nebo je IS velice jednoduchý. Realita ve firmách je však obvykle jiná, procesy a definice zpracovávaných informací jsou popsány mimo systém v obtížně přístupné dokumentaci, pokud vůbec. IS tedy uživateli nijak nepomáhá v jeho práci, pouze mu umožňuje podle jeho momentální potřeby zaevidovat to, co uživatel chce zapsat (často nehledě na
30
MOLNÁR Zdeněk. Podnikové informační systémy. České vysoké učení technické, 2009.
- 26 -
proces) ať už to je nově pořízený záznam nebo úprava dříve zadaných či nějak vypočtených dat. Možnosti řízení kvality dat se tak mohou prakticky omezit pouze na jednoduché validace formátu, případně povinnosti údajů na formuláři, datový profiling a zpětné korekce dat. Složitější obchodní pravidla jsou velmi těžko vynutitelná a většinou v takovém IS existuje mnoho zadních vrátek, jak nastavená pravidla v případě potřeby obejít. Extrémním případem je potom prostý list papíru a tužka. Mnohým uživatelům by takový systém vyhovoval nejvíce, protože papír snese vše, ale je zřejmé, že spolupráce dvou a více lidí je s takovým přístupem nemožná. 4.1.3 Procesně orientovaný IS Společnosti, které si uvědomují přínosy vysoké kvality informací, se kterými pracují, se snaží ve svých informačních systémech co nejvíce přiblížit podnikovým procesům. Můžeme si představit několik úrovní podpory firemních procesů v informačním systému: 1) Evidenční IS, nepředvídatelné a neřiditelné procesy. 2) Stále evidenčně orientovaný IS, ale organizovaný podle firemních procesů, usnadňuje orientaci a napovídá uživateli, co a proč dělá. 3) Procesně orientovaný systém s workflow implementujícím firemní (aplikační) procesy. Uživatel do systému již nemůže zadat kdykoliv cokoliv, ale pouze informace, které odpovídají stavu procesu a obchodním pravidlům. 4) Úkolově orientovaný systém do procesů zapojuje i uživatele. Část podnětů k aktivitě tak vychází z procesu prostřednictvím aplikace. Zároveň je možné procesy řídit a měřit jejich provádění. 5) Úkolově orientovaný systém s vlastnostmi zaměřenými na zlepšování a optimalizaci procesů. Seznam úrovní jsem sestavil na základě zkušeností a podle vzoru zralostních modelů. Metodiky pro řízení kvality informací nám mohou pomoci optimálně nastavit procesy a procesně orientovaný systém pomůže uživatelům procesy se řídit. Uživatel je veden procesem, aplikací a obchodními pravidly k tomu, aby svou činnost vykonával správně, hned napoprvé, bez nutnosti pozdějších korekcí.
- 27 -
4.1.4 Časté typy chyb v informačních systémech David Loshin uvádí ve své knize31 seznam nejčastějších chyb týkajících se kvality informací v informačních systémech: Granularita atributů – granularitou je myšlen počet různých informací vměstnaných do jednoho atributu (např. jméno i příjmení nebo celá adresa). Problém nastane, pokud se způsob zápisu liší záznam od záznamu a není možné hodnoty jednoznačně rozdělit. Překlepy a transkripční chyby – nekorektní informace se do systému mohou dostat překlepem nebo neporozuměním při přepisování, víceznačné výslovnosti nebo při zápisu zkratek. Nepřesná metadata – nejednoznačně popsané atributy nebo nevhodné datové typy vedou k záměnám při zadávání dat. Implicitní a explicitní prázdné hodnoty – pokud systém vyžaduje hodnotu, kterou uživatel nemá a nezná, obvykle si najde cestu jak omezení obejít zadáním „-“, „X“, „n/a“ nebo třeba „nemá bankovní účet“. Zakázaná hodnota null by byla v tomto případě užitečnější. Nestrukturované významové údaje – uživatelé mají tendenci do systému zadávat užitečné údaje automaticky nezpracovatelnou formou (např. jako poznámky), pokud jim systém nenabídne pohodlnější řešení. Osobně jsem se setkal s případy, že zrušený zákazník měl prostě za názvem dopsáno „Zrušeno“ a uživatel předpokládal, že jej tak „vyřadil z evidence“. Striktní podléhání formátům – telefonní nebo poštovní směrovací číslo má v daném regionu a čase určitý formát zápisu, implementací daného standardu do aplikace pro všechny zadané údaje však prakticky vyloučíme možnost zadat správně údaj z jiné oblasti nebo období. Transformační chyby – při migracích nebo extrakcích z nedostatečně dokumentovaných systémů mohou vzniknout nové chyby, které v původním systému nebyly. Přetížené atributy – jako důsledek špatného datového modelu nebo pozdějších změn a úprav v aplikaci, mají hodnoty jednoho atributu více různých významů.
31
LOSHIN David. Business Intelligence. Morgan Kaufmann, 2003.
- 28 -
4.1.5 Kategorizace přístupů Ze svých zkušeností z IT projektů v mnoha organizacích, na kterých jsem se podílel, a v souladu s tím, co popisují metodiky pro řízení informační kvality, jsem rozdělil přístupy k informační kvalitě do kategorií popsaných v následujících kapitolách.
4.2 Proaktivní přístupy Proaktivní přístupy mají společný cíl předcházet vzniku nekvalitních informací. Nejlepším přístupem je využití principů nebo metodiky řízení informační kvality při návrhu firemních procesů a informačního systému, nicméně účinek lze ještě podpořit následujícími praktikami. 4.2.1 Návrh datového modelu Informační systém potřebuje svá data persistentně ukládat. Tradičním úložištěm dat jsou relační databáze, které však přes své četné výhody, mohou při nesprávném návrhu datového modelu vytvořit nepříznivé prostředí pro kvalitu informací. Mnoho z chyb uvedených Davidem Loshinem pochází právě z chybného návrhu datového modelu. Předpokladem pro kvalitní data je tedy správný návrh datového modelu. Moderní objektové, XML nebo non-SQL databáze přinášejí jiný způsob práce a netrpí některými neduhy relačních databází. Nicméně kvalitu informací sami od sebe nevyřeší, proto je nutné následovat stejné principy jako u relačních databází. V této diplomové práci se budeme zabývat pouze relačními databázemi. První doporučení pro návrh datového modelu je, aby byl v projektovém týmu určen jeden datový architekt, který bude mít návrh na starosti, bude stát mezi analytiky a vývojáři a bude udržovat jednotný styl databáze. Pokud si v databázi programátoři vytvářejí, co chtějí podle své momentální potřeby, nemůže nikdo očekávat koherentní datový model. Alternativně je možné nahradit datového architekta objektovým, který stejným způsobem bude vytvářet a udržovat objektový model, jehož persistenci zajistí některá ze standardních knihoven. Druhé doporučení pro návrh je využití CASE nástroje. Dokáže mnohé kroky zautomatizovat a vytvoření dokumentace ze zadaných metadat je dílem okamžiku. Pokud je nástroj dobře rozšiřitelný s podporou skriptování, je možné vytvářet datový model včetně generování obslužných procedur a triggerů přesně na míru, jen podle metadat. Metadata zahrnují textový popis atributů, tabulek nebo celých částí datového modelu, definici atributů, tabulek, vazeb a omezení pro databázový server, specifická
- 29 -
nastavení jako třídy tabulek, domény atributů, parametry pro generování tabulek, procedur nebo triggerů a další údaje. Při návrhu je důležité mít na paměti normální formy. Pomáhají udržet databázi bez redundantních dat a aktualizačních anomálií. 1. NF – Každý atribut obsahuje pouze atomické hodnoty. 2. NF – Každý neklíčový atribut je plně závislý na primárním klíči. 3. NF – Všechny neklíčové atributy musí být vzájemně nezávislé. BCNF – Atributy, které jsou součástí primárního klíče, musí být vzájemně nezávislé. V reálném prostředí normální formy často porušujeme např. z důvodu optimalizace rychlosti a náročnosti dotazů nebo zjednodušování modelu. Je však důležité být si každé jednotlivé denormalizace vědom, mít ji řádně odůvodněnou a případné aktualizační anomálie podchytit např. triggerem nebo uloženou procedurou. Kvalitu datového modelu je poměrně obtížné změřit. Daniel Moody se ve své práci32 pokusil vyhodnotit několik desítek možných metrik, ale jen pět z nich shledává v závěru užitečných: komplexita systému, počet datových položek duplikovaných v existujících systémech, odhad nákladů na vývoj, procento znovu použitelnosti, počet nedostatků podle faktorů kvality. Dovolil bych si přidat jednu z původně vyřazených metrik, která je v našem kontextu velice důležitá: srozumitelnost datového modelu vývojářům. Tabulky i atributy by měly být nezkratkovitě, výstižně a jednoznačně pojmenované v souladu s předem definovanou jmennou konvencí. Datový architekt by měl analytiky i vývojáře pravidelně informovat o připravovaných rozšířeních databáze a namátkově kontrolovat způsob jakým vývojáři databázi používají – zda vše správně pochopili a zda nejsou nuceni hledat alternativní řešení z důvodu špatného nebo nedomyšleného návrhu.
32
MOODY Daniel L. Measuring the Quality of Data Models: An Empirical Evaluation of the Use of Quality Metrics in Practice. [online]
- 30 -
4.2.2 Master Data Management David Loshin ve své knize33 definuje Master Data Management (MDM) jako soubor nejlepších praktik, který zahrnuje obchodní aplikace, metody řízení dat a nástroje pro správu dat, které uskutečňují firemní politiky, postupy a infrastrukturu jako podporu pro získávání, slučování a následné sdílení přesných, aktuálních, konzistentních a kompletních dat.
Vedení
Akce
Kvalita
Politiky Procedury Infrastruktura
Získávání Propojování Sdílení
Přesnost Aktuálnost Úplnost
Obrázek 5: Podstata MDM (vlastní úprava)
Jinými slovy MDM je určeno k plnění obchodních potřeb firmy tím, že poskytuje přístup ke konzistentním, jednoznačně identifikovatelným vzorovým datovým entitám prostřednictvím aplikačně provozní infrastruktury. MDM není cíl, ale prostředek pro dosažení cíle. V rámci vykonávání MDM provádíme následující činnosti: Posouzení běžně používaných informačních objektů, kolekcí, platných datových hodnot a explicitních a implicitních obchodních pravidel v aplikacích v rámci celého podniku. Identifikaci základních informačních objektů přinášejících společnosti užitek, které jsou používány napříč aplikacemi a které by měly prospěch z centralizace jejich správy. Vytvoření standardizovaného modelu pro integraci a správu klíčových informačních objektů. Správu nashromážděných a zjištěných metadat jako snadno přístupného zdroje informací usnadňujícího konsolidaci. Shromažďování údajů z kandidátských datových zdrojů, vyhodnocování odlišností různých údajů v popisu jedné reálné entity, vytváření jednotného konsolidovaného pohledu. Poskytování metod pro transparentní přístup k jednotným pohledům na reálné datové objekty pro exitující i nově vytvářená aplikace.
33
LOSHIN David. Master Data Management. Morgan Kaufmann, 2009.
- 31 -
Stanovení řádných politik a procedur správcovství a řízení dat na podnikové a obchodní úrovni k zajištění kvalitních vzorových údajů. Výhody MDM spočívají především v získání vyčerpávajících znalostí o zákaznících, ve zlepšení služeb zákazníkům, v konzistentním reportování, ve zvýšení konkurenceschopnosti, ve zlepšeném řízení rizik, ve vyšší produktivitě a výkonnosti a nižším nákladům, ve zlepšeném rozhodování a schopnosti lépe plánovat a analyzovat, ve snazším vyhovění regulačním nařízením, ve zvýšení kvality a rychlé dostupnosti informací i ve snížení náročnosti vývoje aplikací. 4.2.3 Change Request Management Metodiky pro řízení informační kvality dle mého názoru zcela pomíjejí změnové řízení. Spíše lze říci, že změny podněcují a jen málo upozorňují, že nezvládnuté řízení změn může mít pro kvalitu informací katastrofální následky. Řízení změn je doménou metodik jako je ITIL nebo CobiT. Nebezpečí neřízených změn spočívá v možné implementaci protichůdných návrhů, implementaci nepromyšlených momentálních nápadů bez řádné analýzy vlivu, nekoncepčních zásazích do datového modelu, struktur formulářů nebo procesů, či v zrychleném zastarávání dokumentace a snižování srozumitelnosti dat a aplikace. Nastavením procesu pro přijetí, posouzení, konsolidaci, ohodnocení, prioritizaci, plánování a provádění změn můžeme potenciální negativní dopady eliminovat. 4.2.4 User Experience Termín User experience (UX) je možné vysvětlit jako prožitek uživatele (jeho vjemy a odezvy) v souvislosti s očekávaným užíváním aplikace nebo též jako uživatelskou přívětivost. Návrh UX je relativně nová multioborová disciplína zahrnující grafický návrh, návrh interakcí, informační architekturu, návrh uživatelského rozhraní s ohledem na přístupnost a použitelnost. Návrh UX je zaměřen na návrh produktů, kterým lidé snadno porozumí, pochopí jejich smysl a snadno je budou užívat – produkty a systémy se mají přizpůsobit uživatelům a sloužit jim, ne naopak. V kapitole The Beautiful People: Keeping Users in Mind When Designing Data Collection Methods34 popisuje J. Follett a M. Holm jak citlivý návrh formuláře pro průzkum trhu zvýší ochotu respondentů poskytnout údaje. Může se zdát, že uvedený případ ankety je vzdálen informačnímu systému, pouze však do té doby, než si uvědomíme, že zaměstnanci používají informační systém stejným způsobem – motivace
34
SEGARAN Toby a Jeff HAMMERBACHER (ed.). Beautiful Data. O'Reilly, 2009.
- 32 -
platem, případně hrozbou, sama o sobě kvalitní informace nezajistí. Data pocházejí od lidí, z jejich činnosti, návrháři a vývojáři by tedy měli mít neustále na mysli lidi a ne jen data, která chtějí shromáždit, zvláště pokud chtějí sebrat kvalitní data. Výzvy při návrhu UX představují především ohledy na: Přístupnost – přizpůsobení (ne nutně jen omezeným) schopnostem vnímat určitými smysly nebo ovládat určitým způsobem. Může se týkat jak velikosti textu nebo ovládacích prvků, tak např. zvolené úrovně jazyka a užití méně běžných (odborných) slov. Získání důvěry – v případě dobrovolného poskytování osobních údajů do ankety je to samozřejmě klíčový bod. Analogicky pro informační systémy je potřeba získat důvěru uživatele, že data, která do systému zadává, jsou užitečná a opravdu potřebná. Náročnost vkládání dat – je potřeba hodnotit z několika hledisek: časová náročnost (udržení pozornosti, krátkodobá paměť), náročnost ovládání (přeskakování mezi prvky, počet kliknutí nebo pohybů myší), vjemová náročnost (zahlcení, zdánlivá složitost) Přesnost získaných údajů – je z hlediska UX ovlivněna mírou pochopení uživatele, co je po něm vyžadováno a pravděpodobností, s jakou může během vkládání udělat nezáměrnou chybu. Motivace – uživatel, který vidí smysl v tom, co dělá, svou práci bude vykonávat lépe než ten, který neví proč nebo nevěří v užitečnost své práce. Motivovat lze například i uspokojením zvědavosti po tom, co se s údaji děje v dalších krocích procesu nebo soutěžením. Zajímavým námětem je „respekt k uživateli“. Mnohokrát se mi v praxi stalo, že zadavatel IS naprosto nevěřil základním schopnostem a elementární inteligenci uživatelů a vynucoval si množství kontrol, potvrzovacích oken, dlouhých vysvětlujících textů, schvalovacích procesů, atd. Realita však byla jiná než záměr – uživatelé se cítí obtěžováni a nečtou už ani užitečná varování, jen slepě odkliknou další vyskočivší okno – produktivita i kvalita dat klesá. Pří návrhu uživatelského rozhraní aplikace pro konkrétní platformu můžeme využít návrhových doporučení grafického zpracování a ovládání vydaných např. výrobcem dané platformy. Vytvoříme tak aplikaci, kterou uživatel bude umět ovládat dřív, než se k ní dostane. Přílišná vlastní invence a vymýšlení inovativních způsobů ovládání nebo grafický design, který strhne pozornost sám na sebe, mohou být kontraproduktivní. - 33 -
Cílem správného návrhu je intuitivní ovládání aplikace, vedoucí uživatele podle definovaných procesů a předcházející situacím, kdy by mohla vzniknout nekvalitní data.
4.3 Restriktivní přístupy Restriktivní přístupy se snaží zamezit vzniku nekvalitních informací vytvořením určitých nepřekonatelných omezení a pravidel. Komplexní obchodní pravidla je však velmi obtížné implementovat formou omezení a navíc každé dobře míněné omezení se může obrátit v nevýhodu, pokud bude nedostatečně popsáno a vysvětleno nebo na něj uživatel bude často narážet a bude tak nucen hledat alternativní cesty. 4.3.1 Úroveň vyhodnocování Omezení uživatele pro určitou informaci je možné implementovat na mnoha úrovních. Pro vytváření omezení platí dvě úměry – první říká, že čím složitější pravidlo potřebujeme naimplementovat, tím dále od samotných dat se dostáváme. Druhá říká, že čím blíže datům jsme, tím hůře se omezení obchází. Z toho plyne, že příliš komplexní pravidla je snadné obcházet nebo naimplementovat nedostatečně či chybně.
Informace
Databáze
Aplikace
Uživatelské rozhraní
Datový typ Constraint Trigger Procedura View
Objekt Model
Vstupní pole Formulář
Uživatel
Obrázek 6: Schéma úrovní vyhodnocování omezujících pravidel (vlastní úprava)
Při vytváření omezení máme poměrně širokou škálu technických prostředků. Při výběru toho vhodného je třeba posoudit jeho vhodnost z hlediska tvrdosti opatření, snadnosti správy a komfortu uživatele (rychlosti poskytnutí zpětné vazby a její srozumitelnosti). Často se jedno omezení implementuje na několika úrovních, protože je potřeba ošetřit několik rozhraní (uživatelské nebo aplikační). V takovém případě je ideální pokud jsou omezení pro příslušná rozhraní generována z jedněch metadat. Obecně lze doporučit, aby omezení, u kterých očekáváme, že je uživatel může porušit např. zadáním chybné hodnoty, byla oznámena srozumitelnou vysvětlující chybovou hláškou nebo zvýrazněním chybné hodnoty s vysvětlením důvodu. Porušení
- 34 -
omezení z důvodu chyby v aplikaci, za kterou bude pravděpodobně zodpovědný programátor, stačí nechat zobrazit jako aplikační výjimku s technickými detaily. 4.3.2 Technické prostředky V relačních databázích je prvním omezením, které na data uplatňujeme, výběr datového typu atributu. Hodnoty atributů dělíme na textové, numerické, datumové, logické, strukturované a konkrétní typ většinou doplňujeme o určení přesnosti nebo délky. Hodnoty atributu můžeme dále omezit použitím check výrazu. Ve výrazu můžeme použít jiné atributy dané entity nebo deterministické funkce, nemůžeme však dosáhnout na jiné tabulky vnořeným SQL dotazem. CREATE TABLE Register ( ... Start_Date Date CONSTRAINT DV_Register_Start_Date DEFAULT '0001-01-01' NOT NULL, End_Date Date CONSTRAINT DV_Register_End_Date DEFAULT '9999-12-31' NOT NULL, CONSTRAINT CK_Register_Start_Date CHECK (day(Start_Date)=1), CONSTRAINT CK_Register_End_Date CHECK (End_Date = '9999-12-31' or month(End_Date)!=month(dateadd(day,1,End_Date))), ... );
Používání primárních a případně unikátních klíčů v databázích lze považovat za samozřejmé. Za zmínku však stojí, že některé databázové systémy nám umožňují vytvořit unikátní index pouze nad vybranými řádky tabulky. Usnadní nám to vynucení pravidel s podmíněnou unikátností – jen jedna verze může být platná, záznamy určitého typu musí být unikátní apod. CREATE UNIQUE INDEX UK_Role_Admin_Area ON Role (Admin_Area) WHERE Deleted=0 and Admin_Area is not null; CREATE UNIQUE INDEX UK_Partner_Reg_Number ON Partner (Reg_Number,Country) WHERE Deleted=0 CREATE UNIQUE INDEX UK_R_Municipality_Central ON R_Municipality (Central_Town,Admin_Area) WHERE Central_Town=1
Dále zde zmíníme cizí klíče, které se mimo popisu a určení chování vazeb mezi entitami hodí k omezení hodnot atributů pouze na hodnoty nastavené v číselníku (referenční tabulce). Pro zvýšení přehlednosti a srozumitelnosti lze i přes malé snížení výkonu upřednostnit jako primární klíč referenčních tabulek krátký textový kód oproti bezvýznamovému číslu.
- 35 -
CREATE TABLE R_Register_Type ( Code varchar(30) NOT NULL, Name Nvarchar(200) NOT NULL, CONSTRAINT PK_R_Register_Type PRIMARY KEY (Code) ); CREATE TABLE Register ( ... Type varchar(30) NOT NULL, CONSTRAINT FK_Register_Type FOREIGN KEY (Type) REFERENCES R_Register_Type (Code), ... );
Výhodou výše uvedených omezení je, že nám databázový server vždy zaručuje jejich platnost – typicky je jejich platnost ověřena při nastavení a při každé změně v datech. Chceme-li provádět složitější kontroly, musíme využít triggery nebo uložené procedury. U nich však nemáme zaručeno, že v tabulkách nejsou existující nevyhovující data – triggery i procedury kontrolují pouze údaje, které jimi protékají. Triggery lze doporučit, pokud kontrolujeme správnost záznamů vkládaných, aktualizovaných nebo odstraňovaných z jedné tabulky. Procedury nám umožní provádět komplexnější kontrolu nad více souvisejícími tabulkami. CREATE TRIGGER TG_R_Template_Type_mnRel ON R_Template_Type AFTER INSERT, UPDATE AS begin set nocount on if exists ( select 1 from inserted e outer apply fn.split(e.Databases) a left join R_Country r on (r.Code=a.StringElement) where fn.sortlist(e.Databases)<>e.Databases or (a.StringElement is not null and r.Code is null) ) raiserror( 'Nevyhovujici format nebo neplatny odkaz v referencnim listu FK_R_Template_Type_Databases',16,0); end
Velice užitečným nástrojem pro vytváření omezení pro textové hodnoty jsou regulární výrazy. Lze si je představit jako šablony, u kterých zjišťujeme, jestli jim daný text vyhovuje nebo ne, nebo hledáme části textu, které šabloně vyhoví a můžeme je nahradit nebo s nimi dále pracovat. Teoretický základ dal regulárním výrazům kolem roku 1950 matematik Stephen Cole Kleene35, později se staly součástí unixových příkazů a jazyku Perl, jehož syntaxi regulárních výrazů převzala řada dalších programovacích jazyků. Z pohledu gramatik a formálních jazyků už nejsou regulární výrazy dávno regulární, ale mají mnohem větší sílu, název však zůstal zachován. Obchodní pravidla lze popsat speciálně vytvořeným jazykem Object Constraint Language, který je součástí UML standardu. Z takového strukturovaného popisu je potom možné přímo generovat aplikační kód, který bude kontrolu pravidel zajišťovat. Bohužel matematicko-logický způsob zápisu pravidel je sice vhodný pro pochopení významu omezení, ale ne pro jeho efektivní automatické naprogramování.
35
Regular expression. Wikipedia. [online]
- 36 -
4.4 Reaktivní přístupy Reaktivní přístupy jsou takové přístupy, které reagují až na vzniklý problém a snaží se ho napravit. Jsou tedy opakem proaktivních přístupů, které se snaží zamezit vzniku problému. Mezi reaktivní přístupy řadíme především data profiling, kontrolní reporty, jednotlivé nebo hromadné korekce dat, konsolidaci a čištění dat. Podle metodiky TIQM a v souladu s třetím Demingovým bodem kvality je opakované využívání reaktivních přístupů v primárních systémech nežádoucí, protože neodstraňujeme příčinu problému, ale pouze jeho následky. „Jednorázovým“ doplněním chybějícího údaje nebo opravením formátu údaje nezamezíme opětovnému vzniku opravované chyby. Zavedením pravidelného čištění dat vytvoříme nežádoucí závislost a navíc riskujeme, že opravná procedura může opravit i přesná data na data správná (vyhovující diagnostice), ale nepřesná (chybná významem). Jako modelový příklad36 si můžeme představit situaci, že máme v systému evidováno sběrné místo, ke kterému přiřazujeme kontaktní osobu. Sběrné místo má jako jeden ze svých atributů telefon na obsluhu a taktéž osoba má v CRM systému evidován telefon. Principiálně lze toto řešení považovat za správné neboť např. mobilní telefon kontaktní osoby (která má v systému i jiné další role) není nutně stejný jako telefon na vrátnici nebo do objektu sběrného místa. Nevhodný návrh formuláře, který zobrazuje pouze jedno z telefonních čísel a nekompletní data, ve kterých to či ono číslo chybí, vede uživatele k požadavku na doplnění telefonního čísla sběrného místa z telefonního čísla přiřazené kontaktní osoby jednorázovým příkazem do databáze. Je zřejmé, že efekt zásahu je pouze krátkodobý a navíc vytváří v budoucnu potencionálně chybné záznamy, protože kontaktní osoba se může změnit a u sběrného místa pak bude evidováno chybné telefonní číslo. Správným řešení by bylo upravit formulář a užití telefonního čísla tak, aby se zobrazilo číslo od kontaktní osoby v případě, že není definováno číslo u sběrného místa. Tato úprava však vyžaduje diskuzi s uživatelem, kde všude je taková úprava žádoucí a dále představuje větší náklady na zapracování než jeden příkaz do databáze. Výše jmenované přístupy budou blíže popsány v kapitole 5 Kontrola a řízení kvality dat při migracích.
36
Požadavek číslo ASIS-1201 na vývojový tým systému AsIS
- 37 -
4.5 Represivní přístupy Dalším způsobem jak vynutit nebo zaručit určitou úroveň kvality informací jsou smluvní závazky a zákonné normy. Často se tyto právní dokumenty zabývají utajováním informací nebo omezením způsobu nakládání s informacemi, ale nezřídka najdeme i závazky týkající se kvality. 4.5.1 Zajištění aktuálnosti a správnosti informací Pokud firma potřebuje ke své činnosti informace vyžadované procesem, smlouvou nebo zákonem, je možné přenést povinnost poskytnout takové informace na subjekty, kterých se informace týkají. Pravidelné ověřování platnosti evidovaných údajů a zjišťování případných změn by bylo příliš náročné a je proto jednodušší seznámit subjekt s povinností změny nahlásit. Výňatek z pracovní smlouvy37 Zaměstnanec je povinen bezodkladně, avšak nejpozději do 5 pracovních dnů, oznámit zaměstnavateli písemně každou změnu osobních údajů, tj. zejména změnu svého jména, bydliště, dále změnu bankovního účtu, změny v počtu vyživovaných osob… Výňatky z obchodní smlouvy38 Obec je povinna bezodkladně informovat provozovatele o… …informace zadá provozovatele…
obec
v uvedené
lhůtě
do
informačního
systému
S ohledem na nutnost zamezení eventuálního duplicitního vykazování … se obec zavazuje, že nebude vykazovat třetím osobám. Porušením povinnosti nahlásit změnu se subjekt vystavuje riziku nesprávného zpracování jeho požadavku, případně i riziku postihu smluvní sankcí nebo postihu vyplývajícího ze zákona. 4.5.2 Ochrana osobních údajů Osobní údaje podléhají zvláštnímu režimu ochrany, který vychází z Listiny základních práv a svobod a z občanského zákoníku a je popsaný v zákoně č. 101/2000 Sb., o ochraně osobních údajů. V kontextu této diplomové práce je vhodné zmínit alespoň dvě definice z výše uvedeného zákona z § 4 písmeno a) a e):
37 38
Vzor Pracovní smlouvy pro zaměstnance firmy Capgemini s.r.o. Vzor Smlouvy o zajištění zpětného odběru elektrozařízení prostřednictvím jejich mobilního svozu firmy Asekol s.r.o.
- 38 -
Osobním údajem je jakákoliv informace týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze subjekt údajů přímo či nepřímo identifikovat zejména na základě čísla, kódu nebo jednoho či více prvků, specifických pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturní nebo sociální identitu. Zpracováním osobních údajů je jakákoliv operace nebo soustava operací, které správce nebo zpracovatel systematicky provádějí s osobními údaji, a to automatizovaně nebo jinými prostředky. Zpracováním osobních údajů se rozumí zejména shromažďování, ukládání na nosiče informací, zpřístupňování, úprava nebo pozměňování, vyhledávání, používání, předávání, šíření, zveřejňování, uchovávání, výměna, třídění nebo kombinování, blokování a likvidace Dále se v zákoně stanovují práva a povinnosti správce osobních údajů a mezi nimi mimo jiné v § 5 odst. 1 písmeno b) požadavky na kvalitu informací: Správce je povinen zpracovat pouze přesné osobní údaje, které získal v souladu s tímto zákonem. Je-li to nezbytné, osobní údaje aktualizuje. Zjistí-li správce, že jím zpracované osobní údaje nejsou s ohledem na stanovený účel přesné, provede bez zbytečného odkladu přiměřená opatření, zejména zpracování blokuje a osobní údaje opraví nebo doplní, jinak osobní údaje zlikviduje. Nepřesné osobní údaje lze zpracovat pouze v mezích uvedených v § 3 odst. 6. Nepřesné osobní údaje se musí označit. Informaci o blokování, opravě, doplnění nebo likvidaci osobních údajů je správce povinen bez zbytečného odkladu předat všem příjemcům. Dále se v zákoně v § 44 až § 46 stanovují sankce pro fyzické i právnické osoby za přestupky proti tomuto zákonu až do výše 10 000 000 Kč. 4.5.3 Hospodářské trestné činy a podvody Jak uvádí J. Požár ve své knize39, kdo ve své podnikatelské činnosti dosáhne na základě nepravdivého nebo neúplného údaje vydání dokladu potřebného pro orgány kontrolující zboží a technologie, může se dopustit trestného činu – porušování předpisů o nakládání s kontrolovaným zbožím a technologiemi podle § 124c trestního zákona. A dále, kdo v účetních knihách, zápisech nebo jiných dokladech uvede nepravdivé nebo hrubě zkreslující údaje, dopustí se tím trestného činu – zkreslování údajů o stavu hospodaření a jmění podle § 125 trestního zákona. Obecně lze v trestním zákoně najít slova „uvede nepravdivé nebo zkreslené údaje nebo podstatné údaje zamlčí“ mnohokrát a důraz na kvalitu informací má tedy své reálné opodstatnění.
39
POŽÁR Josef. Základy teorie informační bezpečnosti. Policejní akademie České republiky, 2007.
- 39 -
4.6 Destruktivní přístupy Závěrem si shrneme přístupy, které jsou v praxi poměrně běžné, ale je nutné se jich vyvarovat, protože mají devastující dopad na kvalitu informací v informačních systémech. Všechny popsané přístupy vycházejí ze zkušeností z reálných projektů zmíněných v této práci. 4.6.1 Sběratelský přístup Někteří lidé mají dobrý pocit, když je v jejich systému mnoho dat. Z různých zdrojů získávají seznamy firem, osob nebo výrobků, které si nechávají naimportovat do svého CRM nebo jiného informačního systému. Jednou se přeci ty informace mohou hodit, jsou to potencionální klienti nebo potencionální produkty. Mohou mít pravdu a někdy lze takto s daty pracovat, problém ale nastane v momentě, kdy pro tyto z externích zdrojů získaná data nemáme samostatný systém a vložíme je mezi ostatní naše živá data v CRM nebo v jiném IS. Typicky jsou externí data v jiné granularitě, trochu jinak organizovaná, neznámého stáří a kvality a zanesou do IS mnoho chyb a přitom jejich přímá využitelnost firemními procesy je téměř nulová. Data bohužel nejsou jako víno, aby s postupem času zrála. S externími daty je lépe pracovat odděleně od živých produkčních dat. V případě přímého využití je možné importovat pouze vybrané záznamy. Nedává smysl vytvářet si ve vlastním informačním systému svou kopii obchodního rejstříku, ale určitě má smysl používat dostupné pravidelně aktualizované oborové databáze a při zakládání zákazníka do CRM si nechat předvyplnit formulář daty z ARESu nebo z jiného online dostupného registru. 4.6.2 Zpravodajský přístup Nepochybně existují zpravodajské systémy plné střípků různě posbíraných informací, ale běžný firemní informační systém by takto vypadat neměl. Při návrhu informačního systému je potřeba vycházet z požadavků, které jsou odvozeny od obchodní strategie společnosti a soustředit se na informace nutné pro obchodní procesy nebo pro operativní a strategické rozhodování. Představme si například uživatele, který dostal nápad, že o jedné firmě ví, že je certifikovaná na ISO 9001 a že by bylo jistě do budoucna užitečné mít toto poznamenané v informačním systému a nechá si datový model a formuláře rozšířit o dalších 5 zaškrtávátek pro různé certifikace. K té jedné firmě to vyplní, u dalších nebude vědět nebo bude obtížné to zjišťovat a za chvilku na to zapomene. Jen formulář zůstane o něco složitější a databáze bude obsahovat o něco více zcela neužitečných dat. V horším případě si uživatel po čase vzpomene, že by se mu možná hodil report nebo nějaký - 40 -
automatický výběr dodavatele, který upřednostní ty partnery, kteří mají certifikaci a obrátí se na IT, vždyť přece tu informaci v tom systému „máte“. Pokud je potřeba obohatit datový model o nové atributy vyhodnocena jako oprávněná, např. z důvodu lepšího rozhodování při řízení obchodních procesů, je nutné doplnit nový druh informace i k existujícím záznamům např. z externího zdroje nebo zpětným postupným zjišťováním. V krajním případě je možné zavést stav atributu s významem „dosud nezjištěno“ tak, aby bylo možné odlišit jej od hodnoty „nemá“. 4.6.3 Systém zápisníčku Jiná varianta zpravodajského přístupu nebo prostého obcházení chybějící funkcionality je zneužívání atributu „Poznámka“ k zápisu nestrukturovaných informací, které by však v systému měli mít svůj významový atribut. Z praxe40 známe případy, kdy je v poznámce uveden: údaj o kategorizaci/přiřazení klienta, který je v rozporu s nastavením, údaj o výjimkách ze smluvních podmínek, které tak nejsou zpracovatelné systémem, číslo nebo kód, o kterém už nikdo neví, co znamená, údaj o zrušení záznamu, který je však dál ponechán aktivní, údaj, který se už nevešel do svého příslušného políčka formuláře. Atribut „Poznámka“ je sám o sobě ústupek analytiků uživatelům, kteří si systém a život bez něj neumí představit. Představuje příliš velké lákadlo pro snadné zadání informace, která však pro systém a procesy zpracování informací nemá žádnou hodnotu. Dalším rizikem je, že informace v poznámce postrádá kontext, není zřejmé, kdy a kdo ji zadal a zda je stále v platnosti, zvláště pokud je v rozporu s aktuálním nastavením. 4.6.4 Systém tužky a gumy Představme si systém, který podle zadaných informací počítá třeba avíza dodavatelům, nebo souhrnné reporty pro státní kontrolní orgány. Uživatelé však mají „správnější“ informace a vyžadují možnost do systému kdykoliv vstoupit a cokoliv tam změnit. Důvodů může být mnoho: chybná vstupní data, ex-post změny v objednávkách nebo jejich plnění, opravy „známých“ nedostatků systému nebo tzv. „manažerské korekce“.
40
Shrnutí obsahu poznámek u partnerů při migraci do systému AsIS
- 41 -
Je zřejmé, že většina korekčních zásahů pramení z nedůsledného následování procesů, v krajním případě z jejich neexistence. V prostředí, kde jsou uživatelé zvyklí provádět korekce vypočtených dat však ani žádné procesy vzniknout nemohou, protože uživatelé nevěří informačnímu systému ani evidovaným datům. Volnost a „flexibilita“, kterou jim tento přístup dává, je pro ně mnohem pohodlnější, než se nechat svazovat nějakým procesem. Uživatelé většinou už ani nejsou schopni sami ze své činnosti původní proces odvodit nebo mezi těmi všemi výjimkami najít správný a standardní postup. Kvalita dat v informačním sytému degraduje a údaje se přes neustálé korekce stávají méně a méně důvěryhodné, protože prakticky není možné jejich ověření a je podkopána časová konzistence reportů. Pro nápravu takového stavu je zapotřebí značného úsilí všech vrstev managementu a podpory odborných konzultantů, kteří přinesou know-how a nejlepší osvědčené postupy z daného oboru. Samozřejmě, po správném nastavení firemních procesů je potřeba upravit IS nebo vytvořit nový, který bude procesy lépe podporovat a začít s opravou dat na vstupech systému tak, aby vypočtené údaje získaly zpět svou důvěryhodnost. Změna smýšlení zaměstnanců je však velmi náročný proces. 4.6.5 Hodnocení kvantity nad kvalitou Nesprávné nastavení klíčových ukazatelů výkonnosti (KPI) může mít na kvalitu informací negativní účinek. Pokud jsou uživatelé motivováni k pořizování co největšího množství dat, lze objektivně pochybovat o kvalitě takto získaných informací. Při snaze o maximalizaci počtu pořízených záznamů (např. smluv) je minimalizován čas pro ověřování nebo samotné zjišťování informací. Místo správných a přesných údajů uživatelé prostě „něco“ napíšou nebo přímo napíšou údaj nepravdivý, jen aby je informační systém pustil do dalšího kroku. Z oblasti řízení datové kvality se tak můžeme rychle přesunout do oblasti boje proti podvodnému jednání. V souladu s metodikou TIQM i Kaizen je potřeba jasně vyjádřit zodpovědnost každého zaměstnance za kvalitu informaci a v tomto duchu nastavit i motivační prostředky a výkonnostní ukazatele. 4.6.6 Eroze cílů Poměrně častým jevem při plnění určitých předem nastavených cílů bývá jejich pozdější korekce s výmluvou na různé nepředvídatelné okolnosti. Záměrem například může být odměnit třeba i marnou nebo zbytečnou snahu. Při stanovování cílů na další období je pak cíl snížen, aby byl snadněji dosažitelný. - 42 -
100 90 80 70 60
Požadovaný stav
50
Současný stav
40
Rozdíl
30 20 10 0 Obrázek 7: Graf postupného snižování cílů (vlastní úprava)
Tento problém je dobře popsán jako jeden z archetypů systémového myšlení. Systémové myšlení41 představuje jeden z nástrojů, který můžeme využít ve snaze pochopit svět kolem nás, nalézt řešení některých problémů nebo se jim předem vyhnout. Systémová dynamika je vědním oborem, který se zabývá studiem chování systémů v čase. Jedním z důležitých poznatků systémové dynamiky je, že se určité struktury a vazby v dynamických systémech, reprezentujících určitou oblast lidského konání, znovu a znovu opakují – těmto opakujícím se schématům říkáme systémové archetypy. Ne všechny problémy jsou nové a jedinečné. Poznání těchto vzorů nám umožní odhalit příčiny a procesy do jejichž vleku jsme se dostali, nalézt jednoduchost v komplexních problémech a také lépe odhadovat konečný důsledek našich rozhodnutí a vyhnout se nechtěným dopadům. Pro popis systémových archetypů využíváme příčinné smyčkové diagramy. Archetypy se skládají ze stupňované zpětné vazby, vyrovnávacích procesů a časového zpoždění.
41
BUREŠ Vladimír. Systémové myšlení pro manažery. Professional Publishing, 2011.
- 43 -
-
Požadovaný stav
Současný stav
+
N
Rozdíl
+
-
N
Tlak na snížení požadavků
Úsilí o dosažení výsledků
+
+
Obrázek 8: Příčinný smyčkový diagram archetypu Eroze cílů42
Archetyp Eroze cílů vychází z přesvědčení, že rozdíl mezi současným a požadovaným stavem může být vyrovnán buď úsilím vedoucím k dosažení požadovaného stavu, nebo snížením nastavených cílů. Protože cíle byly stanoveny v minulosti za určité situace a v určitém kontextu jako předpověď budoucnosti, úprava cílů tak, aby lépe odrážely aktuální znalosti o současnosti a reálných možnostech, se zdá být logická. Bez objektivních metrik (např. benchmarking) je správné vyhodnocení dosažitelnosti původních cílů nemožné. Časté úpravy stanovených cílů také upevňují laxní přístup při určování dalších cílů.
42
Vlastní úprava obrázku z BUREŠ Vladimír. Systémové myšlení pro manažery. Professional Publishing, 2011.
- 44 -
5
Kontrola a řízení kvality dat při migracích Druhá ústřední kapitola diplomové práce pojednává o procesech a opatřeních
pro zvýšení kvality dat během datových migracích. Migrace jsou vhodné pro nasazení technik a nástrojů pro reaktivní řízení kvality informací.
5.1 Úvod do problematiky Datovou migrací se rozumí převod údajů z jedné databázové struktury do jiné databázové struktury, typicky jinak uspořádané. Důvodem pro migraci může být upgrade systému, přechod od nevyhovujícího nebo již nepodporovaného systému k novějšímu a lepšímu, nebo datová migrace může být prvním krokem při integraci dvou a více systémů před spuštěním synchronizačních procesů. Typická datová migrace je jednosměrná a jednorázová, nicméně někdy je nutné připravit nebo i provést zpětnou migraci (pro případ selhání nového systému) nebo migraci inkrementální (pokud je pro migraci vymezeno krátké časové okno, přenesou se za provozu všechna data a potom během vymezené odstávky pouze rozdíly).
5.2 Fáze a procesy datové migrace Migrační projekt má svá specifika a vyžaduje jiný přístup, než by byl vhodný na běžný vývoj nebo implementaci IS. Často vzhledem k časovým dispozicím a relativní jednoduchosti je možné prolnout fázi analýzy, vývoje a realizace a to jak časově, tak personálně. Podle zkušeností z migračních projektů je nutné zadání a analýzu neustále ověřovat proti skutečným údajům v databázi a to na konceptuální úrovni – kontrolou proti datovému profilu nebo přímými dotazy do databáze, i prakticky – brzkým začátkem implementace už s prvními výsledky analýzy. Zjištění z vývoje a zkušebních běhů migrace pak poslouží k následnému zpřesňování analýzy a v případě nalezení neshod mezi zadáním a reálnou situací mohou být tyto neshody vyřešeny velmi brzy s omezeným negativním dopadem změn. 5.2.1 Analýza a mapování Během úvodní analýzy jsou shromažďovány informace o zdrojovém datovém modelu, významu atributů a hodnot, vazbách mezi entitami a o obchodních a aplikačních pravidlech. Tyto informace lze čerpat z dokumentace systému, pokud existuje, z rozhovorů s uživateli, z datového profilu, přímými dotazy do databáze, ze zdrojových kódů nebo technikami reverzního inženýrství. Získané informace tvoří metadata popisující zdrojový systém.
- 45 -
Dalšími kroky jsou datové mapování, definice transformačních pravidel a odvozování požadavků na kvalitu informací a jejich řešení. Datové mapování znamená přiřazení atributů ze zdrojové databáze atributům z cílové databáze. Během mapování odhalíme případy, kdy je nutné hodnoty atributů změnit podle transformačních pravidel (převádět kódy číselníků, přepočítávat, transponovat, slučovat, rozdělovat, atd.). Požadavky na kvalitu migrovaných dat plynou jak z podmínek kladených cílovým systémem, tak z rozšiřujících podmínek stanovených zadavatelem, protože migrace je příhodná pro vyčištění nebo obohacení dat. 5.2.2 Nástroje a příprava Migrace, jako taková, je sice jednorázová, ale během vývoje a testování ji budeme provádět mnohokrát, a protože se skládá z mnoha odlišných kroků, je vhodné využít speciální nástroj, který spouštění automatizuje.
Agresso
Agresso
INP
OUT INP
MAP
DEF
Prima
NOP
GPS DSE
Obrázek 9: Schéma migrace pro projekt NOP Implementation (vlastní úprava)
Příprava migrace spočívá ve vytvoření nebo konfiguraci migračního nástroje (především v zavedení mapovacích a transformačních pravidel), v nastavení kontrolních mechanizmů a ve shromáždění všech datových zdrojů (do migrace mimo zdrojové databáze vstupují typicky např. hodnoty cílových referenčních tabulek, náhradní zdroje dat definované uživatelem, parametry transformačních pravidel, atd.).
- 46 -
5.2.3 Provedení a testování Celý migrační proces se skládá z řady specifických kroků, které nám migrační nástroj umožňuje spustit jednotlivě nebo všechny najednou. Při provádění jednotlivých kroků jsou typicky zaznamenávány: kritické chyby neumožňující další pokračování procesu, kritické vady dat neumožňující zpracování daného záznamu, drobné nedostatky v datech, úspěšné provedení transformací a zápisu dat. Tyto informace nám slouží jako podklad pro zpřesnění metadat a úpravu kontrolních, migračních nebo transformačních procesů. Z hlediska kvality informací jsou zásadní před-migrační kontrolní reporty, které si ukážeme v následující kapitole a migrační log, který se hodí při dohledávání, jakým způsobem byl který záznam zpracován. Testování migrace provádíme jak ověřováním provedených transformací dle migračního logu, tak porovnáváním výsledku migrace proti původní databázi.
5.3 Data profiling Jak během přípravy datové migrace, tak při vyhodnocování kvality dat je nezbytné mít k dispozici spolehlivá metadata – popisné informace o zpracovávaných datech. Vytvořením datového profilu můžeme získat velice dobrý základ metadat, nebo můžeme ověřit informace a předpoklady obsažené v dostupných metadatech. Datové profilování je typicky automatizovaný proces analýzy surových dat, jehož cílem
je
vytvoření
popisných
charakteristik
uložených
informací,
statistické
vyhodnocení a rozpoznání struktur a vazeb. David Loshin popisuje43 datové profilování jako hierarchický proces, ve kterém začínáme analýzou jednotlivých atributů, pokračujeme analýzou vztahů mezi atributy jedné entity a v poslední úrovni profilu hledáme vazby mezi entitami. Zatímco analýza atributů je nejméně náročná, hledání vztahů a vazeb vyžaduje velmi výkonný databázový systém a profilovací nástroj. Tento přístup k datovému profilování je možné popsat jako výpočet hrubou silou, a to i přes možné využití různých sofistikovaných algoritmů blízkých data miningu. Výsledkem je značné množství dat, které vyžaduje další zpracování – je potřeba vyhledat
43
LOSHIN David. Business Intelligence. Morgan Kaufmann, 2003.
- 47 -
užitečné informace a správně je interpretovat. Takto sestavovaný komplexní datový profil je velmi náročný na výkon systému a vhodné nástroje. V některých bodech s Loshinem souhlasím, ale během mé praxe se mi osvědčil jiný postup založený na pozorování a přirozené44 inteligenci. Spíše než k data miningu bych jej přirovnal k reverznímu inženýrství. V drtivé většině případů se při datových migracích ani při analýze kvality dat nepracuje s nepopsanou množinou dat, ale s pojmenovanými tabulkami a sloupci v databázi plné klíčů, integritních omezení a dalších objektů. Často je možné rozeznat i nějakou jmennou konvenci. Vytvoření datového profilu tedy začínám pohledem do katalogu databáze, identifikací zajímavých využitých typů databázových objektů a jejich vlastností a pojmenování. Následně vlastním nástrojem vytvořím základní datový profil tak, že pospojuji informace dostupné v katalogu, informace odhalené z analýzy datového modelu a statistickou analýzu hodnot atributů do přehledné a provázané formy. Takto sestavený profil postupně doplňuji o slovní popis zjištěného významu atributů a hodnot a rozhodnutí o způsobu a případně cíli migrace (datové mapování). Teprve v případě, že narazím na uspořádání dat hodné dalšího a podrobnějšího zkoumání, provedu detailnější analýzu zaměřenou na souvislosti mezi atributy a entitami. Při rozpoznávání významu atributů a jejich hodnot se mimo názvů a hodnot samotných opírám o jejich popis a užití v aplikaci (např. v aplikačních formulářích), způsob užití v pohledech a procedurách v databázi nebo znalosti uživatelů. Hierarchičnost tohoto procesu spatřuji právě v drill-down postupu od rychle a snadno získatelných informací k detailní a náročné analýze omezené pouze na zajímavé oblasti. Výhodou takového přístupu je mnohem nižší náročnost na výkon databáze, nejsou nutné drahé proprietární nástroje, vlastní řešení je mnohem flexibilnější a výstupní datový profil není přesycen neužitečnými informacemi. Přístup však vyžaduje určité zkušenosti a čas. Pro analýzu datového profilu zdrojových databází jsem během projektu datové migraci vytvořil sadu skriptů, které vygenerují adresářovou strukturu hypertextových souborů popisujících zjištěná metadata. Tabulky jsou rozčleněny do tematických modulů, v názvech a popiscích tabulek a atributů je možné vyhledávat.
44
V protikladu k umělé.
- 48 -
Obrázek 10: Příklad datového profilu tabulky (vlastní úprava)
Na příkladu je možné vidět základní statistickou analýzu velikosti hodnot, počtu vyplněných a unikátních hodnot, příklad nejčastějších hodnot a průřezový příklad všech hodnot. V tabulce jsou identifikovány různé typy záznamů, pro které má smysl provést samostatnou analýzu (některé atributy jsou využity pouze u některých typů záznamů). Nevyužité atributy jsou automaticky skryty. David Loshin uvádí45 následující aspekty, na které je dobré se při vytváření datového profilu zaměřit: Analýza rozsahu – určení zda hodnoty tvoří určitý rozsah nebo zda odpovídají předpokládanému rozsahu. Prořídlost – procentuální vyhodnocení naplněnosti. Určení formátu – pokus o identifikaci formátu nerozpoznaných dat. Kardinalita a jedinečnost – počet odlišných hodnot a jejich unikátnost. Frekvenční analýza – hodnocení počtu opakování jednotlivých hodnot. Absence hodnot – vyhodnocení významu prázdných hodnot. Rozpoznání abstraktního typu – hledání vzorů v hodnotách. Analýza přetížení – rozpoznání atributů užitých k více účelům.
45
LOSHIN David. Business Intelligence. Morgan Kaufmann, 2003.
- 49 -
Krátce si rozebereme dva aspekty. Prořídlost snadno vypočteme jako poměr počtu záznamů s vyplněnou hodnotou (tedy jinou než null nebo hodnota defaultní) proti počtu všech záznamů. Interpretace významu nízkého počtu záznamu s vyplněnou hodnotou však tak snadná není. Může se jednat o nevyužívaný atribut (existující hodnoty mohou být dokonce pouze testovací) nebo naopak může jít o zásadní atribut označující několik málo záznamů s vyžadovaným výjimečných chováním. Pro podrobnější analýzu je možné využít dokumentaci informačního systému, nebo pokud neexistuje, tak např. uživatelské prostředí (Má atribut vůbec ovládací prvek, který by umožnil jeho naplnění?), zkušenosti uživatelů (Jsou tyto záznamy něčím výjimečné?), programový kód (Je hodnota atributu užita při zpracování informací?). Pokud atribut vyhodnotíme jako nedůležitý a nepotřebný, můžeme jej vyřadit z migrace nebo jej odstranit z datového modelu. Na absenci hodnot se můžeme také dívat z několika úhlů. V případě hodnoty null si můžeme pokládat otázky: Může být hodnota prázdná? Nepotřebuje ji systém pro zpracování? Z jakého důvodu ji uživatel nevyplnil? Nesmíme ovšem zapomenout na to, že mnohdy „něco“ vyplněno je avšak s významem null např. prázdný řetězec, pomlčka, „neznámo“, „nezjištěno“, „N/A“, „0000”, nebo naopak “9999” atd.
5.4 Kontrolní reporty Kontrolní reporty slouží k identifikaci nekvalitních zdrojových dat v migračním prostředí před samotným provedením migrace. Měly by zachytit všechny problémy, které by způsobily selhání transformačních pravidel nebo všechny záznamy nesplňují kritéria cílového systému nebo kritéria na kvalitu dat stanovená zadavatelem. Kontrolní reporty jsou vytvářeny a zpřesňovány během celého migračního projektu na základě požadavků na správnost a úplnost dat v cílovém systému, na základě požadavků na kvalitu dat stanovených uživatelem a především na základě opakovaného vyhodnocování úspěšnosti a samotných výsledků migrace. V ideálním případě migrační nástroj zajistí nejen spuštění kontrolních reportů a jejich uložení pro uživatele, ale zajistí i odstranění celých kritických záznamů nebo jednotlivých hodnot, které by způsobily selhání migrace nebo cílového systému.
- 50 -
-- rule: Partneři bez nastaveného IČ -- delete from imp.Firma @ Id_Firmy select f.Obch_Nazev, f.Zkraceny_Nazev, f.ICO, a.Nazev_Ulice, a.Cislo_Popisne, a.Cislo_Orientacni, a.Cast_Obce, a.Obec, a.PSC, f.Klient_KS, f.Obec, f.Skola, f.Instituce, f.Provozovatel_SD, f.Provozovatel_MZO, f.Dopravce, f.Zpracovatel, a.Id_Adresy, f.Id_Firmy from imp.Firma f join imp.Adresa a on (f.Id_Adresy_Sidlo = a.Id_Adresy) where f.ICO is null order by f.Obch_Nazev ; -- rule: Neplatné DIČ -- setnull imp.Firma @ Id_Firmy, DIC select Obch_Nazev,Zkraceny_Nazev,ICO,DIC, Kod_Zeme, f.Id_Firmy from imp.Firma f where (DIC not like 'CZ%' and (Kod_Zeme is null or DIC not like Kod_Zeme+'%')) or (len(DIC)>12) ;
Migrační nástroj, který jsem vytvořil pro migraci dat do systému AsIS zpracuje výše uvedené zadání na dva kontrolní reporty a vyloučí z migrace firmy bez IČ nebo odstraní chybně zadané DIČ. Podle zásady, že je lepší nemít žádný údaj, než mít údaj chybný, jsou podezřelé záznamy identifikovány, nabídnuty k opravě a nejsou propuštěny do cílového systému. Obch_Nazev Zkraceny_Nazev ICO Nazev_Ulice Boletice Boletice Březina Březina, okres Vyškov ČR - Ministerstvo vnitra, Policie ČR, správa Zpč. kraje ČR - MINISTERSTVO VNITRA, POLICIE ČR, SPRÁVA ZPČ Havlíček - SERVIS HAVLÍČEK - SERVIS Školní Hradiště Hradiště, okres Karlovy Vary Jaromír Gryč RÁDIO-TELEVIZE JAROMÍR GRYČ RÁDIO-TELEVIZE Revoluční Kovoslužba-Plus, Mezník KOVOSLUŽBA-PLUS, MEZNÍK Novákových Krajská hygienická stanice Plzeňského kraje KHS PLZEŇSKÉHO KRAJE Skrétova Ministerstvo obrany smazat MINISTERSTVO OBRANY SMAZAT Tychonova Opravy TV - Sochůrek SOCHŮREK Peas-Klema Hradec Králové PEAS-KLEMA HRADEC KRÁLOVÉ třída Edvarda Beneše Peas-Klema Pardubice PEAS-KLEMA PARDUBICE Karla IV. REMONDIS spol. s r.o. REMONDIS - POBOČKA STUDÉNKA Žitavského REMONDIS spol. s r.o. REMONDIS - POBOČKA TŘEBÍČ Hrotovická REMONDIS spol. s r.o. REMONDIS - POBOČKA PRAHA Ke Kablu
Cislo_Popisne Cislo_Orientacni Obec Boletice Vyškov Praha 7 3587 Chomutov Karlovy Vary 377 Bor u Tachova 439 6 Praha 8 1188 15 Plzeň 1 Praha 6 210 Poříčany 573 94 Hradec Králové 41 Pardubice 496 Praha 5 1202 27 Třebíč 289 7 Praha 10
PSC Klient_KS Obec Skola Instituce Provozovatel_SD Provozovatel_MZO Dopravce Zpracovatel 38229 0 1 0 0 0 0 0 0 68201 0 1 0 0 0 0 0 0 17000 0 0 0 1 0 0 0 0 43001 0 0 0 0 0 1 0 0 36006 0 1 0 0 0 0 0 0 34802 0 0 0 0 0 1 0 0 18000 0 0 0 0 0 1 0 0 30100 0 0 0 1 0 0 0 0 16000 0 0 0 1 0 0 0 0 28914 0 0 0 0 0 1 0 0 50012 0 0 0 1 0 0 0 0 53002 0 0 0 1 0 0 0 0 15600 0 0 0 0 0 0 1 0 67401 0 0 0 0 0 0 1 0 10200 0 0 0 0 0 0 1 0
Obrázek 11: Příklad chybového reportu "Partneři bez nastaveného IČ" (vlastní úprava)
Kontrolní reporty jsou předány a vysvětleny uživatelům zdrojového systému a je s nimi projednáno řešení zjištěných chyb. Chyby nejlépe opraví uživatelé ve zdrojovém informačním systému, nebo navrhnou nová či upravená transformační pravidla pro migrační nástroj. Případně je možné pouze vzít chyby na vědomí a akceptovat, že chybná data nebudou přenesena. Smyslem kontrolních reportů je tedy včas zachytit kritické chyby a umožnit zpracování migrace správných záznamů bez přerušení a dále zachycené kritické chyby nebo drobné nesrovnalosti sumarizovat a umožnit jejich nápravu ve zdrojovém systému nebo dodatečnou transformací. - 51 -
Někdy však pouhá tabulka s výsledky v Excelu nemá správnou vypovídací hodnotu a pro odhalení nekvalitních informací je nutné nalézt nové řešení. Při migraci vrtů pro rumunský Petrom bylo potřeba ověřit, že přiřazení každého vrtu do organizační hierarchie je v souladu s geografickou pozicí vrtu a zároveň pozice vrtu je aspoň trochu pravděpodobná. Vytvořil jsem nástroj pro export migrovaných dat do programu Google Earth pomocí kterého mohli uživatelé zkontrolovat geografická a hierarchická data. Nástroj zobrazil vrty na mapě včetně detailního popisu a kolem hierarchických skupin všech úrovní vypočetl konvexní obal. Navíc rovnou zvýraznil vrty, které statisticky ležely mimo skupinu.
Obrázek 12: Příklad využití geografického zobrazení pro kontrolu dat (vlastní úprava)
Zobrazení pozice do mapy (někdy úplně postačuje jen bodový graf v Excelu) je skvělým nástrojem pro visuální kontrolu souřadnic samotných: prohození souřadnic (x/y nebo latitude/longitude), správné rozsahy hodnot, shluky v očekávaných oblastech apod. Ale umožňuje nám i provádět kontrolu kvality ostatních údajů: hledání duplikovaných adres nebo záznamů v jednom bodě, ověřování záznamů podle polohy v době pořízení apod.
5.5 Čištění a obohacování dat Tato kapitola je věnována nápravným opatřením, které nám jednorázově umožní zlepšit některé ukazatele datové kvality. Na opravy dat se však není možné spoléhat jako na jediný prostředek dlouhodobého řízení kvality informací. Naproti tomu do firemních procesů vhodně zapojené externí datové zdroje znamenají opravdový přínos jako pro kvalitu dat, tak pro efektivitu uživatelů informačního systému. 5.5.1 Automatické opravy Při datové migraci nebo při čištění dat je vhodné automaticky opravit známé nedostatky v datech. Identifikovat nedostatky nám pomohou především datový profil a kontrolní reporty.
- 52 -
Mezi typické, automaticky opravitelné problémy patří: doplnění chybějících hodnot, normalizace hodnot s významem „nevyplněno“, standardizace identifikátorů a názvů, přepočtení hodnot denormalizovaných atributů, odstranění počátečních a koncových mezer, odstranění diakritických znamének z emailových adres, náhrada zkratek a typických překlepů, správné prohození jména a příjmení, převod hodnot psaných pouze velkými písmeny, formátování PSČ, telefonů apod. Chybějící hodnoty je někdy možné odvodit z jiných atributů, dopočítat z jiných dat, doplnit defaultní hodnotu, apod. Některé databáze v závislosti na nastavení vyhodnotí řetězce „abc“ a „Abc“ jako shodné. Pokud je takový řetězec identifikátorem záznamu s vazbou na jinou entitu přes cizí klíč, riskujeme, že jiný systém vyhodnotí řetězce jako rozdílné a nebude schopen entity správně navázat. Je tedy vhodné identifikátory normalizovat (např. používat pouze malá písmena anglické abecedy) a pro nečíselné identifikátory zapnout binární porovnávání řetězců. Pro rozpoznání prohozeného jména a příjmení osoby nám pomůže buď vlastní statistika z ostatních záznamů osob, nebo můžeme využít volně dostupných seznamů křestních jmen. Pokud hodnota atributu křestní jméno není nalezena v seznamu, kdežto příjmení v seznamu křestních jmen je, můžeme hodnoty sloupců prohodit. Podobně lze podle křestního jména nebo koncovky -ová opravit oslovení pan/paní. 5.5.2 Rozpoznávání informací v nestrukturovaných datech Často se setkáme se situací, kdy informační systém obsahuje data nestrukturovaná nebo méně strukturovaná, než vyžadují cílový systém datové migrace nebo kritéria hodnocení datové kvality. Typickými příklady z podnikové praxe jsou: Jméno osoby včetně titulů jako jedna hodnota – třídění seznamu osob je potom téměř nerealizovatelné. Pracovní pozice nebo funkce jako text – obtížně pak můžeme oslovit pouze statutární zástupce partnerů nebo jejich účetní. - 53 -
Celá adresa nebo její část (např. ulice a číslo) jako jedna hodnota – správné formátování při tisku na obálku nebo ověření správnosti adresy mohou být obtížné. V poznámce zapsané užitečné informace, různá identifikační čísla nebo důvody stavu záznamu, podle kterých bychom chtěli vyhledávat. Typ smlouvy a její verze zakódované do čísla smlouvy. Řešení tohoto problému nám poskytne vhodné užití regulárních výrazů, které vytvoříme na základě vzorku dat nebo datového profilu. V několika iteracích je nutné vyvážit smysluplnost výsledku a množství zpracovaných záznamů – cílem je najít transformaci vhodnou pro co největší množství záznamů, ale stále poskytující validní výsledek. Je nutné opakovaně kontrolovat jak výsledek, tak nezpracovaná data a transformaci doplňovat o další kritéria. -- doplnění osoby ředitele pokud je vyplněn jako kontaktní osoba if @Director is null and (fn.match(@Contact_Position,'[řr](?:e|ia)dit',0)=1 and @Contact_Position not like '%asist%' and @Contact_Position not like '%zást%') set @Director = @Contact_Person;
Tato transformace rozpozná pracovní pozici kontaktní osoby. Pokud je uveden ředitel (nebo některá z variant), ale nejedná se ani o zástupce ředitele ani o asistentku ředitele, bude jméno ředitele nastaveno ze jména kontaktní osoby. if ( $_->{Ulice_a_Cislo} =~ s/ *,? *č\.? *p\.? *(\d+) *// ) {$_->{Cislo_Popisne} = $1;} if ( $_->{Ulice_a_Cislo} =~ s/ *,? *č\.? *or?\.? *(\d+) *// ) {$_->{Cislo_Orientacni} = $1;} if ( $_->{Ulice_a_Cislo} =~ s/\((.*)\)// ) {$_->{Line_2} = $1;} if ( $_->{Ulice_a_Cislo} =~ s/^(.*) *, *(.*?)$/$1/ ) {$_->{Line_2} = $2;} if ( $_->{Line_2} =~ /\d/ && $_->{Line_2} !~ /box/i ) {($_->{Ulice_a_Cislo}, $_->{Line_2}) = ($_->{Line_2}, $_->{Ulice_a_Cislo});} if ( $_->{Line_2} !~ /\d/ && $_->{Ulice_a_Cislo} !~ /\d/ ) {$_->{Ulice_a_Cislo} = "$_->{Ulice_a_Cislo}, $_->{Line_2}"; $_->{Line_2} = undef;} if ( $_->{Ulice_a_Cislo} =~ s/(\d+)[\/ -](\d*\w*)// ) {$_->{Cislo_Popisne} ||= $1; $_->{Cislo_Orientacni} ||= $2;} if ($_->{Ulice_a_Cislo} =~ s/ *(\d+) *$// ) {$1 eq $_->{Cislo_Orientacni} ? $_->{Ulice_a_Cislo} .= " $1" : $_->{Cislo_Popisne} ||= $1;} if ( $_->{Ulice_a_Cislo} =~ s/ *(\d+\w*) *$// ) {$_->{Cislo_Orientacni} ||= $1;} $_->{Ulice_a_Cislo} =~ s/[ \/\\,-]+$//; $_->{Nazev_Ulice} = $_->{Ulice_a_Cislo} if $_->{Ulice_a_Cislo};
Příklad kódu z migračního skriptu, který rozpoznává různé užité varianty zadané adresy a pokouší se správně interpretovat jednotlivé části a rozdělit je na název ulice, číslo popisné, číslo orientační a doplňující adresní informaci. Tento programový kód byl odladěn pro daný případ migrace. Sice by bylo možné jej využít i pro jiné případy, ale není zaručeno, že by poskytoval dobré výsledky – vždy záleží na profilu zpracovávaných dat. Vytvořit jedno univerzální řešení je téměř nemožné.
- 54 -
5.5.3 Obohacování dat z externích zdrojů Čištěním, odvozováním a prohledáváním lze zvýšit kvalitu informací pouze do určité míry, která navíc není příliš vysoká. Chceme-li dosáhnout vyšší kvalitativní úrovně, musíme do procesu zapojit externí datové zdroje s vyšší přesností informací, ze kterých můžeme informace čerpat, nebo proti kterým můžeme informace ověřovat. Externím zdrojem může být i jiný podnikový informační systém, ale pro obohacování dat budeme spíše využívat oficiální evidence, číselníky nebo registry spravované státní nebo jinou autoritou. V České Republice je mnoho oficiálních datových zdrojů veřejně přístupných, často dokonce i přes aplikační rozhraní: Administrativní registr ekonomických subjektů http://wwwinfo.mfcr.cz/ares/ Územně identifikační registr základních sídelních jednotek http://www.czso.cz/csu/rso.nsf/i/prohlizec_uir_zsj Územně identifikační registr adres http://forms.mpsv.cz/uir/ V současné době jsou tyto informační systémy nahrazovány novým systémem základních registrů: Správa základních registrů http://www.szrcr.cz/ Další často využívané externí zdroje dat jsou: Česká národní banka, kurzy devizového trhu http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denn i_kurz.jsp Česká národní banka, kódy platebního styku http://www.cnb.cz/cs/platebni_styk/ucty_kody_bank/ Google Geocoding API https://developers.google.com/maps/documentation/geocoding/ Externí datové zdroje jsou vhodné nejen při ověřování nebo doplňování dat při jednorázových aktivitách jako jsou migrace nebo čištění dat. V ideálním případě by jejich využití mělo být součástí procesů plně implementovaných v informačním systému. Proč by měl uživatel při zavádění nového partnera do IS ručně vyplňovat všechny údaje? Vždyť může zadat pouze IČ organizace a název, sídlo, a další údaje se mohou doplnit - 55 -
automaticky z veřejně dostupné databáze ekonomických subjektů. Zvýší se tak komfortnost aplikace a sníží se riziko zavedení nekvalitních dat do systému. K externím datovým zdrojům můžeme přistupovat mnoha způsoby. Podle objemu dat, četnosti jejich změn, dostupnosti aplikačního rozhraní, a nároků na výkonnost a dostupnost se můžeme rozhodnout pro vytvoření kopie externí databáze v našem informačním systému nebo pro přímý přístup do externí databáze. V případě vytvoření kopie dat musíme samozřejmě zajistit jejich pravidelnou aktualizaci. 5.5.4 Fuzzy matching V ideálním případě mají všechny naše záznamy ve všech databázích nějaký jednoznačný identifikátor platný napříč všemi systémy, pomocí kterého je snadno dohledáme a zajistíme jejich unikátnost v jednotlivých evidencích. Organizace mají své IČ, osoby rodné číslo, výrobky EAN, knihy ISBN, apod. Bohužel reálný svět je vzdálen ideálům a mnohokrát jediný identifikátor, který máme, je jméno nebo název. Představme si například situaci, kdy někdo přinese dlouhý seznam firem a chce vybrat pouze ty, kteří ještě nejsou zákazníky. Klasické porovnání rovnosti řetězců, které nabízí každá databáze, selže na drobných nuancích v textových hodnotách, překlepech, jiném fonetickém zápisu atd. Nejsme tak schopni vyhledat duplicitní záznamy nebo propojit dva datové zdroje. Nejdříve můžeme uplatnit metody standardizace a normalizace popsané v předešlé kapitole o automatických opravách, ale pravděpodobně nevyřešíme všechny problémy – je třeba použít sofistikovanějších metod, často souhrnně označovaných za pravděpodobnostní spojování. Cílem Fuzzy Match46 algoritmů je nalezení referenčních záznamů, které jsou nejvíce podobné vstupnímu záznamu. Prakticky se používají dva způsoby – převod řetězce na kód vystihující výslovnost (např. fonetický algoritmus SOUNDEX) a zjištění vzdálenosti dvou řetězců (např. algoritmy pro výpočet Jaro-Winklerovi vzdálenosti nebo Levenshteinovi vzdálenosti). Následně jsou jako shodné vyhodnoceny takové řetězce, které mají stejný kód nebo vzdálenost menší, než je nastavená hranice.
46
PEJČOCH David. Využití Fuzzy Match algoritmu pro čištění dat. [online]
- 56 -
Databáze Oracle nabízí funkci SOUNDEX a v balíčku UTL_MATCH funkce EDIT_DISTANCE a JARO_WINKLER. Databáze SQL Server nabízí pouze funkci SOUNDEX, ale lze ji doplnit o další algoritmy obsažené v CLR knihovně SimMetrics47. Je zřejmé, že tyto algoritmy budou produkovat určité množství falešných výsledků – podobné názvy dvou různých společností mohou být vyhodnoceny jako shodné. Algoritmy pravděpodobnostního spojování je proto vhodné doplnit o další kritéria a výsledek vyhodnotit lidským operátorem a případně ověřit z externích zdrojů.
47
http://sourceforge.net/projects/simmetrics/
- 57 -
6
Kontrola a řízení kvality dat v sekundárních systémech V této kapitole krátce doplníme pohled na užívané podnikové informační
systémy o systémy sekundární tak, abychom podchytili řízení kvality dat v celé škále typů informačních systémů využívaných v podnikové praxi.
6.1 Úvod do problematiky Podniky využívají celou řadu informačních systémů, které podporují výrobní a podpůrné procesy – CRM, ERP, účetní systém, plánovací a logistické systémy, apod. Všechny tyto systémy mají jednu společnou vlastnost – vznikají v nich data. Efektivní řízení celé společnosti na základě často nesourodých výstupů z několika informačních systémů je dost těžko představitelné. Tato situace si vyžádala vznik nového typu informačního systému – takového, který konsoliduje pohled na data z ostatních systémů a podporuje snadné vytváření reportů, umožňuje sledování výkonnostních ukazatelů a poskytuje celistvý pohled na organizaci pro potřeby středního a vysokého managementu. Odlišující
charakteristikou
sekundárního
systému
od
výše
uvedených
(primárních) je způsob plnění daty – do primárních systémů pořizují data uživatelé, do sekundárních systémů se data kopírují automaticky z primárních a nové data zde nevznikají. Zřejmě nejtypičtějším zástupcem sekundárních systémům je datový sklad. V praxi se také často setkáváme s kombinací primárního a sekundárního v jediném informačním systému – např. systém CRM může být hlavním a jediným systémem pro správu údajů o partnerech a zákaznících – ostatní systémy (ERP, účetní, apod.) tyto údaje pouze přebírají, pracují s nimi, pořizují k nim další data (výkazy, plány, faktury), ale převzaté kmenové údaje nemohou měnit. Sekundární systémy můžeme rozdělit podle několika kritérií. Sekundárním systémem může být pouhá kopie primární databáze na jiném serveru vytvořená z důvodu rozložení zátěže. V lepším případě to může být nový datový model orientovaný na
rychlejší
poskytování
informací
a
v ideálním
případě
jsou
využity
i
multidimenzionální kostky a datová tržiště podporující potřeby uživatelů. Z pohledu řízení datové kvality se však tyto úrovně vyspělosti datového skladu příliš neliší. Kvalita informací v datovém skladu nemůže být řádově vyšší než kvalita původních informací v primárním systému.
6.2 Nové výzvy pro datovou kvalitu Z poslední věty předešlého odstavce vyplývá, že samotný datový sklad ani procesy jeho plnění nedokážou vyřešit zásadní nedostatky v kvalitě dat v primárních - 58 -
systémech. Vhodným uplatněním reaktivních přístupů ke zlepšení datové kvality je možné některé problémy potlačit, ale naše pozornost by se měla spíše obracet k efektivnějším způsobům zlepšování datové kvality v primárních systémech s pomocí proaktivních metod. Datové sklady nám však kladou nové výzvy, se kterými se budeme muset vyrovnat, aby kvalita informací v nich obsažených nebyla degradována.
Obrázek 13: Faktory kvality datových skladů48
V rámci evropského projektu Foundations of Data Warehouse Quality byly definovány faktory kvality datových skladů, které zobrazuje Obrázek 13. Ponecháme-li stranou provozní faktor Přístupnost, zbydou nám tři faktory úzce související s datovou kvalitou. Vysvětlitelnost je faktor zaměřený na metadata a formalizaci návrhových a vývojových postupů tak, aby pro každou informaci v datovém skladu existoval jasný popis významu a byl dohledatelný její původ. Metadatům jsme se již několikrát věnovali a v následující kapitole se na ně podíváme z pohledu sekundárních systémů. Faktor Užitečnost hodnotí přínosnost dat v datovém skladu, do které spadá jak účelnost jejich shromažďování, tak jejich aktuálnost. O potřebě správy pouze relevantních a užitečných informací jsme také již psali. V další kapitole se tedy zaměříme na sledování kvality procesů přenosu dat z primárních do sekundárních systémů. Ve faktoru Uvěřitelnost částečně poznáváme Davidem Loshinem definované 4 dimenze kvality z kapitoly Významy kvality dat. Tento faktor se kryje s řízením kvality v primárních systémech.
48
Vlastní úprava obrázku z JARKE Matthias a Yannis VASSILIOU. A Review of the DWQ Project. Data Warehouse Quality. [online]
- 59 -
6.3 Metadata Metadata – tedy data o datech – jsme již v této práci několikrát skloňovali. Zatím jsme se na metadata dívali z pohledu statistického popisu obsahu v kapitole Data profiling a z pohledu popisu datových struktur v kapitole Návrh datového modelu. Tyto pohledy jsou orientované na primární systémy a na specifické potřeby vývojářů a migračních specialistů – jedná se o technická metadata. Při vytváření datových skladů se nám budou hodit. Nicméně na metadata popisující obsah datového skladu (nebo obecně sekundárního systému) budeme mít jiné nároky – potřebujeme se zaměřit na význam dat pro podnik a jeho řízení – potřebujeme znát obchodní metadata. Toby Teorey uvádí49 následující typy obchodních metadat, o kterých má smysl uvažovat, že je budeme shromažďovat a spravovat: obchodní termíny a jejich definice (i v časových souvislostech), obchodní pravidla, zodpovědnost (autority/governance/stewardship), původ informace, rámec působnosti (scope), organizace (interní i externí). Níže uvedený konceptuální metamodel popisuje vztahy mezi technickými (TMD) a obchodními (BMD) metadaty. Model je myšlen jako ukázkový a entity i vztahy je možné upravit, aby vyhovovaly potřebám konkrétní organizace.
49
TEOREY Toby J. Database design: know it all. Morgan Kaufmann, 2009.
- 60 -
Obrázek 14: Konceptuální metamodel pro technická a obchodní metadata50
Metamodel záměrně integruje technická a obchodní metadata do jednoho celku. Výstupy z datového profilování jsou zahrnuty mezi obchodní metadata, protože umožňují uživatelům kontrolovat jejich definice a data. Pokud jsou metadata spravována na úrovni primárních systémů (měli by být, ale byl by to poměrně ideální případ v praxi téměř výjimečný), měla by být konsolidována za celou organizaci v samostatném datovém skladu. Význam technických metadat uživatelé pravděpodobně nedocení, ale obchodní metadata pro ně mají obrovskou cenu (viz předešlé kapitoly o nedostatcích v datové kvalitě plynoucích z neznalosti pravého významu a účelu pořizovaných dat). Jak Toby Teorey píše, stojí za to přemýšlet jak obchodní metadata nabídnout uživatelům skrze informační systémy, se kterými pracují např. formou nápovědy nebo aspoň zveřejněním na firemním portálu. Propojení technických a obchodních metadat a zveřejnění na vhodné platformě (např. jako Wiki) dá uživatelům a vývojářům nový komunikační nástroj pro zadávání (a
50
Převzato z TEOREY Toby J. Database design: know it all. Morgan Kaufmann, 2009.
- 61 -
hlavně zpřesňování zadání) nových funkcionalit a nově požadovaných informací k evidenci nebo výpočtu.
6.4 ETL: Extract, Transform, Load Způsob, jakým se data do datového skladu dostávají, se nazývá ETL proces nebo také proces integrace informací. Skládá se z následujících kroků51: Získání dat ze zdrojového systému. Mapování dat z jejich původní podoby do datového modelu vhodného k manipulaci s daty v mezi-databázi (staging area). Kontrola a čištění dat. Rekonciliace, integrace, transformace. Mapování dat z mezi-databáze do podoby vhodné pro uložení dat. Uložení dat do datového skladu. Kontrolu kvality dat a čištění dat jsme popsali v předchozích kapitolách. Zaměřme se tedy nyní na některé specifické problémy, se kterými se můžeme během přípravy ETL procesu setkat. Rekonciliací dat je zde myšleno vypořádání rozdílů v datech z různých systémů. Jeden údaj může být evidován v několika informačních systémech a někdy i ve více duplicitních záznamech. Pokud není přímo určen jeden systém jako jediný zdrojový, je nutné vypořádat se s případy, kdy různé systémy poskytují různé hodnoty. Pro vypořádání může být definován i složitý proces zahrnující další kritéria. Data pocházející z více zdrojových informačních systémů je nutné integrovat – propojit související údaje. V ideálním případě jsou provázané již primární systémy a tuto vazbu je možné využít, nebo musí existovat vhodné přirozené klíče. Transformace dat zahrnuje procesy odvozování dat, denormalizace a agregace dat – z původních hrubých dat jsou podle stanovených vzorců a postupů vypočteny hodnoty vhodné pro další zpracování v analytických nástrojích. Samostatným tématem je plánování, řízení a sledování spouštění ETL procesů včetně zotavení se z chybových stavů. Výpadek jednoho datového zdroje nebo i chyba v jediném záznamu se může významně projevit v agregovaných datech neočekávaným výkyvem.
51
LOSHIN David. Business Intelligence. Morgan Kaufmann, 2003.
- 62 -
7
Vyhodnocení projektů V poslední kapitole budeme zpětně hodnotit přístup managementu a řešitelského
týmu k datové kvalitě během vybraných projektů.
7.1 Competitive Pricing Cíl projektu: s pomocí existujících technických prostředků umožnit hromadný a pravidelný sběr cen v konkurenčních obchodech a následné vyhodnocení rozdílů s návrhem nových cen prodávaných ekvivalentních produktů. Od počátku byl kladen důraz na kvalitu sbíraných informací, protože dopady na zákazníka a na prodejní marži byly přímé, významné a dobře měřitelné. Kvalitních podkladů pro stanovení cen bylo dosaženo využitím přenosné techniky (přesné určení výrobku skenováním čárového kódu, zadání konkurenční prodejní ceny do přístroje místo přepisování přes papír) a důslednou manuální kontrolou neočekávaných odchylek před samotným vyhodnocením. Identifikace odchylek byla po testovacím provozu zpřesněna. Během zhruba dvouletého provozu ve třech státech se neobjevily žádné problémy související s datovou kvalitou i přes vysokou fluktuaci uživatelů sbírajících data.
7.2 Trading & Technical Law Pack Cíl projektu: vytvořit intranetový portál pro sběr informací o inspekcích státních kontrolních orgánů na obchodních jednotkách a dále podávání sumárních hlášení a výpočet poplatků za obaly a odpady uvedené na trh. Portál byl navržen s důrazem na komfortnost užití. Vkládané informace byly v maximální míře strukturované (zadávání dat probíhalo převážně výběrem z předem daných možností než vpisováním volného textu), byl umožněn export a zpětný import dat přes MS Excel pro získání informací od třetích stran, byly vytvořeny četné kontrolní reporty pro odhalování nesmyslných hodnot, databáze výrobků byla synchronizována s centrálním systémem téměř v reálném čase, aby bylo možné ihned doplňovat údaje k novým výrobkům. I když portál funguje nepřetržitě téměř deset let, kvalita informací v něm obsažených je nyní poměrně tristní. Během několika let absolutně selhalo nastavení zodpovědností, zachování znalostí o smyslu dat i agendy jako takové a dodržování vytvořených procesů.
- 63 -
Uživatelé nyní vnímají jedinou centrální evidenci inspekcí jako zcela zbytečnou, dublující stále povinné papírové formuláře, neumějí aplikaci správně používat a nechápou, jak jim může být prospěšná jako systém včasného varování při regionálních kontrolách. Evidence hmotností materiálů a obalů výrobků pro zákonem daný odvod poplatků má tak nízké procento vyplněnosti, že z opravných algoritmů pro doplnění několika málo potenciálně chybějících hodnot se stal hlavní zdroj informací. Kontrolní reporty nikdo nevyhodnocuje a celkový výpočet produkuje nesmyslná čísla, která je vždy nutné nějak usměrnit „manažerskou korekcí“. V počátku poměrně úspěšný projekt utrpěl odchodem klíčových osob jak z IT tak z právně-technického oddělení. Již při nasazování aplikace bylo velice obtížné přimět uživatele z obchodního oddělení ke spolupráci a nedařilo se získat ani silnou podpora managementu. Nedůsledné vynucování nastavených zodpovědností a procesů vedlo k zásadní degradaci kvality dat. Po technické stránce považuji obě aplikace za poměrně zdařilé a vyhovující principům řízení datové kvality. Jediný nedostatek vidím v nedokončené podpoře zobrazování obchodních metadat přímo ze vstupních formulářů aplikace tak, aby uživatelé ihned viděli jak a především proč aplikace používat. Po organizační stránce je projekt naopak ukázkovým selháním z důvodu porušení nebo nenaplnění mnoha principů řízení datové kvality popsaných v předešlých kapitolách. Pro nápravu krizového stavu je nutné získat nejprve vyšší a střední management např. vyčíslením přínosů a úspor. Následně investovat do kontroly a doplnění dat, a když systém začne opět poskytovat smysluplné údaje, začít s motivováním uživatelů, aby takový stav udrželi. Přenastavení zodpovědnosti za správné vykazování z technickoprávního oddělení na obchodní oddělení je bohužel nerealizovatelné, ale obchodní oddělení, resp. přímo jednotliví nákupčí, musí být plně odpovědní za kvalitu informací včetně postihu při neplnění.
7.3 Data Entry Team Cíl projektu: vytvoření specializovaného týmu, nástroje a nastavení nových procesů a zodpovědností pro zalistování výrobků. Projekt běžel ve dvou paralelních proudech – organizačním a technickém. Po organizační stránce bylo potřeba vybrat spolehlivé a motivované lidi, zajistit pracovní prostor a především navrhnout způsob spolupráce obchodního oddělení (nákupčí a
- 64 -
jejich asistenti) s Data Entry týmem. Byl vypracován proces, odsouhlaseny pravomoci, zodpovědnosti a lhůty pro jednotlivé kroky procesu. Po technické stránce bylo nutné vytvořit Datový slovník (metadata) obsahující všechny údaje o dodavateli a výrobku nezbytně nutné k tomu, aby mohl být prodáván. Méně důležité atributy byly odsunuty do druhé fáze projektu. Obsahem metadat byl popis účelu z obchodního hlediska, určení datového zdroje (IS, databáze, tabulka, atribut), podmínky povinnosti, jednotky, povolený rozsah, výčet povolených hodnot, režim a způsob zápisu a čtení, oprávnění. Po vytvoření metadatabáze následoval krok k vytvoření rozhraní – pro čtení byl zvolen přímý přístup přes databázové pohledy, pro zápis pak především automatický terminál zadávající údaje do hlavní firemní aplikace. Vzhledem k množství údajů, které bylo potřeba hromadně vyplňovat, byl jako hlavní nástroj pro sběr, validaci a zpracování dat zvolen MS Excel doplněný řadou maker a rozšíření. Bylo možné načíst libovolného dodavatele a jeho výrobky, nechat je zkontrolovat, opravit a uložit zpět, nebo nechat vytvořit prázdný soubor pro zavedení nových dodavatelů a výrobků, který mohl vyplnit přímo dodavatel nebo nákupčí a který byl pak zkontrolován a zpracován v Data Entry týmu. Hlavní motivací projektu bylo snížení nákladů – na neustálé doškolování fluktuujících uživatelů, na časté problémy s řešením „chyba v datech“ zatěžující IT Support a brzdící naplánovaný prodej a stálé stížnosti na přepracovanost a požadavky na další asistenty. V relativně krátké době po nasazení se podařilo cíl splnit. Avšak příprava a implementace projektu se protáhly výrazně nad původní plán – vytvoření metadatabáze a rozhraní bylo velice náročné, protože bylo nutné neustále ověřovat dokumentaci a řešit její rozpor se skutečností. Jednoznačně pozitivní krok pro kvalitu dat byl však ve společnosti vnímán poněkud kontroverzně. Úspor bylo dosaženo i propouštěním, nákupčí ztratili možnost kdykoliv v datech cokoliv rychle upravit a nemohli pustit do prodeje výrobky, pokud neměli všechny informace. Zpoždění a prodražení projektu znamenalo částečnou ztrátu podpory managementu. O dalším pokračování projektu nemám informace. V případě, že by se podařilo nastavený směr udržet a dokončit i druhou fázi, jsem přesvědčen, že by byl pro firmu přínosem. Při zpětném hodnocení provedených kroků mohu potvrdit, že z velké části byly splněny principy řízení datové kvality nastíněné v této práci.
- 65 -
7.4 Master Data Store Cíl projektů: implementace Master Data Store na platformě Seabed, sjednocení silně roztříštěné databáze vrtů a stanovení základních procesů pro řízení životního cyklu vrtu. Well and Field Catalog Prvním projektem, kterého jsem se účastnil, bylo vytvoření katalogu vrtů (WaFC). Vyvinuli jsme speciální aplikaci, do které jsme naimportovali všechny existující lokální databáze vrtů. Data byla automaticky pročištěna a uživatelé dostali k dispozici nástroj pro deduplikaci záznamů – ve zhruba třistatisících záznamech z různých databází bylo identifikováno padesát tisíc unikátních vrtů. Během projektu jsme využili metody datového profilování, kontrolní reporty, čištění, obohacování a spojování dat. Tato, přibližně rok trvající práce, byla završena migrací dat známé a ověřené kvality do MDS databáze. Kvalita záznamů byla hodnocena uživateli na stupnici červená, oranžová, zelená a vyjadřovala jak míru úplnosti dat (tj. nalezení vrtu ve všech stěžejních aplikacích a existenci hodnot), tak subjektivní důvěryhodnost záznamu – uživatelé museli prokázat značné znalosti historických souvislostí a změn při dohledávání a párování informací o vrtech často několik desítek let starých. Cílem čištění dat bylo samozřejmě co nejvyšší procento „zelených“ záznamů, ale management si byl vědom, že toho nelze dosáhnout za každou cenu. Stanovili tedy záměr projektu slovy „migrace dat známé kvality“. Komplikací, se kterými jsem se musel vyrovnat, byla celá řada. Prvotní import dat do katalogu proběhl z různých exportů, které byly dány k dispozici a ne z originálních DBF souborů a někdy neobsahoval žádný technický klíč. Ač se nám dostalo ujištění, že jméno vrtu se nemění a je to tedy dobrý identifikátor, při kontrole dat po půl roce nás čekalo mnoho nepříjemných překvapení. Při spojování záznamů bylo nutné brát ohled např. na změny v rumunské gramatice (jiný zápis, stejný význam) nebo série stejně pojmenovaných validních záznamů, které při spojení vytvářely nežádoucí kartézské součiny. Tato část projektu byla zajímavá především po technické stránce. Za největší komplikací projektu stála nedůsledná a naivní počáteční analýza. Příprava MDS Relativně malé množství zdrojových atributů a entit na jedné straně a perfektně propracovaný specializovaný datový model na druhé straně bylo příslibem snadného projektu. Do hry však vstoupil politický boj s mateřskou OMV o sjednocení způsobu užití MDS. Vzhledem k naprosto odlišným potřebám obou společností bylo nakonec - 66 -
rozhodnuto o vytvoření samostatné rumunské instance a sdílení pouze vybraných číselníků. Zajímavým poznatkem pro mě bylo, že ani velmi vzdělaní lidé (v technických oborech, leč ne IT) nedokáží pochopit ER diagramy ani schopnosti systému, které z nich plynou. Musel jsem ER diagramy rozkreslit tak, že obdélník nereprezentoval celou entitu, ale jeden záznam, u záznamu pak popsat klíčové atributy a vysvětlit stupně volnosti nebo omezení, který dané užití přináší, zejména možnosti evidence historických skutečností. History of names The model doesn’t provide versioning or keeping historical names and attributes. If that is required the model must be reviewed with special attention to parent-child relations. Only if a record becomes obsolete the Current_Flag (below) can be used.
BA_Type Name Unique_Identifier Short_Name
Venture Petrom S.A. ??? Petrom
BA_Association
History of relations The relations between child and parent levels can change in time. The model allows to maintain historical information if the Start and End dates are set properly.
Role Hierarchy_Flag Start_Date End_Date
Historical records The Current_Flag can be used for marking old records that shouldn’t be used anymore.
BA_Association
Parent Y
Role Hierarchy_Flag
BA_Group BA_Type Asset Name Asset 5 Unique_Identifier RO00020002
BA_Association Role Hierarchy_Flag
BA_Group
Parent Y
Obrázek 15: Datový ER
Extension required
Parent Y
BA_Type Field Cluster Name Videle Vadu Lat Unique_Identifier RO00020006
Role Hierarchy_Flag
Parent Y
BA_Group
Extension required
OMV_Well_Land_Rel
BA_Association Role Hierarchy_Flag
BA_Association
Managed By
BA_Type Division Name North-West Unique_Identifier …
BA_Group
BA_Type Field Cluster Name Ticleni Unique_Identifier RO00024004
OMV_Land_BA_Invl Role Start_Date End_Date
Parent Y
BA_Group
BA_Group
BA_Type Field Cluster Name Mamu Otesti Unique_Identifier RO00024003
Land_Agreement
Role Hierarchy_Flag Start_Date End_Date
BA_Group
Parent Y
Fully extensible The organization hierarchy can be completely changed in future, a new branches can be added, relations can be changed, etc.
BA_Association
Parent Y
BA_Type Asset Name Asset 2 Unique_Identifier RO00024001 Current_Flag
BA_Association Role Hierarchy_Flag
Unique_Identifier There is no standard for business associate unique identifiers. What should be used for companies? What should be used for persons? Could this be used for storing OMV_UID for organizational structure?
Company
BA_Type Sector Name ... diagram (vlastní...úprava) Unique_Identifier
BA_Association Role Hierarchy_Flag
Parent Y
BA_Group BA_Type Sector Name … Unique_Identifier …
Ač většinou upřednostňuji zakázkové řešení na míru, musím zde přiznat, že volba implementace standardního, perfektně propracovaného datového modelu Seabed byla správná a otevřela firmě široké možnosti pro vytvoření plně digitálního ropného pole v budoucnosti. Koncept MDS měl podporu nejvyššího vedení, projekt byl dobře strukturován a veden. Principy řízení datové kvality a metodiky nasazování MDS byly dodrženy.
- 67 -
Well Life Cycle Projekt měl za cíl sjednotit kategorizaci vrtů podle mezinárodně uznávaných standardů. Projektu jsem se bohužel neúčastnil, ale při přípravě MDS jsme měli využít jeho výstupů. Bohužel se ukázalo, že osm měsíců vytvářený, diskutovaný a schvalovaný dokument je v praxi nepoužitelný. Hlavní nedostatkem bylo nedůsledné oddělení charakteristik a faktických stavů, které znemožňovalo vytvoření mapování pro migraci a zpětné reportování. Původní seznam „stavů“ vrtu z aplikace Fondul Sondelor čítal 81 položek. V jednom jediném atributu se kombinoval účel vrtu, typ vrtu, produkční metoda a výstup, stav vrtu, důvod odstávky a další charakteristiky. Vše bylo nutné odlišit, normalizovat a správně popsat – vytvářeli jsme tedy datový slovník (metadata) a definovali obsah číselníků. Osvědčilo se nám řídit mapování potřebami integrace systémů, místo vymýšlených potřeb uživatelů – nedokázali si přesně představit, jak v budoucnu budou pracovat, ani domyslet širší dopad svých rozhodnutí. Od navrženého striktního workflow pro řízení stavů vrtu jsme nakonec téměř upustili, protože množství vyžadovaných výjimek z procesu bylo neúnosné. Poučení z tohoto projektu je, že i vysoce odborné terminologické debaty by měl přímo usměrňovat člověk s analytickým myšlením datového architekta.
7.5 AsIS Cíl
projektu:
nahradit
původní
informační
systém
novým,
procesně
orientovaným a otevřeným i pro partnery společnosti, pomoc s vytvořením, zjednodušením a formalizací firemních procesů. Původní firemní kultura Neřízené a nepromyšlené zavádění nových atributů, entit a funkčností. Tendence řešit problémy zvýšení složitosti místo hledání jednodušších způsobů. Neznalost smyslu dat i funkcí IS, úzká orientace pouze na svou agendu. Neexistence firemních procesů. Běžné korekční zásahy do dat možné v kterémkoliv momentu. Nedůvěra v informační systém, nutnost vše přepočítávat a opravovat. Tisíce starých, nekvalitních a nijak nevyužívaných záznamů v databázi. Rozšířený zvyk „nějak to udělat“ bez snahy zjistit správný postup.
- 68 -
Současná firemní kultura Dodavateli vynucené vytváření formálního zadání pro nové funkce IS (i v podepsaném zadání se však ve skutečnosti může cokoliv změnit). Dodavatel IS pomáhá formulovat a vytvářet obchodní procesy. Snaha o vytvoření procesů (troskotá na množství výjimek a potřebě dělat podobné věci pokaždé jinak). Nedůvěra v nový informační systém trvá, ale již bez možnosti kontrolních exportů a ad-hoc oprav dat. Data opravena a vyčištěna při migraci, nepotřebné záznamy smazány, zavedeno mnoho kontrolních mechanismů a uživatelům vysvětlena hodnota kvalitních dat. Změnové požadavky jsou shromažďovány, ale nepracuje se s nimi systematicky – žádné seskupování, posuzování dopadů, prioritizace. Během trvání projektu se nepodařilo změnit přístup uživatelů k informačnímu systému ani k datům v něm zpracovávaným. Při snaze splnit všechny požadavky – bohužel často plynoucí z potřeby zachovat status quo místo požadavků racionálně odvozených ze strategie firmy – jsme vytvořili systém komplexní a konfigurovatelný systém s řadou stupňů volnosti, bohužel někdy to je na úkor přehlednosti vnitřních struktur a snadnosti správy. Procesy řízení datové kvality ani přenesení zodpovědnosti za kvalitu informací na každého jednotlivého uživatele se nepodařilo prosadit. Jediné zlepšení v řízení kvality informací vnímám v technickém zabezpečení minimální úrovně datové kvality pomocí zavedení napojení na externí systémy (Ares, Google Maps) pro obohacování a kontrolu dat, ve vytvoření a vylepšení aplikačních rozhraní a stanovení procesů pro pohyb dat mezi informačními systémy a v aspoň částečném zavedení procesně řízené aplikace s minimem možností pro ad-hoc změny dat. Původní informační systém Stavěn inkrementálně bez jasného záměru. Obsahuje plno zřídka využívaných atributů a mrtvých částí. Bez kontrol a omezení pravidly systém umožňuje uživatelům udělat cokoliv, co je napadne. Mnoho informací je nestrukturovaných. Nedostatečná technická i uživatelská dokumentace.
- 69 -
Současný informační systém Robustní datový model doplněný o množství omezujících pravidel a automatických kontrol. Procesně řízený informační systém. Procesně orientované uživatelské rozhraní. Stavěn po velkých celistvých etapách. Upřednostnění parametrizace před programováním. Nedostatečná technická dokumentace (doplňovaná ex-post). Tento projekt byl inspirací pro většinu obsahu kapitoly Destruktivní přístupy, což je známkou pro obrovský potenciál ke zlepšení. Možnosti podpory a řízení datové kvality technickými prostředky jsme během projektu vyčerpali. Pokud se nezmění zažité zvyklosti a firemní kultura, nemůžeme garantovat dlouhodobé udržení aspoň současné úrovně kvality dat.
- 70 -
Závěr Diplomová práce měla tři základní cíle, které se mi podařilo splnit následujícím způsobem. V první a druhé kapitole byl čtenář seznámen s principy a metodikami pro řízení informační kvality. Vysvětlil jsem význam základních pojmů a obsah příslušných metodik. Čerpal jsem především z vlastní rešerše článků Milana Kučery, které mě navedli na práci Larryho Englishe. Z literatury získané znalosti byly v souladu s mými zkušenostmi. Dalším cílem byla analýza prostředků řízení a přístupů k informační kvalitě v podnikových systémech doplněná o vlastní postřehy a příklady. Téma jsem rozdělil do kapitol čtyři, pět a šest podle specifik primárních systémů, datových migrací a sekundárních systémů. Přístupy k datové kvalitě jsem kategorizoval jako proaktivní, restriktivní,
reaktivní,
represivní
a
destruktivní.
Čerpal
jsem
především
z
vlastních zkušeností a vedoucím práce doporučených knih Davida Loshina. Pro podporu vlastních postřehů a zkušeností se mi podařilo najít množství další literatury. Text jsem doplnil o řadu vlastních příkladů, obrázků a ukázek zdrojových kódů z projektů, na kterých jsem se osobně podílel. Do šíře rozsahu tématu považuji své zpracování za vyčerpávající, do hloubky by samozřejmě bylo možné pokračovat, ale již nad rámec stanovený pro diplomovou práci. Posledním cílem práce bylo zhodnocení rozhodnutí a postupů vzhledem k datové kvalitě uplatněných na reálných projektech, kterých jsem se účastnil. Projekty a svou roli v nich jsem krátce představil ve třetí kapitole. Vyhodnocení pozitivních a negativních skutečností jsem provedl v závěrečné sedmé kapitole na základě znalostí nabytých v předchozí části diplomové práce. V závěru bych chtěl vyzdvihnout důležitost celkového přístupu k zvyšování datové kvality, který zahrnuje jak technickou stránku řešení problému (vylepšování informačního systému, práci s daty), tak organizační stránku řešení (zavedení firemních procesů, vzdělávání uživatelů a nastavení jejich odpovědnosti za kvalitu dat). Bez tohoto celkového přístupu není datová kvalita dlouhodobě udržitelná. Dílčími projekty, postupným zlepšováním a zahrnutím řízení datové kvality do každého nového projektu a do každého firemního procesu – samozřejmě za podpory příslušných technických prostředků v informačních systémech – lze dosáhnout trvalých úspor a konkurenčních výhod plynoucích z kvalitních dat, se kterými pracuje firemní operativa a management rychleji, přesněji a levněji.
- 71 -
Diplomová práce mi pomohla najít řadu argumentů pro podporu tohoto tvrzení. Dále se mi podařilo při rešerších a následném zpracování systematizovat a formalizovat své dosavadní znalosti a k praktickým zkušenostem doplnit teoretický základ. Práce pro mě byla přínosem nejen jako povinný úkol na cestě k vysokoškolskému titulu, ale i jako cenná příležitost k vlastnímu rozvoji v oblasti, které bych se chtěl dále věnovat. Věřím, že práce bude přínosem i pro případného čtenáře.
- 72 -
Seznam použité literatury Literatura 1.
BUREŠ Vladimír. Systémové myšlení pro manažery. Praha: Professional Publishing, 2011. ISBN 978-80-7431-037-9.
2.
DOUCEK Petr (ed.). Informační management. Praha: Professional Publishing, 2010. ISBN 987-80-7431-010-2.
3.
IT Governance Institute. CobiT 4.1. ©2007. ISBN 1-933284-72-2.
4.
KRÁL Jaroslav a Michal ŽEMLIČKA. Kvalita dat. In: Moderní databáze: Kvalita dat v informačních systémech, 26.-27. května 2005, Amber Hotel Vavřinec, Roudnice nad Labem. Praha: Komix, 2005, s. 5-14. ISBN 80-239-4844-X.
5.
LOSHIN David. Business Intelligence. San Francisco: Morgan Kaufmann, 2003. ISBN 9781-55860-916-7.
6.
LOSHIN David. Master Data Management. Burlington: Morgan Kaufmann, 2009. ISBN 978-0-12-374225-4.
7.
MOLNÁR Zdeněk. Podnikové informační systémy. Praha: České vysoké učení technické, 2009. ISBN 978-80-01-04380-6.
8.
MOLNÁR Zdeněk. Manažerské informační systémy. Praha: České vysoké učení technické, 2010. ISBN 978-80-01-04596-1.
9.
POŽÁR Josef. Základy teorie informační bezpečnosti. Praha: Policejní akademie České republiky, 2007. ISBN 978-80-7251-250-8.
10. SEGARAN Toby a Jeff HAMMERBACHER (ed.). Beautiful Data. O'Reilly, 2009. ISBN 9780-596-15711-1. 11. SVATÁ Vlasta. Audit informačního systému. Praha: Professional Publishing, 2011. ISBN 978-80-7431-034-8. 12. TEOREY Toby J. Database design: know it all. Morgan Kaufmann, 2009. ISBN 978-0-12374630-6. 13. VANÍČEK Jiří. Měření a hodnocení jakosti informačních systémů. Praha: Česká zemědělská univerzita, 2004. ISBN 80-213-1206-8.
Články z časopisů 14. KUČERA Milan. Kvalita informací (2): Metodika TIQM. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 12, s. 31. ISSN 1210-9924. 15. KUČERA Milan. Kvalita informací (3): Přesnost vs. správnost. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 13, s. 32-33. ISSN 1210-9924. 16. KUČERA Milan. Kvalita informací (4): E. W. Deming a kvalita informací. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 14, s. 31. ISSN 1210-9924. 17. KUČERA Milan. Kvalita informací (5): Kaizen - proces trvalého zlepšování. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 15, s. 31-32. ISSN 12109924. 18. KUČERA Milan. Kvalita informací (6): Gemba Kaizen. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 16, s. 33. ISSN 1210-9924.
- 73 -
19. KUČERA Milan. Kvalita informací (8): Analýza nákladů na nekvalitní informace. Computerworld. Praha: IDG Czech Republic, 2008, roč. XIX, č. 18, s. 49. ISSN 1210-9924. 20. KUČERA Milan. Informační kvalita v praxi (5): Korektní přístup k analýze kvality informací. Computerworld. Praha: IDG Czech Republic, 2009, roč. XX, č. 12, s. 30. ISSN 1210-9924. 21. KUČERA Milan. Informační kvalita v praxi (4): Analýza kvality dat a čištění dat. Computerworld. Praha: IDG Czech Republic, 2009, roč. XX, č. 7, s. 33. ISSN 1210-9924.
Internetové zdroje 22. Cambridge University Press. Data. British English Dictionary & Thesaurus. [online]. [cit. 2012-01-16]. Dostupné z: http://dictionary.cambridge.org/dictionary/british/data?q=data 23. ČERMÁK Miroslav. CobiT tajemství zbavený. Clever and Smart. [online]. [cit. 7.4.2012]. Dostupné z: http://www.cleverandsmart.cz/cobit-tajemstvi-zbaveny/ 24. ENGLISH Larry. Total Information Quality Management – A Complete Methodology for IQ Management. Information Management. [online]. [cit. 2012-02-11]. Dostupné z: http://www.information-management.com/issues/20030901/7320-1.html 25. JARKE Matthias a Yannis VASSILIOU. A Review of the DWQ Project. Data Warehouse Quality. [online]. [cit. 18.5.2012]. Dostupné z: http://www.dblab.ntua.gr/~dwq/iq97_dwq.pdf 26. Merriam-Webster. Information. Dictionary and Thesaurus. [online]. [cit. 2012-01-16]. Dostupné z: http://www.merriam-webster.com/dictionary/information 27. MOODY Daniel L. Measuring the Quality of Data Models: An Empirical Evaluation of the Use of Quality Metrics in Practice. [online]. [cit. 4.4.2012]. Dostupné z: http://is2.lse.ac.uk/asp/aspecis/20030099.pdf 28. PEJČOCH David. Využití Fuzzy Match algoritmu pro čištění dat. [online]. [cit. 17.5.2012]. Dostupné z: http://www.pejcoch.com/clanky/cl_fuzzy_match_porovnavani_retezcu.pdf 29. Systems2win. Muda - The 7 Types of Waste. [online]. [cit. 5.4.2012]. Dostupné z: http://www.systems2win.com/lk/lean/7wastes.htm 30. VAVRUŠKA Jindřich. ETL a kvalita dat. [online]. [cit. 20.5.2012]. Dostupné z: http://www.systemonline.cz/clanky/etl-a-kvalita-dat.htm 31. Regular expression. Wikipedia. [online]. [cit. 12.5.2012]. Dostupné z: http://en.wikipedia.org/wiki/Regular_expression 32. W. Edwards Deming. Wikipedia. [online]. [cit. 2012-02-18]. Dostupné z: http://en.wikipedia.org/wiki/W._Edwards_Deming
- 74 -
