ERP Implementation Consultant, Kenya

Where Kenyan ERP implementations go wrong

Failures in Kenyan rollouts are rarely about the core platform. They come from the edges where the ERP meets tax systems, payment channels and branches.

• eTIMS tested on one invoice. A single successful transmission is treated as proof. Credit notes, discounts, foreign currency invoices and failures are only discovered in live use.
• Payment provider access arrives late. Production access to mobile money interfaces can take time to arrange, and projects that start the request late end up going live with manual statement imports.
• Customer and supplier records are incomplete. PINs, legal names and payment references are missing, so invoices fail validation or receipts cannot be matched.
• Depots are tested from head office. Everything works on the office connection; nobody tries an order with the link down and a generator starting up.
• Knowledge sits with one developer. Custom work is undocumented and lives on a laptop, so every fix depends on one person.

Each one goes into the project plan early, with a named owner and a test case. The requirement side is covered on the ERP business analyst page for Kenya, and platform notes on the ERPNext in Kenya and Business Central in Kenya pages.

Overseeing a local implementer from the client side

Kenyan implementers range from established firms to small teams built around a few strong developers. My oversight adjusts to that, but a few routines apply everywhere.

At the start I agree with the implementer where configuration and code will live, how environments are separated and how changes move from test to live. Custom work, including any eTIMS or M-Pesa connector, should sit in a repository your company controls, with enough documentation for another developer to pick it up. That protects you whatever happens to the relationship.

During design, each process area gets a short document your process owner signs after a walkthrough in plain language. While building, the implementer shows progress on your own test cases, and I write down every point where it misses the requirement. Extra requests are estimated and put to the sponsor, so scope cannot grow through hallway conversations.

I also watch capacity. If the same person is configuring, building connectors and supporting other clients, the plan needs to reflect that, and the sponsor should know. Raising it early is far kinder to both sides than discovering it a week before go-live.

For the overall method see ERP implementation; connector design is covered under ERP integration.

Migrating from QuickBooks, Sage, POS tools and spreadsheets

Kenyan companies usually arrive at an ERP from QuickBooks, Sage, a locally built accounting or point-of-sale system, or a set of spreadsheets that grew with the business. Each source needs its own extraction and cleansing plan, and each brings familiar data problems.

Before the first trial load, I work with finance and operations on the masters. Customer and supplier records need correct legal names, PINs where required, payment references and credit terms. Items need consistent units, prices and tax categories. Depots and branches need clear codes. This work is unglamorous, but it decides whether invoices pass eTIMS validation and whether receipts match on the first day.

Then the transactional data moves: opening balances, open customer and supplier invoices, unallocated M-Pesa and bank receipts, stock by depot with values, and open orders. Each trial load is compared with the old system in a fixed order: general ledger totals per account, debtor and creditor ageing that must tie back to the control accounts, depot stock by quantity and value, and a random set of records traced to the original documents. Mismatches are assigned to a named person and resolved before another load is attempted.

Completed history generally remains accessible in the retired system or an export file for the period your accountant advises. Physical stock counts at each depot are planned around the cut-off date. My ERP data migration page and the QuickBooks migration page cover the method.

eTIMS, M-Pesa and payroll at cutover

A Kenyan cutover has a few local switches that must happen cleanly. The runbook gives each one an owner and a check, and we rehearse whatever the test environment allows.

• One invoicing system at a time. Invoices must stop leaving the old system before they start leaving the new one. Number series, eTIMS registration for each branch or device and the exact cut-off time are agreed in advance.
• Credit notes for old invoices. Returns against invoices issued from the old system need a rule: where the credit note is raised and how it references the original transmission.
• Payment channels. M-Pesa notifications or statement imports are pointed at the new system, Paybill and Till numbers are mapped to the right entities and branches, and any receipts that arrive during the switch are tracked.
• Banks. Statement imports and payment files are tested with the bank's real formats.
• Payroll provider handoff. Payroll and statutory deductions stay with the provider. The journal into the ERP is mapped to accounts, departments and branches and tested with a real pay run.

eTIMS and payment provider requirements change, so confirm the current position with your tax advisor, KRA guidance and the provider before the date is fixed. My go-live support service covers the cutover method in general terms.

Testing for outages, Kiswahili material and hypercare

UAT in Kenya has to include the conditions staff actually work in. Alongside the core sales, purchasing and closing scenarios, I write scenarios for depot and route staff with the connection cut: capture an order, record a delivery, count stock, then restore the link and confirm everything synchronizes and every eTIMS transmission completes. Finance tests M-Pesa receipts with poor references, withholding VAT certificates and dollar invoices. Every issue is logged and reviewed with the implementer to decide whether it is a bug, a missed requirement, a training matter or a request for later.

The engagement runs in English. For depot, warehouse and route staff who are more comfortable in Kiswahili, quick guides and training come from your super-users or a local partner, who know the vocabulary used on the ground. Short screen recordings of each task, narrated by a supervisor, often work better than long manuals. I review the material for process accuracy.

In the weeks after go-live, a single issue tracker and a daily check-in during the hours Kenya and India share keep problems moving, until month-end and the VAT figures are closed and the eTIMS queue is empty. Your internal system owner then takes over, with written documentation and a prioritized list of later improvements. Test planning is explained under ERP testing and UAT. If no platform has been picked yet, ERP selection in Kenya is the earlier step, and the Kenya overview summarizes the rest. All of it is remote; visits are by arrangement only.