VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU DIPLOMOVÁ PRÁCE 2012 PETR PODANÝ

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU DIPLOMOVÁ PRÁCE 2012 PETR PODANÝ

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU Nárožní 2600/9a, 158 00 Praha 5 DIPLOMOVÁ PRÁCE MASTER OF BUSINESS ADMINISTRATION Vysoká škola ekonomie a managementu +420 841 133 166 / info@vsem.cz / www.vsem.cz

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU Nárožní 2600/9a, 158 00 Praha 5 NÁZEV DIPLOMOVÉ PRÁCE Metodický rámec ITIL a jeho implementace v prostředí BI Komerční banky TERMÍN UKONČENÍ STUDIA A OBHAJOBA (MĚSÍC/ROK) Červen / 2012 JMÉNO A PŘÍJMENÍ / STUDIJNÍ SKUPINA Ing. Petr Podaný / MBA 25 JMÉNO VEDOUCÍHO DIPLOMOVÉ PRÁCE Ing. Miroslav Lorenc PROHLÁŠENÍ STUDENTA Prohlašuji tímto, že jsem zadanou diplomovou práci na uvedené téma vypracoval samostatně a že jsem ke zpracování této diplomové práce použil pouze literární prameny v práci uvedené. Datum a místo: 30. dubna 2012, Praha podpis studenta PODĚKOVÁNÍ Rád bych tímto poděkoval vedoucímu diplomové práce, za metodické vedení a odborné konzultace, které mi poskytl při zpracování mé diplomové práce. Vysoká škola ekonomie a managementu +420 841 133 166 / info@vsem.cz / www.vsem.cz

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU Metodický rámec ITIL a jeho implementace v prostředí BI Komerční banky Implementation of ITIL methodology framework in BI Komercni banka Autor: Petr Podaný

Souhrn Diplomová práce formuluje soubor doporučení pro prostředí Business Intelligence Komerční banky, které při realizaci povedou k zefektivnění implementovaných procesů dle metodického rámce ITIL. Soubor doporučení je zobecněn i mimo prostředí Business Intelligence Komerční banky a může sloužit velkým a středním organizacím jako inspirace a ponaučení při implementaci ITIL procesů. Diplomová práce se zaměřuje na implementaci ITIL procesů v prostředí Komerční banky (velké finanční instituce), resp. oddělení Business Intelligence, kdy se zabývá jednotlivými procesy Help Desk, Requirement Management, Incident Management, Problem Management a Change Management. Hlavní přínos práce je 10 zoběcněných doporučení pro implementaci ITILu a 5 doporučení pro realizaci v prostředí Business Intelligence Komerční banky. Summary The thesis formulates a set of recommendations for the department of Business Intelligence at Komercni banka, which will lead to effective processes. The implemented processes are based on the ITIL best practices. A set of recommendations is also generalized and designed for large or medium organizations and it can be used as an inspiration and advice in case of new implementation of ITIL. The diploma work is concerned with implementation of ITIL processes in Business Intelligence at Komercni banka (large financial institution) and it deals with implementation process of Help Desk, Requirement Management, Incident Management, Problem Management and Change Management. The thesis formulates 10 generalized recommendations for implementation of ITIL and 5 recommendations focused on implementation of ITIL in the department of Business Intelligence at Komercni banka.

Klíčová slova: ITIL, Help Desk, Requirement Management, Incident Management, Problem Management, Change Management Keywords: ITIL, Help Desk, Requirement Management, Incident Management, Problem Management, Change Management JEL Classification: M150 - IT Management

Obsah 1 Úvod... 1 2 Teoreticko-metodologická část práce... 4 2.1 Proces... 4 2.2 Notace modelování business procesů... 6 2.2.1 Elementy BPMN... 7 2.3 ITIL... 10 3 Praktická část práce... 17 3.1 Použité metody a techniky... 17 3.2 Představení Komerční banky... 17 3.3 Představení útvaru Business Intelligence... 17 3.3.1 Poskytované služby... 18 3.3.2 Základní architektura... 18 3.3.3 Organizační struktura BI... 19 3.4 Motivace pro implementaci ITILu... 19 3.5 Procesní architektura BI... 20 3.6 Popis procesů... 22 3.7 Sledované metriky... 23 3.8 Help Desk... 24 3.8.1 Role interagující s procesem... 24 3.8.2 Životní cyklus... 24 3.8.3 Statusy procesu... 25 3.8.4 Popis procesních kroků... 26 3.9 Requirement Management... 32 3.9.1 Role interagující s procesem... 32 3.9.2 Životní cyklus... 32 3.9.3 Statusy procesu... 33 3.9.4 Popis procesních kroků... 34 3.10 Incident Management... 36 3.10.1 Role interagující s procesem... 36 3.10.2 Životní cyklus... 37 3.10.3 Statusy procesu... 37 3.10.4 Popis procesních kroků... 38 3.11 Problem Management... 41

3.11.1 Role interagující s procesem... 41 3.11.2 Životní cyklus... 41 3.11.3 Statusy procesu... 42 3.11.4 Popis procesních kroků... 43 3.12 Change Management... 45 3.12.1 Role interagující s procesem... 45 3.12.2 Životní cyklus... 46 3.12.3 Statusy procesu... 46 3.12.4 Popis procesních kroků... 47 3.13 Navrhovaná doporučení pro implementaci ITILu v organizaci... 52 3.14 Navrhovaná doporučení pro prostředí BI KB... 57 4 Závěr... 67 Literatura... 71 Přílohy

Seznam zkratek BI BPMN BIVOJ DWH ED EDWH IFPC IQ ITIL JIRA Ticket Business Intelligence. BI umožnuje organizaci analyzovat firemní data pro potřeby rozhodování na všech úrovních řízení. BI umožnuje nejenom pohled na historická data organizace, ale lze i predikovat budoucí vývoj. Business Process Modeling Notation. BI Version of JIRA. Data Warehouse. Analytická databáze, kde jsou uložena data z primárních (klíčových) systémů organizace pro následné zpracování (analýzy). Environment Definition. Definice databázového prostředí a objektů v prostředí BI KB. Enterprise Data Warehouse. Centrální úložiště firemních dat (analytická databáze), kdy veškerá data jsou centralizována do jednotného datového úložiště. Výhodou EDWH je, že data je možné spojovat přes různé oblasti (např. marketingová data s prodejními apod.). Informatica PowerCenter. ETL nástroj, který zajištuje load (načtení), transformaci a extrakci (čištění) dat. Information Quality. Information Technology Infrastructure Library Software na sledování chyb, aktivit, úkolů, projektů, lidí a zdrojů. Je obecný název pro aktivitu, tj. požadavek, problém, incident, a další; je použit jako synonymum pro Issue, nebo Ticket.

Workflow Schéma provádění komplexní činnosti (procesu), rozepsané na jednodušší činnosti kroky, jejich vazby a přechody.

Seznam obrázků Obrázek 1: Schéma podnikového procesu... 5 Obrázek 2: Spojení různých rolí v podniku pomocí BPMN... 7 Obrázek 3: Vybrané události BPMN... 7 Obrázek 4: Základní typy události BPMN... 8 Obrázek 5: Aktivita v BPMN... 8 Obrázek 6: Subproces v BPMN.... 9 Obrázek 7: Základní typy konektorů BPMN... 9 Obrázek 8: Základní typy bran (rozhodování) BPMN... 9 Obrázek 9: BPMN Pool a Line... 10 Obrázek 10: Životní cyklus ITILu v3 s rozpadem jednotlivých fází... 13 Obrázek 11: Životní cyklus Správy služeb v organizaci... 14 Obrázek 12: Klíčové procesy v prostředí BI KB... 21 Obrázek 13: Generické workflow procesu... 22 Obrázek 14: Hlavní workflow procesu BI Help Desk... 25 Obrázek 15: Workflow Založení požadavku Zadavatelem... 26 Obrázek 16: Workflow Založení a pre-analýza požadavku... 27 Obrázek 17: Workflow Doplnění požadavku Zadavatelem... 27 Obrázek 18: Workflow Klasifikace požadavku... 28 Obrázek 19: Workflow Nové přiřazení řešitelské skupiny... 28 Obrázek 20: Workflow Řešení požadavku... 29

Obrázek 21: Workflow Doplnění požadavku Zadavatelem... 29 Obrázek 22: Workflow Ověření řešení... 30 Obrázek 23: Workflow Schválení Zadavatelem... 30 Obrázek 24: Workflow Řešení reklamace... 31 Obrázek 25: Workflow Vyhodnocení požadavku... 31 Obrázek 26: Hlavní workflow procesu BI Requirement Management... 33 Obrázek 27: Workflow Založení požadavku... 34 Obrázek 28: Workflow Klasifikace požadavku... 34 Obrázek 29: Workflow Ohodnocení požadavku... 35 Obrázek 30: Workflow Doplnění požadavku... 35 Obrázek 31: Workflow Schválení požadavku... 36 Obrázek 32: Workflow Přehodnocení požadavku... 36 Obrázek 33: Hlavní workflow procesu BI Incident Management... 37 Obrázek 34: Workflow Založení incidentu... 38 Obrázek 35: Workflow Klasifikace incidentu... 39 Obrázek 36: Workflow Analýza incidentu... 39 Obrázek 37: Workflow Řešení incidentu... 39 Obrázek 38: Workflow Doplnění zadání incidentu... 40 Obrázek 39: Workflow V ověření řešení... 40 Obrázek 40: Workflow Vyhodnocení incidentu... 40 Obrázek 41: Hlavní workflow procesu Problem Management... 42

Obrázek 42: Workflow Založení problému... 43 Obrázek 43: Workflow Analýza problému, návrh workaroundu... 43 Obrázek 44: Workflow Schvalování a revize... 44 Obrázek 45: Workflow Doplnění návrhu workaroundu... 44 Obrázek 46: Workflow Zplatnění workaroundu... 45 Obrázek 47: Workflow Vyhodnocení problému... 45 Obrázek 48: Hlavní workflow procesu Change Management... 46 Obrázek 49: Workflow Založení požadavku... 47 Obrázek 50: Workflow Doplnění požadavku... 47 Obrázek 51: Workflow Verifikace zadání... 48 Obrázek 52: Workflow Schválení řešení k nasazení... 48 Obrázek 53: Workflow Kontrola operačních metadat... 49 Obrázek 54: Workflow Metadatová kontrola... 49 Obrázek 55: Workflow Řešení požadavku... 50 Obrázek 56: Workflow Vytvoření prostředí a založení objektů... 50 Obrázek 57: Workflow Kontrola a nasazení řešení... 51 Obrázek 58: Workflow Kontrola výsledků... 51 Obrázek 59: Workflow Řešení reklamace... 52 Obrázek 60: Workflow Schválení a uzavření... 52 Obrázek 61: Integrace Projektového managementu do BI ITIL procesů... 62 Obrázek 62: Návrh procesního kroku Idea Formulation... 63

Obrázek 63: Návrh procesního kroku Project Definition... 64 Obrázek 64: Návrh procesního kroku Solution Design... 64 Obrázek 65: Návrh procesního kroku Implementation... 65 Obrázek 66: Návrh procesního kroku Approval/Akceptance... 66 Obrázek 67: Návrh procesního kroku Evalution/Closure... 66

1 Úvod Diplomová práce se zabývá praktickým využitím metodického rámce ITIL, který zahrnuje a popisuje nejlepší praktiky (best practices), jak přistupovat a řídit IT služby v organizaci. Diplomová práce je zaměřena na prostředí oddělení BI KB, kdy se zabývá implementací metodického rámce ITIL v tomto prostředí. Diplomová práce si klade za cíl navrhnout konkrétní kroky, které povedou ke zlepšení a zefektivnění procesního řízení založené nad metodickým rámce ITIL v prostředí BI KB. Zvolené téma diplomové práce je velice aktuální, protože efektivita a standardizace procesů v dnešní ekonomicky turbulentní době je jedním z faktorů, jak snižovat náklady organizace. Efektivita a standardizace procesů vede rovněž k zrychlení dodání služby či produktu zákazníkovi, což organizaci může přinést komparativní výhodu oproti konkurenci a tak lépe uspět ve vysoce konkurenčním prostředí. První kapitola teoretické části se zaměřuje na procesy a procesní řízení v podniku, zejména přináší různé definice, které jsou uváděny v literatuře a také pozitiva procesního řízení ve firmě. Kapitola přináší vlastní interpretaci procesů tak, jak jsou procesy vnímány v diplomové práci. Druhá kapitola teoretické části práce se zabývá notací modelování business (obchodních) procesů, která je v dnešní době jedna z nejpoužívanějších pro popis a interpretaci procesů ve firmě. Pomocí této notace (BPMN) je v rámci praktické části představena implementace ITIL procesů v prostředí oddělení BI KB a rovněž pro část navržených doporučení je tato notace použita. 1

Poslední kapitola teoretické části si klade za cíl představit metodický rámec ITIL, který je v současné době jedním z nejpoužívanějších přístupů pro řízení IT služeb v rámci organizace. Kapitola se zabývá jednotlivými fázemi životního cyklu ITIL Service Strategy (Strategie služeb), Service Design (Návrh služeb), Service Transition (Přechod služeb), Service Operation (Provoz služeb) a Continual Service Improvement (Neustálé zlepšování služeb). Hlavním cílem praktické části práce je koncipovat a formulovat soubor doporučení pro implementované procesy a stanovit další rozvoj směřující k zefektivnění procesního řízení v rámci oddělení BI KB. Na základě stanovených doporučení praktické části diplomové práce lze provést optimalizaci implementovaných procesů v prostředí BI KB. Výstupy (soubor doporučení) práce lze použít pro celkové zefektivnění současných procesů. První kapitoly praktické části práce představují Komerční banku, resp. oddělení BI. Poskytují čtenáři základní představu o společnosti a oddělení, s cílem přiblížit, v jakém prostředí a kontextu je zasazeno oddělení BI a jaké služby nabízí a poskytuje svým interním zákazníkům v rámci Skupiny KB. Čtenáři je nabídnut elementární pohled na celkovou architekturu a oddělení a to jak z pohledu organizační struktury, tak i z pohledu BI technologií a systémů. Cílem tohoto elementárního pohledu je ilustrovat komplexnost, ve které se oddělení pohybuje. Další kapitoly praktické části práce se zabývají vlastní implementací metodického rámce ITIL v rámci oddělení BI. Tyto kapitoly si kladou za cíl: přinést čtenáři představu, proč se management oddělení rozhodl pro implementaci ITILu; stručně představit jednotlivé fáze životní cyklu, resp. dílčími procesy a subprocesy metodického rámce ITIL, které jsou v oddělení implementovány. 2

