Jednou ze základních podmínek úspěšného dokončení projektu je překonání jeho kritických míst. Naší specializací jsou ERP projekty, u kterých, vzhledem k jejich komplexnosti, o kritická místa rozhodně není nouze.
Při predikci a prevenci kritických míst ERP projektu je důležité si uvědomit, že projekt nezačíná až podpisem smlouvy. Analýza a ošetření rizik musí tedy být nejen součástí fáze realizační, ale stejně důležité je věnovat jim dostatečnou pozornost i ve fázi obchodní.

Obchodní fáze

Trh pro implementace podnikových informačních systémů je v současnosti relativně nasycen. Z této výchozí situace vyplývá prostý fakt, že firmy realizující ERP projekty si své zákazníky nemohou příliš vybírat. Jestliže se nám již podaří nějakého potenciálního zákazníka dostat do stavu, že je ochoten stát se zákazníkem skutečným, jsme obvykle tlačeni ke zdi konkurenčními nabídkami. Zakázku samozřejmě chceme, proto musíme dobře proplout úskalími obchodní fáze. Obchodník plní správně svoji roli, jestliže se nám snaží opatřit zakázku téměř za každou cenu. Musí však mít svého protihráče ve vedoucím projektu.

Vedoucí projektu stanovuje realistický plán projektu již v obchodní fázi. Řešitelský tým mu k tomuto účelu připraví pro plánovaný projekt studii proveditelnosti. Tato studie nemůže být velká – vzniká totiž ještě v období předprodejních aktivit, kdy projekt má pouze náklady a budoucí výnosy jsou zcela nejisté. Zároveň však studie proveditelnosti musí dát vedoucímu projektu podklady, aby mohl pro vedení společnosti formulovat „binární kritérium projektu“ – „go / no go“ rozhodnutí o realizaci projektu. Takovým kritériem může být třeba jasně vymezený minimální rozsah projektu: „Za méně než pět set člověkodnů se to nedá udělat. A když říkám pět set, tak myslím nejméně pět set, nikoli dvě stě, které mi z toho uděláte podpisem smlouvy.“ Pro vedení firmy je rozhodnutí o odmítnutí jakékoli zakázky nesmírně náročné a bolestné. Nicméně projektům, kde je vysoká míra rizika, která není vyvážena dostatečnou finanční rezervou, je lepší se vyhnout.

Zákazník o nás stojí, návrh projektu prošel binárním kritériem – dostáváme se k přípravě smlouvy. V našich krajích se bohužel již stává smutným zvykem, že právní aspekty smlouvy se považují za důležitější než aspekty věcné. Na desítkách až stovkách stran se snažíme ošetřit všemožné situace, které by mohly nastat, kdyby náhodou některá ze smluvních stran chtěla jednat nekorektně, či snad dokonce podvodně. Přitom je jasné, že zrovna v tomto případě nám smlouva asi příliš nepomůže. Naopak ji musíme použít jako páku projektového řízení možných rizik. Ve smlouvě je třeba určit co nejpřesněji nejen obsah, ale i rozsah plnění – co je předmětem dodávky a jaký je rozsah prací v rámci dodávky. Vedle cen a termínů by smlouva měla také deklarovat předpokládané metodiky řízení projektu, hlavně pro změnová řízení a pro akceptační postupy. Žádný dodavatel nenaimplementuje ERP bez součinnosti s uživateli ze strany zákazníka. Proto je důležité, aby se na vymezení součinnosti nezapomnělo již při přípravě smlouvy. Jestliže by si zákazník myslel, že mu dodavatelská firma udělá implementaci ERP „na klíč“ a bez jeho účasti, byl by takový projekt odsouzen ke krachu.

Příprava smlouvy je náročný proces. Smlouva je totiž základním dokumentem pro ošetření možných kritických míst v realizační fázi projektu. Zároveň pro smlouvu platí dvojnásob, že chybami se člověk učí. Proto je vhodné aplikovat princip učící se organizace – používejme standardizovanou smlouvu, do které se promítají úpravy vyplývající ze zkušeností z realizovaných projektů.

Realizační fáze

Analýza

Realizační fáze začíná analýzou. Z hlediska negativní obdoby klíčových faktorů úspěchu – tzv. kritických faktorů selhání – je v této fázi stěžejní udržet smluvní rozsah. Tento rozsah vznikl v obchodní fázi: zákazník formuloval poptávku, dodavatel zpracoval nabídku, na základě přijaté nabídky vznikla smlouva. Za nabídkou ale nutně stojí dva zásadní dokumenty vytvořené rovněž již v obchodní fázi, a to realistický plán projektu a studie proveditelnosti. Vedoucí projektu se o ně opře a v boji proti vlastní řešitelské četě bude operativně rozhodovat, které procesy se budou řešit (omezení procesů), jaké požadavky se budou řešit (omezení informačních potřeb) a jak se budou požadavky řešit (omezení způsobu řešení). Klíčové je tato omezení stvrdit písemně.

Implementace

Předpokládáme, že řešitelský tým bude implementovanému informačnímu systému opravdu rozumět. Proto můžeme pominout všechny kritické faktory neúspěchu, které by snad souvisely s případnou odbornou nekompetencí řešitelského týmu. Ze zbývajících faktorů jsou nejhoršími kritickými místy změnové řízení, testování a akceptace.

