Nasazení IT systému v bance

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Nasazení IT systému v bance Diplomová práce

Autor:

Bc. Radan Novák Informační technologie a management

Vedoucí práce:

Praha

Ing. Martina Hábová, Ph.D.

Duben, 2009

Prohlášení

Prohlašuji, že jsem bakalářskou resp. diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne 15.4.2009 ..............................................

Radan Novák

Poděkování

Ing. Martině Hábové, Ph.D. za precizní odborné vedení při vypracovávání diplomové práce, především za její podnětné a hodnotné nápady a připomínky, které dozajista přispěly k významnému zkvalitnění celé diplomové práce.

Anotace práce Ve své diplomové práci popisuji obecný proces nasazení IT systému začínající předprojektovou etapou, tvořenou sběrem námětů, které se následně vyhodnocují a schválené posunují dále ke spuštění projektu. Následuje etapa zahájení, kde se specifikují cíle projektu a hrubé vymezení rozsahu projektu, jako je plán, harmonogram, rozpočet a alokace jednotlivých rolí. Etapa plánování analyzuje základní požadavky na projekt, jsou zpracovány a vyhodnoceny plány projektu. Následuje realizační etapa, ve které se provádějí činnosti, které produkují měřitelné projektové výstupy jako jsou vývoj, testování a zavedení do produkce. V dalších kapitolách se věnuji rizikům projektu, popisuji role a jejich zodpovědnosti a pravomoci. Poté se věnuji nástrojům řízení projektů, popisuji vedení projektových týmů, protože v lidské faktoru a zkušenosti členů projektu, včetně projektového manažera, spatřuji silný nástroj k úspěšné implementaci systému. V teoretické části se věnuji metodikám projektového řízení, kde standardizované postupy považuji také za klíčové. Další tematickou částí mé práce je popis procesu nasazení IT systému v reálné bance. Závěr věnuji srovnání teorie a praxe.

Annotation My diploma thesis describes a general procedure of an IT system implementation. The description starts from the pre-project stage, commencing by collection of subjects to be subsequently evaluated and, after having been approved, submitted to the project initiation phase. The next stage is the launch phase, which defines project objectives and general project specifications, e.g. plan, time-schedule, budget and allocation of individual roles. The planning stage analyses basic requirements related to the project, with development and evaluation of project plans. This stage is followed by the implementation stage, which involves activities producing measurable project outputs, e.g. development, testing and implementation within production processes. Further chapters deal with project risks and describe individual roles and responsibilities and powers related thereto. Then I focus on project management tools and description of project team management, because in my opinion the human factor and expertise of the project team members constitute a powerful tool of a successful system implementation process. In the theoretical section I deal with project management methodologies, with standardized procedures assessed as key elements. This section is followed by description of an IT system implementation within a real bank. The final part is devoted to comparison of theory and practice.

Obsah Úvod ...................................................................................................................................... 7 1.

2.

3.

Metodiky projektového řízení ........................................................................................ 7 1.1

COBIT .................................................................................................................... 7

1.2

ITIL ......................................................................................................................... 9

1.3

CMMI ................................................................................................................... 12

1.4

Scrum .................................................................................................................... 13

1.5

RUP ....................................................................................................................... 16

1.6

MSF ...................................................................................................................... 18

Obecný proces nasazení IT systému ............................................................................ 21 2.1

Definice etap ......................................................................................................... 21

2.2

Předprojektová etapa............................................................................................. 23

2.3

Etapa zahájení ....................................................................................................... 23

2.4

Etapa plánování..................................................................................................... 24

2.5

Realizační etapa .................................................................................................... 25

2.6

Etapa hodnocení .................................................................................................... 25

2.7

Rizika projektu ...................................................................................................... 25

Techniky řízení projektů .............................................................................................. 27 3.1

Metody plánování ................................................................................................. 27

3.1.1

WBS - Work Breakdown Structure................................................................... 27

3.1.2

AND - Activity Network Diagram .................................................................... 29

3.1.3

Ganttův diagram ................................................................................................ 32

3.1.4

Afinní diagram .................................................................................................. 33

3.1.5

PDPC diagram ................................................................................................... 36

3.1.6

Mapa procesu .................................................................................................... 39

3.1.7

Korelační diagram ............................................................................................. 40

3.2

Role, zodpovědnosti a pravomoci ......................................................................... 41 5

3.2.1

Projektový řídící výbor ..................................................................................... 42

3.2.2

Projektová kancelář ........................................................................................... 43

3.2.3

Majitel projektu (Business vlastník) ................................................................. 43

3.2.4

Projektový vedoucí (Project manager) .............................................................. 44

3.2.5

Projektový tým .................................................................................................. 45

3.3

4.

5.

Vedení projektových týmů.................................................................................... 46

3.3.1

Komunikace v týmu .......................................................................................... 46

3.3.2

Struktura týmu ................................................................................................... 47

3.3.3

Pozice a role v týmu .......................................................................................... 47

3.3.4

Vedení týmu ...................................................................................................... 48

3.3.5

Problémy v týmu ............................................................................................... 48

Proces nasazení IT systému v bance ............................................................................ 49 4.1

Fáze přípravy a schválení plánu projektů ............................................................. 49

4.2

Přípravná fáze projektu ......................................................................................... 51

4.3

Zajištění externí dodávky systému IT ................................................................... 53

4.4

Funkční analýza a návrh řešení ............................................................................. 54

4.5

Příprava první verze testovacího plánu ................................................................. 55

4.6

Testování kvality................................................................................................... 57

4.7

Pilotní provoz, Baby sitting .................................................................................. 62

Srovnání teorie a praxe................................................................................................. 64

Závěry a doporučení ............................................................................................................ 68 Seznam použité literatury .................................................................................................... 69 Seznam obrázků................................................................................................................... 70 Použité zkratky a terminologie ............................................................................................ 71 Přílohy ................................................................................................................................. 76

6

Úvod Podnět k iniciaci nasazení nového nebo úpravě stávajícího IT systému může být potřeba vyvolaná technologickým pokrokem, novými potřebami zákazníků, legislativní nutností, požadavky trhu, případně strategickým plánem rozvoje informačního systému. Zavádění IT systémů v bance rovná se téměř výhradně projekt. To znamená, že klíčovou vlastností pro zavedení jakéhokoli systému je úspěšné ukončení jednotlivých projektů, stejně tak jako celého programu. Klíčové je proto mít kvalitní, excelentní projektovou metodiku, jakožto jednotnou kuchařku pro projekty v organizaci, standardizovat postupy a umožnit využití přínosů z opakovaných činností. Banky jako takové také prochází povinně mnoha různými audity (ČNB, korporátní audity, bezpečnostní audity a další) a je proto nutné mít vše klíčové standardizováno a návazně zapracováno do procesů. Těmito metodikami se pak řídí nejen projekty v IT, ale i ostatní projekty mimo sféru IT. Hodnocení úspěšnosti, přínosů a auditování je pak jednoznačné a Project manager, jakožto vedoucí osoba zodpovědná za projekt jako takový a za jeho úspěšné nasazení se jako osoba stává jednoduše zástupnou. Obecně totiž platí, že Project manager nemusí být odborníkem na řešenou problematiku, ale odborníkem pro řízení projektových týmů.

1. Metodiky projektového řízení 1.1 COBIT COBIT (Control Objectives for Information and Related Technology) - byl vyvinut jako všeobecně přijímaný standard pro správný postup řízení, kontroly a auditu informačních technologií. •

cíle řízení pro informační a s nimi spojené technologie

•

COBIT je zaměřený na business, je procesně orientovaný, založených na kontrolách a řízený metrikami

7

V současné době standard pro hodnocení úrovně provádění procesů informatiky a pro podporu jejího řízení •

COBIT pokrývá všechny aspekty řízení informatiky, zatímco ITIL je zaměřen na řízení ICT infrastruktury a jejích služeb, takže například ITIL neobsahuje oblast řízení lidských zdrojů, zatímco COBIT ano. Jeho nejčastější použití je jako nástroj auditu úseku informatiky a jeho strategického řízení

•

oproti ITIL je COBIT zdarma

•

COBIT umožňuje beze změny certifikovat oblast IT na normu ISO 9001:2000 1

COBIT pro jednotlivé oblasti definuje: •

cíle řízení

•

procesy definuje do 4 domén

•

zdroje přiřazené k procesům

Domény: •

plánování a organizace

•

akvizice a implementace

•

dodávka a podpora

•

monitoring a evaluace

Je založený na kontrolách Procesy potřebují kontrolní mechanismy – politiky, procedury, praktiky a organizační struktury, které zajišťují, že budou dosaženy business cíle, případně budou neočekávané události detekovány a vyřešeny. Hlavní důvody pro použití metodiky COBIT •

COBIT formalizuje IT procesy do jednoduché tříúrovňové struktury

•

implementace základní procesní struktury je jednoduchá a logická

•

struktura COBITu je srozumitelná managementu, uživatelům a auditorům

•

umožňuje beze změny certifikovat oblast IT na normu managementu jakosti ISO 9001:2000

1

Cobit Stearing Committee. Cobit Framework, Second edition. Information Systems Audit and Control Foundation

8

•

COBIT definuje odpovědnosti procesů včetně odpovědnosti, pravomoci a obsah IT vazeb na kritické faktory a podnikové cíle

•

COBIT obsahuje konzistentní vazby mezi podnikovou a informační strategií: -

neIT management pomocí COBITu dokáže lépe definovat a strukturovat požadavky na IT a hodnotit jeho celkovou úspěšnost

-

IT management dokáže pomocí vazby IT cíle <–> Business cíle lépe komunikuje s vrcholovým vedením podniku a prosazuje své potřeby (vstupy pro plánování, zdroje, apod.)

-

umožňuje konzistentní propojení metodiky BSC (Balanced Scorecard) mezi celopodnikovou úrovní a IT úrovní

•

COBIT

obsahuje

komplexní

návrh

výkonnostních

i

výsledkových

ukazatelů/metrik 2

1.2 ITIL ITIL (Information Technology Infrastructure Library) - je sada postupů a doporučení jak řídit IT služby na základě nejlepších praktických zkušeností, přičemž ponechává velikou volnost při implementaci těchto procesů a doporučení. Z tohoto důvodu je možná lepe nehovořit o metodice ale o souhrnu doporučení (Best Practices). Šíření těchto doporučení je prováděno formou školení, kurzů, knih, CD a certifikací. Metodika ITIL je výhradně určena pro každodenní řízení IT služeb a ICT infrastruktury. Knihovna ITIL je rozdělena do 8 svazků, vždy zaměřených na specifickou oblast řízení IT služeb, které odpovídají klíčovým procesům v IT oddělení a vzájemně se prolínají.

Jedná se o: •

podnikatelský pohled (Business Perspectives)

•

správa aplikací IT (Aplication Management)

•

dodávka IT služeb (IT Services Delivery)

•

podpora IT služeb (IT Services Support)

•

správa IT infrastruktury (IT Infrastructure Management)

2

Wikipedie, Control Objectives for Information and related Technology (COBIT), dostupný z URL: http://en.wikipedia.org/wiki/COBIT

9

•

řízení IT projektů IT (Project Management)

Charakteristické rysy ITIL •

procesní řízení - ITIL používá moderní procesně orientovaný přístup k řízení IT služeb. Proces je logický sled úkolů transformujících nějaký vstup na nějaký výstup, přičemž plnění jednotlivých úkolů v procesu je zajišťováno rolemi s jasně definovanými odpovědnostmi. Celý proces je řízen, monitorován, vyhodnocován měřen, a neustále vylepšován, což je odpovědností vlastníka procesu

•

zákaznicky orientovaný přístup - všechny procesy jsou navrženy s ohledem na potřeby zákazníka - každá aktivita musí přinášet nějakou přidanou hodnotu pro zákazníka

•

jednoznačná terminologie

•

nezávislost na platformě

•

Public Domain - každý si může knihy ITIL koupit a procesy ITSM (IT Service Management) podle ITIL ve svém podniku implementovat 3

3

KRŮTA, Vladimír, Procesy pro kvalitnější správu IT služeb

10

Obrázek 1 - schéma ITIL

Obsah ITIL •

Definování procesů potřebných pro zajištění ITSM: -

stanovení cílů, vstupů, výstupů a aktivit každého procesu

-

stanovení rolí a jejich odpovědností v daném procesu

-

způsob měření kvality poskytovaných IT služeb a účinnosti ITSM procesů (performance a metriky)

•

•

-

vzájemné vazby mezi jednotlivými procesy

-

postupy auditu a zásady reportingu pro každý proces

Zásady pro implementaci procesů ITSM: -

přínosy každého procesu

-

Critical Success Factors, možné problémy a vhodná protiopatření

-

náklady na implementaci a následný provoz

-

zásady pro řízení podpůrné ICT infrastruktury

Zásady bezpečnosti ICT infrastruktury

11

1.3 CMMI CMMI (The Capability Maturity Model) - jedná se o soubor pravidel, požadavků a doporučení, které mají splňovat firemní procesy a co je třeba dodržovat, aby procesy vývoje byly efektivní, účinné a spolehlivé, přičemž důležitou charakteristikou modelu, která jej odlišuje od norem primárně zaměřených na procesy a kvalitu výroby je právě zaměření na procesy vývoje. CMMI je stavěno jako cesta, která pomáhá k neustálému zlepšování úrovně řízení a vývoje. CMMI model je složenina z několika původních modelů jako jsou např. CMMI for Services, for Software, for Acquisition. Jako integrované řešení je nazýván souhrnně CMMI od roku 2000. Složení CMMI modelu:

Disciplíny modelu CMMI: CMMI/SW - softwarové inženýrství (aplikace systematických, disciplinovaných a kvalifikovaných přístupů k vývoji, provozu a údržbě SW) CMMI/SE - systémové inženýrství (pohled na vývoj celého systému, popisuje implementaci procesů projektového vývoje sytému) SS – výběr dodavatelů a řízení dodávek Prvky modelu CMMI Procesní oblast – skupina pravidel, doporučení a praktik, které je vhodné společně implementovat z důvodu lepšího dosažení cílů stanovených v dané oblasti projektu. Úrovně CMMI Popisují kroky zlepšování procesů od neúplného stavu do stavu vylepšení. Bývají použity pro hodnocení úspěšnosti. Úroveň vyspělosti – vyjadřuje relativní zlepšení (porovnání předchozího a současného stavu) v dané oblasti. Umožňuje tak vylepšovat vybranou oblast procesů pomocí kontinuálního procesu vylepšování. Úroveň zralosti – vyjadřuje pevnou úroveň, která musí být dosažena. Díky tomu je jasně vytyčena úroveň, která musí být dosažena, aby se dalo prohlásit vylepšení za úspěšné. Tato hodnota je hlavním směrníkem ve stupňovité reprezentaci CMMI.