Předposlední kapitola praktické části práce si klade za cíl vymezit obecná doporučení pro implementaci ITILu mimo prostředí BI KB. Tato doporučení jsou formulována na základě zkušenosti z implementace ITILu v prostředí BI KB. Díky tomu, že doporučení jsou formulována obecně, je možné je využít pro inspiraci a poučení jak v rámci velkých, tak i středních organizací. Cílem poslední kapitoly praktické části práce je formulovat soubor doporučení, které zefektivní procesní řízení v rámci prostředí BI KB. Účelem této kapitoly je vymezit konkrétní doporučení, které povedou (při realizaci) k efektivnějšímu fungování ITIL procesů v rámci oddělení BI KB. 3

2 Teoreticko-metodologická část práce 2.1 Proces Nutkavou potřebu zlepšení procesu pocítil snad každý, kdo jednou zažil dlouhou frontu v obchodě. V tomto případě se procesem rozumí postup vyřízení požadavku zákazníka, jehož účelem je zabalení a předání zboží a přijetí platby. Proces začíná zařazením zákazníka do fronty a končí opuštěním obchodu se zbožím a účtenkou v ruce. 1 Literatura proces definuje následovně: - Proces je organizovaná skupina vzájemně souvisejících činností a/nebo subprocesů, které procházejí jedním nebo více organizačními útvary či jednou (podnikový proces) nebo více spolupracujícími organizacemi (mezipodnikový proces), které spotřebovávají materiální, lidské, finanční a informační vstupy a jejichţ výstupem je produkt, která má hodnotu pro externího nebo interního zákazníka. 2 - Proces je série logicky souvisejících činností nebo úkolů, jejichž prostřednictvím jsou-li postupně vykonány má být vytvořen předem definovaný soubor výsledků 3 - Proces je souhrnem činností, transformujících souhrn vstupů do souhrnu výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje 4 V diplomové práci je proces interpretován jako: soubor činností, které přeměňují vstupy na výstupy s tím, že zákazníkovi (externímu či internímu) přinášejí požadovanou hodnotu. Zákazník je orientován na službu či produkt a ostatní činnosti, které se pojí s vlastní dodávkou zůstavají zákazníkovi skryty. Odběratel (zákazník) produktu či 1 ŘEPA, V. (2007). Podnikové procesy: procesní řízení a modelování. Praha: Grada, str. 15. 2 ŠMÍDA, F. (2007). Zavádění a rozvoj procesního řízení ve firmě. Praha: Grada, str. 29. 3 SVOZILOVÁ, A. (2011). Zlepšování podnikových procesů. Praha: Grada, str. 14. 4 ŘEPA, V. (2007): Podnikové procesy: procesní řízení a modelování. Praha: Grada, str. 15. 4

služby poskytuje zpětnou vazbu, jak je s dodávkou spokojen, což vede k zachování, resp. zlepšování požadované hodnoty. Hlavním smyslem procesu je přinést zákazníkovi produkt (hmotný či nehmotný výrobek, službu), který on sám bude požadovat za hodnotu ve formě potřeby, funkce či prospěchu. 5 Obrázek 1: Schéma podnikového procesu Zdroj: ŘEPA, V. (2007). Podnikové procesy: procesní řízení a modelování. Praha: Grada, str. 15. Procesy, resp. procesní řízení má podniku přispět ke snižování nákladů, zvyšování rychlosti a kvality při dodávce služeb a produktů zákazníkovi. Tyto pozitivní efekty jsou vyvolány díky odstraňování bariér mezi jednotlivými odděleními firmy a partnery, což ve výsledku vede k odstranění opakování činností při dodávce produktu nebo služeb. 6 Díky implementaci procesního řízení ve firmě lze lépe plánovat a utilizovat zdroje firmy (v největší míře lidské zdroje), kvantifikovat některé jevy a lépe předvídat budoucí události (např. objem tržeb v jednotlivých fázích procesu prodeje) či dříve reagovat na změny trhu. 7 5 Volně zpracováno z: SVOZILOVÁ, A. (2011). Zlepšování podnikových procesů. Praha: Grada, str. 16. 6 Volně zpracováno z: ŠMÍDA, F. (2007). Zavádění a rozvoj procesního řízení ve firmě. Praha: Grada, str. 32. 7 Volně zpracováno z: ŠMÍDA, F. (2007). Zavádění a rozvoj procesního řízení ve firmě. Praha: Grada, str. 32. 5

2.2 Notace modelování business procesů Standard BPMN poskytuje podnikům schopnost pochopit jejich (vnitřní) procedury a procesy pomocí grafického zápisu a tím umožní organizacím komunikaci těchto postupů standardním způsobem. Kromě toho grafická notace usnadňuje pochopení výkonnostní spolupráce a obchodních transakcí mezi organizacemi. To zajistí, že podniky budou chápat samy sebe a účastníky v jejich podnikání a umožní organizacím, aby se přizpůsobily novým obchodním podmínkám. 8 BPMN je grafická notace, která slouží k modelování procesů. BPMN je tvořeno sadou grafických elementů a pravidel, podle kterých je možné elementy spojovat. Společně s jazykem BPEL 9 je BPMN nástrojem na modelování v platformách BPMS (soubor nástrojů, které dokážou podporovat uceleně celý životní cyklus podnikání). BPMN je standardem Object Management Group 10 od roku 2006. 11 Cílem BPMN je nalézt porozumění mezi rozdílnými pozicemi a rolemi v podniku (viz obrázek níže). 8 Volně zpracováno z: Object Management Group: Business Process Model and Notation [online]. 2012 [cit. 2012-03-25]. Dostupné z: http://www.bpmn.org/. 9 Business Process Execution Language. Využívá se k modelování obchodních procesů pro automatizované (strojové) vykonání. 10 http://www.omg.org/. 11 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 6

Obrázek 2: Spojení různých rolí v podniku pomocí BPMN Zdroj: Notace modelování business procesů. 2.2.1 Elementy BPMN Níže uvedený text se zabývá základními elementy (události, aktivity, spojovací objekty, brány) BPMN verze 2.0. Celkový výčet elementů je uveden v příloze diplomové práce. Událost Značí se kroužkem, přímo ovlivňují tok procesu. Na obrázku níže jsou zobrazeny události, jimiž proces začne (startovací událost), skončí (ukončující událost), či které nastanou v jeho průběhu (událost během procesu). 12 Obrázek 3: Vybrané události BPMN Startovací událost Ukončující událost Událost během procesu Zdroj: Notace modelování business procesů, vlastní úpravy. 12 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 7

Mezi základní typy událostí patří 13 : - časová událost, - událost značící přijmutí/odeslání zprávy, - chybová událost (spouští alternativní tok). Obrázek 4: Základní typy události BPMN Časová událost Zpráva Chybová událost Zdroj: Notace modelování business procesů, vlastní úpravy. Aktivita a Sub-proces Znázorňuje vykonávanou činnost či práci. Může být buďto atomická (tzv. task) nebo v sobě může obsahovat samostatný proces, pak se tato aktivita nazývá sub-proces. 14 Obrázek 5: Aktivita v BPMN Zdroj: Notace modelování business procesů, vlastní úpravy. Aktivita je dále nedělitelná jednotka práce. Jeden člověk v jeden čas na jednom místě. 15 Subproces je realizován sledem aktivit. Tvoří hierarchickou úroveň modelu. 16 13 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 14 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 15 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 16 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 8

Obrázek 6: Subproces v BPMN. Zdroj: Notace modelování business procesů, vlastní úpravy. Konektory Konektory jsou objekty, které slouží ke spojení aktivit, událostí či artefaktů navzájem. Mezi základní konektory se řadí 17 : - Sekvenční tok nepřerušovaná čára s vyplněnou šipkou, určuje sekvenci (pořadí) aktivit. - Tok zprávy přerušovaná čára s prázdnou šipkou, znázorňuje tok zpráv mezi dvěma účastníky procesu. - Asociace umožňuje spojit objekt s nějakou dodatečnou informací (popiskem). Obrázek 7: Základní typy konektorů BPMN Sekvenční tok Podmíněný sekvenční tok Zdroj: Notace modelování business procesů, vlastní úpravy. Tok zprávy Asociace Brána (rozhodování) Brána označuje rozbíhání (rozhodování) či souběh toků procesu, značí se kosočtvercem. 18 Obrázek 8: Základní typy bran (rozhodování) BPMN Souběh Paralelní rozvětvení Rozhodnutí na základě události Rozhodnutí na základě informací Zdroj: Notace modelování business procesů. 2010, vlastní úpravy. 17 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 18 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 9

Ostatní elementy - Pool - ohraničuje proces, v jeho záhlaví je název procesu, - v rámci jednoho poolu se nachází právě jeden samostatný proces, - komunikace mezi pooly probíhá pomocí zpráv (message). - Line - role v rámci modelovaného procesu (případně oddělení či funkce organizace), - podčást poolu, - slouží k uspořádání a kategorizaci aktivit. 19 Obrázek 9: BPMN Pool a Line Zdroj: Notace modelování business procesů, vlastní úpravy. 2.3 ITIL Metodický rámec ITIL, který zahrnuje a popisuje nejlepší praktiky (best practices), jak přistupovat a řídit IT služby v organizaci. Metodický rámec ITIL se řadí v posledních letech mezi nejrozšířenější přístupy k řízení IT služeb na světě. ITIL poskytuje ucelený soubor osvědčených postupů, které byly shromážděny z veřejného a soukromého sektoru pro oblast IT. Metodický rámec ITIL se rovněž zaměřuje na neustálé zlepšování poskytovaných IT služeb zákazníkovi. 19 Volně zpracováno z: KOMERČNÍ BANKA. (2010). Notace modelování business procesů. 10

ITIL vzniknul více než před 20 lety a je neustále rozvíjen. Současná verze čítá třetí řadu (ITIL v3). ITIL je široce rozvinutý metodický rámec pro řízení IT služeb na světě. Jeho přístup je založen na praktičnosti a reálném přístupu k identifikaci, plánování, realizaci a podpory IT služeb v organizaci. 20 Počátkem 80. let 20. století se počítače a výpočetní centra pomalu začala přesouvat od centrálních sálových počítačů do firemních IT organizací, což mělo mnohdy za důsledek geografické rozptýlení IT a lidských zdrojů. Společnosti tím získávaly větší míru flexibility, ale vedlejším účinkem bylo nekonzistentní uplatňování postupů pro technologické dodávky a podporu. 21 Britský úřad OCG (Office of Government Commerce) identifikoval, že pokud dojde k využítí konzistentních postupů pro všechny aspekty IT životního cyklu, může tento přístup přinést organizaci efektivitu, účinnost a předvídatelnou úroveň služeb a tím položil základy metodického rámce ITIL. Od té doby je ITIL vnímán jako úšpěšný mechanismus, jak řídit konzistenci (soudržnost) a účinnost, která je zapotřebí pro poskytování IT služeb organizace jako prostředek podpory primárního zaměření a aktivit (core business) společnosti. 22 ITIL se obvykle používá ve spojení s jedním nebo více jiných osvědčených postupů pro správu informačních technologií, např. 23 : - COBIT, - Six Sigma, - TOGAF, - ISO 27000. 20 Volně zpracováno z: OGC. (2010). Introduction to the ITIL service lifecycle. United Kingdom: The Stationery Office, str. 3. 21 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 22 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 23 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 11

COBIT (Control Objectives for Information and related Technology) byl vyvinut jako všeobecně přijímaný standard pro správné postupy řízení, kontroly a auditu informačních technologií. Metodický rámec COBIT zajištuje, aby investice do IT byly v souladu s podnikovými cíli. 24 Six Sigma byla vyvinuta společností Motorola. Jedná se manažerský přístup neustálého zvyšování efektivnosti organizace s využítím statistických metod. Cílem této filozofie je zvýšit výkonnost podniku a spokojenost zákazníka. Používá se v řadě odvětvích průmyslu a služeb k eliminaci problémů, defektů a ztrát v řízení kvality. 25 TOGAF (The Open Group Architecture Framework) je metodický rámec určený pro řízení IT Enterprise architektury. TOGAF se zabývá, jak navrhnout, implementovat a dlouhodobě řídít IT Enterprise architektru v souladu se strategií společnosti. 26 ISO 27000 zahrnuje soubor norem, které řeší oblast bezpečnosti informací v organizaci. Soubor se primárně zaměřuje na návrh, zavedení a řízení (provoz) Systému řízení bezpečnosti informací (ISMS). 27 ITIL byl vytvořen a je stále rozvíjen odborníky, kteří sbírají osvědčené postupy a zkušenosti (best practices) z celého světa v rámci řízení IT služeb. Od svého uvedení na počátku devadesátých let se ITIL postupy a návody osvědčily v rámci celého světa. Implementace založené na metodickém rámci ITIL lze nalézt v širokém spektru firem 24 Volně zpracováno z: COBIT Brochure [online]. 2011 [cit. 2012-04-29]. Dostupné z: http://www.isaca.org/knowledge-center/cobit/documents/cobit-4.1-brochure.pdf. 25 Volně zpracováno z: Six Sigma [online]. 2011 [cit. 2012-03-26]. Dostupné z: http://www.6s.cz/. 26 Volně zpracováno z: Základní fakta [online]. 2010 [cit. 2012-03-26]. Dostupné z: http://www.togaf.cz/index.php?option=com_content&view=article&id=11:hlavnistranka&catid=1:hlavni-kategorie. 27 Volně zpracováno z: ISO/IEC 27000 [online]. 2012 [cit. 2012-03-26]. Dostupné z: http://www.iso27000.cz/. 12

