Understanding Before Decision

Before You Choose an ERP System, Understand This

I recently came across an article discussing ERP standardization, and it got me thinking. The article addressed a common concern that businesses must completely change the way they operate to fit an ERP system. I understand why people worry about that. If you've spent years building processes, workarounds, and ways of getting things done, the idea of replacing all of it is overwhelming. [praxisinfo...utions.com]

The more I thought about it, though, the more I realized I was asking a different question.

ERP systems can do many useful things. They can connect departments, improve visibility, standardize information, and help organizations manage complex operations. That's part of what makes them valuable. [deskera.com], [praxisinfo...utions.com]

My question is, before a company decides if it needs an ERP system, how well does it understand the way work actually flows through the business today? I mean, really understand it. Not just the process map, but the work-arounds people have created, the places where work slows down, and the little adjustments employees make every day to keep things moving.

That question feels obvious, but I'm not sure it always gets asked.

That's where I see RSR fitting into the conversation.

When I talk about visibility, I'm not talking about dashboards, reports, or software screens. I'm talking about understanding reality. How does work actually move through the organization? Where does it pause? Where does it get stuck? What do people do when the documented process doesn't quite work the way it was intended?

The discussion around standardization reminded me of a client I worked with recently. I worked with her to map out all the ways orders came into her business. Some through lead-gen pages from her Google ads, some through her website forms, some through emails, and some even through social media messaging. 

There was no standard.  Some fed directly into her CRM and some didn’t.  The CRM didn’t auto-feed into her accounting app.  When her accountant asked for year end numbers, she went to multiple sources to gather it all. 

Let’s look at another example.  Take an order approval process. On paper, it might look straightforward. An order is submitted, reviewed, approved, and released. Nice clean boxes connected by arrows.

Then you sit down with Sarah in Purchasing.

She explains that half the requests arrive missing information, so she spends part of every morning tracking people down. Mark in Operations tells you he keeps a spreadsheet because the information he needs isn't available where he needs it. Meanwhile, Jennifer in Accounting has developed her own checklist because certain requests regularly bounce back with errors.

None of them are trying to work around the process. They're just getting the work done.

Over time, I've started noticing that many of the most important parts of a process don't appear in the process itself. They appear in the adaptations people create to keep work moving. Some of the work-arounds were quite involved, some were dependent on a specific person with a lot of tribal knowledge. I was surprised at how often there was a file on people’s desks of work that was essentially stuck waiting for information.

That reminds me of when I worked at Honeywell as a Parts Expeditor.  After I learned who to talk to in each of the departments, I proactively reached out to the Material Planners once in a while and asked if they had any parts they needed help finding; a not-so-rare-problem between receiving and the floor.  But I digress… 

I remember in the early days at Honeywell I was asked to review the SOP for my job, and it was nothing like the work I actually did. Between the time to SOP was written and I got hired, the company had implemented their own ERP system.  Add to that my constant tweaking of processes to make them better, let’s just say there was a lot to update in the SOP.

I suspect this is why ERP implementations sometimes feel difficult. During implementation, people are asked to define and document how work happens. That's often when someone raises a hand and says, "Actually, that's not always how we do it.”

At first glance, that can look like resistance, but maybe they're seeing a flow that doesn’t reflect points of friction or work-arounds that happen frequently.

Or, they see a process as it was two years ago. But policy changes, staff changes, or really any kind of change, the process has since adapted to a new environment and documentation hasn’t updated.

Maybe they’re thinking about working within the new ERP system and recognize that the same problem that slows them down today is about to be built into the new system.

I've noticed a similar pattern with metrics.

Let's say management discovers that customer applications take five days to process. They decide the goal should be two days. Problem solved, right?

Maybe. Or maybe not.

What if applications spend three of those five days waiting for missing information from the customer? What if approvals are sitting in someone's inbox because they're buried under competing priorities? What if employees are correcting errors that originated somewhere else entirely?

The metric tells us what is happening. It doesn't necessarily explain why.

Without understanding the reason behind the delay, we risk treating symptoms while the underlying friction remains untouched. The same thing can happen with visibility.

ERP vendors often talk about the visibility their systems provide. Those systems can provide tremendous visibility into the processes and information captured within them. [deskera.com], [praxisinfo...utions.com]

But ERP can only see what is inside the ERP.

Reality often spills over into sticky notes, lists, spreadsheets, emails, notebooks, and countless other manual systems. Sue's spreadsheet may contain information she can't get anywhere else. Tom may rely on a daily conversation with another department because it prevents delays later in the day. None of that is likely to appear on a dashboard.

The more I think about it, the more I see RSR as something that belongs before ERP, before automation, and before many other improvement efforts. I've heard many people say they need Lean, automation, AI, ERP, or some other solution to make the business better. My question is always the same: based on what?

My lane isn't choosing the solution. My lane is helping organizations understand the problem well enough to make an informed decision.

If an organization takes the time to understand how workflow, where friction exists, and why people have developed workarounds, it enters every future decision with better information. Whether the next step is an ERP system, automation, process redesign, or something else entirely, the decision is based on real information.

Maybe that's what ERP readiness really means.

Not having perfect processes. Not having perfectly standardized workflows. Maybe it means having a clear vision of how the organization works.

Visibility before judgment. Understanding before decision.