Bankovní institut vysoká škola Praha Katedra informačních technologií Kvalita dat v datovém skladu nezbytný předpoklad reportingu Bakalářská práce Autor: David Vrbka Informační technologie, Manažer projektu IS Vedoucí práce Doc. Ing. Bohumil Miniberger, CSc. Praha Duben, 2009
Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury. V Třeboni dne 15.04.2009 David Vrbka 2
Poděkování: Touto cestou bych chtěl poděkovat vedoucí mé bakalářské práce doc. Bohumilovi Miniberberovi CSc. za odbornou pomoc, připomínky a rady, které mi byly poskytovány při konzultacích během zpracování práce. 3
Anotace Tato bakalářská práce popisuje a posuzuje současné metody a postupy pro nastavení a udržení kvality dat v datovém skladě. Zabývá se i tím, jaký může mít kvalita dat vliv, jak na řízení vztahů se zákazníky, tak i na řízení celé firmy. Současný vývoj řízení vztahů se zákazníky je ve velké míře ovlivněn rozvojem výpočetní techniky a zaváděním komplexních kontrolních informačních systémů do činnosti společnosti, přičemž není rozhodující její velikost, ale spíše aktivní přístup pro udržení a nastavení kvality dat společnosti. Efektivnost využití informačních technologií silně závisí na kvalitě dat. V aplikacích se mnohdy chybně předpokládá, že jsou potřebná a správná data vždy k dispozici. V poslední době význam kvality dat značně zesílil. Důvodem je potřeba podpory managementu, který musí využívat data pro efektivní řízení společnosti. Annotation This bachelor thesis deals with the assessment and describes current methods and procedures for setting and maintaining quality data in the data warehouse and what may have an impact on the quality of data customer relationship management and management throughout the company. Current trends customer relationship management is in large extent influenced by development of computer technology and implementation of complex information systems to control activities of a company. Its size is not critical, but an active approach to maintain a set quality of data is. Efficient use of information technology strongly depends on the quality of data. The applications are often assumed to use the necessary and correct data. In recent years the importance of data quality has significantly increased. The reason is the need to support the management, which must use data for effective management of the company. 4
Obsah Úvod... 7 1. Datový sklad... 8 1.1 Informace jsou jen data... 8 1.1.1 Historie ukládání dat... 8 1.1.2 Prosté databáze... 8 1.1.3 Relační databáze... 9 1.1.4 Datové sklady... 9 1.1.5 Data Mining... 10 1.2 Datový sklad, definice... 11 1.3 Rozdíl mezi OLAP a OLTP... 12 1.4 Typy datových skladů... 13 1.4.1 Podnikový sklad... 13 1.4.2 Datové tržiště... 13 1.4.3 Virtuální sklad... 13 1.4.4 Datové kostky... 13 1.4.5 Struktura datového skladu... 17 1.5 Proces plnění datového skladu... 18 2. Úloha datového skladu v CRM.... 19 2.1 Definice a charakteristika CRM... 19 2.2 Historie a rozvoj CRM ve dvacátém století... 20 2.2.1 Počátky marketingu = počátky CRM... 20 2.2.2 CRM a nástup výpočetní techniky... 21 2.2.3 Vývoj trhu na přelomu tisíciletí a nutnost zavádění CRM... 21 2.2.4 Hlavní kvalitativní trendy ve vývoji CRM... 21 2.3 Nástupci CRM... 22 2.3.1 Customer Intelligence dokonalá znalost zákazníka... 22 2.3.2 Life Time Value Management sofistikovanější nástupce CRM... 23 3. Řízení přístupu k datům datového skladu.... 24 3.1 Implementace řízení přístupu k datům datového skladu... 24 3.2 Implementace řízení přístupu k na úrovni metadat... 25 3.3 Implementace řízení přístupu k datům na úrovni uživatelské vrstvy... 27 4. Nekvalitní data a metody jejich konsolidace.... 28 4.1 Čištění, inspekce... 28 4.2 Příčina nekvalitních dat... 28 4.3 Management a zlepšování... 29 4.3.1 KAIZEN... 29 4.3.2 Data profiling... 30 4.3.3 Spojení KAIZEN s Data profilingem... 30 4.3.4 Extrakce... 31 4.3.5 Transformace... 31 4.3.6 Čištění dat... 32 4.3.7 Komplexní řešení ETL... 32 4.4 Jaká jsou nejčastější úskalí v ETL vrstvě?... 33 4.4.1 Obchodní logika implementovaná do předdefinovaných modelů velkých systémů... 33 4.4.2 Nejasné číselníky ve velkých firmách... 33 5
4.4.3 Nedodržená referenční a doménová integrita... 33 4.4.4 Duplicita dat... 34 4.4.5 Náhodné chyby způsobené člověkem... 34 4.4.6 Problém měnících se dimenzí... 35 4.4.7 ETL v reálném čase... 36 4.4.8 Householding... 36 4.4.9 Nástroje pro čištění dat Trillium... 37 4.5 Metadata... 38 4.5.1 Stručný přehled ETL nástrojů... 38 4.5.2 Návratnost investic do nástrojů ETL... 39 4.6 Možné řešení - SAS Data Quality Solution... 40 5. Audit datového skladu.... 43 5.1 Potřebujeme audit datového skladu?... 43 5.2 Co auditovat?... 44 5.3 Jak auditovat?... 45 5.4 Od technologie k funkcím... 46 5.5 Příklady metrik kvality dat... 47 5.5.1 Objektivní metriky... 48 5.5.2 Subjektivní metriky... 48 5.6 Čištění a optimalizace dat... 48 5.7 Možná úskalí auditu... 49 Závěr... 51 6
Úvod Kvalita dat a informací představuje složitý problém, který je často především ve větších organizacích podceňován. Je to vícedimenzionální pojem, jelikož má i takové aspekty jako je včasnost, dostupnost a důvěryhodnost. Význam aspektů kvality roste v podnikové sféře, protože tam se stále více pracuje s daty a informacemi, které nemusí být přesné či věrohodné. Rozvoj internetu tento problém velmi zesílil. Nízká kvalita dat a hlavně nedořešení problému dostupnosti informací, může významně snížit efektivnost řízení podniků a strategická rozhodnutí managementu firmy. Marketingové komunikace se v posledních desetiletích stále více integrují do spojitého proudu efektivní komunikace, v němž jsou vzájemně podporovány s cílem ještě lépe oslovit, zaujmout a přesvědčit zákazníka k nákupu produktu nebo služby. Toto je patrné také v metodě Řízení vztahů se zákazníky (Customer Relationship Management), která využívá dat uložených v datovém skladě. Cílem mé bakalářské práce je posouzení a popsání současných metod a postupů pro nastavení a udržení kvality dat v datovém skladě a také jaký může mít kvalita dat vliv na řízení, jak vztahů se zákazníky, tak řízení celé firmy V aplikacích se mnohdy chybně předpokládá, že jsou potřebná a správná data vždy k dispozici. V poslední době význam kvality dat značně zesílil. Důvodem je potřeba podpory managementu, který musí využívat data pro efektivní řízení společnosti. Proto je nezbytné, aby byl ve společnostech zaveden a nastaven tzv. Audit datového skladu, jako zdrojového úložiště dat firmy. 7
1. Datový sklad 1.1 Informace jsou jen data Každý z nás má nějakou svoji představu o uspořádání informací, které potřebuje pro svůj každodenní život, případně je využívá ve své profesi. Jsme dnes samozřejmou součástí informační společnosti, z informace se stalo zboží, které je nutno řádně uložit, patřičným způsobem ošetřovat a především zhodnotit a využít. 1.1.1 Historie ukládání dat Informace mají pro dnešní svět mimořádnou důležitost a nejinak tomu bývalo v minulosti. 1 Velkým rozdílem je obrovské množství informací, které dnešní svět produkuje a které je tedy nezbytné přijmout a zpracovat. Jedním z prostředků, vedoucích k potřebné efektivitě zpracování informací, jsou databáze. Jejich podstatnými funkcemi je třídění a správa informací, které slouží nejen k nutnému poznání aktuálních stavů skutečnosti, o níž informace existují a jsou sbírány, ale také k potřebné analýze minulosti, ať už v kratším nebo delším časovém horizontu. Z vývoje dějů atd. lze pak také více či méně úspěšně sestavovat prognózy trendů a předpokládaných směrů vývoje poznávaných oblastí. Databáze mají svůj počátek v daleké minulosti, tehdy pochopitelně pod jiným názvem, později se vžil výraz kartotéka, který vzniknul z názvu média (karta), na němž byly informace uchovávány. Zpracování informace zápisem většinou na papírovou kartu bylo zdlouhavé, třídění zpracování informací, bylo obtížné a nespolehlivé, a časové nároky na vyhledání potřebné informace v kartotékách, byť o několika tisících kartotéčních lístků, bylo, z pohledu požadavků dnešního marketingu, naprosto neúnosné. Dalším krokem ve vývoji ukládání dat a jejich zpracování, je vynález děrného štítku, Jednoduchá myšlenka papírového média, na němž je pomocí řízené perforace zakódováno množství a charakter dat, znamenal, spolu s počátky využití výpočetní techniky, poměrně významný rozvoj v technologii zpracování dat. 1.1.2 Prosté databáze Databáze lze dělit podle několika kritérií, pro snadnější objasnění jejich funkce a možností využití postačí dělení na databáze prosté a relační. Prostou databází je vlastně jakýkoli výčet informací, tedy dat, které mají svoji souvislost vzhledem k účelu, k němuž byly pořízeny. Takovou prostou databází je například jízdní řád, seznam knih v knihovně, výčet potřeb na dovolenou nebo telefonní seznam. Prosté databáze umožňují vyhledávání pouze 1 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 6 8
podle daného setřídění, svému účelu poslouží velmi dobře, ovšem potíže mohou nastat jednak v nadbytečnosti dat (redundanci), kterou tato forma záznamu dat přináší a pak také v obtížnosti vyhledávání vztahů a souvislostí mezi jednotlivými skupinami dat totožného nebo podobného charakteru. 1.1.3 Relační databáze Do hry tedy vstupují databáze relační, které jsou schopny zachytit vztah relaci mezi soubory dat, tříděnými podle určitých, přesně definovaných pravidel. Tato pravidla nebo požadavky jsou pochopitelně velmi odlišné podle účelu vzniku databáze, princip však zůstává stále stejný efektivní zjištění vztahů mezi uloženými daty na základě definovaných požadavků. Kromě úspory práce s daty představují relační databáze prakticky jediný možný způsob zjištění potřebných výstupů, zvláště u souborů dat, jejichž velikost může přesáhnout velké objemy, často v rozsahu Terabytů informací. Souhrou jednotlivých databází uvnitř společnosti vznikají informační systémy, které jsou především v poslední době zdrojem cenných informací povahy finanční, ale také marketingové. Jedna věc je ale kvalitní relační databáze, další věcí je obrovské množství dat, která do firem vstupují z nejrůznějších zdrojů. Z databází se pak stávají tzv. datové sklady (datawarehouse), které je možné popsat jako jednotné konsolidované úložiště podnikových dat, které je patřičně upraveno pro poskytování rychlých odpovědí na obchodní dotazy. Datové sklady také vnáší pořádek do skladby podnikových dat a možnost jejich analytického zpracování. Bylo by ale chybou chápat je pouze jako nástroje analýzy, který uživatelům poskytuje souhrnný pohled na data uložená v jejich informačním systému. Skutečnost musí být jiná jde o nekončící proces, v jehož průběhu je nutné získaná data správným způsobem přijmout, očistit a uložit do definovaných struktur tak, aby bylo možné s nimi pracovat podle požadavků. Do popisu práce takových datových skladů tedy také patří zajištění jejich doručení adresátům, a to ve struktuře, formě a čase, který je pro ně potřebný a užitečný. 1.1.4 Datové sklady Datový sklad čerpá svůj obsah především z podnikových informačních systémů, často také z tzv. e-aplikací 2. Konkrétní uspořádání záleží vždy na tom, jak je vystavěna architektura podnikové informační sítě. Takovými interními datovými zdroji využitelnými pro analýzy dat v datových skladech jsou databáze zákazníků nebo databáze historií, vytvářené zásobami, fakturací, dodávkami a obchodními systémy. Externí zdroje dat mohou mít 2 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 409 9
podobu obchodních katalogů, obchodních adresářů atd. O plnění těchto datových skladů se starají tzv. datové pumpy, což jsou softwarové nástroje, jejichž úkolem je nejen data získávat (například z výše uvedených zdrojů), ale také je transformovat do nových struktur odpovídajícím požadavkům a ukládat do databáze datového skladu. Kvalita takové datové pumpy přímo ovlivňuje kvalitu uložených dat, protože během procesu transformace jsou na tento nástroj kladeny také vysoké nároky na čistotu dat ve smyslu oddělení dat nepotřebných nebo nevyužitelných, od těch očekávaných. Právě v datových skladech hrají klíčovou roli relační databáze a to roli mnohem důležitější, než například v ERP systémech (Enterprise Ressource Planning), kde jsou databáze využívány především pro zpracování poměrně velkého množství dílčích a malých transakcí dat. Tyto databáze tedy v důsledku svého využívání uchovávají pouze aktuální data. Datové sklady jsou nastaveny naopak pro analýzy historických dat a jsou neustále rozšiřovány bez jakéhokoli omezení obsahu. To umožňuje jejich uživateli jedinečný pohled na data, který je prostřednictvím jiných informačních systémů prakticky nemožný. Analýzy pak dostávají, právě na základě historie, potřebný smysl, což je nutné ocenit například v prostředí CRM systémů. V datovém skladě je také možné nalézt souvislosti a vztahy mezi daty získanými z různých zdrojů, které by jinak uživatel nemohl odhalit. Odborná literatura pak hovoří o tzv. multidimenzionální datové struktuře Můžeme si ji představit jako kostku a je zjednodušeně řečeno ekvivalentem tabulky v relační databázi. Každá kostka má několik dimenzí (pohledů na data). Příkladem typického třídimenzionálního modelu může být kostka s dimenzemi: čas, region, produkt. Údaje se nacházejí v průnicích jednotlivých dimenzí. 3 Tím ovšem možnosti využití datového skladu nekončí, nastupují zde totiž další procesy agregace dat pro odvozené datové sklady, takzvaná datová tržiště (data marts). Proces agregace probíhá opakovaně po každé aktualizaci relační databáze hlavního skladu a datová tržiště tak přinášejí možnosti specializovaných analýz obohacujících data o další hodnoty, například ukazatel ziskovosti zákazníka. To může mít význam při rozhodování o dílčích strategiích firemního podnikání, například v zaměření se na klíčové skupiny (segmenty) zákazníků. 1.1.5 Data Mining Takzvané dolování dat (data mining) je pro interpretaci výsledků analýz rozsáhlých souborů dat velmi důležitou fází procesu, který představuje zavedení speciálních postupů a 3 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 414 10
algoritmů. Zjištěné výsledky jsou pak předkládány adresátům marketingovým specialistům a managementu společnosti na různých úrovních, ve srozumitelné podobě. Nejdůležitějšími nástroji data miningu jsou především statistické metody, matematické modelování atd. Přesnost a správnost výsledků přitom přímo ovlivňuje kvalita vstupních dat, čímž se opět vracíme k předchozím odstavcům, pojednávajících o databázích a datových skladech. Tato kvalita je důležitou podmínkou pro správnou funkci dolování dat a tedy také pro získání hodnověrného výsledku. Právě analytické CRM je jedním z výborných příkladů využití data miningu. 1.2 Datový sklad, definice. Pojmem datový sklad (v anglicky psaných dokumentech datový sklad nazývá Data Warehouse (DW)) lze chápat jako komplexní data uložená ve struktuře, která lze následně poměrně rychle analyzovat a manipulovat s nimi. Data do datového skladu jsou načerpávána z informačních systémů a jiných zdrojů Účelem datových skladů je uložení a uchování integrovaných a náležitě vyčištěných dat, tak aby co možná nejpřesněji obrážela a popisovala skutečný stav dat nyní i v minulosti. Datový sklad je zdrojem informací pro organizaci o organizaci samotné a neustále se vyvíjí, tak aby ji mohl zachycovat, když se sama o sobě mění. Do datového skladu mohou přistupovat uživatelé pomocí nástrojů pro reporting a dotazování. V odborné literatuře bývá pro datové sklady někdy používán název OLAP, který je zkratkou slov on-line analytical processing. Pod tímto názvem lze pochopit také rychlé a efektivní zpracování dat. Toto označení, není pro datové sklady úplně přesné. Existují nerůznější názory na to co zařadit pod pojem datový sklad a co pod pojem OLAP. Ve třívrstvé architektuře DW rozlišujeme tři vrstvy 4 : a) spodní do této vrstvy patří server skladu, na kterém jsou uloženy relační databáze. Této vrstvě odpovídá položka Datový sklad. b) prostřední tato vrstva zahrnuje OLAP server, který obvykle implementuje buď relační OLAP model (ROLAP), což je rozšířený relační DBMS, který převádí operace nad multidimenzionálními daty na standardní relační operace. Druhou možností je multidimensionální OLAP (MOLAP), který přímo umí pracovat s multidimenzionálními daty a operacemi. Tato vrstva koresponduje s Aplikační vrstvou 4 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 415 11
c) vrchní vrchní vrstvu označujeme jako klienta. Obsahuje nástroje pro provádění dotazů a vytváření zpráv, analýzy a/nebo data miningové nástroje (analýzy trendu, predikce, apod.). Shoduje se s prezentační vrstvou. 1.3 Rozdíl mezi OLAP a OLTP Celé datové hospodaření lze rozdělit na dvě základní části: Na prvním místě je již zmíněný OLAP a na druhém místě jsou klasické databázové systémy, které mají označení jako OLTP, což je zkratka on-line transaction processing Pod tímto názvem lze pochopit také rychlé a efektivní zpracování dat. Rozdíly mezi OLAP a OLTP lze nalézt v mnoha aspektech. OLTP systémy uchovávají záznamy o jednotlivých uskutečněných (typicky obchodních) transakcích a jsou obvykle realizovány pomocí dnes nejběžnější relační databázové technologie. 5 Data uchovávaná v OLTP databázovém systému jsou agregována a poté ukládána do datového skladu, nad nímž se posléze podle potřeb provádí okamžité zpracování analýz pomocí vrstvy OLAP. Datový sklad je na rozdíl od OLTP databáze určen výhradně ke čtení dat pro potřeby nejrůznějších analýz. Jedinou výjimkou jsou (obvykle periodické) aktualizace datového skladu, tj. přidávání nových datových agregátů či odstraňování již neaktuálních datových agregátů, které probíhají obvykle periodicky každý týden, měsíc, atp. Tyto akce je ovšem možno chápat za součást údržby datového skladu, která probíhá ve speciálním režimu při momentálním vyloučení zpracování OLAP požadavků uživatelů datového skladu. V běžném režimu práce (tzn. při provádění dotazů a analýz) není obsah datového skladu modifikován. Tento zásadní rozdíl mezi OLTP systémy a datovými sklady má rozsáhlé důsledky pro způsob jeho implementace, návrhu a tvorby konceptuálního modelu, který je orientován na dosažení co nejrychlejšího zpracování dotazů kladených datovému skladu vrstvou OLAP. 5 23.01.2009 http:// computerworld.cz/whitepapers/technologie-pro-data-warehousing-a-data-mining-2467-p2510 12
1.4 Typy datových skladů Ze stavebního hlediska je možné rozlišit tři různé modely datových skladů. 1.4.1 Podnikový sklad Podnikový sklad (enterprise warehouse) obsahuje informace o subjektech, které popisují organizaci jako celek. Provádí integraci celopodnikových dat pocházejících obvykle z jednoho nebo více provozních systémů nebo od externího poskytovatele informací. Tato data zasahují do řady oborů. Obvykle obsahují jak hodnoty detailní, tak i sumarizované. Jeho velikost se může pohybovat od několika gigabyte až po stovky terabyte. Tento typ skladů bývá implementován na mainframy, Unixové superservery nebo na paralelní platformu. Vyžadují rozsáhlé modelování a jejich návrh a vytvoření může trvat několik let. 1.4.2 Datové tržiště Datové tržiště (data mart) obsahuje pouze podmnožinu celopodnikových dat, která je určená pro specifickou skupinu uživatelů. Rozsah dat je omezen na určité vybrané subjekty. Např. v marketingovém tržišti jsou obsaženy informace týkající se zákazníků, zboží a prodejů. Tyto hodnoty bývají sumarizovány. Datová tržiště jsou implementována na levnější servery s Unixovým nebo Windows/NT jádrem a jejich tvorba se pohybuje v řádu týdnů. Podle zdroje získávání dat rozlišujeme data marty na nezávislé (získávají data z provozních systémů nebo z externích informačních zdrojů) a závislé (data jsou jim dodávána z podnikového datového skladu). 1.4.3 Virtuální sklad Virtuální sklad (virtual warehouse) je sadou náhledů na provozní databáze. Pro efektivnější provádění dotazů jsou některé náhledy na sumarizace provedeny před vznikem vlastního požadavku a uloženy. Virtuální sklad je snadné vytvořit, ale vyžaduje dodatečné kapacity na provozních serverech. 1.4.4 Datové kostky Datové sklady a OLAP nástroje jsou založeny na multidimensionálním datovém modelu. Tento model zobrazuje data ve formě datové kostky. Dimenze kostky reprezentují rozdílné kategorie pro analýzu dat. Kategorie jako například čas, geografické umístění nebo různé výrobkové řady jsou typickými dimenzemi v datových kostkách. Kostky nejsou omezeny na tři dimenze. 13
Obr. 1: Multidimenzionální struktura OLAP: Např. kostky vytvořené v MS OLAP services mohou obsahovat až 64 dimenzí. Dimenze jsou obvykle uspořádány do hierarchií tak, že mapují sloupce v relačních databázích. Hierarchie dimenzí jsou seskupovány do úrovní obsahujících hodnoty dané dimenze. Každá úroveň v dimenzi může být sumarizována, aby vytvořila hodnoty pro vyšší úroveň. Např. v dimenzi času sumarizací hodnot v úrovni den získáme hodnoty pro vyšší úroveň měsíc. Míry jsou kvantitativní hodnoty v databázi, které mají být analyzovány. Typickými mírami bývají prodeje, náklady a rozpočty. Míry jsou analyzovány oproti různým kategoriím dimenzí datové kostky. Např. analýza prodejů (míra) určitého výrobku (dimenze) v různých zemích (konkrétní úroveň dimenze geografická poloha) během dvou určitých roků (úroveň dimenze čas). Dále uvedená datová kostka reprezentuje data ve třech dimenzích. A to dimenze Umístění, Času a Položky. Aktuálně zobrazenou úrovní dimenze Času je úroveň Měsíc. U Umístění je to Město a u Položky Druh zboží. Mírou tohoto zobrazení jsou Prodané kusy (v tisících). Potom např. hodnota 12 udává, že v Praze v měsíci Březnu bylo prodáno 12 000 kusů Rohlíků. Uložení dat v multidimenzionálních databázích Star 14
Nejčastějším způsobem jak převést relační data na multidimenzionální je využít tzv. star schéma (hvězda) 6. Hvězdicové schéma se skládá z rozsáhlé centrální tabulky s hodnotami (tzv. tabulka faktů) a řadou malých doprovodných tabulek pro každou dimenzi. Grafické vyjádření schématu připomíná hvězdu, s tabulkami dimenzí zobrazenými v paprskovité struktuře okolo centrální tabulky aktů. Obr. 2: Organizace datového skladu Struktura hvědy: Ve hvězdicovém schématu je každá dimenze reprezentována právě jednou tabulkou. A každá tabulka obsahuje několik atributů. Např. dimenze čas může mít tyto atributy: den, měsíc, kvartál, rok. Snowflake Snowflake (sněhová vločka) 7 je určitým druhem hvězdicového schéma, ve kterém jsou tabulky dimenzí normalizovány, čímž se data rozdělují do dalších tabulek. Výsledné grafické schéma pak vytváří tvar podobný sněhové vločce. Hlavní rozdíl mezi těmito 6 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 422 7 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 422 15
dvěma modely spočívá v tom, že tabulky dimenzí jsou normalizované, aby snížili redundance v uložených datech. Takováto tabulka je snadno udržovatelná a šetří diskový prostor. Ovšem tato úspora je zanedbatelná ve srovnání s typickou velikostí tabulky faktů. Navíc toto schéma může snižovat efektivnost analýz dat, neboť je zapotřebí provést více spojení tabulek, aby mohl být dotaz proveden. Proto může být výkon systému nepříznivě ovlivněn. Z tohoto důvodu není schéma sněhové vločky tak časté při návrhu datového skladu jako hvězdicové schéma. Fact Constellation Některé aplikace mohou vyžadovat více tabulek faktů, aby mohly sdílet tabulky dimenzí. Toto schéma může být zobrazeno jako soubor hvězd a proto se nazývá Constellation (galaxie nebo souhvězdí). 16
1.4.5 Struktura datového skladu Stručně je možné základní znaky shrnout do srovnávací tabulky: Znak OLTP OLAP Charakteristika Provozní zpracování Informační zpracování Orientace Transakční Analytická Uživatel Úředník, databázový administrátor Znalostní pracovník (manažer, analytik) Funkce Návrh databáze Každodenní operace Entitně-relační základ, aplikačně orientovaný Dlouhodobé informační požadavky, podpora rozhodování Hvězda/sněhová vločka, věcná orientace Data Současná, zaručeně aktuální Historická Sumarizace dat Základní, vysoce detailní Shrnutá, kompaktní Náhled Detailní Shrnutý, multidimensionální Jednotky práce Krátké, jednoduché transakce Komplexní dotazy Přístup Číst a zapisovat Většinou pouze číst Zaměření Vkládání dat Získávání informací Počet záznamů dostupných Desítky Miliony Počet uživatelů Tisíce Stovky Velikost databáze 100 MB až GB 100 GB až TB Přednosti Vysoký výkon, vysoká přístupnost Vysoká flexibilita, nezávislost koncového uživatele Míry hodnocení Propustnost transakcí Propustnost dotazů a doba odezvy Tabulka 1: vytvořeno autorem podklad: Lubor Lacko, Oracle Správa, programování a použití databázových systémů 17
1.5 Proces plnění datového skladu Proces plnění datového skladu označován jako proces ETL (extraction-transformationload). Tato zkratka vystihuje plnění datového skladu. Data je třeba nejprve extrahovat z primárních datových zdrojů. Vzhledem k tomu, že jednotlivé primární datové zdroje nepracují s týmž datovým modelem, někdy nepoužívají ani tytéž datové typy, některé údaje jsou v datových zdrojích obsaženy neúplně a je třeba je odvozovat z jiných údajů, následuje krok transformace, který převede data získaná z jednotlivých datových zdrojů do unifikovaného datového modelu, nad nímž je možné vytvářet agregace a získaná agregovaná data pak uložit do datového skladu (fáze load). Smyslem OLAP systémů je co nejrychleji poskytnout uživateli požadované agregace dat, popřípadě výsledky analýz provedených právě nad těmito agregacemi. Zatímco v případě návrhu OLTP systému je jakákoliv redundance údajů nežádoucí, neboť je právem považována za potenciální zdroj vzniku nekonzistencí, v případě OLAP systémů se redundance připouštějí a dokonce se jich hojně využívá k dosažení rychlejší odezvy na OLAP dotazy. 18
2. Úloha datového skladu v CRM. 2.1 Definice a charakteristika CRM Úkolem marketingu v dnešní době, je řešit nejnutnější požadavky doby rozvoj distribuce, komunikace všemi směry a budování co neúčinnějších distribučních kanálů. Pokud se tyto úkoly daří plnit, o to více narůstá ztráta kontaktu výrobce se zákazníkem. Informace o požadavcích zákazníků se soustřeďují především u obchodníků a obsluhy distribučních kanálů, k výrobcům se dostanou jen informace zprostředkované, a tedy do jisté míry zkreslené. K poznání zákazníka a k budování vztahu s ním nepomáhají ani další rozšířené prostředky marketingové komunikace inzerce, ať už v tištěných periodikách nebo v rádiu nebo televizi. Tím lze dosáhnout pouze rozšíření povědomosti o výrobku či značce, což je sice nutné a potřebné, ale současně nepřinášející potřebnou míru zpětné vazby od zákazníka k výrobci. Je potřebné říci, že uvedená média neumožňují potřebný dialog s masou bezejmenných spotřebitelů, kteří o svém nákupním chování a především očekávání, prozrazují jen velmi málo. Takový marketing bohužel vzdálil výrobce od zákazníka. Přinesl také nový jev - řešení jakýchkoliv vztahů se zákazníkem je cílem marketingových a prodejních oddělení, nikoli výroby. S postupným nasycením trhu výrobky a službami je stále více nutné hledat pro ně zákazníky, přičemž role marketingu nabývá na významu. Se systémy řízení vztahů se zákazníky se v dnešní době setkáváme stále častěji. Čím dál více společností přistupuje k zavádění systémů, které jim nabízejí kvalitnější správu dat a informací o firemních zákaznících a z produktově orientovaných společností se tak stávají společnosti orientované na zákazníka. Jsou přesvědčeny o skutečnosti, že pokud bude společnost shromažďovat informace o svých zákaznících, může je obratem využít k individuálním, specifickým nabídkám šitým zákazníkům "na míru". Lze nalézt různé definice CRM, ale je patrné, že k jednotné definici CRM dosud odborníci z oboru, trh ani vědecká pracoviště dosud nedospěly. Za výstižnou definici, reflektující současný stav tohoto oboru, lze považovat následující citaci: Řízení vztahu se zákazníky (CRM) zahrnuje pracovníky, podnikové procesy a technologii (informační systémy a informační a komunikační technologie) s cílem maximalizovat loajalitu zákazníků a v důsledku toho i ziskovost podniku. Je součástí podnikové strategie a jako takové se stává 19
součástí podnikové kultury, Technologicky stále více využívá potenciálu a možností internetu. 8 Další možný popis CRM se zaměřuje na interakci mezi jeho třemi hlavními prvky: Existují tři hlavní prvky CRM. Jsou to databáze s dostatečnou kapacitou a výkonem, prostředky pro vedení inteligentního dialogu se zákazníkem a metody a prostředky hromadného přizpůsobování produktů a služeb. Pod pojmem databáze se skrývá celá technická infrastruktura včetně samotných počítačů. Inteligentní dialog lze vést pouze se zákazníkem, kterého můžeme identifikovat. Informace, které musíme mít k dispozici, jsou nejen jeho osobní údaje, ale také údaje o jeho nákupním chování. Následná segmentace zákazníků probíhá podle dvou kritérií. Podle hodnoty zákazníka a potom podle jeho potřeb. 9 2.2 Historie a rozvoj CRM ve dvacátém století 2.2.1 Počátky marketingu = počátky CRM Pojem Customer Relationship Management úzce souvisí s marketingem a jeho vývojem v celé historii lidstva. Popisujeme-li tedy počátky CRM, je nutné vrátit se k počátkům marketingu. Dlouho před průmyslovou revolucí lze nalézt počátky CRM v budování vztahů se zákazníky v prostých dílnách řemeslníků, kteří se jednak zcela zabývali výrobou, ale byli nuceni své výrobky také sami nabízet a prodávat. Nutnost znát své zákazníky byla zcela zřetelná, osobní znalost potřeb každého z nich byla také jedním ze základů úspěchů jejich živnosti. Vzhledem k dlouhodobosti takových vztahů proto tito řemeslníci věděli, jaké jsou nároky zákazníka na výrobek, jak je používán a jaké potřeby zákazníka výrobek splňuje, či spíše, jaká jsou očekávání zákazníka od výrobku. V těchto dobách byla jediným úložištěm pro získané informace (data) pouze paměť řemeslníka. Z ní čerpal své vědomosti o zákaznících, přizpůsoboval jim výsledky své práce, případně obchodní postupy a tedy zcela samozřejmě se vztahem k zákazníkovi zabýval. Nejenom řemeslníci byli těmi, kteří měli zájem o budování důvěry zákazníka, tyto postupy se přirozeně projevovaly i v měřítku mnohem širším, často i mezinárodním, postačí například oblast obchodování s orientem, kdy byly na důvěře a serióznosti obchodníka i 8 Dohnal J., Řízení vztahů se zákazníky, strana 18 9 http://www.crmportal.cz/redakcni/hodnota-pro-zakaznika 23.01.2009 20
zákazníka postaveny dlouholeté obchodní vztahy, které pramenily z poznání zákazníka a zčásti také ze schopnosti předvídat jeho chování. Se změnou výrobních činností a s nástupem masové výroby, počátky těchto změn lze datovat do konce 19. století, se výrazně změnila organizace práce. Řemeslníci se postupně změnili v dělníky, kteří se do kontaktu se zákazníkem nemohli dostat, roli kontaktní osoby přebírali obchodníci. Masová výroba vygenerovala, kromě jiného, nárůst nabídky nad poptávkou, tzn. nezbytnou nutnost zabývat se distribucí výrobků v mnohem širším intenzivněji a nutnost kvalifikovaněji a efektivněji výrobky nabízet. 2.2.2 CRM a nástup výpočetní techniky Proto přirozeně vznikala nutnost vrátit se do dob hluboké znalosti zákazníka. Proto je zde možné vystopovat počátky opětovné snahy o dokonalé poznání zákazníka, možnost odhadu nebo vycítění jeho očekávání a potřeb. Ke správnému poznání je ovšem bezpodmínečně nutný dobrý vztah se zákazníkem. Významným pomocníkem k dosažení tohoto poznání se v době na přelomu padesátých a šedesátých let minulého století, stala výpočetní technika. V době ještě na počátcích svého pozdějšího bouřlivého rozvoje. Teprve s rozvojem výpočetní techniky a využití jejích stále se zdokonalujících nástrojů je možné zaznamenat cílenou a promyšlenou snahu co nejlépe poznat zákazníka a jeho potřeby, v počátcích poznamenanou malými zkušenostmi a také mnohdy odmítavým a nedůvěřivým postojem zaměstnanců firem. V každém případě se do rukou marketingových specialistů dostalo poměrně velké množství dat, které bylo možné posuzovat a vytvářet z nich použitelné závěry, které mohou ovlivnit vzájemný vztah výrobce a zákazníka. 2.2.3 Vývoj trhu na přelomu tisíciletí a nutnost zavádění CRM Důvod rostoucího soustředění v tomto období na práci se zákazníky je zřejmý. Situace na trhu již neumožňovala zajištění růstu tržeb a růstu společnosti jednoduchým zvyšováním zákaznické masy, protože nasycenost trhu produkty byla příliš vysoká a existoval již jen poměrně minimální prostor pro zvyšování zisku, např. cestou reorganizací uvnitř firem. Bylo a je nutné zaměřit se více na zákazníka, který představuje stále ne zcela využitý potenciál růstu podílu společnosti na trhu. Vliv na kvalitu trhu a jeho vývoj má také pokračující globalizace společnosti, nutnost uvažovat o trhu komplexně a volit odpovídající nástroje marketingové komunikace, dnes již v mnoha případech zcela integrované do jednotných postupů a přístupů k zákazníkovi. 2.2.4 Hlavní kvalitativní trendy ve vývoji CRM 21
Především vliv aplikací IS/ITC a změna podmínek na trhu (globalizace, vysoká míra konkurence, nasycenost trhu) určují už od nástupu informačních technologií na počátku osmdesátých let minulého století hlavní trendy ve vývoji CRM. Za ty nejdůležitější lze považovat: vedení firem se bude více soustřeďovat nejen na ekonomické ukazatele, jakými jsou růst obratu, pokles nákladů a zisk společnosti, ale stále více bude do rozhodování o strategii společnosti zahrnuto sledování spokojenosti zákazníka a jeho loajalita vůči firmě nebo značce, bude tedy více řízena hodnota zákazníka, než ekonomika společnosti, zákazník bude namísto produktu nebo služby více vyhledávat podporu svých procesů, bude více oceňovat, a tedy bude pro něj mít větší hodnotu firma, která se o něj dokonale postará a uspoří mu čas a finanční prostředky, CRM software se bude více konsolidovat, systémy CRM budou více řešit procesy Back- Office zpracování a analýza dat, tím bude řídícím pracovníkům firem umožněno více se soustředit na podnikání a na podporu procesů Front-Office kvalifikovaný kontakt se zákazníkem, budou stále více využívány tzv. elektronické služby, od sofistikovanějšího vyhledávání informací, až po zprostředkování produktu nebo služeb prostřednictvím www, vývoj a implementace informačních technologií do života jednotlivce a řízení firemních procesů bude příčinou vyšší míry jejich využitelnosti a vzájemné spolupráce, zákazník tak bude lépe rozpoznatelný a nabídka produktů a služeb bude přesnější. 2.3 Nástupci CRM Vývoj nelze zastavit, proto je už v dnešní době nutné využít maximální množství dat, která jsou náplní rostoucích informačních systémů ve společnostech. Využití ovšem předpokládá nejen kvalifikované zařazení informací do souvislostí, ale také pečlivé určení adresátů zpracovaných výstupů těchto dat. 2.3.1 Customer Intelligence dokonalá znalost zákazníka Business Inteligence představuje komplex aplikací IS/ITC, které se výlučně orientují na analytické a plánovací činnosti podniků, 10 Přestože je stěžejním úkolem aplikací Business Inteligence (BI) podpora plánování a řízení společnosti, a to nejen na strategické úrovni, dochází v poslední době stále častěji k integraci funkcionality CRM systémů s aplikacemi BI. Takovou integraci pak můžeme nazvat Customer Intelligence, neboli 10 Dohnal J., Řízení vztahů se zákazníky, strana 83 22
dokonalá znalost zákazníka, jeho hodnoty, preferencí, ale třeba také rizikovosti. Tyto maximálně spolupracující systémy jsou nasazovány především v bankovním sektoru, kde je nutnost dokonalé znalosti zákazníka jednou z podmínek pro snížení jeho potenciálu rizikovosti, a tedy možné ztráty pro firmu. 2.3.2 Life Time Value Management sofistikovanější nástupce CRM S určitou mírou zjednodušení je Life Time Value Management (LTVM) 11 možné definovat jako zisk (ale také ztrátu) vytvořenou zákazníkem během celého jeho vztahu se společností. Jde tedy o systém, který firmám pomáhá odhadnout obchodní a finanční potenciál jednotlivých zákazníků a zahrnout rizika spojená s možností jejich ztráty. Poskytovatelé finančních, telekomunikačních či jiných služeb potřebují trvale pracovat na zvyšování loajality svých zákazníků, protože případná nespokojenost může být rychle využita konkurenčními podniky. Zároveň se snaží dosáhnout růstu vlastního podílu na zákazníkovi - tedy dosáhnout toho, aby zákazník, který má vztahy s několika konkurenčními podniky, využíval v co největší míře služeb jejich vlastní skupiny. Koncept LTVM se do takové situace velmi dobře hodí, protože poskytuje nástroje pro daleko sofistikovanější ohodnocení zákaznického potenciálu a jeho rozvoje. Na rozdíl od jednoduchých a snadno měřitelných parametrů, které vycházejí například z prostého zjištění obratu připadajícího na zákazníka v určitém časovém období, totiž LTVM zohledňuje delší časové období a porovnává výnosy s vynaloženými náklady. Je ovšem zapotřebí připomenout, že takový model nemůže být aplikován, dokud podnik nemá dobře vyřešenu CRM problematiku. Pokud není schopen zaznamenat klíčové údaje o zákazníkovi, soustředit je a dále zpracovat, nemá práce se sofistikovanými modely smysl. 11 http://www.logica.cz/life+time+value+management 26.01.2009 23
3. Řízení přístupu k datům datového skladu. 3.1 Implementace řízení přístupu k datům datového skladu Prvním možným přístupem je implementace definovaných pravidel v programové nadstavbě databázového systému, která realizuje funkce datového skladu - OLAP server 12. Tato vrstva potom je odpovědná za poskytování tržišť pouze těm uživatelům, kteří na ně mají z titulu své role právo, filtrování dat takovým způsobem, aby uživatel získal pouze faktové hodnoty, které odpovídají dimenzionálním položkám, k nimž má uživatel právo podle svého zařazení do určité skupiny. Toto řešení předpokládá, že pro běžné uživatele nesmí existovat jiná možnost přístupu k datům v databázi, než prostřednictvím OLAP serveru. Pokud by uživatelé měli k dispozici nástroj, pomocí kterého by mohli nahlížet přímo na data v databázi (SQL klient), nebylo by možné spoléhat na utajení citlivých dat před neoprávněným přístupem. Druhou možností je zabezpečení dat na úrovni databáze spojené s šifrováním uložených dat. Takové řešení je odolné vůči téměř libovolným pokusům o neoprávněný přístup k datům datového skladu. Bezpečnost dat v systému je zajištěna i v okamžiku, kdy se uživatel dostane k systémovým prostředkům, které mu umožňují přímý přístup do databáze. Při realizaci některých implementací datových skladů, je situace obdobná s tím rozdílem, že: role určují přístup k jednotlivým multidimenzionálním kostkám, resp. omezují přístup k některým dimenzím dané kostky a některým hodnotám (faktům) uvnitř kostky, skupiny definují omezené řezy datovou kostkou. 13 12 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 317 13 Lubor Lacko, Oracle Správa, programování a použití databázových systémů, strana 313 24
3.2 Implementace řízení přístupu k na úrovni metadat S metadaty v organizacích je to podobně. Poprvé se s tímhle slovem setkáte ve chvílích, kdy je třeba o datech něco zjistit, a ono to nějak nejde. Například ve velké organizaci chcete zavést novou verzi staršího systému. Aplikaci před pěti lety napsal programátor. Od té doby funguje skvěle. Jen že kolega programátor už v té organizaci rok nepracuje. Psaní technické dokumentace ho moc nebavilo. Vlastně se ani moc neví, kdo aplikaci přesně využívá a jaká jsou její rozhraní k jiným systémům. V tomto případě je největším problémem: Kde jenom je ta dokumentace? Máme nějaký datový model? Jací uživatelé a kdy systém používají? Jaké další systémy si berou z této aplikace data? Nejobvyklejší popis toho, co znamená slovo metadata, je: jsou to data o datech. Podobně jako s metafyzikou - nejdřív máme data, a pak o nich nějak mluvíme. Jsou to například informace o názvech sloupců v tabulkách a datových typech. V relačních databázích existuje celá řada způsobů, jak se k takovým informacím dostat. Mohou to být systémové tabulky, pohledy, uložené procedury, které uživateli na jeho dotaz vrátí kompletní popis dané entity, ať již jde o tabulku, pohled, proceduru, uživatele, nebo jiný objekt v databázi. Práce s tímto typem metadat je naprosto běžná. Historicky sahá k počátkům sedmdesátých let minulého století v souvislosti s datovými slovníky mainfraimových systémů. Pak nastoupily nástroje typu CASE, které fakticky pracují na úrovni metadat. Jejich hlavní výhoda spočívá v tom, že umí metadata formulovat v jazyku příslušného databázového stroje, a tedy po namodelování struktury databáze její objekty vytvořit třeba v prostředí Oracle, Microsoft, MySQL, nebo úplně jiném. O metadatech se však dá uvažovat v širším kontextu než jenom jako o datových modelech. Nejvýstižnější metafora je tato: kdyby metadata byla románem, řekla by nám příběh celého systému od začátku až do konce. Datový sklad představuje systém, kde je problematika metadat patrná asi nejlépe. Povědomí o datových skladech je dnes poměrně velké, hlavní motivací pro budování centrálního úložiště dat bývá velké množství heterogenních systémů v organizaci. Typickým příkladem může být například telekomunikační firma, která má údaje o konkrétních zákaznících rozptýleny v mnoha systémech: v billingu vidí oceněné hovory, v mediaci má detailní informace o volání, v systému pro vymáhání pohledávek informaci o nezaplacených platbách, v systému call centra informace o zákazníkových kontaktech či 25
stížnostech a v mnoha dalších systémech podporujících další služby informace o jejich využívání. Pro konkrétní informaci - např. najdi mi seznam všech osob, které jsou pro nás ziskové, v posledních třech měsících volaly do Německa, mají aktivovaný roaming a neposílají platby opožděně - by bylo třeba položit dotazy do několika systémů. Každý z nich však může být na jiné platformě, má jiné datové struktury, takže každý takový dotaz by musel vytvořit jiný člověk. Výsledky všech těchto dotazů by se pak musely sjednotit. Jde-li řádově o stovky tisíc dat na výstupu, je takový postup prakticky nerealizovatelný, protože v požadovaném čase danou odpověď není schopen dát, nemluvě o finančních nákladech. Datový sklad takovou situaci řeší tím, že data zpřístupní uživatelům na jednom místě 14. Pro koncové uživatele těch míst může být i víc (jednotlivé data marty), ale všechna mají shodnou technologii, shodný nástroj, kterým se k datům dá přistupovat a shodný popis. Totiž metadata ve stejném formátu. Podíváme-li se na situaci z ještě větší blízkosti, těch míst, která vyžadují nějaký popis metadaty, je více. Základní složkou datového skladu je relační databáze, která složí k uložení dat. Už na tomto místě, alespoň z pohledu datového skladu, nastává problém. Standardní popis metadat je nedostačující - přestože je datový model v případě vhodně zvolených jmenných konvencí srozumitelný (víme, co je dimenze či faktová tabulka, víme, která tabulka a jak udržuje historii). Ze skutečnosti, že k relační vrstvě přistupují koncoví uživatelé (obvykle ti, kteří vyžadují data na velmi detailní úrovni pro své analýzy), vyplývá, že je nutná dokumentace toho, co která tabulka fakticky obsahuje. Uvažme například tabulku, která se jmenuje D_Zakaznik. Je zákazníkem ten, komu se fakturuje? Je jím ten, kdo využívá nějakou konkrétní službu? Je jím ten, kdo fyzicky vlastní telefon? Z pohledu každého oddělení tomu bývá většinou jinak, avšak datový sklad je v organizaci zpravidla jenom jeden. Data do datového skladu putují z primárních systémů. Využívá se přitom datových pump psaných v procedurálním SQL jazyce nebo specializovaných nástrojů pro ETL procesy (extraction, transformation, loading). Transformace jsou někdy triviální - přenos dat v poměru 1:1 z primárního systému. Někdy jsou netriviální, ba dokonce velmi komplikované. Typickými operacemi jsou: náhrada klíčů (lookup), agregace, spojení většího množství tabulek, doplňování chybějících údajů implicitními hodnotami, validace údajů vůči referenčním číselníkům, případě jejich obohacení o další 14 Časopis Computer, Praha 05.04.2001, 26
data. Většina používaných nástrojů obsahuje podporu pro správu metadat ETL procesů, nicméně opět se zde objevuje stejný problém jako v předchozím případě. Datové transformace v ETL procesech nejsou pouze technickým převodem dat jednoho systému do druhého, ale obsahují v sobě (často i komplikovanou) logiku, kterou požadují koncoví uživatelé. Tato logika vychází z nějakého reálného důvodu. Důvod, proč se má dát při validaci údajů přednost jednomu systému před druhým, může být třeba v tom, že při pořizování dat v jednom případě je požadován občanský průkaz, zatímco v druhém případě nikoliv. 3.3 Implementace řízení přístupu k datům na úrovni uživatelské vrstvy Uživatelskou vrstvu datového skladu představují dotazovací nástroje, které umožňují generovat reporty, nebo zpřístupňují data pro komplikované analýzy. V případě reportů se kromě popisu toho, jak je report sestaven a co která hodnota fakticky znamená, objevuje ještě požadavek na další informace (metadata): Kdy byl report sestaven? Z jakých dat?(tj. jak je starý snímek z primárního systému, kdy proběhla poslední ETL transformace a s jakým výsledkem, které primární systémy poskytly data.) V případě OLAP nástrojů vstupují do hry ještě popisy a význam vypočítaných ukazatelů a vypočítaných prvků v dimenzích. Typicky jde o hodnoty různých průměrů, agregací (YearToDate, MonthToDate), porovnávání s odpovídajícími časovými úseky předcházejících let (může jít o kalendářní nebo fiskální období) nebo uživatelsky definované množiny prvků (všechny produkty našeho oddělení, deset nejziskovějších zákazníků). Metadat je kolem datového skladu prostě hodně. Existují specializované nástroje pro jejich správu. Podpora technických metadat, jako jsou datové modely, fyzická realizace transformací, definice vypočtených ukazatelů, lze z příslušných systémů většinou získat, častokrát i v definovaných standardech (zde už můžeme mluvit o metametadatech). Problémem však často zůstává správa byznys metadat, tedy věcného popisu datových entit, důvodů pro konkrétní transformace či vzorce na úrovni OLAPu. A největší výzvou je vazba těchto business metadat s metadaty technickými, která jim odpovídají. Tato vazba je však nutná proto, abychom mohli sledovat celý datový sklad. Bez jeho znalosti je těžké řešit úkoly, jako jsou datová kvalita, impact analýza nebo kvalitní reporting. 27
4. Nekvalitní data a metody jejich konsolidace. 4.1 Čištění, inspekce Některé společnosti zahajují aktivity v oblasti kvality dat ustanovením útvaru soustředícího se na inspekci dat - data quality assurance (DQA) 15. Na základě zjištěného stavu kvality dat pak rozhoduje o způsobu jejich nápravy nebo jejich vyloučení z dalšího zpracování. Se snahou vyloučit určitá data z následného zpracování se setkáváme u projektů zaměřených na migraci dat či implementaci datového skladu. K tomuto kroku je útvar DQA obvykle donucen potřebou akceptování požadavků koncových uživatelů na kvalitu informací. Náprava defektních dat, jako součást inspekce, se provádí prostřednictvím korekcí, oprav či čištěním dat s cílem zajistit garantovanou (uživateli požadovanou) kvalitu informací (dat). Inspekce však přichází pozdě, a navíc je pro společnost neefektivní. Jedná se o tzv. cost adding aktivitu. Společnosti zaměřené pouze na inspekci tak trvale zvyšují své náklady na udržení určité úrovně IQ. A navíc, tento přístup vytváří ve společnostech mylný pocit toho, že se věnují informační kvalitě. 4.2 Příčina nekvalitních dat Kvalita informací (dat) jde ruku v ruce s kvalitou příslušného obchodního či rozhodovacího procesu. Dobře a efektivně fungující proces vytváří kvalitní data. Nekvalitní informace (data) jsou pak symptomem nekvalitně a neefektivně fungujícího procesu. Inspekce kvality informací (dat) nemá vliv na kvalitu obchodních procesů, a tedy neřeší příčinu vzniku nekvalitních informací (dat) ve společnosti. Nezatracujme inspekci, jako takovou inspekci můžeme akceptovat pouze tehdy, pokud s problematikou informační (datové) kvality začínáme. Masivní inspekce v pozdějších fázích již není akceptovatelná, neboť naší snahou by měla být eliminace nákladů souvisejících s inspekcí a fixací dat (scrap and rework). Inspekci pak zaměřujeme pouze na pravidelné vyhodnocování kvality kritických informací společnosti. Obr. 3: Přístup a odpovědnost ve společnostech: Časopis IT Systems 11/2004 15 Časopis IT Systems 11/2004- Kvalita dat str. 24 28
4.3 Management a zlepšování Často se management firem nevydává cestou využití potenciálu již fungujících nástrojů ve společnosti, tzv. zlepšováním. To znamená, že zlepšování (tedy i zlepšování informační kvality) je převážně řešeno prostřednictvím inovace (nákupem sofistikovaného nástroje). Rozhodování a inovace je plně v odpovědnosti managementu a senior managementu společností. Z procesu zlepšování jsou vyloučení ostatní zaměstnanci společnosti, což je skutečnost, která je například v rozporu s požadavky vyplývajících z metodiky TIQM. Inovace však vyžaduje relativně vysoké náklady, je zaměřena na zlepšování zcela specifického, velmi úzkého problému a je založena na technologickém řešení. Zlepšování prostřednictvím inovace nemusí být pro některé společnosti akceptovatelné, např. v případě příprav na privatizaci. S ohledem na současnou ekonomickou situaci a trendy minimalizace nákladů je vhodné najít jinou alternativu zlepšování informační kvality. Měla by být založena na minimálních investicích s maximálním využitím stávajících technologií společnosti. 4.3.1 KAIZEN Proces zlepšování z pohledu pracovních náplní japonských zaměstnanců vystihuje obrázek Oproti původnímu obrázku zde, vidíme nový princip procesu zlepšování. KAIZEN 16 znamená proces trvalého zlepšování se zapojením všech zaměstnanců společnosti do tohoto procesu. Obr. 4: Přístup a odpovědnost ve společnostech po zavedení metody zlepšování KAIZEN Časopis IT Systems 11/2004 Hovoříme-li o všech, pak skutečně mluvíme jak o vrcholovém managementu, tak i jednotlivých zaměstnancích. Přístup KAIZEN, na rozdíl od inovace, klade důraz na adaptabilitu, týmovou spolupráci, všeobecnou orientaci, "cross-functional" přístup, využití stávajících technologií. Hlubší analýzou pak zjistíme, že například týmová spolupráce znamená definování "leadershipu" a "information stewardshipu", všeobecná orientace znamená začlenění všech "knowledge workers" do procesu zlepšování (řešení problému, kterým jsou negativně ovlivněny), a tak bychom mohli pokračovat dále. Zmiňované 16 Časopis IT Systems 11/2004- Kvalita dat str. 24 29