Enterprise Resource Planning (ERP)

di Joannes Vermorel, marzo 2020

Quando si parla di sistema ERP (dall’inglese Enterprise Resource Planning) ci si riferisce a una tipologia di software aziendale che supporta le operazioni di routine di un'azienda e ne traccia le risorse, principalmente i flussi di cassa, le materie prime, i lavori in corso, i prodotti finiti, gli ordini di vendita, quelli di acquisto e le retribuzioni. I sistemi ERP generalmente includono moduli progettati per dipartimenti aziendali chiave, come la contabilità, gli acquisti, la distribuzione, la finanza, le vendite e così via, e offrono una stretta integrazione tra questi moduli per facilitare il flusso di informazioni (transazionali) tra i dipartimenti. I sistemi ERP sono costruiti su database relazionali e la loro progettazione è generalmente piuttosto ampia: comprende un gran numero di entità (prodotti, clienti, fatture, ecc.), numerose schermate ed un alto grado di configurabilità.

Come sono nati e perché    Il design degli ERP       Tecnologia       Offerta       Ecosistema    I limiti dei sistemi ERP        Avversi a letture o scritture approssimative        Avversi a paradigmi nuovi o particolari     Rischi nelle transizioni tra sistemi ERP     Oltre il monolito     Oltre i database relazionali    Il punto di vista di Lokad    Note

Come sono nati e perché

Durante gli anni '70, è diventato sempre più evidente che i registri elettronici presentavano numerosi vantaggi rispetto ai tradizionali registri cartacei. A differenza di questi ultimi, i registri elettronici erano più economici, veloci e affidabili. Due invenzioni che hanno preceduto i sistemi ERP sono state fondamentali per promuovere l'adozione dei registri elettronici: i lettori di codici a barre (anni '50) e i database relazionali (anni '70). I lettori di codici a barre offrivano una soluzione migliore per gestire i flussi di risorse, aumentando la produttività e riducendo al contempo gli errori amministrativi. Tuttavia, nonostante questi lettori abbiano migliorato drasticamente l'acquisizione dei dati in molte situazioni, la loro archiviazione, organizzazione ed elaborazione rimarranno problemi irrisolti per altri due decenni. Alla fine degli anni '70, i database relazionali sono nati come risposta dell'industria del software a questo problema, e cinque decenni dopo, questi database sono ancora la pratica dominante per quel che riguarda la gestione dei dati aziendali.

Tuttavia, l'implementazione di database relazionali autonomi, come venivano solitamente venduti nei primi anni '80, si è rivelata molto costosa, poiché ogni azienda reinventava il modo di rappresentare tutti gli elementi del proprio database: prodotti, clienti, fatture, pagamenti, ecc. È così che, negli anni '80, è apparsa tutta una serie di aziende informatiche che vendevano database relazionali “preconfigurati”. Questi prodotti sarebbero poi diventati noti come sistemi ERP, termine coniato negli anni '90. Purtroppo l'acronimo ERP è in realtà un termine impreciso, poiché invece di "pianificazione" si sarebbe dovuto usare il termine "gestione" delle risorse aziendali. In effetti, la pianificazione è, nella migliore delle ipotesi, una questione secondaria per gli ERP. Come spiegheremo più avanti, l'analisi predittiva è sostanzialmente in contrasto con il design di base degli ERP.

Storicamente, gli ERP sono divenuti popolari perché ottimizzavano una serie di operazioni che in precedenza richiedevano sforzi significativi da parte del personale amministrativo. Ad esempio, l'invio di un ordine di acquisto ad un fornitore richiedeva la compilazione di un modulo con il nome e l'indirizzo del fornitore e le linee presenti dovevano includere solo riferimenti a prodotto esistenti. Successivamente, al momento della ricezione della merce, le quantità ricevute dovevano corrispondere a quelle dell'ordine di acquisto originale e, una volta stabilito che la consegna era conforme, si doveva generare un ordine di pagamento con un modello che contenesse l'importo corretto, la data corrispondente ai termini di pagamento del fornitore e il numero di conto corrente bancario del fornitore. Tutte queste informazioni erano presenti nel sistema ERP e i controlli di coerenza potevano quindi essere facilmente eseguiti in modo automatizzato.

