Errori nei progetti ERP: trattare la migrazione dei dati da dettaglio tecnico

Ho visto aziende arrancare per mesi con clienti duplicati e transazioni sparite, e ho visto un progetto salvarsi perché le prove in ambiente separato e una verifica severa avevano trovato gli errori prima del giorno buono. La differenza fra i due destini non stava nel software: stava nel rango riconosciuto ai dati. Chi li tratta da dettaglio tecnico del trasloco carica nel sistema nuovo, insieme ai dati, la sfiducia di chi dovrà usarlo.

Questo è il terzo dei sei errori di questa serie sui progetti ERP. Il sistema è stato scelto guardando il costo totale, il perimetro e i requisiti sono firmati: ora bisogna portarci dentro l’azienda, ed è il momento in cui l’errore più sottovalutato presenta il conto.

La prima stampa sbagliata

Il sistema nuovo si giudica dai suoi dati, e il giudizio si forma nel primo giorno.

Un sistema appena acceso non ha reputazione: se la costruisce con le prime stampe, le prime bolle, i primi saldi. Una fattura intestata al cliente sbagliato vale più di dieci dimostrazioni riuscite, e il passaparola interno fa il resto: la gente torna ai fogli di calcolo, e il pezzo sul TCO ha già contato quanto costano le procedure ombra che così ricompaiono.

La casistica pubblica è generosa di esempi. Il rapporto GAO sulle cause dei fallimenti nei sistemi gestionali federali registra il caso del deposito militare di Tobyhanna: per errori di conversione dei dati furono ordinati e ricevuti, per sbaglio, tre autocarri di rondelle, poi restituiti, e l’esercito ripiegò su procedure manuali lente e a loro volta soggette a errore. Lo stesso rapporto conta il caso della NASA: dodici anni e circa 180 milioni di dollari su due tentativi falliti, e al terzo ancora nessun bilancio verificabile. I dati non erano un dettaglio del progetto: erano il progetto. E la diagnosi del rapporto suona familiare a chi segue questa serie: le cause ricorrenti stanno in tre famiglie, i processi disciplinati (requisiti, test, conversione dei dati e interfacce), la gestione delle persone, cambiamento compreso, e il governo dell’informatica. Sono, in pratica, l’indice di questa serie, scritto da un revisore dei conti.

E la malattia non è solo pubblica. Gli studi di settore di Bloor Research, ripresi dalla stampa specializzata, contano che solo il 62% dei progetti di migrazione dati chiude nei tempi e nel bilancio, con budget medi da 875.000 dollari e sforamenti medi da 268.000: numeri di seconda mano, da prendere come ordini di grandezza, ma la proporzione parla da sola.

Cosa si migra e cosa no

Anagrafiche e partite aperte viaggiano; lo storico va in archivio, non nel sistema nuovo.

L’errore di impostazione più comune è trattare la migrazione dei dati come un trasloco totale: tutto ciò che sta nel sistema vecchio deve arrivare nel nuovo. È la scelta che gonfia i tempi, moltiplica la pulizia e intasa il sistema appena nato di storia che nessun processo userà. La decisione vera è un inventario con tre destini.

La riga dell’archivio storico è quella che fa discutere, e la regola pratica è netta: si migra ciò che serve a operare da domani mattina, si archivia ciò che serve a rispondere alle domande su ieri. Un archivio consultabile costa una frazione della migrazione dello storico, e invecchia senza far danni.

La pulizia e la certificazione dei dati, coi loro responsabili

Si pulisce nel sistema vecchio, prima del viaggio. Ma un dato pulito non è ancora un dato corretto: serve qualcuno che lo verifichi e lo certifichi con la sua firma.

La pulizia dei dati si fa nel sistema vecchio, prima del viaggio: duplicati da fondere, campi vuoti da riempire o da dichiarare vuoti per sempre, codifiche da uniformare. Farla dopo, nel sistema nuovo, significa inquinare il nuovo per bonificare il vecchio.

La pulizia però risolve solo metà del problema, ed è la metà che si vede. Un’anagrafica senza duplicati, coi campi tutti compilati e le codifiche allineate, è pulita; se la partita IVA appartiene a una società fusa tre anni fa, se il listino è formalmente completo ma coi prezzi fermi a due anni fa, se la giacenza quadra nei registri e non con lo scaffale, quei dati restano sbagliati. Un programma sa dire che due schede sono uguali; non sa dire che il prezzo è vecchio. Pulito vuol dire in ordine, corretto vuol dire vero, e migrare dati puliti ma non veri fa arrivare nel sistema nuovo errori con l’aria di essere stati controllati.

