Migrazione da SAP ECC a S/4HANA: case study di un retailer in Medio Oriente

Questo è il mio case study preferito. Un noto retailer mediorientale di moda e beni di consumo è passato da SAP ECC 6.0 a S/4HANA. Aveva circa 18.000 dipendenti, più di 1.200 punti vendita in sette paesi e un canale e-commerce in crescita. Usava ECC da anni e il 44% degli oggetti di sistema era personalizzato. Abbiamo scelto una conversione brownfield con riprogettazione selettiva. La chiusura mensile è passata dai fine settimana a prima di pranzo e il codice custom è calato di quasi la metà.

Se gestisce un sistema ECC molto personalizzato e si chiede quanto riportarne con sé, ecco come un programma ha risposto a questa domanda.

La personalizzazione si era accumulata lentamente, una correzione urgente alla volta. Quando abbiamo iniziato, anche i piccoli aggiornamenti comportavano rischi. Le integrazioni erano fragili: una piccola modifica in finanza poteva rompere qualcosa nelle operazioni retail. Il business voleva flessibilità e velocità. L'IT era assorbita dall'emergenza continua. Entrambe le parti ammettevano di lavorare con obiettivi contrapposti.

Ricordo una sessione in cui il team della supply chain ha riso un po' ammettendo che decine dei loro report «critici» ormai venivano toccati a malapena. Eliminarli è stato sia pratico sia stranamente liberatorio.

Il fattore scatenante è stato la fine della manutenzione standard di ECC. SAP ERP 6.0 con gli enhancement package da 6 a 8 esce dalla manutenzione standard alla fine del 2027 (SAP News). Le ragioni vere erano più profonde. La finanza eseguiva estrazioni manuali a ogni chiusura mensile. I negozi avevano bisogno di una visibilità sulle scorte che i job batch notturni non potevano dare. La maggior parte dello sforzo dell'IT andava nel tenere in vita il codice custom.

Lo SAP Readiness Check ha confermato ciò che sospettavamo: un sistema molto personalizzato, con un lavoro di bonifica importante davanti. La Simplification Item List ha mostrato dove S/4HANA standard faceva già ciò che il codice custom di ECC faceva da tempo. La finanza ha scoperto che alcuni report custom mantenuti da anni ora erano ridondanti. Il sollievo in quella riunione era evidente.

Una semplice conversione tecnica avrebbe solo spostato in avanti i problemi. Una ricostruzione greenfield completa avrebbe buttato via dieci anni di configurazione funzionante. Il brownfield con riprogettazione selettiva era il giusto equilibrio: tenere ciò che era solido, ripulire ciò che andava ripulito, ricostruire solo ciò che era rotto. La mia guida alla migrazione da ECC a S/4HANA spiega come soppesare questi percorsi.

Conversione sempliceBrownfield con riprogettazione selettivaRicostruzione greenfield completa

Configurazione mantenutaConversione sempliceTutta, problemi compresiBrownfield con riprogettazione selettivaCiò che era solidoRicostruzione greenfield completaNessuna, dieci anni di lavoro scartati

44% di oggetti customConversione sempliceRiportati così come sonoBrownfield con riprogettazione selettivaCiascuno marcato per eliminazione, sostituzione o adeguamentoRicostruzione greenfield completaNon riportati

Che cosa comportaConversione sempliceI problemi passano a S/4HANABrownfield con riprogettazione selettivaSi ripulisce ciò che va ripulito, si ricostruisce solo ciò che è rottoRicostruzione greenfield completaOgni processo funzionante ricostruito da zero

Sfida	Che cosa abbiamo fatto
44% di oggetti personalizzati	Business e IT hanno classificato insieme ogni oggetto: eliminare, sostituire o adeguare; quality gate per ogni fase
Integrazioni fragili	Piano di regressione che copre POS, WMS, finanza, HR e portali fornitori; collegamenti punto a punto spostati su pattern di SAP Integration Suite
Qualità dei dati	Data steward per funzione con SLA; tracciamento quotidiano dei difetti; pulizia conclusa prima del QA
Adozione nei vari paesi	Guide operative per ruolo, affiancamento sul campo vicino al go-live, formazione legata alle attività reali

Codice custom su larga scala

