7 errori di SAP Commerce Cloud che fanno deragliare i progetti (e come evitarli)

SAP Commerce Cloud è una piattaforma solida. È però anche abbastanza complessa da far sì che gli stessi errori continuino a far deragliare i progetti, in tutti i settori e con team e budget di ogni dimensione. Gli schemi sono prevedibili, ed è una buona notizia: gli errori prevedibili si possono evitare.

Ecco i sette che vediamo più spesso, ciascuno con il relativo rimedio.

In sintesi: i progetti SAP Commerce Cloud vanno storti per sette motivi ricorrenti: sviluppatori Java generalisti invece di specialisti Commerce, aggiornamenti rinviati, piattaforma troppo personalizzata, requisiti vaghi, prestazioni trascurate, migrazione dei dati pianificata male e test insufficienti. Per ognuno esiste una misura preventiva concreta, e il filo conduttore è decidere presto invece di correggere tardi. Se siete ancora su SAP Commerce on-premise, leggete prima la nostra guida alle opzioni dopo la fine della mainstream maintenance.

Errore 1: assumere sviluppatori Java generalisti invece di specialisti Commerce

Commerce Cloud gira su Java, quindi le aziende assumono buoni sviluppatori Java e si aspettano che siano produttivi dal primo giorno. Non lo saranno.

Commerce Cloud ha un proprio modello dati (il type system), un proprio meccanismo di importazione (ImpEx), una propria architettura di extension, una propria pipeline di build e deployment, e un proprio caching e una propria indicizzazione di ricerca (Solr). Uno sviluppatore Java senior senza esperienza su Commerce Cloud ha bisogno di mesi per entrare nel ruolo e, in quel periodo, commette proprio gli errori architetturali costosi da correggere: personalizzare troppo il type system, compromettere il percorso di aggiornamento, scrivere codice su misura dove sarebbe bastata la configurazione standard.

Abbiamo preso in carico progetti in cui era successo esattamente questo, e la bonifica è costata più di quanto sarebbe costato scegliere le persone giuste fin dall’inizio.

Come prevenirlo: assumete sviluppatori con esperienza comprovata su SAP Commerce Cloud. Chiedete referenze di progetto specifiche e verificate le certificazioni SAP. Se costruite un team interno, affiancate a ogni nuovo sviluppatore un consulente Commerce Cloud esperto per i primi mesi. Se state ancora scegliendo un partner di implementazione, la nostra panoramica dei partner SAP Commerce Cloud in Svizzera indica cosa verificare.

Errore 2: saltare o rinviare gli aggiornamenti

SAP aggiorna Commerce Cloud regolarmente (SAP Help Portal). Ogni aggiornamento porta patch di sicurezza, miglioramenti delle prestazioni, nuove funzionalità e correzioni. Saltarli sembra un risparmio di tempo; in realtà crea un problema che si accumula. Più aspettate, più aggiornamenti si sommano e più difficile diventa l’aggiornamento finale.

Dopo due o tre release saltate, lo sforzo di aggiornamento può avvicinarsi a quello dell’implementazione originale. Il codice personalizzato che funzionava sulla versione N potrebbe non compilare sulla N+3, le dipendenze divergono e i test si moltiplicano. Cambiamenti di piattaforma come il passaggio a Java 21 e Spring 6 lo rendono molto concreto; descriviamo cosa comporta questa migrazione nella nostra guida a Java 21 e Spring 6 in SAP Commerce Cloud.

Come prevenirlo: trattate gli aggiornamenti come manutenzione ordinaria, non come progetti. Riservate ogni anno un budget fisso agli aggiornamenti di Commerce Cloud e applicateli entro un ciclo di release dalla loro disponibilità. Se non riuscite ad aggiornare con questa frequenza, probabilmente le personalizzazioni sono troppe, il che ci porta all’errore 3.

Errore 3: personalizzare troppo la piattaforma

Il framework di extension di Commerce Cloud rende facile modificare quasi tutto. Troppo facile. Ogni extension personalizzata è codice che possedete, mantenete e testate a ogni aggiornamento. Ciascuna aumenta lo sforzo di aggiornamento, allarga la superficie di test e crea potenziali problemi di compatibilità.

