Oltre la Lean Production: il Lean Product Development

Pagina 2 di 2

La gestione del bilanciamento del carico di lavoro in un approccio Ce/Sbce deve essere attentamente valutata, per tendere, come in produzione, a un bilanciamento livellato del carico di lavoro per facilitare lo scorrere del flusso di valore.

• Chief Engineer. È un ruolo aziendale che assume importanza significativa all’interno di un processo di sviluppo nuovo prodotto che vuole tendere alla massima efficienza. Nell’esperienza Toyota, è una figura altamente tecnica che cerca di capire al massimo il consumatore, sviscerandone i più nascosti desideri e diventandone la “voce” in azienda, fissando gli obiettivi progettuali, oltre che i target di valore e di performance. Non è un mero program/product manager, ma è un decisore fondamentale, che parte dall’elaborazione del concept di prodotto e governa l’intero progetto di sviluppo. In letteratura, è stato spesso definito “super ingegnere”, personaggio chiave per il processo innovativo.

Nella fase di sviluppo, il valore è rappresentato dalla conoscenza che viene generata e impiegata utilmente. Poter gestire la conoscenza – ad esempio in termini di identificazione delle giuste informazioni da utilizzare in un dato processo e di corretta diffusione all’interno del team – corrisponde a realizzare un processo di maggior valore. Sono diverse le metodologie e le tecniche che aiutano nella condivisione (sharing) e recupero (retrieval) e della conoscenza, come ad esempio:

• Quality Function Deployment (Qfd), detto anche House of Quality: è una matrice che mappa i requisiti del cliente (pesati in termini di importanza per il cliente stesso) rispetto a un elenco di attributi di prodotto (attributi tecnici che guidano le performance del prodotto). È uno strumento che supporta la progettazione in modo strutturato, basandosi sulle reali necessità ed esigenze del cliente, convertendo la “voce del consumatore” in un insieme di caratteristiche che l’organizzazione può utilizzare per riconoscere e ordinare le proprie priorità e per aiutarsi nel processo decisionale. L’evidenza empirica dimostra come l’uso di tale matrice comporti risultati positivi in termini di time-to-market, riduzione di costi del prodotto e di soddisfazione delle esigenze dei clienti;
• Regole di Design for X (Dfx), costituisce un’ampia collezione di linee guida da utilizzare durante la fase di progettazione. Le linee guida stesse sono una forma esplicita di conoscenza da utilizzare per controllare, migliorare e intervenire sulle caratteristiche di un prodotto. Le regole di Dfx “obbligano” i progettisti a considerare (e ottimizzare) una serie di aspetti/elementi riguardanti le diverse fasi della vita di un prodotto, come la sua produzione/assemblaggio (Design for Manufacturing/Assembly), la manutenzione e l’assistenza che dovrà subire (Design for Maintainability/Serviceability), il suo smaltimento (Design for Dissassembly/for Recyclability), come anche alcune prestazioni salienti, come la qualità (Design for Quality) o l’impatto ambientale (Design for Environment);
• Tra le regole di progettazione, occorre citare anche il metodo Poka-yoke, letteralmente “a prova d’errore”. È una tecnica, nata in Toyota, che mira a ottenere un processo privo di parti difettose generate, eliminando in questo modo la necessità del controllo qualità. Con tale scelta progettuale si cerca di porre dei limiti al modo in cui un’operazione può essere condotta, forzando l’utilizzatore a una corretta esecuzione della stessa. Lo scopo è appunto quello di evitare (yokeru) gli errori di distrazione (poka), spingendo gli operatori a focalizzarsi su quelle attività che creano valore piuttosto che dedicarsi al monitoraggio.
• I progettisti, nel proprio compito di trovare soluzioni a problemi, sviluppano conoscenza, lungo un ciclo (personale e di gruppo) di apprendimento. Seguendo la ruota Pdca di Deming, è possibile strutturare il processo di apprendimento di un team di progetto, secondo i passi Lambda:  Look, controlla ogni azione, processo o informazione in prima persona; Ask, cerca di arrivare alla causa-radice del problema; Model, usa simulazioni o prototipi;  Discuss, comunica con i colleghi (progettisti, manager, ecc.); (v) Act, testa sperimentalmente il tuo sapere;
• Il processo così strutturato deve essere opportunamente documentato. Toyota ha sviluppato il metodo standard dell’A3 Sheet (Foglio A3). Fisicamente, ogni progetto è documentato tramite un report breve (per l’appunto un foglio A3, di dimensioni 297 cm per 420 cm), allo scopo di restituire una sintesi di un problema presentato in maniera visiva, che può essere usato per favorire uno scambio di conoscenza e informazioni. Un solo foglio A3 risulta più efficace di un lungo report descrittivo in cui i punti salienti rischiano spesso di essere persi a causa della grande mole di informazioni contenute. L’aspetto innovativo e interessante di tale strumento è non tanto il formato A3, quanto la rappresentazione delle informazioni in tale modo visivo e condensato;
• Per agevolare la comunicazione intra-team e anche intra-progetti, è possibile ricorrere a un’Obeya Room, fisicamente una stanza interamente dedicata alla rappresentazione visiva dell’avanzamento dei progetti, contenente al suo interno fogli A3 e altri tipi di visualizzazione. Tra questi possono poi essere costruite delle matrici, che intersecano le responsabilità individuali dei progettisiti con gli intervalli di tempo, originando scadenze univocamente associate a ogni persona, trascritte su semplici post-it. Diverse esperienze industriali hanno dimostrato come questo tipo di visualizzazione aiuti a condividere le informazioni e a trovare le soluzioni ai problemi, creando consapevolezza su che particolari azioni verranno eseguite e da chi.

