Riziká migrácie účtovného systému pod kontrolou

Migrácia účtovníctva málokedy zlyhá pre samotný import dát. Problém zvyčajne nastane vo chvíli, keď firma zistí, že nové zostatky nesedia so starou hlavnou knihou, faktúry na seba správne nenadväzujú alebo sa účtovný tím musí vrátiť k manuálnym tabuľkám. Riziká migrácie účtovného systému, v projektovej praxi často označované ako accounting system migration risks, preto nie sú iba otázkou IT. Môžu ovplyvniť účtovnú závierku, cash flow, daňové výstupy, ocenenie zásob aj dôveru vedenia v reporting.

Vo výrobnej firme môže nesprávne prenesené ocenenie zásob skresliť maržu. V e-commerce sa problém môže prejaviť neprepojenými dobropismi a platbami. V logistike zase chýbajúce väzby medzi zákazkou, dodávkou a faktúrou komplikujú kontrolu ziskovosti. Dobre riadená migrácia nevzniká rýchlym exportom a importom. Je výsledkom rozhodnutí o tom, ktoré dáta sa majú preniesť, ako sa overia a kto prevezme zodpovednosť za ich správnosť.

Prečo sú riziká migrácie účtovného systému také významné

Účtovný systém nie je izolovaná databáza. Zvyčajne prijíma dáta z CRM, e-shopu, banky, skladu, dochádzky, výroby alebo nástroja na správu zákaziek. Zároveň odovzdáva výstupy do reportingu, konsolidačných prehľadov a často aj do systémov na daňové a mzdové spracovanie. Pri zmene systému sa teda nepresúvajú iba účtovné doklady. Mení sa tok informácií naprieč prevádzkou.

Najväčším rizikom je falošný pocit istoty. Ak sa podarí nahrať tisíce zákazníkov, faktúr a položiek hlavnej knihy bez chybového hlásenia, projekt môže na prvý pohľad pôsobiť úspešne. To však neznamená, že sú dáta použiteľné. Duplicity, nesprávne mapovanie analytických účtov alebo stratené väzby medzi dokladmi sa často prejavia až pri účtovnej závierke, reklamácii či audite.

Treba tiež rozlišovať medzi technickou a prevádzkovou správnosťou. Technicky môže byť záznam v správnom formáte. Pre účtovné oddelenie však môže byť bezcenný, ak mu chýba stredisko, zákazka, dátum zdaniteľného plnenia, mena alebo história úhrad. Kvalitný projekt preto neposudzuje iba to, či dáta prešli importom, ale aj to, či podporujú reálne účtovné a manažérske procesy.

Najčastejšie zdroje problémov pri migrácii

Nekvalitné alebo nejednotné zdrojové dáta

Staršie účtovné systémy často obsahujú roky historických záznamov, ktoré vznikali v rôznych obdobiach a podľa rôznych pravidiel. Jeden zákazník môže byť evidovaný viackrát pod odlišnými názvami. Strediská môžu byť neaktívne, ale stále sa objavovať na otvorených dokladoch. Číselníky produktov môžu obsahovať neplatné sadzby DPH alebo historické merné jednotky.

Preniesť všetko bez kontroly je lákavé, pretože to skracuje prípravnú fázu. V skutočnosti sa tým však prenesie aj prevádzkový dlh. Nový systém potom začne fungovať s rovnakými chybami, iba v modernejšom rozhraní. Správnym postupom je najskôr dáta profilovať: zistiť ich úplnosť, duplicity, chýbajúce hodnoty, neplatné väzby a odchýlky v kľúčových zostatkoch. Až potom možno rozhodnúť, ktorá história sa skutočne migruje a ktorá zostane dostupná iba v archíve.

Chybné mapovanie účtovnej logiky

Mapovanie nie je mechanické prepísanie poľa zo starého systému do nového. Každá účtovná sústava má vlastnú účtovnú osnovu, analytické účty, dimenzie, pravidlá účtovania a spôsob práce s DPH. Starší systém mohol napríklad rozlišovať ziskové strediská v textovej poznámke, zatiaľ čo nový ERP systém vyžaduje samostatnú dimenziu. Ak sa tento rozdiel nevyrieši už v návrhu, reporting po spustení nebude porovnateľný.

Kritické je mapovanie hlavnej knihy, saldokonta, daňových kódov, mien, stredísk a zákaziek. Rovnako dôležité sú počiatočné zostatky a väzby medzi pohľadávkami, záväzkami, platbami a párovaním. Firma musí vopred definovať, čo znamená správne prenesený stav. Nestačí tvrdiť, že sa súčet účtov zhoduje. Musí byť jasné, ako sa overia jednotlivé účtovné okruhy a kto výsledky schváli.

Prerušené integrácie a nejasné vlastníctvo dát

Účtovný systém je zvyčajne závislý od integrácií viac, než sa na začiatku projektu očakáva. E-shop vytvára objednávky, CRM odovzdáva údaje o zákazníkoch, banka posiela výpisy, sklad generuje pohyby a reporting načítava dáta pre vedenie. Ak sa rozhrania neotestujú v reálnych scenároch, firma môže po spustení zistiť, že doklady síce existujú, ale nevznikajú automaticky alebo sa účtujú na nesprávne miesta.

