Best Practices Don’t Exist (and Why That Myth Hurts Digital Transformations)

“Best practices” is one of the most common selling points in enterprise software.

Vendors promise that if you buy their ERP, CRM, or customer service platform, you’ll inherit the “best practices” baked into the system. Your processes will improve. Your teams will become more efficient. Your business will run better than it does today.

It’s a compelling message. It’s also one of the most misleading ideas in the enterprise technology world.

In this blog, we’ll unpack why software “best practices” don’t really exist, how the myth creates real risk during digital transformations, and what to do instead when your business doesn’t fit the “standard.”

What “Best Practices” Actually Means

Before we criticize the concept, it helps to define what vendors mean by “best practices.”

There are two very different categories:

1) Technology best practices (real and useful)
These are legitimate standards around things like cybersecurity, cloud infrastructure, performance, reliability, and deployment approaches. These practices exist for good reason, and following them typically reduces risk.

2) Business or software best practices (the problematic kind)
This is the idea that the way a software vendor designed a workflow is inherently the “best” way for your business to operate.

That’s where things get risky.

When vendors talk about “best practices” in ERP or CRM, they’re usually describing one thing:

The default configuration and workflow assumptions built into their product.

That may be a good starting point. It is not a universal truth.

The Subtle Manipulation Behind “Best Practices”

One reason “best practices” is such an effective sales message is that it flips the burden of proof onto you.

If the vendor says the software is built on “best practices,” then any resistance from your team can be framed as:

• “Your people are resisting change.”
• “You’re stuck in old ways of working.”
• “You’re over-customizing.”
• “You’re the reason the project is hard.”

It becomes a kind of reverse psychology.

The software is “best practice,” so any deviation must be the problem.

This dynamic has been around for decades, but it has gotten worse in the cloud era because many cloud systems are less flexible than older on-premise platforms. Organizations have fewer options to adapt the software, so they’re pressured even more to adapt the business.

You’ll hear the same idea packaged under different labels:

• Fit to standard
• Clean core
• Preconfigured industry solutions

Some of these approaches can be helpful in the right context, but they often carry the same underlying assumption: “Our default way is best.”

Why Best Practices Don’t Exist

Step back from technology for a moment and ask a simple question:

Is there a global governing body that defines “best practice” for your specific industry, business model, customers, strategy, and competitive positioning?

Of course not.

Now consider this: nearly every ERP and CRM vendor claims their software contains “best practices.”

If everyone has the best practices… then whose best practices are actually the best?

They can’t all be.

What you’re really seeing is marketing language used to make software decisions feel safer than they are.

The Bigger Problem: “Best Practice” Can Erase Your Competitive Advantage

There’s a more serious risk hiding underneath all of this.

Some parts of your business should look like everyone else’s. Other parts absolutely should not.

If you adopt “standard best practices” in areas where you’ve built a competitive edge, you can accidentally dilute what makes you different.

Think about a complex manufacturer with:

• unique engineering constraints
• specialized production methods
• unconventional fulfillment requirements
• customer-specific configuration
• differentiated service models

That complexity isn’t necessarily inefficiency.

Sometimes it’s the thing competitors can’t replicate.

When a vendor says “standardize to best practice,” what they often mean is:

“Operate in a way that’s easier for the software to support.”

That can be fine for commodity processes. It can be destructive for your secret sauce.

A Simple Rule of Thumb: Where “Best Practices” Do and Don’t Belong

Use this filter when you’re evaluating fit-to-standard decisions.

Best practices are usually fine for commodity processes, such as:

• accounts payable
• general ledger and basic financial structures
• standard reporting
• routine back-office workflows

These are areas where being “unique” rarely creates value.

Best practices are risky for differentiation processes, such as:

• customer experience workflows
• product configuration and delivery
• service models that drive retention
• industry-specific operating models
• anything that directly supports how you win in the market

This is where blindly “standardizing” can flatten what makes you competitive.

The goal isn’t to refuse change. The goal is to be intentional about where you change and why.

What to Do When the Software Doesn’t Fit

Once you identify areas where the “standard” workflow doesn’t support how you operate, you have a few options. The mistake is assuming customization is the only answer.

Here are three approaches to consider:

1) Reconsider the vendor (or the scope)

It may be that the software you’re evaluating simply isn’t a fit.

Even if the vendor works well for some parts of your business, you may not need every module they sell. Narrow the scope to the areas that fit best, and avoid forcing the platform into places where it creates compromise.

2) Use a composable or best-of-breed model

This is one reason composable ERP and interoperability strategies have gained momentum.

Instead of forcing one suite to run everything, you select:

• a core system for commodity processes
• specialized tools for differentiated functions
• integrations that connect the ecosystem

Yes, that adds complexity for IT.
Still, that technical complexity can be far less risky than operational compromise.

A system that “fits IT” but doesn’t fit the business creates hidden costs that show up later as workarounds, resistance, and poor performance.

3) Build what’s truly unique (selectively)

Custom development is not always a bad word. It just needs to be approached carefully.

The modern difference is that you don’t necessarily have to build everything from scratch.

Platforms and extensions can provide structured ways to develop:

• unique workflows
• competitive differentiators
• customer-facing capabilities
  without rewriting an entire ERP.

This should usually be the last option, but it can be the right one when you have a truly differentiated requirement and no off-the-shelf solution supports it.

The Real Goal: Be Deliberate, Not “Standard”

The biggest transformation failures we see don’t come from organizations having unique processes.

They come from organizations making unexamined tradeoffs.

“Best practices” becomes a shortcut that replaces strategy.

If you want to reduce risk, the real question isn’t:
“Should we follow best practices?”

It’s:

• Which processes should be standardized?
• Which ones should remain differentiated?
• Where does the business need flexibility?
• Where is simplification worth it?
• What are we protecting as core advantage?

That is how you avoid letting software dictate your operating model.

A Final Question for You

Where have you seen “best practices” help, and where have you seen them cause problems?

Some organizations benefit from standardization. Others accidentally standardize away their edge.

If you’ve lived through this, you already know the difference.