• Non ci sono risultati.

Capitolo 9 Rintracciabilità e gestione delle informazioni

N/A
N/A
Protected

Academic year: 2021

Condividi "Capitolo 9 Rintracciabilità e gestione delle informazioni"

Copied!
18
0
0

Testo completo

(1)

Capitolo 9

Rintracciabilità e gestione delle informazioni

L’analisi descritta nello scorso capitolo ha messo in luce uno dei problemi metodologicamente più rilevanti all’interno dell’azienda: la rintracciabilità dell’informazione e, più in generale, la gestione della conoscenza.

L’obiettivo di migliorare questa situazione era emerso anche precedentemente dal lavoro dei vari team per la risoluzione delle deviazioni rispetto ai requisiti prestabiliti per superare la Design Validation.

La maggior parte dei problemi analizzati aveva come causa un certo grado di inesperienza dei progettisti di fronte a problematiche nuove rispetto al passato, fattore caratterizzante dei progetti innovativi complessi.

L’esigenza di rintracciabilità delle informazioni era stata inizialmente tamponata con la costruzione di una rete di file condivisi raggruppati per categorie tecnologiche o funzionali.

L’evolversi del progetto ha portato all’archiviazione di una mole notevole di documentazione: da qui l’esigenza di uno strumento in più per la ricerca delle informazioni necessarie in tempi brevi.

L’obiettivo del lavoro (in collaborazione col sistema qualità aziendale) stato la costruzione di una serie di strumenti operativi nell’ambito di modelli di knowledge

management per rendere di uso comune le conoscenze emerse, facendo così fronte a

un’esigenza importante.

Il modello adottato è quello proposto da Nonaka e Takeuchi nel 1997 che prevede due aree di influenza del knowledge management: la prima riguarda l’aspetto della creazione di conoscenza, la seconda della gestione della conoscenza creata.

Questi due aspetti si risolvono in paradigmi gestionali che prevedono tre fasi sequenziali.

(2)

Le tesi proposte dagli studiosi giapponesi nell’ambito della creazione di conoscenza mettono in luce l’utilità di un sistema pianificato e strutturato nel processo di risoluzione dei problemi inteso come sviluppo di nuovo know-how da cui deriva un’innovazione delle skills che portano a un vantaggio competitivo per l’azienda dato dall’evoluzione professionale delle figure che vi operano.

La schema in figura 9.1 descrive i tre passi sequenziali.

Fig. 9.1 Modello per la creazione di conoscenza

Il vantaggio competitivo dato dallo sviluppo di nuove abilità e, in generale, da una continua innovazione conoscitiva è l’assioma fondamentale degli studi di Nonaka che possono essere esemplificati dall’affermazione generale “in un’economia dove l’unica

certezza è l’incertezza, l’unica sicura risorsa per il vantaggio competitivo è data dalla conoscenza”.

(3)

La seconda area di interesse del modello e che più si concretizza in azioni operative riguarda la sfera della gestione della conoscenza.

Nonaka e Takeuchi sostengono che il processo di gestione della conoscenza richieda tre fasi: la gestione dell’informazione, la gestione della conoscenza e la condivisione della conoscenza.

La prima fase riguarda la capacità di un sistema di avere un facile e veloce metodo di rintracciabilità dei documenti emessi. In questo primo passo l’informazione è intesa come l’”involucro” della conoscenza che, come fosse un componente tangibile, deve essere immagazzinata e deve poter essee recuperata al momento opportuno.

Nella seconda fase si passa da una gestione dell’”involucro” a una del “contenuto” dove l’informazione diventa la conoscenza vera e propria, tecnica o metodologica che sia.

In questa fase l’obiettivo della gestione è la predisposizione di formiche consentano, una volta rintracciata l’informazione voluta, di apprendere la conoscenza contenuta nel documento. Dal punto di vista operativo si tratta di stabilire la forma che devono assumere i documenti nella compilazione per favorire una facile lettura e per acquisire i contenuti voluti.

