Punto1:

Un prodotto, ed i dati che lo definiscono, sono il risultato finale di un combinato di azioni causa->effetto alimentato dalla conoscenza degli esperti che normalmente sono gli “sponsors” di ogni processo creativo. La raccolta, organizzazione e analisi dei dati, se svolta correttamente, da’ luogo a ciò che si chiama informazione. L’informazione è a tutti gli effetti una forma di messaggio e come tale si presta ad essere trasmesso e condiviso. Chi è bravo a generare  nuovi prodotti senza generare nuove informazioni sta inaridendo la sorgente del pozzo.

Punto2:

La valutazione e studio delle informazioni favorisce la formazione di nuova esperienza la quale poi si può “sedimentare” generando nuovi strati di conoscenza.

Se per elaborare i dati in modo da farli divenire informazioni un computer può aiutare.

Per passare dall’esperienza alla stratificazione di un nuovo stato di conoscenza è tutt’ora necessaria un’unità di elaborazione biologica dotata di un clock di poche centinaia di cicli al secondo, alimentata da impulsi elettrochimici, meglio nota con il nome di cervello umano.

Il cervello come unità di elaborazione ha mille pregi, ma anche qualche difettuccio. Ne cito uno… che poi è anche il suo principale pregio. Ogni cervello è unico, individuale, per questa ragione risulta essere unica ed individuale la capacità intuitiva di ogni essere umano grazie alla quale le esperienze acquisite si trasformano in nuova conoscenza.

La capacità di interpretare ed elaborare le esperienze è ciò che chiamiamo “intelligenza”. Come questa capacità venga stimolata ed accresciuta è oggetto di numerosi dibattiti.

Sicuramente gli stimoli e l’allenamento aiutano il “muscolo” cervello… su questo tema però non vado oltre, dato che aprire questo capitolo sarebbe troppo lungo e porterebbe fuori strada il ragionamento complessivo deviando l’attenzione dal punto focale, ovvero il prodotto dell’intelligenza, la conoscenza.

La conoscenza, una volta acquisita, si presta ad essere classificata e condivisa, a patto di avere ben chiaro il perimetro, il contesto, dove si intende realizzare la classificazione.

Ciò premesso il ruolo dei sistemi PLM (Product LifeCycle Management) è quello di cercare di dare supporto al ciclo di generazione virtuosa: prodotto/dati -> informazioni -> conoscenza -> esperienza 

Ogni prodotto ha sempre un precedente ed un seguente.

Ogni esperto ha avuto almeno un “maestro” nella vita… e questo è un debito che ognuno di noi deve cercare di pagare facendo in modo di organizzare il proprio lavoro affinchè “il prodotto” non sia l’unico risultato del  processo creativo.

Fortunatamente negli ultimi anni è aumentato il numero delle aziende che hanno maturato una sufficiente consapevolezza riguardo al tema della gestione estesa del ciclo di vita di ogni prodotto realizzato… e soprattutto del prossimo che lo seguirà.

L’ormai diffusissimo impiego di metodologie di lavoro ispirate al TQM (Total Quality Management) è stata sicuramente una delle principali ragioni che ha fatto maturare la visione organizzativa basata sul miglioramento continuo.

Tuttavia, nonostante i progressi, ancora si tende a fare un poco di confusione rispetto la corretta identificazione di cosa sia: un dato, un’informazione, un’esperienza e alla fine una conoscenza da condividere.

Per comprendere meglio il problema bisogna fare un passo indietro nella storia dei sistemi PLM. Prima che nascesse il concetto di PLM presso le aziende esistevano già delle metodologie similari, delle “best practices” formali ed informali.

Ad esempio, in “attesa” che venissero scritti i software della famiglia PLM i vecchi progettisti si erano già organizzati introducendo il concetto di “normalizzazione” tecnica.

Un esempio di normalizzazione potrebbe essere una tabella che riporta tutti i tipi di viteria utilizzabili per svolgere una certa funzione meccanica. Una tabella del genere la si può definire come una “informazione”.

Però da sola la normalizzazione non è sufficiente in quanto questa informazione non contiene alcun elemento associabile al concetto di conoscenza.

Mi spiego. Ricordo che la prima automobile che ho avuto modo di guidare aveva un piccolo difetto. Con le vibrazioni del motore i bulloni che bloccavano il collettore di scarico si allentavano, fino a svitarsi completamente.

Sicuramente i bulloni utilizzati dal progettista per serrare meccanicamente il collettore al blocco motore erano stati presi da una qualche tabella normalizzata, alla quale però mancava un elemento che invece oggi i moderni sistemi PLM tendono a dare la possibilità di gestire. Nel caso della mia auto probabilmente era mancata la verifica di configurazione del progetto meccanico basata sulle regole della conoscenza applicata al contesto.

Del tipo: non utilizzare un serraggio meccanico semplice su parti sottoposte a vibrazioni da questa a quella frequenza. Cose che, a saperle, meglio prenderle in considerazione prima che dopo. Forse ai tempi della mia prima automobile “la conoscenza mancate” era scritta in qualche istruzione tecnica, oppure giaceva nella mente del progettista o del suo verificatore. Il problema è che la conoscenza non basta che esista, deve essere anche fruibile.

