Pianificazione delle risorse aziendali (ERP)

ERP (Enterprise Resource Planning) si riferisce a una classe di enterprise software che supporta le operazioni quotidiane dell’azienda e traccia le sue risorse, in particolare contanti, materie prime, lavori in corso, prodotti finiti, ordini dei clienti, ordini di acquisto e buste paga. Gli ERP includono tipicamente molti moduli destinati alle funzioni aziendali di base, cioè contabilità, approvvigionamento, distribuzione, finanza, vendite, … e offrono un’integrazione stretta tra tali moduli per facilitare il flusso delle informazioni (transazionali) tra le funzioni. Gli ERP sono costruiti sopra database relazionali e tipicamente presentano un design molto esteso: un elevato numero di entità (ad es. prodotti, clienti, fatture, ecc.), numerosi schermi e un alto grado di configurabilità.

Origine e motivazione

Negli anni ‘70, è diventato gradualmente evidente che i documenti elettronici presentavano molteplici vantaggi rispetto alla tradizionale documentazione cartacea. I documenti elettronici stavano diventando più economici, veloci e affidabili rispetto ai documenti cartacei. Due invenzioni che precedettero gli ERP furono fondamentali per potenziare i documenti elettronici: i lettori di codici a barre (anni ‘50) e i database relazionali (anni ‘70). I lettori di codici a barre offrivano un modo superiore per gestire i flussi di merci, aumentando la produttività riducendo gli errori di segreteria. Tuttavia, mentre i lettori di codici a barre avevano migliorato drasticamente l’acquisizione dei dati in molte situazioni, l’archiviazione, l’organizzazione e l’elaborazione dei documenti elettronici rimasero per due decenni un problema irrisolto.

Tuttavia, i sistemi di database relazionali “nudi”, come venivano tipicamente venduti all’inizio degli anni ‘80, si rivelarono molto costosi da implementare, poiché ogni azienda doveva reinventare come rappresentare tutto nel proprio database: prodotti, clienti, fatture, pagamenti, ecc. Così, durante gli anni ‘80, emerse una serie di società software che vendevano sistemi relazionali “pre-configurati”. Questi prodotti sarebbero stati in seguito collettivamente indicati come ERP, un termine coniato negli anni ‘90. Purtroppo, l’acronimo ERP è fuorviante; avrebbe dovuto essere Enterprise Resource Management piuttosto che Planning. Infatti, la pianificazione è, nel migliore dei casi, una preoccupazione secondaria per gli ERP. Come dettagliato di seguito, l’analisi predittiva è fondamentalmente in contrasto con il design core degli ERP.

Storicamente, gli ERP hanno guadagnato terreno perché hanno snellito una serie di operazioni che in precedenza richiedevano ampie attività di segreteria. Ad esempio, emettere un ordine di acquisto a un fornitore richiedeva il completamento di un modulo con il nome e l’indirizzo del fornitore. Le righe dell’ordine dovevano includere solo riferimenti di prodotto validi. Successivamente, al ricevimento delle merci, le quantità ricevute dovevano corrispondere a quelle indicate nell’ordine di acquisto originale e, una volta ritenuta conforme la consegna, doveva essere generato un ordine di pagamento basato su un modello con l’importo corretto, la data in linea con le condizioni di pagamento del fornitore e identificando correttamente il numero di conto bancario del fornitore. Tutto ciò si trova nell’ERP e i controlli di coerenza possono essere effettuati in modo automatizzato.

Il mercato degli ERP ha registrato una rapida crescita alla fine degli anni ‘90, trainata principalmente dal costante progresso dell’hardware informatico (processore, memoria, storage), che era diventato accessibile a aziende di tutte le dimensioni.

