SAP Service Cloud V2 + S/4HANA Public Cloud: dal caso all'ordine di servizio fino alla fattura

Un cliente chiama per una macchina guasta. L’operatore riesce a vedere di quale macchina si tratta, se è ancora in garanzia, e ad aprire l’ordine di servizio nell’ERP senza cambiare sistema? Con SAP Service Cloud V2 e SAP S/4HANA Public Cloud collegati tramite SAP Integration Suite sì, e gran parte del meccanismo è contenuto standard di SAP, non codice personalizzato.

Questo articolo tratta il lato assistenza del collegamento: dove vive il caso, dove vive l’evasione, quali dati scorrono in quale direzione e le regole di base che applichiamo nei progetti. Per il lato vendite della stessa topologia si veda l’architettura di integrazione di Sales Cloud V2; per il quadro complessivo, la nostra guida allo stack integrato S/4HANA Public Cloud e Sales Cloud V2.

In sintesi: Il caso vive in Service Cloud V2, l’evasione (ordine di servizio, ricambi, conferma, fatturazione) in S/4HANA Public Cloud. SAP fornisce pacchetti di integrazione standard su SAP Integration Suite per i dati anagrafici (partner commerciali, prodotti, attrezzature) e per i processi di assistenza (ordini di servizio, contratti, offerte, resi). Prima si replicano i dati anagrafici, poi si collega il processo. La logica personalizzata va su SAP Business AI Platform (BAIP, ex BTP) come estensione side-by-side, mai all’interno di uno dei due sistemi centrali.

Come si integra Service Cloud V2 con S/4HANA Public Cloud?

L’integrazione passa da SAP Integration Suite (Cloud Integration) su SAP BAIP. Service Cloud V2 espone API REST; S/4HANA Public Cloud espone API rilasciate, documentate sul SAP Business Accelerator Hub e attivate per scenario tramite communication arrangement. Nessuno dei due sistemi chiama direttamente l’altro. Integration Suite mappa, instrada e monitora ogni messaggio, il che significa una sola coda di errori, logica di ripetizione e un unico manuale operativo.

SAP fornisce il contenuto di integrazione pronto da distribuire. Per l’assistenza contano due pacchetti:

• Il pacchetto per i dati anagrafici di Sales e Service Cloud V2 con S/4HANA Cloud Public Edition: partner commerciali e relazioni di contatto in entrambe le direzioni, prodotti, dati organizzativi, attrezzature e sedi tecniche da S/4HANA.
• Il pacchetto di servizio per Service Cloud V2 con S/4HANA: ordini di servizio in entrambe le direzioni, contratti e offerte di servizio da S/4HANA, ordini di reso e un ordine di vendita successivo per la fatturazione.

Distribuire significa copiare il pacchetto nel tenant Integration Suite, configurare connessioni e mappature dei valori e attivare gli iFlow. Prima Integration Suite deve essere attivata nel sottoaccount BAIP e i communication arrangement devono esistere in S/4HANA. I team che trattano questa preparazione come una nota a piè di pagina perdono di solito uno sprint all’inizio della fase di integrazione. La documentazione di SAP Integration Suite copre il lato piattaforma.

Dove vive il caso, dove vive l’evasione

L’architettura parte da una divisione dei compiti voluta. Il caso vive in Service Cloud V2. Lì confluiscono tutti i canali (e-mail, telefono, portale clienti) in un unico oggetto, con categorie di caso, accordi sui livelli di servizio, escalation e tutta la comunicazione con il cliente. L’operatore vede a colpo d’occhio chi chiede, che cosa è già successo e quanto tempo resta prima della violazione dello SLA.

L’evasione vive in S/4HANA: ordine di servizio, reso, logistica dei ricambi, conferma, fattura o nota di credito. Dietro questi documenti ci sono gestione delle scorte, contabilità analitica e finanza. Un CRM non dovrebbe provarci: ricostruire giacenze o fatturazione nel CRM significa costruire un secondo ERP, più debole.

Due sistemi, due ruoli. L’integrazione li collega senza mescolarli.

Prima i dati anagrafici, poi il processo

L’errore più frequente in questi progetti è la sequenza. Tutti vogliono costruire subito il flusso di processo: creare l’ordine di servizio dal caso, vedere tornare lo stato. Senza dati anagrafici sincronizzati non funziona nulla.

Clienti. Gli account in Service Cloud V2 e i partner commerciali in S/4HANA devono essere gli stessi record, con una mappatura pulita degli ID tramite la replica standard. I duplicati di oggi diventano domani storici di assistenza duplicati.

Base installata. S/4HANA è il sistema di riferimento per attrezzature, sedi tecniche e contratti di servizio. Gli iFlow standard replicano attrezzature e sedi tecniche in Service Cloud V2, dove compaiono come prodotti registrati sull’account, con numero di serie, prodotto e data di installazione. Quando un cliente chiama, l’operatore vede la macchina, non solo il cliente.

Stato di garanzia e contratto. Anche i contratti di servizio vengono replicati da S/4HANA. Questo rende concreto il triage: l’operatore vede se il difetto è in garanzia o coperto da un contratto prima di impegnarsi in un intervento a pagamento.

