NASHVILLE, TENNESSEE EST. 2023
Article · Informational

ERP implementation services: what most mid-size companies actually need.

One phrase. Four completely different problems.

Summary

Most companies searching for ERP implementation services do not actually need a VAR to reconfigure their system. They need integration between their existing tools, a custom workflow their ERP cannot support, or reporting built around how their business actually works. This post breaks down the four things people mean when they say ERP implementation and how to figure out which one you have.

When a mid-size manufacturing, distribution, or construction company says they need ERP implementation services, they usually mean one of four different things. Some need a VAR to configure a feature that already exists in their system. Some need their existing tools connected so data stops moving by hand. Some need custom reporting that reflects how their business actually operates. And some have a workflow their ERP simply cannot support, no matter how it gets configured. These are not the same problem. They do not cost the same to solve. And they do not require the same type of vendor.

The phrase “ERP implementation services” gets used as a catch-all for all four, which is why so many companies end up spending $40,000 with a VAR and getting none of what they needed. This post breaks down what the four needs actually are, how to tell which one you have, and what to do about each.

What is an ERP implementation service?

In the traditional sense, ERP implementation is the process of installing, configuring, and deploying an enterprise resource planning system for a business. A VAR — which stands for value-added reseller — typically handles this work. They are authorized by the ERP vendor to resell the software and configure it for specific industries or business types.

This model works well in one specific situation: when the ERP you have already supports the workflow you need and the gap is purely in how it has been set up.

The problem is that most mid-size companies use the phrase ERP implementation to describe four different situations, only one of which a VAR can actually solve.

Why does the distinction matter?

The average VAR engagement for a mid-size company runs $30,000 to $50,000. We regularly speak with business owners who have been through two or three of them at that price and still do not have what they need. The total spent before they find a different approach is often $80,000 to $120,000.

That is not because VARs are bad at what they do. It is because the business was trying to solve a problem the VAR was never equipped to solve. You can only configure a system so much. If the vehicle is not built to do what you need, putting a better driver behind the wheel will not change the outcome.

The most important thing you can do before hiring any ERP implementation partner is define which of the four problems you actually have.

How do the four types of ERP implementation actually work?

Type 1: True implementation — the feature exists, it just isn’t set up correctly

This is the one situation where a VAR is the right answer.

If your ERP has a feature you know exists and it is just not working the way it should, that is a configuration problem. A qualified VAR who knows the platform can get in, set it up correctly, and get out. The software can do what you need. It just has not been told to yet.

The diagnostic question here is simple: can you point to that feature in the software documentation, or have you seen another company use it? If yes and your system is not doing it, you probably need a better VAR, not a different approach.

Type 2: Integration — your tools do not talk to each other

Most mid-size companies run 8 to 15 separate software tools. Their ERP handles core operations, but they also have a CRM, a project management tool, an accounting platform, and a handful of industry-specific applications. None of these share data automatically.

The result is that someone on the team spends hours every day copying information from one system into another. Estimates get re-entered as purchase orders. Customer data gets moved manually from the CRM to the ERP. Reports require an export to Excel before anyone can read them.

This is not an ERP configuration problem. Reconfiguring your ERP will not make it share data with your CRM. What you need is integration, which means building connections between your existing systems that move data automatically without human involvement.

An integration project typically runs 2 to 3 months and does not require you to replace or relearn any of your existing tools.

Type 3: Custom reporting — your ERP cannot show you your business

Off-the-shelf reporting in most ERPs is built for the average company in your industry. If your business has unique cost structures, non-standard job types, or metrics that matter specifically to how you operate, the built-in reports will not show you what you need.

This is not a configuration problem either. The ERP’s reporting was never designed to surface your specific data in the way your business needs to see it. What you need is a custom reporting layer: a dashboard or set of reports built around your actual workflows and metrics, connected to your ERP data but presented in a way that reflects how your business actually runs.

Type 4: Custom workflows — your ERP cannot do what you actually need

This is the most common situation we encounter, and the one least likely to be solved by any VAR.

Every business has processes specific to how they operate. The way a specialty contractor packages material costs. The way a distributor handles partial fulfillment on a custom order. The way a manufacturer tracks job costing across multiple facilities. These workflows are often what make the business competitive, and they are exactly what no off-the-shelf ERP was designed to handle.

