Build an ERP business case from work you can actually measure
Build an ERP investigation case with observed task time, error costs and delivery assumptions. Separate usable capacity from cash savings and avoid double counting.
Build the first ERP business case around a few recurring operating problems you can observe. Measure their current effort or cost, identify what would have to change, and keep the expected benefit separate from a verified result.
The decision at this stage is whether an implementation investigation is justified. You do not need to invent a precise return on investment before you know the scope, data condition, delivery cost or team's ability to adopt the system.
Start with one repeated piece of work
Choose a task with a clear beginning and end: reconciling a completed job before billing, finding a missing material record, or re-entering an approved order. Observe more than one occurrence and record the differences between ordinary and exceptional cases.
Keep active work time separate from elapsed waiting time. A bill that waits two days for approval has not necessarily consumed two days of labor. The delay may still matter, but it belongs in a different measure with its own explanation.
Use this baseline sheet:
| Baseline field | What to record |
|---|---|
| Task and owner | The work being measured and who performs it |
| Trigger and finish | Where the observation starts and ends |
| Observed sample | Record references, dates and case types |
| Active effort | Time spent doing, checking and correcting the work |
| Waiting | Time awaiting a decision or missing input |
| Error consequence | Actual rework or other evidenced effect |
| Recurrence | Count from records, or a clearly labeled estimate |
| Proposed change | What would remove or reduce the work |
| Evidence still needed | Test, decision or source that could change the case |
A broad complaint such as “the team wastes time in spreadsheets” is not a baseline. Name the spreadsheet, the task and the handoff it supports.
Separate capacity from cash
Consider an invented example: 40 jobs per week require six minutes of duplicate entry each. That is 40 × 6 = 240 minutes, or four hours per week. Using a four-week planning period gives 16 hours.
If a planning rate of $40 per hour is applied, the notional labor value is 16 × $40 = $640 for that period. It is not automatically $640 of cash savings. The same employees may remain on payroll and use the capacity for other work.
Now suppose a proposed change could remove half the duplicate-entry effort. That assumption produces eight hours of potential capacity, with a notional value of $320 under the same rate. It remains a hypothesis until a test includes the new process's review and exception work.
| Benefit category | Evidence required before claiming it |
|---|---|
| Available capacity | Comparable observed time after the change |
| Avoided cash expense | A specific expense that actually stops or is avoided |
| Fewer errors | Comparable cases and recorded error consequences |
| Additional contribution from work | Demand, available capacity and a supported contribution basis |
Do not count the same released hours once as labor savings and again as capacity for extra work without explaining the overlap. Have the financial owner define the treatment used in the final investment case.
Put the delivery costs beside the hypothesis
List implementation services, internal staff time, data preparation, subscriptions, integrations, training, support and any ongoing customization work that belongs in the proposed scope. Obtain actual estimates or quotes and label unknowns.
Custom work can create future responsibilities as well as initial effort. Odoo's upgrade guidance explains that custom modules may need code changes and additional testing when versions change. That supports including the maintenance owner and upgrade dependency in an Odoo case; it does not supply a universal annual cost percentage. Odoo customized-database upgrade guidance
Keep the cost of investigating an uncertain requirement separate from the cost of implementing a chosen solution. A small demonstration or data sample may resolve an uncertainty that would otherwise distort the whole estimate.
Use ranges to expose the uncertain assumption
In the invented duplicate-entry example, compare removal of one-quarter, one-half or three-quarters of the 16-hour baseline. The capacity outcomes are four, eight or 12 hours per four-week period. These are sensitivity cases, not probabilities or forecast commitments.
Ask which assumption matters most. If the case only works when nearly all effort disappears, test that workflow early. If the team lacks time to maintain the new process, reducing clicks alone may not produce the proposed benefit.
Use the five-job selection packet to test candidate workflows once the problem is defined. Keep the initial case dated and revise it as evidence arrives. The useful outcome is a decision with visible assumptions, a measurable baseline and a specific next test, rather than a large savings number detached from the work.