Progettazione software per la supply chain

00:00:07 Importanza della progettazione software nelle moderne supply chain.
00:01:22 Problemi comuni di progettazione software nella gestione della supply chain.
00:02:37 Sfide dei sistemi software in tempo reale nelle supply chain.
00:04:55 Come le operazioni complesse possono influire sui sistemi in tempo reale.
00:07:13 Sistemi in tempo reale intasati da operazioni non in tempo reale.
00:09:13 Importanza delle scelte di design e della scala temporale nel software per la supply chain.
00:12:31 Differenze tra software a singolo tenant e software a tenant multipli.
00:14:11 Sfide con le diverse versioni del software nelle applicazioni a singolo tenant.
00:15:33 Vantaggi del software a tenant multipli e il passaggio ai modelli SaaS.
00:17:56 Importanza della comprensione delle assunzioni di base nella progettazione software per i professionisti della supply chain.
00:19:18 Assunzioni di base del design di Lokad, inclusa la modalità di elaborazione batch e la multi-tenancy.
00:21:35 Considerazioni conclusive sulla comprensione delle scelte nel software e il loro impatto sulle future operazioni.
00:23:36 Considerazioni finali.

Riassunto

In un’intervista con Joannes Vermorel, fondatore di Lokad, viene discusso l’impatto della progettazione software sull’ottimizzazione della supply chain. Le sfide spesso derivano da problemi di progettazione piuttosto che da bug o crash, il che può rendere il software lento, poco intuitivo e difficile da configurare. La gestione dei dati in tempo reale è una caratteristica chiave che può influire sulle operazioni. Tuttavia, concentrarsi su operazioni rapide e semplici può ostacolare processi complessi come la previsione o le analisi a livello di rete. È fondamentale comprendere le assunzioni di design del software per evitare problemi derivanti da discrepanze tra il design del software e l’uso previsto dall’azienda.

Riassunto esteso

In questa intervista, l’ospite Kieran Chandler discute con Joannes Vermorel, fondatore di Lokad, l’impatto della progettazione software sulle operazioni aziendali, in particolare nel contesto dell’ottimizzazione della supply chain. Vermorel sottolinea l’importanza della progettazione software nelle moderne supply chain, che si basano su più livelli di software, come ERPs, MRPs, WMSs, OMSs ed EDIs, per funzionare in modo efficiente.

Le sfide affrontate dai clienti di Lokad derivano spesso da problemi di progettazione del loro software, piuttosto che da bug o crash evidenti. Questi problemi di progettazione possono rendere il software lento, poco intuitivo, lento e difficile da configurare. Come spiega Vermorel, questi problemi spesso derivano da una discrepanza tra le decisioni di design di base prese per il software e la realtà effettiva della supply chain che si intende servire.

Una delle caratteristiche chiave dell’architettura del software che può influire sulle operazioni della supply chain è la sua capacità di gestire dati in tempo reale. Vermorel fa notare che, sebbene l’elaborazione dei dati in tempo reale vero non sia possibile a causa della velocità finita della luce, molti sistemi software per la supply chain sono progettati per approssimare l’elaborazione dei dati in tempo reale. Ad esempio, quando un articolo viene prelevato da uno scaffale, il software decrementa immediatamente il livello di stock. Tuttavia, questo approccio in tempo reale può avere conseguenze indesiderate.

Quando il software è progettato per operazioni rapide e semplici, diventa difficile eseguire operazioni più complesse, come la previsione o l’analisi a livello di rete. Queste operazioni complesse richiedono un livello più sofisticato di elaborazione dei dati, che potrebbe non essere fattibile all’interno di un sistema ottimizzato per gli aggiornamenti in tempo reale su piccola scala.

Joannes Vermorel sottolinea l’importanza critica della progettazione del software nell’ottimizzazione della supply chain. Le sfide affrontate dai clienti di Lokad derivano spesso da problemi di progettazione che rendono il software lento, poco intuitivo e difficile da configurare, a causa di una discrepanza tra le decisioni di design di base del software e la realtà effettiva della supply chain. La capacità di gestire dati in tempo reale è una delle caratteristiche chiave dell’architettura del software che può influire sulle operazioni della supply chain. Tuttavia, quando il software è progettato per operazioni rapide e semplici, diventa difficile eseguire operazioni più complesse, come la previsione o l’analisi a livello di rete, che richiedono un livello più sofisticato di elaborazione dei dati.