La terza fase, infine, si pone l’obiettivo di rendere usufruibile a tutti i livelli interessati le informazioni già codificate dai precedenti due passi.

(4)

Fig. 9.2 Modello per la gestione della conoscenza

A livello operativo ci si è concentrati nello sviluppo di strumenti per rendere applicabile i modello appena descritto, focalizzandosi sulla sfera della gestione della conoscenza. In particolare sono stati studiati sistemi per rendere operativo il primo passo (la gestione delle informazioni) e il terzo passo (la condivisione della conoscenza).

Il secondo passo, che prevede la gestione della conoscenza, riguarda aspetti tecnici che evidenziano il “contenuto” dell’informazione e che sono parte integrante del lavoro dei team nella risoluzione dei problemi. In questo contesto sperimentale la forma della conoscenza è data dai report tecnici in uscita dai team e può anche essere resa omogenea attraverso l’utilizzo delle schede del sei sigma predisposte nell’applicazione del metodo DMAIC.

(5)

Per quanto riguarda la gestione dell’informazione, l’obiettivo del lavoro è stato lo sviluppo di un sistema di classificazione della documentazione.

Per quanto riguarda la condivisione della conoscenza, l’obiettivo è stato la creazione di un database di condivisione delle informazione denominato Lesson Learned.

(6)

9.1 Classificazione

Un altro aspetto analizzato e per cui è stato sviluppato un altro strumento di supporto alla reperibilità delle informazioni è un sistema di classificazione chiaro e univoco.

Attualmente esiste un sistema di classificazione per quanto riguarda le procedure e i metodi ma le note tecniche vengono archiviate con un nome a discrezione del compilatore, creando una situazione di caos causata dalla “personalizzazione” della classificazione.

E’ parso necessario costruire un sistema che renda omogenei i documenti emessi.

Un altro scopo del sistema di classificazione è rendere possibile la rintracciabilità di un documento anche se le keywords presentano differenti accezioni o, più banalmente, errori di ortografia.

Il sistema sviluppato prende come modello di riferimento il sistema “KKS” già usato da Ansaldo Energia. Il sistema è stato riadattato in funzione delle esigenze diverse della Siemens VDO Automotive. La differenza principale sta nella tipologia di industria: di processo la prima, manifatturiera la seconda.

Il sistema di classificazione KKS è composto da una stringa di dodici caratteri che identificano cinque sezioni (vedi figura 9.3).

(7)

Fig.9.3 Sistema di classificazione

Le cinque sezioni che rendono possibile la classificazione fanno riferimento a una logica di scomposizione dal più grande al più piccolo (scomposizione top down): la prima sezione fa riferimento al progetto generale e le successive entrano nel dettaglio.

Le sezioni riguardano: • Il progetto

• Il dipartimento che emette il documento • Il sistema (o sottosistema funzionale) • La disciplina tecnologica di riferimento • Un numero progressivo per l’archiviazione

Ogni sezione è formata da una stringa di caratteri: tre per la prima e l’ultima e due per le altre.

(8)

Le abbreviazioni sono state realizzate sulla base delle convenzioni già esistenti all’interno dell’azienda, in modo da evitare la proliferazione di sigle che renderebbero inefficiente e non funzionale il sistema.

Di seguito verranno descritte più dettagliatamente le varie sezioni.

9.1.1 Sezione 1: il progetto di riferimento

La prima serie di caratteri (tre) identifica il prodotto di riferimento. La decisione di adottare un’abbreviazione a tre caratteri deiva dal sistema di riferimento già presente. Ad esempio, il progetto Piezo è già identificato come “PDI” (Piezo Direct Injection) e tutti prodotti realizzati da Siemens VDO Automotive hanno questa denominazione; un altro esempio può essere quello dell’iniettore con attuatore a solenoide, denominato “SDI” (Solenoid Direct Injection) e così tutti gli altri.

9.1.2 Sezione 2: dipartimento che emette il documento

L’identificazione del dipartimento è importante perché identifica anche l’area in cui è emerso il problema.