Il mercato dei sistemi ERP è cresciuto rapidamente alla fine degli anni '90, una crescita che è stata trainata in gran parte dal costante progresso del materiale informatico (processori, memoria, archiviazione), diventato accessibile alle aziende di tutte le dimensioni.

Negli anni '90, i sistemi ERP sono diventati il software principale per la maggior parte delle grandi aziende in cui il business ruotava intorno al flusso di merci. Le aziende principalmente orientate ai servizi, tuttavia, tendevano ad adottare come sistema principale dei software di CRM (dall’inglese Customer Relationship Management). I due sistemi hanno molti attributi in comune, tra cui il fatto che entrambi sono basati su database relazionali. Mentre i sistemi ERP adottano generalmente un approccio incentrato sulle transazioni per la maggior parte delle loro funzionalità, i sistemi CRM adottano un approccio incentrato sul cliente.

Il design degli ERP

I sistemi ERP sono molto diversi tra loro, in quanto il mercato annovera molti fornitori che, nel corso degli anni, hanno sviluppato nuove versioni dei loro prodotti. Nonostante ciò, la maggior parte delle implementazioni segue ancora linee di progettazione molto simili tra loro. Gli ERP sono apparsi come strati di software "preconfigurati" implementati su database relazionali. Pertanto, il processo di progettazione di un ERP prevede la catalogazione dei seguenti elementi:

• Entità, ovvero tutti i concetti o gli elementi che l'ERP deve rappresentare, come i prodotti, i pagamenti, le scorte, i 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 permettono agli utenti finali di visualizzare e modificare i dati delle entità. Queste interfacce sono dominate dal design CRUD (dall’inglese Create / Read / Update / Delete), che rappresenta le operazioni più basilari che gli utenti finali si aspettano per la gestione delle entità.
• Le logiche aziendali che stabiliscono comportamenti automatizzati che eliminano la necessità di molte operazioni amministrative, che possono essere automatizzate sulla base di regole ben definite, come ad esempio la conversione degli ordini in fatture.
  

Poiché le aziende sono incredibilmente variegate e complesse, esiste una necessità infinita di entità più nuove o raffinate, di interfacce utente e di logiche aziendali necessarie per adattarsi alle mutevoli pratiche aziendali. Questo rappresenta un enorme sforzo per i fornitori di ERP. E questa sfida diventa ancora più complessa quando si aggiungono tutte le ambiguità che sorgono quando si cerca di soddisfare le esigenze di settori molto diversi tra loro. Ad esempio, lo stesso concetto di "pagamento", può riflettere realtà e processi molto diversi da un settore all'altro. Nel mondo dei software, la complessità tende ad avere costi non lineari: supportare il doppio delle funzionalità costa molto più del doppio del costo originale. Di conseguenza, i fornitori di soluzione ERP hanno adottato una serie di strategie per rendere più competitivi i loro investimenti.

Tecnologia

Per far fronte alla complessità, la prima strategia sfruttata dai fornitori di ERP consiste nello sviluppo di tecnologie aventi come intento quello di abbassare i costi associati alla gestione della complessità.

In particolare, molti fornitori hanno progettato linguaggi DSL (dall’inglese Domain Specific Programming) destinati a integrare il linguaggio di interrogazione utilizzato dal database relazionale sottostante. Grazie ad un linguaggio DSL ben architettato, è possibile estendere il sistema ERP (ovvero entità, interfacce o logiche più recenti) per coprire le specificità di una data azieda con meno risorse rispetto all'intraprendere lo stesso sforzo con un linguaggio di programmazione generico.

A partire dagli anni 2000, i fornitori di sistemi ERP open source - emersi avvalendosi dei database relazionali open source apparsi alla fine degli anni '90 - hanno adottato una strategia alternativa di plug-in (al posto dei linguaggi DSL), in cui l'ERP è progettato per essere esteso attraverso l'introduzione di codice personalizzato per ogni cliente, scritto nello stesso linguaggio di programmazione dell'ERP. Questa strategia è più semplice da implementare per il fornitore dell'ERP (nessun linguaggio DSL da progettare), e si allinea alla natura open source dell'ERP.

Offerta

