BDC nella pratica: dai dati grezzi di S/4 e CX alle decisioni

L’apertura di questa serie ha spiegato la teoria; questo articolo mostra la pratica. Descrive come pianifichiamo una prima implementazione di Business Data Cloud per un’azienda svizzera di medie dimensioni sullo stack SAP integrato: la tempistica, i punti di attrito e il momento in cui inizia a ripagare.

In sintesi: Un primo progetto BDC dovrebbe coprire un dominio e una domanda che la direzione già pone. Il nostro piano dura da sei a otto settimane: attivazione e un workshop sulle chiavi di collegamento, un modello semantico (di solito pipeline-to-cash), un’app analitica e poi una riunione di direzione che lavora su un unico numero. L’attivazione è rapida e la modellazione veloce quando i data product portano con sé la semantica; il lavoro vero è l’accordo su chiavi e responsabili, quindi mettete a budget i workshop, non la piattaforma.

Questo è il piano che raccomandiamo, non il resoconto di un cliente specifico. Le durate presuppongono chiavi di collegamento sufficientemente pulite; dove non lo sono, lo diciamo nella prima settimana e adattiamo il piano.

Il punto di partenza

L’azienda tipo a cui pensiamo ha da 150 a 400 dipendenti, usa S/4HANA Public Cloud o è in procinto di farlo, ha Sales Cloud V2 in produzione e tiene insieme le sue analisi con delle esportazioni. Il lunedì mattina qualcuno in sales operations scarica le opportunità in un foglio di calcolo, qualcuno nel controlling scarica l’ingresso ordini; i due file si incontrano in una tabella pivot con colonne di ricerca mantenute a mano.

Funziona, ed è per questo che sopravvive. Ma costa giornate di lavoro ogni settimana e, in ogni riunione di direzione, la stessa discussione su quale numero sia quello giusto.

Il piano in sintesi

Fase	Settimane	Risultato	Chi è coinvolto
Attivazione e responsabilità	1 e 2	Tenant attivo, data product sottoscritti, chiavi e responsabili concordati	IT, sales operations, controlling
Modello semantico	3 e 4	Un modello governato per un dominio	Controlling, Spadoom
App e riunione	5 e 6	Un’app analitica, prima riunione di direzione	Sponsor, direzione
Riserva	7 e 8	Pulizia delle chiavi alla fonte, se la prima settimana ha evidenziato criticità storiche	Responsabili dei dati

Settimane 1 e 2: attivazione e workshop sulle responsabilità

Attivare il tenant e sottoscrivere i data product è la parte veloce. SAP descrive un data product come un insieme di dati raffinato, i metadati che lo descrivono e un punto di accesso o un’API (SAP News). Nell’annuncio di lancio, SAP ha indicato i dati finanziari, di approvvigionamento e di supply chain di S/4HANA tra i primi data product gestiti da SAP (SAP News). Per Sales Cloud V2 verificate il catalogo della vostra release; dove l’entità necessaria non è ancora fornita come data product, replicatela tramite Datasphere e gestitela come data product proprio (SAP Help).

Il vero lavoro della prima settimana è un workshop che nessuno strumento sostituisce: concordare le chiavi di collegamento e chi ne è responsabile. Account e business partner, opportunità e ordine di vendita, materiale e prodotto. Dove la corrispondenza ha una storia (account duplicati, opportunità mai collegate agli ordini), la correggiamo alla fonte o la mappiamo in modo esplicito. È qui che la sequenza per la base dati di un articolo precedente di questa serie ripaga, oppure va recuperata.

Settimane 3 e 4: il modello semantico

Un dominio, modellato dall’inizio alla fine. Per la maggior parte delle aziende è il pipeline-to-cash: opportunità vinte collegate all’ingresso ordini e al fatturato, per organizzazione di vendita, gruppo di prodotti e periodo. L’articolo sui modelli di integrazione ne descrive la meccanica.

La modellazione procede in fretta dove i data product portano la semantica. Lo sforzo va nell’ultimo miglio dell’azienda: le definizioni dei KPI, le particolarità dell’anno fiscale e i campi di estensione. Mantenete il perimetro volutamente stretto. La tentazione di aggiungere «già che ci siamo» i dati del servizio o l’attribuzione di marketing nella terza settimana è ciò che trasforma un progetto di sei settimane in uno di sei mesi. Quello è il dominio due. Se preferite un primo dominio guidato dalla finanza, partire dal margine di servizio segue la stessa disciplina.

