Expert Talk con Federico Milan: innovare dai processi, non dalla tecnologia

Dallo Smart SCADA all’Human at the Edge: perché l’innovazione parte dai problemi, non dalla tecnologia 

Federico Milan ha oltre 25 anni di esperienza industriale nella trasformazione digitale. Nasce come ingegnere elettronico e attraversa tutte le fasi di questo percorso: progettazione di architetture OT, automazione, sviluppo di piattaforme software industriali come SCADA, MES e WMS, fino ai progetti IoT, Machine Learning e intelligenza artificiale applicati alle macchine industriali. Nel 2016 assume la responsabilità della divisione digitale nell’azienda in cui lavorava e nel 2018 diventa responsabile della business unit dedicata allo sviluppo di soluzioni di intelligenza artificiale, BI e computer vision.

Il filo conduttore di questo percorso, racconta Milan, non è mai stata la tecnologia in sé ma la curiosità di capire un processo e trovare un modo per governarlo. È da questa tensione che nasce Smart SCADA, un framework sviluppato attorno al 2009 per rompere la tradizionale piramide dell'automazione industriale: macchine autonome e componibili come blocchi Lego, capaci di comunicare tra loro senza bisogno di scrivere codice ogni volta. Il risultato concreto è stato dimezzare i tempi di sviluppo di un impianto.

Nell'intervista, Milan ripercorre come questo approccio lo abbia portato a teorizzare un metodo per riconoscere l'innovazione vera: risolvere contraddizioni, non semplicemente applicare tecnologia. Affronta poi il tema della servitizzazione, la costruzione di team multidisciplinari, il ruolo del CFO nei progetti di innovazione e la sua visione dell'intelligenza artificiale, sintetizzata nel concetto che ha coniato di "Human at the Edge": l'uomo non deve stare dentro ogni micro-decisione automatizzata, ma sul confine cognitivo del sistema, pronto a intervenire dove la macchina non può arrivare.

Il percorso di Federico Milan: dalla curiosità per l'elettronica all'intelligenza artificiale

Il piacere è anche nostro. Per chi non ti conosce ancora, anche se sei una persona abbastanza conosciuta nel settore, ti va di raccontare qual è stata la tua esperienza, nell'arco di qualche minuto?

Ci provo, è sempre difficile. Ma se dovessi trovare un filo conduttore nel mio percorso, direi che è sempre stata la curiosità: capire come funzionano le cose e soprattutto farle funzionare e ottimizzarle in qualche modo.

Nasco come ingegnere elettronico. All'inizio progettavo elettronica analogica, nel 2000 avevo sviluppato un MPPT per il fotovoltaico e nel 2001 sono entrato nel mondo dell'automazione. Sono partito molto vicino alla macchina, sviluppando il PLC, il framework di automazione, il controllo del processo, per poi arrivare alla supervisione e il MES, che praticamente ho sviluppato da zero per il nostro processo produttivo. Progressivamente mi sono accorto di una cosa: più salivo di livello, più il problema non era semplicemente controllare la macchina, ma capire il processo.

Un passo interessante è stato il 2005, quando ho sviluppato un regressore autoadattivo su PLC. All'epoca non parlavamo di machine learning come oggi, ma il problema era già quello: utilizzare il dato della macchina per adattare il comportamento del sistema. Il mio interesse verso quello che oggi chiamiamo intelligenza artificiale è nato molto prima, alle superiori, quando venne a trovarci Federico Faggin e parlava di reti neurali. Per me, che ero appassionato di elettronica e mi piaceva l'informatica, è stato un cortocircuito: ho capito che forse mi piaceva quella cosa lì, prima ancora dell'AI. Ricordo ancora che mi ero affezionato a quella che veniva chiamata Fuzzy Logic e ai sistemi esperti, poi alle reti neurali. Le tecnologie cambiano, ma la domanda rimane sempre la stessa: quanto possiamo rendere un sistema capace di comprendere il proprio contesto e quindi adattarsi? Questo è stato un po' tutto il mio filo conduttore.

E qual è la risposta che ti sei dato a questa domanda?

Questa domanda ha creato la voglia di sviluppare qualcosa di nuovo, che ho chiamato Smart SCADA. Era un'idea per rompere la tradizionale piramide CIM, la piramide dell'automazione industriale: non semplicemente collegare meglio i livelli tra loro, ma mettere in discussione l'architettura stessa. Da lì tutta la tecnica si è evoluta: sono arrivati l'IoT, il WMS, la business intelligence, l'Industry 4.0 e infine l'AI. Nel 2016 ho avuto la responsabilità della divisione digital e nel 2018 è stata formalizzata una business unit dedicata anche all'AI.

Se dovessi fare un riepilogo, potrebbe sembrare una carriera che va dall'elettronica all'AI, ma io la vedo in modo diverso: sono sempre rimasto sullo stesso problema, capire il processo e trovare un modo per governarlo.

Mi sembra di capire che ci sia un filo conduttore, oltre a quello che hai descritto, legato alla curiosità. Il tuo percorso parte dall'OT, dall'hardware, per poi passare dal software ai dati fino all'innovazione digitale. Secondo te è stata una scelta consapevole o solo figlia di questa voglia di comprendere il processo?

Direi entrambe le cose. In sostanza è un'evoluzione naturale, perché ogni problema ne apre un altro. Faccio un esempio: controlli la macchina e scopri che devi supervisionarla. La supervisioni e scopri che devi contestualizzare quello che sta producendo. A quel punto costruisci un MES e scopri che il dato deve dialogare con altri sistemi. Colleghi i sistemi e scopri che avere tanti dati non significa avere informazione. Quando inizi ad avere informazione, nasce un'altra domanda: possiamo utilizzare questa conoscenza per ottimizzare il processo? A questo punto, con le tecnologie che abbiamo oggi, machine learning e AI diventano quasi una conseguenza.