I risultati del readiness hanno funzionato da filtro. Business e IT si sono seduti insieme per classificare ogni oggetto. Alcuni erano chiaramente ridondanti, come i report che nessuno ricordava di aver mai lanciato. Altri supportavano processi retail davvero unici e richiedevano una riprogettazione accurata. Ha costretto i team a decidere invece di rimandare. SAP Signavio ha aiutato a definire i nuovi processi rispetto alle best practice, e smartShift si è occupato delle scansioni automatiche del codice e delle correzioni di poco valore, lasciando il tempo dei profili senior alla riprogettazione. La mia guida al clean core spiega come classifico oggi il codice custom.

Integrazioni

ECC era collegato ai sistemi di punto vendita (POS), al sistema di gestione del magazzino (WMS), alla finanza, alle risorse umane e a diversi portali fornitori. Abbiamo costruito un piano di regressione che copriva tutti questi collegamenti e abbiamo testato dopo ogni modifica significativa della configurazione, non solo alla fine. I job batch notturni dovevano finire più in fretta in S/4HANA, altrimenti i report mattutini del magazzino non sarebbero stati pronti.

Qualità dei dati

I record fornitore duplicati e i dati anagrafici obsoleti hanno allungato i test. La soluzione è stata strutturale: un data steward in ogni funzione, con SLA per la risoluzione. Se i dati non erano puliti all'inizio del QA, tornavano al data steward. Man mano che il cutover si avvicinava, abbiamo provato i caricamenti da cima a fondo e tracciato i difetti ogni giorno. Quella semplice routine ha funzionato meglio di qualsiasi dashboard sofisticata, e la cosa ancora mi sorprende. Il mio articolo su perché la migrazione dei dati SAP fallisce tratta questo schema.

Adozione

La formazione ha raggiunto 26.000 dipendenti. Finanza e operazioni retail avevano priorità diverse, cosa emersa in un workshop iniziale che ha cambiato l'impostazione della formazione. Quando la pressione è salita vicino al go-live, abbiamo usato guide operative per ruolo e affiancamento sul campo. Una responsabile di negozio ha detto poi che la guida di due pagine era servita più di qualsiasi town hall. Le ho creduto.

Delivery a fasi su SAP Activate. Prima sono passati la finanza di base e la supply chain, poi le risorse umane e i portali fornitori, così i team di supporto non sono mai stati sovraccarichi. Ogni ambiente aveva un solo compito. Il sandbox ha convalidato il percorso e bloccato il perimetro. Lo sviluppo ha consolidato i trasporti. Il QA ha eseguito volumi di business reali e ottimizzato i job. La pre-produzione è stata una vera prova generale. Le date di rilascio sono state allineate ai picchi e ai periodi di bassa stagione del retail.

Test con il business. I responsabili di finanza e supply chain hanno testato sui cicli reali di chiusura di periodo e di promozione, con script scritti attorno alla realtà del business e non alla logica del sistema. Le esecuzioni notturne hanno fatto emergere problemi di tempistica. Ricordo il sorriso del responsabile di magazzino quando la seconda esecuzione è andata liscia dopo settimane di frustrazione.

Prove di cutover. Ogni attività è stata cronometrata, sfoltita o accorpata. Il solo dry run ha fatto risparmiare ore che un foglio di calcolo non avrebbe mai rivelato. I piani di ripristino stavano su fogli di una pagina, e le persone dicevano che quel semplice elenco riduceva lo stress più di qualsiasi dashboard. Un negozio pilota ha dimostrato la stabilità di POS e WMS prima del rollout più ampio.

Hypercare. Una war room condivisa tra IT e business, SLA chiari e registri quotidiani delle azioni. I turni nel fine settimana venivano ruotati e i passaggi di consegne del supporto erano scritti al minuto. Di solito la gente ricorda i numeri. Io ricordo soprattutto la prima notte tranquilla.

Chiusura finanziaria. I team hanno detto che la chiusura mensile ora finiva prima di pranzo, mentre prima si trascinava nei fine settimana. Il CFO era soddisfatto soprattutto di avere i report molto più in fretta. Qualcuno della finanza ha scherzato dicendo che il sistema finalmente funzionava «più in fretta della macchinetta del caffè». Momenti così danno più fiducia di qualsiasi presentazione.

Codice custom. Calato di quasi la metà, il che ha ridotto l'onere di supporto a lungo termine e il rischio di regressione a ogni futuro aggiornamento.

Reporting ed esperienza utente. I responsabili dei negozi sono passati dalle vecchie schermate transazionali alle app SAP Fiori. I tempi di formazione si sono ridotti perché le app funzionavano come le persone si aspettavano. Un responsabile l'ha definita «rinfrescante».

Integrazioni. I collegamenti tra POS, WMS e finanza sono diventati più stabili e i job notturni finivano prima.

