Systém pro využívání metodiky Management of Business Informatics

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Diplomová práce Systém pro využívání metodiky Management of Business Informatics Bc. Michal Dobiáš Vedoucí práce: prof.ing. Jiří Voříšek, CSc. 7. května 2013

Poděkování Chtěl bych poděkovat profesoru Ing. Jiřímu Voříškovi, CSc. za to, že nám umožnil pracovat na tomto projektu, za to, že vedl naši práci a spolu s ním bych chtěl poděkovat i docentu Ing. Janu Pourovi, CSc. za spolupráci při konzultacích a podporu při realizaci diplomové práce. V neposlední řadě bych chtěl poděkovat kolegovi Bc. Ondřeji Kofroňovi za spolupráci na tomto projektu a koordinaci výsledného díla, které je výstupem našich prací.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 7. května 2013.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Michal Dobiáš. 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 Dobiáš, Michal. Systém pro využívání metodiky Management of Business Informatics. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract The goal of this work is to familiarize with widespread IT management methodologies like ITIL and COBIT and with the newly created methodology MBI, which has been developed at University of Economics in Prague. Another goal of this work is to examine the reasons that hinder companies from implementing enterprise IT management methodologies. Second part of the work is to create a system that will be used by companies that want to user MBI. The system will allow them to customize the model so it fits their needs. Keywords Enterprise IT management, IT mangement methodologies, ITIL, COBIT, MBI ix

Abstrakt Cílem práce je seznámit se s rozšířenými metodikami řízení IT jako jsou ITIL a COBIT a s nově vytvořenou metodikou MBI, která byla vyvinuta na VŠE. Spolu s metodikami je obsahem práce prozkoumání důvodů, které brání firmám tyto metodiky zavést do řízení IT. Druhou částí práce je vytvoření systému pro využívání metodiky MBI konkrétními firmami. Systém umožní uživatelům kopírovat přizpůsobovat si obsah metodiky tak, aby vyhovoval potřebám společnosti. Klíčová slova Řízení IT, metodiky řízení IT, ITIL, COBIT, MBI x

Obsah Úvod 1 1 Metodiky řízení IT 3 1.1 Metodika ITIL......................... 4 1.2 Norma ISO 20000........................ 7 1.3 Metodika COBIT........................ 8 1.4 Podniková informatika v praxi v České republice....... 10 2 Metodika MBI 13 2.1 Faktory ovlivňující vývoj MBI................. 13 2.2 Cíl metodiky.......................... 14 2.3 Struktura MBI......................... 15 2.4 Srovnání s metodikami ITIL a COBIT............ 21 2.5 Způsob využití metodiky.................... 21 2.6 Verze MBI a budoucí vývoj.................. 23 3 Implementace systému pro využívání metodiky 25 3.1 Analýza a návrh......................... 25 3.2 Volba platformy......................... 33 3.3 Životní cyklus požadavku v aplikaci.............. 37 4 Realizace 41 4.1 Platform specific model..................... 41 4.2 Vygenerování základu aplikace................. 46 4.3 Návrh uživatelského rozhraní.................. 46 4.4 Průběh realizace........................ 47 4.5 Zabezpečení........................... 54 xi

5 Testování 59 6 Zátěžové testování 61 Závěr 63 Literatura 65 A Seznam použitých zkratek 67 B Obsah přiloženého CD 69 xii

Seznam obrázků 1.1 Statistika využití metodiky ITIL................. 11 1.2 Míra definování procesů v závislosti na velikosti podniku.... 12 2.1 Metamodel MBI.......................... 16 3.1 Use case diagram pro vlastníka modelu.............. 28 3.2 Use case diagram pro uživatele.................. 28 3.3 Doménový model.......................... 30 3.4 Diagram nasazení.......................... 37 3.5 Životní cyklus požadavku v CakePHP.............. 38 4.1 Databázové schéma - část 1.................... 42 4.2 Databázové schéma - část 2.................... 43 4.3 Databázové schéma - část 3.................... 44 4.4 Databázové schéma - část 4.................... 45 4.5 Uživatelské rozhraní - hlavní stránka............... 47 4.6 Uživatelské rozhraní - rozdělení rozhraní............. 47 4.7 Ad hoc procházení generického modelu - výběr filtru...... 48 4.8 Ad hoc procházení generického modelu - výsledek vyhledávání. 49 4.9 Vytváření podnikového modelu.................. 50 4.10 Proces vytváření podnikového modelu.............. 51 4.11 Stránka s výpisem úloh v podnikové modelu........... 53 4.12 Editace objektu z podnikového modelu.............. 54 xiii

Seznam tabulek 6.1 Benchmark - vytváření podnikového modelu........... 62 6.2 Benchmark - listování úloh..................... 62 xv

Úvod Metodiky řízení IT poskytují firmám prostředek, jak se vyhnout chybám, které už za ně udělali ostatní a nejen to, nabízí i nejlepší známá řešení daných problémů. Na trhu existuje mnoho metodik řízení, avšak stále si nedokázaly i přes svůj prokazatelný přínos najít cestu ke značné části společností. Katedra informačních technologií VŠE provedla v minulosti sadu průzkumů s cílem zjistit, proč tomu tak je. Jak bylo zjištěno - častou překážkou bývají zdroje, konkrétně jejich nedostatek, a to ať už finančních či personálních, a to platí hlavně pro malé a střední firmy. Metodika MBI, která byla vyvinuta na VŠE, se snaží být řešením tohoto problému a působit jako dostupná metodika řízení IT, která je navíc dostatečně flexibilní, aby po přizpůsobení přesně vyhovovala prakticky každému podniku. Metodika ve své první verzi vyvolala již zájem některých společností, avšak stále je ve fázi vývoje a jedním z plánovaných rozšíření je systém, který umožní vývoj a využití metodiky MBI v praxi. Vytvoření tohoto systému je předmětem této práce. Systém slouží dvěma hlavním účelům, konkrétně usnadní autorům rozvoj metodiky. Druhá část systému je určena pro koncové uživatele a poslouží jako nástroj pro pohodlné používání a přizpůsobování tohoto metodologického rámce. Práce je koordinována s prací Bc. Ondřeje Kofroně, a to takovým způsobem, že analýza a návrh systému probíhá v součinnosti, zatímco implementaci svých částí realizujeme samostatně. Má část práce se týká rozhraní pro koncové uživatele, díky němuž bude možné s metodikou pracovat na uživatelské úrovni. 1

Kapitola 1 Metodiky řízení IT Společným cílem metodik pro řízení IT je nastínit best-practice řešení problémů, které se často objevují v oblasti řízení IT. Metodiky staví na praktických poznatcích kumulovaných napříč různými firmami Z rozličných odvětví a hledají nejlepší řešení problémů, před které jsou manažeři často stavěni. Některé metodiky se zaměřují pouze na některé sektory řízení IT, některé se snaží obsáhnout všechny oblasti. Dalším rozdílem mezi metodikami je například zaměření metodiky podle velikosti podniku, který se metodikou má řídit. Existují například metodiky, jejichž využitelnost pro malé podniky je prakticky nulová, ale existují i metodiky, které jsou vhodné pro libovolně velký podnik. Mezi nejčastěji zmiňované metodiky patří ITIL, COBIT. U těchto metodik je patrný výše zmiňovaný rozdíl v zaměření, kde ITIL se zaměřuje zejména na IT služby a je vhodný pro libovolně velký podnik, kdežto CO- BIT se snaží postihnout všechny aspekty řízení informatiky. Jednotlivé metodiky budou rozebrány podrobněji v kapitolách jim přímo věnovaných. Při vyhledávání informací o řízení IT je možné také často narazit na další rozšířené metodiky a standardy, jejichž obsah není předmětem této práce, pro úplnost je však vhodné některé z nich vyjmenovat. Mimo ITIL a COBIT do této skupiny patří: Normy pro IT service management ISO 20000-1 ISO 20000-2 CMMI - Capability Maturity Model Integration Standardy vymezujíc procesy v IT governance - ISO/IEC 38500 3

1. Metodiky řízení IT TOGAF Zachman Framework Procesy životního cyklu software - ISO/IEC 12207 Metodiky pro řízení projektů jako PRINCE2, PRiSM, PMBOK, apod. Standardy týkající se informační bezpečnosti ISO/IEC 27001 ISO/IEC 27002 ISO/IEC 27003 ISO/IEC 27004 Standardy pro řízení kvality ISO 9000 ISO 9001 ISO 9004 1.1 Metodika ITIL Metodika ITIL 1 je produktem britského úřadu OGC 2 (v té době původně CCTA 3 ), který byl vládou pověřen k vytvoření frameworku pro návrh a užívání IT služeb, a to z důvodu, že kvalita vládě dodávaných služeb nebyla dostatečná. První verze frameworku byla vydána v 80. letech minulého století a tato verze se postupem času rozrostla až na 30 knih zabývajících se různými částmi životního cyklu IT služeb. Mnoho firem ITIL přijalo a tato metodika se rychle rozšiřovala i mimo vládní sektor. V roce 2001 došlo k revizi a restrukturalizaci obsahu, což vedlo k vydání ITIL verze 2, který členil informace do 8 kategorizovaných knih. Vydání nové verze vedlo k další popularizaci metodiky. Zatím nejnovější verze nese pořadové číslo 3 - byla vydána v roce 2007 a aktualizována o 4 roky později, v roce 2011. Nyní ITIL čítá 5 knih, a to konkrétně: 1 IT Infrastructure Library 2 Office of Government Commerce 3 The Central Computer and Telecommunications Agency 4