Vermorel spiega che i problemi affrontati dagli operatori della supply chain che utilizzano tali software non sono sempre evidenti, poiché spesso si manifestano come una lenta accumulazione di problemi, che lui definisce “morte per mille tagli”.

Un problema chiave è la necessità di funzionalità in tempo reale in determinati scenari, come la scansione degli articoli su un nastro trasportatore ad alta velocità. Quando vengono introdotte operazioni non in tempo reale nel sistema, le prestazioni complessive possono essere influenzate negativamente, con conseguenti rallentamenti e ritardi. Ciò può portare a una maggiore frustrazione tra gli utenti e a una ridotta efficienza.

Vermorel sottolinea l’importanza di fare le scelte di design di base corrette, che dovrebbero essere profondamente allineate ai problemi che il software cerca di risolvere. Nel contesto del software per la supply chain, vengono fatte varie ipotesi di base e, se queste non vengono soddisfatte, possono sorgere problemi lungo la linea.

La scala temporale su cui opera il software è una considerazione cruciale. Vermorel descrive i diversi tipi di software necessari per varie scale temporali, che vanno dai tempi di risposta sub-millisecondi per guidare i nastri trasportatori, alla pianificazione a lungo termine che coinvolge decisioni sulla posizione delle fabbriche che si estendono su anni o addirittura decenni. Ogni ordine di grandezza di aumento della scala temporale richiede un tipo di software diverso con capacità uniche.

Presso Lokad, l’attenzione è di solito rivolta a scale temporali da un giorno a un anno, il che richiede un approccio diverso alla progettazione del software. Vermorel parla anche delle differenze tra software multi-tenant e single-tenant, che è una considerazione critica per gli sviluppatori di software, sebbene meno familiare alla maggior parte delle aziende.

Discutono delle differenze tra software multi-tenant e single-tenant, dei vantaggi del modello SaaS e delle ipotesi di base che hanno guidato la progettazione del software di Lokad.

Vermorel spiega che il software multi-tenant serve più clienti utilizzando lo stesso pezzo di software, mentre il software single-tenant prevede di fornire a ciascun cliente la propria versione personalizzata. Lokad è multi-tenant, con una base di codice aggiornata settimanalmente. Questo approccio ha diversi vantaggi, tra cui una versione semplificata e meno problemi di sicurezza. Vermorel contrasta questo con il software single-tenant, che consente la personalizzazione per cliente ma richiede la gestione di più versioni, con conseguenti sfide operative.

Osserva che, negli ultimi dieci anni, molte aziende software serie si sono orientate verso il multi-tenancy. Per le app web come Lokad, essere multi-tenant è piuttosto semplice, ma per il software che opera sulle macchine dei clienti può essere più complicato. Una soluzione a questo problema è la strategia “evergreen”, come esemplificato da Google Chrome e Microsoft Office 365. Queste applicazioni si aggiornano automaticamente, senza intervento dell’utente, mitigando così i problemi derivanti dall’avere più versioni dello stesso software.

Parlando della progettazione del software di Lokad, Vermorel sottolinea l’importanza di comprendere le ipotesi di base di un fornitore. Mette in guardia contro i fornitori che affermano che il loro software può fare tutto e sottolinea che la progettazione riguarda i compromessi, con aspetti positivi e negativi. Incoraggia i potenziali clienti a chiedere ai fornitori di software quali sono le loro ipotesi di base e a essere cauti nei confronti di coloro che forniscono solo risposte vaghe e positive.

Le ipotesi di progettazione fondamentali di Lokad includono la modalità di elaborazione batch, che Vermorel spiega essere scelta perché consente una migliore ottimizzazione e gestione delle risorse.

Uno dei principi fondamentali è dare priorità ai calcoli intelligenti rispetto alla velocità. Lokad preferisce avere calcoli accurati e dettagliati anche se richiede più tempo, piuttosto che calcoli più veloci e meno precisi. Il software è progettato per l’elaborazione batch anziché in tempo reale, consentendo una maggiore espressività e potenza nell’analisi.

Un’altra ipotesi di base è l’importanza del multi-tenancy e l’adozione delle capacità offerte dal cloud computing. Lokad mira a utilizzare le capacità di scale-out anziché di scale-up, il che significa che utilizzano più macchine più piccole per elaborare grandi quantità di dati anziché fare affidamento su un singolo supercomputer potente.

