00:00:07 Importanza dei sistemi ERP.
00:02:42 ERP: Spiegazione del nome fuorviante.
00:03:54 Implementazione iniziale del sistema ERP.
00:05:07 Capacità fondamentali dei primi sistemi ERP.
00:07:34 Sistemi ERP: entità, interfacce, logica.
00:09:14 Il ruolo dell’ERP nell’automazione aziendale.
00:09:54 Evoluzione degli ERP e strategie.
00:11:32 Linguaggi specifici di dominio negli ERP.
00:12:07 Struttura modulare dei sistemi ERP.
00:14:22 Ruolo degli integratori negli ERP.
00:16:00 Integratori che promuovono soluzioni ERP personalizzate.
00:17:01 Rilevanza dei vincoli tradizionali degli ERP.
00:19:01 Sfidare l’esigenza di un unico sistema ERP.
00:20:01 Difficoltà negli aggiornamenti degli ERP.
00:21:35 Il ruolo dell’operatore ERP e le complicazioni.
00:22:53 Rischi/benefici dei fornitori ERP specializzati.
00:25:00 Sistemi ERP: complessità e sfide.
00:26:52 Piccole aziende e applicazioni SaaS.
00:28:42 Prodotti ERP complessi per aziende di medie dimensioni.
00:30:16 Grandi aziende che evitano ERP monolitici.
00:31:46 Strategie delle aziende leader.
00:33:39 Considerazioni finali.
Sommario
In un’intervista con Kieran Chandler, il fondatore di Lokad, Joannes Vermorel, discute l’evoluzione dei sistemi Enterprise Resource Planning (ERP). Ripercorrendo la loro nascita negli anni ‘70, Vermorel evidenzia due innovazioni chiave—l’avvento dei database relazionali e dei lettori di codici a barre—come fondamentali per lo sviluppo degli ERP. Egli suggerisce che “Enterprise Resource Management” sia un termine più accurato per questi sistemi, che sono passati da soluzioni aziendali personalizzate a rappresentazioni preconfezionate di modelli di business. Le funzionalità moderne degli ERP, come le interfacce CRUD e la logica di workflow, hanno automatizzato le attività di routine, migliorando la produttività. Vermorel esplora le strategie dei fornitori ERP di successo, come SAP, per gestire la complessità dei sistemi, e discute anche la selezione e l’implementazione degli ERP per aziende di varie dimensioni.
Sommario Esteso
Nell’intervista, il conduttore Kieran Chandler parla con Joannes Vermorel, il fondatore di Lokad, per discutere l’evoluzione e il funzionamento dei sistemi Enterprise Resource Planning (ERP).
Vermorel delinea le origini dei sistemi ERP, individuandone l’emergere negli anni ‘70, nonostante il termine “ERP” sia stato coniato solo negli anni ‘90. Secondo Vermorel, due innovazioni chiave hanno portato allo sviluppo dei sistemi ERP. La prima è stata il progresso dell’hardware informatico fino al punto in cui i database relazionali sono diventati possibili. Questi database, sebbene rudimentali nelle loro fasi iniziali, offrivano un modo versatile per organizzare i dati. Il formato relazionale, composto da tabelle e colonne, era adatto per modellare varie attività aziendali, incluse transazioni, pagamenti e interazioni con clienti e fornitori.
La seconda innovazione cruciale menzionata da Vermorel è l’invenzione dei lettori di codici a barre. Sebbene i lettori di codici a barre siano apparsi negli anni ‘50, non è stato fino al progresso dell’hardware informatico negli anni ‘70 che essi potevano memorizzare e processare quantità significative di dati. La combinazione di queste due tecnologie ha dato origine ai sistemi ERP che conosciamo oggi.
Vermorel affronta anche il problema del nome fuorviante degli ERP, affermando che si trattava di un espediente di marketing iniziato negli anni ‘90. Spiega che gli ERP hanno ben poco a che fare con la pianificazione, concentrandosi invece sulla gestione—rendendo “Enterprise Resource Management” un nome più appropriato. Illustra questo fatto descrivendo come, nelle fasi iniziali, molte aziende iniziarono a sviluppare i propri sistemi software per gestire le risorse, utilizzando i database e i dispositivi di inserimento dati allora disponibili.
Osservando le somiglianze in ciò che le aziende necessitavano di rappresentare—come pagamenti, scorte e dipendenti—alcune aziende hanno iniziato a offrire versioni preconfezionate di queste rappresentazioni di modelli di business. Vermorel indica che questa fu l’origine di ciò che oggi definiamo sistemi ERP, anche se suggerisce che dovremmo considerarli come sistemi di Enterprise Resource Management, data la loro reale funzionalità.
Le interfacce utente, tipicamente categorizzate come interfacce CRUD (Create, Read, Update, Delete), operano su queste entità. Esse consentono compiti basilari di inserimento dati, come aggiungere un nuovo prodotto (creare), visualizzare gli attributi di un prodotto esistente (leggere), modificare un prodotto esistente (aggiornare) e cancellare un prodotto (eliminare). Questo schema CRUD si applica a ogni entità all’interno del sistema ERP.
La logica di workflow, il terzo componente, è dove entra in gioco l’automazione. Vermorel fornisce l’esempio di un processo di acquisto, che inizia con un ordine di acquisto, seguito dal ricevimento di una fattura dal fornitore, e poi dalla spedizione delle merci da parte del fornitore. Il sistema ERP tiene traccia di questi passaggi ed, se le merci non vengono ricevute, avverte l’utente. Se le quantità ricevute non corrispondono a quelle ordinate, il sistema ERP suggerisce i passaggi successivi, come contattare il fornitore per inviare il resto o restituire le merci. Questa automazione delle attività di routine porta a un significativo miglioramento della produttività.
Passando all’evoluzione degli ERP, Vermorel sottolinea il ruolo dei fornitori nel plasmare questi sistemi. Egli osserva che la sfida principale per i fornitori è gestire la complessità, poiché devono implementare un flusso inesauribile di entità, interfacce utente e logica. Si riferisce a una strategia “triplice” che i fornitori ERP di successo utilizzano per gestire questa complessità e mantenere la competitività.
In primo luogo, i fornitori adottano tecnologie specifiche per semplificare la produzione di entità, interfacce utente e logica. Vermorel cita l’esempio di SAP, un fornitore ERP di successo, che ha inventato il proprio linguaggio di programmazione specifico per il dominio, ABAP, per accelerare il processo di implementazione.
In secondo luogo, i fornitori adeguano la struttura delle loro offerte e dei loro prezzi per rispecchiare il costo e lo sforzo di produrre e supportare la vasta gamma di entità. Questo porta spesso a una struttura di prezzi basata su moduli, in cui le entità sono raggruppate in moduli che hanno senso dal punto di vista aziendale, e i clienti vengono addebitati in base ai moduli che utilizzano.
I sistemi ERP, che sono diventati una parte dominante del mondo del software aziendale, sono in costante evoluzione e si adattano per soddisfare le esigenze delle aziende e delle loro operazioni complesse.
Vermorel inizia discutendo gli incentivi e il modello di business dei fornitori ERP. Spiega che questi fornitori sono incentivati a sviluppare continuamente nuovi moduli o funzionalità da vendere ai loro clienti. I fornitori spesso vedono ogni implementazione riuscita come un’opportunità per creare e vendere un modulo aggiuntivo al cliente. Ciò genera un ciclo perpetuo di vendite e sviluppo.
La conversazione poi si sposta sulla scelta tra i diversi approcci ERP. Vermorel suggerisce che le aziende dovrebbero chiedersi se i vincoli incorporati negli ERP dalla fine degli anni ‘70 siano ancora rilevanti per la loro situazione attuale. Mette in discussione la necessità di un sistema unico e integrato, sostenendo che questo approccio può portare a una complessità aumentata e a una moltitudine di casi limite. Invece, suggerisce alle aziende di riconsiderare l’assunzione che un unico sistema possa fare tutto, mettendo in guardia contro l’avere troppi sistemi distinti.
Discutendo l’implementazione di nuovi sistemi ERP, Vermorel affronta i rischi significativi e i costi associati al passaggio a un nuovo sistema o all’aggiornamento di uno esistente. Utilizza l’esempio di un’azienda che ha sprecato mezzo miliardo di euro per un aggiornamento SAP nel 2009, sottolineando che la semantica delle entità all’interno di un sistema ERP—in gran parte determinata dagli operatori del sistema—cambia spesso in modo sottile ma significativo tra le versioni, portando a numerosi casi limite e sfide.
Vermorel crede che i fornitori più piccoli comportino alcuni rischi, ma è meglio scegliere un prodotto che abbia un nucleo ristretto, che rifletta la complessità e la scala attuali dell’azienda. Consiglia di evitare funzionalità eccessive che possono interrompere i processi e raccomanda di selezionare un prodotto che possa essere integrato, se necessario.
La discussione tocca anche la scelta appropriata dell’ERP per le diverse dimensioni aziendali. Vermorel suggerisce che le aziende più piccole, con meno di 100 dipendenti, dovrebbero optare per applicazioni Software-as-a-Service (SaaS) strette, semplici ed economiche. Raccomanda di utilizzare due o tre app separate che coprano esigenze specifiche, piuttosto che fare affidamento su un ERP completo. Per le aziende di medie dimensioni, con circa 500 dipendenti, Vermorel suggerisce di considerare un prodotto ERP più complesso in grado di gestire una gamma più ampia di funzioni aziendali tipiche. Tuttavia, per le aziende più grandi, con migliaia di dipendenti, Vermorel sconsiglia un approccio ERP monolitico e propone invece una strategia “dividi et impera”. Suggerisce di suddividere il panorama in aree funzionali e di costruire o acquistare soluzioni su misura per ciascuna area, piuttosto che cercare di implementare un unico sistema ERP.
Trascrizione Completa
Kieran Chandler: Oggi scopriremo come è nata questa classe di software aziendali e come le aziende possono scegliere tra la moltitudine di opzioni disponibili. Quindi, Joannes, forse potremmo iniziare esaminando le origini dei sistemi ERP. Come sono nati?
Joannes Vermorel: I sistemi ERP hanno avuto origine da due forze trainanti negli anni ‘70. A proposito, il termine ERP è stato coniato negli anni ‘90, ma ciò che comunemente definiamo sistemi ERP è iniziato già negli anni ‘70. Ci sono state due innovazioni critiche. La prima sono stati i sistemi di database. L’hardware informatico ha raggiunto un punto tale da rendere possibile un database relazionale. Quella è stata la prima innovazione. La seconda innovazione sono stati i lettori di codici a barre. Quando si combinano queste due innovazioni, ci si rende conto che i database relazionali erano incredibilmente versatili e ben adatti a modellare la maggior parte delle attività aziendali, come pagamenti, clienti, fornitori e transazioni. È diventato chiaro che questo formato era adatto a essere il destinatario dei dati. I codici a barre sono stati inventati negli anni ‘50, ma fino a quando l’hardware informatico non progredì abbastanza da memorizzare e processare quantità notevoli di dati negli anni ‘70, non ebbero un impatto importante. Tuttavia, erano già vasti rispetto al processamento manuale.
Kieran Chandler: Bene, ci hai accennato. Il nome ERP non si è affermato fino a un po’ più tardi, negli anni ‘90. ERP sta per enterprise resource planning. Ma da dove deriva il nome? Perché hanno scelto questo termine?
Joannes Vermorel: In realtà, ERP è un termine fuorviante. Purtroppo, il suo nome era più che altro un espediente di marketing nato negli anni ‘90. I sistemi ERP in sostanza non hanno nulla a che fare con la pianificazione. Un nome migliore sarebbe stato enterprise resource management. Quello che è successo è che, non appena sono comparsi sia i database che i lettori di codici a barre, molte aziende hanno cominciato a rendersi conto di voler un sistema computerizzato per gestire tutte quelle risorse. Hanno iniziato a implementare i propri software sopra il database e i dispositivi di inserimento dati disponibili all’epoca. Alcune altre aziende hanno capito che molte imprese hanno necessità simili in termini di rappresentazione. Ad esempio, ogni azienda deve rappresentare pagamenti, scorte per chi si occupa di materiali fisici e la busta paga dei dipendenti. Così, alcune società di software hanno pensato, “Offriamo versioni preconfezionate di questi modelli di business,” ed è da qui che è nato il concetto di ERP. Al giorno d’oggi, è meglio pensarlo come ERP, non enterprise resource planning, ma piuttosto enterprise resource management.
Kieran Chandler: Quindi, quali erano le capacità fondamentali dei primi sistemi ERP?
Joannes Vermorel: Un ERP si compone fondamentalmente di tre elementi: entità, interfacce utente e logica di workflow. Le entità sono astrazioni basate sulle tabelle. Ad esempio, se vuoi rappresentare i prodotti, avresti una tabella chiamata “products,” ma potresti avere più tabelle per differenti attributi o fornitori. Le entità rappresentano concetti di alto livello come prodotti, clienti o transazioni, anziché i dettagli di implementazione a basso livello di come vengono memorizzati in un database.
Le interfacce utente sono progettate specificamente per operazioni CRUD: create, read, update e delete. La maggior parte delle volte, quando si lavora con le entità, si utilizzano semplicemente le interfacce CRUD. Si inseriscono nuovi prodotti, si verificano i dettagli dei prodotti esistenti, si modificano i prodotti o si eliminano. Questo vale per ogni entità, come transazioni, clienti e altro ancora.
Il terzo elemento è la logica di workflow. Prendiamo l’esempio dell’acquisto. Prima, emetti un ordine di acquisto, poi il fornitore conferma con una fattura. Ricevi le merci e devi tracciarle nel sistema. La logica di workflow assicura che vengano fornite notifiche qualora qualcosa manchi e verifica che le quantità corrispondano all’ordine. In base a ciò, puoi decidere di restituire le merci al fornitore o richiedere gli articoli rimanenti. L’ERP automatizza queste attività quotidiane e migliora la produttività gestendo le conseguenze delle operazioni aziendali di base.
Kieran Chandler: Nel mondo del software, quanto sono cambiati rispetto a quei primi pezzi di software? Ciò che è molto interessante è che, per comprendere questo cambiamento, devi capire le dinamiche che guidano il mercato ERP. Gli ERP, in particolare i fornitori ERP, svolgono un ruolo significativo nell’implementazione di questi sistemi, piuttosto che le aziende che li implementano da sole. Esploriamo questo aspetto. La maggior parte dei fornitori ha adottato una strategia triplice, che io chiamo Allah. Questa strategia ha avuto successo nel conquistare il mercato. Al giorno d’oggi, la maggior parte dei fornitori ERP di successo applica queste tre tecniche.
Joannes Vermorel: La sfida principale che devono affrontare i fornitori di ERP è la complessità. Per far fronte a questa sfida, è necessario implementare flussi infiniti di entità e fornire interfacce utente e flussi di lavoro che abbiano senso. Il primo modo per essere più competitivi è disporre di tecnologie specifiche che semplificano la produzione di entità, interfacce utente e logica. Un esempio di tale tecnologia è un linguaggio di programmazione specifico per un dominio. Ad esempio, il fornitore di ERP di successo, CP, ha inventato il proprio linguaggio di programmazione specifico per un dominio chiamato ab app, che lo ha aiutato a distribuire entità, interfacce utente e logica più velocemente rispetto alla concorrenza.
Kieran Chandler: Interessante. Quindi, il secondo percorso consiste nel modificare la struttura dell’offerta e dei prezzi. Puoi approfondire?
Joannes Vermorel: Certamente. Come fornitore, il costo per produrre un ERP è fortemente influenzato dall’impegno necessario per implementare tutti i differenti elementi. Sebbene i singoli pezzi possano essere semplici, gli ERP riguardano la gestione di compiti quotidiani, come la gestione delle ricevute. Poiché i fornitori devono produrre e supportare numerose entità, ha senso iniziare ad addebitare non per entità, ma per moduli. I moduli raggruppano entità correlate e si allineano alle considerazioni di business. Questo solleva un punto interessante su come i sistemi ERP addebitino per il loro software.
Kieran Chandler: Assolutamente. Quindi, c’è un costo aggiuntivo per l’aggiunta dei moduli. Abbiamo già discusso del vendor lock-in. Gli interessi economici dei fornitori di ERP sono in linea con questo modello di pricing basato sui moduli?
Joannes Vermorel: Infatti, non appena si introducono i moduli, si crea un modo efficiente per allineare il prezzo al costo di implementazione di tutte le funzionalità. Tuttavia, ciò genera anche incentivi specifici. I fornitori sono motivati a continuare a sviluppare nuovi moduli da vendere in aggiunta a quelli esistenti. Questo può portare a un ciclo infinito di vendita di ulteriori moduli ai clienti. Ma prima di approfondire i dettagli, passiamo alla terza idea.
Kieran Chandler: Va bene. Qual è la terza idea?
Joannes Vermorel: La terza idea è che i fornitori di ERP di successo, a causa dell’enorme complessità nel catturare tutti i dettagli minuti della realtà, trovano modi per crescere ancora più rapidamente attraverso gli integratori. Poiché una singola azienda non può gestire tutto, i fornitori di ERP collaborano con società esterne, note come integratori, per occuparsi dell’ultimo miglio, garantendo così una soluzione completa ed esaustiva.
Kieran Chandler: Quindi, Joannes, hai accennato in precedenza al fatto che Lokad sta introducendo una nuova funzionalità per i suoi clienti. Puoi dirci qualcosa in più al riguardo?
Joannes Vermorel: Sì, infatti. Stiamo lanciando una nuova funzionalità per i nostri clienti. Essa comprende nuove entità, una nuova interfaccia utente e una nuova logica. Stiamo creando una rete di partner chiamati integratori per implementare questa funzionalità. Dal punto di vista del modello di business, è interessante per le aziende fornitrici di ERP perché possono trasferire il costo e il rischio associati a questa funzionalità. Esiste una lunga coda di funzionalità che possono essere esternalizzate a società terze.
Kieran Chandler: Quindi, i fornitori di software trasferiscono il rischio agli integratori e, in ultima analisi, ai loro clienti. Gli integratori hanno incentivi propri, che potrebbero non allinearsi completamente con quelli del fornitore di software. È corretto?
Joannes Vermorel: Esattamente. Gli integratori hanno l’incentivo di offrire ai clienti un alto livello di personalizzazione perché vengono pagati di più per moduli su misura piuttosto che per moduli predefiniti. Possono convincere i clienti sostenendo che la loro attività è unica e richiede una soluzione che ne rifletta l’unicità. È una dinamica interessante.
Kieran Chandler: Capisco. Quindi, esistono diversi approcci che le aziende possono adottare per quanto riguarda i sistemi ERP. Come si determina quale sia un buon approccio e quale un cattivo?
Joannes Vermorel: Al giorno d’oggi, quando si considerano le scelte ERP, bisogna interrogarsi se tutti i vincoli incorporati negli ERP della fine degli anni ‘70 siano ancora rilevanti per la propria situazione. Ciò dipende da vari fattori. Ad esempio, l’idea che sia necessario integrare tutto in un unico sistema è spesso insensata, poiché la complessità non cresce in maniera lineare. Aggiungere ulteriori entità al sistema porta a più casi limite e variazioni in ciò che le differenti industrie considerano come un “prodotto”.
Kieran Chandler: Quindi, stai dicendo che dobbiamo riconsiderare l’ipotesi secondo cui abbiamo ancora bisogno di un unico sistema per gestire tutto?
Joannes Vermorel: Esattamente. Quell’ipotesi non è più valida. Avere 100 sistemi distinti che richiedono coordinamento è una sfida, ma avere un unico sistema master che li governi tutti è altrettanto problematico. Quando desideri apportare modifiche a un sistema del genere, si trasforma in un progetto enorme che coinvolge ogni funzione dell’azienda.
Kieran Chandler: Capisco. Sembra che la transizione verso un nuovo sistema possa essere piuttosto difficile. Alcune aziende hanno sperimentato fallimenti costosi nel tentativo di passare a nuovi sistemi ERP. Quanto è pratico effettuare quella transizione?
Joannes Vermorel: Infatti, passare a un nuovo sistema ERP può essere davvero impegnativo. Abbiamo visto aziende sprecare miliardi di dollari nel tentativo di tali transizioni. In pratica, non è un compito facile.
Kieran Chandler: Nel 2009, hanno sprecato mezzo miliardo di euro in un aggiornamento ASAP. Non si trattava nemmeno di una distribuzione, solo di un aggiornamento. Quindi, la domanda è: è più difficile aggiornare un ERP che passare a uno nuovo?
Joannes Vermorel: È una domanda molto interessante. Sorprendentemente, aggiornare un ERP è tipicamente più difficile che migrare verso uno nuovo. Può sembrare controintuitivo, ma è quanto ho osservato. Quando migri a un nuovo ERP, non hai l’illusione che sarà un’impresa gigantesca. Tuttavia, se lo consideri semplicemente come un aggiornamento, può sembrare semplice, ma in realtà può essere molto, molto difficile.
Il problema è che, passando da una versione all’altra, si verifica uno spostamento semantico nelle entità. Vedi, gli ERP sono focalizzati sulla rappresentazione di entità che riflettono varie esigenze della tua azienda, come ad esempio i prodotti. Potresti pensare che la semantica di queste entità in un ERP sia definita dal fornitore, ma non è del tutto così. La semantica finale di ogni entità risiede nell’occhio dell’operatore, la persona che interagisce con il sistema ed effettua l’inserimento dei dati e il flusso di lavoro.
Quindi, la vera semantica di un’entità è determinata dalla persona che gestisce l’ERP. Purtroppo, per i fornitori di ERP, il controllo su ciò che le persone effettivamente fanno con il prodotto è limitato. Possono fornire raccomandazioni e programmi di formazione, ma, in definitiva, è una sfida. Alcune aziende possono decidere di adottare una semantica leggermente diversa per far funzionare l’ERP nella loro situazione specifica. Non è perché sono ribelli; è semplicemente ciò che serve per far funzionare l’ERP.
Tuttavia, il problema sorge quando si passa alla versione successiva. Possono emergere numerosi casi limite sottili in cui l’entità improvvisamente non significa più esattamente la stessa cosa a causa di nuovi sviluppi e di una miriade di situazioni limite.
Kieran Chandler: È interessante. Quindi, da un lato, ci sono questi grandi approcci monolitici, e dall’altro, aziende ERP più piccole e specializzate. Quanta fiducia si può riporre in queste piccole aziende che potrebbero non sopravvivere nel prossimo decennio?
Joannes Vermorel: Se sei una piccola azienda, vuoi un sistema in cui la complessità abbia senso in relazione alla tua scala. I prodotti ERP tendono a diventare più complessi col tempo. Quindi, se sei una giovane azienda, magari con soli cinque anni, e stai crescendo rapidamente, sarebbe sbagliato insistere su un ERP che ha tre o quattro decenni. Questi prodotti più vecchi possono essere incredibilmente complessi, con centinaia o addirittura migliaia di tabelle ed entità. Gestire una tale complessità può essere opprimente.
Quindi, il mio consiglio è di considerare aziende ERP più giovani, anche se comportano un certo livello di rischio. Attenzione a non sommergerti sotto una pila di complessità. Dalla mia esperienza alla guida di Lokad per oltre un decennio, non ho mai visto un’azienda affrontare una situazione drammatica esclusivamente a causa della scelta del loro ERP. Tuttavia, lanciare un prodotto molto più complesso rispetto alla propria scala può rivelarsi dannoso e persino mettere a repentaglio il business. L’ho visto accadere spesso, quando le aziende faticano perché hanno adottato un software che risultava semplicemente troppo complesso e con troppe funzionalità.
Kieran Chandler: Sembra che, quando si tratta di scegliere un software, avere un nucleo solido e app interconnesse sia fondamentale per un’azienda in crescita. Joannes, puoi approfondire questa idea?
Joannes Vermorel: Assolutamente. L’essenza controintuitiva è che è meglio avere qualcosa con un nucleo ristretto che rispecchi la tua complessità e scala attuali, anche se mancano ancora alcune funzionalità. Puoi sempre integrare le parti mancanti tramite l’integrazione. D’altra parte, avere troppe funzionalità in conflitto può causare problemi. Le funzionalità inutilizzate tendono a creare scompiglio nei processi e a impedire l’esecuzione di compiti semplici. I prodotti software completamente integrati rendono difficile rimuovere o modificare determinate funzionalità senza compromettere l’intero sistema.
Kieran Chandler: Quindi, scegliere un prodotto più piccolo non elimina del tutto questi problemi?
Joannes Vermorel: No, la portata e l’importanza di questi problemi dipendono dalla complessità e dal numero di entità presenti nel software. Tuttavia, anche la dimensione dell’azienda gioca un ruolo. Per le aziende più piccole, con meno di 100 persone, è consigliabile trovare una soluzione ristretta, semplice ed economica, come un’app SaaS. Potresti aver bisogno di due o tre di queste app per coprire diverse aree, come risorse umane, paghe, e inventory management. Non è necessario avere un unico ERP che comprenda tutto. Basta assicurarsi che queste app abbiano API per estrarre i dati, così da poterle integrare successivamente se necessario.
Kieran Chandler: Ha senso. E per le aziende di medie dimensioni?
Joannes Vermorel: Per le aziende di medie dimensioni, con circa 500 dipendenti, si potrebbe considerare un prodotto ERP più completo. Sarà più complicato, con numerose tabelle e funzionalità. A questo punto, ci sono vari aspetti tipici dell’azienda da gestire, e un ERP può coprire tali esigenze. Potrebbe richiedere un progetto di implementazione più lungo e un buon integratore, ma può offrire le funzionalità desiderate.
Kieran Chandler: Questo è più produttivo rispetto alle piccole app che stanno iniziando a mostrare i loro limiti. Poi, se sei una grande azienda, direi che la situazione cambia nuovamente. Se sei più grande, diciamo un’azienda con 5.000 dipendenti… Sai, una grande azienda. Allora, tipicamente, direi che ci sono due aspetti che entrano in gioco. Innanzitutto, bisogna suddividere il tutto in parti più piccole. Il monolite semplicemente non funzionerà per te se sei grande. Se opti per un ERP monolitico, come fanno la maggior parte delle grandi aziende… Direi che, in generale, sarà sgradevole. Ci vorranno anni ed è destinato a essere incredibilmente costoso.
Joannes Vermorel: Se osservi cosa fanno le migliori grandi aziende, esse adottano solitamente soluzioni piuttosto su misura. E hanno ottime ragioni per farlo. Se sei una grande azienda, probabilmente possiedi un vantaggio competitivo unico che non è una cosa semplice. È radicato nella tua organizzazione, che è grande, complessa, e magari hai effettuato acquisizioni. Quindi, potresti avere, per così dire, un panorama caratterizzato da geni eccentrici fin dall’inizio. Quindi, invece di dire “Voglio un ERP unico per governarli tutti”, che funzionava quando avevi tipo 500 dipendenti, diventa molto difficile quando ne hai, diciamo, 5.000. Il mio suggerimento è di dividere e conquistare. Questo approccio, che suggerivo quando eri molto piccolo e avevi un paio di app, può essere rivisitato in maniera completamente diversa se sei una grande azienda.
Quindi, per dire, dividerò il panorama in, non so, forse fino a una dozzina di aree funzionali. E poi costruirò o acquisterò per ciascuna area, a seconda che i fornitori che trovo siano validi o meno. E la sfida più grande, ciò che raccomanderei alle aziende più grandi, è rompere il dogma secondo cui serve avere un unico ERP per governarli tutti. Credo che ciò sia per lo più… Voglio dire, per lo più assurdo. E se osservi i player super competitivi, diciamo Amazon, Alibaba, Rakuten, Zalando, quei player tecnologici che devono gestire la physical supply chain, noterai che adottano un approccio di divide et impera nel loro panorama applicativo, optando in maniera aggressiva per un modello build o buy. In sostanza, nessuna di quelle aziende possiede davvero un ERP. Hanno elenchi di prodotti. Alcuni di essi sarebbero più vicini a un ERP, e la maggior parte di queste aziende ha scritto anche i propri sistemi per parti specifiche di ciò che normalmente viene definito come un modulo ERP.
Kieran Chandler: Bene, dobbiamo concludere qui, ma grazie mille per il tuo tempo questa mattina.
Joannes Vermorel: Grazie a te, Kieran.
Kieran Chandler: Questo è tutto per questa settimana. Ciao e a presto.
