Využití projektového řízení při implementaci IS/ICT v podniku

Transkript

1 Mendelova zemědělská a lesnická univerzita Provozně ekonomická fakulta Využití projektového řízení při implementaci IS/ICT v podniku Bakalářská práce Vedoucí práce: Doc. Ing. Arnošt Motyčka, CSc. Zpracoval: Daniel Holec Brno 2008

2 Využití projektového řízení při implementaci IS/ICT v podniku 2

3 Využití projektového řízení při implementaci IS/ICT v podniku 3 Čestné prohlášení Prohlašuji, že jsem bakalářskou práci vytvořil samostatně pod vedením svého vedoucího bakalářské práce a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal. V Brně dne 15. prosince 2008

4 Využití projektového řízení při implementaci IS/ICT v podniku 4 Poděkování Rád bych touto cestou poděkoval Doc. Ing. Arnoštu Motyčkovi, CSc. za podporu, konzultace a odbornou pomoc při řešení dotazů a problémů, které jsem při zpracování mé bakalářské práce řešil.

5 Využití projektového řízení při implementaci IS/ICT v podniku 5 Abstrakt Holec, D. Využití projektového řízení při implementaci IS/ICT v podniku. Bakalářská práce. Brno, Bakalářská práce se zabývá využitím projektového řízení při implementaci projektů IS/ICT v podniku. Popisuje základní principy projektového řízení, organizační struktury projektu, modely životního cyklu projektu, nástroje a procesy projektového řízení. Bakalářská práce současně doprovází všechny uvedené nástroje a procesy projektového řízení šablonami jednotlivých dokumentů, které jsou používány a které jsou součástí projektové dokumentace projektu. Klíčová slova Projektové řízení, projekt, implementace IS/ICT, plánování projektů, projektová dokumentace Abstract Holec, D. Project Management in Implementation of IS/ICT in a company. Bachelor s work. Brno, The bachelor s work is concerning with Project Management in implementation of projects IS/ICT in a company. It is describing basic principles of Project Management, organizing structures of project, models of life cycle of project, Project Management instruments and processes. The bachelor s work is also accompanying all described instruments and processes of project management by patterns of single documents, that are used and that are part of project documentation. Keywords Project Management, project, implementation IS/ICT, project planning, project documentation

6 Využití projektového řízení při implementaci IS/ICT v podniku 6 Obsah 1 Úvod a cíl práce Úvod Cíl práce Současný stav Definice projektového managementu Projekt Definice projektu Produkt projektu Harmonogram projektu Rozpočet projektu Okolí projektu Organizace projektu Funkční organizační struktura Projektová organizační struktura Maticová organizační struktura Modely životního cyklu projektu Vodopádový model Spirálový model Síťový model Procesy projektu IS/ICT Výběr dodavatele projektu IS/ICT Inicializace a zahájení projektu Plánování projektu Plánování harmonogramu projektu Plánování zdrojů projektu Plánování rozpočtu projektu Plánování rizik a rezerv projektu Plánování komunikace projektu Realizace a koordinace projektu Monitorování a kontrola projektu Uzavření projektu Metodické standardy projektového řízení Vlastní práce Inicializace a zahájení projektu Cíle projektu Zakládající dokument projektu Definice produktu projektu Komunikace při inicializace a zahájení projektu Plánování projektu Časový plán projektu (harmonogram projektu) Plán zdrojů projektu... 42

7 Využití projektového řízení při implementaci IS/ICT v podniku Plán nákladů projektu Plán řízení rizik projektu Plán komunikace projektu Realizace a koordinace projektu IS/ICT Monitorování a kontrola projektu IS/ICT Kontrola produktu projektu Kontrola harmonogramu projektu Kontrola nákladů projektu Kontrola rizik projektu Kontrola kvality projektu Uzavření projektu Závěrečná akceptace projektu Uzavření projektu Závěr a diskuse Literatura Použité zdroje Doporučená literatura Přílohy A Zakládající dokument projektu B Dokument START projektu C Harmonogram projektu D Kalendář prací zdrojů projektu E Plán nákladů projektu... 73

8 Využití projektového řízení při implementaci IS/ICT v podniku 8 1 Úvod a cíl práce 1.1 Úvod Už v dobách starověkých egyptských pyramid bylo možné se setkat s prvopočátky projektového řízení, kdy tyto složité stavby vznikaly koordinací obrovského množství pracovních sil, materiálu a technologických postupů stavby. V současné době narůstá význam projektového řízení vzhledem k rychle probíhajícím změnám v prostředí podniků. Současný vývoj je charakterizován zkracováním životního cyklu produktů a častými změnami produktů a procesů ve všech odvětvích průmyslu. Dalšími důvody dokazující narůstající význam projektového řízení je silná konkurence v podnikatelském prostředí, velký rozvoj znalostí, zvyšující se orientace na zákazníka atd. Principy projektového řízení jsou aplikovatelné v jakékoliv oblasti průmyslu a jsou v dnešní době často ve všech podnicích v určité míře využívány. Každý projekt je svým způsobem jedinečný, i když určitou podobnost mezi projekty najít můžeme. Projekty implementací informačních systémů a informačních a komunikačních technologií (IS/ICT) jsou v určitých parametrech podobné a je možné se zamyslet nad metodikou projektového řízení pro podporu implementace projektů IS/ICT. Neúspěšnost implementace projektů IS/ICT je v dnešní době relativně velká a cílem každého projektového manažera je eliminace všech rizik projektu a jeho úspěšné dokončení. Metodika implementace projektu IS/ICT v podniku je pro projektové manažery nezbytnou částí projektového řízení a umožňuje: postupovat při implementaci projektu definovaným postupem, eliminovat obvyklé chyby projektu, projekt efektivně plánovat, řídit, kontrolovat a vyhodnocovat, v průběhu projektu efektivně komunikovat, dokončit projekt ve stanovených termínech, dokončit projekt v minimálních odchylkách od plánovaných nákladů. 1.2 Cíl práce Cílem této práce vytvořit metodiku projektového řízení implementace projektu IS/ICT v podniku. Bude vytvořena metodika pro podporu řízení projektu IS/ICT v podniku, kdy budou popsány jednotlivé procesy projektového řízení a v rámci každého procesu všechny probíhající činnosti. Celý průběh projektu bude popsán včetně požadovaných výstupů, které budou součástí komplexní projektové dokumentace projektu. Metodika řízení projektů IS/ICT v podniku by měla být podporou manažerům projektů při projektovém řízení implementací projektů IS/ICT a měla by být využitelná jak pro menší, tak i pro větší projekty implementace IS/ICT. Projektové řízení implementací projektů IS/ICT bude prezentováno prostřednictvím výstupů z aplikace pro podporu projektového řízení Microsoft Project V této aplikaci proběhne průběh konkrétného projektu implementace IS/ICT v podniku Lesaffre Česko, a.s. popisovaného v části Vlastní práce.

9 Využití projektového řízení při implementaci IS/ICT v podniku 9 2 Současný stav Hlavním zdrojem informací při zpracovávání práce byla odborná literatura popisující projektový management a všechny jeho související oblasti. Citovaná a použitá literatura je uvedena v závěru práce v kapitole Literatura. K tématu projektového řízení existuje řada výborných titulů. Svým rozsahem zřejmě největším zdrojem ucelených informací k projektovému řízení je kniha Projektový management (Svozilová, 2006). Kniha mimo obecně vysvětlujících témat projektového řízení popisuje i související oblasti, které se úzce vážou k projektovému řízení, např. vedení týmů, motivace týmové spolupráce, komunikace, apod. Výbornou knihou je Řízení projektů (Rosenau, 2000) a svým obsahem témat je srovnatelná s knihou Projektový management (Svozilová, 2006). Přes menší rozsah jednotlivých kapitol je kniha hodně prakticky orientována a na konci každé kapitoly autor zobrazuje její praktické využití. Dalším použitým zdrojem je kniha Řízení projektů informačních systémů (Doucek, 2006), která je věnována právě projektovému řízení v oblasti projektů informačních systémů a informačních a komunikačních systémů. Jde o specializovaný pohled na projektové řízení právě v této oblasti. Samotné členění publikace vychází nejprve z celkového pohledu na informatiku jako součásti řízení firmy, popisuje vlastní řízení informatiky a její význam při řízení projektů IS/ICT, a poté podrobně vysvětluje metodiku projektového řízení, její tvorbu a význam při řízení projektů IS/ICT. Pro obecnější pochopení modelování projektů je přínosné studium pramenů oblasti grafů a matematických modelů pro řízení projektů. Mezi srozumitelně napsané a snadno pochopitelné patří skripta Mendelovy zemědělské a lesnické univerzity v Brně Ekonomicko-matematické metody (Holoubek, 2006). Skripta České zemědělské univerzity v Praze Projektové řízení základy a matematické metody (Langerová a Šubrt, 2004). Další skripta Systémová podpora projektů (Langrová a Šubrt, 2003) jsou rovněž velmi dobrým zdrojem teoretických informací oblasti grafů a matematického modelování projektů, navíc jsou podrobnější a doplněny o stručný pohled na využití nástrojů projektového řízení v aplikaci Microsoft Project. Mezi další tituly popisující obecné principy projektového řízení, průběh projektu, základy využití aplikace Microsoft Project pro řízení projektů, ale i související základy teorie vycházející z oblasti grafů a matematického modelování projektů, patří knihy Projektový management (Němec, 2002) a Řízení projektů (Fiala, 2002). Skupinou pramenů, kterou jsou rovněž nezbytné pro projektové řízení projektů informačních systémů a informačních a komunikačních systémů jsou knihy popisující práci s aplikací Microsoft Project, která patří mezi často používané nástroje pro podporu projektového řízení. Knihy Vytváříme projekty v programu Microsoft Project 2000 (Hyndrák, 2000) a Řídíme projekty s Microsoft Project 2002 (Kališ, 2002) také patří mezi mnou studované tituly s touto tématikou.

10 Využití projektového řízení při implementaci IS/ICT v podniku Definice projektového managementu Za zakladatele projektového managementu (projektového řízení) je považován Henry L. Gantt. Na základě analýzy pracovních postupů v průmyslové výrobě vynalezl kolem roku 1900 známý Ganttův diagram, který je v současné době považován za nejpoužívanější formu prezentace projektových modelů. Zásadní změna ve vývoji nových metod, nástrojů a technik nastala v padesátých až šedesátých letech, kdy byly vyvinuty nové metody řízení projektů CPM (Critical Patch Method), metoda PERT (Program Evaluation and Review Technique) či metoda PDM (Precedence Diagram Method). Projekty se začaly prezentovat pomocí síťových diagramů, které byly uzlově nebo hranově ohodnoceny. V sedmdesátých letech došlo k rozšíření řízení projektů do dalších odvětví průmyslu, kde nacházelo své nové uplatnění. Od osmdesátých let je projektové řízení vnímáno jako prostor tvořený rovinami času, nákladů a rozsahu. Parametry tohoto prostoru působily i na organizační strukturu projektu. S příchodem výpočetní techniky bylo řízení projektů podporováno softwarově a znamenalo zásadní zvýšení jeho efektivity. Od devadesátých let dochází k přechodu od řízení projektů k projektovému řízení a tímto k vyššímu uvědomení si důležitosti zákazníka, potřeby stálého zlepšování, intenzívnější týmové spolupráce a potřeby řízení se zohledněním životního cyklu projektu. Vzniká komplexní projektová technika TQM (Total Quality Management). 1 Toto období je současně charakterizováno nástupem dalších inovativních postupů v rámci projektového řízení, které jsou využívány i v dnešní době. Patří mezi ně: 2 měření nákladů životního cyklu projektu, řízení změn, které se stává součástí projektového řízení, řízení rizik, které jsou nyní analyzovány a následně řízeny, outsourcing projektového řízení, kdy je projektové řízení realizováno jiným subjektem, než dodavatelem projektu, globalizace, v rámci které dochází k tvorbě mezinárodních týmů, apod. Pojem Projektový management má širší význam a vedle managementu jednotlivých projektů zahrnuje i jejich organizování a koordinování. Může být definován jako plánování, organizování a řízení činností a jejich zdrojů v rámci uceleného projektu za respektování časových, zdrojových a nákladových omezení (obvykle s cílem dosažení maximálního ekonomického efektu) 3. Podle předního světového teoretika projektového managementu profesora Harolda Kerznera je projektový management definován jako souhrn aktivit spočívající v plánování, organizování, řízení a kontrole zdrojů projektu s relativně krátkodobým 1 FIALA, Petr. Řízení projektů. První vydání, Praha, Ediční oddělení VŠE Praha, 2002, ISBN Kapitola 1.1, Historie řízení projektů, s DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN Kapitola 7.1, Historický pohled, s ŠUBRT, Tomáš, LANGROVÁ, Pavlína. Systémová podpora projektů. První vydání, Praha, Česká zemědělská univerzita v Praze, 2003, ISBN Kapitola 2.1, Projektové řízení, s. 115.

11 Využití projektového řízení při implementaci IS/ICT v podniku 11 cílem, který byl stanoven pro realizaci specifických cílů a záměrů 4. Existuje řada dalších definic projektového managementu, které mají ve skutečnosti podobnou podstatu: projekt je určité krátkodobě vynaložené úsilí s využitím znalostí a metod, jehož účelem je transformace materiálních či nemateriálních zdrojů na soubor předmětů a služeb tak, aby bylo dosaženo stanovených cílů a došlo k jejich akceptaci zákazníkem projektu. 2.2 Projekt Definice projektu Projekt je nejdůležitějším prvkem projektového řízení. Jedna z mnoha definic projektu je definice profesora Kerznera. Projekt je jakýkoliv sled jedinečných aktivit a úkolů, který má: dán specifický cíl, který má být jeho realizací splněn, definován datum zahájení a konce ukončení, stanoven rámec čerpání zdrojů potřebných pro jeho realizaci. 4 Tato definice obsahuje tři hlavní charakteristiky tři základny projektového managementu, které definují: čas je limitní při plánování sledu aktivit projektu, dostupnost zdrojů jsou přiděleny projektu a jsou průběžně čerpány, náklady jsou finančním dopadem užití zdrojů v čase. Obr. 1: Základny projektového managementu 5 Z výše uvedené definice vyplývá dočasnost projektu. Začátek a konec projektu nemusí být definován pouze přesnými daty zahájení a ukončení, ale také datem 4 KERZNER, Harold. Project Management, A Systems Approach to Planning, Scheduling, and Controlling, Sixth Edition, New York, Willey & Sons, KERZNER, Harold. Project Management, A Systems Approach to Planning, Scheduling, and Controlling, Sixth Edition, New York, Willey & Sons, 1998

