Konfiguracja automatyzacji zamówień w BaseLinker

Więcej zamówień bez proporcjonalnie większej pracy

Automatyzacje pozwalają obsłużyć rosnącą liczbę zamówień bez zwiększania nakładu pracy ręcznej. Warunek jest jeden: reguły muszą odpowiadać temu, jak firma faktycznie pracuje, a nie temu, jak wyglądają ustawienia przykładowe.

Co zwykle automatyzujemy

• Zmianę statusu zamówienia po zaksięgowaniu wpłaty.
• Tworzenie przesyłki i wydruk etykiety po skompletowaniu.
• Wystawianie dokumentu sprzedaży.
• Wysyłkę wiadomości do klienta z numerem przesyłki.
• Przypisywanie zamówień do właściwego magazynu.
• Oznaczanie zamówień wymagających uwagi obsługi.

Zasada: najpierw proces, potem reguły

Automatyzacja odwzorowuje przebieg pracy — nie zastępuje go. Reguły ustawione na procesie, który sam w sobie jest chaotyczny, powielają ten chaos szybciej. Dlatego zaczynamy od ustalenia statusów i kolejności działań, a dopiero potem konfigurujemy automaty.

Wyjątki

Zamówienia nietypowe — z prośbą o zmianę adresu, z częściową wysyłką, z reklamacją — muszą wypadać z automatycznego obiegu i trafiać do obsługi. Reguła bez zdefiniowanych wyjątków prędzej czy później wyśle paczkę pod stary adres.

Uruchamianie etapami

Nowe reguły włączamy pojedynczo i obserwujemy przez kilka dni. Kilka automatyzacji uruchomionych naraz sprawia, że przy pierwszym błędzie nie wiadomo, która za niego odpowiada.

Przegląd

Reguły warto przeglądać co pewien czas — te ustawione pod dawny sposób pracy działają dalej, także wtedy, gdy firma pracuje już inaczej.

Z czego składa się poprawna reguła automatyzacji

Każda reguła powinna mieć jednoznaczny warunek uruchomienia, zestaw czynności do wykonania oraz określone sytuacje, w których nie może zadziałać. Warunek to zdarzenie lub stan zamówienia, na przykład odnotowanie płatności albo przejście do statusu oznaczającego zakończenie kompletowania. Czynność jest skutkiem spełnienia warunku, takim jak utworzenie przesyłki, wysłanie wiadomości lub zmiana statusu. Wyjątek zatrzymuje regułę, gdy zamówienie wymaga decyzji człowieka.

Przed uruchomieniem warto opisać regułę zwykłym zdaniem: „jeżeli wystąpi określone zdarzenie i nie zachodzi żaden wyjątek, system wykonuje wskazane działanie”. Taki zapis ułatwia wychwycenie niejasności. Jeśli nie da się opisać automatyzacji jednym spójnym zdaniem, prawdopodobnie obejmuje ona zbyt wiele przypadków i powinna zostać podzielona na prostsze reguły.

Różne warianty obiegu zamówienia

Zamówienie opłacone z góry może przechodzić inną ścieżkę niż zamówienie pobraniowe. W pierwszym przypadku rozpoczęcie realizacji bywa uzależnione od informacji o płatności. W drugim trzeba sprawdzić, czy wybrana metoda dostawy dopuszcza pobranie oraz czy dane przesyłki są kompletne. Próba obsługi obu wariantów jedną ogólną regułą może prowadzić do zatrzymania poprawnych zamówień albo przedwczesnego przekazania ich do wysyłki.

Osobnego podejścia wymagają zamówienia obejmujące produkty z kilku magazynów. System może przekazać je do jednej realizacji, podzielić na odrębne przesyłki albo skierować do ręcznej oceny. Decyzja powinna odpowiadać rzeczywistej organizacji magazynu i sposobowi komunikowania częściowych wysyłek. Sam fakt obecności wszystkich produktów w ofercie nie oznacza jeszcze, że można je skompletować w jednym miejscu.

