Dati Errati in Supply Chain

00:00:07 Incolpando i dati errati nei progetti di supply chain.
00:00:33 Perché i dati errati rappresentano una scusa facile per il fallimento dei progetti.
00:01:42 Le sfide legate ai dati errati e i fraintendimenti sulla loro qualità.
00:03:16 Difficoltà nell’accesso ai dati dai sistemi ERP e sfide con i fornitori.
00:06:32 Problemi che sorgono durante la migrazione tra sistemi ERP e la corruzione dei dati.
00:08:01 Affrontare errori di inserimento dei dati e il loro impatto sui sistemi ERP.
00:09:48 Prevedere e individuare problemi nei dati storici.
00:11:37 Come l’evoluzione della semantica e le modifiche nelle definizioni possono causare problemi con i dati.
00:12:20 Problemi di scalabilità e ottimizzazione del recupero dei dati man mano che le aziende crescono.
00:14:45 Sfide nella creazione di estrazioni giornaliere pulite e il potenziale di errori nei dati.
00:16:02 L’impatto dei tempi di elaborazione più lunghi sulla risoluzione dei problemi nei dipartimenti IT.
00:17:15 Il problema della semantica dei dati e i malintesi nell’interpretazione dei dati.
00:19:22 L’importanza della documentazione per ogni campo dati per garantire una corretta comprensione.
00:21:01 Il ruolo dei professionisti della supply chain e dei dipartimenti IT nella comprensione della semantica dei dati.
00:23:59 La varietà di problemi relativi ai dati errati e l’identificazione delle cause alla radice.

Riassunto

Nell’intervista, Kieran Chandler e Joannes Vermorel discutono il ruolo dei dati nell’ottimizzazione della supply chain e le sfide affrontate dai venditori di software e dai professionisti. Vermorel sottolinea che il problema principale non sono i “dati errati”, ma piuttosto l’accesso e l’utilizzo efficace degli stessi. Tra le sfide figurano sistemi obsoleti, documentazione inadeguata e questioni relative alla responsabilità dell’accesso ai dati. Conflitti di interesse con gli integratori, problemi nella migrazione dei sistemi, previsioni e scalabilità rappresentano ulteriori problematiche. Per ottimizzare la supply chain le aziende devono comprendere e affrontare i problemi dei dati, investire in una documentazione adeguata, chiarire la semantica dei dati e mantenere aspettative realistiche, anziché incolpare i dati per i fallimenti.

Riassunto Esteso

Nell’intervista, Kieran Chandler e Joannes Vermorel, il fondatore di Lokad, discutono il ruolo dei dati nei progetti di ottimizzazione della supply chain e le sfide affrontate dai venditori di software e dai professionisti della supply chain. Iniziano affrontando l’idea che i “dati errati” vengano spesso usati come capro espiatorio per il fallimento dei progetti di supply chain. Vermorel osserva che incolpare i dati è un modo comodo per evitare di incolpare le persone, che potrebbero prenderla sul personale e reagire. Tuttavia, egli sottolinea anche che è fondamentale comprendere la causa radice di un problema.

Vermorel afferma che i problemi legati ai dati sono probabilmente la causa principale del fallimento dei progetti di ottimizzazione della supply chain, ma la percezione dei “dati errati” è spesso fuorviante. Egli sostiene che la maggior parte delle aziende occidentali dispone di dati accurati da decenni, grazie all’uso dei codici a barre, dei lettori di codici a barre e di altre tecnologie. Il vero problema, secondo Vermorel, non è la qualità dei dati in sé, ma le difficoltà nell’accesso e nell’utilizzo degli stessi.

Una delle sfide chiave per utilizzare efficacemente i dati è riuscire ad accedervi. Molte aziende utilizzano da anni vari sistemi di enterprise resource planning, sistemi di gestione del magazzino (WMS), sistemi di gestione dei trasporti (TMS) ed altre soluzioni software, ma questi sistemi possono risultare difficili da gestire quando si tratta di esportare i dati. Vermorel individua alcuni scenari in cui l’accesso ai dati può essere particolarmente problematico:

1 Sistemi antichi: Alcune aziende usano ancora sistemi di 40 anni, con back-end obsoleti e proprietari che rendono l’estrazione dei dati estremamente difficile. 2 Mancanza di documentazione: I venditori di software potrebbero non fornire una documentazione adeguata per i loro sistemi, rendendo difficile comprendere e navigare tra le numerose tabelle e campi presenti nei database. 3 Responsabilità e accesso: Determinare chi è responsabile di concedere l’accesso ai dati può essere una sfida, in quanto coinvolge più portatori di interesse all’interno di un’azienda, compreso il venditore di software, dipartimento IT e i professionisti della supply chain.

L’intervista evidenzia l’importanza di comprendere e affrontare le sfide legate ai dati nei progetti di ottimizzazione della supply chain. Sebbene la qualità dei dati in sé non sia di solito il problema, le difficoltà nell’accesso e nell’utilizzo possono contribuire al fallimento di questi progetti. Identificare e affrontare le cause alla radice di tali sfide è essenziale per garantire il successo delle iniziative di ottimizzazione della supply chain.

Si addentrano nelle problematiche dei dati che possono emergere dalle relazioni con i venditori, dalle integrazioni di sistemi e dalla scalabilità man mano che le aziende crescono.

Uno dei problemi chiave di cui discutono è il potenziale conflitto di interessi con gli integratori, i quali potrebbero essere maggiormente interessati a vendere le proprie soluzioni di ottimizzazione della supply chain piuttosto che collaborare con il fornitore scelto dall’azienda. Ciò può portare le aziende a trovarsi prese in ostaggio dai loro integratori, rendendo difficile l’accesso o l’utilizzo efficace dei loro dati.

Un’altra sfida sorge durante la migrazione da un sistema Enterprise Resource Planning (ERP) a un altro, che può portare a una scarsa qualità dei dati o a una “garbage integration”. Sebbene le singole voci di dati possano essere accurate, il processo di migrazione dei dati storici tra sistemi può introdurre errori, poiché spesso non esiste una corrispondenza diretta uno a uno tra i dati dei vecchi e dei nuovi sistemi. Ciò può portare alla corruzione dei dati, che potrebbe non avere un impatto significativo sulle operazioni quotidiane, ma può riemergere come problema quando si tenta di ottimizzare la supply chain o di eseguire progetti di analisi dei dati.

L’intervista affronta anche le previsioni basate sui dati storici, che possono essere difficili a causa dell’incertezza intrinseca del futuro. Rilevare problemi nei dati storici è più semplice quando le problematiche sono evidenti, come gap o cambiamenti improvvisi nei dati. Tuttavia, cambiamenti sottili nella semantica o nelle definizioni nel tempo possono portare a problemi più difficili da individuare, in particolare durante la migrazione tra sistemi.

Man mano che le aziende crescono, la scalabilità può anche introdurre problemi relativi ai dati. Per le aziende più piccole, l’intero set di dati storici può spesso essere contenuto in uno smartphone, rendendo l’ottimizzazione meno preoccupante. Tuttavia, con la crescita delle aziende, il volume stesso dei dati può diventare un problema. La discussione sottolinea l’importanza di comprendere e affrontare questi problemi dei dati per ottimizzare efficacemente la gestione della supply chain.

Vermorel spiega che le aziende spesso faticano a estrarre i dati dai loro sistemi Enterprise Resource Planning (ERP), poiché questi sistemi non sono progettati per fornire incrementi quotidiani di dati puliti. Ciò si traduce in processi complessi, che possono portare a estrazioni di dati errate e introdurre anomalie. Il debug e la correzione di questi problemi possono richiedere molto tempo, arrivando a durare settimane invece di ore, a causa della quantità di dati coinvolti e dei lunghi tempi di elaborazione.

Molte aziende credono di disporre di dati di qualità, ma in realtà la semantica dei dati è spesso poco chiara. Questo può portare a malintesi e calcoli fuorvianti. Ad esempio, una “data d’ordine” può avere diverse interpretazioni, come il momento in cui l’ordine è stato effettuato dal cliente, il momento in cui è stato registrato nel sistema o il momento in cui il pagamento è stato confermato. Per evitare interpretazioni errate, Vermorel suggerisce che le aziende dovrebbero avere una documentazione dettagliata per ogni campo e tabella nei loro sistemi di dati, riflettendo la complessità della loro supply chain.

Un problema comune nell’ottimizzazione della supply chain è che i professionisti potrebbero non dedicare abbastanza tempo a qualificare i loro dati, portando i fornitori a lavorare con informazioni incomplete o poco chiare. Ciò può determinare una situazione di “garbage in, garbage out”, in cui i dati non sono necessariamente errati, ma vengono fraintesi a causa di una documentazione scarsa.