12 Využití projektového řízení při implementaci IS/ICT v podniku 12 zahájení a definicí naplnění cílů projektu. Pro úspěšné dokončení projektu je nutná rovnováha prostoru, který je určen třemi základnami projektového managementu. V případě nerovnováhy dochází k překročení plánovaných nákladů projektu, zpoždění ukončení projektu, překročení plánovaných zdrojů projektu a k vzájemným kombinacím těchto dopadů Produkt projektu Cílem projektu je vytvoření určitého definovaného výsledku produktu projektu (předmětu projektu). Produktem projektu je tedy výstup projektu (předmět, služba či jejich kombinace), který má být realizací projektu vytvořen a který uspokojí očekávání zákazníka projektu. Produkt projektu je svým způsobem unikátní a jedinečný, a to i v případě opakovanosti projektu, při kterém se projeví aspekt podobnosti produktu projektu Harmonogram projektu Jak je výše uvedeno, projekt je definován svým datem zahájení a ukončení. Rozdíl těchto dat definuje čas potřebný pro realizaci projektu. Časový plán realizace projektu je nazýván harmonogramem projektu a je jedním z výstupů plánování projektu. Každý projekt je současně realizován v postupných na sebe navazujících krocích. Z procesního hlediska není projekt jediných procesem, ale soustavou po sobě jdoucích procesů. Čas potřebný pro realizaci procesů projektu je možno rozdělit do pěti hlavních skupin 6 : zahájení, plánování, řízení a koordinace, monitorování a kontrola, uzavření. Jednotlivé skupiny procesů jsou podrobně popsány v následujících kapitolách Rozpočet projektu Každý projekt má stanoven limit čerpání nákladů rozpočet projektu. Rozpočet projektu je dalším výstupem plánování projektu. Tyto plánované náklady jsou při monitorování a kontrole v průběhu realizace projektu srovnávány se skutečnými náklady projektu Okolí projektu Každý projekt je realizován v určitém prostředí okolí projektu. Mezi projektem a jeho okolím existují vzájemné vazby. Okolí projektu tvoří sociální a kulturní prostředí (chování, zvyky a rozhodování účastníků projektu), politická situace (zákonné prostředí), hospodářské a tržní prostředí a specifické prostředí dané geografickými a geologickými podmínkami, ochranou životního prostředí apod. Do projektu jsou zapojeny jednotlivé zájmové skupiny, kterými jsou jak jednotlivci, tak i organizace. Jejich zájmy jsou ovlivněny realizací projektu a dosažením stanovených cílů projektu. 6 SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 3.2, Hlavní skupiny procesů projektového managementu, s. 62.

13 Využití projektového řízení při implementaci IS/ICT v podniku 13 Mezi tyto zájmové skupiny projektu patří: 7 Dodavatel projektu každý projekt má svého dodavatele, který projekt realizuje, poskytuje potřebné zdroje a know-how potřebné k dosažení stanovených cílů projektu. Představitelé dodavatele projektu jsou manažer projektu, členové projektového týmu a subdodavatelé. Zákazník projektu každý projekt má svého zákazníka, pro kterého je projekt realizován. Obvykle jde o budoucího uživatele produktu projektu. Představitelé zákazníka projektu jsou sponzor projektu, investor nebo vlastník podniku (objednává realizaci projektu) a uživatelé budoucího produktu projektu. Ostatní skupiny s vlivem na projekt zastupitelské úřady, konkurence, veřejnost apod. Role manažera projektu je nejdůležitější rolí v projektu. Manažer projektu je osoba odpovědná za splnění cílů projektu. Řídí celý projekt od tvorby projektového plánu, přes koordinaci úkolů, finalizaci a předání výstupů projektu zákazníkovi až po administrativní uzavření projektu. Manažer projektu: 8 má odpovědnost za projekt jako celek, komunikuje se všemi úrovněmi organizační struktury projektu, plánuje, organizuje a koordinuje projekt, vede, řídí, monitoruje a kontroluje projekt, odpovídá za výběr projektového týmu, jedná s managementem o potřebách zdrojů, má dostatečné pravomoci, podává zprávy o postupu vzhledem k plánu projektu, analyzuje a řeší problémy společně s projektovým týmem, Hlavním výkonným článkem projektu je projektový tým. Projektový tým je skupinou osob, která realizuje jednotlivé úkoly projektu. Každý úkol je definován zadáním, požadovaným výsledkem, časovou náročností řešení a termínem řešení. Nutnou podmínkou úspěšné realizace projektu je efektivní a kvalitní projektový tým, ve kterém musí být dodrženy určité zásady: 7 přesné pochopení stanovených cílů projektu, motivace všech členů týmu, demokratická komunikace v týmu, dostatečné pravomoci členů projektového týmu, atmosféra důvěry, nasazení, rozhodnosti v týmu, průběžná informovanost o stavu projektu, efektivní plánování, koordinace, monitorování a kontrola práce všech členů týmu, týmová analýza problémů a jejich řešení. 7 VYTLAČIL, Dalibor. Manažerské informační systémy 30: projektové řízení a řízení projektů. První vydání, Praha, České vysoké učení technické v Praze, 2001, ISBN Kapitola 1.6, Zájmové skupiny, s FIALA, Petr. Řízení projektů. První vydání, Praha, Ediční oddělení VŠE Praha, 2002, ISBN Kapitola 1.3, Zájmové subjekty, s. 15.

14 Využití projektového řízení při implementaci IS/ICT v podniku Organizace projektu Úspěšný a efektivně řízený projekt nemůže být bez jeho organizace. Existují různé organizační formy, které organizace používají k uspořádání svých vnitřních vztahů z hlediska podřízenosti a nadřízenosti. Mezi ty hlavní patří funkční, projektová a maticová organizační struktura Funkční organizační struktura Funkční organizační struktura je charakterizována rozdělením pracovníků do jednotlivých skupin, oddělení či útvarů podle profesního zaměření. Toto má pozitivní vliv na odbornou úroveň každé skupiny. Na druhé straně se stává, že mezi jednotlivými skupinami existují komunikační bariéry a jediným řídícím centrem projektu je vrchol organizační struktury, tj. generální ředitel. Současně specializace jednotlivých skupin způsobuje izolaci od jiných skupin, se kterými je nutno v rámci projektu spolupracovat. Proto je funkční organizační struktura vhodná pro řízení projektu pouze v případě, že všechny zdroje projektu jsou z jediné skupiny Projektová organizační struktura Tato organizační struktura eliminuje nevýhody funkční organizační struktury. Dochází k přesunu jednotlivých zdrojů z jejich profesních skupin do projektové skupiny řízené manažerem projektu. V rámci projektu je využito obvyklé liniové řízení s přesně definovanými pravomocemi. Projekt je vždy časově ohraničen a právě nejistota členů projektového týmu vzhledem k jejich uplatnění po skončení projektu je pravděpodobně jedinou nevýhodou této organizační struktury. Projektová organizační struktura je vhodná pro rozsáhlé a dlouhodobé projekty Maticová organizační struktura Maticová organizační struktura je smíšenou formou z obou výše uvedených forem, tj. funkční a projektové. Dochází k uplatnění liniového řízení v rámci projektu, kdy jsou odborní pracovníci rozděleni do skupin podle odborné specializace. Současně odborné útvary zodpovídají za odborný a kvalifikační růst pracovníků a zajištění tak potřebné kvality pracovníků projektu. Dle Rosenaua (2000, 171) Maticová forma je pravděpodobně nejlepší volbou, jestliže máte mnoho projektů. Hlavním nedostatkem maticové organizace je, že vyžaduje jeden řídící útvar navíc (tj. útvar projektového managementu); takže je obvykle pro malé organizace příliš drahá. 9 ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN Kapitola 12, Jak organizovat projekt, s

15 Využití projektového řízení při implementaci IS/ICT v podniku Modely životního cyklu projektu V případech, kdy je možné problémy strukturovaně definovat, je nejefektivnějším způsobem jejich řešení podrobně je popsat, na základě tohoto popisu sestavit jejich model a řešení nových stavů těchto problémů modelově vyzkoušet. Modelový přístup umožňuje různé pohledy na výsledný produkt projektu a poskytuje jeho vizuální kontrolu. Podle Doucka (2006, 67) Modelem životního cyklu projektu rozumíme formalizovaný popis činností a aktivit, kde jsou definovány vazby mezi nimi a je dána časová posloupnost jejich plnění. Tento přístup našel v projektech IS/ICT široké uplatnění. Pro modelování produktů projektu jsou nejčastěji používané Data Flow Diagramy (DFD), ERA diagramy, návrhy systému apod. Modelový přístup je využíván i pro podporu projektového řízení, kdy jsou pro operativní řízení projektů používány modely s podporou softwarových nástrojů, např. CASE nástroje, Microsoft Project apod. Hlavním rysem modelování projektů IS/ICT je jejich opakovatelnost. Aby byl jakýkoliv proces návrhu, tvorby a implementace informačního systému (IS) opakovatelný, musí být nejprve popsán, zdokumentován a podle této dokumentace také řízen. Model životního cyklu je definován svým začátkem, hierarchickou strukturou jeho částí a svým koncem. Ve stručnosti popisuji tři základní modely životního cyklu projektu a jejich výhody a nevýhody. Jedná se o modely: 10 vodopádový, spirálový, síťový. Existují další modely životního cyklu projektu, např. Fontánový model, model Optimálního životního cyklu, Inkrementální model a řada matematických modelů, které ale z důvodů rozsahu práce nepopisuji. 10 DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN Kapitola 6, Životní cyklus projektu IS/ICT a jeho modelování, s

16 Využití projektového řízení při implementaci IS/ICT v podniku Vodopádový model Vodopádový model patří mezi nejstarší modely životního cyklu projektu IS/ICT. Vychází z předpokladu, že každý projekt je jedinečným a neopakovatelným procesem. Jednotlivé etapy projektu jsou vykonávány postupně po ukončení etap předcházejících a každá etapa je po ukončení vždy ověřena. Zákazník projektu hradí veškeré finanční náklady na realizaci projektu. Dodavatel projektu se na nákladech projektu podílí pouze v rozsahu základního školení pro své pracovníky a získání základních informačních technologií. Podíl krytí nákladů a míry rizika je z 80% na straně zákazníka projektu, z 20% na straně dodavatele projektu. Obr. 3: Vodopádový model životního cyklu projektu DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN Kapitola 6, Životní cyklus projektu IS/ICT a jeho modelování, s. 70.

17 Využití projektového řízení při implementaci IS/ICT v podniku Spirálový model Spirálový model řízení projektů IS/ICT je svázán s využitím metody prototypování. Dodavatel je schopen definovat určité části informačního systému, které jsou obecně použitelné pro více zákazníků a na základě tohoto sestaví prototyp IS. Tento prototyp IS je implementován a současně probíhá kontinuální vývoj nových verzí tohoto prototypu. Podíl rozdělení nákladů mezi zákazníkem a dodavatelem projektu je vyrovnaný. Dodavatel nese náklady vývoje první verze informačního systému. Zákazník platí za tento vyzkoušený prototyp pouze část skutečných nákladů na vývoj, protože dodavatel předpokládá, že svůj prototyp prodá vícekrát. Zákazník projektu současně nese náklady na části řešení, které nebylo součástí prototypu, tj. na části pro něj speciálně upravené. Obr. 4: Spirálový model životního cyklu projektu DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN Kapitola 6, Životní cyklus projektu IS/ICT a jeho modelování, s. 72.

18 Využití projektového řízení při implementaci IS/ICT v podniku Síťový model Při síťovém modelu řízení projektů IS/ICT dodavatel projektu na základě postupů při implementaci minulých projektů postupně vytváří síť po sobě jdoucích kroků a jejich výsledků. Vazby mezi kroky a výsledky definují síťový model prací na projektu. Díky různě složitým a rozsáhlým projektům je využíván síťový model ve více vrstvách. Pak hovoříme o soustavě síťových modelů, kdy první stupněm této soustavy je soustava obecných kroků popisující práci na libovolném projektu. V případě nové situace projektu, která není v síťovém modelu popsána, je její řešení doplněno v příslušné vrstvě síťového modelu. Tímto způsobem je postupně zdokonalován obecně platný síťový model a tímto je projektové řízení neustále učícím se procesem. Dodavatel přenáší část nákladů projektu na vývoj a aktualizaci typového modelu na zákazníka. Podíl krytí nákladů a míry rizika je z 30% na straně zákazníka projektu, z 70% na straně dodavatele projektu. Obr. 5: Síťový model životního cyklu projektu DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN Kapitola 6, Životní cyklus projektu IS/ICT a jeho modelování, s. 75.

19 Využití projektového řízení při implementaci IS/ICT v podniku Procesy projektu IS/ICT Projekt je realizován v postupných, na sebe navazujících etapách a krocích. Z procesního hlediska není projekt jediných procesem, ale soustavou po sobě jdoucích procesů. Podle Svozilové (2006, 60) je možné hlavní skupiny procesů projektového řízení rozdělit takto: Inicializace a zahájení projektu proces definice zakládajícího dokumentu projektu, kterým je projekt oficiálně autorizován a zahájen. Plánování projektu proces vytvoření plánu projektu v oblastech termínů, nákladů, technologií, metodologií, rizik apod. Výstupem je podrobný plán realizace projektu. Realizace a koordinace projektu proces samotné realizace projektu, při kterém dochází k vzájemné projektové komunikaci a řízení projektu osobou projektového manažera. Monitorování a kontrola projektu proces zaměřený na průběžnou kontrolu realizovaných činností a jejich srovnání s plánem projektu v oblastech cílů projektu, termínů, nákladů, rizik, kvality apod. Uzavření projektu proces akceptace výsledků projektu zákazníkem projektu a ukončení projektu. Obr. 6: Zjednodušený logický model skupin procesů řízení projektu SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 3.1, Hlavní procesní model, s. 59.

20 Využití projektového řízení při implementaci IS/ICT v podniku Výběr dodavatele projektu IS/ICT Procesům samotné realizace projektu předchází proces výběru dodavatele projektu IS/ICT. Většina autorů tento proces nepopisuje, neboť do procesů samotného projektu nepatří. Proces výběru dodavatele projektu IS/ICT bude pro úplnost alespoň stručně popsán. Výběr dodavatele projektu je pro zákazníka projektu velice odpovědný úkol. Jakákoliv změna informačního systému je pro zákazníka projektu procesně a finančně velice náročná. Pokud nevzniknou zcela zásadní změny, které nejsou zohledněny ve strategii společnosti zákazníka projektu, očekává funkčnost informačního systému mnoho let bez změny dodavatele projektu. Zákazník projektu právě z tohoto důvodu věnuje výběru správného dodavatele projektu velkou pozornost. Výběrové řízení dodavatele projektu obvykle probíhá v následujících fázích: poptávka zákazníka projektu poptávka je obvykle doplněna o podrobnou zadávací dokumentaci obsahující všechny požadavky zákazníka projektu na budoucí informační systém, zpracování nabídky dodavatele projektu vytvoření nabídky a hrubé kalkulace realizace projektu, stanovení hrubého časového a kapacitního plánu projektu dodavatelem projektu, úvodní prezentace informačního systému dodavatel projektu prezentuje obecná fakta o firmě, informačním systému, průběhu projektu apod., postup do užšího kola výběrového řízení, podrobná prezentace definovaných části informačního systému dodavatel projektu prezentuje detailní části informačního systému, které jsou pro zákazníka projektu klíčové, smluvní jednání smluvní jednání o ceně a rozsahu produktu projektu, o smlouvě o implementaci informačního systému, o smlouvě o technické podpoře po ukončení projektu apod., konečné rozhodnutí zákazník projektu se dle závěrů výběrového řízení rozhoduje pro vybraného dodavatele projektu, podpis smluv podpis smluvních dokumentů. Podmínky výběrových řízení jsou různé a závisí na celé řadě faktorů. Dodavatel projektu čelí velké konkurenci na trhu IS/ICT, nicméně všechny jeho aktivity by měly korespondovat s etikou podnikání. Výběrová řízení projektů IS/ICT jsou v současné době provázena novými požadavky zákazníků projektu, mezi které nejčastěji patří: zákazník projektu nabízí ve výběrovém řízení minimální množství vstupních informací a pro stanovení korektního hrubého rozpočtu projektu je nutno dodavatelem projektu zrealizovat vstupní analýzu předpokládaného rozsahu projektu, zákazník projektu klade důraz na implementační metodiku dodavatele projektu a ujištění, že dodavatel projektu je schopen projekt dovést do úspěšného konce, zákazník projektu požaduje fixní cenu produktu projektu ještě před zahájením předimplementační analýzy (studie proveditelnosti),