Non tutto è andato allo stesso modo. Alcuni team si sono tenuti i vecchi report anche quando ne esistevano di migliori. Alcuni hanno trovato i workshop troppo lunghi e le prove ripetitive. A posteriori, quei passaggi sono stati la rete di sicurezza.

Lezione	Che cosa è successo	Che cosa farei la prossima volta
Allinearsi presto	In un workshop, i responsabili dei negozi hanno detto che le loro esigenze di reporting erano molto diverse da quelle della finanza. È emerso subito e ci siamo adeguati; più tardi sarebbe esploso al cutover	Programmare sessioni di allineamento strutturate prima dell'inizio della progettazione
Iniziare la revisione del codice dal primo giorno	Diversi oggetti sono stati rielaborati sotto pressione vicino al go-live	Prendere le decisioni di eliminazione, sostituzione o adeguamento fin dal kickoff
Fare dei dati un compito del business	I record fornitore duplicati hanno rallentato i test	Nominare data steward di funzione con SLA già nella prima settimana
Provare più di quanto sembri necessario	Un dry run ha rivelato conflitti di sequenza tra POS e WMS che nessuno aveva previsto	Pianificare prove aggiuntive; l'ultima prima del go-live dovrebbe essere noiosa

Se lo stesso programma partisse oggi, cambierebbero tre cose. La maggior parte delle aziende in questa posizione guarderebbe oggi a S/4HANA Cloud Private Edition con RISE with SAP invece di restare on-premise. Le decisioni di eliminazione, sostituzione o adeguamento verrebbero inquadrate rispetto ai livelli da A a D del clean core di SAP. Il monitoraggio di modifiche e rilasci passerebbe su SAP Cloud ALM, perché Solution Manager 7.2 esce dalla manutenzione standard alla fine del 2027. I data steward, le prove, la war room congiunta e le guide di due pagine resterebbero esattamente com'erano. Per il lato delle persone, veda la mia guida alle strategie di formazione SAP.

Perché le aziende passano da SAP ECC a S/4HANA?

Il fattore scatenante è la fine della manutenzione standard di ECC nel 2027. Le ragioni più solide sono operative: reporting in tempo reale, una chiusura più rapida e meno sforzo speso per tenere in vita codice custom e integrazioni fragili. In questo caso il business voleva analisi retail in tempo reale e una chiusura mensile più breve.

Che cosa ha mostrato lo SAP Readiness Check in questo caso?

Ha confermato che il 44% degli oggetti era personalizzato e che molti non venivano usati da anni. Questo ha cambiato la struttura del lavoro sul codice custom: prima eliminare, poi sostituire con lo standard dove possibile e adeguare solo ciò che aveva un reale valore di business. La Simplification Item List ha anche mostrato report resi ridondanti da S/4HANA standard.

Perché scegliere il brownfield con riprogettazione selettiva?

Una semplice conversione tecnica avrebbe portato avanti ogni problema, e una ricostruzione greenfield completa avrebbe scartato dieci anni di configurazione funzionante. La riprogettazione selettiva ha mantenuto ciò che era solido, ha usato SAP Signavio per definire i nuovi processi dove lo standard poteva sostituire la logica custom e ha ricostruito solo ciò che era rotto.

Che cosa succede se si lascia la pulizia dei dati troppo tardi?

I test si trascinano, le prove falliscono e il go-live slitta. Qui i record fornitore duplicati e i dati anagrafici obsoleti hanno causato settimane di attrito nei test. La soluzione sono stati data steward in ogni funzione con SLA, e la pulizia monitorata come indicatore di salute del programma.

Come sono state gestite le integrazioni durante la migrazione?

Mappando prima ogni collegamento: POS, WMS, finanza, HR e portali fornitori. Un piano di regressione li copriva tutti, i test sono stati eseguiti dopo ogni modifica significativa della configurazione e un negozio pilota ha dimostrato la stabilità di POS e WMS prima del rollout più ampio. Un dry run ha comunque rivelato un conflitto di sequenza tra POS e WMS che nessuno aveva previsto.

Come si presenta un buon hypercare dopo un go-live di S/4HANA?

Una war room condivisa tra IT e business con SLA chiari, registri quotidiani delle azioni e problemi chiusi rapidamente invece di essere parcheggiati in un backlog. Le guide per ruolo e l'affiancamento sul campo riducono le chiamate al supporto più in fretta della formazione formale. Si ruotino i turni nel fine settimana e si scrivano i passaggi di consegne, così il team non si logora.