The symptom trap
Client calls: "We need a custom field to track delivery delays."
Most consultants: "Sure, we can build that."
Us: "Why are you having delivery delays?"
That question changes everything.
Because the request isn't the problem. It's a symptom. And if you treat symptoms without finding the root cause, you waste time and money building things that don't fix anything.
What symptom fixing looks like
Company has late deliveries. So they:
- Add a field to track delays
- Create a report showing delay trends
- Build a dashboard with delay metrics
- Set up alerts when delays happen
Six months later: Still having late deliveries. But now they have excellent documentation of how late everything is.
The symptom got treated. The problem didn't.
Why this happens
Because treating symptoms is easier than finding root causes.
Building a custom field takes two days. Finding out why deliveries are late takes two weeks of uncomfortable conversations.
Nobody wants to hear that:
- Sales is promising delivery dates before checking inventory
- Warehouse isn't updating stock levels in real time
- Purchasing isn't reordering fast enough
- Management set unrealistic lead times to win deals
It's easier to build tracking tools than to fix broken processes.
So we track symptoms instead of solving problems.
Real example: The inventory problem
Client calls. "We need better inventory visibility. Build us a custom inventory dashboard."
We dig deeper.
The real problem: They're running out of stock on their best-selling items while sitting on six months of dead inventory.
Why?
- No minimum stock levels set in the system
- Purchasing orders based on gut feel, not data
- Sales team doesn't check stock before promising delivery
- Returns aren't being put back into inventory properly
The dashboard they wanted would show the problem clearly. But it wouldn't fix anything.
What actually fixed it:
- Set minimum stock levels for all active items
- Created automatic reorder points
- Made stock checks mandatory before confirming orders
- Fixed the returns process to update inventory immediately
No custom dashboard needed. Just fixing the broken processes.
Real example: The reporting problem
Client: "Finance takes two days to generate month-end reports. Build faster reports."
We ask: "Why does it take two days?"
Answer: Because they're manually exporting data from five different systems, reconciling in Excel, fixing errors, and reformatting.
The real problem isn't slow reports. It's disconnected systems and manual processes.
What they actually needed:
- Real integration between systems (not Excel exports)
- Automated reconciliation rules
- Single source of truth for financial data
- Real-time dashboards so month-end isn't a surprise
Faster reports would save time. Fixing the process eliminated the problem entirely.
Real example: The customization spiral
Company has 200+ custom objects in Business Central. System is slow. Upgrades break things. Maintenance is expensive.
Their solution: "Build more custom code to make the existing custom code work better."
We ask: "Why was each customization built?"
Turns out:
- 40% duplicate standard functionality people didn't know existed
- 30% work around broken processes
- 20% were built for people who left the company
- 10% actually add value
The symptom: System is slow and hard to maintain.
The root cause: Building customizations instead of fixing processes.
What actually fixed it: Delete 90% of custom code. Fix the processes. Use standard functionality properly.
How to find root causes
Ask why. Then ask why again. Then keep asking until you hit something that isn't another symptom.
Example conversation:
"We need a field to track customer complaints."
Why do you need to track complaints?
"Because we're getting too many."
Why are you getting too many complaints?
"Because deliveries are late."
Why are deliveries late?
"Because production is behind schedule."
Why is production behind schedule?
"Because materials arrive late."
Why do materials arrive late?
"Because we don't order until we run out."
Now we're at the root cause: Reactive ordering process.
The field they asked for wouldn't fix anything. Fixing the ordering process fixes everything.
The five symptoms we see everywhere
1. "We need better reporting"
Usually means: We don't trust our data, our processes are broken, or we're measuring the wrong things.
Fix the data quality and process first. Then reporting is easy.
2. "We need more automation"
Usually means: We're doing too much manual work because our processes are inefficient.
Fix the process first. Then automate the good process, not the broken one.
3. "We need custom fields"
Usually means: We're trying to track something that shouldn't need tracking, or standard fields exist but people don't know about them.
Challenge why the data is needed. Often it's not.
4. "We need better integration"
Usually means: We have too many systems because we bought solutions instead of fixing processes.
Consolidate systems first. Then integrate what's left.
5. "Users aren't adopting the system"
Usually means: The system doesn't match how people actually work, or the process is broken.
Fix the process to match reality. Then train on the system.
Why consultants don't do this
Because it's uncomfortable.
Telling a client "your process is broken" is harder than saying "sure, we can build that custom field."
Finding root causes means:
- Challenging what people tell you
- Asking uncomfortable questions
- Exposing organizational problems
- Saying no to requested features
- Taking longer before you start building
Most consultants avoid this. They build what's asked for, collect their fee, and leave before the client realizes nothing actually improved.
What root cause consulting looks like
Client asks for feature X.
We ask why they need it.
We dig until we find the actual problem.
Often the solution is completely different from what they asked for.
Sometimes the solution is deleting things, not building them.
Sometimes the solution is process change, not software change.
And sometimes - rarely - what they asked for is actually what they need.
The result
Projects that actually fix problems instead of documenting them.
Systems that get simpler instead of more complex.
Clients who can explain exactly why each feature exists.
ROI that's measurable because we fixed the thing that was costing money.
Do you recognize these symptoms?
If your ERP project is:
- Getting more complex over time
- Adding features that don't seem to help
- Creating more reports without solving problems
- Building customizations to work around other customizations
- Expensive but results are unclear
You're treating symptoms, not solving problems.
What we do differently:
- Start with why, not what
- Challenge every request until we find the root cause
- Say no to features that treat symptoms
- Fix processes before writing code
- Measure results by problems solved, not features built
We don't bill by the hour. We don't get paid more for building more. We get paid to fix what's actually broken.
Ready to stop treating symptoms?
Book a call - we'll tell you what's actually broken.