Integracja systemów w firmie: co zrobić, gdy przestaje działać

Integracja systemów to trwałe połączenie dwóch lub więcej programów, w którym dane przechodzą między nimi automatycznie, według ustalonych reguł, bez ręcznego przepisywania. Integracja systemów w firmie rzadko psuje się w dniu uruchomienia — psuje się trzy miesiące później, gdy dostawca zmienia API, sklep dostaje kilkaset zamówień w godzinę albo serwer po drugiej stronie przestaje odpowiadać. Oferty opisują pięć etapów wdrożenia i listę korzyści. Ten tekst jest o tym, czego w nich nie ma: co ustalić przed startem i co się dzieje, gdy druga strona milczy.

Od czego naprawdę zaczyna się integracja systemów w firmie

Zaczyna się od decyzji, który system ma rację, gdy dwa pokazują różne dane — nie od wyboru narzędzia. Źródło prawdy to jeden konkretny system, którego wartość wygrywa w razie rozbieżności; wszystkie pozostałe kopie są tylko odbiciem. Zanim padnie pytanie „Make czy n8n”, musi paść pytanie „kto jest właścicielem informacji o stanie magazynowym”.

Typowy zestaw do połączenia w polskiej firmie średniej wielkości to ERP (Comarch ERP Optima lub XL, enova365, Symfonia, Subiekt GT i nexo, Streamsoft Prestiż, Sente, Microsoft Dynamics 365 Business Central, SAP), platforma sprzedaży (Shoper, IdoSell, PrestaShop, WooCommerce, Magento, Shopify, Sky-Shop, Selly, AtomStore) oraz marketplace’y: Allegro, Amazon, eBay, Kaufland, Empik. W magazynie dochodzi WMS, który z ERP wymienia zwykle dwa komunikaty — zlecenie kompletacji w jedną stronę i potwierdzenie realizacji z powrotem, przez API albo szynę danych.

Dwustronna synchronizacja tej samej encji jest najdroższą i najbardziej awaryjną opcją, jaką można wybrać, bo wymaga rozstrzygania konfliktów w czasie rzeczywistym. Wybieraj ją tylko tam, gdzie proces naprawdę tego wymaga.

Macierz decyzji, którą trzeba wypełnić przed wyborem narzędzia

Dla każdej encji ustal cztery rzeczy: kierunek, częstotliwość, źródło prawdy i zachowanie przy konflikcie. Bez tej tabeli integracja jest zgadywanką, a rozjechane kartoteki i nadsprzedaż są tylko kwestią czasu. Wypełnij ją w arkuszu, zanim ktokolwiek napisze pierwszą linię kodu — to również najlepszy załącznik do zapytania ofertowego i naturalna część tego, co powinien zawierać dobry brief dla software house.

Wiersz o stanie magazynowym rozjeżdża się w praktyce najczęściej, bo pod jednym słowem „stan” kryją się cztery różne liczby — jak ustawić synchronizację stanów magazynowych tak, żeby nie kończyła się nadsprzedażą, rozkłada osobny tekst.

Ostatni wiersz ma osobne konsekwencje prawne: faktury ustrukturyzowane i wpięcie własnego oprogramowania do Krajowego Systemu e-Faktur to temat na osobną rozmowę, opisany w tekście o tym, jak wygląda integracja z KSeF własnego systemu. Ten artykuł ma charakter informacyjny i nie jest poradą prawną.

Webhook czy odpytywanie — różnica widziana od strony odbiorcy

Webhook to powiadomienie, które system nadawcy wysyła sam z siebie w chwili zdarzenia na wskazany adres; odpytywanie (polling) to sytuacja odwrotna, w której to Ty co jakiś czas pytasz „czy jest coś nowego”. Z perspektywy sprzedaży webhook wygląda lepiej, bo działa natychmiast. Z perspektywy odbiorcy jest trudniejszy i to właśnie tutaj integracje w firmach psują się najczęściej.

Odbiorca webhooka musi zrobić cztery rzeczy, których nie widać w ofercie:

