Modello di dati per il monitoraggio dei difetti

Panoramica

Un'architettura dei dati corretta è fondamentale per guidare le azioni giuste per migliorare i processi. I dati non sono mai uguali per tutti, perché i problemi da risolvere sono raramente identici. Questo {{glossario.Esempiofunzionale}} delinea i dati fondamentali consigliati per il monitoraggio dei difetti. Sentitevi liberi di aggiungere altri {{glossario.campi}} per estendere questo esempio funzionale.

Il documento Estensione del concetto analizza alcuni modi in cui questo modello di dati potrebbe essere integrato per ottenere ancora più valore.

Tabelle

Questa applicazione si basa sulle tabelle per la memorizzazione dei dati. Questa scelta è consigliata (rispetto all'uso dei Completamenti) perché significa che la stessa tabella può essere usata in più applicazioni, una caratteristica critica di {{glossario.Compostabilità}}, soprattutto se il tracciamento dei difetti è presente in più applicazioni.

Questa applicazione si basa su una singola tabella [Eventi difettosi].

L'estensione del concetto copre alcune opportunità per estendere questo modello di dati, tra cui un'interconnessione più estesa con il monitoraggio degli ordini o altri casi d'uso.

Tabella [Eventi difettosi

La tabella Defect Events è l'ossatura necessaria per ottenere la visibilità del processo. Alcuni campi dei record della tabella sono opzionali, mentre altri sono necessari per mantenere la visibilità delle operazioni.

Tenete presente che questi campi non devono necessariamente essere popolati da una persona. Le informazioni sull'ordine possono provenire da una fonte di dati esterna o essere dedotte in base a una logica condizionale.

es. La Descrizione del difetto viene calcolata automaticamente combinando la variabile Materiale e la variabile Motivo con l'Espressione:

'Difetto ' + @Variabile.Materiale + ' a causa di ' + @Variabile.Motivo

Tabella Fields

ID (Testo) - Tutte le tabelle hanno bisogno di una colonna ID per rappresentare in modo univoco ogni record della tabella. In questo caso si utilizza una stringa casuale come ID del record.

Descrizione (Testo) - Una descrizione del difetto leggibile dall'uomo. Nell'esempio {{glossario.funzionale}} questa seguirà il formato " Materiale difettoso a causa di un motivo".

Data segnalazione (Datetime) - L'ora in cui il difetto è stato originariamente segnalato.

Segnalato da (Utente) - L'utente che ha segnalato il difetto. Nell'esempio funzionale, questo è popolato con l'utente registrato, ma potrebbe essere impostato su un utente statico o consentire agli utenti di selezionare un segnalatore.

ID materiale (testo) - L'ID del materiale in cui è stato riscontrato il difetto. La sostituzione di questo campo con un record collegato alla tabella [Materiali] sarebbe un ottimo modo per estendere il concetto.

Quantità (Numero) - Come suggerisce il nome, si tratta della quantità di parti difettose.

Motivo (Testo) - Come il campo Stato, il campo Motivo può essere sfruttato per indirizzare automaticamente i difetti al team corretto.

es. Tutti i difetti in eccesso di magazzino devono essere gestiti dai responsabili della produzione.

Destinatario (Utente) - L'utente responsabile della gestione del difetto. Può essere impostato dinamicamente in base al motivo o staticamente su un singolo utente/team.

Stato (Testo) - Lo stato attuale di questo difetto. Quando il difetto viene segnalato nel {{glossario.Esempio funzionale}}, questo sarà impostato come NUOVO. Nel nostro caso d'uso, i difetti si muovono attraverso 3 stati: 1. NUOVO NUOVO 2. IN REVISIONE 3. CHIUSO

Commenti (testo) - Un campo di testo a forma libera in cui è possibile raccogliere qualsiasi nota sul difetto. Sfruttare questo campo come parte dell'analisi delle cause. In combinazione con il widget Digital Record History, è possibile visualizzare i dati storici relativi a ciascun difetto.

Foto (immagine) - Raccogliere una foto del difetto. Le immagini possono essere sfruttate per comprendere meglio la causa principale.

Data di chiusura (Datetime) - Quando un difetto viene risolto, questo campo può tracciare la data di chiusura del rapporto sul difetto. Questo campo può essere utilizzato in Analytics per comprendere l'arretrato di segnalazioni di difetti aperti.

Luogo rilevato (testo) - Ordina i difetti in base al luogo in cui sono stati identificati per la prima volta. Utilizzate questo campo per ottenere informazioni sui punti di errore più comuni del vostro processo. Inoltre, questo campo può essere sfruttato per assegnare il difetto al corretto assegnatario.

Prossime fasi (testo) - Traccia la risoluzione del difetto; se combinato con il widget Digital Record History, gli utenti possono vedere come un difetto è stato risolto. Gli utenti del widget possono vedere come è stato affrontato un difetto.