rollout
6. 6. 2019
heliosadministrator
625 0

Jak správně rozvrhnout implementaci ERP systému

Implementace podnikového informačního systému bývá poměrně náročnou operací, která jednou provždy změní další fungování vaší firmy. K tomu, aby to byla jednoznačná změna k lepšímu, je potřeba věnovat dostatek pozornosti naplánování celé operace. Jak si celou implementaci co nejlépe rozvrhnout?

Na předimplementační analýzu musí být dostatek času

Implementace nového podnikového informačního systému je vlastně totéž jako implementace strategické změny ve firmě. Pokud firma naplno využije potenciál, který jí tento časově, finančně a mnohdy také emočně náročný krok přináší, bude z něj těžit dalších pět až deset, výjimečně dokonce i patnáct let (podle odvětví), což je typická délka životního cyklu ERP systému.

Některé zejména menší firmy, které s ERP systémy nemají třeba zatím vůbec žádnou zkušenost, však vnímají podnikový informační systém jen jako „software“, a nikoliv jako klíčový pracovní nástroj pro chod a řízení celého podniku. To je bohužel někdy vede k podcenění zcela kritické části celé implementace, a to předimplementační analýzy. U větších firem není výjimka, že jen tato fáze trvá třeba půl roku či až deset měsíců. Mít na ni vyhrazené dva týdny nebo měsíc tak může být velmi ošemetné. Nikde jinde totiž neplatí ono známé „spěchej pomalu“ tolik jako právě u předimplementační analýzy. Případná „chyba“, nebo spíše opomenutí či nepřesnost, které se v této fázi dopustíte, se totiž postupně začne v dalších fázích násobit a bude ovlivňovat chod celé firmy někdy i po dobu dalších několika let.

Všechny funkce nepůjde uvést hned při spuštění

Kvalitně provedená předimplementační analýza skýtá obrovský potenciál pro inovace, a to nejen v oblasti pokrytí jednotlivých procesů z pohledu IT, ale mnohdy i v oblasti zásadních změn v logistice, obchodu, zákaznické podpoře, výrobě, odměňování zaměstnanců či samotných základů fungování celé firmy. To s sebou nese ale i jeden, někdy ne vždy zcela pozitivně vnímaný aspekt – fakt, že ne všechno půjde spustit v den, který si firma původně stanovila jako termín spuštění nového systému.

Finální release by měl mít všechny zásadní funkce

Prvním kompromisem, který je proto potřeba uzavřít, je dostat do finálního releasu, jímž odstartuje fungování nového systému ve firmě, všechny nezbytně nutné funkce. Všechny ostatní nadstavby, typicky funkce, jež doposud nebyly k dispozici a zaměstnancům třeba i chyběly, se obvykle dostanou až do toho dalšího. Je to ale relativně častý jev, který rozhodně neznamená žádnou tragédii ani nezmar implementace. Jen reflektuje její náročnost, která obvykle díky nejrůznějším komplikacím předčí původní očekávání.

Ostrý start je někdy vhodné odložit

Alternativním řešením je odložit ostrý start, k čemuž rovněž někdy dochází. Mohou si to však dovolit obvykle jen ty firmy, které začaly hledat nový ERP systém „včas“, tedy v době, kdy ještě není situace se stávajícím ERP systémem (či alternativami v podobě excelovských tabulek) tak katastrofální, aby firmu nějak omezovala, brzdila, či dokonce táhla dolů.

Někdy lze jít i cestou paralelního provozu starého a nového systému

U firem, u kterých se situace dostala až do této bolestivé fáze, je alternativou pustit k původně zamýšlenému datu spuštění jen ty agendy, které jsou stávajícím systémem pokryty opravdu špatně (nebo vůbec), a dočasně přistoupit k paralelnímu provozu nového i starého systému zároveň. Moderní pokročilé podnikové informační systémy jako všechny naše systémy HELIOS jsou totiž dostatečně otevřené a nabízejí široké možnosti integrace a výměny dat s v podstatě libovolným informačním systémem využívajícím SQL databázi. Taková integrace sice zabere nějaký čas a bude stát nějaké prostředky navíc, ale firma tím ve srovnání s předčasným spuštěním nedoladěného a nedostatečně otestovaného systému téměř vždy výrazně ušetří.

