Quentin Mathonet

Quentin Mathonet

I first experienced Odoo from the inside for more than ten years, at a time when its promise was very clear: to give small and medium-sized businesses access to a complete, integrated and modern ERP without the costs, timelines or complexity traditionally associated with the major platforms on the market. The ambition was not simply to replace accounting software or a few Excel files, but to provide a unified environment covering the company’s essential functions: sales, purchasing, inventory, finance, manufacturing, projects, HR and even e-commerce.

That proposition remains highly relevant today. But the market and the maturity of the solution have evolved. We are seeing more and more mid-sized companies, as well as more structured groups, looking at Odoo to replace legacy systems that have become costly, fragmented or difficult to evolve. They are seeking greater flexibility, better integration between departments, a faster ability to adapt to growth and a more controlled total cost of ownership.

This shift broadens the opportunities, but it also raises the level of expectation significantly. A larger ERP project is never simply about deploying more applications or adding users. It often involves several legal entities, localization constraints, more sophisticated inventory and manufacturing flows, financial reporting requirements, more formal approval processes and an existing application landscape that must be assessed pragmatically. The question then becomes less ‘Can we install the software?’ and more ‘What operating model do we want to build, and what decisions is the organization prepared to make to get there?’

Moving to the integration side at Eezee has precisely allowed me to look at this with greater distance. At the software vendor, attention is naturally focused strongly on the product, its roadmap, its standard features and a methodology that must remain reproducible at scale. On the integration side, we are much closer to the company’s day-to-day realities: business constraints, data quality, working habits, exceptions accumulated over time, existing systems, but also the human and decision-making dynamics that directly influence the project.

This position also brings a particular responsibility: bridging the gap between the product’s capabilities and the client’s operational reality. That may involve verticalizing certain business processes or integrating systems that legitimately need to remain in place. But it has to be done with discipline. The goal is not to recreate the old system in a new tool, nor to develop a specific response to every request. It is to keep the standard wherever it brings simplicity, adapt only what corresponds to a genuinely differentiating or non-negotiable requirement, and connect only the systems necessary for the operational flow to function properly.

When a transformation does not produce the expected results, I therefore do not look first at the product, the method or the organization as though one of them alone had to be blamed. I start by analyzing the alignment between the three. A relevant product can be poorly positioned or sold with an unrealistic scope. A solid methodology can fail if decisions are delayed, priorities constantly change or the project moves forward without genuinely committed sponsors. And an organization can be highly motivated while lacking stabilized processes, reliable data repositories or sufficient availability from the business teams.

The first step is to check whether the project was properly scoped before it even started. Did we understand the industry, the regulatory constraints, the financial imperatives and the processes that actually make the company run? Did we distinguish essential needs from preferences inherited from the previous system? Were we transparent about the trade-offs between scope, budget, timelines and the level of customization?

Then the implementation method has to be examined. An ERP project needs clear governance, a sponsor able to arbitrate, an available client team, empowered key users and a realistic schedule. It must also include structured phases of analysis, design, configuration, data migration, testing, training, validation and post-go-live support. A successful implementation does not depend only on delivery speed; it depends on the quality of what is adopted and maintained after go-live.

Finally — and this is often the factor most underestimated on the client side, but also the easiest explanation on the integrator side — I look at the organization itself. Change cannot be carried only by the project team or the integrator. You need to understand who truly owns the processes, who is able to change them, which people need to be involved in decisions, and where legitimate resistance or concerns lie. Change management begins long before training: it starts the moment you explain why certain processes need to evolve, what the teams stand to gain and what is concretely expected of them. Involving them as early and as practically as possible in the project is essential to the success of the implementation.

For me, an ERP is a transformation lever, but it does not transform a company on its own. An ERP forces the company to confront what it could previously work around: unwritten rules, unreliable data and dependence on a few individuals. Success therefore depends on the quality of the product, the rigor of the method and the maturity of the organization, but above all on the consistency between those three elements.

