Process Standardization Before ERP: The Step Most Companies Skip

2026-09-24

Executive Summary

• ERP cannot standardize your processes — it can only operate processes that have already been defined.
• Organizations that implement ERP before their processes are consistent face configuration problems that generate compounding costs throughout the system’s lifetime.
• There are five recognizable warning signs that processes are not ready for ERP.
• Standardization before implementation does not need to be perfect — it needs to be consistent enough to configure and run.

What ERP Actually Requires From Your Processes

Before addressing the risks, it is worth being clear about what ERP actually requires.

ERP — regardless of platform — is not a tool for designing processes. It is a tool for operating processes that have already been designed. This distinction is far more consequential than most organizations recognize before they start.

When an implementation partner begins configuring the system, they need to know:

• How many steps does this process have?
• Who performs each step?
• Who approves, and under what conditions?
• What data needs to be captured at each point?
• When do exceptions occur, and how are they handled?
• How does this process connect to adjacent processes, and in what sequence?

If the organization cannot answer these questions consistently — meaning the same questions asked of different departments yield different answers — no implementation partner can configure the system accurately or efficiently.

What actually happens in these situations: processes get configured according to the opinions of whoever spoke most confidently in the workshop session, not according to operational reality. This is the origin of a large proportion of the problems that surface after go-live.

5 Warning Signs Your Processes Are Not Ready for ERP

These warning signs do not require a formal assessment to identify. They are visible to anyone willing to look at operations honestly.

Warning Sign 1: Processes Live in People’s Heads, Not in Documentation

When you ask a department head to walk you through a process they own, the answer is typically verbal — or a Word document or spreadsheet created years ago that no one has maintained since.

If a process exists only in the memory of one or a few people, and those people taking leave or leaving the company causes the process to change in practice, the process is not documented to a level that supports ERP configuration.

Warning Sign 2: Every Team Has Its Own Way of Doing Things

This is the most common pattern in fast-growing SMEs: processes are not designed — they form organically through the habits of individuals.

The result is that the organization does not have one procurement process. It has three or four procurement processes, each managed by a different person in a different way. ERP cannot operate four parallel versions of the same process.

Warning Sign 3: ERP Requirement Workshops End With “It Depends”

A very specific indicator: in requirements workshops with the implementation partner, when asked how a particular situation is handled, the answers tend to be “it depends”, “that case is different”, “let us come back to that”, or “team A does it this way but team B does it differently.”

Each of these responses signals that the organization does not yet have a single, agreed-upon version of that process.

Warning Sign 4: Exceptions Are More Common Than the Rule

Exceptions exist in every organization — that is normal. The problem occurs when exceptions become so common that no one can clearly articulate what the standard process actually is.

When every purchase order has a special reason, when every customer has undocumented individual terms, when approval steps can be bypassed when a manager is unavailable — these are symptoms of a process that has never been genuinely standardized.

ERP needs to know what the rule is in order to handle exceptions correctly. Without a clear rule, everything becomes an exception — and the system cannot function.

Warning Sign 5: Accountability for Each Step Is Unclear

When a defective batch arrives, who decides how it is handled? When an invoice does not match a purchase order, who has the authority to approve payment or request a correction? When a new product is added to the catalog, who is responsible for setting up the master data?

If accountability questions like these do not have clear answers — or if the answers depend on who happens to be available — the processes are not defined to a level that supports ERP implementation.

The Cost of Skipping This Step

Organizations can choose to bypass process standardization and proceed directly to implementation. Many do. The outcome typically follows one of three patterns.

Pattern 1: The system is configured around the wrong process.

Without a standard process, implementation partners configure what they hear in meetings. The most vocal person in the room determines how the process works in ERP — not the person with the deepest operational knowledge. After go-live, employees discover the system does not match how work actually gets done and find workarounds: parallel spreadsheets, informal notes, requests for managerial exceptions.

Pattern 2: Uncontrolled customization.

When processes are undefined, different user groups have different ideas about how the system should behave. This produces a change request list that grows throughout the project, with cost and timeline extensions following each addition. The problem is not only the initial cost. Each customization creates a point of potential failure at upgrade time, and something that only a small number of people understand well enough to maintain.

Pattern 3: The project runs out of budget before go-live.

When process questions are not resolved before implementation, they are resolved during it — at significantly higher cost. Each workshop session to clarify a process that should have been clarified beforehand has a price. Each configuration revision adds time and money. Many ERP projects exceed budget not because the software costs more than expected, but because resolving things that should have been resolved before the project started consumes far more time than planned.

Process Standardization Before ERP — Not Perfect, Just Consistent

One important clarification: standardizing processes before ERP does not mean every step needs to be documented in a detailed flowchart and signed off by every stakeholder before the project begins.

The level required is: consistent enough to configure and operate.

More specifically:

Prioritize the processes within the initial implementation scope. Full organizational standardization is not a prerequisite — only the processes going into ERP in the first phase need to be ready.

Focus on the core flow, not every exception. Define how 80–90% of standard cases are handled. Exceptions can be addressed once the system has stabilized.

Document to the level where a new employee can follow it. If a new hire in the department can read the documentation and execute the basic process — that is sufficient documentation to start.

Assign a named owner to each process. Not to route all decisions through one person, but to provide a clear point of contact when the implementation partner needs to clarify requirements.

Self-Assessment: Where Do Your Processes Stand?

A practical check: select one core operational process within the scope of the ERP you are considering — for example, goods receiving, purchase approval, or customer order handling.

Then ask honestly:

• Is this process documented in writing, in enough detail for a new employee to follow?
• If I ask three employees who perform this process to describe it, will they describe it the same way?
• Who is the final approver, and is that clearly recorded somewhere?
• Has this process changed in the last 12 months? If so, was the documentation updated?

If several of these answers are “no” or “not sure” — those are gaps to address before implementation begins.

→ Related: Why SOPs Exist But Are Not Actually Followed — and What to Do About It

Next in the series: Data Readiness — Why “Clean Data” Is Harder Than Organizations Expect

→ Complete the ERP Readiness Assessment

→ Explore ERP Readiness Solutions

For context on why process standardization is critical before ERP begins, see the opening article: Is Your Business Actually Ready for ERP?

To dive deeper into the data side of ERP readiness, see: ERP Data Readiness — Why “Clean Data” Is Harder Than Organizations Expect

For the full landscape of why most ERP projects underperform, see the foundational pillar: Why ERP Projects Fail

This article is part of a series on ERP readiness for manufacturing SMEs.

Related articles:

• Why ERP Projects Fail — and What the Software Cannot Fix
• Is Your Business Actually Ready for ERP?
• Data Readiness: Why “Clean Data” Is Harder Than Organizations Expect
• Why SOPs Exist But Are Not Actually Followed