Per questo non ho mai visto la trasformazione digitale come un successo di tecnologie. La vedo come una progressiva estensione: andiamo ad aggiungere pezzi per governare e chiudere un problema, dare una soluzione.

Questo presuppone che ci sia una tecnologia che risolve il problema. Come approcceresti invece un problema che non ha ancora una tecnologia che lo risolve?

Questo è il problema di oggi: pensiamo di prendere la tecnologia, metterla in un contesto e sperare che ci risolva. Io parto un po' dalla filosofia. Prima dobbiamo contestualizzare il problema, ma ancora prima partirei da un concetto importante: la value proposition che vogliamo ottenere. Se ho un problema, lo devo circoscrivere e dargli significato, dargli valore. Dalla value proposition nasce una strategia, dalla strategia nascono l'obiettivo e i goal che dobbiamo darci, e dai goal andiamo a trovare i KPI.

Tutto questo nasce dal comprendere quale missione ci diamo, come strutturiamo il nostro percorso e come vogliamo analizzarlo, perché progettare significa anche progettare le misure per capire dove è il problema. Dobbiamo contestualizzare. Una volta compreso il problema, potremmo capire che sono necessari dei cambiamenti, e i cambiamenti spesso non sono tecnologici, sono procedurali.

Cos'è l'innovazione secondo Federico Milan: risolvere contraddizioni, non applicare tecnologia

Hai citato un aspetto che spesso viene sottovalutato in azienda, ma anche in chi fa prodotto: la comprensione del problema. Si parte con la soluzione senza capire bene il problema dell'utente che poi dovrà usarla. Hai un framework per identificare questi problemi e per riuscire a narrarli e comunicarli bene, sia all'interno del tuo gruppo di lavoro sia per te stesso?

Di framework ce ne sono tanti: pensiamo al brainstorming, al design thinking. Sono strumenti che permettono alle persone di comunicare tra loro, e il valore di un'azienda, per quanto possa sembrare una frase fatta, sono le persone: hanno la capacità cognitiva di capire il problema e di governare poi un processo di cambiamento.

Ciascuno di noi, però, costruisce il proprio frame, e ciascuno dà un significato diverso all'innovazione. Per me l'innovazione è quando trovo il modo di mettere assieme due bisogni tra loro molto distanti, devo risolvere una o più contraddizioni. Se penso allo Smart SCADA, avevo bisogno di standardizzare qualcosa pur rendendolo flessibile, e standardizzazione e flessibilità spesso sono due cose antitetiche. Se ci riesci, crei automaticamente innovazione. Ammetto di essere molto vicino al pensiero di Altshuller in questo contesto, senza dire di applicare la TRIZ in modo rigoroso, ma l'idea è quella: spaccare il problema, comprenderlo. Esistono anche altre tecniche, come il DoE (Design of Experiments), ma tutte prevedono una progettazione che permetta di andare in profondità nel problema, e da lì estrarre i meccanismi e le frontiere che dobbiamo affrontare.

Prima hai raccontato che hai sviluppato un framework di connessione tra macchine già all'inizio degli anni 2000. Cosa ti ha portato a creare un sistema IoT prima ancora che l'IoT esistesse come concetto? Hai usato questo stesso approccio appena descritto per arrivare a quel risultato?

Direi di sì. È stato forse l'evento in cui c'è stato un cambiamento “non solo tecnica”, ma anche un nuovo modo di rendere l'automazione efficiente ed efficace. L'idea era questa: se ho delle macchine e queste macchine generano dati, perché l'informazione deve andare nei livelli più alti solo attraverso tunnel rigidi tra i livelli, quando pensiamo alla piramide CIM con i suoi livelli 0, 1, 2, MES, ERP, ma non renderle autonome, autoconsistenti, capaci di governare in modo verticale il proprio contesto produttivo mantenendo però la capacità di informare chi sta a valle?

Immaginavo tanti centri di lavoro connessi in cascata o in parallelo, ciascuno capace di cooperare con una rete di agenti in grado di governare il proprio processo, comunicare con chi sta a valle e a monte, e dare consapevolezza alla persona. Eravamo nel 2007-2008 e dovevamo affrontare un cambiamento, creare qualcosa di nuovo. Da lì nasce lo Smart SCADA, che porta a cambiare una filosofia che non è più fare coding ma fare composing. Immaginate dei blocchetti Lego che si possono combinare per creare il sistema: una macchina è un componente fatto da tanti blocchetti che può essere inserito, tolto, spostato all'interno dell'ecosistema, e tutto continua a funzionare grazie a meccanismi di comunicazione tra pari e alla capacità del sistema master di capire dove si trova, e perchè, e quindi di governare in modo efficiente i processi. Lo Smart SCADA è l'insieme tra Supervisione, SCADA, MES, WMS e Business Intelligence.

E nell'immediato, che valore ha portato alla gente che operava sulle macchine, e all'azienda, questo tipo di integrazione?

