Da SAP CPQ a S/4 Public Cloud: dal preventivo all’ordine

In sintesi: il passaggio dal preventivo all’ordine funziona quando il preventivo accettato diventa l’ordine previsto in S/4HANA Public Cloud senza essere ricreato. Prima del go-live stabilite un responsabile per ogni decisione (identità del prodotto, configurazione, prezzo, sconto, accettazione dell’ordine), poi testate cosa succede dopo l’approvazione: quantità modificate, prezzi scaduti, nuovi invii e rifiuti dell’ERP. Scrivete prima il risultato atteso, partite da una sola famiglia di prodotti e misurate le rilavorazioni rispetto alla vostra situazione di partenza.

Il cliente accetta il preventivo. Poi qualcuno lo ricrea nell’ERP perché configurazione, sconto o codice prodotto non coincidono. Il preventivo è stato più rapido, ma il lavoro manuale si è semplicemente spostato nella gestione degli ordini.

La domanda utile quindi non è se SAP CPQ sappia produrre un’offerta curata. È se l’offerta accettata diventa l’ordine previsto in S/4HANA Public Cloud, con il giusto contesto commerciale in Sales Cloud V2. Se state ancora valutando se CPQ vi serve davvero, partite dalla nostra guida alla decisione su CPQ accanto a S/4HANA Public Cloud. Questo articolo presuppone che la decisione sia presa e che ora il passaggio debba reggere.

Verificare il percorso di integrazione esatto

SAP documenta l’integrazione di Sales Cloud Version 2 con CPQ tramite SAP Cloud Integration, un’integrazione degli ordini di vendita per CPQ Quote 2.0 lato S/4HANA e l’integrazione di Sales Cloud V2 con S/4HANA Public Cloud per la simulazione dei prezzi e il trasferimento degli ordini. Questo dimostra che gli scenari sono supportati. Non risolve ogni requisito del vostro processo di ordine.

Prima di scegliere i contenuti di integrazione fissate quattro elementi: il motore CPQ e la versione del preventivo, la release Public Cloud, gli scope item attivati e l’API con cui l’ordine viene effettivamente creato (ad esempio l’API degli ordini di vendita sul SAP Business Accelerator Hub). Una vecchia guida di Sales Cloud o un esempio generico di S/4HANA non dimostrano la vostra architettura di destinazione. Il percorso completo dall’opportunità alla fattura è descritto in quote to cash con Sales Cloud V2 e S/4HANA Public Cloud.

Un responsabile per ogni decisione

Decisione	Cosa chiarire
Identità del prodotto	Come corrispondono la riga del preventivo e il materiale ERP, anche per i materiali configurabili?
Configurazione	Quale motore valuta le regole di questa famiglia di prodotti: CPQ, Advanced Variant Configuration o entrambi con una suddivisione chiara?
Prezzo	Quale sistema determina il valore commerciale finale, per ogni elemento di prezzo?
Sconto	Chi approva le eccezioni e quando scade un’approvazione?
Accettazione dell’ordine	Quale risposta dell’ERP rende il passaggio riuscito?

La riga sulla configurazione merita un secondo sguardo. Se CPQ vende e l’Advanced Variant Configuration in S/4HANA produce, decidete per tipo di regola dove risiede la verità. Un insieme di regole mantenuto due volte finisce per divergere, e la divergenza si manifesta come un ordine che la produzione non può realizzare.

L’ultima riga è la più importante. Una risposta HTTP positiva non è necessariamente un ordine accettato. Definite su quale stato ERP il commerciale può contare (creato, bloccato per credito, incompleto, rifiutato), dove questo stato diventa visibile nel CRM e cosa succede quando la verifica dell’ERP rifiuta la richiesta.

Testare le modifiche dopo l’approvazione

Usate un prodotto configurabile di esempio con due opzioni, una combinazione non compatibile e uno sconto soggetto ad approvazione. Approvate un preventivo valido, poi modificate la quantità, l’indirizzo di consegna o un’opzione.

Da questo test nascono tre domande. Quali modifiche attivano un nuovo calcolo? Quali invalidano l’approvazione? E cosa succede se il cliente accetta una versione precedente del preventivo?

