Enterprise Resource Planning (ERP)

L’ERP (Enterprise Resource Planning) si riferisce a una classe di software aziendale che supporta le operazioni di routine dell’azienda e tiene traccia delle sue risorse, in particolare denaro contante, materie prime, lavori in corso, prodotti finiti, ordini dei clienti, ordini di acquisto e stipendi. Gli ERP includono tipicamente molti moduli destinati alle funzioni aziendali principali, come contabilità, approvvigionamento, distribuzione, finanza, vendite, … e offrono un’integrazione stretta all’interno di questi moduli per facilitare il flusso delle informazioni (transazionali) tra le funzioni. Gli ERP sono costruiti su database relazionali e presentano tipicamente un design molto esteso: un gran numero di entità (ad esempio prodotti, clienti, fatture, ecc.), numerose schermate e un alto grado di configurabilità.

Origine e motivazione

Durante gli anni ‘70, è diventato gradualmente evidente che i record elettronici presentavano molti vantaggi rispetto alla tradizionale documentazione cartacea. I record elettronici stavano diventando più economici, più veloci e più affidabili rispetto ai record cartacei. Due invenzioni che precedono gli ERP sono state fondamentali per potenziare i record 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à e riducendo gli errori amministrativi. Tuttavia, sebbene i lettori di codici a barre avessero migliorato notevolmente l’acquisizione dei dati in molte situazioni, memorizzare, organizzare e elaborare i record elettronici rimaneva in qualche modo un problema aperto per due decenni. I database relazionali sono stati la risposta dell’industria del software a questo problema alla fine degli anni ‘70 e, a distanza di cinque decenni, i database relazionali rimangono la pratica dominante per quanto riguarda la gestione dei dati aziendali.

Tuttavia, i sistemi di database relazionali “nudi”, come tipicamente venduti all’inizio degli anni ‘80, si sono rivelati molto costosi da implementare, poiché ogni azienda stava reinventando come rappresentare tutto nel proprio database: prodotti, clienti, fatture, pagamenti, ecc. Così, durante gli anni ‘80, è emersa una serie di aziende software che vendevano sistemi relazionali “preconfigurati”. Questi prodotti sarebbero stati successivamente indicati collettivamente come ERP, un termine coniato negli anni ‘90. Purtroppo, l’acronimo ERP è un termine improprio; avrebbe dovuto essere Enterprise Resource Management anziché Planning. Infatti, la pianificazione è - al massimo - una preoccupazione secondaria per gli ERP. Come dettagliato di seguito, l’analisi predittiva è essenzialmente in contrasto con il design principale degli ERP.

Storicamente, gli ERP hanno guadagnato popolarità perché hanno semplificato una serie di operazioni che in precedenza richiedevano sforzi amministrativi estesi. Ad esempio, emettere un ordine di acquisto a un fornitore richiedeva di compilare un modulo con il nome e l’indirizzo del fornitore. Le righe dell’ordine dovevano includere solo riferimenti validi ai prodotti. Successivamente, al momento della ricezione delle merci, le quantità ricevute dovevano corrispondere a quelle indicate nell’ordine di acquisto originale e, una volta che la consegna veniva considerata conforme, doveva essere generato un ordine di pagamento in base a un modello con l’importo corretto, la data corrispondente alle condizioni di pagamento del fornitore e l’identificazione corretta del numero di conto bancario del fornitore. Tutto ciò può essere trovato nell’ERP e i controlli di coerenza possono essere facilmente effettuati in modo automatizzato.

Il mercato degli ERP ha conosciuto una rapida crescita alla fine degli anni ‘90, alimentata principalmente dai progressi costanti nell’hardware informatico (processore, memoria, archiviazione), che era diventato accessibile a aziende di tutte le dimensioni.

Negli anni ‘90, gli ERP sono diventati il nucleo software della maggior parte delle grandi aziende quando l’attività ruotava principalmente attorno al flusso di merci. Al contrario, le aziende orientate principalmente verso i servizi di solito adottavano un software CRM (Customer Relationship Management) come nucleo. Gli ERP e i CRM condividono molte caratteristiche, compreso il loro design condiviso su database relazionali. Gli ERP adottano tipicamente una prospettiva incentrata sulla transazione per la maggior parte delle loro funzionalità, mentre i CRM adottano una prospettiva incentrata sul cliente.

Il design degli ERP

