Co to jest system ERP i jak pomaga zarządzać firmą?

Firma zaczyna od kilku prostych narzędzi. Zamówienia są obsługiwane w sklepie internetowym, faktury powstają w programie księgowym, stany znajdują się w arkuszu, a informacje o dostawcach przechowuje pracownik odpowiedzialny za zakupy.

Przy niewielkiej skali taki model może działać wystarczająco dobrze.

Problem pojawia się, gdy liczba produktów, zamówień, dokumentów i pracowników zaczyna rosnąć.

Ta sama informacja znajduje się wtedy w kilku miejscach:

• cena produktu w sklepie,
• inna cena w arkuszu,
• stan magazynowy w programie handlowym,
• rezerwacja towaru w systemie sprzedaży,
• dane klienta w sklepie i programie fakturowym,
• status zamówienia w BaseLinkerze,
• dokument sprzedaży w księgowości.

Każda ręczna zmiana zwiększa ryzyko rozbieżności.

Pracownik aktualizuje cenę w jednym systemie, ale zapomina o drugim. Produkt zostaje sprzedany w sklepie, lecz stan magazynowy nie zmniejsza się wystarczająco szybko. Zamówienie jest anulowane, ale rezerwacja towaru nadal pozostaje aktywna.

System ERP może pomóc połączyć takie procesy i wskazać jedno nadrzędne miejsce dla kluczowych danych firmy.

Nie oznacza to jednak, że po zakupie oprogramowania wszystkie problemy automatycznie znikną.

Jeżeli firma nie posiada ustalonego procesu, produkty nie mają stabilnych identyfikatorów, statusy są niejasne, a każdy dział korzysta z własnych zasad, wdrożenie ERP może jedynie przenieść istniejący chaos do większego systemu.

W swojej pracy spotykam firmy, w których system ERP działa od lat, ale sklep internetowy nadal korzysta z osobnych cen, osobnych stanów i ręcznie wprowadzanych dokumentów.

Spotykam również integracje, w których ERP, WooCommerce i BaseLinker próbują równocześnie zarządzać tym samym stanem magazynowym. Każdy system przekazuje inną wartość, a wynik zależy od tego, która synchronizacja wykonała się jako ostatnia.

Dobrze wdrożony ERP nie jest wyłącznie programem. Jest uporządkowanym modelem działania firmy, w którym wiadomo, skąd pochodzą dane, kto może je zmieniać i jak przepływają pomiędzy kolejnymi procesami.

Co to jest system ERP?

ERP to skrót od angielskiego określenia Enterprise Resource Planning, czyli planowania zasobów przedsiębiorstwa.

System ERP pomaga zarządzać kluczowymi procesami firmy w jednym środowisku albo w zestawie ściśle powiązanych modułów.

Może obsługiwać między innymi:

• sprzedaż,
• zakupy,
• magazyn,
• produkty,
• kontrahentów,
• zamówienia,
• dokumenty handlowe,
• finanse,
• księgowość,
• produkcję,
• projekty,
• pracowników,
• raportowanie.

Nie każdy system ERP posiada wszystkie te funkcje.

Zakres zależy od konkretnego rozwiązania, branży, wybranych modułów i sposobu wdrożenia.

Czy ERP jest tylko programem do faktur?

Nie.

Program do faktur może umożliwiać:

• wystawianie dokumentów sprzedaży,
• zapisywanie danych klientów,
• kontrolę płatności,
• podstawowe raportowanie.

ERP może łączyć dokument sprzedaży z:

• zamówieniem klienta,
• wydaniem magazynowym,
• rezerwacją produktów,
• płatnością,
• zakupem od dostawcy,
• kosztem,
• księgowością,
• raportem rentowności.

Faktura jest wtedy jednym z elementów większego procesu.

Czy ERP jest systemem magazynowym?

ERP może zawierać moduł magazynowy, ale nie każdy system magazynowy jest pełnym ERP.

System magazynowy może koncentrować się na:

• stanach produktów,
• lokalizacjach,
• przyjęciach,
• wydaniach,
• rezerwacjach,
• inwentaryzacji.

ERP może dodatkowo powiązać te operacje ze sprzedażą, zakupami, płatnościami, dokumentami i księgowością.

Jakie problemy rozwiązuje ERP?

System ERP może ograniczyć problemy wynikające z rozproszenia danych.

Pomaga między innymi:

• unikać wielokrotnego wpisywania tych samych informacji,
• łączyć dokumenty z zamówieniami i magazynem,
• kontrolować stany i rezerwacje,
• porządkować dane kontrahentów,
• zarządzać zakupami,
• analizować koszty i przychody,
• przekazywać dane do księgowości,
• kontrolować przepływ towaru,
• raportować wyniki firmy.

ERP nie rozwiąże jednak automatycznie problemów takich jak:

• błędne SKU,
• nieuporządkowane warianty,
• brak odpowiedzialności za dane,
• niejasne statusy,
• niespójne procesy,
• brak kontroli błędów integracji.

Z jakich modułów może składać się ERP?

System może być podzielony na moduły odpowiadające różnym obszarom firmy.

Sprzedaż

Moduł sprzedaży może obsługiwać:

• oferty,
• zamówienia klientów,
• faktury,
• korekty,
• cenniki,
• rabaty,
• płatności,
• limity kredytowe.

Magazyn

Moduł magazynowy może odpowiadać za:

• stany,
• rezerwacje,
• przyjęcia,
• wydania,
• przesunięcia,
• inwentaryzację,
• partie i numery seryjne,
• lokalizacje.

Zakupy

Moduł zakupowy może obsługiwać:

• zamówienia do dostawców,
• oferty zakupowe,
• terminy dostaw,
• ceny zakupu,
• przyjęcia towaru,
• rozliczenia dostawców.

Finanse i księgowość

Zakres może obejmować:

• rozrachunki,
• księgowanie dokumentów,
• płatności,
• rejestry podatkowe,
• raporty finansowe,
• kontrolę należności i zobowiązań.

Produkcja

W firmach produkcyjnych ERP może wspierać:

