Connect981 – Content Dev

RSC Topic: Operational Performance Metrics

On-Time In-Full (OTIF)
On-Time In-Full (OTIF) is a delivery performance key performance indicator (KPI) that measures how reliably an organization delivers customer orders by the agreed date and in the complete, requested quantity. It is widely used in manufacturing and supply chain operations to monitor service levels between plants, distribution centers, and customers.

What OTIF measures

OTIF typically combines two aspects of delivery performance into a single metric:
- On-time: Whether the order (or shipment line) is delivered within a defined delivery window relative to the promised or required date and time.
- In-full: Whether the quantity delivered matches the quantity ordered (or otherwise committed), with no shortages or unplanned partial deliveries.
OTIF is usually expressed as a percentage of eligible orders or order lines that meet both conditions simultaneously within a specified period (for example, per day, week, or month).

How OTIF is used in manufacturing and supply chains

In industrial and regulated environments, OTIF commonly:
- Links production planning, warehouse operations, and logistics performance to customer delivery expectations.
- Requires data from ERP, MES, WMS, and transport or shipping systems to determine promised dates, ship dates, delivery timestamps, and confirmed quantities.
- Is configured differently by customer or contract, for example using requested delivery date vs. committed date, or order-level vs. line-level evaluation.
- Supports analysis of late or short deliveries by cause, such as capacity constraints, quality holds, missing documentation, or carrier issues.
Some organizations calculate separate sub-metrics, such as on-time rate and in-full rate, and then define OTIF as the share of orders that satisfy both criteria at once.

Scope and boundaries

OTIF usually focuses on customer-facing or intercompany deliveries, not internal work-in-progress movements within a plant. It tracks adherence to agreed delivery performance, not manufacturing efficiency or product quality. It can, however, be correlated with other KPIs such as OEE, throughput, or scrap rates to understand how upstream issues affect delivery reliability.

Common confusion
- OTIF vs. on-time delivery (OTD): OTD typically measures whether deliveries are on or before the promised date, but may not require full quantity. OTIF explicitly requires both timeliness and completeness.
- OTIF vs. perfect order rate: Perfect order metrics often add further conditions such as correct documentation, correct labeling, and no damage. OTIF usually focuses only on time and quantity.
- Order-level vs. line-level OTIF: Some systems define an order as OTIF only if every line is on-time and in-full, while others measure each line separately. This difference must be defined clearly when comparing values across systems or sites.
Relation to the source context

In KPI sets for manufacturing, OTIF is often grouped with metrics such as OEE, non-productive time, quality defect rates, and cost or productivity. It provides the delivery adherence perspective, translating production and supply chain performance into customer-facing service reliability.
June 13, 2026
on-time-in-full

Core meaning

On-time-in-full (OTIF) is a supply chain and operations performance metric that indicates how reliably a supplier or plant meets customer order commitments.

It typically measures the percentage of orders that are delivered:

– **On time** – by or before the agreed delivery date or time window, according to defined business rules, and
– **In full** – with the complete quantity and items requested on the order, without shortages or unapproved substitutions.

An order usually counts as “OTIF” only if **both** conditions are met.

How OTIF is calculated

Organizations commonly calculate OTIF at the order or line level, based on clear rules such as:

– **Denominator**: total number of orders (or order lines) scheduled for delivery in a period.
– **Numerator**: number of those that meet both the on-time and in-full criteria.
– **Result**: OTIF % = (qualifying orders ÷ total orders) × 100.

Variations include:

– Order-level OTIF (all lines must be on-time and in-full to count).
– Line-level OTIF (each line is evaluated separately).
– Volume- or value-weighted OTIF.

The exact time window (e.g., on the due date only, within a tolerance of ±1 day, or within a delivery window) and quantity tolerance (e.g., no shortage allowed, or small deviations permitted) are defined in local procedures or contracts.

Use in manufacturing and regulated environments

In industrial and regulated manufacturing, OTIF is commonly used to:

– Assess **service performance** to external customers, distributors, or internal plants.
– Monitor the impact of **planning parameters** (e.g., safety stock, lead times, minimum order quantities) on service reliability.
– Track **supply chain robustness** across production, quality release, packaging, and logistics steps.
– Support **supplier performance management** when plants act as suppliers to other sites or contract manufacturers.

In regulated environments, OTIF is influenced not only by production capacity and inventory, but also by quality release cycles, documentation, and required checks, which can affect the “on-time” portion.

Boundaries and what OTIF is not

OTIF:

– **Is** a measure of delivery reliability relative to customer commitments.
– **Is not** a direct measure of cost, profitability, or capacity utilization.
– **Does not** by itself explain *why* deliveries were late or incomplete; root cause analysis, schedule adherence, and quality investigation are separate activities.
– **Is not** the same as forecast accuracy or demand plan adherence, which compare actual demand against planning forecasts.

Some organizations also track related metrics such as:

– **On-time delivery (OTD)** – may ignore the “in-full” component.
– **Fill rate** – focuses on the proportion of demand volume supplied, not necessarily on the promised date.

Common variations and confusion

OTIF is also written as:

– OTIF (most common acronym)
– On time in full
– On-time / in-full or on-time & in-full

Common points of confusion include:

– **OTIF vs. OTD**: OTD may count an order as successful if it is on time even when partially delivered. OTIF requires the full quantity as well as timeliness.
– **OTIF vs. fill rate**: A high fill rate can coexist with low OTIF if shortages are small but frequent, or if full quantities are delivered late.
– **OTIF vs. service level**: “Service level” is a broader term that may include several service KPIs (OTIF, lead-time performance, response time), while OTIF is one specific metric.

Site context: OTIF and safety stock changes

When safety stock levels are adjusted in a plant, OTIF is often monitored to observe how changes in inventory policy affect service reliability.

Typical patterns include:

– **Reduced safety stock** may increase stockouts or partial shipments, lowering OTIF.
– **Increased safety stock** may improve OTIF but tie up more inventory, so it is evaluated alongside inventory value and carrying cost indicators.

In brownfield or highly regulated environments, measuring OTIF precisely can depend on data quality in ERP/MES, alignment of promised dates, and consistent rules for what counts as “on time” and “in full.”

June 13, 2026
How do we show both global and local KPIs in the same dashboard?
Yes, but only if you separate standardized enterprise metrics from locally useful operational metrics and govern how they relate.

The practical pattern is a layered dashboard:
- Global KPIs at the top, using one approved definition across plants, programs, or business units.
- Local KPIs underneath or behind drill-down views, showing site, line, cell, product-family, or shift-level performance in the context operators and supervisors actually manage.
- Explicit mapping between the two, so users can see whether a local measure feeds a global KPI, explains it, or exists only for local control.
If you do not govern that relationship, the dashboard becomes misleading. Many organizations say they have one KPI framework when they actually have multiple formulas, different data cutoffs, different exclusions, and inconsistent master data. In that case, putting global and local KPIs on the same screen creates apparent alignment without real comparability.

What has to be standardized

Not everything needs to be identical across sites. The items that usually do need standard control are:
- metric name and business definition
- formula and inclusion or exclusion rules
- time basis, refresh cadence, and reporting window
- source systems and system-of-record precedence
- unit of measure and normalization logic
- owner, approval workflow, and change control
Without that baseline, a global KPI is often just a roll-up of incompatible local numbers.

What can remain local

Local KPIs are still important because plants do not run the same process, asset mix, staffing model, product mix, or constraint profile. A site may need local measures for setup loss, queue age, first-pass inspection delay, rework load, tool availability, outside processing turnaround, or traveler completion lag. Those may be operationally critical even if they are not appropriate as enterprise KPIs.

The key is to label them clearly as local, define their scope, and avoid presenting them as cross-plant comparable unless they truly are.

Recommended dashboard structure
1. Start with enterprise KPIs that answer leadership questions consistently across the network.
2. Allow drill-down by site, program, line, product family, shift, or asset without changing the core definition of the enterprise KPI.
3. Add local KPIs in a separate section for the selected site or area.
4. Show lineage or metric metadata so users can inspect definitions, sources, and last refresh times.
5. Flag exceptions where a site cannot yet calculate the standard KPI due to missing data, legacy systems, or process variation.
This structure is usually more credible than trying to make one flat dashboard satisfy executives, plant leaders, and frontline supervisors equally well.

Brownfield reality

In mixed MES, ERP, PLM, QMS, historian, and spreadsheet environments, the main issue is rarely dashboard software. It is data semantics and integration debt.

Common failure modes include:
- the same KPI calculated in different systems with different logic
- site-specific spreadsheet adjustments outside audit trails
- local event codes that do not map cleanly to enterprise loss categories
- different production calendars, shifts, or batch boundaries
- missing context such as rework, holds, nonconformance status, or genealogy links
- master data conflicts for work centers, part numbers, routings, and organizational hierarchies
That is why full replacement is often the wrong first move in regulated, long-lifecycle environments. Replacing every local system just to force one KPI model usually runs into qualification burden, validation cost, downtime risk, and integration complexity. In many plants, a better path is coexistence: keep systems in place, define a canonical metric layer, map local data carefully, and tighten governance over time.

Tradeoffs to expect

There is no perfect design. You are balancing competing needs:
- Comparability versus local usefulness: the more standardized a KPI is, the less it may reflect local operational reality.
- Simplicity versus traceability: executives want clean rollups, but regulated operations often require users to inspect underlying records and exclusions.
- Speed versus control: fast dashboard rollout is possible, but trustworthy KPI harmonization takes data cleanup, ownership, and change control.
- Single source of truth versus multiple fit-for-purpose views: one semantic layer is desirable, but different roles still need different visualizations and tolerances.
If leadership insists on one dashboard, make sure that means one governed metric framework, not one screen that hides inconsistency.

Minimum governance model

At a minimum, assign:
- metric owners for each global KPI
- site owners for local KPI definitions and mappings
- approval and version control for formula changes
- documented exceptions for sites that are not yet aligned
- traceability from dashboard values back to source transactions or events where feasible
That last point matters in regulated operations. If a KPI drives management action, investigations, or audit evidence, users need confidence in where the number came from and what changed.

So the short answer is: yes, show both global and local KPIs in the same dashboard, but do it as a governed hierarchy, not as an unstructured mix of metrics.
June 5, 2026