Before you invite an ERP demonstration, pick one customer order from last month.
Choose an ordinary order that involved sales, stock, delivery, invoicing, and payment. Ask your team to reconstruct its journey.
Who confirmed the price? Who checked stock availability? Was the delivery complete? Did the invoice match the agreed terms? Was payment received, and could accounts identify which invoice it settled?
Watch how your team finds the answers.
The exercise can reveal two things: where your business needs better coordination, and how prepared it is to implement ERP.
Follow the transaction across departmental boundaries
Sales may consider an order complete when the customer confirms it. The warehouse may consider it complete when goods leave the premises. Accounts may still be waiting for a signed delivery note before raising the invoice.
Each department has finished its own task, yet the transaction remains unfinished.
Write down every handover. Identify what information the next person needs, who provides it, and where it is recorded.
If your team can discuss these gaps openly and agree who should own them, you have a useful foundation for implementation.
Look closely at the exceptions
A straightforward order tells only part of the story. Now consider what happens when the customer changes the quantity, goods are delivered in parts, or a payment arrives without an invoice reference.
Ask employees how they handle these situations today.
You may discover that the official process is rarely followed because it does not cover everyday conditions. These exceptions belong in your implementation discussions and testing.
An ERP demonstration becomes much more useful when you can say, “Show us how this particular situation would work.”
Check who can make a decision
Suppose sales wants to release an order, but the customer has exceeded the agreed credit limit.
Who decides whether delivery can proceed? Who records the approval? Who follows up on the resulting payment commitment?
Software configuration needs answers to questions like these. If department heads disagree, someone with the appropriate authority must resolve the issue.
Your readiness becomes clearer when you can name the people who will approve business rules—and give them time to do so.
Ask someone to stand behind the opening figures
Consider the stock quantity you intend to bring into the new system.
Does it agree with a physical count? Are damaged goods identified? Are quantities recorded in consistent units? Have goods held at another location been included correctly?
Apply the same discipline to customer balances, supplier balances, and other opening records.
You may still have corrections to make. What matters is that each area has a responsible person and an agreed method of verification. Unexplained figures need investigation before they become the starting point for daily operations.
Make room for the work before go-live
Ask a practical question: who will test the system on a busy working day?
The people who know your operations are often the people already carrying the heaviest workload. They need scheduled time to explain requirements, review results, practise transactions, and help colleagues.
Include this internal effort in your plan alongside software, implementation services, data preparation, and support.
Turn the findings into a starting scope
After tracing the order, prepare a short action list:
| Finding | Preparation needed |
|---|---|
| Stock availability is checked by telephone | Agree how stock movements will be recorded |
| Credit exceptions depend on verbal permission | Define approval authority and records |
| Delivery documents reach accounts late | Assign responsibility for the handover |
| Opening balances contain unexplained differences | Allocate reconciliation and approval work |
| Key users cannot attend testing | Reserve time and arrange workload cover |
Use the findings to choose a manageable first phase with clear responsibilities and a way to assess the results.
A difficult order history does not mean you should postpone ERP indefinitely. It gives you something concrete to work on.
Bring that order to your first implementation meeting. The documents, delays, exceptions, and unanswered questions will make a better starting brief than a long list of software features.