E’ una sezione più generale della successiva (il sistema funzionale) perché per ogni sistema ci possono essere diverse tipologie di problemi: dal design alla qualità, dal processo tecnologico al testing.

Il problema più rilevante emerso per questa categoria è stato l’adozione di una sigla comprensibile, possibilmente già usata. Ogni divisione della Siemens VDO Automotive ha diversi dipartimenti in base alle esigenze interne e alla cultura organizzativa della location.

Per ovviare a una moltiplicazione eccessiva di sigle che rispettassero tutte le autonomie organizzative, è stato preparato una schema principale con delle funzioni presente in tutte le varie divisioni, come descritto nella tabella 9.1.

(9)

PD Product Development

QU Quality

PR Production

PE Process Engineering

TE Testing

Tab. 9.1 Identificazione funzioni

9.1.3 Sezione 3: Sistema funzionale

La sezione riguardante il sistema funzionale è una delle più critiche della classificazione, dato che entra nel dettaglio della localizzazione a cui fa riferimento il documento in esame.

Dato che ogni prodotto è sostanzialmente diverso dagli altri, con sistemi funzionali non sempre analoghi, il problema principale è la necessità di standardizzare la sigla perla classificazione sapendo che i prodotti che verranno sviluppati in futuro presenteranno sicuramente delle novità costruttive non preventivabili a tutt’oggi.

L’idea di base per avere un sistema effettivamente ripetibile è il riferimento a una scomposizione standard con parametri facilmente estrapolabili e sintetizzabili.

E’stato deciso di fare riferimento a un documento standard previsto per tutti i prodotti che vengono sviluppati: la Bill Of Material (BOM).

La distinta dei materiali presenta, infatti, una scomposizione del prodotto in tutti i componenti, raggruppati per area funzionale.

Questa scomposizione permette una standardizzazione dato che i criteri di suddivisione sono già definiti.

Nel caso dell’iniettore piezoelettrico, lo spaccato riportato in figura 9.4 evidenzia bene la scomposizione che rispecchia le caratteristiche di funzionalità necessarie per l’identificazione.

(10)

Il prodotto è scomposto in otto sottosistemi, un numero accettabile per non creare un’eccessiva frammentazione e rendere limitato il numero degli acronimi.

I sistemi funzionali sono: • Il compensatore idraulico • L’inlet fitting • Il termo-compensatore • L’elemento piezoelettrico • L’involucro esterno • La flangia • L’involucro interno

• La valvola, sede dello spillo e dell’ugello

Hydraulic

Compensat Inlet Fitting

Thermal Compensat Piezo Stack External Tube Internal Tube Flange Valve Body

(11)

Le abbreviazioni sono riportate nella tabella 9.2. HC Hydraulic Compensator IF Inlet Fitting TC Thermal Compensator PS Piezo Stack ET External Tube FL Flange IT Internal Tube VB Valve Body

Tab. 9.2 Identificazione parti del prodotto

Il sistema adottato permette la ripetibilità di certe sigle anche per prodotti diversi, quando è possibile; ad esempio, la valvola è un elemento comune a tutti gli iniettori, dunque il sistema funzionale “VB” sarà presente per tutti i prodotti. In questo modo sarà possibile ricercare tutte le informazioni relative al sistema valvola per tutti i prodotti rendendo così una serie di informazioni al progettista che potrà confrontare anche le diverse soluzioni costruttive di più esperienze, prendendo ispirazione dal pi pertinente al suo caso.

Ovviamente questo non sarà possibile per tutti i sistemi: l’elemento PS (piezo stack) è una peculiarità esclusiva di questo tipo di iniettore e non si trova negli altri.

9.1.4 Sezione 4: Disciplina tecnologica di riferimento

Questa sezione è quella che ha il maggior grado di variabilità perché descrive sinteticamente il tipo di problema emerso.

Alcuni aspetti sono standard e generalizzabili, ad esempio le saldature, le cricche, la contaminazione ecc…; altri sono peculiari del singolo tipo di prodotto.

