Zavedení Self-Service BI u MVNO GoMobil

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačních technologií

Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Zavedení Self-Service BI u MVNO GoMobil DIPLOMOVÁ PRÁCE

Student

:

Bc. František Řehoř

Vedoucí

:

doc. Ing. Jan Pour, CSc.

Oponent :

Ing. Jiří Malecha

2014

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.

V Dolním Bukovsku dne 1. prosince 2014 Bc. František Řehoř

Poděkování Tímto bych chtěl poděkovat vedoucímu mé diplomové práce doc. Ing. Janu Pourovi, CSc. za jeho motivující přístup, nápady a rady v průběhu psaní. Dále bych chtěl poděkovat Ing. Miroslavu Žebrákovi ze společnosti KOMIX s.r.o., díky němuž jsem získal testovací licence a mohl jsem tedy naplno vyzkoušet nástroj Qlik Sense. Velké díky patří také mým kolegům ze společnosti TERMS a.s., zejména za to, že byli často v průběhu mého psaní nuceni snášet mé často se měnící nálady. Nesmím samozřejmě zapomenout na svou milovanou rodinu, která mě podporovala po celou dobu mého dlouholetého studia. Bez ní si (studentský) život nedokážu vůbec představit. Právě jejím členům, zejména pak mým drahým rodičům, bych tuto práci chtěl věnovat.

Abstrakt Hlavními cíli této práce jsou vymezení přístupu Self-Service Business Intelligence, jakožto jednoho z přístupů Business Intelligence, charakteristika nástroje Qlik Sense a dále popis vývoje reálného řešení s pomocí daného nástroje. V její první části se práce zabývá po teoretické stránce právě daným přístupem, popisuje jeho výhody a nevýhody a uživatele přicházející do styku s danými technologiemi. Uvádí požadavky kladené na daná řešení a zmiňuje rozdílné požadavky na míru a řešení Self-Service v organizacích. Dále jsou zmíněna doporučení pro zavádění takovéhoto přístupu a technologií. Ve druhé části je práce věnována nástroji Qlik Sense, jednoho z představitelů řešení postavených na přístupu Self-Service Business Intelligence. Zprvu jsou popsány jeho základní vlastnosti, možnosti a výhody. Posléze je pak vysvětlen vývoj řešení a princip práce s tímto nástrojem, popsána architektura serverového podnikového řešení, instalace a základní nastavení Qlik Sense serveru. V poslední části se práce věnuje mobilnímu virtuálnímu operátorovi GoMobil, jeho současnému stavu, potřebám z pohledu Business Intelligence a v neposlední řadě pak požadavkům a vývoji řešení s využitím nástroje Qlik Sense.

Klíčová slova Business Intelligence, Self-Service Business Intelligence, Qlik Sense, mobilní virtuální operátor, malé a střední podniky

Abstract The main objectives of this work are determining Self-Service Business Intelligence as one of Business Intelligence approaches, description and characterization of Qlik Sense and finally development of particular solution using the above tool. In the first part thesis deals with the theoretical side of the approach, describes its advantages and disadvantages and users coming into contact with the respective technologies. Subsequently, thesis specifies requirements for Self-Service Business Intelligence and mentions different requirements and sizes of solutions in organizations. At the end recommendations for the implementation of the approach and technologies are mentioned. The second part is devoted to Qlik Sense platform, as one of the representatives based on the Self-Service approach. At first basic features, options and benefits are described. Then the development of solutions and principles of work with this tool are explained. Finally, architecture of enterprise server solution is described together with installation steps and basic configuration of a Qlik Sense site. The third part is focused on mobile virtual operator GoMobil, its current state, Business Intelligence needs and last but not least the requirements and development of solution using Qlik Sense platform.

Key words Business Intelligence, Self-Service Business Intelligence, Qlik Sense, mobile virtual network operator, small and medium enterprises

OBSAH 1

Úvod ................................................................................................................................................................ 9 1.1

Cíle práce a způsob jejich dosažení ....................................................................................... 10

1.2

Rozsah a struktura práce ........................................................................................................... 10

1.3

Předpoklady a omezení práce.................................................................................................. 11

1.4

Výstupy a očekávané přínosy práce ...................................................................................... 11

2

Rešerše publikovaných zdrojů .......................................................................................................... 12

3

Self-Service Business Intelligence.................................................................................................... 14 3.1

Úvod do BI ........................................................................................................................................ 14

3.2

Klasický přístup BI........................................................................................................................ 16

3.3

Self-Service BI ................................................................................................................................. 18

3.4

Důvody pro SS BI ........................................................................................................................... 19

3.4.1 Stále se měnící požadavky .................................................................................................. 19 3.4.2 Dodávání BI výstupů v nepřijatelném čase .................................................................. 19 3.4.3 Potřeba organizace být více „data-driven“................................................................... 19 3.4.4 Pomalé či již neaktuální informace ................................................................................. 20 3.4.5 Nespokojenost se současným stavem a dodávanými výstupy od IT ................. 20 3.4.6 Příliš složité nástroje ............................................................................................................. 20 3.4.7 Omezování nákladů na IT .................................................................................................... 20 3.4.8 Omezené BI zkušenosti/dovednosti ............................................................................... 20 3.5

Typy uživatelů SS BI..................................................................................................................... 21

3.5.1 Změna role IT v organizaci.................................................................................................. 23 3.6

Proces a úlohy SS BI ..................................................................................................................... 24

3.7

Požadavky na SS BI...................................................................................................................... 26

3.7.1 Snadno dostupná zdrojová data ....................................................................................... 26 3.7.2 Rychlost nasazení, vývoj a snadné řízení ...................................................................... 26 3.7.3 Jednoduchost BI nástrojů .................................................................................................... 27 3.7.4 Srozumitelnost BI výstupů.................................................................................................. 28

4

3.8

Typy řešení SS BI ........................................................................................................................... 29

3.9

Míra SS BI ......................................................................................................................................... 30

3.10

Doporučení při zavádění SS BI ........................................................................................... 31

3.11

Shrnutí .......................................................................................................................................... 33

Qlik Sense ................................................................................................................................................... 34 4.1

Výjimečné vlastnosti Qlik Sense ............................................................................................ 35

4.1.1 Jednoduchá architektura ..................................................................................................... 35 4.1.2 Asociativní indexace dat ...................................................................................................... 35 4.1.3 In-memory analytika ............................................................................................................. 36 4.1.4 Drag & drop vizualizace ....................................................................................................... 36 4.1.5 Přístup kdykoliv, kdekoliv, na čemkoliv........................................................................ 36 4.1.6 Storytelling ................................................................................................................................ 37 4.1.7 Řízené SS BI ............................................................................................................................... 37 4.1.8 Aplikace i pro velké podniky .............................................................................................. 37 4.1.9 Otevřenost ................................................................................................................................. 38 4.2

Druhy Qlik Sense aplikací a licence ....................................................................................... 38

4.2.1 Qlik Sense Desktop ................................................................................................................. 38 4.2.2 Qlik Sense „server“ ................................................................................................................. 41 4.3

Vývoj Qlik Sense aplikace .......................................................................................................... 42

4.3.1 Data............................................................................................................................................... 43 4.3.2 Vizualizace dat ......................................................................................................................... 49 4.3.3 Příprava aplikací pro ostatní uživatele .......................................................................... 51 4.3.4 Práce s vizualizacemi ............................................................................................................ 52 4.4

Serverové řešení a nasazení ..................................................................................................... 53

4.4.1 Architektura .............................................................................................................................. 53 4.4.2 Vytvoření SITE ......................................................................................................................... 56 4.4.3 Content management ............................................................................................................ 59 4.5 5

Shrnutí ............................................................................................................................................... 62

SS BI řešení pro MVNO GoMobil ....................................................................................................... 63

5.1

Projekt BI .......................................................................................................................................... 63

5.1.1 Projekt SS BI.............................................................................................................................. 65 5.2

Řešení pro GoMobil ...................................................................................................................... 66

5.2.1 Současný stav ........................................................................................................................... 66 5.2.2 Možné přínosy zavedení SS BI ........................................................................................... 67 5.2.3 Požadavky na první přírůstek ........................................................................................... 70 5.2.4 Multidimenzionální analýza ............................................................................................... 70 5.2.5 Informační systém a primární zdroje dat ..................................................................... 71 5.2.6 Návrh ETL .................................................................................................................................. 72 5.2.7 Uživatelské rozhraní.............................................................................................................. 83 5.3 6

Shrnutí ............................................................................................................................................... 87

Závěr ............................................................................................................................................................ 88 6.1

Naplnění cílů práce....................................................................................................................... 88

6.2

Data & SME ...................................................................................................................................... 89

7

Terminologický slovník........................................................................................................................ 90

8

Seznam literatury ................................................................................................................................... 92

9

Seznam obrázků a tabulek .................................................................................................................. 95

10

Přílohy .................................................................................................................................................... 96

10.1

Log proběhlého ETL skriptu ................................................................................................ 96

10.2

Vygenerování umělé časové dimenze .............................................................................. 97

10.3

Přírůstkové načítání dat transakcí .................................................................................... 98

1 ÚVOD Současná ekonomická situace, dynamicky se měnící turbulentní prostředí, konkurenční boj na trhu - to jsou překážky, se kterými se musí umět v dnešní době firmy vypořádat, aby obstály na trhu se svými produkty a službami, zvyšovaly svůj tržní podíl a popřípadě pronikaly i na další potenciální trhy. Za úspěchem firmy v tomto neutuchajícím konkurenčním boji většinou obvykle stojí především správná rozhodnutí a kroky jejího managementu, a to i na nižších úrovních řízení. Není žádným tajemstvím, že v mnoha společnostech jsou ještě nyní přijímány rozhodnutí pouze na základě intuice či domněnek, které nejsou podloženy žádnými podnikovými daty, a jsou tudíž spojena s velkou mírou rizika. Protikladem je pak jednání na základě informací a dat poskytnutých ze specializovaných systémů podporujících manažerské rozhodování. Manažerské kroky a rozhodnutí se s takovými systémy stává rychlejší, jednodušší, efektivnější. Celkově se tím snižuje riziko, že budou ona manažerská rozhodnutí mylná. Navíc v častých případech umožňují firmám a jedincům objevovat nové skutečnosti, vazby, zákonitosti a být inovativní, kreativní v tom, co dělají. Systémy a nástroje pro podporu manažerského rozhodování jsou v současné době řazeny pod zastřešující název „Business Intelligence“, zkráceně „BI“. Obor v IT je to velmi mladý. Jeho prvopočátky se datují do 80. let 20. století, kdy vznikaly první pokusy o tento druh systémů. Od zmíněné doby do současnosti však obor prošel obrovskou renesancí. V současnosti, vzhledem k popisované situaci na trhu, je BI jednou z nejvíce se rozvíjejících oblastí IT. Tento fakt jen potvrzuje množství každoročně investovaných prostředků do BI technologií a to jak ze strany poptávajících firem, tak i ze strany samotných tvůrců systému a nástrojů, které se neustále vyvíjejí. Dle Gartner (2013) se například celosvětové roční výnosy z BI aplikací dostanou ze současných přibližně 14 miliard dolarů v roce 2013 až na 17 miliard dolarů v roce 2016. Zavedení a provoz BI v podnicích je velmi komplexní, dlouhodobý a v jistých směrech iterativní proces, který ukrývá mnoho specifických výzev a problémů, kterým je třeba čelit. V návaznosti na současně rychle se měnící konkurenční prostředí a obecně celkovou situaci na trzích je ovšem i samotné potřebné BI pod jedním z největších tlaků. Jedná se zejména o snižování nákladů, zvyšování ROI a stále vzrůstající a měnící se poptávka ze strany zaměstnanců po rychleji dodávaných personalizovaných BI výstupech. Přirozenou reakcí na tyto skutečnosti a potřeby je do určité míry „Self-Service Business Intelligence“, zkráceně „SS BI“, což je druh BI aplikací, které umožňují do jisté míry samotnému ne-IT uživateli vytvářet

Zavedení Self-Service BI u MVNO GoMobil

9 / 100

své vlastní reporty a provádět analýzy v rámci daného prostředí a poskytnutých nástrojů (Gartner). Právě SS BI bude má práce věnována. Musím přiznat, že výběr diplomové práce na téma BI byl pro mě jasnou volbou již od doby, co jsem přišel s těmito technologiemi poprvé do styku na kurzu Business Intelligence na Vysoké škole ekonomické v Praze. Od té doby jsem se o BI a data začal intenzivněji zajímat. Bližší specifikace tématu přišla však až následně po mém nástupu do českobudějovické společnosti TERMS a.s., která provozuje v současné době mimo jiné mobilního virtuálního operátora GoMobil. Na tomto projektu jsem měl to štěstí působit již před jeho samotným spuštěním. Více než po roce působení MVNO GoMobil na českém telekomunikačním trhu a růstu co do počtu zákazníků tak do množství produkčních dat však ještě stále není nasazen žádný nástroj pro podporu rozhodování založený na principech BI. Právě v zavedení BI, dnes již nepostradatelné technologie pro každý podnik, spatřuji velké příležitosti.

1.1 CÍLE PRÁCE A ZPŮSOB JEJICH DOSAŽENÍ Diplomová práce má stanoveny tři cíle, kterých se budu pokoušet postupně dosáhnout. A. Prvním cílem je vymezení SS BI, jako jednoho z BI přístupů, jeho přínosů pro organizaci a dalších specifik. B. Druhým

cílem

je

popis

SS

BI

nástroje

Qlik

Sense,

jakožto

jednoho

ze současných předních SS BI řešení na trhu. C. Třetím cílem je řešení BI přírůstku vycházejícího z reálných uživatelských požadavků MVNO GoMobil s využitím nástroje Qlik Sense.

1.2 ROZSAH A STRUKTURA PRÁCE Struktura práce kopíruje v předchozí kapitole její stanovené cíle. V teoretické části je práce věnována vymezení technologie a přístupem SS BI, jakožto jednoho z nových BI přístupů. Jsou vyjmenovány důvody pro zavedení této technologie, identifikovány typy SS BI uživatelů, popsán proces a požadavky kladené na řešení, vysvětleny typy přístupů k tvorbě SS BI řešení, naznačena rozdílná míra SS u jednotlivých řešení a nakonec jsou uvedena doporučení pro implementaci SS BI. Praktická část práce je věnována jednomu z předních SS BI řešení na trhu, nástroji Qlik Sense, a následně reálným BI požadavkům uživatelů MVNO GoMobil a vývoji s pomocí zmíněného nástroje. Nejdříve je popsán samotný Qlik Sense - jeho vlastnosti, možnosti, architektura a principy. Poté se práce věnuje MVNO GoMobil, současnému stavu, potřebám, v neposlední řadě pak požadavkům a vývoji daného řešení na platformě Qlik Sense.


10 / 100

1.3 PŘEDPOKLADY A OMEZENÍ PRÁCE Nástroj Qlik Sense bude samozřejmě popsán jen do té míry, aby čtenář pochopil jeho možnosti a měl základní přehled o jeho architektuře a principech. Pro detailnější studium, návody a postupy je vhodné využít dostupné bohaté produktové dokumentace a dalších zdrojů. Protože cílem praktické části práce je spíše nastínění možností a návrh směru než celistvé pokrytí všech oblastí, procesů a BI požadavků u MVNO GoMobil, je praktická část práce zaměřena pouze na úzce specifikované uživatelské požadavky týkající se zákaznických dat MVNO GoMobil.

1.4 VÝSTUPY A OČEKÁVANÉ PŘÍNOSY PRÁCE Výstupy dané práce jdou ruku v ruce se stanovenými cíli a zvolenou strukturou. Jsou to: A. Vymezení SS BI, jako jednoho z odvětví BI, vysvětlení přínosů, požadavků a doporučení. B. Popis nástroje Qlik Sense, jeho možností, vlastností a specifik. C. Návrh a implementace BI řešení dle specifikovaných uživatelských požadavků týkající se zákaznických dat MVNO GoMobil. To vše s využitím nástroje Qlik Sense. Očekávané přínosy práce se nacházejí hned ve čtyřech rovinách. První z nich leží na rovině teoretické, kdy čtenář získává základní informace o SS BI, jeho výhodách, překážkách, principech. Na základě těchto poznatků může následně sám zhodnotit, zdali přístup SS BI, či kombinace zmíněných přístupů, by mohl být vhodný pro jeho organizaci nebo řešenou oblast. Za druhé je předpoklad využití teoretické části této práce jako zdroje pro aktualizaci tématu SS BI popsaném na portálu MBI (Management of Business Informatics). Vývoj referenčního modelu řízení podnikové informatiky, označovaného jako MBI, je grantový projekt katedry IT na Vysoké škole ekonomické v Praze. Třetí přínos pak leží v rovině praktické, kdy doufám, že tato práce poskytne čtenáři základní přehled o nástroji Qlik Sense, jeho možnostech a vývoji v něm. V neposlední řadě, což je má velká touha, by mohla být práce prvotním impulsem ke změně přístupu společnosti TERMS a.s., ale i jiných společností nacházejících se v podobné situaci, k podnikovým datům a způsobu a míry jejich utilizace.


11 / 100

2 REŠERŠE PUBLIKOVANÝCH ZDROJŮ Na problematiku BI již bylo za řadu let existence této technologie napsáno bezpočet kvalitních teoretických, ale i praktických, prací, ze kterých se dá vycházet. Příkladem nejkvalitnějších česky psaných zevrubných zdrojů, které vedou čtenáře od základných principů BI až po implementační a provozní část řešení, může být kupříkladu kniha Business Intelligence: Jak využít bohatství ve vašich datech (Novotný, a další, 2005) či Business Intelligence v podnikové praxi (Pour, a další, 2012), jejichž autory spojuje zejména jejich akademická činnost na Vysoké škole ekonomické v Praze.

Co se pak týče anglicky psané literatury na téma

BI a budování datových skladů je výběr velmi široký a je možné čerpat z nepřeberného množství knih, akademických prací či článků. U velmi mladého odvětví SS BI je situace však zcela opačná a prací na dané téma je poskrovnu. Kniha, která by se věnovala výhradně dané oblasti, neexistuje. Česky psaných zdrojů, které se SS BI zabývají aspoň trochu do hloubky, jsou pouze diplomové práce studentů Vysoké školy ekonomické v Praze, kde má výuka BI již několikaletou tradici. Nejrelevantnější tématu je diplomová práce Self-service BI a PowerPivot (Černý, 2013), kde autor srovnává klasický přístup s přístupem SS BI, praktickou část práce pak věnuje rozšíření MS Excel o nástroj PowerPivot. Druhou použitelnou prací je Aplikace typu Business Intelligence v podnikové praxi (Janošek, 2010), kde autor popisuje nástroj QlikView a jeho možnosti. V nejnovější relevantní práci nazvané Self-service BI – problémy současné architektury (Formánek, 2013) pak autor nejprve vymezuje SS BI a hezky rozvádí její potřebu v dnešní informační společnosti, věnuje se obecným doporučením při budování SS BI řešení a následně se snaží dokázat to, zdali je možné pouze s pomocí SS BI technologií pokrýt všechny požadavky reálného BI zákazníka. Všechny knihy výše zmíněné, ale i diplomové práce, jsou velmi velkou inspirací této práci a přinejmenším, v případě diplomových prací, se dají brát jako velmi kvalitní rozcestník obsahující odkazy na primární zdroje. Jsou zde ovšem dva zdroje, které byly pro tuto práci opravdovou inspirací a impulsem. V prvé řadě se jedná o krátkou výzkumnou práci Self-Service Business Intelligence: Empowering Users to Generate Insights (Imhoff, a další, 2011), která se zabývá na několika desítkách stránek velmi čtivě a podrobně SS BI zejména z business perspektivy, kdy jsou všechny informace podložené výzkumem provedeným na vzorku skoro šesti stovek firem různé velikosti z různých odvětví z celého světa. Popisuje velmi dobře všechny „drivers“ a výhody SS BI, zainteresované uživatele a „best practises“ v případě jejího zavádění a adaptace v organizaci. Druhým inspirativním zdrojem je pak krátký článek 5 Ways to Bring Self-Service BI to Your Small or Midsized Business (Smietana, 2013), kde hlavním sdělením autora článku je to, Zavedení Self-Service BI u MVNO GoMobil

12 / 100

že zejména malé a středně velké organizace mají velký potenciál ve využití podnikových dat, neměli by podceňovat význam této technologie a že BI řešení nemusí nutně znamenat pouze monstrózní velmi nákladné řešení podobající se těm, které mají velké organizace. Ale právě naopak, může to být pouze velmi malé, nenákladné, flexibilní a mnohdy jednoduché „DIY“ řešení postavené na principech SS BI. Technologii SS BI, produkci článků a podporou výzkumných prací na toto téma se pak významně přirozeně věnují společnosti vyvíjející SS BI nástroje. Příkladem může být společnost Qlik Technologies Inc., jejiž hlavními produkty jsou nástroje QlikView a Qlik Sense. Tyto zdroje jsou v průběhu několikrát citovány, zejména pak v teoretické části práce.


13 / 100

3 SELF-SERVICE BUSINESS INTELLIGENCE 3.1 ÚVOD DO BI Business Intelligence je definován v mnoha zdrojích různě, avšak všechny tyto definice mají vždy stejné jádro. První, kdo tento pojem definoval, byl v roce 1989 Howard Dresner, analytik přední IT poradenské společnosti Gartner. Co může tedy BI lépe vystihnout než jeho do češtiny přeložená definice? „Business intelligence je zastřešující pojem pro aplikace, infrastrukturu, nástroje a procesy, které umožňují přístup k datům a jejich následnou analýzu. To vše prováděno za účelem zlepšení a optimalizace rozhodování a zvýšení výkonnosti organizace.“ (Gartner) Autoři (Pour, a další, 2012) předchozí definici ještě nepatrně rozvádějí pro lepší porozumění. „Business Intelligence je sada procesů, know-how, aplikací a technologií, jejichž cílem je účinně a účelně podporovat řídící aktivity ve firmě. Podporují analytické, plánovací a rozhodovací činnosti organizací na všech úrovních a ve všech oblastech podnikového řízení, tj. prodeje, nákupu, marketingu, finančního řízení, controllingu, majetku, řízení lidských zdrojů, výroby a dalších.“ Aby se manažeři na všech úrovních řízení mohli úspěšně a rychle rozhodovat v dnešním velmi konkurenčním prostředí, potřebují mít včas na správném místě poskytnuto dostatek pravdivých a relevantních informací, na jejichž základě tato rozhodnutí mohou provést. Dle poslední reportu (HBR, 2013) provedeného pro společnost Qlik Technologies, je pouze 13% manažerů z největších organizací jisto svými rozhodnutími, což je dle reportu dáno zejména buď jejich nedostatkem či špatným přístupem k nim. Zpracování dat v organizacích se provádí zejména na úrovni transakčních systémů typu ERP, CRM aj., které ukládají data většinou v relačních databázových systémech. Tyto systémy se označují jako OLTP (OnLine Transaction Processing). Takovéto uložení dat v případě dobrého navržení datové základny má velmi mnoho výhod. Je to například velmi rychlé pořizování, změna a přístup k detailním datům. Dále databázové systémy zajišťují datovou integritu a řídí přístup k samotným datům. Pro analýzu těchto dat jsou ovšem transakční systémy z několika důvodů nevhodné (Novotný, a další, 2005): 

Za pomoci transakčních systémů je nemožné rychle a pružně měnit kritéria datových analýz. Například podívat se rychle na prodejní čísla z více perspektiv, např. z geografické, časové, obchodních zástupců atd.



Obtížné řešení okamžitého přístupu k datům na různé úrovni agregace při obrovských objemech dat.


14 / 100



Transakční systémy, primárně určené pro pořizování, změnu a přístup k detailním datům, většinou pracují na 100% svého maximálního výkonu a je tedy nemožné, aby zpracovávaly i další náročné analytické úlohy zrovna, když si nějaký pracovník uvědomí tuto potřebu.



Nabývání dat v jednotlivých systémech způsobuje ve velmi častých případech situace, kdy jsou data redundantní či nekonzistentní. Samozřejmě i OLTP systémy by byly schopny zvládnout tyto analytické úlohy. Nicméně,