Un’installazione con cento o più extension personalizzate può trasformare ogni aggiornamento in un progetto di diversi mesi. Consolidarle in un insieme ridotto e motivato che copra le stesse funzioni di business è spesso il modo più rapido per rendere di nuovo gli aggiornamenti un’attività ordinaria: stessi risultati, una frazione della manutenzione.

I casi peggiori: modificare le definizioni di base del type system, sovrascrivere i controller standard e sostituire funzioni standard con implementazioni su misura che fanno quasi la stessa cosa con piccole differenze.

Come prevenirlo: prima di costruire qualsiasi extension personalizzata, chiedetevi se basta la configurazione standard. Se no, usate i punti di estensione della piattaforma e, lato storefront, i meccanismi di personalizzazione di SAP Composable Storefront invece di modificare il codice di base. Fissate un limite alle extension personalizzate (10-15 è un obiettivo ragionevole per un progetto di media complessità) e documentate la motivazione di business di ciascuna.

Per vedere come manteniamo snelle le personalizzazioni sfruttando al massimo la piattaforma, visitate la nostra pagina della soluzione SAP Commerce Cloud.

Errore 4: requisiti di business vaghi o irrealistici

Secondo un sondaggio Gartner, solo il 48% delle iniziative digitali raggiunge o supera i propri obiettivi di business (Gartner, 2024). I requisiti poco chiari vi contribuiscono spesso.

“Vogliamo una piattaforma di e-commerce come Amazon” non è un requisito. “Ci serve uno storefront B2B con prezzi specifici per cliente, quantità minime d’ordine, workflow di approvazione e un collegamento al nostro SAP ERP per la disponibilità in tempo reale” lo è.

Quando i requisiti di business sono vaghi, il team di implementazione colma le lacune con ipotesi, e quelle ipotesi sono spesso sbagliate. Qualche mese dopo la lacuna diventa visibile, e costosa: rilavorazioni, perimetro che si allarga e un sistema che non corrisponde a ciò di cui gli utenti hanno bisogno.

Come prevenirlo: definite i requisiti a livello di processo, non di funzionalità. Usate esempi concreti: “Quando un buyer del cliente X accede, vede il suo listino prezzi negoziato e lo storico ordini degli ultimi 12 mesi.” Percorrete ogni customer journey: navigazione, ricerca, configurazione dei prodotti, checkout, tracciamento degli ordini e resi.

Errore 5: ignorare le prestazioni finché è troppo tardi

Uno shop lento costa vendite e, nel B2B, costa anche la fiducia dei buyer che lo usano ogni giorno.

Le prestazioni di Commerce Cloud dipendono da una corretta indicizzazione di ricerca, dalla configurazione del caching, dal setup della CDN e da codice personalizzato efficiente. Molti team si concentrano solo sulle funzionalità durante lo sviluppo e scoprono i problemi di prestazioni solo nei test di carico, o dopo il go-live.

I killer più comuni delle prestazioni: query di prodotto non ottimizzate, header di cache mancanti, troppe chiamate API per pagina, cataloghi di grandi dimensioni senza indicizzazione adeguata e codice personalizzato che aggira il caching integrato della piattaforma.

Come prevenirlo: fissate budget di prestazioni dal primo giorno, per esempio un caricamento sotto i 2 secondi per le pagine di elenco prodotti e sotto 1,5 secondi per le pagine di dettaglio. Eseguite test di carico dopo ogni sprint, non solo prima del go-live, e monitorate costantemente i tempi delle query di ricerca, il tasso di successo della cache e i tempi di risposta delle API.

Errore 6: pianificare male la migrazione dei dati

La migrazione dei dati per Commerce Cloud riguarda prodotti, categorie, prezzi, clienti, ordini storici e contenuti (pagine CMS, media). Ogni tipo di dato ha il proprio formato ImpEx, le proprie regole di validazione e le proprie dipendenze. I prodotti dipendono dalle categorie, i prezzi dai prodotti, gli ordini da clienti e prodotti. La catena di dipendenze è reale.

