Business Intelligence a problematika datového skladu VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA MEZINÁRODNÍCH VZTAHŮ OBOR: MANAŽER OBCHODU

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA MEZINÁRODNÍCH VZTAHŮ OBOR: MANAŽER OBCHODU

Business Intelligence a problematika datového skladu

Autor: Pavlína Kopalová Vedoucí práce: Ing. Markéta Kubálková, Ph.D.

Prohlášení: Prohlašuji, že jsem bakalářskou práci Business Intelligence a problematika datového skladu vypracovala samostatně pod vedením Ing. Markéty Kubálkové Ph.D., uvedla jsem použité literární a jiné odborné zdroje, vyznačila všechny citace z pramenů. V Praze dne: 21. 5. 2014

1

Poděkování Ráda bych poděkovala vedoucí mé bakalářské práce Ing. Markétě Kubálkové Ph.D., za odborné rady, cenné a podnětné připomínky při vedení této bakalářské práce a za její velmi vstřícný přístup. Dále bych chtěla poděkovat finančnímu řediteli společnosti Nutricia, a.s. Vadimovi Ilovaiskisovi za umožnění realizace této bakalářské práce.

2

Abstrakt V mé bakalářské práci se zabývám relativně novou problematikou Business Intelligence. Zaměřuji se zejména na problematiku datových skladů. Na jejich tvorbu, údržbu a efektivitu. Zabývám se datovým skladem jako základním kamenem pro aplikace Business Intelligence (BI). V mé práci se zabývám tvorbou datového skladu, jeho efektivitou, jak jej vytvořit a udržovat. V praktické části popisuji a hodnotím budování datového skladu ve společnosti Nutricia, a.s. Tohoto projektu jsem se osobně účastnila a čerpám z poznatků z praxe. Popisuji a hodnotím zakládání datového skladu. V mé práci se zabývám možnými datovými zdroji. V závěru mé práce hodnotím celkovou efektivitu datového skladu a pokusila jsem se o několik pravidel, které je podle mého názoru dobré dodržovat, pokud datový sklad zakládáme.

3

Obsah 1

Úvod ................................................................................................................................................ 5

2

Pojem Business Intelligence (BI)..................................................................................................... 6 2.1

Definice BI – vymezení pojmu.................................................................................................. 6

2.2

Vývoj BI .................................................................................................................................... 7

2.3

Základní principy ...................................................................................................................... 8

3

Architektura, modelování datového skladu ..................................................................................... 9 3.1

Definice datového skladu ........................................................................................................ 9

3.2

Strategie datového skladu ....................................................................................................... 9

4

Architektura datového skladu a metody budování datového skladu.............................................. 10 4.1

5

Metody budování datového skladu ....................................................................................... 11

ETL (extract, transform, load) a kvalita dat ................................................................................... 12 5.1

Pořizování dat ........................................................................................................................ 13

5.2

Distribuce dat......................................................................................................................... 14

6

Dolování dat (data mining) ............................................................................................................ 14 6.1

Definice pojmu dolování dat .................................................................................................. 14

6.2

Oblasti použití dolování dat ................................................................................................... 15

6.3

Úlohy dolování dat ................................................................................................................. 15

7

Úvod praktické části....................................................................................................................... 17 7.1

Představení firmy ................................................................................................................... 17

7.2

Situace před vybudováním datového skladu......................................................................... 18

7.3

Rozhodnutí, výběr dodavatele a systému ............................................................................. 20

8

Úvodní analýza a stanovení cíle ..................................................................................................... 20

9

Budování datového skladu a datové zdroje................................................................................... 23 9.1

Exact ....................................................................................................................................... 23

9.2

Číselníky ................................................................................................................................. 24

9.3

Ostatní zdrojové soubory....................................................................................................... 25

10

Vrstva L1 .................................................................................................................................... 26

11

Vrstva L2 .................................................................................................................................... 29

12

Výstup z datového skladu .......................................................................................................... 31

13

Hodnocení .................................................................................................................................. 32

14

Poznatky..................................................................................................................................... 35

15

Pokračování................................................................................................................................ 36

16

Názory uživatelů a tvůrců BI ...................................................................................................... 37

17

Závěr .......................................................................................................................................... 39

4

1 Úvod V mé bakalářské práci se budu zabývat relativně novou problematikou Business Intelligence. Je to termín označující celou škálu činností, technologií a úloh. Já se zaměřím zejména na problematiku datových skladů. Na jejich tvorbu, údržbu a efektivitu. V mé práci si budu klást otázku, jak významný je datový sklad jako základní kámen Business Intelligence (BI). Dále budu zkoumat, jak co nejefektivněji datový sklad postavit, založit a udržovat, aby z něj firma mohla co nejvíce profitovat ve formě rychle dostupných informací. Toto nabízí otázku možnosti využití datového skladu a aplikace BI v řízení podniku nebo instituce. Cílem mé bakalářské práce je sestavit seznam doporučení a postupů pro případné nové uživatele. V bakalářské práci čerpám ze zkušeností z praxe, které jsem získala ve firmě Nutricia, a.s. při budování systému BI. Zároveň bych chtěla mé poznatky zasadit do širšího okruhu poznatků teoretických, které budu čerpat z odborné literatury a zdrojů dostupných na internetu. Toto téma jsem si zvolila, protože je zajímavé, práce na budování BI byla velmi přínosná a navíc příjemná. V současnosti zažíváme veliký rozvoj informačních technologií. Zároveň s dokonalejší technikou přichází i určitá informační přesycenost. Je nutné rozdělit informace podle důležitosti a vybrat informace, se kterými pracovat a se kterými ne. Informace jsou velmi cenným aktivem pro každou firmu a je v zájmu každé firmy naučit se s informacemi pracovat co nejefektivněji. K práci s informacemi patří také jejich skladování. Získávat informace ať už nákupem, nebo z vlastních zdrojů (např. účetní software) je pouze jedna část práce s informacemi. Stejně tak důležité je jejich skladování a mít informace k dispozici ve správný čas, ve správném porovnání nebo ke správné analýze. Při skladování informací bychom si měli uvědomit a definovat, v jakém formátu budou skladovány, jaká bude jejich struktura, k čemu je budu potřebovat a jestli mám potřebný hardware pro skladování informací. Tato problematika mne velmi zajímá, ve své praxi jsem se několikrát věnovala činnostem souvisejících se zpracováním dat. Od této práce očekávám, že své praktické poznatky uspořádám do přehledného celku, chápu tuto práci jako formu osobního rozvoje v oblasti, která je mi blízká. Zpracování a uchovávání informací přímo vede k problematice datových skladů, kterým bych chtěla věnovat většinu mé práce. Datový sklad je základním kamenem celého systému BI a je důležité mu věnovat pozornost. Pokud je v pořádku datový sklad a tím pádem zdroj „jediné pravdy“, systém BI je již jen nadstavba. I životnost datového skladu vnímám jako delší než systém BI. Formu zpracování dat může společnost měnit podle konkrétních požadavků reflektujících momentální požadavky, nebo 5

podmínky. Vždy je ale potřeba pracovat s daty, které jsou pokud možno v pořádku, ve správném formátu a správné struktuře. V literatuře jsem našla několik způsobů tvorby datového skladu. Ráda bych se na ně v mé práci zaměřila. V druhé části mé práce se budu věnovat budování datového skladu ve firmě Nutrica, a.s. se zaměřením pouze na Českou republiku. Zhodnotím na základě teoretických poznatků, zda budování datového skladu v této firmě probíhalo správně, co by se dalo zlepšit, udělat jinak, nebo co naopak funguje velmi dobře.

2 Pojem Business Intelligence (BI) 2.1 Definice BI – vymezení pojmu BI není zrovna český název, ale pojem BI jako takový se již vžil a je běžně používán. Vymezení tohoto nového pojmu není jednoduché, každá firma by asi tento pojem vnímala jinak. Pro některou z firem může být BI soubor navzájem propojených tabulek aplikace Microsoft Excel a to v lepším případě, pro jiný sofistikovaný systém práce s informacemi od jejich skladování, použití až po ošetření přístupů a školení zaměstnanců. Co tedy říká odborná literatura? „Business intelligence je termín označující celý komplex činností, úloh a technologii, které dnes stále častěji tvoří běžnou součást řízení podniků a jejich informačních systémů.“1 „Business intelligence je zastřešující termín, který se vztahuje ke znalostem, procesům, technologiím, aplikacím a postupům, které usnadňují podnikové rozhodování. Technologie Business intelligence pracuje s použitými (historickými) daty v požadovaném kontextu a pomáhá přijímat podniková rozhodnutí pro budoucnost.“2 „Business intelligence (BI) jsou dovednosti, znalosti, technologie, aplikace, kvalita, rizika, bezpečnostní otázky a postupy používané v podnikání pro získání lepšího pochopení chování na trhu a obchodních souvislostech. Za tímto účelem provádí sběr, integraci, analýzu, interpretaci a

1

NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, 1.vydání. Praha: Grada Publishing, a.s., 2005. 254 s. ISBN 978-80-247-6685-0. S. 13 2 LABERGE, Robert. Datové sklady, Agilní metody a business intelligence, 1.vydání. Brno: Computer Press, a.s., 2012. 350 s. ISBN 978-80-251-3729-1. S. 24

6

prezentaci obchodních informací. Mohou zahrnovat samotné shromážděné informace nebo explicitní znalosti získané z informací.“3 Z uvedených vymezení pojmu vyplývá, že chápání BI v odborné literatuře je celkem jednotné a dá se chápat jako soubor aktivit, nehmotných prostředků, ale i zcela materiálního technického vybavení společnosti. Tento soubor všech aspektů pak podporuje rozhodování pro budoucnost, sledování současnosti a vyhodnocování minulosti. Mně osobně se líbí definice BI jako přerod dat na informace. „Proces transformace dat na informace a převod těchto informací na poznatky prostřednictvím objevování nazýváme Business Intelligence.“4 Tato definice je velmi jednoduchá ale i velmi výstižná. BI nezajišťuje nic jiného než přerod dat v užitečné informace. Tato definice svým způsobem opět poukazuje na důležitost budování datového skladu. Pokud nemáme data, nezískáme z nich informace. Aby celý systém fungoval a informace byly kvalitní a odrážely pravdu, je potřeba věnovat velkou pozornost právě přípravě datového skladu.

2.2 Vývoj BI „Řešení směřující k podpoře manažerských a analytických úloh v podnikovém řízení se začala objevovat již na konci sedmdesátých let minulého století v souvislosti s rozvojem on-line zpracování dat. Prvotní pokusy a aplikace jsou spojeny s americkou firmou Lockheed. V polovině osmdesátých let byly publikovány první významné práce k tomuto typu aplikací (prof. Rockart: „CEO Goes on-line“ a některé další). V druhé polovině osmdesátých let přišly na trh v USA první firmy s komerčními produkty, založenými na multidimenzionálním uložení a zpracování dat, označovaných jako EIS (Executive Information System), a to firmy Comshare a Pilot. Trh s EIS produkty se pak velmi rychle rozvíjel a na začátku devadesátých let (od roku 1993) se tyto produkty začaly prosazovat i na českém IS/ICT trhu.“5 „Termín Business Intelligence zavedl v roce 1989 Howard J.Dresner, analytik společnosti Gartner Group, který jej popsal jako „sadu konceptů a metod určených pro zkvalitnění rozhodnutí firmy“.

