Migracja z innego systemu do BaseLinker

Zmiana systemu przy działającej sprzedaży

Przejście na inny system obsługi zamówień w trakcie normalnej pracy sklepu budzi uzasadnioną obawę o historię sprzedaży i o ciągłość obsługi. Przy zaplanowanej migracji ryzyko jest niewielkie — pod warunkiem że przejście nie odbywa się w sezonie.

Co przenosimy

• Katalog produktów wraz z kodami, wariantami, cenami i wagami.
• Stany magazynowe na dzień przejścia.
• Podłączenia do sklepu, platform sprzedażowych i przewoźników.
• Konfigurację statusów zamówień.
• Integrację z systemem księgowym.

Historia zamówień

Zwykle nie przenosi się jej w całości — systemy różnią się strukturą, a zamówienia zamknięte i tak są już rozliczone. Sensowniejszym rozwiązaniem jest zachowanie dostępu do starego systemu w trybie do odczytu przez ustalony okres, a rozpoczęcie pracy w nowym od zamówień bieżących.

Okres przejściowy

Przez kilka dni zamówienia złożone wcześniej obsługiwane są w starym systemie, a nowe — w nowym. To jedyny sposób, żeby nie zostawić w połowie zamówień będących w trakcie realizacji.

Kolejność

Najpierw katalog i kody, potem magazyn, potem kanały sprzedaży, na końcu automatyzacje. Uruchamianie automatyzacji przed sprawdzeniem reszty jest najczęstszą przyczyną nieudanych migracji.

Termin

Poza okresem wzmożonej sprzedaży. Przez pierwsze dni pozostajemy dostępni, bo większość trudności ujawnia się przy prawdziwych zamówieniach.

Zakres migracji zależy od dotychczasowego systemu

Migracja może oznaczać przejście z panelu sklepu internetowego, programu magazynowego, rozwiązania przygotowanego na zamówienie albo innego integratora sprzedaży. W każdym wariancie dane są zapisane w nieco inny sposób. Przed rozpoczęciem prac trzeba więc ustalić, które informacje można wyeksportować, czyli zapisać w pliku możliwym do dalszego przetwarzania, a które trzeba odtworzyć w konfiguracji BaseLinker.

Najprostszy wariant występuje wtedy, gdy produkty mają jednoznaczne kody, warianty są uporządkowane, a stany magazynowe pochodzą z jednego źródła. Więcej przygotowań wymaga środowisko, w którym ten sam towar ma różne oznaczenia w sklepie, na platformach sprzedażowych i w programie magazynowym. W takiej sytuacji potrzebna jest mapa powiązań, czyli zestawienie wskazujące, które rekordy w różnych systemach dotyczą tego samego produktu.

Osobnym przypadkiem jest migracja z rozwiązania rozwijanego indywidualnie. Dostęp do bazy danych nie oznacza jeszcze, że wszystkie informacje da się przenieść bezpośrednio. Trzeba rozpoznać strukturę tabel, sposób zapisu wariantów oraz zależności między zamówieniami, płatnościami i wysyłkami. Bez takiej analizy łatwo otrzymać kompletny technicznie plik, którego nie można bezpiecznie wykorzystać w nowym środowisku.

Audyt danych przed rozpoczęciem przenoszenia

Przed migracją sprawdzana jest jakość danych źródłowych. Szczególne znaczenie mają powtarzające się kody produktów, brakujące numery SKU, niespójne nazwy wariantów oraz pozycje wycofane ze sprzedaży, które nadal figurują jako aktywne. SKU to wewnętrzny kod identyfikujący konkretny produkt lub jego wariant. Powinien prowadzić do jednej właściwej pozycji, ponieważ na jego podstawie mogą być synchronizowane stany i zamówienia.

Kontroli wymagają również stawki podatkowe, jednostki miary, ceny, wagi oraz przypisanie produktów do magazynów. Błąd w wadze może powodować wybór niewłaściwej metody dostawy, a niezgodna cena może zostać przekazana do wielu kanałów jednocześnie. Dane nie powinny być poprawiane przypadkowo w trakcie importu. Najpierw przygotowuje się listę rozbieżności, a następnie ustala, które źródło jest nadrzędne dla każdej grupy informacji.

Warto także oddzielić produkty rzeczywiście sprzedawane od archiwalnych kart, wersji testowych i duplikatów. Migracja całej zawartości starego systemu bez selekcji przenosi wcześniejszy nieporządek do nowej konfiguracji. BaseLinker nie usuwa automatycznie niejednoznaczności występujących w danych źródłowych, dlatego porządkowanie katalogu jest częścią przygotowania, a nie kosmetycznym etapem po uruchomieniu.

Ustalenie nadrzędnego źródła stanów i cen

Przed podłączeniem kanałów sprzedaży trzeba wskazać system nadrzędny, czyli miejsce uznawane za właściwe źródło określonych danych. Stan magazynowy może być prowadzony w BaseLinker, sklepie albo programie magazynowym. Cena również może pochodzić z jednego systemu i być przekazywana dalej. Jeżeli kilka aplikacji jednocześnie aktualizuje tę samą wartość, powstaje pętla synchronizacji, czyli sytuacja, w której kolejne systemy nadpisują się wzajemnie.

