Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Návrh na zlepšení projektové dokumentace v rámci projektového řízení v bankovním domě
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Kognitivní informatika
Autor: Bc. Polina Luneva
Vedoucí diplomové práce: doc. Ing. Ota Novotný, Ph.D.
Praha, červen 2021
2
Prohlášení
Prohlašuji, že jsem diplomovou práci „Návrh na zlepšení projektové dokumentace v rámci projektového řízení v bankovním domě“ vypracovala samostatně za použití v práci
uvedených pramenů a literatury.
V Praze dne 22.06.2021 . . . Polina Luneva
3
Poděkování
Ráda bych poděkovala vedoucímu diplomové práce doc. Ing. Otovi Novotnému, Ph.D. za konzultace, připomínky a nasměrování při psaní této diplomové práce. Rovněž děkuji svému vedoucímu v práci, který mi poskytl cenné rady a podpořil mě při psaní této práce.
4
Abstrakt
Práce je zaměřena na problematiku v oblasti zlepšení projektové dokumentace v příslušné bance v ČR. V práci je rozebráno projektové řízení se zaměřením hlavně na projektovou dokumentaci v bankovnictví za účelem identifikace problémových oblastí.
Hlavním cílem práce je stanovit návrhy na zlepšení projektové dokumentace v bance.
V první části se práce věnuje projektovému řízení v IT a popisuje specifika IT projektové dokumentace se zaměřením na banku. Dále se v práci analyzují chyby v IT projektech v bankovnictví a chyby, plynoucí z dokumentace. Ve třetí části je stručně představena IT architektura v bankovnictví a dopad architektury na projektové řízení. V následující části práce je charakterizován a popsán současný stav projektového řízení v dané bance se zaměřením na identifikaci problémových částí projektů v rámci projektové dokumentace v jednotlivých fázích projektů.
Výstupem práce jsou jednotlivé návrhy na zlepšení v rámci fází projektů. Ověření těchto výsledků pomocí dialogů s projektovými manažery, kteří návrhy využili, je obsaženo na konci této diplomové práce.
Klíčová slova
Projektové řízení, projektová dokumentace, IT projekty, chyby projektů, IT architektura banky, fáze projektů, bankovnictví
5
Abstract
The work is focused on issues in the field of improving project documentation in the relevant bank in the Czech Republic. The diploma thesis deals with project management with a focus on project documentation in banking in order to identify problem areas.
The first part deals with project management in IT and describes the specifics of IT project documentation with a focus on the bank. Furthermore, the work analyzes errors in IT projects in banking and errors resulting from documentation. The third part briefly introduces the IT architecture in banking and the impact of architecture on project
management. The following part of the thesis characterizes and describes the current state of project management in the bank with a focus on the identification of problematic parts of projects within the project documentation in various phases of projects.
The output of the work are individual suggestions for improvement within the project phases. Verification of these results through dialogues with project managers who have used the proposals is included at the end of this thesis.
Keywords
Project management, project documentation, IT projects, project mistakes, IT architecture of the bank, project phases, banking
6
Obsah
Úvod ... 11
1.1 Důvod výběru tématu ... 11
1.2 Hlavní cíl práce ... 12
1.3 Dílčí cíle práce ... 12
1.4 Struktura práce ... 12
1.5 Cílová skupina ... 13
1.6 Přínosy práce ... 13
1.7 Omezení práce ... 14
2 Rešerše ... 15
2.1 Řízení projektů ve vybrané společnosti ... 15
2.2 Optimalizace projektového řízení ve vybrané organizaci ... 15
2.3 Způsob údržby dat o klientech a produktech banky ... 15
2.4 Technický redesign integračního rozhraní pro výpisy v bankovním sektoru ... 16
2.5 Projektový management podle IPMA ... 16
2.6 Řízení projektů v IT ... 16
2.7 Bankovnictví ... 16
3 Projektové řízení v IT se zaměřením na bankovnictví ... 17
3.1 IT projekty ... 17
3.2 Specifika IT projektové dokumentace v bance... 20
3.2.1 Fáze Idea – Čeho chceme dosáhnout? ... 22
3.2.2 Fáze Zahájení projektu – Co vše bude projekt obnášet? ... 22
3.2.3 Fáze Plánování – Jak by měl projekt proběhnout? ... 23
3.2.4 Fáze Realizace projektu – Jak projekt uřídit? ... 25
3.2.5 Uzavírání projektu – Jak projekt správně zakončit? ... 26
3.3 Závěry z kapitoly ... 27
4 Analýza chyb plynoucích z dokumentace a chyby v IT projektech obecně ... 28
4.1 Chyby v projektové dokumentaci ... 28
4.2 Chyby v lidských zdrojích ... 30
4.3 Chyby v postupech ... 31
4.4 Chyby v plánování ... 32
4.5 Komunikační problémy ... 33
4.6 Závěry z kapitoly ... 33
5 IT referenční architektura banky ... 34
5.1 Microsoft Industry Reference Architecture for Banking ... 35
7
5.2 Systémový přístup v projektovém řízení ... 37
5.3 Závěry z kapitoly ... 38
6 Charakteristika současného stavu projektového řízení včetně dokumentace v BANK MONEY a.s. a návrh na zlepšení ... 40
6.1 Projektové řízení v BANK MONEY a.s. ... 40
6.2 Životní cyklus projektu ... 41
6.3 Fáze Idea projektu ... 42
6.3.1 Návrh na zlepšení ... 42
6.4 Fáze Zahájení projektu ... 43
6.4.1 Návrh na zlepšení ... 44
6.5 Fáze Plánování ... 44
6.5.1 Návrh na zlepšení ... 47
6.6 Fáze Realizace projektu ... 51
6.6.1 Návrh na zlepšení ... 53
6.7 Sledování a kontrola projektu ... 56
6.7.1 Návrh na zlepšení ... 59
6.8 Uzavírání projektu ... 68
6.8.1 Návrh na zlepšení ... 70
6.9 Závěry z kapitoly ... 70
7 Ověření výsledků ... 72
8 Závěr ... 74
9 Použitá literatura ... 75
10 Přílohy ... 77
10.1 Příloha A: Idea projektu: role a zodpovědnosti ... 77
10.2 Příloha B: Fáze Zahájení projektu: role a zodpovědnosti ... 77
10.3 Příloha C: Fáze Plánování: role a zodpovědnosti ... 78
10.4 Příloha D: Fáze Realizace projektu: role a zodpovědnosti ... 83
10.5 Příloha E: Sledování a kontrola projektu: role a zodpovědnosti ... 89
10.6 Příloha F: Uzavírání projektu: role a zodpovědnosti ... 95
10.7 Příloha G: Akceptační protokol – šablona ... 97
8
Seznam obrázků
Obrázek 1 Životní cyklus IS vs. životní cyklus projektu (Řepa, 2006)... 18
Obrázek 2 Provázanost referenční architektury s okolím (Jabůrek, 2015, s. 39, cit. podle Cloutier, aj. 2009, s. 20) ... 35
Obrázek 3 Rozdíl mezi sily s přístupem a modulárně-integrační platformy (Microsoft, 2012, str. 6) ... 36
Obrázek 4 Tři základní oblasti systémového řízení (Schwalbe, 2011, s. 60) ... 38
Obrázek 5 Životní cyklus projektu v rámci společnosti BANK MONEY, a.s. a jednotlivé fáze projektu (Interní zdroj BANK MONEY, a.s.) ... 42
Obrázek 6 Vzor vyčíslení externích zdrojů v rámci přípravy ke schválení exekuční fáze . 54 Obrázek 7 Vzor nastavení harmonogramu projektu ... 55
Obrázek 8 Projektová pravidla ... 60
Obrázek 9 Schůzky kalendář ... 60
Obrázek 10 Vzor struktury zápisu ... 61
Obrázek 11 Vzor vedení rizik ... 62
Obrázek 12 Projektové registry 1 ... 63
Obrázek 13 Projektové registry 2 ... 63
Obrázek 14 Demand, change management ... 64
Obrázek 15 Způsob sledování rozpočtu – úroveň 1 ... 65
Obrázek 16 Způsob sledování rozpočtu – úroveň 2 ... 66
Obrázek 17 Organizační struktura business – rolloutu ... 66
Obrázek 18 Role a odpovědnosti členů business rolloutu ... 67
Obrázek 19 Koncept podpory v rámci Business – rolloutu ... 68
9
Seznam tabulek
Tabulka 1 Vstupy a výstupy v rámci fáze Idea ... 42
Tabulka 2 Vstupy a výstupy v rámci fáze Zahájení projektu ... 44
Tabulka 3 Vstupy a výstupy v rámci Stanovení rozsahu projektu ... 44
Tabulka 4 Vstupy a výstupy v rámci Přípravy harmonogramu ... 45
Tabulka 5 Vstupy a výstupy v rámci stanovení nákladů, sestavení rozpočtu, sestavení klíčových ukazatelů vyhodnocení projektu ... 45
Tabulka 6 Vstupy a výstupy v rámci Plánování lidských zdrojů ... 45
Tabulka 7 Vstupy a výstupy v rámci Analýzy a plánu rizik ... 46
Tabulka 8 Vstupy a výstupy v rámci Plánu řízení rizik ... 46
Tabulka 9 Vstupy a výstupy v rámci Komunikačního plánu ... 46
Tabulka 10 Vstupy a výstupy v rámci Plánování nákupu ... 47
Tabulka 11 Vstupy a výstupy v rámci Projektového plánu ... 47
Tabulka 12 Vstupy a výstupy v rámci Řízení realizace projektu ... 52
Tabulka 13 Vstupy a výstupy v rámci Zajištění, motivace a rozvoj členů týmu ... 52
Tabulka 14 Vstupy a výstupy v rámci Informování o průběhu projektu ... 53
Tabulka 15 Vstupy a výstupy v rámci Smluvního zajištění nákupu ... 53
Tabulka 16 Vstupy a výstupy v rámci Sledování a kontroly projektových prací ... 57
Tabulka 17 Vstupy a výstupy v rámci Řízení změn ... 57
Tabulka 18 Vstupy a výstupy v rámci Kontrola rozsahu, harmonogramu a rozpočtu ... 57
Tabulka 19 Vstupy a výstupy v rámci Kontroly kvality řízení projektu ... 58
Tabulka 20 Vstupy a výstupy v rámci Akceptace projektových výstupů ... 58
Tabulka 21 Vstupy a výstupy v rámci Vyhodnocování a aktualizace rizik ... 58
Tabulka 22 Vstupy a výstupy v rámci Schvalování a kontroly nákupu ... 59
Tabulka 23 Vstupy a výstupy v rámci Vyhodnocení výkonnosti zdrojů ... 69
Tabulka 24 Vstupy a výstupy v rámci Sestavení závěrečné zprávy ... 69
Tabulka 25 Vstupy a výstupy v rámci Uzavření nákupu... 69
Tabulka 26 Vstupy a výstupy v rámci Předání výstupů Projektu a administrativní uzavření Projektu ... 70
Tabulka 27 Sumarizace návrhů na zlepšení ... 71
Tabulka 28 Zpětná vazba na návrhy na zlepšení ... 73
10
Seznam použitých zkratek
BC Business case
BE Backend
BIAN Banking Industry Architecture Network B/O Back-office
ČNB Česká národní banka EA Enterprise architektura FAT Factory Acceptance Test
FE Frontend
F/O Front-office
ICT Informační a komunikační technologie IS Informační systém
IPMA International Project Management Association KGI Key Goal Indicators
PMBOK Projekt Management Book of Knowledge
PRINCE2 PRojects IN Controlled Envi-ronments 2nd Version RUP Rational Unified Process
SIT System integration testing SOA Service Oriented Architecture UAT User acceptance testing WBS Work breakdown structure
11
Úvod
V dnešní době, plné na inovace v mnoha prostředích, se změny přímo dotýkají i projektového řízení. Práce se zaměřuje specificky na projektové řízení v bance v IT oddělení. Zde je potřeba myslet na to, že IT projekty jsou specifické. Specifika nacházíme například v unikátnosti jednotlivých IT projektů a přesném určení cílů a výstupů projektů.
Vždy máme jasně stanovený cíl, čeho chceme po úspěšné realizaci projektu dosáhnout.
Dále jsou projekty jasně omezené termínem dodávky a realizace projektu je tedy stanovena v čase. Omezen je projekt i cenou a omezenými zdroji. Hlavním specifikem je však
interdisciplinární charakter. Co si pod tím představit? Je nepochybné, že složitost, dynamika a proměnlivost IT oblasti je obrovská a zároveň se často IT projekt musí vyrovnat i s tím, že dopad cílového řešení není pouze do IT oblasti, ale i do dalších,
dotčených změnou, oblastí. O to více se musí IT projekt vyrovnávat s faktorem neznámého a rizik.
Je třeba brát v potaz i to, že projektem se nerozumí rutinní a opakovaná činnost, a tudíž každý projekt vyžaduje specifický přístup. Je to daný i tím, že na každém projektu participují jiní zaměstnanci a je potřeba mnohdy spolupracovat s celou škálou lidských faktorů. Toto úskalí však neříká a nenařizuje, aby projekt byl chaotický a snažil se
přizpůsobit lidem. Projekt má zároveň i jasné charakteristiky, které musí splňovat a to, že jsou definované cíle a jasná kvalita. Projekt je organizovaná činnost s určitými průběžnými výsledky a nepostrádá ani kontrolní mechanismy. Mimo tyto obecné charakteristiky patří i samotné řízení projektu, kdy mezi hlavní činnosti řízení projektů spadá plánování,
organizování, delegování a motivování, řízení času, zdrojů, financí a nákladů, komunikace, kvalita, změny, rizika a rezervy a dále pak hodnocení a kontrolování. Mimo tyto hlavní činnosti je pak mnoho činností vedlejších. Hlavní je, že veškerá práce na projektu je zaznamenávána do tzv. projektové dokumentace, která musí splňovat určité normy.
Nicméně v poslední době se setkáváme s projektově řízenými implementacemi progresivních metod zvyšování efektivnosti, které vnášejí do veškerého IT moderní přístupy a metody používání. Tyto přístupy v řízení IT se rychle vyvíjí a mění a má to přímí dopad i na samotné projektové řízení. Jelikož v rámci projektu je potřeba se s těmito inovacemi a novotami vypořádat a nastavit projekt tak, aby se tyto dvě vertikály vzájemně doplňovaly. Zde ale dochází k opožděnosti, kdy společnosti zcela nemyslí na vývoj a optimalizaci projektového řízení tak, aby se těmto změnám přizpůsobily. Hlavním úskalím je od začátku projektová dokumentace, která obsahuje zastaralé byrokratické metody a potřeby od projektového manažera. Tyto potřeba jsou pak vyžadovány, jelikož bez toho nelze žádný z projektů zahájit a schválit. Nicméně čas, který se na tvorbě této projektové dokumentaci stráví, je naprosto neoptimální vzhledem k tomu, k čemu je pak dokumentace potřeba.
1.1 Důvod výběru tématu
Důvodem, proč bylo vybráno toto téma, je faktor toho, že autorka již čtvrtým rokem působí v jedné z banky v ČR v oblasti projektového řízení a necelé dva roky se přímo věnuje řízení IT projektů jako projektový manažer.
12
S řízením projektů a projektovou dokumentací autorka přišla do styku již několikrát a vidí zde jednoznačná úskalí a neoptimálnost řízení projektů a projektové dokumentace v této společnosti. I přes to, že se zkušenosti autorky jen nepatrně vyrovnají zkušenostem jiných projektových manažerů, kteří působí na pozicích desítky let, avšak mladiství pohled na tuto problematiku může být přínosný pro čtenáře z cílové skupiny.
1.2 Hlavní cíl práce
1. Návrh na zlepšení projektové dokumentace v bance v rámci jednotlivých fází projektu.
Hlavním cílem této diplomové práce je předložení návrhu na zlepšení v oblasti projektového řízení, zaměřené hlavně na zlepšení projektové dokumentace, v jedné z banky v ČR. Dále v diplomové práci uváděno jakožto společnost BANK MONEY a.s.
Za účelem dosažení tohoto cíle bude ve společnosti charakterizováno a následně rozebráno projektové řízení se zaměřením hlavně na projektovou dokumentaci a dokumentaci
v bankovnictví obecně za účelem identifikace problémových oblastí. Dosažením tohoto cíle bude bráno to, že na závěr se stanoví jasné přínosy, které plynou z implementací navržených změn.
1.3 Dílčí cíle práce
Za dílčí cíle práce jsou považovány:
1. Analyzovat projektové řízení v IT a popsat specifika IT projektové dokumentace se zaměřením na banku.
2. Analýza chyb plynoucích z dokumentace a chyby v IT projektech obecně.
3. Stručné představení IT architektury v bankovnictví a dopad architektury na projektové řízení.
4. Charakteristika současného stavu projektového řízení v BANK MONEY a.s.
5. Zaměřit se a identifikovat problémové části projektu v rámci projektové dokumentace v jednotlivých fázích projektu.
1.4 Struktura práce
Tato diplomová práce je rozdělena do čtyř kapitol. Do jednotlivých kapitol není zahrnut Úvod, kde je stručně popsáno, v čem práce spočívá, jaké jsou důvody výběru tématu a co vedlo autorku k tomuto výběru. Dále pak hlavní a dílčí cíle práce, cílová skupina a v neposlední řadě přínosy a omezení práce. Ke konci jsou rešerše prací na obdobné téma a rešerše některých dalších kvalitních zdrojů, které byly při sepisování této práce mimo jiné použity. Jako zvláštní kapitola není brán i Závěr a Ověření výsledků.
13
V první kapitole této práce se autorka zaměřuje na stručný popis projektového řízení v rámci IT. Jsou zde popsány určité standardy v rámci IT projektů, které by se měly dodržovat a které mají za úkol pomoci v dodávce IT projektu. V rámci této diplomové práce se autorka nezaměřuje příliš na obsáhlejší popis projektového řízení, jelikož je identifikováno obsáhlé množství diplomových prací, které se tomuto tématu vyloženě věnuji, tudíž problematika a teoretický popis projektového řízení zde není rozváděn do detailu. Granularita dané kapitoly je přesně taková, aby čtenáři byl předložen kontext problematiky a aby porozuměl dalším kapitolám. Zároveň součástí této kapitoly je popis specifik IT projektové dokumentace se zaměřením na banky.
Druha kapitola je zaměřena na identifikaci vyskytujících se chyb v rámci projektové dokumentace a následně chyb v IT projektech obecně.
Ve třetí kapitole se autorka zaměřuje na popis IT architektury a na její specifika v rámci banky, jelikož je to nutný předpoklad k tomu, pochopit následně některá specifika IT projektů v bankovnictví. Je potřeba si vymezit, co přesně znamená IT architektura, proč je důležité mít v každé společnosti systematičnost, co se architektury týče a jaké vlastnosti má IT architektura v bance. Zároveň se autorka zaměří i na propojení IT architektury a projektového řízení přes systémový přístup v projektovém řízení.
V poslední kapitole bude zaměřeno na popis stavu projektového řízení v IT v bance BANK MONEY a.s. Kapitola bude dosti podrobná z důvodu, že hlavním cílem této diplomové práce je analýza současného stavu projektové dokumentace a následující navržení lepšího způsobu dokumentace. Z toho důvodu bylo pro autorku zásadní zanalyzovat veškeré podrobnosti jednotlivých úkonů, které se v rámci IT projektů dějí a které je potřeba brát v potaz při tvorbě dokumentace. Autorka se zaměří a identifikuje problémové části projektové dokumentace v jednotlivých fázích projektu a navrhne příslušné návrhy na zlepšení projektové dokumentace. V iniciační fázi, plánovací fázi, exekuční fázi a při samotném ukončení projektu.
1.5 Cílová skupina
Cílovou skupinou jsou primárně projektový́ manažeři v oblasti bankovnictví, kteří se pohybují v IT. Je nutné podotknout, že oblast IT v bankách je velice specifická, a tudíž je tato práce určena primárně pro čtenáře, kteří se v bankovnictví pohybují.
1.6 Přínosy práce
Hlavním přínosem práce jsou navržené změny v projektové dokumentaci. V první řadě se autorka musí opravdu dopodrobna seznámit se všemi kroky projektového řízení a zároveň se dobře orientovat v ostatních návrzích a metodikách projektového řízení, aby byla opravdu schopná navrhnout nejlepší možná řešení.
Dále může být práce i přínosná pro samotnou společnost, která může použít tuto diplomovou práci k samotné optimalizaci projektového řízení. Vzhledem k tomu, že se jedná o banku, nelze očekávat, že ke změně dojde, jelikož je banka řízena další
14
mezinárodní organizací, která udává mimo jiné i směr projektového řízení. Nicméně práce může posloužit k vyvolání podnětu a diskusí o změně.
Dále práce může být i přínosná pro samotné projektové manažery, kteří mohou některé kapitoly použít v rámci svých projektů. Nezmění sice dokumentaci, ale mohou
zoptimalizovat některé fáze.
1.7 Omezení práce
Hlavním omezením je potřebnost anonymizovat interní údaje o společnosti a o projektech této společnosti. Z toho důvodu byl název společnosti změněn na již zmíněný název BANK MONEY a.s.
V rámci práce pak byly odebrány všechny identifikovatelné znaky. Dalším omezením je i zachování utajených informací co se harmonogramu a rozpočtu projektů týče. Z tohoto důvodu je harmonogram projektů fiktivní a rozpočty projektů se v práci neuvádí.
15
2 Rešerše
Na úvod se provedla rešerše již existujících prací na podobné téma a potencionálních dalších kvalitních zdrojů. Prací, které by se zaměřovaly na bankovnictví, není mnoho, ale poměrně velké množství prací se zaměřuje na projektové řízení. Práci, která by se
zaměřovala vyloženě na projektovou dokumentaci v bankách, nebyla nalezena.
2.1 Řízení projektů ve vybrané společnosti
Diplomová práce pana Škrdla (2015) s titulem Řízení projektů ve vybrané společnosti, se zaměřuje na návrh optimalizace na zlepšení v oblasti projektového řízení ve vybrané společnosti. V práci je charakterizováno a následně rozebráno projektové řízení a vydefinování problémových oblastí. Na závěr autor stanovuje přínosy, plynoucí
z implementace navržených změn. Autor v práci popisuje jednotlivé fáze projektu a věnuje samostatnou kapitolu i monitorování a kontrole projektu. Popisuje v práci současný stav projektového řízení ve společnosti a dále pak navrhuje možné změny ke zlepšení. V jedné z kapitol, při navrhování změn ke zlepšení v rámci projektového řízení, navrhuje i změnu v rámci projektové dokumentace. Tato práce bude využita hlavně vzhledem k obdobnému tématu této diplomové práce.
2.2 Optimalizace projektového řízení ve vybrané organizaci
Podobná práce, na téma Optimalizace projektového řízení ve vybrané organizaci, je sepsána autorem panem Daňou (2014) a zaměřuje se též na návrh zlepšení v rámci projektového řízení. V práci popisuje projektové řízení obecně, dále se zaměřuje na procesní řízení a na metodiku procesních změn. Dále v práci popisuje projektové řízení v podniku a v samostatné kapitole navrhuje optimalizaci řízení projektů.
2.3 Způsob údržby dat o klientech a produktech banky
Diplomová práce s titulem Způsob údržby dat o klientech a produktech banky,
vypracovaná Znojilem (2009), se zabývá způsobem údržby dat o klientech a produktech v bankách. Rozumí se tím ucelený proces začínající pořízením dat, zpracování těchto dat, zálohování a jejich archivace a s tím spojená kontrola a aktualizace všech archivovaných dat. Předkládá ve své práci přehled informací o klientech a bankovních produktech i v rámci ochrany osobních údajů. Tato práce bude dále využita v rámci třetí kapitoly, která se týká dokumentace v bance obecně.
16
2.4 Technický redesign integračního rozhraní pro výpisy v bankovním sektoru
Dále bude, jako jeden z mnoha dalších zdrojů, použita bakalářská práce stejnojmenné autorky této diplomové práce. Polina Lukaševič (2018) s titulem práce Technický redesign integračního rozhraní pro výpisy v bankovním sektoru. V teoretické se práce zaměřuje na informační systémy a projektové řízení v rámci IT. V praktické části řeší samotnou realizaci skutečného projektu. Práce bude použita hlavně pro účely popisu projektového řízení a přiblížení popisu samotného projektu.
2.5 Projektový management podle IPMA
Jako další zdroj bude použita kniha Doležala, aj. (2012) s titulem Projektový management podle IPMA. Jedná se o publikaci o řízení projektů podle české implementace standardu projektového řízení IPMA. Kniha seznamuje čtenáře s jednotlivými prvky technických, behaviorálních a kontextových kompetencí projektového manažera, popisuje doporučené a požadované techniky, vysvětluje pojmy a formulace ze standardu IPMA, přináší řadu příkladů a případových studií.
2.6 Řízení projektů v IT
Jedná se o knihu od světoznámé autorky Kathy Schwalbe (2011). Tato kniha vychází z ceněného a osvědčeného PMBOK Guide a je nejznámějším průvodcem řízení projektů.
V rámci kapitol této knihy je možné se seznámit se všemi aspekty řízení projektů v IT.
Kniha obsahuje řadu poznatků, informací a příkladů z praxe a pomáhá předejít mnoha chybám při řízení IT projektů. V rámci této práce se autorka k této knize nejednou vracela ať už v kapitole o projektovém řízení v IT se zaměřením na bankovnictví, nebo v kapitole IT referenční architektura banky.
2.7 Bankovnictví
Kniha Bankovnictví od autora Stanislava Poloučka, aj. (2013) přináší ucelený pohled na problematiku bankovnictví. Kapitoly se týkají bankovnictví obecně a oblastí, které s bankovnictvím úzce souvisejí. Autorka použila tuto knihu jako informační zdroj pro pochopení oblasti bankovnictví.
17
3 Projektové řízení v IT se zaměřením na bankovnictví
Tato kapitola se zaměřuje na stručný popis projektového řízení v rámci IT. Jsou zde popsány určité standardy v rámci IT projektů, které by se měly dodržovat a které mají za úkol pomoci v dodávce IT projektů. V rámci této diplomové práce se autorka nezaměřuje příliš na obsáhlejší popis projektového řízení, jelikož je identifikováno obsáhlé množství diplomových prací, které se tomuto tématu vyloženě věnuji, tudíž problematika a
teoretický popis projektového řízení zde není rozváděn do detailu. Granularita dané
kapitoly je přesně taková, aby čtenáři byl předložen kontext problematiky a aby porozuměl dalším kapitolám.
Vývoj bankovního světa a možnost implementace inovací v bankách ovlivňuje řada tradičních faktorů. Mezi tyto faktory patří hlavně ekonomická situace ať už ve státě, nebo ve světě, dále jistá politická rozhodnutí, neméně důležité jsou i sociální, a hlavně
technologické změny. Prvním třem faktorům se říká tradiční faktory, jelikož ovlivňují bankovnictví již několik staletí a určitě stále ovlivňovat budou. Poslední faktor, jimž jsou technologické změny, se ve velké míře objevuje až v posledním století, nicméně přispívá k vývoji bankovnictví o to víc a snaha managementu většiny bankovních institucí vkládají do technologických změn čím dál větší množství prostředků ať už fyzických, či finančních.
(Šlapanská, 2019, s. 18)
3.1 IT projekty
Dušan Chlapek (2005) říká: „Projekt IS/ICT definujeme jako projekt vyvolaný za účelem pořízení nebo adaptace (změny) IS/ICT, směřující k dosažení předem určených cílů.
Komplexnost projektů IS/ICT je dána skutečností, že projekty směřují k realizaci svých cílů ve vyvíjejícím se světě uživatelských cílů, požadavků, průběžně zlepšovaných věcných (business) procesů, rychle se vyvíjejících technologií a integrujících se systémů.“
Základní vlastnosti IS/ICT projektů jsou dle Dušana Chlapka (2005) následující:
1. Unikátnost. Projekt je vždy jednorázový proces. Projekt je vždy neopakovatelný a určuje ho mnoho charakteristických rysů a podmínek, ve kterých se projekt realizuje.
2. Potřeba přesně určených cílů a výstupů projektu.
3. Potřeba realizovat projekt ve stanoveném čase. Potřeba tedy přesného plánování a vytváření rozkladu prací na dílčí činnosti a úkoly.
Václav Řepa, aj. (2006) v rámci kapitoly, Řízení projektů vývoje IS, píše: „úspěch procesu vývoje informačního systému je přímo závislý nejenom na porozumění obsahu prací v jednotlivých fázích a krocích, ale z celé své jedné poloviny i na způsobu řízení
tohoto procesu. Vývoj informačního systému, či jeho části je vždy projektem – jedná se o akci se zjevně definovatelným cílem, časově omezenou a neopakovanou a se zjevně stanoveným a omezeným rozpočtem a se striktními požadavky na kvalitu (z hlediska
18
uživatele je nepřípustné si představovat vývoj IS jako nějakou permanentní a nikdy neukončenou rutinní činnost s nejistým výsledkem - vždy musí být zřetelný okamžik, od kterého bude informační systém sloužit a musí být záruka, že skutečně sloužit bude). To jsou všechno aspekty, které je nutno v postupu projektu řídit.“
Obrázek 1 Životní cyklus IS vs. životní cyklus projektu (Řepa, 2006)
Z Obrázku 1 je patrné, že životní cyklus a jím daná metodika vývoje IS a metodika řízení projektu, které musí platit současně, jsou na druhou stranu zcela různé. Je tedy v procesu vývoje IS vždy důležité vědět, co náleží projektu a co metodice postupu. Je nutné
rozlišovat mezi věcnými činnostmi projektu a činnostmi jejich řízení. (Řepa, 2006) V rámci IT projektů nás zajímají postřehy z oblasti projektů takové, jejichž součástí je i vývoj softwaru, případně jeho záměna či konsolidace stávajícího řešení. Analýza, návrh, design, vývoj a testování nového SW produktu je často hlavní náplní cílů, které jsou požadované k dosažení milníků v rámci takových projektů. (Bělka, 2007, s. 7) Je nutné podotknout, že poměrně malé procento IT projektů je dokončeno se
stoprocentním úspěchem. Často totiž na ramenou projektového manažera IT projektu stojí břímě toho, najít rovnováhu mezi vylučujícími si cíli a riziky, ale zároveň se očekává v maximální míře uspokojit požadavky zákazníka, ať už se jedná o koncového uživatele daného vyvíjeného produktu, nebo uživatele dodávaného řešení v rámci společnosti, případně dodávané řešení pro Business oblast v rámci společnosti. (Bělka, 2007, s. 7) Obecně se za úspěšný projekt považuje takový projekt, v rámci něhož byly dodány
všechny výstupy kvalitně, v rámci daného rozpočtu a včas. Metriky a nápomocné nástroje jsou používány projektovým manažerem k tomu, aby se v projektu lépe zorientoval a dokázal projekt řídit produktivně a nečerpat kapacity svých zdrojů duplicitně. Tyto metriky a nástroje mohou mít číselný, slovní či subjektivní charakter, ale obecně se za základy metrik projektového řízení považují:
• Kvalitu – zabezpečení maximální použitelnosti výstupů
• Kvantitu – vytvoření předem dohodnutého množství výstupů
19
• Termín – předání výstupů v souladu se stanoveným termínem
• Rozpočet – vytvoření výstupů v požadovaném rozpočtu (Bělka, 2007, s. 8)
„Správná aplikace výše uvedených metrik pomáhá manažerovi zhodnotit aktuální stav projektu. Navíc slouží i pro poskytování informací nadřízeným i pro prezentaci průběhu projektu zákazníkovi. Kvalitu výstupu nelze ověřovat až na konci projektu, ale je nutno ji provádět průběžně.“ (Bělka, 2007, s. 8)
I když se zdá, že IT projekty mají své specifické vlastnosti a požadavky, stále lze na
všechny takové projekty pohlížet očima metodiky. Metodika udává směr a řád jakémukoliv procesu a bez ní projekty postrádají právě tento zmiňovaný důležitý řád. Veškeré činnosti v průběhu procesu vývoje nového SW, případně tedy jeho konsolidace či inovace, popisuje právě metodika a určuje jednotlivé fáze procesu a výstupy, které definují úspěšný progres a následně ukončení projektu. Správně uchopena metodika není jen byrokratická záležitost, ale umožňuje průběžnou kontrolu SW vývoje z hlediska dodržení kvantity, kvality, termínu a rozpočtu projektu. (Bělka, 2007, s. 8)
Jelikož ke každému projektu lze přistupovat mnoha způsoby, je několik různých metodik, kterými projekt lze řídit. Každý projekt se zaměřuje a udává prioritu různým částem, tudíž nelze použit jednoznačně definovanou metodiku pro všechna řízení projektů. Metodika se odvíjí především od toho, na co se v rámci projektu zaměřuje a udává správný směr, zároveň pomáhá řídit projekt takovým způsobem, aby nebylo odbočeno od cíle projektu.
(Lukaševič, 2018, s. 16)
Primárně však všechny metodiky, bez ohledu na to, jaký problém řeší, musejí obsahovat minimálně následující skupiny problémů:
• rozklad jednotlivých rizik daného projektu
• určení organizačního rozdělení projektu a definování jednotlivých rolí a vzájemných vztahů
• životní cyklus projektu a rozdělení projektu do dílčích částí k lepší kontrole
• určení odpovědnosti organizačním strukturám případně rolím
• dodržování a stanovení standardů projektu (Lukaševič, 2018, s. 16, cit. podle Doucek, 2006, s. 34)
„Jednou z nejznámějších metodik vývoje softwarových aplikací je RUP. RUP poskytuje flexibilní rámec pro metodický popis organizační struktury a pracovních procesů a postupů v dané organizaci. Je to komplexní sada konceptů, postupů, nástrojů a technik používaných v softwarovém inženýrství. Softwarový vývoj stojí podle RUP na čtyřech základních pilířích – pracovníci, činnosti, pracovní procesy a výstupy. Definuje také šest nejlepších praktik softwarového vývoje – iterativní vývoj softwaru, správu a řízení požadavků, použití komponentové architektury, vizuální modelování, průběžné ověřování kvality a řízení změn.“ (Bělka, 2007, s. 8)
Existuje však spoustu dalších metodik, se kterými se můžeme v rámci projektového řízení setkat, ať už se jedná o mezinárodní normy, které mají za úkol především upravovat životní cykly ICT projektů a zároveň navrhovat základní sady projektových procesů. Nebo
20
se jedná o obecně přijímané standardy projektového řízení, které jsou nápomocné k porozumění projektového řízení. Mezi nejznámější patří PMBOK, dále pak standard IPMA a Prince2. (Lukaševič, 2018, s. 17, cit. podle Oškrdal, Doucek, 2014, s. 98) Projekty informačních technologií, stejně jako projekty z jiných sfér lidské činnosti, například stavebnictví nebo průmyslu, mají svá specifika. Pro oblast informačních technologií mezi ně patří zejména povaha informačních projektů, vlastnosti členů projektových týmů a odlišnost používaných technologií. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)
Vzdělání členů projektového týmu je naprosto různorodá. Jedná se o členy různých technických znalostí, ale i o členy, kteří absolvovali ekonomické, matematické či humanitární obory. Tito členové mají důležitý kontext v podobě odlišného pohledu na informační projekty a tím i jakési neobvyklé myšlení pro jiné členy s technickými znalostmi. Tento aspekt napomáhá k různorodosti členů projektu a tím i k progresivitě samotného projektu. Pro projektové týmy je charakteristické i vysoká specializace členů týmu. Často musejí být technické role úzce zaměřené na jakousi specializaci, například programátoři bývají úzce zaměřeni na jednoznačné programovací jazyky. Problém nastává i v tom, že v projektových týmech, zaměřených na IT, dochází k poměrně vysoké fluktuaci členů, jelikož techničtí specialisté v dnešní době nacházejí rozsáhlé využití a uplatnění v mnoha jiných společnostech a často nezastaví ani to, že se jedná o déle trvající projekt.
(Arendáč, 2016, s. 7)
Informační projekty bývají velmi různorodé. Některé se týkají pouze několika lidí instalujících nakoupený HW či SW, jiné zahrnují stovky lidí, analyzujících několik
obchodních procesů organizace a následně společně vyvíjejí nový SW za účelem dosažení podnikových cílů. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)
Informační projekty dnes podporují nejrůznější typy průmyslu a obchodu. Řízení informačního projektu v animačním oddělení filmové společnosti bude od projektového manažera a členů týmu vyžadovat jiné znalosti než projekt, jehož cílem bude zlepšit výběr daní či instalovat komunikační infrastrukturu v některé ze zemí třetího světa. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)
Rychlé se rozrůstající oblast technologií má za následek další problém, který se vztahuje k IT projektům a jedná se o jakési ohrožení podobných projektů. Často delší IT projekty musejí nést riziko toho, že po ukončení takového projektu a vlastně i po dosažení všech stanovených cílů na začátku, nemusí být projekt a dodaná funkčnost zcela uspokojivá.
Příčinou této situace je to, že rychlost proměny používaných technologií nutí společnost ke zkracování životního cyklu produktu a služeb a služba, která se vyvíjí příliš dlouho nemusí být již na trhu natolik potřebná a inovativní, jak se tomu na začátku projektu zdálo. Tato situace nutí vyvíjet a distribuovat tyto produkty a služby mnohem rychleji, než tomu bylo v minulosti. (Arendáč, 2016, s. 7)
3.2 Specifika IT projektové dokumentace v bance
Celé řízení projektů musí být něčím hnáno. Hnacím motorem všech projektů je správně nastavená projektová dokumentace. Jedná se o velmi důležitou informační část jak pro projektového manažera, tak i pro projektový tým. Cílem veškeré dokumentace je zachytit
21
ať už textem, nebo schématem důležité myšlenky, které se týkají jak návrhu, tak i implementace projektu.
Dokumentace, aby sloužila správně, musí v zásadě být:
1. Jasně definovaná. Musí být jasné kdy, co, kde, kdo a jak má dokumentovat.
2. Dobře strukturovaná do jednotlivých a přehledně označených částí, které na sebe logicky navazují.
3. Jednoduchá.
4. Musí být udržována v aktuálním stavu (musí být jasně označeny poslední provedené změny).
5. Dostupná všem zainteresovaným stranám a všem, kteří s ní musí pracovat.
(Doležal, aj, 2012, s. 260)
Pro dokumentaci je dále velice důležité, aby byla jasně označovaná. Každý dokument by měl obsahovat následující náležitosti:
1. Jednoznačný název dokumentu.
2. Datum, kdy dokument vznikl a kdo ho zpracoval.
3. Kdo a kdy byl schválen.
4. Jak a pro koho byly vytvořeny kopie.
5. Jaký je stupeň jeho utajení (pokud podléhá zvláštnímu režimu, kde je to vyžadované).
6. Platnost dokumentu.
6. Jiné potřebné informace, např. verze dokumentu. (Doležal, aj, 2012, s. 261) Projektovou dokumentaci lze různě dělit. Například se může jednat o dokumenty, které se vztahují k jednotlivým fázím projektu (Idea, Zahájení projektu, Plánování, Realizace projektu, Uzavření projektu). (Doležal, aj, 2012, s. 261)
Dále lze rozlišovat dokumentaci, která je již schválená pro realizaci projektu, jedná se pak o platnou dokumentaci. Ostatní je již neplatná dokumentace, která musí být i přesto řádně archivována. Různě rozpracované dokumenty mohou být označovány jako pracovní dokumentace. Podle předpisů může být i předepsána doba archivace projektové dokumentace. (Doležal, aj, 2012, s. 261)
Všechny projekty jsou řízeny dle jednotlivých fází. Projektová dokumentace se tedy vždy přizpůsobuje potřebám dané fáze. V následujících odstavcích se autorka zaměří na hlavní požadovanou projektovou dokumentaci v rámci jednotlivých fází.
Zároveň je nutné podotknout, že se autorka zaměří na projektovou dokumentaci v rámci IT projektů a v prostředí banky. Zde je potřeba dodat, že odbornou literaturu a již zpracované vysokoškolské práce na téma IT projektové dokumentace se zaměřením na banky po provedení podrobného průzkumu autorka nenašla. Popis níže bude tedy čerpán částečně z odborné literatury, zaměřené vyloženě na IT projekty a informace, které doplňují pohled potřeb k projektové dokumentaci v bance, bude autorka čerpat z osobních zkušeností.
22 3.2.1 Fáze Idea – Čeho chceme dosáhnout?
V této prvotní fázi projektu vzniká z pohledu projektové dokumentace – Identifikační listina projektu (ILP, případně Project charter). Tento dokument hlavně slouží k účelu, aby bylo možné strukturovaně popsat hlavní parametry projektu a tyto parametry dále dle potřeby komunikovat s okolím. Z hlediska mezilidské spolupráce je zde určitě lepší, když náměty na projekt vznikají v jedné šabloně a dle stejné struktury. Náměty lze tímto lépe komunikovat a vzájemně porovnávat. Často spolu s ILP vzniká i první Obchodní případ (častěji uváděno Business case). Tento dokument slouží hlavně ke kalkulaci nákladů proti výnosům. V rámci zpracování ILP často vznikají otázky, které mají mnohdy fatální dopad na pokračování projektu a nutí ke komunikaci se správnými útvary. (Doležal, aj, 2013, s.
19)
V kontextu banky je nutné dodat, že ILP je hlavně důležitý pro potřebné uvedení IT projektu pro zástupce obchodních útvarů v rámci banky. IT útvar je stále v bankách uchopen jako podpůrný útvar, a tudíž všechny IT projekty je potřeba řádně konzultovat se zástupci obchodu banky. Tito zástupci ve většině případů vyslovují potřebu vidět záměr IT projektů ještě před tím, než se rozhodne o jeho reálné implementaci, a tedy pokračování do následující fáze – Zahájení projektu.
Mnohdy obchodní útvar banky zajímá nejen oblast nákladů, tedy kompletně vyčíslený zmiňovaný Business case, ale i reálný dopad IT projektu na klienty banky a z toho plynoucí výnosy. IT projekty v bankách jsou specifické často i tím, že si stavějí za úkol nikoliv výnos, plynoucí z implementace, ale konsolidaci stávajících řešení, tedy
problematika transformace systémů banky. „V dnešní době sílí tlak ke snižování nákladů a ke snižování marží a poplatků s tím souvisejících. Zároveň trh nutí banky poskytovat lepší služby za nižší ceny. Tohoto stavu ale v žádném případě nelze dosáhnout, pokud
infrastruktura banky je založena na monolitickém řešení a tím pádem je naprosto neflexibilní a nedokáže se tím pádem rychle se rozvíjejícímu trhu přizpůsobit. Dále je potřeba myslet i na to, že dochází k čím dál většímu tlaku ze strany České národní banky a celoevropských institucí a regulačních orgánů, tím pádem banky musí být vždy připraveny naimplementovat požadovanou změnu.“ (Lukaševič, 2018, s. 29, cit. podle Vopršal, Hampl, 2005)
V rámci této fáze se často doporučuje zpracovat i dokument Logický rámec (též
Logframe). Tento dokument slouží za účelem, aby bylo možné strukturovaně zformulovat hlavní parametry projektu. Formuluje se zde zadání a strategie projektu. Definují se zde mimo jiné cíle a přínosy projektu. Tento dokument je pouze doporučený. (Doležal, aj, 2013, s. 29)
3.2.2 Fáze Zahájení projektu – Co vše bude projekt obnášet?
Tato fáze následuje po fázi Idea a slouží již k zhotovení projektové dokumentace, která slouží k samotnému schválení IT projektu příslušnými stranami.
Zde Doležal (2013) uvádí jako hlavní dokumentaci s touto fází spojenou – WBS. Každý projekt je totiž svým způsobem komplexní a skládá se z postupně navazujících kroků.
Z toho důvodu je potřeba provést dekompozici celku na menší části. K tomu slouží nástroj WBS. Výsledná WBS zahrnuje výsledky celé práce, kterou je potřeba na projektu odvést, aby bylo dosaženo cíle. Účelem WBS je pokrýt sto procent věcného rozsahu projektu.
23
Projektový tým tedy má za úkol dodat vše, co je obsahem WBS, o nic více ani o nic méně.
(Doležal, aj, 2013, s. 57)
Z pohledu banky je tento dokument ve fázi Zahájení projektu důležitý z mnoha pohledů.
WBS pomáhá nastavit potřebný rámec postupné dodávky v rámci jednotlivých releasů.
Banka je specifická tím, že si nemůže dovolit udělat takovou chybu v rámci systémů, která by mohla způsobit nesprávné finanční výpočty s dopadem na klienty banky. Z tohoto důvodu lze všechny změny striktně nasazovat v nasazovacích oknech (releasech) a tyto okna určují rámec WBS.
Dále WBS v rámci banky pomáhá nastavit časový rámec pro realizaci pilotu. Zde je tím myšleno to, že mnohdy změna, která je způsobena IT projekty v bance, vede k potřebě tuto změnu opravdu řádně vyzkoušet na užším kruhu zainteresovaných lidí. WBS pomáhá určit termín tohoto vyzkoušení a odkomunikovat následně správný termín pro ostrý provoz.
Dále je v této fázi doporučován dokument – Tabulka souvislostí. Je potřeba totiž brát v potaz i vnější vlivy a různé dopady projektu na organizaci a případně i širší okolí. Zde může jít i o různé legislativní dopady. Slouží i k identifikaci veškerých oblastí, které mohou být projektem zasaženy. (Doležal, aj, 2013, s. 53)
Z pohledu banky je tento dokument mnohdy vyžadován právě za účelem, aby nedošlo k legislativnímu sporu případně negativnímu obchodnímu dopadu.
V rámci této fáze je ještě doporučován dokument – Registr zainteresovaných stran (Stakeholders register). Tento dokument má sloužit k identifikaci každého jedince, skupiny, atd., které budou IT projektem zasaženy. Cílem je uvědomit si očekávání jednotlivců případně skupin spojených s projektem, aby byla zajištěna co největší spokojenost zainteresovaných stran. (Doležal, aj, 2013, s. 47)
V rámci banky je tento dokument též mnohdy vyžadován. IT projekty mají často dopad na útvary Backofficu a Frontofficu a tento dokument mimo jiné slouží k identifikaci
relevantních útvarů a zajištění jejich kapacit, ať už v rámci analýzy, kdy dochází ke komunikaci s těmito útvary za účelem dosáhnout již zmiňované spokojenosti, tak i kapacity na straně testovaní, kdy jsou tyto útvary potřebné v momentě UAT testů.
3.2.3 Fáze Plánování – Jak by měl projekt proběhnout?
V této fázi vzniká hned několik dokumentů. První dobrovolný dokument je – Plán řízení projektu (Project management plan). Tento dokument se obzvlášť doporučuje u složitých a velkých IT projektů. Je zde velmi důležité stanovit některé postupy a procesy tak, aby byl projekt efektivně řízený, vytvořit tedy Plán řízení projektu. Tento dokument stanovuje domluvu, jak by měl být daný projekt řízený a je určen hlavně pro projektový tým, který se tímto postupem musí dále řídit. Pokud tento dokument nebude zpracován, může to vést k tomu, že potřebné procesy nebudou probíhat, nebo budou probíhat chybně. To následně povede ke zdržení a finančním ztrátám. (Doležal, aj, 2013, s. 69)
V bance je tento dokument doporučován pro to, aby bylo v rámci projektového týmu jasné, mimo jiné, jaká je maximálně tolerovaná odchylka v harmonogramu. Jak bude probíhat řízení lidských zdrojů v projektu. Jak bude docházet k předávání informací v projektu. Jak budou řešena rizika a jak bude probíhat změnový proces projektu. To vše je dobré sdělit
24
projektovému týmu před samotným zahájením projektu. B/O útvary v bance totiž mnohdy mají vyčleněnou omezenou kapacitu z důvodu, že jejich hlavní činností je podpora v rámci B/O a nemohou si dovolit věnovat projektu více, než jim jejich čas dovoluje. Z toho důvodu je potřeba dopředu nastavit očekávání od jednotlivců v týmu.
Dalším dokumentem je – Matice odpovědnosti (Responsibility matrix). Tento dokument je vyžadovaný v rámci IT projektů. Při plánování projektu je potřeba rozdělit práci na
projektu mezi projektový tým tak, aby za každou část projektu byla zodpovědná jedna osoba, a aby bylo jasné, kdo práci provádí a kdo je za ní zodpovědný. S kým případně lze jednotlivé otázky řešit. Tento dokument slouží k vymezení kompetencí jednotlivých členů týmu. Často se této dokumentaci říká RAM nebo RACI či RASCI matice. Jedná se o poměrně jednoduchou metodu, jak efektivně rozdělit práci a pokrýt tím zodpovědnost za celou WBS. (Doležal, aj, 2013, s. 79)
Dalším doporučovaným dokumentem Doležal (2013) uvádí – Organizační struktura, role a odpovědnosti. (Organization structure, roles and responsibilities). Tento dokument slouží jako podpůrný prostředek pro zformování týmu, pro stanovení rolí a zodpovědnosti a návazně i jako prostředek komunikace. Stává se, že vztahy na projektu často nejsou jasné, z toho důvodu je dobré, aby ke vzniku tohoto dokumentu došlo. Tento dokument má zamezit především komunikačním a kompetenčním sporům a šumům. (Doležal, aj, 2013, s.
85)
V bance, zde je to obdobné s jinými organizacemi, je dobré organizační strukturu
definovat. Často se totiž jedná o IT projekty, kdy jsou vedené projektovými manažery, ale samotní zúčastnění zaměstnanci jsou vedeni liniovým manažerem. Z toho důvodu je dobré jednotlivcům správně definovat oblast zodpovědnosti a manažera, kterému se v dané oblasti musí zodpovídat. Toto by mělo být vždy před samotným vytvořením této dokumentace prodiskutováno mezi projektovým manažerem a liniovým manažerem jednotlivých zúčastněných. Často k této diskusi dochází v rámci zhotovení Registru zainteresovaných stran, kdy cílem projektového manažera je zajistit potřebné kapacity u liniového manažera a zároveň prodiskutovat, v jaké oblasti či procesu je jedinec komu zodpovědný.
Dalším doporučeným dokumentem je Komunikační plán (Communication plan). Často je tento dokument využíván, pokud má projekt dopad na širší okolí a je vhodné tedy s tímto okolím komunikovat. Jedná se o klíčový nástroj, jenž projektovému týmu usnadňuje komunikaci se zainteresovanými stranami. (Doležal, aj, 2013, s. 91)
Dalším doporučeným dokumentem je Rozpočet a finanční plán (Budget and costs baseline). Rozpočet by měl detailně specifikovat výdaje a náklady projektu a často je doplněný i o zdroje příjmů, výnosů a benefitů, plynoucích z projektu. Plán čerpání je rozepsán po jednotlivých časových úsecích, tedy například po měsících. Tento dokument je skoro vždy nezbytnou součástí projektové dokumentace v této fázi. (Doležal, aj, 2013, s.
97)
Z pohledu banky je tento dokument ve většině případů vyžadován. Banka tímto
dokumentem řídí jak operativní (OPEX) a investiční (CAPEX) náklady, tak i personální náklady (PEREX). V rámci IT projektu často dochází k již zmiňované redukci zastaralých systémů a z toho plynou příslušné úspory. Tyto benefity se do tohoto dokumentu také promítají. Před tím ale musí vždy dojít k samotnému vyčíslení těchto benefitu. Toto
25
vyčíslení též není často jednoduché a stojí za tím mnoho diskusí jak s infrastrukturním útvarem banky, s Vendor managementem a s útvarem finančního řízení banky.
Dalším povinným dokumentem v této fázi je Registr rizik (Risk register). S každým projektem jsou totiž spojená určitá rizika, která se v rámci IT projektu mohou vyskytnout.
Analýza rizik je samotná a dosti rozsáhlá disciplína, která se snaží rizika správně
odhadnout, ať už jejich pravděpodobnost, nebo velikost. Řízení rizik pak má za úkol snížit pravděpodobnost výskytu, zmírnit případné dopady a vytvořit nouzový plán pro případ naplnění hrozby rizika. Jedná se o živý dokument, jelikož se rizika v průběhu projektu často mění a doplňují. (Doležal, aj, 2013, s. 105)
Ohledně této disciplíny – Řízení rizik, vznikla spousta odborné literatury a jiných
diplomových prací. Z toho důvodu se autorka v této práci o náležitostech této dokumentace více nerozepisuje i přes to, že jsou rizika a práce s nimi velice důležitou součástí vedení IT projektu a převážně pak v bance. Banka je totiž velice náchylná na veškeré dopady na legislativu. Je velice omezena legislativními požadavky a při překročení těchto
legislativních požadavků může dojít k vysoké penalizaci ze strany ČNB.
Posledním potřebným dokumentem v této fázi je Harmonogram (Schedule baseline). Tento dokument popisuje, které úkoly by měly proběhnout, kdy by měly proběhnout a kdo je uskuteční. Tento dokument slouží k tomu, abychom eliminovali možný problém s časovým rámcem, který máme v rámci projektu definovaný. Bez projektových harmonogramů nemůže být řeč o hospodaření s lidskými a dalšími zdroji v rámci projektu. (Doležal, aj, 2013, s. 111)
Mnohdy je v bance využívána k sestavení tohoto dokumentu WBS. Důvod, proč je tento dokument důležitý, je stejný, který již byl popsán v oblasti, zabývající se dokumentem WBS. Banka je totiž velice striktně omezena v nasazovacích oknech a tím pádem je potřeba řádně plánovat časový rámec jednotlivých funkčností.
3.2.4 Fáze Realizace projektu – Jak projekt uřídit?
Dále zde máme samotnou fázi realizace projektu. Zde z pohledu dokumentace se musejí vyskytovat Zápisy z porady (Meeting minutes). Tento dokument slouží k zaznamenávání a sdílení informací o průběhu a výsledcích jednotlivých porad. Tyto dokumenty často obsahují seznam úkolů, plynoucí z porady s označením zodpovědné osoby a termínu splnění. Je doporučení vždy na začátku další porady tyto úkoly projít. Tento dokument často slouží i jako důkazní materiál a prokázání některých rozhodnutí, které na poradě padly. (Doležal, aj, 2013, s. 123)
Dalším doporučeným dokumentem v této fázi je Report o stavu projektu (Project status report). Za pomoci tohoto dokumentu jsou shromažďovány klíčové informace o stavu projektu a jeho předpokládaném vývoji. Pravidla hlášení je vždy na rozhodnutí příslušných osob, ale vždy se jedná o pravidelné reporty v daném časovém úseku. Reporting slouží jako informace pro okolí projektového týmu. (Doležal, aj, 2013, s. 131)
V bance se často plánuje projektový status v intervale jednoho týdne. Jeho cílem je sladění se mezi obchodními, IT a B/O útvary. Dále jsou jednotlivé projekty reportovány nejčastěji v intervale jednou za 14 dnů v rámci Řídícího výboru (Steering Committee). Jednotlivé
26
projekty jsou nejčastěji zařazeny pod různé skupiny, kterých se projekt týká a dle těchto skupin se plánuje sestava Řídícího výboru v rámci reportování.
Dalším doporučeným dokumentem je Seznam bodů k řešení (Issue log). Tento dokument vede k otevřenosti a společnému sdílení mezi jednotlivými členy projektu. Jedná se o seznam otevřených bodů a problémů, které je nutno při realizaci řešit. Jedná se o
problémové části, ke kterým dochází mimo rámec projektu. Takové otevřené body je nutno komunikovat a zaznamenávat, též je nutné přiřadit zodpovědnou osobu a termín vyřešení.
Jedná se o přehledný a komplexní způsob řízení bodů, které je nutné v rámci projektu vyřešit. (Doležal, aj, 2013, s. 137)
Další doporučenou dokumentací je Změnový požadavek (Change request). Je velice časté, že v průběhu projektu dojde ke změnám původní specifikace. Projekt musí umět na tyto změny pružně reagovat a hlavně každý takový zásah musí být zaznamenaný a
dohledatelný. Týká se to veškerých změn na projektu, ať už WBS, Harmonogram či Rozpočet. Takto lze selektovat takové změny, které vznikají na základě „chodbových dohod“. Každý požadavek na změnu by měl projít určitým procesem, který změnu vyhodnotí, a buď doporučí, nebo nedoporučí k realizaci. (Doležal, aj, 2013, s. 143) Z pohledu banky je tato dokumentace poměrně významná. Každý změnový požadavek často stojí banku další náklad a jelikož je útvar IT stále vnímán, jakožto podpůrný útvar v bance, musí se toto navýšení důkladně obhájit. Toto je pak úloha projektového manažera, aby zajistil, že všechny změny se budou dít s jeho obeznámením a že bude přímo
rozhodovat o jejich realizaci.
Dalším doporučeným dokumentem je Seznam poučení (Lessons log). Je to místo pro zaznamenávání zkušeností. Jedná se o zaznamenávání v průběhu celého projektu a slouží především k popisu negativních či pozitivních událostí v průběhu projektu. Doporučuje seznam kroků pro budoucí projekty. (Doležal, aj, 2013, s. 149)
3.2.5 Uzavírání projektu – Jak projekt správně zakončit?
Jedná se o poslední fázi projektu a s tím spojenou dokumentaci. První doporučenou dokumentací je Předávací protokol (Handover). Slouží k formálnímu předání plnění nebo díla odběrateli. Po předání zpravidla začíná běžet lhůta k připomínkování a akceptaci.
V protokolu je potřeba uvést předmět předání ve vazbě na smlouvu. Dokument slouží jako právní důkaz, že předání proběhlo. (Doležal, aj, 2013, s. 157)
Banka v tomto případě se vyznačuje tím, že Předávací protokol se často používá i mezi IT útvarem a ostatními útvary banky. Jedná se o dokument, který definuje, co IT útvar v rámci projektu dodal. Protokol slouží k následnému uchování a k tomu, aby v budoucnu nedošlo k rozporování dodávky projektu.
Dalším nutným dokumentem je Akceptační protokol (Acceptance). Zákazník tímto potvrzuje dokončení díla a jeho správnost a kvalitu. Akceptační protokol slouží jako doklad o provedení akceptační procedury. Tato procedura nám umožňuje ověřit kvalitu předávaného plnění. Součástí akceptačního řízení mohou být i předepsané testy. (Doležal, aj, 2013, s. 163)
27
V bance se tento dokument často využívá ať už v rámci interních záležitostí – v rámci předávky mezi IT útvarem a jiným útvarem banky, nebo v rámci předání od externího dodavatele do banky. Součástí jsou skoro vždy příslušné testy, které by měly proběhnout.
Ať už se jedná o penetrační testy či uživatelské testování. Tento dokument je právě často spojován s konečnými testy a k jeho akceptaci dochází po pozitivním výsledku testování.
Další nutnou dokumentací je Vyhodnocení projektu (Project closure). Zpracovává se v okamžiku ukončení realizační fáze projektu. Tento dokument sumarizuje výsledky dosažené projektem a porovnává je s kritérií úspěšnosti, které byla formulovány při zahájení projektu. Pomocí tohoto dokumentu lze říct, zda a jak moc byl projekt úspěšný či nikoliv a poučit se z toho do budoucna. (Doležal, aj, 2013, s. 169)
Posledním doporučenou dokumentací je Poučení z projektu (Lessons learned). Obsahuje strukturovaně zaznamenané zkušenosti, které projektový tým zaznamenal v průběhu celého projektu. Je to cenné pro ostatní týmy, které by v budoucnu realizovali obdobný projekt.
3.3 Závěry z kapitoly
V rámci této kapitoly bylo vysvětleno, čím jsou IT projekty specifické a jaká kritéria musí splňovat. S jakými úskalí se můžeme v rámci IT projektů potýkat a proč tyto problémy vznikají.
Zároveň byly krátce představeny metriky, dle kterých se IT projekty řídí. V kapitole bylo věnováno i objasnění důležitosti metodik, se kterými se v IT projektech můžeme setkat a popsáno, co všechno by měla taková metodika obnášet a byla krátce popsána metodika RUP.
Dále bylo v krátkosti věnováno i obecně uznávaným standardům, se kterými se v IT projektech můžeme setkat, jako například PMBOK, IPMA, Prince 2.
Podkapitola 3.2 se věnovala specifikům IT projektové dokumentace se zaměřením na banku. Byly zde popsány jednotlivé projektové dokumenty, které se v rámci fází projektu vyskytují (Fáze Idea, Zahájení projektu, Plánování, Realizace a Ukončení).
28
4 Analýza chyb plynoucích z dokumentace a chyby v IT projektech obecně
V této kapitole se autorka zaměří na identifikaci vyskytujících se chyb v rámci projektové dokumentace a následně chyb v IT projektech obecně.
Je nutné podotknout, že pouze 29 % IT projektů bývá podle průzkumu Standish Group dokončena úspěšně. Mnoho SW společností a projektových expertů se shodují na tom, že vedení IT oddělení se dopouští mnohdy stejných chyb. (Metodický portál, 2012, s. 58) Chyby se vyskytují nejen při ignorování obecně platných pravidel, ale i při nesprávném obsazování významných rolí na projektu. Dále pak v nedostatečné schopnosti zvážit rizika, která ohrožují projekt, případně chyby v postupech, jak těmto rizikám předejít. (Metodický portál, 2012, s. 58)
4.1 Chyby v projektové dokumentaci
Alena Svozilová (2016) v knize Projektový management definuje nejčastější problémy řízení projektů. Rozlišuje mimo jiné tyto problémy dle fází, kde se vyskytují, následujícím způsobem. Autorka diplomové práce vybrala ty problémy, které úzce souvisejí
s projektovou dokumentací a na které se následně zaměří v návrhu na zlepšení v rámci této diplomové práce:
• Při iniciaci:
Mezi projektovým manažerem a strategickými záměry podniku nedošlo k dokonalému vyjasnění a následně nebyly správně definovány cíle projektu. (Svozilová, 2016, s. 78) Autorka této diplomové práce v kapitole, která se zaměřuje na návrh na zlepšení ve fázi idea projektu (kapitola 6.3.1), bude pojednávat o tom, jak této chybě předejít. Krátce řečeno, je velice důležité vždy před zahájením jakéhokoliv projektu projít kontext projektu s co nejvíce relevantními lidmi, hlavně by se mělo jednat o členy Řídícího výboru, kteří následně daný projekt budou schvalovat.
• Při plánování:
Nedokonalé zpracování podrobného rozpadu práce a následně nedostatečně dobré
promítnutí tohoto rozpadu práce do harmonogramu a rozpočtu projektu. (Svozilová, 2016, s. 78)
Opět tento problém autorka diplomové práce bude řešit v rámci kapitoly návrhu na zlepšení v rámci plánovací fáze (kapitola 6.5.1). Je potřeba vždy myslet na to, že zvlášť u IT projektu je potřeba počítat s rizikem, že některá dodávka IT systému bude z mnoha různých důvodů protažena a nebude možné toto ovlivnit z důvodu problematiky
technického řešení. Zabránit tomuto faktoru projektovému manažerovi by mělo pomoci
29
vydefinování si několika oblastí v rámci IT, na které se musí zaměřit a které mu budou sloužit jako záchytné body. Co se týče promítnutí rozpadu práce do rozpočtu projektu – tento problém autorka též bude řešit v již zmíněné kapitole a vydefinuje několik bodů, kterých se projektový manažer opět může držet a které mu mohou v rámci prvotního návrhu rozpočtu pomoci. V kapitole 6.7.1 bude autorkou zároveň navrženo sledování rozpočtu projektu v rámci celého jeho průběhu, aby se dařilo projektovému manažerovi udržet finance projektu pod kontrolu po celou dobu trvání projektu.
Nejasnosti a nejednoznačně formulované cíle projektu a jejich nesprávná komunikace sponzorovi projektu. (Svozilová, 2016, s. 78)
Eliminaci této chyby autorka řeší též v rámci plánovací fáze (kapitola 6.5.1). Autorka říká, že ve chvíli schvalování projektu do plánovací fáze je dobré mít všechna klíčová fakta na jednom místě pro strukturovanější a jednoznačnou prezentaci. Doporučuje mít v prezentaci pro schvalovací orgán některé body, které tento orgán určitě zajímají a které právě zabrání tomu, že dojde k nedorozumění mezi projektovým manažerem a schvalovacím orgánem (sponzorem) projektu.
• Při koordinaci a řízení prací:
Dochází ke konfliktům mezi liniovým manažerem a projektovým manažerem. (Svozilová, 2016, s. 79)
Tento problém autorka otevírá též dále v návrhu na zlepšení v rámci plánovací fáze (kapitola 6.5.1) v oblasti lidských zdrojů. Zásadní pro projektového manažera je vždy od první chvíle komunikovat s liniovými manažery a nastavit si správná očekávání.
• Při monitorování a kontrole:
Nedostatečně správně prováděné kontroly po časové stránce a zkreslování výsledků.
(Svozilová, 2016, s. 79)
Tato problematika se bude řešit v návrhu na zlepšení v rámci realizační fáze (kapitola 6.6.1). Autorka navrhne jasně definovanou a zároveň obecnou strukturu, která by měla projektovému manažerovi pomoci při kontrolách prováděných prací v časových úsecích.
Dochází k nedorozumění v komunikaci cílů projektu a jejich záměrů mezi členy projektu a projektovým manažerem. Některé komunikační kanály nejsou dostupné pro všechny členy týmu. (Svozilová, 2016, s. 79)
Tento problém bude autorka řešit v rámci fáze sledování a kontrola projektu (kapitola 6.7.1). Je potřeba již při zahájení projektu nastavit jasnou spolupráci v týmu. Pomoci k tomu může kick-off schůzka na které projektový manažer představí očekávanou spolupráci v týmu a jasně vykomunikuje na všechny členy týmu dodržování těchto
pravidel. Nejlepším možným řešením je připravit prezentaci dostupnou pro všechny členy týmu. Body, které by měla daná prezentace obsahovat, autorka uvede ve zmíněné kapitole.
Zároveň autorka bude pojednávat o struktuře dokumentu, ve kterém všichni členové týmu najdou potřebné informace a odkazy na jednotlivé dokumenty projektu.
30
Nedostatečné ověřování a kontrola kvality mezivýsledků, které se předávají mezi členy projektu v jednotlivých krocích zpracování. (Svozilová, 2016, s. 79)
Eliminaci této chyby autorka řeší též v kapitole 6.7.1. Navrhuje vytvořit mimo jiné jednu hlavní schůzku projektu, které se účastní všichni participující členové týmu v rámci organizační struktury. Na této schůzce se vždy minimálně procházejí oblasti: analýza, vývoj, testy.
Špatná kontrola v oblasti řízení rizik projektu. (Svozilová, 2016, s. 79)
V kapitole 6.7.1 se autorka na eliminaci této chyby zamíří. Autorka krátce navrhne strukturu zanesení rizik projektu a jejich kontrolu.
• Při uzavření projektu:
Špatně navržené metody pro řízení změn v prostředích, do kterých se výsledek projektu promítne. (Svozilová, 2016, s. 79)
Tento problém bude autorka řešit v rámci kapitoly 6.7.1. Navrhne metodiku pro postupné zanesení změn od IT k business útvarům. Navržená aktivita v sobě obnáší přípravu příslušných business útvarů k novému/změněnému řešení.
Nedostatečně správně vydefinovaná akceptační kritéria a špatná formulace. Nevhodně navržené akceptační procedury. (Svozilová, 2016, s. 79)
Tomuto problému se v rámci projektové dokumentace a návrhu na zlepšení této dokumentace se autorka bude věnovat v rámci fáze uzavření projektu (kapitola 6.8.1).
Navrhne šablonu, která bude obsahovat minimální možné požadavky na akceptační protokol.
4.2 Chyby v lidských zdrojích
Nejčastější chyby a rizika v IT projektech definuje Meridith Levinson a Irena Krupičková na portálu Řízení podniku (2010). Tento výčet by měl pomoci určit zranitelná místa IT projektu a zajistit opatření k jejich nápravě.
• Chyba č. 1: Projekt nemá lidský kapitál s požadovanými znalostmi a dovednostmi.
V žebříčku nejběžnějších chyb figuruje nesprávně alokovaný lidský kapitál na nejvyšší příčce v nejběžnějších chybách při projektovém řízení. Nedostatek akceschopného týmu dokáže daný projekt urychleně přivést k neúspěchu. (Levinson, Krupičková, 2010) Předejít této chybě je potřeba následujícím způsobem. Je nutné, aby projektový a IT manažeři měli detailní přehled o schopnostech a pracovním zatížením svěřených jim pracovníků. Týká se to nejen interních zaměstnanců, ale i svěřených zdrojů – sítě konzultantů, dodavatelů a outsourcing. Tito externí dodavatele bývají často ignorování i přes to, že odvedou nejčastěji velký kus práce na projektu. V momentě, kdy projektový manažer ví, jaké zaměstnance má k dispozici, je potřeba, aby v rámci projektu rozvrhnul práci mezi tyto zaměstnance po určitých časových úsecích. K tomu lze využít mnoho