nejsou v jistých ohledech, které jsou zmíněny výše, pro analýzy vhodné. Problémy transakčních systémů

řeší

právě

technologie

OLAP

(OnLine

Analytical

Processing)

a

aplikace

Business Intelligence. Základní principy BI jsou dle (Pour, a další, 2012) následující: 

Uložení a organizace dat v BI systémech je přizpůsobena účelu těchto aplikací.



Data jsou uchovávána na všech potřebných úrovních detailu (granularity). Tedy jsou uchovávána jak data detailní, stejně jako v transakčních systémech, tak i data agregovaná.



Aplikace pracují s daty podnikových ukazatelů, např. tržby, které jsou zpracovávány v kontextu dimenzí a jejich kombinací. Příkladem dimenze může být např. čas, lokalita, obchodní zástupce, produkt aj.



Využívá se časové dimenze, která umožňuje ukládání dat do analytických databází v časových intervalech a snímcích. Tím je umožněno provádět časová srovnání, časové řady a predikovat budoucí vývoj.



BI je charakteristická vyššími nároky na kvalitu dat.



Hlavním zdrojem dat těchto systémů jsou OLTP systémy typu ERP, CRM aj. Data jsou podle potřeby transformována a uložena „multidimenzionálně“, kdy je možné se dívat na podnikové ukazatele z mnoha různých úhlů pohledu a pružně tyto pohledy měnit. To, jak řešit uložení dat pro jejich následné analyzování a reporting, se může organizace

od organizace lišit. Je pro to dnes již možné využít nepřeberné množství dostupných BI technologií a přístupů.


15 / 100

3.2 KLASICKÝ PŘÍSTUP BI Každé řešení BI je jiné, většinou velmi specifické a šité na míru dané organizaci. V řešeních jsou využity různé komponenty a aplikace od různých dodavatelů. Následující obrázek zachycuje komponenty využívané v klasických komplexních BI řešeních a jejich vzájemnou provázanost. Popíši jen ty nejdůležitější.

Obrázek 1: Komponenty vyskytující se v klasickém BI řešení (Novotný, a další, 2005)

Proces budování komplexních BI řešení je zpravidla řešen v kooperaci s externí dodavatelskou společností. Započíná specifikací požadavků a výstupů ze strany business uživatelů v kooperaci s analytiky dodavatelské společnosti. Základem všeho jsou data, bez nich by nic nemohlo vzniknout, a proto jsou následně identifikována data a datové zdroje, které jsou potřeba k dodání požadovaných výstupů. V reálu jsou typy a množství využitých datových zdrojů velmi různorodá. Většinou se jedná o transakční databáze systémů jako ERP, CRM a další podnikové systémy. Nicméně mohou to být i informace z jiných typů zdrojů v podniku, jako jsou tabulky, textové soubory aj. Ve většině případů je nutné také využít i externích dat z volně dostupných externích zdrojů či data od dodavatelů, odběratelů atd. Následující stupeň v klasickém BI architektuře představují datové pumpy (ETL – Extract, Transform, Load), které mají za cíl, jak již název napovídá, identifikovaná zdrojová data vzít, transformovat do požadované podoby, která umožní požadované druhy analýz, a v očištěné podobě uložit do nového úložiště, typicky datového skladu. Datové pumpy jsou standardně spouštěny v dávkovém režimu mimo špičku ve večerních hodinách z důvodu vytíženosti Zavedení Self-Service BI u MVNO GoMobil

16 / 100

transakčních systémů. Dalším mezistupněm mezi zdrojovými daty a datovým skladem může být dočasné úložiště (DSA – Data Staging Area), které má význam buď v případě nahrávání netransformovaných dat z vytížených transakčních systémů, či může sloužit jako prvotní místo uložení pro systémy, u nichž je potřeba nejdříve nahrát data do databázových struktur. Jedná se například o data z textových souborů. Po identifikaci dat, jejich nahrání, očištění a traformaci do požadovaných struktur jsou data nahrána do datového skladu (Data Warehouse). V datovém skladu jsou uložena ve speciální tzv. multidimenzionální formě, ve „star“ nebo „snowflake“ schématu, které umožňují se na ně dívat hned z několika různých úhlů pohledu, tzv. dimenzí, což je předpokladem k dalším analýzám a vytvoření OLAP kostek. Určitou podmnožinu datového skladu představují datová tržiště, která slouží většinou jako funkčně orientované úložiště pro potřeby jednotlivých částí organizace, např. marketingu. Postupné budování datových tržišť a jejich následné sjednocování v jeden velký datový sklad je ostatně jedním z přístupů, jehož představitelem je BI ikona Ralph Kimball. Dle něj má tento přístup výhodu zejména z počátku projektu, kdy přináší rychleji hmotné výsledky a snižuje tím riziko neúspěchu. Naproti tomuto přístupu stojí princip jednorázového vybudování datového skladu a z něho vycházejících datových tržišť pro potřeby jednotlivých útvarů v organizaci, který dle jeho zastánce Billa Imona výrazně omezuje počet rozhraní mezi zdrojovými systémy a datovým skladem, zamezuje výskytu redundantních dat a možných špatných BI výstupů. Po uložení dat do datového skladu v multidimenzionální podobě jsou vytvářeny datové kostky. Jedná se o analytické databáze OLAP (OnLine Analytical Processing), které obsahují předzpracované agregace podnikových ukazatelů v požadované granularitě dle různých dimenzí a jejich kombinací. Umožňují tak prohlížet si data z různých úhlů pohledu (dimenzí) a rychle mezi nimi přecházet. Výhody OLAP databází jsou popsány v kapitole 3.1. S pomocí dalších aplikačních nástrojů mohou být následně připravená data a jejich agregace uvedena do podoby požadovaných výstupů pro konečné uživatele. Lze vytvářet pravidelné reporty, provádět ad-hoc analýzy dat z datového skladu, tržišť, OLAP kostek a provádět dolování dat (Data Mining). Existují však ještě další komponenty, které se nenacházejí ve všech BI řešeních. Je to například EAI (Enterprise Application Interface) či operativní úložiště (ODS – Operational Data Store).

O

těchto

komponentách

se

můžete

dočíst

dopodrobna

například

v knize

Business Intelligence: Jak využít bohatství ve vašich datech (Novotný, a další, 2005).


17 / 100

Jak je patrné, klasické řešení obsahuje velmi mnoho komponent, je velmi složité na realizaci, velmi drahé a pomalé z pohledu konečných business uživatelů z důvodu plné závislosti na vytíženém IT týmu. V poslední době, v době silného konkurenčního prostředí, se snad v každém odvětví projevuje stále větší tlak na správnost a rychlost manažerského rozhodování. Přirozeně tak již pomalý a omezený klasický přístup BI přestává některým organizacím, zejména těm menším a „agilnějším“, a jejich pracovníkům postačovat. Řešením může být právě přístup a technologie Self-service BI.

3.3 SELF-SERVICE BI Potřeba rychlejších a zároveň chytrých rozhodnutí podložených správnými informacemi na vysoce konkurenčních trzích, kde je potřeba neustálé inovace, hledání nových příležitostí ale i tlak na snižování nákladů dala za vznik rozvoji odvětví BI zvané „Self-service BI“ (dále pouze jen SS BI). To, na rozdíl od klasického přístupu k BI, dává rozhodujícím pracovníkům a těm, co potřebují BI výstupy pro svou práci, samostatný přístup k datům a umožňuje provádění vlastních analýz, čímž výrazně zrychluje samotný BI proces. Zde je rozdíl oproti klasickému přístupu, který předpokládá, že manipulace s daty bude pouze v rukách IT pracovníků. Imhoff, a další (2011) definují ve své výzkumné práci SS BI výstižně jako „Nástroje v rámci BI prostředí organizace, které umožňují ne-IT uživatelům stát se více soběstačnými a méně závislými na IT odděleních. Hlavními cíli SS BI jsou snazší přístup ke zdrojovým datům pro reporting a analýzy, jednoduchost a intuitivní práce s nástroji, důraz na srozumitelnost BI výstupů, následné zpracování a v neposlední řadě rychlé nasazení technologie v organizacích.“ SS BI se snaží vyřešit rozpor mezi dvěma protichůdnými podnikovými silami – potřebou flexibility a svobody při analýze a zkoumání dat koncovými „spotřebiteli“ BI výstupů, které ovšem bohužel nelze docílit s pomocí pomalého a neflexibilního „dodavatele“ ve formě podnikového IT oddělení. Proti pak stojí potřeba IT oddělení mít neustálou kontrolu nad daty a vytvářením a distribucí informací uvnitř firmy. SS BI rozšiřuje klasické tradiční BI prostředí o možnosti provádění vlastních analýz nad zpřístupněnými daty a jejich reporting bez nutnosti potřeby zásahu IT oddělení. Dává ne-IT pracovníkům více možností, větší flexibilitu a větší samostatnost, kdy je možné získat odpověď na danou otázku ve výrazně kratší době. Přístup SS BI tedy obchází problém s neustále se měnícími a novými požadavky a potřebami uživatelů, kdy každý může získat potřebnou informaci, kdykoliv si zamane. Podnikové IT se tak staví do zcela nové role.


18 / 100

Rozhodující osoby potřebují správné informace ve správný čas a ne až tehdy, když na ně dojde řada u stále požadavky zahlceného IT oddělení, které v klasickém BI přístupu představuje většinou úzké hrdlo. Průzkum HBR (2013), kdy manažeři firem měli sdělit, jaké skutečnosti se nejvíce negativně podepisující na jistotě jejich rozhodování, odhalil, že rychlost dodaných potřebných informací je jedním z klíčových problémů. S rychlostí dodaných BI výstupů mělo konkrétně problém celkem 33% všech dotázaných.

3.4 DŮVODY PRO SS BI Z průzkumu, který byl proveden (Imhoff, a další, 2011) mezi podniky po celém světě, vzešly hlavní důvody pro zavádění technologií a přístupů SS BI v organizacích.

Obrázek 2: Hlavní důvody pro zavádění SS BI (Imhoff, a další, 2011)

3.4.1 STÁLE SE MĚNÍCÍ POŽADAVKY Turbulentní tržní prostředí, neustále se měnící požadavky a neustále nové vyvěrající otázky business uživatelů jsou hlavním důvodem pro nepostradatelnost zavedení určité formy SS BI v podniku. Technologie a poskytnuté nástroje umožňují jednotlivým uživatelům na základě jejich aktuálních potřeb rychle, jednoduše provádět potřebné vlastní analýzy dat a získat tak odpovědi na otázky přesně tehdy, kdy jsou potřeba.

3.4.2 DODÁVÁNÍ BI VÝSTUPŮ V NEPŘIJATELNÉM ČASE Je faktem, že v klasickém přístupu není IT oddělení většinou schopno uspokojit veškerou poptávku business uživatelů na požadované informace. „Pokud nebudou vyřizovány informační požadavky přesně tehdy, když je uživatelé potřebují, budou uživatelé obcházet IT a vytvářet svá vlastní rychlá, avšak chaotická, řešení.“ (Imhoff, a další, 2011) Udržování těchto vlastních řešení pak bude v konečném důsledku mnohonásobně převyšovat náklady spojené se zavedením SS BI.

3.4.3 POTŘEBA ORGANIZACE BÝT VÍCE „DATA-DRIVEN“ Cílem zavedení SS BI je přetvoření organizace na takovou, kde se nedělají rozhodnutí jen na základě vlastních zkušeností, intuice či domněnek, které jsou velmi často chybné, nýbrž na tu, kde budou nově učiněná rozhodnutí podložena správnými daty. Zavedení Self-Service BI u MVNO GoMobil

19 / 100

Důležitá při vytváření „data-driven“ kultury je demokratizace dat, tedy aby každý v organizaci měl k dispozici data, která potřebuje ke své práci. Navíc mu musí mít k dispozici nástroje, s jejichž pomocí může s daty pracovat a přetvářet je na informace. (Qlik, 2014)

3.4.4 POMALÉ ČI JIŽ NEAKTUÁLNÍ INFORMACE V současné době mají business uživatelé potřebu tvořit své vlastní reporty a provádět své vlastní analýzy na datech bez nutnosti čekat na IT. Zároveň požadují neomezený přístup ke všem datům a chtějí mít data dostupná ihned, jakmile to bude možné. Jsou si moc dobře vědomi důležitosti BI a jeho potřeby pro lepší rozhodování. Přístup ke správným datům ve správný čas znamená ve většině případů úspěch.

3.4.5 NESPOKOJENOST SE SOUČASNÝM STAVEM A DODÁVANÝMI VÝSTUPY OD IT Jsou-li za pomoci IT dodávány BI výstupy po dlouhé době, velmi snadno se stane, že v daný čas nejsou již pro uživatele vůbec relevantní a jsou zastaralá. Pokud jsou uživatelům dány do rukou nástroje, které jim umožní si provádět své analýzy a vytvářet své vlastní reporty, jež budou odpovídat jejich potřebám, je velmi pravděpodobné, že celková spokojenost s IT oddělením napříč podnikem vzroste.

3.4.6 PŘÍLIŠ SLOŽITÉ NÁSTROJE S nástroji, které jsou nyní dostupné, je velmi obtížné se naučit rychle pracovat. To znemožňuje business uživatelům samostatnosti při práci a obrací se tedy v případě informační potřeby opět na podnikové IT oddělení. Z průzkumu (Imhoff, a další, 2011) vyplývá, že jedním z důvodů, proč se SS BI těší tak velké popularitě, je, že uživatelé nepotřebují pro užívání nástrojů příliš mnoho školení k tomu, aby se s nástroji naučili pracovat.

3.4.7 OMEZOVÁNÍ NÁKLADŮ NA IT Tlak na omezování provozních nákladů a snižování rozpočtů na BI projekty jsou současný trend. Technologie SS BI je jednou z možností, jak je možné snížit náklady a zvýšit ROI takovýchto projektů.

3.4.8 OMEZENÉ BI ZKUŠENOSTI/DOVEDNOSTI Zavádění BI technologií, budování datových skladů a ostatní infrastruktury je velmi drahým, komplexním, zdlouhavým a mnohdy zbytečně složitým procesem, při kterém se využívá mnoho robustních nástrojů a technologií a je potřeba mnoho odborníků na dané oblasti řešení. V případě malých a středních firem, které často nepotřebují takto robustní technologie, které jsou nákladově velmi náročné co do implementace, samotných nástrojů, dalšího vývoje a lidí, se řešení SS BI zdá jako ideální volba a vstupní bod. (Smietana, 2013) Zavedení Self-Service BI u MVNO GoMobil

20 / 100

3.5 TYPY UŽIVATELŮ SS BI Ve spojitosti s SS BI je pro dobré pochopení uvést a popsat jednotlivé typy uživatelů. V článcích věnující se tematice je velmi časté se setkat s pojmy jako „information producers“, „power business users“ nebo zkráceně jen „power users“. Všechny tyto pojmy označují právě tu část business komunity, které je umožněn přístup k datům a dána „moc“ k jejich analyzování a produkci informací pro ostatní uživatele. Imhoff, a další (2011) rozdělují uživatele do třech skupin na informační producenty, konzumenty a kolaborátory. Já jsem se rozhodl ještě pro rozšíření. Detailněji rozdělím a popíši jednotlivé typy uživatelů s přihlédnutím k rozdělení v článku od Melissy Coates. 

Informační konzument Jedná se o všechny uživatele, kteří konzumují BI výstupy (reporty, dashboardy aj.),

které jsou jim naservírovány. Provádí maximálně snadné ad-hoc analýzy s použitím interaktivních nástrojů. Jedná se většinou o uživatele, kteří nemají hlubší znalosti k práci s dostupnými daty v rámci podniku a ani potřebu a čas pro jejich hlubší analýzy. Potřebují pouze informace pro svou práci a rozhodování. Chtějí dostat informace v jednoduché a snadno stravitelné formě. Příkladem mohou být obchodní zástupci, management, zaměstnanci zákaznické podpory, dodavatelé, zákazníci aj. 

Informační producent Tito uživatelé jsou oním stavebním prvkem SS BI. Jedná se o již zmíněnou skupinu

„power“ uživatelů. Mají schopnost práce s daty a produkují výstupy pro informační konzumenty a kolaborátory. Dle Melissy Coates je možné tyto uživatele dále dělit na: o

Návrhář reportů Jedná se o největší skupinu informačních producentů. Je schopen tvořit reporty,

dashboardy a používat různé komponenty pro práci s daty. o

Datový analytik Uživatelé jsou schopni vytvářet datové modely, identifikovat a integrovat datové zdroje

uvnitř i vně podniku a provádět ETL procedury.


21 / 100

o

Statistik Provádí pokročilé statistické operace, data mining či analýzy nestrukturovaných dat.

Jedná se o velmi pokročilé uživatele. Tato skupina představuje nejmenší podmnožinu informačních producentů.

Obrázek 3: Typy uživatelů SS BI (Coates)



Informační kolaborátor Skupina informačních kolaborátorů, kterou identifikuje ve své publikaci (Imhoff, a další,

2011), jsou novým typem uživatelů velmi podobných informačním konzumentům. Podílejí se ovšem navíc na vylepšování informací pro ostatní. Přidávají BI výstupů další business kontext většinou s použitím nástrojů pro spolupráci a social-computing nástrojů, což pomáhá k lepšímu pochopení výstupů a k lepším rozhodnutím. Většinou se jedná o různé komentáře, hodnocení, ranking, značky, feedback aj. Jednotlivé uživatele není ovšem většinou možné přesně vymezit. Jeden uživatel může patřit zároveň do různých skupin. Určitě nebude výjimkou uživatel, který bude někdy konzument, někdy kolaborátor a někdy producent. Dle obrázku výše je ovšem patrné, že počet zastoupených uživatelů v jednotlivých skupinách klesá se zvyšující se mírou komplexity a složitosti práce s daty, což je logické.


22 / 100

3.5.1 ZMĚNA ROLE IT V ORGANIZACI Nedílnou součástí BI prostředí v organizaci jsou zástupci IT, BI vývojáři, bez kterých by řešení nemohlo být realizováno. Oproti klasickému BI se ovšem jejich úloha mění. IT se již donekonečna nemusí zabývat uživatelskými požadavky na BI výstupy a může se soustředit na hodnotnější činnosti a úlohy. Tato specializace má zejména pozitivní vliv na komunikační propast mezi businessem a IT, jedná-li se o dodávané BI výstupy. (Bennett, 2013) Nicméně i u SS BI jsou IT pracovníci ve funkci opatrovníka firemních dat. Tato funkce pak ovšem nabírá v tomto případě na mnohem větší významnosti. Aby uživatelé byly schopni vyprodukovat korektní reporty a další BI výstupy, je nutné zabezpečit, aby uživatelé měli přístup k očištěným datům, v podobě, kterým porozumí, a budou s nimi moci pracovat bez nutnosti stálé pomoci IT pracovníků. Podle Imhoff, a další (2011) přináší změna role IT v případě SS BI následující výhody: 

Přínosy pro uživatele Uživatelé dostávají do rukou data a přístup k nim, která si mohou kdykoliv dle svých

aktuálních potřeb zanalyzovat a vyhodnotit za pomoci poskytnutých nástrojů. Nemusí tak dlouho čekat na výstupy, které jim dodá pomalé IT na základě jejich požadavku. 

Přínosy pro IT Namísto toho, aby IT oddělení bylo zahlceno stále novými a měnícími se požadavky

na reporty a analýzy, předává „moc“ práce s daty do rukou samotných uživatelů. Zároveň se může soustředit na řízení a aktivity, které přinášejí společnosti větší hodnotu. 

Přínos pro samotnou organizaci Změna vede k celkové větší spokojenosti uživatelů s IT oddělením v organizaci, které se

v jejich očích přetváří z pomalého lenochoda, který představuje úzké hrdlo v rychlosti dodávání BI výstupů, do role flexibilního pomocníka, který lépe dokáže uspokojovat uživatelské business požadavky.


23 / 100

3.6 PROCES A ÚLOHY SS BI Následující diagram zachycuje SS BI proces a jeho jednotlivé úlohy od identifikování potřebných zdrojových dat až po samotné rozhodování na základě dostupných BI výstupů.

Obrázek 4: SS BI proces (Imhoff, a další, 2011)



Získání dat (Access) Zahrnuje identifikaci potřebných dat a jejich získání. Jak je patrné z obrázku 4, potřebná

data lze získat z podnikového datového skladu, přímo z produkčních relačních databází či jiných zdrojů dat dostupných uvnitř či mimo podnik. „Když není možné daná data získat v určitý okamžik z podnikových zdrojů, je potřeba umožnit uživatelům jejich samostatné získávání, ať už odkudkoliv, a umožnit jim s nimi pracovat.“ (Yap, 2011) Pro lepší přístup k datům za účelem analýz jsou mnohdy uživatelé ušetřováni od komplexity umístění zdrojových dat skrz virtualizované pohledy na data, tzv. business views. Data se pak uživatelům tváří, že jsou konsolidovaně na jednom místě, ovšem být to tak nemusí. (Compositesw.com) 

Integrace dat & Řízení (Integration & Manage) Plné poskytnutí přístupu ke zdrojovým datům uživatelům nemusí být vždy úplně ideální.

Uživatelé nemají většinou znalost uložení a komplexnosti struktur zdrojových dat, proto se může při analýzách lehce stát chyba. Před tím, než lze data vůbec poskytnout business uživatelům pro následné analýzy a práci s nimi, je potřeba je většinou nějak očistit či transformovat


24 / 100

do snadněji stravitelné podoby, např. v podobě zmíněných business views či, u větších firem, v datovém skladu. Je určitě nade vše jasné, že volnost v provádění analýz samotnými uživateli musí být vyvážená silným řízením a pravidly přístupu a užívání dat. Zde by do hry mělo vstupovat IT, které pravidla definuje a následně monitoruje a řídí nakládání s daty a využívání nástrojů. 

Analýza dat (Analyze) Informační producenti přistupují k předpřipraveným či jiným datům, analyzují je

a připravují výstupy pro informační konzumenty. 

Publikování výsledků (Publish) Po zanalyzování dat a vytvoření výstupů jsou distribuovány mezi informační

konzumenty. Děje se tak skrz různorodá prostředí jako BI portály, e-mail, podnikové sociální sítě aj. 

Vylepšení BI výstupů (Enhance) Informační kolaborátoři vylepšují výstupy od informačních producentů o další informace

a připravují tak pro informační konzumenty výstupy doplněné o další business kontext. Přispívají tak k tomu, že informační konzumenti dané výstupy lépe chápou a jsou je schopni snáze použít. Většinou se jedná o odkazy na další informace, hodnocení, komentáře aj. 

Nalezení potřených informací (Discover) Během této fáze informační konzumenti komunikují mezi sebou a hodnotí výstupy.

Aby byly informační konzumenti schopni rozhodovat, musí být vyprodukované BI výstupy schopni najít a nalézt k nim i další relevantní informace, které k danému rozhodnutí potřebují. Pro zpřístupnění výstupů, dobrou orientaci mezi nimi, vzájemné souvislosti, detailní informace, komunikace nad výsledky s ostatními atd. se používají např. zmíněné BI portály. 

Rozhodování (Decide) Na základě shromážděných dat, jejich analýz, vytvoření BI komponent, doplnění o další

business kontext, zhodnocení výstupů ze strany informačních konzumentů jsou přijímána business rozhodnutí.


25 / 100

3.7 POŽADAVKY NA SS BI

Obrázek 5: Požadavky na SS BI řešení (Imhoff, a další, 2011)

Ve výzkumu (Imhoff, a další, 2011), ze kterého jsem přejal tabulku na obrázku 5, byly identifikovány kritické požadavky vztahující se k jednotlivým uživatelům a úlohám SS BI řešení. V následujících podkapitolách budou požadavky podrobněji rozebrány.

3.7.1 SNADNO DOSTUPNÁ ZDROJOVÁ DATA Bez dat to prostě nejde. Pokud nejsou potřebná data dosažitelná, není možné jakékoliv BI implementovat, data analyzovat a na základě nich přijímat rozhodnutí. Významný rozdíl mezi SS BI a klasickým přístupem je ten, že data se nemusí nacházet nutně v datovém skladu v případě SS BI, nýbrž je lze s dostupnými nástroji čerpat přímo z primárních či externích zdrojů mimo organizaci bez pomoci IT pracovníků. Existují dokonce i řešení, kdy datový sklad není vyžadován vůbec.

