Your OTIF number is a post-mortem.
It should be a warning.
OTIF Reporting & Dashboards on Microsoft Fabric and Power BI
One OTIF number reconciled across ERP, WMS and TMS. Drillable to customer, order and SKU. And a near-real-time layer that flags the miss before the delivery window closes — not on the fifth working day of the month.
Who this is for
OTIF reporting built around your role
OTIF reporting for supply chain, fulfilment and planning teams — the view each leader actually opens, mapped to the decision they own, reconciled across ERP, WMS and TMS on Microsoft Fabric.
Supply Chain Head
The problem
OTIF gets argued over because operations, commercial and planning each measure it against a different date — requested, confirmed or the one planning quietly rescheduled to. The S&OP meeting never quite agrees on the number, so it never quite agrees on the fix.
What we build
One governed OTIF definition and dashboard by customer and lane, built on a Microsoft Fabric model over your ERP, WMS and TMS, read live in Direct Lake.
One OTIF number every function trusts
Customer Service / Fulfilment Lead
The problem
The failure is visible only after the customer has already rung to complain — by which point the order shipped days ago and the goodwill is already spent.
What we build
A near-real-time view of open orders against their delivery windows, so a miss surfaces while there is still time to expedite, split or call ahead.
See the miss before the customer does
Planning Manager
The problem
When OTIF drops there is no drill to root cause, so you cannot tell whether the loss is late dispatch, a short shipment or a carrier problem — and the fix goes to whoever is in the room, not whoever owns it.
What we build
Drill-through from the plant-level number to the specific failed orders, with OTIF split cleanly into its late and incomplete components across ERP, WMS and TMS.
Root cause visible at line level
COO
The problem
The board pack carries a single OTIF figure a month after the fact, and nobody can tell you what it cost or which customers drove it.
What we build
A live OTIF dashboard by customer and lane on Microsoft Fabric, drillable to the orders behind the number — not a month-end post-mortem.
OTIF you can act on, not just report
The Problem
Why the OTIF number never quite settles the argument
It is not a reporting problem. It is a data foundation problem wearing an OTIF costume — and it shows up the same way in almost every operation.
The OTIF report is a post-mortem.
It arrives on the fifth working day of the month. By then the order shipped late three weeks ago, the customer already logged the complaint, and the penalty is already in the ledger. The number is accurate. It is also useless — nothing about it could have changed the outcome it describes.
The date you measure against flatters the number.
Requested delivery date, confirmed date, or the date your own planning system quietly rescheduled to? Measuring against the confirmed date instead of the customer’s original request is the most common way OTIF is made to look healthy while customers are quietly furious.
Three systems, three OTIF numbers.
The WMS says the order shipped complete. The TMS says it was two pallets short on the truck. The ERP invoiced the full quantity. Until those three agree against a single order master, your OTIF is an average of three contradictory truths.
Late and incomplete get averaged into one blur.
OTIF is two independent failures wearing one number. The moment you split it into late versus short, the diagnosis changes — and the fix goes to the function that actually owns it, not to whoever is in the room.
What we build
What we build
A reconciled foundation first, then the views that make the number act — not another dashboard nobody trusts.
One agreed OTIF, reconciled across three systems
Replaces
The internal OTIF that reconciles to nothing, argued three ways every S&OP meeting.
- ERP, WMS and TMS connected into one governed layer on Microsoft Fabric via Fabric Mirroring and Azure Data Factory
- One agreed definition of on time and one of in full, reconciled against a single order master
- Measured against the customer’s requested date by default — the promise you are actually held to
- Reconciliation becomes redundant, not a monthly argument
One OTIF number every function trusts. The S&OP meeting debates the fix, not whose number is right.
OTIF three ways — customer, order and line
Replaces
The single plant number that hides which customer, order or SKU is driving the loss.
- Power BI in Direct Lake mode gives the same model at customer, order and line level
- Drill from the plant-level number into the specific customer, lane or SKU driving the miss
- OTIF split cleanly into its late and incomplete components
- Answers in seconds, not a two-day spreadsheet reconstruction
Root cause is visible where it happens — the why takes seconds, not the whole meeting.
Predicted misses, before the window closes
Replaces
Finding out about the miss from the customer, 30 days after it was recoverable.
- Fabric Real-Time Intelligence watches open orders against their delivery windows
- A Fabric Activator rule flags orders trending toward a miss 24–72 hours ahead
- The signal arrives where someone can still expedite, split, or call the customer
- Alerts routed to the planner or customer service, not to a report nobody opens
The miss is managed in-week. Month-end OTIF confirms what you already handled.
OTIF and DIFOT from one foundation
Replaces
The endless argument about whether OTIF or DIFOT is the right number.
- OTIF against the requested date and DIFOT against the confirmed date — both built, both explicit
- The definition shown on the face of the report so the number stops being contestable
- Reconciliation row to any customer vendor scorecard where one exists
- Consistent with the DIFOT dashboard where retail scorecards drive the requirement
The definition argument ends. Everyone is looking at the same, labelled number.
How we work
First working output in 6 weeks
We start with how OTIF is calculated today. The reconciled number has to survive contact with three systems before we build prediction on top of it.
01
Discover — how OTIF is calculated today
Two weeks. Pull order, dispatch and delivery data. Establish which of your three systems disagree, which date you measure against, and whether your timestamps can support live prediction. Establish the real baseline.
02
Prototype — reconciled OTIF for top customers
Two to four weeks. Build the reconciled OTIF model for the top customers and lanes. Validate against actual outcomes for two cycles. Operations and Commercial see the same number for the first time.
03
Deploy — live prediction and alerting
Four to six weeks. All customers and lanes. Fabric Real-Time Intelligence and Activator alerting on the lanes where timestamps support it. Late-versus-incomplete split wired to the owning function.
Technology stack
Lakehouse
Visualisation
Real-Time
Integration
ERP & Order
Fulfilment
Common questions
What buyers ask us
What is the difference between OTIF and DIFOT?
OTIF (On Time In Full) measures delivery to the customer’s requested date, in the full quantity ordered. DIFOT (Delivered In Full On Time) is frequently used as a synonym, but many operations define DIFOT against the confirmed date and OTIF against the requested date — which is exactly why the two numbers diverge. We build both from the same foundation and make the definition explicit on the face of the report.
How is OTIF calculated?
OTIF is the share of order lines delivered to the customer’s requested date, in full, with nothing substituted or short-shipped. It combines two independent failures — late, or incomplete. The number goes wrong in three common ways: measuring against the confirmed date instead of the customer’s original request, disagreement between the ERP, WMS and TMS, and confusing line-level with order-level completeness. We reconcile all three against a single order master.
Can you predict an OTIF miss before it happens?
Yes, on the lanes where your timestamps support it. Fabric Real-Time Intelligence and a Fabric Activator rule watch open orders against their delivery windows and flag the ones trending toward a miss 24–72 hours ahead — while someone can still expedite, split, or call the customer. If your warehouse scans goods-out in an end-of-shift batch, the on-time signal is already blurred and prediction is limited; we tell you this in the diagnostic.
How long until OTIF reporting is live?
First working output in 6 weeks — a reconciled OTIF number in Power BI across ERP, WMS and TMS. A full production platform including live prediction typically takes 12–18 weeks depending on ERP complexity and timestamp quality.
Ready to move
Book a 30-minute OTIF diagnostic
30 minutes with Amit. No slides. No pitch deck. No obligation to proceed. You will leave knowing whether your OTIF problem is a measurement problem, a data-foundation problem, or a genuine capacity problem — three different things with three different fixes.