Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Zuzana Fišerová
Business Intelligence v řízení obchodních procesů malých a středních firem
Bakalářská práce
2009
Čestné prohlášení: Prohlašuji, že jsem tuto bakalářskou práci vypracovala samostatně. Veškeré použité podklady, ze kterých jsem čerpala informace, jsou uvedeny v seznamu použité literatury a citovány v textu podle normy ČSN ISO 690.
V Praze dne 5. 1. 2009
Podpis: ........................................
Poděkování: Ráda bych na tomto místě poděkovala Ing. Ivě Stanovské za vedení této práce a za mnoho přínosných podnětů a Ing. Petru Šprunglovi za cenné rady a připomínky k této práci.
Abstrakt Bakalářská práce se zabývá problematikou Business Intelligence, konkrétně využitím nástrojů Business Intelligence pro analýzu a monitorování obchodních dat SW firmy. V teoretické části jsou popsány základní principy a nástroje BI. Tato část je ale omezena jen na oblasti BI, s kterými je v projektu pracováno. Praktická část je věnována tvorbě BI řešení pro vyhodnocování obchodního plánu plněním zakázek (obchodními případy) s hlavní orientací na definování a implementaci výstupů (reportů). Práce ukazuje vhodný postup při řešení BI úloh, a na praktickém příkladě uvádí obsah jednotlivých fází a kroků projektu.
Abstract This bachelor paper deals with the issues of Business Intelligence, concretely the use of Business Intelligence tools for the analysis and monitoring of SW company’s data. The theoretical part describes the basic principals and tools of BI, however it is only limited to those areas of BI that are relevant to the actual project. The practical part concentrates on creation of BI solutions that help evaluate business plans by fulfilling orders (business transactions) while focusing on the definition and implementation of outputs (reports). The paper suggests the suitable process of resolving BI problems, and shows on an concrete example the content of the individual phases and steps of the project.
Obsah OBSAH .................................................................................................................................... 1 ÚVOD ....................................................................................................................................... 2 ODDÍL A – TEORETICKÁ ČÁST ............................................................................................ 4 1.
BUSINESS INTELLIGENCE ........................................................................................... 4 1.1 1.2 1.3
DEFINICE POJMU BI .................................................................................................... 4 PRINCIPY BI ............................................................................................................... 5 ZÁKLADNÍ KOMPONENTY BI ......................................................................................... 5
ODDÍL B – PRAKTICKÁ ČÁST ............................................................................................ 11 2. BI ŘEŠENÍ: VYHODNOCOVÁNÍ PLNĚNÍ PLÁNU ZAKÁZEK PRO OBCHODNÍ PŘÍPADY ............................................................................................................................... 11 2.1 CHARAKTERISTIKA SPOLEČNOSTI .............................................................................. 11 2.2 SPECIFIKACE UŢIVATELSKÝCH POŢADAVKŮ ................................................................ 12 2.2.1 Katalog uživatelů ................................................................................................ 12 2.2.2 Požadované výstupy .......................................................................................... 13 2.2.2.1 Reporty ....................................................................................................... 13 2.2.2.2 Poţadavky na analýzu ............................................................................... 17 2.2.3 Katalog požadovaných ukazatelů ...................................................................... 17 2.3 MAPOVÁNÍ ZDROJOVÝCH SYSTÉMŮ ............................................................................ 21 2.3.1 MX Contact ......................................................................................................... 21 2.3.2 Data obchodních plánů ...................................................................................... 24 2.4 NÁVRH BI ŘEŠENÍ ..................................................................................................... 26 2.4.1 Celková architektura celého řešení BI a DWH firmy .......................................... 26 2.4.2 Dimenzionální (multidimenzionální) modelování ............................................... 27 2.4.2.1 Návrh dimenzí a jejich charakteristik.......................................................... 27 2.4.2.2 Návrh ukazatelů a jejich charakteristik a vazby mezi dimenzemi a ukazateli 29 2.4.3 Modelování datového skladu ............................................................................. 31 2.4.3.1 Návrh logické struktury DWH ..................................................................... 31 2.4.3.2 Fyzický model............................................................................................. 35 2.5 TECHNOLOGICKÁ PLATFORMA ................................................................................... 37 2.6 IMPLEMENTACE VYBRANÉ ČÁSTI A JEJÍ TESTOVÁNÍ ...................................................... 39 2.6.1 Implementace (realizace) prezentace požadovaných výstupů s využitím zvolených klientských aplikací ....................................................................................... 39 2.6.1.1 Shrnutí poţadovaného výsledku ................................................................ 39 2.6.1.2 Logika ......................................................................................................... 40 2.6.1.3 Tvorba reportu ve vývojovém prostředí...................................................... 43 2.6.1.4 Tvorba sestavy (sady reportů) ................................................................... 47 2.6.2 Testování reportů ............................................................................................... 50 3.
ZÁVĚR ........................................................................................................................... 52
SEZNAM LITERATURY ........................................................................................................ 53 TERMINOLOGICKÝ SLOVNÍK ............................................................................................. 55 SEZNAM POUŢITÝCH TABULEK ........................................................................................ 56 SEZNAM POUŢITÝCH OBRÁZKŮ ....................................................................................... 56 PŘÍLOHY ............................................................................................................................... 57
~1~
Úvod Pro vedení podniku je obzvlášť v dnešní době velmi důležité, aby firma měla dostatek kvalitních a dobře strukturovaných informací, a to nejen o zákaznících, ale také o interních procesech a aktivitách. Je nezbytné umět monitorovat a analyzovat chod firmy. To ovšem není vůbec jednoduché. I když je v centru zájmu střední firma, objem dat, který produkuje, je poměrně rozsáhlý. V mém konkrétním případě je třeba pracovat s podklady z několika oblastí, jako jsou účetnictví, informace o projektech, o zaměstnancích a jejich pracovních výkonech tak i samozřejmě údaje o zákaznících či obchodních partnerech.
Data
z jednotlivých oblastí spolu úzce souvisí, i když jsou sledována vždy z určitého úhlu pohledu (obchod, realizace, finance) a bohužel i v jiné aplikaci. Vedení firmy ale vyžaduje, aby bylo možné se na data dívat z různých pohledů, v různých časových horizontech a aby se zobrazovala jen ta data, která jsou pro daný případ potřebná. Tedy aby stačilo „kouknout a vidět“. A přesně to je úkol pro Business Inteligence, které pro zpracování dat používá různé specializované nástroje. V mé bakalářské práci se právě zpracováním dat do podoby vyžadované vedením podniku budu zabývat. Ráda bych v této práci popsala celé BI řešení. Ovšem popsat podrobněji celý proces není možné v práci tohoto rozsahu. Proto stručně popíši celý proces a více se zaměřím na oblast návrhu BI řešení v oblasti analýzy a na realizaci požadovaných výstupů s využitím zvolených klientských aplikací v oblasti implementace. Předmětem bakalářské práce je tvorba řešení pomocí nástrojů Business Intelligence pro středně velkou firmu, která působí v oblasti vývoje softwaru. Z důvodu citlivosti informací není název firmy v práci uveden. Mým přínosem v projektu bude tvorba výstupů (reportů) pro uživatele, které se pokusím navrhnout tak, aby co nejlépe vyhovovaly jejich potřebám. Cíl bakalářské práce Cílem této práce je realizace vymezené části konkrétního BI projektu zaměřené na řešení pro monitorování a analýzu obchodních dat s využitím BI nástrojů Microsoft Server SQL 2005. Dílčí cíle: Definovat požadované výstupy Zvolit zdrojové systémy Vytvořit logický a fyzický model datového skladu
~2~
Popsat implementaci požadovaných výstupů s využitím klientských aplikací Postup řešení Na začátek je třeba si vytvořit teoretický základ o Business Intelligence. Zde bude vysvětlen samotný pojem Business Intelligence (BI), z jakých se skládá komponent a jakých nástrojů a technik využívá. V praktické části se přístupy a techniky Business Intelligence pokusím aplikovat na realizaci konkrétního požadavku: „analýzy a monitorování vývoje a stavu obchodních případů“. Pro tvorbu BI řešení pro obchodní případy je třeba nejprve zjistit požadavky uživatelů. Podle nich pak sepsat požadované informace a následně navrhnout uskupení těchto informací (dat) do přehledných tabulek tak, aby co nejlépe vyhovovaly požadavkům uživatelů. Tyto tabulky budou sloužit jako vzor pro vzhled reportů. K požadovaným datům je třeba definovat vhodné datové zdroje. Poté už je možné přejít na návrh BI řešení, které zahrnuje definování dimenzí, ukazatelů a jejich vztahů. Dalším krokem je návrh datového skladu - jeho logické a fyzické struktury. Poslední částí projektu je implementace řešení. Podrobně bude popsána jen implementace požadovaných výstupů, tedy sestav (reportů) a také testování těchto sestav. Použité metody Z předchozího textu vyplývá, že v práci jsou použity tyto metody: Analýza uživatelských požadavků Datová analýza Datové a dimenzionální modelování Výstupy Výstupem práce jsou data uspořádaná a prezentovaná dle požadavků, které si definovali uživatelé na počátku projektu. Z výstupů by mělo být možné vyčíst podrobné informace o plánovaných a předpokládaných příjmech firmy z různých pohledů.
~3~
Oddíl A – Teoretická část 1. Business Intelligence V teoretické části bych ráda představila Business Intelligence (BI) jako takové. Nejprve bude vysvětlen samotný pojem, principy BI a nakonec základní komponenty, které vstupují do BI řešení. Pozn.: Hlavní myšlenky tohoto oddílu jsou čerpány ze zdroje [NOV] .
1.1
Definice pojmu BI Čas je v dnešní době velmi důležitou komoditou, za kterou jsou lidé ochotni platit nemalé
peníze. Tím více toto platí v podnikání. V oblasti řízení firmy potřebují manažeři i podnikoví analytici v co nejkratším čase získat dostatek objektivních a relevantních informací, aby se mohli co nejlépe rozhodovat. Ovšem objem informací, který je obklopuje, je nemožné obsáhnout. Takže musí mít přístupné co nejlépe postavené nástroje, se kterými pro ně bude snadné pracovat a které jim poskytnou jen pro ně potřebné informace. Tyto informace musí být srozumitelné, důvěryhodné, snadno dostupné a musejí být poskytnuty ve správnou chvíli. Procesem získávání informací s těmito vlastnostmi se zabývá právě odvětví Business Intelligence (BI). BI často využívá konceptu datového skladu. Proto se často stává, že lidé vnímají BI jako synonymum ke slovu datový sklad. To ovšem není přesné, protože BI může fungovat i bez datového skladu. Do nástrojů BI patří i vrstvy nad datovým skladem a nástroje pro zpracování dat z datového skladu, jako je například OLAP nebo reporting. Konečným cílem BI je pak poskytnout srozumitelné, uspořádané, analyzovatelné a aktuální informace z podnikových databází i externích zdrojů, které jsou využitelné při řízení firmy. Na tomto místě je dobré uvést doslovnou citaci termínu BI České společnosti pro systémovou integraci: „Business Inteligence (BI) představuje komplex přístupů a aplikací IS/ICT, které téměř výlučně podporují analytické a plánovací činnosti podniků a organizací a jsou postaveny na principu multidimenzionality, kterým zde rozumíme možnost pohlížet na realitu z několika možných úhlů.“[NOV] Pojem Business Intelligence jako první použil roku 1989 Howard J. Dresner a definoval jej jako„sadu konceptů a metod určených pro zkvalitnění rozhodnutí firmy“.
~4~
1.2
Principy BI V této kapitole budou shrnuty základní principy, nástroje a komponenty BI řešení.
Komponenty, které zde budou popsány, jsou základem řešení, které je objektem této práce. BI pokrývá oblast analytických a plánovacích funkcí firmy v oblasti podnikového řízení. To jsou především tyto oblasti: Prodej
Controlling
Nákup
Majetek
Výroba
Řízení lidských zdrojů
Marketing
IS/ICT atd.
Finanční řízení
Cílem BI je řešit problémy informačních (transakčních) systémů, jako je nedostatek a nedostupnost analytických informací a vytvořit tak prostor pro zkvalitnění řízení firmy. [PIR] Na data se nahlíží přes multidimenzionální pohledy. Druhým principem BI je uspořádání dat do hierarchických struktur, které umožní pohled v různých úrovních rozpadů a agregací. Zdrojem dat pro BI jsou produkční databáze transakčních systémů. Uživateli výstupů BI řešení jsou především top a střední management a datoví analytici firem a institucí.
1.3
Základní komponenty BI Komponenty BI řešení nejsou striktně dané. Použití komponent záleží na potřebách a
možnostech podniku. Do popisu komponent budou zařazeny jen ty, které budou využity pro realizaci projektu. Nejprve ale představím jednotlivé vrstvy BI řešení. Komponenty přiřazeny k jednotlivým vrstvám. Přiřazení komponent do vrstev je znázorněno na obrázku č.1. Detailnější popis komponent bude následovat po popisu jednotlivých vrstev.
~5~
Obrázek 1 Obecná koncepce architektury BI [zdroj: NOV]
Vrstvy BI architektury Vrstva extrakce, transformace, čištění a nahrávání dat Na této vrstvě probíhá přenos dat ze zdrojových systémů (ERP, CRM, specifické aplikace, externí systémy atd.). Zde se data čistí. Čištění dat je jednou z nejnáročnějších operací BI. Po vyčištění dat se data nahrají do míst, na kterých jsou data uložena. Do komponent této vrstvy patří: -
ETL – extrakce, transformace, načítání a čištění dat
-
EAI – integrují podnikové systémy, redukují počet vzájemných rozhraní (v projektu nebude komponenta použita)
Vrstva pro douložená data Tato vrstva zajišťuje ukládání, aktualizaci a správu dat. Data jsou zde ukládána do logických struktur. Její součástí mohou být: -
Dočasná úložiště dat (Data Staging Areas) – nebude v projektu použito
-
Operativní datová úložiště (Operational Data Store) – nebude v projektu použito
-
Datová tržiště (Data Marts)
~6~
-
Datové sklady (Data Warehouse)
Analytická vrstva Analytická vrstva čerpá data z logické struktury. Probíhá zde tvorba vzhledu výstupů a samotná analýza dat. Do této vrstvy spadají komponenty: -
Reporting
-
OLAP (On-Line Analytical Processing) – multidimenzionální databáze
-
Data Mining – nástroje pro dolování dat
Prezentační vrstva Tato vrstva zabezpečuje komunikaci koncových uživatelů s komponentami BI řešení. Hlavní úkol vrstvy je realizuje požadavky uživatelů na analytické operace a dle toho pak poskytnout výstupy. Tyto služby může zajišťovat: -
Portálová aplikace (na principu webových technologiích)
-
EIS (Exclusive Information Systems) manažerské aplikace, které integrují všechny důležité datové zdroje (v projektu nebude použito)
-
Jiné analytické aplikace
Komponenty BI Na následujícím obrázku jsou zobrazeny komponenty BI a jejich vzájemné vazby.
Obrázek 2 Hlavní komponenty BI a jejich vazby [zdroj: NOV]
~7~
Produkční systémy (zdrojové, primární, transakční, OLTP) Tyto systémy nepatří do skupiny BI aplikací. Ale komponenty BI z nich získávají data. Jsou to jedny z nejdůležitějších a často jediných vstupů pro BI. Data jsou v těchto aplikacích modifikována v reálném čase. To znamená, že změny jsou v nich zobrazovány hned po jejich uložení (na rozdíl od datových skladů). Ovšem na druhou stranu tyto systémy nejsou navrženy tak, aby pracovaly s analytickými úlohami. Problémem, který musí BI řešit při extrakci dat z produkčních systémů, je nestejnorodost obsahu i formátu dat. BI musí zajistit výběr relevantních dat a zároveň to, aby data byla vzájemně integrována.
ETL (Extract, Transformation and Loading) Tato komponenta také bývá často označována jako datová pumpa. ETL zajišťuje výběr dat ze zdrojových systémů (extraction). Tato data poté upraví do požadovaného formátu (tranformation). Neopomenutelnou úlohou ETL je také čištění dat. Poslední fází funkcionality datové pumpy je nahrání dat do datového skladu v podobě specifických datových struktur. Datové pumpy přenášejí data v pravidelných časových intervalech, v takzvaném dávkovém režimu (na rozdíl od EAI). Datový sklad (Data Warehouse) Datový sklad je většinou centrem BI řešení. Datový sklad definoval Bill Inmon1 takto: „Datový sklad je integrovaný, subjektově orientovaný, stálý a časově rozlišený souhrn dat, uspořádaný pro podporu potřeb managementu.“ Integrovaný znamená, že data jsou ukládána v kontextu celé organizace, ne jen v kontextu za jednotlivé části firmy či aplikace. Subjektově orientovaný vyjadřuje rozdělení dat dle jejich typu a to jen jednou. Nemělo by nastat, že jedna informace bude uložena několikrát v jedné databázi. To, že je datový sklad stálý, označuje skutečnost, že se do něj nedají ručně ukládat data, ani je nijak měnit či mazat. Časová definice vyjadřuje přítomnost časové dimenze. Datový sklad může být uspořádán podle dvou datových modelů (schémat): a) Star schéma = typ hvězda
1
Inmonn Bill, jeden ze zakladatelů Datawarehousingu
~8~
V centru je tabulka faktů. V této tabulce jsou uloženy hodnoty ukazatelů (číselné hodnoty) plus cizí klíče dimenzionálních tabulek. Tyto dimenzionální tabulky jsou propojené jen s faktovou tabulkou a slouží pro ukládání textových informací o ukazatelích uložených ve faktové tabulce. b) Snowflake schéma = typ sněhová vločka V tomto schématu nejsou některé dimenze navázané přímo na faktovou tabulku, ale jsou navázané na jinou dimenzionální tabulku. Toto řešení se používá například při potřebě tvorby hierarchie. V tomto schématu jsou tabulky v normalizované formě. Datová tržiště (Datamarts) Datová tržiště pracuje v podstatě na stejném principu, jako datový sklad. Na rozdíl od datového skladu, datové tržiště nezobrazuje pohled na celou firmu, ale jen data určité oblasti řízení, či aplikace. Pohled přes datové tržiště je specializovaný pro menší okruh uživatelů. Jsou dva přístupy pro použití datových tržišť. a) Tvorba několika datových tržišť, které mají být ve výsledku propojené a poskytovat tak pohled na celou firmu. b) Tvorba datových tržišť nad datovým skladem. OLAP databáze OLAP databáze bývají složené z jedné či více OLAP kostek. Již na této úrovni jsou prováděny agregace díky vytvořeným hierarchickým strukturám. OLAP může mít několik podob: MOLAP (multidimenzionální OLAP) Data jsou uložena v multidimenzionálních OLAP kostkách, ve kterých je vždy začleněna dimenze čas a potřebný počet dalších dimenzí. Do těchto kostek se nelze přímo podívat na jednotlivé tabulky, je zde třeba použít nástroj, který umožní získat z kostek data. V tomto typu OLAP nelze použít SQL dotaz, právě proto, že zde nejsou definovány klasické tabulky, jako v relační databázi. Proto se zde používá specifický jazyk MDX. MOLAP jsou rychlé, ale mohou zde vznikat zbytečné agregace. ROLAP (relační OLAP)
~9~
Odráží multidimenzionální skutečnosti, ovšem k tomuto pohledu používá data uložená v relačních databázích (tedy bez použití multidimenzionality). Práce s ROLAP je flexibilnější, ovšem pomalejší. HOLAP (hybridní OLAP) Kombinuje postupy MOLAP a ROLAP. Detailní data jsou ukládána v relačních databázích. Agregované hodnoty jsou uloženy v kostkách. DOLAP (desktopové OLAP) Principem je stažení části OLAP kostky na lokální počítač, poté s touto částí pracovat bez nutnosti být připojen k síti.
Reporting Pojem reporting vyjadřuje dotazování do databází pomocí standardních rozhraní, například pomocí SQL příkazů. Úkolem reportovacích služeb je usnadnit rozhodování na všecj stupních organizační struktury. Existují dva typy reportingů: a) Reporting – předem definované pohledy. Uživatel má jen malou možnost pohledy měnit. Změna pohledu může být prováděna jen na úrovni pohledů. b) Ad hoc reporting – uživatelům se poskytne možnost tvořit pohledy podle toho, jak jsou postaveny OLAP kostky, jaké dimenze obsahují. Uživatel tak může manipulovat s ukazateli a s dimenzemi.
~ 10 ~
Oddíl B – Praktická část 2. BI řešení: vyhodnocování plnění plánu zakázek pro obchodní případy Účelem této práce je přehledně popsat postupy při tvorbě nástroje pro analýzu a reportování vývoje a stavu obchodních případů od definování požadavků, přes mapování zdrojových systémů, dimenzionální modelování a modelování datového skladu, volbu technologické platformy až po implementaci. Na tomto místě je dobré vysvětlit, jaké části postupů při tvorbě BI řešení budou z této práce vynechány a které naopak budou popsány podrobněji a proč. Každá větší firma by měla mít vybudován datový sklad, který obstarává uchování dat pro různé výstupy. Problém, který jsem se rozhodla popsat v této práci je jen zlomek toho, co je nutné ve firmě sledovat. A data, která používám pro výsledné výstupy, jsou tedy používána pro více požadavků. Ty jsou často obsáhlejší než tento projekt. Proto se v návrhu BI řešení nemusím zabývat tím, jak velká bude databáze, nebo co se bude dít při nárůstu dat, také zde není nutné řešit hardwarové či softwarové komponenty. Technologickou platformu tedy nemusím vybírat, pouze využijeme platformu běžně používanou pro implementaci BI řešení. V práci bude popsán základní postup tvorby BI řešení. Ovšem pro dostatečné vysvětlení bude použito zjednodušených modelů v rozsahu dostačujícím pro tuto práci. Tedy nebudou zde začleněny komponenty, které se nebudou přímo vztahovat k řešenému problému. Zároveň bych na tomto místě ráda objasnila mou úlohu v týmu realizující BI řešení pro analýzy a reportování vývoje a stavu obchodních případů. Můj přínos v tomto projektu spočívá v poslední fázi BI řešení, tedy v implementaci požadovaných výstupů. Mým úkolem je pomocí nástroje MS Reporting Services uspořádat zpracovaná data do podoby, která bude co nejvíce vyhovovat uživatelům. Proto se v kapitole implementace zaměřím především na tuto oblast.
2.1
Charakteristika společnosti Firma, pro kterou je toto BI řešení tvořeno, je jednou z hlavních tuzemských firem v oblasti
vývoje a dodávky rozsáhlých softwarových aplikací. V současnosti firma začíná novou fázi svého vývoje, a to především díky získání významné zahraniční zakázky. Firma poskytuje tato řešení: Softwarové aplikace na zakázku Podnikové informační systémy (ERP) Integrace aplikací
~ 11 ~
Datové sklady a BI aplikace Firma nabízí svým zákazníkům spolupráci na všech fázích zavádění informačního systému od analýzy potřeb, po testování výstupů. Následně pak zajišťuje podporu uživatelů, správu, údržbu systémů a rozvoj.
2.2
Specifikace uţivatelských poţadavků Základním kamenem pro vytvoření BI řešení obchodních případů je analýza potřeb, tj.
nejprve poznat ty, kteří budou výstupy používat. Poté je vyslechnout a zaznamenat jejich požadavky. Poslední částí této fáze je utřídění získaných informací od uživatelů a návrh toho, jak by měly výstupy vypadat.
2.2.1 Katalog uţivatelů Kapitola definuje skupiny uživatelů, kteří budou toto řešení využívat. Hlavním uživatelem výstupů k analýze a reportování obchodních případů, je obchodní ředitel. Dále tyto výstupy sledují divizní manažeři a obchodníci a zároveň samozřejmě vedení firmy. Obchodní ředitel a vedení Hlavním iniciátorem požadavku na přehledy nad obchodními daty je obchodní ředitel. Obchodní ředitel vypracovává plán pro jednotlivá období. Plán je vyčíslen v korunách a představuje předpokládaný objem výnosů. Vedení a obchodní ředitel pak můžou porovnávat plány obchodníků a divizí se skutečností. Vedení má zároveň možnost požadovat od obchodníků objemy zakázek, které slíbili ve svém operativním plánu. Obchodníci Obchodníci sledují v CRM systému jednotlivé zakázky. A to od fáze, kdy se jedná o pouhou hypotetickou příležitost, až po fázi její realizace. Neustále aktualizují částky, které mají být z těchto zakázek fakturovány. Principem měření jejich výkonnosti, popřípadě úspěšnosti, je porovnání této předpokládané fakturace s jejich obchodním plánem. Předpokládané výnosy jsou s plynoucím časem měněny v závislosti na vývoji zakázek. Obchodníci tedy potřebují sledovat vývoj zakázek a také to, jak si stojí jejich obchodní plán v porovnání s jimi sledovanou skutečností (předpokládanými výnosy).
~ 12 ~
Divizní manažeři Divizní manažeři sledují to, zda je divize produktivní. Důležitější pro ně je ale sledovat vývoj obchodních případů. Zdroje (tj. pracovní síly) pak plánují dle stavu obchodního plánu.
2.2.2 Poţadované výstupy Data budou uspořádána jednak v datovém skladu do relačních tabulek. Nad těmito daty budou vytvořeny výstupy v podobě reportů, viz dále. Druhým typem uspořádání dat je struktura OLAP databáze (OLAP kostek), nad níž budou sloužit jako výstupy kontingenční tabulky.
2.2.2.1 Reporty Reporty budou využívat tabulky datového skladu, které budou naplněny daty z CRM. Kromě textového zobrazení budou informace prezentovány i graficky. Pro každý pohled (pohled na data pro celou firmu, za obchodníka, za divizi, za neuskutečněné příležitosti) by měla být sada reportů a jeden report pro sledování licencí a subdodávek. Pro možnost sledování širší či užší části dat bude mít uživatel možnost rozsah dat ovlivňovat filtry. Níže jsou uvedeny popisy a návrhy reportů:
Reporty pro pohled za celou firmu, za obchodníky, za divize Vzhled reportů v těchto 3 různých pohledech bude prakticky stejný. Proto zde bude popsán návrh jen jednoho pohledu - pohledu na celou firmu. Uživatel bude moci ovlivňovat rozsah zobrazovaných dat dle filtrů: roky – výběr období obchodníci – jmenovitý seznam divize – seznam divizí. Následující text je věnován definici jednotlivých reportů obsažených v sestavě. Pravděpodobný příjem kumulovaný V tomto reportu bude sledován pravděpodobný příjem a to dle pravděpodobnosti získání zakázky, tak jak jí odhadují obchodní manažeři (100%, >=80%, <80%). Příjem bude monitorován po kvartálech, ovšem kumulovaně. To znamená, že např. v 2. kvartálu bude částka rovna součtu za 1. a 2. kvartálu. V posledních řádcích bude srovnání plánů a skutečností a přehled hodnot vypovídajících o stavu obchodu.
~ 13 ~
Tabulka 1 Návrh reportu "Pravděpodobný příjem" Pravděpodobný příjem -rok XXXX 1. Celkem - 100% 2. Celkem >= 80% (pravděpodobný) 3. Celkem < 80% (pravděpodobný) Plán Skutečná fakturace Celkem: Odchylka od plánu: Plnění plánu (kumulovaně):
Q1
Q2
Q3
Q4
Pravděpodobný příjem dle řešení Hodnoty v reportu zde už nejsou kumulativní, odpovídají předpokládanému příjmu za jednotlivá čtvrtletí. Příjem je zde rozpadnut na sumy za jednotlivé typy řešení. Typem řešení rozumíme způsob zpracování zakázky. Podrobnější popis viz kap. 2.4.2.1 Návrh dimenzí a jejich charakteristik Tabulka 2 Návrh reportu "Pravděpodobný příjem dle řešení" Pravděp. příjem dle řešení - rok XXXX BI & DWH ERP Integrace aplikací Konzultace Ostatní Podpora provozu Zakázkový vývoj aplikací Operativní plán: Celkem skutečnost:
Q1
Q2
~ 14 ~
Q3
Q4
Celkem
Pravděpodobný příjem dle fáze obchodního případu Příjem zde opět nebude napočítáván kumulovaně. Fáze vyjadřuje stav obchodního případu od příležitosti, přes nabídku, až k fázi uzavření smlouvy. Zde popsané fáze jsou ty aktivní fáze obchodních případů, ty budou také v tomto reportu využity. Existují ještě neaktivní (pasivní) fáze, které zde použity nebudou. Pro ně je vytvořena samostatná sada reportů. Tabulka 3 Návrh reportu "Pravděpodobný příjem dle fáze" Pravděp. příjem dle fáze - rok XXXX 2 - Zájem 4 - Nabídka 5 - Vyhraná nabídka 6 - Smlouva 7 - Dokončeno Operativní plán: Celkem skutečnost:
Q1
Q2
Q3
Q4
Celkem
Rozpracované příležitosti Tento report bude v jedné sadě reportů zobrazován hned třikrát. A to pro obchodní příležitosti s pravděpodobností 100%, tedy již příležitosti, které budou získány (tzn. již je podepsaná smlouva). Další reporty budou zobrazovat obchodní příležitosti s pravděpodobností >=80% a <80%. Tabulka 4 Návrh reportu "Obchodní příležitosti s pravděpodobností"
Rozpracované příležitosti - rok XXXX Obchodní případy s pravděpodobností = XX% Zákazník
Obchodní případ
% Abs. obj.
Fáze
Řešení
Divize
Zaháj. proj. Obchodník
Zákazník 1 Zákazník 2 Zákazník 3 Celkem
Příjmy za jednotlivá řešení Report je vlastně detailem k pravděpodobnému příjmu dle řešení. Jsou zde zobrazovány obchodní případy a jejich detail seskupené dle řešení.
~ 15 ~
Tabulka 5 Návrh reportu "Příjmy za jednotlivá řešení"
Příjmy za jednotlivá řešení v roce XXXX Typ Řešení Zákazník BI & DWH Zákazník 1 Zákazník 2 Zákazník 3 ERP Integrace aplikací Konzultace Ostatní Podpora provozu Zakázkový vývoj aplikací Celkem
Obchodní případ
%
Abs.obj.
Fáze
Divize Datum Obchodník
Neuskutečněné příležitosti Sestava se bude skládat ze 4 reportů. „Neuskutečněné příležitosti“ jsou ty, které mají v datech zaznamenanou fázi obchodního případu „odstoupeno“, „nevyhráno“ nebo „zrušeno“. První report bude vypadat jako report „Pravděpodobný příjem kumulovaný“, ale místo pravděpodobností (v řádcích) zde budou jednotlivé fáze. Druhý
report
bude
totožný
s
reportem
„Pravděpodobný
příjem
dle
řešení“.
Třetí report bude mít stejný vzhled jako report “Rozpracované příležitosti“, ale místo 3 pravděpodobností zde budou 3 tabulky pro jednotlivé fáze („odstoupeno“, „nevyhráno“ a „zrušeno“). Čtvrtý report je opět totožný s „Příjmy za jednotlivá řešení“.
Licence a subdodávky Tato tabulka zobrazuje objem nákladů, který připadne v jednotlivých čtvrtletích za licence a subdodávky. Licencemi zde rozumíme licence nakupované od dodavatelů software, které firma využije při realizaci zakázek. Subdodávky zde vyjadřují služby, které firma nerealizuje sama, například výdaje za koupi a instalaci hardware, placení externích pracovníků, atd.
~ 16 ~
Tabulka 6 Návrh reportu „Licence a subdodávky“
Licence a subdodávky - kvartální
Subdodávky
Licence
Celkem Subdodávky
Licence
Q4 Subdodávky
Licence
Q3 Subdodávky
Licence
Q2 Subdodávky
Název
Licence
Q1
Prav.%
Divize
Projekt 1 Projekt 2 Projekt 3 Celkem
Pro analýzu obchodních dat budou vytvořeny 3 sady reportů obchodních případů (za firmu, za divize a za obchodníky), sadu pro neuskutečněné příležitosti a report zobrazující výši licencí a subdodávek. Vypadá to, že bude třeba vytvořit poměrně dost reportů, ale v podstatě jsou to vždy stejné struktury z různých pohledů.
2.2.2.2 Poţadavky na analýzu Jsou případy, ve kterých má uživatel specifické požadavky na zobrazovaná data a pohled na ně je specifický. Popřípadě sám neumí v současnosti definovat, jaké pohledy bude chtít vidět. Proto je dobré dát uživateli možnost, aby si pohledy vytvářel sám. K této možnosti se přistupuje přes multidimenzionální prostor, ve kterém jsou definovány jednak ukazatele (číselné hodnoty) a jednak dimenze (kategorie, pomocí kterých budeme hodnoty zkoumat). Výsledný analytický přehled by měl být ideálně ve formě kontingenční tabulky, grafu, ale i v podobě kostek zobrazovaných prostřednictvím nástrojů pro BI analýzy. Uživatelé by s ním měli pracovat v jednoduchém a známém uživatelském prostředí (internetový prohlížeč, MS Office Excel).
2.2.3 Katalog poţadovaných ukazatelů Z požadavků, které definovali uživatelé, lze odvodit ukazatele, které budou potřeba. Ovšem zde je třeba si přiblížit jejich význam, jelikož často není lehké pochopit význam ukazatele jen z jeho názvu. Absolutní příjem Absolutní příjem vyjadřuje hodnotu předpokládaného příjmu. Tento ukazatel nebere v potaz pravděpodobnost, s jakou je možnost zakázku získat. Zobrazuje hodnoty, kterých by bylo dosaženo za předpokladu, že všechny zaznamenané zakázky budou získány a vyrobeny. Absolutní příjem bude zobrazovat jednak plánovaný absolutní příjem (všechny zakázky), jednak
~ 17 ~
skutečný absolutní příjem (podepsané zakázky=smlouva). Vždy když obchodník dokončí zakázku do zdárného konce, připíše zakázku i do příjmu skutečného. Plánovaný příjem Plánovaný příjem je ukazatel, který definuje obchodní ředitel na začátku roku. Tato hodnota je velice důležitá pro srovnávání toho, jak je předpoklad z počátku roku plněn. Na obchodní plán se nahlíží ze třech dimenzí. Ovšem možnost dívat se na hodnoty plánu z více, jak jedné dimenze (obchodník, divize, řešení) je nesmyslné, protože mezi nimi nejsou hierarchické vazby. Pravděpodobný příjem „Pravděpodobný příjem“ je odhad, který určují obchodníci dle fáze a vývoje obchodního případu. Bude vycházet z absolutního příjmu. Tento ukazatel bude vypočítán jako „Absolutní příjem“ násobený „Pravděpodobností získání zakázky“. Tím bude vyjádřen odhad výše objemu získaných zakázek (a to v Kč). „Pravděpodobný příjem“ je ukazatel, který se bude vyskytovat prakticky ve všech pohledech. Je to centrální ukazatel, který bude sledován sám, nebo s ním budou porovnávány ostatní ukazatele. Zde je výčet pohledů na tento ukazatel: Pravděpodobný příjem za celou firmu Pravděpodobný příjem dle divizí Pravděpodobný příjem dle obchodníka V rámci těchto tří rovin bude dále tento ukazatel sledován v dalších souvislostech: Pravděpodobný příjem kumulovaný (za jednotlivá čtvrtletí) Pravděpodobný příjem dle řešení Pravděpodobní příjem dle fáze Pravděpodobný příjem dle obchodního případu Odchylka od plánu Ukazatel „Odchylka od plánu“ je vyjádření podílu pravděpodobného příjmu a obchodního plánu, a to v korunách. Pokud se ukazatel dostane do mínusu, znamená to, že není dodržen předem stanovený plán. Plnění plánu
~ 18 ~
Ukazatel „Plnění plánu“ je opět výpočet. Je zobrazován v procentech a vypočítá se jako poměr pravděpodobného příjmu a obchodního plánu násobený 100. Pokud je tento ukazatel větší, než 1, znamená to plnění plánu nad očekávání. Absolutní licence Firma samozřejmě nepoužívá při zakázkách jen svůj software, ale začleňuje do svých řešení software vyráběný jinými firmami. Výši ceny software (=licence) si musí započítat do celkové ceny nabídky svých služeb pro zákazníky. „Absolutní licence“ vyjadřuje výši licencí bez ohledu na procentuální odhad získání zakázky. Stejně jako v případě „Absolutního příjmu“ je zde na licence pohlíženo ze dvou úhlů. „Absolutní příjem“ (plán) je výše všech zakázek. Na rozdíl od absolutního příjmu (skutečnost), která vyjadřuje výši již dokončených zakázek. Jako dokončené zakázky označujeme ty, které již byly vyfakturovány. Pravděpodobné licence „Pravděpodobné licence“ je ukazatel vypočítaný z absolutní licence, ve které je zohledněna pravděpodobnost získání zakázky, pro kterou jsou licence plánovány. Vzorec pro výpočet je tedy „Absolutní licence“ * „Pravděpodobnost získání zakázky“. Absolutní subdodávky Tento ukazatel je vyčíslením práce, kterou firma neprovádí sama. Například instalace HW, externí zdroje, atd. Tento ukazatel vyjadřuje objem subdodávek bez ohledu na to, zda bude zakázka, jejíž součástí je subdodávka, získána. Absolutní subdodávky (skutečnost) bude vyjadřovat výši subdodávky již získaných zakázek (tj. 100%, tj. podepsaná smlouva). Absolutní subdodávka (plán) pak vyjádří objem subdodávek ve všech zakázkách bez ohledu na pravděpodobnost získání zakázek. Pravděpodobné subdodávky „Pravděpodobné subdodávky“ vyjádří hodnotu subdodávek přepočítanou k procentuálnímu odhadu získání zakázky, která tuto subdodávku obsahuje.
Nyní je jasné, která data bude třeba získat a v jakých formách budou zobrazována. V této kapitole je představen i hrubý náčrt obsahu a struktury reportů. Lze tedy přistoupit k samotné práci s daty. Bude nutné porovnat data, která potřebujeme, s daty, které nám konkrétní aplikační
~ 19 ~
software firmy nabízí. Otázkou teď je: Dokážeme nalézt data ve zdrojových systémech, která chceme zobrazovat?
~ 20 ~
2.3
Mapování zdrojových systémů K potřebě získání požadovaných dat by měly stačit dva zdrojové systémy, a to MX Contact
(CRM) a data obchodních plánů. Čím méně zdrojových systémů je použito, tím menší jsou pak problémy s konzistencí a čištěním dat.
2.3.1 MX Contact MX Contact je primární aplikace pro sledování obchodních případů. Jedná se o CRM aplikaci. Tato aplikace obsahuje informace o jednotlivých případech. Základem dat jsou obchodní případy navázané na zákazníky a s tím i všechny důležité informace k případům. Důležitou součástí jsou i události spojené s obchodními případy. Jde zejména o schůzky, důležité dokumenty a emailové adresy. Vlastní data jsou tedy umístěna ve složkách Exchange serveru. Aplikace je pak zakomponována do prostředí MS Office Outlook. Pro potřeby reportování jsou pomocí speciální aplikace každou hodinu kopírována data obchodních případů a všech jejich souvisejících objektů z Exchange Serveru do samostatné databáze na SQL Server.
Popis hlavních datových tabulek Data jsou uspořádána do relačních tabulek. Budou zde popsány jen ty nejdůležitější, včetně významných atributů. Pro přehlednost jsou atributy a jejich významy uvedeny v tabulkách Tabulka „Companies“ Tabulka 7 MXC - Comanies Atribut název společnosti domovská stránka telefon fax Adresa Obor činnosti
Význam název společnosti, se kterou jsou, nebo by mohly být uzavírány obchodní zakázky odkaz na stránky firmy telefonní spojení do firmy faxové spojení do firmy adresa firmy obor, ve kterém firma působí
~ 21 ~
Tabulka „Contacts“ Tabulka 8 MXC - Contacts Atribut jméno společnost titul Domovská stránka e-mail telefon telefon domů mobil poštovní adresa pracovní pozice typ kontaktu
Význam jméno osoby ze zákaznické firmy, se kterou je obchodní případ projednáván název společnosti, se kterou jsou, nebo by mohly být uzavírány obchodní zakázky titul osoby odkaz na stránky firmy e-mail osoby firemní telefonní číslo osoby - pevná linka osobní telefonní číslo - pevná linka telefonní číslo - mobil adresa pro poštovní korespondenci pracovní pozice kontaktní osoby význam osoby ve vztahu k zakázce (např. rozhodující, doporučující osoba …)
Tabulka „Opportunities“ Tabulka 9 MXC - Opportunities Atribut příležitost společnost očekávané uzavření smlouvy služba řešení kontaktní osoba absolutní příjem pravděpodobný příjem Fáze případu očekávané uvedení do provozu pravděpodobnost odpovědná osoba zahájení projektu očekávané uzavření projektu zahájení přípravy očekávané zahájení projektu absolutní subdodávky pravděpodobné subdodávky absolutní licence pravděpodobné licence sloupce jednotlivých řešení
Význam název obchodního případu (obchodní příležitosti) název společnosti zadávající obchodní případ datum předpokládaného uzavření smlouvy jaký způsob služby je v obchodním případu použit jakým řešením je obchodní případ realizován jméno kontaktní osoby absolutní příjmy za jednotlivé měsíce absolutní příjem násobený pravděpodobností získání obchodního případu fáze obchodního případu (viz popis dimenze fáze) Předpokládané datum implementace výsledného produktu odhadnutá pravděpodobnost získání obchodního případu obchodník sjednávající obchodní případ datum zahájení práce na obchodním případu předpokládané datum ukončení obchodního případu datum zahájení přípravy datum zahájení obchodního případu výše nákladů na subdodávky (absolutní číslo) výše nákladů na subdodávky přepočítaná na pravděpodobnost získání zakázky výše nákladů na licence (absolutní číslo) výše nákladů na licence přepočítaná na pravděpodobnost získání zakázky pro vyjádření procentuálního podílu účasti jednotlivých řešení na projektu
~ 22 ~
Tabulka „Projects“ Obchodní případ (obchodní příležitost) se stává projektem až po podepsání smlouvy. Tzn. po podepsání smlouvy je pro obchodní případ založen projekt. Tabulka 10 MXC - Projects Atribut název projektu náklady pracnost stav datum zahájení plánované dokončení divize licence subdodávky výnosy
Význam název projektu náklady na projekt pracnost projektu (v člověkohodinách) stav projektu datum zahájení projektu plánované dokončení projektu Divize realizující projekt náklady na licence náklady na subdodávky výnosy z projektu
Tabulka „SmlouvyXs“ Tabulka 11 MXC - SmlouvyXs Atribut Název společnost objem smlouvy smluvní vztah náklady pracnost
Význam název smlouvy mezi firmou a zákazníkem název zákaznické společnosti výše částky uvedená na smlouvě smluvní vztah se zákazníkem (např. zadavatel, odběratel) výše nákladů vydaných při realizaci zakázky pracnost projektu (v člověkohodinách)
Objem dat Dat v tomto systému není mnoho. Řádově se jedná o stovky obchodních případů a stovky společností. Velikost databáze můžeme tedy odhadovat do 1 GB. Není proto důvod řešit možné problémy s databází, které by mohly nastat díky nedostatku místa.
Zatížení systému Jak již bylo zmíněno, data obchodních případů jsou kopírována do databáze, a to každou hodinu. Tato databáze je oproti původním datům v poměru 1:1. Nedochází zde ke ztrátě dat. V databázi je tedy totéž, co v primárních systémech. Datový sklad může k databázi přistupovat kdykoli. Zatížení databáze je prováděno v krátkých, pravidelných intervalech. Data jsou ukládána transakčně. To znamená, že pokud jsou data z datového skladu čerpána právě v okamžiku, ve kterém je prováděno načítání dat z databáze do datového skladu, nehrozí, že by například chyběla část dat. Vždy se zobrazí stav před, nebo až po načítání.
~ 23 ~
Kvalita dat V tomto projektu používáme jen jeden zdrojový systém. Komplikace nastávají při navázání dat na jiný systém (na jinou oblast datového skladu). Problémem často bývá špatné pojmenování obchodního případu, protože název je používán jako indetntifikátor. To pak způsobuje nepropojení záznamů z těchto systémů. Co se týče reportů, vlastní aplikace neposkytuje žádné reporty, pouze jednoduché seznamy objektů v rámci jejich tříd, které lze filtrovat a třídit. Jsou očekávány změny v aplikaci – aplikace bude do konce roku 2009 nahrazena novým systémem CRM.
2.3.2 Data obchodních plánů Data obchodních plánu je zdroj dat složený z tabulek, které jsou uloženy na SQL serveru. Tyto tabulky byly ručně vytvořeny ze souborů formátů XLS2 a DOC3. Každý rok jsou tyto tabulky plněny aktuálními hodnotami. V průběhu roku dochází k změnám jen výjimečně. Velikost této databáze (datového zdroje) je ještě menší, než velikost dat CRM. Počty záznamů odhadujeme v řádu desítek.
Popis hlavních tabulek V tabulkách jsou uchovávány plány za jednotlivá čtvrtletí. Tabulky mají v podstatě stejnou strukturu, jen se liší v pohledu, za koho je plán sledován. Zda za divizi, obchodníka, či za řešení. Zdrojové tabulky jsou tedy tyto: Plán divize Plán obchodníka Plán řešení
Potřebná data pro požadované reporty jsou ve zdrojových systémech CRM a v datech obchodních plánů. Tyto zdrojové databáze nejsou nijak složité. Skutečností, která usnadňuje 2
Formát MS Office Excel
3
Formát MS Office Word
~ 24 ~
práci při ošetřování případných problémů, je fakt, že zdrojové systémy obsahují poměrně malý objem dat. Díky transakčnímu ukládání dat je v datech ošetřen i problém jejich načítání v době, kdy jsou data ukládána. Data se načtou buď před, nebo až po ukončení ukládání. Neměla by nastat situace, ve které by byla načtena jen část dat.
~ 25 ~
2.4
Návrh BI řešení Nyní víme, jaká data je třeba získat, odkud je budou čerpána, a to, že jsme schopni všechna
tato data získat. Můžeme tedy přejít k návrhu struktury datového skladu. Cílem této kapitoly je vytvořit logický model. Poté tento model bude převezen do fyzické podoby v prostředí skutečné databáze. Nejprve ale bude přiblížen současný stav architektury firmy.
2.4.1 Celková architektura celého řešení BI a DWH firmy Firma samozřejmě nevytváří celou architekturu až díky tomuto projektu. Architektura již existuje. Její strukturu demonstruje Obrázek 3 Architektura datového skladu firmy.
Obrázek 3 Architektura datového skladu firmy
V první vrstvě jsou produkční systémy (primární zdroje dat), které jsme si definovali v předchozí kapitole (MX Contact, data obchodních plánů). Dalším zdrojem dat může být například účetní systém. Pomocí ETL procesů se načítají data do datového skladu. Nad datovým skladem je možné tvořit reporty. Reporty jsou předem připravené pohledy na aktuální data. Většinou vznikají na základě požadavků uživatelů. Při zobrazování je možné využít filtry náležící k reportům. Součástí architektury je i OLAP databáze. Ta je vytvořená nad datovým skladem. Díky ní lze využívat analytické aplikace a nástroje. Ty slouží podobně jako reporty pro tvorbu a ukládání pohledů na data. Analytickými aplikacemi a nástroji je zde míněn především MS
~ 26 ~
Office Excel, ve kterém je možné vytvářet pohledy nad OLAP kostkami v podobě kontingenčních tabulek. Pohledy nad OLAP kostkami jsou uloženy na analytickém interním portálu, který je realizován nástrojem MS Sharepoint. Kromě nově vznikající oblasti (analýza nad obchodními daty) se tato architektura používá na sledování bonusů zaměstnanců, čerpání jejich dovolené, výkazy práce a další. Celková architektura je navržena tak, aby bylo možné napojovat další funkcionalitu BI.
2.4.2 Dimenzionální (multidimenzionální) modelování Jak je vidět z výše popsané struktury řešení, při realizaci našeho projektu nejsme současnou architekturou nijak omezeni, využijeme komponenty stávajícího řešení. Projekt jen doplňuje do současného řešení věcné oblasti.
2.4.2.1 Návrh dimenzí a jejich charakteristik V této kapitole budou představeny všechny dimenzionální pohledy použité pro sledování ukazatelů. Strukturu a atributy jednotlivých dimenzí je možné si prohlédnout v příloze č. 1. Dimenze můžeme rozdělit do dvou hlavních skupin:
Časové dimenze Čas Dimenze „Čas“ umožňuje sledovat požadované hodnoty s časovou kontinuitou.
Tato
dimenze má hierarchii. V našem případě: rok, kvartál, měsíc, den Skutečnost/plán Druhou dimenzí, která se vztahuje časovému určení, je dimenze „Skutečnost plán“. Díky této dimenzi bude možné odlišit skutečně dosažené hodnoty od plánovaných hodnot obchodního plánu.
Dimenze týkající se obchodních případů Fáze Dimenze „Fáze“ v sobě zahrnuje stavy, ve které se mohou obchodní případy, nacházet. Tato dimenze bude obsahovat hodnoty číselníku. Hodnoty můžeme rozdělit do dvou skupin, a
~ 27 ~
to na aktivní fáze a stornované fáze. Aktivní fáze jsou ty, které mají šanci na úspěšné získání zakázky, ať už jen hypotetickou, nebo reálnou. Takovýchto fází bude v dimenzi obsaženo sedm, při čemž sedmá fáze bude označovat úspěšné dokončení projektu. Stornované fáze zahrnují případy, ve kterých již není možné uspět. A to jak z důvodu zrušení poptávky zákazníkem, neúspěšným výběrovým řízením, nebo tím, že firma odstoupila od zakázky.
Divize Divize jsou výrobní částí firmy odpovídající za realizaci zadaných zakázek. Tato dimenze bude mít opět formu číselníku. Typ řešení Dimenze „Typ řešení“ vyjadřuje způsob, jakým jsou zakázky zpracovány. Pro realizaci zakázek je obvyklé, že se na nich podílí více oblastí (více druhů řešení), které jsou vhodné pro daný typ zakázky. Pohled na hodnoty přes dimenzi řešení může být použit pro analýzu dostatku kapacit ve firmě. Dimenze bude ve formě číselníku. Obchodník Dimenze „Obchodník“ obsahuje podstatné údaje o obchodnících. Obchodníků není ve firmě mnoho, jelikož zakázky, které obstarávají, bývají většinou rozsáhlé a často dlouhodobé. Pravděpodobnost V dimenzi „Pravděpodobnost“ je zachycena škála pravděpodobnosti, s jakou bude zakázka získána.
Pravděpodobnost
bude
seskupena
do
intervalů
100%,
<80%,
>=80%.
Pravděpodobnost získání zakázek určují obchodníci z vývoje obchodních jednání nad zakázkami. Samozřejmě při odhadu se také řídí tím, v jaké fázi se zrovna obchodní případ nachází. Ale opět nelze říci, že pokud se obchodní případ dostane do té a té fáze, tak je její pravděpodobnost rovna určitému procentu (kromě fáze „podpis smlouvy“ - pravděpodobnost je rovna 100%, u neaktivních fází obchodních případů je pravděpodobnost rovna 0%). Zákazník Dimenze „Zákazník“ bude poskytovat informace o institucích, se kterými firma měla možnost kdy obchodovat. V dimenzi bude uveden název firmy.
~ 28 ~
Obchodní případ Dimenze „Obchodní případ“ v sobě skrývá jednotlivé obchodní případy.
2.4.2.2 Návrh ukazatelů a jejich charakteristik a vazby mezi dimenzemi a ukazateli Ukazatele již byly definované v kapitole 2.2.3Katalog požadovaných ukazatelů. Všechny podstatné informace již k této části byly řečeny. Proto zde nemá smysl informace o ukazatelích opakovat. Kapitola je zaměřená především na vztahy mezi dimenzemi a ukazateli. Ty popisuje tabulka uvedená na další stránce. Význam sloupců tabulky: Ukazatel – název ukazatele Jednotka – jednotka ukazatele Zdroj/kalkulace – pokud je ukazatel přímo z primární databáze, zobrazuje se v buňce tato databáze. Pokud jde o vypočítaný ukazatel, v buňkách je zobrazen vzorec výpočtu. Zdroj (databáze) zde uveden není, jelikož vzorec se skládá z ukazatelů, které jsou v tabulce zaznamenané a mají tento zdroj vyplněn. Poznámky – stručný popis ukazatele Ostatní sloupce – dimenze, ukazatel používá dimenze, ve kterých je „x“.
~ 29 ~
Plnění plánu
Predikce obchodníků, jak velký objem zakázek získají k určitému datu. Na tento ukazatel bude moţné pohlíţet ze tří dienzí. Data obchodních Ovšem tyto pohledy budou Kč plánů neslučitelné. obchodní sledování plnění plánu dle plán/Pravděp.příjem předpokládaného objemu % * 100 získaných zakázek v procentech
Absolutní licence
Kč MXC Contact
Pravděpodobné licence
absolutní licence * pravděpodobnost Kč získání zakázky
objem peněz, který je vynaloţen za zprostředkované licence k programům (od jiných firem) pouţívaných v dodávaném řešení bez ohledu na pravděpodobnost získání zakázky objem peněz, který bude vynaloţen za zprostředkované licence k programům (od jiných firem) pouţívaných v dodávaném řešení bez ohledu na pravděpodobnost získání zakázky
Kč MXC Contact
objem peněz, který je vynaloţen za zprostředkované subdodávek pouţívaných v dodávaném řešení s ohledem na pravděpodobnost získání zakázky
Absolutní subdodávky
plán/skutečnost
Obchodní plán
sledování plnění plánu dle předpokládaného objemu získaných zakázek - rozdíl
x
divize
pravděpodobný příjem - obchodní Kč plán
x
obchodník
Odchylka od plánu
Výše příjmu přepočítaný na procentuelní pravděpodobnost získání zakázky
obchodní případ
Absolutní příjem * pravděpodobnost Kč získání zakázky
zákazník
Pravděpodobný příjem
x
řešení
Kč MXC Contact
tento příjem je brán v absolutních hodnotách, nebere se zde v úvahu pravděpodobnost, se kterou budou zakázky získány;
fáze
Absolutní příjem
Poznámky
pravděpodobnost
Zdroj/kalkulace
čas
Ukazatel
Jednotka
Tabulka 12 Vztahy mezi dimenzemi a ukazateli
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Pravděpodobnost získání zakázky %
objem peněz, který je vynaloţen za zprostředkované subdodávek pouţívaných v dodávaném řešení bez ohledu na pravděopodobnost získání zakázky odhad, s jakou pravděpodobností bude zakázka získána; To odhadují hbchodníci
Absolutní výroba
absolutní příjem očištěný o výdaje za licence a subdodávky (v absolutních číslech)
x
x
x
x
x
x
x
x
pravděpodobný příjem očištěný o licence a subdodávky (s ohledem na pravděpodobnost získání zakázky)
x
x
x
x
x
x
x
x
Pravděpodobné subdodávky
Pravděpodobná výroba
absolutní subdodávky * pravděpodobnost Kč získání zakázky
MXC Contact Absolutní příjem absolutní licence absolutní Kč subdodávky pravděpodovný příjem pravděpodobné licence pravděpodobné Kč subdodávky
~ 30 ~
x
x
x
x
2.4.3 Modelování datového skladu V této kapitole se budeme zabývat strukturou datového skladu. Návrh faktových a dimenzionálních tabulek bude vycházet z návrhu ukazatelů a dimenzí definovaných v minulé kapitole. Co se týče volby typu schématu (ve všech publikacích opakované star nebo snowflake schéma), zde zvolíme typ souhvězdí (Fact contesllation scheme), jelikož zde bude využito několika faktových tabulek. Ovšem pokud by měl být zvolen typ bez ohledu na to, kolik je zde faktových tabulek s jen ohledem na strukturu zvoleného schématu, bude model vytvářen ve schématu typu star.
2.4.3.1 Návrh logické struktury DWH Logický návrh datového skladu bude obsahovat faktové tabulky a napojení dimenzí na tyto faktové tabulky. Z důvodu přehlednosti modelu nebudou dimenzionální tabulky ve schématu nijak blíže specifikovány. Jejich atributy jsou zachyceny ve fyzickém modelu (Obrázek 5 Fyzický model)Nebudeme zde uvádět jejich atributy. Specifikaci ukazatelů faktových tabulek je možné si prohlédnout v příloze č. 2.
Obrázek 4 Logický model datového skladu
Model je vytvořen z logických názvů. Není zde použito názvosloví, které bude zapracováno ve fyzickém modelu. Jak již bylo zmíněno, dimenze nemají v modelu zaznamenány atributy, ve faktových tabulkách jsou naopak uvedeny jako atributy jednak ukazatele, jednak cizí klíče (odkazy na ID dimenzí) popřípadě degenerované dimenze. V modelu jsou reprezentovány i takzvané odvozené dimenze. Odvozená dimenze má jako zdroj jinou dimenzi. Obsah odvozené dimenze je možné dle potřeb omezit. Tyto dimenze jsou v modelu vyznačeny jako běžné
~ 31 ~
dimenze (tedy není u nich uváděn výpis atributů), ale za názvem dimenze mají v závorce uvedenu dimenzi, ze které byly odvozené. Nyní si popíšeme jednotlivé faktové tabulky, co obsahují a jaké dimenze jsou na ně napojené.
Faktové tabulky: Obchodní případ pravděpodobnost V této faktové tabulce je jediný ukazatel, a to právě pravděpodobnost každého obchodního případu. Pravděpodobnost vyjadřuje procentuální odhad úspěšného dokončení zakázky. Tento ukazatel je velice důležitý, neboť se podle něj počítají odhady příjmů. Na základě pravděpodobnosti se také odhadují budoucí zisky (tedy predikce). Faktové tabulky plánů (Plán firma, Plán divize, Plán obchodník) Všechny tyto faktové tabulky mají stejnou strukturu. Jediný rozdíl mezi nimi je to, na co se odkazují do dimenze plán – skutečnost. Obchodní případ obrat I když v předchozím textu pojem „obrat“ nebyl zmíněn, uchovává tabulka hodnoty, které jsou v textu nazývány jako „příjem“, popřípadě „fakturace“. Tabulka uchovává výši odhadovaných příjmů za jednotlivé obchodní případy. Dalšími ukazateli v této tabulce jsou objemy licencí a subdodávek, ovšem na ty je pohlíženo jako na náklady. Tabulka také obsahuje odkaz na odvozenou dimenzi „Období fakturace“, díky níž lze sledovat obchodní případy z hlediska času (roky, kvartály). Obchodní případ řešení Každá zakázka nemusí být řešena jen jedním typem řešení. Pokud by to tak bylo, stačilo by vytvořit pro typ řešení dimenzionální tabulku. Jelikož ale každý případ může zahrnovat více typů řešení v různých poměrech (procentuálních podílech), je třeba vytvořit pro toto zobrazení tabulku. Ukazatelem zde bude podíl daného typu řešení na celkovém příjmu. Pro textové vyjádření druhu řešení je vytvořena dimenze „Řešení“, která je na tabulku navázána. Vazby dimenzí na tabulky faktů vyjadřuje následující tabulka:
~ 32 ~
x
x
x
Obchodní případ řešení
x x
Obchodní případ obrat
x
Plán obchodník
Plán divize
x x x x x
Plán firma
divize/faktové tabulky Datum Divize Fáze případu Obchodní případ Odpovědná osoba Plán - skutečnost Pravděpodobnost Řešení Uvedení do provozu Uvedení do provozu Uzavření smlouvy Zahájení projektu Zákazník Zdroj
Obchodní případ pravděpodobnost
Tabulka 13 Vazby mezi dimenzemi a faktovými tabulkami
x
x x x x x x x x x
x
Dimenze: Datum „Datum“ je základní dimenzí, která nesmí chybět v žádném datovém modelu. Tato dimenze obsahuje nejen datum jako takové, ale datum je zde rozkouskováno na potřebné části, jako je rok, kvartál, měsíc, týden, den a také slovní pojmenování. Z této dimenze je odvozeno několik dalších dimenzí, viz dále.
Divize Dimenze je tvořená číselníkem, jehož hodnoty jsou vypsané v příloze č. 1. Fáze případu Tato dimenze je tvořena číselníkem, jeho obsah je možné si prohlédnout v příloze č. 1. Obchodní případ V této dimenzi jsou ukládány textové doplňující informace o obchodních případech. Zároveň je tato tabulka napojená na další faktovou tabulku obchodní případ řešení.
~ 33 ~
Plán – skutečnost Dimenze slouží k rozlišení, zda hodnota „Absolutní Příjem“ je skutečná,nebo plánovaná. Hodnoty dimenze mají podobu číselníku. Pravděpodobnost Jelikož je požadavek zobrazovat obchodní případy rozřazené dle jejich pravděpodobnosti získání, a to ve třech intervalech (<80%, >=80%, 100%), vytvoříme dimenzi, která bude tyto tři intervaly zobrazovat. Opět se zde jedná o dimenzi složenou z číselníku. Řešení Tato dimenze je výčtem typů řešení, tedy opět jde o číselník. (viz příloha č. 1) Zákazník Hodnoty z této dimenze nebudeme prozatím v reportech používat, ovšem tato dimenze je poměrně podstatná a předpokládáme, že postupem času bude tato dimenze využita pro drilldown4.
Zdroj Dimenze „Zdroj“ obsahuje seznamy zaměstnanců firmy, ovšem my tuto dimenzi začleňujeme do návrhu proto, že chceme z tohoto seznamu zaměstnanců získat informace jen o obchodnících.
Odvozené dimenze: Období fakturace Dimenze je odvozena z dimenze „Datum“. Obsahuje data, ve kterých byly/budou fakturovány jednotlivé obchodní případy. Díky této dimenzi lze obchodní případy (a jejich objemy) zobrazovat v časovém rozlišení, v tomto řešení za jednotlivé roky či kvartály. Odpovědná osoba Je odvozena z dimenze „Zdroj“. Vyjadřuje osoby odpovědné za jednotlivé obchodní případy (tzn. obchodník),
4
drill-down – princip, při kterém je možnost hierarchicky agregovaná data rozpadnout na nižší úroveň
~ 34 ~
Uzavření smlouvy, Zahájení projektu, Uvedení do provozu V reportech, které jsou součástí tohoto řešení, sice tato data nejsou využita, ale jsou třeba pro přehledy využívané divizními manažery pro plánování zdrojů.
Nyní jsou zhruba definované všechny dimenze a faktové tabulky, které budou součástí BI řešení, popřípadě ty, které je možné využít při dalším rozšiřování nově zadaných výstupů. Nyní můžeme přejít na mapování zdrojových dat na námi vytvořený model. Mapování nejlépe vystihuje tabulka uvedená v příloze (příloha č. 2). Zde je zaznamenán logický i fyzický název atributů a ukazatelů pouze pro jednotlivé faktové tabulky, jejich datové typy, popis, typ sloupce (atributu, ukazatele) a fyzické mapování do datových zdrojů primárních systémů. Typ sloupce je uveden prefixem (jedno písmeno), proto je dobré si jej na tomto místě vysvětlit: U – ukazatel D – dimenze (odkaz na dimenzi, většinou ID – cizí klíč) A – atribut G – degenerovaná dimenze V – pohled (odvozená dimenze). Definování datových typů ale spíše spadá do oblasti návrhu fyzického modelu. Je třeba dobře rozmyslet, jaký datový typ bude pro daný atribut nejvhodnější. Čím lépe budou datové typy navrženy, tím menší prostor bude databáze zabírat. Většina dat je čerpána z datového zdroje MX Contact, kromě plánů (plán divize, plán obchodník, plán firma) a kromě některých dimenzí, které vznikly jako tabulky přímo v datovém skladu – byly naplněny ručně, včetně např. dimenze „Datum“, která byla ručně generována pro rozpětí možných dat v intervalu let 2000 až 2020. Logický model je vytvořený. Jsou i namapovaná data k vytvořenému logickému modelu (data faktových tabulek viz příloha č. 2). Lze tedy přejít k tvorbě fyzického modelu.
2.4.3.2 Fyzický model Fyzický model je realizací logického modelu v prostředí zvolené implementační platformy. Názvy ve fyzickém modelu jsou již takové, jak budu uložené v datovém skladu. Zobrazují se
~ 35 ~
zde jen skutečné dimenze (dimenzionální tabulky), odvozené dimenze se zde neuvádí. Datové typy již jsou vyřešené (viz příloha č.2). Nyní je potřeba zamyslet se nad indexy. Na úvod budou nastaveny primární klíče na umělé identifikátory jednotlivých tabulek a dále budou nastaveny klasické databázové indexy na jednotlivých cizích klíčích a současně i na jednotlivých atributech dimenzionálních tabulek. Předpokládáme, že míra využití jednotlivých indexů bude v rámci zkušebního provozu vyhodnocena a indexování bude dále upravováno. Výsledek tvorby fyzického modelu prezentuje následující schéma. DPravdepodobnost
DDivize FPlanDivize PlanDivizeId
DivizeId
PravdepodobnostId
Nazev
Pravdepodobnost
KodDivize
Popis
PlanObchodnikId DatumId Rok
Kod
DsOd
DatumId
FPlanObchodnik
Kvartal
A4
Rok
DsDo
Kvartal
Neznamo
DivizeId
ProcesId
IdDivize
ZmenilProcesId
ZdrojId
Neznamo
IdZdroje
ProcesId
PlanPrijem
ZmenilProcesId
PlanSkutecnostId
PlanPrijem
DsOd
PlanSkutecnostId
DsDo
DDatum
DsOd
DatumId
DsDo
Datum
ProcesId
Den
ObchodPripadPravdepodobnostId
ZmenilProcesId
NazevDne
ObchodPripadId
PracovniDen
IDObchodnihoPripadu
Tyden
ZakaznikId
PlanAQId
Mesic
DivizeId
DatumId
NazevMesice
FazePripaduId
Rok
PocetDnuMesi...
SektorId
Kvartal
Kvartal
OborId
NazevKvartalu
OdpovednaOsobaId
PocetDnuKvar...
PravdepodobnostId
Rok
Pravdepodobnost
PocetDnuRoku
UzavreniSmlouvyId
PoslDenMesice
ZahajeniProjektuId
PoslDenKvart...
UvedeniDoProvozuId
PoslDenRoku
RozpracovanyId
Neznamo
FakturovaneMesicePresKonecRoku
ProcesId
DsOd
FPlanAQ
DPlanSkutecnost PlanSkutecnostId
PlanPrijem
KodPlanu
PlanSkutecnostId
NazevPlanu
DsOd
Popis
DsDo
Neznamo
ProcesId
ProcesId
ZmenilProcesId
ZmenilProcesId
ProcesId
FObchodPripadPravdepodobnost
DFazePripadu
DruhZdroje Globalni IdZdroje Lidsky MesicniPNC Nazev NTLogin
PrimyNadrizeny
DZakaznik
PoziceFMS
ICO
RBSId
Nazev
TypoveMistoId
Mesto
DenniSazbaBonusu
Kraj
KoeficientZmenyCeny
Zeme
KoeficientDisponibilniKapac...
IDSpolecnosti
DPC
OborCinnosti
PNC
Segment
SkupinaZdroju
OdpovednaOs... PlatformaId DsOd
ProcesId
Skutecny
ZakaznikId
OdpovednaOs...
FazePripaduId
PravidelnyUvazek Vykazuje Kategorie DivizeId PoziceId
Neznamo
DatumNastupuId
ProcesId
DatumVystupuId DsOd
Nazev
ObchodPripadId
KodFazePripadu
IDObchodnihoPripadu
Otevren
ObdobiFakturaceId
Ziskan
ObchodPripadId
DsOd
IDObchodnihoPripadu
AbsolutniLicence
Aktivni
Pohlavi
DsDo
ObchodPripadObratId
AbsolutniPrijem
ZdrojId
OsobniCislo
DsDo
FObchodPripadObrat
DZdroj
DsDo
DObchodPripad FObchodPripadReseni ObchodPripadReseniId
DReseni
DsDo
NazevObchodnihoPri...
ObchodPripadId
ReseniId
AbsolutniSubdodavky
Neznamo
NazevProjektu
IDObchodnihoPripadu
KodReseni
PlanSkutecnostId
ProcesId
TypObchodnihoPripadu
ReseniId
Nazev
DsOd
ZmenilProcesId
Kontakt
PodilReseni
DsOd
DsDo
Zprostredkovatel
DsDo
ProcesId
DsOd
PravdepodobnostId
ZmenilProcesId
DsOd DsDo
DsDo ProcesId ZmenilProcesId
Neznamo ProcesId ZmenilProcesId
Neznamo ProcesId ZmenilProcesId
Obrázek 5 Fyzický model datového skladu
Ve fyzickém modelu si lze všimnout hodnot, které nebyly doposud vysvětleny. Zejména se jedná o technické atributy sloužící pro případnou historizaci dat (nebudou prozatím využívány, historizace na straně datového skladu nebude prováděna) a o atributy ETL mechanismů, které identifikují konkrétní procesy, kterými byl daný řádek tabulky vložen či změněn. Podrobné vysvětlení použitého způsobu a logiky ETL transformací je nad rámec této práce.
~ 36 ~
2.5
Technologická platforma Kapitola je zaměřena na popis využívaných nástrojů pro navrhované řešení. Jelikož
společnost úzce spolupracuje s firmou Microsoft, jsou využívané nástroje především z dílny Microsoftu. Firma Microsoft nabízí pro Business Intelligence integrované řešení na platformě SQL Serveru (SQL Server 2005).Proto budou představeny jednotlivé nástroje, jejichž funkcionalitu využijeme pro naše řešení. Na straně databázového serveru je tedy již zmíněný MS SQL Server 2005. Jeho součástí jsou škálovatelné komponenty pro Business Intelligence. Mezi komponenty MS SQL 2005 patří Integration services pro zajištění fungování ETL procesů, dále Analysis services pro tvorbu OLAP databáze (OLAP kostek). Reporting je realizován pomocí komponenty Reporting services. Pro výstupy nad daty jsou využívány nástroje MS Office, jako jsou Excel pro ad hoc dotazy nad OLAP kostkami a SharePoint Portal Server pro publikaci předpřipravených výstupů nad OLAP v Excelu. Pro zobrazení publikovaných tabulek na firemním portálu i reportů vystavených na reportovacím serveru je třeba mít internetový prohlížeč Microsoft Internet Explorer.
MS SQL Server Zde je uložená celá databáze v podobě běžné relační databáze. Správa databáze je realizována v aplikaci Management Studio.
Integration services (SSIS) Tento nástroj zajišťuje řízení procesů integrace, transformace a přesunu dat, tedy ELT procesy. SSIS dokáže získávat data z různých zdrojů, jako je SQL, vlastní datové zdroje, např. ve formátu xls popřípadě komponenty text miningu. SSIS umí s těmito daty pracovat bez ohledu na to, odkud pochází. Nástroj umožňuje provádět různé druhy transformací, jako například podmíněné rozdělení dat, konverze dat, spojování dat, odvozené sloupce, agregace, lookup (kontrolní dotazy). Navíc SSIS také dokáže spouštět ActiveX prvky, spouštět procesy systému, dotazovat se do dataminigového modelu, stahovat a nahrávat soubory z FTP serveru, posílat maily pomocí SMTP serveru, procesovat OLAP databáze i jejich části, spouštět metody nějaké webové služby, přenášet objekty SQL serveru mezi SQL servery, kopírovat, přesouvat a mazat soubory a adresáře. [SSIS]
Analysis services (SSAS)
~ 37 ~
I když je SSAS součástí Microsoft SQL Serveru, je tento OLAP server na SQL serveru nezávislý. Pro komunikaci s klienty využívá tento nástroj rozhraní OLE DB pro OLAP a implementuje dotazovací jazyk MDX, který se standardně používá pro dotazování v multidimenzionálním datovém prostoru. Nástroj lze snadno integrovat do internetových či intranetových aplikací. Analysis Services navíc podporuje tvorbu fyzických, virtuálních kostek a dimenzí, možnost uložení dat kombinací HOLAP, MOLAP, ROLAP, možnost pohlížet jen na části kostek a objektové modelování (DSO, ADO MS).[SSAS]
Reporting services Reporting services nabízí možnost tvorby, správy a doručování sestav (reportů), které je možné prohlížet jak ve webové podobě, tak si tyto sestavy nechat zasílat na mail. Reporty je možné nechat exportovat do různých formátů, jako je PDF, Excel a dalších. Reporty se vytvářejí pomocí sady Microsoft Visual Studio, konkrétně upravená verze - SQL Server Business Intelligence Development Studio. V tomto nástroji lze reporty připojit k vlastnímu zdroji, navrhnout jejich vzhled, popřípadě definovat další výstupní formáty. Uživatel sice nemá moc velkou možnost si vytvořené reporty přizpůsobovat (kromě využití filtrů), zato mu nabízí často složité předpřipravené pohledy na data. [SRS] Nástroje MS Office Pohledy na data z OLAP kostek si uživatelé tvoří sami, a to ve formě kontingenčních tabulek v nástroji MS Office Excel. Některé kontingenční tabulky jsou publikovány na portále firmy. Ten je vytvořen v aplikaci Office SharePoint Serveru. Portál je využíván pro publikaci informací týkající se zaměstnanců, chodu firmy (firemní dokumenty). Najdeme zde ale i podrobnosti k projektům a další důležité informace. Firma má technologickou platformu již zvolenou, proto nebylo třeba řešit tuto otázku. Využili jsme jen zaběhnutého postupu. Základem platformy je MS SQL server 2005, který obsahuje komponenty pro Business Inteligence.
~ 38 ~
2.6
Implementace vybrané části a její testování V předchozích kapitolách byl popsán kompletní postup tvorby BI řešení na úrovni návrhu
řešení, datového a dimenzionálního modelování. Jelikož omezená kapacita práce nedovoluje více, v kapitole implementace se zaměřím jen na vybranou oblast - implementaci reportů. Důvodem tak podrobného popisu postupu tvorby je jednak zajímavý způsob použité logiky (využití parametrů) a jednak má aktivní účast na této fázi.
2.6.1 Implementace
(realizace)
prezentace
poţadovaných
výstupů
s vyuţitím zvolených klientských aplikací Poslední fází tohoto projektu je vytvoření uživatelsky přívětivého prostředí pro sledování požadovaných dat dle návrhů z počátečních fází projektu, a to prostřednictvím reportů. Kapitola je věnována postupu tvorby reportů jak ze stránky logického uspořádání, tak práce ve vývojovém prostředí Visual Studia.
2.6.1.1 Shrnutí poţadovaného výsledku Na úvod by bylo dobré ujasnit si, co je vlastně požadovaným výsledkem – jakou strukturu bude mít výsledné řešení. Následující výčet obsahuje všechny požadavky. 1. Sestava obchodní případy celkem – pohled za celou firmu Filtry: rok, divize, obchodník Subreporty: Pravděpodobný příjem kumulovaný (data rozřazena dle intervalů pravděpodobnosti za jednotlivá čtvrtletí) Pravděpodobný příjem dle fáze (data rozřazena dle fází případů – jen aktivní fáze za jednotlivá čtvrtletí) Pravděpodobný příjem dle řešení (data rozřazena dle druhů řešení za jednotlivá čtvrtletí) Obchodní příležitosti s pravděpodobností 100% (detail obchodních příležitostí) Obchodní příležitosti s pravděpodobností <80% (detail obchodních příležitostí) Obchodní příležitosti s pravděpodobností >=80% (detail obchodních příležitostí) Příjmy za jednotlivá řešení (detail obch. příležitostí seřazených podle řešení) 2. Sestava obchodní případy celkem – pohled za divize Filtry: rok, divize Subreporty: Pravděpodobný příjem kumulovaný (data rozřazena dle intervalů pravděpodobnosti za jednotlivá čtvrtletí) Pravděpodobný příjem dle fáze (data rozřazena dle fází případů – jen aktivní fáze za jednotlivá čtvrtletí) Pravděpodobný příjem dle řešení (data rozřazena dle druhů řešení za jednotlivá čtvrtletí) Pravděpodobný příjem dle divize (data rozřazena dle divizí) Obchodní příležitosti s pravděpodobností 100% (detail obchodních příležitostí)
~ 39 ~
Obchodní příležitosti s pravděpodobností <80% (detail obchodních příležitostí) Obchodní příležitosti s pravděpodobností >=80% (detail obchodních příležitostí) Příjmy za jednotlivá řešení (detail obch. příležitostí seřazených podle řešení) 3. sestava obchodní případy celkem – pohled za obchodníky Filtry: rok, obchodník Subreporty: Pravděpodobný příjem kumulovaný (data rozřazena dle intervalů pravděpodobnosti za jednotlivá čtvrtletí) Pravděpodobný příjem dle fáze (data rozřazena dle fází případů – jen aktivní fáze za jednotlivá čtvrtletí) Pravděpodobný příjem dle řešení (data rozřazena dle druhů řešení za jednotlivá čtvrtletí) Pravděpodobný příjem dle obchodníka (data rozřazena dle obchodníků za jednotlivá čtvrtletí) Obchodní příležitosti s pravděpodobností 100% (detail obchodních příležitostí) Obchodní příležitosti s pravděpodobností <80% (detail obchodních příležitostí) Obchodní příležitosti s pravděpodobností >=80% (detail obchodních příležitostí) Příjmy za jednotlivá řešení (detail obch. příležitostí seřazených podle řešení) 4. sestava Neuskutečněné příležitosti Filtry: rok, obchodník, divize Subreporty: Pravděpodobný příjem dle fáze (data rozřazena dle fází případů – jen stornované fáze) Pravděpodobný příjem dle řešení (data rozřazena dle druhů řešení za jednotlivá čtvrtletí) Obchodní příležitosti s pravděpodobností 0% (detail obchodních příležitostí) Příjmy za jednotlivá řešení (detail obch. příležitostí seřazených podle řešení) 5. sestava Licence a subdodávky – jediný report Filtry: rok
2.6.1.2 Logika I když je cílem vytvořit 4 sestavy (4 sady reportů – Obchod celkem - divize, obchod celkem - obchodník, obchod celkem - firma, neuskutečněné příležitosti), které se budou skládat ze čtyř až sedmi reportů, bude třeba vytvořit jen čtyři základní reporty, viz dále. Tyto reporty pak budou vkládány do konečných reportů (sestav) jako subreporty. Těm pak budou nastaveny parametry tak, aby se zobrazovala požadovaná data. Proto je důležité si na začátek definovat použité parametry. Parametry Parametr je pohled do dimenze na její jednotlivé prvky. Na základě výběru prvků dimenze – výběru hodnot parametru - je možné zobrazovat jen data vybraných prvků.
~ 40 ~
Parametry je třeba definovat u již zmíněných čtyř základních reportů. V tomto projektu je použito osm parametrů. Jejich použití v jednotlivých reportech je vyznačeno v níže uvedené tabulce.
x x x x x x
Příjmy za jednotlivá řešení
Rok Obchodník Divize Report Plán Omezení fáze Pravděpodobnost od Pravděpodobnost do
Obchodní příleţitosti Dle pravděpodobnosti
Parametry
x x x x
x x x
x x x
x
x x x
x
Pravděpodobný příjem plán
Pravděpodobný příjem kumulovaně
Tabulka 14 Výskyt parametrů v jednotlivých sestavách
Některé parametry budou sloužit uživateli k filtrování dat, jiné slouží ke změně zobrazovaných dat. Tyto parametry ovšem ovlivňují tvůrci reportů jejich nastavením. Pro přehlednost je uveden výpis jednotlivých parametrů a hodnoty, kterých nabývají. a) Parametry sloužící uživateli Parametry „Rok“, „Obchodník“ a „Divize“ budou moci využívat uživatelé k filtrování zobrazovaných dat. Tabulka 15 Přehled parametrů pro uživatele Parametr Rok Obchodník Divize
Hodnoty roky od 2000 do 2011 jména obchodníků Divize D1, D2, D3, ISL
Význam hodnoty zobrazení hodnot za vybraný rok označení divize
Rok Tento parametr slouží pro uživatele jako filtr a bude zobrazen ve všech čtyřech sestavách, zároveň i v reportu Licence a subdodávky. Jeho přínosem je možnost sledovat data za jednotlivé roky. Obchodník Parametr obchodník slouží jako filtr pro uživatele a bude použit ve všech čtyřech sestavách. Hodnoty parametru jsou jména jednotlivých obchodníků.
~ 41 ~
Divize Parametr divize také slouží jako filtr pro uživatele. Opět bude zobrazen ve všech čtyřech sestavách. Hodnotami jsou v současnosti divize D1, D2, D3 a ISL. b) Skryté parametry K těmto parametrům uživatelé nebudou mít přístup. Slouží k usnadnění tvorby reportů. Stačí vytvořit čtyři základní typy reportů, k nim vytvořit SQL dotazy, které budou pracovat s parametry. A tyto reporty pak vložit do konečných sestav jako subreporty (některé i několikrát do jedné sestavy) a nastavit jim správné hodnoty tak, aby se volala správná část SQL dotazu. Zobrazovaná data budou ovlivňována parametry „Report“, „Plán“ a „Omezení fáze“ a parametry „Pravděpodobnost od“ a „Pravděpodobnost do“. Tabulka 16 Přehled parametrů pro ovlivňování zobrazovaných dat Parametr
Report
Plán
Omezení fáze Pravděpod. od Pravděpod. do
Hodnota
Význam hodnoty
Pouţití vybere sadu popisků pro data k reportu Pravděpodobný příjem kumulovaně vybere sadu popisků pro data k reportu Pravděpodobný příjem dle Divize vybere sadu popisků pro data k reportu Pravděpodobný příjem dle fáze vybere sadu popisků pro data k reportu Pravděpodobný příjem dle řešení
kum
kumulovaně
div
divize
faz
fáze
res
řešení
ob obchodni k divize plan aktiv
obchodník výše plánu definovaného pro obchodníky výše plánu definovaného pro divize výše plánu za celou firmu aktivní fáze (1-7)
storno
stornované fáze (8-10)
číslo
%
číslo
%
vybere sadu popisků pro data k reportu Pravděpodobný příjem dle obchodníka vybere plán definovaný obchodníky vybere plán definovaný divizemi vybere plán definovaný za celou firmu pro výběr aktivních obchodních případů Pro výběr případů, které byly stornovány počáteční hodnota poţadovaného intervalu konečná hodnota poţadovaného intervalu
Report Parametr report slouží pro správné popisy zobrazovaných dat (v řádcích). SQL dotaz je utvořen tak, aby dle zvoleného parametru byly vybrány popisky pro report kumulovaný, dle fází, dle řešení a report, který sleduje obchod dle divizí, nebo podle obchodníků. Plán Parametr plán se využívá jen v reportu pravděpodobný příjem kumulovaně. Zobrazuje plány definované pro divize, obchodníky a celou firmu.
~ 42 ~
Omezení fáze Jelikož zobrazujeme 3 sestavy, které se týkají aktivních případů (fáze 1 až 7) a jednu sestavu, která se vztahuje ke stornovaným případům (fáze 8-10), použiji pro rozlišení těchto dvou stavů parametr „Omezení fáze“. Pravděpodobnost od, pravděpodobnost do Pravděpodobnost bude v reportech zobrazována v intervalech, vždy jeden report pro určitý interval. Pro zadání intervalu jsou potřeba 2 parametry: „Pravděpodobnost od“ a „Pravděpodobnost do“. Pět parametrů slouží tvůrci reportů pro ovlivňování zobrazovaných dat. Pro uživatele by manipulace s nimi byla dosti pracná. A cílem je vždy co nejvíce usnadnit práci uživatelům. Ostatní tři parametry budou moci využívat uživatelé podle svých potřeb.
2.6.1.3 Tvorba reportu ve vývojovém prostředí Jelikož je rozsah této práce omezený, není třeba zde uvádět tvorbu všech reportů, ale bude popsána tvorba jen jednoho reportu. Cílem této kapitoly není obsáhnout všechny vzniklé reporty, ale popsat principy vzniku. Tvorba reportů v nástroji Microsoft SQL Reporting Services 2005 má dvě fáze, a to tvorba samotného vzhledu a naplnění reportu daty pomocí Report Designeru - integrovaného SQL Serveru Business Intelligence Development Studia, což je upravená verze
Visual Studia.
Druhou fází je publikace reportů a jejich následná správa. Reporty jsou ukládány v jazyce RDL (Report Definition Language), jehož kód je vyjádřen pomocí dokumentu XML. Při vzniku nového projektu RS je možné použít průvodce vytvořením nového projektu RS, nebo projekt RS vytvořit ručně. V programu Visual Studio se při tvorbě reportů v návrhovém okně pracuje ve třech režimech: Data, Layout a Preview. Režim Data Je třeba definovat data, se kterými se bude pracovat, a to pomocí SQL dotazu. V tomto reportu stačí vytvořit jen jeden dataset5. Parametry určené k možnosti filtrování pro uživatele bude výhodnější definovat až na úrovni celé sestavy (viz dále). Tímto krokem jsme si definovali zdroj dat a obsah reportu.
5
Dataset obsahuje informace pro selekci požadované množiny dat. [LAC]
~ 43 ~
Obrázek 6 Visual Studio - Karta Data
Režim Layout Zde je třeba učinit několik kroků: Navrhnout design reportu Karta slouží pro grafický návrh reportů. Grafické prvky (prvek table = tabulka, prvek Chart = graf, atd.) jsou umístěny v levé části obrazovky na panelu Toolbox. Odsud stačí jednotlivé grafické prvky přetáhnout na formulář pro návrh reportu (oblast grafického návrhu). Nejvhodnější pro tento report je grafický prvek „Table“ (tabulka). Tabulce je možné navrhnout formát (podbarvení jednotlivých buněk, typ písma/číslic umístěných v buňkách, zarovnání hodnot atd.) na panelu „Properties“. Vložit data do tabulky Je třeba vytvořit skupiny (Groups), které budou reprezentovat jednotlivé řádky. Do těchto skupin se vloží atributy z panelu „Datasets“, které jsou potřeba. Pozn.: Na obrázku č. 7 je panel „Datasets“ schován pod panelem „Toolbox“. Popisky sloupců a popisky některých řádek je třeba doplnit ručně. Atributy vyjadřující sledované
~ 44 ~
hodnoty lze agregovat (sčítat, vytvářet vzorce), popřípadě tvořit podmínky, na základě kterých bude založeno chování jiných komponent. V tabulce se budou zobrazovat hodnoty „Celkem plán“, „Operativní plán“,“Celkem skutečnost“, „Odchylka od plánu“ a „Plán plnění“. Aplikace umí rozpoznat, že se jedná o číselné hodnoty, a sama doplní sumarizační funkci do buněk. Vložit graf Přetažením grafu (Chart) z nabídky panelu „Toolbox“ na požadované místo se umístí požadovaný grafický prvek do oblasti pro návrh reportu. Způsob tvorby grafu je dosti podobný tvorbě grafu v MS Office Excelu.
Obrázek 7 Visual Studio - karta Layout
Definovat parametry Parametry se definují v dialogovém okně „Report Parameters“ na kartě „Report“. Zde se definuje chování parametrů: zda budou viditelné, jakého jsou datového typu, jaká bude výchozí hodnota, kterými daty se mají parametry plnit (parametr lze napojit na dataset) atd.
~ 45 ~
Při tvorbě reportu je třeba neustále kontrolovat výsledky na záložce Preview (Náhled). Zde se zobrazují i parametry, které budou ve výsledných sestavách nastavené na určité hodnoty. Pro možnost kontroly v režimu„Preview“ jsou parametry nastaveny tak, aby se zobrazovaly ve formě komboboxu.
Obrázek 8 Visual Studio - Nastavení parametrů
Report by se měl být hotový. Teď už se jen stačí přesvědčit o výsledku na záložce „Preview“. Režim Preview Tento režim slouží k ověřování výsledků. Režim simuluje vzhled reportu vystaveného na serveru. Dalším důvodem užití tohoto režimu je kontrola zobrazovaných dat.
~ 46 ~
Obrázek 9 Visual Studio - karta Preview
Tímto způsobem se vytvoří všechny čtyři základní reporty.
2.6.1.4 Tvorba sestavy (sady reportů) V této podkapitole bude popsána tvorba sestavy, která je složená z několika reportů. Jelikož je postup u všech sestav obdobný, Obchodní případy celkem – divize. Prvním krokem je vytvoření nového reportu. Režim Data Jelikož budou v tomto reportu volány jednotlivé základní reporty, které už mají nadefinovaný dataset, není třeba tvořit hlavní dataset pro tento report. Je ale třeba vytvořit datasety pro parametry, které budou k filtrování využívat uživatelé sestav. Parametry „Rok“, „Obchodník“ a „Divize“ se vytvoří obdobně, jako byl tvořen hlavní dataset v dílčím reportu. Režim Layout Volba grafických prvků Z panelu Toolbox tentokrát použiji grafický prvek Subreport (vnořený report), který umožňuje volat již vytvořený report. Tento prvek je třeba vložit do reportu hned osmkrát, jelikož chceme v této sestavě zobrazovat osm reportů.
~ 47 ~
Obrázek 10 Visual Studio - tvorba konečné sestavy pomocí subreportů
Nastavení grafického prvku Ve vlastnostech subreportů je třeba nastavit, jaký report že se má jako subreport zobrazovat, a také se zde nastaví hodnoty parametrů. První subreport bude zobrazovat Pravděpodobný příjem kumulovaný. Ve vlastnostech subreportu (Subreport Properties) na kartě „General“ se doplní název subreportu a report, který se má zobrazovat, tedy „Pravdepodobny_prijem_kumulovane_plan“ (viz Obrázek 11 Visual Studio - nastavení subreportu) . Na kartě „Parameters“ se nastavují parametry. Parametry, které jsou buď viditelné (uživatel je bude nastavovat dle své libosti), nebo je pro tento případ nepoužijeme (není
důvod
jej
nastavovat),
definujeme
pomocí
syntaxe
=Parameters!NázevParametru.Value. To znamená, že v subreportu se pak počítá s hodnotami, které mají parametry defaultně nastavené v „Report parameters“ ( viz pbrázek č. 8). Parametrům, které ovlivňují pohled na data, je třeba určit přesně danou hodnotu, jejíž význam je zanesen do SQL dotazu. Tedy například když zvolím hodnotu parametru „Report“ rovnu „kum“, říkám tím: „Proveď takovou část dotazu, která je v SQL definovaná pro @Report6=“kum“ a navrať hodnoty tomu odpovídající. 6
@ symbolizuje v T-SQL označení parametru.
~ 48 ~
Pro parametr „Report“ bude nastavena hodnota„kum“, která vybere popisky pro subreport, a pro parametr „Plán“ hodnotu „divize“, která vybere hodnoty plánu rozpadnuté dle divizí.
Obrázek 11 Visual Studio - nastavení subreportu
Tento postup se opakuje u všech subreportů. Nemá smysl zde popisovat nastavení každého subreportu zvlášť, proto si zde uvedeme jen výčet nastavení parametrů v této sestavě.
Tabulka 17 Nastavení parametrů pro subreporty v sestavě Obchod celkem - Firma Subreporty Pravděpodobný příjem kumulovaně plán
Parametry Plán
divize
Report
kum
Pravděpodobný příjem plán
faz
Pravděpodobný příjem plán
res
Obchodní příleţitosti dle pravděpodobnosti Obchodní příleţitosti dle pravděpodobnosti Obchodní příleţitosti dle pravděpodobnosti Obchodní příleţitosti dle pravděpodobnosti
Omezení Fáze odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše) odkaz na defaultní hodnotu (Vše)
Pravděpod. Pravděpod. od do
100
100
80
99
0
79
Postup při tvorbě dalších tří sestav „Obchodní případy celkem – pohled za divize“, „Obchodní případy celkem – pohled za celou firmu“ a sestava „Neuskutečněné příležitosti“ bude obdobný. A tvorba reportu „Licence a subdodávky“ bude obdobná, jako tvorba jednoduchého reportu (kap. 2.6.1.3 Tvorba reportu ve vývojovém prostředí).
~ 49 ~
Podařilo se vytvořit všechny požadované výstupy, nyní stačí vystavit sestavy na server. To se realizuje také z prostředí Visual Studia. Výsledek je možné shlédnout v příloze č. 3. Pro ukázku je zde představena jedna sestava Obchodní případy celkem – pohled za divize. Kvůli citlivosti zobrazovaných informací byly údaje upraveny tak, aby je nebylo možné rozpoznat zobrazované cifry.
2.6.2 Testování reportů Celkové řešení je sice hotové, ovšem práce ještě zdaleka nekončí. Vzniklé sestavy je třeba důkladně otestovat. A to jak z hlediska estetického, funkčního, tak z hlediska správnosti zobrazovaných dat. Ovšem testování dat není tak úplně snadná věc. Zde si klademe otázku: „Co je vlastně pravda?“ Odpověď na otázku musíme nalézt. Pozn.: V práci je testování omezeno jen na testování výstupů, tedy reportů, ovšem v běžném BI řešení se vždy musí testovat všechny vrstvy, nejen výstupy. Při zobrazování dat můžeme narazit na několik problémů: a) Chybné zobrazování dat z důvodu špatně použité struktury dat Pokud je dobře navržen datový sklad, bývá tento problém spíše v SQL dotazu, například špatně zvolené navázání tabulek. b) Chybné zobrazování dat z důvodu nefunkčnosti některé z komponent Hodně komponent pracuje automaticky – jejich funkčnost byla nastavena v průběhu tvorby řešení BI. Ovšem může se stát, že některá z komponent přestane z nějakého důvodu fungovat tak, jak má. Příkladem může být nefunkčnost ELT procesů. c) Chybné zobrazování dat z důvodu nepochopení požadavku uživatele Při sestavování řešení je velice důležité mít přehled o tom, s jakými daty pracujeme. Potřebujeme rozumět problematice. Ale přestože problematice rozumíme (i když zřídkakdy stejně dobře, jako uživatel), nemusí být při definici požadavků uživatele řečena jasně pravidla, která by měl uživatel rád zachycená ve výsledku. To může být z důvodu opomenutí, nebo proto, že uživatel informaci pokládá za automatickou (On to ví, jelikož s tím každý den přichází do styku). To se ovšem projeví až při odevzdání výsledné práce. Proto je důležité komunikovat při jakýchkoli nesrovnalostech se zadavatelem (uživatelem). Vyhneme se tak případným problémům při odevzdávání naší práce. Nyní se vrátíme k otázce, jak nalézt pravdu. Nejlepším způsobem, jak nalézt pravdu a tím i uspokojit uživatele, je kromě správně vedeného dialogu mezi uživatelem a tvůrcem ještě před začátkem tvorby projektu dotazovat se uživatele na případné nesrovnalosti. Dalším krokem by
~ 50 ~
mělo být předvedení práce a vysvětlení funkcionality po dokončení projektu. Tím se vyjasní, zda námi utvořená představa o cíli byla shodná s původní představou uživatele. Konečnou odpověď na otázku získáme tehdy, když uživatel po nějaké době užívání našeho výtvoru spokojeně pokyvuje hlavou. Pak je naše práce hotová. Ovšem jen do té doby, dokud nepřijde požadavek na rozšíření, nebo úpravu stávajícího řešení.
~ 51 ~
3. Závěr Výsledkem práce jsou výstupy pro analýzu a monitorování obchodních dat firmy, která se zabývá vývojem softwaru. V práci byl tedy splněn hlavní cíl. Pro pochopení práce bylo třeba nejprve vytvořit teoretický základ k oboru Business Intelligence. V projektu byla použita analýza uživatelských požadavků a analýza datových zdrojů. Na analýzu navazovalo datové a dimenzionální modelování, čímž byly splněny i dílčí cíle práce. V práci je popsána jen jedna část implementace řešení – realizace požadovaných výstupů (reportů) s využitím nástrojů Microsoft SQL Serveru 2005. Výsledky této konečné fáze jsou i důkazem splnění vytyčeného cíle. Díky tomuto projektu může firma, pro kterou byl tento projekt realizován, sledovat obchodní příležitosti a porovnávat tyto hodnoty s obchodními plány. Díky nim lze hodnotit práci obchodníků, sledovat vývoj vzhledem k určeným obchodním plánům a odhadovat objem příjmů. Zároveň je možné na základě výstupů hlídat, zda množství pracovních zdrojů je dostačující. Výstupy z projektu jsou využívány na pravidelných poradách. Na jejich základě je pak rozhodováno o dalších krocích, které by firma měla podnikat. Velký přínos měl projekt i pro mě. Měla jsem možnost zapojit se do reálného projektu. Pochopila jsem principy datového a dimenzionálního modelování. Tuto znalost jsem v bakalářské práci také prezentovala. Naučila jsem se pracovat s nástroji pro tvorbu reportů. K tomu bylo třeba i rozšířit si znalosti SQL jazyka. Popisované BI řešení se bude nadále upravovat a rozvíjet. Již teď jsou známy další požadavky uživatelů. Data by měla být na straně datového skladu historizována. Na to už je datový sklad připraven. Díky historizaci dat bude možné sledovat přizpůsobování plánů a pravděpodobnosti získání obchodních případů v časovém horizontu. Na základě historizace dat budou moci vznikat další výstupy, které přispějí k ještě kvalitnější analýze vývoje obchodních případů.
~ 52 ~
Seznam literatury Literatura [GAL] GÁLA, Libor, POUR, Jan, TOMAN, Prokop. Podniková informatika. 1. vyd. Praha : GRADA, 2006. 484 s. ISBN 80-247-1278-4. [KIM] KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit : The Complete Guide to Dimensional Modeling. 2nd edition. New York : John Wiley & Sons, 2002. xvii, 421 s. ISBN 0-471-20024-7 [LAC] LACKO, Luboslav. Business inteligence v SQL Serveru 2005. 1. vyd. Brno : Computer Press, 2006. 388 s. ISBN 80-251-1110-5. [LAK] LACKO, Luboslav. Datové sklady, analýza OLAP a dolování dat. 1. vyd. Brno : Computer Press, 2003. 486 s. ISBN 80-7226-969-0. [NOV] NOVOTNÝ , Ota, POUR, Jan, SLÁNSKÝ, David. Business Intelligence : jak využít bohatství ve vašich datech. 1. vyd. Praha : Grada Publishing, 2005. 254 s. ISBN 80-247-1094-3.
~ 53 ~
Elektronické zdroje
[AMB] Amica s. r. o.. Microsoft SQL Server 2005/2008 [online]. 2008 [cit. 2008-11-25]. Dostupný z WWW: http://www.ambica.cz/content/view/27/41/ . [BIV] Přednášky z předmětu Business Intelligence, VŠE Praha [on-line]. Novotný, O., Pour, J., Slánský, D.: http://kit.vse.cz [INB] Microsoft. Integrované nástroje Business Intelligence [online]. 2006 [cit. 2008-12-12]. Dostupný z WWW: http://www.microsoft.com/cze/windowsserversystem/sql/solutions/bi/default.mspx . [MIS] Microsoft Business Intelligence Suite [online]. c2008 [cit. 2009-01-01]. Dostupný z WWW: http://www.microsoft.com/bi .
[PIR] PIRKL, David. Datové sklady [online]. 2004 [cit. 2008-10-26]. [dokument ve formátu PDF]. Dostupný z: http://www.datakon.cz/datakon04/d04_it_pirkl.pdf . [PRE] Novotný, O., Pour, J., Slánský, D Přednášky z předmětu Business Intelligence, VŠE Praha [on-line]..: http://kit.vse.cz [SSAS] Amica s. r. o.. SQL Server 2000 Analysis Services [online]. 2008 [cit. 2008-11-25]. Dostupný z WWW: http://www.ambica.cz/content/view/45/81/. [SSIS] Amica s. r. o.. SQL Server 2005 Integration Services (SSIS) [online]. 2008 [cit. 2008-1125]. Dostupný z WWW: http://www.ambica.cz/content/view/44/79/. [SRS] Amica s. r. o.. SQL Server Reporting Services (RS) [online]. 2008 [cit. 2008-11-25]. Dostupný z WWW: [SQL] Microsoft. SQL Server 2005 Documentation [online]. 2008 [cit. 2008-11-25].. Dostupný z WWW:http://msdn2.microsoft.com/en-us/library/ms203721.aspx .
~ 54 ~
Terminologický slovník Terminologie v oblasti BI není v českém jazyce ani mezi odborníky zcela sjednocena. Pro jednu skutečnost se vyskytuje několik pojmů, proto uvádím ty, které používám ve své práci. A zároveň budou v následujícím textu výrazy, které nemusí být běžnému čtenáři zcela známé.
Pojem Ukazatel
Význam hodnota uložená v dimenzionálním prostoru, na kterou je nahlíženo z různých dimenzí. Ukazatelé jsou většinou číselného typu
Fakt
viz ukazatel
Pohled
pohled na ukazatel specifikovaný přesně vymezenými dimenzemi
Dimenze
kontextová složka, která dává význam faktům. V dimenzi uložená data jsou většinou textového charakteru. Tato data popisují fakta (On-Line Analytical processing) – provádění analýzy dat v reálném čase pomocí
OLAP
online technologií umožňující konzistentní přístup k informacím datového skladu [NOV]
Atribut
Report
1) vlastnost dimenze 2) sloupec tabulky ve zdrojovém systému slouží pro zpřístupnění dat a výsledků analýz uživatelům ve vhodné formě, obsahu a rozsahu
Subreport
dílčí report, který je složkou konečného reportu
Dataset
databázová část reportu , SQL dotaz
Kombobox databázová část reportu , SQL dotaz Parametr CRM
ETL
pomocná proměnná; jeho hodnoty jsou plněny z hodnot dimenzí (Customer relationship management) – shromažďování, zpracování a využití informací o zákaznících podporované databázovými technologiemi (Extraction-Transformation-Loading) nebo ztv. Datové pumpy, slouží k extrakci, transformaci a načítání dat. Zajištuje i čištění dat.
~ 55 ~
Seznam pouţitých tabulek Tabulka 1 Návrh reportu "Pravděpodobný příjem" .......................................................14 Tabulka 2 Návrh reportu "Pravděpodobný příjem dle řešení" ......................................14 Tabulka 3 Návrh reportu "Pravděpodobný příjem dle fáze" .........................................15 Tabulka 4 Návrh reportu "Obchodní příleţitosti s pravděpodobností" ..........................15 Tabulka 5 Návrh reportu "Příjmy za jednotlivá řešení" .................................................16 Tabulka 6 Návrh reportu „Licence a subdodávky“ .......................................................17 Tabulka 7 MXC - Comanies ........................................................................................21 Tabulka 8 MXC - Contacts ..........................................................................................22 Tabulka 9 MXC - Opportunities ...................................................................................22 Tabulka 10 MXC - Projects..........................................................................................23 Tabulka 11 MXC - SmlouvyXs .....................................................................................23 Tabulka 12 Vztahy mezi dimenzemi a ukazateli ..........................................................30 Tabulka 13 Vazby mezi dimenzemi a faktovými tabulkami ..........................................33 Tabulka 14 Výskyt parametrů v jednotlivých sestavách ...............................................41 Tabulka 15 Přehled parametrů pro uţivatele ...............................................................41 Tabulka 16 Přehled parametrů pro ovlivňování zobrazovaných dat .............................42 Tabulka 17 Nastavení parametrů pro subreporty v sestavě .........................................49
Seznam pouţitých obrázků Obrázek 1 Obecná koncepce architektury BI [zdroj: NOV] ............................................6 Obrázek 2 Hlavní komponenty BI a jejich vazby [zdroj: NOV] ........................................7 Obrázek 3 Architektura datového skladu firmy ............................................................26 Obrázek 4 Logický model datového skladu .................................................................31 Obrázek 5 Fyzický model datového skladu .................................................................36 Obrázek 6 Visual Studio - Karta Data ..........................................................................44 Obrázek 7 Visual Studio - karta Layout .......................................................................45 Obrázek 8 Visual Studio - Nastavení parametrů ..........................................................46 Obrázek 9 Visual Studio - karta Preview .....................................................................47 Obrázek 10 Visual Studio - tvorba konečné sestavy pomocí subreportů .....................48 Obrázek 11 Visual Studio - nastavení subreportu .......................................................49
~ 56 ~
Přílohy Příloha č.1 Popis jednotlivých dimenzí Dimenze: čas ID DCas Struktura Prvky Struktura 1 dny Atributy: rok, kvartál, měsíc MX Zdroje: Cotact
Počty 2550
Dimenze: Zázaník ID DZakaznik Struktura Prvky Počty Struktura 1 firma (=zákazník) 30 ZakaznikID, ICO, Nazev, Mesto, Kraj, Zeme, IDSpolecnost, Obor cinnosti, Atributy: OdpovednaOsoba, Zdroje: MX Contact Dimenze: Fáze ID Dfaze Struktura Prvky Počty Struktura 1 Fáze 10 1.1. Příleţitost 1 1.2. Zájem 1 1.3. Poptávka 1 1.4. Nabídka 1 1.5. Vyhraná nabídka 1 1.6. Smlouva 1 1.7. Dokončeno 1 1.8. Zrušeno 1 1.9. Nevybráno 1 1.10. Odsotoupeno 1 FazePripaduID, Nazev, KodFazePripadu, Atributy: Otevren, Ziskan Zdroje: číselník Dimenze: Řešení ID Dreseni Struktura Struktura 1 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.
Atributy: Zdroje:
Prvky
Řešení_Celkem BI & DWH ERP Integrace aplikací Konzultace Ostatní Podpora provozu Zakázkový vývoj 1.7. aplikací ReseniID, KodReseni, Nazev číselník
~ 57 ~
Počty 7 1 1 1 1 1 1 1
Dimenze: Divize ID Ddivize Struktura Struktura 1 1.1. 1.2. 1.3.
Atributy: Zdroje:
Prvky Divize_celkem D1 D2 D3
Počty 3 1 1 1
DivizeID, Nazev, KodDivize číselník
Dimenze: Obchodník ID Dobchodnik Struktura Prvky Struktura 1.1. Obchodník Atributy: ObchodnikID, nazev, kontakt Zdroje: MX Contact
Počty 5
Dimenze: Plán/skurtečnost ID DPlan Struktura Prvky Počty Struktura 1 Plán 1.1. Operativní plán 1.2. Prognóza 1.3. Roční plán 1.4. Skutečnost 1.5. Roční plán divize 1.6. Roční plán obchodníků Atributy: PlanSkutecnostID, KodPlanu, NazevPlanu Zdroje: Data obchodních plánů Dimenze: Pravděpodobnost ID DPravdepodobnost Struktura Prvky Struktura 1.1. >=80% 1.2. <80% 1.3. 100%
Atributy: Zdroje:
Počty
PravdepodobnostID, PRavdepodobnost, Popis, Kod číselník
Dimenze: DobchodniPripad ID DObchodniPripad Struktura Prvky Počty Struktura 1 obchodní případ ObchodniPripadID, NazevObchodnihoPripadu, NazevProjektu, Atributy: TypObchodnihoPripadu, Kontaktu Zdroje: MX Contact
~ 58 ~
Typ sloupce
Příloha č.2 Fyzické mapování faktových tabulek
Sloupec
Logický název
Tabulka:
FObchodPripadObrat
PlanSkutecnostId
Dimenze PlánSkutečnost
int
D
'OP'
ObchodPripadId
Obchodní případ ID
int
NULL
D
T01.mxSearchKey
AbsolutniLicence
Absolutní licence
money
Náklady na licence za OP a období
U
OLS.Licence
money
Obraty za OP a období
U
OLS.Obrat
U
OLS.Subdodavka
AbsolutniPrijem
Absolutní příjem
Datový typ
Fyzické mapování
Popis
AbsolutniSubdodavky
Aboslutní subdodávky
money
Náklady na subdodávky za OP a období
IDObchodnihoPripadu
ID obchodního případu
varchar(50)
NULL
G
ObdobiFakturaceId
Období fakturace
int
NULL
V
T01.mxSearchKey dbo.fw_FPosledniDatumMesice(c ast(OLS.Obdobi as varchar(6)) + '01')
Tabulka:
FObchodPripadPravdepodobnost
DivizeId
Divize
int
NULL
D
T01.mxBU
FazePripaduId
Fáze případu
int
NULL
D
T01.mxFazePripadu
IDObchodnihoPripadu
ID obchodního případu
varchar(50)
NULL
G
T01.mxSearchKey
ObchodPripadId
Obchodní případ ID
int
NULL
D
OborId
Obor
int
NULL
D
OdpovednaOsobaId
Odpovědná osoba
int
NULL
V
T01.mxSearchKey (select top 1 cmp.mxOborCinnosti from SA_MXC..Companies cmp where cmp.mxSearchKey = T01.mxPrimaryCompanySearchK ey) (select top 1 IdZdroje from DZdroj where (right(T01.mxPrimaryUser,len(T01 .mxPrimaryUser) - CHARINDEX(' ',T01.mxPrimaryUser, 0)) + ' ' + left(T01.mxPrimaryUser,CHARIN DEX(' ',T01.mxPrimaryUser, 0)1)) = Nazev)
Pravdepodobnost
Pravděpodobnost
money
NULL
U
PravdepodobnostId
Skupina pravděpodobnosti
int
Odkaz do dimenze DPravdepodobnost
D
T01.mxPravdepodobnost CASE WHEN T01.mxPravdepodobnost >= 0 and T01.mxPravdepodobnost < 80 THEN '0' WHEN T01.mxPravdepodobnost >= 80 and T01.mxPravdepodobnost < 100 THEN '80' WHEN T01.mxPravdepodobnost = 100 THEN '100' ELSE '#Neznámo' END
RozpracovanyId
RozpracovanyId
int
NULL
V
T01.mxRozpracovany
SektorId
Sektor
int
NULL
D
UvedeniDoProvozuId
UvedeniDoProvozuId
int
Očekávané uvedení do provozu
V
UzavreniSmlouvyId
UzavreniSmlouvyId
int
Očekávané uzavření smlouvy
V
ZahajeniProjektuId
ZahajeniProjektuId
int
Očekávané zahájení projektu
V
T01.mxSektor case when T01.mxOcekavaneUvedeniDoPro vozu = '45010101' then null else T01.mxOcekavaneUvedeniDoPro vozu end case when T01.mxOcekavaneUzavreniSmlou vy = '45010101' then null else T01.mxOcekavaneUzavreniSmlou vy end case when T01.mxOcekavaneZahajeniProjek tu = '45010101' then null else T01.mxOcekavaneZahajeniProjek tu end
~ 59 ~
ZakaznikId
Zákazník
int
NULL
D
(select top 1 mxAssociatedSearchKey from SA_MXC..[Associations_Opportu nities_to_Companies] ac where ac.mxAssociatingSearchKey=T01 .mxSearchKey and (ac.mxAssociatedSearchKey=T01 .mxPrimaryCompanySearchKey or T01.mxPrimaryCompanySearchK ey is null))
FakturovaneMesicePres KonecRoku
FakturovaneMesicePresKo necRoku
int
NULL
G
T01.MxFakturacePresRok
Tabulka:
FObchodPripadReseni
ObchodPripadId
Obchodní případ ID
int
NULL
D
T01.mxSearchKey
IDObchodnihoPripadu
ID obchodního případu
varchar(50)
NULL
G
T01.mxSearchKey
ReseniId
Typ řešení
int
NULL
D
OLS.Reseni
PodilReseni
Podíl řešení
numeric
NULL
U
OLS.Procento/100
Tabulka:
FPlanAQ
FPlanAQ
DatumId
Datum
int
Poslední datum kvartálu
D
T01.Datum
Kvartal
Kvartál
tinyint
Kvartál
G
T01.Kvartal
PlanPrijem
Plán
int
Plán příjem
U
T01.PlanPrijem
PlanSkutecnostId
Dimenze plán skutečnost
int
D
'RP'
Rok
Rok
int
Rok
G
T01.Rok
Tabulka:
FPlanDivize
DatumId
Datum
int
Poslední datum kvartálu
D
T01.Datum
DivizeId
Divize
int
Divize
D
T01.DivizeKlic
IdDivize
Kód divize
varchar(50)
Kód divize
G
T01.DivizeKlic
Kvartal
Kvartál
tinyint
Kvartál
G
T01.Kvartal
PlanPrijem
Plán
int
Plán příjem
U
T01.PlanPrijem
PlanSkutecnostId
Lookup do dimenze DPlanSkutecnost
int
D
'RPD'
Rok
Rok
int
Rok
G
T01.Rok
Tabulka:
FPlanObchodnik
ZdrojId
Obchodník
int
Obchodník (zdroj)
D
T01.ZdrojKlic
DatumId
Datum
int
Poslední datum kvartálu
D
T01.Datum
IdZdroje
Id Zdroje
int
Id zdroje podle primárních dat
G
T01.ZdrojKlic
Kvartal
Kvartál
tinyint
Kvartál
G
T01.Kvartal
PlanPrijem
Plán
int
Plán příjem
U
T01.PlanPrijem
PlanSkutecnostId
Dimenze PlánSkutečnost
int
D
'RPO'
Rok
Rok
int
Rok
G
T01.Rok
~ 60 ~
Příloha č. 3 Výsledek – sestava obchodní případy celkem za divize
~ 61 ~
~ 62 ~
~ 63 ~