Poiché il costo di implementazione e di supporto delle funzionalità aumenta con il numero di funzionalità globali, la maggior parte dei fornitori di sistemi ERP adotta una strategia tariffaria basata su moduli: le funzioni sono raggruppate in moduli che si rivolgono a diverse aree all’interno dell’azienda: gestione dell'inventario, finanza, retribuzioni, ecc. Il sistema ERP è venduto a moduli, il che permette alle aziende di scegliere i moduli di cui hanno più bisogno e ritardare l'acquisto di altri, lasciandoli per investimenti futuri.

Questa strategia tariffaria offre al fornitore di ERP anche una strategia di upsell, in cui la base di clienti esistente diventa l'obiettivo primario per le vendite future. Al momento opportuno, le aree dell'azienda non coperte originariamente dal set di moduli, possono essere dotate di nuovi moduli a loro dedicati.

Essa è inoltre un meccanismo efficace per la gestione della complessità in quanto fornisce un feedback diretto al fornitore del sistema ERP sulle aree funzionali per le quali i clienti sono più disposti a pagare. E quindi, aiuta il fornitore a dare la giusta priorità ai suoi sforzi di sviluppo software.

Ecosistema

Ogni funzionalità aggiunta all'ERP tende a generare un ritorno minore ridotti per il fornitore dell'ERP che ha stabilito correttamente la priorità dei suoi sforzi di sviluppo del software (1). In effetti, se una funzionalità non era stata aggiunta in precedenza, è probabilmente perché non interessava un numero sufficiente di aziende. Inoltre, anche le organizzazioni stesse (compresi i fornitori di ERP) tendono ad essere soggette a diseconomie di scala: è risaputo che l'aggiunta di ulteriori ingegneri del software al team di sviluppo di un prodotto non genera guadagni lineari nella produzione di miglioramenti apportati al prodotto.

Pertanto, la maggior parte dei fornitori di ERP adotta una strategia che consiste nel delegare ad aziende terze (generalmente note come integratori) quegli sforzi di sviluppo dell' ultimo miglio necessari per rendere operativo il sistema ERP per una data azienda. Questi integratori addebitano alle aziende clienti l'implementazione e il roll-out di tutte le funzionalità che non sono incluse nell'ERP "di base". In passato, fino agli anni 2000, nel momento in cui le aziende adottavano gli ERP per la prima volta, il lavoro degli integratori era di solito incentrato sull'introduzione di funzionalità aggiuntive nell'ERP. Oggi, invece, la maggior parte dei progetti ERP consiste in upgrades, in quanto un ERP ereditato è spesso già in funzione. Pertanto, il principale valore aggiunto dell'integratore è quello di garantire una transizione fluida 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 orientata principalmente al sistema ERP stesso, trattato come un asset di IP (Proprietà Intellettuale), gli integratori adottano generalmente una strategia tariffaria per giornata di lavoro. Essi fatturano il loro lavoro in base al numero di giorni lavorati e la proprietà intellettuale del lavoro consegnato di solito spetta, per contratto, all'azienda cliente.

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

I limiti dei sistemi ERP

I sistemi ERP ereditano la maggior parte dei limiti dei loro sistemi di database relazionali sottostanti (2). A ciò si aggiungono le limitazioni derivanti dalle strategie di attenuazione della complessità descritte nella sezione precedente. Queste limitazioni sono particolarmente interessanti in quanto sono limitazioni di progettazione, e quindi è improbabile che vengano affrontate da versioni più recenti dell'ERP, o meglio, è improbabile che la soluzione di queste limitazioni comporti la denaturazione del sistema ERP a tal punto che non avrebbe più molto senso continuare a chiamarli sistemi ERP.

Avversi a letture o scritture approssimative

I database relazionali utilizzati dagli ERP presentano le proprietà ACID (Atomicità, Consistenza, Isolamento e Durata) con un design orientato principalmente ad un carico di lavoro che comporta operazioni di lettura e scrittura generalmente di ridotte dimensioni, che dovrebbero essere eseguite con bassa latenza - in genere una frazione di secondo – e con volumi relativamente equilibrati. Un'analisi dettagliata dei database relazionali va oltre lo scopo del presente articolo, ma questa osservazione riguardante il carico di lavoro previsto per l’ERP spiega, di per sé, molte delle limitazioni poco comprese dei sistemi ERP.

