Модель данных для отслеживания дефектов

Обзор

Правильная архитектура данных имеет решающее значение для принятия правильных мер по совершенствованию процессов. Данные никогда не бывают универсальными, поскольку решаемые проблемы редко бывают одинаковыми. В этом Functional Example описаны основные данные, рекомендуемые для отслеживания дефектов. Не стесняйтесь добавлять другие Field, чтобы расширить этот функциональный пример.

В документе "Расширение концепции " рассматриваются некоторые способы построения этой модели данных для получения еще большей ценности.

Таблицы

В данном приложении для хранения данных используются таблицы. Это рекомендуется (вместо использования завершений), поскольку одна и та же таблица может использоваться в нескольких приложениях, что является критической характеристикой Composability, особенно если отслеживание дефектов ведется в нескольких приложениях.

Данное приложение опирается на одну таблицу [Defect Events].

В разделе "Расширение концепции " рассматриваются некоторые возможности расширения этой модели данных, включая более широкое взаимодействие с системой отслеживания заказов или другие варианты использования.

Таблица [Defect Events] Table

Таблица Defect Events представляет собой "голые кости", необходимые для обеспечения наглядности процесса. Некоторые поля записи таблицы являются необязательными, а другие действительно необходимы для обеспечения наглядности операций.

Следует помнить, что эти поля не обязательно должны заполняться человеком. Информация о заказе может быть получена из внешнего источника данных или выведена на основе условной логики.

Например. Описание дефекта автоматически вычисляется путем объединения переменной Material и переменной Reason с выражением:

'Дефект ' + @Variable.Material + ' из-за ' + @Variable.Reason

Таблица Field

ID (Text)- Всем таблицам необходим столбец ID для уникального представления каждой записи таблицы. В данном случае в качестве идентификатора записи используется случайная строка.

Описание (Текст) - человекочитаемое описание дефекта. В Functional Example это описание будет иметь формат "Дефект материала по причине".

Reported Date (Datetime) - Время первоначального сообщения о дефекте.

Reported By (User) - Пользователь, сообщивший о дефекте. В функциональном примере этот параметр заполняется именем Logged in User, но его можно установить на статического пользователя или позволить пользователям выбирать автора отчета.

Material ID (Text) - идентификатор материала, в котором был обнаружен дефект. Замена этого поля на связанную запись с таблицей [Materials] была бы отличным способом расширить концепцию.

Количество (Число)- Как следует из названия, это количество дефектных деталей.

Причина (Текст) - Как и поле Статус, поле Причина может быть использовано для автоматического направления дефектов в нужную группу.

Например. Все дефекты, связанные с избыточными запасами, должны обрабатываться менеджерами производства.

Assignee (User) - Пользователь, ответственный за устранение дефекта. Он может быть динамически установлен на основе причины или статически для одного пользователя/команды.

Статус (Текст) - текущее состояние данного дефекта. Когда о дефекте сообщается в Functional Example, по умолчанию будет установлено значение NEW. В нашем случае дефекты проходят через три статуса: 1. NEW 2. НА РАССМОТРЕНИИ 3. CLOSED

Comments (Text) - текстовое поле произвольной формы, в котором могут быть собраны любые заметки о дефекте. Используйте это поле как часть анализа первопричин. В сочетании с виджетом Digital Record History можно просмотреть исторические данные по каждому дефекту.

Photo (Image) - сбор фотографии дефекта. Изображения могут быть использованы для лучшего понимания причин дефекта.

Closed Date (Datetime)- Когда дефект устранен, в этом поле можно отследить дату закрытия отчета о дефекте. Используйте это поле в аналитике, чтобы понять, сколько еще осталось открытых отчетов о дефектах.

Место обнаружения (Текст)- Сортировка дефектов по месту, где они были впервые обнаружены. Используйте это поле для получения информации о наиболее распространенных точках сбоя в вашем процессе. Кроме того, это поле может быть использовано для назначения дефекта правильному назначенному лицу.

Next Stes (Text) - отслеживание решения по дефекту, в сочетании с Digital Record History. Виджет позволяет пользователям увидеть, как был устранен дефект.