např. 28 : Microsoft, HP, Fujitsu, IBM, Target, Walmart, Staples, Citi, Bank of America, Barclay s Bank, Sony, Disney aj. 29 Životní cyklus ITILu verze 3 obsahuje tyto fáze 30 : - Strategie služeb (Service Strategy), - Návrh služeb (Service Design), - Přechod služeb (Service Transition), - Provoz služeb (Service Operation), - Průběžné zlepšování služeb (Continual Service Improvement). Obrázek 10: Životní cyklus ITILu v3 s rozpadem jednotlivých fází Zdroj: http://g2sf.com/wp-content/uploads/2011/02/itil-service-lifecycle-copy.png. 28 ARRAJ, V. (2010). ITIL: The Basics. OGC. 29 Volně zpracováno z: KNELLER, M. (2010). The Benefits of ITIL. OGC. 30 OGC. (2010). Introduction to the ITIL service lifecycle. United Kingdom: The Stationery Office, str. 11 13. 13

Díky implementace ITILu v organizaci lze dosáhnout vysokého standardu dodávek služeb tak, jak je zobrazeno na obrázku níže. Obrázek ukazuje, jak může vypadat sjednocená Správa služeb, když je pokryt celý životní cyklus. 31 Obrázek 11: Životní cyklus Správy služeb v organizaci Zdroj: http://itil.cz/index.php?id=988. Strategie služeb (Service Strategy) Cílem této fáze je nálezt IT zákazníky a specifikovat požadavky na jejich potřeby služby. Identifikovat IT kapacity a zdroje, které pokryjí vývoj a provoz služby. Pomocí 31 Proč zavádět ITIL [online]. 2007 [cit. 2012-03-26]. Dostupné z: http://itil.cz/index.php?id=988. 14

fáze Strategie služeb (a zároveň při dodávce a podpoře služby) musí IT zajistit, aby náklady na dodání byly v souladu požadovanou hodnotou pro zákazníka. 32 Návrh služeb (Service Design) Cílem této fáze je zajistit, aby nové služby či změny prováděné ve stávajích službách, účinně naplňovaly očekávání IT zákazníků. V rámci této fáze musí dojít k nastavení technologie a architektury tak, aby byly cenově s očekáváním zákazníků. Součástí fáze Návrh služeb je i rovněž návrh procesů, které jsou spojené s navrhovanou či měněnou službou. 33 Přechod služeb (Service Transition) Hlavním cílem této fáze je otestovat vyvinutou službu (např. IT řešení) a nasadit (přesunout) do produkčního prostředí, kdy musí být zajištěno, že zákazník díky službě může dosahovat požadované hodnoty služby. V rámci této fáze se rovněž ověřuje, že daná služba může být nasazena do produkčního prostředí v kontextu organizace a jiných závislostí, které mohou ovlivnit provoz služby na produkci. 34 Přechod služeb (Service Transition) V rámci této fáze dochází k provozu služby, kdy cílem je zajistit běžný a rutinní provoz pro zákazníka tak, aby mu služba poskytovala požadovanou hodnotu. Tato fáze zahrnuje jak rutinní (bezproblémový provoz), tak i řešení výpadků, incidentů a problémů spojených s provozem služby. 35 32 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 33 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 34 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 35 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 15

Průběžné zlepšování služeb (Continual Service Improvement) Fáze Průběžného zlepšování služby v rámci životní cyklu metodického rámci ITIL pokrývá mechanismy pro zlepšování služby z pohledu technologie, účinnosti a efektivnosti poskytované služby, čímž dochází k udržování přidané hodnoty služby prostřednictvím zvyšující se kvality a efektivity. 36 36 Volně zpracováno z: ARRAJ, V. (2010). ITIL: The Basics. OGC. 16

3 Praktická část práce 3.1 Použité metody a techniky V rámci diplomové práce jsou použity analytické a syntetické metody. Vyjmenované metody jsou použity především proto, že analytická metoda popisuje AS-IS stav a pomocí syntetické metody je navržen budoucí efektivnější procesní řízení v BI KB. 3.2 Představení Komerční banky Komerční banka spadá do mezinárodní skupiny Société Générale, která vlastní cca 60% procent akcií. KB se řadí mezi tzv. univerzální banky se snahou nabízet širokou paletu služeb v oblasti retailového, podnikového a investičního bankovnictví. KB poskytuje služby cca 1,6 miliónů klientů, má rozsáhlou síť poboček (395) a pokrývá Českou republiku 677 bankomaty. 37 Detailní finanční a nefinanční ukazatele KB jsou přiloženy v příloze práce. 3.3 Představení útvaru Business Intelligence Útvar BI spadá do úseku Financí a Strategie a je zodpovědný za koordinaci, vývoj a provoz jednotné informační základny založené na požadavcích uživatelů v rámci KB, za funkční design analytického centrálního datového skladu (Data Warehouse) a jeho části (Data Marts), za design řešení pro sdílení dat, výkaznictví a podporu analytických požadavků zahrnující získávání dat v různých dimenzích statistické analýzy a data mining. Podporuje oddělení (uživatele) připravující specificky vyžádaná řešení a výkazy. Veškeré analytické manažerské výkazy v KB by měly pocházet z jediného zdroje dat spravovaných útvarem BI. 37 Volně zpracováno z: KOMERČNÍ BANKA. Komerční banka: Základní informace [online]. 2010 [cit. 2012-02-12]. Dostupné z: http://kb.cz/cs/o-bance/o-nas/zakladni-informace.shtml. 17

3.3.1 Poskytované služby BI poskytuje služby cca 7 tisícům uživatelů ze Skupiny KB, kdy tyto služby jsou poskytovány napříč všemi úrovněmi řízení včetně bankovních poradců. Mezi BI služby patří: - Základní služby. - Standardní reporty. - Dodávka dat a podpora BI aplikací. - Doplňkové služby. - Přímý přístup do datového skladu. - Individuální reporty. - Ad-hoc reporty. - Load uživatelských dat do datového skladu z externích zdrojů. - Ostatní služby. - Hodnocení informační kvality. - Podpora rozpočtovacího a plánovacího procesu. - BI školení. - Vývoj nových BI služeb a jejich změna. 3.3.2 Základní architektura V rámci KB je implementován EDWH s hlavním cílem, aby sloužil jako jednotná báze dat pro celou KB, resp. Skupinu KB. KB EDWH integruje data z řady klíčových primárních systémů (transakční systém, kartový systém, ERP, aj.). Tato data jsou poskytována uživatelům pomocí BI služeb (viz kapitola: Poskytované služby). 18

Architektura KB EDWH je vyobrazena v příloze diplomové práce. Technologicky je KB EDWH tvořen: - ETL: Informatica PowerCenter 9.1. - Databáze: Teradata 13.10. - Reporting: Cognos 8.4. 3.3.3 Organizační struktura BI Jak již bylo zmíněno v úvodu kapitoly, útvar BI spadá do úseku Finance a Strategie, nikoliv do úseku IT, jak je spíše zvykem. Toto organizační uspořádání se ukázalo jako velice vhodné a lze ho doporučit i ostatním organizacím. Zejména proto, že BI je blíže business uživatelům a dokáže tak lépe spolupracovat a vytvářet řešení, které ve výsledku lépe podporují strategické cíle banky. Útvar BI má v současné době cca 90 interních zaměstnanců a využívá cca 60 externích konzultantů převážně z firem Accenture, Reporters, Profinit, Ness a Anywhere. Útvar BI se dělí na 4 základní oddělení, jejichž další členění je zobrazeno na obrázku v příloze práce. 3.4 Motivace pro implementaci ITILu Útvar BI, stejně jako celá banka, musí neustále zlepšovat kvalitu služeb, při současném tlaku na snižování nákladů a zvyšování efektivnosti. Aby toho BI mohla dosáhnout při stále se zvyšujícím počtu dodávaných řešení, tak se v roce 2008 uskutečnila zásadní reorganizace útvaru a od roku 2009 je cílem zprůhlednění a standardizace procesů. Na popud vedoucího útvaru, byl jako hlavní priorita v oblasti vnitřního rozvoje BI v roce 2009 schválen projekt OPERa (Optimization of Proceses and Elimination of Risks), jehož hlavním cílem je zprůhlednění a zlepšení BI služeb, aby činnost každého oddělení i jednotlivce BI byla plně zákaznicky orientovaná a proaktivní a aby veškerá 19

činnost byla prověřována otázkami typu pro koho to dělám?, vím k čemu to můj zákazník potřebuje?, nemohl bych to dělat ještě lépe?, neměl bych doporučit svému zákazníkovi možné zlepšení, které jsem právě objevil?. 3.5 Procesní architektura BI Je primárně určena pro ilustraci vazeb mezi jednotlivými procesy a tím, jak jsou procesy implementovány. BI procesy, resp. workflow procesu, jsou implementovány v systému JIRA 38, resp. v systému BIVOJ 39, což je customizovaná verze systému pro BI KB účely. Procesní architektura vychází z best practice frameworku ITIL v3 a pokrývá tyto základní BI procesy: - Incident Management. - Problem Management. - Help Desk. - Requirement Management. - Change Management. 38 Software na sledování chyb, aktivit, úkolů, projektů, lidí a zdrojů. Více na www.jira.com. 39 BI Version of JIRA 20

Obrázek 12: Klíčové procesy v prostředí BI KB Incident Management Problem Management Help Desk Requirement Management Change Management IM100 Creation and pre-analysis of incident PM100 Creation and pre-analysis of problem HD100 Creation and pre-analysis of requirement RM100 Creation and pre-analysis of requirement CH100 Creation of RFC IM200 Classification and categorization of incident PM200 Classification and categorization of problem HD200 Classification and categorization of requirement RM200 Classification of requirement CH200 Classification of RFC IM300 Analysis, diagnosis of incident IM500 Solution and recovery of incident PM300 Analysis, diagnosis of problem PM500 Solution of problem, Known Error HD500 Solution of requirement Support, Maintanace CH 500 Solution of RFC RM500 Design and evaluation of effort, risk IM700 Verification IM800 Approval PM700 Verification HD700 Verification HD800 Approval RM800 Approval to Implementation Project, Small Enhancement CH600 Deployment CH 800 Approval IM900 Evaluation, closure PM900 Evaluation, closure HD900 Evaluation, closure RM900 Closure CH 900 Evaluation, closure Zdroj: BIVOJ Guideline, vlastní úpravy. Všechny uvedené BI procesy pak podporují základní činnosti BI: - Řízení a správa útvaru Business Inteligence. - Provozování DWH. - Vývoj BI služeb. - Vývoj a provoz systémů BI. - Analýza a návrh řešení IQ. - Ostatní činnosti. 21

3.6 Popis procesů Tvorba procesů je v KB upravena vnitrobankovní instrukcí (Tvorba a správa procesů KB, resp. BPM Governance). Použitá metodika pro BI je jejím rozšířením a je navržena tak, aby bylo možné popsané procesy implementovat do libovolného workflow nástroje (v případě BI se jedná o nástroj BIVOJ) a zároveň zachovala soulad s požadavky celé KB a již zmiňované instrukce. Základní mapa procesu je zakreslená v notaci BPMN, součástí mapy je přiřazení procesních kroků jednotlivým rolím. Mapa obsahuje pozitivní průchod procesem a nejdůležitější alternativní toky. Každý z procesních kroků zakreslených v procesní mapě je dále podrobněji popsán podle šablony procesního kroku. Implementovaný proces musí, z důvodu dodržení konzistentnosti, vycházet z generického procesu (viz obrázky níže). Obrázek 13: Generické workflow procesu Řešitelské kroky (dle potřeby) X100 Založení a preanalýza X200 Klasifikace ticketu X600 Řešení ticketu X500 Řešení ticketu X400 Řešení ticketu X300 Řešení ticketu X700 Ověření řešení majitelem procesu X800 Schválení X900 Vyhodnocení ticketu Zdroj: Metodika modelování procesů, vlastní úpravy. Výše uvedený obrázek ilustruje do jakého rámce musí být zasazeno workflow procesu v prostředí BI KB. V rámci procesů vystupují tyto obecné role: - zadavatel, - řešitel, - schvalovatel, - participant, u kterých se uvádí základní odpovědnosti. 22

3.7 Sledované metriky Výčet navržených metrik 40 slouží jako KPI 41 procesu tj. k vyhodnocování procesu a jeho zlepšování. Obecné metriky pro každý implementovaný proces jsou: - Historické metriky za období (průměr, suma, medián dle potřeby): - Celková doba nutná ke zpracování ticketu doba od založení ticketu do systému (status Nový) až po jeho vyhodnocení (status Vyhodnocený). - Doba potřebná k vyřešení ticketu doba od přechodu ze statusu Založený do statusu Vyřešený. - Doba potřebná k dodání (Zadavateli, Žadateli) ticketu - doba od přechodu ze statusu Založený do statusu K ověření. - Dále časové metriky dle: - jednotlivých výkonných statusů (v kroku X100, X300-X600, X700), - jednotlivých čekacích statusů (doba nutná na schválení Zadavatelem, doba vyhodnocení ticketu managerem). - Počty jednotlivých ticketů v (pseudo) chybových statusech: - počet stornovaných ticketů, - počet reklamovaných ticketů Zadavatelem, - počet ticketů odeslaných k doplnění Zadavatelem v řešitelských procesních krocích. 40 Měřitelný údaj procesu, resp. kvalitativní ukazatel procesu. 41 Key Performance Indicator. Česky: klíčové ukazatele výkonnosti. 23

