Projekt lze definovat jako jedinečný neopakovatelný proces, který se skládá z řady elementárních činností či úkonů, který má daný čas zahájení a ukončení, který směřuje k dosažení určitého cíle a který se musí vyrovnat s omezeným časem, náklady a zdroji. Projektem může být například:

• Přechod z tradičního řízení organizace na procesní řízení.
• Pořízení a zavedení informačního systému.
• Pořízení výkonnějšího stroje a jeho uvedení do provozu.
• Zavedení systému vzdělávání zaměstnanců.
• Vývoj nového výrobku a jeho uvedení do výroby a na trh.
• Realizace jedinečné zakázky pro odběratele (např. návrh, výroba a instalace schodiště).

Jednotlivé projekty velmi často nejsou zcela nezávislé, některé projekty z výše uvedených příkladů však mohou být součástí jiného většího projektu, například projektu „Zvýšení produktivity organizace o 10 procent“, podobně součástí projektu „Přechod na procesní řízení“ může být projekt „Pořízení procesně orientovaného IS“ apod. Kromě standardních projektů musíme umět projektově řídit i „ve velkém“, tedy celé skupiny projektů jako projekt. Podstatou projektového řízení je plánování projektu a řízení jeho realizace, včetně řízení změn a rozporů mezi plány a realitou. V rámci plánování projektu se sestavuje několik projektových plánů, které lze rozdělit takto:

• CO – popisuje předmět projektu (cíl), včetně specifikace všech dílčích a detailních jeho parametrů.
• JAK – identifikuje činnosti (úkony) včetně jejich pracnosti, které je nutné uskutečnit pro dosažení cíle projektu, a uspořádá je do smysluplné posloupnosti. Zde je patrná teoretická kritická cesta.
• S KÝM – plánuje využití zdrojů (lidé, prostředky, …) v závislosti na jejich kompetencích v jednotlivých činnostech projektu, tedy přiřazuje zdroje k činnostem.
• KDY – vyjadřuje časový plán (harmonogram), kdy se budou projektové činnosti uskutečňovat, obvykle v závislosti na disponibilitě zdrojů. Zde je již patrná plánovaná kritická cesta včetně všech rezerv a prodlev.
• ZA KOLIK – plánuje náklady potřebné na uskutečnění projektu (rozpočet).

Řízení realizace projektu fakticky znamená udržet na plánované úrovni „trojimperativ“ projektu (viz obrázek), tedy:

• Dosáhnout cíle (předmět projektu) v plánovaném rozsahu a kvalitě.
• Dodržet stanovený časový plán pro jednotlivé milníky projektu i celý projekt.
• Nepřekročit stanovené náklady.

Je zřejmé, že smysluplná změna na některé ose trojimperativu kvalitního projektového plánu, vyvolá i změny na osách jiných. Zejména zvýšení rozsahu či kvality předmětu projektu vyvolá zvýšení nákladů a obvykle i posun termínu dokončení.

V praxi není výjimkou, spíše je běžné, že realizace projektů se značně rozchází s projektovými plány, takže končí se zpožděním, nenaplňuje zcela cíl a očekávání a navíc významně překračuje původní rozpočet (Vloni jsem napsal pro IT Systems článek o kritických místech ERP projektů, kde jsem použil slavný citát slavného pruského generála Helmuta von Moltkeho: „Žádný plán nepřežije střetnutí s nepřítelem.“ Ten člověk byl zřejmě prvním projektovým manažerem).

Co je příčinou? Lze příčiny správně identifikovat, aby došlo k poučení? Velmi pohodlné je od boku říci, že projekt byl špatně řízen, že neměl dostatek zdrojů, že byl obsazen neschopnými pracovníky, že účastníci nebyli dostatečně motivováni, …, že prostě někdo něco při realizaci projektu udělal špatně.

To ovšem nemusí být vždy pravda, neboť k problémům dochází i při dobře řízené realizaci projektu. Často je totiž významný rozdíl mezi tím, v jakém rozsahu byly činnosti plánované a v jakém rozsahu byly činnosti realizované. Objevují se vícepráce. A obvykle je pravdou, že činnosti realizované navíc nebylo možné pro dosažení cíle vynechat – projekt byl tedy špatně naplánován. Nejčastější příčinou špatného plánování projektu bývá:

1. Podcenění rizik, tedy nebyla v projektu plánována preventivní opatření ani potřebné rezervy na případná nápravná opatření při nenadálých situacích. Například došlo k nepředpokládaným změnám reálného světa (konkurence, státní správa, vliv jiných souvisejících projektů, …), na které se muselo v projektu reagovat. A to obvykle pod časovým tlakem - jenže unáhlené rozhodnutí nemusí být (a často není) to nejlepší. I mistr tesař se někdy utne.
2. Předmět projektu byl nedostatečně či nepřesně specifikován, tedy i navazující projektové plány nebyly správné. Toto je identifikováno až v průběhu projektu, mnohdy těsně před jeho dokončením, takže se musí řada činností provádět opakovaně s dalšími náklady, další nové činnosti se musí realizovat navíc, aneb jedna chyba sto jiných za sebou táhne, - a frustrace všech účastněných je nevyhnutelná.