Da qui il secondo lavoro, che chiude il primo: la certificazione dei dati. Per ogni famiglia di dati serve un nome, non un ruolo: un proprietario che decide cosa è un duplicato, cosa si fonde e cosa muore, che verifica i valori sul mondo reale - il magazzino contato, i contratti riletti, i listini confermati dal commerciale - e che alla fine firma dichiarandoli buoni per il sistema nuovo. Quella firma è ciò che rende la migrazione una consegna fra persone invece che un travaso fra archivi. È la delega effettiva del primo pezzo applicata ai dati: se a decidere sui clienti doppi è «il progetto», i clienti doppi arriveranno nel sistema nuovo con una riunione di scuse al seguito.

La trasformazione fra i due modelli

I due sistemi non parlano la stessa lingua: migrare è tradurre, non copiare.

Qui sta la parte del mestiere che nessuna presentazione commerciale racconta. I due sistemi hanno modelli dei dati diversi, e la trasformazione dei dati è una traduzione fra due lingue che si somigliano quanto basta per ingannare. Gli esempi che chi ha migrato riconosce al volo:

• listini, sconti e promozioni: un sistema li modella per cliente, l’altro per canale; uno mette lo sconto nella riga d’ordine, l’altro in una condizione a monte. La stessa parola «listino» copre strutture incompatibili;
• le distinte base e i cicli: la distinta base (BOM, bill of materials, l’elenco di ciò che compone un prodotto) e i cicli di lavorazione hanno profondità, varianti e validità temporali che ogni sistema tratta a modo suo;
• le varianti, i kit e le confezioni: lo stesso articolo venduto singolo, in kit o in scatola da sei può essere un prodotto con tre confezioni o tre prodotti legati, e i due modelli non si convertono senza decisioni;
• il piano dei conti: se durante la migrazione si decide di cambiarlo, la quadratura smette di essere un confronto e diventa una doppia traduzione, con una mappa conto-per-conto che va scritta e firmata prima.

Per toccare con mano quanto divergano i modelli, prendiamo i tre grandi sistemi del mercato - SAP, Microsoft Dynamics 365 F&O e Oracle - e facciamo dire loro due frasi qualunque: una commerciale, sui listini, e una di fabbrica, sulle distinte e sui cicli. Sono i due terreni dove la traduzione costa di più.

I listini nelle tre lingue

«Il 10% al cliente Rossi» diventa un record di condizione, una riga di accordo, o un modificatore.

La frase commerciale è banale: «il cliente Rossi ha il 10% su tutto il catalogo frigoriferi». I tre sistemi la scrivono in tre lingue diverse.

In SAP la frase diventa un record di condizione: una riga in una tabella che dice «questo cliente, questi articoli, questo sconto, con queste date». A trovarla, quando arriva l’ordine, è una sequenza di accesso che prova le combinazioni dalla più specifica alla più generale - prima «cliente e articolo», poi «cliente», poi «gruppo di clienti» - e si ferma alla prima riga che risponde. Uno schema di calcolo mette poi in fila quella condizione con tutte le altre (maggiorazioni, trasporti, imposte) per arrivare al prezzo finale. L’insieme si chiama condition technique, ed è una gerarchia: la regola sta scritta in un punto solo, e copre tutti i casi che le ricadono sotto.

In Dynamics 365 F&O la stessa frase diventa una riga di accordo commerciale, registrata con un giornale prezzi/sconti. La riga vale per una combinazione dichiarata - il cliente Rossi, o il suo gruppo, incrociato con l’articolo o col gruppo dei frigoriferi, con le sue date - e non c’è una cascata da percorrere: la regola è la riga, e per coprire più casi se ne scrivono di più.

In Oracle la frase diventa un modificatore: lo sconto vive in una lista di modificatori che convive coi listini, e davanti alla lista stanno i qualificatori, il cancello che stabilisce chi ha diritto a entrare - «i clienti come Rossi». Chi passa il cancello riceve la pila dei modificatori che gli spettano: sconti, promozioni, maggiorazioni, ognuno con le sue precedenze.

Tre modi legittimi e incompatibili di dire la stessa frase. Chi migra da uno all’altro non copia lo sconto: decide come tradurre gerarchie di ricerca in combinazioni di gruppi, o combinazioni in qualificatori, e ogni traduzione ha perdite ed eccezioni da dichiarare prima, non da scoprire alla quadratura.

Dove la mappa dei listini fa male

La gerarchia, il punto di applicazione, la concorrenza fra regole, e le figure del vecchio sistema che nel nuovo non esistono.

