ERP
ERP Implementation Timeline: The Reality vs. The Sales Pitch
April 202510 min read
ERP
Every ERP vendor will show you a timeline slide. It looks clean: 3 months for design, 2 months for build, 1 month for testing, go-live. Total: 6 months. Real implementations — the ones I've been part of at Commsult Indonesia — look nothing like that. Studies show that fewer than 50% of ERP projects are completed on time, and the median implementation extends to 15.5 months, nearly double the typical vendor estimate for SMEs. This post breaks down why timelines slip, what the real phases are, and how to build a schedule that holds.
Vendors estimate timelines based on their best-case scenarios: clients who have clean data, engaged project teams, fast decision-making, and no scope changes. None of those conditions exist in the real world. Indonesian SMEs in particular face three timeline killers that vendors rarely account for: data quality problems in legacy systems (Excel files with years of inconsistent data), slow internal decision-making cycles (every requirement change needs four sign-offs), and part-time project team members who have day jobs on top of ERP duties.
A realistic ERP implementation has five phases, not three. Phase 1: Discovery and Requirements (4–8 weeks) — this is where you map every business process, audit your existing data, and define what Phase 1 scope includes. Phase 2: System Design and Configuration (6–12 weeks) — detailed design, database schema, UI wireframes, integration specifications. Phase 3: Development and Unit Testing (8–16 weeks) — actual build, including all custom logic and integrations. Phase 4: UAT and Parallel Running (4–8 weeks) — users test the real system with real data while still running the old system. Phase 5: Go-Live and Hypercare (4–6 weeks) — live deployment with intensive support. Each phase bleeds into the next, and problems discovered in Phase 4 send you back to Phase 3.
From my implementations: requirements gathering always takes twice as long as planned because stakeholders don't know what they want until they see a prototype. Data migration always hits unexpected quality problems — I've never seen a clean Excel import on the first attempt. User acceptance testing (UAT) always surfaces requirements that were not captured — real users doing real work find edge cases that workshops miss. Each round of UAT feedback adds 1–2 weeks of development and retesting. Parallel running — running old system and new ERP simultaneously — is often skipped to 'save time' and is the single most common cause of catastrophic go-lives.
Realistic ERP Timeline: Indonesian SME (30–100 staff, 3 modules)
Month 1–2 │ Discovery + Requirements
│ ● Process mapping workshops
│ ● Data audit (legacy systems)
│ ● Scope definition + sign-off
│
Month 3–4 │ System Design
│ ● Database schema
│ ● UI wireframes
│ ● Integration specs
│ ● Stakeholder design review
│
Month 5–7 │ Development
│ ● Core module build
│ ● Integration development
│ ● Unit testing
│
Month 8 │ Internal QA
│ ● Bug fixing sprint
│ ● Performance testing
│
Month 9–10 │ UAT (User Acceptance Testing)
│ ● Dept lead testing with real scenarios
│ ● Feedback → fix → retest cycles
│
Month 11 │ Parallel Running
│ ● Old system + ERP running simultaneously
│ ● Compare outputs daily
│ ← DO NOT SKIP THIS PHASE
│
Month 12 │ Go-Live + Hypercare
│ ● Hard cutover
│ ● Daily standups with dept champions
│ ● Issue log + resolution tracking
│
"Vendor estimate": 6 months ← (best case, ideal client)
"Reality": 12 months ← (typical Indonesian SME)From my experience implementing ERPs at Commsult: build your timeline backwards from a hard deadline if you have one (like a fiscal year start), then identify which phases have flex and which are fixed. Discovery and UAT are fixed — they cannot be compressed without destroying quality. Development can sometimes be parallelized across modules. Never compress parallel running; it's the only real safety net you have before full commitment.
For an Indonesian SME (30–100 employees) implementing HR leave management, AP with multi-level approval, and AR with automated reminders — three moderately complex modules — a realistic timeline is 9–12 months. Month 1–2: discovery, process mapping, data audit. Month 3–4: system design, UI prototypes, stakeholder sign-off. Month 5–7: core development. Month 8: internal QA and bug fixing. Month 9–10: UAT with department leads. Month 11: parallel running. Month 12: go-live and hypercare begins. Projects that compress this to 6 months typically do so by skipping the data audit, rushing UAT, and skipping parallel running — and then spend months 7–12 in crisis mode fixing what breaks.
# ERP Timeline Delay Analysis — Common Indonesian SME Patterns
Timeline killers and their typical delay impact:
┌──────────────────────────────────────────┬─────────────────┐
│ Cause │ Delay Impact │
├──────────────────────────────────────────┼─────────────────┤
│ Data quality worse than expected │ +4–8 weeks │
│ Stakeholder unavailable for sign-off │ +2–4 weeks │
│ Scope changes in month 5+ │ +4–12 weeks │
│ UAT reveals missed requirements │ +2–6 weeks │
│ Parallel running skipped → go-live fail │ +8–16 weeks │
│ Part-time project team (day job conflict)│ +6–10 weeks │
│ Integration partner delays │ +2–4 weeks │
└──────────────────────────────────────────┴─────────────────┘
Mitigation:
- Appoint full-time internal PM (not a dept head)
- Clean data BEFORE development starts
- Lock scope at Month 2 with signed change control process
- 100% attendance required for UAT sessions
- Never skip parallel runningInstead of a big-bang go-live where every module launches simultaneously, a phased rollout launches one module or department at a time. At Commsult, we went live with HR leave management first — it was the lowest-risk module, touched every employee, and built company-wide confidence in the system before finance went live. Accounts payable went live two months later. AR followed. Each phase had its own UAT and parallel running cycle. Total timeline was 14 months from kick-off to full AR go-live, but the business never experienced a catastrophic failure because each phase was small enough to contain.
I've seen three ERP go-lives timed to coincide with month-end financial closing. All three were disasters. The system is under maximum stress from batch jobs and report generation at exactly the moment your team has minimum tolerance for delays. Schedule go-live for the second week of the month, mid-year if possible. Give yourself a full business cycle (one complete month of operations) before any financial reporting period deadline.
Three things consistently accelerate ERP timelines: a full-time internal project manager (not a part-time department head), clean pre-migrated data (data cleaning done before development starts, not after), and pre-approved decision-making authority (the project lead can approve scope changes up to a defined limit without a 3-week approval chain). If you can deliver these three, you can meaningfully compress the timeline without sacrificing quality.
The most useful thing you can do before starting an ERP project is to present a realistic timeline to your board and get explicit approval — not just for the timeline, but for the resources it requires. A 12-month implementation means 12 months of disruption to your team's normal operations. It means a full-time internal project lead for 12 months. It means UAT sessions that pull department heads out of their day jobs for 2–4 weeks. Getting sign-off on these resource commitments upfront is what separates implementations that succeed from those that get quietly abandoned at month 8.