Why “do-what-the-customer-asks” rarely leads to a successful implementation

ERP isn’t about bending software to old habits, but about designing smarter processes. Implementations fail when the software vendor or implementation partner simply executes what’s requested instead of uncovering—and challenging—the question behind the question.

Many companies begin an ERP project with the understandable wish to get ‘what we do today, but digitally’. The result?

• Unnecessary customisation to reproduce the past

• Complexity and higher costs when upgrading

• Inconsistencies between departments, as every exception becomes a feature

• Low user adoption because the new system accommodates old habits in a new interface

The reality is that forcing an ERP system to imitate the past mainly buys you more of the same, with additional licence costs.

Instead of a checklist of “must-have” functionalities, it’s better to start with clear business goals. Think of:

• Shortening the lead time from quote to invoice

• Less manual work and fewer errors across the process

• Better traceability and reporting

• Faster onboarding of new colleagues

Question behind the question: “What do we want to improve, and how will we measure it?”
Only then should you ask: “Which standard ERP flows best support this?”

At Teamservices, we believe implementation involves more than configuration. Our approach:

1. Process workshops before configuration
   We map current and desired workflows, including order-to-cash, procure-to-pay and project-to-invoice. We look for bottlenecks and overlap.

2. Standard functionality first, customisation by choice
   We use standard functionality unless there is a clear business case for customisation, such as a competitive advantage, a legal requirement or an integration need.

3. Challenge respectfully
   If you say, ‘We have done it this way for 20 years’, we ask why and test alternatives. The aim is to simplify the process, not to make life difficult.

4. Successful onboarding and change management
   Role-specific training, clear work instructions and a feedback loop after go-live. Technology without user adoption is only half a solution.

A client insisted on linking the same budget line to multiple procurement cases because their previous software worked that way. After analysis, it turned out the old system was built linearly (1 case → 1 request for quotation → 1 contract), whereas the new one actually supports multiple steps per case. The “multi-link” was really masking a different need: budget control and traceability.

The solution was not to create a procurement case for every step, but to bundle the process: start a single procurement case and carry out all subsequent steps within it. Result: one clear budget trail, no double counting.

ERP rarely fails because of the software itself. It fails when you try to force an old way of working into a new system. So choose a partner who thinks with you, challenges you, and dares to push back—so tomorrow you don’t do the same as yesterday, but better.