W skrócie
Specyfikację wymagań firma pisze przed wyborem programu do reklamacji, a jej odpowiedzi służą do wyceny i do analizy przedwdrożeniowej. Opisuje w niej liczbę i rodzaje zgłoszeń, kanały przyjęcia, liczbę użytkowników pracujących jednocześnie i systemy do połączenia z programem. Wymagania opisuje językiem procesu zamiast ekranów i dzieli je na konieczne oraz pożądane. Na zapytanie z taką specyfikacją odpowiadamy wyceną zwykle w ciągu dwóch dni roboczych.
Cel specyfikacji wymagań przed wyborem programu
Specyfikacja wymagań opisuje, czego firma potrzebuje od programu do reklamacji, zanim zacznie rozmawiać z dostawcami. Firma pisze ją sama, bo zna swoje sprawy lepiej niż ktokolwiek z zewnątrz. Ta sama specyfikacja służy potem dwa razy: do porównania ofert i wyceny, a po podpisaniu umowy do analizy przedwdrożeniowej. Analizę prowadzimy wtedy przez 3-5 dni razem z działami firmy, a spisane wcześniej odpowiedzi skracają rozmowy. Kryteria porównania ofert opisujemy przy wyborze programu do reklamacji.
Ta sama specyfikacja pracuje dwa razy, więc opłaca się napisać ją przed pierwszą rozmową z dostawcą.
Dobra specyfikacja odpowiada na pytania o cenę i zakres wdrożenia. Cennik Studio RMA.net nie publikuje stawek, bo kwota zależy od kilku czynników opisanych w kolejnej sekcji. Specyfikacja nie jest natomiast projektem konfiguracji, bo ten powstaje dopiero w analizie po podpisaniu umowy. Etapy całego wdrożenia opisujemy przy etapach wdrożenia systemu reklamacyjnego, a przebieg analizy przy analizie przedwdrożeniowej systemu reklamacji.
Lista pytań do uzupełnienia
Pytania zebraliśmy według czynników, od których zależy wycena w cenniku Studio RMA.net, i dodaliśmy te, które skracają analizę. Odpowiedzi najlepiej podać liczbami tam, gdzie to możliwe, bo „dużo zgłoszeń” znaczy co innego w każdej firmie. Listę można skopiować do własnego dokumentu i uzupełnić:
| Obszar | Pytanie w specyfikacji | Przykład odpowiedzi | Wpływ na wycenę |
|---|---|---|---|
| Liczba zgłoszeń | Ile reklamacji firma przyjmuje miesięcznie i w którym miesiącu najwięcej | 120 miesięcznie, w styczniu 200 | Pośredni, przez liczbę użytkowników |
| Rodzaje spraw | Jakie rodzaje spraw obsługuje dział | Konsumenckie i od partnerów B2B | Tak - typy obsługiwanych zgłoszeń |
| Kanały | Którędy przychodzą zgłoszenia i kto je rejestruje | Formularz na stronie i e-mail | Pośredni, przez zakres konfiguracji |
| Użytkownicy | Ile osób pracuje w programie w tym samym czasie | 8 osób na jednej zmianie | Tak - licencje dostępowe |
| Klienci i partnerzy | Czy klienci albo partnerzy mają zgłaszać sprawy sami | Partnerzy B2B przez konto w portalu | Tak - portal zgłoszeń jako osobny moduł |
| Serwis w terenie | Czy serwisanci pracują poza siedzibą firmy | 5 serwisantów z telefonami z Androidem | Tak - aplikacja Android jako osobny moduł |
| Integracje | Z jakim ERP program ma wymieniać dane i jakie to dane | Comarch ERP XL, kartoteki i dokumenty sprzedaży | Tak - integracje z ERP |
| Terminy | Jakie terminy obowiązują dla rodzajów spraw i kto dostaje sprawy zagrożone | 14 dni dla konsumentów, 21 dni z umów B2B | Tak - reguły terminów i eskalacji |
| Model działania | Chmura prywatna Cloud RMA czy serwer firmy | Serwer firmy w dwóch lokalizacjach | Tak - instalacja lokalna wyceniana indywidualnie |
| Raporty | Jakie zestawienia czyta kierownictwo i jak często | Reklamacje według dostawców co miesiąc | Pośredni, przez zakres danych |
Liczba zgłoszeń nie jest czynnikiem cennika, ale wpływa na liczbę osób pracujących jednocześnie. Strona produktu opisuje firmy od kilkudziesięciu zgłoszeń miesięcznie po organizacje wielooddziałowe z setkami spraw prowadzonych równolegle. Miesiąc z największą liczbą zgłoszeń warto podać osobno, bo to on wyznacza obciążenie działu. W firmach sezonowych średnia z roku zaniża potrzeby działu w szczycie.
Proces i terminy opisane językiem firmy
Proces reklamacyjny opisujemy w specyfikacji tak, jak przebiega dziś, razem z miejscami, w których sprawy czekają najdłużej. Dla każdego rodzaju sprawy wystarczy kilka zdań: kto przyjmuje zgłoszenie, kto ocenia wadę, kto decyduje i kiedy klient dostaje odpowiedź. Opis ekranów i przycisków pomijamy, bo rozwiązanie w programie dobiera się do potrzeby, a nie odwrotnie. Wymaganie „przycisk do przekazania sprawy” zamyka drogę do prostszego rozwiązania, a wymaganie „zastępca widzi sprawy nieobecnego pracownika” ją zostawia. Procedurę, z której specyfikacja bierze opis ścieżki, opisujemy przy procedurze reklamacyjnej w firmie.
Terminy firma podaje osobno dla każdego rodzaju spraw, bo mają różne źródła. Konsumentowi sprzedawca odpowiada na reklamację w 14 dni od jej otrzymania, a brak odpowiedzi oznacza jej uznanie. Między firmami termin wynika z umowy albo z procedury, z wyjątkiem przedsiębiorcy na prawach konsumenta. Umowy z największymi kontrahentami warto przejrzeć przed napisaniem specyfikacji, bo część z nich może zawierać krótsze terminy.
Rodzaje spraw warto nazwać tak, jak firma nazywa je w raportach. Referencje na stronie produktu wymieniają m.in. zgłoszenia klientowskie, przedsprzedażne, partnerskie i pogwarancyjne oraz usługi odpłatne. Każdy rodzaj z własnym terminem albo ścieżką zapisujemy w specyfikacji osobno. Pole Typ reklamacji i rodzaje spraw opisujemy przy rodzajach reklamacji i polu Typ reklamacji.
Użytkownicy jednocześnie zalogowani i role
Licencje dostępowe Studio RMA.net liczy się według użytkowników jednocześnie zalogowanych, a nie nazwanych kont. Specyfikacja podaje więc, ile osób pracuje w programie w tym samym czasie, a nie ilu pracowników ma dostęp. W firmie pracującej na dwie zmiany ta liczba bywa wyraźnie mniejsza od liczby kont. Wariant bez limitu użytkowników przypisuje licencję do procesora serwera, co opisujemy przy modelu zakupu programu RMA.
Obok liczby użytkowników specyfikacja opisuje role, czyli grupy osób z tym samym zakresem pracy. Starsza dokumentacja programu wymienia role Administrator, Kierownik, Przyjęcia, Technik, Wydania i Partner. Firma nie musi używać tych nazw, ale dla każdej grupy powinna podać zakres pracy:
- Rejestracja - kto przyjmuje zgłoszenia i zakłada sprawy w programie.
- Ocena i naprawa - kto ocenia wadę i zapisuje wykonane usługi.
- Decyzja i nadzór - kto zmienia status na decyzję i czyta raporty.
- Administracja - kto zakłada konta i zmienia skorowidze po starcie.
Firma zaznacza też, czy pracownicy mają logować się kontami z sieci firmowej. Studio RMA.net obsługuje wtedy logowanie przez Active Directory, a komunikację szyfruje protokołem SSL. Program działa w przeglądarce na komputerze i na urządzeniach z Androidem, więc specyfikacja nie musi opisywać instalacji na stanowiskach.
Integracje z ERP i raporty w specyfikacji
Dla integracji specyfikacja podaje system ERP firmy i dane, które mają przechodzić między systemami. Strona produktu i referencje potwierdzają integracje z czterema systemami: SAP, Microsoft Dynamics, Comarch ERP XL i enova 365. Program wiąże wtedy zgłoszenie z dokumentami sprzedaży i historią zamówień klienta. Wymiana plikowa kartotek i eksport reklamacji wystarczają, gdy firma nie potrzebuje połączenia w czasie rzeczywistym. Zakres wymiany opisujemy przy integracji programu do reklamacji z ERP.
Raporty opisujemy w specyfikacji jako pytania, na które kierownictwo chce odpowiedzi, np. który dostawca ma najwięcej reklamacji. Program ma gotowe raporty, m.in. Matrix wg artykułu, Reklamacje wg dostawców, Statystyki wg uszkodzeń artykułów i Zgłoszenia wg pracowników. Pytanie, na które żaden raport nie odpowiada, zapisujemy jako wymaganie do wyceny. Wyniki raportów w starszym interfejsie zapisuje się do PDF albo XLS.
Wymagania konieczne i pożądane
Każde wymaganie dostaje w specyfikacji jedną z dwóch wag. Bez podziału wszystkie wymagania wyglądają na równie ważne, a dostawca nie wie, gdzie firma może pójść na kompromis. Przyjmujemy prosty podział:
- Wymaganie konieczne - bez niego firma nie uruchomi programu, np. kontrola 14-dniowego terminu odpowiedzi konsumentowi.
- Wymaganie pożądane - poprawia pracę działu, ale firma może zacząć bez niego, np. zestawienie na życzenie zarządu.
Wymagania konieczne firma sprawdza w demo jeszcze przed zapytaniem o wycenę. Bezpłatne demo online jest dostępne od ręki i bez zobowiązań, ale działa w standardowej konfiguracji dla sieci sklepów z centralą. W demo sprawdza się więc sposób pracy, np. formularz zgłoszenia i zmianę statusu, a nie połączenie z ERP firmy. Scenariusze sprawdzeń opisujemy przy wersji demo programu do reklamacji.
Wymagania, których demo nie pokazuje, zapisujemy jako pytania otwarte. Wracamy do nich w analizie przedwdrożeniowej, gdy znamy już dane i procedury firmy. Pytanie otwarte nie oznacza braku funkcji, tylko to, że odpowiedź zależy od konfiguracji albo zakresu wdrożenia.
Od specyfikacji do wyceny i analizy
Specyfikację firma wysyła razem z zapytaniem o wycenę, a odpowiedź przygotowujemy zwykle w ciągu dwóch dni roboczych. Cennik nie publikuje stawek, bo kwota zależy od czynników z tabeli, a wdrożenie wyceniamy osobno od licencji. Ceny podajemy netto, a dojazdy i prace na obiekcie rozliczamy osobno. Przy instalacji na serwerze firmy wycena zależy dodatkowo od liczby lokalizacji i podziału odpowiedzialności za infrastrukturę. Drugi model opisujemy przy reklamacjach w chmurze prywatnej Cloud RMA.
Po podpisaniu umowy specyfikacja staje się materiałem wejściowym analizy przedwdrożeniowej. W 3-5 dni analizy sprawdzamy jej odpowiedzi w rozmowach z działami i uzupełniamy pytania otwarte. Rozbieżności między specyfikacją a praktyką rozstrzyga właściciel procesu po stronie firmy. Dobrze napisana specyfikacja nie zastępuje analizy, ale sprawia, że rozmowy dotyczą decyzji, a nie zbierania podstawowych danych.