Le tre forme non sono intercambiabili, e le difficoltà della mappa stanno in punti precisi.

La gerarchia contro la matrice. SAP trova un record solo, scendendo la sequenza di accesso dal caso specifico al generale; Dynamics registra righe per combinazione. Tradurre una regola gerarchica in righe piatte la fa esplodere: una condizione con quattro livelli di ripiego diventa decine di righe, una per combinazione coperta. E nel verso opposto, comprimere righe piatte in una gerarchia obbliga a inventare precedenze che nessuno aveva mai scritto.

Il punto di applicazione. Lo stesso 10% può agire sul prezzo di listino, su un netto intermedio o sul totale del documento, e i tre sistemi ordinano i calcoli con leggi proprie: lo schema di calcolo in SAP, i livelli di riga e di totale negli accordi di Dynamics, le precedenze fra i modificatori di Oracle. Due traduzioni giuste dei singoli sconti possono dare totali diversi appena gli sconti si combinano.

Chi vince quando le regole concorrono. Esclusioni fra condizioni, regole di concorrenza fra accordi, incompatibilità fra modificatori: ogni sistema ha la sua legge, ed è la parte che nessuna tabella di conversione cattura. Il cliente che in un sistema prendeva uno sconto, nell’altro ne prende due, o nessuno.

Le figure senza gemello. Promozioni a punti, maturazioni di fine periodo, premi sui volumi: esistono in una lingua e non nell’altra, o esistono con meccaniche diverse. Quelle frasi non si migrano: si riscrivono nella lingua nuova o si rinuncia, e la decisione va presa prima, con l’ufficio commerciale al tavolo.

La conseguenza di metodo: la mappa dei prezzi non si fa per tabelle, si fa per frasi commerciali. Si censiscono le frasi in vigore, si riscrive ognuna nella lingua nuova, e si prova su ordini veri confrontando i totali: è la prova su casi propri del pezzo precedente, arrivata al reparto prezzi.

La fabbrica nelle tre lingue

La distinta, il ciclo e le risorse stanno in oggetti con confini diversi, e l’ordine di produzione nasce copiandoli.

La frase di fabbrica è altrettanto banale: «il tavolo T si monta con quattro gambe e un piano, in due operazioni: il taglio alla sega, poi il montaggio al banco, due ore di falegname». Dentro ci sono tre ingredienti - cosa serve (la distinta base), come si lavora (il ciclo con le sue operazioni), chi e dove lavora (le risorse) - più un quarto oggetto che li mette in moto: l’ordine di produzione, il documento che dice al reparto di fare dieci tavoli per venerdì. I tre sistemi distribuiscono questi ingredienti in oggetti con confini diversi.

In SAP gli oggetti sono due, separati e riusabili: la distinta base elenca gambe e piano, il ciclo di lavorazione elenca le operazioni, e ogni operazione punta a un centro di lavoro, l’anagrafica che porta la capacità, i turni e le tariffe con cui si calcolano i costi. Alla creazione dell’ordine di produzione il sistema fotografa entrambi: seleziona il ciclo e ne trasferisce le operazioni dentro l’ordine, esplode la distinta e ne trasferisce i componenti, genera le prenotazioni dei materiali e i fabbisogni di capacità sui centri di lavoro.

In Dynamics 365 F&O gli oggetti sono ancora due, ma vestiti di versioni: la distinta ha le righe dei componenti e le versioni che dicono per quale prodotto e in quale periodo valgono, e lo stesso vale per il percorso di produzione (la route, il ciclo nella lingua di Microsoft). La particolarità sta nelle risorse: l’operazione può non nominare la macchina e dichiarare invece i requisiti - «una macchina che sappia stampare a venti tonnellate» - lasciando al motore di schedulazione la scelta della risorsa che li soddisfa, dentro i gruppi di risorse disponibili. Distinta e percorso sono le entità principali dell’ordine di produzione: alla creazione vengono copiati dentro l’ordine, e restano modificabili fino all’avvio.

In Oracle (Fusion) il confine cade in un punto diverso: la definizione di lavoro (work definition) fonde la struttura dell’articolo e il ciclo in un oggetto solo, una vista unica di operazioni, materiali e risorse, un livello costruibile per volta: se il tavolo ha un sottoassieme prodotto in casa, quello ha la sua definizione. Le risorse sono persone e macchine assegnate ai centri di lavoro, e le istanze di risorsa portano i nomi veri: il singolo operatore, la singola macchina. L’ordine di lavoro (work order) nasce dalla definizione, che gli detta operazioni, componenti, risorse, quantità e date.

Anche qui la mappa fa male in punti precisi.

