Datové sklady a BI aplikace

Datové sklady a BI aplikace

MFF – část 3

Duben 2004Ing. David Pirkl

7. Přednáška

Obsah Dokončení metodologie BDLC OLAP DM a CRM

Agenda BDLC Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Projektový management

Projektový plán

Definice

uživatelských

požadavků

Technická architektura

Výběr produktůinstalace

Dimensionální modelování

Fyzická úroveň

ETL procesy Nasazení Údržba

a růst

Uživatelské aplikace

specifikace


vývoj

Projektový managementProjektový management

Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

Architektura Je třeba mít plán

Nezačnete stavět dům bez plánu O co je DW dražším projektem?

Návrh architektury slouží Pro komunikaci v rámci týmu Určení plánu Podklad pro učení nových členů týmu Zaručuje flexibilitu a snadnost údržby Pro znovu použití (na dalších projektech)

Architektura Využít Top-Down přístup

Od obecného k detailními Architektura musí vycházet z uživatelských

požadavků

ArchitekturaÚroveň Data (co) Technologie (jak) Infrastruktura (kde) (bezpečnost,

síť, metadata, …)ETL Prezentace

Uživatelsképožadavky a audit

Jaké informacepotřebujeme krozhodování? Jak zapadají do matice BUS architektury (DM a dimenze)?

Jak můžeme získat data,jak je transformovat, jak jedostat k uživatelům? Jakse to děje dnes?

Jak chceme analyzovat data? Jaké jsou hlavníbusiness otázky? Jakměříme výkonnost firmy?

Jaké HW a SW komponentypotřebujeme k úspěchu? Jaképoužíváme dnes?

Model a Dokumentacearchitektury

Dimensionální model: Jaké jsou hlavní fakta adimenze které chcemesledovat? Jaké jsouvztahy mezi nimi? Jaktyto entity mají býtstrukturovány?

Jaké specifické komponenty potřebujemek dostání dat v užitečnéformě na potřebné místo vpotřebném čase? Jakébudou hlavní úložiště data kde budou situovány?

Co budou uživatelépotřebovat k získáníinformací v užitečnépodobě? Jaké druhyanalýz a reportingubudeme potřebovat? Jakéjsou priority?

Odkud a kam proudí data? Máme kapacity na přesun dat ana jejich uložení?Co za specifickékomponenty potřebujeme? Kdoza ně bude odpovídat?

Detailní model a specifikace

Logický a fyzický model: Jednotlivé atributy,datové typy, domény,pravidla pro odvozeníatributů. Jak se zdrojedat mapují na cíle dat?

Jaké produkty podporují potřebné vlastnosti? Jakje lze integrovat?Standardy pro psaní

kódu,jmenné konvence, …

Jaké jsou požadavky na reporty (šablony) – prořádky, sloupce, hlavičky,filtry, ...? Kdo potřebujejaké? Jak často? Jak jetřeba je distribuovat

Jak je možné integrovat nástroje?Jak volat jejich utility, API, …?

Implementace Vytvořit databáze, indexy, backup, …Dokumentace.

Napsat ETL kód. Automatizace procesu.Dokumentace.

Implementace reportingového aanalytického řešení,vytvořit první sadustandardních reportů,školení uživatelů.Dokumentace.

Instalace a testování komponent infrastruktury. Propoj zdroje dat aDW s uživateli. Dokumentace.

Architektura Základní framework architektury (logický model)

Data StagingArea

MetadataCatalog

High Level W arehouse Technical Architecture

The Back Room The Front R oom

DataStag ingServices

Q ueryServices

- Extract- Transformation- Load- Job Control

- W arehouse Browsing- Access and Security- Query Management- Standard Reporting- Activity Monitor

Dim ensional Data Martsincluding atom ic data

Applica tion M odels(e .g . data m in ing)

KeyData

ElementServiceElement

SourceSystems

Presentation Serv ers

Dow nstream /operationa l

sys tem s

Desk top DataAccess Tools

StandardReporting Tools

Dim ensional Data Marts w ithonly aggregated data

The DataW arehouse

BUS

Conform edD im ens ions &Conform edFacts

Architektura Architektura by měla být řízena metadaty

(metadata catalog) Poskytuje parametry a informace pro všechny procesy

(ETL, reporty, …) Informace o DW, zdrojových systémech, ETL, … Např. procedury pro zakládaní tabulek, indexů,

uživatelů, spuštění skriptů, … (informace o tabulce a atributech v metadata katalogu, …)

Umožňuje např. rychlou změnu při upgrade provozních systémů, …

Architektura Data staging area (DSA) je vhodným místem pro

archivování dat z provozních systémů Datový model DSA by měl být navržen tak, aby

podporoval výkonnost ETL procesu a snadnost vývoje ERD modely (kopie OLTP systémů) Dimenzionální model Pomocné tabulky DSA – převod ERD modelů do dimenzionálních

určených k načtení do 1. vrstvy DW (prezentační část)

Architektura Nástroje ETL je možné

Vyvinout sami Zakoupit

Komerční ETL nástroje jsou často poměrně drahé ale zaručují vysokou produktivitu (při správném využití) Má smysl první etapu udělat ručně Pak po schválení výsledků přejí na ETL nástroj

Architektura ETL proces – zabírá až 60 procent celkového

vývojového času na projektu Potřeba vybrat a integrovat dat Problémy

Různé názvy sloupců Chybné hodnoty Neexistující referenční integrita …

Architektura Možnosti získat data

Export z provozního systémů (flat file) Vhodné dohodnout rozhraní a přenechat odpovědnost na

provozovateli OLTP systému Přímé napojení Replikace Někdy je vhodné data komprimovat pro přenos a zase

dekomprinovat

Architektura Typy extrakce

Inkrementální load Načtení dát nových (změněných) od posledního loadu Nová (změněná) data identifikována většinou flag v provozním

systému nebo dle datumu (času) transakce, trigery, log file, … Datum (čas) transakce posledního loadu nutné uložit do metadata

katalogu Většinou tak načítáme velké fakt tabulky

Full load Malé dimenze Při sledování SCD je nutné porovnat s původní dimenzí I v případě velkým faktových tabulek – jestliže není možné

identifikovat v provozním systému co se změnilo od posledního loadu

Architektura Po načtení dat následuje transformace Transformace zahrnuje:

Integraci SCD Kontrola referenční integrity Denormalizace Čištění dat, spojování (merge), rozpojování Konverze datových typů (např. ASCII, EBCDIC) Odvození nových atributů, alokace hodnot na nižší granualitu (např.

náklady) – využití business pravidel Agregace Audit obsahu dat (kontrolní součty, počty řádků, …) Plnění auditních tabulek a metadat Transformace dat pro specifické potřeby (např. pro Data miningové

nástroje) Null hodnoty – identifikace (např. speciálních kódu pro null hodnoty),

nahrazení

Architektura Během načítání dat je třeba kontrolovat a monitorovat:

Naplánování úloh Monitorovat proces načtení – ukládat potřebné informace např.

pro možnost recovery (znovunačtení) Řízení výjimky a špatná data identifikovaná při procesu ETL

(např. duplicity) Exportovat, předat k vyřešení, načíst Identifikovat odpovědnou osobu za data (kvalitu)

Navrhnout postupy řešení chyb při načítání (např. výpadek proudu, DB, …)

Zaslání upozornění na chyby při loadu (nečekat až do rána, že neproběhlo)

Architektura Potřeba nastavit způsoby zálohování a recovery

Potřeba zajistit rychlost a jednoduchost zálohování a recovery Archivace

Fyzická – databáze Logická – modely, skripty, …

Seznam všech tabulek v DW (0. i 1. vrstva) Zhodnotit jak náročné je bude obnovit Které by nešly (obsahují historická dat) Vybrat a rozhodnout co zálohovat Nastavit procesy Vyzkoušet recovery

Architektura Otázky bezpečnosti nejsou v 0. vrstvě (ETL) tak kritické

– není-li určena pro dotazy Pozor při přenášení dat po sítí při loadu

Architektura V metadata katalogu je vhodné udržovat

metadata pro uživatele při získávání dat z DW Kde co naleznou, popis, v jakých reportech se

vyskytuje, … V prezentační vrstvě je třeba zajistit bezpečnost

dat Authentication

Systém hesel, fyzické kontroly (otisky prstů, rohovky), omezení přístupu na základě IP adres, …

Bezpečnost přístupu k databázi, reportům, exportovaným souborům

Authorization Co kdo může vidět – někdy vyžaduje hodně práce zabezpečit

Architektura Monitorovat využití DW Využití pro:

Zvýšení výkonnosti (agregace, indexy, view, …) Podporu uživatelů, školení Marketing DW Plánování (rozvoje, upgrade architektury, …)

Dobré reportovací nástroje by měly podporovat Uživatelskou formulaci dotazů (business vrstva mezi daty a

uživatelem) Podporu využití agregací Rozklad složitých SQL na více dotazů a jejich propojení ve

výsledků Tvorbu odvozených atributů Ochranu před složitými dotazy, které mohou „položit“ DW

Architektura Reportingové nástroje

Desktop Aplikační server Součást RDBMS

Reportingové řešení by mělo podporovat Uživatelskou tvorbu reportů Reportovací server Parametrizované reporty Plánovač plnění reportů (scheduler) Interaktivní reporty Propojení reportů Report delivery (pull, push, email, web, file system) Metadata Pokročilá prezentace (např. barevně označení položek nad určitý limit) Podpora práce s semiaditivními ukazateli Přímý zápis SQL plus SQL builder API

Architektura Dále:

Calculace položet (if then, …) Pivoting (cross tab) Sorting Kompletní formátování (mix tabulek, obrázků, grafů, report s více

sekcemi, …) Podpora grafů Export výstupů (excel, word, …) Uživatelsky přívětivý Drop and down – tvorba reportů Multitasking (nemuset čekat až report doběhne) Cancel query Podpora přístupy k různým zdrojům Bezpečnost Administrace (desktop, web) …

Architektura Existuje několik skupin uživatelů z hlediska jejich

technických znalostí

Oblast Typ uživatele

Papírový uživatel Tlačítkový uživatel Jednoduchý ad-hoc Pokročilý uživatel

Používání počítače Žádná E-mail, Word Word, Excel, PowerPoint Makra, tvorba WWW

DW Spoléhá na pomocostatních

Standardní reporty,default parametry, EIS

Vytvoří jednoduché dotazy (QBE), modifikaceexistujících dotazů, změna parametrů,navigace v hierarchiích

Tvorba dotazů, přímý přístup k databázi

Architektura Informační požadavky se rovněž liší

Informační potřeby – kategorie

Role uživatele Přístup k datům - kategorie

Nástroje Počet osob

Monitoring na vysoké úrovni - klíčové metriky, flags

Senior management Přístup na "tlačítko" EIS - styl nástrojů Malý

Sledování businessu - trh, produkty, zákaznicí, drill-down k detailu

Střední management, marketing, prodejci, podpora zákazníků

Standardní reporty – parametrizované

OLAP style, reportingové nástroje, časování tvorby

Velký

Průzkum . Výjimky, nové problémy a příležitosti, vývoj obchodních případů (business case)

Jako předchozí plus business analytici

Ad hoc analýza OLAP style, reporting, analytické nástroje pro ad-hoc dotazování

Střední

Kompletní analýza – kombinace dotazů, statistická analýza, vývoj modelů

Business analytici a experti na analýzu

Data mining - pokročilé analýzy

Statistické nástroje, data mining nástroje, pokročilé analytické nástroje

Malý

Architektura Potřeba poznat potřeby uživatelů -> navrhnout

správné nástroje pro přístup k datům Vycházet z priorit nejdůležitějších uživatelů DW Vhodné využít web

Např. pro přístup k metadatům, reportům, …

Architektura Otázky infrastruktury je vhodné řešit s expertem z

dané firmy (kde se buduje DW) Navržení HW

DW většinou prudce roste v prvních dvou letech (objem dat, dotazy)

Architektura Existuje mnoho variant řešení:

Vývoj/Testování

Warehouse 0. vrstva

Aplikační server

Desktopnástroje

Warehouse Datové tržiště

0. vrstvaVývoj

Aplikační server

Desktopnástroje

Aplikační server

Desktopnástroje

Aplikační server

Reportingnástroje

1. vrstva0. vrstva

tržiště

Tržiště

Malé/Počáteční řešení

Střední/2. kolořešení

Velké/Enterprise řešení

Architektura Třeba vzít v úvahu business požadavky Faktory

Velikost dat Přírůstky, změny v datech, frekvence loadů, čas pro load Počet uživatelů, jejich aktivita, typy analýz, kolik pracuje

konkurenčně, rozložení časové zátěže Složitost business – řešení Požadavky na dostupnost (regionální, časovou) Znalosti IS pracovníků (umí UNIX, Windows, DBA, …) Finanční zdroje

Architektura Využití paralelního zpracování

Symmetric multiprocessing (SMP) Jeden počítač, sdílejí disk, paměť

Massively parrallel processing (MPP) Více počítačů, každý paralelně, např. tabulky přes několik

počítačů, full table scan paralelně Non-uniform memory architecture (NUMA)

Kombinace SMP a NUMA Musí to HW a SW (OS, RDBMS) podporovat Při výběru OS zvážit i jaké jsou pro něj dostupné

aplikace

Architektura

CPU CPU CPU CPU

SMP

CPU CPU CPU CPU

MPP

CPU CPU

NUMA

CPU CPU

Architektura HW:

Disky (velikost, rychlost, RAID 1-5) Paměť (čím více tím lépe)

Nezapomenout na zdroje pro back-up Volba

OS: UNIX Windows

RDBMS OLAP databáze ETL tool

Architektura RDBMS – hlavní faktory pro uvažování:

Podpora DW Bitmapové indexy Optimalizátor dotazů

Vhodné je se poučit z jiných DW projektů nebo dopředu otestovat výkonnost RDBMS

Existují speciální relační databáze určené pro DW a ne pro transakční Sybase IQ

Architektura Pro front-room nástroje zjistit nároky:

Paměť Disk Platforma

U desktop aplikací vyřešit problém upgrade na nové verze, OS desktop stanic, paměť Záleží na potřebách uživatele co bude za aplikace

používat Stanovit minimální požadavky dle skupin uživatelů

(pasivní, analytici, …)

Architektura Potřeba zvážit nároky na síť

Kapacita, zatížení, množství přenesených dat Bezpečnost – přenos přes síť (ssh)

Databázová konektivita Nativní ovladače OBDC OLE DB JDBC

Využití DNS serveru (ne přímý zápis IP adres), Active directory - metadata

Architektura Metadata – data o datech

„Je to užitečná definice, moc toho neříká“ Metadata

Pro ETL Pro prezentaci

Ohledně metadat je třeba: Sepsat všechna metadata Určit jejich důležitost Určit odpovědnou osobu Rozhodnout zda není vhodné koupit speciální nástroj na podporu metadat Určit jejich uložení a back-up a recovery Vystavit je uživatelům (procesům), kteří je potřebují Zaručit jejich kvalitu a aktuálnost Kontrola

Architektura Metadata:

Zdrojové systémy Umístění, modely, formát, vlastník, popis, frekvence změn, limity

použití, dostupnost, způsob přístupu, práva přístupu, heslo, privilegia, extrakty z provozních systémů (formát, čas, zodpovědnost)

ETL Plánování (schedule) ETL pump, výsledky pump, jakých dat se týkalo

(time stamp – pro inkrementální load), čas loadu, definice tabulek (dimenze, fakta, pracovní), skripty – popis, SCD pro každý atribut, umělé klíče pro produkční klíče (mapování), specifikace postupů čištění dat, transformace - popis, datový model, skripty – popis, agregace popis, auditní dimenze, nastavení bezpečnosti, specifikace back-up, recovery

RDBMS Model (logický, fyzický), partition, indexy, disk využití, bezpečnost,

uživatelé, práva, view definice, uložené procedury, administrační skripty, back-up, recovery

Architektura Metadata

Prezentace Business jména sloupců, tabulek, hierarchií, reporty, business

skupiny požadavků (marketing, obchod, …), uživatelská dokumentace, bezpečnost – privilegia, počty login, délka, počet dotazů, nejvíce využívané reporty (obecně, uživatelem)

Metadata – prostě všechno

Architektura Je potřeba zajistit publikaci dat vs. ochanu data a

bezpečnost Bezpečnost: Fyzické komponenty

Servery, stanice, kabely, switch, … Nebezpečí

Krádež Zničení/vandalismus Oheň Vlhkost Voda Prach Slunce, chemie Elektrické výpadky, zkraty Magnetismus

Architektura Informace: data, finanční dopady, reputace

Data, metadata, emaily, dokumenty, kopie, zálohy Nebezpečí

Vyzrazení strategie, plánů, rozpočtu, … Vyzrazení citlivých dat (čísla účtů, stavy účtů, …) Modifikace dat

Hrozby Odposlech Hacker útoky Fyzická krádež (notebook, dokumenty) Sociotechnika Trojské koně

Architektura SW

Nebezpečí Krádež kódu Krádež SW Trojské koně Viry

Ataky na business Nemožnost poskytovat služby (např. zahlcení serveru) Nemožnost rekonstruovat data (např. objednávku) Terorismus

Architektura Zajistit bezpečnost přenosu informací přes internet

Krytování Symetrické Asymetrické

HW prvky k využití: Routry (pro filtraci paketů) Firewall

Důležitý systém hesel Neodhadnutelný Odolný proti útoku hrubou silou (slovník slov)

Heslo – písmena a číslice Člověk – nebezpečí pro bezpečnost

Hesla na papírku přilepená na monitor Otisky palce, sítnice

Architektura Bezpečnost je proces

Potřeba zakomponovat do firemní kultury Je potřeba

Definovat bezpečnostní politiku Získat podporu vedení Školit a stále připomínat Být ostražití, stále aktualizovat bezp. pravidla Nedůvěřivý (Proč chtějí uživatelé vidět tyto data,

pozorovat log, …)

Architektura Kroky

Taktické Využij antivirové programy (server, desktop), aktualizuj je Zvaž odstranění floppy disků a CD z stanic uživatelů Instaluj firewall, zakaž připojení přes modem ze stanic uživatelů,

nastav bezpečnou komunikaci na internet (přes proxy server) Kontroluj SW instalovaný na počítačích Nastav a vyžaduj politiku hesel Škol uživatele v otázkách bezpečnosti Nastav kontrolní mechanizmy – kontrola logů, špatné přihlášení Zabezpeč back-up media Kontroluj nastavení práv uživatelů (vidí jen co mají?) Fyzicky zabezpeč servery Zajisti skartaci starých záloh, …

Architektura Strategické

Nezávislý bezpečnostní audit Využití asymetrického kódování Nahrazení hesel pokročilými technikami (otisky prstů,

sítnice, magnetické karty) Z pohledu DW – využít bezpečnostní politiku,

kterou firma implementovala dosud

Architektura Návrh a implementace architektury

Vycházet z principu 80-20 20 procent úsilí přinese 80 procent přínosu Nastavit priority a na ty se zaměřit Interaktivní proces – zpřesňování požadavků a návrhu

architektury

Architektura Výstupy návrhu architektury

