Map Before You Modernize: Start with ERP Process Mapping

In the first article in this series, I talked about why successful ERP projects begin with business outcomes, not software features.

Once leadership agrees on those outcomes, the next question is usually:

“Which ERP system should we look at?”

I think there is a more important question to answer first.

That’s where ERP process mapping comes in.

“How does our business actually work today?”

After decades of working with organizations evaluating and implementing ERP systems,

I've learned that this question is harder to answer than most executives expect.

Ask ten people how an order moves through the company and you may get ten different answers.

• Sales describes one process.

• Operations describes another.

• Finance sees something entirely different.

And somewhere in the middle, an employee says, “Well, technically that's the process, but here's what we actually do.”

That sentence is where ERP discovery really begins.

Your ERP Demo Is Only as Good as the Processes Behind It

Software demonstrations are designed to be impressive.

• The salesperson enters an order.

• Inventory updates instantly.

• A workflow triggers.

• The dashboard changes.

• An approval appears on someone's phone.

• Everything moves beautifully.

Then someone in the room says, “That's not really how we do it.”

That's the moment that matters.

Because an ERP demonstration can show you how software works.

It cannot tell you how your business should work.

That requires process mapping.

What is ERP Process Mapping, and Why Is It Important?

Process mapping documents how work, information, decisions, approvals, and handoffs move through your organization today: who does what, what information they need, which decisions are made, where handoffs occur, where approvals happen, and where the process slows down or breaks.

More importantly, good ERP process mapping exposes the work that never appears on a software requirements list.

• The spreadsheet someone created eight years ago.

• The report Finance manually rebuilds every Friday.

• The customer-service employee who calls the warehouse because she doesn't trust inventory availability.

• The purchasing manager who keeps his own list because the system doesn't provide the information he needs.

Those aren't side issues.

Those are the clues.

That visibility matters before you select or implement an ERP system. It helps uncover inefficiencies, workarounds, duplicate tasks and hidden requirements so the new ERP supports better business processes instead of simply recreating old ones.

This is where business process mapping for ERP also strengthens ERP requirements gathering, because your team is documenting what the business actually needs before evaluating how a system should support it.

You Wouldn't Remodel a House Without Looking Behind the Walls

Imagine buying an older house and deciding to remodel the kitchen.

You walk into a showroom and immediately fall in love with beautiful cabinets, new appliances, quartz countertops, and smart lighting.

You order everything.

Then construction begins.

• That's when the contractor discovers the plumbing runs through the wall you planned to remove.

• The electrical system can't support the appliances.

• The floor isn't level.

• And somebody made three additions to the house over forty years without updating the original plans.

Suddenly, your beautiful new kitchen has become a very expensive construction problem.

ERP projects can unfold exactly the same way.

The software demo is the showroom.

Process mapping is opening the walls.

Before you decide what technology should support the business, you need to understand what's actually happening underneath it.

Most Companies Don't Have Just One Process

They have layers of processes accumulated over time.

A company begins with a straightforward way of doing something.

• Then a customer asks for an exception.

• Someone creates a workaround.

• The business acquires another company.

• A spreadsheet gets added.

• An employee leaves.

• A regulation changes.

• A new manager creates another approval.

Ten years later, nobody remembers why half the steps exist.

They just know, “That's how we've always done it.”

• I've seen processes with twelve steps where four were necessary.

• I've seen employees enter the same information into three systems.

• I've seen reports that took hours to prepare even though almost all the underlying data already existed.

• And I've seen organizations prepare to spend significant money customizing a new

ERP system to reproduce those exact same processes.

Think about that.

They were about to automate the inefficiency.

“Don't Pave the Cow Path”

There's an old expression in process improvement: don't pave the cow path.

Years ago, cattle created wandering trails because they were navigating trees, streams, and terrain.

If you came along later and simply paved those trails, you'd certainly have a better road surface.

But you'd still have a crooked road.

That's what happens when organizations replace an ERP system without examining their processes.

• They digitize the detours.

• They automate the workarounds.

• They recreate old approvals.

• They build customizations around business practices nobody has challenged in years.

The new system may be faster. But the process is still crooked.

Modern ERP transformation should ask a different question:

If we were designing this process today, would we design it this way?

Sometimes the answer is yes. Often, it isn't.

Gartner Is Warning Organizations About This Problem

The stakes are significant.

Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as 25% will fail catastrophically. Gartner also reports that 75% of ERP strategies are not strongly aligned with overall business strategy.

Those numbers should get every executive's attention.

But Gartner's guidance about ERP selection is equally important.

Its recommended process includes defining and prioritizing use cases and functional requirements around current and future needs before vendor demonstrations.

Gartner then recommends controlling those demonstrations with scripts focused on business objectives, results, and how users will actually interact with the ERP solution.

In other words:

Don't let the demo define your requirements.

Your business processes should define the demo.

Should You Map Business Processes Before Selecting an ERP System?

Without process mapping, ERP evaluation questions tend to sound like this:

• “Do you have workflow?”

• “Does the system support approvals?”

• “Can it automate purchasing?”

• “Does it integrate with Excel?”

• “Does it have AI?”

Every major ERP vendor can answer questions like those. Usually with a very enthusiastic yes.

Process mapping creates much better questions.

Instead of asking, “Do you support purchasing approvals?” you can say:

“Today, purchase requests above $25,000 require three approvals and take an average of four days. We want to reduce that to one business day without weakening financial controls. Show us how your system would handle that.”

Now you aren't watching a feature. You're evaluating a business outcome.

That's an entirely different demonstration.

That is why I recommend mapping business processes before selecting an ERP system. Instead of giving vendors a generic feature list, you give them real operational scenarios to solve.