Il confine degli oggetti. Migrare verso Oracle vuol dire fondere, per ogni prodotto e livello per livello, due anagrafiche in una definizione sola; migrare nel verso opposto vuol dire separare ciò che era nato insieme. Nessuna delle due operazioni è una copia: è una decisione su dove mettere le cuciture, e le validità temporali e le varianti cambiano casa nel viaggio.

Le risorse senza gemello. Un centro di lavoro SAP con turni e tariffe non è un gruppo di risorse di Dynamics. Se il ciclo vecchio nominava la macchina e il sistema nuovo ragiona per requisiti, la migrazione deve scrivere un vocabolario di capacità che prima non esisteva, e decidere quale macchina «sa fare» che cosa; nel verso opposto si inchioda a una macchina ciò che era flessibile. In entrambi i casi la schedulazione cambia comportamento con dati formalmente giusti, e se ne accorge il reparto.

Gli ordini in corso. L’ordine di produzione non si migra come un’anagrafica, perché ogni sistema lo costruisce copiandoci dentro distinta e ciclo al momento della creazione: un ordine aperto a metà, coi materiali già prelevati e le ore già consuntivate, non ha una traduzione fedele. La regola pratica, per esperienza: si chiude nel sistema vecchio tutto ciò che si può chiudere, si rifà nel nuovo ciò che era appena partito, e la data di taglio la fissa la strategia di passaggio, di cui ora bisogna parlare.

La morale vale più dei singoli casi: due sistemi possono dichiarare la stessa funzionalità e implementarla in modi profondamente diversi, e la sorpresa si scopre alla trasformazione, quando la firma è già data. È un’altra ragione per la prova su casi propri del pezzo precedente: coi vostri listini, i vostri kit, le vostre distinte e i vostri cicli.

La strategia di passaggio

Tutto insieme, per gradi, o in parallelo: è la decisione che comanda tutte le altre.

Nessun pezzo di questa serie, finora, aveva detto come si accende un ERP, ed è la decisione di regia dell’intera migrazione: la strategia di passaggio. Le forme sono tre:

• il big bang: si spegne il vecchio e si accende il nuovo in una finestra sola, di solito un fine settimana lungo. È la forma più pulita e la più rischiosa, perché il ritorno indietro ha ore contate;
• il passaggio a fasi: per società, per stabilimento o per processo. Riduce il rischio di ogni passo e allunga il periodo in cui i due sistemi convivono, col doppio binario di costi che il pezzo precedente ha messo in conto;
• il parallelo: i due sistemi lavorano insieme e si confrontano. È la forma più prudente sulla carta e la più cara in pratica, perché ogni operazione si fa due volte, e chi la fa due volte è chi ha già un reparto da mandare avanti.

La strategia comanda il calendario dei dati. Fissa il congelamento delle anagrafiche: il momento da cui il sistema vecchio non accetta più modifiche ai dati in viaggio, e ogni eccezione va gestita a mano due volte. E decide fin quando resta possibile tornare al sistema vecchio: nel big bang tornare indietro è un’operazione, nelle fasi una manovra, nel parallelo è quasi gratis perché il vecchio non ha mai smesso di lavorare. Il piano che governa quel ritorno ha una sezione sua, più avanti.

Il ripuntamento delle interfacce

Le interfacce non sono migrazione: sono flussi permanenti che al passaggio cambiano canale.

Il confine va detto esplicito, perché nei progetti si confonde: le interfacce coi sistemi di terzi non sono migrazione dei dati. La migrazione è un evento, si fa una volta e si chiude con una firma; le interfacce sono flussi permanenti, e il pezzo sul TCO ne ha già contato i costi ricorrenti. Ma al passaggio si toccano in tre punti. Cambiano canale: ogni flusso va ripuntato dal vecchio al nuovo, tutto in una finestra nel big bang, con un doppio instradamento nelle fasi, e i terzi vanno avvisati per tempo su chi risponderà loro. Si provano insieme ai dati: una migrazione di prova che non prova le interfacce lascia fuori metà del passaggio. Rispettano il congelamento: anche i flussi in ingresso si fermano o si accodano, sennò i dati cambiano sotto il camion mentre il trasloco è in corso.

Il confine concettuale è netto, ma il rischio viaggia insieme: il GAO archivia «conversione dei dati e interfacce di sistema» nella stessa famiglia di problemi ricorrenti, ed è il modo di un revisore per dire quello che ogni capo progetto scopre al passaggio.

Le prove e la quadratura

Si prova finché i tempi e gli scarti non sono noti, e si chiude con una firma contabile.