Per affrontare questi problemi, Vermorel sottolinea l’importanza di identificare la causa radice del problema, che solitamente coinvolge le persone e le strutture organizzative. Le aziende dovrebbero capire chi è responsabile del fallimento e lavorare per risolvere le questioni sottostanti, anziché limitarsi a incolpare i dati. I fornitori dovrebbero anche essere onesti riguardo alle sfide e al tempo necessario per chiarire la semantica dei dati, invece di essere eccessivamente ottimisti per chiudere accordi.

Le aziende devono investire in una documentazione adeguata, in una semantica dei dati chiara e in aspettative realistiche per ottimizzare la loro supply chain e prevenire fallimenti dovuti a problemi dei dati.

Trascrizione Completa

Kieran Chandler: Oggi su Lokad TV, andremo a comprendere perché questa diagnosi è così imprecisa e quali sono alcune delle sfide legate ai dati che possono essere incontrate sia dai fornitori di software sia dai professionisti della supply chain. Quindi, Joannes, perché i dati errati rappresentano una scusa così facile?

Joannes Vermorel: Innanzitutto, perché i dati non possono lamentarsi. Nessuno li difenderà, quindi incolpi qualcosa di inerte, il che è meglio che incolpare un collega che ce la prenderà sul personale e reagirà. Ma la realtà è che, andando alla radice del problema, sono sempre le persone a essere responsabili. Incolpare i dati equivale a saltare il passaggio dell’identificazione della causa radice del problema.

Kieran Chandler: È certamente facile criticare qualcosa che non reagirà. Quindi, come possiamo essere più precisi? Quali sono alcune delle sfide?

Joannes Vermorel: I problemi legati ai dati sono probabilmente la principale causa di fallimento nei progetti di ottimizzazione della supply chain. Ma ci sono alcune idee sbagliate. Quando le persone parlano di “dati errati”, intendono numeri corrotti o errati. Tuttavia, per la maggior parte delle aziende occidentali, i dati sono stati molto accurati per decenni. Quasi nessuno inserisce numeri di parte errati o commette errori di battitura. Utilizzano codici a barre, lettori di codici a barre e altri trucchi come l’RFID. Quindi, la quantità di dati veramente errati è solitamente una frazione molto ridotta, e non è sufficiente a spiegare perché la maggior parte delle iniziative che falliscono a causa di problemi legati ai dati falliscono in realtà.

Kieran Chandler: Se la stragrande maggioranza delle aziende occidentali raccoglie dati di buona qualità, quali sono alcune delle sfide che possiamo incontrare e che ci fanno pensare che i dati non siano così buoni?

Joannes Vermorel: Il primo problema è avere accesso ai dati. Sarete sorpresi. Le aziende operano da decenni utilizzando varie versioni di ERP, WMS, TMS o altri software aziendali per gestire le loro attività quotidiane. Ma la maggior parte di questi sistemi non è molto user-friendly quando si tratta di esportare i dati. In alcuni casi, si hanno sistemi così antichi da non avere nemmeno un adeguato database relazionale SQL a supporto del sistema. In una situazione del genere, è davvero difficile estrarre i dati perché il back-end è generalmente completamente obsoleto e proprietario.

Kieran Chandler: Quindi, di chi è la responsabilità di farlo?

Joannes Vermorel: Ci sono diverse responsabilità qui. In primo luogo, c’è il fornitore di software che non ha fornito una documentazione significativa sul sistema. Nei peggiori casi, apri il tuo database e ti accorgi che il tuo ERP contiene 2.000 tabelle, ciascuna con 20-200 campi, ed è un incubo. È completamente enorme, e non sai da dove cominciare. Anche se su chi cercare si può avere un problema con il fornitore, poi c’è il problema dell’integratore. Il problema con l’integratore è che potrebbe sussistere un conflitto di interessi. Alcuni integratori potrebbero essere fortemente interessati a venderti la loro ricetta per l’ottimizzazione della supply chain, per questo modulo o per quell’altro modulo o qualcosa del genere. E quando li chiedi fondamentalmente di eseguire per te un’estrazione dei dati, per le tue squadre interne o per qualunque iniziativa tu voglia portare avanti con un altro fornitore, l’integratore può – succede, l’abbiamo visto molte volte – essere semplicemente non collaborativo. Perché, ancora una volta, per loro è strategicamente nell’interesse non essere competitivi. E qui, ci troviamo in una situazione simile a una presa in ostaggio, dove l’azienda viene effettivamente presa in ostaggio dall’integratore. L’azienda, l’azienda IT responsabile della configurazione, a volte dell’hosting, e in generale della manutenzione dell’ERP o dell’altro sistema informatico dell’azienda. Quindi questo è un altro tipo di problema legato ai dati. Ma vedi, ha molto poco a che fare con i dati.

