W planach rolloutowych Polska pozornie może wyglądać jak kolejny kraj do uruchomienia w globalnym szablonie. Na poziomie formalnym wszystko zwykle wydaje się proste: gotowy template, ustalone procesy, lokalna konfiguracja podatków, testy, start. W praktyce rollout Dynamics 365 do Polski rzadko układa się tak gładko. Najczęściej problem zaczyna się wtedy, gdy centrala zbyt późno odkrywa, że polskie wymagania dotyczą nie tylko ustawień, ale też specyfiki raportowania, obiegu dokumentów, płatności i jakości danych źródłowych.
Dla partnerów wdrożeniowych to ważna różnica. Rollout do Polski komplikuje się przez serię drobnych założeń, które na początku projektu wydają się rozsądne, a później wracają jako poprawki, opóźnienia i napięcie między centralą, lokalnym biznesem i partnerem wdrożeniowym.
Polska to nie jest tylko kolejnym krajem w global template
Jednym z częstych błędów jest potraktowanie Polski jak zwykłego rozszerzenia już działającego modelu. W praktyce okazuje się, że polska spółka wymaga czegoś więcej niż uruchomienia tych samych procesów w nowej jednostce. Dochodzą lokalne obowiązki, które wpływają nie tylko na raporty końcowe, ale też na sposób prowadzenia danych i codzienną pracę działu finansów.
To ważne już na etapie planowania. Jeżeli centrala zakłada, że Polska „dopnie się” na końcu, projekt zaczyna działać reaktywnie. Zespół nie przygotowuje kraju pod lokalne wymogi, tylko próbuje je dopisać do gotowej konstrukcji.
JPK zaczyna się wcześniej, niż wielu zakłada
JPK bywa mylnie traktowany jak lokalny raport, który trzeba po prostu wygenerować. W rzeczywistości problem rzadko pojawia się na końcu, przy samym pliku. Zwykle zaczyna się dużo wcześniej: przy klasyfikacji transakcji, oznaczeniach, mapowaniach, logice dokumentów i jakości danych źródłowych.
To powoduje, że rollout do Polski wymaga wcześniejszego przygotowania. Jeżeli dane nie są prowadzone w sposób, który później pozwala na poprawne raportowanie, sam system niewiele pomoże. Technicznie wszystko może działać, ale lokalna spółka nadal nie będzie gotowa do bezpiecznej pracy.
KSeF zmienia nie tylko fakturę, ale cały obieg dokumentów
Drugi obszar, który często bywa niedoszacowany, a który aktualnie jest mocno na czasie to KSeF. Bywa, że temat e-fakturowania traktuje się tylko jako kolejną integrację, którą można dołożyć później. W praktyce chodzi o coś więcej. KSeF wpływa na sposób wystawiania i odbierania faktur, obieg dokumentów, testy, uprawnienia i gotowość operacyjną zespołu.
Nie można potraktować tego jako kolejnego dodatku do końcowej fazy projektu. Jeżeli rollout nie uwzględni KSeF odpowiednio wcześnie, organizacja bardzo szybko zacznie nadrabiać to ręcznymi obejściami i dodatkowymi poprawkami.
Split payment i biała lista wpływają na codzienną operację
Kolejne zaskoczenie może pojawić się w obszarze płatności. Globalny model zakupów i płatności może wyglądać dobrze z perspektywy centrali, ale w Polsce dochodzą dodatkowe reguły, które mają realny wpływ na codzienną operację. Chodzi między innymi o split payment i białą listę podatników VAT.
To nie są poboczne elementy konfiguracji. One wpływają na kontrole, sposób realizacji płatności i zakres automatyzacji. Gdy projekt odkłada je na później, lokalny zespół zwykle wraca do ręcznego sprawdzania i obchodzenia braków procesowych.
Dane lokalne trzeba ustalić przed testami, nie po nich
W rolloutach do Polski często wraca ten sam problem: zbyt późne włączenie lokalnego zespołu do rozmowy o danych. Formalnie wszystko może się zgadzać. Plan kont działa, dokumenty się księgują, proces zakupowy i sprzedażowy ma swój ciąg logiczny. Dopiero przy raportowaniu albo testach okazuje się, że jednak czegoś brakuje.
Wtedy projekt przestaje być wdrożeniem systemu, a zaczyna być porządkowaniem rzeczy, które powinny zostać ustalone dużo wcześniej. A na tym etapie pojawia się presja czasu, poprawki i napięcie po stronie biznesu. Rekomendujemy, aby włączać lokalne zespoły już na etapie projektowania procesów.
Największe ryzyko nie leży w systemie, tylko w założeniach projektu
Wielu problemów da się uniknąć, ale pod jednym warunkiem: Polska musi zostać potraktowana jako kraj wymagający wcześniejszego przygotowania, a nie jako lokalny dodatek do globalnego modelu. Im wcześniej zespół zada sobie pytanie, które elementy template naprawdę nadają się do przeniesienia bez zmian, tym mniejsze ryzyko kosztownych korekt pod koniec projektu.
Dla partnerów wdrożeniowych to dziś jedna z ważniejszych kompetencji. Istotne jest, aby odpowiednio wcześnie zobaczyć miejsca, w których standardowy plan rolloutowy nie pokazuje całego ryzyka.
Co warto zrobić przed rolloutem do Polski
Przed startem projektu warto uporządkować kilka obszarów, które później decydują o tym, czy rollout będzie przewidywalny, czy zamieni się w serię poprawek.
Pierwszy krok to audyt procesów i obowiązków lokalnych. Chodzi o to, żeby jeszcze przed konfiguracją szczegółowo ustalić, które obszary wpływają na raportowanie, obieg dokumentów, płatności i pracę finansów. Wszystko po to, aby jak najdokładniej wychwycić miejsca, w których globalne założenia nie pokrywają się z polskimi wymaganiami.
Drugi krok to weryfikacja danych i mapowań. Jeśli zespół odkłada ją na później, problemy wracają zwykle przy testach albo raportowaniu. Wtedy okazuje się, że dokumenty księgują się poprawnie, ale dane nie są przygotowane pod lokalne obowiązki.
Trzeci element to decyzja, co zostaje w global template, a co powinno trafić do lokalnego rozszerzenia. To właśnie tutaj rozstrzyga się, czy projekt będzie próbował zmieścić Polskę w uniwersalnym modelu, czy dopuści lokalne różnice tam, gdzie są one potrzebne.
Kolejny punkt to UAT z udziałem polskiego biznesu i finansów. Bez tego rollout wygląda dobrze tylko z perspektywy projektu. Dopiero lokalni użytkownicy są tak naprawdę w stanie rzetelnie sprawdzić, czy rozwiązanie działa w codziennej pracy.
Na końcu warto zaplanować wsparcie po go-live. To właśnie po starcie najczęściej wychodzą wyjątki procesowe i lokalne potrzeby, których nie udało się wychwycić wcześniej. Bez takiego planu organizacja szybko wraca do ręcznych obejść.
Polska wymaga wcześniejszego przygotowania, nie późniejszych poprawek
Jeżeli planujesz rollout Dynamics 365 do Polski i chcesz wcześniej sprawdzić, które obszary wymagają lokalnego przygotowania, warto przeanalizować je jeszcze przed wejściem w fazę końcowej konfiguracji i testów. To właśnie wtedy najłatwiej ograniczyć ryzyko, które później wraca już jako koszt projektu i problem operacyjny.
Na tym etapie możemy pomóc uporządkować najważniejsze obszary projektu: od weryfikacji lokalnych wymagań, przez ocenę gotowości danych i procesów, po wskazanie miejsc, w których globalny template wymaga dopracowania pod polskie realia. Dzięki temu łatwiej wychwycić ryzyka wcześniej, zamiast poprawiać je już pod presją czasu.
Jeżeli chcesz lepiej zrozumieć, jak wygląda zakres Polskiej Lokalizacji w Dynamics 365 i jakie obszary najczęściej wymagają przygotowania przy wdrożeniu lub rolloucie, pobierz też nasz e-book o Polskiej Lokalizacji. Znajdziesz tam uporządkowane informacje o wymaganiach, modułach i etapach przygotowania projektu.
FAQ
Czy rollout Dynamics 365 do Polski można oprzeć wyłącznie na global template
Zazwyczaj nie. Global template zwykle wymaga wcześniejszej weryfikacji pod kątem polskich obowiązków podatkowych, raportowych i operacyjnych.
Czy KSeF to tylko dodatkowa integracja?
Nie. Mimo, że KSeF z założenia jest raportem z danych w systemie, dość szybko może zweryfikować obecne procesy biznesowe związane z fakturowaniem. Może się okazać, że niektóre z nich będą wymagać usprawnień (np. rabaty od obrotu).
Czy lokalny zespół powinien być zaangażowany przed UAT?
Zdecydowanie tak. Musi to nastąpić jeszcze w fazie projektowania procesów. Zbyt późne włączenie lokalnego biznesu i finansów często kończy się poprawkami pod presją czasu, bo dopiero wtedy wychodzą braki w danych, procesach i raportowaniu.
Co warto sprawdzić przed rolloutem ERP do Polski?
Warto przeanalizować lokalne obowiązki, dane, mapowania, wpływ polskich wymagań na płatności i dokumenty oraz udział lokalnego zespołu w warsztatach procesowych i testach.
Nie zwlekaj! Zarejestruj się już teraz.
O nas
Firma GO-ERP to Partner Microsoft Dynamics 365, którego biura znajdują się na Litwie, w Polsce oraz w Wielkiej Brytanii. Oferujemy szeroki zakres usług i rozwiązań dla klientów z całego świata. GO-ERP zajmuje się takimi usługami jak wdrażanie, migracje, obsługa oraz rozwój aplikacji D365. Jako Złoty Partner Microsoft zapewniamy wysokiej jakości usługi i niestandardowe rozwiązania w oparciu o innowacyjną platformę Dynamics 365.