- Metriky vztažené k aktuálnímu stavu procesu: - počty ticketů ve statusech, které nejsou finální s rozpadem na jednotlivé statusy, - počty ticketů dle priorit, - počty ticketů dle jednotlivých řešitelských skupin. 3.8 Help Desk Cílem procesu je evidovat, řešit a řídit požadavky přicházející na BI od zákazníků (KB, dceřiné společnosti KB) nebo BI interních uživatelů. Proces pokrývá založení, ohodnocení, ocenění a přiřazení rozhodnutí o schválení či neschválení požadavků na BI zadaných interními uživateli nebo zákazníky. 3.8.1 Role interagující s procesem V procesu BI Help Desk vystupují tyto role: - Zadavatel - Help Desk Operátor - Help Desk Koordinátor - Help Desk Řešitel - Help Desk Manager 3.8.2 Životní cyklus Životní cyklus procesu BI Help Desk (obrázek níže) se skládá z 11 kroků (sub-procesů), kdy proces při hladkém průběhu musí projít minimálně 7 kroky. 24

Obrázek 14: Hlavní workflow procesu BI Help Desk Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. 3.8.3 Statusy procesu Proces BI Help Desk může nabývat tyto stavy: - Otevřený požadavek je v tomto stavu pokud ho ještě nikdo nezačal řešit, anebo požadavek již je v řešení, ale nebyla dokončena úvodní pre-analýza. - Založený požadavek je pre-analyzovaný, čeká na zpracování další řešitelskou skupinou nebo jiným procesem. - V řešení požadavek je přiřazený řešitelské skupině a probíhají výkonné kroky k jeho vyřešení. - K ověření požadavek byl vyřešen HD operátorem, řešení bylo otestované a čeká na formální ověření řešení. - Vyřešený požadavek je připraven k ověření Zadavatelem. - V reklamačním řízení řešení požadavku bylo reklamované Zadavatelem. - Uzavřený požadavek prošel procesním krokem Schválení zadavatelem a čeká na vyhodnocení řešení (SLA, časová náročnost atd.). 25

- Vyhodnocený finální stav, ticket je uzavřen, životní cyklus skončil. - K doplnění Zadavatel nedodal všechny potřebné podklady, řešení ticketu čeká na jejich dodání. - Stornovaný finální stav, ticket není určen k řešení v daném procesu. Případně Zadavatel požádal o zrušení. - K novému přiřazení Požadavek byl vrácen HD Operátorovi k novému přiřazení řešitelské skupiny. 3.8.4 Popis procesních kroků Založení zadavatelem (HD050) Procesní krok popisuje aktivity spojené se založením požadavku Zadavatelem. Zadavatel otevře na intranetu příslušný formulář. Do formuláře vyplní požadované údaje a přiloží případné přílohy. Obrázek 15: Workflow Založení požadavku Zadavatelem Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Založení a pre-analýza (HD100) Procesní krok popisuje aktivity spojené se založením požadavku, kompletací potřebných informací a výběru řešitelů. Součástí sub-procesu je i možnost vyžádání více informací od Zadavatele, případně požadavek Stornovat. Řešitel procesního kroku má dále možnost delegovat část pre-analýzy požadavku na jiného řešitele v rámci BI (pomocí podproblému). HD operátor ověří, zda není v rozporu detailní popis požadavku 26

s povinnými atributy. Obrázek 16: Workflow Založení a pre-analýza požadavku Nutnost doplnění informací Zadavatelem Vrátit k doplnění K doplnění podproblémy Požadavek na Storno Stornovat Doplnění požadavku Stornovaný Přiřazení si požadavku Upravení povinných a nepovinných atributů Změna kategorie a služby Přidělení úkolů Připojení příloh Zapsání vykonané práce Ne Založení nového SD pro každou neatomickou část původního SD Notifikace zadavatele obsahující sumarizaci Stornovat Stornovaný Otevřený Je SD atomicke? Vytvoření komentářů Výběr řešitele požadavku Ano Označit jako založený Založený Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Cílem procesního kroku je zkompletovat požadavek a vybrat HD koordinátora, resp. řešitelskou skupinu. Doplnění požadavku Zadavatelem (HD150) Procesní krok popisuje aktivity spojené s požadavkem na doplnění informací do zadání požadavku. Po obdržení požadavku na doplnění, Zadavatel doplní formou komentáře chybějící/doplňující údaje příp. připojí chybějící/doplňující přílohu a požadavek odešle opět ke zpracování. Obrázek 17: Workflow Doplnění požadavku Zadavatelem Doplnění požadavku V doplnění Připojení příloh Doplnění komentářů Předat ke zpracování Otevřený Stornovat Stornovaný Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. 27

Cílem procesního kroku je doplnit zadání o informace, potřebné k založení a preanalýze požadavku. Klasifikace požadavku (HD200) Procesní krok popisuje aktivity spojené s klasifikací požadavku a výběrem řešitelů. Součástí sub-procesu je i možnost požádat o změnu Řešitelské skupiny. Obrázek 18: Workflow Klasifikace požadavku Správně přiřazen? Založený Kontrola správnosti přiřazení požadavku Ano Postoupit k řešení V řešení Zapsání komentáře Vrátit k novému přiřazení řešitele V doplnění Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Cílem procesního kroku je zkontrolovat správnost přiřazení požadavku na řešitelskou skupinu a vybrat řešitele. Nové přiřazení řešitelské skupiny (HD250) Cílem procesního kroku je přiřazení požadavku na novou řešitelskou skupinu. Obrázek 19: Workflow Nové přiřazení řešitelské skupiny Doplnění požadavku Ne Připojení příloh K doplnění Nutná změna řešitelů? Ano Výběr kategorie a nové řešitelské skupiny Doplnění komentářů Označit jako založený Založený Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. 28

Řešení požadavku (HD500) Procesní krok popisuje aktivity spojené s řešením požadavku. Vlastní řešení požadavku je realizováno vytvořením podproblému. Vytvořením podproblému přiřadí HD Koordinátor požadavek k řešení pracovníkovi v rámci příslušné řešitelské skupiny. Součástí sub-procesu je i možnost vyžádání si doplnění požadavku od Zadavatele. Obrázek 20: Workflow Řešení požadavku podproblémy V řešení Přidělení úkolů Zapsání vykonané práce Postoupit k ověření K ověření Požadavek je neřešitelný Zapsání vykonané práce Označit jako neřešitelný K ověření (s příznakem) Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Cílem procesního kroku je vyřešit požadavek v rámci řešitelské skupiny. 3.8.4.1 Doplnění požadavku Zadavatelem (HD550) Procesní krok popisuje aktivity spojené s doplněním informací Zadavatelem. Cílem procesního kroku je doplnit zadání o informace, potřebné k vyřešení požadavku. Obrázek 21: Workflow Doplnění požadavku Zadavatelem Doplnění požadavku V doplnění Připojení příloh Doplnění komentářů Předat ke zpracování V řešení Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Ověření řešení (HD700) Procesní krok popisuje aktivity spojené s ověřením řešení požadavku z formálního 29

hlediska. Po ověření řešení je požadavek postoupen k ověření Zadavatelem. Cílem procesního kroku je formálně ověřit řešení před jeho odesláním Zadavateli. Obrázek 22: Workflow Ověření řešení Je řešení kompletní? Přiřadit mně Ověření řešení Ano Zapsání vykonané práce Postoupit k ověření zadavatelem V ověření Vyřešený podproblémy Ne Přidělení úkolů Požadavek je neřešitelný Zapsání vykonané práce Označit jako neřešitelný Vyřešený (s příznakem) Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Schválení Zadavatelem (HD800) Procesní krok popisuje aktivity spojené se schválením vyřešeného požadavku Zadavatelem a případné možnosti zaslání reklamace. V případě, kdy zadavatel neschválí požadavek ve stanové lhůtě (10 dní), je tento požadavek automaticky uzavřen a není možné jej dále reklamovat. Cílem procesního kroku je schválit vyřešený požadavek. Obrázek 23: Workflow Schválení Zadavatelem E.g. 10WD Automatická změna stavu Vyřešený Uzavřený Ověřit řešení Positive Přidat komentáře a hodnocení řešení Schválit řešení Doplnit požadavek Negative Připojit přílohy Reklamovat řešení Doplnit komentáře V reklamačním řízení Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. 30

Řešení reklamace (HD850) Procesní krok popisuje aktivity spojené s požadavkem na reklamaci řešení. Zadavatel má možnost ve stanovené reklamační lhůtě reklamovat řešení svého požadavku. Pokud není ve stanovené lhůtě na HD reklamace zaslána, je požadavek považován za vyřešený. Obrázek 24: Workflow Řešení reklamace Je reklamace oprávněná? V reklamačním řízení Ověření nároku na reklamaci Ne Zapsání vykonané práce Postoupit k ověření zadavatelem Vyřešený Přiřadit jinému řešiteli podproblémy V reklamačním řízení Ano Přidělení úkolů Požadavek je neřešitelný Zapsání vykonané práce Označit jako neřešitelný Vyřešený (s příznakem) Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. Cílem procesního kroku je vyřešit reklamaci požadavku. Vyhodnocení požadavku (HD900) Procesní krok popisuje aktivity spojené s vyhodnocením požadavku. Cílem procesního kroku je vyhodnotit uzavřený požadavek. Obrázek 25: Workflow Vyhodnocení požadavku Požadavek s bezproblémovým řešením Automatická změna stavu Uzavřený Ano Automatické vyhodnocení požadavku Vyhodnocení požadavku HD managerem Uzavřít Vyhodnocený Zdroj: Dokumentace procesu BI Help Desk, vlastní úpravy. 31

3.9 Requirement Management Cílem procesu je evidovat a analyzovat, oceňovat a řídit požadavky na BI (zákazníků nebo interní požadavky) na vytvoření nové nebo změnu stávající služby. Proces pokrývá založení, ohodnocení, ocenění a přiřazení rozhodnutí o schválení či neschválení požadavků na BI zadaných interními uživateli nebo zákazníky. 3.9.1 Role interagující s procesem V procesu Requirement Management vystupují tyto role: - Zadavatel. - Koordinátor. - Řešitel. - Hodnotitel. - Requirement Manager. 3.9.2 Životní cyklus Životní cyklus procesu Requirement Management se skládá z minimálně 4, resp. maximálně 6 kroků, jež jsou vyobrazeny na níže uvedeném obrázku. Proces se může vázat na proces BI Help Desk, pokud se jedná o novou službu nebo změnu stávající služby. 32

Obrázek 26: Hlavní workflow procesu BI Requirement Management Helpdesk BI HD050 - Založení zadavatelem HD100 (Založení a) preanalýza ANO REM NE HD700 - Ověření řešení HD800 Schválení zadavatelem HD900 Vyhodnocení požadavku Report (KIBIC) Zadavatel REM_100 - Založení požadavku REM_350 Doplnění požadavku Requirement Managemnt Koordinátor Řešitel REM_200 - Klasifikace požadavku REM_300 Ohodnocení požadavku REM_850 Přehodnocení požadavku Hodnotitel REM_800 Schválení požadavku Stornovaný Uzavřený Podstav: Schváleno/ Neschváleno Proces Schvalování požadavků Schvaluje komise: PMC/MPC BI Oper. Committee Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. 3.9.3 Statusy procesu Proces může nabývat tyto stavy: - Otevřený požadavek nabývá stavu otevřený, pokud nebyl zatím řešen. - Založený požadavek byl založen a čeká na přiřazení Koordinátorem. - V řešení požadavek byl předán k dalšímu zpracování. - Ohodnocený požadavek je oceněn a čeká na schválení. - V doplnění nebyly dodány všechny potřebné podklady, požadavek čeká na jejich dodání. - Stornovaný požadavek byl zrušen a není předán k dalšímu zpracování v daném procesu. - V řešení (Přehodnocení) požadavek byl předán k reklasifikaci příslušnému řešiteli. - Uzavřený požadavek prošel stavem uzavření požadavku. Stav Uzavřený nabývá dvou rozhodnutí Schváleno nebo Neschváleno. 33

3.9.4 Popis procesních kroků Založení požadavku (REM100) Cílem procesního kroku je založit ticket procesu Requirement Managementu (tzn. požadavek na BI od Zadavatele). Obrázek 27: Workflow Založení požadavku Otevřený Otevření formuláře REM Sumarizace požadavku Příkaz k založení požadavku Založený Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. Klasifikace požadavku (REM200) Procesní krok řeší aktivity spojené s klasifikací založeného požadavku. Klasifikace požadavku je rozlišení velikosti požadované změny. Cílem procesního kroku je klasifikovat požadavek, zda se jedná o typ Projekt nebo Drobný rozvoj (Small Enhancement). Obrázek 28: Workflow Klasifikace požadavku Založený Klasifikovat založený požadavek Předat k ohodnocení V řešení Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. Ohodnocení požadavku (REM300) Procesní krok řeší aktivity spojené s návrhem řešení a oceněním požadavku. K požadavku je možné vkládat komentáře nebo požadavek přiřadit na uživatele v roli Zadavatel, pokud je nutné požadavek doplnit o další informace a přílohy. 34

