Order visibility & analytics

An order passes through many systems: the order lands in the ERP, the warehouse system handles picking, the transport system handles the truck, the carrier tracks delivery, and finance handles the invoice. When a customer asks “where’s my order?”, someone often has to check four screens and call two people.

Order visibility joins those steps into one timeline per order: received, credit released, allocated, picked, shipped, in transit, delivered, invoiced. Each step has a planned time and an actual time, so delays are visible as they happen.

Order analytics then does three useful things:

• Monitor: live counts of orders by status, and which ones are stuck, such as on credit hold for over a day, allocated but not picked, or picked but missing the truck.
• Predict: a model using order type, customer, warehouse workload, product availability and carrier performance can flag orders likely to miss their date while there’s still time to act.
• Explain: for every late or incomplete order, a reason code (stock not available, picking error, missed truck, carrier delay, customer not available). Adding them up shows where the biggest failures come from, which is usually a handful of causes.

The aim is to fix the few causes behind most failures, and to answer customers before they have to ask.

One timeline per order

Each system records events: order created (ERP), credit released (ERP), allocated (ERP), wave released and picked (WMS), loaded and shipped (WMS, TMS), carrier scans (carrier), delivered with proof (carrier), invoiced (ERP). Joining them needs common identifiers (order, delivery and shipment numbers) and the planned time for each milestone, so every step can be compared with its plan as it happens.

Investigating an OTIF drop

Predicting late orders

A model can score each open order’s risk of being late from features such as order type, customer, items and their stock, warehouse workload, carrier and lane performance, and time remaining. Judge it with two numbers:

• Precision: of the orders it flags, how many really would have been late?
• Recall: of the orders that end up late, how many did it flag in time?

If the model flags 200 orders a week, 120 of which would have been late, precision is 60%. If 160 orders would have been late in total, recall is 75%. Raising the threshold improves precision but misses more late orders; the right balance depends on how much an intervention costs compared with a late order.

Process mining

Process mining reconstructs how orders actually flow from system event logs, rather than how the process is documented. It reveals the real variants: orders that loop back through credit checks, deliveries changed after picking, invoices corrected twice. Van der Aalst (2016) describes the methods. For order management, it typically shows that a small number of variants and rework loops explain most delays and cost.

Keeping reason codes honest

Reason codes are only as good as the people and systems that set them:

• Standard list: a short, mutually exclusive list with clear definitions, the same across sites.
• Automatic where possible: derive the reason from system data (stock was zero at allocation; the truck left before the order was loaded) rather than relying on manual entries.
• Independence: the person who caused a delay shouldn’t be the only one choosing its reason.
• Watch “other”: if it grows beyond a small share, the list or the discipline needs fixing.

Proactive updates

Customers contact service mainly when they are uncertain. Sending a proactive message when an order ships, when the delivery window is set and when a delay is predicted reduces “where is my order?” contacts, and turns a late delivery from a surprise into a managed event. Visibility is most valuable when it reaches the customer before they ask.

The data plumbing

• Common identifiers across ERP, WMS, TMS and carrier data, maintained when orders are split or combined.
• Timestamps in one time zone with clear definitions (when exactly is an order “shipped”?).
• Latency: carrier updates that arrive hours late limit how early problems can be seen.
• Master data: planned lead times and cut-off times must be right for planned-versus-actual comparisons to mean anything.

From analytics to improvement

The aim is to change the process: fix the few causes behind most failures, then re-measure. A quarterly cycle of “Pareto of reasons, root-cause projects, re-measure” usually does more for OTIF than any dashboard.