Perché la migrazione dei dati SAP fallisce e come rimediare

La migrazione dei dati SAP fallisce soprattutto per un motivo: il piano è costruito su ciò che il business pensa che siano i propri dati, non su ciò che mostra un'estrazione. Questa guida è per i direttori di programma, i responsabili dei dati e i leader della finanza in un programma S/4HANA. Spiega perché le migrazioni si rompono, i cinque errori dietro la maggior parte dei cutover falliti, un piano di mock load da copiare e quali strumenti SAP si adattano a quale compito nel 2026. Se questa settimana fa una cosa sola, prenda un'estrazione completa delle anagrafiche di clienti, fornitori e materiali e conti i record da sé.

Un'azienda manifatturiera ha speso 18 mesi e 4,5 milioni di dollari per la sua implementazione SAP. È arrivato il giorno del lancio. Tutti erano nervosi ma entusiasti. Poi la migrazione dei dati è fallita.

Niente funzionava come doveva. Mancavano i dati dei clienti. I numeri di magazzino erano sbagliati. La contabilità non riusciva a chiudere i conti. Il CEO era furioso.

Non era colpa del software e non era colpa del team di implementazione. Il fallimento stava nello scarto tra ciò che il business pensava che fossero i propri dati e ciò che erano davvero.

Il modello dati di SAP non è un'importazione piatta. I record dipendono l'uno dall'altro. Un'anagrafica materiale ha un record generale (MARA), dati di stabilimento (MARC), dati di valorizzazione (MBEW) e, dove si usano le aree MRP, dati dell'area MRP (MDMA). Se carica la testata senza le viste dipendenti, il materiale esiste ma non può essere usato in una transazione.

S/4HANA aggiunge una regola propria. Clienti e fornitori sono business partner. Un cliente legacy diventa un business partner con ruolo cliente, e un fornitore diventa un business partner con ruolo fornitore. Limiti di credito, coordinate bancarie e identificativi fiscali dipendono da quel business partner. Un record che un sistema legacy tollerava con delle lacune qui non supererà la validazione.

Poi c'è il volume. La maggior parte delle aziende resta sconvolta da quanti dati abbia davvero. Un cliente pensava di avere circa 50.000 record di materiali. Contando tutte le varianti e i record specifici di stabilimento, il numero era vicino a 500.000. Un piano dimensionato sul primo numero non sopravvive al secondo.

Stima del businessEstrazione completa

Record di materiali nel perimetro500,000+450,000 · +900%

Stima del business50,000

Estrazione completa500,000

• Ogni variante e ogni record specifico di stabilimento contato
• Un piano dimensionato sulla stima non sopravvive a questo dato

Non era un problema di migrazione dei dati. Era un problema di perimetro che lo è diventato.

La valutazione della qualità dei dati all'inizio di un progetto è di solito una descrizione dei dati, non un loro esame. Il direttore finanziario dice che l'anagrafica fornitori è ben tenuta. Il responsabile di magazzino dice che i materiali sono per lo più puliti. Sono impressioni.

La prima estrazione dice la verità. Fornitori che avrebbero dovuto essere ripuliti anni fa e non lo sono stati. Materiali dismessi da tempo e mai disattivati. Indirizzi dei clienti con codici paese incoerenti. Coordinate bancarie mancanti su fornitori pagati con bonifico.

Ciascuno di questi casi richiede una decisione di business, non una correzione tecnica. Solo la contabilità fornitori può dire quale di due fornitori duplicati sia quello corretto. Solo gli acquisti possono dire quali materiali obsoleti bloccare e quali lasciare indietro. Queste decisioni richiedono tempo e le persone che conoscono i dati. Se la valutazione non si basa su un'estrazione reale, il piano poggia su ipotesi che non sopravvivranno al contatto con i dati. Il mio stimatore gratuito per la migrazione dei dati aiuta a dimensionare l'impegno quando si hanno i conteggi reali.

1. Trattare la migrazione come un'attività tecnica tardiva

La migrazione appartiene a ogni fase di SAP Activate. Explore definisce il perimetro: oggetti, sistemi di origine, volumi e qualità. Realize costruisce i template ed esegue i mock load. Deploy esegue la prova generale finale e il caricamento di cutover. Run riconcilia la prima chiusura di periodo sui dati live.

I progetti che iniziano il lavoro di migrazione in Deploy lo iniziano con mesi di ritardo. I problemi di qualità che avrebbero dovuto essere risolti in Realize emergono nel primo mock, settimane prima del cutover. La mia guida alla pianificazione della timeline SAP mostra dove si colloca la migrazione nel piano complessivo.

2. Poco coinvolgimento del business