• Potwierdzić odbiór, zanim cokolwiek przetworzy. Nadawca ma limit czasu na odpowiedź. Jeśli Twój system najpierw zapisze zamówienie do ERP, a dopiero potem odpowie, każde spowolnienie ERP wygląda dla nadawcy jak awaria. Poprawna kolejność: zapisz surowy komunikat, odpowiedz, przetwarzaj osobno.
• Mieć kolejkę. Kolejka to lista komunikatów czekających na obsługę, przetwarzana po kolei niezależnie od tempa ich napływu. Bez niej nagły ruch przewraca integrację, a zdarzenia z okresu awarii przepadają.
• Wytrzymać duplikaty. Nadawca ponawia wysyłkę, gdy nie dostanie potwierdzenia — ten sam komunikat potrafi przyjść dwa razy. Ratuje idempotencja: własność, dzięki której komunikat obsłużony dwukrotnie daje ten sam skutek co obsłużony raz. W praktyce oznacza to zapisywanie identyfikatora zdarzenia i odrzucanie powtórek.
• Nie zakładać kolejności. Zdarzenia potrafią przyjść w innej kolejności, niż powstały. Status „wysłane” nie może cofnąć się do „w kompletacji” tylko dlatego, że starszy komunikat dotarł później. Decyduje znacznik czasu albo numer wersji rekordu, nie moment odebrania.

Odpytywanie ma jedną przewagę, o której mało kto mówi: przegapione zdarzenie nie znika, bo następny przebieg i tak zobaczy zmieniony rekord. Zgubiony webhook przepada bezpowrotnie. Dojrzałe integracje mają obie ścieżki — webhook dla szybkości i cykliczne dosynchronizowanie raz na dobę jako siatka bezpieczeństwa.

Co zrobić, gdy system nie ma API

Sprawdź to u dostawcy pisemnie, zanim uznasz, że API nie ma — bywa, że istnieje, tylko jest płatne, niereklamowane albo dostępne wyłącznie w nowszej wersji. Część starszych systemów księgowo-magazynowych na polskim rynku faktycznie nie ma publicznego, wspieranego interfejsu i wtedy zostają opcje gorsze. Warto je znać w kolejności od najlepszej — pełne porównanie tego, jak połączyć dwa systemy bez API, wraz z oceną, która droga jest długiem technicznym, opisuje osobny tekst.

1. Oficjalne, wspierane API (REST, SOAP lub GraphQL, uwierzytelniane przez OAuth 2.0, token albo klucz API). Jedyna opcja, którą dostawca ma obowiązek utrzymać.
2. Eksport i import plików przez SFTP z harmonogramem. JSON, XML lub CSV odkładane cyklicznie do katalogu. Rozwiązanie stare, ale przewidywalne i łatwe do audytu. Wymaga katalogu na pliki odrzucone i alertu, gdy plik nie pojawi się o czasie.
3. Integracja przez bazę danych systemu. Działa, dopóki dostawca nie zmieni struktury tabel przy aktualizacji — a zmieni, bo nie obiecywał inaczej. To dług techniczny z odroczonym terminem płatności: nie jest objęta wsparciem i potrafi po cichu zapisać dane w sposób, którego aplikacja się nie spodziewa.
4. Ręczny import i eksport CSV. Nie jest integracją, tylko procedurą. Akceptowalne jako rozwiązanie na kilka tygodni, nie na kilka lat.

Ostatnie zdanie tego pytania jest najważniejsze. Odpowiedź na nie decyduje, czy integracja będzie kosztem jednorazowym, czy stałym.

Punkt-punkt, szyna danych czy iPaaS w firmie MŚP

W polskich materiałach branżowych opisuje się trzy układy i każdy ma swój moment. Połączenie punkt-punkt, czyli bezpośrednie łącze między dwoma systemami, jest najtańsze i najszybsze do uruchomienia — sensowne, gdy systemów są dwa lub trzy i nie planujesz kolejnych. Szyna danych (ESB) to centralny pośrednik, przez który przechodzi cała komunikacja; zaczyna się opłacać, gdy systemów jest kilka, a każdy nowy oznaczałby dopisywanie połączeń do wszystkich pozostałych. iPaaS (Integration Platform as a Service) to platforma integracyjna hostowana przez dostawcę chmurowego, który odpowiada za aktualizacje i dostępność, a Ty budujesz w niej przepływy — wygodna, gdy nie chcesz utrzymywać własnej infrastruktury i akceptujesz zależność od dostawcy.

W e-commerce funkcję warstwy pośredniej pełnią też gotowe integratory obecne na rynku polskim: BaseLinker, Apilo, Sellasist. Osobnym światem jest EDI, czyli ustandaryzowana wymiana dokumentów handlowych — standard EDIFACT powstał w ramach ONZ i został przyjęty przez ISO jako norma ISO 9735. Największymi użytkownikami EDI w Polsce są sieci handlowe, więc jeśli sprzedajesz do sieci, standard i format wybiera odbiorca, nie Ty.

Kiedy no-code przestaje wystarczać

Narzędzia takie jak Make, n8n, Zapier, Microsoft Power Automate, Node-RED czy Pipedream są dobrą pierwszą wersją integracji i złą wersją docelową dla procesu krytycznego. Granicę wyznacza sześć progów, a nie opinia o narzędziu:

• Skala. Rozliczenie od operacji przestaje być tanie dokładnie wtedy, gdy proces staje się codzienny. Policz liczbę operacji miesięcznie, zanim uznasz, że koszt jest pomijalny.
• Wrażliwość danych. Dane osobowe i handlowe przechodzą przez infrastrukturę dostawcy. Make działa wyłącznie w chmurze, n8n jest otwartoźródłowe i można je hostować u siebie albo w chmurze n8n z serwerami w Niemczech. Lokalizację i warunki przetwarzania sprawdzaj w umowie z dostawcą, nie w opisie funkcji.
• Przewidywalność opóźnień. Jeśli proces musi zdążyć w określonym czasie, potrzebujesz gwarancji, których plan współdzielony zwykle nie daje.
• Audyt. Pytanie „dlaczego to zamówienie nie trafiło do ERP 14 marca” musi mieć odpowiedź opartą na zapisach, a nie na pamięci.
• Uzależnienie od dostawcy. Scenariusz zbudowany klikaniem nie przenosi się na inną platformę. Im więcej w nim logiki, tym droższe wyjście.
• Rozmiar scenariusza. Przepływ z kilkudziesięcioma krokami i gałęziami warunkowymi jest już oprogramowaniem — tyle że bez testów, wersjonowania i przeglądu kodu, często z jedną osobą, która go rozumie.

Koszt przepisania takiego przepływu na własny serwis rządzi się tą samą logiką co wycena aplikacji mobilnej: płacisz za przypadki brzegowe i integracje, nie za liczbę ekranów. Warto też z góry przyjąć, że pierwsza wersja obejmuje jeden proces — ta sama zasada, którą stosuje się przy ustalaniu zakresu MVP aplikacji. Gdzie dokładnie przebiega granica opłacalności i ile realnie kosztuje samodzielne hostowanie narzędzia, rozkłada tekst o tym, czy wybrać Make, n8n czy własną integrację.

Co musi mieć każda integracja, żeby dało się z nią żyć

Integracja bez monitoringu nie jest gotowa, nawet jeśli działa. Poniższa lista to minimum, którego warto wymagać w umowie, niezależnie od tego, czy prace prowadzi zespół wewnętrzny, czy zewnętrzny.

• Logi z treścią komunikatu. Nie „błąd zapisu”, tylko co przyszło, co wysłano i jaką odpowiedź zwrócił drugi system.
• Monitoring ciszy. Alarmuje nie tylko błąd, ale też brak zdarzeń — sklep, który od czterech godzin nie przysłał żadnego zamówienia w środku dnia roboczego, jest sygnałem sam w sobie.
• Alert do człowieka. Konkretna osoba, konkretny kanał, konkretny próg czasu. Powiadomienie na skrzynkę, której nikt nie czyta, to brak alertu.
• Kolejka nieudanych komunikatów. Osobne miejsce, w którym lądują zdarzenia odrzucone przez drugą stronę, wraz z powodem odrzucenia.
• Procedura ponowienia. Ktoś nietechniczny musi umieć wskazać komunikaty z ostatnich dwóch godzin i wysłać je ponownie, bez grzebania w bazie danych.
• Właściciel po stronie firmy. Jedna osoba, która wie, co się z czym synchronizuje, i ma kontakt do dostawców obu systemów. Bez tego pierwsza awaria zamienia się w ustalanie, kto powinien zadzwonić.
• Plan na zmianę API. Zapisz, gdzie dostawca ogłasza zmiany, kto to śledzi i ile czasu ma zespół na reakcję. To pytanie z wzoru powyżej, tylko przeniesione do umowy.

Ta warstwa jest tym, co odróżnia integrację od jednorazowego skryptu, i tym, czego najczęściej brakuje w wycenach — podobnie jak stała opieka nad wydajnością bywa pomijana przy stronach, gdzie mierzy się ją wskaźnikami Core Web Vitals. Jeśli planujesz szerszy projekt, w którym integracja jest jednym z elementów obok aplikacji, warto przejść ją tą samą ścieżką co tworzenie aplikacji mobilnej: najpierw zakres i decyzje, potem narzędzia. Najprostszy sposób, żeby to uporządkować, to opisać sytuację w kreatorze briefu — sześć kroków wystarczy, żeby wyszło, które połączenie jest pilne, a które może poczekać.