Tempi della migrazione a S/4HANA e piano di progetto per percorso

Nella mia esperienza, i tempi di una migrazione a S/4HANA da SAP ECC vanno da 12 a 18 mesi per una conversione brownfield e da 18 a 24 mesi per un'implementazione greenfield. Una selective data transition richiede da 12 a 18 mesi. Il piano di progetto segue le sei fasi di SAP Activate, e la fase che sfora più spesso è il codice custom.

Risposta breve: apra il piano con il SAP Readiness Check e dia ai dati dal 30 al 40 percento dell'effort. In un brownfield, pianifichi tre mock conversion e metta in conto un fermo per il cutover che va da un weekend a una settimana.

Questo articolo è il dettaglio su tempi e pianificazione che sta dietro la mia guida alla migrazione da ECC a S/4HANA, che tratta i percorsi e le scadenze di ECC. Se sta implementando SAP da zero invece di lasciare ECC, la mia guida ai tempi di implementazione SAP copre quel caso, con la durata delle fasi.

È il percorso a fissare la durata. La mia regola: greenfield quando arriva da altri sistemi o vanno definiti processi nuovi. Brownfield quando i processi sono definiti e funzionano, e selettiva quando i processi di alcune aree vanno ridefiniti.

Ecco quanto dura ciascun percorso nei programmi che ho visto, e cosa di solito lo allunga:

Percorso	Tempi tipici	Attorno a cosa è costruito il piano	Cosa di solito lo allunga
Brownfield (conversione del sistema)	Da 12 a 18 mesi	Conversione del sistema ECC esistente con il Software Update Manager, poi conversioni di test ripetute	Adattamento del codice custom e conversione ai business partner
Greenfield (nuova implementazione)	Da 18 a 24 mesi	Progettazione fit-to-standard, realizzazione e cicli ripetuti di caricamento dei dati	Workshop di Explore che diventano lunghe liste di requisiti, e pulizia dei dati
Selective data transition	Da 12 a 18 mesi	Accordo su quali società, unità e quanto storico trasferire, poi strumenti specialistici	Perimetro dei dati e dipendenza da partner specialistici

Il calendario conta quanto il percorso. Per ECC sugli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027 (SAP News). Un brownfield avviato questo mese va in go-live tra ottobre 2027 e aprile 2028, e un greenfield avviato adesso arriva nel 2028.

La maggior parte dei piani scritti oggi deve quindi mettere a budget un po' di manutenzione estesa. La inserisca all'inizio, non come sorpresa al secondo anno.

RISE with SAP è un pacchetto commerciale, non un percorso. Un brownfield o una migrazione selettiva sotto RISE arriva su SAP Cloud ERP Private, il nome attuale usato da SAP per quello che molti cercano ancora come S/4HANA Cloud Private Edition. I tempi che indico, da 6 a 9 mesi per GROW with SAP e da 9 a 18 mesi per RISE, valgono per nuove implementazioni, non per migrazioni da ECC.

SAP Activate è il metodo di delivery di SAP per S/4HANA. Ha sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run (SAP Activate).

Una migrazione usa le stesse fasi. Quello che cambia è il lavoro dentro ciascuna.

Il piano di progetto della migrazione

1. 01

   Discover

   Readiness Check, scelta del percorso e business case.

2. 02

   Prepare

   Piano, governance, team e primo sandbox.

3. 03

   Explore

   Fit-to-standard o progettazione delta, lista WRICEF concordata.

4. 04

   Realize

   Realizzazione, codice custom, caricamenti dati, conversioni di test.

5. 05

   Deploy

   Prova generale, cutover e go-live.

6. 06

   Run

   Hypercare, stabilizzazione e dismissione di ECC.

Ecco cosa contiene ciascuna fase in una migrazione, e dove i percorsi si differenziano:

Fase	Cosa succede in una migrazione	Come si differenziano i percorsi
Discover	SAP Readiness Check, scelta del percorso, business case, prima vista su codice custom e dati	La selettiva richiede qui un primo perimetro dei dati
Prepare	Piano, governance, team, responsabilità dei dati, sandbox	Il brownfield esegue una prima conversione in sandbox; il greenfield prepara il sistema e il calendario dei workshop
Explore	Workshop fit-to-standard o progettazione delta, lista WRICEF concordata, mappatura dei dati	Il greenfield passa qui più tempo; il brownfield lavora sui simplification item applicabili
Realize	Realizzazione, adattamento del codice custom, cicli di caricamento dati, cicli di test	Il brownfield esegue le mock conversion; il greenfield esegue i cicli di caricamento, di solito con il Migration Cockpit
Deploy	Prova generale, cutover, go-live	La finestra di fermo dipende da percorso, volume dei dati e approccio
Run	Hypercare, stabilizzazione	Dismissione di ECC e archiviazione di ciò che si è tenuto

