Interventi sul campo con SAP FSM e S/4HANA Public Cloud: una plancia di pianificazione al posto del gruppo WhatsApp

Queste organizzazioni di service si riconoscono da tre sintomi. Primo: la pianificazione degli interventi corre su telefono, una lista Excel chiamata «Interventi_Sett27_finale_v3» e un gruppo WhatsApp. Secondo: dopo l’intervento il tecnico compila un rapporto cartaceo che arriva al back office giorni dopo, via foto o posta interna, leggibile a metà. Terzo: la fattura segue l’intervento con due-quattro settimane di distacco, perché prima qualcuno deve ricopiare i rapporti, registrare il materiale e controllare le ore. Ogni sintomo da solo è fastidioso. Insieme costano denaro vero: viaggi a vuoto, materiale dimenticato in fattura, liquidità bloccata.

La buona notizia per chi è già su SAP S/4HANA Public Cloud, o ci sta passando adesso: non serve valutare un sistema di terzi. SAP Field Service Management (FSM) si aggancia in standard. La domanda non è se funziona, ma quando conviene e come introdurlo senza perdere i tecnici per strada.

Cosa fa FSM che l’ERP da solo non può fare

S/4HANA Public Cloud porta con sé un processo di service solido: ordine di servizio, conferma, fatturazione. Quello che manca è tutto ciò che sta tra «l’ordine esiste» e «il tecnico è dal cliente». È esattamente questa lacuna che FSM colma, con quattro mattoni:

• La plancia di pianificazione grafica. Il dispatcher vede tutti i tecnici, le loro competenze, la loro disponibilità e gli interventi aperti su un’unica plancia, con la mappa accanto. Assegnare significa trascinare e rilasciare. Chi oggi pianifica con Excel risparmia qui mezza mattinata.
• L’app mobile nativa con modalità offline. Il tecnico vede i suoi interventi, il percorso, lo storico dell’impianto e la checklist sul telefono. Anche in cantina senza campo; la sincronizzazione riparte appena torna la rete.
• Smartforms e checklist. Il rapporto di servizio nasce in digitale durante l’intervento: misurazioni, foto, materiale consumato, firma del cliente direttamente sullo schermo. Il PDF è pronto prima che il tecnico esca dal cortile.
• Prenotazione appuntamenti in self-service. Il cliente finale prenota da sé la finestra di manutenzione, invece di telefonare tre volte alla pianificazione.

Il flusso di processo, tracciato una volta da cima a fondo

Il percorso di un intervento attraverso i sistemi è sorprendentemente banale in standard, ed è esattamente così che deve essere. All’inizio c’è un innesco: un ordine di servizio da S/4HANA Public Cloud oppure, se c’è una Service Cloud V2, un case dall’ingresso omnicanale. Da lì nasce il service call in FSM. Il dispatcher lo pianifica sulla plancia, il tecnico riceve l’attività sul telefono. Sul posto conferma tempi, materiale e spese nell’app, compila la checklist, raccoglie la firma. Questa conferma torna in S/4HANA, dove girano conferma e fatturazione, con i numeri veri dell’intervento invece della trascrizione di un rapporto cartaceo.

Il punto che sorprende di più nei workshop di architettura: tutto questo passa dal connettore standard tra FSM e S/4HANA Public Cloud. Nessun middleware su misura, nessun progetto di integrazione con budget a sei cifre. La connessione si configura, non si costruisce.

Cosa ci portiamo a casa dai progetti

La tecnica è raramente il problema. L’introduzione, più spesso. Quattro lezioni da progetti di field service, anonimizzate, ma tutte pagate:

1. Partire in piccolo: pianificazione più rapporto di servizio digitale, nient’altro. Prenotazione appuntamenti, logistica ricambi, piani di manutenzione, tutte buone idee per la fase due. Chi introduce tutto in una volta non stabilizza niente.
2. Nessuna checklist da 40 campi il primo giorno. La tentazione è forte, perché gli smartforms sono così piacevolmente flessibili. La realtà: oltre una certa lunghezza i tecnici smettono di compilare la checklist, o peggio, la spuntano alla cieca. Da cinque a otto campi obbligatori, il resto facoltativo. Estendere si può sempre; tornare indietro costa politicamente molto di più.
3. Il time-to-invoice è IL KPI. Non il numero di login all’app, non l’occupazione della plancia. Il tempo dall’intervento concluso alla fattura spedita. Da due-quattro settimane a uno-due giorni è un obiettivo realistico, e il CFO capisce questo numero senza slide di spiegazione.
4. Prima i dati anagrafici. La plancia è intelligente solo quanto i suoi dati: tecnici con competenze mantenute, materiali di servizio che il tecnico ritrova davvero nell’app. Chi fa questo compito prima del go-live ottiene una plancia che pianifica. Chi lo salta ha comprato un foglio Excel costoso con lo sfondo sfumato.

Quanto costa, calcolato onestamente

FSM si licenzia per tecnico. Questo rende il conto piacevolmente semplice: il beneficio scala con le stesse teste del costo. Regola pratica dai nostri progetti: FSM conviene a partire da una manciata di tecnici pianificati; è lì che lo sforzo di coordinamento e il ritardo di fatturazione iniziano a fare davvero male. Con due tecnici che si organizzano la settimana da soli, il processo di service S/4 più un telefono di solito basta; uno strumento di dispatching senza un problema di dispatching è complessità comprata. Da dieci-quindici tecnici in su, la licenza si ripaga de facto già solo con il tempo di back office risparmiato e la fatturazione anticipata.

Quello che resta alla fine: una pianificazione che avviene su una plancia invece che su tre canali, un rapporto di servizio che non deve più sopravvivere al viaggio di ritorno, e una fattura che parte mentre il cliente si ricorda ancora del tecnico.

Domande frequenti

SAP FSM funziona anche offline?

Sì. L’app mobile è un’applicazione nativa con modalità offline: interventi, checklist, registrazione del materiale e firma funzionano senza connessione di rete. Appena il dispositivo torna online, l’app si sincronizza automaticamente. Per i tecnici in cantine, capannoni e zone periferiche non è un comfort, è la condizione perché accettino lo strumento in assoluto.

Ci serve anche SAP Service Cloud V2?

No. FSM si collega direttamente a S/4HANA Public Cloud; l’ordine di servizio nell’ERP basta come innesco. Service Cloud V2 si giustifica quando il problema è l’ingresso: tante segnalazioni di servizio via e-mail, telefono, chat o portale, da raggruppare in case, prioritizzare e solo poi passare al field service. Ingresso omnicanale e gestione degli interventi sono due problemi diversi; è lecito risolverli separatamente.

Si possono pianificare anche i subappaltatori?

Sì, con la funzione crowd workforce. Partner di servizio esterni e subappaltatori ricevono gli interventi dalla stessa piattaforma e confermano dalla stessa app, con un accesso proprio e senza comprare un pacchetto di licenze per l’intera azienda partner. Il rapporto di servizio appare identico al cliente finale, chiunque si presenti.

Quanto dura un’introduzione?

Con il perimetro che raccomandiamo (pianificazione più rapporto di servizio digitale, connettore standard, dati anagrafici preparati), tre-quattro mesi fino al go-live sono realistici. A dettare i tempi è raramente la tecnica; sono la qualità dei dati anagrafici e il tempo che si concede ai tecnici per cambiare abitudini.

La vostra pianificazione corre ancora sul gruppo WhatsApp e la fattura aspetta il rapporto cartaceo? Vi mostriamo volentieri plancia e app dal vivo, con il vostro processo di service. Parlate con noi.