12

Rozdíl mezi kontinuální a stupňovitou reprezentací v CMMI charakterizujte jednotlivé úrovně. Kontinuální reprezentace používá úrovně vyspělosti (Capability level) pro popis relativního zlepšení v dané oblasti. Je flexibilnější pro zlepšení procesů, nezáleží na aktuální úrovni. Stupňovitá reprezentace – využívá definované, strukturované postupy pro zlepšení na základě referenčního modelu. Dosažení určité úrovně zralosti je východiskem k další úrovni. Úroveň 0 - vyspělost neúplná (proces není vykonáván vůbec, neexistují generické cíle a specifické cíle jsou vykonávány jen částečně), zralost neexistuje. Úroveň 1 – vyspělost vykonávaná (proces splňuje specifické cíle procesní oblasti), zralost úvodní ( sw. procesy jsou náhodné a chaotické, reagují pouze na vzniklé problémy) Úroveň 2 – vyspělost řízená (proces je vykonáván, plánován a monitorován na základě definic procesu), řízená zralost (jsou zavedeny a prováděny postupy řízení) Úroveň 3 – vyspělost definovaná (proces je řízen a je upravován podle definovaných postupů), zralost je definovaná ( procesy jsou dobře definované a chápané, jsou popsány ve standardech i pro vylepšení) Úroveň 4 – vyspělost kvantitativně řízená (proces je řízen a optimalizován pomocí kvantitativních technik), zralost kvantitativně řízená (definice metrik pro definované procesy pomocí kterých jsou měřeny a optimalizovány, lze předpovídat i vývoj stavu procesů) Úroveň 5 – vyspělost optimalizující (je kvantitativně řízen a stáje je optimalizován), zralost optimalizující (procesy se neustále zlepšují na základě chápání příčin). 4

1.4 Scrum SCRUM – z anglického slova Scrum (v ragby skrumáž, mlýn), je to agilní metodika, která vychází z objektově orientovaného přístupu. Slibuje zvýšit produktivitu a pružnost vývoje pomocí organizace práce v týmu, vhodná zejména na řízení projektů.

4

Buchalcevová, Alena, přednášky z předmětu „Systémová metodologie"

13

Vývoj pomocí SCRUM: začíná se plánovací fází (Pergame) kde se určí úkoly (Backlog), následují vývojové sprinty (měsíční vývojová epizoda, jejím cílem je uvolnění nové verze systému a představení nové funkčnosti). Sprinty se dělí na fázi vývoje, zabalení, revize a přizpůsobení. Na konci každého dne Sprintu je schůzka (Scrum Meeting = 15minut), která shrnuje co se udělalo, jaké byly problémy a plány do další schůzky. Definuje vývoj SW jako empirický proces (není ho možné přesně popsat a opakovat), je postavený na třech pilířích: viditelnost do procesu, inspekce, adaptace. Osoby zainteresované do projektu – pigs (vývojový tým) a chickens (ostatní - např. management, obchodníci, atd.).

Role SCRUM: ProductOwner = spravuje seznam požadavků (Backlog) Team = skupina lidí, která se řídí sama a cílem je v každém Sprintu dodat fungující software ScrumMaster = zodpovídá za SCRUM proces (jeho implementaci a maximální účinnost) Sprint •

všechna práce se dělá uvnitř sprintu. Sprint je 30 denní iterace.

•

na začátku sprintu se koná Sprint Planning Meeting: -

trvá max. 8 hodin

-

cílem je definovat Sprint Backlog

-

první 4 hodiny - Product Owner prezentuje požadavky nejvyšší priority v Product Backlogu, tým se dotazuje na obsah, účel, význam požadavků, nakonec vybere požadavky nejvyšší priority do Sprint Backlogu

-

druhé 4 hodiny – tým plánuje Sprint – jde o plán předběžný, který se neustále sprintu v průběhu upravuje

•

každý den se koná Scrum Meeting – 15 min.

•

na konci sprintu se koná Sprint review meeting: -

trvá 4 hodiny

-

tým prezentuje, co bylo vyvinuto

-

Sprint retrospective meeting zlepšení procesu a praktik 14

Principy Scrum •

•

Komunikace -

sdílení informací umožňuje viditelnost, lepší rozhodování a pochopení cílů

-

denní informování o (daily meeting) pokroku

-

je třeba vědět, jak na tom tým je a podle toho dělat rozhodnutí (Sprint backlog)

-

pracujte společně ( Stay in sync.)

Pravomoc týmu -

není nic mocnějšího než tým, který je omezován jen tím, jak kreativní je a jak tvrdě bude pracovat

•

•

Učit se a zlepšovat -

zkusit, prohlédnout výsledky, zlepšit sprint

-

krátké sprinty jsou efektivní

-

předvedení výsledků na konci sprintu (Sprint review)

-

zlepšení po každé iteraci (Sprint retrospective).

Dodat hodnotu včas -

priority požadavků (product backlog, Product Owner), dohoda o produktech, jejich dodání – to buduje důvěru mezi spolupracovníky, dalšími týmy a zákazníky

-

plánování sprint (Sprint planning meeting)

SCRUM meetings •

umožňují monitorovat stav projektu,

•

konají se vždy ve stejný čas na stejném místě

•

trvají méně než 30 minut (cílem je 15 minut)

•

vede je Scrum master

•

účastní se jich všichni členové týmu (vývojáři, uživatelé, testeři,...)

•

navštěvují je manažeři, aby věděli o stavu, ale aktivně se neúčastní

•

slouží ke zjištění problémů, ale ne k jejich řešení

•

každý účastník musí zodpovědět 3 otázky: - co udělal od poslední Scrum porady co bude dělat do příští Scrum porady - jaké překážky mu stojí v cestě

15

Scrum - zhodnocení: •

projektová metodika

•

zaměřená především na řízení projektu

•

chápe procesy při vývoji software jako empirické procesy, které není možné předvídat, ale je nutné je monitorovat. K tomu poskytuje praktiky jako denní porady, monitorování Sprintu (30 denní iterace) pomocí Backlog graph a dalšího.

•

explicitně tím že stabilizuje snižuje chaos při vývoji, úkoly pro 30 denní Sprint

•

je popsána jako jazyk vzorů (pattern language). 5

1.5 RUP Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje: iterativní vývoj, řízení požadavků, použití komponentové architektury, vizuální modelování, kontrola kvality software, řízení změn. Je založena na třech základních zásadách: •

řízení případů užití a rizik (snaha o co největší užitečnost pro zákazníka, pro to je důležité porozumění mezi zákazníkem a vývojovým týmem už od raných fázi, snaha o řízení projektu tak, aby byla minimalizována rizika)

•

základem je architektura (rozklad systému na části – komponenty, důležité jsou jejich vztahy a nasazení na HW) - řízení pomocí případů užití

•

iterativní a inkrementální vývoj

Je to instance metodiky Unified Process. Důraz je kladen na tzv. best practises (iterativní a inkrementální vývoj, použití komponentové architektury, řízení změn, kontrola a ověřování kvality, vizuální modelování (UML), správa požadavků, použití CASE nástrojů). Je třeba vytvářet jen to, co je nezbytné, minimalizovat papírovou dokumentaci, snažit se o flexibilitu, učit se z chyb, prověřovat rizika, definovat cíle a metriky (aby se mohl hlídat pokrok), používat nástroje na vývoj SW.

Hlavní myšlenky metodiky RUP – shrnutí: •

5

řešit hlavní rizika včas a kontinuálně

Buchalcevová, Alena, přednášky z předmětu „Systémová metodologie"

16

•

ujistit se, že je dodávána zákazníkovi hodnota

•

zaměřit se hlavně na fungující SW

•

umožnit změny v projektu

•

definovat včas architekturu

•

sestavit systém z komponent

•

pracovat společně jako jeden tým

•

chápat kvalitu jako základ vývoje (ne až zpětně)

Fáze a disciplíny v metodice RUP, Fáze iterativního vývoje - hlavní milníky: •

Počáteční fáze (Inception): je třeba pochopit co se bude vytvářet (vize, high-level požadavky, business case, ne detaily) definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu, možné realizovat.

•

Elaborační fáze (Elaboration): je třeba vědět jak vytvářet (architektura, detailizace většiny požadavků, ne detailní design), definovat architekturu systému a komponenty, je vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému.

•

Konstrukční fáze (Construction): vytváření produktu (výsledkem je fungující produkt, možnost provedení kompletních systémových testů), návrh a realizace systému včetně testování. Prosazuje se pokud možno paralelní vývoj.

•

Fáze nasazení (Transition): prověření řešení (splňuje očekávání, akceptace) zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření HelpDesku atd. Každá fáze je uzavřena milníkem – časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování.

Metodika Rational Unified Process patří mezi rigorózní metodiky, neboť podrobně definuje procesy a činnosti při vývoji software. Zaměřuje se pouze na vývoj nového řešení 17

realizovaný objektově orientovaným způsobem. Podstatným nedostatkem metodiky RUP je její zaměření pouze na úroveň projektu. Metodika má poměrně malý rozsah, neboť se zaměřuje pouze na vývoj řešení (nezahrnuje provoz a údržbu) a pouze na softwarově inženýrské role a dimenze. Silnou stránkou metodiky RUP je její integrace s CASE nástroji firmy Rational, které podporují především oblast analýzy a návrhu, testování, řízení konfigurací a správu požadavků. K výhodám patří, že je dodávána jako produkt, který zahrnuje znalostní bázi s webovým rozhraním a sadu nástrojů na přizpůsobení procesu a šablon do nástrojů firmy Rational. 6

1.6 MSF MSF (Microsoft Solutions Framework) zavádí proces do vývoje softwaru, ale neomezuje příliš kreativitu lidí. Snaží se odhalovat chyby a rizika včas. Tato metodika je vhodná pro menší týmy (velké týmy mohou fungovat jako „tým týmů“). Postup projektu je definován úspěšností testů a dalšími objektivními metrikami (počet chyb, pokrytí kódu, apod.). •

iterativní postup založený na scénářích

•

pracuje s požadavky na kvalitu a riziky

•

využívá testování v kontextu projektu

Vývoj v iteracích •

jednotlivé úlohy, chyby, scénáře apod. jsou přiřazovány verzím (iteracím) – např. Beta1, RC, RTM

•

každá iterace je vždy jasně uzavřena

•

podporuje postupný vývoj řešení

•

umožňuje dobré měření postupu

•

nabízí odhad rychlosti dalšího postupu

Týmový model MSF – role Product Management •

6

zastupuje zákazníka vůči týmu - Zastupuje tým vůči zákazníkovi

CHARVAT, Jason. Project Management Methodologies

18

Oblasti činnosti: marketing, přínosy produktu, zastupování zájmů zákazníka, plánování produktu.

Program Management •

řídí celkový proces (termíny, náklady, rozsah, specifikaci)

Oblasti činnosti: řízení projektu, celková architektura řešení, dohlížení na dodržení procesu, administrativa.

Development •

vytváří řešení, které naplňuje očekávání zákazníků a je v souladu se specifikací produktu

Oblasti činnosti: technologické konzultace, implementace architektury a designu, vývoj infrastruktury, vývoj aplikace.

Testing •

vytváří strategii a plány testování

•

spravuje automatický build

•

provádí testy

•

účastní se na řízení kvality produktu

Oblasti činnosti: plánování testů, vytváření testů, vyhodnocování výsledků. User Experience •

zastupuje koncového uživatele vůči týmu

•

zastupuje tým vůči koncovému uživateli

•

účast na definování: o požadavků uživatele o funkcí produktu

•

zodpovědný za ergonomii a použitelnost

Oblasti činnosti: grafický design, ergonomie a použitelnost, speciální požadavky, pro postižené, internacionalizace. •

dokumentace a komunikace

•

školení uživatelů

19

Release Management •

zastupuje provozní oddělení vůči vývojovému týmu

•

zastupuje vývojový tým vůči provoznímu oddělení

•

podpora Beta testování produktu

•

příprava provozního oddělení na provoz aplikace

•

definuje požadavky na provoz aplikace a její důsledky

Oblasti činnosti: infrastruktura a provoz, podpora. Procesní model MSF Envisioning Phase - Vision/Scope Approved (odpovídá Produkt management) Planning Phase – Project Plan Approved (odpovídá Program management) Development Phase – Scope komplete (odpovídá Development, user experience) Stabilising Phase – Release Readiness Approved (odpovídá Testing, Release management) Deploing Phase – Deployment komplete(odpovídá Release Management)

Persony (personas) •

v kontextu vývoje zastupuje uživatele anebo jejich skupinu (podobné „actor“)

•

persona není abstraktní a neosobní „actor“, je to fiktivní osoba

•

popisuje se její chování, návyky, motivace apod., je možné ji ztotožnit s konkrétním člověkem

•

používá se ke stanovení cílů (a z nich pak scénářů)

Seznam scénářů •

pro každou personu se stanoví její cíle, pro každý cíl scénáře nutné k jeho dosažení

•

scénář je cesta uživatelským rozhraním od počátku až do dokončení úlohy

•

při psaní scénářů je vhodné být specifický, ale nezacházet do příliš hlubokých detailů

•

příliš málo scénářů znamená malou flexibilitu plánů

•

příliš mnoho scénářů vede k zahlcení

•

stanovení důležitosti scénáře - priority

•

volitelně - stanovení pracnosti implementace

20

Řízení projektu v MSF •

disciplína, nikoliv role

•

v MSF má každá určité povinnosti s řízením projektu

•

“Manažer projektu” v klasickém smyslu neexistuje, nejblíže k němu má role Program Management

Týmový model není příliš hierarchický manažer lidí zpravidla není přímým členem týmu, rozhoduje případné spory apod. Vytvoření týmového projektu •

•

Na základě šablony procesu: -

MSF for Agile Software Development

-

MSF for Process CMMI Improvement

-

vlastní anebo upravená jiná šablona

Šablona obsahuje: -

typy udržovaných seznamů (work items)

-

položky v těchto seznamech

-

skupiny a jejich oprávnění

-

reporty

-

úvodní obsah projektového portálu (šablony dokumentů apod.)

-

politiku pro check-in

-

integrovanou nápověda metodologie

-

iterace projektu

2. Obecný proces nasazení IT systému 2.1 Definice etap

21

Obrázek 2 - obecný vývojový diagram etap Info autora Námět (příloha A)

Projektová kancelář

Podmíněné zastavení

Předprojektová etapa

Informování autora komunikace s autorem check list (příloha B)

NE (info autora) Majitel projektu

ANO (info o zamítnutých námětech) Projektový výbor

Vedoucí projektového týmu ANO (prirorita, majitel)

NE

Etapa zahájení