WRICEF sta per workflow, report, interfacce, conversioni, enhancement e form. È la lista di tutto ciò che si realizza oltre lo standard SAP, ed è il numero da tenere d'occhio.

Nei 21 programmi SAP che ho guidato o salvato, l'errore più grande è non pianificare bene all'inizio dell'implementazione. In Prepare, concordi chi è responsabile della pulizia dei dati, quale codice custom viene dismesso e quando si svolgono ogni conversione di test e ogni prova generale. Quelle date diventano la spina dorsale del piano.

Brownfield: pianificare attorno alle conversioni di test

Un piano brownfield è costruito attorno al ciclo di conversione. Il Software Update Manager converte il sistema, e ogni esecuzione di test Le dice quanto durerà quella vera e cosa si rompe.

In un brownfield pianifico tre mock conversion prima del cutover. Ognuna dovrebbe girare su una copia recente della produzione, così i tempi misurati hanno un senso. L'ultima dovrebbe comportarsi come il go-live: stessa sequenza, stesse persone, stessi controlli.

Il piano di SAP per il suo approccio downtime-optimized è simile. Prevede un'esecuzione in sandbox, un'esecuzione in quality assurance, una verifica del caricamento su un clone e una prova generale (SAP Learning). SAP precisa che tecnicamente si possono fare meno esecuzioni, ma il rischio aumenta.

Greenfield: pianificare attorno alla progettazione e ai caricamenti dei dati

Nel greenfield il tempo va in Explore. I workshop fit-to-standard decidono quanta parte dello standard SAP adotta, e ogni gap diventa un oggetto WRICEF da realizzare, testare e mantenere.

I dati si spostano a cicli di caricamento, di solito con il SAP S/4HANA Migration Cockpit. Pianifichi diversi cicli di caricamento completi, ciascuno seguito da una riconciliazione firmata dal business. La mia guida passo per passo al Migration Cockpit tratta staging table, oggetti di migrazione e processo di caricamento.

Selettiva: pianificare attorno al perimetro dei dati

Un piano selettivo parte dal perimetro dei dati. Quali società, business unit e anni di storico vengono trasferiti, e quali processi vengono riprogettati.

Quel perimetro determina gli strumenti, il partner specialistico e i cicli di test. Se lo cambia tardi, i tempi si spostano con lui.

Nella mia esperienza il codice custom è la fase che sfora più spesso. È anche il costo nascosto più dimenticato in una migrazione, tema trattato nella mia guida ai costi della migrazione a S/4HANA.

Questi sono i punti che terrei d'occhio, in ordine:

1. Codice custom. I team lo stimano da un report, poi scoprono la dimensione reale quando parte la correzione. In un programma, l'analisi con smartShift ha ridotto gli oggetti custom da 18.000 a 3.200. Prima si dismette, poi si adatta.
2. Oggetti custom sfuggiti all'assessment. Nella mia esperienza gli oggetti custom che il SAP Readiness Check non rileva sono quelli che fanno male dopo. Legga la mia guida al SAP Readiness Check prima di trattarne l'output come il Suo perimetro.
3. Dati. La migrazione dei dati assorbe dal 30 al 40 percento dell'effort. Quando la pulizia non ha un responsabile parte tardi, poi comprime i cicli di test. Il mio articolo sul perché la migrazione dei dati SAP fallisce approfondisce il tema.
4. Explore. I budget vengono colpiti in Explore, man mano che la lista WRICEF cresce. Quando è il vendor a controllare il perimetro, nessuno dalla parte del vendor ha motivo di fermarne la crescita.
5. Prove tagliate per guadagnare tempo. Una prova eliminata per difendere la data tende a costare nel weekend del go-live più tempo di quanto ne abbia fatto risparmiare.

La mia opinione: blocchi la data di go-live alla fine di Explore, quando la lista WRICEF e il perimetro del codice custom sono noti. Una data fissata al kickoff è un'ipotesi con allegata una presentazione al consiglio di amministrazione.

Il fermo del cutover che ho visto va da un weekend a una settimana. Lo fanno variare il volume dei dati, l'approccio di conversione, il numero di società e interfacce che vanno in go-live insieme e la rapidità con cui il business riesce a validare.

