The One Product That Is Quietly Wrecking Your Delivery Record

A plant-wide on-time percentage is an average, and averages are governed by the many while the damage is concentrated in the few. Somewhere in most product catalogs is one part number that generates a disproportionate share of the late jobs, and finding it converts an unactionable percentage into a specific project. EDGEBIC by User Solutions puts the volume ranking and the on-time ranking side by side over a ninety-day window, so the item that is both frequent and chronically late surfaces without a spreadsheet exercise.

This post covers one return: replacing a general improvement push with a specific one. It sits under the EDGEBIC results guide and pairs with how fewer late jobs reduce customer chargebacks, which handles what the misses cost.

Why the Plant Number Cannot Be Improved Directly

Consider what an 85 percent on-time figure describes. It does not mean every part number ships 85 percent of the time. In practice it means most items ship close to perfectly and a small group ships badly, and the average lands where it lands.

That has a consequence people rarely draw out. An improvement effort aimed at the average is aimed at nothing in particular. It gets distributed across the catalog, which means the items already performing well absorb attention they do not need, and the items generating the misses get a fraction of the effort required to change their behavior. Two quarters later the number has moved a point and nobody can say which action moved it.

The alternative is to stop treating delivery as a plant property and treat it as a property of individual products, because that is where the causes actually live. A routing belongs to a product. A lead time belongs to a product. A path through the constraint belongs to a product. None of those are plant-level facts.

The Mechanism: Two Rankings, Read Together

The executive view carries a ninety-day product pair: the top items by volume and the bottom items by on-time-in-full. The design intent is stated plainly in the product documentation, which is that chronic late runners with volume surface first.

Reading them together is the whole trick, because either list alone misleads.

Alongside it, the On-Time Delivery report groups completed and forecast jobs against their due dates by customer, with the on-time percentage on its subtitle bar. Finished jobs are judged by their actual end, and unfinished ones by their scheduled end, which makes it both a scorecard and an early-warning list.

Two lenses, then: the product lens tells you what to fix, and the customer lens tells you who is currently paying for not having fixed it. Most plants have only ever looked through the second one.

The Three Causes, and Why the Distinction Decides the Fix

A product that is chronically late is almost never late for exotic reasons. It is late for one of three, and they have nothing in common.

Its routing understates the hours. Somebody estimated the per-unit hours once, optimistically, and the item has been planned against that number ever since. Every schedule for it is wrong before work starts, so it eats into the next job and slips. The signature is that logged actuals consistently exceed planned hours on the same steps, run after run.

Its lead time is unset or wrong. Classification of lateness uses the delivery-ready date, which is the scheduled end plus the product's end-item lead time. If that lead time is unset, the item looks better than reality and the miss appears at the dock. If it is overstated, the item looks worse than reality and you will chase a problem that is only in the product record.

It routes through the constraint. The item's path includes the station that sets your plant's pace, so it competes with everything else that needs that station and loses whenever priorities move. The signature is that the item is fine in quiet weeks and late in busy ones.

That fourth row exists because sometimes the data is right and the promise was simply not achievable. The honest answer is a longer quoted lead time for that item, which is a commercial decision that accurate quoting makes possible rather than a scheduling failure.

The Causal Chain to a Better Plant Number

1. You decompose misses by product rather than reading the plant average.
2. A short list accounts for most of the damage. In most mixes it is remarkably short.
3. You diagnose each item to one of the causes above. This takes an hour per item, not a project.
4. You apply the matching fix. A routing correction, a product field, a routing change, or a re-quoted lead time.
5. Those items stop generating misses. Their late-job count falls to something like the rest of the catalog.
6. The plant average moves, and you know why. Which is the part a general push can never deliver.

Step six is worth more than it looks. A number that moved for a reason you can name is a number your management team will keep funding. A number that drifted up during a general improvement effort teaches nobody anything and is the reason these programs get quietly dropped.

Measuring It in Your Own Plant

Ninety days of history and about two hours.

1. Pull the ninety-day volume and on-time rankings. Note which part numbers appear on both the high-volume and low-performance lists.
2. Count late jobs by product across the same window, using your late-job history rather than a percentage.
3. Compute each product's share of total late jobs. Sort descending. This is your ranked list, and its shape is the finding: check how few items make up the majority.
4. Take the top item and test the three causes in order. Compare its logged actuals against its planned hours on each step. Check whether its end-item lead time is set and whether the value is right. Check whether its routing crosses your flagged constraint.
5. Estimate the recovery. If that item's late jobs stopped, what does your plant percentage become? That is the size of the prize for one item, and it is usually larger than anyone expects.
6. Repeat for the second item, then stop and go fix them. Analysis past the second item is procrastination.

For documented outcomes rather than typical ones, the User Solutions and RMDB lineage includes GE Railcar moving from 30 percent to 90 percent on-time delivery. That belongs to that engagement and is quoted as heritage, not as a forecast for a particular part number.

Where This Analysis Does Not Apply

Five honest limits.

It needs due dates to work at all. A job without a due date cannot be judged late, so it contributes nothing to any ranking. If your late population looks small relative to how the shop feels, audit for empty due dates before you audit products.

Thin history produces noise. A part number introduced last month has too few runs to rank. Two late jobs out of two is not a 0 percent performer, it is an unknown, and treating it as a finding wastes a project.

This is not a profitability ranking. It ranks delivery performance and volume, not money. Revenue-based tiles remain offline until that data is captured, and the product's costing view covers labor and material only. If you want to know which product is worth keeping, this analysis is one input among several and not the deciding one.

Fixing the worst product does not fix a plant-wide shortfall. If every product is late because the plant is genuinely short of capacity, product decomposition will show damage spread evenly and no short list will emerge. That flat result is itself the finding, and it points at protecting the constraint or at capacity rather than at any part number.

The customer lens and the product lens disagree sometimes, and both are right. A customer can be unhappy while their products rank fine, because they order the one item that is chronically late alongside four that are not. Read the product list to know what to fix and the customer grouping to know who to call.

The takeaway

Delivery performance is not a plant property, it is a property of individual products, because routings, lead times, and paths through the constraint all belong to part numbers rather than to buildings. That is why a plant-wide improvement push spreads too thin to work and a product-level project moves the average visibly. Rank your misses by product, intersect the poor performers with the high-volume ones, diagnose the top item to one of three specific causes, and fix that instead of everything. To see the product rankings against your own history, book a demo of EDGEBIC, and if you are running the older platform, the move from RMDB to EDGEBIC brings the reporting with it. Read this next to how honest promise dates win repeat customers and how variance data fixes the routing that was always wrong.