I've been implementing ERP systems for over twenty years. SAP Business One, Acumatica, and a handful of others across manufacturing, distribution, professional services — you name it. More than 120 implementations. And somewhere around implementation number thirty, I stopped being surprised by what actually determines success or failure.
It's never the software. It's never the hardware. It's never even the budget. It's whether the people were truly bought in before the system went live — or whether they were simply informed that change was coming and expected to comply.
That distinction — bought in versus informed — is the single most expensive lesson in enterprise technology. And most companies learn it the hard way.
120 Implementations, One Lesson
When I look back across every SAP Business One and Acumatica project I've led or advised on, the pattern is so consistent it's almost boring. The implementations that succeeded — the ones where adoption hit 90%+ within the first quarter, where the ROI timeline actually matched the business case, where people weren't quietly running shadow spreadsheets six months later — those projects had one thing in common: the team was emotionally and intellectually invested before the first server was configured.
I'm talking about the warehouse supervisor at a building materials distributor who could explain to his team why the new pick-pack-ship workflow mattered — not because management told him to, but because he helped design it. The production planner at a food manufacturer who championed the new MRP module because she'd spent three months articulating exactly how the old system was costing her team two hours a day in manual workarounds.
These weren't technology champions by title. They were people who felt ownership over the change because someone took the time to connect the system to their daily reality.
Now contrast that with the failures. And I've seen plenty. The implementations where the C-suite signed the contract, the IT team ran the project, and the end users showed up to a two-day training session the week before go-live. Those projects don't just underperform — they actively destroy trust. People learn that "transformation" means "more work with less input," and that lesson sticks for years.
The $2M Mistake I Watched Happen
A few years ago, I was brought in to consult on a situation that still keeps me up at night. A mid-market manufacturer — about 200 employees, $80M in revenue — had spent just north of $2 million on a full ERP implementation. New system, new hardware, new integrations with their CRM and their EDI platform. On paper, the project was textbook.
Eighteen months after go-live, adoption was hovering around 40%.
Four out of ten people were actually using the system as designed. The rest had reverted to Excel, to the old access databases, to sticky notes and tribal knowledge. The finance team was manually reconciling data between three different sources every month-end close. The warehouse was printing pick tickets from the new system and then re-entering confirmations into a spreadsheet "just to be safe."
The company's leadership was convinced the software was the problem. They were shopping for a replacement. Another $2 million. Another two-year project. Another round of disruption.
But the software wasn't broken. I spent two weeks on-site, and the configuration was solid. The data migration was clean. The integrations worked. The problem was that nobody on the floor had been asked what they needed. Nobody had been involved in process design. Nobody had been given a reason to trust the new system beyond "this is what we're doing now."
→ The most expensive ERP failures don't show up on the implementation invoice. They show up eighteen months later in lost productivity, shadow systems, and the quiet erosion of your team's trust.
We didn't replace the software. We replaced the approach. Six months of structured change management — role-by-role process workshops, identifying and empowering informal leaders, creating feedback loops that actually got acted on — and adoption climbed to 85%. The system they thought was broken had been fine all along.
What "Bought In" Actually Means
When I say people need to be "bought in," I don't mean what most consultants mean. I don't mean you held a town hall. I don't mean you sent a company-wide email from the CEO. I don't mean you scheduled three days of classroom training and checked the box.
Bought in means every person affected by the change can answer one question: "What does this mean for me — not the company, not the department — me?"
That's a fundamentally different conversation than most organizations are willing to have. It requires sitting with an accounts payable clerk and understanding that her resistance to the new approval workflow isn't about the software — it's about the fact that she's built fifteen years of professional identity around being the person who "knows how things work," and you just made that knowledge obsolete without acknowledging it.
It requires understanding that the shipping manager who keeps undermining the new WMS isn't a bad employee — he's a guy who's been burned by three previous "transformations" that all meant more work and less autonomy.
This is where my work as a Certified Dream Manager fundamentally changed how I approach technology implementations. The Dream Manager framework starts with a radical premise: when people feel genuinely seen — when their individual aspirations and concerns are acknowledged — they become capable of embracing change that would otherwise terrify them.
It's not soft. It's strategic. When a warehouse team member tells you his dream is to move into a logistics coordination role, and you can show him how mastering the new system is the direct path to that promotion — you don't have an adoption problem anymore. You have an advocate.
The Three Questions I Ask Before Any Implementation
After twenty-plus years, I've distilled my pre-implementation assessment down to three questions. I ask them in the first meeting, and the answers tell me more about the project's likelihood of success than any RFP or requirements document ever could.
→ Question One: Can your team — not your managers, your frontline team — describe their current process in one sentence? If they can't, you don't have a technology problem. You have a clarity problem. And no ERP in the world fixes that.
→ Question Two: Who are the informal leaders who will make or break adoption? Every organization has them. They're not on the org chart. They're the person everyone goes to when they have a question. The person whose body language in the training room determines whether twenty other people engage or check out. If you can't name them, you haven't done the work yet.
→ Question Three: What's the dream this technology serves? Not the business case — I've read the business case. I mean the human case. What does life look like for your people on the other side of this change? If the only answer is "more efficient processes," you've given them nothing to fight for.
These questions make some leadership teams uncomfortable. Good. That discomfort is the gap between where they are and where they need to be before they spend a dollar on software licenses.
Why Trinity One Pairs ERP with Dream Management
This is the thesis of my entire practice, and it's the reason Trinity One exists: technology adoption is a people problem disguised as a technology problem.
The data backs this up at every level. Industry research consistently shows that 50-75% of ERP implementations fail to meet their objectives — not because of technical issues, but because of organizational resistance, poor change management, and lack of user adoption. The technology works. The people strategy doesn't.
On the other side of that equation, the Dream Manager Program — the framework I'm certified in and have deployed across multiple organizations — produces results that directly address the root cause of implementation failure. Companies running Dream Manager programs have documented 68% reductions in employee turnover and 91% employee engagement rates. When you have a workforce that's engaged, that trusts leadership, and that feels invested in the company's future, technology change doesn't feel like a threat. It feels like a tool.
That's not a coincidence. It's a causal relationship. Trust is the foundation of change management, and Dream Management builds trust at a depth that no training program or communication plan can match.
When I work with a company on an SAP Business One or Acumatica implementation today, the ERP workstream and the people workstream run in parallel from day one. We're not bolting on change management as an afterthought. We're building the human infrastructure that makes technology adoption inevitable rather than aspirational.
→ The companies that get this right don't just implement software successfully. They build organizations where the next change — and the one after that — gets easier every time. That's the real ROI.
If you're planning an ERP implementation — or recovering from one that didn't land — I'd love to have a conversation about what the people side of your project looks like. Not the technical requirements. Not the project timeline. The people. Because after 120+ implementations, I can tell you with certainty: that's where the outcome is decided.