La mappatura tra gli oggetti tecnici di S/4HANA e il modello dei prodotti registrati di Service Cloud V2 richiede attenzione. Il contenuto standard gestisce la traduzione principale, ma campi personalizzati e regole di gerarchia vanno configurati esplicitamente. Preveda uno sprint. L’integrazione dei dati anagrafici non è spettacolare, ma decide se l’integrazione di processo richiederà poi settimane o mesi.

Dal caso all’ordine di servizio fino alla fattura

È il flusso transazionale centrale, quello che elimina la maggior parte del lavoro manuale che i team di assistenza detestano:

1. Il caso nasce in Service Cloud V2, qualunque sia il canale. Chiamata, e-mail o richiesta dal portale finiscono tutti nello stesso caso, collegato al cliente e al prodotto registrato.
2. L’operatore classifica e verifica. Categoria del caso impostata, garanzia e diritti verificati sui dati replicati da S/4HANA, orologio dello SLA avviato.
3. Si crea il documento successivo. Dal caso l’operatore crea un ordine di servizio, che l’iFlow standard replica in S/4HANA. A seconda dello scenario può trattarsi anche di un ordine di reso.
4. S/4HANA evade. I ricambi vengono riservati a magazzino, tempi e materiali del tecnico vengono confermati sull’ordine di servizio e la fatturazione avviene in S/4HANA, dove il contenuto standard può creare un ordine di vendita successivo per la fatturazione.
5. Lo stato torna nel caso. L’ordine di servizio S/4HANA viene replicato in Service Cloud V2 con il suo stato e l’operatore informa il cliente dal caso.

L’ultimo punto è il più importante: la comunicazione con il cliente resta nel CRM. Il cliente ha un solo interlocutore, un solo filo e un solo storico, e viene a sapere tramite il caso che cosa succede nell’ERP.

Un esempio tipico è una consegna che arriva danneggiata. Arriva la chiamata, il caso viene creato con la categoria «danno da trasporto» e le foto inviate via e-mail si allegano allo stesso caso. L’operatore controlla la consegna nel documento S/4HANA collegato e avvia reso e sostituzione. Non appena S/4HANA conferma la sostituzione, l’aggiornamento parte verso il cliente dal caso. Un processo, un riferimento, nessuna ricerca.

Ricambi e passaggio a FSM

Nelle aziende di assistenza con molte attrezzature, la disponibilità dei ricambi è spesso il percorso critico. Le prenotazioni si fanno sull’ordine di servizio S/4HANA, quindi i pezzi sono legati all’intervento e non alla scorta del furgone di un tecnico. Per le organizzazioni con più magazzini è ciò che rende affidabili le promesse di disponibilità.

Quando serve un intervento sul campo e la pianificazione diventa impegnativa (turni, competenze, percorsi), SAP Field Service Management è il livello di pianificazione e di esecuzione mobile. Il caso resta in Service Cloud V2, la pianificazione avviene in FSM, e tempi e materiali confermati dal tecnico vengono registrati sull’ordine di servizio S/4HANA per la fatturazione. Si decida un unico innesco guida per l’intervento, di solito l’ordine di servizio S/4HANA, e lo si documenti: due sistemi che possono entrambi creare interventi FSM per lo stesso caso producono visite doppie. I nostri articoli su FSM con S/4HANA Public Cloud e la checklist di integrazione tra FSM, Sales Cloud e S/4HANA entrano nei dettagli.

Che cosa vede l’operatore dell’assistenza

Un operatore che passa da CRM a ERP a FSM per rispondere a una sola domanda sbaglia e impiega troppo tempo. Nella configurazione integrata, l’operatore in Service Cloud V2 vede:

• Base installata: attrezzature, numeri di serie e stato del contratto (da S/4HANA)
• Ordini di servizio: gli ordini lato ERP collegati al caso e il loro stato (da S/4HANA)
• Contratti e offerte di servizio: replicati da S/4HANA
• Storico dei casi: casi precedenti, note di risoluzione e tempi di risoluzione (nativi in Service Cloud V2)

L’operatore non ha bisogno di lavorare in S/4HANA per rispondere al cliente. Per le organizzazioni in cui assistenza sul campo ed ERP appartengono a team diversi è un vero cambiamento: chi parla con il cliente ha il contesto senza aspettare un collega della logistica.

Che cosa si è dimostrato valido nei progetti

Tenere piccola la tassonomia dei casi. Un albero di categorie con quaranta rami al go-live significa che gli operatori scelgono la voce più vicina e che la reportistica perde valore. La nostra regola: da cinque a otto categorie all’inizio, poi affinare dopo tre mesi sulla base dei casi reali.

Collegare la telefonia. Nell’assistenza B2B il telefono resta il canale più forte. Un’integrazione CTI che identifica il chiamante e mostra il contesto del cliente mentre il telefono sta ancora squillando fa risparmiare il primo minuto di ogni chiamata. Abbiamo realizzato più volte adattatori CTI per Service Cloud V2; si veda come funziona lo screen pop nativo nell’agent desktop.

