Why an ERP needs questions before it needs software
An ERP is the system a business runs on: orders, stock, purchasing, production, projects, finance, people. A custom one is a serious undertaking, and the projects that disappoint tend to share a beginning. Someone wrote a list of modules, a company quoted for the list, and the discovery of how the business really works happened during development, at the highest possible cost.
The questions below move that learning to the front. They are meant to be answered by the people who do the work, in workshops and by observation, not by one manager at a desk. If a packaged ERP might fit instead, answer them anyway: our comparison of a custom ERP and an Odoo implementation shows how the same answers settle that choice.
Questions about goals and limits
- 01
What must be different when this is finished?
What the answer decidesThe measure of success. Fewer stock-outs, faster month-end and one version of customer data are goals. Having an ERP is not.
- 02
What is the business unable to do today?
What the answer decidesThe priority. The module that removes the worst constraint usually comes first.
- 03
What is working well and must not be damaged?
What the answer decidesThe boundaries. Some spreadsheets and habits are good, and replacing them adds risk without benefit.
- 04
Who sponsors the project and who decides disputes?
What the answer decidesWhether decisions will be made. ERP work crosses departments, and someone must be able to settle disagreements between them.
- 05
What budget range and horizon are realistic?
What the answer decidesHow much can be attempted in the first phase.
Questions about each process
For every area in scope, walk one real case from start to finish with the people who handle it. A recent order, a recent purchase, a recent production job. Then ask what happens when it goes wrong.
| Area | Follow this case | Then ask |
|---|---|---|
| Sales and orders | An order from enquiry to invoice | How are prices, discounts and credit limits decided? What happens to a part-delivered order? |
| Purchasing | A purchase from request to payment | Who approves, at what amounts? How are deliveries matched to orders and invoices? |
| Stock and warehouse | An item from receipt to dispatch | How many locations? Batches, serial numbers, expiry dates? How are counts and corrections done? |
| Production or projects | A job from plan to completion | How are materials, labour and time recorded? What happens when the plan changes mid-job? |
| Finance | A month-end close | Which entries are manual? What does the accountant correct every month? |
| People | A new employee, a leave request, a payroll run | Which rules are statutory, and which are company policy? |
The most valuable question in every workshop is: what do you keep in your own spreadsheet, and why? The answer shows where the current system fails and what the new one must do.
Questions about data and connected systems
- Master data. Where do the lists of customers, suppliers, items and prices live today? How many versions exist? Who may create or change an entry?
- Codes and units. Do item codes, units of measure and tax codes follow a consistent scheme, or will they need rationalizing first?
- History. How much past data must be available in the new system, and how much can stay in an archive?
- Systems that remain. Accounting software, payroll, an online store, a warehouse scanner system, bank connections, government reporting portals. For each, what must be exchanged and how often?
- Authority. For every kind of record shared between systems, which one is right when they disagree?
- Access. Does each remaining system offer a documented way to connect, on the plan you pay for?
Statutory requirements such as tax invoicing rules, payroll rules and data residency differ by country and change over time. List the ones that apply to you and have them confirmed by your accountant or legal adviser, since a software company should build to your confirmed requirements and not guess them.
Questions about people and change
An ERP changes daily work for most of the company. Projects that treat this as a training session at the end meet resistance that looks like software failure.
- 01
Who will use each part, and where?
At a desk, on a warehouse floor with a scanner, on a phone at a customer's site. The setting shapes the design.
- 02
Who are the informal experts?
Every department has someone others ask. Their involvement makes or breaks adoption.
- 03
What will people stop doing?
If nothing is removed, the new system is extra work. Name the spreadsheets and paper forms that will be retired.
- 04
How will the switch happen?
Area by area, site by site, with a period of running old and new together. A single switch for the whole company is the riskiest option.
- 05
Who looks after the system afterwards?
An internal owner for each module, and a support arrangement for the software.
A worked example
Discovery at a food distributor
This example is invented to show how answers turn into a first phase. A food distributor runs on accounting software, a warehouse spreadsheet and a great deal of messaging.
- GoalStop selling stock that has already been promised or has expired. Month-end and purchasing are also slow, but this is the constraint that costs customers.
- ProcessFollowing one order shows that sales staff check a spreadsheet updated twice a day. Batches and expiry dates are tracked on paper in the cold store.
- DataThere are three item lists with different codes. Units differ too: sales sells cases, the warehouse counts pallets and purchasing buys by weight.
- SystemsThe accounting software stays, and it has a documented interface. Invoices will be created there from confirmed orders.
- First moduleStock with batches and expiry, and order entry that reserves stock at once. Purchasing and reporting are planned as second and third phases.
Before any development, the distributor spends a month agreeing one item list and one set of units. That unglamorous work is what makes the first module possible, and discovery is what revealed it.
Use the answers to choose the first module
A good first module
- Removes the constraint the business feels most
- Has a clear owner who wants it
- Depends on few other areas
- Can run beside existing systems
- Gives a visible result within the first phase
A poor first module
- Chosen because it is the easiest to build
- Needs every other module to be useful
- Belongs to a department that does not want it
- Requires all master data to be perfect first
- Replaces something that already works well
Our ERP module planner lets you rank the areas of your business against these criteria and produces a summary to bring to a discovery workshop.
Discovery checklist
Custom ERP discovery checklist
0 of 11 checkedWhat to do next
Pick the area that hurts most and follow one real case through it this week, writing down each step, each handover and each spreadsheet. That single walk-through will tell you more than any list of modules.
Our custom ERP development page explains how we run discovery and build in phases. Tell us which area you would start with and we will say what we would want to see.
Common questions
How long does ERP discovery take?
It depends on how many areas are in scope and how available the people who do the work are. Discovery for one or two areas can be brief, while a company-wide review takes considerably longer. It is reasonable to run a full discovery for the first module and a lighter survey of the rest, deepening each area as its turn comes.
Should we replace everything at once?
Almost never. A custom ERP is best built and introduced one module at a time, beside the systems you already have, with each module proving itself before the next begins. A single company-wide switch concentrates every risk on one day. Staged delivery also lets early modules pay back while later ones are built.
Do we need a custom ERP, or would a packaged one do?
If your processes are close to standard, a packaged ERP configured well is usually faster and cheaper. Custom is justified when a core process is unusual and gives you an advantage, when packaged products would need heavy modification, or when licence costs do not suit your size. Discovery answers apply to both routes.
Who from our side should take part in discovery?
The sponsor, a lead for each area in scope, the people who actually perform the work in those areas, whoever looks after current systems, and your accountant for finance and statutory questions. Sessions with only managers produce the official process. Sessions that include the people at the desks produce the real one.
What should we receive at the end of discovery?
A description of each process as it will work, a data model in outline, a list of integrations with their direction, the scope of the first module, later phases in outline, risks with a response for each and an estimate with its assumptions. It should be usable by any competent company, not only its authors.