UNICORN COLLEGE. Katedra informačních technologií BAKALÁŘSKÁ PRÁCE. Řízení lidských zdrojů na ICT projektech. Autor BP: Jiří Šulc

UNICORN COLLEGE Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE Řízení lidských zdrojů na ICT projektech

Autor BP: Jiří Šulc Vedoucí BP: Mgr. Barbora Čapková Ph.D. 2014 Praha

Zadání bakalářské práce

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Řízení lidských zdrojů v ICT projektech vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V……Praze …………. Dne … 27. 7. 2014……. …….…………………………… Jiří Šulc

Poděkování Děkuji vedoucímu bakalářské práce Barboře Čapkové za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Řízení lidských zdrojů na ICT projektech Resource management in ICT projects

5

Abstrakt: Cílem mé práce je analyzovat oblast řízení lidských zdrojů na ICT projektech a prezentovat návrh softwarové podpory tohoto procesu. Bakalářská práce je rozdělena na dvě hlavní části, teoretickou a praktickou. Teoretická část mé práce je věnována analyzování a poskytnutí uceleného přehledu na proces řízení ICT projektů a řízení lidských zdrojů jako důležitou součást tohoto procesu. Analyzuji zde základní rámec, nejdůležitější vlastnosti, schopnosti a oblasti v procesu projektového řízení. V teoretické části bakalářské práce se také věnuji definování rolí, které se účastní dodávky ICT projektů a popsání způsobů, jak tyto role mohou být v rámci ICT projektů řízeny. V praktické části popisuji výsledky své analýzy, jak lze navrhnout a využít SW podporu pro řízení lidských zdrojů na ICT projektech.

Klíčová slova: Řízení lidských zdrojů, ICT projekty, řízení ICT projektů, SW podpora, projektový management, HR, PM.

Abstract The main goal of my work is to analyze the management of human resources in ICT projects and to propose the software support of this process. This bachelor's thesis is divided into two main parts, theoretical and practical. The aim of theoretical part of my work is to analyze and provide a comprehensive overview on the management of ICT projects and human resources management as an important part of this process. Basic framework is analyzed in this part, as well as the most important characteristics, abilities and areas of project management. In the practical part of this work I describe roles that are involved in the delivery of ICT projects and the results of my analysis. The analysis outcomes are described in the practical part of this thesis and I am coming to a conclusion on how to design and use software support for the management of human resources on ICT projects.

Keywords:

6

Human resources, ICT projects, ICT projects management, SW support, project management, HR, PM

Obsah:

1

ÚVOD .............................................................................................................................. 11

2

TEORETICKÁ ČÁST .................................................................................................... 14

2.1

Cíle projektu..............................................................................................................................14

2.2

Historie projektového řízení ..............................................................................................16

2.3

Standardy a metodiky projektového řízení ..................................................................16

2.4

Projekt a metodické souvislosti ........................................................................................17

2.5

Základní rámec řízení projektů dle procesního a znalostního přístupu ...........19

2.6

Základní rámec řízení projektů dle systémového přístupu ...................................23

2.7

Základní rámec řízení projektů dle kompetenčního přístupu ..............................24

2.8

Základní rámec řízení projektů dle agilního přístupu ..............................................26

2.9

Role v projektovém řízení ...................................................................................................26

2.10

Teoretické vstupy pro analýzu ..........................................................................................31

3

PRAKTICKÁ ČÁST ....................................................................................................... 34

3.1

Postup zpracování praktické části ...................................................................................34

3.2

Proces řízení lidských zdrojů na ICT projektech ........................................................35

3.3

SW podpora pro řízení zdrojů na ICT projektech ......................................................37

3.3.1

Požadavky a očekávání od SW podpory ....................................................................... 37

3.3.2

Model způsobu užití SW podpory procesu .................................................................. 40

3.3.3

Přehled způsobů užití SW podpory procesu ............................................................... 42

3.3.4

Specifikace způsobů užití ................................................................................................... 44

3.3.5

Prostředí pro implementaci SW podpory .................................................................... 51 7

3.3.6

Finanční shrnutí implementace SW podpory ............................................................. 56

3.3.6.1

Komplexita uživatelů systému.......................................................................................... 57

3.3.6.2

Komplexita způsobů užití ................................................................................................... 58

3.3.6.3

Faktor komplexity prostředí ............................................................................................. 59

3.3.6.4

Faktor technické komplexity............................................................................................. 60

3.3.6.5

Souhrn nákladů na vývoj SW podpory pro proces ................................................... 61

4

ZÁVĚR............................................................................................................................. 63

5

CONCLUSION ................................................................................................................ 64

6

CITOVANÁ LITERATURA.......................................................................................... 65

7

SEZNAM OBRÁZKŮ .................................................................................................... 66

8

SEZNAM TABULEK ..................................................................................................... 67

8

Seznam používaných zkratek Tabulka 1: Seznam používaných zkratek Zkratka

Význam ICT je zkratka oboru informačních a komunikačních

ICT

technologií. Vychází z anglického názvu Information and Communication Technologies.

PRINCE 2

RUP ITIL® IPMA

PMBoK

PMI

OTIFOB

ROI

NPV

Metodika pro řízení projektů. Projects IN Controlled Environments. Metodika pro vývoj software. Rational Unified Process. Information Technology Infrastructure Library International Project Management Association Standard udržovaný IPMA Project Management Body of Knowledge Standard udržovaný PMI. Project Management Institute (PMI), profesní sdružení firem a projektových manažerů. Parametr OTIFOB je trojimperativ, který znamená splnění cíle projektu, ve vymezeném čase a s použitím přidělených zdrojů Return of Investments. Návratnost investic. Net Present Value. Čistá současná hodnota.

ŘVP

Řídící výbor projektu.

http

Hlavní tým projektu.

9

ŘVZ

WBS SLA

Řídící výbor změn. Change Advisory Board. Skupina lidí, která asistuje manažerovi změn při plánování změn. Work breakdown structure. Označení pro hierarchickou strukturu činností na projektu. Service Level Agreement. Dohoda o úrovni služby.

10

1 ÚVOD Za více než deset let mé práce v ICT prostředí a práce na dodávce a řízení ICT projektů jsem pochopil důležitost správného řízení lidských zdrojů. Pochopil jsem, že dobré fungování či úspěch malého ICT oddělení, ICT projektu, velkých organizačních jednotek i celého podniku závisí na kvalitě lidského kapitálu a schopnosti jej využít. Při studiu na Unicorn College a přípravě na bakalářskou práci jsem si tento svůj poznatek ověřil. Podle Michaela Armstronga1 lze lidský kapitál považovat za prvořadé bohatství každé organizace. Pro zajištění růstu a konkurenceschopnosti musí podniky do tohoto svého bohatství investovat. Cílem řízení lidských zdrojů je zabezpečit, aby organizace získala a udržela potřebné kvalifikované, oddané a dobře motivované pracovní síly. Z mé zkušenosti však není proces řízení lidských zdrojů na ICT projektech vždy správně zaveden a podpořen kvalitní softwarovou podporou. Proces řízení lidských zdrojů na ICT projektech, kterému se ve své bakalářské práci věnuji, na jedné straně čerpá z procesu řízení zdrojů organizace jako celku a na druhé straně tento proces doplňuje. Proces řízení lidských zdrojů na ICT projektech má potenciál obohatit a rozvíjet lidské zdroje, s nimiž pracuje. Z procesu řízení zdrojů organizace využívá identifikované kvalitní, oddané a motivované zaměstnance, na druhé straně je obohacuje díky rozvoji jejich know-how, posilování jejich motivace a správně cíleným odměňováním. Správnou volbou projektových týmů a rolí jednotlivých osob v projektech tedy pomáhá proces řízení lidských zdrojů na ICT projektech řídit a rozvíjet jejich znalosti, zlepšovat zaměstnanecké vztahy, správnou komunikací a řízeným odměňováním projektových týmů zvyšovat motivaci, angažovanost a oddanost firmě. Při špatném řízení lidských zdrojů na ICT projektech však můžeme dosáhnout právě opačného, nežádoucího stavu. Neplnění cílů projektu může vést ke zhoršení motivace s dopadem do odměn členů projektového týmu, špatná komunikace v projektu může vést ke zhoršení zaměstnaneckých vztahů, přetěžování jednotlivých rolí může vést k neplnění úkolů, frustraci, stresu a narušení pracovního i sou-

1

ARMSTRONG, Michael: Řízení lidských zdrojů. 10.vydání, Praha : Gr ada Publishing, 2008, s. 31

11

kromého života. V dalších kapitolách mé práce se budu detailně věnovat rolím v projektových týmech, jejich popisu a fungování v rámci projektů. Na úvod bych rád využil poučení z historie, které jasně ukazuje, že i v dnešní přetechnizované době jsou lidé základem úspěchu většiny činností, které realizujeme. Tuto skutečnost ve své knize zmiňuje i Tom DeMarco2. Poučení z historie se vztahuje ke ztroskotání lodi Titanic. Titanic byl v tu dobu nejmodernější, nejbezpečnější a do osudné noci roku 1912 i údajně nepotopitelná loď. Zodpovědné osoby za řízení lodi (v ICT a projektové terminologii osoby s konkrétní rolí) ignorovali varování před riziky a v honbě za získáním Modré stuhy pro nejrychlejší loď Atlantiku narazili do ledovce a během tří hodin zmizela loď pod hladinou i s více než 1500 cestujícími. Poučení pro řízení projektů tedy je, že nemůžeme v důsledku slepé víry v techniku ignorovat rizika spojená s projektem a kvalitou lidských zdrojů. Správnou volbou lidských zdrojů pro projekt musíme vytvořit optimální tým, který bude správně pracovat a hospodařit jak s technikou, tak i s časem, zdroji, riziky i úkoly. Problematiku správného řízení lidských zdrojů na ICT projektech považuji nejen já za důležitou část řízení zdrojů organizace jako celku. „Většina projektových manažerů souhlasí, že efektivní zvládání lidských zdrojů v projektu je jedním z nejobtížnějších úkolů, které před nimi stojí.“3 Dostupnost souhrnných informací, metodických postupů a publikací však této důležitosti neodpovídá, z čehož může vyplívat i nižší důraz na řízení tohoto procesu v organizacích samotných. V mé bakalářské práci bych tedy rád tento souhrnný materiál k řízení lidských zdrojů na ICT projektech v rámci svých znalostí vypracoval a představil. Dosažením cíle práce a poskytnutím uceleného přehledu o rolích, procesu a způsobu softwarové podpory napříč různými typy ICT projektů chci podpořit eliminaci stávajících nedostatků při řízení lidských zdrojů na ICT projektech. Správné řízení zdrojů na ICT projektech následně pomůže zajistit dosažení vyššího procenta projektů dodaných v parametrech OTIFOB. Strukturovaně jsem si tedy jako cíl své

2

DeMARCO Tom, LISTER Timothy: Peopleware, Productive Projects and Teams, 2nd ed. New York:

Dorset House Printing, 1999, s.5. 3

SCHWABLE Kathy: Řízení projektů v IT, Brno: Computer Press, a.s., 2007, s. 376.

12

bakalářské práce stanovil popsat principy a cíle projektového managementu, shrnout historii a popsat role účastnící se dodávky projektů. V další části mé práce jsem si stanovil jako cíl popsat proces řízení lidských zdrojů na ICT projektech, definovat varianty procesu řízení lidských zdrojů napříč různými typy ICT projektů a analyzovat a popsat způsob jak pomocí SW nástrojů řešit podporu pro proces řízení lidských zdrojů na ICT projektech.

13

2 TEORETICKÁ ČÁST Správné řízení lidských zdrojů na ICT projektu je jedním ze základních podmínek pro úspěšné dosažení cílů projektu. Lidské zdroje na ICT projektech a jejich správné řízení ovlivňují dodání projektu jak v čase, kvalitě, tak i ceně. I přesto není správnému řízení lidských zdrojů v mnoha ICT projektech věnována náležitá pozornost či není zavedeno vůbec a mnoho projektů proto není dodáno v požadované ceně, kvalitě a termínu. V následujících kapitolách analyzuji cíle a hlavní principy projektového řízení, zainteresované strany na projektech a hlavní role účastnící se dodávky ICT projektů.

