Etapy projektu ERP: ako prebieha implementácia v slovenskej firme

Dobre vedený projekt ERP sa nezačína inštaláciou a nekončí sa ostrým štartom. Začína sa otázkou, čo firma od systému skutočne potrebuje, a končí sa až vtedy, keď ľudia v ňom pracujú bez tabuľkových záplat. Tento prehľad prechádza etapy projektu ERP v poradí, v akom ich zažije slovenská malá alebo stredná firma: pri každej uvádzame, čo je jej cieľom, aké výstupy by ste mali dostať do rúk a kde sa projekty najčastejšie zadrhnú.

Ak ešte len zisťujete, čo vlastne ERP je, začnite stránkou čo je ERP systém. Ak už máte rozhodnuté a zaujíma vás mise en place ERP, teda samotné nasadenie, čítajte ďalej.

Prečo sa implementácia ERP riadi etapami

Zavedenie ERP sa dotýka účtovníctva, skladu, nákupu, predaja, výroby aj zákazníckej komunikácie naraz. Keby sa to robilo jedným veľkým skokom, každá chyba by sa prejavila vo všetkých oddeleniach súčasne. Etapy preto plnia tri úlohy:

• rozdeľujú rizikový projekt na časti, ktoré sa dajú skontrolovať a odsúhlasiť,
• nútia firmu rozhodovať v správnom čase, nie pri ostrom štarte,
• dávajú vedeniu bod, v ktorom sa môže zastaviť a opraviť smer, kým je to ešte lacné.

Pri nasadení ERP je nepríjemné najmä to, že chyba z prvých etáp sa ukáže neskoro. Nejasné zadanie sa prejaví až pri teste, nesprávne nastavený číselník až pri uzávierke. Preto sa vyplatí vrátiť sa k nasledujúcemu prehľadu aj v strede projektu.

Prehľad etáp na jednom mieste

Cielenie a zadanie projektu

Cieľ. Pred akýmkoľvek výberom softvéru treba písomne vyjadriť, prečo do projektu idete. Nie „chceme moderný systém“, ale konkrétne: sklad sa nezhoduje s účtovníctvom, mesačná uzávierka trvá príliš dlho, e-shop a pokladnica nie sú prepojené, vedenie nemá aktuálny prehľad o marži zákaziek.

Výstupy. Zadanie projektu s cieľmi a hranicami, menovaný vlastník projektu, menovaný vedúci projektu a zoznam požiadaviek rozdelený na nevyhnutné a želané. Praktický postup nájdete v časti o vzore požiadaviek na ERP.

Pasce.

• Zadanie opisuje súčasné problémy, ale nie budúci stav, takže nikto nevie povedať, kedy je projekt hotový.
• Projekt sa vedie ako „záležitosť IT oddelenia“ a vedenie sa zapojí až pri problémoch.
• Slovenské povinnosti, ako e-kasa, DPH, kontrolný výkaz či elektronická fakturácia, sa v zadaní vôbec nespomenú, lebo sa „predsa rozumejú samy“. Neskôr sa ukáže, že sú práve to, čo rozhoduje o výbere.

Zadanie je jediný dokument, ktorý vás neskôr ochráni pred rozširovaním rozsahu zo strany dodávateľa aj z vašej vlastnej strany.

Výber systému a dodávateľa

Cieľ. Vybrať dvojicu, ktorá spolu funguje: systém, ktorý zodpovedá vašej firme, a integrátora, ktorý ho vie nasadiť. Platí, že zlý integrátor dokáže pokaziť výborný systém, a naopak.

Výstupy. Porovnanie aspoň dvoch riešení podľa vašich požiadaviek, ukážky na vlastných scenároch, referencie od firiem podobnej veľkosti a odvetvia, ponuka s jasne vymedzeným rozsahom a zmluva. Na trhu sa pri stredne veľkých firmách stretnete najmä s riešeniami Odoo, Microsoft Dynamics 365 Business Central, SAP Business One či Oracle NetSuite a s lokálnym systémom POHODA pre menšie účtovné prevádzky. Ako ich porovnávať, opisuje stránka ako vybrať ERP a o partnerovi hovorí výber ERP integrátora.

Pasce.

• Rozhodnutie iba podľa ceny licencie. Väčšiu časť nákladov tvorí práca na zavedení, nie samotný softvér; podrobnosti sú v časti o cene ERP.
• Ukážka prebehne na vopred nachystaných údajoch dodávateľa, nie na vašich scenároch.
• Zmluva nepomenúva, čo je súčasťou ceny a čo sa bude účtovať zvlášť.

