Why Your RM500K System Still Runs on Excel

You approved the budget. Half a million ringgit — maybe more. A proper enterprise system. ERP, CRM, integrated dashboards, automated workflows. The vendor's presentation was immaculate. The board was convinced. IT signed off. The project kicked off with a town hall and a Gantt chart.

Eighteen months later, the system is live. And every Monday morning, your operations manager still emails an Excel file to three department heads. Your sales team tracks their pipeline in Google Sheets. Finance runs their month-end reconciliation in a spreadsheet they've maintained since 2019.

The RM500K system is running. But so is Excel. And if you're being honest, Excel is winning.

The System Was Bought, Not Designed

Most enterprise system purchases in Malaysia follow the same pattern. A vendor gives a compelling demo. Management is impressed by the brand name, the feature list, the reference clients. A decision is made at the executive level. A contract is signed.

At no point does anyone sit down with the people who will actually use the system every day and ask: how do you actually work?

No business process mapping. No workflow analysis. No observation of how data actually flows between departments. No understanding of the workarounds, the informal approvals, the tribal knowledge that keeps operations running.

The system is selected based on what it can do in theory. Not based on what the business actually needs it to do in practice.

The result is predictable. The system doesn't match how people work. It's clunky where they need speed. It's rigid where they need flexibility. It requires six clicks for something that took one formula in Excel. So they go back to what works. They open a spreadsheet.

Customization That Digitizes Inefficiency

When staff complain that the new system doesn't work the way they need it to, the vendor offers customization. This sounds like progress. It isn't.

Because what typically happens is this: someone from the business says "make it follow exactly how we do things now." The vendor nods, documents the existing process — however messy, manual, or redundant it is — and replicates it inside the enterprise system.

This is the customization trap. The vendor replicates legacy forms, manual approval chains, and old Excel logic — exactly as they are — instead of asking whether those processes should exist in the first place.

Nobody stops to ask: why does this approval require three signatures? Nobody questions whether the five-step procurement workflow could be two steps with the right system design. Nobody challenges the monthly report that takes two days to compile because it was designed around Excel's limitations, not the business's actual needs.

The vendor isn't incentivised to simplify. They're paid to build what's requested. And what's requested is usually "make it work like it works now, but digital." That's not transformation — that's a very expensive photocopy.

Every Department Wants Their Own Version

Here's where it gets worse. Once the system is live and customization begins, every department pulls in a different direction.

Sales wants a pipeline view with their specific deal stages, custom fields for client relationships, and a dashboard that shows conversion rates the way their VP likes to see them. Finance wants strict approval hierarchies, audit trails for everything, and reports formatted to match their existing templates. Operations wants scheduling tools, inventory views, and real-time status boards that reflect how their warehouse actually runs.

Each department is right about their own needs. But the system was never architected to serve all of them coherently. So the customizations start conflicting. Data models get stretched. The same "customer" means something different in Sales versus Finance. Reports break because one department changed a field that another department depends on.

The punchline writes itself: Excel becomes the common meeting point. It's the one tool every department trusts, every department knows, and every department can bend to their will without filing a change request. The RM500K system becomes the system of record that nobody actually records in first.

Customization Isn't the Enemy — Lack of Governance Is

Let's be clear: customization itself isn't the problem. Every business has legitimate unique needs. A logistics company in Johor has different workflows from a fintech startup in KL. Cookie-cutter systems rarely survive contact with reality.

The problem is customization without governance. Without a clear framework for what should be customized, what should be standardised, and who decides — you get chaos dressed up as configuration.

Smart customization differentiates your business. Bad customization preserves your business's worst instincts in expensive software. The difference isn't budget or technology — it's governance. Someone needs to be empowered to say: "No, we're not replicating that broken process. We're fixing it."

What Actually Works

If you've recognised your own organisation in the paragraphs above, the path forward isn't another system purchase. It's a fundamentally different approach to how you think about technology and process.

The Spreadsheet Isn't the Problem

When your staff opens Excel instead of your enterprise system, they're not being difficult. They're being rational. They're choosing the tool that actually helps them do their job over the tool that was chosen for them by someone who doesn't do their job.

The spreadsheet isn't the disease. It's the symptom. The disease is a system that was bought for its branding, configured to replicate broken processes, fragmented by competing department demands, and deployed without the governance to keep it coherent.

Fix the disease, and the spreadsheets will close themselves.