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 start an ERP project with the (logical) desire to “get what we’re doing now, just digital.” The result?

• Unnecessary customizations to reproduce the past

• Complexity and higher costs during upgrades

• Inconsistencies between departments (every exception becomes a feature)

• Low adoption because the new system enables old behavior in a new guise

The hard reality: if you force the ERP to imitate the past, you’re mainly buying more of the same—plus extra licensing 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 is different from mere configuration. Our approach:

1. Process workshops before configuration
   We visualize the current and desired flow (Order-to-Cash, Procure-to-Pay, Project-to-Invoice, etc.). We identify bottlenecks and overlap.

2. Standard first, custom by design
   We choose standard functionality unless there’s a clear business case for customization (competitive advantage, legal requirements, integration).

3. Challenging with respect
   If you say, “we’ve been doing it this way for 20 years,” we ask “why?” and test alternatives. Not to be difficult, but to win on simplicity.

4. Adoption and change
   Role-based trainings, clear work instructions, and a feedback loop after go-live. Technology without adoption is 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.