facebook LinkedIN LinkedIN - follow
IT SYSTEMS 7-8/2009 , ERP systémy

Úskalí nástrojů pro projektové řízení

Petr Kincl


Jen malé procento projektů v oblasti IT je dokončeno se stoprocentním úspěchem, tedy realizovaných včas, v požadované kvalitě a při dodržení plánovaného rozpočtu. Příčinou těchto neúspěchů je obvykle špatné vybalancování rovnováhy mezi mnoha faktory a zdroji, které úspěch projektů ovlivňují. Pro sledování všech těchto činitelů přitom již existují metodiky a nástroje, které umožňují i složitější projekty úspěšně řídit. Jak si vhodný nástroj pro projektové řízení vybrat a nasadit jej ve vlastní organizaci?


Jednoznačně nelze říci, že by existoval jeden konkrétní nástroj, který by pokryl všechny potřeby projektového manažera a dalších nedílných uživatelů. Vždy to bude o kompromisu funkcionalit nástroje, vynakládaných finančních prostředcích a skutečných potřebách všech uživatelů. Proto je dobré vědět, jaké funkce dnešní nástroje poskytují a jaká mají případná omezení.
Nástroje lze obecně kategorizovat do dvou skupin. První skupinou je tzv. open source sofware pro řízení projektů. Výhodou tohoto způsobu je, že máme k dispozici zdrojový kód, který můžeme libovolně měnit a upravovat. Za další plus lze považovat nezávislost na jednom dodavateli. Na vývoji se totiž většinou podílí široká komunita dalších uživatelů. Naopak velkou nevýhodou a rizikem je nedostatečná business podpora či případné dodatečné skryté implementační náklady.

Nejrozšířenější je komerční software

Nejrozšířenější kategorií nástrojů pro řízení projektů je komerční software. Na tomto poli existuje velké množství dodavatelů, proto je potřeba před definitivním výběrem konkrétního nástroje zvážit jeho jednotlivé možnosti – jak dalece je skutečně využijeme, jaké typy uživatelských licencí budeme potřebovat, možnost propojitelnosti s jinými systémy apod. Nevýhodou je, že pokud se jednou rozhodneme pro jednoho dodavatele, je poměrně finančně náročné jej následně opustit.
Tyto nástroje jsou většinou velice robustní. Obsahují moduly pro různé uživatele, nástroje pro řízení rizik, varianty vykazování odpracované doby, projektový reporting, archivace dokumentů, sady standardizovaných konektorů do ERP, CRM systémů apod. Lze v nich namodelovat jakýkoliv podproces, který nám přijde závažný. Implementace takového nástroje se provádí postupně po jednotlivých modulech a může být rozprostřena do mnoha měsíců. Výhodou je však jistota a stabilita a zajištění podpory všech upravovaných modulů a můstků v novějších verzích nástroje. Servisní poplatky jsou ve srovnání s implementačními náklady výrazně menší.

Nástroj jako služba

Obě dvě výše uvedené skupiny v poslední době přechází na moderní formu poskytování prostřednictvím internetu nabízenou jako služba SaaS (software as a service). Velkou výhodou jsou nízké pořizovací náklady a vysoká dostupnost všude tam, kde je internet. Poskytovatelé této služby také samozřejmě garantují pravidelné zálohování dat. Na druhou stranu se musí klient smířit s tím, že případné propojení s třetími systémy je mnohem náročnější. Tento druh služby zvyšuje závislost firmy na internetu, ale bez jeho dostupnosti si dnes nelze firemní prostředí ani představit.
Zůstává také závislost na rychlosti internetového připojení, kdy se na pomalejším mobilním internetu bude klient webového rozhraní pro řízení projektů ovládat mnohem hůře než na vysokorychlostním připojení. Tyto systémy jsou proto většinou vhodné pro střední a menší společnosti, které své procesy pro realizaci projektů podřídí standardnímu nastavení aplikace.

Návratnost může být rychlá

Celkové přímé a nepřímé náklady se u komerčního software a SaaS většinou s výhledem do čtyř let vyrovnávají. Návratnost investice do softwaru ovšem může být ještě rychlejší, protože společnost může profitovat z úspěšného nasazení nástroje již po několika měsících už jen nárůstem produktivity projektových manažerů, kterým odpadnou rutinní operativní záležitosti, a interních pracovníků, kteří budou včas a přesně informováni o úkolech a termínech splnění a jejich volná výrobní kapacita bude využívána pro jiné projekty či aktivity.
Je však vždy nutné pamatovat na to, že samotný nástroj je jen prostředek k vyšší efektivitě řízení projektů. Jeho vlastní efektivita je ovšem podložena kázní všech uživatelů, kdy například harmonogramy jsou pravidelně aktualizovány, pracovník pracuje pouze na přiděleném úkolu, management pružně určuje priority projektů a podobně.

Analýza navrhne další postup

