Integracja z ERP: co spiąć w pierwszej wersji

Decyzje handlowe z poprzedniego rozdziału mają jedną wspólną cechę: prawie żadnej z nich platforma nie wykona na własnych danych. Limit kupiecki wymaga salda, blokada wymaga listy przeterminowanych faktur, cena kontraktowa i stan magazynowy żyją tam, gdzie od lat pracuje firma, czyli w ERP. Ten rozdział jest o decyzjach, a nie o technice: co spiąć najpierw, kto jest właścicielem którego pola, jak często wymieniać dane i co się dzieje, gdy połączenie milknie w środę o dziesiątej rano. Architekturę takiej wymiany, w tym kolejki i ponawianie, rozpisaliśmy osobno w tekście o integracji sklepu B2B z ERP.

Co musi być spięte w pierwszej wersji, a co może poczekać

Test jest prosty: bez czego klient nie złoży poprawnego zamówienia, a Twój zespół nie zamknie dnia. Odpowiedź daje pięć pozycji. Stany magazynowe, z rozstrzygnięciem, którą wartość pokazujesz: fizyczną czy dostępną do sprzedaży, po odjęciu rezerwacji. Ceny i warunki klienta, najlepiej wyliczone już po stronie ERP, żeby nie odtwarzać jego logiki w drugim systemie. Kartoteka kontrahenta razem z limitem i saldem, bo bez niej decyzje z poprzedniego rozdziału zostają na papierze. Zamówienia przekazywane do ERP natychmiast po złożeniu, z numerem i statusem wracającym do klienta. Oraz dokumenty, czyli faktury i dokumenty wydania do pobrania z konta.

Dokumenty są w tej piątce najczęściej niedoceniane, a zdejmują z księgowości i handlowców jedno z najbardziej powtarzalnych zadań w firmie: odsyłanie faktur na życzenie. Poczekać mogą za to rzeczy, które w prezentacjach wyglądają dobrze, a w pierwszych miesiącach są używane rzadko: rezerwacje partii i numerów seryjnych, rozliczanie bonusów rocznych, ewidencja reklamacji, prognozy dostaw, statusy przesyłek od przewoźnika. Każda z nich jest osobnym projektem integracyjnym i każda wydłuża start. Zasada jest jedna: jeżeli proces dziś działa na telefonie i mailu, a jego przeniesienie nie blokuje zamówień, to nie jest zakres pierwszej wersji.

Kto jest źródłem prawdy dla każdego typu danych

To najważniejsza decyzja architektoniczna, którą podejmuje się jednak biznesowo, a nie technicznie. Zasada brzmi: jedno źródło prawdy na typ danych, wskazane wprost i zapisane. W typowym układzie ERP jest właścicielem cen, warunków handlowych, stanów, kartoteki i dokumentów, bo to tam pracuje księgowość i magazyn. Platforma jest właścicielem tego, czego ERP nie ma i mieć nie musi: treści produktowych, zdjęć, struktury kategorii, kont użytkowników i uprawnień (w ERP nie istnieje pojęcie „użytkownik sklepu”), koszyków oraz zapytań ofertowych do momentu ich akceptacji.

Problem robi się w polach spornych i to je trzeba rozstrzygnąć na papierze. Adresy dostawy: klient dodaje je w sklepie, ale ERP musi je przyjąć i to on jest właścicielem adresu na dokumencie. Dane kontaktowe i osoby zamawiające: zwykle właścicielem jest platforma, a ERP dostaje je do kartoteki. Zamówienie: platforma jest właścicielem do momentu przyjęcia przez ERP, potem właścicielem statusu staje się ERP i sklep tylko go pokazuje. Gdy dwa systemy mogą edytować to samo pole, wygrywa ten, który zapisał później, a to znaczy, że wygrywa przypadek. Zablokowanie edycji po jednej stronie jest zawsze tańsze niż uzgadnianie konfliktów po fakcie.

Poniższa tabela jest wzorem takiego ustalenia. Wypełnij ją dla swojej firmy przed rozmową z dostawcą, bo ostatnia kolumna decyduje o zakresie, a przedostatnia o koszcie.

Wzór do wypełnienia przed wyborem dostawcy. Kolumna z częstotliwością jest jednocześnie kolumną kosztu: im bliżej czasu rzeczywistego, tym drożej w budowie i w utrzymaniu.

Czas rzeczywisty czy cykliczny: to decyzja kosztowa

Synchronizacja na bieżąco brzmi jak wybór oczywisty i bywa nim rzadziej, niż się wydaje. Kosztuje więcej w budowie, wymaga monitoringu i obciąża ERP, który przy starszych wdrożeniach nie zawsze znosi ciągłe odpytywanie, a bywa też licencjonowany od liczby interfejsów albo zapytań. Synchronizacja cykliczna, na przykład nocna, jest tania i przewidywalna, ale oznacza, że sklep pracuje na danych sprzed kilkunastu godzin. Wariant pośredni sprawdza się najczęściej: cykliczna podstawa plus odświeżenie na żądanie w punktach krytycznych, czyli przy wejściu do koszyka i przy składaniu zamówienia.

