Nel mio lavoro quotidiano ho spesso a che fare con prodotti complessi e ricchi di varianti. Nel contesto del PLM e della gestione delle varianti si pone allora la domanda: come descrivo un prodotto che può avere forse miliardi di varianti possibili, nel modo più semplice ed efficiente?
Sarebbe del tutto inefficiente provare a elencare e declinare le singole varianti una per una. Se un prodotto può avere miliardi di varianti possibili, ci vorrebbe moltissimo tempo.
Ci servono quindi dei modi per descrivere gli spazi delle varianti. Ed è qui che comincia già il problema:
- Che cos’è esattamente uno spazio delle varianti?
- Come si può rendere uno spazio delle varianti afferrabile?
Quando parlo di uno spazio delle varianti, intendo (di norma) un determinato insieme di varianti di prodotto (ovvero varianti del mio «system of interest»).
Prendiamo le auto, per esempio: si possono acquistare in diverse varianti: bianca, verde, blu, con o senza tettuccio apribile, station wagon, berlina a tre volumi o cabrio.
…e ora immaginiamo un parcheggio pieno di auto di questo tipo 🅿🚗🚘
Nel linguaggio burocratico si parla talvolta di «spazio» di parcheggio, e l’analogia con lo «spazio» delle varianti è quindi evidente 😉 In questo parcheggio le varianti simili stanno vicine tra loro, quelle diverse più lontane. Quindi le rosse una accanto all’altra, le verdi una accanto all’altra e le blu altrettanto.
Nella fila di parcheggio successiva si continua allo stesso modo, con le auto rosse, verdi e blu di nuovo una accanto all’altra. Ma nella prima fila ci sono solo le station wagon, nella seconda le berline a tre volumi, e nella terza le cabrio.
Nel nostro spazio di parcheggio abbiamo già rappresentato due «dimensioni»: colore e tipo di carrozzeria. Ogni caratteristica (per esempio il colore) che può variare da veicolo a veicolo (rosso, verde, blu) è una dimensione propria dello spazio delle varianti.
La prossima caratteristica potrebbe essere il tettuccio apribile. E l’auto ha un tettuccio apribile oppure non lo ha (= due valori: presente o non presente). Per fortuna possiamo ancora ampliare il nostro spazio di parcheggio verso l’alto, costruendo senza problemi un livello di parcheggio su due piani: un piano per ogni valore della caratteristica. Le auto senza tettuccio apribile vanno sopra, quelle con tettuccio apribile vanno sotto.
Se ora parlo di station wagon rosse con tettuccio apribile, posso delimitare con precisione, in questo spazio (delle varianti) tridimensionale, la regione in cui si trovano tutti i veicoli che corrispondono a queste caratteristiche.
E in ogni posto di questo parcheggio multipiano può effettivamente esserci un’auto? No, non proprio.
Le cabrio con tettuccio apribile, in fondo, non hanno molto senso, no? La fila di parcheggio in cui al piano superiore ci sono le cabrio resta quindi semplicemente vuota al piano inferiore. In pratica si parla allora di condizioni di costruibilità, di conoscenza delle relazioni (in SAP) o semplicemente di vincoli (constraint). Queste «regole» descrivono quali varianti di prodotto sono possibili o non possibili. Queste regole non devono necessariamente avere motivazioni tecniche, ma possono anche essere stabilite per ragioni commerciali o di altra natura. Per ottimizzare la produzione, per esempio, si potrebbe decidere che le station wagon bianche esistano solo con tettuccio apribile.
A proposito, invece di «caratteristiche» si parla a volte anche di «punti di variazione» (variation point). E naturalmente la maggior parte dei prodotti ha più di tre caratteristiche o punti di variazione (oltre a colore, carrozzeria e tettuccio apribile, anche potenza del motore, sedili comfort, navigatore premium o standard, riscaldamento ausiliario, ecc.)
I parcheggi reali (o i parcheggi multipiano) non si possono ovviamente costruire in più di tre dimensioni (almeno nel nostro mondo — finora non ho ancora visto un parcheggio multipiano quadridimensionale) — ma gli spazi delle varianti, per fortuna, sono solo costrutti logici e si possono descrivere in linea di principio in un numero qualsiasi di dimensioni.
Torniamo alla pratica dei progetti. Come affronto il fatto di dover gestire parcheggi multipiano multidimensionali, scusate, spazi delle varianti? Dipende naturalmente dal compito. In definitiva uno spazio delle varianti è un insieme*, e tutto ciò che la matematica della teoria degli insiemi offre si può applicare anche agli spazi delle varianti. Algebra booleana, calcolo con gli insiemi, ecc.
*C’è un matematico che legge queste righe? Non lo sono, e sono grato per correzioni o aggiunte 😊
Ora, le espressioni matematicamente formali e corrette non sono il genere di cose che piacciono a tutti (a me solo a seconda dell’umore). Per fortuna, nei miei progetti è quasi sempre sufficiente rappresentare visivamente il problema e la soluzione. Riducendo gli spazi delle varianti a cerchi bidimensionali (…patate, cetrioli, pomodori di forma irregolare…).
Lo faccio così da tanto tempo — a un certo punto ho scoperto che questa forma di rappresentazione ha anche un nome in matematica: diagrammi di Euler, diagrammi di Venn.
La rappresentazione insiemistica per i veicoli con tettuccio apribile in vetro che hanno anche il riscaldamento ausiliario potrebbe quindi assomigliare a questo:
Venn è riuscito a dimostrare che, in modo simile, in linea di principio un numero qualsiasi di insiemi (= numero qualsiasi di dimensioni dello spazio delle varianti) può essere rappresentato in due dimensioni. In pratica, finora in ogni progetto mi è bastata la rappresentazione di una manciata di insiemi, ma è bene sapere che c’è ancora margine verso l’alto 😉
Sulla base di queste rappresentazioni, nel mio lavoro sui progetti posso illustrare principi di funzionamento, per esempio descrivere algoritmi su come vengono consolidate le varianti, come vengono alimentati i configuratori, quali componenti o quale software sono necessari per quale variante, e molto altro.
E lo faccio in modo molto più efficiente e comprensibile che con una descrizione a parole o con espressioni matematicamente complicate e corrette.
