Обзор
Правильная архитектура данных имеет решающее значение для принятия правильных мер по совершенствованию процессов. Данные никогда не бывают универсальными, поскольку решаемые проблемы редко бывают одинаковыми. В этом 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. Виджет позволяет пользователям увидеть, как был устранен дефект.
.gif)