• receptury,
• listy materiałowe,
• zlecenia produkcyjne,
• zużycie surowców,
• planowanie,
• kontrolę etapów,
• koszty wytworzenia.

CRM i obsługa klienta

Niektóre systemy posiadają własne funkcje CRM:

• kontakty,
• szanse sprzedażowe,
• zadania,
• historię rozmów,
• oferty,
• opiekunów klientów.

Czy wszystkie moduły muszą działać w jednym systemie?

Nie.

Firma może korzystać z osobnych specjalistycznych narzędzi.

Przykładowo:

• ERP zarządza produktami, cenami, stanami i dokumentami,
• WooCommerce odpowiada za sprzedaż internetową,
• BaseLinker centralizuje kanały sprzedaży,
• CRM zarządza procesem handlowym,
• system kurierski obsługuje przesyłki,
• platforma marketingowa prowadzi komunikację.

Kluczowe jest ustalenie odpowiedzialności każdego systemu.

Nie wszystkie funkcje trzeba przenosić do ERP tylko dlatego, że posiada odpowiedni moduł.

Czym jest źródło prawdy?

Źródło prawdy jest nadrzędnym systemem odpowiedzialnym za określony rodzaj danych.

Przykładowo:

• ERP może być źródłem cen,
• ERP może być źródłem stanów,
• WooCommerce może być źródłem opisów marketingowych,
• PIM może być źródłem zdjęć i parametrów,
• CRM może być źródłem etapu sprzedaży,
• operator płatności może być źródłem statusu transakcji.

Źródło prawdy nie oznacza, że dana wartość występuje tylko w jednym systemie.

Może być kopiowana do sklepu, BaseLinkera i katalogu reklamowego, ale tylko jeden system powinien posiadać prawo nadrzędnego ustalania jej wartości.

Dlaczego kilka źródeł prawdy powoduje problemy?

Jeżeli sklep, BaseLinker i ERP mogą równocześnie zmieniać cenę, powstaje konflikt.

Proces może wyglądać następująco:

1. Pracownik zmienia cenę w WooCommerce.
2. Sklep przesyła nową wartość do BaseLinkera.
3. ERP wysyła starą cenę do BaseLinkera.
4. BaseLinker aktualizuje sklep wartością z ERP.
5. Ręczna zmiana znika.

Systemy działają technicznie poprawnie, ale brakuje jasnego kierunku danych.

ERP jako źródło produktów

ERP może być miejscem, w którym powstają podstawowe dane towarów.

Może przechowywać:

• kod produktu,
• nazwę handlową,
• jednostkę miary,
• stawki podatku,
• ceny,
• stany,
• producenta,
• numery katalogowe,
• parametry logistyczne.

Nie zawsze jest jednak dobrym miejscem do zarządzania pełnym opisem marketingowym sklepu.

Treści takie jak:

• rozbudowany opis,
• sekcje wizualne,
• SEO,
• galeria,
• materiały wideo,
• powiązane produkty,

mogą pozostać w WooCommerce albo w systemie PIM.

ERP jako źródło cen

ERP może przechowywać kilka rodzajów cen:

• cenę detaliczną,
• cenę hurtową,
• cenę netto,
• cenę brutto,
• cenę zakupu,
• cenę promocyjną,
• cenę dla grupy klienta,
• cenę w obcej walucie.

Integracja musi dokładnie wiedzieć, którą wartość przekazać do sklepu.

Nazwa „cena hurtowa” nie wystarcza, jeżeli nie wiadomo:

• czy jest netto czy brutto,
• w jakiej walucie została zapisana,
• czy zawiera rabat,
• dla jakiej grupy obowiązuje,
• czy jest aktualna.

ERP jako źródło stanów

Stan magazynowy może być przedstawiany na kilka sposobów.

ERP może zwracać:

• stan fizyczny,
• stan dostępny,
• stan po rezerwacjach,
• stan w drodze,
• stan z kilku magazynów,
• stan handlowy,
• stan pomniejszony o bufor.

Sklep powinien otrzymywać wartość odpowiadającą rzeczywistej możliwości sprzedaży.

Nie zawsze będzie to liczba znajdująca się fizycznie na półce.

Stan fizyczny a stan dostępny

Jeżeli magazyn posiada 20 sztuk, ale 7 zostało zarezerwowanych dla innych zamówień, do sprzedaży może pozostać 13.

Dodatkowo firma może pozostawić bufor bezpieczeństwa, na przykład 2 sztuki.

Do sklepu powinno wtedy trafić 11 sztuk, a nie 20.

Integracja musi znać regułę wyliczania dostępności.

Rezerwacje magazynowe

Rezerwacja zmniejsza ilość dostępną do dalszej sprzedaży bez fizycznego wydania produktu.

Może powstać po:

• utworzeniu zamówienia,
• potwierdzeniu płatności,
• przyjęciu zamówienia do realizacji,
• ręcznej decyzji pracownika.

Trzeba ustalić również moment zwolnienia rezerwacji.

Może nastąpić po:

• anulowaniu,
• wygaśnięciu płatności,
• odrzuceniu zamówienia,
• wydaniu produktu,
• ręcznej zmianie statusu.

ERP a WooCommerce

Integracja ERP z WooCommerce może obejmować:

• produkty,
• ceny,
• stany,
• zamówienia,
• klientów,
• statusy,
• numery dokumentów,
• faktury,
• informacje o wysyłce.

Nie każda integracja musi synchronizować wszystkie dane.

Dobrym modelem może być:

• ERP przekazuje stany i ceny,
• WooCommerce zachowuje opisy i zdjęcia,
• zamówienia trafiają ze sklepu do ERP,
• ERP odsyła numer dokumentu i status realizacji.

Jak zamówienie trafia do ERP?

Proces może wyglądać następująco:

1. Klient składa zamówienie w WooCommerce.
2. Sklep zapisuje dane i nadaje wewnętrzne ID.
3. Integracja sprawdza warunki przekazania.
4. Zamówienie trafia do ERP.
5. ERP rozpoznaje produkty i klienta.
6. ERP tworzy własny dokument lub zamówienie.
7. Zwraca identyfikator.
8. Sklep zapisuje powiązanie.

