W skrócie
Analiza przedwdrożeniowa jest pierwszym etapem wdrożenia Studio RMA.net i trwa 3-5 dni od podpisania umowy. W rozmowach z działami opisujemy drogę reklamacji od przyjęcia do odpowiedzi dla klienta, a dla typów spraw ustalamy progi SLA. Wynikiem jest zatwierdzony opis ścieżki reklamacyjnej, który wyznacza konfigurację programu i zakres danych z ERP. Zmiana zasad po zatwierdzeniu cofa wdrożenie do konfiguracji, dlatego spory między działami rozstrzygamy już w analizie.
Miejsce analizy w harmonogramie wdrożenia
Analiza przedwdrożeniowa otwiera wdrożenie Studio RMA.net i trwa 3-5 dni od podpisania umowy. Po niej przez 1-2 tygodnie konfigurujemy program, a następnie łączymy go z danymi firmy. Testy i szkolenia zamykają wdrożenie, które w standardowym harmonogramie trwa 4-8 tygodni. Analiza zajmuje z tego najwyżej tydzień roboczy, ale jej wynik wyznacza zakres pracy we wszystkich kolejnych etapach.
Przed umową firma ogląda bezpłatne demo online i dostaje wycenę, zwykle w ciągu dwóch dni roboczych od zapytania. Cennik wycenia wdrożenie osobno od licencji, a analiza należy do prac wdrożeniowych. Rozmowy z pracownikami i wgląd w dokumenty firmy zaczynamy dopiero po podpisaniu umowy. Wszystkie etapy razem z podziałem zadań opisujemy na stronie o etapach wdrożenia systemu reklamacyjnego.
Analiza nie ocenia opłacalności zakupu ani nie porównuje programów różnych dostawców, bo firma podjęła już decyzję. Jej przedmiotem jest proces reklamacyjny firmy, a nie wybór narzędzia. Firma, która dopiero wybiera program, zaczyna od specyfikacji wymagań dla systemu reklamacji i od demo. Spisane wcześniej wymagania skracają potem rozmowy w analizie, bo część odpowiedzi jest już gotowa.
Rozmowy z działami i dokumenty firmy
Analizę prowadzimy w rozmowach z osobami, które na co dzień obsługują reklamacje. Z każdym działem rozmawiamy osobno, bo obsługa klienta i serwis opisują tę samą sprawę z innej strony. Według opisów wcześniejszych wdrożeń konsultanci zbierali wymagania na miejscu u klienta, a ich dokumentacja była projektem dla wdrożeniowców. Tematy rozmów zestawiamy w tabeli:
| Temat rozmowy | Uczestnicy po stronie firmy | Materiały od firmy | Wynik w konfiguracji |
|---|---|---|---|
| Przyjęcie i ocena zgłoszeń | Obsługa klienta i serwis | Obecna procedura, przykłady spraw | Statusy i kierowanie spraw do działów |
| Terminy odpowiedzi | Właściciel procesu i dział handlowy | Umowy z kontrahentami, lista spraw po terminie | Progi SLA dla typów reklamacji |
| Korespondencja z klientem | Obsługa klienta | Wzory pism i wiadomości | Szablony SMS i e-mail |
| Użytkownicy | Kierownicy działów, dział IT | Lista osób z działami | Role użytkowników i logowanie przez Active Directory |
| Dane i raporty | Osoba znająca ERP, kierownictwo | Kartoteki, raporty używane dziś | Zakres integracji z ERP albo wymiany plikowej |
Firma przygotowuje na rozmowy obecną procedurę reklamacyjną i wzory pism wysyłanych klientom. Najwięcej mówią jednak sprawy z ostatnich miesięcy: typowa naprawa, reklamacja nieuznana, sprawa po terminie i zgłoszenie od partnera B2B. Na każdej z nich sprawdzamy, czy procedura na papierze zgadza się z tym, jak dział naprawdę pracuje. Zadania firmy przed startem prac opisujemy przy przygotowaniu firmy do wdrożenia systemu reklamacji.
Rozbieżności między procedurą a praktyką zapisujemy w rejestrze ustaleń razem z osobą, która ma je rozstrzygnąć. Rozstrzyga właściciel procesu, bo tylko on odpowiada za całą ścieżkę, a nie za jeden dział. Wpis w rejestrze zamykamy dopiero decyzją, a nie samą rozmową. Otwarte pozycje przeglądamy na koniec każdego dnia analizy.
Ścieżka reklamacji od zgłoszenia do zamknięcia
Ścieżkę reklamacyjną opisujemy na przykładzie jednej sprawy, od chwili zgłoszenia do zamknięcia. Dla każdego kroku zapisujemy wykonawcę oraz zdarzenie, po którym sprawa przechodzi dalej. Na tym etapie nie rozmawiamy jeszcze o ekranach programu, tylko o pracy działu. Pytamy o cztery punkty decyzyjne:
- Przyjęcie - kto rejestruje zgłoszenie i jakim kanałem, np. formularzem na stronie firmy albo po rozmowie telefonicznej.
- Ocena - kto ocenia wadę i kiedy sprawa trafia do serwisu albo do rzeczoznawcy.
- Decyzja - kto uznaje albo odrzuca reklamację i czy potrzebna jest zgoda kierownika.
- Informacja - kiedy klient dostaje wiadomość o decyzji i czy dostaje ją SMS-em albo e-mailem.
Starsze opisy programu wymieniają kilka kanałów przyjęcia, m.in. formularz WWW, e-mail, telefon i wizytę w punkcie. Reklamację z e-maila rejestruje pracownik, a formularz tworzy zgłoszenie bez jego udziału. Program kieruje nowe zgłoszenie do właściwego działu, np. serwisu albo obsługi klienta, więc punkt przyjęcia wyznacza też pierwszy dział na ścieżce. Przekazania między działami zaznaczamy osobno, bo w tych miejscach sprawa zmienia osobę odpowiedzialną.
Opis ścieżki przekładamy potem na statusy i stany programu. Stany Nowa, W realizacji, Rozpatrzona, Zamknięta i Anulowana wyznaczają etapy sprawy, a statusy nazywamy tak, jak dział mówi o sprawach na co dzień. Demo ma jedenaście statusów dla sieci sklepów z centralą, m.in. Opinia sklepu i Wysłanie do centrali. Firma bez centrali ich nie potrzebuje, za to może potrzebować statusu na oczekiwanie na część albo na odpowiedź dostawcy. Zasady spisania procedury opisujemy przy procedurze reklamacyjnej w firmie.
Progi SLA dla typów reklamacji
Progi SLA ustalamy osobno dla każdego typu reklamacji, bo terminy mają różne źródła. Na reklamację konsumenta sprzedawca odpowiada w 14 dni od jej otrzymania, a brak odpowiedzi w tym terminie oznacza uznanie reklamacji. W sprawach między firmami przepisy nie narzucają terminu odpowiedzi, z wyjątkiem przedsiębiorcy na prawach konsumenta. Termin wynika wtedy z umowy z kontrahentem albo z wewnętrznej procedury.
Dla każdego typu zapisujemy dwie wartości, a różnicę między nimi nazywamy rezerwą terminu. Rezerwa zostawia czas na decyzję i wiadomość do klienta, gdy ocena wady się przedłuży. Obie wartości zapisujemy w opisie ścieżki:
- Termin zewnętrzny - wynika z przepisów albo z umowy i obowiązuje wobec klienta.
- Próg wewnętrzny - krótszy termin dla działu, po którym kierownik sprawdza, dlaczego sprawa czeka.
Próg wewnętrzny uruchamia reakcję kierownika, zanim sprawa dojdzie do terminu wobec klienta.
Termin kończący się w sobotę albo w dzień ustawowo wolny od pracy upływa następnego dnia roboczego. W analizie ustalamy więc, czy program ma liczyć termin z uwzględnieniem dni wolnych, jak w jednym z wdrożeń opisanych w referencji z 2023 roku. Cennik wymienia reguły terminów i eskalacji wśród czynników, od których zależy kwota, dlatego ich zakres zamykamy przed konfiguracją. Priorytety i progi opisujemy szerzej przy priorytetach zgłoszeń i SLA w reklamacjach.
Kolumna Dni na listach pokazuje liczbę dni do terminu rozpatrzenia, a wartości ujemne oznaczają sprawy po terminie. Na liście z 2019 roku 7 dni ma żółte tło, a 0 czerwone. Progi kolorów sprawdzamy w demo, zanim dopasujemy do nich progi wewnętrzne. Typy spraw opisujemy przy rodzajach reklamacji i polu Typ reklamacji.
Dane w zgłoszeniu a raporty dla kierownictwa
Zakres danych w formularzu zgłoszenia ustalamy od końca, czyli od raportów, które kierownictwo będzie czytać. Raport Reklamacje wg dostawców pokaże pełny obraz tylko wtedy, gdy kartoteka łączy artykuły z dostawcami. Statystyki wg uszkodzeń artykułów wymagają z kolei spójnego opisu przyczyny reklamacji. Dlatego w analizie przeglądamy z kierownictwem listę raportów i dla każdego wskazujemy pola, bez których wynik będzie niepełny.
Pola obowiązkowe mają w formularzu pomarańczowy znacznik, a kontrahenta i asortyment pracownik wybiera z kartotek. Każde pole obowiązkowe wydłuża rejestrację sprawy, więc wybieramy tylko pola wymagane przez raporty albo procedurę. Pozostałe dane pracownik uzupełnia w trakcie sprawy, np. po ocenie serwisu. Listę pól obowiązkowych zatwierdza właściciel procesu razem z liderem obsługi klienta.
Asortyment i kontrahenci trafiają do programu z ERP, a zakres tej wymiany ustalamy w analizie. Integracje z SAP, Microsoft Dynamics, Comarch ERP XL i enova 365 potwierdzają strona produktu i referencje. Bez połączenia w czasie rzeczywistym kartoteki przechodzą przez wymianę plikową: import kartotek magazynowych i kontrahentów oraz eksport reklamacji i usług serwisowych. Przed pierwszą wymianą sprawdzamy, czy artykuły mają indeks, numer katalogowy, producenta i czas gwarancji. Wymieniane dane opisujemy przy integracji programu do reklamacji z ERP.
Model działania, czyli chmurę prywatną Cloud RMA albo instalację na serwerze firmy, firma wybiera przed wyceną. W analizie ustalamy tylko szczegóły, które z niego wynikają, np. dostęp do ERP z serwerowni firmy. Przy instalacji lokalnej w rozmowach bierze udział administrator serwera firmy.
Role użytkowników i wiadomości do klientów
Listę użytkowników zbieramy razem z działami i zakresem pracy każdej osoby. Według starszej dokumentacji konto ma rolę i kod oddziału, a większość uprawnień wynika z roli. Dlatego w analizie przypisujemy osoby do ról, a nie opisujemy uprawnień każdej z nich osobno. Z działem IT ustalamy, czy pracownicy logują się kontami z sieci firmowej przez Active Directory.
Wgląd w sprawy innych działów zapisujemy w opisie ról razem z zastępstwami na czas urlopów. Kierownik działu potrzebuje zwykle obrazu wszystkich spraw działu, a pracownik przyjęć przede wszystkim nowych zgłoszeń. Zakres widoczności dla ról i oddziałów sprawdzamy w demo przed konfiguracją, bo dokumentacja go nie opisuje.
Wiadomości do klientów omawiamy z działem obsługi klienta, bo to on odpowiada za ich treść. Program wysyła SMS albo e-mail przy zmianie statusu, a pracownik może też wysłać wiadomość ręcznie przyciskiem Wyślij. W analizie rozdzielamy więc dwa rodzaje wiadomości:
- Wiadomość przy zmianie statusu - wychodzi bez udziału pracownika, więc jej treść musi pasować do każdej sprawy w danym statusie.
- Wiadomość wysyłana ręcznie - według opisu okna e-mail pracownik zaczyna od gotowego szablonu i dopisuje szczegóły sprawy.
Klient B2C dostaje e-mail przy każdej zmianie statusu, od przyjęcia do zakończenia sprawy. Dlatego przy każdym statusie sprawdzamy, co z jego nazwy i treści wiadomości zrozumie klient. Wzory obecnych pism firma przekazuje w analizie, a treść szablonów zatwierdza przed testami. Na formularzu klient wybiera powiadomienie SMS albo e-mail, więc szablon przygotowujemy w obu wersjach.
Menu Historia pokazuje wysłane wiadomości w pozycjach Wysłane e-mail i Wysłane SMSy. W testach sprawdzamy tam, czy każda zmiana statusu wysłała właściwy szablon. Błędy w treści poprawiamy przed szkoleniem, bo po starcie każda pomyłka trafia od razu do klientów.
Wynik analizy i zmiany po zatwierdzeniu
Wynikiem analizy jest zatwierdzony opis ścieżki reklamacyjnej i progów SLA. Opis zatwierdza właściciel procesu, a my traktujemy go jako projekt dla konfiguracji. Zawiera cztery części:
- Ścieżka reklamacyjna - punkty decyzyjne na drodze sprawy i lista statusów, które je odzwierciedlają.
- Progi SLA - termin zewnętrzny i próg wewnętrzny dla każdego typu reklamacji.
- Role i wiadomości - przypisanie osób do ról oraz treść szablonów SMS i e-mail.
- Dane i integracje - pola obowiązkowe formularza oraz zakres wymiany danych z ERP.
Według opisu przez 1-2 tygodnie konfigurujemy program, a szczegóły tego etapu przedstawiamy przy konfiguracji programu do reklamacji przy wdrożeniu. Opis wraca potem w testach, bo sprawy testowe prowadzimy według zapisanej w nim ścieżki. Zakres sprawdzeń opisujemy przy testach systemu reklamacji przed uruchomieniem. We wcześniejszych wdrożeniach zakres zmian wskazanych w analizie trafiał do wyceny, zanim ruszyły prace.
Zmiana zasad po zatwierdzeniu opisu cofa wdrożenie do konfiguracji, a po starcie testów także do ponownych sprawdzeń. Każdą zmianę zgłasza więc właściciel procesu, a my szacujemy jej wpływ na harmonogram przed wprowadzeniem. Poprawki, które nie zmieniają ścieżki, np. literówkę w szablonie, wprowadzamy bez tej procedury. Spór między działami rozstrzygnięty w analizie kończy się jedną decyzją, a ten sam spór odkryty w testach cofa wdrożenie o cały etap.