Quest’idea ha portato sicuramente un risultato molto concreto: normalmente un impianto veniva sviluppato in nove mesi, e l'abbiamo praticamente dimezzato. Non dovevamo più scrivere codice e ripensare da zero i moduli software, perché avevamo creato moduli meccatronici, sistemi autonomi che potevano essere inseriti nel contesto e riconosciuti automaticamente. Ho tolto ai miei progettisti le attività a basso valore, per concentrarli sul vero sviluppo di valore. Il goal l’ho ottenuto quando lavoravo con la scuola con stage per l’alternanza scuola-lavoro. Avevamo appena finito di sviluppare questo framework e il test l'abbiamo dato a un ragazzo appena uscito dall'ITIS. Dopo tre settimane era riuscito a fare la supervisione di una macchina, senza sapere onestamente perché funzionasse, ma funzionava: la composizione di blocchetti permetteva di collegare tutti gli asset automaticamente al MES senza dover scrivere una riga di codice, senza preoccuparsi di dove fosse quella tag o quella variabile, perché tutto era coerentemente conosciuto tra i sistemi e comunicavano tra loro. L'unica attività era decidere se mettere il pulsante a destra o a sinistra, o dove posizionare quel centro di lavoro rispetto agli altri o ad altre macchine. Oggi parliamo di software defined automation, software defined network, software defined process: quello era un inizio, fatto qualche tempo prima.

Il valore del network e la scrittura come strumento di riflessione

Volevo citare un altro aspetto della tua carriera che ho molto apprezzato: hai scritto diversi libri e fai parte di vari comitati scientifici, tra cui quello di SPS. Vorrei capire due cose: che valore ti ha portato il network di comitati scientifici all’interno del quale puoi confrontarti con persone che hanno storie interessanti e diverse da raccontare, e cosa ti ha portato a scrivere un libro, qual è il valore che vuoi dare a chi lo legge.

Domande interessanti, la prima è più facile della seconda. Partecipare, avere un network, è fondamentale. Ho notato che l'innovazione soffre molto quando rimaniamo confinati dentro il nostro settore. Incontrare persone che vengono da mondi diversi ti fa scoprire che qualcuno ha già affrontato un caso simile al tuo, magari contraddizioni simili a quelle che stai pensando di risolvere, e questo scambio ci permette di crescere. I comitati scientifici, SPS, mantenere i contatti con l'università, incontrare altre aziende e professionisti mi hanno permesso soprattutto questo: avere contaminazione. Penso che chi fa innovazione debba stare con i propri problemi e le proprie competenze, ma anche avere altri pari che possano essere contributori, e creare una rete di scambio.



Sulla seconda domanda: forse ho scritto perché avevo capito che non stavo semplicemente sviluppando software, ma stavo creando una nuova filosofia, e dietro c'era un modello. Lo Smart SCADA nasceva dal tentativo di rompere la piramide CIM, cambiare paradigma, passare dal coding al composing, quindi non costruire sempre applicazioni da zero ma renderle collaborative e possedere una semantica interna. Scrivere mi ha obbligato a fare una cosa utile per tutti i tecnici: trasformare un'intuizione in un'esperienza e in un sistema di pensiero che aiuta a trovare altre strade.

Quindi non è solo un voler trasmettere qualcosa al prossimo, ma anche un modo per mettersi in discussione, ragionare sulle cose e forse chiarirsi alcuni aspetti che non erano del tutto chiari.

Sicuramente sì. Rubo anche una frase di un professore, Carlo Bagnoli, che dice che chi scrive un libro fa un'autocelebrazione. Probabilmente c'è anche questo.

Ci sta, e ci può essere anche un effetto positivo per la carriera o per lo status di chi scrive. D'altronde il libro si basa su esperienze vissute, e raccontarle ha un grande valore per tutti, oltre a valorizzare il proprio lavoro. Prima ci hai raccontato la differenza tra innovazione e tecnologia. Hai un modo specifico per capire se un progetto è davvero innovativo o è solo novità tecnologica? Ci fai un esempio concreto di questo?

Partiamo da un presupposto: la tecnologia può essere interessante ma può anche non produrre innovazione. Per me l'innovazione nasce quando modifichiamo in modo significativo il modo in cui risolviamo un problema, perché il nostro compito è risolvere problemi, quindi dobbiamo capire quando la tecnologia è utile. Qui mi affeziono a persone come Robert Gordon, Lewin, Bateson, Erik Brynjolfsson, la curva a J: tutti ci dicono che la tecnologia senza strategia è inutile. Proviamo a pensare che cos’è veramente innovazione. Qui sono molto filo Altshuller, io cerco una contraddizione: se non capisco bene quale contraddizione risolve una tecnologia o una soluzione, rimango nel dubbio; se mi è chiara, allora la comprendo.



Facevo l'esempio di Smart SCADA per un pubblico di automazione: qualcosa che vuole essere standard ma anche flessibile. Se risolvo questa contraddizione, standard pur rimanendo flessibile, automaticamente ho fatto innovazione. Ma lo possiamo pensare anche in altri campi, anche di processo: voglio fare la stessa cosa in metà del tempo, questo non significa semplicemente applicare tecnologia, ma spaccare il problema, perché probabilmente è la sequenza con cui applichiamo le tecnologie che ci permette di migliorare. Lo possiamo applicare anche a livelli più alti, perché un'azienda è fatta di vari processi, dalla vendita al marketing, e anche il CFO può avere le sue contraddizioni: come faccio a impegnarmi a creare un budget se non ce l'ho? Qui si aprono tantissime strade. Il mio obiettivo è sempre stato non essere di ostacolo, ma creare pillars di cui tutti i processi interni possano beneficiare. Non tecnologia fine a se stessa, ma un concetto di strategia e costruzione tecnologica: per questo lo chiamiamo ecosistema, a supporto di tutti i processi aziendali.

Dalla visione alla tecnologia: il framework strategico, da vision e mission ai KPI

Quanto di questo processo di innovazione è strategia, quanto processo e quanto tecnologia?

Qui mi tocchi nel cuore. Io parto sempre da una vision. La vision crea una mission. La mission genera la value proposition. La value proposition crea i goal. I goal definiscono i KPI. La value proposition permette di costruire quella parte strategica e tattica che va a toccare la parte tecnologica. Ma dobbiamo sempre partire da una visione e da una missione: senza queste non si riesce a definire una proposta di valore utile per trasformare quelle idee che arrivano dal brainstorming, dal business canvas, dalla voglia di un'azienda di fare sempre meglio in azioni concrete. Non esiste una parte più importante delle altre. Sicuramente la tecnologia viene dopo, perché deve essere applicata una filosofia che nasce da un concetto di strategia.