Negli anni ‘90, gli ERP divennero il nucleo software della maggior parte delle grandi aziende, quando il business ruotava principalmente attorno al flusso delle merci. Al contrario, le aziende focalizzate maggiormente sui servizi solitamente adottavano come core un software CRM (Customer Relationship Management). Gli ERP e i CRM condividono molte caratteristiche, incluso il loro design comune basato su database relazionali. Gli ERP adottano tipicamente una prospettiva incentrata sulle transazioni per la maggior parte delle loro funzionalità, mentre i CRM adottano una prospettiva incentrata sul cliente.

Il design degli ERP

Gli ERP sono diversificati, poiché il mercato include molti fornitori che hanno continuato a proporre numerose versioni dei loro prodotti ERP per decenni e, tuttavia, nel cuore, la maggior parte delle implementazioni segue linee di design molto simili. Gli ERP sono emersi come strati software “pre-configurati” implementati sopra database relazionali. Pertanto, il processo di progettazione dell’ERP implica la catalogazione di:

• entità, cioè tutti i concetti o oggetti che l’ERP deve rappresentare, come prodotti, pagamenti, scorte, fornitori… Ogni entità può coinvolgere una o più tabelle nel database relazionale sottostante. La maggior parte degli ERP definisce centinaia di entità, e fino a migliaia per gli ERP più complessi.
• interfacce utente che consentono agli utenti finali di visualizzare e modificare i dati delle entità. Queste interfacce sono dominate dal design CRUD (Create / Read / Update / Delete), che rappresenta le operazioni di base che gli utenti finali si aspettano quando interagiscono con le entità.
• logica aziendale che fornisce comportamenti automatizzati, eliminando la necessità di molte attività di segreteria, che possono essere automatizzate in base a regole ben definite, come la conversione degli ordini dei clienti in fatture.

Poiché le aziende sono incredibilmente diverse e complesse, c’è un flusso continuo di esigenze per entità, interfacce utente e logiche aziendali nuove o raffinate necessarie a coprire le pratiche aziendali in evoluzione. Ciò rappresenta un enorme sforzo costante da parte dei fornitori di ERP. Inoltre, questa sfida si complica ulteriormente a causa di tutte le ambiguità che sorgono quando si tenta di servire verticali molto diverse. Lo stesso termine, come “payment”, riflette realtà e processi molto differenti da un verticale all’altro. Nel software, la complessità tende ad avere costi non lineari, cioè supportare il doppio delle funzionalità in un prodotto costa molto più del doppio del costo originale.

Di conseguenza, i fornitori di ERP hanno adottato una serie di strategie per rendere i loro investimenti software più competitivi.

Tecnologia

Per far fronte alla complessità, la prima strategia adottata dai fornitori di ERP consiste nello sviluppare tecnologie con l’esplicito intento di abbassare i costi associati alla gestione della complessità.

In particolare, molti fornitori di ERP hanno sviluppato DSL (Domain Specific Programming Languages) progettati per integrare il linguaggio di query sottostante - tipicamente una variante di SQL al giorno d’oggi - del database relazionale sottostante. Grazie a un DSL ben progettato, l’estensione dell’ERP (cioè maggiori entità, interfacce o logiche) per coprire le specificità di una data azienda può essere realizzata con meno risorse rispetto allo sforzo richiesto utilizzando un linguaggio di programmazione generico.

Dagli anni 2000, i fornitori di ERP open source - emersi sfruttando i database relazionali open source disponibili alla fine degli anni ‘90 - di solito hanno adottato una strategia plug-in alternativa (invece dei DSL), in cui l’ERP è progettato per essere esteso tramite l’introduzione di codice personalizzato, su misura per ciascuna azienda cliente, scritto nello stesso linguaggio di programmazione generico usato per l’ERP stesso. Questa strategia è più semplice da eseguire per il fornitore di ERP (nessun DSL da progettare) ed è in linea con la natura open source dell’ERP.

Offerta

Poiché il costo di implementare e supportare le funzionalità cresce con il numero complessivo di funzionalità, la maggior parte dei fornitori di ERP adotta una strategia di prezzo basata sui moduli: le funzionalità sono raggruppate in “moduli”, che si concentrano su distinti ambiti funzionali all’interno dell’azienda: controllo delle scorte, finanza, buste paga, ecc. L’ERP viene venduto su base modulare, consentendo alle aziende clienti di scegliere i moduli più urgenti e rimandare gli altri a investimenti futuri.

