facebook LinkedIN LinkedIN - follow
ERP systémy 2 , ERP systémy

8 největších rizik při implementaci firemního informačního systému

Petr Klapka


VisionImplementaci firemního software si můžete představit jako stavbu domu. Nejdřív uvažujete, jak má dům vypadat, jaké nároky splňovat. Řešíte, co je pro vás důležité a do čeho jste ochotní investovat a jaké zařízení budete muset oželet nebo si ho pořídíte později. Během stavby se pak objevují nové skutečnosti, musíte se rychle rozhodovat, vybírat z různých variant, zvažovat možné navýšení nákladů. Při tom všem máte stále na paměti, že jde o investici na desítky let a že co se nyní zanedbá, to se vám může později vymstít. Proto je dobré si neustále připomínat možná úskalí a při stavbě zvané implementace se jim pečlivě vyhnout. Existuje řada pouček, jak při IT projektech postupovat a kterým rizikům se vyhnout. Já jsem vybral ty, které se nám v praxi objevují opakovaně a kterých se můžete s trochou snahy vyvarovat.


1. Malá pozornost managementu v průběhu projektu

Implementační team musí být správně sestaven nejen na straně dodavatele, ale i zákazníka. Je třeba v něm mít jasně stanovené rozhodovací pravomoci. Konečné rozhodnutí musí být vždy na tom členu teamu, který nese za celý projekt zodpovědnost. Vedení společnosti by mělo být v obraze a zachovat vedoucímu teamu důvěru po celou dobu a podpořit ho v případě sporných situací, ovšem pokud je to skutečně člověk na svém místě. Musí se také počítat s tím, že vedení projektu zabere tomuto člověku dost času a je třeba mu uvolnit ruce od každodenních povinností.

Přihodilo se nám, že byl vedoucí projektu na straně zákazníka v průběhu implementace vyměněn. Nový šéf měl jiné představy o projektu a snažil se ho v průběhu výrazně změnit, čímž se neúměrně navyšovaly vícepráce a konečný termín projektu. V takové chvíli je lepší projekt zastavit a s celým teamem včetně vedení společnosti si znovu stanovit priority a směr, kterým se bude projekt nadále ubírat.

2. Selhání komunikace

Implementace ERP systému je velmi komplikovaná v jedné oblasti, a tou je vzájemné pochopení. Budete-li stavět dům, tak i jako „nestavebník” budete nejspíš vědět, co je to kotel, a tak nějak laicky budete vnímat rozdíl mezi plynovým a elektrickým kotlem a budete se pídit po tom, jaký by měl mít výkon. U ERP systému to takhle jednoduché není. Je proto potřeba spolu mluvit, mluvit a mluvit. Věci si vyjasňovat a hledat řešení. Ne vždy budou problémy jednoduché, a ne všechno se povede na „první dobrou“. Komunikace by neměla být ani z jedné strany konfrontační – tím spolehlivě zabijete jakoukoliv snahu něco vyřešit dobře. Problémy je potřeba komunikovat nejlépe osobně a s kompetentními lidmi. Nesmíte ale zapomínat ani na formální stránku. Osobní jednání je samozřejmě nejefektivnější, ale musí o tom někde zůstat záznam. Komunikace je nezbytnou aktivitou v rámci přípravy i samotné realizace a připravte se na to, že je to i nutný, ale užitečný náklad realizace.

3. Opuštění formální roviny

Jakmile opustíte formální rovinu vedení projektu, ztratíte kontrolu a otevíráte jedno veliké riziko, kterým je přímé ohrožení některého z prvků projektového „trojcíle“ (požadovaný výsledek - peníze - termín). Může se zdát, že ve všem panuje shoda a že není třeba dbát formalit.

Jako příklad můžu uvést jednu výrobní firmu, kde byl vedoucím implementačního projektu sám majitel, který na formality právě nedbal, a nenechal se námi jako dodavatelskou firmou přesvědčit k obvyklému postupu. V jednu chvíli přestal mít čas se projektu věnovat a pověřil jím jiného pracovníka, kterému předal složku plnou nepodepsaných dokumentů. Bylo třeba udělat „inventuru“ celého projektu a projít znovu všechny formality, aby byl nový člověk schopen zodpovědně převzít projekt. Stálo to množství práce navíc a také došlo k mírnému zdržení, kterého bylo možné se vyvarovat, kdyby se postupovalo podle pravidel.

4. Vynechání úvodní studie

Zákazník má někdy pocit, že „všechno je jasné“ a že není třeba investovat do úvodní studie. I když implementujete systém ve firmě s jednoduchými procesy, tak to vždy děláte z nějakého důvodu. Tento důvod je vlastně cílem implementace. Naplnění tohoto cíle znamená splnit řadu drobnějších požadavků (někdy i poměrně samozřejmých). Zmapování těchto cílů a požadavků je první krok každé studie. Studie shrnuje, na čem se zákazník s dodavatelem dohodli. Jsou zde veškeré požadavky a způsob řešení, popisuje jednotlivé fáze implementace, požadavky na součinnost klienta i možná rizika. Analýzu nestačí pouze přečíst, je potřeba ji pochopit a ztotožnit se s jejím obsahem, případně požádat o vysvětlení či doplnění. Zabrání se tak možným nedorozuměním.

