00:00:00 Introduzione
00:03:17 Perche esistono i forward deployed engineers?
00:09:48 Perche i progetti IA falliscono nelle grandi aziende
00:13:35 Il supporto esperto indebolisce il software plug-and-play?
00:18:33 Il trend FDE valida l’approccio di Lokad?
00:22:55 Automazione contro decisioni consequenziali
00:28:07 Come un Supply Chain Scientist approccia un nuovo cliente
00:32:26 Valutare gli esperti su orizzonti lunghi
00:36:12 L’adozione del prodotto e la giusta metrica di successo?
00:40:06 Perche l’automazione e un problema da zero a uno
00:43:09 Impatto finanziario contro impatto economico
00:48:05 Perche il processo decisionale richiede expertise di dominio
00:52:32 Come Lokad identifica validi Supply Chain Scientists
00:55:22 Automazione ospedaliera contro decisioni mediche
00:57:09 Gli FDE smentiscono i moduli di ottimizzazione plug-in?
00:58:43 Il problema dei costi dei servizi FDE
01:01:04 Conclusione
Riepilogo
Conor Doherty e Joannes Vermorel esaminano perche i forward deployed engineers sono diventati una delle ultime tendenze del software enterprise. Discutono la carenza di talenti e le iniziative IA fallite che ne alimentano l’ascesa, distinguendo l’automazione ordinaria dalle decisioni finanziariamente rilevanti. Joannes sostiene che l’automazione dovrebbe eliminare completamente il lavoro, mentre i sistemi decisionali richiedono manutenzione continua, giudizio economico e profonda expertise di dominio. La conversazione confronta gli FDE con i Supply Chain Scientists di Lokad, mette in discussione l’adozione come metrica di successo ed esplora se il costoso supporto umano riveli i limiti del software enterprise presumibilmente plug-and-play.
Trascrizione completa
Conor Doherty: Allora, sono quasi le 18, che a Parigi e praticamente notte. Quindi si, stiamo davvero lavorando sodo in Francia, secondo gli standard francesi. Sono quasi le 18 qui a Parigi e Joannes e io abbiamo appena finito il podcast sui forward deployed engineer. E venuto fuori in modo piuttosto diverso da come pensavo.
Ovviamente avevo preparato le mie domande, ma poi la conversazione si e evoluta. Pensavo che avremmo parlato soprattutto di cosa sia un forward deployed engineer e se si tratti o meno di hype. Invece abbiamo coperto anche questo, ma siamo entrati anche in discussioni su come valutare l’offerta di un FDE nel software enterprise, su quale dovrebbe essere davvero l’uso di questo ruolo, e sul confronto con la posizione di supply chain scientist in Lokad. Quindi si, mi e piaciuto molto. Spero piaccia anche a voi, e fatecelo sapere su LinkedIn.
Potete connettervi con Joannes e con me se volete fare altre domande. Ma ora torno a casa. Buona conversazione. Joannes, grazie per essere qui.
Ti ho portato qui oggi per discutere dell’ascesa dei forward deployed engineer. Ora, mi sono documentato. Non e una posizione nuova. In realta affonda le sue radici nell’esercito, ma nei circoli del software, e in particolare del software enterprise, e una posizione molto recente.
E giusto per dare un po’ di contesto sulla scala di cui parliamo, questa mattina ho letto che AWS sta investendo circa un miliardo, anzi poco piu di un miliardo di dollari, per costruire il proprio dipartimento di forward deployed engineer, o FDE. Y Combinator, il famosissimo acceleratore, attualmente, quindi in questo momento, il 27 agosto, ha piu di 100 startup che cercano questi ruoli specifici: non ingegneri, ma forward deployed engineer. Che cos’e, in termini semplici? Ho sintetizzato alcune definizioni, perche ovviamente variano, ma a grandi linee un forward deployed engineer, o FDE, e un software engineer a contatto con il cliente che lavora direttamente dentro o con il team del cliente, fisicamente o da remoto, per costruire, personalizzare e rilasciare software complesso per risolvere problemi complessi del mondo reale. Ora, come sono sicuro sia venuto in mente a te, e a me nel momento in cui l’ho letto, e come sono sicuro sia venuto in mente a chiunque conosca Lokad, questo suona molto simile a un supply chain scientist. Ci sono differenze, ci arriveremo dopo, ma la mia prima domanda, ad alto livello, e questa.
Siamo al quarto anno del boom dell’AI. ChatGPT e uscito nell’autunno 2022, ora siamo quasi nell’autunno 2026. Sembra passato meno tempo, ma sono quattro anni. Abbiamo AI che scrive il proprio codice in molti contesti, eppure siamo arrivati di nuovo, come se il tempo fosse un cerchio piatto, allo stesso punto.
Siamo tornati a: “Se vuoi che questa cosa funzioni, devi assumere il mio esperto che venga da te e la faccia funzionare.” Joannes, perche questo ruolo esiste ancora oggi?
Joannes Vermorel: Si, voglio dire, stiamo chiudendo il cerchio e tornando al tipo di configurazione che storicamente fece la fortuna di IBM. L’idea del forward deployed engineer era praticamente la configurazione predefinita di IBM negli anni 70 e 80: mandare molti ingegneri, direi, sul posto dal cliente per installare il mainframe. Quello era, direi, il modello standard.
In realta, negli ultimi due decenni ci siamo allontanati da questo, e ora sta tornando con forza. La mia interpretazione generale del perche stia tornando e che ci sono molte forze in gioco, ma una di esse e semplicemente l’effetto sociologico delle assunzioni. Alcune aziende sono incredibilmente brave ad attrarre talenti rispetto ad altre. E se, diciamo, credo di aver letto qualche anno fa che circa quattro milioni di persone facevano domanda a Google ogni anno.
Era un’informazione di circa dieci anni fa. Probabilmente l’ordine di grandezza e ancora quello. La cosa interessante e che alcune aziende hanno successo e altre no. E come piccolo dato del tutto aneddotico, quando in Lokad pubblichiamo un’offerta su LinkedIn, vedo molto spesso che abbiamo molti piu candidati di aziende molto grandi, con oltre 100.000 dipendenti, quando pubblicano un ruolo comparabile.
Conor Doherty: Ti riferisci specificamente al ruolo di supply chain scientist?
Joannes Vermorel: Si, su LinkedIn lo presentiamo come business analyst.
Conor Doherty: Ah, giusto.
Joannes Vermorel: Perche altrimenti le persone al computer non sanno nemmeno davvero di cosa stiamo parlando. Quindi quando pubblichiamo su LinkedIn, lo chiamiamo business analyst e di solito otteniamo molti piu candidati di aziende estremamente grandi. Quello che vedo in generale e che ci sono aziende di ogni dimensione che riescono ad avere enorme successo nell’attrarre tantissimi talenti, e molte altre, tipicamente piu vecchie e piu grandi, che non ci riescono. Questo crea una naturale inclinazione a dire: se possiamo assumere tutte queste persone, o piu di queste persone che fanno domanda da noi, allora possiamo rivendere i loro buoni servizi a quei clienti. E se si puo combinare questo con una piattaforma software, allora si vende il tempo di quelle persone brillanti che si riescono ad assumere, e in piu si aggancia l’azienda cliente a qualunque tecnologia fondazionale si stia vendendo. A quel punto puo diventare una mossa molto redditizia per un periodo molto lungo. Se parliamo di AWS, parliamo di persone che aiuteranno i clienti ad adottare l’offerta cloud, le soluzioni cloud offerte da Amazon. E sara lo stesso se si prendono forward deployed engineer da Palantir: quelle persone costruiranno sulla piattaforma Palantir. In una certa misura, in Lokad e simile: i supply chain scientist costruiranno sulla piattaforma Lokad. Ma fondamentalmente penso che la forza sottostante, piu grande della tecnologia, sia questo effetto sociologico: sembra che i talenti si riversino verso alcune poche aziende che ricevono un numero enorme di candidature, mentre molte altre ne ricevono pochissime. Cosi si finisce, in un certo senso, con aziende che accumulano talento, e poi nasce questa inclinazione naturale a dire: posso assumere solo cio di cui ho bisogno, oppure posso decidere di espandermi e usare il fatto di essere cosi bravo ad attrarre talento per rivendere questi talenti ingegneristici ai clienti.
Conor Doherty: E vero. Di nuovo, ovviamente e multivariato.
Joannes Vermorel: Si.
Conor Doherty: Un altro filone su cui vale la pena concentrarsi, e torna di nuovo all’idea che il tempo sia un cerchio piatto. Credo fosse 18 mesi fa quando abbiamo fatto un evento live sul divario di valore dell’AI generativa. Avevamo fatto un episodio registrato qualche mese prima. Parlavamo del fatto che c’e molta ricerca, anche da parte di grandi societa di consulenza, che dice che molti progetti in cui le persone stanno investendo centinaia di milioni di dollari, prima di tutto, non vengono adottati e, in secondo luogo, non generano alcun valore. Preparandomi a questo, sono tornato a vedere quante delle mie note di allora siano ancora rilevanti oggi. Sorpresa: tutte. In effetti, c’e stato uno studio del MIT l’anno scorso su 400 aziende, grandi aziende statunitensi, e il 95% ha dichiarato che il denaro speso in progetti AI non aveva prodotto nulla.
La formula era: nessun impatto misurabile. Molte di queste posizioni di forward deployed engineer sono molto strettamente associate al far funzionare i progetti AI. Sono sicuro che ci siano applicazioni di nicchia in cui si dice: no, voglio solo far partire il mio system of record e mando qualcuno a farlo. Ma molto spesso OpenAI, Anthropic, persino persone nel nostro ambiente di business, vendono progetti AI con il FDE: il FDE fara funzionare il progetto AI nel vostro contesto.
Quindi hai parlato di accumulare talento, certo, ed e quasi come un investimento in un bisogno futuro. Ma allo stesso tempo, almeno secondo molte istituzioni, c’e un bisogno molto presente, perche molti progetti AI su cui le aziende spendono, un po’ alla cieca, milioni di dollari non aggiungono nulla. E il mercato ha detto: sapete cosa, ho un esperto che vi aiuta a sistemarlo. Questo risuona con te?
Joannes Vermorel: Si, ma attribuirei la causa principale a qualcosa di un po’ diverso.
Conor Doherty: Okay.
Joannes Vermorel: Le grandi aziende, tutte le aziende, di solito hanno padroneggiato e calibrato completamente l’esatta quantita di competenza e abilita necessaria per ogni singola posizione. Di conseguenza, si finisce con una piramide in azienda in cui gran parte della piramide e riempita da persone che sono esattamente al loro picco di competenza. Vedi, e il principio di Peter: vieni promosso finche raggiungi il tuo punto di incompetenza.
Ora immagina un’azienda di 50.000 persone in cui quasi tutti sono esattamente al limite dell’incompetenza. Non sono incompetenti, sono appena sotto. Ora introduci una tecnologia che di per se non e cosi complicata, ma e chiaramente una complicazione in piu. Ti rendi conto che letteralmente quasi tutta la piramide e troppo sollecitata, perche e qualcosa che li porta fuori dalla loro zona di capacita. E un po’ duro, ma pensa a un’azienda che esiste da decenni: di solito e riuscita a spremere ogni singola percentuale di redditivita dalla propria struttura dei costi. Quindi, se impiegavi persone piu competenti di quanto fosse davvero necessario, quello era denaro lasciato sul tavolo. Molte aziende, nel corso di molti decenni, finiscono per effetto delle forze naturali del mercato per eliminare ogni surplus di competenza. Questa e la mia prospettiva tipica sul caso. Percio, quando arrivano tecnologie software dirompenti, finiscono per aver bisogno di supporto. Se provano a implementarle internamente, faticano, perche praticamente tutti nella piramide sono gia al massimo di cio che possono gestire. Se aggiungi un’altra cosa, diventa ingestibile e non ci riescono. Ecco perche penso che molte iniziative AI falliscano: servono persone con molto margine, in termini di intelligenza, competenza e capacita, oltre al loro lavoro attuale, per poter ripensare il futuro del proprio lavoro quando si inserisce l’AI. Con le tecnologie AI, di solito cio che succede e che bisogna ripensare il lavoro. Poi si puo farlo con una produttivita potenzialmente 10x, ma questo richiede un ripensamento molto attento, molto oltre cio che storicamente serviva solo per mantenere lo status quo.
Conor Doherty: Mentre lo dicevi, mi si e cristallizzato un pensiero. Non l’avevo scritto, ma provo a tirarlo fuori. L’idea dell’AI, almeno come e stata venduta, e: automatizziamo il piu possibile, e saremo anche in grado di scalare molto oltre cio che era necessario o possibile usando, diciamo, una forza lavoro umana, o certamente cio che una persona poteva fare. Ora siamo nella fase in cui, se vuoi che l’AI funzioni, devi avere qualcuno con molto margine di competenza per farla funzionare.
Joannes Vermorel: Si.
Conor Doherty: Questo non invalida, o almeno non mina, l’intero concetto del “paga e collega”, del comprare software pronto all’uso e via, perche ora devi comprare qualcun altro per farlo funzionare per te?
Joannes Vermorel: Si. Ti faccio un aneddoto recente. Stavo contattando il mio operatore mobile tramite la loro hotline. Un’esperienza meravigliosa. Storicamente avevano i primi due minuti esasperantemente lenti di disclaimer legale, che non mi interessa, e poi “Premi uno per questo, premi due per quello” e cosi via.
Avevano il labirinto di numeri per raggiungere la cosa che volevi raggiungere e alla fine un operatore, perche nessuno dei percorsi portava da nessuna parte. E anche quello era un po’ rotto. Quello che bisogna immaginare e che gli ingegneri, facendo del loro meglio in questa azienda, riuscivano a malapena a mantenere quello che era un albero decisionale con numeri per indirizzare le persone. Quello era gia il loro picco ingegneristico, e gia fallivano un po’. Ora hanno recentemente rinnovato il sistema con un’AI. Questa AI ha il peggior riconoscimento vocale possibile. Non capisce niente.
Mi ci sono voluti circa 20 minuti a discutere con questa maledetta AI prima di riuscire finalmente ad avere un operatore, perche quello che volevo fare non era possibile con quel sistema. Era un errore ingegneristico epico. Ma la realta e che era molto prevedibile. Se hai persone gia al limite della loro capacita ingegneristica quando si tratta di costruire un albero decisionale, e quello e gia una sfida per loro, se chiedi loro di costruire qualcosa come un triage fluido basato su AI per le chiamate in arrivo, sara pessimo. Ed era molto interessante perche tutto era pessimo: il riconoscimento vocale era terribile, si percepiva che lo script e la base di conoscenza con cui dovevano gestire la situazione erano pessimi.
Quindi era un problema multilivello in cui ogni singolo pezzo di software era pessimo. Il riconoscimento vocale che avevano scelto era pessimo. La sintesi vocale era pessima. L’LLM che avevano scelto era pessimo.
La base di conoscenza con cui avevano alimentato l’LLM era pessima. Era, di nuovo, un software pessimo a piu livelli. E se torniamo al perche fallisce: immagina di avere una situazione in cui l’IT sta gia faticando a fare cose molto semplici e a farle funzionare. E conosco le persone che lavorano nell’IT di quella specifica azienda: non sono proprio i piu brillanti.
E il tipo di azienda che fatica immensamente a ottenere qualcuno di decente da qualunque scuola di ingegneria in Francia. Quindi non sorprende che qualsiasi tentativo con l’AI sara una catastrofe. E quindi il fatto di dover portare aiuto e semplicemente la conseguenza del fatto che, appena introduci novita, i tuoi team non riusciranno a gestirla perche riescono a malapena a gestire lo status quo.
Conor Doherty: Si.
Joannes Vermorel: E anche lo status quo e gia molto tirato.
Conor Doherty: Avevo scritto la parola flusso prima, ma novita e meglio, perche credo catturi davvero lo spirito di uno dei maggiori fattori differenzianti qui. Storicamente Lokad ha sempre abbinato l’idea che hai il software, ma hai anche l’esperto. E il motivo per cui hai l’esperto e che la tua supply chain sara piena di sfumature e casi limite che emergeranno. Ovviamente ci sono decisioni quotidiane banali, ma saranno governate da molto flusso. Non e mai stato: si, compralo semplicemente pronto all’uso.
Tutto il marketing e, in realta, la funzione effettiva del servizio era: questo deve essere costruito attorno ai tuoi problemi, attorno alla tua realta. Il nostro supply chain scientist deve interagire con te per costruire il livello decisionale.
Joannes Vermorel: Si.
Conor Doherty: Vedi l’emergere del ruolo FDE in aziende simili, e parliamo di pari, concorrenti, qualunque cosa, come una conferma del fatto che hai sempre sostenuto che tutto debba essere costruito da zero? Che non si possa avere codice copia-incolla per tutto?
Joannes Vermorel: Si e no. Prima di tutto, la realta e che quasi tutti i problemi che si incontrano quando si entra nel regno del software enterprise consistono nel incollare software insieme. Vedi, e quasi tutto il problema. Si, puoi avere un LLM pronto all’uso laggiu.
Puoi avere un web server pronto all’uso laggiu. Puoi avere un database transazionale pronto all’uso laggiu. Ma devi incollare queste cose. E poiche la tua azienda esiste da 50 anni, hai decenni di cose gia in piedi. Quindi non hai il lusso di dire: “Collego questo prodotto e funziona.”
Quella e una situazione greenfield che funziona in una PMI. Non funziona nello spazio enterprise. Quindi, per essere equi con il mercato, l’idea di usare molti consulenti e integratori per fare questo plumbing personalizzato esiste da molto tempo. Le persone erano molto realistiche.
Qui la differenza principale, penso, riguarda l’automazione. Questa e la differenza chiave. Di solito, se si tratta solo di configurare un system of record e raccogliere il tuo system of record, si poteva farlo con integratori che erano tipicamente bravi con i system of record. Quelle cose non sono davvero intelligenti. Anche in termini di design software sono fondamentalmente applicazioni CRUD: create, read, update, delete. E quanto piu vanilla possibile.
Hanno una funzione semplice: mantenere i record. Ma l’automazione e un’altra cosa. Noi ci concentriamo sulle decisioni, ma anche prima delle decisioni ci sono moltissime cose che sono solo automazioni di base. E qui vedo molti ostacoli all’automazione, soprattutto perche ogni volta che c’era un campo di testo libero, un dato non strutturato, un’immagine, qualunque cosa, ci si bloccava e bisognava mettere un umano nel loop. Ora, con queste tecnologie AI, quasi tutta l’automazione banale diventa possibile. Non sto nemmeno parlando del vero livello decisionale come Lokad.
Sto dicendo cose come: un cliente deve mandare una copia della carta d’identita. Bene, ricevi un’immagine. E un’immagine di una carta d’identita? Si.
No. Se non puoi avere un sistema che dica se e un’immagine di una carta d’identita, si o no, allora hai bisogno di un umano che guardi e stia in mezzo. Quindi questa automazione, credo, e molto piu ampia delle decisioni. E letteralmente fatta di tutti i passaggi super granulari dei tuoi processi, e la maggior parte e molto poco consequenziale. Devono solo essere fatti, e quello che vuoi e che vengano fatti senza un umano nel loop, sapendo che e una cosa incredibilmente banale. La posta in gioco non e altissima, e molto diretta. Ma se guardi solo al paradigma CRUD, create, read, update, delete, quel paradigma non ti da un modo per automatizzare questo. Serve qualcosa in piu. Ed e qui che penso che i forward deployed engineer possano fornire molto valore: fornendo essenzialmente l’intelligenza necessaria per automatizzare oltre il CRUD, perche la maggior parte degli integratori non e capace di fare nulla oltre il CRUD.
Conor Doherty: Assolutamente. E un punto che vale la pena chiarire. Il contesto della discussione qui, almeno per la maggior parte, e certamente per quanto riguarda il confronto con il livello di Lokad, il livello di system of intelligence: la stragrande maggioranza della ricerca che ho fatto, dei lavori che ho esaminato, consisteva fondamentalmente nel costruire codice AI che aiutasse le persone a prendere decisioni. Quindi, prendendo l’esempio dell’ERP come system of record: quello e un system of record.
Hai i tuoi dati transazionali. Come passi da li a quali decisioni dovrei prendere oggi, domani, eccetera? E li che molte persone stanno usando i forward deployed engineer, o almeno nello spazio del software enterprise. E li che vengono inseriti.
E nel loro linguaggio e essenzialmente una missione. Entri, puo durare sei mesi, un anno, due settimane. Al contrario, quando parli del supply chain scientist, non e una cosa a breve termine. E una relazione continuativa per ragioni molto specifiche.
Joannes Vermorel: Si. Di nuovo, soprattutto perche la quasi totalita di cio che il mercato considera forward deployed engineer non riguarda decisioni. Stanno solo automatizzando il banale. La decisione e gia stata presa.
La domanda e letteralmente solo: automatizzare. E quando dico automatizzare, pensa a cose che possono essere molto semplici. Per esempio, c’e un record che appare su uno schermo e in certe situazioni deve essere copiato e incollato nel software A, in altre nel software B, e il confine tra i due casi e un po’ sfumato e poco chiaro. Quella e la situazione in cui, boom, forward deployed engineer. Se puoi avere una regola iper-semplice che puoi codificare in Excel, non hai bisogno di quelle persone. Ma se e piu sfumato, allora si, potresti averne bisogno. La mia idea e che la redditivita si ottiene solo quando rimuovono persone dal quadro. Se non c’e un guadagno netto sostanziale di produttivita, non ci sara ritorno sull’investimento. E ancora, se dici che la missione ha un limite temporale, per definizione non stai trattando decisioni.
Conor Doherty: E un punto corretto.
Joannes Vermorel: Si, e un punto corretto. Una decisione, qualcosa a cui sono associati interessi finanziari, deve essere monitorata e rivista. Ed e per questo che i supply chain scientist non evaporano.
E per questo che, quando iniziamo un’iniziativa con un cliente, rimangono li. Se scrivi una ricetta numerica che puo letteralmente spendere milioni di dollari al giorno, lo fara, perche se raccomandi cosa riordinare, hai una ricetta numerica che ti da la lista dei riordini. E letteralmente la lista della spesa. Sono dollari che spenderai a causa di questa ricetta numerica. Deve essere mantenuta, perche non mantenerla sarebbe follia.
A un certo punto ci sara un cambiamento di mercato. Invalidera le assunzioni fatte dalla ricetta numerica e sara un disastro. Quindi la manutenzione e ovviamente necessaria, e serve qualcuno di intelligente per farla. Ma se parliamo di automazioni di base, allora no. Puoi avere qualcosa per cui serve qualcuno di intelligente per costruire l’automazione, ma poi quell’automazione puo funzionare praticamente fino alla fine dei tempi.
Per esempio, diciamo che vuoi fare riconoscimento di assegni, con grafia manuale. Una volta che hai un setup capace di riconoscere la grafia, puo funzionare quasi indefinitamente. Ma fondamentalmente non e qualcosa con posta in gioco alta. E solo riconoscimento della grafia: conservi l’immagine, hai il riconoscimento e puoi avere l’automazione.
Va bene. Non devi necessariamente tenere vicino l’ingegnere che ha progettato l’algoritmo di riconoscimento della grafia.
Conor Doherty: Mi viene in mente che una dimensione centrale che vale la pena esplorare qui e se stai assumendo un FDE tramite un’altra azienda o stai lavorando con Lokad e hai un supply chain scientist. Il punto e che stai introducendo un esperto che in quel momento non conosce davvero la tua azienda, non ha il codice scritto, o non dovrebbe averlo scritto, perche deve intervistare, deve capire la supply chain per estrarre queste informazioni e presumibilmente applicare competenza di dominio. Si, non credo siamo in posizione di commentare come un FDE faccia questo. Noi non abbiamo FDE.
Come si approccia un supply chain scientist a questo? Quindi e il primo giorno, parla con i clienti. Sulla carta sembra molto semplice: parlare con le persone, ottenere informazioni. Ma qual e il tipo di informazione, in un contesto supply chain, rilevante perche un FDE o un SCS inizi a costruire codice? Puoi scegliere qualunque problema giocattolo tu voglia.
Joannes Vermorel: Nel nostro caso, in Lokad, quello che il supply chain scientist deve fare e essenzialmente mappare il panorama applicativo. Sara una discussione tecnica con l’IT, per capire quali dati sono disponibili. La regola e: i dati sono quello che sono. Quindi non lamentarti. L’azienda riesce a operare con questi dati. Quindi l’assunzione predefinita e che siano sufficienti.
Non sono mai perfetti, ma sono sufficienti. Quindi si mappa il panorama. Questa e davvero una grande parte. E poi l’altra parte e capire cosa l’azienda stia effettivamente facendo per il mercato, con i suoi partner, e come tutto cio debba essere quantificato per avere un modello economico dell’azienda.
Deve avere senso, perche il supply chain scientist sara responsabile di creare una ricetta numerica. Questa nuova ricetta numerica consumera i dati. Questo e il primo punto. Ma poi, alla fine, valutera tutte le diverse opzioni che abbiamo in euro o in dollari.
E per avere una valutazione che non sia fasulla, serve una profonda comprensione del business. Bisogna capire cosa e realmente apprezzato dai clienti. Quali vincoli sono davvero dolorosi per i fornitori. Dove sono i colli di bottiglia nella supply chain.
Cosa conta come risorsa scarsa. Tutto e scarso, si, ma alcune cose nella supply chain possono esserlo molto di piu. Si puo essere bloccati in punti molto specifici. Quindi bisogna esserne consapevoli.
E poi bisogna essenzialmente modellare anche tutte le forze che hanno effetti duraturi ma sono difficili da valutare immediatamente. Un esempio sarebbe: se vendi sopra il prezzo dei concorrenti, a parita di tutto il resto, allora ci sara attrito nel tempo. Perderai gradualmente quote di mercato. Se, a parita di tutto il resto, sei solo un po’ piu caro dei concorrenti, nel tempo, a meno che il mercato non sia regolato o qualcosa del genere, i clienti andranno dai concorrenti.
Ma questo sara invisibile nell’arco di settimane, perche ci sono molte abitudini e cosi via. Quindi il supply chain scientist e li per avere una prospettiva intelligente di lungo periodo sull’economia dell’azienda, facendo leva sui dati, ma senza essere cieco agli effetti di lungo periodo che possono solo essere compresi e, direi, stimati, perche non possono mai essere davvero misurati. Non faremo esperimenti lungo un decennio. Ci sono molte cose che possono venire solo da una comprensione ad alto livello. Un esempio: se fai hard luxury, non vuoi mai dare sconti a nessun cliente. Se vendi un orologio costoso, vuoi dire al cliente: non stai spendendo denaro, questo e un investimento. Questo orologio varra ancora di piu tra dieci anni. Che sia vero o no e un’altra questione, ma certamente, se inizi a fare sconti, non puo essere vero. Ecco perche molte cose devono venire da una comprensione ad alto livello, e non farai esperimenti con i clienti per valutarle.
Conor Doherty: Ah, quindi tu…
Joannes Vermorel: No.
Conor Doherty: Ah, perche avevo scritto orizzonti. Voglio parlare di valutare, di nuovo valutare l’impatto dell’esperto. Che sia un FDE o un SCS e irrilevante per la discussione, ma hai citato un ottimo esempio e mi ha fatto venire in mente qualcosa che ho sentito in ufficio un paio di giorni fa. Non diro chi, ma si parlava di aerospazio, di ordini di acquisto per motori.
Il punto con questo cliente e che e un impegno pluriennale per definizione. Non entro nei dettagli perche potrebbe essere di dominio pubblico, ma comunque stanno comprando, diciamo, 10 motori. E l’orizzonte temporale per questo progetto su cui lavorano e circa cinque anni. Quindi fra cinque anni sapranno realisticamente se il 27 agosto sia stata una buona idea comprare tutti quei motori.
Se hai un FDE, quella persona se ne e andata da tempo. Ma se lavori ancora con Lokad, almeno c’e continuita nella valutazione.
Joannes Vermorel: Si. E vale in entrambe le direzioni. La mia opinione e che gli FDE dovrebbero produrre guadagni di produttivita che possano essere valutati letteralmente e pienamente il giorno in cui termina la missione.
Conor Doherty: Okay.
Joannes Vermorel: Hai quindi un processo che dovrebbe essere automatizzato. Passi potenzialmente da 100 persone a zero per fare il lavoro, e forse una per supervisionare. Questo e il deliverable. Quindi l’FDE, ancora una volta, poiche non siamo al livello decisionale, non ha quel tipo di posta in gioco.
Automatizzi completamente le cose. Rimuovi le persone, e questa e la condizione di successo. Non ce n’e un’altra. Posso avere questo lavoro, che era fatto da 100 persone, fatto essenzialmente da zero persone con un po’ di supervisione IT per assicurarsi che le cose continuino a funzionare senza intoppi? Questo e tutto. Un esempio che abbiamo fatto in Lokad e la traduzione del nostro sito web in molte lingue: ora e completamente automatizzata. La domanda e solo monitorare l’automazione, non fare i traduttori.
Conor Doherty: Noi pero abbiamo decisioni.
Joannes Vermorel: Capisco. E esattamente quello che dico: gli FDE non tratteranno decisioni. Pensalo come la traduzione, che e un compito molto migliore come esempio. Si, richiede intelligenza. Si, e il tipo di cosa che non puoi fare con una configurazione grezza. Create, read, update, delete nel tuo database SQL non puo tradurre. Questo e cio in cui gli FDE sono bravi. Prendi un processo molto ben definito. Sai cosa dovresti ottenere alla fine della pipeline. E cio che reingegnerizzi e semplicemente rimuovere le persone dal percorso critico. Robotizzi quel pezzo.
E di nuovo, il motivo per cui la missione puo finire e che non c’e una decisione coinvolta. Nessuna vera decisione. Non nel senso che definisco in questo libro, cioe un’allocazione di risorse. Non c’e allocazione di risorse.
E solo un processo in cui qualcosa doveva essere fatto e ora viene fatto sostanzialmente senza presidio. Non c’era una posta in gioco specifica. Doveva essere fatto, e ora viene fatto automaticamente, restando conforme a qualunque sia il tuo obiettivo di qualita. Tutto qui.
Conor Doherty: A proposito di obiettivi di qualita, il punto successivo era, e di nuovo non faro nomi, ma consiglio vivamente a chiunque ascolti di cercare “deployed engineers”, la propria citta e poi la parola “jobs”, e capirete di cosa parlo. Sto dando una descrizione rappresentativa dei criteri di valutazione per un FDE secondo molte aziende che pubblicizzano queste posizioni. Si tratta dell’adozione dei prodotti. Ora, non e banale, ovviamente, perche se costruisci qualcosa e letteralmente nessuno lo usa, e un problema.
Potrebbe essere il miglior software decisionale del mondo, ma se nessuno lo usa e un problema. Lo capiamo tutti. Ma questo, di per se, e sufficiente per dire che e stata una spesa valida di denaro, tempo, sforzo e opportunita? Per il fornitore software, l’adozione nel senso di molte persone che passano molto tempo sul prodotto e super critica, perche cosi si crea stickiness.
Joannes Vermorel: Si.
Conor Doherty: Ma per l’azienda cliente che lo riceve, e una trappola enorme.
Joannes Vermorel: Si. Non vuoi qualcosa che venga adottato. Vuoi qualcosa che funzioni e basta.
Conor Doherty: Spiegalo, perche li non ho capito.
Joannes Vermorel: Qual e il tasso di adozione del tuo filtro anti-spam?
Conor Doherty: Ah, okay. Capisco.
Joannes Vermorel: Le persone hanno adottato l’anti-spam? No. L’anti-spam e li. Fa il suo lavoro, e tu non ti accorgi nemmeno piu di avere un anti-spam.
E semplicemente li. Fa il suo lavoro e lo fa estremamente bene. Il 99% delle email spazzatura viene filtrato. Non ti accorgerai mai che era li. E stato fatto.
Questo e l’aspetto dell’automazione. Si, questo e l’aspetto dell’automazione. E qualcosa che si fonde nel resto e poi e fatta. E il problema, quando le persone pensano all’automazione in termini di adozione, e: di cosa stiamo parlando?
C’e davvero una sfida di adozione per l’anti-spam? Storicamente ce n’era una, perche alla fine degli anni 90 i filtri anti-spam erano pessimi. Quindi le persone dovevano personalizzare le regole e fare molte cose per farli funzionare almeno un po’, per avere caselle di posta almeno un po’ sensate. Ma oggi, andando avanti nel tempo, in generale sono eccellenti, e di solito le aziende che finiscono segnate come spam se la sono cercata, perche hanno inviato milioni di email e sono state contrassegnate da milioni di persone come “Questa e spam”. Quindi ora le loro email sono spam.
Ma il problema che ho e che, quando le persone pensano che una tecnologia di successo sia adozione, stanno abbracciando le metriche del fornitore software, del fornitore tecnologico. E quello che dico e che nel business B2B non vuoi un pezzo di software che tenga occupati i tuoi dipendenti molti minuti al giorno. Ogni minuto passato da un dipendente a gestire un software costa alla tua azienda. Vuoi che la cosa risolva il problema cosi completamente che questi problemi diventino invisibili. Diventa il rumore di fondo della tua azienda e nessuno ci pensa nemmeno.
E semplicemente li. Fa le cose.
Conor Doherty: Ma per arrivarci, e sono d’accordo e mi piace l’analogia, non passi semplicemente da zero… non e davvero zero a uno, lo sappiamo. C’e automazione.
Joannes Vermorel: No. Per l’automazione e sempre strettamente zero a uno. Non l’ho mai visto diversamente. Pensa a cose a bassa posta in gioco. Quindici anni fa ho visto persone in compagnie assicurative il cui lavoro era solo premere un pulsante, confermare se era una carta d’identita, si, no, premere un pulsante, immagine successiva, confermare se era una carta d’identita. No, era sempre zero a uno.
Il problema e la completa fallacia del crawl-walk-run. No. Per l’automazione non funziona cosi. Quando si parla di milioni di dollari, e un’altra cosa. E per questo che dico che non stiamo parlando della stessa cosa. Lokad opera nel regno delle decisioni, decisioni finanziarie. Richiede decisioni finanziariamente molto consequenziali. Li sta la differenza. E parliamo di decisioni che non hanno un limite superiore a quanto bene possano essere prese. Torniamo al software che classifica un’immagine per dire: e una carta d’identita?
Si o no? Se hai qualcosa che, valutato, e gia molto oltre l’accuratezza di un umano, allora hai finito. Non c’e motivo di andare oltre. E se non ci sono giochi avversariali, persone che possono imbrogliare e cosi via, e ci sono molte situazioni in cui non ci sono, allora il lavoro e risolto. Hai gia risolto completamente il problema, fine. Devi passare a qualcos’altro.
Questo e il tipo di problemi di cui parlo. Una versione AI, per esempio, sarebbe: il tuo fornitore ti manda un PDF, una fattura, e tu vuoi estrarre dal PDF il numero di fattura nella codifica del tuo fornitore. Si puo fare automaticamente. Una volta che lo hai, e fatto.
Si, qualcuno puo aprire il PDF e fare copia e incolla, ma se hai un’automazione che lo fa, e fatta. Se hai una valutazione che dice che sei quasi perfetto, allora non ha senso l’adozione graduale. Non ha senso. Ecco perche dico che per l’automazione esistono solo zero e uno, mai adozione graduale.
Conor Doherty: Se confrontiamo mele con mele, per aziende che forniscono o vendono FDE come servizio per costruire il tipo di software decisionale che potremmo costruire anche noi, allora parliamo di metriche di valutazione diverse. E per te, lo hai citato prima, non esplicitamente ma lo hai suggerito, erano decisioni finanziarie, impatto finanziario. La linea nella sabbia per te e che l’unico modo per valutare un esperto che porti dentro per prendere decisioni, decisioni del tipo prendi questi soldi e compra questo, alloca questo stock li, programma persone per fare queste cose, deve essere l’impatto finanziario. Almeno e la stella polare.
Joannes Vermorel: Si. Direi economico. La distinzione e che, quando pensi in termini economici, ci sono cose che non appariranno nel tuo bilancio, di nuovo tutti gli effetti di lungo periodo.
Conor Doherty: Corretto.
Joannes Vermorel: Come il goodwill. Non vuoi inimicarti i clienti e fare cose che distruggono costi diretti e indiretti.
Conor Doherty: Esatto.
Joannes Vermorel: Tutti i costi indiretti, tutte le cose per cui devi pensare a lungo termine. Quindi la prospettiva economica e molto piu orientata al futuro di quella finanziaria, che tende a essere la versione di breve termine della prospettiva economica.
Conor Doherty: Per chi ascolta, potresti spiegare un po’ cosa intendi per goodwill? Potrebbe non essere immediatamente chiaro, e anche come si possa scomporre quel driver economico o quella prospettiva economica. E un punto molto interessante.
Joannes Vermorel: Per esempio, se lasci che le persone comprino prodotti su un e-commerce e dici loro che l’articolo sara consegnato in meno di sette giorni, ma in realta, diciamo, nel 30% dei casi manchi il tuo obiettivo. Nel breve periodo, se fai una promessa che mostra un tempo di consegna breve, puoi effettivamente aumentare le vendite. Ma se hai una percentuale significativa di fallimenti, in cui manchi le date di consegna che avevi dato ai tuoi clienti, ti costruisci una pessima reputazione. E perderai quote di mercato nel tempo. Potrebbe non vedersi subito, ma si vedra nel tempo.
Ecco perche, per esempio, qualche anno fa, oggi non si fa piu tanto, alcune piattaforme e-commerce dicevano “Lo abbiamo in stock” quando non era vero. Se mostri un articolo online e dici “Ce l’ho in stock”, probabilmente raddoppi le vendite rispetto allo stesso prodotto con scritto “Non ce l’ho in stock, ma lo ordino quando ordini tu”. Tuttavia, se non sei onesto con i clienti, rovinerai la tua reputazione e in pochi anni avrai perso tutte le quote di mercato se giochi a queste cose. Questo e il goodwill di cui parlo: essenzialmente tutta la fiducia che i tuoi clienti hanno in te per fare altri affari con te in futuro.
Conor Doherty: Si, la prospettiva economica, e preferisco il termine prospettiva economica.
Joannes Vermorel: E corretto.
Conor Doherty: E bene chiarirlo rispetto alla prospettiva finanziaria. Ma far apprezzare questo alle persone e, credo, una parte centrale della prospettiva dell’SCS o dell’FDE, ma certamente per noi della prospettiva dell’SCS. Capire, per esempio, le penalita da stockout, il costo di non avere qualcosa: non appare necessariamente direttamente, ma ovviamente esiste. Se non hai qualcosa, non lo vendi.
Joannes Vermorel: E direi che, se pensi in termini di FDE, appena dici che questi FDE non sono li solo per fare automazione banale, ma per toccare il livello decisionale, allora la mia opinione e che serve verticalizzazione. Servono persone esperte del dominio. Se ti occupi solo di automazione banale, va bene: prendi software engineer intelligenti, possono essere FDE, se la caveranno. Se vuoi toccare il livello decisionale, non puoi avere persone che sarebbero presumibilmente competenti universalmente su tutto. Non funzionera. Serve una competenza verticale per avere questa corretta comprensione economica.
Conor Doherty: Ma non posso semplicemente elicitarla? Per esempio, giorno uno, sono un FDE. Arrivo. Okay.
Quanto variano in media i vostri lead time? Non posso semplicemente raccogliere questa informazione? Perche devo essere esperto del dominio? Perche non posso essere tecnicamente brillante e fare domande?
Joannes Vermorel: Se assumiamo che tu sia Leonardo da Vinci, un genio poliedrico.
Conor Doherty: Si.
Joannes Vermorel: Okay. Ma se sei appena uscito dall’universita, potresti non esserlo. La mia esperienza in Lokad e che, quando prendiamo persone intelligenti da una scuola di primissimo livello, Ivy League, servono circa due anni perche persone molto brillanti siano in grado di avere una valutazione ad alto livello corretta di cio che succede nella supply chain di una grande azienda. Coltivare questo giudizio richiede tempo. Tipicamente il nostro obiettivo in Lokad e che, entro sei mesi, partendo da una persona molto intelligente, si abbia qualcuno capace di mantenere un account. Quindi molte decisioni architetturali super critiche sul design della ricetta numerica sono gia state prese.
Si tratta quindi di mantenere un sistema, e questo si puo ottenere in sei mesi. Ma essere in grado di prendere quelle decisioni in modo accurato e saggio richiede piu o meno due anni, anche partendo da persone molto intelligenti e con un focus esclusivo su una verticale.
Conor Doherty: Si. E vero.
Joannes Vermorel: Il problema e che, se hai persone che fanno una missione dopo l’altra e si suppone siano missioni brevi, di pochi mesi, non c’e magia. Non saranno in grado di avere questa prospettiva economica fatta bene, e quindi la maggior parte di cio che uscira, se iniziano a lavorare al livello decisionale, sara semplicemente fasullo. E cosi. E in Lokad, anche per noi, i primi cinque anni sono stati estremamente difficili. I primi anni di Lokad sono stati atroci.
Non avevo colto cio che dovevo cogliere. A mia difesa, la quasi totalita dei libri sulla supply chain e completamente fasulla, e lo e ancora.
Conor Doherty: Credo che abbiamo gia coperto questo terreno.
Joannes Vermorel: Tuttavia, mi stavo effettivamente comportando esattamente come un FDE senza vera competenza verticale, e questo ha portato a molto dolore e miseria. Quindi la mia opinione e che, se le aziende prendono FDE, devono assicurarsi che si concentrino su automazione stretta e assoluta, dove il criterio sara molto semplice: headcount. E per il livello decisionale, devono assolutamente assicurarsi di avere persone davvero verticalizzate. Di nuovo, se ci pensi, e puro buon senso. Lokad tratta problemi di supply chain, ma immagina di assumere qualcuno per occuparsi di frodi finanziarie nel sistema bancario. E un’area incredibilmente specializzata. Io non pretenderei di sapere esattamente come operano truffatori e frodi quando cercano letteralmente di truffare banche e costruire schemi transnazionali con identita false, documenti falsi e cosi via. Non e la mia competenza. Se pensi di poter prendere un ingegnere brillante appena uscito da una scuola di ingegneria e affrontare problemi che richiedono una specializzazione verticale molto profonda, semplicemente non funzionera. Quelle persone avranno bisogno di tempo, potenzialmente anni, per diventare davvero esperti di dominio. E questo in qualche modo mina la promessa degli FDE: assumi questi ragazzi, fanno la loro missione di tre mesi, bam, payback, se ne vanno a casa e hai un ritorno sull’investimento redditizio.
Conor Doherty: Per chi ascolta, e questo si collega all’idea che hai le competenze tecniche ma non hai ancora la competenza di dominio. Come fai a sapere, e ti chiedo la tua esperienza aneddotica, se qualcuno sarebbe un buon SCS? Perche e appena uscito da una grande ecole, ovviamente non sa nulla di supply chain, o molto probabilmente non sa nulla delle peculiarita e delle eccentricita.
Quindi come fai a sapere, Joannes, che questa e una buona investimento, che questa persona ha competenze sufficienti, eccetera?
Joannes Vermorel: In generale valutiamo semplicemente la capacita grezza di apprendere, tutto qui. E credo che la maggior parte delle aziende che vendono FDE faccia esattamente lo stesso. Dicono: prendiamo persone intelligenti che possono imparare molto velocemente, e accumuliamo questo talento. E funziona. Non sto dicendo che non funzioni. Sto dicendo che, se vuoi operare al livello dell’automazione, cio che serve e formare le persone, direi, nell’arte di fare software, e andra bene. Sara molto agnostico. Puoi avere una prospettiva completamente orizzontale in cui possono affrontare qualunque verticale, e andra bene se tratti solo automazione stretta.
Se vuoi trattare il livello decisionale, allora prendi persone intelligenti e quelle persone dovranno essere formate per quella verticale. La domanda diventa: stai comprando un FDE, un forward deployed engineer, per la tua verticale; questo FDE e stato formato esplicitamente per questa verticale, si o no? E se l’azienda ti dice: “No, assumiamo solo i migliori.
Fidati, andra bene.” Non andra bene. Quello che dico e che, se vuoi qualcuno che gestisca un livello decisionale che prende decisioni su frodi avanzate nel sistema bancario, e meglio che quella persona abbia una vera comprensione di cio che accade nel sistema bancario. Se vuoi qualcuno che prenda decisioni per un sistema avanzato di diagnosi medica che riguarda la vita dei pazienti, voglio che questa persona sia molto competente nelle scienze mediche oltre che software engineer.
Quando ci pensi, e davvero ovvio.
Conor Doherty: Bene, okay. Si. Si.
Sono d’accordo.
Joannes Vermorel: Ma tornando indietro, per darti ancora un esempio, prendiamo l’ospedale per contrapporre due missioni FDE. Una, e le ho viste entrambe, missione numero uno: le persone vengono registrate piu volte in diverse divisioni dell’ospedale e quindi bisogna riconciliare il fatto che sia in realta lo stesso paziente.
Conor Doherty: Si.
Joannes Vermorel: Altrimenti finisci con molti duplicati, perche molte persone si registrano qui e la, ci sono problemi, e quindi ci sono molti record duplicati. Non sarai in grado di risolvere questo problema di riconciliare tutti quei duplicati con una configurazione grezza. Quindi prendi un FDE e quelle persone faranno l’automazione per riconciliare quei duplicati.
Conor Doherty: Perfetto.
Joannes Vermorel: Ora, questo e un problema che non richiede vera competenza medica. Succede in un ospedale, ma alla fine riguarda la riconciliazione di persone identiche con possibili errori di battitura in nome, cognome, indirizzo, numero di telefono e cosi via. Se invece vuoi qualcosa che prenda decisioni su qualsiasi cosa medica, e prenda decisioni consequenziali per la vita del paziente e finanziariamente per l’ospedale, allora vuoi qualcuno esperto nelle scienze mediche. La linea, in pratica, non e cosi sottile. Credo che molte aziende tendano a confondere se stanno trattando automazione intelligente o decisioni intelligenti, e le due cose in pratica hanno vibrazioni molto diverse e requisiti molto diversi.
Conor Doherty: Come pensiero conclusivo, se dovessi prendere almeno un paio di conclusioni, puoi dirmi se sei d’accordo o no con questa valutazione. Pensi sia corretto dire che, sulla base di quanto abbiamo discusso oggi, e certamente dell’emergere e della popolarizzazione di questo ruolo, l’affermazione che sentiamo da un paio d’anni, anzi da diversi anni, cioe: se vuoi ottimizzare il tuo decision-making, compra semplicemente un modulo aggiuntivo, collegalo e sei a posto, e morta? Saresti d’accordo?
Joannes Vermorel: Si. Si.
Conor Doherty: Ma voglio dire, noi lo abbiamo sempre pensato. Pensi che questo non funzioni mai? Pensi che il mainstream ora stia tacitamente dicendo: “Si, si, non funziona”? Questo e quello che avrei dovuto dire.
Joannes Vermorel: Non lo so. Chiaramente lo stanno dicendo i vendor che vendono FDE.
Conor Doherty: Si. Beh, e vero.
Joannes Vermorel: Ma gli altri vendor che non vendono FDE continuano a vedere l’opposto. E direi che il tempo lo dira. Il tempo lo dira. Ma vedo ancora che il mercato e assolutamente pieno di vendor ERP che vendono moduli di inventory optimization.
Ci sono ancora mille aziende che fanno questo. Quindi il tempo lo dira. Forse si, col tempo. Chiaramente e una tendenza interessante, ma non sono sicuro che sia gia dominante. Parte del problema e che le aziende che vendono FDE sono anche estremamente costose. Questa e anche una delle debolezze di aziende molto di alto profilo come OpenAI, Anthropic, Amazon: sono aziende che pagano salari che tendono a essere un po’ stravaganti rispetto alle norme di mercato. Per esempio, OpenAI ha assunto regolarmente persone con pacchetti annuali multimilionari.
Il problema e, di nuovo, non sto valutando se quelle persone valgano o meno. Sto solo dicendo che, se tutta la tua struttura dei costi, dal punto di vista del vendor, deve tenere conto di persone di questo tipo…
Conor Doherty: Si.
Joannes Vermorel: Il prezzo che dovrai far pagare per il tuo FDE sara probabilmente irragionevolmente alto. E tra l’altro, se guardi la storia di Palantir, e stata una storia di avanti e indietro: fanno progressi nel dominio, poi crescono come matti, poi ridimensionano, semplicemente perche sono super costosi e molti clienti, dopo l’entusiasmo iniziale, dicono: e troppo costoso, dobbiamo ridurre.
Conor Doherty: Bene, per separare un po’ questa idea, se ti ho capito correttamente, sei sostanzialmente d’accordo con me, ma il punto che fai e che farlo bene, qualunque cosa sia, quindi fare bene un progetto AI, potrebbe essere proibitivamente costoso. Di conseguenza ci saranno ancora persone, vendor che vendono essenzialmente, non voglio dire olio di serpente, ma vendono: “Si, si, compra questo modulo. Ottimizzera tutto.” E una alternativa piu economica. Imperfetta, ma piu economica rispetto all’acquisto di un FDE.
Quindi credo che non ci sia davvero alcuna contraddizione in questi termini. Puo ancora esistere come prodotto, anche se l’esistenza di un FDE in qualche modo mina l’ottimizzazione di un modulo di ottimizzazione. Un po’ filosofico, ma penso che questo fosse il punto a cui stavamo arrivando.
Joannes Vermorel: Si. Si. Esatto.
Conor Doherty: Joannes, mi e piaciuto molto, ma non ho altre domande. Grazie mille per il tuo tempo. E a chiunque stia ascoltando, segnalo che ci sono posizioni aperte di supply chain scientist in Lokad. Quindi, se siete interessati, controllate il nostro LinkedIn o mandateci una email a contact@lokad.com.
E detto questo, non resta altro da dire se non: tornate al lavoro.