Plán technické architektury Shrne požadavky uživatelů Návrh budoucí architektury DW

Plán infrastruktury Někdy součástí Plánu technické architektury Popisuje servery, desktopy, síť

Architektura

Uživatelské požadavky(Zahrnující business, data, otázky infrastruktury)

Matice BUS

architektura

Model businessdatových procesů

Logický a fyzický model

dat

Plán technické architektury

Matice vyhodnocení

produktů

Výběr produktů

Implementace

Specifikace Infrastruktury

(a model)

Plán infrastruktury

Data Technologie Infrastruktura

Plán technické architektury Během interview získej i požadavky na architektury

Její první návrh lze udělat už v průběhu interview nebo před a následně upřesňovat

Spolupracuj s vybranými pracovníky (IS) na oponentuře a tvorbě architektury Vypracovat draft plánu Nechat oponovat

Vytvoř model architektury (grafický) Vhodný pro komunikaci

Navrhni postup implementace architektury Vyber prioritní oblasti Odhadni čas a zdroje potřebné pro implementaci

Proveď revizi dokumentu s managementem

Plán technické architekturyDotazník pro interview – Dodatečné otázky na architekturu a infrastrukturu

A. IS business role Jak důležitá je analýza dat při podpoře rozhodování managementu ve Vaší firmě? Jakou roli hraje IS při podpoře rozhodování (analýzy dat)? Mění se toto? (Vlivem konkurenčního prostředí, organizační struktury, …)

B. Technologické směrování Jaký je přístup Vaší firmy k IS/ICT v předchozích letech (striktně Klient/Server, web-base

aplikace, ERP, …)? Existuje plán, specifikace, která určuje požadavky na softwarovou infrastrukturu (DCOM,

CORBA, objektová orientace, …)? Jaké jsou Vaše plány pro nejbližší budoucnost? Jaké plány a záměry v oblasti infrastruktury budou mít dopad na přístup k datům (přesun dat,

načasování úloh, jména serverů, bezpečnost, distribuce software, …) Existuje specifická role pro metadata? Jak jsou řízené? Jaké jsou standardní firemní produkty dnes? Jaké platformy, OS SW, DBMS, klientský SW,

utility. Bude to tak i v následujících letech? Jaké jsou nejužší místa a otázky v oblasti infrastruktury? Kdo odpovídá za architekturu? Existuje nějaká dokumentace?

C. Infrastruktura Kdo všechno je zahrnut do nákupu, instalace a podpoře nové infrastruktury (servery, Sw,

připojení)? Kdo odpovídá za bezpečnostní architekturu? Existuje centrální správa uživatelů, dat, bezpečnosti v organizaci?

Plán technické architektury Plán – nemusí být na úroveň konkrétního

produktu, ale měl by vycházet z potřeb uživatelů Vize jak to do budoucnosti bude Vypsat typy uživatelů, jejich potřeby na přístup k

informacím, požadavky na reporting, …

Plán technické architekturyEXECUTIVE SUMMARY

Business Understanding Project Focus

METHODOLOGY

Business Requirements High Level [PROJECT NAME] Architecture Development [PROJECT NAME] Standards & Products Ongoing Refinement

BUSINESS REQUIREMENTS SUMMARY

Business Issues Information Access

Ad Hoc Operational or “Canned” Reporting

Navigation Data Quality Common Data Elements and Business Definitions Data Management Infrastructure and Utilities Organizational

Software Distribution Education and Training Communications

Miscellaneous

[PROJECT NAME] ARCHITECTURE OVERVIEW Typical Data Flow Metadata Driven Flexible Services Layers

MAJOR ARCHITECTURAL ELEMENTS

Services and Functions Data Staging Services Data Access Services Metadata Catalog Maintenance Modeling

Data Stores Sources and Reference Data Data Staging Area Enterprise Warehouse -- Conformed Data Marts Metadata Catalog

[PROJECT NAME] ARCHITECTURE DEVELOPMENT PROCESS

Architecture Development Phases Architecture Proof of Concept [PROJECT NAME] Standards and Product Selection First Pass Data Model

APPENDIX A – ARCHITECTURE MODELS

APPENDIX B – REQUIREMENTS INTERVIEWS SUMMARY

Plán infrastruktury Tři základní oblasti

Server (HW a OS) CPU, OS, Disk, Přírůstek dat, paměť

Síť Od OLTP do DW Od DW k uživatelům Zabezpečení, frekvence přenosu

Pracovní stanice HW, OS, konektivitu (ODBC, OLE DB, …)

Plán je postupně upřesňován na základě vybraného SW podle plánu technické architektury

Výběr produktů Výběr na základě návrhu architektury, uživatelských

požadavků HW DBMS ETL tool Nástroje pro prezentaci a přístup k datům

Vhodné je testovat vybrané HW a SW komponenty Vytvořit prototyp DW a testovat produkty Nikdy je ale neotestujeme na reálné zatížení Vhodné je např. domluvit s dodavatelem 90 denní testovací

období a potom teprve podepsat smlouvu

Výběr produktů Vytvořit Matici vyhodnocení produktů

Nastavit priority (váhu) jednotlivým kritériím Musí mít … bylo by dobré kdyby mělo

Spolupracuj s výrobcem (ať objasní potřebné informace) Proveď průzkum trhu

WWW stránky Publikace, časopisy DW konference, fórum, portály

Kritéria Dle uživatelských potřeb pro daný ty nástroje Výrobce

Podpora Dokumentace Školení Konzultace Externí podpora (nezávislé forum na webu o produktu, …) Spolupráce s výrobce (dobrá, nekomunikativní, …) Velikost, budoucnost Reference

Výběr produktů Vybrat pro porovnání maximálně 5 produktů Uspořádat prezentaci výrobců

Získat informace na vyplnění Matici vyhodnocení produktů

Ukázka práce produktu Domluvit ukázku u stávajícího zákazníka s podobným

řešením Není-li možné rozhodnout – vytvoř prototyp (2 – 3

výrobci) a otestuj Vhodné přenést na výrobce nebo s ním spolupracovat

Výběr produktů Otestovat produkty v plné šíři, ne jen omezeně

Jednoduché i komplexní funkce Málo i hodně dat Jeden a více uživatelů

Tvorba prototypu – 4 až 6 týdnů Po 2 – 3 letech je vhodné výběr opakovat pro

možný upgrade na nové technologie

Výběr produktů Na co si dát při tvorbě prototypu pozor

Definovat rozsah prototypu Rozsah by neměl být moc velký Vzít rozumnou velikost dat Načíst data v syrovém stavu (neztrácet čas čištěním)

Jednorázové ne vytvářet pro inkrementální Naučit se v rámci tvorby prototypu co nejvíce o

provozních systémech, problémech v datech, HW, SW potřebném

Získej názory uživatelů – ukázat jim výstupy Nenechat se zaslepit očekáváním

Výběr produktů Instalace je závislá na to co je vybráno

HW a SW Potřeba dobře nainstalovat –může dosti ovlivnit

výkonnost řešení Spolupracovat se specialisty, dodavatelem, výrobcem

Nezapomenout na: Příprava místa na HW (servery) Školení administrátorů Testování po instalaci

Výběr produktů Čas potřebný na vytvoření plánu architektury

Techno – politickýKomplexní12+ týdnů

Jednoduché1 – 6 týdnů

Nerozumně Komplexní

n týdnů

Funkčně komplexní8 – 12 týdnů

Systémová komplexitaVýstupy

Datové zdrojePlatformy

Organizačníkomplexnost

Jeden člověk

Globálnífirma

8. Přednáška



Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj


Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

Fyzický design - Agregace Agregace mohou významně zvýšit výkonnost

Někdy nahrazeno OLAP databází Uchování agregací vedle detailních dat v databázi DW Agregace – obvyklé souhrny podle daných dimensí Je třeba vložit vrstvu, která dokáže rozpoznat, zda

uspokojit uživatelský požadavek přímo z detailních dat nebo existuje agregace Umí některé reportingové nástroje Nebo je třeba vyvinout Je to největší obtíž a výzva směrem k agregacím

Fyzický design - Agregace Přidat je rozumné agregace – zvyšuje nároky na prostor

na disku Výběr dat pro agregaci

Dle potřeb uživatelů Např. na základě existujících reportů Vybrat atributy z dimenzí používané pro seskupení (region, kategorie

produktu) Určit jejich kombinace – které atributy jsou používány společně

Dle statistické distribuce dat v DW Např. produktu je 1 000 000 Kategorií – 500 000 – nemá moc smysl agregovat (stále mnoho

řádků) Kategorii – 1 500 – agregovat Počítat frekvence výskytu řádků pro kombinace hodnot atributů

dimenzí Např. 12 měsíců x 256 produktů = XY možných řádků v faktové

V čase se mění – interaktivní cyklus Mažou nepoužívané, přidávají nové

Fyzický design - Agregace Všechny agregace v součtu by měly být optimálně asi

stejně objemově velké jako původní tabulka Každá agregace má svoji faktovou tabulku

A zmenšené verze dimenzionálních tabulek (dle úrovně agregace) Některá fakta musí být vypuštěna – mohou dávat smysl pouze na

detailní úrovni Agregace pak často umožňují přímé porovnání s

uloženými daty plánu (plány jsou často na agregované úrovni) Lze uložit do jedné tabulky

Agregované tabulky mohou být často rozšířeny o fakta typu min_prodej_kč, max_, count_

Fyzický design - Agregace

Sales fact table

Time_key (FK)

Product_key (FK)

Store_key (FK)

Promotion_key (FK)

Dollar_sold

Units_sold

Dollars_cost Promotion dimension

Promotion_key

Promotion_name

Price_type

Ad_type

Display_type

…

