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

8 největších rizik při implementaci firemního informačního systému
Implementaci 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.
Při stavbě se 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. I laik zřejmě tuší, kde si dát největší pozor, aby se stavba nezhroutila. My vás nyní provedeme stavbou zvanou implementace a upozorníme na možná úskalí.

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

O sestavení implementačního teamu jsme psali už v článku Jak vybrat ERP systém? Je třeba mít jasně stanovené rozhodovací pravomoci v teamu a 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ě.

ikona-palec.JPGNáš tip: Nenaslouchat kverulantům! 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.

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 technický analfabet 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.


_Y2A1157_mala.jpg

ikona-palec.JPGNáš tip: 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í.

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).

ikona-palec.JPGNáš tip: Nechte dodavatele ERP systému vést projekt, nechte si posílat kopie všech dokumentů a veďte si stínovou agendu. Něco vás to bude stát, ale vyplatí se to.

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.

_Y2A1005_mala-(1).jpg
 

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.

VISION-061_mala.jpg

ikona-palec.JPGNáš tip: 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í.

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.

ikona-palec.JPGNáš tip: 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.
 

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í.
 
VISION-179_mala.jpg

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. Další tipy na to, jak zvyšovat efektivitu při využívání ERP systému, přineseme v příštím článku.