Ryzyka migracji systemu księgowego pod kontrolą
Migracja księgowości rzadko kończy się niepowodzeniem z powodu samego importu danych. Problem pojawia się zazwyczaj wtedy, gdy firma odkrywa, że nowe salda nie zgadzają się ze starą księgą główną, faktury nie mają prawidłowych powiązań albo zespół księgowy musi wrócić do ręcznie prowadzonych arkuszy. Ryzyka migracji systemu księgowego, często określane w praktyce projektowej jako accounting system migration risks, nie są więc wyłącznie kwestią IT. Mogą wpływać na zamknięcie okresu, przepływy pieniężne, rozliczenia podatkowe, wycenę zapasów oraz zaufanie zarządu do raportowania.
W firmie produkcyjnej nieprawidłowo przeniesiona wycena zapasów może zniekształcić marżę. W e-commerce problemem mogą być niepowiązane faktury korygujące i płatności. W logistyce brak relacji między zleceniem, dostawą a fakturą utrudnia kontrolę rentowności. Dobrze zarządzana migracja nie polega na szybkim eksporcie i imporcie. Jej podstawą jest decyzja o tym, które dane należy przenieść, jak zostaną zweryfikowane i kto przejmie odpowiedzialność za ich poprawność.
Dlaczego ryzyka migracji systemu księgowego są tak istotne
System księgowy nie jest odizolowaną bazą danych. Zazwyczaj otrzymuje dane z CRM, sklepu internetowego, banku, magazynu, systemu ewidencji czasu pracy, produkcji lub narzędzia do zarządzania zleceniami. Jednocześnie przekazuje informacje do raportowania, zestawień konsolidacyjnych, a często także do systemów obsługujących podatki i płace. Zmiana systemu nie oznacza więc wyłącznie przeniesienia dokumentów księgowych. Zmienia się przepływ informacji w całej działalności operacyjnej.
Największym ryzykiem jest fałszywe poczucie pewności. Jeżeli uda się wczytać tysiące klientów, faktur i pozycji księgi głównej bez komunikatu o błędzie, projekt może na pierwszy rzut oka wydawać się udany. Nie oznacza to jednak, że dane nadają się do użytku. Duplikaty, nieprawidłowe mapowanie kont analitycznych lub utracone powiązania między dokumentami często ujawniają się dopiero podczas zamknięcia okresu, reklamacji albo audytu.
Trzeba również rozróżnić poprawność techniczną od poprawności operacyjnej. Z technicznego punktu widzenia rekord może mieć właściwy format. Dla działu księgowości będzie jednak bezwartościowy, jeśli zabraknie w nim centrum kosztów, zlecenia, daty powstania obowiązku podatkowego, waluty lub historii płatności. Dobry projekt ocenia zatem nie tylko to, czy dane zostały zaimportowane, lecz także czy wspierają rzeczywiste procesy księgowe i zarządcze.
Najczęstsze źródła problemów podczas migracji
Niska jakość lub niespójność danych źródłowych
Starsze systemy księgowe często zawierają wieloletnie dane historyczne, które powstawały w różnych okresach i według odmiennych zasad. Ten sam klient może figurować w systemie kilka razy pod różnymi nazwami. Centra kosztów mogą być nieaktywne, a mimo to nadal występować na otwartych dokumentach. Kartoteki produktów mogą zawierać nieaktualne stawki VAT lub historyczne jednostki miary.
Przeniesienie wszystkiego bez kontroli jest kuszące, ponieważ skraca etap przygotowań. W praktyce oznacza jednak również przeniesienie długu operacyjnego. Nowy system zaczyna wtedy działać z tymi samymi błędami, tylko w nowocześniejszym interfejsie. Właściwym podejściem jest najpierw profilowanie danych: sprawdzenie ich kompletności, duplikatów, brakujących wartości, nieprawidłowych powiązań oraz rozbieżności w kluczowych saldach. Dopiero później można zdecydować, które dane historyczne rzeczywiście zostaną zmigrowane, a które pozostaną dostępne wyłącznie w archiwum.
Błędne mapowanie logiki księgowej
Mapowanie nie polega na mechanicznym przepisaniu pola ze starego systemu do nowego. Każdy system księgowy ma własny plan kont, konta analityczne, wymiary, reguły księgowania i sposób obsługi VAT. Starszy system mógł na przykład rozróżniać centra zysku za pomocą notatki tekstowej, podczas gdy nowy system ERP wymaga osobnego wymiaru. Jeżeli ta różnica nie zostanie uwzględniona na etapie projektowania, raportowanie po uruchomieniu nie będzie porównywalne.
Kluczowe znaczenie ma mapowanie księgi głównej, rozrachunków, kodów podatkowych, walut, centrów kosztów i zleceń. Równie ważne są salda otwarcia oraz powiązania między należnościami, zobowiązaniami, płatnościami i ich uzgadnianiem. Firma musi z wyprzedzeniem zdefiniować, co oznacza prawidłowo przeniesiony stan. Nie wystarczy stwierdzić, że sumy na kontach się zgadzają. Trzeba jasno określić, w jaki sposób zostaną zweryfikowane poszczególne obszary księgowe i kto zatwierdzi wyniki.
Przerwane integracje i niejasna odpowiedzialność za dane
System księgowy zazwyczaj zależy od integracji w większym stopniu, niż zakłada się na początku projektu. Sklep internetowy tworzy zamówienia, CRM przekazuje dane klientów, bank przesyła wyciągi, magazyn generuje ruchy, a system raportowy odczytuje dane dla zarządu. Jeżeli interfejsy nie zostaną przetestowane w rzeczywistych scenariuszach, po uruchomieniu firma może odkryć, że dokumenty wprawdzie istnieją, ale nie powstają automatycznie albo są księgowane w niewłaściwych miejscach.
Każdy istotny przepływ danych powinien zatem mieć właściciela zarówno po stronie biznesowej, jak i technicznej. Zespół IT nie może samodzielnie potwierdzić poprawności VAT, a księgowość bez wsparcia programistów nie może zdecydować o działaniu API. Odpowiedzialność trzeba jasno rozdzielić: kto tworzy dane, kto je kontroluje, kto obsługuje wyjątki i kto zatwierdza zmianę reguł.
Niewystarczające testy i zbyt szybkie uruchomienie produkcyjne
Migracja testowa nie jest jednorazową próbą importu. To etap, na którym weryfikuje się cały łańcuch operacyjny. Firma powinna przeprowadzić test na reprezentatywnych danych, porównać wyniki z systemem źródłowym, poprawić reguły i powtórzyć test. W bardziej złożonych organizacjach warto osobno przetestować księgowość, magazyn, zamówienia, procesy bankowe i raportowanie, a następnie całe scenariusze przebiegające przez wiele systemów.
Uruchomienie produkcyjne w trakcie zamknięcia okresu księgowego, inwentaryzacji lub sezonowego szczytu zwiększa ryzyko niezależnie od jakości dostawcy. Niekiedy lepiej wdrożyć nowy system na początku okresu rozliczeniowego. W innych przypadkach konieczne jest stopniowe przejście według oddziałów, spółek lub procesów. Właściwy wariant zależy od wolumenu transakcji, obowiązków regulacyjnych oraz zdolności zespołu do poradzenia sobie ze zmianą w bieżącej działalności.
Jak ograniczyć ryzyko jeszcze przed pierwszym importem
Udane projekty zaczynają się od jasno określonego zakresu. Firma musi zdecydować, czy przenosi pełną historię, tylko bieżący rok obrotowy, czy wyłącznie salda otwarcia i aktywne dokumenty. Większa ilość danych oznacza lepszy dostęp do historii w nowym systemie, ale także więcej transformacji, testów i potencjalnych błędów. Dla wielu średnich firm bardziej praktyczne jest pozostawienie starszych okresów w zabezpieczonym archiwum oraz przeniesienie do nowego systemu danych niezbędnych do codziennej pracy, realizacji obowiązków ustawowych i porównywalnego zarządzania wynikami.
Kolejnym krokiem jest przygotowanie projektu migracji opisującego źródło każdego obszaru danych, strukturę docelową, reguły transformacji, osobę odpowiedzialną oraz metodę kontroli. Dokument ten powinien być narzędziem roboczym, a nie formalnym załącznikiem do projektu. Jeżeli podczas testów zmieni się reguła księgowania lub tworzenia klientów, zmiana musi być możliwa do prześledzenia i zatwierdzona.
Przed uruchomieniem produkcyjnym należy potwierdzić co najmniej następujące punkty kontrolne:
- zgodność księgi głównej, rozrachunków, sald bankowych i otwartych pozycji,
- prawidłowe mapowanie VAT, walut, centrów kosztów, zleceń i wymiarów księgowych,
- działające integracje z krytycznymi systemami operacyjnymi,
- przetestowane wyjątki, takie jak faktury korygujące, anulowania, płatności częściowe i korekty dokumentów,
- przygotowany plan wycofania zmiany lub pracy w trybie ograniczonym na wypadek wystąpienia poważnego błędu.
Kontrola musi opierać się na konkretnych dowodach, a nie na wrażeniu, że system działa prawidłowo. Oznacza to porównywanie sum kontrolnych, liczby rekordów, próbek konkretnych dokumentów oraz wyników raportów. W przypadku kluczowych obszarów danych wyniki powinien zatwierdzić właściciel finansowy procesu, a nie wyłącznie kierownik projektu.
Rola automatyzacji i doświadczonego partnera wdrożeniowego
Automatyzacja może znacząco ograniczyć liczbę ręcznych działań związanych z czyszczeniem, transformacją i weryfikacją danych. Potrafi wykrywać zduplikowane rekordy, kontrolować pola obowiązkowe, porównywać salda między systemami i sygnalizować nietypowe odchylenia. Nie zastępuje jednak decyzji księgowych. System może wskazać problematyczny kod podatkowy, ale regułę jego stosowania musi określić firma wraz z osobami, które rozumieją jej księgowość i działalność operacyjną.
Właśnie tutaj istotną rolę odgrywa partner, który zna systemy ERP, integracje oraz automatyzację przepływów pracy. Logyloop traktuje migracje jako element szerszej modernizacji działalności operacyjnej, a nie odizolowane zadanie techniczne. Celem nie jest wyłącznie przeniesienie przeszłości do nowego systemu, lecz także zapewnienie lepszej jakości danych, bardziej niezawodnych powiązań i mniejszej ilości pracy ręcznej w przyszłości.
Najlepszym momentem na ograniczenie ryzyka nie jest dzień poprzedzający uruchomienie. Jest nim chwila, w której firma po raz pierwszy decyduje, jak dokumenty będą powstawać w nowym systemie, kto będzie odpowiadać za dane i na podstawie jakich liczb będzie zarządzać swoimi wynikami. Migracja przestaje być wtedy skokiem w nieznane, a staje się kontrolowanym przejściem do księgowości, której zarząd może zaufać.