Product dimension

Product_key (PK)

SKU

Description

Brand

Category

Department

Package_type

Size

…

Time dimension

Time_key (PK)

SQL_date

Day_of_week

Month

Fiscal_period

Season

Store dimension

Store_key (PK)

Store_ID

Store_name

Address

Region

Division

Floor_plan_type

Fyzický design - Agregace

Sales fact table

Time_key (FK)

Product_key (FK)

Store_key (FK)

Dollar_sold

Units_sold

Dollars_cost

Plan_dollars_sold

Plan_units_sold

Plan_dollars_cost

Category dimension

Product_key (PK)

Category

Department

Time dimension

Time_key (PK)

Month

Fiscal_period

Season

Store dimension

Store_key (PK)

Region

Division

Sales by Category-Region-MonthFact table

Fyzický design Je ovlivněno:

Logický datový model Zvolený RDBMS Objemem dat Způsobem využití dat Nástroji pro přístup k datům

Je třeba: Vytvořit plán fyzické implementace Vytvořit a dodržovat standardy

Fyzický designVytvoř jmenné a databázové

standardy

Fyzický model Revize Plánu agregací

PočátečníStrategieindexace

Databázová instance

Fyzickéuložení

Monitoringužívání

Fyzický design Vytvořit standardy

Jména databázových objektů Jména a cesty k fyzickým souborům

Lze převzít (a případně modifikovat) již existující firemní standardy Příklad konvence – jméno složené ze tří částí

Hlavní část – co je to? (např. zákazník, produkt, účet) Třída – typ objektu (např. průměr, počet, datum, flag) Vlastnost – volitelný, popisuje předchozí dvě vlastnosti (např. počátek,

konec, primární, sekundární) Konvence: hlavni_vlastnost_třída

Ucet_počateční_datum Prodeje_průměr

Zvážit rozlišit logická a fyzická jména Doporučeno stejné – co nejvíce popisné

Fyzický design - standardy Dohodnout se na seznamu slov (Hlavních části) s uživateli

Vytvořit seznam tříd a vlastností Vytvořit seznam používaných zkratek (např. desc =

description) Vytvořit standardy pro pojmenování pracovních tabulek

pro ETL Zvážit poměr mezi popisností názvu a jeho délkou

my_company_billingDW_customer_ID Pozor zda databáze je case senzitive

Brát jako by byla i když není Připraveno pro migraci na novou databázi, která by mohla být

Fyzický design - standardy Využít pro názvy tabulek synonyma

Je pak jednoduší při změně struktury tabulky jenom změnit odkaz synonyma než měnit aplikace

Alternativně lze využít view Nebo materializované view Zvážit výkonnost view tvořené z více tabulek

Vytvořit standardy (adresářovou strukturu a jmenné konvence) pro umístění souboru Zdrojové kódy Skripty Binární soubory Databázové soubory Modely Dokumentace

Fyzický design - standardyDISK A RAID 1

Adresáře

RDBMS Obsahuje databázi

ETL Obsahuje ETL nástroj

LOG Obsahuje log soubory

SCRIPT_PROD Obsahuje produkční scripty

METADATA Obsahuje skripty pro metadata

DIMENZE Obsahuje scripty pro dimenze

ZAKAZNIK Obsahuje scripty pro dimenzi zákazník

crt_zakaznik.sql DDL - vytáří tabulku zákazník

crt_cust_stage.sqlDDL - vytáří data staging tabulky pro

zákazníka

crx_customer.sql DDL - indexy nad tabulkou zakazník

drx_customer.sql DDL - drop indexy

customer_stage.sql Script pro 0.vrstvu

upd_customer.sql Script pro načtení do 1. vrstvy

readme Popis obsahu adresáře

….

FAKTA Obsahuje scripty pro faktové tabulky

SCRIPT_DEV Obsahuje vývojové scripty

DRIVE B RAID 5

DATABASEObsahuje databázové soubory (vlastní

data)

DRIVE C NO RAID

DATASTAGE Obsahuje flat files

TEMPDAT Temp místo pro databázi

JOBLOGS Logy z proběhlých úloh a scriptů

Fyzický design Fyzický model vychází z logického

Některé změny vlivem zvoleného RDBMS Přidány pomocné tabulky (většinou nejsou součástí logického

modelu) Detailní nastavení datových typů, partition, specifikace umístění

tabulky, umístění na disku databáze (souborů) Vhodné využít modelovacího (case) nástroje

Většinou je možné i využít pro tvorbu dokumentace (např. technický popis z jakých zdrojů se plní daný atribut, jaký je typ, transformace, …)

Definovat entitní, doménovou a referenční integritu, null hodnoty Někdy je výhodnější neimplementovat (když jsou čistá data) –

nezatěžuje RDBMS – ale pozor na konzistenci dat

Fyzický design Model by měl obsahovat i indexy Modifikovat model dle potřeb uživatelských nástrojů

Např. vyžadují snow-flake Provedení přibližného odhadu velikosti databáze

Možno využít schopností modelovacího nástroje „Ruční výpočet“

Délka (velikost) řádku Počet řádek, počet řádek přírůstku pro jeden load Pro indexy přidej stejně místa jak pro tabulku Temp space – pro budování indexu musí být dvojnásobný jak index

Pro třídění alespoň velký jak tabulka Započítat metadata tabulky Připočítej agregační tabulky (obecně velikost v souhrnu jako base tabulka) Obecně platí, že DW zabere v součtu 3 až 4 tolik místa jak atomická data Potřeba zahrnout i místo pro testování, vývoj, ETL

Fyzický design Nejvíce místa zabírají

Faktové tabulky Indexy na nich

Dimenze jsou v porovnání s faktovou tabulkou obecně zanedbatelné Výjimka např. velké dimenze zákazníků

Fyzický design Vytvořit počáteční plán indexace

Bude se měnit v průběhu využívání DW – podle analýzy dotazů, doby odezvy, …

Potřeba porozumět jak zvolený RDBMS využívá indexy a jak tvoří plán provedení dotazu

B-tree indexy Pro atributy s velku kardinalitou (např. customer_ID) Klastrované vs. Neklastrované Na jednom nebo více sloupcích

Bitmapové indexy Pro atributy s nízkou kardinalitou (např. pohlaví)

Některé RDBMS disponují speciálními indexy Některé mají zabudovanou podporu star schéma (násobné join)

Fyzický design Faktová tabulka

Indexy na klíčích Jeden pro jeden klíč – RDBMS podporuje využití více indexů

pro jeden dotaz Několik složených indexů – podle cesty dotazu

Lze v případě potřeby i indexy na faktech (když hodně dotazů typu prodej > 1000)

Dimenzionální tabulka Na primárním klíči Bitmapové indexy na atributech dimenze Na atributech sloužících pro join, filtrování, group by

Fyzický design Nastavit a zvážit indexy i pro efektivní ETL Při loadu dat

Zvětší-li se loadem tabulka o 10 až 20 procent je efektivnější smazat a znovu vytvořit index

Kontroluj indexy a statistiky po loadu

Fyzický design Instalace a nastavení databáze

Zdokumentovat nastavení databáze plus důvod DW je náročny na paměť Blocksize

Záleží na potřebách Uložit scripty pro nastavení databáze Nastavit partition tabulek

Většinou podle atributu datum Nastavit umístění souborů na disku

Doporučuje se využít RAID disky (RAID 1 až 5) Optimálně databáze a OS jeden disk, zdrojová data (flat soubory)

druhý disk, tabulky a indexy další dva disky, transakční log další disk, temp další disk

Z hlediska dotazů je vhodné aby fakt na jednom disku a dimenze na jiném

Fyzický design Potřeba vybudovat systém pro monitoring využití DW

Load dat Dotazy Běh procesů Využití zdrojů

Důvody pro monitoring: Výkonnost

Ladění dotazů, indexy, agregace Výběr testovacích dotazů

Podpora uživatelů Sledovat vytíženost, logování uživatelů Pro plánování školení Proč se uživatel už dlouho nepřihlásil – neví jak, nemůže se připojit k databázi

Marketing Že DW je stále více využíván Kdo z uživatelů využívá nejvíce – konkurence mezi uživateli

Plánování Další rozvoj DW dle vzrůstajícího počtu uživatelů, konkurenčních dotazů, času

loadu, velikosti databáze,….

9. Přednáška



Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj


Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

ETL Hlavní základní kámen dobrého DW V prvním kroku je třeba vytvořit plán ETL

Plán: Konceptuální model zdroj-cíl prodění dat (na jednu stránku) Testovat, implementovat nástroj pro ETL nebo využít SQL Graficky zobraz všechny komplexní transformace, generování umělých klíčů,

SDC. Vytvořit prvotní plán sekvenčních kroků Dimenze

Vytvoř a testuj statický load dimensionální tabulky. Primárním cílem je otestovat infrastrukturu (připojení, přenos souborů, bezpečnost – práva)

Vytvoř a testuj SCD proces pro jednu dimenzi Vytvoř load pro zbývající dimenze

Fakta a automatizace Vytvoř load historických dat do faktových tabulek (zahrnuje management

umělých klíčů, a jejich substituci) Vytvoř a testuj inkrementální proces Vytvoř a testuj load agregací nebo load do OLAP vrstvy Vytvoř a testuj automatizaci celého procesu

Vrstvy datového skladu Datový sklad se většinou staví ve vrstvách:

Vrstva Popis ETL náročnost

0. vrstva V nulté vrstvě se uchovávají data z jednotlivých provozních databází. Jedná se většinou o kopie provozních dat 1:1. Data neslouží přímo pro analýzy, ale jako vstup pro další vrstvy.

Převod dat v zásadě 1:1, základní transformační kroky.

