Complex ERP projects: why they fail, and how to succeed with Odoo

Complex ERP projects: why they fail, and how to succeed with Odoo

Having delivered over 120 Odoo projects and supported some of the most complex architectures on the market—spanning multiple subsidiaries, countries, or dense application ecosystems—we have reached an unequivocal conclusion: the challenges in an ERP project rarely stem from the software itself. Rather, they arise from how decisions accumulate over time, combined with a chronic inability to manage the various, overlapping layers of complexity—whether business-related, technical, or organizational.

Faced with this web of interdependent constraints, traditional integration methods—from rigid "V-model" frameworks to poorly executed agile approaches—quickly reveal their limitations. In fact, Gartner predicts that by 2027, more than 70% of recently deployed ERP projects will fail to fully achieve their initial business objectives.

The organization then finds itself trapped by a system that has become overly cumbersome and rigid—impossible to update without risking total breakdown—and completely disconnected from the teams' daily operational needs. An ERP system, initially approved by the executive committee as a strategic investment and a driver for growth, instead transforms into a major technological liability, becoming the primary obstacle to the organization's agility.

Below, we outline what we observe in the field, along with the principles we have formalized to prevent such stagnation and effectively tame this complexity.

Where does the complexity of an ERP project really come from?

A project is not complex simply because it has a large number of users. Volume is a matter of infrastructure sizing—a well-understood challenge that can be addressed using established methods.

True complexity is of a different nature and manifests across three areas:

Business complexity: This involves critical processes that fall outside of any standard model, such as:

• just-in-time logistics featuring cross-docking and high-speed dynamic picking;
• advanced financial engineering (handling multiple tax jurisdictions, triangular intra-community invoicing, pivot currencies, and consolidation);
• end-to-end industrial traceability—essential in sectors like food processing, medical devices, or aerospace—where a single batch error can bring an entire production line to a standstill.

Technical complexity: An ERP system never arrives in a vacuum; it must interact with an existing ecosystem, including:

• automated machinery and warehouse control systems that generate thousands of messages per minute;
• Product Information Management (PIM) systems with complex, multi-layered variant matrices;
• e-commerce platforms that experience asynchronous traffic spikes;
• legacy applications whose data formats must be translated without any loss of integrity.

Every interface acts as an implicit contract between two teams that may not always communicate effectively.

Organizational complexity: This is the most underestimated—and by far the most decisive—factor, typically arising in environments with multiple subsidiaries, countries, or ERP systems. It plays out on two levels. The first is convergence: getting various entities—each with its own operational culture, language, and legal obligations (often resulting from external growth)—to adopt a single "core model," all while ensuring that the factors driving their local performance remain intact. The second is adoption: an ERP system is not truly adopted simply because it has been deployed; it is adopted only when it proves to be more efficient than the spreadsheet it replaces. These are two distinct questions, and they are addressed using different methods.

How asphyxia sets in

The undecided specific

Custom development is not inherently a problem. In complex projects, certain customizations are entirely justified—they represent the very elements that provide a company with its competitive edge. Rejecting them on principle would result in an ERP system of little practical value. The goal has never been to avoid custom development altogether; rather, it is about determining which customizations to implement, why they are needed, and what they will cost.

The real issue arises with custom developments that are implemented without a formal decision-making process. When every request from the field is handled in isolation—often under tight scheduling pressure—without weighing the expected benefits against the long-term maintenance costs, these customizations accumulate without any overarching strategy or oversight. While each individual change might seem justifiable on its own, the cumulative result has never been vetted or approved by anyone.

After a few months, "side effects" begin to emerge. A modification disrupts a related function; one fix necessitates another. The system evolves into a complex, fragile structure that no one dares to touch, because no one can explain what was changed or why.

This is precisely why a formal decision-making body is essential. With such a process in place, every customization becomes a documented choice: its value is understood, its long-term cost is accounted for, and the rationale for selecting it over a standard, out-of-the-box alternative is clear. Without this, the accumulation of customizations isn't a deliberate strategy—it is merely an outcome that is eventually discovered.