Quentin Mathonet

An ERP does not transform a company by itself. It is better described as a revealer and an accelerator. It reveals what has never been sufficiently structured: processes based on habits rather than clear rules, contradictory data between departments, informal approvals, dependence on a few key people, or exceptions that have gradually become the norm as the company grows.

In many companies, dysfunctions remain invisible for a long time because teams compensate for them every day: with Excel files, WhatsApp exchanges, verbal approvals, personal spreadsheets or historical knowledge held by a handful of employees. As long as the business remains at a certain scale, that can work. But when an ERP is introduced, the organization has to formalize its rules: who creates an item, who approves an order, how a price is determined, when inventory is considered available, which data is authoritative, who can modify an accounting entry or commit expenditure. That is when the grey areas appear.

The ERP therefore does not create these problems; it makes them difficult to work around. And that is precisely where transformation begins. If the company agrees to challenge certain processes, clarify roles and make decisions, the ERP becomes a structuring tool. If it merely tries to reproduce the old way of working exactly, including its exceptions and workarounds, it may technically deliver the project on time while failing operationally.

The distinction is essential. A project may be considered ‘delivered’ because the modules have been configured, the data migrated and the users trained. But it is only successful when teams genuinely use the system as their reference, processes operate without relying on parallel files, and management can make decisions based on data that is more reliable, more consistent and more accessible.

That is why adoption should never be treated as a final step limited to a few training sessions before go-live. It has to be built into the project from the start. Key users should not discover the solution during final training. They should contribute to the choices, test the flows and become project relays within their teams. When they understand the rationale behind the changes and take part in the decisions, adoption becomes far more natural.

In my view, when an integrator believes a client is not yet ready, its role is to be transparent, to challenge and to protect the project, including when that means slowing down, reducing the scope or questioning certain requests. An integrator should not replace the client’s management or make internal decisions on its behalf. It does, however, have a responsibility to clearly flag the risks: lack of a sponsor, limited availability of business teams, unresolved decisions, insufficiently reliable data, an overly broad scope, unrealistic expectations or a determination to preserve every legacy exception.

In some cases, the right decision is to begin with a deeper scoping phase, data cleansing, clarification of roles and responsibilities, or a progressive rollout by flow, department, subsidiary or country. Postponing a go-live is not necessarily a failure: it can be a responsible governance decision if it prevents the long-term installation of a system that is poorly understood or rejected by teams.

The integrator therefore has to go as far as making the consequences visible and proposing a realistic path forward. It should be able to say: ‘Under these conditions, this is what is feasible, these are the risks, these are the decisions that need to be made, and this is what should be postponed or simplified.’ But it must also respect a boundary: it cannot seek to change the organization in place of its leaders. The transformation has to be carried by the client itself, with a sponsor who owns the trade-offs and provides clear direction.

Ultimately, an ERP becomes transformative when it forces the company to move from individual practices and implicit knowledge to shared processes, reference data and explicit responsibilities. Technology provides the framework, the integrator brings the method and perspective, but the organization has to agree to change for the project to truly have an impact.

Quentin Mathonet

I start from a very simple principle: not everything old is necessarily useless, but not everything old is a competitive advantage either. In ERP projects, you have to be wary of a frequent confusion between what genuinely differentiates the company and what teams have simply learned to work around or master over time.

A habit can be strongly defended because it is reassuring, because it gives a sense of control or because it is championed by a key person. But that does not mean it creates value. For example, an extra manual approval, a parallel Excel spreadsheet or a succession of commercial exceptions may have been justified at a given point in time. As the company grows, however, that same mechanism can become a source of slowness, errors, dependence on certain people and reduced visibility for management.

Conversely, some specific features are genuinely structural. They may stem from a particular business model, manufacturing know-how, a regulatory requirement, a pricing or service logic that differentiates the company in its market, or a constraint specific to its industry. In that case, trying to force everything into a generic standard can weaken precisely what creates value for the organization.