1. vrstva Data jsou uložena v datovém modelu datového skladu (tabulky fakt a dimenzí). Na data jsou aplikována integritní omezení. Tato vrstva slouží pro analýzy. Data jsou očištěná a konzistentní.

Náročné transformace ačištění dat, mapování datz 0. vrstvy na datový modeldatového skladu.

2. vrstva Speciálně připravená data pro podporu speciálních aplikací. V podstatě se jedná o jednotlivá datová tržiště.

Náročné transformacez 0. a 1. vrstvy(speciální algoritmy).

ETL Obecně je nutné vyřešit dva základní problémy:

Transformace z různorodých zdrojů Integrace data do datového skladu

zdrojové DB

transformace integrace

homogenní DB DW

ETL Je třeba zajistit dostupnost zdrojových systémů pro

potřeby loadu Přímé napojení Extrakty s danou strukturou

Vychází se z vytvořeného dokumentu mapující vazby zdroj – cíl

Je potřeba Dodržovat standardy (jmenné, psaní kódu) Psát srozumitelné komentáře Hlavičky skriptů Vytvořit knihovny obecně využívaných funkcí Testovat funkčnost Dokumentace

ETL Krok 1 – konceptuální model ETL

Základní, na jednu stránku Mapování zdroj – cíl, poznámky k hlavním bodům Je-li jeden hlavní systém – zdroje logické seskupení

zdrojových tabulek Tři základní fáze ETL

Extrakce – ze zdrojových dat Transformace Load – do 1. vrstvy DW

ETLZákazníci(RDBMS)

Regiony(RDBMS)

DMR systém(COBOL flat file, 2000 sloupců

Jeden na zákazníka)

Měřiče(MS Access)

Čas(MS Excel)

ZákazníkRegion Prodeje

elektřiny Měřiče

Čas odpočtu

Měsíčníspotřeba

SCD pro demografické

a účetní atributy

25 mil zakazniku,10 tis nových neboZměněných za den

15 tis oblasti

Popisky potřebujíupravit

Kontrola RI

Kontrola RI

750 tis. ZakazníkuZa den

….

Kontrola RI

Kdo spravuje75 typů měřičů

Starší nejsou v tomto systému

ETL Krok 2 – nástroj na ETL

Možnosti řešení Kód

T-SQL, PL/SQL, Delphi, … Nástroj

Grafické rozhraní, zrychlení procesů Repositář dat, paralelismus Dražší řešení Informatika, DTS, warehouse Builder

Většinou na první fázi dělat „ručně“ Nezvyšovat náklady na DW Záleží na podmínkách

ETL Krok 3 – detailní plán

Detailně rozpracovat jednotlivé kroky Rozhodnout se nad sekvencí kroků

Nejprve dimenze Pak fakta (plus look-up na umělé klíče)

Zde jedna (i více) stránka pro jednu tabulku v DW Někdy smysl vycházet ze zdrojové tabulky

Doplnit pseudokódem pro transformaci 0. vrstva = data staging area

Místo kde jsou načtená data čištěna, kombinována, archivována, transformována a přenášena do prezentačních vrstev (1. vrstva DW)

ETL Dimenze

Statická SCD Umělé – nejsou v datech (Časová dimenze)

Krok 4 – naplnit jednoduchou statickou (ne SCD) dimenzionální tabulku Load

Ze souboru – výhoda, že soubory lze zálohovat a tak znovu použít při recovery, lze je při přenosu kryptovat, zapakovat

Přímé napojení - stream

ETL Krok 4 – pokračování

I jednoduchá tabulka potřebuje Čištění dat Přiřazení umělých klíčů

Je třeba uchovávat tabulku mapování přirozených klíčů na umělé Využívá se později i pro faktové tabulky Obvykle umělý klíč – integer Možno využít sekvencí

Hlavní transformace – konverze datových typů, kódování – čeština Jsou-li zdrojová data pro dimenzi z více zdrojů (např. zákazník)

Potřeba namapovat na sebe Někdy těžko lze – fuzzy logika (jméno, adresa, …) Existují na to nástroje Uložit do tabulky umělých klíčů přirozené klíče ze všech spojených záznamů

(ze všech zdrojů) Testovat zda vztahy mezi atributy dimenze jsou opravdu 1:1 nebo 1:N


Pro load dat využít bulk funkci I pro load do 1. vrstvy je možné Insert into je pomalé a zapisuje se do log souboru – problém

při velkých loadech Pro load dat do prezenční vrstvy – doporučení

Vypnout loggování Pre-sort data dle primárního klíče (rychleji se načte při indexu na

primární klíč) Při full refresh tabulky – smaž původní data pomocí truncate

table Nelogguje se

Přidává-li se více jak 10 procent dat do tabulky je smysluplné drop a recreate index (záleží na podmínkách, počtu indexů, …)

I při ponechání indexů je dobré je časem přebudovat pro zamezení přílišné fragmentace (fillfactror na maximum)

ETL Krok 5 – SCD

Hlavně se používá technika Typ 2 Přístup

Načíst všechna data a dívat se co se změnilo Využít inkrementálního načítání (načíst jen změny od minulého loadu)

– viz dále u faktové tabulky Hlavně u velkých tabulek SCD typ 1 – je vlastně inkrementální načtení dimenzionální tabulky (jako

full ale inkrementálně) Problém s položky smazanými v OLTP – byly smazány tak nemohou

být načteny – pro DW to ale potřebujeme vědět Triggery Změny v OLTP – nemazat, deaktivovat

Výhodně je načítat jen změny A ještě více pokud OLTP udržuje informaci o typu změny


Identifikovat změny Porovnat s stávající dimenzí

Neexistuje-li záznam – vložit Existuje-li – SCD (dle typu SCD)

Jestliže v dimenzi některé položky mají SCD typ 1 a některé SDC typ 2 musím u položek s typem 1 každou změnu promítnout do všech záznamů pro daný objekt v dimenzionální tabulce

Velké dimenze se zpracovávají podobně jako faktové tabulky

ETL

Změněné záznamyDimeze zákazník

Customer_id

Customer_type

Jméno

Adresa

…

Most recent keymap

Customer_id

Customer_key

Update key map

Lookup maxCustomer key

Add surrogaste Key and load

record

Záznamy s umělým klíčem

Customer_key (PK)

Customer_id

Customer_type

Jméno

Adresa

…

Load to DBMS dimension

table

Umělý klíč

ETL

Dnešní záznamy

Customer_id

Customer_type

Jméno

Adresa

…

Změněné záznamy dimenzezákazník

Customer_id

Customer_type

Jméno

Adresa

…Včerejší verze dimenze

Customer_id

Customer_type

Jméno

Adresa

…

Diff comparePolicy decision

Input do Procesu

Na předchozímslide

ETL Krok 6 – naplnit zbývající dimenze

Obdobně jako předchozí načíst i další tabulky Vytvořit skript pro načtení Časové dimenze

Někdy se využívá tabulkový procesor

ETL Faktové tabulky

Výhodné načítat inkrementálně Jen záznamy změněné od posledního loadu

Podobně i velké dimenze Krok 7 – načtení historických údajů

Vytvořit pumpy pro načtení historických dat Interaktivní proces – nebude pravděpodobně dobře na první

pokus V praxi řada výjimek (co započítat, co ne, …) – potřeba identifikovat

tyto business pravidla Potřeba auditovat součty, počty, … a porovnat s výstupy z provozních

systémů – zvyšuje důvěryhodnost DW


Nahrazení přirozených klíčů umělými Vhodné je zjišťovat aktuální umělé klíče ze speciálních

tabulek, ne přímo z dimenzí (může být pomalé) Lze řešit v dimenze flagem – aktuální záznam a bitmapovým

indexem nad ním Jestliže se načítají faktová tabulka historicky musí se i

historicky přiřadit umělé klíče (platné v čase transakce zachycené v faktové tabulce), ne vzít aktuální umělý klíč!!!

ETL

Sales fact tableProduction ID

Time_id

Product_id

Store_id

Dollar_sold

Units_sold

Dollars_cost

Plan_dollars_sold

Plan_units_sold

Plan_dollars_cost

Most recent key map

product_id

product_key

Most recent key map

store_id

store_key

Most recent key map

time_id

time_keySales fact tableSurrogate key

Time_key (FK)

Product_key (FK)

Store_key (FK)

Dollar_sold

Units_sold

Dollars_cost

Plan_dollars_sold

Plan_units_sold

Plan_dollars_cost

Replace ID umělým klíčem



Load fact tableInto RDBMS


Je-li null hodnota v klíči do dimenzionální tabulky – nahradit klíčem k speciálnímu záznamu v dimenzionální tabulce („Neuvedeno“)

Odvozená fakta je možné uložit fyzicky (jsou-li často přistupována, chceme index nad nimi) nebo vypočítáme až ve view

ETL Krok 8 – inkrementální načtení

Identifikovat co se stalo nového Nová transakce

Přidat záznam do fakt tabulky Update transakce

Změnit záznam ve fakt tabulce Přidat změnový záznam

Smazání transakce Smazat záznam ve fakt tabulce

ETL Technika pro zajištění maximální dostupnosti DW Vhodná pro menší DW

Budou existovat 3 kopie faktové tabulky

ETL

Load_fact_1

Active_fact_1

Dup_fact_1

From data staging

1. Load fact table

Old_fact_1

2. Duplicate load_fact_1

3. Index

4. DW down

5. Rename Active_fact1 na old_fact_1

6. Rename load_fact_1 na Active_fact_1

8. Rename dup_fact_1na load_fact_1

7. DW up

9. Drop old fact table

ETL Krok 9 – Agregace a OLAP

Agregace – někdy třeba rovněž vytvářet inkrementálně (full proces moc náročný časově)

