Według GUS z systemów ERP korzysta dziś 40,5% firm w Polsce – dwa lata wcześniej było to 36%. Liczba rośnie, a wraz z nią rośnie pewne nieporozumienie: że skoro firma ma ERP, to dane w firmie krążą same.
Nie krążą. W większości organizacji, do których wchodzimy, widzimy, że ERP jest szczelny w środku i całkowicie odcięty na zewnątrz. Faktura przychodzi mailem albo przez KSeF, ktoś ją otwiera, patrzy na numer kontrahenta, przepisuje do ERP-a, potem zapisuje PDF na dysku sieciowym w folderze nazwanym rokiem i miesiącem. Ten sam dokument istnieje w dwóch miejscach, w dwóch formatach, z dwoma różnymi zestawami metadanych…
W tym artykule przeczytasz o:
- Gdzie dokładnie w firmie powstaje podwójne wprowadzanie danych i dlaczego nikt tego nie zgłasza
- Gdzie rozjazd między archiwum a ERP wychodzi na jaw i dlaczego zawsze w najgorszym momencie
- Pięciu ścieżkach technicznych, którymi DocuWare łączy się z ERP
- Czterech wdrożeniach z różnymi systemami ERP i tym, co z nich wyszło
- Dlaczego co drugi projekt integracyjny przekracza budżet i jak tego uniknąć
Podwójne wprowadzanie danych nie jest błędem, lecz procedurą
To jest rzecz, którą najtrudniej wytłumaczyć zarządowi. Nikt w firmie nie podjął decyzji „przepisujmy dane dwa razy”. To zachowanie narosło przez lata, bo ERP wdrożono w 2016, system kadrowy w 2019, a repozytorium umów założono na dysku współdzielonym, kiedy dział prawny miał dość szukania po mailach. Każde z tych narzędzi rozwiązywało realny problem jednego działu i żadne z nich nie rozmawiało z pozostałymi.
Luki między nimi zasypali ludzie. Księgowa przepisuje pozycje z faktury do ERP-a. Osoba z zakupów sprawdza w ERP numer zamówienia i wkleja go do nazwy pliku PDF, żeby dało się go później znaleźć. Ktoś z kadr eksportuje listę pracowników do arkusza, bo system kadrowy nie potrafi oddać jej w formacie, który przyjmie archiwum umów.
Żadna z tych osób nie zgłosi tego jako problemu, bo dla nich to po prostu praca. Problem widać dopiero w danych: w rozjazdach między numerami kontrahentów, w duplikatach kartotek, w fakturach zaksięgowanych na złe konto, w dokumencie, którego nie da się znaleźć, bo w nazwie pliku ktoś wpisał numer zamówienia z literówką.
Rozjazd wychodzi na jaw w dwóch momentach
Dopóki oba systemy pracują osobno, na co dzień nic się nie dzieje. Dane rozjeżdżają się po cichu i nikt tego nie mierzy, bo nie ma czym. Ujawnia się to w dwóch sytuacjach:
Pierwsza to uzgodnienie trójstronne: zamówienie, dokument przyjęcia i faktura. Jeśli numer zamówienia w ERP ma format z myślnikiem, a w opisie dokumentu w archiwum ktoś wpisał go bez, pozycje się nie skleją. Faktura trafia do wyjątków, księgowość dzwoni do zakupów, zakupy szukają PZ-ki, a termin płatności biegnie dalej.
Druga to zamknięcie okresu albo audyt. Wtedy wychodzi, że dokument jest w repozytorium, ale nie ma go w ERP, albo że w ERP wisi dwa razy, bo wpłynął i mailem, i przez KSeF. Dla operacji oznacza to dogrywanie różnic w pierwszym tygodniu kolejnego miesiąca. Dla IT serię zgłoszeń w stylu „nie mogę znaleźć faktury z sierpnia”, na które nie ma technicznej odpowiedzi, bo faktura istnieje, tylko w każdym z dwóch systemów pod innym numerem.
Jak to wygląda od strony technicznej
Tu zwykle pada pytanie, na które warto odpowiedzieć konkretnie, bo od niego zależy wycena projektu: czym właściwie te systemy się łączą.
DocuWare ma pięć ścieżek i wybór między nimi zależy od tego, gdzie stoi Twój ERP i jak bardzo chcesz w niego ingerować.
REST API i SOAP Web Services to podstawa dla scenariuszy niestandardowych. Pobieranie metadanych dokumentu, uruchamianie workflow z poziomu ERP-a, walidacja indeksów w czasie rzeczywistym. Tędy idzie większość integracji z polskimi systemami księgowymi, bo prawie każdy z nich udostępnia dziś jakieś API.
Gotowe konektory obejmują moduły Connect to SAP dla instancji ECC 6.0 i S/4HANA, osobny konektor dla S/4HANA Public Cloud oparty na standardzie CMIS, oraz Connect to DATEV dla firm rozliczających się w niemieckim ekosystemie księgowym.
Local Data Connector rozwiązuje sytuację hybrydową, którą widzimy coraz częściej: DocuWare stoi w chmurze, a ERP został na serwerze w serwerowni. Connector pozwala chmurowej instancji odpytywać lokalną bazę – SQL Server, Oracle, MySQL, dowolne źródło przez ODBC – żeby synchronizować kartoteki kontrahentów i słowniki księgowe.
Konektory iPaaS przez Make.com i Microsoft Power Automate dają połączenia bezkodowe. Tą drogą DocuWare łączy się z ponad tysiącem narzędzi SaaS, co ma znaczenie, jeśli w firmie oprócz ERP-a działa CRM, system obsługi zgłoszeń i pięć innych aplikacji, których nikt nie planuje wymieniać.
Smart Connect to rozwiązanie dla systemów, których nie wolno ruszać. Moduł odczytuje słowa kluczowe bezpośrednio z ekranu aplikacji ERP, bez ingerencji w jej kod, z poziomu otwartego dokumentu w ERP użytkownik jednym przyciskiem wywołuje powiązane dokumenty z archiwum. Stosujemy to tam, gdzie producent ERP-a nie przewidział interfejsu albo gdzie każda modyfikacja systemu wymaga zgody centrali.
Łącznie DocuWare ma dziś zintegrowanych 500 aplikacji biznesowych. Ta liczba jest mniej istotna niż fakt, że przy standardowym ERP nie zaczynasz od pisania własnego interfejsu.
Cztery firmy, cztery różne systemy ERP – case studies DocuWare
Alfred rexroth, niemiecki zakład obróbki metali, spiął DocuWare z SAP Business One i zautomatyzował 80% pracy działu dokumentacji technicznej. Przez ich archiwum przechodzi kilkaset tysięcy dokumentów rocznie w obiegu odpornym na audyt.
Owens Group, brytyjska firma transportowa, połączyła archiwum z Sage 200 przez bezpośrednie mapowanie indeksów. Efekt opisany w case study jest tak prosty, jak to tylko możliwe: ręczne wprowadzanie danych z faktur i zamówień do rejestrów Sage przestało istnieć.
Browar Riegele z Augsburga trzyma 840 000 dokumentów w jednym repozytorium zintegrowanym z SAP-em i automatycznie uzgadnia faktury przychodzące z dowodami dostaw.
Jura Products, brytyjski dystrybutor sprzętu AGD, pracuje na Microsoft Dynamics NAV. Cały wolumen obsługi posprzedażowej na rynek brytyjski prowadzi pięcioosobowy zespół, któremu dokumentacja serwisowa i faktury otwierają się natychmiast z poziomu systemu.
Cztery różne ERP-y, cztery różne branże. Wspólny mianownik jest jeden: dane wprowadza się raz, w miejscu, w którym powstają.
Gdzie te projekty się wywracają
Będziemy uczciwi, bo obiecywanie, że integracja to konfiguracja na dwa popołudnia, kończy się źle dla obu stron.
Panorama Consulting Group przebadała wdrożenia systemów klasy enterprise i tylko 46,4% z nich zmieściło się w budżecie. Mediana projektu to 450 tysięcy dolarów i 15,5 miesiąca – mówimy o dużych wdrożeniach, ale struktura przyczyn niepowodzeń powtarza się niezależnie od skali.
Na pierwszym miejscu, w 38% nieudanych projektów, przyczyną porażki jest brak wyznaczonego właściciela procesu po stronie klienta. Nikt nie ma mandatu, żeby rozstrzygnąć, kto akceptuje fakturę powyżej określonej kwoty i co się dzieje, gdy ta osoba jest na urlopie. Bez tej decyzji nie da się zaprojektować workflow, więc projekt stoi.
Drugie miejsce, 35% przypadków, to rozrost zakresu. Zwykle zaczyna się od zdania „a czy dałoby się zrobić tak, jak mamy teraz” – i zamiast standardowego konektora powstaje indywidualna modyfikacja odtwarzająca przyzwyczajenie, które samo w sobie było obejściem starego problemu.
Trzecie, 34%, to jakość danych i mapowanie pól. Duplikaty kartotek kontrahentów, ten sam dostawca zapisany na trzy sposoby, niespójne plany kont. Interfejs działa poprawnie i dlatego odrzuca pakiety, których nie umie dopasować. Ta praca i tak musi zostać wykonana, pytanie tylko, czy przed startem projektu, czy w jego trakcie, kiedy kosztuje wielokrotnie więcej.
Dlatego na starcie zawsze pytamy o dwie rzeczy: kto podejmuje decyzje procesowe i w jakim stanie są słowniki w ERP. Odpowiedzi na te pytania mówią o powodzeniu projektu więcej niż specyfikacja techniczna.
KSeF zamyka dyskusję o ręcznym przepisywaniu
Od 1 lutego 2026 obowiązkowe e-fakturowanie objęło firmy, których obrót brutto za 2024 rok przekroczył 200 milionów złotych. Od 1 kwietnia 2026 wszystkich pozostałych podatników VAT.
Faktura przestała być plikiem PDF, który ktoś może wydrukować i położyć na biurku. Jest ustrukturyzowanym rekordem XML walidowanym po stronie Ministerstwa Finansów. Ręczne przepisywanie kilkudziesięciu pól ze schemy XML do ERP-a nie jest trudne, ono po prostu nie ma sensu, skoro dane przychodzą już w formacie nadającym się do bezpośredniego wczytania.
W tym układzie system zarządzania dokumentami przestaje być archiwum, do którego zagląda się po fakcie. Pobiera XML z KSeF przez API, odczytuje pozycje kosztowe, wiąże dokument z zamówieniem i dowodem przyjęcia w ERP, prowadzi go przez akceptacje i oddaje gotowy dekret. Człowiek wchodzi tam, gdzie trzeba podjąć decyzję, a nie tam, gdzie trzeba przepisać numer.
Od czego więc zacząć
Nie od wyboru systemu. Od jednego procesu, w którym te same dane wprowadzacie dwa razy, najczęściej jest to obieg faktur zakupowych, czasem dokumentacja pracownicza, czasem umowy z dostawcami. Policzcie, ile razy w miesiącu ten sam numer trafia do dwóch systemów z klawiatury. To jest Wasz punkt startowy i Wasza pierwsza wycena.
Jeśli chcesz to przejść z kimś, kto widział, jak takie projekty wyglądają od środka – również te, które poszły źle – odezwij się. Jedna rozmowa może zaoszczędzić miesięcy szukania rozwiązań.
