Order Tracking Data Model

Overview

Getting the data architecture right is critical to driving the right actions to improve your process. Data is never one-size-fits-all because the problems being solved are seldom identical. This Functional Example outlines the core minimum data model recommended for Order Tracking.

Orders at a fundamental level are simple. They have a set of Attributes, and a set of inputs. The [Orders] table is where order 'metadata' is stored.

The Extending the Concept document goes into some ways this data model could be built on top of to drive even more value.

Tables

This application relies on Tables for data storage. This is recommended (over using Completions) because it means this same Table can be used across multiple apps, a critical characteristic of Composability.

This Application relies on a single [Orders] table.

Extend the Concept covers how this table could be combined with Linked Record to the [Materials] table to track dependent materials.

[Orders] Table

The Orders table is the bare bones needed to drive visibility into your process. Some Table Record Fields are optional, and others really are required to maintain visibility into your operations.

Keep in mind, these fields don't necessarily need to be populated by a person. Order information could come from an external datasource, or be inferred based on conditional logic.

ex. At the beginning of an order in this Functional Example the order status is set to OPEN

Required Fields

ID (Text)- All tables need an ID column to uniquely represent each Table Record. In this use case we are using the order number as the ID.

Material Number (Text) - The material number for this use case is the part number (or SKU) this order is producing. Because this isn't the ID field, multiple Records (orders) can share a single Material Number.

Target Quantity (Number) - The number of units required to complete the order.

Status (Text) - The current state of this order. In our use case, orders move through 6 statuses:

1. NEW
2. RELEASED
3. IN-PROGRESS
4. COMPLETE
5. ON-HOLD
6. CANCELLED

Due Date (Datetime) - Without a target date, prioritizing work can be a sizable challenge.

Optional Fields

Material Description (Text)- Any semantic information that might help your operators better understand what they are making.

For example - I don't know what PN-24136 is, but the Material description is "3/16x2" bolt", so I can act on the order

Material Photo (Image)- An optional photo of the final product to be produced.

Final Quantity (Number)- As the name implies, this is the final quantity of parts. The intention is this field could be used for a final part count by a quality department or shipping department before the order is shipped.

Unit of Measurement (Text) - What is the unit to describe the material being produced? This field can be leveraged to inform if they are to make 15oz of product or 15 tons of product.

Type (Text) - This is a higher-level categorization for the order that could be used to group orders.

ex. We always run printing jobs earlier in the week so the machines don't need to be cleaned twice, so all printing orders are given the PRINTING type so they can be prioritized first.

Scheduled Manufacture Date (Datetime) - When should this order be started to insure it can be delivered on time?

Manufacture Date (Datetime) - When did manufacturing actually start?

Complete Date (Datetime) - When was the order completed?

Current Location (Text) - The current location of the order. Incredibly useful in larger facilities to insure finished goods can be found.

Materials (Linked Record) - Materials is a Linked Record field to the [Materials] Table. This field is intended to link materials required to complete this order to the parent order.

This is also where the BOM for your assembly can be stored.

Customer (Text) - This field is a place to store customer names, customer IDs, etc.