Questa classificazione nasce dalle esigenze emerse dall’iniettore piezoelettrico che rappresenta, in questo senso, il progetto pilota.

In futuro ci saranno sicuramente adeguamenti che si riferiscono ad altri elementi e altre discipline tecnologiche.

(12)

In questa sezione sono state definite una serie di acronimi che riguardano solo i problemi e gli aspetti tecnologico costruttivi analizzati nell’esperienza di cui è oggetto la presente tesi che non ha scopi di carattere generale ma si occupa solo di alcuni aspetti particolari.

A titolo di esempio vengono riportate le discipline (e le relative sigle) individuate in questa esperienza, raggruppate nella tabella 9.3.

AS Assembly CL Cleaning/contamination CR Cracks CT Cycle Time HA Handling LE Leak MA Machining MC Material Corrosion MD Material Durability MS Misfire OL Oil OX Oxidation SP Spray WA Washing WE Welding

Tab. 9.3 Identificazione problemi

9.1.5 Sezione 5: Numero progressivo

I tre caratteri della quinta sezione sono semplicemente dei numeri progressivi, necessari per l’archiviazione e per evitare duplicazioni.

Quando si hanno più problemi legati allo stesso componente e alla stessa disciplina, la classificazione rischierebbe, altrimenti, di avere due documenti con lo stesso nome; il numero progressivo risolve questo problema.

(13)

Come esempio si può citare un problema già descritto nei precedenti capitoli: la black

oxidation sull’external tube.

Il documento in archivio verrà classificato come PDI-PE-ET-WE-001. Se la saldatura laser dovesse avere dei problemi di saldabilità nella stessa zona, dovuta (ad esempio) al materiale, la classificazione sarà PDI-PE-ET-WE-002.

Senza l’identificativo finale (il numero progressivo), i due documenti avrebbero lo stesso codice e il secondo non sarebbe archiviabile nel database delle lesson learned che non accetta duplicazioni.

(14)

9.2 Lesson Learned

Letteralmente Lesson Learned sta per “lezioni di apprendimento”: se si dovesse presentare una situazione di deviazione rispetto ai requisiti o una qualunque altra sorta di problema, il progettista dovrebbe informarsi su come era stato affrontato il problema in passato e sulle soluzioni identificate che potrebbero essere riutilizzate o, almeno, usate come spunto per l’analisi.

Attualmente è prevista la redazione di rapporti tecnici che, però, troppo spesso diventano lettera morta, nel senso che vengono archiviati insieme a centinaia di altri file e documenti, rendendo dispendiosa e lenta la ricerca e inficiando il vantaggio dell’esperienza acquisita con l’eccessiva lentezza per il reperimento dell’informazione.

La Lesson Learned è, invece, un documento sintetico che viene archiviato in un database apposito.

All’interno della Lesson Learned si potrà comunque collegare un richiamo al rapporto o alle note tecniche ma la funzione è un’altra.

Il database delle Lesson Learned è inserito all’interno della reste intranet aziendale a cui hanno accesso tutti i dipendenti delle varie sedi della Siemens VDO Automotive.

9.2.1 Ricerca di Lesson Learned

Quando il database viene aperto, la schermata iniziale è la sezione “ricerca” (vedi figura 9.5).

La maschera d’interfaccia è costituita essenzialmente da due settori: • La colonna di sinistra (grigio): è la zona dei comandi

(15)

Fig.9.5 Database Lesson Learned – Ricerca

Zona dei comandi.

Nella parte superiore (Form Options) sono visualizzati i pulsanti di comando del form che appare nella colonna di destra e sono specifici. In figura si vede solo il pulsante

“Performance Search” perché l’unica opzione voluta è quella di ricerca.

Nella parte inferiore sono presenti i tre comandi per la navigazione: “Enter a Lesson” (per inserire una nuova Lesson Learned), “Search” (per cercare una o più Lesson

Learned) e “Reports” (genera i report delle informazioni desiderate).

Form.

