Dal modello al mindset: la vera sfida del Model-Based Systems Engineering
- Salvatore Marangio
- 25 lug
- Tempo di lettura: 21 min
Aggiornamento: 28 lug
Il fallimento dell’MBSE: viva il MBSE!
Perché il MBSE fallisce (e come farlo funzionare davvero)
di Gian Giacomo Ermacora e Castrese Di Marino.
Una volta era il “Lean”. Poi il “Digital Twin”. Oggi è l’“AI ovunque”. Ogni azienda rincorre l’onda del momento. Ma seguire i trend senza comprendere le basi è come costruire una casa partendo dal tetto. La giustificazione più ricorrente per spiegare perché non si fa davvero MBSE è: “Abbiamo acquistato il miglior tool per il Model-Based Systems Engineering, ma dopo tre mesi nessuno lo usava.”
Ma quindi… perché succede?
Il Model Based Systems Engineering (MBSE), evoluto negli ultimi periodi nell’acronimo MBS(S)E (ovvero dove la seconda “S” indica il Software, rendendo quindi il termine quale Model Based Systems and Software Engineering), è un approccio all’ingegneria dei sistemi complessi basato sull’utilizzo di modelli formali come fonte primaria di informazione, in contrapposizione al più tradizionale uso di documentazione testuale.
Il MBSE non è di recente concezione, in realtà si è iniziato a parlare di Model Based già intorno agli anni 70 del 1900, poi con la nascita e diffusione dei sistemi di disegno CAD, il concetto di “modello virtuale” si è sempre più evoluto ed affermato nell’ingegneria. Mentre il CAD definisce l’oggetto fisico ed è il perfetto rappresentante del “dominio della soluzione”, il Model Based Systems Engineering, invece, si colloca perfettamente a cavallo tra il dominio del problema e quello della soluzione. L’MBSE nasce con l’obiettivo di permettere un naturale flusso tra i domini, grazie alla visione olistica del sistema, del suo comportamento da e verso l’utilizzatore e in relazione al mondo circostante, così come le relazioni (implicite/esplicite o estrinseche/intrinseche) con i sistemi con i quali il Sistema di Interesse (SoI) si relaziona.
In termini formali, l’MBSE è stato definito come “l’applicazione formalizzata della modellazione per supportare le attività di definizione dei requisiti, progettazione, analisi, verifica e validazione di un sistema, a partire dalle fasi concettuali e per tutto il suo ciclo di vita”. Quindi in teoria questo approccio promette indubbi benefici, ovvero una maggiore coerenza e tracciabilità delle informazioni progettuali, una migliore gestione dei cambiamenti, una grande rivoluzione dell’integrazione interdisciplinare e una notevole riduzione di potenziali errori lungo il ciclo di sviluppo del Sistema di Interesse.
Purtroppo, però, la realtà dell’adozione del MBSE (e del MBSSE) è molto più complessa.
Innumerevoli organizzazioni, di qualsiasi dimensione, hanno intrapreso iniziative MBSE, incontrando gravi difficoltà o addirittura fallimenti delle stesse iniziative, non realizzando quindi alcuno dei benefici attesi.
In questo articolo vogliamo analizzare in profondità le ragioni di tali fallimenti, articolando in particolare tre aspetti chiave, ovvero (1) i limiti intrinseci del MBSE, (2) le criticità legate alla cultura organizzativa e agli strumenti e (3) alcuni casi concreti in cui l’adozione del MBSE è fallita, oppure ha avuto successo solo grazie a trasformazioni radicali dell’organizzazione.
I limiti intrinseci del MBSE
L’obiettivo ambizioso primario del MBSE è quello di fornire un approccio alla modellazione per descrivere le caratteristiche di un sistema complesso. Purtroppo, però, presenta alcuni limiti che, se non vengono compresi opportunamente, possono essere d’intralcio per l’efficacia dell’intero approccio.
Ambiguità concettuali e standard immaturi
Incredibilmente il termine stesso MBSE genera spesso confusione. Come si citava nell’incipit dell’articolo, il concetto di Model-Based non è recente. Infatti, negli anni la comunità scientifica ed ingegneristica ha proposto molte varianti e interpretazioni del termine. Infatti, in ingegneria la parola “modello” è estremamente generica, può includere qualsiasi forma di rappresentazione più o meno semplificata, per esempio diagrammi, simulazioni, prototipi, etc. Proprio questa ambiguità concettuale ha portato a profondi fraintendimenti, tra cui non in ultimo quello dell’equazione (errata) “MBSE = SySML”, ovvero l’accezione per la quale l’adozione del MBSE significhi unicamente utilizzare il SySML. La realtà suggerisce che il SySML sia solamente uno degli strumenti possibili e tale equivalenza ha generato timori e incertezze. Ad oggi il SySML, e così sarà fino al rilascio finale ed ufficiale della versione 2.0, è un linguaggio che di fatto non è pienamente maturo ed è "interpretato" in modi leggermente diversi da molti vendor di software. È spesso criticato per la sua complessità e incompletezza, al punto che in molte occasioni si preferisca utilizzare addirittura strumenti di disegno generici, persino come Microsoft Visio, pur di evitare la curva di apprendimento di SySML. Essendo appunto un linguaggio e non un metodo, il SysML porta con sé la necessità di adottare un metodo di lavoro ben definito che sottintende di seguito insiemi di processi che, per rendere il tutto ancora più articolato, introducono un ulteriore livello di complessità, per esempio l’adozione di un framework, che se da una parte indirizza l’operatività, dall’altra richiede studio e rigore applicativo.
Questa immaturità degli standard e dei metodi si traduce spesso nella mancanza di indicazioni chiare e condivise: ancora oggi, infatti, non esiste una metodologia universalmente riconosciuta che spieghi in modo pratico come applicare l’MBSE ai progetti reali. Spesso, inoltre, la formazione si limita agli strumenti software e ai linguaggi specifici, come ad esempio SysML, ma raramente offre una guida passo-passo che permetta di costruire concretamente un modello davvero efficace e utile. Infatti, gli standard di riferimento forniscono indicazione su cosa fare, che tipo di artefatto usare e in ultima istanza, quali devono essere le capacità dei software a supporto, ma si fermano li, a semplici indicazioni, per quanto precise e puntuali. Come se la conoscenza delle regole grammaticali di una linea fosse sufficiente per intraprendere una conversazione.
Questo porta spesso i team di progetto a sentirsi un po' persi, costretti a prendere decisioni cruciali quasi "a tentoni" (Che notazione usiamo? Fino a che livello dobbiamo spingerci? Come possiamo davvero i requisiti?), soprattutto in caso di mancanza di una figura guida esperta che faccia da mentor. In altri termini, se guardiamo alla questione sotto il profilo pratico e metodologico, l’MBSE presenta ancora diversi punti non ben definiti e una maturità non del tutto raggiunta; il rischio concreto, quindi, è che si finiscano per creare modelli poco coerenti e, di conseguenza, di limitata efficacia sul campo.
Rigidità e integrazione limitata degli strumenti
Gli strumenti software impiegati per l’MBSE portano a loro volta altri limiti intrinseci, risultando spesso rigidi e poco interoperabili con gli altri strumenti ingegneristici già comunemente utilizzati nei vari domini, dal requirements management e giù per l’Engineering Lifecycle Management toolchain, al PLM e alla simulazione fisica.
La teoria vorrebbe che l’MBSE potesse abilitare finalmente il “digital thread” che dovrebbe collegare tutte le discipline, ma sappiamo bene che in pratica spesso si inciampa proprio sull’integrazione. I tool dedicati al MBSE faticano a dialogare con software specializzati (CAD meccanici, ambienti di simulazione, strumenti di project management, ecc.), causando potenziale frammentazione invece che integrazione. La soluzione naturale è quella del trasferimento manuale dei dati tra i sistemi, con conseguenti inefficienze ed errori. Anche nel caso nei casi esistano sistemi di integrazione, sono spesso soluzioni costose e fortemente personalizzate oppure invasive riguardo la definizione dei processi.
Un ulteriore tema importante è quello dell’usabilità: i tool MBSE hanno curve di apprendimento ripide, le interfacce non sono sempre intuitive e possono scoraggiare gli utilizzatori. La necessità di competenze specialistiche per usare efficacemente questi strumenti fa sì che i modelli MBSE potenzialmente restino “chiusi” in mano a pochi specialisti. Di conseguenza, il modello rischia di non essere consultabile o comprensibile dall’intero team di progetto: stakeholder non addestrati al linguaggio formale (es. manager, fornitori, o anche ingegneri di altre discipline) faticano a interpretare diagrammi SysML complessi.
Questo limita l’accessibilità del modello e lo depotenzia, rischiando di mantenerlo confinato in un silo invece di fungere da Single Source of Truth. Ma quando il modello è davvero centrale (accessibile, interrogabile, tracciato) non è più solo un contenitore tecnico, diventa il punto di riferimento comune per analizzare, discutere, decidere.
Il valore dell’MBSE emerge proprio lì: ovvero, nella capacità di fornire una fonte unica e verificabile di informazione, che elimina ambiguità, riduce i fraintendimenti tra ruoli diversi, e abilita un dialogo continuo tra domini.
Senza questa condizione, il rischio è che ogni funzione torni a parlarsi attraverso i propri strumenti (documenti, fogli di calcolo, presentazioni) perdendo di nuovo allineamento e coerenza.
Eccessiva astrazione e distacco dalla realtà ingegneristica
L’astrazione è il mantra del MBSE: "Bisogna creare solo modelli concettuali di alto livello, lontano da soluzioni specifiche!". Ma quindi il know-how aziendale che fine fa?
Infatti, lo spingersi ad un’astrazione troppo esasperata può allontanare dalla realtà concreta dell’ingegneria. In alcuni contesti industriali si è notato che, se l’MBSE non viene integrato opportunamente con i processi aziendali (i quali a loro volta devono essere pronti per ricevere l’MBSE), si rischia di finire ad operare in un silo separato, a volte persino come esercizio di documentazione formale parallelo al lavoro pratico degli ingegneri.
I team tecnici, soprattutto quelli molto orientati al risultato concreto, spesso vedono i modelli MBSE come qualcosa di teorico, distante dal lavoro “vero”, quasi un esercizio accademico che non si sporca le mani con i dettagli pratici. Questo pregiudizio può diventare un freno all’adozione: il modello finisce per vivere in un mondo a parte, senza incidere realmente sulle decisioni progettuali di tutti i giorni. E così, paradossalmente, si perde proprio il senso dell’MBSE.
Un altro rischio legato all’astrazione è l’“over-modelling”: la tentazione di rappresentare ogni singolo dettaglio del sistema, inseguendo l’idea (spesso illusoria) di una rappresentazione digitale perfetta.
Questa convinzione è in realtà una trappola concettuale piuttosto insidiosa: l’idea, molto diffusa, che un modello per essere davvero utile debba descrivere tutto del sistema, nel minimo dettaglio possibile.
In realtà, provare a modellare ogni vite, ogni cavo o ogni bit di un sistema complesso è semplicemente irrealistico. Le risorse – tempo, budget, energie – si esauriscono ben prima di arrivare in fondo. Il rischio? Perdere di vista lo scopo del modello stesso: supportare le decisioni, non diventare un’impresa enciclopedica.
Il vero valore di un modello non sta nella sua completezza enciclopedica, ma nella sua capacità di essere un’astrazione mirata: deve essere abbastanza dettagliato da rispondere alle domande progettuali rilevanti, né più né meno.
Come sottolineato anche in uno studio della NASA, è essenziale “modellare solo fin dove serve per rispondere alla domanda in esame”. Andare oltre rischia di trasformare la modellazione in un esercizio sterile, disconnesso dalla realtà operativa.
Se questo principio viene trascurato, l’MBSE può generare modelli ipertrofici, complessi da mantenere e ancora più difficili da tenere allineati con l’evoluzione del sistema reale. Il risultato? Frustrazione, perdita di fiducia nel modello e nel metodo.
Quindi l’astrazione è la grande forza dell’MBSE, ma come ogni strumento potente, va usata con criterio. Troppa astrazione – o male indirizzata – può produrre modelli scollegati dal mondo reale e dalla realtà aziendale, di conseguenza, poco utili per chi deve prendere decisioni operative.
Critiche alla cultura e agli strumenti MBSE
La maggior parte dei fallimenti nell’adozione dell’MBSE derivaano da fattori organizzativi, culturali e legati agli strumenti, ovvero come l’MBSE viene introdotto e supportato in azienda.
Di seguito analizziamo le principali criticità riscontrate.
Competenze organizzative inadeguate
L’MBSE richiede specifiche figure professionali, con un mix non proprio comune di competenze, ovvero conoscenze di Systems Engineering tradizionali, padronanza dei linguaggi di modellazione formale, capacità di astrazione e allo stesso tempo la capacità di dialogo con le altre discipline.
Molte organizzazioni si sono accorte, a posteriori, di non disporre del capitale umano necessario e soprattutto di aver sottovalutato la necessità di investimento proprio in competenze e formazione.
Uno studio su casi aziendali osserva che “la generale mancanza di ingegneri esperti in MBSE” è uno dei principali ostacoli a un’implementazione di successo. In altre parole, si può acquistare il miglior tool sul mercato, ma se il team non possiede (o non sviluppa) le competenze per usarlo in modo efficace, l’iniziativa è destinata a incontrare serie difficoltà nel raggiungimento del successo auspicatostentare.
Curva di apprendimento ripida e resistenza al cambiamento
Introdurre l’MBSE implica il cambiare, in modo significativo, il modo di lavorare dei team di ingegneria e non si tratta di “imparare un nuovo software” di modellazione, quanto invece di fare un vero e proprio “switch di mindset”.
Questo shock culturale è un aspetto, come qualsiasi cambiamento, che può generare notevoli resistenze. La sindrome del “si è sempre fatto così” è un nemico da non sottovalutare: molti ingegneri con anni di esperienza nei metodi tradizionali possono percepire l’MBSE come un’imposizione burocratica o una moda passeggera imposta dall’alto.
Le aziende che hanno ottenuto negli anni successi significativi con l’approccio tradizionale document-centric tendono a “santificare” quei metodi, vedendo con sospetto qualsiasi novità che comporti rischi, fatica ed investimenti.
Si può dire senza essere smentiti che l’introduzione del MBSE cambi i ruoli e comfort zone – il Systems Engineer deve imparare a modellare formalmente, gli specialisti di dominio devono inserire la loro conoscenza nel modello, tutti devono consultarlo e contribuire.
Risulta evidente quindi che senza un chiaro valore immediato, il personale possa addirittura ribellarsi passivamente, ignorando il modello e continuando con i vecchi strumenti paralleli, facendo fallire l’iniziativa nel silenzio.
Un effetto ricorrente nei progetti di introduzione dell’MBSE è che viene percepito come un aggravio di lavoro, non come un modo più intelligente di lavorare. Se i team devono comunque redigere la documentazione tradizionale — perché lo impongono i clienti o i processi esistenti — e in più tenere aggiornato il modello, è inevitabile che lo vedano come una fatica doppia, non come un aiuto.
Questo porta a uno degli errori più comuni: un’adozione superficiale del MBSE, dove si introducono strumenti e formalismi senza gestire davvero il cambiamento culturale che serve. Senza formazione mirata, mentoring sul campo e un po’ di pazienza per superare l’inevitabile fase di assestamento, l’MBSE rischia di arenarsi contro la più dura delle barriere: quella mentale, quella del “non ci credo” e, ancora peggio, del “non ho tempo di imparare”.
Incapacità di adattarsi ai processi legacy
L’MBSE, per avere successo, in molti casi richiede di rivisitare i processi di un’organizzazione consolidati, spesso raffinati negli anni per prodotti specifici. Occorre mettere su un “re-engineering” del “modo” in cui un’organizzazione sviluppa i propri sistemi e prodotti.
Quando però l’adozione viene presentata da consulenti esterni o tool vendor semplicemente come se fosse una semplice transizione, emergono tutti i problemi legati all'adozione dell'MBSE esattamente come descritto precedentemente: scontro con la realtà dei processi in essere, inadeguatezza dell'ambiente e dei mezzi, scarsa o assenza di preparazione nelle persone, distacco dalla realtà aziendale ed infine narrazioni troppo astratte ed utopiche. Promesse di un cambiamento sistematicamente disattese.
Un frequente errore che viene commesso è di calare l’MBSE al di sopra dei flussi di lavoro esistenti e consolidati, senza apportarne alcuna modifica, per esempio aggiungere processi di modellazione come fase a sé stante, senza pensare come le informazioni possano poi fluire tra le discipline. Questo porta ad un modello che è scollegato, l’MBSE rimane un ramo secco parallelo alle altre discipline e agli altri processi tecnici.
Un aspetto da tenere in considerazione è che l’MBSE implica e richiede un approccio data-centrico e integrato, che proprio non si sposa con i concetti “legacy” document-centric.
L’organizzazione deve essere disposta a ridefinire ruoli, deliverable e flussi approvativi attorno al modello, pena il creare un mismatch: “gli ingegneri, abituati a certi strumenti e prassi, faticano a incorporare i modelli MBSE nella routine, con il risultato che l’MBSE diventa uno sforzo parallelo e sotto-utilizzato, invece di parte integrante del processo”.
Un esempio emblematico è la gestione dei requisiti: in molte aziende regna ancora sovrano il caro vecchio Excel o qualche tool legacy ormai parte del DNA aziendale. Se si introduce l'MBSE senza pensare a come integrarlo con questi strumenti, si finisce per dover tenere aggiornati i requisiti in due posti contemporaneamente — nel sistema storico e nel nuovo modello. Il risultato? Un vero incubo operativo, che fa perdere tempo, crea confusione e alimenta la tentazione di mollare tutto e tornare al metodo “che almeno funziona”. Quindi, quando il beneficio non è immediato, ma solo futuro, molti tecnici reagiscono con frustrazione e rifiuto: vedono solo un modello in più, non un lavoro migliore.
Non è affatto raro, anzi: in diversi progetti si finisce per abbandonare l’uso di SysML, semplicemente perché è “più scomodo” o “meno familiare” rispetto agli strumenti che si usano da sempre. Il modello, se non reso comprensibile e usabile, genera distanza invece che convergenza. SysML, con il suo formalismo, può intimorire. Ma è indicativo che la stessa sensazione emerga anche in ambito CAD: l’interazione col modello è comunque vissuta come macchinosa, scollegata, a volte imposta. È un chiaro segnale che il problema non è (solo) lo strumento, ma come viene percepito il valore del modello nel contesto di lavoro reale. Quando il nuovo strumento non si integra davvero nei flussi di lavoro esistenti, ma sembra solo un'aggiunta macchinosa, la sua sorte è segnata.
Il problema è che l’MBSE, se non prende il posto di un processo esistente ma si limita ad affiancarlo, rischia di diventare solo un altro peso da portare. E in ambienti dove i processi sono rodati da anni — con documenti standardizzati, revisioni formalizzate, checklist scolpite nella pietra — introdurre una novità è come provare a invertire la rotta di una petroliera col timone di un gommone. Serve molto più che un buon tool: serve coraggio organizzativo e una volontà reale di cambiare.
Abbracciare davvero l’MBSE non vuol dire semplicemente “aggiungere un modellino qua e là”: vuol dire rimettere in discussione l’intero impianto operativo dell’azienda. E questo, inutile girarci intorno, è uno sforzo enorme. Se non viene pianificato con cura — con il giusto commitment da parte del management e un coinvolgimento serio dei team di processo — l’MBSE rimane un’iniziativa di contorno, buona per le slide ma irrilevante nella pratica quotidiana.
Gli stessi esperti INCOSE lo dicono chiaro e tondo: non esistono modelli di processo “chiavi in mano” per integrare davvero l’MBSE nei flussi tradizionali. Ogni organizzazione deve costruirsi la propria formula, cucita su misura, supportati dalle persone giuste con mindset e preparazione adeguati. Il problema? Molti non lo fanno, per timore o per mancanza di intraprendenza o competenze chiave. Oppure, peggio, ogni progetto si inventa la propria versione estemporanea, generando confusione, disallineamenti e incoerenza sistemica.
Il risultato è che, senza un intervento deciso sui processi consolidati — e sulle abitudini che li sorreggono — l’MBSE rimane un corpo estraneo, che il sistema azienda finisce per rigettare come un trapianto non compatibile.
Mancanza di supporto dal top management
Un aspetto spesso sottovalutato — ma decisivo — è il coinvolgimento attivo del top management, soprattutto affichè ai vertici siano chiari i benefit a livello di business che questa tipologia può concedere attraverso l’incremento della competitività sui mercati. . L’adozione del MBSE non è un semplice cambio di strumento, non si tratta di sostituire un software con un altro. È una trasformazione strutturale, che mette mano a ruoli, processi, responsabilità e, soprattutto, al modo di pensare e lavorare di un’intera organizzazione.
Quando questa rivoluzione non è compresa e sostenuta dai vertici, l’iniziativa si spegne prima ancora di decollare. In più di un caso, è stato osservato come la causa principale del fallimento non sia stata la tecnologia, né la complessità del metodo, ma la totale assenza di uno sponsor interno, qualcuno con l'autorità e la visione per guidare il cambiamento e difenderlo nei momenti difficili.
Al contrario, quando il management crede davvero nel valore del MBSE, allora accade qualcosa di diverso: arrivano risorse concrete — tempo, budget per la formazione, investimenti nei tool giusti — e si cominciano a rimuovere quegli ostacoli interni che altrimenti inchioderebbero ogni tentativo di innovazione. La transizione, per quanto complessa, trova spazio per maturare.
Il successo, in questi casi, parte dall’alto, e non è uno slogan: è una realtà confermata da tanti progetti andati a buon fine. Ma perché questo accada, è essenziale comunicare il valore del MBSE in termini che parlino al business: meno acronimi, più impatto su tempi, costi, qualità, margini. Se la narrazione resta tecnica, se le demo parlano solo in “SysMLese”, i decisori si disinnamorano presto, e con loro anche i fondi, la pazienza e il supporto.
Alla fine, quello che conta davvero non è solo lo strumento, ma il contesto che lo accoglie: le persone, i processi, la mentalità e il coraggio di cambiare. È lì che si gioca la partita vera del MBSE. E come in ogni cambiamento profondo, senza leadership convinta, è solo questione di tempo prima che tutto torni com’era prima — o peggio, in un limbo fatto di tool inutilizzati e promesse mancate.
Casi di studio: fallimenti e trasformazioni necessarie
Per comprendere concretamente il fallimento (o il successo) dell’MBSE, è utile esaminare alcuni casi reali o emblematici. Qui presentiamo esempi che evidenziano come un’adozione superficiale porti al fallimento e, per contrasto, come un’adozione corretta richieda profondi cambiamenti organizzativi e di processo.
Tentativo superficiale e fallimento
Un classico esempio di fallimento nell’adozione del MBSE è quello dell’azienda che, sedotta dall’entusiasmo del momento attorno a SysML, decide di fare “il grande salto” acquistando uno strumento di modellazione e mandando il team a un paio di corsi veloci. Tutto sembra partire bene, con l’entusiasmo tipico delle novità. Ma poi? Poi le cose si inceppano.
Il modello inizia a prendere forma, ma intanto le scadenze incombono, i documenti “ufficiali” continuano a essere richiesti in Word o Excel, e nessuno ha davvero ripensato a come integrare tutto questo nel flusso reale di lavoro. Così, a poco a poco, gli ingegneri tornano ai metodi di sempre. Non per pigrizia, ma per sopravvivenza: il modello rallenta, il cliente vuole i soliti file, e il tempo è sempre meno. Parlando con Chief Engineers, quasi sempre emerge questo dubbio o paura: “In che modo l’MBSE accelererà i nostri processi?”. Non si riesce a percepire il beneficio a lungo termine nell’uso di un modello rispetto gli strumenti tradizionali, più semplici e più diffusi, ma molto meno performanti sulle grandi distanze.
Nel frattempo, il management osserva da lontano, senza metterci la faccia, senza mettere a disposizione tempo, persone o una visione chiara. Il risultato? Il modello viene aggiornato solo per salvare le apparenze, quando serve fare “bella figura” o chiudere un audit. Di fatto, diventa un esercizio di stile, non uno strumento utile.
È una storia già vista. E lo confermano anche diversi studi: l’MBSE, quando viene trattato come un semplice cambio di tool e non come un cambiamento profondo del modo di lavorare, è destinato a fallire. Le iniziative che non prevedono sponsor forti, tempo per formare davvero le persone, e soprattutto una revisione dei processi esistenti, finiscono per spegnersi piano piano.
La morale è semplice e brutale: se affronti l’MBSE come se stessi installando un nuovo software, senza toccare nient’altro, stai solo buttando tempo e soldi. Non è la tecnologia a fare la differenza, ma il contesto in cui la cali: le persone, i processi, il supporto, la volontà di cambiare davvero. Senza questi ingredienti, ogni modello — per quanto elegante — è destinato a finire in un cassetto.
Caso NASA JSC – successi ottenuti con trasformazione organizzativa
All’estremo opposto dei casi fallimentari, c’è un’esperienza che vale la pena raccontare: quella del NASA Johnson Space Center (JSC). Già dal 2009, il centro ha deciso di scommettere seriamente sull’MBSE, adottandolo in progetti di frontiera. Ma non è stata una passeggiata. Le difficoltà iniziali c’erano tutte: resistenze culturali, preoccupazione per i rischi, lo scetticismo diffuso nei confronti di un approccio percepito come troppo teorico o complicato.
La differenza? JSC non si è limitata a installare un tool e fare due corsi. Ha intrapreso un lavoro profondo, strutturato e multilivello. Ha formato le figure chiave, costruito un’infrastruttura interna di supporto — un vero e proprio gruppo di riferimento MBSE — e definito regole del gioco chiare per tutti, con linee guida comuni, strumenti integrati e modelli riutilizzabili.
Non si è trattato di un “progetto IT”, ma di una trasformazione culturale. Sono stati individuati dei “campioni” interni — ingegneri con visione e leadership — per guidare il cambiamento dal basso e farlo accadere nei team, giorno per giorno. È nata persino una community interna, il SysML User’s Group, per condividere esperienze, risolvere problemi e contaminare l’organizzazione con un nuovo modo di pensare.
Ma soprattutto, si è puntato a dimostrare il valore del MBSE nella pratica. Non a parole, ma nei task quotidiani: generazione automatica di report, tracciabilità dei requisiti, visibilità trasversale su funzioni, software e hardware. In sostanza, gli ingegneri hanno iniziato a vedere come il modello potesse semplificare davvero il loro lavoro — non complicarlo.
È stato un processo lungo, e tutt’altro che indolore. Per arrivare lì, il JSC ha dovuto rivedere i suoi processi di sviluppo, spostandosi da una logica documentale statica a un modello vivo e dinamico, capace di evolvere insieme al progetto. Ma i risultati sono arrivati, eccome.
Un esempio concreto? Il progetto Deep Space Habitat (DSH) — il modulo abitativo per le future missioni nello spazio profondo. Lì, il modello SysML ha permesso di rappresentare in modo integrato requisiti, funzioni e componenti, dando a tutti — dai progettisti agli stakeholder — una visione unica, coerente e aggiornata del sistema in costruzione.
Quel modello non era un “file in più”. Era la fonte ufficiale di verità del progetto. Grazie a questa centralità, il team ha ottenuto maggiore controllo sui cambiamenti, miglior tracciabilità e una gestione molto più efficiente delle complessità interdisciplinari. Infatti, quando il modello è davvero al centro, cross-piattaforma, tracciato e accessibile, tutta l'informazione e la conoscenza risiedono li. Gli strumenti software non sono più semplici editor, ma diventano ambienti di fruizione, navigazione e collaborazione. La conoscenza non è più dispersa, le review si fanno attraverso il modello e le decisioni hanno un contesto chiaro. I benefici sono evidenti: gestione della complessità, migliore comprensione, comunicazione efficace.
La lezione è chiara: l’MBSE può davvero mantenere le sue promesse — ma solo se viene trattato per quello che è: una trasformazione organizzativa, non un plug-in da aggiungere alla vecchia routine. Anche alla NASA, se non ci fossero stati investimenti reali in competenze, pratiche e cultura, il modello sarebbe rimasto un esercizio accademico. Invece, è diventato uno strumento vivo e utile. Come dovrebbe essere.
Settore automotive – il cambio culturale come chiave di successo
Un altro caso interessante arriva dal mondo automotive, dove un’azienda aveva deciso di puntare sull’MBSE. Ma l’inizio, diciamolo, non è stato dei più brillanti. Il modello SysML veniva percepito dai team di progettazione come una creatura strana, distante, quasi un esperimento accademico calato dall’alto, del tutto scollegato dalla realtà quotidiana fatta di CAD, simulazioni, iterazioni continue e pressioni di produzione.
Il risultato? I systems engineers modellavano da una parte, gli specialisti di dettaglio continuavano per la loro strada. Due mondi che non si parlavano, e il modello, per quanto elaborato, restava lì — utile forse per fare una presentazione, ma inutile per risolvere i problemi veri.
I responsabili, però, hanno avuto il merito di non ignorare i segnali. Invece di insistere a colpi di linee guida e normative, hanno scelto una via diversa: coinvolgere le persone, davvero. Hanno organizzato workshop misti, messi fianco a fianco systems engineers e progettisti meccanici, elettrici, software. Obiettivo? Capirsi. Far sì che il modello non fosse solo corretto formalmente, ma utile praticamente.
Durante questi incontri, succedeva una cosa interessante: chi modellava imparava a “parlare semplice”, adattando le viste del modello alle domande reali dei colleghi. E gli altri, quelli che all’inizio storcevano il naso, iniziavano a esplorare il modello con curiosità, a far domande, a suggerire miglioramenti. Piano piano, quel gap culturale si è ristretto. Il modello ha iniziato a rispondere a domande concrete, a semplificare decisioni, a far risparmiare tempo su rilavorazioni inutili. 5000 requisiti diventavano 500; bisogno del cliente venivano rappresentati in modo chiaro ed efficace, datasheet immensi diventano diagrammi in un'architettura logico e funzionale chiara, organizzata, fruibile. L'informazione ben strutturata diventava conoscenza che si muoveva da un livello ad un altro con estrema semplicità e chiarezza.
In pochi cicli di sviluppo, quello che era considerato un peso è diventato uno strumento di coordinamento reale. I team parlavano la stessa lingua. I problemi si prevenivano, anziché rincorrerli. E il modello, da corpo estraneo, è diventato parte integrante del modo di lavorare.
Certo, non è successo per magia. Ci sono voluti nuovi spazi di dialogo, formazione reciproca, e soprattutto la disponibilità a rivedere i processi, adattandoli per far sì che l’MBSE non fosse una comparsa, ma il protagonistaun accessorio, ma un alleato. E come spesso accade, il cambiamento vero è iniziato quando si è smesso di pensare in termini di tool e si è cominciato a lavorare sulle persone. I migliori strumenti (metodologici e software) nelle mani di persone impreparate e non adeguatamente formate e coinvolte, portano ad una costosa frustrazione diffusa. D'altro canto, se persone capaci e competenti riescono a realizzare meraviglie con un foglio, una matita, un'idea e un po’ò di tempo, cosa potrebbero compiere se dotati degli strumenti giusti?
Cosa ci insegnano, davvero, questi casi? Che quando l’MBSE funziona, non è mai per caso. Tutti gli esempi di successo hanno un minimo comune denominatore: dietro c’è una trasformazione profonda, non un semplice upgrade tecnologico. Si parla di nuove infrastrutture digitali, integrazioni tra strumenti che prima non si parlavano, formazione strutturata, cambiamento dei processi e — soprattutto — una leadership che crede nel cambiamento e lo guida, giorno dopo giorno.
Al contrario, ogni volta che l’MBSE è stato introdotto in modo superficiale — comprando un tool, disegnando qualche diagramma, magari inserendo qualche termine “alla moda” nei documenti — i risultati sono stati deludenti, quando non disastrosi. Perché l’MBSE non è una vernice da dare su un’organizzazione esistente.
È un lavoro di ristrutturazione.
E richiede tempo, coordinamento e una visione chiara.
Come dicono molti esperti, non basta pensare all’aspetto tecnico. Serve un approccio che abbracci l’insieme: persone, processi, cultura e strumenti. È questo l’unico modo per rendere il modello centrale nel modo in cui si progettano, costruiscono e gestiscono sistemi complessi.
L’MBSE non è una soluzione plug-and-play. Non lo è mai statao. È un cambio di paradigma, con tutto ciò che questo comporta. E se lo si prende alla leggera, non solo rischia di non dare risultati, ma può anche peggiorare le cose, generando confusione, spreco di risorse e disillusione diffusa.
Insomma: o si fa sul serio, o è meglio lasciar perdere.
Tirando le somme
Il fallimento dell’MBSE, quando accade, non è colpa dell’approccio. Non è una debolezza strutturale o un’idea sbagliata alla base. Quasi sempre, il problema sta in come l’MBSE viene adottato. È facile innamorarsi del concetto, pensare che basti introdurre un tool di modellazione, aggiungere qualche diagramma e voilà — sistema trasformato. Ma purtroppo non funziona così.
L’MBSE non è una bacchetta magica che si aggiunge sopra i processi esistenti senza toccarli. È più simile a un intervento chirurgico profondo: richiede preparazione, competenze specifiche e, soprattutto, una volontà vera di cambiare. E questo vale non solo a livello tecnico, ma culturale, organizzativo, umano.
Certo, i limiti ci sono — SysML può essere ostico, gli strumenti non sempre brillano per usabilità, l’astrazione a volte fa perdere il contatto con il mondo reale. Ma tutto questo si può gestire, se si ha il coraggio di affrontare l’adozione per ciò che realmente è: una rivoluzione sistemica. Esempi concreti sono dati dai tool di PLM la cui introduzione ha portati a forti scontri, eppure oggi sono enormemente diffusi e ormai irrinunciabili asset dei workflow aziendali.
Ecco il nodo: nessuna azienda dovrebbe affrontare da sola questo percorso. È troppo facile — e troppo umano — rimanere affezionati ai propri processi, alle proprie certezze, ai “così abbiamo sempre fatto”. Il rischio, altissimo, è quello di piegare il nuovo sul vecchio: adattare l’MBSE a processi obsoleti, anziché cogliere l’occasione per rinnovarli. Così facendo, si finisce per sterilizzare tutto il potenziale trasformativo del metodo.
Per questo serve affiancarsi a consulenti esperti, che non solo conoscano a fondo gli strumenti, ma che vivano e respirino gli standard come SysML, i framework metodologici come Arcadia, Harmony, MagicGrid, UAF, e sappiano come accompagnare un’organizzazione in una trasformazione profonda. Non stiamo parlando di una formazione tecnica, ma di una vera e propria opera di change management strutturato.
È proprio questo il cuore della missione di ONE-SYS: supportare le aziende in questa transizione, aiutandole a disegnare e costruire il proprio sistema MBSE in modo solido, sostenibile, e davvero integrato nel modo di lavorare quotidiano. Lo facciamo ogni giorno, fianco a fianco con i nostri clienti, traducendo ambizioni in realtà e modelli in valore operativo.
Perché l’MBSE, se adottato seriamente, non è solo un’evoluzione dell’ingegneria dei sistemi: è un salto che può ripensare il modo in cui un’intera impresa concepisce, costruisce e gestisce i propri prodotti. Un salto che richiede leadership forte, investimenti in formazione, la disponibilità a mettere in discussione i ruoli, le responsabilità e i processi dati per scontati.
E non esistono scorciatoie. Non si può “provare un po’ di MBSE” come se fosse una moda passeggera. O si abbraccia fino in fondo, come leva strategica di trasformazione, oppure si finisce per alimentare la frustrazione — e la solita narrativa delle “promesse mancate”.
In conclusione, il punto non è se l’MBSE funziona. Il punto è: siete pronti ad affrontarlo per ciò che è davvero? Perché, se la risposta è sì, i risultati arrivano. E sono trasformativi. Una maggiore coerenza tra requisiti e progettazione, meno rilavorazioni, tracciabilità reale, e un’organizzazione più consapevole, più allineata, più pronta ad affrontare la complessità dei sistemi di oggi — e soprattutto di domani.
Il primo passo è semplice, ma non facile: smettere di cercare scorciatoie e iniziare a costruire con metodo, con visione, con competenza. E sapere che non si è soli: ONE-SYS è qui per questo.
Fonti utilizzate nell'articolo
Cloutier, R., & Bone, M. (2015). "MBSE Adoption Challenges and Recommendations." INCOSE International Symposium.
Friedenthal, S., Burkhart, R., & Sampson, M. (2009). "INCOSE MBSE Initiative – The Roadmap to Deployment." INCOSE IW.
Link: https://www.researchgate.net/publication/267687693_INCOSE_Model_Based_Systems_Engineering_MBSE_Initiative https://www.omg.org/sysml/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf
Estefan, J. A. (2008). " Survey of Candidate Model-Based Engineering (MBSE) Methodologies." INCOSE Technical Report.
Paredis, C. J., et al. (2010). "An Overview of the SysML Modeling Language." Proc. of INCOSE International Workshop.
DOI: 10.1002/sys.20179
Sandia National Laboratories (2016). "Model-Based Systems Engineering Adoption Assessment." Internal Review.
Mohammad Chami, Jean-Michel Bruel. A Survey on MBSE Adoption Challenges. INCOSE EMEA
NASA: MBSE implementation reports and pilot projects (incl. Deep Space Habitat case).
INCOSE MBSE Working Group (2023). "MBSE Maturity Survey Report."
Accenture (2024). "Future of MBSE."