1.1. Metodika ITIL Service Strategy Service Design Service Transition Service Operation Continual Service Improvement Knihy popisují celý životní cyklus IT služby a každá z nich se zaobírá jednou oblastí tohoto cyklu. 1.1.1 Service Strategy První knihou ITIL v3 je Service Strategy [12], která radí, jak správně zvolit strategii. Mezi základní kroky zmiňované v této knize patří zjištění zákazníkových potřeb a zmapování trhu. Výstupem je ve stručnosti znalost toho, jaké služby bude organizace poskytovat a jaké schopnosti musí vyvinout či zlepšit. Hlavním cílem je přimět organizaci myslet a jednat strategicky a na základě toho stavět portfolio poskytovaných služeb. 1.1.2 Service Design Kniha Service Design [10] shrnuje doporučení pro fázi návrhu služeb, a to se týká jak služeb nových, tak úprav stávajících, tak, aby plnily potřeby zákazníků a zároveň byly říditelné a přínosné. Mezi hlavní cíle popisované v této knize je správa portfolia služeb, které zákazníkovi přinesou hodnotu, řešení dostupnosti IT služeb, řízení kapacity IT služeb, řizení nepřetržité dodávky služeb, řízení úrovně služeb prostřednictvím SLA 4, zajištění bezpečnosti služeb a řízení dodavatelů poskytujících službu. 1.1.3 Service Transition Třetím krokem životního cyklu IT služby je její přenesení do ostrého provozu [13]. V rámci této knihy je popsáno, co je třeba zajistit před zveřejněním služby, jak nakládat se změnami, ověřovat správnou funkci služeb a jak spravovat informace společnosti. Dále kniha doporučuje připravit se na různé situace, které mohou nastat při provozování služby a nastavit správu nasazování služeb do ostrého provozu. 4 Service Level Agreement - smlouva, která zajišťuje, že služba bude provozována za předem daných podmínek ve sjednané kvalitě a dostupnosti 5

1. Metodiky řízení IT 1.1.4 Service Operation Svazek číslo 4 [11] se zaměřuje na období, kdy je již služba v provozu a hlavním cílem doporučení v této knize je provozovat službu správně a udržet ji v provozu. Organizace řídící se těmito doporučeními by měla zajistit stabilitu služby, optimalizovat služby jak z pohledu nákladů, tak kvality a dokáže se připravit na neočekávané situace. Součástí těchto doporučení je například funkce service desk, podle které by měli klienti mít možnost kontaktovat provozovatele služby s připomínkami a požadavky týkajícími se dané služby. Provozovatel by měl míst nastaveny procesy, které popisují, jak s touto zpětnou vazbou naloží. 1.1.5 Continual Service Improvement Poslední kniha aktuální verze knihovny ITIL [9] obsahuje sadu doporučení, jejichž hlavním cílem je pokračovat ve vylepšování služby i po tom, co je plně v provozu. Doporučení jsou rozdělena na 4 hlavní procesy: Service review - cílem tohoto procesu je pravidelně zkoumat službu a hledat oblasti, ve kterých by se dala zlepšit, Process evaluation - formální ohodnocení procesů souvisejících s poskytováním služeb, kdy se vyhodnocuje splněný metrik, benchmarky a v případě nutnosti se provádí audity, Definition of CSI 5 - definování činností, které vedou ke zlepšení služeb a procesů založené na výsledcích předchozích 2 procesů service review a process evaluation, Monitoring of CSI initiatives - cílem tohoto procesu je ověřit, zda jdou vylepšení podle původního plánu a pokud tomu tak není, tak podniknout příslušné kroky k nápravě. V případě implementace ITILu se společnost může rozhodnout, že využije pouze některé části z rozsáhlé sady doporučení pro zlepšení svých procesů, jelikož ostatní části nemusí být pro daný typ podniku vhodné. Kvůli tomuto faktu se neprovádí certifikace společností na soulad s knihovnou ITIL. V případě nutnosti získat certifikaci blízkou souladu s ITILem je možnost využít normy ISO 20000. 5 Continual Service Improvement 6

1.2. Norma ISO 20000 1.2 Norma ISO 20000 Normy ISO/IEC 20000 jsou standardem pro řízení IT služeb, které jsou silně spjaty s ITILem a řeší absenci možnosti certifikace na řízení IT služeb. Norma specifikuje provozovateli požadavky na plánování, vytváření, implementaci, provoz, monitorování, přezkoumání, udržení a vylepšování IT služeb. Jak je vidět, i zde je velká podobnost s ITILem, a to je jen podtrženo faktem, že sledování praktik definovaných v ITILu je nejlepší cestou k získání certifikace ISO 20000. Norma je cílena jak na společnosti, které poptávají IT služby, jelikož jim zajišťuje, že certifikovaná společnost bude poskytovat služby na dostatečné úrovni kvality, tak na dodavatele služeb, kteří pomocí této certifikace mohou prokázat, že jejich služby jsou opravdu dostatečně kvalitní a jejich monitorování a rozvoji je věnováno dostatečné úsilí. Celkem se norma skládá z 5 částí a 3 další jsou v současnosti připravovány: ISO/IEC 20000-1:2011 Information technology Service management - Part 1: Service management system requirements - definuje požadavky na systém řízení IT služeb. Na základě shody s požadavky je možné provádět certifikaci. ISO/IEC 20000-2:2012 Information technology Service management - Part 2: Guidance on the application of service management systems - obsahuje pokyny a doporučení pro použití systému řízení IT služeb. ISO/IEC 20000-3:2009 Information technology Service management Part 3:Guidance on scope definition and applicability of ISO/IEC 20000-1 - tato norma poskytuje návod, jak aplikovat normu ISO 20000:1 a ukazuje příklady shody s normou. Tato část doplňuje druhou část normy a obsahuje spíše konkrétní příklady. ISO/IEC 20000-4:2010 Information technology Service management Part 4:Process reference model - specifikace referenčního modelu. ISO/IEC 20000-5:2010 Information technology Service management Part 5:Exemplar implementation plan for ISO/IEC 20000-1 - Ukázková implementace systému pro správu IT služeb, která vyhovuje ISO 20000-1. ISO/IEC 20000-7: Application of ISO/IEC 20000-1 to the cloud - Tento standard podává návod, jak aplikovat ISO 20000-1 v prostředí cloudu. V současnosti připravováno. 7

1. Metodiky řízení IT ISO/IEC 20000-10: Concepts and terminology for ISO/IEC 20000-1 - Detailní popis konceptu a terminologie ISO 20000-1. V současnosti připravováno. ISO/IEC 20000-11: Guidance on the relationship between ISO/IEC 20000-1 and related frameworks - Tato technická zpráva definuje vztah mezi ISO 20000-1 a ITILem, případně dalšími obdobnými metodikami. V současnosti připravováno. 1.3 Metodika COBIT Metodika COBIT 6 byla vytvořena organizací ISACA 7 a dnes je distribuována ve verzi s označením COBIT 5 [3]. Tato metodika se zaměřuje na popis sady procesů, návodů, cílů, hodnocení, nejlepších praktik a ukazatelů s cílem maximalizovat využití informačních technologií při dosahování podnikových cílů. 1.3.1 Historie První verze vydaná v roce 1996 obsahovala pouze framework pro řízení podnikové informatiky. Při tvorbě COBITu vycházela ISACA z mezinárodních standardů a rozsáhlých zkušeností s řízením IT a auditorskou činností. Druhé vydání, které vyšlo o 2 roky později bylo obohaceno o auditorské postupy (audit guidelines), implementační nástroje (implementation toolset) a kontrolní cíle (control objectives). Dvouletý interval byl dodržen i mezi druhým a třetím vydáním, které bylo vydáno roku 2000. Novinkou ve třetím vydání byla část zabávající se manažerskými postupy (management guidelines) a přepracování se dočkala část týkající se řízení podnikové informatiky. Čekání na čtvrté vydání zkrátilo v roce 2003 zpřístupnění online verze, na samotnou čtvrtou verzi se však muselo čekat až do roku 2005. Následující dva roky práce přinesly revizi čtvrtého vydání na verzi s označením 4.1. V této verzi se procesy v COBITu dělily do 4 domén: Plan and Organize, Acquire and Implement, Deliver and Support, 6 Control Objectives for Information and Related Technology 7 dříve známá Information Systems Audit and Control Association, dnes vystupuje pouze pod zkratkou ISACA 8

1.3. Metodika COBIT Monitor and Evaluate. Tato verze byl nejčastěji využívána pro audit systémů podnikové informatiky. 1.3.2 Současná verze Nejaktuálnější verze z roku 2012, COBIT 5, byla rozšířena a restrukturalizována tak, že nyní obsahuje 37 procesů rozdělených do 5 následujících domén (zdroj [5]): doména EDM (Evaluate, Direct and Monitor) zahrnuje procesy zaměřené na nastavení rámce pro IT governance a procesy zaměřené na dosažení efektů, optimalizaci rizik, zdrojů a řízení zúčastněných stran, doména APO (Align, Plan and Organise) obsahuje procesy zaměřené na plánování a řízení nákupů, obchodních vztahů a dodavatelů, řízení rizik, řízení IT strategie, řízení podnikové architektury, plánování programů, portfolií a projektů, řízení kvality, řízení bezpečnosti, doména BAI (Build, Acquire and Implement) se zaměřuje na budování a implementaci IT řešení, jedná se zejména o procesy pro správu uživatelských požadavků, návrh a realizaci IT řešení, řízení programů a projektů, řízení změn, správu aktiv a správu konfigurací, doména DSS (Deliver, Service and Support) obsahuje popis procesů zaměřených na dodávku IT řešení a následnou podporu jejich provozu, včetně řízení kontinuity, řízení bezpečnosti v oblasti provozu IT řešení, doména MEA (Monitor, Evaluate and Assess) se zaměřuje na monitorování, měření a posuzování souladu s externími požadavky, sledování a posuzování systému interních kontrol. Největšími posuny kupředu z pohledu verze 5 bylo zahrnutí IT governance, integrace dílčích standardů jako Val IT a Risk IT a stejně, jako tomu bylo u předcházející liché verze, přepracování pohledu na řízení IT, díky čemuž bylo možné využít metodiku pro výchozí nastavení procesů v oblasti řízení podnikové informatiky. 9

