Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Diplomová práce

Reportování pro efektivní řízení fakulty Bc. Adam Kučera

Vedoucí práce: Ing. Pavel Kordík, Ph.D.

14. května 2012

Poděkování Děkuji svému vedoucímu, Ing. Pavlu Kordíkovi, Ph.D., za ochotu a trpělivost, Davidu Kadlečkovi a Petru Svobodovi za pomoc a své rodině za skvělé zázemí a podporu.

Prohlášení Prohlašuji, že jsem tuto práci vytvořil samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některý zákonů (autorský zákon), nemám závažný důvod proti užití tohoto školního díla a k užití uděluji svolení.

V Praze dne 14. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Adam Kučera. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Adam Kučera. Reportování pro efektivní řízení fakulty: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract Masters thesis covers whole life cycle of business report for efective faculty management. It introduces and uses key performance indicator methodology in key areas of faculty, describes possibilities and technologies of data warehouse querying and designs business reports for introduced performance indicators. It examines the options of graphical representation of these reports as portlets for portal of faculty information system and describes the overall architecture of such solution. Keywords key performance indicator (KPI), business intelligence (BI), data warehouse, OLAP, report, portlet

Abstrakt Diplomová práce pokrývá celý životní cyklus reportů pro efektivní řízení fakulty. Zavádí a rozpracovává použití metodiky klíčových ukazatelů výkonnosti v zásadních oblastech fakulty, popisuje možnosti a technologie dotazování se nad fakultním datovým skladem a pro zavedené ukazatele výkonnosti navrhuje reporty. Pro ně pak zkoumá možnosti zobrazení, navrhuje portlety pro portál fakultního informačního systému a popisuje celkovou architekturu takového řešení. Klíčová slova klíčový ukazatel výkonnosti (KPI), business intelligence (BI), datový sklad, OLAP, report, portlet

9

Obsah Odkaz na tuto práci . . . . . . . . . . . . . . . . . . . . . . . . Úvod

8 19

1 KPI - klíčové ukazatele výkonnosti 21 1.1 Stav problematiky v oblasti klíčových ukazatelů výkonnosti . . 21 1.1.1 Zaměření na správné oblasti . . . . . . . . . . . . . . . . 23 1.1.2 Zaměření na správná KPIs . . . . . . . . . . . . . . . . 23 1.1.3 Zaměření na formulaci KPIs . . . . . . . . . . . . . . . . 23 1.2 Analýza problému a nastínění řešení . . . . . . . . . . . . . . . 27 1.2.1 Výkonnost . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.2.2 Metriky a měření výkonnosti . . . . . . . . . . . . . . . 27 1.2.3 KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.2.4 Definice klíčových ukazatelů výkonnosti . . . . . . . . . 28 1.2.5 Parametry a použití klíčových ukazatelů výkonnosti . . 29 1.3 Vlastní řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.3.1 Konstrukce klíčových ukazatelů výkonnosti v prostředí fakulty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.3.1.1 Proces přijetí doktoranda . . . . . . . . . . . . 30 1.3.1.2 Proces obhajoba disertační práce . . . . . . . . 31 1.3.1.3 Proces vydávání skript . . . . . . . . . . . . . 33 1.3.1.4 Proces public relations - vztahy s veřejností . . 33 1.3.1.5 Proces správa lokálního hardware . . . . . . . 34 1.3.1.6 Proces správa lokálního software . . . . . . . . 35 1.3.1.7 Procesy personalistiky . . . . . . . . . . . . . . 35 1.3.1.8 Proces zahraniční cesty . . . . . . . . . . . . . 37 1.3.1.9 Procesy mobilita studentů a kantorů . . . . . . 39 1.3.1.10 Proces správa webu . . . . . . . . . . . . . . . 40 1.3.1.11 Proces nákupy . . . . . . . . . . . . . . . . . . 41 1.3.2 Návrh KPI pro vybrané oblasti . . . . . . . . . . . . . . 43 1.3.2.1 Doktorské studium - školitelé . . . . . . . . . . 43 1.3.2.2 Přijímací řízení - přihlášky . . . . . . . . . . . 43 1.3.2.3 Závěrečné práce - vedoucí . . . . . . . . . . . . 45 1.3.2.4 Hodnocení pedagogických výkonů . . . . . . . 45 11

2 BI reporty nad fakultním datovým skladem 2.1 Problematika datových skladů . . . . . . . . . . . . . . . . . . . 2.1.1 Motivace pro využití datového skladu . . . . . . . . . . 2.1.1.1 Datový sklad, data a informace . . . . . . . . . 2.1.1.2 Technologie pro datový sklad . . . . . . . . . . 2.1.2 Struktura dat v datovém skladu, OLAP operace a reporty 2.1.2.1 Struktura dat v datovém skladu . . . . . . . . 2.1.2.2 OLAP operace a reporty . . . . . . . . . . . . 2.1.3 MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Analýza a návrh řešení BI reportů . . . . . . . . . . . . . . . . 2.2.1 Doménový model . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Navržené reporty . . . . . . . . . . . . . . . . . . . . . . 2.2.2.1 Doktorské studium - školitelé . . . . . . . . . . 2.2.2.2 Přijímací řízení - přihlášky . . . . . . . . . . . 2.2.2.3 Závěrečné práce - vedoucí a přehledový report 2.3 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Report výkon učitele . . . . . . . . . . . . . . . . . . . . 2.3.1.1 Databáze a dostupná data a datová kostka . . 2.3.1.2 MDX dotaz a výstup . . . . . . . . . . . . . .

47 47 48 49 50 50 50 51 54 54 55 57 57 58 59 61 61 61 62

3 Rozhraní a GUI BI reportů 65 3.1 Použité technologie a postupy . . . . . . . . . . . . . . . . . . . 65 3.1.1 REST API . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.1.1.1 Princip REST, operace a formát dat . . . . . . 66 3.1.1.2 Servlety jako zdrojové služby, JAX-RS . . . . . 66 3.1.1.3 Umístění zdrojů, DWHAPI . . . . . . . . . . . 67 3.1.2 GUI pro reporty . . . . . . . . . . . . . . . . . . . . . . 67 3.1.2.1 Adobe Flex . . . . . . . . . . . . . . . . . . . . 67 3.1.2.2 Nástroje a komponenty pro vizualizaci reportů 68 3.1.3 Komunikace mezi portletem a API . . . . . . . . . . . . 68 3.2 Architektura a návrh řešení . . . . . . . . . . . . . . . . . . . . 69 3.2.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2.2.1 Základní služby DWHAPI . . . . . . . . . . . 69 3.2.2.2 Služby reportů . . . . . . . . . . . . . . . . . . 70 3.2.2.3 Struktura rozhraní . . . . . . . . . . . . . . . . 72 3.2.3 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.2.3.1 Portlet doktorské studium - školitelé . . . . . . 72 3.2.3.2 Portlet přijímací řízení - přihlášky . . . . . . . 74 3.2.3.3 Portlet závěrečné práce . . . . . . . . . . . . . 75 3.2.3.4 Portlet závěrečné práce - vedoucí bakalářských prací . . . . . . . . . . . . . . . . . . . . . . . 77 3.2.3.5 Portlet komise . . . . . . . . . . . . . . . . . . 78 3.2.4 Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . 80 12

3.2.4.1 3.2.4.2

3.3

3.2.4.3 Implementace 3.3.1 Portlet

Handshake, získání portletu a iniciální nahrání dat . . . . . . . . . . . . . . . . . . . . . . . . Množina přenášených dat, opětovné nahrání a cache . . . . . . . . . . . . . . . . . . . . . . . Detaily volání, autentizace a autorizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . výkon učitelů . . . . . . . . . . . . . . . . . . . .

80 80 82 84 84

Závěr

87

Literatura

89

A Seznam použitých zkratek

91

B Hvězdicové schéma databáze úvazky

93

C Schéma datové kostky pro report výkon učitele

97

D Obsah přiloženého CD

99

13

Seznam obrázků 1.1 1.2

Vývoj dokončených doktorských studií v letech na Iowa State University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vývoj podílu online vzdělávání v letech na Iowa State University .

26 26

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13

Hierarchie data, informace, znalosti . . . . . . . . . . . . . . . . . . datová (OLAP) kostka . . . . . . . . . . . . . . . . . . . . . . . . . řez datovou kostkou (slice) . . . . . . . . . . . . . . . . . . . . . . kostkování datové kostky (dice) . . . . . . . . . . . . . . . . . . . . otáčení datové kostky (pivot) . . . . . . . . . . . . . . . . . . . . . zavrtávání datové kostky (drill-down) . . . . . . . . . . . . . . . . doménový model datového skladu . . . . . . . . . . . . . . . . . . . návrh číselníků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . model reportu doktorské studium - školitelé . . . . . . . . . . . . . číselníky dimenzí datové kostky reportu doktorské studium - školitelé model reportu přijímací řízení - přihlášky . . . . . . . . . . . . . . model reportu závěrečné práce - vedoucí . . . . . . . . . . . . . . . model reportu přehled závěrečných prácí . . . . . . . . . . . . . . .

49 51 51 52 52 53 56 57 58 58 59 60 61

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16

návhr architektury řešení datového skladu, jeho rozhraní a portletů model rozhraní služby pro získání dostupných reportů a portletů . model rozhraní služby reportu výkon učitele . . . . . . . . . . . . . wireframe portletu doktorské studium - školitelé . . . . . . . . . . . diagram užití portletu doktorské studium - školitelé . . . . . . . . . wireframe portletu příjímací řízení - přihlášky . . . . . . . . . . . diagram užití portletu příjímací řízení - přihlášky . . . . . . . . . . wireframe portletu závěrečné práce . . . . . . . . . . . . . . . . . . diagram užití portletu závěrečné práce . . . . . . . . . . . . . . . . wireframe portletu závěrečné práce - vedoucí bakalářských prací . . diagram užití portletu závěrečné práce - vedoucí bakalářských prací wireframe portletu komise . . . . . . . . . . . . . . . . . . . . . . . diagram užití portletu komise . . . . . . . . . . . . . . . . . . . . . návrh architektury komunikace portlet - api - datový sklad . . . . akce po invokaci služeb /portlet/ a /report/ . . . . . . . . . . . . . implementovaný portlet výkon učitelů . . . . . . . . . . . . . . . .

70 71 71 73 74 75 75 76 76 77 78 79 79 81 83 84 15

B.1 hvězdicové schéma databáze úvazky (1. část) . . . . . . . . . . . . B.2 hvězdicové schéma databáze úvazky (2. část) . . . . . . . . . . . .

16

94 95

Seznam tabulek 1.1

KPI Zkušenosti studentů

. . . . . . . . . . . . . . . . . . . . . . .

25

2.1

výsledek MDX dotazu . . . . . . . . . . . . . . . . . . . . . . . . .

54

17

Úvod Škola, ať už fakulta informačních technologií, nebo České vysoké učení technické jako celek, sbírá v dnešní době ohromné množství dat, o studentech, učitelích, katedrách, odděleních, činnostech každého subjektu a mnoho dalších. Data jsou však vázána na způsob, jakým byla získána, může to být papírový formulář stejně jako specifická databáze nějaké aplikace. Přitom by se tato data dala efektivně využít pro rozhodování a analýzu téměř ve všech úrovních školy, od studentů a zaměstnanců po vrcholový management. Tato práce probíhá společně s vývojem nového fakultního informačního systému, jehož částí je i nasazení fakultního datového skladu, a zabývá se částečnou definicí a především využitím dat, která budou v datovém skladu uložena. Proces využití dat má tři fáze, nejprve jsou abstraktně a obecně popsány požadavky, poté jsou takto definované požadavky specifikovány a zrealizovány nad daty v datovém skladu a nakonec jsou výsledky zobrazeny ve formě snadno čitelné pro uživatele. Práce tento proces respektuje a je dělena do tří uzavřených celků, které na sebe postupně navazují. Prvním krokem při využití dat z datového skladu pro zefektivnění práce a rozhodování je zodpovězení čtyř základních otázek - co chceme sledovat, kde pro to vezmeme data, k čemu to bude a kdo to bude využívat. Formalizací tohoto postupu se zabývá metodika klíčových ukazatelů výkonnosti, cílem práce je tedy tuto metodiku prozkoumat, navrhnout její použití v prostředí fakulty a zároveň zmapovat klíčové ukazatele výkonnosti vybraných oblastí. Druhým krokem po specifikaci klíčových ukazatelů výkonnosti je samotná realizace nad daty v datovém skladu, jejíž výstupem je analytický report. Tato část úzce souvisí s definicí datového skladu, protože právě v této části mohou vznikat konkrétní požadavky na jeho obsah. Práce si klade za cíl prozkoumat možnosti realizace dotazů nad daty v datovém skladu a rozpracovat navržené ukazatele výkonnosti do reportů na úrovni návrhu a případně implementace. Posledním krokem je prezentace reportu vzniklého dotazem nad daty v datovém skladu uživateli srozumitelnou a snadno uchopitelnou formou tak, aby výsledek uživateli usnadnil a zefektivnil práci a rozhodování. Součástí vývoje nového fakultního informačního systému je i nasazení portálu, který bude uživatelským rozhraním tohoto systému. Práce si tedy klade za cíl navrhnout a případně realizovat analytické reporty jako portlety, které budou moci být v portálu používány, a především navrhnout a detailně popsat architekturu 19

Úvod takového řešení. Celá práce tedy může sloužit jako průvodce možným využitím dat školy pro její efektivní řízení.

20

KAPITOLA

KPI - klíčové ukazatele výkonnosti Tato kapitola se zabývá problematikou KPI - klíčových ukazatelů výkonnosti1 (dále jen KPI). Je členěna na tři části. V první části jsou uvedeny důležité definice v oblasti KPI, důležité faktory při tvorbě KPI a diskutují se některé případy, kdy byla metodika KPI použita v univerzitním prostředí. Ve druhé části je analyzován řešený problém a je proveden rozbor vybraných důležitých procesů fakulty informačních technologií Českého vysokého učení technického v Praze a diskutovány navržené KPI. Třetí část pokrývá detailní rozbor KPI pro vybrané oblasti, které pak budou použité jako základ pro návrhovou a implementační část celé práce.

1.1

Stav problematiky v oblasti klíčových ukazatelů výkonnosti

Aby bylo možné vytvořit základ pro definování klíčových ukazatelů výkonnosti napříč fakultou, budou v této sekci zběžně popsány nejdůležitější pojmy při návrhu KPI a také způsob jejich konstrukce. Výkonnost - Výkonnost znamená charakteristiku, která popisuje způsob, respektive průběh, jakým zkoumaný subjekt vykonává určitou činnost, na základě podobnosti s referenčním způsobem vykonání (průběhu) této činnosti. Interpretace této charakteristiky předpokládá schopnost porovnání zkoumaného a referenčního jevu z hlediska stanovené kriteriální škály.[15] 1 zkratka KPI vznikla sloučením počátečních písmen anglického názvu Key Performance Indicator

