ERP investment is not a small decision. For most Indonesian SMEs, it's one of the larger technology investments they'll make. Which means someone — the owner, a board member, a finance director, or an investor — is going to ask hard questions before signing off. If you're still getting clear on what ERP is and how it works, that context helps before diving into the business case structure.
A good business case answers those questions before they're asked. Here's how to structure one that actually works.
Who You're Writing This For
The business case structure depends on who's reading it.
If you're writing for an owner-founder who controls the budget directly, the case is often simpler. You need to connect the investment to real pain they already feel, show a credible cost and timeline, and give them confidence in the outcome. Founders make decisions faster when they recognize the problem as their own.
If you're writing for a board or investors, you need to be more formal. Quantified benefits, ROI estimates, risk analysis, and implementation governance matter more.
If you're writing for a finance director who controls budget approval, the numbers need to be rigorous. They'll look hard at the cost side, the assumptions behind the savings estimates, and whether the benefits are realistic.
Know your audience before you write a single word.
The Structure That Works
1. Current State: What's Actually Broken
Start with the pain, not the solution. This section needs to be specific and honest.
Don't write "our current systems are inefficient." Write "month-end close takes 8 working days because finance manually reconciles data from three separate spreadsheets. This delays our reporting to the board by almost two weeks every month."
Specific examples make the problem credible. If you can quantify the pain, do it:
- How many hours per week does manual data entry consume? Multiply by headcount and average salary cost.
- How often do you have stockouts or overstock situations? What does each incident cost?
- How long does it take to answer "how much do we owe suppliers this month" or "what's our gross margin this week"?
- When did a missed invoice last cost you real money?
You don't need perfect data for this section. Reasonable estimates with clear assumptions are fine. The point is to anchor the case in real operational experience, not theoretical efficiency gains.
2. Proposed Solution and Scope
Describe what you're actually proposing to implement. Be specific about scope — which modules, which locations, which business processes.
This section should also address what's out of scope. If you're only implementing finance and inventory in phase one, say so. Undefined scope is one of the biggest sources of cost overruns and stakeholder disappointment.
Include a brief description of why this approach was selected over alternatives. If you evaluated Odoo or a different packaged solution before recommending a custom build, explain the reasoning.
3. Expected Benefits
This is where most business cases go wrong. They list abstract benefits like "improved efficiency" and "better decision making" without connecting them to anything measurable.
Better approach: go back to the specific problems in section one and describe how the proposed system addresses each of them.
- Month-end close from 8 days to 1-2 days (based on comparable implementations) — frees up finance staff for analysis rather than data assembly
- Inventory accuracy from approximately 70% to 95%+ — reduces stock write-offs and prevents lost sales from stockouts
- Payroll processing from 3 days to half a day — with full audit trail for BPJS and PPh 21 compliance
Where you can convert time savings to money (hours × salary cost), do it. Where you can't, be honest that the benefit is operational and qualitative rather than a specific cost reduction.
Don't inflate the numbers to make the case look better than it is. Stakeholders who've seen business cases before will sense it, and it undermines your credibility on the rest of the document.
4. Cost Estimate
Include everything:
- Implementation cost — development, configuration, testing, data migration, training
- Ongoing costs — hosting, maintenance, support, future enhancements
- Internal time cost — staff time required for requirements, UAT, training, go-live support
For custom ERP, there's no licensing fee — that's worth calling out explicitly as a long-term advantage compared to SaaS alternatives.
If you're working with an implementation partner, get a real quote range before including it in the business case. Presenting a number that changes significantly later damages credibility.
5. Risks and Mitigations
Every implementation has risk. Acknowledging this in the business case is a strength, not a weakness. The risks that matter:
- Timeline risk — scope changes and client-side unavailability are the most common causes of delays. Mitigation: fixed scope per phase, designated internal owner with protected time.
- Adoption risk — users don't actually use the system. Mitigation: involve key users in design and UAT, not just training.
- Data quality risk — migrating dirty data creates problems from day one. Mitigation: data audit and cleanup before migration.
- Business disruption at go-live — cutover to a new system is always a risk. Mitigation: parallel run period, rollback plan, hypercare support for the first month.
6. Timeline
Give a realistic implementation timeline with phases. Don't promise a go-live in 6 weeks to make the case look easier — it won't happen, and you'll lose credibility.
A typical Indonesian SME ERP implementation runs 3-6 months depending on scope. Breaking it into phases (phase 1: core finance and inventory; phase 2: procurement automation and HR) makes the investment feel more manageable and lets you demonstrate value earlier.
7. Recommendation
Summarize the case in 3-4 sentences. What do you recommend, what does it cost, and what's the expected outcome?
Don't bury the recommendation at the end after 20 pages. State it clearly at the beginning as an executive summary, then support it with the detail below.
The Most Common Business Case Mistake
The weakest business cases anchor on potential benefits — "imagine if we could see our inventory in real time" — without connecting those benefits to real pain the business is experiencing today.
The strongest business cases start from documented, specific problems that the decision-maker already recognizes as real. When stakeholders read the current state section and think "yes, that's exactly what's costing us," the rest of the case writes itself.
ERP investment makes sense when it solves a real problem the business has today. If the problem is real, the case is straightforward. If you're struggling to articulate the pain, the timing might not be right yet.
CERIS helps businesses assess whether ERP is the right investment for where they are now. See what we build or reach out if you want a direct conversation about it.