1. Metodiky řízení IT 1.4 Podniková informatika v praxi v České republice Cílem této kapitoly je identifikovat stav, v jakém se nachází řízení informatiky v ČR a zjistit, proč nejsou v množství případů využívány metodiky ITIL a COBIT. 1.4.1 Hlavní problémy v řízení informatiky Dodržování prověřených metodik je určitě správnou cestou, po které jít, avšak ne vždy se o společnosti snaží nebo k tomu pro ně existuje řada překážek, které jim v tom brání. Jak ukazuje výzkum provedený Katedrou informačních technologií Vysoké školy ekonomické v Praze v únoru roku 2012 na semináři ČSSI 8 [15], mezi nejzásadnější problémy v oblasti řízení informatiky z pohledu pracovníků konkrétních společností patří: Chybějící strategie informatiky, nedostatečné řízení nákladů na informatiku, chybějící katalog informatických služeb, orientace na strategické aplikace 9, sledování návratnosti investic, řízení personálních zdrojů pro rozvoj informatiky. Mezi další problémy v řízení podnikové informatiky, které byly v rámci daného výzkumu zjištěny, patří zejména nízká míra dokumentace procesů, či dokumentace bez dalšího využití (do těchto dvou kategorií spadá až 60 % podniků). 1.4.2 Využívání metodik ITIL a COBIT pro řízení podnikové informatiky v ČR Z obrázku 1.1 je patrné, že téměř polovina respondentů odpovídala záporně na otázku, zda využívají metodiku ITIL. Část respondentů využívala ně- 8 Česká společnost pro systémovou integraci 9 Strategickými aplikacemi jsou označovány ty aplikace, které rozhodujícím způsobem přispívají ke zvyšování konkurenceschopnosti podniku. Příkladem jsou ERP, Business intelligence či CRM systémy 10

1.4. Podniková informatika v praxi v České republice Obrázek 1.1: Využití metodiky ITIL v řízení informatiky [%], zdroj: [15] které její části, avšak komplexního využití se metodika dočkala pouze v 6 % případů. Co se týče metodiky COBIT, tak je situace ještě horší, konkrétně 53 % dotazovaných přiznalo, že metodiku nevyužívá vůbec a 12 % ji využívá pouze v oblasti strategického řízení, ostatní na tuto otázku neodpověděli, což je možné vysvětlit tak, že metodiku také nevyužívají. Mezi nejpravděpodobnější příčiny této situace patří relativně velká složitost metodik, velké nároky na čas a finance potřebné pro jejich implementaci, nutnost nastudovat rozsáhlou dokumentaci a v neposlední řadě jsou kladeny vysoké nároky na znalosti pracovníků. Vzhledem k těmto faktorům je pravděpodobnější, že spíše velké firmy budou tyto metodiky využívat, zatímco malé firmy budou mít větší problémy vyhradit potřebné zdroje na implementaci. Rozdíl ve využívání je možné vidět například na obrázku 1.2, který srovnává míru definování procesů podle velikosti podniku. Průzkum z roku 2006 [2] ukázal významnou závislost relativního počtu certifikovaných firem na velikosti podniku, kdy se mezi nejmenšími podniky mohlo pyšnit certifikací v oblasti řízení IT ani ne 18 % z nich, oproti tomu mezi firmami nad 25 zaměstnanců již byla více než polovina certifikována. Součástí průzkumu byla i snaha zjistit, proč je mezi malými podniky tak málo certifikovaných subjektů. Výsledky se neliší od předpokladů zmíněných 11

1. Metodiky řízení IT Obrázek 1.2: Míra definování procesů v závislosti na velikosti podniku [%], zdroj: [4] výše, kdy největší překážkou pro malé firmy jsou zdroje a složitost norem, pro než neexistuje dostatečně "jednoduchý"návod na jejich implementaci. Většina z těchto podniků však zájem o certifikaci má, avšak zmíněné bariéry jim k tomu blokují cestu. 12

Kapitola 2 Metodika MBI Nově vznikající metodika MBI 10 má být odpovědí na problémy zmiňované v předchozí kapitole. Hlavním cílem, který si autoři kladli při vytváření metodiky bylo zvýšit využití metodik řízení IT v praxi, přičemž se metodika zaměřuje hlavně na malé a střední firmy, které se s těmito problémy potýkají nejvíce a které mají, ač často nechtěně, k metodikám a certifikacím cestu uzavřenou, a to nejvíce svými časovými a finančními omezeními. Metodika MBI je součástí metodiky MMDIS 11 vyvinuté KIT VŠE 12 v Praze. 2.1 Faktory ovlivňující vývoj MBI Návrh metodiky vychází z rozsáhlých analýz a průzkumů. Jednou z hlavních otázek, které vyvstaly před samotnou tvorbou modelu, bylo, zda by se měla metodika ubírat směrem k univerzálně platnému modelu či zda respektovat fakt, že se podniky z různých odvětví různých velikostí mohou lišit i co do požadavků na řízení IT. Na základě výzkumů KIT VŠE, jak vlastních, tak cizích, bylo zjištěno, že by podoba modelu řízení měla být závislá na podniku samotném a že i například dva podniky ze stejného odvětví, které jsou stejně velké, mohou mít naprosto odlišné požadavky na model řízení IT. O nalezení či vytvoření řešení pro daný podnik by se měl starat CIO 13 spolu se svým týmem, jelikož je z pohledu řízení IT nejkompetentnější osobou, respektive skupinou lidí ve společnosti. 10 Management of Business Informatics 11 Multidimensional Management and Design of Information Systems 12 Katedra informačních technologií Vysoké školy ekonomické 13 Chief Information Officer 13

2. Metodika MBI Mezi faktory, které byly brány v potaz při vývoji metodiky patří například: Faktory společné všem podnikům: stav hospodářského prostředí, stav legislativy, situace na IT trhu, aktuální úroveň znalostí IT komunity. Faktory specifické pro jednotlivé podniky: význam IT pro daný sektor, význam IT pro realizaci cílů podniku, velikost podniku, rozdělení kompetencí a pravomocí v řízení informatiky, zvolený typ IT strategie, zaměření IT služeb, náležitost podniku do soukromého či veřejného sektoru, počet zaměstnanců a uživatelů IS a úroveň jejich znalostí, rozsah a úroveň outsourcingu, podniková kultura. 2.2 Cíl metodiky Hlavním cílem metodiky bylo poskytnout řídícím pracovníkům IT metodický rámec, který by mohli jednoduše využívat pro řízení podnikové informatiky. Tento rámec si zakládá na tzv. best practices 14. Důležitým faktem, který je třeba zmínit je ten, že metodika se nezaměřuje na podniky, jejichž hlavním předmětem podnikání je IT jako takové, a to hlavně z důvodu, že řízení IT v těchto společnostech funguje na jiné, jednodušší, bázi, kdy je jejich cílem udržovat pouze takové služby, které přinášejí zisk. Pro ostatní společnosti může být nutné udržovat služby, které jsou nutné pro dosažení vlastních business cílů. Hlavní přínos modelu vidí autoři v následujících oblastech, které usnadňují nebo pomáhají řízení podnikové informatiky: 14 Nejlepší známá řešení, která byla ověřena v praxi 14

2.3. Struktura MBI zaznamenávání a dokumentace v podniku implementovaného systému řízení podnikové informatiky, návrh a implementace nového systému řízení IT, mapování jednotlivých částí systému řízení na mezinárodně uznávané metodiky, standardy a nejlepší praktiky využití best practice řešení konkrétních problémů Vzhledem k výše zmíněnému množství faktorů, které mohou být různé napříč jednotlivými podniky je nespornou výhodou možnost přizpůsobit model vlastním potřebám a využívat z něj jenom ty části, které zrovna ta která firma potřebuje, či si nejlepší praktiky definované v modelu upravit tak, jak to dané firmě bude vyhovovat nejvíce a vytvořit si tím pádem vlastní model řízení podnikové informatiky, který je založen na best practices, avšak zároveň je postaven přesně na míru danému podniku. Druhotným cílem metodiky je poskytnout budoucím manažerům přehled o tom, jak by mělo fungovat řízení informatiky a na jakých principech je založeno. 2.3 Struktura MBI 2.3.1 Úlohy Hlavním stavebním kamenem metodiky MBI jsou úlohy, jak je vidět na obrázku 2.1, které se pak vážou na řadu dalších entit a tvoří hlavní jednotku řízení podnikové informatiky. Úloha obsahuje popis, jak řešit nějakou konkrétní situaci, jako příklady mohou posloužit následující úlohy: U0001A - Plán řešení informační strategie, U011A - Vymezení subjektu, pro který se strategie zpracovává, a jeho významného okolí, U101A - Vytvoření a rozvoj katalogu služeb U221A - Analýzy stavu personálních zdrojů a jejich kvalifikace Každá entita v MBI má svůj unikátní identifikátor, u úloh je to v seznamu vypsaný identifikátor ve tvaru UxxxY, kde U označuje úlohu, xxx je číslo úlohy a Y zastupuje variantu úlohy. Varianty úlohy jsou v modelu 15

