Disposition Latency, Not Defects, Sets Your Sourcing Ceiling

The report came back missing a supplier

A mid-market prepared-foods brand sent over its year-to-date ordering report so the team could check whether the packaging awards were actually being followed. The file carried quantities but no pricing, and it left out one distributor entirely. That distributor was the one still shipping a high-volume item that had been awarded to a different converter months earlier. The single question the report existed to answer, is the award being honored, was the exact question the report could not answer.

Nobody did anything wrong. The fix was trivial: same format, add the missing supplier. The fix was never the expensive part. The expensive part was that the compliance read, the client deliverable, and an unresolved overlap between a folding carton group and a corrugated group all stopped moving until the next pull came back. One missing column in one file, and a category's worth of decisions went to sleep for a cycle.

The defect is cheap, the wait is not

Sourcing programs get managed as analysis pipelines. They behave like queueing systems. Items rarely fail outright; they wait. And what they wait on is almost never more analysis. They wait on somebody with standing to say "this is what we are doing about it."

Look at what sits in the queue. On another spend file, for a global protein processor, categorization was wrong across most of the non-corrugated lines, and two of three major box vendors had been tagged out of scope. Real spend, invisible to the bid, sitting in a workbook that was not shared, so corrections could not be seen by the people who needed them or rolled back when they went wrong. The classification engine behind it had never been backloaded with the roughly 72 historical customer data sets that had trained its counterpart, so it kept producing the same class of error at the same rate. Each wrong tag is cheap. Each one still has to be found, questioned, and disposed of by a human, and that is the resource in short supply.

The program's own tracking says the same thing in plainer language. The blocked gates read "award recommendation," "issue RFQ and bid package," "sourcing strategy and path aligned," and "volume and usage data." Not one of those is blocked on effort. Every one is blocked on a predecessor, which is to say on a decision that has not been made yet.

It scales up, too. On a leveraged packaging program, with the resin market unsettled and corrugated increases announced, the question of whether to take a category to market at all was held pending an update from one person. That is the same mechanism at program altitude: a live decision parked behind an input, with no date attached to the decision itself.

This is why predictive orchestration matters more than faster reporting. Orchestration means the decision is scheduled before the data lands, with the owner named and the fallback written. Reporting speed only shortens the first half of the cycle. If the second half, the disposition, has no clock on it, cutting analysis time in half moves the finish line by almost nothing.

Put a decision date on it the day it is raised

Start with measurement, because most teams have never looked at this number. For your last twenty open items, record two timestamps: raised, and decided. Not "data received," decided. The gap between those two, not the analysis time, is your program's actual cycle time.

Then change one rule. Every data request that gates a decision gets a decision date at the moment the request goes out, not when the data comes back. My rule is that the request never owns the calendar. The decision owns the calendar, and the data has to arrive before it. If the data is late, you decide with what you have, write down the assumption you used, and name the single condition that would reverse the call. A reversible decision made on time beats a correct decision made after the transition window closed.

Name a disposer for every gate, one person, not a standing meeting. Meetings do not have authority; people do. A gate assigned to a recurring call inherits that call's cadence as its floor, so a weekly meeting quietly sets a one-week minimum on every decision routed through it.

Fix classification where it is produced instead of where it is discovered. Backload the history into whatever engine tags your spend, work in a shared file so corrections are visible and reversible, and treat a supplier missing from a compliance report as a failed report rather than a partial one. A partial report invites the team to work it anyway, which is how a known gap becomes an unknown one.

Finally, measure award compliance against shipped volume by supplier, monthly. That is the check that would have caught a high-volume item still flowing from the wrong distributor without anyone needing to ask for a special pull.

What a well-run sourcing program reads

Every open item has a named owner and a decision date, and both are visible without asking. Median time from raised to decided runs inside one meeting cycle. No gate is assigned to a meeting. Award compliance is read monthly against shipped volume, every awarded supplier appears in the file, and a report that omits one is rejected instead of analyzed. Spend classification is corrected in a shared document with an audit trail, and the categorization error rate on new files trends down quarter over quarter rather than holding flat.

The bottleneck was never the hard question

The category work was not stalled on anything difficult. It was stalled on an easy question that had a name attached to the data and no name attached to the decision. Get the data faster and you still wait. Put a date and an owner on the decision, and the data starts arriving to meet it.