Nie zawsze zamówienie powinno być wysyłane natychmiast po utworzeniu.

Może być wymagane:

• potwierdzenie płatności,
• kontrola danych,
• akceptacja zamówienia B2B,
• weryfikacja dostępności,
• wybór właściwego magazynu.

Identyfikatory zamówień

Jedno zamówienie może posiadać kilka identyfikatorów:

• ID WooCommerce,
• numer widoczny dla klienta,
• ID BaseLinkera,
• numer zamówienia ERP,
• numer dokumentu handlowego,
• identyfikator płatności,
• numer przesyłki.

Integracja powinna przechowywać powiązania pomiędzy tymi wartościami.

Nie należy zakładać, że numer z jednego systemu będzie automatycznie używany w każdym pozostałym.

Jak ERP rozpoznaje produkty z zamówienia?

Najczęściej wykorzystywany jest stabilny identyfikator, na przykład:

• SKU,
• kod towaru,
• ID ERP zapisane w sklepie,
• EAN,
• inne mapowanie techniczne.

Łączenie produktów wyłącznie po nazwie jest ryzykowne.

Nazwa może:

• zostać zmieniona,
• różnić się pomiędzy systemami,
• zawierać wariant,
• nie być unikalna,
• posiadać dodatkowe informacje marketingowe.

SKU w integracji ERP

SKU powinno być:

• unikalne,
• stabilne,
• przypisane do właściwego produktu,
• zgodne w systemach,
• oddzielne dla wariantów, jeśli są magazynowane osobno.

Przed integracją warto sprawdzić:

• produkty bez SKU,
• duplikaty,
• spacje,
• różnice wielkości liter,
• zmienione kody,
• produkty archiwalne,
• kody wariantów.

Produkty wariantowe w ERP

W WooCommerce produkt może posiadać warianty rozmiaru, koloru lub pojemności.

ERP może przechowywać każdy wariant jako oddzielny towar.

Każdy wariant może posiadać własne:

• SKU,
• EAN,
• cenę,
• stan,
• wagę,
• kod producenta.

Integracja musi połączyć konkretny wariant WooCommerce z konkretną kartą towaru w ERP.

Powiązanie wyłącznie produktu głównego nie wystarczy, jeżeli stany są prowadzone osobno.

Najczęstsze problemy wariantów

Problemy pojawiają się, gdy:

• wszystkie warianty posiadają jedno SKU,
• ERP nie rozróżnia atrybutów,
• kolory mają inne nazwy w systemach,
• produkt główny jest traktowany jako towar magazynowy,
• warianty powstają w innym momencie niż produkt w ERP,
• kod wariantu zostaje zmieniony.

Zestawy produktów

Zestaw może być sprzedawany jako jeden produkt, ale składać się z kilku pozycji magazynowych.

Przykładowo zestaw zawiera:

• urządzenie,
• akcesorium,
• opakowanie,
• materiał eksploatacyjny.

ERP może rozłożyć zestaw na składniki i zmniejszyć stan każdego elementu.

Integracja musi ustalić:

• czy zestaw istnieje jako osobny towar,
• czy jest kompletem,
• jak wyliczać jego dostępność,
• jak obsługiwać zwrot,
• jak wyceniać składniki,
• co przekazać na dokument.

ERP a BaseLinker

BaseLinker może pełnić rolę pośrednika pomiędzy ERP i kanałami sprzedaży.

Przykładowy przepływ może wyglądać następująco:

• ERP przekazuje ceny i stany do BaseLinkera,
• BaseLinker aktualizuje sklepy i marketplace’y,
• zamówienia z kanałów trafiają do BaseLinkera,
• BaseLinker przekazuje je do ERP,
• ERP odsyła status i numery dokumentów.

Trzeba jednak ustalić, czy WooCommerce komunikuje się z ERP bezpośrednio, czy wyłącznie przez BaseLinker.

Dwie równoległe drogi mogą powodować:

• podwójne zamówienia,
• powtórne aktualizacje,
• konflikty statusów,
• trudności w diagnozowaniu błędów.

ERP a CRM

CRM i ERP odpowiadają za inne części procesu.

CRM może przechowywać:

• leady,
• szanse sprzedażowe,
• zadania,
• historię rozmów,
• planowane działania.

ERP może przechowywać:

• zamówienia,
• produkty,
• stany,
• dokumenty,
• płatności,
• rozrachunki.

Połączenie może przekazywać:

• klienta po wygranej sprzedaży,
• zamówienie,
• wartość transakcji,
• numer dokumentu,
• status płatności,
• historię sprzedaży.

ERP a PIM

PIM służy do zarządzania informacjami produktowymi.

Może przechowywać:

• rozbudowane opisy,
• parametry,
• tłumaczenia,
• zdjęcia,
• dane dla różnych kanałów,
• klasyfikacje.

ERP może pozostać źródłem:

• SKU,
• cen,
• stanów,
• jednostek,
• danych logistycznych.

PIM może odpowiadać za prezentację i kompletność danych marketingowych.

ERP a księgowość

Niektóre systemy ERP posiadają pełną księgowość. Inne przekazują dokumenty do osobnego programu.

Integracja może obejmować:

• faktury,
• korekty,
• płatności,
• kontrahentów,
• rejestry,
• rozrachunki.

Trzeba ustalić:

• który system nadaje numer dokumentu,
• kiedy faktura staje się ostateczna,
• jak obsługiwać korekty,
• jak rozliczać płatności,
• jak zachować zgodność danych.

Dokumenty handlowe w ERP

System może tworzyć:

• oferty,
• zamówienia sprzedaży,
• faktury,
• paragony,
• korekty,
• wydania magazynowe,
• przyjęcia,
• zamówienia zakupu.

Każdy dokument może posiadać własny numer i relację z pozostałymi elementami procesu.

Zamówienie internetowe nie zawsze powinno od razu tworzyć fakturę.

Może najpierw utworzyć zamówienie sprzedaży, rezerwację albo dokument roboczy.

Numer dokumentu a numer zamówienia

Numer zamówienia klienta i numer faktury pełnią inne funkcje.

Integracja powinna zachować oba.