2.1 Cíle projektu Cílem projektu je realizovat projekt v požadovaném čase, kvalitě a ceně neboli v parametrech OTIFOB. Parametr OTIFOB je v projektovém řízení používaný trojimperativ, který jak uvádí Jan Doležal4 ve své knize, znamená splnění cíle, ve vymezeném čase a s použitím přidělených zdrojů. Realita je však složitější, jelikož i projekt dodaný v parametrech OTIFOB může naimplementovat nepoužitelné řešení či naopak projekt, který nedopadl v parametrech OTIFOB dobře nemusel být zcela neúspěšný. „Jak můžeme zabránit těmto problémům, kdy sice splníme stanovený cílový rozsah, čas i nákaldy, ale z pohledu zákazníka či zadavatele nedosáhneme uspokojivé kvality? Odpovědí je dobré řízení projektu – které ale znamená více, než jen splnit popsané trojé omezení.“5 Pro splnění cíle projektu je nezbytná správná organizace a vedení lidských zdrojů, které jsou jednou z hlavních částí všech omezených zdrojů projektu. Správná organizace a vedení lidských zdrojů představuje aktivity spojené s vytvořením plánu lidských zdrojů, sestavení projektového týmu a zajištění alokací těchto osob na projekt, postupný rozvoj projektového týmu a řízení tohoto týmu. Za řízení lidských zdrojů na projektu je zodpovědný projektový manažer.

Ing. DOLEŽAL Jan, Ing. MÁCHAL Pavel, CSc, doc. Ing. LACKO Branislav, CSc., a kolektiv: Projektový management podle IPMA, Praha: Grada Publishing, 2009, s. 35. 4

5


14

Vytvoření plánu lidských zdrojů znamená identifikování aktivit realizovaných v rámci projektu a od nich odvozených nutných kompetencí a schopností rolí, které budeme na projektu potřebovat. Při sestavování projektového týmu již PM identifikuje konkrétní pracovníky, kteří vystupují v rolích potřebných pro realizaci projektu. Obsazení těchto konkrétních pracovníků na projekt se nazývá alokací a tento proces detailně popisuji v praktické části své práce. Při postupném rozvoji projektového týmu směřujeme k rozvoji know-how členů projektového týmu, zvýšení jejich motivovanosti a soudržnosti celého týmu tak, aby vzrostla schopnost celého týmu dodat projekt v parametrech OTIFOB. Řízení projektového týmu je sada administrativních činností, které zajišťují sledování a měření práce na svěřených úkolech projektu, výkonnosti členů projektového týmu a hodnocení členů projektového týmu. Zkušenosti z řízení projektového týmu jsou reportovány a využity pro řízení dalších projektů. Obrázek 1: Trojimperativ projektového řízení6

Cílem řízení projektu tedy není jen dodat projekt v parametrech OTIFOB, ale zajistit realizaci úspěšného projektu. Úspěšnost projektu závisí na ocenění dodaných výsledků zainteresovanými stranami.


15

2.2 Historie projektového řízení Projektové řízení je poměrně mladý obor. O projektovém řízení případně o profesi projektového manažera můžeme mluvit v podstatě až od konce druhé světové války, kdy podniky a jiné instituce začaly poznávat výhody plynoucí z organizace prací formou projektu. Známy jsou samozřejmě aktivity i z dávné minulosti, které by svým charakterem mohly spadat do kategorie projektového řízení. Příkladem takových aktivit může být stavba pyramid v Egyptě, stavba velké čínské zdi, či stavba akvaduktu ve starém Římě. Aktivity tohoto druhu vyžadovali organizaci manuální práce tisíců dělníků, tedy správné řízení lidských zdrojů, avšak nebyly tak přísně omezeny časem, zdroji ani zadáním, jak je tomu dnes. „Většina lidí se nicméně shodne, že moderní principy řízení projektů se začaly používat až u projektu Manhattan, který měla americká armáda a jehož cílem byl vývoj jaderné bomby. Do projektu Manhattan bylo zapojeno množství lidí různých profesí, již pracovali na několika různých místech. Zároveň v něm bylo jasně oddělené řízení projektu jako celku, tedy řízení cíle projektu, jeho časového plánu a rozpočtu pod vedením generála Leslieho R. Grovese, a odborné řízení projektu, které měl na starosti Dr. Robert Oppenheimer.“7

2.3 Standardy a metodiky projektového řízení Pro projektové řízení vzniklo několik standardů, které nejsou teoretickými výstupy akademiků, ale jsou soupisem nejlepších zkušeností mnoha významných manažerů. Mezi hlavní světové standardy patří PMBoK, IPMA či PRINCE2. Standardy mají totožnou základní filozofii, liší se úhlem pohledu na konkrétní oblast. Jak uvádí Jan Doležal8 ve své knize, je každý standard udržován organizací či profesním sdružením firem. Standard PMBoK – Project Management Body of Knowledge vytváří a udržuje Project Management Institute (PMI), profesní sdružení firem a projektových manažerů. Dle informací z organizace PMI9 mělo sdružení v roce 2012 více než 500.000 aktivních členů ve více než 170 zemích celého světa. PMBoK vznikl ve 20. století na zá-

7



PMI Project Management Institute [online]: PMI’s 2012 Annual Report, [cit. 2014-04-24]. Dostupný z URL: 9

16

kladě standardů US Army a tyto standardy byly brzy převzaty i do průmyslových standardů USA (ANSI). PRINCE2 je britský standard, který vznikl na základě zadání britského ministerstva průmyslu a obchodu v době, kdy vláda a státní správa potřebovali mnoho IT projektů, jejichž kvalita však byla velmi proměnlivá. Standard IPMA je spravován profesní organizací International Project Management Association10 a jedná se o standard kompetenční. Kompetenční standard znamená, že není zaměřen na přesnou definici procesů, ale na schopnosti – kompetence – projektových manažerů a jejich týmů. Dalšími nástroji, které lze v projektovém řízení využít, ale nejsou standardy projektového řízení, jsou metodiky a nástroje pro vývoj software. Příkladem metodik vývoje software mohou být RUP, AUP a například Integrated IT Methodology. Tyto frameworky se využívají k návrhu, plánování a řízení procesu vývoje informačního systému. Obrázek 2: Iterativní vývoj SW dle RUP11

2.4 Projekt a metodické souvislosti Jak ve své knize uvádí Robert K. Wysocki12, lze projekt definovat jako sekvenci jedinečných, komplexních a propojených aktivit, které mají jeden společný cíl nebo záměr a které musí být dokončeny ve specifickém čase, kvalitě a v souladu se zadáním. Jiné definice projektu uvádějí, že produkt, služba nebo jakýkoliv jiný výstup projektu by

10IPMA

International Project Management Association [online]: About IPMA, [cit. 2014-04-24]. Dostupný z URL: 11

ŠTORK Radim, VITOUŠ Otto: RATIONAL UNIFIED PROCESS, Praha: Unicorn Multimedia, 2000, s. 25.

12WYSOCKI

Robert K.: Effective Project Management: Traditional, Agile, Extreme, Indianapolis: John Wiley&Sons, 2012, s. 5.

17

měl být jedinečný, čímž se odlišuje od běžných provozních aktivit a odlišuje projekt od procesu. Projekt se od provozní činnosti nebo od procesu odlišuje také tím, že po splnění stanovených cílů svou činnost ukončí. Podle Kathy Schwalbe13 může projekt existovat ve všech oblastech lidské působnosti a ve všech velikostech. Jak definuje ve své knize řízení projektů v IT, má projekt jednoznačný cíl, je dočasný, řešení projektu se postupně vypracovává, projekt si vyžaduje určité zdroje často z různých oblastí, má hlavního zákazníka nebo zadavatele a součástí projektu je určité riziko nebo neurčitost. Jiří Skalický14 ve své knize uvádí, že projektový management používá znalostí, procesů, kompetencí, metod a nástrojů, které byly speciálně pro řízení projektů vytvořeny. Dalším uváděným specifikem pro projektové řízení je, že využívá všeobecný podnikový management a management řízení lidských zdrojů a realizuje činnosti, které jsou typické pro projekty v určitém odvětví lidské činnosti. Příkladem těchto metod a nástrojů může být metoda kritické cesty. Obrázek 3: Metodické souvislosti projektového řízení15

Mezi nástroje a metody všeobecného podnikového managementu patří stanovení kritérií, které jsou hodnotitelná ještě před zahájením projektu a jsou tedy jedním z hlavních podkladů pro rozhodnutí, zda projekt realizovat či nikoliv. Jedná se o finanční kritéria, kterými jsou například ROI či NPV. Součástí hodnocení, zda projekt

13


doc. Ing. SKALICKÝ Jiří, CSc, PhDr. JERMÁŘ Milan, Ing. SVOBODA Jaroslav: Projektový management a potřebné kompetence, Plzeň: Západočeská univerzita v Plzni, Vydavatelství, 2010, s. 21. 14


18

realizovat či nikoliv, musí být i posouzení, zda jsme schopni na projekt alokovat potřebný počet zejména lidských zdrojů pro jeho realizaci. Tabulka 2: Finanční kritéria pro realizování projektu Finanční

Výpočet

Popis

kritérium

ROI

[ ]

x 100[%]

Return of Investment. Návratnost investic. Net Present Value. Čistá současná hodnota.

NPV

je cash flow v daném období

∑

r je míra vnitřního výnosu t je počet let, po které musíme na výnos čekat

2.5 Základní rámec řízení projektů dle procesního a znalostního přístupu Řízení projektu je komplexní činnost, při níž dochází k uplatnění znalostí, využití dovedností, použití nástrojů a technik s cílem splnit požadavky na projekt kladené. „Součástí řízení lidských zdrojů na projektech jsou veškeré procesy, kterými dosáhneme co nejefektivnějšího využívání osob zapojených do projektu.“16

16


19

Obrázek 4: Základní rámec řízení projektů17

Základní rámec řízení projektů v IT lze rozdělit do následujících oblastí: Řízení lidských zdrojů18 v projektu je jednou z klíčových aktivit pro doručení projektu v parametrech OTIFOB. Do procesů řízení lidských zdrojů zahrnujeme plánování neboli identifikování a dokumentování veškerých rolí pracovníků v projektu, jejich kompetence a pravomoci, sestavení pracovního týmu, budování a rozvíjení dovedností celého týmu i jednotlivců a řízení projektového týmu. Řízením projektového týmu rozumíme činnosti jako sledování výkonnosti a motivace členů týmu, poskytování zpětné vazby, řešení problémů a konfliktů a koordinace změn. Pro správné řízení lidských zdrojů v projektech využíváme motivační techniky, naslouchání, matice přidělení rolí a zodpovědností, histogramy zdrojů, vyrovnávání zdrojů a další techniky jako jsou workshopy, teambuildingy apod. O procesu řízení lidských zdrojů v ICT projektech budu detailně pojednávat v dalších kapitolách. Řízení integrací projektu19 realizuje koordinaci všech oblastí, v nichž projekt operuje. Řízení integrací tedy zajišťuje, že všechny části projektu proběhnou ve správný čas. V tomto procesu nejlépe uplatníme metodologii a software určené pro

17


18


19


20

řízení projektu, systémy pro přidělování a sledování odvedené práce, řídící a kontrolní mechanizmy jak pro jednotlivé změny (ŘVZ), konfiguraci, tak i pro úroveň celého projektu (ŘVP, HTP). Řízení rozsahu projektu20 určuje aktivity a procesy, které definují a kontrolují, jaké práce budou a nebudou do projektu zahrnuty. „Jednou z nejdůležitějších a současně také nejobtížnějších stránek řízení projektu je proto správné definování rozsahu projektu“.21 Rozsahem projektu chápeme všechny práce, zapojené do vytvoření produktů požadovaných v rámci projektu a také všechny procesy, které vedly k vytvoření těchto produktů. Součástí řízení rozsahu projektu je plánování jeho rozsahu - jak bude definován, jak ověřen a kontrolován, jak bude vytvořena struktura rozpisu prací. Definuje rozsah projektu, stanovuje strukturu rozpisu prací (WBS) a zajišťuje formální přijetí a následnou kontrolu rozsahu projektu. Řízení času22 v projektu označuje procesy, které jsou nezbytné k dokončení projektu v definovaném čase. Součástí řízení času v projektu je definování aktivit, rozpoznání vztahů mezi těmito aktivitami, odhad zdrojů nezbytných pro realizování aktivit (lidských zdrojů, zařízení, materiálu), stanovení doby trvání jednotlivých aktivit, příprava časového plánu neboli posloupnosti jednotlivých aktivit a v neposlední řadě řízení časového plánu. Řízení časového plánu znamená jeho průběžnou kontrolu a reagování na změny a odchylky a řízení změn v časovém plánu. Řízení nákladů23 na projekt zahrnuje procesy, které zajistí dodání projektu v rámci jeho schváleného rozpočtu. Dodání projektu v rámci rozpočtu je jedno ze tří omezení projektu – viz Obrázek 1: Trojimperativ projektového řízení. Hlavními procesy zahrnutými v rámci řízení nákladů na projekt jsou odhad nákladů, rozpočtování nákladů představující rozdělení odhadu nákladů na jednotlivé pracovní položky a následná kontrola a řízení změn v rozpočtu projektu.