To tell the difference, we first examine the process’s actual contribution to the promise made to the customer, the quality of the product or service, the control of a regulatory or financial risk, or the protection of margin. We also ask whether it would remain relevant if the company doubled in size, opened a new subsidiary or replaced a significant part of its workforce. Finally, a genuinely structural process must be explainable, measurable and transferable. If it relies mainly on implicit knowledge, it is often more of a vulnerability than a competitive advantage.

If several of these criteria are met, the request deserves to be considered as a potential differentiator. But even then, customization is not automatically the right answer. We first need to see whether the standard can meet the need through appropriate configuration, process discipline or an organizational change. Development or integration should only be used when there is a real, lasting and significant gap between the business requirement and the solution’s standard capabilities.

That is where I draw the line: useful customization strengthens a distinctive capability, improves quality or execution speed, meets a non-negotiable obligation or removes a real source of friction without creating a new dependency. Conversely, it becomes a transfer of complexity when it mainly serves to preserve an old way of working, avoid an internal decision or maintain an exception that is neither documented, measurable nor capable of supporting growth.

The full cost of customization also has to be considered, not just its initial cost. Every development must be tested, maintained, documented, secured and kept compatible with future platform upgrades. Too many specific developments can slow adoption, make the tool harder to understand, complicate version upgrades and recreate the rigidity the company was trying to leave behind in the first place.

I therefore prefer a three-level logic. First, standardize what does not differentiate the company: administrative processes, master data, simple approvals and common flows should be as clear and consistent as possible. Second, configure when the standard can reflect the need without creating technical debt. Finally, customize in a targeted way only what carries durable and demonstrable business value.

This approach is not about imposing an ERP on the client. It is about helping the client distinguish its operational identity from its operational legacy. A good project should not erase what makes a company perform; it should eliminate what makes it difficult to manage, evolve and pass on.

The integrator’s role is therefore to challenge respectfully. It should be able to say: ‘We can technically reproduce this way of working, but before we do, let us make sure it still serves a strategic need and is not simply a historical constraint.’ The quality of an ERP transformation is often decided in that conversation. In short, good customization does not reproduce complexity: it protects a useful difference. Everything else should be simplified, standardized or challenged.

Quentin Mathonet

Saudi Arabia and the United Arab Emirates are geographically close, closely connected economically and driven by similar ambitions for digitalization, growth and the professionalization of businesses. Yet in an ERP project, treating them as a single market would be a mistake. The broad principles remain comparable, but the context in which a company makes decisions, organizes change and adopts new processes can be very different.

In the UAE, we frequently work with companies that have evolved in a highly international environment: multicultural teams, foreign shareholders or customers, operations spread across several countries, and long-standing exposure to international management and governance standards. This can make it easier to accept process standardization and a common operating model across several entities. Many of these companies have also grown rapidly by successively adding tools, Excel files and local processes. Their ERP need is therefore often to reunify information, consolidate data, reduce parallel operations and gain a more reliable view of the business as a whole.

In Saudi Arabia, we are seeing a particularly strong and rapid transformation dynamic. Ambitions around growth, diversification, industrialization and compliance are leading many organizations to rethink both their systems and the way they operate. ERP projects are often viewed as strategic infrastructure: not only to automate operations, but also to support expansion, strengthen governance, structure data and respond to an increasingly demanding regulatory environment. In Saudi Arabia, compliance — particularly around ZATCA and e-invoicing — is often a structural element of the project from the scoping stage onward.

That does not mean the UAE is systematically more mature, nor that Saudi Arabia is a less international market. That would be an oversimplification. The UAE has historically had strong exposure to international management models, but Saudi Arabia is also attracting a great deal of international talent and rapidly developing its own capabilities, organizations and standards. We are also seeing increasing movement of talent, practices and expertise between the two countries, as well as between the Kingdom and international markets. The difference is more a matter of trajectory, pace of transformation and organizational priorities than an absolute level of maturity.