Vermorel sottolinea l’importanza che i professionisti della supply chain comprendano le ipotesi di base di progettazione del loro software. Questa comprensione aiuta a prevenire problemi derivanti da una discrepanza tra la progettazione del software e l’uso previsto dall’azienda. I fornitori possono affermare che il loro software è versatile e adatto a varie situazioni, ma in realtà, determinate limitazioni di progettazione possono ostacolarne l’efficacia in alcune applicazioni.

Trascrizione completa

Kieran Chandler: Oggi, cercheremo di capire come queste decisioni possano effettivamente limitare una società e comprendere anche alcune delle ipotesi di base che le sottendono. Quindi, Joannes, stiamo parlando un po’ di come una cattiva progettazione del software possa effettivamente influire su una società. Quali sono alcune delle sfide che vedi?

Joannes Vermorel: La prima sfida è che la progettazione del software è di fondamentale importanza per le catene di approvvigionamento. Le moderne catene di approvvigionamento si basano sul software. Hai camion, macchine, nastri trasportatori, ma anche grandi quantità di software come il tuo ERP, MRP, WMS, OMS, EDI e così via. Le moderne catene di approvvigionamento non funzionano senza software in grandi quantità. Quando discuto con i clienti di Lokad, spesso si scontrano con il panorama applicativo della catena di approvvigionamento. Ci sono molti problemi legati al software, ma non sono necessariamente bug o crash. I problemi di progettazione sono molto più diffusi; rendono le cose lente, non intuitive, lente e ci vuole un’eternità per configurare il sistema. Quando si cerca di fare un’analisi delle cause di fondo, spesso si osserva che i problemi sono in realtà problemi di progettazione del software in cui sono state prese decisioni fondamentali sul design del software e che semplicemente non corrispondono alla realtà effettiva della catena di approvvigionamento di interesse.

Kieran Chandler: Quindi, quali sono alcune caratteristiche dell’architettura del software che possono essere così importanti? Quali sono alcune delle sfide che hai riscontrato con i tuoi clienti?

Joannes Vermorel: Diciamo, ad esempio, in tempo reale. Molti software di supply chain oggi sono orientati verso operazioni in tempo reale. Con “in tempo reale” intendo che se decidi di prendere un’unità dallo scaffale, il livello di stock viene immediatamente decrementato. Sembra una cosa molto ragionevole. Tuttavia, non appena hai questo tipo di software progettato per l’elaborazione in tempo reale, qualsiasi calcolo sofisticato diventa difficile da gestire nel software. Il motivo è che se il tuo software è progettato per essere super veloce per operazioni molto semplici, avere un’operazione complessa, come una previsione o un’analisi a livello di rete, diventa una lotta. Questo perché il tuo software è progettato per operazioni molto rapide e semplici e quando devi elaborare una quantità moderatamente complessa di dati, diventa difficile.

Kieran Chandler: E se hai una versione molto granulare, rallenterà tutti, comprese le cose che dovrebbero essere super veloci, come la scansione di un codice a barre e il beep. Ho scansionato, puoi passare al prossimo articolo. Quanto sono evidenti alcune di queste sfide? Devi simpatizzare con un professionista della supply chain. Voglio dire, ci sono molte cose in corso e con un software del genere, ci sono molte cose che accadono sotto il cofano. Quindi, quanto è evidente che alcune di queste sfide sono presenti?

Joannes Vermorel: Non è ovvio perché di solito non è un bug evidente che fa crashare il sistema. È più come una morte per mille tagli. Lascia che ti illustri: hai questo sistema che dovrebbe essere in tempo reale. Quando qualcosa viene scansionata su un nastro trasportatore ad alta velocità, dovresti essere in grado di beepare gli articoli a una velocità di tre articoli al secondo, o qualcosa del genere. Dovresti essere molto veloce e avere un tempo di risposta di millisecondi.

Ora, cosa succede se, di tanto in tanto, hai un calcolo che richiede alcuni secondi invece di millisecondi? Se hai solo un’operazione, di tanto in tanto, che richiede alcuni secondi e il tuo sistema in tempo reale è ben progettato, probabilmente la maggior parte delle altre operazioni rimarrà super veloci, quindi non fa molto male. Tranne che, se non hai fortuna e nello stesso momento hai come dieci diverse operazioni che richiedono diversi secondi per essere elaborate. Questo assorbe, in quel preciso momento, tutte le risorse di calcolo.

Quindi, quello che succederà è che il sistema che avrebbe dovuto essere in grado di scansionare e darti un feedback in millisecondi improvvisamente richiederà un secondo. Non è ideale, ma puoi conviverci. Tuttavia, di tanto in tanto, hai questa situazione in cui ti aspettavi qualcosa di velocissimo, ma improvvisamente ci sono due o tre secondi di ritardo. A proposito, a volte puoi vedere questo anche nei supermercati locali. Hai un punto vendita e la scansione degli articoli è molto fluida, ma ad un certo punto, beepano qualcosa e passano tre secondi, e poi beep.

