Przykład automatyzacji przepływu zamówień w sklepie internetowym

Zamówienie ze sklepu internetowego jest otrzymywane, a następnie ktoś przekazuje dane do magazynu za pomocą e-maila lub Excela. Kolega sprawdza płatność, przepisuje dane do faktury, tworzy etykietę, zmienia status i w końcu próbuje powiadomić klienta. To działa, dopóki jest to kilka zamówień dziennie. przykład automatyzacji przepływu zamówień w sklepie internetowym staje się naprawdę przydatny, gdy wzrost oznacza więcej ręcznych kroków, więcej wyjątków i coraz trudniej śledzić odpowiedzialności.

Problem zazwyczaj nie polega na braku aplikacji. Raczej na tym, że to ludzie utrzymują przepływ informacji między sklepem internetowym, ERP, systemem magazynowym, fakturowaniem i usługą kurierską. Jeśli zamówienie utknie, często dowiadujemy się o tym dopiero, gdy obsługa klienta otrzyma reklamację. W takim przypadku warto zacząć nie od narzędzia do automatyzacji, ale od pytania: co dokładnie dzieje się z zamówieniem od momentu płatności do przekazania?

Gdzie przerywa się ścieżka zamówienia?

W przypadku średniej wielkości sprzedawcy przetwarzanie zamówień rzadko jest jednym procesem. Inna ścieżka może dotyczyć zamówień dostępnych w magazynie, zamówień wstępnych, za pobraniem, z fakturą firmową lub odbiorem osobistym. Pakiety promocyjne, częściowe dostawy, zwroty i błędy adresowe zwiększają liczbę wariantów.

Dlatego pierwszym błędem często jest próba traktowania wszystkich zamówień w ten sam sposób. W rzeczywistości celem nie jest, aby system ślepo przekazywał wszystkie dane, ale aby częste, jednoznaczne przypadki były przetwarzane automatycznie, a niepewne lub wrażliwe biznesowo przypadki trafiały do odpowiedniej osoby.

Warto prześledzić konkretne zamówienie, nie tylko na ekranach systemów, ale także w rzeczywistej pracy. Kto decyduje o różnicy w płatności? Skąd magazyn wie, że pozycja jest nadal dostępna? Kiedy tworzona jest faktura? Co się dzieje, jeśli firma kurierska nie akceptuje adresu? Jeśli odpowiedzi na te pytania pochodzą z ustnych przekazów lub z pamięci doświadczonego kolegi, proces nie jest jeszcze wystarczająco kontrolowany.

Przykład automatyzacji przepływu zamówień w sklepie internetowym

Załóżmy, że zamówienia ze sklepu internetowego są obecnie ręcznie rejestrowane w ERP. Magazyn pracuje na tej podstawie, faktura jest tworzona w trzecim systemie, a etykiety wysyłkowe są tworzone na osobnym interfejsie. Status zamówienia w sklepie internetowym często jest aktualizowany z opóźnieniem, dlatego obsługa klienta również telefonicznie pyta o magazyn.

W tej sytuacji niekoniecznie nowy sklep internetowy lub całkowita wymiana ERP jest dobrym pierwszym krokiem. Mniejsza, dobrze określona zmiana może polegać na tym, że zatwierdzone zamówienie automatycznie tworzy lub aktualizuje odpowiedni rekord zamówienia w ERP. ERP pozostaje centralnym rejestrem realizacji biznesowej: stąd pochodzą dane dotyczące zapasów, fakturowania i decyzji o wysyłce.

Gdy zamówienie jest gotowe do przetworzenia, system magazynowy otrzymuje zadanie kompletacji. Po skompletowaniu paczki dane wysyłkowe trafiają do połączenia kurierskiego, etykieta wraca do magazynu, a identyfikator paczki i odpowiedni status są aktualizowane w sklepie internetowym. Klient jest informowany nie na podstawie ręcznie skomponowanego e-maila, ale na podstawie rzeczywistych zdarzeń realizacji.

Logika procesu może być krótko zorganizowana wokół pięciu stanów:

• zamówienie otrzymane i technicznie ważne;
• płatność lub zatwierdzenie biznesowe sprawdzone;
• zapasy zarezerwowane i utworzone zadanie realizacji;
• paczka gotowa do przekazania lub przekazana przewoźnikowi;
• realizacja zamknięta, niezbędne dane finansowe i komunikacyjne z klientem zarejestrowane.

Nazwy statusów mogą się różnić w zależności od firmy. Ważne jest, aby każdy stan miał jednoznaczne znaczenie biznesowe, odpowiedzialnego i źródło systemowe. Na przykład „w trakcie przetwarzania” nie jest dobrym stanem, jeśli raz oznacza, że czeka się na płatność, a innym razem, że paczka jest już w magazynie.

