Why I’m Cautious About the Word “Partnership” in ERP Projects
Many years ago, an IT Director I had the privilege of working with at Denner AG in Switzerland said something that I heard at the time but didn’t truly understand:
“ERP is a people business.”
Today, after many years in the ERP world, numerous projects, and countless conversations with customers, I believe I finally understand what he meant.
Interestingly, that realization has far less to do with software, technology, or processes than with a term that appears in almost every ERP project: Partnership
Why the Word “Partnership” Makes Me Think
In almost every proposal, presentation, and initial conversation, the word partnership eventually comes up.
Customers are looking for a partner. Service providers promise a collaborative, partnership-driven approach. Together, both sides aim to overcome challenges, develop solutions, and deliver a successful project.
At first glance, that sounds exactly right. Yet over the years, I have developed a slightly different view of the term.
Perhaps it comes from having been involved in so many ERP projects. Perhaps it comes from seeing the same patterns repeat themselves time and again. The more I think about it, the more I feel that the word partnership often fails to describe what ERP projects actually need. Because when I think of a partnership, I think of two sides bringing similar experience, carrying comparable responsibility, and having a clear understanding of what lies ahead.
In reality, that is rarely the case in ERP projects. A company may implement a new ERP system once every ten or fifteen years. Some businesses only go through the process once in their entire history. As an ERP provider, we support projects like these on a regular basis. We know where projects typically lose momentum. We have seen the discussions around master data, business processes, resource constraints, ownership, and competing priorities many times before. In many cases, we can identify potential risks months before they become visible to everyone else. For the customer, however, this is often unfamiliar territory. That is why I increasingly believe that customers do not necessarily need a partnership in the traditional sense. What they really need is guidance. They need someone who can help them navigate the project, provide direction when decisions become difficult, and take responsibility when it matters. Someone who does more than ask questions. Someone who helps find the answers.
There Was a Time When I Thought ERP Was All About Technology
When I started working in ERP, I would have answered that question very differently. At the time, I believed that the key to a successful project was choosing the right software, building the right architecture, and defining the right processes.
- Which system offers more functionality?
- Which solution is more modern?
- Which platform is best positioned for the long term?
Those were the questions that occupied my mind. And to be fair, they are still important questions today. But the more projects I have been involved in, the more I have realised that the decisions that matter most are often made somewhere else entirely. With established ERP solutions, we are often comparing systems that can all meet a company’s core requirements. Of course, there are differences. But those differences are often much smaller than many people assume. What frequently makes the difference is something that never appears in a requirements document: trust in the people on the other side of the table. The confidence that you can speak openly with one another. The belief that you will be able to work through difficult situations together. And sometimes, quite simply, whether the people involved are a good fit. I have seen many situations where customers had to choose between two solutions that were almost identical from a functional perspective. In those situations, the better feature rarely wins. More often, the customer chooses the team they feel most comfortable working with. And honestly, I do not think that is irrational. Quite the opposite. ERP projects are not software purchases. They are long-term relationships that often continue for many years.
What Happens After the Contract Is Signed Is What Really Matters
One observation has stayed with me throughout the years. Sales teams invest significant effort in building trust. They talk about goals, challenges, and expectations. Together, they develop initial ideas and create a vision of what the future could look like. Eventually, the customer makes a decision. And then the project begins. Suddenly, project managers, consultants, and developers take over. Presentations become workshops. Visions become decisions. Ideas become task lists. This is often the point where a subtle disconnect appears. Not because anyone is doing something wrong, but because the relationship changes. The customer has built trust with certain people and suddenly finds themselves working with a different team. At the same time, the real project work begins—and with it, the difficult decisions. We are not immune to this challenge either. That is why I believe it is essential to manage this transition consciously. Expectations should not be clarified only when problems arise. They should be discussed openly and early.
Many Customers Need More Guidance Than We Realise
Another observation has been confirmed time and again throughout my career. When projects run into difficulties, it is usually not because customers are unwilling to contribute. More often, they are being asked to do things that are difficult to accomplish without proper support. Many companies underestimate how much time an ERP project really requires. At the same time, service providers sometimes underestimate how difficult it is for customers to manage a transformation project while running their day-to-day operations. Customers are expected to document processes, make decisions, clean up master data, assign key users, and prepare workshops. All of this is reasonable. But we should never forget that these people still have a full-time job. This is where I believe a provider’s real responsibility begins.
Of course, every project requires commitment from the customer. Of course, decisions need to be made. But we should never forget that we are the ones who guide projects like these on a regular basis. For many customers, it is their first experience. That is why I firmly believe it is better to provide too much guidance than too little.
The Uncomfortable Truth Behind It
This is also where a tension emerges that is rarely discussed openly. Supporting customers closely takes time. It requires additional coordination, more communication, and often significantly more assistance than originally planned. From a commercial perspective, that is not always comfortable. From a project perspective, however, it is often exactly what is needed. I have seen projects stall because customers were expected to deliver work they simply could not complete without additional support. The outcome is usually the same: frustration on both sides. The customer feels left to figure things out alone. The provider feels that critical decisions are not being made. Yet the root cause is often not a lack of commitment. It is a mismatch in expectations about who is responsible for what. Many situations could likely be avoided if both sides discussed these expectations earlier and more openly.
What I Have Learned from This at OTE
Perhaps this is one of the reasons why I have deliberately approached certain things differently over the years. If I truly believe that ERP projects are ultimately shaped by people, then that belief should be reflected in how we deliver them. One thing that has always been important to me is that, as Managing Director, I never disappear completely from our projects. I am no longer involved in the day-to-day management of every project, of course. But I always try to stay connected. Not to monitor project managers or consultants, but to pick up on early signals. Anyone who has worked on projects for long enough knows that problems rarely appear overnight. Most of the time, they reveal themselves weeks or even months in advance. In conversations. In small comments. In subtle changes in mood. In uncertainties that initially seem insignificant. Those are exactly the signals I try to notice before they turn into real problems.
Another lesson I have learned concerns the balance between project effort and billing. Projects need to be commercially viable, of course. At the same time, I consciously try not to put financial pressure on our teams when it comes to supporting customers. It is important to me that consultants and project managers have the freedom to help when help is needed. Whether an additional hour can be billed or not is often far less important than whether the customer feels supported during a difficult situation. Those moments shape how a project is remembered. And they often determine how customers look back on the relationship years later.
And finally, I still try to stay in regular personal contact with as many customers as possible. Not because I want to make every functional decision myself, but because many things can only be understood through direct conversation. These conversations often reveal things that would never appear in a status report. You gain a real sense of how a project is actually being experienced, where uncertainties exist, and which topics are genuinely on the customer’s mind. Perhaps these conversations are one of the reasons why I am more convinced than ever that ERP is not a technology business.
Why AI Reinforces This Belief Even Further
In recent years, another topic has emerged that is fundamentally changing our industry: Artificial Intelligence. Today, it is difficult to find an event, industry publication, or software vendor that is not talking about AI, copilots, or autonomous agents. And I am convinced that these technologies will change the way we work. Many tasks will be completed faster. Information will be easier to access. Decisions will be better informed. Yet this development reinforces my original belief more than ever. Because the more powerful technology becomes, the more important the people behind it become. AI can analyse information. It can identify patterns. It can make recommendations and automate routine work.
What it cannot do is build trust.
It cannot sense when a customer becomes uncertain. It cannot recognise tensions between project stakeholders. It cannot build relationships or take responsibility when a project enters a difficult phase. The biggest challenges in ERP projects rarely emerge because technology fails. They emerge when people have different expectations, when change creates uncertainty, or when communication breaks down.
Perhaps AI will take many tasks off our hands in the future. If that happens, what remains will become even more important.
- Listening.
- Understanding.
- Guiding.
- Building trust.
These are the things that even the best technology will never replace.
ERP is, and will remain, a people business.
The longer I work on ERP projects, the more often I find myself thinking back to something my former IT Director once said. At the time, I saw ERP primarily as a technology and process challenge. Today, I am convinced that the factors that determine success often lie somewhere else entirely. Systems matter. Processes matter. Data matters. But in my experience, successful projects are built where trust exists, expectations are clear, and people take responsibility together. Perhaps that is the real role of a good ERP provider. Not simply to implement software, but to help people navigate change successfully. And perhaps that is exactly what my former manager at Denner meant when he said:
“ERP is a people business.”