Úkolem IT je pak dát business uživatelům, kteří data potřebují

pro své rozhodování, intuitivní a snadný nástroj pro přístup k nim a následně přístup a manipulaci s daty monitorovat a řídit. Za účelem lepšího pochopení analýz a reportů je možné dokonce pracovat i s nestrukturalizovanými daty, jako jsou e-maily či data ze sociálních sítí. (Imhoff, a další, 2011) Díky těmto možnostem je možné BI výstupy obohatit o další informace, které napomohou opět k lepším rozhodnutím.

3.7.2 RYCHLOST NASAZENÍ , VÝVOJ A SNADNÉ ŘÍZENÍ Rychlejší nasazení, vybudování datového skladu a zjednodušení řízení výrazně pozitivně přispěje ke zvýšení produktivity BI/DWH vývojářů. Data pro potřeby informačních producentů budou dostupné rychleji a rychleji budou dodány i požadované BI výstupy.

V konečném

důsledku pak rychlejší nasazení a snadnější správa budou mít pozitivní vliv na návratnost investic do BI řešení a na snížení nákladů na provoz.


26 / 100

Přílišné zjednodušení ovšem také není žádoucí. Je třeba dbát velmi na řízení a míru volnosti uživatelů, v jaké budou data používána. Jedná se o problém tzv. „nezávislých datových tržišť“ samotnými uživateli, kdy je obcházeno podnikové IT. Vzniká tak velké množství nekonsistentních informací napříč firmou. Vzniká chaos, který se může stát do budoucna velmi významným. Aby k tomuto nedocházelo k roztříštěnosti dat a „mnoho verzí pravd uvnitř podniku“, je dle Jamese Kobieluse, senior analytika Forrester Research, nutné, aby každý pracoval pouze s očištěnými konsolidovanými daty se striktně řízeným přístupem k nim (Torode). Na druhou stranu je ovšem vcelku výhodné nechat informační producenty tvořit tzv. experimentální tržiště, tzv. analytické sandboxy, ve kterých si mohou hrát s jakýmikoliv daty. Tato řešení jsou následně velmi dobrým základem pro pozdější pokročilejší řešení vyvinuté

s pomocí

IT

či

informačních

producentů.

Toto

řešení

nabízí

například

v kapitole 4 popisovaný nástroj Qlik Sense.

3.7.3 JEDNODUCHOST BI NÁSTROJŮ Není žádným tajemstvím, že největšími bariérami v adopci BI nástrojů je kromě příliš složitého uživatelského prostředí také složitost nástrojů, které byly navrhnuty pouze pro technicky zaměřené uživatele. (Wachstock, 2014) Všem pracovníkům musí být poskytnuto takových nástrojů, které umožní jednoduché a intuitivní provádění vlastních jednoduchých analýz a tvorbu reportů. Následující tři vlastnosti přispívají k tomu, aby bylo používání nástrojů pro jednotlivé druhy uživatelů jednodušší a stravitelnější. 

Jednoduchost používání Ne všichni uživatelé BI potřebují příliš sofistikované nástroje pro práci s daty. Informační

konzumenti potřebují velmi snadno použitelné nástroje pro pochopení a práci s BI výstupy. Méně zkušení informační producenti potřebují méně komplexní a snadno použitelné nástroje pro vývoj BI aplikací. Na druhou stranu, jednoduchost používání je důležité i pro zkušené informační producenty. Ne vždy tito uživatelé vyžadují funkcionalitu a nástroje, které předpokládají například vysokou míru programátorských či statistických znalostí. 

Automatizovanost řešení Pro mnoho informačních konzumentů jsou BI výstupy velmi důležité pro jejich práci

a pro jejich každodenní rozhodování. Nicméně není po nich vyžadováno, a ani to nechtějí, aby prováděli své vlastní analýzy nad daty, tvořili své vlastní reporty aj. Místo toho chtějí užívat


27 / 100

BI výstupy pasivním způsobem, chtějí být informováni o tom, když mají něco provést či přijmout nějaké rozhodnutí. Řešením je automatizovanost BI. Příkladem mohou být různé upozornění na hodnoty hlídaných indikátorů, navedení na další informace a znalosti, které pomohou uživateli s rozhodnutím, doporučení k rozhodnutím či automaticky naprogramované akce dle hodnot jednotlivých indikátorů. 

Jednoduchá architektura Pro menší organizace je jistě kritickým bodem míra robustnosti daného řešení.

Dnes je velká tendence menších a středních firem inklinovat k méně složitým řešením poskytovaných v cloudu a či jednoduchým „all-in-one“ řešením. Výhody takovýchto řešení pak vychází logicky z obecných výhod cloudu, je to dále jednoduchý vývoj, snadná správa a rozvoj či ovládání skrz obyčejný internetový prohlížeč.

3.7.4 SROZUMITELNOST BI VÝSTUPŮ Pro úspěšné přijetí technologie SS BI je naprosto stěžejní srozumitelnost, vizualizace dat a následné snadná práce s BI výstupy. (Power to the People, 2012) Uživatelé musí rozumět prezentovaným informacím, musí jim být příjemné a stravitelné jejich podání. Tyto požadavky pak kladou nároky na uživatelské rozhraní a nástroje pro prezentaci, reporting, distribuci a sdílení výstupů. Zejména pak z pohledu informačních konzumentů a kolaborátorů je důležité, aby jim byly servírovány jen informace, které potřebují, způsobem, který jim vyhovuje, a v prostředí, které je snadné na používání. 

Známé uživatelské rozhraní Uživatelé mají tendenci vždy používat nástroje, které již dobře znají. Známé uživatelské

prostředí a intuitivní nástroje mají na rychlou adaptaci BI řešení obrovský vliv. Není jistě žádným překvapením, že většina firem vyvíjejících BI řešení klade velkou prioritu na integraci s kancelářskými nástroji, např. typu Microsoft Office, za účelem snadnějšího používání a rychlejšího přijetí mezi uživateli. Pro zlepšení vyhledávání a orientace mezi BI výstupy pak velmi mnoho respondentů dle výzkumu vyžaduje a hodnotí funkcionalitu á la „Google for BI“ jako velmi důležitou. Poskytnutí informací a reportů formou rejstříků a propojení souvisejících informací pak zlepšuje přehled a napomáhá k lepšímu pochopení daných výstupů i s přihlédnutím k dalšímu business kontextu.


28 / 100

S cílem poskytnout data v podobě, které uživatelé porozumí a budou pro ně více stravitelné, se firma nevyhne složitějším implementacím zobrazování informací. Příkladem může být např. zobrazení metrik dle dimenze lokalita, kdy budou informace zobrazovány na mapách. 

Nástroje pro podporu spolupráce Spojením nástrojů pro spolupráci a BI je možné dosáhnout hned několika přínosů.

Jak vystihuje následující obrázek, v prvé řadě mají tyto nástroje celkově kladný efekt na zlepšení komunikace v BI prostředí. Dávají možnost kolaborace nad samotnými výstupy a jejich následné vylepšování, což by následně mělo vyústit v lepší rozhodnutí.

Obrázek 6: Benefity nástrojů pro podporu spolupráce (Imhoff, a další, 2011)



Mobilní rozhraní V reportu od Cisco (2014) se píše, že počet mobilních zařízení (chytrých telefonů

a tabletů) do konce roku 2014 překoná počet obyvatel žijících na Zemi. Stále se zvyšující prodeje mobilních zařízení, způsob a četnost jejich využívání má velký vliv na to, jak chtějí uživatelé konzumovat obsah a používat informace v této době. Prezentační vrstva musí být nyní tedy už nutně „mobile-friendly“. Jednodušší mobilní rozhraní, a tedy i používání, dokáže přilákat pak i ty méně technické uživatele a také mladé uživatele, pro které jsou dnes mobilní technologie už nepostradatelnou součástí života.

3.8 TYPY ŘEŠENÍ SS BI Jak jsem již naznačil v kapitole věnující se klasickému BI, jednotlivá řešení se od sebe povětšinou liší. A je tomu tak v případě SS BI. Dá se říci, že v současné době, můžeme rozdělovat řešení SS BI na dvě skupiny:


29 / 100



S konsolidovaným datovým skladem



Bez konsolidovaného datového skladu Dnešní SS BI nástroje již umožňují poskytovat BI výstupy, aniž by bylo potřeba

zdlouhavého budování konsolidovaného datového skladu. Samozřejmě výhody a účel datového skladu jsou u velkých organizací neoddiskutovatelné. Nicméně v případě malých a středních organizací věřím, že mnohdy není potřeba datový sklad vůbec budovat. Zde určitě platí známé heslo „One size doesn't fit all“, tedy co se hodí pro jednoho, nemusí se hodit pro druhého. Mnoho současných SS BI platforem a jejich ETL nástrojů je tak mocných, že představuje dobrou alternativu k budování datového skladu. Jeho vynechání pak může dané organizaci snížit náklady, čas potřebný na realizaci BI a snížit tak i komplexitu celkového řešení. (Smietana, 2013)

3.9 MÍRA SS BI „Data. Analytika. Business Intelligence. Každá společnost, ať už velká nebo malá, toto vše bez rozdílu potřebuje. Nicméně potřeby se liší společnost od společnosti. V průběhu toho, jak společnost roste, se u ní míry potřeb po klasickém „korporátním BI“ a SS BI mění. Potřebují střední a velké společnosti oboje? Asi ano. Že jsou oba dva přístupy v rozporu? Také pravda, ovšem ne vždy.“ (Coates, 2013) Vždy je potřeba BI řešení dobře nastavit pro potřebu konkrétní organizace a jejich uživatelů a následně vše uřídit. U velkých firem se nyní ve spojitosti s SS BI dnes jedná spíše než o nahrazování klasického BI řešení, kde jsou výstupy vytvářeny výhradně IT oddělením, o jeho rozšiřování o možnosti SS BI. (Imhoff, a další, 2011) Následující obrázek 7 vystihuje vše. O SS BI se bavíme pouze v případě, pohybujeme-li se v rozmezí ohraničovaném černou šipkou. Jak je z obrázku patrné, čím více se pohybujeme po černé šipce doprava, míra SS BI se zvyšuje. Čím větší míra SS BI, tím více benefitů pro uživatele ale také mnoho složitých úkolů, se kterými se v rámci BI řešení musíme poprat z hlediska řízení.

Obrázek 7: Míra SS BI (Schlegel, 2014)


30 / 100

3.10 DOPORUČENÍ PŘI ZAVÁDĚNÍ SS BI Autoři (Imhoff, a další, 2011) identifikovali několik doporučení, ke kterým je potřeba zaujmout patřičný postoj za účelem získání zmíněných benefitů SS BI, fungujícího prostředí a minimalizace rizika neúspěchu zavedení tohoto přístupu. 

Pouhou instalací SS BI nástrojů se požadované přínosy nezískají Kvalitní infrastruktura a nástroje jsou samozřejmě základ. Nicméně není to vše, na čem

stojí kýžený úspěch takového projektu. Jsou to vždy hlavně lidé, kteří rozhodnou. Je potřeba, aby uživatelé pochopili přínos a možnosti daných nástrojů. Je potřeba nástroje pro ně připravit tak atraktivní, jednoduché na používání a pochopitelné, aby nic nebránilo jejich používání i bez většího školení. Často to znamená také dát tyto nástroje „správným“ uživatelům. 

IT musí monitorovat SS BI prostředí IT musí být určitým „supervisorem“ nad celým systémem. Musí mít nástroje k tomu

monitorovat chování a práci a obsah uživatelů. Je potřeba mít přehled o tom, co je publikováno, z jakých zdrojů, kdo používá co atd. Je potřeba také sledovat výkon infrastruktury a náročnost procedur a aplikací. Kromě monitoringu je potřeba ovšem řídit bezpečnost, schvalovat a provádět audity toho, co uživatelé vytvořili. Klíčové je vytvořit takové prostředí, kde se uživatelé cítí, že mají onu „moc“ provádět vlastní analýzy, zatímco IT ze shora provádí dohled a je vždy připraveno zasáhnout a pomoci. 

Umožnění spolupráce uživatelů Podporujte kolaboraci a umožněte uživatelům spolupracovat při tvorbě reportů

a provádění analýz dat. Spolupráce vždy posune dané výstupy a závěry na vyšší úroveň, protože více hlav vždy více ví. Jedná se zejména o sdílení, komentování, hodnocení atd. 

Neklást na uživatele příliš mnoho zodpovědnosti Většina uživatelů nechce tvořit reporty a provádět analýzy, není to prostě v jejich popisu

práce nebo na to nemají vědomosti. Vývoj by měl být v rukou povolaných producentů, kteří mají veškeré potřebné školení, vědomosti, zkušenosti, znají konvence, firemní standardy tvorby reportů atd. V případě, že business uživatelé dosud těmto znakům neodpovídají, je potřeba při zavádění SS BI postupovat po menších krůčcích a prozatím ponechat větší tíhu tvorby výstupů na IT. Pokud by se nahrnula zodpovědnost ihned na nezkušené business uživatele,


31 / 100

hrozí velké riziko odmítnutí z jejich strany. „Nic nezničí SS BI prostředí rychleji než to, že jej nikdo nepoužívá.“ (Imhoff, a další, 2011) 

Pochopení uživatelů a jejich potřeb Základem k efektivnímu fungování SS BI prostředí je potřeba pochopit uživatele, jejich

potřeby, motivaci, schopnosti, vědomosti. Je možné, že většina uživatelů bude pouze pasivními konzumenty, kteří nechtějí nebo nemají potřebné schopnosti k tomu provádět vlastní analýzy dat. Ovšem je třeba brát v úvahu, že role se velmi často mění. Uživatelé přecházejí mezi rolemi například se změnou pracovní pozice. Je potřeba se uživatelům dostat nějak do hlavy a zjistit, co chtějí zjistit, splnit či vytvořit. Jednou z možností, jak uživatele a jeho potřeby pochopit, je jít na to od lesa přes jeho platové ohodnocení a systém bonusů. To totiž z větší části vystihuje potřeby a motivaci zaměstnance na dané pracovní pozici. (Imhoff, a další, 2011) 

Startovací aplikace/ reporty/ dashboardy Dejte na začátku uživatelům několik startovacích aplikací/reportů/dashboardů,

na kterých může vidět možnosti, pochopit přínosy. Samozřejmostí je pak nevytvářet pouze statické výstupy, nýbrž interaktivní a nastavitelné, a učinit tak uživatele samostatným. Ty pak pozitivně přispějí k adaptaci SS BI. 

Stanovení řídící komise Jedním z důležitých prvků, a platí to nejenom u BI projektů, je mít stanovenou řídící

komisi složenou z business i IT představitelů, která bude rozhodovat o všech strategických otázkách. Zároveň by její členové, kteří by měli mít autoritu, měli šířit osvětu mezi uživatele a přispět tak k rychlejší adopci SS BI. 

Možnost používat i data jiná než z datového skladu Jsou zkrátka situace, kdy uživatelé potřebují informace ihned, ovšem potřebná relevantní

data se nenacházejí v datovém skladu, ale například stále v primárních zdrojích. Možností je poskytnout uživatelům přístup k těmto primárním zdrojům a umožnit jim provádět vlastní analýzy. To vše samozřejmě stále s dohledem IT a řídící komise. 

Nezatěžujte méně zkušené uživatele komplexitou BI Odstiňte své uživatele od komplexity BI, nechte uživatele využívat nástroje, které již

velmi dobře znají a jsou na ně zvyklí. Umožněte jim pro práci využívat např. webový prohlížeč, Zavedení Self-Service BI u MVNO GoMobil

32 / 100

připravte jim intuitivní interaktivní reporty, průvodce a upozornění tak, aby snadno a rychle splnili dané úkony. Urychlíte tak proces učení. Je důležité být si vědomi propasti mezi IT a business uživateli, jejich potřebami a schopnostmi. 

Sledování nákladů Neustálé sledování nákladů u projektů, SS BI nevyjímaje, je nutnost, kterou ani není

potřeba zmiňovat. Co se týče ceny řešení, hodně záleží na tom, jestli již firma nějaké BI řešení má nebo ne. V případě nějakého již existujícího řešení je možné využít dodatečných SS nástrojů v rámci v současnosti využívané platformy a minimalizovat tak vstupní náklady. Na druhou stranu existují SaaS možnosti či řešení pro menší společnosti s omezenými nároky a finančními možnostmi. Každopádně je potřeba vždy dbát na to, aby řešení sedělo konkrétní organizaci, a to po všech stránkách.

3.11 SHRNUTÍ V první teoretické části je práce nejdříve věnována vymezení technologie a přístupem SS BI, jakožto jednoho z nových BI přístupů. Jsou vyjmenovány jednotlivé důvody pro zavedení této technologie do organizací a naznačeny nedostatky neflexibilního klasického BI přístupu. Pro lepší chápání jsou následně identifikovány jednotlivé typy uživatelů, popsán proces a jeho jednotlivé úlohy v rámci SS BI prostředí.

Na základě předcházejících částí jsou

vyjmenovány z prováděného výzkumu vyplývající požadavky kladené na SS BI řešení, popsány typy SS BI řešení a naznačena rozdílná potřeba míry self-service u jednotlivých organizací a řešení. Na konci kapitoly jsou uvedena doporučení pro zavádění SS BI v organizacích. První teoretická část práce a její jednotlivé podkapitoly dávají čtenáři základní přehled o SS BI přístupu a jeho výhodách a úskalích. Jsou, myslím, velmi dobrým výchozím bodem pro zhodnocení vhodnosti SS BI pro danou organizaci a určení její požadované míry. V neposlední řadě uvedené informace mohou sloužit jako dobrý základ pro identifikaci požadavků na konkrétní řešení a výběr platformy/nástrojů pro konkrétní organizaci. Zmíněné požadavky na SS BI řešení, zejména pak z pohledu menších a středně velkých organizací, dle mého názoru velmi dobře splňuje nástroj Qlik Sense, který dokáže pokrýt veškeré jejich potřeby a potřeby jejich uživatelů. Právě tento nástroj bude popisován a využit v následujících částech práce.


33 / 100

4 QLIK SENSE BI nástroj Qlik Sense je čerstvě narozené dítě společnosti Qlik Technologies Inc., která byla dříve známá pod názvem QlikTech. Tato firma byla založená v devadesátých letech ve Švédsku a dnes má téměř dva tisíce zaměstnanců, mnoho certifikovaných partnerů nabízejících její služby a více jak třicet tři tisíc zákazníků po celém světě. Dosud byla jejím jediným nabízeným řešením platforma QlikView, situace se však změnila v září tohoto roku s představením Qlik Sense. Společnost tímto novým řešením navazuje na svou vlajkovou loď, která je pokládána za jedno z předních řešení v oblasti „user-driven“ BI. Následující obrázek, kvadrant vytvořený analytickou společností Gartner, ukazuje, jak si společnost stála naposledy v únoru tohoto roku v porovnání s jinými platformami.

Obrázek 8: BI Gartner Magic Quadrant (Gartner, 2014)

Qlik Sense vychází plně z QlikView, kdy je mezi nimi určitá míra kompatibility. Je možné do jisté míry migrovat z QlikView na Sense na úrovni dat. Nadefinované datové pumpy načítající data z primárních zdrojů do požadovaných struktur budou fungovat i v Sense. Situace je však jiná u vizualizací, kdy vytvořené grafy, tabulky a jiné vizualizace migrovat možné není. V současné době žijí obě řešení de facto svým vlastním životem a jsou společností nabízeny paralelně vedle sebe. Přestože je Qlik Sense QlikView v lecčems velmi podobná, je dle svého zaměření velmi odlišná. Mezi nástroji je zřejmý velký rozdíl v samotném přístupu k uživateli a onou mírou „self-service“, viz kapitola 3.9. QlikView je často svým přístupem nazýván jako „guided-analytics“ nástroj, tedy že umožňuje svým uživatelům jen interakce s předem nadefinovanými komponentami uvnitř daných aplikací. Analýza dat a tvorba reportů je vložena Zavedení Self-Service BI u MVNO GoMobil

34 / 100

pouze do rukou určeným velmi zkušeným informačních producentům. Qlik Sense jde cestou zcela opačnou. Vkládá moc zkoumání a analyzování dat do rukou všech uživatelů a umožňuje jim provádět své vlastní analýzy, tvořit vizualizace dle potřeby, a to v rámci poskytnutých i vlastních dat, nadefinovaných metrik a dimenzí. S odkazem na obrázek 7, v kapitole 3.9, se Sense řadí do skupiny „data discovery“ nástrojů.

4.1 VÝJIMEČNÉ VLASTNOSTI QLIK SENSE 4.1.1 JEDNODUCHÁ ARCHITEKTURA Qlik Sense se zásadně na první pohled odlišuje od klasického BI řešení, které je zobrazeno na obrázku 1 v kapitole 3, svou jednoduchostí. Klasická BI řešení jsou velmi komplexní, robustní, obsahují většinou mnoho různých komponent – nástrojů, databází, OLAP kostek, aplikací, hardwaru aj. S nákupem Qlik Sense si kupujete celou BI platformu, která na jedné straně absorbuje data a na druhé je zpřístupní ve srozumitelné podobě skrz webový prohlížeč uživateli.

4.1.2 ASOCIATIVNÍ INDEXACE DAT Qlik Sense je postavena stejně jako QlikView na unikátní patentované technologii asociativní indexace dat „QIX – Qlik Indexing“, která umožňuje snadno a velmi rychle propojit data z různých datových zdrojů do takové podoby, kdy je lze jednoduše procházet a objevovat souvislosti mezi nimi, které by jinak zůstaly s klasickým hierarchickým přístupem svým uživatelům skryty. Porovnání tradičního a asociativního propojení dat lze vidět na obrázku 9.

Obrázek 9: Asociativní indexace dat (Qlik, 2014)


35 / 100

Uživatelé tento přístup ocení zejména tehdy, když neví, co vlastně hledají. Stačí jakákoliv interakce a výběr se ihned projeví do všech ostatních komponent, jelikož všechna data jsou navzájem propojena.

4.1.3 IN-MEMORY ANALYTIKA In-memory analytika patří mezi jeden z největších aktuálních trendů v oblasti uložení dat pro potřeby multidimenzionálních analýz. Vše v tomto případě stojí na tom, že operační paměť je vždy rychlejší než klasické disky. Analyzovaná data jsou uložená v hlavní paměti počítače a výrazně tím přispívají k rychlosti práce s daty. V případě Qlik Sense je celá aplikace, s koncovkou QVF, a v ní uložená data načtena přímo do operační paměti počítače. Výpočty a odezva aplikace na výběry uživatele a interakce s vizualizacemi je opravdu velmi rychlá, plynulá a práce je tak velmi příjemná.

4.1.4 DRAG & DROP VIZUALIZACE Při vytváření vizualizací dat stačí jednoduše vzít danou komponentu, např. sloupcový graf na obrázku 10, vložit ho na „pracovní plochu“, jednoduše přidat metriky a dimenze a po jednoduchém nastavení do požadovaného vzhledu je graf hotov.

Obrázek 10: Drag & drop vizualizace dat (autor)

4.1.5 PŘÍSTUP KDYKOLIV , KDEKOLIV, NA ČEMKOLIV V dnešní době již uživatelé nepracují jen na PC, nýbrž chtějí mít vše na svém tabletu nebo dokonce malém chytrém telefonu. Qlik Sense je tomu plně přizpůsobeno, aplikace jsou vytvářeny pro všechny druhy zařízení. Plně responsivní řešení umožňuje uživatelům pracovat s interaktivními aplikacemi pomocí kteréhokoliv webového prohlížeče.

Stačí si jen otevřít

firemní „hub“, což je obdoba BI portálu, přihlásit se a ihned má uživatel k dispozici veškeré mu zpřístupněné aplikace. Kdykoliv je tak možné danou otázku ihned, vždy, všude a za jakékoliv situace zodpovědět. Zavedení Self-Service BI u MVNO GoMobil

36 / 100

Obrázek 11: Responsivní zobrazení Qlik Sense aplikací (Qlik)

