Executive BriefDigital Transformation

Seven questions to ask before starting an ERP programme

ERP programmes rarely fail on technology. They fail on decisions taken — or avoided — before procurement begins.

10 Sep 2026 · 4 min read

Why it matters

An ERP decision commits an organization to a multi-year cost base, a fixed data model and a way of working that is expensive to reverse. Most of the risk is created in the months before a vendor is selected, when scope, ownership and process design are still assumptions rather than decisions. These seven questions surface that risk while it is still cheap to address.

The questions
  1. 01

    Which processes genuinely need integration, and which merely need to work?

    Integration is expensive and it couples processes together permanently. A process that runs adequately in a standalone system, and whose data management does not need in real time, is a candidate for interfacing rather than absorbing. Deciding this early is what keeps scope defensible later.

  2. 02

    Who owns each end-to-end process — not each department's part of it?

    ERP failures are usually ownership failures. Procure-to-pay and order-to-cash cross four or five functions, and if no single person is accountable for the whole flow, design decisions get resolved by whoever escalates hardest. Name the process owners before the design workshops, not during them.

  3. 03

    Which management decisions should the system support?

    Work backwards from the decisions. If management needs to see committed-but-uninvoiced spend weekly, that requirement shapes the commitment accounting design, the approval workflow and the chart of accounts. Systems specified from transaction lists produce complete data and unusable reporting.

  4. 04

    What is the current state of the data that has to migrate?

    Migration is where optimistic plans meet reality. Duplicate vendor records, inconsistent cost centres and part-numbers that encode meaning in free text all have to be resolved by someone, and that someone is almost always the client rather than the implementer. Profile the data before you commit to a go-live date.

  5. 05

    How much configuration are we prepared to accept, and how much customization will we refuse?

    Every customization is a permanent tax on upgrades, testing and support. The useful question is not whether to customize, but which handful of processes are genuinely a source of competitive or regulatory distinction and therefore worth the tax. Everything else adapts to the package.

  6. 06

    What has to change in how people work, and who is accountable for making it change?

    An ERP go-live changes job content for hundreds of people. If adoption is delegated to training delivered in the final month, the organization will run shadow processes in spreadsheets and the reporting will never reconcile. Adoption needs an owner, a budget line and a measurement plan from the outset.

  7. 07

    How will we know, six months after go-live, whether this was worth it?

    Define the measures before the programme starts, while the baseline is still observable. Close cycle time, approval turnaround, inventory accuracy, and the proportion of management reports produced without manual consolidation are all measurable before and after. Without a baseline, benefit realization becomes a matter of opinion.

Management implications
  • Scope discipline is set before procurement, not during delivery.
  • Process ownership is an organizational decision, not a project role.
  • Data quality work starts earlier than most plans assume.
  • Customization decisions should be explicit, few and defended.

Discuss this with someone who has done it.

Start a conversation →