Klient może kontaktować się, podając numer zamówienia ze sklepu, podczas gdy księgowość pracuje na numerze dokumentu ERP.

Powiązanie powinno być widoczne dla obsługi.

Statusy zamówień

WooCommerce, BaseLinker i ERP mogą używać innych statusów.

Sklep może posiadać:

• oczekujące na płatność,
• w trakcie realizacji,
• wstrzymane,
• zrealizowane,
• anulowane,
• zwrócone.

ERP może używać statusów:

• nowe,
• potwierdzone,
• zarezerwowane,
• w realizacji,
• wydane,
• zamknięte.

Mapowanie powinno określać:

• który status odpowiada któremu,
• który system może zmieniać status,
• kiedy zmiana jest wysyłana,
• co zrobić z niestandardowym etapem,
• jak obsługiwać cofnięcie.

Dlaczego mapowanie statusów bywa trudne?

Statusy nie zawsze posiadają bezpośrednie odpowiedniki.

Status „zrealizowane” w WooCommerce może oznaczać, że zamówienie zostało zakończone.

W ERP mogą istnieć oddzielne etapy:

• towar przygotowany,
• wydany z magazynu,
• faktura wystawiona,
• płatność rozliczona,
• proces zamknięty.

Jednego statusu sklepu nie należy mapować przypadkowo na pierwszy podobnie brzmiący etap.

Synchronizacja jednokierunkowa

W synchronizacji jednokierunkowej dane płyną w określonym kierunku.

Przykładowo:

• ERP wysyła ceny do sklepu,
• ERP wysyła stany do sklepu,
• sklep wysyła zamówienia do ERP.

Każdy rodzaj danych posiada własny, jasny kierunek.

Taki model jest zwykle łatwiejszy do utrzymania.

Synchronizacja dwukierunkowa

Synchronizacja dwukierunkowa pozwala obu systemom zmieniać dane.

Może być potrzebna, gdy pracownicy pracują równocześnie w ERP i sklepie.

Wymaga jednak obsługi:

• konfliktów,
• kolejności,
• czasu zmian,
• pętli synchronizacji,
• równoczesnej edycji,
• priorytetów.

Nie wdrażam synchronizacji dwukierunkowej tylko dlatego, że brzmi bardziej kompleksowo.

Najpierw sprawdzam, czy firma rzeczywiście potrzebuje zmieniać te same dane w obu miejscach.

Synchronizacja pełna

Pełna synchronizacja przetwarza cały katalog albo kompletny zestaw danych.

Może być używana:

• przy pierwszym uruchomieniu,
• po zmianie mapowania,
• po awarii,
• podczas kontroli zgodności,
• przy odbudowie integracji.

Przy dużym katalogu może być kosztowna i długotrwała.

Synchronizacja przyrostowa

Synchronizacja przyrostowa obejmuje tylko dane zmienione od ostatniego poprawnego wykonania.

Może przetwarzać:

• nowe produkty,
• zmienione ceny,
• zmienione stany,
• nowe zamówienia,
• zaktualizowanych klientów.

Wymaga prawidłowej obsługi:

• dat modyfikacji,
• stref czasowych,
• usuniętych rekordów,
• nieudanych fragmentów,
• momentu ostatniego sukcesu.

Integracja przez API

API umożliwia programistyczne pobieranie i modyfikowanie danych ERP.

Może pozwalać na:

• pobieranie produktów,
• aktualizowanie stanów,
• tworzenie zamówień,
• pobieranie dokumentów,
• tworzenie kontrahentów,
• sprawdzanie płatności.

Integracja API powinna obsługiwać:

• uwierzytelnianie,
• limity,
• paginację,
• błędy,
• ponowienia,
• duplikaty,
• wersje API.

Integracja przez pliki

Nie każdy ERP posiada odpowiednie API.

Dane mogą być wymieniane przez:

• CSV,
• XML,
• arkusze,
• pliki tekstowe,
• katalogi wymiany,
• serwer FTP.

Import plikowy może być wystarczający, gdy:

• dane nie muszą zmieniać się natychmiast,
• proces działa cyklicznie,
• format jest stabilny,
• liczba operacji jest umiarkowana.

Dobry automatyczny plik może być bardziej niezawodny niż źle przygotowane API.

Integracja bezpośrednio z bazą danych

Niektóre integracje odczytują dane bezpośrednio z bazy ERP.

Może to być potrzebne, gdy system nie udostępnia wymaganych funkcji.

Takie rozwiązanie wymaga szczególnej ostrożności.

Bezpośredni zapis może ominąć:

• reguły biznesowe,
• walidację,
• historię zmian,
• rezerwacje,
• automatyczne dokumenty,
• kontrolę uprawnień.

Odczyt raportowy i kontrolowany zapis to dwa zupełnie różne poziomy ryzyka.

Webhooki w integracji ERP

ERP może informować inne systemy o zmianach przez webhook.

Zdarzenie może dotyczyć:

• zmiany stanu,
• nowego dokumentu,
• zmiany statusu,
• utworzenia produktu,
• rozliczenia płatności.

Webhook może uruchomić dalszą automatyzację albo pobranie aktualnych danych przez API.

Odbiorca powinien obsługiwać:

• podpisy,
• duplikaty,
• ponowienia,
• opóźnienia,
• nieprawidłową kolejność.

Kolejki w integracji ERP

Zamówienia i aktualizacje nie powinny znikać, gdy ERP chwilowo nie odpowiada.

Kolejka może przechowywać:

• zamówienia oczekujące na wysłanie,
• aktualizacje produktów,
• zmiany cen,
• zmiany stanów,
• dokumenty do pobrania.

Każde zadanie powinno posiadać:

• status,
• liczbę prób,
• czas utworzenia,
• powiązany rekord,
• ostatni błąd,
• możliwość ponowienia.

Dlaczego integracja nie powinna blokować checkoutu?

Jeżeli sklep próbuje wysłać zamówienie do ERP podczas finalizowania zakupu, awaria ERP może zablokować klientowi złożenie zamówienia.

Bezpieczniejszy model może wyglądać następująco:

