Dyspozytor wysyła technika do pilnej naprawy bez wcześniejszej oferty cenowej. Czas pracy i potrzebne części są jeszcze nieznane, ale dział finansowy nadal potrzebuje zatwierdzonej faktury, której pozycje można uzasadnić. To punkt wyjścia interwencji bez oferty pokazanej podczas webinaru Odoo poświęconego usługom, w którym prowadząca opisuje przeniesienie Field Service do Planning.
Oceniaj proponowane połączenie na podstawie kompletnych scenariuszy obsługi, a nie liczby aplikacji. Wymagaj przeprowadzenia naprawy bez oferty oraz cyklicznej konserwacji od planowania, przez dokumentację wykonanych prac, po uzgodnienie rozliczenia. Zaakceptuj proces dopiero wtedy, gdy działy operacji serwisowych i finansów zgodnie zatwierdzą wyniki. W przeciwnym razie świadomie zatwierdź zmianę sposobu pracy albo odłóż migrację do czasu zweryfikowania rozwiązania spełniającego wymagania.
Ustal, co demonstracja musi udowodnić
Podczas webinaru połączenie aplikacji uzasadniono między innymi modelem planowania w Planning, który rozróżnia wersję roboczą i publikację: przydział można przygotować, zanim publikacja uruchomi powiadomienie pracownika. To rozróżnienie ma znaczenie operacyjne. Poproś dyspozytorów o pokazanie przygotowania, publikacji i zmiany przydziału, w tym komunikatów, które powinny trafiać do klienta i pracownika na każdym etapie przekazania pracy.
Dokumentacja Field Service oznaczona wersją Odoo opisuje interwencje planowane jako zmiany w Planning, wraz z kartami pracy, materiałami, czasem i raportami dla klientów. Traktuj ją jako opis procesu do zweryfikowania, a nie gwarancję dostępności produkcyjnej czy zgodności z Twoim wdrożeniem. Zanim uznasz demonstrację za miarodajną, zapisz docelową wersję, edycję, model hostingu, zainstalowane aplikacje i wszelkie moduły niestandardowe.
Wymagaj od zespołu wdrożeniowego wskazania uprawnień wynikających z warunków handlowych i licencji do korzystania z kart pracy, subskrypcji, planowania cyklicznego oraz proponowanych funkcji opłat za dojazd. Widoczność funkcji w bazie demonstracyjnej nie jest wystarczającym dowodem jej dostępności w środowisku objętym Twoją umową.
Zacznij od procesu operacyjnego, zamiast zachowywać każdy dotychczasowy ekran. Ekspert ERP Francesco Perrotta podkreśla znaczenie obiektywnej oceny procesów biznesowych i zrozumienia kontekstu firmy przy wyborze rozwiązań. Zastosuj tę zasadę tutaj: sklasyfikuj każde wymaganie jako niezbędny mechanizm kontroli biznesowej, przydatną preferencję operacyjną albo przyzwyczajenie, które zespół jest gotów zmienić. Pozwoli to uniknąć zarówno automatycznego odrzucenia innego interfejsu, jak i bezrefleksyjnego zaakceptowania słabszej kontroli.
Scenariusz: interwencja bez oferty aż do faktury
Wykorzystaj reprezentatywne dane klientów, lokalizacji, pracowników, stawek za usługi i części. W przykładzie naprawy podczas webinaru prowadząca tworzy zmianę bez oferty, publikuje ją, rozpoczyna pracę i uzupełnia kartę pracy. Twój scenariusz testu akceptacyjnego powinien wykraczać poza te kliknięcia i obejmować podstawę handlową do wykonania prac bez z góry wycenionej kwoty.
Przed wysłaniem technika wymagaj pokazania klienta i adresu realizacji usługi, przydzielonego zasobu, planowanego przedziału czasowego, karty pracy oraz obowiązujących zasad naliczania opłat. Ustal, gdzie zapisywana jest zgoda na przyjazd i kto może zatwierdzić dodatkowe prace. Potwierdzenie obecności technika przez klienta nie powinno oznaczać akceptacji wszystkich opłat, chyba że tak stanowią uzgodnione zasady biznesowe.
Poproś technika o zarejestrowanie naprawy, czasu i wymienionych części przy użyciu docelowych uprawnień. Dokumentacja Odoo wskazuje, że dodawanie produktów ze zmiany wymaga uprawnienia w aplikacji Sales „User: All Documents” lub Administrator. Podaje też, że produkty trafiają do powiązanego zamówienia sprzedaży, a jeśli go nie ma, zamówienie powstaje automatycznie. Demonstracja przeprowadzona wyłącznie na koncie administratora pozostawia więc istotną kwestię bez odpowiedzi: czy technik może wykonać zadanie z dostępem, który firma jest gotowa mu przyznać?
Prześledź powstałe zapisy aż do działu finansowego. Webinar pokazuje utworzenie faktury po dodaniu usługi i produktów. Na potrzeby akceptacji wymagaj, aby finanse powiązały każdą proponowaną opłatę z interwencją: pozycję usługową, stawkę, ilość podlegającą rozliczeniu, ilość części oraz zgodę klienta. Sprawdź kartę pracy lub raport przedstawiany klientowi do podpisu, ustal osobę podpisującą i potwierdź, kto rozwiązuje przypadek odmowy podpisu lub zakwestionowania części przed dalszym fakturowaniem.
Uwzględnij wyjątek gwarancyjny. Zgodnie z dokumentacją ustawienie Under warranty zeruje ceny materiałów i usług dodawanych ze zmiany, ale nie zmienia cen pozycji wprowadzonych bezpośrednio do zamówienia sprzedaży. Przetestuj obie ścieżki. Warunek zaliczenia jest spełniony, gdy finanse potrafią wyjaśnić sposób rozliczenia i wykryć niezamierzone opłaty przed zatwierdzeniem faktury. Samo znalezienie pola gwarancji nie wystarczy.
Oddziel zakres dat z szablonu, przydzielone godziny i czas do rozliczenia
Nie uznawaj wpisu w kalendarzu za dowód poprawnego rozliczania czasu. Zdefiniuj osobno zakres dat wynikający z szablonu planowania, czas przydzielony na interwencję, czas zarejestrowany podczas realizacji i ilość, którą finanse mogą zafakturować. Przy prostej naprawie wartości te mogą się pokrywać. W teście celowo doprowadź do ich rozbieżności.
Opisany w dokumentacji proces fakturowania rzeczywistego czasu wymaga aplikacji Project i Timesheets, przydzielonego pracownika oraz projektu rozliczanego z klientem z włączoną ewidencją czasu. Dokumentacja wskazuje, że fakturowanie opiera się na polu Allocated Time zmiany, aktualizowanym przy rozpoczęciu i zakończeniu pracy. Przejście od planowanego przydziału do ilości podlegającej rozliczeniu staje się więc kluczowym elementem testu akceptacyjnego, a nie drugorzędnym szczegółem konfiguracji.
Zapisz daty wygenerowane przez szablon i przydzielone godziny przed rozpoczęciem pracy. Następnie pokaż opóźniony start, przerwę i korektę zapisu zakończenia. Jeśli w interwencji uczestniczy kilku techników, wymagaj wyjaśnienia, czy proponowana opłata odpowiada czasowi trwania interwencji, czy pracy każdego pracownika. To pytania testowe, a nie założenia dotyczące obsługiwanych funkcji. Finanse powinny uzgodnić wynikową ilość z zasadami naliczania opłat i zachować dowody pozwalające wyjaśnić każdą korektę.
Przekonujący wynik pokazuje pierwotny plan, zarejestrowaną realizację, zatwierdzoną korektę i końcową ilość na fakturze. Odpowiedź „licznik czasu to obsługuje” jest niewystarczająca, gdy przerwy, korekty lub zmiany zasobów wpływają na opłatę. Jeśli proces wymaga ręcznego uzgadniania, wskaż osobę sprawdzającą, porównywane zapisy i potwierdź, czy zespół operacyjny akceptuje związany z tym nakład pracy.
Scenariusz: cykliczna konserwacja właściwego urządzenia
Demonstracja cyklicznej konserwacji wprowadza inny łańcuch zależności. W przykładzie konserwacji z webinaru poświęconego usługom urządzenie jest identyfikowane unikalnym numerem seryjnym, a zmiana udostępnia informacje o konserwowanym sprzęcie i dokumentację produktu. Planowanie uwzględnia datę rozpoczęcia subskrypcji, a cykliczność odzwierciedla subskrypcję i datę jej zakończenia. Zweryfikuj cały ten łańcuch w środowisku docelowym, zamiast zakładać, że same cykliczne zmiany wystarczą do obsługi umów konserwacyjnych.
Zacznij od reprezentatywnej umowy konserwacyjnej, lokalizacji klienta i urządzenia z numerem seryjnym. Wymagaj prześledzenia powiązania subskrypcji lub zapisu sprzedaży z właściwym sprzętem i zaplanowaną wizytą. Poproś technika o otwarcie odpowiedniej dokumentacji technicznej z rekordu pracy, uzupełnienie wymaganej karty pracy i wskazanie obsługiwanego urządzenia. Poprawna nazwa klienta nie wystarczy, jeśli w lokalizacji znajdują się podobne urządzenia o różnych wymaganiach konserwacyjnych.
Testuj zmiany umowy, a nie tylko jej utworzenie. Przesuń wizytę, zmień datę zakończenia subskrypcji i pokaż, jak wyznaczana jest kolejna wymagana wizyta. Uwzględnij wymianę urządzenia lub zmianę lokalizacji, jeśli takie sytuacje występują w Twojej firmie. Dla każdego wyjątku wymagaj wskazania właściciela oraz widocznego sposobu wykrywania brakującej wizyty, zbędnej wizyty lub interwencji powiązanej z niewłaściwym numerem seryjnym.
Uzgadniaj zakres objęty umową oddzielnie od prac dodatkowych. Finanse powinny pokazać, które prace i części obejmuje subskrypcja, które wymagają osobnej zgody oraz jak kontrola faktury zapobiega podwójnym lub pominiętym opłatom. Porównaj umowę, wykonaną wizytę, dokumentację w karcie pracy i proponowany wynik rozliczenia. Wygenerowanie kolejnego terminu nie dowodzi spełnienia obowiązku konserwacji ani zastosowania właściwej reguły naliczania opłat.
Przetestuj również zasady zarządzania kartami pracy. Dokumentacja Odoo wskazuje, że edycja szablonu karty pracy ze zmiany wpływa na wszystkie zmiany korzystające z tego szablonu. Zmodyfikuj wspólny szablon w środowisku testowym i sprawdź pozostałe objęte zmianą prace. Ustal, kto może zatwierdzać zmiany szablonów i jak zachować zrozumiałość dokumentacji wykonanych usług, gdy instrukcje konserwacji będą się zmieniać.
Uwzględnij zależności i wyjątki w decyzji
Oceń opłaty za dojazd oddzielnie od podstawowej interwencji. Webinar opisuje opłaty stałe i zależne od odległości oraz wskazuje integrację z Mapbox służącą do obliczania dystansu. Zanim na niej polegniesz, zweryfikuj dostępność w środowisku docelowym, obowiązujące opłaty i limity użycia, dane dostępowe API, punkt początkowy i docelowy obliczeń oraz zachowanie w przypadku niepowodzenia kalkulacji. Zapytaj, jakie dane adresowe lub współrzędne są przesyłane i jakie warunki przetwarzania mają zastosowanie. Nie zakładaj, że funkcja jest zawarta w pakiecie lub zawsze bezpłatna.
Przy migracji Odoo Field Service wymagaj mapowania i przykładowego uzgodnienia istniejących zadań, pól niestandardowych, historii kart pracy, prac cyklicznych, powiązań urządzeń i odwołań do historycznych rozliczeń. Nowa zmiana utworzona na potrzeby demonstracji nie dowodzi, że zmigrowane rekordy zachowają relacje potrzebne zespołom serwisowym i finansowym.
Prowadź rejestr decyzji dla scenariuszy, zawierający kryteria zaliczenia, odwołania do rekordów, zaobserwowane wyniki, nierozwiązane wyjątki, konsekwencje biznesowe, właściciela i dowody potrzebne do zamknięcia każdej kwestii. Perrotta wskazuje niedocenianie szkoleń jako powtarzający się problem wdrożeniowy. Niech dyspozytorzy, technicy i pracownicy finansów samodzielnie wykonają swoje kroki, aby ocena odróżniała dopasowanie funkcjonalne od potrzeb szkoleniowych.
To decyzja wcześniejsza niż zgoda na uruchomienie produkcyjne. Nasza analiza gotowości do uruchomienia ERP dotyczy tego, czy organizacja jest w stanie pracować na dostarczanej wersji systemu. Tutaj zdecyduj, czy zaakceptować zademonstrowany model obsługi, zmienić proces za zgodą jego właściciela, czy odłożyć migrację, ponieważ kluczowe wymaganie dotyczące planowania, dokumentacji lub rozliczania pozostaje nierozwiązane.
Przed podjęciem zobowiązania przedstaw wyniki naprawy bez oferty i cyklicznej konserwacji wspólnie działom operacji serwisowych i finansów oraz wymagaj decyzji dotyczącej każdego krytycznego wyjątku. Jeśli potrzebujesz pomocy w określeniu zakresu tej oceny lub usunięciu luk funkcjonalnych i technicznych, porozmawiaj ze specjalistami Odoo w Digiventi o swoich procesach i wymaganiach migracyjnych.
