|
Les problèmes relatifs au produit et ceux liés à la documentation décrivant ce produit peuvent être capturés dans Windchill PDMLink par la création d'un rapport de problème (PR) ou d'une demande de modification (ECR). Un processus et une structure de modification d'une organisation déterminent si un rapport de problème est utilisé ou si la création d'une demande de modification a généré un processus de modification.
Le diagramme ci-dessous illustre comment le processus de modification Windchill PDMLink s'aligne sur le processus de modification CMII standard Windchill. Etudions les étapes du processus.
Processus de modification CMII en boucle fermée -- Rapport de problème |
L'objectif du rapport de problème est de capturer et de décrire un problème relatif au produit ou de suggérer un moyen d'améliorer ce produit grâce à une source quelconque impliquée dans le processus de développement du produit. Les rapports de problèmes capturent des informations pertinentes concernant le problème (une brève description, l'initialisateur ou la priorité, par exemple). Il est possible d'attacher des pièces jointes au rapport de problème pour améliorer la collecte et le conditionnement des informations, telles que l'élément affecté (données système), le produit fini affecté (produit seul) et les pièces jointes (données externes).
Une fois que le rapport de problème est stocké dans la base de données, son état est Ouvert. Cela signifie qu'il a été créé mais qu'il n'a pas été soumis au processus de modification. Lorsque le rapport de problème est soumis au processus de modification, son état est En cours de validation.
Lorsqu'un rapport de problème est créé, il est affecté à un produit. Le validateur initial est l'Administrateur de modification I (CAI) affecté au produit identifié par le rapport de problème. Celui-ci confirme la validité du rapport de problème. Il existe trois résultats possibles :
- Confirmation du rapport de problème et envoi pour création d'une demande de modification.
- Rejet du rapport de problème pour des raisons d'inadéquation de l'idée.
- Rejet du rapport de problème car il en existe un doublon.
Si le rapport de problème est confirmé, il prend l'état Accepté. Si le rapport de problème est un doublon ou s'il est rejeté, il prend l'état Résolu. L'auteur d'un rapport de problème résolu par fermeture reçoit une notification justifiant cette fermeture..
L'illustration suivante représente les informations du rapport de problème telles que l'Administrateur de modification I les voit. La section mise en évidence correspond à un lien direct vers le rapport de problème réel. Pour y accéder, il suffit de cliquer sur le lien.
Fenêtre d'analyse du rapport de problème |
Une fois l'analyse du rapport de problème terminée, celui-ci est acheminé en fonction de l'instruction donnée. Un rapport de problème confirmé devient une demande de modification (ECR). L'objectif de la demande de modification est de décrire une défaillance du produit ou de proposer, en détail, des améliorations à apporter, de façon à ce qu'une décision commerciale puisse être prise. Pour poursuivre, il est impératif de répondre aux deux questions suivantes :
- La mise en oeuvre de cette modification est-elle justifiée d'un point de vue commercial ?
- Si elle est acceptée, s'agira-t-il d'une modification simple ou complexe ?
L'illustration précédente représentait le processus de création d'une demande de modification. Il n'est pas nécessaire de créer un rapport de problème pour créer une demande de modification. L'auteur de la demande de modification a la possibilité de fournir des informations supplémentaires pour valider le problème ou modifier l'analyse avec les propositions correspondantes. Il peut également collaborer avec les validateurs techniques pour valider ces modifications et y accéder. Une fois la demande de modification enregistrée, son état passe à Ouvert. Elle peut être soumise à l'étape suivante du processus de modification.
L'Administrateur de modification I reçoit la demande de modification créée et mise à jour, valide le contenu et l'analyse, puis répond aux deux questions précédemment posées. L'illustration suivante représente un exemple d'affichage d'une demande de modification tel que l'Administrateur de modification I le voit. Les différentes possibilités d'acheminement figurent au bas de la fenêtre d'analyse d'une demande de modification et les décisions requises par l'Administrateur de modification I se situent au-dessus des informations concernant la validation de la demande de modification. Nous approfondirons cette analyse à la page suivante.
Fenêtre d'analyse d'une demande de modification |
|