Kolejny wariant stanowią zamówienia połączone. Klient może złożyć kilka zamówień, które mają zostać wysłane razem. Automatyczne utworzenie etykiety dla każdego z nich zaraz po wpłynięciu może zamknąć możliwość bezpiecznego połączenia wysyłek. Potrzebny jest więc etap, na którym zamówienie pozostaje otwarte do kontroli, zanim system przekaże dane przewoźnikowi.

Odrębnej ścieżki potrzebują też zamówienia z produktami wykonywanymi na zamówienie, personalizowanymi albo oczekującymi na dostawę. Status „opłacone” nie powinien w takim przypadku automatycznie oznaczać „gotowe do wysłania”. Płatność potwierdza rozliczenie, natomiast dostępność i zakończenie przygotowania produktu są osobnymi warunkami.

Statusy powinny opisywać rzeczywisty etap pracy

Status zamówienia to oznaczenie etapu, na którym znajduje się realizacja. Powinien informować pracowników, co już wykonano i jakie działanie jest następne. Statusy o podobnych nazwach, których znaczenia nie są ustalone, utrudniają budowę reguł. Przykładowo „w realizacji”, „przyjęte” i „przetwarzane” mogą być używane zamiennie przez różne osoby, choć automatyzacja traktuje je jako odrębne stany.

Przydatny jest podział na statusy robocze i końcowe. Status roboczy oznacza, że zamówienie nadal wymaga określonej czynności, na przykład kontroli płatności, kompletowania albo wyjaśnienia danych. Status końcowy wskazuje, że dany proces został zamknięty, na przykład przesyłkę nadano lub zamówienie anulowano. Reguła nie powinna przenosić zamówienia do stanu końcowego, zanim wszystkie wymagane działania rzeczywiście się zakończą.

Należy również ustalić, kto może zmieniać poszczególne statusy ręcznie. Ręczna zmiana może uruchomić tę samą automatyzację, która zwykle reaguje na zdarzenie pochodzące z integracji. Integracja to połączenie BaseLinker z innym systemem, na przykład sklepem, magazynem, przewoźnikiem lub programem księgowym. Jeżeli pracownik nie zna skutków zmiany statusu, może nieświadomie spowodować utworzenie dokumentu, przesyłki albo wiadomości.

Kolejność reguł ma znaczenie

Dwie poprawne reguły mogą dać nieprawidłowy wynik, jeśli uruchamiają się w niewłaściwej kolejności. Przykładem jest wysłanie wiadomości o nadaniu przed skutecznym utworzeniem przesyłki. Sama zmiana statusu może nastąpić prawidłowo, ale wiadomość nie powinna zostać wysłana, dopóki numer przesyłki nie jest dostępny.

Trzeba również uważać na pętlę automatyzacji, czyli sytuację, w której jedna reguła wywołuje zdarzenie uruchamiające kolejną, a ta ponownie uruchamia pierwszą. Nawet jeśli system ogranicza część takich powtórzeń, konfiguracja powinna jednoznacznie prowadzić zamówienie do następnego etapu. Pomaga w tym stosowanie stanów pośrednich oraz warunków sprawdzających, czy dana czynność nie została już wykonana.

Jeśli kilka reguł reaguje na ten sam status, ich zakresy nie powinny się nieświadomie pokrywać. Zamówienie spełniające warunki dwóch automatów może otrzymać sprzeczne działania. Jedna reguła może na przykład kierować je do wysyłki, a druga oznaczać jako wymagające kontroli. Przed wdrożeniem trzeba ustalić, który warunek ma pierwszeństwo i w jaki sposób przypadek nietypowy zostanie zatrzymany.

Błędy podczas samodzielnej konfiguracji

Częstym błędem jest kopiowanie gotowej reguły bez sprawdzenia wszystkich jej warunków. Skopiowany automat zachowuje zależności od statusów, metod dostawy, magazynów i innych elementów konfiguracji. Zmiana samej nazwy nie dostosowuje go do nowego procesu. Każdą kopię trzeba przejrzeć od warunku początkowego aż po ostatnią wykonywaną czynność.