Gli ERP sono diversi, poiché il mercato include molti fornitori che hanno continuato a sviluppare molte versioni dei loro prodotti ERP nel corso di decenni, eppure, nel nucleo, la maggior parte delle implementazioni segue ancora linee di design molto simili. Gli ERP sono emersi come strati di software “preconfigurati” implementati su database relazionali. Pertanto, il processo di progettazione degli ERP prevede la catalogazione di:

• entità, ovvero 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 più basilari che gli utenti finali si aspettano quando si occupano di entità.
• logica aziendale che fornisce comportamenti automatizzati che eliminano la necessità di molte attività amministrative, che possono essere automatizzate in base a regole ben definite, come la conversione degli ordini dei clienti in fatture dei clienti.

Poiché le aziende sono estremamente diverse e complesse, c’è una continua necessità di nuove entità, interfacce utente e logiche aziendali più raffinate che sono necessarie per coprire le pratiche aziendali in evoluzione. Questo rappresenta un enorme sforzo continuo da parte dei fornitori di ERP. Questa sfida è poi aggravata da tutte le ambiguità che sorgono quando si cerca di servire verticali molto diversi. Lo stesso termine, come “pagamento”, riflette realtà e processi molto diversi da un settore all’altro. Nel software, la complessità tende ad avere costi non lineari, ovvero supportare il doppio delle funzionalità in un prodotto costa molto di 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’intento esplicito di ridurre i costi associati alla gestione della complessità.

In particolare, molti fornitori di ERP hanno progettato linguaggi DSL (Domain Specific Programming) che sono destinati a integrare il linguaggio di query sottostante - tipicamente una variante di SQL al giorno d’oggi - del database relazionale sottostante. Attraverso un DSL ben progettato, l’estensione dell’ERP (cioè nuove entità, interfacce o logiche) per coprire le specificità di una determinata azienda può essere fatta con meno risorse rispetto all’effort richiesto con un linguaggio di programmazione generale.

Dagli anni 2000, i fornitori di ERP open source - che sono emersi sfruttando i database relazionali open source che erano diventati disponibili alla fine degli anni ‘90 - di solito hanno adottato una strategia di plug-in alternativa (invece di DSL), in cui l’ERP è progettato per essere esteso attraverso l’introduzione di codice personalizzato, adattato per ogni azienda cliente, che viene scritto nello stesso linguaggio di programmazione generale dell’ERP stesso. Questa strategia è più leggera da eseguire per il fornitore di ERP (nessun DSL da progettare) e allineata con la natura open source dell’ERP.

Offerta

Poiché i costi di implementazione e supporto delle funzionalità aumentano con il numero complessivo delle funzionalità, la maggior parte dei fornitori di ERP adotta una strategia di prezzo basata su moduli: le funzionalità vengono raggruppate in “moduli” che si concentrano su aree funzionali distinte all’interno dell’azienda: gestione delle scorte, finanza, paghe, ecc. L’ERP viene venduto su base modulare, consentendo alle aziende clienti di selezionare i moduli più urgenti e di posticipare gli altri per investimenti successivi.

La strategia di prezzo basata su moduli offre anche al fornitore di ERP una strategia naturale di upselling in cui la base di clienti esistente diventa il target principale per le vendite future. Le aree aziendali che inizialmente non erano state 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 su moduli è un meccanismo efficace per gestire la complessità perché fornisce un feedback diretto al fornitore di ERP sulle aree funzionali in cui la volontà di pagare è maggiore. In tal senso, aiuta il fornitore a dare la giusta priorità ai propri sforzi di ingegneria del software.

Ecosistema

Ogni nuova funzionalità aggiunta all’ERP tende a produrre rendimenti decrescenti per il fornitore di ERP che ha dato la giusta priorità ai propri sforzi di ingegneria del software¹. Infatti, se questa funzionalità non era stata aggiunta in precedenza, probabilmente è perché non interessava abbastanza aziende in primo luogo. Inoltre, le organizzazioni stesse - inclusi i fornitori di ERP - tendono ad essere soggette anche a diseconomie di scala: l’aggiunta di ulteriori ingegneri del software a un prodotto software è notoriamente noto per non produrre guadagni lineari nell’aumento della produttività delle migliorie apportate al prodotto.