4.1.6 STORYTELLING S Qlik Sense je velmi jednoduché sdílet a prezentovat závěry analýz kolegům. Pomocí prezentačního nástroje, vkládaných analytických výstupů a dalších přidaných doplňujících informací ze strany uživatele je možné vytvářet tzv. „stories“, sdílet své poznatky a kolaborovat nad nimi. Ale pozor, daná prezentace není jen sekvence slidů s určitým nadefinovaným chováním. Vložené analytické komponenty, např. grafy, si drží vazbu na provedený výběr a

kdykoliv

je

možné

přeskočit

z prezentace

zpět

na

danou

aplikaci

do

stavu,

v jakém se nacházela po vložení do prezentace, a zodpovědět aktuální otázku.

4.1.7 ŘÍZENÉ SS BI S Qlik Sense se každý uživatel stane analytikem. Najít balanc mezi potřebami IT a potřebami business uživatelů je pro SS BI typický. Qlik Sense tento problém dle mého názoru velmi dobře zvládá řešit. Zatímco poskytuje business uživatelům určitou volnost v jejich analýzách, IT pracovníci provádí pouze centralizovaný dohled a v případě nutnosti zasahují. Je nutné říci, že úplně každý uživatel si může vytvářet své vlastní vizualizace dat, jak se mu zlíbí a jak mu to vyhovuje. Na druhou stranu IT oddělení vždy ví, že daný uživatel pracuje s daty, ke kterým má oprávnění, jsou pravdivá a konzistentní napříč celou organizací, je tedy nastolena jedna verze pravdy.

4.1.8 APLIKACE I PRO VELKÉ PODNIKY Jak je sděleno na webu Qlik, Sense byla vytvářena s přihlédnutím k potřebám podniků. Celé řešení je opravdu architektonicky velmi jednoduché, nicméně žádné kompromisy a ústupky nikde neuvidíte. Sofistikované centralizované nástroje umožňují řídit, kontrolovat a škálovat celkové řešení tak, jak právě daná organizace potřebuje.


37 / 100

4.1.9 OTEVŘENOST Qlik Sense je plně otevřen dalšímu vývoji. Zajímavé například z mého pohledu je v tuto dobu možnost dalších komponent pro vizualizaci, kdy je možné si řešení rozšířit do požadované podoby. Velmi jednoduché je také vytváření a používání tzv. mashupů, tedy zobrazování informací z Qlik Sense v jiných aplikacích, např. webu, CRM systému aj. A to jsou pouze ukázky, možnosti pro vývoj jsou opravdu široké.

4.2 DRUHY QLIK SENSE APLIKACÍ A LICENCE V rámci platformy existují v podstatě jen dvě aplikace. Samotné Qlik Sense je synonymem k serverovému řešení, které pokrývá veškeré podnikové požadavky a nabízí požadovanou funkcionalitu k provozování SS BI řešení uvnitř podniku. Na druhou stranu existuje desktopová verze pro použití na osobním počítači uživatele s názvem Qlik Sense Desktop, které slouží zejména pro vyzkoušení samotného nástroje a vývoji aplikací.

4.2.1 QLIK SENSE DESKTOP Společnost

Qlik

destopovou

verzi

považuje

a

prezentuje

jako

prostředek,

kterým jednoduše umožňuje lidem vyzkoušet jeho nástroje, samozřejmě pak s cílem pozdějšího nákupu serverového řešení či využívání dalších služeb jako je např. plánovaný Qlik Cloud. Qlik Sense Destop je volně ke stažení na stránkách Qlik a to zcela zdarma k jakýmkoliv účelům. Představuje tedy ideální variantu k tomu, aby se uživatel s danou platformou seznámil a vše si vyzkoušel před tím, než se rozhodne pro nákup celopodnikového řešení. Qlik Sense Desktop má několik vlastností a také omezení oproti serverovému řešení: 

Jak jsem již napsal, je možné aplikaci nainstalovat pouze na lokálním počítači, a to s nainstalovaným OS Windows.



Aplikace, které jsou vytvořeny pomocí desktopové verze, je možné sdílet jen způsobem zaslání zdrojového souboru uživateli. Ten si ho může otevřít poté jen v případě, že má Qlik Sense desktop také naistalován.



Nenabízí oproti serverovému řešení funkcionalitu a nástroje k řízení publikace aplikací pro ostatní uživatele.



Není možné plánovat načítání dat z datových zdrojů. Chce-li uživatel aktualizovat data v aplikaci, je nutné provést vše ručně.



Aplikace, které jsou vytvořeny v desktopové verzi, je možné posléze s malými úpravami využít v serverové verzi.


38 / 100

4.2.1.1 Základy práce s Qlik Sense Desktop Po té, co desktopovou verzi na svůj lokální počítač s Windows nainstalujete a otevřete si ho buď v samotné nativní aplikaci či v prohlížeči, ocitnete se v tzv. hubu, ze kterého máte přístup do všech aplikací vytvořených na zmíněném počítači. Po instalaci by zde měly být dostupné ukázkové aplikace, které je možno ihned otevřít a práci s nimi si vyzkoušet. Začít vytvářet svou vlastní aplikaci je velmi snadné. Stačí ji na jeden klik vytvořit. Poté, co je jsme založili aplikaci je dalším přirozeným krokem vytvořit napojení na zdrojová data, ať už jsou to soubory uložené na lokálním počítači či externí databáze, a pomocí editoru pospojovat data z různých zdrojů do požadovaného datového modelu. Poté, co do požadovaného datového modelu nahrajeme, je možné v rámci aplikace vytvořit sešity a v nich a začít data analyzovat a vizualizovat pomocí dostupných nástrojů do požadované podoby. Jak může vypadat konečný výsledek, je možné vidět na obrázku 12.

Obrázek 12: Sešit aplikace Qlik Sense (autor)


39 / 100

4.2.1.2 Qlik Cloud Chystaným

poměrně

zajímavým

řešením

je

z mého

pohledu

Qlik

Cloud.

Jedná se o úložiště aplikací, které jejich autor vytvořil v desktopové verzi na svém lokálním počítači. S Cloudem pak tyto aplikace může zpřístupnit snadno k náhledu, podotýkám pouze k náhledu, dalším uživatelům, kterým dá právo přístupu. Své analýzy, přehledy a zjištění chce každý jejich tvůrce samozřejmě sdílet s ostatními, nicméně ne vždy potřebuje pro své ad hoc analýzy a její zpřístupnění monstrózní a drahé řešení. Qlik Cloud se od samého počátku zdá být zamýšlen jako alternativa k řešení serverovému, které samozřejmě sdílení aplikací má velmi dobře řešeno, nicméně je zamýšlen pro využití v podnicích. Aby mohl uživatel začít využívat funkcionalitu Qlik Cloud, stačí si založit účet, nahrát aplikace vytvořené v desktop verzi a pozvat k jejich náhledu požadované uživatele. V současné době, jelikož je služba/produkt velmi mladý a ve vývoji, je Cloud stále v beta verzi, a to zdarma s omezením na velikost prostoru a počtu uživatelů, kterým zpřístupníte své aplikace. Patrné tedy je zde to, že služba bude zřejmě později nabízena za poplatek, a to možná v určitém „freemium“ modelu, kdy v základní variantě bude služba zdarma, ale v případě potřeby většího využívání bude zpoplatněn v návaznosti na velikost poskytovaného prostoru pro sdílené aplikace a počet uživatelů, kterým své aplikace sdílíte.

Obrázek 13: Qlik Cloud (autor)


40 / 100

4.2.2 QLIK SENSE „SERVER“ Qlik Sense serverové řešení je plnohodnotná platforma pro poskytování SS BI v rámci celého podniku či podnikového útvaru. Serverovému řešení se budu důkladně věnovat v následujících kapitolách, nicméně je nutné říci, že oproti desktopové verzi se liší zejména tím, že běží samozřejmě na serveru. Veškeří uživatelé pak k němu přistupují skrz svůj webový prohlížeč, kde mají po přihlášení ve svém hubu k dispozici všechny své vytvořené nebo zpřístupněné aplikace. Stejně jako v desktopové verzi zde mohou vytvářet své vlastní aplikace a v rámci zpřístupněných aplikací upravovat a vytvářet své vlastní sešity. Následně mohou publikovat veškerou svou tvorbu k náhledu a úpravám ostatním. Serverové

Qlik

Sense

řešení

je

řízeno

centrálně

s pomocí

rozhraní

QMC

(Qlik Management Console), do kterého mají přístup pouze uživatelé s administrátorskými právy. V rámci administračního rozhraní lze z jednoho místa řídit veškeré aspekty takového SS BI řešení, a to i v případě složitější architektury, kdy jsou servery rozmístěny v různých lokalitách. Z QMC lze nastavit vše, od základní konfigurace, přes monitoring, řízení zdrojů, licencí, uživatelů, až samozřejmě po samotné aplikace, publikování, kontrolu a řízení uživatelského obsahu.

4.2.2.1 Licence Na rozdíl od desktopové verze již využívání serverového řešení zdarma není. Pro jeho uživatele je nutné zakoupení licencí. Licenční model Qlik Sense je celkem jednoduchý. Existují pouze dva typy uživatelských přístupů: 

Přístup na uživatele (User Access) Přístup na uživatele znamená, že licence je čerpána pouze pro konkrétního uživatele.

Ten může otevřít jakýkoliv svůj report, a to kolikrát chce a kdy chce. Je vhodný zejména pro uživatele, kteří přistupují k reportům často nebo samozřejmě pro vývojáře. 

Přístup na přihlášení (Login Access) Přístup na přihlášení (Login Access) znamená, že licence je čerpána pro konkrétní

přístup, tedy kohokoliv, kdo se přihlásí nastaveným uživatelským jménem a heslem. Takových přístupů je v rámci jedné licence a každého měsíce možné provést celkem 10, kdy doba jednoho přístupu je 1h. Zákazník nakupuje licence v podobě tokenů, které pak čerpá pro dané přístupy. Je to jakási „měna“, která může být použita pro přidělení odlišného přístupu. Změna mezi přístupy může být provedena po jednom týdnu karantény. Firma se tedy nemusí


41 / 100

strachovat, kolik licencí nakupuje a jestli si nevybrala špatný druh licence. Minimální možný nákup je pět tokenů. Je nutné podotknout, že nákup tokenů je jednorázová investice. Příklad 

3 uživatelé pro častý přístup, každý den i několikrát denně vytvářejí a otevírají reporty



10 obchodníků, kteří si dvakrát měsíčně otevřou report pro ně určený Celkem tedy stačí nakoupit pět tokenů. Tři tokeny jsou čerpány pro tři licence

pro uživatele s častým přístupem, a dva tokeny jsou čerpány na dvacet přístupů v měsíci pro deset obchodníků (1 token pokryje 10 přístupů v měsíci). Cena Cena jednoho tokenu je 1 110 Euro + 20% z ceny za podporu po dobu 1 roku. (Pro první rok je podpora povinná. V rámci podpory je možné kontaktovat zaměstnance dodavatelské společnosti či zaměstnance Qliku a aktualizovat produkt.) Cena licencí byla zjištěna od certifikovaného Qlik partnera pro ČR společnosti KOMIX s.r.o. Samotná aplikace Qlik Sense „Server“ je zdarma a je možné ji nainstalovat například na produkční i testovací server, tokeny mezi nimi se sdílejí. Takže vývojáři mohou pracovat na testovacím serveru a zároveň uživatelé přistupovat k produkčnímu.

4.3 VÝVOJ QLIK SENSE APLIKACE V Qlik Sense se vše točí okolo samotné aplikace. Ta obsahuje informace o datových zdrojích, jsou v ní nadefinovány procedury pro načítání, čištění a transformaci dat do požadovaného datového modelu, data samotná jsou do ní následně uložena, nad daty jsou vytvořeny jejich vizualizace a každý uživatel s touto aplikací následně pracuje, vytváří si vlastní pohledy na data, záložky, vlastní prezentace aj. Každá aplikace v Qlik Sense má v podstatě tři hlavní nástroje, které jsou potřebné k vytvoření aplikace: 

Data Load Editor V rámci skriptu, který má za úkol nahrát data, se aplikace připojí k datovému zdroji

a požadovaná data do aplikace nahraje. V případě potřeby editace skriptu je využíván Data Load Editor.


42 / 100



Data Model Viewer Nástroj umožňuje vývojáři přehledný pohled na strukturu vytvořeného datového modelu

v aplikaci, zobrazovat si náhledy na data v tabulkách a vytvářet ihned kalkulované metriky a dimenze později používané ve vizualizacích v sešitech. 

Sheets V rámci sešitu vývojář využívá různých vizualizací pro zobrazení dat. Využívá k tomu

již vytvořené metriky a dimenze z Data Model Vieweru nebo si definuje své další. Cílem této kapitoly je provést čtenáře v rychlosti tím, jak probíhá vývoj aplikace v Qlik Sense od počátečního připojení k datům, definice datových pump, datového modelování až po připravený vizualizovaný výstup pro další uživatele.

4.3.1 DATA Základem všeho jsou v BI dostupná data. V rámci nástroje Data Load Editor je realizováno vše, co se týká datových zdrojů a datových pump, kterými jsou data načtena z původních zdrojů, očištěna, transformována a nahrána do požadované datové struktury v rámci Qlik Sense.

Obrázek 14: Data Load Editor (autor)

Na obrázku 14 je snímek z Data Load Editoru. V horní části napravo se nachází sloupec, kde jsou nadefinována a uložena datová spojení ke zdrojovým datům, na které se v rámci procedur odkazujeme. Po levé straně jsou sekce, jimiž se kód procedury strukturuje do logických Zavedení Self-Service BI u MVNO GoMobil

43 / 100

částí pro lepší přehled a určení posloupnosti prováděného kódu. V hlavní části uprostřed je pak samotný kód procedury. Dole je otevřen výstup logu, který vrací výstupy spuštěné procedury. Součástí editoru je samozřejmě také debugger, za pomoci kterého se dá procedura krokovat pro potřeby hledání a objevování chyb.

4.3.1.1 Datové zdroje Do Qlik Sense je možné nahrávat data z různých datových zdrojů, v různých formátech, propojovat je dohromady a hledat v nich vazby a souvislosti. V základu je možné nahrávat data z klasických typů souborů, webových zdrojů a databází různých typů, které jsou přístupné přes standardní rozhraní, např. ODBC. Existuje však již také mnoho rozšiřujících konektorů vytvořené dalšími subjekty pro různé datové zdroje. Můžete se tak snadno připojit a získat data ze sociálních sítí, Google Analytics a různých dalších cloudových služeb. Navíc není problém si rozšíření ve formě konektoru na svůj specifický datový zdroj či API vyvinout.

Obrázek 15: Definice ODBC spojení (autor)

Aby se uživatel mohl připojit k datovému zdroji a načetl z něj data, je potřeba v rámci dané Qlik Sense aplikace vytvořit v Data load editoru datové spojení tzv. „data connection“. To spočívá ve výběru typu datového zdroje a jeho identifikaci. V případě XLS souboru je potřeba vybrat typ souboru a následně identifikovat jeho umístění na serveru. V případě připojení k databázi je situace trošku složitější. Při využití ODBC pro připojení k relační databázi MySQL, je nutné nejdříve definovat spojení v OS. Nejdříve se vytvoří logický název DSN (Data Source Name) v systému, kde je Sense nainstalován. DSN záznam drží informace o využívaném ovladači a další informace, které jsou vyžadovány pro přístup k datovému zdroji. Následně pak může být ODBC spojení použito v Qlik Sense aplikacích. Na obrázku 15 můžete vidět administrátorské rozhraní pro správu ODBC spojení na Windows serveru a dále to, co vidí následně uživatel při definování datového spojení v Sense. Zavedení Self-Service BI u MVNO GoMobil

44 / 100

4.3.1.2 Data load skript Pro vytvoření datových pump, tedy nahrání dat do Qlik Sense, se využívají speciálního skriptovacího jazyka, což je určitý mix jazyků, který si vypůjčil mnoho z různých jazyků, např. SQL, JavaScript nebo VB.NET. Celkem pozitivní zpráva je pak ta, že je na 100% shodný s tím, co je využíváno při psaní procedur v QlikView, a proto procedury napsané zde budou fungovat i v Qlik Sense. V jednoduchých případech je skript generován automaticky samotným nástrojem, nicméně ve většině případů je nutná přinejmenším lehká úprava kódu, aby datový model vypadal podle našich představ a byl schopný později naplnit našich BI cílů. V předešlé kapitole jsem nastínil definici datového spojení k externí MySQL databázi přístupné přes ODBC. Nyní již tedy naše aplikace čeká pouze na to, aby do ní byla data z tabulek oné databáze nahrána. V první řadě je potřeba identifikovat konkrétní tabulku v dané databázi a vybrat potřebné sloupce. Qlik Sense dle vybraných tabulek a sloupců sám generuje skript, který bude určitým startovním bodem v definici naší datové pumpy. Vše ukážu na následujícím příkladu. Chceme z naší databáze načíst dvě velice jednoduché tabulky – Kontakty a k nim příslušné Služby, které mají na kontakty vazbu. Tyto dvě tabulky jsou ve vzahu 1:N. Pomocí Qlik Sense se připojíme do databáze a vybereme zaškrtnutím požadované tabulky a sloupce. Po takto provedeném výběru je nám automaticky vygenerován skript, který může vypadat například následujícím způsobem:

LIB CONNECT TO 'test'; LOAD id, kontakt_id, timestamp, nazev; SQL SELECT id, kontakt_id, timestamp, nazev FROM databaze_test.sluzby; LOAD id, typ, subjekt, ic; SQL SELECT id, typ, subjekt, ic FROM databaze_test.kontakty;


45 / 100

Jak je z kódu patrné, na prvním řádku je tzv. connection string, kdy se procedura připojuje ke konkrétnímu datovému zdroji, v tomto případě ke spojení s názvem „test“. Následně se provede načtení požadovaných dat z tabulky „sluzby“ z databáze „databaze_test“ a uloží se do aplikace. To samé by se provádělo následně pro tabulku s názvem „kontakty“. Tímto však naše práce není u konce, nyní přichází na řadu nutná ruční úprava samotného kódu. Datový model v Qlik Sense není před nahráváním dat předem definován, obnovuje se při každém spuštění LOADu dat, a je tedy proto nutné dbát při vývoji procedur zvýšené opatrnosti. Na druhou stranu je toto řešení velmi flexibilní a výboj aplikací je opravdu rychlý. Qlik Sense ani QlikView neznají pojem referenční integrita a tato problematika je tedy plně v rukou vývojáře samotného. Vztahy jsou mezi jednotlivými tabulkami vytvářeny velice jednoduše

pouze

na základě shodných

názvů

sloupců

daných

tabulek nahraných

do Qlik Sense aplikace. Abychom tedy propojili v naše vybrané tabulky, je nutné vygenerovaný skript pozměnit do podoby, aby ID v tabulce „kontakty“ odpovídalo názvem jeho referenci v tabulce „sluzby“. Přejmenování daných sloupců je velmi jednoduché, a to s použitím klauzule AS. Pro další budoucí vývoj se následně také hodí přejmenování tabulek, pro přehlednost i názvů ostatních sloupců tabulky a přidání meta informací pro snadnější pozdější úpravy a pochopení skriptu. Upravený skript pak může vypadat následujícím například způsobem:

LIB CONNECT TO 'test'; Sluzby: LOAD id AS sluzba_id, kontakt_id, Date(Floor(timestamp)) AS sluzba_datum, nazev AS sluzba_nazev; SQL SELECT id, kontakt_id, nazev FROM databaze.sluzby;

// připojení k databázi // přejmenování tabulky na Sluzby

Kontakty: LOAD id AS kontakt_id, typ AS kontakt_typ, subjekt AS kontakt_nazev, ic AS kontakt_ic; SQL SELECT id, typ, subjekt, ic FROM databaze.kontakty;

// přejmenování tabulky na Kontakty


// reference na kontakt_id z tabulky Kontakt // úprava datumu a přejmenování

46 / 100

4.3.1.3 ETL ETL (Extract, Tranform, Load), neboli datová pumpa, je procedura, kterou jsou nahrávána data z primárních datových zdrojů do jiných datových struktur/databází při nichž probíhá jejich transformace a čištění. Jak jsou data nahrávána do datových struktur Qlik Sense je jednoduché vysvětlit na samotném principu ETL. 

Extract Extrakcí je myšleno připojení se k primárním datovým zdrojům a definování

požadovaných dat, která se budou ze souborů, databází, webových či jiných zdrojů nahrávat. 

Tranform Transformací dat je myšlena manipulace s daty s použitím skriptovacího jazyka s cílem

dosáhnutí požadované datové struktury. V našem případě to v předešlých případech znamenalo přejmenovávání tabulek, polí či využití funkcí pro úpravu datumů. Dalšími typickými transformacemi jsou například nová kalkulovaná pole, pojmenovávání číselných hodnot do smysluplně podoby, joinování tabulek, agregace hodnot aj. 

Load Posledním krokem je pak samotný load dat, což v Qlik Sense představuje spuštění

daného skriptu a nahrání dat do aplikace.

4.3.1.4 Datové modelování „Cílem datového modelování v Qlik Sense je vytvoření takové datové struktury, datového modelu, který umožní efektivní práci s daty.“ (Qlik) Datové modelování v Qlik Sense se nikterak neliší od principů Business Intelligence datového modelování v jiných architekturách. Vždy to tedy znamená, že je potřeba vytvořit do určité míry normalizované struktury tabulek ve STAR nebo SNOWFLAKE schématu, které umožní se na data dívat z různých úhlů pohledu, multidimenzionálně, a rychle, efektivně s nimi pracovat. Ústřední roli hraje v datovém modelu jedna nebo více tabulek faktů, které v sobě drží všechny sledované ukazatele a samozřejmě reference na dimenze, a to vše v požadované granularitě. V okolí tabulky faktů jsou pak tabulky dimenzí se všemi potřebnými atributy. Příklad takto uspořádané tabulkové struktury je možné vidět na obrázku 16.


47 / 100

4.3.1.5 Datový model Jak již bylo řečeno, asociace mezi tabulkami jsou identifikovány na základě společných názvů jednotlivých polí rozdílných tabulek vždy při novém spuštění skriptu. Po doběhnutí skriptu je možné výslednou datovou strukturu, propojení tabulek a náhled na detailní data kontrolovat v nástroji Data Model Viewer. Abychom změnili strukturu v případě chyby, stačí pouze změnit název jednotlivých polí tabulek ve skriptu v Data Load Editoru a spustit daný skript znovu. Jak takový náhled na datový model může vypadat, je možné vidět na následujícím obrázku 16. Po té, co jsou data nahrána z primárních dat, vytvořeny asociace mezi jednotlivými tabulkami a poli, jsou uložena v dané aplikaci. Ta tvoří ústřední prvek Qlik Sense. Při práci s aplikací jsou veškerá data uložena v operační paměti počítače nebo serveru. Práce s ní probíhá vždy bez připojení na primární zdroje dat. V případě aktualizace dat je nutné vždy znovu spustit skript a nahrát do aplikace data nová, aktuální. V rámci nástroje Data Model Viewer je kromě kontroly asociací mezi tabulkami a jednotlivými poli samozřejmě možný detailní náhled na nahraná data. Z nástroje Data Model je také možné ihned vytvářet odvozené dimenze a metriky.

Obrázek 16: Datový model Qlik Sense (Qlik)


48 / 100

4.3.2 VIZUALIZACE DAT Předpokladem pro vytváření vizualizací je mít v dané aplikaci nahraná požadovaná data z primárních zdrojů. Po té, co je tak učiněno, je možné v rámci dané aplikace vytvořit jeden nebo více sešitů a v nich s pomocí metrik, dimenzí a dostupných komponent v podobě upravitelných grafů, tabulek, výběrů a dalších vyvářet požadované interaktivní vizualizace dat.

4.3.2.1 Sešity Založit sešit je velice snadné na jedno kliknutí ihned po otevření aplikace v jejím přehledu. Následně můžete ihned snadno principem drag & drop vkládat dostupné komponenty na pracovní plochu sešitu. Když je komponenta na pracovní plochu vložena, je potřeba ji asociovat s vybranými dimenzemi a metrikami, jak je naznačeno na obrázku 17.

