Si dice che impostare e manutenere un sistema di configurazione vuol dire combattere con la complessità causata dal dover alimentare la struttura di regole che permettono di generalizzare un prodotto/servizio.

Sicuramente il “combattimento” risulterà molto più agevole se si riesce a diminuire il numero e la complessità delle regole e dei vincoli necessari per generalizzare un prodotto.

Si dice poi che per ogni tipologia di azienda deve essere adottato uno specifico configuratore.

Se sei un’ azienda assemble-to-order (ATO) hai bisogno di un tipo di configuratore.

Se sei un’ azienda Engineered-to-Order (ETO) hai bisogno di un altro tipo di configuratore e così via…

Non è così. Il motore del sistema di configurazione può essere unico, a patto di risolvere il problema della classificazione dei prodotti/servizi seguendo i naturali “usi e costumi umani”.

e.g. In merito a ciò, qualche riga più sotto ho preparato un piccolo esempio che spero possa aiutare.

La modalità tramite la quale vengono realizzate le interfacce utente di un configuratore merita un inciso di riflessione.

Più l’interfaccia utente riesce ad essere “adattiva” (in grado di adeguarsi alla capacità cognitiva dell’utente), più questa riuscirà ad aiutare efficacemente il cliente nella configurazione del prodotto/servizio desiderato.

Sul piano tecnico sono oggi numerose le piattaforme di sviluppo che consentono di generare a “run-time” le forms d’interfaccia più idonee per ogni situazione.

Tornando al tema centrale di questo post; come combattere la “complessità” di un sistema di configurazione, migliorando la propria capacità di costruire astrazioni di prodotti/servizi… un buon punto di inizio potrebbe essere quello di passare per un negozio di giocattoli e comprare una confezione di Lego.

Perché i mattoncini hanno avuto successo?

I mattoncini hanno ancor oggi successo perché sono semplici. I Lego dispongono di un sistema di normalizzazione che permette ad ogni mattoncino di interagire con un altro ed è facile capire se esiste una compatibilità o incompatibilità d’incastro.

Con le cose semplici si possono costruire cose complesse. Da leggere come: se uno capisce “dove stanno i mattoncini” facile che poi riesca a realizzare quanto desidera.

Se invece non si riesce a scomporre la complessità identificando i mattoni elementari… la strada è in salita.

Per comprendere il vantaggio offerto dal sistema di codifica degli items SKU basato sulla teoria degli oggetti, ecco un esempio che pone a confronto due metodi che possono essere utilizzati per generalizzare una semplice distinta base di un prodotto.

Situazione: si deve realizzare un prodotto composto da due assi di legno di stessa essenza e diverso spessore da unire con un chiodo.

Problema: definire una struttura dati idonea a generalizzare tutte le possibili varianti del prodotto considerato, così da ottenere una lista pezzi finale (distinta base) costituita da tre legami:

• codice SKU prima asse di legno
• codice SKU seconda asse di legno
• codice SKU del chiodo.

Soluzione: la generalizzazione sarà svolta con i seguenti metodi:

–metodo A (classico), ovvero la normale tecnica utilizzata dai configuratori “a regole” presenti nei sistemi “ERP majors” che codificano gli items SKU con il metodo del “codice item parlante”. e.g. il codice item viene costruito concatenando più sottostringhe,  ognuna della quali identifica una caratteristica dell item da classificare.

–metodo B, tecnica della classificazione degli oggetti.

Parametri input necessari per la configurazione del prodotto:

A) Costruzione della generalizzazione con il metodo A (regole e codici parlanti)

A.1) Regole per la selezione del chiodo

………………………e via a continuare, se ci sono 100 possibili chiodi diversi, andranno inserire 100 regole

B) Costruzione della generalizzazione con il metodo B 

–Classificazione ad oggetti–

B.1) Prerequisito: classificare gli items come illustrato nel diagramma E-R (classificazione ad oggettti)

B.2) Creare due classi di oggetti caratterizzate dai propri attributi identificativi.

B.3) Valorizzare gli attributi appartenenti alle due classi di oggetti.

Con questi dati forniti in input un algoritmo “solutore” è in grado di verificare l’esistenza, oppure istanziare (create), tutti gli items SKU necessari per la costruzione della distinta base BOM.

Anche senza entrare nei dettagli dei tipi di notazione utilizzati nell’esempio, risulta evidente che fra il sistema A e quello B esiste un’enorme differenza quantitatiiva riguardo ai dati da inserire e manutenere e stiamo parlando di una distinta base finale di soli tre items.

Anche chi non ha avuto modo di conoscere la teoria degli oggetti credo troverà intuitivo riferirsi ad un item SKU come ad un membro di un insieme detto Classe.

Ogni Classe è caratterizzata da un set attributi che una volta valorizzati permettono l’identificazione di un item appartenente al suo insieme di riferimento.

Ad esempio, la riga 3 della tabellina, quella che identifica il chiodo, dice: trovami il chiodo che va bene per fissare queste due assi di legno.

Questa è la frase che normalmente un mastro falegname rivolge al suo apprendista per chiedergli di andare a prendere i chiodi necessari per inchiodare due assi di legno.

Poi sono arrivati i computers e le assi di legno le abbiamo iniziate a chiamare: 221LEGN67P1NOCL1200S45P300. I chiodi: 224CHI23FE14L060 … e così ci siamo “snaturati”.

Qualcuno riesce ad immaginare la scena dove il mastro falegname dice al suo apprendista: devo inchiodare 221LEGN67P1NOCL1200S45P300 con 221LEGN67P1NOCL1200S35P300 vai un a vedere se ci sono i chiodi 224CHI23FE14L020, 224CHI23FE14L030…. etc, etc, e una volta finito l’elenco dei SKU necessari, dire all’apprendista… e per favore portami anche un bicchiere d’acqua che a forza di pronunciare tutti questi codici parlanti mi si è seccata la lingua.

E’ l’apprendista dire al suo maestro; scusi master, mi può dire il codice del bicchiere d’acqua... cercando poi di scappare più veloce del martello lanciato dal suo master al solo fine di incoraggiare l’apprendista ad andargli a prendere il bicchiere d’acqua richiesto.

In sostanza solo razionalizzando il metodo di codifica degli articoli SKU è possibile costruire una “grammatica” delle regole di configurazione espresse nella forma più naturale possibile. Annullando così i “si dice” che hanno caratterizzato le prime righe di questo post.