ERP Implementation Checklist for SMEs (Free Template)
ERP projects fail in predictable places — dirty master data, big-bang go-lives, training on demo data, and nobody owning adoption. The full checklist for a Kenyan SME implementation, from decision to retired spreadsheets.
The software is rarely why ERP implementations fail. They fail because the item list had four names for the same product, because go-live was a Friday big bang across every module, because training happened on demo data three weeks before anyone touched the system, and because six months later half the team still kept their notebooks "just in case". Every one of those failures is preventable, and the prevention is a checklist — not genius.
Phase 1: Before you sign (weeks 1–2)
Decision readiness
- Name the bleeding point: the one process whose failure is funding this project (stock variance, donor reports, fee reconciliation). It goes live first.
- Name an internal owner — one person with authority and hours, not a committee. If nobody owns it, the vendor ends up owning it, and vendors go home.
- Agree the success metrics in writing: "van variance under 1% by month two", "donor report in under an hour". Vague projects cannot succeed because success was never defined.
- Complete commercial diligence: the ten provider questions and the three-year cost math.
- Set the go-live anchor date around your calendar — a stocktake, a term boundary, a month-end — and work backwards from it.
Phase 2: Master data — the real project (weeks 2–4)
Every implementation is secretly a data-cleaning project wearing a software badge. Budget more time here than anywhere else:
Data readiness
- One canonical item list: merge the four names for the same product, kill the dead SKUs, agree units of measure (the carton/piece confusion is the classic stock-variance seed).
- Customers and suppliers deduplicated, with the fields you will actually use (KRA PINs for eTIMS, payment terms, contacts).
- Chart of accounts agreed with your accountant — changing it after go-live is surgery; before, it is typing.
- Opening balances verified: stock counted (not copied from the old tracker), debtors/creditors confirmed, bank reconciled to a cut-over date.
- Historical data decision made explicitly: master data and balances migrate; transaction history stays archived in the old system for reference. Do not re-enter history.
The cut-over date is sacred
Pick the date, count and verify everything as of that date, and start the system from those numbers. The failure pattern is the soft launch — half the transactions in the new system, half in the old, reconciled by hope. One date, one truth, no stragglers.
Phase 3: Configuration & pilot (weeks 3–6)
Setup that matches your policy
- Approval chains configured to your written thresholds — the policy the board adopted, not the vendor's defaults.
- Roles mapped person by person: who raises, who approves, who sees reports. Least-privilege now beats untangling later.
- Statutory settings verified: eTIMS connection tested with real (voidable) transactions, payroll rules checked against a hand-computed payslip.
- One full pilot cycle on real data: a purchase from requisition to payment, a sale from order to receipt, a payroll run in parallel — with the people who will actually do the work, not just the project owner.
- Document the exceptions the pilot surfaces (the weird discount, the split delivery) and configure or consciously defer each one.
Phase 4: Training & go-live (weeks 5–8)
People readiness
- Train on your data, in role groups, hands-on — the cashier runs sales, the storekeeper runs issues. A projector demo is not training.
- Print the one-page cheat sheet per role: the five tasks that person does daily, with screenshots.
- Go live module-first, not everything-first: the bleeding-point module opens on the anchor date; the next module follows once the first is boring.
- Staff the first week deliberately: the vendor reachable, the internal owner floor-walking, and a visible fast channel for "it won't let me…" moments.
- Hold the line on parallel records: the old spreadsheet gets a retirement date per module, announced and honored — see the true cost of keeping both.
Phase 5: The first ninety days
Adoption is a metric, not a mood
- Week 2 and week 6 check-ins against the written success metrics — with the vendor at the table.
- Watch the tell-tales: transactions entered same-day vs batched at month-end; adjustments with reasons vs "correction"; reports pulled by managers vs prepared for them.
- Second training round at week 3–4 — the real questions only exist after two weeks of real use.
- Review the exceptions log and configure what the pilot deferred.
- Month three: retire the last parallel spreadsheet, run the first month-end entirely in-system, and take the team's temperature honestly — resistance at this point is a workflow problem to fix, not a personality problem to wait out.
A well-run SME implementation on this checklist lands in six to ten weeks from signature to a confident first module — with the schedule's length set almost entirely by Phase 2 data readiness. Ready to price the project honestly? Start with what ERP costs in Kenya, then see the platform the checklist was written for.
Implement against a checklist, not a hope
Bring your item list and your bleeding point — we'll walk this exact checklist against your operation and give you the honest timeline.
Plan your implementationFrequently asked questions
How long does an SME implementation really take?
Six to ten weeks to a confident first module for a typical Kenyan SME — two to four if your master data is genuinely clean, longer if the item list is archaeology. Multi-module rollouts then proceed a module at a time. Distrust both the "live in three days" pitch and the six-month enterprise methodology.
Should we go live with everything at once or module by module?
Module by module, bleeding point first, every time. Big-bang go-lives fail on training bandwidth: every person relearning every task in the same week guarantees the notebooks come back. One module reaching boring reliability builds the credibility the next module inherits.
Who from our side needs to be involved, and how much?
The internal owner at several hours a week throughout; each functional lead (store, accounts, sales) heavily during their module's pilot and training weeks; management at the metric check-ins. The project that only the vendor attends is the project that ends when the vendor leaves.
What if staff resist the new system?
Diagnose before blaming: nine times out of ten "resistance" is a workflow that genuinely takes longer than the old way, a training gap, or fear about visibility. Fix the workflow, retrain the gap, and be honest about the visibility — the system does make work attributable, and for good staff that is protection, not surveillance. Persistent sabotage after all that is a management issue that predates the software.