3

Wikipedia [online]. [vid. 19.4.2014]. Dostupné z: http://cs.wikipedia.org/wiki/Business_Intelligence LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, 1.vydání. Brno: Computer Press, a.s., 2009. 456 s. ISBN 978-80-251-2887-9. S. 14 5 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 17 4

7

Vyzdvihuje zde význam datové analýzy, reportingu a dotazovacích nástrojů, které provádějí uživatele množstvím dat a pomáhají mu se syntézou hodnotných a užitečných informací.“6 Howard Dresner pracoval v Gartner Group třináct let. Působil také v Hyperion Solution a v roce 2007 zformoval Dresner Advisory Services.

2.3 Základní principy Systémy BI pracují se dvěma typy informací. Informativními a analytickými. Informativní informace se také často označují jako operativní. Operativní informace vznikají „za pochodu“ odráží realitu v podniku. V čase se často mění. Příkladem operativní informace může být například zaúčtování příchozí faktury, resp. její řádek, nebo třeba přijetí objednávky na koupi našeho zboží. Tato data jsou většinou uložena v nějakém typu relační databáze. Transakční systémy pak pracují s operativními informacemi a zpracovávají je v čase. Analytické systémy mají své charakteristiky, do kterých patří práce s operativními (primárními) daty, různé úrovně agregace, faktor času a jako hlavní multidimenzionalita, která v sobě vlastně všechny charakteristiky odráží. Bez multidimenzionálního vymezení by například agregace nebyly možné. Multidimenzionalitu v databázi potřebujeme proto, abychom se na data mohli podívat z různých úhlů pohledů současně. Vytváří také souvislosti mezi daty, které primárně z původních dat nemusí vyplývat (nejsou jasné). „Základním

principem,

na

němž

jsou

aplikace

Business

Intelligence

založeny,

je

několikadimenzionální tabulka umožňující velmi rychle a pružně měnit jednotlivé dimenze, a nabízet tak uživateli různé pohledy na modelovanou ekonomickou realitu. Jde tak v podstatě o princip „ndimenzionální Rubikovy kostky“ naplněné nejdůležitějšími podnikovými daty.“7 Důležitými dimenzemi pak jsou ukazatele a čas. Ukazately myslím ekonomické proměnné. Dimenze si může každá společnost definovat sama, většinou svým způsobem již s dimenzemi pracuje, jen pro účely BI je nutné je definovat. Dalšími dimenzemi rozumíme například hospodářské středisko, zákazník, nebo produkt. Vše je většinou uspořádáno v hierarchické struktuře, jinými slovy uspořádáno do skupin a podskupin. Díky tomu je možná agregace dat a nahlížení na data v různých úrovních detailu.

6 7

NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 18 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 22

8

3 Architektura, modelování datového skladu 3.1 Definice datového skladu „Datový sklad je podnikově strukturovaný depozitář subjektové orientovaných, integrovaných, časově proměnných, historických dat použitých pro získávání informací a podporu rozhodování. V datovém skladu jsou uložena atomická a sumární data.“8 „Datový sklad (data warehouse) je systém, který umožňuje shromažďovat, organizovat, uchovávat a sdílet historická data. Zahrnuje „použitá“ data pocházející z provozních systémů, které data zachytávají a používají v kontextu své funkce.“9 V mém chápaní je datový sklad skutečně v jistém smyslu depozitářem. Zda má dle první definice obsahovat i sumární data bych rozporovala. Primárně v datovém skladu není potřeba dle mého názoru agregovat, ale nevylučuji to. V definici bych tento obrat ale nepoužila. Více tedy souhlasím s druhou definicí. Sama bych definovala datový sklad takto: Datový sklad je systém ukládání a uchovávání dat, které jsou organizovány do hierarchických struktur se zachováním kontextu.

3.2 Strategie datového skladu Zatímco strategie BI je založena na poskytování výsledků podnikovým uživatelům, strategie datového skladu spočívá ve vytvoření struktury, hierarchie a organizace dat. V mnohých společnostech toto vyžaduje zavedení procesů pro správu a tvorbu dat. Datový sklad je soubor uspořádaných dat z různých zdrojů. Právě různé zdroje jsou někdy problémem v konsolidaci dat. Data je potřeba sjednotit a jednat vždy podle předem stanovených pravidel. Pokud například všechny výrobky patří do nějaké skupiny výrobků, pak všechny výrobky musí tuto informaci obsahovat. Jakmile připustíme, aby některé výrobky měli definovanou skupinu a jiné ne, jen těžko se bude s těmito daty dále pracovat. Se strategií datového skladu souvisí otázka, proč datový sklad vzniká? Tuto otázku je nutné si položit právě při tvorbě datového skladu. Při tvorbě datového skladu by měl být jasný účel. Ten by měl být aktuální a realistický. Většinou vzniká z potřeby jistého sjednocení dat a vytvoření jediného zdroje, nebo jediného zdroje pravdy. Pokud podnik používá například pouze soustavu několika tabulek

8 9

LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 38 LABERGE, Robert. Datové sklady, Agilní metody a business intelligence, s. 35

9

aplikace Microsoft Excel, stačí pouze chyba ve vzorci, nebo překlep majitele souboru a již máme na světě dva soubory s odlišnými výsledky. Datový sklad by měl toto eliminovat a být zdrojem správných dat. V současné době existuje mnoho efektivních možností, jak zpracovávat, nebo uchovávat data. I zde ale hraje roli lidský faktor a rozhodování. Jak nejlépe zvolit strategii datového skladu? V první řadě by měl manažer, který strategii určuje, zmapovat současný stav. Pokud zakládáme datový sklad, očekáváme jisté zlepšení ve správě dat, ale toto nemůžeme později posoudit, pokud jsme neznali výchozí stav. Také ne všechny procesy v podniku musí být nutně změněné nebo předělané. Každý podnik již nějak funguje a data spravuje a je dobré začít s těmito poznatky. Pokud je například ve firmě již funkční proces zakládání nového výrobku, není nutné ho měnit, jen se změní prostředí, do kterého budou informace vkládány. Pokud si manažeři podniku vyjasní otázku účelu datového skladu, pak je potřeba definovat projektový tým, který datový sklad bude zakládat. Firmy většinou využívají dodavatelské firmy. Do projektového týmu by tedy v případě, že tomu tak je, měl patřit někdo z dodavatelské firmy a poté zástupci těch oddělení, které budou data spravovat a zpracovávat. V běžném typu podniku si dokážu představit, že členy projektového týmu bude určitě někdo z oddělení financí, tedy controllingu, účtárny a někdo z oddělení, které má na starosti distribuci, sklady, atd. Většinou to bývá oddělení logistiky.

4 Architektura datového skladu a metody budování datového skladu „Datová architektura se obvykle odvozuje od dat, která podnik potřebuje. Cílem je omezit rozsah celého projektu.“10 „Datovou architekturu si také můžeme představit jako návrh celkového plánu datového skladu z hlediska dat. Datový sklad má mnoho aspektů a lze jej budovat různými způsoby. Každý z nich má přitom určité důsledky.“11 Architektura datového skladu je velmi důležitá a v čase se velké změny dělají těžko. Stojí většinou mnoho energie a času.

10

LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 70 11 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 71

10

Abychom mohli správně zvolit architekturu, je nutné si předem definovat cíl, požadavky a očekávání. Pokud se rozhodneme postavit si dům, také máme představu o tom, jak by měl vypadat, jak by měl být velký, kolik to bude stát peněz, jak dlouho to bude trvat. Teprve potom zadáme architektům nakreslit plány a teprve potom dům stavíme – většinou po důkladném výběru dodavatelské firmy. Datový sklad je většinou formou centralizace dat a to v kontextu. A právě kontext je velmi důležitým aspektem. Pokud data pocházejí z různých systémů, je nutné nejprve zajistit jejich integritu, stejný kontext, popřípadě úplně změnit zadávání některých dat. Při budování architektury datového skladu bychom si měli také položit otázku, jaká data budeme zpracovávat a v jakém množství. Pokud se například rozhodneme zpracovávat data z účetního softwaru. Dále je třeba se rozhodnout, zda všechny, nebo jen některé. Budeme zpracovávat data pro výkaz zisků a ztrát, tedy zjednodušeně účty v rozmezí 5xxxxx – 6xxxxx, nebo potřebujeme informaci i o změnách v rozvaze? Nebo chceme jen informace o prodejích? V rozhodování je potřeba přihlédnout k plánům do budoucna. To, že některé informace nezpracováváme nyní, neznamená, že s nimi nemůžeme pracovat v budoucnosti. Pro vybudování datového skladu je nutné definovat současné datové zdroje, odkud data pocházejí a kdo data spravuje. Je dobré vymezit duplicity a vymezit pouze jeden datový zdroj.

4.1 Metody budování datového skladu Pro budování datového skladu bychom měli zvolit správnou metodu. Chtěla bych zde popsat čtyři metody budování datového skladu, které nabízí kniha Business Intelligence v SQL serveru 2008.

Metoda „velkého třesku“ – jedná se o metodu, kdy datový sklad je vytvořen jediným projektem. Skládá se z analýzy požadavků podniku, vytvoření podnikového datového skladu a vytvoření přístupu buď přímo, nebo přes datové trhy. Výhodou této metody je skutečnost, že celý projekt lze kompletně vypracovat ještě před začátkem jeho realizace. Je to také výhodou jedinou. Nevýhodou je dynamika tvorby datového skladu. Je téměř jisté, že v průběhu procesu se požadavky změní. Tento proces také vyžaduje většinou větší investice a trvá dlouho.

11

Přírůstková metoda – tato metoda předpokládá budování datového skladu po jednotlivých etapách. Jednotlivé „přírůstky“ musí samozřejmě zapadat do celkové architektury datového skladu. Když se částečné řešení důkladně otestuje koncovými uživateli a je funkční, může se do systému přidat další oblast. „Začneme tedy budováním několika málo předmětných oblastí, typicky jednou, nebo dvěma. Toto částečné řešení implementujeme například jako škálovatelný datový trh a poskytneme ho koncovým uživatelům.“12 Výhodou této metody je možnost implementace rozšiřitelné architektury, což oceníme zejména v časové souvislosti. Jak již bylo řečeno, v čase se požadavky mění a tato metoda je flexibilní. Podle mého názoru také řešíme menší okruh dat v čase. Dle mého názoru může být nevýhodou špatná definice na počátku budování datového skladu. Přírůstková metoda se dále člení na přírůstkovou metodu směrem „shora dolů“ a „zdola nahoru“. Přírůstková metoda „shora dolů“ – je nejdříve vytvořen model a koncept datového skladu. Důležitou roli hraje hierarchie předmětných oblastí. Přírůstková metoda „zdola nahoru“ – tato metoda je velmi podobná té „shora dolů“, ale prioritu mají data před obchodním ziskem. Nevýhodou tohoto modelu může být jistá nepružnost v rozšiřování modelu. Je to zapříčiněno tím, že model se odvíjí od zdrojových systémů.