Un ulteriore ambito da considerare è dato dall’introduzione e utilizzo delle tecnologie informatiche a supporto dello sviluppo prodotti. Negli ultimi anni, le tecnologie Cax (Computer Aided X) hanno registrato evoluzioni importanti, mettendo a disposizione delle imprese strumenti di progettazione dall’elevato rendering grafico e avanzate capacità di modelling e testing, con cui realizzare sofisticati prototipi virtuali. Ad esempio, i moderni Cad (Computer Aided Design) tridimensionali forniscono l’abilità di modellare innumerevoli tipi di geometrie, includendo relazioni parametriche che facilitano di molto il lavoro dei progettisti, mentre gli strumenti CAM (Computer Aided Manufacturing), analizzando il modello geometrico tridimensionale creato col CAD, generano i linguaggi macchina in maniera sicura e certa, favorendo l’introduzione di un processo produttivo che sia efficace e veloce. Sono inoltre oggigiorno disponibili numerose piattaforme di collaborazione (indicate come Pdm/Plm – Product Data/Lifecycle Management) che supportano i progettisti nelle attività di recupero della conoscenza pregressa (ad esempio da precedenti progetti/prodotti) e di accumulo della conoscenza in sviluppo. L’esperienza industriale insegna che l’insieme di questi strumenti Ict (Information and Communication Technology) permette di fare ordine ed efficienza lungo il processo di sviluppo, riducendo sensibilmente il time-to-market e migliorando spesso anche la stessa qualità di progetto.

I muda nello sviluppo nuovo prodotto

Il lean thinking (anche nella sua particolare accezione di lean product development) non va però confuso con le sue tecniche: implementare una o alcune delle metodologie sopra citate, non è sufficiente a ottenere un processo lean. Il punto di forza è saperle adottare in maniera integrata e coerente come elementi di un unico e compatto insieme. Il lean è una vera e propria filosofia, un modo di pensare, sempre: chi punta a sviluppare un ambiente lean deve rendersi conto che ogni miglioramento di efficienza comincia fin dall’inizio di un prodotto. Infatti, nella fase di sviluppo si manifestano già i primi muda, che – se non risolti prontamente – si diffondono e propagano inesorabilmente lungo tutto il ciclo di vita di un prodotto.
Come avvenne per la produzione, per cui prima Ohno e poi Womack e Jones ne classificarono gli sprechi, così è stato fatto anche per la progettazione, in cui i muda assumono una declinazione un po’ differente, vista la diversa natura dell’oggetto del flusso di valore. Il senso è sempre quello di distinguere le attività che aggiungono valore per il cliente, da quelle che, al contrario, non lo fanno. Rielaborando il primo lavoro di Liker, le principali categorie di muda nella progettazione sono qui di seguito descritte:

