L'aspetto più sorprendente di una migrazione ERP non è il software che cambia. È quello che diventa la wiki che la documenta, mentre la migrazione procede.
Aprendo questa wiki si incontrano contemporaneamente due progetti. Il primo è una migrazione ERP: un retailer fashion, con qualche migliaio di SKU a stagione, sta abbandonando l'ERP storico per una piattaforma cloud moderna, mentre intorno orbitano un sistema satellite frontend-online, una suite gestionale di terze parti, un CRM commerciale, un paio di applicativi verticali per il prodotto e uno strato di BI. Il secondo progetto è la wiki stessa: alcune centinaia di pagine in un knowledge management tool che documentano quel passaggio attraverso decine di decisioni, di problemi, di domande aperte, di verbali, di persone, di moduli, di voci di glossario. I due progetti non sono indipendenti: il modo in cui la wiki è fatta riflette il modo in cui la migrazione si sta facendo, un assemblaggio iterativo di pezzi parziali che cercano di tenere insieme un sistema-mondo.
Il sistema-mondo prima del cambio
I verbali coprono un arco di alcuni mesi e raccontano un'azienda che vive di flussi documentali fragili. Una merce arriva senza documento di trasporto corretto, una fattura proforma viene cancellata e altera lo storico nella reportistica BI, le coordinate bancarie nel template conferme sono obsolete, le anagrafiche dei buyer arrivano incomplete. Sul fronte logistico la complessità è artigianale: rientro campioni dallo shooting fotografico senza automatismo, magazzino centrale e magazzino negozio con priorità da bilanciare a mano, brand store-driven e brand online-driven che richiedono criteri ordine diversi ma li impongono allo stesso software. Sul fronte commerciale, il B2B convive con marketplace, retail diretto e canali accessori. Un solo ERP, troppi modelli operativi.
Le persone tengono insieme tutto questo a mano. Il graph del progetto identifica un piccolo gruppo di referenti, un project sponsor lato direzione, una responsabile operations, un controller, alcuni capi-funzione su buyer e logistica, non per gerarchia ma per centralità nelle decisioni: sono i nodi su cui converge la maggior parte delle decisioni e dei problemi. La migrazione, in questa lettura, è un tentativo di trasferire dalle persone ai sistemi la conoscenza che oggi sta nelle teste.
La pipeline che ricostruisce il sistema-mondo
Per questo la wiki non poteva essere scritta a mano. L'impianto è quello dell'LLM wiki di Karpathy: non RAG sui documenti grezzi a query-time, ma un LLM che costruisce e mantiene in modo persistente una base interconnessa di pagine, sorgente dopo sorgente. Sotto la cartella degli script vive una pipeline di ingest che converte i verbali grezzi in pagine strutturate: un hash su ogni sorgente alimenta un manifest con delta tracking, un convertitore documentale normalizza in Markdown, e un'estrazione LLM parallela (più worker, una chiamata per ciascun tipo di entità) produce persone, decisioni, problemi, moduli e domande con il loro frontmatter. Il pezzo più interessante è la funzione di matching: una normalizzazione accent-aware riconosce che "Mario" e "Mario Rossi" potrebbero essere la stessa persona, ritorna match esatto, parziale o nessuno, e lascia decidere al merge se arricchire una pagina esistente o crearne una nuova. Il merge del frontmatter e delle liste è idempotente: la pipeline è rieseguibile senza creare duplicati né perdere annotazioni manuali.
C'è un parallelo evidente. La pipeline fa per i verbali quello che il nuovo ERP dovrà fare per i flussi aziendali: prendere informazione semi-strutturata, deduplicarla contro un'anagrafica esistente, integrarla senza distruggere ciò che è stato curato a mano. Persino il principio "no documenti, no ricezione", che le riunioni hanno adottato per la merce in ingresso, ha il suo gemello tecnico nello schema della wiki: nessun campo del frontmatter è opzionale per caso, ogni entità deve dichiarare tipo, stato, data, related.
L'idempotenza del merge è una proprietà che molti software gestionali italiani non hanno: rieseguire l'import di un file produce duplicati invece di aggiornamenti puliti. È esattamente il debito tecnico che la migrazione sta tentando di scaricare nel nuovo sistema. La wiki, nel frattempo, lo ha già scaricato.
Le decisioni che si tengono insieme
Le decisioni accumulate nel vault non sono indipendenti: il knowledge graph mostra che convergono su tre assi. Il primo è pagamenti e credito: policy pre-shipment per il B2B con valutazione di copertura assicurativa, depositi e acconti collegati alla conferma ordine, alert automatici sulle proforma scadute, controlli incrociati sulla fatturazione marketplace. Il secondo è tracciabilità e status: uno schema di status operativo univoco nell'ERP, il flusso proforma generato a partire dal collo, il booking della merce in ingresso con documenti obbligatori. Il terzo è automazione governata: adozione di AI per l'indossato virtuale ma con controllo manuale sistematico, valutazione di tool per l'associazione automatica codici prodotto, alert di disponibilità verso la ricezione logistica.
Il god node più connesso del graph è una singola riunione di metà progetto, con oltre cinquanta archi che vi convergono. È il momento in cui i tre assi entrano nella stessa stanza: conferme ordini, tracciabilità pagamenti, reportistica clienti, roadmap B2B. Non è un caso che sia tra le ultime nella sequenza temporale coperta: è la riunione in cui le decisioni prese nei mesi precedenti vengono finalmente operativizzate.
Le sorprese che il grafo svela
Qui la duplicità del progetto produce il suo dividendo. Letta come testo, la wiki racconta la migrazione. Letta come grafo (qualche migliaio di nodi, quasi diecimila archi, oltre il 90% di edge estratti direttamente dai documenti e non inferiti), rivela cose che nessuno, leggendo i verbali uno per uno, vedrebbe.
Tre esempi. Primo: due nodi-persona, "Mario" e "Mario (CRM)", compaiono distinti, collegati da un edge marcato AMBIGUOUS: la deduplica non è ancora chiusa, e il grafo lo dice prima ancora che qualcuno se ne accorga rileggendo i verbali. Secondo: un edge INFERRED tra "depositi/acconti e tracciabilità pagamenti" e "adeguamento flussi di fatturazione marketplace con controlli incrociati" mostra che due decisioni nate in riunioni diverse stanno risolvendo lo stesso problema strutturale: la riconciliazione tra ordine, pagamento e fatturazione attraverso un canale terzo. Terzo: il nodo "proforma" è connesso al problema "la cancellazione di una proforma altera la disponibilità storica nel tool di BI" da un edge inferito che nessun verbale ha mai dichiarato esplicitamente. È un'inferenza del grafo, ma è esatta: cambiare il flusso proforma cambierà la BI a valle, e questo va messo nel piano.
C'è anche un hyperedge, un gruppo di nodi che partecipano insieme a un pattern, etichettato "flusso operativo buyer / caricamento ordini". Il grafo ha riconosciuto che alcune entità sparpagliate su cartelle diverse della wiki formano in realtà un unico processo operativo. È esattamente il tipo di evidenza che alimenta la prossima fase del progetto: capire dove la rifattorizzazione sul nuovo ERP può consolidare, non solo replicare.
Quello che resta aperto
Le domande nella cartella domande/ sono il fronte di lavoro aperto: come l'ERP smista automaticamente migliaia di righe ordine sulla maschera giusta, dove si parcheggiano le merci che cambiano destinazione dopo essere state prese a magazzino, quali responsabilità si assegnano al project manager interno della migrazione e quali no. Il grafo, nel suo stato attuale, mescola ancora segnale e rumore: buona parte delle community sono codice di plugin del tool documentale, da escludere con una regola di ignore. La pipeline di ingest ha già superato un test di riusabilità su un dominio completamente diverso (uno standup di sviluppo software, con tutte le asserzioni superate), il che lascia intravedere un futuro in cui questa stessa infrastruttura serva non solo questa migrazione ma le successive.
La conclusione che vale per entrambi i progetti è la stessa. Una migrazione ERP non è il passaggio da un software a un altro, ed è per questo che richiede una wiki: è il passaggio dalla conoscenza tacita delle persone a un modello esplicito che il sistema possa eseguire. La wiki è il laboratorio in cui quel modello viene articolato, e il knowledge graph è lo strumento con cui si verifica che le sue parti si tengano insieme. Quando il giorno dell'avvio il nuovo ERP sostituirà quello storico, ciò che davvero sarà migrato non è il software: è quello che oggi questa wiki sta imparando a dire.
Se questo tema risuona con una migrazione che stai pianificando, scrivimi: andrea.iorio@me.com. Le conversazioni partono di solito da un verbale che nessuno riesce più a interpretare.