Lasciare il modello di stato dell’ERP nell’ERP. Il caso non ha bisogno di un gemello di ogni stato dei documenti S/4HANA; ha bisogno della risposta alla domanda del cliente: in lavorazione, in viaggio, concluso. Chi rispecchia ogni flusso documentale mantiene da quel momento due modelli di stato.

Mantenere le gerarchie in un solo posto. Le gerarchie di prodotti e attrezzature hanno una sola casa, l’ERP, e da lì vengono replicate. Due gerarchie mantenute a mano divergono; l’unica domanda è quando.

Modelli di integrazione clean core

Il principio clean core di SAP per S/4HANA Public Cloud significa nessuna modifica al codice SAP. La stessa disciplina vale per il livello di integrazione.

Copiare, poi configurare. SAP mantiene gli iFlow standard e ne distribuisce gli aggiornamenti. Chi modifica direttamente un iFlow standard perde la possibilità di applicare quegli aggiornamenti in modo pulito. Lo si copia, si fa la modifica nella copia e si documenta la differenza.

Logica personalizzata su BAIP. Regole di instradamento per tipo di attrezzatura e regione, o trigger di escalation per livello di contratto, vanno in un’applicazione CAP o in un iFlow personalizzato su SAP BAIP, non nei workflow di Service Cloud V2 o nei processi di servizio di S/4HANA. La nostra guida alle estensioni clean core con SAP CAP mostra il modello.

Una sola piattaforma di integrazione. Tutti i flussi (dati anagrafici, dal caso all’ordine di servizio, FSM, stato di fatturazione) passano dallo stesso tenant Integration Suite: una sola vista di monitoraggio, una sola coda di errori, un solo team responsabile. Le chiamate punto a punto tra sistemi sono un problema di manutenzione annunciato.

Avvisi dal primo giorno. I pacchetti standard includono la gestione degli errori, ma qualcuno deve decidere chi viene avvisato quando un messaggio fallisce, qual è la politica di ripetizione e chi corregge che cosa. Nella consegna dei progetti questo viene spesso saltato e diventa una lacuna al primo errore in produzione.

Che cosa si ottiene alla fine

Un caso tracciabile dalla prima chiamata alla nota di credito. Un operatore che vede garanzia e stato della consegna senza cambiare sistema. Un cliente che chiama una volta invece di tre. E due sistemi che restano nello standard, perché nessuno dei due imita il lavoro dell’altro.

Se lo pianifica su entrambi i lati, aiuta avere un unico team per le due metà; è la tesi della nostra guida alla scelta di un partner SAP per Cloud ERP e CRM in Svizzera. Se S/4HANA Public Cloud è ancora davanti a Lei, l’assessment di prontezza S/4HANA chiarisce prima il punto di partenza.

Domande frequenti

Un caso in SAP Service Cloud V2 può creare un ordine di servizio in S/4HANA Public Cloud?

Sì. L’operatore crea dal caso un ordine di servizio in Service Cloud V2 e il pacchetto di integrazione standard di SAP lo replica in S/4HANA, dove si gestiscono ricambi, conferme e fatturazione. L’ordine di servizio S/4HANA viene replicato indietro con il suo stato, così l’operatore può rispondere al cliente dal caso senza aprire l’ERP.

Come fluiscono i dati della base installata tra S/4HANA e Service Cloud V2?

S/4HANA è il sistema guida. Il pacchetto SAP per i dati anagrafici replica attrezzature e sedi tecniche da S/4HANA Public Cloud a Service Cloud V2, dove compaiono come prodotti registrati sull’account del cliente. L’operatore vede nel caso numero di serie, data di installazione e stato del contratto, e la gerarchia non viene mai mantenuta due volte.

Come si inserisce SAP Field Service Management?

FSM è il livello di pianificazione degli interventi e di esecuzione mobile. Si decide un unico innesco per l’intervento sul campo, di norma l’ordine di servizio S/4HANA, e FSM lo pianifica e lo esegue. Tempi e materiali confermati dal tecnico vengono registrati sull’ordine di servizio, che poi guida la fatturazione in S/4HANA.

Service Cloud V2 sostituisce uno strumento di ticketing separato?

Per l’assistenza rivolta ai clienti sì: ricezione omnicanale, categorie di caso, SLA, knowledge base e storico del cliente sono inclusi, e il collegamento all’ERP è il vero vantaggio rispetto a uno strumento di ticketing generico. Per il ticketing IT interno uno strumento dedicato resta spesso la scelta migliore, perché si tratta di un altro caso d’uso.

Quale impegno è realistico per il flusso dal caso alla risoluzione?

Dipende soprattutto dai dati anagrafici. Se account e attrezzature si replicano già in modo pulito, il flusso dal caso all’ordine di servizio richiede settimane, perché il contenuto di integrazione SAP copre i flussi documentali. Diventa costoso quando mancano i dati anagrafici o quando si costruisce una logica di stato personalizzata in uno dei due sistemi.

---

I Suoi reclami finiscono in una casella di posta condivisa e il Suo team di assistenza cerca lo stato delle consegne nell’ERP? Le mostriamo il flusso con i Suoi processi di assistenza. Parli con il nostro team.