# ERP Process Mapping: The Requirements Work That Saves Your Project

> How to map business processes before ERP implementation — with practical swimlane diagram techniques, common mistakes to avoid, and a real example from an Indonesian SME.

URL: https://www.matthewswong.com/en/blog/erp-process-mapping-guide/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2025-06-10
- Updated: 2025-06-10
- Category: ERP

ERP process mapping is the least glamorous and most important phase of any implementation. It's the work that defines what the system actually needs to do — before a single screen is designed or a single line of code is written. Without it, you're building a system based on assumptions. With it, you're building a system based on how your business actually works. I've seen projects skip process mapping to 'save time' and spend 3x more time fixing the resulting mismatches in UAT. This post explains how to do process mapping correctly for an ERP project.

## What Process Mapping Is and Why It Matters

Process mapping is the practice of documenting how a business process works today (the 'as-is' state) and how it should work in the new ERP (the 'to-be' state). The gap between as-is and to-be defines your ERP requirements. Process mapping reveals: who does what (roles and responsibilities), what triggers each step (events and inputs), what decisions are made and by whom (approval logic), what data is needed and produced (data requirements), what can go wrong and how it's handled (exception paths), and what integrates with other systems (integration requirements). A process map is the source of truth for ERP design — every screen, every workflow, every field should trace back to it.

### The Process Inventory: Starting Point

Before mapping any process in detail, create a process inventory — a complete list of business processes that the ERP will support. For a typical Indonesian SME ERP covering HR, finance, and operations, the inventory includes 20–40 distinct processes. Organize them by module: HR (leave request submission, leave approval, payroll preparation, employee data management), Finance (AP invoice entry, AP payment approval, AP payment recording, AR invoice generation, AR reminder sending, bank reconciliation), Operations (purchase requisition, purchase order creation, goods receipt, inventory adjustment). The process inventory becomes your project scope document.

### Swimlane Diagrams: The Best Format for ERP Process Maps

Swimlane diagrams organize process steps by role (each role has its own 'lane' in the diagram) and show handoffs between roles as flows that cross lanes. They're the best format for ERP process mapping because they make approval hierarchies and handoffs immediately visible — the two things ERP systems are most often designed to support. For the AP invoice approval process: Employee lane (submits invoice), Manager lane (reviews and approves), Finance Staff lane (records approved invoice), Finance Manager lane (approves payment), Accounting lane (records payment and reconciles). Each box is a step, each arrow is a handoff, and each diamond is a decision point.

> From my experience as a freelance ERP consultant: run process mapping workshops with the people who actually do the work, not their managers. Managers describe how processes should work. Staff describe how processes actually work. The difference is where your ERP requirements are hidden. When I mapped the AR process for one client, the finance staff revealed that they were manually checking a separate Excel sheet for payment terms before sending reminders — a step management didn't know existed, and one that the ERP needed to automate.

## As-Is vs To-Be: Mapping the Gap

After mapping the as-is process, map the to-be process — how the workflow will work in the new ERP. The to-be map should reflect best practices where applicable, but it must be validated by the users who will execute it. Common improvements in the to-be map: eliminating manual data re-entry (entering the same data in multiple places), removing manual notification steps (replacing email chains with system notifications), adding system-enforced validation (the system checks required fields before allowing a step to proceed), and compressing multi-day approval chains into same-day workflows through mobile access.

> **Process mapping is not the same as documenting what people wish would happen**

> I've seen process mapping workshops turn into wish-list sessions where stakeholders describe their ideal future process rather than the reality of today. Both are valuable, but they serve different purposes. The as-is map must be painfully accurate — including all the workarounds, undocumented exceptions, and informal shortcuts. If your as-is map looks too clean, it's not accurate. Only after you have a true as-is can you design a to-be that actually addresses the real problems rather than the problems you thought you had.

## From Process Map to ERP Requirements

Each process map translates into a set of functional requirements for the ERP system. A functional requirement states: 'When [trigger], the system shall [action], so that [outcome].' For example: 'When a leave request is submitted and the employee has sufficient leave balance, the system shall automatically notify the direct manager for approval within 15 minutes, so that leave approval is completed within 24 hours.' Good requirements are specific enough that a developer can implement them and a tester can verify them. Vague requirements ('the system should support leave management') produce vague systems.