Reguły powinny określać nie tylko źródło stanu, lecz także sposób traktowania rezerwacji. Rezerwacja oznacza czasowe odjęcie sztuki dostępnej do sprzedaży po wpłynięciu zamówienia, zanim operacja zostanie ostatecznie rozliczona. Trzeba ustalić, co dzieje się po anulowaniu zamówienia, zwrocie, ręcznej korekcie oraz braku płatności. Te przypadki wpływają na rzeczywistą dostępność towaru i powinny zostać sprawdzone przed pełnym uruchomieniem synchronizacji.

Próba na ograniczonym zestawie danych

Bezpieczniej jest rozpocząć od niewielkiej, reprezentatywnej grupy produktów. Powinna obejmować produkt prosty, produkt z wariantami, pozycję z różnymi cenami w kanałach oraz towar wymagający konkretnej formy dostawy. Taki test pozwala sprawdzić mapowanie pól, czyli przypisanie danych ze starego systemu do odpowiednich miejsc w BaseLinker.

Po imporcie porównuje się nazwy, kody, warianty, ceny, stany, wagi oraz identyfikatory ofert. Sam komunikat o poprawnym zakończeniu operacji nie wystarcza. Import może wykonać się bez błędu technicznego, a jednocześnie umieścić dane w niewłaściwych polach. Dopiero ręczna kontrola kilku różnych przypadków pokazuje, czy ustalone reguły działają zgodnie z założeniami.

Następnie wykonuje się zamówienia testowe z używanych kanałów. Sprawdzany jest przepływ statusów, wybór magazynu, rezerwacja towaru, dokument sprzedaży i przekazanie danych do przewoźnika. Jeżeli wykorzystywany jest system księgowy, kontrola obejmuje również zgodność kontrahenta, pozycji dokumentu oraz sposobu rozliczenia. Dane testowe muszą być wyraźnie oznaczone, aby nie zostały potraktowane jak rzeczywista sprzedaż.

Automatyzacje wymagają odtworzenia logiki, a nie kopiowania nazw

Reguły działające w poprzednim systemie rzadko dają się przenieść jeden do jednego. Automatyzacja to zestaw warunków i czynności wykonywanych bez ręcznej obsługi, na przykład zmiana statusu po zaksięgowaniu płatności albo przygotowanie przesyłki po spełnieniu określonych kryteriów. Podobnie nazwana funkcja w dwóch systemach może działać w innym momencie procesu.

Każdą regułę trzeba opisać przez zdarzenie uruchamiające, warunki oraz oczekiwany skutek. Zdarzeniem może być wpłynięcie zamówienia, zmiana statusu lub pojawienie się płatności. Warunkiem może być kanał sprzedaży, metoda dostawy albo zawartość koszyka. Skutkiem bywa wysłanie wiadomości, utworzenie dokumentu, nadanie przesyłki lub zmiana statusu. Takie rozpisanie pozwala wykryć reguły dublujące się albo uruchamiane w niewłaściwej kolejności.

Najpierw wdraża się czynności niezbędne do obsługi zamówień. Dodatkowe powiadomienia, oznaczenia i rozbudowane scenariusze można uruchomić po ustabilizowaniu podstawowego procesu. Ogranicza to liczbę zależności sprawdzanych jednocześnie i ułatwia ustalenie przyczyny, gdy jedno zamówienie przejdzie inną ścieżkę niż oczekiwano.

Błędy popełniane podczas samodzielnej migracji

Częstym błędem jest podłączenie wszystkich kanałów przed uporządkowaniem katalogu. Jeżeli oferty nie są prawidłowo powiązane z produktami, aktualizacja stanu może objąć niewłaściwe pozycje albo nie zadziałać wcale. Samo podobieństwo nazw nie jest wystarczającym potwierdzeniem, zwłaszcza gdy produkty różnią się kolorem, rozmiarem lub zestawem.

Ryzykowne jest również wykonywanie kolejnych pełnych importów bez sprawdzenia sposobu rozpoznawania istniejących rekordów. Zależnie od przygotowania danych może to prowadzić do duplikatów albo nadpisania wcześniej poprawionych informacji. Przed powtórzeniem operacji należy ustalić, czy rekordy są identyfikowane według kodu, identyfikatora, numeru oferty czy innego jednoznacznego pola.

Inny problem stanowi uruchomienie dwukierunkowej synchronizacji w kilku miejscach. Synchronizacja dwukierunkowa oznacza, że dane mogą być zarówno wysyłane, jak i odbierane przez oba połączone systemy. Bez jasno ustalonego źródła nadrzędnego korekta wykonana przez pracownika może po chwili zostać cofnięta przez automatyczną aktualizację.

Nie należy też zamykać starego systemu natychmiast po pierwszym poprawnie obsłużonym zamówieniu. Potrzebny może być dostęp do wcześniejszej korespondencji, dokumentów, numerów przesyłek, zwrotów albo reklamacji. Zachowanie środowiska w trybie do odczytu pozwala zakończyć rozpoczęte procesy bez mieszania ich z nową konfiguracją.

