Vi serve davvero SAP CPQ? Una guida onesta alla decisione accanto a S/4HANA Public Cloud

Pochi prodotti SAP finiscono sulla shortlist così in fretta come CPQ. Le vendite vogliono offerte più rapide, il consulente licenze annuisce, e all’improvviso c’è un prodotto in più nell’architettura target, prima che qualcuno abbia chiesto quale problema debba risolvere. La domanda raramente è se SAP CPQ sia buono. Lo è. La domanda è se il vostro processo di offerta abbia bisogno della macchina che state comprando insieme. Dai nostri progetti attorno a S/4HANA Public Cloud e Sales Cloud V2 sappiamo che in circa la metà dei casi la risposta onesta è no. Questo articolo è la guida alla decisione che avremmo voluto avere all’inizio di alcune valutazioni.

Cosa è davvero SAP CPQ

CPQ sta per Configure, Price, Quote. Il prodotto consegna queste tre lettere su scala industriale:

• Guided selling: un percorso guidato da domande porta il venditore al prodotto giusto invece di farlo navigare tra cataloghi. Prezioso quando l’assortimento è così ampio che nemmeno i commerciali esperti conoscono ogni combinazione.
• Regole complesse: regole di compatibilità e vincoli tra componenti. Se motore X, allora mai cambio Y; se variante di tensione A, allora accessorio obbligatorio B. Il regolamento impedisce che offerte tecnicamente impossibili escano dall’azienda.
• Matrici di approvazione a più livelli: soglie di sconto con un workflow vero. Fino al 5 per cento decide il venditore, fino al 12 il direttore vendite, oltre la direzione, tutto tracciato.
• Generazione di proposte: documenti d’offerta con il vostro brand, blocchi di testo, immagini e riepiloghi prezzi, generati invece che assemblati in Word.
• Vendita indiretta e partner: portali in cui rivenditori e partner configurano e quotano in autonomia, con proprie liste prezzi e regole di visibilità.

È tanta macchina. Costa licenze, implementazione e manutenzione continua. Proprio per questo vale uno sguardo sobrio prima che l’inchiostro si asciughi.

L’albero decisionale dai nostri progetti

Negli anni si è consolidato da noi un albero decisionale semplice. Non è scienza, ma nei progetti ha retto.

Niente CPQ se valgono tutti e tre i punti: meno di una decina di caratteristiche per famiglia di prodotto, solo vendita diretta senza canale rivenditori, e prezzi che il venditore imposta manualmente o con una semplice logica di prezzo indicativo. In questa costellazione un’offerta snella nel CRM più l’Advanced Variant Configuration nell’ERP va in produzione prima, costa meno in esercizio ed è più facile da imparare per la forza vendita. Come appare concretamente questa architettura lo descrive il nostro articolo sulla configurazione varianti.

CPQ si ripaga appena domina uno di questi schemi: regole di compatibilità che non stanno più in una manciata di caratteristiche. Un canale partner o rivenditori che deve quotare in autonomia. Approvazioni sconti formali che oggi passano per e-mail e a voce e regolarmente vanno storte. Oppure documenti d’offerta che devono fare da biglietto da visita, perché il concorrente si presenta con PDF curati.

La zona grigia in mezzo esiste, naturalmente. Il nostro consiglio lì: costruire prima la via snella, misurare il processo per sei mesi, poi decidere. Un CPQ si può aggiungere in seguito. Smontare una piattaforma sovradimensionata è molto più doloroso.

Il quadro d’integrazione quando CPQ è deciso

Quando la decisione cade su CPQ, il suo posto è definito con chiarezza: tra Sales Cloud V2 e S/4HANA Public Cloud. L’opportunità vive nel CRM. Da lì nasce l’offerta in CPQ, dove avvengono configurazione, pricing e approvazione. L’ordine vinto va in S/4HANA, dove distinta base, ciclo di lavoro e produzione prendono il timone.

Due punti fanno la differenza tra successo e cantiere permanente. Primo, la sincronizzazione dei prezzi varianti: prezzi e valori di caratteristiche rilevanti per il prezzo vanno tenuti allineati tra i modelli AVC in S/4HANA e CPQ, altrimenti le vendite quotano prezzi che il calcolo costi non confermerà mai. Secondo, e più importante: non modellate mai le stesse regole due volte. Chi duplica l’intero regolamento AVC in CPQ mantiene due verità dal primo giorno, e divergeranno. Decidete per tipo di regola dove vive la verità di configurazione: logica di vendita in CPQ, logica di produzione in AVC, e l’interfaccia tra le due più stretta possibile.

Tre lezioni che nessuna scheda tecnica menziona

Dai progetti, in forma anonima ma reali:

1. La governance del regolamento è il costo nascosto. Costruire le regole è il problema minore. Mantenerle quando i prodotti cambiano è quello maggiore. Nominate un responsabile, una persona con nome e cognome, non un comitato, e fissate una revisione trimestrale. Senza questo ritmo il regolamento invecchia in silenzio e le vendite si costruiscono scorciatoie.
2. Le matrici di approvazione devono rispecchiare la vera politica di firma, non inventarne una nuova. La tentazione di riformare le deleghe insieme allo strumento è forte. Resistetele. Un workflow che non corrisponde alla prassi vissuta viene aggirato, e a quel punto avete costi di licenza più un processo ombra.
3. Misurate il tempo di ciclo dell’offerta prima e dopo. Dalla richiesta all’offerta inviata, in ore. Senza il valore di partenza non c’è business case, solo una sensazione di pancia. Con quel valore, dopo sei mesi vedrete nero su bianco se l’investimento si regge.

Domande frequenti

CPQ può calcolare i prezzi dalle condizioni di S/4HANA?

Sì. CPQ può collegarsi alla logica di pricing di S/4HANA e usare le condizioni come base; in alternativa mantiene proprie liste prezzi, tenute aggiornate via sincronizzazione. Decisivo è stabilire quale sistema guida il prezzo. Due logiche di prezzo mantenute in parallelo sono lo stesso errore di due regolamenti.

CPQ sostituisce l’Advanced Variant Configuration?

No, i due si completano. CPQ vende: guided selling, regole di vendita, documento d’offerta. AVC produce: super-distinta base, ciclo di lavoro, calcolo costi. Chi vuole spegnere l’AVC perché è arrivato CPQ confonde la vista commerciale con quella di produzione, e sposta il problema in fabbrica.

Qual è una tempistica realistica per un’introduzione di CPQ?

Per una prima linea di prodotto con un regolamento pulito e i collegamenti verso Sales Cloud V2 e S/4HANA Public Cloud calcoliamo da quattro a sei mesi. Poi il modello cresce linea per linea. Voler modellare tutte le famiglie di prodotto in un colpo solo diventa de facto un progetto pluriennale, e ve ne accorgerete solo al secondo anno.

E se vogliamo solo offerte più rapide, senza tutto l’apparato?

Allora la via snella è di solito quella giusta: offerta in Sales Cloud V2, caratteristiche come campi, configurazione solo nell’ordine S/4HANA. È esattamente lo schema descritto nell’articolo sulla configurazione varianti citato sopra. CPQ lo potrete sempre aggiungere quando il canale rivenditori o il regolamento arriveranno davvero.

Siete davanti a esattamente questa decisione? Guardiamo il vostro processo di offerta e vi diciamo onestamente se CPQ vale la licenza, anche se la risposta è no. Parlate con noi.