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 S/4HANA Public Cloud alle spalle risponde sempre alla stessa domanda in quattro varianti: i dati si spostano nel webshop, o il webshop li prende in tempo reale dall’ERP nel momento in cui contano? Chi risponde con una regola unica costruisce un webshop lento o un ERP sovraccarico. La risposta giusta cambia per ciascuna classe di dati, ed è di questo che tratta l’articolo.

In sintesi: Prodotti e catalogo si replicano in Commerce Cloud e lì si arricchiscono. Prezzi specifici del cliente e disponibilità si richiedono in tempo reale a S/4HANA, con una cache di pochi minuti. Gli ordini si inviano in modo asincrono tramite una coda monitorata, e lo storico degli ordini si legge in tempo reale dall’ERP. Il pacchetto di integrazione standard di SAP copre la maggior parte dei flussi; i prezzi in tempo reale sono la parte da progettare consapevolmente.

La domanda centrale: replicare o richiedere in tempo reale?

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

Prodotti e catalogo: replicare. L’anagrafica prodotti confluisce in Commerce Cloud e lì viene arricchita: testi di vendita, immagini, attributi per la ricerca a faccette, albero delle categorie, dati SEO. Nulla di tutto questo appartiene all’ERP; appartiene al webshop, dove ci lavorano i team dei contenuti. L’ERP resta l’anagrafica strutturale: codice materiale, unità e classificazione vengono da S/4HANA e non vengono mai sovrascritti nel webshop. I cataloghi cambiano abbastanza di rado perché la replica basti del tutto.

Prezzi specifici del cliente: richiedere 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. Il pacchetto standard di SAP replica prezzi e sconti nel webshop, il che funziona per i prezzi di listino. Per i prezzi contrattuali facciamo in modo che il webshop interroghi S/4HANA al momento della visualizzazione, sulla base della simulazione dei prezzi dell’ERP, con una breve cache di pochi minuti. Una sola verità sui prezzi, nessuna seconda logica di prezzo da mantenere allineata.

Giacenze e disponibilità: richiedere in tempo reale, con una breve cache. Nel B2B la disponibilità è una promessa, non una decorazione. Il webshop verifica la disponibilità su S/4HANA e mette in cache il risultato per minuti, non per ore. Chi replica le giacenze solo di notte passa la giornata a promettere merce già esaurita.

Ordini: inviare in modo asincrono. L’ordine viene confermato nel webshop, poi spinto nell’ERP tramite una coda con una vera gestione degli errori: se la creazione in S/4HANA fallisce, l’ordine finisce in una coda di errori con un avviso, non in un buco nero. Lo storico degli ordini nell’area cliente, invece, si legge in tempo reale da S/4HANA, così il cliente vede anche gli ordini arrivati per telefono o EDI. Come si svolge il ciclo di vita dell’ordine all’interno del negozio, dal carrello ai resi, è descritto in gestione degli ordini in SAP Commerce Cloud.

SAP pubblica gli elementi costitutivi come pacchetto SAP Commerce Cloud Integration with SAP S/4HANA Cloud sul SAP Business Accelerator Hub: materiali e classificazione, clienti B2B, prezzi e sconti, livelli di giacenza, replica degli ordini verso S/4HANA, notifiche di ordine e di consegna verso il webshop e resi. La documentazione SAP sull’integrazione della gestione ordini con S/4HANA descrive il lato Commerce.

Perché il B2B funziona diversamente dal B2C

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

Primo, i prezzi. Nel B2C vale un prezzo per tutti, quindi lo si può replicare senza pensarci due volte. Nel B2B il prezzo è funzione di cliente, quantità, contratto e stato attuale delle tabelle di condizioni. Da qui la richiesta in tempo reale.

Secondo, il comportamento d’acquisto. I clienti B2B non curiosano, si approvvigionano. Modelli d’ordine, riordino dallo storico e inserimento rapido per codice articolo contano più della messa in scena dei prodotti.

Terzo, il limite di credito. Prima del checkout serve una verifica sulla gestione del credito in S/4HANA. Un ordine che nell’ERP finisce subito in blocco di credito non aiuta nessuno, men che meno il back office che deve sbloccarlo a mano.

Quarto, i canali d’ordine. I grandi clienti ordinano tramite punch-out dal loro sistema di approvvigionamento; quelli di medie dimensioni caricano file CSV con cinquanta posizioni. Entrambi devono alimentare la stessa interfaccia d’ordine del carrello.