Co zrobić, gdy ERP nie ma API

To sytuacja częstsza, niż sugerują materiały dostawców platform, zwłaszcza przy starszych i lokalnych systemach. Nie przekreśla projektu, tylko przesuwa go w stronę rozwiązań cyklicznych, a to znaczy, że część decyzji z poprzedniego rozdziału trzeba przemyśleć ponownie: przy wymianie plikowej trudno obiecywać klientom dokładny stan magazynu co do sztuki.

Warianty są cztery, w kolejności od najbezpieczniejszego. Pierwszy: dostawca ERP ma własny moduł integracyjny lub konektor, zwykle płatny, za to utrzymywany i testowany przy aktualizacjach. Drugi: wymiana plikowa, czyli uzgodnione pliki wymieniane w cyklu przez katalog albo serwer plików. Jest tania, zaskakująco trwała i całkowicie wystarcza przy dobowej częstotliwości, ale nie daje potwierdzeń w czasie rzeczywistym. Trzeci: warstwa pośrednicząca, która trzyma mapowania i tłumaczy formaty; sensowna, gdy systemów jest więcej niż dwa. Czwarty: czytanie wprost z bazy danych ERP, najszybsze do uruchomienia i najbardziej ryzykowne, bo pierwsza aktualizacja ERP potrafi je zepsuć, a zapisywanie do tej bazy z pominięciem logiki aplikacji jest wprost złym pomysłem. Przy każdym wariancie zadaj to samo pytanie: kto to utrzyma za dwa lata i co się stanie, gdy ERP dostanie nową wersję.

Plan na wypadek awarii integracji

Integracja kiedyś przestanie działać i nie jest to pesymizm, tylko doświadczenie: wygasa hasło, zmienia się nazwa pola po aktualizacji, kończy się miejsce na dysku, serwer ERP idzie na przegląd. Pytanie nie brzmi „czy”, tylko „co wtedy robi sklep”. Domyślna, rozsądna odpowiedź brzmi: przyjmuje zamówienia dalej i kolejkuje je do przekazania, a ERP dostaje je po powrocie łączności. Wariant przeciwny, czyli wstrzymanie zamówień, jest bezpieczny księgowo i kosztowny sprzedażowo, bo klient nie czeka, tylko dzwoni do konkurencji.

Do rozstrzygnięcia zostają cztery rzeczy. Na jakich danych pracuje sklep w trybie awaryjnym: na ostatnich znanych cenach i stanach, i po jakim czasie przestaje pokazywać dostępność, bo dane sprzed dwóch dni wprowadzają klienta w błąd. Co z odroczoną płatnością, gdy nie ma salda: wstrzymujesz ją i przełączasz na przedpłatę, czy dopuszczasz z ryzykiem; to decyzja finansów, nie programistów. Kto się dowiaduje o awarii i w jakim czasie: alert ma trafić do konkretnej osoby, a nie na skrzynkę zbiorczą, i handlowiec powinien wiedzieć wcześniej niż klient. Oraz jak wygląda procedura ręczna: kto przepisuje zaległe zamówienia i po czym poznaje, że dane zamówienie zostało już przepisane, żeby klient nie dostał tego samego towaru dwa razy.

Pytania do dostawcy ERP przed podpisaniem umowy

Te odpowiedzi zbierz na piśmie, zanim podpiszesz umowę na platformę, bo każda z nich potrafi zmienić zakres i harmonogram. Czy moja wersja ERP ma udokumentowane API i co dokładnie udostępnia: stany, ceny dla konkretnego kontrahenta z uwzględnieniem jego warunków, saldo i limit, zakładanie zamówienia. Czy potrzebny jest dodatkowy moduł lub licencja i ile kosztuje rocznie, a nie tylko przy wdrożeniu. Jakie są limity zapytań i czy istnieje środowisko testowe, na którym można pracować bez ruszania danych produkcyjnych. Kto po stronie dostawcy odpowiada za integrację, w jakim czasie reaguje i czy jest to objęte umową serwisową. Co dzieje się przy aktualizacji ERP i czy integracje są wtedy testowane.

Jedno pytanie warto zadać osobno, bo jest najdroższe w skutkach: czy ERP potrafi zwrócić cenę wyliczoną dla danego klienta, ze wszystkimi jego warunkami, czy platforma musi tę logikę odtworzyć u siebie. Odtwarzanie oznacza dwa miejsca, w których ta sama polityka cen musi być utrzymywana, i gwarantowany rozjazd przy pierwszej zmianie warunków. Gdy te odpowiedzi masz na piśmie, dane zaczynają płynąć w obie strony i zostaje pytanie, kto z tego rzeczywiście skorzysta. Klienci i handlowcy muszą wejść do systemu i zacząć w nim pracować, a o tym jest następny rozdział.