This nuance is also visible in the way go-live is approached. In the UAE, we regularly see a phased rollout — by flow, department, legal entity or country — being well accepted. It reduces risk, allows processes to be tested in real conditions, incorporates user feedback and builds adoption step by step. This approach is particularly relevant when a group has several entities, when processes are not fully homogeneous or when the data needs to be made reliable progressively.

In Saudi Arabia, some organizations prefer a broader, big-bang switch. They see it as a way to move everyone quickly onto a single model, avoid an overly long coexistence between the old and new systems, and give the project a clear impulse across the group. This preference should not, however, be interpreted as a national rule. A big bang can make sense when flows are highly interconnected, the scope is under control, the data is ready and both the sponsor and business teams are genuinely mobilized. Conversely, it becomes dangerous when it is used to conceal a lack of preparation or unresolved decisions.

In my view, there is therefore no uniform methodology in the sense of an identical sequence for every country and every company in the Middle East. There is, however, a common discipline: a serious diagnosis, a target vision, a prioritized scope, clear governance, empowered key users, a data strategy, thorough testing, change management and strong support after go-live.

What varies is how this framework is executed: the pace, sequencing, degree of localization, working language, decision-making structure, compliance requirements and the levers used to secure team buy-in. An effective regional methodology must be structured enough to guarantee quality and capitalize on best practices, while remaining flexible enough to respect each client’s local reality.

In short, execution rigor can be standardized at regional level, but the context in which a company has to change cannot be standardized blindly.

Quentin Mathonet

There is indeed a tipping point, but it does not correspond to a particular level of revenue or a precise headcount. Two companies of comparable size can have completely different needs depending on their industry, transaction volumes, inventory complexity, purchasing or manufacturing flows, multi-entity footprint, regulatory constraints and pace of growth.

The tipping point appears when the tools that supported the early stages of growth no longer allow the company to operate reliably without substantial human compensation. At the beginning, it is normal for an organization to rely on accounting software, a few business tools, Excel files and very direct coordination between teams. The leader knows the customers, the exceptions, the priorities and the people who hold the information. That agility can be a strength.

The problem arises when the organization grows, volumes increase, new activities or entities are created, and the business still relies on the same informal mechanisms. The same information starts being copied into several systems, data is consolidated manually before every meeting, inventory is checked by phone or in Excel, a specific person has to be available to approve an order, a margin or a payment, or financial figures are produced several weeks after month-end.

At that stage, the information system is not necessarily failing in the technical sense. The tools may continue to work independently. But the company itself begins to stop functioning as a coherent whole. It no longer has a single, reliable source of data, teams create their own versions of reality, and management spends more and more time reconciling information instead of deciding and acting.

The first signal is therefore a loss of confidence in the numbers. When management asks for the actual stock level, the profitability of a customer, the orders to be delivered, expected cash receipts or the margin of a business line, and receives different answers depending on which department is asked, there is no longer a common source of truth. That leads to decisions that are slower, more cautious and sometimes simply wrong.

The second signal is the proliferation of tools and parallel processes. Excel and ERP should not automatically be set against each other: Excel remains a very good analytical tool. But when a spreadsheet becomes indispensable for creating an invoice, setting a price, calculating a commission, tracking inventory or consolidating management reporting, it becomes a critical part of the operational process without providing the necessary controls, traceability or continuity.

The third signal is dependence on key people. Some companies appear to operate well until the day someone goes on leave, leaves the organization or is simply unavailable. If nobody can reproduce a closing process, correct a price, identify the right version of a file, understand a margin calculation or follow an order without asking that person, growth depends more on individual knowledge than on a controlled process.