Obrázek 29: Workflow Ohodnocení požadavku Vrátit k doplnění V řešení Ocenit požadavek V doplnění Zapsat ocenění Přiřadit jinému řešiteli Ohodnocený Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. Doplnění požadavku (REM 350) Po obdržení požadavku k doplnění přidá Zadavatel formou komentáře nebo přílohy chybějící/doplňující údaje a požadavek odešle zpět řešiteli řešící požadavek v předchozím procesním kroku. Cílem procesního kroku je dospecifikovat zadání požadavku či doplnit další požadované údaje od Zadavatele. Obrázek 30: Workflow Doplnění požadavku V doplnění Doplnit komentář Doplnit přílohy Předat ke zpracování V řešení Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. Schválení požadavku (REM800) Procesní krok řeší aktivity spojené s rozhodnutím o schválení či neschválení požadavku na službu k realizaci. Rozhodnutí o schválení či neschválení je výsledkem jiného procesu Schvalování požadavků komisemi buď na úrovni BI nebo celé banky. 35

Obrázek 31: Workflow Schválení požadavku Doplnit komentář Přidat rozhodnutí Ohodnocený Zpráva komise o schválení/ neschválení požadavku Uzavřený (Schválený/ Neschválený) Stornovaný Report SE/ KB/ DC Report Projektů / KB/ DC V řešení (Přehodnocení) Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. Přehodnocení požadavku (REM850) Procesní krok řeší aktivity spojené s přehodnocením požadavku. K přehodnocení požadavku dochází na základě rozhodnutí Hodnotitele (např. pokud není specifikace odhadů dostatečná nebo pokud došlo ke změně předpokladů). Obrázek 32: Workflow Přehodnocení požadavku V řešení (Přehodnocení) Překlasifikovat požadavek Předat k ohodnocení Ohodnocený Zdroj: Dokumentace procesu Requirement Management, vlastní úpravy. 3.10 Incident Management Proces, který odpovídá za správu životního cyklu incidentů. Primárním cílem procesu je rychlé obnovení provozu služeb pro uživatele. Incident Management má za úkol obnovit službu v co nejkratším čase a s co nejmenším dopadem na odběratele služeb. Incident je vyřešený v okamžiku, kdy uživatel může dál pokračovat ve své práci, bez ohledu na to, zda příčina incidentu je či není známá a byla nebo nebyla odstraněna. 3.10.1 Role interagující s procesem - Zadavatel - Incident Management Operátor - Řešitel 36

- Schvalovatel 3.10.2 Životní cyklus Životní cyklus procesu Incident Managementu se skládá z minimálně 6, resp. maximálně 7 kroků, jež jsou vyobrazeny na níže uvedeném obrázku. Proces se může vázat na proces BI Help Desk nebo na proces Problem Management. Obrázek 33: Hlavní workflow procesu BI Incident Management Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. 3.10.3 Statusy procesu Proces může nabývat tyto stavy: - Otevřený ticket je ve stavu otevřený, pokud jej ještě nikdo nezačal řešit. - Založený probíhá klasifikace incidentu. - V řešení (Analýza) předání incidentu řešitelské skupině, probíhá analýza 37

a diagnostika incidentu. - V řešení (Řešení incidentu) předání incidentu ke zpracování řešitelské skupině. - V doplnění incident byl předán k doplnění. - V ověření incident byl vyřešen a čeká na ověření. - Vyřešený incident je připraven k uzavření, případně vyhodnocení. - Uzavřený incident byl uzavřen a vyhodnocen. 3.10.4 Popis procesních kroků Založení incidentu (IM100) Procesní krok řeší aktivity spojené se založením incidentu Zadavatelem. Zadavatel otevře v aplikaci BI JIRA (BIVOJ) příslušný formulář. Do formuláře vyplní požadované údaje a přiloží případné přílohy. Pokud je známo, jakého SLA se incident týká, uvede se jeho název. Obrázek 34: Workflow Založení incidentu Otevřený Otevření formuláře pro incident Sumarizace požadavku Příkaz k založení požadavku Založený Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. Klasifikace incidentu (IM200) Procesní krok řeší primárně aktivity spojené s prioritizací a klasifikací incidentu. Cílem procesního kroku je prioritizace incidentu, přiřazení konfiguračních položek a určení typu incidentu z pohledu člena role IM Operátor. 38

Obrázek 35: Workflow Klasifikace incidentu Založený Kontrola správnosti přiřazení incidentu Vyplnění podrobností incidentu Postoupení k řešení V řešení (Analýza) Doplnění komentáře Stornovaný Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. Analýza incidentu (IM300) Procesní krok řeší aktivity spojené s analýzou a diagnostikou incidentu. Cílem procesního kroku je především analyzovat incident. V tomto procesním kroku se rovněž zjišťuje, zda se již nevyskytl obdobný incident v minulosti a zda není evidován doporučený workaround 42 v procesu Problem Management. Obrázek 36: Workflow Analýza incidentu V řešení (Analýza) Převzetí požadavku Analýza incidentu Diagnostika incidentu Zapsání vykonané práce V řešení (Řešení incidentu) Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. Řešení incidentu (IM500) Procesní krok řeší aktivity spojené s řešením incidentu. Cílem procesního kroku je vyřešit nahlášený incident. Obrázek 37: Workflow Řešení incidentu V řešení (Řešení incidentu) Převzetí požadavku Řešení incidentu Doplnění komentáře Zapsání vykonané práce V ověření Přiřazení incidentu na jinou řešitelskou skupinu Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. 42 Dočasné řešení, díky kterému se odstraní incident či problém. Řešení není vnímané jako finální (cílový) stav. 39

Doplnění zadání incidentu (IM550) Procesní krok řeší aktivity spojené s doplněním zadání incidentu. Obrázek 38: Workflow Doplnění zadání incidentu V doplnění Doplnění komentářů Připojení příloh Předat ke zpracování V řešení (Řešení incidentu) Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. V ověření řešení (IM700) Procesní krok řeší aktivity spojené s ověřením vyřešeného incidentu ze strany Zadavatele. Cílem procesního kroku je ověřit, zda bylo řešení provedeno dle zadání incidentu. Obrázek 39: Workflow V ověření řešení V ověření Ověření řešení Doplnění komentářů Vyřešený Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. Vyhodnocení incidentu (IM900) Procesní krok popisuje aktivity spojené se zhodnocením řešení incidentu z hlediska průběhu procesu Incident Managementu a návrhem na opatření proti opakování incidentu. V případě opakovaných incidentů nebo těch, kterým lze obtížné předcházet, je schvalovatel povinen založit příslušný ticket v procesu Problem Management. Obrázek 40: Workflow Vyhodnocení incidentu Schválení řešení Vyhodnocení incidentu Uzavření ticketu Vyřešený Uzavřený Zdroj: Dokumentace procesu Incident Management, vlastní úpravy. 40

3.11 Problem Management Proces, který odpovídá za správu životního cyklu problémů. Primárním cílem procesu je minimalizace dopadu problémů na organizaci a evidence standardního řešení opakovaných incidentů v databázi známých chyb. Dalším cílem je zabránit vzniku problémů a z nich vyplývajících incidentů, odstranit opakující se incidenty a minimalizovat dopad incidentů, kterým nelze předejít. Problem Management hraje důležitou roli při detekci a prevenci vzniku problémů, jejich řešení za pomoci workaroundů a evidence známých chyb. Jedná-li se o založení problému na základě opakovaných incidentů, iniciuje typicky založení problému Incident Manager nebo ten, kdo vyhodnocuje incident. Problém je známá nebo neznámá příčina jednoho nebo více incidentů. Problem Management zkoumá příčinu incidentů, aby jim mohl předejít a incidenty se již neopakovaly. Problem Management se zaměřuje na systémové řešení chyb. 3.11.1 Role interagující s procesem - Zadavatel - Řešitel - Schvalovatel 1 - Schvalovatel 2 3.11.2 Životní cyklus Životní cyklus procesu Problem Managementu se skládá z minimálně 5, resp. maximálně 6 kroků, jež jsou vyobrazeny na níže uvedeném obrázku. Proces se může vázat na proces Incident Management. 41

Obrázek 41: Hlavní workflow procesu Problem Management Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. 3.11.3 Statusy procesu Proces může nabývat tyto stavy: - Otevřený problém je ve stavu otevřený, pokud jej ještě nikdo nezačal řešit. - Založený probíhá klasifikace problému a návrh workaroundu. - Stornovaný problém stornován. - V revizi probíhá schvalování workaroundu. - V doplnění problém je předán řešiteli k doplnění návrhu workaroundu. - V řešení předání problému k návrhu systémového řešení. - Vyřešený problém je připraven k vyhodnocení. - Uzavřený problém je vyhodnocen a uzavřen. 42

3.11.4 Popis procesních kroků Založení problému (PRM100) Procesní krok řeší aktivity spojené se založením ticketu Zadavatelem. Zadavatel ověří, že ještě daný problém neexistuje v Problem Managementu. Následně otevře příslušný formulář pro založení problému. Do formuláře vyplní specifikaci a přiloží případné přílohy. Cílem procesního kroku je shromáždit informace o problému a klasifikovat jej z hlediska priority problému a jednotlivých komponent. Obrázek 42: Workflow Založení problému Otevřený Otevření formuláře pro problém Sumarizace problému Klasifikace a prioritizace problému Prolinkování incidentů Založený Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. Analýza problému, návrh workaroundu (PRM300) Cílem procesního kroku je analyzovat problém, zjistit příčinu problému, popsat ji a navrhnout dočasné řešení (workaround). Obrázek 43: Workflow Analýza problému, návrh workaroundu Přiřadit na jiného řešitele nebo skupinu Založený Analýza problému Návrh workaroundu Postoupení ke schválení V revizi Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. Schvalování a revize (PRM400) Cílem kroku Schvalování a revize je schválit workaround, případně, jedná-li se o plošnou revizi, Schvalovatel 1 ověřuje, zda jsou problém a jeho workaround stále platné. 43

Obrázek 44: Workflow Schvalování a revize Přiřadit na jiného schvalovatele V revizi Schválení návrhu na workaround Doplnění komentáře V řešení Stornovaný V doplnění Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. Doplnění návrhu workaroundu (PRM450) Procesní krok je vykonán v případě, že je potřeba doplnit návrh na dočasné řešení (workaround) problému. Obrázek 45: Workflow Doplnění návrhu workaroundu V doplnění Doplnění komentářů, připojení příloh Předat ke schválení V revizi Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. Zplatnění workaroundu (PRM500) Cílem procesního kroku je evidovat záznam v databázi známých chyb o platném workaroundu až do doby, kdy bude problém vyřešen. V tomto kroku jsou zvážena možná řešení problému. 44

Obrázek 46: Workflow Zplatnění workaroundu Založení BI subtasku Závěrečné shrnutí V revizi Založení RFC a realizace změny Vyřešený Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. Vyhodnocení problému (PRM900) Procesní krok řeší aktivity spojené se zhodnocením řešení problému ze dvou hledisek: správnosti odstranění problému a zhodnocení průběhu procesu Problem Managementu. Cílem procesního kroku je vyhodnotit problém Schvalovatelem 1 a 2. Schvalovatel 2 při uzavření vybere rozhodnutí Vyřešené/Nevyřešené. Obrázek 47: Workflow Vyhodnocení problému Vyřešený Schválení vyřešení problému Schvalovatelem 1 Schválení vyřešení problému Schvalovatelem 2 Uzavření problému Uzavřený Zdroj: Dokumentace procesu Problem Management, vlastní úpravy. 3.12 Change Management Proces slouží pro nasazování nového nebo úpravu stávajícího řešení. 3.12.1 Role interagující s procesem - Zadavatel. - Participant. - Řešitel 1. - Řešitel 2. - Řešitel 3. - Schvalovatel. 45

3.12.2 Životní cyklus Životní cyklus procesu Change Managementu se skládá z minimálně 8, resp. maximálně 10 kroků, jež jsou vyobrazeny na níže uvedeném obrázku. Obrázek 48: Hlavní workflow procesu Change Management Zadavatel SDT_180 - Verifikace zadání SDT_350 - SDT_300 Řešení SDT_250 - Metadatová kontrola problému Kontrola ODWH SDT_550 SDT_500 Vytvoření prostředí Kontrola a nasazení řešení a založení objektů SDT_900 Schválení a uzavření Vyhodnocený - rozhodnutí: Pozitivní Negativní SDT_100 - Založení požadavku Change Management (Solution Deployment Task) Participant Řešitel 1 Řešitel 2 Průvodka nasazení SDT_150 - Doplnění požadavku Řešení problému SDT_300 Metadatová kontrola Řešení problému SDT_400 - Vytvoření prostředí a založení objektů Řešení problému SDT_500 Kontrola a nasazení řešení SDT_800 Kontrola výsledků SDT_850 - Řešení reklamace Řešení problému Řešitel 3 SDT_250 Kontrola ODWH Schvalovatel SDT_200 Schválení řešení k nasazení Zdroj: Dokumentace procesu Change Management, vlastní úpravy. 3.12.3 Statusy procesu Proces může nabývat tyto stavy: - Otevřený požadavek je ve stavu otevřený, pokud zatím není řešen. - V doplnění požadavek je předán k doplnění. - V řešení požadavek je založen a předán ke schválení. Status se může opakovat u více procesních kroků. - Schválený předání požadavku ke schválení členům role Schvalovatel. - Stornovaný požadavek je stornován. - V řešení požadavek je přiřazen řešitelské skupině a probíhají výkonné kroky k jeho vyřešení. 46

- V ověření požadavek je vyřešen a čeká na formální ověření. - Vyřešený požadavek je připraven k ověření. - K uzavření požadavek prošel procesním krokem Kontrola výsledků a byl předán ke schválení a uzavření. - Uzavřený požadavek je uzavřen a vyhodnocen Zadavatelem. 3.12.4 Popis procesních kroků Založení požadavku (SDT100) Procesní krok řeší aktivity spojené se založením požadavku členem role Zadavatel nebo Participant. Tento uživatel otevře formulář Solution Deployment a vyplní požadované údaje. Obrázek 49: Workflow Založení požadavku Otevřený Otevření formuláře Solution Deployment Sumarizace požadavku Příkaz k založení požadavku V doplnění Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Doplnění požadavku (SDT150) Procesní krok řeší aktivity spojené s připojením dokumentů nezbytných pro nasazení nového nebo úpravu stávajícího řešení. Obrázek 50: Workflow Doplnění požadavku Doplnění komentářů Připojení příloh Předat k ověření V doplnění V ověření Zdroj: Dokumentace procesu Change Management, vlastní úpravy. 47