Vedoucí projektového týmu sestaví projektový tým (příloha C, příloha D) Zadání projektu (příloha E)

Feasibility study (příloha F) Business case (příloha G)

Podmíněné zastavení

Majitel projektu

Uživatel

NE

ANO Work Breakdown Structure (Stromový diagram)

Matice zodpovědností

Etapa plánování

Activity Network Diagram (Síťový diagram)

Podmíněné zastavení

Analýza rizik

Gantt diagram - Plán operativního řízení projektu, diagram nákladů (příloha H), diagram zdrojů

Uživatel

"Výroba" projektového výstupu

Majitel projektu

NE

ANO

Etapa realizace

Operativní řízení (příloha I)

Podmíněné zastavení

Testování projektového výstupu

Školení uživatelů

Odevzdání projektového výstupu (příloha J)

Uživatel

Majitel projektu

NE ANO

Etapa hodnocení

Hodnotící matice (příloha K)

Hodnocení skupinové dynamiky (příloha L)

Archivace, standardizace

22

2.2 Předprojektová etapa V této etapě probíhá sběr námětů. Náměty jsou elektronickou poštou zasílány do Projektové kanceláře, která vyplní po upřesnění s autorem Checklist. Na jeho základě se rozhoduje, zda je námět vhodný jako téma pro projekt a navrhne se projektovému řídícímu výboru vybraná témata pro spuštění projektu. V případě, že téma není vhodné na projekt, informuje projektová kancelář autora námětu o důvodech a archivuje kompletní dokumentaci k námětu. Pokud projektový řídící výbor povolí pustit projekt do etapy zahájení, stanoví prioritu a rozhodne o majiteli projektu. Majitel projektu jmenuje vedoucího projektu. Výstupem předprojektové etapy je vyplněný Checklist, definovaný majitel projektu, priorita a jmenovaný vedoucí projektu.

2.3 Etapa zahájení Cílem etapy Zahájení projektu je právě stanovit rámec řízení projektu. Etapa obsahuje pouze řídicí činnosti s výjimkou specifikace rozsahu projektu, protože dekompozice tohoto kroku zpravidla obsahuje i výkonné činnosti závislé na typu projektu (např. o projektu vývoje systému zahrnuje i úvodní analytické modely). Specifikace cílů a rozsahu projektu je podmínkou pro návazné kroky, protože bez prvního hrubého vymezení rozsahu projektu nelze uvažovat o jeho plánu, harmonogramu, rozpočtu i potřebných rolích pro splnění cílu projektu. Celý postup etapy Zahájení projektu může být v praxi iterativní, neboť důsledkem specifikace projektu mohou být termíny a náklady, které nejsou pro sponzora projektu přijatelné, což muže vést v další iteraci ke snížení rozsahu projektu. Podobně jako provedení analýzy rizik může vést k doplnění činností, které mají tato rizika snížit, do plánu projektu.

Výstupem etapy Zahájení projektu je Základní dokument projektu (Project Charter) nazývaný také Zpráva o zahájené projektu. Tento dokument je vždy na závěr každé další etapy (kromě poslední) opětovně posuzován a podle potřeby revidován. V etapě Zahájení projektu je třeba definovat hranice projektu, tj. jeho rozsah (co projekt bude a co nebude pokrývat). Rozsah projektu lze uvažovat z dvou hledisek: z hlediska rozsahu zkoumání a z hlediska rozsahu řešení. Nejdříve identifikujeme hlavní cíle a kritické požadavky projektu. Rozsah projektu zpravidla znázorníme pomocí diagramů.

23

Rozsah projektu bývá definován pomocí seznamu požadavků vyšší úrovně. Oprávněnost těchto požadavků může být prověřena pomocí techniky analýzy kritických požadavků. Pro projekt definujeme jeho organizaci, tj. role, které se budou podílet na realizaci projektu. Pro každou roli stanovíme její odpovědnost. Projektová organizace zahrnuje vzájemné vztahy mezi jednotlivými rolemi. Plán celého projektu vychází obvykle z některého procesu, který je k dispozici pro projekty obdobných charakteristik. Definujeme kroky a etapy projektu a závislosti mezi nimi. Dále odhadneme jejich pracnost, určíme potřebu zdrojů (počty pro jednotlivé role) pro jednotlivé kroky, vypracujeme harmonogram projektu a připravíme rozpočet projektu. Podobně, ale na podrobnější úrovni, zpracujeme plán následující etapy projektu. Plán projektu je vytvářen na začátku projektu a pak je vždy aktualizován na konci jeho etap případně pokud dojde k významným změnám. Jedná se o hrubý plán na úrovni etap a kroků často vytvářený bez znalosti konkrétních osob, které se budou na projektu podílet. Naproti tomu plán etapy je podrobný a vytváří se vždy na konci předchozí etapy. Výjimku tvoří plán etapy zahájení projektu, který se tvoří v rámci iniciace projektu. Důležité je zaznamenat jako součást každého plánu předpoklady jeho platnosti. Na úrovni projektu neplánujeme podrobně. Podrobný plán vypracováváme vždy jen pro následující etapu. 7

2.4 Etapa plánování Jsou analyzovány základní požadavky na projekt. Jsou navrhována a hodnocena možná řešení. Jsou zpracovány a vyhodnoceny plány projektu. Po schválení postupu projektu do etapy plánování vytvoří projektový tým metodou brainstormingu stromový diagram (WBS - Work Breakdown Structure), matici zodpovědnosti a síťový diagram. Dále provede analýzu rizik a vytvoří Ganttův diagram s plánem operativního řízení. Do elektronické podoby (MS Project) se práce převádí po vytvoření síťového diagramu. Výstupem plánovací fáze jsou Ganttův diagram s plánem operativního řízení, diagram nákladů a diagram zdrojů.

7

Metodika pro implementaci systémů, Cleverlance

24

2.5 Realizační etapa V etapě realizace se provádějí činnosti, které produkují měřitelné projektové výstupy jako jsou vývoj, testování, dodání, instalace, zkoušení, dokumentace, trénink a zavedení. Řízení realizační etapy se provádí na základě plánu operativního řízení projektu (Ganttův diagram). Vedoucí projektu je povinen podávat zprávy o stavu projektu majiteli projektu v každém stanoveném milníku. Vzor zprávy o stavu projektuje uveden v příloze. Výstupem fáze realizace je předávací protokol k projektovému výstupu.

2.6 Etapa hodnocení Hodnoceni projektů se provádí u všech projektů, které byly zahájeny a to i v případech, kdy byl projekt zastaven v některé z fází projektového řízení. V etapě hodnocení majitel projektu oficiálně akceptuje měřitelné výstupy projektu a jsou formálně zhodnoceny přínosy projektu. Vedoucí projektu vyplňuje hodnotící matici a hodnocení týmové práce. Projektový tým je rozpuštěn, účastníci hodnoceni. Majitel projektu hodnotí vedoucího projektu, vedoucí projektu hodnotí členy projektového týmu. Výstupem etapy hodnocení je zanesení hodnocení projektu do databáze projektů. 8

2.7 Rizika projektu Na začátku projektu je vhodné provést analýzu rizik, která jsou spojená s provedením projektu. Tuto analýzu je žádoucí realizovat v týmu. Včasným stanovením rizik odstraníme možné příčiny vzniku rizikových událostí. Pro analýzu rizik jsou používány zejména nástroje zlepšování kvality jako je brainstorming, PDPC, Ishikawův diagram. Rizika se vztahují k:

8

•

kvalitě produktů

•

termínům

•

nákladům

•

přínosům

Kolektiv, Projektové řízení, Tiscali

25

Prvky řízení rizik: •

analýza (pravděpodobnost, dopady)

•

sledování

•

řízení

•

komunikace

•

dokumentace

Rizika se vztahují k technické oblasti (kvalita vytvořených produktů může být nízká, cíl projektu není splněn), nákladům a plánu. Rostou s komplexností projektu. Jsou spojena s mírou neurčitostí v plánu a předpokladech projektu. Nejdříve se ptáme: Co a proč se může nedařit? Co je z toho pravděpodobné? Jaké jsou následky rizikové události? Potom následují otázky: Co můžeme proti tomu udělat? Kolik to bude stát? Jaké jsou možné kompromisy z hlediska nákladů, přínosů a rizik? Co bychom dělali, kdyby se to už stalo? Možná rizika je třeba nejdříve identifikovat, teprve poté je možné je řídit, to znamená odhadovat pravděpodobnost výskytu rizikové události a její dopady a plánovat akce pro snížení rizika, případně i podmíněné činnosti pro případ, že by riziková událost skutečně nastala. Analýza rizik vede k vytvoření podkladů pro rozhodování. Analýza rizik poskytuje tak vedoucímu projektu podklady k tomu, aby se věnoval největším rizikům. Výsledkem je vytvoření seznamu akcí, které se týkají jednotlivých zjištěných rizik. Tyto akce je třeba integrovat do plánu projektu.

Reakcí na riziko může být: •

naplánování akce, která riziko snižuje, popř. změny v návrhu produktů či projektovém postupu

•

přijetí rizika včetně očekávaných důsledků výskytu rizikové události bez následné akce (u neovlivnitelných rizik není jiná možnost)

•

vytvoření havarijního plánu pro případ, že riziko nastane, s cílem snížit dopad výskytu rizikové události

•

další zkoumání rizika s cílem včasného odhalení symptomů jeho výskytu tak, aby později bylo možné učinit kvalifikované rozhodnutí

26

Sledování spočívá v monitorování stavu jednotlivých rizik a průběhu naplánovaných akcí. Řízení rizik v užším smyslu spočívá v reakcích na zjištěné odchylky od plánu akcí. Je to stejné jako u jiných položek plánu projektu. Otevřená komunikace týkající se rizik je pro úspěch projektu velmi důležitá a musí zahrnovat všechny úrovně projektové organizace, což zahrnuje jak projektový tým tak různé úrovně uživatelů. Management nesmí trestat nositele špatných zpráv, ale spíše podněcovat volný tok informací na všech úrovních i mezi nimi. Riziky se zabýváme v etapě Zahájení projektu a dále v průběhu projektu vždy na konci každé etapy kdy provádíme revizi analýzy rizik. V případě závažných změn je potřeba taky znovu posoudit vlastní analýzu rizik.

3. Techniky řízení projektů 3.1 Metody plánování

3.1.1 WBS - Work Breakdown Structure WBS neboli Work Breakdows Structure znamená dekompozici projektu do jednotlivých činností. WBS slouží k vypracování činností, které musí proběhnout pro to, aby byl splněn cíl projektu. Pro svůj vzhled bývá WBS někdy nazýván stromovým diagramem nebo dendogramem.

WBS se používá k: •

odhalení činitelů, jež přispívají k řešení problému

•

stanovení logické posloupnosti projektových činností tak, aby bylo možno projekt rozebrat do co největších podrobností a jednotlivým činnostem přiřadit zodpovědnosti

•

ze zadaného seznamu činností lze usoudit, zda-li nechybí některé činnosti pro zdárný průběh projektu

•

při rozebírání projektu lze dosáhnout takové hladiny podrobnosti, aby konečné položky byly vhodné pro bezprostřední řešení. Jejich vyřešením postoupíme na

27

úroveň, která není tak podrobně specifikována atd. Tímto způsobem lze postupovat až do vyřešení cíle projektu 9. WBS patří do kategorie "povinných" nástrojů v projektovém řízení. Příklad sestavení WBS z Ishikawova diagramu: Obrázek 3 - WBS z Ishikawova diagramu

9

ŠMÍRA, Miroslav; MATULA, Zdenko, Řízení projektů a projektových týmů

28

Obrázek 4 - WBS z Ishikawova diagramu

Příklad bankovní aplikace, kde je WBS s naplánovanými alokacemi rozdělené podle jednotlivých útvarů: Obrázek 5 - WBS v aplikaci pro řízení nasazování systémů v bance

3.1.2 AND - Activity Network Diagram AND představuje v podstatě metodu síťové analýzy, zjednodušenou na nejnutnější minimum z důvodu snadného použití v manažerské praxi. Metodice síťové analýzy při řízení a časovém plánování projektů je v zahraničí věnována mimořádná pozornost. Dvě základní metody síťové analýzy v současné západní praxi jsou CPM (Critical Path Method 29

- metoda kritické cesty) a PERT (Program Evaluation and Review Technique - metoda pro vyhodnocování a sledování programů). Metody PERT/CPM se používají v případech, kdy jsou jednotlivé plánované kroky dobře definované, mají zřetelné návaznosti a lze u nich spolehlivě rozeznat začátek a konec. Metodiky síťové analýzy poskytují dokonalý přehled o načasování činností v rámci projektu a jsou neocenitelné zejména při sledování rozsáhlých akcí investiční výstavby, náročných oprav atd. Jaké funkce a vlastnosti ale požadujeme od síťové analýzy při řízení projektů? Rozhodně se obejdeme bez množství doplňujících funkcí a pomocných grafů, které obsahuje většina softwarových balíků pro síťovou analýzu. Místo toho je lepší klást větší nároky na to, abychom zdůvodnili nezbytnost každého kroku a každé činnosti. Ty činnosti a kroky, které nemají žádnou "přidanou hodnotu" musíme z plánu vyřadit. Velkou pozornost musíme věnovat otázce, které kroky je možno provádět současně a které na sebe musí navazovat. Tímto způsobem dokážeme celý tok procesu zefektivnit. Při sestavování AND se řídíme následujícími kroky: •

z poslední úrovně dekompozice činností projektu (WBS) převezmeme základní seznam činností projektu a eventuelně ho modifikujeme nebo doplníme

•

každou činnost napíšeme na předem na formátovanou kartičku

•

kartičky nalepíme na svislou plochu za sebou i vedle sebe. K tomu si položíme dvě otázky: -

Kterou činnost musím dokončit, než mohu zahájit tuto?

-

Které činnosti mohu provádět, zatímco provádím tuto?

První otázka identifikuje ty činnosti, jež musí následovat za sebou, druhá otázka ukazuje na ty činnosti, jež mohou probíhat vedle sebe. V průběhu tohoto kroku se možná objeví v plánu "díry", které bude nutno zaplnit, anebo duplicitní činnosti, jež je třeba vyloučit. Až uspořádáme všechny kartičky, pojmenujeme je písmeny abecedy, jež napíšeme vlevo. Konečně pak seřazené kartičky propojíme šipkami tím způsobem, že šipka bude vždy vycházet z kartičky bezprostředně předcházející a směřovat do kartičky bezprostředně následující.

30