Obrázek 17: Sešit aplikace Qlik Sense (autor)

Jak je patrné, plocha uvnitř sešitu je rozdělena na tři hlavní části. Ústřední roli hraje pracovní plocha uprostřed, která představuje tu část, kterou posléze uvidí uživatel a bude s ní interagovat. Na ni vývojář vkládá komponenty pro vizualizaci dat, asociuje je s metrikami a dimenzemi a následně upravuje do požadované podoby. V levém postranním panelu se nacházejí všechny v současné době dostupné komponenty pro vizualizaci dat. Ve druhé záložce v levém postranním panelu má vývojář všechny dostupné pole/sloupce tabulek napříč celým datovým modelem, které může použít jako dimenze nebo jako metriky, nebo je využít jako filtry dat pro výběry. Ve třetí záložce jsou pak uložené tzv. „master items“, což jsou definované metriky, dimenze a vytvořené vizualizace, které lze používat opakovaně napříč všemi sešity v rámci dané aplikace. Typickým příkladem jsou kalkulované či „drill-down“ dimenze, kalkulované metriky nebo vizualizace, které je potřeba využívat napříč více sešity. Zavedení Self-Service BI u MVNO GoMobil

49 / 100

Pravý postranní panel je dynamický a váže se vždy k označené komponentě na pracovní ploše, která je právě upravována. Na panelu je možné detailně nastavit jednotlivé metriky a dimenze a vzhled grafického vyjádření dat uvnitř komponent.

4.3.2.2 Zásady tvorby vizualizací Při vytváření aplikací by se měli jejich tvůrci držet několika zásad, aby pro uživatele byla práce intuitivní a jednoduchá. Pracovní plocha v Qlik Sense není nafukovací, jednotlivé komponenty mají určitý minimální rozměr. Při návrhu sešitů by se měl jejich tvůrce držet klasických zvyklostí při tvorbě dashboardů/reportů, nicméně Qlik explicitně ve svých doporučeních vypisuje následující pravidla: První z pravidel je dodržování určité konzistence rozmístění a vlastností komponent napříč sešity v rámci dané aplikace, potažmo všech aplikací. Konzistentní rozmístění a design pomáhá k rychlejšímu zorientování a lepšímu pochopení. Ke správnému návrhu zobrazení dat a předání informace uživateli vede určitá cesta. V první řadě je nutné pochopení dat samotných – jaký typ dat je to, jak jsou mezi sebou data propojena, co je zamýšleno být daty komunikováno? Pro standardní typy sdělovaných informací měly být použité zažité vzorce jejich zobrazování. Zobrazuji-li určitou metriku v čase, např. počet prodaných kusů určitého produktu, použiji obecně známý spojnicový graf, čímž je redukována nutnost pochopení principu grafu samotného. Poté, co je zvolen typ vizualizace, je potřeba upravit daný výstup ještě tak, aby byl pro uživatele co nejvíce „stravitelný“, co se týče zobrazovaných dat v grafu. Využívá se takových technik jako barevné rozlišení, velikost, pozice, tvary atd. Každý sešit by měl být přehledný a čistý. Vizualizace dat by měly hrát centrální roli uvnitř každého sešitu a vždy by mělo být na první pohled patrné, čemu a o jaké KPI se aktuálně jedná. S tím souvisí, že by v každém sešitu mělo být jen omezené množství sledovaných KPI, a to dále ještě vyobrazených a umístěných dle priorit. Je potřeba navrhnout aplikaci vždy tak, aby uživatelé mohli provádět „drill-down“ v datech a zkoumat je na nejnižší možné míře detailu. Příkladem je časová dimenze. Uživatelé vždy chtějí zobrazovat data nejen po letech ale i například kvartálech, měsících, týdnech či dnech. Nástroj by jim pak měl umožnit rychlé a jednoduché klouzání po těchto úrovních v rámci dimenzí. Co se týče barevnosti návrhů, nemělo by se zapomínat na uživatele, kteří mají problém s rozpoznáváním barev. Návrháři by se měli vyvarovat nadměrnému užívání červenozelených


50 / 100

kombinací k vyobrazení indikátorů, jelikož tyto barvy nejsou rozeznatelné pro uživatele s těmito indispozicemi.

4.3.3 PŘÍPRAVA APLIKACÍ PRO OSTATNÍ UŽIVATELE Aby byla práce pro uživatele ke zkoumání vytvořených sešitů a následné jejich další analýzy co nejjednodušší a nejefektivnější, je potřeba jim k tomu samotnou aplikaci a prostředí připravit.

4.3.3.1 Znovupoužitelné „master items“ Jak již bylo vysvětleno, master items jsou dimenze, metriky a vizualizace, které mohou být znovupoužity napříč celou aplikací. Tedy nemusí být uživateli stále dokola definovány při jejich častějším použití, což má přínos zejména v úspoře času a redukci možných chyb. Za druhé jsou pak master items z publikovaných sešitů užívány uživateli pro jejich osobní analýzy. Je poměrně velmi časté, že pouhá definice dimenze nebo metriky je velmi složitá. Master items zabezpečují to, že uživatelé používají metriky/dimenze/vizualizace, které jsou pravdivé a zároveň schváleny. Takovýto přístup umožňuje, aby byla napříč celou organizací mezi všemi uživateli a konzumenty informací nastolena pouze jediná verze pravdy.

4.3.3.2 Záložky Při analyzování dat se může snadno stát, že jejich uživatel narazí na nějaké zajímavé zjištění, ke kterému by se později rád vrátil nebo ho sdílel s ostatními. K takovému účelu slouží záložky, což není nic jiného než pro sešit uložená určitá množina selekcí v datech a umožňuje tak se vrátit zpět do bodu, ve kterém se nacházel před uložením.

Obrázek 18: Záložky Qlik Sense (autor)


51 / 100

4.3.3.3 Formální záležitosti Pro lepší orientaci uživatelů je na místě danou aplikaci a sešity v ní obohacovat o popisky, které napomohou k nalezení požadované aplikace v hubu dostupných aplikací či sešitů v rámci dané aplikace. Pro snadnější identifikaci pak je pak také možné přidat aplikaci její grafickou ikonu.

4.3.4 PRÁCE S VIZUALIZACEMI Práce s aplikací Qlik Sense je pro uživatele velmi jednoduchá a intuitivní. Výbornou vlastností, což vyplývá z asociativního propojení dat zmíněné v kapitole 4.1.2, jsou výběry dat. Jak může vypadat takový výběr, je možné vidět na následujícím obrázku s již vytvořenou aplikací a sešitem. Jedná se o dashboard týkající se produktů. Provedl jsem pouze jednoduchý výběr kategorie produktů a následně vybral konkrétní produkt ve vizualizaci zobrazující výnosy dle produktů. Po jakémkoliv provedeném výběru se změny ihned projeví i v ostatních vizualizacích dat v rámci sešitu i aplikace, na které má daný výběr asociaci.

Obrázek 19: Výběry v Qlik Sense (autor)

Nástrojů pro výběry dat má Qlik Sense hned celou řadu. Ve všech grafech je například možné používat „lasso selection“, viz obrázek 20, které přijde vhod v případě složitějších selekcí v grafech. Výborným pomocníkem je pak „search tool“, který je zase užitečný zejména v případě velkého počtu možných hodnot dimenzí, které nemusí být ani v sešitě nijak vyobrazeny. S nimi je možné vytvářet selekce pro zobrazení potřebných dat pouze vyhledáním a vybráním dané dimenze/dat. V neposlední řadě je pak u některých typů grafů možné využívat „scrolling“ pro vyhledávání dat na větším stupni detailu pro následné provedení selekce.


52 / 100

Obrázek 20: „Lasso Selection“ v Qlik Sense (autor)

4.4 SERVEROVÉ ŘEŠENÍ A NASAZENÍ 4.4.1 ARCHITEKTURA Serverové řešení Qlik Sense je navržené tak, aby uspokojilo i ty nejnáročnější organizace provozující BI řešení pro své uživatele po celém světě. Tomu samozřejmě musí odpovídat i jeho architektura. Ta je v Qlik Sense distribuovaná, což má pozitivní vliv na odolnost systému, snižují se tím nároky na údržbu a naopak zvyšuje flexibilita nasazení celkového BI řešení.

4.4.1.1 Site & node Qlik Sense „site“, představuje jedno řešení, které se dále skládá z několika jednotlivých „nodes“, česky uzlů. Uzly jsou de facto fyzické servery, které jsou vždy napojeny do jednoho společného centrálního uzlu. Typická Qlik Sense instalace obsahuje jeden centrální uzel, na kterém jsou uložena veškerá potřebná data. Navíc však mohou být volitelně součástí další uzly, které mají zejména smysl při napomáhání zvyšování výkonu a odolnosti celého řešení. Všechny jsou pak napojeny do jednoho centrálního uzlu, který celý systém řídí. Veškerá data jsou pak synchronizována napříč jednotlivými uzly.


53 / 100

4.4.1.2 Servises Základem distribuované architektury Qlik Sense jsou jednotlivé „services“, tedy služby, které mohou být samozřejmě nasazeny různými způsoby, aby splňovali unikátní potřeby zákazníka. Uvnitř Qlik Sense běží následující služby:

QRS (Qlik Sense Repository Service) QRS má na starosti řízení a synchronizaci jednotlivých aplikací, licencí, bezpečnosti a detailního nastavení v distribuované multi-node architektuře Qlik Sense. Připojuje se ke QRD a je potřebná ostatními aplikacemi k tomu, aby bylo vůbec možné spustit a pracovat s uloženými aplikacemi. Navíc drží informace o aplikacích a cestách k jejich k binárním souborům uloženým na disku v souborovém systému daného stroje. QRS na centrálním uzlu řídí synchronizaci na další uzly v dané architektuře.

QRD (Qlik Sense Repository Database) QRD je využívána výhradně pro potřeby QRS. Do databáze PostgreSQL se QRS připojuje, čte a zapisuje do ní pro svou potřebu. Na databázi je QRS závislá, proto je QRD vždy první ze služeb, která se spouští. Jsou v ní uložena všechna potřebná data pro potřebu systému.

QPS (Qlik Sense Proxy Servise) Jak už samotný název napovídá, QPS je služba, která má na starosti přístupy uživatelů, autentizace, relace a vyrovnávání zátěže. QPS společně se QRS komunikuje s adresářovými službami, např. MS Active Directory, pomocí protokolů LDAP nebo ODBC s cílem načtení a řízení přístupu uživatelů.

QSS (Qlik Sense Scheduler Servise) Služba QSS řídí vše, co se týká „reloadingu“ dat aplikací a jejich automatického spouštění na základě vydefinovaných triggerů.

QES (Qlik Sense Engine Servise) QES je výpočetní jednotka Qlik Sense. Má na starosti veškeré výpočty a logiku v aplikacích.


54 / 100

4.4.1.3 Single-node architektura Na obrázku 21 je vyobrazena základní architektura instalace s jedním centrálním uzlem, serverem. Jsou v ní obsaženy všechny Qlik Sense služby, ostatní důležité entity, jejich vztahy a popsán princip komunikace mezi nimi.

Obrázek 21: Single-node architektura (Qlik)

V obrázku se vyskytují dvě dosud neznámé entity. První z nich je Client, což je klasický uživatel, který se připojuje pomocí webového prohlížeče k hubu a následně vytváří a pracuje s aplikacemi. Druhou entitou je již zmíněný QMC (Qlik Sense Management Console), což je nástroj pro centralizovanou správu celého řešení. Detailně je popsán v kapitole 4.4.2.2.

4.4.1.4 Multi-node architektura Jak již bylo řešeno, multi–node architektura je vytvářena s cílem ovlivnění výkonu a zvýšení odolnosti proti náhlým událostem. Nicméně toto řešení přichází vhod i v jiných situacích. Může být ideální pro globální organizace a řešení s potřebou mít servery umístěné blíže jejich uživatelům za účelem poskytnutí služeb v dostatečné kvalitě. V rámci multi-node architektury běží instance QRS na každém z uzlů. Instance QRS běžící na centrálním uzlu je ovšem brána jako „master“. QRS běžící na „slave“ uzlech mají přístup pouze do lokálních QRD oproti centrální QRS, která má přístup do centrální databáze a tuto databázi má za úkol synchronizovat do ostatních uzlů s lokálními databázemi.


55 / 100

QSS nainstalovaná na centrálním „master“ uzlu má za úkol zase koordinovat všechny úkoly, které spadají do jejích kompetencí. V případě multi-node architektury je Qlikem doporučováno mít na centrálním nodu nainstalovaný dedikovaný QPS a QES pouze pro účely QMC.

4.4.2 VYTVOŘENÍ SITE Všechny produkty Qliku jsou velmi pevně svázány s produkty společnosti Microsoft, proto ani není divu, že je k serverové instalaci potřeba Microsoft Windows Server. Pro produkční účely je vyžadována minimálně 64bit verze Microsoft Windows Server 2008 R2, tím pádem i 64bitovým multi-core procesorem a s doporučenou operační pamětí RAM ve výši minimálně 8 GB. Nicméně její skutečně potřebná výše je samozřejmě odvislá od náročnosti a požadavků konkrétního zákazníka. Qlik Sense pro svůj běh potřebuje mít nainstalovaný .NET Framework ve verzi 4.0 a databázi PostgreSQL, které jsou součástí instalačního balíku. Nutný je samozřejmě přístup do sítě Internet. Samotná instalace pak vyžaduje přibližně 500 MB místa na disku serveru plus samozřejmě další místo pro aplikace, databázi aj.

4.4.2.1 Instalace Instalace Qlik Sense je velmi jednoduchá a rychlá. Osobně jsem vyzkoušel nainstalovat Qlik Sense na virtuální server, který splňoval dané minimální požadavky, tedy 64bit platforma, Windows Server R2, 8 GB RAM. Po připravení serveru je potřeba si stáhnout instalační EXE soubor Qlik_Sense_setup.exe ze stránek Qlik.com. Instalace Qlik Sense v single-node architektuře pak probíhá následovně. 1. Před samotnou instalací je potřeba si samozřejmě zkontrolovat, zdali uživatel, který Qlik Sense instaluje, je k takovým činům oprávněn. Je potřeba, aby měl na serveru odpovídající administrátorská práva k instalaci softwaru. 2. V prvním kroku uživatele průvodce vyzve k výběru způsobu instalace, kdy dostává na výběr mezi QUICK a CUSTOM verzí instalací. Rozdíl mezi nimi je ten, že v případě rychlé instalace se na aktuální server nainstalují všechny služby Qlik Sense. V případě volitelné instalace si může uživatel vybrat jaké služby si na server/počítač nainstaluje, což se hodí v případě multi-node architektury. My v případě single-node vybíráme „Quick Installation“. 3. Další krok obsahuje odsouhlasení podmínek. Po pročtení podmínky odsouhlasíme. 4. Ve třetím kroku je potřeba vytvořit heslo pro „superuser-a“ pro přístup k databázi QRD. Pokud již tato databáze existuje, je uživatel vyzván k zadání hesla. 5. Následně je uživatel vyzván k zadání přihlašovacích údajů k Windows Serveru. Ponecháním nezaškrnutého checkboxu budou služby nainstalovány a spuštěny pod současným


56 / 100

uživatelem. Pokud chceme, aby byla instalace Qlik Sense považována za centrální uzel, naopak necháme zaškrtnutý druhý daný checkbox. 6. V dalším kroku je vyzván uživatel k zadání adresy zařízení, typicky doménovému jménu, skrz který budou ostatní případné uzly a uživatelé ke Qlik Sense přistupovat. 7. Potvrdíme vytvoření ikon na plochu a odklikneme počátek instalace. 8. Po dokončení instalace se uživateli objeví okno s přehledem běžících nainstalovaných služeb. 9. Pokud se QMC neotevřela automaticky, je potřeba ji spustit přes vytvořenou ikonu na ploše či otevřít webový prohlížeč a zadat adresu https://nazev_pocitace/qmc. Následně se při prvním pokusu o přihlášení do QMC objeví typická hláška ohledně nedůvěryhodného SSL certifikátu. Po odkliknutí, že jsme si vědomi bezpečnostního rizika, následuje dialogové okno, které nás vybízí k přihlášení. Po přihlášení se dostáváme do QMC, kde jako jeden z prvních kroků můžeme udělat to, že nainstalujeme vlastní SSL certifikáty či povolíme nezabezpečenou http komunikaci. Preferována je samozřejmě první varianta.

4.4.2.2 Qlik Sense Management Console (QMC)

Obrázek 22: Qlik Sense Management Console (autor)

QMC je webový nástroj pro centrální správu pro nastavování, administraci a monitoring celého řešení.

QMC se připojuje vždy k centrálnímu uzlu, který obsahuje všechna systémová

data a ze kterého se vše do slave uzlů synchronizuje. Z jednoho místa je tak možné spravovat celé řešení. Jak je možné vidět na obrázku 21, umožňuje administrátorům řídit vše, co se týče


57 / 100

obsahu a jednotlivých uživatelů, úloh, bezpečnostních pravidel, datových spojení, licencí, uživatelských přístupů až po konfiguraci jednotlivých uzlů a služeb na nich běžících.

4.4.2.3 Aktivace licence Poté, co je instalace dokončena, je nutné aktivovat v QMC zakoupenou licenci. Jak je již vysvětleno v kapitole 4.2.2.1, licence jsou v Qlik Sense postaveny na bázi tokenů, které si zákazník nakupuje pro své uživatelské přístupy. V rámci jednoho řešení, tedy i řešení v multi-node architektuře jsou licence mezi uzly sdíleny a není potřeba pro každý uzel nakupovat speciální tokeny. Při nákupu licencí Qlik Sense zákazník typicky obdrží licenční klíč a kontrolní číslo. Zadáním těchto čísel je následně z licenčního serveru stažen tzv. Licence Enabling File (LEF), který určuje počet dostupných tokenů pro Qlik Sense řešení. V případě nedostupnosti internetu je možné vložit LEF ručně. Po jejím načtení může být systém naplno využíván.

Obrázek 23: Nastavení licencí v Qlik Sense (autor)

4.4.2.4 Alokace uživatelských přístupů Jakmile je aktivována licence a dostupné tokeny, je potřeba je alokovat mezi uživatele. V první řadě je potřeba sobě samému, jako adminstrátorovi, alokovat uživatelský přístup (User Access), abyste mohli kdykoliv přistupovat k hubu a aplikacím. Za druhé je potřeba alokovat přístupy pro další uživatele a případně jim přidat typ administrátorského přístupu. Alokování ať už USER či LOGIN ACCESS, které jsou blíže vysvětleny v kapitole 4.2.2.1, lze provést v QMC v sekci „Licence and tokens“ prostým alokováním jednoho z přístupů vybranému uživateli. Abychom však mohli uživatelům přístupy přiřadit, je nejdříve nutné načíst samotné uživatele. To lze provést za pomoci „User Directory Connector-u“, který umožňuje se Zavedení Self-Service BI u MVNO GoMobil

58 / 100

připojit k adresářovým službám a dané uživatele prostě načíst. Vytvoření konektoru a synchronizaci uživatelů s adresářovými službami je možné provést v relevantní sekci v menu QMC. Přiřazování administrátorských rolí probíhá v QMC v sekci USERS. Administrátorských rolí je hned několik typů – RootAdmin, DeploymentAdmin, AuditAdmin, SecurityAdmin, ContentAdmin. Každý typ pak samozřejmě má odlišná práva. Jednomu uživateli je možné přidat více typů administrátorských rolí. Uživatelé bez administrátorských práv nejsou samozřejmě oprávněni k přístupu ani do QMC. Naopak uživatelé s administrátorským přístupem budou moci přistupovat ke QMC a jsou oprávněni jen k takovým krokům, které odpovídají typu jejich přiřazené administrátorské role.

4.4.3 CONTENT MANAGEMENT Nejzajímavější částí Qlik Sense se týká samotné správy a řízení obsahu, jelikož o tom to celé je. V Qlik Sense probíhá řízení obsahu dle modelu na obrázku 24. Aplikace a její vývoj začíná u Qlik Sense developera. Ten se připojuje ke zdrojům dat, navrhuje datové pumpy, datový model a nahrává první data, následně pak vytváří vizualizace v sešitech. Aplikace vytváří buď s pomocí Qlik Sense Desktop na svém lokálním počítači nebo po připojení k hubu přes webové rozhraní. Jak desktopová tak serverová verze skrze prohlížeč nabízejí stejnou funkcionalitu a rozhraní pro práci je na první pohled nerozeznatelné. V případě vytvoření aplikace v desktopové verzi na lokálním počítači developera je potřeba vytvořenou aplikaci uloženou v QVF souboru nahrát skrz QMC na server. V případě vytvoření aplikace v hubu na serveru není potřeba nic importovat, aplikace již je na serveru uložena. Poté, co je aplikace vytvořena a je schopna publikace, přichází do hry admin (zjednodušeně), který musí zabezpečit, aby se aplikace dostala pouze uživatelům, kterým je určena, a byl nastaven pravidelný reloading dat pro její aktuálnost.


59 / 100

Obrázek 24: Řízení obsahu v Qlik Sense (Berg, 2014)

Základní nástrojem pro shlukování souvisejícího obsahu jsou v Qlik Sense tzv. „streams". Jsou to opravdu česky kanály, do kterých jsou jednotlivé aplikace zařazovány. Je opravdu jen na organizaci samotné, jak bude struktura kanálů vypadat, nabízí se např. funkční struktura – marketing, obchod, finance, provoz atd. Je pak například možné nastavit, aby do jednotlivých kanálů mohli jen určení zaměstnanci. Toho je poměrně snadné docílit nastavením jednoduchých pravidel, které zabezpečí, že se kanály a jejich aplikace zobrazí v hubu pouze těm uživatelům, kterým mají. S pomocí QMC je možné nastavit taková pravidla, která umožňují administrátorovi řídit, jaké kanály a aplikace uživatel může vidět a co může dále v aplikacích dělat a využívat. Poté, co je aplikace vytvořena či importována, ji administrátor v QMC publikuje do odpovídajícího kanálu.

Obrázek 25: Kanály souvisejících aplikací (autor)

U většiny aplikací se samozřejmě časem budou měnit a nabývat zdrojová data. Aby daní uživatelé měli vždy aktuální data v aplikacích pro potřeby svého rozhodování, je potřeba Zavedení Self-Service BI u MVNO GoMobil

60 / 100

aplikacím nastavit pravidelný reload dat. V Qlik Sense toto znamená, že je potřeba dané aplikaci vytvořit nový RELOAD TASK, který bude automaticky spouštět ve vydefinovanou dobu v určených intervalech skript dané aplikace a tím aktualizuje všechna data. Dle povahy dat a aplikací se nabízí nastavit úlohy tak, že budou spouštěny např. v nočních hodinách, kdy se předpokládá nízká zátěž serveru. Samozřejmě při velkém množství dat, kdy se v datovém modelu objevují velké tabulky o milionech záznamů, ani spouštění automatických úloh v nočních hodinách nemusí být ideální. Je potřeba tedy řešit načítání dat přírůstkově, které je samozřejmě i u Qlik Sense možné. Jak je řešeno přírůstkové načítání dat u GoMobil se můžete dočíst v kapitole 5.2.6.5.

4.4.3.1 Logika a interakce jednotlivých prvků Jak spolu komunikují jednotlivé prvky dostupné v QMC a jak jsou provázané je názorně nastíněno na následujícím obrázku 26. Aplikace, sešity a „stories“, které jsou vytvářeny skrz hub nebo naimportovány, jsou publikovány uživatelům administrátorem v QMC. Reloading aplikací je prováděn na základě definovaných úloh, které se spouštějí v definovaný čas. Úlohami je řízena také automatická pravidelná synchronizace uživatelů s adresářovými službami. Definovaná bezpečnostní pravidla určují, kteří uživatelé mají jaký přístup k jakým kanálům a aplikacím. Licence poskytuje odpovídající počet tokenů, které jsou alokovány pro jednotlivé uživatele, a každému z nich je přiřazen určitý typ přístupu.

Obrázek 26: Logika a interakce jednotlivých prvků v Qlik Sense (Qlik)


61 / 100