Standardní systémy ERP dnes již disponují velkou funkčností. Nicméně tato funkčnost se vždy v rámci implementace přizpůsobuje potřebám a požadavkům konkrétního zákazníka. Běžte třeba na kraj světa, implementaci ERP, která by byla tvořena pouze a přesně standardní funkčností, prostě nenajdete. Proto je tak důležité zvládnout při implementaci ERP změnové řízení. Nutnou podmínkou dobrého změnového řízení je pravidlo, že za zákazníka zadává změny pouze garant za danou oblast řešení, čili osoba zodpovědná za řešení za stranu zákazníka. Nestane se potom to, že realizace informačního systému se podobá pohádce „jak si pejsek s kočičkou vařili dort“.

Pokud je ve smlouvě proces změnového řízení dobře podchycen a zákazník s ním byl srozuměn a souhlasí, při samotném změnovém řízení už jde jen a pouze o to, které požadavky uhájíme jako vícepráce, a které budeme realizovat v rámci projektu, tedy zdarma. Kromě naší schopnosti přesvědčovací se opíráme právě o schválený dokument analýzy.

Testování je při implementaci nutné zlo – netestovat nelze, přestože to je pro obě strany pracná a časově náročná činnost. Kritickými faktory úspěchu při testování je důslednost – důslednost na straně dodavatele i důslednost na straně zákazníka. Ať chce či nechce, musí vedoucí projektu působit na obou stranách jako dráb. Navíc je klíčové vyvážit úsilí obou stran, pokud na jedné straně dodavatel testuje málo, zákazník nachází mnoho chyb a ztrácí důvěru v dosažení cíle. Pokud zákazník naopak příliš věří dodavateli a testování podceňuje, po nasazení přichází nezřídka rozčarování nad dodanou aplikací, „která přece měla dělat něco jiného“.

Nový informační systém musí být po částech přijat uživateli zákazníka – formálně i fakticky. Pro fakturaci dodavatelem je důležitá formální akceptace, pro smysl projektu akceptace faktická. V případě úspěšného projektu proběhnou akceptace obě a jsou v souladu. K tomu je třeba připravit akceptační testy a v nich nadefinovat postupy a kritéria, pomocí nichž se objektivně pozná, že implementovaný systém funguje správně a v souladu se zadáním. Pravidla akceptačních testů musí vzniknout už v obchodní fázi – každý přece ví, že měnit pravidla v průběhu hry se nevyplácí.

Nasazení

Implementovaný informační systém je převeden do rutinního používání. Je tedy – v optimálním případě – přijat zákazníkem jako celek. S přijetím aplikace zákazníkem jsou spjaty mnohé kritické faktory.

První velká skupina úskalí vyplývá z očekávání uživatelů. Uživatelé od implementace něco očekávali a něco dostali. Pravdivě musíme konstatovat, že tyto dvě stránky se v realitě nikdy stoprocentně nekryjí. Jestliže budeme předpokládat, že implementace je úspěšná, řešení se jeví jako správné, dobré a plně funkční, potom nám zbývá dobře průběžně ošetřovat očekávání uživatelů. U implementace ERP se v tomto kroku může zúročit, že zákaznický řešitelský tým byl na začátku projektu dobře proškolen. Také si ERP systém dobře vyzkoušel a byl v průběhu analýzy a implementace zatažen do řešení problémů. Tím se stane zázrak a uživatelé na straně zákazníka v průběhu projektu přijmou dílo za své. Zákaznický řešitelský tým tak v době nasazení už „kope za naši stranu“ a přesvědčuje nové uživatele, pro které je jakýkoli krok do neznáma utrpením, o krásách nového ERP systému. Přijetí nového informačního systému je samozřejmě vhodné podpořit prostřednictvím PR aktivit nasměrovaných do zákaznické firmy, ale nejlepší PR je dostatečná, otevřená a přátelská komunikace na projektu.

Implementace prakticky vždy způsobí změny firemních procesů. Je to přirozený důsledek, nicméně pokud není v projektu patřičně ošetřen, stává se časovanou bombou neúspěchu. S tímto faktorem musíme pracovat „jak nahoře, tak dole“. Klíčovým faktorem při změně firemních procesů je určitě plná podpora managementu zákazníka. Zároveň nesmíme zapomínat na ty, kterým jsme jejich pracovní postupy propletli s novým informačním systémem. S uživateli se musí mluvit, uživatelé musejí být vyškoleni, uživatelé musejí mít k dispozici vhodnou dokumentaci nových postupů – a hlavně, uživatelé musejí vědět, na koho se mohou kdykoli a s čímkoli podle svých potřeb obrátit.

Závěr

Uvedený krátký přehled kritických míst projektů ERP v žádném případě neaspiruje na úplnost. Chtěli jsme pouze přitáhnout vaši pozornost ke skutečnosti, že kritické faktory selhání a klíčové faktory úspěchu k sobě mají velmi blízko. Tak blízko, že se mohou plíživě vyměnit. Proti tomu existuje jediná, avšak velmi účinná obrana: rozumět jim a věnovat jim pozornost.

Jaroslav Šuvarský
Autor je manažerem divize podnikové informační systémy ve společnosti Aquasoft.

< Předchozí		Další >