Provedeme odhad stanovení doby trvání každé činnosti. Tam, kde si nebudeme jisti nám pomůže jednoduchý empirický vztah t = (a + 4m + b) / 6, kde t = výsledná průměrná doba provádění činnosti a = doba, potřebná k dokončení činnosti, když všechno půjde hladce (optimistický odhad) m = doba, potřebná k dokončení činnosti za normálních podmínek (nejpravděpodobnější doba trvání) b = doba, potřebná k dokončení v případě. že nastanou významné problémy Není dobré dělat diagram příliš složitý a "vědecký". Drobné činnosti, jež mohou vytvářet samostatné větve a jež nejsou pro uskutečnění projektu příliš významné, lze vypustit nebo sloučit s jinými. Některé složitější úkony, které se zpočátku zdají být jednoduché je někdy vhodnější rozdělit na více drobnějších činností. Pomůže to lépe naplánovat čas a odhalit případné mezery, které by se mohly skrývat ve velkých blocích. Activity Network Diagram lze využívat nejen k plánování dosud neuskutečněných projektů, ale i ke znázornění procesů běžně a opakovaně probíhajících. Většina počítačových programů pro síťovou analýzu chrlí množství dodatečných informací, které ve svých důsledcích zanášejí cesty týmové komunikace a odrazují méně zkušené členy týmů. Activity Network Diagram prováděný ručně a v této nejjednodušší podobě je přístupný jakožto užitečná pomůcka všem členům projektových týmů.

31

Obrázek 6 - příklad Activity Network Diagramu

3.1.3 Ganttův diagram Ganttův diagram je přehledným nástrojem pro vytváření harmonogramu projektu včetně kritické cesty. Zároveň nám umožňuje prakticky sledovat a vyhodnocovat průběh realizace projektu. Pro vlastní převedení Mapy Činností do Ganttova diagramu můžeme použít dostupných softwarových prostředků - nejčastěji používanými jsou MS Project nebo Ventura. Pokud nevyužíváme softwarových prostředků, je vhodné provést následující postup: •

vytvoříme velkou pracovní plochu, použít můžeme například flip-chartových papírů s předtištěným rastrem

•

přepíšeme činnosti z WBS do sloupce pod sebe k levému okraji pracovní plochy. Prvá činnost v Mapě činností je zároveň prvá od shora v Gantt diagramu

•

rozhodneme o měřítku diagramu. Nejčastěji používaným jsou dny nebo týdny v závislosti na velikosti projektu

•

vyneseme měřítko na horní okraj pracovní plochy a využijeme při tom předtištěného rastru 32

•

jednotlivé činnosti znázorňujeme jako úsečky, jejichž délka odpovídá počtu časových jednotek. Průběžně při vynášení úseček vynášíme i vzájemné závislosti jednotlivých činností a označíme zdroje, které činnosti provádějí

•

nakonec porovnáme Ganttův diagram s původní WBS a doplníme aktuální data do časové osy Obrázek 7 - Ganttův diagram v aplikaci Microsoft Project

3.1.4 Afinní diagram Skupina nebo tým mohou využívat afinního diagramu ke generování, třídění a ucelení velkého a nepřehledného množství verbálních informací, týkajících se problému. Tyto verbální informace se zpravidla skládají z faktů, zkušeností, názorů a odhadů. Afinní diagram nám pomůže uspořádat tyto informace do přirozených shluků, z nichž vyvstane skrytá struktura zkoumaného problému. Tvorba afinního diagramu je spíše tvůrčím nežli logickým procesem.

33

Problémy, s nimiž se setkáváme ve své praxi mohou tvrdě odolávat navyklým způsobům řešení. Použití afinního diagramu často pomůže řešitelskému týmu se odpoutat od myšlenkových stereotypů. Afinní diagramy povzbuzují tvůrčí přístupy řešení problémů. Použití afinních diagramů je zejména užitečné, jestliže: •

řešený problém je složitý a obtížně uchopitelný

•

jeho řešení si vyžádá spoustu času

•

odolává běžným metodám řešení

•

jeho řešení vyžaduje aktivní zapojení členů řešitelského týmu.

Afinní diagramy naopak nejsou užitečné tam, kde řešený problém je poměrně jednoduchý nebo vyžaduje okamžité řešení. Dříve nežli přistoupíme k vlastní konstrukci afinního diagramu, musíme identifikovat řešený problém a provést výběr členů týmu. Složení týmu bude tedy přirozeně záviset na řešené otázce. Tým by měl být složen ze čtyř až šesti členů, z nichž ne všichni by měli být odborníky v oblasti řešeného procesu. Při konstrukci afinního diagramu se řídíme těmito kroky: •

vybereme moderátora týmu

•

moderátor týmu napíše řešené téma na flip-chart a poskytne skupině čas k tvůrčímu promyšlení problému

•

po individuálním promyšlení lze myšlenku rozvinout a obohatit řízenou diskusí, která může trvat 30 až 45 minut. Slovní informace a podněty zapisuje moderátor na kartičky nebo lepicí papírky přesně tak jak byly vysloveny. Cílem je zachovat podstatu myšlenek.

•

druhou alternativou je, že si členové týmu v průběhu diskuse sami své myšlenky zaznamenávají na kartičky

•

shodne-li se tým, že diskuse je skončena a že všechny verbální informace byly zapsány, rozprostře moderátor kartičky po veliké pracovní ploše tak, jak mu přijdou pod ruku 34

•

všichni členové týmu posunují kartičkami tak, aby utvořili shluky, jež mají vnitřní souvislost. Jeden člen týmu může kartičku posunout k jednomu shluku a další člen týmu ji může posunout zpátky. To se může přihodit i vícekrát po sobě, kartička si však nakonec najde shluk, ve kterém se "zabydlí". Členové týmu pokračují v přesunech tak dlouho, pokud jednotlivé shluky nedávají ucelený smysl. Jakmile kartičky mají své místo končí se a členové týmu spolu začnou hovořit.

•

budeme-li v přeskupování shluků pokračovat příliš dlouho, zůstane jich jen několik a tím se de facto skrytá struktura problému opět zakryje. Pro kartičky, které nelze rozumně umístit do žádné skupiny vytvoříme shluk, nazvaný "různé". Celou tuto činnost je nejlépe provádět mlčky.

•

pokud se tým shodne na tom, že tvorba shluků je již ukončena (zpravidla se jich objeví sedm až deset), vyberou jeho členové z každého shluku tu kartičku která jej charakterizuje a shrnuje v něm obsažené informace. Z této kartičky se pak stává nadpis shluku.

•

pokud není možné nadpis z žádné kartičky takto udělat, členové týmu ji vymyslí

•

moderátor pak přesune kartičky ve vytvořených shlucích a každý shluk ohraničí silnou čarou. Tím vzniká vlastní afinní diagram, který může sloužit týmu jako základ pro diskusi o vzájemných vztazích jednotlivých shluků.

•

struktura problému zpravidla vyvstane na povrch, přečteme-li si kartičky s názvy jednotlivých shluků

Moderátor by měl účastníkům umožnit doplnění dalších kartiček i tehdy, když už jsou shluky hotové. Pohled na ně totiž může vyvolávat další myšlenky a asociace. Názvy shluků musí být co nejužší a nejvýstižnější. Název musí být jen tak široký, aby přesně obsáhl všechny kartičky v něm zahrnuté. Je dobré se vyhnout obecným pojmům jako "zákazníci", "dodavatelé", "komunikace v podniku" atd. Moderátor musí zabránit tomu, aby si některý jednotlivec vytvářel v týmu dominantní postavení. Tomu lze zabránit pečlivou přípravou metodiky. Při pojmenovávání shluků je možné například vyzvat všechny členy týmu, aby na kartičku potichu napsali svůj návrh názvu nebo popsali, co pro ně daný shluk znamená. Všechny kartičky se pak po řadě přečtou a dosáhne se shodě o názvech shluků. 35

3.1.5 PDPC diagram Plánování vytváří v projektových týmech mocnou iluzi, že vše je jaksi "pod kontrolou" a nástroje plánování, jakými je například metoda kritické cesty, k této iluzi jen přispívají. Skutečnost je ovšem taková, že projektový tým dokáže přinejlepším narýsovat trasu, která se zdá být slibná a doufat, že se po cestě nevyskytnou zásadní překážky. Pokud tomu tak bude, je třeba trasu operativně změnit. K tomu nám může napomoci nástroj s názvem PDPC (Process Decision Program Chart). Tento nástroj pomůže týmu dopředu pojmenovat potenciální problémy a pomocí brainstormingu najít možnosti, jak problémům předejít. Prevenci vzniku problémů dáváme samozřejmě přednost. Metodu PDPC ale můžeme použít i tam, kde vznik problému nelze odvrátit. Takové použití znají pracovníci servisů z tzv. troubleshooting guides. Plánování je činnost, která v mnoha lidech vzbuzuje pocity euforie, hraničící se ztrátou soudnosti. V některých podnicích se dokonce stalo zvykem, že se v projektech vytyčují nereálné cíle a nikdo se pak nepozastaví nad tím, že se jich nepodařilo dosáhnout. Vypracování PDPC umožní projektovému týmu pohlédnout na cíl projektu z druhé strany, uvědomit si dopady navrhovaných řešení na práci kolegů z jiných oddělení a vyslovit nahlas všechny pochybnosti. K brainstormingu o možných úskalích projektu a způsobech, jak jim zabránit je vhodné přizvat i členy jiných projektových týmů nebo další zainteresované osoby. Všichni tak lépe porozumí možným dopadům projektu a projektový tým si získá nové spojence. Postup vytvoření: Na jednu stranu pracovní plochy (flip-chart, tabule) umístíme systematický diagram s rozpracovanými kroky projektu. Základní cíl (čeho má být projektem dosaženo) se octne na okraji plochy. Kroky, které směřují k základnímu cíli, pak povedou směrem do středu až do takového stupně podrobnosti, který chceme ochránit před potenciálními problémy. Pokud je včasné a bezchybné dokončení projektu pro firmu životně důležité, bude možná potřeba "ochránit" všechny větve systematického diagramu. Ve většině případů ale není nutné zacházet až do takového stupně podrobnosti. To bude samozřejmě záviset na individuálním posouzení.

36

Brainstormingem se vyhledají možné problémy. Na koncích jednotlivých větví systematicky hledáme všechny možné a pravděpodobné zdroje problémů, které by mohly zabránit úspěšnému završení jednotlivých kroků. Každý takový problém napíšeme na papírek a papírky nalepíme na pracovní plochu a spojíme čarou s výstupem projektového kroku. Může se stát, že členové týmu nebudou schopni sami odhalit všechna možná rizika. V takovém případě se brainstorming může "odročit" do doby, kdy se seženou další podklady nebo budou přizváni další odbornici. Brainstormingem rozpracujeme vhodná protiopatření, přičemž nestačí pouhý výčet. Každé opatření, které má nějakému problému zabránit nebo nějaký problém vyřešit, je třeba posoudit z hlediska jeho přiměřenosti, uskutečnitelnosti, nákladů apod. Vybraná protiopatření zabudujeme do projektu. Každé preventivní či nápravné opatření je naplánováno a odpovědnost za jeho provedení musí být jasně určena.

Obrázek 8 - příklad PDPC záznamu výkonostního problému systému a návrhů řešení

37

Při brainstormingu potenciálních problémů je třeba držet se reality a nevymýšlet si přitom různé absurdní problémy. Může to sice podněcovat tvořivost členů týmu, přesto je ale zbytečné ztrácet čas zkoumáním nerealistických problémů. Brainstorming je nutno dělat v týmu. Občas vedoucí týmů mají někdy sklon "ušetřit čas" tím, že možnosti selhání hledají sami. Brainstorming je ale jedinečný tím, že využívá synergických efektů práce ve skupině. PDPC se používá ke skutečnému zlepšení projektu. Členové projektového týmu mohou být v pokušení využít metody PDPC k přidání další "vaty" k plánovaným časům jednotlivých kroků projektu. To ale není cílem, otevřená komunikace při hledání možných zdrojů obtíží by naopak měla povzbudit ke skutečnému zlepšení projektu a ke zlepšování procesů a měla by členy projektového týmu přesvědčit, aby si na sebe vzali větší díl odpovědnosti za konečný úspěch projektu.

Obrázek 9 - Analýza rizik

38

3.1.6 Mapa procesu Mapa procesu poskytuje obraz funkce procesu uvnitř banky nebo podniku. Pomáhá pochopit jednotlivé "předávky", kdy se informace nebo materiál přesunuje z jednoho organizačního útvaru nebo pracoviště do druhého. Na mapě procesu vidíme: •

účastníky procesu

•

vstupy a konečné výstupy procesu

•

kroky nebo činnosti uvnitř procesu

•

útvary nebo organizace, které dodávají vstupy nebo odebírají výstupy z jednotlivých kroků (pokud nejsou součástí procesu)

Před zpracováním mapy procesu je potřeba: •

určit, kterým vstupem proces začíná a kterým výstupem končí. Zpravidla budou procesy začínat požadavkem klienta a končit jeho uspokojením.

•

najít a pojmenovat činnosti, ze kterých se proces skládá

•

zjistit, kdo se na jednotlivých krocích podílí a kdo je za ně odpovědný

Potom je zapotřebí: •

stanovit pořadí kroků

•

najít pro každý krok vstupy a dodavatele a výstupy a místa jejich určení

Vlastní konstrukce mapy se pak skládá z těchto kroků, mapu procesu na obrázku použijeme jako vzor: •

do sloupce po levé straně seřadíme všechny účastníky procesu

•

činnosti vyneseme do mapy tak, že na vodorovné ose budou seřazeny chronologicky a na svislé ose se budou nacházet v řádce, ve které je útvar, zabezpečující danou činnost 39

•

pokud jsou dvě činnosti prováděny souběžně, je potřeba je zařadit v mapě nad sebe, do jednoho sloupce, činnosti označíme

•

pokud se jedné činnosti účastní více partnerů, seřadíme je do jednoho sloupce.

•

činnosti očíslujeme v chronologickém pořadí, tzn. zleva doprava podle sloupců

•

činnosti spojíme čárami tak, že každá činnost bude mít čáru vstupní a čáru výstupní s výjimkou počátečního vstupu a konečného výstupu

•

nakonec najdeme vstupy a výstupy, ke kterým v průběhu procesu dochází a které leží mimo jeho hranice. Vstupy dáme nad hranice procesu do příslušných sloupců, výstupy pod hranici procesu. Obrázek 10 - příklad mapy procesů

další vstupy

Zákazník

činnost

Oddělení A Oddělení B Oddělení C

činnost činnost Výstup

činnost činnost

další výstupy

3.1.7 Korelační diagram Korelační diagramy mají tu smůlu, že jim pro laika osud nadělil tak složitý název. Jinak by se jistě běžně uplatňovaly v podnikové praxi všude tam, kde chceme zkoumat vzájemný vztah dvou parametrů či proměnných. Zjistíme-li, že jeden parametr je závislý na parametru druhém, vysloveně se nabízí možnost druhý parametr řídit či ovlivňovat změnou parametru prvého.