Je-li agregován čas (z dnu např. na měsíce) volby: Nezahrnovat dosud neskončený měsíc Zahrnout – hodnota month-to-day (každý den se přepočítává)

OLAP – viz dále

ETL Krok 10 – automatizace

Načasovat jednotlivé kroky Lze na sebe jednotlivé kroky navázat (např. zápis do tabulky metadat,

že už jeden proces skončil a druhý může začít, existence souboru, …) Získat potřebná metadata

Proces Start Konec Doba běhu Počet přesunutých řádků Status dokončení (úspěšně/neúspěšně) Diskové operace, CPU, … Viz Auditní dimenze u faktové tabulky


Možný postup: Extrakce dimenzí a zápis metadat Extrakce faktů a zápis metadat Procesování dimenzí

Umělé klíče/SCD/…. Čištění dat, zápis metadata

Procesování fakt Umělé klíče, zápis nevyhovujících záznamů Zápis nevyhovujících záznamů Transformace dat

Load dimenze Load fakta Agregace, OLAP Validace loadu proti metadatům Zaměň servery (pro 24 hod DW) Načti datové tržiště Aktualizuj metadata Zapiš metadata o loadu Otestuj správnost a úplnost loadu

ETL Hlavním problémem je kvalita zdrojových dat Obsáhlý problém (Data quality and cleaning) Kvalitní data

Přesnost Kompletnost Konzistence Jedinečnost (stejné názvy pro atributy se stejnou informací) Včasnost

Kvalitní data – „pravda, jenom pravda a nic než pravda“

ETL Problémy v datech

Nekonsistentní používání kódů (Ano, true, T, …) Jeden atribut uchovává více informací Význam atributu záleží na hodnotě druhého atributu Chybějící hodnoty Duplicity Chybné hodnoty Překlepy

OLTP systémy pro podporu transakcí Aby doručili zboží Kvalita dat není na prvním místě Validace dat by mohla neúměrně zdržet zápis transakce Problémy při ručním vkládání

DW – přínos – ukazuje na kvalitu dat Pro zvýšení kvality potřeba získat podporu managementu

ETL – příklad transformaceK

ódov

ání

Měř

ítko

Atri

buty appl A - balance

appl B - balappl C - currbalappl D - balcurr

appl A - pipeline - cmappl B - pipeline - inappl C - pipeline - feetappl D - pipeline - yds

appl A - m,fappl B - 1,0appl C - x,yappl D - male, female

Datový sklad

ETL Nejběžnějším problémem je integrace zákazníků

Standardizace jmen a adres Householding – identifikace ekonomické jednotky Existují specializované nástroje na tento problém

Doporučení ke kvalitě dat Je-li možnost (více potencionálních zdrojů dat) vybrat nejkvalitnější zdroj Prozkoumat data – hledat možné problémy Prezentuj nekvalitu dat managementu – nesmí dojít k názoru, že data

jsou nekvalitní jen v DW Spolupracuj s OLTP správci na odstranění chyb Spolupracuj s uživateli na definici pravidel pro čištění dat Využij specializované nástroje na čištění dat Přenes odpovědnost za čištění dat na provozovatele OLTP (čisté extrakty

pro DW) – je.li to možné

ETL Kontrola správnosti dat

Dotazy vůči provozním systémů Porovnání s DW Možnost automatizovat a ukládat do metadat

Ruční prohlídka Nejde-li testovat vůči provozním (např. informace v DW z více

zdrojů) Hledat odchylky, možné chyby Spolupracovat s uživateli (experty)

Těžko kdy ale bude všechno pasovat se vším

ETL 0. vrstva

Často místo pro zálohy Obsahuje detailní data Je možné z nich rekonstruovat další vrstvy (?inkrementální load

fakt a dimenzí?) Není třeba je zálohovat (data jejich, modely ano)

Může sloužit pro nové transformace (např. pro data mining) Potřeba kontrolovat dostupné místo na disku

Např. i místo přidělené pro růst databáze, zda nedojde k jeho vyčerpání během ETL – problém

Někdy vhodné vytvořit speciální opravné pumpy

Praktický příklad 4 Tvorba modelu a naplnění 1. vrstvy

Využití DTS SQL skripty

Create Naplnění



Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj


Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

Uživatelské aplikace Důležitá část z hlediska „prodeje“ předchozího úsilí Vytvořit šablony (parametrizované) standardních reportů

Operativní Taktické Strategické

Podpořit ad-hoc analýzu Podpořit plánování, stanovení rozpočtu, předpovědi, what-

if analýzy Čerpají data z DW a potřebují výsledky někam zapsat (často i

verze) Zápis do DW (vlastní faktová tabulka)


Potřeba využít flexibilních nástrojů, multidimenzionální pohled na data, data mining

Verifikace Objevování

Jaký je průměrný prodej dlejednotlivých okresů?

Jaké jsou nejlepší prediktoryprodeje?

Jaký je průměrný věk zákazníků?

Co zapříčiňuje odchod zákazníka?

Uživatelské aplikace Potřeba zapojit uživatele Vhodné definovat počáteční množinu reportů co nejdříve po interview

(sbírání uživatelských požadavků) Kroky:

1. Určení počáteční množiny reportů Vybrat 10 – 20 hlavních reportů Identifikovat kandidáty

Např. v excelu soupis reportů z interview, popis, řádku, sloupce, ukazatele, komu slouží

Ukázat uživatelům k doplnění Kategorizovat reporty

Výkonnost (prodej, podíl, hodnota) Trendy Odchylky, výjimky (Top n, odchylky od normálu) Důvody odchylek What-if Dopady rozhodnutí, promocí, …

Nastav priority Identifikuj skupinu A (implementována v první fázi) Skupina B – v druhé, skupina C – možná v třetí

Uživatelské aplikace Pozn: Je-li to možné nekopírovat původní reporty

Většinou nebudou přesně sedět čísla Potřeba dopředu vědět proč Uživatelé ztrácí důvěru v DW

Ukázat uživatelům něco nového

Uživatelské aplikace Kroky:

2. Určit strategii navigace Počet reportů bude rychle růst Potřeba najít způsob jejich uspořádání – přehledné pro

uživatele Podle obsahu, nebo dle oddělení, …


Welcome

Sales volume report Forecastying Pricing analyst Inventory

trackingTo desktopapplication

Market trendtemplate

Market toplinetemplate

Produkt trendtemplate

Product toplinetemplate

Uživatelské aplikace Kroky

3. Vytvořit standardy tvorby reportů Dohodnout standardy pro tvorbu reportů Jmenné (jména reportů, atributů), formátovací (co v hlavičce – datum

vytvoření, počet stran, zdroj dat, pro koho určeno), standardní zkratky – pro lepší uživatelskou orientaci

Naplnit metadata těmito informacemi 4. Vytvořit reporty na detailní úrovni

Vytvoř prvních 10 až 20 šablon reportů Dokumentace Metadata (popis reportů)

Název šablony Popis Frekvence plnění Nastavitelné parametry Default omezení (např. že je za aktuální rok) Způsob výpočtu odvozených faktů Poznámky

Nechat zkontrolovat uživateli

Uživatelské aplikace Nasazení reportů Několik možností

Přístup přes Web Asi nejhodnější, možno rozšířit o přístup k metadatům

Speciální reportingové nástroje Vlastní vývoj

Načasovat plnění reportů Nebo nechat vybrané on-line (např. pro zadání parametrů)

Testovat reporty Na různých strojích, různé dotazy Porovnat s OLTP

Rozdíly (jiná definice faktu, jinak počítá reportingový nástroj, správně v DW a špatně v OLTP – potřeba vysvětlit uživatelům)

Podpora uživatelům – získat od nich zpětnou vazbu, zda jsou reporty bez chyb

Uživatelské aplikace V čase je třeba sledovat reporty

Přidávat nové Aktualizovat staré (nové zdroje, změna stávajících) Monitorovat výkonnost reportů (čas tvorby) Sledovat využívání reportů

Odstranit nepoužívané reporty

10. Přednáška

OLAP Popis – definice Způsoby uložení dat (MOLAP, ROLAP, HOLAP)

Výhody, použití Příklady výstupů Vypočítané ukazatele Bezpečnost na kosce Ukázka Analysis Services

OLAP SW technologie, která

umožňuje analytikům a managerům získat informace z dat rychle, konzistentně a interaktivně za pomoci široké škály pohledů vytvořených z relačních dat a odrážejících pravou dimenzionalitu obchodního světa, kterou rozeznávají uživatelé.

Bezpečnost

Interaktivita

Vizualizace

FlexibilitaOLAP

OLAP OLAP funkcionalita poskytuje dynamický

multidimenzionální přístup k datům, analýzu dat a podporuje analytické a navigační aktivity

OLAP funkcionalita je poskytována pomocí OLAP Serveru

OLAP Server: Výkonný, víceuživatelský server vytvořený pro podporu a správu operací nad multidimenzionálními strukturami uložení dat

OLAP je FASMI Fast

Do 30 sekund (dle výzkumu v Holandsku) Neovlivněno množstvím dat

Analysis Flexibilita (ad-hoc dotazy, vypočítané ukazatele) Důraz na obchodní logiku

Shared Stejné výsledky pro všechny (konzistence dat) Bezpečnost dat – oprávnění uživatelů

Multidimensional Základ analýz OLAP – dimenzionální modelování

Information Důraz na zpracování velkého objemu informací Není důležité kolik GB bude potřeba

OLAP Multidimenzionální uložení dat – multidimenzionální databáze

(krychle) Uloženy data i agregace

Prod

ukt (

druh

)

Čas (den)

P U S Čt Pá S N

Rohlík

Zmrzlina

Sýr

Chleba