Sono presenti cinque campi, ciascuno può essere riempito o meno in base ai criteri di ricerca desiderati.

(16)

Il campo “Lesson Learned #” è utilizzabile quando si conosce il numero esatto di archiviazione della Lesson Learned (codice alfanumerico).

Gli altri campi sono gli stessi relativi alla codifica di classificazione già descritta precedentemente.

9.2.2 Inserimento di nuova Lesson Learned

Per accedere a questa opzione è sufficiente ciccare sul pulsante “Enter a Lesson”. Viene visualizzata la schermata riportata in figura 9.6.

Fig.9.6 Database Lesson Learned - Inserimento

Zona dei comandi.

La parte relativa alla navigazione è, ovviamente la solita. Cambia la parte superiore, le “Form Options”.

(17)

Sono presenti tre pulsanti:

• Process: una volta compilato il form serve per salvare la Lesson Learned e archiviarla

• Print: comando di stampa

• Email: per inviare il form tramite posta elettronica Form.

La prima riga contiene informazioni generiche quali la data, il numero della Lesson

Learned, la sede dove viene scritta e il numero di telefono.

Scendendo in basso, nella videata si trovano i quattro campi di classificazione.

Infine ci sono i tre campi che definiscono la vera e propria Lesson Learned: • Lesson Learned: viene immesso nel campo il contenuto vero e proprio della

lezione

• Driving Event: indica l’evento (problema) che ha portato alla ricerca di soluzioni e alternative. Inquadra la lezione nel contesto in cui è stata scritta.

• Recommended actions & implementations: sono note a margine dell’autore che non rientrano nei campi precedenti. Il campo contiene informazioni a livello più operativo rispetto al primo.

(18)

9.3 Prospettive future

Il sistema di classificazione descritto permette un’archiviazione efficace ed efficiente nel database e permette una rintracciabilità immediata attraverso la descrizione sintetica del problema fornita dalle cinque sezioni della stringa.

In questo modo si velocizza la ricerca all’interno del database potendo concentrarsi sul dettaglio voluto ed evitando una lista eccessiva che potrebbe risultare da una semplice ricerca delle keywords. Inoltre viene risolto il problema della ricerca di documenti in caso di errori ortografici nell’elencazione delle keywords nei campi del database (errore sempre possibile) e da’ un’impostazione standard della codifica di un documento: infatti, a seconda di chi compila la lesson learned, ci potrebbero essere molte parole chiave come una sola. Questo sistema è la base per un’indicazione standard di come debba essere compilato il documento e un sistema generale di classificazione che renda omogenei i criteri di ricerca.

Figura

Fig. 9.1 Modello per la creazione di conoscenza
Fig. 9.2 Modello per la gestione della conoscenza
Tab. 9.1 Identificazione funzioni
Fig. 9.4 Scomposizione iniettore
+3

Riferimenti

Documenti correlati

Qualora una relazione possieda degli attributi, va anch’essa scissa in due relazioni (1:1 oppure 1:m a seconda della cardinalità della relazione originaria) collegate ad una

Calcolare fino alla derivata quinta della funzione data pu`o per`o essere lungo, noioso e con alta probabilit`a

L’esame dei risultati dell’analisi agli elementi finiti effettuata sul modello riproducente la struttura nello stato attuale ha evidenziato la possibilità di

Bill Gates negli anni ‘80 (courtesy of Computer History Museum). Steve Jobs negli

In questo lavoro sono state affrontate le problematiche relative alle subroutines ed è stato implementato in Java un componente in grado di compiere una verifica delle

Entra in scena un personaggio cattivo = antagonista che crea un problema.. Il protagonista deve lottare con l’antagonista per risolvere

ematologiche, soprattutto nella corretta determina- zione delle popolazioni cellulari del sangue median- te sistemi automatizzati. L’obiettivo della relazione, infatti, non è quello

Nelle frasi seguenti ci sono 39 errori ortografici, sottolineali e riscrivi le parole corrette sul tuo quaderno..  Lo sentito dire da Gaia, non so se e