40

Korelační diagram můžeme sestrojit tehdy, když máme k dispozici údaje o velikosti dvou proměnných v témže okamžiku. Ty potom vyneseme do grafu, kde každý bod představuje dvojici hodnot z jediného měření. U praktických procesů výrobních či podnikatelských, které jsou zatíženy vysokým stupněm proměnlivosti, nám pravděpodobně nevyjde hladká křivka či přímka, ale spíše shluk bodů.

Prodej [ks]

Obrázek 11 - Korelační diagram

C

+ +

+

+

+

+

+

+ ++ + + +

D

A

B

Čas [dny]

Korelační analýza jako jeden ze základních nástrojů zlepšování procesů nepředpokládá matematické zpracování výsledků. Buď je na diagramu závislost na první pohled patrná nebo nikoli. Nebezpečí korelačních diagramů spočívá v jejich nesprávné interpretaci.

3.2 Role, zodpovědnosti a pravomoci Úspěšnost projektu nezávisí ani tak na použitých metodách a nástrojích, jako na lidech, kteří na něm pracují. Je třeba jasně od počátku definovat a sdělit role projektovému týmu tak, aby jeho řešitelé mohli pracovat společně jako tým. Klíčovým faktorem úspěchu je pochopení, jaký význam má určení správných lidí pro každou roli v projektovém týmu. 41

Pro úspěšný průběh projektu je klíčové přiřadit role a odpovědnosti pro jednotlivé účastníky projektového řízení. V projektovém řízení mohou být definovány například následující role: •

Projektový řídící výbor ( Steering Committee)

•

Projektová kancelář

•

Majitel projektu

•

Uživatel projektu

•

Vedoucí projektu

•

Člen projektového týmu

•

Partner projektu

Základní předpoklady, které v rozhodující míře ovlivní vlastní projekt a jeho úspěšnost jsou: •

podpora vedení společnosti a stanovení patřičné priority

•

jmenování a uvolnění kompetentních členů projektového týmu pro projektové práce

3.2.1 Projektový řídící výbor Projektový řídící výbor je strategickým rozhodovacím orgánem v projektovém řízení a během procesu řízení projektu. Jeho odpovědnost zasahuje od uvolňování důležitých zdrojů po prioritizaci zásadních problémů, které mají vliv na průběh projektu. Tvoří jej top management. Odpovědnosti a pravomoci projektového řídícího výboru: •

reviduje a schvaluje procedury platné pro projektové řízení

•

řeší konflikty priorit mezi jednotlivými projekty

•

schvaluje cíle strategických projektů, nastavuje priority, rozsah a plán projektu

•

schvaluje předložené náměty na projekty, rozhoduje o změnách projektu

•

určuje majitele projektu (zpravidla ze svých řad)

42

•

je pravidelně informován vedoucím projektu o jeho průběhu. V případě, že se vyskytnou problémy a jejich řešení není v kompetenci vedoucího projektu, nařizuje provedení příslušných opatření.

•

potvrzuje ukončení etap projektu, schvaluje základní dokumenty projektu

3.2.2 Projektová kancelář Projektová kancelář je subjekt, který metodicky a organizačně podporuje systém projektového řízení, případně chod jednotlivých projektů. Odpovědnosti a pravomoci projektové kanceláře: •

eviduje a vyhodnocuje náměty na projekty

•

komunikuje s předkladateli námětů

•

předkládá náměty na projekty projektovému řídícímu výboru k rozhodnutí, zda bude námět realizován

•

poskytuje metodickou podporu pro projektové vedoucí

•

udržuje databázi projektů

•

připravuje návrhy na aktualizaci metodiky a nástrojů projektového řízení

•

plánuje a koordinuje logistické záležitosti všech porad a zasedání a udržuje projektovou dokumentaci

•

vytváří a distribuuje odkazy na zápisy ze všech porad, které se používají při komunikaci o stavu projektu

•

aktivně sleduje řešení otevřených problémů

3.2.3 Majitel projektu (Business vlastník) Každý projekt má svého majitele. Majitel projektu je jmenován projektovým řídícím výborem zpravidla z řad jeho členů. Odpovědnosti a pravomoci majitele projektu: •

majitel projektu schvaluje projekt, je zodpovědný za vytvoření vhodných podmínek pro zapojení příslušných lidí do projektu a financování projektu po celou dobu

43

životního cyklu projektu. Po celou dobu trvání projekt podporuje a pomáhá překonávat překážky projektu •

rozhoduje o nutnosti zpracovat feasibility study (studie proveditelnosti) nebo business case

•

majitel určuje nebo schvaluje požadavky na projekt s ohledem na potřeby uživatelů výstupů projektu. Je zodpovědný za celkové investice do projektu a za jeho úspěšné dokončení

•

vybírá a jmenuje vedoucího projektu

•

dělá klíčová rozhodnutí na rozhraní jednotlivých etap projektu

•

schvaluje změny projektového plánu nebo zadání

•

reviduje vývoj projektu

•

řeší konflikty mezi projektovým a liniovým řízením

•

rozhoduje ve sporných záležitostech předkládaných vedoucími projektů

•

pro projekt zajišťuje potřebné zdroje

•

sleduje vývoj a organizační změny projektu

3.2.4 Projektový vedoucí (Project manager) Projektový vedoucí je osoba odpovědná za plánování a řízení operativního chodu projektu. Odpovědnosti a pravomoci vedoucího projektu: •

pomáhá majiteli projektu definovat projektové zadáni a zdůvodňovat financování projektu

•

řídí plánování a provádění projektu tak, aby se dosáhlo výstupů definovaných uživatelem a majitelem v předem určených hranicích daných náklady, časem a kvalitou

•

rozvíjí a udržuje projektové plány

•

kontroluje stav projektu a reportuje majiteli projektu zpravidla v předem daných milnících

•

stanovuje, přiřazuje a průběžně kontroluje práce na jednotlivých částech projektu přiřazených členům projektového týmu

•

řídí projektový tým a udržuje kontakty s partnery projektového týmu 44

•

udržuje kontakty s uživatelem projektového výstupu

•

v případě potřeby operativně řeší vzniklé problémy s majitelem projektu případně uživatelem

•

odpovídá za výběr a sestavení projektového týmu, podává návrhy na uvolňování členů projektového týmu

•

odpovídá za aktuálnost svého projektu v projektové databázi

•

vytváří strategie implementace a údržby plánu projektu, definici a průběžné řízení zdrojů projektu

•

poskytuje informace o stavu projektu jak členům řídícího výboru, tak i projektovému týmu

•

vedoucí projektu musí být schopen působit účinně jako člen řídícího výboru a být tímto orgánem plně podporován

•

kontroluje dodržování pravidel při práci na projektu

3.2.5 Projektový tým Odpovědnosti a pravomoci člena projektového týmu: Je zodpovědný za řízení úsilí k zajištění analýzy a dokumentace aktuálních podnikových procesů. Jeho primárním úkolem je pracovat se členy projektového týmu a koncovými uživateli ke splnění následujících cílů: •

vývoj projektového návrhu

•

realizace/kontrola funkčního návrhu

•

testování a dokumentace funkčního návrhu

Člen projektového týmu je osoba odpovědná za určenou část projektových prací. •

podílí se na analýze zadání a koncepci řešení projektu

•

vykonává, případně odpovídá za provedení přidělených projektových úkolů

•

účastní se schůzek projektového týmu

•

plní úlohy podle pokynů vedoucího projektu

45

3.3 Vedení projektových týmů 3.3.1 Komunikace v týmu Původ slova komunikace je z latinského slova communis neboli společný. Zavádění systému znamená komunikaci mezi mnoha různými útvary a lidmi na různých pozicích s různými odbornostmi. V této souvislosti je potřeba zvládnutí komunikace základním kamenem vzhledem k tomu, že projekt jde většinou napříč přes různé bankovní systémy. S vyjadřováním dochází nejčastěji k následujícím chybám: •

neuspořádání si myšlenek před začátkem presentace kde například vysvětlujeme proč je potřeba navýšit rozpočet nebo i když na status meetingu pouze probíráme aktuální stav projektu

•

vyjadřujeme se nepřesně

•

pokud se snažíme dostat do své výpovědi příliš mnoho, působí zmateně a podstata zaniká ve změti většinou nepodstatných informací. Účinnost roste se stručností

•

vkládáme-li do své výpovědi příliš mnoho myšlenek jež nemají často mezi sebou vazbu, je pro posluchače jejich shrnutí příliš obtížné

•

pokud jsme nejistí, hovoříme stále dále aniž bychom odhadli kapacitu vnímání posluchačů

•

při přednášení nevnímáme určité body v odpovědích posluchačů nebo jejich dotazy a proto neodpovídáme na to, co bylo aktuálně řečeno (typický problém našich politiků, i když v tomto případě to je spíš záměr)

•

shazováním či snižováním názorů druhých

•

mlčením, změnou tématu, nedokončováním vět, skákáním do řeči atd.

Velmi důležitou věcí v komunikaci je informování druhých ať už o aktuálním stavu projektu nebo problémech a jejich řešení. 10

10

Kolektiv, Řízení projektů, LBMS

46

3.3.2 Struktura týmu Struktura týmu je tvořena diferencovaným systémem pozic a rolí ve skupině. Struktura většiny skupin je hierarchická, protože pozice v rámci skupiny jsou seřazeny směrem vzhůru podle statusu a moci. Struktura je tudíž dána vztahy mezi členy skupiny a má dvojí hranice: vnější a vnitřní. Vnější hranice oddělují skupinu od ostatních jedinců a do jisté míry i od okolních vlivů. Čím je skupina soudržnější, tím silnější se stává její vnější hranice, tím zřetelněji je oddělena od okolní sociální reality. Vnitřní hranice skupiny tvoří její formální a neformální skladba. To platí i o týmu.

Formální struktura je dána organizací, v jejímž rámci tým vzniká a plní své úkoly. Podle daného organizačního schématu jedinci plní určité role, zaujímají pozice v hierarchii a splňují patřičná očekávání, přičemž jsou realizovány i tendence členů týmu. Podstatnou součástí formální struktury je vedení skupiny. Stabilita struktury do určité míry závisí na stupni formálnosti týmu. Neformální struktura týmu je dána interpersonálními výběry a preferencemi jeho členů. tedy dimenzemi sympatie, antipatie a indiference mezi členy. Podléhá změnám v souvislosti s děním v týmu. Často se nekryje s formální strukturou týmu a tento nesoulad může být zdrojem vnitřních týmových konfliktů.

3.3.3 Pozice a role v týmu Pozice, neboli umístění jedince ve skupině je vlastně skupinou, společenstvím uznávaná kategorie anebo místo v systému společenské klasifikace, v systému společenských funkcí a určuje skupinový status člena skupiny, tedy jeho soubor práv a povinností, jeho společenskou hodnotu a prestiž. Každý člověk zaujímá v životě mnohonásobné pozice a s každou z nich se spojuje jeho role. Sociální role je tedy dynamickou charakteristikou statusu (pozice).

Role v týmu jsou profesní a týmové. Každý tým musí mít správnou skladbu odborných dovedností (toho, co lidi dělají jako odborníci) a správnou skladbu týmových dovedností (toho. jak se lidé chovají, aby přispěli k existenci týmu). Odborné role reprezentují stránku "co", týmové role stránku ,Jako". Jestliže máte analyzován úkol, který před týmem stojí, a stanoveny požadavky na specializované dovednosti (je také důležité zvážit úroveň 47

požadovaných dovedností - seřízení automobilového motoru vyžaduje mechanika, ale úroveň jeho dovedností se bude lišit v závislosti na tom, zda půjde například o vůz rodinný nebo závodní), role v oblasti "co" jsou obyčejně zcela jasné. Méně jasné bývají ovšem role v oblasti "jako". Problém je samozřejmě v tom, že lidé, kteří v týmu musí být kvůli nezbytným specializovaným dovednostem nemusí mít mnoho týmových dovedností. Efektivní tým vytvářejí jednotlivci, kteří mají své vlastní přednosti i slabosti a uměním je složit tým tak, aby byly všechny potencionální slabosti nějak kompenzovány, takže si zachovává celé spektrum předností. To v podstatě znamená vyhýbat se "sebekopírování", zabezpečit, aby v týmu byly zastoupeny určité velice rozdílné povahy, i když se ze začátku nemusí příliš snášet. Vedoucí týmu musí tyto nedostatky rozpoznat a pracoval na tom, aby problémy minimalizoval.

3.3.4 Vedení týmu Řízení týmu zahrnuje procesy, potřebné k co nejefektivnějšímu využití lidí pracujících na projektu. Patří mezi ně všechny zúčastněné strany - sponzoři, zákazníci, partneři, individuální spolupracovníky a ostatní. Profesionální a etické kvality vedoucího jsou pro jakýkoliv typ projektu nesmírně důležitým faktorem. Jeho vlastnosti rozhodují zejména v počátcích vývoje o tom, jak rychle se podaří ustanovit žádoucí vztahy a skupinovou atmosféru. Každý vedoucí týmu má v podstatě tři základní odpovědnosti: •

zajistit splnění úkolu

•

vytvářet a udržovat tým

•

stimulovat a udržovat rozvoj jedinců

3.3.5 Problémy v týmu Každý tým provádí rozhodování a řeší problémy. Každý tým je také v průběhu své činnosti týkající se jeho úkolu, v určitých časových intervalech nucen řešit i své interní problémy, což zvyšuje úroveň napětí, zabírá čas a projevuje se negativně na výkonech týmu. Mezi nejčastěji se vyskytující se problémové skupiny patří nezájem, nerozhodnost a zejména konflikt. Každá z těchto skupin se projevuje určitými symptomy, pomocí nichž je možné 48

definovat určitý problém a stanovit jeho diagnózu. To je základním předpokladem k tomu, aby mohl být příslušný problém konstruktivně řešen, a aby došlo ke snížení napětí v týmu na únosnou hladinu. Mezi obecné symptomy patří: •

členové odvracejí nit diskuze

•

napadání všech návrhů

•

neochota naslouchat druhé

•

členové přicházejí opožděně a často chybějí

•

neschopnost učinit rozhodnutí

•

povrchní příprava schůzek

•

pokud dojde k rozhodnutí, členové se jím neřídí

•

další odpovědnost se přijímá jen zdráhavě 11

4. Proces nasazení IT systému v bance Cílem je definovat základní proces a postupy platné pro vývoj, testování, akceptaci a implementaci aplikačního programového vybavení systému používaného v bance bez ohledu na platformu. Proces definuje jednotlivé kroky při vývoji a implementaci systému jak interními pracovníky banky, tak externími dodavateli. Součástí je dále definice rolí a jejich konkrétních odpovědností v rámci procesu vývoje.

