SAP Business Data Cloud: partire dal margine di servizio

La finanza segnala un contratto di servizio redditizio. Il responsabile del servizio vede interventi ripetuti e lavoro non fatturato. Possono avere ragione entrambi, perché contano cose diverse.

In sintesi: Un buon primo caso d’uso per SAP Business Data Cloud è una metrica contesa con una decisione alle spalle. Il margine di servizio si presta: definire la misura per iscritto, collegare i dati finanziari di S/4HANA con quelli contrattuali e di field service, riconciliare a mano un campione di contratti e solo dopo aggiungere dashboard o AI. Il risultato è una lista di contratti da esaminare, non un data lake.

È un punto di partenza migliore di «mettere tutti i dati in un unico posto». Si parte da una decisione: quali contratti richiedono attenzione, e perché? L’esempio che segue è un esercizio di progettazione illustrativo, non un risultato ottenuto presso un cliente.

Definire la metrica prima di collegare le fonti

Per questo esempio, definite un margine di contribuzione come ricavo di servizio fatturato meno i costi concordati di manodopera, materiale e prestazioni esterne. Decidete in modo esplicito se includere trasferte, interventi in garanzia, note di credito e costi generali. Non chiamate «margine di servizio» due misure con perimetri diversi.

Concordate il periodo di riferimento, la conversione valutaria e il trattamento delle registrazioni tardive. Una dashboard non può risolvere una definizione contabile che l’azienda non ha concordato.

Un esempio di calcolo (cifre illustrative)

Un contratto di manutenzione su un trimestre, con numeri inventati:

Voce	CHF
Ricavo di servizio fatturato	48’000
Manodopera alla tariffa interna concordata (120 ore)	-18’000
Ricambi consumati	-9’500
Subappaltatore esterno	-4’000
Contribuzione (definizione A)	16’500
Tempo di viaggio non fatturato (30 ore)	-4’500
Intervento in garanzia, non addebitabile	-2’200
Contribuzione (definizione B)	9’800

La finanza, con la definizione A, vede un sano 34 per cento. Il responsabile del servizio, che convive con trasferte e garanzie, vede circa il 20 per cento. Nessuno dei due sbaglia. La differenza sta nella definizione, e nessuna piattaforma la risolve al posto vostro. Mettete per iscritto la definizione scelta, assegnatele un responsabile nel controlling e date un altro nome all’altra variante, se vi serve ancora.

Da dove arrivano i dati

Una misura del margine di servizio richiede di solito quattro tipi di record:

• Valore finanziario da S/4HANA: fatture, ordini di servizio e le registrazioni di costo collegate. È la verità contabile e la base della misura concordata. In SAP S/4HANA Public Cloud questi oggetti sono standard, il che mantiene gestibile la mappatura.
• Dati contrattuali: perimetro, prezzo, livelli di servizio e ciò che è addebitabile. Senza di essi non si distingue il lavoro non fatturato da quello incluso.
• Attività di field service: interventi, tempi e materiali confermati da SAP Field Service Management (SAP Help). Spiegano il numero, ma non sostituiscono il valore registrato.
• Dati anagrafici: chiavi di cliente, equipment e materiale che permettono di collegare le tre fonti.

Quanto questi record si colleghino in modo pulito dipende dall’integrazione operativa. La nostra checklist di integrazione per FSM, Sales Cloud e S/4HANA Public Cloud tratta i passaggi che in seguito decidono se un collegamento analitico funziona.

Cosa apporta BDC

SAP ha presentato Business Data Cloud nel febbraio 2025 (SAP News). Riunisce SAP Datasphere, SAP Analytics Cloud, SAP BW e SAP Databricks (SAP Learning). SAP descrive un data product come un insieme di dati raffinato, i metadati che lo descrivono e un punto di accesso o un’API; la documentazione sui data product spiega come si attivano e si utilizzano i data product gestiti da SAP.

Verificate il catalogo attuale e le vostre autorizzazioni per le fonti effettivamente necessarie. L’esistenza di BDC non significa che ogni campo FSM o contrattuale sia già disponibile esattamente come il data product che serve alla vostra metrica. Dove non esiste, replicate la fonte tramite Datasphere e gestitela come data product proprio, con la stessa disciplina su responsabilità e definizioni applicata da SAP. Per il quadro generale, vedete che cos’è SAP Business Data Cloud.

Mantenere piccolo il primo contratto sui dati