21

1

1. KPI - klíčové ukazatele výkonnosti Metrika - Měřitelný údaj v procesu, definice způsobu měření a přiřazování hodnoty. Stanovení metriky a možnost jejího měření je nutným předpokladem pro jakékoliv porovnání činnosti subjektů.[20] KPI - KPI je primární nebo sekundární ukazatel výkonnosti subjektu nebo jeho části. Nejčastěji se používá v kontextu obchodní organizace jako míra obchodní výkonnosti. Kolekce klíčových ukazatelů výkonnosti (dále jen KPIs) jsou měření navržená pro vizualizaci, hodnocení a řízení výkonnosti vybraných operací uvnitř organizace.[18] Jsou stejně vhodné pro komerční organizace jakožto i pro nekomerční organizace, tedy například školy a univerzity. Cíle KPI - dát managementu organizace transparentní a měřitelné údaje o tom, jak fungují (respektive nefungují) vybrané části organizace. Tyto informace jsou sbírány kontinuálně za účelem • optimalizace chodu organizace • ad hoc řízení organizace (okamžité zásahy v případě náhlých poklesů výkonnosti) • prediktivní řízení organizace (včasné odhalení tendence směřující k poklesu výkonnosti) Výzkumem problematiky KPI a vlastním nasazováním se zabývá celá řada soukromých firem, individuálních výzkumíků a univerzit. Jedním z pionýrů této problematiky je i David Parmenter, který ve své knize (viz [13]) definuje 12ti krokový model. Ukazuje, jak použít tento model při konstrukci KPI a definuje kontrolní body pro ověření toho, že byly aplikovány všechny vhodné kroky. Tyto základní kroky jsou 1. získejte a udržujte podporu senior management týmu 2. postavte projektový tým 3. nastavte „just-do-it“ kulturu pro implementaci KPI 4. nastavte holistickou strategii vývoje KPI 5. prodejte systém KPI všem zaměstnancům 6. identifikujte klíčové faktory úspěchu 7. zaznamenávejte měření 8. zaveďte měření výkonnosti na úrovni týmů 9. vyberte KPIs které jsou klíčové pro vaši organizaci 10. implementujte framework pro reporting 22

1.1. Stav problematiky v oblasti klíčových ukazatelů výkonnosti 11. prosazujte používání KPIs 12. upravte KPI podle posledních změn Vlastní definice KPI je velmi složitý proces, který vyžaduje zkušenosti a multi-oborový pohled na věc. Mezinárodní fórum pro výzkum a aplikaci KPI (viz [19]) doporučuje následující postup při definici KPI. Některé z aspektů tohoto postupu byly použity i při konstrukci KPI v této diplomové práci. Formulace „nechť je měřeno co má být měřeno“ ilustruje důležitost měření správných věcí a naopak neměření zbytečností. Správný výběr KPI má velký vliv na fungování organizace a kruciálním se stává porozumění faktorů ovlivňujících sledované výkonnosti.

1.1.1

Zaměření na správné oblasti

KPIs by se měly zaměřit na aspekty důležité pro organizaci. To znamená, že organizace by měla mít v každém okamžiku jasno v tom, čeho a jak se snaží dosáhnout. KPIs by se měla zaměřit na akce a služby poskytované na každé úrovni organizace. KPIs na vyšší úrovni budou adresovat celopodnikové cíle a KPIs na nižší úrovni se zaměří na denní operativu. Častou chybou je také to, že organizace se snaží měřit to, co je jednoduše měřitelné místo toho, co by mělo být měřeno.

1.1.2

Zaměření na správná KPIs

Je důležité implementovat dobře vybalancovanou množinu KPIs, které reflektují všechny důležité aspekty služby. Existuje několik různých frameworků, které adresují tuto problematiku • 3Es framework - užití tří dimenzí ekonomie, efektnost a efektivita • Balanced Scorecard - užívá čtyři perspektivy pro reprezentaci všeobjímajícího pohledu na výkonnost organizace (služba, perspektiva uživatele; perspektiva z pohledu interního řízení; perspektiva z pohledu učení; finanční perspektiva) • Best Value KPI

1.1.3

Zaměření na formulaci KPIs

Formulace správných KPI by měla dodržovat určité konkrétní kroky. Za prvé, vyhnout se objevování již objeveného. Internet umožňuje přístup k obrovskému množství KPI, a proto může být velkou pomocí v první orientaci. Za druhé, pokus o formulaci kompletního indikátoru napoprvé zřídka vyústí v kvalitní KPI. Proto, na základě charakteristiky SMART KPIs (konkrétní, měřitelné, dosažitelné, relevantní, časově omezené) při formulaci KPI, by měly být zodpovězeny následující otázky 23

1. KPI - klíčové ukazatele výkonnosti • Co? (brainstorming o proměnných, které mohou poskytnout prostředky k měření změny v cílech nebo fenoménech problému) • Jak moc? (definovat velikost změny, které chceme dosáhnout) • Kdo? (aby se ujasnilo, kdo patří do cílové skupiny) • Kde? (specifické informace o oblasti intervence) • Kdy? (vymezení časového rámce) KPI má již zavedeno nebo zavádí většina univerzit ve velké Británii a v Austrálii. V USA je míra použití KPI zatím nižší, nicméně i zde dochází k rozšiřování. Jednou z institucí, která úspěšně zavedla KPIs je například prestižní University of Essex (viz [16]). University of Essex zavedla, měří a vyhodnocuje KPIs v těchto oblastech (zmíněno pět nejdůležitějších) • výzkum • zkušenosti studentů • výměna znalostí • globální • finanční a navíc doplňková KPI • vybavení • rozšiřování příležitostí • zaměstnanci • řízení a správa • regionální Například pro oblast „zkušenosti studentů“ byly zavedeny následující KPI (každoročně revidováné školní radou)

24

1.1. Stav problematiky v oblasti klíčových ukazatelů výkonnosti

Tabulka 1.1: KPI oblasti „zkušenosti studentů“ na University of Essex (zdroj [16]) KPI Spokojenost studentů

Měření Národní studentský průzkum (NS) Studentský průzkum spokojenosti (interní) Postgraduální průzkum zkušeností (PRES, PTES)

Zaměstnatelnost absolventů

DLHE průzkum

Příležitosti pro další rozvoj Implementace plánování osobního rozvoje Absolventské podnikání Studentský život

Finanční zdraví

Finanční zdraví hlavních akademických činností Diverzifikace

Spokojenost studentů s úrovní nabízených sociálních příležitostí Přebytek Likvidita

Podíl osobních nákladů k příjmům Růst příjmů Finanční výkonnosti fakult

Ostatní provozní výnosy a příjmy z výzkumných grantů jako procento z celkových příjmů Příjmy z fundraisingu

Cíl\Milník Celková míra spokojenosti (Q22) 90% Lepší výsledky spokojenosti ve všech sledovaných oblastech (90% celkové spokojenosti) Vysoká úroveň spokojenosti benchmarkovaná proti jednotlivým odvětví 90% absolventů v zaměstnání nebo další studium, 70% absolventů v zaměstnání vyžadujícím univerzitní vzdělání nebo postgraduální studium Umístění na klíčových pozicích - 300 v ustáleném stavu Zvýšené zavádění plánování osobního rozvoje, včetně e-portfolia Pět absolventských start-up firem za rok Vysoká míra spokojenosti (85%) v NSS B4 dotazníku ve srovnání s ostatními univerzitami 3,5% z obratu Držet dostatek hotovosti k financování alespoň 25 dnů průměrných výdajů V souladu se skupinou roku 1994 5% p.a. Přinejmenším vyrovnaná sumární bilance přes všechny fakulty

Čeká na doplnění

£6m v 2012-13

25

1. KPI - klíčové ukazatele výkonnosti Zavedení KPI mělo dle University of Essex kladný vliv na efektivitu řízení a celkovou výkonnost univerzity. Dalším úspěšným příkladem je University of Iowa, která dlouhodobě sleduje a vyhodnocuje celou řadu KPI. Příkladem je vývoj dokončených doktorských studií

Obrázek 1.1: Vývoj dokončených doktorských studií v letech na Iowa State University (zdroj [17]) nebo vývoj podílu online vzdělávání

Obrázek 1.2: Vývoj podílu online vzdělávání v letech na Iowa State University (zdroj [17]) Při rešeršní práci se bohužel nepodařilo najít univerzitu používající taková KPI, které bychom mohli ve významné míře přepoužít pro účely této diplomové práce. 26

1.2. Analýza problému a nastínění řešení

1.2 1.2.1

Analýza problému a nastínění řešení Výkonnost

Příkladem z prostředí školy může být vypisování závěrečných prací, což reprezentuje činnost učitele, který je subjektem zkoumání. Aby bylo možné ohodnotit činnost z hlediska výkonnosti, je nutné ji uzavřít, ohraničit. Touto hranicí je v prostředí školy často akademický rok, který se dále štěpí na semestry, výukové týdny atd.. Kriteriální škálou tedy v tomto příkladu bude počet vypsaných prací za semestr. Referenčním způsobem průběhu může být například děkanem pevně stanovený počet vypsaných prací za semestr. Při tomto nastavení tedy můžeme porovnávat počet vypsaných prací za semestr jednotlivých učitelů s referenčním počtem a získávat tak informace o jejich výkonnosti.

1.2.2

Metriky a měření výkonnosti

Pokud tedy vezmeme činnost z předchozího příkladu, vypisování závěrečných prací, metrikou bude počet vypsaných závěrečných prací, což je porovnatelná hodnota, kterou lze měřit sledováním a zaznamenáváním činnosti. Při vztažení na předchozí příklad vypisování závěrečných prací bylo měřením výkonnosti jednoho učitele zjištěno, že vypsal pouze polovinu prací, než jaký je optimální případ a z toho pak usoudit, že má ještě volnou kapacitu (toho lze využít při nedostatečném počtu volných prací), nebo že nepracuje dle svého úvazku (a například mu přidat předmět na cvičení). Z předchozího příkladu je zřejmé, že provedené měření výkonnosti nemá dostatečnou vypovídající hodnotu, protože učitel může sice mít například pouze jednu volnou (vypsanou) práci, ale v současné době jich již pět vede. Popis komplexní výkonnosti subjektu se nazývá primární ukazatel výkonnosti a jeho nalezení je netriviální problém. Zavádí se tedy sekundární ukazatele výkonnosti, které se nesnaží popsat výkonnost subjektu jako celku, ale pouze určitou část. Lze jich nalézt mnoho a většinou se odvozují od primárních ukazatelů výkonnosti. Příkladem tedy může být výkon učitele jako primární ukazatel a počet vypsaných prací, počet cvičených předmětů jako sekundární ukazatele, které na primárním participují. I při rozpadu celku a zaměření se na určitou oblast lze nalézt primární a několik sekundárních ukazatelů výkonnosti. Aby bylo možné na jejich základě dělat objektivní rozhodnutí, zavádí se pojem klíčové ukazatele výkonnosti.

1.2.3

KPI

Jeho hodnota může mít několik podob (například hodnotami klíčového ukazatele výkonnosti studenta z hlediska přijímacího řízení na vysokou školu jsou přijat nebo nepřijat), nejčastěji je však vyčíslena s nějakou jednotkou (například body, hodiny). Pokud tedy máme subjekt učitele a činnosti vypisování závěrečných prací, klíčovými ukazateli mohou být počet volných prací, počet 27

1. KPI - klíčové ukazatele výkonnosti vedených prací, počet rezervovaných prací a počet oponentur. Tento klíčový ukazatel nám pak může říci, jak je učitel v dané oblasti vytížen a jakou má výkonnost.

1.2.4

Definice klíčových ukazatelů výkonnosti

Pro definici klíčových ukazatelů výkonnosti existuje několik postupů, nejpoužívanější a nejjednodušší vychází z definovaných procesů v dané oblasti. V procesu se identifikují činnosti (nejčastěji činnosti lidí, jelikož měřit výkonnost má smysl zejména u subjektů, které činnost mohou ovlivnit) a pro ně se pak tvoří KPI. Současně s procesem a činnostmi jsou důležité také metriky, které s KPI úzce souvisí. Pokud vyspecifikujeme činnost, pro kterou metriku nemáme (tzn. neumíme ji změřit a ohodnotit), nelze u takové činnosti specifikovat KPI. Příkladem vytváření KPI může být proces vypisování závěrečných prací (pro účel příkladu bude popsán ve zjednodušené formě) 1. vypsání práce učitelem 2. rezervace práce studentem 3. výběr oponenta 4. zadání práce studentovi a zpracování studentem 5. odevzdání práce a vypracování posudku Pokud se na činnosti podíváme z pohledu učitele, nachází se pro něj práce v několika stavech • vypsaná (volná) • rezervovaná • zadaná • odevzdaná přičemž ve stavu zadaná může být učitel jako vedoucí nebo jako oponent. Na vypisování závěrečných prací máme již také metriku, počet vypsaných prací, kterou pro tento příklad zobecníme na počet prací. Pokud se tedy podíváme na stavy prací a na případné stavy učitele (vedoucí, oponent) a aplikujeme metriku počet prací, dostáváme KPI • počet volných prací • počet rezervovaných prací • počet vedených prací 28

1.3. Vlastní řešení • počet oponentur které popisují oblast vypisování závěrečných prací u daného učitele.

1.2.5

Parametry a použití klíčových ukazatelů výkonnosti

Samotný popis KPI nestačí, aby bylo možné s ním pracovat, je nutné definovat sadu parametrů, které musí mít každé KPI. Pro ilustraci parametrů bude využit příklad KPI definovaným nad vypisováním závěrečných prací. Parametry jsou • činnost, oblast - pokud by nebyla definována činnost, mohlo by se KPI počet volných prací vztáhnout například k přijímání nových zaměstnanců, proto je důležité zahrnout činnost jako parametr KPI. • měrná jednotka - samotná hodnota nemá pro rozhodování dostatečnou informační hodnotu, musí se definovat i měrná jednotka. V případě KPI nad vypisováním závěrečných prací to budou kusy, pro jiná KPI to mohou být například hodiny, metry apod. • stakeholders - neboli vlastníci KPI, tedy pro koho je KPI určeno. Nejčastěji je to management, kterému informace získané aplikací KPI pomáhají při rozhodování. V případě KPI nad vypisováním závěrečných prací budou mezi stakeholders děkan a vedoucí katedry, kteří danou oblast řídí a zodpovídají za ni. Dalších parametrů může být celá řada, například detailní popis KPI, potřebná data a jejich zdroj, ale tři výše jmenované jsou povinné a nezbytné. Hlavní využití KPI se nachází v analýze problému. Umožní přehledně a strukturovaně popsat zájmovou množinu dat a oblastí a slouží tak k budoucímu návrhu reportů, které KPI realizují. Do návrhu reportů se také mohou přenést některé výše zmíněné parametry, například definice potřebných dat a jejich zdrojů, které by měly být v době návrhu reportů již známé.