Mantenete la versione accettata riconoscibile in tutti i sistemi: numero e versione del preventivo in CPQ, il riferimento sull’opportunità in Sales Cloud e il riferimento esterno sull’ordine ERP. È un controllo di business quanto un requisito di interfaccia, perché è ciò che revisione e servizio clienti chiederanno quando un ordine viene contestato.

Includere i casi che escono dal flusso standard

Caso di test	Risultato atteso da scrivere prima
Prezzo scaduto tra preventivo e accettazione	Nuovo calcolo o nuova approvazione, mai il vecchio prezzo in silenzio
Materiale non abilitato alla vendita nell’ERP	Rifiuto visibile al commerciale, con motivazione
Anagrafica cliente incompleta nell’ERP	Ordine bloccato o rifiutato, con una persona designata per correggere i dati
Stesso preventivo accettato inviato due volte	Un solo ordine ERP, non due
Preventivo rivisto dopo il passaggio	Una regola chiara su chi può modificare l’ordine ERP
Combinazione di opzioni non valida	Bloccata in CPQ, non arriva mai all’ERP

Scrivete i risultati attesi prima della demo. Altrimenti una sequenza di schermate convincente può nascondere un processo d’ordine irrisolto. Il caso del doppione in particolare costa poco da testare e molto da scoprire in produzione, perché si presenta proprio con un nuovo invio dopo un timeout.

Decidere se CPQ è il primo passo giusto

Configurazioni complesse, frequenti eccezioni di approvazione e rilavorazioni ripetute delle offerte sono buoni motivi per valutare CPQ. Da BDTronic le regole di compatibilità di oltre 1’400 componenti erano raccolte in un documento di 60 pagine e un preventivo su otto conteneva un errore di configurazione. Dopo l’introduzione di CPQ i tempi dei preventivi si sono ridotti del 70% e gli errori di configurazione sono scomparsi. È il profilo in cui le regole giustificano la licenza.

Un catalogo ridotto con prezzi semplici può avere bisogno prima di dati più puliti e di un flusso esistente migliore. Non acquistate un motore di configurazione per sopperire a una responsabilità di prodotto che manca.

Partite da una sola famiglia di prodotti e da un solo percorso dalla vendita all’ordine. Misurate rilavorazioni, passaggi rifiutati e tempi di approvazione rispetto alla vostra situazione di partenza, senza prendere in prestito la percentuale di un altro cliente.

Domande frequenti

Esiste un’integrazione standard tra SAP CPQ e S/4HANA Public Cloud?

SAP documenta contenuti di integrazione: Sales Cloud V2 con CPQ tramite SAP Cloud Integration e, lato S/4HANA, un’integrazione degli ordini di vendita per CPQ Quote 2.0. Quale scenario si applica dipende dal motore CPQ, dalla release Public Cloud e dagli scope item attivati: verificatelo sui vostri sistemi prima di progettare.

Qual è l’errore più frequente nel passaggio dal preventivo all’ordine?

Un successo tecnico che non è un successo di business: l’interfaccia segnala il messaggio come elaborato, ma l’ordine nell’ERP è bloccato, incompleto o con un prezzo diverso da quello accettato. Definite quale stato ERP vale come ordine accettato e chi interviene quando l’ERP rifiuta la richiesta.

Quale sistema deve determinare il prezzo finale?

Uno solo, deciso per ogni elemento di prezzo e messo per iscritto. CPQ può calcolare l’offerta commerciale oppure leggere le condizioni da S/4HANA; entrambe le soluzioni funzionano. Due logiche di prezzo mantenute in parallelo no, perché preventivo e fattura finiscono per divergere.

Quanti casi di test servono per una prima release CPQ?

Meno di quanto si teme, se sono quelli giusti. Una famiglia di prodotti configurabile, una combinazione valida e una non valida, uno sconto soggetto ad approvazione, una modifica dopo l’approvazione, un nuovo invio e un rifiuto dell’ERP coprono la maggior parte degli errori costosi. Scrivete il risultato atteso di ogni caso prima della prima demo.

---

CPQ, Sales Cloud V2 e il lato S/4HANA formano un’unica catena, e noi li implementiamo tutti e tre con un solo team. Perché questo conta proprio in questo punto di contatto lo spiegano la guida al partner ERP e CRM e l’articolo sullo stack SAP integrato. Portate un preventivo reale a Spadoom: ne ricostruiamo regole di prodotto, decisioni di prezzo e passaggio all’ERP prima di proporre un perimetro di progetto.