When a business has been through two or three VARs and still is not getting what they need, this is almost always why. The ERP does not support the workflow. Configuring it differently will not change that. What is needed is a custom workflow built outside the ERP, connected to it via API, that handles the specific process the platform cannot.

When you say you need ERP implementation, you have to define what that actually means. Each one requires a different methodology. But they are all covered under the same term.

What are the trade-offs for each path?

Going back to a VAR for more configuration is the fastest and lowest-cost option if the problem genuinely is configuration. But if the problem is integration, reporting, or a workflow the ERP does not support, another VAR engagement will produce the same result as the last one.

Integration projects are typically the fastest path to visible improvement. Connecting existing tools takes 2 to 3 months and does not require learning a new system. The trade-off is that integration solves the data flow problem but does not fix underlying workflow gaps.

Custom workflows take longer, typically 4 to 6 months for a focused scope, but produce something the business owns outright with no ongoing licensing fees. For companies that have spent $80,000 to $120,000 on VAR engagements without resolution, a custom workflow project often costs less than what they have already spent and actually solves the problem.

For companies considering whether to move off their ERP entirely, a module-by-module replacement is worth understanding. Rather than replacing the whole system at once, a developer pulls features out of the ERP one at a time, building custom replacements that run alongside the existing system. There is no downtime and no loss of efficiency during the transition. Most clients who go this route see 1 to 3 hours per user back in their day within the first few months, because the work is not just replacing what the ERP did but thinking through how to do it better.

Common questions

How do I know which of the four problems I have?

Start with one question: can you point to a specific feature in your ERP documentation that should be doing what you need and is not? If yes, it is a configuration problem and a VAR can solve it. If the answer is no, or if you have been through multiple VARs without results, you are likely dealing with an integration gap, a reporting gap, or a workflow the ERP simply cannot support.

We have already spent a lot on VAR implementations. Is it worth starting over?

That depends on what you have been trying to solve. If past implementations did not produce results, the first step is figuring out whether the problem was the configuration or the approach. We offer a free 30-minute consultation specifically to help answer that question.

Can we keep our current ERP and still build custom workflows?

In most cases, yes. Your ERP likely has an API a developer can connect to. The custom workflow lives outside the ERP but exchanges data with it automatically, so your team does not have to change how they interact with the core system day to day.

At what point should we consider replacing our ERP entirely?

When the list of things the ERP cannot support is longer than the list of things it can. Most companies reach this point gradually. They build one custom workflow, then another, then realize the ERP is handling less and less of the actual business. At that point, a full custom replacement built module by module alongside the existing system starts to make economic sense.

What is a VAR actually good at?

Configuration and deployment of features that already exist in the platform. If your ERP supports what you need and it is just not set up correctly, a qualified VAR is the right choice. We will tell you that honestly on a consultation, even if it means you do not work with us.


ERP implementation means something different for every business that searches for it. If you want help figuring out which of the four problems you are actually dealing with, our ERP Integration Services page covers what that work looks like in practice. Or book a free 30-minute consultation and we will work through it with you. You keep the assessment regardless of what you decide.

More from the blog

Keep reading.

Article No. 01

Do construction companies actually need an ERP?

Before you buy a construction ERP, you need to answer one question: what problem are you actually solving for?

Construction Custom Enterprise Software Decision guide
MAY 5, 2026 · 8 min read Read →
Article No. 02

Converting your estimating spreadsheet to custom software: what to know first.

Most companies that convert their estimating Excel to an app end up rebuilding the same friction in a different form. Here's how to avoid that.

Construction Legacy Modernization How-to
MAY 5, 2026 · 7 min read Read →
Article No. 03

Most companies don't need a new ERP. Here's how to know.

A consultation framework drawn from hundreds of calls with mid-sized owners trying to figure out their software.

Distribution Custom ERP Decision guide
MAY 1, 2026 · 8 min read Read →
Related service

ERP Integration.

If this article hit close to home, the matching service page covers what we actually do, what it costs, and how the work runs.

30 minutes No commitment No sales pitch Written summary, free to keep