4.1 Fáze přípravy a schválení plánu projektů Proces začíná přípravou požadavku žadatele a končí fází tzv. Baby sitting po implementaci do produkčního prostředí. Příprava a projednání požadavku na úrovni obchodních útvarů, příprava související metodiky a sledování obchodních dopadů souvisejících se zavedením systému nebo změn systému se řeší vnitřním předpisem Vývoj produktů. U projektů je popsán postup plánování projektů z pohledu zajištění kapacit ICT potřebných pro vývoj a realizaci systému.

11

ŠMÍRA, Miroslav; MATULA, Zdenko, Řízení projektů a projektových týmů

49

Každý projekt, který požaduje zdroje útvaru ICT nebo předpokládá, že systém bude vyvíjen externě, musí být řízen v souladu s ustanoveními vnitřních předpisů. Za dodržení všech podmínek odpovídá Projektový manažer. Proces neřeší obchodní stránku, smluvní stránku, cyklus objednávání a fakturace externích vývojových prací. Tyto činnosti probíhají dle pravidel útvaru Centrálního nákupu a logistiky. První činností je příprava požadavků na projekt, za což odpovídá Business architekt. Projekty jsou plánovány ročně s možností čtvrtletních změn. Plán projektů je schválen na příslušném Domain Councilu neboli EXCO výboru a posléze na ASC (Activity Stearing Committee). Žádný projekt nesmí být zahájen bez schválení ASC v rámci plánovacího cyklu. Business architekt vytvoří obchodní zadání tzv. Idea template a po schválení na Domain Councilu (DOC) i Business Case, což je ve své podstatě popis požadovaných funkčností a projedná jej s příslušným Aplikačním manažerem. Nakonec zašle emailem obchodní zadání na pevně stanovenou adresu v termínu určeném harmonogramem přípravy ročního plánu projektů. Administrativní pracovník oddělení Procesů ICT, zaregistruje obchodní zadání v registru požadavků a přidělí mu číslo zakázky, poté zašle obchodní zadání Manažerovi přípravné fáze k dalšímu zpracování, ten určí Business analytika odpovědného za přípravnou fázi projektu. Dalším postupem je vytvoření ročního plánu projektů. Toto má na starost Business analytik, který: •

projedná obchodní zadání s Business architektem

•

navrhne rámcové ICT řešení obchodního zadání

•

připraví odhad nákladů (lidské zdroje a nakupované služby) nutných pro realizaci obchodního zadání

•

zašle odhad nákladů Business architektovi

Jakmile je toto stanoveno předkládá se ke schválení ročního portfolia projektů. Business architekt připraví vyhodnocení přínosů a nákladů navrhovaného řešení a připraví finální

50

dokument ke schválení (tzv. business case), který zašle ke schválení nejprve na DOC a po jeho schválení sekretáři ASC ke schválení na ASC. Na základě schváleného plánu projektů ASC Release manažer připraví release kalendář na další rok. Release kalendář se připravuje na běžný rok a definuje termíny, ve kterých bude nasazení nových systémů nebo změny těchto systémů. Tím končí fáze přípravy a schválení plánu projektů.

4.2 Přípravná fáze projektu Přípravná fáze projektů je povinná pro všechny projekty. Nedílnou součástí přípravné fáze je vypracování pre-study jako podkladu pro plán implementace projektu. Při přípravě prestudy je klíčová účast pracovníků útvaru Business architekta, který projekt požaduje.

Business architekt: •

připraví návrh přípravy pre-study (pre-study charter) obsahující harmonogram, náplň, potřebné lidské zdroje a v případě potřeby náklady na externí dodávky

•

vyžádá v případě potřeby u příslušných Vlastníků zdrojů ICT kapacity pracovníků ostatních útvarů ICT

•

požádá Business architekta o zajištění potřebných zdrojů z obchodního útvaru

•

předloží pre-study charter ke schválení příslušnému Domain councilu (DOC)

Business analytik vypracuje pre-study report jako výstupní dokument pre-study, který bude obsahovat: •

návrh ICT řešení včetně případných variant s informací, zda se jedná o interní nebo externí vývoj

•

požadované ICT kapacity potřebné pro implementaci (zpřesnění odhadu použitého pro přípravu ročního plánu projektu)

•

požadovaný rozpočet na externí dodávky (zpřesnění odhadu použitého pro přípravu ročního plánu projektu)

•

analýzu dopadu na architekturu ICT

•

analýzu bezpečnostních aspektů 51

Klíčové je poté posouzení architektury, kde Aplikační architekt posoudí dopady navrhovaného řešení na ICT architekturu jako celek. V případě nutnosti navrhne případné změny v návrhu řešení, aby řešení bylo v souladu s ICT architekturou. Oddělení provozu a infrastruktury navrhne technické řešení nutné k realizaci. Navrhované řešení posoudí oddělení ICT bezpečnosti, které posoudí zda je navrhované řešení v souladu s požadavky na informační bezpečnost podle platných bezpečnostních politik a standardů banky. Pokud je v rozporu nebo se vyskytnou bezpečnostní rizika navrhne změny v návrhu řešení, v souladu s politikou bezpečnosti ICT. Pro zachování kontinuity mezi přípravnou a realizační fází projektu je důležité zapojení Project managera (Project leadera) již v přípravné fázi. Pro jeho přidělení požádá Business analytik manažera útvaru ICT. Project manager doplňuje či vznáší připomínky při tvorbě pre-study. Jakmile je pre-study vyhotovena Business analytik předloží pre-study report ke schválení pracovnímu výboru architektury (WSC-A: ICT WSC Architektura) z hlediska dopadů do ICT architektury. Po schválení WSC-A dále předloží pre-study report příslušnému DOC ke schválení věcné náplně, to znamená, že navrhované řešení je v souladu s požadovanou funkčností. Po schválení nastává příprava plánu implementační fáze projektu, kterou má na starost Project manager/Project leader. Ten plánuje činnost a sestavuje ICT tým, který bude odpovědný za realizaci. Vypracuje plán realizace ICT řešení projektu jako vstup do Project charteru a to zejména: •

harmonogram ICT implementace

•

potřebné interní zdroje ICT a jejich kapacity pro realizaci projektu

•

potřebné náklady na externí dodávky pro realizaci projektu

•

globální plán testů

52

Členy týmu musí být následující role: •

IT analytik

•

návrhář aplikace

•

programátor

•

IT test koordinátor

•

zástupce útvaru ICT - Provoz a inženýring

V případě potřeby jsou členy projektového týmu Certifikátor aplikačního programového vybavení, Aplikační architekt a Analytik bezpečnosti ICT. Project manager poté projedná plán realizace ICT řešení projektu s ICT Test koordinátorem případně projektovým manažerem za business. Vlastníky ICT zdrojů požádá o vyčlenění potřebných interních ICT kapacit pro realizaci projektu. Termín nasazení systému do produkčního prostředí ověří v rámci release kalendáře s Koordinátorem domény, popř. s Release manažerem. Fázi realizace projektu schvaluje řídící výbor projektu/programu na základě předloženého Project charteru. Pokud je schválen zašle informaci o schválení projektu všem členům projektového týmu.

4.3 Zajištění externí dodávky systému IT Jsou chvíle, kdy je výhodnější vývoj systému svěřit externímu dodavateli. Dodávky systému od externích dodavatelů zajišťuje po věcné stránce výhradně útvar ICT. Žádný jiný útvar není oprávněn jednat s dodavatelem systému o věcné stránce. ICT Project manager požádá kontaktního pracovníka externího dodavatele o zajištění nabídky na řešení dodávky. Pokud je nutné, poskytne zástupci externího dodavatele nezbytné kontakty pro případné upřesnění požadavků. ICT Project manager posoudí nabídku externího dodavatele z věcného hlediska a požádá v případě nejasností nebo v případě, kdy řešení neodpovídá požadované funkčnosti (nebo pokud není v souladu s ICT architekturou) odpovědného pracovníka externího dodavatele o upřesnění, popř. změnu nabídky řešení. Nakonec zašle odsouhlasenou nabídku na definovanou emailovou adresu. 53

Administrativní pracovník procesů ICT zašle nabídky na externí vývoj útvaru Centrálního nákupu a logistiky k projednání ceny.

Nakonec nabídku externího dodavatele schvaluje výbor Budget committee (tzv. BUCO).

4.4 Funkční analýza a návrh řešení

Pokud není analýza zadána jako dodávka od externího dodavatele koordinuje Project manager přípravu analýzy požadavků na funkčnost a návrh technického řešení, které připravuje útvar Provozu a inženýringu. Analýze předchází funkční specifikace, kterou má na starost IT analytik. Funkční specifikace je výstupem z IT analýzy a definuje, jaké funkčnosti má řešení pokrývat. Analýza by měla obsahovat: •

rekapitulaci všech požadavků

•

popis požadovaných funkčností v jednotlivých aplikacích a vazby mezi systémy

•

požadavky na datový model včetně požadovaného zabezpečení dat

•

požadavky a návrhy řešení obrazovek

•

požadavky a návrhy řešení výstupů

•

požadavky a návrh řešení uživatelských oprávnění

•

vazby na další aplikace a systémy

•

případnou vazbu na CDS zejména v případě, že dochází ke změně datové struktury u některých systémů

•

metodikem přístupových oprávnění (útvar ICT – zákaznická podpora) přidělení stávajících nebo zřízení nových rolí uživatelů dle katalogu přístupových oprávnění ITIM, což je systém pro řízení a správu uživatelských rolí.

Žadatel o implementaci systému odsouhlasí, že obsah funkční specifikace je ve shodě s jeho požadavky na funkcionalitu systému. Osobně doporučuji písemné potvrzení souhlasu s funkční specifikací. Tento krok je možné vypustit u jednodušších žádostí 54

o aplikační programové vybavení nebo změnového požadavku, kdy je funkční specifikace dostatečně připravená v rámci schvalování žádosti.

4.5 Příprava první verze testovacího plánu Následuje příprava první verze testovacího plánu. Testování probíhá podle testovací metodiky založené na tzv. V-modelu jako na doporučované metodě. Tento model stanoví postup při přípravě testovacího plánu, testovacích scénářů a následně postupy pro provedení testů. Vodopádový model - postup: specifikace požadavků - analýza - návrh - implementacetestování - zavedení - údržba. Různé typy testů jsou odvozeny od odpovídajících fází návrhu, je požadavek trasovatelnosti shora dolů v levé části modelu.

Problémy vodopádového modelu •

model předpokládá, že se všechny požadavky specifikují na začátku projektu

•

iterace jsou možné jen v rámci jedné fáze, případně je možné se vrátit k předchozí fázi

•

není zpětná vazba od zákazníka

•

pozdní integrace systému, ke které dochází až po naprogramování všech modulů

55

Obrázek 12 - V-model

Akceptační testování

Analýza požadavků

Návrh systému

Systémové testování

Integrační testování

Návrh architektury

Jednotkové testování

Návrh jednotek

IMPLEMENTACE

IT analytik zpracuje první verzi testovacího plánu pro funkční-FET, integrační a akceptační testy podle platné testovací metodiky v závislosti na funkční specifikaci. Testovací plán musí obsahovat: •

obsahovou náplň testů včetně pokynů pro testování jednotlivých funkčností

•

navržený harmonogram testů s ohledem na plán realizace

•

požadavky na testovací prostředí

•

souvislosti s ostatními platformami

•

požadované testování dávkových funkcí, ETL procesů, zpracování konců dne atd.

•

požadované testování v produkčním prostředí

IT analytik dále projedná návrh testovacího plánu s IT test koordinátorem, který provede na základě obdržených informací naplánování testů nad jednotlivými platformami a navrhne rozsah a termín provedení zátěžových testů. Následně lze přistoupit k vypracování technického návrhu řešení. Za toto zodpovídá Návrhář systému, přičemž technický návrh řešení by měl obsahovat: 56

•

fyzický datový model

•

technický návrh interfaců a komunikace

•

technické řešení požadavků na bezpečnost včetně přístupových oprávnění a přístupu k datům

•

odkazy na platné standardy a doporučení v rámci jednotlivých vývojových domén

Návrhář systému dále projedná: •

s Analytikem bezpečnosti ICT zda je návrh řešení v souladu s požadavky na informační bezpečnost podle platných bezpečnostních politik a standardů banky

•

s Aplikačním architektem případné dopady navrženého řešení na ICT architekturu v případě, že výsledné řešení se liší od řešení doporučeného v pre-study

•

s Architektem ICT infrastruktury případné dopady navrženého řešení na ICT infrastrukturu v případě, že výsledné řešení se liší od řešení doporučeného v prestudy

Nakonec navrhne scénáře pro integrační testy v případě, že se bude provádět integrační testování.

4.6 Testování kvality IT Project manager rozhodne zda bude provedeno integrační testování. Rozhodnutí je provedeno na základě charakteru a složitosti změny systému a dostupnosti integračního testovacího prostředí. Integrační testování se provádí ve speciálním prostředí v rámci vývoje před odesláním změny systému do Modelové banky. Je zaměřeno zejména na ověření komunikace s ostatními aplikacemi. V případě, že speciální integrační testovací prostředí není k dispozici, je možno provést integrační testování v rámci akceptačního testovacího prostředí. Tato skutečnost musí být uvedena v testovacím plánu a projednána s Release manažerem (aby nedošlo ke kolizi s ostatními aktivitami) a zároveň odsouhlasena IT test koordinátorem. Termíny pro přesun změny do Modelové banku budou tuto skutečnost zohledňovat.Jedná se o činnost, která není povinná pro všechny změny aplikace. O jeho provedení rozhoduje IT koordinátor podle charakteru změny.

57

Programátor provede integrační testování ve spolupráci s a Návrhářem aplikace na základě rozhodnutí IT Project managera. V případě, že se integrační testování provádí v prostředí Modelové banky, spolupracuje s IT Test koordinátorem. Po úspěšném ukončení integračních testů je aplikace předána do Modelové banky. Programátor odsouhlasí přesun vyvinuté změny včetně povinné dokumentace do Modelové banky k Akceptačnímu testování. Povinnou dokumentaci pro předání do Modelové banky tvoří: •

průvodka změnového řízení (formulář pro jednotlivé platformy ve správě Modelové banky)

•

instalační pokyny včetně postupu pro případné odinstalování

•

testovací plán včetně pokynů pro testování a testovacích scénářů

•

uživatelská příručka

•

informace o souvisejících změnových řízeních na ostatních platformách

Nepovinná dokumentace: •

provozní dokumentace, kterou tvoří operátorská příručka a administrátorská příručka

•

požadavky na nastavení, parametrizaci a autorizaci v testovacím prostředí