5. Nedodržení fází implementace

Kromě vynechání úvodní studie se často objevuje požadavek na zrychlení procesu implementace vynecháním testovacích fází a na to navazujících vypořádacích etap. Například Vision ERP se často přizpůsobuje zákazníkovi na míru, jde tedy o prototyp, který je potřeba „doladit“ na cvičných datech v bezpečném prostředí. Všechny situace nelze nasimulovat při vývoji a uživatelské testování je nenahraditelné a je nezbytnou součinností zákazníka. I zde je potřeba dodržet formální stránku vedení projektů a zaznamenat výsledky testů a případně dohodnutá opatření při zjištění jakýchkoliv problémů. Vynechat nelze ani školení uživatelů, které je nutné provést až těsně před spuštěním ostrého provozu, aby získané poznatky mohli hned začít využívat.

6. Nepřipravenost datového prostředí

Do nového systému je třeba přenést množství stávajících dat (firmy, saldokonto, stavy různých agend a podobně). Data nejde jen „přesypat“, jak si leckdo myslí. Používají se různým způsobem a mají různé vazby. Je třeba se předem dohodnout s předchozím dodavatelem systému, jak která data bezpečně převést. Zaměstnanci musejí mít data v pořádku. Není žádoucí, aby se chyby přenesly do nového systému. V neposlední řadě je třeba dohlédnout na to, aby dodavatel nového systému dodal data včas. To, že se jeden zaměstnanec zrovna „musí věnovat něčemu jinému“, může zdržet celou implementaci. Převody dat jsou velikým rizikem každé implementace a je třeba jim věnovat hodně pozornosti.

7. Přílišná volnost uživatelů – nezvládnutí změnových požadavků

Je třeba hned zpočátku nastavit a důsledně dodržovat, kdo a za jakých podmínek může požadovat změny v navrženém řešení. Změny je zároveň třeba formalizovat. Často se děje to, že koncoví uživatelé přímo zadávají požadavky na změny konzultantům dodavatele a změna probíhá mimo kontrolu projektových manažerů či majitelů projektů. Je to velké riziko ohrožující náklady i termíny. Přirozeně není změna jako změna a rozdíl mezi koncepční změnou a změnou parametru uživatel často nevnímá. Proto je nezbytné, aby projektový manažer všechny požadavky na změny shromažďoval, podroboval kritice a konzultoval je s dodavatelem. Rozhodnutí o změnách, které mohou jakkoliv zasáhnout do některého z „trojcílů“ by však mělo náležet výhradně do kompetence vedoucího projektu.

8. Podcenění managementu rizik

Celý tento článek je o rizicích a rizikem číslo jedna je „nezabývat se riziky“. Rizika je třeba pojmenovat a průběžně s nimi pracovat. Je to práce projektových manažerů, a i když jsou některá rizika celkem zjevná a opatření pro zmírnění cekem logická, je vhodné je doopravdy kontrolovat. Pro řízení rizik existuje několik metodik, ale úplně postačí zdravý selský rozum a důslednost v zjišťování rizik, případně v naplňování opatření k jejich zmírnění.

Aby všechno dobře fungovalo, měl by mít i po implementaci nadále zodpovědnost za chod a rozvoj systému jeden člověk, který si prohloubí znalosti o systému a alespoň částečně „do něj vidí“. Důležité je pokračovat ve školení uživatelů, již proškolení by si měli znalosti osvěžovat a noví by se měli učit od odborníků, a ne od služebně starších kolegů, od kterých by mohli převzít i jejich chyby a zlozvyky.

Na závěr několik tipů na navíc:

  • Nenaslouchat kverulantům víc než je zdrávo. Lidé obecně nemají rádi změny a nejsou většinou ochotní učit se novým věcem. Koncoví uživatelé často hledají důvody, proč nový systém nepoužívat a proč „to nebude fungovat“. Jeho výhody ocení až po čase, když se s ním naučí pořádně pracovat. Vedení společnosti si musí po celou dobu implementace za změnou stát a důsledně ji prosazovat. Kverulant, kterému management naslouchá, aniž by si zjistil fakta, dokáže projekt úplně rozložit.
  • Dobrou praxí z pohledu projektového manažera je vytipovat hned ve fázi úvodní studie pouze ty změny, které jsou nezbytně nutné pro běh systému a požadavky na „komfort“ je vhodné nechat na dobu např. 6 měsíců po ukončení implementace. Pozor však, aby se z provizoria nestal trvalý stav.
  • Ještě ve fázi úvodní studie si zjistěte možnosti exportu vašich dat do čitelných formátů (xls, csv a jiné) a ideálně předejte vzorky dodavateli ERP k prozkoumání.
  • Motivujte zaměstnance, aby vycházeli implementačnímu teamu vstříc. V příjemné atmosféře, kdy spolu konzultanti s uživateli komunikují a dobře vycházejí, se výsledek přiblíží rychleji a bývá lepší. Se stejnými konzultanty se navíc uživatelé budou potkávat i v budoucnu při údržbě systému a ochota na obou stranách vše usnadní.
Petr Klapka Petr Klapka
Autor článku je ředitelem společnosti Vision Praha.
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.