There is also a technical aspect to consider. Odoo features a built-in inheritance mechanism that allows for the extension of models or views without altering the core system. When a customization is developed in haste and bypasses this mechanism, the side effects may not be immediately apparent. They often surface only several modules later, leaving no one to connect the dots. This is a matter of professional discipline for the integrator—a standard that must be upheld from the very first weeks of the project.

Technical debt that makes upgrading versions painful

Odoo releases a major version every year. The standard software is migrated by the vendor—a task they handle well. Custom developments, however, remain the responsibility of the project team with every version upgrade.

It is important to clarify what kind of custom development is being discussed, as not all are affected the same way by a migration—a distinction rarely considered during the decision-making process.

A module that introduces its own objects, data model, and screens generally handles version upgrades quite well. It relies on the framework rather than the internal behavior of a vendor-provided module. While porting such a module still requires effort, the process is predictable and can be quantified.

Developments that modify the behavior of the standard software are of an entirely different nature. Overriding a calculation method, altering a native workflow, or hooking into the internal logic of a vendor module creates a dependency on code that evolves with every version—sometimes in ways that are not explicitly flagged as breaking changes. This is where the bulk of migration costs and risks are concentrated.

This distinction has a direct impact on design. For any given requirement, it is better to build alongside the standard software rather than within it. This is an architectural trade-off that must be addressed during the design phase—not at the time of migration, when it is already too late.

In our projects, we typically allocate approximately 15% of the initial cost of a custom development per year to cover its maintenance and porting. This is an average, and the variation between the two types of development mentioned above accounts for most of the disparity. Across a portfolio of dozens of custom developments accumulated over the years, this line item becomes a permanent budgetary fixture—eventually dictating decisions rather than allowing strategy to lead the way.

The dilution of functional responsibility

The proliferation of committees and the involvement of multiple service providers often lead to the same conclusion: no one is left to guarantee the overall consistency of the data. When responsibility for the quality of a master dataset is shared among ten different teams, it effectively belongs to no one. Data flows fall out of sync. Decisions are deferred until they become technical *faits accomplis*.

A complex project rarely fails due to a lack of competence. It fails because no single body has the explicit mandate to make the final call.

The silent bypass

This latter mechanism does not appear on any dashboard, because it occurs after the system has gone live—and because no one reports it.

The system is up and running. The indicators are all green. Meanwhile, the teams have rebuilt a parallel layer of spreadsheets, shared files, and email-based approvals just to get their work done. The ERP system is reduced to a tool for retroactive data entry; it merely records information rather than driving operations.

People don’t revolt against software; they simply take the path of least resistance. If that path bypasses the system, then the project has failed to meet its objective—even if every single milestone was reached.

What Odoo makes possible in the face of complexity

Having been an Odoo partner for 18 years, we made this choice for a specific reason. The mechanisms described above are not unique to Odoo; they can be observed across all platforms on the market. What sets Odoo apart is the room for maneuver it provides to avoid them. From our perspective as an integrator, here is what truly matters.

A hybrid architecture: standard ERP and development framework

Odoo is both a comprehensive ERP system and an open-source development framework. This duality has a practical consequence: when a requirement falls outside the standard scope, the extension is built within the same technical environment as the rest of the system—utilizing the same inheritance mechanisms—rather than as a makeshift, peripheral add-on. This is what allows for custom developments that remain migratable.

At the same time, this necessitates the discipline described later on; if left unchecked, this same freedom can easily lead to the very kind of "layered mess" mentioned earlier.

Readability and open source

Access to the source code is not an ideological argument; it is an operational one. It transforms the nature of architectural work in two key respects.

Regarding internal performance: Direct access to the code makes it possible to audit generated queries, understand why a process slows down when handling hundreds of thousands of records, and optimize the system from within—all without being hindered by a "black box" effect or relying on vendor support.

