Popular ERP solutions such as SAP, Oracle, or Dynamics enable the "information backbone" of many corporate businesses. The business case is to reduce cost by standardising processes and rationalising the number of systems from, say, 30 to 1 supporting the business. Whilst the initial implementation possibly succeeds in this, the customisation increases year on year subsequently with:

• Small feature requests such as a new tax report or streamlining the order entry process

• Integration with third-party vendors

• Upgrades and patches

• Onboarding new regions, products or acquisitions to use the platform .

In the discussions I've been having with IT Business Partners over the past month, this is a real headache and can become the main topic of conversation in their role. I related my own experience with SAP where in one company I worked for, we had so many customisations to the vanilla order to cash process we called it "ZAP" since every new custom transaction started with "Z", so the sales order entry transaction VA01 was replaced with ZA01. This customisation was repeated for DOZENS of transactions throughout SAP.

Can one platform fit all processes? In theory, yes, but at what cost? A "one platform" approach:

• Cannot meet all business requirements "out of the box", so customisations will happen, despite the best will in the world.

• Exposes us to vendor lock-in, a closed ecosystem with vendor-specific cloud hosting code base, service packages, additional modules, and some very sharp licensing practices designed to increase vendor revenue.

• Is a risk for the company. We've seen how Crowdstrike and Microsoft can have a systemic risk across a market and can take whole companies offline.

• Closes down alternatives and innovation opportunities to those only available within the vendor's ecosystem, which becomes a bottleneck as demand outstrips capacity/budget for changes.

• Leaves you hostage to the vendor's own pace of innovation. Suppose they are not releasing new features that could satisfy some of the opportunities on the backlog. In that case, it's not the most compelling business case to upgrade only to "remain in support".

So what to do when planning a future roadmap? Should trying to remain "in support" take up the lion's share over the next 3 to 5 years? I have a few thoughts to consider in planning long term the 'information backbone" of your organisation:

1. Initial vendor selection. Shortlisting those vendors in the Gartner magic quadrant, Forrester Wave, or IDC Marketscape pre-supposes their analysts have considered all available options. Just like the financial advice given for investment products, the small print "do your own research" creates conviction about your purchasing options. You're not solely relying on someone else's opinion.

2. ERP solutions are now Software As A Service (SAAS). As part of the procurement process, you can test processes, configurations and data in test environments with relative ease. The question is not whether it fulfils the requirement but how adaptable it is for new requirements in the future.

3. Opensource code libraries. Why recruit specialist developers in PL/SQL, ABAP or APEX, when the most popular programming language is Python? Reduce risk and cost by selecting ERP solutions with an industry-standard application footprint.

4. One of the decision criteria you will need as part of the procurement process is the ability to keep the customisation path outside your system of record or ERP solution. Its ability to support an Application Protocol Interface (API) and Service Oriented Architecture (SOA) enables this. When there are new requirements, new vendors or customers, acquisitions or divestments, the ability to participate in, say, the order to cash process or purchase to payment process will fundamentally depend on how extensible and interoperable your existing "system of record" is to other systems to support the business workflow. Having libraries or modules of code that can be easily assembled into a service that transforms and outputs data and calling reference-able standard APIs to transfer that data gives you options on where to customise.

5. We don't want to customise ERP but will inevitably do so. Suppose requirements cannot be configured in ERP. Can investment in the capabilities (user training, software development, maintenance and licensing) mentioned below keep customised workflows or applications outside the expensive original ERP solution? This approach will help keep ERP's "vanilla" Target Operating Model and maintain an easier upgrade path.

1. Microsoft Power Apps and Power Automate

2. Other code platforms

3. Platform as a service (PAAS)

If we insist on procuring expensive ERP solutions, we only make the solution more costly by customising it. I believe the answer is not to deflect or put on the back burner requests that require customisation of the solution but to validate the relative merit in the requirement and have a "pressure release valve" onto a complimentary low code or industry standard platform where customisations can reside. This pressure release valve means that should the ERP solution be easy to integrate through a SOA and API library, then:

• Those customisations don't have to be rewritten or retested every time a new release of your ERP solution comes out.

• Other end-of-life apps, web portals or ERP solutions from other business acquisitions with unique business-critical features can be subsumed and onboarded into a blended mix of ERP and PAAS.

• You reduce risk by having multiple solutions and an alternative coding framework.

• You increase redundancy and scale by being able to export and archive data that can be processed separately for applications such as reporting, business intelligence, dashboards and AI applications.

• You could maintain more than one ERP solution with different cost structures, licensing models, and resourcing requirements to offer choices to business units with other requirements, operating models, and capacity to fund technology. An alternative I advocate is Odoo.com, which has a radically different, open-source approach to enabling business processes.

• By maintaining two ERP platform models, you can increase competition between ERP vendors as you have removed lock-in.

• Your long-term roadmap is no longer driven by one monolithic ERP vendor release schedule, and you can include alternative strategies that are easier to adapt as the business environment changes.