Gestione delle modifiche di progettazione in fase avanzata

Gestire modifiche di progettazione in qualsiasi fase del ciclo di progettazione è una realtà inevitabile per i produttori. Una chiara specifica di progettazione concordata, basata su ricerche di mercato affidabili, requisiti dei clienti e metodologie di progettazione tecnica, consente di evitare numerosi errori che potrebbero richiedere modifiche di progettazione. Anche i progetti più promettenti e meglio concepiti, tuttavia, possono richiedere modifiche per una vasta gamma di motivi nell’intero ciclo di progettazione. Un fatto è certo. L’implementazione di modifiche al modello diventa sempre più costosa e invasiva quanto più avanzata è la fase del ciclo di progettazione in cui viene eseguita. Apportare una modifica dopo l’introduzione di un prodotto sul mercato può avere conseguenze ancora più gravi, quali costosi richiami del prodotto, possibili controversie legali con i consumatori e perdita di fiducia tra i clienti. Il danno al marchio causato da un richiamo di vaste proporzioni nel 2010 è costato a Toyota una perdita di vendite stimata pari a 770 e 880 milioni di dollari. Il costo in termini di perdita di fiducia tra i consumatori è difficile da quantificare, ma è probabilmente altrettanto significativo. Nonostante la variazione delle stime in relazione alla quantificazione delle spese dell’implementazione di modifiche, una regola empirica piuttosto semplice è che il costo dell’implementazione di modifiche di progettazione aumenta di dieci volte in ciascuna fase del processo di progettazione. Una modifica che potrebbe costare 10 dollari se apportata durante la fase concettuale iniziale, pertanto, nel momento in cui il modello raggiunge la fase di produzione potrebbe costare 100.000 dollari. Ciò è noto ai produttori. Purtroppo, gli errori accadono. La domanda diventa quindi: qual è il modo ottimale per gestire le inevitabili modifiche in fasi successive del ciclo di progettazione?  Perché adesso? È una domanda comune quando sono necessarie modifiche di progettazione in fase avanzata. Talvolta sono richieste per soddisfare mutevoli esigenze dei clienti. In altri casi possono essere causate da metodologie produttive specifiche del sito. Potrebbero essere necessarie modifiche quando si verifica un cambiamento nel materiale o nel metodo di produzione, che potrebbe essere causato dalla mancata disponibilità del materiale, da difficoltà nel reperimento di un componente specifico o dal cambiamento di un fornitore. Tali circostanze sono spesso il risultato di processi disgiunti all’interno dell’organizzazione, che non sono in grado di tenere i membri del team informati dei cambiamenti nei requisiti del prodotto o nei parametri di progettazione basati sulla produzione. Mentre i team di progettazione devono concentrarsi sul progetto, i team a monte e a valle devono fornire continuamente dati sui requisiti del prodotto ai progettisti. Quando è necessaria una modifica, è essenziale che tutti i membri del team comunichino apertamente e collaborino per trovare la soluzione appropriata. L’implementazione di una modifica al progetto influisce spesso sui processi a valle, pertanto è necessario che ingegneri e progettisti identifichino in modo realistico l’impatto della modifica su pianificazioni e stime dei costi e comunichino con le parti interessate dalla modifica.  Flessibilità Nonostante una specifica di progettazione ben scritta consenta di evitare alcune modifiche di progettazione, può anche determinare mancanza di flessibilità e di reattività quando le modifiche sono necessarie. Le aziende devono aggiungere continui punti di contatto con i clienti affinché possano testare i concetti, i prototipi e le funzionalità dei prodotti nel corso del ciclo di sviluppo e di lancio. Gli studi hanno dimostrato che ciò può abbreviare i tempi di ciclo addirittura del 30% e ridurre i costi di sviluppo addirittura del 40% rispetto al più tradizionale approccio di progettazione definito in gate con un rigoroso rispetto delle specifiche di progettazione sviluppate nelle prime fasi del ciclo di progettazione. Queste metodologie di progettazione lean, tuttavia, si rivelano inadeguate nello stadio iniziale del processo. La maggiore efficienza dello sviluppo prodotto lean dipende comunque in larga misura (come il modello definito in gate) dalla stabilizzazione iniziale dei requisiti, anziché iterare, ottimizzare e individuare compromessi per i requisiti al fine di ottenere la progettazione vincente. Indipendentemente dal livello di innovazione, pertanto, questo approccio tende a salvaguardare lo status quo anziché essere creativo, esponendo le aziende al rischio di modifiche invasive in un secondo momento sul mercato.  Ne consegue che la maggiore globalizzazione ha creato un panorama sempre più competitivo per i produttori. L’ambiente di sviluppo prodotto è diventato troppo mutevole per un rigido processo standardizzato. Ingegneri e progettisti, così come il resto del team di progettazione, devono essere flessibili, aperti e pronti a gestire le inevitabili modifiche necessarie nell’intero processo per risolvere rapidamente i problemi e rispettare comunque i tempi previsti per i prodotti con interruzioni minime.

Questo articolo è stato pubblicato in Progettazione rivoluzionata e ha le etichette , , , , , . Aggiungi ai preferiti: link permanente. I trackbacks sono chiusi ma puoi scrivi un commento.

Pubblica un Commento

Il tuo indirizzo Email non verra' mai pubblicato e/o condiviso. I campi obbligatori sono contrassegnati con *

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Puoi usare questi HTML tag e attributi: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>