Pertanto, la maggior parte dei fornitori di ERP adotta una strategia di ecosistema per delegare gli sforzi di sviluppo dell’ultimo miglio necessari per rendere l’ERP operativo per una determinata azienda a società terze, generalmente note come integratori. Questi integratori addebitano alle aziende clienti l’implementazione e l’implementazione di tutte le funzionalità che non sono offerte dall’ERP “grezzo”. Storicamente, fino agli anni 2000, quando le aziende hanno adottato per la prima volta gli ERP, il lavoro degli integratori era di solito incentrato sull’introduzione di funzionalità extra per l’ERP. Tuttavia, oggi la maggior parte dei progetti ERP sono aggiornamenti, poiché è già presente un ERP legacy. Pertanto, il valore aggiunto principale dell’integratore è garantire una transizione senza intoppi dal vecchio ERP al nuovo. In pratica, questo lavoro comporta la migrazione di dati e processi tra i sistemi.

A differenza dei fornitori di ERP che hanno una strategia aziendale principalmente incentrata sull’ERP stesso, trattato come un asset di proprietà intellettuale (IP), gli integratori di solito adottano qualche forma di addebito giornaliero. Fatturano il loro lavoro in base al numero di giorni lavorati e l’IP del lavoro svolto di solito passa, per contratto, all’azienda cliente stessa.

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

I limiti degli ERP

Gli ERP ereditano la maggior parte dei limiti dei loro sistemi di database relazionali sottostanti². Poi, ulteriori limitazioni derivano dalle strategie di mitigazione della complessità che abbiamo appena descritto nella sezione precedente. Queste limitazioni sono particolarmente interessanti perché sono limitazioni di progettazione e quindi è improbabile che vengano affrontate dalle nuove versioni degli ERP, o piuttosto risolvere tali limitazioni comporterà probabilmente una denaturazione degli ERP al punto in cui non avrebbe più molto senso riferirsi a quei prodotti software come ERP.

Avversi alle letture o scritture grossolane

I database relazionali utilizzati dagli ERP offrono le proprietà ACID (Atomicità, Coerenza, Isolamento, Durabilità) con un design orientato in modo estensivo a un carico di lavoro che coinvolge prevalentemente operazioni di lettura e scrittura di piccole dimensioni, che dovrebbero essere eseguite con basse latenze - tipicamente una frazione di secondo - con letture e scritture che sono approssimativamente bilanciate in volume. Un’analisi dettagliata dei database relazionali va oltre lo scopo del presente articolo, ma questa osservazione riguardante il carico di lavoro previsto per gli ERP spiega, da sola, molte limitazioni degli ERP poco comprese.

A causa del loro design basato su database relazionali, gli ERP sono in gran parte inadatti per l’analisi, le statistiche e la generazione di report quando la quantità di dati non è trascurabile. Accedere a una quantità non trascurabile di dati in qualsiasi ERP - mentre le operazioni aziendali sono in corso - è sempre un problema, perché quando il sistema viene affamato a causa di troppe letture o scritture di dati, il sistema rallenta. Nella pratica, ciò significa che anche le operazioni banali, come l’elaborazione dei codici a barre, rallentano. Nel peggiore dei casi, l’intera azienda si blocca. Pertanto, ogni operazione nell’ERP, lettura o scrittura, deve rimanere piccola, idealmente “triviale”. La quantità di dati che può essere considerata non trascurabile è aumentata notevolmente negli ultimi quattro decenni, insieme all’hardware informatico migliore e più economico. Tuttavia, le aziende hanno approfittato di questo progresso per espandere notevolmente anche la quantità di dati riversati nei loro ERP. Di conseguenza, i sistemi ERP odierni di solito non sono notevolmente più veloci di quanto non fossero due decenni fa.

Ad esempio, gli ERP sono adatti per visualizzare il livello di stock di un SKU, o per aggiornare il suo valore quando viene prelevata o caricata un’unità, ma gli ERP di solito non sono adatti per visualizzare la cronologia consolidata giornaliera delle variazioni di stock di un SKU negli ultimi tre anni. L’intero segmento dei prodotti software per l’Intelligence Aziendale (BI) è emerso negli anni ‘90 come risposta del settore alle limitazioni analitiche degli ERP (e dei CRM). A differenza degli ERP, gli strumenti BI sono progettati intorno a ipercubi in memoria, di solito indicati come OLAP (Online Analytical Processing). Rinunciando alle proprietà ACID, i sistemi OLAP diventano molto più efficienti dal punto di vista hardware rispetto ai database relazionali per fornire statistiche aggregate, come le vendite al giorno, per negozio, per categoria, ecc.

