Defect Tracking - Extend the Concept

Overview

Functional Examples arent intended to perfectly fit any one process or facility, but rather to act as a starting point in building your own order tracking apps.

This guide is intended to give you some ideas on how this functional example could be changed and adapted to your process, along with ways it could be combined with other fantastic Tulip use cases.

Extend the Apps

Split Apps by Job Function

As we talked about in the App Architecture guide one of the simpliest ways to get value with Tulip is by making apps specific for the users who will be interfacting with them.

In most processes, operators will be reporting Defects, but a seperate team will be doing the root cause analysis, taking corrective action, and completing the audit resolution. Seperating this into a seperate app will streamline the operator interface and allow increased controls around user access.

Modify the User Interface

Adoption of a new process is always a challenge in manufacturing, but intuitive apps will always be easier to get buy-in for. Adjust the Functional example to better suit the needs of your users.

• Determine which [Defect Events] Table Record Fields you want users entering, vs. those that can be automated.
  • In the Functional Example the description field is automatically generated, but it might make more sense for your users to be able to write a custom note.
• Modify defect routing so users only see defects that apply to them. This filtering could happen on the Next Steps field, Reason field, Assignee field, or any other key differentiator for your process.
• Add 'quick action' buttons to automate common workflows. Maybe your quality department has standard resolutions to specific defects. These resolutions can be added to buttons that auto-populate the respective table fields.

Extend the Data Model

Each process is unique, and these differences in process almost always mandate some additional data is added to the default data model.

As the app builder, you know best where the Common Data Model doesn't match your process, but here are so examples of ways the model could be extended.

Linked Tables

Linked Records allow you to associate one Record with another. This means your [Defect Events] table doesn't need the details of the material that was found to be defective, it can instead just reference the linked record in the [Materials] table.

[Materials] Table

The Materials table is intended to be used to track materials, their associated orders, defects, and more. One material can have muliple defects.

This associated allow you to track defects by material, and leverage the information about each material in the Materials table, while working with its defects.

Add Table Fields

The [Defect Events] table is a good starting point to track the important data around your defects, but probably doesn't include every field important for your process. Maybe you want to also track:

• Sunk cost in defective goods (Cost-Of-Goods could come from the Linked [Materials] table.
• Linked Record to the associated [Orders] record.

Add Tables

There are dozens of different great uses for Tulip, adding more processes might mandate adding more Tulip Tables.

• And-On Tracking
• Quality Events
• Inspections
• Equipment
• Shipping/Reciving Orders

Any/all of these Tables can be built and incorportated into a core Defect
Tracking use case. Because of the flexible nature of Tables, these new Tables can also be managed by dedicated apps.