What a Rising Backlog Tells You Weeks Before a Job Is Late

Backlog is the length of the queue in front of a station, and its direction is a leading indicator: it rises the moment work starts arriving faster than the station clears it, which is weeks before any job on that station crosses its due date. Lateness reports tell you the arithmetic already failed. Backlog tells you it is about to. EDGEBIC by User Solutions computes it per work center per period in the Resource Calendar, and the number is drillable down to the exact jobs behind it.

This post is about one specific return: the decision window you buy by watching a cause instead of an effect. It sits under the EDGEBIC results guide and is the leading-indicator companion to the return on catching an overload early.

Every Lateness Metric Is Lagging by Construction

Start with why the usual dashboard does not warn you.

On-time delivery is computed from completed jobs against their due dates. It is a scorecard, and by definition it reports on work that has already shipped or already failed to. The Late Jobs report is faster because it includes forecast lateness, but it still only fires once a job's scheduled end has crossed its due date, meaning the overload that caused the slip already happened and already got absorbed into the plan.

Both are worth watching. Neither one leaves you many options when it moves, because the condition they report is the condition after the arithmetic broke.

What you actually want is the input side: is this station taking on more than it can clear? That question has an answer weeks earlier, and it is a different number: backlog in capacity scheduling, the forward sum of remaining hours a work center still owes.

The Mechanism: Backlog Is a Forward Sum That Burns Down

In the Resource Calendar, reachable as a tab inside Schedule, each work center can be read in several modes. Two of them look similar and answer completely different questions.

Assigned answers "what hours land in this period?" It is this week's load.

Backlog answers "how much work is still ahead of this station as of this period?" It is the forward sum of all remaining allocation hours on or after each period. Critically, it burns down as work is consumed rather than repeating: a step carrying 24 hours spread over three days reads 24, then 16, then 8, then 0 across the periods.

That burn-down is the whole reason the trend is readable. If backlog simply repeated the booked total until an operation finished, the number would be a step function full of false plateaus. Because it decays as hours are consumed, a flat reading means the station is exactly keeping pace with arrivals, a falling reading means it is gaining ground, and a rising reading means work is arriving faster than it is being cleared.

This is classic input and output control logic, and it is the reason lean and APS practice both put queue length ahead of delivery percentage in the daily review.

The Causal Chain, Step by Step

Here is the whole chain from a number moving to a customer being disappointed, so you can see exactly where the intervention goes.

1. Orders arrive and get scheduled. Each operation books hours against a work center. Note that imports never schedule on their own, so an imported order joins the backlog only after a Drive Schedule run.
2. Arrivals outpace clearance at one station. Its backlog begins climbing. Nothing is late. No dashboard turns red. The Assigned row for the current week may look entirely normal.
3. The queue pushes start dates outward. Later operations on that station get placed further out, because the earlier hours are taken. This is finite capacity working correctly, not a fault.
4. A job's computed end passes its due date. Now it appears in the Late slice or on the Late Jobs report. This is the first moment a conventional review notices.
5. Recovery options are expensive. Whatever remains at this point is overtime, an expedite, or a moved date, because the cheap options needed time you no longer have.

The intervention belongs at step 2, and step 2 is only visible if someone is reading the queue rather than the scorecard. That is the entire value proposition of the metric.

From a Number to a Named Job

A trend on its own would be an interesting chart and nothing more. What makes it actionable is that you can click through it.

Click any non-zero Backlog cell and the Job Detail dialog opens, listing the allocations that make up that exact number: job number, product, work center, shift, date, instance, transaction hours, and transaction pieces. The rows sum back to the cell under whatever shift and job filters are active on the calendar.

So the review sequence is short. Notice a station whose backlog has climbed three weeks running. Click the cell. Read which jobs and how many hours. Then decide, because you now have both the condition and its composition.

The decisions that open up at that point are the cheap ones: shift the least urgent job in the list to an alternate machine or a work center group member, resequence the queue, place a modest overtime block on the station, or quote the next order against a lead time that reflects the real queue. Every one of them costs less than an expedite, and every one of them requires the notice that only the leading indicator provides.

Measuring Your Own Warning Lead Time

Do not take a number from anyone else's plant for this. It is measurable in yours, and the measurement takes a quarter of light effort.

1. Pick your three or four busiest stations. Include your constraint if you have flagged one.
2. Record backlog once a week, same day, same view. Week buckets are usually the right grain. Put it in a spreadsheet with one column per station.
3. Separately log the date each late job appears, from the Late Jobs report, and note which station caused it.
4. Compute the gap. For each late job, find the week its causing station's backlog started climbing. The distance between that week and the week the job appeared as late is your warning lead time for that station.
5. Value the window. For a sample of those late jobs, ask what the cheapest available recovery would have been at the earlier date, and what you actually paid at the later one. The difference, repeated across a year, is the return.

The number you get will be specific to your mix, your routings, and your queue discipline. A station with long operations and few jobs will warn you differently from a high-turn station running short setups. That is exactly why a plant-specific figure beats a borrowed one.

For context on 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, and Homestead Furniture cutting schedule build from 40 hours to 2. Those belong to their engagements and are quoted as heritage, not as forecasts for your shop.

Where This Benefit Does Not Apply

Backlog is a genuinely useful early warning and a genuinely narrow one. Four honest limits.

It only knows about scheduled work. Backlog is the forward sum of booked allocation hours. Demand sitting in your sales pipeline, quoted but not converted, or entered but not yet run through Drive Schedule contributes nothing. A station can read zero backlog while a full order book waits behind it, and the metric is not lying, it is answering the question it was asked.

It has no opinion about due dates. A large backlog protecting distant dates is fine. A small backlog protecting tomorrow is not. Level alone is meaningless; you need the slope, and then you need the dates on the jobs behind it. Reading a high number as a problem is the most common misuse of this metric.

It does not tell you why. A climbing queue could be more orders, a routing whose hours were always wrong, a machine running below its assumed rate, or a downstream station starving this one. Backlog points at the station. Finding the cause means going to variance data or the utilization report.

It cannot manufacture capacity. If a station's backlog climbs for two quarters and every cheap answer has been used, the honest reading is that you are short of capacity and the metric has been telling you so for months. At that point it becomes evidence for a machine request, not a scheduling problem to solve.

The takeaway

Every metric in a production review is either a cause or an effect, and almost all of them are effects. Backlog is a cause, which is why its slope arrives weeks before lateness does and why the decisions it opens are the cheap ones. Record it weekly, drill any cell that climbs, and measure your own warning lead time rather than trusting a figure from someone else's shop. If you want to see the queue behind your busiest station, book a demo of EDGEBIC, and if you are running the older platform, the move from RMDB to EDGEBIC brings the Resource Calendar with it. Read this next to the return on catching an overload early and how load visibility sharpens staffing decisions.