Quote-to-cash tra SAP Sales Cloud V2 e S/4HANA Public Cloud: chi possiede quale documento?

Quando un CRM e un ERP portano lo stesso processo di vendita, una domanda decide se l’integrazione dura per anni o diventa un cantiere permanente: chi possiede quale documento? Non quale interfaccia si sceglie né quale strumento di mappatura, ma in quale sistema nasce un’offerta, dove nasce l’ordine e chi ha il diritto di modificare che cosa. Quasi ogni integrazione quote-to-cash problematica che ci è stato chiesto di sistemare non aveva, all’inizio, una risposta chiara a questa domanda.

Per SAP Sales Cloud V2 e S/4HANA Public Cloud la risposta chiara esiste. Deriva dal contenuto di integrazione standard di SAP, se lo si legge con coerenza. Eccola, compresi i punti in cui i progetti inciampano di solito.

In sintesi: Ogni oggetto ha esattamente un sistema guida. Clienti, prodotti e prezzi sono guidati da S/4HANA Public Cloud; l’offerta da Sales Cloud V2; l’ordine di vendita nasce in S/4HANA come documento successivo e viene replicato indietro in sola lettura. I prezzi vengono simulati in tempo reale in S/4HANA invece di essere mantenuti due volte. Definisca il livello di stato delle offerte e un elenco governato dei motivi di rifiuto prima di costruire il primo iFlow, e concordi chi corregge quale messaggio fallito.

La matrice di responsabilità: un oggetto, un sistema guida

La regola di base è semplice: ogni oggetto ha esattamente un sistema guida. Lì viene creato e modificato. Altrove è una copia, e le copie sono in sola lettura.

Oggetto	Sistema guida	Nell’altro sistema
Clienti (partner commerciali)	S/4HANA Public Cloud	replicati nel CRM
Prodotti	S/4HANA Public Cloud	replicati nel CRM, in sola lettura
Prezzi e condizioni	S/4HANA Public Cloud	simulati in tempo reale dall’offerta, non mantenuti nel CRM
Offerta	Sales Cloud V2	diventa un ordine di vendita successivo in S/4HANA
Ordine di vendita	S/4HANA Public Cloud	replicato nel CRM, in sola lettura

L’offerta nasce nel CRM perché lì lavorano le vendite: opportunità, storico dei contatti e attività in un’unica vista. L’ordine di vendita nasce in S/4HANA perché lì vivono disponibilità, limite di credito, logistica e fatturazione. Il passaggio avviene come documento successivo tramite gli iFlow standard di SAP Integration Suite, pubblicati sul SAP Business Accelerator Hub come pacchetto di integrazione per i processi di vendita tra Sales Cloud V2 e S/4HANA Cloud Public Edition. Nella direzione opposta, l’ordine compare nel CRM come documento replicato che le vendite possono vedere ma non modificare.

Questa matrice va appesa alla parete della sala di progetto prima di distribuire il primo iFlow. Conta più di qualsiasi documento di progettazione tecnica. Per il quadro tecnico completo si veda l’architettura di integrazione di Sales Cloud V2.

Prezzi in tempo reale: una sola verità sui prezzi, non due

La parte più elegante di questa architettura è quella che non viene mantenuta due volte: i prezzi. Mentre il commerciale inserisce una riga, l’offerta del CRM viene simulata in S/4HANA e il prezzo torna con condizioni, prezzi specifici del cliente, scaglioni e sconti. SAP descrive la configurazione nella guida sull’integrazione di Sales Cloud V2 con S/4HANA Cloud Public Edition per simulazione e trasferimento.

Il pacchetto SAP per i dati anagrafici può anche replicare le condizioni di prezzo nel CRM. Noi usiamo la simulazione ovunque la connessione lo consenta. Non appena i prezzi vengono mantenuti o calcolati in due posti, ci sono due verità sui prezzi, e prima o poi qualcuno fa un’offerta con quella sbagliata. Con i prezzi in tempo reale c’è un unico luogo in cui si mantengono le condizioni, e l’offerta calcola con gli stessi numeri dell’ordine e poi della fattura: nessun job di riconciliazione, nessuna conversazione imbarazzante sul perché offerta e fattura non coincidono.

Due insidie da progetti reali

L’architettura qui sopra è ordinata. Nella nostra esperienza i progetti non sono inciampati sulla tecnologia, ma su due dettagli funzionali che nessuno aveva chiarito prima della realizzazione.

Insidia 1: lo stato vinto/perso viveva su due livelli. In un progetto l’ERP gestiva lo stato dell’offerta a livello di testata: un’offerta è vinta o persa. Il CRM gestiva lo stesso stato per singola posizione, perché un cliente può ordinare tre articoli su cinque. Entrambe le scelte sono difendibili; tutte e due insieme sono un veleno. Le analisi del tasso di successo nel CRM contavano posizioni, la reportistica ERP contava testate, e alla direzione venivano mostrate due cifre molto distanti. Definisca il livello di stato una sola volta, identico sui due lati, prima di costruire il primo pezzo di integrazione. Cambiarlo dopo costa molte volte di più.

