Custom ERP implementations are the doctorate-level project of business analysis. Every process is connected to five others, configuration is as consequential as code, and getting it wrong can paralyse an organisation. In this episode, Benjamin Walsh walks through the seven-step blueprint for how a BA should tackle a custom ERP — and what separates the BAs who survive them from those who don’t.

Listen on Spotify — The Better Business Analyst Podcast

Why Custom ERP Is a Different Universe for Business Analysts

If you’ve only ever worked on SaaS apps, integrations, or workflow tools, an ERP implementation will feel like a different planet. Here’s why:

An ERP is the organisation’s nervous system. Touch it wrong and you paralyse something critical. Every process is coupled — a change to procurement affects inventory, inventory affects finance, finance affects reporting, reporting affects governance. There’s no isolated change. There’s no “just this one area.”

That tightly coupled nature is both the power and the risk of systems like SAP, Oracle ERP, Microsoft Dynamics, and custom-built equivalents. And unlike a Salesforce implementation where you’re configuring known patterns against established IP, a custom ERP often requires you to define how the entire business runs — not how people think it runs.

“The business doesn’t really know what they really need — not because they’re incompetent, but because ERPs force them to define how the business actually runs, not how they think it runs.”

— Benjamin Walsh, BBAI Podcast

Configuration Is as Powerful as Code

This is the insight that separates experienced ERP BAs from everyone else: in a custom ERP, configuration can make or break the entire solution. If the BA doesn’t get it right, developers cannot rescue it. The system is designed to be configurable — which means it will do exactly what it’s configured to do, right or wrong.

Whether it’s mapping a GL account structure, pointing item code 197 to the right cost centre, or defining workflow approval thresholds — these decisions belong to the BA. They’re not an afterthought. They’re the product.

The Seven-Step ERP Blueprint for Business Analysts

Step 1 — Understand the Enterprise Before You Touch the ERP

You cannot jump to future-state design without first understanding the operating model, the value chain, the financial model, customer flows, how data moves through the organisation, and where the real bottlenecks are. Without this foundation, the ERP becomes a Frankenstein of assumptions — and you get led through each module individually, creating a mess that nobody can maintain.

This current-state understanding is not optional. It’s the entire basis for every configuration decision that follows.

Step 2 — Deep Dive into End-to-End Process Mapping

ERPs require full end-to-end process modelling — not isolated functional mapping, not user story mapping. The standard ERP process flows you must map include:

• Lead to Cash / Opportunity to Order
• Procure to Pay
• Hire to Retire
• Forecast to Report
• Build to Deliver / Make to Stock
• Asset Lifecycle Management
• Customer Service to Resolution

Each should be modelled at three levels: Level 0 (high-level value chain), Level 1–2 (core process areas), and Level 3 (detailed steps, business rules, data elements, and actors). This is where 50% of real BA value is created on an ERP project.

Step 3 — Define Solution Scope via Process Gaps

On an ERP project, you don’t define scope by what users want. You define it by gaps — aim points, control issues, data issues, compliance requirements, and process inconsistencies. ERP is about fixing the model, not replacing today with a digital version of the same problems.

This reframing is critical: the goal is standardisation and operational integrity, not feature delivery.

Step 4 — Write Architectural-Level Requirements

ERP requirements are not business-as-usual user stories. They must map to process steps, procedures, master data rules, integrations, reporting requirements, and financial controls. This is epic-level, architectural requirements writing — and it requires a different level of rigour and abstraction than standard feature requirements.

Step 5 — Configuration Requirements (Where Junior BAs Fall Over)

This is the step where 90% of junior BAs struggle. Configuration requirements means mapping:

• Business workflows → system behaviour
• Business rules → configuration objects
• Organisation structure → system hierarchy
• Roles → permissions
• Data models → master data structures

You must understand how the ERP wants the business to work — what constraints you’re accepting by using the system, where you can flex, and critically, what configuration choices will break downstream processes or financial integrity. Getting this right is what earns you the title of Senior BA.

Step 6 — Define the Wrappers (Custom Extensions and Integrations)

Every custom ERP implementation has extensions — custom modules, custom workflows, API layers, data transformations, and integration points. These must be defined in detail and validated against core processes. This is a substantial body of work on top of the core ERP configuration, and it cannot be left to developers to define.

Step 7 — Cutover, Data Migration, and Operational Readiness

ERP go-lives succeed or die on this step — even if everything else was done perfectly. A lead BA must own:

• Master data cleansing and validation
• Data format transformation and mapping (old structures → new)
• Cutover playbook development
• Role-based training content (what each role does in the new system)
• Process-based UAT scenarios tied to real end-to-end flows
• Business readiness assessment

Most teams de-prioritise this because time runs out. Most failed ERP go-lives trace back to inadequate data migration or operational readiness — not technical failure.

What BAs Must Do Differently on ERP Projects

• Be harder on process owners. “This is how we’ve always done it” is not acceptable. ERPs hate bespoke — every customisation means pain, delays, cost, and technical debt. Push towards standardisation.
• Treat data as a first-class citizen. Every ERP process relies on data discipline. BAs must lead this — not assume someone else will handle it.
• Own the process-to-system traceability. You are the translation layer between the business and the system. No one else is positioned to hold this.
• Protect financial integrity. ERP originated as a financial system. If BA decisions break finance, the project is effectively dead. Every configuration choice needs to be evaluated through a financial lens.

ERP Is the Project That Makes Your Career

“If you’re a BA stepping into the world of custom ERP implementations — it’s hard. It’s complex. You’ll feel overwhelmed. But it’s also the project that makes your career. If you do ERP well, you can do anything.”

— Benjamin Walsh, BBAI Podcast

A full ERP implementation typically needs four to six BAs. It is not a one-person job. But if you lead it — or contribute meaningfully to one — you’ll have demonstrated a depth of analysis capability that transfers to every other project type.

Key Takeaways

• Custom ERP is doctorate-level BA work — every process is connected, configuration is as powerful as code
• Start with enterprise understanding before touching the system
• Map all major end-to-end flows at three levels of detail
• Define scope by gaps and compliance requirements, not by user wants
• Configuration requirements are the most critical and most underestimated BA deliverable
• Data migration and operational readiness kill more ERP projects than technical failure
• ERP done well makes your career — it demonstrates a level of analysis capability nothing else matches

Free BA Templates for ERP Projects

Use these free templates on your next ERP project:

• Gap Analysis Template — map current vs. future state before touching the system
• Process Mapping Template (AS-IS / TO-BE) — structure your end-to-end flow documentation
• Requirements Traceability Matrix — trace process steps through to configuration and testing
• RAID Log — manage the risks and issues that come with every ERP implementation
• UAT Test Plan Template — build process-based test scenarios for go-live readiness

Subscribe to the Better Business Analyst Podcast

Weekly episodes on business analysis, requirements, stakeholder management, and BA career development. Subscribe on Spotify or watch on YouTube. Browse all episodes on our podcast page.

Also useful: 15 Essential BA Techniques | Requirements Gathering Guide | How to Write a BRD