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
diplomových prací. Z toho důvodu se autorka v této práci o náležitostech této dokumentace