21 Využití projektového řízení při implementaci IS/ICT v podniku 21 zákazník projektu požaduje prezentaci budoucího řešení, kdy je dodavatel projektu nucen připravit prezentaci s daty zákazníka projektu a s hrubými rysy budoucího řešení, zákazník projektu v důsledku zkrácení výběrového řízení požaduje jedinou prezentaci Inicializace a zahájení projektu V této fázi projektu dochází k formálnímu zahájení projektu, definici cílů projektu a definici základních dokumentů projektu. Stanovení cílů projektu je podstatným prvkem projektového řízení, který je klíčový pro hodnocení úspěšnosti projektu. Podle Svozilové (2006, 78) Cíl projektu je nová hodnota předmět, služba nebo jejich kombinace, která je výsledkem projektu a je reprezentována popisem určitého stavu, jež má v budoucnu existovat. Cíle projektu mají zásadní význam, protože: 15 jsou základem kontraktu mezi zákazníkem projektu a dodavatelem projektu, jsou předmětem komunikace mezi sponzorem projektu, manažerem projektu a projektovým týmem, definují výstupy očekávané od projektu, jsou základem pro plánování projektu, poskytují rámec požadovaných parametrů a rámec pro kontrolní procesy, určují měřítko hodnocení dosažení úspěšného dokončení projektu. Projekt je obvykle definován hlavním globálním cílem, který je následně rozložen na jednotlivé konkrétní cíle. Cíle je nutno správně formulovat, neboť chybně formulované cíle není možné dosáhnout, měřit, splnit, ani hodnotit. Pro správnou definici cílů je doporučováno využít techniky SMART: 16 S = Specific cíle musí být specifické a konkrétní, M = Measurable cíle musí být měřitelné, aby bylo možné rozhodnout o jejich splnění, A = Assignable cíle musí být přidělitelné určenému subjektu s odpovědností, R = Realistic cíle musí být dosažitelné s použitím dostupných zdrojů, T = Time-bound cíle musí být časově ohraničené. Každý z konkrétních cílů projektu by měl být logicky navázán na určitou část produktu projektu. Pokud tomu tak není, je cíl definován příliš obecně. Metriky splnění cílů projektu pak přesně specifikují hodnoty, které mají být realizací projektu vytvořeny a jejichž splněním jsou splněny stanovené cíle projektu. Některé cíle zákazníků projektu nejsou v souvislosti s implementací projektu IS/ICT měřitelné, např. zvýšení zisku, snížení zaměstnanosti či zvýšení efektivity práce o stanovená procenta. Snahou dodavatele projektu by mělo být tyto cíle nevztahovat k produktu projektu, neboť jsou ovlivněny okolnostmi, které nesouvisí pouze s projektem (např. nesplnění zvýšení zisku 15 SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 4.2, Stanovení cílů projektu, s DORAN, George. There s a S.M.A.R.T. Way to Write Management Goals and Objectives, First Edition, Management Review, 1981

22 Využití projektového řízení při implementaci IS/ICT v podniku 22 společnosti zákazníka projektu o stanovené procento v důsledku oslabení kurzu koruny nemohl projekt implementace IS/ICT žádným způsobem ovlivnit). Další důležitou součástí fáze projektu inicializace a zahájení projektu je definice základních dokumentů projektu. Jsou to následující dva klíčové dokumenty: Zakládající dokument projektu dokumentem je stvrzeno přidělení odpovídajících odpovědností a pravomocí manažeru projektu, jsou stvrzeny termíny zahájení a ukončení projektu, je definován rozsah potřebných zdrojů apod., Definice produktu projektu dokument určuje rozsah projektu, který je definován formou požadavků zákazníka projektu, globálních a konkrétních cílů projektu a metrik jejich hodnocení. Definice rozsahu projektu je klíčovou částí ovlivňující následující plánování projektu. Pro snížení pravděpodobnosti, že by v rozsahu projektu byly zapomenuty některé jeho části, je vhodné rozdělit projekt na menší oblasti. Hierarchická struktura činností (Work breakdown structure, WBS) je vhodnou metodou pro rozdělení projektu do jednotlivých částí, úkolů a činností. Je zřejmé, že jednotlivé rozdělené části musí být mezi sebou propojeny a řízeny. Rozdělením projektu na velké množství menších částí (a případně i více vrstev) je zlepšená přesnost sledování stavu projektu, ale na druhé straně vzniká větší potřeba tyto části mezi sebou propojit a řídit. Rozdělením projektu na velké části je snížena potřeba propojení, ale na druhé straně je značně zhoršena přesnost sledování stavu projektu 17. Optimální volbou je kompromis mezi výše uvedenými přístupy, v případě projektů IS/ICT se osvědčila maximálně čtyřvrstvá struktura WBS. Současně je doporučováno do struktury WBS doplnit další důležité údaje, které jsou využívány při plánování projektu. Mezi tyto údaje patří čas potřebný k realizaci daného úkolu a název zdroje zodpovědného za provedení daného úkolu. Příklad části struktury WBS projektu IS/ICT je uveden na obr ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN Kapitola 6, Hierarchická struktura činností projektu, s. 73.

23 Využití projektového řízení při implementaci IS/ICT v podniku Plánování projektu Obr. 7: Možné členění struktury WBS projektu IS/ICT Plánování projektu je klíčovým a rozhodujícím procesem projektového řízení. Plány poskytují základ pro sledování průběhu projektu a jsou klíčové pro komunikaci a koordinaci projektu. Do plánování projektu je potřeba zapojit všechny osoby, které jsou odpovědné za realizaci jednotlivých úkolů projektu. Pro plánování platí zlaté pravidlo (Rosenau, 2000, 57) Zapojte osoby, které budou na projektu pracovat, do plánování prací. Měly by o nich vědět víc, než kdokoliv jiný. Je to jejich úkol, ne váš. Plány vznikají pro všechny tři základny projektového managementu a musí tvořit jeden navzájem provázaný a integritní celek, nazývaný Plán projektu. Každý projekt má svou odpovídající úroveň plánování a neexistuje pravidlo, do jakých podrobností při plánování zajít. Plán projektu IS/ICT je tvořen níže uvedenými částmi: Výchozím stavem tvorby plánu projektu jsou definované cíle a rozsah projektu. U projektů implementace IS/ICT jde o dokument vstupní analýzy (analýzy proveditelnosti, předimplementační analýzy apod.) zpracovaný dodavatelem projektu. 2. Pro možné hodnocení splnění produktu projektu jsou přijaty metriky projektu, tj. konkrétní a měřitelná akceptační kritéria pro všechny části produktu projektu. Metriky projektu vycházejí z definice jednotlivých cílů a rozsahu projektu. 18 ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN Kapitola 5, Proč a jak projekt plánovat, s

24 Využití projektového řízení při implementaci IS/ICT v podniku Některé projekty jsou doprovázeny dalšími metrikami, které jsou interními pravidly zákazníka či dodavatele projektu, např. realizace projektu dle procesů ISO normy dodavatele. I tato kritéria musí být při realizaci projektu splněna. 4. Definované cíle a rozsah projektu určují hierarchickou strukturu činností (WBS) projektu a jakýkoliv realizovaný úkol musí být ve struktuře WBS definován. 5. Realizace každého prvku struktury WBS musí být časově ohraničená. Tímto bude možné v síťovém grafu určit kritickou cestu projektu. 6. Jednotlivé prvky struktury WBS jsou realizovány přidělenými zdroji. Tímto vzniká plán materiálních a lidských zdrojů. 7. Každý prvek struktury WBS má svůj začátek a dle délky trvání i svůj konec. Délka trvání je závislá na kvalitě přiděleného zdroje (je zřejmé, že zkušený pracovník přidělený úkol provede v kratším čase, než jeho méně zkušený kolega). Na základě hierarchické struktury činností (WBS) a přidělených zdrojů je možné stanovit rozpočet projektu. Obr. 8: Vztahy mezi jednotlivými částmi plánu projektu Plánování harmonogramu projektu Diagramy hrají významnou roli v metodologiích projektového managementu jako efektivní nástroje pro plošné zobrazení všech informací potřebných pro řízení projektu 20. Existuje řada metod používaných pro časové plánování projektu. Ganttovy diagramy Úsečkové diagramy, nazývané také Ganttovy diagramy, jsou často používanou metodou pro časové plánování projektu. Hierarchická struktura činností je 19 ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN Kapitola 5, Proč a jak projekt plánovat, s SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.3, Časový rozpis projektu, s

25 Využití projektového řízení při implementaci IS/ICT v podniku 25 organizována horizontálně v posloupnosti shora dolů a časová osa je organizována vertikálně zleva doprava. Původně měly tyto diagramy určitá omezení, kdy neukazovaly závislosti mezi úkoly, změny v trvání úkolů se nepromítly do zbývajících částí harmonogramu, procentuální vyjádření stavu dokončení úkolů bylo velice subjektivní atd. V dnešní době je již řada těchto omezení u používaných softwarových nástrojů (např. Microsoft Project) vyřešena. Milníky Milníky zaznamenávají klíčové události projektu. I ony mají svá omezení, kdy nezobrazují jednotlivé úkoly projektu a jejich trvání. Mezi typické milníky projektu IS/ICT patří zahájení projektu, zahájení a ukončení testování dílčích částí produktu projektu, zahájení a ukončení akceptace produktu projektu, připravenost pro převod dat, zahájení a ukončení školení či asistencí, ukončení projektu. Milníky mají obvykle vazbu na rámce definované ve smluvních dokumentech dodavatele projektu se sponzorem projektu. Síťové diagramy CPM/PERT Obě metody, metoda kritické cesty (Critical Path Method, CPM) i metoda techniky vyhodnocení a kontroly programu (Program Evaluation and Review Technique, PERT) jsou si velice podobné a dovolují efektivně a flexibilně udržovat harmonogram projektu. Umožňují hledat alternativy, určovat pravděpodobnosti a odchylky, mají definovanou kritickou cestu a disponují dalšími vlastnostmi nutnými pro efektivní projektové plánování. Jednotlivé činnosti projektu jsou s použitím metody CPM plánovány s definovanou délkou jejich realizace. S použitím metody PERT je zvažována optimistická a pesimistická varianta délky trvání jednotlivých činností projektu a plánovaná délka trvání je z těchto údajů kalkulována. Metoda PERT je využívána pro projekty, kde je obtížné odhadnout délku trvání jednotlivých činností (např. vývoj informačního systému). Metoda CPM je využívána pro projekty, kde je možné stanovit délku trvání jednotlivých činností projektu (např. implementace informačního systému). Obr. 9: Příklad PERT diagramu SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.3, Časový rozpis projektu, s. 136.

26 Využití projektového řízení při implementaci IS/ICT v podniku 26 Síťové diagramy PDM Následníkem metod CPM a PERT je metoda měření potenciálu v síti (Metra Potencial Method, MPM) 22, která vychází z uzlově orientovaného síťového grafu. Tato metoda vznikla v roce 1958 ve Francii a byla poprvé použita při plánování a kontrole stavby jaderné elektrárny na řece Loiře. Zjednodušenou variantou metody MPM je metoda PDM (Precedence Diagram Method). Metody CPM a PERT nabízejí jedinou vazbu dvou činností, která je typu konec začátek (Finishto-Start). Tento typ vazby znamená, že po ukončení dané činnosti bude pokračovat činnost následující. Metoda PDM množinu typů vazeb rozšiřuje a nabízí celkově čtyři možné typy vazeb mezi jednotlivými činnostmi: začátek začátek (Start-to-Start, SS) činnost A2 může být zahájena pouze po zahájení činnosti A1, začátek konec (Start-to-Finish, SF) činnost A3 musí začít dříve, než skončí činnost A4, konec konec (Finish-to-Finish, FF) činnost A6 nemůže skončit dříve, než skončí činnost A5, konec začátek (Finish-to-Start, FS) činnost A7 musí být dokončena před zahájením činnosti A8. Obr. 10: Typy vazeb v PDM diagramu 23 Další novou vlastností metody PDM jsou možné vzájemné překryvy a prodlevy realizace jednotlivých činností, které jsou zobrazeny na obrázku 10 (činnosti A1- A2 a A3-A4). Síťové diagramy ADM Metoda šipkového diagramu (Arrow Diagram Method, ADM) vychází ze síťového grafu, ve kterém jsou činnosti reprezentovány šipkami mezi body (Activity On Arrow, AOA) nebo jsou činnosti reprezentovány uzly (Activity on Node, AON) 23. Tyto metody pracují s dalšími informacemi potřebnými pro efektivní řízení projektu, mezi které patří osoby přiřazené jednotlivým činnostem, náklady na jednotlivé úseky práce, časové rezervy apod. 22 FIALA, Petr. Řízení projektů. První vydání, Praha, Ediční oddělení VŠE Praha, 2002, ISBN Kapitola 3, Modely a metody řízení projektů, s SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.3, Časový rozpis projektu, s. 137.

27 Využití projektového řízení při implementaci IS/ICT v podniku 27 Integrované metody GERT, VERT a další Metoda GERT umožňovala pravděpodobnostní větvení a kalkulaci nákladů na jednotlivé činnosti. Náklady byly závislé na délce trvání projektu. Metoda VERT přiřazovala náklady ke každé činnosti a výkonnost byla modelována v měřitelných jednotkách. Spíše než rozdělení parametrů jednotlivých činností na náklady, plán a vykonanou práci, byly používány korelační koeficienty ke zjištění závislostí mezi těmito třemi parametry. 24 Po vytvoření návrhu harmonogramu projektovým manažerem dochází obvykle k jeho následné optimalizaci. Nejčastějšími důvody optimalizace harmonogramu jsou nutné zkrácení harmonogramu, kapacitní omezení zdrojů, snížení nákladů projektu nebo koordinace s interními projekty (např. související projekt subdodávky). Pro optimalizaci je možné použít řadu postupů, kdy mezi nejčastěji používanými jsou 25 : vyhledání činností na kritické cestě, které lze rozdělit do více paralelně běžících částí, rekalkulace s výsledným snížením doby trvání činností na kritické cestě, přidělení více zdrojů realizaci vybraných činností s výsledným zkrácením doby jejich realizace, revize typů vazeb mezi jednotlivými činnostmi a změna typů vazeb konec začátek (FS) na jiné typy, přesun některých skupin činností mimo kritickou cestu Plánování zdrojů projektu Vytvoření plánu potřebných zdrojů pro realizaci projektu je další krokem při plánování projektu. Při plánování zdrojů je nutné plánované zdroje alokovat, tj. zdroje pro každou činnost projektu rezervovat. Tímto nedochází ke konfliktům nároků na zdroj jinými činnostmi daného projektu nebo nároků na zdroj jinými projekty. Kromě kvalifikace a osobních schopností pracovníka pro plnění přidělených činností je nutno, aby daný pracovník tuto úlohu přijal a tímto akceptoval převzetí odpovědnosti. Organizační struktura projektu určuje matici odpovědností. Dle Svozilové (2006, 151) Matice odpovědností je soustavou řádků a sloupců, jejímž prostřednictvím jsou přiřazeny projektovým úsekům a úkolům ti, kteří mají schopnosti a odpovědnost pro jejich realizaci. Síťový graf projektu zobrazuje, jaké zdroje, a v jakých termínech, jsou pro realizaci přidělených činností požadovány. Sumární pohled na počet potřebných pracovníků v čase dává první kontrolu správnosti plánu zdrojů. Pokud bude v daném čase potřeba 8 pracovníků a projektový tým takovým počtem pracovníků nedisponuje, jde o konflikt, který je třeba řešit. Dalším kontrolním pohledem na plán zdrojů je pracovní kalendář jednotlivých pracovníků. Jedna z forem pohledů na pracovní kalendář pracovníka je 24 ŠUBRT, Tomáš, LANGROVÁ, Pavlína. Systémová podpora projektů. První vydání, Praha, Česká zemědělská univerzita v Praze, 2003, ISBN Kapitola 2.5, Nástroje projektového řízení, s SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.3.2, Obecné postupy tvorby diagramu projektu, s. 147.