Per via del loro design basato su database relazionali, i sistemi ERP sono inadeguati per l'analisi, la statistica e la reportistica quando la quantità di dati è notevole. L'accesso a quantità significative di dati in qualsiasi sistema ERP - mentre le operazioni commerciali sono in corso - è sempre problematico, perché quando il sistema soffre a causa di troppi dati in lettura o scrittura, diventa lento. In pratica, questo significa che anche le operazioni di routine, come l'elaborazione dei codici a barre, diventano più lente. E, nel peggiore dei casi, l'intera azienda si blocca. Pertanto, ogni operazione di lettura o di scrittura, deve rimanere contenuta. Negli ultimi 40 anni, grazie al miglioramento del materiale informatico e alla diminuzione dei suoi costi, la quantità di dati che oggi può essere analizzata è aumentata in maniera vertiginosa. Il problema è che le aziende hanno approfittato di questi progressi per aumentare drasticamente la quantità di dati che riversano nei loro sistemi ERP. Di conseguenza, i sistemi ERP attuali non sono in genere più veloci di quanto non fossero due decenni fa.

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

È interessante notare come la maggior parte dei venditori di ERP non sembra essere pienamente consapevole di questa limitazione di progettazione dei propri prodotti, anche quelli nati dopo gli anni '90, quando il segmento della BI era la prova vivente di questo problema. Ad esempio, la maggior parte dei fornitori di ERP si è avventurata nello sviluppo di funzionalità di previsione della domanda che sono, per progettazione, completamente in contrasto con il database relazionale sottostante, ancor più delle semplici caratteristiche di reporting. La previsione richiede l'accesso all'intera cronologia dei dati transazionali dell'azienda: vendite, resi, livelli di scorte, sconti, ecc. Mentre i calcoli sono generalmente destinati ad essere eseguiti durante la notte, attenuando così il problema del sovraccarico del sistema di cui abbiamo parlato sopra, i database relazionali generano sovraccarichi accidentali quando tentano di eseguire questo tipo di calcolo. Di conseguenza, al giorno d'oggi, la maggior parte degli ERP dispone di capacità di previsione "ereditate" (3) che sono cadute in disuso, anni e a volte decenni fa.

Avversi a paradigmi nuovi o particolari

La strategia di catalogazione delle entità utilizzata dai fornitori di sistemi ERP non è lineare in termini di gestione della complessità. Strumenti migliori, come discusso in precedenza, forniscono solo un sollievo lineare – in termini di numero di entità - mentre i costi della complessità aumentano in modo sovralineare. Di conseguenza, i paradigmi nuovi o diversi si rivelano di solito dispendiosi sia in termini di costi che di ritardi nell'integrazione, e spesso raggiungono il punto in cui è meglio evitare del tutto il sistema ERP e optare per un’alternativa. Queste situazioni sono molto varie, di conseguenza ne elencheremo solo alcune di seguito. Tuttavia, tutte si riducono a paradigmi difficili da integrare perché sono arrivati in ritardo nel processo di sviluppo dell'ERP (4).

Raggiungere un tempo di inattività operativa pari a zero è difficile perché, come sottolineato in precedenza, qualsiasi lettura o scrittura importante può portare a un rallentamento generale del sistema. Per questo motivo, tutte queste operazioni vengono generalmente eseguite per batch notturni, quando ci sono poche o nessuna operazione in corso. Tuttavia, questo approccio è in contrasto con le esigenze dell'e-commerce, emerso relativamente tardi nella storia degli ERP. Di conseguenza, la maggior parte dei fornitori di ERP ha provveduto a separare il proprio modulo di e-commerce, spesso sfruttando un database separato, infrangendo la regola implicita di progettazione secondo cui tutti i moduli ERP devono risiedere nello stesso database. Questo fa si che i moduli di e-commerce supportati dagli ERP tendono ad essere tanto difficili e costosi da installare quanto le applicazioni di terze parti.

Qualcosa di simile accade nel settore della rifabbricazione, dove le merci seguono complessi flussi ciclici (le riparazioni), mentre gli ERP sono fortemente orientati verso i flussi a termine - dai produttori ai consumatori - come quelli dei settori del largo consumo e della distribuzione. Mentre la maggior parte delle entità necessarie per la rifabbricazione (prodotti, scorte, ordini) esiste già nei sistemi ERP, i loro progetti sono in genere completamente in contrasto con le esigenze della rifabbricazione. Spesso è più facile reimplementare interamente queste entità piuttosto che cercare di riciclare quelle di un ERP tradizionale in quei settori.