E quanto questo si lega al modello di business? Immagino che una buona tecnologia senza un buon modello di business resti una tecnologia buona che però rimane in garage.

È molto legato, e lo stiamo vedendo sempre di più. Quante volte sentiamo parlare di servizi o di servitizzazione? Non sono la stessa cosa. Dicevo prima di costruire dei pillar che sostengano, senza essere di ostacolo, i vari processi: il modello di business entra proprio in quel concetto di cosa vogliamo fare. Oggi il mercato è molto competitivo e dobbiamo cambiare il nostro modo di aggredirlo, costruendo strategie e business plan che ci dicono come attivarci: vogliamo vendere un prodotto? Vogliamo vendere un prodotto e agganciarci dei servizi? È così che è nato l'IoT: avevamo un prodotto, ci abbiamo agganciato un servizio, che richiede un altro prodotto capace di comunicare con una base centrale e garantire dato più contesto e informazione. Quell'informazione oggi la possiamo sfruttare bene con machine learning e AI, per chiudere un cerchio tornando al cliente con servizi e informazioni. Questa è una strategia. Un'altra strategia è chiedersi: perché ti devo vendere un prodotto e non la produzione che genera? Qui ci si sposta dai servizi alla servitizzazione: non ti vendo più la macchina, ma ti vendo cosa fa quella macchina.

Servitizzazione: vendere il valore, non il chilogrammo di ferro

Ci sono tanti esempi noti, dalle stampanti con il costo copia ai motori aerei Rolls-Royce venduti come ore di volo. Proviamo però a portare questo ragionamento in un contesto industriale di processo, dove magari serve anche un'opera civile: lì serve una strategia diversa per fare servitizzazione, sostenuta da metodologia e tecnologia insieme.

Hai introdotto il tema della servitizzazione. Come l'hai affrontata tu nella tua carriera, e quali sono state le difficoltà reali che hai incontrato in questo processo di implementazione?

Il valore al chilo è completamente diverso. Mi ricorda un altro amico che racconta spesso similitudini di questo tipo, Roberto Siagri, non so se lo conosci.

Sì, l'ho sentito anch'io. Sono idee che nascono molti anni fa, forse in altri ambienti, e che ho cercato di portare a casa: come faccio a fare la stessa cosa con le macchine che sviluppiamo noi, aziende manifatturiere italiane, che alla fine vendono al chilo? Io vengo dal mondo manifatturiero degli anni 2000 dove ci si chiedeva che cos'è il software. Forse per questo cerco di scardinare certe cose. Qui si tocca un concetto interessante: la produttività. Spesso la confondiamo con il produrre di più nello stesso tempo, ma non è così: produttività significa prendere un input e aggiungergli valore, perché quell'oggetto da 200 grammi costa mille euro proprio perché dentro ci sono componenti di servizio che ne fanno lievitare il valore, tante cose immateriali.

Tornando alle macchine, dobbiamo capire cosa possiamo dare al cliente per aumentare la sua produttività, per fargli produrre oggetti fisici che abbiano molto più valore rispetto a prima. Questo è un vero cambiamento strategico e di mercato. Tutto nasce da una catena: noi siamo produttori di macchine, di cosa ha bisogno il nostro cliente? Dobbiamo creare partnership, capire cosa possiamo dare e cosa possiamo ricevere. I servizi nascono per questo, perché possiamo dare un aiuto e iniziare a creare partnership. Quando riusciamo a fare servitizzazione, creiamo una contaminazione e un collegamento tra il business del produttore di macchine e quello del cliente del produttore di macchine. E torniamo alla vision, alla mission, alla value proposition.

Mi sto prendendo appunti perché vedo spunti molto interessanti. Una cosa che emerge ora è anche un aspetto di generosità: creo servizi perché voglio aiutare il mio cliente a ottenere risultati migliori. Quanto viene coinvolto il cliente nella progettazione di questi servizi, nel tuo caso?

I latini dicevano "do ut des", ti do perché tu mi dia. Un egoismo nobile, forse possiamo dire così. I clienti fanno parte della catena, sono stakeholder, la componente su cui l'industria manifatturiera e i costruttori devono analizzare i bisogni. Senza quello è impossibile creare un piano: dobbiamo analizzare il mercato, capire con chi abbiamo a che fare e valutare se diventare partner ha senso, con tutti i pro e i contro. Si applica una mappatura per identificare il punto in cui possiamo creare davvero una proposta di valore, perché il valore non lo diamo noi, ce lo riconosce il mercato.

Quindi tutto passa dal co-design con il cliente finale che non solo espone le sue esigenze, ma racconta anche come vorrebbe vederle soddisfatte, e il processo sta nel trasformare questo in qualcosa di funzionale, la macchina e il risultato.

Sicuramente sì, senza generalizzare troppo, ci limitiamo a contesti abbastanza specifici: la mia esperienza è verso costruttori di una certa tipologia di impianti e complessità, va analizzato caso per caso. Possiamo chiamarlo co-design? Si, prima di questo ci sono tecniche come il QFD, chi applica la user experience ne ha altre, ma tutte partono da un concetto simile alla lean: devi andare sul gemba, nel reparto produttivo del tuo cliente, e non solo lì. Devi scalare tutti i piani, perché il reparto produttivo è dove si crea il prodotto, ma poi ci sono tutti gli altri uffici. Hai il direttore di stabilimento, il responsabile di impianto, l'ufficio acquisti, l'ufficio tecnico e tutti questi hanno dei bisogni e poi hai la parte amministrativa. Quando parliamo di servitizzazione, diamo qualcosa che risolve i problemi a tutti questi livelli, tutti questi stakeholder. È facile dirlo, ma difficile metterlo insieme.

