Datenmodell für die Fehlerverfolgung

Überblick

Die richtige Datenarchitektur ist entscheidend, um die richtigen Maßnahmen zur Verbesserung Ihrer Prozesse zu ergreifen. Daten sind nie eine Einheitsgröße, da die zu lösenden Probleme selten identisch sind. Dieses Functional Example umreißt die für die Fehlerverfolgung empfohlenen Kerndaten. Sie können gerne weitere Fields hinzufügen, um dieses Funktionsbeispiel zu erweitern.

Das Dokument " Extending the Concept " geht auf einige Möglichkeiten ein, wie dieses Datenmodell erweitert werden kann, um noch mehr Wert zu schaffen.

Tabellen

Diese Anwendung stützt sich auf Tabellen zur Datenspeicherung. Dies wird empfohlen (im Gegensatz zur Verwendung von Completions), weil es bedeutet, dass dieselbe Tabelle in mehreren Anwendungen verwendet werden kann, ein entscheidendes Merkmal der Composability, insbesondere wenn diese Fehlerverfolgung in mehreren Anwendungen existiert.

Diese Anwendung stützt sich auf eine einzige [Defect Events] -Tabelle.

Extend the Concept deckt einige Möglichkeiten zur Erweiterung dieses Datenmodells ab, einschließlich einer umfassenderen Interkonnektivität mit der Auftragsverfolgung oder anderen Anwendungsfällen.

Tabelle [Defect Events]

Die Tabelle "Defect Events" ist das Grundgerüst, das für die Transparenz Ihres Prozesses benötigt wird. Einige Felder des Tabellendatensatzes sind optional, andere sind für die Transparenz Ihrer Vorgänge unbedingt erforderlich.

Beachten Sie, dass diese Felder nicht unbedingt von einer Person ausgefüllt werden müssen. Auftragsinformationen können aus einer externen Datenquelle stammen oder auf der Grundlage einer bedingten Logik abgeleitet werden.

Beispiel. Die Fehlerbeschreibung wird automatisch berechnet, indem die Variablen " Material" und " Grund" mit der Expression kombiniert werden:

'Defekt ' + @Variable.Material + ' aufgrund von ' + @Variable.Grund

Tabelle Fields

ID (Text)- Alle Tabellen benötigen eine ID-Spalte, um jeden Tabellendatensatz eindeutig zu kennzeichnen. In diesem Anwendungsfall wird eine zufällige Zeichenfolge als Datensatz-ID verwendet.

Beschreibung (Text) - Eine von Menschen lesbare Beschreibung des Fehlers. Im Functional Example hat dies das Format "Defected Material due to Reason".

Reported Date (Datetime) - Der Zeitpunkt, zu dem der Fehler ursprünglich gemeldet wurde.

Reported By (User) - Der Benutzer, der den Defekt gemeldet hat. Im Funktionsbeispiel wird dies mit dem angemeldeten Benutzer ausgefüllt, kann aber auch auf einen statischen Benutzer gesetzt werden oder den Benutzern die Möglichkeit geben, einen Berichterstatter auszuwählen.

Material-ID (Text) - Die ID des Materials, in dem der Fehler gefunden wurde. Das Ersetzen dieses Feldes durch einen verknüpften Datensatz mit der Tabelle [Materialien] wäre eine gute Möglichkeit, das Konzept zu erweitern.

Menge (Zahl)- Wie der Name schon sagt, ist dies die Menge der fehlerhaften Teile.

Grund (Text) - Ähnlich wie das Feld " Status" kann das Feld "Grund" genutzt werden, um Defekte automatisch an das richtige Team weiterzuleiten.

Beispiel. Alle Überbestandsfehler sollten von den Produktionsmanagern bearbeitet werden.

Zugewiesener (Benutzer) - Der Benutzer, der für die Bearbeitung des Defekts verantwortlich ist. Dies kann dynamisch auf der Grundlage des Grundes oder statisch auf einen einzelnen Benutzer/Team festgelegt werden.

Status (Text) - Der aktuelle Status dieses Fehlers. Wenn der Defekt im Functional Example gemeldet wird, wird dieser Status auf NEW gesetzt. In unserem Anwendungsfall durchlaufen die Defekte 3 Status: 1. NEU 2. IN ÜBERPRÜFUNG 3. GESCHLOSSEN

Comments (Text) - Ein Freiform-Textfeld, in dem Notizen zum Defekt erfasst werden können. Nutzen Sie dieses Feld als Teil der Ursachenanalyse. In Kombination mit dem Widget Digital Record History können Sie die historischen Daten zu jedem Defekt einsehen.

Foto (Bild) - Erfassen Sie ein Foto des Defekts. Bilder können genutzt werden, um die Ursache besser zu verstehen.

Closed Date (Datetime)- Wenn ein Defekt behoben ist, kann dieses Feld das Datum nachverfolgen, an dem der Defektbericht geschlossen wurde. Nutzen Sie dieses Feld in Analytics, um den Rückstand bei bestehenden offenen Fehlerberichten zu verstehen.

Erkennungsort (Text) - Sortieren Sie Defekte nach dem Ort, an dem sie zuerst erkannt wurden. Nutzen Sie dieses Feld, um Erkenntnisse über die häufigsten Fehlerpunkte in Ihrem Prozess zu gewinnen. Außerdem kann dieses Feld genutzt werden, um den Fehler dem richtigen Empfänger zuzuordnen.

Next Stes (Text) - Verfolgen Sie die Lösung des Defekts. In Kombination mit dem Digital Record History Widget können Benutzer sehen, wie ein Defekt behandelt wurde.