On a discovery call last week, a controller at a CNC manufacturer told us something we hear more often than you'd think: they don't want a full ERP implementation. They'd already been through one that went badly, learned the software the hard way, and now they want a partner for advice, best practices, and the specialty work they can't do themselves, not someone to run the whole build.
Why a company would want less help, not more
Their first implementation ran long and cost more than double the original quote, partly because the monthly software fee kept running while the project dragged on. Along the way, their own team ended up doing a lot of the work anyway: importing inventory, building forms, writing customizations. By the end, they had real skills in-house and a healthy skepticism of paying for legwork they could do themselves.
That's a reasonable place to land. If your engineers can configure the system and load your data, you may not need a partner for that part at all. What you often still need is judgment: someone who can tell you when a thing you want to do will cause problems downstream, and who can handle the pieces that genuinely require deep platform knowledge.
The real scoping work: a shared-responsibility matrix
When the client is doing a big share of the work, the estimate isn't really about sizing a full build. It's about drawing clear lines. The exercise becomes a detailed conversation about who owns what, where our work starts and stops, and exactly which gaps you want us to fill.
Done well, that gives everyone a document that answers questions before they become disputes:
- Which configuration and data work your internal team owns
- Which decisions you want reviewed before you commit to them
- What you can escalate to us and how quickly you'll get an answer
- Which specialty items (integrations, tricky workflows, industry-specific needs) we handle end to end
- How the relationship continues after go-live for changes and new requirements
The failure mode of a shared engagement is fuzzy boundaries: both sides assume the other owns a task, and it falls through the cracks near go-live. Nail the responsibility split in writing before work starts.
Advice work needs business fluency, not just developers
There's a reason this client's first experience felt thin on guidance. They said their implementers were technologists first, capable of writing code but light on understanding the business and steering them away from choices that would break later. That's the gap an advisory engagement has to fill.
On a Dynamics or Business Central project, the person you most need in these conversations is someone who can take a business need, translate it into a sound configuration, and push back when "you can, but you shouldn't" is the right answer. On our team that lead usually comes from an accounting or controller background and moved into systems work, precisely so those downstream-impact conversations happen up front.
Keeping support to one phone number
This company had also been burned by finger-pointing between a platform vendor and a third-party integrator, each blaming the other when something broke. That's worth planning around. Business Central covers general ERP needs, and some manufacturing-specific features come from independent software vendors (ISVs, third parties Microsoft maintains close partnerships with). Using an ISV is fine. What matters is scoping support so you call one team, and that team deals with the ISV on your behalf instead of sending you off to chase it.
If you've already got capable people in-house and you mostly want a knowledgeable partner on call for the hard parts and the strategic calls, that's a real engagement model, not a consolation prize. We're glad to talk through where the lines should sit for your situation.