Regarding ecosystem interconnection: Odoo’s objects are accessible from the outside via native APIs, and the data model is both documented and transparent. When dealing with large volumes, the API may not be the ideal channel, necessitating an intermediary layer. The crucial difference is that this layer can be designed with a precise understanding of how the underlying system behaves—an advantage not possible with a closed platform.

Modularity for a phased deployment

Odoo consists of applications that can be activated independently on a common foundation. This allows for a phased rollout—by subsidiary or by business activity—rather than an all-at-once, company-wide transition. For instance, you could activate accounting and sales for one subsidiary, heavy manufacturing for another, and e-commerce for a third, all while maintaining a unified and consistent database.

In a multi-entity environment, this significantly reduces the risks associated with going live. However, it requires rigorous design of access rules and intercompany workflows during the scoping phase; otherwise, the apparent simplicity may come at a cost later on.

The Smile methodology: three pillars that we apply

To harness the power of Odoo in a complex environment—without falling into the trap of becoming overwhelmed—Smile employs a rigorous methodology based on three pillars.

Pillar 1: IT system urbanisation before functional aspects

You don’t start a large-scale project by configuring screens. That is a classic trap—one that creates the illusion of progress while the real, fundamental questions remain unaddressed.

We begin by mapping out the IT landscape (the "urbanization" of the information system). A complex project is, first and foremost, a matter of data flow, lifecycles, and transactional integrity—long before it becomes a matter of user interfaces. Defining the "master" system for each piece of data—identifying who creates it, who modifies it, and who consumes it—is what determines the overall performance and stability of the entire system. This phase is demanding; it produces no screens to show a steering committee, yet it is the very step that dictates the path forward.

In practical terms, this phase addresses questions that shape the entire remainder of the project. Where does a product record "live"—in the PIM or the ERP—and in which direction does synchronization occur? Which system holds the authoritative stock data when a warehouse management system (WMS) is in place? What happens when two systems modify the same piece of data within the same minute? These are architectural decisions—not mere configuration choices—and revisiting them once the build phase has begun carries a cost far greater than the time it would have taken to address them at the outset.

This is also where our unique positioning makes a difference. Beyond being an Odoo integrator and a Gold Partner, Smile is a comprehensive digital services provider. This means that the components surrounding the ERP—such as data flows and interfaces, e-commerce platforms, portals, data tools, and artificial intelligence applications—are all handled by the same teams and integrated within a unified architectural framework. In a project where an ERP system must coexist with around a dozen other applications, this continuity helps avoid the most common point of failure: a scenario where each service provider takes responsibility only for their own scope, leaving no one accountable for the connections between the systems. Our consulting division steps in at an early stage—whenever the issues at hand go beyond the simple choice of a software tool—to address matters such as the strategic roadmap for the information system or the target organizational structure.

Pillar 2: The Odoo Augmented Standard approach

The "standard-first" principle is nothing new. Software vendors champion it, and integrators—ourselves included—advocate for it. What distinguishes one project from another is not the principle itself, but rather what happens when adhering to it becomes costly—when a specific requirement doesn't fit, a milestone is just three weeks away, and building a custom solution seems faster than searching for an existing one.

What we call the "Augmented Standard" is our methodological response to this precise moment. Any requirement not met by the core system follows a strict, invariable hierarchy:

1. The Odoo standard—which may involve adapting business processes to the tool, rather than the other way around.
2. Our own library of existing applications, provided a solution already exists and is actively maintained.
3. Community modules from the OCA (Odoo Community Association) ecosystem, selected from a certified catalog with a clearly identified maintainer.
4. A custom extension, built using the platform’s inheritance patterns and—whenever possible—developed alongside the standard rather than embedded within it.

This final level is not a failure of the methodology; it is its logical conclusion. A custom development that reaches the end of this chain is one for which we know no other solution existed, and which has been designed to remain compatible with future version upgrades.

This hierarchy is only effective if two conditions are met:

• Sufficient time spent upfront with an expert who truly understands the standard and can propose alternative approaches.
• A designated authority capable of making a final decision when disagreements persist.