2. Metodika MBI Obrázek 2.1: Metamodel MBI 16

2.3. Struktura MBI obsaženy proto, že některé druhy společností se na stejnou úlohu mohou dívat jinak, případně se na ně vztahují například jiné legislativní požadavky a řešení pro ně může být odlišné. Je však zbytečné, aby do svého modelu přidávali úlohu, která je vhodným řešením daného problému pro jiný typ společnosti, když už ve svém modelu řešení daného problému mají a navíc takové, které jim vyhovuje nejvíce. Vzhledem ke značnému počtu úloh v modelu jsou pro lepší orientaci úlohy tříděny do dvouúrovňové hierarchické struktury. První úrovní dělení jsou domény řízení, které rozdělují úlohy podle toho, jaké části řízení IT se týkají. Mezi domény řízení patří: Strategické řízení, řízení informatických služeb, řízení informatických zdrojů, řízení ekonomiky podnikové informatiky, řízení rozvoje podnikové informatiky, řízení provozu podnikové informatiky. Domény řízení se dále dělí na skupiny úloh, které seskupují úlohy do společných kategorií. Jako příklad skupin úloh mohou posloužit následující skupiny spadající do domény řízení informatických zdrojů: Řízení datových zdrojů, řízení technologických zdrojů, řízení personálních zdrojů. 2.3.2 Další významné entity v MBI 2.3.2.1 Schéma úlohy a klíčové činnosti Pro každou úlohu platí, že může mít přiřazeno schéma, které znázorňuje postup, jak při plnění úlohy správně postupovat. Pokud je potřeba k jednotlivým krokům přidat detailnější popisy, je nutné vyplnit klíčové činnosti, což jsou kroky, jak již z jejich názvu vyplývá, které je třeba pro splnění úlohy učinit. 17

2. Metodika MBI 2.3.2.2 Role Role v MBI slouží ke znázornění zodpovědností týkajících se dané úlohy, konkrétně je využíváno RACI matice, která definuje různé druhy zodpovědností a míry účasti na splnění dané úlohy. 2.3.2.3 Dokumenty Častým vstupem či výstupem úloh bývají dokumenty. Například pro úlohu U105A Příprava a uzavírání SLA je vstupním dokumentem katalog služeb a výstupem je smlouva s konkrétním zákazníkem o poskytování některé ze služeb. 2.3.2.4 Metody Pod označením metoda se skrývá způsob, jakým můžeme dosáhnout kýženého cíle. Jedná se o osvědčené a formalizované postupy. 2.3.2.5 Referenční metodika a referenční proces Vazba úlohy na referenční metodiku a referenční proces umožňuje namapovat úlohy MBI na procesy ostatních metodik a standardů, jako například ITIL, COBIT, PRINCE2, ISO 20000. Každá z úloh MBI může obsahovat více vazeb na referenční procesy a metodiky a stejně tak je tomu i naopak, že jeden referenční proces (resp. metodika) může být vázán na více úloh MBI. Tato vazba je využitelná například při ověřování shody modelu MBI a referenční metodiky. 2.3.2.6 Critical Success Factors Klíčové faktory úspěchu, anglicky Critical Success Factors (CSF), definují, co je potřeba zajistit, aby bylo možné úlohu splnit. Mezi CSF může patřit: Podpora vrcholového vedení, zkušený vedoucí projektu, seznámení týmu s metodikou. 2.3.2.7 Praktiky Praktika definuje doporučení, které usnadní realizaci úlohy. V rámci každé úlohy může být navrženo více praktik, ale jejich dodržení není mandatorní. 18

2.3. Struktura MBI 2.3.2.8 Životní situace Vztah úlohy k nějaké životní situaci umožňuje na základě právě této životní situace získat seznam úloh, které nám pomohou danou situaci vyřešit. Konkrétně se může jednat například o životní situaci Je třeba snížit rozpočet na IT při zachování dosavadní úrovně služeb. 2.3.2.9 Vlastnosti informačního systému Na obdobném principu jako spojení úloh a životních situací funguje i napojení úloh na vlastnosti informačního systému. V případě, že je třeba ověřit nějakou vlastnost informačního systému, je možné si v modelu vyhledat jenom úlohy týkající se dané vlastnosti a zajistit jejich splnění. Mezi vlastnosti informačního systému popsané ve výchozím nastavení MBI jsou: Pokrytí požadované funkcionality dostupnost, včasnost, správnost a důvěryhodnost potřebných funkcí a informací soulad s legislativou uživatelská přívětivost bezpečnost, flexibilita, otevřenost, integrita, standardizace, výkonnost, efektivita. 2.3.2.10 Objekty řízení Další kritérium k vyhledávání úloh zastupují objekty řízení, což jsou objekty podnikové informatiky či objekty podniku. Mezi objekty podnikové informatiky patří: ICT služby, 19

2. Metodika MBI ICT procesy, ICT zdroje: aplikace (ASW), technologické zdroje (ZSW, HW, komunikační infrastruktura), datové zdroje, finanční zdroje, personální zdroje ICT útvaru a znalosti, organizace ICT útvaru, pravidla řízení podnikové informatiky, ICT projekty. Mezi objekty podniku můžeme zahrnout: podnikové procesy, podnikovou organizaci, podnikové směrnice a pravidla, externí partnery, můžeme také hovořit o marketingovém mikroprostředí, rozvojové projekty podniku. 2.3.2.11 Metriky a dimenze Aby bylo možné nějakým formálním způsobem měřit míru dosažení cíle úlohy, byly do modelu zapojeny i metriky. Každá metrika může v rámci úlohy vystupovat jako KGI 15 či KPI 16, případně nemusí být ani KGI ani KPI. Metriky označené jako KGI vyjadřují míru dosažení cíle úlohy, zatímco KPI metriky měří kvalitativní a kvantitativní parametry úlohy. V případě metrik je možné definovat i IT podpůrné aplikace, které slouží k měření dané metriky. Těsně k metrikám se váží dimenze, které reprezentují analytická hlediska pro identifikaci a hodnocení sledovaných ukazatelů. 15 Key goal indicator 16 Key performance indicator 20

2.4. Srovnání s metodikami ITIL a COBIT 2.3.2.12 IT podpůrné aplikace Mimo použití podpůrných aplikací pro měření metrik je možné pro úlohu definovat aplikace, které úloha používá pro splnění svého cíle. 2.3.2.13 Charakteristika podniku a profil Velmi důležitou součástí modelu je i charakteristika podniku a jeho profil, na jejichž základě je pro podnik vytvořen prvotní model, který je potom dále přizpůsobován. Toto však platí pouze pro použití modelu popsané v sekci 2.5.2. 2.4 Srovnání s metodikami ITIL a COBIT Nemělo by smysl vyvíjet metodiku, která by se z velké části podobala zavedeným metodikám jako ITIL a COBIT. I když z těchto metodik MBI čerpá podklady a často mapuje své prvky právě na tyto metodiky, existují zásadní odlišnosti, které by měly v konečném důsledku znamenat větší adaptabilitu MBI ve srovnání s ITIL a COBIT, a to zejména v oblasti SMB 17. Tyto podniky s menším počtem zaměstnanců charakterizuje hlavně jejich rozmanitost, kterou MBI respektuje a bere v potaz, že každý podnik má jiné požadavky a tím pádem neexistuje jeden obecně platný model. S tímto souvisí i to, že MBI respektuje oproti velkým podnikům širší pravomoce a zodpovědnosti jednotlivých zaměstnanců v SMB, takže zodpovědnosti za vykonávání úloh z modelu řízení si může každá organizace nastavit sama. Mezi hlavními znaky, kterými se MBI odlišuje, jsou: Zaměření na SMB, součástí užívání modelu je přizpůsobení specifickým podmínkám daného podniku, základ modelu vychází z přesně definovaného metamodelu2.1, jednotlivé prvky jsou mapovány na vybrané metodiky a standardy. 2.5 Způsob využití metodiky Pokud se organizace rozhodne využívat metodiku MBI má k tomu připraveny dva způsoby použití. První možností je využití modelu tzv. Ad hoc, 17 Small and medium sized businesses neboli malé a střední firmy 21

2. Metodika MBI tato možnost je cílena spíše na menší podniky a druhá varianta zahrnuje vytvoření modelu na míru danému podniku. 2.5.1 Ad hoc využití Často se stává, že podnik potřebuje vyřešit jeden konkrétní problém, vylepšit jeden aspekt podnikové informatiky a nemá zájem či prostředky na to procházet komplexní metodiky a hledat nejlepší řešení jeho konkrétní situace. Pro tento případ umožňuje metodika ad hoc využití, díky kterému si uživatel může vyfiltrovat úlohy z generického, které jsou pro něj v tu chvíli důležité. Filtrování je možné na základě následujících 4 faktorů: Životní situace, objekt řízení, vlastnost informačního systému, typ podniku. Zvolením příslušných filtrů je možné ihned získat seznam úloh, které řeší situaci, kdy v podniku náklady na informatiku přesahují povolený rozpočet. Pokud uživatel navíc zvolí objekt řízení aplikace ASW, Efektivitu jako vlastnost IS a svůj obor podnikání, například Bankovnictví, dostane seznam úloh, které radí, jak snížit náklady na informatiku pomocí úprav aplikačního software a které budou vést ke zvýšení efektivity využívání tohoto software. Vše bude mít navíc seřazeno podle vhodnosti pro společnosti podnikající v bankovnictví. Tento unikátní nástroj dodává metodice nesrovnatelnou výhodu v jednoduchosti používání oproti ostatním metodikám, a to hlavně proto, že nároky na znalosti uživatele metodiky jsou prakticky nulové. Uživateli stačí k užívání metodiky vědět jen jedinou věc, a tou je problém, který chce aktuálně vyřešit. 2.5.2 Vytvoření podnikového modelu Pro větší podniky, či podniky, které mají zájem o striktnější definici podnikových procesů je zde možnost vytvořit si vlastní podnikový model. Proces funguje tak, že si uživatel - vlastník modelu (detailní popis role je k nalezení v sekci 3.1.4.2) - při vytváření účtu zadá údaje o podniku, konkrétně obor podnikání a počet zaměstnanců. 22