28 Využití projektového řízení při implementaci IS/ICT v podniku 28 histogram kapacitního vytížení, který zobrazuje jeho vytížení včetně případných přetížení nebo časových rezerv. Obr. 11: Histogram kapacitního vytížení pracovníka Plánování rozpočtu projektu Rozpočet projektu je důležitou částí plánu projektu. Rozpočtem projektu je časový plán nákladů kalkulovaný v peněžních jednotkách, někdy také v pracovních jednotkách (obvykle hodiny nebo dny). Rozpočet projektu se skládá z následujících druhů nákladů projektu 27 : přímé náklady jsou náklady přímo zatěžující projekt, např. náklady na práci, materiál, pořízení nebo pronájem technologií, cestovné, licence a poplatky, nákup subdodávek, další služby projektu (přepravné, likvidace odpadu apod.), pojištění, náklady na financování projektu a další, nepřímé (režijní) náklady jsou náklady promítnuté do projektu stanoveným koeficientem, např. koeficient nákladů na režijní mzdové náklady (platy administrativních pracovníků, manažerů apod.), koeficient nákladů na provoz společnosti dodavatele (pronájem budov, odpisy majetku, marketing apod.) a další, ostatní náklady jsou mimořádné náklady projektu, např. rezerva pro krytí rizik projektu, rezerva na mimořádné stavy projektu, vyplacené bonusy obchodníkům, inflace či změny kurzů při financování projektu a další. 26 SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.4, Obsazení projektu plánování a alokace zdrojů, s SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 5.5, Rozpočet projektu, s. 156.

29 Využití projektového řízení při implementaci IS/ICT v podniku 29 V době kalkulace nákladů mají všechny činnosti stanovenou délku jejich trvání a mají přiděleny zdroje pro jejich realizaci. Kalkulace nákladů na práci (popř. cestovného) vychází z hierarchické struktury činností (WBS) projektu a kalkulované nákladové ceny každého přiděleného zdroje. Všechny náklady projektu je možné odhadovat nebo kalkulovat s využitím nejrůznějších technik a metod. Nejhrubší odhady vycházejí ze zkušeností z jiných projektů, z analýz konkurenčních nabídek nebo z analýz nabídek potencionálních subdodavatelů. Přesnější plány nákladů jsou výsledkem kalkulací vycházejících ze sazeb jednotlivých zdrojů a hierarchické struktury činností projektu. Při kalkulaci nákladů určitých typů projektů IS/ICT (např. vývoj informačního systému) jsou využívány parametrické odhady nákladů, které vycházejí z výchozích údajů (např. počet řádků kódu) a ověřených statistických dat. Při plánování rozpočtu projektu by měl projektový manažer vycházet z odborných odhadů projektového týmu. Na druhé straně může projektový manažer čelit neúměrně vysokým odhadům projektového týmu, který si tímto vytváří rezervy pro realizaci projektu. Před optimalizací harmonogramu projektu by mělo dojít k vyjednávání projektového manažera se členy projektového týmu s výslednou shodou v kalkulaci nákladů projektu. Projektový manažer je současně pod tlakem vrcholového managementu, jehož snahou je minimalizace nákladů projektu vedoucí k nižší ceně projektu či vyšším ziskům z projektu Plánování rizik a rezerv projektu Rizika jsou součástí každého projektu, v závislosti na charakteru projektu jsou menší nebo větší. Plánování rizik je aktivita v průběhu plánování projektu, která predikuje možné nežádoucí situace a stavy projektu a určuje jejich finanční hodnotu nutnou pro případ jejich řešení. Je to cena nápravy stavu v případě výskytu daného rizika v průběhu realizace projektu. Mezi nejčastější zdroje rizik projektu patří nedostatečně definované požadavky produktu projektu, chybné odhady doby trvání jednotlivých činností, subdodávky projektu, nedostatečná podpora managementu zákazníka projektu, nezkušení pracovníci projektového týmu, nezkušený projektový manažer a další. Proces řízení rizik je dle Svozilové (2006, 268) Sled aktivit, ve kterých jsou prostřednictvím preventivních nebo korektivních zásahů odvraceny události a odstraňovány vlivy, které by mohly ohrozit řiditelnost plánovaných procesů nebo by mohly vést k jiným nechtěným výsledkům. Každé riziko je identifikováno místem jeho vzniku na projektu, zdrojem a pravděpodobností jeho vzniku, závažností jeho dopadu a stupněm možnosti jeho kontroly. Důležitým faktorem posuzování rizik je místo jeho vzniku na projektu. Obrázek 12 ukazuje míru ohrožení projektu riziky vzhledem k jeho životnímu cyklu.

30 Využití projektového řízení při implementaci IS/ICT v podniku 30 Obr. 12: Hodnota rizika v životním cyklu projektu Plánování komunikace projektu Při realizaci projektu je klíčová efektivní projektová komunikace. Zajišťuje přenos potřebných informací v projektovém týmu a její budování je odpovědností projektového manažera. V průběhu zahájení projektu dochází k definici interních (v rámci projektového týmu dodavatele projektu) a externích (se zákazníkem projektu a vnějším okolím projektu) komunikačních pravidel a komunikačních kanálů projektu. Součástí plánu komunikace projektu je plán projektových jednání. Projektová jednání je možné rozdělit podle zaměření jejich programu. Interní zahájení projektu (interní Kick-Off Day) je zahájením projektu pouze na úrovni dodavatele projektu, kdy je projektový tým seznámen s rozsahem produktu projektu, jednotlivými členy projektového týmu a pravidly projektové komunikace. V rámci tohoto jednání je projektový tým současně seznámen se všemi dostupnými informacemi týkajících se projektu včetně informací interních a neveřejných. Zahájení projektu (Kick-Off Day) je oficiálním zahájením projektu, kdy jsou oba projektové týmy (zákazníka i dodavatele) seznámeny s rozsahem produktu projektu, jednotlivými členy projektových týmů a pravidly projektové komunikace. V rámci tohoto jednání je zákazníkovi projektu prezentován návrh harmonogramu projektu a plánovaný průběh realizace projektu. Jednání projektových týmů probíhá v průběhu realizace projektu v případech potřeby řešení vzniklých problémů, požadavků či úkolů projektu. Tato jednání probíhají i na interní úrovni v rámci projektového týmu při kontrole stavu projektu. 28 SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 9.2, Proces řízení rizik projektu, s. 271.

31 Využití projektového řízení při implementaci IS/ICT v podniku 31 Jednání vedení projektu probíhají pravidelně dle harmonogramu programu a jejich náplní je kontrola realizace projektu vůči plánu projektu ve všech jeho dílčích částech (rozsah produktu projektu, harmonogram projektu, rozpočet projektu, zdroje, rizika, komunikace a další). Individuální jednání probíhají v průběhu realizace projektu mezi zúčastněnými osobami projektových týmů i mimo něj Realizace a koordinace projektu Řízení projektových prací se soustředí na dosažení definovaných cílů projektu prostřednicím výkonů jednotlivých zdrojů projektu. Realizace a koordinace projektu začíná schválením plánu projektu a vychází z podrobného harmonogramu projektu. Každý zdroj dle svého pracovního kalendáře realizuje jemu přidělené úkoly a odvedenou práci vykazuje. V dnešní době je již běžné a pro efektivní řízení projektů nepostradatelné, že toto vykazování probíhá v softwarových nástrojích pro podporu řízení projektů. Řízení projektu probíhá ve formě 29 : obsazování vyhledávání pracovníků vhodných pro splnění daného úkolu, delegování přidělení daného úkolu pracovníkovi s předáním odpovědnosti za splnění úkolu, koordinace zajištění plynulosti při realizaci jednotlivých úkolů, motivace zajištění zájmu pracovníka na splnění daného úkolu v souladu s jeho hodnotovým žebříčkem, dohledu sledování průběhu plnění realizovaných úkolů, školení rozvoj znalostí a dovedností pracovníků, poskytování rad sdílení znalostí a zkušeností Monitorování a kontrola projektu Monitorování a kontrola projektu jsou zaměřeny na zjištění souladu probíhající realizace projektu s jeho plánem. Probíhající realizace je srovnávána s plánem produktu projektu, časovým plánem projektu, plánem nákladů projektu, plánem rizik a plánem kvality. Monitorování a kontrola je proces, který probíhá vždy ve třech fázích: měření, hodnocení a korekce. Pokud jsou zjištěny odchylky od plánu projektu, musí dojít k vyhodnocení vzniklého stavu a k návrhu a provedení nápravných opatření. Další důležitou částí monitorování a kontroly projektu je proces řízení změn projektu ve všech jeho částech, tj. produktu, času, nákladů, rizik a kvality. Existují různé postupy a metody, jak monitorovat a kontrolovat stav prací na projektu. Jedním z postupů je sledování procenta dokončenosti jednotlivých úkolů projektu. Je potřeba si uvědomit, že procentuální ohodnocení rozpracovanosti úkolu je subjektivní a tímto je tento postup méně spolehlivý. Současně existují určité úkoly, u kterých je stanovení procenta dokončení zkreslující, např. vyvrtáním 80 děr ze 100 je 29 SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN Kapitola 6, Řízení projektových prací, s. 174.

32 Využití projektového řízení při implementaci IS/ICT v podniku 32 úkol dokončen v 80%, nicméně při zničení desky není možné vycházet ze zbývajících 20% k dokončení. Dalším možným postupem je sledovat stav úkolu pouze ve dvou stavech (dokončeno, nedokončeno) a posuzovat dokončení úkolu na základě výstupů daného úkolu, které vyhovují dohodnutým akceptačním kritériím projektu Uzavření projektu V případě akceptace produktu projektu zákazníkem projektu můžeme říci, že projekt byl úspěšně ukončen. Zákazník projektu akceptací deklaruje splnění podmínek definující tři základny projektového managementu (čas, zdroje a náklady). Uzavření projektu probíhá formálním vyhodnocením projektu. Projektový manažer vytváří závěrečné a hodnotící interní dokumenty projektu, hodnotí práci všech členů projektového týmu a administrativně projekt uzavírá. Závěrečné a hodnotící interní dokumenty projektu vyhodnocují naplnění cílů projektu a porovnávají plánované a skutečně dosažené výsledky všech částí projektu (produkt, čas, náklady, rizika a kvalita). Administrativní uzavření projektu ověřuje a dokumentuje všechny výstupy projektu, účetně vypořádává financování projektu a archivuje komplexně připravenou dokumentaci projektu. 30 ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN Kapitola 17, Nástroje k sledování průběhu projektu, s

33 Využití projektového řízení při implementaci IS/ICT v podniku Metodické standardy projektového řízení Teoretické znalosti také vycházejí z metodických standardů a metodik společností, které vyvíjejí a implementují projekty IS/ICT. Metodologie projektového řízení představuje způsob řízení projektu. První metodologie vznikají v padesátých a šedesátých letech minulého století. V roce 1969 byl založen Project Management Institute (PMI), který má v dnešní době více než členů ve více než 171 státech světa. PMI definuje standardy, provádí výzkum a poskytuje vzdělávání vedoucí k profesionalitě projektového managementu. V současné době existují standardizované pohledy na metodologii projektového řízení a mezi nejvýznamnější patří: System Development Life Cycle (SDLC) metodika popisuje základní fáze projektu jako zahájení/plánování, analýza, návrh řešení, vývoj/kódování, testování, implementace a je využívána převáženě pro řízení projektu vývoje informačního systému. Metodika také popisuje možné modely životního cyklu projektu. Project Management Body Of Knowledge (PMBOK) byla poprvé představena v roce 1996 a v roce 2004 byla vydána její třetí verze. Metodika popisuje znalostní oblasti projektového řízení, mezi které patří řízení projektové integrace, cílů, času, nákladů, kvality, lidských zdrojů, komunikace, rizik a dokumentace. Project in Controlled Enviroment (PRINCE2) je strukturovanou metodikou pro efektivní řízení projektu, poprvé vydanou ve Velké Británii v roce 1989 v první verzi a v roce 1996 ve druhé verzi. Metodika obsahuje charakteristiku všech 45 procesů, které určují popisy činností na projektu v dané fázi a vymezují určitou oblast projektového řízení organizace, plánování, kontrola, fázování, řízení rizik, řízení kvality, řízení konfigurace a řízení změn. Rational Unified Process (RUP) je metodikou vyvinutou společností Rational Software v roce 2003 (divize společnosti IBM). Metodika je podporována softwarově a lze ji dynamicky přizpůsobit procesům společnosti, ve které je implementována. Metodika disponuje základními elementy (role, produkty a úkoly) a čtyřmi fázemi životního cyklu projektu (zahájení, zpracování, vývoj, změna). Všechny metodiky projektového řízení používají základní techniky a nástroje projektového řízení, mezi které patří síťové grafy, diagramy projektů (PERT/CPM a další), kritická cesta, organizační struktura projektu a další.

34 Využití projektového řízení při implementaci IS/ICT v podniku 34 3 Vlastní práce Vlastní práce vychází ze současného stavu práce popsaného v předcházející kapitole, z mých znalostí projektového managementu a získaných zkušeností implementací projektů informačního systému NAVISON (v dnešní době informační systém Microsoft Dynamics) v letech a informačního systému KARAT v letech Tato část práce prezentuje praktické využití projektového řízení při řízení projektů implementací IS/ICT v podniku. Rozsah využití všech oblastí projektového řízení popisovaných v této práci závisí na rozsahu implementovaného projektu IS/ICT v podniku. V případě menších projektů nebudou pravděpodobně využity všechny popisované oblasti projektového řízení (obvykle totiž neprobíhá plánování rizik či subdodávek, v menším rozsahu probíhá plánování nákladů, komunikace či plánování kvality). Naopak v případě velkých projektů budou využity všechny oblasti projektového řízení ve větším rozsahu, než samotná práce popisuje. Projekt implementace IS/ICT je obvykle realizován dle síťového modelu životního cyklu projektu a jeho určité části mohou přecházet k modelu vodopádovému. Specifikem projektu implementace IS/ICT vůči projektům jiných oblastí je fakt, že samotné implementaci IS/ICT obvykle předchází předimplementační analýza (také nazývána studie proveditelnosti, vstupní analýza apod.). V závislosti na rozsahu implementovaného IS/ICT mohou být předimplementační analýza a implementace IS/ICT realizovány jako samostatné a na sebe navazujícími projekty. Závěry projektu předimplementační analýzy definují vstupní rozsah projektu implementace IS/ICT. Pro zjednodušení vycházím ze situace, kdy předimplementační analýza byla realizována samostatným projektem, který byl dokončen a zákazníkem projektu akceptován. Dokument předimplementační analýzy podrobně popisoval produkt projektu implementace IS a definoval: přesný rozsah modulů IS, které zákazník požaduje, přesný popis nastavení požadovaných modulů IS, přesný popis procesů, postupů a funkčností, které zákazník požaduje, přesný popis zakázkových úprav vůči standardnímu řešení, které zákazník požaduje, přesný popis technického řešení projektu IS. Zákazníkem projektu byla akciová společnost Lesaffre Česko. Projekt implementace IS/ICT v tomto podniku proběhl v průběhu roku 2007 a od 1. ledna 2008 byl zahájen rutinní provoz celého řešení. Ke dni 31. března 2008 byl projekt dokončen a zákazníkem projektu akceptován. Projekt implementace IS/ICT v podniku Lesaffre Česko, a.s. byl řízen s využitím projektového řízení a při jeho realizaci byly realizovány postupy a procesy popsané v teoretické části této práce.