Ryzykowne jest także stosowanie zbyt szerokiego warunku, na przykład obejmującego wszystkie nowe zamówienia niezależnie od źródła, płatności i dostępności produktów. Pozornie upraszcza to konfigurację, lecz przenosi różne przypadki do jednej ścieżki. Bezpieczniejsze są reguły o jasno ograniczonym zakresie, nawet jeśli oznacza to utworzenie kilku automatów.

Inny błąd polega na traktowaniu utworzenia przesyłki jako potwierdzenia jej fizycznego nadania. Utworzenie danych przewozowych i etykiety nie musi oznaczać, że paczka została już odebrana albo przekazana w punkcie przewoźnika. Komunikat wysyłany klientowi powinien odpowiadać rzeczywistemu etapowi realizacji, aby nie zapowiadał nadania przed zakończeniem pracy magazynu.

Problemy powoduje też edytowanie działającej reguły bez zapisania jej dotychczasowej logiki. Po zmianie trudno wtedy ustalić, który warunek odpowiadał za wcześniejsze zachowanie. Przed większą modyfikacją warto opisać stan wyjściowy, cel zmiany oraz przypadki testowe. Przypadek testowy to przykładowe zamówienie o kontrolowanych cechach, na którym można sprawdzić przewidywany przebieg automatyzacji.

Jak testować automatyzację przed pełnym uruchomieniem

Test powinien obejmować nie tylko standardowe zamówienie, ale także sytuacje graniczne. Należy sprawdzić zamówienie opłacone, pobraniowe, anulowane, zawierające brakujący produkt oraz wymagające zmiany danych. Jeśli firma korzysta z kilku kanałów sprzedaży lub magazynów, testy powinny uwzględnić ich różne kombinacje. Celem nie jest wyłącznie potwierdzenie, że reguła działa, lecz również sprawdzenie, czy nie uruchamia się tam, gdzie powinna pozostać nieaktywna.

Wynik testu warto porównać z wcześniej opisanym przebiegiem. Sprawdza się kolejność zmian statusu, zawartość wiadomości, poprawność danych dokumentu oraz moment utworzenia przesyłki. Jeżeli automat korzysta z danych przekazywanych przez integrację, trzeba uwzględnić brak wartości albo jej opóźnione pojawienie się. Reguła nie powinna zakładać, że każda informacja jest dostępna natychmiast.

Po uruchomieniu produkcyjnym, czyli rozpoczęciu pracy na prawdziwych zamówieniach, potrzebna jest obserwacja pierwszych realizacji. Kontrola powinna obejmować zarówno zamówienia przechodzące całą ścieżkę, jak i te zatrzymane jako wyjątki. Nadmierna liczba zatrzymanych spraw może oznaczać, że warunki są zbyt restrykcyjne. Brak wyjątków może natomiast wskazywać, że reguła przepuszcza przypadki wymagające ręcznej decyzji.

Kiedy problem nie wynika z samej automatyzacji

Nie każda nieprawidłowa zmiana statusu oznacza błąd reguły. Przyczyną może być informacja odebrana ze sklepu, marketplace, czyli zewnętrznej platformy sprzedażowej, systemu płatności albo programu magazynowego. Jeśli zewnętrzny system przekazał nieaktualny lub błędny stan, automat mógł prawidłowo zareagować na nieprawidłowe dane wejściowe.

Brak etykiety nie zawsze wynika z warunku automatyzacji. Trzeba sprawdzić kompletność adresu, wybraną usługę przewoźnika, parametry przesyłki oraz działanie połączenia z systemem kurierskim. Podobnie brak dokumentu sprzedaży może być związany z niepełnymi danymi nabywcy albo konfiguracją integracji księgowej, a nie z samym przejściem między statusami.

Opóźniona wiadomość nie musi oznaczać, że automat się nie uruchomił. Konieczne jest rozróżnienie między utworzeniem wiadomości, przekazaniem jej do wysyłki a doręczeniem przez zewnętrzną usługę pocztową. Diagnoza powinna zaczynać się od wskazania ostatniego etapu, który zakończył się prawidłowo. Dopiero wtedy można ustalić, czy problem znajduje się w regule, integracji czy danych zamówienia.

