ERP Process Mapping: The Requirements Work That Saves Your Project

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.

Swimlane: Accounts Payable Invoice Approval (As-Is → To-Be)

AS-IS (current process — manual):
  ┌──────────────────────────────────────────────────────────────┐
  │ VENDOR         │ Sends paper/PDF invoice via email           │
  ├──────────────────────────────────────────────────────────────┤
  │ FINANCE STAFF  │ Receives email → enters into Excel         │
  │                │ → emails manager for approval (via Outlook) │
  ├──────────────────────────────────────────────────────────────┤
  │ MANAGER        │ Replies "Approved" via WhatsApp or email   │
  │                │ (no formal record, approval can be missed)  │
  ├──────────────────────────────────────────────────────────────┤
  │ FINANCE MGR    │ Checks Excel, approves payment             │
  │                │ → instructs bank transfer manually          │
  ├──────────────────────────────────────────────────────────────┤
  │ ACCOUNTING     │ Records payment in separate ledger file     │
  └──────────────────────────────────────────────────────────────┘
  Average time: 3–5 business days | Data in: 4 separate places

TO-BE (ERP workflow — automated):
  ┌──────────────────────────────────────────────────────────────┐
  │ FINANCE STAFF  │ Enters invoice in ERP                      │
  │                │ ↓ (system validates required fields)        │
  ├──────────────────────────────────────────────────────────────┤
  │ SYSTEM         │ Routes to Manager based on amount threshold │
  │                │ Sends push notification + email to Manager  │
  ├──────────────────────────────────────────────────────────────┤
  │ MANAGER        │ Approves/rejects in ERP (mobile or web)    │
  │                │ ↓ (system routes to Finance Manager if >Rp X│
  ├──────────────────────────────────────────────────────────────┤
  │ FINANCE MGR    │ Final approval → payment scheduled          │
  │                │ ↓ (system generates payment instruction)    │
  ├──────────────────────────────────────────────────────────────┤
  │ ACCOUNTING     │ Payment recorded automatically on confirm   │
  │                │ Audit trail: every action logged            │
  └──────────────────────────────────────────────────────────────┘
  Average time: 4–8 hours | Single source of truth

Gap analysis: 3 steps eliminated, 2 manual notifications automated,
              approval record now immutable in system.

From my experience implementing ERPs at Commsult: 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 we mapped the AR process at 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 Map → Functional Requirements Template

# Format: "When [TRIGGER], system shall [ACTION], so that [OUTCOME]"

requirements = [
    {
        "id": "AP-001",
        "trigger": "Finance staff submits a new AP invoice",
        "action": "System validates required fields (vendor, amount, date, "
                  "invoice number, supporting document) and rejects submission "
                  "if any required field is missing",
        "outcome": "No incomplete invoice records enter the workflow",
        "testable": "Attempt to submit invoice without each required field → "
                    "expect validation error per field"
    },
    {
        "id": "AP-002",
        "trigger": "AP invoice is submitted with amount ≤ Rp 5,000,000",
        "action": "System automatically routes to direct manager of submitting "
                  "staff for approval within 15 minutes",
        "outcome": "Low-value invoices are approved same day without "
                   "Finance Manager bottleneck",
        "testable": "Submit invoice ≤ Rp 5M → verify notification sent to "
                    "correct manager within 15 minutes"
    },
    {
        "id": "AP-003",
        "trigger": "AP invoice is submitted with amount > Rp 25,000,000",
        "action": "System routes to Manager AND Finance Manager simultaneously "
                  "for dual approval",
        "outcome": "High-value payments have mandatory dual control per "
                   "internal audit requirement",
        "testable": "Submit invoice > Rp 25M → verify both managers notified "
                    "and both must approve before payment is released"
    },
]

# Each requirement maps to: 1 database constraint / workflow state / UI element
# Each testable description becomes a UAT test case

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.

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.

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