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

Vue d'ensemble

Il est essentiel de bien définir l'architecture des données pour mener les bonnes actions afin d'améliorer votre processus. Les données ne sont jamais uniformes, car les problèmes à résoudre sont rarement identiques. Cet {{glossaire.Exemple fonctionnel}} décrit les données de base recommandées pour le suivi des défauts. N'hésitez pas à ajouter d'autres {{glossaire.Champs}} pour étendre cet exemple fonctionnel.

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

Tables

Cette application s'appuie sur des tables pour le stockage des données. Cela est recommandé (plutôt que d'utiliser des complétions) car cela signifie que cette même table peut être utilisée dans plusieurs applications, une caractéristique critique de Composability, en particulier si ce 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 interconnectivité plus étendue avec le suivi des commandes, ou d'autres cas d'utilisation.

Tableau [Événements défectueux

La table [Événements liés à des défauts] est la base nécessaire pour assurer la visibilité de votre processus. Certains champs d'enregistrement de la table sont facultatifs, tandis que d'autres sont indispensables pour assurer 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 à la commande 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 les variables Material et Reason avec l'expression :

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

Table Fields

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 identifiant de l'enregistrement.

Description (Texte) - Une description lisible par l'homme du défaut. Dans l'exemple fonctionnel Functional Example, cette description suivra le format " Matériau défectueux en raison d'un motif"

Date de signalement (Datetime) - Date à laquelle le défaut a été signalé à l'origine.

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

ID de l'article (texte) - L'ID de l'article dans lequel 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.

Motif (Texte) - Tout comme le champ Statut, le champ Motif peut être utilisé pour acheminer automatiquement les défauts vers l'équipe appropriée.

Par exemple. Tous les défauts liés aux stocks excédentaires doivent être traités par les responsables de la production.

Assigné (utilisateur) - L'utilisateur qui est responsable du traitement du défaut. Il peut être défini de manière dynamique en fonction de la raison, ou de manière statique pour un seul utilisateur ou une seule équipe.

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

Commentaires (Texte) - Un champ de texte libre dans lequel des notes sur le défaut peuvent être collectées. Ce champ peut être utilisé dans le cadre de l'analyse des causes profondes. Combiné avec le widget Digital Record History, vous pouvez voir les données historiques relatives à chaque défaut.

Photo (Image)- Recueillez 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 utilisé pour affecter le défaut au bon destinataire.

Prochaines étapes (texte) - Suivi de la résolution du défaut. Combiné au widget Digital Record History, il permet aux utilisateurs de voir comment un défaut a été résolu. les utilisateurs peuvent voir comment un défaut a été traité.