Your team can evaluate how well each ERP supports the outcomes you want, while identifying integration and customization needs earlier.

The demonstrations become more relevant because they reflect how your organization actually operates and how you want it to operate in the future.

That makes the ERP selection process less about checking boxes and more about comparing how each solution supports the way you want the business to operate.

Follow the Order

One of the most valuable process-mapping exercises I use is surprisingly simple.

Follow one customer order through the business.

Start when the customer places it.

• Where does the information go?

• Who touches it?

• Does anyone re-enter it?

• \Who verifies inventory?

• How is the delivery date determined?

• What happens if inventory isn't available?

• Who tells purchasing?

• Who tells production?

• Who tells the customer?

• When does Finance see the transaction?

• How many spreadsheets, emails, phone calls, and side conversations are required before that order becomes cash?

Executives are often surprised by what this exercise reveals.

On an organization chart, departments appear neatly separated into boxes.

In real life, business processes run horizontally across every one of them.

Customers don't experience your departments. They experience your processes.

An ERP system does too.

What Is the Difference Between Current-State and Future-State Process Mapping?

Understanding the current state is only half the job.

Current-state ERP process mapping documents how work happens today, including bottlenecks, manual steps, exceptions, and workarounds.

You also need to define the future state: how the process should work after improvement or ERP implementation. This distinction matters.

If you only document what happens today and hand that document to an ERP vendor, you've created instructions for rebuilding the past.

Looking at current state and future state together helps you decide what to keep, eliminate, redesign, or automate rather than carrying outdated processes into a new ERP system.

That is the heart of business process improvement: not just documenting the work but deciding how it should work better.

A modern ERP project should identify three things:

What should remain?

Some processes genuinely differentiate your business. Protect them.

What should disappear?

Duplicate entry, unnecessary approvals, manual reconciliations and shadow spreadsheets are obvious candidates.

What should change?

This is where standard ERP functionality, automation and better information can redesign how work gets done.

It is also where ERP workflow automation can remove repetitive steps and speed up handoffs without simply automating an inefficient process.

The objective isn't to force every business into generic processes.

And it isn't to customize every screen until the new ERP looks exactly like the old one.

The objective is to understand where your processes create competitive value and where complexity simply accumulated over time.

Standardization Is Not the Enemy

This can be uncomfortable.

Every organization has processes that someone believes are unique. Sometimes they are.

Sometimes we've simply been doing them differently for so long that different feels necessary.

Before approving customization, I like to ask:

“What business outcome does this unique process create?”

If the answer is meaningful, keep exploring.

If the answer is, “That's how we've always done it,” keep questioning.

Customization isn't inherently bad. Unexamined customization is.

Every customization introduces something the organization will have to test, maintain, upgrade, and understand in the future.

Process mapping helps distinguish genuine competitive requirements from organizational habits.

That clarity also helps define ERP customization requirements, so you can separate capabilities that truly need to be unique from habits that should not be carried forward.

Your Best Process Experts May Not Be in the Conference Room

There's another mistake I see frequently.

Leadership maps the process without involving the people who actually perform it.

Executives know how a process is supposed to work. Employees know how it really works.

You need both perspectives.

• The warehouse supervisor knows why inventory gets moved before the transaction is entered.

• Accounts payable knows which vendors consistently create exceptions.

• Customer service knows which promises are difficult to keep.

• The production planner knows which spreadsheet quietly holds the schedule together every Monday morning.

Those employees aren't obstacles to transformation. They're your field guides.

They know where the trail gets difficult because they walk it every day.

Include them early.

You will uncover better requirements, identify risks sooner, and make future adoption much easier.

Map First. Demonstrate Second.

Software demonstrations absolutely have a place in ERP selection. Just not at the beginning.

First, define the business outcomes.

Then understand the processes that produce those outcomes.

Identify the friction.

Challenge unnecessary complexity.

Design the future state.

Then invite ERP vendors to show you how their technology supports it.

When you reverse that sequence, the software drives the conversation.

When you get the sequence right, the business drives the software decision.

That's the difference between buying an ERP system and transforming an organization.

For organizations preparing for a Dynamics 365 Business Central implementation, that same process-first discipline helps create clearer requirements and a stronger foundation for change.

Final Thoughts

Stay tuned for the next and final article in this series.

Because if you want to know where to begin your process mapping, there's a remarkably reliable place to look.

Look at your best employees.

If they're spending their days building spreadsheets, re-entering data, creating manual reports, chasing approvals, and inventing workarounds, they're telling you something.

Your people have been compensating for your technology.

In Part 3, we'll explore why your best employees working around your ERP may be the clearest sign that it's time for change.

Don't start your ERP journey by asking software vendors what their systems can do. Start by understanding what your people are already doing.

Map the business first. Then choose the technology that helps you build a better one.

Before Your Next ERP Conversation, Map One Process.

Pick a process your team touches every day and follow it from beginning to end.

Look for the handoffs, spreadsheets, duplicate entry, workarounds, and moments where someone has to stop and ask, “What happens next?”

You may learn more about what your business needs from that one exercise than you will from an hour-long software demonstration.

Map the work first. The right technology decisions become much clearer afterward.

And if you need help mapping the way forward, I’m always happy to share what I’ve learned and guide your team through the process.

About the Author 

Terri Marello, President of Key Partner Solutions, is a thought leader in the Microsoft Dynamics space and the author of the LinkedIn newsletter "Why Ask Why?", where she explores the intersection of technology and business strategy.

Subscribe now for more insights straight to your inbox.

Key Partner Solutions is an experienced Microsoft VAR with the in-house skills to optimize your business and smoothly migrate to cloud-based Microsoft Dynamics 365 Business Central.