Modelo de datos de seguimiento de defectos

Visión general

Disponer de una arquitectura de datos adecuada es fundamental para impulsar las acciones correctas que mejoren su proceso. Los datos nunca son de talla única porque los problemas que se resuelven rara vez son idénticos. Este Functional Example describe los datos básicos recomendados para el seguimiento de defectos. No dude en añadir más Field para ampliar este Ejemplo Funcional.

El documento Extendiendo el Concepto describe algunas formas en las que este modelo de datos puede ser construido para generar aún más valor.

Tablas

Esta aplicación se basa en Tablas para el almacenamiento de datos. Esto se recomienda (sobre el uso de Completions) porque significa que esta misma tabla se puede utilizar a través de múltiples aplicaciones, una característica crítica de Composability, especialmente si este seguimiento de defectos existe a través de múltiples aplicaciones.

Esta aplicación se basa en una única tabla [Defect Events].

Extend the Concept cubre algunas oportunidades para extender este modelo de datos, incluyendo una interconectividad más extensa con Order Tracking, u otros casos de uso.

Tabla [Defect Events]

La tabla [Defect Events] es la base necesaria para dar visibilidad a su proceso. Algunos campos de registro de la tabla son opcionales, y otros son realmente necesarios para mantener la visibilidad de sus operaciones.

Tenga en cuenta que estos campos no necesariamente deben ser rellenados por una persona. La información del pedido puede proceder de una fuente de datos externa, o inferirse basándose en una lógica condicional.

Ej. La Descripción del defecto se calcula automáticamente combinando la variable Material y la variable Razón con la Expresión:

'Defectuoso ' + @Variable.Material + ' debido a ' + @Variable.Reason

Tabla Fields

ID (Texto)- Todas las tablas necesitan una columna ID para representar unívocamente cada Registro de Tabla. En este caso utilizaremos una cadena aleatoria como ID del registro.

Descripción (Texto) - Una descripción legible del defecto. En el Functional Example seguirá el formato " Material defectuoso debido a un motivo".

ReportedDate (Datetime) - La hora en que se notificó originalmente el defecto.

Reportado por (Usuario) - El usuario que reportó el defecto. En el ejemplo funcional, este campo se rellena con el usuario registrado, pero podría establecerse con un usuario estático, o permitir a los usuarios seleccionar un informador.

IDMaterial (Texto) - ID del material donde se encontró el defecto. Sustituir este campo por un registro vinculado a la tabla [Materiales ] sería una buena forma de ampliar el concepto.

Cantidad (Número)- Como su nombre indica, es la cantidad de piezas defectuosas.

Razón (Texto) - Al igual que el campo Estado, el campo Razón puede utilizarse para enviar defectos al equipo correcto de forma automática.

Ej. Todos los defectos por exceso de inventario deben ser gestionados por los responsables de producción.

Asignado (Usuario) - El usuario responsable de la disposición del defecto. Puede establecerse dinámicamente en función del motivo o estáticamente a un único usuario/equipo.

Estado (Texto) - Estado actual del defecto. Cuando el defecto es reportado en el {{glosario.Ejemplo Funcional}} este será por defecto NUEVO. En nuestro caso de uso, los defectos se mueven a través de 3 estados: 1. NUEVO NUEVO 2. EN REVISIÓN 3. CERRADO

Comentarios (Texto) - Un campo de texto libre donde cualquier nota sobre el defecto puede ser recogida. Aproveche este campo como parte del análisis de la causa raíz. Combinado con el widget Digital Record History, puede ver los datos históricos en torno a cada defecto.

Foto (Imagen)- Recopile una foto del defecto. Las imágenes pueden aprovecharse para comprender mejor la causa raíz.

Fecha de cierre (fecha y hora)- Cuando se resuelve un defecto, este campo puede rastrear la fecha en que se cerró el informe de defectos. Aproveche este campo en Analytics para comprender la acumulación de informes de defectos abiertos existentes.

Ubicación detectada (texto): clasifique los defectos por la ubicación en la que se identificaron por primera vez. Utilice este campo para obtener información sobre los puntos de fallo más comunes en su proceso. Además, este campo se puede aprovechar para asignar el defecto a la persona correcta.

Next Stes (Text) - Seguimiento de la resolución del defecto, cuando se combina con el Digital Record History los usuarios pueden ver cómo se ha abordado un defecto.