Without these two conditions, the hierarchy remains nothing more than a paragraph in a methodology document.

Pillar 3: Governance of functional decision-making

The initial filter is not a formal committee, but rather a two-person team. A business stakeholder and a Smile business analyst work on the requirement together, first seeking a standard solution—such as adjusting configuration settings, finding an alternative workflow within the tool, or perhaps even modifying the process itself. Most requests are resolved at this stage, which is where the bulk of the work takes place.

Only those requests that survive this initial review are escalated to the "Design Authority." The two-person team presents the case together, explaining what was attempted and why it did not yield a solution.

Three roles make the final decision: the Smile engagement manager—who will deal with the day-to-day consequences regarding the schedule and budget; an enterprise IT architect (from either Smile or the client, depending on the organizational structure), who ensures technical consistency and assesses the request’s impact on the overall architecture and future version upgrades; and finally, the client’s program director, who balances business needs against the budget and provides the ultimate approval. This last point is crucial: the decision-making power remains with the client. Our role is to provide clarity and—when necessary—voice any disagreements, rather than making decisions on the client's behalf.

Those who prepare the case are not the same people who make the final ruling. This is not a matter of distrust; a request that is perfectly legitimate from a specific business perspective may have significant structural implications for the entire system, and someone must evaluate it from that broader vantage point.

The operational rules are intentionally rigorous: weekly sessions during the build phase, a fixed time slot (even when the agenda is empty), and a maximum of thirty minutes per case. If a case exceeds this time limit, it is considered poorly prepared and is sent back for further review.

This framework has a beneficial side effect: the business analyst is never the one who has to say "no" to their business counterpart. Instead, they have worked together to build the case and have advocated for it side-by-side. It is the governing body that makes the decision, and the operational relationship survives within that framework.

These three pillars are positioned within the frame.

None of these three elements can be successfully implemented once a project is already underway. Enterprise architecture loses its purpose once the build phase has begun; the hierarchy of an "augmented standard" (a standard extended by necessary customizations) ceases to be effective once the first bespoke components have already been delivered; and a "Design Authority" established merely to put out fires lacks the same standing as one defined from the very start.

This is why we consistently recommend a formal scoping phase prior to the project. This process produces a map of data flows and master systems, a gap analysis between actual business needs and the established standard, and a deployment roadmap—along with the governance bodies required to support it. If this scoping reveals that bespoke customizations are set to become the rule rather than the exception, it is far better to discover this at that stage than six months down the line.

Diagnosis: what is the status of your system?

Whether it stems from business, technical, or organizational factors, complexity is not inevitable—but it does demand an uncompromising architectural discipline. The following questions will help you assess the current state of your system, regardless of the ERP platform it runs on.

1. If your core technical team were to leave tomorrow, could you explain how data flows and transforms between your various applications and your ERP?
2. Do you know what proportion of your processes currently runs on unmodified, standard software? If no one can answer this, that in itself is a significant insight.
3. Regarding custom developments already in production, do you know which ones alter the behavior of the standard system, and which ones operate alongside it?
4. Have your teams been working on specifications for more than six months without a single end-user having interacted with the tool using real-world data?
5. Have your teams created external, shared files to handle tasks that the ERP was intended to manage?
6. Are your deployments still carried out manually, lacking an automated testing suite to ensure no regressions occur within the ecosystem?

None of these questions are merely theoretical. Each one reflects a situation we have encountered in live, production systems—and each is far easier to address the sooner it is identified.

Conclusion: Securing the path for your Odoo ERP with Smile

The success of a complex ERP project depends less on the choice of platform than on how well three key areas are managed: defining data flows before designing user interfaces, establishing the boundary between standard functionality and custom development, and having someone whose specific role is to enforce that boundary—even when doing so becomes uncomfortable.

Odoo makes this discipline possible; it does not replace it.

If any of these questions caught your attention, write to us. We will share our thoughts on them.