La migrazione è tecnica nell'esecuzione e un'attività di business nelle decisioni. L'IT non può produrre l'elenco dei fornitori duplicati. Quali conti cliente migrano come attivi e quali restano come storico è una decisione della finanza. La bonifica dei materiali obsoleti richiede acquisti, magazzino e product management.

I programmi che affidano la migrazione solo a persone tecniche, e trattano il business come una firma di approvazione alla fine, producono dati che si caricano. Dal punto di vista commerciale, sono sbagliati.

3. Pianificare troppo pochi mock load

Una migrazione dei dati SAP ben gestita richiede almeno tre mock load prima del cutover, e i programmi complessi ne richiedono di più. I progetti che ne pianificano uno o due stanno pianificando per dati puliti e una mappatura pulita. È uno scenario raro. Più cicli non sono il segno di una migrazione in difficoltà. Sono il segno di una migrazione pianificata bene.

4. Non riconciliare i caricamenti di prova

Un job di caricamento che termina senza errori non è validazione. La validazione confronta ciò che è stato caricato con ciò che ci si aspettava: numero di record, totali finanziari, saldi delle partite aperte. Poi uno smoke test di processo conferma che i dati funzionano nelle transazioni.

Un caricamento di prova non riconciliato costa comunque tempo. Lo scarto che ha prodotto è ancora lì al mock successivo, solo che ora è più difficile risalire alla sua causa. Riconcili ogni caricamento prima di iniziare il successivo.

5. Un caricamento di cutover diverso dalle prove

La migrazione di cutover dovrebbe ripetere esattamente l'ultimo mock: stessi script di estrazione, stessa logica di trasformazione, stessa sequenza di caricamento, stessi controlli e stessi tempi. Qualsiasi cambiamento al cutover è un rischio non testato nel momento di massima pressione del programma.

La parte meno testata è di solito il delta. Tra l'ultimo mock e il cutover il business continua ad aggiungere fornitori, modificare ordini e spostare scorte. Definisca la data di congelamento dei dati e provi il caricamento del delta come parte del mock finale.

Usi questa struttura di cicli come punto di partenza. Ogni ciclo ha un obiettivo e un criterio di uscita, e non è completo finché la riconciliazione non è firmata.

Ciclo	Obiettivo	Criterio di uscita	Responsabile
Mock 1	Struttura: ogni oggetto si carica nell'ordine delle dipendenze	Lacune di mappatura ed errori di formato registrati per oggetto	Responsabile della migrazione dei dati
Mock 2	Qualità: testare le correzioni alla mappatura e far emergere i problemi di dati	Tasso di errore in calo per oggetto; decisioni di bonifica registrate	Data steward
Mock 3	Regole di business: eccezioni e casi limite	Gli steward accettano un campione riconciliato in ciascun dominio	Data steward
Mock 4	Volume e tempi alla dimensione piena di produzione	Il caricamento completo termina entro la finestra di cutover	Responsabile del cutover
Prova generale finale	Prova generale del cutover, compresi delta e congelamento	Conteggi e totali finanziari riconciliati e firmati	Financial controller e responsabile dei dati

Attorno a questo piano, cinque cose fanno la differenza:

1. Un'estrazione completa in Prepare. Tutta, non un campione. Profili completezza, accuratezza, coerenza e duplicati, poi dimensioni la bonifica e la timeline in base ai risultati.
2. Mappatura oggetto per oggetto. Per ogni oggetto (business partner, materiali, ordini di acquisto e di vendita aperti, partite aperte, scorte, cespiti), documenti i campi da origine a destinazione, le regole di trasformazione, i controlli di validazione e le regole per le eccezioni.
3. Data steward nominati. La finanza è responsabile dei dati finanziari di clienti e fornitori. Gli acquisti sono responsabili dell'anagrafica materiali. Il magazzino è responsabile delle scorte. Ogni steward firma il proprio dominio dopo ogni ciclo.
4. Riconciliazione definita in anticipo. Concordi quali conteggi e totali dimostrano che un caricamento è corretto prima del primo mock, così nessuno ne discute al cutover.
5. Una sequenza di cutover scritta. Congelamento, estrazione, trasformazione, caricamento, validazione, approvazione del business, go/no-go. La stessa sequenza della prova generale finale.