1. Sklep zapisuje zamówienie lokalnie.
2. Klient otrzymuje potwierdzenie.
3. System dodaje zadanie do kolejki.
4. Zadanie przekazuje zamówienie do ERP w tle.
5. W przypadku błędu następuje ponowienie.
6. Administrator otrzymuje alert po przekroczeniu limitu.

Wyjątkiem są sytuacje, w których odpowiedź ERP jest bezwzględnie potrzebna przed zakończeniem procesu.

Idempotencja w ERP

Jedno zamówienie nie powinno zostać utworzone w ERP kilka razy.

Integracja może ponowić żądanie, gdy:

• przerwano połączenie,
• ERP nie odpowiedział w czasie,
• zadanie zostało ręcznie uruchomione ponownie,
• webhook dotarł kilka razy.

System powinien rozpoznać, że operacja została już wykonana.

Może wykorzystywać:

• unikalny numer zamówienia źródłowego,
• klucz idempotencji,
• zapisane ID ERP,
• tabelę powiązań,
• znacznik wcześniejszego przetworzenia.

Błędy techniczne i biznesowe

Błąd techniczny może oznaczać:

• brak połączenia,
• timeout,
• awarię serwera,
• przekroczenie limitu,
• wygaśnięcie tokenu.

Taki błąd może kwalifikować się do ponowienia.

Błąd biznesowy może oznaczać:

• brak produktu,
• nieprawidłowe SKU,
• brak kontrahenta,
• niezgodną stawkę podatku,
• niedozwolony status,
• brak wymaganej wartości.

Wielokrotne ponawianie nie naprawi danych.

Zadanie powinno trafić do osoby odpowiedzialnej za ich poprawę.

Mapowanie danych

Mapowanie określa, które pole WooCommerce odpowiada polu ERP.

Przykładowo:

• SKU odpowiada kodowi towaru,
• billing_first_name odpowiada imieniu kontrahenta,
• billing_company odpowiada nazwie firmy,
• numer zamówienia odpowiada numerowi zewnętrznemu,
• status processing odpowiada etapowi przyjęte do realizacji.

Mapowanie może wymagać:

• łączenia pól,
• zmiany formatu,
• przeliczania wartości,
• tłumaczenia statusów,
• uzupełnienia wartości domyślnej,
• użycia słownika.

Słowniki danych

Dwa systemy mogą inaczej zapisywać tę samą informację.

Przykładowo:

• PL odpowiada Polska,
• pcs odpowiada szt.,
• processing odpowiada realizacja,
• bank_transfer odpowiada przelew,
• black odpowiada czarny.

Słownik powinien być dokumentowany i kontrolowany.

Nieznana wartość nie powinna być zastępowana losowym odpowiednikiem.

Jednostki miary

ERP może przechowywać produkty w różnych jednostkach:

• sztukach,
• metrach,
• kilogramach,
• litrach,
• opakowaniach,
• zestawach.

Sklep może sprzedawać produkt w innej jednostce niż magazyn.

Przykładowo magazyn prowadzi towar w opakowaniach po 10 sztuk, a sklep sprzedaje pojedyncze sztuki.

Integracja musi znać przelicznik i zasady zaokrąglania.

Podatki i ceny netto oraz brutto

Integracja musi rozróżniać:

• cenę netto,
• cenę brutto,
• stawkę podatku,
• kraj sprzedaży,
• rodzaj klienta,
• walutę.

Przesłanie ceny netto jako brutto może spowodować poważną rozbieżność pomiędzy sklepem, dokumentem i płatnością.

Nie należy zakładać rodzaju ceny wyłącznie na podstawie nazwy pola.

Kontrahenci w ERP

ERP może tworzyć kontrahenta na podstawie danych zamówienia.

Trzeba ustalić, jak rozpoznawać istniejącego klienta.

Możliwe identyfikatory to:

• ID klienta,
• numer kontrahenta,
• adres e-mail,
• numer podatkowy,
• powiązanie zapisane w sklepie.

Łączenie wyłącznie po nazwie firmy jest ryzykowne.

Firmy mogą posiadać podobne nazwy, różne oddziały albo zmieniać dane.

Klient detaliczny a kontrahent jednorazowy

Nie każdy zakup detaliczny musi tworzyć osobną kartę kontrahenta w ERP.

Firma może wykorzystywać:

• jednego kontrahenta zbiorczego,
• osobne karty tylko dla klientów B2B,
• osobne karty dla każdego zamówienia,
• model zależny od dokumentu.

Decyzja wpływa na:

• liczbę rekordów,
• historię klienta,
• rozrachunki,
• raportowanie,
• obsługę faktur.

ERP a sprzedaż B2B

W sprzedaży B2B system może obsługiwać:

• indywidualne cenniki,
• rabaty,
• limity kredytowe,
• terminy płatności,
• opiekunów,
• zamówienia cykliczne,
• warunki dostawy,
• rezerwacje.

Sklep B2B powinien pobierać właściwe warunki dla konkretnego klienta.

Nie wystarczy przekazać jednego ogólnego cennika detalicznego.

ERP a marketplace

ERP może zasilać marketplace bezpośrednio albo przez BaseLinker.

Proces może obejmować:

• stany,
• ceny,
• zamówienia,
• dokumenty,
• statusy,
• zwroty.

Marketplace posiada jednak własne identyfikatory ofert, kategorie i statusy.

ERP zwykle nie powinien być jedynym miejscem odpowiedzialnym za całą warstwę prezentacji ofert.

ERP a feed produktowy

Feed może pobierać dane pochodzące z ERP, takie jak:

• cena,
• stan,
• SKU,
• EAN,
• marka,
• dane logistyczne.

Opis, zdjęcia i tytuły mogą pochodzić z WooCommerce albo PIM.

Generator feedu powinien łączyć dane z właściwych źródeł bez tworzenia rozbieżności.

ERP a automatyzacja zakupów

System może pomagać planować zakupy na podstawie:

• stanów minimalnych,
• rezerwacji,
• sprzedaży,
• zamówień klientów,
• terminów dostaw,
• historii zapotrzebowania.

Może sugerować zamówienie do dostawcy albo utworzyć dokument roboczy.

