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 / [email protected] / 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 / [email protected] / 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

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.

BPMN

Business Process Modeling Notation.

BIVOJ

BI Version of JIRA.

DWH

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).

ED

Environment Definition. Definice databázového prostředí a objektů v prostředí BI KB.

EDWH

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.).

IFPC

Informatica PowerCenter. ETL nástroj, který zajištuje load (načtení), transformaci a extrakci (čištění) dat.

IQ

Information Quality.

ITIL

Information Technology Infrastructure Library

JIRA

Software na sledování chyb, aktivit, úkolů, projektů, lidí a zdrojů.

Ticket

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 BPEL9 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 Group10 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


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


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


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


14


15


16


8

Obrázek 6: Subproces v BPMN.


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

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


18


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


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


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


23


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áze30: - 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


33


34


35


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


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 JIRA38, resp. v systému BIVOJ39, 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

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

PM300 Analysis, diagnosis of problem

IM500 Solution and recovery of incident

PM500 Solution of problem, Known Error

Support, Maintanace

IM100 Creation and pre-analysis of incident

HD500 Solution of requirement

CH 500 Solution of RFC

IM700 Verification

HD700 Verification

PM700 Verification

HD800 Approval

RM800 Approval to Implementation

HD900 Evaluation, closure

RM900 Closure

IM800 Approval

IM900 Evaluation, closure

PM900 Evaluation, closure

Project, Small Enhancement

RM500 Design and evaluation of effort, risk

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

CH600 Deployment

CH 800 Approval

CH 900 Evaluation, closure

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í X500 ticketu Ř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 metrik40 slouží jako KPI41 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


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í Požadavek na Storno

podproblémy

Stornovat Doplnění požadavku Upravení povinných a nepovinných atributů

Stornovaný

Přidělení úkolů

Ne Přiřazení si požadavku

Změna kategorie a služby

Připojení příloh

Vytvoření komentářů

Výběr řešitele požadavku

Založení nového SD pro každou „neatomickou“ část původního SD

Zapsání vykonané práce

Otevřený

Stornovat Notifikace zadavatele obsahující sumarizaci

Stornovaný

Je SD atomicke? Ano Označit jako založený Založený


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


Doplnění komentářů

Předat ke zpracování

V doplnění

Otevřený

Stornovat Stornovaný


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? Kontrola správnosti přiřazení požadavku

Postoupit k řešení Ano V řešení

Založený

Vrátit k novému přiřazení řešitele

Zapsání komentáře

V doplnění


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

Ano K doplnění


Výběr kategorie a nové řešitelské skupiny

Označit jako založený Doplnění komentářů

Nutná změna řešitelů?


28

Založený

Ř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


Přidělení úkolů

Postoupit k ověření

V řešení

K ověření Požadavek je neřešitelný


Označit jako neřešitelný K ověření (s příznakem)


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í

V řešení


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ě

Ano

Ověření řešení


Postoupit k ověření zadavatelem Vyřešený

V ověř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)


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 Automatická změna stavu E.g. 10WD

Vyřešený

Uzavřený

Přidat komentáře a hodnocení řešení

Ověřit řešení

Schválit řešení

Positive

Doplnit požadavek Negative Připojit přílohy Reklamovat řešení V reklamačním řízení Doplnit komentáře


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á? Ne

Ověření nároku na reklamaci


Postoupit k ověření zadavatelem Vyřešený

V reklamačním řízení Přiřadit jinému řešiteli

podproblémy Ano Přidělení úkolů

V reklamačním řízení

Požadavek je neřešitelný Zapsání vykonané práce

Označit jako neřešitelný Vyřešený (s příznakem)


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 Automatická změna stavu Požadavek s bezproblémovým řešením

Ano Uzavřený

Vyhodnocení požadavku HD managerem

Uzavřít Vyhodnocený

Automatické vyhodnocení požadavku


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

HD800 – Schválení zadavatelem HD100 – (Založení a) preanalýza

HD700 Ověření řešení

REM

NE

HD900 – Vyhodnocení požadavku

ANO

REM_350 – Doplnění požadavku

Koordinátor

REM_100 Založení požadavku

REM_200 Klasifikace požadavku

Řešitel

REM_300 – Ohodnocení požadavku

Hodnotitel

Requirement Managemnt

Zadavatel

Report (KIBIC)

REM_850 – Přehodnocení požadavku

REM_800 – Schválení požadavku

Uzavřený Podstav: Schváleno/ Neschváleno Stornovaný

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í formuláře REM

Sumarizace požadavku

Příkaz k založení požadavku

Otevřený

Založený


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 Klasifikovat založený požadavek Založený

Předat k ohodnocení V řešení


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 doplnění Ocenit požadavek V řešení Zapsat ocenění Přiřadit jinému řešiteli

