Caribbean organisations are spending millions on enterprise systems and getting a fraction of the value.

Caribbean organisations are spending millions on enterprise systems and getting a fraction of the value. After two decades working in information security and technology strategy across this region, I want to talk about why — and what actually changes it.

 By Ajmal Nazir

Somewhere in the Caribbean right now, a project manager is updating a red-amber-green dashboard that has been amber for eight months. The ERP implementation that was supposed to take 12 months is in its 22nd. The budget approved by the board has been exceeded by a figure that nobody wants to say out loud in a meeting. The system is technically live in three of the seven modules that were promised. Staff in finance are running parallel processes — the new system and the old spreadsheets — because nobody trusts the new data yet. And the vendor’s implementation consultant, who was on-site three days a week six months ago, is now responding to emails within five business days.

I have seen this story more times than I can count. The organisations are different. The vendors are sometimes SAP, sometimes Oracle, sometimes Microsoft Dynamics, sometimes a regional or tier-two solution. The industry varies — energy, banking, insurance, manufacturing, retail. The outcome is consistent: a gap between what was sold, what was planned, and what was delivered that consumes management attention, erodes staff confidence, and produces a system that the organisation neither fully owns nor fully uses.

50% 

of ERP implementations fail on their first attempt  — Panorama Consulting / RubinBrown ERP Advisory

3–4x 

most ERP projects exceed initial budgets by three to four times the original estimate

55–75% 

of ERP projects fail to meet their objectives, according to Gartner

51% 

of companies experience operational disruptions when going live with a new ERP system

 In the Caribbean context, where organisational capacity is thinner, specialist implementation expertise is scarcer, and the margin for expensive failure is narrower, these numbers are not statistics to observe from a safe distance. They are a description of what is likely to happen to your organisation if you approach an ERP implementation the way most Caribbean organisations approach them.

The Mistakes Come Before the System Goes In

The most consistent error I see in Caribbean ERP implementations is this: the organisation treats the technology decision as the primary decision. It evaluates vendors, compares feature sets, negotiates licence costs, and selects a system. It then treats everything else — process design, data readiness, change management, governance, resourcing — as implementation details that will be worked out after the contract is signed.

“The most expensive mistake isn’t technical. It’s treating ERP like a software purchase instead of a business transformation.”

The technology is the least complex part of an ERP programme. What is complex is the organisational work — defining what processes will actually run through the system, cleaning and migrating the data those processes depend on, redesigning workflows to take advantage of what the system can do, and bringing the people who will use the system along with genuine change management rather than a two-day training session the week before go-live.

Among organisations that experienced budget overruns, 38% said the reason was because the original staffing for the project was underestimated, nearly 35% said the initial project scope was expanded, and about 34% cited technical issues. Read that again carefully. Staffing underestimation and scope expansion — both of which are planning failures, not technology failures — account for more budget overruns than technical problems. The technology industry has a commercial incentive to sell you a more sophisticated system than you need and a simultaneous incentive to minimise what it will cost you to run it. Caribbean organisations need to approach vendor-led ERP conversations with that asymmetry explicitly in mind.

The Requirements Problem: Buying Before You Know What You Need

In 20 years of advising organisations in this region, the requirement I encounter most consistently is some variation of: ‘We need an ERP.’ When I ask what specific business problems the ERP is intended to solve, I typically get a list that combines legitimate operational challenges with aspirational capabilities the organisation does not currently have the data or process maturity to use, and a set of requirements that were defined by the vendor’s pre-sales team during the discovery process rather than by the organisation’s own analysis of its needs.

This is the starting-point failure that cascades into every subsequent problem. A system selected against poorly defined requirements will be scoped incorrectly, configured incorrectly, and tested against the wrong success criteria. The organisation will go live with a system that technically passes the acceptance tests — because the acceptance tests were written against the requirements, and the requirements were wrong — and then discover that the system does not support how the business actually operates.

The Lidl-SAP case is instructive. Lidl was keen on not changing the way it managed its inventory, so the SAP implementation had to be heavily customised. After spending nearly €500 million on the ERP implementation, the project was eventually scrapped after seven years. The problem was not SAP. The problem was the collision between a system designed around industry-standard processes and an organisation that was unwilling to adapt its processes to those standards — combined with a decision to customise around that unwillingness rather than resolve it.

Customisation is expensive to build, expensive to maintain, and creates a system that cannot be upgraded without re-implementing the customisations. It is the path that feels pragmatic and turns out to be the most costly. Caribbean organisations face this dynamic at smaller scale but with the same structural logic. The temptation — and often the vendor’s commercial accommodation — is to customise the system to match existing processes rather than redesign processes to take advantage of what the system makes possible. This is the wrong trade-off in almost every case.

Best of Breed vs. The One-Size-Fits-All Suite: The Decision Nobody Gets Right

The architectural decision that precedes every ERP implementation — and that is rarely made with adequate analytical rigour — is whether to deploy a single integrated suite or to assemble best-of-breed solutions for different functional areas.

The integrated suite argument is well understood: one system, one database, one vendor relationship, one training requirement, tighter data integration across functions, lower total cost if the suite genuinely meets your needs across all areas. SAP, Oracle, and Microsoft Dynamics make this case compellingly. The integration is real. The data coherence is real. The reduced complexity of managing one vendor relationship rather than six is real.

