Escursione nel territorio dell’analisi ad oggetti; la revisione del sistema di codifica dei prodotti/servizi in ambito ERP. Il primo passo verso la costruzione del Configuration Lifecycle Management.

Esattamente, cos’è e qual è la funzione di un configuratore?
Con i due precedenti post ho cercato di descrivere due concetti fondamentali:

Primo:  un configuratore non è uno strumento periferico rispetto l’architettura del sistema informativo aziendale. Il configuratore è la base sopra la quale è possibile  edificare il miglioramento dell’efficacia e dell’efficienza dell’intera organizzazione d’impresa.

Secondo: la revisione della metodologia di classificazione dei prodotti e servizi non è un argomento che interessa il solo ufficio progettazione. Se si vuole utilizzare gli strumenti di “automatismo del ragionamento” è necessario rivedere il criterio di classificazione dei prodotti/servizi così da renderlo più “naturale” e assimilabile da un processo di ragionamento automatico.

Ciò premesso il ruolo di un configuratore si concretizza con la messa a disposizione di due principali servizi:
a)  guidare in maniera automatica la compilazione di un’offerta tecnico/commerciale, seguendo gli stessi schemi di ragionamento che sarebbero adottati se la stessa attività fosse svolta da una persona esperta.
b)  Ricevere in input le specifiche raccolte durante la fase di configurazione commerciale così da produrre in maniera automatica quante più informazioni possibili utili per la realizzazione di ciò che si è venduto: parametri per l’automazione della progettazione CAD, distinta base e cicli di lavorazione, istruzioni di lavoro, etc…

Oltre a ciò ci sono altre funzioni che si possono avvantaggiare grazie alla presenza di un configuratore. Però per il momento meglio procedere per capitoli principali un passo alla volta così da assimilare bene i concetti fondamentali.

Chi invece vuol fare un salto avanti può dare uno sguardo a questo esempio.

Come ho avuto già modo di scrivere il grande gap presente in gran parte dei moderni sistemi ERP è la codifica (classificazione) dei prodotti/servizi.

Codice articolo… codice parlante… dimensioni associate ad un item, etc, etc… non sono sufficienti.

E’ necessario realizzare un diverso modello concettuale. Diverso però non vuol dire necessariamente radicalmente nuovo, anzi.
Il modello di riferimento che suggerirò per risolvere il problema della codifica è molto vicino al modo di vedere e classificare gli oggetti utilizzato da  noi esseri umani che per istinto tendiamo a classificare il mondo che ci circonda utilizzando dei metodi di organizzazione basati su precisi criteri di riconoscimento.

Per chi volesse approfondire le basi della teoria della classificazione consiglio la lettura del lavoro di S. Korner  “classification Theory” pubblicato nel 1974. Da molte persone questo testo è considerato il punto di riferimento di ciò che in seguito è divenuto noto con il termine “object oriented”; analisi ad oggetti e programmazione ad oggetti, i cui prodotti concreti sono oramai di uso quotidiano per ognuno di noi dato che oggi, grazie ad essi, funziona ogni moderno software per computer, tablet, telefonino, lavatrice, aspirapolvere, etc…

Se canta come un gallo e ruspa come un gallo, allora è un gallo!

Prima della formulazione della teoria della classificazione un vecchio proverbio bolognese gettava a modo suo le basi del paradigma degli oggetti.

Il mondo che ci circonda può essere suddiviso in “classi di oggetti”, come schematicamente illustrato nella figura qui a lato. Ogni classe è caratterizzata dalla presenza di:

• Attributi identificativi propri, i cui valori sono indipendenti dal contesto, ovvero immediatamente qualificabili a livello di classe.
• Attributi dipendenti dal contesto, ovvero  qualificati dalle classi che formano la discendenza rispetto alla classe padre dalla quale ereditano il patrimonio di attributi.

  -> Se dispone di un cervello, possiede quattro zampe e come verso fa “miao”, allora è un gatto.