35 Využití projektového řízení při implementaci IS/ICT v podniku Inicializace a zahájení projektu Po rozhodnutí o výběru dodavatele projektu implementace IS/ICT zákazníkem projektu Lesaffre Česko, a.s. následoval proces inicializace a zahájení projektu. Vedením společnosti dodavatele projektu byl delegován manažer projektu, který přijetím této role akceptoval převzetí odpovědnosti za projekt jako celek. Jeho klíčová role je podrobně popsána v kapitole Okolí projektu Cíle projektu Při inicializaci a zahájení projektu došlo projektovým manažerem k sumarizaci cílů projektu, které vycházejí ze závěrů dokumentu předimplementační analýzy. Zákazník projektu definoval několik desítek cílů. Všechny definované cíle byly projektovým manažerem vztaženy k rozsahu a specifikaci uvedené v předimplementační analýze. Současně byly společně se zákazníkem projektu definovány metriky splnění všech takto stanovených cílů. Na obrázku 13 je zobrazena část těchto cílů včetně všech jejich definovaných parametrů. Obr. 13: Část cílů projektu, jejich rozsah a metriky hodnocení Zakládající dokument projektu Následně byl projektovým manažerem připraven Zakládající dokument projektu, který je uveden v příloze č. 1. Tento dokument byl při zahájení projektu (Kick-Off Day) se zákazníkem projektu odsouhlasen. Dokument definuje rámce a pravidla projektového řízení, kterými se obě zúčastněné strany po celou dobu projektu implementace řídily. Dokument se skládá z níže uvedených částí, které budou stručně vysvětleny: název projektu slouží k jednoznačné identifikaci projektu, která je uvedena ve všech dokumentech projektové dokumentace, v systému pro podporu řízení projektů dodavatele projektu apod. identifikace zákazníka projektu,

36 Využití projektového řízení při implementaci IS/ICT v podniku 36 definice cílů projektu podrobně popisuje stanovené cíle projektu společně s metrikami hodnocení jejich splnění, vazbami cílů na produkt projektu a termíny kontroly jejich splnění, datum zahájení projektu, datum ukončení projektu, organizační struktura projektu graficky zobrazuje postavení jednotlivých členů projektových týmů a jejich vazby v rámci odpovědností, pravomocí a komunikačních pravidel projektu, definice odpovědností osob projektu podrobně popisuje odpovědnosti jednotlivých členů projektových týmů (ředitele projektu, vedoucího projektu, vedoucího pracovního týmu, člena pracovního týmu, vedoucího změnové komise a člena změnové komise), definice pravomocí osob projektu podrobně popisuje pravomoci jednotlivých členů projektových týmů, dokumenty projektové dokumentace podrobně popisuje druhy dokumentů a jejich význam v průběhu projektu (harmonogram projektu, výkaz o provedení práce, plán školení, hodnocení lektora, test, zápis z jednání, zápis z řídícího/výkonného týmu, zpráva o průběhu projektu, požadavek na změnu, reklamační protokol, předávací protokol, testovací protokol a akceptační protokol), projektové týmy projektu podrobně popisuje všechny projektové týmy projektu včetně jejich vazby na produkt projektu, delegování členů projektu deleguje jednotlivé osoby zákazníka a dodavatele projektu do všech definovaných projektových týmů, rizika projektu podrobně popisuje rizika projektu a nápravná opatření k jejich minimalizaci, komunikační standardy projektu podrobně popisují prostředky externí a interní komunikace v průběhu projektu, základní nástroje této komunikace a kompetentní osoby k podpisu výkazů práce pracovníků dodavatele projektu. Současně byl projektovým manažerem připraven interní dokument START projektu, který je uveden v příloze č. 2. Dokument slouží pro interní stvrzení přijetí role projektového manažera (ředitel projektu) a vedoucího projektu. V případě jakékoliv změny v parametrech projektu uvedených v tomto dokumentu dochází k vytvoření nové verze dokumentu START projektu. Časté změny v zadání projektu nastávají u rozpočtu projektu, který je obvykle v průběhu projektu implementace IS/ICT navyšován v důsledku změn v rozsahu produktu projektu, u termínů ukončení projektu apod. Dokument se skládá z níže uvedených částí, které budou stručně vysvětleny: název projektu slouží k jednoznačné identifikaci projektu, identifikace zákazníka projektu, cíle projektu a metriky jejich hodnocení projektu podrobně popisuje stanovené cíle projektu společně s metrikami hodnocení jejich splnění, vazbami cílů na produkt projektu a termíny kontroly jejich splnění, interní objednatel projektu popisuje delegované osoby projektu vystupující jako interní objednatel projektu,

37 Využití projektového řízení při implementaci IS/ICT v podniku 37 interní zhotovitel projektu popisuje delegované osoby projektu vystupující jako interní zhotovitel projektu, definice projektu popisuje produkt projektu, jehož realizace je požadována interním objednatelem po interním zhotoviteli, začátek projektu, konec projektu, rozpočet projektu stanovený a odsouhlasený rozpočet realizace projektu, projektová dokumentace popisuje stav připravenosti projektové dokumentace (připravenost dokumentace projektu v papírové podobě a dokumentace projektu v elektronické podobě včetně přístupových práv členů projektového týmu) a připravenosti komunikace projektu Definice produktu projektu Dalším klíčovým dokumentem, který byl projektovým manažerem v průběhu inicializace a zahájení projektu vytvořen, byl dokument Definice produktu projektu. Produkt projektu implementace IS/ICT v podniku Lesaffre Česko, a.s. byl podrobně popsán samostatným dokumentem Předimplementační analýza. Tento dokument byl definován a zákazníkem projektu akceptován samostatným projektem, který předcházel projektu implementace IS. Jak bylo v úvodu této kapitoly řečeno, dokument předimplementační analýzy definoval: přesný rozsah modulů IS, které zákazník požaduje, přesný popis nastavení požadovaných modulů IS, přesný popis procesů, postupů a funkčností, které zákazník požaduje, přesný popis zakázkových úprav vůči standardnímu řešení, které zákazník požaduje, přesný popis technického řešení projektu IS Komunikace při inicializace a zahájení projektu V rámci zahájení a inicializace projektu došlo na straně dodavatele projektu k následujícím interním procesům: byl připraven šanon sloužící jako úložiště projektové dokumentace v písemné podobě s definovanými záložkami odpovídající jednotlivým druhům dokumentů projektové dokumentace, byl připraven portál aplikace Microsoft SharePoint Portal Server sloužící jako úložiště projektové dokumentace v elektronické podobě s definovanými stránkami odpovídající jednotlivým druhům dokumentů projektové dokumentace (pro úložiště projektové dokumentace v elektronické podobě lze i efektivně využít veřejné složky aplikace Microsoft Exchange Server, popř. adresářovou strukturu sdílenou na serveru), jednotlivým členům projektového týmu byla nastavena přístupová práva k jednotlivým částem úložiště projektové dokumentace v elektronické podobě,

38 Využití projektového řízení při implementaci IS/ICT v podniku 38 byla zřízena centrální ová projektová adresa lesaffre@karatsoftware.cz a nastaveno automatické přeposlání všem členům projektového týmu každého e- mailu zaslaného na tuto ovou projektovou adresu, bylo nastaveno ukládání přijatých a odeslaných ů této ové projektové adresy do příslušných složek projektové dokumentace v elektronické podobě. Projektový manažer současně zorganizoval interní úvodní schůzku celého projektového týmu dodavatele projektu (interní Kick-off Day), v rámci kterého byl: projektový tým seznámen s komunikačními pravidly projektu, projektový tým seznámen s rozsahem a základními parametry projektu (termín zahájení a termín dokončení, celkový rozpočet projektu apod.), projektový tým seznámen se všemi dostupnými informacemi týkajících se projektu včetně informací interních a neveřejných, projektový tým seznámen s termíny úkolů projektu, které bylo nutno v nejbližším období zrealizovat (úkoly byly následně přiděleny definovaným členům projektového týmu), definovanými osobami projektového týmu odsouhlasen a akceptován interní dokument START projektu, který je uveden v příloze č. 2. Po dokončení plánu projektu ve všech jeho částech (časový plán, plán zdrojů, plán nákladů, plán rizik a plán komunikace) bylo projektovým manažerem zorganizováno oficiální zahájení projektu za účasti zákazníka projektu (Kick-Off Day). Plánem tohoto oficiálního zahájení projektu bylo: seznámení obou projektových týmů s cíly projektu a metrikami hodnocení jejich splnění (rekapitulace závěrů dokumentu Předimplementační analýza), seznámení projektového týmu zákazníka projektu s organizací projektové dokumentace v písemné a elektronické podobě, seznámení projektového týmu zákazníka projektu s komunikačními pravidly projektu, seznámení projektového týmu zákazníka projektu s rozsahem a základními parametry projektu (termín zahájení a termín dokončení, celkový rozpočet projektu apod.), seznámení obou projektových týmů s harmonogramem projektu, který byl v rámci jednání oběma projektovými týmy odsouhlasen a akceptován. Průběh plánování projektu, který předcházel oficiálnímu zahájení projektu za účasti zákazníka projektu, je popsán v následující kapitole.

39 Využití projektového řízení při implementaci IS/ICT v podniku Plánování projektu Plánování projektu je procesem následujícím po procesu inicializace a zahájení projektu. Při plánování projektu byli do procesu zapojeni všichni členové projektového týmu. Plánování projektu probíhalo pro všechny tři základny projektového managementu a plány navzájem tvořily jeden logický a integritní celek. Postupně vznikly následující plány: časový plán projektu (harmonogram projektu), plán zdrojů projektu, plán nákladů projektu (rozpočet projektu), plán rizik a rezerv projektu a plán komunikace projektu. V následujících kapitolách budou jednotlivé plány popsány podrobněji Časový plán projektu (harmonogram projektu) Pro možné sestavení harmonogramu projektu bylo nutné projektovým manažerem a celým projektovým týmem sestavit hierarchickou strukturu činností (WBS) projektu. Celý rozsah produktu projektu podrobně definoval dokument Předimplementační analýza, ze kterého se při tvorbě hierarchické struktury činností projektu vycházelo. Rozsah produktu projektu byl rozdělen do jednotlivých oblastí (ekonomika, logistika apod.) a následně každá oblast byla rozdělena do jednotlivých činností, které byly již dále nedělitelné. Časová náročnost realizace standardizovaných činností projektu byla stanovena metodou odhadu vycházející ze zkušeností z jiných projektů. Takto byla stanovena časová náročnost realizace činností následujících oblastí: instalace a konfigurace databázového serveru a informačního systému, nastavení všech definovaných modulů IS, převody dat, školení všech definovaných modulů IS, asistence testovacího a ostrého provozu. Časová náročnost realizace zakázkových programových úprav projektu byla stanovena metodou parametrického odhadu, který vycházel z rozsahu uvedeného v dokumentu Předimplementační analýza. Takto byla stanovena časová náročnost realizace činností následujících oblastí: zakázkové programové úpravy následujících standardních modulů informačního systému: organizace, skladové jádro, objednávky, odbyt, fakturace a personalistika, zakázkový vývoj řešení docházkového systému, zakázkový vývoj řešení propojení informačního systému s externí aplikací logistiky Dispatcher. Vytvořená hierarchická struktura činností projektu (WBS) byla třívrstvá a umožňovala efektivně plánovat ve všech oblastech projektového managementu a následně i v průběhu realizace kontrolovat aktuální stav projektu s jeho plánem. Výsledná hierarchická struktura činností (WBS) projektu je uvedena v příloze C Příloha C zobrazuje podrobnou hierarchickou strukturu činností projektu doplněnou o další údaje: termín zahájení, termín dokončení a název alokovaného zdroje pro realizaci každé činnosti.

40 Využití projektového řízení při implementaci IS/ICT v podniku 40 Současně byly projektovým manažerem definovány všechny milníky projektu, které měly vysokou závaznost. Při plánování harmonogramu projektu, ale i plánování zdrojů a rizik projektu, byly respektovány takto stanovené milníky projektu. Seznam všech vytvořených milníků projektu je zobrazen na obrázku 13. Obr. 13: Milníky projektu Seskupením jednotlivých činností hierarchické struktury činností (WBS) projektu vznikl rámcový harmonogram projektu, který je zobrazen na obrázku 14. Tento rámcový harmonogram projektu byl přílohou smluvních dokumentů mezi sponzorem projektu a dodavatelem projektu. Výsledný harmonogram projektu obsahoval detailní časový plán všech činností projektu a je uveden v příloze C.

41 Využití projektového řízení při implementaci IS/ICT v podniku 41 Obr. 14: Rámcový harmonogram projektu V průběhu plánování harmonogramu projektu docházelo k jeho časté optimalizaci. Při optimalizaci byly vyhledány činnosti na kritické cestě a došlo k rozdělení plánovaných činností na činnosti paralelně běžící s menším rozsahem (hlavně části vyvíjené programátory projektového týmu). Další možností, která byla při optimalizaci harmonogramu projektu využita, bylo přehodnocení kalkulací časů potřebných k realizaci některých činností hierarchické struktury činností projektu. Výsledkem těchto opakujících se postupů bylo vytvoření optimalizovaného harmonogramu projektu. Část síťového diagramu zobrazeného v aplikaci Microsoft Project 2007 projektu včetně části kritické cesty projektu je zobrazena na obrázku 15.

42 Využití projektového řízení při implementaci IS/ICT v podniku 42 Obr. 15: Část síťového diagramu se zobrazením části kritické cesty projektu Plán zdrojů projektu Dalším krokem při plánování projektu bylo vytvoření plánu zdrojů projektu. Před sestavením plánu zdrojů projektu byla vytvořena matice odpovědností, při jejíž tvorbě se vycházelo z organizační struktury projektu a kvalifikačních předpokladů jednotlivých zdrojů projektu. Z matice odpovědností vyplývalo, který zdroj projektu odpovídá za splnění každé činnosti hierarchické struktury činností (WBS) projektu. Z matice odpovědností současně vyplývalo, které zdroje projektu spolupracují na splnění každé projektu. Část matice odpovědnosti projektu vytvořená v této fázi plánování projektu je zobrazena na obrázku 16.