La strategia di prezzo basata sui moduli offre anche al fornitore di ERP una naturale strategia di upsell, in cui la base clienti esistente diventa il target principale per le vendite future. Le aree di business che non erano state inizialmente coperte dal set originale di moduli dell’ERP ottengono nuovi moduli dedicati che, a loro volta, possono essere venduti alle aziende clienti.

Questa strategia di prezzo basata sui moduli è un meccanismo efficace per far fronte alla complessità perché fornisce un feedback diretto al fornitore di ERP sulle aree funzionali in cui la disponibilità a pagare è maggiore. In tal modo, aiuta il fornitore a dare la giusta priorità ai propri sforzi di ingegneria del software.

Ecosistema

Ogni funzionalità extra aggiunta all’ERP tende a produrre rendimenti decrescenti per il fornitore di ERP che ha correttamente prioritizzato i propri sforzi di ingegneria del software¹. Infatti, se questa funzionalità non era stata aggiunta prima, probabilmente è perché non riguardava abbastanza aziende sin dall’inizio. Inoltre, le organizzazioni stesse - inclusi i fornitori di ERP - tendono a subire diseconomie di scala: aggiungere ulteriori ingegneri del software a un prodotto è notoriamente noto per non produrre guadagni lineari nella produttività delle migliorie apportate al prodotto.

Pertanto, la maggior parte dei fornitori di ERP adotta una strategia di ecosistema per delegare quelle operazioni di sviluppo dell’ultimo miglio necessarie per rendere l’ERP operativo per una determinata azienda a società terze, tipicamente note come integratori. Questi integratori fanno pagare alle aziende clienti l’implementazione e il dispiegamento di tutte le funzionalità non offerte dall’ERP “grezzo”. Storicamente, fino agli anni 2000, quando le aziende adottavano per la prima volta gli ERP, il lavoro degli integratori era solitamente incentrato sull’introduzione di funzionalità extra per l’ERP. Oggi, tuttavia, la maggior parte dei progetti ERP sono aggiornamenti, poiché un ERP legacy è già in uso. Pertanto, il valore aggiunto primario dell’integratore è garantire una transizione senza intoppi dal vecchio ERP al nuovo. In pratica, questo lavoro comporta la migrazione dei dati e dei processi tra i sistemi.

A differenza dei fornitori di ERP che hanno una strategia di business principalmente orientata all’ERP stesso, trattato come un bene di proprietà intellettuale (IP), gli integratori di solito adottano una tariffa basata sulle giornate lavorative. Fatturano il loro lavoro in base al numero di giorni lavorati e la proprietà intellettuale del lavoro svolto, di solito, spetta per contratto all’azienda cliente.

Sviluppare un ecosistema diversificato di integratori, sia in termini geografici che verticali, è un modo efficace per mitigare la complessità intrinseca associata allo sviluppo degli ERP. Quasi tutti i grandi fornitori di ERP hanno sviluppato reti di integratori di notevole dimensione.

I limiti degli ERP

Gli ERP ereditano la maggior parte delle limitazioni dei loro sistemi di database relazionali sottostanti². Inoltre, ulteriori limitazioni derivano dalle strategie per attenuare la complessità che abbiamo appena descritto nella sezione precedente. Queste limitazioni sono particolarmente interessanti perché sono limitazioni di design e, pertanto, è improbabile che vengano affrontate nelle versioni successive degli ERP, anzi, risolvere tali limitazioni comporterebbe probabilmente una denaturazione degli ERP al punto tale che non avrebbe più molto senso continuare a definirli ERP.

Avversi a operazioni di lettura o scrittura massicce