Automatyzacja nie polega na usuwaniu wyjątków

W przepływie zamówień zawsze będą wyjątki. Produkt może się wyczerpać, potwierdzenie bankowe może się opóźnić, adres może być niekompletny lub klient może chcieć połączyć kilka zamówień. Nie warto ukrywać ich za automatycznym procesem.

Dobre rozwiązanie rozpoznaje, że dane zamówienie nie może bezpiecznie przejść dalej, zatrzymuje je w odpowiednim momencie i tworzy zadanie. Zadanie musi być widoczne: kto je otrzymuje, na podstawie jakich informacji podejmuje decyzję, jak długo czeka zamówienie i co się dzieje po podjęciu decyzji. To nie jest szczegół administracyjny. Jeśli obsługa wyjątków staje się poszukiwaniem e-maili, automatyzacja tylko szybciej generuje niepewność.

Szczególną uwagę zasługują częściowe błędy. Może się zdarzyć, że zamówienie zostało utworzone w ERP, ale zadanie magazynowe nie. Lub etykieta wysyłkowa została utworzona, ale sklep internetowy nie otrzymał identyfikatora śledzenia. W takim przypadku system nie powinien generować duplikatów zamówień, faktur ani etykiet.

Dlatego w technicznym projektowaniu potrzebne są unikalne identyfikatory, powtarzalne przetwarzanie i rejestrowanie. Mówiąc prosto: później również trzeba móc powiedzieć, który system, kiedy, jakie dane przekazał i dlaczego proces się zatrzymał. To część kontroli operacyjnej, a nie tylko kwestia dla deweloperów.

Który system mówi prawdę?

Wiele błędów zamówień wynika z tego, że te same dane są edytowane w wielu miejscach. Adres jest zmieniany w sklepie internetowym, ale w ERP pozostaje stary. Magazyn pracuje na podstawie tabeli, podczas gdy zapasy już się zmieniły. Fakturujący używa innych danych klienta niż te, które widzi obsługa klienta.

Dla każdego istotnego danych warto wyznaczyć wiodący system. W przypadku katalogu produktów, cen, danych klienta, zapasów, statusu zamówienia i danych faktury niekoniecznie będzie to to samo źródło. To jest w porządku, jeśli zasada jest wyraźna i synchronizacja ją przestrzega.

Zapasy są szczególnie wrażliwym obszarem. W sprzedaży internetowej nie zawsze fizyczne zapasy magazynowe są zapasami możliwymi do sprzedaży. Należy uwzględnić już zarezerwowane ilości, produkty pod kontrolą jakości, towary w trakcie przenoszenia i czasami zapasy oczekiwane z zaopatrzenia. Jeśli ta różnica nie zostanie wyjaśniona, zautomatyzowane przekazywanie zamówień może prowadzić do nadmiernej sprzedaży lub nieuzasadnionego zatrzymania.

Pomiar to nie tylko tworzenie raportów po fakcie

Zautomatyzowany przepływ zamówień przynosi wartość menedżerską, jeśli czyni działanie widocznym. Nie wystarczy wiedzieć, ile zamówień przyszło. Warto obserwować, ile czasu mija między zamówieniem a wydaniem magazynowym, ile zamówień czeka na obsługę wyjątków, który błąd się powtarza i gdzie gromadzi się praca.

Te dane często ujawniają niewygodne pytania. Może się okazać, że to nie integracja jest wolna, ale codzienne zatwierdzanie faktur opóźnia zamówienia. Może też się okazać, że magazyn nie otrzymuje wystarczająco wcześnie informacji o kampaniach. Celem pomiaru nie jest kontrola kolegów, ale zrozumienie, gdzie warto zmienić proces.

Podczas wdrażania warto zacząć od dobrze określonego typu zamówienia. Na przykład zamówienia dostępne w magazynie, opłacone z góry, z dostawą krajową. Zazwyczaj można je dobrze regulować, a na podstawie doświadczeń można doprecyzować statusy, pola danych, zasady obsługi błędów. Następnie można włączyć bardziej złożone przypadki.

Stopniowe podejście niekoniecznie spowalnia rozwój. Raczej zmniejsza szansę na trwałe wprowadzenie źle zrozumianego procesu do systemów. W podejściu CGAT integracja i automatyzacja są wartościowe, jeśli za nimi kryje się bardziej przejrzysty, mierzalny i zrównoważony porządek pracy.

Dobre pierwsze pytanie nie brzmi więc, które narzędzie łączy sklep internetowy z ERP. Raczej, jeśli jutro przyjdzie dwa razy więcej zamówień, na którym etapie firma straci kontrolę. Tam warto najpierw uporządkować.