5 ETL (extract, transform, load) a kvalita dat „Procesy integračních služeb mohou být navrženy pro jednorázovou akci, nebo naopak pro akce periodicky se opakující. Jednorázovou akcí může být například migrace dat z jedné databázové platformy do jiné, nebo přenos dat ze souborů dokumentů kancelářských balíků do cílových databází. U periodicky se opakujících úloh, například při každodenním zavádění dat z produkčních databází do datového skladu, je důležité, aby tyto operace proběhly v požadovaném čase.“13 Datový sklad je systém, který má svůj vstup, zpracování a výstup. Zde bych se chtěla zaměřit na vstup a zpracování. Proces ETL v sobě obsahuje jak pořizování dat, tak uchovávání dat.

12

LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 44 13 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 75

12

Data a zejména správná data ve správném kontextu jsou velmi cenným aktivem každé firmy. Pokud budou data nesprávná, ve špatném kontextu, pak hrozí riziko i nesprávného rozhodování ze strany managementu. Benefity BI nemůžeme využívat, pokud bude proces ETL a kvalita dat podceněna. Důležité je také data udržovat a pravidelně kontrolovat.

5.1 Pořizování dat Pořizování dat většinou probíhá z různých datových zdrojů a je potřeba je unifikovat, dát do kontextu a hierarchie. Jedním velkým zdrojem dat je většinou účetní software. V účetnictví nalezneme data různého typu, svým způsobem uložená v relační databázi. Chybí další hierarchie. Pokud například v účetnictví máme záznam o prodeji výrobku na určitého zákazníka v určitém čase, je potřeba tato data dále zpracovat pomocí hierarchie, kterou v účetním softwaru většinou nenalezneme. Pokud hovoříme o zákazníkovi, v účetnictví většinou nebývá další členění, například do jakého prodejního kanálu daný zákazník patří. U výrobků je v účetnictví hierarchie výrobků většinou omezená, nebo slouží k jinému účelu, než k jakému je potřebujeme. V datovém skladu tedy musíme zajistit, že všechny tyto údaje budou v širším kontextu. U časových údajů je třeba zajistit následnou agregaci například po čtvrtletích, pololetích, nebo jiných časových úsecích. Při pořizování dat je také potřeba sjednotit formát a zajistit referenční integritu. Pokud máme definované datové zdroje a zajistily jsme jejich konzistentnost a rozumíme jejich kontextu, nastává fáze nahrání dat do datového skladu. Toto by mělo být zároveň doprovázeno kontrolou. „Důležité je ověření dat. Když nejsou data ověřená, může dojít k problémům při extrakci a transformaci. Podle závažnosti selhání je nezbytné potom začít znovu, nebo postačí pokračovat od místa selhání. Nepřesná, nebo neúplná data mohou být příčinou nepřesnosti výsledků analýzy, což může následně vést k nesprávným obchodním, nebo ještě hůř strategickým rozhodnutím.“14

14

LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 81

13

5.2 Distribuce dat Distribuce dat je součástí procesu ETL. „Zahrnuje načítání dat z oblasti organizace dat a jejich distribuci do prostředí různých datových trhů.“15 Data se zde převádějí do konkrétních formátů (pokud možno konzistentních).

6 Dolování dat (data mining) Po vybudování datového skladu je potřeba s daty pracovat a k tomu slouží proces dolování dat. Pro tento proces se vžil pojem data mining. „Databáze v dnešní informatické společnosti skrývají nesmírné informační bohatství, problémem však je, jak ho odkrýt, nebo expresivněji řečeno vydolovat. Databázové tabulky obsahují miliony až miliardy záznamů, které jsou různě uspořádané a členěné. Problémem je zahlcení informacemi a porozumění informační hodnotě velkého množství dat,“16 Proto bych chtěla věnovat i část mé bakalářské práce této problematice. Práce s daty je důležitou součástí budování BI. Je nutné datům porozumět a tím pádem správně data „dolovat“.

6.1 Definice pojmu dolování dat „Dolování dat lze charakterizovat jako proces extrakce relevantních předem neznámých nebo nedefinovaných informací z velmi rozsáhlých databází.“17 „Data mining je proces analýzy dat z různých perspektiv a jejich přeměna na užitečné informace. Z matematického a statistického hlediska jde o hledání korelací, tedy vzájemných vztahů nebo vzorů v datech. Data mining je proces, jehož cílem je těžba informací v databázích. Využívá statistické metody a další metody hraničící s oblastí umělé inteligence.“18 Podle mého názoru je první definice přesnější. Lépe vystihuje, jak data mining chápu já. Je to proces extrakce. U druhé definice bych nesouhlasila s hledáním korelací. Korelace nám mají být známy již při tvorbě datového skladu a v procesu data miningu je potřeba tyto korelace nadefinovat. 15

LABERGE, Robert. Datové sklady, Agilní metody a business intelligence, s. 228 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 264 17 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 205 18 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 265 16

14

6.2 Oblasti použití dolování dat “Mnoho podniků v současné době spravuje rozsáhlé informační databáze a datové sklady. Reálná data v nich uložená představují obrovský potenciál použitelný pro řízení podniku ve všech jeho oblastech. Cílem dolování dat je tato data automaticky, či poloautomaticky analyzovat a nalézt v nich („vytěžit“ z nich) důležité informace o vzájemných závislostech mezi vývojem hodnot určitých ukazatelů nebo o strukturách chování (např. nákupní preference zákazníků).“19 Oblastí použití data miningu je zejména v podnicích, které již mají datový sklad a potřebují extrahovat informaci. V ideálním případě by byl datový sklad již funkční se správnými daty. Já bych oblast data miningu rozšířila i do podniků, které datový sklad nevlastní. V takových případech je potřeba data získat právě z primárních zdrojů, které by jinak zpracovávala technologie datového skladu. Tento data mining je možná ještě složitější než případ zmíněný dříve. V tomto případě je potřeba se v datech vyznat a vědět, který datový zdroj použít. Použití data miningu je relevantní ve všech odděleních společnosti. Může se jednat o data pro finanční analýzu, nebo data relevantní pro marketing ve smyslu analýzy trhu. „Pomocí data miningu můžeme principiálně studovat, pochopit a pravděpodobně i vylepšit prakticky jakýkoliv proces ve vzájemně velmi odlišných oblastech, jako je například řízení procesu výroby, lidské zdroje, analýza lékařských vzorků, analýza signálů, prostě všude tam, kde je možné shromažďovat data z procesů.“20

6.3 Úlohy dolování dat „Data mining je prostředek pro získávání informací pro podporu rozhodování. Samotné rozhodování musí udělat příslušný zodpovědný pracovník.“21 Z této definice vyplývá, že úlohou data miningu je získávání a zpracování relevantních dat. Práce s daty ale ovlivňuje lidský faktor a to, jak s daty naložíme je v rozhodovací kompetenci většinou manažerů podniku.

19

NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 205 20 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 265 21 LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, s. 267

15

Kniha Business Intelligence jak využít bohatství ve vašich datech uvádí pět úloh dolování dat. „Explorační analýzy dat – podstatou je prozkoumat data bez předcházející znalosti, která by určitým způsobem naše hledání usměrňovala. Využívají se zde různé grafické metody či speciální techniky.“22 Využít tuto úlohu dolování dat lze především v neznámém prostředí. Například pokud chceme udělat analýzu v nám neznámém prostředí. V praxi by se tato analýza mohla použít například k analýze trhu, na který chceme vstoupit. „Deskriptivní úlohy – podstatou je určitým způsobem popsat celou datovou množinu. Z hlediska dolování dat je například takovou metodou shlukování, při kterém dochází k vytvoření skupin, do kterých se dají projevy v datech rozdělit.“23 Tato úloha by se dala v praxi využít například ve zkoumání sezónnosti výrobků. Daly by se vytvořit skupiny v určitých časových obdobích v roce v členění po měsících. Kritériem pro výběr by pak byla výše prodejů a jejich odchylka od průměru, nebo jiné předem stanovené hodnoty. „Prediktivní úlohy – cílem je předpovědět hodnotu určité veličiny na základě znalosti hodnot ostatních veličin. Z hlediska statistiky je takovou metodou regresní analýza. Predikci v dolování dat provádíme zejména klasifikací příkladů do tříd.“24 Konkrétní využití této úlohy by mohlo být například ve výrobním podniku při plánování výroby. „Hledání vzorců a pravidel (hledání nuggetů) – podstatou je hledání určitých vztahů a vzorů chování v datech. Klasickou úlohou je zde analýza nákupního košíku, která má rozkrýt, které druhy zboží jsou zákazníky kupovány současně. Dalším takovým příkladem může být úloha z oblasti bankovnictví, spočívající v detekci vzorů implikujících provádění operací praní špinavých peněz. Hledání podle vzorů – před prováděním hledání znalostí podle vzorů má analytik k dispozici určitý vzor, a cílem je nalézt v datech vzory, shodující se nebo podobné s touto předlohou. Jedná se tedy o rozpoznávání vzorů v datech na základě předem definované šablony.“25

22

NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 205 23 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 205 24 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 205 25 NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, s. 206

16

7 Úvod praktické části Pracuji ve firmě Nutricia, a.s., momentálně v divizi Advanced Medical Nutrition. V letech 2007 – 2013 jsem pracovala v divizi Early Life Nutrition a v této době jsme implementovali systém BI. S tím samozřejmě souviselo vybudování datového skladu. Datový sklad jsme začaly budovat v roce 2010. Protože před tím podobný systém v této společnosti neexistoval, vybudování datového skladu a identifikace všech datových zdrojů trvala téměř půl roku.

7.1 Představení společnosti Firma Nutricia, a.s. je na českém trhu od roku 1995. Je tvořena dvěma divizemi – divizí kojenecké a dětské výživy a divizí klinické výživy. Divize Advanced Medical Nutrition se specializuje na enterální klinickou výživu a výrobky pro pacienty s metabolickými poruchami. Tyto se dělí do několika skupin: •

Enterální klinická výživa určená k popíjení – tu reprezentuje na trhu značka Nutridrink. Nutridrink je krátkodobou plnohodnotnou náhradou stravy. Podává se při nechutenství, nebo pokud má pacient speciální nároky na výživu. Nechutenství se může vyskytnout například při léčbě onkologických onemocnění, nebo ve stáří. Nutridrink je na trhu v mnoha příchutích a variantách. Na trhu je varianta MultiFibre s vyšším obsahem vlákniny, Diasip pro diabetiky a například Cubitan pro zmírnění dekubitů. Dále je na trhu Nutridrink Protein, který pomáhá při pooperační léčbě.

•

Enterální klinická výživa určená k podávání sondou, reprezentovaná značkou Nutrison. Nutrison je vak s výživou, opět vyráběný v několika mutacích podle potřeb pacienta. Je podáván v případě, že pacient má z nějakého důvodu nefunkční část trávicího traktu.

•

Přípravky speciální dietetické výživy, určené pro pacienty vyžadující speciální dietu. Zejména pacienty s potravinovými alergiemi a metabolickými vadami, nejčastěji fenylketonurií. Tyto metabolické poruchy se většinou týkají trávení bílkovin a tuků, některé bílkoviny jsou v této stravě nahrazovány aminokyselinami.

•

Pediatrika, kam patří výrobek Neocate – kojenecké a pokračovací mléko pro děti s velkým rizikem alergií, Nutrini – sondová výživa pro děti a Nutrinidrink (v budoucnu Fortini) – Nutridrink určený pro děti do dvanácti let.