Per una nuova implementazione S/4HANA, lo SAP S/4HANA Migration Cockpit è lo strumento raccomandato da SAP per il caricamento iniziale. Da S/4HANA 2020 gira come app Fiori Migrate Your Data. La transazione LTMC è deprecata e i progetti LTMC esistenti possono solo essere visualizzati. L'app offre due approcci: migrare i dati usando tabelle di staging (popolate da file o con strumenti propri) e migrare i dati direttamente da un sistema di origine SAP. I team on-premise e private cloud usano la transazione LTMOM, il migration object modeler, per adattare gli oggetti standard o costruirne di propri. Il cockpit è pensato per i caricamenti iniziali, non per interfacce ricorrenti o modifiche di massa.

SAP Data Services è la piattaforma ETL di SAP. La usi per volumi elevati, logiche di trasformazione complesse, più sistemi di origine, o quando vuole un framework di qualità dei dati riutilizzabile che sopravviva al progetto.

Strumenti ETL di terze parti come Informatica, Talend o Microsoft SSIS hanno senso dove l'organizzazione li possiede già e ne ha le competenze.

SAP Datasphere, ora parte di SAP Business Data Cloud, non è uno strumento di migrazione. Il suo posto è il livello di analytics dopo il go-live. Conta se lascia lo storico nel sistema legacy e deve comunque farne reporting.

Per la maggior parte delle implementazioni standard, il Migration Cockpit copre la maggioranza degli oggetti. Volumi elevati, sistemi legacy molto personalizzati o strutture di origine insolite richiedono di solito Data Services o uno strumento ETL a fianco. Le conversioni da ECC sono un esercizio diverso, trattato nella mia guida alla migrazione da ECC a S/4HANA.

Che cos'è la migrazione dei dati SAP?

La migrazione dei dati SAP consiste nell'estrarre i dati dai sistemi legacy, trasformarli per adattarli alle strutture e alle regole di SAP e caricarli in SAP nell'ambito di un'implementazione o di una conversione. Gli oggetti tipici sono i business partner (clienti e fornitori), i materiali con i dati di stabilimento, gli ordini di acquisto e di vendita aperti, i saldi di magazzino, le partite aperte finanziarie e i cespiti. È difficile perché SAP impone dipendenze e regole di validazione che i sistemi legacy spesso non avevano.

Quali sono i principali approcci alla migrazione dei dati SAP?

Una nuova implementazione (greenfield) carica dati anagrafici selezionati e partite aperte in un sistema S/4HANA nuovo, lasciando lo storico nel sistema legacy o in un archivio. Una conversione di sistema (brownfield) converte sul posto un sistema ECC esistente e il suo storico. La selective data transition sta a metà strada: sposta company code, oggetti o intervalli temporali selezionati. La scelta giusta dipende dalla qualità dei dati, dai requisiti di storico e da quanto del vecchio processo si vuole mantenere.

Che cos'è lo SAP Migration Cockpit e quando usarlo?

Lo SAP S/4HANA Migration Cockpit è lo strumento raccomandato da SAP per il caricamento iniziale dei dati in S/4HANA, in tutte le edizioni. Da S/4HANA 2020 gira come app Fiori Migrate Your Data; la transazione LTMC è deprecata. Fornisce oggetti di migrazione predefiniti, valida i dati prima della registrazione e segnala gli errori a livello di campo. Lo usi per oggetti standard a volumi normali. Affianchi SAP Data Services o un altro strumento ETL quando volumi, logiche di trasformazione o strutture di origine vanno oltre ciò che i template gestiscono.

Per quanti mock load deve essere pianificata una migrazione dei dati SAP?

Almeno tre, con l'ultimo che sia una prova generale completa del cutover. I programmi complessi ne richiedono di più. In un piano tipico, il primo individua le lacune strutturali di mappatura. Il secondo testa le correzioni e fa emergere i problemi di qualità dei dati. Il terzo affronta regole di business e casi limite. L'ultima esecuzione ripete esattamente il cutover, e la sua riconciliazione diventa la baseline per il giorno del go-live.

Come si migrano clienti e fornitori in SAP S/4HANA?

Come business partner. In S/4HANA i dati anagrafici di clienti e fornitori si gestiscono tramite il business partner, con i ruoli di cliente e fornitore associati. In una nuova implementazione, il Migration Cockpit li carica tramite i suoi oggetti business partner. In una conversione da ECC, l'integrazione cliente-fornitore va configurata ed eseguita prima della conversione stessa.

Che cosa fa fallire la migrazione dei dati SAP al cutover?

Cinque schemi causano la maggior parte dei cutover falliti. Troppo pochi mock load. Una sequenza di cutover mai testata end to end. Modifiche al legacy dopo l'ultimo mock con un caricamento del delta non testato. Lacune di riconciliazione lasciate aperte. Approvazione del business basata su un controllo a campione. «I primi 1.000 record sembravano a posto» non è validazione. Il go-live richiede conteggi e totali riconciliati.