I database relazionali utilizzati dagli ERP garantiscono le proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità) con un design ampiamente orientato a carichi di lavoro che prevedono principalmente operazioni di lettura e scrittura di piccola entità, che dovrebbero essere eseguite con latenze basse - tipicamente una frazione di secondo - con letture e scritture approssimativamente bilanciate in volume. Un’analisi dettagliata dei database relazionali va oltre lo scopo del presente articolo, ma questa osservazione riguardo al carico di lavoro previsto per gli ERP spiega, da sola, molte limitazioni poco comprese degli ERP.

A causa del loro design basato su database relazionali, gli ERP sono in gran parte inadatti per l’analisi, le statistiche e i report ogniqualvolta la quantità di dati non sia trascurabile. Accedere a una quantità non trascurabile di dati in un ERP - mentre le operazioni aziendali sono in corso - è sempre un problema, poiché quando il sistema viene soffocato a causa di troppe operazioni di lettura o scrittura, il sistema rallenta. In pratica, ciò significa che operazioni banali, come l’elaborazione dei codici a barre, rallentano anch’esse. Nel peggiore dei casi, l’intera azienda si ferma. Pertanto, ogni operazione nell’ERP, di lettura o di scrittura, deve rimanere piccola, idealmente “banale”. La quantità di dati che può essere considerata non trascurabile è aumentata drasticamente negli ultimi quattro decenni, insieme a hardware informatico migliore e più economico. Tuttavia, le aziende hanno sfruttato questo progresso per espandere notevolmente la quantità di dati inseriti nei loro ERP. Di conseguenza, i sistemi ERP attuali non sono tipicamente visibilmente più veloci di quanto non fossero due decenni fa.

Ad esempio, gli ERP sono ben attrezzati per mostrare il livello di giacenza di una SKU, o per aggiornare il suo valore quando un’unità viene prelevata o caricata, ma tipicamente non sono adatti a mostrare la timeline giornaliera consolidata delle variazioni di giacenza di una SKU negli ultimi tre anni. L’intero segmento Business Intelligence (BI) di prodotti software è emerso negli anni ‘90 come risposta del settore alle limitazioni analitiche degli ERP (e dei CRM allo stesso modo, in effetti). A differenza degli ERP, gli strumenti BI sono progettati attorno a ipercubi in-memory, solitamente riferiti come OLAP (Online Analytical Processing). Abbandonando le proprietà ACID, i sistemi OLAP risultano dramaticamente più efficienti in termini di hardware rispetto ai database relazionali per fornire statistiche aggregate, come le vendite per giorno, per negozio, per categoria, ecc.

È interessante notare che la maggior parte dei fornitori di ERP non sembrava essere pienamente consapevole di questa limitazione di design nei propri prodotti, anche quelli emersi dopo gli anni ‘90, quando il segmento BI era la prova tangibile di tale situazione. Ad esempio, la maggior parte dei fornitori di ERP si è cimentata nell’implementazione di funzionalità di previsione della domanda che sono, per design, completamente in contrasto con il loro database relazionale sottostante - ancor più delle semplici funzionalità di reporting. La previsione richiede l’accesso all’intera storia dei dati transazionali dell’azienda: vendite, resi, livelli di stock, sconti, ecc. Sebbene il calcolo sia tipicamente previsto per essere eseguito in batch durante la notte, mitigando così il problema di esaurimento delle risorse menzionato sopra, i database relazionali comportano enormi costi accidentali quando si tenta di eseguire questo tipo di calcolo. Di conseguenza, al giorno d’oggi, la maggior parte degli ERP presenta funzionalità di previsione “legacy”³ che sono cadute in disuso anni, e talvolta decenni, fa.

Avversi a paradigmi nuovi o distintivi