43 Využití projektového řízení při implementaci IS/ICT v podniku 43 Obr. 16: Část matice odpovědností projektu 32 Při tvorbě plánu zdrojů projektu se vycházelo z organizační struktury projektu, hierarchické struktury činností (WBS) projektu, připravené matice odpovědností a pracovních kalendářů jednotlivých zdrojů. Výsledkem plánování zdrojů projektu byla alokace jednotlivých zdrojů projektu jednotlivým činnostem projektu jeho hierarchické struktury činností (WBS) projektu. V příloze C je zobrazen harmonogram projektu zobrazující výsledný časový plán včetně alokovaných zdrojů k realizaci všech definovaných činností projektu. Současně vytvořením plánu zdrojů projektu způsobilo aktualizaci pracovních kalendářů všech alokovaných zdrojů projektu. Detail pracovního kalendáře zdroje Konzultant E (konzultant ekonomiky) je zobrazen na obrázku S spolupracuje, O odpovídá.

44 Využití projektového řízení při implementaci IS/ICT v podniku 44 Obr. 17: Detail pracovního kalendáře pracovníka Konzultant E projektu Při vytváření plánu zdrojů projektu docházelo k jeho průběžné optimalizaci. Při optimalizaci byly formou histogramů kapacitního vytížení vyhledány činnosti způsobující přetížení kapacit alokovaných zdrojů a tato přetížení byla vyřešena. Výsledkem bylo vytvoření optimalizovaného plánu zdrojů projektu. Část kalendáře prací zdrojů sumarizující všechny detailní kalendáře všech zdrojů projektu je zobrazena v příloze D Plán nákladů projektu Dalším krokem při plánování projektu bylo vytvoření plánu nákladů projektu. Náklady projektu se skládaly z následujících druhů nákladů: přímé náklady byly náklady přímo zatěžující projekt (náklady na práci, cestovné a ubytování), nepřímé (režijní) náklady nebyly v projektu kalkulovány, neboť přímé náklady na práci každého zdroje projektu byly již navýšeny o koeficienty nákladů na režijní mzdové náklady a na provoz společnosti dodavatele projektu, ostatní náklady byly mimořádné náklady projektu (rezerva pro krytí rizik projektu). Pro kalkulaci nákladů projektu byly dodavatelem projektu definovány nákladové hodinové sazby každého alokovaného zdroje projektu. Takto definované sazby jsou zobrazeny na obrázku 18.

45 Využití projektového řízení při implementaci IS/ICT v podniku 45 Obr. 18: Sazby zdrojů projektu Kalkulace hodnot přímých a nepřímých nákladů (jsou součástí přímých nákladů) vycházela z rozsahu definované hierarchické struktury činností (WBS) projektu a definovaných nákladových sazeb každého alokovaného zdroje projektu. Dalšími přímými náklady projektu bylo cestovné v sazbě 5,50 Kč á 1 km a při vzdálenosti 400 km tam i zpět byly výsledné náklady na cestu ve výši 2.200,- Kč. Posledním přímým nákladem projektu bylo ubytování v ceně 1.100,- Kč za noc. Výsledné seskupené přímé a nepřímé náklady projektu jsou zobrazeny na obrázku č. 19, ze kterého vyplývají celkové plánované náklady na projekt ve výši ,- Kč ( ,- Kč za přímé a nepřímé náklady pracovních zdrojů, ,- Kč za přímé náklady cestovného a ,- Kč za přímé náklady ubytování). Obr. 19: Seskupené náklady projektu Výsledný podrobný plán nákladů projektu byl vytvořen jak v hodinách, tak i v Kč a je zobrazen v příloze E. Součástí plánu nákladů projektu byl také plán cash-flow projektu, který byl vytvořen z příjmových a výdajových finančních toků v závislosti na časové ose.

46 Využití projektového řízení při implementaci IS/ICT v podniku Plán řízení rizik projektu Při plánování projektu byly současně identifikovány následující rizika a jejich hodnoty, které navýšily celkový rozpočet projektu o ,- Kč. Plán rizik byl definován formou tabulky, která je uvedena na obrázku 20. Pro každé riziko vyplývalo: popis popis možného rizika, maximální částka v ohrožení náklady způsobené vznikem rizika, pravděpodobnost pravděpodobnost výskytu rizika, závažnost závažnost výskytu rizika, redukce / optimalizace popisuje možnou eliminaci či optimalizaci výskytu rizika, transfer popisuje formu přenosu rizika na jiný subjekt, očekávaná hodnota rizika je dána kalkulací maximální částky v ohrožení a pravděpodobnosti výskytu rizika a definuje výslednou částku nutnou k zohlednění v plánu rizik projektu Plán komunikace projektu Obr. 20: Plán rizik projektu Poslední částí při plánování projektu bylo vytvoření plánu komunikace projektu. Komunikační plán projektu určoval níže uvedené části: definice informací, které budou sdíleny, cíle sdílení daných informací, periodicita jednotlivých informací, odpovědnost za distribuci daných informací, adresáti daných informací, forma distribuce daných informací. Plán řízení komunikace projektu byl definován formou tabulky. Část komunikačního plánu projektu je zobrazen na obrázku č. 21). Podle potřeb komunikačního plánu a dle zakládajícího dokumentu projektu byly vytvořeny šablony jednotlivých dokumentů a

47 Využití projektového řízení při implementaci IS/ICT v podniku 47 formulářů distribuce určených informací. Z důvodů rozsahu této práce nejsou takto připravené šablony dokumentu a formuláře distribuce určených informací uvedeny v příloze této práce. Obr. 21: Část plánu řízení komunikace projektu 3.3 Realizace a koordinace projektu IS/ICT Vlastní řízení v průběhu realizace a koordinace projektu bylo souhrnem aktivit, které byly zaměřeny na výkon, časování a sladění plánovaných prací dle harmonogramu projektu uvedeného v příloze C. Součástí těchto aktivit byla také probíhající projektová komunikace, motivace členů projektového týmu a evidence projektové dokumentace v papírové i elektronické podobě. Při realizaci projektový manažer koordinoval realizaci plánovaných úkolů, jejichž souhrnná část je zobrazena na obrázku 22.

48 Využití projektového řízení při implementaci IS/ICT v podniku 48 Obr. 22: Část souhrnu jednotlivých úkolů projektu Každý člen projektového týmu řešil úkoly v pořadí vycházející z logických vazeb hierarchické struktury činností (WBS) projektu zohledněných v harmonogramu projektu. Seznam všech úkolů k řešení každého člena projektového týmu definoval jeho pracovní kalendář, podle kterého definované úkoly realizoval. Realizace jednotlivých úkolů byla jednotlivými členy projektového týmu průběžně odváděna prostřednictvím výkazů práce. Tímto docházelo k aktualizaci následujících informací: skutečná odpracovaná doby na realizaci jednotlivých úkolů, stav realizace jednotlivých úkolů a její dokončenost v procentech, odchylky vůči harmonogramu projektu, výše skutečných nákladů projektu, další důležité informace pro řízení projektu. Při realizaci a koordinaci projektu byla klíčovou částí projektová komunikace. Představovala vazbu mezi členy obou projektových týmů (zákazníka i dodavatele) a projektového týmu navzájem a byla hybnou silou projektu. Většina odpovědnosti za

49 Využití projektového řízení při implementaci IS/ICT v podniku 49 budování a posilování komunikačních kanálů byla na bedrech projektového manažera. Komunikační informace byly obsahově zaměřeny na: řízení projektu koordinace, řízení a kontrola projektu, hlášení o stavu projektu, vedení, týmová spolupráce a motivace, řízení produktu projektu distribuce a sdílení informací, podkladů, zadání, vysvětlení k zadání, pokynů a know-how řešení. 3.4 Monitorování a kontrola projektu IS/ICT Proces monitorování a kontrola projektu byl souhrnem aktivit, které byly zaměřeny na zjištění souladu realizovaných položek projektu s plánem projektu, a to z pohledu rozsahu, času, nákladů, kvality a rizik projektu. Monitorování a kontrola projektu probíhala v opakujících se činnostech: sběr informací o stavu realizovaných úkolů projektu, vyhodnocení vzhledem k aktuálnímu plánu projektu, distribuce zjištěných informací pro všechny zájmové skupiny projektu. Pokud byly při monitorování a kontrole zjištěny odchylky proti platné verzi plánu projektu, došlo k vyhodnocení vzniklého stavu a následně k doporučení nápravného postupu. Součástí procesu monitorování a kontrola projektu bylo také monitorování a kontrola rizik. V případě výskytu rizika projektu byl přijat návrh takového korektivního opatření, které snížilo pravděpodobnost vývoje rizikového stavu, nebo snížilo závažnost jeho případného dopadu. Další důležitou částí procesu monitorování a kontrola projektu bylo řízení změn projektu ve všech oblastech, hlavně v oblasti změn produktu projektu. Kontrola okamžitého stavu projektu proti jeho plánu a korekce případných odchylek byla hlavní metodou monitorování a kontroly projektu. Systém kontroly zajistil kontrolu projektu z pohledu: produktu projektu, harmonogramu projektu, rozpočtu projektu, ostatních částí projektu, hlavně pak rizik a kvality projektu. Kontrolní systém dával projektovému týmu zpětnou vazbu o kvalitě procesu plánování projektu, generoval podklady pro proces rozhodování, identifikoval odchylky skutečného stavu od plánovaného a vytvářel předpoklady, za kterých bylo možné projekt dokončit Kontrola produktu projektu Kontrola produktu projektu byla klíčovou aktivitou z pohledu postupného plnění dílčích cílů projektu. Tento proces vycházel z následujících podkladů: smlouva o dílo, definice produktu projektu (dokument Předimplementační analýzy), cíle a metriky jejich splnění, harmonogram projektu a seznam milníků projektu,

50 Využití projektového řízení při implementaci IS/ICT v podniku 50 podrobný rozpis úkolů projektu, seznam schválených a realizovaných změn produktu projektu, Kontrola harmonogramu projektu Kontrola harmonogramu projektu zjišťovala, zda realizace projektu probíhala v souladu s harmonogramem projektu. Tento proces vycházel z následujících podkladů: smlouva o dílo, harmonogram projektu a seznam milníků projektu, podrobný rozpis úkolů projektu, seznam schválených a realizovaných změn produktu projektu, Kontrola nákladů projektu Kontrola nákladů projektu probíhala v pravidelném týdenním intervalu a zjišťovala, zda realizace projektu probíhala v souladu s rozpočtem projektu. Vycházela z faktu, že každý účastník projektového týmu průběžně vykazoval čas, který odpracoval v souvislosti s plněním definovaných úkolů projektu. Stejně tak i ostatní náklady, které byly průběžně čerpány, byly průběžně zaznamenávány a následně kontrolovány vzhledem k plánovanému rozpočtu projektu. Proces vycházel z následujících podkladů: aktuální stav nákladů v účetnictví, cash-flow projektu, stav rozpracovanosti dílčích částí projektu, Kontrola nákladů projektu je jednou z nejobtížnějších částí kontrol projektu projektového manažera. Často je doporučováno pravidelné sledování nákladů v nejdéle týdenních intervalech a pravidelné vyhodnocování případných odchylek. Pro správnou volbu korektivních akcí je nezbytně nutné zjištění důvodů a příčin vzniku této odchylky. Důležitou částí sledování a ovlivňování vývoje čerpání nákladů projektu jsou změnové požadavky, které mohou být důvodem k změně rozpočtu projektu s vlivem na cenu projektu. Právě změny v průběhu realizace implementace projektů IS/ICT jsou zcela běžné a proto musí být projektovým manažerem pečlivě sledovány Kontrola rizik projektu Základním předpokladem řízení a kontroly rizik byla existence plánu rizik. Monitorování a kontrola rizik byla zaměřena na stavy a jevy, které byly pro projekt nežádoucí. Projektový manažer pravidelně sledoval stavy, jevy a trendy, které mohly indikovat vznik rizikového stavu projektu, a to u vnitřních procesů projektu i mimo něj. Projektový manažer současně sledoval a kontroloval procesy, které souvisely s potencionálními riziky, hodnotil všechny odchylky mezi plánem projektu a skutečným stavem projektu z pohledu jejich vztahu k definovaným rizikům. Při zjištění možných impulsů by byl projektový manažer povinen iniciovat takové akce a kroky, které by riziko minimalizovalo nebo minimalizovalo dopady daného rizika. Zkušenosti projektového manažera mohou pomoci k zachycení vzniku dalšího, do té doby neidentifikovatelného rizika.

51 Využití projektového řízení při implementaci IS/ICT v podniku Kontrola kvality projektu Kontrola kvality projektu probíhala ve dvou základních oblastech: kontrola kvality procesů porovnání s plánem kvality, které by v případě nežádoucích odchylek spouštěl korekční opatření, kontrola kvality výstupů projektu porovnání výsledků dílčích částí projektu s metrikami akceptovatelnosti, které by v případě nežádoucích odchylek opět spouštěly korekční opatření. Kontrola kvality procesů je obvykle realizována mimo aktuální projekt v rámci procesů společnosti dodavatele, nicméně kontrola kvality výstupů projektu byla zcela v režii pracovního týmu projektu. Projekt byl realizován se splněním cílů projektu a jejich splnění bylo kvantifikováno dle dohodnutých metrik akceptace definovaných cílů. 3.5 Uzavření projektu Proces uzavření projektu byl vyvrcholením celého projektového řízení a tento proces představoval: ukončení všech běžících procesů projektového řízení, předání všech výstupů projektu a formální uzavření kontraktu z pohledu produktu projektu, uvolnění alokovaných pracovních zdrojů, ukončení používání všech materiálních a ostatních zdrojů, účetní vyrovnání projektu, vyhodnocení celého projektu, zpracování všech nových zkušeností a dosažených výsledků projektu do hodnotících dokumentů, archivace dokumentace projektu. Proces uzavření kontraktu zahrnoval všechny činnosti spojené s vypořádáním výstupů projektu a jejich akceptací, závěrečnou fakturací projektu a převedením projektu do jeho další fáze, z pohledu dodavatele projektu do jeho servisní podpory Závěrečná akceptace projektu Obsahem této části bylo schválení výstupů projektu zákazníkem projektu. Akceptace produktu projektu zákazníkem projektu proběhla bez jakýchkoliv výhrad Uzavření projektu Formální uzavření projektu probíhalo v následujícím sledu činností: vytvoření závěrečných a hodnotících interních dokumentů, hodnocení individuálních výkonů členů projektového týmu, administrativní uzavření projektu.

