Gestione delle modifiche: indispensabile, onnipresente — e nella scala di popolarità del reparto engineering si trova subito dopo i tagli al budget e le riunioni del lunedì mattina. Ma seriamente: perché è così? È nella natura di noi ingegneri cambiare e migliorare le cose.
La modifica in sé non è nemmeno il problema.
Il problema dell’impact analysis
Un esempio classico: l’impact analysis, compagna necessaria di ogni modifica. Quali componenti sono coinvolti, quali documenti, quali requisiti? E qual è lo stato attuale — nel PLM, nell’ALM, nell’ERP?
Nella pratica, questa domanda finisce spesso con la necessità di chiedere all’unico collega che lo sa sempre. Quello che proprio ora è in vacanza. E prima di farsi strada in questa giungla, si preferisce magari rinunciare subito alla modifica.
La visione: richiedere una modifica, risposta in pochi secondi
Se potessi desiderare liberamente qualcosa, oggi potrebbe già funzionare così:
Io: “Computer, il componente X deve essere sostituito da Y — non più disponibile. Cosa significa?”
Chatbot: “Il requisito A47 non sarà più soddisfatto completamente, a causa della stabilità ridotta di Y. E la postazione di montaggio dovrà essere adattata — attrezzo diverso.”
Le attività conseguenti potrebbero poi essere avviate in modo analogo.
Cosa serve davvero per arrivarci
Per ora suona ancora come una visione — ma dal punto di vista tecnologico siamo già molto più vicini di quanto si pensi. A condizione che le basi siano solide. Perché nessun modello di IA salva un’impact analysis se la base di dati sottostante non è corretta. Tre cose sono decisive:
- Un Digital Thread che rende visibili le dipendenze tra requisiti, progettazione e software
- Un versionamento pulito — in modo che sia chiaro qual è lo stato valido
- Un’architettura dell’informazione che definisca cosa si trova dove e cosa è collegato
Questi tre punti, del resto, sono atemporali. Non servono solo alla fattibilità dei chatbot basati su IA — sono la base di ogni impact analysis funzionante, con o senza IA.
La gestione delle modifiche non ha un problema di accettazione perché gli ingegneri temono le modifiche — ma perché l’impact analysis dietro di esse vive spesso di passaparola invece che di dati. Digital Thread, versionamento pulito e un’architettura dell’informazione chiara sono la base per poter rispondere alla domanda “cosa comporta questa modifica?” in secondi invece che in giorni — con o senza chatbot davanti.