Ohodnocený


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 Doplnit komentář

Doplnit přílohy

Předat ke zpracování V řešení

V doplnění


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 Přidat rozhodnutí

Doplnit komentář Ohodnocený

Uzavřený (Schválený/ Neschválený)

Zpráva komise o schválení/ neschválení požadavku

Stornovaný

Report SE/ KB/ DC

Report Projektů / KB/ DC

V řešení (Přehodnocení)


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 Překlasifikovat požadavek

Předat k ohodnocení

V řešení (Přehodnocení)

Ohodnocený


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í formuláře pro incident


Příkaz k založení požadavku Založený

Otevřený


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

Kontrola správnosti přiřazení incidentu

Vyplnění podrobností incidentu

Postoupení k řešení V řešení (Analýza)

Založený

Doplnění komentáře Stornovaný


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ý workaround42 v procesu Problem Management. Obrázek 36: Workflow Analýza incidentu Převzetí požadavku

Analýza incidentu

Diagnostika incidentu

Zapsání vykonané práce V řešení (Řešení incidentu)

V řešení (Analýza)


Ř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 Převzetí požadavku

Řešení incidentu

Doplnění komentáře

Zapsání vykonané práce V ověření

V řešení (Řešení incidentu)

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 Doplnění komentářů



V řešení (Řešení incidentu)

V doplnění


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í Ověření řešení

Doplnění komentářů Vyřešený

V ověření


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 Uzavřený

Vyřešený


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í formuláře pro problém

Sumarizace problému

Klasifikace a prioritizace problému

Prolinkování incidentů Založený

Otevřený


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

Analýza problému

Návrh workaroundu

Postoupení ke schválení

Založený

V revizi


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

Schválení návrhu na workaround

Doplnění komentáře V řešení

V revizi

Stornovaný

V doplnění


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 Doplnění komentářů, připojení příloh

Předat ke schválení

V doplnění

V revizi


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

Vyřešený

Založení RFC a realizace změny


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 Schválení vyřešení problému Schvalovatelem 1

Schválení vyřešení problému Schvalovatelem 2

Uzavření problému Uzavřený

Vyřešený


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.

Zadavatel

Obrázek 48: Hlavní workflow procesu Change Management SDT_180 Verifikace zadání

SDT_300 – Metadatová kontrola

SDT_350 Řešení problému

SDT_500 – Kontrola a nasazení řešení

Vyhodnocený - rozhodnutí: · Pozitivní · Negativní

SDT_250 Kontrola ODWH

SDT_900 – Schválení a uzavření

SDT_550 – Vytvoření prostředí a založení objektů

SDT_800 – Kontrola výsledků

Participant

SDT_150 Doplnění požadavku

Průvodka nasazení Řešení problému

Řešitel 1

Řešení problému SDT_400 Vytvoření prostředí a založení objektů

SDT_300 – Metadatová kontrola

Řešení problému

Řešitel 2

Change Management (Solution Deployment Task)

SDT_100 Založení požadavku

SDT_850 - Řešení reklamace

SDT_500 – Kontrola a nasazení řešení

Řešitel 3

Řešení problému

Schvalovatel

SDT_250 – Kontrola ODWH

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í formuláře Solution Deployment


Příkaz k založení požadavku V doplnění

Otevřený


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ředat k ověření V ověření

V doplnění


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 řešení

V ověření

V doplnění


Stornovaný


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)

Přiřazení si požadavku

Vývojová změna

Kategorizace změny

Posouzení úplnosti zadání

Validace průvodky

Kontrola splnění provozních parametrů

Aktualizace plánu nasazení Schválený

V řešení

Stornovaný


Operativní změna

V doplnění

Kontrola správnosti řešení k nasazení

Předání k testování V ověření (Kontrola a nasazení řešení)


48

Kontrola operačních metadat (ODWH) (SDT250) Procesní krok řeší aktivity spojené s kontrolou operačních metadat43. Obrázek 53: Workflow Kontrola operačních metadat Převzetí požadavku

ODWH kontrola

Přidání komentářů

Zapsání vykonané práce Schválený

V ověření (Kontrola ODWH)


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 Přidání komentářů Kontrola IFPC

Převzetí požadavku


Kontrola modelu z metadatové oblasti

V ověření (Kontrola a nasazení řešení)

Schválený Kontrola skriptu z metadatové oblasti

Sumarizace problému V řešení (Řešení problému)


Ř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ý

Je problém oprávněný?

V řešení (Vytvoření prostředí a založení objektů) Řešení požadavku

V řešení (Řešení problému)

ANO

Zapsání vykonané práce V ověření (Kontrola a nasazení řešení)

NE V ověření (Kontrola ODWH)


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 ANO V řešení (Vytvoření prostředí a založení objektů)

Je potřeba vytvořit prostředí?