Automatyczne zakupy wymagają szczególnej kontroli, ponieważ błędna reguła może zamówić zbyt dużo towaru.

ERP a produkcja

W firmie produkcyjnej zamówienie klienta może uruchamiać:

• zlecenie produkcyjne,
• rezerwację materiałów,
• kontrolę dostępności surowców,
• planowanie terminu,
• zamówienie brakujących komponentów.

Integracja sklepu powinna rozumieć, czy produkt jest:

• gotowy na magazynie,
• produkowany na zamówienie,
• konfigurowany,
• składany z komponentów,
• dostępny po określonym terminie.

Raportowanie w ERP

System może analizować:

• sprzedaż,
• marżę,
• koszty,
• stany,
• rotację produktów,
• należności,
• zobowiązania,
• rentowność klientów,
• wyniki kanałów.

Raport jest wiarygodny tylko wtedy, gdy dane źródłowe są kompletne.

Jeżeli część zamówień nie trafia do ERP, analiza sprzedaży będzie zaniżona.

Jeżeli ceny zakupu są nieaktualne, raport marży może być błędny.

Marża a narzut

ERP może obliczać rentowność produktów, ale trzeba rozumieć używaną metodę.

Marża i narzut nie są tym samym.

System może uwzględniać:

• cenę sprzedaży,
• cenę zakupu,
• koszt dostawy,
• prowizję marketplace,
• koszt płatności,
• rabaty,
• koszt obsługi.

Sama różnica pomiędzy ceną sprzedaży a zakupu nie zawsze pokazuje rzeczywisty zysk.

Wdrożenie ERP

Wdrożenie nie polega wyłącznie na instalacji programu.

Obejmuje:

• analizę procesów,
• wybór modułów,
• konfigurację,
• przygotowanie danych,
• migrację,
• integracje,
• uprawnienia,
• testy,
• szkolenia,
• uruchomienie,
• utrzymanie.

Analiza przedwdrożeniowa

Przed wyborem systemu warto opisać:

• jak powstaje produkt,
• gdzie zmienia się cena,
• jak przyjmowany jest towar,
• jak powstaje zamówienie,
• kiedy rezerwowany jest stan,
• jak wystawiany jest dokument,
• jak obsługiwany jest zwrot,
• jakie raporty są potrzebne.

Analiza powinna obejmować również wyjątki, a nie tylko idealny scenariusz.

Migracja danych do ERP

Migracja może obejmować:

• produkty,
• stany,
• ceny,
• kontrahentów,
• dokumenty,
• rozrachunki,
• historię sprzedaży.

Przed importem trzeba sprawdzić:

• duplikaty,
• brakujące kody,
• nieprawidłowe formaty,
• nieaktualne rekordy,
• różne jednostki,
• niespójne stawki,
• brakujące powiązania.

Nie warto przenosić całego wieloletniego bałaganu tylko dlatego, że dane istnieją.

Testy integracji ERP

Test nie powinien obejmować wyłącznie jednego prostego zamówienia.

Sprawdzam:

• produkt prosty,
• produkt wariantowy,
• zestaw,
• promocję,
• kupon,
• zamówienie B2B,
• płatność online,
• pobranie,
• anulowanie,
• zwrot,
• brak produktu w ERP,
• awarię połączenia,
• powtórzenie tego samego zamówienia.

Środowisko testowe

Integracja powinna być sprawdzana bez tworzenia rzeczywistych dokumentów i rozrachunków.

Warto posiadać osobne:

• bazy testowe,
• klucze API,
• magazyny,
• serie dokumentów,
• konta użytkowników,
• endpointy.

Po zakończeniu testów wykonuję również kontrolowany test produkcyjny.

Uruchomienie etapowe

Nie zawsze warto od razu uruchamiać pełną synchronizację dla całej firmy.

Można rozpocząć od:

• jednego magazynu,
• wybranej kategorii produktów,
• jednego kanału sprzedaży,
• samego odczytu danych,
• ograniczonej grupy zamówień.

Po potwierdzeniu poprawności zakres można rozszerzyć.

Monitoring integracji

Integracja może przestać działać po zmianie:

• API,
• hasła,
• certyfikatu,
• adresu serwera,
• pola w ERP,
• statusu,
• wersji systemu.

Monitoring powinien kontrolować:

• czas ostatniej synchronizacji,
• liczbę przetworzonych rekordów,
• liczbę błędów,
• kolejkę,
• różnice stanów,
• zamówienia bez ID ERP,
• nieznane produkty,
• czas odpowiedzi.

Brak danych jako sygnał błędu

Nie tylko komunikat błędu powinien uruchamiać alert.

Jeżeli zwykle do ERP trafia sto zamówień dziennie, a nagle nie trafia żadne, może to oznaczać:

• awarię webhooka,
• problem z kolejką,
• wygaśnięcie dostępu,
• zmianę statusu wyzwalającego,
• problem po stronie sklepu.

Logi integracji

Log powinien pomagać ustalić:

• co zostało wysłane,
• kiedy,
• jakiego rekordu dotyczyło,
• jaka była odpowiedź,
• ile razy wykonano próbę,
• dlaczego operacja się nie udała.

Nie powinien bez potrzeby przechowywać:

• haseł,
• pełnych tokenów,
• nadmiarowych danych osobowych,
• danych kart,
• sekretów integracji.

Bezpieczeństwo ERP

ERP może zawierać krytyczne dane firmy.

Podstawowe zabezpieczenia obejmują:

• indywidualne konta,
• silne hasła,
• uwierzytelnianie wieloskładnikowe,
• ograniczone uprawnienia,
• kontrolę logowań,
• kopie zapasowe,
• aktualizacje,
• szyfrowanie komunikacji,
• monitoring zmian.

Nie każdy pracownik potrzebuje dostępu do cen zakupu, księgowości, integracji i eksportu całej bazy.

Uprawnienia użytkowników

Zakres dostępu powinien wynikać z obowiązków.

Pracownik magazynu może potrzebować:

• produktów,
• stanów,
• przyjęć,
• wydań,
• zamówień do realizacji.

Nie musi mieć dostępu do:

• pełnych danych finansowych,
• kluczy API,
• konfiguracji systemu,
• eksportu kontrahentów,
• edycji cenników.

