Before Buying an ERP: Twelve Questions Every Owner Should Ask

1. What a business owner is seeing

Before signing for an ERP, a business owner should ask whether the company is ready to standardize how it works—or expects software to solve disagreements between departments. This question matters especially to growing SMEs where senior management remains the informal escalation point for routine work.

A useful first diagnostic is to name the observable symptom. Is it late delivery, inconsistent records, duplicated work, customers waiting, or an approval bottleneck? Keep the diagnosis separate from the tool or person someone has already proposed.

2. The root cause beneath the symptom

ERP programmes struggle when master data is inconsistent, ownership is unclear, the chart of accounts is unresolved and requirements are replaced with a vendor demonstration.

A company may have talented people and reputable software yet still struggle because nobody has written down who owns the process, what a complete handover means, or which records represent the truth. Those operating decisions must precede automation.

3. The decision framework

Agree on business outcomes, process boundaries, master-data ownership, integrations, controls, acceptance criteria and support costs before vendor selection.

Ask twelve questions: Why ERP? Which processes first? Who sponsors it? Is the chart of accounts ready? Are items and units clean? What integrations? What customization? What permissions? What UAT criteria? How will balances reconcile? What is lifecycle support cost? What is the recovery plan?

Before committing budget, compare the cost of doing nothing for one quarter with the smallest controlled pilot. Include training, operational support, access control and the time required to reverse an unsuccessful change.

The twelve-question checklist

Photo source: Pexels.

• Which business outcome justifies ERP?
• Which processes go live first?
• Who is the internal executive sponsor?
• Has the chart of accounts been agreed?
• Are products, units of measure, customers and vendors clean?
• Which integrations are essential?
• What needs configuration versus customization?
• How are permissions and duties separated?
• What are the UAT acceptance scenarios?
• How will balances and migrated records be reconciled?
• Who supports the system and at what ongoing cost?
• What is the continuity or rollback plan?

Related perspective: CRM Is Not a Contact Book: Design Real Sales Stages

4. Practical implementation steps

Choose one department or a limited, representative workflow first. Name the person responsible for the pilot, set a review date and collect employee feedback. Broad rollout should follow evidence of reliable day-to-day use.

• Select the highest-value process chain and draw its current and target state.
• Clean products, units of measure, customers, suppliers and accounting data with named owners.
• Test a complete quote-to-cash and purchase-to-pay workflow using realistic scenarios.
• Document UAT acceptance, migration reconciliation, support ownership and continuity arrangements.

5. An illustrative scenario

A hypothetical distributor implements Odoo while the same product exists in boxes, pieces and cartons without approved conversion rules. Inventory differences appear after migration. The issue is not fixed by a prettier interface; the measurement data must first be governed.

The example is educational. Adapt its logic to your actual company, verify any legal or sector-specific constraints locally and never present a fictional case as ORVEAX client evidence.

6. What success looks like—and what can go wrong

Track reconciliation differences, failed UAT scenarios, manual workarounds and post-launch support incidents.

Establish a baseline before changing the process. Common mistakes include purchasing technology before defining responsibilities, confusing completed tasks with business outcomes, skipping handover training and ignoring exceptions because the dashboard looks green.

Ask the team two questions after the pilot: can a colleague follow the process without calling its original designer, and can management explain why an exception was approved? If not, the operating model is not mature enough.

An ERP decision gate before issuing an RFP

Put the evidence in one brief to distinguish vendor-selection readiness from unresolved operating design.

If these answers are not documented, avoid requesting extensive customizations. Stabilize the operating foundation, then compare vendors against one controlled scope and testable outcomes.

7. The next step for your company

Take one issue that repeatedly consumes the business owner's time. Write down how it works today, the intended outcome, the accountable owner and one measurable improvement. That becomes a more reliable starting point than a software shopping list.

ORVEAX's Digital Business Foundation approach begins with operating structure and ownership, then designs an appropriate digital setup. A focused Business Structure Review can help define the first practical step without promising a predetermined technology purchase.

• Area — Evidence to assemble
• Processes — Agreed purchase, sales, and inventory flows
• Data — Named owners for items, customers, and suppliers
• Access — Documented roles, approvals, and exceptions
• Integration — Systems and data exchanges listed
• Total cost — Delivery, training, support, maintenance, and future changes
• Acceptance — Test scenarios and authorized sign-off roles