Jak se vyvarovat podobných chyb v plánování projektu?

Ad 1) Kdo je připraven, není ohrožen. Preventivní práce s riziky nám zajistí, že v případě jejich projevu nejsme zaskočeni a dokážeme na ně s chladnou hlavou a ihned reagovat třeba navýšením rozpočtu, změnou harmonogramu, změnou kvality a rozsahu předmětu projektu anebo i zastavením projektu.

Ad 2) Formuluj přesně. Kvalitní specifikace předmětu projektu nám usnadní správné sestavení zbývajících projektových plánů. Čím přesněji je specifikován předmět projektu, tím přesněji je možné specifikovat plánovaný rozsah prací a jejich strukturu, také tím významně roste pravděpodobnost, že projekt bude možné úspěšně řídit k naplnění výchozích představ. Skutečně se můžeme vyhnout zbytečným nákladům navíc a v cíli mohou být naplněna očekávání. Je tedy zřejmé, že jedině přesně specifikovaný cíl projektu popsaný detailními a přesnými parametry umožní správné a plnohodnotné plánování a tedy i následné řízení projektu – je tedy i základem projektového řízení. Na druhou stranu je třeba zmínit, že u projektů určitého typu nelze na jejich počátku přesně specifikovat všechny parametry, neboť se budou určovat až na základě dílčích výsledků projektu – význam řízení rizik, jako disciplíny projektového řízení, pak velmi stoupá.

IT a projektové řízení

Pokud se budeme zabývat podporou projektového řízení ze strany informačních technologií, pak nás musí zajímat, jak je podporován každý směr trojimperativu a jak je projektové řízení integrované v rámci firemního informačního systému (obvykle ERP) do firemních procesů.

Začneme-li pátrat, co nabízí informatický trh pro podporu projektového řízení, najdeme rychle řadu nástrojů (častěji solitérních) pro dva ze tří aspektů trojimperativu:

• časový plán – softwarové nástroje pro plánování a řízení času, které využívají Ganttův diagram (síťový diagram, …),
• rozpočtované náklady – softwarové nástroje pro plánování a řízení nákladů (těmi disponuje většina ERP systémů, ale postačí i tabulkový procesor).

V předchozí části tohoto článku jsem však uvedl, že za nejdůležitější pro projektový plán považuji třetí aspekt, a to parametry předmětu projektu, tedy přesnou specifikaci předmětu projektu reprezentovanou řadou parametrů a jejich hodnot, protože z něj se teprve odvozují zbývající projektové plány. Zde už to s IT podporou tak slavné není. Při prvním pohledu na předměty projektu (cíle) je totiž patrné, že bývají velmi různorodé. Nelze tedy dopředu připravit množinu všech typových parametrů, kterými by se dal každý předmět projektu popsat. Navíc některé parametry se uplatní jen v závislosti na jiných parametrech.

Můžeme si tuto skutečnost dokumentovat na následujících dvou příkladech:

Příklad 1: Vydání knihy je typický příklad řízeného projektu. Na základě stanovení tématu pro určitou cílovou skupinu a po nalezení vhodného titulu je nutno co nejpřesněji formulovat výsledný cíl projektu – hotovou knihu.

Příklad 2: Akce pro zákazníky (event) je typická zakázka pro marketingovou agenturu, řízená jako projekt, jehož základem musí být co nejpodrobnější scénář výsledné akce s popisem všech detailů a variant.

Detailní představa výsledné knihy, resp. eventu je pak východiskem pro rozplánování ostatních částí projektu (jak, s kým, kdy a za kolik).

Nakladatel i produkční agentura si logicky budou chtít popsat cíl svého projektu zcela odlišnými parametry. Měli by tedy mít možnost si parametry sami vymyslet a v systému sami vytvořit.

Co by tedy měl SW (informační systém - ERP) umět pro popis cíle projektu:

• Uživatelsky definovat typové parametry předmětu projektu včetně jejich souvislostí a závislostí (hierarchie), což pro naše příklady to znamená:
  Kniha - ilustrace (počet, styl, ilustrátor, formát, barvy..), podoba knihy (vazba, papír, typ písma, formát…), marketingové faktory (anotace, obálka, cena, PR info, náklad…) atd.
  Event - místo (lokalita, velikost, ubytování, doprava…), občerstvení (úroveň, množství, složení…), hudba (styl, délka produkce, velikost tělesa…), program (počet vstupů, typ vstupu, délka…), propagace (plakáty, pozvánky, inzerce…) atd.
• Uspořádat tyto parametry do smysluplných okruhů dle typů projektu, aby se k popisu cíle projektu určitého typu užívaly jen relevantní parametry, což pro naše příklady znamená:
  Kniha - projekt „Vydání knihy“ lze dále rozdělit na další podtypy, například vydání paperbacku, knihy v pevné knižní vazby nebo elektronické knihy. Každá tato varianta na sebe váže změnu parametrů i v ostatních skupinách (jiné ilustrace, jiný papír, jiná cena, jiné PR…)
  Event - „suchá“ a „mokrá“ varianta, tzn. příprava akce pro slunečné a deštivé počasí. Souvislost přesného popisu cíle projektu a řízení rizik (viz výše) je zde nasnadě.
