The Silo Stack

Many organisations aren’t failing at technology. They’re failing at sequence.

The software goes in before anyone has defined what the business is actually supposed to do end-to-end. The SOPs are written around the tool, not around the work. The integrations are half-built. And then the go-live happens — not because everything is ready, but because the calendar ran out.

That’s where the drift begins.

What executives are hearing from their teams

If this is happening in your organisation, you’re probably hearing some version of the following:

“We just need to get this SaaS tool across the line for this team.”

“The legacy system can’t handle it, so we’ve built something internally to bridge the gap.”

“We tried to get IT involved but it was taking too long, so we’ve moved ahead with what we have.”

“There’s another system the other department is using that does something similar, but we need ours to be a bit different.”

None of these statements are dishonest. Each one is a rational response to a local problem. The person saying it is trying to make progress. What they cannot see — because they’re solving at the SOP level — is that every one of these decisions is adding complexity to a stack that no one is stewarding.

You end up with a pile of digital SOPs. Some SaaS. Some home-grown. Some half-built go-lives that technically launched but never fully landed. Staff members across different areas attempting similar fixes independently. A growing number of systems that are connected in ways no one has fully mapped.

The reports stay green. The pile gets taller.

What’s actually happening

Organisations don’t end up in this position because of bad technology decisions. They end up here because software selection happened before business architecture was established.

The sequence that creates this problem looks like this:

Problem is identified → Software is selected to solve it → Implementation proceeds → End-to-end complexity is discovered mid-delivery → Shortcuts are taken to cross the line → The next problem is identified → Another tool is selected.

Each cycle adds a layer. Each layer makes the next selection harder. And because each decision was made at the SOP level — quick and dirty, close to the problem, disconnected from the whole — no one accumulates a coherent picture of where the organisation actually is.

The cost is not just financial. It’s organisational. Your staff are spending increasing amounts of time managing the interfaces between systems rather than doing the work the systems were meant to support.

What executives should be considering

The mitigation is not a technology decision. It’s an architectural and sequencing decision.

Before the next tool is selected, before the next project kicks off, executives need honest answers to three questions:

Do we have a current-state map of our systems, integrations, and data flows? Not a diagram from three years ago. Not what the IT team thinks it looks like. What it actually looks like — including the home-grown patches, the workarounds, and the systems that were never fully decommissioned.

Have we established an enterprise-level roadmap before we select software? Software selection at the SOP level optimises for the local problem. It almost always creates a broader one. The architecture conversation has to precede the vendor conversation, not follow it.

Who is accountable for the coherence of the whole? In most organisations that have drifted into a silo stack, the honest answer is: no one. Each system has an owner. No one owns the relationships between systems, the end-to-end logic, or the question of whether the current state is moving toward or away from where the organisation needs to be.

The pattern is common. That doesn’t make it inevitable.

Organisations that avoid it don’t have better technology. They have executives who insisted on the architectural conversation before anyone was allowed to start selecting tools. They slowed down at the point where speed felt urgent — and that’s what kept them from spending the next three years undoing decisions that looked sensible in isolation.

The question worth asking before the next project brief lands on your desk: are we solving the right problem, or are we solving the closest one?

SP Singh is the founder of Bhani Consulting. He provides independent ERP oversight and advisory to WA local government and Aboriginal corporations — across the full program lifecycle, from direction through to post-go-live stewardship.