V případě chybějící povinné dokumentace, popř. jakékoliv její části, je instalace pozdržena do doby, dokud dokumentace není kompletně dodána. Přesun do Modelové banky musí proběhnout u jednotlivých změn nejméně jeden pracovní den, u velkých projektů 3-5 dní před plánovanou instalací do testovacího prostředí. V případě, že se jedná o urgentní požadavek, který má být instalován v termínu kratším, musí požadavek na instalaci potvrdit Release manažer. V případě, že je změna urgentní, musí být takto označena. V případě externího vývoje autorizační autorita odsouhlasí přesun externě vyvinutého systému do Modelové banky k Akceptačnímu testování a to u takového systému, kde je v bance k dispozici vývojové prostředí, do kterého je možno systém implementovat. Způsob přesunu do vývojového prostředí musí být stanoven ve smlouvě s dodavatelem. 58

V případě, že banka vývojové prostředí nemá k dispozici, autorizace v bance neprobíhá. Základní testování probíhá u dodavatele. Aplikace je poté spolu s veškerou povinnou dokumentací zaslána přímo do Modelové banky s tím, že IT Test koordinátor musí být o předání informován. Způsob předání a komunikace musí být definována ve smlouvě s dodavatelem. Instalační pokyny připravené externím dodavatelem musí rovněž obsahovat scénář pro zpětné odinstalování aplikace. Odpovědný pracovník Modelové banky připraví dle požadavku před zahájením testování testovací prostředí pro akceptační testy v souladu s navrženým testovacím plánem. Provede požadovaná nastavení (např. parametrizaci a autorizaci) v testovacím prostředí a zavede aplikaci do evidence. Instalaci provede zástupce útvaru Provoz a inženýring (ISO) nebo programátor na základě jeho pokynů nebo on sám. Dále informuje aplikačního manažera nejpozději následující pracovní den po ukončení instalace o instalaci systému do akceptačního testovacího prostředí a odsouhlasí s ním testovací plán včetně termínů testování. Aplikační manažer definuje testery pro provedení testů příslušného nasazeného systému nebo požadavku na plánovanou údržbu, případně zajistí zřízení přístupových oprávnění pro testery do testovacího systému v souladu s předpisy o přidělování přístupových oprávnění do IT systémů. Tím je systém předán do akceptačních testů. Akceptační testování - Tester aplikace provádí akceptační testování systému či změnového požadavku na základě testovacích pokynů. Archivuje dokumentaci o testování minimálně po dobu 3 let pro účely vnitřního či vnějšího auditu. Akceptační testování se provádí primárně v Modelové bance, ale mohou nastat případy, kdy nelze otestovat z důvodu, že například není k dispozici odpovídající prostředí pro provedení průkazných akceptačních testů. Jedná se o nestandardní postup, který lze používat pouze v mimořádných případech, kdy: •

je třeba provést testy na plném rozsahu dat, který nelze zajistit v prostředí Modelové banky

•

testování výkonnostních parametrů v případech, kdy není v Modelové bance prostředí, které by mohlo prokázat výkonnostní parametry v produkčním provozu

59

Vzhledem k tomu, že takovéto testování v produkčním prostředí není standardní musí se dodržet tyto podmínky: •

musí být schváleno B-1 manažerem útvaru ICT

•

nesmí se měnit zdrojová data aplikace (např. databáze dat načtených z transakčních systémů)

•

testování nesmí ovlivnit produkční využití aplikace, je doporučeno provádět testování mimo provozní hodiny banky

•

testování musí být zahrnuto v testovacím plánu včetně seznamu pracovníků, kteří budou testování provádět

•

musí předcházet testování funkčnosti ve vývojovém a integračním prostředí a v prostředí modelové banky

•

musí být k dispozici záloha dat před testováním pro případ havárie

V průběhu akceptačního testování Tester zapisuje případný výskyt chyby do Mercury Quality Centra (MQC) což je systém evidence chyb. Toto hlášení musí obsahovat čas výskytu chyby, popis chyby, prioritu (závažnost) chyby a popis činnosti, při které chyba nastala. Doporučuji v takovémto případě pro usnadnění hledání chyby vkládat i snímek obrazovky. Chyba je předána k vyřešení programátorovi nebo externímu dodavateli. Ten opraví chybu v programu a připraví opravný balíček pro Modelovou banku obsahující modul s odstraněnou chybou. Balík musí obsahovat průvodku změnového řízení, popis opravené chyby, návaznost na předešlé změny a instalační pokyny. Ostatní dokumentace se posílá pouze v případě, že je změněna.

60

Obrázek 13 - MQC systém evidence chyb

IT Test koordinátor zajistí otestování opravy, parametrizaci prostředí, nahrání do testovacího prostředí a výzvu aplikačnímu manažerovi k otestování. Testování provádí tester, zároveň testování musí prokázat, že chyba byla nejen odstraněna, ale i že oprava chyby neměla vliv na další funkčnost aplikace. Jakmile chybovost poklesne na nebo pod úroveň počtu chyb definovaných na počátku projektu je aplikace prohlášena za připravenou na přechod do stádia testů v pilotním provozu. Kritériem bývá většinou pevně stanovený počet chyb včetně jejich urgentnosti, například 0 chyb kategorie Vysoká, maximálně 2 chyby kategorie Střední a maximálně 10 chyb kategorie Nízká. Aplikační manažer potvrdí akceptaci funkčnosti systému na základě výsledů testování a podepisuje akceptační protokol. Akceptační protokol je možno potvrdit elektronicky, je však nutné zajistit, aby schválení aplikačním manažerem bylo jednoznačně prokazatelné a dokladovatelné. V případě, že aplikační manažer neakceptuje nasazení, je povinen na akceptačním protokolu uvést důvody, proč systému neakceptuje.

61

4.7 Pilotní provoz, Baby sitting Pilotní provoz musí být součástí plánu realizace změny systému nebo aplikace (typicky součástí Project charteru). K nasazení do pilotního provozu může dojít pouze po řádném akceptačním testování a podpisu akceptačního protokolu. Pro pilotní provoz, popř. fázi Baby sittingu musí mít programátor a IT Test koordinátor rezervovanou kapacitu v plánu aktivit. Fáze pilotního provozu je fází provozní, kde je sice aplikace nasazena v produkčním prostředí, nicméně není vypublikována pro všechny případné uživatele systému (tzn. klienty banky), ale pouze pro zaměstnance banky. Případné chyby při ostrém používání jsou zaměstnanci hlášeny na HelpDesk. Zde je chyba zaregistrována a odeslána k řešení. Hlášení o chybě musí obsahovat kategorii chyby dle metodiky HelpDesku, popis situace, kdy chyba nastala, popis chybného chování systému a chybová hlášení, pokud se objeví. V případě urgentní chyby se chyba posílá přímo určenému pracovníku v rámci pohotovosti.

Obrázek 14 - proces předávání chyb

62

V případě výskytu chyby programátor provede ve spolupráci s IT analytikem analýzu chybového stavu na základě popisu chyby. Poté opraví chybu v aplikaci, provede základní, popř. integrační testy opravy a připraví instalační sadu pro přesun do Modelové banky spolu s průvodkou změnového řízení a aktualizovanou provozní dokumentací (pokud následkem opravy chyby dochází k její změně). Průvodka změnového řízení musí obsahovat číslo incidentu přidělené HelpDeskem. Poté IT test koordinátor zkontroluje úplnost dokumentace a zajistí přípravu testovacího prostředí a instalaci opravy do testovacího prostředí Modelové banky včetně všech požadovaných nastavení. Nakonec vyzve aplikačního manažera k provedení akceptačních testů. Tester systému provede otestování opravy na základě pokynů pro testování. Pokyny musí obsahovat nejen testování samotné opravy chyby, ale i testování dalších funkčností, které mohou být odstraněním chyby ovlivněny. Jedná se především o to, že nasazená oprava mohla ovlivnit ostatní funkčnosti systému. Aplikační manažer akceptuje opravu chyby potvrzením akceptačního protokolu. V případě, že změna není akceptována, je povinen na akceptačním protokolu uvést důvody, proč změnu neakceptuje. Po vyjádření Aplikačního manažera Modelová banka zajistí posun změny do útvaru Provoz a inženýring (ISO) k provedení instalace do produkčního prostředí v souladu s ostatními platnými předpisy. Opravy urgentních chyb se instalují do produkčního prostředí v nejbližším možném termínu. Opravy chyb s nižší prioritou se instalují u platforem se zavedeným release managementem v termínu nejbližšího release, u ostatních platforem v následujícím plánovaném termínu pro nasazování změn do produkčního prostředí. V případě, že je požadováno nasazení změny mimo pravidelný termín nasazování změn, musí instalaci do produkčního prostředí povolit Release manažer po dohodě s ředitelem útvaru Provoz a inženýring (ISO) nebo jím pověřeným zástupcem. Aplikační manažer potvrdí ukončení pilotního provozu, popř. fáze Baby sittingu v termínu daném implementačním plánem, který je uveden v Project charteru. V případě, že je z vážných důvodů nutno pilotní fázi nebo fázi Baby sittingu prodloužit, připraví požadavek na změnu projektu nebo žádost o posun termínu nasazení systému do provozu. V opačném 63

případě je systém vypublikován i pro veřejné adresy a aplikace je dostupná pro všechny klienty banky. Předáním aplikace na klienty končí proces vývoje systému v bance.

5. Srovnání teorie a praxe Pro smysluplnou diskusi nad rozdíly mezi teoretickými doporučeními a praktickým nasazením IT systémů v bance je nutné si problematiku rozdělit do dvou kroků: •

porovnání obecných metodik projektového řízení a vnitřní bankovní metodiky řízení změn a nasazení IT systémů

•

diskusi nad tím, proč a jak se liší nebo neliší skutečný projekt nasazení IT systému od schválené a závazné interní metodiky řízení nasazování a změn IT systémů

Podle mého názoru nelze tyto dva kroky bez další diskuse sloučit do kroku jednoho, jedná se totiž o zcela jinou problematiku, i když na sebe navazující.

Ve své praxi jsem se setkal s projektem EBPP (Electronics Billing Presentment and Payment) na kterém bych chtěl poukázat na některé nedostatky, které se objevily nedodržováním standardizovaných postupů. Pokud chceme srovnat využití klasických projektových metodik (PMI, IPMA,…), plánování, postupů a doporučení s faktickou metodikou pro nasazení a změny, vývoj IT systémů v bance je bezpodmínečně nutné si uvědomit následující skutečnosti: •

Každá obecná metodika je ve skutečnosti zobecněným koncentrátem mnoha přístupů, typů projektů, best practices ve zcela různých oblastech (TELCO, finančnictví, utility, FMCG, stavebnictví,…). Jedná se tedy o zobecnění a koncentraci z mnoha vertikál.

•

Obecné metodiky popisují všechny typů projektů (marketingové projekty, projekt stavby metra, vývoj nového automobilu, menšinové sociální projekty, IT projekty…). Je nepochybné, že každý typ projektu má svá určitá specika. IT projekt je jeden z typů projektů. 64

•

IT projekt (nasazení nebo změna IT systémů) je v drtivé většině případů pouze určitým, subprojektem výsledného projektu. Úspěšnost IT subprojektu, zejména například ve finančnictví, je z hlediska celkového výsledku rozhodujícím aspektem (je to dáno výraznou závislostí této vertikály na IT systémech). IT projekt není pro IT, je službou objednávanou a placenou businessem.

Srovnání bankovní metodiky nasazení IT systémů a obecné projektové metodiky. Metodika popsaná v odstavci „Proces nasazení IT systému v bance“, je právě tou „očištěnou“ esencí od jiných vertikál a jiných typů projektů. Z pohledu IT, plánování kapacit, prací, architektury a jejích změn nelze k metodice jako takové mít závažnější připomínky. Z tohoto úhlu pohledu je metodika jistě vhodná a praxí prověřená, ale určitě není zcela bez chyb. Pokud však pokud se však podíváme šířeji ze vztahu zadavatele (business) a dodavatele (IT), lze mít k metodice velmi mnoho závažných výhrad: •

Základní výhradou je to, že po dobu realizační fáze projektu nedostatečně propojuje tyto dva základní subjekty. V rámci ukončení počáteční (plánovací) fáze dochází fakticky k uzamknutí vlastností a parametrů nasazovaného systému a systém se vyvíjí zcela v IT režii, bez interakce se zákazníkem.

•

Metodika klade extrémní nároky na analytickou přípravu v počáteční fázi, kde business analytik musí velice pečlivě vést přípravu Pre-study. Důvodem je, že v této fázi se uzavírají takřka všechny důležité parametry technického řešení. Koncem této fáze je schválená Pre-study a schválená a zafixovaná architektura. Chyba, případně funkční změna těchto parametrů je následně velice obtížně korigovatelná.

•

Důsledkem předchozích dvou bodů jsou značné nároky na faktickou znalost IT problematiky role business analytik. Tyto nároky lze nazvat i extrémními vzhledem k tomu, že musí obsáhnout veškeré bankou používané technologie, systémy a jejich architekturu.

•

Metodikou je konzervováno původního řešení. Existuje pouze minimální možnost změny řešení: původní nebo žádné. Faktické řízení změny tedy neexistuje.

65

Z úhlu druhého kroku, tj. diskusí nad tím, jak se existující a platná metodika nasazování IT systémů v bance uplatňuje v konkrétní praxi, je možné konstatovat následující: •

Metodika je vcelku aktivně využívána (neobcházena) a úspěšně se vyrovnává s projekty nasazení nových a změn systémů, které jsou v bance známy. Tím jsou myšleny všechny projekty pracující nad již existující infrastrukturou, případně systémy, které je nějak rozšiřují.

•

Metodika bohužel nijak zvlášť významně nepodporuje nasazení systémů a technologií v bance dosud nevyužívaných. Tato vlastnost je umocněna klíčovým postavením role Business analytik a jeho znalostí o bankovních systémech. Příkladem je projekt EBPP (elektronická fakturace), kdy v počáteční fázi byla nedostatečně analyzována dosud v bance nepoužívaná technologie kvalifikovaných

časových

razítek.

Důsledkem

byly

vynucené

změny

infrastruktury, změnová řízení a tím i prodloužení projektu. •

Chyby v IT architektuře řešení a jejich náprava (rigidnost původního řešení). V témže projektu (EBPP) se vyskytla zásadní chyba v návrhu architektury řešení, kdy zasílání notifikačních SMS správy pro klienty banky, měly být sice směrováno na dostatečně dimenzované servery, ale ty neměly implementovány všechny funkce, které byly pro zasílání SMS zpráv z EBPP potřebné. Na problém se přišlo až v rámci testování. V rámci implementace bylo nutné tyto funkce doprogramovat a systém upravit. Důsledkem bylo zpoždění projektu a vícenáklady.

•