20


21


22


23


21

Řízení kvality24 projektu je souhrn aktivit a procesů, které vedou k zajištění shody mezi výstupy projektu a požadavky na projekt. Cílem řízení kvality v projektu je zajistit, že projekt uspokojí potřeby, kvůli kterým byla poptána jeho realizace. Řízení komunikace25 v projektu je podpůrný, ale důležitý proces, který má za cíl zajistit celý životní cyklus plánování a realizace komunikačních aktivit v rámci projektu. Odborníci se shodují, že pro projekty z oboru informačních technologií je nedostatečná nebo nevhodná komunikace jednou z největších hrozeb pro úspěch projektu. Součástí komunikačních aktivit z projektu je včasné a náležité generování, shromažďování, distribuce a likvidace informací o projektu. V každém projektu by měl vzniknout komunikační plán, který obsahuje požadavky účastníků na komunikaci, okruh sdělovaných informací, příjemce a tvůrce informací, doporučené metody a technologie pro přenos informací, frekvenci potřebné komunikace, zásady pro eskalaci řešených problémů, postupy pro aktualizaci plánu a slovníček běžně používaných pojmů. Pro účely komunikace v projektu je vhodné připravit analýzu účastníků, která nám pomáhá identifikovat komunikační potřeby jednotlivých osob zapojených do řešení projektu. Komunikaci z projektu realizujeme různými metodami od formální, neformální, písemné po metody verbální. Pro každý typ informace z projektu je potřeba stanovit nejvhodnější formu a prostředek komunikace. Z projektu je vhodné komunikovat zprávy o postupu prací, které zahrnují informace o tom, jak projekt postupuje ke splnění svých cílů. Projektový manažer musí s projektovým týmem rozvíjet dovednosti řízení konfliktů i další komunikační dovednosti. „Řízení rizik v projektu je zčásti exaktní vědou a zčásti uměním, které zahrnuje identifikaci rizik, jejich analýzu a reakci na ně po celou dobu života projektu, přičemž se musíme řídit těmi nejlepšími zájmy naplnění cílů projektu.“26 Řízení rizik v projektu tedy pomáhá minimalizovat potenciální negativní stavy za současné maximalizace potenciálních pozitivních rizik. Součástí řízení rizik v projektu jsou procesy plánování řízení rizik, identifikace rizik, provádění kvalitativní a kvantitativní analýzy rizik, plá-

24


25


26


22

nování reakcí na rizika a sledování a kontrola rizik. Kvalitativní analýza rizik představuje rozbor hrozících rizik a přiřazení jejich závažnosti podle pravděpodobnosti a dopadů vzniku takového rizika. Kvantitativní analýza rizik obsahuje číselné odhady dopadů rizik. Řízení obstarávání27 v projektu obsahuje veškeré procesy, které projektu zajistí obstarání zboží a služeb nezbytných k realizaci projektu a dodání jeho výstupů. Součástí řízení obstarávání je plánování a příprava smluv, poptání informací a nabídek od externích subjektů, proces výběru dodavatele, administrativní zajištění smluv a uzavření neboli ukončení smluv.

2.6 Základní rámec řízení projektů dle systémového přístupu Podle Jiřího Skalického a jeho knihy Projektový management a potřebné kompetence28 lze systémový přístup charakterizovat jako využívání nástrojů řízení systémů – systémové analýzy a syntézy, zpětné vazby (kontrolní a korekční procesy), modelování (plánování) a simulace – pro řízení projektů. Základní analýzu projektu provedeme rozkladem na dvě základní části: 

Cíl projektu – odpovídá nám na otázku CO? projekt přináší.



Aktivity a činnosti, pomocí nichž bude projekt realizován – odpovídá na otázku, JAK? bude projekt realizován.

Další stránka projektu je jeho řízení – skládá se z vlastního řízení a z toho, co je řízeno

27



Řídící stránka projektu – plánovací práce, konání kontrolních dnů, atd.



Pracovní stránka – vytváří samotný výstup projektu



23

2.7 Základní rámec řízení projektů dle kompetenčního přístupu Kompetenční přístup k projektovému řízení vychází ze standardů mezinárodní asociace IPMA29 a stanovuje, že člověk vybavený potřebnými způsobilostmi je nejdůležitější součástí projektového managementu. IPMA Competence baseline definuje 46 elementů způsobilosti a doplňuje je o vztahy mezi nimi. Těchto 46 elementů je rozděleno do 3 oblastí, ve kterých jsou seskupeny technické způsobilosti, způsobilosti behaviorální a způsobilosti kontextové – způsobilosti dané vazbami projektového prostředí na okolí.

Jednotlivé oblasti kompetencí popisuje ve své knize Projektový ma-

nagement podle IPMA Jan Doležal30. Okruhy elementů kompetencí včetně jejich popisu, stupňů kompetencí a způsobu certifikace jsou uvedeny v národním standardu kompetencí projektového řízení31. Obrázek 5: Okruhy elementů způsobilosti32

Oblast technických kompetencí popisuje zásadní elementy kompetencí projektového řízení. Náleží sem obsah projektového řízení, který bývá označován jako tzv. pevné elementy. Mezi 20 elementů technických kompetencí patří úspěšnost řízení projektu, zainteresované strany, požadavky a cíle projektu, rizika a příležitosti,



Společnost pro projektové řízení [online]: NÁRODNÍ STANDARD KOMPETENCÍ PROJEKTOVÉHO ŘÍZENÍ VERZE 3.2, [cit. 2014-04-26]. Dostupný z URL: 31


24

kvalita, organizace projektu, týmová práce, řešení problémů, struktury v projektu, rozsah a dodávané výstupy projektu, čas a fáze projektu, zdroje, náklady a financování, obstarávání a smluvní vztahy, změny, kontrola, řízení a podávání zpráv, informace a dokumentace, komunikace, zahájení a ukončení. Elementy technických kompetencí se používají při iniciování a zahájení projektu, při řízení jeho realizace a při ukončování projektu. Pořadí užití kompetencí se může lišit dle typu, velikosti a komplexnosti projektu. Oblast behaviorálních kompetencí je založena na řadě referenčních dokumentů, které popisují chování a zahrnují elementy osobního přístupu. Mezi elementy behaviorálních kompetencí, které jsou relevantní pro projektové řízení patří vůdcovství, zainteresovanost a motivace, sebekontrola, asertivita, uvolnění, otevřenost, kreativita, orientace na výsledky, výkonnost, diskuze, vyjednávání, konflikty a krize, spolehlivost, porozumění hodnotám a etika. To, jak jsou jednotlivé behaviorální elementy na projektu důležité, závisí na situaci, ve které se projekt nachází. Elementy kontextových kompetencí popisují koncepce projektu, programu a/nebo portfolia a propojení těchto koncepcí s širším okolím projektu, které je definované organizací, nebo organizacemi, které se projektu účastní. Mezi kontextové kompetence patří orientace na projekt, orientace na program, orientace na portfolio, realizace projektu, programu a portfolia, trvalá organizace, byznys, systémy, produkty, technologie, personální management, zdraví, bezpečnost, ochrana života a životního prostředí, finance a právo. První část kontextových kompetencí se zaměřuje na podporu řízení projektu, programu nebo portfolia v organizaci. „Řízení projektu zahrnuje plánování, organizaci, sledování a kontrolu všech aspektů projektu, a dále řízení a vedení všech zainteresovaných proto, abychom dosáhli cílů projektu bezpečně a v rámci dohodnutých podmínek pro čas, náklady, obsah/rozsah, výkonnost a kvalitu.“33 Posledních šest zmíněných kompetencí se zaměřuje na podpůrné funkce trvalé organizace a na to, co o nich musí projektový tým vědět a naopak, co musí vědět tyto podpůrné funkce o projektu.


25

2.8 Základní rámec řízení projektů dle agilního přístupu Agilní metody projektového řízení jsou metodami, kdy se využívá projektového přístupu při použití krátkodobých ohraničených iterací, při kterých jsou produkty postupně vyvíjeny. Využívají se klasicky pro vývoj software. Tyto metody projektového řízení jsou známy od roku 2001, kdy skupina 17 vedoucích pracovníků vývojových společností sepsala Manifest pro vývoj agilního software34. Manifest uvádí, že při snaze o dosažení lepších výsledků při vývoji software dospěli autoři manifestu k závěrům, že jednotlivci a vzájemné ovlivňování jsou více než procesy a nástroje, že pracovat na software je více než zpracovávat obsáhlou dokumentaci, že spolupráce se zákazníkem je více než kontraktační vyjednávání a že schopnost reagovat na změny je více než řídit se plánem. Agilní přístup k řízení projektů se opírá o několik zásad, jež jsou detailně definovány v knize K.Wisockého Effective Project Management: Traditional, Agile, Extreme35. První zásadou je adaptace – učení se a přizpůsobení. Agilnost je založena na přiznání, že na počátku o projektu zdaleka nevíme všechno. Věci, které na počátku projektu víme či předpokládáme, jsou měněny a je nutné na ně reagovat. Další zásadou je, že nejdůležitějším účastníkem projektu je zákazník. Agilní tým si musí udržet trvalý kontakt se zákazníkem. Agilní tým ví, že seznam funkčních požadavků, pokud byl sepsán, obsahuje chyby, je neúplný či jej lze interpretovat několika způsoby. Udržení kontaktu se zákazníkem je základ pro to být schopen vyprodukovat to, co zákazník skutečně potřebuje. Další zásadou je budování malých týmů s nezávislým řízením. Agilní tým přebírá odpovědnost nejen za svou technickou práci, ale také za uzavírání závazků a za konání podle těchto závazků. Dalšími zásadami agilního projektového řízení je postupné zpřesňování požadavků a inkrementální vývoj systému.

2.9 Role v projektovém řízení Cílem řízení projektu je zajistit realizaci úspěšného projektu. Jak jsem již zmínil, úspěšnost projektu nezávisí jen na dodání projektu v parametrech OTIFOB, ale závisí

34

FOWLER Martin, HIGHSMITH Jim: The Agile Manifesto, Software Development, 2001, s. 28-32.

WYSOCKI Robert K.: Effective Project Management: Traditional, Agile, Extreme, Indianapolis: John Wiley&Sons, 2012, s. 384 - 448. 35

26

na ocenění dodaných výsledků zainteresovanými stranami. Kritéria hodnocení úspěšnosti projektu se liší podle úhlu pohledu - jiný pohled na úspěch projektu má sponzor projektu, dodavatel, provozovatel výstupů či vlastník zadávající firmy. Pro dosažení úspěšného projektu je důležité mít zmapované osoby či skupiny, které mají zájem na výkonu nebo úspěchu projektu nebo které jsou jím ovlivněny či omezeny. Podle IPMA36 je zainteresovanou stranou osoba/organizace, která je aktivně zapojena do projektu, nebo jejíž zájmy mohou být pozitivně/negativně ovlivněny realizací projektu nebo jeho výsledkem. Zainteresované strany se dělí na primární a sekundární. Primární zainteresované strany jsou uvedeny v tabulce Tabulka 3: Primární zainteresované strany. Sekundární zainteresované strany mohou být veřejnost, vládní instituce a samosprávní orgány, konkurenti, lobbisté, nátlakové skupiny a média. Tabulka 3: Primární zainteresované strany37 Role

Popis, očekávání

Vlastníci a investoři

Očekávají od projektu podporu generování zisku, růst hodnoty podniku, transparentnost. Pro kontrolu a měření zisku plynoucího z realizovaného projektu se využívají kritéria definovaná v předprojektových fázích – ROI, NPV. ROI je ukazatel, který určuje návratnost investic. NPV slouží v době přípravy projektu pro podporu rozhodnutí, zda se vyplatí investovat.

Zaměstnanci

Očekávají přiměřenou mzdu a nefinanční benefity za odvedenou práci a dobré pracovní podmínky. Očekávají profesní růst a další vzdělání. Očekávají sladění osobního a profesního života.



27

Zákazníci (potenciální

Očekávají dodání kvalitního produktu nebo služby za přimě-

i stávající)

řenou cenu. Očekávají poprodejní servis.