17

Divize Early Life Nutrition se zaměřuje na produkty určené pro děti od narození do batolecího věku. Výrobky této divize jsou reprezentovány značkami Nutrilon a Hami. A opět několika skupinami: •

Kojenecká a pokračovací mléka - kojenecká mléka Nutrilon jsou nejčastější první volbou mezi maminkami a doporučuje je nejvíce pediatrů. Dlouhodobě si drží prvenství v tržním podílu na českém trhu. Nutrilon mléka disponují řadou pro speciální výživové potřeby kojenců a batolat. Je to například mléko HA, kde dochází k hydrolýze bílkoviny kravského mléka a ta je štěpena na aminokyseliny. Alergie na bílkovinu kravského mléka se stává stále častějším problémem u malých dětí. Druhou značkou v mlécích je Hami. Hami prošlo nedávno několika inovacemi a stává se také oblíbenou volbou.

•

Kaše - Ty jsou zastoupeny oběma značkami. Jsou k dispozici mléčné i nemléčné kaše v mnoha příchutích a variantách, například kaše na dobrou noc s větším obsahem rýžové složky, která je sytivější.

•

Skleničky. Ty se dále rozpadají na několik dílčích produktových skupin, jako jsou masozeleninové příkrmy, ovocné příkrmy a sytivé svačinky (s obsahem jogurtu nebo jinou složkou než jen ovoce). Tyto výrobky jsou k dispozici v různých gramážích s různým věkovým určením.

•

Ovocné příkrmy a jogurtové svačinky v plastových kelímcích a sušenky, reprezentované Safari sušenkami a Meďánky, nebo Hami 100% ovoce.

V roce 2009/10 se Nutricia, a.s. zúčastnila soutěže o nejlepšího zaměstnavatele roku v kategorii malých a středních podniků. Tuto soutěž vyhrála. Mohu pouze potvrdit unikátní firemní kulturu, která je možná trochu způsobená i výrobky a jejich určením.

7.2 Situace před vybudováním datového skladu Před vybudováním datového skladu byla data uchovávána systematicky především v účetním softwaru. To byl také jediný systém využívající databázové propojení tabulek. Ostatní informace, které v účetním softwaru nebyly, představovalo především několik tabulek aplikace Microsoft Excel, spravované různými lidmi. Toto mělo samozřejmě za následek několik různých výsledků a „několik pravd“. A proto se stávalo, že mnoho času zabralo jen dopátrávání se správného výsledku. Většinou to spočívalo v revizi Excelů a v kontrole výpočtu. Jako příklad bych uvedla data, která zařazují produkty do výrobkových skupin různého stupně. V oddělení logistiky měli jiný náhled na třídění do produktových skupin než v oddělení controllingu. Zatímco controlling zařazoval výrobky do produktových skupin na základě požadavků marketingu (i globálního), logistika řadila výrobky do skupin podle toho, jak je zařazovaly výrobní závody.

18

Dalším softwarem, který fungoval a funguje dodnes a dá se označit za strukturovaný, je globální reportovací systém BPC (Business Planning Consolidation). Do tohoto systému vkládáme měsíční výsledky, což obsahuje finanční výkazy zisku a ztrát, rozvahu a cash flow, dále několik menších reportů obsahující výsledky ve větším detailu, například výsledky po produktových skupinách, zákaznících, nebo zůstatek na skladě po výrobních závodech. Třikrát ročně vkládáme plán – v srpnu plán na příští rok, v březnu revidovaný plán pro zbytek roku a v srpnu znovu revidovaný plán pro poslední čtvrtletí aktuálního roku. Každý měsíc se také vkládá velmi zjednodušený plán po čtvrtletích do konce roku spolu s následujícím měsícem ve větším detailu. Data reflektují v aktuálních obdobích skutečnost a tento systém se dá používat i pro datový export, ne jen pro import. Jednodušší reporty, které kopírovaly pouze takový detail, který obsahuje BPC se tedy daly „vyrábět“ z BPC. Zároveň zdroje pro importování dat plánů byly dále použity při tvorbě datového skladu. Tato situace vedla v roce 2010 k rozhodnutí vybudovat datový sklad. Jak jsem již zmínila, jediným strukturovaným interním systémem ve společnosti byl účetní software. Nutricia používá Exact a ten pracuje s add-iny určenými pro Excel. Toto znamená, dvě možnosti, jak systematicky a s propojením vydolovat data ze systému do Excelu. Dá se využít buď speciální databázová funkce, která vrátí podle parametrů hodnotu do jedné buňky. Pro ilustraci je to například funkce, kam zadám parametr číslo účtu, hodnotu období (1-12), vyberu, zda chci hodnoty kumulovaně či za období, zda chci saldo, nebo obrat na straně dal, nebo na straně má dáti, nebo v případě rozvahových účtů zůstatek a některé jiné parametry a funkce vrátí hodnotu. Takto vytvořený report je funkční, ale velmi objemný a trvá dlouho, než se přepočítá. Musí se proto otvírat jen v Excelu s volbou manuální rekalkulace, jinak je nemožné s ním pracovat. Ačkoliv to tak nevypadá, i takový report může najít své uplatnění a jeden soubor reportů tohoto typu stále existuje. Další možností add-inu je do první buňky reportu vložit query a výsledkem je seznam odpovídající query v zadání. Pokud je potřeba pracovat s proměnnými (například datum, číslo zápisu, nebo číslo účtu), je možné je zadat do Excelu s reportem a v query se na tyto buňky odkazovat. Aktualizovat takto vytvořený report není složité a netrvá dlouho. Ovšem seznam se musí dále zpracovávat. S reportem ve stylu seznamu (tabulky), by 99% uživatelů, interních zákazníků, nechtělo pracovat. Pro tvorbu těchto reportů je ale potřeba nejdříve vytvořit query. Exact umožňuje si query vykopírovat ze soustavy a výsledkem je pak ona soustava, ale pro účely controllingu a reportingu toto nestačilo. Bylo třeba query upravovat. Díky tomuto jsem poznala strukturu Exactu a jeho provázanost. Tato znalost spolu se znalostí firemního prostředí a datových zdrojů mě posunula to týmu pro vytváření datového skladu.

19

7.3 Rozhodnutí, výběr dodavatele a systému Rozhodnutí vybudovat datový sklad inicioval tehdejší finanční ředitel a předložil návrh top managementu firmy. Návrh na vybudování systému BI a tedy nejdříve vybudování datového skladu byl schválen. Na tomto projektu jsem se aktivně podílela, v té době jsem pracovala v divizi Early Life Nutrition jako controller. Ve firmě jsem v tu dobu byla již tři roky a byla jsem obeznámena s datovou strukturou a datovými zdroji ve společnosti. Následovalo několik prezentací firem, které jsme oslovily a byl vybrán systém Cognos a společnost, která tvorbu datového skladu a implementaci BI dodavatelsky zajišťovala. Po určení systému a dodavatele následovala úvodní analýza a stanovení cíle.

8 Úvodní analýza a stanovení cíle V této kapitole začnu stanovením cíle. Před vybudováním BI se společnost potýkala s problémem identifikace ziskovosti u jednotlivých výrobků u určitých zákazníků. Samozřejmě nějaké povědomí existovalo, ale detailní výpočty nebylo možné v Excelu vytvořit. Z dostupných reportů se dala odvodit informace o prodejním kanále, nebo zákazníkovi, ale už ne o produktech na daném zákazníkovi. A opačně, dala se vystopovat ziskovost jednotlivých produktů, nebo produktových skupin, ale u konkrétního zákazníka to již byl problém. Tyto reporty byly většinou tvořeny ad-hoc na základě momentálních požadavků a neexistoval žádný ucelený systém pro získávání těchto informací. Jednou měsíčně se aktualizovaly tzv. zákaznické soubory obsahující prodeje po výrobcích po zákaznících, ale tato informace přicházela zpožděně, za minulý měsíc v polovině následujícího měsíce a informace nebyly kompletní. Chyběly tedy podklady pro rozhodování o strategii, jaký produkt nebo jakou produktovou skupinu upřednostnit na jakém zákazníkovi, nebo kam směřovat jaké marketingové aktivity. Informace tohoto typu také potřebovalo prodejní oddělení pro řízení slev a jejich správné cílení. Cíl byl tedy stanoven jako možnost pomocí BI stanovit ziskovost jakéhokoliv produktu na jakémkoliv zákazníkovi. Ziskovost počítaná z výsledku před úroky a daní, tedy EBIT. Úvodní analýza měla za úkol zmapovat situaci se zdroji a případně upozornit na nedostatky v datech, abychom mohli vytvořit BI, které poskytne informace v takovém detailu, jak bylo stanoveno v cíli. V úvodní analýze se dodavatelská firma seznamovala s datovým prostředím společnosti. Nadefinovali jsme společně datové zdroje a jejich zpracování. Protože cíl se týkal pouze hodnot, které souvisejí s výkazem zisků a ztrát, samozřejmě ve velkém detailu, jedním z vymezení byl například interval účtů od 500000 do 699999. O datových zdrojích a jejich vymezení budu dále hovořit v dalších kapitolách. 20

Dále úvodní analýza obsahovala systém výpočtů pro různé pozice výkazu zisků a ztrát. Zejména pro fixní náklady. Pro mě bylo v úvodní analýze důležité sjednocení slovníku s dodavatelskou firmou. Při budování datového skladu se setkává svět obchodu, většinou z oblasti financí a svět programátorů. Jakákoliv definice může být na každé straně pochopena jinak a je důležité dávat si navzájem zpětnou vazbu. Podle mých zkušeností většinou vzniká problém na straně společnosti, když nedefinují své požadavky přesně a do detailů. Většinou je to způsobeno tím, že nějakou informaci považují za samozřejmou. Úvodní analýza obsahovala seznam datových zdrojů, u datových zdrojů bez detailu jejich způsob rozpočítávání. Dále mapování zdrojů do systému vykazování zisku a ztráty podle IFRS, předběžnou strukturu dat a časový plán.

Protože píši o tvorbě datového skladu, který skutečně proběhl, ráda bych zde popsala pár úskalí, které při úvodní analýze vyšli najevo. Opakování hodnot v číselníkách, které jako opakování nevypadají – v tomto smyslu hovořím o číselníkách v účetním softwaru. Jako příklad uvedu měrné jednotky položek. Velká většina položek má měrnou jednotku kusy. Ta se ale musí zadat do číselníku. Během let, kdy byl účetní software používán, se v číselníku objevily hodnoty kus, ks, KS, Ks, což je v databázi potřeba sjednotit. Kontrola tvrzení o obsahu dat – opět uvedu příklad. Počáteční tvrzení, že účty v intervalu 604100 až 604399 obsahují pouze zápisy, na nichž je detail na položku zboží. Praxe může být ale jiná a každý zápis bez položky by znamenal chybu. Toto jsme naštěstí již měsíčně kontrolovali a skutečně párkrát do roka někdo vynalezl způsob, jak udělat zápis na tyto účty bez kódu položky. Pokud tedy tvrdíme, že určitá data mají nějaký charakter, je potřeba to vždy ověřit, než se začne importovat do datového skladu. Nebo je potřeba takovou kontrolu při importu nastavit. Vyspělost tzv. controllingové struktury – pod tímto pojmem mám na mysli soustavu hospodářských středisek, nositelů nákladů, projektů a jiných dodatečných zařazení. Svým způsobem sem spadá i struktura účetní osnovy. Pokud například nejsem z účetnictví schopna určit, jak systematicky poznám například fixní náklady a například služby za skladování, nerozdělí to ani systém BI. Správné nastavení a používání takové struktury ulehčuje rozdělení nákladů v BI. Zápisy je samozřejmě nutné pravidelně kontrolovat. Struktura by měla být řádně promyšlená a není vhodné ji měnit každý rok. Pokud například tvrdím, že v intervalu účtů se nachází data potřebná pro určitou pozici výkazu zisků a ztrát, není vhodné toto často měnit, museli bychom měnit parametry importu dat. Znalost interních systémů – při tvorbě datového skladu je nutné znát strukturu všech systému, které budou sloužit jako zdroj pro datový sklad. V našem případě se jednalo o účetní software Exact. Pro účely plnění datového skladu je potřeba znát název tabulky, ze které čerpám. Většinou ale pouze název tabulky nestačí. V účetním softwaru se pracuje i se statusy a s různými jinými parametry. Jako 21