Settimane 5 e 6: l’app e la prima riunione

Il risultato è un’app analitica (una story di SAP Analytics Cloud o una piccola app su misura) che risponde alle domande poste dallo sponsor nella prima settimana: dove si trova la pipeline rispetto al forecast, quanto era preciso il forecast dell’ultimo trimestre rispetto al fatturato, quali trattative si sono mosse. Va alle persone che l’hanno chiesta, con una breve presentazione invece di un programma di formazione.

SAP offre anche intelligent application preconfezionate su BDC. A ottobre 2025 erano disponibili Finance Intelligence, People Intelligence e Cloud ERP Intelligence Private, mentre Revenue Intelligence era in anteprima limitata (SAP News). Verificate cosa è disponibile per la vostra release prima di costruire qualcosa che SAP fornisce già.

L’obiettivo della prima riunione di direzione è semplice: vendite e finanza guardano la stessa vista pipeline-to-cash, e il tempo normalmente speso a riconciliare i numeri va alle decisioni che stanno dietro.

Cosa cambia dopo

Progettiamo il lavoro in funzione di tre effetti:

• La disciplina del forecast migliora senza nuove direttive. Quando la precisione del forecast è misurata rispetto al fatturato e mostrata ogni mese, i venditori tengono aggiornate le opportunità perché il numero è visibile.
• Il dominio due costa meno del dominio uno. Le chiavi sono allineate, le responsabilità definite, la piattaforma è in piedi. La redditività del servizio (i casi di Service Cloud V2 rispetto ai margini contrattuali) è un passo successivo naturale.
• Il discorso sull’AI diventa concreto. Con un modello governato alla base, un agente Joule che risponde a «come sta andando il Q4 rispetto al forecast?» legge gli stessi numeri del CFO. La guida pratica a Joule mostra come si presenta in Sales Cloud V2. L’ultimo articolo della serie approfondisce la dipendenza dell’AI dai dati.

Perché un unico team per ERP e CRM aiuta

La maggior parte dell’attrito delle prime due settimane nasce al confine tra CRM ed ERP: quale sistema gestisce il cliente, come un’opportunità diventa un ordine, dove risiedono i prezzi. Se lo stesso team ha configurato entrambi i lati, queste risposte sono già documentate. È l’argomento che sviluppiamo nella guida al partner per ERP e CRM, e vale per l’analisi quanto per i processi. Se state ancora pianificando il passaggio all’ERP, lo S/4HANA Readiness Assessment è il luogo per portare presto le domande sui dati.

Lo schema da ricordare: l’attivazione è rapida, la modellazione veloce, l’allineamento è il lavoro. Mettete a budget i workshop, non la piattaforma.

Domande frequenti

Quanto dura una prima implementazione BDC?

Per un primo perimetro mirato pianifichiamo da sei a otto settimane: un dominio di business, i data product standard disponibili da S/4HANA più i dati CRM replicati dove serve, e un’app analitica. Questo presuppone che le chiavi di collegamento fra CRM ed ERP siano in gran parte pulite. Responsabilità irrisolte sui dati anagrafici e chiavi con una lunga storia allungano il progetto; lo stack cloud SAP integrato, dove le chiavi sono allineate per progettazione, lo accorcia.

Di quale team ho bisogno da parte mia?

Più piccolo di quanto molti si aspettino: una persona responsabile della domanda di business (di solito sales operations o controlling), una che conosce la storia dei dati e l’accesso a chi amministra i tenant SAP. A questa scala, per il primo dominio BDC rende superfluo un team dedicato di data engineering.

Quanto costa la gestione dopo il go-live?

BDC è concesso in licenza a consumo in capacity unit, e i dettagli dipendono dal vostro contratto. Da parte vostra, la cura del modello richiede in genere una frazione di un posto a tempo pieno una volta che il primo dominio è operativo. Confrontatelo con gli estrattori, i job di warehouse e le ore di riconciliazione su fogli di calcolo che sostituisce, non con zero.