Kopie zapasowe ERP

Kopia powinna obejmować:

• bazę danych,
• dokumenty,
• załączniki,
• konfigurację,
• integracje,
• klucze i ustawienia potrzebne do odtworzenia.

Samo wykonywanie backupu nie wystarcza.

Trzeba okresowo sprawdzać możliwość odtworzenia systemu.

ERP w chmurze i na własnym serwerze

ERP chmurowy jest utrzymywany przez dostawcę i dostępny przez internet.

Może oferować:

• szybsze uruchomienie,
• aktualizacje,
• skalowanie,
• dostęp z różnych lokalizacji,
• mniejszą odpowiedzialność za infrastrukturę.

ERP instalowany na własnym serwerze może dawać większą kontrolę, ale wymaga:

• administracji,
• aktualizacji,
• kopii zapasowych,
• monitoringu,
• zabezpieczeń,
• planowania wydajności.

Wybór zależy od branży, integracji, wymagań prawnych, kosztów i kompetencji technicznych.

ERP gotowy czy dedykowany?

Gotowy system posiada sprawdzone moduły i standardowe procesy.

Może być rozszerzany przez:

• konfigurację,
• dodatki,
• API,
• integracje,
• własne raporty.

Dedykowany system może mieć sens, gdy firma posiada bardzo nietypowy proces, którego gotowe rozwiązania nie obsługują.

Trzeba jednak uwzględnić:

• koszt projektu,
• programowanie,
• testy,
• utrzymanie,
• bezpieczeństwo,
• dokumentację,
• zależność od wykonawcy,
• dalszy rozwój.

Nie buduję dedykowanego ERP tylko dlatego, że technicznie jest to możliwe. Najpierw sprawdzam, czy gotowy system można prawidłowo skonfigurować i zintegrować.

Jak wybrać system ERP?

Wybór powinien wynikać z procesów firmy.

Warto sprawdzić:

• obsługiwane moduły,
• skalę danych,
• liczbę użytkowników,
• branżę,
• magazyny,
• produkcję,
• księgowość,
• API,
• możliwości integracji,
• uprawnienia,
• raporty,
• koszt wdrożenia,
• koszt utrzymania,
• możliwość eksportu danych.

System z największą liczbą funkcji nie zawsze będzie najlepszy.

Znaczenie ma to, czy pracownicy potrafią go używać i czy wspiera rzeczywisty proces.

Dlaczego wdrożenia ERP się nie udają?

Najczęstsze przyczyny to:

• brak analizy procesów,
• nieuporządkowane dane,
• zbyt duży zakres wdrożony jednocześnie,
• brak właściciela projektu,
• niedostateczne testy,
• brak zaangażowania użytkowników,
• niejasne wymagania,
• brak dokumentacji,
• próba odwzorowania każdego starego nawyku.

Nowy system nie powinien być wyłącznie cyfrową kopią wszystkich dotychczasowych problemów.

Najczęstsze błędy w integracjach ERP

Brak źródła prawdy

Kilka systemów równocześnie zarządza cenami, stanami lub statusami.

Łączenie produktów po nazwie

Zmiana tytułu powoduje utratę powiązania.

Duplikaty SKU

Różne produkty są traktowane jako jedna pozycja.

Brak SKU wariantów

ERP nie potrafi rozpoznać konkretnego rozmiaru albo koloru.

Brak idempotencji

Ponowienie tworzy kolejne zamówienie lub dokument.

Dwie równoległe integracje

WooCommerce i BaseLinker niezależnie wysyłają to samo zamówienie do ERP.

Nieprawidłowa cena

System przesyła wartość netto zamiast brutto albo niewłaściwy cennik.

Nieprawidłowy stan

Sklep otrzymuje stan fizyczny bez uwzględnienia rezerwacji.

Błędne jednostki

Jedno opakowanie jest traktowane jak jedna sztuka.

Niejasne mapowanie statusów

Zamówienie zostaje zakończone przed wydaniem towaru.

Brak obsługi anulowania

Rezerwacja pozostaje aktywna po anulowaniu zamówienia.

Brak obsługi zwrotu

Produkt wraca do magazynu, ale stan nie zostaje poprawiony.

Synchronizacja blokująca sklep

Awaria ERP uniemożliwia klientowi złożenie zamówienia.

Brak kolejki

Chwilowy błąd powoduje utratę danych.

Nieograniczone ponawianie

Wadliwe zadanie jest wykonywane bez końca.

Brak monitoringu

Zamówienia nie trafiają do ERP przez kilka dni.

Brak dokumentacji

Nikt nie wie, które pola i statusy są ze sobą połączone.

Zbyt szerokie uprawnienia

Integracja posiada dostęp do funkcji, których nie potrzebuje.

Jak samodzielnie ocenić integrację ERP?

Podstawową kontrolę można rozpocząć od odpowiedzi na kilka pytań:

1. Który system jest źródłem produktów?
2. Który system jest źródłem cen?
3. Który system jest źródłem stanów?
4. Jak rozpoznawane są produkty?
5. Czy SKU są unikalne?
6. Czy warianty posiadają osobne kody?
7. Jak wyliczany jest stan dostępny?
8. Kiedy powstaje rezerwacja?
9. Kiedy rezerwacja jest zwalniana?
10. Kiedy zamówienie trafia do ERP?
11. Jak zapobiega się duplikatom?
12. Jak mapowane są statusy?
13. Który system tworzy dokument?
14. Jak obsługiwane są anulowania i zwroty?
15. Czy integracja działa przez kolejkę?
16. Co dzieje się podczas awarii ERP?
17. Gdzie widoczne są błędy?
18. Kto otrzymuje alert?
19. Czy istnieje dokumentacja mapowania?
20. Kiedy ostatnio testowano cały proces?

Jak wygląda prawidłowe wdrożenie ERP?