2.6. Verze MBI a budoucí vývoj Následuje krok, kdy je třeba vytvořit podnikový model. Při vytváření modelu je nejdříve uživateli předvybrána sada úloh, které jsou vhodné pro jeho typ podniku. Tato sada úloh, společně s přidruženými objekty, je nazývána specifickým modelem 18. Dalším krokem je přizpůsobení modelu, kdy uživatel ze specifického modelu odebere ty úlohy, které nepovažuje za důležité a může si naopak přidat ty úlohy z generického modelu, které by ve svém modelu chtěl mít a nebyly zařazeny do specifického modelu. Po přizpůsobení je model již připraven k používání. Uživatel si může procházet úlohy rozdělené do skupin a domén a hlavním rozdílem mezi tímto a ad hoc přístupem je ten, že v případě podnikového modelu má uživatel možnost si editovat veškeré objekty svého modelu, mazat je, či vytvářet úplně nové, čímž vznikne unikátní model, který je vytvořen přímo na míru podniku, který však vychází z nejlepších praktik. 2.6 Verze MBI a budoucí vývoj Možnost vytváření podnikových modelů ve webové aplikaci je součástí až druhé verze metodiky. První verze metodiky vyšla knižně pod názvem Management podnikové informatiky [5]. V této verzi je zahrnut popis struktury modelu a seznam objektů, se kterými metodika pracuje spolu s obsahem klíčových objektů modelu. Druhá verze, jejích součástí je i výstup této práce, je plánována na první kvartál roku 2014. Mimo systému pro správu objektů MBI, který je výstupem práce Bc. Ondřeje Kofroně [6] a systému pro využívání metodiky pro koncové uživatele bude součástí další verze i doplnění objektů tak, aby model pokrýval všechny úlohy, které jsou aplikovatelné v SMB. Dále je v plánu aktualizace úloh ve skupině Řízení rozvoje služeb podnikové informatiky, a to hlavně s cílem držet si aktuální úlohy i pro nové trendy v IT jako jsou mobilní aplikace, cloud computing, BI či sociální sítě. O rok později, čili v prvním čtvrtletí roku 2015 by měla být podle plánu uvolněna třetí verze MBI, která bude obsahovat nově metodiku použití MBI jako nástroje pro audit systému řízení informatiky v podniku. Při vývoji této verze budou brány v potaz připomínky a návrhy uživatelů, které se objeví v průběhu provozu metodiky v první a druhé verzi. Předpokládá se, že v rámci třetí verze bude vytvořena sociální síť uživatelů MBI, která bude sloužit k dalšímu rozvoji metodiky. Uživatelé by si v ideálním případě měli vyměňovat zkušenosti s používáním metodiky a 18 Specifický model označuje model, který v sobě zahrnuje úlohy, které jsou pro dané odvětví nejvhodnější 23

2. Metodika MBI sdílet své modely, díky čemuž by docházelo ke zdokonalování modelu generického. Zároveň by takto bylo možné získat zpětnou vazbu od uživatelů k nejmodernějším trendům a vyvíjet model, který bude schopen podat nejlepší řešení aktuálních problémů. 24

Kapitola 3 Implementace systému pro využívání metodiky 3.1 Analýza a návrh Cílem této části je prozkoumat požadovanou funkcionalitu a identifikovat potencionální rizika, která by mohla mít negativní dopad na aplikaci v době implementace. Základem analýzy byla identifikace aktérů, kteří budou se systémem interagovat, identifikace veškerých datových struktur, se kterými se pracuje a hlavních interakcí mezi nimi. 3.1.1 Problémy tištěné verze metodik V případě tištěných verzí metodik mohou vznikat nesrovnalosti při úpravách objektů, a to zejména asociací. Když by například došlo ke změně názvu uživatelské role, bylo by třeba tuto změnu propagovat do všech úloh, ve kterých se vyskytuje, což může vést k opomenutí některých výskytů a tím pádem nepřesnosti modelu. Další nevýhodou, která se týká také aktualizace je to, že v případě vydání nové verze si uživatelé musí sehnat nový výtisk, chtějí-li mít vše aktuální. Mezi nejzávažnější nevýhody tištěných verzí však patří za prvé nízká možnost přizpůsobení metodiky a hlavně vyhledávání relevantních objektů. Všechny tyto problémy by měly být odstraněny se zavedením aplikace pro správu a užívání modelu, která je cílem této práce a práce kolegy Kofroně. 25

3. Implementace systému pro využívání metodiky 3.1.2 Funkční požadavky Požadavky na funkčnost aplikace vychází hlavně ze specifikace metodiky a dají se shrnout následujícími body: 26 Vytváření uživatelských účtů: registrace nového uživatele, vytvoření uživatele s přístupem k podnikovému modelu, který ho může pouze procházet. Ad hoc procházení generického modelu s filtrací podle: životních situací, objektů řízení, vlastností informačního systému. Ad hoc procházení generického modelu s možností řadit podle vhodnosti pro daný typ podniku Vytvoření podnikového modelu, které se skládá z: navržení specifického modelu, výběru výskytů úloh, které chce uživatel zařadit do svého modelu, kopírování generického modelu do modelu podnikového, úprava podnikového modelu s možností dodatečně přidat či odebrat úlohy. Úprava objektů v podnikovém modelu - vytváření, editace, mazání: úlohy (včetně entit na ně přímo navázaných jako CSF, Klíčové činnosti apod.), dokument, metriky, metody, životní situace, referenční procesy, role,

3.1. Analýza a návrh možnost sloučit role tak, že se v nové roli spojí přiřazení jejich zodpovědností objekty řízení, it aplikace, vlastnosti informačního systému. Procházení podnikového modelu, úlohy budou tříděny do domén a skupin úloh 3.1.3 Nefunkční požadavky systém a databáze musejí být navrženy tak, aby umožňovaly napojení administrační části aplikace, která je vyvíjena paralelně s touto prací, aplikaci bude možné provozovat na některém ze serverů zadavatele, krátká doba odezvy, pravidelné zálohování databáze a uložených souborů. 3.1.4 Role v systému 3.1.4.1 Nepřihlášený uživatel Uživatel, který není přihlášen v systému, má jenom velmi omezené možnosti - může si buď vytvořit nový účet a nebo se přihlásit k již existujícímu účtu. Veškerá ostatní funkcionalita aplikace je přístupná až po přihlášení. 3.1.4.2 Vlastník modelu Po úspěšné registraci vznikne nový účet, kde uživatel bude v roli vlastníka modelu. Nejdůležitější funkcionalitou je pro vlastníka modelu vytvoření podnikového modelu, který si poté může libovolně upravovat a přidávat další uživatele, kteří už mohou model pouze procházet. Dále má tento uživatel možnost spravovat veškeré objekty, se kterými se v podnikovém modelu pracuje, čili může vytvářet kompletně nové úlohy se vším potřebným. Další důležitou funkcí přístupnou vlastníkovi modelu je ad hoc procházení generického modelu. Veškeré možnosti uživatele znázorňuje use case diagram na obrázku 3.1. 27

3. Implementace systému pro využívání metodiky Obrázek 3.1: Use case diagram pro vlastníka modelu Obrázek 3.2: Use case diagram pro uživatele 3.1.4.3 Uživatel Poslední rolí, která se v uživatelské části vyskytuje je uživatel, kterého má vlastník modelu možnost vytvořit. Tento uživatel má velice omezené možnosti, a to konkrétně na procházení generického a podnikového modelu. Souhrn jeho povolených akcí vyobrazuje use case diagram na obrázku 3.2. 28

3.1. Analýza a návrh 3.1.5 Domény v systému Systém pracuje z velké části na základě metamodelu, který je součástí první verze MBI. Některé entity však musely být přizpůsobeny potřebám aplikace a některé entity byly z modelu odstraněny, jiné zase přidány. Současný doménový model je zobrazen na obrázku 3.3. Oproti původnímu modelu zde došlo k následujícím změnám: Odstraněné / nevyužité domény: Profil, Charakteristika, Hodnota charakteristiky, Hodnota vhodnosti profilu. Přidané domény: Company, User, Person, Document Group, Role Group, Technical Term, Model. Domény Profil, Charakteristika, Hodnota charakteristiky a Hodnota vhodnosti podniku byly odstraněny z toho důvodu, že v současném použití nemá takto složitá datová struktura smysl. Ze schůzek vyplynulo, že informace, které jsou potřebné pro využívání metodiky jsou pouze obor podnikání a počet zaměstnanců, což tedy jasně směřovalo k odstranění této struktury. Mezi přidanými entitami figuruje na prvním místě entita Company, která zastupuje výše zmíněné 4 objekty a slouží k uchování nutných informací o společnosti. V aplikaci je nutné rozlišovat, kdo je autorem úloh, kdo je vlastníkem modelu apod. a také který uživatel má přístup ke kterému modelu. Z tohoto důvodu bylo nutné zavést entitu která reprezentuje osobu, a tou byla entita User společně s doplňujícími informacemi, které zastupuje entita Person. Ze schůzek, na kterých se řešil obsah diplomové práce byl vznesen požadavek na zavedení skupin dokumentů a skupin rolí, a to hlavně z důvodu 29

