Quando si parla di codifica dei disegni CAD nella progettazione meccanica, spesso l’attenzione si concentra su come renderla più descrittiva, più completa o più “intelligente”.
Nella pratica quotidiana del progettista, però, il problema è un altro.
Il punto non è quanto tempo impiego a codificare, ma se mi sto ponendo una domanda sulla codifica mentre progetto.
Se il progettista si sta chiedendo “come devo codificare questo file?”, allora sta già perdendo tempo e la codifica sta introducendo rumore.
Una codifica efficace dovrebbe portare esattamente all’opposto:
non generare domande.
L’obiettivo della codifica dei disegni nella progettazione meccanica
Una codifica dei componenti meccanici ben progettata non serve a spiegare cos’è un pezzo.
Serve a:
- identificare in modo univoco file e modelli CAD
- essere stabile nel tempo
- funzionare sempre allo stesso modo
- non richiedere interpretazioni
In altre parole, la codifica deve essere definita prima di iniziare a progettare.
Se durante il lavoro CAD il progettista si trova a dover scegliere:
- come strutturare il codice
- che informazioni inserire
- che livello di dettaglio usare
allora quella codifica sta sottraendo attenzione al progetto.
Primo principio: la codifica CAD non deve generare domande
Durante la progettazione CAD:
- il progetto è già definito
- la struttura di codifica è già nota
- l’azione deve essere meccanica
Una buona codifica dei disegni è quella che non costringe il progettista a fermarsi.
Non devo chiedermi:
- quanto essere descrittivo
- se inserire dimensioni nel nome
- se specificare la funzione del componente
- che dimensione ha il componente
Se queste domande emergono, la codifica sta sottraendo energia al progetto.
Secondo principio: distinguere il tipo di componente nel codice
Non tutti i componenti svolgono lo stesso ruolo e trattarli allo stesso modo è una delle principali fonti di confusione nei modelli CAD.
Osservando l’albero di un assieme, solo guardando i codici, dovrebbe essere immediatamente chiaro se un componente è:
- un componente commerciale (buy)
- un componente standard o a magazzino (make)
- un componente specifico di progetto
- un componente di test o prototipo
Questa informazione non dovrebbe dipendere dalla descrizione o dall’esperienza di chi legge l’assieme, ma essere parte integrante della codifica.
Buy, make e progetto: non solo componenti diversi, ma flussi diversi
La distinzione tra componenti buy, make e di progetto non è solo concettuale, ma operativa.
Componenti diversi seguono, nella pratica, flussi di revisione e approvazione differenti.
- Un componente di progetto segue il flusso di revisione del progetto o della commessa
- Un componente make segue tipicamente un flusso legato allo sviluppo tecnico e alle modifiche costruttive
- Un componente buy ha esigenze di revisione molto più limitate, spesso legate solo a sostituzioni o aggiornamenti di fornitura
Se questa distinzione non è chiara nella codifica, il rischio è evidente:
in una revisione di commessa tutti i componenti finiscono inutilmente in revisione.
Questo aspetto diventa particolarmente rilevante per chi utilizza un PDM, dove la codifica può influenzare direttamente:
- gli stati del file
- i flussi di approvazione
- le automazioni sui passaggi di revisione
Senza entrare nel dettaglio, è importante capire che una codifica strutturata è il prerequisito per governare questi flussi, non un optional.
Perché i componenti commerciali non vanno lasciati “con il loro nome”
Un errore “a mio parere” molto diffuso è lasciare i componenti commerciali con:
- il nome del produttore
- una descrizione testuale
- il codice del fornitore
Questo approccio è fragile perché:
- i fornitori cambiano
- i nomi non sono univoci
- la descrizione non identifica il componente in modo stabile
Il componente commerciale deve avere un codice interno, indipendente dal fornitore.
Riutilizzo dei file e librerie di componenti
Se utilizzo lo stesso componente commerciale in progetti diversi, non devo duplicarlo, ma fare sempre riferimento allo stesso file.
Questo implica automaticamente che:
i componenti buy e i componenti make debbano vivere in una libreria virtuale, separata dai componenti di progetto.
Proprietà del file e informazioni di acquisto
Le informazioni come:
- produttore
- codice di ordinazione del produttore
non dovrebbero stare nel nome del file, ma nelle proprietà del file CAD.
In questo modo:
- il file mantiene un’identità stabile
- non si è vincolati a un singolo fornitore
- è possibile gestire più canali di acquisto
- si evitano duplicazioni di modelli
Queste proprietà del file sono ciò che comunemente viene definito metadati.
Il tema verrà sviluppato in modo più approfondito in un articolo dedicato.
Terzo principio: una codifica CAD deve essere pulita
Una codifica dei disegni CAD deve essere pulita.
Pulita significa:
- stesso numero di caratteri per tutti i componenti
- struttura fissa
- nessuna eccezione
Quando si osserva l’albero CAD:
- i codici sono allineati
- la lettura è immediata
- il disordine visivo è ridotto al minimo
Anche questo è un modo concreto per ridurre rumore.
Quarto principio: una codifica strutturata è anche funzionale
Una codifica strutturata non serve solo a ordinare i file, ma abilita possibilità future.
Quando una codifica CAD:
- ha campi fissi
- posizioni definite
- significato stabile
diventa leggibile anche da una macchina.
Questo permette:
- automazioni
- script
- regole
- algoritmi
Codifiche basate su descrizioni o dimensioni non permettono questo tipo di evoluzione.
Codifica di progettazione, produzione e commerciale: logiche diverse
Un errore ricorrente è pensare che debba esistere un unico codice valido per tutta l’azienda.
In realtà convivono almeno tre logiche diverse:
- progettazione
- produzione
- commerciale
Ognuna risponde a esigenze differenti.
Quando la progettazione eredita il codice dalla produzione o dal commerciale, la codifica diventa un vincolo.
E un vincolo, genera rumore.
Codifiche diverse, ma collegate
La codifica che utilizzo personalmente non è un modello universale, ma un esempio concreto di applicazione dei principi descritti.
È basata su:
- identificazione del contesto
- numero di progetto progressivo
- distinzione chiara tra:
- assieme generale
- assieme
- parte
- prefissi dedicati per componenti buy, make e testing
- stessa lunghezza per tutti i codici
Il risultato è una codifica:
- stabile
- leggibile
- pulita
- predisposta all’automazione
Un esempio di codifica dei disegni CAD strutturata
La codifica che utilizzo personalmente non è un modello universale, ma un esempio concreto di applicazione dei principi descritti.
È basata su:
- identificazione del contesto
- numero di progetto progressivo
- distinzione chiara tra:
- assieme generale
- assieme
- parte
- prefissi dedicati per componenti buy, make e testing
- stessa lunghezza per tutti i codici
Il risultato è una codifica:
- stabile
- leggibile
- pulita
- predisposta all’automazione
Conclusione
Nella progettazione meccanica, la codifica dei disegni non serve a descrivere.
Serve a non far sorgere domande.
Quando è progettata correttamente:
- elimina micro-decisioni
- riduce il rumore operativo
- mantiene il flusso di lavoro
- crea basi solide per il futuro
La codifica non è un dettaglio organizzativo.
È uno strumento progettuale.
E come tutti gli strumenti, o riduce il rumore…
oppure lo amplifica.