4.5 SHRNUTÍ Kapitola navazuje na předešlou teoretickou část. Věnuje se jednomu z nejvyspělejších SS BI řešení v současnosti na trhu, nástroji Qlik Sense. Na začátku kapitoly jsou vyjmenovány a popsány základní a nejdůležitější vlastnosti a charakteristiky daného nástroje, podle kterých čtenář dokáže ihned v návaznosti na předcházející kapitolu zhodnotit, do jaké míry splňuje Qlik Sense požadavky kladené na SS BI nástroje. V následující podkapitole je popsána desktopová a serverová verze Qlik Sense, jejich charakteristiky a rozdíly. Následně na to je popsán vývoj aplikací od samotného připojení ke zdrojovým datům, přes návrh datových pump, datového modelu až po tvorbu vizualizací dat a práci s uživatelským rozhraním. Jako poslední je popsána architektura serverové verze. Na základě praktických zkušeností je popsán postup při nasazení single-node řešení na Microsoft Windows Server a vysvětleny další potřebné kroky nastavení za účelem plného zprovoznění. V poslední části práce se čtenář dozvídá, jak v Qlik Sense probíhá řízení a publikace obsahu. Svým „data discovery“ zaměřením, vlastnostmi, možnostmi a poskytovanými nástroji umožňuje uživatelům provádět své vlastní analýzy, zkoumání tvorbu reportů a sdílení informací. Na druhou stranu poskytuje IT pracovníkům nástroje pro důkladný monitoring, audit a řízení, které jsou v případě SS BI řešení nezbytné. Qlik Sense se mi zdá být jako perfektní a jednoduché řešení pro menší či středně velké organizace, kde je velká potřeba po SS BI ze strany uživatelů. V následující kapitole bude na reálné situaci a požadavcích u MVNO GoMobil demonstrován postup a popsány jednotlivé kroky vývoje SS BI řešení na platformě Qlik Sense.


62 / 100

5 SS BI ŘEŠENÍ PRO MVNO GOMOBIL V návaznosti na předešlé kapitoly se nyní zaměřím na konkrétní BI řešení pro společnost TERMS a.s., která založila a v současné době provozuje mimo jiné mobilního virtuálního operátora GoMobil. SS BI přístup v kombinaci s platformou Qlik Sense je z mého pohledu z mnoha důvodů ideálním řešením. Jednoduše již samotný SS přístup by dobře zapadal do podnikové kultury a řešil by spoustu současných problémů a potřeb. Na druhou stranu Qlik Sense je pro svou jednoduchost architektury, snadným nasazením, správou, vývojem aplikací, škálovatelností, snadnou integrovatelností s ostatními aplikacemi, otevřeností, celkem nízkou pořizovací cenou licencí a jednoduchostí pro uživatele naprosto ideálním řešením, co se do použitých technologií týče. Obsahem této kapitoly je nastínit postup řešení projektu SS BI. Následně bude zaměřen zrak přímo na společnost TERMS a.s., identifikovány konkrétní přínosy BI, reps. SS BI, pro MVNO GoMobil a následné zpracováno řešení přírůstku BI na platformě Qlik Sense od samotné specifikace uživatelských požadavků až po dodání daných výstupů/reportů.

5.1 PROJEKT BI Projekty BI jsou velmi komplexní a svým určením, použitými technologiemi a úlohami velmi specifické. Na základě těchto skutečností jsou stavěny na pro ně určených metodikách, při kterých je užíváno metod, které jsou specifické pouze pro daný typ projektu. Tradiční klasický BI projekt se skládá z několika úloh. Každá úloha obsahuje set činností, které je potřeba v jejím rámci vykonat a splnit. Úlohy na sebe vzájemně navazují a výstupy z každé z nich pak slouží přirozeně jako podklad pro úlohy následující. Stručně zde popíši jednotlivé úlohy. Obsah jednotlivých úloh vychází z informací dostupných na dříve zmíněném portálu MBI (Management of Business Informatics) vyvíjeného na katedře IT Vysoké školy ekonomické v Praze. 

Zpracování úvodní studie Zpravidla BI projekt začíná jeho plánováním a zpracováním úvodní studie, která má za cíl

zmapovat prostředí, do kterého bude řešení BI zasazeno, určit přístup k řešení, vydefinovat priority v rámci podnikových procesů a sestavit celkovou koncepci řešení. 

Specifikace přírůstku řešení Po té, co je zpracována úvodní studie, následuje úloha specifikace přírůstku řešení,

jejímž výstupem by mělo být vymezení a popis aktuálně zpracovávané oblasti. Slouží jako výchozí bod pro analýzu stavu a požadavků. Zavedení Self-Service BI u MVNO GoMobil

63 / 100



Analýza stavu a požadavků Cílem analýzy stavu a požadavků je na jedné straně zhodnocení aktuálních uživatelských

požadavků, na straně druhé pak zhodnocení všech současných existujících aplikací, dostupnosti a kvality dat. V neposlední řadě je potřeba navrhnut celkový obsah řešení přírůstku. 

Dimenzionální analýza a modelování V rámci úlohy jsou navrženy datové modely datového skladu, resp. datových tržišť,

a dalších použitých databázových komponent. Jsou navrženy analytické aplikace, reporty, dashboardy a vytvořeny prototypy BI výstupů k připomínkování. 

Návrh technologické platformy přírůstku V dané fázi jsou specifikovány softwarové a hardwarové nároky daného přírůstku

a následně jsou navrhnuty konkrétní používané aplikace a hardware pro dané řešení přírůstku. 

Návrh ETL procedur Po návrhu datových modelů a výběru technologie je navrhnuta množina ETL procedur,

v rámci nichž je prováděno čištění a transformace dat z produkčních databází a jiných zdrojů s cílem jejich uložení v požadované podobě do BI databází. 

Implementace řešení Ve fázi implementace je realizováno celé řešení daného přírůstku. Jsou implementovány

všechny databázové komponenty, aplikace BI, provedeny a nastaveny ETL procedury, vytvořeny všechny klientské aplikace běžící nad databázovými komponentami. 

Zavedení do provozu, migrace Cílem této úlohy je nasazení celého nového řešení/přírůstku a všech jeho požadovaných

komponent do provozu. Je prováděno nasazení/upgrade technologické infrastruktury a počáteční migrace a čištění dat.


64 / 100

5.1.1 PROJEKT SS BI Projekt SS BI může v mnoha ohledech odpovídat klasickému projektu BI. Vždy je potřeba zprvu provést určitou úvodní studii, dále specifikovat uživatelské požadavky, definovat řešený přírůstek, vytvořit návrh datových struktur a uživatelských rozhraní, navrhnout používané technologie, ETL, následně řešení implementovat a vytvořené přírůstkové řešení nasadit do provozu. Tento postup je ovšem relevantní pouze v okamžiku, kdy jsou požadavky na řešení předem jasně specifikovány. Pokud je v podniku potřeba větší míra agility (Pover, 2014), kdy samozřejmě většinou nejsou požadavky dopředu úplně jasně specifikovány, vývoj řešení probíhá trošku odlišným postupem.

Obrázek 27: Porovnání postupů vývoje řešení (Pover, 2014)

Přístup k vývoji je přímo odvislý právě od toho, jak moc jsou požadavky předem specifikovány. (Pover, 2014) Jak vidno z předchozího obrázku, tradiční postup se od postupu Data Discovery, na kterém je postaven i Qlik Sense, značně liší. V tradičním postupu se začíná od specifikace požadavků, přes jejich dodání a končí mnohdy pouze interaktivními reporty, tedy omezenou možností uživatele, jak objevovat a zkoumat další souvislosti v datech. Řešení je totiž vytvořeno přesně podle požadavků vyspecifikovaných na počátku projektu. V případě Data Discovery je ovšem situace zcela opačná. Uživatel většinou začíná samotným objevování a zkoumáním dat. Následuje distribuce jeho výstupů ostatním uživatelům a poté, pokud to za to stojí, může být jeho řešení více rozvinuto do mnohem lepší, komplexnější a vyzrálejší podoby. V tomto případě tedy stačí uživatelům platforma a nástroje. Vývoj řešení pak probíhá zcela organicky. Samozřejmě jsou u společností většinou předem jasně dané některé požadavky týkající se sledovaných KPIs. Na tyto požadavky je možné naroubovat a použít klasický postup při řešení BI projektu. Nicméně budou existovat mezi uživateli i mnohé otázky a požadavky, které nemají jasně specifikované zadání. Na ty se zase hodí druhý, Data discovery postup.


65 / 100

Nejinak je tomu i u GoMobil. Na jednu stranu je tu několik v současné době sledovaných a jasně definovaných KPIs. Na druhou stranu jsou ve vzduchu ne úplně jasně specifikované informační potřeby pracovníků. Dále existují mnohá data a souvislosti v nich ukryté, na které nikdo ještě ani nepomyslel a nezkoumal je. Produkty a řešení společnosti Qlik, zejména pak Qlik Sense, jsou na SS BI a Data discovery přístupu postaveny, kdy umožňují agilní vývoj aplikací a zkoumání dat všem uživatelům. Zároveň je pro ně samozřejmě možné využít tradičních projektových postupů.

5.2 ŘEŠENÍ PRO GOMOBIL V rámci řešení bude zhodnocen současný stav MVNO GoMobil z pohledu BI, resp. SS BI, řešení a vyjmenovány jeho možné přínosy. Následně bude specifikováno zadání pro přírůstek na základě požadavků uživatelů, provedeny potřebné analýzy a přírůstek implementován na popisované platformě Qlik Sense.

5.2.1 SOUČASNÝ STAV Mobilní virtuální operátor GoMobil odstartoval nabídku svých služeb v červnu roku 2013. Za rok a půl svého působení na českém telekomunikačním trhu si stihnul vybudovat slušnou zákaznickou základnu čítající menší desítky tisíc aktivních telefonních čísel. Toto číslo je z pohledu managementu a mých aktuálních informací pokládáno za velice dobré vzhledem k výši vynaložených prostředků na marketing a turbulentnímu telekomunikačnímu trhu, kdy postupně vzniklo přibližně až 50 dalších virtuálních operátorů. Nyní koncem roku 2014 již přichází očekávané období konsolidace, kdy menší subjekty začínají být pohlcovány silnějšími nebo úplně zanikají. Od samého začátku byl u MVNO GoMobil kladen velký důraz zejména na brzký start, což já pokládám, a budou se mnou jistě souhlasit i další osoby z našeho projektového týmu participující v době spouštění služeb, za jeden z klíčových důvodů „úspěchu“. Při tvorbě produktu, což je v pojetí MVNO představováno zejména strukturou mobilních tarifů, bylo dáno nejvíce na intuici se zaměřením na cílovou skupinu, kde jsme vycítili největší prostor. Žádný uživatelský výzkum před startem GoMobil neproběhl, nebyl na to jednoduše čas. Nicméně povedlo se, struktura mobilních tarifů byla přijata zákazníky velmi vřele a my se soustředili na inovace, zejména co se do poskytnuté funkcionality zákazníkovi týče. S tím souvisí i druhý aspekt, který hrál velmi důležitou roli v růstu. Je to konstantní naslouchání zákazníkovi a jeho potřebě, bez čehož se dnes asi tvořit produkt ani nedá. S narůstající zákaznickou bází se však naslouchání zákazníkům stává více a více obtížnějším a zpětné vazby ztrácí s většími počty zákazníků vypovídací hodnotu. Zmíněné jednání na základě vlastní intuice


66 / 100

se zase stává více a více rizikovějším. Přestože je snaha minimalizovat takovéto jednání, mnohdy se mu zkrátka nejde vyhnout. Dle mého skromného názoru je nyní ten nejvyšší čas na to, aby začal být přístup k veškerému rozhodování, tvorbě produktů a inovacím postavený více na datech. Jinými slovy, s použitím používaného anglického buzzwordu: GoMobil se musí stát více „data-driven“. Ke kýženému stavu by mělo být dospěno zavedením Business Intelligence a jeho aplikací. Cílem je, aby všichni data-chtiví uživatelé měli v rukou informace potřebné pro své rozhodování, nebo alespoň takové nástroje, aby se k požadovaným informacím rychle a snadno sami dostali a nemuseli na ně dlouho čekat. Nejlépe pak tak, aby získávání informací a práce s daty nevyžadovala participaci IT oddělení, které klasicky nestíhá reagovat na všechny informační potřeby, což implikuje ono zmíněné jednání na základě vlastní intuice, které může v konečném důsledku znamenat velké riziko, neefektivnost či ušlé příležitosti. Dle klasického BI „maturity“ modelu, lze stupeň dospělosti BI v GoMobil identifikovat na počátečním stupni jedna. V současné době se pro reporting a analýzy používá klasických tabulkových procesorů typu MS Excel či naprogramovaných statických tabulkových výstupů vytvořených interním IT týmem, které se přepočítávají z produkčních dat vždy, kdykoliv se na ně některý uživatel doptá. Na data se nelze dívat z různých dimenzí. V případě nové informační potřeby je nutné zaslat požadavek na IT oddělení. Pokud zaměstnanci vytvoří report poté, co nějakým způsobem získají data od IT, není v současné době možnost jeho centralizovaného uložení k náhledu pro ostatní uživatele.

5.2.2 MOŽNÉ PŘÍNOSY ZAVEDENÍ SS BI O tom, že by BI, resp. SS BI, řešení pro společnost, která kromě MVNO GoMobil provozuje a rozjíždí i další ambiciózní projekty, mělo velký přínos, není z mé strany absolutně pochyb. Nové požadavky na reporty a informace nutné pro podporu rozhodování nyní vyvstávají od zaměstnanců na denní bázi. Přínosy SS BI vidím zejména v následujících oblastech: 

Rychlejší a lepší rozhodování SS BI jednoznačně pozitivně přispěje k lepšímu a rychlejšímu rozhodování v situacích

informační potřeby, ve kterých se zaměstnanci často nacházejí. Zároveň napomůže v situacích stále se měnících požadavků. Dosud byl jediný možný způsob, jak získat odpověď na otázku týkající se dat, poslání požadavků na IT, které ho zpracovává tehdy, až na něj přijde řada, což mnohdy může trvat i měsíce. Dodané informace už nemusí pak být aktuální.


67 / 100



Změna vlastnictví dat Data budou ve vlastnictví podniku a všem dostupná, ne jen pouze ve vlastnictví toho,

kdo je vytvořil, má je uložené na svém počítači a jediný k nim má přístup. 

Snížení nákladů IT Obecný problém organizací s neexistujícím či BI v raném stádiu. IT pracovníci tráví

při vývoji požadovaných reportů velmi mnoho času, výstupy tak vyjdou velmi draze a navíc většinou ani nedokážou odpovědět na často se měnící požadavky jejich zadavatelů, jelikož v době dodání jsou již zastaralé či nedostatečné, aby pokryly celou informační potřebu. 

Snížení nákladů na post-analýzu reportů Studovat statickou tabulku či interaktivní graf je ohromný rozdíl. Navíc je možné SS BI

výstupy s poskytnutými nástroji upravovat rozšiřovat o další dimenze, ukazatele aj. Analýza takovýchto výstupů se tak stává rychlejší, snazší, levnější, efektivnější. 

Měření výkonnosti BI umožní jednoduše sledovat definované podnikové ukazatele, nastavit KPI a směřovat

k nim výkonnost. V současné době je měření výkonnosti a ukazatelů v mnohých oblastech velmi neefektivní, některé ukazatele se nesledují vůbec, jelikož stále ještě leží v „backlogu“ IT oddělení. 

Vytěžení stávajících dat Produkční databáze ve svých strukturách nyní ukrývají ohromné množství informací

o zákaznících a transakcích, které do této doby nebyly pořádně analyzovány. Je zde velmi mnoho prostoru k poznání konkrétních skupin zákazníků, jejich chování, objevování jejich specifik či identifikaci jejich potřeb. 

Objevování souvislostí Při pohledu na podnikové ukazatele z různých úhlů pohledu, není vzácné často objevit

velmi užitečné informace a souvislosti, které při jejich správném využití mohou přinést podniku velké výnosy či úspory. 

Efektivnější marketing Specifika zákazníka a poznání jeho chování je možné využít v komunikaci, při tvorbě

nabízeného produktu a kampaních a podstatně tak zvýšit pravděpodobnost úspěchu.


68 / 100



Atraktivnější služby a produkty Nabízet služby, o které cílová skupina nemá zájem, je hloupé. Z produkčních dat je možné

vytěžit informaci o tom, jak se zákazníci chovají a o co by mohli mít zájem. 

Identifikace cross-sell a up-sell příležitostí S lepším poznáním zákazníků souvisí i identifikace příležitostí ke zvýšení obratu a zisků.



Zefektivnění vztahu s partnery Nejen poznání zákazníka je důležité. Neméně důležité je poznat naše partnery a další

prodejní kanály, které nám zákazníky a zisk přinášejí. Na základě poznatků je možné pak učinit taková opatření, která povedou k maximalizaci užitku všech zúčastněných stran. 

Přehled o minulosti, současnosti a predikce budoucnosti businessu Jak se podniku dařilo v určitých sledovaných ukazatelích v minulosti v různých

segmentech, co se na trhu dělo, jak se daří nyní a jak se bude pravděpodobně dařit do budoucna, to je velmi důležité pro následné plánování. 

Zvýšení konkurenceschopnosti Všechny zmíněné přínosy a efekty BI, resp. SS BI, výše uvedené by se pak měly

v konečném důsledku projevit ve zlepšení konkurenceschopnosti GoMobil na trhu. Toto byla pravděpodobně pouhá část přínosů popř. požadovaných cílů zavedení SS BI u GoMobil, potažmo dalších chystaných projektů. Velmi důležité je se také zamyslet nad tím, jaký dopad by do budoucna mělo, kdyby se BI technologie opomenuly. Dá se předpokládat, že BI je u největších konkurentů, jako jsou O2, Vodafone, T-Mobile a dalších velcí telco hráči, na velmi vysoké úrovni, se zákaznickými daty se intenzivně pracuje při tvorbě služeb a produktů, BI je využíváno k zefektivnění komunikace se zákazníkem, cross-sellu, up-sellu aj. Díky jejich postavení, síle a takovémuto přístupu zmíněné společnosti snadno diktují situaci na trhu a je velmi těžké s nimi bojovat. Je jasné, že malý virtuální operátor GoMobil nikdy nemůže přetlačit zmíněné molochy, i z důvodu jeho postavení, kdy je na nich závislý a využívá jejich infrastrukturu. Nicméně, může svůj business postavit tak, že bude dělat chytré kroky, zaujme svou nabídkou zákazníky, kterým nemají dnes velcí operátoři co nabídnout, nabídne další relevantní služby a produkty a bude inovativní. Právě SS BI a lepší práce s daty a jejich vytěžení mu k tomu může velmi pomoci a umožní společnosti jít stále vpřed a nepřehlížet naskýtající se příležitosti. Zavedení Self-Service BI u MVNO GoMobil

69 / 100

5.2.3 POŽADAVKY NA PRVNÍ PŘÍRŮSTEK V současné době je v rámci firmy nutné pro marketingové potřeby provést analýzu dat za účelem poznání současného zákazníka, podívat se na něj z několika různých úhlů pohledu a zefektivnit tak marketingové aktivity GoMobil. Od uživatelů jsem v rámci interview sesbíral několik požadavků na sledované metriky (dle různých dimenzí): 

Počty a poměry zákazníků dle různých dimenzí



Počty a poměry služeb dle různých dimenzí



Počet služeb na zákazníka dle různých dimenzí



Délka trvání služby dle různých dimenzí



Průměrný počet provolaných minut, poslaných SMS, MMS, přenesených dat dle různých dimenzí V následující fázi multidimenzionální analýzy budou tyto požadavky rozpracovány

do jednotlivých detailních ukazatelů a dimenzí.

5.2.4 MULTIDIMENZIONÁLNÍ ANALÝZA Produkty Qliku propojují všechny tabulky a jejich sloupce v rámci datového modelu do jedné datové struktury, viz kapitola 4.1.2. Jsou-li tabulky propojeny, jsou ve výsledném datovém modelu mezi nimi vytvořeny požadované vazby. Není tedy na místě vytváření matice ukazatelů a jejich dimenzí, stačí logicky pouze jejich výpis a vysvětlení.

5.2.4.1 Ukazatele 

Počet zákazníků – jeden záznam v tabulce zákazníci se rovná jednomu zákazníkovi



Počet služeb – jeden záznam v tabulce služby se rovná jedné službě



Datum objednání a ukončení služby – délka trvání služby se vypočte z těchto hodnot



Počet transakcí – konkrétní transakce představuje provedený hovor, SMS či MMS



Počet provolaných minut – transakce volání nese informaci o délce hovoru



Počet stažených dat – transakce data nese informaci o množství stažených dat

5.2.4.2 Dimenze 

Lokalita zákazník – město, okres kraj



Ročník narození zákazníka (degenerovaná) – ročník narození je určen z rodného čísla



Pohlaví zákazníka (degenerovaná) – pohlaví zákazníka je určeno z rodného čísla



Typ zákazníka (degenerovaná) – soukromá osoba nebo firma/živnostník



Datum zákazníka – časová dimenze získání zákazníka



MVNO – vzhledem k tomu, že GoMobil má pod sebou ještě další virtuální operátory, je potřeba rozlišovat data i podle jednotlivých MVNO


70 / 100



Typ služby (degenerovaná) – nové číslo nebo přenos čísla od jiného operátora



Datum služby – časová dimenze objednání služby



Tarif služby – mobilní tarif zvolený zákazníkem



Doplňkové služby – jedná se o aktivní balíčky volání, SMS a dat



Stav služby (degenerovaná) – služba je/není v současné době je v provozu



Datum transakce – časová dimenze pro transakce



Typ transakce (degenerovaná) – volání, SMS, MMS, DATA atd.



Destinace-operátor transakce (degenerovaná) – kam bylo voláno, posílána SMS, MMS



Destinace-země transakce (degenerovaná) – vnitrostátní, do zahraničí, či roaming

5.2.5 INFORMAČNÍ SYSTÉM A PRIMÁRNÍ ZDROJE DAT Ve společnosti tvoří určitý středobod všeho dění individuální aplikační software (IASW), který je vyvíjen in-house podnikovými zdroji přesně na míru potřebám MVNO GoMobil, ale i ostatním projektům a jejich procesům. Systém, a jeho databáze, ukrývá veškerá data, která se týkají zákazníka, jeho služeb, produktů, objednávek, přehledů spotřebovaných služeb, vyúčtování, komunikace, ticketů, fakturace, pohledávek, provisioningu atd. Pro potřeby daného přírůstku jsou téměř veškerá data ukrytá v tabulkách zmíněné relační databáze. Ta má ve své kompletní podobě velmi robustní strukturu, kdy obsahuje několik stovek tabulek, jak už to v takovém složitém podnikovém systému bývá. Našemu úzce definovanému přírůstku o několika málo ukazatelích a dimenzích jsou relevantní pouze následující tabulky dané databáze (jména neodpovídají realitě): 

zákazníci Jedná se o tabulku ukrývající data o konkrétních zákaznících. Zákazník může mít několik služeb a zároveň má jednu hlavní adresu.



služby Jedná o službu v podobě provozovaného mobilního telefonního čísla v síti GoMobil. Služba patří vždy jednomu zákazníkovi.



adresy Adresa daného zákazníka. Jedná se o jeho fakturační adresu (trvalé bydliště, sídlo firmy)



tarify Jedná se o mobilní tarif. Každá služba má v daný okamžik právě jeden tarif.



tarif_definice Definice tarifu. Každý tarif má právě jednu definici tarifu. Tabulka obsahuje název tarifu.


71 / 100



doplnkovaSluzba Každá služba má určité volitelné množství doplňkových služeb. Jedná se například o zvolené balíčky výhodného volání, SMS a internetu v mobilu.



doplnkovaSluzba_definice Jedná se o typ doplňkové služby. Každá doplňková služba má právě jednu definici doplňkové služby. Tabulka obsahuje např. název doplňkové služby.



doplnkonaSluzba_definice_parametr Definice doplňkové služby má dále několik možných parametrů, kterých může nabývat. Například doplňková služba definovaná (typem) „balíček internet v mobilu“ může nabývat parametrů 300 MB, 600 MB, 1 GB atd.