Ak chcete tento krok urýchliť, služba na mise en relation s integrátorom vám bezplatne sprostredkuje kontakt na integrátora, ktorý sa zameriava na váš typ projektu. Samotný projekt potom robí integrátor.

Návrh riešenia

Cieľ. Premeniť požiadavky na opis toho, ako sa bude v systéme pracovať. Tento krok sa niekedy nazýva analýza alebo koncepčný návrh. Odpovedá na otázky: kto zadáva objednávku, kto ju schvaľuje, kedy vzniká faktúra, ako sa vedie sklad, ako sa vykazuje DPH.

Výstupy. Dokument návrhu s popisom procesov, zoznam rozdielov medzi štandardom systému a vašimi potrebami, rozhodnutie, ktoré rozdiely sa vyriešia nastavením, ktoré úpravou a ktoré zmenou vášho postupu, a harmonogram s míľnikmi. V tejto etape sa rozhoduje aj o cloude alebo on-premise prevádzke, pretože od toho závisí architektúra prepojení.

Pasce.

• Firma chce, aby nový systém kópioval starý, vrátane obchádzok, ktoré vznikli zo zvyku. Návrh je príležitosť niektoré postupy zjednodušiť.
• Na workshopoch chýbajú ľudia, ktorí proces skutočne vykonávajú, a prichádzajú len vedúci, ktorí ho poznajú zo schém.
• Účtovník sa do návrhu nezapojí, hoci práve on vie, čo vyžaduje slovenský daňový úrad a ako vyzerá bežná uzávierka.

Dobrý návrh je zrozumiteľný pre človeka, ktorý nie je z IT. Ak mu pri čítaní nerozumiete, opýtajte sa, kým nebude jasný.

Nastavenie systému

Cieľ. Systém sa prispôsobí návrhu. Nastavuje sa štruktúra spoločnosti, číselné rady, sklady, ceny, daňové kódy, používatelia, práva, tlačové zostavy a automatické pravidlá. Prvé skutočné prostredie, v ktorom si môžete kliknúť, býva hotové práve v tejto etape.

Výstupy. Testovacie prostredie nastavené podľa návrhu, zoznam realizovaných úprav a prepojení (napríklad na e-shop, banku, pokladnicu alebo prepravcu), dokumentácia nastavení.

Pasce.

• Príliš veľa úprav na mieru. Každá úprava sa musí testovať, udržiavať a pri aktualizáciách systému znovu overovať. Zásada: najprv štandard, úprava iba tam, kde prináša jasnú hodnotu.
• Slovenské špecifiká sa riešia až na konci. E-kasa, kontrolný výkaz DPH a elektronická fakturácia patria do nastavenia od začiatku, nie do „fázy dva“. Pozrite si e-kasu v ERP a kontrolný výkaz DPH v ERP.
• Práva používateľov sa nastavia „na všetko pre všetkých“, aby sa nič nezablokovalo. Neskôr je ťažké to vrátiť.

Nastavenie sa deje priebežne a vy ho sledujete na krátkych ukážkach. Ak vidíte výsledok až po dlhom čase, riziko nedorozumenia je vysoké.

Prenos dát

Cieľ. Preniesť zo starých systémov a tabuliek to, čo nový systém skutočne potrebuje: zákazníkov, dodávateľov, produkty, ceny, otvorené objednávky, otvorené faktúry, zostatky na účtoch a stavy skladu. Nie všetko, čo kedy vzniklo.

Výstupy. Rozhodnutie, ktoré dáta sa prenášajú a ktoré sa archivujú, vyčistené zdrojové súbory, skúšobný prenos so zápisom rozdielov a záverečný prenos pri štarte. Zostatky na účtoch odsúhlasí váš účtovník. Podrobnejšie sa téme venuje stránka o migrácii ERP.

Pasce.

• Prenos nečistých dát. Duplicitní zákazníci, zastarané produkty a nekonzistentné číselníky sa po prenose stanú problémom nového systému.
• Prenos sa skúša iba raz, tesne pred štartom, takže nie je čas na opravy.
• Nikto nevlastní kvalitu dát. Určite zodpovednú osobu za každú oblasť, napríklad za produkty, zákazníkov a ceny.
• Historické doklady sa prenášajú do detailu, hoci stačí ich archív a čitateľný prehľad.

