20 key learnings about ERP implementations

Reading Time: 8 minutes

ERP implementations are heavy stuff! Many organizations struggle to get the intended value out of an ERP project. Although there is no universal ‘recipe for success’ for ERP implementations, we can learn from and avoid many of the pitfalls that show up project after project.

In this post, we want to address the 20 most common pitfalls AND HOW TO TACKLE THEM. We have ordered them according to the SAP Activate methodology phases. 9TEAMS brings SAP Activate to live and allows you – and all stakeholders involved – to collaborate on roadmaps, issues, requests, tasks, scenarios, and so much more.

DISCOVER

#1  WHY DO YOU HAVE TO START THAT PROJECT?

Do you have a solid business case? Are the financials looking nice?
That’s good, but not enough!

Replacing one system with another is just not enough! Inspire your stakeholders to change by showing them “what’s in it for them”!

Make sure you explain why asking for an astronomical effort from the people in the organization will result in added value for the organization.

What do you want to achieve and why is it worthwhile?

  • Develop the story that motivates stakeholders to tackle the tough journey ahead.
  • Create a framework for efficient and effective decision making.

Communicate, Communicate, Communicate! You should be selling your project continuously. This does not stop until the project has been closed.

Are our posts inspiring you? Sure you will be impressed by our cloud solution to accelerate ERP implementations, powered with ERP methodologies, templates and best practices. Learn how it works here.

#2  IS YOUR BUSINESS READY FOR THE CHANGE?

Success does not come overnight. Be aware: business IT projects = business transformation

How do you evaluate business readiness before starting your project?

  1. pain and awareness: can we convince stakeholders there is a link between the project and alleviating the daily pain they are experiencing?
  2. organizational stability: a high employee or role turnover substantially increases the organizational risk involved.
  3. organizational discipline: does the organization work in a structured and controlled way? the higher the organizational discipline, the lower the organizational risk
  4. post implementation review of previous projects: how did the organization perform during previous and similar projects? what were the ‘lessons learned’?

Clearly define the organizational scope that will be involved and define the impact (both positive and negative) as clearly as possible. Who will be impacted and how?

Be aware that there is always a limit to the amount of change humans and organizations can handle. Don’t change too much all at once!

PREPARE

#3  DIVIDE SCOPE AND CONQUER

Reduce initial project scope and focus on key areas first. Move optimizations and non-key areas to later incremental stages whenever possible.

Rule of thumb: Don’t involve business users for longer than 9 months on a project!

Break projects into phases and treat your milestones as deadlines. Something valuable and tangible has to be delivered at every milestone.

We’re always more productive working within a limited time frame and budget. If your project comes under pressure, leverage scope before budget and time (deadline), not the other way around.

 

#4  AVOID RESOURCE FRAGMENTATION

What’s good for your external consultants is not always good for your project.

Try to reduce the number of consultants working on your business IT project. Generally, it is better to do the project with 2 consultants than to do the same project with 4 consultants.

  • Context switching between your project and other projects is very costly!
  • Lower commitment/involvement/overview increases risk.

Fix your (external) resources:

  • screen them and evaluate the fit with your project and the team
  • fix them on your project
  • avoid consultant switching without your approval

 

#5  REGULAR STATUS REVIEWS

Preparation and planning without regular follow-up is useless. Every transition between project phases has to include a status review. Status reviews should have a fixed and repetitive structure. This will allow for more effective decision making.

  • Overall status (progress, time, scope and budget)
  • Progress against phases and milestones
  • Objectives/deliverables
  • Status per workstream
  • Risks and risk mitigation
  • Open issues
  • Open change requests

Don’t be afraid to adjust your plan when required. Decisions should remain flexible in lieu of new data.

Fix your review committees well ahead. It’s difficult to bring all of the decision makers together at one table.

EXPLORE

#6  KEEP IT VANILLA

Vanilla?

Preferring an activity or thing in its basic and unmodified state. Refers to vanilla ice cream. Used when expressing a preference for having something the traditional way.

‘I like my burgers vanilla, no mayonnaise or bacon for me please.’

Rule of thumb in business IT projects: the closer you stay to standard functionalities, the lower the risks, the higher the flexibility and the lower the (project/maintenance) costs. There has to be a very good reason to deviate. Be aware that a lot of bespoke developments are not being used in the operational setting. Changes are quite often requested because of a lack of understanding or a preference for the legacy system.

Are you really sure you need that custom feature or the modified process? What will be the consequences if we use standard functionalities? Why wouldn’t you start standard first and review the change request at a predefined checkpoint?

Document all change requests, their status and progress in a central project collaboration tool.

 

#7  DON’T DO WHAT USERS ARE ASKING YOU

Even if you are being paid to handle their requests, please don’t! Understand the problem and come up with a solution that works ‘end-to-end’.

Don’t throw options and alternatives to users, you only spoil project resources and harm confidence. Having a lot of system knowledge might look like an asset, but the real added value is being delivered when a solid solution can be provided that applies subject matter expertise and best practices on the problem area.

Change requests often reflect a lack of system understanding or reluctance to change. Tackle the root cause, not the symptoms.

 

#8  BUSINESS IS NOT INTERESTED IN MODULES AND FEATURES

Business talks processes, you should also. Business is not organized in modules, functionalities and features. Systems are.

  • Organize your project toward processes
  • workshops
  • training
  • documentation
  • work packages

#9  TACKLE HIGH RISK ACTIVITIES FIRST

If activities are being defined as ‘high impact / high uncertainty’, schedule them as early as possible in the project. This gives you more options to intervene and reduces the risk and uncertainty quicker during the project. Tackling ‘high impact / high uncertainty’ tasks early in the project, reduces the risk for missed deadlines and budget overruns.

