12 E-Commerce operators share how they scale operations. → Get the ERP Playbook.
12 E-Commerce operators share how they scale operations.
How to Start an ERP Project Successfully: 9 Decisions That Need to Be Made Before Implementation
How to Start an ERP Project Successfully: 9 Decisions That Need to Be Made Before Implementation
In growing companies, ERP projects usually start when processes can no longer keep up with the business: data is scattered, decisions depend on individual people, and too much work happens through Excel, manual checks, or undocumented routines.
Most teams then focus on the obvious question: Which system should we choose?
But that is rarely where ERP projects are won. The more important question is: How should the system reflect the way responsibility, processes, data, and decisions actually work inside the company?
Because an ERP does not create clarity by itself. It amplifies what is already there. If the setup is unclear, the system will make that unclear setup visible, especially once real-life exceptions hit: changed orders, unavailable products, split deliveries, returns, special prices, or invoices that do not follow the happy path.
This article covers the 9 decisions that need to be made before and during an ERP implementation, so the project does not turn into a permanent state of workarounds, tickets, and rework.
TL;DR
Most ERP projects do not fail because of the software. They fail because of missing, unclear, or wrong decisions.
If target state, processes, ownership, data quality, scope, and the operating model are not properly clarified, an ERP project quickly becomes a system that technically exists but does not truly guide day-to-day work.
The most important question is therefore not: “Which ERP should we choose?” But: Are we as a company decision-ready enough to implement, use, and continuously improve an ERP properly?
The Real Mistake Often Happens Before Implementation
An ERP project rarely fails because of one big mistake. Most of the time, the problem develops gradually.
The target state is not clear enough, processes are only understood at workshop level, Phase 1 becomes too large, and nobody really knows who can make binding internal decisions. Customization is discussed before the actual process is understood, data quality remains a side project, testing checks functions but not real workflows, and after go-live there is no rhythm for continuous improvement.
Each of these points may seem manageable on its own. Together, they create a setup that is almost impossible to steer later. The ERP project then turns into a permanent state: open tickets, unreliable data, Excel sheets next to the system, debates about numbers, workarounds in departments, and declining trust across the team.
The tricky part is that it often still looks like progress at the beginning: There are workshops, tasks, a system, a roadmap. But at some point, the company realizes that a lot has been built — and too little has been clarified.
An ERP project therefore does not just need implementation. It needs decision readiness before implementation starts.
An ERP Project Has Three Layers
Before we get into the 9 decisions, it helps to use a simple model. An ERP project is not one decision. It has three layers:
1. Business Design
What should become operationally better? Which processes are critical? Which KPIs need to be reliable? Which problems can no longer be covered up with workarounds?
2. Delivery Design
How will the project be implemented? What belongs in Phase 1? What will deliberately be done later? How will testing work? How do you prevent the first go-live from collapsing under its own scope?
3. Operating Design
Who will run the system after go-live? Who prioritizes changes? Who owns data quality? How is knowledge documented? How does support become real continuous improvement?
Many companies invest too much energy in the software selection and too little in these three layers. But this is where the difference emerges between a system that has been implemented and a system that actually works inside the company.
1. Target State: What Should the ERP Actually Improve?
“We need an ERP” is not a goal. “We want to become more digital” is not a goal either. And “we need more transparency” is at least still too vague.
A good ERP project starts with a different kind of question:
“Which work should become simpler, faster, or more reliable afterwards?”
That may sound obvious, but it is critical. Without a clear target state, the project quickly becomes a collection of requirements.
Sales wants better quotes, logistics wants cleaner inventory, finance wants more consistent numbers, and management wants transparency. Procurement wants better planning, customer service wants fewer internal questions. All of these wishes may be valid, but not everything is equally important, and not everything belongs in Phase 1.
A good target state forces decisions:
Which processes need to run reliably first?
Which KPIs actually define success?
Which problems currently cost time, money, or trust?
Which workarounds must not simply be rebuilt digitally?
What is annoying, but not critical?
What sounds important, but can wait?
In growing companies, the pain is often vague at first: “Everything is becoming too messy.” That is enough to start a conversation, but it is not enough to start an implementation.
A better target state would be: “We want to stabilize the order-to-cash process from quote to invoice so that sales, warehouse, and accounting work from the same data, orders can run through without manual rework, and month-end closing no longer depends on Excel corrections.”
Or: “We want to manage inventory, purchasing needs, and delivery capability in a way that operational decisions are no longer based on gut feeling and manually maintained lists.”
These kinds of target states are more useful. They clarify which work should improve and how you will later know whether the ERP project actually created value.
Without this target state, the ERP has to solve everything at once. And that is exactly where many projects fail.
2. Do You Really Understand Your Processes or Only the Ideal Version?
“Many companies believe they know their processes. Until they actually look at them.”
Then it becomes clear: the official process is only part of the truth. The real process lives in exceptions, side paths, handovers, individual routines, and silent agreements.
An order does not simply move from quote to delivery to invoice. Along the way, there are many special cases: a customer changes the quantity, an item is unavailable, a delivery address is wrong, an order has to be split, a special price applies only in a specific situation, accounting needs information that nobody in sales has maintained properly, or the warehouse books something differently because it makes sense physically, but was never properly mapped in the system.
These are the moments that decide whether an ERP works in everyday operations.
From Practice
In one of our projects, the basic process initially looked plausible: purchasing, sales, warehouse, and accounting were set up in the system. As long as everything ran straight through, the setup seemed okay. The problem appeared with small changes. As soon as a customer changed a quantity in an order or something had to be removed, incorrect postings, uncertainty, and manual rework followed. The system was not resilient enough.
An ERP project must not only understand the fair-weather process. It must understand the real operational reality. That is why it is not enough to discuss processes abstractly in workshops. You have to see how work actually happens:
Which information is needed when?
Where does responsibility change hands?
Which exceptions happen regularly?
Which lists are maintained next to the system?
Which manual steps only work because experienced employees carry them in their heads?
Which decisions are not documented, but are constantly being made?
Where do errors appear when someone is sick or new to the team?
This is one of the biggest differences between superficial requirements gathering and real discovery:
“If you only ask, ‘What should the system be able to do?’, you usually get feature requests. If you observe how work actually happens, you understand process logic, dependencies, and risks.”
An ERP must not reflect the wishful version of a process. It has to cope with the reality of work. If that reality has not been understood beforehand, you end up with a system that looks good in the demo but does not create enough impact in daily operations.
3. How Big Should the First Phase Really Be?
One of the most dangerous ideas in ERP projects is: “If we are already doing this, we might as well include that too.”
This is how the scope of Phase 1 grows: a bit of CRM, warehouse, accounting. Then procurement, reporting, a special process, an integration, time tracking, a portal, and one more request from a department that otherwise will not buy in.
In the end, the first phase is expected to deliver so much that it becomes almost impossible to manage. Every additional process does not just bring another module. It brings decisions, data, roles, testing, training, exceptions, and dependencies.
The most dangerous topics are often the ones that sound small. “Let’s include time tracking as well” sounds harmless. Until it becomes clear that HR master data, absences, payroll, shift planning, production planning, permissions, approvals, and reporting are attached to it. Suddenly, what looked like a small add-on is no longer a small add-on. It is its own project stream.
The same is true for many ERP areas: a portal is not just a portal, an integration is not just an integration, a new module is not just a new module. It changes who works how and where responsibility sits.
A good ERP project therefore needs a first implementation wave that is large enough to create real value, but small enough to be implemented, tested, and understood properly. It does not need to perfect the entire company, but to create a stable core that can be built on. That sounds less impressive than a big bang, but it works more often.
Later, the ERP can become a full orchestra. But in Phase 1, it first needs to make music. If too many instruments start playing at the same time, the result is rarely harmony. Usually, it is noise.
The better question is therefore not: “What could we include in Phase 1?” But: “What needs to work in Phase 1 so the company operates more reliably afterwards than it does today?”
Everything else does not automatically disappear. It belongs in a backlog that is prioritized later.
In growing companies, ERP projects usually start when processes can no longer keep up with the business: data is scattered, decisions depend on individual people, and too much work happens through Excel, manual checks, or undocumented routines.
Most teams then focus on the obvious question: Which system should we choose?
But that is rarely where ERP projects are won. The more important question is: How should the system reflect the way responsibility, processes, data, and decisions actually work inside the company?
Because an ERP does not create clarity by itself. It amplifies what is already there. If the setup is unclear, the system will make that unclear setup visible, especially once real-life exceptions hit: changed orders, unavailable products, split deliveries, returns, special prices, or invoices that do not follow the happy path.
This article covers the 9 decisions that need to be made before and during an ERP implementation, so the project does not turn into a permanent state of workarounds, tickets, and rework.
TL;DR
Most ERP projects do not fail because of the software. They fail because of missing, unclear, or wrong decisions.
If target state, processes, ownership, data quality, scope, and the operating model are not properly clarified, an ERP project quickly becomes a system that technically exists but does not truly guide day-to-day work.
The most important question is therefore not: “Which ERP should we choose?” But: Are we as a company decision-ready enough to implement, use, and continuously improve an ERP properly?
The Real Mistake Often Happens Before Implementation
An ERP project rarely fails because of one big mistake. Most of the time, the problem develops gradually.
The target state is not clear enough, processes are only understood at workshop level, Phase 1 becomes too large, and nobody really knows who can make binding internal decisions. Customization is discussed before the actual process is understood, data quality remains a side project, testing checks functions but not real workflows, and after go-live there is no rhythm for continuous improvement.
Each of these points may seem manageable on its own. Together, they create a setup that is almost impossible to steer later. The ERP project then turns into a permanent state: open tickets, unreliable data, Excel sheets next to the system, debates about numbers, workarounds in departments, and declining trust across the team.
The tricky part is that it often still looks like progress at the beginning: There are workshops, tasks, a system, a roadmap. But at some point, the company realizes that a lot has been built — and too little has been clarified.
An ERP project therefore does not just need implementation. It needs decision readiness before implementation starts.
An ERP Project Has Three Layers
Before we get into the 9 decisions, it helps to use a simple model. An ERP project is not one decision. It has three layers:
1. Business Design
What should become operationally better? Which processes are critical? Which KPIs need to be reliable? Which problems can no longer be covered up with workarounds?
2. Delivery Design
How will the project be implemented? What belongs in Phase 1? What will deliberately be done later? How will testing work? How do you prevent the first go-live from collapsing under its own scope?
3. Operating Design
Who will run the system after go-live? Who prioritizes changes? Who owns data quality? How is knowledge documented? How does support become real continuous improvement?
Many companies invest too much energy in the software selection and too little in these three layers. But this is where the difference emerges between a system that has been implemented and a system that actually works inside the company.
1. Target State: What Should the ERP Actually Improve?
“We need an ERP” is not a goal. “We want to become more digital” is not a goal either. And “we need more transparency” is at least still too vague.
A good ERP project starts with a different kind of question:
“Which work should become simpler, faster, or more reliable afterwards?”
That may sound obvious, but it is critical. Without a clear target state, the project quickly becomes a collection of requirements.
Sales wants better quotes, logistics wants cleaner inventory, finance wants more consistent numbers, and management wants transparency. Procurement wants better planning, customer service wants fewer internal questions. All of these wishes may be valid, but not everything is equally important, and not everything belongs in Phase 1.
A good target state forces decisions:
Which processes need to run reliably first?
Which KPIs actually define success?
Which problems currently cost time, money, or trust?
Which workarounds must not simply be rebuilt digitally?
What is annoying, but not critical?
What sounds important, but can wait?
In growing companies, the pain is often vague at first: “Everything is becoming too messy.” That is enough to start a conversation, but it is not enough to start an implementation.
A better target state would be: “We want to stabilize the order-to-cash process from quote to invoice so that sales, warehouse, and accounting work from the same data, orders can run through without manual rework, and month-end closing no longer depends on Excel corrections.”
Or: “We want to manage inventory, purchasing needs, and delivery capability in a way that operational decisions are no longer based on gut feeling and manually maintained lists.”
These kinds of target states are more useful. They clarify which work should improve and how you will later know whether the ERP project actually created value.
Without this target state, the ERP has to solve everything at once. And that is exactly where many projects fail.
2. Do You Really Understand Your Processes or Only the Ideal Version?
“Many companies believe they know their processes. Until they actually look at them.”
Then it becomes clear: the official process is only part of the truth. The real process lives in exceptions, side paths, handovers, individual routines, and silent agreements.
An order does not simply move from quote to delivery to invoice. Along the way, there are many special cases: a customer changes the quantity, an item is unavailable, a delivery address is wrong, an order has to be split, a special price applies only in a specific situation, accounting needs information that nobody in sales has maintained properly, or the warehouse books something differently because it makes sense physically, but was never properly mapped in the system.
These are the moments that decide whether an ERP works in everyday operations.
From Practice
In one of our projects, the basic process initially looked plausible: purchasing, sales, warehouse, and accounting were set up in the system. As long as everything ran straight through, the setup seemed okay. The problem appeared with small changes. As soon as a customer changed a quantity in an order or something had to be removed, incorrect postings, uncertainty, and manual rework followed. The system was not resilient enough.
An ERP project must not only understand the fair-weather process. It must understand the real operational reality. That is why it is not enough to discuss processes abstractly in workshops. You have to see how work actually happens:
Which information is needed when?
Where does responsibility change hands?
Which exceptions happen regularly?
Which lists are maintained next to the system?
Which manual steps only work because experienced employees carry them in their heads?
Which decisions are not documented, but are constantly being made?
Where do errors appear when someone is sick or new to the team?
This is one of the biggest differences between superficial requirements gathering and real discovery:
“If you only ask, ‘What should the system be able to do?’, you usually get feature requests. If you observe how work actually happens, you understand process logic, dependencies, and risks.”
An ERP must not reflect the wishful version of a process. It has to cope with the reality of work. If that reality has not been understood beforehand, you end up with a system that looks good in the demo but does not create enough impact in daily operations.
3. How Big Should the First Phase Really Be?
One of the most dangerous ideas in ERP projects is: “If we are already doing this, we might as well include that too.”
This is how the scope of Phase 1 grows: a bit of CRM, warehouse, accounting. Then procurement, reporting, a special process, an integration, time tracking, a portal, and one more request from a department that otherwise will not buy in.
In the end, the first phase is expected to deliver so much that it becomes almost impossible to manage. Every additional process does not just bring another module. It brings decisions, data, roles, testing, training, exceptions, and dependencies.
The most dangerous topics are often the ones that sound small. “Let’s include time tracking as well” sounds harmless. Until it becomes clear that HR master data, absences, payroll, shift planning, production planning, permissions, approvals, and reporting are attached to it. Suddenly, what looked like a small add-on is no longer a small add-on. It is its own project stream.
The same is true for many ERP areas: a portal is not just a portal, an integration is not just an integration, a new module is not just a new module. It changes who works how and where responsibility sits.
A good ERP project therefore needs a first implementation wave that is large enough to create real value, but small enough to be implemented, tested, and understood properly. It does not need to perfect the entire company, but to create a stable core that can be built on. That sounds less impressive than a big bang, but it works more often.
Later, the ERP can become a full orchestra. But in Phase 1, it first needs to make music. If too many instruments start playing at the same time, the result is rarely harmony. Usually, it is noise.
The better question is therefore not: “What could we include in Phase 1?” But: “What needs to work in Phase 1 so the company operates more reliably afterwards than it does today?”
Everything else does not automatically disappear. It belongs in a backlog that is prioritized later.
Ist dein ERP Projekt in Gefahr?
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
4. Who Really Owns the Project Internally?
ERP projects often need external expertise, but they must not be fully owned externally. An implementation partner can structure, advise, build, challenge, and accelerate. What they cannot replace is internal responsibility.
Because the most important decisions can only be made by the company itself.
Which processes are critical?
Which compromises are acceptable?
Which special cases are truly relevant?
Which teams need to change the way they work?
Which data is binding?
Which decision can no longer be postponed?
If nobody owns this internally, a dangerous dynamic emerges.
The partner asks, the company answers halfway, the partner builds, the company reviews late, decisions are postponed, requirements change, priorities blur. In the end, “the system” gets blamed — but the real issue is missing ownership.
A typical pattern: a capable employee is given the ERP project on the side. They research systems, speak to partners, prepare data, and try to hold the project together internally. At first, this seems pragmatic. Later, it becomes clear: the project is too large for one person without real decision-making authority. Management then realizes too late that it should have led the project more closely. The system may already be live, but the real work only starts afterwards: fixing, explaining, correcting, calming people down.
An ERP needs someone who does not just use the system, but leads it. This role does not have to be the most technical person in the company. Often, the opposite is better. The person needs to understand processes, moderate decisions, set priorities, and translate between management, departments, and implementation.
What matters is that this person has time, mandate, and backing.
“Just do this on the side” is an invitation to chaos.
5. What Should Stay Internal, and What Should Be Added Externally?
Many companies think about this too narrowly: Either they want to build the ERP completely internally, or they hand over too much to external partners. Both can go wrong.
A fully internal setup often lacks breadth: ERP architecture, integrations, finance logic, data models, testing, releases, change management, process design, training, and clean continuous improvement are rarely combined in one person. Good profiles are hard to find, onboarding takes time, and what should be a strategic role quickly becomes the dumping ground for everything that is unclear in the system.
A fully external setup creates different problems: Internal understanding does not develop, decisions, logic, and dependencies sit primarily with the service provider, the company can pass on requirements but no longer truly understands them, changes take longer because nobody internally can properly prioritize or assess what matters, and problems are forwarded instead of being understood. The ERP then remains a foreign object in daily operations.
The better path is usually somewhere in between.
Internal responsibility must cover:
target state
prioritization
process decisions
data quality
acceptance
change inside the team
operating rhythm after go-live
External leverage can come from:
methodology
architecture
specialist expertise
integrations
QA
enablement
technical implementation
clean continuous improvement
Good ERP projects happen when internal responsibility exists and external support adds better options, structure, and implementation power.
The key question is therefore:
“What do we need to own ourselves, and where do we need better leverage?”
6. How Do You Prevent Customization From Becoming the Default?
Customization is not bad. Sometimes it is exactly right. Companies with complex workflows, specific product logic, hybrid business models, or specific integrations often need more than standard functionality.
The problem begins when customization comes too early. Then things are adapted before they are understood. Built before they are decided. Individualized before the standard has been seriously tested.
At first, this feels pragmatic. Later, it becomes expensive.
Every customization increases complexity. It needs to be understood, tested, documented, maintained, and considered during updates. If it is based on a clear business case, it can make sense. If it only covers up an unclear process, it becomes technical debt.
A simple example from practice:
A department says it needs a specific field, special logic, or its own status. Maybe that is true, but maybe it is only the digital reproduction of a workaround that exists because responsibility, data, or handovers have not been clearly defined.
In that case, customization does not solve the problem. It preserves it. A good ERP implementation therefore asks the following question before every customization:
“Are we really solving a system problem here, or are we avoiding a bad process decision?”
For example:
Are we building something because the workflow is unclear?
Because responsibilities have not been defined?
Because we want to digitally rebuild existing workarounds?
Because a special case looks bigger than it really is?
Because the standard is not sufficient or because we have not understood it yet?
The sentence “we’ll just build that quickly” almost always sounds too harmless in ERP projects. Very little is ever “just built quickly”. Most of it has to be understood, maintained, and defended for a long time afterwards.
7. Who Owns Data Quality?
Data quality sounds like detail work, but it is leadership work. If product data is messy, inventory is wrong, customer data is duplicated, posting logic is unclear, or reports are interpreted differently, the system loses authority. People stop believing the ERP.
They export lists, build their own spreadsheets, ask colleagues, maintain shadow logic. And the more this happens, the less the ERP remains the shared truth of the company.
This is one of the most dangerous moments in an ERP project because trust in the system is lost. An ERP can only become the backbone of the organization if people trust the data.
Data quality needs responsibility, rules, and routines:
Who is allowed to change product data?
Which fields are mandatory?
Which data is leading?
Where are duplicates cleaned up?
Which reports are binding?
Who decides when departments use different definitions?
How do you prevent old data problems from simply being migrated?
Many companies underestimate this because data migration sounds technical. But technical migration is only one part. The harder part is deciding which data will be binding in the future.
If the company does not already have a shared understanding of item master data, customer data, inventory logic, or reporting, the ERP will not magically create that understanding.
8. How Do You Test: With Real Workflows or Just With Functions?
Many ERP projects test too technically: a module works, a button does what it should, an invoice can be created, inventory changes, an email is sent. That matters, but it is not enough.
The decisive question is whether the process works as a whole:
Can a real order with real special cases run through cleanly?
Are the handovers between sales, warehouse, and accounting clear?
Does the team understand what needs to happen when?
Do gaps appear before real customers are affected?
Does the workflow still work when things are not ideal?
Do employees know what to do when the standard case breaks?
Good testing therefore feels less like software testing and more like rehearsal. You run real scenarios with the people who will later work with the system, as close as possible to the actual work.
In broader end-to-end projects, we therefore work with dry runs:
An order is played through as a simulated working reality from start to finish: from sales through purchasing, warehouse, production or service delivery, all the way to invoicing.
This is often where the most important insights happen: A role does not understand when it needs to take over, a data field is missing, a special case was not considered, a handover sounds logical but does not work in daily operations, or a decision that seemed clear in the workshop suddenly becomes practically unclear.
That is exactly what these dry runs are for. They validate the system and train the team in context. And they show early where the setup is not yet resilient enough.
An ERP project is only stable when it is not just logically configured, but understood and used in day-to-day work.
4. Who Really Owns the Project Internally?
ERP projects often need external expertise, but they must not be fully owned externally. An implementation partner can structure, advise, build, challenge, and accelerate. What they cannot replace is internal responsibility.
Because the most important decisions can only be made by the company itself.
Which processes are critical?
Which compromises are acceptable?
Which special cases are truly relevant?
Which teams need to change the way they work?
Which data is binding?
Which decision can no longer be postponed?
If nobody owns this internally, a dangerous dynamic emerges.
The partner asks, the company answers halfway, the partner builds, the company reviews late, decisions are postponed, requirements change, priorities blur. In the end, “the system” gets blamed — but the real issue is missing ownership.
A typical pattern: a capable employee is given the ERP project on the side. They research systems, speak to partners, prepare data, and try to hold the project together internally. At first, this seems pragmatic. Later, it becomes clear: the project is too large for one person without real decision-making authority. Management then realizes too late that it should have led the project more closely. The system may already be live, but the real work only starts afterwards: fixing, explaining, correcting, calming people down.
An ERP needs someone who does not just use the system, but leads it. This role does not have to be the most technical person in the company. Often, the opposite is better. The person needs to understand processes, moderate decisions, set priorities, and translate between management, departments, and implementation.
What matters is that this person has time, mandate, and backing.
“Just do this on the side” is an invitation to chaos.
5. What Should Stay Internal, and What Should Be Added Externally?
Many companies think about this too narrowly: Either they want to build the ERP completely internally, or they hand over too much to external partners. Both can go wrong.
A fully internal setup often lacks breadth: ERP architecture, integrations, finance logic, data models, testing, releases, change management, process design, training, and clean continuous improvement are rarely combined in one person. Good profiles are hard to find, onboarding takes time, and what should be a strategic role quickly becomes the dumping ground for everything that is unclear in the system.
A fully external setup creates different problems: Internal understanding does not develop, decisions, logic, and dependencies sit primarily with the service provider, the company can pass on requirements but no longer truly understands them, changes take longer because nobody internally can properly prioritize or assess what matters, and problems are forwarded instead of being understood. The ERP then remains a foreign object in daily operations.
The better path is usually somewhere in between.
Internal responsibility must cover:
target state
prioritization
process decisions
data quality
acceptance
change inside the team
operating rhythm after go-live
External leverage can come from:
methodology
architecture
specialist expertise
integrations
QA
enablement
technical implementation
clean continuous improvement
Good ERP projects happen when internal responsibility exists and external support adds better options, structure, and implementation power.
The key question is therefore:
“What do we need to own ourselves, and where do we need better leverage?”
6. How Do You Prevent Customization From Becoming the Default?
Customization is not bad. Sometimes it is exactly right. Companies with complex workflows, specific product logic, hybrid business models, or specific integrations often need more than standard functionality.
The problem begins when customization comes too early. Then things are adapted before they are understood. Built before they are decided. Individualized before the standard has been seriously tested.
At first, this feels pragmatic. Later, it becomes expensive.
Every customization increases complexity. It needs to be understood, tested, documented, maintained, and considered during updates. If it is based on a clear business case, it can make sense. If it only covers up an unclear process, it becomes technical debt.
A simple example from practice:
A department says it needs a specific field, special logic, or its own status. Maybe that is true, but maybe it is only the digital reproduction of a workaround that exists because responsibility, data, or handovers have not been clearly defined.
In that case, customization does not solve the problem. It preserves it. A good ERP implementation therefore asks the following question before every customization:
“Are we really solving a system problem here, or are we avoiding a bad process decision?”
For example:
Are we building something because the workflow is unclear?
Because responsibilities have not been defined?
Because we want to digitally rebuild existing workarounds?
Because a special case looks bigger than it really is?
Because the standard is not sufficient or because we have not understood it yet?
The sentence “we’ll just build that quickly” almost always sounds too harmless in ERP projects. Very little is ever “just built quickly”. Most of it has to be understood, maintained, and defended for a long time afterwards.
7. Who Owns Data Quality?
Data quality sounds like detail work, but it is leadership work. If product data is messy, inventory is wrong, customer data is duplicated, posting logic is unclear, or reports are interpreted differently, the system loses authority. People stop believing the ERP.
They export lists, build their own spreadsheets, ask colleagues, maintain shadow logic. And the more this happens, the less the ERP remains the shared truth of the company.
This is one of the most dangerous moments in an ERP project because trust in the system is lost. An ERP can only become the backbone of the organization if people trust the data.
Data quality needs responsibility, rules, and routines:
Who is allowed to change product data?
Which fields are mandatory?
Which data is leading?
Where are duplicates cleaned up?
Which reports are binding?
Who decides when departments use different definitions?
How do you prevent old data problems from simply being migrated?
Many companies underestimate this because data migration sounds technical. But technical migration is only one part. The harder part is deciding which data will be binding in the future.
If the company does not already have a shared understanding of item master data, customer data, inventory logic, or reporting, the ERP will not magically create that understanding.
8. How Do You Test: With Real Workflows or Just With Functions?
Many ERP projects test too technically: a module works, a button does what it should, an invoice can be created, inventory changes, an email is sent. That matters, but it is not enough.
The decisive question is whether the process works as a whole:
Can a real order with real special cases run through cleanly?
Are the handovers between sales, warehouse, and accounting clear?
Does the team understand what needs to happen when?
Do gaps appear before real customers are affected?
Does the workflow still work when things are not ideal?
Do employees know what to do when the standard case breaks?
Good testing therefore feels less like software testing and more like rehearsal. You run real scenarios with the people who will later work with the system, as close as possible to the actual work.
In broader end-to-end projects, we therefore work with dry runs:
An order is played through as a simulated working reality from start to finish: from sales through purchasing, warehouse, production or service delivery, all the way to invoicing.
This is often where the most important insights happen: A role does not understand when it needs to take over, a data field is missing, a special case was not considered, a handover sounds logical but does not work in daily operations, or a decision that seemed clear in the workshop suddenly becomes practically unclear.
That is exactly what these dry runs are for. They validate the system and train the team in context. And they show early where the setup is not yet resilient enough.
An ERP project is only stable when it is not just logically configured, but understood and used in day-to-day work.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
9. What Happens After Go-Live?
Go-live is not the end of the ERP project. It is more like the moment when the quality of the project becomes truly visible.
Only then does it become clear which processes really work, which data is missing, which special cases happen more often than expected, which teams adopt the system, and where training was not enough.
That is why a good ERP setup needs a clear operating rhythm after go-live:
What input is collected?
How is it prioritized?
Who decides?
When are releases made?
How is testing handled?
How are employees trained further?
How is knowledge documented?
How do you prevent every small friction point from becoming another directionless ticket?
Many ERP initiatives fail because no decision system exists after go-live.
Then the usual thing happens: everyone reports issues. Some are bugs, some are training gaps, others are real improvements, some are special requests, others are symptoms of a process that has not yet been properly decided.
If these topics are not sorted properly, no continuous improvement process emerges.
Everything that was deliberately not built in Phase 1 must not disappear after go-live as a vague “we’ll do that later”. It needs a backlog, a fixed prioritization rhythm, and regular decisions with the relevant stakeholders. Otherwise, continuous improvement turns back into support.
Context is just as important. ERP projects lose time because knowledge gets lost: Why was something decided this way? Which exception was deliberately postponed? Which rule applies going forward? What was explained to a department? What logic sits behind a customization?
If this context disappears into calls, chats, and people’s heads, every future change becomes harder.
Why ERP Costs Are Often Misunderstood
ERP discussions often focus on licenses. That is understandable, because they are visible, comparable, and easy to put into spreadsheets.
But the larger part of the cost usually appears elsewhere: in concept work, process work, implementation, testing, training, operations, continuous improvement, and rework.
It becomes even more expensive when this work is done poorly: Unclear requirements, weak prioritization, missing ownership, excessive scope, bad customization, or rework without direction can turn an ERP project into a cost trap.
The most expensive ERP costs rarely appear in the proposal: They appear when departments do not trust the system after go-live. When workarounds return, reports have to be debated, every small change needs external clarification again, nobody knows exactly why something was built the way it was, and teams have a new system but not a better working reality.
That is why the real cost question is: What will it cost us if we build the wrong setup?
How to Tell Whether You Are Not Ready Yet
An ERP project does not need to be perfectly prepared, but it needs to be prepared well enough to make decisions.
The decisive question is: Can we make clean decisions?
Go through the following points honestly:
Target Clarity
Can you explain in one or two sentences which problem the ERP is supposed to solve and how you will measure success? Or does the goal sound more like “more transparency”, “better processes”, and “integrate everything”?
Scope and Phase 1
Is it clear what is deliberately not part of Phase 1? Or does the scope grow with every conversation?
Process Understanding
Do your departments describe the same workflows in a similar way? Or do sales, warehouse, procurement, finance, and management already contradict each other when asked how the process actually works today? Have you looked at the processes in practice?
Special Cases
Do you know the 20 percent of cases that create 80 percent of the complexity? Or do critical exceptions only appear late in the project?
Prioritization
Is there someone who can make binding decisions? Or does everything have to be “discussed again”?
Internal Responsibility
Does your ERP owner truly have time, mandate, and backing? Or is the project running alongside day-to-day work?
Customization Understanding
Do you discuss solutions early before it is clear whether the problem should be solved that way at all? Or do you first check whether process, standard, and business case fit together?
Data Ownership
Are there clear owners for data quality? Or is data migration a technical side project that “someone” will take care of?
Testing
Do you test real workflows with real roles and special cases? Or do you only check whether individual functions basically work?
Operations After Go-Live
Do you know how the system will be run and continuously improved afterwards? Or does planning end at go-live?
Interpretation
If you are unsure on several of these points or answer “it depends”, then you probably lack more than preparation. You lack decision readiness in the setup.
And this is exactly where most projects fail, because they run alongside the normal business. Everyone is busy and everyone wants progress. But hardly anyone has the time to make the necessary decisions properly.
Typical Trade-Offs You Need to Clarify Early
ERP projects do not become more stable because every tension disappears. They become more stable because trade-offs are made consciously.
Speed vs. Stability
A fast go-live sounds good, but too much scope makes it worthless. Ask instead: What can we bring live quickly without overwhelming the organization?
nternal vs. External
Internal knowledge is important, external breadth is often more efficient. So ask instead: Which responsibility must stay internal, and which expertise should we add externally?
Standard vs. Customization
Standard reduces complexity, customization can create value. So ask yourselves: Where does real business impact emerge, and where are we only rebuilding old workarounds?
Big Bang vs. Phased Model
A big bang looks decisive, but phased models usually win in reality. So look carefully at this question: Which first wave creates enough value without overloading the project?
Feature Request vs. Process Decision
A feature request sounds concrete, while a process decision is often more uncomfortable. Ask: Do we really need this function, or do we first need to decide how we want to work in the future?
A Simple Decision Framework
If you do not yet have a clear target state: Do not start implementation. Do discovery.
If Phase 1 is supposed to include everything: Reduce the scope.
If you do not have an internal owner role: Clarify the project setup before a partner starts working.
If processes are only known at workshop level: Look at the work where it actually happens.
If special cases appear late: Do not only test functions. Test real workflows.
If customization becomes the default answer early: First check process, standard, and business case.
If nobody owns data quality: Define owners, rules, and binding data sources.
If nobody is responsible after go-live: Build an operating model with backlog, prioritization, release rhythm, and follow-up training.
Conclusion: The Most Important ERP Decision Is Not the Tool
Of course, system selection matters, but it is not where ERP projects are won.
A good ERP project is created through the decisions before and after: target state, process understanding, scope, ownership, capability building, data quality, testing, and continuous improvement.
That sounds less spectacular than big software promises. But that is exactly where the difference emerges between a system that has been introduced and a system that truly becomes the backbone of the company.
FAQ: How to Start an ERP Project Successfully
When Is a Company Ready for an ERP Project?
A company is ready for an ERP project when it is not just looking for a new system, but is ready to make decisions. That means the target state, core processes, internal responsibility, data quality, Phase 1 scope, and operating model after go-live are clear enough to make meaningful decisions. The setup does not need to be perfect, but it cannot be completely open.
What Should Be Clarified Before an ERP Implementation?
Before an ERP implementation, at least the following points should be clarified: What should become operationally better? Which processes are critical? Who decides internally? What belongs in Phase 1? Which data is binding? How will testing work? And who will run the system after go-live? Without this clarification, implementation quickly becomes a collection of requirements without clear direction.
Why Do ERP Projects Fail So Often?
ERP projects rarely fail because of software alone. More often, they fail because of unclear processes, excessive scope, missing internal responsibility, poor data quality, premature customization, unrealistic testing, or a missing operating model after go-live. The system is implemented, but it is not truly embedded in the organization.
How Big Should Phase 1 of an ERP Implementation Be?
Phase 1 should be large enough to create real operational value, but small enough to be implemented, tested, and understood properly. A good first wave creates a stable core. It does not need to perfect the entire company. Topics that are important but not critical for the first go-live belong in a prioritized backlog.
Should an ERP Project Be Implemented Internally or Externally?
In most cases, a hybrid setup works best. Internally, the company must own the target state, prioritization, process decisions, data quality, and acceptance. Externally, methodology, architecture, specialist expertise, integrations, QA, technical implementation, and enablement can be added. A fully external setup often creates dependency. A fully internal setup often lacks the necessary breadth.
Which Internal Role Does a Company Need for an ERP Project?
A company needs an internal owner role that understands processes, can moderate decisions, and translates between management, departments, and implementation. This person does not need to be the most technical person in the company. Mandate, time, prioritization ability, and backing from management are more important.
Why Is Data Quality So Important in ERP Projects?
Data quality determines whether people trust the ERP. If product data, inventory, customer data, or posting logic is unreliable, shadow lists, manual checks, and distrust in the system emerge. Data quality is therefore not a technical side task. It is leadership work.
How Should an ERP Project Be Tested?
An ERP project should not only be tested through functions, but through real workflows. Good tests play through real scenarios with real roles, handovers, and special cases. This shows whether the system works in day-to-day operations and whether employees understand what they need to do and when.
What Happens After ERP Go-Live?
After go-live, the actual operating phase begins. This requires follow-up training, a prioritized backlog, clear responsibilities, regular decision rounds, and a clean release rhythm. Without this operating model, continuous improvement quickly turns into an unstructured support process.
Is Customization Bad in ERP Projects?
No. Customization can make sense when it has a clear business case and supports a real process advantage or competitive advantage. It becomes problematic when it comes too early and only digitally rebuilds unclear processes or old workarounds. Before every customization, the team should check whether it is truly solving a system problem or merely covering up a bad process decision.
9. What Happens After Go-Live?
Go-live is not the end of the ERP project. It is more like the moment when the quality of the project becomes truly visible.
Only then does it become clear which processes really work, which data is missing, which special cases happen more often than expected, which teams adopt the system, and where training was not enough.
That is why a good ERP setup needs a clear operating rhythm after go-live:
What input is collected?
How is it prioritized?
Who decides?
When are releases made?
How is testing handled?
How are employees trained further?
How is knowledge documented?
How do you prevent every small friction point from becoming another directionless ticket?
Many ERP initiatives fail because no decision system exists after go-live.
Then the usual thing happens: everyone reports issues. Some are bugs, some are training gaps, others are real improvements, some are special requests, others are symptoms of a process that has not yet been properly decided.
If these topics are not sorted properly, no continuous improvement process emerges.
Everything that was deliberately not built in Phase 1 must not disappear after go-live as a vague “we’ll do that later”. It needs a backlog, a fixed prioritization rhythm, and regular decisions with the relevant stakeholders. Otherwise, continuous improvement turns back into support.
Context is just as important. ERP projects lose time because knowledge gets lost: Why was something decided this way? Which exception was deliberately postponed? Which rule applies going forward? What was explained to a department? What logic sits behind a customization?
If this context disappears into calls, chats, and people’s heads, every future change becomes harder.
Why ERP Costs Are Often Misunderstood
ERP discussions often focus on licenses. That is understandable, because they are visible, comparable, and easy to put into spreadsheets.
But the larger part of the cost usually appears elsewhere: in concept work, process work, implementation, testing, training, operations, continuous improvement, and rework.
It becomes even more expensive when this work is done poorly: Unclear requirements, weak prioritization, missing ownership, excessive scope, bad customization, or rework without direction can turn an ERP project into a cost trap.
The most expensive ERP costs rarely appear in the proposal: They appear when departments do not trust the system after go-live. When workarounds return, reports have to be debated, every small change needs external clarification again, nobody knows exactly why something was built the way it was, and teams have a new system but not a better working reality.
That is why the real cost question is: What will it cost us if we build the wrong setup?
How to Tell Whether You Are Not Ready Yet
An ERP project does not need to be perfectly prepared, but it needs to be prepared well enough to make decisions.
The decisive question is: Can we make clean decisions?
Go through the following points honestly:
Target Clarity
Can you explain in one or two sentences which problem the ERP is supposed to solve and how you will measure success? Or does the goal sound more like “more transparency”, “better processes”, and “integrate everything”?
Scope and Phase 1
Is it clear what is deliberately not part of Phase 1? Or does the scope grow with every conversation?
Process Understanding
Do your departments describe the same workflows in a similar way? Or do sales, warehouse, procurement, finance, and management already contradict each other when asked how the process actually works today? Have you looked at the processes in practice?
Special Cases
Do you know the 20 percent of cases that create 80 percent of the complexity? Or do critical exceptions only appear late in the project?
Prioritization
Is there someone who can make binding decisions? Or does everything have to be “discussed again”?
Internal Responsibility
Does your ERP owner truly have time, mandate, and backing? Or is the project running alongside day-to-day work?
Customization Understanding
Do you discuss solutions early before it is clear whether the problem should be solved that way at all? Or do you first check whether process, standard, and business case fit together?
Data Ownership
Are there clear owners for data quality? Or is data migration a technical side project that “someone” will take care of?
Testing
Do you test real workflows with real roles and special cases? Or do you only check whether individual functions basically work?
Operations After Go-Live
Do you know how the system will be run and continuously improved afterwards? Or does planning end at go-live?
Interpretation
If you are unsure on several of these points or answer “it depends”, then you probably lack more than preparation. You lack decision readiness in the setup.
And this is exactly where most projects fail, because they run alongside the normal business. Everyone is busy and everyone wants progress. But hardly anyone has the time to make the necessary decisions properly.
Typical Trade-Offs You Need to Clarify Early
ERP projects do not become more stable because every tension disappears. They become more stable because trade-offs are made consciously.
Speed vs. Stability
A fast go-live sounds good, but too much scope makes it worthless. Ask instead: What can we bring live quickly without overwhelming the organization?
nternal vs. External
Internal knowledge is important, external breadth is often more efficient. So ask instead: Which responsibility must stay internal, and which expertise should we add externally?
Standard vs. Customization
Standard reduces complexity, customization can create value. So ask yourselves: Where does real business impact emerge, and where are we only rebuilding old workarounds?
Big Bang vs. Phased Model
A big bang looks decisive, but phased models usually win in reality. So look carefully at this question: Which first wave creates enough value without overloading the project?
Feature Request vs. Process Decision
A feature request sounds concrete, while a process decision is often more uncomfortable. Ask: Do we really need this function, or do we first need to decide how we want to work in the future?
A Simple Decision Framework
If you do not yet have a clear target state: Do not start implementation. Do discovery.
If Phase 1 is supposed to include everything: Reduce the scope.
If you do not have an internal owner role: Clarify the project setup before a partner starts working.
If processes are only known at workshop level: Look at the work where it actually happens.
If special cases appear late: Do not only test functions. Test real workflows.
If customization becomes the default answer early: First check process, standard, and business case.
If nobody owns data quality: Define owners, rules, and binding data sources.
If nobody is responsible after go-live: Build an operating model with backlog, prioritization, release rhythm, and follow-up training.
Conclusion: The Most Important ERP Decision Is Not the Tool
Of course, system selection matters, but it is not where ERP projects are won.
A good ERP project is created through the decisions before and after: target state, process understanding, scope, ownership, capability building, data quality, testing, and continuous improvement.
That sounds less spectacular than big software promises. But that is exactly where the difference emerges between a system that has been introduced and a system that truly becomes the backbone of the company.
FAQ: How to Start an ERP Project Successfully
When Is a Company Ready for an ERP Project?
A company is ready for an ERP project when it is not just looking for a new system, but is ready to make decisions. That means the target state, core processes, internal responsibility, data quality, Phase 1 scope, and operating model after go-live are clear enough to make meaningful decisions. The setup does not need to be perfect, but it cannot be completely open.
What Should Be Clarified Before an ERP Implementation?
Before an ERP implementation, at least the following points should be clarified: What should become operationally better? Which processes are critical? Who decides internally? What belongs in Phase 1? Which data is binding? How will testing work? And who will run the system after go-live? Without this clarification, implementation quickly becomes a collection of requirements without clear direction.
Why Do ERP Projects Fail So Often?
ERP projects rarely fail because of software alone. More often, they fail because of unclear processes, excessive scope, missing internal responsibility, poor data quality, premature customization, unrealistic testing, or a missing operating model after go-live. The system is implemented, but it is not truly embedded in the organization.
How Big Should Phase 1 of an ERP Implementation Be?
Phase 1 should be large enough to create real operational value, but small enough to be implemented, tested, and understood properly. A good first wave creates a stable core. It does not need to perfect the entire company. Topics that are important but not critical for the first go-live belong in a prioritized backlog.
Should an ERP Project Be Implemented Internally or Externally?
In most cases, a hybrid setup works best. Internally, the company must own the target state, prioritization, process decisions, data quality, and acceptance. Externally, methodology, architecture, specialist expertise, integrations, QA, technical implementation, and enablement can be added. A fully external setup often creates dependency. A fully internal setup often lacks the necessary breadth.
Which Internal Role Does a Company Need for an ERP Project?
A company needs an internal owner role that understands processes, can moderate decisions, and translates between management, departments, and implementation. This person does not need to be the most technical person in the company. Mandate, time, prioritization ability, and backing from management are more important.
Why Is Data Quality So Important in ERP Projects?
Data quality determines whether people trust the ERP. If product data, inventory, customer data, or posting logic is unreliable, shadow lists, manual checks, and distrust in the system emerge. Data quality is therefore not a technical side task. It is leadership work.
How Should an ERP Project Be Tested?
An ERP project should not only be tested through functions, but through real workflows. Good tests play through real scenarios with real roles, handovers, and special cases. This shows whether the system works in day-to-day operations and whether employees understand what they need to do and when.
What Happens After ERP Go-Live?
After go-live, the actual operating phase begins. This requires follow-up training, a prioritized backlog, clear responsibilities, regular decision rounds, and a clean release rhythm. Without this operating model, continuous improvement quickly turns into an unstructured support process.
Is Customization Bad in ERP Projects?
No. Customization can make sense when it has a clear business case and supports a real process advantage or competitive advantage. It becomes problematic when it comes too early and only digitally rebuilds unclear processes or old workarounds. Before every customization, the team should check whether it is truly solving a system problem or merely covering up a bad process decision.
More articles
Switching ERP from weclapp, Xentral or JTL to Odoo: How companies migrate cleanly (process, risks and common mistakes)
ERP Implementation: 7 Risks That Make Projects Fail (and How to Spot Them Early)
Best-of-Breed vs. Best-of-Suite in Mid-Market: HubSpot vs. Odoo in a Reality Check
Controlling ERP in E-Commerce: How to Scale Without Losing Financial Control
Customer Service ERP: How to Integrate Service, ERP and Logistics Properly
E-Commerce Accounting ERP: When 60,000 Monthly Bookings Break Your System
E-Commerce Logistics & ERP: Why Fulfillment Becomes Structural at Scale
E-Commerce Inventory Planning: Why It Breaks at €20M and How to Fix It
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH