Wyobraźmy sobie klienta, który zamawia produkt w sklepie internetowym, wybiera odbiór w salonie, a później pyta o wymianę w innej placówce. Z jego perspektywy to kontakt z jedną marką. Firma musi natomiast powiązać zamówienie, rezerwację towaru, wydanie i dalszą obsługę, choć poszczególne czynności mogą odbywać się w różnych narzędziach. Projekt integracji warto zacząć od tej drogi, zanim powstanie lista połączeń między systemami.

Sprzedaż w kilku miejscach nie daje jeszcze odpowiedzi na pytanie, czy każdy kanał pracuje na tych samych zasadach. Trzeba je określić: co oznacza dostępność, kiedy towar zostaje zarezerwowany i gdzie pracownik sprawdzi stan realizacji. Właśnie w tych ustaleniach spotykają się technologia oraz codzienna obsługa klienta.

Wspólny model zamówienia, różne miejsca pracy

ERP może pełnić rolę środowiska łączącego informacje o sprzedaży, zapasach i rozliczeniach. Nie oznacza to jednak, że każdy ekran sklepu, stanowiska sprzedażowego czy magazynu musi zostać zastąpiony jednym interfejsem. W projekcie należy ustalić, które narzędzie odpowiada za daną czynność oraz jakie informacje ma przekazać dalej. Ważniejsze od liczby połączeń jest to, czy razem obsłużą uzgodniony przebieg zamówienia.

Dobrym początkiem jest słownik statusów z opisem zdarzenia, które powoduje każdą zmianę. „Przyjęte”, „opłacone”, „gotowe do odbioru” i „wydane” nie powinny być używane zamiennie. Przy każdym etapie wskaż, kto lub co potwierdza jego zakończenie. Ustal również, która informacja trafia do klienta. Jeśli magazyn przygotował paczkę, ale nie przekazał jej przewoźnikowi, komunikat powinien odpowiadać rzeczywistemu etapowi. Rozróżnienie ma znaczenie także wewnątrz firmy: osoba odpowiadająca na pytanie klienta potrzebuje czytelnej informacji, a nie domysłu opartego na nazwie statusu w obcym narzędziu.

Osobno opisz relację między zapasem fizycznym a ilością, którą można zaoferować. Zgodnie z zasadami firmy odrębnie potraktuj rezerwacje, towar zatrzymany do wyjaśnienia i produkty przeznaczone do innego zamówienia. Nie należy ukrywać tych decyzji w ogólnym określeniu „stan magazynowy”.

Przy prezentacji rozwiązania poproś o pokazanie jednego zamówienia w widoku sklepu, salonu i magazynu. Zespół powinien rozumieć, które dane są wspólne, a które służą tylko lokalnemu zadaniu. Jeżeli obsługa wymaga ręcznego przepisywania identyfikatora między narzędziami, warto nazwać tę czynność i zdecydować, czy pozostaje w docelowym procesie.

Dostępność produktu wymaga reguł wymiany danych

Przed rozmową o częstotliwości synchronizacji trzeba ustalić źródło informacji o produkcie. Nazwa handlowa nie zawsze wystarczy do powiązania kartotek: znaczenie mogą mieć wariant, rozmiar, kolor lub jednostka sprzedaży. Wybierz identyfikator, którego użyją połączone narzędzia, i zapisz zasady dodawania oraz zmiany produktu. Bez uzgodnienia tych reguł zespół może inaczej interpretować dane wysłane przez poprawnie działające połączenie.

Kolejna decyzja dotyczy rezerwacji. W hipotetycznym przypadku jeden egzemplarz jest dostępny w salonie i widoczny w sklepie internetowym. Projekt powinien rozstrzygnąć, co stanie się, gdy klient w placówce poprosi o jego zakup, a w tym samym czasie wpłynie zamówienie z sieci. Nie chodzi o założenie, że każda firma ma taki sam model. Chodzi o przetestowanie własnych zasad przed udostępnieniem usługi klientom. Możesz określić, kiedy powstaje rezerwacja, jak długo obowiązuje i kto może ją zwolnić. Te decyzje powinny być czytelne również dla pracownika obsługującego wyjątek, na przykład nieodebrany produkt.

W opisie integracji uwzględnij czas przekazania danych oraz sposób rozpoznawania problemu. Gdy dane nie dotarły, pracownik potrzebuje odpowiedzi, czy może przyjąć zamówienie i gdzie sprawdzi aktualny stan. Samo zadeklarowanie automatycznej synchronizacji nie rozstrzyga takiej sytuacji.