Qui hai un sistema in tempo reale che è stato in qualche modo intasato da un’operazione non in tempo reale. Non so cosa fosse, forse un aggiornamento di Windows o qualche tipo di stranezza che rallenta la macchina. Ma in un sistema in tempo reale, non ti è permesso fare nulla di intelligente o complesso perché ciò degraderà le operazioni super veloci che desideri effettuare.

Quando dico morte per mille tagli, è perché la prima volta che fai qualcosa di non in tempo reale in un sistema in tempo reale, probabilmente non succederà nulla di grave. È raro, quindi sei abbastanza tranquillo. Ma il problema è che accumuli sempre più cose non in tempo reale e improvvisamente quei problemi che erano molto rari iniziano a diventare più frequenti e sempre più frequenti, fino a diventare super frequenti. A quel punto, le persone impazziscono dicendo: “Perché questo nastro trasportatore non funziona più velocemente? Potrebbe farlo.”

La risposta è che c’è una macchina che dovrebbe scansionare il codice a barre e dobbiamo aspettare che il sistema risponda. Ho visto situazioni in cui ci voleva mezzo minuto perché il sistema rispondesse dopo la scansione di un codice a barre. Si trattava di stampare qualcosa da mettere sulla scatola, ma il nastro trasportatore era limitato dalla velocità con cui il sistema poteva inviare l’ordine alla stampante per stampare qualcosa sulla scatola. Avevano persone che aspettavano solo che la stampante stampasse.

Hai molte scelte di progettazione che devono essere fatte correttamente, in modi profondamente allineati con i problemi che stai cercando di risolvere.

Kieran Chandler: Quali sono le principali assunzioni di base che vengono fatte nel software di supply chain e quali di queste hai osservato che non funzionano davvero?

Joannes Vermorel: Ci sono molti modi per affrontare questo problema. Prima di tutto, considera la scala temporale in cui vuoi operare. Abbiamo cose che devono funzionare con un tempo di risposta inferiore al millisecondo, che è ciò di cui hai bisogno per guidare letteralmente un nastro trasportatore, fino a decisioni in cui devi pensare a dieci anni nel futuro, come la posizione delle fabbriche. Ogni volta che aggiungi un ordine di grandezza, cambi fondamentalmente il software.

Kieran Chandler: Puoi darmi alcuni esempi di diverse scale temporali e i tipi di software corrispondenti?

Joannes Vermorel: Certamente. Il sub-millisecondo è un tipo di software; da 1 a 10 millisecondi, sarà un altro tipo di software; da 10 a 100 millisecondi, sarà un altro tipo, che è tipicamente un software ERP con tempi di risposta da 10 a 100 millisecondi. Da 100 millisecondi a 1 secondo, ottieni il tipo di cose che puoi trovare in un’app web. Poi, se inizi a pensare da 1 minuto a 10 minuti nel futuro, non sei più in tempo reale, ma puoi iniziare a fare calcoli fantasiosi. Ad esempio, un’app di navigazione come Waze deve fornire un percorso entro mezzo minuto ma non deve essere in tempo reale.

Se stai ottimizzando un percorso per le consegne dei camion, di solito puoi impiegare diversi minuti per ottenere i risultati, poiché non è necessario che sia in tempo reale. Da Lokad, siamo tipicamente più concentrati su intervalli di tempo da 1 giorno a 1 anno. Questo è il nostro punto di forza e significa che possiamo praticamente ignorare tutto ciò che viene prima. Se andiamo oltre un anno, entriamo nel campo della progettazione della supply chain, che è più incentrata sulla mappa e cambia il problema.

Kieran Chandler: Parliamo di più dell’implementazione del software. Quali sono le principali differenze tra il software a tenant singolo e il software a tenant multipli?

Joannes Vermorel: La differenza tra il software a tenant singolo e il software a tenant multipli sta nel numero di clienti che servono con lo stesso pezzo di software. Se sei a tenant multipli, come Lokad, è lo stesso software che serve tutti i nostri clienti. Abbiamo una sola versione distribuita online in qualsiasi momento e aggiorniamo questo software settimanalmente. L’altro modo, che era più comune prima dell’avvento del SaaS, è il tenant singolo. Questo approccio prevede di dare a ciascun cliente la propria copia del software, il che spesso comporta personalizzazioni per i grandi clienti.