I team che trattano la migrazione come uno script una tantum scoprono durante il collaudo che alcuni prodotti hanno immagini non funzionanti, che gli account clienti sono duplicati e che gli ordini storici non vengono visualizzati correttamente. A quel punto la data di go-live è in pericolo. Approfondiamo le insidie specifiche della migrazione nei cinque errori più comuni nella migrazione SAP Commerce.

Come prevenirlo: pianificate la migrazione come un filone di lavoro separato con la propria tempistica, non come un’attività. Eseguite almeno tre cicli di migrazione completi prima del go-live: uno per validare la struttura, uno per verificare la qualità dei dati e uno come prova generale. Validate i file ImpEx prima dell’importazione e controllate in modo automatizzato immagini, assegnazioni alle categorie e associazioni dei prezzi.

Errore 7: test insufficienti

I test insufficienti sono la strada attraverso cui si materializzano molti sforamenti, perché i difetti trovati tardi costano molto più di quelli individuati presto.

I progetti Commerce Cloud richiedono diversi tipi di test: test unitari per il codice personalizzato, test di integrazione per le connessioni API, test di prestazioni sotto carico e collaudi utente con scenari di business reali. Tralasciarne anche uno solo crea rischio.

La lacuna più pericolosa è il test di integrazione con l’ERP. Commerce Cloud invia gli ordini all’ERP e riceve disponibilità, prezzi e aggiornamenti di spedizione. Se questa integrazione non viene testata in condizioni realistiche (utenti simultanei, picchi di volume, scenari di errore), i problemi emergono il giorno del lancio. Per le aziende su SAP S/4HANA, la nostra guida a SAP Commerce Cloud con S/4HANA Public Cloud nel B2B spiega dove si trova questo punto di contatto.

Come prevenirlo: prevedete per i test una quota sostanziale dello sforzo complessivo del progetto. Iniziate i test di integrazione a metà progetto, non nell’ultima settimana. Usate suite automatizzate per i test di regressione a ogni deployment e fate eseguire i collaudi a utenti di business reali con scenari reali, non al team di implementazione che percorre solo i casi ideali.

Domande frequenti

Qual è l’errore di Commerce Cloud più costoso da correggere?

L’eccesso di personalizzazione. Rimuovere o riscrivere extension personalizzate profondamente radicate può costare più dell’implementazione originale, e ogni extension aggiunge lavoro a ogni aggiornamento. Ogni extension personalizzata dovrebbe avere una motivazione di business documentata e una valutazione del suo impatto sul percorso di aggiornamento.

Quanto dovrebbe durare un’implementazione SAP Commerce Cloud?

I tempi tipici sono da 4 a 9 mesi per uno storefront B2B o B2C standard e da 8 a 14 mesi per implementazioni complesse multi-paese e multilingua. I fattori principali sono il numero di integrazioni, l’entità delle personalizzazioni e lo stato dei dati da migrare.

Conviene migrare da SAP Hybris on-premise a Commerce Cloud?

Nella maggior parte dei casi sì. La mainstream maintenance di SAP Commerce on-premise è terminata il 31 luglio 2026; la release 2205 riceve ormai solo manutenzione specifica per cliente, senza nuovi support package, adeguamenti normativi né aggiornamenti delle librerie. La domanda è come e con quale velocità, e se sia più adatta Commerce Cloud, la ERP Edition o un replatforming.

Quante extension personalizzate sono troppe?

Non esiste un numero assoluto, ma 10-15 sono gestibili per la maggior parte dei progetti. Oltre 30 lo sforzo di aggiornamento cresce in modo più che proporzionale. Oltre 50 ogni aggiornamento tende a diventare un progetto di diversi mesi. Contate regolarmente le vostre extension e consolidate dove possibile.

Posso usare Commerce Cloud per B2B e B2C sulla stessa piattaforma?

Sì. Commerce Cloud supporta più storefront (siti) su una sola istanza, ognuno con catalogo, prezzi, modello clienti e checkout propri. B2B e B2C possono convivere, ma la complessità dell’implementazione aumenta: pianificate perimetro e budget di conseguenza.