00:00:07 Importanza dei sistemi ERP.
00:02:42 Spiegazione del termine “ERP: Misnomer”.
00:03:54 Implementazione iniziale del sistema ERP.
00:05:07 Capacità principali dei primi sistemi ERP.
00:07:34 Sistemi ERP: entità, interfacce, logica.
00:09:14 Ruolo degli ERP nell’automazione aziendale.
00:09:54 Evoluzione degli ERP e strategie.
00:11:32 Linguaggi specifici del dominio negli ERP.
00:12:07 Struttura modulare dei sistemi ERP.
00:14:22 Ruolo degli integratori negli ERP.
00:16:00 Gli integratori promuovono soluzioni ERP personalizzate.
00:17:01 Rilevanza dei vincoli tradizionali degli ERP.
00:19:01 Sfida della necessità di un singolo sistema ERP.
00:20:01 Difficoltà nell’aggiornamento degli ERP.
00:21:35 Ruolo e complicazioni dell’operatore ERP.
00:22:53 Rischi/vantaggi dei fornitori di ERP specializzati.
00:25:00 Complessità e sfide dei sistemi ERP.
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 gli ERP monolitici.
00:31:46 Strategie delle principali aziende.
00:33:39 Considerazioni finali.
Riassunto
In un’intervista con Kieran Chandler, il fondatore di Lokad, Joannes Vermorel, discute dell’evoluzione dei sistemi Enterprise Resource Planning (ERP). Risalendo alla loro nascita negli anni ‘70, Vermorel evidenzia due innovazioni chiave - l’avvento dei database relazionali e dei lettori di codici a barre - come cruciali per lo sviluppo degli ERP. 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 moderne funzionalità degli ERP, come le interfacce CRUD e la logica dei flussi di lavoro, hanno automatizzato le attività di routine, migliorando la produttività. Vermorel esplora le strategie dei fornitori di ERP di successo, come SAP, per gestire la complessità del sistema, e discute anche della selezione e implementazione degli ERP per aziende di diverse dimensioni.
Riassunto Esteso
Nell’intervista, l’ospite Kieran Chandler parla con Joannes Vermorel, il fondatore di Lokad, per discutere dell’evoluzione e delle funzionalità dei sistemi di Enterprise Resource Planning (ERP).
Vermorel illustra le origini dei sistemi ERP, individuando la loro comparsa 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 la progressione dell’hardware di calcolo fino al punto in cui erano possibili i database relazionali. Questi database, sebbene rudimentali nelle prime fasi, offrivano un modo versatile per organizzare i dati. Il formato relazionale, composto da tabelle e colonne, era adatto per modellare varie attività aziendali, tra cui transazioni, pagamenti e interazioni con clienti e fornitori.
La seconda innovazione critica menzionata da Vermorel è l’invenzione dei lettori di codici a barre. Sebbene i lettori di codici a barre siano comparsi negli anni ‘50, è stato solo con l’avanzamento dell’hardware di calcolo negli anni ‘70 che è stato possibile memorizzare ed elaborare quantità considerevoli di dati. La combinazione di queste due tecnologie ha dato origine ai sistemi ERP che conosciamo oggi.
Vermorel affronta anche l’errore di denominazione degli ERP, affermando che si trattava di un trucco di marketing iniziato negli anni ‘90. Spiega che gli ERP hanno poco a che fare con la pianificazione, ma sono invece focalizzati sulla gestione, rendendo “Enterprise Resource Management” un nome più appropriato. Illustra ciò descrivendo come, nelle prime fasi, molte aziende hanno iniziato a sviluppare i propri sistemi software per gestire le risorse utilizzando database e dispositivi di inserimento dati disponibili all’epoca.
Osservando le somiglianze in ciò che le aziende dovevano rappresentare, come pagamenti, scorte e dipendenti, alcune aziende hanno iniziato a offrire versioni preconfezionate di queste rappresentazioni del modello aziendale. Vermorel indica che questa è stata l’origine di ciò che ora chiamiamo sistemi ERP, anche se suggerisce di pensarli come sistemi di Enterprise Resource Management, data la loro effettiva funzionalità.
Le interfacce utente, generalmente categorizzate come interfacce CRUD (Create, Read, Update, Delete), operano su queste entità. Consentono operazioni di base di inserimento dati, come l’aggiunta di un nuovo prodotto (crea), la visualizzazione degli attributi di un prodotto esistente (leggi), la modifica di un prodotto esistente (aggiorna) e l’eliminazione di un prodotto (elimina). Questo modello CRUD si applica a ogni entità all’interno del sistema ERP.
La logica del flusso di lavoro, il terzo componente, è dove entra in gioco l’automazione. Vermorel dà l’esempio di un processo di acquisto, che inizia con un ordine di acquisto, quindi riceve una fattura dal fornitore, seguita dalla spedizione delle merci da parte del fornitore. Il sistema ERP tiene traccia di questi passaggi e, se le merci non vengono ricevute, avvisa l’utente. Se le quantità ricevute non corrispondono alle quantità 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 nella definizione di questi sistemi. Sottolinea che la sfida principale per i fornitori è gestire la complessità, poiché devono implementare un flusso infinito di entità, interfacce utente e logica. Fa riferimento a una strategia “a tre vie” che i fornitori di ERP di successo utilizzano per gestire questa complessità e mantenere la competitività.
In primo luogo, i fornitori adottano tecnologie specifiche per razionalizzare la produzione di entità, interfacce utente e logica. Vermorel cita l’esempio di SAP, un fornitore di ERP di successo, che ha inventato il proprio linguaggio di programmazione specifico del dominio, ABAP, per accelerare il processo di implementazione.
In secondo luogo, i fornitori adeguano la struttura delle loro offerte e la tariffazione per riflettere il costo e lo sforzo di produrre e supportare la vasta gamma di entità. Questo porta spesso a una struttura di tariffazione 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 utilizzati.
I sistemi ERP, che sono diventati una parte dominante del mondo del software aziendale, sono in continua evoluzione e si adattano per soddisfare le esigenze delle aziende e delle loro complesse operazioni.
Vermorel inizia discutendo gli incentivi e il modello di business dei fornitori di 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 di successo come un’opportunità per creare e vendere un modulo aggiuntivo al cliente. Questo crea un ciclo perpetuo di vendite e sviluppo.
La conversazione poi si sposta sulla scelta tra diversi approcci ERP. Vermorel suggerisce che le aziende dovrebbero chiedersi se i vincoli incorporati negli ERP degli anni ‘70 siano ancora rilevanti per la loro situazione attuale. Mette in discussione la necessità di un sistema singolo e integrato, sostenendo che questo approccio può portare a un aumento della complessità e a una moltitudine di casi limite. Invece, suggerisce alle aziende di riconsiderare l’assunzione che un unico sistema debba fare tutto, avvertendo anche contro l’utilizzo di troppi sistemi distinti.
Nel discutere dell’implementazione di nuovi sistemi ERP, Vermorel affronta i significativi rischi e 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 - spesso cambia in modo sottile ma significativo tra le versioni, portando a numerosi casi limite e sfide.
Vermorel ritiene 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. Sconsiglia l’utilizzo di funzionalità eccessive che possono interrompere i processi e consiglia di selezionare un prodotto che possa essere integrato se necessario.
La discussione tocca anche la scelta appropriata di un ERP per diverse dimensioni aziendali. Vermorel suggerisce che le piccole aziende 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 anziché fare affidamento su un ERP completo. Per le aziende di medie dimensioni con circa 500 dipendenti, Vermorel suggerisce di considerare un prodotto ERP di medie dimensioni più complesso che possa gestire una gamma più ampia di funzioni aziendali tipiche. Tuttavia, per le grandi aziende con migliaia di dipendenti, Vermorel sconsiglia un approccio ERP monolitico e propone invece una strategia di divide et impera. Suggerisce di suddividere il panorama in aree funzionali e di costruire o acquistare soluzioni adatte a ciascuna area, anziché cercare di implementare un singolo sistema ERP.
Trascrizione completa
Kieran Chandler: Oggi scopriremo come questa classe di software aziendale è nata e come le aziende possono scegliere tra la moltitudine di diverse opzioni. Allora, Joannes, forse potremmo iniziare guardando le origini dei sistemi ERP. Come sono nati?
Joannes Vermorel: I sistemi ERP sono nati da due forze trainanti negli anni ‘70. A proposito, il termine ERP è stato coniato negli anni ‘90, ma ciò a cui ci riferiamo comunemente come sistemi ERP è iniziato negli anni ‘70. Ci sono state due innovazioni fondamentali. Una erano i sistemi di database. L’hardware informatico è progredito fino a un punto in cui è diventato possibile un database relazionale. Questa è 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 adatti a modellare la maggior parte delle attività aziendali, come pagamenti, clienti, fornitori e transazioni. È diventato chiaro che questo formato era adatto per ricevere dati. I codici a barre sono stati inventati negli anni ‘50, ma fino a quando l’hardware di elaborazione non era progredito abbastanza da poter memorizzare e elaborare quantità considerevoli di dati negli anni ‘70, non aveva un impatto così significativo. Tuttavia, era già vasto rispetto all’elaborazione manuale.
Kieran Chandler: Ok, hai accennato a questo. Il nome ERP è arrivato un po’ più tardi negli anni ‘90. ERP sta per enterprise resource planning. Ma da dove è arrivato il nome? Perché hanno deciso di chiamarlo così?
Joannes Vermorel: In realtà, ERP è un nome improprio. Purtroppo, il suo nome era più una trovata di marketing che è arrivata negli anni ‘90. I sistemi ERP non hanno praticamente nulla a che fare con la pianificazione. Un nome migliore sarebbe stato enterprise resource management. Quello che è successo è che non appena sono state introdotte sia le basi di dati che i lettori di codici a barre, molte aziende hanno capito di voler avere un sistema computerizzato per gestire tutte quelle risorse. Hanno iniziato a implementare le proprie soluzioni software sopra il database e i dispositivi di inserimento dati disponibili all’epoca. Altre aziende si sono rese conto che molte imprese hanno esigenze simili per quanto riguarda la rappresentazione. Ad esempio, ogni azienda ha bisogno di rappresentare pagamenti, scorte per coloro che si occupano di materiali fisici e stipendi dei dipendenti. Quindi, alcune aziende software hanno pensato: “Abbiamo versioni preconfezionate di questi modelli di business”, ed è così che è nato il concetto di ERP. Oggi è meglio pensare ad esso come ERP, non come enterprise resource planning, ma come enterprise resource management.
Kieran Chandler: Quindi, quali erano le capacità principali dei primi sistemi ERP?
Joannes Vermorel: Un ERP consiste fondamentalmente in tre cose: entità, interfacce utente e logica di flusso di lavoro. Le entità sono le astrazioni sopra le tabelle. Ad esempio, se si vuole rappresentare i prodotti, si avrebbe una tabella chiamata “prodotti”, ma si possono avere più tabelle per attributi o fornitori diversi. Le entità rappresentano concetti di alto livello come prodotti, clienti o transazioni, rispetto ai dettagli di implementazione di basso livello su come sono memorizzati in un database.
Le interfacce utente sono specificamente progettate per le operazioni CRUD: creazione, lettura, aggiornamento ed eliminazione. La maggior parte delle volte, quando si lavora con le entità, si lavora semplicemente con interfacce CRUD. Si inseriscono nuovi prodotti, si controllano i dettagli dei prodotti esistenti, si modificano i prodotti o li si eliminano. Questo si applica a ogni entità, come transazioni, clienti e altro ancora.
Il terzo elemento è la logica di flusso di lavoro. Prendiamo ad esempio l’acquisto. Prima si emette un ordine di acquisto, poi il fornitore conferma con una fattura. Si ricevono le merci e bisogna tenerne traccia nel sistema. La logica di flusso di lavoro garantisce che ci siano avvisi se manca qualcosa e verifica che le quantità corrispondano all’ordine. In base a questo, si può decidere di restituire la merce al fornitore o richiedere gli articoli rimanenti. L’ERP automatizza queste attività noiose e migliora la produttività gestendo le conseguenze delle operazioni di base dell’azienda.
Kieran Chandler: Nel mondo del software, quanto sono cambiati rispetto ai primi pezzi di software? Quello che è molto interessante è che per capire questo cambiamento, bisogna capire le dinamiche che guidano il mercato ERP. L’ERP, in particolare i fornitori di ERP, svolgono un ruolo significativo nell’implementazione di questi sistemi, piuttosto che le aziende che li implementano da sole. Approfondiamo questo argomento. La maggior parte dei fornitori ha adottato una strategia tripla, che io chiamo Allah. Questa strategia è stata vincente nel conquistare il mercato. Oggi la maggior parte dei fornitori di ERP di successo applica queste tre tecniche.
Joannes Vermorel: La sfida principale che i fornitori di ERP devono affrontare è la complessità. Per affrontare questa sfida, devono implementare flussi continui di entità e fornire interfacce utente e logiche che abbiano senso. Il primo modo per essere più competitivi è avere tecnologie specifiche che semplifichino la produzione di entità, interfacce utente e logiche. Un esempio di tale tecnologia è un linguaggio di programmazione specifico del dominio. Ad esempio, il fornitore di ERP di successo, CP, ha inventato il proprio linguaggio di programmazione specifico del dominio chiamato ab app, che li ha aiutati a implementare entità, interfacce utente e logiche più velocemente rispetto alla concorrenza.
Kieran Chandler: Interessante. Quindi, il secondo percorso è adattare la struttura dell’offerta e la tariffazione. Puoi approfondire questo argomento?
Joannes Vermorel: Certamente. Come fornitore, il costo di produzione di un ERP è fortemente influenzato da quanto sforzo è richiesto per implementare tutti gli elementi diversi. Mentre i singoli pezzi potrebbero essere semplici, gli ERP si occupano di attività noiose, come gestire le ricevute. Poiché i fornitori devono produrre e supportare numerose entità, ha senso iniziare a addebitare non per entità, ma per moduli. I moduli raggruppano entità correlate insieme e si allineano alle considerazioni aziendali. Questo solleva un punto interessante riguardo a come i sistemi ERP addebitano il loro software.
Kieran Chandler: Assolutamente. Quindi, c’è un costo aggiuntivo per l’aggiunta di moduli. Abbiamo precedentemente discusso del blocco del fornitore. Gli interessi economici dei fornitori di ERP si allineano con questa tariffazione basata sui moduli?
Joannes Vermorel: Infatti, non appena si introducono i moduli, si offre un modo efficiente per allineare la tariffazione al costo di implementazione di tutte le funzionalità. Tuttavia, crea anche incentivi specifici. I fornitori sono motivati a continuare a sviluppare nuovi moduli da vendere oltre a quelli esistenti. Ciò può portare a un ciclo infinito di vendita di moduli ai clienti. Ma prima di approfondire i dettagli di questo, 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 della vasta complessità nel catturare tutti i dettagli dettagliati della realtà, trovano modi per crescere ancora più velocemente attraverso gli integratori. Poiché una singola azienda non può gestire tutto, i fornitori di ERP collaborano con aziende esterne note come integratori per gestire l’ultimo miglio, garantendo una soluzione completa e esaustiva.
Kieran Chandler: Quindi, Joannes, hai accennato in precedenza che Lokad sta introducendo una nuova funzionalità per i suoi clienti. Potresti dirci di più a riguardo?
Joannes Vermorel: Sì, infatti. Stiamo lanciando una nuova funzionalità per i nostri clienti. Coinvolge 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 scaricare il costo e il rischio associati a questa funzionalità. Ci sono molte funzionalità che possono essere esternalizzate a aziende di terze parti.
Kieran Chandler: Quindi, i fornitori di software trasferiscono il rischio agli integratori e, in ultima analisi, ai loro clienti. Gli integratori hanno il loro incentivo, che potrebbe non allinearsi completamente con l’incentivo del fornitore di software. È corretto?
Joannes Vermorel: Esattamente. Gli integratori hanno l’incentivo di fornire ai clienti un alto livello di personalizzazione perché vengono pagati di più per i moduli personalizzati piuttosto che per i moduli integrati. Possono convincere i clienti dicendo che la loro attività è unica e richiede una soluzione che rifletta la loro unicità. È una dinamica interessante.
Kieran Chandler: Capisco. Quindi, ci sono approcci diversi che le aziende possono adottare quando si tratta di sistemi ERP. Come si determina quale sia un buon approccio e quale sia un cattivo approccio?
Joannes Vermorel: Oggi, quando si considerano le scelte degli ERP, è necessario interrogarsi se tutti i vincoli che sono stati incorporati negli ERP alla fine degli anni ‘70 siano ancora rilevanti per la propria situazione. Dipende da diversi fattori. Ad esempio, l’idea che sia necessario integrare tutto in un unico sistema è spesso insensata perché la complessità non scala linearmente. Aggiungere più entità al sistema porta a più casi limite e variazioni in ciò che diverse industrie considerano come un “prodotto”.
Kieran Chandler: Quindi, stai dicendo che dobbiamo riesaminare l’assunzione che abbiamo ancora bisogno di un unico sistema per gestire tutto?
Joannes Vermorel: Esattamente. Quell’assunzione non è più accurata. Avere 100 sistemi distinti che richiedono coordinazione è impegnativo, ma avere un unico sistema principale come soluzione totale è anche problematico. Quando si desidera apportare modifiche a un tale sistema, diventa un progetto enorme che coinvolge ogni funzione dell’azienda.
Kieran Chandler: Capisco. Sembra che passare a un nuovo sistema possa essere piuttosto difficile. Alcune aziende hanno subito costosi fallimenti nel tentativo di passare a nuovi sistemi ERP. Quanto è pratico effettuare tale transizione?
Joannes Vermorel: Effettivamente, passare a un nuovo sistema ERP può essere impegnativo. Abbiamo visto aziende sprecare miliardi di dollari cercando di effettuare tali transizioni. Non è un compito facile nella pratica.
Kieran Chandler: Nel 2009, hanno sprecato mezzo miliardo di euro per un aggiornamento ASAP. Non era nemmeno un’implementazione, solo un aggiornamento. Quindi, la domanda è: è più difficile aggiornare un ERP rispetto a passare a uno nuovo?
Joannes Vermorel: È una domanda molto interessante. Sorprendentemente, l’aggiornamento di un ERP è tipicamente più difficile rispetto al passaggio a uno nuovo. Potrebbe sembrare controintuitivo, ma è quello che ho osservato. Quando ti sposti su un nuovo ERP, non hai illusioni sul fatto che sarà un’impresa enorme. Tuttavia, quando lo consideri solo come un aggiornamento, potrebbe sembrare semplice, ma può essere effettivamente molto, molto difficile.
Il problema è che quando passi da una versione all’altra, c’è uno spostamento semantico nelle entità. Vedi, gli ERP riguardano la rappresentazione di entità che riflettono varie questioni nel tuo business, come i prodotti. Potresti pensare che la semantica di queste entità in un ERP sia definita dal fornitore, ma non è del tutto vero. La semantica finale di qualsiasi entità risiede nell’occhio dell’operatore, la persona che interagisce con il sistema e svolge l’inserimento dati e il flusso di lavoro.
Quindi, la vera semantica di un’entità è determinata dalla persona che opera l’ERP. Sfortunatamente per i fornitori di ERP, non hanno molto controllo su ciò che le persone fanno effettivamente con il prodotto. Possono fornire raccomandazioni e programmi di formazione, ma alla fine è impegnativo. Alcune aziende possono decidere di avere semantica leggermente diversa per far funzionare l’ERP nella loro situazione specifica. Non è perché sono ribelli; è ciò che serve per far funzionare l’ERP.
Tuttavia, il problema sorge quando passi alla versione successiva. Puoi incontrare numerosi casi limite sottili in cui l’entità improvvisamente non significa esattamente la stessa cosa a causa di nuovi sviluppi e una miriade di vari casi limite.
Kieran Chandler: È interessante. Quindi, da un lato dello spettro, hai questi approcci monolitici su larga scala, e dall’altro hai aziende ERP più piccole e specializzate. Quanta fiducia puoi riporre in queste aziende più piccole che potrebbero non sopravvivere nel prossimo decennio?
Joannes Vermorel: Se sei una piccola azienda, desideri un sistema in cui la complessità abbia senso in relazione alla tua scala. I prodotti ERP tendono a diventare più complessi nel tempo. Quindi, se sei un’azienda giovane, magari di soli cinque anni, e sei cresciuta rapidamente, sarebbe sbagliato attenersi a 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à. Affrontare una tale complessità può essere opprimente.
Quindi, il mio consiglio è quello di considerare le aziende ERP più giovani, anche se comportano un certo livello di rischio. Fate attenzione a non seppellirvi in pile di complessità. Nella mia esperienza di gestione di Lokad per oltre un decennio, non ho visto un’azienda affrontare una situazione drammatica solo a causa della scelta dell’ERP. Tuttavia, lanciare un prodotto che è molto più complesso della tua scala può essere dannoso e persino uccidere la tua attività. L’ho visto accadere frequentemente, dove le aziende lottano perché hanno adottato un software che era semplicemente troppo complesso per loro in termini di complessità e funzionalità.
Kieran Chandler: Sembra che quando si tratta di scegliere un software, avere un nucleo solido e applicazioni interconnesse sia cruciale per un’azienda in crescita. Joannes, potresti approfondire questa idea?
Joannes Vermorel: Assolutamente. L’essenza controintuitiva è che è meglio avere qualcosa con un nucleo ristretto che rifletta 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 seminare il caos nei tuoi processi e ti impediscono di svolgere semplici compiti. I prodotti software completamente integrati rendono difficile rimuovere o modificare determinate funzionalità senza interrompere l’intero sistema.
Kieran Chandler: Quindi, scegliere un prodotto più piccolo non elimina completamente questi problemi?
Joannes Vermorel: No, la portata e l’importanza di questi problemi dipendono dalla complessità e dalle entità all’interno del 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, stipendi e gestione delle scorte. Non è necessario avere un singolo ERP che comprenda tutto. Assicurati solo che queste app abbiano API per estrarre i dati in modo da poterle integrare in seguito 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, potrebbe essere preso in considerazione un prodotto ERP più completo. Sarà più complicato, con numerose tabelle e funzionalità. A questo punto, hai vari aspetti tipici dell’attività da gestire e un ERP può fornire copertura per tali esigenze. Potrebbe richiedere un progetto di implementazione più lungo e un buon integratore, ma può offrire la funzionalità desiderata.
Kieran Chandler: Questo è più produttivo rispetto alle piccole app che stanno iniziando a mostrare i loro limiti. Quindi, se sei più grande, direi che la situazione cambia di nuovo. Se sei più grande, più… Voglio dire, diciamo che sei come un’azienda con 5.000 dipendenti… Sai, la tua grande azienda. Allora, tipicamente, direi che ci sono due cose che entrano in gioco. Prima di tutto, vuoi spezzarli sul ramo. Sai, il monolite semplicemente non funzionerà per te se sei grande. Se opti per un ERP monolitico, che la maggior parte delle grandi aziende sta facendo… Direi che la maggior parte… Voglio dire, sarà brutto. Ci vorranno anni. Sarà incredibilmente costoso.
Joannes Vermorel: Se guardi cosa stanno facendo le migliori grandi aziende, stanno implementando, direi, cose abbastanza personalizzate. E hanno ottime ragioni. Se sei un’azienda grande, è probabile che tu abbia, come dire, un vantaggio competitivo unico che non è una cosa semplice. È incorporato nella tua organizzazione, che è grande, che è complessa e forse hai fatto acquisizioni. Quindi potresti avere, come dire, un paesaggio di geni erratici fin dall’inizio. Quindi, anziché dire “Voglio un ERP che governi tutto”, che funzionava quando avevi, diciamo, 500 dipendenti, diventa molto difficile quando ne hai, diciamo, 5.000. Quindi il mio suggerimento è che devi fondamentalmente dividere e conquistare. Questo tipo di approccio che stavo suggerendo quando eri molto piccolo, sai, e avevi un paio di app, puoi ripensarlo in modo completamente diverso se sei grande.
Quindi, diciamo, dividerò il panorama in, non so, forse una dozzina di aree funzionali. E poi costruirò o comprerò in ogni area, a seconda che i fornitori che posso trovare siano buoni o meno. E la sfida più grande, quello che consiglierei a quelle aziende più grandi, è rompere il dogma secondo cui è necessario avere, come dire, un ERP che governi tutto. Credo che sia per lo più… voglio dire, è per lo più una sciocchezza. E se guardi i giocatori molto, molto competitivi, diciamo Amazon, Alibaba, Rakuten, Zalando, sai, quei giocatori tecnologici che devono gestire la supply chain fisica. Quindi, non sto… Sai, non sto parlando di Microsoft, che è, come dire, un giocatore digitale quasi puro. Sai, hanno Xbox. Xbox è un prodotto molto fisico. Ma se guardi le aziende che sono state riconosciute come le migliori nel gestire una supply chain fisica come Amazon, tutte hanno adottato un approccio molto… direi, di dividere e conquistare nel loro panorama applicativo, dove fondamentalmente, vanno molto aggressivamente per un approccio di costruire o comprare. E… E fondamentalmente, nessuna di queste aziende ha davvero un ERP. Hanno elenchi di prodotti. Alcuni di essi sarebbero più vicini a un ERP. E la maggior parte di queste aziende ha anche scritto i propri sistemi, per parti specifiche di ciò che sarebbe tipicamente definito come un modulo ERP.
Kieran Chandler: Bene, dobbiamo concludere qui, ma grazie mille per il tuo tempo questa mattina.
Joannes Vermorel: Grazie, Kieran.
Kieran Chandler: Questo è tutto per questa settimana. Ciao per adesso.
