Failure looks the same every time
For a mid-market Indonesian company an ERP implementation runs somewhere between Rp 400 juta and Rp 1,5 miliar. Failure rarely means the software does not work. It means the system went live and the organisation did not follow: parallel spreadsheets return within six weeks, month-end close still happens in Excel, the warehouse keeps a paper book because the app is slower than writing, and reporting becomes a person copying numbers between two systems every Monday.
The tell is always the same. People build workarounds instead of raising issues. A workaround means somebody decided the system will not be fixed and it is easier to go around it. When you see three workarounds in the first month and none of them appear in the issue log, you are already in a recovery project — you simply have not named it yet, and naming it early is what makes it cheap.
Sponsorship predicts everything else
The strongest single predictor of outcome is whether there is an executive sponsor with real authority who spends around four hours a week on the project. Not a steering committee that meets monthly and defers every decision. One person who can tell the sales director that the discount approval flow is changing, and make it stick. Projects with that person land. Projects without one negotiate endlessly and slip a quarter at a time.
The second-order effect matters more than the first. When the sponsor is engaged, decisions take days instead of weeks and the consultant is not stuck mediating between two department heads who each hold a veto. Most ERP delays are not technical work at all. They are queued decisions, and a decision queue is an organisational problem that no amount of project management software will resolve for you.
Scope and data: the two silent killers
Scope creep in ERP is rarely dramatic. It arrives as twelve small requests from people who have not yet used the standard flow, each entirely reasonable on its own. The discipline is a written scope, change control that prices every request in cost and schedule, and one rule we apply consistently: run the standard process for a month before approving any customization meant to replace it. Roughly half the requests evaporate.
Data quality is the killer nobody budgets for. Item masters with 40 percent duplicates, six spellings of the same supplier, opening stock nobody has counted in three years, customers with no NPWP and no address. Cleaning that is not an IT task. It needs a business owner per master file with authority to make final calls, a quality gate before migration, and time in the plan — usually six to eight weeks that projects habitually assume will take two.
Change management is a schedule item, not a slogan
Change management gets treated as a communications exercise. It is not. It is a named process owner in each department who signs off that the new way of working is theirs, participates in the design, and defends it to their own team. Without that person the consultant is proposing changes to people who never agreed to them, and the moment go-live gets hard the department reverts to what it already knows.
- One named process owner per module, from the business, with the time formally allocated
- A decision log everyone can read, so nobody relitigates a settled question in month four
- Early demos with real data — people cannot react honestly to a system full of ABC Corp records
- Explicit messaging about what changes for whom, especially where the new process is more work
- A visible route for raising problems, so workarounds turn into issues instead of habits
Training that survives contact with the warehouse
Training two weeks before go-live, in a meeting room, on demo data, does not work. It has to be role-based, on the real system with the client’s own data, and it needs a competency check — every warehouse operator posts a real goods receipt before they are signed off. Print quick reference cards. Laminate them. Put them where the work happens, because nobody in a warehouse opens a PDF manual at 06:00.
Budget for repeat sessions as well. Attendance at the first round will be around 70 percent because of shifts, leave, and urgent customer problems. The people who miss it are, reliably, the ones who generate the most support tickets in week two. A second round three weeks after go-live costs a day and prevents a month of noise for everyone.
Phasing and the post-go-live owner
Phase the go-live. Finance and procurement first, then inventory, then manufacturing or projects. Big-bang cutovers work when the organisation is small and disciplined; everywhere else they concentrate every risk into one weekend. Between phases, leave a stabilisation window where the only work is fixing what the previous phase exposed, and protect that window from new scope with the same rigour you protect the budget.
Then fund the day after. Most projects end when the consultant leaves, which is exactly when the organisation starts asking real questions. Name an internal product owner at 50 to 100 percent time, keep a backlog, ship a small release monthly, and budget 15 to 20 percent of project value for the first six months. Systems that keep improving get trusted. Systems frozen at go-live get replaced.
- An executive sponsor with authority and four hours a week, named in the project charter
- A written scope with change control that prices every request in cost and schedule
- A business owner per master data file, with a quality gate before migration begins
- A named process owner per module who defends the new way of working to their own team
Those four are settled before delivery starts, and they cost political capital rather than money — which is exactly why they get skipped. The remaining three are settled during and after delivery, and they are the ones quietly deferred the moment the timeline tightens or the budget review lands in the middle of a phase.
- Role-based training on real data, with a competency check and printed reference cards
- A phased go-live with a protected stabilisation window between the phases
- A funded internal owner and a monthly release cadence after the consultants leave
None of those seven are insights. They are all obvious. They are also the seven items that get cut first when the budget tightens, which is precisely why the same projects keep failing in the same way. Protect them in the plan, and most of what people call ERP risk simply stops happening to you.