Do testów można wykorzystać trzy scenariusze:

• równoczesny zakup tego samego wariantu w dwóch kanałach oraz sprawdzenie wyniku rezerwacji;
• brak potwierdzenia odbioru danych i ponowne przekazanie wiadomości, z kontrolą, czy nie powstał drugi dokument;
• anulowanie zamówienia po rezerwacji i sprawdzenie, kiedy produkt ponownie pojawi się w ofercie.

Test powinien zakończyć się wskazaniem wyniku w każdym narzędziu, a nie tylko komunikatem, że wymiana została wykonana. Warto zachować identyfikatory użytego zamówienia oraz zapis tego, co potwierdził sklep, ERP i magazyn. Dzięki temu można odtworzyć rozbieżność bez przeszukiwania całej historii sprzedaży.

Zwrot i odbiór w salonie należą do tego samego procesu

W projekcie wielokanałowym trzeba uwzględnić działania po złożeniu zamówienia. Jeśli firma dopuszcza odbiór lub obsługę zwrotu w placówce, pracownik powinien móc ustalić, której transakcji dotyczy zgłoszenie oraz jakie czynności przewidują zasady organizacji. Zakres dostępnych usług, sposób rozliczenia i wymagania formalne trzeba ustalić dla własnej działalności; integracja nie tworzy ich automatycznie.

Warto sprawdzić, co dzieje się z produktem po oddaniu go do salonu. Przyjęcie fizyczne, ocena stanu, decyzja o dalszym przeznaczeniu i aktualizacja dostępności to różne momenty. Zespół może potrzebować odrębnego statusu, zanim towar ponownie będzie oferowany. Podczas analizy ustal, kto odpowiada za każdy etap i jak informacja dotrze do magazynu oraz osób prowadzących rozliczenie. Do testu wybierz również sytuację, w której zwrócono tylko część zamówienia. Zobacz wtedy, czy pracownik potrafi powiązać produkty z właściwą transakcją bez ręcznego odtwarzania jej przebiegu z kilku wydruków.

Przykłady łączenia handlu internetowego i stacjonarnego pojawiają się w kampanii Streamsoft z udziałem Sportano i Lilou, opisanej przez Puls Biznesu: https://www.pb.pl/klienci-w-centrum-kampanii-telewizyjnej-streamsoft-1268671. Producent przedstawia Verto jako ERP dla nowoczesnego handlu. Dla firmy planującej projekt takie przykłady mogą być punktem wyjścia do rozmowy o własnym modelu sprzedaży.

Najbardziej użyteczna demonstracja powinna pokazywać obsługę konkretnej sytuacji klienta. Same osobne prezentacje modułów nie wyjaśnią, jak dane przejdą od przyjęcia zamówienia do zakończenia jego obsługi.

Uruchomienie połączeń i dalsza odpowiedzialność

Przed startem wybierz grupę scenariuszy, które zespół przeprowadzi od początku do końca. Oprócz zwykłego zakupu uwzględnij zdarzenia wymagające decyzji pracownika. Określ oczekiwany wynik, dopuszczalny czas aktualizacji i osobę zatwierdzającą test. Nie muszą to być te same kryteria dla wszystkich informacji: zmiana opisu produktu może mieć inne znaczenie operacyjne niż rezerwacja ostatniego egzemplarza.

Warto także uzgodnić miejsce zgłaszania błędów i podział odpowiedzialności między dostawcami. Jeżeli sklep, ERP i rozwiązanie magazynowe obsługują różne zespoły, zgłoszenie powinno zawierać dane pozwalające powiązać zdarzenie po każdej stronie. Numer zamówienia, czas operacji i opis oczekiwanego wyniku są praktycznym początkiem. Z góry ustal, kto prowadzi sprawę do wyjaśnienia, zamiast pozostawiać pracownika z kilkoma kontaktami bez wskazania kolejnego kroku.

Po zmianie któregoś narzędzia wróć do scenariuszy dotyczących wspólnego procesu. Aktualizacja jednego elementu powinna być oceniona również z perspektywy pozostałych miejsc pracy. Utrzymanie takiego zestawu testów pomaga sprawdzić, czy klient nadal może przejść uzgodnioną drogę zakupu, a pracownik widzi informacje potrzebne do obsługi jego sprawy.

Artykuł partnera