1. Over-production/Over-engineering: progettare in eccesso oppure in anticipo rispetto alle aspettative del progetto stesso. È uno spreco molto comune laddove i processi di sviluppo non sono sincronizzati tra le funzioni aziendali e tra i diversi attori coinvolti nel progetto;
2. Waiting: attese per mancanza di informazioni o decisioni fondamentali e necessarie per proseguire il proprio lavoro. I progettisti si trovano molto spesso bloccati da una lacuna e/o mancanza informativa, magari dovuta a una specifica incompleta o poco chiara fornita da un’altra funzione aziendale;
3. Transportation: trasferimento di informazioni da un sistema all’altro. Ancora oggi, i diversi sistemi Ict che supportano la progettazione sono spesso difficilmente compatibili e diverse ore vengono spese per la sola transcodifica dei diversi formati file (es. formati file Cad).
4. Processing (Over/Inappropriate Processing): si ha quando si compiono azioni non necessarie durante lo svolgimento di un particolare task, oppure si esegue un task non necessario. Ad esempio, non sono rari i casi di progetti condotti partendo da informazioni (ad esempio specifiche) errate e/o incomplete, che devono essere successivamente rivisti alla luce di un aggiornamento/correzione delle fonti originarie;
5. Inventory: accumulazione di eccessive informazioni non utilizzate o che restano in coda a lungo in attesa di essere processate. Caso tipico in cui studi o documenti vecchi rimangono inutilizzati, dopo aver consumato molte ore rilevanti nelle attività di progettazione;
6. Defects and Corrections: correggere errori commessi in fase di progettazione e individuare problemi di qualità sul prodotto. È uno spreco anche realizzare un prodotto non di successo, che non soddisfa tutte le richieste del cliente, o che le soddisfa in maniera adeguata (di fatto un prodotto progettato male);
7. Motion: eccesso di attività eseguite durante un determinato task, come ad esempio report ridondanti, meeting e review di progetto non necessari;
8. Underutilized people’s abilities: mancato utilizzo delle capacità delle persone, insufficiente condivisione di conoscenza tra gli ingegneri, incapacità di creare motivazione o cattiva comunicazione con i fornitori. La progettazione è un processo creativo, cognitivo, che mira a essere innovativo. Ogni mancanza nello sviluppo di queste caratteristiche è uno spreco: disporre di ingegneri non motivati che autolimitano la propria capacità propositiva corrisponde a buttar via preziose risorse non creando valore per il cliente.

La classificazione sopra riportata è, gioco-forza, generica. Comunque, come diversi studi empirici attualmente in corso rivelano, gli sprechi sopra definiti sono rintracciabili nella stragrande maggioranza delle imprese. Ad esempio, la Figura 2 riporta i risultati di una recente indagine in una decina di imprese italiane, circa l’esistenza e la rintracciabilità dei muda negli uffici tecnici.

Fatto 100 l’insieme degli sprechi rintracciabili in progettazione, oltre il 30% è dato da sprechi per un processo inappropriato, ridondante e pieno di errori di comunicazione.

Conclusione

Anche dal semplice studio qui sopra riportato, emerge chiaro ciò che era evidente fin dall’introduzione teorica: la progettazione è un processo complesso, in cui è facile accumulare inefficienze. Queste, se ignorate, non possono che ripercuotesi a valle, lungo l’intero ciclo di vita del prodotto. L’insieme delle metodologie (organizzative, procedurali, tecnologiche) che compongono il variegato mondo del lean aiutano a risolvere buona parte di tali inefficienze, permettendo la costituzione di un processo di sviluppo più pulito, con meno sprechi e a maggior valore aggiunto. Come comporre tale insieme di metodologie è ancora – almeno in buona parte – oggetto di studio, come dimostrano le diverse fonti disponibili in letteratura (ad esempio Liker) e le diverse società di consulenza che stanno operando sull’argomento. Anche gli autori stanno attualmente lavorando, nell’ambito del progetto europeo LeanPpd (www.leanppd.eu), ad un modello complessivo, cui un’azienda potrà in futuro agevolmente rifarsi per definire il proprio percorso di lean product develoment.