Obchodní partneři,

Očekávají kvalitní smlouvy a seriózní jednání v průběhu

dodavatelé

přípravy a realizace projektu. Očekávají včasné plnění závazků.

Během mé praxe v projektovém řízení jsem poznal klíčové role, které se podílejí na realizaci a dodání úspěšného projektu. Mezi nejdůležitější role na ICT projektech řadím projektového manažera, sponzora projektu, resource manažera, testovacího manažera, vývojáře, business konzultanta, service level manažera, garanta business zadání a garanta ICT řešení. Mezi skupinové role pak řadím řídící výbor projektu nebo portfolia a hlavní tým projektu. Jejich fungování, kompetence a úkoly v projektu popisuji dále v této kapitole. Sponzorem projektu může být manažer či člen vedení společnosti, jenž odpovídá vrcholovým orgánům za dosažení projektových cílů, schvaluje zadání projektu včetně jeho přínosů – viz kapitola 2.4 Projekt a metodické souvislosti - NPV a ROI. Sponzor projektu také odpovídá za obsazení role garanta business zadání a za splnění všech požadavků z projektu na součinnost jdoucí za zákazníkem. Mezi tyto odpovědnosti patří zejména zajištění požadovaných kapacit zástupců zákazníka v projektových týmech, zajištění zákaznického testování výstupů projektu a zajištění školení koncových uživatelů. Sponzor projektu také odpovídá za řešení přiřazených eskalací z projektových platforem v průběhu realizace projektu a rozhoduje o souvisejících opatřeních. Projektový manažer odpovídá za řízení projektu dle zadání ve schválených termínech, rozsahu a zdrojích včetně řízení změn v projektu a řízení rizik – viz kapitola 2.1 Cíle projektu. Projektový manažer dále odpovídá za plánování a čerpání zdrojů projektu, především rozpočtu a kapacit lidských zdrojů. Projektový manažer přijímá návrhy od členů projektu a rozhoduje o nich v rámci svých kompetencí, případně je předkládá k rozhodnutí příslušným řídícím projektovým platformám. Projektový manažer připravuje reporty o stavu projektu a má pravomoc zadávat úkoly a delego28

vat své činnosti členům HTP a projektového týmu v rozsahu jejich schválených kapacit (alokací na projekt – více v Praktické části). Projektový manažer odpovídá za zadání úkolů jednotlivým členům projektového týmu, případně vedoucím týmů. Odpovídá za vypracování, schválení a uložení povinných projektových dokumentů. Odpovídá za řádné ukončení projektu včetně zajištění akceptace výstupů a zatřídění do majetku. Projektový manažer řídí lidské zdroje a na denní bázi vede projektový tým, HTP (dle organizační struktury projektu). Resource manažer řídí proces plánování lidských zdrojů na ICT projektech. Resource manažer zodpovídá za provedení pravidelné aktualizace volných kapacit lidských zdrojů pro využití v ICT projektech. Resource manažer zodpovídá za vyřešení konfliktů a přealokacích lidských zdrojů návrhem alternativních lidských zdrojů, navýšením volné kapacity zdrojů pro projekty. Možná řešení jsou dohoda s liniovým manažerem o změně disponibilní kapacity, projektovým manažerem o rozsahu alokací, případně posun harmonogramů projektů. Resource manažer vytváří pravidelné reporty o využití lidských zdrojů na ICT projektech dle definice svého procesu a požadavků vedení projektů, vedení společnosti a liniových nadřízených výkonných zaměstnanců. Quality Assurance představuje kontrolní prvek v organizaci projektu. Využití role Quality Assurance na projektu je volitelné a mělo by odpovídat důležitosti a složitosti projektu. Osoba obsazená do této role by měla mít vysokou úroveň odbornosti daného ICT řešení, měla by splňovat maximální míru nezávislosti a objektivity a měla by mít praxi v kontrolních a auditních činnostech. Quality Assurance kontroluje kvalitu realizace projektu dle předem definovaných kritérií, kontroluje kvalitu výstupů a postup prací na straně dodavatelů vůči platné smlouvě, schváleným zadávacím dokumentům a obvyklé praxi. Quality Assurance provádí věcnou oponenturu klíčových projektových dokumentů a výstupů, předkládá návrhy vedoucí k neustálému zlepšování kvality průběhu vlastních prací a výsledků projektu. Quality Assurance kontroluje soulad zvolených postupů v rámci projektu vůči interním pravidlům ve společnosti a identifikuje možná rizika v realizaci projektu. Service Level Manažer odpovídá za smluvní zajištění plátce ICT řešení a za zajištění a schválení aktuálního zadání projektu před jeho startem. Service Level Mana29

žer odpovídá za efektivní komunikaci se zákazníkem projektu v celém jeho průběhu včetně změnových řízení v projektu. Business analytik je v projektu zodpovědný za identifikování a modelování procesních požadavků, identifikování a modelování datových požadavků, identifikaci business pravidel, spolupráci při definování požadavků na testování, řízení požadavků a zadání scope projektu a specifikuje způsoby užití nového systému. Volitelně pomáhá v projektu vedením některého z projektových týmů. Testovací manažer řídí testování na ICT projektu. Test manažer soustavně hodnotí, zda kvalita prací na projektu neklesá. Nástroji pro kontrolu jsou soustavná kontrola průběhu činností (spoluúčast, vyhodnocovací meetingy, výkazy), analýza zjištěných nedostatků a hodnocení odchylek, porovnání skutečného a předpokládaného počtu a závažnosti zjištěných nedostatků. Testovací manažer průběžně sleduje, zda jsou dostatečně otestovány všechny oblasti funkcionality a jakou vykazují chybovost Vývojář zajišťuje návrh, vývoj a úpravu programů, software a informačních systémů. Další jeho náplní v projektu je tvorba kódu, programování a předávání balíčků (částí řešení) k otestování a následnému release do produkčního prostředí. Garant Business zadání je nominován sponzorem projektu a proto má na projektu mandát smluvního partnera. Ve spolupráci s business analytikem odpovídá za úplné a kvalitní vypracování a konsolidaci detailních business požadavků (business zadání). Garant Business zadání spolupracuje při tvorbě detailní funkční a technické specifikace ICT řešení a odpovídá za akceptaci výstupů projektu za stranu zákazníka. Garant ICT řešení odpovídá za vypracování a konsolidaci detailní funkční a technické specifikace ICT řešení. Odpovídá za to, že navrhované technické a funkční řešení splňuje požadované business zadání. Garant ICT řešení na projektu odpovídá za kvalitu a technickou proveditelnost ICT řešení, které je v souladu s ICT standardy společnosti a požadavky zadavatele. Garant ICT řešení také odpovídá za kvalifikovaný odhad všech nákladů ICT řešení včetně odhadů pracnosti. Hlavní tým projektu představuje nejvyšší operativní úroveň řízení projektu. Hlavní tým projektu odpovídá za koordinaci práce jednotlivých projektových týmů, 30

má povinnost dodržovat pravidla stanovená v projektové dokumentaci dle pokynů projektového manažera a průběžně kontroluje postup všech fází projektu. Hlavní tým projektu přijímá návrhy a rozhoduje o nich v rámci svých kompetencí, případně je předkládá k rozhodnutí nadřízeným projektovým platformám. Řídící výbor představuje nejvyšší úroveň řízení ICT projektu či portfolia ICT projektů. Portfolio ICT projektů jak jej definuje Národní standard kompetencí projektového řízení: „Skupina projektů nebo programů seskupených do jednoho celku za účelem efektivnějšího řízení a usnadnění dosažení strategických cílů. Projekty se vzájemně ovlivňují většinou pouze sdílenými zdroji a jejich časovým rámcem.“ 38 Řídící výbor schvaluje zařazení nového projektu do portfolia projektů, projednává a schvaluje plán proajektů na následující plánovací období. Akceptuje

výstupy

projektů,

milníky, mandatorní dokumenty a s ohledem na milníky a harmonogramy jiných projektů schvaluje návrhy na změny v rozsahu, termínech a v rozpočtu projektů v rámci portfolia. Má pravomoc schvalovat změny projektů a kontroluje naplňování cílů a výstupů projektů včetně čerpání rozpočtu. Má pravomoc zadávat úkoly svým členům v rozsahu jejich liniových pravomocí a odpovědností.

2.10 Teoretické vstupy pro analýzu K provedení analýzy využití nástrojů pro podporu řízení projektů a projektového portfolia jsem využil svých znalostí těchto nástrojů, jejich implementace a intenzivní analýzu jejich využití, využívání přidělených licencí, utilizaci infrastruktury, modelaci způsobů a využití optimálního prostředí pro podporu tohoto procesu. Při analýzách a zpracování praktické části mé práce jsem s úspěchem využil metodu SWOT analýzy a metodu logického rámce. Jak uvádí Jan Doležal ve své knize projektový management podle IPMA, je metoda SWOT analýzou silných a slabých stránek, hrozeb a příležitostí. „Cílem analýzy


31

SWOT je sestavit reprezentativní seznamy pro silné stránky, slabé stránky, příležitosti a hrozby.“39 „Logický rámec je metoda, která nám pomáhá při plánování, realizaci a vyhodnocení projektu. Jedná se tedy o velmi účinný nástroj, který nám pomůže zvládnout řízení celého projektového cyklu.“40 Jak uvádí Jan Doležal v knize Projektový management podle IPMA, je doporučený postup pro tvorbu logického rámce následující41: 1. stanovit si cíl projektu; 2. stanovit konkrétní výstupy pro dosažení cíle projektu; 3. stanovit skupiny klíčových činností pro dosažení každého výstupu; 4. stanovit záměr; 5. ověřit dodržení vertikální logiky testem jestliže – pak; 6. stanovit požadované předpoklady na každé úrovni (časový a finanční rámec); 7. stanovit objektivně ověřitelné ukazatele na úrovni; 8. stanovit prostředky a způsob ověření; 9. určit náklady na provedení činnosti – zdroje; 10. provést test návrhu dle kontrolních otázek;


Kaţmierski T., Pelcl T.: Projektové a strategické plánování pro neziskové organizace. Vyd. 1, Praha: Regionální enviromentální centrum: centrum pro komunitní práci, 2003, s. 12. 40


32

Tabulka 4: Způsob čtení logického rámce Záměr Cíl

Konkrétní stupy

vý-

OOU

Způsob ověření

OOU

Způsob ověření

OOU

Způsob ověření

Klíčové činnosti Zdroje

Časový rámec

Předpoklady a rizika Předpoklady a rizika Předpoklady a rizika Předběžné podmínky

Výstupy jsem průběžně zaznamenával a shrnul v závěrečné zprávě za tuto oblast. Zkušenosti z této analýzy a části zprávy využil i v praktické části této práce.

33

3 PRAKTICKÁ ČÁST 3.1 Postup zpracování praktické části Jako autor práce jsem se v roce 2013 podílel na analýze možnosti optimalizovat proces řízení lidských zdrojů na ICT projektech v jedné konkrétní energetické společnosti. Společnost využívala pro podporu řízení projektů a projektového portfolia nástroj, jehož aktuálně používaná verze měla být v následujícícm roce postavena mimo podporu výrobce. Proces řízení lidských zdrojů byl podporován také tímto nástrojem, nicméně byl implementován jen částečně a v nástroji nebyly pokryty funkcionality jako vykazování a schvalování odvedeného času. Tyto části procesu byly realizovány mimo nástroj a podporovány jen rozesíláním mailů s excelovými přílohami. Návratnost odpovědí a nepřesnosti zavlečené ručním zpracováním zkreslovaly celkový obrázek o využití lidských zdrojů na ICT projektech. Společnost měla několik možností, jak se postavit k nadcházející situaci. Zadání analyzovat možnost optimalizace řízení lidských zdrojů na ICT projektech měla pomoci podpořit či zavrhnout některou z možností. Jednou z možností bylo provést technologický upgrade prostředí na podporovanou verzi a dokoupit licence pro modul vykazování. Druhou možností bylo vysoutěžit řešení od jiného dodavatele včetně podpory kompletního řízení lidských zdrojů a utlumit platbu za údržbu licencí stávajícího produktu. Další variantou bylo nedělat nic, provozovat výrobcem nepodporovanou verzi nástroje a zjistit pracnost implementace části procesu řízení lidských zdrojů mimo tento nástroj a případně ji i implementovat. Výhoda technologického upgrade na poslední verzi, dokoupení licencí modulu vykazování a využití tohoto enterpise prostředí jednoznačně spočívá v pokročilých funkcích prostředí a jednoduchosti implementace. Součástí nové implementace by bylo poskytnutí prostředí umožňující samoobslužnou tvorbu reportů, nové uživatelské rozhraní, reportování agregovaných dat pro management společnosti, podpora přístupu z mobilních zařízení a mnoho dalších funkčních vylepšení. Stejné výhody nabízela i implementace nástroje od nového dodavatele. Rozhodnutí implementovat nástroj nového dodavatele by muselo předcházet zdůvodnění

