Business Process Design: Why Better Software Won't Fix Broken Processes
When something isn't working, the instinct is often to blame the system.
The ERP is too slow. The CRM isn't flexible enough. The payroll software can't do what we need. The document management system feels clunky. The project management platform doesn't suit the business.
So, the search begins for new software.
Yet, after months of evaluation, implementation, training, and significant investment, the same frustrations often return. The reports are still inconsistent. Workflows remain inefficient. Staff continue creating workarounds.
The business concludes that the new system isn't good enough. In reality, the problem may never have been the technology.
"Technology exposes process maturity. It rarely creates it."
The most successful organisations understand a simple truth. Systems support processes. They should not define them.
Every System Is Built Around Assumptions
Every software platform is designed with a particular way of working in mind.
Accounting systems assume financial disciplines. CRM platforms assume structured sales processes. HR systems assume consistent employment practices. Project management tools assume defined workflows. Document management platforms assume governance around information.
When businesses attempt to force software to replicate every historical process, they often create unnecessary complexity.
Instead of asking, "How should this process work?", they ask, "How do we make the software behave exactly like our old spreadsheet?"
Those are very different questions.
"If your first requirement is to make the new system behave like the old one, you may not need a new system. You may need a new process."
The Customisation Trap
Software vendors often promote flexibility. And flexibility is valuable. But flexibility should not be confused with unlimited customisation.
Every customised workflow, bespoke report, unique integration, or modified screen increases complexity.
Initially, those changes appear harmless. They solve immediate operational frustrations. Over time, however, they create technical debt.
Each modification becomes something that must be maintained, tested, documented, and understood. The organisation slowly builds a system that only it fully understands.
"Customisation should solve strategic problems, not preserve historical habits."
The more a business customises its systems, the further it moves away from the vendor's standard product, and the more difficult future change becomes.
Complexity Has a Long-Term Cost
Customisation is rarely a one-time expense. It creates an ongoing commitment. Software upgrades become more complicated because custom functionality must be tested or rebuilt. Vendor support becomes more limited because the business is no longer operating the standard solution. Integrations become more fragile.
Future improvements take longer because every change affects something else. The business becomes increasingly dependent on the people who understand how the customisations work.
What started as an efficiency improvement quietly becomes an operational risk.
"Every customisation has an implementation cost. Many have a lifetime cost."
Those lifetime costs are often invisible during the initial business case.
Processes Should Challenge the Business Too
Not every inefficient process should be automated. Sometimes it should be eliminated. Growing businesses often attempt to digitise poor processes instead of redesigning them. Approval workflows with six signatures become digital approval workflows with six signatures. Manual reconciliation becomes automated manual reconciliation. Duplicate data entry simply occurs faster.
Technology has improved the speed. It has not improved the process.
"Automating an inefficient process simply allows inefficiency to happen more quickly."
Before selecting software, organisations should ask whether the process still deserves to exist. That conversation often creates far greater value than the technology itself.
Key-Person Risk Increases with Complexity
One of the least discussed consequences of excessive system customisation is knowledge concentration. Eventually, someone becomes the expert.
They know why a particular workflow exists. They understand which integrations cannot be touched. They remember why certain exceptions were created years ago.
Over time, the business becomes dependent on their knowledge. When they are unavailable, even routine changes become difficult. If they leave, the organisation inherits a system that nobody fully understands.
"When your system only makes sense to one person, your business has inherited a risk, not an asset."
This is not simply an IT issue. It is a governance issue.
This Problem Exists Everywhere
While ERP implementations often receive the most attention, this challenge is not limited to enterprise software. It appears across almost every operational platform.
Customer relationship management systems become overloaded with unnecessary fields and workflows. Payroll systems carry years of legacy award interpretations that nobody questions. Procurement platforms mirror outdated approval structures that no longer reflect organisational responsibilities. Document management systems become labyrinths because folders replicate decades of historical filing practices.
Even simple spreadsheet models evolve into highly customised operational systems that only one employee understands.
The pattern is always the same.
Rather than simplifying the way work is performed, technology inherits every inefficiency that already existed.
"The platform changes. The complexity remains."
Standardisation Creates Capability
There is a reason successful software vendors encourage businesses to adopt standard functionality wherever possible.
Standard processes are:
Easier to understand.
Easier to train.
Easier to support.
Easier to improve.
Easier to upgrade.
More importantly, they reduce organisational dependency on individuals.
Standardisation does not mean abandoning what makes your business unique. Your competitive advantage should come from how you serve customers, develop products, and create value. It should not come from maintaining highly customised software that nobody else can support.
"Competitive advantage should exist in your business model, not in your software modifications."
Design Processes for the Business You Are Becoming
Growing businesses often customise systems to solve today's frustrations. The better approach is to design processes that support tomorrow's organisation.
Ask:
Would we design this process this way if we started again today?
Does this approval step reduce risk or simply preserve history?
Is this exception genuinely necessary?
Could a new employee understand this process without relying on one expert?
These questions shift the conversation from software configuration to organisational capability. That is where sustainable improvement occurs.
Final Thoughts
Technology is one of the greatest enablers of growth. But it cannot compensate for poorly designed processes. Nor should it be expected to preserve every historical way of working.
The organisations that achieve the greatest return from technology investments are those willing to simplify before they automate, standardise before they customise, and challenge existing practices before embedding them into new systems.
"The best systems are built around great processes. Great processes are not built around systems."
Before approving the next software implementation, ask a different question.
Are we solving a systems problem? Or are we trying to automate a process that should have been redesigned in the first place?
The answer may save far more than the cost of the software.
It may determine whether the business becomes simpler or significantly more complex.
Need Support?
If your organisation is considering new software, a major upgrade, or significant system customisation, take the opportunity to review the underlying processes first.
At Ordinis Advisory, we help growing businesses simplify operating models, strengthen governance, and ensure technology investments support long-term capability rather than embedding unnecessary complexity.
If you're planning your next systems project, let's have a conversation before configuration begins.
Disclaimer
This article is general in nature and does not constitute technology, financial, operational, or professional advice. You should consider your organisation's specific circumstances and seek appropriate advice before implementing significant process or system changes.
Comments