transakce Všechny odchozí i příchozí transakce (volání, SMS, data aj.), které uskuteční určitá služba. Abychom mohli vytvořit zamýšlenou dimenzi lokality (kraj, okres, obec), pro niž data

v databázi nemáme, je nutné získat číselníky obsahující psč a k němu přidružené okresy a kraje. Využijeme veřejně dostupných dat ve formátu XLS.

5.2.6 NÁVRH ETL Produkty Qliku se vyznačují díky používaným technologiím trošku jiným přístupem k tvorbě datového skladu. Zprvu není potřeba dopředu vůbec navrhovat datový model, vše se může dít až za pochodu při samotné tvorbě ETL procedur v Data Load Editoru. Při nahrávání tabulek neexistují žádná integritní omezení, jako je tomu u jiných BI řešení, veškerá zodpovědnost ohledně čistoty dat je pouze a jen na vývojáři samotném. Na druhou stranu to dává vývojáři ohromnou svobodu v případě změn. Pro změnu v datovém modelu stačí pouze provést změnu v ETL skriptu a spustit nový reload dat, samotný datový model se tvoří vždy při každém spuštění skriptu. Jak jsem již zmínil, propojení tabulek se děje pouze na základě shody názvů sloupců, načež by měl dávat vývojář také pozor.

5.2.6.1 Definice proměnných Po vytvoření Qlik Sense aplikace je potřeba nejdříve nadefinovat základní proměnné prostředí. Qlik Sense si je ze začátku definuje automaticky sám, zřejmě dle jazykové lokalizace OS. Jedná se například o nastavení ohledně číselných formátů, času, datumů, dnů v týdnu atd. V tomto případě není potřeba nic měnit.


72 / 100

// proměnné prostředí SET ThousandSep=' '; SET DecimalSep=','; SET MoneyThousandSep=' '; SET MoneyDecimalSep=','; SET MoneyFormat='# ##0,00 Kč;-# ##0,00 Kč'; SET TimeFormat='h:mm:ss'; SET DateFormat='D.M.YYYY'; SET TimestampFormat='D.M.YYYY h:mm:ss[.fff]'; SET MonthNames='1;2;3;4;5;6;7;8;9;10;11;12'; SET DayNames='po;út;st;čt;pá;so;ne'; SET LongMonthNames= 'leden;únor;březen;duben;květen;červen;červenec;srpen;září;říjen;listopad;prosinec'; SET LongDayNames='pondělí;úterý;středa;čtvrtek;pátek;sobota;neděle'; SET FirstWeekDay=0; SET BrokenWeeks=1; SET ReferenceDay=0; SET FirstMonthOfYear=1;

5.2.6.2 Připojení ke zdrojovým datům Abychom se mohli připojit k datovým zdrojům, je potřeba nadefinovat datová spojení, na které se budeme následně ve skriptu odkazovat. Pro připojení k MySQL databázi, kde se nachází většina zdrojových dat, je potřeba úplně nejdříve, pokud ještě tak není provedeno, nainstalovat MySQL ODBC driver a následně nadefinovat dané ODBC spojení ve Správci zdrojů dat ve Windows. Jakmile je zdroj dat nadefinován na úrovni OS, je možné v Data Load Edioru v Qlik Sense vytvořit datové spojení.

// Connection string pro připojení pomocí ODBC ke zdrojové MySQL databázi v rámci běhu skriptu LIB CONNECT TO 'MySQL_GoMobil';

Pro připojení k souborovým zdrojům, v našem případě k Excel dokumentům, v nichž jsou uloženy informace o územní nomenklatuře, je potřeba vytvořit datové spojení, kde bude definována cesta ke složce se soubory. Následně můžeme pomocí průvodce data ze souborů číst a generovat základní skripty.


73 / 100

5.2.6.3 Transformace Jak jsem již zmínil dříve, při jejich spouštění se není potřeba držet z důvodu absence integritních omezení v Qlik Sense žádného požadovaného postupu načítání tabulek. Všechna data se sama propojí na základě shodných názvů polí jednotlivých tabulek. Jednotlivé transformace dat pro získání potřebných ukazatelů, dimenzí a jejich propojení jsou uvedeny v následujících blocích. Transformace a další čištění jsou z důvodu komplexnosti a existence dalších projektů v rámci firmy pro lepší orientaci a pochopení zjednodušeny.

Ukazatel: Počet zákazníků Pole: id_zakaznik f_zakaznik: LOAD id as id_zakaznik, date(floor(date_insert)) as datum_zakaznik, primary_address_id as adresa_zakaznik, type as type_cust, mid(PurgeChar(personal_id,'/'),1,6) as rc; SQL SELECT id, date_insert, type, primary_address_id, personal_id FROM db.zakaznici;

Ukazatel: Počet slušeb, datum objednání služby, datum ukončení služby Pole: id_sluzba, datumObjednani_sluzba, datumKonec_sluzba f_sluzba: LOAD id as id_sluzba, contact_id as id_zakaznik, tariff_id as id_tarif, date(floor(date_demand)) as datumObjednani_sluzba, date(floor(date_begin)) as datumZacatek_sluzba, date(floor(date_end)) as datumKonec_sluzba, name as nazev_sluzby; SQL SELECT id, contact_id, tariff_id, date_demand, date_begin, date_end, name FROM db.sluzby; Zavedení Self-Service BI u MVNO GoMobil

74 / 100

Ukazatel: Počet transakcí, Počet provolaných minut, Počet stažených dat Pole: pocetDni_sluzba f_transakce: Load id as id_transakce, date(floor(date)) as datum_transakce, base_service_id as id_sluzba, duration/60 as dobaHovoru_transakce, volume as mnozstviDat_transakce, type as typ_transakce, to_type as kamOperator_transakce, roaming, international; SQL SELECT id , date, base_service_id, duration, volume, type, to_type, roaming, international

// sekundy -> minuty

FROM db.`transakce` WHERE ((type=('CALL' or 'SMS' or 'MMS' or 'PAYMENT') and direction='OUTGOING') or type='DATA'); // výběr pouze relevantních odchozích transakcí

Dimenze: Typ zákazníka Pole: typ_zakaznik left join (f_zakaznik) Load id_zakaznik, if(wildmatch(type_cust, '*COMPANY*'),'firma','soukromé') as typ_zakaznik Resident f_zakaznik;


75 / 100

Dimenze: Lokalita Pole: obec, okres, kraj, stat // adresa d_lokalita_adresa: LOAD id as adresa_zakaznik, PurgeChar(zip,' ') as psc, if(state='ČR' or state='CZ','Česká republika',if(state='SK','Slovenská republika','jiný')) as stat; SQL SELECT id, zip, state FROM db.adresy; // obec, okres d_lokalita_okres: LOAD NAZOBCE as obec, PSC as psc, NAZOKRESU as okres FROM 'lib://folder/psc_okres.xls' (biff, embedded labels, table is Zv_pcobc$); //kraj d_lokalita_kraj: LOAD okres, kraj FROM 'lib://folder/okres_kraj.xlsx' (ooxml, embedded labels, table is okres_kraj);


76 / 100

Pohlaví a ročník narození zákazníka pro pozdější zjištění věku zákazníka je počítáno z rodného čísla, jinak zjistit z dostupných dat nelze. Je nutné říci, že u velkého počtu záznamů je rodné číslo buď ve špatném formátu, nesmyslné nebo zcela chybí. Data je tedy potřeba co nejvíce očistit.

Dimenze: Ročník narození Pole: rokNarozeni_zakaznik left join (f_zakaznik) Load id_zakaznik, if(rc>0 and Frac(mid(rc,1,6))=0 and mid(rc,5,2)<32, if(left(rc,1)<>0,'19' & left(rc,2),'20' & left(rc,2)), if(typ_zakaznik='firma', 'neznámý rok-firma', 'neznámý rok')) as rokNarozeni_zakaznik Resident f_zakaznik; Dimenze: Pohlaví zákazníka Pole: pohlavi left join (f_zakaznik) Load id_zakaznik, if(rc>0 and Frac(mid(rc,1,6))=0 and mid(rc,5,2)<32, if(mid(rc,3,2)>50, 'žena', if(mid(rc,3,2)>0 and mid(rc,3,2)<33,'muž', 'neznámé pohlaví')), if(typ_zakaznik='firma', 'neznámé pohlaví-firma','neznámé pohlaví')) as pohlavi_zakaznik Resident f_zakaznik;

Dimenze: Typ služby Pole: typ_sluzba left join (f_sluzba) Load id_sluzba, if(mid(nazev_sluzby,25,4)='nové','nové číslo','přenos čísla') as typ_sluzba resident f_sluzba;


77 / 100

Dimenze: Stav služby Pole: stav_sluzba left join (f_sluzba) Load id_sluzba, if(isnull(datumZacatek_sluzba) and isnull(datumKonec_sluzba),'čeká na aktivaci', if(isnull(datumZacatek_sluzba),'nikdy neaktivována', if(isnull(datumKonec_sluzba),'aktivována','ukončena'))) as stav_sluzba resident f_sluzba;

Dimenze: Tarif Pole: nazev_tarif //načtení tarifů Tmp: LOAD id as id_tarif, tariff_def_id as id_tarif_def; SQL SELECT id, tariff_def_id FROM db.tarify; //join s názvy tarifů left join(Tmp) LOAD id as id_tarif_def, name as nazev_tarif SQL SELECT id, name FROM db.tarify_definice; // výběr jen potřebných polí d_tarif: NOCONCATENATE LOAD id_tarif, nazev_tarif RESIDENT Tmp; DROP TABLE Tmp;


78 / 100

Dimenze: Doplňková služba Pole: nazev_dopnkovkaDef, nazev_doplnkovkaParam // aktuální doplňkové služby Tmp: LOAD id as id_doplnkovka, add_service_def_id as id_doplnkovkaDef, add_service_param_def_id as id_dopnkovkaParam, base_service_id as id_sluzba; SQL SELECT id, add_service_def_id, add_service_param_def_id, base_service_id FROM db. doplnkovaSluzba where date_begin is not null and date_end is null; //join s definicemi doplňkových služeb left join (Tmp) LOAD id as id_doplnkovkaDef, name as nazev_dopnkovkaDef, base_service_def_id; SQL SELECT id, base_service_def_id, name FROM db. doplnkovaSluzba_definice; //join s parametry doplňkových služeb left join (Tmp) LOAD id as id_dopnkovkaParam, name as nazev_doplnkovkaParam; SQL SELECT id, name FROM db. doplnkovaSluzba_definice_parametr; // Výběr aktivních doplňkových služeb d_doplnkovka: NOCONCATENATE LOAD id_sluzba, nazev_dopnkovkaDef, nazev_doplnkovkaParam RESIDENT Tmp; DROP TABLE Tmp;


79 / 100

Dimenze: Destinace-země transakce Pole: kamZeme_transakce left join (f_transakce) Load id_transakce, if(roaming=1, 'roaming', if(international=1, 'volání do zahraničí', 'vnitrostátní')) as kamZeme_transakce Resident f_transakce;

Pro vytvoření potřebných časových dimenzí je potřeba v Qlik Sense vygenerovat tzv. „master“ kalendáře. Ty obsahují všechny potřebné dny v daném intervalu a jejich přidružené názvy dnů v týdnu, čísla týdnů, měsíce, kvartály, roky atd. Časová dimenze, představovaná vygenerovaným kalendářem je pak následně spojená s faktovou tabulkou přes shodný název sloupce (datum). V našem modelu máme hned tři kalendáře pro zákazníka, službu a transakci. Jak může vypadat skript pro vygenerování umělé časové dimenze, je uvedeno v příloze práce v kapitole 10.2.

5.2.6.4 Běh ETL procedury

. Obrázek 28: Log a výsledek běhu skriptu (autor)

Následně spustíme námi nadefinovaný skript. Vzhledem k velkému množství záznamů v tabulce transakce, která obsahuje záznamy o všech odchozích i příchozích transakcích a v současné době zabírá v relační databázi místo ve velikosti 27 GB. Běh ETL procedur načítající jen odchozí transakce na výkonném virtuálním serveru, který se nachází ve stejné síti jako databáze se zdrojovými daty, trval skoro 13 minut. Během běhu skriptu byly v jeden Zavedení Self-Service BI u MVNO GoMobil

80 / 100

okamžik dva procesory vytíženy na 100% a Qlik Sense procesy potřebovaly až 6 GB operační paměti serveru. Výsledný soubor QVF uložený na disku měl pak velikost 160 MB. Na následujícím obrázku můžete vidět dialogové okno informující o průběhu a výsledku běhu skriptu. Celý logu skriptu je umístěn v příloze této práce 10.1.

5.2.6.5 Načítání dat po přírůstcích Co Opakované

se

týče

načítání

transakcí, celého

celkově obsahu

bylo

tabulky

nahráno transakcí

skoro

22

vzhledem

milionů k jejímu

záznamů. stálému

exponenciálnímu nárůstu a omezeným serverovým zdrojům tedy není vhodné. Tato tabulka, vzhledem ke statickým záznamům, doslova křičí po načítání dat po přírůstcích. Qlik Sense, i jeho předchůdce QlikView, má přírůstkové načítání dat řešené pomocí QVD souborů (QlikView Data file), které představují určitou mezivrstvu, dočasného úložiště, kde jsou data ukládána v optimalizované podobě po jejich načtení z primárních zdrojů. Následně umožňují až 10-100x rychlejší načítání dat (Sinha). Přírůstkové načítání transakcí probíhá v tomto případě následovně: 1. Kontrola existence QVD souboru. 2. Pokud existuje, nahrání dat z QVD souboru. Pokud neexistuje, nahrání dat z primárních zdrojů a jejich uložení do QVD souboru. 3. Načtení přírůstku (pouze záznamů s větším id než největší id v existujícím QVD souboru) 4. Aktualizace QVD souboru a nahrání dat do QVF aplikace. Jak by mohl vypadat samotný skript v případě tabulky transakcí, je možné vidět v příloze této práce v kapitole 10.3. Soubor QVD obsahující oněch 22 milionů transakcí zabírá na disku serveru pouze 370 MB. Zdroje potřebné na provedení skriptu jsou tímto značně redukovány a sníží se samozřejmě i výsledná doba běhu skriptu. V případě načítání transakcí po přírůstcích pomocí QVD souboru se zkrátila doba běhu skriptu ze 13 na 4 minuty.


81 / 100

5.2.6.6 Výsledný model datové skladu

Obrázek 29: Výsledný datový model (autor)


82 / 100

5.2.7 UŽIVATELSKÉ ROZHRANÍ Po nahrání dat do aplikace již přichází ta zábavnější část, což je samotná tvorba vizualizací a příprava dimenzí a ukazatelů pro uživatele. Jak jsem již nastínil v předešlých kapitolách, v rámci aplikace jsou uživateli vytvářeny sešity, které představují uživatelské rozhraní pro zobrazení dashboardů, interaktivní reportů a provádění vlastních analýz. V rámci sešitů jsou dostupné vizualizační nástroje, které umožňují prezentaci vzájemně propojených dat v datovém skladu. Na požadavcích, které byly definovány na počátku, ukážu, jak lze dojít ke kýženým výsledkům s použitím některých dostupných vizualizací. Veškeré potřeby GoMobil na reporty nejsou obsahem této práce, proto ukážu jen některé zajímavé pro potřeby demonstrace postupu jejich tvorby.

5.2.7.1 Poměr zákazníků dle věku Na zákazníky a jejich počty se dá nahlížet z mnoha různých dimenzí. Následující sloupcový graf reprezentuje procentuální podíl zákazníků dle jejich věku. V daném sešitu jsou ještě umístěny filtrovací nástroje pro některé detailnější výběry. Aktuální výběr je zúžen na zákazníky se sídlem v ČR a dobu jejich akvizice v aktuálním roce, 2014. Šedý sloupec na grafu vyznačuje ty zákazníky, kteří z nějakého důvody nemají uveden ročník narození (jedná se o firmy či neúplný záznam s chybějícím rodným číslem).

Obrázek 30: Zobrazení poměru aktivních zákazníků dle jejich věku (autor)

Abych se k takovémuto grafu dostal, je potřeba pro tuto vizualizaci nadefinovat výrazy pro dimenze a metriky. Následně je možné v nastavení vizualizace upravit vzhled grafu, barvy, vyjádření hodnot, jejich řazení a další detaily pro lepší pochopení a práci s grafem.


83 / 100

Abych získal z ročníku narození u zákazníka požadované zobrazení dle věkových skupin, je potřeba si nejdříve vypočíst u každého zákazníka jeho věk a následně pomocí funkce class() tyto hodnoty seskupit dle požadovaného intervalu. Pro lepší přehlednost je ještě použita funkce replace(), která upravuje textové vyjádření věkových skupin.

// Věkové skupiny po 5 letech =replace(class(year(today()) - rokNarozeni_zakaznik,5),'<= x <', ' - ')

Aby bylo docíleno požadovaného vyjádření metriky, kdy chceme získat poměr zákazníků GoMobil s alespoň jednou aktivní službou dle dané věkové skupiny a zároveň ještě chceme provádět další výběry, je potřeba již trošku složitějšího výrazu.

// Počet aktuálně vybraných zákazníků GoMobil s alespoň jednou aktivní službou Count({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_zakaznik) / // Počet všech zákazníků GoMobil s alespoň jednou aktivní službou Count(total {1<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_zakaznik)

5.2.7.2 Poměr zákazníků dle počtu aktivních služeb & průměrný počet služeb na zákazníka Na následujícím reportu, který má za cíl ukázat poměr počtu zákazníků dle počtu jejich aktivních služeb a průměrný počet služeb na zákazníka, bych chtěl demonstrovat jak několik zajímavých vizualizací tak zajímavých funkcí. Poměr zákazníků GoMobil dle počtu aktivních služeb jsem se rozhodl pro srovnání ukázat hned na dvou vizualizacích, na obrázku 31. Jednou z nich je klasická tabulka a druhý je tzv. „Treemap“ graf, na obrázku vlevo dole. Dimenze a metrika pro tyto vizualizace se vyjádří následujícím způsobem s pomocí funkce aggr():

// Dimenze - počet aktivních služeb na zákazníka z aktuálního výběru =aggr(count({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_sluzba), id_zakaznik) // Metrika – poměr zákazníků z aktuálního výběru Count({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_zakaznik) / Count(total {$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_zakaznik)


84 / 100

Pro průměrný počet aktivních služeb na zákazníka jsem pak použil vizualizace zvané anglicky „Gauge“, která představuje stupnici a má vstup pro jednu metriku, na obrázku vpravo nahoře. Abychom dostali průměrný počet služeb na zákazníka z aktuálního výběru, je potřeba ještě trochu rozšířit již napsaný výraz s agregační funkcí, kdy jsme potřebovali vyjádřit počty služeb na zákazníka, o jejich průměr, funkci avg().

// Průměr počtu aktivních služeb pro vybrané zákazníky avg(aggr(Count({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}>} id_sluzba), id_zakaznik))

Obrázek 31: Poměr zákazníků dle počtu aktivních služeb (autor)


85 / 100

5.2.7.3 Průměrný počet provolaných minut/SMS měsíčně dle věku Poslední zajímavou vizualizaci, na které ukážu průměrné počty provolaných minut a SMS, je bodový diagram tzv. „Scatter plot“ znázorněný na obrázku 32.

Obrázek 32: Průměrně minut/sms dle věku (autor)

Tento diagram má celkem tři vstupy – potřebuje dvě metriky a jednu dimenzi. Dimenzi u nás bude představovat věková skupina zmíněná již dříve v této práci a metrikami budou průměrné počty minut a SMS. Metriky jsou definovány následovně:

// Průměrný počet provolaných minut měsíčně avg(aggr(sum({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}, typ_transakce={'CALL'}>} dobaHovoru_transakce), rok_transakce, mesic_transakce, id_sluzba)) // Průměrný počet poslaných SMS měsíčně avg(aggr(count({$<stav_sluzba={'aktivována'}, mvno_nazev={'GoMobil'}, typ_transakce={'SMS'}>} id_transakce), rok_transakce, mesic_transakce, id_sluzba))


86 / 100

5.3 SHRNUTÍ V úvodu kapitoly věnující se implementaci SS BI řešení na základě požadavků uživatelů MVNO GoMobil na platformě Qlik Sense jsou popsány jednotlivé úlohy klasického projektu BI a vysvětlen rozdíl oproti agilnějšímu SS BI projektu. Další část práce se již věnuje MVNO GoMobil. Je popsán současný stav, kdy není prozatím žádná BI technologie využívána. Jsou vyjmenovány a popsány možné přínosy, které by mohly být pomocí BI, resp. SS BI, a novým přístupem při správném uchopení doručeny. Následně jsou specifikovány uživatelské požadavky a na základě nich provedena multidimenzionální analýza již s přihlédnutím k vybrané platformě. Po zmapování a analýze dostupnosti dat je navržena množina ETL procedur, kterými jsou data z primárních zdrojů transformována a uložena v požadované podobě do „datového skladu“ v aplikaci Qlik Sense, kdy je možné z nich posléze snadno a rychle získat požadované výstupy. Po nahrání požadovaných dat do aplikace bylo vytvořeno několik zajímavých složitějších výstupů s pomocí základních dostupných vizualizací aplikace Qlik Sense. Po vytvoření aplikace s vizualizacemi dat je následně možné ihned ji publikovat a zpřístupnit v hubu do patřičného kanálu pro vybrané uživatele a jejich vlastní analýzy a reporty.


87 / 100

6 ZÁVĚR 6.1 NAPLNĚNÍ CÍLŮ PRÁCE Stanovených cílů bylo v průběhu práce dosaženo následovně: A. Vymezení SS BI, jakožto jednoho z BI přístupů, jeho přínosů pro organizaci a dalších specifik bylo dosaženo v kapitole 3. B. Popis SS BI nástroje Qlik Sense, jednoho ze současných předních SS BI řešení na trhu, jeho charakteristika a principy jsou obsaženy v kapitole 4. C. Analýza a řešení BI přírůstku vycházejícího z reálných uživatelských požadavků MVNO GoMobil za pomoci nástroje Qlik Sense, byla provedena v kapitole 5. Ze začátku je práce věnována „teoretickému“ úvodu do SS BI a rozdílu oproti klasickému neflexibilnímu BI závislém na podnikovém IT. Zejména na nedostatcích klasického BI jsou prezentovány přínosy, které organizacím přístupy a technologie SS BI nabízejí. Následně jsou popsány typy uživatelů a vysvětleny nároky a požadavky na daná podnikové řešení. Na konci kapitoly byla vysvětlena rozdílná míra a potřeba SS v daných organizacích vzhledem k jejich variabilitě a rozdílným potřebám. Po nutném úvodu do SS BI následuje představení nástroje Qlik Sense, jakožto jednoho z nejvyspělejších zástupců na současném trhu. Zprvu jsou popsány jeho hlavní charakteristiky a principy. Následuje popis desktopové a serverové verze Qlik Sense. V dalších podkapitolách je nejdříve nastíněna práce a vývoj řešení na dané platformě a nakonec je zevrubněji popsáno serverové podnikového řešení, jeho architektura, funkcionalita a postup nasazení. Poslední třetí část práce se věnuje MVNO GoMobil, jeho potřebám v oblasti BI a možným přínosům. Posléze je na základě uživatelských požadavků s přihlédnutím ke zvolené platformě provedena multidimenzionální analýza, navrhnuty ETL procedury a schéma „datového skladu“. Dále je navrhnuté řešení implementováno a to včetně několika vytvořených složitějších vizualizací dle specifikovaných požadavků. Troufám si tvrdit, že jsem obstojně naplnil cílů stanovených v úvodu, a tím pádem má tato práce i velký potenciál co do očekávaných přínosů a přidané hodnoty pro možné čtenáře. Dle mého názoru by práce mohla být zajímavým čtením pro ty, kteří se zajímají o problematiku SS BI, vývoj řešení na platformě Qlik Sense anebo jsou to představitelé malých podniků, kde přemýšlí o tom, jakým způsobem využít cenná data ukrytá v jejich databázích.


88 / 100