Potvrzení ED k založení prostředí

Vytvoření kontejnerů

Vytvoření objektů a X objektů

Zapsání vykonané práce V ověření (Kontrola a nasazení řešení)

Nastavení prostoru

Nastavení práv



Zapsání vykonané práce V řešení (Řešení problému)


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


NE

Nasazení řešení

Vyřešený (Kontrola výsledků)

V ověření (Kontrola a nasazení řešení) ANO

V řešení (Vytvoření prostředí a založení objektů)


V řešení (Řešení problému)

Doplnění komentáře Stornovaný


Kontrola výsledků (SDT800) Procesní krok řeší aktivity spojené s ověřením výsledků řešení. Obrázek 58: Workflow Kontrola výsledků

Převzetí požadavku




K uzavření

Vyřešený (Kontrola výsledků) Stornovaný Sumarizace problému V reklamačním řízení


Ř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á? Ověření nároku na reklamaci


Postoupit k ověření Vyřešený (Kontrola výsledků)

V reklamačním řízení

Řešení požadavku


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 Uzavřený

K uzavření


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 PoC44 (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 (PoT45). - Š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

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

PM300 Analysis, diagnosis of problem

IM500 Solution and recovery of incident

PM500 Solution of problem, Known Error

PM500 Solution Design

CH 500 Solution of RFC

PM600 Implementation

CH600 Deployment

PM800 Approval/Acceptance

CH 800 Approval


CH 900 Evaluation, closure

Support, Maintanace

IM100 Creation and pre-analysis of incident

HD500 Solution of requirement

IM700 Verification

PM700 Verification

IM800 Approval

IM900 Evaluation, closure


HD700 Verification

HD800 Approval

RM800 Approval to Implementation

HD900 Evaluation, closure

RM900 Closure

Project, Small Enhancement

RM500 Design and evaluation of effort, risk

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 bankera46 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

Schválení Sponzorem a Responsible bankerem

Identifikace PM

Tvorba projektového plánu, rizik a prezentace

BI schválení

Stornovaný

K doplnění

Ke schválení pro KB management

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í

Validace základních projektových parametrů (náklady, plán, rizika, čas aj.)

Příprava prezentace

BI schválení (Sponzor, Responsible banker)

K doplnění

K doplnění

Výběr řešení

K doplnění


K doplnění


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

Validace základních projektových parametrů (náklady, plán, rizika, čas aj.)

Příprava prezentace


K doplnění

K doplnění

Revize nákladů a rizik


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í


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 Akceptace řešení Řešení bylo úšpěšně nasazeno v rámci procesu Change Managementu

K uzavření

Ano

Ne 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ů



66

K uzavření na úrovni KB

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-1331047-0. OGC. Service operation. United Kingdom: The Stationery Office, 2007, 263 s. ISBN 978-01133-1046-3. OGC. Service strategy. United Kingdom: The Stationery Office, 2007, 264 s. ISBN 978-01133-1045-6. OGC. Service transition. United Kingdom: The Stationery Office, 2007, 261 s. ISBN 978-01133-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/. 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-0325]. 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. Six Sigma [online]. 2011 [cit. 2012-03-26]. Dostupné z: http://www.6s.cz/. Základní

fakta

[online].

2010

[cit.

2012-03-26].

Dostupné

http://www.togaf.cz/index.php?option=com_content&view=article&id=11:hlavnistranka&catid=1:hlavni-kategorie.

73

z:

Přílohy Příloha 1: BPMN 2.0

Zdroj: bpmb.de/poster.

Příloha 2: Základní ukazatele KB

Zdroj: www.kb.cz.

Příloha 3: Architektura KB EDWH

PeopleSoft

IBS NET Branch TSS3

Front office systems

Kondor+

Call Centrum TSS3

Trade Fin

CMS

Kondor

Their Primary databases systems

ERP

ODS KBI

Teradata Environment Data Stage

Errors

Metadata Repository

Transformation Rules

E T L

Enterprise Data Warehouse

EDW

Errors

Data mining Mart

Marketing Campaigns

Risk

Performanc e Reporting

MIS, Profitabilit y

ALM

Metada reporting

DATA MARTS

User Application, Data Access, BI Platform Back office User

Marketing User

Credit Risk Applications

Sun Guard Risk User

Zdroj: BIVOJ Guideline, vlastní úpravy.

Distribution network User

Finance User

User

(Portal, Reports, Query, OLAP, ROLAP)

M E T A D A T A

Příloha 4: Organizační struktura BI KB

Business Intelligence BI Office

Information Quality

Architecture and Metadata

Operations

Reporting

Architecture

Data Integration

Performance management

Infrastructure

User Support

Design

Infrastructure Projects

Operation Support

Development

Project management

Zdroj: Vlastní tvorba.

Service Level Management

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

Recommend Documents