3. Implementace systému pro využívání metodiky 30 Obrázek 3.3: Doménový model

3.1. Analýza a návrh lepší orientace v těchto objektech. Na základě toho byly do modelu zařazeny entity Document Group a Role Group. Mezi další požadavky, které vyplynuly ze schůzek patří zavedení terminologického slovníku, jehož cílem je zajistit, aby nedocházelo k nesouladu mezi pochopením pojmu a jeho pravým významem. Následují dvě položky, které se týkají modelů - Model a Model Type. Vzhledem ke značné podobnosti podnikového a generického modelu je rozumné pracovat s nimi jako s totožnými entitami, avšak je nutné mít způsob, jak je odlišit. Entita Model tedy reprezentuje celý model, který obsahuje úlohy, dokumenty, metriky, atd. a Model Type udává, zda se jedná o model podnikový či generický. 3.1.6 Kopírování modelu Velmi důležitou operací je pro uživatele kopírování úloh z generického modelu do modelu podnikového a z toho důvodu bylo nutné tuto operaci dobře promyslet a vybrat nejvhodnější řešení. Varianty, které se nabízí pro vytváření podnikového modelu: Podnikový model budou tvořit pouze vazby odkazující na objekty generického modelu, podnikový model bude vytvořen jako kopie objektů generického modelu, a to pouze pro objekty, které si uživatel vybral, ostatní objekty budou přebírány z generického modelu, podnikový model bude vytvořen jako kopie objektů generického modelu a pouze u vybraných bude nastaven příznak, že je uživatel uvidí. 3.1.6.1 Podnikový model budou tvořit pouze vazby odkazující na objekty generického modelu Realizace kopírování generického modelu způsobem, kdy jsou pouze vytvořeny vazby mezi nově vytvořeným podnikovým modelem a existujícími úlohami a dalšími objekty z generického modelu, by byla vhodná v případě, že by bylo cílem vytvořit podnikový model jen pro čtení. U takového modelu by nebylo možné přizpůsobovat si úlohy podle svého, model by působil vlastně jen jako vyfiltrovaná verze generického modelu. Výhodou by však na druhé straně byl fakt, že se úlohy aktualizují všem uživatelů poté, co budou upraveny administrátorem. Na konzultacích k projektu bylo dosaženo závěru, že je nutné, aby si uživatelé mohli přizpůsobovat svůj podnikový model, což samo o sobě tuto 31

3. Implementace systému pro využívání metodiky variantu znemožňuje a jako druhý argument proti zvolení této varianty byla dříve zmíněná výhoda, a to automatická aktualizace podnikového modelu při změně generického modelu. Ukázalo se, že změny v podnikovém modelu, které uživatel nemá pod kontrolou nejsou žádoucí, čili tato varianta je zcela jistě nepoužitelná. 3.1.6.2 Podnikový model bude vytvořen jako kopie objektů generického modelu, a to pouze pro objekty, které si uživatel vybral, ostatní objekty budou přebírány z generického modelu Další variantou řešení způsobu kopírování modelu je kopírování pouze vybrané části objektů a zbytek objektů by byl řešen vazbou na generický model. Výhodou této varianty je možnost editovat si objekty, které chceme a zároveň nechat aktualizovat objekty, které si vybereme. Na druhou stranu by se v modelu objevovaly i nově přidané objekty, což nemusí být žádoucí, chce-li mít nějaká společnost opravdu jednoduchý model, ve kterém by nemátly nepoužívané objekty. Navíc u existujících objektů by docházelo k aktualizaci, což může být výhoda, ale když uživatel bude očekávat nějaký objekt, se kterým ve svém podnikovém modelu pracoval delší dobu a poté se mu zničehonic tento objekt změnil. Je však otázkou, zda v tomto případě převažují výhody nad nevýhodami, ale to bude možné zjistit až za provozu na základě četnosti a rozsahu prováděných změn v objektech. Mezi nevýhody patří složitější implementace, kdy je třeba u každého objektu sledovat, ke kterému objektu se váže a na základě toho vybírat, zda budou prvky generického modelu, nebo v případě, že má uživatel tyto prvky zkopírované, tak místo nich ty uživatelovy. Stejně jako v předchozím případě se automatická aktualizace ukázala jako problémový faktor a bez automatické aktualizace se tato varianta z funkční stránky jeví stejně jako varianta následující, což vzhledem ke složitější implementaci znamená zamítnutí i této možnosti. 3.1.6.3 Podnikový model bude vytvořen jako kopie objektů generického modelu a pouze u vybraných bude nastaven příznak, že je uživatel uvidí Třetí varianta je tou, která byla nakonec zvolena - jedná se o variantu, kdy je při vytváření podnikového modelu vybrána sada úloh, které uživatel chce využívat. Po výběru úloh jsou zkopírovány jak všechny úlohy, tak všechny asociované objekty z generického modelu a u vybraných je nastaveno, že budou použity v podnikovém modelu. 32

3.2. Volba platformy Pokud bude mít uživatel později zájem o přidání dosud nepřidaných objektů, je možné jenom změnit nastavení u daných objektů, že jsou uživatelem vybrány a může s nimi pracovat. V případě, že by se objevil v budoucnu požadavek na možnost volitelné aktualizace - například přidání nových úloh, které v době vytváření nebyly součástí generického modelu - je možné jednoduše získat seznam úloh z generického modelu a zařadit nově vybrané do podnikového. 3.2 Volba platformy 3.2.1 Architektura aplikace Volba architektury vychází z požadavků na aplikaci, které by nebylo možné splnit, pokud by bylo použito architektury standalone desktopové aplikace 19, a to hlavně proto, že je třeba vždy pracovat s aktuálními daty. Jasnou volbou byla architektura klient-server, která se vyznačuje tím, že na straně uživatele je klientská část aplikace, která získává a posílá data jednomu či více serverům. V případě takto řešených aplikací je třeba vyřešit otázku, zda bude vhodným řešením tlustý nebo tenký klient. Tlustý klient je takový, který zná a vykonává veškerou logiku aplikace a komunikuje se serverem pouze s požadavky na data, která zpracuje a zase odešle zpět serveru. Hlavní nevýhodou tohoto řešení je nutnost instalovat aplikace na všechna zařízení, která mají systém využívat, což může být ve větších firmách velmi nákladné. Na druhou stranu bývá práce s tlustým klientem rychlejší, jelikož není třeba kvůli každé operaci komunikovat se serverem. Kromě nutnosti instalace aplikace na všechny stanice má obecně tlustý klient řadu dalších nevýhod, kterými jsou například: Vyšší HW nároky na straně klienta, vyšší nároky na přenosový kanál, složité aktualizace a opravy, nutnost vyvíjet klientskou aplikaci pro různé verze operačních systému a různý HW. Z pohledu aplikace pro využívání MBI není první bod moc relevantní, jelikož aplikace není nijak výpočetně ani paměťově náročná. Nároky na přenos 19 Aplikace, která nevyžaduje internetové připojení pro svůj provoz 33

3. Implementace systému pro využívání metodiky dat nejsou vysoké, čili tato položka také problémová není. Velkým problémem je však třetí bod v seznamu - aktualizace a opravy. Hlavním důvodem je to, že metodika je stále ve vývoji a tím pádem se očekává, že se řada aspektů jejího používání bude měnit, což bude znamenat častou nutnost měnit logiku aplikace a časté rozšiřování funkcionality. To ovšem vzhledem k nákladům na aktualizace software na všech stanicích není žádoucí. Tlustý klient má kromě nevýhod samozřejmě i řadu výhod, mezi nimiž je například možnost pracovat s aplikací bez připojení k internetu, či nižší HW nároky na server, avšak žádné z těchto kladných stránek nejsou v našem případě přínosné a tím pádem byla jasně zvolena alternativní možnost tenkého klienta. V případě tenkého klienta má uživatel na své straně prezentační vrstvu a veškeré logické operace s daty zajišťuje server, který uživateli dodá pouze výsledek operace. Nespornou výhodou této architektury je fakt, že k využívání aplikace stačí internetový prohlížeč, který je přítomný na každém počítači či tabletu a také na řadě mobilních telefonů, což znamená nulové náklady na instalaci aplikace, stejně tak je tomu i v případě aktualizací, které se projeví ihned všem klientům. Jedinou nevýhodou tenkého klienta je absence možnosti pracovat se systémem bez připojení k internetu. To ale v dnešní době poměrně irelevantní, jelikož je možné se připojit k internetu prakticky na každém rohu, a velké množství lidí je připojeno pomocí mobilního telefonu neustále. Výsledkem je, že systém poběží jako webová aplikace v prohlížeči. 3.2.2 Volba programovacího jazyka Pro realizaci systému byl zvolen programovací jazyk PHP, jedná se o jeden z nejrozšířenějších, ne-li nejrozšířenější, jazyk volený pro tvorbu webových aplikací. S vývojem aplikací v jazyce PHP mám již několikaleté zkušenosti, což byl také jeden z důvodů pro výběr tohoto jazyka. Spolu s programovacím jazykem jsme vybírali i framework, který pro vývoj aplikace zvolíme. Volba padla na framework CakePHP, se kterým mám jen kladné zkušenosti. Framework z různých testů ([1],[8],[7]) vychází jako jeden z pomalejších, avšak s přihlédnutím k očekávanému využití aplikace zpočátku řádově desítkami, maximálně stovkami uživatelů je tento fakt zanedbatelný a převládají výhody plynoucí z použití známého frameworku. Z vlastní zkušenosti však vím, že s frameworkem nebyl problém ani v aplikaci se stovkami tisíc unikátních uživatelů měsíčně - jednalo se o aplikaci pro server www.uschovna.cz, která sloužila uživatelům ke správě vlastních zásilek a administrátorům ke správě obsahu a nastavování serverů. 34

