Process mapping before an ERP implementation

Before an ERP system is selected, the current processes should be mapped with volumes, variants, media breaks and the forms they use. This gives the requirements document a factual basis, shows which exceptions the system has to handle, and provides the baseline against which the new process is later measured. Map broadly but not in endless detail: the goal is decisions, not an archive.

Why map before selecting

Vendors demonstrate standard processes. Whether the standard fits depends on your processes: how many cases, which variants, which approvals, which data comes from outside. If this is unknown, the selection compares demonstrations instead of fit, and the gaps appear during the rollout, when they are expensive.

Mapping first also separates two questions that often get mixed: what the organization needs, and how it does things today out of habit. A step that exists only because two systems do not talk to each other is not a requirement; the data flow behind it is.

Volume figures: the numbers the requirements need

Requirements documents usually have a chapter with volume figures: orders per day, invoices per month, items, customers, users. These numbers decide sizing, licenses and which processes deserve automation. Record them per process together with the period they refer to (see volumes and case counts).

Volume alone is not enough. Equally important are the shares at decisions (how many invoices need an approval, how many orders are custom-made) and the peaks, for example month-end or seasonal business.

Case types instead of the regular process only

Many guides recommend mapping only the regular process. For an ERP project that is risky: the exceptions are exactly what the standard may not cover. The template “Order processing” works with three case types: standard orders (80%), custom-made orders (15%) and export orders (5%), each with its own path at the decisions. A system that handles the 80% elegantly but forces the 15% into workarounds may cost more than it saves.

Case types with their shares make this visible without mapping every variant as a separate diagram. More in case types and exceptions.

Media breaks and forms are requirements

Every media break describes a data flow that the new system should either take over or connect: invoice data from the scan, order data from the customer’s email, master data typed twice. Every form describes data that someone needs at a step. Together they are a precise list of interfaces and input masks (see media breaks and forms).

The fit-gap idea

A fit-gap analysis compares each step of the mapped process with what the candidate system does out of the box: fit, fit with configuration, or gap. Gaps are then decided one by one: change the process, extend the system, or accept a manual step.

The mapped current process with metrics helps to weigh a gap. A gap in a step that 5% of the cases pass and that takes two minutes is different from a gap at the bottleneck. The metrics per step and per case type supply exactly that weighting.

How much effort is right

Mapping can grow without end. Limit it in three ways:

• Scope: only the processes the system will support, delimited with trigger, result and participants (see process scoping with SIPOC).
• Depth: steps at the level of “who does what with which system”, not every click.
• Precision: estimated ranges instead of time studies. A rough figure that is available in time is worth more than a measured one that arrives after the decision.

What goes into the requirements document

From the mapping, the requirements document typically takes:

• a description of each process with its steps, lanes and decisions,
• the volume figures and shares, including case types and peaks,
• the media breaks and forms as interface and data requirements,
• the current metrics as a baseline: lead time, cost per case, staffing per role,
• the open questions the mapping could not answer, such as approval limits or how often a special case occurs. In the editor they are “To clarify” entries on the steps and are listed in the report; a requirements document that names its open points is more reliable than one built on guesses.

Frequently asked questions

Keep learning