Why Kenyan Businesses Abandon Their ERP Projects

A practical look at where ERP implementations stall in Nairobi, Mombasa, Kisumu and beyond — and how to avoid becoming another cautionary tale

Walk into almost any mid-sized Kenyan business — a distributor in Industrial Area, a SACCO with branches across three counties, a clinic chain, a school with boarding and day operations — and you will find at least one ERP project sitting half-finished in a drawer somewhere. Sometimes it is literally abandoned: a server nobody logs into, a contract with a vendor who stopped returning calls, a WhatsApp group that went quiet. Other times it limps along, used for a fraction of what it was bought to do, while the real business still runs on Excel, paper ledgers, and someone's institutional memory.

This is not a Kenyan-specific problem — ERP projects fail everywhere. But the specific pressures on a Kenyan business make the failure modes distinct, and worth understanding on their own terms rather than importing generic advice written for a company with a much bigger IT budget and a much more predictable operating environment.

1. The Budget Was Sized for the Software, Not the Project

Most ERP conversations start with a license quote. A vendor, often pricing in US dollars, gives a number per user per month, and the business owner does the arithmetic against their headcount and decides it is affordable. What almost never makes it into that early arithmetic is everything else: data migration from the old system, customisation to match how the business actually invoices in KES, integration with M-Pesa for reconciliation, training for staff who have never used anything beyond a spreadsheet, and the ongoing cost of a consultant or internal admin to keep the system healthy after go-live.

By the time these costs surface — usually mid-project, when it is hardest to walk away cleanly — the business has already spent more than it budgeted and is now choosing between throwing good money after bad or cutting scope so aggressively that the system no longer does what was originally promised. Either path damages morale and trust in the project. If you are budgeting for ERP, treat the license fee as the smallest line item, not the total, and build in contingency for the parts nobody quotes you upfront.

The Forex Trap

A large share of ERP platforms available to Kenyan businesses are priced in dollars. That exposes you to exchange rate movement over the life of a multi-year contract, and it is a cost that is easy to forget about when you sign, and painful to explain to a board or a co-owner eighteen months later when the shilling has moved against you. Where possible, negotiate shilling-denominated invoicing, ask whether the vendor allows annual rather than monthly billing to reduce the number of conversion events, and build a forex buffer into your budgeting rather than assuming today's rate holds.

2. Nobody Mapped How the Business Actually Works

ERP software encodes assumptions about process. Off-the-shelf systems, especially those built for markets with different regulatory and payment norms, assume a particular way of handling stock, approvals, invoicing, and cash. Kenyan businesses frequently run processes that are perfectly sensible for their context but don't map cleanly onto those assumptions — a SACCO's loan approval chain that depends on a specific committee structure, a school that collects fees through multiple channels including M-Pesa paybill and cash at the gate, a clinic that needs to reconcile NHIF or insurance claims against daily patient records.

When the implementation team — whether an external consultancy or an in-house IT lead — doesn't spend real time mapping these processes before configuration begins, the result is a system that technically works but fights the business every day. Staff find workarounds, workarounds multiply, and within a few months the "system of record" is quietly being overridden by a parallel Excel file that everyone trusts more. That is usually the beginning of the end.

A Practical Starting Point

Before any vendor conversation, write down — on paper, in a shared document, however you can manage it — how money, stock, and information currently move through your business from the point a customer or member interacts with you to the point the transaction is closed and reported. Include the messy exceptions: the credit sale that gets settled three weeks late, the branch that has patchy internet and processes things in batches. A vendor who cannot engage seriously with that document is not ready to implement for you.

3. Connectivity and Power Were an Afterthought

Many ERP systems, particularly cloud-hosted ones, assume a level of continuous, reliable internet connectivity that does not match the day-to-day reality of a branch in a smaller town, a retail outlet during a fibre outage, or an office during a power interruption that outlasts the UPS. If staff cannot reliably reach the system to record a sale or check stock, they revert to paper, and once that habit forms it is very hard to reverse — because now there are two records of the truth, and reconciling them becomes its own job.

This doesn't mean cloud ERP is wrong for a Kenyan business — for many, it is the right choice, since it removes the burden of running your own servers and generators. It means the implementation plan needs an honest answer to "what happens when connectivity drops for an hour, a day, or during a serious outage" before go-live, not after the first branch loses a day's sales records. Ask vendors directly about offline modes, local caching, and how transactions sync once connectivity is restored.

4. Compliance Requirements Arrived Mid-Project

Kenyan regulatory requirements around tax and data are not static, and they carry real operational weight. Invoicing needs to align with KRA's eTIMS requirements, and any system handling customer or member data has obligations under the framework overseen by the Office of the Data Protection Commissioner. When ERP selection happens without a clear view of these obligations — or when the requirements shift while the project is already underway — businesses can find themselves needing significant rework to a system that was already tight on budget and timeline.

The specifics of current eTIMS integration requirements and data protection obligations change and are outside the scope of what this article should state with confidence — verify the current requirements directly with KRA and the Office of the Data Protection Commissioner before finalising your system design, and build in the assumption that compliance requirements may evolve again during the life of the system.

5. The Project Had No Real Owner

In a lot of Kenyan SMEs, ERP is handed to whoever is "good with computers" — often a junior staff member or an external IT contractor — without giving that person real authority to make decisions, push back on department heads who resist change, or say no to scope creep. Meanwhile, the actual decision-maker, usually the owner or MD, is too busy running the business to attend implementation meetings and only re-engages when something has already gone wrong.

ERP projects need an owner who has both the mandate and the time to make trade-off decisions weekly, not quarterly. If that person doesn't exist in your organisation, the project is at serious risk regardless of how good the software or the vendor is. This is a staffing and governance problem before it is a technology problem, and no amount of software sophistication fixes it.

Training Gets Cut First, and It Shows Last

When budgets tighten mid-project, training is almost always the first thing reduced — a two-week plan becomes a two-day plan, or a single session recorded and shared as a video nobody watches properly. The cost of this doesn't show up immediately; it shows up three months later, when staff have quietly built their own inefficient habits around the system, error rates are up, and the appetite to "go back and retrain properly" has evaporated because everyone is exhausted from the go-live already. Protect training budget as fiercely as you protect the license budget — a system nobody knows how to use properly is not cheaper than a slower rollout with proper training, it just defers and disguises the cost.

What This Means Practically

None of this is an argument against ERP for Kenyan businesses that have genuinely outgrown spreadsheets and manual processes — for a growing SACCO, a multi-branch retailer, or a clinic managing patient and billing data across locations, a well-run ERP implementation can be transformative. The argument is against treating ERP as a software purchase rather than an organisational change project that happens to involve software. Budget honestly, map your real processes before configuring anything, plan explicitly for connectivity and power realities, confirm compliance requirements with the relevant authorities rather than assuming, and put someone in charge who has the time and authority to see it through. Do that, and you dramatically improve your odds of being the business that finished its ERP project — not the one still running on the spreadsheet everyone secretly trusts more than the new system.