3.2. Volba platformy 3.2.2.1 CakePHP CakePHP je open-source MVC framework, který si klade za cíl co nejvíce urychlit vývoj webových aplikací. Vývoj tohoto frameworku je mimo jiné sponzorován i firmou Microsoft, což vypovídá o jeho potenciálu. V následujících odstavcích budou shrnuty vybrané vlastnosti frameworku, díky kterým se stal oblíbeným a často využívaným frameworkem. Každá webová aplikace musí nějakým způsobem řešit zabezpečení proti případnému útoku. CakePHP poskytuje komponentu, která chrání před různými druhy útoků či škodlivé činnosti. Více o bezpečnostních opatřeních poskytovaných frameworkem a využívaných v aplikaci je možné se dočíst v kapitole 4.5. Při tvorbě vizuální stránky aplikace je využit šablonovací systém, který je integrální součástí CakePHP a umožňuje mimo jiné například ukládat do mezipaměti kód jednotlivých view souborů, aby bylo dosaženo rychlejšího načítání stránek. Navíc je možné ukládat do cache například jen vybrané části stránky, díky čemuž je možné kombinovat cacheování s dynamickým obsahem. CakePHP disponuje vlastní implementací ORM 20, díky čemuž je kterákoliv aplikace nezávislá na tom, zda funguje na MySQL (verze 4 a vyšší), PostgreSQL, Microsoft SQL server či SQLite. V nové verzi CakePHP, ve verzi 3, je navíc v plánu přidání podpory pro další databázové stroje. Programátor nepíše SQL dorazy, které by byly specifické pro danou databázi, nýbrž každý model je vybaven sadou CRUD 21 operací u kterých framework sám rozhodne, jak je přeložit do jazyka vybrané databáze. Mocným nástrojem pro aplikace vyžadující velmi specifickou definici přístupových práv, který však při implementaci systému pro využívání MBI nebyl využit, je tzv. ACL 22. ACL umožňuje přidělovat oprávnění provádět akce na úrovni uživatelů či uživatelských skupin. Je tak možné definovat, kdo bude mít k jaké akci přístup a naopak kdo bude od dané akce zcela odstíněn. Validace formulářů byla vždy činností, která se napříč webovými aplikacemi opakovala stále dokola. CakePHP nabízí možnost, jak tuto činnost automatizovat a pomocí jednoduchých definic vytvořit komplexní validace. Za jednu z největších výhod frameworku považuji jeho preferenci konvencí před konfigurací, čímž je míněno to, že je pro aplikace doporučováno používat jistou sadu konvencí pro pojmenovávání tříd, souborů a databázových polí a tabulek. Dodržování těchto konvencí má hned dvě obrovské vý- 20 Objektově relační mapování 21 Create, Read, Update, Delete - základní sada operací pro správu objektů 22 Access Control List 35

3. Implementace systému pro využívání metodiky hody - první je to, že pokud se někdo cizí, kdo však již s CakePHP pracoval, dostane k aplikaci, kterou předtím neviděl, dokáže se rychle zorientovat a pochopit jak aplikace funguje a začít na ní rychleji pracovat. Druhou, častěji oceňovanou výhodou je možnost vygenerovat si kostru aplikace na základě návrhu databáze. Při dodržení konvencí si dokáže framework automaticky zjistit, jaké jsou vazby mezi různými objekty a podle toho připravit základ aplikace. V rámci zadání této práce se objevuje i požadavek na otestování aplikace. CakePHP využívá testovacího frameworku PHPUnit, který se, jak z názvu vyplývá, zaměřuje na provádění unit testů. Aplikace bude k ověření správné funkcionality využívat testů napsaných v tomto frameworku. Další neoddiskutovatelnou výhodou je rozsáhlá komunita vývojářů pracujících s CakePHP, díky čemuž je framework rychle rozvíjen a často je otázkou jen několika minut najít řešení nějakého problému, který se při implementaci vyskytne. 3.2.3 Volba databáze Pro uchovávání dat byla zvolena databáze MySQL, a to hlavně díky rozšíření a dostupnosti této databáze. S ohledem na předpokládanou nutnost vytvářet či editovat velké množství záznamů během jedné operace byl zvolen engine InnoDB, který podporuje transakce. Oproti netransakčnímu engine MyISAM vyžaduje InnoDB více diskového prostoru a ve výchozím nastavení trvají read operace na tomto engine déle, avšak InnoDB poskytuje spoustu výhod, které s přehledem vyváží zápory tohoto řešení. Mezi další nevýhody oproti MyISAM patří omezení limitu velikosti databáze na 64 TB v porovnání s 256 TB pro MyISAM, což však nejsou hodnoty, které by valnou většinu aplikací používajících libovolný z výše zmíněných engine používal jakkoliv omezovaly. Ve výčtu výhod InnoDB v porovnání s MyISAM nesmí chybět (zdroj [14]): podpora ACID 23 transakcí, ochrana proti ztrátě dat při pádu aplikace, 23 ACID - zkratka slov Atomicity, Consistency, Isolation a Durability. Toto označení pod sebou skrývá transakce, které jsou atomické - provedou se buďto kompletně nebo vůbec, zachovávají konzistenci dat - výsledkem každé transakce je databáze v konzistentním stavu, izolované - dokud není transakce odeslána příkazem commit, nikdo se k datům změněným v transakci nedostane. Poslední vlastnost udává, že data jsou po skončení transakce uložena a ani výpadek proudu nezpůsobí jejich ztrátu 36

3.3. Životní cyklus požadavku v aplikaci Obrázek 3.4: Diagram nasazení podpora cizích klíčů, při editaci záznamů je přidán zámek pouze na daný záznam (u MyI- SAM je zámek na celé tabulce), mnohem lepší škálovatelnost. Aplikace bude tedy postavena jako klient-server aplikace s tenkým klientem. Programována bude v PHP na frameworku CakePHP a pro uchování dat poslouží databáze MySQL. Na serveru bude běžet operační systém Linux a jako aplikační server poslouží Apache. Diagram nasazení v tomto případě vypadá velmi jednoduše a je znázorněn na obrázku 3.4. 3.3 Životní cyklus požadavku v aplikaci Aplikace bude využívat architekturu MVC, která rozděluje aplikaci do vrstev - model, view a controller, kde každá z těchto vrstev se stará pouze o záležitosti, které jí přísluší. Vrstva modelu zajišťuje správu dat, což v základním pojetí znamená čtení, ukládání a mazání. Controller se stará o byznys logiku aplikace a View definuje, jak bude aplikace vypadat. Jednotlivé vrstvy pracují nezávisle na sobě, což dovoluje v aplikaci vyměnit i celou vrstvu, aniž by byly ovlivněny zbývající dvě. Životní cyklus zpracování požadavku je k vidění na obrázku 3.5. V prvním kroku klient vyšle na server požadavek, adresa může být například www.example.com/tasks/list/1. Dispatcher požadavek přijme a nasměruje 37

3. Implementace systému pro využívání metodiky Obrázek 3.5: Životní cyklus požadavku v CakePHP na správný controller. Mezi controllerem a dispatcherem je možné si všimnout bloku s názvem Router, který definuje mapování vlastních url na jednotlivé akce. Výchozí nastavení CakePHP je takové, že adresa se skládá z následujících částí: doména spolu s adresářem, ve kterém aplikace běží - www.example.com, jméno controlleru - tasks, akce controlleru - list, volitelný libovolný počet parametrů - 1. V tomto případě by došlo k zavolání metody: TasksController::list(1); Router dovoluje definovat v adresách tzv. prefixy, které umožňují seskupovat akce a na základě prefixů je poté možné omezit používání akcí jenom pro administrátory, či jinou uživatelskou skupinu. Alternativní URL s admin prefixem pro akci z předchozího příkladu by bylo sestaveno takto: 38

3.3. Životní cyklus požadavku v aplikaci www.example.com/admin/tasks/list/1. V tomto případě však není volána akce list, nýbrž admin_list. Pomocí routeru je možné namapovat libovolnou URL adresu na akci, kterou si zvolíme. Router tyto URL rozluští a dalším krokem zpracování požadavku je zavolání příslušné metody controlleru. Metody controllerů, neboli akce, vykonávají byznys logiku aplikace. Šedý čtvereček v diagramu 3.5 reprezentuje tzv. callback metody, které se volají v různých okamžicích životního cyklu. Před voláním jakékoliv akce je volán callback beforefilter, což je nejčastěji využíváno pro kontrolu, zda je uživatel přihlášen. Pokud ne, je přesměrován na přihlašovací stránku a v ostatních případech se pokračuje na volání metody controlleru. Ve valné většině případů jsou z controlleru volány metody modelu, a to aby buď data uložily nebo načetly. Zde jsou opět připraveny callback funkce, první z nich, beforefind, umožňuje centralizovaně upravovat požadavky na získání dat z databáze. Druhá callback funkce, afterfind, je volána po získání dat z databáze a slouží k úpravě dat před tím, než se s nimi bude dále pracovat v controlleru. Dále jsou k dispozici ještě funkce beforesave, aftersave, beforedelete, afterdelete a další. Dalším krokem je poslání dat pro zobrazení do view. U čísla 7 je vidět obdélník znázorňující volání další callback funkce, tentokráte s název beforerender, která slouží k úpravě dat těsně před jejich vykreslením. Prezentační vrstva aplikace se skládá z různých komponent. Nejvyšší úrovní je Layout, což je část view, která definuje základní šablonu stránky, jako například rozložení elementů a obsahuje prvky, které jsou společné všem stránkám. Uvnitř jsou potom vykreslovány views, což jsou šablony, které jsou zpravidla přiřazeny nějaké akci a nesou stejné pojmenování jako daná akce. Poslední součástí view jsou tzv. elementy, které slouží jako způsob k vložení obsahu, který je používán na více místech, aby nebylo nutné psát stále dokola stejný kód. Příkladem může být například výpis posledních článků na blogu. Po připravení šablony následují dva callbacky, které umožňují volat akce buď v okamžiku po vyrenderování view souboru včetně vložených elementů a nebo po vyrenderování view i s layoutem a všemi elementy. Výsledek je nakonec odeslán zpět klientovi. 39