Dodatkowe pytania o automatyzacje BaseLinker

Czy jedna reguła może obsługiwać wszystkie kanały sprzedaży?

Może to być możliwe, jeśli wszystkie kanały przekazują takie same dane i podlegają identycznemu procesowi. W praktyce metody płatności, dostawy, oznaczenia magazynu lub wymagania dotyczące dokumentów często się różnią. Wtedy lepiej rozdzielić reguły według źródła zamówienia albo zastosować warunki, które jednoznacznie rozpoznają dany kanał.

Czy automatycznie utworzona etykieta powinna od razu zmieniać status zamówienia?

Zależy to od przyjętego procesu. Jeśli utworzenie etykiety następuje przed fizycznym spakowaniem towaru, zmiana statusu na oznaczający nadanie byłaby przedwczesna. Bezpieczniej rozdzielić etap przygotowania danych przewozowych od potwierdzenia, że paczka rzeczywiście opuściła magazyn.

Jak postępować z zamówieniem po zmianie adresu przez klienta?

Zmiana adresu powinna zatrzymać automatyczne tworzenie lub dalsze przetwarzanie przesyłki do czasu kontroli. Jeżeli etykieta już powstała, sama aktualizacja danych zamówienia może nie zmienić danych przekazanych przewoźnikowi. Trzeba sprawdzić, czy dotychczasowa przesyłka wymaga anulowania i ponownego utworzenia.

Czy pracownik może ręcznie ominąć automat?

Proces powinien przewidywać kontrolowaną ścieżkę ręczną dla wyjątków. Nie powinna ona jednak polegać na przypadkowej zmianie statusów. Potrzebny jest jasno nazwany status przeznaczony do weryfikacji oraz ustalenie, jaka czynność przywraca zamówienie do automatycznego obiegu.

Po czym poznać, że reguły wymagają przebudowy?

Sygnałem są powtarzające się ręczne poprawki, zamówienia cofane między statusami, wiadomości wysyłane w niewłaściwym momencie oraz wyjątki obsługiwane poza ustaloną ścieżką. Pojedynczy nietypowy przypadek nie musi uzasadniać przebudowy. Jeśli jednak pracownicy regularnie obchodzą automat, konfiguracja przestała odpowiadać rzeczywistemu procesowi.

Dokumentacja ułatwia bezpieczne zmiany

Dla każdej reguły warto zapisać jej cel, warunek uruchomienia, wykonywane działania, wyjątki oraz osobę odpowiedzialną za proces. Przydatna jest również informacja, które inne reguły mogą uruchomić się po zmianie statusu. Taka dokumentacja nie musi być rozbudowana. Powinna jednak pozwalać zrozumieć konfigurację bez odtwarzania jej metodą prób.

Opis trzeba aktualizować po zmianach w magazynie, sposobach płatności, przewoźnikach, systemie księgowym lub kanałach sprzedaży. Automatyzacja jest częścią procesu firmy, dlatego wymaga kontroli podobnie jak inne procedury operacyjne. Dobrze opisana konfiguracja pozwala szybciej rozpoznać skutki planowanej zmiany i ogranicza ryzyko, że poprawa jednego etapu zakłóci kolejny.

Automatyzacja powinna pozostawiać miejsce na decyzję

Dobrze skonfigurowany BaseLinker przejmuje czynności powtarzalne, ale nie ukrywa zamówień nietypowych. Najważniejszy efekt to przewidywalny obieg: standardowe sprawy przechodzą kolejne etapy bez zbędnej pracy ręcznej, a wyjątki trafiają do właściwej osoby z czytelną informacją o przyczynie zatrzymania. Taka konfiguracja nie polega na uruchomieniu możliwie największej liczby reguł. Polega na świadomym rozdzieleniu czynności, które można bezpiecznie wykonać automatycznie, od tych, które wymagają sprawdzenia.