OstravaBrno

Praha

28

28 kusů chleba prodaného v Praze v pondělí

Dimenze:Time, Product, Geography

Hierarchie:Druh Značka …Den Týden KvartálMěsto Region Země

roll-up týden

roll-up značkaroll-up region

OLAP Druhy uložení OLAP:

MOLAP – Multi-dimensional OLAP Data i agregace uložení v multidimenzionální databází Rychlé, výkonné, pro menší objemy dat

ROLAP – Relational OLAP Data a agregace uloženy v relační databázi Pro velké objemy dat, rychle se měnící

HOLAP – Hybrid OLAP Kombinace MOLAP a ROLAP Agregace v multidimenzionální databázi, detailní data v relační Rychlé pro sumární informace, pomalejší pro detailní

DOLAP – Desktop OLAP Zjednodušená verze MOLAP nebo ROLAP

OLAP Možno definovat složité výpočty na úrovni OLAP

databáze Např. MDX jazyk – MS Analysis Services 2000

OLAP Výhody uložení dat v OLAP:

Rychlí přístup k datům Uživatelský přívětivé

Standardní rozhraní Drag and drop Vizualizace

Příklad nástrojů MS Analysis Server 2000 Oracle Discoverer SAS Warehouse Administrator, SAS MDDB serverBusiness

Warehouse (SAP) Microstrategy …

Praktický příklad 5 Vytvoření OLAP krychle

MS Analysis Services Ukazatel: Prodej Kč, Prodej Ks Dimenze: Zakaznik (Kraj – Mesto – Jmeno)

Čas (Rok – Kvartal – Mesic – Den) Produkt (Kategorie – Subkategorie – Nazev) Dovozce (Nazev) Prodejce (Pobocka kraj – Mesto – Jmeno)

Prohlídka dat v MS Excel



Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj


Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

Nasazení Zkontrolovat připravenost (SW, HW) serveru a uživatelských stanic

Databázová konektivita, internet, přístup k databázi SW instalovaný Naplánovat nutné reinstalace, upgrade, … Získat login pro jednotlivé uživatele Test na různých stanicích

Vytvořit strategii školení uživatelů Důležité – aby uživatelé opravdu využívali DW Seznámit s daty, jejich význammen, nástroji pro přístup k datům,

metadaty Customizované pro jednotlivé skupiny uživatelů dle jejich potřeb Specializované kurzy pro pokročilé analytiky Při prvním školení základy, ne se snažit jim říci vše, budou ještě další

příležitosti

Nasazení Možné pro školení připravit speciální databázi s

vzorkem dat Rychlejší odpovědi, konzistentní přes více školení

Nasazení Body školení

Představení DW a projektu DW Web site Jak začít

Prohlídka dat Dimenze Fakta Jak je prohlížet

Uživatelské aplikace Předpřipravené reporty Jak se k nim dostat Jak je využívat

Další možnosti Tisk Export do Wordu, Excelu Manipulace s report – grafy, drill-down, …

Aplikace toho co se naučili na reálném příkladě Diskuze

Nasazení Provádět školení, když už DW běží „bez chyb“

Jinak riziko, že uživatelé ztratí důvěru v DW, když ještě bude ve fázi plné chyb

Nastavit politiku:“bez školení – DW není přístupný“ Zmenšit riziko rozčarování nad DW

Nastavit strategii podpory uživatelů Umožnit uživatelům přístup k dokumentaci (DW,

nástrojů pro přístup k datům) a metadatům Vytvořit web portál datového skladu

Nasazení

DW homepage

Fact of the month

Warehouse community

Learn about The warehouse

Standard reportA analysis

What is new

About thereports

Customer services

Sales activity

Cool techniquesOr analysis

DW team

DW discusiongroup

User list And DW team

contact

Public statussummary

Conntact

DW status

Education and class schedule

About data

DWoverview

Data load status

Call tracckingStatus inquiry

Metadata browser

Nasazení Vlastní nasazení se může připodobnit k nasazení SW (verze)

Alfa verze DW Testovat technickou infrastrukturu, ETL, kvalitu dat, výkonnost, reporty,

metadata Interaktivní proces odstraňování chyb Zapojen tým DW případně pokročilí business analyst

Beta verze DW přístupný malému počtu vybraných uživatelů

10 až 15 Musejí být flexibilní, motivovaní, dostupní Zabere jim dost času – potřeba podpory jejich vedoucích Budou pak pro uživatel zdrojem informací o DW

Každá další etapa růstu DW by měla projít beta testováním Finální verze

Umožnit uživatelům přístup ve vlnách (po 10 až 15) – zvládnutelné lépe z hlediska podpory uživatelů

Nasazení Finální nasazení

Uživatel prošel školením a druhý den už může pracovat s DW Co je třeba zkontrolovat:

Desktop stanice Potřebný HW a SW Uživatel má přidělen přístup k DW

Kvalita dat Porovnány výstupy s OLTP Rozdíly vysvětleny, zdokumentovány a vysvětleny uživatelům

Otestovány uživatelské aplikace (a reporty) Uživatel prošel školením Je nastaven způsob podpory uživatelů (zaznamenávání problému

a jejich řešení) Dokumentovat plán nasazení



Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj


Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


a růst


specifikace


vývoj

Správa a růst DW DW se stále se vyvíjející „organizmus“ Je třeba reagovat na změny požadavků, změny zdrojových systémů,

… Správa DW – potřeba zajistit finanční fondy

Obecně bude potřeba na správu asi 50 procent zdrojů co na vývoj Není-li DW využíván je třeba zjistit příčiny

Business sponzor odešel z organizace, nebo už nepodporuje DW? Naplňuje DW požadavky uživatelů? Rozumí uživatelé dimensionálnímu modelu? Prošli uživatelé školením? Mají uživatelé podporu, vědí kam zavolat, jsou jejich problémy řešeny? Neobsahují data chyby? Jsou data dostupná včas (ve správné frekvenci)? Je výkonnost DW dostatečná, není nutné příliš dlouho čekat na odezvu? …

Správa a růst DW Jako v business

Je levnější si udržet stávajícího zákazníka DW než získat nového Podporovat stávající zákazníky DW – zvyšovat jejich loajalitu k DW

(budou o DW říkat ostatním) Důležité jsou první 2 týdny od nasazení

Uživatelé musí cítit podporu Např. vyhlásit úřední hodiny pro dotazy na DW (uživatelé mohou přijít pro

radu a kafe) Pokračovat ve školení

Pokročilá analýza Refresh školení Školení pro nové zaměstnance (pravidelně např. 1 za čtvrtletí) Web stránky DW Newsletter DW Pravidelné semináře při kávě – řešit aktuální problémy, novinky, …

Správa a růst DW DW se stane kritickou aplikací pro firmu

Hlavní zdroj informací Data musí být dostupná co nejdříve Vysoké nároky na řízení DW

Školení správců (nové trendy, nástroje, …) Monitorovat HW, SW, infrastrukturu

Síť, výkonnost, zaplnění disků, … Ladění databáze (indexy, agregace, …)

Upgrade nové technologie Oddělit provozní a vývojové prostředí

Změny provozních systémů Změny ETL Aktualizace metadat

Modifikace provozních systému dle chyb zjištěných při loadu do DW Reakce na nové potřeby uživatelů (nové reporty, …)

Správa a růst DW Monitorovat a marketovat úspěch DW

Sledovat naplnění kritérií úspěchu DW Sledovat

Využití DW (počet login, doba strávená) Počet dotazů na podporu a čas potřebný na řešení

Zaznamenávat např. v DW (vlastní fakt tabulka) Prezentovat managementu Spočítat ROI

Zaznamenat rozhodnutí učiněná po používání DW Část zisk přičíst na vrub DW

Správa a růst DW Marketovat DW

Oproti provozním systémům uživatelé DW nemusí používat

Rozhodovali se bez informací před tím, řada z nich v tom chce pokračovat

Potřeba informovat o výhodách a úspěchu DW Např. „určit mluvčího DW“, který prezentuje DW

Udržovat komunikaci S business sponzorem Uživateli IS pracovníky DW týmem

Správa a růst DW DW se stále buduje

Na první etapu navazují další etapy Jejich realizace opět dle popsané metodologie

Využívá již nainstalované technologie a uživatelské nástroje Reviduje potřeby jejich upgrade nebo přidání nových

Je vhodné ustanovit Řídící výbor DW Složen ze zástupců IS a uživatelů

S vlivem, s důvěrou v informační podporu rozhodování, s drivem k DW, s představou směrování celé firmy

Rozhoduje o prioritách dalšího rozvoje DW, podstatných upgrade, financích na rozvoj

Setkání přibližně jednou za čtvrtletí Ustanovit dokument strategie rozvoje DW

Správa a růst DW Řídící výbor

Je mu předložen k schválení seznam menších změn, jejich priority

Případně co bylo od minule uděláno za menší změny Jsou mu předloženy návrhy na další etapy

Provedeny pro ně hrubě studie proveditelnosti (čas, potřebné finance, …)

Gratuluji Právě jste dokončili tvorbu datového skladu a

úspěšně jste ho nasadili!!!

Tipy a triky budování DW Potřeba získat podporu vedení Nejkritičtější je kvalita dat v provozních systémech

Dopad na náročnost ETL procesu Potřeba široké komunikace s uživateli

Učit práci s informacemi Začít jednoduchou aplikací – rychlí přínos výsledků

Proof-of-concept

11. Přednáška

Agenda CRM Analytické metody – Data Mining

CRM Existuje mnoho definic:

Zákaznicky orientovaná obchodní strategie umožněná současnou a vznikající technologií

Budování bližšího vztahu a poznání mezi zákazníkem a firmou Zvyšování prodeje, loajality zákazníků, zefektivnění servisu