È interessante notare che la maggior parte dei fornitori di ERP sembrava non essere pienamente consapevole di questa limitazione di progettazione nei propri prodotti, anche quelli che sono emersi dopo gli anni ‘90, quando il segmento BI era la prova vivente di questa situazione. Ad esempio, la maggior parte dei fornitori di ERP si è avventurata in funzionalità di previsione della domanda che sono, per progettazione, completamente in contrasto con il loro database relazionale sottostante - ancora 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 destinato ad essere eseguito in batch durante la notte, mitigando così il problema della carenza di risorse menzionato in precedenza, i database relazionali comportano enormi sovraccarichi accidentali quando si tenta di effettuare questo tipo di calcolo. Di conseguenza, al giorno d’oggi, la maggior parte degli ERP dispone di funzionalità di previsione “legacy” che sono cadute in disuso anni, e talvolta decenni, fa.

Avversi a nuovi o distintivi paradigmi

La strategia di catalogazione delle entità utilizzata dai fornitori di ERP non scala linearmente in termini di gestione della complessità. Gli strumenti migliori, come discusso in precedenza, portano solo un sollievo lineare - rispetto al numero di entità - mentre i costi di complessità crescono in modo superlineare. Di conseguenza, i nuovi o distintivi paradigmi si rivelano di solito costosi sia in termini di costi che di ritardi nell’integrazione, raggiungendo spesso il punto in cui è una migliore alternativa saltare del tutto l’ERP. Queste situazioni sono diverse, ne elencheremo alcune di seguito, ma tutte si riducono in modo simile a paradigmi difficili da integrare perché sono arrivati tardi nel processo di sviluppo dell’ERP.

Raggiungere zero downtime operativo è difficile perché, come indicato in precedenza, qualsiasi operazione di lettura o scrittura mette l’ERP a rischio di rallentamento del sistema. Pertanto, tutte queste operazioni vengono generalmente eseguite come batch notturni, quando ci sono poche o nessuna operazione in corso. Tuttavia, questa progettazione è in contrasto con i requisiti del commercio elettronico che sono emersi relativamente tardi nella storia degli ERP. Di conseguenza, la maggior parte dei fornitori di ERP ha separato ampiamente il proprio modulo di commercio elettronico, spesso sfruttando un sistema di database separato, rompendo la regola di progettazione implicita che tutti i moduli ERP vivono nello stesso database (o database). Di conseguenza, i moduli di commercio elettronico supportati da ERP tendono ad essere altrettanto difficili e costosi da implementare come le app di terze parti.

Affrontare i settori di ricondizionamento in cui le merci seguono flussi ciclici complessi (ad esempio riparazioni), mentre gli ERP mainstream sono fortemente orientati ai flussi in avanti - dai produttori ai consumatori - come comunemente si trova nel settore FMCG e della distribuzione. Sebbene la maggior parte delle entità rilevanti necessarie per scopi di ricondizionamento (ad esempio prodotti, scorte, ordini) esistano già negli ERP, le loro progettazioni sono tipicamente completamente in contrasto con i requisiti del ricondizionamento. Spesso è più facile reimplementare completamente queste entità anziché cercare di riciclare quelle di un ERP mainstream in quei settori.

Offrire basse latenze garantite, ad esempio al di sotto della percezione umana (cioè al di sotto dei 50 ms), è difficile perché né l’ERP né il suo database relazionale sono stati progettati con tali requisiti in mente. Tuttavia, il pilotaggio di sistemi altamente automatizzati come i magazzini robotizzati richiede questo tipo di latenze al fine di evitare che l’orchestrazione guidata dal software diventi il collo di bottiglia del sistema. Pertanto, nella pratica, la maggior parte delle aree associate al processing “in tempo reale” ha sistemi dedicati al di fuori dell’ERP.

È interessante notare che ci sono ERP specializzati - che non sempre si definiscono ERP - che hanno intrapreso percorsi di sviluppo alternativi al fine di far fronte precisamente a quelle situazioni. Questi ERP sono tipicamente rivolti a settori di nicchia che non sono adeguatamente serviti dagli ERP mainstream. Tuttavia, questi percorsi di sviluppo alternativi sono tipicamente in contrasto con i requisiti mainstream.