Elemento	Accordo necessario
Granularità	Un contratto, un ordine di servizio o un intervento?
Chiavi	Come si collegano record commerciali, di servizio e finanziari?
Aggiornamento	Quanto possono essere vecchi i dati per questa decisione?
Responsabilità	Chi spiega un valore mancante o contestato?
Accesso	Chi può vedere costi, dati dei clienti e informazioni sui tecnici?

Usate i documenti finanziari dell’ERP per la misura finanziaria concordata. Aggiungete il contesto del field service dove spiega il risultato. Tenete distinti stato operativo e valore contabile: un intervento completato non equivale a un ricavo registrato.

L’accesso merita una decisione a sé. Tariffe di costo interne, nomi dei clienti e tempi dei tecnici sono dati personali o commercialmente sensibili secondo la LPD svizzera e, per i clienti nell’UE, il GDPR. Date alla finanza i costi, ai responsabili del servizio i propri contratti, e mantenete aggregato il dettaglio a livello di tecnico salvo una ragione documentata.

Riconciliare prima di aggiungere l’AI

Scegliete un piccolo campione di contratti. Riconciliate i totali con i documenti sottostanti e chiedete a finanza e servizio di spiegare insieme le differenze. Verifichiamo almeno questi casi:

1. Una nota di credito emessa dopo la chiusura del periodo.
2. Una correzione tardiva dei tempi da parte di un tecnico.
3. Un lavoro che si estende su due periodi di riferimento.
4. Un contratto con una variazione di prezzo nel trimestre.
5. Un intervento in garanzia che dovrebbe generare costi ma nessun ricavo.

Solo allora ha senso una sintesi AI come «quali contratti sono cambiati in modo significativo questo mese?». La sintesi dovrebbe indicare i documenti e le definizioni alla base della risposta. Frasi plausibili non sostituiscono la riconciliazione.

Un primo perimetro in quattro passi

1. Workshop sulla definizione (finanza, servizio, controlling): scegliere la definizione A o B, la logica di periodo e il responsabile.
2. Verifica delle fonti: stabilire quali data product esistono per la vostra release e quali fonti vanno replicate.
3. Riconciliazione a campione: da dieci a venti contratti, i cinque casi di test sopra, differenze spiegate per iscritto.
4. Lista di lavoro: pubblicare il risultato per le persone che decidono e rivederlo ogni mese.

Rendere il risultato utilizzabile

Un risultato utile è una breve lista di lavoro: contratto, motivo della verifica, responsabile e prossima azione. Un contratto può richiedere una pulizia della fatturazione, un altro una modifica del processo di servizio. Lo stesso margine basso non implica lo stesso rimedio.

BDC non sostituisce l’integrazione operativa che crea gli ordini, pianifica i tecnici o registra le conferme. Analisi ed elaborazione delle transazioni richiedono test di accettazione diversi.

Domande frequenti

Perché iniziare SAP Business Data Cloud dal margine di servizio?

Perché è un numero conteso con una decisione chiara alle spalle: quali contratti di servizio richiedono attenzione e perché. Richiede dati della finanza (S/4HANA), dei contratti e del field service, quindi mette alla prova i collegamenti su cui si basa ogni caso d’uso successivo, restando abbastanza piccolo da essere riconciliato a mano.

Quali fonti di dati servono per una misura del margine di servizio?

Di norma fatture, ordini di servizio e registrazioni di costo di S/4HANA per il valore finanziario, i dati contrattuali per perimetro e prezzi, e interventi, conferme di tempo e materiale di SAP Field Service Management per il contesto operativo. Verificate il catalogo dei data product BDC per la vostra release; dove SAP non fornisce un data product per una fonte, replicatela tramite Datasphere e gestitela come data product proprio.

L’AI può spiegare il margine di servizio prima che i numeri siano riconciliati?

Non dovrebbe. Una sintesi AI su una misura non riconciliata produce frasi plausibili su un numero che nessuno ha concordato. Riconciliate prima un campione di contratti, poi lasciate che un assistente riassuma le variazioni, sempre indicando i documenti e le definizioni alla base della risposta.

Chi dovrebbe accedere ai dati sul margine di servizio?

Meno persone di quanto suggerisca il pubblico di una dashboard. Tariffe di costo, dati dei clienti e tempi dei tecnici sono sensibili secondo la LPD svizzera e il GDPR. Definite i ruoli prima del go-live: la finanza vede i costi, i responsabili del servizio vedono i propri contratti e il dettaglio a livello di tecnico resta aggregato, salvo un’esigenza documentata.

Parlate di un primo data product con Spadoom. Portate una metrica contesa e la decisione che dovrebbe supportare. Questo dà alla valutazione un confine concreto.