6.2 DATA & SME Jedním z důvodů, proč jsem si vybral téma této práce, byla z mého pohledu ne moc dobrá utilizace dat v naší malé společnosti. Je obecně platné, že v segmentu SME (Small and Medium Entreprises) se nepracuje s daty, i přes jejich kvantum tak, jak je to obvyklé u velkých konkurentů. V malých společnostech se spoléhají zejména na intuici svých klíčových zaměstnanců. A proč je tomu tak? Co jim brání, aby využívaly data stejně jako ti velcí? Zcela jasně je to kvůli omezeným zdrojům takových firem. Zejména pak pořizovacím cenám řešení, která by jim data umožňovala analyzovat a vytěžit. Dále zajisté kvůli vysoké ceně práce kvalifikovaných pracovníků, ať už developerů či analytiků. Možná ale vidina nákladů není jedinou brzdou v tomto ohledu. Výrazně k tomu dle mého názoru v takto malých firmách přispívá i určitá míra absence znalosti dané problematiky a možností daných technologií, což v konečném důsledku znamená neschopnost odhadnutí možných přínosů a návratnosti investic. Samotná přítomnost BI technologií a pracovní síly schopné s daty pracovat pro doručení kýžených přínosů ovšem nestačí, není samospasitelná. Je nutná určitá transformace myšlení a kooperace uvnitř organizace. Jsou to zejména business uživatelé, kteří musí být zapojeni do analytické činnosti a musí být motivováni a mít prostředky k tomu data analyzovat, přemýšlet o tom, jak by bylo možné je využít v podnikání, správně se ptát a získané poznatky aplikovat. Bez tohoto žádné přínosy nebudou, spíše jen zklamání ze zmařené investice. Nejideálnějším startovním bodem pro takto malé společnosti nepředstavují robustní drahá řešení a přístupy zamýšlené pro velké organizace, nýbrž malá a flexibilní řešení. Popisovaný přístup SS BI a nástroj Qlik Sense dle mého názoru představují, zejména v případě jejich správného uchopení, ideální řešení pro analýzu dat a reporting v malých a dynamických firmách.


89 / 100

7 TERMINOLOGICKÝ SLOVNÍK Termín

Business Intelligence

Customer Relationship Management Dashboard

Data discovery

Datové tržiště (Data Mart)

Data mining

Data Staging Area

Datový sklad (Data Warehouse)

Dimenze Drilling Enterprise Application Integration Enterprise Resource Planning

Zkratka Význam „Business Intelligence představuje komplex přístupů a aplikací IS/ICT, které téměř výlučně podporují analytické a plánovací činnosti podniků a organizací BI a jsou postaveny na principu multidimenzionality, kterým zde rozumíme možnost pohlížet na realitu z několika možných úhlů.“ (Novotný, a další, 2005) „CRM systém je typem informatické aplikace CRM orientované na komplexní zajištění vztahů podniku se svými zákazníky.“ (Gála, a další, 2006) „Aplikace, které na jednom panelu poskytují informace o vybraných klíčových metrikách a jejich změnách, které vyvolávají podnikové aktivity.“ (Jan, a další, 2009) Přístup Data discovery je jednou variantou SS BI. Vyznačuje zejména orientací na uživatele, kterému umožňuje tvořit své vlastní interaktivními reporty a zkoumat a analyzovat data pomocí dostupných nástrojů. Viz kapitola 3.9 a 5.1.1. (autor) „Problémově orientovaný datový sklad určený pro pokrytí konkrétní problematiky daného okruhu uživatelů.“ (Jan, a další, 2009) „Dolování dat umožňuje pomocí speciálních algoritmů automaticky objevovat v datech strategické informace. DM Je to analytická technika pevně spjatá s datovými sklady, jako s velmi kvalitním datovým zdrojem pro tyto speciální analýzy.“ (Novotný, a další, 2005) Dočasné úložiště sloužící pro uložení extrahovaných dat z produkčních systémů. Jeho hlavním úkolem je DSA podporovat rychlou a efektivní extrakci (výběr) dat. (Novotný, a další, 2005) „Datový sklad (Data Warehouse) je integrovaný, subjektově orientovaný, stálý a časově rozlišený DWH souhrn dat, uspořádaný pro podporu potřeb managementu.“ (Pour, a další, 2012) „Dimenze dávají kontext faktům. Obsahují většinou textové atributy popisující fakta.“ (Novotný, a další, 2005) Drill-down a drill-up jsou vlastnosti BI, které umožňují zobrazovat data na různé úrovni požadovaného detailu. EAI nástroje představují middleware, jehož cílem je EAI integrovat primární podnikové systémy a razantně tak redukovat počet jejich vzájemných rozhraní. (autor) „Představuje obvykle jádro aplikační architektury ERP informačních systémů a pokrývá největší rozsah jeho funkcí a procesů.“ (Gála, a další, 2006)


90 / 100

Extract - Transform - Load

ETL

Granularita Key Process Indicator

KPI

Metrika Mobilní virtuální operátor

MVNO

OnLine Analytical Processing

OLAP

OnLine Transaction Prosessing

OLTP

Open DataBase Connection

ODBC

Operational Data Store

ODS

Return Of Investment

ROI

Self-Service Business Intelligence

SS BI

Snowflake schema

Star schema

„Datová pumpa. Jejím úkolem je získat data ze zdrojových systémů a vybrat (Extraction), upravit do požadované formy a vyčistit (Transformation) a nahrát je do specifických datových struktur, resp. datových schémat, datového skladu (Loading).“ (Novotný, a další, 2005) Granularita představuje stupeň detailnosti uložení dat v datovém skladu. (autor) Sledovaná klíčová metrika používaná k měření výkonnosti organizace. (autor) Fakt nebo také ukazatel, který se v daném podniku sleduje. Většinou je číselný. (autor) Mobilní virtuální operátor poskytující mobilní služby koncovým zákazníkům bez toho aniž by vlastnila či provozovala svou vlastní síť či infrastrukturu. (autor) Umožňují provádění analýz v reálném čase. „OLAP databáze představují jednu nebo několik souvisejících OLAP kostek. Ty většinou již zahrnují předzpracované agregace dat podle definovaných hierarchických struktur dimenzí a jejich kombinací.“ (Novotný, a další, 2005) OLTP databáze umožňují transakční zpracování dat na nejmenší míře detailu. Transakční OLTP systémy a jejich data ukrytá většinou v relačních databázích jsou vstupem pro aplikace Business Intelligence. (autor) Standardní softwarové rozhraní pro přístup k databázím. (autor) Operativní datové úložiště je BI datová komponenta sloužící buď jako místo pro ukládání dat v reálném čase či jako derivace již existujícího datové skladu, který obsahuje malé množství analytických dat pro potřeby jednoduchých dotazů nad aktuálními daty. (Novotný, a další, 2005) Návratnost investice. Poměr vydělaných a investovaných peněz. (autor) „Nástroje v rámci BI prostředí organizace, které umožňují ne-IT uživatelům stát se více soběstačnými a méně závislými na IT odděleních. Hlavními cíly SS BI jsou snazší přístup ke zdrojovým datům pro reporting a analýzy, jednoduchost a intuitivní práce s nástroji, důraz na srozumitelnost BI výstupů a následné zpracování a v neposlední řadě rychlé nasazení technologie v organizacích.“ (Imhoff, a další, 2011) Schéma uspořádání tabulek v datovém skladu, kdy jsou dimenzionální tabulky napojené na tabulky faktů normalizované do více tabulek a svým vzhledem tak připomínají sněhovou vločku. (autor) Dimenze, která je tvořena právě jednou tabulkou, připomínající svým vzhledem hvězdu. (autor)


91 / 100

8 SEZNAM LITERATURY Bennett, Russell. 2013. Self-service Business Intelligence: the IT department’s role. spaceage.co.za. [Online] 31. 6 2013. [Citace: 8. 9 2014.] http://www.spaceage.co.za/blog/business-intelligence/rapid-fire-business-intelligence-the-itdepartments-role/. Berg, Magnus. 2014. Qlik Sense Architecture: Understand the basics of the new Sense platform. [Online] 21. 10 2014. [Citace: 30. 10 2014.] http://qvfiles.s3.amazonaws.com/landing_pages/DK/DK-VYW_Qlik_SenseArchitecture.pdf. Černý, Ondřej. 2013. Self-service BI a PowerPivot. Praha : autor neznámý, 2013. Cisco. 2014. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018. Cisco. [Online] 5. 2 2014. [Citace: 26. 8 2014.] http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-indexvni/white_paper_c11-520862.pdf. Coates, Melissa. 2013. Corporate BI and Self-Service BI - One Size Does Not Fit All. SQL Chick. [Online] 15. 3 2013. [Citace: 20. 9 2014.] http://www.sqlchick.com/entries/2013/3/15/corporate-bi-and-self-service-bi-one-size-doesnot-fit-all.html. —. The Role of Power Users in a Self-Service BI Initiative. Blue Granite. [Online] [Citace: 23. 8 2014.] http://www.blue-granite.com/blog/bid/328825/The-Role-of-Power-Users-in-aSelf-Service-BI-Initiative. Compositesw.com. BUSINESS VIEWS: Business Views to Simplify Rationalize IT Data. Compositesw.com. [Online] [Citace: 27. 8 2014.] http://www.compositesw.com/datavirtualization/business-views/. Formánek, Václav. 2013. Self-service BI - problémy současné architektury. Praha : autor neznámý, 2013. Gála, Libor, Pour, Jan a Toman, Prokop. 2006. Porniková informatika. Praha : Grada Publishing a.s., 2006. 80-247-1278-4. Gartner. Business Intelligence (BI). Gartner. [Online] [Citace: 26. leden 2014.] http://www.gartner.com/it-glossary/business-intelligence-bi/. —. 2013. Gartner Says Worldwide Business Intelligence Software Revenue to Grow 7 Percent in 2013. Gartner. [Online] 19. únor 2013. [Citace: 20. leden 2014.] http://www.gartner.com/newsroom/id/2340216. —. 2014. Magic Quadrant for Business Intelligence and Analytics Platforms. Gartner. [Online] 20. 2 2014. [Citace: 10. 9 2014.] http://www.gartner.com/technology/reprints.do?id=1-1QLGACN&ct=140210&st=sb. Zavedení Self-Service BI u MVNO GoMobil

92 / 100

—. self-service business intelligence. Gartner. [Online] [Citace: 18. leden 2014.] http://www.gartner.com/it-glossary/self-service-business-intelligence. HBR. 2013. Data and Organizational Issues Reduce Confidence. Harward Business Review. [Online] 2013. [Citace: 23. 8 2014.] http://issuu.com/bsgmanager/docs/wp-hbr-pulse-surveyen/2. Imhoff, Claudia a White, Colin. 2011. Self-Service Business Intelligence: Empowering Users to Generate Insights. Renton, WA : The Data Warehousing InstituteTM, 2011. Jan, Pour, Libor, Gála a Zuzana, Šedivá. 2009. Podniková informatika. 2. vydání. Praha : Grada Publishing a.s., 2009. 978-80-247-2615-1. Janošek, Tomáš. 2010. Aplikace typu Business Intelligence v podnikové praxi. Praha : autor neznámý, 2010. MBI. Management Byznys Informatiky. [Online] http://mbi.vse.cz/. Novotný, Ota, Pour, Jan a Slánský, David. 2005. Business Intelligence: Jak využít bohatství ve vašich datech. Praha : Grada Publishing a.s., 2005. 80-247-1094-3. Pour, Jan, Maryška, Miloš a Novotný, Ota. 2012. Business Intelligence v podnikové praxi. Praha : Professional Publishing, 2012. 978-80-7431-065-2. Pover, Karl. 2014. Data Discovery in QlikView – Part 1 – Agile Implementation. PowerConsulting.com. [Online] 26. 9 2014. [Citace: 1. 11 2014.] http://poverconsulting.com/2014/09/26/data-discovery-in-qlikview-part-1-leanimplementation/. Power to the People. Saporito, Pat. 2012. Vol. 113 Issue 7, p72-72. 1p., místo neznámé : Best's Review, 2012. 1527-5914. Qlik. 2014. 3 Big Data Myths, Busted. Qlik. [Online] 2014. [Citace: 23. 8 2014.] http://www.qlik.com/tw/explore/resources/e-books/3-big-data-myths-busted. —. Qlik Help. Qlik Help. [Online] [Citace: 25. 10 2014.] https://help.qlik.com/sense/enUS/online/index.html#Home.htm. —. Qlik Sense. Qlik. [Online] [Citace: 16. 11 2014.] http://www.qlik.com/~/media/Images/Headline-Pictures/new_sense_overview-bottom_left2.ashx?h=205&w=436. —. 2014. QlikView architectural overview. Qlik. [Online] 1 2014. [Citace: 20. 9 2014.] http://www.qlikview.com/us/~/media/Files/resource-library/globalus/register/whitepapers/qlikview11/WP-QlikView-Architectural-Overview-EN.ashx. Schlegel, Kurt. 2014. How to Deliver Self-Service Business Intelligence. Gartner. [Online] 28. 5 2014. [Citace: 7. 9 2014.] Zavedení Self-Service BI u MVNO GoMobil

93 / 100

http://www.gartner.com/it/content/2645500/2645517/february_20_how_to_deliver_self_servi ce_kschlegel.pdf?userId=77581140. Sinha, Chandraish. QVDs in Qlikview. Learn QlikView. [Online] [Citace: 7. 11 2014.] http://www.learnallbi.com/qvds-in-qlikview/. Smietana, Frank. 2013. 5 Ways to Bring Self-Service BI to Your Small or Midsized Business. Information management. [Online] 20. srpen 2013. [Citace: 2. leden 2014.] http://www.information-management.com/news/five-ways-to-bring-self-service-bi-to-yoursmall-or-midsized-business-10024780-1.html. Torode, Christina. Ensuring self-service BI doesn't become a data free-for-all. techtarget.com. [Online] [Citace: 26. 8 2014.] http://searchcio.techtarget.com/news/2240147443/Ensuring-self-service-BI-doesnt-become-adata-free-for-all. Wachstock, Michal. 2014. 3 Ways Self-Service BI Tools Will Free You From Your IT Bottleneck. SiSence. [Online] 27. 1 2014. [Citace: 26. 8 2014.] http://www.sisense.com/blog/3-ways-self-service-bi-tools-will-free-you-from-your-itbottleneck/. Yap, Jamie. 2011. Self-service BI brings benefits, challenges. ZDNET. [Online] 11. 12 2011. [Citace: 27. 8 14.] http://www.zdnet.com/self-service-bi-brings-benefits-challenges2062303227/.


94 / 100

9 SEZNAM OBRÁZKŮ A TABULEK Obrázek 1: Komponenty vyskytující se v klasickém BI řešení (Novotný, a další, 2005) .................. 16 Obrázek 2: Hlavní důvody pro zavádění SS BI (Imhoff, a další, 2011) ..................................................... 19 Obrázek 3: Typy uživatelů SS BI (Coates)............................................................................................................. 22 Obrázek 4: SS BI proces (Imhoff, a další, 2011) ................................................................................................. 24 Obrázek 5: Požadavky na SS BI řešení (Imhoff, a další, 2011) ..................................................................... 26 Obrázek 6: Benefity nástrojů pro podporu spolupráce (Imhoff, a další, 2011) .................................... 29 Obrázek 7: Míra SS BI (Schlegel, 2014) ................................................................................................................. 30 Obrázek 8: BI Gartner Magic Quadrant (Gartner, 2014) ................................................................................ 34 Obrázek 9: Asociativní indexace dat (Qlik, 2014) ............................................................................................. 35 Obrázek 10: Drag & drop vizualizace dat (autor).............................................................................................. 36 Obrázek 11: Responsivní zobrazení Qlik Sense aplikací (Qlik) ................................................................... 37 Obrázek 12: Sešit aplikace Qlik Sense (autor) .................................................................................................... 39 Obrázek 13: Qlik Cloud (autor) ................................................................................................................................. 40 Obrázek 14: Data Load Editor (autor) ................................................................................................................... 43 Obrázek 15: Definice ODBC spojení (autor) ........................................................................................................ 44 Obrázek 16: Datový model Qlik Sense (Qlik) ...................................................................................................... 48 Obrázek 17: Sešit aplikace Qlik Sense (autor) .................................................................................................... 49 Obrázek 18: Záložky Qlik Sense (autor) ................................................................................................................ 51 Obrázek 19: Výběry v Qlik Sense (autor).............................................................................................................. 52 Obrázek 20: „Lasso Selection“ v Qlik Sense (autor) ......................................................................................... 53 Obrázek 21: Single-node architektura (Qlik) ...................................................................................................... 55 Obrázek 22: Qlik Sense Management Console (autor) .................................................................................... 57 Obrázek 23: Nastavení licencí v Qlik Sense (autor).......................................................................................... 58 Obrázek 24: Řízení obsahu v Qlik Sense (Berg, 2014) .................................................................................... 60 Obrázek 25: Kanály souvisejících aplikací (autor)............................................................................................ 60 Obrázek 26: Logika a interakce jednotlivých prvků v Qlik Sense (Qlik) .................................................. 61 Obrázek 27: Porovnání postupů vývoje řešení (Pover, 2014) ..................................................................... 65 Obrázek 28: Log a výsledek běhu skriptu (autor) ............................................................................................. 80 Obrázek 29: Výsledný datový model (autor) ...................................................................................................... 82 Obrázek 30: Zobrazení poměru aktivních zákazníků dle jejich věku (autor)........................................ 83 Obrázek 31: Poměr zákazníků dle počtu aktivních služeb (autor) ............................................................ 85 Obrázek 32: Průměrně minut/sms dle věku (autor) ....................................................................................... 86


95 / 100

10 PŘÍLOHY 10.1 LOG PROBĚHLÉHO ETL SKRIPTU Started loading data Connecting to MySQL_GoMobil Connected f_zakaznik << c_contact Lines fetched: 19 934 f_zakaznik Lines fetched: 19 934 f_zakaznik Lines fetched: 19 934 f_zakaznik Lines fetched: 19 934 d_zakaznik_lokalita_adresa << c_address Lines fetched: 23 787 d_zakaznik_lokalita_okres << Zv_pcobc$ Lines fetched: 16 736 d_zakaznik_lokalita_kraj << okres_kraj Lines fetched: 6 250 QuartersMap << AUTOGENERATE(12) Lines fetched: 12 Temp << f_zakaznik Lines fetched: 1 TempCalendar << AUTOGENERATE(1) Lines fetched: 557 d_zakaznik_kalendar << TempCalendar Lines fetched: 557 f_sluzba << bs_base_service Lines fetched: 30 645 f_sluzba Lines fetched: 30 645 f_sluzba Lines fetched: 30 645 QuartersMap << AUTOGENERATE(12) Lines fetched: 12 Temp << f_sluzba Lines fetched: 1 TempCalendar << AUTOGENERATE(1) Lines fetched: 526 d_sluzba_kalendar << TempCalendar Lines fetched: 526 d_mvno << f_sluzba Lines fetched: 30 645 Tmp << bs_tariff Lines fetched: 47 380 bs_tariff_def Lines fetched: 175 d_tarif << Tmp Lines fetched: 35 103 Tmp << bs_add_service Lines fetched: 47 959 bs_add_service_def Lines fetched: 68 bs_add_service_param_def Lines fetched: 1 128 d_doplnkovka << Tmp Lines fetched: 45 484 f_transakce << gm_call_data Lines fetched: 21 762 167 f_transakce Lines fetched: 21 762 167 QuartersMap << AUTOGENERATE(12) Lines fetched: 12 Temp << f_transakce Lines fetched: 1 TempCalendar << AUTOGENERATE(1) Lines fetched: 550 d_transakce_kalendar << TempCalendar Lines fetched: 550 App saved Finished successfully 0 forced error(s) 0 synthetic key(s)


96 / 100

10.2 VYGENEROVÁNÍ UMĚLÉ ČASOVÉ DIMENZE Dimenze: Datum zákazníka Pole: datumAkvizice_zakaznik, tydenAkvizice_zakaznik, mesicAkvizice_zakaznik, kvartalAkvizice_zakaznik, rokAkvizice_zakaznik // Kvartálová mapa QuartersMap: MAPPING LOAD rowno() as Month, 'Q' & Ceil (rowno()/3) as Quarter AUTOGENERATE (12); // Načtení min a max data v tabulce zákazníků Temp: Load min(datum_zakaznik) as minDate, max(datum_zakaznik) as maxDate resident f_zakaznik; // Uložení číselného vyjádření data do proměnné Let varMinDate = Num(Peek('minDate', 0, 'Temp')); Let varMaxDate = Num(Peek('maxDate', 0, 'Temp')); DROP Table Temp; // vygenerování všech číselných vyjádření datumů mezi varMinDate a varMaxDate TempCalendar: LOAD $(varMinDate) + rowno() - 1 AS Num, $(varMinDate) + rowno() - 1 AS TempDate AUTOGENERATE 1 While $(varMinDate)+IterNo()-1<= $(varMaxDate); // Kalendář obsahující datum, číslo týdne, měsíce, kvartál, rok d_kalendar_akvizice_zakaznik: LOAD date(floor(TempDate)) AS datumAkvizice_zakaznik, Week(TempDate) AS tydenAkvizice_zakaznik, Month(TempDate) AS mesicAkvizice_zakaznik, ApplyMap('QuartersMap', month(TempDate), Null()) as kvartalAkvizice_zakaznik, Year(TempDate) AS rokAkvizice_zakaznik RESIDENT TempCalendar ORDER BY TempDate ASC; DROP TABLE TempCalendar;


97 / 100

10.3 PŘÍRŮSTKOVÉ NAČÍTÁNÍ DAT TRANSAKCÍ //kontrola existence QVD souboru LET vQVDExists = not isnull(QVDCreateTime('lib://folder/f_transakce.qvd')); IF $(vQVDExists) THEN

/*****************************QVD existuje*******************************/ // načti qvd soubor s transakcemi transakceid: LOAD id_transakce FROM [lib://folder/f_transakce.qvd](qvd);

//najdi nejvyšší ID v souboru last_id: Load max(id_transakce) as last_id resident transakceid;

//proměnná s tímto ID let last_updated = peek('last_id',0,'last_id');

// drop tables drop table transakceid; drop table last_id; //inkrementální load increment: Load id as id_transakce, date(floor(date)) as datum_transakce, base_service_id as id_sluzba, duration/60 as dobaHovoru_transakce, volume as mnozstviDat_transakce, type as typ_transakce, to_type as kamOperator_transakce, roaming, international;


98 / 100

SQL SELECT id , date, base_service_id, duration, volume, type, to_type, roaming, international FROM db.`transakce` WHERE id>$(last_updated) and ((type=('CALL' or 'SMS' or 'MMS' or 'PAYMENT') and direction='OUTGOING') or type='DATA'); //slouceni s qvd Concatenate LOAD id_transakce, datum_transakce, id_sluzba, dobaHovoru_transakce, mnozstviDat_transakce, typ_transakce, kamOperator_transakce, roaming, international FROM [lib:// folder/f_transakce.qvd] (qvd); //ulozeni noveho prirustku Store increment into [lib://folder/f_transakce.qvd]; // drop table prirustek drop table increment; //load updated qvd f_transakce: LOAD id_transakce, datum_transakce, id_sluzba, dobaHovoru_transakce, mnozstviDat_transakce, typ_transakce, kamOperator_transakce, roaming, international FROM [lib:// folder/f_transakce.qvd](qvd);


99 / 100

/*****************************QVD ještě neexistuje*******************************/ ELSE // načtení všech dat z primárního zdroje f_transakce: Load id as id_transakce, date(floor(date)) as datum_transakce, base_service_id as id_sluzba, duration/60 as dobaHovoru_transakce, // sekundy -> minuty volume as mnozstviDat_transakce, type as typ_transakce, to_type as kamOperator_transakce, roaming, international; SQL SELECT id , date, base_service_id, duration, volume, type, to_type, roaming, international FROM db.`transakce` WHERE ((type=('CALL' or 'SMS' or 'MMS' or 'PAYMENT') and direction='OUTGOING') or type='DATA'); // Uložit záznamy do QVD souboru Store f_transakce into [lib://folder/f_transakce.qvd]; END IF;


100 / 100

Zavedení Self-Service BI u MVNO GoMobil

Recommend Documents