Modèle de données pour le suivi des défauts

Vue d'ensemble

Il est essentiel d'avoir une bonne architecture de données pour mener les bonnes actions afin d'améliorer votre processus. Les données ne sont jamais universelles car les problèmes à résoudre sont rarement identiques. Ce {{glossary.Functional Example}} présente les données de base recommandées pour le suivi des défauts. N'hésitez pas à ajouter d'autres {{glossary.Field}} pour étendre cet exemple fonctionnel.

Le document " Extending the Concept " explique comment ce modèle de données peut être développé pour créer encore plus de valeur.

Tableaux

Cette application s'appuie sur des tableaux pour le stockage des données. Cela est recommandé (plutôt que d'utiliser des compléments) car cela signifie que la même table peut être utilisée dans plusieurs applications, une caractéristique essentielle de {{glossary.Composability}}, surtout si le suivi des défauts existe dans plusieurs applications.

Cette application s'appuie sur une seule table [Defect Events].

L'extension du concept couvre certaines possibilités d'extension de ce modèle de données, y compris une interconnexion plus étendue avec le suivi des commandes, ou d'autres cas d'utilisation.

Tableau [Événements défectueux

La table des événements défectueux est l'élément de base nécessaire pour assurer la visibilité de votre processus. Certains champs d'enregistrement de la table sont facultatifs, tandis que d'autres sont vraiment nécessaires pour maintenir la visibilité de vos opérations.

Gardez à l'esprit que ces champs ne doivent pas nécessairement être remplis par une personne. Les informations relatives aux commandes peuvent provenir d'une source de données externe ou être déduites sur la base d'une logique conditionnelle.

ex. La description du défaut est automatiquement calculée en combinant la variable Matériau et la variable Raison avec l'expression :

'Défaut ' + @Variable.Material + ' dû à ' + @Variable.Reason

Table {{glossary.Field}}s

ID (Texte)- Toutes les tables ont besoin d'une colonne ID pour représenter de manière unique chaque enregistrement de la table. Dans ce cas d'utilisation, nous utilisons une chaîne aléatoire comme ID d'enregistrement.

Description (Texte) - Une description du défaut lisible par l'homme. Dans l'exemple {{glossary.Functional}}, elle suivra le format " Matériel défectueux en raison de la raison".

Date de signalement ( Datetime) - L'heure à laquelle le défaut a été initialement signalé.

Reported By (User) - L'utilisateur qui a signalé le défaut. Dans l'exemple fonctionnel, il s'agit de l'utilisateur connecté, mais il peut être défini comme un utilisateur statique ou permettre aux utilisateurs de sélectionner un rapporteur.

ID matériel (texte) - ID du matériel où le défaut a été constaté. Remplacer ce champ par un enregistrement lié à la table [Matériaux] serait un excellent moyen d' étendre le concept.

Quantité (Nombre)- Comme son nom l'indique, il s'agit de la quantité de pièces défectueuses.

Raison (Texte) - Tout comme le champ Statut, le champ Raison peut être utilisé pour acheminer automatiquement les défauts vers la bonne équipe.

ex. Tous les défauts de stock excédentaire doivent être traités par les responsables de la production.

Assignee (User) - L'utilisateur qui est responsable du traitement du défaut. Il peut être défini dynamiquement en fonction de la raison, ou statiquement pour un seul utilisateur/équipe.

Statut (Texte) - L'état actuel de ce défaut. Lorsque le défaut est signalé dans le {{glossary.Functional Example}}, le statut par défaut est NEW. Dans notre cas d'utilisation, les défauts passent par 3 statuts : 1. NOUVEAU 2. EN REVUE 3. CLOSED

Comments (Text) - Champ de texte libre dans lequel peuvent être recueillies toutes les notes concernant le défaut. Exploitez ce champ dans le cadre de l'analyse des causes profondes. Combiné avec le widget {{glossary.Digital Record History}}, vous pouvez voir les données historiques relatives à chaque défaut.

Photo (Image)- Collectez une photo du défaut. Les images peuvent être exploitées pour mieux comprendre la cause première.

Date de clôture (Datetime)- Lorsqu'un défaut est résolu, ce champ permet de suivre la date de clôture du rapport de défaut. Exploitez ce champ dans Analytics pour comprendre l'arriéré des rapports de défauts ouverts existants.

Lieu de détection (texte) : triez les défauts en fonction du lieu où ils ont été identifiés pour la première fois. Utilisez ce champ pour obtenir des informations sur les points de défaillance les plus courants de votre processus. En outre, ce champ peut être exploité pour que le défaut soit attribué au bon attributaire.

Next Stes (Texte) - Suivi de la résolution du défaut. Combiné au widget {{glossary.Digital Record History}}, il permet aux utilisateurs de voir comment un défaut a été résolu. Widget, les utilisateurs peuvent voir comment un défaut a été traité.