34

kladného business case a obhajoba projektu pomocí kritérií uvedených v kapitole 2.4 Projekt a metodické souvislosti - NPV a ROI. V průběhu analýzy jsem identifikoval, že společnost v nástroji řídí kompletně předprojektovou přípravu v rozsahu stovek námětů na projekt, běžící projekty v počtu necelých sto dvaceti souběžně běžících ICT projektů a lidské zdroje pro přípravu a realizaci projektů. Pomocí tohoto nástroje bylo ve společnosti řízeno cca 500 výkonných pracovníků z ICT a cca 1000 osob z businessu v rolích metodiků, klíčových uživatelů a testerů. Vytížení nástroje však nebylo vysoké, jeho využití bylo nárazové a odpovídalo termínům před tvorbou reportů pro řídící struktury projektů a management společnosti. Díky této skutečnosti byla přijatelná i varianta nerealizovat upgrade, provozovat systém bez podpory výrobce a implementovat proces řízení lidských zdrojů mimo tento nástroj. Cena implementace nástroje pro řízení lidských zdrojů této společnosti mimo enterprise nástroje oproti ceně licencí a implementace těchto nástrojů by následně přispěla k volbě varianty řešení.

3.2 Proces řízení lidských zdrojů na ICT projektech V každé firmě, ve které jsem působil, byl proces řízení lidských zdrojů implementován různě a měl jinou důležitost. Míra implementace a využití tohoto procesu závisela vždy na velikosti firmy, požadavcích vedení společnosti, tlaku na zodpovědné finanční řízení projektů a celé společnosti, ale i zkušeností a způsobu řízení útvaru zodpovědného za dodání projektů. Proces řízení lidských zdrojů na ICT projektech vychází z poskytnutí určité kapacity zaměstnance jeho liniovým manažerem či osobou zodpovědnou za řízení tohoto výkonného pracovníka pro potřeby projektů. Tuto poskytnutou kapacitu nazýváme disponibilní kapacita. Definice disponibilní kapacity tedy může být následující: disponibilní kapacita je kapacita poskytnutá vlastníky lidských zdrojů pro projektovou činnost. Vlastníci lidských zdrojů (linioví nadřízení) garantují její rozsah s ohledem na výjimečné stavy (například nemoc, dodržení provozních SLA, a podobně). Další důležitá definice v procesu řízení lidských zdrojů na ICT projektech je alokovaná kapacita. Alokovaná kapacita je závazně rezervovaná kapacita jednotlivých

35

zaměstnanců (tzn. konkrétní jména) v definovaných měrných jednotkách – například člověkodnech (MD man-days) pro konkrétní projekt a časový interval. Výsledkem práce vlastníků zdrojů s disponibilní kapacitou a projektových manažerů s jejich alokacemi je čerpaná kapacita, což je skutečně odpracovaná kapacita na projektovém úkolu. Tato čerpaná kapacita se zjišťuje z vykázaného času alokovaného zdroje, který je schválený projektovým manažerem. Oproti tomu volná kapacita je disponibilní mínus alokovaná kapacita. Volná kapacita tak představuje informaci o nevyužití nebo přetížení zaměstnance v určitém časovém intervalu. Při alokování zaměstnance na práci na projektu vychází projektový manažer z odhadů pracnosti daného úkolu, což je odborný odhad pracnosti realizace činnosti v daných měrných jednotkách, například člověkodnech (MD man-days). Pracnost daného úkolu je následně rozdělena na jednotlivé zaměstnance dle jejich rolí. Resource manažer a projektový manažer pracují s tabulkou obsahující seznam zaměstnanců a jejich aktuální a budoucí disponibilní kapacitu. Tato tabulka se nazývá resource pool. Z disponibilní kapacity lidských zdrojů, odhadů pracnosti a aktuálních alokací jednotlivých zdrojů se připravuje kapacitní plán lidských zdrojů dle jednotlivých rolí. Tento kapacitní plán slouží resource manažerovi a vedení společnosti pro identifikaci kritických lidských zdrojů a v případě nedostatku interní kapacity jako včasný indikátor nutnosti nákupu externích lidských zdrojů. Zaměstnanci evidují čas, který byl skutečně odpracován na daném úkolu pro konkrétní projekt. Tento čas se nazývá vykázaný čas. Měřítkem efektivity využívaní lidských zdrojů na ICT projektech je jejich utilizace. Utilizace zdrojů uvádí schopnost projektů čerpat poskytnutou kapacitu tzn. je poměrem mezi disponibilní a čerpanou kapacitou. Proces řízení lidských zdrojů v ICT projektech je podpůrná aktivita pro řízení ICT projektů. Jeho cílem je podpořit dokončení projektů v požadovaném termínu, rozsahu a nákladech (OTIFOB), a optimalizace využití kapacit lidských zdrojů. Celý proces řízení lidských zdrojů na ICT projektech lze shrnout do aktivit poskytnutí a průběžné aktualizace disponibilních kapacit vlastníkem zdrojů, alokování volných dispo-

36

nibilních kapacit a průběžné zpřesňování alokací projektovým manažerem a vykázání skutečně odvedené práce od alokovaného zdroje. Obrázek 6: Grafické znázornění procesu řízení lidských zdrojů

Proces řízení lidských zdrojů na ICT projektech má shodné postupy pro různé typy projektů, je využitelný pro všechny základní rámce řízení projektů i pro projekty řízené dle různých metodik. Podle mnou realizované analýzy lze uvedený proces řízení lidských zdrojů na ICT projektech aplikovat na Telco projekty, projekty řešící obnovu či konsolidaci infrastruktury stejně jako agilně řízené vývojové projekty. Pokud není proces řízení lidských zdrojů v ICT projektech nastaven správně, či není nastaven vůbec, vystavuje se organizace problémům s dopady v oblasti efektivity, v oblasti finanční i v oblasti personální. Dopad v oblasti efektivity ovlivňuje využití lidských kapacit ve společnosti (přetížení některých zdrojů, neefektivní využití jiných) a tedy celkovou výkonnost společnosti. Dopad v oblasti finanční ovlivňuje dosažené hospodářské výsledky společnosti a její prosperitu. Dopad v oblasti personální negativně ovlivňuje pracovní prostředí ve společnosti, může vést ke zhoršení zaměstnaneckých vztahů, k neplnění úkolů a narušení pracovního i soukromého života zaměstnanců.

3.3 SW podpora pro řízení zdrojů na ICT projektech 3.3.1

Požadavky a očekávání od SW podpory

Pro řízení lidských zdrojů na ICT projektech je možné využít mnoho softwarových nástrojů pro jednoduché přidělování povinností neboli odpovědností, vytváření histogramů zdrojů, přiřazování a sledování zdrojů, jejich vyrovnávání. Příkladem nástrojů pro SW podporu může být tabulkový procesor nebo specializovaný softwarový 37

nástroj typu Microsoft Project, HP PPM nebo CA Clarity PPM. Od pokročilých nástrojů očekáváme možnost na základě uložených informací a sestav s přiřazením zdrojů sledovat aktuální působení jednotlivých zdrojů, možnost identifikovat nedostatek zdrojů, kvůli kterému by mohlo být ohroženo splnění harmonogramu projektu a samozřejmě mít možnost identifikovat nedostatečně využité zdroje a změnit jejich přiřazení. V následujících kapitolách jsem se na SW podporu procesu řízení lidských zdrojů na ICT projektech podíval jako na sadu pracovních postupů nad konkrétní strukturou dat a polí a tuto jsem se pokusil implementovat v jakémkoliv dostupném nástroji, jenž podporoval tvorbu pracovních postupů a vytváření vlastních knihoven a seznamů. Při analyzování silných a slabých stránek nasazení SW podpory pro řízení lidských zdrojů jsem vycházel ze svých zkušeností. Identifikoval jsem, jaké výhody by implementace SW podpory pro proces řízení lidských zdrojů na ICT projektech měla přinést a jaké požadavky na tento systém budou kladeny. Implementovaná SW podpora pro proces řízení lidských zdrojů na ICT projektech by měla eliminovat stav, kdy nejednotný způsob práce s lidskými zdroji a způsob vykazování práce neposkytuje potřebné informace pro efektivní řízení lidských zdrojů společnosti. Implementace SW podpory pro proces znamená implementaci systému, který umí vygenerovat reporty o skutečné odpracované době. Tyto výstupy mohou být dále HR procesem využity k podpoře rozhodování o počtu FTE v jednotlivých rolích. Nový implementovaný systém musí zajistit SW podporu pro efektivní plánování kapacit na ICT projekty. Díky reálnému vykázání zpětné vazby v procesu plánování kapacit musí systém poskytnout liniovým manažerům podklady pro rozhodnutí, jak optimálně zajistit obsazení jednotlivých rolí ve svých útvarech, softwarovým architektům podklady k tvorbě návrhů řešení a kalkulacím cen projektů a projektovým manažerům k řízení projektu. Nový implementovaný systém musí zajistit způsob kontroly a schvalování výkazů odvedené práce. Tím systém podpoří efektivní řízení interních nákladů na dodávku projektů, provozování služeb, popř. neprojektové změny. 38

Systém na podporu řízení lidských zdrojů musí sloužit jako zdroj kvalitních dat, který eliminuje problémy způsobené nepřesným či ad-hoc vykazováním aktivit spojených s projekty. SW podpora procesu musí eliminovat stav, který vede k nepřesnosti údajů ve výkazech pramenící z prodlevy mezi realizací práce a vytvořeným výkazem práce. Díky snížení složité manuální obsluhy procesu zajistí systém redukci těžkopádnosti a složité obsluhy procesu, která vede k nadměrné administrativní zátěži, netransparentnosti, riziku zavlečení chyb, nemožnosti zpětného dohledání informací a neexistenci jednoho místa pravdy. Od systému dále očekávám, že bude schopen dodat informace o skutečné pracnosti na projektech a poskytovat reporty o skutečném vytížení pracovníků. Tento stav umožní liniovým manažerům a vedení společnosti lépe rozhodovat o počtu FTE v jednotlivých rolích. Navržený systém musí umožňovat sledovat alokaci práce na jednotlivé činnosti (value added / non value added), což umožní nově stanovovat a vyhodnocovat cíle (KPIs) liniovým manažerům v této oblasti. Díky zpětné vazbě je možné zpřesnit plánování projektů a tím zlepšit plnění parametrů OTIFOB. SW podpora procesu musí podporovat samotný proces vykazování odvedené práce. Vykazování v systému musí být jednodušší než papírová forma a nesmí být pro zdroje vykazující v systému administrativní zátěží. Stejně tak pro projektové manažery, resource manažera a další role zapojené do procesu. Systém musí podporovat přesuny dat mezi systémem pro plánování a vykazování, HR systémy a finančními systémy. Implementovaná SW podpora pro proces řízení lidských zdrojů na ICT projektech by měla také být schopna podpořit schvalování vykázaného času u všech aktivit. Díky tomu bude společnost lépe schopna řídit náklady na projekty.

39

3.3.2

Model způsobu užití SW podpory procesu

V další fázi přípravy SW podpory pro řízení lidských zdrojů na ICT projektech jsem identifikoval aktéry vystupující či interagující se systémem pro SW podporu procesu řízení lidských zdrojů na ICT projektech. Obrázek 7: Přehled aktérů systému SW podpory uc Actors

«business actor» Zákazník

«internal w orker» Manažer neproj ektov é změny

Finanční systém

«internal w orker» Proj ect Manager

HelpDesk

«internal w orker» Resource Manager

«internal w orker» Liniov ý Manager

«internal w orker» Zaměstnanec

HR systém