1.3 1.3.1

Vlastní řešení Konstrukce klíčových ukazatelů výkonnosti v prostředí fakulty

Pro nový informační systém fakulty byly vybrané oblasti prostředí fakulty popsány pomocí business procesů (viz dokument [14]). V této sekci budou procesy stručně popsány, dekomponovány a ke každému procesu a jeho subprocesům budou navržena KPI, jejichž parametry budou pouze obecně popsány pro celý proces. Účelem je sumární pohled na vybrané oblasti fakulty z pohledu KPI, na který bude navazovat zevrubná definice KPI pro vybrané oblasti (nebo jejich podoblasti). 29

1. KPI - klíčové ukazatele výkonnosti Rozpad procesu je realizován jako více-úrovňový seznam (u každého procesu nebo subprocesu je v závorce číslo odpovídající sekci ve zdrojovém dokumentu [14]), KPI jsou (pro odlišení od procesů a subprocesů) tučně zvýrazněna a začínají zkratkou KPI. 1.3.1.1

Proces přijetí doktoranda

Tento proces se zabývá přijetím doktoranda ke studiu, což je administrativně nejnáročnější oblast z hlediska přijímacího řízení. Zdroje dat • systém PRIZ (přijímací řízení) • systém ZP (závěrečné práce) Stakeholders v tomto procesu jsou • oddělení pro vědeckou a výzkumnou činnost • děkan fakulty • školitel doktoranda • vedoucí katedry, pod kterou doktorand spadá • přijímací komise • doktorand Rozpad procesu přijetí doktoranda a navržená KPI • KPI celkový čas běhu procesu • přihlášení ke studiu (5.1) – KPI počet přihlášek – výběr disertační práce a školitele (5.1.1) ∗ KPI celkový čas běhu procesu ∗ KPI počet vypsaný prací ∗ KPI zastoupení jednotlivých oborů mezi přihláškami a vypsanými pracemi ∗ KPI počet doktorandů školitele ∗ KPI počet přímo oslovených studentů – podání přihlášky (5.1.2) ∗ KPI celkový čas běhu procesu ∗ KPI průměrný čas pro zpracování přihlášky 30

1.3. Vlastní řešení ∗ KPI podíl nesprávně podaných přihlášek • přijímací řízení (5.2) – KPI celkový čas běhu procesu – KPI počet vyřízených oznámení o nepřijetí – příprava přijímacího řízení (5.2.1) ∗ KPI celkový čas běhu procesu – vytvoření přijímací komise (5.2.1.1) ∗ KPI celkový čas běhu procesu ∗ KPI členové komise (seznam, četnost) – půběh přijímacího řízení (5.2.2) ∗ KPI celkový čas běhu procesu (na 1 studenta) – výsledky přijímacího řízení (5.2.3) ∗ KPI celkový čas běhu procesu (zhotovení výsledku a sdělení uchazeči) – přezkoumání rozhodnutí o přijetí (5.2.4) ∗ KPI celkový čas běhu procesu (pro 1 odvolání) ∗ KPI odvolání (celkový počet, úspěšnost, důvody) • zápis do studia (5.3) – příprava pracoviště doktoranda (5.3.1) ∗ KPI celkový čas běhu procesu (vyřízení potřeb 1 studenta) – zápis přijatých doktorandů ∗ KPI celkový čas běhu procesu (na 1 studenta) 1.3.1.2

Proces obhajoba disertační práce

Proces obhajoby disertační práce je (spolu se státními závěrečnými zkouškami) procesem řádného ukončení doktorského studia doktoranda. Zdroje dat • systém ZP (závěrečné práce), kde se nachází údaje o disertační práci doktoranda Stakeholders v tomto procesu jsou • oddělení pro vědeckou a výzkumnou činnost • děkan fakulty 31

1. KPI - klíčové ukazatele výkonnosti • školitel doktoranda • vedoucí katedry, pod kterou doktorand spadá • oborová rada programu • komise obhajoby disertační práce • doktorand Rozpad procesu obhajoba disertační práce a navržená KPI • přihláška k obhajobě dsp (6.1) • KPI celkový čas běhu procesu • kontrola dokumentů k obhajobě – KPI počet (ne)kompletně odevzdaných dokumentů k obhajobě • oponenti dsp (6.2) – KPI reakční doba oponenta dsp v případě odmítnutí jmenovaní – KPI vytížení oponentů – výběr oponentů dsp (6.3) ∗ KPI celkový čas běhu procesu (do odevzdání návrhu oponenta) ∗ KPI počet nevhodných návrhů oponentů – oponentský posudek dsp (6.3) ∗ KPI celkový čas běhu procesu (do odevzdání posudku) ∗ KPI počet nevhodných návrhů oponentů • komise pro obhajobu dsp (6.5) – KPI doba nutná na projednaní návrhu v oborové radě programu – KPI doba nutná pro získání návrhu na členy komise – KPI počet odmítnutých žádostí na členství v komisi • termíny obhajoby dsp • příprava obhajoby dsp • průběh a výsledky obhajoby dsp • opakování obhajoby dsp 32

1.3. Vlastní řešení 1.3.1.3

Proces vydávání skript

Proces vydávnání skript se zabývá publikační činností zaměstnanců fakulty (obecnou, nejenom vydáváním skript). Zdroje dat • VVVS - systém věda, výzkum a vnější vztahy Stakeholders v tomto procesu jsou • ediční referent fakulty • zaměstnanec, který chce publikovat svou práci • vedoucí katedry, pod kterou zaměstnanec spadá • děkan fakulty Rozpad procesu vydávání skript a navržená KPI • KPI celkový čas běhu procesu (od předání žádosti edičnímu referentovi do schválení vydání publikace) • příprava vydání nové publikace (7.1) – KPI počet podaných žádostí na katedru – KPI počet schválených (zamítnutých) žádostí – KPI výkon zaměstnanců (počet žádostí, podíl schválených) • předložení žádosti ediční radě (7.2) – KPI počet schválených (zamítnutých) publikací • sepsání autorské smlouvy (7.3) – KPI počet (znovu)uzavřených smluv 1.3.1.4

Proces public relations - vztahy s veřejností

Proces public relations - vztahy s veřejností (dále jen PR) se zabývá komunikací fakulty s veřejností a médii, vydáváním prohlášení, tiskovými konferencemi, reakcí na zveřejněné informace atd.. Zdroje dat • systém pro monitoring médií Stakeholders v tomto procesu jsou • tiskový mluvčí fakulty 33

1. KPI - klíčové ukazatele výkonnosti • děkan fakulty • zaměstnanec fakulty, který komunikuje nebo bude komunikovat s veřejností Rozpad procesu PR a navržená KPI • mediální prezentace (7.4) – KPI doba schválení informace k uveřejnění – KPI doba od přijetí požadavku na reakci (od médií) do prezentování reakce • reakce na informaci v médiích (7.5) – KPI doba od zjištění informace, na kterou je nutné reagovat, do zveřejnění reakce • svolání tiskové konference (7.6) – doba od zjištění potřeby tiskové konference do jejího svolání • vyhodnocení tiskové konference – KPI počet ohlasů na tiskovou konferenci – KPI počet kladných (záporných) ohlasů – KPI doba reakce na ohlasy 1.3.1.5

Proces správa lokálního hardware

Proces správa lokálního hardware (dále jen HW) se zabývá nákupem, reklamací a řešením poruch HW. Zdroje dat • sytém iFIS - evidence majetku Stakeholders v tomto procesu jsou • IT oddělení • oddělení nákupu • zaměstnanec fakulty Rozpad procesu správa lokálního HW a navržená KPI • nákup HW (8.1) – KPI doba od požadavku na nákup po fyzické získání HW 34

1.3. Vlastní řešení • reklamace HW (8.2) – KPI doba vyřízení reklamace – KPI počet reklamací (úspěšných, neúspěšných, celkem) • řešení poruch HW (8.3) – KPI doba od nahlášení poruchy do odstranění 1.3.1.6

Proces správa lokálního software

Proces správa lokálního software (dále jen SW) se zabývá nákupem, instalací, správou a řešením poruch SW. Zdroje dat • v současné době neexistuje systém pro správu SW, který by potřebná data sbíral Stakeholders v tomto procesu jsou • IT oddělení • oddělení nákupu • zaměstnanec fakulty Rozpad procesu správa lokálního HW a navržená KPI • KPI doba od nahlášení poruchy do odstranění • nákup SW – KPI doba od požadavku na nákup po získání SW k instalaci • instalace SW – KPI doba od požadavku na instalaci do dokončení instalace 1.3.1.7

Procesy personalistiky

Procesy personalistiky se zabývají přijímáním nových zaměstnanců, změnami úvazků, mzdy, ukončováním pracovního poměru, dovolenými a neschopenkami. Zdroje dat • mzdový systém Eleanor Global • KOS 35

1. KPI - klíčové ukazatele výkonnosti Stakeholders v tomto procesu jsou • personální oddělení • děkan fakulty • vedoucí katedry • zaměstnanec fakulty Rozpad procesů personalistiky a navržená KPI • KPI doba od podání žádosti o přijetí do přijetí nového pracovníka • KPI počet žádostí o přijetí • KPI poptávka (nabídka) jednotlivých pozic • dovolené (11.1) – KPI délka dovolené – KPI rozložení dovolených v roce • neschopenky (11.2) – KPI průměrná doba neschopnosti – KPI délka a četnost neschopnosti (pro jednotlivé zaměstnance) • postregistrační procesy (11.3) – KPI celkový čas běhu procesu • příprava dokumentů a jejich popis (11.4) – KPI doba od sepsání pracovní smlouvy do podepsání děkanem – KPI doba trvání do přidělení jednacího čísla – KPI počet vrácených připomínkovaných smluv – KPI počet „otáček“ před podepsáním připomínkované smlouvy • příprava podkladů (11.5) – KPI doba od předání požadavku na odevzdání dokumentu zaměstnanci do jejich odevzdání na personální oddělení – KPI počet zaměstnanců s nekompletní dokumentací 36

1.3. Vlastní řešení • ukončení pracovního poměru (11.6) – KPI počet odcházejících zaměstnanců za období • vyplnění osobních údajů (11.7) – KPI doba od požadavku na vyplnění osobních údajů do jejich vyplnění – KPI počet zaměstnanců s nekompletními osobními údaji • zadání do HR systému (11.8) – KPI doba nutná pro zadání osobních údajů zaměstnance do systému • změna osobních údajů (11.9) – KPI doba od požadavku na aktualizaci osobních údajů do jejich aktualizace • změna úvazku/mzdy (11.10) – KPI doba od požadavku na změnu údajů do jejich změny 1.3.1.8

Proces zahraniční cesty

Proces zahraniční cesty se zabývá celým životním cyklem zahraniční cesty zaměstnance fakulty, od schválení po konečné vyúčtování. Zdroje dat • VVVS - systém věda, výzkum a vnější vztahy Stakeholders v tomto procesu jsou • zaměstnanec fakulty, který má záměr podniknout zahraniční cestu • referent zahraničních cest • správce rozpočtu • statutární zástupce • účtárna • vedoucí katedry, pod kterou zaměstnanec spadá Rozpad procesu zahraniční cesty a navržená KPI • KPI doba od podání žádosti na zahraniční cestu do schválení 37

1. KPI - klíčové ukazatele výkonnosti • KPI počet realizovaných zahraničních cest (na zaměstnance a celkem) • podpisy - schválení cesty (12.1) – KPI počet přepracování žádosti před schválením • podpisy - schválení vyúčtování (12.2) – KPI doba od podání žádosti na vyúčtování do schválení – KPI počet schválených (zamítnutých) žádostí o vyúčtování – KPI počet přepracování vyúčtování před schválením • příprava na cestu (12.3) – KPI doba pro získání potřebných informací pro žádost o cestu do zahraničí • sepsání zprávy ze zahraniční cesty (12.4) – KPI doba od ukončení zahraniční cesty do předání zprávy referentovi zahraničních cest • úhrady do zahraničí (12.5) – KPI doba od požadavku na úhradu do zahraničí do přijetí platby • výplata záloh (12.6) – KPI objem vyplacených záloh – KPI podíl záloh na konečném vyúčtování zahraniční cesty • vyplnění návrhu žádosti (12.7) – KPI doba od zadání informací do systému do předání dokumentu cestovateli – KPI počet žádostí vrácených k doplnění – KPI počet přepracování žádosti před schválením • vyrovnání se s cestovalem (12.8) – KPI doba od schválení vyúčtování do vyrovnání se s cestovalem – KPI počet nedoplatků (přeplatků) • vyúčtování po příjezdu (12.9) – KPI doba od příjezdu cestovale do schválení vyúčtování • žádost o zálohy (12.10) 38

1.3. Vlastní řešení 1.3.1.9

Procesy mobilita studentů a kantorů

Procesy mobilita studentů a kantorů se zabývají problematikou studijních pobytů (například program Erasmus), výjezdem vlastních a hostováním zahraničních pedagogů. Zdroje dat • informační systém Erasmus • VVVS - systém věda, výzkum a vnější vztahy Stakeholders v tomto procesu jsou • kvestor univerzity • proděkan pro studijní a pedagogickou činnost • proděkan pro vědu a výzkum • proděkan pro vnější vztahy • proděkan pro studium • vedoucí katedry, pod kterou vyjíždějící zaměstnanec spadá • zaměstnanec fakulty • studijní oddělení • student fakulty • hostující učitel Rozpad procesů mobilita studentů a kantorů a navržná KPI • KPI počet vyjíždějících studentů • KPI počet přijíždějících studentů • KPI úspěšnost vyjíždějících studentů • KPI délka pobytu zahraničního studenta na FIT • KPI počet výjezdů učitelů (na učitele, celkem) • pobyt a uzavření výjezdu studenta FIT (13.1) – KPI prospěch studentů na zahraničních univerzitách • pobyt hostujícího studenta (13.2) – KPI prospěch hostujících studentů 39

1. KPI - klíčové ukazatele výkonnosti • příjezd hostujícího učitele (13.3) – KPI počet hostujících učitelů – KPI doba strávená na FIT • příprava příjezdu hostujícího studenta (13.4) – KPI počet žadatelů – KPI počet přijatých studentů • příprava výjezdu studenta (13.5) – KPI počet žadatelů – KPI počet vyjíždějících studentů • sestavení bilaterální dohody (13.6) – KPI úspěšnost sestavení nové bilaterální dohody • výjezd učitele (13.7) – KPI počet vyjíždějících učitelů – KPI doba strávená na zahraniční univerzitě 1.3.1.10

Proces správa webu