Každý významný dátový tok preto potrebuje vlastníka na obchodnej aj technickej strane. IT tím nemôže samostatne potvrdiť správnosť DPH, účtovník zase nemôže bez podpory vývoja rozhodnúť o správaní API. Zodpovednosť musí byť rozdelená jasne: kto dáta vytvára, kto ich kontroluje, kto rieši výnimky a kto schvaľuje zmenu pravidiel.

Nedostatočné testovanie a príliš rýchle ostré spustenie

Testovacia migrácia nie je jednorazová skúška importu. Je to priestor, v ktorom sa overuje celý prevádzkový reťazec. Firma by mala vykonať test na reprezentatívnych dátach, porovnať výsledky so zdrojovým systémom, opraviť pravidlá a test zopakovať. Pri zložitejších organizáciách má zmysel testovať oddelene účtovníctvo, sklad, objednávky, bankové procesy a reporting a následne celé scenáre naprieč systémami.

Ostré spustenie počas účtovnej závierky, inventúry alebo sezónnej špičky zvyšuje riziko bez ohľadu na kvalitu dodávateľa. Niekedy je vhodnejšie spustiť nový systém na začiatku účtovného obdobia. Inokedy je potrebný postupný prechod podľa pobočiek, spoločností alebo procesov. Správny variant závisí od objemu transakcií, regulačných povinností aj schopnosti tímu zvládnuť zmenu v prevádzke.

Ako znížiť riziko ešte pred prvým importom

Úspešné projekty sa začínajú jasným rozsahom. Firma musí rozhodnúť, či prenesie kompletnú históriu, iba aktuálny účtovný rok, alebo len počiatočné zostatky a aktívne doklady. Viac dát znamená lepšiu dostupnosť histórie v novom systéme, ale aj viac transformácií, testovania a možných chýb. Pre mnohé stredne veľké firmy je praktickejšie ponechať staršie obdobia v zabezpečenom archíve a do nového systému preniesť dáta potrebné na každodennú prácu, plnenie zákonných povinností a porovnateľné riadenie výkonnosti.

Ďalším krokom je vytvorenie migračného návrhu, ktorý opisuje zdroj každej dátovej oblasti, cieľovú štruktúru, transformačné pravidlá, zodpovednú osobu a metódu kontroly. Tento dokument má byť pracovným nástrojom, nie formálnou prílohou projektu. Ak sa počas testu zmení pravidlo účtovania alebo vytvárania zákazníkov, zmena musí byť dohľadateľná a schválená.

Pred ostrým spustením by mali byť potvrdené aspoň tieto kontrolné body:

• zhoda hlavnej knihy, saldokonta, bankových zostatkov a otvorených položiek,
• správne mapovanie DPH, mien, stredísk, zákaziek a účtovných dimenzií,
• funkčné integrácie s kritickými prevádzkovými systémami,
• otestované výnimky, napríklad dobropisy, storná, čiastočné úhrady a opravy dokladov,
• pripravený plán návratu alebo obmedzenej prevádzky, ak sa objaví závažná chyba.

Kontrola musí byť založená na konkrétnych dôkazoch, nie na dojme, že systém vyzerá správne. To znamená porovnávať kontrolné súčty, počty záznamov, vzorky konkrétnych dokladov a výstupy reportov. Pri zásadných dátových oblastiach je vhodné, aby výsledky schválil finančný vlastník procesu, nielen projektový manažér.

Úloha automatizácie a skúseného implementačného partnera

Automatizácia môže výrazne znížiť množstvo manuálnych zásahov pri čistení, transformácii a overovaní dát. Dokáže identifikovať duplicitné záznamy, kontrolovať povinné polia, porovnávať zostatky medzi systémami a upozorňovať na neobvyklé odchýlky. Nenahrádza však účtovné rozhodovanie. Systém môže označiť problematický daňový kód, ale pravidlo jeho použitia musí určiť firma spolu s ľuďmi, ktorí rozumejú jej účtovníctvu a prevádzke.

Práve tu má význam partner, ktorý rozumie ERP, integráciám aj automatizácii pracovných tokov. Logyloop pristupuje k migráciám ako k súčasti širšej modernizácie prevádzky, nie ako k izolovanej technickej úlohe. Cieľom nie je iba preniesť minulosť do nového systému, ale nastaviť kvalitnejšie dáta, spoľahlivejšie väzby a menej manuálnej práce do budúcnosti.

Najlepší čas na zníženie rizika nie je deň pred spustením. Je to chvíľa, keď firma prvýkrát rozhoduje, ako budú v novom systéme vznikať doklady, kto bude vlastniť dáta a podľa akých čísel bude riadiť svoju výkonnosť. Migrácia potom nie je skokom do neznáma, ale riadeným prechodom k účtovníctvu, ktorému môže vedenie dôverovať.