La migrazione vera dev’essere la replica noiosa di una prova già riuscita. La migrazione di prova è il passaggio completo, interfacce comprese, eseguito e cronometrato: il cronometro dice se la finestra del fine settimana basta davvero, e gli scarti dicono dove la trasformazione perde i pezzi. Si ripete finché i numeri non diventano prevedibili, e ogni giro alimenta la pulizia e affina le mappe.

A validare gli scarti servono occhi che riconoscono i dati a colpo d’occhio dentro le procedure nuove: i key user, le stesse persone che mandano avanti i reparti. Il loro tempo per la validazione va prenotato come una risorsa del progetto, con i responsabili che li liberano davvero: è lo stesso vincolo visto nel pezzo precedente per gli aggiornamenti in cloud, e arrivarci senza averlo pianificato significa validare di notte, male.

Gli studi Bloor aggiungono una raccomandazione organizzativa che l’esperienza conferma: una squadra interna dedicata alla migrazione, che accumuli il mestiere dei giri di prova invece di disperderlo, e che faccia da sponda stabile ai proprietari dei dati e ai key user.

La chiusura ha una forma sola: la quadratura. I saldi del vecchio e del nuovo a confronto, conto per conto, magazzino per magazzino, e una firma di chi ne risponde, l’amministrazione per i conti, i proprietari dei dati per le anagrafiche. È il criterio di uscita della migrazione: finché la quadratura non torna e non è firmata, il passaggio non è finito, è solo finita l’agenda.

Il piano di ritorno

Si scrive prima, si prova come il resto, e si spera di buttarlo via.

Il piano di ritorno (in inglese rollback) è l’assicurazione del passaggio: cosa succede se, a migrazione fatta, qualcosa di grave impone di tornare al sistema vecchio. Va scritto prima, con le sue condizioni di innesco decise a mente fredda: chi lo dichiara, entro quante ore, su quali sintomi. E va provato nelle migrazioni di prova come tutto il resto, perché un piano di ritorno mai provato è una preghiera con un titolo migliore. La strategia di passaggio decide quanto a lungo resta possibile: dopo giorni di operazioni nel sistema nuovo, tornare indietro significa migrare al contrario, e la finestra si chiude da sola.

Dove prosegue la serie

Dati a posto, sistema acceso: ora tocca alle persone.

Il prossimo pezzo entra nell’errore più umano della serie: le persone lasciate all’oscuro del cambiamento, con i key user che qui hanno validato i dati e là diventano il perno della formazione e del supporto. Poi vengono i test sacrificati alla data, e l’abbandono dopo il lancio.

I concetti che questo articolo introduce

Nove voci nuove sull’ambito ERP, con gli agganci al criterio di uscita e alla delega.

---

Fonti

• U.S. Government Accountability Office, Financial Management Systems: Additional Efforts Needed to Address Key Causes of Modernization Failures, GAO-06-184, marzo 2006 - le cause ricorrenti dei fallimenti nei sistemi gestionali federali; i tre autocarri di rondelle ordinati per errore di conversione al deposito di Tobyhanna, coi ripieghi manuali che ne seguirono; la NASA al terzo tentativo dopo dodici anni e circa 180 milioni di dollari, ancora senza bilanci verificabili.
• Le documentazioni ufficiali dei tre modelli di prezzo citati nell’esempio dei listini, aperte e consultate: SAP, Condition Technique and Pricing; Microsoft Learn, Sales trade agreement prices; Oracle Advanced Pricing Implementation Guide, Modifiers.
• Le documentazioni ufficiali dell’esempio di fabbrica, aperte e consultate: SAP, Production Orders (PP-SFC) per il ciclo e la distinta copiati nell’ordine alla creazione; Microsoft Learn, Bills of materials and formulas, Routes and operations e Production order lifecycle overview per le versioni, i requisiti di capacità e la copia nell’ordine; Oracle, Overview of Work Definitions, How You Manage Resources e Overview of Work Orders per la definizione di lavoro, le risorse con le istanze e l’ordine di lavoro.
• Bloor Research, studi sulle migrazioni di dati (2000, 2007 e 2011), citati qui attraverso la ripresa di Network World: il 62% dei progetti nei tempi e nel bilancio, budget medi da 875.000 dollari, sforamenti medi da 268.000. Il rapporto originale è a registrazione: fonte di seconda mano, i numeri valgono come ordini di grandezza documentati, non come misure verificate qui.
• Le regole pratiche di questo pezzo, cosa si migra e cosa si archivia, le prove cronometrate, la quadratura firmata, vengono dall’esperienza diretta di chi scrive: errori visti, non letti.