A dashboard is a useful window into a business. It is not a map of how that business works. When an ERP project begins with charts and modules, the important questions can stay hidden: who can approve a purchase, when stock becomes available, and what happens when an order changes after an invoice has been issued?
Follow one real journey
Start with an ordinary transaction and follow it from beginning to end. For a distributor, that might mean a sales order moving through a stock check, purchasing, delivery, invoicing, and payment. Ask the people doing that work to show the spreadsheets, emails, and workarounds they depend on. The goal is to understand the current process before deciding what should change.
At each handoff, record the information required, the person responsible, and the decision being made. Separate business rules from habits that grew around an old tool. An approval exists for a reason; copying a number between two spreadsheets might not.
Design for the exceptions
The happy path is only part of the product. A returned delivery, a duplicate customer record, or a manager on leave can reveal more about the system than a clean demonstration. Describe those situations in plain language and agree on who is allowed to resolve them.
- Which fields have an authoritative source?
- Who can create, approve, edit, and reverse each record?
- What needs an audit trail?
- How should the team continue when an integration is unavailable?
Choose a coherent first release
A useful first release supports a complete piece of work. It might connect inventory and purchasing for one team, with finance continuing in an existing system. Define the boundary explicitly: what is included, what remains elsewhere, and how information crosses between them. A small but complete workflow is easier to assess than a collection of disconnected screens.
Migration belongs in that plan. Agree which historical records matter, clean a representative sample, and rehearse importing and reconciling them. Give staff a way to practice ordinary tasks before the live transition. The interface, the data, and the operating process need to arrive together.
Build the system around how work should move, then make that movement visible.
The result of discovery should be a shared understanding that a designer, a developer, and an operations lead can all question. That is the foundation for choosing modules, estimating the work, and building screens that serve a clear purpose.
What should an ERP discovery session produce?
A shared workflow map, a list of data owners, a clear first release, and a record of the exceptions that need human judgment. Screens can follow once those foundations are understood.
Codevsol Editorial
Perspectives on designing and building thoughtful digital products, business systems, and emerging technology.