Produrre il software significa che improvvisamente ti ritrovi con molte varianti del tuo software che casualmente stanno funzionando contemporaneamente, il che rappresenta un grande problema operativo perché significa che se c’è un bug che si è verificato in una versione, devi correggere questa versione, ma devi assicurarti che il bug sia anche corretto in tutte le altre versioni. A proposito, questo è un problema in cui, per le aziende di software, hai come delle anti-economie di scala. Più sei grande, più hai problemi con la tua versione. A proposito, questo problema sta influenzando molto Oracle, ad esempio, con il database Oracle. Hanno molte versioni pesantemente personalizzate che sono ottimizzate per le prestazioni. Non ho informazioni riservate, ma dalle sole informazioni pubbliche si può vedere che letteralmente, in alcune divisioni di ingegneria multiple in Oracle, stanno lottando con il fatto che ci sono molte varianti del software in circolazione. Ovviamente, Oracle ha tonnellate di capacità di ingegneria, ma rimane comunque una grande sfida. Quindi, il tenant singolo ti offre l’opzione di personalizzazione per cliente, ma poi devi fare i conti con gli oneri per cliente. Il tenant multipli ti offre il fatto che hai una base di codice per tutti, nessuna personalizzazione, ma in cambio puoi evolvere molto più velocemente e avere anche molti meno problemi di sicurezza.

Kieran Chandler: Quando dici che il mercato si sta spostando molto verso quel tipo di modello SaaS, perché questo modello è così migliore? Fornisce un grado maggiore di flessibilità per l’azienda?

Joannes Vermorel: Sì, nell’ultimo decennio, praticamente tutti i seri fornitori di software si sono spostati verso il multi-tenant, anche le classiche applicazioni desktop tradizionali. Perché ovviamente, se sei un’app web come Lokad, essere multi-tenant è piuttosto semplice. Ridistribuisci le cose sui tuoi sistemi e il gioco è fatto. Ovviamente, quando hai un software che opera sulle macchine dei clienti, come ad esempio il tuo browser, Internet Explorer o Google Chrome, è più complicato perché non hai il controllo delle macchine dei clienti. Ma indovina cosa hanno fatto i fornitori di software? Sono passati alla strategia evergreen. Ad esempio, Google Chrome non ti chiede più di aggiornare il browser. Quando Google decide che la tua versione di Chrome è obsoleta e deve essere sostituita, Google aggiorna il tuo browser a distanza. Ovviamente, la prossima volta che ti colleghi a Internet e così via, non possono aggiornare magicamente il tuo software se non hai una connessione a Internet. Ma supponendo che tu abbia una connessione a Internet e non abbia fatto alcuna manovra specifica con la tua macchina per impedire l’aggiornamento, l’aggiornamento avverrà, fondamentalmente senza il tuo intervento. E quando guardi cosa sta facendo Microsoft con Office 365, è la stessa cosa. In passato, avevi una serie di versioni di Microsoft Office quando passavi da una versione di Excel alla successiva. Oggi è on-demand e Microsoft si occupa dell’aggiornamento. Hai una sottoscrizione, il software è installato sulla tua macchina, ma può semplicemente aggiornarsi alla versione successiva. E se lo lasci fare, a meno che tu non disattivi le opzioni di aggiornamento, Microsoft sta semplicemente aggiornando tutte le app desktop proprio per mitigare il problema di avere molte versioni dello stesso software.

Kieran Chandler: Parliamo un po’ di Lokad allora. Hai detto che ci sono alcune assunzioni fondamentali che devono essere fatte nella progettazione del software che possono davvero influenzare le operazioni future. Quindi, quali sono le assunzioni fondamentali che hai fatto qui a Lokad?

Joannes Vermorel: Ce ne sono un sacco, ma prima di entrare nelle assunzioni fondamentali, vorrei fare una nota. Se incontri un fornitore di software che

