«Il PLM è morto» — lo sento dire di continuo. Vero, forse. E anche falso, allo stesso tempo. Perché dipende da cosa si intende per PLM. Da una certa prospettiva, l’affermazione può avere un senso. Non dalla mia, sia chiaro. Perché io penso che il PLM sia più vivo che mai. E lo spiego volentieri.
Software PLM o disciplina PLM? La differenza decisiva
Partiamo dalla domanda su cosa voglia essere il PLM, in fondo.
Prima lettura
Il PLM sono le grandi suite — Teamcenter, Windchill, ENOVIA. Sistemi monolitici che promettono di rappresentare l’intero ciclo di vita del prodotto. Spoiler: per questa lettura, l’affermazione “il PLM è morto” ha — forse — una sua ragione. Non necessariamente, ma è sostenibile.
Seconda lettura
Il PLM è la disciplina che comprende tutto ciò che appartiene al ciclo di vita del prodotto. Gestione della configurazione, gestione delle modifiche, tracciabilità, integrazione dei sistemi lungo tutto il ciclo di vita. Per questa lettura, il PLM è tutt’altro che morente. Al contrario, si sta appena sviluppando in ciò che ha sempre voluto essere.
La mia visione del PLM è sempre stata la seconda lettura. Per me descrive ciò che il PLM intende davvero — e a chi questo sembra troppo di parte: Gartner definisce il PLM come “philosophy, process and discipline supported by software”. Disciplina prima di tutto, software come strumento. Ciononostante, molti continuano a intendere il PLM più come una categoria di prodotto per suite nel contesto engineering.
Cosa muore: le suite PLM monolitiche
Che queste note suite PLM, spesso monolitiche, restino il modello dominante è oggi più che mai in forse. Perché la direzione del viaggio è chiara, anche se il processo è lento. Tre riflessioni in merito:
Primo: la convinzione che un solo sistema possa coprire tutto non è sostenibile in molti casi. I fornitori di PLM legacy sono cresciuti tramite acquisizioni, non (solo) tramite innovazione architetturale. Il risultato, come lo descrive l’analista PLM Oleg Shilovitsky (che peraltro vende lui stesso un approccio PLM decentralizzato), sono “conglomerati di strumenti, tenuti insieme da integrazioni — a volte con modelli di dati incompatibili”. Chi ha vissuto questa esperienza dolorosa, annuisce. Chi non l’ha vissuta, la farà.
Secondo: il pendolo Make-or-Buy oscilla verso il Make — e l’IA accelera questa tendenza. Non perché gli sviluppatori ora scrivano codice dieci volte più velocemente. Ma perché domini PLM periferici ben definiti — piattaforme di release, workflow di gestione delle modifiche, soluzioni di tracciabilità specifiche — diventano improvvisamente realistici da sviluppare in proprio. Ciò che prima falliva per sforzo e rischio di manutenzione, oggi si può realizzare con team molto più piccoli. Questo vale forse (ancora) non per un’intera architettura PLM. Ma per quei punti in cui le soluzioni monolitiche sono sovradimensionate e generano comunque costi di licenza annuali, il calcolo cambia.
Flashback su un progetto a cui ho partecipato io stesso qualche anno fa: un cliente voleva costruire una propria piattaforma di release software. Tutto sviluppato internamente. All’epoca ero scettico, e avevo raccomandato di verificare quali soluzioni ci fossero già sul mercato. Il coding assistito dall’IA, che oggi rende questi progetti molto più accessibili, allora non esisteva ancora. Il cliente aveva già deciso, e data la sua dimensione era fattibile, anche se costoso, non optare per una soluzione standard. Forse anche troppo costoso. Fast forward: con le possibilità di oggi, la mia valutazione sarebbe molto probabilmente diversa, il che non significa che oggi rifiuterei la soluzione “standard”. Ma le tendenze stanno cambiando.
Terzo: il PLM come archivio documentale è acqua passata — le aspettative in realtà sono sempre state più alte. Che il PLM debba essere più di un archivio documentale glorificato è ormai un dato di fatto condiviso. Ma il consenso è tutt’altro che operativo, e nella realtà operativa l’azione resta indietro rispetto alla consapevolezza. Eppure l’aspettativa su ciò che un sistema PLM moderno dovrebbe effettivamente offrire non è così irraggiungibile: un modello dati di prodotto strutturato, che rappresenti in modo leggibile dalla macchina componenti, varianti, dipendenze e storici delle modifiche. Tracciabilità continua dal requisito, passando per codice e CAD, fino al prodotto finito sul campo. Integrazione di tutti i processi rilevanti, dalla A di After Sales alla Z di archivio disegni.
Solo che: uno strumento buono per tutto non è davvero buono per nessuno. Vale per i coltellini svizzeri, e vale per le suite PLM monolitiche. Il modello dati è generico perché deve esserlo. L’integrazione totale non esiste, perché in azienda ci sono sempre anche altri mondi di sistemi (parola chiave: ERP). E: chi vuole costruire un modello dati di prodotto davvero profondo e specifico per il proprio dominio — uno che rappresenti con precisione i propri componenti, varianti e processi — nel monolite si trova di fronte a sforzi di personalizzazione che possono potenzialmente erodere ogni valore aggiunto. Gli strumenti specializzati con standard aperti evitano almeno in parte questo problema, perché sono pensati fin dall’inizio per l’interoperabilità, non per la completezza.
Cosa non muore: il PLM come disciplina, perché il bisogno cresce
Un fatto: i prodotti diventano più complessi. I confini tra meccanica, elettronica e software si sfumano.
Esempio automotive: secondo le stime, gli OEM perdono tra 500 milioni e un miliardo di dollari USA all’anno per richiami fisici che tecnicamente sarebbero possibili come aggiornamento OTA (eSync Alliance, 2023; ABI Research, 2023). Che gli aggiornamenti OTA non siano ancora diffusi quanto sarebbero tecnicamente possibili è dovuto anche alla complessità dei prodotti. Un’auto non è più una macchina semplice come una volta, riparabile in caso di dubbio in qualsiasi officina nel deserto. Perché un aggiornamento OTA funzioni, e parlo per esperienza, serve una macchina ben oliata che mantenga una visione d’insieme su tutti i prodotti sul campo, la loro configurazione, lo stato del software e tutte le dipendenze.
Per questo: gestione della configurazione, gestione delle modifiche, tracciabilità lungo tutto il ciclo di vita… il bisogno di professionalizzare queste discipline è tutt’altro che in calo. Al contrario, diventa più esigente.
Certo, chi dice “il PLM è morto” e ha ancora sulle spalle un progetto PLM che non ha dato i risultati promessi, lo capisco. Solo che forse ha confuso il sintomo con la malattia. Lo strumento ha vacillato, ma la disciplina, la continuità e il mindset che ci stanno dietro probabilmente non sono mai stati davvero vissuti, e forse nemmeno compresi.
Una frase attribuita al veterano del PLM Rob Ferrone dice più di dieci set di slide: «I miei primi cinque anni non sapevo nemmeno che stessimo facendo PDM o PLM — ma lo stavamo facendo.». Se vale anche il contrario — se le aziende comprano il software ma non implementano mai la disciplina — allora la frustrazione è comprensibile, ma colpisce il modo in cui il PLM è stato introdotto, non la disciplina in sé.
Solo il 13% pensa di non poter lavorare senza il PLM
A questo si aggiunge un dato che fa riflettere: solo il 13% delle aziende che usano il PLM dice di non poter lavorare senza di esso. Che sia il 10, il 13 o il 20% è quasi irrilevante. L’affermazione vera sta nel ragionamento inverso: la maggior parte delle aziende crede di poter fare a meno del PLM. No. Non possono. Ogni azienda che sviluppa e produce prodotti gestisce il PLM — in una forma o nell’altra. La domanda è solo se capisce cosa sta facendo…
La vera sfida: architettura assente e organizzazione insufficiente
Il Digital Thread — la traccia dati continua e bidirezionale dal requisito fino all’esercizio — è la visione che è sempre stata strettamente legata al concetto di PLM. “Single Source of Truth”, tracciabilità dal requisito fino al campo: i vendor lo promettono già dagli anni 2000. Purtroppo, fin troppo spesso la promessa non è stata rispettata, per i motivi più diversi:
A fallire, sorprendentemente, è raramente il software. È ciò che manca intorno al software: strutture informative e dati. Ontologie. Un’organizzazione disposta ad affrontare seriamente i propri processi. In breve: architettura. E questa non nasce da sola — che si compri o che si costruisca.
Chi compra, compra una casa prefabbricata. E chi compra una casa prefabbricata deve essere pronto ad accettare planimetrie predefinite. Anche se questo significa abbandonare abitudini a cui si è affezionati e abituarsi a nuovi flussi di lavoro. Questo, certo, non avviene da solo. È lavoro. Ed è esattamente questo lavoro che si tende a evitare — i propri processi consolidati sono spesso una specie di sacro graal, e il successo avuto finora sembra persino darne ragione. Solo che: chi poi piega il software standard invece di adattarsi, si porta in casa gli sforzi di personalizzazione che possono erodere ogni valore aggiunto. Il fallimento, a quel punto, non è un problema di software. È un problema di compiti a casa non fatti.
Chi costruisce non ha il problema della planimetria — ma ne ha un altro. Strumenti PLM a cui manca ancora qualche funzionalità desiderata, più la nuova disponibilità dello sviluppo software assistito dall’IA: tutto questo spinge rapidamente verso la decisione di voler costruire qualcosa in proprio. Sia “from scratch”, sia come collegamento molto personalizzato di strumenti diversi. Si può fare, come visto sopra — il calcolo si è effettivamente spostato. Ma: un’architettura Digital Thread continua richiede a maggior ragione un’architettura. Chi si limita a costruire senza criterio, costruisce un panorama di strumenti che all’inizio funziona più o meno, dopo poco tempo diventa quasi impossibile da mantenere — e prima o poi esplode in faccia. Un saluto all’IT fatta di Excel.
Ergo: investire in organizzazione e architettura informativa non è un’opzione, è il biglietto d’ingresso. Su entrambe le strade. Chi l’ha capito — e solo chi l’ha capito —, trova interessante l’opzione Make: perché se il lavoro architetturale va fatto comunque, il vantaggio del monolite è minore di quanto suggerisca il suo cartellino del prezzo. Un approccio decentralizzato, lontano dalle suite consolidate, oggi più che mai merita almeno di essere preso in considerazione. Potrebbe valerne la pena.
Ma torniamo alla domanda iniziale. Il PLM è morto?
❤️ PLM vive
Se con PLM si intende la disciplina (e a questo mi attengo), allora la risposta è chiara: il PLM è più vivo che mai. I requisiti non diminuiscono. I prodotti non si semplificano. E i costi di trascurare questa disciplina aumentano.
Se i grandi monoliti PLM tireranno le cuoia? Non lo so, e mi tengo lontano dalle profezie. Gli argomenti a favore sono quantomeno plausibili. Ma i vendor PLM non sono stupidi — vedono anche loro i cambiamenti che vediamo tutti noi. Architetture più aperte, offerte più modulari, SaaS — stanno già arrivando, e in alcuni vendor più che in altri. Se funzionerà, lo deciderà il mercato.
Long live PLM 😉🖖
Domande frequenti
Il PLM è morto o no?
Dipende dalla lettura. Come suite monolitica (Teamcenter, Windchill, ENOVIA), l’affermazione merita almeno una discussione. Come disciplina — gestione della configurazione, gestione delle modifiche, tracciabilità, ecc. — è semplicemente sbagliata. Questa disciplina diventa più importante, non superflua.
Cosa distingue il software PLM dal PLM come disciplina?
Il software è lo strumento, la disciplina è lo scopo che sta dietro. Gartner definisce il PLM come “philosophy, process and discipline supported by software” — disciplina prima, strumento dopo. Un progetto PLM fallito, quindi, non significa che la disciplina sia fallita, ma spesso solo che non è mai stata davvero vissuta.
Conviene ora sviluppare il PLM internamente (Make) piuttosto che comprare una suite PLM (Buy)?
Il calcolo cambia, perché lo sviluppo assistito dall’IA rende realisticamente costruibili in proprio domini PLM periferici ben definiti. Per un’architettura PLM completa, questo per lo più (ancora) non vale. E: anche il Make non risparmia il lavoro architetturale — chi si limita a costruire senza criterio finisce con un panorama di strumenti che diventa presto impossibile da mantenere.
Cos’è il Digital Thread, e perché è importante?
La traccia dati continua e bidirezionale dal requisito, passando per CAD e codice, fino al campo — la visione che il PLM promette fin dagli anni 2000. Spesso non viene realizzata perché manca l’architettura dietro, non perché il software non ne sarebbe capace.