příklad uvedu opět prodejní faktury. Do datového skladu se mají importovat pouze vystavené, tedy hotové faktury. Musím tedy vědět, jak je faktura vystavená v účetním softwaru označena. Ve většině účetních softwarů mají zápisy také své statusy, při vložení účetního zápisu je většinou možné jej editovat až do manuální změny statusu (například jako odeslané, záleží na typu softwaru) – pro plnění datového skladu je toto opět nutné vědět. Málo společností má tuto znalost interně, většinou je nutná konzultace s někým, kdo je s účetním softwarem obeznámen. V našem případě probíhala většina interně, v některých případech proběhla konzultace s externím dodavatelem, který Exact důvěrně znal. Odpovědnost za správnost dat – z mé zkušenosti je dobré pro konzistenci a kompaktnost dat určit odpovědnosti za dané okruhy dat. Odpovědnost by měla být adresná, určená konkrétnímu zaměstnanci, ne oddělení. Časová vytíženost členů projektového týmu – při budování datového skladu bychom měli stanovit projektový tým. Většinou jsou to ale interní zdroje, zaměstnanci, kteří již ve společnosti pracují. Tudíž mají již náplň práce na plný úvazek. Pokud pak členové týmu nemají čas na kooperaci s dodavatelskou firmou, celý projekt tím prodlužují. Doporučila bych společnostem, které takový projekt zvažují, aby se zamysleli nad svými interními zdroji. Zamyslet se nad tím, zda nepřijmout na dobu určitou například brigádníka, studenta, který by mohl pomoci například s pravidelnými reporty, nebo jinou rutinnější činností. Projektová dokumentace a sdílení informací – tato činnost je někdy opomíjena, ale je důležité dokumentovat práci projektového týmu a funkčnost datového skladu. Budování takového systému je většinou dlouhodobější vize a může se stát, že se například za pár let kompletně vymění personální obsazení týmu. Zaměstnanci, kteří mají přehled o datech ve firmě a o tom, jak datový sklad funguje, mohou časem odejít a je složité bez dokumentace takové informace získat. Důležité je také vnitropodniková komunikace a sdílení informací. Dodavatelská firma musí dostávat celistvé a jednotné informace, ne různé informace od různých členů týmu. Proto jsou důležité pravidelné schůzky. Před vybudováním BI bych každé společnosti doporučila, aby si sama nejdříve udělala svou malou analýzu. Výsledkem by měl být přehled, jak a kde jsou data uchovávána, zda jsou konzistentní, kdo za ně odpovídá. Zda má ve svých datech systém a jak zpracovává reporty. Dodavatelská firma sice umí založit datový sklad, vybudovat BI, ale pracuje s daty společnosti a není v její kompetenci je opravovat, nebo do nich zasahovat.

22

9 Budování datového skladu a datové zdroje Datový sklad vznikal v Nutricii takřka „na zelené louce“. Jak jsem již zmínila v úvodu, data byla na počátku projektu velmi decentralizovaná a vlastně jediným systémem s konzistentními a jedinečnými informacemi byl účetní systém. Bylo potřeba identifikovat datové zdroje, jejich funkci a místo v datovém skladu.

9.1 Exact Exact je účetní software používaný firmou Nutricia, a.s. Stal se základním zdrojem dat pro datový sklad. Z tohoto systému jsou do datového skladu načítány i téměř celé tabulky. Relevantními tabulkami jsou zejména Hlavní kniha, která obsahuje veškeré transakce. Hlavní kniha je důležitým zdrojem pro všechny kategorie výkazu zisků a ztrát. Dále jsou z Exactu načítány seznamy hospodářských středisek, nositelů nákladů, projektů a seznam výrobků. Hierarchické zařazení veličin dále probíhá přes jiný zdroj. Problémem, kterému bylo nutné při tvorbě datového skladu čelit, byly zejména formáty číselných veličin v účetním softwaru. Ačkoliv hospodářské středisko, nositel nákladů, nebo číslo položky zboží vypadá jako číslo, účetní software to za číslo nepovažuje. V Exactu je vždy pevně definována délka veličiny a dále se liší, jestli je zarovnána zprava, nebo zleva. Pro vyhledávání v SQL serveru je pak nutné znát tuto specifikaci, psát veličinu do apostrof a nahradit zbývající počet míst mezerou. Pro použití v datovém skladu, musela být data transformována do požadovaných formátů. Struktura účtů, nositelů nákladů a hospodářských středisek byla již jasně definována z minulého období, kdy došlo k rozsáhlé aktualizaci Exactu. Kontrola zaúčtování byla stejně tak funkční. Toto práci velmi zjednodušilo a po převedení dat na požadovaný formát byla data z Exactu použitelná. Z Exactu je dále použit seznam odběratelů a dodavatelů. Seznam odběratelů a dodavatelů v sobě nese informace o tom, k jakému zákazníkovi se vztahuje určitá transakce. Pokud ale zákazník fakturuje zpět, například službu za promoci, stává se i dodavatelem. Sjednocení těchto dvou tabulek probíhalo mimo Exact. Hierarchické zařazení opět probíhá v jiném zdroji datového skladu. Dalším důležitým zdrojem pro datový sklad byly ceny položek. Exact poskytuje jak nákupní cenu, tak prodejní cenu. Prodejních cen může mít položka několik. Má tzv. základní prodejní cenu, ale výrobek může být zároveň v časově omezené akci na konkrétního zákazníka. Tato informace je také nahrávána do datového skladu pro účely budoucího vyhodnocení slev. Z Exactu byly brány jak celé transakce, tak agregace dat, pokud nebyl potřebný detail. Toto se děje například při rozpočítávání fixních nákladů. Fixní náklady nebylo potřeba zahrnovat v celém svém

23

detailu do datového skladu, protože analýza fixních nákladů nebyla cílem tvorby BI. Fixní náklady se tedy do datového skladu načítaly jako agregace po účtu a hospodářském středisku a dále docházelo k rozpočítávání podle klíče. Načtení dat do datového skladu probíhá zpravidla jednou měsíčně a je nutné jej manuálně spustit. Toto byla žádost Nutricie. Výhody tohoto rozhodnutí jsou, že načtení dat proběhne v okamžiku, kdy je měsíční závěrka ukončena a data v Exactu považujeme za správné. Přináší to s sebou ovšem určitou neflexibilitu v průběhu měsíce.

9.2 Číselníky Pro práci s veškerými číselníkovými hodnotami, které nejsou obsaženy v Exactu, byla vyvinuta miniaplikace v Excelu. Tento Excel uměl data jak vyexportovat, tak naimportovat. Data v číselníku byla doplňována také měsíčně. První okruh dat uvedených v číselníkách se týkal položek. Ke každému kódu položky zde byla uvedena produktová skupina nejnižšího řádu, která dále určovala celou hierarchii. Nejvyšším stupněm hierarchické struktury (vyjma celku) bylo z úhlu pohledu typu dětské výživy rozdělení na mléka a jídla a z pohledu značek na Hami a Nutrilon. Pokud v Exactu přibyl záznam o položce, bylo samozřejmě nutné začlenit ji do hierarchické struktury v číselníkách. Najdeme zde také informaci o gramáži výrobku, což slouží k tomu, abychom prodeje mohli analyzovat nejen podle prodaných kusů, ale také podle prodaného množství v kilogramech. Druhý okruh dat se týkal zákazníků. Zákazníci i dodavatelé se zde sjednocovali do tzv. obchodních partnerů. Jako příklad uvedu Tesco. Tesco jako zákazník má svou jednu fakturační adresu, ale může vystupovat i v roli dodavatele a u obou těchto záznamů je potřeba uvést sjednocovací prvek Tesco. Zákazníci se dále hierarchicky řadí do prodejních kanálů a i ty se dále agregují. Třetím okruhem dat v číselníkách byly tzv. nositelé nákladů. To je dimenze zadávána při účtování. Pro účely datového skladu se pracovalo zejména s nositeli nákladů určující zákazníka, za kterým jde poskytnutá sleva. Pokud byla sleva zaúčtována z faktury, nebo dobropisem, resp. opravným daňovým dokladem, dala se sleva určit pomocí zákazníka nebo dodavatele. Pokud byla ale sleva zaúčtována například jako dohad při měsíční závěrce, byl zákazník určován pomocí nositele nákladů. Nositel nákladů měl číselnou podobu a popisem odpovídal členění obchodních partnerů u odběratelů a dodavatelů. Každý zákazník (v tomto smyslu obchodní partner) měl přiřazeny dva číselné kódy. Jeden pro aktuální rok a jeden pro rok minulý. Toto sloužilo spíše pro controlling, aby mohl správně určit efekt slev z minulého roku do roku současného. Slevy byly dále účtovány i na hospodářské středisko.

24

A tím se dostáváme ke čtvrtému okruhu dat zpracovávaných v číselníkách. Hospodářské středisko ve smyslu slev určovalo produktovou skupinu, ke které se váže. Jinde určovalo oddělení fixních nákladů. Fixní náklady se dále člení na náklady na logistiku (i když tam nemluvíme 100% o fixních nákladech), obchodní zástupce a na náklady spojené s kanceláří, nebo chodem společnosti. Určení těchto hospodářských středisek se také odehrávalo v číselníkách. Pátým okruhem dat zpracovávaných v číselníkách byly čísla účtů a povolené kombinace účtů s hospodářskými středisky. Toto sloužilo jak ke kontrole účetnictví, tak k rozřazení dat do správné struktury výkazu zisků a ztrát. Šestým údajem v číselníkách je kurz koruny k euru platný pro určitý rok. Tímto kurzem se pak přepočítávají všechna data. Údržba číselníků probíhala měsíčně. Nejprve bylo nutné aktualizovat číselníky přesně podle datového skladu. Do aktualizovaného číselníku pak bylo možné připisovat záznamy v požadovaném formátu a takto aktualizovaný číselník nahrát zpět do datového skladu.

