Modelo de dados de rastreamento de defeitos

Visão geral

Obter a arquitetura de dados correta é fundamental para conduzir as ações certas para melhorar seu processo. Os dados nunca são únicos, pois os problemas que estão sendo resolvidos raramente são idênticos. Este Functional Example descreve os principais dados recomendados para o rastreamento de defeitos. Sinta-se à vontade para adicionar mais Fields para ampliar este Exemplo Funcional.

O documento Estendendo o conceito aborda algumas maneiras pelas quais esse modelo de dados pode ser desenvolvido para gerar ainda mais valor.

Tabelas

Este aplicativo depende de tabelas para o armazenamento de dados. Isso é recomendado (em vez de usar conclusões) porque significa que essa mesma tabela pode ser usada em vários aplicativos, uma característica essencial de Composability, especialmente se esse rastreamento de defeitos existir em vários aplicativos.

Este aplicativo depende de uma única tabela [Defect Events].

Estender o conceito abrange algumas oportunidades para estender esse modelo de dados, incluindo uma interconectividade mais ampla com o rastreamento de pedidos ou outros casos de uso.

Tabela [Defect Events] (Eventos de defeito)

A tabela Defect Events é a base necessária para gerar visibilidade em seu processo. Alguns campos de registro da tabela são opcionais e outros são realmente necessários para manter a visibilidade de suas operações.

Lembre-se de que esses campos não precisam necessariamente ser preenchidos por uma pessoa. As informações do pedido podem vir de uma fonte de dados externa ou ser inferidas com base na lógica condicional.

Ex. A descrição do defeito é calculada automaticamente pela combinação da variável Material e da variável Reason com a Expressão:

'Defected ' + @Variable.Material + ' due to ' + @Variable.Reason

Tabela Fields

ID (Texto) - Todas as tabelas precisam de uma coluna ID para representar exclusivamente cada registro da tabela. Neste caso de uso, estamos usando uma cadeia de caracteres aleatória como ID do registro.

Description (Texto) - Uma descrição legível por humanos do defeito. No Functional Example, ela seguirá o formato "Defected Material due to Reason" ( Material com defeito devido à razão)

Data do relatório (Datetime) - A hora em que o defeito foi originalmente relatado.

Reported By (User) - O usuário que relatou o defeito. No exemplo funcional, isso é preenchido com o usuário conectado, mas pode ser definido como um usuário estático ou permitir que os usuários selecionem um relator.

ID do material (Texto) - A ID do material em que o defeito foi encontrado. Substituir esse campo por um registro vinculado à tabela [Materials] seria uma ótima maneira de ampliar o conceito.

Quantity (Number) (Quantidade (Número)) - Como o nome indica, essa é a quantidade de peças defeituosas.

Motivo (Texto) - Assim como o campo Status, o campo Motivo pode ser aproveitado para encaminhar defeitos para a equipe correta automaticamente.

Ex. Todos os defeitos de excesso de estoque devem ser tratados pelos gerentes de produção

Assignee (User) - O usuário que é responsável pela disposição do defeito. Pode ser definido dinamicamente com base no Motivo ou estaticamente para um único usuário/equipe.

Status (Texto) - O estado atual desse defeito. Quando o defeito for relatado no {{glossário.Exemplo Funcional}}, o padrão será NOVO. Em nosso caso de uso, os defeitos passam por 3 status: 1. NOVO 2. EM REVISÃO 3. FECHADO

Comments (Text) (Comentários (Texto)) - Um campo de texto de forma livre onde podem ser coletadas quaisquer observações sobre o defeito. Aproveite esse campo como parte da análise de causa raiz. Combinado com o widget Digital Record History, é possível ver os dados históricos de cada defeito.

Foto (Imagem)- Colete uma foto do defeito. As imagens podem ser aproveitadas para entender melhor a causa raiz.

Closed Date (Datetime)- Quando um defeito é resolvido, esse campo pode rastrear a data em que o relatório de defeito foi fechado. Aproveite esse campo no Analytics para entender o acúmulo de relatórios de defeitos abertos existentes.

Local detectado (Texto)- Classifique os defeitos pelo local onde foram identificados pela primeira vez. Use esse campo para gerar insights sobre os pontos de falha mais comuns em seu processo. Além disso, esse campo pode ser aproveitado para que o defeito seja atribuído ao responsável correto.

Next Stes (Texto) - Acompanha a resolução do defeito, quando combinado com o Widget Digital Record History. os usuários do Widget podem ver como um defeito foi resolvido.