Contact Info
Process Mapping
What is ERP process mapping?
ERP process mapping documents how work flows through a business today (as-is) and how it should flow once an ERP is in place (to-be). I map core end-to-end flows such as order-to-cash, procure-to-pay and record-to-report as simple swimlane diagrams, showing every role, handoff, decision and system. The maps become the shared reference for requirements, configuration, testing and training.
Last reviewed by Vikas Saroj
An ERP automates processes. If nobody can draw those processes on one page, the ERP will automate confusion. ERP process mapping makes the flow of work visible: who does what, in which order, in which system, and where it waits for someone else.
I map processes end to end, across departments, because that is where ERP value and ERP problems both live. A sales order touches sales, credit control, the warehouse, logistics and finance. Mapping each team separately hides the handoffs where most delays and errors happen.
The maps are deliberately simple. I use a lightweight, BPMN-style notation that business owners can read and correct without training, while still being precise enough for an implementer to configure from.
What I Do
I map the core flows that an ERP will run, plus the industry-specific processes that make your business different.
Swimlane maps of how each core process runs today, including spreadsheets, side systems, manual checks and the exceptions people handle from memory. Accurate as-is maps are the baseline for every later decision.
Future-state maps showing how each process should run on the new ERP: fewer handoffs, clear approvals, single data entry and controls built into the flow rather than checked afterwards.
From inquiry and quotation through order, credit check, fulfilment, delivery, invoicing, collection and cash application, including returns, credit notes and disputes that often get forgotten.
From purchase requisition and approval through ordering, receiving, quality checks, supplier invoice matching and payment, with clear rules for partial receipts and price differences.
Journal entries, accruals, reconciliations, intercompany, period close and management reporting, mapped so finance can see where close depends on manual effort and late inputs from other teams.
Plan-to-produce for manufacturers, project-to-invoice for contractors and services firms, and stock-to-ship for distributors, mapped with the same care as the standard financial flows.
My Consulting Journey
Business first, technology second. You can hire me for one step - a BRD, a gap analysis, a vendor shortlist - or for the whole journey.
How I Work
Walk through real transactions
Agree process list and boundaries
Workshops with process participants
Walk through real documents
Record exceptions and workarounds
Draw as-is maps and find issues
Swimlane as-is maps
Mark handoffs and wait points
Highlight duplicate data entry
Validate maps with owners
Agree how processes should run
To-be swimlane maps
Approvals and controls defined
Link maps to requirements
Sign-off by process owners
Most businesses run on processes that have grown over time rather than been designed. A step was added after an audit finding. A spreadsheet appeared when the old system could not handle a new product. An approval was introduced for one large customer and never removed. Each change made sense at the time, but together they produce a process that nobody can fully describe.
Put that process into an ERP without looking at it, and three things tend to happen:
ERP process mapping avoids this by putting the real flow on paper before any configuration. It shows where work is duplicated, where it waits, where control depends on individuals, and which steps exist only because of current tool limitations. Those findings shape the requirements, the gap analysis and the solution design. If you are earlier in the journey and still need to understand the business more broadly, start with ERP business analysis, which includes initial as-is discovery.
I always map in two stages, and I keep them separate on purpose.
As-is maps describe how the process runs today, honestly, including the parts people are not proud of. They are drawn from real transactions in workshops with the people who do the work, not from policy manuals. Their job is to establish facts: how many handoffs a purchase order goes through, where approvals wait, which steps are repeated in two systems.
To-be maps describe how the process should run on the new ERP. They are designed with process owners, using what the as-is maps revealed and what good ERP platforms support as standard. A to-be map typically has fewer handoffs, approvals that happen inside the system, data entered once and controls built into the flow.
Skipping the as-is stage is tempting, because it feels like looking backwards. But without it, the to-be design is based on assumptions, and you lose the ability to show stakeholders what is actually changing for them. That comparison is also the basis for training and change management later. The difference between as-is and to-be is often where the business case for the ERP becomes concrete.
I draw process maps as swimlane diagrams. Each lane is a role or department, such as sales, credit control, warehouse or accounts payable, and the flow moves across lanes as work changes hands. This makes handoffs impossible to hide: every time the line crosses a lane, someone is waiting for someone else.
I use a deliberately small set of symbols, a BPMN-lite approach:
Full BPMN notation is powerful, but most finance directors and warehouse managers will not read it. A simpler map that the business actually reviews and corrects is far more useful than a technically perfect diagram nobody checks. The maps are still precise enough for an implementer to configure from, and each step can be linked to requirements in the requirement log.
Most ERP scope is built around a few end-to-end flows. I map these first because they cross the most departments and carry the most risk.
| Flow | Typical scope | Common issues I look for |
|---|---|---|
| Order-to-cash | Quote, order, credit check, fulfilment, invoice, collection | Pricing outside the system, delayed invoicing, manual credit checks, unclear returns |
| Procure-to-pay | Requisition, approval, purchase order, receipt, invoice match, payment | Orders raised after the fact, missing receipts, manual invoice matching |
| Record-to-report | Journals, reconciliations, intercompany, close, reporting | Late inputs from operations, spreadsheet consolidation, manual accruals |
| Plan-to-produce | Demand, planning, work orders, consumption, costing | Stock not matching reality, costing done offline |
For each flow I also mark where it hands data to the others, for example where a goods receipt in procure-to-pay creates the accrual that record-to-report has to clear. Industry context changes the detail. A contractor's project-to-invoice flow looks nothing like a distributor's stock-to-ship flow. My articles on ERP for manufacturing and ERP for trading show how these flows differ by industry.
A process map is not a deliverable that sits in a folder. In a well-run ERP project it is used at almost every stage, and I design the maps with that reuse in mind.
Because I am independent of any vendor, the to-be maps describe the best way for your business to work, not the way one product happens to work. They stay valid whichever platform you choose. Process mapping also helps businesses that are not ready for an ERP: sometimes a cleaner process and better use of existing tools solves the immediate problem, which my business process consulting covers. Get in touch to discuss which processes to map first.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
FAQ
An as-is map shows how a process runs today, including manual steps, workarounds and delays. A to-be map shows how it should run on the new ERP, with fewer handoffs, approvals inside the system and data entered once. Comparing the two shows exactly what will change for each team.
A swimlane diagram is a process map divided into horizontal or vertical lanes, one for each role or department. Steps sit in the lane of whoever performs them, so every time the flow crosses a lane you can see a handoff. It is the clearest way to show cross-department processes.
I use a lightweight, BPMN-style subset: tasks, decisions, start and end events, documents and systems. It is precise enough for implementers but simple enough for business owners to review and correct without training. If your organization has a BPMN standard, I can follow it.
Start with the end-to-end flows that cross the most departments and carry the most money: usually order-to-cash, procure-to-pay and record-to-report, plus any industry-specific flow such as production or project billing. Supporting processes can follow once the core is clear. Mapping in that order keeps the most important decisions first.
I use standard diagramming tools that your team can open and edit after the engagement, and I can work in tools you already use. The tool matters far less than the content: accurate steps, clear handoffs and maps that the business has actually reviewed.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Insights
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.
