Modular ERP: start with processes, not a list of screens

Before choosing modules, follow one complete operation: who receives a request, what they check, where they record it and who decides the next step. An order may cross sales, warehouse, purchasing and administration. If each department describes only its own screen, dependencies remain hidden. Include waiting periods, supporting documents and decisions currently resolved through a phone call.

Identify the authoritative system for each field. A customer’s legal name, delivery address and commercial limit may have different owners. Define stable identifiers, mandatory fields and rules for correcting duplicates. Importing spreadsheets unchanged is rarely a useful starting point: first decide what each column means and who is allowed to change it.

A useful first module lets people finish a task from beginning to end. In a hypothetical example, that means recording an order, reserving stock and showing an exception when material is missing. Validate this journey with actual users before opening ten unfinished modules. State what is included, what remains in the existing system and the conditions for extending the solution.

To retain an existing ERP, review its APIs, versions, licences and access limits. A familiar brand does not mean every connector works with every installation. Test a sample and compare totals, relationships and statuses. Migration needs an owner, a cutover point and a recovery plan if the results do not match the agreed criteria.

Request a module inventory, a permission matrix, acceptance examples and separate development, infrastructure, licensing and maintenance costs. Clarify how decisions will be documented and how the team will be trained. The objective is not to promise a saving before understanding the operation: establish a baseline, then measure whether repeated work and incidents actually decrease.