Why your OTIF report causes arguments instead of action
Quick answer
OTIF and SLA reports cause arguments when one KPI definition is forced across operations that work differently. The fix is not a prettier dashboard. It is agreed business logic: which date starts the clock, which event stops it, which product categories need different rules, who owns exceptions, and how Power BI exposes the late, at-risk and disputed orders each day.
One standard OTIF definition sounds clean in a meeting. It gives the business a single number, a single target and a single line on the management pack. The trouble starts when that single number is used to judge teams doing different work under different physical constraints.
This was the problem behind one Power BI KPI report I worked on. The business wanted a daily view of on-time performance, SLA risk and picking progress across warehouse and yard operations. At first, the report used one broad SLA logic. It treated the operation as if every order line moved through the same process and deserved the same clock.
The operation disagreed, and they were right to disagree. Aggregates did not move like pots. Yard work did not behave like warehouse work. Some product categories needed different staging logic, different picking windows and different expectations between order arrival, release, pick, stage and despatch.
The report was not technically broken. It was worse than that: it was technically plausible but operationally unfair. That is when OTIF reporting stops creating action and starts creating arguments.
The teams were arguing because the report was too blunt
The warehouse and yard teams were not arguing because they hated measurement. They were arguing because the measurement was collapsing different operating realities into one judgement.
If a report says a team is late, the first question is simple: late against what? Order date, requested delivery date, release date, pick start, pick complete, staged-ready time, despatch scan or invoice date can all appear in the same ERP flow. They do not mean the same thing.
In this case, the argument centred on whether the teams had been given a fair amount of time to pick and stage different categories. For some work, the standard logic gave a realistic window. For other work, especially where product handling, yard movement or staging rules were different, the same clock made good performance look late.
That is how a KPI turns into a blame machine. The report does not show a useful exception. It creates a meeting about whether the report is wrong.
A KPI is only useful if the people being measured believe the definition reflects the work.
Why OTIF needs more than one clock
OTIF sounds like one metric, but inside an ERP or Power BI model it is usually several decisions pretending to be one calculation. Before anyone argues over a percentage, the business has to agree the rules underneath it.
For this kind of operational report, the important questions are:
- Which event starts the SLA clock: order creation, release to warehouse, customer promise, stock availability or route confirmation?
- Which event stops the clock: pick complete, staged ready, loaded, despatched, delivered or invoiced?
- Do warehouse and yard operations share the same process, or do they need separate logic?
- Do product categories such as aggregates and pots need different handling windows?
- How are split shipments, back orders, substitutions, supplier delays and customer-requested date changes treated?
- Who owns the exception when the order is late: warehouse, yard, planning, purchasing, customer service, master data or supplier?
If those decisions are not written down, the dashboard builder ends up making business policy by accident. A Power BI measure becomes the hidden referee for warehouse performance, supplier performance and customer-service promises.
The Power BI report had to show different operational views
The fix was not to remove the OTIF KPI. The fix was to make the KPI honest.
The Power BI report needed separate views for warehouse and yard, with product-category-specific logic where the physical process demanded it. That meant the model had to recognise category, route, operational owner and the right date events, then calculate late and at-risk work against the rule that actually applied.
That change matters because it separates three very different problems:
- True operational lateness: the team had the work, the clock was fair, and the order still missed the agreed point.
- Definition mismatch: the order looked late because the wrong event or product rule was being used.
- Upstream constraint: the warehouse or yard was blamed for something caused by supplier delay, planning change, stock availability, master data or customer instruction.
Once those are separated, the report becomes useful. Managers can review the exception list every day and see what is actually late, what is at risk, which product categories are causing pressure, which suppliers or parts are creating repeat issues, and where process discipline is slipping.
That is very different from putting one OTIF percentage on a dashboard and asking people to defend it.
The practical model behind a trusted OTIF report
A trusted OTIF report needs a small amount of modelling discipline. It does not have to be an enterprise data warehouse, but it does need the business logic to be visible and testable.
For this kind of report, I would expect the model to include:
- A clear order-line grain, so header dates do not accidentally distort line-level performance.
- A controlled product category or fulfilment route field, not a manually typed label in a spreadsheet.
- Separate date fields for order, release, pick, stage, despatch and delivery where the ERP records them.
- A rule table that says which clock applies to which category, route or operational area.
- Exception reason codes that can distinguish operational misses from supplier, stock, customer or master-data causes.
- A daily at-risk view, not only a historical pass or fail percentage.
The key is that the rule table should be owned by the business, not hidden in a DAX measure that only the report builder understands. Operations should be able to say: this is the rule for aggregates, this is the rule for pots, this is the rule for warehouse picks, this is the rule for yard staging, and this is how exceptions are treated.
What the daily review changed
Once the report reflected the operation properly, the daily conversation changed. The meeting was no longer about whether the dashboard was unfair. It became about which orders needed action.
A good daily OTIF view should let managers scan for:
- Orders already outside SLA.
- Orders likely to miss SLA if nobody intervenes.
- Product categories creating repeat pressure.
- Users or process steps where transactions are not being completed cleanly.
- Parts, suppliers or stock issues blocking fulfilment.
- Customer-service promises that no longer match operational capacity.
That is where Power BI earns its keep. Not by drawing a prettier gauge, but by making the exception path visible before the customer sees the failure.
How to stop OTIF reports becoming political
If your OTIF report causes the same argument every week, do not start by redesigning the visual. Start by auditing the definition.
Use a short working session with operations, customer service, planning and the report owner. Pick ten real orders: some on time, some late, some disputed. For each one, trace the dates and status changes from the ERP through to the dashboard. Ask whether the result feels right and, if not, whether the problem is the source data, the business rule or the process.
Then write the rule down in plain English before changing the measure. For example: for this product category, the SLA starts when the order is released and stock is available; for this yard category, the staging window is different; for customer-requested date changes, the promise date is reset only when customer service records the reason.
That definition work is not admin. It is what stops the report becoming political.
The takeaway
OTIF, KPI and SLA reporting is not just a dashboard build. It is a business-definition exercise with a Power BI front end.
If date logic, product categories, fulfilment routes, exclusions and ownership are wrong, the report will create arguments instead of action. If those rules are agreed and visible, the same report can show managers what is late, what is at risk, who owns the next action and which repeat problems need fixing.
Build the definitions with the people who run the process. Then use Power BI to make the exceptions visible, the ownership clear and the daily review worth having.
If your current report cannot do that, use a Power BI reporting trust checklist or a post go-live reporting reconciliation checklist to test the logic before rebuilding the visuals.
Do your KPI reports create arguments?
Digital Adaption helps operations and finance teams define trusted KPI logic, reconcile source data and build reports people can act on.
View reporting support