## Common Process Mapping Mistakes

The mistakes I see most often: mapping only the happy path (the process when everything goes right) and ignoring exceptions. In reality, 20–30% of transactions hit an exception path. Not identifying who owns each decision point — if the map says 'manager approves' without specifying which manager and under what conditions, the ERP can't implement it. Over-engineering the to-be map with ideal processes that nobody will actually adopt — design for how people will realistically work, not for perfection. Skipping the validation step where the process map is reviewed by the actual process participants before it becomes a requirement.

## Process Mapping in the Indonesian Business Context

Indonesian business processes have specific characteristics that require careful mapping. Approval hierarchies are often deeper and more hierarchical than Western business norms — a purchase order might require 4 levels of approval for amounts that would require 1 level in an equivalent Western business. Informal communication channels (WhatsApp groups for approvals, verbal sign-offs) are common and need to be explicitly replaced in the to-be map, not assumed to be already handled. Regulatory requirements (BPK audit trails, BPJS reporting, tax invoice formatting for e-faktur) must be explicitly captured in the process map and translated into ERP requirements. Missing a regulatory requirement in the process map often means discovering it in UAT — when it's expensive to fix.

## Sources & Further Reading

- Creately — ERP Business Process Mapping: A Comprehensive Guide — https://creately.com/guides/erp-bpm/
- Pemeco — BPR: An Essential Risk Management Process Before ERP Selection — https://www.affilityconsulting.com/bpr-crucial-risk-management-process-erp-selection/
- Terillium — 3 Best Practices for ERP Requirements Gathering — https://terillium.com/erp-requirements-gathering-best-practices/

> **Key takeaway:** ERP process mapping defines what the system must actually do before any screen is designed or any code is written. Skipping it means building on assumptions, and the cost surfaces later as rework during user acceptance testing, when changing a decision is far more expensive than making it was.

## Source links

- https://creately.com/guides/erp-bpm/
- https://www.affilityconsulting.com/bpr-crucial-risk-management-process-erp-selection/
- https://terillium.com/erp-requirements-gathering-best-practices/

## FAQ

### Why is process mapping considered the most important phase of an ERP implementation?

Process mapping defines what the ERP actually needs to do before any screen is designed or code is written. Skipping it means building a system based on assumptions rather than how the business really works — a shortcut that typically leads to costly mismatches discovered during UAT. The process map becomes the source of truth that every screen, workflow, and field should trace back to.

### What is the difference between an as-is and a to-be process map, and why do you need both?

The as-is map documents how a business process works today, including all workarounds, undocumented exceptions, and informal shortcuts. The to-be map shows how the process will work inside the new ERP, incorporating best practices and system-enforced improvements like automatic notifications and validation. The gap between the two defines your ERP requirements — you cannot design an accurate to-be map without first capturing a painfully accurate as-is.

### Why are swimlane diagrams recommended over other formats for ERP process maps?

Swimlane diagrams organize steps by role, with each role occupying its own lane, and show handoffs between roles as flows that cross lanes. This layout makes approval hierarchies and handoffs immediately visible — the two things ERP systems are most commonly built to support. Diamonds mark decision points, making it clear who approves what and under what conditions.

### What are the most common mistakes made during ERP process mapping?

The most frequent mistakes are mapping only the happy path while ignoring exception paths that account for 20–30% of real transactions, leaving decision points vague (e.g., 'manager approves' without specifying which manager or conditions), over-engineering the to-be map with ideal workflows nobody will adopt, and skipping the validation step where actual process participants review the map before it becomes a requirement.

### How do Indonesian business characteristics affect ERP process mapping?

Indonesian businesses typically have deeper, more hierarchical approval chains than equivalent Western businesses — a purchase order may require four levels of approval where one level would suffice elsewhere. Informal channels like WhatsApp group approvals and verbal sign-offs are common and must be explicitly replaced in the to-be map. Regulatory requirements such as BPK audit trails, BPJS reporting, and e-faktur tax invoice formatting must also be captured in the process map, as missing them usually surfaces in UAT when they are expensive to fix.

---

- HTML version: https://www.matthewswong.com/en/blog/erp-process-mapping-guide/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/erp-process-mapping-guide/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json