Che cosa va storto nei progetti, e come evitarlo

L’errore più comune che troviamo nelle architetture esistenti è la replica notturna completa dei prezzi contrattuali. Sembra innocua finché il primo contratto non viene modificato durante il giorno. Il webshop mostra allora il vecchio prezzo fino al mattino dopo, il cliente ordina, la conferma d’ordine dall’ERP è diversa e il back office si attacca al telefono. La soluzione non è una replica più veloce, ma una richiesta di prezzo in tempo reale con una breve cache.

Il secondo classico è la registrazione sincrona dell’ordine: il checkout aspetta che S/4HANA abbia creato l’ordine. Funziona finché l’ERP non è in una finestra di manutenzione o in un aggiornamento di release. Allora il checkout si blocca, proprio per i clienti che volevano ordinare alle dieci di sera. Gli ordini vanno in una coda: il webshop 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: lo zoo di funzionalità. Configuratori, collegamenti a marketplace, fidelizzazione, tutto nella prima fase. Il nostro consiglio è una prima versione snella: catalogo, prezzi specifici del cliente, ordini, storico degli 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 segue, con priorità secondo ciò che i clienti reali cercano nel webshop reale. Per le aziende B2B più piccole, la SAP Commerce Cloud ERP Edition racchiude gran parte di questo per S/4HANA Public Cloud.

Costruito una volta, usato molte volte

Il livello di interfacce che nasce qui non è un accessorio del webshop, ma un elemento costitutivo. Richiesta di prezzo, verifica di disponibilità, coda degli ordini e API dello storico sono separati in modo pulito dal frontend. Oggi questo livello serve SAP Commerce Cloud; domani serve un’app per la forza vendita, un portale clienti o un altro canale di vendita, senza nuovo lavoro sul lato ERP. È questo che significa composable nella pratica, come descritto nel nostro articolo sul composable commerce nel B2B.

È anche il motivo per cui pianifichiamo webshop ed ERP con un unico team; la nostra guida al miglior partner SAP per Cloud ERP e CRM in Svizzera lo argomenta, lo stack integrato S/4HANA Public Cloud e Sales Cloud V2 mostra il lato CRM dello stesso ERP, e i migliori partner SAP Commerce Cloud in Svizzera indica con chi parlare. Come lo realizziamo in un progetto è descritto nella nostra pagina SAP commerce B2B per i distributori in Svizzera.

Domande frequenti

S/4HANA Public Cloud dispone delle API per questo modello?

Sì. SAP pubblica un pacchetto di integrazione standard per SAP Commerce Cloud e S/4HANA Cloud che copre materiali, clienti B2B, prezzi e sconti, giacenze, ordini, notifiche di ordine e di consegna e resi. Le richieste in tempo reale di prezzo e disponibilità usano API S/4HANA rilasciate, documentate sul SAP Business Accelerator Hub, e SAP Integration Suite gestisce mappatura, code e gestione degli errori senza modifiche.

Il checkout come ospite funziona nel B2B?

Di solito no, e non è una carenza. Gli account B2B dipendono dall’anagrafica cliente nell’ERP, dove sono ancorati condizioni, limite di credito, indirizzi di consegna e termini di pagamento. Un carrello anonimo non può usare nulla di tutto questo. Funziona meglio una registrazione snella, dopo la quale il back office collega l’account del webshop al cliente ERP corretto.

Dove vivono i contenuti di prodotto, nell’ERP o nel webshop?

In entrambi, con una chiara divisione dei compiti. L’ERP resta l’anagrafica strutturale per codice materiale, unità e classificazione; Commerce Cloud fa da PIM leggero per testi, immagini, attributi e categorie. Un sistema PIM separato conviene solo quando più canali usano gli stessi contenuti in più lingue; prima sarebbe un sistema di troppo.

Quanto devono essere aggiornate le giacenze nel webshop?

Abbastanza da mantenere la promessa. Una cache da due a cinque minuti sul controllo di disponibilità è il compromesso giusto nella maggior parte degli scenari B2B: protegge l’ERP dai picchi di carico e mantiene la visualizzazione vicina alla realtà. Una replica notturna delle giacenze invita ai conflitti di consegna.

---

Sta pianificando un webshop B2B su SAP Commerce Cloud, o il Suo webshop attuale soffre di prezzi non aggiornati e ordini bloccati? Le illustriamo l’architettura partendo dalle Sue classi di dati. Parli con il nostro team.