Verifikace zadání (SDT180) Procesní krok řeší aktivity spojené s ověřením požadavku, zda obsahuje popis nasazení řešení a všechny přílohy pro nasazení nového nebo úpravu stávajícícho produkčního řešení. Obrázek 51: Workflow Verifikace zadání Doplnění komentářů Předat ke schválení V ověření V řešení Sumarizace problému V doplnění Stornovaný Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Schválení řešení k nasazení (SDT200) Procesní krok popisuje aktivity spojené s kontrolou požadavku, zda splňuje všechny náležitosti pro nasazení nového nebo úpravu stávajícího řešení. Po obdržení požadavku na schválení, člen role Schvalovatel zkontroluje obsah a komplexnost příloh založeného požadavku, případně vrátí požadavek na doplnění. Cílem procesního kroku je schválit navržené řešení z pohledu provozu DWH. Obrázek 52: Workflow Schválení řešení k nasazení V ověření (Kontrola ODWH) V řešení Přiřazení si požadavku Kategorizace změny Vývojová změna Posouzení úplnosti zadání Validace průvodky Kontrola splnění provozních parametrů Aktualizace plánu nasazení Schválený Stornovaný Operativní změna Doplnění komentáře V doplnění Kontrola správnosti řešení k nasazení Předání k testování V ověření (Kontrola a nasazení řešení) Zdroj: Dokumentace procesu Change Management, vlastní úpravy. 48

Kontrola operačních metadat (ODWH) (SDT250) Procesní krok řeší aktivity spojené s kontrolou operačních metadat 43. Obrázek 53: Workflow Kontrola operačních metadat V ověření (Kontrola ODWH) Převzetí požadavku ODWH kontrola Přidání komentářů Zapsání vykonané práce Schválený Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Metadatová kontrola (SDT300) Procesní krok řeší metadatovou kontrolu řešení vzhledem k platným metodikám BI KB pro produkční řešení. Obrázek 54: Workflow Metadatová kontrola Metadatová kontrola Kontrola IFPC Přidání komentářů Zapsání vykonané práce Schválený Převzetí požadavku Kontrola modelu z metadatové oblasti V ověření (Kontrola a nasazení řešení) Kontrola skriptu z metadatové oblasti Sumarizace problému V řešení (Řešení problému) Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Řešení problému (SDT350) Procesního krok řeší doplnění řešení nebo opravu zadání požadavku. 43 Řídící metadata, díky kterým se řídí ETL zpracování v KB EDWH. 49

Obrázek 55: Workflow Řešení požadavku Schválený V řešení (Řešení problému) Je problém oprávněný? ANO Řešení požadavku Zapsání vykonané práce V řešení (Vytvoření prostředí a založení objektů) V ověření (Kontrola a nasazení řešení) NE V ověření (Kontrola ODWH) Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Vytvoření prostředí a založení objektů (SDT400) Procesní krok řeší vytvoření databázového prostředí a založení nových databázových objektů. Obrázek 56: Workflow Vytvoření prostředí a založení objektů NE Vytvoření prostředí Převzetí požadavku V řešení (Vytvoření prostředí a založení objektů) Je potřeba vytvořit prostředí? ANO Potvrzení ED k založení prostředí Vytvoření kontejnerů Nastavení prostoru Vytvoření objektů a X objektů Zapsání vykonané práce V ověření (Kontrola a nasazení řešení) Nastavení práv Zapsání vykonané práce Sumarizace problému Zapsání vykonané práce V řešení (Řešení problému) Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Kontrola a nasazení řešení (SDT500) Procesní krok řeší aktivity spojené s kontrolou, testováním a nasazením řešení do produkčního prostředí. 50

Obrázek 57: Workflow Kontrola a nasazení řešení Přezaložit objekty? Převzetí požadavku Ověření řešení Nasazení řešení NE V ověření (Kontrola a nasazení řešení) ANO Vyřešený (Kontrola výsledků) Doplnění komentáře V řešení (Řešení problému) V řešení (Vytvoření prostředí a založení objektů) Doplnění komentáře Stornovaný Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Kontrola výsledků (SDT800) Procesní krok řeší aktivity spojené s ověřením výsledků řešení. Obrázek 58: Workflow Kontrola výsledků Vyřešený (Kontrola výsledků) Převzetí požadavku Ověření řešení Doplnění komentářů Zapsání vykonané práce K uzavření Sumarizace problému V reklamačním řízení Stornovaný Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Řešení reklamace (SDT850) Procesní krok řeší případnou reklamaci požadavku. 51

Obrázek 59: Workflow Řešení reklamace Je reklamace oprávněná? V reklamačním řízení Ověření nároku na reklamaci Zapsání vykonané práce Postoupit k ověření Vyřešený (Kontrola výsledků) Řešení požadavku Zdroj: Dokumentace procesu Change Management, vlastní úpravy. Schválení a uzavření (SDT900) Procesní krok řeší schválení a uzavření vyřešeného požadavku. Obrázek 60: Workflow Schválení a uzavření Schválit řešení Uzavřít požadavek K uzavření Uzavřený Zdroj: Dokumentace procesu Change Management, vlastní úpravy. 3.13 Navrhovaná doporučení pro implementaci ITILu v organizaci Níže uvedená doporučení jsou zobecněná doporučení, která je dobré zvážit při implementaci ITILu v organizaci. Tato doporučení vznikla na základě implementace metodického rámce ITIL v rámci prostředí BI KB, tj. velké finanční organizace. Doporučení lze primárně využít v rámci velkých (finančních i nefinančních) organizací, ale mohou sloužit pro inspiraci a poučení i pro střední organizace. 1. Detailně informujte a vyškolte všechny pracovníky, kterých se implementace ITILu dotkne Pokud se rozhodnete v rámci organizace (divize, oddělení) implementovat metodický rámec ITIL a tento záměr nezůstane utajen na úrovni managementu organizace (divize, oddělení), což od jisté fáze implementace musí dojít k odtajnění záměru. Postupujte tak, aby se v co nejkratším čase o tomto záměru dozvěděli všichni pracovníci, kteří budou změnou dotčeni (i minimalisticky). Je potřeba si uvědomit, že 52

ne manažeři, ale primárně řadoví pracovníci se budou na implementaci ITILu podílet, přinášet klíčové myšlenky a odrážet své zkušenosti s každodenní práce při tvorbě procesů. V rámci implementace ITILu v prostředí BI KB toto nebylo dodrženo a situace na začátku implementace byla zmatečná. Pro přiblížení, jak nezačínat s implementací ITILu je uveden příklad. V roce 2009 začala implementace ITILu v prostředí BI KB. Pracovníci BI byli informováni vedením BI, že začíná projekt OPERa, do kterého se postupně zapojí vybraní vedoucí oddělení či jiní vybraní pracovníci BI. O ITILu, mimo managementu BI, pracovníci nevěděli detaily. Situace v některých případech docházela tak daleko, že vyškolený na ITIL BI management vedl na schůzkách a jiných setkání diskuze o tom, jak je ITIL úžasný a jak se vybrané aktivity díky ITILu zjednoduší. Bohužel manažeři neustále zapomínali na to, že BI personál neprošel ani základním školením a tudíž většina naprosto netušila, co se pod pojmem ITIL skrývá. Po cca 6 měsících si management BI tuto skutečnost uvědomil a zorganizoval workshop pro všechny pracovníky BI. Bohužel tento workshop vedl konzultant z externí společnosti, který byl velmi dobrým a zkušeným odborníkem na implementaci ITILu, ale velmi špatný prezentátor. Workshop byl valnou většinou zaměstnanců vnímán jako fiasko, kdy nedošlo představení základních myšlenek a principů metodického rámce ITIL. Situace se postupně (během 2 let) vyřešila tak, že někteří manažeři svým lidem představili principy ITILu samostatně, či je poslali na externí školení nebo se lidé seznámili s ITILem samostudiem. Na výše uvedeném příkladu z prostředí BI KB je dobré si uvědomit, že při implementaci ITILu do organizace je nutné pracovníky vyškolit a seznámit s metodickým rámcem ITIL a poté začít s implementací ITILu. Nikoli naopak. Předejdete tím odmítavému stanovisku řadového personálu k ITILu a desítkám (či 53

stovkám) hodin schůzek, které nikam nevedou. 2. Stabilita na úkor flexibility Je velice důležité si uvědomit, co od zavedení metodického rámce ITIL očekáváte. Pokud zúžíme pohled pouze na dva faktory a to: stabilita a flexibilita, je nutné si uvědomit, že tyto dva faktory jsou spojené nádoby a vzájemně se ovlivňují. Úspěšné zavedení ITILu vám zcela jednoznačně přinese stabilní prostředí pro všechny zúčastněné strany (uživatele, pracovníky, aj.) v rámci organizace, ale na úkor flexibility. Mějte na paměti, že čím vyšší svázání aktivit v rámci procesů provede, tím bude prostředí stabilnější, ale tato stabilita snižuje míru flexibility. 3. Vybírejte si vhodné lidské zdroje Nezapomínejte na to, že po zavedení ITILu se může spoustě pracovníků změnit náplň práce. Činnosti, které před implementací ITILu mohly být velice kreativní, protože zde existoval velký prostor pro vlastní realizaci, může být po implementaci ITILu vnímána jako mechanická a málo kreativní. Aktivity se totiž jasně popíší, standardizují a mají ve většině případů jasný řád, což některým typům osobností může vadit. Pracovníci, kteří přijdou s procesy do styku, budou zatíženy větší operativní prací. Přemýšlejte proto, zda pracovníci, kteří tyto aktivity prováděli před implementací, jsou schopni absorbovat větší míru rutinní práce a zda je tato rutinní práce nebude demotivovat. 4. Cena služeb může být dražší Při úváhách o tom, zda chcete zavést ITIL ve vaší organizaci, je důležité si uvědomit, že s velkou pravděpodobností dojde ve vaší organizaci ke zvýšení pracnosti při řešení požadavků, resp. ceny vašich poskytovaných služeb. Při prosazování záměru implementace ITILu u managementu organizace proto doporučuji nemít hlavní argument to, že dojde ke snížení ceny jednotlivých služeb. Naopak s velkou pravděpodobností dojde k opaku. Jako jedny z hlavních argumentů doporučuji: snížení rizik spojených s nedodáním klíčových služeb organizaci (interním či externím 54

klientům), zvýšení dostupnosti služeb, resp. snížení výpadku služeb, zrychlení dodávky služeb aj. 5. Vnímejte rady ostatních, ale jdete svou vlastní cestou ITIL není krabicové řešení, každá implementace je velice odlišná a různorodá. Před implementací se dívejte kolem sebe, nejlépe do podobných institucí, kde již ITIL mají. Pokud máte možnost, jděte na referenční návštěvu. Existuje mnoho implementací ITILu, které jsou naimplementovány napůl nebo neefektivně. Velice dobrou cestou je si najmout externí konzultanty, optimálně alespoň ze dvou firem a od nich požadovat návrhy, které vaši interní lidé zrevidují a přizpůsobí vašim podmínkám. Samozřejmě, že existuje i opačná cesta: vytvořit interní návrh, který bude podroben externí oponentuře. Přemýšlejte nad každým detailem a berte v úvahu to, že implementace ITILu je velice individuální v každé organizaci. 6. Integrujte své ITIL procesy do již stávajícího software organizace Pokud v rámci vaší organizaci využíváte software (např. centrální servis desk software), který umožňuje vaše procesy integrovat a pojmout, využijte toho. Dívejte se na implementaci ITILu pohledem uživatelů, pro které finálně implementaci realizujete. Uživatelé (ať v roli realizátora úkolu či odběratele služby) velice přivítají pokud nově implementované procesy budou integrovány do již stávajícho software. Díky tomu eliminujete odpor k novému softwarovému nástroji a budete se moci soustředit na klíčovou změnu zavedení ITILu. Věřte, že minimálně starší či méně flexibilní (s větší rezistencí ke změně) zaměstnance si tímto krokem nakloníte a bude moci komunikovat kritické faktory změny. 7. Perfektní uživatelská dokumentace Nezapomeňte na to, že v rámci implementace ITILu vzniknou procesy, které ne vždy budou triviální a lehce zapamatovatelné. Proto klaďte velký důraz na výbornou dokumentaci všech nově vzniklých procesů. Jako velice vhodné se ukazuje využít portálové řešení (typu wiki), které slouží jako dokumentace a zároveň uživatelé mohou 55