Insidia 2: motivi di rifiuto come testo libero. Perché un’offerta è stata persa? Con un campo di testo libero si ottengono «prezzo», «troppo caro», «prezzo troppo alto», «concorrente più economico» e altre quaranta varianti dello stesso motivo, e la reportistica è morta prima di nascere. I motivi di rifiuto vanno in un elenco di valori governato, mappato in modo identico sui due lati, con un responsabile che approva i nuovi valori. Un’ora di governance nella fase di concetto fa risparmiare anni di analisi inutili.

Se le Sue offerte comprendono prodotti configurabili, la stessa logica di responsabilità vale per la configurazione; il nostro articolo sulle offerte per prodotti configurabili con Sales Cloud V2 e AVC mostra come, e quando serve SAP CPQ con S/4HANA Public Cloud tratta il caso più complesso.

Monitoraggio: chi corregge che cosa

Replica significa messaggi asincroni, e i messaggi asincroni ogni tanto falliscono: un cliente senza numero IVA valido, un prodotto bloccato, un valore di mappatura che non esiste nel sistema di destinazione. È normale. Non è normale che nessuno se ne accorga.

Il monitoraggio dei messaggi di Integration Suite mostra ogni messaggio fallito con contenuto e motivo dell’errore. A questo si aggiungono avvisi che raggiungono una persona con nome e cognome invece di prendere polvere in una casella condivisa. Poi va chiarita la questione delle responsabilità prima del go-live: l’amministratore CRM corregge ciò che nasce nel CRM (dati dell’offerta, campi obbligatori mancanti, mappature dei valori lato CRM); il key user ERP corregge ciò che ha origine nell’ERP (errori nei dati anagrafici, problemi di condizioni, partner commerciali bloccati). Senza questa ripartizione, ogni messaggio fallito rimbalza tra due team prima che qualcuno lo tocchi.

L’unica regola che tiene insieme tutto

Se porta via una sola frase da questo articolo, sia questa: lo stesso tipo di documento non deve mai essere modificabile in due sistemi. Nel momento in cui un ordine può essere cambiato nel CRM e nell’ERP, inizia la corsa tra versioni, e l’integrazione diventa un arbitro che può solo perdere. L’integrazione standard di SAP applica in gran parte la regola da sola, perché i documenti replicati sono in sola lettura nell’altro sistema. Resista a ogni richiesta di ammorbidirla con un’estensione; l’eccezione che oggi sembra comoda è il workshop di riconciliazione di dopodomani.

È anche il punto in cui finanza e vendite si incontrano, ed è per questo che pianifichiamo il quote-to-cash con consulenti ERP e CRM nella stessa stanza; la nostra guida al miglior partner SAP per Cloud ERP e CRM in Svizzera spiega perché conta, e lo stack integrato S/4HANA Public Cloud e Sales Cloud V2 mostra il quadro completo.

Domande frequenti

Gli ordini si possono creare anche direttamente nel CRM?

Tecnicamente sì: Sales Cloud V2 ha un oggetto ordine di vendita e il contenuto standard di SAP può replicarlo in S/4HANA. Raccomandiamo comunque offerta nel CRM e ordine nell’ERP, perché l’ordine ha bisogno di disponibilità, limite di credito e dati logistici da S/4HANA. Un ordine registrato nel CRM è al massimo una preregistrazione che viene ricontrollata nell’ERP, cioè un posto in più in cui mantenere dati.

Le offerte vengono replicate da S/4HANA Public Cloud nel CRM?

Non come offerte di Sales Cloud V2. Il contenuto standard può creare un’offerta successiva in S/4HANA da un’opportunità e conserva il riferimento sull’opportunità, ma le offerte create nell’ERP non diventano offerte del CRM. È un motivo in più per far nascere le offerte nel CRM, così la visione commerciale resta completa.

E la forza vendita sul campo senza copertura di rete?

I prezzi in tempo reale richiedono una connessione a S/4HANA. Offline, la forza vendita può registrare articoli e quantità, e il prezzo vincolante viene calcolato quando il dispositivo torna online. Per l’incontro con il cliente, un prezzo indicativo sull’anagrafica prodotto, chiaramente segnalato come non vincolante, ha funzionato bene per noi.

Che cosa succede quando una replica fallisce?

Il messaggio resta nel monitoraggio dei messaggi di SAP Integration Suite con contenuto e motivo dell’errore e può essere rielaborato dopo la correzione. Decisivi sono gli avvisi e una ripartizione delle responsabilità concordata prima: l’amministratore CRM per le cause lato CRM, il key user ERP per errori di dati anagrafici e condizioni. Allora un errore è questione di minuti, non di settimane.

---

Sta pianificando l’integrazione tra Sales Cloud V2 e S/4HANA Public Cloud, o quella esistente produce due verità? Appendiamo insieme a Lei la matrice di responsabilità alla parete. Se S/4HANA Public Cloud è ancora davanti a Lei, cominci dall’assessment di prontezza S/4HANA. Parli con il nostro team.