A supply chain director at a scientific instrument manufacturer walked us through his situation recently. He'd been hired specifically to bring in the company's first ERP. Thirty people, engineer-to-order work, everything highly configurable, and no ERP at all today. Purchase orders come out of a basic online tool, the CRM is half Salesforce and half OneNote, and finances sit in QuickBooks. The interesting part wasn't the tool sprawl, though. It was that he already knew he couldn't start the ERP yet.
The reason: the company had a product data management (PDM) implementation kicking off first, and the ERP's part-number master and bills of materials all need to come out of that PDM. His words were direct: he didn't want bad data on day one. That's the right instinct, and it's worth explaining why.
What a PDM owns and why the ERP waits on it
In an engineer-to-order shop, the engineering system (in this case a SOLIDWORKS-based PDM) is where part numbers get created, drawings get revised, and revisions get released. That's the source of truth for what a part is and what goes into a product. The ERP is where you buy, build, cost, and ship those parts. If the two disagree on part numbers or BOM structure, your ERP inherits the disagreement.
He described the current pain clearly: engineers change something, there's no official revision release the whole company sees, purchasing orders against a stale spreadsheet, and duplicate part numbers pile up because a couple of people can edit that spreadsheet freely. If you stand up an ERP on top of that mess, you don't fix it, you just move it into a more expensive system.
The system that creates and releases part numbers should be stable before the system that transacts against them goes live. Get the part master and BOMs clean in the PDM first, then let the ERP pull from a known-good source.
Why not run both at once
There's a technical answer and a human answer. Technically, the ERP's item setup and BOMs depend on data the PDM hasn't finished producing, so running them in parallel means building your ERP on a moving target. The human answer is just as important. He put it plainly: he didn't want to run two implementations at the same time, because people can only absorb so much change.
We agree. We're not a rip-it-all-out-at-once shop. An ERP go-live already asks for a real chunk of your team's time, not just ours. Stacking a second system change on top of that is how go-lives go sideways and how the team quietly decides the new tools aren't worth the trouble.
A sequence that gives you room
Here's how this kind of timeline can lay out without anyone feeling rushed:
- Run the ERP evaluation now (platform fit and partner fit), while the PDM implementation is getting off the ground. Evaluating costs you nothing but time and can proceed in parallel.
- Land on a platform, scope, and budget, then let that decision sit rather than kicking off immediately.
- Let the PDM finish and stabilize so the part master and BOMs are clean and released.
- Kick off the ERP implementation once the PDM is the source of truth.
In his case the PDM is expected to wrap around year-end or early the following quarter, and Q4 is the company's busiest stretch. That actually leaves plenty of runway: evaluate carefully now, decide, wait for the PDM, then implement in a quieter window with everything wrapped up well before the busy season. Evaluating early doesn't force an early start. It just means you're ready to move the moment the data is.
The other thing that has to come with the ERP
He named a second problem worth flagging: too many hats, not enough heads, and nobody sure whose job ends where. Things get ordered twice, and the owner never sees a purchase get approved. A foundation of clean data solves half of that. Approval workflows solve the other half, routing the transactions that need a second set of eyes to the right person automatically. Business Central handles that natively, and it's one of the first things worth turning on once the data underneath it is trustworthy.
If you're staring at the same sequencing question
If you're bringing in your first ERP and there's an engineering or PDM system feeding it, the order of operations is a real decision, not a detail. We're happy to talk through how your part master, BOMs, and go-live timing should line up, and where an ERP evaluation can run in parallel without committing you to anything. No rush on our end.