Digitising Dysfunction

Why technology amplifies whatever you feed it - and what to fix first.

Introduction

Someone is trying to sell you something right now. I have seen this many times over the years.

An ERP software that will give you real-time visibility across your entire operation. A dashboard that will surface insights you never knew existed. An AI copilot that will handle the decisions that eat your week. An automation platform that will eliminate the manual work your team has always complained about.

The promises are compelling. The demos are impressive. The case studies are from businesses that look a lot like yours.

And yet the implementation graveyard of Australian SMEs is full of systems that went live and quietly died. ERPs the team learned to work around. Dashboards nobody checks anymore. Automation running in the background producing outputs nobody trusts. Software licences renewing every year for tools that stopped being used six months after go-live.

The technology was not the problem.

The sequence was. And in some cases, the technology itself was.

Technology Is a Multiplier

This is the principle that changes how you think about every system purchase you will ever make.

Technology does not create capability. It multiplies whatever already exists. Apply it to a well-designed, consistently executed process and you get speed, scale, and genuine insight. Apply it to a broken or undefined process and you get faster errors, wider confusion, and systemic waste - delivered reliably, at scale, every day.

Garbage in, amplified garbage out.

Most business owners understand this in theory. Very few apply it in practice. Because the technology is visible and the process is not. You can see the software. You can demo it. You can get a quote for it. The process conversation is harder - it requires sitting with your team and admitting that the current way of working is the actual problem. That conversation is uncomfortable. The software purchase feels like progress.

It rarely is. Not yet.

What Process Actually Means

Process is one of those words that business owners either over-engineer into a compliance exercise or dismiss entirely as bureaucracy. Both responses miss the point.

A process is simply an agreed, repeatable way of doing something that produces a consistent outcome. It has a sequence. It has clear roles and accountabilities. It has defined inputs and outputs. It has a quality standard and a way of knowing when that standard is not being met.

Most SMEs do not have well defined processes. They have activities - held together by tribal knowledge. The three people who know how things actually work. The workarounds that have accumulated over years. The institutional memory that lives in someone’s head and walks out the door when they resign.

When you implement technology on top of tribal knowledge, you do not eliminate the tribal knowledge. You hide it inside the system, where it is harder to find, harder to fix, and far more expensive to change.

The businesses that get the most from technology are almost never the fastest to adopt it. They do the unglamorous work first - mapping how work actually flows, agreeing on who does what, establishing the standards that make consistency possible. Only then does technology have something real to scale.

The Honest Truth About ERP

Enterprise resource planning systems have been the backbone of business operations for decades. And they deserve credit for what they genuinely do well - integrating transactional data across functions, creating traceability, imposing a discipline of record-keeping that manual systems cannot match. Definitely not at scale.

But there is an honest conversation about ERP that the industry rarely has, and that most vendors actively avoid.

The user interface and user experience of most ERP systems is, to put it plainly, poor. Not poor by the standards of thirty years ago - poor by the standards of today. The underlying database structures are clunky. The application layer that users interact with has changed remarkably little since these systems were first designed. The logic that governs how information flows between modules was built for a world of desktop terminals and batch processing, and it shows.

Here is the uncomfortable truth: the green screen software of the 1980s and 1990s was in some respects more usable. It was focused, relatively simple, functional, and unambiguous. It did a small number of things and it did them clearly. The modern ERP, by contrast, attempts to do everything - and in doing so has become a system that requires significant training to navigate, generates significant resistance from the people who are supposed to use it, and produces workarounds that undermine the very integration it was designed to create.

The deeper architectural problem is this: ERP was designed around functions, not workflows. It manages data within departments reasonably well. It manages the flow of work between departments poorly. Sales hands to production. Production hands to warehouse. Warehouse hands to despatch. Finance sits across all of them. In theory, the ERP connects these functions. In practice, the handoffs between them are where errors accumulate, omissions occur, and the promised efficiency disappears into the gap between modules.

Rather than improving interdepartmental alignment, a poorly configured ERP often makes it worse. Each department sees its own module clearly. Nobody sees the whole. The data exists. The workflow intelligence does not.

What the Last Decade Actually Changed

While ERP architectures remained largely static, the world around them moved dramatically.

The internet arrived at the coalface. eCommerce created direct channels to customers that bypassed traditional order processes entirely. Mobile and portable devices put real-time data entry in the hands of people on the floor, in the field, and on the road - people who were never going to sit at a desktop terminal to log a transaction. Customers began expecting visibility into their orders, their deliveries, and their account status at any hour.

None of this was designed into the original ERP architecture. It was bolted on. Web portals. Mobile apps. API integrations with third-party platforms. Each addition extending the system further from its original logic, adding complexity, and creating new seams where errors could enter.

