La migrazione dei dati è il filone di lavoro più sistematicamente sottostimato in tutti i programmi ERP che ho gestito. Il vendor ipotizza tre mesi di lavoro sui dati. La realtà ne richiede da sei a nove. Al cutover metà del team sta spegnendo incendi tra i duplicati e lo steering committee chiede perché nessuno lo abbia segnalato prima.
Ho costruito questo strumento per anticipare quella conversazione di qualche mese. Dimensiona il lavoro per oggetto dati, per volume e per ERP di destinazione, e restituisce una stima in giorni-persona, una fascia di costo e un approccio di migrazione consigliato. È indipendente dal vendor e copre SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite e Microsoft Dynamics 365 e AX.
Il risultato è un intervallo, non un valore unico, perché la realtà è un intervallo. Le variabili che spostano di più il numero sono la qualità dei dati, il numero di sistemi sorgente e quanto storico decide di portare con sé.
Scelga l'ERP di destinazione. Aggiunga gli oggetti dati nel perimetro e i volumi di record previsti per ciascuno. Imposti con onestà l'indicatore di qualità dei dati. Lo strumento restituisce l'impegno per oggetto, un intervallo complessivo in giorni-persona, una fascia di costo e un approccio consigliato (Migration Cockpit, LSMW, ETL custom o ibrido).
Tutto gira nel suo browser. Non viene inviato nulla. Non viene salvato nulla. Modifichi gli input quante volte vuole per mettere alla prova il risultato rispetto alle sue ipotesi.
- Dati anagrafici clienti: relazioni di committente, destinatario merce, pagatore e destinatario fattura, funzioni partner
- Dati anagrafici fornitori: record dei fornitori, condizioni di pagamento, ritenute alla fonte, coordinate bancarie
- Dati anagrafici materiali: dati di base, viste di stabilimento, viste di vendita, MRP, contabilità e calcolo dei costi
- Conti di contabilità generale e piano dei conti: costi primari e secondari, gerarchie
- Centri di costo, centri di profitto, ordini interni: dati anagrafici di controlling
- Ordini d'acquisto aperti: testata, posizioni, ripartizioni di consegna, assegnazioni contabili
- Ordini di vendita aperti: testata, posizioni, condizioni, dati partner
- Fatture aperte (AP e AR): partite aperte con assegnazioni e regole di compensazione
- Giacenze di magazzino: per ubicazione di magazzino, lotto, stock speciale
- Transazioni finanziarie storiche: registrazioni, saldi, riporto di fine anno
- Anagrafica cespiti e storico degli ammortamenti: per classe di cespite e area di ammortamento
- Dati anagrafici HR: dipendenti, unità organizzative, posizioni, dove SuccessFactors o HCM rientrano nel perimetro
Inserisca i dati della migrazione
I campi contrassegnati con * sono obbligatori.
Lo schema è sempre lo stesso. La fase di discovery si svolge in workshop, con i responsabili dei sistemi presenti. Dicono che i dati sono «sostanzialmente puliti». La stima si costruisce su questa affermazione. Nessuno esegue una sola query di profilazione prima che il numero finisca nel business case.
Un cliente del manifatturiero mi ha detto che i suoi codici articolo erano standardizzati. Abbiamo estratto i dati e trovato 12 formati diversi in uso. In un altro programma il sistema di riferimento per le note sui clienti si è rivelato un campo custom che nessuno aveva documentato, e tre anni di storico sono spariti perché il mapping lo aveva ignorato. In una migrazione finanziaria l'unica persona che conosceva il piano dei conti legacy era andata in pensione cinque anni prima.
Il momento costoso è scoprire questi problemi durante le prove di cutover, non in fase di pianificazione. Una correzione sulla qualità dei dati individuata nella seconda settimana di discovery costa giorni. La stessa correzione scoperta nel terzo mock cutover costa al programma settimane, a volte un trimestre. A quel punto le date sono pubbliche, la rete del change è mobilitata e rinviare il go-live diventa una discussione da board.
La mossa giusta è profilare i dati prima di firmare la stima. Esegua query vere sulla sorgente. Conti i duplicati. Conti i valori nulli. Conti i record che oggi non rispettano le regole sui campi obbligatori del sistema di destinazione. Lo strumento parte dal presupposto che Lei lo faccia. La fascia di costo si allarga nettamente quando imposta con onestà l'indicatore di qualità dei dati.
L'approccio giusto dipende dall'ERP di destinazione, dai volumi di dati e da quanti sistemi sorgente deve consolidare. Qui sotto trova, a grandi linee, ciò che scelgo di solito, con l'impegno riferito all'opzione più semplice.
| Approccio | Ideale per | Moltiplicatore di impegno | Strumenti |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | S/4HANA greenfield, oggetti standard, volumi medi | 1,0× | LTMC, LTMOM, template forniti da SAP |
| LSMW | ECC, migrazioni legacy, programmi ancora su release precedenti | 1,2× | LSMW, sessioni BDC registrate |
| ETL custom tramite SAP BTP / Integration Suite | Volumi elevati, trasformazioni complesse, consolidamento di più sorgenti | 2,0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Ibrido (Cockpit + ETL) | Conversioni brownfield a S/4HANA e migrazioni selettive | 1,5× | Cockpit per i dati anagrafici, ETL per lo storico transazionale |
| Nativo Oracle | Destinazioni Oracle Fusion Cloud ed EBS | 1,3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Destinazioni Dynamics 365 F&O e AX | 1,3× | Entità DMF, Azure Data Factory |
L'ETL custom è l'opzione più flessibile e la più costosa. Il test onesto per capire se serve è questo: i dati sorgente violano le regole standard della destinazione in modi che nessun template può correggere senza una logica record per record? Se la risposta è no, resti sugli strumenti standard forniti.
- SAP S/4HANA (greenfield, brownfield, selettivo)
- SAP ECC (ancora rilevante per i landscape paralleli e le migrazioni tardive)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Programme manager che dimensionano il filone dati prima che il system integrator (SI) si impegni su un numero.
- Responsabili della migrazione dei dati che mettono alla prova la propria stima interna rispetto a una base indipendente.
- CIO e CFO che verificano la voce dati in un budget di implementazione da molti milioni di dollari.
- Consulenti indipendenti che producono numeri difendibili in proposte o revisioni di assurance.
- Team ERP interni che costruiscono il business case senza pagare un incarico di scoping a parte.
- Un numero difendibile, in fretta. Stima in giorni-persona oggetto per oggetto, invece di una sola ipotesi.
- Neutrale rispetto ai vendor. Costruito sugli schemi ricorrenti dei programmi SAP, Oracle e Microsoft, non sul playbook di un solo vendor.
- Approccio consigliato. Indica se il punto di partenza giusto è Migration Cockpit, LSMW, ETL custom o un approccio ibrido.
- Sensibile a volume e qualità. La fascia di costo si allarga quando la qualità dei dati cala, come accade nei programmi reali.
- Gratuito, solo nel browser, senza registrazione. Nulla lascia il suo computer. Aggiorni la pagina e ricominci quante volte serve.
Quanto sono accurate le stime di migrazione dei dati di questo strumento?
I numeri riflettono gli schemi che ho visto nei programmi SAP, Oracle e Dynamics negli ultimi 25 anni. Servono a fissare un punto di riferimento per la pianificazione, non a sostituire una profilazione dei suoi dati reali.
La leva più importante per l'accuratezza è aver eseguito query di profilazione sulla sorgente. Una fascia di costo costruita su un indicatore di qualità dei dati onesto regge. Una costruita sull'ottimismo dei workshop no. Usi il risultato dello strumento come numero di base nel confronto con il SI. Se la stima del SI è nettamente più bassa, chieda quale ipotesi sulla qualità dei dati stia facendo e come l'abbia validata.
Devo migrare le transazioni finanziarie storiche o solo le partite aperte?
Per la maggior parte dei programmi la risposta giusta è: partite aperte più saldi di apertura, con lo storico che resta consultabile nel sistema legacy tramite un archivio in sola lettura o un livello di reporting. Migrare l'intero storico transazionale moltiplica l'impegno, rallenta le riconciliazioni e raramente ripaga il costo.
L'eccezione sono i settori regolamentati in cui gli obblighi di conservazione di legge richiedono che lo storico risieda nel sistema di riferimento, o le aziende per cui i confronti anno su anno nel nuovo sistema sono un reale requisito operativo. In entrambi i casi il moltiplicatore di impegno dello strumento per i dati storici tiene conto del carico maggiore.
Quale approccio di migrazione consiglia lo strumento?
Sceglie il punto di partenza in base all'ERP di destinazione, all'insieme di oggetti e ai volumi. Un S/4HANA greenfield con oggetti standard di solito porta al Migration Cockpit. Le conversioni brownfield e le migrazioni selettive tendono verso un approccio ibrido. Volumi elevati, più sistemi sorgente o trasformazioni pesanti spostano la raccomandazione sull'ETL custom su BTP o su una piattaforma equivalente lato Oracle o Microsoft.
La raccomandazione è un punto di partenza. La decisione vera si prende dopo un proof of concept su un campione dei suoi dati, non con un calcolatore. Consideri il risultato come l'ipotesi di lavoro da portare in quell'esercizio.
Posso esportare il piano o condividerlo con il mio team?
Il calcolatore funziona interamente nel browser. Può fare uno screenshot del risultato oppure copiare i numeri per oggetto nel suo foglio di pianificazione. Non c'è alcun account, non c'è l'esportazione in PDF e nulla viene salvato lato server. È una scelta voluta. Se desidera un'analisi più approfondita dei numeri, prenoti una call di 30 minuti e porti lo screenshot.
Copre anche dati diversi da quelli anagrafici, come configurazione e sicurezza?
No. Lo strumento considera solo i dati anagrafici e quelli transazionali. I dati di configurazione, i ruoli di sicurezza, gli sviluppi custom e gli oggetti di integrazione appartengono ad altri filoni, con driver di impegno propri, e non vanno ammassati nella voce dati. Metterli tutti in un unico numero è una delle ragioni per cui le stime di migrazione dei dati saltano già in fase di pianificazione.
Come gestisce i rollout multi-regione e multi-entità?
Lo strumento dimensiona un singolo evento di migrazione. Per un rollout multi-regione lo esegua una volta per ondata e sommi le ondate, applicando un fattore di riduzione per template, mapping e strumenti che riutilizza dalla prima ondata in poi. Nella mia esperienza la seconda ondata costa circa il 60-70% della prima, la terza scende intorno al 50% e poi si stabilizza. Gli oggetti dati di legge locali (fiscale, payroll, bancario) sono di solito la parte che non si riutilizza senza attriti.
Lo strumento funziona per le conversioni brownfield da ECC a S/4HANA?
Sì, e tiene conto del minor impegno sugli oggetti che si convertono sul posto rispetto a quelli che richiedono un nuovo mapping. Una conversione brownfield richiede in genere dal 40 al 60% dell'impegno sui dati di una migrazione greenfield equivalente, perché le strutture di clienti, fornitori, materiali e piano dei conti passano senza una nuova estrazione. Il carico maggiore è di solito la conversione dei business partner e l'impatto della nuova contabilità generale sulle registrazioni storiche.
Il calcolatore è gratuito?
Sì. Nessuna registrazione, nessun obbligo di lasciare l'email, nessun pagamento. Il calcolo gira nel suo browser e nulla viene salvato o inviato altrove. Se desidera aiuto per costruire il business case della migrazione dei dati una volta ottenuto un numero, prenoti una call di 30 minuti.