Gestione della modifica dei prodotti

I prodotti evolvono nel tempo man mano che migliora la qualità, i requisiti di mercato cambiano e idee innovative vengono incorporate nei prodotti esistenti. Le modifiche informali possono essere adottate facilmente nelle prime fasi del ciclo di vita di un prodotto prima del rilascio. Tuttavia, quando le progettazioni maturano e vengono prodotte, è necessario utilizzare un processo più formale man mano che la pianificazione delle modifiche diventa più complessa e i costi aumentano.

Windchill facilita i processi di modifica sia informali che formali. Il processo di modifica formale è univoco per ogni società. Tuttavia esistono molte best practice condivise da tutte le società. Windchill include un processo di modifica formale che acquisisce le best practice comuni.

Il processo Windchill standard è costituito da cinque passi di base descritti nel diagramma seguente. Ogni passo è gestito da un workflow automatizzato. Fare clic sulla casella del diagramma di flusso per visualizzare direttamente una descrizione del passo del processo di base.

• Passo 1 - Identificazione del problema: un problema può essere qualsiasi errore o guasto segnalato o miglioramento suggerito relativo a una progettazione. Solitamente viene acquisito in un report di problema. Il problema viene analizzato, discusso e convalidato prima del passaggio al passo successivo. L'utilizzo dei report di problema è facoltativo. I problemi possono venire documentati anche con richieste di modifica e notifiche di modifica.

• Passo 2 - Richiesta di modifica: uno o più problemi convalidati vengono gestiti con una richiesta di modifica. Le richieste di modifica danno inizio al processo di modifica e acquisiscono tutti i dati pertinenti e l'analisi, tra cui la motivazione tecnica e aziendale per effettuare la modifica.

A seconda della complessità della modifica viene utilizzato un processo di modifica semplice o affidabile. È possibile trasmettere le richieste di modifica tramite un workflow semplificato, definito processo di procedimento abbreviato, quando le modifiche da effettuare non interessano gli ordini, la produzione o i riadattamenti delle unità implementate. Un processo più affidabile, detto procedimento intero, viene utilizzato quando la modifica è complicata, costosa o di ampio ambito. La società dispone di linee guida univoche per determinare il procedimento da adottare.

• Passo 3 - Pianificazione della modifica: quando si accetta una modifica da implementare, è necessario pianificare il lavoro di documentazione e implementazione della modifica. Una notifica di modifica registra il piano di implementazione. Il piano include task separati associati ai dati di prodotto da modificare. Viene proposta una programmazione e vengono fatte delle raccomandazioni per la disposizione dell'inventario di prodotti esistente. L'implementazione viene attivata dal workflow quando viene approvato il piano.

• Passo 4 - Implementazione modifiche: i task di modifica vengono distribuiti ai responsabili dell'aggiornamento della documentazione del prodotto e dell'acquisizione di nuove configurazioni di prodotto. Le nuove configurazioni di prodotto vengono rilasciate e passano alla fase di produzione quando inizia l'implementazione fisica.

• Passo 5 - Implementazione fisica: le modifiche vengono incorporate nella produzione e le parti nuove e modificate vengono ispezionate per garantire che siano conformi ai requisiti di progettazione. Le soluzioni temporanee delle specifiche di prodotto vengono gestite con un processo di deviazione/deroga.

I quattro oggetti di modifica di base descritti sopra vengono collegati insieme per fornire una cronologia completa del processo di modifica. La rete degli oggetti di modifica e delle relative relazioni è illustrata nel diagramma seguente. Si noti che la rete degli oggetti di modifica viene creata a partire dal report di problema, nella parte superiore sinistra, per poi passare al task di modifica nella parte inferiore destra. La rete degli oggetti di modifica si risolve nell'ordine inverso, a partire dal completamento dei task di modifica per finire con il report di problema nella parte superiore sinistra.

È possibile creare una richiesta di modifica a partire della pagina delle informazioni di una parte o un documento o da un report di problema esistente. Quando la richiesta di modifica viene creata dal report di problema, i due oggetti di modifica vengono automaticamente correlati tra loro. I dati interessati possono essere copiati dal report di problema nella richiesta di modifica. Con una richiesta di modifica è possibile gestire più report di problema.

Quando la richiesta di modifica viene accettata dalla commissione d'esame delle modifiche per l'implementazione, un utente crea la notifica di modifica a partire dalla richiesta di modifica, correlando automaticamente i due oggetti. La notifica di modifica è costituita da uno o più task di modifica richiesti dal piano di implementazione, che vanno ancora una volta ad aggiungersi alla rete degli oggetti di modifica. Ogni oggetto di modifica dispone di un workflow pronto all'uso che termina con il completamento. I workflow separati sono collegati insieme in modo che il completamento dei task in un workflow attivi l'inizio dei task in quello successivo. Il workflow chiude il ciclo del processo man mano che vengono completate le modifiche, modificando lo stato del ciclo di vita degli oggetti di modifica e inviando notifiche alle parti interessate.

Nel diagramma riportato sopra è illustrato il processo di modifica completo con tutti gli oggetti di modifica a partire dal report di problema. È possibile abbreviare il processo iniziando con una richiesta di modifica o una notifica di modifica.