The fourth signal is that every new stage of development adds a disproportionate administrative burden. Opening a subsidiary, warehouse, point of sale, new e-commerce channel or product line should create capacity and value. If it systematically requires new files, new re-entry of data, manual controls and hires whose sole purpose is to reconcile information, then the model is no longer designed to scale.

There are also more subtle signals that the leader does not always notice immediately. Phrases such as ‘we need to check with Finance’, ‘the system stock is not always up to date’, ‘don’t use that report as your reference’, ‘ask that person’, or ‘the real tracking is in my file’. These phrases are revealing. They show that the actual processes are being carried out outside the official tools and that the company has begun to build a parallel organization, often invisible in management dashboards.

This is often where an integrator can create value before even talking about software. The role is not to sell an ERP as soon as an existing tool shows its limits. No system solves every problem. Our first role is to make the cost of fragmentation visible: the time spent reconciling data, delays in decision-making, invoicing errors, margin leakage, excess inventory or stockouts, cash-flow forecasting difficulties and the risk associated with dependence on certain individuals.

An ERP becomes genuinely relevant when the company needs to replace individual effort with a shared operating model: reference data, connected processes, clear approvals, better traceability and information available at the moment a decision has to be made. The right time to act is therefore not when the tools have already collapsed, but when the organization realizes that its growth still depends too heavily on its teams’ ability to compensate every day for the system’s limitations.

Quentin Mathonet

ERP integration is a business that cannot be industrialized like simple software production. Every client has its own history, business model, regulatory constraints, operational priorities, level of digital maturity and working habits. If the same solution is applied to every organization, you lose precisely what creates the value of an integrator: the ability to understand what is actually happening on the ground and to support a company through choices that can sometimes be complex.

That does not mean, however, that every project has to start from scratch. In my view, industrializing ERP integration means standardizing what should never depend on improvisation: how the project is scoped, how needs are understood and prioritized, how governance is built, how decisions are documented, how data is secured, how testing is prepared, how users are trained and how go-live is supported.

It is also important to capitalize on experience from one project to another. Most integrators gradually develop strong expertise in certain industries or operating models. That does not mean they cannot excel in other sectors, but they naturally become recognized for their understanding of specific issues, recurring flows and constraints that are particular to certain businesses.

At Eezee Saudi, one of our strongest areas of expertise is transport and logistics. We have built an industry vertical around Odoo, which we called ‘Logistics+’: a foundation that brings together processes, configurations, functionalities, technical components, test scenarios and best practices that have already been proven in this industry. This vertical allows us to start a project with a concrete understanding of the client’s realities rather than from a blank page.

Logistics+ can be deployed quickly, but it always has to be adapted. Every company has its own particularities: transport flows, pricing, contracts, traceability constraints, invoicing model and application environment. The vertical therefore never replaces the diagnostic phase. It provides a more robust foundation, but it must always be confronted with the reality of the organization.

Its first benefit is acceleration. We do not have to rebuild, for every project, functionalities that have already been proven, nor redefine the same flows or test scenarios from the beginning. This speeds up scoping, design, development when adaptations are required, testing, training and go-live. It also reduces risk: a functionality that has already been used and tested in a comparable context is generally more reliable than one designed in a hurry for a single client.

The second benefit is that the client gains not only a tool, but also the experience accumulated in its industry. A team that understands transport and logistics can ask better questions from the outset, identify points of attention more quickly, challenge processes that appear to be historical habits, and distinguish a genuine business-specific requirement from something that can be standardized. It is this industry knowledge that allows an integrator not merely to execute a request, but to genuinely advise the client.

Finally, an industry vertical makes it possible to enrich the solution over time. When an enhancement developed for one client meets a recurring need in the industry, and is sufficiently generic, robust, documented, secure and maintainable, it can be incorporated into the vertical and offered to other relevant clients. That creates a virtuous circle: every project feeds collective knowledge, and subsequent clients benefit from a richer solution and broader experience.