Proces správa webu se zabývá správou, aktualizací a řešením poruch webové prezentace fakulty. Zdroje dat • webové stránky fakulty Stakeholders v tomto procesu jsou • tiskový mluvčí fakulty • redaktor fakultního webu • děkan fakulty • webmaster fakultního webu • IT oddělení • zaměstnanec fakulty Rozpad procesu správa webu a navržená KPI • aktualizace informací 40

1.3. Vlastní řešení – KPI doba od přijetí požadavku na aktualizaci do aktualizace • řešení poruch – KPI doba od zjištění poruchy do odstranění • zveřejnění aktuality – KPI doba od přijetí požadavku na zveřejnění aktuality do zveřejnění 1.3.1.11

Proces nákupy

Proces nákupy se zabývá celým životním cyklem nákupu majetku, od vytvoření požadavku po zaplacení. Zdroje dat • FIS - fakultní informační systém a nově vznikající komponenta pro řešení problematiky nákupů Stakeholders v tomto procesu jsou • správce rozpočtu • účtárna • děkan fakulty • vedoucí katedry • zaměstnanec fakulty Rozpad procesu nákupy a navržená KPI • KPI doba realizace objednávky • KPI doba od zjištění nízkého stavu hotovosti na pokladně do doplnění • KPI průměrná doba proplacení nákupu v hotovosti • vytvoření požadavku na objednávku (15.1) – KPI doba trvání schválení formuláře „požadavek“ • vytvoření objednávky (15.2) – KPI počet realizovaných objednávek – KPI doba od schválení formuláře „požadavek“ do podpisu objednávky 41

1. KPI - klíčové ukazatele výkonnosti • odeslání a zpracování objednávky (15.3) – KPI počet realizovaných objednávek • likvidace faktury za objednávku (15.4) – KPI doba od přijetí faktury do potvrzení formuláře „likvidační list k faktuře“ • platba na účet (15.5) – KPI doba potřebná pro realizaci převodu • finanční vyrovnání na základě vyúčtování (15.6) – KPI doba od předání vyúčtování do účtárny do uzavření vyúčtování a vyrovnání nedoplatku (přeplatku) • platba řádné zálohy (15.7) – KPI doba od předání žádosti do účtárny do vyplacení zálohy žadateli • ukončení řádné zálohy (15.8) – KPI doba od předání příkazu k ukončení řádné zálohy do informování zaměstnance o ukončení vyplácení zálohy • platba mimořádné zálohy (15.9) – KPI počet vyplacených mimořádných záloh – KPI objem vyplacených mimořádných záloh • proplacení nákupu v hotovosti (15.10) – KPI doba trvání proplacení nákupu v hotovosti – KPI objem nákupů v hotovosti • vystavení likvidačního listu k závazku k zaměstnanci (15.11) – KPI počet vyplněných a zpracovaných formulářů „vyúčtování zálohy“ • podpisy likvidačního listu k závazku k zaměstnanci a vyplacení peněz (15.12) – KPI doba od získání formuláře „likvidační listu k závazku k zaměstnanci“ do jeho proplacení pokladnou 42

1.3. Vlastní řešení

1.3.2

Návrh KPI pro vybrané oblasti

Pro detailní popis bylo vybráno několik oblastí, pro které byly vytvořeny KPI, jež budou postupně v práci dále rozpracovány. 1.3.2.1

Doktorské studium - školitelé

Oblast doktorské studium - školitelé se týká problematiky školitelů a jejich výkonnosti. Pro školitele je možné definovat dvě hlavní činnosti • vypsání disertační práce • vedení doktoranda, přičemž doktorand může být v několika stavech (i) před odevzdáním minima, (ii) před SSZ (oba tyto stavy lze popsat jako doktorand ve standardní době studia) a (iii) čekajících na obhajobu disertační práce Metrikou v tomto případě bude počet vypsaných disertačních prací za semestr a počet vedených doktorandů v daném semestru, a to pro každý stav zvlášť a celkově. Dalším důležitým hodnotícím kritériem pro daného školitele je počet úspěšných doktorandů celkem. Klíčové ukazatele výkonnosti pro práci školitele tedy jsou • počet vypsaných disertačních prací za semestr • počet doktorandů ve standardní době studia v daném semestru • počet doktorandů čekajících na obhajobu disertační práce v daném semestru • počet úspěšných doktorandů celkem Aby bylo možné KPI realizovat, je nutné získat data o disertačních pracech a studiu doktorandů, zdroji dat tedy jsou • KOS pro informace o studiu doktorandů • ZP - závěrečné práce pro informace o disertačních pracech Stakeholder KPI je děkan, proděkan pro studium, případně vedoucí katedry, pod kterou školitel spadá. 1.3.2.2

Přijímací řízení - přihlášky

Oblast přijímacího řízení je široká a celou ji popsat by bylo velice náročné a díky možným změnám i nekonzistentní. Je tedy nutné oblast rozpadnout na jednotlivé podoblasti a ty popisovat odděleně. Pro tvorbu KPI byla vybrána podoblast přihlášky, konkrétně v pohledu na studenta, který se postupně přihlašuje a zapisuje k jednotlivým krokům přijímacího řízení, od samotného podání přihlášky po zápis do studia. Činnostmi tedy jsou 43

1. KPI - klíčové ukazatele výkonnosti • podání přihlášky ke studiu, přičemž studium může být prezenční nebo kombinované a obojí v bakalářském nebo magisterském programu • zápis k přijímací zkoušce • přijetí bez přijímacího řízení, a to na základě SCIO testu, státní maturity nebo olympiády • přijetí na základě výsledku přijímacího řízení • registrace k zápisu do studia • zápis do studia Zdrojem dat o průběhu přijímacího řízení je systém PRIZ, který vzniká pro nový fakultní informační systém. Metrikou přes všechna KPI je zde počet studentů. KPI jsou • počet studentů přihlášených ke studiu – bakalářský program prezenční – bakalářský program kombinovaný – bakalářský program celkem – magisterský program prezenční – magisterský program kombinovaný – magisterský program celkem • počet studentů přihlášených k přijímací zkoušce • počet studentů přijatých bez přijímací zkoušky – na základě SCIO testu – na základě státní maturity – na základě olympiády – celkem • počet studentů přijatých na základě výsledku přijímací zkoušky • počet studentů registrovaných k zápisu • počet zapsaných studentů Všechny KPI se vztahují k jednomu přijímacímu řízení, tedy k jednomu akademickému roku. Stakeholder KPI je děkan a proděkan pro studijní a pedagogickou činnost. 44

1.3. Vlastní řešení 1.3.2.3

Závěrečné práce - vedoucí

Oblast závěrečných prací - vedoucí pokrývá problematiku vypisování a zadávání závěrečných prací. Je důležitá zejména ve fázi zadávání, kde se často hledají volné kapacity. Činnostmi z pohledu vedoucího tedy jsou • vypsání závěrečné práce • vedení závěrečné práce • oponentura k závěrečné práci Metrikou je počet závěrečných prací, přičemž jsou brány v potaz i jednotlivé stavy z životního cyklu práce. KPI pro vedoucího pak jsou • počet vypsaných (volných) závěrečných prací • počet rezervovaných závěrečných prací • počet zadaných závěrečných prací • počet oponovaných závěrečných prací KPI se vztahují k určitému období, nejčastěji akademickému roku. Stakeholder KPI je děkan a vedoucí katedry. 1.3.2.4

Hodnocení pedagogických výkonů