• Přehledně a uspořádaně zobrazovat hodnoty parametrů projektu, například formou stromu se signalizací všeho významného.
• Umožnit novému projektu zdědit (automaticky založit) strukturu i hodnoty parametrů od již existujícího projektu v několika úrovních příbuznosti, čímž se významně usnadní obsluha.
• Propojit parametry cíle projektu se souvisejícími firemní procesy, tzn. umožnit, aby některé typy a hodnoty parametrů iniciovaly či jinak ovlivňovaly např. procesy v oblasti nákupu, výroby, prodeje, řízení projektů, …(příklady jsou uvedeny v následující kapitole).
• Automatizovaně porovnávat plánované a dosažené hodnoty parametrů s případnou eskalací problému vedoucímu projektu (může vést na změnu projektových plánů, zastavení realizace projektu apod.).

Všechno souvisí se vším

Projektové řízení nevisí ve vakuu, naopak velmi intenzivně souvisí s ostatními firemními procesy, které v dané organizaci běží a jsou spravovány/řízeny firemním ERP, například:

• V projektu „Vývoj nového výrobku“ budou potřebné určité materiály či subdodávky, tedy je nutné v rámci některé projektové činnosti iniciovat a řídit nějaký nákupní proces (např.: požadavek nákupu – schválení – objednávka – přijetí – došlá faktura/DPH – zaplacení – účtování nákladů). Podobně bude nutné otestovat jeho výrobu, tedy iniciovat a řídit nějaký výrobní proces (např.: požadavek na testování ve výrobě – jeho schválení – plánování interní výrobní zakázky – realizace zakázky – spotřeba materiálu a času – vyhodnocení – účtování nákladů). Dále se může jednat o obchodní procesy, kdy jsou vzorky výrobku testovány na trhu apod.
• Z projektu „Pořízení výkonnějšího stroje“ se kromě nákupních procesů budou iniciovat procesy směřující k průzkumu trhu se stroji, následně i procesy související se zaškolením obsluhy apod.

Ale vše může být i naopak, tedy procesy projektového řízení budou iniciovány a řízeny z jiných firemních procesů, například: Je-li podnikatelskou oblastí kusová zakázková výroba, pak každý obchodní případ musí být individuálně posouzen (konstrukce, použitý materiál, způsob dopravy, stanovení ceny atd.), a to není nic jiného než projekt, jehož cílem je návrh výrobku včetně ceny. Takže z obchodního procesu (např. poptávka – projekt – nabídka) se iniciuje, tedy zakládá, plánuje a následně řídí proces „Návrh zakázkového výrobku“, který svým pojetím odpovídá projektovému řízení. Nastíněná souvislost projektového řízení a ostatních firemních procesů vyžaduje určitou integraci projektového řízení a ERP, která musí zejména zajistit:

• Vzájemnou návaznost (tedy i možnost je iniciovat) firemních procesů s procesy projektového řízení a naopak. Z každého z nich musí být vidět, v jakém stádiu se nachází ten druhý.
• Sdílení nebo alespoň mapování klíčových objektů na sebe (adresáti, zdroje, projekt, předmět projektu, …).
• Sdílení dokumentů, které se týkají projektu a současně dalších firemních procesů (např. faktura, objednávka, smlouva, …).
• Komunikaci mezi členy projektového týmu (zdroji) a vlastníky souvisejících procesů.
• Jednotnost manažerských údajů o projektu (souvisejících projektech) v rámci manažerských systémů i účetnictví.

Rozsah požadavků na integritu mezi řízením procesů a ERP systémem je skutečně netriviální a zřejmě není snadné je vždy naplnit. Faktem je, že o smysluplné integraci je možné hovořit pouze v případě, že ERP systém je procesně orientovaný. Ideální zřejmě je, pokud je projektové řízení součástí ERP systému jako jeden z modulů. V opačném případě jsou kladeny vysoké nároky na integrační možnosti ERP systému a systému projektového řízení anebo se budou údaje zadávat duplicitně se všemi negativy, které duplicitní data představují.

Závěr

Výše uvedené skutečnosti lze závěrem shrnout do dvou doporučení, která by měl vzít v úvahu každý, kdo chce skutečně uplatnit projektové řízení v praxi. Doporučení první - nepodceňujte přesnou specifikaci cíle a jeho popis detailními strukturovanými parametry. Ušetříte si řadu překvapení a rozčarování. Doporučení druhé - neizolujte řízené projekty od ostatních, „běžných“ firemních činností. Teprve v synergii s ostatními firemními procesy se projektové řízení stává silnou zbraní.

Ing. Jaroslav Janda Autor článku je ředitelem společnosti BM Servis s.r.o.