Kieran Chandler: Sì, decisamente. Non riuscire ad accedere ai propri dati sembra essere un ostacolo piuttosto enorme. E per quanto riguarda alcune delle altre sfide che possono verificarsi? Un grosso grattacapo che molti dei nostri clienti affrontano è quando migrano da un sistema ERP a un altro sistema ERP. Quindi, cosa può succedere ai dati?

Joannes Vermorel: Non si può semplicemente chiudere la questione a causa dei problemi. Quella è la situazione in cui puoi incorrere in un altro tipo di dati errati. Ma qui, il vero problema dei dati si manifesta quando c’è un’integrazione scadente. Quindi, direi che in genere le voci dei dati sono corrette, ma quando si passa da un ERP a un altro, ciò che il fornitore, o l’integratore, o magari il tuo reparto IT interno cercheranno di fare è fondamentalmente migrare i dati storici dal vecchio sistema al nuovo. Il problema è che non esiste una corrispondenza uno-a-uno tra, sai, quella che era una vendita registrata nel vecchio sistema e quella che è una vendita registrata nel nuovo sistema. Forse le cose sono semplicemente organizzate diversamente, e quindi non c’è un modo chiaro per riportare AR dal vecchio al nuovo sistema. E poi ti ritrovi con integrazioni tentennanti che possono portare alla corruzione dei dati, perché se, direi, effettui una reintegrazione impropria della tua storia, ciò non impedirà alla tua azienda di operare quotidianamente. Vedi, se i dati di East Oracle vengono importati in modo errato nel nuovo sistema, per la maggior parte delle operazioni quotidiane non avranno alcun impatto. E anche se dovessero avere un impatto, di solito qualcuno farà una riparazione veloce per sistemare l’errore e procederà. Quindi, potrebbe essere una fonte di attrito continuo, ma inizialmente scompare rapidamente, perché se le persone inciampano, per esempio, supponiamo che tu abbia codici fornitore importati in maniera errata. Voglio dire, le probabilità sono che non hai un milione di fornitori, quindi i tuoi 100 fornitori più frequenti probabilmente verranno corretti, risolvendo le voci errate, entro due settimane dalla data in cui inizi a utilizzare il nuovo sistema. E forse, dopo tre mesi, avrai praticamente corretto ogni singola voce fornitore errata. Ma il problema sono i codici storici: le persone non torneranno indietro a correggere i dati storici. Quindi, supponiamo che tu abbia circa cinque anni di storia, forse tre

Kieran Chandler: In futuro, quanto è facile individuare questi problemi che potrebbero essersi verificati in passato?

Joannes Vermorel: È facile notare quei problemi quando ci sono anomalie evidenti, come dati mancanti per alcuni mesi. Tuttavia, possono esserci cambiamenti sottili che risultano più difficili da individuare, come differenze nel modo in cui le vendite sono conteggiate, se includere o meno frodi o resi. Questo può portare a molti problemi difficili da scoprire nei dati storici, perché la definizione stessa dei dati che stai osservando è cambiata nel tempo, e non è evidente se non si verifica un picco o un brusco aumento.

Kieran Chandler: Un altro problema comune tra i clienti con cui parliamo è la scalabilità. Man mano che un’azienda cresce, i suoi dati iniziano a diventare più disordinati. Quali sono le problematiche che la scalabilità può introdurre?

Joannes Vermorel: Quando non ci sono problemi di scalabilità, puoi semplicemente copiare tutti i dati dell’azienda ogni singolo giorno. Per le aziende più piccole, questo può essere gestibile, dato che la loro intera storia potrebbe essere inferiore a 10 gigabyte. Tuttavia, quando si arriva a gestire aziende più grandi, finisci per avere molti più dati e devi optare per un recupero incrementale dei dati. Ciò significa estrarre una porzione dei dati ogni giorno, e alcuni sistemi non sono progettati per gestire questo in maniera efficiente o accurata. Così, devi ricorrere a operazioni complicate per costruire un’estrazione giornaliera pulita e, nel processo, ti espone a potenziali problemi.