La “buona e fruibile conoscenza” dipende molto dai metodi grazie ai quali questa viene classifica in modo da averla disponibile quando e dove serve, magari automaticamente.

Il cervello umano è molto adatto a compiere attività di tipo intuitivo e creativo, tuttavia spesso l’intelligenza scivola su delle “bucce di banana” , specie quando si compiono attività di routine. Anche per questo motivo oggi i moderni software PLM si sono evoluti e almeno quelli di “classe A” dispongono di alcune funzionalità di classificazione della conoscenza in grado di alimentare il motore di configurazione, elemento quest’ultimo indispensabile per considerare completo l’ecosistema di un PLM.

Tutto bene quindi? Problema risolto?

Non accadrà più di dover guidare un auto che perde per strada il collettore dello scappamento? Non esattamente…

Nelle grandi e piccole aziende, specie nelle grandi, ma molto spesso anche nelle piccole, si tende ancora a lavorare per compartimenti stagni. Si è vero le best practices organizzative dicono che non bisognerebbe fare così. Però quello che ci frega sempre è che fra il dire ed il fare c’è di mezzo il mare… oltre alla natura umana.

L’essere umano, noi tutti, tendiamo ad avere un innato senso di proprietà verso la conoscenza. I sistemi informatici, ERP, PLM interconnessi, interoperabili, inter…qualcosa, alla fine tendono sempre ad ereditare i difetti degli esseri umani che li utilizzano.

Quando mi capita di leggere delle specifiche di architettura di sistema informativo dove si progetta di implementare la gestione della conoscenza governata da un sistema di assistenza alla progettazione di tipo PLM scomposto per area di competenza: meccanica, elettronica, software, etc… lasciando poi che anche il sistema ERP possa disporre di analoghi sistemi di classificazione della conoscenza, se pur orientati alla produzione e al business… mi sembra che dall’ottobre 1998, mese del più grande e costoso fuoco artificio della storia, poca acqua sia passata sotto i ponti.

Il fatto cui mi riferisco è il “botto” del razzo vettore Ariane 5 causato, in senso figurato per i lettori non informatici, dall’ardita operazione di aver tentato di avvitare un dado M64 su una vite M16.

Sembra che il team dei sistemi elettronici decise di montare sul razzo un nuovo e più veloce sistema inerziale in grado di fornire i dati di volo a 64 bit. Invece il software che elaborava i dati, lo stesso utilizzato nel precedente razzo Ariane 4, utilizzava aree di memoria a 16 bit…

Tutto si risolse, dopo il decollo, con un bel errore di overflow di memoria e gran fuoco di artificio finale del costo stimato di 500 Millions $, oltre ad una figura di m… mondiale non so se a 16 o 64 bit.

Probabilmente se la configurazione di lancio fosse stata fatta passare per un sistema di “configuration management”… magari un warning generato da un vincolo di configurazione sarebbe saltato fuori, così da segnalare ai vari teams di progettazione che un sistema che fornisce dati a 64 bit poteva avere “qualche problema” con un software progettato per elaborare numeri a 16 bit.

Se qualcuno si stesse domandando: ma come hanno fatto a non accorgersi?

La risposta a questa domanda è semplice: può accadere, ciò fa parte della natura umana. Magari mentre un progettista stava verificando manualmente la corrispondenza degli attributi della classe sensori con gli attributi della classe software, un collega gli avrà detto: “andiamo a prendere un caffè?”

Invece con un sistema logistico-organizzativo basato sui principi orientati al “Configuration Lifecycle Management” risulta molto più difficile avvitare un dado M64 su di una vite M16…

Tutto ciò a patto di guadagnare un diverso punto di vista organizzativo in modo da permettere la costituzione di un database di conoscenza unico e polimorfico, parola difficile per dire “condiviso fra le varie aree di competenza aziendale”, così da far muovere tutta l’azienda verso un’architettura organizzativa unificante e semplificata, basata sui principi del Configuration LifeCycle Management.

Non è argomento questo che riguarda solo i costruttori di razzi. E’ nella fase di design e progettazione che si fanno le scelte aventi impatto su: funzionalità/economicità, appeal, di un prodotto. Più si riesce ad integrare nella vita aziendale chi si occupa di sviluppo… meglio è per tutti. Per approfondire ulteriormente questo tema consiglio la lettura di questo studio: Bridging the product configuration gap between PLM and ERP – an automotive case study

In conclusione, il tema del Configuration Lifecycle Management è un argomento che non riguarda solo le grandi aziende. La linea di demarcazione che separa le realtà che dovrebbero utilizzare i principi del Configuration Management non è dimensionale in ordine di fatturato.

La linea di demarcazione è costituita dalla più o meno alta variabilità e grado di innovazione dei prodotti realizzati da un’ azienda.

E ancora, da quanto sia decisivo il “time to market” e poi il “Time to Customer”.

Insomma, da quanto si voglia essere dinamici, flessibili e veloci… senza per questo dover fare la fine di Ariane 5.