La strategia di catalogazione delle entità utilizzata dai fornitori di ERP non scala in modo lineare in termini di gestione della complessità. Strumenti migliori, come discusso sopra, offrono solo un sollievo lineare – rispetto al numero di entità – mentre i costi della complessità crescono in modo superlineare. Di conseguenza, nuovi o distinti paradigmi risultano solitamente costosi sia in termini di spesa che di ritardi nell’integrazione, arrivando frequentemente al punto in cui conviene bypassare completamente l’ERP. Queste situazioni sono diverse, ne elencheremo alcune di seguito, ma tutte si riducono sostanzialmente a paradigmi difficili da integrare perché introdotti in una fase tardiva del processo di sviluppo dell’ERP⁴.

Raggiungere zero downtime operativo è difficile perché, come indicato sopra, ogni operazione di lettura o scrittura di grandi dimensioni mette a rischio il rallentamento del sistema ERP. Pertanto, tutte queste operazioni vengono tipicamente eseguite come batch notturni, quando sono in corso poche o nessuna operazione. Tuttavia, questo design è in contrasto con i requisiti dell’ecommerce, emersi relativamente tardi nella storia degli ERP. Di conseguenza, la maggior parte dei fornitori di ERP ha separato in maniera estesa il modulo ecommerce, sfruttando frequentemente un sistema di database separato, rompendo la regola implicita del design secondo la quale tutti i moduli ERP risiedono nello stesso (o negli stessi) database. Di conseguenza, i moduli ecommerce supportati da ERP tendono ad essere difficili ed costosi da distribuire tanto quanto le applicazioni di terze parti.

Gestire verticali di remanifatturazione in cui i beni seguono flussi ciclici complessi (cioè, riparazioni), mentre gli ERP tradizionali sono fortemente orientati verso flussi diretti – dai produttori ai consumatori – come si riscontra comunemente in FMCG e distribuzione. Sebbene la maggior parte delle entità rilevanti necessarie a scopi di remanifatturazione (ad esempio, prodotti, scorte, ordini) esistano già negli ERP, i loro design sono tipicamente in netto contrasto con i requisiti richiesti dalla remanifatturazione. Spesso risulta più semplice reimplementare completamente queste entità piuttosto che tentare di riciclare quelle di un ERP tradizionale in tali verticali.

Fornire latenze garantite basse, per esempio inferiori alla percezione umana (cioè, inferiori a 50ms), è difficile perché né l’ERP né il suo database relazionale sono stati progettati tenendo conto di tali requisiti. Tuttavia, il pilotaggio di sistemi altamente automatizzati, come magazzini robotizzati, richiede questo tipo di latenza per evitare che l’orchestrazione guidata dal software diventi il collo di bottiglia del sistema. Di conseguenza, in pratica, la maggior parte delle aree associate al processing “in tempo reale” dispone di sistemi dedicati al di fuori dell’ERP.

È interessante notare che esistono ERP specializzati – anche se non sempre si definiscono ERP – che hanno intrapreso percorsi di sviluppo alternativi per far fronte esattamente a tali situazioni. Questi ERP puntano tipicamente a verticali di nicchia che non sono adeguatamente serviti dagli ERP tradizionali. Tuttavia, questi percorsi di sviluppo alternativi sono generalmente in contrasto con i requisiti mainstream.

Rischi nelle transizioni ERP

Anche se può sembrare un paradosso, solitamente è enormemente più difficile aggiornare un ERP piuttosto che semplicemente distribuirlo per la prima volta. Gli upgrade sono notoriamente lunghi, estendendosi su più anni; anche un semplice aggiornamento di versione mantenendo lo stesso fornitore si rivela di solito un’impresa che richiede molti mesi. In senso aneddotico, questa difficoltà fa regolarmente notizia, poiché grandi aziende pubblicano comunicati stampa in cui si afferma che i loro sforzi di aggiornamento ERP hanno superato il budget di centinaia di milioni di dollari o euro. In tali situazioni, il fornitore ERP, l’integratore e/o l’azienda stessa vengono incolpati. Tuttavia, sembra che la maggior parte non riconosca che tali problemi sono intrinseci agli ERP stessi, così come sono stati progettati in base alle forze di mercato sopra elencate.