Čistenie dát je práca vašej firmy, nie integrátora. Integrátor vie dáta prepísať a nahrať, ale nevie rozhodnúť, ktorý z dvoch duplicitných záznamov je správny.

Akceptačné testovanie

Cieľ. Overiť, že systém zvláda reálne situácie vašej firmy, nie iba ukážkové scenáre. Nazýva sa to aj recepcia alebo UAT. Je to posledný bod, v ktorom môžete zasiahnuť bez tlaku ostrej prevádzky.

Výstupy. Zoznam testovacích scenárov spísaných s ľuďmi z oddelení, protokol s výsledkami, zoznam chýb s prioritami a písomné odsúhlasenie, že riešenie je pripravené na štart.

Pasce.

• Testujú ľudia, ktorí systém nebudú používať. Testuje skladník, účtovníčka, obchodník, nie iba vedúci projektu.
• Testy pokrývajú iba bežný deň. Overte aj výnimky: dobropis, vrátenie tovaru, čiastočná dodávka, oprava dokladu, uzávierka mesiaca, podanie DPH a kontrolného výkazu, tržba v pokladnici cez e-kasu.
• Každá nájdená chyba sa berie ako dôvod odložiť štart. Chyby treba rozdeliť na tie, ktoré štart blokujú, a tie, ktoré sa dajú opraviť po ňom.

Dobrý test je nudný: rovnaké scenáre sa opakujú dovtedy, kým prechádzajú bez zásahu. Pri nich sa zároveň ľudia učia systém.

Školenie používateľov

Cieľ. Pripraviť ľudí tak, aby v deň štartu vedeli svoju prácu urobiť v novom systéme. Školenie sa neuskutočňuje v poslednom týždni; pripravuje sa už počas testov.

Výstupy. Plán školení podľa rolí, školenia na testovacom prostredí s vlastnými dátami firmy, stručné pracovné návody pre najčastejšie činnosti, určení „interní lídri“, ku ktorým sa kolegovia obrátia ako k prvým, a plán podpory v prvých týždňoch.

Pasce.

• Jedno spoločné školenie pre všetkých. Skladník a finančný riaditeľ potrebujú rozdielne veci.
• Školenie sa robí na údajoch dodávateľa, takže si ľudia neviazajú postup s vlastnou prácou.
• Nikto nezodpovedá za návody, takže po odchode kľúčových ľudí zostane iba ústne podanie.
• Odpor voči zmene sa podceňuje. Najlepšie ho znižuje to, že sa zástupcovia oddelení zapájajú už do návrhu a testov a nie sú prekvapení až pri štarte.

Ostrý štart

Cieľ. Prepnúť firmu zo starého spôsobu práce na nový, s najmenším možným narušením objednávok, fakturácie, skladu a pokladnice.

Výstupy. Plán prechodu rozpísaný po krokoch, vyhlásenie času uzávierky starých údajov, záverečný prenos dát, kontrola zostatkov, zodpovednosti za jednotlivé činnosti v prvých dňoch a postup návratu, ak by sa objavila kritická chyba.

Pasce.

• Štart v nevhodnom období: pri uzávierke, inventúre, sezónnej špičke alebo tesne pred termínom podania DPH.
• Paralelná prevádzka starého a nového systému trvá príliš dlho. Ľudia potom pracujú dvakrát a dáta sa rozchádzajú.
• Na štart sa nepripraví zvýšená podpora. Prvé dni prinášajú množstvo drobných otázok a každá nevyriešená otázka vedie k návratu k tabuľke.
• Pokladnica a e-kasa sa overia iba v teste a nie priamo v prostredí, v ktorom budú pracovať. Tržby a doklady musia zodpovedať.
• Faktúry sa nedajú vystaviť elektronicky v požadovanej podobe. Prečítajte si elektronickú fakturáciu v ERP.

Ostrý štart je dobré rozložiť. Niektoré firmy prepínajú po moduloch alebo po prevádzkach, iné uprednostňujú jeden dátum. Rozhodnutie závisí od prepojenosti procesov a od toho, aký veľký výpadok si môžete dovoliť.

Zlepšovanie po štarte

Cieľ. Systém sa po štarte nezastavuje. Prvé týždne slúžia na opravy a stabilizáciu, potom sa zavádzajú veci, ktoré sa kvôli rozsahu odložili: ďalšie moduly, nové zostavy, automatizácie, prepojenia a prípadná expanzia na ďalšie prevádzky.

