Il sistema di record dovrebbe essere locale
Ho cominciato a pensare che, for supply chain, la maggior parte delle aziende dovrebbe smettere di acquistare ampi sistemi di record e iniziare a svilupparli localmente. Parlo del software che registra ordini, ricevute, movimenti di magazzino, fatture, approvazioni e le conseguenze burocratiche delle operazioni ordinarie. Questi sistemi sono critici, ma il loro valore è limitato. Essi sono dei registri contabili con flussi di lavoro. Il mercato li valuta, li presenta e li gestisce come se fossero i gioielli della corona dell’azienda. Quel errore è diventato molto costoso.
In Introduction to Supply Chain, in particolare nei Capitoli 5 e 6, ho tracciato una linea di demarcazione tra il software che conserva la documentazione e quello che prende decisioni. Tale distinzione è importante qui. Una volta che analizziamo un sistema di record senza il consueto spettacolo, gran parte del mistero svanisce. Un sistema di record dovrebbe essere affidabile, verificabile e piuttosto noioso. Non dovrebbe fingere di pensare. Dovrebbe memorizzare i fatti, far rispettare alcuni flussi di lavoro e non intralciare.
La tassa nascosta dei registri confezionati
Un sistema di record raggiunge rapidamente la maturità commerciale. Una volta che è in grado di gestire fedelmente acquisti, vendite, inventario, fatturazione e alcuni flussi di lavoro adiacenti, il valore aggiunto di renderlo più ampio è minimo. I fornitori ne sono perfettamente consapevoli. La loro risposta è stata la stessa per decenni: aggiungi un’altra entità, un’altra schermata, un altro modulo, un’altra pagina di configurazione. Vendi il prossimo incremento alla base installata. Col tempo, il prodotto diventa il sedimento di innumerevoli richieste dei clienti, molte delle quali sensate isolate, ma assurde complessivamente. Il risultato è un mastodonte di funzionalità la cui complessità continua ad aumentare, sebbene il compito fondamentale sia a malapena cambiato.
La letteratura accademica ha descritto lo stesso problema in un linguaggio più moderato per anni. Strong e Volkoff hanno osservato che i sistemi aziendali confezionati sono progettati per requisiti generici piuttosto che specifici e, pertanto, tendono a non adattarsi perfettamente in nessuna organizzazione concreta. Un recente studio sulla personalizzazione degli ERP rende esplicito il compromesso: la personalizzazione può migliorare la funzionalità e la soddisfazione degli utenti, ma aumenta anche i costi di implementazione, la complessità e le spese per gli aggiornamenti successivi. Una rassegna del 2025 sugli errori degli ERP giunge a una conclusione altrettanto sobria: i tassi di fallimento nelle implementazioni rimangono elevati, il disallineamento tra processi standardizzati e flussi di lavoro locali persiste, e nessuna pratica industriale ampiamente adottata è emersa per risolvere questi disallineamenti in modo pulito.
Questa tassa non si limita alle tariffe di licenza. Il benchmark ERP del 2025 di Panorama riporta un costo mediano di progetto di 450.000 USD e una tempistica mediana di nove mesi. Tra i progetti che hanno sforato il budget, il motivo più comune è stata l’imprevista necessità di tecnologia aggiuntiva. Tra i progetti in ritardo, le problematiche relative ai dati sono state il principale colpevole. Lo stesso rapporto osserva che molte implementazioni ERP non riescono ancora a eliminare i silos organizzativi. Questo è lo schema che continuo a osservare: la suite non abolisce la complessità; la redistribuisce in integrazione, migrazione, governance e soluzioni alternative elaborate.
I modelli di dati sottostanti raccontano la stessa storia. La documentazione di Microsoft per Dynamics spiega che un concetto aziendale semplice, come un cliente, può essere disperso su diverse tabelle normalizzate, ed è proprio per questo che le entità di dati esistono come astrazioni denormalizzate. La documentazione di Oracle per JD Edwards espone lunghi cataloghi di tabelle suddivise per tipo e modulo. ERPRef, un catalogo di schemi di terze parti, elenca 1.687 tabelle per SAP Business One 9.0 e 5.097 per JD Edwards 9.20; nello stesso catalogo, la tabella delle fatture A/R in SAP Business One 9.3 viene mostrata con 424 colonne. Una determinata azienda utilizzerà solo una piccola parte di questa vastità, eppure paga per essa in termini di permessi, mappature, integrazioni, formazione e aggiornamenti.
C’è una seconda tassa, e spesso è la più dannosa. La visione dell’azienda basata sull’attenzione di William Ocasio parte da una semplice osservazione: ciò che le aziende fanno dipende da come viene canalizzata l’attenzione dei decisori. Un sistema di record dilagante consuma quell’attenzione tanto quanto consuma denaro. Gli anni spesi in implementazioni, pulizie, migrazioni, riprogettazioni, aggiunte e aggiornamenti sono anni in cui il top management viene assorbito dalla meccanica dell’infrastruttura burocratica. Ho sostenuto altrove che, quando i record e i report consumano la maggior parte del budget software, assorbono anche la maggior parte della capacità esecutiva, lasciando poco spazio per il software che potrebbe effettivamente migliorare le decisioni.
Perché il su misura ha smesso di essere difficile
La parte notevole è che il caso tecnico per i sistemi di record su misura ha smesso di essere esotico già da tempo. PostgreSQL vanta quasi quarant’anni di sviluppo attivo ed è conforme agli standard ACID dal 2001. ASP.NET Core è gratuito, open source e multipiattaforma. Entity Framework Core supporta il tracciamento delle modifiche, gli aggiornamenti e le migrazioni dello schema attraverso vari database. Django viene fornito con protezioni integrate contro i comuni attacchi web. Quando le fondamenta del software transazionale sono diventate così mature, costruire un registro interno ristretto non è più un atto di audacia.
C’è addirittura un dettaglio rivelatore nella documentazione di Django. La sua interfaccia di amministrazione automatica è raccomandata come strumento di gestione interna per l’organizzazione, non come front-end pubblico. Quel piccolo commento racchiude l’intera faccenda. L’industria ha standardizzato così a fondo lo scheletro back-office del software CRUD che i principali framework lo forniscono ora di serie. Ciò che rimane difficile non è l’infrastruttura di base, ma decidere quali entità, stati e flussi di lavoro contano veramente per la tua azienda e quali sono presenti solo perché qualche fornitore ha trascorso vent’anni a raccogliere peculiarità da un determinato segmento di mercato.
È qui che il su misura vince in maniera decisiva. Il vantaggio non risiede nella virtuosità del codice, ma nell’esattezza semantica. Le entità possono corrispondere all’azienda così come opera realmente: la sua gerarchia di prodotti, le sue eccezioni negli acquisti, gli stati di ricezione, le regole di approvazione, i motivi per i resi, le sospensioni per qualità e quelle distinzioni singolari ma utili che nessuna suite generica dovrebbe essere in grado di comprendere. Un piccolo codice locale può rimanere comprensibile. Ancora più importante, l’azienda mantiene la proprietà della conoscenza operativa incarnata in quel codice. Il software riflette l’azienda; l’azienda non deve più ereditare i compromessi accumulati dall’intera base clienti di un fornitore.
Cosa hanno cambiato gli agenti di coding
Ciò che è cambiato nel 2025 non è il database, né il browser, né lo stack web. Ciò che è cambiato è il costo di produzione del codice. Nel gennaio 2025, Anthropic ha riportato il 49 percento su SWE-bench Verified per un agente Claude 3.5 Sonnet aggiornato. Ad agosto, Claude Opus 4.1 ha raggiunto il 74,5 percento. Il team SWE-bench ha poi osservato che il mini-SWE-agent ha raggiunto il 65 percento sullo stesso sottoinsieme verificato in una configurazione minima. OpenAI, da parte sua, ha rilasciato Codex come un agente software cloud in grado di lavorare su molti compiti in parallelo, eseguire test e linter in ambienti isolati e proporre modifiche per revisione; in un esperimento interno separato, OpenAI afferma che Codex ha scritto l’intero codice di una base di un milione di righe, realizzata in circa un decimo del tempo che avrebbe richiesto la codifica manuale.
Questo non significa che gli agenti rendano ogni ingegnere più veloce su ogni base di codice. Un trial randomizzato di METR su sviluppatori open-source esperti ha rilevato che, agli inizi del 2025, gli strumenti AI li hanno rallentati del 19 percento quando lavoravano sui propri repository. Prendo quel risultato sul serio. Tuttavia, ciò non descrive lo stesso problema. Mantenere una base di codice pubblica matura con standard rigorosi e anni di contesto tacito non è la stessa attività del redigere un flusso di lavoro per la ricezione, un portale per i fornitori, un back-office per l’aggiustamento delle scorte o una schermata per i resi destinata a un team interno. In quest’ultimo caso, i requisiti sono locali, i criteri di accettazione sono concreti e l’architettura è ordinaria. Un ulteriore studio di METR su orizzonti temporali separati riporta anche che la lunghezza delle attività software che gli agenti di frontiera possono completare con una affidabilità del 50 percento è raddoppiata ogni circa sette mesi. Questo è esattamente il tipo di tendenza che conta quando il lavoro è ristretto e ben definito.
Questo è il motivo per cui anche un produttore, un distributore o un rivenditore ordinario può ora ragionevolmente possedere molta più parte del proprio software transazionale rispetto al passato. Un’azienda del genere non ha bisogno di diventare un fornitore di software. Occorre un responsabile di processo che conosca il business, un referente tecnicamente preparato, un piccolo codice, una suite di test e la disciplina per mantenere il perimetro ristretto. Gli agenti di coding riducono la quantità di implementazione manuale necessaria per le parti noiose, che costituiscono la maggior parte dei sistemi di record. Nel frattempo, lo stack open source maturo si occupa del resto. La combinazione è potente proprio perché i sistemi di record sono così poco glamour. Sono per lo più moduli, tabelle, validazioni, permessi, flussi di lavoro e integrazioni. È lì che gli strumenti sono più efficaci.
Risparmierei comunque i settori in cui il principale valore del fornitore risiede nel tenere il passo con le modifiche normative. Queste sono vere eccezioni. Al di fuori di essi, soprattutto in supply chain, l’approccio predefinito dovrebbe invertirsi. Per i flussi di acquisto, il ricevimento, i resi, le sospensioni per qualità, la collaborazione con i fornitori, la gestione dei dati master e simili ambiti transazionali, il software confezionato ampio è diventato il modo costoso per ottenere un adattamento mediocre. L’alternativa su misura non è più riservata alle aziende tecnologiche. Ora è alla portata delle aziende ordinarie, a condizione che esse siano disposte a possedere una modesta quantità di codice e a resistere alla tentazione di trasformare quella base di codice in una grandiosa piattaforma.
Il caso non è più sentimentale e non è più futuristico. I registri confezionati ampi sono generici per costruzione, inadatti per abitudine e generano inflazione sia in termini di costi che di attenzione. Gli strumenti per costruire sistemi di record ristretti sono maturi da anni. Gli agenti di coding hanno ora compresso l’ultima parte che una volta impediva a molte aziende di agire, ovvero la pura quantità di codifica di routine. Per i sistemi di record in ambito supply chain, l’onere della prova si è capovolto. Un’azienda dovrebbe iniziare chiedendosi perché questo sistema debba essere acquistato in primo luogo.
