Capitolo 5
L'approccio al problem solving
Alla fine della fase di sviluppo del prodotto, in occasione dei test per la validazione del Design (Design Validation) e del Prodotto (Product Validation), la revisione ha avuto un esito negativo.
Il management, coerentemente con le procedure interne, ha deciso di adottare un approccio strutturato per affrontare e risolvere i problemi emersi che hanno portato alle deviazioni rispetto ai requisiti presenti nella specifica del cliente.
L’approccio, di tipo pianificato e sistematico, ha seguito le seguenti fasi:
• Brainstorming generale • Definizione dell' Action List
• Definizione dei Sub-project
• Definizione dei team e della relativa struttura • Assegnazione delle priorità
5.1 Brainstorming
La fase di brainstorming è stata coordinata da un consulente in rappresentanza del management centrale allo scopo di supervisionare nella fase iniziale la definizione delle strutture organizzative necessarie per la risoluzione dei problemi.
Il brainstorming ha interessato lo stearing committee, il “comitato guida” che è responsabile e gestisce il coordinamento delle varie funzioni interessate.
Bisogna ricordare che la struttura organizzativa di Siemens VDO Automotive è di tipo matriciale: la suddivisione di tipo funzionale si interseca con un project manager per ogni progetto specifico (come nel caso del PDI - Piezo Direct Injection) che ha l’obiettivo e la responsabilità di coordinare le attività e i team interfunzionali durante tutto il ciclo di sviluppo del prodotto.
Lo stearing committee ha visto la partecipazione del project manager, dei responsabili delle funzioni aziendali interessate e di alcuni progettisti.
Scopo di questo primo passo è stata l'elencazione di tutti i possibili problemi riscontrati, il raggruppamento in categorie generali e una visualizzazione iniziale delle relazioni tra i vari argomenti.
Alla fine di questo passo sono stati emessi due documenti:
1. Un elenco dei punti critici rispetto alle devizioni emerse nella fase di testing.
2. Un diagramma per visualizzare in forma schematica e concisa le varie problematiche e una prima correlazione fra queste (Fig.5.1)
5.2 Action List
I problemi emersi sono di vario tipo e con differenti criticità. Sarebbe impensabile costituire unità operativa per la risoluzione di tutti i problemi nel dettaglio, dato che alcuni interessano lo stesso ambito tecnico mentre altri hanno una rilevanza diversa.
E’ necessaria una fase di screening per la “scrematura” dei problemi, con l’eliminazioni di quelli meno rilevanti o con possibilità di risoluzione immediata.
Obiettivo dello step è l'elenco di azioni correttive da intraprendere, con un primo dettaglio dei tempi da rispettare e dei responsabili assegnati.
Questo elenco è denominato Action List ed è il documento di riferimento per tutto il processo di problem solving.
La lista non è completa e dettagliata; in alcuni casi i punti sono poco chiari, alcune responsabilità non sono ancora assegnate e alcuni problemi sono stati accantonati perché di risoluzione immediata o con attività di routine.
Rispetto all’elencazione avvenuta in seguito al brainstorming, è da evidenziare come le
issues siano diminuite da 130 a 70: quasi il 50% in meno.
Il numero resta comunque ragguardevole e sarà ulteriormente diminuito con l’accorpamento di varie issues caratterizzate da una certa omogeneità. La fase di
screening, dunque, non può dirsi terminata e risulta abbracciare diversi step del metodo
5.3 Definizione dei Sub-project
Anche se c'è stata una notevole riduzione, la lista dei 70 problemi rimasti risulta comunque essere molto numerosa e di difficile gestione.
L'approccio strutturato si pone come obiettivo di questo passo l'accorpamento dei problemi che hanno attinenza con lo stesso ambito, al fine di avere un numero più limitato di aspetti da gestire.
I problemi affini sono stati raggruppati in sotto-progetti (sub-projects).
Il risultato è l'identificazione dei diciotto sub-projects elencati nella tabella 5.1.
ID Function Main activities
1 DV Remaining DV
2 DV IMH flow vs. temperature test
3 PD Terminal welding development
4 PD Spray cone angle optimization
5 PD Laser Welding design/requirment optimization
6 PD Durability issue solving (Coating optimization)
7 PD Fuel intrusion issue
8 PD Specification finalization
9 PD Valve cartridge micro crack ( shot peening alternative?)
10 MD Process/equipment optimization - final debug:
a)Machining b)Assembly c)Testing
11 MD Washing development (include oxidable component)
12 MD Production increase capacity (Phase 2 step)
13 PV PV testing
14 RA Sample Return analysis (failure+Durability+TCMA+ TCMB)
15 Mis Misfire issue for the N53 engine
16 PPQ5 PPQ5
17 PS Scrap analysis (internal)
18 PS Incoming inspection for production components
Nella tabella, oltre alle attività, è presente un numero progressivo e una sigla che identifica l'ambito di riferimento dei ogni sub-project:
• DV: Design Validation • PD: Product development
• MD: Manufacturing development
• PPQ5: Acclerated reliability test definition • PS: Product support
• RA: Return analysis • Mis: Misfire
A questo punto la fase di screening può dirsi terminata. Di seguito vengono descritti i momenti successivi: l’organizzazione interna per l’approccio a i problemi e la rilevanza degli stessi (fase di scoring).
5.4 Definizione dei team e della relativa struttura organizzativa
In un’organizzazione di tipo matriciale, i team e le task forces sono gli elementi cardine che rendono la struttura (di per sé abbastanza complessa) flessibile e adatta ad affrontare le emergenze.
Lo sviluppo di un prodotto innovativo e complesso (come può essere l’iniettore in questione) si trova ad affrontare una serie di problemi dati dall’incertezza intrinseca delle novità tecniche e tecnologiche che solo in parte possono essere ricollegate a soluzioni storiche adottate dall’azienda o pertinenti del bagaglio culturale dei progettisti. In certi casi si tratta di soluzioni costruttive completamente innovative e che necessitano di riscontri sperimentali e di tempo per la messa a punto.
La struttura organizzativa flessibile e l’approccio strutturato permettono di affrontare i problemi con una logica non casuale e scollegata dalle iniziative legate ai singoli individui. Questo aspetto dell’organizzazione è il cuore del vantaggio competitivo di un’impresa di grandi dimensioni e che qualifica agli occhi del cliente l’affidabilità necessaria per avere garanzie su un prodotto di qualità nei tempi assegnati.
Per ognuno dei diciotto sub-projects è stato costituito un team con l'obiettivo di risolvere il problema: questi team sono delle vere e proprie task forces composte da un numero diverso di persone a seconda dell'entità del problema e delle risorse necessarie per risolverlo.
Ogni Team ha un Coach e un Team Leader di riferimento, che in taluni casi possono anche coincidere nella stessa persona. Il Coach è il responsabile per quanto riguarda l'aspetto delle risorse (economiche e non) del sotto-progetto, mentre il Team Leader è il coordinatore operativo dell'attività e colui che presiede i meeting e pianifica le attività di ogni gruppo.
Normalmente il Coach è un responsabile di una funzione di riferimento dell'organigramma aziendale.
La numerazione dei team rimane per tutta la durata del progetto assegnato.
Successivamente sono stati “scorporati” dalla lista alcuni sub-project ritenuti non più dipendenti dal project manager ma affidati al responsabile della funzione di interesse. I sub-project non esaminati sono elencati nella tabella 5.2.
ID Function Main Activities
10 MD Process/equipment optimization – final debug: a)Machining b)Assembly c)Testing
11 MD Washing development (include oxidable component)
12 MD Production increase capacity (Phase 2 step)
17 PS Scrap analysis (internal)
18 PS Incoming inspection for production components
Tab.5.2 Sub-project esclusi dal coordinamento del project manager
I primi tre sono stati affidati alla funzione Manifacturing Engineering mentre gli ultimi due sono andati alla funzione Testing.
Per ogni team in esame sono stati definiti il Coach, il Team Leader e i membri.
La tabella 5.3 riassume (quantitativamente) la composizione dei team.
ID Function Main activities
Number (members +
equirement)
1 DV Ramaining DV 1
2 DV
IMH flow vs. temperature test
1
3 PD Terminal welding development 3
4 PD Spray cone angle optimization 10
5 PD Laser Welding design/ equirement optimization 8
6 PD Durability issue solving (Coating optimization) 4
7 PD Fuel intrusion issue 3
8 PD Specification finalization 1
9 PD
Valve cartridge micro crack
( shot peening alternative?) 9
13 PV PV testing 3
14 RA
Sample Return analysis
(failure+Durability+TCMA+ TCMB) 2
15 Mis Misfire issue for the N53 engine 6
16 PPQ5 PPQ5 2
5.5 Priorità
Prima di stabilire la pianificazione delle attività e le risorse(umane ed economiche) da destinare ad ogni team è stato adottato un sistema per definire la priorità di ogni sotto progetto.
5.5.1 Il Risk Management
La definizione di priorità per affrontare i problemi ricade nella sfera più vasta del Risk
Management.
L’attribuzione di risorse, la definizione di team, la pianificazione delle attività da svolgere sono attività a rischio perché rientrano in un processo di sviluppo che ha delle fasi ben definite e una scadenza nei confronti del cliente. La gestione del rischio deriva dalla necessità di risolvere i problemi nel migliore dei modi possibili e nel rispetto dei vincoli temporali e di costo.
Dato che non tutte le attività hanno lo stesso grado di complessità e dato che l’impatto sulla piena riuscita del progetto non è la stessa, serve un metodo consolidato per la gestione dei queste deviazioni: il Risk Management.
Il Risk Management prevede due fase ben identificate: • Il Risk Assessment
• Il Risk Treatment
Queste due fasi servono alla definizione dei rischi e al livello di priorità da assegnare e alla gestione vera e propria delle attività a rischio.
Risk Treatment
Identifyin Implementing Monitoring Assessin Identifying Monitoring AssessingAction definition by team
Risk Assessment
Fig.5.2 Modello di Risk Management
La prima fase del Risk Management è la definizione del Meeting Goal. Si tratta di definire con i capi reparto azioni a breve termine per rendere più efficiente il processo della gestione dei rischi del progetto piezo.
Segue la fase di classificazione e gestione vera e proprio delle attività a rischio. Infine c’è la fase di chiusura del processo di Risk Management.
FASE 3
FASE 2
FASE 1
Nell’ambito del progetto piezo, la situazione di partenza per la gestione delle deviazioni si è presentata con una serie di difficoltà e di punti non chiarificati:
• Mancanza di un team strutturato di Risk Management.
• Mancanza di raccolta e valutazione di nuovi rischi legati allo svolgimento del progetto (nuovi rischi durante lo sviluppo, rischi di produzione,…).
• Mancanza di monitoraggio locale delle singole azioni definite
Dall’analisi delle mancanze si è proceduto alla proposta di azioni migliorative per affrontare i problemi, sintetizzati nel seguente elenco:
• Possibile definizione di un Risk Management Team: definire i reparti-gruppi coinvolti e nominare un responsabile per ogni gruppo.
• Impegno da parte dei responsabili ad un aggiornamento settimanale (monitoraggio azioni e valutazione nuovi rischi). Il PM organizza riunioni di revisione e aggiorna il file riassuntivo.
• Condivisione della definizione delle azioni da parte del team e impegno nel completare le azioni da parte dei responsabili.
5.5.2 Modello proposto per l’assegnazione delle priorità
In passato non esisteva in azienda una metodologia per assegnare le priorità, azione di esclusiva competenza del Project Manager che, sulla base della propria esperienza e dei colloqui avuti con i vari Coach, decideva in modo unilaterale.
E’ stata proposta una metodologia molto semplice: partendo dal presupposto della condivisione delle conoscenze, è stato richiesto ad ogni coach di assegnare un grado di priorità ad ogni sotto-progetto.
Il ranking prevede tre possibili gradi: 1. H (high): priorità alta
2. M(medium): priorità media 3. L(low): bassa priorità
Per rendere il concetto più chiaro, specialmente a livello d'impatto visivo, è stato adottato un codice colore già presente in molti form e documenti aziendali: verde (L), giallo (M), rosso (H).
Ad ognuno di questi gradi è stato associato un punteggio da 1 a 3 a seconda del grado attribuito: ad un'alta priorità è stato attribuito un punteggio "3", ad una media "2" e ad una bassa "1".
Il questionario è stato sottoposto a sei persone: il Project Manager più cinque Coach (in questo caso tutti responsabili delle funzioni).
Per stabilire la priorità da assegnare sono stati stabiliti dei limiti per le medie dei punteggi: • Nell'intervallo [1;1,5] Î priorità bassa, codice verde (L)
• Nell'intervallo ]1,5;2,5[ Î priorità media, codice giallo (M) • Nell'intervallo [2,5;3] Î priorità alta, codice rosso (H)
Il principio che ha guidato l'assegnazione di questi valori come limiti di soglia risponde a un metodo valutativo molto empirico e di "buon senso".
Se la maggioranza delle persone (6 intervistati) è concorde su un certo valore, viene assegnata la priorità corrispondente.
La situazione analizzata per stabilire i limiti è la presenza di metà giudizi con un valore e metà con un altro. Per semplificare l'analisi si sono considerate solo le situazioni con metà "L" e metà "M" e quelle con metà "M" e metà "H", tralasciando le combinazione di tutti e tre i valori.
Da una parziale simulazione svolta sulla distribuzione dei giudizi successivi (quindi "L" e "M" oppure "M" e "H") si ottengono 13 situazioni.
Per armonizzare il giudizio è stato scelto di escludere i limiti nell'assegnazione di una priorità "Medium".
Ad esempio, con tre giudizi "Low" e tre "Medium" si ha un punteggio medio di 1,5 che rappresenta la soglia inferiore nella scala delle priorità: ad un punteggio di 1,4 viene assegnata un priorità "Low".
Situazione analoga con tre "M" e tre "L": si ha un punteggio medio di 2,5 che viene considerato priorità "High".
Attraverso questi parametri, la simulazione rende su 13 occorrenze: • 3 Low
• 4 Medium • 4 High
Questa attribuzione è ritenuta soddisfacente perché rispecchia il principio per cui le priorità alte devono essere costantemente sotto controllo e un giudizio con punteggio medio pari a 2,5 deve essere messo sotto controllo, non può essere sottovalutato.
Per i limite inferiore, invece, si parte dal presupposto che i problemi valutati a bassa priorità sono sempre un numero marginale e serve un discrimine più ampio per la distinzione tra bassa e media priorità.
Questo semplice modello ha portato all’attribuzione di priorità su tutti i sub-project, riportate in tabella 5.4.
Main activities
Priority Cini Priority Attolico Priority Facch
in
Priority Ma
nnuc
c
i
Priority Giorgetti Priority Co
rd o va Ave rag e Priority 1.Ramaining DV 2 3 3 3 2 2 2,50 H
2.IMH flow vs. temperature test 2 3 3 3 3 1 2,50 H
3.Terminal welding development 2 3 3 3 2 1 2,33 M
4.Spray cone angle optimization 3 3 3 3 2 3 2,83 H
5.Laser Welding design/requirment optimization
2 2 2 2 1 3 2,00 M
6.Durability issue solving (Coating optimization)
3 3 3 3 3 2 2,83 H
7.Fuel intrusion issue 3 3 3 3 3 2 2,83 H
8.Specification finalization 3 2 3 2 2 1 2,17 M
9.Valve cartridge micro crack ( shot peening alternative?)
3 2 2 2 3 2 2,33 M
10.Process/equipment optimization - final debug
3 2 2 2 3 3 2,50 H
11.Washing development (include oxidable component)
2 3 3 2 3 2,60 H
12.Production increase capacity (Phase 2 step)
3 2 2 2 1 2,00 M
13.PV testing 3 2 3 2 3 2 2,50 H
14.Sample Return analysis (failure+Durability) 2 2 2 2 2,00 M
15.Misfire issue for the N53 engine 3 3 3 1 2,50 H
16.PPQ5 2 2 1 1 1,50 L
17.Scrap analysis (internal) 2 3 2 3 2 2 2,33 M
18.Incoming inspection for production components
1 2 3 2,00 M
La tabella 5.5 riporta l’attribuzione di responsabilità e delle priorità in forma ufficiale. Questo documento è stato inserito all’interno del Project Folder, una cartella di documenti condivisa da tutta l’organizzazione.
5.6 Kick-off meeting dei team e pianificazione delle attività
I Team formalizzano la loro costituzione nell'ambito di un Kick-off meeting dove vengono stabiliti:
• la costituzione del team (Coach, Team Leader, Team Members) • gli obiettivi da raggiungere
• la pianificazione temporale sulla base della priorità assegnata • l'assegnazione delle risorse
• la suddivisione delle attività e le scadenze intermedie • la cadenza del reporting (meeting minute)
La pianificazione temporale delle attività è riassunta dalla linea temporale (Fig.5.4) che raffigura le scadenze di tutte le attività sull’orizzonte temporale. Ogni team, successivamente, pianifica le proprie sotto-attività e le inserisce in un diagramma di Gantt.
Fig.5.4 Orizzonte temporale dei sub-project
La priorità delle attività è visualizzata con il codice colore corrispondente (verde, giallo e rosso). Le risorse sono state attribuite tenendo conto della priorità e del tipo di attività. I sub-projects sono stati codificati all’interno del sistema SAP.
5.7 Monitoraggio e reporting
Una delle esigenze emerse in questa fase riguarda l’attività di coordinamento e reporting. Come già accennato, ogni team ha una sua struttura autonoma che si occupa di gestire il relativo sub-project sulla base dell’orizzonte temporale predefinito.
Nonostante la delega di queste attività, il project manager ha sentito l’esigenza di formalizzare un sistema per il monitoraggio costante delle attività sia a livello generale (avere un quadro unitario di avanzamento delle attività), sia a livello di dettaglio per le attività specifiche dei team.
Il lavoro svolto ha messo a punto un sistema per favorire il coordinamento fra le attività e tenere sotto controllo gli eventuali ritardi.
Questo sistema è costituito da una serie di fogli di calcolo inseriti all’interno del Project
Folder e aggiornabili da tutti i Team Leader.
Fig.5.4.1 Particolare del sistema di monitoraggio: corpo centrale
La figura 5.4 da il quadro d’insieme della videata.
Nel corpo centrale (Fig.5.4.1) sono riportate le attività con la numerazione attribuita in fase iniziale e quella generata dal sistema SAP per l’attribuzione delle risorse. Sono inoltre riportate la priorità, il nome dei Team Leader, dei Coach e le scadenze.
Nella parte a destra (Fig.5.4.2) è riportato l’orizzonte temporale, con la numerazione delle settimane secondo l’anno solare.
Per ogni settimana è presente una casella dove viene inserito una sigla tra le seguenti: • D (Done): quando il sub-project è completato
• OT (On Time): quando il sub-project è “in tempo”, cioè segue le scadenze pianificate
• OG (On Going): quando il sub-project non ha oltrepassato la scadenza prefissata ma è presente un rischio di non riuscire a rispettare il tempo assegnato
• L (Late): quando il sub-project è in ritardo, ha oltrepassato la scadenz prefissata.
Il codice colore associato ai vari status rende visivamente la situazione a livello unitario. Il verde (rischio basso) è associato agli status Done e On Time.
Il giallo (richio medio) è associato allo status On Going. Il rosso (rischio alto) è associato allo status Late.
L’attribuzione dello status dipende dalle scadenze attribuite ad ogni sottoattività dei
sub-projects e dalle relative scadenze.
Il sistema è collegato ad altri fogli interni per ciascun sub-project.
Fig.5.5 Scheda per il reporting del sub-project 9: Valve Cartridge Microcrack
Fig.5.5.1 Particolare scheda per il reporting: sottoattività
Il particolare in figura 5.5.1 mostra la divisione del sub-project in sottoattività: ciascuna è delegata a un responsabile con una certa scadenza secondo un orizzonte temporale ravvicinato (dell’ordine di tre-quattro settimane). Il raggiungimento o meno delle scadenze definisce lo status delle sottoattività.
Lo status generale del sub-project deriva da quello delle singole attività: • Se tutte le attività sono completate (Done) lo status è Done.
• Se almeno un’attività è On Time e le altre sono Done, lo status è On Time • Se almeno un’attività è On Going e nessuna è Late, lo status è On Going • Se almeno un’attività è Late, lo status è Late
Attraverso questo sistema autoaggiornante (lo status è definito automaticamente dai giudizi espressi nelle singole schede), i Team Leader possono monitorare l’avanzamento dei lavori e il project manager ha una visone d’insieme di tutti i sub-project.
Inoltre è previsto che in caso di rischio (status On Going o Late), il Team Leader provveda a inserire la possibile causa del ritardo e l’azione tampone presa per ovviare all’inconveniente.
L’ultima parte del sistema è dedicata alle “references”, una serie di collegamenti alla documentazione tecnica interna, per permettere di risalire velocemente ai documenti in cui vengono descritti in modo approfondito le sottoattività.
Questo sistema è stato adottato in via sperimentale dai tredici team e prevede, come già accennato, un aggiornamento settimanale da parte dei Team Leader.
Ogni settimana viene salvato il file in una cartella apposita all’interno del Project Folder chiamata “G3-2-Status-weekly-reports”.
All’interno della cartella sono presenti i file salvati settimanalmente, in modo da mantenere lo storico degli aggiornamenti.
Per avere una facile lettura, i file prendono il nome dalla settimana in oggetto.
Ad esempio, il report settimanale (weekly report) dell’ultima settimana di gennaio prende il nome “PDI_subprojects_weekly_reporting_06cw04”.
Il titolo del file segue questa logica:
• PDI Î indica il progetto di appartenenza (Piezo Direct Injection) • subprojects Î indica l’area di interesse all’interno del progetto • weekly_reporting Î indica l’oggetto di riferimento
• 06cw04 Î indica il periodo temporale d’interesse. 06 è l’anno, cw04 indica la
current week numero quattro, secondo l’indicizzazione riportata nella videata del
Con questa codifica è possibile reperire immediatamente il file della settimana corrente, senza perdere informazioni passate.
In caso di status Late prolungato, il project manager convoca il Team Leader per capire ed organizzare le contromisure necessarie a riportare il sub-project in tempo.
In certi casi è possibile che vengano attribuite ulteriori risorse, in altri si tratta di accorgimenti tecnici o organizzativi.
In ogni caso questo strumento fornisce un valido ausilio al project manager per la gestione delle attività volte a recuperare le deviazioni occorse in fasi critiche del progetto come, in questo caso, i problemi emersi durante la Design Validation.
