ERP Rescue Consultant, Kenya

What a failing rollout looks like in a Kenyan business

A struggling ERP project in Kenya usually shows itself through operations before it shows up in a status report. The finance team notices first, followed quickly by branches and customers.

• Some invoices still come from the old accounting package or a POS, so the tax position is split across systems and nobody is sure every document reached eTIMS.
• M-Pesa and bank receipts accumulate in an unallocated account, customer statements are wrong and collections calls go to people who have already paid.
• Depots lose connection, staff revert to paper and stock figures drift further from reality each week.
• The implementer has a long ticket list, the original lead consultant or developer has moved on and responses have slowed.
• Dollar-priced license and service invoices keep arriving while the system delivers less than promised.

Underneath these symptoms there are usually a few root causes: requirements that never captured Kenyan essentials such as eTIMS, mobile money and offline working; testing done in head office conditions rather than at depots; data imported from QuickBooks, Sage or spreadsheets without reconciliation; and a contract that left key responsibilities vague.

None of this calls for blame. It calls for a structured recovery, beginning with control and facts. The general approach is described on my ERP recovery page; below is the Kenyan version of it.

Securing the system before anything changes

In smaller Kenyan implementations, important parts of the system can end up outside the company's control. The hosting account may be in the implementer's name, the custom apps may live in a developer's personal code repository, and the only administrator login may belong to someone who has left. Before any recovery work, that has to be put right.

The first checklist I run with your team covers:

• Who holds administrator access to the ERP, and whether the company has its own working admin account.
• Where the system is hosted, in whose name the account is registered and who pays for it.
• Whether backups exist, where they are stored and whether a restore has ever been tested.
• Where custom code, scripts and integration settings are kept, and whether the company has a copy.
• Who holds credentials for connected services such as the eTIMS connector, M-Pesa APIs and bank links.

This is not an accusation against the implementer. Most of these arrangements were made for convenience during the build. But a company cannot negotiate a reset or a handover from a position where someone else holds the keys. Once control is secure, I move to the fact base: separate conversations with each party, a review of the contract and change history and hands-on tests of the main processes. The implementation consultant page for Kenya explains how custom code ownership should be agreed at the start of a project.

Keeping invoicing compliant and cash moving

Two things cannot wait while the longer recovery is planned: tax invoicing and cash collection.

One invoicing route. If invoices and credit notes are being issued from more than one system, the first step is agreeing with directors and your tax advisor which system issues what, from which date, and how documents raised elsewhere during the transition are accounted for. I then work with the implementer to make sure failed eTIMS transmissions are visible, retried and tracked to closure. Your tax advisor confirms obligations and any corrections; I make sure the records they need are complete and organized.

Receipts. The unallocated balance is worked down with finance in a planned sweep: oldest and largest items first, with customer statements corrected as items are cleared. At the same time the causes are fixed, whether that is a Paybill number mapped to the wrong entity, a reference format customers cannot follow or a missing rule for part payments.

Month-end and returns. With your accountant I agree an interim close routine: reconciliations for bank, M-Pesa and debtor balances, a review of withholding certificates received, and a check of VAT figures before returns are filed. The routine has named owners and stays in place until the system produces reliable figures on its own.

Once these basics hold, the first clean close becomes the proof point. The go-live support page covers that stage in more detail.

Making depots and branches resilient to outages

Connectivity is a design question in Kenya, not an afterthought. When a recovered ERP still assumes every depot is online all day, the same failures return the next time a link drops. So rescue work includes a resilience review of every site that matters.

For each depot or branch I look at what must keep working during an outage, such as issuing goods, taking payment and recording returns, and how that is done today. Then, with the implementer and your operations team, we define a practical routine:

1. Which transactions can be captured offline, in the ERP's own offline mode, a POS that syncs later or a controlled paper form.
2. How and when offline transactions are synchronized, and who checks for duplicates, gaps and wrong dates afterward.
3. Whether a backup mobile data connection is justified for critical sites.
4. How stock is reconciled after a long outage before normal operation resumes.
5. How eTIMS documents are handled for sales made while offline, confirmed with your tax advisor.

The routine is tested at a real depot, not only at head office. Hosting choices get a look too: whether the system runs in a reliable data center, how quickly it can be restored and whether performance from remote sites is acceptable. Personal data and hosting arrangements are noted for whoever handles data protection obligations. The selection page for Kenya describes how these questions should be asked before a system is chosen.

Resetting with the implementer and choosing a direction

With control secured and operations steadier, the conversation with the implementer can move forward. Most recoveries continue with the existing firm on a reset baseline. I chair a neutral session where every outstanding ticket gets one label: essential before the business can run smoothly, deferred to a later phase, dropped, or contested. Contested tickets are judged against the proposal and statement of work. The outcome is a written baseline with owners, acceptance tests and review dates.

If the implementer cannot continue, perhaps because the key person has left or the firm lacks capacity, the handover is planned: documentation of configuration and customizations, transfer of any remaining accounts, the open issue list and a briefing for the incoming team, whether local or regional.

The contract deserves careful reading. Payment milestones, dollar-denominated fees, warranty periods and support terms are compared with what was delivered. I record the facts and the gaps; any question of breach, withheld payment or termination is for your lawyer.

Directors then choose between continuing on the full plan, a narrower first phase, a different implementer or, where the platform cannot meet core Kenyan requirements without heavy custom work, a reselection. Each option is set out with its conditions and risks. When the system has settled, a later ERP audit confirms the fixes held. More on my remote work in this market is on the Kenya overview.