otif-analysis

OTIF Analysis

Most "delivery problems" are measurement problems first. Before recommending any operational fix, establish what the honest number is and which definition choices inflate the reported one.

Required data

Order-level rows with: order_id, requested_delivery_date (what the customer asked for), promised_delivery_date (what was confirmed), actual_delivery_date, completeness info (lines ordered vs delivered, or qty ordered vs delivered), and a status/cancelled flag. Useful cuts: carrier, region, customer, product family.

If requested_delivery_date is missing, say so explicitly: only the promised-date rungs are computable, and the analysis cannot see sales-padding. Recommend capturing the requested date going forward.

Workflow

1. Validate before computing. Count duplicated order rows; flag impossible dates (actual before order date); count cancelled orders and state how they will be treated. Report these counts in the output - an audit that silently cleans data is not an audit.
2. Compute the metric ladder on the same population, strictest last:
   • L1: on-time vs promised date, with the tolerance window currently in use (ask what it is; if unknown, show +3 days and label it)
   • L2: on-time vs promised, zero tolerance
   • L3: on-time vs requested, zero tolerance
   • L4: OTIF = on-time vs requested AND order complete (all lines / full qty). In-full is judged at order level - a 9-of-10-lines delivery is not 90% on-time, it is one incomplete order
   • L5: OTIF with cancelled orders kept in the denominator Present the ladder as a table with the delta and the cause of each drop (tolerance, padding, partials, cancellations).
3. Decompose the gap. For the dimension with the largest spread (try carrier, region, month, customer, product family), show OTIF per segment. Name the concentrated driver, not just the average.
4. Analyze the tail, not the mean. Average lateness hides the distribution. Report the share of orders 4+ days late and the worst decile - those are the orders customers remember.
5. Reconcile before reporting. Recompute the headline OTIF once more directly from raw rows (single pass, no intermediate tables) and confirm it matches. If it does not, stop and find out why.

Pitfalls to check explicitly

• Anchor choice: promised-date metrics hide sales padding. Compute average (promised - requested) days; if > 0.5, quantify its KPI effect.
• Tolerance windows are policy, not truth. Show the tolerance-sensitivity curve if the tolerance is contested.
• Cancelled orders quietly leaving the denominator flatter the metric.
• Line-level averaging overstates performance versus order-level in-full.

Output format

1. The ladder table (definition, result %, delta, cause)
2. Three finding sentences, each: what moved / where it concentrates / what decision it needs
3. A definitions footnote stating anchor date, tolerance, in-full rule and cancellation treatment - so the number cannot be misread

Worked example with charts and synthetic data: https://github.com/gulmezeren2-byte/otif-analytics

---

Source: industrial-engineering-ai-skills by Eren Gulmez (MIT). The full method pack - entry skill, role agents, data-hygiene rules and artifact templates - lives there.