An Excel file that has become indispensable, an ERP that structures the main process, a CRM that carries the customer relationship \u2014 and yet teams still spend time reconciling information between these three tools. It’s a classic situation in SMEs and mid-market companies.<\/p>\n\n\n\n
When a tool shows its limits, the temptation is often to replace everything. That’s rarely the right answer. The right decision depends on the tool’s real role in the business process: what it does well, what it doesn’t cover, and what teams do around it to compensate.<\/p>\n\n\n\n
Because in reality, a tool never lives alone. It fits into an organization, into habits, into management rules that are sometimes very specific, and into an already-built information system. Replacing too quickly means risking the loss of part of what works. Doing nothing means letting workarounds multiply. Between the two, there is often a more pragmatic path: understand, secure, connect, or extend what already exists.<\/p>\n\n\n\n
Excel is flexible, quick to set up, and mastered by almost every team. It lets you test a calculation logic, structure a tracking system, build a dashboard without waiting for an IT project. That’s precisely why it has taken hold in places where no other tool has managed to dislodge it.<\/p>\n\n\n\n
In many companies, the most strategic Excel files are not makeshift jobs: they are full-fledged business tools that embed complex calculation rules, validation logic, and operational dashboards. They represent years of accumulated knowledge about the specifics of the business.<\/p>\n\n\n\n
This point matters. When an Excel file has been used for several years by a business team, it often contains far more than columns and formulas. It carries part of the company’s operational intelligence: known exceptions, commercial trade-offs, internal controls, the calculation rules the ERP doesn’t handle, or the indicators teams really need day to day.<\/p>\n\n\n\n
But as the process becomes critical, the limits appear. Multiple versions circulating by email, access rights impossible to manage finely, data-entry errors with no safety net, dependence on the one person who “knows how it works,” a total lack of traceability. It’s not Excel that’s at fault: it’s the usage that has outgrown what the tool can reasonably carry.<\/p>\n\n\n\n
It’s in this intermediate zone – between the file to secure and the business application to build – that expertise in Excel and business processes<\/a> takes on its full meaning. Depending on the case, it may be more relevant to make an existing file reliable, to wrap it in a web interface, or to progressively turn its logic into a business application.<\/p>\n\n\n\n An ERP structures the core functions: purchasing, inventory, accounting, production. A CRM organizes the customer relationship and the sales pipeline. These are essential tools, and there’s no question of calling them into doubt.<\/p>\n\n\n\n But they don’t cover everything. The calculation rules specific to your business, internal approval workflows, customer or supplier portals, interfaces tailored to specific business profiles: all needs that standard publishers cannot anticipate for every sector and every organization.<\/p>\n\n\n\n That’s where teams fill the gaps with parallel files, manual exports, and informal processes. Not because the ERP is bad, but because it cannot, by nature, cover the full range of each company’s specificities.<\/p>\n\n\n\n So the issue is not to choose between standard tool and custom development, as if the two had to be set against each other. In many cases, the challenge is rather to make the best of both worlds work together: keep the ERP or CRM for what they do very well, and add around them the building blocks that cover the differentiating business uses.<\/p>\n\n\n\n When a tool shows its limits, there are three possible responses. The choice between them depends on the diagnosis, not on a technological preference.<\/p>\n\n\n\n Replacing<\/strong> is justified when the tool is obsolete, unmaintainable, or so far removed from current needs that any evolution would cost more than a rebuild. It’s the heaviest decision, to be reserved for situations where the other two options are no longer viable. It may be necessary, but it means accepting a more structuring undertaking: data migration, change management, integrations, new application governance.<\/p>\n\n\n\n Connecting<\/strong> is the way to go when the tools are relevant within their scope but don’t communicate. Data flows poorly, re-entry piles up, information diverges between departments. Application integration<\/a> work makes it possible to automatically synchronize the flows without touching the tools in place.<\/p>\n\n\n\n Extending<\/strong> is often the most underestimated path. The tool works well on its main scope, but needs a complementary module, an interface tailored to a specific profile, or a dedicated application to cover a differentiating process. Custom development then complements what exists rather than replacing it.<\/p>\n\n\n\n Extending a tool isn’t about creating “one more tool” for the sake of adding to the list. It’s about designing an interface, a module, or a business application that plugs into the existing setup to cover a grey area: a specific calculation, a validation workflow, a customer portal, document generation, an operational dashboard. The goal isn’t to compete with the ERP or CRM, but to let them play their role better within a broader process.<\/p>\n\n\n Access it helps you choose between securing, connecting, or building custom, based on the real role of each tool in your processes.<\/p>\n \n A B2B services SME produces its quotes in an Excel file. At first, it’s efficient: the file embeds the pricing rules, the commercial exceptions, the internal validation levels. An experienced salesperson manages just fine.<\/p>\n\n\n\n Then the sales team grows. Several people use different versions of the file. Prices change, but not everyone has the latest version. Errors increase. Management no longer always knows which quote is up to date. A sales opportunity is lost over a price discrepancy that should never have existed.<\/p>\n\n\n\n The file didn’t suddenly “age badly.” It simply moved from individual or limited use to a far more critical role. It now commits commercial consistency, margin, the customer relationship, and sometimes even the company’s image. At this stage, the risk is no longer just a formula error: it’s a commercial decision made on data that isn’t under control.<\/p>\n\n\n\n Three scenarios are possible depending on the level of risk identified. Securing the file: centralize, lock the formulas, manage access rights, keep a version history. Building a web interface that draws on the existing Excel logic while adding the controls that are missing. Or progressively turning the file into a business application<\/a> connected to the CRM, with a controlled calculation engine, validation workflows, and full traceability.<\/p>\n\n\n\n The right answer isn’t the same for every company. It depends on the volume, the number of users, the level of commercial risk, and the degree of integration desired with the rest of the IS.<\/p>\n\n\n\n A simple decision grid helps you find your bearings quickly.<\/p>\n\n\n\n If the tool is used by few people on a low-criticality scope, a marginal improvement is often enough: structure the file, clarify the rights, document the rules.<\/p>\n\n\n\n If the tool commits financial, commercial, or regulatory decisions, you need more traceability and control: who changed what, when, and according to which rule. That’s typically where turning it into an application becomes justified.<\/p>\n\n\n\n If the tool spans several departments or has to exchange data with other systems, integration becomes key. And if the process the tool supports is genuinely differentiating for the business, custom development<\/a> brings the control that a generic tool cannot offer.<\/p>\n\n\n\n One last criterion must also be factored in: the ability to maintain the solution over time. A tool may meet the need today but become fragile tomorrow if it isn’t documented, monitored, or understood by several people. Modernization therefore isn’t limited to the interface visible to users. It also concerns the company’s ability to evolve its process without depending on a file, an export, or a key person.<\/p>\n\n\n\n Modernizing a process doesn’t mean disowning what exists. Excel isn’t the problem. The ERP isn’t the problem. The problem is when a tool carries more responsibility than it can bear, without the necessary safeguards.<\/p>\n\n\n\n The right approach is to keep what works, secure what’s becoming risky, connect what needs to circulate, and build custom what carries real business value. In that order.<\/p>\n\n\n\n The right tool isn’t always the one that replaces what exists. It’s often the one that reveals, secures, and extends what teams already do well.<\/p>\n\n\n\n\t\t\t\t\t\tWhen the ERP or CRM reaches its limits<\/h2>\n\n\n\n
Three options: replace, connect, or extend<\/h2>\n\n\n\n
Excel, ERP, CRM: unsure about the right strategy?<\/h4>\n \n
A concrete example: a quoting file that became a critical tool<\/h2>\n\n\n\n
The right choice depends on the level of risk<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n