Per un brownfield, SAP offre un approccio di conversione downtime-optimized nel Software Update Manager. Sposta una parte della conversione e della migrazione dei dati nel periodo di uptime, mentre la produzione continua a girare.

Non è tempo gratuito. SAP elenca esecuzioni di test aggiuntive, una pianificazione più complessa, congelamenti di customizing e sviluppo prima del fermo e un esperto formato sull'approccio.

Concordi quindi il fermo che il business può accettare prima di scegliere l'approccio tecnico. Poi lo dimostri nelle mock conversion, non nel weekend del go-live. Tenga il cutover lontano dalla chiusura mensile e dall'alta stagione.

Un piano vale quanto le ipotesi su cui si regge. Queste sono le domande che farei prima che qualcuno firmi:

1. Quale percorso presuppone il piano, e cosa nei risultati del nostro Readiness Check lo sostiene?
2. Quanti oggetti custom restano nel perimetro dopo l'analisi d'uso, e quanti verranno dismessi?
3. Chi è responsabile della pulizia dei dati, e in quale fase inizia?
4. Quante mock conversion o quanti cicli di caricamento sono previsti, e su quali dati?
5. Quale fermo presuppone il piano, e quale esecuzione di test lo dimostra?
6. Quando viene bloccata la data, e cosa le succede se la lista WRICEF cresce in Explore?

Chieda al partner referenze di programmi simili al Suo e la sua progettazione di alto livello. Se le risposte sono generiche e non specifiche per la Sua azienda, lo consideri un campanello d'allarme.

Esegua il SAP Readiness Check in questo trimestre. Porti i risultati su codice custom e dati davanti al CFO e al programme director prima che qualcuno si impegni su una data di go-live.

Poi costruisca il piano a ritroso dalla finestra di cutover che può accettare, con tre mock conversion in un brownfield o con i cicli di caricamento che il Suo percorso richiede. Per mettere prima alla prova il percorso stesso, provi la mia valutazione della migrazione greenfield o brownfield.

Aiuto le organizzazioni a costruire e a mettere sotto stress piani di migrazione come questo. Se desidera un parere indipendente, mi contatti.

Quanto dura una migrazione a S/4HANA?

Nella mia esperienza una conversione brownfield da ECC richiede da 12 a 18 mesi, un'implementazione greenfield da 18 a 24 mesi e una selective data transition da 12 a 18 mesi. Il codice custom è la fase che sfora più spesso, e la migrazione dei dati assorbe dal 30 al 40 percento dell'effort.

Quali sono le fasi di un piano di progetto di migrazione a S/4HANA?

Il piano segue SAP Activate: Discover, Prepare, Explore, Realize, Deploy e Run. In una migrazione, Discover contiene il Readiness Check e la scelta del percorso, Realize contiene codice custom, caricamenti dei dati e conversioni di test, e Deploy contiene la prova generale e il cutover.

Quante mock conversion servono per una migrazione brownfield a S/4HANA?

In un brownfield pianifico tre mock conversion prima del cutover. Per il suo approccio downtime-optimized, SAP prevede un'esecuzione in sandbox, un'esecuzione in quality assurance, una verifica del caricamento e una prova generale, e afferma che meno esecuzioni aumentano il rischio.

Quanto dura il fermo per il cutover di S/4HANA?

Il fermo del cutover che ho visto va da un weekend a una settimana. Dipende dal volume dei dati, dall'approccio di conversione e da quante società e interfacce vanno in go-live insieme. La conversione downtime-optimized di SAP sposta una parte del lavoro nel periodo di uptime, ma richiede più esecuzioni di test e più pianificazione.

Possiamo completare una migrazione a S/4HANA prima che finisca il supporto di ECC nel 2027?

La manutenzione standard di ECC sugli enhancement package da 6 a 8 termina il 31 dicembre 2027. Un brownfield avviato a ottobre 2026 va in go-live tra ottobre 2027 e aprile 2028, e un greenfield nel 2028. La maggior parte dei programmi che partono adesso dovrebbe mettere a budget un po' di manutenzione estesa.

Cosa ritarda di più i progetti di migrazione a S/4HANA?

Nella mia esperienza è il codice custom a sforare più spesso, seguito dalla pulizia dei dati che parte tardi e da una lista WRICEF che continua a crescere in Explore. La radice della maggior parte di questi problemi è non pianificare bene all'inizio del programma.