I costi della complessità non scalano in modo lineare, ma in modo superlineare. Quando un’azienda adotta un ERP per la prima volta, ha il lusso di introdurre gradualmente ogni modulo, uno alla volta. Di conseguenza, il numero di entità / interfacce / logiche coinvolte in ogni iterazione è relativamente ridotto, e le estensioni personalizzate possono essere implementate progressivamente per rendere l’ERP adatto alle esigenze dell’azienda.

Tuttavia, quando l’azienda deve passare a un altro ERP, si trova ad affrontare il problema di dover migrare tutti i moduli contemporaneamente. Infatti, gli ERP sono, per design e per forze economiche⁵, dei monoliti software costruiti su un piccolo insieme di database. Pertanto, quando il nuovo ERP deve essere distribuito, il percorso di adozione incrementale usato per l’ERP originale non può essere replicato. L’azienda deve quindi effettuare una transizione in modalità tutto o niente. Di conseguenza, i costi di implementazione iniziali tendono ad essere molto elevati, mentre lo stato post-distribuzione si traduce spesso in situazioni parzialmente disfunzionali che possono richiedere diversi anni per essere risolte.

Dal punto di vista tecnico, questi aggiornamenti sono sempre difficili da implementare perché importare le entità / interfacce / logiche dal vecchio sistema al nuovo non è un’operazione uno-a-uno. La semantica delle entità evolve nel tempo. Ad esempio, il fornitore ERP potrebbe aver iniziato con una tabella denominata “Orders” destinata agli ordini dei clienti. Tuttavia, con il tempo, il fornitore deve rispondere a nuovi requisiti, non originariamente previsti, per gestire i resi dei clienti. La versione successiva dell’ERP riutilizza la tabella “Orders” per i resi, sebbene quelle righe ora presentino quantità ordinate negative. Questo cambiamento apparentemente innocuo finisce per complicare notevolmente la migrazione dalla vecchia versione dell’ERP a quella nuova.

Tuttavia, l’aggiornamento verso un nuovo ERP, o verso una versione successiva dello stesso ERP, non è l’unica opzione per le aziende. In realtà, sono disponibili diverse alternative per ridurre il rischio della transizione. Naturalmente, l’intero ecosistema di fornitori ERP e integratori ha un vivo interesse finanziario a promuovere l’opposto, per la sopravvivenza del loro modello economico.

Oltre il monolite

Gli ERP sono nati come un monolite software, cioè prodotti software in cui tutti i componenti interni sono strettamente accoppiati – una necessità per garantire una distribuzione plug-and-play di tutti i moduli. Inoltre, fino agli anni 2010, costruire sistemi distribuiti – cioè software che operano su una flotta di macchine anziché su poche macchine centrali – era significativamente più difficile e costoso⁶. Pertanto, in larga misura, i fornitori di ERP (la maggior parte dei quali operanti da decenni) non hanno avuto altra alternativa se non costruire i loro prodotti come un monolite.

Tuttavia, man mano che il cloud computing divenne mainstream, strumenti e librerie – spesso open source – divennero più popolari e accessibili. Di conseguenza, i costi e gli overhead associati alla progettazione di applicazioni distribuite sono diminuiti costantemente nell’ultimo decennio. L’industria del software ha cominciato a rivedere ampiamente come il valore aggiunto, storicamente erogato solo dagli ERP (o software simili agli ERP), possa essere distribuito.

L’approccio moderno al software enterprise consiste nel rompere il monolite attraverso una serie di applicazioni più piccole che, idealmente, fanno una cosa sola e la fanno bene⁷. Il collegamento tra queste app viene realizzato tramite API (Application Programming Interfaces), appositamente pensate per facilitare integrazioni personalizzate in diversi contesti applicativi. La maggior parte delle API è progettata per sfruttare strumenti API open source popolari che abbassano significativamente i costi di sviluppo associati a tali integrazioni.