The result, for many SMEs, is a technology stack that has grown organically over a decade into something that no single person fully understands. The ERP sits at the centre. Around it orbits a constellation of tools, plugins, manual extracts, and spreadsheet bridges that together constitute what the business optimistically calls its systems.

AI: The Elephant in the Room

Into this environment arrives artificial intelligence - positioned by every vendor, consultant, and technology publication as the solution to the problems that ERP created and the decade of bolt-ons compounded.

AI copilots. Agentic tools that execute tasks autonomously. Workflow automation that eliminates manual steps. Predictive analytics that surface decisions before they become urgent.

The promise is real. The risk is significant.

Because AI sits directly on top of your process layer and your data layer. It does not think. It executes patterns. It identifies what has happened before and extends it forward - with a speed and consistency that no human team can match. Which is extraordinary when the underlying patterns are sound. And catastrophic when they are not.

Poor inventory logic, automated by AI, produces stock-outs and overstocking at scale - faster than any manual process could manage. Weak customer qualification criteria, handed to an AI lead generation tool, produces high volumes of low-quality prospects pursued at significant cost. Undefined pricing rules, fed into an automated quoting system, deliver inconsistent margins to every customer, every time, without a human ever noticing until the monthly accounts arrive.

And here is the structural problem that almost nobody is saying out loud: AI is being asked to provide the cross-functional workflow intelligence that ERP never delivered. To bridge the gaps between departments that ERP made visible but never resolved. To create alignment across functions that the underlying architecture was never designed to support.

AI does not fix the architecture. It adds another layer on top of it.

The seams are still there. The handoffs are still fragile. The tribal knowledge is still hiding in the gaps. The AI simply executes across all of it - including the broken parts - at a speed that makes the errors harder to catch before they have already caused damage.

Why Owners Skip the Process Work

It is not ignorance. Most business owners who skip process work and go straight to technology understand the risk intellectually. They skip it anyway, for reasons that are entirely human.

Process work is slow. It requires sitting with the people who do the actual work and listening carefully to how things currently happen - including the parts that are embarrassing, inefficient, or contradictory. It produces flowcharts and checklists, which feel far less impressive than a new system dashboard.

Technology feels like progress. There is a go-live date. The system is either live or it is not. Process improvement is never definitively done, and that ambiguity makes it easier to defer.

There is also a cultural factor in many owner-led businesses. The people who are valued are the firefighters - the ones who solve problems fast and work around any obstacle. The patient, methodical work of designing a system that does not need firefighting is less visible and less celebrated. Until the system goes live and the fires start burning at a scale that no individual can contain.

The Sequence That Works

The businesses that implement technology successfully - and get the return they were promised - follow a sequence that is less exciting and consistently more effective.

They start with process clarity. They map how work actually flows, assign clear ownership, and define what good looks like before any system is asked to measure it. Every gap in the map is a gap in organisational understanding that technology will eventually expose.

They build process discipline next. Consistent execution. Training that covers the underlying logic, not just the software steps. Basic measurement so the team knows whether the process is working before the technology arrives.

Only then do they implement technology - as an enabler of a process that already works, not a replacement for one that does not. ERP to structure and integrate the transactional layer. Mobile and internet-enabled tools at the point where work actually happens. Reporting that confirms what the team already knows.

And only once the data is clean, the processes are stable, and the team understands the logic does AI enter the picture. Layered onto proven processes, these tools deliver exactly what they promise. Layered onto anything else, they deliver exactly what we have described.

First, make the work work. Then let technology scale it.

Before You Buy

The most valuable conversation you can have before any technology investment is the one most businesses skip. Run through these questions honestly for the specific function you are considering:

Do we have a clear, documented workflow for this? Does everyone who touches this process perform it the same way? When errors occur, do we understand why - or do we just correct them and move on? Could a new team member execute this without leaning on someone who has been here for years? Are the decision rules explicit, or do they live in experienced heads?

If the honest answer to most of those is no, you are not ready for technology. You are ready for process work.

The technology will wait. It will be better, cheaper, and more capable in twelve months than it is today.

The process work, done well, will not.

Your Wednesday question:

Pick one system in your business that has underdelivered on its promise. Before blaming the system, ask what process it was implemented on top of - and whether that process was actually ready. That is where the real answer lives.

Working With Frank

Frank Choy is a Commercial Adviser and founder of Capstone Consulting, working with SME and family business owners across manufacturing, food and beverage, trades, and professional services.

Frank works alongside business owners and their management teams through technology transitions - helping design and document the process layer before implementation begins, and advising on the management conversations needed to build genuine adoption after go-live.

Getting the sequence right - process first, technology second - is one of the highest-return investments a growing business can make. Frank’s methodology, The Engine Room Method, is built on exactly that principle.

To explore how to prepare your business for its next technology step, connect with Frank on LinkedIn