3 systemy, zero komunikacji — jak połączyliśmy Comarch Optima, magazyn i zamówienia

Firma produkcyjna z branży spożywczej — 12 osób, własny magazyn, klienci hurtowi w całej Polsce. Trzy systemy, które każdego dnia opisywały tę samą rzeczywistość trzema różnymi językami. Po czterech miesiącach pracy zostały dwa, rozmawiające ze sobą po cichu w tle. Co tydzień zespół odzyskał dwanaście godzin, a liczba błędów spadła o 70%.

Kontekst: trzy systemy, każdy z innej epoki

Klient prowadzi produkcję wyrobów spożywczych pod marką własną i pod markami sieci handlowych. Zespół to dwunaście osób — trzech handlowców, biuro obsługi zamówień, kierownik magazynu, dział księgowy i produkcja. Współpracę zaczęliśmy w połowie 2025 roku, polecił nas zaprzyjaźniony dostawca opakowań, którego rok wcześniej wsparliśmy przy integracji.

Trafiliśmy na typowy układ, który widzimy w MŚP po kilkunastu latach na rynku: Comarch Optima jako główny ERP (faktury, magazyn księgowy, kartoteki), osobny system magazynowy (WMS pod kody kreskowe, kupiony pięć lat wcześniej pod konkretny przetarg) i arkusz Google Sheets, w którym biuro obsługi przyjmowało zamówienia od stałych klientów. Każdy z tych trzech systemów był poprawny w swoim świecie. Problem zaczynał się tam, gdzie świat jednego się kończył, a drugiego zaczynał — czyli przy każdym zamówieniu.

Punkt startowy: 12 godzin tygodniowo na ręczne przepisywanie

Codzienna procedura wyglądała tak: zamówienie spływało mailem albo telefonicznie, biuro wpisywało je do arkusza Google. Po południu dwie osoby przepisywały zamówienia z arkusza do Comarch Optima jako dokumenty rezerwacji. Drukowały listę, niosły do magazynu. Magazynier wprowadzał wydania do WMS. Po wydaniu szła informacja zwrotna do biura — mailem albo na karteczce — i ktoś wystawiał fakturę w Optimie. Stan magazynowy w Optimie aktualizował się dwa razy w tygodniu, kiedy ktoś znalazł chwilę.

Konsekwencje były przewidywalne. Zamówienia ginęły między arkuszem a Optimą — średnio dwa tygodniowo. Stan magazynu w Optimie nie zgadzał się z fizycznym stanem na półkach, więc handlowcy obiecywali klientom towar, którego nie było. Faktury wystawiane były z opóźnieniem, czasem na zły adres, bo dane klienta w arkuszu różniły się od danych w Optimie. Reklamacje rozwiązywało się wertując trzy systemy i mail-a archiwum.

Zmierzyliśmy to przed rozpoczęciem prac. Zespół tracił średnio 12 godzin tygodniowo na ręczne przepisywanie i prostowanie błędów. Liczba błędnych dokumentów (zła ilość, zły klient, zły indeks) wynosiła około 80 miesięcznie przy średnim wolumenie 1 200 zamówień.

Co rozważaliśmy i czego nie zrobiliśmy

Pierwszą myślą zarządu było „przejdziemy w całości na jeden system, najlepiej coś nowoczesnego". Sprawdziliśmy ten scenariusz: migracja z Optimy oznaczała trzy miesiące pracy księgowej, ryzyko utraty historii dokumentów (Comarch trzyma dane w specyficznym formacie) i kilkadziesiąt tysięcy złotych licencji nowego ERP, którego nikt w zespole nie znał. Odradziliśmy.

Drugą opcją było iPaaS w stylu Make (dawniej Integromat) albo Zapier. Działa to dobrze przy prostych przepływach, ale Comarch Optima nie ma natywnego konektora, a my potrzebowaliśmy synchronizacji w obie strony, z transakcyjnością — żeby zamówienie albo trafiło do Optimy w całości, albo wcale, bez stanów pośrednich. Make tego nie gwarantuje.