Hodnocení pedagogických výkonů, tedy hodnocení učitele, je nejrozsáhlejší zde popisovanou oblastí. Pokouší se najít primární ukazetel výkonnosti, kterým by bylo možné celkový výkon učitele popsat a hodnotit. Činnosti učitele pokrývají prakticky všechny výše zmíněné oblasti, například • školení doktorandů • vypisování a vedení závěrečných prací • výuka (přednášení a cvičení) • účast v komisi Každá z těchto činností je jinak náročná, vyžaduje odlišné předpoklady a nelze je tedy jednoduše porovnávat, například počtem hodin, kterou učitel danou činností strávil. Na základě zkušeností a výzkumu Vysokého učení technického v Brně byla přijata metrika započítatelná hodina (dále jen ZH), na kterou se pomocí funkce s danými parametry převádí čas strávený nějakou činností. Parametry byly dohodnuty na schůzích grémia ČVUT FIT. Aby bylo možné porovnávat učitele s různě velkými úvazky, počítá se normovaná započítatelná hodina (dále jen NZH), kde se počet ZH podělí velikostí úvazku normovaného v rozmezí (0, 1 >. 45

1. KPI - klíčové ukazatele výkonnosti Vzniká tak KPI počet ZH a KPI počet NZH, které je v případě potřeby možné aplikovat na jednotlivé činnosti učitele, nebo na všechny jeho činnosti jako celek. Zdrojem dat jsou všechny systémy, které sbírají údaje o činnosti učitele (nejkoplexněji tuto oblast pokrývá systém Úvazky) a stakeholderem KPI je management fakulty a jednotlivých kateder.

46

KAPITOLA

2

BI reporty nad fakultním datovým skladem Tato kapitola se zabývá samotným problémem datového skladu a dotazování se nad ním. V první části jsou definovány základní pojmy a popsány použité technologie, druhá část pokrývá návrh reportů pro KPI z první kapitoly a v poslední části je popsána vzorová implementace jednoho z reportů.

2.1

Problematika datových skladů

Problematika datových skladů, vytváření reportů a obecně BI (business intelligence) jako podpory rozhodování se točí kolem několika základních pojmů, které je nutné pro pochopení oblasti definovat. Datový sklad - Datový sklad je podnikově strukturovaný depozitář subjektově orientovaných, integrovaných, časově proměnlivých, historických dat použitých na získávání informací a podporu rozhodování. V datovém skladu jsou uložena atomická a sumární data. [8] OLAP - OnLine Analytical Processing je způsob, jak nad daty rychle provádět vícedimenzionální analytické dotazy.[6] Je součástí rozšířené kategorie business intelligence, která zahrnuje relační reporting a data mining.[12] BI - Business Intelligence je schopnost chápat vzájemné vztahy prezentovaných skutečností způsobem, který umožní vytvářet rozhodnutí vedoucí k požadovanému cíli.[10] Datová (OLAP) kostka - Datová kostka je soubor dat organizovaný způsobem, který usnadňuje předem neurčené dotazy pro získání agregovaných informací.[7] 47

2. BI reporty nad fakultním datovým skladem Report - Report je souhrnem informací agregovaných z různých zdrojů dat a různých pohledů na doménu problému zobrazeným snadně čitelnou a pochopitelnou formou. MDX - MultiDimensional eXpressions je dotazovací jazyk pro OLAP datové sklady, podobně jako SQL pro relační databáze. Poskytuje speciální syntaxi pro manipulaci a dotazování se nad daty strukturovanými do vícedimenzionálních OLAP kostek.[11]

2.1.1

Motivace pro využití datového skladu

Tradičně jsou data nějakého systému uložena v jeho operační databázi, která umožňuje data rychle modifikovat, přidávat, mazat, a to pro velké množství přihlášených uživatelů (operační databáze nejčastěji využívá technologii OLTP2 a v dnešní době nejčastěji RDBMS3 ). Dat je velké množství, neustále se mění, a jsou uložena způsobem odpovídajícím danému systému. Aby bylo možné těmto nárokům vyhovět, je jim operační databáze co nejvíce přizpůsobena. Pokud ale začneme požadovat komplexní pohled na data z více systémů, navíc s určitou historií, narazíme na omezení • nejsou uchovány historické údaje - operační databáze pracuje kontinuálně s jednou množinou dat • nehomogení struktura údajů napříč různými zdroji dat - každá aplikace zpracovává data různým způsobem a uchovává je ve specifickém formátu, který se může napříč aplikacemi lišit • netriviální agregace dat a vytěžování zdrojů operačních databází - operační databáze uchovává data v atomické podobě, aby s nimi mohla daná část aplikace rychle a snadno pracovat. Pokud tedy potřebujeme sumární údaje, je třeba provést velké množství operací nad velkým množstvím dat, což neúměrně čerpá zdroje systému, který pro tento účel ani nebyl určen. Uvědomit si navíc veškeré závislosti mezi daty, aby výsledná agregace měla vypovídající hodnotu, je u větších databázích a složitějších dotazech netriviální problém. Díky těmto problémům a omezením vzniká potřeba někde uchovávat historická data v jednotné formě z více systémů a pomocí struktury dat a vhodné technologie umožnit provádění netriviálních dotazů. K tomuto účelu slouží datový sklad. 2 3

48

Online Transaction Processing Relational Database Management systém, tedy relační systém řízení báze dat

2.1. Problematika datových skladů 2.1.1.1

Datový sklad, data a informace

Datový sklad je vlastně archivem, kde se ukládají důležitá data integrovaná z různých systémů, například z jejich operačních databází. Data musí být sesynchronizována (tak, aby konkrétní položka byla v datovém skladou pouze jednou), vyčištěna a protříděna (aby se do datového skladu dostala pouze důležitá data ve správném formátu) a uspořádána do vhodné struktury tak, aby bylo podpořena zamýšlená funkce datového skladu. Z hlediska přenášení dat do datového skladu je důležité rozlišovat mezi pojmem data a informace. Podle jedné z definic se data stávají informacemi, pokud [5] 1. máme data 2. víme, že máme data 3. víme, kde data máme 4. máme k datům přístup 5. zdroji dat můžeme důvěřovat Transformací dat do datového skladu tedy vytváříme informace, jak je znázorněno na obrázku (2.1). Dalším stupněm je pak vytváření znalostí pomocí informací, kdy informace používáme v praxi pro rozhodování, predikci apod..

Obrázek 2.1: Hierarchie data, informace, znalosti

49

2. BI reporty nad fakultním datovým skladem 2.1.1.2

Technologie pro datový sklad

Technologií a řešení datových skladů existuje na trhu celá řada, prakticky každý výrobce operačních databází nabízí i datový sklad (Oracle, IBM, HP). Pro realizaci datového skladu fakulty bylo rozhodnuto využít open-source produkt Mondrian od společnosti Pentaho, který bude nasazen na aplikačním serveru Apache Tomcat. Zevrubným popisem datových skladů, popisem dostupných řešení, důvody pro výběr konkrétní technologie a popisem získávání a nahrávání dat se blíže zabývá práce Stanislava Kuznětsova (viz [9]).

2.1.2 2.1.2.1

Struktura dat v datovém skladu, OLAP operace a reporty Struktura dat v datovém skladu

Tradiční struktura operační databáze se pro uchovávání dat v datovém skladu nehodí, potřebujeme jasně odlišit jednotlivé časové verze, které byly do skladu nahrány a podle účelu skladu potřebujeme rozlišovat i další vlastnosti. Těmto rozměrům se říká dimenze, přičemž se prakticky vždy vyskytuje dimenze časová. Každá dimenze může mít navíc více hierarchicky řazených úrovní, v případě časové dimenze například úrovně roky, kvartály, měsíce a dny (členění často odpovídá obecně zažitým konvencím). V těchto dimenzích pak shromažďujeme data, která jsou důležitá a kvůli kterým jsme datový sklad vytvářeli. Těmto datům se říká fakta (občas jsou také označována jako míry), nejčastěji mají číselnou, nebo jinou snadno měřitelnou jednotku a získávají se agregacemi a výpočty z dat operačních databází. Data se pak strukturují do vícedimenzionálních kostek, kde je každá osa jednou dimenzí a průnik dimenzí faktem, přičemž kostka není omezena na 3 dimenze. Samotné fyzické uložení dat se liší v závislosti na použitém produktu a technologii, nejčastějšími dvěma typy jsou MOLAP4 a ROLAP 5 datové sklady. MOLAP fyzicky uchovává data ve vícedimenzionálních kostkách, ROLAP pak používá relační databázi, kde data strukturuje do tzv. hvězdicového schématu, v jehož středu se nachází tabulka faktů, která je pomocí cizích klíčů spojena s tabulkami dimenzí kolem ní (o fyzické struktuře dat a návrhu relační databáze pro datový sklad pojednává ve své práci Stanislav Kuznětsov (viz [9]). Soubor těchto kostek pak tvoří datový sklad. Příkladem takového uspořádání může být datový sklad pro síť obchodů se smíšeným zbožím. Vedení společnosti se rozhodlo, že bude, mimo jiné, uchovávat data o počtu prodaných produktů, a to pro každý produkt, každou pobočku a každý den. Dimenzemi v tomto případě tedy budou čas, pobočka a produkt, faktem pak počet prodaných produktů. Datová kostka je znázorněna na obrázku 2.2. V jednotlivých kostkách pak jsou konkrétní fakta o prodeji daného produktu na dané pobočce v daném čase. 4 5

50

multidimensional OLAP relational OLAP

2.1. Problematika datových skladů

Obrázek 2.2: Datová (OLAP) kostka pro sledování počtu prodaných produktů na pobočkách v čase.

2.1.2.2

OLAP operace a reporty

Zajímavou informací jsou i jednotlivá fakta, ale z analytického hlediska jsou mnohem hodnotnější různé agregace faktů z různých pohledů (na základě různých dimenzí). Aby to bylo možné, je definována množina operací, které lze nad datovou kostkou provádět řez kostkou (slice) - řez kostkou se provádí podle dimenze. Z dimenze se pak vybere jedna hodnota, pro kterou se řez provede. Na obrázku 2.3 je znázorněn řez podle dimenze času. Počet dimenzí výsledné kostky je zmenšen o jedna a kostka tedy obsahuje fakta pouze za jednu hodnotu dimenze času (například za jeden rok).

Obrázek 2.3: Řez datovou kostkou časovou dimenzí, tmavší kostka je výsledkem řezu.

51

2. BI reporty nad fakultním datovým skladem kostkování (dice) - kostkování je podobné operaci řezu, ale provádí se na dvou a více dimenzích. Na obrázku 2.4 je znázorněno kostkování podle dimenzí času a pobočky. Výsledná kostka může mít stejný počet dimenzí jako kostka výchozí, ale dimenze jsou zmenšené o ořezané hodnoty.

Obrázek 2.4: Kostkování datové kostky podle dimenzí času a pobočky, tmavší kostka je výsledkem řezu.

otáčení (pivot) - některé nástroje BI umožňují zobrazení tzv. pivot table, neboli zobrazení “předku” datové kostky (na obrázku 2.5 je znázorněn čtverci s čísly). Pokud potřebujeme jinou perspektivu dat, musíme kostku otočit (analogií může být otáčení složené rubikovi kostky, kdy při rozdílném natočení vidíme rozdílné barvy). Na obrázku je znázorněno otočení kostky podle dimenze produktu, takže v pivot table vidíme místo počtu prodaných produktů na pobočkách počty prodaných produktů v čase.

Obrázek 2.5: Otáčení datové kostky podle dimenze produktu, prohozené hodnoty jsou čas a pobočka.

52

2.1. Problematika datových skladů zavrtávání (drill-down) a vyvrtávání (drill-up) - zavrtávání a vyvrtávání je operací nad konkrétní hodnotou ve vybrané dimenzi (při zavrtávání) nebo nad celou dimenzí (při vyvrtávání) kostky. Jedná se vlastně o pohyb v hierarchii dané dimenze, kdy při zavrtávání zkoumáme nižší úroveň dané hodnoty (na obrázku 2.6 je znázorněno zavrtání v dimenzi času a hodnotě 2011 - postupujeme tedy na nižší úroveň roku 2011, v tomto případě na kvartály). Vyvrtávání je opačnou operací k zavrtávání, pokud bychom tedy provedli vyvrtání z kostky zobrazující kvartály, dostali bychom se na kostku zobrazující jednotlivé roky.

Obrázek 2.6: Zavrtávání datové kostky v dimenzi času, konkrétně v roce 2011. Spodní kostka je výsledkem operace.

agregace (roll-up, aggregate, consolidate) - operace agregace počítá sumy přes členy jedné a více dimenzí. Při předpokladech definovaných na obrázku 2.6 by byl počet produktů prodaných na pobočkách v jednom roce agregací počtu prodaných produktů za jednotlivé kvartály. Agregace často bývá netriviální a je třeba ji zvlášť popsat funkcí. Pomocí těchto operací nad datovými kostkami můžeme zobrazovat informace, provádět analýzy, vytvářet reporty. Na základě toho pak usuzujeme závěry, 53

2. BI reporty nad fakultním datovým skladem provádíme rozhodnutí a predikce, tedy použitím v praxi převádíme informace na znalosti (viz obrázek 2.1).

2.1.3

MDX

Pro samotnou realizaci dotazu nad danou datovou kostkou slouží jazyk MDX, ne nepodobný dotazovacímu jazyku SQL pro relační databáze. Výsledkem MDX dotazu je dvoudimenzionální tabulka. Základním a nejdůležitějším příkazem jazyka MDX pro dotazování se nad vícedimenzionální datovou kostkou je příkaz |SELECT|. Syntaxe SELECT {[míra]} ON COLUMNS {[dimenze]} ON ROWS FROM Kostka WHERE (podmínka) Míra specifikuje daný fakt, který chceme zobrazit, dimenze hledisko, ve kterém chceme fakt zobrazit, kostka referencuje datovou kostku a podmínka omezuje výstup. Konkrétním příkladem může být dotaz nad datovou kostkou z předchozí sekce (viz obrázek 2.2), kde mírou je počet prodaných produktů a dimenzemi čas, pobočka a produkt. Dotaz je postaven nad fiktivní datovou kostkou, ale dodržují se jmené konvence pro tvorbu datových kostek (míry jsou uvozeny objektem [Measures], dimenze a jejich úrovně jsou popsány anglickými názvy). SELECT {[Measures].[pocet_produktu]} ON COLUMNS {[Time].[2011]} FROM Kostka_prodej_produktu WHERE ([Branch].[city].[Brno]) Výsledkem takového dotazu je tabulka 2.1 s jedním řádkem a jedním sloupcem. Tabulka 2.1: Výsledek MDX dotazu. 2011

pocet_produktu 13

V tabulce je zobrazen celkový počet prodaných produktů za rok 2011 na pobočce v Brně (případně pobočkách, pokud jich má Brno více). Detailnější popis a vysvětlení jazyku MDX je nad rámec této práce, více informací lze nalézt například v referenční příručce společnosti Microsoft, viz [2].

2.2

Analýza a návrh řešení BI reportů

Zásadním problémem datového skladu fakulty je velké množství systémů a obrovské množství různorodých dat. To znesnadňuje nejenom nahrávání dat 54

2.2. Analýza a návrh řešení BI reportů do datového skladu, ale i orientaci v dostupných informacích. To zase vede k obtížné analýze a realizaci požadavků, které mohou na fakultě vůči datovému skladu vznikat. Vzniká tedy požadavek na obecný a snadno čitelný popis domény datového skladu, který by šel dále rozvíjet a usnadňoval by činnosti s datovým skladem spojené. Pro tento účel byl navržen doménový model reprezentovaný diagramem podle notace UML class diagram.

2.2.1

Doménový model

Doménový model je obecným, na platformě nezávislým modelem dané domény. Popisuje soubor klíčových entit, které se v doméně vyskytují, jejich atributů a vazeb mezi nimi. Slouží především pro orientaci, kdy může typově popisovat datové složení skladu, ze kterého se pak může odvozovat například dostupnost dat pro navržené reporty. Kromě možného užití při návrhu výstupů datového skladu slouží model i pro popis potřebné datové množiny pro vstup, tedy plnění skladu. Díky navrženým entitám, jejijich atributům a vazbám mezi nimi se dá specifikovat množina potřebných údajů, které se musí vyextrahovat ze zdrojového systému. Typ atributů pak určuje výsledný formát dat. Pro popis doménového modelu byl zvolen diagram tříd jazyku UML, viz obrázek 2.7. Entity a jejich atributy vycházejí ze struktury školy, fakulty a dat jednotlivých systémů. Pro jednodušší práci bylo zavedeno několik konceptů specifických pro doménu datového skladu • CB_Nazev je číselník, kde je klíčem kód vytvořený podle konvencí fakulty a hodnotou skutečný název (viz obrázek 2.8). Číselníky jsou použity proto, aby referenční datové sady, které se často mění a rozšiřují, nebyly “zadrátovány” do řešení čímž by byla výrazně degradována flexibilita řešení. • Atribut nebo entita se stereotypem «fact» je specifická pouze pro doménu datového skladu. Je to vlastně míra (viz sekce 2.1.2.1), která se v datovém skladu počítá a uchovává. • Entita se stereotypem «technical» je specifická pouze pro doménu datového skladu a reportů a portletů s ním spojených. Slouží především pro dokumentaci. V tuto chvíli jsou číselníky pouze v doméně datového skladu, pokud však dojde k nasazení celofakulního (celoškolského) řešení číselníků, může být současná implementace, společně s úpravou dat ve skladu, nahrazena.

55

2. BI reporty nad fakultním datovým skladem

Obrázek 2.7: Doménový model datového skladu (notace UML class diagram).

56

2.2. Analýza a návrh řešení BI reportů

Obrázek 2.8: Návrh číselníků (notace UML class diagram).

2.2.2

Navržené reporty

Návrh reportů reflektuje navržená KPI v kapitole 1 (viz sekce 1.3.2). Výsledný report je pak realizací KPI, umožňuje jeho sledování a vyhodnocování na datech v datovém skladu. Návrh reportů je koncipován jako popis datové závislosti, znázorněný výsekem doménového modelu, a popis datové kostky, jejích dimenzí a faktů. Na základě takto navržených parametrů se datový sklad bude vytvářet a plnit (dimenze a faktové tabulky). Pro přehlednost budou základní věci (jako obecná třída osoba reprezentující jakoukoliv osobu a shromažďující její základní informace - jméno, příjmení, adresy) vynechány, ale vztahu se prakticky vždy účastní. 2.2.2.1

Doktorské studium - školitelé

Report realizuje KPI navržené v první kapitole, viz 1.3.2.1. Z pohledu dat vyžaduje údaje o jednotlivých učitelích, kteří školí doktorandy a vypisují závěrečné práce a studentech, kteří prochází jednotlivými stádii studia (viz obrázek 2.9). Datová kostka bude mít následující dimenze (úrovně) • čas (akademický rok, semestr) • učitel (obor, učitel) • stav doktoranda - stav doktoranda může být nulový, pokud není daná disertační práce přiřazena doktorandovi • stav disertační práce Obor hodnot dimenze stavu doktoranda a stavu disertační práce je reprezentován číselníky, viz obrázek 2.10. 57

2. BI reporty nad fakultním datovým skladem

Obrázek 2.9: Model reportu doktorské studium - školitelé (notace UML class diagram).

Obrázek 2.10: Číselníky dimenzí datové kostky reportu doktorské studium školitelé (notace UML class diagram).

Ve faktové tabulce pak bude počet doktorandů pro jednotlivé dimenze. 2.2.2.2

Přijímací řízení - přihlášky

Report realizuje KPI navržené v první kapitole, viz 1.3.2.2. Potřebnými daty jsou data o příhláškách pro jednotlivé obory a případně jednotlivé typy (přih58

2.2. Analýza a návrh řešení BI reportů láška ke studiu, přihláška k zápisu apod.), viz obrázek 2.11. Datová kostka bude mít následující dimenze (úrovně) • čas (akademický rok, semestr) • typ přihlášky • obor

Obrázek 2.11: Model reportu přijímací řízení - přihlášky (notace UML class diagram). Obor hodnot typů přihlášek a oborů je definován číselníky. Mírou ve faktové tabulce bude počet studentů. 2.2.2.3

Závěrečné práce - vedoucí a přehledový report

Report realizuje KPI navržené v první kapitole, viz 1.3.2.3. Data potřebná pro realizaci se týkají učitele a jeho vypsaných závěrečných prací, viz obrázek 2.12. Datová kostka bude mít následující dimenze (úrovně) • čas (akademický rok, semestr) • typ práce • stav práce • obor práce • učitel • obor učitele 59

2. BI reporty nad fakultním datovým skladem

Obrázek 2.12: Model reportu závěrečné práce - vedoucí (notace UML class diagram).

Obory hodnot dimenzí typ práce, stav práce a obor jsou dány odpovídajícími číselníky. Mírou ve faktové tabulce v tomto případě bude počet prací. Kromě specifického reportu pro vedoucí závěrečných prací bude existovat ještě report zobrazující sumář všech prací pro daný obor a mimo jiné bude poskytovat i současné počty studentů v jednotlivých oborech. Datově pak tento report potřebuje informace o studentech, závěrečných pracech a oborech, viz obrázek 2.13. Aby bylo možné takový report realizovat, je nutné použít dvě datové kostky. První datová kostka týkající se počtu prací bude mít následující dimenze (úrovně) • čas (akademický rok, semestr) • typ práce • stav práce • obor práce Obory hodnot stavu a oboru práce jsou v odpovídajících číselnících. V tabulce faktů bude míra počet prací. Druhá kostka se bude týkat počtu studentů v jednotlivém oboru, dimenzemi jsou • čas (akademický rok, semestr) • obor Mírou v tabulce faktů bude počet studentů. Aby byla data výsledného reportu konzistentní, dimenze času se při každém „dvojdotazu“ budou rovnat. 60

2.3. Implementace

Obrázek 2.13: Model reportu přehled závěrečných prácí (notace UML class diagram).

2.3

Implementace

Implementace probíhala v lokálním prostředí formou testování funkcionality, protože fakultní řešení datového skladu, kde by mohly být naimplementované repoty nasazeny, nebylo v době zpracování práce k dispozici. Výstupem implementační fáze v oblasti reportů jsou tedy především zkušenosti, které budou v této sekci popsány a po nasazení fakultního datového skladu budou využity k úpravě, případně implementaci navržených reportů. Nasazením fakultního datového skladu se ve své práci zabývá Stanislav Kuznětsov (viz [9]). Pro implementaci byl vybrán report výkon učitele, který realizuje KPI Hodnocení pedagogických výkonů (viz sekce 1.3.2.4).

2.3.1 2.3.1.1

Report výkon učitele Databáze a dostupná data a datová kostka

Jako RDBMS pro datový sklad byl vybrán systém PostgreSQL, který bude nasazen na stejné doméně jako datový sklad. Aby bylo možné provádět testovací reporty, byla připravena malá databáze vytvořená na datech ze systému Úvazky. Data byla vyčištěna a upravena do hvězdicového schématu, které je přílohou této práce (viz příloha B). Nad touto databází, konkrétně nad faktovou tabulkou f_ucitele_vykon, byla vytvořena datová kostka pro dotazování se na výkony učitelů. Kostka se definuje ve schématu pomocí speciálních XML značek, které spolčně se svými atributy určují název kostky, dimenze, míry a jejich propojení na tabulky v databázi (více o psaní schématu v referenční příručce [3]). Schéma, někdy 61

2. BI reporty nad fakultním datovým skladem také nazývané jako katalog, určuje vícedimenzionální databázi definicí všech datových kostek. Schéma popisující datovou kostku pro report výkon učitele je součástí příloh této práce, viz C. Kostka pro report výkon učitele má tedy následující dimenze • učitel • čas (akademický rok, semestr) V případě většího datového pokrytí bude možné zavést další dimenze, například dimenzi katedra. Mírou je v tomto případě započítatelná hodina. 2.3.1.2

MDX dotaz a výstup

Nad takto definovanou kostkou je již možné provádět MDX dotazy. Před samotným dotazem je třeba získat konexi do databáze, tu poskytuje DriverManager z WAR Mondrianu. Při vytváření konexe je třeba předat nutné parametry, jako název databáze, uživatele, kterým budeme přistupovat, jeho heslo, ovladače pro připojení, použitý katalog (schéma datového skladu) a samotnou cestu k databázi. Požadavek pak vypadá následovně Connection connection = DriverManager.getConnection( "Provider=mondrian;" + "jdbc:mondrian:JdbcDrivers=org.postgresql.Driver;" + "JdbcDrivers=org.postgresql.Driver;" + "Jdbc=jdbc:postgresql://localhost/dwuvazky;" + "JdbcUser=uzivatel;JdbcPassword=heslo;" + "Catalog=WebContent/WEB-INF/DWUvazky.xml;", null); Poté již můžeme předat konexi MDX dotaz (v případě reportu výkon učitele to je dotaz na počet započítatelných hodin pro všechny učitele přes všechny dostupné roky, a to pro každý zvlášť) a provést ho Query query = connection.parseQuery( "SELECT {[Measures].[ZH Count]} on columns, " + "{[Teacher].Members} on rows " + "FROM [VYKON_U] " + "WHERE ([Time].Members)"); Result result = connection.execute(query); Pro zpřehlednění náleží výstup dotazu omezenému na jednoho učitele a jeden akademický roku Axis #0: {[Time].[2012]} 62

2.3. Implementace Axis #1: {[Measures].[ZH Count]} Axis #2: {[Teacher].[balikm]} Row #0: 3,020.664 Učitel s uživatelským jménem balikm tedy má v akademickém roce 2012 3020.665 započítatelných hodin.

63

KAPITOLA

Rozhraní a GUI BI reportů Tato kapitola pokrývá problematiku API6 pro reporty realizované nad datovým skladem, GUI7 pro reporty a komunikaci mezi nimi. V první části jsou definovány základní pojmy a popsány dostupné technologie, ve druhé části je návhr architektury a samotné realizace a nakonec je popsána vzorová implementace pro jeden report.

3.1

Použité technologie a postupy

Pro návrh a implementaci API a GUI pro reporty realizované nad datovým skladem bylo navrženo použítí několika technologií a nástrojů. V této části bude jejich krátké představení a vysvětlení, proč byly vybrány a použity právě tyto technologie. Cílem není detailně vysvětlit jejich implementaci v rámci datového skladu, jeho rozhraní (reportů) a GUI, ale umožnit čtenáři jejich pochopení a nastínit použitý přístup.

3.1.1

REST API

Aby byly dodrženy standardy z hlediska poskytovaných služeb na fakultě, používá se pro tvorbu rozhraní architektura REST. REST je styl architektury, která definuje množinu podmínek, jejichž aplikace v architektuře distribuovaného systému vyústí v dobré vlastnosti jako loose coupling a horizontální škálovatelnost. RESTful webové služby jsou výsledkem aplikace těchto podmínek na služby, které využívají webových standardů, jako URI, HTTP a JSON. Takové služby se pak stávají součástí struktury webu a využívají výhody letitého vývoje webového inženýrství k uspokojeni potřeb klientů.[4] Samotná 6

Application Programming Interface, rozhraní, které je možné na daném systému použí-

7

Graphical User Interface, neboli grafické uživatelské rozhraní.

vat.

65

3

3. Rozhraní a GUI BI reportů REST architektura není protokolově specifická, pro účely API nad datovým skladem a reporty se bude využívat protokol HTTP. Rozhraní je pak kolekcí RESTful služeb s omezeními vyplývajícími z jeho účelu. Dále se budu zmiňovat pouze o REST API, myšlena je tím kolekce RESTful služeb a REST architektura. 3.1.1.1

Princip REST, operace a formát dat

Principem REST je poskytovat služby jako data, nikoliv jako operace. Každá služba (nebo také datový zdroj) má definované URI, na které je možné volat HTTP operace GET, POST, PUT a DELETE. Výsledkem takového volání jsou data ve vyžádaném formátu (na základě dostupných formátů), například jako HTML, XML, JSON a další. Díky datové orientaci služeb je možné jejich výstupy na cestě ukládat do cache, zrychlit tak práci a omezit velikost a intenzitu síťových přenosů. Z hlediska práce s reporty, tedy zobrazením dat z reportů v GUI, jsou přípustné pouze operace pro čtení, tedy GET. Tato operace ovšem neumožňuje posílat parametry jako data, ale pouze jako součást HTTP hlavičky (v URI se objevují za ?, například ?jmeno=karel), proto se využívá i metoda POST, která místo dat, která chce založit v daném zdroji, pošle parametry volané operace. Pro čitelnost a snadnou práci bylo jako formát přenášených dat zvoleno XML. 3.1.1.2

Servlety jako zdrojové služby, JAX-RS

Protože na serveru nejsou zdroje uloženy přímo, ale dynamicky se tvoří na základě požadavků klientů, je nutné vytvořit "obsluhu"jednotlivých zdrojů servlety. Servlet je malý modul v rámci serverové aplikace, který má, v tomto případě, definované rozhraní pomocí metod a jejich parametrů. Každá metoda určená jako veřejná služba je pak namapovaná na určité URI a HTTP operaci, kterou je možné ji volat, a navenek se tváří jako datový zdroj. Existuje několik způsobů jak servlety tvořit, buď přímo jako "pravé"servlety z JDK, u kterých je ale potřeba velké množství logiky pro zpracování dotazu a vytvoření odpovědi, nebo je možné využít JAX-RS - Java API for RESTful Web Services, které využívá anotací nad POJO a vytváří tak zdroje, konkrétně tedy některou z implemetací. Implementací JAX-RS existuje celá řada - například Apache CFX, JBoss RESTEasy nebo Jersey od Oracle. Rozhodl jsem se použít právě poslední jmenovanou možnost, jelikož se jedná o stabilní, dobře zdokumentovanou a hojně používanou referenční implementaci od společnosti Oracle (dříve Sun). Na fakultě se již používá JBoss RESTEasy, a to na projektu KOSApi. Odlišná implementace byla zvolena jednak na základě prostředí, na kterém datový sklad a jeho rozhraní poběží (viz níže), tak z důvodu možného porovnávání obou implementací v rámci fakulty. 66

3.1. Použité technologie a postupy 3.1.1.3

Umístění zdrojů, DWHAPI

Zdroje samotné musí být umístěny na stejném aplikačním serveru jako Mondrian8 . Implemetovat je však přímo v Mondrianu by zapříčinilo vznik těsných vazeb a možné problémy při potřebě rozhraní vyměnit či silně modifikovat. Proto vznikl WAR9 projekt DWHAPI10 , který má Mondrian jako knihovnu a může tak přistupovat ke všem reportům na něm implementovaných. V případě potřeby vyměnit API tak stačí vytvořit nový WAR projekt, který může existovat paralelně k DWHAPI a zajistí se tak zpětná kompatibilita. Lze tedy zasahovat do API bez nutnosti zásahu a odstávky Mondrianu.

3.1.2

GUI pro reporty

Zobrazení výstupu reportu nad datovým skladem není statické, ale musí uživateli umožnit určitou interaktivitu, aby mohl data třídit, filtrovat a dostal tak požadovanou informaci. Proto byl výběr technologie omezen na platformy pro vytváření bohatých internetových aplikací (dále pouze RIA - Rich Internet Application), které se v mnohém podobají aplikacím desktopovým. Mezi tři největší a zároveň nejrozšířenější patří Adobe Flash (společně s Adobe Flex frameworkem, dále pouze jako Flex), Java (applety a JavaFX, dále pouze jako JavaFX) a Microsoft (dále jen MS) Silverlight. Kritériem pro výběr byla rozšířenost, standardizace, dostupnost na více platformách (MS Windows, Linux), dostupnost nástrojů pro vývoj a především rychlost a efektivita při tvorbě potřebných komponent a komunikací s rozhraním datového skladu. Důležité je také vzít v potaz to, že primárním použitím GUI aplikace je být vložena a zobrazena jako portlet v portálu FIS. Dále bude tedy GUI aplikace pro zobrazování reportů nad datovým skladem označována jako portlet. 3.1.2.1

Adobe Flex

Podmínka pro dostupnost na více platformách vyřadila MS Silverlight, který je sice dostupný i například na OS Linux, ale jeho funkcionalita není stabilní a podpora prakticky neexistuje. JavaFX i Flex jsou obě standardizované technologie dostupné na široké škále platforem, ale Flex je v současné době rozšířenější, poskytuje více funkcionality a především je efektivnější pro vývoj. Nevýhodou je, že oficiální vývojové prostředí od společnosti Adobe vyžaduje licenci a není distribuováno jako open-source, stejně jako Flash Player, plugin internetového prohlížeče a virtuální stroj, ve ktrém aplikace běží (který je dostupný zdarma). Adobe Flash bývá často spojován s animacemi, webovými hrami a obecně s vektorovou grafikou. To je ale pouze část možností, pro snadný vývoj RIA 8

OLAP server, kterým je realizován datový sklad. Web application ARchive - balíček jazyku Java obsahující kolekci tříd, konfiguračních souborů, servletů apod., dohromady tvořící webovou aplikaci. 10 DataWareHouseAPI, neboli aplikační rozhraní datového skladu. 9

67

3. Rozhraní a GUI BI reportů vznikl framework Flex, který rozšiřuje původní ActionScript (objektově-orientovaný programovací jazyk derivovaný z ECMAScriptu) o MXML, značkovací jazyk ne nepodobný HTML. Flex byl od počátku vyvýjen jako open-source a na konci roku 2011 se přesunul od Adobe do Apache Foundation, která jeho rozvoj a správu převzala.

3.1.2.2

Nástroje a komponenty pro vizualizaci reportů

Pro samotné zobrazení výstupu reportů v GUI jsou důležité příslušné komponenty, které umožní nejen zobrazení, ale i manipulaci s daty. Flex takových komponent poskytuje mnoho, například DataGrid – interaktivní tabulka s možností řazení dat ve sloupcích a filtrací obsahu. Všechny komponenty je také možné skinovat – měnit barvu, vzhled, velikost – buď lokálně u komponenty, nebo globálně pomocí CSS. Další výhodou je existence nástroje pro výroby wireframe, Balsamiq Mockups, která slouží k rychlému náčrtu obrazovek, které mohou sloužit ke komunikaci a ladění vzhledu ještě před vlastní implementací. Zobrazení dat a funkcionalita sou tak komunikovány a odladěny s koncovým zákazníkem ještě ve fázi analýzy a návrhu. Komponenty, které tento nástroj poskytuje, jsou také přímo dostupné v Flex frameworku, wireframe tedy může být velice přesným obrázkem budoucí aplikace. Bližší informace o Adobe Flash a Flex frameworku naleznete referenční příručce (viz [1]).

3.1.3

Komunikace mezi portletem a API

V předchozích dvou sekcích byly nastíněny použité technologie a principy jak na straně klienta, tak na straně serveru. Pro komunikaci bude použit protokol HTTP, konkrétně metody GET a POST a data budou předávána v XML formátu. Vstupem pro komunikaci bude výstup MDX dotazu do datového skladu převedený na POJO (Plain Old Java Oject). Pro komunikaci s klientem je však nutné převést POJO do XML. Možností je ruční přepis (například modifikací toString() metody), ale tento přístup je velice náchylný na jakoukoliv modifikaci (a modifikace jsou velice pravděpodobné a předpokládané) a především neřeší převod z XML do POJO. Proto bylo rozhodnuto použít JAXB (Java Architecture for XML), který je součástí JDK. Pomocí anotací nad třídami je tak možné serializovat POJO do XML a naopak. Na straně klienta je situace komplikovanější, nativní podpora pro mapování XML na objekty neexistuje. Je sice možné pracovat přímo s XML dokumentem pomocí E4X - ECMAScript for XML, ale pro složitější operace je to nepraktické. Proto byl vybrán framework FlexB, který se snaží implementovat funkcionalitu podobnou JAXB v prostředí Flexu. 68

3.2. Architektura a návrh řešení Aby bylo možné tímto způsobem komunikovat, je nutné mít na obou stranách stejné třídy se stejnou anotací. Vzniká tedy nutnost zavést jednotný model, který bude sloužit jako popis komunikace a rozhraní.

3.2 3.2.1

Architektura a návrh řešení Architektura

Vedle samotného Mondrianu jako datového skladu je na stejném aplikačním serveru nasazeno i DWHAPI, což je kolekce zdrojů, které jsou vystaveny jako rozhraní datového skladu, a aplikační logiky, která transformuje požadavky od klientů, se získanými parametry volá služby na straně Mondrianu a data získaná dotazy do datového skladu transformuje na příslušnou odpověď. Dále se na DWHAPI nachází HTML stránka, do které se pomocí java scriptu vkládá flash aplikace - zobrazení reportů. Tato stránka bude k dispozici na rozhraní DWHAPI, odkud si ji, společně s příslušnými parametry, klient stáhne a vloží do své struktury (například jako portlet do portálu fakultního informačního systému) a samotná aplikace ve formě SWF souboru. Model architektury je znázorněn v komponentovém diagramu, viz obrázek 3.1.

3.2.2

API

Jak již bylo zmíněno v předchozí sekci, API je realizováno pomocí WAR DWHAPI, které poskytuje jak základní služby pro načtení portletů, tak samotné služby jednotlivých reportů. Pro přístup ke všem službám je nutná autentizace a autorizace uživatele. Autentizace bude probíhat pomocí SSO11 v rámci FIS (případně SSO modulem nad aplikačním serverem, na kterém DWHAPI běží. V současné době není k dispozici IDM12 služba, která by pro daného uživatele vrátila jeho roli, proto budou prozatím role pro dané uživatele pevně určeny a po vytvoření IDM služby bude autorizace namapována na poskytnuté role. 3.2.2.1

Základní služby DWHAPI

Mezi základní služby poskytované DWHAPI patří načtení seznamu dostupných reportů (portletů) pro danou roli uživatele a v případě neprázdné množiny také načtení vybraného portletu. Přímé volání reportu není povoleno a není možné, protože logika transformace výstupu reportu do dohodnutého formátu je implementována na DWHAPI. Pokud by bylo v budoucnu nutné výrazně upravit rozhraní, případně připravit rozhraní s odlišným protokolem nebo formátem, je možné nasadit další WAR paralelně s DWHAPI a zajistit tak plně 11

Single Sign-On, neboli jednotné přihlášení v rámci domény pro více systémů v dané doméně. 12 IDentity Management, systém pro správu identit jednotlivých uživatelů umožňující autentizaci a autorizaci.

69

3. Rozhraní a GUI BI reportů zpětnou kompatibilitu a neměnnost rozhraní. Rozhraní základní služby pro získání dostupných portletů je namodelována diagramem tříd, viz obrázek 3.2.

Obrázek 3.1: Návhr architektury řešení datového skladu, jeho rozhraní a portletů (notace UML component diagram).

3.2.2.2

Služby reportů

Rozhraní jednotlivých reportů co možná nejvíce využívá doménový model datového skladu (viz sekce 2.2.1). Pokud to není možné, vytváří se DTO 13 , který 13

70

Data Transfer Object, obalující třída s atributy přenášených dat.

3.2. Architektura a návrh řešení může rozšiřovat doménový model o atributy, které v něm chybí za účelem datového přenosu a jednoduššího API. Stejně jako doménový model se rozhraní zakresluje pomocí diagramu tříd, ve kterém by měly být všechny potřebné entity (pro přehlednost jsou někdy obecné entity, které jsou předky entit na rozhraní, vynechány a konkludentně se předpokládá jejich účast).

Obrázek 3.2: Model rozhraní služby pro získání dostupných reportů a portletů (notace UML class diagram).

Obrázek 3.3: Model rozhraní služby reportu výkon učitele (notace UML class diagram). Na obrázku 3.3 je vidět rozhraní reportu pro výkon učitele. Základními 71

3. Rozhraní a GUI BI reportů entitami jsou UcitelVykonRequest a UcitelVykonResponse, které reprezentují vstup a výstup služby. Pro vstup je použito DTO, které nese pouze jméno uživatele, pro kterého se mají získat data. Tento atribut je také na entitě osoba, ale její ostatní atributy jsou v tomto případě irelevantní a nadbytečné. Na výstupu se nacházejí pouze entity z doménového modelu. 3.2.2.3

Struktura rozhraní

Rozhraní jako takové, tedy URI jednotlivých služeb, bylo rozděleno podle oblasti a funkce dané služby do několika složek. V případě DWHAPI jsou služby referencovány ve formátu urlServeru/dwhapi/oblast/služba. Jednotlivé oblasti služeb jsou popsány v následujícím seznamu /common/ - obecné služby, například získání seznamu dostupných portletů. /portlet/ - služby pro získání portletů. /portlet/swf/ - podoblast pro získání swf aplikací. /report/ - služby reportů. URI poskytovaných služeb se tvoří v rámci implementace, kde budou naimplementované služby popsány. Z HTTP metod (viz 3.1.1.1) jsou povoleny pouze metody GET a POST a to pouze pro čtení.

3.2.3

GUI

Pro vizualizaci navržených reportů bylo vytvořeno několik portletů, které budou v následujících sekcích posány. Bude uveden jejich popis, možnosti a několik příkladů zamýšleného užití portletu. Pokud portlet poskytuje možnost parametrizovat zobrazení (například podle let, semestru apod.), získávají se tyto rozsahy přímo z dat, která portlet zpracovává. 3.2.3.1

Portlet doktorské studium - školitelé

Aby byl splněn účel reportu školitelé, portlet musí zobrazit seznam všech školitelů pro doktorandy a umožnit uživateli snadnou práci. V tabulce je tak pro každého školitele zobrazen počet jeho doktorandů ve standardní době, počet jeho doktorandů, kteří čekají na obhajobu, počet volných prací, které školitel nabízí a celkový počet jeho úspěšných doktorandů. Zobrazená data se dají parametrizovat výběrem roku, semestru, případně zobrazením celého akademického roku, případně všech dostupných dat. Dále je možné data filtrovat dle jména a příjmení školitele (filtr funguje jako fulltextové vyhledávání) a třídit dle jednotlivých sloupců (jak vzestupně, tak sestupně). 72

3.2. Architektura a návrh řešení Při výběru školitele ze seznamu se pod ním zobrazí jeho detailní informace, jeho jméno a příjmení, katedra, ke které přísluší, jeho kontaktní informace a souhrné informace o jeho činnosti. Mezi ně patří průměrná doba školeného doktoranda do obhajoby disertace, počet školených doktorandů před minimem, před státními závěrečnými zkouškami a ostatních. Všechny tyto údaje vycházejí z nejaktuálnějších dat, která jsou k dispozici. Společne se souhrnými informacemi se zobrazují grafy, které reprezentují počet školených doktorandů a počet vypsaných prací v jednotlivých letech. Portlet je znázorněn jako wireframe na obrázku 3.4.

Obrázek 3.4: Wireframe portletu doktorské studium - školitelé. Portlet slouží především pro vedoucího katedry, děkana, případně další manažery fakulty, kteří s jeho pomocí mohou sledovat různé ukazatele o práci školitelů. Příklady použití jsou znázorněny v diagramu užití 3.5.

73

3. Rozhraní a GUI BI reportů

Obrázek 3.5: Diagram užití portletu doktorské studium - školitelé (notace UML use case diagram).

3.2.3.2

Portlet přijímací řízení - přihlášky

Portlet příjímací řízení - přihlášky umožňuje aktuální i historický přehled stavu zájemců o studium na fakultě v bakalářském a magisterském programu, pro každý program ve zvláštním okně. Zobrazovaná data jsou počet přihlášených studentů, který se dále rozpadá na počet přihlášených studentů do prezenční formy studia do kombinované formy studia, počet studentů zapsaných k přijímací zkoušce (PZ), počet studentů přijatých bez přijímací zkoušky, který se dále rozpadá na jednotlivé důvody přijetí (státní maturita, SCIO test, olympiáda), počet studentů přijatých na základě přijímací zkoušky a počet přijatých studentů celkem. Dále se sledují data ohledně zápisů do studia, konkrétně počet studentů registrovaných k zápisu a počet zapsaných studentů. Z těchto dat se pak počítají procetuální poměry počtu studentů zapsaných k počtu studentů přihlášených a počtu studentů zapsaných k počtu studentů přijatých. Posledním údajem je datum přijímací zkoušky a zbývající čas (pokud ještě neproběhla). Zobrazená data se dají parametrizovat výběrem roku, ve kterém přijímací řízení probíhá. Společně s těmito údaji se zobrazují i sumární grafy, které sledují počet studentů přihlášených, zapsaných a přijatých v letech, pro které jsou data dostupná. Portlet je znázorněn jako wireframe na obrázku 3.6. Portlet je určen především pro děkana a management fakulty, kteří mohou sledovat aktuální stav a také upravovat parametry přijímacího řízení na základě historických dat (například bodovou hranici přijímací zkoušky pro přijetí). Dále může sloužit pro studijní referenty jako kontrola stavu přihlášek pro odhady nutných kapacit pro jejich zpracování. Příklady použítí jsou znázorněny v diagramu užítí 3.7. 74

3.2. Architektura a návrh řešení

Obrázek 3.6: Wireframe portletu příjímací řízení - přihlášky.

Obrázek 3.7: Diagram užití portletu příjímací řízení - přihlášky (notace UML use case diagram).

3.2.3.3

Portlet závěrečné práce

Portlet závěrečné práce je přehledem informací o bakalářských a magisterských závěrečných pracech. Je zobrazen počet volných, rezervovaných a zadaných prací, a to vždy ke každému oboru (nebo specializaci, pokud se obor dále člení na specializace). Ke každému oboru (specializaci) je také zobrazen počet 75

3. Rozhraní a GUI BI reportů studentů, kteří se již na daný obor přihlásili. Dále jsou vypsána sumární čísla, přičemž celkový počet studentů nemusí být součtem počtu studentů v jednotlivých oborech, protože ne všichni musejí být zařazeni. Zobrazená data se dají parametrizovat výběrem školního roku. Portlet je znázorněn jako wireframe na obrázku 3.8.

Obrázek 3.8: Wireframe portletu závěrečné práce.

Portlet je určen především pro vedoucí jednotlivých kateder, kteří mohou kontrolovat stav prací pro daný obor a případně pokračovat pomocí odkazů na systém pro správu závěrečných prací nebo portlet report vedoucí závěrečných prací. Může sloužit také děkanovi fakulty pro celkový přehled stavu. Příklady použití jsou znázorněny v diagramu užití 3.9.

Obrázek 3.9: Diagram užití portletu závěrečné práce (notace UML use case diagram).

76

3.2. Architektura a návrh řešení 3.2.3.4

Portlet závěrečné práce - vedoucí bakalářských prací

Portlet závěrečné práce - vedoucí bakalářských prací lze použít jak samostaně, tak v kombinaci s portletem závěrečné práce jako celkovým přehledem. Účelem portletu ke zobrazit přehled možných vedoucích bakalářských prací v přehledné tabulce, kde je ke každému vedoucímu zobrazeno jeho jméno a příjmení, katedra na které je zaměstnán, počet jeho volných, rezervovaných a zadaných prací a počet oponentur. Zobrazená data se dají parametrizovat výběrem roku a dále filtrovat vyhledáváním dle celého jména a katedry (fulltext), případně se dají zobrazit pouze externisté. Tabulku je také možné řadit dle jednotlivých sloupců. Po vybrání vedoucího se pod tabulkou zobrazí jeho detailní informace, jeho jména a příjmení, katedra, ke které přísluší a kontaktní informace. Dále je zde podrobný výpis počtu oponentur a volných, rezervovaných a zadaných prací členěný po oborech (specializacích) a celkový počet zadaných prací přes všechna období. Tato čísla jsou zobrazena i formou sumárních grafů po letech, pro které jsou dostupná data. Portlet je znázorněn jako wireframe na obrázku 3.10.

Obrázek 3.10: Wireframe portletu závěrečné práce - vedoucí bakalářských prací. 77

3. Rozhraní a GUI BI reportů Portlet je určen pro vedoucího katedry, který s jeho pomocí může kontrolovat jednotlivé zaměstnance své katedry (z aktuálního i historického hlediska), případně hledat volné kapacity pro bakalářské práce. Příklady použití portletu jsou znázorněny v diagramu užití 3.11.

Obrázek 3.11: Diagram užití portletu závěrečné práce - vedoucí bakalářských prací (notace UML use case diagram). Společně s tímto portletem bude existovat i portlet pro vedoucí diplomových prací a sumární portlet vedoucí závěrečných prací, který bude zobrazovat souhrn všech závěrečných prací, bakalářských i diplomových. Mezi těmito portlety se bude možné přepínat pomocí odkazů, a to jak na úrovni celkového přehledu, tak na úrovni vybraného vedoucího. 3.2.3.5

Portlet komise

Portlet komise zobrazuje seznam všech komisí, které na fakultě vznikají. Ke každé komisi pak zobrazuje její typ, datum, kdy vykonává svou činnost, jméno, příjmení a obor předsedy, místopředsedy a všech členů. Zobrazená data lze parametrizovat podle data, kdy má komise vykonávat svou činnost, případně lze zvolit celý měsíc nebo celý rok (vztažený k vybranému datu). Je také možné najít nejbližší datum s nekompletní komisí (nutný minimální počet členů komise je nastaven na 5). Při vybrání komise se zobrazí detailní informace o všech členech komise, jejich jméno a příjmení, obor, který v komisi zastupují, katedra, ke které náleží a jejich kontaktní informace. Portlet je znázorněn jako wireframe na obrázku 3.12. Portlet je určen děkanovi a vedoucím kateder, kteří mají na starosti sestavování a kontrolu komisí. Příklady použití jsou znázorněny v diagramu užití 3.13.

78

3.2. Architektura a návrh řešení

Obrázek 3.12: Wireframe portletu komise.

Obrázek 3.13: Diagram užití portletu komise (notace UML use case diagram).

79

3. Rozhraní a GUI BI reportů K portletu komise bude existovat „inverzní“ portlet člen komise, který bude sloužit pro zobrazování dat o členství v komisích pro jednotlivé zaměstnance. Na tento portlet se bude možné dostat odkazem z portletu komise, případně otevřít přímo detail vybraného člena komise pomocí odkazu z detailu komise. Portlet komise také umožňuje pomocí odkazu přejít do systému pro správu komisí.

3.2.4

Komunikace

V rešeršní části komunikace (viz sekce 3.1.3) bylo nastíněno pomocí jakých technologií bude komunikace probíhat. Tato návrhová část se detailně zabývá životním cyklem komunikace a daty, které se přenáší. 3.2.4.1

Handshake, získání portletu a iniciální nahrání dat

Prvním krokem, který je nutné provést, je získání samotného portletu (HTML wrapper a SWF aplikace). Tato sekvence je nazvána handshake14 a má dvě fáze. První fází je získání HTML wrapperu, který zapouzdřuje samotnou aplikaci. Parametrem tohoto volání je ID portletu, který chceme náhrát, výsledkem pak HTML wrapper a případně jeho parametrizace. Druhou fází je pak nahrání samotné aplikace, parametrem je opět ID portletu a výsledkem SWF aplikace. Okamžitě po nahrání a inicializaci portletu probíhá automaticky volání příslušného reportu, buď bezparametrické, nebo s výchozími hodnotami parametrů pro daný portlet. Portlet v naprosté většině volá a má volat pouze jeden report, pokud by jich bylo více, bude se tento případ řešit speciální logikou pro daný portlet. 3.2.4.2

Množina přenášených dat, opětovné nahrání a cache

Při prvním a každém dalším volání reportu se portlet vždy snaží získat co největší množinu dat, například data pro všechny dostupné roky, i když viditelný je jenom jeden. Za cenu většího objemu přenášených dat pak dostaneme rychlejší klientskou aplikaci schopnou provádět některé výpočty na své straně, která nezatěžuje server a linky častou komunikací. Pokud by tato množina byla příliš velká, mohou se nastavit určité meze (například u portletů zobrazujících velkou množinu dat z různých oblastí). Komunikace je znázorněna pomocí sekvenčního diagramu, viz obrázek 3.14. Mezi portletem a DWHAPI se ještě nachází komponenta ESB15 , která převystavuje rozhraní systémů (V diagramu je zakreslena schematicky jako pasivní člen, může však plnit celou řadu funkcí. Popis komponenty ESB, jejího 14

podání rukou Enterprise Service Bus, základní komponenta servisně orientované architektury zapouzdřující komunikaci mezi jednotlivými službami a jejich konzumenty. 15

80

3.2. Architektura a návrh řešení účelu a funkcionality je nad rámec této práce, více informací je možné zjistit v dokumentaci FIS.). Díky přenášení celé množiny dat tak může odpovědi ukládat do cache a při opakovaném dotazu je vracet (bude ovšem nutné zkontrolovat práva uživatele, aby nedostal data, ke kterým nemá přístup). Aby bylo toto všechno možné, je nutné přesně definovat životnost dat a při jejím konci data invalidovat a načíst znovu (a to na všech případných vrstvách, které mají cache, nebo data jinak drží - klient, ESB), jinak mohou být neaktuální.

Obrázek 3.14: Návrh architektury komunikace portlet - api - datový sklad (notace UML sequence diagram).

81

3. Rozhraní a GUI BI reportů 3.2.4.3

Detaily volání, autentizace a autorizace

Je tedy dán princip a posloupnost komunikace. Aby bylo možné pochopit, jak může volání vypadat a jaký může mít výsledek, zobrazuje následující diagram aktivity (viz obrázek 3.15) akce po zavolání služby na DWHAPI. První volání je první fází handshake, získání HTML wrapperu. Nejprve se z parametrů volání získá security principal, tedy entita reprezentující volajícího, ať už je jím uživatel nebo jiná aplikace (dále jen uživatel pro oba případy), která může být autentizována. Autentizace se ověří (autentizace v rámci FIS probíhá jako SSO) a v případě úspěchu se ověří uživatelova role (viz dále) a v případě neúspěchu se zavolá obsluha chyb. Po úspěšném ověření se role přiřadí danému security principal (aby se ověřování nemuselo opakovat) a vrátí se požadovaný HTML wrapper spolu s iniciálními parametry. V současné době neexistuje jednotná správa rolí uživatelů (IDM), proto musí být zavedeny role uměle pro doménu datového skladu a reportů, a to zvlášť pro každého uživatele. Autorizace tedy bude probíhat v rámci DWHAPI a Mondrianu a bude určovat přístup k reportům (datům) a portletům. Po nasazení IDM komponenty bude správa přepojena a přístupy upraveny podle IDM. Druhé volání znázorněné v diagramu aktivity je již přímo načítání dat autentizovaným a autorizovaným uživatelem. Nejprve se načtou parametry volání a zvalidují se proti pravidlům daného reportu. Z parametrů se poté postaví dotaz do datového skladu, jehož výsledek se převede nejprve do POJO a poté do XML, které se vrátí jako výsledek volání.

82

3.2. Architektura a návrh řešení

Obrázek 3.15: Akce po invokaci služeb /portlet/ a /report/ (notace UML activity diagram).

83

3. Rozhraní a GUI BI reportů

3.3

Implementace

Rozhraní na straně DWHAPI bylo experimentálně vyzkoušeno a po nasazení datového skladu a uzpůsobení konfigurace může být nasazeno. V této práci tedy zůstává ve fázi návrhu. Aby bylo možné prezentovat možnosti Flexu jako frameworku pro tvorbu portletů, byl vytvořen portlet s daty převzatými z databáze systému úvazky (viz sekce 2.3). Aby nedošlo k úniku informací, byla reálná jména změněna na fiktivní. Jakákoliv možná podobnost se zaměstnanci fakulty je čistě náhodná. Použitá data de týkají výkonů pěti učitelů v akademickém roce 2011/2012.

3.3.1

Portlet výkon učitelů

Pro implementaci GUI aplikace byl vybrán portlet pro report výkon učitelů (report viz sekce 2.3.1). V portletu je formou tabulky zobrazen seznam učitelů, jejich jméno a příjmení, katedra, úvazek, počet započítatelných hodin a normovaný počet započítatelných hodin. Zobrazená data se dají parametrizovat výběrem roku a semestru (případně zobrazením celého akademického roku). Dále je možné data v tabulce třídit podle všech sloupců a filtrovat fulltextovým vyhledáváním podle jména učitele. Při výběru učitele ze seznamu se pod ním zobrazí jeho detailní informace (jméno a příjmení, katedra, kontaktní informace) a graf znázorňující počty započítatelných hodin v dostupných letech. Screenshot z aplikace je na obrázku 3.16.

Obrázek 3.16: Implementovaný portlet výkon učitelů. Portlet je možné spustit samostaně ve webovém prohlížeči otevřením HTML stránky portlet.html ze složky se zkompilovanou aplikací (viz obsah CD D). 84

3.3. Implementace Pro spuštění je nutné mít nainstalovaný plugin Adobe Flash Player minimálně ve verzi 11.2. Zdrojové soubory portletu jsou taktéž součástí přiloženého CD. Po nasazení celé infrastruktury datového skladu a jeho rozhraní může být portlet vložen do portálu fakultního informačního systému.

85

Závěr V práci se podařilo nastínit problematiku klíčových ukazatelů výkonnosti a s jejich pomocí zmapovat několik vybraných důležitých oblastí řízení fakulty, prozkoumat možnosti dotazování se nad daty v datovém skladu fakulty a navrhnout a otestovat dotazy pro vytvoření analytických reportů pro tyto ukazatele. Pro tyto reporty byl vytvořen návrh uživatelského rozhraní a jeden z nich byl implementován jako portlet, který bude moci být využit v portálu fakultního informačního systému. Jednotlivé kroky byly konzultovány s managementem fakulty, aby vyhovovaly jeho požadavkům, a byly podle toho přizpůsobeny. Důležitým přínosem práce je pak především popis a návrh architektury celého tohoto řešení, který bude moci být po nasazení datového skladu využit k jeho implementaci. Cíle práce se tak podařilo naplnit. Práce tedy v současném stavu demonstruje možnosti manipulace s daty v datovém skladu fakulty a poskytuje čtenáři návod, jak k dané problematice přistupovat. Je možné a vhodné ji pro dosažení maximálního efektu dále rozšiřovat, kromě samotné implementace řešení po nasazení datového skladu může rozvoj pokračovat ve všech jejích úrovních, tedy mapovat další oblasti klíčovými ukazateli výkonnosti, navrhovat a realizovat dotazy nad daty v datovém skladu pro získání analytických reportů a vytvářet pro ně uživatelské rozhraní ve formě portletů. Je také nutné dále rozvíjet a upřesňovat architekturu řešení, aby perfektně zapadla do koncepce nového informačního systému fakulty.

87

Literatura [1] Flex reference guide. http://help.adobe.com/en_US/flex/using/index.html, 11. 5. 2012.

stav

z

[2] MDX reference guide. http://msdn.microsoft.com/en-us/library/aa216767(v=sql.80).aspx, stav z 11. 5. 2012. [3] Mondrian schema reference guide. http://mondrian.pentaho.com/documentation/schema.php, stav z 11. 5. 2012. [4]

Burke, B.: RESTful Java with JAX-RS. O’Reilly Media, 2009, ISBN 9780596158040.

[5]

Chua, C. S.; Green, R.: Data Warehouse Method. 1999, studijní literatura.

[6]

Codd, E. F.; Codd, S.; Salley, C.: Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate. 1993.

[7]

Dubler, C.; Wilcox, C.: Just What Are Cubes Anyway? (A Painless Introduction to OLAP Technology). http://msdn.microsoft.com/en-us/library/aa140038%28v=office.10%29, stav z 11. 5. 2012.

[8]

Inmon, B.: Building the Data Warehouse. John Wiley & Sons, Inc., 1992, ISBN 0471569607.

[9]

Kuznětsov, S.: Datový sklad fakulty, diplomová práce.

[10] Luhn, H. P.: A Business Intelligence System. IBM Journal of Research and Development, 1958. [11] Nolan, C.: Manipulate and Query OLAP Data Using ADOMD and Multidimensional Expressions. Microsoft systems journal, 1999. [12] Pareek, D.: Business Intelligence for Telecommunications. CRC Press, 2007, ISBN 0-8493-8792-2. 89

Literatura [13] Parmenter, D.: Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs. John Wiley & Sons, Inc., 2007. [14] Pergl, R.: Příprava systému managementu kvality Fakulty informačních technologií ČVUT. [15] Wagner, J.: Měření výkonnosti. GRADA Publishing, 2009, ISBN 978-80247-2924-4. [16] KPI definované University of Essex. http://www.essex.ac.uk/about/strategy_and_vision/kpi/default.aspx, stav z 11. 5. 2012. [17] KPI definované Iowa State University. http://www.engineering.iastate.edu/strategic-plan/kpis/, stav z 11. 5. 2012. [18] Knihovna KPI. http://kpilibrary.com, stav z 11. 5. 2012. [19] Mezinárodní fórum pro výzkum a aplikaci KPI. http://www.smartkpis.com/key-performance-indicator-KPI, stav z 11. 5. 2012. [20] Definice metriky v encykopedii Wikipedia. http://en.wikipedia.org/wiki/Metric, stav z 11. 5. 2012.

90

PŘÍLOHA

Seznam použitých zkratek API Application programming interface BI Business intelligence DSP Disertační práce DTO Data transfer object FIS Fakultní informační systém GUI Graphical user interface IDM Identity management KPI Key performance indicator MDX Multidimensional expressions SQL Structured query language OLAP Online analytical processing ROLAP Relational OLAP MOLAP Multidimensional OLAP OLTP Online transaction processing RDBMS Relational database management system PR Public relations POJO Plain old Java object 91

A

A. Seznam použitých zkratek SW Software HW Hardware UML Unified modeling language WAR Web application archive HTTP Hypertext transfer protocol HTML Hypertext markup language CSS Cascading style sheets XML Extensible markup language SSO Single sign-on SSZ Státní závěrečná zkouška ZP Závěrečná práce ZH Započítatelná hodina NZH Normovaná započítatelná hodina

92

PŘÍLOHA

Hvězdicové schéma databáze úvazky

93

B

B. Hvězdicové schéma databáze úvazky

d_nastav_semestr asem

f_predmet_pokr verze asem id_time kod m_stud m_hp m_hc m_hs m_hm m_ho m_hz m_uhpc m_uhcc m_uhsc m_uhmc m_uhoc m_uhzc



Characte
d_time id_time rok

d_verze verze datum_nahral

f_predmety_nar verze asem id_time kod m_zhp m_zhc m_zhs m_zho m_zhm m_kontaktni m_klasifikace podily_klasifikace m_garance m_projekty m_celkova katedra m_studentu format m_cena_stud_kred



varchar15 varchar Integer varchar 10 real real real real real real real Text real real real varchar 10 Integer varchar 10 real

Identifier_1

Identifier_1

pred verze Characters (15) <M> kod Characters (10) <M> Identifier_1

f_predmety_pokr verze asem rok kod m_pred_pokr m_pred_zbyva m_lab_pokr m_lab_zbyva m_pros_pokr m_pros_zbyva m_proc_pokr m_proc_zbyva m_prip_pokr m_prip_zbyva m_proj_pokr m_proj_zbyva m_p_proj_pokr m_p_proj_zbyva m_klas_pokr_zh m_klas_zbyva_zh klas_podil_sem_zkou klas_sumy_pokryto katedra



varchar15 varchar Integer varchar10 real real real real real real real real real real real real real double precision real real varchar varchar varchar

uci verze Characters (15) <M> kod Characters (10) <M> uname Characters (20) <M> Identifier_1 ucitel verze varchar 15 <M> uname <M> Identifier_1

Tabulky d_nastav_semestr, d_time a d_verze vyjadruji synteticky dimenze casu a verze, kvuli oddeleni jednotlivych dat

Identifier_1

1/2

Obrázek B.1: Hvězdicové schéma databáze úvazky (zdroj [9]).

94

<M> <M> <M> <M>

f_ucitele_vykon verze asem id_time uname pomer m_uvazek m_zap_hod_sem katedra uci_a_zkousi komise oponentury_a_vv vedeni_doktorandu repre_extra



varchar15 varchar Integer varchar 20 varchar 10 real real varchar 10 varchar varchar varchar varchar varchar

Cislice 2 na konci nazvu tabulky je pridam kvuli duplikace a zlepseni prehlednosti schematu. Fyzicka jsou tabluky jenom jedny

<M> <M> <M> <M>

Identifier_1 d_nastav_semestr2 asem

f_ucitel_vytizeni verze asem id_time uname uhp uhc uhs uhm uho uhz kl_sem_poc_pred_s_pod klas_zk_poc_pred_s_pod garance_poc_pred_s_podilem vpro pomer uvazek zap_hod_sem uci_a_zkousi



varchar 15 varchar Integer varchar 20 bigint bigint bigint bigint bigint bigint bigint bigint bigint bigint varchar 10 real real varchar

<M> <M> <M> <M>

Identifier_1 d_time2 id_time rok

d_verze2 verze datum_nahral

pred2

uci2

verze Characters (15) <M> kod Characters (10) <M>

verze Characters (15) <M> kod Characters (10) <M> uname Characters (20) <M>

Identifier_1

Identifier_1

ucitel2 verze varchar 15 <M> uname <M> Identifier_1

2/2

Obrázek B.2: Hvězdicové schéma databáze úvazky (zdroj [9]).

95

PŘÍLOHA

C

Schéma datové kostky pro report výkon učitele <Schema name="dwuvazky"> 97

C. Schéma datové kostky pro report výkon učitele <Measure name="ZH Count" column="m_zap_hod_sem" aggregator="sum" datatype="Numeric" /> <Measure name="Pomer" column="pomer" aggregator="count" datatype="String" /> <Measure name="Uvazek" column="m_uvazek" aggregator="sum" formatString="#,###" />

98

PŘÍLOHA

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD bin.............................adresář se spustitelnou formou portletu src impl ........................................ zdrojové kódy portletu thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce kucerad2_dp.pdf........................text práce ve formátu PDF 99

D

×

Report "Sem vložte zadání Vaší práce"

Your name

Email

Reason -Select Reason- Pornographic Defamatory Illegal/Unlawful Spam Other Terms Of Service Violation File a copyright complaint

Description

Close Send

×

Sign In

Email

Password

Remember me Forgot password?

Sign In

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close