Finální release musí být definován do pevného data

Když už je řeč o termínu spuštění, s ním je určitě možné pohnout, pokud v průběhu implementace přijdete na to, že to je opravdu potřebné, ale jeho datum by mělo být velmi pevně stanoveno. Datum spuštění totiž představuje důležité vodítko při rozhodování, co všechno bude ve finálním releasu nového systému k dispozici a co připadne až na ty další. Zejména u firem, které mají finanční prostředky na to, aby si v novém systému odladily vše podle vlastních představ. Aby to vyhovovalo co nejvíce zaměstnancům a klíčovým uživatelům, je totiž dobré mít aspoň pevnou hranici, kdy nový systém prostě musí být uveden v život. To pak zafunguje jako nejlepší síto v tom, co při svém spuštění bude či nebude umět.

Ostrý start by měl proběhnout v nejklidnějším období v roce

Tím se dostáváme k samotnému datu ostrého startu. Často jím bývá první den hospodářského roku, což je dáno snahou zjednodušit práci finančnímu oddělení. Ne vždy to ale bývá nejlepší datum ke spuštění systému. Navíc předpoklad, že se tím finančnímu oddělení zjednoduší práce, je obvykle zcela lichý. Většina účetních operací probíhá na konci každého měsíce (u menších firem s obratem do 10 mil. ročně na konci kvartálu), takže konec hospodářského roku se liší „jen“ nutností vyhotovit rozvahu a výkaz zisku a ztráty. U každé implementace podnikového informačního systému však stejně probíhá import starých dat. Jediným obdobím, kdy je pro finanční oddělení možná opravdu trochu nevýhodné přecházet na nový systém, je měsíc před koncem hospodářského roku.

Mnohem důležitějším indikátorem pro vhodnost ostrého startu nového systému je však to, v kterém období máte ve firmě provozní špičku. Drtivá většina oborů mívá některé kvartály z pohledu tržeb či vytížení výroby silnější a některé slabší. Ideálním datem pro ostrý start systému je pár týdnů po skončení provozní špičky a aspoň měsíc před začátkem té další.

Počítejte s prostorem na doladění za chodu

Důvodem, proč je vhodné mít delší rezervu před další provozní špičkou, je fakt, že je zcela běžné, že po ostrém startu systému se ukáže, že i přes veškeré testování některé věci prostě nejsou ideální. Typicky se jedná o rozvržení uživatelského rozhraní, ovládacích prvků jednotlivých formulářů apod. Zároveň je nezbytné věnovat na začátku dostatek úsilí a času důkladnému proškolení všech uživatelů. V něm mohou hrát roli i dovolené zaměstnanců, proto se vyplatí mít aspoň měsíc „klidu“ na rozjezd nového systému.

V dalším releasu mějte prostor pro opravy toho úvodního

Až když si nový systém ve firmě zcela „sedne“, je čas na další release. Ten obvykle přichází půl roku po ostrém startu. Původní představa bývá, že bude obsahovat ideálně všechny požadované funkce, jež se nevešly do finálního releasu. Praxe však ukazuje, že je nanejvýš vhodné i tyto funkce nějak prioritizovat a nechat si dostatek volných kapacit na úpravy funkcionalit, které se po ostrém startu ukázaly jako ne zcela optimální nebo u nichž se přišlo na další potřebné úpravy.

Obecným principem, který lze nanejvýš doporučit, je také postupné uvádění nového systému v život. Pěkně krok za krokem. Příliš mnoho změn najednou obvykle škodí. Je to proto, že podnikový informační systém mění i fungování firmy jako takové, a hlavně každodenní pracovní náplň zaměstnanců, kteří se systémem pracují.

TIP: Chcete vědět, které body jsou při implementaci podnikového informačního systému kritické? Přečtěte si tento náš článek.

Napsat komentář





Loading SWGDPR…

© 2019 Asseco Solutions
Developed by SHERWOOD