Key takeaways
- Clarify your processes before comparing systems. An ERP reflects what is there — it repairs nothing.
- Data quality is the most underestimated effort item in every implementation project.
- Name key users and give them real time — not on top of daily business.
- Question every requested customisation: competitive advantage or just historically grown?
- Plan for the time after go-live. The stabilisation phase is part of the project, not an exception.
Processes first, system second
An ERP system mirrors your workflows. If those workflows are unclear, contradictory or different from department to department, the project turns into process consulting — only under time pressure and with a software invoice attached. So it pays to clarify beforehand how an order actually moves through the company, where the media breaks are and which special cases really exist.
An honest separation helps here: what is legally or industry-mandated, what is a genuine competitive advantage, and what has simply been done that way for fifteen years? The third category is usually the largest — and the best lever for keeping a project lean.
The underestimated item: data
Every implementation project eventually meets the master data, and the finding is rarely pleasant: duplicate customers, items without classification, addresses in free-text fields, prices only one colleague can interpret correctly. Carrying this legacy into a new system preserves the problem — and immediately undermines trust in the new system.
So plan data cleansing as a work package of its own, with owners and a deadline. And clarify early how much history really has to come along. Often open items and a defined period of documents are enough; anything older can be archived in an audit-proof way instead of migrated.
People: the factor that decides success
Key user is not a title but a job. They test, decide on business matters, collect feedback and later become the first point of contact in their area. That costs time — time that has to be freed up. Assigning key-user duties on top of a full workload is the most common way to let an ERP project fail slowly.
Equally important is a clear decision structure. Who decides when two departments need a process differently? Without a named authority such questions end in endless loops or get worked around with customisations — both expensive.
The questions to settle before signing
Regardless of system and provider, it pays to have these points in writing:
- What exactly is included in the quote — and what explicitly is not?
- How many person-days are planned for data migration, testing and training?
- What effort is expected on your side, and in which time frames?
- How are customisations implemented — upgrade-safe as extensions or in standard objects?
- What happens after go-live: who is the contact, with which response times?
- How do you get out again if needed — do you get your data and your documentation?
Frequently asked questions
- For a near-standard implementation in a manageable company, a few months is realistic. With multiple sites, manufacturing, many interfaces or extensive custom development it quickly becomes a year or more. The decisive factors are process complexity and key-user availability, not the software.
- A phased rollout lowers risk but extends the period of parallel operation. A big bang is shorter but demands more testing discipline and a solid fallback plan. With several sites or entities, starting with a manageable unit and carrying the experience forward has proven effective.
- When in doubt, the processes. Staying close to the standard permanently lowers implementation cost, operating effort and update risk. Customisations are still right where a workflow genuinely defines your business — but then deliberately, documented and implemented upgrade-safe.