Module

OTIF Post-Mortem

Why the deliveries that missed, missed — with the order numbers, not a recollection.

In build — not switched on₹25,000 / month
See pricing

What it produces

  • A waterfall decomposing the OTIF gap into named causes, by value
  • Every missed line with its cause and the record that proves it
  • The share of missed value nothing on file explains, stated plainly
  • Lines that could not be assessed at all, and what is missing

A worked example

June — OTIF 87.4%, and where the 12.6 points went
supplier late · 5.1 points · ₹18,40,000 · 7 lines
promised inside lead time · 3.2 points · ₹11,60,000 · 4 lines
short shipped · 1.8 points · ₹6,50,000 · 11 lines
unexplained · 2.5 points · ₹9,00,000 · 6 lines — 20% of the miss

Illustrative figures. On your tenant the same page shows yours.

Why it is hard

The part that is not a report.

OTIF reported as a single percentage hides which half went wrong, and the two halves have different causes: late is usually planning or transport, short is usually stock or quality. Splitting them is the easy part. The harder part is the post-mortem — tracing each miss back to the stage that caused it, with the order numbers attached — because without that the monthly meeting argues about whose recollection is right rather than about what to change. A number nobody can trace is a number everybody can dispute.

Opened by the supply chain manager, the logistics manager and the planner — what each of them sees first.

Said before you ask

What is not finished.

COMING_SOON. The engine is built and tested — 47 tests, 15 mutants, all killed — and it decomposes a period's OTIF into causes that each point at a record, refusing to name one where nothing on file supports it. What is missing is three of the six causes on live data. Stock at a past date cannot be reconstructed from the current inventory row, realised lead times are not yet wired through from supplier history, and outbound shipments are not joined to delivery lines — so PROMISE_INSIDE_LEAD_TIME, STOCK_NOT_AVAILABLE and CARRIER_LATE cannot fire against a real tenant yet. The engine handles all three and the golden dataset covers them; the queries that would feed them do not exist. Releasing now would ship a post-mortem whose unexplained share is high for a reason the customer would reasonably read as the module not working.

Where this sits

One of 16 modules, on one engine.

OTIF Post-Mortem reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 15 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.

Get started

Bring one month of data. Leave with your own control tower.

A demo runs on your material master, your purchase orders and your stock — not on ours. Thirty minutes, and you see your own exceptions rather than a scripted one.

Ask a question

Book a demo

Thirty minutes, on your own data. Six fields — the rest only helps us prepare.

Not binding. Tell us the size and we will say which one fits.

The demo connects to it, so this shapes the whole session.

Add context, and the demo runs on your problem rather than a scripted one

We reply within one working day.