Implementazione di SAP Commerce Cloud: che cosa succede davvero in un progetto

Gran parte dei contenuti sulle implementazioni di SAP Commerce Cloud sembra un opuscolo commerciale. Questo articolo descrive che cosa succede davvero in un progetto: le decisioni che contano, le fasi che durano più del previsto e le abitudini che distinguono un go-live tranquillo da uno doloroso.

SAP Commerce Cloud è una piattaforma matura, ma una piattaforma matura non rende semplice un’implementazione. Budget e tempi raramente saltano per colpa del software; saltano per decisioni prese troppo tardi, dati che nessuno ha esaminato e integrazioni che nessuno ha pianificato.

In sintesi: le implementazioni di SAP Commerce Cloud durano in genere da tre a nove mesi, a seconda del perimetro. Quattro fasi decidono il risultato: discovery (decisioni architetturali e analisi delle personalizzazioni), sviluppo (rilasci iterativi in sprint di due-quattro settimane), integrazione (ERP, PIM, pagamenti, spedizioni) e go-live (migrazione dei dati, test di prestazione, passaggio in produzione). Il workshop di discovery e l’analisi delle personalizzazioni si ripagano più volte durante lo sviluppo.

Cercate un partner invece di una guida fai da te? Spadoom è SAP Gold Partner e realizza SAP Commerce Cloud in Svizzera, Germania, Austria e Italia, sia la Cloud Edition sia la nuova ERP Edition, insieme al nucleo ERP. Richiedete un colloquio di scoping o leggete il caso di studio Franke.

Fase	Durata tipica	Contenuti
Discovery	Da due a quattro settimane	Architettura, requisiti, analisi delle personalizzazioni
Sviluppo	Da sei a sedici settimane	Modello dati, storefront, sprint iterativi
Integrazione	Da quattro a otto settimane, in parallelo allo sviluppo	ERP, PIM, pagamenti, spedizioni
Go-live	Da tre a quattro settimane	Test di accettazione, test di prestazione, migrazione dei dati, passaggio in produzione

Che cosa succede durante la discovery?

Nella discovery i progetti si vincono o si perdono. È qui che emerge il debito tecnico della piattaforma precedente, prima che faccia deragliare lo sviluppo.

Una discovery solida (da due a quattro settimane) comprende:

Decisioni architetturali. SAP Composable Storefront o frontend su misura? Quanti ambienti? Quale pipeline CI/CD? Sono scelte difficili da cambiare in seguito.

Analisi delle personalizzazioni. In caso di migrazione dall’on-premise, ogni personalizzazione va classificata: ancora necessaria, sostituibile con funzioni standard oppure obsoleta. Di solito una parte consistente si rivela eliminabile, e ogni personalizzazione che cade è codice da non migrare né mantenere.

Analisi dei dati. Si esaminano catalogo prodotti, anagrafiche clienti, storico degli ordini e contenuti, per individuare i problemi di qualità prima che blocchino la migrazione. I progetti perdono settimane quando nessuno guarda i dati di prodotto prima del quarto sprint.

Mappa delle integrazioni. Si documenta ogni connessione in entrata e in uscita: ERP, PIM, CRM, pagamenti, spedizioni, fiscalità, analytics. Per ciascuna: protocollo, formato dei dati, frequenza e gestione degli errori.

Struttura del team e governance. Chi è responsabile di cosa, come si prendono le decisioni, demo settimanali o revisioni mensili. I progetti con una governance poco chiara si trascinano.

Come dovrebbe svolgersi la fase di sviluppo?

Le implementazioni di Commerce Cloud funzionano meglio con un approccio iterativo: sprint di due-quattro settimane, ciascuno con un risultato funzionante.

Sprint 1: modello dati e configurazione di base. Tipi personalizzati, struttura del catalogo, regole di prezzo, motore delle promozioni. L’obiettivo è un catalogo funzionante in staging entro le prime settimane.

Sprint 2 e 3: storefront e checkout. Si pubblica lo storefront con i dati di prodotto e si costruiscono checkout, logica del carrello e gestione dell’account. Ogni sprint produce qualcosa che i referenti possono usare e commentare.

Dallo sprint 4: logica di business e casi particolari. Prezzi specifici per cliente e per quantità, giacenze su più magazzini, funzioni B2B come flussi di approvazione, limiti di acquisto e gerarchie di acquirenti.

La disciplina che conta: ogni sprint si chiude con un sistema funzionante che i referenti possono testare. «Vi mostreremo qualcosa al quarto mese» è troppo tardi per correggere la rotta.

Perché l’integrazione è la parte più difficile?

L’integrazione è spesso il blocco di lavoro più grande. Queste sono le connessioni che contano di più.

