Who Undoes This?

A recommendation that improves your metric by degrading someone else’s will be reversed, and usually not by argument. It will be reversed by workaround, which is slower to detect and harder to fix.

The people who do this are not obstructive. They are being evaluated on a local scoreboard and responding rationally to it. Everyone in the system is being reasonable, which is precisely why the system produces an unreasonable outcome.

Local scoreboards

A plant manager measured on utilization will run long batches. A parts organization measured on holding cost will thin the tail. A sales team measured on bookings will promise dates operations cannot meet.

None of these people is wrong given what they are graded on. The oscillation that follows, where each function’s correction triggers the next function’s correction, is a property of the measurement structure rather than of anyone’s judgment.

Your recommendation lands inside that structure. If it asks someone to accept a worse number on their own scoreboard for a better number on yours, the structure will absorb it and the absorption will look like implementation failure.

The question

Before you write the recommendation, find the adjacent team that will dislike it if it works as designed, and go ask them what they will do about it.

Not whether they agree. What they will do. The answers are informative in a specific way:

If they say they will escalate, you have a disagreement, which is workable and belongs in the open.

If they say they will comply, ask what it costs them and whether anyone is watching that cost. Uncompensated compliance decays.

If they say they will work around it, you have not finished. A rule with a known, unpriced bypass is not a rule; it is a suggestion with a document attached.

Feedback you will pretend not to see

Every operational system has loops that the analysis conveniently excludes because including them makes the model harder.

Expedites are the canonical example. Thin the stocking on an item class and expedite requests rise, which restores service at a cost that lands in a different budget line and therefore does not appear in your comparison. The improvement is real in the spreadsheet and absent in the aggregate.

The practical defense is to ask, for every alternative, what will increase somewhere else if this works. There is nearly always something, and naming it is what separates an analysis from a projection.

Delay is why it oscillates

The reason these systems swing rather than settle is delay, and delay is the part almost every analysis leaves out.

A stockout today produces an expedite next week, a policy review next month, and a safety-stock increase next quarter. By the time the correction lands, the condition that justified it has often passed, so the correction overshoots. The next correction then overshoots the other way. Nobody in the loop is behaving unreasonably, and the aggregate behavior is a system that is permanently either too full or too empty and never at rest.

The practical consequence for a recommendation is that you have to state how long your rule takes to show its effect, and commit to not intervening inside that window. A rule revisited faster than its own feedback delay is not being managed, it is being oscillated. This is the argument for a revisit date rather than continuous monitoring: continuous monitoring plus a delay is precisely the recipe that produces the swing.

Where to push

Not every point in a system is worth the same effort to change, and the highest-leverage point is rarely the one with the most obvious lever attached.

Changing a parameter is easy and usually weak: a threshold moves, the system absorbs it, the behavior returns. Changing the structure of a feedback loop is harder and much stronger: routing expedite cost back to the requester changes what requesters do, permanently, without anyone policing it. Changing what is measured is stronger still, because local scoreboards are what produce the reasonable behavior that adds up to the unreasonable outcome.

The ordering matters for scoping. An analyst with one quarter and no authority should look for the cheapest structural change rather than the largest parameter change, because the parameter change will be undone and the structural one will not.

Constraints are often the system

A constraint that looks like physics frequently turns out to be a policy that someone can change, and vice versa.

Both errors are costly. Treating a policy as physics means optimizing inside a box that need not exist. Treating physics as policy means producing a recommendation that cannot be implemented and losing credibility for it.

The cheap test is to ask who could change it and what it would cost them. If there is a name and a number, it is a policy. If there is not, plan around it.