přidávat komentáře a postřehy pro zlepšení procesů. Dokumentace procesů by měla umožňovat fulltextové vyhledávání, což je pro většinu portálových řešení v dnešní době běžné. Pokud v rámci organizace (divize, oddělení) již máte portálové řešení, zakomponujte dokumentaci procesů do tohoto systému. Dokumentace implementovaných procesů bude mít podobný grafický layout jako ostatní dokumenty organizace, bude možné využívat prolinkování na ostatní procesy a dokumenty organizace apod. 8. Držte vhodnou míru abstrakce a granularity V rámci implementace ITILu a procesů berte v úvahu, že pokud sebemenší aktivity svážete procesem a půjdete do nejnižší možné granularity, dostane tím obrovskou stabilitu (zejména pro zákázníky), kdy každý řešitel bude nucen aktivitu víceméně řešit stejně, ale na druhou stranu tím řešitele nutíte vykonávat někdy až monotónní práci s minimálním podílem kreativity. To kreativní a tvůrčí zaměstnance brzy přestane bavit. Jak již bylo popsáno v bodě 3), je nutné při zavádění ITILu myslet i na tento HR aspekt. ITIL má organizaci přinést stabilitu a zlepšení služeb pro zákazníky, ale dle mého názoru by měl zachovat jistou míru kreativity při řešení zákaznicnických požadavků a poskytování služeb. 9. Respektujte již zavedené definice pojmů Při zavádění procesů se držte již zavedených pojmů organizace. Nové pojmy a názvy vymýšlejte tehdy, pokud tento pojem opravdu neexistuje nebo je použit pro jiné účely. Předejte tím zbytečným zmatkům, kdy každá ze stran bude mluvit sice o stejném pojmu, ale s jiným významem nebo o stejném významu s jiným pojmenováním. 10. Opravdový leader je nutná nikoli postačující podmínka Pokud jste se rozhodli úspěšně implementovat ITIL a procesy ve vaší organizaci, divizi či oddělení veřte, že je to velice nelehký úkol a dlouhodobá aktivita. Dobře si 56

rozmyslete, komu tento projekt svěříte. Implementace ITILu bude mít obrovský dopad na vaše aktivity v organizaci (divizi, oddělení), a proto je potřeba tento projekt svěřit opravdovému leadrovi. Zde lze použít citát, že kdo chce zapalovat, musí sám hořet. Tento leader, ať už je to projektový nebo liniový manažer či vybraný jedinec organizace, musí být přirozená autorita vnímaná a podporovaná většinou, musí být schopen řídit lidi, nekonfliktně vyjednávat, řídit se winwin strategií. Zároveň musí být v přiměřené míře technického detailu, znát do určité míry aktivity, které transformuje do procesního řízení. Člověk, který bude zodpovědný za implementaci ITILu by měl být vyzrálá osobnost, dotahovač a měl by lidi spojovat, nikoliv rozdělovat. V neposlední řadě nezapomeňte na to, že pokud takového člověka máte a rozhodnete mu svěřit implementaci ITILu, tak ještě předtím než mu ji svěříte, zeptej se ho, zda o tuto pozici (roli) stojí. On (ona) sám musí být přesvědčen, že dosáhne vytýčených cílů. Pokud to myslíte s implementací ITILu vážně a chcete se řadit mezi organizace, ve kterých je ITIL a procesy naimplementovány úspěšně, pak dle mého názoru bod 10) je nejdůležitější a nejvíc markantní faktor, který vaši implementaci zařadí mezi špatné, průměrné či nadprůměrné. 3.14 Navrhovaná doporučení pro prostředí BI KB Níže formulovaná doporučení jsou zaměřeny na prostředí BI KB. Doporučení poskytují konkrétní postup, který při realizaci povede ke zlepšení procesního řízení v prostředí BI KB. 1. Změnit software (JIRA), ve kterém jsou procesy implementovány Software JIRA je primárně určen jako podpůrný nástroj pro softwarový vývoj, který umožňuje částečnou customizaci a nastavení vlastních workflow, ale jako podpůrný softwarový nástroj pro procesy ITIL není zcela vhodný. Nelze říci, že je zcela nepoužitelný či kategoricky nevyhovující, ale v některých případech je pro uživatele 57

matoucí a nekomfortní není zcela jasné, v jakém procesním kroku se uživatel nachází, do jakého kroku má pokračovat a co má v kroku vykonat. Pokud uživatel nepracuje s konkrétním procesem každodenně, musí neustále využívat dokumentaci procesů, což ve výsledku vede k neoptimálnímu využívání lidských zdrojů v podobě zdlouhavého zpracování uživatelem. Podpůrný software by měl být více uživatelsky přívětivý a zároveň návodný, tj. měl být schopen uživatelé vést, co má v daném kroku udělat, dávat mu nápovědu, kam se v rámci procesu může pohybovat. Navrhuji dvě alternativní řešení: a. Integrovat BI procesy do centrální servisdeskového nástroje KB. Nebo: b. Nalézt jiný vhodnější softwarový nástroj. Varianta a) přinese benefity v podobě jednotné softwarové platformy, což pro uživatele bude značně přehlednější, protože požadavky mimo BI řeší v rámci centrálního Servisdeskového nástroje KB. Integrace přinese lepší napojení na ostatní procesy KB, které jsou v rámci této platformy již integrovány. V neposlední řadě je tato platforma uživatelsky přívětivější než software JIRA a to z důvodu, že je její primární účel je podpora procesů (nejen procesy založené na ITILu). Uživatele jasně a návodně směřuje bez použití dokumentace konkrétních procesů. Varianta b) je alternativou pokud není možné přejít kvůli jiným objektivním důvodům (nedostatek zdrojů v rámci banky, BI management nepodporuje tuto variantu aj.) na centrální servisdeskovou platformu KB. V případě realizace této varianty doporučuji tento postup: - Otevřít projekt na novou softwarovou platformu BI procesů. - Definovat specifikaci, co by měla tato platforma splňovat s akcentem na: 58

- primární zaměření na podporu procesního řízení, - vysoká uživatelská přívětivost, - přijatelná (nízká) nákupní cena a poplatky za podporu platformy. - Pro platformy, které splňují definovanou specifikaci realizovat PoC 44 (Proof of Concept). - V rámci PoC platformy definovat vybranou uživatelskou množinu testerů, kteří ohodnotí, jak jsou s platformou spokojeni, resp. zda splňuje naspecifikované požadavky. - Finální výběr platformy. - Implementace procesů do nové platformy. - Pilotní provoz (PoT 45 ). - Školení uživatelů. - Přechod k běžnému provozu platformy. 2. Zavést reporting nad sledovanými parametry V současné době není vytvořen reporting nad sledovanými (měřenými) parametry procesů, který by měl sloužit pro pravidelnou revizi procesů zda některé procesní kroky netrvají neúměrně dlouho a nedochází tím k neefektivnímu využívání lidských, resp. finančních zdrojů KB. Navrhuji tento postup pro vytvoření reportingu: - Specifikovat sledované parametry pro report - Vytvořit datovou základu pro report a to tímto postupem: - Připravit datový model úložiště. 44 Ověření, zda je produkt života schopný v rámci dané organizace. 45 Proof of Technology neboli prototyp či pilotní provoz. 59

- Na základě modelu vygenerovat datové tabulky a struktury v prostředí Teradata. - Vytvořit ETL workflow, které bude pravidelně transformovat data z repozitory (datové uložiště) softwarového nástroje (aktuálně JIRA) do datových struktur prostředí Teradata. - Vytvořit report (či datovou kostku) v reportingovém prostředí Cognos. - Nalézt vlastníka (gestora), který bude pravidelně sledovat a analyzovat měřené parametry. Výsledky analýz předkládat BI managementu či vlastníkům procesů pro případné optimalizace. 3. Zlepšit dokumentaci procesů Dokumentace BI procesů je uložena ve MS Wordu nebo v BI Wiki systému, do kterého je pravidelně z MS Word exportována. Díky tomu, že není zajištěná pravidelná aktualizace exportu (např. jednou za den) dochází k nekonzistenci dokumentace v BI Wiki systému. Navrhuji tuto aktivitu automatizovat, resp. tento postup pro dokumentaci procesů: - Primární zdroj pro editaci dokumentace je udržován v dokumentech typu MS Word. - Primární zdroj dokumentace (MS Word) je každé ráno a večer automaticky exportován pomocí BI nástroje Informatica PowerCenter, který umožňuje načíst strukturu formátu MS Wordu a následně zpracován a exportován do formátu BI Wiki systému (HTML). Díky tomuto postupu je dosaženo, že primární zdroj pro čtení dokumentace (BI Wiki systém) je konzistentní s podkladovým MS Wordem. 60

4. Vyškolení BI pracovníků, resp. pravidelné semináře Současný stav vyškolenosti BI pracovníků, kteří každodenně přicházejí do styku s ITIL procesy, vnímám jako nevyhovující pracovníci nemají stále jasno v implementovaných procesech zejména díky tomu, že v procesech dochází ke změnám. Navrhuji zavést dva typy interních BI seminářů (workshopů) v pravidelných měsíčních, resp. čtvrtletních intervalech: - Dobrovolný, který je na měsíční bázi a není povinný. Záleží pouze na BI pracovníkovi, zda se chce zúčastnit a aktualizovat si novinky či změny, ke kterým došlo. - Povinný, který se uskutečňuje jednou za čtvrt roku, absolvování je povinné pro všechny BI pracovníky. Cílem tohoto povinného workshopu je aktualizovat vědomosti BI pracovníků a informovat je o změnách, ke kterým došlo za uplynulé období. Školitelé těchto workshopu by měli být z řad vlastníků (gestorů) jednotlivých procesů. Workshop by neměl trvat neúměrně dlouhou dobu, cca 1 hodinu, max 2 hodiny. 5. Navázat procesy Requirement Management a Change Managementu na celobankovní proces Projektového řízení Současná vazba mezi Requirement Managementem a Change Managementem nereflektuje celobankovní proces Projektového managementu, který logicky spadá mezi tyto dva procesy. Navrhuji spojit proces Requirement Management a Change Management procesem Projektového managementu. Následně implementovat níže uvedené workflow do podpůrného softwarového nástroje. Návrh je vyobrazen na obrázku níže. 61

Obrázek 61: Integrace Projektového managementu do BI ITIL procesů Incident Management Problem Management Help Desk Requirement Management Project Management Change Management IM100 Creation and pre-analysis of incident PM100 Creation and pre-analysis of problem HD100 Creation and pre-analysis of requirement RM100 Creation and pre-analysis of requirement PM100 Idea Formulation CH100 Creation of RFC IM200 Classification and categorization of incident PM200 Classification and categorization of problem HD200 Classification and categorization of requirement RM200 Classification of requirement PM200 Project Definiton CH200 Classification of RFC IM300 Analysis, diagnosis of incident IM500 Solution and recovery of incident PM300 Analysis, diagnosis of problem PM500 Solution of problem, Known Error HD500 Solution of requirement Support, Maintanace PM500 Solution Design CH 500 Solution of RFC RM500 Design and evaluation of effort, risk IM700 Verification IM800 Approval PM700 Verification HD700 Verification HD800 Approval RM800 Approval to Implementation Project, Small Enhancement PM600 Implementation PM800 Approval/Acceptance CH600 Deployment CH 800 Approval IM900 Evaluation, closure PM900 Evaluation, closure HD900 Evaluation, closure RM900 Closure PM900 Evaluation, closure CH 900 Evaluation, closure Zdroj: BIVOJ Guideline, vlastní úpravy. Procesní krok Idea Fomulation (PM100) Cílem tohoto kroku je: - Popsat nový záměr/myšlenku. - První pohled na náklady & přínosy (Business Case). - Identifikovat Responsible bankera 46 a Sponzora, který bude projekt podporovat. - Ohodnotit záměr z pohledu architektury. - Přiřadit projektového manažera. - Vytvořit projektový plán a sestavit projektový tým. - Identifikovat a popsat rizika. 46 Stanovená osoba, která jako zástupce sponzora projektu formuluje, upřesňuje a vysvětluje obchodní zadání projektu (potřeby a požadavky, stejně jako současný a cílový stav procesů). Zároveň tato osoba akceptuje (za klienta projektu) výstupy projektu. 62

