Custom ERP software development in Kenya should begin with agreement about how the business operates. Buying a list of modules before resolving ownership of customers, products, purchases and approvals can simply move existing confusion into a new application.
An ERP project connects processes that different departments may currently manage separately. Sales promises delivery, stores checks availability, procurement replenishes materials and finance tracks the transaction. A useful scope workshop follows those handovers and establishes which records each team can trust.
Invite the people who own the work
Include a decision-maker, representatives from the departments in scope, and someone responsible for finance and reporting. Invite employees who perform routine work as well as managers. They often know about exceptions that never appear in a process diagram.
Give the workshop a narrow starting point. Purchase-to-payment or order-to-delivery is easier to resolve than “automate the company”. Agree who can approve process decisions and record unresolved questions with a named owner. Without decision ownership, development can stall while departments give conflicting instructions.
Follow one transaction from beginning to end
Consider an illustrative distributor that receives an order larger than available stock. Sales needs to know what can be supplied immediately. Procurement needs a replenishment request. Finance needs visibility of the customer’s account. The delivery team needs a record of what actually left the warehouse.
Map the ordinary path and then test partial delivery, a cancellation, a rejected purchase and returned goods. These exceptions determine how records relate to each other. They should be discussed before developers build screens around an incomplete process.
Decide which records are authoritative
An ERP needs agreed product identifiers, customer records, supplier details, locations and units of measure. If one department sells cartons while another counts individual pieces, the conversion must be explicit. Otherwise stock reports may appear precise while describing incompatible quantities.
Decide who can create or amend master records. Establish a review process for duplicates and opening data. Where another application remains in use, define which system owns each field and which system only receives a copy. Two applications should not silently compete to control the same balance.
Define approvals and permissions separately
Permission to view a purchase does not necessarily mean permission to approve it. Document who can request, review, approve, receive and adjust a transaction. Consider temporary delegation when an approver is absent, and identify actions that require a reason.
For sensitive changes, specify the history the system should retain. Examples include changes to supplier payment details, price overrides and stock adjustments. These are design requirements to discuss and validate, not features to assume every ERP already provides.
Design reports from decisions
Start each report with a management question. Which orders are delayed? Which purchases await approval? Where is inventory unavailable? Define the calculation, date basis and owner of every important measure.
Ask finance and operations to reconcile the same sample period. If their totals differ, investigate the underlying definition before adding more charts. A visually attractive dashboard cannot resolve disagreements about whether a figure means ordered, delivered, invoiced or paid.
Choose a manageable first release
The first release should complete a useful process across departments. It may cover procurement and stock receipt before introducing production planning or customer portals. Select the boundary based on business dependencies and risk rather than the number of modules promised.
Agree a migration rehearsal, user training, acceptance checks and a cutover decision. Document how staff will handle unfinished transactions during transition. A phased rollout still requires a complete operating plan for the departments that move first.
What should the workshop produce?
Leave with a process map, agreed terminology, a list of roles, sample reports, migration responsibilities and a prioritised backlog. Record assumptions separately from confirmed requirements. These outputs make estimates more meaningful and make changes easier to assess.
Custom ERP software development is most valuable when the system fits a clearly understood operation. Review Zama’s enterprise software services and request an ERP scoping discussion with examples of the processes your teams need to connect.