Wybraliśmy trzecią drogę: dedykowany middleware napisany w .NET, działający jako usługa Windows na serwerze klienta, łączący się z Optimą przez Comarch ERP XL/Optima API (BIS) oraz z WMS przez jego REST API. Arkusz Google podmieniliśmy na prosty formularz przyjmowania zamówień zintegrowany bezpośrednio z middlewarem.

Rozwiązanie: jak to działa technicznie

Architektura w jednym widoku:

Przepływ: zamówienie wchodzi przez formularz, middleware waliduje (kontrahent istnieje? indeksy aktywne? limit kredytowy nieprzekroczony?), tworzy dokument Rezerwacja Odbiorcy w Optimie i jednocześnie zlecenie wydania w WMS. Magazynier potwierdza wydanie skanerem, WMS wysyła komunikat do middleware, ten zamyka rezerwację w Optimie i wystawia fakturę.

Trzy decyzje techniczne, na które warto zwrócić uwagę:

• Kolejka i retry. Optima potrafi się „zaciąć" przy długich operacjach. Middleware nie woła API synchronicznie — wszystko leci przez kolejkę z retry i exponential backoff. Jeśli Optima nie odpowie, zamówienie czeka, a nie znika.
• Mapowanie indeksów. Klienci hurtowi używają własnych kodów produktów. Stworzyliśmy prostą tabelę mapującą — handlowiec widzi kod klienta, Optima i WMS widzą kod wewnętrzny.
• Log audytowy. Każda zmiana stanu zamówienia jest zapisana z timestampem, użytkownikiem i payloadem. Reklamacje, które kiedyś trwały 30 minut wertowania, dziś rozwiązują się w 2 minuty.

Wdrożenie: cztery miesiące, jeden weekend wyłączenia

Pracowaliśmy iteracyjnie. Pierwsze sześć tygodni — analiza, mapowanie procesów, integracja z Optimą w środowisku testowym (Comarch BIS API ma kilka kruczków, np. limity sesji i specyficzne kody błędów, które trzeba znać). Kolejne sześć tygodni — integracja z WMS i formularz zamówień. Ostatnie cztery tygodnie — testy z prawdziwym ruchem na środowisku stagingowym, równolegle z dotychczasowym procesem.

Przełączenie nastąpiło w jeden weekend. Zespół przez pierwszy tydzień pracował z naszym asystentem on-site (jeden z naszych ludzi siedział w biurze klienta i odpowiadał na pytania w czasie rzeczywistym). Drobne korekty wprowadzaliśmy na bieżąco. W trzecim tygodniu po przełączeniu przeszliśmy w tryb wsparcia zdalnego.

Wynik po 6 miesiącach od wdrożenia

Liczby to jedna strona. Druga to rzeczy, których nie da się tak łatwo zmierzyć: handlowcy przestali obiecywać klientom towar, którego nie ma, bo widzą rzeczywisty stan magazynu w czasie rzeczywistym. Biuro obsługi zamówień zamiast przepisywania danych zajęło się obsługą reklamacji i kontaktami z nowymi klientami. Kierownik magazynu nie musi już tłumaczyć księgowości, dlaczego ktoś znowu zapisał coś nie tak.

Najtrudniejszą częścią projektu nie była technologia. Najtrudniejsze było pokazanie zespołowi, że nie zabieramy im pracy — zabieramy im najgorszą część pracy.

Co dalej

Po wdrożeniu utrzymujemy system w trybie SLA — monitoring 24/7, miesięczne przeglądy logów, kwartalne aktualizacje pod nowe wersje Comarch Optima. W 2026 roku planujemy dołączyć drugi magazyn (klient otwiera oddział pod Wrocławiem) i rozszerzyć formularz zamówień o portal B2B dla stałych klientów hurtowych — żeby składali zamówienia samodzielnie.

To dobry przykład tego, jak działają nasze projekty. Nie wymieniamy wszystkiego. Nie kupujemy nowych systemów. Bierzemy to, co masz, i sprawiamy, żeby zaczęło działać jak jedna całość.

← Wszystkie case studies