Kieran Chandler: Quindi, alla fine, ti ritrovi con dati errati solo perché desideri eseguire l’estrazione dei dati in maniera incrementale, ed è complicato perché il sistema potrebbe non essere stato progettato per questo compito. Quando si parla di debug, tutto ciò che vuoi è copiare i dati da un posto all’altro, e può trattarsi di un problema molto banale. Se il processo richiede un minuto, qualcuno del tuo reparto IT può impiegare cinque minuti, avviare il processo e essere sicuro che funzioni. Tuttavia, se il processo richiede sei ore per essere completato, diventa un’operazione molto più laboriosa. Puoi spiegare le sfide in questa situazione?

Joannes Vermorel: Certo. Immagina di avere un sistema in cui il processo impiega sei ore per completarsi. Nel tuo reparto IT, qualcuno avvierà il processo, aspetterà 10 minuti, si renderà conto che sta impiegando troppo tempo e farà qualcos’altro. Potrebbero persino dimenticarsene. Il giorno successivo, potrebbero notare un piccolo bug che ha causato un arresto dopo sei ore. Per riprodurre il problema, occorrono altre sei ore di attesa. Di conseguenza, ti ritrovi con problemi che dovrebbero essere risolvibili in poche ore, ma a causa della maggiore complessità e dei tempi di elaborazione più lunghi, si trasformano in un processo davvero laborioso in cui il ritardo complessivo si prolunga per settimane. Non perché si tratti di settimane di lavoro, ma perché le persone avviano il processo, se ne dimenticano e poi riprendono il giorno dopo. Questo porta a iterazioni molto lente.

Kieran Chandler: Quanto diffusi diresti siano questi problemi? Ci sono molte aziende che credono di avere dati molto buoni, ma in realtà, se li osservi in profondità, non sono così ottimi?

Joannes Vermorel: Sì, c’è un altro problema di cui non abbiamo parlato, ovvero la semantica stessa. Molte aziende credono di avere dati buoni, ma in realtà i dati hanno una semantica sconosciuta. Quello che intendo dire è, per esempio, quando parliamo di una data d’ordine, esistono molte interpretazioni possibili. Potrebbe trattarsi della data d’ordine del cliente, del momento in cui l’ordine è stato piazzato sul sito web, registrato nel sistema o anche quando il pagamento è stato confermato come valido. Potrebbero esistere venti interpretazioni diverse su ciò che questa data d’ordine significhi.

Quando iniziamo a lavorare con i clienti, di solito ci imbattiamo in tabelle e colonne con scarsa documentazione. Ma quando abbiamo finito di preparare i dati, abbiamo quasi una pagina di documentazione per ogni campo, per ogni tabella. Una situazione tipica nella supply chain comprende circa 20 tabelle con 20 campi ciascuna, quindi stiamo parlando di circa 400 pagine di documentazione solo per chiarire cosa significhino i dati. Di solito le persone rimangono molto sorprese, ma è necessario per comprendere correttamente i dati.

Kieran Chandler: Joannes, puoi parlare dell’importanza di comprendere correttamente i dati nell’ottimizzazione della supply chain?

Joannes Vermorel: Sì, basta osservare la complessità della tua supply chain che si riflette in questi dati, e se non svolgi questo lavoro, ti ritroverai con dati che non comprendi correttamente. Quindi, si ha l’effetto garbage in, garbage out. Non è che i dati siano scadenti nel senso che i numeri siano sbagliati, ma non sai cosa significhino. Così, se hai una data che non comprendi appieno, qualunque calcolo o operazione di modernizzazione tu voglia effettuare finirà per portare a risultati fuorvianti. Pertanto, la semantica dei dati è la conclusione chiave, e la documentazione deve essere pronta prima ancora di iniziare un progetto.

Kieran Chandler: Allora, di chi è la colpa quando si tratta di semantica?