The problem, as Gartner notes, is that although ERP vendors offer numerous enterprise applications and claim that their integrated system is a superior solution, all modules in an ERP system are rarely best-of-breed. The HR module of a finance-oriented ERP system will not match the capability of a dedicated human capital management platform. The supply chain module of a generalist ERP will not match a purpose-built supply chain solution for an organisation whose competitive advantage lies in logistics complexity. You get 80% of your functional requirements met reasonably well, and 20% met inadequately — and that 20% is typically the part of the business where you most need capability.

“If your business has genuine operational differentiation, no single suite will address all of your requirements with equal competence. Know which 20% matters most before you sign anything.”

For Caribbean organisations in sectors with genuine operational differentiation — energy companies with complex field operations, financial institutions with regulatory reporting requirements across multiple jurisdictions, utilities managing infrastructure across island geographies — the honest answer is that no single suite will address all of their requirements with equal competence.

The best-of-breed approach delivers deeper functional capability in each domain. A specialist HR platform, a specialist financial management system, a specialist supply chain tool — each will outperform the equivalent module in a generalist suite within its specific domain. The cost of that depth is integration complexity: more vendors, more APIs, more potential points of failure in the data flows between systems, and more internal capability required to manage a more complex technology estate.

The hybrid model — a core integrated ERP handling financials, procurement, and basic operations, with best-of-breed bolt-ons for specific complex functions — is increasingly the pragmatic answer for mid-to-large Caribbean organisations. A core single ERP system handles the common functions of the business, while best-of-breed solutions address the more complex or unique aspects. This is how SAP, Oracle, and Microsoft have themselves responded to the best-of-breed challenge — by acquiring specialist vendors and integrating them into their ecosystems.

What this means for a Caribbean CIO making a procurement decision is: do not let the vendor define the boundary of your requirements. Map your functional requirements across all business domains before you engage any vendor. Identify where your business has genuine differentiation that requires deep specialist capability. Be honest about where industry-standard processes are sufficient. Then design an architecture that matches the right level of sophistication to each domain — and evaluate vendors against that architecture, not against their own product roadmaps.

The Change Management Gap: The Most Underfunded Element of Every Implementation

If I were to identify the single most consistent reason that Caribbean ERP implementations underdeliver, it would not be poor requirements definition, though that matters. It would not be the wrong vendor selection, though that matters too. It would be the systematic underfunding and undervaluation of change management.

Change management is the disciplined work of helping people move from old ways of working to new ones. It encompasses communication — explaining why the change is happening and what it means for each role. It encompasses training — not a two-day pre-go-live session but sustained, role-specific capability building that begins months before the system goes live. It encompasses resistance management — identifying the people and teams who are most resistant to change and addressing that resistance with genuine engagement rather than management pressure. And it encompasses leadership reinforcement — the visible, sustained commitment from senior leaders that the new system is the way the organisation operates, not an optional tool that can be worked around.

A significant portion of failed ERP projects can be attributed to insufficient user training and buy-in. Employees resist changes when they don’t understand the benefits or feel unprepared to use the new system. In most Caribbean ERP projects I have reviewed, the change management budget is between 5% and 10% of the total project cost. In successful large-scale ERP implementations globally, change management typically represents 15–25% of programme spend. The gap between those two figures is the gap between a system that the organisation adopts and a system that the organisation works around.

What a Well-Run ERP Programme Actually Looks Like

A well-run ERP programme in the Caribbean context has several consistent characteristics that distinguish it from the pattern of underdelivery I described at the opening of this piece.

Start with business requirements, not vendor evaluations: Before any vendor is engaged, the organisation maps its current processes, identifies its pain points, and defines in business terms — not technology terms — what success looks like. This work typically takes three to six months and produces a requirements document that is owned by the business, not the IT department.

Assign a business owner, not an IT owner: The ERP programme is a business transformation programme that uses technology as its instrument. Accountability for outcomes must sit with a senior business leader — a CFO, a COO, a Managing Director — who has the authority and the mandate to make the process design decisions that the implementation will require.

Phase the delivery: Over 50% of companies prefer a phased implementation strategy over the ‘big bang’ approach. In the Caribbean context, where internal capacity to absorb change is genuinely limited, the phased approach is not just preferred — it is essential. Starting with the modules that address the most acute pain points, demonstrating value, and building organisational confidence before expanding scope is the approach that survives operational pressure.

Invest in data before you invest in the system: The most common cause of go-live instability is data quality. Migrating poor-quality data from legacy systems into a new ERP does not improve the data. It propagates the errors at the speed and scale of the new system. Data cleansing, data governance, and data migration testing must begin early, run throughout the implementation, and be treated with the same rigour as system configuration.

Define what success looks like before you sign a contract: Not features delivered. Not modules live. Business outcomes: the reduction in month-end close time, the improvement in inventory accuracy, the reduction in procurement cycle time, the improvement in financial reporting quality. These are the measures by which the implementation should be evaluated — and they are the measures that, if absent from the original programme design, will never be achieved.

 The ERP decision is one of the most consequential technology commitments a Caribbean organisation will make. It will consume significant capital, management attention, and organisational energy. Done well, it produces a platform that enables better decisions, more efficient operations, and genuine competitive capability. Done poorly, it produces a system that the organisation neither trusts nor uses fully, at a cost that cannot be recovered.

The difference between those two outcomes is not the vendor you choose. It is the rigour, the honesty, and the governance discipline you bring to every decision before the system goes live.

Buy the right system for your actual business. Not the one the vendor tells you that you need.