Rischi nelle transizioni ERP

Sebbene possa sembrare paradossale, è tipicamente molto più difficile aggiornare un ERP piuttosto che semplicemente implementarlo per la prima volta. Gli aggiornamenti sono noti per essere processi di durata pluriennale. Anche i semplici aggiornamenti di versione dell’ERP - mantenendo lo stesso fornitore - di solito si rivelano difficili, richiedendo molti mesi di lavoro. Aneddoticamente, questa difficoltà fa regolarmente notizia quando le grandi aziende pubblicano comunicati stampa indicando che gli sforzi di aggiornamento del loro ERP sono andati oltre il budget di centinaia di milioni di dollari o euro. In tali situazioni, il fornitore di 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, come progettati attraverso le forze di mercato elencate in precedenza.

I costi della complessità non scalano linearmente ma superlinearmente. Quando un’azienda adotta un ERP per la prima volta, ha il lusso di adottare gradualmente ogni modulo, un modulo alla volta. Pertanto, il numero di entità / interfacce / logiche coinvolte con ogni iterazione è relativamente piccolo e le estensioni personalizzate possono essere consegnate gradualmente per rendere l’ERP adatto alle esigenze dell’azienda.

Tuttavia, quando l’azienda deve passare a un altro ERP, si trova di fronte al problema di transizione di tutti i moduli contemporaneamente. Infatti, gli ERP sono, per design e per forze economiche³, monoliti software costruiti su un piccolo insieme di database. Pertanto, quando il nuovo ERP deve essere implementato, il percorso di adozione incrementale utilizzato per l’ERP originale non può essere replicato. L’azienda deve quindi passare in modo totale o nullo. Di conseguenza, i costi di implementazione iniziali tendono ad essere molto elevati, mentre lo stato post-implementazione tende ad essere situazioni parzialmente non funzionanti che richiedono fino a diversi anni per essere risolte.

Tecnicamente, questi aggiornamenti sono sempre difficili da implementare perché l’importazione delle entità / interfacce / logiche tra il vecchio e il nuovo sistema non è un’affare uno a uno. La semantica delle entità evolve nel tempo. Ad esempio, il fornitore di ERP potrebbe aver iniziato con una tabella chiamata “Ordini” destinata agli ordini dei clienti. Tuttavia, in seguito, il fornitore deve affrontare i nuovi requisiti, non originariamente pianificati, di gestire i resi dei clienti. La versione successiva dell’ERP ricicla la tabella “Ordini” per i resi dei clienti, ma queste righe hanno ora quantità di ordine negative. Questo cambiamento apparentemente innocuo finisce per complicare notevolmente la migrazione dalla vecchia versione dell’ERP alla nuova.

Tuttavia, l’aggiornamento a un nuovo ERP o a una versione successiva dello stesso ERP non è l’unica opzione per le aziende. Esistono diverse alternative per ridurre i rischi della transizione. Naturalmente, l’intero ecosistema di fornitori di ERP e integratori ha un vivido interesse finanziario nel promuovere il contrario, come una questione di sopravvivenza del loro modello economico.

Oltre il monolite

Gli ERP sono emersi come un monolite software, ovvero prodotti software in cui tutti i componenti interni sono strettamente accoppiati - una necessità per garantire un’implementazione plug-and-play di tutti i moduli. Inoltre, fino agli anni 2010, la creazione di sistemi distribuiti - ovvero software che opera su un insieme di macchine anziché su poche macchine centrali - era significativamente più difficile e costosa⁴. Pertanto, in larga misura, i fornitori di ERP (la maggior parte dei quali ha decenni di esperienza) non avevano alternative se non costruire i loro prodotti come monoliti.

Tuttavia, con l’affermarsi del cloud computing, gli strumenti e le librerie - spesso open source - sono diventati più popolari e accessibili. Di conseguenza, i costi e gli oneri associati alla progettazione di applicazioni distribuite sono diminuiti costantemente nell’ultimo decennio. L’industria del software ha iniziato a rivedere ampiamente come il valore aggiunto che in passato veniva fornito solo dagli ERP (o software simili agli ERP) possa essere fornito.

