Implementace nového podnikového informačního systému s sebou nese celou řadu úskalí. Na základě našich zkušeností z praxe českých podniků jsme dali dohromady deset nejkritičtějších. Dnes si povíme o dalších pěti věcech, na které si dát pozor.

I. díl článku najdete zde.

 

Definice pokrytých procesů

Implementace podnikového IS je velká příležitost ke změně procesů ve firmě. Pokrývat stávající procesy přesně tak, jak jsou, by tedy byla nevyužitá příležitost. Navíc každá jedna úprava standardního průběhu procesů, jak jsou definovány v rámci podnikového IS, přináší řadu vícenákladů i do budoucna. Přitom systémy HELIOS díky tomu, že jsou vyvíjeny lokálně pro ČR a SR, už obsahují best practices obvyklé právě v obou těchto zemích. Nejsou to tedy best practices nastavované pro „malou tisícihlavou“ americkou nebo německou firmu, které by u nás třeba neobstály.

 

Výběr funkcionalit pro první release

Obvyklá představa při zvažování nového podnikového informačního systému je, že nový systém odstraní úplně všechny nedostatky toho předchozího a pokryje konečně úplně všechno, co ten stávající nedokázal. Řadě firem se tuto představu nakonec podaří naplnit, jen to obvykle není možné ani účelné udělat najednou. Změny totiž nestačí provést jen uvnitř podnikového IS, ale zejména uvnitř firmy a v každodenním fungování jejích zaměstnanců. Proto se většina implementací nakonec rozkládá do delšího časového období na tzv. releasy neboli „vydání“. První release by měl obsahovat všechny pro firmu nezbytné agendy, ty další by pak měly obsahovat ty důležité až méně podstatné. Firma by také měla počítat s tím, že po ostrém startu bude potřeba zapracovávat i některé následné změny. Obvykle totiž až ostrý provoz dokáže odhalit veškeré praktické dopady inovovaných procesů a agend, které třeba mohou vyvolat potřebu doplnění některých formulářových polí či tlačítek do systému, nebo možnost další přínosné inovace již inovovaných procesů. Druhý release se tak obvykle skládá z řady úprav toho, co přinesl ostrý start systému.

 

Testování předprodukční verze systému

Množství změn po ostrém startu systému lze do značné míry předejít dostatečně dlouhým testovacím provozem. Toho se účastní jak klíčoví uživatelé, tak ideálně ještě i další zaměstnanci. Žádný testovací provoz však nedokáže poukázat na všechny aspekty následného ostrého provozu, třeba už proto, že neobsahuje přímou interakci se všemi zaměstnanci, zákazníky či obchodními partnery a že málokdy je schopen pokrýt všechny nestandardní situace. Na testování si však určitě nechte dostatek času a prostoru, i za cenu posunu data spuštění systému. Přechod na nedostatečně otestovaný podnikový informační systém totiž může přinést celou řadu zásadních problémů.

 

Komunikace se zaměstnanci před zavedením nového systému

Obvyklým klíčovým problémem po ostrém startu systému nebývají ani tak nedostatky v podnikovém informačním systému, jako spíše nedostatečná příprava zaměstnanců na změny, které systém přináší. Klíčová je přitom i motivace zaměstnanců, aby nový systém používali. Běžné jsou totiž situace, kdy agendy, jež se dříve řešily jen poznámkou na papíře, je teď nutné zaznamenat do systému. Přínosy, které z toho plynou, však zaznamenáte pouze tehdy, pokud tak příslušní zaměstnanci opravdu začnou činit. V opačném případě to naopak způsobí spoustu problémů, protože zatímco jedni to budou psát na papírek „jako vždycky“, jiní budou danou informaci očekávat už jen v systému – „jak jsme se přece dohodli, že to budeme dělat“. A právě o té dohodě se všemi zaměstnanci to je.

 

Volba data ostrého startu nového systému

Posledním kritickým bodem je volba data ostrého startu nového systému. Velká část firem spouští nový systém spolu s novým hospodářským rokem. To dává vcelku logický smysl, zejména pro finanční oddělení, které by jinak muselo složitě přecházet uprostřed roku na nový systém s novými účetními knihami, způsoby provádění účetních závěrek apod. V praxi však není volba takového data nezbytná. Migrace dat je naprosto běžnou součástí každé implementace podnikového IS a to se samozřejmě týká i dat účetních.

Obecně je vhodné se věnovat spíše tomu, kdy firma zažívá největší nápor práce, a vyhnout se právě těmto obdobím. Každý ostrý start je spojen s určitými potížemi. Jeden den lidé pracují se systémem X a svou práci provádějí způsobem Z, zatímco druhý den musí začít pracovat už jen se systémem Y, což ovšem zároveň často znamená, že svou práci musí začít provádět zcela novým způsobem Z2. I kdyby v novém systému bylo vše dokonale v pořádku a funkční a všechna data v něm byla správně zmigrována z toho předchozího, stále je tu výrazný rizikový faktor spočívající v tom, že vaši zaměstnanci musejí začít pracovat jinak. Tedy pokud firma využila implementaci podnikového IS jako potenciál pro zavedení inovací a změn. Proto vždy pečlivě volte datum ostrého startu podle toho, zda je systém řádně otestován, zda jsou na něj zaměstnanci připravení a zda existuje dostatečný prostor pro „učení se“ novým způsobům práce.

zdroj: www.helios.eu