Kapitola 4 Realizace 4.1 Platform specific model Prvním krokem při vytváření aplikací v CakePHP bývá zpravidla vytvoření databázového schématu, a to podle konvencí, které jsou pro framework definovány. Pro pojmenovávání tabulek platí doporučení používat množná čísla s malými písmeny, čili tabulka pro uchování úloh je pojmenována tasks. U víceslovných názvů je k oddělení slov použito podtržítko, takže tabulka obsahující seznam procesů z referenčních metodik se jmenuje reference_processes. Pro vazební tabulky konvence praví používat jména obou modelů, mezi kterými je vazba, a to v abecedním pořadí a oddělené podtržítkem - příkladem je zde vazební tabulka mezi úlohami a referenčními procesy reference_processes_tasks. Další dvě doporučení se týkají sloupců v tabulce, konkrétně klíčů. Primární klíč by měl nést jméno id a všechny cizí klíče by měly být pojmenovávány názvem asociované tabulky ve tvaru podstatného jména v jednotném čísle s příponou _id. Opět konkrétní příklad, pro který poslouží cizí klíč s názvem task_group_id z tabulky tasks, který udává, do které skupiny úloh daná úloha patří. Výsledné schéma databáze je možné vidět na obrázcích 4.1, 4.2, 4.3 a 4.4. Schéma databáze bylo lehce zjednodušeno a rozděleno na 4 části, aby bylo možné se v něm orientovat. Zjednodušení se týká toho, že všechny tabulky, které mají sloupec state_id nemají v diagramech vazbu na tabulku state a stejně tak tomu je i pro tabulku mbimodel s výjimkou posledního diagramu, ve kterém tyto tabulky jsou i s příslušnými vazbami. Stav u objektů indikuje, v jaké fázi vytváření se objekt nachází, tyto stavy jsou využívány jen v administrační části, v uživatelské jsou všechny nově vytvořené a zkopírované objekty ve stavu OK, který udává, že s objektem je možné pracovat. Vazba na mbimodel říká, do kterého modelu daný objekt patří. V tabulce 41

4. Realizace Obrázek 4.1: Databázové schéma - část 1 mbimodels je implicitně vytvořen jeden model, který reprezentuje generický model. Schéma databáze bylo vytvářeno v programu MySQL Workbench, který umožňuje připojit se k databázi a vytvářený diagram reprezentující schéma databáze převést na změny v dané databázi. Jelikož CakePHP v současné verzi nepodporuje namespaces, bylo nutné přejmenovat tabulku models na mbimodels, a to z důvodu, že odpovídající třída by se jmenovala Model a došlo by ke konfliktu se třídou Model, která 42

4.1. Platform specific model Obrázek 4.2: Databázové schéma - část 2 43

4. Realizace Obrázek 4.3: Databázové schéma - část 3 je předkem všech tříd reprezentujících model v CakePHP. Tento problém řeší CakePHP v nové verzi, avšak u této verze ještě není známo, kdy bude uvolněna. Dalším rozšířením oproti doménovému modelu je zavedení uživatelských skupin, které umožňují rozlišovat uživatele a podle skupiny, do které patří uživateli povolit či zakázat vybrané akce. V systému figurují 4 uživatelské skupiny: 44 Administrátor, Editor, Vlastník modelu, Uživatel.

4.1. Platform specific model Obrázek 4.4: Databázové schéma - část 4 45

4. Realizace První dvě z těchto skupin opravňují uživatele k přístupu do administračního rozhraní, ve kterém se edituje generický model. Zbývající dvě role byly popsány v sekci 3.1.4. 4.2 Vygenerování základu aplikace Spolu s CakePHP je dodáván CLI 24 skript, který umožňuje vygenerovat soubory Modelu, View a Controllerů, které podporují základní operace jako vytváření, čtení, úpravy a mazání záznamů. Vygenerovaný kód je opravdu jen základem a pro drtivou většinu aplikací, stejně jako tomu bylo u aplikace pro využívání MBI, je třeba tento kód značně rozšířit, aby bylo dosaženo požadované funkcionality. Hlavním přínosem generování kódu je však generování souborů s definicí modelu, v nich jsou definovány vazby na ostatní třídy. Tato část aplikace byla poté editována jen minimálně, a to v případě, kdy bylo třeba přidat nějakou novou asociaci. Z akcí v controlleru nezůstala v původní podobě prakticky žádná, jelikož ve výchozím stavu neprobíhají například žádné kontroly přístupových práv a ve výchozím nastavení dotazy hledají i asociace, které nejsou potřeba a tím pádem je prováděno velké množství dotazů, což může vést ke zbytečnému zpomalení aplikace. 4.3 Návrh uživatelského rozhraní Uživatelské rozhraní je rozděleno na 2 hlavní části - horní menu, které slouží pro navigaci v rámci celé aplikace a hlavní část, která slouží k zobrazování informací relevantních k dané stránce. Hlavní stránka, kterou uživatel uvidí po vytvoření podnikového modelu či po kliknutí na logo MBI nebo odkaz Úvod v hlavním menu je k vidění na obrázku 4.5. Hlavní část se může dále dělit na dvě podoblasti, a to v případě editace objektů z podnikového modelu. V levé části se nachází navigace, která souvisí s daným modelem a v pravé už buďto výpis objektů či editační formulář. Rozdělení hlavní části je vidět na obrázku 4.6. 24 Command Line Interface - rozhraní příkazové řádky 46

4.4. Průběh realizace Obrázek 4.5: Uživatelské rozhraní - hlavní stránka Obrázek 4.6: Uživatelské rozhraní - rozdělení rozhraní 4.4 Průběh realizace 4.4.1 Vytváření uživatelských účtů Prvním požadavkem, který byl v aplikaci implementován, byla možnost vytvářet uživatelské účty, a to hlavně z toho důvodu, že by veškerá funkcionalita aplikace měla být přístupna pouze pro přihlášené uživatele. Pro zaregistrování je potřeba zadat jméno, příjmení, emailovou adresu, heslo a základní údaje o firmě jako název, obor podnikání a počet zaměstnanců. Po registraci je automaticky uživateli nastavena role vlastníka modelu, i když zatím žádný model vytvořen nemá. 47

4. Realizace Obrázek 4.7: Ad hoc procházení generického modelu - výběr filtru 4.4.2 Ad hoc prohledávání modelu Po možnosti vytvářet uživatelské účty byla do systému přidána funkcionalita umožňující prohledávat generický model. Prohledávání generického modelu ad hoc má sloužit uživatelům k vyhledávání konkrétních úloh podle několika kritérií. Formulář pro výběr kritérií obsahuje pouze základní výběr možností, podle kterých filtrovat a nic, co by dále uživatele mátlo, což je v souladu s cílem poskytnout co nejjednodušší možnost procházet model. Formulář pro výběr filtru je zobrazen na obrázku 4.7. Po odeslání formuláře je uživateli zobrazen seznam úloh, které vyhovují jeho dotazu a v případě, že byl zadán typ podniku, jsou tyto úlohy řazeny podle vhodnosti pro daný podnik. 4.4.3 Vytváření podnikového modelu Jako další přišlo na řadu vytváření podnikového modelu. Hlavním cílem podnikového modelu je dát společnosti možnost upravit si objekty generického modelu tak, aby přesně vyhovovaly potřebám jejich podniku. V případě, že uživatel ještě nemá vytvořen podnikový model, bude mít na hlavní stránce, která je mu zobrazena hned po přihlášení pouze 2 možné akce, a to buď procházení generického modelu ad hoc nebo vytvoření pod- 48

4.4. Průběh realizace Obrázek 4.8: Ad hoc procházení generického modelu - výsledek vyhledávání nikového modelu. Vybere-li si uživatel možnost vytváření podnikového modelu, dostane se na obrazovku obsahující seznam úloh roztříděných do domén a skupin úloh, viz obrázek 4.9. V horní části se nachází posuvník, který umožňuje nastavit rozsah úloh, které budou do podnikového modelu předvybrány. Předvýběr úloh funguje na základě definice vhodnosti úlohy pro typ a velikost podniku, kterou zadal uživatel během registrace. Při posunu posuvníku doleva bude předvybráno pouze menší množství úloh, avšak bude se jednat o klíčové úlohy, které by měl daný podnik řešit. Přesunutí posuvníku do zcela pravé pozice naopak označí úplně všechny úlohy modelu MBI. Po fázi automatického výběru úloh na základě vhodnosti a preference uživatele ohledně rozsahu modelu je poté možné dodatečně přidat či odebrat úlohy, u kterých si uživatel myslí, že jsou pro jeho podnik důležité, nebo naopak, mají pouze mizivý přínos. Výběr úloh je prováděn pomocí zaškrtávacího pole, které je přítomno vedle každé úlohy. Implementace se zde odlišuje od procesu popsaném v textu verze 1 [5], kde stojí, že se při vytváření podnikového modelu pracuje nejdříve s ge- 49