Magari lui non lo sa, ma è importantissimo. Un servizio significa strutturare un modo di avere una rendita continua, le classiche fee ricorrenti. Significa avere la capacità di sviluppare una tecnologia, mantenerla ed esporla al cliente, quindi garantire un team capace di seguirlo, migliorarla con logiche di improvement, e far quadrare i conti, perché serve un team da sostenere e un parco clienti adeguato a bilanciare questo sforzo. Se facciamo un passo in più verso la servitizzazione, non vendiamo più nemmeno il prodotto, il ferro resta nostro e vendiamo, ad esempio, la produzione: si entra in un meccanismo di finanziamento che, finché il prodotto costa poco e il tempo di recupero è veloce, resta semplice, ma se abbiamo macchine che richiedono opere civili, il tema tocca meccanismi finanziari che non sono più solo di appannaggio dell'ufficio tecnico, ma di tutto l'ambiente amministrativo. Il CFO è parte fondamentale per una crescita innovativa verso queste filosofie, perché il piano deve essere costruito e sostenibile non solo dal punto di vista tecnologico, ma dell'ecosistema aziendale e della vita finanziaria dell'azienda.

Anche solo per il fatto che ci sono flussi di cassa molto diversi rispetto alla vendita upfront. Come hai detto anche tu, servono strumenti finanziari diversi per soddisfare le esigenze finanziarie dell’azienda.

Costruire team multidisciplinari e superare "abbiamo sempre fatto così"

Hai introdotto il concetto di team necessario per un progetto di servitizzazione. Come deve essere composto? Deve essere un team di R&D o un team multidisciplinare, con visioni divergenti che portano a esplorare aree diverse?

Fare innovazione per me significa essere multidisciplinari. Ho sempre avuto la fortuna di avere team multidisciplinari: non solo chi sviluppa software o firmware, ma anche chi fa il design della meccanica, lo strutturista, chi va a montare la macchina, chi va dal cliente a vendere, chi acquista (supply chain). Oggi è un errore creare silos. Cito Gregory Bateson: il problema è che cerchiamo di risolvere i nostri problemi in modo singolo, senza accorgerci che sono tutti legati tra loro.

Se pensiamo di fare innovazione per l’azienda, poi è ovvio che ogni singolo processo ha il proprio innovatore, ma creando una struttura che parte da una visione, che crea una missione, che genera la value proposition, abbiamo bisogno di conoscere tutte le voci, tutti i rappresentanti di quel contesto aziendale. Il team deve essere multidisciplinare: oggi, se stiamo solo nel piano software, hai bisogno anche di chi si occupa di cybersecurity, per esempio, pensando alle normative già in vigore. Non posso avere un team ristretto di esperti verticalizzati, ho bisogno di persone con esperienza che coprano l'intera superficie di analisi. È lì la difficoltà nel mettere insieme questi team: spesso, per inesperienza, ci si dimentica qualcuno, magari la parte acquisti. Abbiamo fatto il progetto più bello del mondo e poi dove andiamo a prendere quello che ci serve? Solo per fare un esempio.

E come si combatte la pigrizia all'interno di un team? Si combatte alla fonte, scegliendo le persone giuste, ma su un team che già esiste, dove magari c'è il classico "abbiamo sempre fatto così". Come si combatte, secondo te?

Ho imparato una cosa, e l'ho imparata sbagliando. Il primo errore è pensare che le attività vengano portate avanti dalla buona disponibilità delle persone: è un errore perché significa basarsi sulla persona senza considerare che è un individuo, con le proprie necessità. Non tutto può ricadere sulla persona, un individuo con una propria intelligenza emotiva, che porta interesse e capacità cognitiva, ma deve essere il processo a guidare e a portare al goal. Dobbiamo cambiare il modo in cui ragioniamo: non possiamo fare affidamento sulla buona volontà delle persone sempre, dobbiamo costruire processi in grado di portare le persone a bordo e dare loro il contesto corretto perché siano capaci di portare a compimento il compito assegnato o che si prendono in carico di fare. È un mix: le persone hanno buona volontà, ma serve prima strutturare un processo. Io all'inizio parlavo di tecnologia e di macchina, ma in realtà quello che andavo a ottimizzare erano i processi.

Quindi questo va calato dall'alto e condiviso con il team per avere successo, non ci si può aspettare che il team, per così dire “essere illuminato”, prenda spontaneamente l'iniziativa di introdurre un nuovo processo?

La cosa va declinata bene, nel senso che una cosa non toglie l'altra. Se mi metto nei panni dell'imprenditore o del manager, dobbiamo costruire soluzioni il più possibile deterministiche: abbiamo una missione, un obiettivo, e lo dobbiamo trasformare in qualcosa di concreto. Devo guidare il mio team, e lo faccio attraverso framework di gestione, dal project management all'Agile allo Scrum: sono metodi che governano, attraverso processi, l'esecuzione di ogni singola persona del team. È un patto tra il manager e il team, anche una regola di ingaggio. Quando le regole di ingaggio sono ben definite e il team viene portato dentro questo, le cose funzionano bene. Se non sono chiare, è lì che nascono le incomprensioni, che non è colpa di nessuno, siamo fatti così, e dobbiamo imparare a governare la complessità perché noi stessi siamo complessi.

Misurare l'innovazione industriale: KPI e contro-KPI

Invece, secondo te, come si misurano i progetti di innovazione? Ci sono dei KPI o delle strategie che utilizzi?

