Najpierw opisz pracę wykonywaną ręcznie
Przez kilka dni zbieraj przykłady powtarzalnych czynności: sprawdzanie płatności, zmiana statusu, przepisywanie danych, wybór dostawy czy informowanie klienta. Zapisuj także sytuacje, w których pracownik musi podjąć decyzję. Lista samych kliknięć nie pokaże wszystkich zależności.
Wybierz jeden powtarzalny proces, którego wynik da się sprawdzić. Na start może to być skierowanie kompletnego zamówienia do realizacji. Ustal, co znaczy „kompletne”: czy są produkty, dane dostawy i właściwy sposób rozliczenia płatności.
Wspólne etapy, różne źródła zamówień
Zamówienia ze sklepu i marketplace mogą przechodzić przez wspólny proces magazynowy, ale nie zawsze dostarczają dane w tej samej chwili. Dlatego reguła nie powinna zakładać, że pojawienie się zamówienia oznacza gotowość do wysyłki.
Przy projektowaniu warto rozdzielić etapy: przyjęcie, sprawdzenie danych, oczekiwanie na warunki realizacji, kompletacja, pakowanie i wysyłka. Nazwy statusów są wtórne wobec tego, co rzeczywiście oznaczają dla zespołu.
Reguła powinna mieć jasny początek i rezultat
Dla każdej automatyzacji opisz zdarzenie, warunki, działanie i obsługę błędu. Przykład koncepcyjny: po uzupełnieniu danych sprawdź warunki realizacji, a zamówienie spełniające zasady skieruj do kolejnego etapu. Konkretną konfigurację trzeba dopasować do możliwości wybranego narzędzia.
Sellasist opisuje automatyzację jako wykonywanie działań po spełnieniu ustalonych warunków; przykłady obejmują zmianę statusu i komunikację. Base również udostępnia akcje oparte na zdarzeniach. Nie przenoś jednak reguł między systemami wyłącznie według podobnej nazwy — sprawdź dostępne warunki i moment wywołania.
Wyjątki zaplanuj przed uruchomieniem
Zamówienie pobraniowe nie przechodzi tej samej ścieżki płatności co przedpłata. Brak produktu, zmiana adresu czy anulowanie po rozpoczęciu realizacji również wymagają osobnych ustaleń. Automatyzacja może wskazać wyjątek pracownikowi, zamiast próbować rozstrzygnąć go samodzielnie.
W dokumentacji Base zwrócono uwagę m.in. na moment pobrania formularza dostawy i różnicę między opłaceniem zamówienia a obsługą pobrania. To przykład, dlaczego trzeba badać dostępność danych w chwili uruchomienia akcji.
Testuj także ponowne wykonanie i błędy
Sprawdź standardowe zamówienie, ale również brak danych, powtórne zdarzenie i zmianę decyzji klienta. Zweryfikuj, czy dwie reguły nie uruchamiają tej samej operacji oraz czy proces nie wraca w pętli do poprzedniego etapu.
Dla każdego testu zapisz wynik oczekiwany, rzeczywisty i warunek zaliczenia. Jeśli akcja zleca operację w zewnętrznym systemie, ustal sposób kontroli odpowiedzi i zachowanie po błędzie. Sama zmiana statusu nie dowodzi, że zewnętrzna czynność została wykonana.
Mierz efekt i zostaw czytelny opis
Po uruchomieniu porównaj czas ręcznej obsługi i liczbę wyjątków w podobnym okresie oraz przy zbliżonej strukturze zamówień. Nie zakładaj z góry określonego procentu oszczędności. Gdy wzrasta liczba błędów, sprawdź ich przyczynę przed dodawaniem kolejnych reguł.
Każda reguła powinna mieć zrozumiałą nazwę, opis celu i właściciela procesu. W większym środowisku taka dokumentacja ułatwia zmianę konfiguracji i wdrażanie pracowników. Kolejne obszary automatyzuj dopiero wtedy, gdy poprzedni etap jest sprawdzony.
Dokumentacja i dalsza lektura
Zakres funkcji sprawdzaj dla używanej wersji i integracji. Poradnik opisuje sposób planowania prac, nie zastępuje analizy Twojej konfiguracji.