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 sola domanda decide se l’integrazione regge per anni o diventa un cantiere permanente: chi possiede quale documento? Non quale interfaccia si sceglie, non quale strumento di mapping. Ma: in quale sistema nasce l’offerta, dove nasce l’ordine, e chi può modificare cosa? Dall’esperienza di progetto possiamo dirlo: quasi ogni integrazione quote-to-cash faticosa che siamo stati chiamati a risanare non aveva, all’inizio, una risposta chiara a questa domanda.

Per la combinazione SAP Sales Cloud V2 e S/4HANA Public Cloud esiste una risposta pulita. Non la troverete in nessun singolo documento SAP, ma emerge dallo standard se lo si legge con coerenza. Eccola, compresi i punti in cui nei progetti ci siamo già scottati le dita.

La matrice di proprietà: un oggetto, un sistema leader

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

L’offerta nasce nel CRM perché lì vivono le vendite: opportunità, storico contatti, attività, tutto in un’unica vista. L’ordine cliente nasce in S/4HANA perché lì sono agganciati disponibilità, limite di credito, logistica e fatturazione. Il passaggio dall’una all’altro corre come documento successivo attraverso gli iFlow standard di SAP Integration Suite. E nella direzione di ritorno: l’ordine compare nel CRM come documento replicato, che le vendite vedono ma non toccano.

Questa matrice merita la parete della sala progetto prima che il primo iFlow venga deployato. De facto conta più di qualsiasi documento di design tecnico.

External pricing: una sola verità di prezzo, non due

La parte più elegante di questa architettura è quella che non replica nulla: la determinazione prezzi. L’offerta CRM richiama in tempo reale la determinazione prezzi di S/4HANA. Condizioni, prezzi specifici del cliente, scaglioni, sconti: tutto arriva dall’ERP nel momento esatto in cui il venditore inserisce la posizione.

Perché conta: appena i prezzi vengono manutenuti in due sistemi, esistono due verità di prezzo, e prima o poi qualcuno quota con quella sbagliata. Con l’external pricing esiste esattamente un solo luogo di manutenzione delle condizioni, l’ERP, e l’offerta nel CRM calcola con gli stessi numeri dell’ordine e della fattura più avanti. Nessuna replica notturna dei prezzi, nessun job di riconciliazione, nessuna conversazione imbarazzante con il cliente sul perché offerta e fattura non combaciano.

Due trappole dalla pratica

L’architettura qui sopra suona ordinata, e lo è. Nella nostra esperienza i progetti non sono falliti sulla tecnica, ma su due dettagli funzionali che nessuno aveva chiarito prima della costruzione dell’integrazione.

Trappola 1: lo stato vinto/perso viveva su due livelli. In uno dei nostri progetti l’ERP tracciava lo stato dell’offerta a livello di testata: un’offerta è vinta o persa, punto. Il CRM tracciava lo stesso stato per posizione, perché un cliente può ovviamente ordinare tre posizioni su cinque. Entrambe le scelte sono difendibili. Entrambe insieme sono veleno: l’analisi del win rate nel CRM contava posizioni, il reporting ERP contava testate, e al management sono state presentate due verità distanti punti percentuali a due cifre. La lezione: il livello dello stato si definisce una volta sola, identico su entrambi i lati, e prima che il primo mattone di integrazione venga costruito. Prendere la stessa decisione a posteriori costa molte volte di più.

Trappola 2: i motivi di rifiuto come testo libero. Perché un’offerta è stata persa? Se la risposta è un campo di testo libero, ottenete «prezzo», «troppo caro», «prezzo troppo alto», «concorrente più economico» e quaranta altre varianti dello stesso motivo. Così muore ogni reporting prima ancora di iniziare. I motivi di rifiuto appartengono a una lista valori governata, mappata in modo identico su entrambi i lati, con un proprietario che approva i nuovi valori. È un’ora di lavoro di governance in fase di concetto, e vi risparmia anni di analisi inutilizzabili.

Monitoring: chi ripara cosa

Replica significa messaggi asincroni, e i messaggi asincroni prima o poi falliscono. Un cliente senza partita IVA valida, un prodotto bloccato, un valore di mapping che sul lato di destinazione non esiste. È normale. Non è normale che nessuno se ne accorga.

Il message monitoring di Integration Suite mostra ogni messaggio fallito con payload e motivo dell’errore. Sopra ci vuole un alerting che non prenda polvere in una casella condivisa ma raggiunga una persona con nome e cognome. E poi la questione delle responsabilità, da chiarire nota bene prima del go-live: l’amministratore CRM sistema ciò che nasce nel CRM, cioè dati dell’offerta, campi obbligatori mancanti, mapping delle liste valori lato CRM. Il key user ERP sistema ciò che ha radici nell’ERP, cioè errori anagrafici, problemi di condizioni, business partner bloccati. Senza questa separazione arriva il ben noto ping-pong: ogni messaggio fallito viaggia tre volte avanti e indietro tra due team prima che qualcuno lo prenda in mano.

La regola che tiene insieme tutto

Se da questo articolo portate a casa una sola frase, che sia questa: lo stesso tipo di documento non deve mai essere modificabile in due sistemi. Nel momento in cui un ordine è modificabile nel CRM e nell’ERP, comincia la corsa delle versioni, e l’integrazione degrada ad arbitro che può solo perdere. L’integrazione standard di SAP impone questa regola in gran parte da sola, i documenti replicati sono in sola lettura dall’altra parte. Resistete a ogni requisito di ammorbidirla con un’estensione. Ogni eccezione che oggi sembra comoda è il workshop di riconciliazione dati di dopodomani.

Domande frequenti

Si possono creare ordini anche direttamente nel CRM?

Tecnicamente sì, Sales Cloud V2 conosce l’ordine cliente come oggetto. Il pattern pulito resta comunque: offerta nel CRM, ordine nell’ERP. L’ordine ha bisogno di controllo disponibilità, limite di credito e dati logistici, e questi vivono in S/4HANA. Un ordine inserito nel CRM è nel migliore dei casi una pre-registrazione che verrà ricontrollata nell’ERP, quindi un luogo di manutenzione in più.

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

No. La replica delle offerte da S/4HANA Public Cloud verso il CRM non è supportata in standard. Le offerte create nell’ERP non compariranno nel CRM. Un motivo in più per attenersi a: le offerte nascono nel CRM, e la vista delle vendite resta completa.

E la forza vendita esterna senza copertura di rete?

L’external pricing ha bisogno di una connessione all’ERP. Offline il venditore può registrare posizioni e quantità; la determinazione prezzi vincolante parte appena il dispositivo torna online. Per l’appuntamento dal cliente si è dimostrato valido un prezzo indicativo sull’anagrafica prodotti replicata, chiaramente marcato come non vincolante, con il prezzo definitivo che arriva alla sincronizzazione.

Cosa succede quando una replica fallisce?

Il messaggio resta nel message monitoring di Integration Suite, con payload e motivo dell’errore, e può essere rielaborato dopo la correzione. A decidere l’esito sono l’alerting e la ripartizione delle responsabilità definita in anticipo: admin CRM per le cause lato CRM, key user ERP per errori anagrafici e di condizioni. Allora un fallimento del genere è questione di minuti, non di settimane.

State pianificando l’integrazione di Sales Cloud V2 e S/4HANA Public Cloud, o la vostra produce due verità? Mettiamo volentieri la matrice di proprietà alla parete insieme a voi. Parlate con noi.