ERP (SAP S/4HANA, ECC). Esportazione degli ordini, allineamento delle giacenze, prezzi, dati anagrafici dei clienti. Di solito è l’integrazione più complessa e quella che deve funzionare: se gli ordini non arrivano all’ERP, il resto non conta. Il modulo di integrazione di SAP per la gestione ordini con S/4HANA copre prezzi e giacenze in tempo reale, verifiche del credito e creazione sincrona degli ordini per il B2B sul Composable Storefront, ma la mappatura sulla configurazione del vostro ERP resta lavoro di progetto. Noi realizziamo lato commerce e lato ERP con un unico team; il nostro articolo sullo stack integrato S/4HANA Public Cloud e Sales Cloud V2 spiega perché è importante. Se dietro c’è ancora SAP ECC, pianificate l’integrazione commerce sul sistema di destinazione: la nostra pagina sulla fine della manutenzione di SAP ECC nel 2027 mostra scadenze e percorsi di migrazione.

PIM. Flussi di dati di prodotto, media, gerarchie di classificazione. Se il PIM è il sistema di riferimento per i dati di prodotto, serve un’integrazione in tempo reale o quasi.

Pagamenti. Collegamento al fornitore di pagamento, tokenizzazione, 3-D Secure, rimborsi. Commerce Cloud supporta diverse estensioni di pagamento, e scegliere e configurare quella giusta conta più di quanto si pensi.

Spedizioni e logistica. Calcolo delle tariffe, stampa delle etichette, tracciamento. Spesso con più corrieri e API diverse.

L’approccio che funziona: avviare lo sviluppo delle integrazioni in parallelo agli ultimi sprint di sviluppo, senza aspettare che la piattaforma sia «finita». Altrimenti una lunga fase di integrazione si aggiunge a uno sviluppo già lungo.

Che cosa comporta davvero il go-live?

Test di accettazione (due-tre settimane). Gli utenti di business, non gli sviluppatori, testano ogni flusso critico con dati reali. Trovano ciò che gli sviluppatori non troverebbero mai.

Test di prestazione. Test di carico con traffico realistico, inclusa la simulazione di un giorno di picco, verifica dell’autoscaling e tempi di caricamento rispetto agli obiettivi. Della scalabilità dell’infrastruttura si occupa Commerce Cloud, ma il vostro codice e le vostre query devono comunque essere efficienti.

Prova generale della migrazione dei dati. Si esegue l’intera migrazione dall’inizio alla fine e se ne misura la durata: definisce la finestra di passaggio. Si testa la migrazione differenziale per i dati creati durante la transizione.

Passaggio in produzione. Si segue il piano di go-live: congelamento del vecchio sistema, migrazione differenziale, cambio del DNS, verifica dei flussi principali e monitoraggio per 48 ore con tutto il team a disposizione. Da lì in poi conta la misurazione: quali KPI seguire e quali strumenti collegare è spiegato nel nostro articolo su analytics e prestazioni del negozio in Commerce Cloud.

Chi migra da SAP Commerce on-premise deve tenere presente che la manutenzione mainstream della versione on-premise è terminata il 31 luglio 2026; le opzioni sono descritte nel nostro articolo su cosa fare ora che il supporto on-premise è terminato.

Che cosa distingue le buone implementazioni da quelle cattive?

Investire nella discovery. I progetti che dedicano da due a quattro settimane a una discovery accurata risparmiano un multiplo di quel tempo durante lo sviluppo. Quelli che la saltano passano lo sviluppo a scoprire ciò che avrebbero dovuto pianificare.

Disciplina sul perimetro. Il rischio maggiore non è tecnico: è l’allargamento del perimetro. «Già che ci siamo, aggiungiamo anche…» trasforma un progetto di quattro mesi in uno di nove. Si definisce la prima release, la si pubblica e poi si prosegue. Non si dice no per sempre: si dice non ancora.

Prima l’integrazione. L’architettura di integrazione si imposta già nella discovery e lo sviluppo delle integrazioni parte nello sprint 2 o 3. La piattaforma serve a poco finché non è collegata all’ERP.

Per la piattaforma in sé c’è la nostra panoramica su SAP Commerce Cloud, insieme ai passi di configurazione più sotto. Per il budget, la nostra guida a prezzi e TCO scompone i costi di licenza, implementazione ed esercizio. Chi confronta partner trova i criteri nella nostra panoramica dei migliori partner SAP Commerce Cloud in Svizzera.

Come si configura SAP Commerce Cloud passo dopo passo?

Sul piano tecnico la configurazione di Commerce Cloud attraversa dieci passi. Modellazione dei dati e integrazione ERP determinano il percorso critico; la maggior parte dei ritardi nasce dal sottovalutare uno dei due.

