ERP Business Analysis

Why ERP business analysis comes before software

Most ERP problems I am asked to look at did not start in the software. They started earlier, when nobody wrote down how the business actually worked. Finance assumed sales would capture contract terms. Operations assumed the system would handle partial deliveries the way they do today. Leadership assumed reporting would simply appear. None of these assumptions were tested until user acceptance testing, when changing course is slow and expensive.

ERP business analysis puts that discovery at the front of the project. Before anyone compares Zoho, Odoo, ERPNext or Microsoft Dynamics 365, I want to know:

• which processes create value and which only exist to work around current tools;
• where data is owned, duplicated or missing;
• which approvals, controls and compliance obligations are non-negotiable;
• what management needs to see each week and each month.

Business analysis before software implementation is the cheapest risk reduction available in an ERP program. It is also the step most often skipped when a vendor is eager to start configuring. If you already know you need a structured requirement set, see my ERP requirements gathering service, which builds directly on this discovery work.

How I run discovery workshops and stakeholder interviews

I run discovery remotely, in short focused sessions rather than marathon days. Each workshop has one process area and a clear set of questions, and I ask participants to bring real documents: a recent sales order, a supplier invoice, a stock count sheet, a month-end checklist. Walking through actual transactions exposes the exceptions that generic questionnaires miss.

Group workshops are paired with one-to-one stakeholder interviews. The finance controller, the warehouse supervisor and the managing director each see the business differently, and they often say different things when they are not in the same room. I listen for:

• Goals: what each person needs the business to do better.
• Pain points: delays, rework, errors and blind spots, in their own words.
• Workarounds: spreadsheets, side systems and manual checks that keep things running.
• Dependencies: who waits on whom, and what breaks when someone is away.

Every session is written up within a day or two, so participants can correct me while the conversation is still fresh. That habit alone prevents a large share of later misunderstandings.

From as-is mapping to requirement elicitation

Discovery notes are only useful once they are organized. I turn them into two connected artifacts. The first is a set of as-is process maps showing how work moves between people and systems today, drawn simply enough that the people who do the work recognize it. For the detailed mapping method, including swimlanes and to-be design, see my ERP process mapping service.

The second is a requirement and issue log. Each entry records what the business needs, why, who raised it and which process step it belongs to. This is where elicitation becomes analysis: I challenge vague statements such as "we need better reporting" until they become something testable, such as which report, for whom, at what level of detail and how often.

I also separate three things that often get mixed up:

• genuine business rules, such as credit limits or approval thresholds set by policy;
• current habits that could change without harm;
• features that are nice to have but solve no stated problem.

That separation is what keeps a later business requirement document focused. My guide on how to create an ERP BRD shows where this material ends up.

What you get at the end of the analysis

The deliverables are practical documents your team, any vendor and any implementation partner can use. A typical ERP business analysis engagement produces:

• Stakeholder map: who owns which process and decision.
• As-is process maps: for the core flows in scope, such as order-to-cash, procure-to-pay, inventory and month-end close.
• Pain point inventory: each problem described, located in a process and ranked by business impact.
• Requirement and issue log: the raw material for a BRD, with source and rationale for each item.
• Data and reporting notes: key master data, its quality, and the reports management depends on.
• Findings and recommendations: quick wins, decisions still open, and a clear next step.

Sometimes the honest recommendation is that you are not ready for an ERP yet, or that a process change and a better CRM would solve most of the pain. I would rather tell you that now than after you have signed a license agreement. Where an ERP is the right answer, the findings feed directly into BRD preparation and independent ERP evaluation.

Why an independent ERP business analyst

Vendors and implementation partners do run discovery, and some do it well. But their discovery usually happens after a sale, inside a product, and with a commercial interest in keeping scope aligned to what they deliver. Questions that might lead to a different platform, a smaller project or no project at all are rarely asked.

As an independent ERP business analyst, I have no license to sell and no implementation team to keep busy. My only job is to describe your business accurately and say what it needs. That makes the analysis portable: you own the documents, and you can take them to any vendor or partner you choose.

It also means continuity. One consultant who understands both your business and the technology can carry the analysis through to gap analysis, solution design and implementation oversight, so the reasoning behind each requirement is never lost. If you want to start with a wider view of the ERP journey, my ERP consulting page explains how this fits together, or you can book a discovery call to talk through your situation.