1. Opisuję procesy firmy – ustalam, jak działają sprzedaż, zakupy, magazyn, dokumenty i płatności.
2. Wskazuję problemy – identyfikuję ręczne przepisywanie, rozbieżności i miejsca utraty danych.
3. Określam źródła prawdy – przypisuję odpowiedzialność za produkty, ceny, stany, klientów i statusy.
4. Porządkuję identyfikatory – sprawdzam SKU, EAN, warianty i numery dokumentów.
5. Wybieram moduły – wdrażam tylko funkcje potrzebne do rzeczywistych procesów.
6. Projektuję mapowanie – łączę pola, statusy, jednostki, stawki i słowniki.
7. Przygotowuję dane – usuwam duplikaty, błędne wartości i nieaktualne rekordy.
8. Projektuję integracje – ustalam kierunki, harmonogramy, API, pliki i webhooki.
9. Dodaję kolejki – zabezpieczam proces przed chwilową niedostępnością systemów.
10. Wdrażam idempotencję – chronię zamówienia i dokumenty przed duplikacją.
11. Projektuję błędy – rozdzielam problemy chwilowe i wymagające poprawy danych.
12. Tworzę uprawnienia – ograniczam dostęp według obowiązków użytkowników.
13. Przygotowuję środowisko testowe – oddzielam testy od danych produkcyjnych.
14. Testuję scenariusze – sprawdzam produkty, warianty, płatności, zwroty i awarie.
15. Uruchamiam etapami – zaczynam od ograniczonego zakresu.
16. Wdrażam monitoring – kontroluję synchronizację, kolejki, stany i błędy.
17. Szkolę użytkowników – pokazuję rzeczywisty proces, a nie tylko funkcje programu.
18. Dokumentuję rozwiązanie – zapisuję mapowanie, kierunki i procedury awaryjne.
19. Wyznaczam właściciela systemu – wskazuję osobę odpowiedzialną za rozwój i jakość danych.
20. Regularnie przeglądam proces – dostosowuję ERP i integracje do zmian firmy.

Czy każda firma potrzebuje ERP?

Nie każda firma potrzebuje rozbudowanego systemu.

Mała działalność obsługująca niewielką liczbę zamówień może korzystać z:

• WooCommerce,
• prostego programu fakturowego,
• narzędzia magazynowego,
• dobrze przygotowanych automatyzacji.

ERP staje się szczególnie wartościowy, gdy:

• firma posiada wiele produktów,
• sprzedaje w kilku kanałach,
• zarządza magazynem,
• obsługuje dużą liczbę dokumentów,
• prowadzi zakupy lub produkcję,
• potrzebuje kontroli rozrachunków,
• dane są rozproszone,
• pracuje wiele osób i działów.

Nie wdrażam ERP wyłącznie dlatego, że firma przekroczyła określoną liczbę pracowników. Najpierw sprawdzam, czy obecne narzędzia rzeczywiście ograniczają rozwój, powodują błędy albo utrudniają kontrolę danych.

Najważniejsze wnioski

• ERP pomaga zarządzać kluczowymi procesami i zasobami firmy.
• Nie jest wyłącznie programem do faktur ani prostym magazynem.
• Może łączyć sprzedaż, zakupy, produkty, magazyn, dokumenty, finanse i produkcję.
• Nie każda firma potrzebuje wszystkich modułów.
• Dla każdego rodzaju danych trzeba wskazać jeden system nadrzędny.
• ERP może być źródłem cen, stanów, kodów i dokumentów.
• WooCommerce może pozostać źródłem treści marketingowych i prezentacji produktów.
• Stan fizyczny nie zawsze jest stanem dostępnym do sprzedaży.
• Rezerwacje i zapas bezpieczeństwa powinny wpływać na dostępność w sklepie.
• Produkty należy łączyć przez stabilne identyfikatory, a nie wyłącznie przez nazwy.
• Warianty wymagają osobnych SKU i powiązań, jeżeli są magazynowane oddzielnie.
• Zestawy wymagają określenia składników, dostępności i zasad rozchodowania.
• WooCommerce, BaseLinker i ERP powinny posiadać jasno określone kierunki komunikacji.
• Dwie równoległe integracje mogą powodować podwójne zamówienia i konflikty.
• Statusy wymagają świadomego mapowania pomiędzy systemami.
• Synchronizacja jednokierunkowa jest prostsza i często wystarczająca.
• Synchronizacja dwukierunkowa wymaga kontroli konfliktów i pętli.
• API, pliki i webhooki są różnymi sposobami wymiany danych.
• Kolejka zabezpiecza proces przed chwilową niedostępnością ERP.
• Idempotencja chroni przed wielokrotnym tworzeniem zamówień i dokumentów.
• Błędy techniczne można czasem ponawiać, ale błędy danych wymagają poprawy.
• Ceny netto, brutto, waluty i jednostki muszą być jednoznacznie mapowane.
• Integracja nie powinna blokować checkoutu, jeżeli odpowiedź ERP nie jest natychmiast potrzebna.
• Raporty ERP są wiarygodne tylko wtedy, gdy wszystkie dane trafiają do systemu poprawnie.
• Wdrożenie ERP obejmuje analizę, migrację, integracje, testy, szkolenia i utrzymanie.
• Monitoring powinien wykrywać zarówno błędy, jak i brak oczekiwanych danych.
• Każdy użytkownik i integracja powinny posiadać wyłącznie potrzebne uprawnienia.
• Najlepszy ERP nie jest systemem z największą liczbą funkcji, lecz rozwiązaniem porządkującym rzeczywiste procesy firmy.

Nie wiesz, jak połączyć ERP ze sklepem internetowym?

Podczas analizy sprawdzam nie tylko dostępność API. Rozpisuję źródła produktów, cen i stanów, sposób identyfikowania wariantów, przepływ zamówień, mapowanie statusów, dokumenty oraz zachowanie systemów podczas awarii.

Mogę wskazać sytuacje, w których WooCommerce, BaseLinker i ERP wzajemnie nadpisują dane, zamówienia powstają podwójnie albo sklep prezentuje stan bez uwzględnienia rezerwacji magazynowych.

Nie zakładam automatycznie, że potrzebna jest pełna synchronizacja wszystkich informacji. Najpierw ustalam odpowiedzialność systemów, a dopiero później projektuję integrację, kolejki, monitoring i bezpieczny sposób obsługi błędów.