Queste applicazioni a volte presentano costi di integrazione iniziali maggiori rispetto ai moduli ERP incorporati. Tuttavia, offrono benefici a lungo termine consistenti, in quanto riducono notevolmente il rischio di ulteriori evoluzioni del panorama applicativo. L’azienda acquisisce la possibilità di aggiornare o sostituire un’applicazione alla volta, operazione che si rivela non solo molto più semplice da eseguire, ma anche più economica e meno rischiosa. Infine, le app SaaS (Software as a Service) tendono a optare per un rilascio continuo di piccoli cambiamenti incrementali. Sebbene questo schema generi un carico di lavoro costante – ma limitato – per i team IT, il processo di cambiamento tipico del SaaS è più organico, meno costoso e meno rischioso rispetto agli aggiornamenti annuali o biennali.

Oltre i database relazionali

I database relazionali sono stati la spina dorsale de facto degli ERP dagli anni ‘80. Tuttavia, dagli anni 2010 sono emerse alternative interessanti. La più notevole è probabilmente Event Sourcing (ES) abbinato a Command Query Responsibility Segregation (CQRS). Questo approccio offre una scalabilità e latenze superiori, permettendo al contempo design più espressivi, in grado di catturare in maniera più precisa le intenzioni di business in varie situazioni.

Il concetto alla base dell’event sourcing consiste nel trattare ogni cambiamento nel sistema come un evento immutabile. L’approccio all’immutabilità si ispira alle pratiche contabili: quando una riga risulta errata in un libro mastro, il contabile non la cancella per risolvere il problema, ma ne aggiunge una correttiva. Conservare l’intera cronologia degli eventi – ammesso che l’archiviazione dei dati sia sufficientemente economica da rendere questa strategia praticabile – comporta numerosi benefici: migliore tracciabilità, auditabilità, sicurezza… Inoltre, l’approccio immutabile rende più facile scalare i sistemi event-driven. I dati possono essere copiati e replicati in modo estensivo senza dover gestire le modifiche.

Il design CQRS riconosce che, nella maggior parte dei sistemi, i volumi di letture e scritture sono fortemente sbilanciati. In molte situazioni, il volume delle letture (dei dati) supera di diversi ordini di grandezza quello delle scritture. Tuttavia, i database relazionali sono progettati per volumi (piuttosto) simmetrici di letture e scritture. CQRS segrega esplicitamente le responsabilità delle letture e delle scritture, tipicamente in due sottosistemi distinti. Questo design comporta benefici, soprattutto in termini di latenza, scalabilità ed efficienza hardware.

Tuttavia, mentre sia ES che CQRS sono già popolari tra le grandi aziende tecnologiche orientate al consumatore e nel trading quantitativo (finanza), hanno iniziato a guadagnare terreno nel software enterprise mainstream solo molto recentemente. Di conseguenza, gli strumenti ES+CQRS sono ancora in una fase embrionale rispetto ai loro omologhi nel campo dei database relazionali. Ciononostante, questo approccio offre modi non solo per ridurre drasticamente i costi hardware, ma anche per comprimere le latenze che spesso restano un problema acuto per la maggior parte delle implementazioni ERP.

Il parere di Lokad

Poiché gli ERP non sono nemmeno adatti a scopi analitici – da qui la necessità degli strumenti di BI (Business Intelligence) – non sorprende che il loro curriculum risulti pessimo ogni volta che è coinvolta l’analisi predittiva. A titolo aneddotico, nessuna delle rivoluzioni in machine learning / data science è avvenuta negli ERP e, di fronte a tali requisiti, i team ricorrono invariabilmente a fogli di calcolo o a script ad hoc.

Lokad è nata come un’app specializzata destinata a integrare – non a sostituire – gli ERP, fungendo da strato analitico dedicato all’ottimizzazione predittiva delle supply chain. La maggior parte delle nostre funzionalità principali, come le capacità di previsione probabilistica, che mirano a supportare decisioni quotidiane quali scorte / acquisti / produzione / assortimento / prezzi, sono del tutto impraticabili da implementare all’interno dei sistemi ERP.

Note