Je vždy nutné začít vypracováním úvodní studie nasazení nástroje pro podporu projektového řízení. Cílem této studie je zjištění výchozího stavu projektového řízení v organizaci, což může kromě samotných potřeb organizace zahrnovat jak záležitosti procesní (existenci procesů projektového řízení, existenci projektové kanceláře apod.), tak i organizační (počty realizovaných projektů, jejich průměrná realizační délka apod.) a samozřejmě i technické (stav infrastruktury, požadovaná dostupnost, možnost integrace do současných interních systémů).
Po této analytické fázi by mělo dojít k návrhu dalšího postupu, který bude odvislý od závěrů analýzy. Je možné jít cestou implementace procesů projektového řízení, doplněním vzdělání projektových manažerů, implementací nástroje pro projektové řízení nebo zavedením institutu projektové kanceláře. Je třeba od začátku myslet na to, že implementace nového nástroje / procesní změny si vyžádá svůj čas v podobě nutného zaškolení uživatelů, ladění systému a odstranění nedodělků. Platí, že čím sofistikovanější nástroj, tím delší musí být doba pro jeho implementaci.

Fáze vývoje projektového řízení v organizaci
Fáze vývoje projektového řízení v organizaci

 

Každý vidí rizika jinak

Při nasazení nástrojů pro projektové řízení se lze setkat s řadou úskalí a rizik, na které však může každý účastník projektu pohlížet jinak. Například projektový manažer bude z pohledu budoucího uživatele spatřovat rizika ve schopnosti nového systému v předstihu avizovat konflikty zdrojů s jinými paralelně probíhajícími projekty, sledovat jejich vytížení, schopnost identifikovat, evidovat a vyhodnocovat rizika u projektů, které řídí atd. Naopak pro resource manažera bude podstatné, aby měl možnost zavčas předejít nedostatkům zdrojů, měl k dispozici údaje o plánovaných dovolených z ostatních informačních systémů či aby byl schopen vykrýt momentální krátkodobý výpadek zdroje.
Pro pracovníky projektové kanceláře (PMO) zas bude stěžejní dívat se na všechny projekty jako na celek, identifikovat jejich „úzká hrdla“, mít schopnost prioritizace projektů nebo modelování situací „co když“. Pro pracovníka výroby pak bude důležité, aby věděl, co a jakou činnost má kdy dělat, kam si tuto činnost bude moci vykázat a mít přehled o naplnění fondu pracovní doby.

Jak si s riziky poradit

Na všechny zmíněné požadavky a očekávání je proto potřeba pamatovat již v analytické fázi celého projektu, kdy krystalizuje jeho skutečný rozsah, kdy jsou požadavky prioritizovány, svázány s možnými riziky, kdy jsou řešeny jejich možné dopady a adekvátně k nim navržena patřičná opatření.
Prvotním rizikem, se kterým se projektový manažer bude muset vypořádat, jsou rizika vyplývající ze samotného vztahu dodavatel–odběratel. Tady bude zapotřebí vyvážit například vyžadovanou součinnost ze strany odběratele vůči penalizaci za pozdní dodání díla, deklarovanou a skutečnou (požadovanou) funkčnost komponentů celého systému, upravených modulů, můstků k jiným systémům apod.
V další, analytické fázi bude nutné eliminovat příliš náročné požadavky uživatelů vůči skutečně nezbytným – všichni známe situaci, kdy si uživatelé navymýšlí obrovské množství funkcí „nezbytných“ pro jejich běžnou činnost a v reálu zjistíme, že ve skutečnosti používají dvě, možná tři. Doporučuji jít v tomto případě cestou dílčích úprav, tedy upravit systém řízení projektů v nezbytně nutné míře a až teprve z reálného provozu evidovat požadavky na změny, které se dají u dodavatele pak objednat jako „balík“ najednou, za sníženou cenu.

Důležité je testování

Samotnou kapitolou je nutnost si dopředu vyjasnit, zda chceme ve společnosti zároveň měnit i procesní model. Pokud ano, je potřeba jej upravit a ověřit před samotnou analytickou fází. Při samotné implementaci je potřeba dohlédnout na práci „testerů“ nového systému. Obzvláště důležité bude otestování všech mezimodulárních vazeb do zainteresovaných systémů. Na kvalitním otestování všech funkcí bude záležet budoucí spokojenost/nespokojenost všech uživatelů. Navíc si zde ověříme, zda jsme dostali za své peníze vše, co jsme požadovali. Další možné riziko plyne z nedostatečného nebo nekvalitně provedeného školení bez možnosti ověření znalostí uživatelů v testovacím prostředí či z odbyté uživatelské dokumentace.
Poměrně přehlíženým rizikem na projektech je podpora vrcholového vedení – pokud ji nemáme, obtížně se nám bude vyvracet argumentace běžných pracovníků poukazující právě na tento nedostatek. Zkrátka je zlatým pravidlem začít s identifikací rizik včas, pokračovat v ní často, pravidelně a na všech úrovních.

Autor pracuje jako ředitel sekce řízení projektů ve společnosti Anect.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Modernizace IS je příležitost přehodnotit způsob práce

IT Systems 4/2025V aktuálním vydání IT Systems bych chtěl upozornit především na přílohu věnovanou kybernetické bezpečnosti. Jde o problematiku, které se věnujeme prakticky v každém vydání. Neustále se totiž vyvíjí a rozšiřuje. Tematická příloha Cyber Security je příležitostí podívat se podrobněji, jakým kybernetickým hrozbám dnes musíme čelit a jak se před nimi můžeme chránit. Kromě kybernetické bezpečnosti jsme se zaměřili také na digitalizaci průmyslu.