Garantire delle basse latenze, al di sotto della percezione umana (ovvero al di sotto dei 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 i magazzini robotizzati richiede questo tipo di latenze per evitare che l'organizzazione guidata dal software diventi un collo di bottiglia per il sistema. È per questo motivo che, in pratica, la maggior parte delle aree associate all'elaborazione "in tempo reale" (4) hanno sistemi dedicati al di fuori dell'ERP.

È interessante notare che esistono ERP specializzati (non sempre chiamati ERP) che hanno adottato percorsi di sviluppo alternativi per far fronte con precisione a queste situazioni. Questi ERP si rivolgono generalmente a settori di nicchia per i quali i sistemi ERP convenzionali non sono adatti. Tuttavia, questi percorsi di sviluppo alternativi sono generalmente in conflitto con i requisiti tradizionali.

Rischi nelle transizioni tra sistemi ERP

Anche se può sembrare un paradosso, spesso è molto più difficile aggiornare un ERP piuttosto che implementarlo per la prima volta. Gli aggiornamenti sono spesso processi pluriennali. Anche un semplice aggiornamento di versione – mantenendo lo stesso fornitore – può richiedere diversi mesi. Purtroppo, questa difficoltà è spesso all'onore delle cronache, quando ad esempio le grandi aziende pubblicano comunicati stampa che indicano che i loro sforzi per l'aggiornamento dell'ERP hanno superato il budget di centinaia di milioni di dollari o di euro. In tali situazioni, la colpa è del fornitore dell'ERP, dell'integratore o dell'azienda stessa. Eppure, sembra che la maggior parte di loro non riconosca che tali problemi sono intrinseci agli ERP stessi, per la loro stessa progettazione, come spiegato sopra.

I costi della complessità non sono scalabili in modo lineare ma sovralineare. Quando un'azienda adotta un ERP per la prima volta, ha il privilegio di adottare gradualmente ogni modulo, un modulo alla volta o quasi. Pertanto, il numero di entità/interfacce/logiche coinvolte in ogni iterazione è relativamente piccolo, e le estensioni su misura possono essere fornite gradualmente per rendere l'ERP adatto alle esigenze dell'azienda.

Tuttavia, quando l'azienda deve passare ad un altro ERP, deve poi affrontare il problema della transizione di tutti i moduli contemporaneamente. In effetti, gli ERP sono, per progettazione e a causa di forze economiche (5), monoliti software costruiti su piccoli insiemi di database. Di conseguenza, quando il nuovo ERP deve essere implementato, non è possibile replicare il percorso di adozione progressiva utilizzato per l'ERP originale. L'azienda deve quindi effettuare la transizione in modalità "tutto o niente". Di conseguenza, i costi iniziali di implementazione tendono ad essere significativi, mentre il risultato dell’implementazione è spesso un sistema semifunzionale che richiede anni per essere riparato.

Tecnicamente, questi aggiornamenti sono sempre difficili da implementare perché non c'è un'equivalenza uno ad uno nell'importazione delle entità/interfacce/logiche dal vecchio sistema a quello nuovo. La semantica di queste entità si evolve nel tempo. Per esempio, il fornitore di ERP potrebbe aver iniziato con una tabella chiamata "Ordini" che era destinata agli ordini dei clienti. Tuttavia, nel corso del tempo, il fornitore potrebbe aver dovuto rispondere a nuove esigenze, non previste in origine, come per esempio la gestione dei resi. La versione successiva dell'ERP ricicla quindi la tabella "Ordini" per i resi dei clienti, ma queste righe hanno ora quantità di ordini negativi. Questo cambiamento apparentemente innocuo finisce per complicare enormemente la migrazione dalla vecchia versione alla nuova.

Tuttavia, la migrazione verso un nuovo ERP, o verso una versione successiva dello stesso, non è l’unica opzione per le aziende. In realtà sono disponibili diverse alternative per eliminare il rischio legato alla transizione. È naturale che l'intero ecosistema dei venditori e degli integratori di ERP abbia un vivo interesse finanziario a promuovere il contrario, semplicemente perché garantisce la sopravvivenza del loro modello economico.

Oltre il monolito

Gli ERP sono emersi come monoliti, cioè prodotti software in cui tutti i componenti interni sono strettamente connessi tra loro, una necessità per garantire un’implementazione plug-and-play di tutti i moduli. Inoltre, fino al 2010, la progettazione di sistemi distribuiti - cioè di software che funzionano su un parco macchine piuttosto che su poche macchine centrali - era molto più difficile e costosa (6). Pertanto, molti fornitori di ERP (la maggior parte dei quali ha decenni di storia alle spalle) non avevano altra alternativa che realizzare i loro prodotti come monoliti.

Tuttavia, man mano che il cloud computing è diventato popolare, gli strumenti e le librerie - spesso open source - sono diventati più popolari e accessibili. Di conseguenza, i costi e le spese generali associate alla progettazione di applicazioni distribuite sono in costante diminuzione nell'ultimo decennio. L'industria del software ha iniziato a rivedere come il valore aggiunto storicamente fornito solo da sistemi ERP (o software di tipo ERP) possa essere fornito.

L'approccio moderno al software aziendale consiste nel dividere il monolito attraverso una serie di applicazioni più piccole che, idealmente, fanno una cosa sola e la fanno bene (7). Le applicazioni sono combinate attraverso API (dall’inglese Application Programming Interfaces) appositamente progettate per facilitare integrazioni personalizzate in diversi ambienti applicativi. La maggior parte delle API sono progettate per sfruttare i popolari strumenti API open source che riducono significativamente i costi di sviluppo associati a tali integrazioni personalizzate.

Queste applicazioni hanno talvolta costi di integrazione più elevati rispetto ai moduli ERP integrati. Tuttavia, presentano notevoli vantaggi a lungo termine, in quanto riducono notevolmente il rischio di ulteriori evoluzioni del panorama applicativo. L'azienda ha la possibilità di aggiornare o sostituire un’applicazione alla volta, il che si dimostra non solo molto più facile da eseguire, ma anche più economico e con meno rischi. Infine, le app SaaS (dall’inglese Software as a Service) optano in genere per la realizzazione costante di piccole modifiche. Mentre questo modello genera un carico di lavoro continuo, ma limitato, per i team IT, il processo di cambiamento SaaS è più organico, più economico e meno rischioso rispetto agli aggiornamenti annuali o biennali.

Oltre i database relazionali

I database relazionali sono stati la spina dorsale dei sistemi ERP fin dagli anni '80. Tuttavia, a partire dal 2010, sono emerse delle valide alternative. La più importante è probabilmente l'Event Sourcing (ES) insieme al Command Query Responsibility Segregation (CQRS). Questo approccio offre scalabilità e latenze superiori, consentendo al tempo stesso di ottenere un design più espressivo, cioè in grado di catturare in modo più efficace gli intenti aziendali in varie situazioni.

L’idea dell'event sourcing è quella di trattare ogni cambiamento del sistema come un evento immutabile. La prospettiva dell'immutabilità si ispira alle pratiche contabili: quando una riga si rivela errata in un libro contabile, il contabile non cancella la riga per risolvere il problema, ma aggiunge un'altra riga correttiva. Mantenere l'intero storico degli eventi (supponendo che l'archiviazione dei dati sia abbastanza economica da rendere questa strategia praticabile) produce numerosi vantaggi: migliore tracciabilità, verificabilità, sicurezza... Inoltre, la prospetriva immutabile rende i sistemi basati su eventi più facili da scalare. I dati possono essere ampiamente copiati e replicati senza dover affrontare eventuali modifiche dei dati.

Il CQRS design riconosce che, nella maggior parte dei sistemi, i rispettivi volumi di lettura e scrittura sono altamente sbilanciati. In molte situazioni, il volume delle letture (dati) supera il volume delle scritture di diversi ordini di grandezza. Tuttavia, i database relazionali sono orientate verso volumi di lettura e scrittura (relativamente) simmetrici. Il CQRS separa esplicitamente le responsabilità di lettura e scrittura, in genere in due sottosistemi distinti. Questo design produce anche benefici, soprattutto in termini di latenza, scalabilità ed efficienza hardware.

Tuttavia, mentre sia l'ES che il CQRS sono già popolari nelle grandi aziende tecnologiche orientate al consumo e nel commercio quantitativo (finanza), solo molto recentemente hanno iniziato a guadagnare terreno nel campo dei software aziendali. Di conseguenza, gli strumenti ES+CQRS sono ancora ai primi passi rispetto ai loro omologhi nell'ambiente dei database relazional. Ciononostante, questo approccio offre la possibilità non solo di ridurre drasticamente i costi in termini di materiale informatico, ma anche di comprimere le latenze che spesso costituiscono un serio problema per la maggior parte delle implementazioni di sistemi 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 - non dovrebbe sorprendere che il loro track record sia triste quando si tratta di analisi predittiva. A titolo di prova, nessuna delle rivoluzioni di machine learning / data science è avvenuta nei sistemi ERP, e quando si affrontano questi tipi di requisiti, i team fanno sistematicamente ricorso a su fogli di calcolo o script ad hoc.

Lokad stesso è emerso come un'applicazione specializzata destinata a integrare - e non a sostituire – i sistemi ERP come strato analitico dedicato all'ottimizzazione predittiva delle supply chain. La maggior parte delle nostre funzionalità principali, come le capacità di previsione probabilistica, sono progettate per supportare le decisioni di routine, come l'inventario, gli acquisti, la produzione, l'assortimento, il prezzo, che non sarebbe possibile implementare nei sistemi ERP.

Note

(1) Questa visione è piuttosto semplicistica. In pratica, negli ultimi decenni, l'ingegneria del software ha fatto un enorme balzo in avanti insieme alle risorse informatiche di base. Di conseguenza, una funzionalità che sarebbe stata eccessivamente costosa da sviluppare negli anni '80 potrebbe essere diventata molto più economica un decennio più tardi. I fornitori di ERP stanno ridefinendo le priorità dei loro sforzi di sviluppo tenendo presente questo fenomeno.

(2) Storicamente, i primi sistemi ERP degli anni '70, o meglio, i pezzi di software in stile ERP (come il sistema ERP sarebbe poi emerso) si basavano su rudimentali database di flat-files. I database relazionali sono emersi come un'alternativa superiore a questi database di flat-files. Ecco perché i primi fornitori di sistemi ERP hanno aggiornato il loro progetto utilizzando database relazionali. Tuttavia, quando si tratta dell'elaborazione di dati di intere banche dati in batch, le banche dati di flat-files sono rimaste superiori nella pratica - in concomitanza con l'investimento in hardware per computer - fino a quando la forma a colonne delle banche dati relazionali è diventata popolare nel 2010.

(3) Come molti fornitori di ERP hanno tentato di costruire e fornire funzionalità di previsione, anche i fornitori di database, a loro volta, hanno tentato di costruire e fornire funzionalità di previsione nei loro sistemi. Per quanto ne sappiamo, le capacità di "previsione" native dei database sono diffuse e largamente inutilizzate (o pesantemente compensate manualmente con fogli di calcolo Excel), presenrvate solo per consentire la contatibilità a ritroso dei fornitori.

(4) L'elaborazione in tempo reale è una nozione relativamente soggettiva. Tecnicamente, la velocità della luce stessa pone dei limiti rigidi limiti alle latenze ottenibili con sistemi distribuiti. Lo scopo di avere un ERP è quello di coordinare fornitori, impianti, magazzini, ... che sono geograficamente dispersi.

(5) Il punto di forza dell'avere una strategia tariffaria per modulo è che l'aggiunta di un nuovo modulo è un'esperienza (quasi) plug-and-play per l'azienda cliente. Tuttavia, il prezzo da pagare, dal punto di vista del design, per questa facilità di adozione è una pesante combinazione tra i moduli, cioè un design monolitico. Toccare un modulo qualsiasi ha un impatto su molti altri moduli.

(6) I sistemi informatici distribuiti sono in circolazione da decenni. Tuttavia, fino a quando il cloud computing non è diventato mainstream intorno al 2010, quasi tutti i software aziendali sono stati costruiti intorno a un'architettura client-server, che centralizza tutti i processi e i dati su di una manciata di macchine, generalmente un front-end, un back-end e un database. Al contrario, il cloud computing comporta un parco macchine, sia per l'affidabilità che per le prestazioni.

(7) Questa era in origine la filosofia di design Unix. Dal 2010, le applicazioni aziendali specializzate non sono generalmente così limitate e focalizzate come gli strumenti Unix. Tuttavia, queste applicazioni sono già due volte più complesse (o più) dei sistemi ERP. Inoltre, questo approccio non deve essere confuso con i microservizi, un modo per ingegnerizzare internamente le applicazioni stesse.