Kiedy problem nie wynika z samej migracji

Brak zamówienia w BaseLinker nie zawsze oznacza błąd przenoszenia danych. Przyczyną może być nieaktywne połączenie z kanałem, nieprawidłowe uprawnienia integracji albo filtr ograniczający pobieranie zamówień. Filtr to reguła wybierająca tylko rekordy spełniające określone warunki. W takim przypadku katalog może być przeniesiony poprawnie, a diagnoza powinna dotyczyć bieżącej komunikacji między systemami.

Rozbieżny stan magazynowy również nie musi wynikać z błędnego importu. Trzeba sprawdzić rezerwacje, zamówienia oczekujące, anulowania oraz ręczne zmiany w systemie nadrzędnym. Jeżeli wartość początkowa była prawidłowa, a różnica pojawiła się później, analizuje się kolejne operacje wykonane po uruchomieniu synchronizacji.

Podobnie brak dokumentu księgowego może wynikać z konfiguracji integracji, danych kontrahenta albo warunku wystawiania dokumentu, a nie z migracji katalogu. Rozdzielenie tych obszarów skraca diagnozę. Zamiast ponawiać cały import, sprawdza się konkretny etap, na którym przepływ danych został zatrzymany.

Dodatkowe pytania dotyczące przejścia do BaseLinker

Czy można przenieść wszystkie stare zamówienia?

Możliwość techniczna zależy od formatu danych udostępnianego przez poprzedni system oraz od celu migracji. Pełne przenoszenie archiwum często nie daje korzyści proporcjonalnej do złożoności prac. Zamówienia mogą zawierać statusy, płatności, przesyłki i dokumenty zapisane według reguł, które nie mają bezpośrednich odpowiedników. Dlatego najpierw ustala się, które informacje muszą być dostępne operacyjnie, a które mogą pozostać w archiwum do odczytu.

Czy sprzedaż trzeba całkowicie zatrzymać?

Nie zawsze jest to konieczne. Potrzebne jest jednak kontrolowane okno przejścia, w którym wykonuje się końcową aktualizację stanów i przełącza źródła danych. Zamówienia wpływające przed wyznaczonym momentem kończy się w starym systemie, a późniejsze obsługuje w nowym. Granica musi być jednoznaczna dla wszystkich osób zajmujących się sprzedażą, magazynem i księgowością.

Co zrobić z zamówieniami oczekującymi na płatność lub zwrot?

Takie zamówienia należy ująć na liście spraw otwartych i przypisać do systemu, w którym zostaną zakończone. Przeniesienie samego rekordu bez całego kontekstu może utrudnić rozpoznanie późniejszej płatności albo korekty. Bezpieczniej jest pozostawić rozpoczęty proces w dotychczasowym środowisku, chyba że wcześniej przygotowano i sprawdzono pełną ścieżkę jego obsługi w BaseLinker.

Czy po migracji można zmienić układ statusów?

Można, ale najpierw trzeba sprawdzić, do czego poszczególne statusy są wykorzystywane. Mogą uruchamiać wiadomości, dokumenty, wysyłki lub inne automatyzacje. Zmiana nazwy jest zwykle mniej istotna niż zmiana znaczenia statusu w procesie. Nowy układ powinien być opisany prostymi zasadami, aby każda osoba wiedziała, kiedy zamówienie ma zostać przesunięte do kolejnego etapu.

Jak rozpoznać, że migracja została zakończona prawidłowo?

Potwierdzeniem nie jest sam import katalogu. Trzeba zweryfikować pełny przebieg rzeczywistego procesu: pobranie zamówienia, rezerwację właściwego produktu, zmianę statusu, przygotowanie wysyłki, utworzenie potrzebnego dokumentu oraz aktualizację stanu w kanałach. Dodatkowo sprawdza się anulowanie i zwrot, ponieważ te operacje odwracają część wcześniejszych zmian. Migrację można uznać za stabilną, gdy podstawowe i wyjątkowe scenariusze mają ustalony, powtarzalny przebieg.

Kontrola po przełączeniu chroni ciągłość sprzedaży

Po rozpoczęciu pracy w BaseLinker porównuje się zamówienia widoczne w kanałach z zamówieniami pobranymi do systemu. Kontrolowane są także stany produktów o największej rotacji, dokumenty oraz przesyłki. Wszelkie rozbieżności zapisuje się wraz z godziną, kanałem i numerem zamówienia. Taki opis pozwala odtworzyć kolejność zdarzeń bez zgadywania.

Dobrze przygotowana migracja kończy się nie wtedy, gdy ostatni plik zostanie zaimportowany, lecz wtedy, gdy cały zespół pracuje według jednego procesu, dane mają określone źródła, a zamówienia przechodzą przez kolejne etapy bez ręcznego obchodzenia konfiguracji. To właśnie uporządkowany pierwszy obieg zamówienia stanowi najważniejszy test przejścia do BaseLinker.