9.3 Ostatní zdrojové soubory Ostatní zdrojové soubory byly určeny k nahrávání dat, které nebyly obsaženy v Exactu a nejsou číselníkovými hodnotami. Prvním takovým zdrojem byl soubor cen položek. Každá položka má přiřazeno několik nákladových cen, které nejsou součástí Exactu. Každá položka, která byla zaznamenána v transakcích hlavní knihy, musela mít také přiřazeny své ceny. Protože se ceny mohou měnit (minimálně jednou ročně), byly ceny vkládány měsíčně a historie byla uchovávána. Dalším zdrojem pro datový sklad byla historie slev poskytovaných při fakturaci. Protože Exact neumí držet historii tohoto údaje a pro zpětné výpočty byla tato hodnota nutná. Každý měsíc se tedy zálohovala data související s procentuální slevou poskytovanou při fakturaci. Třetím zdrojem patřícím do kategorie ostatních zdrojů byly plány. Pro porovnání s plánem bylo nutné plán v datovém skladu obsáhnout. Jak a v jakém formátu naimportovat do datového skladu plán se ukázalo být celkem složité. V plánu samozřejmě nejsou použity všechny dimenze, které lze použít v aktuálním období. Bylo tedy nutné specifikovat klíče, podle kterých se bude plán porovnávat na aktuální průběh roku. Plán byl importován v detailu po produktových skupinách, které odpovídaly členění v číselníku, po zákaznících, kteří odpovídali členění po obchodních partnerech a po měsících. Měsíc se v aktuálním období dá odvodit z data. Dalším zdrojem byla tabulka klíče, jak rozpočítávat fixní náklady na obchodní zástupce. U jednotlivých týmů nelze s jistotou určit, jaký prodejní kanál a jakou produktovou skupinu nejvíce ovlivňují. U obchodního týmu specializujícího se na lékárny lze ale odvodit, že největší vliv budou mít 25

pravděpodobně na prodejní kanál pharma a na produktové skupiny mlék a kaší. Nejméně pak na produkty typu masozeleninových příkrmů. S jistotou to ale nelze určit. Proto byla vytvořena matice na rozpočítávání těchto fixních nákladů. Matice byla tvořena na základě výpočtů, ale také na základě odhadu. Podle této matice se fixní náklady na obchodní zástupce rozpočítávaly na produktové skupiny do prodejních kanálů.

10 Vrstva L1 Vrstva L1 je taková součást datového skladu, kde dochází k prvnímu zpracování zdrojových dat a k jejich načtení a případnému rozpočítání. Ve vrstvě L1 probíhá také kontrola načtených dat. Jedná se o načtení zdrojových dat tak, aby byly komplexní a konzistentní. Při tvorbě vrstvy L1 dochází ke kontrole dat a chybné záznamy jsou filtrovány do tabulky chybných zápisů. Po kontrole je nutné chybná data opravit. Transakce použité v celém svém detailu byly řádky prodejních faktur a zdrojem byl Exact. Účetní zápis prodejní faktury vypadal z pohledu výkazu zisku a ztrát (neberu tedy v úvahu ani účet odběratele ani účet DPH) jako dvojí zápis na analytické účty 604, kdy na jeden se zaúčtovala celková částka bez jakýchkoliv slev, zjednodušeně základní ceníková cena vynásobená počtem kusů a na druhý účet poskytnutá sleva. Dále samozřejmě proběhne zápis na analytický účet 504, náklady na prodané zboží. Pro účely datového skladu byly náklady na prodané zboží počítány zvlášť a pro datový sklad jsme použily všechny zápisy na účtech 604. Poskytnutá sleva na faktuře může být dvojího typu a pouze z Exactu nebylo zřejmé, o jaký typ se jedná. První typ slevy je smluvní a bývá stanoven jako procentuální částka z ceníkové ceny. Tato sleva je zadaná v Exactu v kartě odběratele, ale při změně bohužel nedokáže uchovat historii. Pro zpětné výpočty je tedy tato informace nerelevantní. Druhý typ slevy je časově omezená dohoda u určitého zákazníka. Většinou se vztahuje pouze na omezený okruh sortimentu objednaný v určitém časovém rozmezí. Historie takových slev je v Exactu uchovávána. Informace z tabulky cenových dohod nám pak říká kód položky, datum od, datum do a novou cenu, za kterou bylo v tom daném časovém období prodáváno. Z Exactu již ale nejde vyčíst, jaký typ slevy byl zrovna aplikován, jinými slovy nešlo v částce určit, jaká sleva byla dána z titulu smlouvy a jaká nad rámec smlouvy. Toto bylo dále v datovém skladu řešeno dopočítáváním. Nejdříve byla vypočtena částka, která vznikla z titulu smlouvy a k celému zbytku bylo pohlíženo jako na cenovou dohodu. Díky této informaci jsme získali povědomí o struktuře slev na faktuře. Z těchto transakcí jsme zároveň získali informaci o prodaných kusech a díky číselníkům je možné tento prodej převést na kilogramy.

26

Po fakturovaných prodejích následují slevy poskytnuté tzv. mimo fakturaci (také off invoice). Tyto slevy se počítají většinou na základě smlouvy a někdy se jedná o zpětnou fakturaci poskytnuté služby, například promoční akce cílené na určitou produktovou skupinu. V datové kostce se tyto slevy nepočítají, ale jsou brány z účetnictví. Každý měsíc se revidují zaúčtované slevy a další předpokládané podle smlouvy, nebo na základě informace z obchodního oddělení jsou tvořeny dohadné položky. Na to již existuje v Nutricii funkční proces a datová kostka dále pracuje pouze se zaúčtovanými hodnotami. Každá sleva poskytnutá mimo fakturu je zaúčtovaná s nositelem nákladů a tím určíme obchodního partnera a s hospodářským střediskem, čímž určíme produktovou skupinu. Rozpočítávání, které se děje ve vrstvě L1 je přiřazování slev k prodaným položkám na základě údaje o zákazníkovi a produktové skupině. V rámci produktové skupiny pak probíhá výpočet podle prodaného množství. Tím se ve vrstvě L1 dopracováváme k čistým prodejům. Po určení čistých prodejů v detailu na položku zboží a zákazníka následuje výpočet nákladů na prodané zboží. Po výpočet těchto nákladů nebyl používán Exact. Výpočet probíhal ve vrstvě L1 jako násobek prodaných kusů a nákladové ceny. Výsledek byl pak porovnáván se skutečnými náklady na prodané zboží a zbytek byl rozpočítán podle prodaných kusů. Rozdíl byl většinou tvořen poplatky za Eko-kom, kde nelze s jistotou určit jak částku rozpočítat a náklady na polepování. Tyto náklady nebyly dle rozhodnutí managementu signifikantní a byly tudíž rozpočítávány tak, jak jsem vysvětlila výše. Po určení nákladů na prodané zboží se do vrstvy L1 importovaly náklady na logistiku. Ta v sobě obsahuje náklady na skladování, náklady na distribuci, náklady na likvidaci zboží, inventurní rozdíly a fixní náklady na oddělení logistiky. Všechny tyto náklady se dají určit podle hospodářského střediska a takto byly vybírány pro účely datového skladu. Rozpočítávání pak probíhalo podle prodaných kilogramů. Rozpočítávání opět probíhalo v detailu na položku zboží a zákazníka. Po logistických nákladech následovaly náklady na marketing, ve smyslu marketingových aktivit. Ne na oddělení marketingu. Jako zdroj opět posloužil Exact. Náklady tohoto typu mají vyčleněn svůj seznam účtů a dalším rozměrem v účtování je hospodářské středisko, značící opět produktovou skupinu. Podle čísla účtu jsou vymezeny čtyři skupiny nákladů na marketing, toto určení najdeme v číselníkách. Ve vrstvě L1 se náklady na marketing rozpočítávaly primárně pouze podle výrobků na základě produktových skupin uvedených v Exactu. V celkovém objemu dat pak došlo i přirozeně k přiřazení k zákazníkům. Po marketingových nákladech se do vrstvy L1 importovaly náklady na obchodní zástupce a obchodní oddělení. K rozpočítávání docházelo podle klíče v číselníkách. Vše opět v detailu na položku zboží a zákazníka. Fixní náklady ostatní (například náklady na oddělení financí, oddělení marketingu, regulatory, HR) byly rozpočítávány pak pouze podle prodaného množství.

27

Tímto jsme obsáhli téměř celý výkaz zisků a ztrát. Po rozpočítání všech hodnot je tedy zatím teoreticky možné určit, jak který výrobek na jakém zákazníkovi je nebo není ziskový. Díky historickým datům – datový sklad byl při tvorbě nahrán od roku 2009 – bylo opět zatím teoreticky provádět analýzy vývoje slev a vývoje marží. Datový sklad se tímto stal cenným nástrojem pro podporu rozhodovacího procesu. Vrstva L1 má také kontrolní funkci a data při vstupu do datového skladu kontroluje podle stanovených pravidel. Kontroly jsou z několika úhlů pohledu a podle zkušenosti byly i funkční. Data, která prošla kontrolním systémem vrstvy L1 byla opravdu systematická a dala se vždy zařadit do struktury BI. Ráda bych zde uvedla systém kontrol, které byly při vstupu dat prováděny. Úroveň prodeje výrobků – v této úrovni dat se prováděla kontrola, zda je zápis s položkou zboží a zda je tato uvedena v číselníkách. Dále byla prováděna kontrola odběratele, zda je uveden v číselníkách v seznamu dodavatelů a zda má přiřazené procentuální hodnoty slev při fakturaci. Úroveň slev – pro slevy „mimo fakturu“ byl určující seznam účtů dedikovaných jen pro takovéto zápisy. Kontrola probíhala na úrovni nositele nákladů. Musel být existující v číselníkách. Náklady na prodané zboží – zde probíhala kontrola, zda všechny kódy položek zboží mají v tabulce cen uvedenu nákupní ceny. Úroveň ostatních nákladů – V těchto zápisech byla kontrolována kombinace účtu a hospodářského střediska. Neplatné kombinace, tedy ty nevyskytující se v číselníkách byly považovány za chybné. Kontrola byla prováděna na úrovni transakcí z Exactu. Všechny transakce, které byly označeny za chybné se po importu do vrstvy L1 nacházely ve speciální databázi chybných zápisů. Po manuálním spuštění importu dat do vrstvy L1 musela být tato databáze zkontrolována. Zápisy v této databázi zůstávaly a bylo třeba ji ručně vymazávat. Ukázku struktury tabulek ve vrstvě L1 lze vidět na obrázku 1. Na schématu zkratka PK představuje primární klíč a FK cizí klíč.

28

Obrázek 1: Tabulky vrstvy L1

11 Vrstva L2 Ve vrstvě L2 se připravená a zkontrolovaná data připravují pro výstup do datové kostky. Vrstva obsahuje tři ukazatele pojmenované amount, units a volume. První představuje peněžní vyjádření, druhý počet kusů a třetí objem (v kg). Pro generování kostky byly vytvořeny tři zdrojové datamarty: L2_IS – Invoiced sales – obsahuje fakturované prodeje, které mají kompletní rozsah dimenzionální mapy až na úroveň kódu položky a zákazníka. L2_NNS – Net net sales – Obsahuje ukazatele čistých prodejů, které při načítání obsahují informace hospodářského střediska a nositele nákladů a na nižší úroveň je třeba je rozpočítat. Je zde také obsažena dimenze, zda bylo zboží v akci. L2_Costs – Obsahuje všechny ostatní ukazatele, které při načítání nemají žádnou informaci o kódu výrobku, nebo zákazníkovi. Tyto ukazatele se kompletně rozpočítávají na úroveň položky zboží a zákazníka. Datamart jsou transformovaná, odfiltrovaná a agregovaná data z vrstvy L1 připravená tak, aby se dala přímo použít jako zdroj pro generování datové kostky. Na následujících schématech je možno vidět jednotlivé datamarty. Na schématu zkratka PK představuje primární klíč a FK cizí klíč. 29