1. Predisposizione degli ambienti: SAP mette a disposizione il Cloud Portal e tre ambienti (sviluppo, staging, produzione), ciascuno con database, indice di ricerca e configurazione propri.
2. Struttura del progetto: scegliere una recipe (B2C, B2B o personalizzata), attivare le estensioni necessarie e decidere il frontend; la configurazione della build sta in manifest.json.
3. Modellazione dei dati: estendere il modello di prodotti, clienti e cataloghi tramite il type system e mapparvi i dati di prodotto esistenti.
4. Configurazione dello storefront: tema, navigazione, template CMS e content slot, layout responsive e impostazioni SEO.
5. Integrazione ERP: prezzi e disponibilità in tempo reale, dati anagrafici dei clienti, replica degli ordini e verifiche del credito, di solito tramite SAP Integration Suite.
6. Pagamenti e spedizioni: provider di pagamento, modalità di consegna per paese e un motore fiscale per le vendite transfrontaliere.
7. Creazione dei contenuti: testi di prodotto, immagini e landing page in SmartEdit; i grandi volumi tramite ImpEx o Hot Folder.
8. Test: funzionali, di integrazione, di prestazioni, di sicurezza, su browser e dispositivi.
9. Ottimizzazione delle prestazioni: caching, indice di ricerca, distribuzione via CDN, query sul database e autoscaling per i picchi.
10. Go-live e stabilizzazione: deploy, cambio DNS e da due a quattro settimane di monitoraggio stretto.

Volete aiuto a tradurre tutto questo in pratica?

Spadoom realizza SAP Commerce Cloud dall’inizio alla fine: la Cloud Edition per il B2B e il B2C enterprise, la ERP Edition per le aziende di medie dimensioni su S/4HANA Public Cloud e le migrazioni da Hybris on-premise. Da Franke abbiamo ripreso una piattaforma in stallo, portato online il lancio commerce in 90 giorni e ridotto gli ordini manuali del 75%; il progetto ha ricevuto lo SAP Quality Award per «Rapid Time to Value». Ogni nostro progetto parte da un workshop di discovery che definisce l’architettura, mappa le integrazioni e produce una pianificazione realistica. Parliamone.

Domande frequenti

Quanto dura un’implementazione tipica di SAP Commerce Cloud?

Dipende dal perimetro. La maggior parte dei progetti dura da tre a nove mesi: una migrazione dall’on-premise con un volume moderato di personalizzazioni spesso da tre a sei mesi, una nuova implementazione B2B con più storefront, molte integrazioni e logica di business propria da sei a nove mesi. Da Franke il lancio della piattaforma commerce è andato online in 90 giorni. La variabile principale è la complessità delle integrazioni, non la configurazione della piattaforma.

Quanto costa un’implementazione di SAP Commerce Cloud?

Per i progetti di aziende di medie dimensioni i costi di implementazione si collocano di solito nell’ordine delle centinaia di migliaia di franchi; programmi enterprise complessi possono superare il milione. I principali fattori di costo sono il numero di integrazioni, la complessità delle personalizzazioni, il volume dei dati, il numero di storefront e mercati e il fatto di migrare da un sistema SAP esistente o di partire da zero.

Che team serve per un progetto SAP Commerce Cloud?

Un progetto tipico di medie dimensioni richiede da tre a cinque consulenti di implementazione (SAP Commerce, frontend, integrazione) e da due a tre persone lato cliente (product owner, business analyst, referente IT). Il ruolo più importante è il product owner lato cliente, perché decide sul perimetro e fornisce il contesto di business. I progetti senza un product owner dedicato durano sistematicamente di più.

Meglio il Composable Storefront o un frontend su misura?

Nella maggior parte dei progetti conviene partire dallo SAP Composable Storefront: è integrato con la piattaforma, sviluppato attivamente e copre gli scenari standard B2B e B2C. Un frontend su misura in React o Next.js ha senso se serve un’esperienza utente radicalmente diversa o si gestiscono più storefront molto diversi tra loro; allunga lo sviluppo di alcune settimane e richiede sviluppatori frontend dedicati per la manutenzione. Il nostro confronto tra Composable Storefront e React/Next.js entra nei dettagli.

Qual è la causa più frequente degli sforamenti di budget nelle implementazioni Commerce Cloud?

Una complessità di integrazione non valutata correttamente nella discovery, seguita dall’allargamento del perimetro durante lo sviluppo. Entrambe si evitano con una discovery disciplinata che mappa ogni integrazione e classifica ogni personalizzazione, e con una prima release definita con chiarezza.

Come funziona il deployment?

La configurazione del progetto si trova in un file manifest.json nel repository del codice. Nel Cloud Portal si crea una build da un branch e la si distribuisce negli ambienti di sviluppo, staging o produzione. I deployment di tipo rolling consentono aggiornamenti della produzione senza interruzioni del servizio.