Joannes Vermorel: Direi che dovrebbero esserne responsabili i practitioner della supply chain. La maggior parte di loro direbbe che è un problema IT. Ma il modo in cui interpreti la semantica dei dati dipende davvero dal processo che hai in atto. Se hai un processo in cui scansioni i prodotti all’ingresso del magazzino – e questo viene gestito dal reparto IT – loro non sono in prima linea nel magazzino, quindi non sanno esattamente come è strutturato il tuo processo. Le uniche persone che sanno esattamente sono quelle che operano direttamente nel sistema, perché questi dati sono semplicemente il risultato di un processo. Quindi, il mio punto è: non aspettarti che l’IT, che si limita a gestire le macchine e a garantire che il software disponga di sufficiente memoria, larghezza di banda e spazio su disco, abbia gli spunti, le competenze e la comprensione necessari per interpretare il significato dei dati. Quello che significano i dati è tipicamente un problema molto specifico per il business. Non è affatto un problema IT. Dunque, tipicamente, la colpa ricade spesso anche sui practitioner. Questi non hanno dedicato abbastanza tempo a qualificare adeguatamente i dati con le proprie parole e la propria comprensione. Così, quando si tratta di ottimizzazione della supply chain, ti ritrovi con un fornitore che tratta i dati in modo parzialmente cieco. E questo porta a un effetto di garbage in, garbage out.

Kieran Chandler: Quindi, il fornitore può essere colpevole anche lui?

Joannes Vermorel: Sì, ovviamente, anche il fornitore può essere in parte responsabile. Aziende come Coke Ad, che si occupano di ottimizzazione della supply chain, e tipicamente quando la colpa ricade sul fornitore, è perché questi cerca di apparire elegante. Di solito cerca di minimizzare la sfida perché sta cercando di vendere un problema. Discutono approcci tipo: “Fidati di noi. Sarà un gioco da ragazzi. Lo faremo in poche settimane. Boom, lo faremo così e funzionerà.” La realtà è che se dici a un direttore della supply chain, “temo che solo per qualificare i tuoi dati ci vorranno sei mesi e, mi dispiace, avresti dovuto farlo, ma non l’hai fatto, quindi dovremo farlo noi per te,” ovviamente è difficile concludere un accordo simile. Quindi, è molto più facile essere eccessivamente ottimisti, ma questa è una ricetta per il fallimento. Poi il fornitore dovrà prendersi la colpa perché avrebbe dovuto sapere meglio. Forse il cliente non sa meglio perché è la prima volta che tenta un progetto di ottimizzazione quantitativa predittiva della supply chain. Ma il fornitore, che per definizione probabilmente non è la prima volta che lo fa, dovrebbe sapere meglio. Così, se la situazione diagnostica è quella in cui questo tipo di dati è inesistente, allora dovrebbero

Kieran Chandler: Dovrebbero fondamentalmente avvisare il cliente che saranno necessari, magari, diversi mesi di lavoro solo per chiarire la semantica dei dati, affinché questi possano essere qualificati come buoni. Ma non era che fossero veramente cattivi all’inizio. Quindi, buono non è l’opposto di cattivo in questa situazione; è solo che buono è più simile all’opposto dei dark data, dei dati non qualificati o dei dati disordinati.

Joannes Vermorel: Ok, e per concludere oggi, esiste una vasta gamma di problemi diversi che rientrano sotto l’ombrello dei dati errati. Direi che è importante cercare di identificare la causa principale del problema, e di solito si tratta delle persone. Voglio dire, ovviamente, quando dico che il problema sono le persone, non si vuole incolpare James del reparto IT per essere responsabile del pasticcio. Ma quando dico che il problema sono le persone, devi capire esattamente chi detiene la responsabilità del fallimento, e forse quella persona è stata messa in una situazione in cui non aveva altra scelta se non fallire.

Vedi, potresti concludere che James del reparto IT ha fallito, ma anche che l’organizzazione stessa ha messo questo povero James in una posizione nella quale non aveva altra opzione se non fallire, parlando realisticamente. Quindi, è interessante che inizi a vedere il problema da un punto di vista che almeno ti fornisce degli indizi su come risolverlo, invece di dire semplicemente che i dati erano cattivi, troppo cattivi, dati mal gestiti. E poi, se intraprendi un’altra iniziativa, ripeteresti esattamente lo stesso problema, gli stessi errori, e quindi finiresti per ottenere lo stesso fallimento alla fine della giornata.

Kieran Chandler: Okay, beh, se il capo di James sta guardando, spero che sia comprensivo. Comunque, questo è tutto per questa settimana. Grazie mille per averci seguito, e ci vediamo alla prossima. Ciao per ora.