Obrázek 2: Datamart Invoiced sales

Obrázek 3: Datamart Net net sales

30

Obrázek 4: Datamart costs

Struktura ukazatelů má určenou hierarchii, kdy z podřízených ukazatelů se načítá ukazatel nadřízený. Vzhledem k tomu, že sledované ukazatele mají svojí hierarchii a z podřízených ukazatelů se agregují ukazatele nadřízené, vykazují vlastnosti dimenze. Aby tato vlastnost byla automaticky zabudována v datové kostce, bylo třeba vytvořit z ukazatelů zvláštní dimenzi Ukazatel. Tato dimenze je generována ze souboru číselníky, o kterém jsem hovořila dříve.

12 Výstup z datového skladu Pokud bychom chtěli být přesní, je výstupem z datového skladu datová kostka. Ta se generuje na základě zadaných parametrů, a pokud je již jednou definovaná, je možné ji pak pouze aktualizovat. Pro uživatele je ale výstupem to, co vidí, konkrétní reporty. Ne imaginární datová kostka, o které na pozadí ani neví. Výstup z datového skladu byl v Nutricii řešen jednou velkou datovou kostkou s tím, že v další fázi může být vytvořeno několik dalších. Datová kostka ale obsahovala tolik dat, že již nebylo třeba tvořit kostky jiné. Tato datová kostka byla samozřejmě pomalá. Na výstup z ní bylo nutné čekat někdy až 10 vteřin. Podle mého názoru je lepší stanovit si dílčí cíle a tomu přizpůsobit tvorbu datových kostek a je lepší pracovat s několika malými. Příliš komplikovaný výstup pak komplikuje celou práci. Panuje všeobecný předpoklad, že musím na začátku budování datového skladu co nejvíce definovat jeho použití, aby byl tomu přizpůsoben. Někdy ale toto vede k přílišné zmatenosti v tom, co vlastně chceme a vypadá to tak, že vlastně chceme všechno a v datech je pak snadné se ztratit. Chtěla bych upozornit, že není 31

cílem stanovit si co nejkomplikovanější report jako výstup, ale měli bychom se zamyslet nad použitím, stanovit si dílčí cíle a těm se přizpůsobit. Jedním z výstupů z datového skladu, přesněji řečeno z datové kostky byla aplikace Cognos, report zobrazený v internet Exploreru. V prostředí internet Exploreru, v tzv. analysis studiu byla připravená struktura celého výkazu zisků a ztrát po výsledek před úroky a daní. Tento report se pak dal přizpůsobit na jakéhokoliv zákazníka, prodejní kanál, produktovou skupinu, nebo i konkrétní výrobek. Report se dal použít buď pouze pro aktuální hodnoty, nebo porovnání s plánem. Pro uživatele z obchodního oddělení jsem v tomto prostředí připravila tyto reporty po zákaznících a prodejních kanálech, s možností volby produktové skupiny. Naopak pro uživatele z marketingu jsem připravila reporty po značkách a v nich po produktových skupinách s možností volby zákazníka, nebo prodejního kanálu. V internetovém prostředí bylo možné vytvářet i své vlastní reporty, které si buď tvořili uživatelé sami, nebo požádali o jeho vytvoření. Dalším možným výstupem v internet Exploreru byl report v tzv. report studiu. V report studiu si uživatelé nebyli schopni nic vytvořit, pouze prohlížet již vytvořené reporty. Zde jsem vytvořila měsíční report prodejů po produktových skupinách a zákaznících s hodnotami amount a volume. Nevýhodou tohoto reportu je nízká interaktivita. Není možné zobrazit si větší detail, pouze je možné měnit parametry. Výhodou je, že je rychlejší a pro účely tisku nebo pdf souborů lze lépe upravit vizuální stránku reportu. Z obou dvou studií šlo samozřejmě udělat výstup do několika formátů souborů. Nejvíce využívaný byl asi Excel. Nevýhodou bylo, že Excel byl statický a již se nedal aktualizovat. Nové verze BI toto již umí, bohužel v tuto dobu to nebylo možné. Výstup do Excelu se dal částečně nahradit kontingenční tabulkou v Excelu, která byla navázána do vrstvy L2. Toto bylo ale spíše pro pokročilejší uživatele a já sama jsem toto využívala spíše pro kontrolu.

13 Hodnocení V této části mé práce bych chtěla shrnout poznatky a zhodnotit tvorbu datového skladu ve společnosti Nutricia, a.s. Nejprve bych chtěla zmínit pozitivní dopady budování datového skladu na společnost. Jedním z pozitivních efektů je spolupráce mezi odděleními. V projektovém týmu byly zastoupeni zaměstnanci oddělení logistiky, controllingu a na méně pravidelné bázi marketing a prodejní

32

oddělení. Navzájem jsme museli sdílet informace o svých činnostech a museli jsme navzájem pochopit činnosti, které se v odděleních odehrávají. Být součástí takového projektového týmu je určitě velmi obohacující a přináší spoustu nových poznatků. Také náhled na chod firmy získá novou dimenzi. Chod firmy začneme chápat v širších souvislostech. Dalším pozitivním efektem bylo zapojení obchodního týmu a marketingu do širších souvislostí. Před vybudováním datového skladu a BI nebylo zejména obchodní oddělení motivováno sledovat výsledky na jednotlivých zákaznících a hlídat jejich ziskovost. Do té doby bylo jediným cílem výše prodejů. Při historickém vyhodnocování slev se toto ukázalo. Díky pochopení těchto širších souvislostí začali o poskytovaných slevách více přemýšlet a více je cílit tam, kde to dávalo smysl. Stejně tak oddělení marketingu dostalo podklady, které bylo jinak složité získat. V datech se dalo najednou nalézt, jak která marketingová akce se projevila na jakém zákazníkovi. Takové vyhodnocování mělo například za následek upravování marketingových balíčků pro různé prodejní kanály. V dnešní době naleznete málokdy stejný promoční balíček v retailu a například v lékárně. Spolu s tržními daty se BI stalo důležitým nástrojem pro pochopení chování trhu. Dalším pozitivním aspektem celého projektu byla formulace cíle již na začátku. Ačkoliv byl cíl formulován již na začátku, budu o něm psát také později v aspektech, které bych dnes změnila. Cíl byl stanoven jako možnost zjistit profitabilitu jednotlivého výrobku na jakémkoliv zákazníkovi. Toto bylo splněno, ale splnění cíle vyžadovalo práci s velkým objemem dat a mnoho doplňujících výpočtů tak, aby bylo možné profitabilitu do takového detailu spočítat. Pro mě osobně byla účast v takovém projektu přínosná i z hlediska osobního rozvoje. Naučila jsem se díky tomu pracovat trochu s SQL serverem, psát jednoduché query a poznala jsem fungování datových pump. To jsem ale opravdu měla možnost pouze pozorovat. Při mapování datových zdrojů jsem si prohloubila znalosti o datových strukturách ve společnosti a troufám si říci, že v rámci společnosti jsem se stala téměř expertem. Díky novým poznatkům jsem si byla schopna vytvořit i jiné nástroje pro controlling, které ani nesouvisely s budováním datového skladu. Datový sklad jako zdroj datové pravdy – to je další efekt, který získáme díky vybudování datového skladu a BI. Samozřejmě je důležité výsledky zobrazené ve výstupech pravidelně kontrolovat, ale pro společnost je to interně jediný zdroj a odpadá tedy ověřování dvou různých výsledků. Pozitivní změnu přinesla také možnost částečné samoobsluhy ze strany uživatelů. Uživatelé si mohli najednou vytvořit sami report, uložit jej a dále jen aktualizovat. I při jednorázové pomoci ze strany controllingu toto přinášelo časovou úlevu pro controlling. Informace, které by dříve požadovali ze strany financí, byly najednou schopni sami získat. Myslím, že proces budování datového skladu vnesl do povědomí zaměstnanců, že existují širší souvislosti ve fungování firmy. Díky tomu se komunikace především mezi marketingem a prodejním

33

oddělením začala odehrávat na jiných základech a začala mnohem lepší komunikace. Na meetingy marketingového a obchodního oddělení jsou od té doby zvány pravidelně i finance. Při budování datového skladu samozřejmě neprobíhá vždy všechno ideálně, a proto bych dále chtěla uvést několik aspektů, které mohly být jinak, nebo kterých jsme se mohli již od začátku vyvarovat. Panuje všeobecné přesvědčení, že při projektech tohoto typu je potřeba všechno promyslet již na začátku, protože potom je jakákoliv změna nemožná, nebo velmi složitá. Já bych si dovolila s tímto nesouhlasit. Na počátku je samozřejmě důležité zvážit cíl a cestu k němu, ale je možné zvážit také etapy práce. Myslím, že první a jediný cíl nemusel být sledovat chování jednotlivých výrobků až po EBIT. Souhlasím se sledováním marže po výrobcích na jednotlivých zákaznících. Stačila by ale marže po logistických nákladech. Výkon jednotlivých výrobků na zákazníkovi je nejvíce ovlivněn slevami a ty v datovém skladu byly. Už se ale nekladl takový důraz například na balení promočních balíčků a logistické náklady byly rozpočítávány jako celek. Podle mého názoru by stačila jedna kostka, která by obsahovala detail po položce zboží a zákazníkovi po marži po logistických nákladech. Naopak jiná kostka pak mohla sloužit ke kontrole a k řízení fixních nákladů. Není podle mě nutné zahrnovat fixní náklady do rozhodovacího procesu o tom, na jakém zákazníkovi, nebo v jakém prodejním kanále budu dělat jakou promoční akci a kolik to bude stát. Navíc rozhodování mnohdy neprobíhá striktně podle finančních výsledků, ale rozhodování o promočních akcích v sobě nese také aspekt strategie. Někdy se marketingová akce uskuteční i přes předpoklad nižší ziskovosti. Ale zapadá do firemní strategie. Z tohoto důvodu nevidím velký přínos v rozpočítávání fixních nákladů. Mohli bychom namítnout, že alespoň fixní náklady na obchodní zástupce by se o jednotlivých prodejních kanálů rozpočítávat mohli. Podle mého názoru je ale složité určit, jak který zástupce ovlivní jaký prodejní kanál. Pokud například obchodní zástupce navštíví lékárnu a představí akci na Hami mléka – teoreticky bychom tedy předpokládali, že celý náklad v době této akce, na tohoto obchodního zástupce by měl být přiřazen do prodejního kanálu pharma, produktová skupina Hami mléka. Realita může ale být úplně jiná. Lékárník může mamince poradit Hami mléko, maminka si ho koupí, ale pouze jednou. Další nákupy už může realizovat jinde, a protože je spokojená, může zkusit i jiné produktové skupiny. Podle mého názoru je nemožné 100% správně přiřadit náklady na obchodní zástupce. Vždy budeme pracovat pouze s předpoklady. Podle mého názoru to není ani tak obchodní zástupce, co ovlivňuje prodej na jednotlivých prodejních kanálech, ale právě probíhající akce. Role obchodního zástupce je spíše budování povědomí. Rozhodování by tedy nemělo probíhat v rovině kolik který stojí a co ovlivní, ale kolik chci do obchodních zástupců investovat celkem. A to potom nepotřebuji rozpočítávat na jednotlivé výrobky. Stejně tak fixní náklady týkající se chodu kanceláře se podle mého názoru rozpočítávat nemusely. Tato informace podle mého nepřinesla žádný výjimečný benefit v rozhodovacích procesech.

