ERP Customization in Rwanda

What is ERP customisation, and who needs it

It’s the design, build, testing and documentation of changes to an ERP platform beyond its standard settings: new fields and screens, workflows, reports, document templates, calculations and add-on modules. It suits organisations whose ERP covers most needs but leaves a few important processes in spreadsheets, and those whose earlier customisations now block upgrades.

The problem it solves

When an ERP doesn’t fit a process, staff work around it: exporting to Excel, keeping side records, approving by email. The system stops being the single source of truth. Customisation closes those gaps, but done carelessly it creates a different problem: a system so modified that every upgrade breaks it. Careful customisation fixes the gap while keeping the platform maintainable.

Choosing the least invasive approach

1. Change the process. Sometimes the platform’s standard way is better than the old habit. We check this first.

2. Configure. Use the platform’s own settings for fields, rules, roles, templates and reports.

3. Extend. Use supported extension points, scripting or separate add-on modules that sit beside the core.

4. Report externally. Build complex reports in a reporting tool reading standard data, rather than changing the ERP.

5. Modify core code only as a last resort, documented and flagged for every future upgrade.

Typical customisations

• Approval workflows by amount, department, project or donor.
• Document templates: invoices, purchase orders and payslips in your format and languages.
• Local requirements, such as integration with the Rwanda Revenue Authority’s EBM electronic invoicing for VAT-registered businesses.
• Reports for management, boards and donors.
• Fields and screens for industry-specific information.
• Calculations, such as pricing rules or allowances.

Reports before code

Many customisation requests are really reporting requests: a management pack in a particular format, a donor report by budget line, or a stock summary by location. These rarely need changes to the ERP itself. A reporting tool reading the ERP’s standard data can produce them without touching the platform, which keeps upgrades simple and lets reports change as often as managers’ questions do.

Keeping a customisation register

Every customisation is recorded with its purpose, the people who asked for it, how it was built, how to test it and its upgrade risk. The register makes support and upgrades predictable, and it shows at a glance when customisation is growing to the point where the platform choice should be reconsidered.

What the work involves

1. Document the gap: what the process needs and why the standard system doesn’t do it.
2. Choose the approach, preferring configuration and extensions.
3. Specify and agree the change with its users.
4. Build on a test environment.
5. Test with real cases, including upgrade impact where relevant.
6. Deploy, train affected users and document the change.

Before any change goes live, the people who asked for it test it with real cases and confirm it does what they need.

What’s included and what’s not

Typical timelines and what drives cost

Simple configuration changes take days; substantial customisations take weeks. Cost is driven by complexity, how many modules a change touches, how much is configuration versus code, testing effort, and documentation.

Equipment typically used

The ERP platform’s configuration and extension tools, a separate test environment, version control for any code, a reporting tool for complex reports, and a register of every customisation with its purpose, owner and upgrade risk.

Common mistakes we see

Customising to copy old spreadsheet habits. Changing core code when configuration would do. No test environment. Customisations nobody documented. Approval chains so complex nothing gets approved. And upgrades skipped for years because nobody knows what will break.