Webshop B2B su SAP Commerce Cloud con S/4HANA Public Cloud alle spalle: quali dati dove?

Chi costruisce un webshop B2B su SAP Commerce Cloud con un S/4HANA Public Cloud alle spalle risponde in fondo sempre alla stessa domanda, solo in quattro varianti: i dati migrano nello shop, o lo shop li recupera in diretta dall’ERP nel momento della verità? Chi risponde a questa domanda con una regola unica costruisce o uno shop lento o un ERP sovraccarico. La risposta giusta cambia per classe di dati, ed è esattamente il tema di questo articolo.

La domanda di fondo: replicare o chiamare in tempo reale?

Quattro classi di dati, quattro decisioni. Dalla nostra esperienza di progetto, la ripartizione è questa:

Prodotti e catalogo: replicare. L’anagrafica prodotti migra per replica verso Commerce Cloud e lì viene arricchita: testi di vendita, immagini, attributi per la ricerca a faccette, albero delle categorie, dati SEO. Tutto questo non appartiene all’ERP, ma allo shop, dove i team di contenuto ci lavorano. L’ERP resta il master strutturale: numero di materiale, unità e classificazione arrivano da S/4HANA e non vengono mai sovrascritti nello shop. I cataloghi cambiano abbastanza raramente perché qui una replica basti del tutto.

Prezzi specifici del cliente: chiamare in tempo reale. Nel B2B quasi ogni cliente ha le proprie condizioni: prezzi contrattuali, scaglioni, schemi di sconto. Questa logica vive in S/4HANA, e lì deve restare. Lo shop recupera il prezzo al momento della visualizzazione tramite una chiamata di pricing, con una cache breve di pochi minuti. Una sola verità dei prezzi, niente export notturni, nessuna seconda logica di prezzo da tenere sincronizzata per anni.

Stock e ATP: chiamare in tempo reale, con cache breve. Nel B2B la disponibilità è una promessa, non una decorazione. Lo shop interroga la disponibilità verso S/4HANA e mette in cache il risultato per minuti, non per ore. Chi replica lo stock solo di notte promette per tutto il giorno merce che non c’è più.

Ordini: iniettare in modo asincrono. L’ordine viene confermato nello shop e poi portato nell’ERP tramite una coda, con una gestione degli errori pulita: se la creazione in S/4HANA fallisce, l’ordine finisce in una coda di errore con allarme, non nel nulla. Lo storico ordini nell’area my-account, invece, viene letto in diretta dalle API di S/4HANA. Così il cliente vede anche gli ordini arrivati per telefono o EDI, non solo quelli dello shop.

Perché il B2B funziona diversamente dal B2C

Le ricette B2C da manuale nel B2B non bastano, per quattro motivi.

Primo, i prezzi. Nel B2C un prezzo vale per tutti, quindi lo si può replicare senza pensarci. Nel B2B il prezzo è una funzione di cliente, quantità, contratto e stato del giorno delle tabelle condizioni. Da qui la chiamata in diretta.

Secondo, il comportamento d’acquisto. I clienti B2B non curiosano, approvvigionano. Modelli d’ordine, riordino dallo storico e inserimento rapido per numero di articolo contano più di qualsiasi messa in scena del prodotto.

Terzo, il limite di credito. Prima del checkout serve un controllo verso il credit management in S/4HANA. Un ordine che nell’ERP finisce subito in blocco credito non aiuta nessuno, meno di tutti il back office che poi dovrà ripescarlo a mano.

Quarto, i canali d’ordine. I grandi clienti ordinano via punch-out direttamente dal loro sistema d’acquisto; quelli medi caricano file CSV con cinquanta posizioni. Entrambi devono alimentare la stessa interfaccia ordini del carrello.

Cosa va storto nei progetti, e come evitarlo

L’errore più frequente che troviamo nelle architetture esistenti è la replica notturna completa dei prezzi. Sembra innocua, finché il primo contratto viene adeguato durante il giorno. Allora lo shop mostra il vecchio prezzo fino al mattino dopo, il cliente ordina, la conferma d’ordine dell’ERP diverge, e il back office può mettersi al telefono. Il rimedio non è una replica più veloce, ma il passaggio al pricing in tempo reale con cache breve. Dopo, esiste esattamente un solo posto dove nascono i prezzi.

Il secondo classico: la registrazione sincrona dell’ordine. Il checkout aspetta finché S/4HANA ha creato l’ordine. Funziona, finché l’ERP è in finestra di manutenzione o installa una release. Allora il checkout si rompe, e proprio per i clienti che volevano inserire l’ordine alle dieci di sera. Gli ordini vanno sempre in una coda: lo shop conferma subito, l’ERP elabora appena può, e gli errori finiscono in una coda monitorata invece che addosso al cliente.

Il terzo punto è meno tecnico che umano: lo zoo di funzionalità. Configuratori, collegamento marketplace, loyalty, tutto in fase uno. Il nostro consiglio è un MVP lato acquisto: catalogo, prezzi specifici del cliente, ordine, storico ordini. È il nucleo con cui un cliente B2B può lavorare in modo produttivo, e va in produzione in mesi, non in anni. Tutto il resto arriva dopo, con priorità date da ciò che manca ai clienti veri nello shop vero.

Costruito una volta, usato più volte

Lo strato di interfacce che nasce qui non è un accessorio dello shop, è un mattone. Chiamata di pricing, controllo ATP, coda ordini e API dello storico sono separati in modo pulito dal frontend. Oggi questo strato serve SAP Commerce Cloud. Domani serve altrettanto bene un’app per la forza vendita, un portale clienti o un altro canale di vendita, senza costruire nulla di nuovo lato ERP. Alla fine, composable significa solo una cosa: l’investimento nello strato API si ripaga di nuovo con ogni frontend in più.

Domande frequenti

S/4HANA Public Cloud ha davvero le API per questo modello?

Sì. Per prezzi, disponibilità, ordini e business partner sono disponibili API OData e SOAP rilasciate, documentate nel SAP Business Accelerator Hub. L’orchestrazione, cioè mapping, coda e gestione errori, la fa SAP Integration Suite. Si lavora nello standard del Public Cloud, senza modifiche, e si resta a prova di release.

Il checkout come ospite funziona nel B2B?

Di regola no, e non è un difetto. I conti B2B sono agganciati al cliente nell’ERP: condizioni, limite di credito, indirizzi di consegna e termini di pagamento sono ancorati lì. Un carrello anonimo non può usare nulla di tutto questo. Ha più senso un percorso di registrazione snello, dietro il quale il back office collega l’account shop al cliente ERP giusto.

Dove vive il contenuto prodotto, nell’ERP o nello shop?

In entrambi, con una chiara divisione dei compiti. L’ERP resta il master strutturale per numero di materiale, unità e classificazione. Commerce Cloud assume il ruolo di un PIM leggero: testi, immagini, attributi, categorie. Un sistema PIM separato serve solo quando più canali consumano lo stesso contenuto in più lingue; prima sarebbe un sistema di troppo.

Quanto deve essere aggiornato lo stock nello shop?

Abbastanza da far reggere la promessa. Una cache di due-cinque minuti sul controllo ATP è il compromesso giusto nella maggior parte degli scenari B2B: protegge l’ERP dai picchi di carico e tiene la visualizzazione abbastanza vicina alla verità. La replica notturna dello stock, al contrario, è de facto un invito ai conflitti di consegna.

State pianificando uno shop B2B su SAP Commerce Cloud, o il vostro shop esistente combatte con prezzi vecchi e ordini bloccati? Vi mostriamo volentieri l’architettura sulle vostre classi di dati. Parlate con noi.