52 Využití projektového řízení při implementaci IS/ICT v podniku 52 4 Závěr a diskuse Cílem této práce, který je popsaný v první kapitole, bylo vytvoření metodiky projektového řízení projektů IS/ICT v podniku. Tento cíl byl prací splněn. Metodika řízení projektů IS/ICT je podporou manažerům projektů při řízení projektu a je využitelná jak pro menší, tak i pro větší projekty implementace IS/ICT. Tato metodika byla v části vlastní práce aplikována při řízení projektu implementace informačního systému KARAT v akciové společnosti Lesaffre Česko, a.s. Druhá kapitola je popisem současného stavu a je souhrnem nastudované literatury oblasti projektového managementu. V úvodu jsou popsány základní principy projektů a projektového řízení, výhody a nevýhody možných organizačních struktur řízení a používané modely životního cyklu projektu. Největší část této kapitoly je věnována procesům projektu implementace IS/ICT v podniku, a to od výběru dodavatele projektu, přes inicializaci a zahájení projektu, plánování projektu, realizaci a koordinaci projektu až po jeho uzavření. V poslední části této kapitoly jsou popsány metodické standardy projektového řízení, kterou jsou v dnešní době často používány. Další kapitola je vlastní práce a popisuje využití metodiky projektového řízení při implementaci informačního systému projektu v podniku Lesaffre Česko, a.s. V úvodu této kapitoly jsou popisovány všechny činnosti související s inicializací a zahájením projektu. Zde je zdůrazněna důležitost správné definice cílů projektu a metrik jejich splnění. Současně tato část podrobně popisuje důležité dokumenty projektové dokumentace, kterými jsou Zakládající dokument projektu, Definice produktu projektu a dokument START projektu. Plánování projektu bylo realizováno v postupných krocích uvedených v této práci. Bylo ověřeno, že tato sekvence tvorby jednotlivých plánů je pro plánování projektů IS/ICT logická a optimální. Klíčovou stránkou plánování byla definice hierarchické struktury činností projektu, stanovení jejich vzájemných vazeb a časové náročnosti jejich realizace. Použitá třívrstvá hierarchická struktura činností projektu umožnila jak detailní a přehledné plánování projektu, tak i jeho následnou realizaci, koordinaci, monitorování a kontrolu. Po určení klíčových milníků projektu byl následně vytvořen podrobný časový plán projektu (harmonogramu projektu). Plánování pokračovalo vytvořením plánu kapacit projektu. Pak již bylo možné hodnotit reálnost plánu projektu a stanovit jeho úzká místa. Další etapou plánování projektu bylo vytvoření finančních plánů projektu, kterými byly plán nákladů, plán výnosů a plán cash-flow. Důležitou a často na projektech IS/ICT opomíjenou částí plánů projektu, byla definice plánu rizik a jejich finančních dopadů na projekt. Poslední částí plánování bylo vytvoření plánu projektové komunikace. Ta je klíčovou pro úspěšné dokončení projektu a již ve fázi inicializace a zahájení projektu byla definována její pravidla, kterými se v průběhu projektu oba projektové týmy řídily. Při realizaci a koordinaci projektu se vycházelo z jednotlivých plánů projektu. Jakékoliv odchylky skutečnosti a plánu byly průběžně sledovány a vyhodnocovány. Nejčastějšími změnami vůči jednotlivým plánům projektu byly změny v časovém a kapacitním plánu projektu a v plánu produktu projektu formou požadavků na změnu produktu projektu. Přesná a podrobná definice dokumentu Definice produktu projektu

53 Využití projektového řízení při implementaci IS/ICT v podniku 53 se ukázala v průběhu realizace projektu jako klíčová a byla základní oporou při rozhodování u jakéhokoliv požadavku zákazníka projektu, zda je nebo není tento požadavek předmětem realizovaného projektu. Realizace implementace projektu IS/ICT byla na závěr formálně ukončena s výslednými vyhodnoceními všech sledovaných parametrů projektu. Projektové řízení implementací projektů IS/ICT bylo celou částí vlastní práce prezentováno prostřednictvím výstupů z aplikace pro podporu projektového řízení Microsoft Project Tato aplikace nabízí velké množství typů výstupních sestav, které jsou pro úspěšné řízení projektů nezbytné. Důležitou podmínkou je samozřejmě reálnost a aktuálnost dat informující o stavu rozpracovanosti projektu, které probíhalo v pravidelných časových intervalech. Zde se ukázala oblast možného zlepšení ve formě automatizace aktualizace stavu rozpracovanosti projektu v této aplikaci. Poslední pátá kapitola definuje použitou literaturu a literaturu doporučenou pro její související obsah s touto prací. V přílohách jsou uvedeny obsáhlejší dokumenty a obrazové přílohy metodiky projektového řízení při implementaci IS/ICT v podniku. Každý ukončený projekt zvyšuje know-how dodavatele projektu, ať už je projekt ukončený úspěšně, ukončený s výhradami zákazníka projektu nebo je projekt ukončený neúspěšně. Z pohledu vlastního rozvoje projektového řízení navrhuji vytvoření dokumentu Poučení z realizace projektu, který by obsahoval hodnocení naplnění cílů projektu, porovnání plánovaných a skutečně dosažených hodnot všech měřitelných výsledků projektu, rekapitulace změn předmětu projektu, naplnění plánu kvality, naplnění plánu řízení rizik a další. Současně se při praktickém využití metodiky projektového řízení při implementacích IS/ICT v podniku ukázaly další potřeby rozvoje připravené metodiky, a to hlavně v následujících oblastech: metodika detailní implementace konkrétního produktu IS/ICT, metodika školení produktu projektu, metodika komunikace s třetími stranami řešící subdodávky projektu, vytvoření znalostní databáze všech problémů projektu a jejich způsobů řešení, vytvoření znalostní databáze řešení jednotlivých zákazníků. Nabízí se zpracování výše uvedených oblastí, které by mohly navazovat na tuto práci.

54 Využití projektového řízení při implementaci IS/ICT v podniku 54 5 Literatura 5.1 Použité zdroje [1] DORAN, George. There s a S.M.A.R.T. Way to Write Management Goals and Objectives, First Edition, Management Review, 1981 [2] DOUCEK, Petr. Řízení projektů informačních systémů. Druhé vydání, Praha, Proffesional Publishing, 2006, ISBN [3] FIALA, Petr. Řízení projektů. První vydání, Praha, Ediční oddělení VŠE Praha, 2002, ISBN [4] HYNDRÁK, Karel. Vytváříme projekty v programu Microsoft Project První vydání, Praha, Computer Press, 2000, ISBN [5] KALIŠ, Jan. Řídíme projekty s Microsoft Project První vydání, Praha, Computer Press, 2002, ISBN [6] KERZNER, Harold. Project Management, A Systems Approach to Planning, Scheduling, and Controlling, Sixth Edition, New York, Willey & Sons, 1998 [7] MOOZ, Hal, FORSBERG, Kevin, COTTERMAN Howard. Communication Project Management, First Edition, New Jersey, Willey & Sons, 2003 [8] ROSENAU, Milton D. Řízení projektů. První vydání, Praha, Computer Press, 2000, ISBN [9] SVATÁ, Vlasta. Projektové řízení v podmínkách ERP systémů. První vydání, Praha, Vysoká škola ekonomická, 2002, ISBN [10] SVOZILOVÁ, Alena. Projektový management. První vydání, Praha, Grada Publishing, 2006, ISBN [11] ŠUBRT, Tomáš, LANGROVÁ, Pavlína. Systémová podpora projektů. První vydání, Praha, Česká zemědělská univerzita v Praze, 2003, ISBN [11] VYTLAČIL, Dalibor. Manažerské informační systémy 30: projektové řízení a řízení projektů. První vydání, Praha, České vysoké učení technické v Praze, 2001, ISBN Doporučená literatura [12] ADAMEC, František. Řízení projektů pomocí Microsoft Project První vydání, Praha, Grada Publishing, 2001, ISBN [13] HOLOUBEK, Josef. Ekonomicko-matematické metody. První vydání, Brno, Mendelova zemědělská a lesnická univerzita, 2006, ISBN [14] MOLNÁR, Zdeněk. Efektivnost informačních systémů. Druhé vydání, Praha, Grada Publishing, 2001, ISBN [15] MOTYČKA, Arnošt. E-technologie a konkurenceschopnost podniku. Sborník přednášek konference Internet a konkurenceschopnost podniku, Zlín, Academia Centrum, 2002, ISBN X [16] NĚMEC, Vladimír. Projektový management. První vydání, Praha, Grada Publishing, 2002, ISBN

55 Využití projektového řízení při implementaci IS/ICT v podniku 55 [17] ŠUBRT, Tomáš, LANGROVÁ, Pavlína. Projektové řízení I. (základy a matematické metody). První vydání, Praha, Česká zemědělská univerzita v Praze, 2004, ISBN [18] TVRDÍKOVÁ, Milena. Zavádění a inovace informačních systémů ve firmách. První vydání, Praha, Grada Publishing, 2000, ISBN [19] UČEŇ, Pavel. Metriky v informatice. První vydání, Praha, Grada Publishing, 2001, ISBN

56 Využití projektového řízení při implementaci IS/ICT v podniku 56 Přílohy

57 Využití projektového řízení při implementaci IS/ICT v podniku 57 A Zakládající dokument projektu Základní identifikace projektu Název projektu: D-LESAF-002 Cíle projektu a metriky jejich hodnocení Ze strany dodavatele je cílem tohoto projektu realizace Předimplementační analýzy a implementace IS v podniku Lesaffre Česko, a.s. Ze strany zákazníka jsou definovány následující cíle implementace IS 33 : Začátek projektu: Konec projektu: V důsledku rozsahu práce je uveden pouze příklad stanovených cílů, kterých zákazník projektu definoval několik desítek.

58 Využití projektového řízení při implementaci IS/ICT v podniku 58 Organizační struktura projektu Organizační struktura projektu předimplementační analýzy a implementace IS je stanovena podle tohoto dokumentu a je pro dodavatele a zákazníka závazná. Řídící tým projektu Ředitel projektu za Zhotovitele Ředitel projektu za Objednatele Vedoucí projektu za Zhotovitele Vedoucí projektu za Objednatele Vedoucí pracovních týmů A.. Z za Zhotovitele Vedoucí pracovních týmů A.. Z za Objednatele Členové pracovních týmů A.. Z za Zhotovitele Členové pracovních týmů A.. Z za Objednatele Výkonný tým projektu Změnová komise Vedoucí Změnové komise Člen Změnové komise za Zhotovitele Členové Změnové komise za Objednatele Definice odpovědností osob projektu Ředitel projektu informuje statutární orgány společnosti o průběhu projektu, je odpovědný statutárním orgánům společnosti za průběh a úspěšné ukončení projektu, je odpovědný za projekt jako celek, zodpovídá za zajišťování zdrojů (finančních, informačních, technických, organizačních a personálních), je odpovědný za předání a převzetí plnění díla dle definované smlouvy a její případných příloh, svým podpisem potvrzuje předání jednotlivých plnění díla. Vedoucí projektu je odpovědný za průběh řízení projektu implementace IS jako celku, je odpovědný za dodržování projektové metodiky a definice díla dle smlouvy o dílo, je povinen průběžně sledovat a kontrolovat čerpání nákladů,

59 Využití projektového řízení při implementaci IS/ICT v podniku 59 je odpovědný za dodržování harmonogramu projektu, je odpovědný za generování, kompletaci a archivaci projektové dokumentace a dodržování její formální a obsahové úrovně, je odpovědný za vypracování zpráv o průběhu realizace projektu, informuje ředitele projektu o průběhu projektu, zodpovídá za zajišťování zdrojů (informačních, technických, organizačních a personálních), je odpovědný za předání částí plnění dle definované smlouvy a její případných příloh, svým podpisem potvrzuje předání jednotlivých plnění díla, je odpovědný za celkové řešení dle definované smlouvy a její případných příloh, a to za úplnost a věcnou správnost realizace řešení implementace IS, je odpovědný za včasné, úplné a věcně správné vyhotovení plnění požadavků potřebných k realizaci plnění díla. Vedoucí pracovního týmu je odpovědný za průběh řízení projektu v zastřešujících funkčních oblastech projektu, zodpovídá za zajišťování zdrojů (organizačních a personálních), informuje vedoucího projektu o průběhu projektu, je odpovědný za dodržování metodiky implementace, je odpovědný za dodržování harmonogramu projektu, je odpovědný za generování projektové dokumentace a dodržování její formální a obsahové úrovně, je odpovědný za zastřešující část řešení dle definované smlouvy a její případných příloh, a to za úplnost a věcnou správnost realizace řešení implementace IS, je odpovědný za včasné, úplné a věcně správné vyhotovení plnění požadavků potřebných k realizaci zastřešující části plnění díla. Člen pracovního týmu informuje vedoucího pracovního týmu o průběhu projektu, je odpovědný za dodržování metodiky implementace, je odpovědný za dodržování harmonogramu projektu, je odpovědný za generování projektové dokumentace a dodržování její formální a obsahové úrovně, je odpovědný za včasné, úplné a věcně správné vyhotovení plnění požadavků potřebných k realizaci zastřešující části plnění díla. Vedoucí změnové komise je povinen shromáždit všechny potřebné podklady pro řešení požadavku a projednat předložený návrh změny v co nejkratším možném termínu, zodpovídá za věcnou správnost předávaných dat dodavateli, je odpovědný za generování, kompletaci a archivaci projektové dokumentace a dodržování její formální a obsahové úrovně. Člen změnové komise

60 Využití projektového řízení při implementaci IS/ICT v podniku 60 informuje vedoucího projektu o průběhu změnového řízení projektu, je odpovědný za generování, kompletaci a archivaci projektové dokumentace a dodržování její formální a obsahové úrovně, je odpovědný za včasné, úplné a věcně správné předání všech požadavků na změnu vedoucímu projektu. Definice pravomocí osob projektu Ředitel projektu má rozhodovací pravomoc pro realizaci projektu, má právo odvolávat členy projektového týmu, rozhoduje o strategických postupech, které ovlivní úspěšné ukončení projektu, rozhoduje o řešení konfliktů a věcných výjimek, je oprávněn k podpisu dokladující předání plnění dle smlouvy, ve spolupráci s vedoucím projektu provádí kontrolu plnění úkolů podle harmonogramu projektu, je nadřízen vedoucímu projektu a je oprávněn od něho požadovat detailní informace o průběhu prací na projektu, ve spolupráci s ředitelem projektu druhé strany se podílí na kontrole prací na projektu a na činnosti řídicího týmu projektu, poskytuje rady a pomoc výkonnému týmu projektu, je oprávněn k podpisu výkazů práce pracovníkům Dodavatele, není-li definováno jinak. Vedoucí projektu rozhoduje o operativních postupech, které ovlivní úspěšné ukončení projektu, schvaluje změny (pokud nemají vliv na celkový časový plán nebo náklady projektu), je oprávněn k podpisu dokladující předání částí plnění dle definované smlouvy a její případných příloh, je v pravidelném kontaktu s ředitelem projektu a konzultuje s ním: - věcný stav projektu, - dokumenty projektové dokumentace, jako jsou zprávy o průběhu projektu, zápisy z jednání apod., - řešení věcných problémů projektu, - změny projektu na základě podaných požadavků na změnu, - požadavky na zdroje, - postup prací vzhledem k harmonogramu projektu, - zajištění kvality prací projektu, - schvalování změn projektu, ve spolupráci s vedoucími pracovních týmů provádí kontrolu plnění úkolů podle harmonogramu projektu, navrhuje strategické postupy, které ovlivní úspěšné ukončení projektu, navrhuje řešení konfliktů a věcných výjimek, podílí se na schvalování změn (pokud nemají vliv na celkový časový plán nebo náklady projektu),