L’approccio moderno al software aziendale consiste nel rompere il monolite attraverso una serie di app più piccole che, idealmente, fanno una cosa e la fanno bene⁵. L’unione delle app avviene attraverso API (Interfacce di programmazione delle applicazioni) che sono appositamente progettate per facilitare integrazioni personalizzate in paesaggi applicativi diversi. La maggior parte delle API è progettata per sfruttare strumenti API open source popolari che riducono significativamente i costi di sviluppo associati a tali integrazioni personalizzate.

Queste app hanno a volte costi di integrazione iniziali più elevati rispetto ai moduli ERP integrati. Tuttavia, presentano notevoli vantaggi a lungo termine in quanto riducono notevolmente i rischi delle future evoluzioni del paesaggio applicativo. L’azienda ha la possibilità di aggiornare o sostituire un’app alla volta, il che risulta non solo molto più facile da eseguire, ma anche più economico e meno rischioso. Infine, le app SaaS (Software as a Service) di solito optano per una consegna continua di piccoli cambiamenti incrementali. Sebbene questo modello generi un carico di lavoro continuo, ma limitato, per i team IT, il processo di modifica delle app SaaS è più organico, più economico e meno rischioso rispetto agli aggiornamenti annuali o biennali.

Oltre ai database relazionali

I database relazionali sono stati il pilastro dei sistemi ERP fin dagli anni ‘80. Tuttavia, dagli anni 2010, sono emerse alternative convincenti. La più nota è probabilmente Event Sourcing (ES) abbinato a Command Query Responsibility Segregation (CQRS). Questo approccio offre una scalabilità e una latenza superiori, consentendo anche progettazioni più espressive, in grado di catturare più precisamente le intenzioni aziendali in diverse situazioni.

L’essenza del event sourcing consiste nel trattare ogni modifica nel sistema come un evento immutabile. L’aspetto dell’immutabilità è ispirato alle pratiche contabili: quando una riga si rivela errata in un registro, il contabile non cancella la riga per risolvere il problema, ma aggiunge un’altra riga correttiva nel registro. Conservare l’intera cronologia degli eventi - assumendo che lo storage dei dati sia sufficientemente economico da rendere questa strategia fattibile - comporta numerosi vantaggi: una migliore tracciabilità, auditabilità, sicurezza… Inoltre, l’aspetto immutabile rende i sistemi basati sugli eventi più facili da scalare. I dati possono essere ampiamente copiati e replicati senza dover gestire modifiche ai dati.

Il design CQRS riconosce che, nella maggior parte dei sistemi, i volumi rispettivi di lettura e scrittura sono fortemente sbilanciati. In molte situazioni, il volume delle letture supera di gran lunga il volume delle scritture di diversi ordini di grandezza. Tuttavia, i database relazionali sono progettati per volumi di letture e scritture (in qualche modo) simmetrici. CQRS separa esplicitamente le responsabilità per letture e scritture, tipicamente in due sottosistemi distinti. Questo design comporta anche vantaggi, principalmente in termini di latenza, scalabilità ed efficienza hardware.

Tuttavia, sebbene ES e CQRS siano già popolari in grandi aziende tecnologiche orientate al consumatore e nel trading quantitativo (finanza), hanno iniziato solo di recente a guadagnare terreno nel software aziendale mainstream. Di conseguenza, gli strumenti ES+CQRS sono ancora agli inizi rispetto ai loro omologhi nel campo dei database relazionali. Tuttavia, questo approccio offre modi per ridurre notevolmente i costi hardware e comprimere le latenze che spesso rimangono un problema acuto per la maggior parte delle implementazioni ERP.

Il punto di vista di Lokad

Poiché gli ERP non sono adatti nemmeno per scopi analitici - da qui la necessità di strumenti di BI (Business Intelligence) - non dovrebbe sorprendere che il loro track record sia disastroso quando si tratta di analisi predittive. A titolo di prova aneddotica, nessuna delle rivoluzioni di machine learning / data science si è verificata negli ERP, e quando si affrontano quelle classi di requisiti, i team ricorrono invariabilmente a fogli di calcolo o script ad hoc.

Lokad stesso è emerso come un’app specializzata destinata ad integrare - non sostituire - gli ERP come un livello analitico dedicato all’ottimizzazione predittiva delle supply chain. La maggior parte delle nostre funzionalità principali, come le capacità di previsione probabilistica, destinate a supportare decisioni banali come scorte / acquisti / produzione / assortimento / prezzi, sono praticamente impraticabili da implementare all’interno dei sistemi ERP.

Note