34

Myslím, že by bylo vhodnější stanovit cíle dva. První týkající se prodejů a data zpracovat tak jak byla zpracována, ale pouze po logistické náklady. Druhý cíl by se pak týkal fixních nákladů a sloužil by ke kontrole a plánování takových nákladů. Druhý cíl mohl být časově posunut a mohl být do datového skladu pouze přidán. Tvorba datového skladu a BI ale podléhá momentálním potřebám managementu a je podřízená jejich rozhodování. Ráda bych tedy v mé práci poukázala na mýtus všeobecně přijímaný, že už na začátku musím sestavit co nejkomplikovanější strukturu dat, aby s ní bylo později možné pracovat. Podle mého názoru to není pravda. Cíle si můžeme rozdělit do dílčích cílů a za pomocí dodavatelské firmy definovat vše potřebné. Datový sklad se dá rozšiřovat a BI se dá s časem upravovat. Struktura nemusí být na začátku komplikovaná. Jako celek hodnotím tuto zkušenost kladně, mnoho jsem se v tomto projektu naučila a poznatky z té doby stále využívám. Naučila jsem se více chápat strukturu navzájem propojených tabulek v datových systémech a procvičila jsem se ve zpracovávání velkého množství dat.

14 Poznatky V této části mé práce bych ráda shrnula poznatky z celého projektu. Vedoucí projektu – pokud se firma pouští do takového projektu jako je budování datového skladu a následně BI, doporučuji zároveň určit vedoucího projektu. Vedoucí projektu by měl být ideálně střední manager a měl by mít silnou osobnost. Měl by zvládat koordinovat spolupráci interního projektového týmu a dodavatelské firmy. Měl by znát kompletní záměr BI, aby byl schopen dílčího rozhodování, měl by komunikovat s top managementem a informovat je o průběhu projektu. Vedoucí projektu nemusí sám vykonávat činnosti jako identifikaci a úpravu datových zdrojů, ale měl by mít přehled a případně korigovat práci projektového týmu. Z mých zkušeností je celkem složité tzv. přepnout a začít uvažovat o širších souvislostech po celodenním detailním zkoumání dat. Toto by měla být úloha vedoucího projektového týmu. Spolupráce v rámci firmy – při takovém projektu je velmi důležitá spolupráce v rámci firmy i s dodavatelskou firmou. Dodavatelská firma je dostatečně motivována, protože ta za službu dostane zaplaceno. Je ale důležité motivovat i zaměstnance firmy, kteří se do projektu zapojují v rámci vztahu zaměstnanec-zaměstnavatel. Zaměstnanci by měli být obeznámeni s tím, že takový projekt probíhá, kdo je členem týmu, jaké budou benefity a přínosy nového systému a měli by být upozorněni, že i oni budou možná v této souvislosti požádáni o pomoc.

35

Osobní zainteresovanost – mnoho firem má systém ohodnocování zaměstnanců a výpočet bonusů navázaných na osobní výkon. Pokud je to možné, je vhodné účast a výsledky projektového týmu promítnout do osobního ohodnocení touto formou. Je to jeden z účinných motivačních faktorů. Testovací skupina – v průběh projektu je vhodné stanovit testovací skupinu, ideálně napříč odděleními v celé firmě. Testovací skupina by měla obsahovat budoucí uživatele. Pokud se ve společnosti nachází zaměstnanec, který není nikdy moc spokojený, polemizuje nad výsledky a neustále řeší různé reporty, pak je nejvhodnějším kandidátem pro vstup do testovací skupiny. Testování dílčích pokroků právě na testovací skupině by mělo zabránit publikaci nehotové práce a všichni uživatelé by pak měli dostat již hotový produkt. Já osobně bych doporučila ještě třetí úroveň. Výsledek nejdříve otestovat na testovací skupině, potom na všech uživatelích kromě top management a až nakonec zpřístupnit produkt top managementu. Role managementu – toto je jen doporučení pro manažery ve společnostech, které se chystají implementovat BI. Manažeři by měli naslouchat a sami i poznat datovou strukturu ve firmě. Měli by zvažovat i protinávrhy postupů. Jeden člověk není vševědoucí a někdy se stává, že názor jediného člověka potom vyhraje nad racionálními připomínkami projektového týmu. Změna managementu – bohužel budování datového skladu a systému BI podléhá momentálnímu manažerskému rozhodnutí. Za nějakou dobu se ale většinou na manažerských postech odehraje personální změna a tím pádem i změna priorit. Cíle BI, které byly považovány za potřebné před tím, najednou dostávají úplně jiné pořadí důležitosti. Někdy se také stává, že příchozí manažer je zvyklý na práci s jiným systémem ze své předchozí pracovní zkušenosti a tento systém začne prosazovat i ve své současné společnosti. Důvod podle mého názoru ani není v tom, že by jeden systém byl dobrý a jeden špatný, ale může se stát, že je zde pouze nechuť učit se něco nového. Jedna z marketingových komunikací Nutricie týkající se masozeleninových příkrmů říká, že je potřeba někdy i sedmkrát příkrm dítěti podat, aby si zvyklo na novou chuť. Asi to platí i o vnitropodnikových systémech.

15 Pokračování V divizi Early Life Nutrition již nepracuji, ale vývoj datového skladu a BI i po mém odchodu sleduji. V druhé polovině roku 2013 byl stávající systém BI nahrazen novým Panorama Necto a BI byl rozšířen i o aspekt plánování. Proces plánování byl již předtím funkční, ale podobně jako před vybudováním datového skladu se odehrával v soustavě tabulek aplikace Microsoft Excel. Proces byl tedy přenesen do systému BI. Dále získal systém BI aspekt interaktivity – některá data se zpracovávají denně a projektují výhled na konec měsíce.

36

Výhled do budoucnosti je zabudovat do datového skladu také tržní data. Nyní pracuji v divizi Advanced Medical Nutrition a během roku 2014 bychom měli vybudovat vlastní datový sklad a v lednu roku 2015 spustit BI také v Panorama Necto.

16 Názory uživatelů a tvůrců BI Oslovila jsem tři zaměstnance korporace Danone, kteří s BI pracují, nebo jej tvoří a zeptala jsem se na jejich názor, co je přínosem BI a čeho se případně vyvarovat.

16.1 Vadims Ilovaiskis Finance & Supply Chain Director Danone Baby Nutrition Czech & Slovak Republics

-

BW should be cheap and flexible solution

-

What is important is the scope of BW ...i.e. it should be practical for users -> only relevant information and easy to use.

-

One owner, ideally understanding the business and having the IT skills to adjust/create reports or retrieve relevant information.

-

BW should always work and information should show sense, otherwise the credibility of the reports and information is lost

-

BW should become the only reference when talking numbers and business

-

Important is to keep the documentation and knowledge transfer in case of the departure of an owner of BW

Překlad: -

BW by mělo být levné a flexibilní řešení

-

Důležitý je rozsah BW, to znamená, aby byl praktický pro uživatele -> pouze relevantní informace, jednoduché k použití

-

Jeden vlastník, ideálně takový, který rozumí obchodu a má potřebné znalosti IT, aby mohl přizpůsobit/vytvářet reporty a vyhledal relevantní informace.

-

BW by měl vždy být funkční a měl by ukazovat smysluplné výsledky, jinak reporty i informace v něm obsažené ztrácí na důvěryhodnosti

-

BW by měl být jediným zdrojem, pokud se budeme bavit o číslech a obchodu

37

Je důležité zpracovávat a uchovávat dokumentaci a předávání znalostí pokud odchází klíčová

-

osoba pro BW

Pozn. BW = Business (data) warehouse

16.2 Jan Hromádko Head of Controlling Danone Baby Nutrition Russia Plusy: -

Je dobré mít databázi na udržování dat jako zdroj jediné pravdy

-

Rozpočítání nákladů do nejmenšího detailu

-

V prostředí jako je Rusko (velká fluktuace), je potřeba vytvořit základní balík reportů, ve spolehlivém systému

Mínusy: -

Náklady a čas implementace, projekt musí mít vlastní dedikovanou osobu pouze pro tvorbu a následně pro správu systému

-

Změny v top managementu – každý top manager má své vlastní vize a chce jiné výstupy z datového skladu

-

Komplikovanost systému

16.3 Simons Levinsons Business Systems Analyst – Support Enterprise Danone IS Central Europe Hub When Building DW important is to: Understand the business evolution and requirement evolution to make the data warehouse easy adjustable towards new needs. Store in the DW only data and information having business meaning, not just fields with values from the source system without having any value added.

Překlad: Při budování datového skladu je důležité:

38

Rozumět vývoji obchodu a vývoji požadavků, aby byl datový sklad jednoduše přizpůsobitelný novým potřebám. Skladovat v datovém skladu pouze informace, které mají význam pro obchod, ne jen pole s hodnotami ze zdrojového systému, které nemají žádnou přidanou hodnotu.

17 Závěr Závěrem mé práce bych chtěla v několika větách shrnout celý projekt budování datového skladu. Každé společnosti bych doporučila zamyslet se nad možností vybudování datového skladu. Získá tím přehled o svých datech, bude mít k dispozici podklady pro rozhodování. Zaměstnanci v projektovém týmu získají nové poznatky a budou na společnost nahlížet v jiných souvislostech. Účast v takovém projektovém týmu může být pro některé zaměstnance velmi motivační. Já osobně jsem ráda, že jsem se takového projektu účastnila a považuji to spolu se vzděláním, které si dodělávám, za jeden z hlavních momentů mého osobního rozvoje.

39

LITERATURA: [1] LABERGE, Robert. Datové sklady, Agilní metody a business intelligence, 1.vydání. Brno: Computer Press, a.s., 2012. 350 s. ISBN 978-80-251-3729-1 [2] LACKO, Luboslav. Business Intelligence v SQL serveru 2008, Reportovací, analytické a další datové služby, 1.vydání. Brno: Computer Press, a.s., 2009. 456 s. ISBN 978-80-251-2887-9 [3] NOVOTNÝ, Ota, POUR, Jan, STRÁNSKÝ, David. Business Intelligence, Jak využít bohatství ve vašich datech, 1.vydání. Praha: Grada Publishing, a.s., 2005. 254 s. ISBN 978-80-247-6685-0

INTERNETOVÉ ZDROJE: [1] Wikipedia [online]. [vid. 19.4.2014]. Dostupné z: http://cs.wikipedia.org/wiki/Business_Intelligence

SEZNAM TABULEK: Obrázek 1: Tabulky vrstvy L1 ................................................................................................................. 29 Obrázek 2: Datamart Invoiced sales ...................................................................................................... 30 Obrázek 3: Datamart Net net sales........................................................................................................ 30 Obrázek 4: Datamart costs .................................................................................................................... 31

40