Quando tutti gli attributi di una classe terminale (ovvero senza altre discendenze) vengono qualificati si ottiene la generazione di un istanza. Nel mondo degli oggetti un istanza è ciò che in ingegneria gestionale viene definito SKU – Stock Keeping Unit, termine meglio noto nell’uso quotidiano con il nome di: codice articolo.

Immaginate di disporre di un sistema ERP che vi consenta di classificare i vostri prodotti organizzando e relazionando le classi di oggetti come descritto dalla figura precedente. Chi utilizza questo tipo di sistema di classificazione sa di aver messo finalmente in cascina la soluzione del problema delle 3F (Form, Fit, Function  e.g. 3F è il criterio che permette di stabilire quando bisogna creare una nuova SKU… e quando no!)

A parte la generazione automatica e razionale di un codice articolo di tipo SKU quali sarebbero gli altri vantaggi?
Il più importante: disporre di una notazione di riconoscimento degli oggetti utilizzabile per la composizione delle regole e dei vincoli, gli elementi grazie ai quali è possibile costruire il Knowledge Base, ovvero le informazioni necessarie per attivare un processo di ragionamento automatico.

Le regole ed i vincoli che costituiscono il modulo d’intelligenza di un configuratore possono assumere diversa forma e funzione a seconda del contesto.
Ad esempio: se oAnimali.verso esiste bau e oAnimali.verso esiste miao allora -> mai due di questi simpatici “oggetti” nello stesso contesto… se non volete una zuffa 🙂

Oppure, più seriemente: se oRegistriSW.numerobit diverso oRegistriHW.numerobit allora -> ferma tutto e rivedi il progetto!!!
Una business rule del genere in ambito di verifica della configurazione di lancio del vettore Arianne 5 probabilmente avrebbe impedito il fuoco di artificio più costoso della storia… si veda articolo dal PLM al Configuration Life Cycle Management.

In sintesi rivedere in maniera “orientata agli oggetti” il sistema di codifica ERP significa poter disporre degli elementi di riconoscimento indispensabili per la costruzione di un motore di configurazione… ma non solo! Tutto il workflow SCM (Supply Chain Management) ne potrebbe trarre grandi benefici.

Ad esempio, poter riconoscere in “maniera naturale” le istanze di oggetti SKU (= codici articoli) è senz’altro utile anche per uno schedulatore di produzione che grazie al riconoscimento degli attributi di ogni SKU potrà produrre delle sequenze di ordini di lavoro ottimizzate con criteri di similitudine, così da ridurre i tempi di set-up, i tempi di apprendimento degli operatori e un sacco di altre cose.
Senza poi parlare dei benefici che potrebbero derivare per chi lavora in TQM (Total Quality Management)… sai che diagrammi di Pareto si potrebbe tirare fuori potendo “vedere” gli oggetti grazie agli attributi.

La BI  (Business Intelligence) avrebbe una marcia in più. La gestione dei magazzini pure… e il forecast commerciale? 😉

Per realizzare un sistema di codifica basato sui principi sopra esposti è necessario buttare via e ricreare un intero sistema ERP?
No, non è necessario.

Come si può vedere dalla figura sopra lo schema di base delle entità costituenti il data base di riferimento è abbastanza semplice.

La tabella che nello schema si chiama “IstanzeSKU-ERP” è l’entità equivalente rispetto alla tabella Items presente in un qualsiasi sistema ERP.
La tabella IstanzeSKU-ERP il “bridge” che unisce il mondo della classificazione ad oggetti con il mondo ERP che ragiona per codice articolo-descrizione.

Ogni row di “IstanzeSKU-ERP” è identificata da un semplice Id progressivo. Non da un codice parlante.
Al codice Id è associato il set di attributi e valori che identifica univocamente un Id di tipo SKU.

Comprendere e realizzare quanto riportato nel disegno E-R vi permetterà di rendere più naturale ed efficiente l’intero sistema di codifica degli articoli/servizi. Si tratta del primo passo da compiere per lanciare l’implementazione di un configuratore.