Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Nastavení BI systému ve firmě Epico International s.r.o.
ZÁVĚREČNÁ PRÁCE
MBA program: Data & Analytics for Business Management
Autor: Jan Vítek
Vedoucí práce: Ing. Martin Potančok, Ph.D.
Praha, 01/2021
Poděkování
Tímto bych chtěl poděkovat především své manželce, která mě podporovala ve studiu i navzdory tomu, že za poslední rok a půl jsem pravděpodobně strávil více času na přednáškách nebo nad psaním této práce než s ní. Dále bych chtěl poděkovat Ing. Martinu Potančokovi, Ph.D. za cenné připomínky a v neposlední řadě Romanovi Nováčkovi, díky kterému jsem měl možnost psát tuto práci ve spolupráci s firmou Epico Internationl s.r.o.
Abstrakt
Cílem této práce je navrhnout a v rámci pilotního projektu implementovat business intelligence systém pro firmu Epico International s.r.o. První část práce představuje firmu Epico International s.r.o. Je zde popsána její historie, zaměření a organizační struktura. Poté jsou popsány business požadavky na BI systém a čtyři business potřeby. Hlavní část práce se věnuje teorii datového skladu, která je v další části aplikována na firmu Epico a její business požadavky a slouží jako východisko pro návrh BI systému. Výsledkem práce je za prvé funkční BI systém, který splňuje všechny požadavky managementu a koncových uživatelů a za druhé road map popilotního rozvoje projektu.
Klíčová slova :
Business intelligence, Datová analytika, Datová architektura, Vizualizace dat
JEL klasifikace: C80
Abstract
The aim of this thesis is to design and implement a business intelligence system for Epico International s.r.o. The first part of the thesis introduces the company Epico International s.r.o.
- its history, scope of business and organizational structure. The next section focuses on the business requirements and business needs for the BI system. The main part of the thesis describes theoretical background of a data warehouse architecture, which is then applied in the next section to Epico International and serves as a starting point for the design of a BI system.
The results of the work are, firstly, a functional BI system that meets all the requirements of company’s management and end users, and secondly, a road map of the after-pilot development of the project.
Keywords:
Business intelligence, Data analytics, Data architecture, Data visualization
JEL Classification: C80
Obsah
1 Úvod ... 9
1.1 Cíle práce ... 9
1.2 Struktura práce ... 10
2 Business prostředí a Business požadavky ... 11
2.1 Charakteristika business prostředí ... 11
2.2 Specifikace business požadavků na řešení ... 12
2.2.1 Návrhy a popis dashboardů a reportů ... 14
3 Analýza a návrh řešení projektu ... 17
3.1 Teorie datového skladu ... 17
3.1.1 ETL (Extract, Transform, Load) alias Datové pumpy ... 20
3.1.2 Data staging area (DSA) ... 21
3.1.3 Datová tržiště (Data Marts, DM) ... 21
3.1.4 Reportingová vrstva ... 23
3.1.5 Master data management ... 24
3.1.6 Data quality management ... 25
3.2 Popis aktuálního stavu analytického systémů v Epico s.r.o. ... 26
3.3 Návrh datové architektury pro Epico s.r.o. ... 27
3.3.1 Datové zdroje ... 29
3.3.2 ETL ... 31
3.3.3 Datová tržiště ... 33
3.3.4 Master data management ... 34
3.3.5 Datová kvalita ... 37
3.3.6 Reportingová vrstva ... 38
4 Vyhodnocení pilotního projektu a budoucí plány ... 44
Použitá literatura ... 47
Seznam obrázků
Obr. 1 Zjednodušená organizační struktura firmy ... 12
Obr. 2 Road map projektu ... 13
Obr. 3 Přehled KPIs a jejich definice ... 14
Obr. 4 Mockup pravidelného reportu pro management společnosti ... 15
Obr. 5 Mockup přehledu nejdůležitějších KPIs po zákaznících ... 15
Obr. 6 Mockup Automatizování doporučené výše objednávek pro APR zákazníky ... 16
Obr. 7 Mock up detailu prodejů po produktech a prodejnách pro APR ... 16
Obr. 8 Bill Inmon’s Data Warehouse Architecture (Rangarajan, 2018) ... 18
Obr. 9 Ralph Kimball Data Warehouse Architecture (Zentut.com, nedatováno) ... 20
Obr. 10 Architektura nezávislých datových tržišť (Oracle, nedatováno) ... 21
Obr. 11 Architektura závislých datových tržišť (Oracle, nedatováno) ... 22
Obr. 12 Architektura hybridních datových tržišť (Oracle, nedatováno) ... 23
Obr. 13 OLAP kostka (olap.com, 2020) ... 24
Obr. 14 Současná datová „architektura“ ... 26
Obr. 15 Konceptuální model datového skladu ... 29
Obr. 16 Schéma ETL ... 31
Obr. 17 Příklad vstupních dat do transformace T0 ... 32
Obr. 18 Příklad výstupu transformace T0 ... 32
Obr. 19 Logický model DM1 ... 33
Obr. 20 Logický model DM2 ... 34
Obr. 21 Logika produktové hierarchie a kódů ... 35
Obr. 22 Příklad produktové hierarchie ... 36
Obr. 23 Příklad zákaznické hierarchie ... 37
Obr. 24 Příklad upozornění na chybu při transformacích ... 38
Obr. 25 Pravidelný report pro management společnosti ... 40
Obr. 26 Přehled nejdůležitějších KPIs po zákaznících ... 41
Obr. 27 Přehled „per store“ prodejů pro jednotlivé zákazníky po kategoriích ... 42
Obr. 28 Přehled prodejů po kategoriích a obchodech ... 43
Obr. 29 Doporučená výše objednávky ... 43
Obr. 30 Aktualizovaná road map projektu ... 45
9
1 Úvod
Business intelligence (BI) bylo v minulosti doménou hlavně velkých firem, které potřebovaly spravovat velké objemy dat a zároveň byly schopné ufinancovat vysoké počáteční investice do hardwaru i softwaru potřebného k vytvoření efektivního a výkonného BI řešení. V současnosti se BI už netýká jenom velkých firem, ale stále více malých a středních podniků investuje do svých analytických systémů. (Slánský, 2018) Existují pro to dva hlavní důvody:
1) celková digitalizace společnosti. Rok 2020 byl v tomto směru zcela bezprecedentní. Kvůli COVID-19 pandemii a následným opatřením, kdy byl tradiční retail zavřený, došlo k masivnímu přesunu zákazníků do online světa a firmy, které na to byly připraveny, měly obrovskou konkurenční výhodu.
2) počáteční náklady na implementaci BI systémů se výrazně snížily, díky cloudovým řešením, které jsou poskytované jako SaaS (Software as a Sevice) a tím pádem firmy můžou jednoduše nákladovost BI řešení přizpůsobit své velikosti a potřebám.1
Tato práce se věnuje analýze a návrhu BI systému pro firmu Epico International s.r.o., které je implementováno v rámci pilotního projektu v obchodním oddělení firmy.
1.1 Cíle práce
Hlavním cílem této práce je navrhnout nový analytický systém ve společnosti Epico International s.r.o. (dále jen Epico) Tento hlavní cíl je rozdělen na tři dílčí cíle.
▪ Analyzovat současné datové prostředí ve společnosti, nadefinovat business požadavky a potřeby a na jejich základě navrhnout novou datovou architekturu
▪ Vytvořit datový sklad v rámci pilotního projektu a doručit první dashboardy a reporty pro business
▪ Navrhnout další kroky po skončení pilotního projektu
1 V některý případech, jako je například tento pilotní projekt, je možné část analytického systému implementovat v rámci testovacích/neplacených plánů, které jsou některými dodavateli poskytovány a v případě potřeby dále rozšiřovat.
10
1.2 Struktura práce
Práce je rozdělena do dvou hlavních celků. V první části práce (kapitola 2) se věnuji popisu firmy Epico. Je zde popsána firma jako taková, její velikost, organizační struktura a dále zde specifikuji business požadavky na nový analytický systém a hlavní business potřeby.
Třetí kapitola je pomyslně rozdělena na dva části, které na sebe vzájemně odkazují. V první části je popsána teorie datového skladu a všech jeho komponentů a v druhé části se tato teorie aplikuje na firmu Epico a je zde navržena nová podoba analytického systému s podrobným popisem jednotlivých komponent.
Poslední část práce je zaměřena na vyhodnocení pilotního projektu a návrh popilotního rozvoje.
11
2 Business prostředí a Business požadavky
Tato kapitola se věnuje vymezení business prostředí firmy a trhu, na kterém se pohybuje. Dále je zde popsána samotná firma, její velikost, organizační struktura, požadavky na analytický systém a hlavní business potřeby, na které se v práci zaměřím.
2.1 Charakteristika business prostředí
Epico bylo založeno v roce 2014 Martinem Habinou a Romanem Nováčkem s cílem změnit český trh s příslušenstvím pro mobilní telefony. Prvními produkty v portfoliu Epica byly kryty a samolepky na mobilní telefony. Postupně se portfolio rozrostlo na širokou škálu funkčního příslušenství a doplňků, z nichž nejprodávanější produkty jsou nabíječky, power banky a ochranná skla na displeje telefonů (Epico International s.r.o., 2020). Významným úspěchem Epica bylo získání certifikace od společnosti Apple jako oficiálního výrobce příslušenství, které je v nejvyšší kvalitě a plně kompatibilní s jejich produkty.
Epico v rámci Evropy spolupracuje se sítí distributorů a retailových obchodů, sami se nezaměřují na přímý prodej koncovému zákazníkovi, kromě několika obchodních míst v České republice – např. vlastní showroom nebo prodejní stánek v obchodním centru Arkády Pankrác, jejichž příjmy mají však minimální podíl na celkovém obratu firmy.
Za 7 let se zakladatelům Epica podařilo překonat původní plán dobýt trh v České republice a jejich firma nyní vyrábí a dodává příslušenství k mobilním telefonům a počítačům do 18 evropských zemí s vizí stát se do pěti let jedničkou na evropském trhu a rozšířit podnikatelské aktivity na Blízký východ a do Afriky. V roce 2019 byl obrat Epica 185 milionů Kč a v roce 2020 očekávají majitelé nárůst obratu i přes nepříznivou situaci způsobenou uzavíráním trhů kvůli nemoci COVID-19 díky přesunu velké části koncových spotřebitelů na internetové obchody.
V současné době firma zaměstnává přibližně 30 zaměstnanců. Jak je vidět na Obr. 1 organizační struktura firmy je relativně plochá a jednoduchá. Ve firmě existují tři oddělení – marketingové, obchodní a provozní. Součástí provozního oddělení jsou finance, sklad a zákaznické oddělení.
Z výčtu jednotlivých oddělení, resp. pozic je vidět, že v současné době ve firmě neexistuje pozice zaměřená na správu a analýzu dat a každé oddělení si to řeší samo. Což je i jeden z důvodů, proč se vedení firmy rozhodlo zainvestovat do vytvoření jednotného analytického systému.
12 Obr. 1 Zjednodušená organizační struktura firmy
2.2 Specifikace business požadavků na řešení
Jak bylo zmíněno v předchozí kapitole organizační struktura firmy je relativně jednoduchá a plochá a odpovídá její velikosti a fázi životního cyklu, v kterém se nyní nachází. Tím, že je to relativně mladá firma, tak se do této chvíle zaměřovala především na růst a upevnění své pozice na východoevropském trhu, což se jim povedlo a současnosti dodávají zboží předním hráčům s mobilním příslušenstvím na tomto trhu. Právě proto, že v rámci východoevropského trhu už neexistuje mnoho příležitostí, kam dál expandovat, vznikla potřeba zaměřit se na „kvalitativní“
růst obratu, tzn. zjistit, jak je možné zvýšit obrat se stávajícím počtem zákazníků. Jinými slovy zde vznikla potřeba začít analyzovat jednotlivé zákazníky a zjistit, kde jsou ještě příležitosti pro růst a na tu oblast se zaměřit. To je hlavní důvod, proč se vedení firmy rozhodlo zainvestovat do vytvoření analytického systému, který jim a) umožní efektivně vytvářet reporty, díky kterým budou schopni identifikovat tyto příležitosti a b) sníží administrativní zátěž a umožní alokovat ušetřený čas na činnosti s vyšší přidanou hodnotou. (Slánský, 2018)
Před zahájením projektu proběhlo několik rozhovorů s vedením společnosti a business uživateli, s kterými jsme si vytyčili pět základní požadavky na pilotní projekt. Tyto požadavky berou v potaz jednak současnou situaci, kde se firma nachází, ale i pohled do budoucna, kde je zohledněna vize růstu firmy v dalších pěti letech, aby v případě úspěšného pilotního projektu mohl být rozšířen i na další oddělení ve firmě.
13
▪ Pokrytí základních analytických potřeb
▪ Škálovatelnost a s ní spojená dlouhodobá udržitelnost
▪ Nízké pořizovací náklady
▪ Rychlá realizace
▪ Nízké náklady na správu
Vzhledem k výše popsaným požadavkům se pilotní projekt zaměří na oblast obchodu (viz Obr.
1), kde jsme schopní doručit první výsledky/reporty relativně rychle a s nízkými pořizovacími náklady a kde budeme schopni kvantifikovat, jestli doporučení založená na datech mají pozitivní dopad na business. V rámci obchodu bude projekt dále omezen pouze na zákazníky, kteří s Epicem sdílí prodejní data. V rámci těchto zákazníků se bude jednat především o APR (Apple Premium Resellers), kteří jsou pro Epico nejdůležitějšími obchodními partnery. Dalším důvodem, proč jsme se rozhodli „vyzkoušet“ projekt na obchodním týmu je ten, že obchodní tým má největší zkušenosti s analýzou dat a sami cítí potřebu vylepšení současného způsobu tvorby reportů.
Obr. 2 Road map projektu
Zvolili jsme si čtyři business potřeby, na které se v rámci pilotního projektu zaměříme:
▪ Pravidelný report pro management společnosti
▪ Přehled nejdůležitějších KPIs po zákaznících
▪ Automatizování doporučené výše objednávek pro APR zákazníky
▪ Detail prodejů po produktech a prodejnách pro APR
14
2.2.1 Návrhy a popis dashboardů a reportů
Vedle samotných dashboardů a reportů byl vytvořen přehled používaných KPIs s jejich definicí, zdrojem, výskytem a v případně počítaných metrik s detailem výpočtu (viz Obr. 3).
Kvůli přehlednosti je detail výpočtu v Obr. 3 vynechán.
Obr. 3 Přehled KPIs a jejich definice
1) Pravidelný report pro management společnosti. Mělo by se jednat o jednostránkový dashboard s klíčovými ukazateli přes všechny zákazníky s možností vyfiltrovat si jednotlivé zákazníky nebo produkty. Účelem toho dashboardu je poskytnout managementu společnosti ucelený pohled na obrat firmy.
15
Obr. 4 Mockup pravidelného reportu pro management společnosti
2) Přehled nejdůležitějších KPIs po zákaznících. Dynamický jednostránkový dashboard s klíčovými ukazateli, kde bude možné filtrovat jednotlivé zákazníky, produkty, obchody, časový interval a tzv. core products (jedná se o subset nejdůležitějších produktů). Účelem tohoto dashboardu je poskytnout obchodnímu týmu nástroj k rychlému analyzování výkonosti jednotlivých zákazníků.
Obr. 5 Mockup přehledu nejdůležitějších KPIs po zákaznících
16
3) Automatizování doporučené výše objednávek pro APR zákazníky. Jedná se o zautomatizování reportu, který existoval v Google docs. Je určený pro jednotlivé zákazníky, kteří ho používají jako podklad pro objednávky.
Obr. 6 Mockup Automatizování doporučené výše objednávek pro APR zákazníky
4) Detail prodejů po produktech a prodejnách pro APR. Cílem reportu je za prvé identifikovat v rámci sítě obchodů ty obchody, které mají podprůměrné prodejte v dané kategorii, a za druhé nasdílet tyto informace se zákazníky, abychom se společně mohli zaměřit na podprůměrné prodejny, zjistit, proč mají podprůměrný obrat a v nejlepším případě navrhnout řešení, jak obrat zvýšit.
Obr. 7 Mock up detailu prodejů po produktech a prodejnách pro APR
17
3 Analýza a návrh řešení projektu
V úvodní části této kapitoly jsou představeny dva přístupy k architektuře datového skladu.
Prvním přístupem je Inmonova teorie datového skladu a jako druhý přístup je Kimballův model.
Dále jsou podrobně popsány jednotlivé komponenty DWH – ETL, DSA, datová tržiště, reportingová vrstva, master data management a data quality management. Přístupy a komponenty poslouží k návrhu řešení projektu.
Dále je popsán současný stav analytického prostředí ve firmě a následuje podkapitola zabývající se návrhem datové architektury, kde je na základě teorie, současného stavu a business požadavků popsáno navržené řešení.
3.1 Teorie datového skladu
V této části práce jsou popsány různé teoretické a technické přístupy ke stavbě datového skladu, na základě kterých je v další části práce vybráno nejlepší řešení pro firmu Epico vzhledem k jejich business požadavkům, organizační struktuře a celkové velikosti firmy.
Existují dvě hlavní teorie architektury datového skladu – Inmonova metoda a Kimballova metoda. Pro obě dvě metody je stěžejní jednotkou podnikové datové architektury datový sklad (DWH), ale liší se v přístupu, jak jsou jednotlivé komponenty DWH modelovány a jaké mezi sebou mají vztahy.
Podle Inmona je DWH centralizované uložiště dat pro celou organizaci tzn. „single point of truth“, z kterého čerpají všechny další komponenty analytického systému. Hlavními vlastnostmi Inmonova DWH je subjektová orientace, integrovanost a neměnnost v čase.
Subjektová orientace znamená zaměření na určitou oblast, kterou může být např. produkt, zákazník, dodavatel apod. Integrovanost znamená, že data z různých systémů jsou transformována a nahrána do jednoho skladu. Neměnnost v čase znamená, že na rozdíl od transakčních systémů se data v DWH už po nahrání nemění (Inmon, 2002).
Tím, že do DWH jsou nahrávána data ze všech relevantních transakčních systémů, je důležité, aby byla minimalizována redundance dat, a tím se zároveň optimalizovala celková velikost DWH. Proto DWH podle Inmona využívá k modelování datových struktur snowflake schéma.
Výhody Inmonova přístupu (Naeem, 2020):
▪ Datový sklad je „single point of truth“, protože obsahuje všechna data z celého podniku
18
▪ Nízká redundance dat a díky tomu je menší pravděpodobnost vzniku nesrovnalostí během nahrávání dat. A to dělá ETL proces jednodušší a méně náchylný k selhání
▪ Je snazší aktualizovat datový sklad v případě, že dojde ke změně business potřeby nebo zdrojových dat.
▪ Možnost vytvoření reportingu přes celou společnost a jednodušší propojování dat z jednotlivých oddělení
Nevýhody Inmonova přístupu (Naeem, 2020)
▪ S narůstajícím počtem tabulek v datovém modelu narůstá celková komplexita datového skladu
▪ Vyšší nároky na dovednosti datového týmu
▪ Počáteční rollout je časově náročnější a nákladnější
▪ Jsou potřeba další ETL na plnění jednotlivých datových tržišť z datového skladu
Obr. 8 Bill Inmon’s Data Warehouse Architecture (Rangarajan, 2018)
Kimball, na rozdíl od Inmona, používá bottom-up přístup, kdy místo jednoho centralizovaného uložiště pro celý podnik, navrhuje použít různá datová tržiště pro různé business procesy/potřeby. A právě z tohoto vychází největší rozdíl oproti Inmonově modelu a to, že
19
Kimballův model je dimenzionální – není normalizovaný a základní koncept modelování je Star schéma. Dalším klíčovou součástí je Data warehouse bus, který zajišťuje, že jednotlivá datová tržiště používají standardizované dimenze (Breslin, 2014). Z Kimballova modelu vychází architektura nezávislých datových tržišť (viz Architektura datových tržišť).
Výhody Kimballova přístupu (Naeem, 2020):
▪ Model je denormalizovaný a díky tomu je první část implementace datového skladu rychlá a relativně nenákladná
▪ Star schéma je srozumitelné pro business uživatele, a protože má denormalizovanou formu, tak i vytváření dotazů a samotná analýza je jednodušší
▪ Model datového skladu je jednodušší, protože se zaměřuje na jednotlivá oddělení a procesy, místo na celý podnik. A tím pádem je i jednodušší jeho údržba
▪ Na správu datového skladu stačí menší tým developerů Nevýhody Kimballova přístupu (Naeem, 2020):
▪ Neexistuje „single point of truth“ a proto může dojít k tomu, že data v jednotlivých datových tržištích jsou různá
▪ Integrace starých systému (legacy systems) může být komplikovaná
▪ Náročná změna DWH při změně business potřeby nebo zdrojových dat. Přidání nových sloupců do faktových tabulek může způsobit problém s výkonem. To je dané tím, že faktové tabulky jsou velmi rozsáhlé a při přidání nového sloupce dojde k výraznému růstu její velikosti v databází a snížení výkonu.
▪ Není možné vytvořit ucelenou reportingovou vrstvu přes celý podnik
20
Obr. 9 Ralph Kimball Data Warehouse Architecture (Zentut.com, nedatováno)
3.1.1 ETL (Extract, Transform, Load) alias Datové pumpy
ETL je komponenta datové architektury, která má za úkol extrahovat, pozměnit a nahrát data ze zdrojových systémů buď do jednotlivých datových tržišť (viz Kimball) nebo do EDW (viz Inmon). V současné době se ETL nástroje vyvinuly do takové podoby, že už nejsou používány jenom pro svůj původní účel, ale dají se využít i na zajištění datové kvality a bezpečnosti (Slánský, 2018).
▪ Extract je první komponenta ETL, která má za úkol přesunout data ze zdrojových systému do DSA.
▪ Transform je v pořadí druhý krok ETL. Během tohoto procesu dojde k pozměnění dat nahraných do DSA. Mezi základní transformace patří: změna názvů sloupců, změna datových typů, rozsekání (parsing) textových souborů, sjednocení měrných jednotek, přidání time-stamp atd. Krok transformace má za úkol také zabezpečit datovou integritu v datovém skladu.
▪ Load je poslední krok ETL, kdy se transformovaná data fyzicky nahrají do datového skladu/tržiště.
21
3.1.2 Data staging area (DSA)
DSA je uložiště, které slouží k dočasnému uložení dat nahraných ze zdrojových systémů. Pro data v DSA je charakteristické (Slánský, 2018):
▪ Jedná se o tzv. jedna ku jedné kopii dat ze zdrojových systému – data nejsou nijak transformována, obohacena či jinak pozměněna
▪ není zaručena jejich kvalita
▪ jsou dočasná – po zpracování jsou přehrána novými daty
3.1.3
Datová tržiště (Data Marts, DM)
Datová tržiště jsou komponenty datového skladu, které obsahují data vztahující se k určitému problému či oddělení. Existují dva hlavní přístupy k architektuře datových tržišť – architektura nezávislých datových tržišť a architektura závislých datových tržišť, kde každý vychází z jiného pohledu na architekturu datového skladu.
V případě nezávislých datových tržišť jsou jednotlivá datová tržiště plněna daty přímo z dočasného uložiště integrační vrstvy. Jednotlivá datová tržiště, která dohromady tvoří datový sklad, jsou na sobě nezávislá a mohou existovat samostatně (Slánský, 2018). Výhodou toho přístupu je především rychlost, nenáročnost implementace a relativně snadná rozšiřitelnost. Na druhou stranu velkou nevýhodou této architektury je fakt, že jednotlivá datová tržiště jsou na sobě nezávislá, takže zde hrozí riziko vzniku nejednotné reportingové vrstvy, a s tím spojené riziko rozdílného reportování skutečnosti.
Obr. 10 Architektura nezávislých datových tržišť (Oracle, nedatováno)
22
U architektury závislých datových tržišť jsou jednotlivá datová tržiště plněna daty z podnikového datového skladu (Enterprice Data Warehouse – EDW) a jednotlivá datová tržiště mohou být na sobě vzájemně závislá. Mezi hlavní výhody této architektury patří centralizace všech dat v jedné „core“ databázi a vystavení jednotlivých datových tržišť na stejných vstupních datech, čímž se snižuje riziko rozdílné interpretace skutečnosti a je jednodušší docílit jednotné reportingové vrstvy. Tato architektura se v posledních letech stala standardem pro architekturu datového skladu (Slánský, 2018).
Obr. 11 Architektura závislých datových tržišť (Oracle, nedatováno)
Jako poslední architektura, kterou zde zmíním, je hybridní architektura datového tržiště, která spojuje oba přístupy. Je založena na závislých datových tržištích, ale specifická datová tržiště mohou být plněna daty z jiných zdrojů než z EDW. Hlavní výhodou této architektury je relativní rychlost a snadnost rozšíření o další datové zdroje, protože mohou být nahrána přímo do jednotlivých tržišť. Toho se hlavně využívá v případě, když je zapotřebí ad hoc integrace nových dat, která nejsou dostupná v EDW. Nevýhody toho přístupu jsou stejné jako v případě nezávislých datových tržišť (Oracle, nedatováno).
23
Obr. 12 Architektura hybridních datových tržišť (Oracle, nedatováno)
3.1.4 Reportingová vrstva
Poslední vrstvou datové architektury je reportingová vrstva, která je z pohledu business uživatelů určitě ta nejdůležitější, protože právě zde nalezne management odpovědi na business otázky a business potřeby. Ačkoliv existuje více komponent reportingové vrstvy, zmíním pouze dvě nejvíce používané, a to OLAP a vizualizaci dat.
OLAP (online analytical processing) je na rozdíl od klasické relační databáze multidimenzionální a obsahuje již předpočítaná a agregovaná data. Díky tomu je práce s OLAP kostkou rychlejší a umožnuje větší flexibilitu při různých pohledech na data, např. je možné porovnávat prodeje po produktech přes různé lokace nebo zákazníky v různých časových intervalech (Slánský, 2018).
24 Obr. 13 OLAP kostka (olap.com, 2020)
Vizualizace dat je grafická prezentace dat pro potřeby koncových uživatelů, aby se na jejich základě mohli rozhodovat. Základní dělení vizualizačních nástrojů je na reporty a dashboardy.
Reporty se zaměřují na specifickou oblast podniku např. prodeje a jdou do většího detailu než dashboardy. Dashboardy obsahují hlavní KPIs, které jsou většinou agregované do jednoho místa, aby bylo možné odhalit trendy rychle a na první pohled. Dashboardy také bývají většinou dynamické (Slánský, 2018).
Na trhu existuje mnoho vizualizačních nástrojů, proto zde zmíním jen ty nejrozšířenější, a to jsou Power BI, Tableau a Qlik Sense. (Gartner, 2020)
3.1.5 Master data management
Master data management má na starost, aby klíčová data podniku byla vždy aktuální a správná.
(Slánský, 2018) Master data dávají kontext transakčním datům. Na správu master dat existuje celá řada nástrojů. Mezi hlavní dodavatele patří Informatica, TIBCO Software, SAP, IBM atd.
(Gartner, 2020)
25
3.1.6 Data quality management
Řízení datové kvality je jedna ze stěžejních oblastí celého datového ekosystému a bezesporu nesmí být opomenuta. Tradičně byla kontrola datové kvality spojena s integrační vrstvou, ale v posledních letech její důležitost stoupá, a to z toho důvodu, že nízká datová kvalita je jeden z velkých problémů, který řeší téměř všechny společnosti.
Datová kvalita je důležitá nejen z čistě analytického pohledu, abychom byli schopní dodat relevantní doporučení, ale také z pohledu úspěšnosti implementace datové infrastruktury a změny uvažování koncových uživatelů. Pokud nejsme schopni zajistit dostatečnou kvalitu dat, koncoví uživatele nebudou analytickým výstupům věřit a budu se i nadále spoléhat na svoji zkušenost a intuici a celý projekt je odsouzen k zániku.
Pokud se bavíme o tom, co jsou kvalitní data, neexistuje přesně daná definice. Pragmatický přístup by byl, že data jsou dostačující kvality, pokud jsou koncoví uživatelé spokojení.
Pomineme-li tento pragmatický pohled, tak datová kvalita se dá definovat následovně (Slánský, 2018):
▪ Včasnost – data jsou dostupná v požadovaný čas
▪ Dostupnost – data jsou dostupná pro koncové uživatele
▪ Užitečnost – data mají business využití
▪ Integrita – data nebyla pozměněna
▪ Konzistence – data si vzájemně neodporují
▪ Přesnost – data přesně popisují aktuální stav
▪ Aktuálnost – data odráží aktuální stav
▪ Kompletnost – nechybí žádná užitečná data
Tak jako v případě master data managementu, tak i pro data quality management existuje celá řada nástrojů zaměřující se na tuto oblast. Mezi hlavní dodavatele patří IBM, Informatika, SAP, SAS, Attaccama, atd. (Gartner, 2020)
26
3.2 Popis aktuálního stavu analytického systémů v Epico s.r.o.
Tak jako v mnoha firmách, i v Epicu je celý analytický systém postaven v excelu, resp. v tomto případě dokonce v Google docs. Jedná se o komplexní systém propojených tabulek, které jsou dále napojené na jednotlivé reporty. Zdrojová data pocházejí z:
▪ interního ERP systému, jedná se o transakční a master data
▪ interní data v Google docs, jedná se především o obchodní a finanční plány a minimální výše skladových zásob a minimální výše objednávky u jednotlivých zákazníků
▪ externí data v Google docs, obsahující týdenní sell-out a výši skladových zásob Tyto data jsou v Google docs konsolidována a propojena pomocí základních excelovských funkcí a dále používána pro jednotlivé reporty, kde dochází k napočítávání jednotlivých metrik.
Celý systém je vyobrazen na Obr. 14. Z pohledu objemu dat se jedná o nižší stovky MB dat, takže hlavní problém není ve výkonu, ale spíš v komplexnosti a chybovosti celého prostředí.
Obr. 14 Současná datová „architektura“
Co se týká datové maturity firmy, tak se nachází nízké úrovni. Ve firmě neexistuje žádný jednotný analytický systém. Každé oddělení má své vlastní reporty se svými vlastními metrikami, jejichž definice není vždy sjednocena napříč firmou. Jedná se o cca 15 různých reportů, a přestože jsou mezi nimi lehké nuance, nemá to žádný negativní business dopad. Jak již bylo řečeno, reporty jsou postavené v Google docs, takže se jedná o poměrně jednoduché tabulky, které se musí každý týden manuálně aktualizovat. Tým stráví cca 1 pracovní den týdně aktualizací a kontrolou jednotlivých reportů. Vedle velké manuální zátěže je zde také problém
27
s datovou kvalitou, často se stává, že propojení jednotlivých tabulek jsou poškozena a v lepším případě se na to přijde hned, v tom horším se to zjistí zpětně a musí se opravovat celá historie.
Ze vstupní analýzy se také ukázalo, že Epico má problém s kvalitou master dat. V případě produktových master dat neexistuje standardizované kódování a pojmenování produktů a existují duplicitní záznamy – stejný produkt je v databázi vícekrát, ale pokaždé s odlišným jménem a cenou. Dále jsme identifikovali potřebu vytvořit produktovou hierarchii, která roztřídí produkty nejenom podle kategorií, ale také podle toho, jestli jsou Private label (produkty, které jsou obrandované logy jednotlivých zákazníků, např iWant) nebo ne, a bude mít další úroveň mezi kategorií a SKU, která bude obsahovat všechny SKU patřící do jedné produktové řady. Kvalita zákaznických dat je relativně dobrá a v rámci projektu bude vytvořena pouze nová zákaznická hierarchie, která umožní lépe analyzovat prodeje.
Dále je důležité poznamenat, že na podzim roku 2019 Epico přešlo na nový ERP systém a při auditu kvality historických dat starého ERP systému bylo zjištěno, že vyčištění a úprava dat by byla relativně náročná a nákladná bez velké přidané hodnoty pro business. Proto bylo rozhodnuto, že do nového datového skladu budou nahrány jenom data od ledna 2020. To nás samozřejmě omezuje v tom, že v rámci pilotního projektu nelze zobrazovat meziroční evoluce.
3.3 Návrh datové architektury pro Epico s.r.o.
Než přistoupím k popisu zvolené datové architektury pro firmu Epico, považuji za důležité zmínit, že celkový přístup k projektu a obecně celé architektuře je založen na tzv. principu
„Think big, start small, scale up“.
Hlavní faktory zohledněné při výběru a návrhu řešení jsou
▪ Velikost firmy a s tím spojená organizační struktura
▪ Business prostředí
▪ Business požadavky
▪ Datová maturita firmy
▪ Objem a typ dat
▪ Budoucí rozvoj firmy
Pokud bychom se měli rozhodnout na základě současného stavu firmy, s největší pravděpodobností bychom vybrali Kimballův model DWH a model nezávislých datových tržišť. Protože hlavními výhodami tohoto modelu jsou relativně rychlá a nenakládá realizace, model je pochopitelnější pro business uživatele, protože je jednodušší, a tím pádem je i
28
jednodušší na údržbu. I přes tyto výhody Kimballova modelu jsem se nakonec rozhodli pro Inmovům přístup modelování datového skladu, který lépe odpovídá business požadavkům firmy a její vizi do budoucna (viz kapitola 3.1 Teorie datového skladu). Abych shrnul hlavní důvody, proč jsme se rozhodli pro toto řešení:
▪ Škálovatelnost – vzhledem ke stáří firmy a budoucí vizi managementu byl velký důraz kladem právě na jednoduchost rozšiřování DWH
▪ Single point of truth
▪ Udržitelnost datové kvality napříč celým datových skladem – data se vyčistí jen jednou na vstupu
▪ Finanční a časová náročnost obou přístupů je vzhledem k velikosti firmy a množství dat stejná
▪ Nižší náročnost na implementace změn do DWH
Celé řešení DWH je postavené na platformě Keboola, a to z následujících důvodů:
▪ Dobrá zkušenost a vztahy jednoho z majitelů s firmou Keboola
▪ Jedná se o cloudové řešení, které je jednoduše škálovatelné
▪ Jednoduché uživatelské prostředí – základní údržba a administrace jde zvládnout i bez znalostí programovacích jazyků
▪ Jednoduché napojení na externí zdroje přes na nativní Keboola extraktory
▪ Se současným objemem dat a celkovým měsíčním run-time se vejdeme do Keboola free plan2.
2 V rámci Keboola free plánů je zdarma poskytováno uložiště do 250 GB, 300 minut run-time za měsíc a přístup k základním funkcím, které zahrnují např. SQL, Phyton transformace, zautomatizování orchestrací a přístup k nativním Keboola extraktorům (Keboola, 2020). Epico v rámci pilotního projektu využívá cca 100 MB a 120 minut run-time za měsíc, takže se dá předpokládat, že i v rámci popilotního rozvoje se stále vejdeme do limitů free plánu.
29 Obr. 15 Konceptuální model datového skladu
3.3.1 Datové zdroje
Do datového skladu vstupují data ze dvou hlavních datových zdrojů – interní ERP systém K2 a externí data sdílená obchodními partnery přes Google docs.
Data z ERP systému se nahrávají do DSA s týdenní frekvencí ve formátu JSON, kde jsou dále upravena pomocí jednotlivých stupňů transformací (viz ETL). Jedná se o master a referenční data, počet produktů dodaných zákazníkům v rámci komisního prodeje, zboží v transitu a výši skladu Epica.
30 Tabulka 1 Přehled importovaných interních dat z K2
Co se týká externích dat, tak se jedná o týdenní sell-out data a skladové zásoby jednotlivých zákazníků. Externí data jsou také aktualizována a nahrávána do DSA týdně. Struktura dat od jednotlivých zákazníků je různá a musí být v rámci transformací standardizována (viz ETL).
Tabulka 2 Příklad struktury externích dat.
Název tabulky Popis dat
Customers
Zákaznická master data
(TaxIDNo, IDNo, CompanyName, Abbr1, CustomerId, Country_CountryId, ProductGroup_Abbr)
Products
Produktová master data
(TradeMark, Name, Abbr1, ArticleId, DStockPriceCalc, DefaultEANCalc, ProductGroup_Id, ProductGroup_Abbr, Name_Eng)
Retail_prices
Doporučené prodejní ceny pro zákazníky
(PriceList_RID, Priority, CurrencyCode, DOClassName, PriceGross, PriceNet, Zbo_Name, Zbo_Abbr1, Zbo_ArticleId, Zbo_ArticleId, RecordID)
Wholesale_prices
Nákupní ceny pro zákazníky
(PriceList_RID, Priority, CurrencyCode, DOClassName, PriceGross, PriceNet, Zbo_Name, Zbo_Abbr1, Zbo_ArticleId, Zbo_ArticleId, RecordID)
GoodsOnWay
Zboží v transitu mezi Epico a zákazník
(CustomerId, CustomerName, DeliveryAddress, Abbr1, Qty, Store)
StockConsigment
Výše skladu v kusech u jednolivých zákazníků (AvailableUMCalc, WarehouseId2, CompanyName, CustomerId, ZboAbbr1)
StockEpico
Výše skladu v kusech sklad Epico
(Abbr1, EX_DispNakBezVyr, EX_DispBezBlokVyr, EX_DispVyr, ReservedUMCalc, OrderedPurchCalc,
ArticleCategory_LangTxtCalc)
K2
Název tabulky Popis dat
Customer 1
Týdenní sell out a skladové zásoby zákazníka 1
(Country, Store, Itemnumber, SoldUn, StockUn, WeekNo, Week start)
Google docs
31
3.3.2 ETL
Extract z K2 je vyřešený pomocí API rozhraní a import dat z Google docs běží přes nativní Keboola extraktory. Vždy se nahrávají všechna data (full load) nikoliv pouze inkrementální.
Transformace jsou rozděleny od čtyř úrovní – T0, T1, T2 a T3. Na úrovni T0 se transformují data do tabulární struktury. T1 archivuje, čistí a obohacuje data o time stamp. T2 aktualizuje data v DWH. T3 nahraje data do jednotlivých datových tržišť. Pro T0 je použitý Python a pro T1-T3 je použitý jazyk SQL.
Obr. 16 Schéma ETL
Popis jednotlivých transformací, které jsou zobrazeny na Obr. 16:
▪ T0 – K2 parsing: parsing exportů z K2, které jsou ve formátu JSON (Obr. 17), a jejich následné uložení do tabulkové struktury (Obr. 18)
▪ T1.1 – Historizace a aktualizace číselníků z K2: porovná záznamy v DWH se záznamy v DSA pro tabulky číselníků a pokud najde aktualizovaný záznam, tak ho přidá do dané tabulky v DWH s aktuální datumem. Transformace probíhá pro tabulky Customers, Products, Retail_prices a Wholesale_prices.
▪ T1.2 – Archivace a čištění zákaznických dat: zde probíhá spojování aktuálních týdenních sell-out dat s historickými, čištění struktury, datových typů a archivace dat.
▪ T2.1 – Vytvoření aktuálních master dat: přejmenuje sloupce a vybere nejnovější záznam z tabulek upravených v T1.1.
32
▪ T2.2 – Zboží na cestě, Min stock: seskupuje jednotlivé záznamy na úroveň obchodů, když není obchod na úroveň zákazníků a filtruje jenom APR obchody/zákazníky, přejmenuje názvy sloupců v tabulce minstock-minorder- customer, minstock-minorder-store a GoodsOnWay
▪ T2.3 – Standardizace zákaznických dat: u jednotlivých tabulek od zákazníků dochází k přejmenování názvů sloupců, přidání sloupce „rok“, „customer id“ a
„date_to (konec retailového týdne)“ a sjednocení reportovaných čísel na stejné jednotky.
▪ T3.1 – Vytvoření datového tržiště 1
▪ T3.2 – Vytvoření datového tržiště 2
Obr. 17 Příklad vstupních dat do transformace T0
Obr. 18 Příklad výstupu transformace T0
33
3.3.3 Datová tržiště
V pilotní fázi projektu jsem se rozhodl pro tvorbu dvou datových tržišť, aby bylo sníženo riziko úniku citlivých dat, protože jak bylo zmíněno v kapitole 2.1.1 některé reporty jsou sdíleny se zákazníky. Reporty a dashboardy vytvořené nad DM1 jsou pouze pro interní účely, zato ty postavené nad DM2 jsou určeny i pro zákazníky.
DM 1 obsahuje data o prodejích po zákaznících, prodejní ceny, doporučené maloobchodní ceny a náklady na prodané zboží (COGS). Do budoucna by mělo také obsahovat cíle pro jednotlivé obchody/zákazníky, aby se mohlo vyhodnocovat plnění vůči cílům. Vzhledem k současné situaci kolem vývoje COVID-19 a přitvrzujících opatření, kdy se jakékoliv cíle stávají bezpředmětnými, jsme se rozhodli posunout implementaci cílů do DM1 na Q1 2021.
Obr. 19 Logický model DM1
Výstupy postavené nad DM2 jsou určené pro zákazníky a jsou s nimi pravidelně sdíleny, právě proto DM2 neobsahuje COGS, cíle a prodejní ceny, abych snížil riziko úniku těchto informací k našim zákazníkům. Na rozdíl od DM1 obsahuje informace o minimálních výši skladových zásob a minimální výši objednávky.
34 Obr. 20 Logický model DM2
3.3.4 Master data management
Vzhledem k velikosti a organizační struktuře nebude master data management v případě společnosti Epico řešený žádným z nástrojů popsaných v teoretické části, ale jako nejvhodnější řešení bylo zvoleno vytvoření směrnice, která popisuje, jak postupovat při vytváření nových produktů a zákazníků. Zákaznická a produktová master data se i nadále budou spravovat a ukládat v ERP systému.
Jak bylo popsáno ve vstupní analýze k pilotnímu projektu kvalita produktových master dat je v současnosti nízká a oprava přímo v ERP je nad rámec pilotního projektu. Proto jsme se rozhodli upravit produktová master data v excelu a nahrát je jednorázově přímo do DWH. Toto zjednodušení se týká pouze pilotního projektu. Vyčištění produktových master dat v ERP je plánováno na Q1/2021 (viz kapitola Vyhodnocení pilotního projektu a budoucí plány).
Produktová master data
V rámci úpravy produktových master dat do podoby specifikované v nové směrnici byly provedeny tyto změny:
35
▪ Přidání sloupců, které budou obsahovat informace, které byly doposud obsaženy pouze v názvu SKU – Manufacturer, Type/verison, Bulk, with warranty a Color.
▪ Přidání úrovně Product, která konsoliduje všechny SKU patřící do jedné produktové řady, např. CANDY SILICON CASE, aby bylo možné vytvořit TOP 10 nejprodávanějších produktů do zákaznického reportu.
▪ Vznik třech nových číselníků pro Private label, Category a Product.
▪ Vytvoření produktové hierarchie, viz Obr. 22
▪ Standardizování produktových kódů a pojmenování, viz Obr. 21
Obr. 21 Logika produktové hierarchie a kódů
36 Obr. 22 Příklad produktové hierarchie
Zákaznická master data
Stejně jako u produktových master dat, tak i u zákaznických dat byla vytvořena hierarchie, která konsoliduje zákazníky patřící do stejného kanálu/skupiny. Zákaznická hierarchie má čtyři úrovně L1, L2, L3 a L4. Na úrovni L1 se zákazníci dělí na dva kanály – B2B a B2C. L2 popisuje skupinu zákazníků – Apple Premium Resellers (APR), E-commerce, ostatní a Epico retail. L3 je úroveň jednotlivých zákazníků a na L4 jsou rozlišené jednotlivé ship-to resp. obchody.
37 Obr. 23 Příklad zákaznické hierarchie
3.3.5 Datová kvalita
Datovou kvalitu sledujeme jak na vstupu v rámci jednotlivých transformací, tak přímo i v DWH pomocí dedikovaných reportů.
Sledováním datové kvality na vstupu je myšleno sledování jednotlivých orchestrací přímo v Keboole, jestli všechny automatizované úkoly v rámci orchestrace3 proběhly úspěšně.
V případě nějaké z níže popsaných událostí je automaticky odeslána notifikace na email s popisem problému a odkazem na detail v Keboolu.
3 Orchestrací se v Keboola prostředí myslí složení několika úkolů do jednoho celku, který má přesně dané pořadí, v kterém jsou jednotlivé úkoly vykonávány. Druhou vlastností orchestrace je možnosti nastavení automatizace a opakování.
38
▪ Chyba – orchestrace se dokončila, ale jeden nebo více úkolů v rámci orchestrace selhal
▪ Varování – orchestrace se dokončila, ale jeden nebo více úkolů v rámci orchestrace selhal
▪ Podezřele dlouhý čas procesování – dokončení jednoho nebo více úkolů trvalo o x% déle než obvykle
Obr. 24 Příklad upozornění na chybu při transformacích
Upozornění z Kebooly ale odhalí pouze technické problémy, a to především zdali byly všechny vstupní zdroje správně naimportovány, transformovány a zapsány do DWH, ale nezjistíme, jestli zapsaná data jsou správná. Jinými slovy nezjistíme, jestli náš zákazník odreportoval správná data. K této kontrole dochází až v DWH, a to pomocí dedikovaných reportů vytvořených v Tableau. V těchto reportech například sledujeme chybějící data za aktuální týden, jestli zákazník neodreportoval stejná data jako minulý týden, crosscheck SKU kódů v datech od zákazníků s našimi master daty. Z pohledu našich interních dat kontrolujeme, především jestli neexistují duplicity v master datech.
3.3.6 Reportingová vrstva
Poslední vrstvou architektury datového skladu je reportingová vrstva, která je z pohledu businessu a businessových uživatelů tou nejdůležitější komponentou. Zde dochází k vizualizaci dat, zasazení dat do kontextu a vytvoření příběhu, co nám data říkají. Jak bylo zmíněno v rámci teoretické části práce na trhu existuje mnoho nástrojů používaných k vizualizaci dat. V Epicu jsme se rozhodovali mezi softwarem Tableau a Power BI, které jsou nejrozšířenější. Oba
39
nástroje mají ve své podstatě stejné funkce, hlavní rozdíl pro firmu jako je Epico, je v rozdílné cenové strategii.
Základní verze Power BI Desktop je nabízená zdarma, ale její největší omezení je, že nepodporuje sdílení vytvořených dashboardu s ostatními uživateli. Vyšší verze Power BI Pro stojí 10USD/licence za měsíc, tato verze už podporuje sdílení reportů a dashboardů. Cena nejvyšší verze Power BI premium začíná na cca 5000USD a je pro potřeby Epica zbytečná (MS Power BI pricing, 2020).
Co se týká cenové strategie Tableau, tak Tableau nenabízí free verzi a místo toho nabízí tři různé verze Tableau – Creator, Explorer a Viewer. Creator je plná licence se všemi funkcionalitami a náklady na ní jsou 70USD/měsíc/licence. Explorer je osekaná verze Creatoru, uživatel nemá možnost publikovat vytvořené reporty a dashboardy a neobsahuje Tableau Desktop a Tableau Prep builder. Cena Tableau Explorer je 35USD/měsíc/licence, ale minimální objednávka je 5 licencí. Poslední nabízenou verzí je Tableau Viewer, jehož cena je 12USD/měsíc/licence a minimální počet zakoupených licencí je 100. Tato verze, jak název napovídá, má jen read only přístup, k již vytvořeným reportům a dashboardům (Tableau Pricing, 2020).
I přes vyšší pořizovací náklady jsme se rozhodli k vizualizaci dat používat Tableau.4 Byla zakoupena jedna licence pro vybraného člena obchodního týmů, který vytvořené dashboardy a reporty pravidelně sdílí s ostatními zaměstnanci. V rámci popilotního rozšiřování na další oddělení se bude muset zvolený přístup přehodnotit a rozšířit počet zakoupených licencí.
V rámci reportingové vrstvy existují dvě oddělená prostředí. První obsahuje pravidelné, předem definované reporty a dashboardy, konktrétně se jedná o všechny reporty a dashboardy popsané v této práci. Tyto reporty/dashboardy jsou publikované do Tableau serveru a koncoví uživatelé by neměli mít možnost je měnit. Druhá vrstva je tzv. self-service, kde koncoví uživatelé mohou vytvářet vlastní analýzy, obohacovat data o nové datové zdroje a vytvářet nové reporty a dashboardy. Pokud se ukáže, že reporty vytvořené v rámci self-service jsou z dlouhodobého hlediska užitečné a že by se měly stát součástí pravidelných reportů, tak dojde k jejich přesunu do složky pravidelných reportů. V případě, že byly použity externí datové zdroje, tak budou tato data přidána do DWH.
Příklady jednotlivých dashboardů a reportů
Cílem pilotního projektu bylo vedle návrhu a implementace datové architektury vytvořit reporty, které budou odpovědí na business potřeby definované managementem společnosti,
4 Jak jsem již zmínil, co se funkcionality týká, tak pro firmu typu Epica není mezi Power BI a Tableau ve své podstatě rozdíl. Hlavním důvodem pro upřednostnění Tableau před Power BI byla čistě preference dodavatele, resp. averze jednoho z majitelů k Microsoft.
40
které byly popsány v rámci kapitoly Specifikace business požadavků na řešení. Pro připomenutí se jednalo o
▪ Pravidelný report pro management společnosti
▪ Přehled nejdůležitějších KPIs po zákaznících
▪ Automatizování doporučené výše objednávek pro APR zákazníky
▪ Detail prodejů po produktech a prodejnách pro APR
Dashboard 1: Pravidelný dashboard pro management společnosti
Jedná se o pravidelný report určený pro management společnosti, který obsahuje YTD hodnoty hlavních KPIs – čistý obrat, prodané kusy, marži, stock coverage zákazníků, počet zákazníků a počet obchodů. Celý dashboard je dynamický, tzn. že jednotlivá pole mohou být kliknutím použita jako filtry. Data se dají dále filtrovat pomocí klasických filtrů, a to podle zákazníků, zákaznické hierarchie, produktové hierarchie a také je možné vyfiltrovat prodeje za posledních 6 týdnů (jedná se o business pravidlo). Barvy jednotlivých polí v treemap grafu a sloupců u sloupcových grafů znázorňují procentuální výši marže – čím tmavší barva tím výší marže a naopak.
Obr. 25 Pravidelný report pro management společnosti
41
Dashboard 2: Přehled nejdůležitějších KPIs po zákaznících
Tento dashboard přehledně zobrazuje nejdůležitější KPIs pro jednotlivé zákazníky – čistý obrat, prodané kusy, marži, stock coverage zákazníků a počet obchodů. Ve střední části dashboardu jsou spojnicové grafy zobrazující vývoj prodejů a marže v čase. Ve spodní části se nachází přehled TOP 10 produktů v rámci jednotlivých kategorií a detail prodejů v hodnotě po zemích a obchodech. Stejně jako u předchozího dashboardu, tak i tento je dynamický a jednotlivá pole se dají použít jako filtry. Dále se dají hodnoty filtrovat podle zákazníků, zákaznické hierarchie, produktové hierarchie, obchodu, času (měsíce a týdny), Core products (jedná se předem nadefinovaný subset nejdůležitějších produktů) a i zde je možnost zobrazit pouze prodeje za posledních 6 týdnů.
Obr. 26 Přehled nejdůležitějších KPIs po zákaznících
Report 3: Detail prodejů po produktech a prodejnách pro APR
První report srovnává YTD per store prodeje jednoho zákazníka v jednotlivých zemích přes kategorie. Zároveň je zde zobrazen průměr kategorie, aby by jednoduše identifikovatelné, v jaké zemi jsou prodeje podprůměrné. Barva sloupcových grafů znázorňuje procentuální výši marže – čím tmavší barva tím výší marže a naopak.
42
Obr. 27 Přehled „per store“ prodejů pro jednotlivé zákazníky po kategoriích
Na prvním reportu jsme schopní identifikovat zemi, která je podprůměrná v rámci jedné kategorie. U druhého reportu jdeme o úroveň níž a snažíme se identifikovat konkrétní obchod, který má podprůměrné výsledky pro danou kategorii a zemi.
Přestože oba reporty jsou poměrně jednoduché, tak se ukázaly jako nejsilnější a nejpoužívanější obchodním týmem, protože obchodní tým dokáže velice snadno identifikovat „problémové“
obchody a může tak prezentovat zákazníkům tvrdá data, která jasně ukazují, na co se zaměřit a jaký je potenciál navýšit obrat u podprůměrných prodejen.
43 Obr. 28 Přehled prodejů po kategoriích a obchodech
Report 4: Automatizování doporučené výše objednávek pro APR zákazníky
Posledním vytvořeným reportem v rámci pilotního projektu je automatizování doporučených objednávek. Jedná se o jednoduchou tabulku, která zobrazuje průměrný počet prodaných kusů za 4, 6, 8 nebo 10 týdnů (filtr Sales – weeks), minimální doporučenou výši skladu (Min Stock), současnou výši skladu (Current stock), doporučenou výšku objednávky (Recomm. Order), minimální výši objednávky (Minimum order) a doporučenou výšku objednávky vzhledem k minimální výši (Recomm. Order (w/minimum)). Automatizováním tohoto reportu obchodní tým ušetří cca 4 hodiny týdně.
Obr. 29 Doporučená výše objednávky
44
4 Vyhodnocení pilotního projektu a budoucí plány
Cílem práce bylo vytvořit BI prostředí ve firmě Epico. Na základě vstupní analýzy, business požadavků, organizační struktury a datové gramotnosti firmy bylo vybráno nejvhodnější řešení.
Součástí řešení bylo navržení a následná realizace datového skladu se všemi jeho komponenty – ETL, DSA, jednotlivá datová tržiště a v neposlední řadě reportingová vrstva včetně vytvoření pravidelných dashboardů a reportů.
V rámci vyhodnocení projektu byli jednotliví business uživatelé požádáni o zpětnou vazbu.
Jako největší přínos obchodní tým hodnotí report ukazující detail prodejů po produktech a prodejnách pro APR. Protože na základě tohoto reportu se jim potvrdila jejich domněnka o podprůměrných prodejnách a mohou na základě tvrdých dat vypracovat akční plány s jednotlivými zákazníky na zvýšení prodejů v podprůměrných prodejnách. Bohužel kvůli zhoršující se situaci ohledně COVID-19, zpřísnění sanitárních opatření a následnému uzavření obchodů a obchodních center ve většině zemí, kde Epico operuje, nebylo možné kvantifikovat dopad jednotlivých akčních plánů.
Druhý významný přínos je, že obchodní tým může reporty sdílet se zákazníky, a tím podpořit vzájemnou spolupráci. Ať už se jedná o analýzu prodejů přes jednotlivé prodejny a produktové kategorie, kde je jasně vidět srovnání prodejů napříč jednotlivými obchody a zákazníci mohou sami začít zkoumat, proč se některým produktům na jedné prodejně daří a na druhé ne, nebo o sledování a cílování výše skladu, a s tím spojené automatické doporučení produktů, které by si měli objednat.
Management společnosti pilotní projekt hodnotí jako úspěch a jako hlavní pozitiva, mimo těch zmíněných obchodním týmem, zmiňuje standardizaci a automatizaci reportů, zvýšení datové kvality a vytvoření kvalitního základu pro další rozvoj analytického prostředí. Celkově se tedy dá říct, že cíle pilotního projektu definované v kapitole 2.2. byly naplněny a pilotní fáze může být úspěšně ukončena.
Management společnosti podpořil a odsouhlasil další investice a rozvoj analytického prostředí.
V návaznosti na to byla aktualizována původní road mapa projektu a byly identifikovány oblasti rozšíření, které byly roztříděny podle priority.
45 Obr. 30 Aktualizovaná road map projektu
Vysoká priorita:
▪ Otevření pozice datového analytika/admina – mezi jeho/její hlavní úkoly bude patřit správa, údržba a rozvoj analytického prostředí v rámci popilotního rozvoje definovaného v road mapě.
▪ Master data – vyčištění produktových master dat přímo v K2, kde budou master data spravována i do budoucna
▪ Meziroční evoluce – tím, že od ledna 2021 budou k dispozici historická data za rok 2020, musejí se jednotlivé reporty a dashboardy upravit, aby zobrazovaly meziročního evoluce
▪ Obchodní cíle – obohacení DM1 o obchodní cíle a zároveň úpravu dashboardů, aby zobrazovaly srovnání reality s cíli.
Střední priorita:
▪ Rozšíření na všechny zákazníky – jak bylo zmíněno v úvodu práce, pilotní projekt pracuje pouze s daty zákazníků, kteří poskytují Epicu sell-out data, proto v rámci dalších fází projektu dojde o rozšíření i o ty zákazníky, kteří sell-out data neposkytují, abychom získali celistvý pohled na obrat firmy
▪ Rozšíření o finanční data – obohacení současných dat v DWH o finanční data a vytvoření pravidelného reportingu. Především se bude jednat o různé pohledy na ziskovost zákazníků a produktů a na OPEX (mzdové náklady, cestovní náklady, marketingové náklady, leasing, atd…)
46 Nízká priorita:
▪ Plánování a optimalizace skladových zásob – toto je spíše dlouhodobý cíl a nejedná se o business prioritu, ale současná situace ohledně COVID-19, kdy ze dne na den byla uzemněna většina letadel a dovoz zboží z Číny se výrazně prodloužil, ukázala, že schopnost efektivně a hlavně přesně plánovat výši skladových zásob je kritická. Proto jsme do road mapy projektu zařadili i tento dlouhodobý cíl. Jde především o prozkoumání možností využití automatizace a modelování pro předpovídání prodejů, a s tím spojené optimální výše skladových zásob.
47
Použitá literatura
Breslin, M. (2014). Data Warehousing Battle of the Giants: Comparing the Basics of the Kimball and Inmon Models. BUSINESS INTELLIGENCE JOURNAL.
Epico International s.r.o. (2020). about-us. Načteno z myepico.com:
https://www.myepico.com/
Gartner. (2020). Gartner Magic Quadrant for Data and Analytics Service Providers.
Gartner. (January 2020). Gartner Magic Quadrant for Master Data Management Solutions.
Načteno z Gartner.com: https://www.gartner.com/en/documents/3979521
Gartner. (January 2020). Magic Quadrant for Data Quality Solutions. Načteno z gartner.com.
Inmon, W. H. (2002). Building the Data Warehouse. John Wiley & Sons, Inc.
Keboola. (December 2020). Keboola Pricing. Načteno z keboola.com:
https://www.keboola.com/pricing
MS Power BI pricing. (2020). Načteno z powerbi.microsoft.com:
https://powerbi.microsoft.com/en-us/pricing/
Naeem, T. (22. September 2020). Data Warehouse Concepts: Kimball vs. Inmon Approach.
Načteno z astera.com: https://www.astera.com/type/blog/data-warehouse-concepts/
olap.com. (11. 10 2020). Načteno z WHAT IS THE DEFINITION OF OLAP?:
https://olap.com/olap-definition/
Oracle. (nedatováno). Data Marts. Načteno z Oracle8i Data Warehousing Guide:
https://docs.oracle.com/cd/A81042_01/DOC/server.816/a76994/marts.htm
Rangarajan, S. (6. June 2018). Data Warehouse Design – Inmon versus Kimball. The Data Administration Newsletter.
Slánský, D. (2018). Data and Analytics for the 21st Century. Praha: Professional Publishing.
Tableau Pricing. (2020). Načteno z Tableau.com: https://www.tableau.com/pricing/teams-orgs Zentut.com. (nedatováno). Načteno z Bill Inmon Data Warehouse :
https://www.zentut.com/data-warehouse/bill-inmon-data-warehouse/
