An ERP project is a change to how the business works as much as a change to its software. The first conversations should focus on operational needs rather than a long list of screens.
Start with the transaction journey
Follow a representative transaction from beginning to end. For an order, that might include availability, approval, fulfilment, invoicing, payment, and reconciliation. Identify where information is re-entered, delayed, or disputed.
This gives the team a concrete way to discuss what should be connected and what should remain separate.
Define the source of truth
Decide which system owns each record and who can change it. Product codes, customer records, units of measure, tax fields, and account mappings need consistent definitions before they can move reliably between systems.
Assess what you already have
Existing software may still serve an important purpose. Review its interfaces, export options, constraints, and operating cost before deciding to replace it. A targeted integration may address the immediate problem; other situations may justify a wider redesign.
Make reporting requirements concrete
Ask which decisions a report supports, who uses it, and how current the data must be. A report that looks complete can still be unhelpful if definitions differ across departments.
Plan a controlled transition
Agree how data will be cleaned, migrated, and checked. Define acceptance criteria with the people who will use the system. Include permissions, training, reconciliation, and a fallback plan.
A phased rollout can make dependencies easier to manage, but the sequence should reflect the business. The aim is a coherent operating system with clear ownership, rather than a collection of loosely connected modules.
← All insights