Magari dico cose note, ma ripeto sempre: value proposition, che dà i goal, e i goal si traducono in KPI. Parlando di innovazione, il tempo necessario per trasformare un'idea in un esperimento può essere un KPI. Il tempo di adozione, ho un'idea, faccio l'esperimento, mi piace, proviamo ad adottarlo: anche questo è un KPI, stiamo parlando di misure. Il numero di processi realmente modificati, perché faccio dei miglioramenti. Più difficile è magari misurare la riduzione della complessità: posso creare una misura di scalabilità, o di riutilizzo, cioè come abbiamo imparato a riutilizzare le cose, quindi abbiamo creato un metodo. Prima scrivevamo sempre codice da zero, oggi abbiamo creato moduli componibili che tolgono lavoro a basso valore e aggiungono valore perché arrivo prima alla soluzione componendo moduli preesistenti.

Restando vicino al piano produttivo, si può misurare la produttività reale, cioè cosa esce in più rispetto a quello che entra, non solo il bene tangibile ma anche tutti gli elementi intangibili che aumentano il valore di quell'artefatto: pensiamo al telefonino, 200 grammi di ferro e silicio che paghiamo mille euro, più ogni mese tutti gli abbonamenti che ci abbiamo dentro.

Cos'è "Human at the Edge"? La visione di Federico Milan sull'intelligenza artificiale

Partendo da questo, vorrei andare più in profondità su due aspetti: la tua posizione sull'intelligenza artificiale, cosa è secondo te, e il concetto che hai coniato di "Human at the Edge". Ce lo racconti?

Proviamoci. Non mi piace molto il termine "intelligenza artificiale", lo dico subito, perché le parole hanno sempre un significato e spesso ci portano fuori dal campo. Quella che chiamiamo AI, per me, è una tecnologia molto utile e vicina, che se ben usata dà soddisfazione, o meglio aiuta a essere intercalata nei processi. Prima ancora di definire cosa sia l'AI nell'industria, di sicuro non è magia: è una tecnologia che aiuta a estrarre significato dai dati che l'automazione genera, se parlo di AI applicata all'automazione, o dai dati generati dall'industria, se parlo di AI applicata all'industria.

Se pensiamo che l'informatica è l'informazione automatica, l'AI applicata all'informatica in senso stretto è un'automatizzazione di come sfruttare questi dati per chiudere un loop di controllo che ottimizza i processi. L'AI va vista come il kick-off per iniziare a ripensare i processi aziendali. È impensabile dire "che bello, c'è ChatGPT, lo inseriamo in ufficio", quello lo puoi fare a casa tua, ma in un contesto aziendale, ripeto quello che ho detto prima, non dobbiamo mai pensare che un'attività venga fatta dalla buona volontà della persona, ci deve essere un processo che la guida. Non dobbiamo mai dare una tecnologia alle persone senza delle regole di ingaggio. Quando entriamo in un contesto di AI in azienda, dobbiamo prima costruire e rivedere i nostri processi, capire dove introdurre queste nuove tecnologie.

E qui ci accorgiamo che le AI, oggi parliamo di agenti, sono nostri colleghi: l'azienda non è più fatta solo di persone, o non lo sarà più, ma di persone e di agenti che non sono persone. Rubando un concetto da Bruno Latour, l'Actor-Network Theory, tutti noi siamo attori in un ecosistema di lavoro, di industria, e collaboriamo insieme: per questo dobbiamo ricostruire i processi, partire da loro, capire dove sono questi attori, quali sono i punti di comunicazione, dove si chiude l'informazione, quali sono i centri di potere, di conoscenza, di interazione.

Su questo, sentiamo sempre parlare di human in the loop, un termine sempre più usato con l'Industry 5.0. A me non piace, perché significa mettere l'uomo alla pari dell'intelligenza artificiale, e io non ci sto: per me dobbiamo mantenere l'uomo dentro il ciclo decisionale, e voglio provare a spingere il concetto un po' oltre, adottando l'idea di "Human at the Edge". L'uomo non deve stare continuamente dentro le micro-decisioni automatizzate, deve stare sul bordo, sul confine cognitivo del sistema. La macchina, la tecnologia, gli algoritmi gestiscono ciò che conoscono, automatizzano ciò che è ripetibile e propongono ciò che possono inferire. L'uomo interviene quando emerge l'eccezione, l'ambiguità, il nuovo. Non uso l'uomo per far peggiorare ciò che la macchina fa già bene, ma usare l’uomo dove il suo contributo cognitivo dà maggior valore. L'edge può essere un confine fisico, il lean ci dice di andare sul gemba a vedere cosa fanno, il kaizen, il miglioramento continuo, ma può essere anche un confine astratto, dove la capacità cognitiva che solo l'uomo può dare, per fortuna ancora per molto tempo, porta miglioramento. Da qui nasce l'idea: human at the edge, non human the loop. Non voglio essere governato da una macchina, devo governare la macchina, il processo.

Trovo affascinante questa visione, ed è molto diversa da quella che viene prospettata oggi, dove l'automazione basata su AI viene venduta come sostituzione della persona. Il tuo modo di vedere la situazione mi sembra molto più vicino alla realtà, dove le persone danno ancora qualcosa che la macchina non è in grado di dare, almeno per oggi. Non so fare previsioni sui prossimi cinque anni, ma oggi è così. Il tuo punto di vista sull'utilizzo dell'AI generativa come interfaccia conversazionale verso la macchina, invece, qual è?

Perché l'AI generativa è la nuova interfaccia tra uomo e macchina