Liniový manažer je v procesu řízení lidských zdrojů na ICT projektech zodpovědný za zadání disponibilní kapacity svých pracovníků do systému. Liniový manažer je dále zodpovědný za pravidelnou aktualizaci disponibilní kapacity jednotlivých pracovníků. Frekvence aktualizace disponibilní kapacity se může lišit dle typu projektu či metodiky jeho řízení. Projekt řízený dle agilní metodiky bude mít jinou frekvenci než tradiční projekt vodopádového typu. Liniový manažer také zodpovídá za řádné a včasné vyplnění výkazů na projektové činnosti u jím řízených pracovníků. Projektový manažer v systému plánuje obsazení jednotlivých rolí na celou délku projektu. Plán zdrojů ICT pro daný projekt je konzultován s resource manažerem. Projektový manažer je zodpovědný za pravidelnou aktualizaci plánu alokovaných kapacit daného projektu. Projektový manažer aktualizuje plán zdrojů podle plánovaných projektových činností na základě průběhu prací projektu. Zpřesňující požadavky na následující plánovací období konzultuje projektový manažer s konkrétním liniovým manažerem daného zdroje a s resource manažerem. Daný pracovník, který je identifikovaný jako vhodný pro výkon konkrétní role v projektu je automaticky informován SW podporou procesu o změnách v jemu přiřazených alokacích. Projektový 40

manažer kontroluje a schvaluje vykázané hodiny na jím řízených projektech. Projektový manažer odpovídá za dodání projektu dle zadání ve schválených termínech, rozsahu a s využitím přidělených zdrojů. Projektový manažer odpovídá za plánování a čerpání zdrojů projektu, tj. především rozpočtu a kapacit lidských zdrojů. Projektový manažer má pravomoc zadávat úkoly členům projektového týmu v rozsahu jejich schválených disponibilních kapacit. Resource manažer zodpovídá za včasnost a úplnost údajů zadaných disponibilních kapacit. Resource manažer v procesem definovaných intervalech vyhodnocuje a reportuje poměr alokací a vykázaných hodin po jednotlivých projektech za účelem kontroly efektivity využívání zdrojů. Resource manažer v pravidelných intervalech vytváří reporty o stavu plánovaných kapacit a jejich obsah je zpřístupňován projektovým manažerům a liniovým manažerům využívaných zdrojů. Resource manažer řeší s projektovým manažerem a liniovými manažery nápravu při zjištění nesouladů. V případě kolizí lidských zdrojů vypracovává resource manažer ve spolupráci s příslušnými rolemi návrh jejich řešení. Řešením může být zvýšení disponibilních kapacit existujících pracovníků, nominace nových pracovníků, snížení požadavků na daný zdroj, případně nákup externího zdroje nebo posun harmonogramu projektu. Výkonný pracovník vystupuje v procesu řízení lidských zdrojů na ICT projektech jako řízený zdroj, jenž pro projekt vykonává přidělené úkoly v rozsahu své disponibilní kapacity a svých alokací. Výkonný pracovník je zodpovědný za zadání návrhu své disponibilní kapacity ke schválení svým liniovým manažerem do systému pro SW podporu procesu řízení lidských zdrojů na ICT projektech. Výkonný pracovník je zodpovědný za aktualizaci své disponibilní kapacity v procesem definovaných termínech a pomocí SW podpory procesu o její předložení ke schválení svým liniovým manažerem. Výkonný pracovník zodpovídá za řádné a včasné vyplnění výkazů na projektové činnosti v systému na SW podporu procesu. Výkonný pracovník je automatickými notifikacemi ze systému SW podpory procesu informován o své disponibilní kapacitě a provedených alokacích na projekty a o změnách ve svých alokacích. V procesu dále figuruje zákazník, jenž skrze ticketovací nástroj (HelpDesk, ServiceDesk) zadává požadavky na projekt. Požadavek zákazníka je po schválení pře-

41

dán do systému k realizaci projektu a k umožnění vykazování času na projekt a alokování kapacit na jeho realizaci. Dalším účastníkem procesu je finanční systém, který slouží k evidenci mzdových a jiných nákladů každého zaměstnance. Finanční systém slouží k převedení vykázaných a schválených hodin odpracovaných na projektech, neprojektových činnostech a režii na jejich finanční hodnotu. Reportování finančních dat je omezeno na definovanou skupinu projektového manažera u projektů jím řízených a pro liniového manažera pro informace napříč projekty o hodnotě práce jím řízených pracovníků. Finanční systém dále slouží k evidenci zatříděného majetku, který byl dodán v rámci projektu. Personální systém slouží k evidenci zaměstnanců společnosti včetně jejich stavu, rolí v systému a přiřazených oprávnění. Personální systém je integrován do systému SW podpory procesu k jednoznačné identifikaci pracovníka, který je zařazen do konkrétní role pracující na projektu. Personální systém je integrován na ticketovací nástroj pro identifikaci žadatele o projekt. Systém sloužící k evidenci incidentů a požadavků zákazníků a zaměstnanců. Ticketovací nástroj je jediným místem komunikace zákazníka s ICT a slouží i ke sběru a schválení požadavků na projekt. 3.3.3

Přehled způsobů užití SW podpory procesu

Při identifikaci množství způsobů užití (use-case) nového systému jsem identifikoval pět hlavních způsobů užití, které zajišťují pokrytí všech požadavků na systém.

42

Obrázek 8: Model způsobů užití systému uc Use Case Model

«internal w orker» Zaměstnanec

System

«internal w orker» Resource Manager

Vytváří

Eviduje a aktualizuje UC001 Reporting Je zdrojem

Kontroluje Vykazuje

Finanční systém Kontroluje

UC002 Ev idence disponibilních kapacit

Schvaluje Slouží k identifikaci HR systém

Schvaluje výkazy na režii

UC003 Vykazov ání

«internal w orker» Liniov ý Manager

Slouží k identifikaci

Vytváří a aktualizuje

Schvaluje výkazy na neprojektové změny

UC004 Ev idence číselníku aktiv it Je vstupem pro

Schvaluje výkazy na projekt HelpDesk

Vytváří a aktualizuje UC005 Alokace kapacit

«business actor» Zákazník

Vytváří a aktualizuje Zadává alokace «internal w orker» Manažer neproj ektov é změny Zadává alokace

«internal w orker» Proj ect Manager

Hlavním způsobem užití je use-case Alokace kapacit. Tento use-case umožňuje vytvářet a aktualizovat plán alokace zdrojů podle plánovaných činností. Umožňuje zpřesnit požadavky na následující plánovací období. Tento use-case umožňuje předávat výkonnému pracovníkovi informace o změnách v jemu přiřazených alokacích. Dalším důležitým use-case je evidence disponibilních kapacit. Tento use-case umožňuje liniovému manažerovi výkonného pracovníka zadání disponibilní kapacity do systému pro SW podporu procesu. Tento use-case umožňuje aktualizaci disponibilní kapacity a realizaci pracovního postupu na schválení disponibilní kapacity jednotlivých výkonných pracovníků. Neméně důležitým je use-case vykazování, který umožňuje přiřazení projektových činností pracovníkům k vykazování jejich odvedených činností. Tento use-case také umožňuje nastavit pracovní postup schválení vykázaných hodnot projektovým 43

manažerem a po schválení odeslat souhrny do finančního systému. Vykazování umožňuje zaměstnancům vykazovat odvedenou práci a čas. Správné fungování předešlých use-case podporuje use-case Evidence číselníku aktivit, který umožňuje tvorbu a aktualizaci číselníku projektových činností. Umožňuje integraci na ticketovací nástroj k příjmu informací o projektech. Umožňuje tvorbu a aktualizaci číselníku projektových činností. Poslední důležitý use-case je Reporting. Use-case reporting umožňuje v procesem definovaných či ad/hoc intervalech vytvářet reporty o poměru alokací a vykázaných hodin po jednotlivých projektech za účelem kontroly efektivity využívání zdrojů. 3.3.4

Specifikace způsobů užití

Specifikaci způsobu užití jsem připravil pro use-case Reporting, Evidence disponibilních kapacit a vykazování. Tyto use-case jsou klíčové pro fungování systému a budou zajištěny samostatnými moduly. Jsou však také klíčové pro ověření možností a funkcionalit prostředí Sharepoint, pro identifikaci vstupů do kalkulace komplexity prostředí z pohledu způsobu užití, prostředí i technické komplexity. Vzhledem k poučení, které pro čtenáře plyne z implementace těchto use-case jsem tyto ponechal v hlavní části práce a detailně je zde popisuji. Tabulka 5: UC Reporting

V pravidelných, procesem či ad-hoc, definovaných intervalech vytvářet Popis

reporty o poměru alokací a vykázaných hodin po jednotlivých projektech neprojektových činnostech a režii za účelem kontroly efektivity využívání zdrojů. Systém je funkční.

Vstupní

Uživatel je zalogován do systému.

podmínka

Existuje role s požadavkem na vytvoření reportu. Aktér

Systém 44

Základní tok

1. aktér otevře modul Reporting

2. systém zobrazí úvodní obrazovku

3. aktér zvolí typ reportu 4. aktér zvolí role k reportování 5. aktér zvolí reportované období 6. aktér zvolí generování reportu

7. systém vygeneruje report 8. systém zobrazí report a nabídne možnosti uložit/odeslat/zavřít 10. systém provede volbu a zobrazí

9. aktér zvolí z nabídky

příslušný dialog

11. aktér vyplní požadované údaje

11. systém provede volbu a ukončí zpracování 12. systém uzavře modul

Alternativní

tok 1. aktér otevře modul Reporting

01


3. v systému neexistuje požado-

2. systém zobrazí úvodní obrazov-

vaný typ/role/ období k reportu

ku

4. aktér zadá požadavek do SD k vytvoření reportu 5. aktér ukončí práci v modulu

Výstupní podmínka Seznam aktérů

6. systém uzavře modul

Report je odeslán/ uložen/ zobrazen, zpracování reportu je ukončeno, modul reporting je uzavřen resource manažer

45

Use-case reporting je klíčovým případem užití systému pro roli resource manažer. Slouží resource manažerovi k plnění hlavních činností jeho role v procesu řízení lidských zdrojů na ICT projektech. Tabulka 6: UC Evidence disponibilních kapacit umožňuje liniovému manažerovi zadání disponibilní kapacity svých pracovníků do systému.

Popis

Umožňuje aktualizaci a realizaci WF na schválení disponibilní kapacity jednotlivých pracovníků.

Vstupní podmínka

Systém je funkční. Uživatel je zalogován do systému. Existuje role s požadavkem a oprávněním na evidování disponibilních kapacit Aktér

Zá kladní tok

Systém

1. aktér otevře modul Disponi-


bilní kapacity (DK) 3. aktér zvolí Roli a osobu k evidování DK 4. aktér zvolí období ke změně DK 5. aktér zvolí Uložení

6. systém provede změny 7. systém zobrazí informaci o výsledku operace

8. aktér zvolí z nabídky Alternativní tok 01


1. aktér (RM/LM) otevře modul


Disponibilní kapacity (DK)

46

3. Role nebo osoba není v systému zavedena 4. aktér zvolí Zadat roli do sys-

5. systém zobrazí formulář

tému 6. aktér vyplní požadované informace

8. systém vytvoří roli a zadá požada-

7. aktér zvolí Uložení

vek na HR systém k založení osoby 9. systém zobrazí informaci o výsledku operace

10. aktér potvrdí informaci 11. systém uzavře modul Alterna-

1. aktér (zaměstnanec) otevře

2. systém zobrazí obrazovku s infor-

tivní tok modul Disponibilní kapacity

macemi o vlastní disponibilní kapaci-

02

(DK)

tě

3. aktér potvrdí informaci


Disponibilní kapacita je vytvoVýstupní podmínka

řena, změněna, zrušena nebo Je vytvořena nová role nebo Je zadán požadavek na založení osoby a Modul Reporting je uzavřen

Seznam aktérů

Resource manažer Liniový manažer Zaměstnanec

Use-case evidence disponibilních kapacit je místem propojení liniového a projektového řízení. V rámci tohoto use-case předává či schvaluje liniový manažer část disponibilní kapacity svých výkonných pracovníků pro využití v rámci projektů. Moti47

vací pro tuto aktivitu je eliminace práce pracovníků na režijních činnostech, které nepřinášejí firmě zisk. Tabulka 7: UC Vykazování Umožňuje přiřazení projektových činností pracovníkům k vykazování Popis

činností. Po schválení jsou souhrny předány do fin. systému. Umožňuje zaměstnancům vykazovat odvedenou práci a čas. Systém je funkční.

Vstupní

Uživatel je zalogován do systému.

podmín-

Existuje role s požadavkem a oprávněním na evidování disponibilních

ka

kapacit Aktér

Základní tok

Systém

1. aktér otevře modul Vy-

2. systém zobrazí úvodní obrazovku s histo-

kazování

rií uložených výkazů

3. aktér zvolí Volbu aktivi- 4. systém zobrazí seznam kategorií k vykaty k vykázání 5. aktér zvolí kategorii