This is particularly important in the context of Eezee’s regional development and the integration of Solution Founder in Saudi Arabia, which became Eezee Saudi. The challenge is not simply to increase the number of projects we can deliver. It is to combine local expertise built on the ground with methods, resources, quality standards and execution capacity at group level.

This growth must not result in greater distance from clients. On the contrary, it should allow the right expertise to be mobilized at the right time: consultants who know the industry, finance profiles when decisions concern accounting, control or consolidation, technical experts when architecture or integrations require them, and local teams capable of maintaining close relationships with decision-makers and users.

We can therefore standardize strongly the elements that ensure execution quality: the governance framework, project management methods, deliverables, validation criteria, risk management, documentation, testing strategy and knowledge-transfer mechanisms. On the other hand, we should never blindly standardize our understanding of the client. Project sequencing, the level of customization, change management, necessary integrations and team composition must always be adapted to the organization’s operational reality.

For me, good industrialization means circulating experience, tools and best practices at regional level without eliminating business judgment and human proximity. A vertical is not a way of imposing a pre-packaged solution; it is a way of turning experience accumulated in the field into a value accelerator for the next client.

Quentin Mathonet

I do not think artificial intelligence will make the ERP integrator’s profession disappear. It will, however, profoundly change where its value lies. For a long time, users had to learn the logic of the system’s screens, menus, filters and transactions. Tomorrow, they will more often be able to query the ERP in natural language: ask for an analysis, obtain an explanation, search for information, identify an anomaly or, in some cases, trigger an action without navigating the traditional interface themselves.

That will simplify the user experience, but it will not make the ERP less important. I would even say the opposite: the simpler the interaction becomes, the higher the requirements for what sits behind it. An AI agent can only provide a reliable answer if it relies on consistent data, shared definitions, clearly modeled processes and correctly defined access rights. If the data is contradictory, if the margin calculation is not stabilized, if roles are unclear or if the real processes still take place in parallel files, AI will simply make those inconsistencies faster and more visible.

I therefore see AI as a maturity accelerator. It does not spontaneously fix a poorly structured organization; it amplifies the quality — or, conversely, the weaknesses — of the system to which it is connected. That is why ERP remains essential: it continues to be the system of record that organizes data, processes, validations, responsibilities and traceability.

Configuration will remain necessary, but it will no longer be enough. The integrator’s value will shift toward four areas: data quality, business rules, the rights granted to agents and the governance of automated decisions.

First, data architecture. You need to know which data can be exposed to an agent, which must remain confidential, which data is reliable and in what context it can be interpreted and used. An agent should not have indiscriminate access to all of the company’s data simply because it is connected to the ERP.

Then, business rules. AI has to understand what it can suggest, what it can prepare, what it can execute and what it must necessarily escalate to a human. There is a fundamental difference between asking an agent ‘show me the overdue payments’ and asking it to ‘automatically block orders from every customer who is overdue’. In the first case, it supports a decision; in the second, it makes a decision that can have commercial, financial and relationship consequences.

The third topic is permissions. An AI should be treated like a user or digital colleague with a defined role, a limited scope and precisely assigned rights. It should respect the same principles of segregation of duties, multi-company scope and confidentiality as human users. The principle of least privilege is particularly important: an agent should receive only the data and actions necessary for its task, not global access by default.

Finally, there is decision governance. Companies will have to define explicitly what level of autonomy they are willing to accept. Some tasks can be largely automated: categorizing requests, preparing a draft response, detecting inconsistencies, suggesting replenishment, creating a support ticket or pre-filling a record. On the other hand, decisions involving finance, pricing, payments, accounting entries, customer data, access rights or contractual commitments should, in most cases, retain human validation and an audit trail. Agent-governance recommendations converge on this separation between read access and the ability to act, as well as on the need to log access and decisions.