Konkrétním příkladem nedodržování platné metodiky v tomtéž projektu (EBPP) byl problém bezpečného způsobu přenosu dávek od billerů do banky. V původním návrhu základního funkcionálního modelu EBPP byla navržena metoda přenosu dávek pomocí SFTP protokolu autentizovaného pomocí bankou generovaných uživatelských jmen a billerem generovaných přístupových certifikátů. Takto byla schválena Pre-study, zpracována analýza a v rámci jejího schvalování byla tato metoda z ne zcela jasných příčin rozporována (použití

66

kvalifikovaných certifikátů, generování jména, hesla pro billery, atd.), úplně změněna na protokol FTPS, aby se posléze ustálila na původním SFTP s bankou generovanými uživatelskými jmény a hesly. Toto ovšem vedlo k dalšímu zdržení vinou nutnosti znovu opakovaně tyto změny schvalovat přes příslušné komise.

67

Závěry a doporučení Znalost a faktické dodržování základních ustanovení a smyslu některé z obecných metodik projektového řízení je nezbytnou podmínkou pro úspěšné nasazení nebo změnu IT systému v bance. Tyto obecné metodiky jsou pro použití v IT a ve finančnictví navíc doplněny o některé oborové metodiky (ITIL, COBIT, BASELII, apod.) a modifikovány konkrétním prostředím dané banky. Takto vznikne dobrá, zcela konkrétní metodika, kterou lze s úspěchem využívat. Je nutné si ale uvědomit, že vhodná metodika je nutnou, nicméně ne dostačující podmínkou pro úspěšný projekt. Další podmínkou pro úspěšné završení projektu je kreativní používání metodiky, což ale neznamená její obcházení. Třetí zásadní podmínkou je tzv. lidský faktor, kde motivace, zkušenost a spolupráce členů projektového týmů, včetně projektového manažera, je tím, co rozhoduje o konečném výsledku zda nasazený systém uspokojí všechny potřeby, kvůli kterým byl realizován. Velmi zde záleží i na tzv. senioritě projektového managera a na jeho profesních znalostech. Tato práce byla pro mě přínosem, protože jsem si uvědomil některé aspekty, na které se v praxi zapomíná a teoreticky jsem si mohl ujasnit celý proces implementace systému od jeho počátku až po jeho finální nasazení do produkčního prostředí.

68

Seznam použité literatury 1. Cobit Stearing Committee. Cobit Framework, Second edition. Information Systems Audit and Control Foundation, April 1998. ISBN 0-9629440-4-1 2. CHARVAT, Jason. Project Management Methodologies: Selecting, Implementing and Supporting Metodologies and Processes for Project. John Wiley & Sons, 2003. ISBN 0471221783 3. KOLEKTIV. Řízení projektů. LBMS, 2004 4. KOLEKTIV. Tvorba a hodnocení smluv v oblasti outsourcingu IS/IT. První vydání. ČSSI, červen 2001. ISBN 80-245-0181-3 5. KOLEKTIV. Projektové řízení. Tiscali, s.r.o. 2005 6. KRŮTA, Vladimír. Procesy pro kvalitnější správu IT služeb. Praha: Business World. IDG Czech a.s., listopad 2006. ISSN 1213-1709 7. Metodika pro implementaci systémů, Cleverlance, a.s., dostupný dne 14.1.2009 z URL: https://confluence.cleverlance.com/confluence/display/metodiky/Home 8. Přednášky z předmětu „Systémová metodologie". Přednášející Buchalcevová, Alena. 2009 9. ŠMÍRA, Miroslav; MATULA, Zdenko. Řízení projektů a projektových týmů. Interquality, s.r.o., 2002 10. WASCHKE, Marvin. Nechte ITIL pracovat za sebe. Praha: Business World. IDG Czech a.s., listopad 2006. ISSN 1213-1709 11. Wikipedie, Information Technology Infrastructure Library, dostupný dne 17.2.2009 z URL: http://cs.wikipedia.org/wiki/Information_Technology_Infrastructure_Library 12. Wikipedie, Control Objectives for Information and related Technology (COBIT), dostupný dne 27.2.2009 z URL: http://en.wikipedia.org/wiki/COBIT

69

Seznam obrázků Obrázek 1 - schéma ITIL ..................................................................................................... 11 Obrázek 2 - obecný vývojový diagram etap ........................................................................ 22 Obrázek 3 - WBS z Ishikawova diagramu .......................................................................... 28 Obrázek 4 - WBS z Ishikawova diagramu .......................................................................... 29 Obrázek 5 - WBS v aplikaci pro řízení nasazování systémů v bance ................................. 29 Obrázek 6 - příklad Activity Network Diagramu ................................................................ 32 Obrázek 7 - Ganttův diagram v aplikaci Microsoft Project................................................. 33 Obrázek 8 - příklad PDPC záznamu výkonostního problému systému a návrhů řešení .... 37 Obrázek 9 - Analýza rizik.................................................................................................... 38 Obrázek 10 - příklad mapy procesů..................................................................................... 40 Obrázek 11 - Korelační diagram ......................................................................................... 41 Obrázek 12 - V-model ......................................................................................................... 56 Obrázek 13 - MQC systém evidence chyb .......................................................................... 61 Obrázek 14 - proces předávání chyb ................................................................................... 62 Obrázek 15 - vzor Project charteru ...................................................................................... 76

70

Použité zkratky a terminologie A. Role

Definice

Administrativní pracovník procesy ICT Analytik bezpečnosti ICT

Pracovník útvaru ICT. Zajišťuje nezbytnou administrativu spojenou s realizací změny systémů. Posuzuje ICT řešení z hlediska bezpečnosti. Odpovídá za správnou definici bezpečnostních podmínek aplikace.

Aplikační architekt

Posuzuje změnu systému z hlediska aplikační architektury informačních systémů. Odpovídá za posouzení požadavku z hlediska architektury.

Aplikační manažer

Odpovídá za definování funkčnosti SW aplikace vč. bezpečnostních parametrů a katalogu UT, schvaluje její implementaci, koordinuje její vývoj a správu na straně uživatele, je kontaktní osobou pro ICT správce aplikace, předkládá IT development request.

Architekt ICT infrastruktury

Navrhuje technické řešení infrastruktury ICT. Odpovídá za technické řešení ICT infrastruktury v rámci projektů a za dodržování platných standardů architektury ICT infrastruktury. Řídí přípravnou část projektů na stran ICT, je odpovědný za rámcový návrh řešení ICT části projektu a za přípravu pre-study

Business analytik

Business architekt

Certifikátor systému Data steward

IT analytik

Transformuje strategii domény do obchodní a procesní architektury (cíle, funkce, procesy, priority pro přidělení zdrojů); koordinuje činnost produktových, procesních a aplikačních manažerů a vazbu na ICT; definuje obchodní specifikaci produktu. Pracovník útvaru ISO provádějící certifikaci aplikace do systému AKEP. Pracovník útvaru MIS, popř. útvaru aplikačního manažera, provádějící parametrizaci aplikace v produkčním prostředí. Odpovídá za správné nastavení parametrů v produkční aplikaci. Pracovník útvaru ICT, který provádí IT analýzu požadavku na změnu. připravuje funkční specifikaci jako zadání pro programování. Odpovídá za přípravu funkční specifikace a vytvoření uživatelské příručky. Připravuje testovací plán a testovací scénáře.

IT koordinátor

Koordinuje realizaci změny systému v rámci ICT v oblasti projektů. Je kontaktní osobou v ICT pro žadatele. Odpovídá za koordinaci ICT realizace požadavku a za komunikaci v rámci útvarů ISD ICT.

IT test koordinátor

Pracovník útvaru Modelová banka, který organizuje a řídí akceptační testování. Odpovídá za přípravu testovacího prostředí v Modelové bance, za koordinaci a vyhodnocení akceptačních testů a testovacího procesu. Odpovídá rovněž za dodržování platné metodiky testování.

71

Kontaktní pracovník externího dodavatele

Pracovník pověřený jednáním s dodavatelskou firmou o podmínkách externího vývoje. Pro každého dodavatele je jmenován pouze jeden kontaktní pracovník. Odpovídá za komunikaci s externím dodavatelem.

Koordinátor domény

Řídí release v rámci jedné domény, tj. jedné aplikace, popř. sady vzájemně souvisejících aplikací. Rozhoduje, do kterého release bude změna systému zařazena v rámci jeho domény.

Koordinátor zakázky

Programátor nebo analytik odpovědný za vývoj a implementaci žádosti systému v rámci plánované údržby. Pracovník na pozici B-2 manažer útvaru Provoz a inženýring. Schvaluje spolu s release manažerem nasazení mimořádných změnových řízení do produkčního prostředí mimo pravidelné termíny.

Manažer provozu IT

Manažer přípravné fáze

Řídí přípravnou fázi projektů. Odpovídá za přípravu odhadů nákladů ICT při přípravě ročního plánu projektů. Řídí WSC Architecture.

Návrhář aplikace

Programátor popř. IT analytik, který provádí technický návrh aplikace - datová struktura, vnitřní struktura aplikace, rozhraní, výstupy.

Project manager

Plánuje a řídí dodávku systému jako celku.

Programátor

Pracovník útvaru ICT, který programuje změnu systému. Odpovídá za tvorbu programu dle standardů platných v ICT a za přípravu provozní dokumentace. Plánuje, řídí a koordinuje releasy v jednotlivých doménách a zajišťuje koordinaci mezi jednotlivými doménami, které jsou zařazeny do režimu release managementu. Připravuje release kalendář - tj. roční plán releasů.

Release manažer

Sekretář MSC

Správce aplikace

Tester systému

Pracovník útvaru ICT zajišťující přípravu agendy MSC. Odpovídá za předložení požadavků k rozhodnutí MSC. Pracovník provozu IT zajišťující instalaci a údržbu aplikace v provozu. Odpovídá za chod a údržbu aplikace v provozu a řídí řešení nestandardních stavů. Vypracovává havarijní plán při selhání systému. Zástupce útvaru aplikačního manažera provádějící akceptační testování. Není oprávněn podepsat akceptační protokol. Odpovídá za provedení testu dle testovacího plánu.

Uživatel systému

Cílový uživatel systému, které je předmětem změny

Vlastník zdrojů ICT

Vedoucí útvaru ICT na řídící úrovni B-2, v jehož útvaru je změna systému realizována. Rozhoduje o vyčlenění lidských zdrojů na konkrétní aktivitu. Odpovídá za plánování lidských zdrojů. Zástupce útvaru, který žádá o změnu systému. Žadatelem může být manažer minimálně na úrovni B-2. Odpovídá za správné zadání. K dalšímu projednávání požadavku může pověřit referenta svého útvaru.

Žadatel systému

72

B. Pojem

Definice

Baby sitting

Fáze stabilizace a odstraňování chyb po implementaci změny systému v produkčním prostředí. Při baby sitting je (narozdíl od pilotního provozu) aplikace funkční na všech cílových pracovištích a jsou obsluhováni všichni klienti.

Funkční specifikace

Dokument připravený na základě procesní analýzy požadavku na změnu systému, který slouží jako podklad pro programování požadované funkčnosti.

Integrační testování

Testování ve speciálním prostředí ve vývoji k ověření funkčnosti aplikace ve spolupráci s ostatními systémy IT.

Neplánovaná údržba

Opravy chyb aplikací bez dodání nové funkčnosti, podpora uživatelů. Modul systému předávaný k akceptačního testování. je Modelovou bankou evidován jako jedno samostatné změnové řízení. Řešení požadavku na vývoj systému je řešen jedním nebo více pakety (opravami).

Paket

Plánovaná údržba

Vývoj funkčnosti stávající aplikace v rozsahu do 40 člověkodnů bez změny architektury ICT systémů. Jako výjimku lze považovat vývoj v rozsahu do 200 člověkodnů v případě, že jde o rozvoj funkčnosti jedné aplikace bez vlivu na architerkturu. Tyto případy je však nutno posuzovat individuálně.

Porada o řízení rizik

Porada, kterou svolává v případě potřeby B-2 manažer útvaru Provoz a inženýring (ISO). Porada posuzuje rizika nasazení změny systému do produkčního prostředí. Účastníci schůzky jsou: a) vedoucí útvaru Provoz a inženýring; b) IT Project manager; c) IT test koordinátor; d) Release manažer; e) žadatel (projektový manažer); f) aplikační manažer (na pozvání. Rozhodující hlas má vedoucí útvaru Provoz a inženýring.

Posouzení aplikační architektury Release

Dokument posuzující vliv navrhované změny systému na architekturu IT systémů. Sada změn systému dodávaná do testovacího a produkčního prostředí v jednom předem definovaném termínu Položka v rámci plánu investic ISD. Může být použit se na neplánované investiční výdaje na vývoj systému u externích dodavatelů pouze v případě nedostatku vnitřních zdrojů ISD nebo při neplánovaných ad hoc zakázkách a projektech.

SW Emergency rozpočet

73

Urgentní požadavek na systém

Požadavek na změnu systému rozsahu realizace max. 5 člověkodnů kapacity v rámci ISD, u kterého by při dodržení všech kroků procesu a pravidelných termínů implementace mohlo dojít k prodlení s negativním dopadem. Jedná se zejména o: Nařízené změny nebo hlášení ze strany ČNB, KCP, FM a ostatních orgánů - Řešení nesprávných obchodních nebo vnitřních procesů banky Požadavky vnitřního nebo externího auditu na sestavy

WSC Architektura

Pracovní výbor řízení architektury ICT

Základní testování

První testování funkčnosti ve výjovém prostředí bez integrace s dalšími systémy.

C. Seznam použitých zkratek AAA Posouzení aplikační architektury AND Activity Network Diagram ASC Řídící výbor aktivit (Activity Steering Committee). Výbor schvalující roční plán projektů a rozpočet vynaložený na vývoj systému. Beta1 Systém nebo aplikace ve stádiu zkušební verze BUCO

Budget Committee

CPM

Critical Path Method - metoda kritické cesty

DOC EXCO

Výbor domény (Domain council) - schvaluje věcnou náplň vývoje systému v obchodní doméně. Execution Committee

IT

Information technology

MSC

MSF

Řídící výbor údržby (Maintenance Steering Committee). Schvaluje požadavky na plánovanou údržbu v dané oblasti. Bere na vědomí informace o neplánované údržbě v jeho oblasti. Microsoft Solutions Framework

PDPC

Process Decision Program Chart

PERT

Program Evaluation and Review Technique

RC

Release Candidate

RTM

Release To Manufacture

WBS

Work Breakdows Structure

74

WSC-A

Working Stearing Committee - Architecture

75

Přílohy Příloha č.1 Obrázek 15 - vzor Project charteru

76

Příloha č.2

77

Příloha č.2

78

Příloha č.2

79