- Připravit prezentaci. - BI schválení. Obrázek 62: Návrh procesního kroku Idea Formulation Stornovaný Založení IF dokumentu Popis cílů a benefitů Vytvoření Business Casu (náklady) Revize architektury K doplnění Schválení Sponzorem a Responsible bankerem Identifikace PM Tvorba projektového plánu, rizik a prezentace BI schválení Ke schválení pro KB management Stornovaný K doplnění Stornovaný K doplnění Zdroj: Vlastní návrh. Procesní krok Solution Design (PM200) Cílem tohoto kroku je: - Ukotvit ( zafixovat") rozsah (cíle), trvání, náklady & přínosy a pracnost projektu. - Nalézt, analyzovat a vyhodnotit alternativní řešení a doporučit jedno z nich. - Validace projektového plánu, týmu, rizik a nákladů. - Příprava prezentace. - BI schválení. 63

Obrázek 63: Návrh procesního kroku Project Definition Založení PD dokumentu Analýza řešení Tvorba alternativ řešení Výběr řešení K doplnění Validace základních projektových parametrů (náklady, plán, rizika, čas aj.) Příprava prezentace BI schválení (Sponzor, Responsible banker) Ke schválení pro KB management K doplnění K doplnění K doplnění Zdroj: Vlastní návrh. Procesní krok Solution Design (PM500) Cílem tohoto kroku je: - Rozpracovat požadavky a architekturu řešení. - Potvrdit rozsah projektu, trvání, náklady & přínosy a pracnost. - Připravit a naplánovat fázi Implementation. - Připrava prezentace. - BI schválení. Obrázek 64: Návrh procesního kroku Solution Design Založení SD dokumentu Tvorba architektury řešení Plán pro implementační fázi Revize nákladů a rizik Validace základních projektových parametrů (náklady, plán, rizika, čas aj.) Příprava prezentace BI schválení (Sponzor, Responsible banker) Ke schválení pro KB management K doplnění Zdroj: Vlastní návrh. K doplnění K doplnění 64

Procesní krok Implementation (PM600) Cílem tohoto kroku je: - Vytvořit detailní funkční specifikaci. - Vyvinout a otestovat řešení. - Předat řešení k nasazení do provozu. Obrázek 65: Návrh procesního kroku Implementation K doplnění Tvorba Funkční specifikace Architektonické schválení Funkční specifikace Implementace Testování K nasazení K doplnění Zdroj: Vlastní návrh. Procesní krok Approval/Akceptance (PM800) Cílem tohoto kroku je: - Akceptovat (z pohledu projektu) řešení, které bylo vyvinuto. 65

Obrázek 66: Návrh procesního kroku Approval/Akceptance Řešení bylo úšpěšně nasazeno v rámci procesu Change Managementu Ano Akceptace řešení K uzavření Ne Zdroj: Vlastní návrh. Předání na dodavatele/vývoj K doplnění Procesní krok Evaluation/Closure (PM900) Cílem tohoto kroku je: - Zhodnocení. - Uzavření. - Příprava prezentace. Obrázek 67: Návrh procesního kroku Evalution/Closure K doplnění Zhodnocení projektu (Best Practises pro další projekty) Příprava uzavíracích materiálů BI schválení (Sponzor, Responsible banker) K uzavření na úrovni KB Zdroj: Vlastní návrh. 66

4 Závěr Tématem diplomové práce je implementace metodického rámce ITIL v prostředí Business Intelligence Komerční banky. Práce je členěna na teoreticko-metodologickou a praktickou část. Teoretická část práce se zabývá procesy, resp. procesním řízením v organizaci, notací BPMN a metodickým rámcem ITIL. Praktická část práce se věnuje implementaci metodického rámce v prostředí oddělení BI KB, navrhuje obecná doporučení pro implementaci ITILu mimo prostředí tohoto oddělení a formuluje soubor doporučení pro zefektivnění procesního řízení v rámci tohoto oddělení. První kapitola teoretické části definuje procesy a procesní řízení v organizaci. Kapitola podtrhuje důležitost a pozitiva pro organizaci. Proces je interpretován jako: soubor činností, které přeměňují vstupy na výstupy s tím, že zákazníkovi přinášejí požadovanou hodnotu. Zákazník je orientován na službu či produkt a ostatní činnosti, které se pojí s vlastní dodávkou jsou zákazníkovi skryty. Druhá kapitola teoretické části se zabývá notací BPMN, která se řadí mezi nejpoužívanější nástroje pro popis a interpretaci procesů v organizaci. Standard BPMN poskytuje podnikům schopnost pochopit jejich (vnitřní) procedury a procesy pomocí grafického zápisu a tím umožní organizacím komunikaci těchto postupů standardním způsobem. Kapitola podává základní přehled o jednotlivých elementech notace včetně jejich grafického znázornění. Celkový výčet elementů notace BPMN je uveden v příloze této diplomové práce. Třetí kapitola teoretické části prezentuje výklad metodického rámce ITIL, který zahrnuje a popisuje nejlepší praktiky (best practices), jak přistupovat a řídit IT služby v organizaci. ITIL se řadí v posledních letech mezi nejrozšířenější přístupy k řízení IT služeb na světě. Poskytuje ucelený soubor osvědčených postupů, které byly shromážděny z veřejného a soukromého sektoru pro oblast IT. Čtenáři je poskytnut přehled o jednotlivých fázích životního cyklu ITILu Service Strategy (Strategie služeb), Service Design (Návrh služeb), Service Transition (Přechod služeb), Service Operation (Provoz služeb) a Continual Service Improvement (Neustálé zlepšování 67

služeb). Hlavní výstup a přínos praktické části práce je formulace souboru doporučení pro prostředí BI KB, které při realizaci povedou k zefektivnění implementovaných procesů dle metodického rámce ITIL. Soubor doporučení je zobecněn i mimo prostředí BI KB a může sloužit velkým a středním organizacím jako inspirace a ponaučení při implementaci ITIL procesů. V diplomové práci jsou použity analytické a syntetické metody. Analytická metoda je použita pro popis aktuálního stavu (AS-IS) implementace ITILu v BI KB. Syntetická metoda je využita pro návrh a soubor doporučení (TO-BE) pro prostředí BI KB. Úvodní část praktické části je věnována představení KB, resp. oddělení BI s cílem představit kontext a komplexnost prostředí. Tato část práce nabízí přehled služeb, které jsou poskytovány v rámci Skupiny KB. Útvar BI spadá do úseku Financí a Strategie a je zodpovědný za koordinaci, vývoj a provoz jednotné informační základny založené na požadavcích uživatelů v rámci KB, za funkční design analytického centrálního datového skladu (Data Warehouse) a jeho části (Data Marts), za design řešení pro sdílení dat, výkaznictví a podporu analytických požadavků zahrnující získávání dat v různých dimenzích statistické analýzy a data mining. BI poskytuje služby cca 7 tisícům uživatelů ze Skupiny KB, kdy tyto služby (reporting, datové kostky, přímý přístup k datům, aj.) jsou poskytovány napříč všemi úrovněmi řízení až na úroveň bankovních poradců. Další kapitoly praktické části práce prezentují vlastní implementaci metodického rámce ITIL v prostředí BI KB. V rámci těchto kapitol je představena (pomocí BPMN) implementace jednotlivých procesů (Help Desk, Requirement Management, Incident Management, Problem Management, Change Management). Help Desk eviduje, řeší a řídí požadavky přicházející na BI od zákazníků (KB, dceřiné společnosti KB) nebo BI interních uživatelů. Proces pokrývá založení, ohodnocení, ocenění a přiřazení rozhodnutí o schválení či neschválení požadavků na BI zadaných interními uživateli nebo zákazníky. 68

Requirement Management eviduje, analyzuje, oceňuje a řídí požadavky na BI na vytvoření nové nebo změnu stávající služby. Proces pokrývá založení, ohodnocení, ocenění a přiřazení rozhodnutí o schválení či neschválení požadavků na BI zadaných interními uživateli nebo zákazníky. Incident Management odpovídá za správu životního cyklu incidentů. Primárním cílem procesu je rychlé obnovení provozu služeb pro uživatele. Incident Management má za úkol obnovit službu v co nejkratším čase a s co nejmenším dopadem na odběratele služeb. Problem Management spravuje životní cyklus problémů. Primárním cílem procesu je minimalizace dopadu problémů na organizaci a evidence standardního řešení opakovaných incidentů v databázi známých chyb. Problem Management hraje důležitou roli při detekci a prevenci vzniku problémů, jejich řešení za pomoci workaroundů (dočasné řešení) a evidence známých chyb. Change Management pokrývá životní cyklus nasazování nového nebo úpravu stávajícího BI řešení do produkčního prostředí. Cílem procesu je eliminovat výskyt nestandardního či chybného chování v produkčním prostředí BI. Předposlední kapitola praktické části formuluje 10 zobecněných doporučení, která vznikla na základě zkušeností v rámci implementace metodického rámce ITIL v prostředí BI KB. Tyto doporučení jsou formulována na základě zkušeností ve velké finanční instituci, ale je možné se jimi inspirovat i pro velké a střední nefinanční organizace. Formulovaná zoběcněná doporučení jsou tato: detailně informujte a vyškolte všechny pracovníky, kterých se implementace ITILu dotkne; stabilita na úkor flexibility; vybírejte si vhodné lidské zdroje; cena služeb může být dražší; vnímejte rady ostatních, ale jděte svou vlastní cestou; integrujte své ITIL procesy do již stávajícího software organizace; perfektní uživatelská dokumentace; držte vhodnou míru abstrakce a granularity; respektujte již zavedené definice pojmů; opravdový leader je nutná nikoli postačující podmínka. 69

Poslední formulované doporučení se řadí mezi nejdůležitější a nejvíc markantní faktor, který vaši implementaci zařadí mezi špatné, průměrné či nadprůměrné. Pokud jste se rozhodli úspěšně implementovat ITIL a procesy ve vaší organizaci, divizi či oddělení veřte, že je to velice nelehký úkol a dlouhodobá aktivita. Dobře si rozmyslete, komu tento projekt svěříte. Implementace ITILu bude mít obrovský dopad na vaše aktivity v organizaci (divizi, oddělení) a proto je potřeba tento projekt svěřit opravdovému leadrovi. Tento leader, ať už je to projektový, liniový manažer či vybraný jedinec organizace, musí být přirozená autorita vnímaná a podporovaná většinou, musí být schopen řídit lidi, nekonfliktně vyjednávat, řídit se win-win strategií. Zároveň musí být v přiměřené míře technického detailu, znát do určité míry aktivity, které transformuje do procesního řízení. Člověk, který bude zodpovědný za implementaci ITILu by měl být vyzrálá osobnost, dotahovač a měl by lidi spojovat, nikoliv rozdělovat. Poslední kapitola praktické části práce formuluje 5 doporučení pro prostředí BI KB, které při realizaci povedou k efektivnějšímu procesnímu řízení. Formulovaná doporučení jsou rozpracována do konkrétní podoby s návodným postupem, jak tato doporučení implementovat a tím zefektivnit ITIL implementaci v rámci oddělení BI. Formulovaná doporučení jsou tato: změnit software (JIRA), ve kterém jsou procesy implementovány; zavést reporting nad sledovanými parametry; zlepšit dokumentaci procesů; vyškolení BI pracovníků, resp. pravidelné semináře; Navázat procesy Requirement Management a Change Managementu na celobankovní proces Projektového řízení. Diplomová práce se nezabývá návrhem nových procesů v rámci životních cyklu ITILu, protože to je nad rámec práce. V budoucnu je velice vhodné a doporučené se zamyslet nad další integrací nových procesů z životního cyklu ITILu např. implementovat proces Capacity Managementu v rámci fáze Service Design či Financial Management v rámci fáze Service Strategy. Stanovené cíle teoretické i praktické části diplomové práce jsou naplněny. 70

Literatura Primární zdroje KOMERČNÍ BANKA. BIVOJ Guideline. 2012. KOMERČNÍ BANKA. Dokumentace procesu Help Desk. 2011. KOMERČNÍ BANKA. Dokumentace procesu Change Management. 2011. KOMERČNÍ BANKA. Dokumentace procesu Incident Management. 2011. KOMERČNÍ BANKA. Dokumentace procesu Problem Management. 2011. KOMERČNÍ BANKA. Dokumentace procesu Requirement Management. 2011. KOMERČNÍ BANKA. Metodika modelování procesů. 2012. KOMERČNÍ BANKA. Notace modelování business procesů. 2010. Monografie ŠMERDA, Miroslav. Řízení informatiky v malých a středních podnicích. Praha, 2007. Bakalářská práce. VŠE Praha, Fakulta informatiky a statistiky, Katedra systémové analýzy. Vedoucí práce Petr Doucek. Odborné knihy a časopisy ARRAJ, Valerie. ITIL: The Basics. OGC, 2010. Dostupné z: http://www.best-managementpractice.com/gempdf/itil_the_basics.pdf. KNELLER, Maggie. The Benefits of ITIL. OGC, 2010. Dostupné z: http://www.bestmanagement practice.com/gempdf/ogc_executive_briefing_benefits_of_itil.pdf. ŘEPA, Václav. Podnikové procesy: procesní řízení a modelování. 2., aktualiz. a rozš. vyd. Praha: Grada, 2007, 281 s. ISBN 978-80-247-2252-8. 71

SVOZILOVÁ, Alena. Zlepšování podnikových procesů. 1. vyd. Praha: Grada, 2011, 223 s. ISBN 978-80-247-3938-0. ŠMÍDA, Filip. Zavádění a rozvoj procesního řízení ve firmě. 1. vyd. Praha: Grada, 2007, 293 s. ISBN 978-80-247-1679-4. OGC. Continual service improvement. United Kingdom: The Stationery Office, 2007, 221 s. ISBN 978-01-133-1049-4. OGC. Introduction to the ITIL service lifecycle. United Kingdom: The Stationery Office, 2010, 247 s. ISBN 978-01-133-1131-6. OGC. Service design. United Kingdom: The Stationery Office, 2007, 334 s. ISBN 978-01-133-1047-0. OGC. Service operation. United Kingdom: The Stationery Office, 2007, 263 s. ISBN 978-01- 133-1046-3. OGC. Service strategy. United Kingdom: The Stationery Office, 2007, 264 s. ISBN 978-01- 133-1045-6. OGC. Service transition. United Kingdom: The Stationery Office, 2007, 261 s. ISBN 978-01- 133-1048-7. Internetové zdroje COBIT kontrolní rámec pro IT Governance [online]. 2007 [cit. 2012-03-26]. Dostupné z: http://www.itil.cz/index.php?id=929. COBIT Brochure [online]. 2011 [cit. 2012-04-29]. Dostupné z: http://www.isaca.org/knowledge-center/cobit/documents/cobit-4.1-brochure.pdf. ERNST & YOUNG. Dvě třetiny českých společností již snížily náklady, teď je třeba pokračovat v důsledné optimalizaci procesů [online]. 2012 [cit. 2012-03-26]. Dostupné z: http://www.ey.com/cz/cs/newsroom/news-releases/2012_dve-tretiny-ceskych-spolecnosti-jizsnizily-naklady. 72

ISO/IEC 27000 [online]. 2012 [cit. 2012-03-26]. Dostupné z: http://www.iso27000.cz/. Six Sigma [online]. 2011 [cit. 2012-03-26]. Dostupné z: http://www.6s.cz/. Základní fakta [online]. 2010 [cit. 2012-03-26]. Dostupné z: ITIL - IT Service Management. ITIL - Homepage [online]. [cit. 2011-11-14]. Dostupné z: http://www.itil.cz/. KOMERČNÍ BANKA. Komerční banka: Základní informace [online]. 2010 [cit. 2012-02-12]. Dostupné z: http://kb.cz/cs/o-bance/o-nas/zakladni-informace.shtml. Object Management Group: Business Process Model and Notation [online]. 2012 [cit. 2012-03- 25]. Dostupné z: http://www.bpmn.org/. Proč zavádět ITIL [online]. 2007 [cit. 2012-03-26]. Dostupné z: http://itil.cz/index.php?id=988. http://www.togaf.cz/index.php?option=com_content&view=article&id=11:hlavnistranka&catid=1:hlavni-kategorie. 73

Přílohy Příloha 1: BPMN 2.0 Zdroj: bpmb.de/poster.