7. aktér zvolí 1...n položek a zvolí pokračovat

zování 6. systém zobrazí přiřazené položky této kategorii a tomuto aktérovi 8. systém zobrazí vybrané položky s časovou osou a možností doplnit odpracované hodiny

9. aktér přiřadí počty hodin 10. aktér zvolí Uložení

11. systém provede uložení 12. systém spustí WF schválení pro každou vyplněnou položku 13. systém zobrazí informaci o výsledku 48

operace 14. aktér potvrdí informaci


Alterna-



tivní tok

kazování


01 3. aktér zvolí kopírování výkazu do aktuálního vý-

4. systém provede kopírování

kazu 5. systém zobrazí vybrané položky s časovou osou a možností doplnit odpracované hodiny 6. aktér přiřadí počty hodin 7. aktér zvolí Uložení

8. systém provede uložení 9. systém spustí WF schválení pro každou vyplněnou položku 10. systém zobrazí informaci o výsledku operace

11. aktér potvrdí informaci


Alterna-



tivní tok

kazování


02 3. aktér zvolí historický/uložený výkaz

4. systém zobrazí výkaz 49

5. aktér zvolí Volbu aktivi- 6. systém zobrazí seznam kategorií k vykaty k vykázání 7. aktér zvolí kategorii

9. aktér zvolí 1...n položek a zvolí pokračovat

zování 8. systém zobrazí přiřazené položky této kategorii a tomuto aktérovi 10. systém zobrazí vybrané položky s časovou osou a možností doplnit odpracované hodiny

11. aktér přiřadí počty hodin 12. aktér zvolí Uložení

13. systém provede uložení 14. systém spustí WF schválení pro každou vyplněnou položku 15. systém zobrazí informaci o výsledku operace

Výstupní podmínka

Výkaz je uložen Výkaz je odeslán ke schválení Modul Výkaz je uzavřen Resource manažer Projektový manažer

Seznam

Manažer neprojektové

aktérů

změny Liniový manažer Zaměstnanec

Use-case vykazování slouží výkonným pracovníkům k zaznačení odvedené práce, na kterou byli alokováni do systému. Je také místem, kde dochází ke kontrole a schvalování rozsahu odvedené práce a zpětné kontrole správnosti plánování pracnosti projektů a skutečné utilizaci lidských zdrojů.

50

3.3.5

Prostředí pro implementaci SW podpory

Pro implementaci nástroje na SW podporu procesu řízení lidských zdrojů na ICT projektech jsem zvolil prostředí Microsoft SharePoint Server ve verzi 2010. Pro snazší implementaci by bylo vhodné využít nástroj pro tvorbu Workflow například Nintex Workflow, který však ve stávající infrastruktuře nemám k dispozici. Nintex Workflow 2010 je produkt australské společnosti Nintex, která je certifikovaným Gold partnerem společnosti Microsoft. Produkt je plně integrován s produkty společnosti Microsoft a vhodně doplňuje portálovou platformu Microsoft SharePoint 2010. V průběhu implementace prostředí jsem využil nástroj Microsoft Infopath k úpravě a publikaci složitějších formulářů a dialogových oken. Farma Microsoft Sharepoint je implementována na platformě x86 serverů, implementace v High Availibility (HA) je volitelné, systém by svou povahou neměl být kritický pro chod společnosti. Obrázek 9: Infrastrukturní prostředí SW podpory

Prostředí Sharepoint 2010 bylo napojeno na Active Directory společnosti a poštovní server Exchange 2010. Pomocí této integrace bylo řešeno ověření uživatele, přidělení rolí a oprávnění a odesílání mailů z modulu Reporting. Výhodu využití platformy Sharepoint spatřuji v její snadné rozšiřitelnosti a využití i pro další agendy. Například je zde možnost uživatelsky upravit formuláře, do51

plnit workflow a využít systém i pro podporu řízení jiných než projektových zdrojů. Rozšířením systému a zavedením vykazování času v nástroji i na neprojektové změny, liniovou činnost a režijní činnost by přinesl vedení společnosti ucelený pohled na využití svých lidských zdrojů. Navržené řešení odpovídá potřebám menších až středních firem a je alternativou pro běžně používaná korporátní řešení renomovaných dodavatelů. V rámci navržené architektury bude využito většiny standardně poskytovaných Sharepoint funkcionalit a workflow importovaných z programu Microsoft Visio 2010 do aplikace Sharepoint designer k dokončení a publikování na Sharepoint farmu. V rozsahu mé práce nebylo možné implementovat všechny moduly, scénáře a workflow, ale zaměřil jsem se na ověření pracnosti těch funkcionalit konkrétního usecase, které se v modulech opakují a tím jsem získal potřebnou znalost a schopnost nacenit implementaci systému jako celku. Základní jednotkou pro spolupráci v SharePointu je pracovní prostor. Pracovní prostor je možné vytvořit velmi snadno pomocí průvodce, který je v SharePointu připraven. Jednotlivé pracovní prostory mohou být hierarchicky poskládané. Příkladem může být pracovní prostor některého oddělení, kterému jsou podřízeny pracovní prostory jednotlivých projektů. Pro nás bude hlavním pracovním prostorem prostředí uživatele a jemu budou podřízeny jednotlivé moduly systému. V systému SW podpory řízení lidských zdrojů na ICT projektech jsem využil komponenty seznam, knihovna dokumentů, kalendář a knihovna úkolů. Seznam bych mohl popsat jako zjednodušenou knihovnu dokumentů, která nám dává další možnosti definice oprávnění, spolupráce s dalšími aplikacemi jako je například Microsoft Access. Hlavní entitou v seznamu není dokument, ale jsou to jednotlivá metadata, která mohou být vytvářena a provazována s jinými seznamy a knihovnami dokumentů. Příkladem může být seznam pro evidenci disponibilních kapacit.

Obrázek 10: Seznam disponibilních kapacit

52

Knihovna dokumentů je určená především k ukládání dokumentů všeho druhu. Ukládání dokumentů do knihovny není nijak vázáno na jejich formát, takže do knihovny lze uložit dokument prakticky v kterémkoliv formátu. Pro potřeby mého systému pro SW podporu procesu je knihovna dokumentů určena pro vytváření, ukládání a sdílení reportů. Obrázek 11: Knihovna dokumentů

Komponentu kalendář jsem využil pro podporu vyhledávání volných zdrojů v jednotlivých rolích a vizualizaci informací o využití jednotlivých zdrojů. Obrázek 12: Komponenta kalendář

Komponenta úkol je speciální formou seznamu. Tato komponenta eviduje veškeré úkoly přiřazené v rámci jednotlivých pracovních postupů. Komponenta úkol je centrálním místem, kde pracovníci ve všech rolích naleznou své přiřazené úkoly. 53

Obrázek 13: Komponenta úkol

Ke knihovnám dokumentů a seznamům jsou připojeny pracovní postupy, které umožňují definovat schvalovací postupy a úkoly ke konkrétním typům dokumentů, případně na místa, kam se dokumenty ukládají. Uživatelům definovaným v postupech pak jsou přiděleny úkoly s konkrétním datem plnění a odkazem na položku seznamu či dokument. Obrázek 14: Úkol pracovního postupu

K vytvoření a nasazení složitějších formulářů na webu SharePoint jsem využil aplikaci InfoPath Designer, která umožňuje zjednodušit, zpřehlednit a urychlit vytváření pokročilých webových formulářů. Díky integraci s pracovními postupy na webech SharePoint lze tvořit pokročilé formuláře podporující firemní procesy, a to vše uživatelsky, bez nutnosti programování. Aplikaci SharePoint Designer jsem využil tam, kde předdefinované pracovní postupy prostředí Sharepoint již nebyly dostatečné. Sharepoint Designer je dalším stupněm pro pracovní postupy SharePointu a lze v něm zpracovat složitější požadav54

ky, které nejsou obsaženy v základních šablonách. Pomocí Sharepoint Designer lze definovat vlastní pracovní postup skládáním jednotlivých aktivit. Takto vytvořený pracovní postup se následně publikuje do SharePointu a uživatelé jej pak mohou používat jako kterýkoliv standardní postup dodávaný s produktem. Na obrázku je zobrazen začátek přípravy pracovního postupu pro modul Vykazování. Pracovní postup může být spuštěn automaticky při vytvoření nové položky, při jakékoliv změně, může reagovat na stav hodnot ve formuláři nebo může být spouštěn manuálně. V systému SW podpory jsem využil všechny varianty spouštění pracovních postupů. Obrázek 15: Pracovní postup modulu vykazování

Pro modul Reporting, rychlejší práci s daty při vykazování a alokování zdrojů jsem využil služby prostředí Sharepoint 2010 Excel Services, InfoPath Services a Access Services Obrázek 16: Komponenty použité při implementaci systému 55

cmp Component Model

InfoPath

«use» Sharepoint designer «use»

InfoPath form Serv ices

Access serv ices

Konfigurece a úpravy «use» Konfigurece a úpravy

Konfigurece a úpravy Modul Vykazov ání

Modul Ev idence disponibilních kapacit

Zdroj dat

«use»

Excel Serv ices

Modul Reporting «use»

Ověření uživatele

Zdroj dat «use»


Exchange Serv er

«use»

Modul uživ atel

Modul Ev idence číselníků

Modul Alokace Ověření uživatele


Single Sign On

Activ e Directory

Ve finančním shrnutí implementace SW podpory prostředí nejsou zahrnuty licence komponent prostředí Microsoft Sharepoint. Toto prostředí již ve společnosti bylo plně zalicencováno a lze jej nahradit jakýmkoliv jiným nástrojem pro tvorbu pracovních postupů. 3.3.6

Finanční shrnutí implementace SW podpory

Pro kalkulaci nákladů na vývoj systému jsem použil metodu USE CASE POINT. Tato technika je založená na odhadu složitosti jednotlivých use case (případů užití), které popisují chování mezi systémem a jeho okolím z pohledu uživatele informačního systému.

56

3.3.6.1

Komplexita uživatelů systému

Obsahuje popis složitosti systému z pohledu interakce s jinými typy uživatelů či systémů. Zjištění aktéři se dále rozčlení do třech kategorií: jednoduchý – průměrný složitý. V systému nebude žádný uživatel s jednoduchým přístupem a nejnižším multiplikátorem 1. Definice jednoduchého uživatele systému odpovídá jiným systémům, které s naším systémem budou komunikovat skrze předdefinované rozhranní (API). Klíčovým elementem je, že komunikace se systémem bude probíhat skrze specifické a velice dobře definované rozhranní. V systému bude jeden typ uživatele s průměrně složitým přístupem a středním multiplikátorem 2. Definice průměrně složitého uživatele systému odpovídá jiným uživatelům, či jiným systémům, které s naším systémem budou komunikovat skrze složité a více komplexní rozhranní (API) V systému budou 3 typy komplexních uživatelů s nejvyšším multiplikátorem 3. Tabulka 8: Shrnutí komplexity uživatelů systému Aktéři

Multiplikátor

Jméno aktéra

Simple

0

Finanční systém

Simple

0

HR Systém

Simple

0

Helpdesk

Average

2

Resource manažer

Complex

3

Project manažer

Complex

3

Liniový manažer

Complex

3

Pracovník

57

Definice komplexního uživatele spočívá v tom, že využívá náš systém skrze grafické rozhranní. Jiná definice spočívá v tom, že popisuje komplexního uživatele jako uživatele, který využívá náš systém nepredikovatelným způsobem. Komplexita způsobů užití

3.3.6.2

Komplexita zpusobu uzití vychazí z poctu transakcí realizovanych v ramci konkretního zpusobu uzití. V systemu nebude zadny use-case s nejnizsím multiplikatorem, ktery by mel mene nez 3 transakce. V systemu budou 3 use-case s poctem 4 az 7 transakcí. Tyto use-case mají multiplikator 10. V systému budou 2 komplexní use-case, které mají více než 7 transakcí a tedy nejvyšší multiplikátor 15. Tabulka 9: Komplexita způsobů užití Individuální Use Cases

Multiplikátor Název Use Case

1

Average

10

2

Average

10

3

Complex

15

4

Average

10

5

Complex

15

UC001 Reporting UC002 Evidence disponibilních kapacit UC003 Vykazování UC004 Evidence číselníku aktivit UC005 Alokace kapacit

Jednotlivé use-case jsou rozděleny podle počtu transakcí do kategorií a každé kategorii je přidělena určitá váha. Výsledek získáme roznásobením vah kategorií a součtem přes jednotlivé typy use-case.

