Capitolo 6 - Analisi di un approccio innovativo: Mitigation of Obsolescence Cost Analysis (MOCA).
6.3 Flusso logico alla base del MOCA6.
L'analisi realizzata dal tool MOCA viene condotta attraverso i passi e il flusso logico mostrati nella figura successiva.
Figura 6.3: Flusso logico secondo cui è strutturato il tool MOCA.
Per capire meglio come il tool effettivamente opera, sarà meglio analizzare nel dettaglio i vari step.
- Genera una lista di azioni: combina tutti gli eventi possibili come produzione, design refresh prefissati e obsolescenza dei singoli componenti su una timeline simile a quella mostrata nel Par. 6.1.
- Determina il costo in caso di nessun design refresh: determina il life cycle cost nel caso in cui non vengano effettuati design refresh addizionali; questo risultato servirà come baseline per le successive analisi del tool. In questo caso, viene ipotizzato che i componenti obsoleti siano disponibili presso stock esistenti grazie a lifetime buy o da fonti after-market, a seconda di come è stato specificato in input.
- Sceglie un piano di design refresh: un set di azioni di design refresh viene scelto per essere analizzato.
- Modifica la lista di azioni: la lista di azioni originale viene modificata includendo il pianoro design refresh candidato all'analisi.
- Sintetizza nuove parti quando un componente viene sostituito durante un design refresh, con un dispositivo il cui ciclo
di vita potrebbe non essere ancora noto: al fine di minimizzare i costi nell'intero ciclo di vita del sistema, infatti, il
MOCA cerca di prevedere la data di obsolescenza di questi ultimi, basandosi sul ciclo di vita dei componenti che utilizzano
la stessa tecnologia di base del dispositivo usato per la sostituzione.
Per meglio spiegare il meccanismo di quest' operazione, riporto un esempio molto frequente nella letteratura sull'argomento7.
Supponiamo di dover prevedere la data di obsolescenza di un logic divice, per il quale l'attributo primario8 è rappresentato
dalla logic family di appartenenza.
La previsione parte dal considerare i cicli di vita dei componenti appartenenti alla device class del componente di cui vogliamo
la data di obsolescenza e che presentano diversi valori dell'attributo primario.
Nella figura successiva, come esempio di questo, sono mostrati i cicli di vita di alcune logic families suddivisi nelle diverse tipiche fasi.
Figura 6.4: Cicli di vita di alcune logic families.
Partendo da questi dati, si diagrammano le date di introduzione e di phase-out in funzione della data in cui si è verificato il picco di vendita; tali punti vengono poi interpolati con due rette delle quali si ricava, poi, l'espressione analitica. Il risultato che si ottiene è riportato nell'immagine seguente.
Figura 6.5: Date di introduzione e phase-out in funzione dell'anno del picco di vendita per alcune logic families.
La presunta data di obsolescenza per il componente che si va a sostituire è data dalla seguente espressione:
In cui i termini hanno il seguente significato:
- B = Anno in cui si prevede si sostituire la parte ;
- L = Lifespan del componente;
Nell'esempio L = .
- i = Indice di obsolescenza della parte sostituita, che corrisponde alla fase del ciclo di vita in cui quest'ultimo si trova ( per esempio: 2= introduzione; 3= maturità; 5= phase-out).
- Determina il costo del design refresh candidato.
- Classifica i piani di design refresh in base ai risultati economici: in seguito alla valutazione economica i paini di design refresh considerati vengono classificati in base al costo e in più cost effective viene scelto.
I tool Price H/HL vengono usati sia nella valutazione dei singoli piani di design refresh, sia nella stima finale del life
cycle cost del sistema una volta che è stato scelto il piano finale di design refresh.
- 6: P. Sandborn, P. Singh, Electronic part obsolescence driven product redesign optimization, 6° Joint FAA/DoD/NASA Aging Aircraft Conference, 16-19 settembre 2002.
- 7: P. Sandborn, P. Singh,. Electronic part obsolescence driven product redesign planning, IJAMS International Journal of Advanced Manufacturing Systems, Volume 7, Issue 2, 2004.
- 8: Per la definizione e la spiegazione di cosa sia un attributo primario di un componente e l'appartenenza ad una device class rimando al cap. 5, par 5.2.