Field Service w firmie produkcyjnej: serwis z danymi z SAP
Opublikowano: 10 września 2026
Producent maszyn zarabia na serwisie więcej niż na sprzedaży maszyn. W analizie rynku posprzedażowego McKinsey z 2017 roku średnia marża EBIT na usługach posprzedażowych w 30 branżach wyniosła 25% wobec 10% na nowym sprzęcie, a Deloitte w 2020 roku szacował, że producenci generują z usług od 40% do 50% zysku, przy marży operacyjnej około 2,5 razy wyższej niż na sprzęcie. Tymczasem technik, który przyjeżdża do klienta, często nie wie, jaka wersja urządzenia tam stoi, czy naprawa jest w gwarancji i czy część, którą ma w samochodzie, jest tą właściwą. Te trzy informacje są w SAP. Technik pracuje w aplikacji mobilnej. Cały projekt sprowadza się do tego, jak je ze sobą połączyć.
Dwa systemy, które opisują to samo urządzenie
W S/4HANA urządzenie u klienta istnieje jako equipment, osadzone w lokalizacji funkcjonalnej, ze strukturą podzespołów. Wokół niego działa moduł serwisu: zlecenie serwisowe z kontrolą uprawnień z gwarancji i umowy, przydział czynności technikom oraz potwierdzenia serwisowe, które raportują czas pracy, koszty i zużyte części i z których powstaje faktura.
W Salesforce Field Service to samo urządzenie jest obiektem Asset. Asset reprezentuje konkretny zakupiony lub zainstalowany produkt, ma hierarchię podzespołów i wiąże się ze zleceniami pracy, uprawnieniami, umowami serwisowymi i planami konserwacji. Wokół niego działa konsola dyspozytora i aplikacja mobilna zaprojektowana do pracy offline, w której technik widzi i aktualizuje zlecenia bez zasięgu. Od kwietnia 2025 roku dochodzi do tego Agentforce for Field Service: odsłuchiwane podsumowanie zlecenia przed przyjazdem i raport po pracy generowany na podstawie notatek technika.
Obie strony mają więc pełny model serwisu. Problem nie polega na tym, że któremuś systemowi czegoś brakuje, tylko na tym, że każdy chce być właścicielem tych samych obiektów.
Dlaczego w ogóle Salesforce, skoro SAP ma własny serwis mobilny
SAP sprzedaje SAP Field Service and Asset Management, produkt wyrosły z przejętej firmy Coresystems, który przejmuje harmonogramowanie i pracę technika na urządzeniu mobilnym, a stany magazynowe replikuje z S/4HANA przez SAP Cloud Integration. Dla firmy, w której serwis jest przedłużeniem utrzymania ruchu i sprzedaż nie pracuje w CRM, to naturalna droga o mniejszej liczbie interfejsów.
Salesforce Field Service wybiera się zwykle z innego powodu: obsługa klienta i sprzedaż już pracują w Salesforce, historia kontaktów, reklamacje i szanse na sprzedaż umowy serwisowej są tam, a serwis ma być częścią tej samej relacji z klientem. Wtedy pytanie nie brzmi „który system serwisowy jest lepszy”, tylko „ile interfejsów do SAP trzeba utrzymać, żeby technik w Salesforce pracował na prawdziwych danych”. Odpowiedź jest zaskakująco stała między projektami.
Co trzeba połączyć
| Obiekt | Właściciel | Kierunek | Interfejs SAP |
|---|---|---|---|
| Klient i lokalizacja | SAP | do Salesforce | Business Partner |
| Zainstalowane urządzenie | SAP | do Salesforce | Equipment |
| Zlecenie serwisowe | zależy od wzorca | w obie strony | Service Order |
| Stan części w magazynach i samochodach | SAP | do Salesforce | Material Stock |
| Potwierdzenie: czas, części, koszty | Salesforce | do SAP | Service Confirmation |
| Faktura | SAP | do Salesforce | Billing Document |
Wszystkie wymienione interfejsy są standardowymi, aktywnymi API S/4HANA, więc żaden z tych strumieni nie wymaga programowania po stronie SAP. Wymaga natomiast decyzji, które w tabeli kryją się pod słowem „właściciel”.
Baza zainstalowanych urządzeń powstaje w SAP w momencie dostawy, bo tam jest numer seryjny, dokument sprzedaży i gwarancja. Salesforce dostaje replikę i może ją wzbogacać o to, czego SAP nie zna: zdjęcia, notatki technika, historię rozmów. Jeśli Salesforce zacznie zakładać własne urządzenia bez odpowiednika w SAP, po roku nikt nie będzie wiedział, ile maszyn firma faktycznie serwisuje.
Zlecenie serwisowe jest jedynym obiektem, dla którego właściciel zależy od wzorca. Jeśli zgłoszenia przyjmuje obsługa klienta w Salesforce, zlecenie powstaje tam, a SAP dostaje jego odbicie, żeby zarezerwować części i rozliczyć pracę. Jeśli zlecenia generuje plan konserwacji w SAP albo alarm z maszyny przez system MES, powstają w SAP i trafiają do Salesforce jako praca do zaplanowania. Serwis predykcyjny jest przedłużeniem tego samego przepływu sygnałów z produkcji, który opisaliśmy przy integracji SAP z MES. Wiele firm ma oba źródła zleceń naraz i wtedy trzeba zaakceptować, że zlecenie może powstać po obu stronach, ale jego numer SAP jest zawsze kluczem.
Serwis, sprzedaż i SAP w jednym procesie
Serwis posprzedażowy na danych z ERP wraca w rozmowach na każdej edycji. Przyjdź i zapytaj tych, którzy to wdrożyli.
Zarejestruj się za darmo ↗Gdzie projekty się zatrzymują
Pierwsze miejsce to hierarchia urządzeń. W SAP struktura equipment i lokalizacji funkcjonalnych bywa głęboka i budowana pod potrzeby utrzymania ruchu, w Salesforce hierarchia Asset ma być czytelna dla technika na ekranie telefonu. Mapowanie jeden do jednego daje technikowi kilkanaście poziomów do przeklikania, mapowanie spłaszczone traci informację potrzebną do rozliczenia części. Zwykle kończy się to decyzją, do którego poziomu Salesforce widzi strukturę, i tę decyzję trzeba podjąć z serwisem, a nie z IT.
Drugie to praca offline. Technik potwierdza zużycie części w piwnicy bez zasięgu, a potwierdzenie trafia do SAP kilka godzin później, gdy w magazynie samochodowym już zaksięgowano inną transakcję. Integracja musi zakładać, że potwierdzenia przychodzą z opóźnieniem i w innej kolejności niż powstały, a to wyklucza proste, synchroniczne wywołania i wymusza kolejkę z obsługą błędów księgowania.
Z pracy offline wynika też problem numeracji. Zlecenie założone przez technika bez zasięgu ma przez kilka godzin tylko tymczasowy identyfikator Salesforce, a numer dokumentu SAP dostanie dopiero po synchronizacji i przetworzeniu przez interfejs. W tym czasie technik może już dopisać do niego zużyte części i czas pracy, więc integracja musi trzymać tabelę odwzorowań obu kluczy i umieć dopisać numer SAP do rekordów, które powstały wcześniej. Jeśli SAP odrzuci dokument, na przykład z powodu zablokowanego klienta, technik powinien zobaczyć to w aplikacji, a nie dowiedzieć się od księgowości po tygodniu. Ten mechanizm zwrotny bywa pomijany w pierwszej wersji projektu i dokładany po pierwszym zamknięciu miesiąca.
Trzecie to gwarancja. SAP sprawdza uprawnienia w zleceniu serwisowym, Salesforce ma własne obiekty uprawnień i umów serwisowych. Jeśli oba systemy liczą gwarancję, wcześniej czy później dadzą różne odpowiedzi, a klient dostanie fakturę za naprawę, którą technik obiecał jako gwarancyjną. Trzeba wybrać jedno miejsce, a drugie ma tylko wyświetlać wynik.
Czwarte dotyczy agentów. Podsumowanie przed przyjazdem i raport po pracy są tak dobre, jak dane, na których pracują. Agent, który nie widzi historii napraw z SAP, streści tylko to, co jest w Salesforce, jak każdy z agentów AI w ERP i CRM ograniczony zasięgiem swoich interfejsów.
Na koniec pytanie, które pada w każdym projekcie z działem prawnym: gdzie leżą dane. Salesforce pozwala wybrać region w ramach Hyperforce, a dla firm z wymogiem przetwarzania w Unii działa strefa operacyjna UE, w której przechowywanie i przetwarzanie danych klienta odbywa się w centrach danych w regionie, ze wsparciem świadczonym z Unii. To nie rozwiązuje kwestii transferu do SAP, jeśli S/4HANA działa gdzie indziej, ale zamyka najczęstsze pytanie audytu.
FAQ
Czy firma z SAP potrzebuje Salesforce Field Service, skoro SAP ma własny serwis mobilny?
Nie zawsze. SAP Field Service and Asset Management jest dobrym wyborem, gdy serwis jest przedłużeniem utrzymania ruchu, a sprzedaż i obsługa klienta nie pracują w Salesforce. Salesforce Field Service wybiera się wtedy, gdy relacja z klientem, reklamacje i sprzedaż umów serwisowych już są w Salesforce i serwis ma być częścią tego samego obrazu klienta.
Który system powinien być właścicielem bazy zainstalowanych urządzeń?
SAP. Urządzenie powstaje tam w momencie dostawy, razem z numerem seryjnym, dokumentem sprzedaży i gwarancją. Salesforce dostaje replikę i wzbogaca ją o notatki, zdjęcia i historię kontaktów, ale nie zakłada urządzeń bez odpowiednika w SAP.
Czy technik może pracować bez zasięgu, jeśli dane są w SAP?
Tak, aplikacja mobilna Salesforce Field Service jest zaprojektowana do pracy offline i synchronizuje zmiany po odzyskaniu połączenia. Integracja z SAP musi jednak zakładać, że potwierdzenia serwisowe przychodzą z opóźnieniem i w innej kolejności niż powstały, a zlecenia założone offline dostają numer SAP dopiero po synchronizacji.
Kto powinien sprawdzać, czy naprawa jest gwarancyjna?
Jeden system, a drugi ma tylko wyświetlać wynik. Zarówno S/4HANA, jak i Salesforce mają własne mechanizmy uprawnień i umów serwisowych, i jeśli oba liczą gwarancję niezależnie, w końcu dadzą różne odpowiedzi. Najczęściej źródłem jest SAP, bo tam są dokumenty sprzedaży i warunki umowy.
Czy dane serwisowe klientów mogą pozostać w Unii Europejskiej?
Po stronie Salesforce tak, przez strefę operacyjną UE w ramach Hyperforce, w której dane klienta są przechowywane i przetwarzane w centrach danych w regionie. Osobno trzeba ocenić, gdzie działa S/4HANA i platforma integracyjna, bo strefa UE Salesforce nie obejmuje tych systemów.