What an ERP Implementation Consultant Actually Does

You're the operations director or VP of digital transformation at a mid-market manufacturer or distributor doing $50M to $500M in revenue. Your CFO approved budget for an ERP migration. Now you're tasked with finding the person or team who will make it work. You've heard "ERP implementation consultant" thrown around, but the job boards show resumes, the vendor calls pitch their partners, and you have no clarity on what you're actually buying.

Here's what's true: an ERP implementation consultant is not a software salesman, a project manager, or a systems analyst. They're the person who makes your team competent enough to use the software before it breaks your operation.

The Actual Job

I've led 18 mid-market ERP implementations over 12 years. Eight of those were as an implementation lead at Deloitte on $2M+ SAP projects. The other ten I ran independently, ranging from $400K to $1.8M engagements. The role is not what the job descriptions say.

An ERP implementation consultant does three things:

First, they translate your business process into software configuration and data structure. You don't just "implement SAP" or "go live on NetSuite." You implement your specific accounts payable workflow, your inventory costing method, your revenue recognition logic. The consultant maps what you do today to what the software will force you to do tomorrow. This mapping is not technical documentation. It's a decision log. It records what changed, why, and who approved it.

Second, they own the first 90 days after go-live. This is where implementations die. Your finance team is exhausted. Your old system is still running in parallel because the cutover was incomplete. Your AR is backed up because nobody trained on the cash application module. Your team is two weeks into a new system and the person who was supposed to maintain it has already quit. A real consultant stays embedded through this chaos. They triage. They document. They teach your team the workarounds that will hold you until you're stable.

Third, they manage the conversation about what you actually need versus what you want. Most implementations bloat because stakeholders believe the software can do anything. A consultant who's seen fifteen implementations before yours knows that SAP will do your three-way reconciliation, but it will force you to change how you structure your purchase orders. They say that out loud before you spend $300K configuring a workaround that will break in two years.

I've watched CFOs approve $1.2M implementations only to have the finance team bypass the system six months later because nobody explained why the software required them to code differently. The consultant's job is preventing that conversation from happening in the wrong sequence.

Why You'll Hire Wrong

The existing vendors and consulting firms ranking for this keyword—the big four, the regional firms—they're describing implementation as a structured methodology. Governance. Change management. Training programs. Testing phases. All of those exist. None of them matter if the consultant doesn't understand that your supply chain manager is going to quietly continue entering data into Excel after go-live because the software's lead time calculation doesn't match how your customers actually order.

I saw a $2.8M SAP implementation fail because the consultant managing it had only done one previous system migration, and that one was a five-year maintenance contract where the client never actually changed their processes. When our client needed to decide between customizing the software to match their current workflow versus redesigning the workflow to match the software, the consultant couldn't make that call. So both happened. The project ran 18 months over and $1.1M over budget.

Most hiring decisions look for someone with the right software certification or the right industry background. Those things help. What actually matters is whether the consultant has lived through a failed cutover and learned from it. Whether they've had to explain to a VP that their $400K customization won't work after the next software patch. Whether they've managed the political conversation when the new system reveals that the order fulfillment process has been broken for three years and nobody noticed.

Where This Approach Fails

There's a counterargument worth acknowledging. If your ERP implementation is truly greenfield—you're a five-year-old company that has never run an integrated system and your processes are still forming—you don't need a consultant who specializes in rescuing existing operations. You need someone who can architect a clean implementation because your political surface is flat and your technical debt is minimal. I've seen young companies over-invest in a consultant designed to manage dysfunction when they actually need someone to prevent it in the first place.

Also, if you're migrating from one major ERP to another within the same vendor family—Oracle to Oracle, SAP to SAP—the vendor's migration tools and accelerators can carry more of the load than I'm implying here. You still need someone, but the role is narrower.

But if you're a 20-year-old company running on a legacy system that's become a liability, or you're consolidating after an acquisition and your finance teams are running different processes, or you've outgrown your mid-market ERP and you're moving to enterprise software—you need someone who has seen this specific failure mode and lived through the recovery.

How to Know You've Found the Right Person

When you interview a consultant, ask them to describe a go-live they managed. Not the success story. The moment it went wrong. If they describe a problem and then immediately explain the fix, they're pattern-matching. If they describe a problem and explain why they didn't see it coming until it was too late, they're thinking about failure. That's the person you hire.

Ask them how long they stayed engaged after go-live. If they say "until the system was stable," ask them what stable means. If they can't define it with a specific timeline and specific metrics, they've never been accountable for that phase. Consultants who exit on day one after go-live are not ERP implementation consultants. They're implementation project managers.

Ask them what percentage of their time is spent in meetings versus in the system itself. If it's more than 30% meetings, you're paying for governance theater. You need someone whose hands are in the configuration, the data migration, the testing, the triage.

What This Means for Your Decision

You're going to spend between $150K and $600K on this hire, depending on engagement length and scope. That's real money. The difference between a consultant who understands that your finance operation is unique and a consultant who applies a generic playbook is not a difference in knowledge. It's a difference in outcome. I've seen the same software, the same timeline, the same budget produce a go-live that held because the consultant had worked in your industry and understood the failure modes, versus a go-live that collapsed because the consultant knew the software but not the operation.

Find someone who has done this 15 times or more. Find someone who has stayed past go-live. Find someone whose first question is not "What system are you moving to?" but "What's going to happen on day 91 when the consultant leaves and your team is exhausted?"

If you need help identifying the right fit for your specific situation, post your implementation scope and timeline on Symbrite. Consultants who've been through this before you can assess the risk factors you haven't named yet.

Ready to work with an expert?

Post your problem from AcumiSol and receive proposals from experts.