pomocí znalosti zákazníka CRM je koncept nebo manažerská disciplína zaměřená na to jak

firma může zvýšit loajalitu svých nejziskovějších zákazníků za současného snížení nákladů a zvýšení zisku (Subbarathnam Swaminathan, CRM.Talk)

CRM se soustřeďuje na poskytování optimální hodnoty zákazníkovi – za pomoci komunikace se zákazníkem, způsobu prodeje zákazníkovi, servisem zákazníkovi jako i za pomoci tradičních prostředků jako jsou produkt, cena, promoce, způsob distribuce (Melinda Nycamp, Nycamp consulting group)

Více

CRM CRM je a mnoho dalšího:

Firemní filozofie SW, který implementuje marketingové, prodejní,

servisní obchodní procesy Velká řada aplikací Způsob uspokojení zákaznických potřeb a očekávání

Více

CRM 3 základní typy CRM interakce

Prodej – efektivní prodej, tvorba nabídek, znalostní systém, prodejní síť, forecasting

Marketing – zacílení na potencionální zákazníky, získání nových zákazníků, využití data miningu, campaign management, distribuční kanály

Servis – poprodejní podpora, call centum, www aplikace pro zákazníky

Více

CRM CRM označuje zákaznicky orientovaný přístup k

relevantnímu, nákladově efektivnímu a časově příhodnému prodeji zboží (služby) zákazníkovi a zaručující maximalizaci zisku firmy

Zákazník Organizace

CRM Pouze 4% nespokojených zákazníků si

stěžuje firmě Přes 90% nespokojených zákazníků se

nevrátí Každý nespokojený zákazník to oznámí v

průměru 9 známým

Udržet zákazníka stojí v průměru pětinu až šestinu nákladů na získání nového zákazníka

Spokojený zákazník je ochoten platit více Spokojený zákazník to oznámí v průměru 5

znaným

CRM Pravděpodobnost prodeje novému zákazníkovi je

15% zatímco stávajícímu 50% Firma může zvýšit zisk až o 85% udržením 5%

zákazníků navíc Zákaznicky orientované firmy jsou o 60%

ziskovější než tradiční firmy

CRM

Source: Microstrategy

IndividuálníJeden pro všechny

Mas

s m

arke

ting

One

-to-o

ne

Mar

ketin

gový

přís

tup

Produktový přístup

CRM

Plat

ba

Dod

ávka

Prod

ej

Zpr

acov

ání o

bjed

návk

y

Podp

ora

záka

zník

ů

Ved

ení

• Neosobní vztah• Nekonzistentní pohled • Slabá komunikace• Stejné služby pro všechny

Od: Izolovaný zákazník

PodporaDodávka Lidské zdroje

Prodej a marketing

VýrobaŘeditelství Finance

PodporaDodávka Lidské zdroje

Prodej a marketing

VýrobaŘeditelství Finance

• Důvěrný vztah• Jednotný pohled na zákazn.• Komunikace• Služby dle hodnoty zakazn.

DoDo: : Zákaznická orientaceZákaznická orientace

CRM

Starý pohled: Supply Chain (ERP)

Nový pohled: CRM

CustomersCustomers

CustomersCustomers

CRM Základní části řešení CRM

Collaborative CRM Front-end aplikace Zabezpečení kontaktu se zákazníkem Aktuální potřeby – Co se děje

Operativní CRM Operativní rozhodnutí Data pro Collaborative CRM Aktuální potřeby – Co se děje

Analytické CRM Proč se to děje? Back-end systém Získávání znalostí o zákaznících (Data Mining) Data pro operativní CRM

Někdy označováno jakooperativní CRM celé

CRMCRM aplikace

Modely chování zákazníků

Zákazníci

Analýza zákazníků

Vztah (CRM)

Datový sklad

Znalosti o zákaznících

CRM – loajalita zákazníka

Nový zákazník Podpora stávajícího zákazníka

Náklady

Příjmy

Loajální a spokojenýzákazník

Podpora prodejecross-selling, up-selling, …

Získání zákazníka

CRM

Hodnota zákazníka(Life time value)

Loajalita

Cross sellingUp selling

Představ služby a produkty

CRM

Marketing

Prodej

PodporaOpe

rativ

ní C

RM Marketingové

analýzy

Prodejníanalýzy

Zákaznické analýzyA

naly

tické

CR

M

Web

Call centrum

Přímý prodej

Col

labo

rativ

e C

RM

Plánování/Analýza

Akce Zpětná vazba

CRMA

naly

tické

CR

M

Datový sklad

Marketing Prodej Zákazníci

Reporting OLAP Data Mining

Segmentace

Kampaně

Churn (odchod zákazníka)

Detekce podvodů

Credit scoring

Event Scheduling

Predikce

Plánování promocí

Cross selling

Ope

rativ

ní C

RM

Col

labo

rativ

e C

RM

CRM

•Automatizace prodeje•Předpovědi prodeje•Hledání příležitostí•Objednávkový Mgt.•Náhrady, Slevový Mgt.•Kategory Mgt.

Prodej

•Marketingové předpovědi•Kampaň Mgt.•Event Mgt.•Promoce•Katalog Mgt.•Marketingový mix•Balíčky

Marketing

•Předpověď potřeby podpory•Průzkumy spokojenosti•Zákaznická péče•Reklamační řízení•Náhrada zboží•Call, web centrum

Podpora

Prodej

Před prodejem

Po prodeji

Udržet zákazníkovuloajalitu

Personifikace

Zesílit zákazníkovu spokojenost

Čas CRM úkol Řešení

Ana

lytic

ké C

RM

Ope

rativ

ní C

RM

Col

labo

rativ

e C

RM

CRM

CRM DB

Kom

unik

ace

se z

ákaz

níke

m

Ana

lytic

ké C

RM

Ope

rativ

ní C

RM

Col

labo

rativ

e C

RM

Prodejny

Fyzická

Face-to-faceDirect mail

Call centrum

Telekomunikace

SMSMobil

Web

Internet

ChatEmail

CRM – kroky k úspěchu

Celopodnikový konsenzus na vývoji a nasazení CRM řešení

Vytvoření CRM projektového týmu Analýza obchodních potřebPlán CRM aktivit

Výběr CRM SW

Výběr dodavatele

Tvorba CRM aplikací a nasazení

Údržba a růst CRM řešení

Krok1

Krok2

Krok3

Krok4

Krok5

Krok6

Krok7

Krok8

CRM – začít v malém

• Datová architektura • Cílení analýza zákazníků• Využití kanálů - Mail - Call centrum - Web - Prodejní místa - …

Fáze 2

Kampaně na podporu zákazníků

• Business processes reengineering • Nákup CRM systému• CRM orientace organizace• Training CRM technologií

Fáze 3

Prorůstání CRM v organizaci

• Dlouhodobé plánování• Strategické řízení zákazníků• Rozšíření systémů

- Architektura- CRM

• Nové možnosti kanálů- Call centre- E-commerce

Fáze 4

Dlouhodobé plánování CRMVysoce ziskové kampaně

Fáze 1

• Současné obchodní problémy/příležitosti • Optimální start: - Cross-selling - Churn - Direct mailing

CRM Úspěšné CRM stojí na pěti pilířích:

Strategie Zákazníci (cílový segment, potřeby, nároky, chování, zvyky, ...) Trh (otevřenost trhu, velikost, růst, konkurence, …) Produkt (cena, balíčky, vlastnosti, …) Kanály distribuční (preference zákazníků, trendy, náklady, …) Zaměstnanci (schopnosti, znalosti, školení, motivace, …)

Informace DW, Householding, …

Funkcionalita Ohodnocení zákazníka Risk analýza Segmentace Modelování chování Cílený marketing (Campaign management)

Integrace Integrace kontaktu se zákazníkem a informací a analýz o zákazníkovi

Technologie Podpora funkcionality (reporting, DM, Statistika, …)

CRM – hodnota zákazníka

Potencionálnízákazník

Novýzákazník

Stávající zákazník

Dřívější zákazník

Cílovýtrh

Novýzákazník

Začátek vztahu

Vysokáhodnota

Vysokýpotenciál

Nízkáhodnota

Neřízenýodchod

Řízenýodchod

Nábor Aktivace CRM management

Zpětná vazba

CRM - metriky Kdo je náš zákazník?

Profilace Demografie “Firmografie”

Jak se k němu můžeme dostat? Segmentace

Jak s námi zákazníci přicházejí do kontaktu ? Face-to-face Katalog Direct mail Internet

CRM - metriky Jaká je hodnota zákazníka pro firmu?

Ziskovost Lifetime Value Loajalita

V jakém životním cyklu se zákazník nachází? Počáteční fáze Růst Dospělost

Jaké jsou zákazníkovy postoje? Jak se zákazník v čase mění?

CRM „Nábor“ zákazníků:

Jaké jsou charakteristiky dobrých zákazníků? Na které potencionální zákazníky bych se měl zaměřit? Jak mohu zvýšit odpovědi na promoce? Jak mohu předpovědět, zda potencionální zákazník bude dobrý

zákazník? Hodnota zákazníka v čase:

Jaká bude celoživotní hodnota zákazníka? Cross marketing (Jaké další produkty mohu zákazníkovi prodat)?

Retence a odchod zákazníků: Kteří zákazníci pravděpodobně odejdou ke konkurenci? Které zákazníky chci nechat odejít? Které zákazníky si chci

udržet?

DM Analytické aplikace -> předávám slovo SPSS CR

Praktický příklad Praktický příklad

Děkujeme za pozornost

Ing. David [email protected]

Datové sklady a BI aplikace

Documents

Transcript of Datové sklady a BI aplikace