Gli errori architetturali dei configuratori CAD
Un configuratore può funzionare correttamente ed essere comunque progettato male
Nell’articolo precedente abbiamo visto che un configuratore non dovrebbe irrigidire il progetto.
Deve poter evolvere insieme al prodotto, alle commesse e al modo in cui l’ufficio tecnico lavora.
Ma questa capacità non dipende soltanto dalla volontà di mantenere il sistema flessibile.
Dipende soprattutto dalla sua architettura.
Un configuratore può superare perfettamente la prima prova.
Le quote cambiano.
I componenti vengono attivati o sospesi.
L’assieme si aggiorna.
Le tavole vengono generate.
La distinta è corretta.
Tutto sembra funzionare.
Poi arriva una modifica apparentemente semplice.
Bisogna cambiare una regola dimensionale.
Aggiungere una variante.
Sostituire un componente.
Produrre un nuovo output.
Ed è in quel momento che emergono le domande vere.
Dove si trova la regola da modificare?
Quali parti del sistema saranno coinvolte?
Come si verifica che il cambiamento non abbia prodotto effetti collaterali?
Chi deve decidere se quella richiesta appartiene al prodotto standard oppure alla singola commessa?
L’architettura di un configuratore non si vede quando il sistema esegue ciò che era già stato previsto.
Si vede quando qualcosa deve cambiare.
Un’architettura non nasce necessariamente completa
Quando si parla di architettura, si rischia di immaginare una struttura perfetta, definita interamente prima di iniziare lo sviluppo.
Nella pratica accade raramente.
Un configuratore nasce da una prima lettura del prodotto e delle sue regole.
Poi viene messo alla prova sulle varianti reali.
Le prime commesse fanno emergere collegamenti che inizialmente non erano visibili.
Alcune regole vengono sviluppate separatamente e solo in seguito si comprende che possono essere accorpate.
Altre sembrano necessarie, ma con l’utilizzo si rivelano ridondanti o troppo specifiche.
A volte bisogna tornare indietro, eliminare una soluzione e ricostruirla in modo più semplice.
È un percorso che ho seguito anch’io nello sviluppo dei configuratori.
Ho introdotto regole che successivamente ho accorpato.
Ho sviluppato logiche che, dopo averle provate sulle commesse, ho preferito rivedere o eliminare.
E continuo a portare progressivamente il sistema verso uno standard più chiaro.
Questo non significa necessariamente che l’impostazione iniziale fosse completamente sbagliata.
Significa che il prodotto e il processo vengono conosciuti più a fondo anche attraverso l’utilizzo del configuratore.
Il vero errore non è tornare indietro.
Il vero errore è continuare ad aggiungere regole senza fermarsi periodicamente a rileggere, semplificare e consolidare la struttura.
Una buona architettura non è quella che non cambia mai.
È quella che può essere modificata senza perdere il controllo del sistema.
L’architettura non coincide con il linguaggio di programmazione
Quando si parla di architettura, è facile pensare subito al software utilizzato, al linguaggio di programmazione o alla struttura del codice.
Sono aspetti importanti, ma non sono il punto centrale.
L’architettura definisce soprattutto:
- dove risiedono le decisioni;
- come vengono trasferite al CAD;
- quali responsabilità appartengono alla geometria;
- come vengono generate informazioni e documentazione;
- quali dipendenze esistono tra le diverse parti del sistema;
- dove termina lo standard e dove inizia la commessa;
- chi governa le modifiche e come le verifica.
Un configuratore è ben progettato quando queste responsabilità sono riconoscibili.
È fragile quando funziona soltanto perché chi lo ha costruito ricorda tutti i collegamenti nascosti.
Errore 1: non avere una fonte chiara per ogni regola
Uno degli errori più frequenti è distribuire la stessa decisione in più punti del sistema.
Una condizione può essere definita in un foglio Excel.
Ripetuta in un’equazione del CAD.
Controllata nuovamente all’interno di una macro.
E infine corretta manualmente nella distinta.
Finché i valori coincidono, il sistema sembra coerente.
Il problema emerge quando la regola cambia.
Immaginiamo, ad esempio, che oltre una determinata larghezza debba essere introdotto un rinforzo.
La soglia potrebbe essere presente:
- nell’interfaccia di configurazione;
- nel codice che attiva il componente;
- in un’equazione che ne modifica le dimensioni;
- nella logica che lo inserisce in distinta.
Se la stessa decisione viene replicata, non esiste più una vera regola.
Esistono più copie che devono rimanere sincronizzate.
E ogni copia rappresenta una possibile incoerenza.
Questo non significa che tutte le regole debbano vivere nello stesso file o nello stesso strumento.
Un sistema può essere composto da livelli differenti.
Ma per ogni decisione deve essere chiaro qual è il punto autorevole.
Il luogo in cui la regola viene definita.
Gli altri livelli devono riceverla e applicarla, non reinterpretarla.
Una regola può essere utilizzata in più punti, ma deve essere definita in un solo punto.
Il vero errore non è distribuire il sistema.
È distribuire la responsabilità della decisione.
Errore 2: legare troppo strettamente logica, geometria e output
In un configuratore tutto è collegato.
Le regole producono una configurazione.
La configurazione modifica il CAD.
Il CAD rende disponibili dati e geometrie.
Questi dati vengono trasformati in distinte, tavole, PDF, DXF e altri output.
Il collegamento è necessario.
Il problema nasce quando ogni livello dipende dalla struttura interna degli altri.
Succede, ad esempio, quando:
- la distinta riconosce un componente solo dalla sua posizione nell’albero CAD;
- una procedura di esportazione funziona soltanto se il file mantiene un nome specifico;
- una regola tecnica dipende direttamente dallo stato di una feature;
- una modifica dell’assieme interrompe la generazione delle tavole;
- un cambio di materiale richiede interventi sia nel modello sia nel codice di esportazione.
In questi casi il sistema non sta semplicemente trasferendo informazioni.
Sta utilizzando dettagli interni di un livello per governarne un altro.
Di conseguenza, una modifica locale non rimane locale.
Si propaga.
Una variazione geometrica può rompere un output.
Una modifica documentale può richiedere un intervento nel modello.
Una nuova regola può obbligare a ristrutturare l’assieme.
Separare logica, geometria e output non significa renderli indipendenti.
Significa definire passaggi chiari tra loro.
La logica stabilisce cosa deve essere generato.
Il CAD rappresenta il prodotto e restituisce dati affidabili.
Il livello di output utilizza quei dati per produrre le informazioni necessarie.
Ogni livello deve conoscere ciò che riceve e ciò che deve restituire.
Non deve dipendere da tutti i dettagli interni degli altri.
Quando questa separazione manca, il configuratore può continuare a funzionare.
Ma ogni modifica diventa più rischiosa di quanto dovrebbe essere.
Errore 3: trasformare il modello master in tutto il sistema
Il modello master è spesso il punto di partenza naturale di un configuratore.
Contiene la struttura del prodotto.
Raccoglie le varianti standard.
Permette di attivare o sospendere componenti.
Guida la generazione delle geometrie.
Utilizzare un master non è un errore.
Anzi, può essere il centro corretto da cui generare una nuova configurazione.
L’errore è chiedergli di diventare contemporaneamente:
- rappresentazione geometrica;
- contenitore di tutte le regole;
- archivio di tutte le varianti realizzate;
- gestore di ogni personalizzazione cliente;
- origine di tutti gli output;
- memoria dell’intera storia delle commesse.
All’inizio concentrare tutto nel master sembra conveniente.
Le relazioni sono vicine e chi sviluppa il sistema riesce a controllarle direttamente.
Ma, con il tempo, entrano nuovi optional, configurazioni, componenti alternativi e casi particolari.
Se ogni modifica effettuata su una commessa ritorna automaticamente nel master, il modello non rappresenta più lo standard del prodotto.
Rappresenta l’accumulo di tutto ciò che è successo nel tempo.
Il master deve invece conservare una funzione precisa:
generare la variante standard più vicina alla richiesta e creare una base tecnica ordinata da cui iniziare la commessa.
Da quel punto il progetto specifico può proseguire senza obbligare il master a contenere ogni possibile sviluppo.
Errore 4: non distinguere il prodotto configurabile dalla commessa
Non tutte le richieste reali devono diventare immediatamente una nuova regola del configuratore.
Il flusso che utilizzo parte dal master.
Il sistema genera la variante coerente con le regole standard.
Da quella variante viene creata la commessa o il progetto specifico.
Le modifiche richieste dal cliente vengono poi sviluppate all’interno della commessa.
Il percorso può essere sintetizzato così:
- il master genera la variante standard più vicina alla richiesta;
- la variante diventa la base della nuova commessa;
- le personalizzazioni vengono sviluppate nel progetto di commessa;
- ciò che ritorna nel tempo viene valutato per entrare nello standard.
Questa separazione protegge entrambi i livelli.
Il master rimane leggibile, controllabile e orientato a ciò che è ripetibile.
La commessa mantiene la libertà necessaria per gestire ciò che non può essere previsto o standardizzato.
Naturalmente, una modifica nata come eccezione può ripresentarsi.
Quando una soluzione speciale ritorna in più progetti, può essere il segnale che il prodotto sta evolvendo.
A quel punto bisogna valutarla nuovamente.
Può diventare un optional.
Una nuova variante.
Una regola stabile da riportare nel master.
Ma questo passaggio deve essere una decisione consapevole, non la conseguenza automatica di ogni richiesta cliente.
La domanda corretta non è soltanto:
Come inseriamo questo caso nel configuratore?
La domanda precedente è:
Questa soluzione appartiene ormai al prodotto standard oppure deve rimanere una modifica di commessa?
Un configuratore non deve chiudere ogni possibile sviluppo.
Deve costruire il miglior punto di partenza possibile.
Errore 5: confondere la manutenibilità con la possibilità che chiunque modifichi il sistema
Un configuratore deve essere leggibile, documentato e modificabile.
Ma questo non significa che debba poter essere modificato da chiunque.
Al suo interno convivono:
- conoscenza tecnica del prodotto;
- regole dimensionali e costruttive;
- compatibilità tra componenti;
- relazioni tra modelli e assiemi;
- procedure di generazione;
- collegamenti con distinte, documenti e dati produttivi.
Per intervenire su questa struttura non basta conoscere il comando utilizzato o saper aprire il codice.
Bisogna comprendere il prodotto, il processo e l’architettura con cui il sistema è stato costruito.
Pretendere che una persona al primo giorno di lavoro possa modificarlo correttamente sarebbe come chiederle di guidare una Formula 1.
Una Formula 1 è progettata per raggiungere prestazioni elevate.
Ma per portarla al limite serve un pilota che la conosca.
Il configuratore è una macchina specialistica dello stesso tipo.
Deve essere costruito bene, ma ha bisogno di una persona competente che sappia governarlo.
La qualità dell’architettura non si misura dal fatto che chiunque possa metterci mano.
Si misura dalla possibilità che una figura preparata possa comprenderlo, modificarlo e verificarlo senza dover ricostruire ogni volta tutto il sistema.
Il configuratore deve avere un responsabile
Un sistema di configurazione deve avere una figura che ne governi l’evoluzione.
Può essere una persona interna.
Può essere il consulente esterno che lo ha progettato.
Può essere un gruppo ristretto con responsabilità differenti.
Ciò che conta è che sia chiaro:
- chi raccoglie le esigenze dell’ufficio tecnico;
- chi valuta se una richiesta deve entrare nel master;
- chi modifica le regole;
- chi verifica gli effetti sulle configurazioni esistenti;
- chi valida i nuovi output;
- chi mantiene la coerenza complessiva dell’architettura.
Nel mio caso, il configuratore viene gestito come una collaborazione tra il team interno e chi lo ha progettato.
Ho impostato il sistema e formato le persone che lo utilizzano.
Il team lavora sulle commesse, fa emergere necessità, limiti e nuove opportunità e mi trasferisce gli input raccolti nel lavoro reale.
Il mio compito è leggere queste esigenze, valutarne l’impatto e decidere come integrarle senza compromettere la coerenza del configuratore.
Questo modello permette all’azienda di utilizzare e conoscere operativamente il sistema senza dover trasformare ogni utilizzatore in uno sviluppatore.
Allo stesso tempo evita che modifiche non coordinate vengano introdotte direttamente nel master.
Formare il team non significa trasformare tutti in sviluppatori
Il team che utilizza il configuratore deve essere formato.
Deve sapere:
- come generare correttamente una variante;
- quali informazioni inserire;
- quali limiti rispettare;
- come riconoscere un’anomalia;
- quando una modifica appartiene alla commessa;
- quando una necessità deve essere riportata a chi governa il master.
Non è necessario, però, che ogni utilizzatore conosca l’intera architettura interna o sia in grado di modificarne le regole.
Utilizzare il configuratore e sviluppare il configuratore sono due competenze differenti.
Confonderle può produrre due rischi opposti.
Da una parte, concentrare tutta la conoscenza in una persona senza documentazione e senza confronto con il team.
Dall’altra, permettere a troppe persone di intervenire sul sistema, facendo perdere coerenza alle regole.
La soluzione non è rendere tutto modificabile da tutti.
È costruire una governance chiara.
Manutenzione significa anche consolidare e verificare
Governare il configuratore non significa soltanto rispondere alle nuove richieste.
Significa anche fermarsi periodicamente a rileggere ciò che è stato costruito.
Alcune regole possono essere accorpate.
Alcune eccezioni possono essere eliminate.
Alcune soluzioni nate in commessa possono essere promosse a standard.
Altre devono rimanere fuori dal master.
Questa attività di consolidamento è fondamentale perché impedisce al sistema di crescere soltanto per aggiunte successive.
Ogni modifica deve inoltre essere verificata.
Controllare che il modello si rigeneri non è sufficiente.
Una variazione può non produrre errori CAD e generare comunque una distinta incompleta, un componente errato o un output incoerente.
Per questo è utile mantenere alcuni casi di riferimento:
- una configurazione minima;
- una configurazione massima;
- le varianti più frequenti;
- i casi vicini ai limiti dimensionali;
- configurazioni che in passato hanno generato criticità.
Quando il sistema cambia, questi casi permettono di verificare non soltanto che continui a funzionare, ma che continui a produrre risultati corretti.
La manutenzione non è un’attività successiva all’architettura.
È una parte dell’architettura.
Cinque domande per valutare l’architettura di un configuratore
Prima di considerare solido un sistema, può essere utile porsi cinque domande.
- Per ogni decisione, è chiaro dove risiede la regola?
- Logica, geometria e output hanno responsabilità riconoscibili?
- È chiaro cosa deve rimanere nel master e cosa deve essere sviluppato nella commessa?
- Il sistema viene periodicamente semplificato e consolidato, oppure cresce soltanto per aggiunte?
- È definito chi può modificarlo, come raccoglie gli input del team e come verifica gli effetti delle modifiche?
Se le risposte non sono chiare, il configuratore può anche funzionare oggi.
Ma probabilmente sta già accumulando fragilità.
La qualità si vede nel cambiamento
L’architettura di un configuratore non si misura dal numero di operazioni che automatizza.
E nemmeno dalla semplicità con cui chiunque può modificarlo.
Si misura nella chiarezza con cui rende leggibili le decisioni che governano il prodotto.
Nella possibilità di modificare una regola senza cercarla in più punti.
Nella capacità di distinguere lo standard dalla personalizzazione di commessa.
Nel modo in cui permette di tornare indietro, accorpare e semplificare ciò che è stato sviluppato.
Nella presenza di una figura competente che ne governa l’evoluzione insieme al team che lo utilizza.
Un configuratore ben progettato non elimina il cambiamento.
Lo rende controllabile.
Non deve prevedere in anticipo ogni variante futura.
Deve permettere di introdurla senza perdere la comprensione di ciò che esiste già.
Come una Formula 1, può essere una macchina complessa e ad alte prestazioni.
Non deve essere guidabile da chiunque.
Deve essere comprensibile, verificabile e sviluppabile da chi ha le competenze per portarla al limite.
Ed è proprio questa combinazione tra architettura, esperienza e governo del sistema che trasforma un automatismo in una vera infrastruttura tecnica.