The ERP process map – six chains everything hangs on
An ERP glossary is sorted alphabetically. A company does not work alphabetically. Between order confirmation and incoming payment sit a hundred glossary entries – on the shop floor sit six steps, three departments and, usually, one media break.
This page therefore arranges the terms differently: along the six end-to-end process chains that virtually every company runs and that every ERP system models in some form. Each step links to the matching glossary entry. Below every chain you will find what tends to break in practice – the part vendor brochures leave out.
The map is vendor-neutral. It describes what has to happen, not what a particular product calls it. That is precisely what makes it usable as a grid for your own as-is assessment: annotate each step with "which system today, run by whom, with which media break" and after one morning you have a firmer basis than after three vendor presentations.
The six chains
1. Order-to-Cash (O2C) – from customer request to cash in the bank
The chain that generates revenue. It ties together sales, logistics and accounts receivable.
Incoming paymentImport the bank statement, match the payment to the open item.
Where it breaks: At the availability promise. Sales commits to a date based on yesterday's stock figure or on instinct. As soon as production and procurement are not looking at the same plan, this is where the backlog appears that nobody ever catches up on. Second weak point: matching payments to open items when customers send lump-sum transfers without a clean reference.
2. Procure-to-Pay (P2P) – from demand to a paid invoice
The mirror image of O2C, seen from purchasing. Most of the cost side originates here.
Identify demandA threshold is breached, or planning raises a requirement.
Purchase proposalDetermine quantity and date — manually or from the planning run.
Select the supplierTerms, framework agreements, ratings from supplier history.
Send the orderVia EDI, portal or PDF — whatever the supplier can handle.
Invoice verificationCapture the invoice and match it against order and goods receipt.
Post the liabilityCoding, approval, early-payment discount deadline in view.
Release paymentPayment run, bank transfer, confirmation back into the system.
Where it breaks: At the three-way match between purchase order, goods receipt and invoice. As long as quantity or price deviations are cleared by hand, every invoice costs minutes instead of seconds — and discounts expire. The second perennial is maverick buying: purchases made outside the process by email or company card that only surface when the invoice arrives. Both are measurable before you pick a system: how many invoices arrive today without a purchase-order reference?
3. Plan-to-Produce – from the plan to the finished part
The manufacturers' chain. It depends on data quality more than any other.
Detailed schedulingSequence and setup optimisation at hourly rather than daily level.
Shop-floor confirmationGood quantity, scrap, times — the data basis for everything downstream.
Post-calculationWhat did the part actually cost, compared with the estimate?
Where it breaks: At confirmation discipline. Without reliable actual times and quantities from the shop floor, post-calculation is fiction — and the next estimate carries the error forward. The second fracture line is the bills of materials themselves: if engineering changes are not tracked rigorously, the system plans against a product that is no longer built that way. High-variant manufacturers should additionally check whether the system handles variant manufacturing without a BOM explosion.
4. Record-to-Report (R2R) – from posting to financial statement
The chain where all the others end. Whatever fails to arrive here does not exist commercially.
Post the transactionEvery entry traceable and logged without the option to alter it.
RetainUnalterable, machine-readable, for the full statutory period.
Where it breaks: At reconciling the subledgers. Receivables, payables, inventory and assets have to agree with the general ledger — when stock valuation and the nominal account drift apart, the team spends days hunting differences during the close. The second classic is the procedure documentation: it gets postponed during implementation and is then missing during a tax audit. Both belong in the selection phase, not in the go-live scramble.
5. Hire-to-Retire (H2R) – from headcount need to leaving date
The chain that most often runs outside the ERP in mid-sized firms — and still reaches into it.
Where it breaks: At the exit. Payroll is reliably stopped; the ERP authorisation often stays live for months — a finding that shows up in every second access review. Technically solvable through Active Directory and single sign-on, organisationally only through a defined offboarding step. Second point: if payroll runs in a separate system, the posting of personnel cost needs a cleared interface — otherwise it gets re-keyed from a spreadsheet every month.
6. Demand-to-Supply (D2S) – from demand signal to supply
The bracket around purchasing, production and warehouse. It decides how much capital sits in stock.
Forecast demandBring together history, seasonality, orders and market knowledge.
Avoid amplificationKeep small demand swings from becoming large order waves.
Verify stockCount without shutting the operation down for three days.
Where it breaks: At forecast quality — and at what follows from it. If you never measure the forecast against actual demand, you will not notice that safety stock has been tying up a multiple of what is needed for two years. The bullwhip effect is not a textbook curiosity: it arises in real life wherever each tier of the chain adds its own buffer because it does not trust the numbers from the tier before it.
The seams – where chains touch
Within a chain, software usually works well. Problems arise at the transitions, because that is where ownership changes and often the system with it. These six seams deserve the closest scrutiny during selection — they are the difference between an ERP system and a collection of modules.
Sales promises a date that production and procurement have to hold. This only works if the promise comes from the same plan that is produced against — otherwise available-to-promise is a number without cover.
Invoice and receivable (O2C ↔ R2R)
A delivery becomes an invoice, an invoice becomes an open item. Where format obligations such as XRechnung or ZUGFeRD apply, this is where it is decided whether the document arrives in a form the customer can process at all.
Invoice verification (P2P ↔ R2R)
Purchase order, goods receipt and supplier invoice have to find each other automatically. This seam is the most rewarding automation candidate in the whole company — and the most honest test of how well document recognition really performs day to day.
Confirmation and valuation (Plan-to-Produce ↔ R2R)
Production times and material consumption become cost of goods and inventory values. Without confirmations, neither post-calculation nor the balance sheet is right — and nobody notices until the close.
Personnel cost (H2R ↔ R2R)
Payroll generates postings on cost centres, projects and orders. If it runs in a third-party system, that handover has to be automated and reconciled, not typed in afterwards.
Master data (every chain)
Item, customer, supplier, employee, account: every chain draws on the same pool. That is why master data management is not clerical work but the precondition for processes running through at all. The principle behind it is the single source of truth.
What to do with the map
1. An as-is assessment in one morning
Print the six chains or transfer them to a whiteboard. Annotate every step with three things: which system does it run in today, who performs it, and where does the medium break (spreadsheet, email, paper, verbal)? The media breaks are your real requirements list — not the wish list from the departments. In our experience, 80 per cent of the tangible benefit of an ERP implementation lies in closing those breaks.
2. Gather requirements by process, not by department
A requirements document structured by department describes the same reality six times from different angles — and omits the handovers. Structured by chain, every requirement sits where it takes effect, and the seams become requirements in their own right. For the template see the requirements document template; for the distinction from the functional specification, requirements document vs functional spec.
3. Cut vendor demos differently
The usual demo runs module by module and looks good at every vendor. Ask instead for a run along one chain using your data: an order from enquiry to incoming payment, a supplier invoice with a quantity deviation, a production order with scrap. Wherever a system jumps into a spreadsheet or a second application at a seam, you will see it immediately. The RFP process supplies concrete questions for this.
4. Decide the implementation sequence
Not every chain has to move at the same time. The usual and generally sensible order is R2R (financial accounting as the foundation), then O2C and P2P, then Plan-to-Produce and finally H2R. The reason lies in the dependencies: production needs valued inventory, and inventory needs a working general ledger. What that means for timeline and resources is covered in rollout planning.
Limits of this representation
Three caveats, so the map does not promise more than it can deliver. First, real processes are rarely linear: complaints, partial deliveries, cancellations and subsequent changes create loops that a chain diagram cannot show. Second, the sequence does not hold everywhere — in engineer-to-order the design work starts only after the order, so O2C and Plan-to-Produce interlock. Third, the step names are deliberately neutral; every system calls them something else, and some merge two steps into a single document.
If you need more precision, measure rather than draw: process mining reconstructs the actual paths from the document timestamps in your legacy system — including the variants nobody documented. The map does not become redundant then; it becomes the legend you read the measurement with.
Häufig gestellte Fragen
Why do I need a process map if I already have a requirements document?
A requirements document describes what you need; the map describes how things connect. Together they prevent the most common mistake in ERP selection: requirements are gathered department by department, and nobody checks whether the handovers between departments still work in the new system. In practice that is exactly where the pain sits — not in an individual feature, but at the seam between two chains.
The sequence we recommend: map the six chains onto your own operation first, then gather requirements per chain, then write the requirements document. That way every requirement stays visibly attached to the point in the chain where it applies.
Are these all ERP processes, or are there more?
These are the six chains that exist in virtually every company and that every ERP system models in some form. Alongside them sit industry-specific chains — Idea-to-Product in development, Issue-to-Resolution in service, Acquire-to-Retire for assets — plus special cases such as project delivery or intercompany settlement in a group.
Project-driven and one-off manufacturers should mentally extend the O2C chain with project manufacturing and engineer-to-order: there the order exists before the product has been designed, and the chain runs in loops rather than in a straight line.
Does one ERP system have to cover all six chains?
No, and in reality it almost never does. Payroll usually runs in its own system, the warehouse often in a WMS, shop-floor control in an MES. What matters is not whether everything sits in one system, but whether the handovers are defined — who owns which data, when does it move, what happens when it fails.
That architecture of specialised systems around an ERP core is called postmodern ERP. It is a legitimate choice, but it costs integration effort — which is routinely underestimated in the total cost of ownership.
Where does it break most often in practice?
At the seams, not inside the chains. The three classics: an availability promise in sales that is not based on real stock and planning data; invoice verification where purchase order, goods receipt and invoice fail to match automatically; and shop-floor confirmations, without which no reliable post-calculation exists.
None of these is a software problem in the narrow sense — they are data problems. You can test them during selection by making the vendor demonstrate exactly those transitions in a test system, instead of walking through module by module.
How do I find out how my processes actually run?
By measuring, not by asking. Process mining reconstructs from the document timestamps in your legacy system which route an order or an invoice really took — including the loops that no org chart contains.
Without a dedicated tool, a simple substitute goes a long way: pull 20 completed transactions per chain, log every step with date and owner, then compare lead times. The outliers show you where the process genuinely differs from its description.
Can I use this map for a workshop?
Yes — that is what it is designed for. A format that works: give each chain its own wall or whiteboard frame. Participants mark, for every step, which system it runs in today, who performs it and where the medium breaks (spreadsheet, email, paper, verbal). After two hours you have an honest as-is picture — and the media breaks are the list of requirements that actually matter in the new system.
The step names on this page are deliberately vendor-neutral so they transfer to any system.