61 Využití projektového řízení při implementaci IS/ICT v podniku 61 je oprávněn k podpisu výkazu práce pracovníků dodavatele, není-li definováno jinak. Vedoucí pracovního týmu rozhoduje o dílčích částech operativních postupů, které ovlivní úspěšné ukončení projektu, schvaluje změny (pokud nemají vliv celkový časový plán nebo náklady projektu, je oprávněn k podpisu dokladující předání částí plnění dle definované smlouvy a její případných příloh, je v pravidelném kontaktu s vedoucím projektu a konzultuje s ním: - věcný stav projektu, - řešení věcných problémů projektu, - změny projektu na základě podaných požadavků na změnu, - požadavky na zdroje, - postup prací vzhledem k harmonogramu projektu, - schvalování změn projektu, navrhuje operativní postupy, které ovlivní úspěšné ukončení projektu, navrhuje řešení konfliktů a věcných výjimek, podílí se na schvalování změn (pokud nemají vliv na celkový časový plán nebo náklady projektu). Člen pracovního týmu je v pravidelném kontaktu s vedoucím pracovního týmu a konzultuje s ním: - řešení věcných problémů projektu, - změny projektu na základě podaných požadavků na změnu, - požadavky na zdroje. Vedoucí změnové komise je oprávněn rozhodovat v souvislosti s navrhovanou změnou o posunu termínu řešení a výši případných dodatečných nákladů, jedná-li se o zásadní změnu, předkládá návrh řešení řediteli projektu, má právo si na jednání přizvat další pracovníky, je povinen shromáždit všechny potřebné podklady pro řešení požadavku a projednat návrh v co nejkratším možném termínu. Člen změnové komise je v pravidelném kontaktu s vedoucím změnové komise a konzultuje s ním změny projektu na základě podaných požadavků na změnu, má právo si na jednání přizvat další pracovníky. Dokumenty projektové dokumentace Akceptační protokol Dokument je dokladem akceptace dílčích částí či celého předmětu díla, které bylo dodavatelem předáno a zákazníkem převzato na základě předávacího protokolu. Akceptační protokol ukončuje proces akceptačního řízení. Není-li uvedeno jinak, je dokument podepsán řediteli projektu obou stran.

62 Využití projektového řízení při implementaci IS/ICT v podniku 62 Denní plán školení Dokument obsahuje podrobný časový, personální a obsahový denní plán školení (seznam školených částí IS a jeho jednotlivých funkčností). Současně slouží jako prezenční listina školených uživatelů zákazníka. Dokument je podepsán školitelem ze strany dodavatele a všemi školenými osobami ze strany zákazníka. Harmonogram projektu Dokument obsahuje podrobný časový, personální a obsahový průběh realizace projektu a je podepsán vedoucími projektu obou stran (popř. v případě zastoupení řediteli projektu). Požadavek na změnu Požadavek na změnu je používán jako podklad pro zahájení změnového řízení. Požadavek předkládá vedoucí změnové komise za zákazníka nebo vedoucí projektu za zákazníka pověřené osobě dodavatele (řediteli projektu, vedoucímu projektu či vedoucímu pracovního týmu za dodavatele). Dokument je podepsán vedoucím změnové komise za zákazníka, členem změnové komise za dodavatele a členy změnové komise za zákazníka zastřešující oblast daného požadavku. Reklamační protokol Reklamační protokol slouží k popisu závad (pokud se vyskytnou) po předání díla. Dokument je podepsán pověřenými osobami obou stran. Předávací protokol Předávací protokol je dokladem předání ze strany dodavatele a převzetí ze strany zákazníka dílčích částí či celého předmětu díla. Není-li stanoveno jinak, je dokument podepsán osobami v pozicích ředitel projektu a vedoucí projektu za obě strany. Předání dílčích částí či celého předmětu díla je následně podstoupeno akceptačnímu řízení. Test Zkušební test školených témat s uvedenými možnými odpověďmi (i více odpovědí je správných) je určený účastníkům školení a je používán pouze na základě požadavku zákazníka. Vyhodnocení lektora Dokument, který vyplňuje každý školený uživatel zákazníka po dokončení školení ze strany dodavatele za účelem zhodnocení průběhu školení. Dokument není anonymní. Výkaz o provedení práce Je vypracován vždy po každé odvedení práce projektu a podepsán pověřenou osobou ze strany zákazníka (vedoucí projektu, vedoucí pracovního týmu nebo jiná pověřená osoba). Tento dokument může být přílohou dokumentu Zápis z jednání nebo Zápis z řídícího/výkonného týmu projektu. Dokument je vždy podepsán všemi zúčastněnými ze strany dodavatele a jednou z pověřených osob ze strany zákazníka. Zápis z řídícího/výkonného týmu Dokument je vypracován při jednání dodavatele a zákazníka na úrovni řídícího týmu projektu. Jeho přílohou může být dokument Zpráva o průběhu projektu.

63 Využití projektového řízení při implementaci IS/ICT v podniku 63 Stručně a výstižně popisuje průběh jednání, eviduje projednávané otázky a definuje návrh řešení projednávaných otázek. Pokud jsou známy, obsahuje termíny řešení, pokud tomu tak není, obsahuje termíny, do kterých bude návrh řešení zaslán. Obsahuje doporučení či upozornění dodavatele zákazníki, stanoviska obou stran, odkazy na jiné již dříve uskutečněné jednání apod. Dokument je podepsán všemi zúčastněními ze strany dodavatele a ze strany zákazníka. Zápis z jednání Dokument je vypracován při každém jednání dodavatele Zákazníkam s výjimkou jednání řídícího/výkonného týmu a školení. Stručně a výstižně popisuje průběh jednání, eviduje projednávané otázky a definuje návrh řešení projednávaných otázek. Pokud jsou známy, obsahuje termíny řešení, pokud tomu tak není, obsahuje termíny, do kterých bude návrh řešení zaslán. Obsahuje doporučení dodavatele či upozornění vůči objednavateli, stanoviska obou stran, odkazy na jiné již dříve uskutečněné jednání apod. Tento dokument může být alternativně nahrazen dokumentem Výkaz práce. Zpráva o průběhu projektu Bude vypracována pro každý probíhající úkol podle harmonogramu projektu. Vypracuje ho vždy vedoucí projektu za dodavatele nebo jím pověřený člen pracovního týmu za dodavatele. Dokument je podepsán vedoucím projektu za dodavatele. Projektové týmy projektu Pracovní tým Ekonomika standardní centrální moduly IS (Organizace apod.), standardní účetní moduly IS (Účetnictví, Vnitřní doklady, Počáteční a závěrkové operace, Opakované účetní operace, Evidence a výkazy DPH, Účetní výkazy, Účetní kalkulace, Souhrnné hlášení, Konsolidace), standardní ekonomické moduly IS (Sekretářka, Saldokonto, Faktury přijaté, Příkazy k úhradě, Platební avíza, Kompenzace, Pokladna, Banka, Plán, Provozní Cash-flow, Platební karty, Manažer), standardní moduly Majetek, standardní mzdové moduly IS (Personalistika, Mzdy), zakázkové úpravy zákazníka výše uvedených oblastí. Pracovní tým Odbyt standardní skladové a odbytové moduly IS (Skladové jádro, Odbyt, Ceníky, Objednávky, Fakturace, Inventury, Exportní JSD, Paragonová pokladna, Servis, Zdroje, Půjčovna, Internetový obchod) ostatní standardní moduly IS (Workflow, Reklamace, Datové sklady, Archivace dat), zakázkové úpravy a zakázkové řešení zákazníka. Pracovní tým CRM standardní modul CRM, zakázkové úpravy a zakázkové řešení zákazníka (vazba na IP ústřednu apod.). Pracovní tým Komunikace datová komunikace KARAT Dispatcher,

64 Využití projektového řízení při implementaci IS/ICT v podniku 64 zakázkové úpravy a zakázkové řešení zákazníka (vazba komunikace na standardní moduly). Pracovní tým HW technické řešení serverů, technické řešení terminálového přístupu do IS, další technická specifika projektu. Delegování členů projektu Řídící tým projektu Řídící tým projektu dohlíží podle plánu řízení projektu implementace IS na průběh realizace projektu. Je řídící částí projektového týmu. Členem řídícího týmu projektu ze strany dodavatele je: Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Ředitel projektu Daniel Holec Komplexní řízení projektu Členem řídícího týmu projektu ze strany zákazníka je: Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Ředitel projektu Komplexní řízení projektu Výkonný tým projektu Výkonný tým projektu průběžně řídí realizaci projektu implementace IS a podává zprávy o průběhu projektu řídícímu týmu projektu. Členy výkonného týmu projektu ze strany dodavatele jsou: Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Vedoucí projektu Daniel Holec Všechny oblasti IS Vedoucí pracovního týmu Ekonomika Vedoucí pracovního týmu Odbyt Vedoucí pracovního týmu CRM Vedoucí pracovního týmu Komunikace Vedoucí pracovního týmu HW Konzultant E Konzultant O Konzultant S Konzultant S Technik IT Všechny oblasti účetnictví a ekonomiky, majetku a mezd IS Všechny oblasti skladů a odbytu IS, zakázkové funkčnosti této oblasti Všechny oblasti CRM Všechny oblasti komunikace IS externí aplikace (Dispatcher) Všechny oblasti technického řešení projektu Členy výkonného týmu projektu ze strany zákazníka jsou:

65 Využití projektového řízení při implementaci IS/ICT v podniku 65 Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Vedoucí projektu Vedoucí pracovního týmu Ekonomika Člen pracovního týmu Ekonomika Vedoucí pracovního týmu Odbyt Člen pracovního týmu Odbyt Vedoucí pracovního týmu CRM Člen pracovního týmu CRM Vedoucí pracovního týmu Komunikace Člen pracovního týmu Komunikace Vedoucí pracovního týmu HW Všechny oblasti IS Všechny oblasti účetnictví a ekonomiky, majetku a mezd IS Definované oblasti účetnictví a ekonomiky, majetku a mezd IS Všechny oblasti skladů a odbytu IS, zakázkové funkčnosti této oblasti Definované oblasti skladů a odbytu IS, zakázkové funkčnosti této oblasti Všechny oblasti CRM Definované oblasti CRM Všechny oblasti komunikace IS externí aplikace (Dispatcher) Definované oblasti komunikace IS externí aplikace (Dispatcher) Všechny oblasti technického řešení projektu Změnová komise Změnová komise koordinuje vznikající požadavky na změnu ze strany Zákazníka. Členem Změnové komise ze strany Dodavatele jsou: Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Člen Změnové komise Konzultant E Člen Změnové komise Konzultant O Člen Změnové komise Konzultant S Všechny oblasti účetnictví a ekonomiky, majetku a mezd IS Všechny oblasti skladů a odbytu IS, zakázkové funkčnosti této oblasti Všechny oblasti CRM a komunikace s externí aplikací Členy Změnové komise ze strany Zákazníka jsou: Pozice v týmu Jméno a příjmení Zastřešovaná oblast IS Vedoucí Změnové komise za Zákazníka Člen Změnové komise Všechny oblasti IS Všechny oblasti účetnictví a ekonomiky, majetku a mezd IS

66 Využití projektového řízení při implementaci IS/ICT v podniku 66 Člen Změnové komise Člen Změnové komise Všechny oblasti skladů a odbytu IS, zakázkové funkčnosti této oblasti Všechny oblasti CRM a komunikace s externí aplikací Rizika projektu Ze strany dodavatele byla definována následující rizika projektu: 1. Chybějící popis procesů společnosti zákazníka. 2. Outsourcing služeb IT zákazníka externí společností. 3. Požadavek nákupu vlastního HW. 4. Negativní přístup koncových uživatelů k implementaci IS. 5. Omezenost financování požadavků zákazníka nad rámec předmětu projektu. Ze strany dodavatele byla přijata následující opatření ke snížení výše uvedených rizik projektu: 1. Vedení zákazníka k implementaci obvyklých procesů ve společnostech stejného zaměření, pečlivá dokumentace rozhodnutí zákazníka o výběru z nabízených variant, minimalizace zakázkových úprav IS a maximalizace přizpůsobení se standardnímu řešení IS. 2. Definování kompetentní osoby zákazníka za jednání s externí společností, zajištění informování externí společnosti oblasti HW, plánování akcí HW s dostatečnou časovou rezervou. 3. Smluvní oddělení odpovědnosti za vady předmětu díla způsobené vlastním dodávaným HW. 4. Zajištění motivace koncových pracovníků zákazníka vedením společnosti zákazníka, zavedení testů po školení, plánování jednání s koncovými uživateli v průběhu projektu a sledování jejich postoje. 5. Minimalizace zakázkových úprav IS a maximalizace přizpůsobení se standardnímu řešení IS, pečlivá kalkulace požadavků na změnu, zajištění objednávky kompetentních osob projektového týmu zákazníka na případnou realizaci požadavků na změnu. Komunikační standardy projektu Základní prostředky externí komunikace projektu zahajovací schůzka projektu (tzv. Kick-Off day), horizontální komunikace mezi týmy dodavatele a zákazníka v rámci řídícího/výkonného týmu projektu, pravidelné kontrolní dny projektu za účasti členů řídícího týmu obou stran, pravidelné kontrolní dny projektu zúženého projektového týmu za účasti ředitelů a vedoucích projektu obou stran, pravidelní kontrolní dny projektu výkonného projektového týmu obou stran, pravidelné konzultační dny projektu za účasti vedoucích členů (vedoucí projektu a vedoucí projektových týmů) výkonného týmu obou stran, pravidelné konzultační dny jednotlivých pracovních týmů obou stran,

67 Využití projektového řízení při implementaci IS/ICT v podniku 67 jednání změnové komise, individuální jednání a setkání. Základní prostředky interní komunikace projektu vertikální komunikace mezi týmy dodavatele a zákazníka v rámci řídícího/výkonného týmu projektu, pravidelné kontrolní dny projektového týmu, konzultační a analytické porady projektových týmů. Základní nástroje komunikace projektu ová komunikace na centrální ovou projektovou adresu dodavatele lesaffre@karatsoftware.cz, ová komunikace na centrální ovou projektovou adresu zákazníka karat@lesaffre.cz, telefonická komunikace na mobilní nebo pevné telefonní čísla uvedená u každého člena projektového týmu dodavatele a zákazníka, projektová jednání. Kompetentní osoby zákazníka k podpisu výkazů práce Ředitel projektu zákazníka, Vedoucí projektu zákazníka Zúčastněné strany se zavazují dodržovat ustanovení tohoto dokumentu. V Přerově, dne 1. května 2007 Za zákazníka: Pozice v týmu Jméno a příjmení Podpis Ředitel projektu Daniel Holec Za dodavatele: Pozice v týmu Jméno a příjmení Podpis Ředitel projektu

68 Využití projektového řízení při implementaci IS/ICT v podniku 68 B Dokument START projektu Základní identifikace projektu Název projektu: D-LESAF-002 Zákazník projektu: Lesaffre Česko, a.s. Cíle projektu a metriky jejich hodnocení: cíle uvedené v Zakládajícím dokumentu projektu Interní objednatel projektu Obchodní ředitel: Branislav Ludva Obchodní manažer: Marcel Herman Podpis: Podpis: Interní zhotovitel projektu Ředitel projektu: Daniel Holec Podpis: Vedoucí projektu: Daniel Holec Podpis: Definice projektu Produkt projektu je definován dokumentem Předimplementační analýza, která je přílohou tohoto dokumentu. Začátek projektu Konec projektu Rozpočet projektu Analýza Vývoj řešení Implementace hodin 244 hodin 252 hodin Definice šanonu projektové dokumentace Definice struktury veřejných složek Definice přístupových práv veřejných složek Název ové skupiny projektového týmu Název ové adresy projektového týmu Ano / Ne Ano / Ne Ano / Ne lesaffre lesaffre@kara tsoftware.cz Tímto je projekt schválen a připraven k realizaci. Projekt bude veden projektovým řízením a dokumentován dle metodiky implementace KARAT. Datum: 1. červen 2007

69 Využití projektového řízení při implementaci IS/ICT v podniku 69 C Harmonogram projektu Pokračování

70 Využití projektového řízení při implementaci IS/ICT v podniku 70

71 Využití projektového řízení při implementaci IS/ICT v podniku 71 D Kalendář prací zdrojů projektu Pokračování

72 Využití projektového řízení při implementaci IS/ICT v podniku 72

73 Využití projektového řízení při implementaci IS/ICT v podniku 73 E Plán nákladů projektu Pokračování

74 Využití projektového řízení při implementaci IS/ICT v podniku 74