Start as soon as possible with ‘master data preparation’, even if there is still a lot of uncertainty about the details. Accept no excuses.

Initiate critical developments with a high uncertainty factor first. Keep the easy and low risk developments for the end.

 

REALIZE

#10  EVERYTHING HAS TO HAVE A DEADLINE AND AN OWNER

Tasks don’t go on indefinitely and eventually somebody has to do the job …

Avoid delaying tasks to the point when there are no more resources available. Plan ahead so tasks are assigned an owner.

Make sure the local organization starts producing rather than consuming early in the project. What should/can be done now?

Not everything is equally important. Multitasking is a joke! Avoid doing too many things in parallel and reduce your work in progress.

Use collaboration tools to keep track of everything to be done.

Are our posts inspiring you? Sure you will be impressed by our cloud solution to accelerate ERP implementations, powered with ERP methodologies, templates and best practices. Learn how it works here.

 

#11  REMOVE DEPENDENCIES

A quote often heard: ‘I can only start with X, if Y has been done’. Unfortunately, in the end, nothing gets done.

Some examples:

  • I can only start preparing master data if I have full understanding of all the relevant fields and their use.
  • I can only start training the sales order flow when the production department can receive stock on production orders.
  • I can only start testing the PO flow when relevant master data is being migrated
  • I can only …

Is that really the case???

Progress is better than perfection. There is no valid excuse to delay work. Analyze how to remove the perception of dependency. Force and support people to take action.

Use to consultants to close gaps and remove (perception of) dependencies.

#12  FOCUS ON ROLES AND RESPONSIBILITIES

Don’t assume people automatically know their roles and responsibilities during and after the project. Document RASCI AS-IS and TO-BE from a process point of view and manage the gaps.

Code Description Explanation
R Responsible the person who executes the process
A Accountable the owner of the process to whom “R” is Accountable; the person with the authority to approve and sign off on the process
S Supportive a person who plays a supporting role in the process
C Consulted a person who provides information and/or expertise necessary to complete the process
I Informed a person who needs to be notified of results, but need not necessarily be consulted

Don’t accept a scattered RASCI where:

  • too many people handle the same process,
  • people have to handle too many processes.

This is a recipe for disaster.

 

#13  TRAIN IN A REAL-LIFE ENVIRONMENT

Training is about changing user behavior and installing new routines. This can only be done if training is conducted by simulating real-life cases in a real-life environment. Prepare a training environment where system (incl. devices), master data and the organization can be validated simultaneously. Users have to recognize and relate to their organization, their customers, their stocks, their item codes, … in the training environment.

Creating that ‘real-life’ training environment is the perfect preparation and validation for the cutover. Use that opportunity.

Train for process execution, not to become an expert in every single system functionality. Training is about doing, not about talking.

Don’t forget to train key users in the process of ‘exception handling’.

 

DEPLOY

#14  VALIDATE BUSINESS TRANSFORMATION

Training without exercising and validation is useless. It’s like going to university without having exams.

3 hours of training a day per user is the absolute maximum. Exceeding that limit is just a waste of time.

Train users in multiple training waves. Each wave has a training and an exercising phase. Test and score knowledge transfer and skill improvement after each training wave. Evaluation is based on what users have done, not based on what they tell you they can do.

Install validation and gatekeeping processes between waves.

#15  ADDING PEOPLE TO A LATE PROJECT ONLY MAKES IT LATER

If you expect to exceed your deadlines, reduce scope rather than add resources.

When people are added to a project, they mainly consume the time of the people who were already creating the bottleneck to the project delivery. The project also gets more complicated as it requires more alignment. As a consequence, your deadlines get pushed even further.

Don’t try to free up more budget or delay the go-live of the project, this jeopardizes the project. Reduce the scope when possible and work with split deadlines.

 

#16  PREPARE CHECKLISTS FROM THE BEGINNING OF YOUR PROJECT

There are lots of things to be done and so much that can be forgotten along the way.

Use supporting tools to create checklists per functional domain. Refer to them daily.

 

#17  DEFINE YOUR GO-LIVE CHECKPOINTS AND METRICS

How can we be sure that everything is under control after the cutover? Be aware that there can be a big delay between a problem occurrence and the problem becoming visible.

Who keeps track of what and when? Define the list of metrics before cutover. Make sure all stakeholders involved understand the importance and their role.

  • metric description
  • metric owner
  • frequency of checking
  • how to check
  • target
  • how to intervene in case of anomalies

RUN

#18  INSTALL REGULAR FOLLOW-UP

Conduct regular reviews and reports after cutover.

Are we realizing the planned benefits of the project? If not, why? What actions should be taken and by who?

Use informal contacts to understand how business is (mis)using the new system.

#19  CENTRALIZE ISSUES AND CHANGE REQUESTS

Define the procedures and organization to tackle issues and change requests.

Regularly review progress and status.

Use one supporting tool to achieve transparency and collaboration.

#20  ORGANIZE TRANSFER TO THE SUPPORT ORGANIZATION

What is the impact on roles and responsibilities? Is there an impact on issues and change request processes to follow?

Centralize documentation (training, changes, configuration, …) for easy access and distribution.

Provide additional training to support organizations.

Are our posts inspiring you? Sure you will be impressed by our cloud solution to accelerate ERP implementations, powered with ERP methodologies, templates and best practices. Learn how it works here.

LEARN MORE ABOUT ERP IMPLEMENTATIONS

3 reasons to implement an ERP system

5 tricks to improve the speed of an ERP implementation

Why is implementing an ERP so challenging?

One simple way to improve your ERP skills

Signup to the 9TEAMS newsletter today to receive one update per month.

* indicates required