È un aspetto che vedo interessante e che già abbiamo iniziato a usare, perché rappresenta una trasformazione enorme. Deriva da un paradigma vecchio: pensiamo al technology-centered design contro l'human-centered design. Qualche anno fa partivamo da un concetto in cui noi tecnici sviluppavamo bene il progetto, ma era verticalizzato: pensiamo a un impianto degli anni '90, funzionava, aveva tecnologia, era composto da tante macchine, ma ogni macchina era verticalizzata. Dovevi conoscere la macchina che depositava il materiale, spostarti di due metri e conoscere quella che pressava, spostarti ancora e conoscere quella successiva. Pensiamo alle interfacce, dovevi conoscere tante interfacce, tanti modi di operare, tanti modi di programmare. L'uomo doveva adattarsi alla tecnologia.

Poi sono nati una serie di paradigmi, pensiamo alla UX, ma prima ancora alla situation awareness, e Norman, prima di tutti, ha detto: no, l'uomo deve essere al centro e quindi Human-centered design: le tecnologie funzionano bene, ma l'interfaccia verso l'operatore deve essere semplice, è la tecnologia che si adatta all'uomo, non il contrario. Le interfacce si sono modificate rendendo l'informazione sempre più centrale, pensiamo anche al PC: una volta c'era il DOS, ogni singola riga di codice per fare qualcosa, adesso c'è un'interfaccia dove puoi fare tutto insieme. Aggiungiamo un bit in più, la capacità di usare il linguaggio naturale, ed ecco che l'AI generativa nell'applicazione normale diventa utile: non devo più imparare il linguaggio della macchina, non devo più ricordarmi di premere quel pulsante, parlo come stiamo parlando noi due. Questo aiuta a chiudere la distanza, ma aggiunge anche altri problemi.

Quali sono, secondo te, questi problemi? E in secondo luogo, l'AI generativa può essere anche uno strumento per far emergere correlazioni tra dati e informazioni che oggi non siamo in grado di individuare? Ha senso usarla anche nell'analisi dei dati?

Quando parliamo di AI generativa, spesso ci focalizziamo sui modelli linguistici, tipo ChatGPT. Il problema che osservo è che la macchina ci dà risposte in linguaggio naturale molto convincenti, e come esseri umani siamo attratti dalle risposte quando sono ben fatte e ci convincono. Cosa succede? Non ci poniamo più la domanda se quello che ci ha detto è corretto, non lo mettiamo in dubbio. Questo è un grosso problema, ed è il motivo per cui dicevo che prima di adottare l'AI in azienda dobbiamo costruire dei processi. Non solo perché lo dice l'AI Act, ma perché dobbiamo mantenere l'attenzione delle nostre persone, che non devono fidarsi ciecamente dell'output. Faccio un esempio: una persona adeguatamente addestrata, quando vede l'interfaccia grafica di una macchina, capisce se sta lavorando nella curva di lavoro buona, se è sottoutilizzata, perché ha la capacità di leggere grafici e carte di controllo e capire come sta andando il processo, anche fare previsioni. Se complico troppo quei grafici, rendendoli più belli e informativi, si fa più fatica a interpretarli, ma resta comunque uno sforzo mentale attivo: vedo, traduco quello che vedo graficamente in un concetto, applico un'analisi. Se invece la macchina mi dice direttamente "va tutto bene", sono contento, ma perché devo comunque chiedermi "sei sicuro?". Mi dà la risposta che piace a me, ma se sono una persona di innovazione non voglio una risposta bella, voglio dati che mi permettano di fare un'altra domanda, non a te ma a me stesso, per capire se posso migliorare o se quello che mi stai dicendo è vero solo per una piccola parte del quadro.

Qui torniamo al concetto di KPI: se tutto è basato su un solo KPI è un problema. Banalizzando, se prendo un KPI di produzione, quanti oggetti ho prodotto nell'ora, il setup è di 10 all'ora e ne produco 15, il direttore di produzione è contentissimo. Ma qual è il contro-KPI? Serve un KPI di qualità, perché se prima facevamo 9 oggetti di qualità su 10 e adesso ne facciamo 7, va bene aver prodotto più velocemente oppure no? Ad ogni KPI serve un contro-KPI, e ad ogni risposta dell'AI serve almeno una contro-risposta. Torniamo sempre al concetto di processo.

Sul fidarci: la macchina è più brava di noi ad analizzare i dati, ma dobbiamo fidarci? Secondo me no, e lo dico in modo semplice e banale. Quando prendiamo i dati e facciamo correlazioni, la correlazione ci dice solo quanto due eventi sono potenzialmente legati tra loro, non che uno causi l'altro. Se do in pasto dei dati alla macchina, l'esempio classico che troviamo in tutti i libri è che d'estate aumenta la vendita di gelati e aumenta anche il numero di annegamenti: se faccio una correlazione, sembra che più gelati vendo più annegati ci siano, ma non è vero, è solo perché d'estate si va al mare più spesso. La causa non è la vendita del gelato, è tutt'altra. Portando questo esempio in azienda, capiamo che parlare di correlazione dimenticandoci la causalità rischia di farci fare un errore molto grande. Più facile che l'AI generativa, mettendo insieme più contesti e attività, ci dia una correlazione piuttosto che una causalità. La causalità dobbiamo costruirla noi, oggi, attraverso un processo che definisce come deve essere misurata e valutata una misura, un dato, un report.

Manutenzione predittiva: perché il contesto conta più del modello

Come si sposa questo con il concetto di manutenzione predittiva?

Abbastanza bene. Prima di tutto serve un'infrastruttura che trasformi gli eventi in dati usabili, per raccogliere informazioni interessanti dall'ambiente e trasformarle in informazioni utili da trasferire a chi ne ha bisogno. C'è tanta letteratura sulla manutenzione predittiva, spesso legata a macchine rotanti o a processi di vibrazione noti, dove c'è un bel beneficio perché si è costruito un modello sufficientemente utile da essere analizzato.

Quando invece abbiamo sistemi più complessi, dove la macchina è soggetta non solo all'operazione che svolge ma anche all'ambiente che la contiene, questo non funziona altrettanto bene. Possiamo costruire un modello che predice numericamente molto bene l'andamento, con precisioni anche del 98-99%, ma poi, conti fatti, non vuol dire nulla: se ho un processo che lavora benissimo e produce pochi o nessuno scarto, dire che ho una predizione del 99% o se non si rompe quasi mai, non porta nessun valore, perché finiamo comunque a lavorare sempre in modalità "run to failure". Che cos’è che ho capito? Se è una tecnica nota, è una cosa ben definita, torno all’esempio della macchina, lì le cose funzionano bene. Se però ho sistemi complessi che modificano la posizione a seconda delle variabili ambientali, lì bisogna utilizzare tutti i dati, non solo pressione, velocità, vibrazione della macchina, ma anche temperatura, umidità, se è lunedì o mercoledì, se siamo in inverno o in estate, se piove o no. Tutto questo aggiunge complessità e informazioni al modello.

Quindi non è sbagliato fare AI predittiva, ma va considerato con attenzione il set di dati da utilizzare per la predizione.

Esattamente. Il concetto è che quando si fa predizione non basta aggiungere un componente tecnologico: bisogna aprire un progetto per capire esattamente quali dati, in che modo e con quali tempistiche sono utili per estrarre le informazioni che servono. L'errore grande è pensare "ci metto qualcosa di intelligente che raccoglie i dati e mi dà una risposta". Non funziona così, funziona quando le cose sono semplici.

Come si integra la manutenzione predittiva con l'aspetto umano?

Entra in un contesto di maintenance: diventa un fattore abilitante che aiuta l'operatore a non essere stressato, a non dover guardare continuamente i dati, ma a vedere degli alert che attirano la sua attenzione solo quando serve valutare qualcosa. La mia visione è che si creerà un ambiente sempre più collaborativo, con figure specializzate, perché si va ad agire su più punti: le persone del service trovano un beneficio quasi immediato, non ricevono più solo la chiamata al telefono ma sanno già cosa capiterà a breve, quindi possono organizzare e pianificare. E se io, come azienda produttrice, riesco a pianificare, posso acquistare al momento giusto i beni di consumo da dare al cliente, e il cliente può attivare a sua volta il processo di acquisto, trovando ottimizzazioni. Avremo come clienti anche delle macchine, a breve.

Da dove iniziare per fare manutenzione predittiva basata sui dati

Se dovessi consigliare a un'azienda da dove cominciare per creare un sistema di manutenzione basato sui dati, cosa risponderesti?

Farei un processo di due diligence verticalizzato sul tipo di macchina o di prodotto che l'azienda realizza. In base a quello, andrei a guardare il reparto acquisti o il processo di manutenzione, che tipo di chiamate riceve, concentrandomi su quel 20% di attività che dà l'80% del valore. Da lì capirei cosa utilizzare: molto spesso si scopre che non serve aggiungere sensori, ma si possono fare pianificazioni semplici, aiutate dai nuovi strumenti AI, che danno già un beneficio.

Con questa analisi si può poi strutturare la raccolta del dato, perché raccogliere il dato costa: serve un sensore, un applicativo software, una connessione internet, un cloud anche se locale, qualcosa che contenga quel dato, e serve fare inferenza. Se siamo un'azienda, dobbiamo ottimizzare questi costi e trasformarli in valore, e lo si fa solo se si attiva un processo di analisi serio: non prendere la tecnologia, ma partire dal bisogno. È la parte più difficile, perché richiede molta analisi, ma bisogna partire da ciò che già esiste, fare un'ipotesi su cosa conviene usare, cosa conviene toccare e quale beneficio si ottiene. Mettersi un goal chiaro: cosa vogliamo ottenere.

Visto che siamo in chiusura, ti farei un'ultima domanda che facciamo a tutti gli ospiti, probabilmente una delle più importanti dell'intervista: se potessi tornare indietro all'inizio della tua carriera, quali sono i tre consigli che daresti al giovane Federico?

Visto quello che ho imparato, direi: studia i fondamentali, non solo le tecnologie, perché le tecnologie cambiano velocemente mentre i principi rimangono nel tempo. Innamorati della filosofia, la tecnologia viene dopo.

La seconda: nell'innovazione cerca le contraddizioni. Se tutti ti dicono che devi scegliere tra A e B, prova a chiederti se il vero problema non sia proprio l'eliminazione di quella scelta. È forse la lezione più importante che mi porto dentro, aver letto Altshuller e il fatto che dobbiamo, in qualche modo, risolvere contraddizioni.

La terza forse deriva dalla prima: non innamorarti mai della tecnologia, ma del problema che vuoi risolvere. C'è una battuta che dice che gli ingegneri amano talmente tanto risolvere i problemi che, quando non ce ne sono, ne inventano uno.

Bella questa, la riutilizzerò. Federico, ti ringrazio per il tempo che ci hai dedicato, è stato davvero un piacere parlare con te. Apprezzo molto la generosità con cui hai raccontato la tua esperienza, il tuo percorso, il tuo modo di affrontare i problemi. Per chi ci ascolta e volesse approfondire, trovate i riferimenti dei libri di Federico nelle note dell'episodio, e avete la possibilità di iscrivervi per essere aggiornati sull'uscita dei prossimi video. Mettete un like se il video vi è piaciuto. Grazie ancora Federico, è stato un piacere.

Grazie a voi, il piacere è tutto mio. Un saluto, a presto!

Grazie a tutti per averci ascoltato, ci risentiamo al prossimo episodio di Expert Talks.