The business is not broken where you think it is

A customer order leaves the warehouse two days late.

Sales sees a commitment that was not met. Operations sees a planning failure. The warehouse sees unavailable stock. Finance sees avoidable cost and margin pressure. IT receives a request to correct the report.

Each interpretation may be accurate. None of them necessarily explains where the problem began.

The instinct is to investigate the place where the failure became visible. That is often the right place to contain the immediate consequence. It may be the wrong place to prevent the same condition from returning.

A problem can become visible at a different point from where it originated.

The point of appearance is not a diagnosis

The point of appearance is where the business first sees or feels the consequence: a late order, an incorrect report, a stock variance, a missed approval or a customer complaint.

The point of origin is the earlier point at which business reality first moved materially away from what the organisation expected.

Those two points can be close together. A failed integration, incorrect configuration or unavailable system may directly create the visible problem.

They can also be several decisions and handoffs apart.

Consider an illustrative late order sequence:

1. A delivery date is committed before capacity is confirmed.
2. An exception is approved outside the normal workflow.
3. The revised priority does not reach planning before the next run.
4. Stock exists, but at another site or in a status that cannot be used.
5. The system records the resulting order position and the report shows the delay.

By the time the warehouse encounters the order, the business has already passed several points at which the outcome could have changed.

The warehouse still has responsibility for what it controls. Sales still has responsibility for the commitment. Planning still has responsibility for its decisions. Technology still has to perform as designed.

But accountability becomes more accurate when it follows the complete operating sequence instead of stopping at the team closest to the symptom.

Why reasonable fixes can fail

When pressure is high, the nearest fix is attractive.

The report is redesigned. The warehouse is retrained. Another approval is introduced. A new spreadsheet is created. The system is blamed, customised or replaced.

Any of those actions may be necessary. The risk is approving one as the permanent answer before the causal chain is understood.

A better report may reveal the same misalignment sooner without removing it. Retraining may strengthen the final handoff while leaving the earlier decision unchanged. Another approval may add control on paper while increasing delay in practice. A new system may encode an unresolved business rule at greater cost.

The visible symptom can improve temporarily while the originating condition survives.

This is why recurring problems often move. The issue appears in one team, is corrected locally, then returns later in a different report, customer interaction or operational exception.

The system may be the cause or the record of the cause

Technology should neither be blamed automatically nor protected from scrutiny.

A system can originate a problem through downtime, incorrect configuration, weak integration, poor usability, defective logic or an automation applying the wrong rule. Those are real technical causes and should be treated as such.

A system can also be an accurate record of fragmented inputs, conflicting business rules and decisions made outside the process.

The distinction cannot be settled by opinion. It requires evidence from the operating reality: timestamps, audit trails, actual handoffs, exception routes, business rules and the people doing the work.

This is also why documented process maps are not enough on their own. The written process shows how work is expected to happen. The people performing it reveal how work is made possible under real demand, incomplete information and time pressure.

The gap between those two realities is not automatically evidence of poor discipline. It may reveal a process that cannot absorb the conditions it was designed to handle.

Systems thinking does not remove accountability

Looking beyond the nearest person or system is sometimes mistaken for avoiding accountability.

It should do the opposite.

Weak accountability asks only, “Who was closest when the problem became visible?”

Stronger accountability asks what conditions shaped the outcome, who controlled each material decision, whether they had the required information and authority, and which change would reduce the likelihood of recurrence.

People still own their decisions. Leaders still own priorities and business rules. Process owners still own the way work connects. Technology teams still own technical performance. The difference is that responsibility is assigned according to evidence rather than proximity.

Containment and prevention are different decisions

An urgent issue may need an immediate local response. The delayed order must still move. The incorrect report must still be corrected. The customer still needs an answer.

Containment protects today’s outcome.

Prevention asks why the business needed containment in the first place.

Treating these as separate decisions helps leaders avoid turning an emergency workaround into the new operating model:

• Stabilise the immediate outcome.
• Preserve the evidence before the story is simplified.
• Test where the first material divergence occurred before approving the lasting change.

The answer may sit in a decision, the information available at the time, the process, a handoff, accountability, the system, a business rule or a combination of them.

The objective is not to force every problem into one convenient “root cause”. It is to understand enough of the connected conditions to choose a change that can hold.

The question before the next fix

Before approving another report change, training intervention, control, customisation or system replacement, ask:

Are we correcting where the problem appeared or where the chain first diverged?

If the answer is not supported by evidence, the proposed fix is still a hypothesis.

Choose one recurring issue with a material effect on cost, control, capacity, customer experience or decision quality. Make its real operating path visible before deciding which solution it needs.

That is where better change begins: not with the nearest solution, but with a clearer understanding of the business reality it must improve.

Evidence note: The distinction between immediate and underlying causes is established in the UK Health and Safety Executive’s investigation guidance, which also warns against focusing only on immediate events in its guidance on organisational learning. NHS England similarly promotes system based learning rather than simplistic single cause analysis and uses walkthrough analysis to examine the gap between work as imagined and work as done. The business scenario in this article is illustrative.