Výstupy. Záverečné hodnotenie projektu oproti pôvodnému zadaniu, zoznam odložených požiadaviek s prioritami, dohodnutý spôsob podpory, správa verzií a aktualizácií, pravidelná kontrola, či sa systém používa tak, ako bol navrhnutý.

Pasce.

• Projekt sa vyhlási za ukončený a nikto sa už nestará o to, aby sa zvyšovala jeho využiteľnosť.
• Do systému sa pridávajú výnimky a ručné zásahy, ktoré postupne vracajú firmu k tabuľkám.
• Podpora nie je zmluvne dohodnutá, takže sa každá otázka rieši ad hoc.
• Pri zmene legislatívy, napríklad v elektronickej fakturácii alebo evidencii tržieb, nie je jasné, kto zabezpečí úpravu systému. Pozrite si prehľad právnych požiadaviek na ERP.

Roly, ktoré projekt potrebuje

Etapy sú len polovica obrazu. Druhou polovicou sú ľudia. Funkčný projekt potrebuje na strane firmy vždy tieto roly:

• Vlastník projektu s právomocou rozhodovať o rozpočte, rozsahu a prioritách, zvyčajne konateľ alebo finančný riaditeľ.
• Vedúci projektu s vyhradeným časom, ktorý komunikuje s integrátorom a sleduje míľniky.
• Vedúci oddelení a skutoční používatelia, ktorí sa zúčastňujú na workshopoch a testoch.
• Účtovník alebo vedúci financií, ktorý odsúhlasuje daňové nastavenia, zostatky a výstupy pre úrad.
• Správca dát, ktorý zodpovedá za čistotu číselníkov aj po štarte.

Integrátor má na svojej strane vedúceho projektu, konzultantov pre jednotlivé oblasti a technikov. Ak sa vám ich zloženie nepozdáva alebo sa počas projektu mení, hovorte o tom hneď.

Čo platí bez ohľadu na zvolený systém

Podobná kostra platí pre všetky systémy, ktoré na stránke porovnávame. Líši sa miera, v akej sa dá veľa vyriešiť nastavením a koľko práce vyžaduje úprava. Pri menšej firme s jednoduchým účtovníctvom môže byť projekt s POHODA kratší a lacnejší, pri firme s viacerými spoločnosťami a výrobou nadobúdajú väčšiu váhu návrh a prenos dát. Pri otvorených riešeniach sa väčšia časť práce sústreďuje na prispôsobenie, pri uzavretých na správne nastavenie a licencie.

Pravidlá, ktoré sa osvedčujú v každom z nich:

• Rozsah sa mení len písomne a s vedomím dopadu na čas aj peniaze.
• Rozhodnutia sa dokumentujú, aby sa neotvárali znova.
• Míľnik sa uzatvára odsúhlasením, nie ústnym „asi je to hotové“.
• Štart sa neposúva z lenivosti, ale ani sa nevynucuje za každú cenu.

Prehľad bežných zlyhaní a ich príčin nájdete v časti o chybách ERP projektov.

Ako sa pripraviť ešte pred prvým stretnutím s integrátorom

Dobrý projekt sa začína doma. Skôr než oslovíte dodávateľa, vyplatí sa urobiť niekoľko krokov, ktoré nič nestoja a skrátia analýzu:

• Spíšte hlavné procesy firmy od objednávky po platbu a označte miesta, kde sa dnes stráca čas alebo vznikajú chyby.
• Zistite, aké systémy a súbory dnes používate, kto ich spravuje a ako sú prepojené.
• Zoznam povinností, ktoré musí systém plniť: pokladnica s e-kasou, DPH a kontrolný výkaz, elektronické faktúry, prípadne špecifiká odvetvia.
• Určte, kto bude vlastníkom a kto vedúcim projektu, a uvoľnite im čas.
• Premyslite, či budete pracovať v jednej spoločnosti alebo v skupine, v jednej prevádzke alebo vo viacerých krajoch.

S takto pripraveným podkladom sa rozhovor s integrátorom zmení z hľadania problému na hľadanie riešenia. Ak chcete, aby sa váš kontakt dostal k vhodnému integrátorovi, popíšte svoj projekt v dopyte a my ho odovzdáme tomu, kto sa na podobné zadania zameriava.

Uvedené názvy softvéru sú ochranné známky ich príslušných výrobcov a uvádzajú sa len na informačné účely. Táto stránka je nezávislá a nie je prepojená so žiadnym výrobcom.