Kieran Chandler: Che ti dice tutto il mio software, sai. Siamo capaci di fare tutto ciò che non abbiamo fatto. Sai, assunzione del software. Se ti danno solo, posso suggerire, sai, quando incontri un fornitore di software per la tua supply chain, chiedigli quali sono le assunzioni fondamentali? E se ti dicono qualcosa di vago come “siamo progettati per la sicurezza”, ottimo. “Siamo progettati per la velocità”, sì, anche io. “Siamo progettati per l’efficienza dei costi”, sì. Sai, queste sono sorta di cose vaghe, assolutamente positive. Ma quando discutiamo di progettazione, un punto di vista di progettazione è un compromesso. È qualcosa che ha aspetti positivi e aspetti negativi. Quindi, se puoi discutere con il fornitore di software e tutto ciò che possono darti sono gli aspetti positivi, probabilmente non capiscono nemmeno la natura della progettazione del software in primo luogo. Quindi, Joannes, quali sono le assunzioni di progettazione fondamentali che hai integrato in Lokad?

Joannes Vermorel: La prima era una modalità di elaborazione batch. Quindi, cosa significa? Significa che vogliamo essere in grado di elaborare tonnellate di dati e fare calcoli molto intelligenti. Ovviamente, perché vogliamo, preferiamo essere molto intelligenti piuttosto che molto, molto veloci, il che significa che, per noi, avere calcoli che vengono eseguiti tipicamente in pochi minuti, ma il fatto che possano essere eseguiti in pochi secondi è una sorta di bonus. Ma se non possiamo, non è un grosso problema. Preferiamo avere numeri migliori anche se ci vuole un po’ di tempo. A proposito, non è perché ci sono parti nostre che guardano a quello che facciamo. È solo una presentazione dei risultati. Quindi, forse ti serviranno mezz’ora per fare un calcolo massiccio, ma quando vuoi accedere a quei risultati, allora deve essere in tempo reale, ma è pre-calcolato. Quindi, vedi che era un’assunzione di progettazione fondamentale. Niente in tempo reale, o è batch. E il motivo è che vogliamo essere in grado di essere molto espressivi e molto potenti e quindi essere intelligenti quanto possibile per, direi, l’analisi mondiale netta. Quindi, questa è una delle assunzioni fondamentali. Un’altra era che volevamo avere multi-tenancy. Ovviamente, al giorno d’oggi, la maggior parte delle persone lo fa, ma ci sono ancora aziende che sono, specialmente nello spazio enterprise, indietro. E direi multi-tenancy fatto con tutto.

Kieran Chandler: Puoi spiegare la differenza tra scalabile e scalabile in modo orizzontale?

Joannes Vermorel: Le capacità offerte dal cloud significano che vogliamo avere capacità di scalabilità orizzontale piuttosto che scalabilità verticale. La domanda è, se vuoi elaborare terabyte di dati, puoi farlo accumulando tonnellate di piccole macchine o hai bisogno di un supercomputer per farlo?

Kieran Chandler: Quindi qual è la nostra principale conclusione qui oggi?

Joannes Vermorel: La nostra principale conclusione è che in termini dei dati che abbiamo là fuori e in termini di prendere decisioni sul software, può davvero limitare ciò che fai in futuro. Quindi devi capire appieno le scelte che stai facendo.

Kieran Chandler: Puoi approfondire questo argomento?

Joannes Vermorel: Il mio suggerimento sarebbe per i professionisti della supply chain di essere più consapevoli delle assunzioni di progettazione fondamentali che caratterizzano il proprio panorama applicativo. Hanno molte app e possono darmi mezza dozzina di assunzioni di codice critiche che spiegano i dettagli del prodotto. Potrebbe sembrare super tecnico, ma se non capisci quelle assunzioni di progettazione fondamentali, soffrirai molto quando ti rendi conto che stai cercando di fare qualcosa per cui, per progettazione, questo non sarà un buon prodotto. Spesso ho visto molte aziende in cui letteralmente i loro problemi emergono da una discrepanza tra la progettazione del software e ciò che stanno cercando di fare con esso.

Kieran Chandler: Puoi dare un esempio?

Joannes Vermorel: I fornitori cercano di essere molto fiduciosi, sai, come fornitore, stai cercando di vendere il tuo software. Vuoi agire con fiducia e dire al cliente che il tuo software per la supply chain sarà ottimo in tutte le situazioni e che ti abbiamo coperto. Ma la realtà è che se un cliente sta per utilizzare il tuo software per qualcosa che è al di fuori delle tue capacità di progettazione, non puoi semplicemente aggiustare il tutto con del nastro adesivo. Non puoi semplicemente aggiungere una funzionalità. Gli ingegneri del software sul retro ti diranno: “Boss, mi dispiace, non possiamo farlo. Sarà un inferno.”

Kieran Chandler: Bene, concludiamo. Grazie, Joannes. Questo è tutto per questa settimana. Grazie mille per averci seguito e ci vediamo la prossima volta. Ciao per ora.