58

Faktor komplexity prostředí

3.3.6.3

Vliv na odhad doby realizace projektu má také skutečnost související s dovednostmi a znalostmi zaměstnanců. Tyto vlivy jsou zastřešeny tzv. faktorem prostředí. Tabulka 10: Faktor komplexity prostředí


1

Multiplikátor

Obeznámenost s projektem, projektovým modelem (RUP)

Váha (0-5)

1,5

4

2

Zkušenost s aplikací

0,5

2

3

Zkušenosti s objektovou orientací

1

3

4

Kapacita vedoucího analytika

0,5

4

5

Motivace

1

1

6

Stabilita požadavků

2

2

7

Pracovníci na částečný úvazek

-1

0

8

Složitost programovacího jazyka

-1

3

Kalkulované EF

0,98

Hodnocení faktoru komplexity prostředí realizujeme tak, že nejprve ohodnotíme 8 faktorů týkajících se prostředí, ve které IS vzniká. Máme opět k dispozici stupnici od 0 do 5 (0 – bezvýznamný, 5 – velmi významný dopad). Hodnoty následně roznásobíme váhami a sečteme výsledky. Tyto se dosadí do vzorce výpočtu faktoru složitosti prostředí – ef. 59

Faktor technické komplexity

3.3.6.4

Pro dokončení výpočtu celkové složitosti implementace systému jsem ještě určil tzv. technický faktor, který je ovlivněn i úrovní znalostí zapojených zaměstnanců. Úkolem je ohodnotit 13 faktorů, které souvisejí s technickou stránkou vytvářeného systému. Hodnotící stupnice obsahuje hodnoty od 0 do 5. Hodnota multiplikátoru 0 znamená, že jeho vliv na systém je bezvýznamný, v případě multiplikátoru 5 je vliv velmi silný. Tabulka 11: Faktor technické komplexity

Technický faktor

Multiplikátor

Distribuovanost systému

Výpočet (Enter 0-5)

2

3

1

2

Efektivita koncových uživatelů

1

4

Složitost vnitřního zpracování

1

2

Znovupoužitelnost kódu

1

2

Jednoduchost instalace

0,5

1

Jednoduchost užití

0,5

2

Přenositelnost

2

1

Snadnost změny

1

3

Souběžnost

1

2

Nutnost zahrnout speciální bezpečnostní cíle

1

3

Doba reakce nebo požadovaná rychlost zpracování/výkon

60

Závislost na kódu třetích stran

1

0

Školení uživatelů

1

4

Vypočtené TCF

0,915

Postup pro hodnocení faktoru technické komplexity je obdobný jako u faktoru komplexity prostředí, tzn. nejprve ohodnotíme 13 faktorů týkajících se technické stránky vyvíjeného IS. Máme opět k dispozici stupnici od 0 do 5 (0 – bezvýznamný, 5 – velmi významný dopad). Hodnoty (0–5) přidělené každému faktoru se roznásobí jakousi přidělenou váhou, dále se provede jejich součet. Takto získáme tzv. technický faktor (fFactor), který dále dosadíme do vzorce pro výpočet technického faktoru složitosti (technical complexity factor – tcf). 3.3.6.5

Souhrn nákladů na vývoj SW podpory pro proces

Tabulka 12: Souhrn nákladů na vývoj SW podpory pro proces Kalkulace z předchozích kapitol TCF

Faktor technické komplexity

0,915

EF


0,98

UUCP

Komplexita způsobů užití

60

AW

Komplexita uživatelů systému

14

Kalkulace Use Case Points UCP

66,4

Use Case Points Kalkulace předpokládaného úsilí Počet hodin na Use Case Points

61

28

Pracnost hodin:

1 858

Pracnost KČ:

1 857 962 Kč

Celková pracnost na vývoj mnou navrženého systému vychází na 1858 hodin.

Při interní kalkulaci průměrné ceny 1 MD na 8000 Kč vychází náklady spojené s vývojem systému na 1 857 962,40 Kč. Toto je investice byla v kalkulaci business case přechodu na novou verzi systému pro podporu procesu vykazování rozpočítána na odpisované období 6 let a porovnána s cenou investice na implementaci nové verze stávajícího systému, dokoupení licencí modulu vykazování a platbě údržby celého řešení ve stejném odpisovém období 6 let. Stejná kalkulace byla provedena pro nákup nového řešení od jiného dodavatele a útlum stávajícího prostředí. Výsledné rozhodnutí managementu společnosti je vázáno obchodním tajemstvím a nemohu jej ve své práci zveřejnit ani dále komentovat.

62

4 ZÁVĚR Bakalářská práce se zabývá analyzováním oblasti řízení lidských zdrojů na ICT projektech a návrhem softwarové podpory tohoto procesu. V teoretické části mé práce jsem rozkryl základní metodiky, standardy a rámce řízení projektů, vazby a důležitost procesu řízení lidských zdrojů na ICT projektech. Díky zkušenostem z praxe, znalostem získaným během studia na Unicorn College a konzultacím s vedoucím své práce jsem zde uceleně popsal základní rámec, nejdůležitější vlastnosti, schopnosti a oblasti v procesu projektového řízení. V teoretické části bakalářské práce jsem také vydefinoval role, které se účastní dodávky ICT projektů a navrhl způsob, jak tyto role mohou v rámci ICT projektů fungovat a jak mohou být řízeny. Teoretický základ jsem následně využil v praktické části, kde jsem shrnul požadavky na SW podporu procesu a očekávání spojené s implementací takového systému. V této části práce jsem identifikoval aktéry a způsoby užití počítačového systému, který by měl proces řízení lidských zdrojů na ICT projektech podporovat. Vzhledem ke svým znalostem a dostupnosti technologie jsem navrhl způsob implementace systému v prostředí Microsoft SharePoint a realizoval implementaci části tohoto prostředí. Implementace uživatelského rozhraní, tří kompletních modulů včetně pracovních postupů mi dala dostatek informací pro vytvoření finančního rámce pro implementaci celého systému a tedy pro identifikaci časové náročnosti implementace všech use-case. Pro finanční shrnutí implementace SW podpory pro proces řízení lidských zdrojů na ICT projektech jsem využil techniku use case points, která je založená na odhadu složitosti jednotlivých případů užití. Klíčovým prvkem pro správný odhad pracnosti jsou reálné zkušenosti z průběhu implementace systému. Díky implementaci modulu vykazování jsem byl schopen doplnit informace pro definování chování mezi systémem a jeho okolím z pohledu uživatele informačního systému. Vzhledem ke zkušenostem z praktické části jsem byl schopen podpořit rozhodnutí konkrétní společnosti, zda investovat prostředky do koupě balíkového řešení či implementace vlastního systému.

63

5 CONCLUSION This bachelor’s thesis analyzes areas of the human resources management on the ICT projects and proposes software support of this process. In the theoretical part of this thesis basic methods, standards and frameworks of project management are described as well as basic linkages and importance of human resources management on ICT projects. Basic framework of this topic has been described here thanks to my practical experience and knowledge gained on Unicorn College while consulting with professor who supervises my thesis. I have defined roles that take place in ICT projects supply and designed approach of managing and operating them. Theoretical principles were subsequently implemented in practical part of this thesis, where demands on SW support of the process were summed up to give an integrated picture on expectations from implementation of such a system. In this part of the thesis roles and utilization of the system were identified, which is supposed to support human resources management on ICT projects. Based on my knowledge and technology availability I have designed system implementation in Microsoft Sharepoint and partly proceeded to realize implementation of this interface. Implementation of user interface and entire reporting module including workflows created solid foundation to collect information on financial framework of the system implementation and thus, I have identified time demands on implementation of all use-case. I have used the use-case points technique for financial evaluation of implementation of the SW support for human resources process on ICT projects, which is based on the estimation of difficulty of every use. The key attribute for correct estimation of the labor intensity during system implementation are real experience, Due to reporting module implementation I was able to include information to define interaction of the system and its surrounding from the IS user point of view. Experience gained in the practical part of the thesis was used to support investment decision making of particular company on implementation of own system or using package solutions.

64

6 CITOVANÁ LITERATURA Association, IPMA International Project Management. 2014. IPMA International Project Management Association. About IPMA. [Online] IPMA, 2014. [Citace: 24. 04 2014.] http://ipma.ch/about/. DeMARCO, Tom a LISTHER, Timothy. 1999. Peopleware, Productive Projects and Teams, 2nd ed. New York : Dorset House Printing, 1999. ISBN 0-932633-43-9. DOLEŽAL, Jan, MÁCHAL, Pavel a LACKO, Branislav a kol. 2009. Projektový management podle IPMA. Praha : Grada Publishing, 2009. ISBN 978-80-247-2848-3. FOWLER, Martin a HIGHSMITH, Jim. 2001. The Agile Manifesto. místo neznámé : Software Development, 2001. Institute, PMI Project Management. 2012. PMI’s 2012 Annual Report. [Online] PMI, 2012. [Citace: 24. 04 2014.] http://www.pmi.org/About-Us/About-UsAnnual-Report.aspx. KAŽMIERSKY, Tomáš a PELCL, Petr. 2003. Projektové a strategické plánování pro neziskové organizace, Vyd. 1. Praha : Regionální enviromentální centrum: centrum pro komunitní práci, 2003. ISBN 80-902 368-9-8. SCHWABLE, Kathy. 2007. Řízení projektů v IT. Brno : Computer Press, 2007. ISBN 978-80-251-1526-8. SKALICKÝ, Jiří, JERMÁŘ, Milan a SVOBODA, Jaroslav. 2010. Projektový management a potřebné kompetence. Plzeň : Západočeská univerzita v Plzni, Vydavatelství, 2010. ISBN 978-80-7043-975-3. Společnost pro projektové řízení. NÁRODNÍ STANDARD KOMPETENCÍ PROJEKTOVÉHO

ŘÍZENÍ

VERZE

3.2,.

[Online]

[Citace:

26.

04

2014.]

http://www.ipma.cz/web/files/narodni-standard-kompentenci-projektovehorizeni.pdf. ŠTORK, Radim a VITOUŠ, Otto. 2000. RATIONAL UNIFIED PROCESS. Praha : Unicorn Multimedia, 2000. ISBN 80-238-6358-4. WYSOCKI, Robert. 2012. Effective Project Management: Traditional, Agile, Extreme. Indianapolis : John Wiley&Sons, 2012. ISBN 978-1-118-01619-8. 65

7 SEZNAM OBRÁZKŮ Obrázek 1: Trojimperativ projektového řízení............................................................................ 15 Obrázek 2: Iterativní vývoj SW dle RUP ......................................................................................... 17 Obrázek 3: Metodické souvislosti projektového řízení ............................................................ 18 Obrázek 4: Základní rámec řízení projektů .................................................................................. 20 Obrázek 5: Okruhy elementů způsobilosti .................................................................................... 24 Obrázek 6: Grafické znázornění procesu řízení lidských zdrojů .......................................... 37 Obrázek 7: Přehled aktérů systému SW podpory....................................................................... 40 Obrázek 8: Model způsobů užití systému ...................................................................................... 43 Obrázek 9: Infrastrukturní prostředí SW podpory .................................................................... 51 Obrázek 10: Seznam disponibilních kapacit ................................................................................. 52 Obrázek 11: Knihovna dokumentů .................................................................................................. 53 Obrázek 12: Komponenta kalendář ................................................................................................. 53 Obrázek 13: Komponenta úkol .......................................................................................................... 54 Obrázek 14: Úkol pracovního postupu ........................................................................................... 54 Obrázek 15: Pracovní postup modulu vykazování..................................................................... 55 Obrázek 16: Komponenty použité při implementaci systému .............................................. 55

66

8 SEZNAM TABULEK Tabulka 1: Seznam používaných zkratek Tabulka 2: Finanční kritéria pro realizování projektu Tabulka 3: Primární zainteresované strany Tabulka 4: Způsob čtení logického rámce Tabulka 5: UC Reporting Tabulka 6: UC Evidence disponibilních kapacit Tabulka 7: UC Vykazování Tabulka 8: Shrnutí komplexity uživatelů systému Tabulka 9: Komplexita způsobů užití Tabulka 10: Faktor komplexity prostředí Tabulka 11: Faktor technické komplexity Tabulka 12: Souhrn nákladů na vývoj SW podpory pro proces

67

UNICORN COLLEGE. Katedra informačních technologií BAKALÁŘSKÁ PRÁCE. Řízení lidských zdrojů na ICT projektech. Autor BP: Jiří Šulc

Recommend Documents