At Eezee Group, we have already started evolving our role in this direction. We have developed Eezee Harness, a secure environment specific to each client, in which our agents — as well as agents configured by the client — can operate with controlled access to flows, configuration and environment-specific code. The aim is to allow AI to provide genuinely useful context without giving it uncontrolled freedom to act on the production system.

Within this environment, Eezee Assist handles support-related topics: helping users, answering questions, analyzing problems, carrying out initial diagnostics, reviewing existing flows or code, and creating tickets for Eezee teams. The agent can accelerate incident identification and prepare the information needed to resolve it, but recommendations and any intervention that could affect the system remain subject to review by an Eezee consultant.

Eezee Harness also includes Eezee Build, which allows the client to express a functional requirement in natural language. The agent can then prepare or generate an enhancement in a secure environment, taking the existing technical and functional context into account. That enhancement is then deployed to a test database, evaluated and reviewed by our specialists before any decision is made to put it into production.

This approach makes it possible to accelerate support, analysis, design and the initial development work without removing the essential stages of an ERP project: testing, technical review, functional validation and business decision-making. AI makes the cycle faster and more accessible, but human expertise remains indispensable to guarantee the quality, security and relevance of what is ultimately deployed.

Over time, the integrator’s profession will therefore be less focused on the simple configuration of screens and more on designing a trusted environment. It will be necessary to connect data correctly, formalize rules, secure access, define validation levels, organize test and production environments, and be able to explain what the agent did, on what basis and under what authorization.

The real question is not so much what AI can do, but which decisions the company is willing to entrust to it, with what limits, what controls and what level of human responsibility. The integrator therefore has a central role in this discussion because it sits precisely at the intersection of technology, processes and governance.

Quentin Mathonet

Looking ahead to 2030, I think ERP will probably become less visible to some users, but much more strategic for the company. Those two developments may appear contradictory, but in reality they are complementary.

ERP as we know it today was designed around interfaces, menus, forms and transactions. Users had to learn how to navigate the system to find information, produce a report, trigger an action or follow a process. With agents and conversational interfaces, that relationship will evolve. For a growing number of use cases, employees will interact directly with an intelligence layer capable of understanding their intent, finding the relevant information and guiding them toward the appropriate action.

ERP will therefore probably become less visible as an interface. A user will not necessarily need to know which module contains a piece of data, which report to launch or which sequence of screens to follow. They will be able to interact with their work environment more naturally through a conversation, a recommendation, an alert or an automated process.

But making the interface less visible does not make the system less important. On the contrary, ERP will gain value as the company’s central infrastructure. It will remain the place where reference data is structured, where flows between sales, purchasing, inventory, manufacturing and finance are connected, where business rules are formalized and where operations retain their traceability.

The real evolution is therefore a change in positioning. ERP will no longer be only the tool in which teams work; it will increasingly become the platform from which they work. Conversational interfaces, mobile tools, customer portals, automations and agents may simplify access to the system, but they will all have to rely on the same operational foundation.

The most important consequence is that ERP will have to become more open, more composable and easier to query. Its value will no longer depend only on its screens or the number of its features, but on its ability to reliably feed the portals, mobile applications, automations and agents surrounding the company.

This is particularly relevant in a region such as the Middle East, where digitalization ambitions are very strong. Saudi Arabia’s Vision 2030, like the UAE’s digital-transformation and artificial-intelligence strategies, creates an environment that is favorable to the adoption of new technologies. But technology alone does not create a lasting advantage. It becomes genuinely useful when it rests on organizations capable of structuring their information, circulating data between departments and making decisions from a common reference base.

I therefore do not see AI as the disappearance of ERP. I see it as the gradual end of ERP being perceived only as an administrative interface. ERP will become less visible on the surface, but more central in its role as the operational backbone. As companies delegate more analysis, controls and tasks to agents, they will need an even stronger foundation of data and processes.

Tomorrow’s ERP may be less present on the screen, but it will be more present in every operation, every decision and every interaction between the company, its teams, its customers and its partners.