|
I problemi relativi ai prodotti e i punti da risolvere nella documentazione che descrive il prodotto fisico possono essere acquisiti in Windchill PDMLink creando un report di problema o una richiesta di modifica. Il fatto che venga utilizzato un report di problema o che il processo di modifica venga avviato con la creazione di una richiesta di modifica dipende dalla struttura e dal processo di modifica dell'organizzazione.
Il diagramma di seguito riportato mostra come il processo di modifica di Windchill PDMLink sia in linea con il processo di modifica standard CMII. È ora possibile passare a una descrizione dettagliata del processo.
Processo di modifica a circolo chiuso CMII - Report di problema |
Lo scopo del report di problema è quello di rilevare e descrivere un problema relativo a un prodotto o suggerire una miglioria per il prodotto da qualsiasi origine coinvolta nel processo di sviluppo del prodotto stesso. Il report di problema quindi fornisce informazioni pertinenti sul problema o sul punto da risolvere, ad esempio una breve descrizione, l'iniziatore e la priorità. Al report di problema è anche possibile aggiungere degli allegati allo scopo di razionalizzare la raccolta delle informazioni, in modo che nei pacchetti siano inclusi l'elemento interessato (dati di sistema), il prodotto finale interessato (prodotto indipendente) e gli eventuali allegati (dati esterni).
Una volta reso persistente nel database, il report di problema ha come stato Aperto, il che significa che è stato creato ma non è stato inviato al processo di modifica. Dopo essere stato inviato al processo, il report di problema ha come stato In esame.
Quando viene creato, il report di problema viene assegnato a un prodotto. L'esaminatore iniziale è l'Amm modifiche I assegnato al prodotto identificato nel report di problema. Tale amministratore deve confermare se il report di problema è valido. Gli esiti possibili sono tre:
- Conferma del report di problema e invio per la creazione della richiesta di modifica
- Rifiuto del report di problema perché inappropriato
- Rifiuto del report di problema perché è un duplicato di un report già esistente
Se il report di problema viene confermato, gli viene assegnato lo stato Accettato. Se invece il report di problema è un duplicato o viene rifiutato, gli viene assegnato lo stato Definito. Quando un report di problema viene risolto mediante chiusura, l'autore riceve una notifica con la motivazione appropriata.
La figura di seguito riportata mostra la finestra in cui un report di problema viene visualizzato all'Amm modifiche I. La sezione evidenziata è un link diretto al report di problema effettivo, a cui è possibile accedere facendo appunto clic sul link.
Finestra Analizza report di problema |
Dopo essere stato analizzato e completato, il report di problema viene instradato in base alle disposizioni previste. Un report di problema confermato diventa una richiesta di modifica. L'obiettivo della richiesta di modifica è quello di descrivere nei dettagli un difetto del prodotto o una miglioria proposta, in modo che si possa prendere una decisione a livello aziendale. Sono due i quesiti di base a cui è necessario dare una risposta:
- Se esiste una motivazione aziendale per implementare la modifica
- In caso di accettazione della modifica, se è oppurtuno scegliere il procedimento abbreviato o quello intero
Nel grafico di flusso sopra riportato viene mostrato il processo di creazione della richiesta di modifica. Infatti, per poter creare la richiesta di modifica, non deve necessariamente esistere un report di problema. L'autore della richiesta di modifica può fornire informazioni aggiuntive per confermare l'esistenza di un problema o fornire informazioni a supporto dell'analisi del problema con relative proposte. L'autore può anche collaborare con degli esaminatori tecnici per convalidare e valutare l'impatto. Dopo essere stata salvata, la richiesta di modifica ha come stato Aperto e può essere inviata al passaggio successivo del processo di modifica.
L'Amm modifiche I riceve la richiesta di modifica creata o aggiornata, ne esamina il contenuto e l'analisi, quindi risponde ai due quesiti dell'elenco puntato sopra riportato. La figura seguente è un esempio della finestra in cui la richiesta di notifica viene visualizzata all'Amm modifiche I. Notare le opzioni di instradamento nella parte inferiore della finestra Analizza Richiesta di modifica e le decisioni su come procedere prese dall'Amm modifiche I dopo aver esaminato la richiesta di modifica. Questi aspetti verranno esaminati nella pagina successiva.
Finestra Analizza Richiesta di modifica |
|
