ERP implementation: an (im)possible challenge?
ERP implementation. When you think about it, does “Enterprise Resource Planning” come to mind, or does a distant voice start whispering “Warning: Exhaustion of Resources Possible”?
Don’t worry, if you’ve thought this at least once, it’s not just the classic and all-too-familiar fear of change; you are simply aware of the operation’s complexity and all its risks.
After all, given all the stories of failed implementations out there, it’s not something to be taken lightly.
Let’s start by assessing the context. “If you pull too hard, the rope breaks.” Well, in ERP implementations, there aren’t just two parties pulling, but three, and each one is tugging in their own direction:
- The project sponsor rightly leans toward respecting the budget and wants a high-quality system that reflects the standards and Best Practices proposed by the System Integrator as much as possible;
- The System Integrator, depending on the type of contract signed, tries either to maximize profit by offering as many customizations as possible, or to minimize their resources’ effort by proposing, in most cases, standard solutions that risk not fully meeting the Client’s requirements.
- Finally, the company workforce, the least heard voice of the three, fears change, unconsciously, and is therefore held back by the prospect of new working habits.
With all these forces at play, it’s no surprise that some ERP implementation projects end up resembling Stephen King novels, earning the title of horror stories. They are scary, but they help us understand the problems we might face. Let’s look at four of the most famous cases, one for each major issue.
4 implementation problems: 4 cases of failure
LIDL and budget overruns
In 2011, the well-known German low-cost supermarket chain embarked on an ERP implementation journey. The result? Seven years of work riddled with continuous budget overruns that reached 500 million euros, an abandoned project, and a return to the old management system.
Hershey Company: expected results vs. reality
Imagine buying a new car that is faster and more reliable, only to realize once you’re behind the wheel that it doesn’t deliver the improvements you expected: this is the exact situation the Hershey Company found itself in. The American chocolate manufacturer expected to reap several benefits from the ERP implementation; instead, precisely because of the new management system, its revenue dropped by 19% the following year.
Worth & Company: go-live, delays, and cancellations
For Worth & Company, a manufacturing business in Pennsylvania, the go-live date became a mirage: it was initially scheduled for November 2015, then pushed to February 2016, delayed again to 2017, until… that was enough! The company chose to pull the plug on the project.
Vodafone and disruptions to the end customer
Vodafone UK was fined 4.6 million pounds by British regulators because, due to a poor implementation of its new IT infrastructure, many users were not credited for the payments they made.
It is easy to talk about the problems that emerge at the end of a flawed or poorly executed process; it is much harder, however, to analyze them to understand their root causes. Naturally, in complex projects like the ones we are describing, there is no simple one-to-one problem-cause correlation. Instead, we often find ourselves facing different combinations of uncontrolled variables.
9 causes that can lead an ERP implementation to failure
1. Technical solution über alles
When a client company lets itself be driven too much by the technical solution during an ERP implementation project, a problem arises. Without an analysis of the organizational and social impacts of the proposed solutions, and without a thorough assessment of both the positive and negative effects on processes, as well as the influence on the organizational structure caused by redefining roles and responsibilities, the project is at risk of failing.
key users must be guided in their collaboration with the system integrator. It is necessary to draw a fine line right from the start between technical elements that are nice-to-have and those that are must-have. This is because these resources, being prone to strong resistance to change, will tend to classify everything possible as a must-have. This dynamic results in continuous requests for ad-hoc processes tailored to the specific requirements of their own department, eventually turning the new ERP system into a dysfunctional copy of the previous one.
Striking a balance between standardization and customization must be kept in mind from the very beginning, as it is a latent yet driving force behind the entire project.
2. Communication: the great unknown
During an ERP implementation project, it is only right that a limited number of people are directly involved. This group has been working on the project for several months, while the rest of the company workforce, sometimes, and mistakenly, only find out about the existence of the new system a month before the actual go live.
It is only natural for those who weren’t involved from the start to be less informed, but a total lack of communication about what is happening within the company is unacceptable.
Without regular “updates” to make non-key users feel like part of an ongoing change, the project risks collapsing.
Let’s remember that in any change process, we tend to focus on the negative aspects rather than the positive ones, especially when that change is imposed on us. For this reason, it is crucial to establish a well-structured communication flow that is, above all, tailored to the target audience you want to reach.
3. People do not have infinite energy
Like any resource on Earth, people (our KUs) do not possess infinite energy. Entrusting the project to a small, select group can become a major critical issue if the workload is excessive, especially during the initial phases of Business Blueprint and Project Realization.
Let’s take it a step further: imagine being a KU being spent in meetings for six hours a day, all aimed at defining the structure of the new ERP system. Once those six hours are up, you still must carry out all the daily tasks you couldn’t get to during the day.
At that point, what would your motivation look like? Would you feel involved in the project, or completely overwhelmed by it? The answer is simple.
It is precisely to avoid this dynamic that you need to perform preventive capacity workload analyses, as well as monitor and adjust the resources’ workload.
KUs are our best ambassadors; the more attention we pay to their motivation and workload, the more they will feel like an active part of the project. It is not enough to simply plan workloads on paper; it is essential (for motivational purposes) to ask them what their needs are. Setting up a regular interview schedule allows resources to communicate their difficulties and enables us to catch the full spectrum of emerging risks and dissatisfaction.
4. Thinking that the project is purely technical
Believing that a digital transformation project is just an IT project rather than a business project is a massive, and unfortunately very common, risk. This does not mean the project must necessarily be managed entirely by the business side, but it certainly must be viewed as something that impacts the company across the board. At the end of the project, we won’t just have new management software, but resources who will most likely have to adopt a new modus operandi, leading them to execute different processes and behaviors.
5. System integrator in the driver’s seat
In most cases, the technical expertise regarding the new ERP system does not reside within the client company but is the exclusive domain of the system integrator.
We can safely say that, in this interplay of roles, the system integrator finds themselves in a position of strength from which they dictate project governance, timelines, technical specifications, and can heavily influence the defined budget.
The client company, unfamiliar with the technical solution, thus exposes itself to the risk of endless timelines, non-essential software solutions, and out-of-control budgets.
6. Lack of risk management
The impact of an ERP implementation project should never be underestimated.
The risks it presents are not just technical but are deeply linked to both organization and processes.
The framework of responsibilities, for instance, is often treated as a standalone element, but it naturally shifts and reshapes itself because of the new IT structure. Frequently, the tasks performed by resources change master data might end up being managed by the sales department instead of administration, and the individual managers, rather than the HR department, might become accountable for the vacation request process.
7. The “Saboteurs”
In companies that use legacy management systems, department heads have generally had the time to build a set of tools over the years that represent their own knowledge management system. However, the moment the company decides to adopt an integrated management system, that entire wealth of information is migrated into the new platform. For some people, this feels like “losing power” within the organization, leading them to think: “Now that all the data is readily available in the new system, I will lose visibility.” This is where the dynamic of the “saboteurs” originates, individuals who do not commit 100% to the project because they view the arrival of the new IT infrastructure as a threat to their indispensability.
8. Are we sure we choose the right people?
The client company normally selects project figures based on their technical expertise and their availability or current workload capacity. Relying solely on these criteria can be a mistake; indeed, we must not forget that among the resources forming the project team, we also need to identify the change agents.
The difficulty, which is often underestimated when selecting these resources, is that not everyone is cut out to be a good change agent. They cannot just be technically skilled; they must be equally excellent on a social level, as they will be the project’s primary “ambassadors.”
They will be called upon to guide a large part of the company workforce through the transition, to keep the project team motivated, and to be the first to communicate the low-hanging fruits, the initial quick wins achieved thanks to the new system. Furthermore, they must accurately communicate the project milestones and, above all, dismantle the natural fear of change through their own positive attitude.
9. Process does not mean function
It frequently happens during process mapping that people think in terms of individual functions. For example, if the mapping concerns the sales function, the system integrator might only involve people from the sales department, when many aspects of that process can also impact administration and management control.
By its very definition, you are implementing an integrated system, which means the analysis phase must be integrated as well.
It is not enough to only involve the resources who are an active part of a specific function; you must also include everyone who is touched or in some way influenced by it.
The 5 Pillars for leading successful implementation
To avoid falling into one of the 9 problems, or having to solve them only as they arise, it is highly advisable for the client company to rely on a third-party partner, like Lenovys. A partner capable of supporting the implementation toward achieving the expected goals in terms of costs, timelines, and quality, while managing the entire change process.
This translates into a Change Management plan that, to be effective, must focus on the 5 pillars that form the acronym G.I.O.I.A.
1. Governance
Structuring project governance is of fundamental importance to keep the 3 main pillars steady: timelines, costs, and quality. At the same time, it will be necessary to steer the ship firmly in relation to 3 key stakeholders:
- the system integrator
- the client company
- the users
Governance means respecting deadlines, which requires defining a detailed Gantt chart.
Governance means risk mapping, which must be carried out at the beginning of the project, during it, and even beyond the system’s go live.
Governance means a Project Management Office (PMO) and therefore organizing meetings by creating cross-functional tables with the goal of thinking in terms of processes rather than functions.
True Governance is knowing how to manage in advance the organizational and social changes the project might bring, and especially the consequences they may have.
2. Integration
As previously mentioned, an ERP system is an integrated system, which means it should not be implemented by individual function or department.
Integration must be achieved in the most functional way possible in relation to the client’s structure and processes.
From the very early stages of the project, it is essential to work with the clear understanding that the new IT infrastructure will communicate across the board with other functions. Therefore, every code, master data entry, and process must be functional not just for oneself, but for one’s colleagues as well.
The less our resources understand this dynamic, the more we will end up working in silos, resulting in a dysfunctional ERP system.
3. Opportunity
Change must always be perceived as an opportunity for improvement, never as an impending disaster!
The skill of the project sponsor and the third-party partner lies in making people realize that change is an opportunity for both the company and the individual resource. It is a chance for growth and improvement that allows them to expand and update their current skills, as well as learn new ones.
The attitude displayed by high-level executives and project sponsors is crucial. Following the golden rule of “leading by example,” the more key users see their superiors acting as active agents of change, the more motivated and enthusiastic they will be.
It is essential from the very beginning to establish tools and touchpoints aimed at helping resources realize the advantages they are already gaining from the project. This ensures they are fully aware of the benefits resulting from all the hours they are personally investing in the ERP project.
4. Identity
Every organization has its own identity. For this reason, it is crucial not to simply copy and paste solutions tout court, and for the third-party partner to deeply understand the company’s identity.
Identity is not just about processes (highly customized processes) but also about culture. This means that the exact same issues can be approached differently in different contexts. For example, depending on the company, the selection criteria for working groups in certain phases may vary.
For businesses with a highly rigid structure, it will be more effective to form working groups by selecting people who already work closely together, whereas for more “fluid” organizations, cross-disciplinary groups can be structured.
If you don’t fully understand the corporate culture, there is a risk of system rejection: the solution is successfully implemented on a technical level, but on a social and cultural level, it hasn’t been accepted by the people who continue to use the old system.
Understanding the company’s identity means preventing the implementation from becoming a project success but a business failure.
Working on behavior is a guaranteed key to success. As Habit Management teaches us, it is vital to create the right cues and the right consequences so that the project becomes a pleasant and functional habit.
What can these cues be? A customized logo for the project name, a motivational video to play before every workshop…
The more powerful a cue means, the more it makes the people working on the project feel like part of a group, the stronger the social bond unites them and their commitment will be.
5. Alliance
The implementation must not be driven by a small, isolated group of resources.
It is a transformation that impacts the entire company. Through consistent communication, we create ongoing engagement and, consequently, an alliance across the whole workforce.
The clearer, more shared, and more appreciated the benefits and goals are by the group, the more united the project team will move, like an alliance, toward a single path to travel together. If that is the case, success will be well within reach.
“In the past, education-built identities were as solid as stone houses. Today, we need to build them like camping tents, designed to be folded up and moved.” – Yuval Harari
As Harari highlights, in today’s world, the only way to effectively navigate change is to create a solid structure that knows how to bend under pressure without collapsing.
How do you achieve this in a new software implementation project?
Use the Lenovys approach: build the foundations of this structure with G.I.O.I.A. and transform your ERP implementation from Exhausting Resource Pressure into Efficiency through Results Planned.
Article written by:
Gianluca Ferrari
già Partner e Executive Director Lenovys
With degrees in economics and clinical psychology, he has over 20 years of experience in strategic consulting, particularly in national and international projects focused on organizational change, talent acquisition, leadership development, and potential enhancement. As a Change Manager, he has led projects to define organizational models that support the achievement of corporate strategy, and to analyze the cultural impacts of corporate restructuring and generational transitions. He has worked in theretail andautomotive sectors, for luxury and fashion companies, and for the mechanical, steel, chemical, and service industries, as well as for banks and insurance companies. Since December 2021, he has been a Lenovys partner.
Federico Visca
già Senior Consultant Lenovys
With a degree in Work and Organizational Psychology, he began his professional career collaborating with the University of Turin on various organizational projects. Specifically, the creation and implementation of a Smart Working system at Ferrero.
At Lenovys, he has worked with a variety of clients across different industries to achieve technical and operational excellence, integrating the Habit Management methodology with the Lean Lifestyle framework.
Read more
