Rulewave
System zarządzania magazynem dla globalnego dostawcy usług logistycznych

ERP, system magazynowy, przewoźnik, płatności i księgowość rzadko są projektowane tak, aby ze sobą współpracowały. Budujemy połączenia między nimi, przesyłamy dane w obie strony, obsługujemy błędy i dostosowujemy integrację, gdy któryś system się zmienia.
Nasi partnerzy


Zamówienia, przesyłki, stany i dokumenty są spójne po obu stronach. Magazyn i zaplecze operacyjne nie muszą ustalać, który system pokazuje właściwe dane. Rulewave, od 2019 roku.
Integracja z DHL od utworzenia etykiety po śledzenie przesyłki, bez ręcznego przepisywania danych. Skanery pokazują to samo co system, a dostawcy samodzielnie awizują dostawy. Rulewave.
Stripe do obsługi subskrypcji, e-faktury wysyłane bezpośrednio do KSeF oraz fakturowanie przez zewnętrzne systemy w Holandii i USA. Tesoro, TransHans, Rulewave.
Twilio, Gmail i Outlook. Rozmowy oraz wiadomości są przypisywane do właściwego klienta, dzięki czemu nikt nie musi przeszukiwać kilku skrzynek. Tesoro.
Położenie każdego pojazdu jest widoczne w tym samym systemie, który obsługuje sprzedaż biletów. TransHans.
Oferty trafiają do Idealisty, Fotocasy, Resales Online i kilkunastu innych portali. Każdy z nich wymaga innego formatu, od XML po API. OpenAI tłumaczy treść ofert i ocenia przychodzące zapytania. Tesoro.
Większość integracji może działać na dwa sposoby: dane są przesyłane na bieżąco albo synchronizowane raz na dobę. Najważniejsza różnica nie jest techniczna, lecz operacyjna, i staje się szczególnie widoczna w razie błędu.
| Czas rzeczywisty | Nocna synchronizacja | |
|---|---|---|
| Kiedy dane się zgadzają | Od razu po zmianie | Rano, po nocnym imporcie |
| Gdy coś pójdzie źle | Problem widać od razu | Problem wychodzi następnego dnia, o ile ktoś go sprawdzi |
| Inwentaryzacja | Nie ma rozbieżności do wyjaśniania | Powstają różnice, których po tygodniu nie da się odtworzyć |
| Praca ludzi | Jeden stan i jedno miejsce | Ktoś patrzy w dwa systemy i wybiera, któremu wierzy |
| Koszt wdrożenia | Wyższy, bo trzeba obsłużyć błędy i powtórzenia | Niższy, bo to jeden eksport i jeden import |
| Kiedy wystarczy | Magazyn, sprzedaż, płatności i inne systemy wykorzystywane w bieżącej pracy | Raporty, księgowość, archiwum |
W żadnym z tych projektów ekrany nie były najtrudniejszą częścią. Magazyn globalnego operatora, CRM dla biur nieruchomości i system sprzedaży biletów zależą od tego, czy dane docierają we właściwe miejsce i we właściwym czasie.
System zarządzania magazynem dla globalnego dostawcy usług logistycznych
System CRM dla agencji nieruchomości
Własna aplikacja do sprzedaży biletów autobusowych
Integracja rzadko powstaje w idealnych warunkach. Po drugiej stronie zwykle znajduje się starszy system, którego dokumentacja od dawna nie odpowiada rzeczywistości.
Dokumentacja często jest nieaktualna, dlatego analizujemy komunikację przez API i same dane. Opis sprzed trzech lat traktujemy jako wskazówkę, a nie źródło prawdy.
Pierwsze próby przeprowadzamy w środowisku testowym na kopii danych. Błąd na tym etapie kosztuje godzinę, a nie dzień pracy magazynu.
Nowy obieg działa obok starego, dopóki dane po obu stronach nie będą zgodne. Dopiero wtedy wyłączamy poprzednie rozwiązanie.
Ten etap łatwo pominąć przy wyborze wykonawcy, choć to właśnie odpowiedzialne utrzymanie sprawia, że klienci zostają z nami przez lata.
Integracja może przestać działać bez widocznego błędu. Nikt nie otrzymuje komunikatu, a liczby stopniowo zaczynają się różnić.
Niezależnie od tego, czy chodzi o SAP, przewoźnika, czy operatora płatności, zmianę po jego stronie traktujemy jako element utrzymania, a nie osobny projekt do wyceny.
Zasady KSeF ewoluują, a TransHans korzysta z tej integracji od 2022 roku. Aktualizacje prawne obsługujemy tak samo jak zmiany API.
Ci sami inżynierowie, którzy zbudowali integrację. Niska rotacja ma szczególne znaczenie przy utrzymaniu złożonych połączeń między systemami.
Zwykle tak, choć rozwiązanie może wyglądać inaczej, niż się spodziewasz. Czasem dostępny jest eksport pliku na serwer, możliwa do odczytu baza danych, webhook albo starszy protokół, którego dostawca już aktywnie nie wspiera. Zaczynamy od tego, jakie dane system rzeczywiście udostępnia, a nie od deklaracji w materiałach sprzedażowych. Jeśli nie ma żadnej realnej możliwości integracji, mówimy o tym od razu.
Czasem tak, czasem nie i nie ma sensu twierdzić inaczej. Na produkcji utrzymujemy między innymi integracje z SAP, DHL, Stripe, Twilio, KSeF i portalami MLS. Pracę z nieznanym systemem zaczynamy od jego dokumentacji i rozmowy z osobą, która dobrze go zna. Ważniejsza od znajomości konkretnego produktu jest umiejętność zrozumienia protokołu innego dostawcy.
To jedna z najczęstszych awarii integracji, choć zwykle nie wygląda groźnie. Nic się nie zatrzymuje, ale stan magazynowy lub saldo stopniowo odbiega od rzeczywistości. Dlatego na początku ustalamy, który system jest źródłem prawdy dla każdego rodzaju danych, i zapewniamy możliwość ponownego przesłania informacji, które nie dotarły. Bez tego pierwsza rozbieżność kończy się ręcznym poprawianiem danych w Excelu.
Największy wpływ na termin ma system po drugiej stronie. Dobrze udokumentowane API ze środowiskiem testowym wymaga zupełnie innego nakładu pracy niż rozwiązanie, do którego dostęp trzeba przez kilka tygodni uzgadniać z dostawcą. Przed wyceną prosimy więc o dokumentację i kontakt do osoby znającej ten system. Dopiero wtedy możemy podać wiarygodny termin.
Najczęściej nie. Szyna danych albo płatna platforma iPaaS zaczyna się opłacać, gdy systemów jest kilkanaście i każdy wymienia dane z wieloma pozostałymi. Przy trzech lub czterech oznacza zwykle dodatkowy koszt i zależność od kolejnego dostawcy. Jeśli skala uzasadni takie narzędzie, powiemy o tym, ale nie zakładamy go z góry.
Napisz, o jakie systemy chodzi i w którym miejscu ich dane zaczynają się różnić. Odpowiemy pytaniami o dane, a nie gotową ofertą wdrożenia.