New System, Same Problems
Digital Services Depends on Rethinking Platforms, Not Repeating the Past
Walk into almost any council building and you’ll hear it: “We’ve been with the same system for over a decade.” “Our payroll has always run on this software.” “We’ve used the same finance suite since amalgamation.” These aren’t strategy statements. They’re security blankets. Familiar lines that make continuity sound like intent.
But that comfort hides something deeper and more dangerous. It is a confusion between loyalty and leadership. Between having software, and having a strategy. It papers over the fact that most core processes haven't evolved, and neither has the citizen experience. Staff are still buried in manual approvals. Spreadsheets still drive planning. Residents still wonder why basic services are so hard to access online. Or why, when they are, they still feel like a maze.
And so, without realising it, councils have allowed their vendor relationships to stand in for critical thinking about how their organisations actually work. Or should, at least. Large swathes of the sector have come to mistake the presence of technology for the practice of transformation. As if saying what system you use is the same as designing the future.
It’s not. And never was.
What began as a practical investment in systems of record for payroll, property, and payments has slowly hardened into default thinking. ERP didn’t just anchor operations. It began to shape the entire conversation. System upgrades became stand-ins for reform. New modules were sold as innovation. Councils have allowed operational compliance systems to define their entire digital ambition.
And that’s the real problem.
ERP systems weren’t built to modernise government. They were built to stabilise it. To close the books. Pay the staff. Track the assets. Let’s not quibble. These are essential functions. But they are not transformative ones. They don’t improve the resident experience. They don’t reshape how services are delivered. They don’t empower employees to work differently. And yet, ERP remains the lens through which most councils still view transformation.
Not because it’s strategic. But because it’s familiar.
No resident ever said, “This council feels modern because their finance module reconciles faster.” No employee ever loved their job more because the leave balance screen moved to the cloud.
But that’s still where most digital investment goes. Toward internal systems, compliance upgrades, and marginal improvements to processes that were never the problem to begin with.
It’s as if cloud-hosted compliance has become the peak of ambition. Meanwhile, CIOs and IT Managers are swamped with stakeholder project lists that grow longer by the month. Yet most can’t be delivered meaningfully because the architecture can’t support the change those projects demand.
Outside the government bubble, digital has moved on. Airlines don’t win loyalty with flashy websites. Banks aren’t modern because they have CRMs. Retailers aren’t efficient because they upgraded their ledger. These sectors have rebuilt around orchestration, observability, real-time insight, and embedded intelligence. Their systems anticipate, adapt, resolve issues before the customer even notices.
They are invisible because they work.
And that’s the real shift. The best digital services don’t call attention to themselves. They remove friction. They just deliver. That’s the standard now. But local government isn’t building for that standard. It’s still buying upgrades and calling it strategy.
The private sector didn’t get there by luck. It got there because it had to. Airlines (and the underlying agent ecosystems that once supported them) that didn’t modernise lost bookings. Banks that didn’t simplify access lost customers. Retailers that clung to clunky inventory systems didn’t survive. Digital transformation became an existential requirement. Not modernise or die. Modernise or become irrelevant.
Local governments have never faced that kind of pressure. They’re protected by legislation. Residents don’t get to choose their council. A permit is a permit. A rate notice is a rate notice. And as long as those obligations are technically met, councils survive.
But survival is not the same as evolution. And the absence of competitive pressure has led to the dangerous assumption that digital transformation is optional. It’s not. It hasn’t been for years. And now they're being judged by a standard they didn’t choose but can’t ignore.
Because residents aren’t comparing your council to the one next door. They’re comparing you to their bank. To Apple. To the airline app that shows their baggage moving in real time. To the parcel tracker that tells them where a box is in Shanghai and when it will land in Shepparton.
And here’s the thing. Those expectations aren’t unrealistic. They’re entirely reasonable because the technology that makes them possible is already in play. It’s not science fiction. It’s not enterprise-only. It’s the architecture of the modern digital experience. Available. Accessible. Proven.
Which makes the gap even harder to defend. Because it’s not a capability problem.
It’s a decision problem.
Citizens now expect self-service that works the first time. They expect updates without having to ask. They expect systems that feel invisible because they don’t fail. For decades, they never cared what software their council used. But technology decisions are no longer internal matters. They now define the public experience. The system is the service. And when that system underdelivers, it’s not the vendor who loses trust, it’s the council.
Which is why brand-centric thinking is no longer harmless. It’s a liability. It traps councils in the wrong conversation. What vendor do we use? What module can we bolt on? What roadmap feature should we hold out for?
None of those questions drive real change. The right conversation starts somewhere else entirely. What part of the business needs to change? And how would we know if it had?
That’s where outcome metrics become critical. Not vendor dashboards. Not system usage stats. But lived internal indicators. How many hours to onboard a new staff member? How long to resolve a planning application? How often does a resident call twice for the same issue? Those are the metrics that matter. Because those are the moments that shape trust.
And they’re also the metrics that ERP systems were never designed to move.
Take service resolution. If your complaints process still bounces between departments, if systems don’t share histories, if customers aren’t updated, no module will fix that. That’s not a system feature problem. That’s a workflow problem. A data problem. An architectural problem. And architecture isn’t a feature. It’s a design decision.
Or take automation. If your finance team is still manually routing invoices, downloading spreadsheets, and reconciling across platforms with incompatible data models you haven’t digitised. You’ve just made the manual labour digital.
True automation means business logic abstracted from code. It means changes that don’t need vendor intervention. It means systems that evolve with you not six months after you raise a ticket.
And that’s not an ERP conversation. It’s a platform one.
This is why PaaS (Platform-as-a-Service) matters. Because it puts councils back in control. Of workflows. Of data. Of service design. It breaks the dependency on monolithic systems and vendor-defined roadmaps. It enables shared data models, reusable components, flexible integrations. It lets councils design for the real world, not just configure within constraints.
But even the best-designed system won’t deliver if you can’t see how it’s performing.
That’s where observability comes in. The ability to track performance in real time, detect failure before users do, and continuously improve. In high-functioning digital environments, observability isn’t optional. It’s expected. Industries rely on tools like Datadog, Splunk, Dynatrace, and New Relic not for trendiness, but because they make complexity manageable and failure visible.
Local government still lags behind. Not just in tooling. In mindset.
System issues are still found through complaints, not alerts. Downtime is still tolerated as long as the core system kept running. Payroll ran? Then the system “worked.”
But no one asks whether the resident experience held together. Or whether staff had to patch things up manually behind the scenes.
In one council I worked with, it took observability to finally prove what everyone suspected. A critical parking integration had been quietly failing for months. Until then, the vendor actively and aggressively denied it. The council doubted it. But the citizens knew. Once the data was irrefutable, the conversation shifted. It was no longer a technology debate. It was a business resolution. The fix came fast. The ROI came faster.
This is the missing piece in most local government tech strategies. It’s not just about building better systems. It’s about knowing whether those systems are doing what you say they do.
And let’s stop pretending this kind of transformation is a “big council” luxury. It’s not.
Small IT teams don’t need less automation. They need more. They don’t have time for manual triage, workaround scripts, or chasing vendors for fixes. They need environments that support them and architectures that reduce complexity, not systems that multiply it.
The irony? The same tools billion-dollar banks use to lower overhead are exactly what small councils need to survive with three techies and a constrained budget. Not because they’re aiming for scale. But because they have no margin for waste.
To get there, councils have to let go of the dangerous illusion that software is strategy. That a system upgrade is transformation. That progress is measured in project completions, not service outcomes.
It’s not about running more projects. It’s about making different decisions. And that starts with architecture. Not as a buzzword. As a discipline. Because without it, every dollar spent is just a newer version of the same limitation.
So what can you actually do about it?
Once you’ve seen the pattern, things like projects piling up, systems stuck, and residents frustrated, it’s tempting to reach for another upgrade. Or revisit the vendor roadmap. But those are the same moves that got us here. What’s needed isn’t another product. It’s a new way of thinking about the problem.
You need a way to cut through the noise. To see where the real pain is. What processes are broken. What systems are slowing you down. Where effort is wasted. Where the friction lives. You need a clear, practical lens that connects business outcomes to architectural decisions.
That’s where a Business Impact Matrix comes in.
It’s not a wishlist. It’s not a vendor evaluation. It’s a simple, structured way to surface what matters. Function by function, and outcome by outcome. It lays out the changes you want to see, the processes involved, the systems in play, and the level of manual effort or fragmentation you’re dealing with. It shows you where data is stuck, where integration fails, and where automation could actually make a difference.
It doesn’t give you a product shortlist. It gives you something far more useful: a map of pain. And with it, a map of opportunity.
Because once you can see the real constraints, like onboarding that takes two weeks or more, service requests that bounce between departments, or budget planning stuck in disconnected spreadsheets, something shifts.
You stop asking “Which product has that feature?” And start asking the only question that matters. What capability do we need to build or buy to remove this barrier?
That’s strategy. Not brand preference. But here’s the problem...
Even when councils get to that point, when they see clearly that the issue isn’t the ERP module, but the architecture, many still don’t know what to do next. They recognise the gap. They understand that PaaS is the right direction. But they don’t know how to buy it.
Procurement language is still wired for the last generation. It’s built around systems, not services. Around modules, not capability. Around features, not flexibility. And because of that, the insight gets shelved. The recommendation gets buried. And the cycle resets.
Another upgrade. Another RFP. Another attempt to stretch an ERP suite into places it was never meant to go. Not because councils are resistant to change. But because the change they need doesn’t fit neatly into the frameworks they’ve always used.
This is the moment the conversation must shift. From choosing tools to designing environments. From asking what systems do, to asking what the organisation needs to become. From chasing logos, to building platforms that serve people.
Until that shift happens, transformation will keep falling short. Because you can’t buy your way out of an architectural problem with a transactional mindset.
The road ahead isn’t easy. It asks councils to do more than upgrade. It asks them to unlearn. To let go of decades of procurement-driven thinking. To stop rebranding the old as new. To build digital accountability. Because unlike broken footpaths, broken workflows don’t trigger inspections. But they should.
Digital services are now public infrastructure. Just as essential as roads, water, and waste. The difference is, their failures don’t leave cracks in the pavement. They leave gaps in trust. And by the time those gaps become visible, the damage is already done.
The future of local government won’t be defined by who upgrades their ERP first.
It will be defined by who stops waiting for a vendor roadmap and starts designing an environment their people actually need. Staff. Citizens. Communities. Everyone who depends on things just working.
So the next time someone in the room says, “We’ve always been a [vendor] council,” don’t nod. Ask them what they actually want to change. Because if that answer isn’t clear, the strategy isn’t either.