Ep. 23: When to Integrate CAD & PLM with ERP: Getting the Foundations Right in Manufacturing

Where Should You Integrate CAD, PDM, and PLM with Your ERP? (Episode 23)
The Integrate Intelligently Podcast, Episode 23 — with Jeff Bickler and Scott Bickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, again joined by my brother, CEO and founder of CADTALK, Scott Bickler. This is episode 23 — we're officially among the elite few who've made it past 22 episodes. Today's title: Where Should We Integrate CAD, PDM, and PLM with the ERP? Should we start with a new ERP system, or wait for phase two? Scott, this comes up a lot, especially with our partners when we're selling alongside a new ERP implementation. Before we get into it, what's your take — what are some common misconceptions people have here? Since you were the first to build something like this, you didn't have the benefit of it existing during your own ERP implementation, so you could really only tailor around what you needed at the time. What's your read on this?

Setting Up the Two Scenarios: Phase One vs. Phase Two
Scott: It's an interesting topic. Obviously we could be a little self-serving here and just say "earlier is always better" — which, sure, is generally what we'd advise — but I think there are really two things at play. We were actually talking about this with Kevin on a recent episode: people tend to take on too much during an ERP implementation. Their eyes get bigger than their stomach, so to speak — they load up the scope of the project, and inevitably end up cutting features just to get something live. So I understand the instinct some people have that CADTALK, or any CAD integration, feels like a "nice to have" — something that streamlines things, sure, but you can still do it manually without it. It's not like scheduling, where you genuinely need a lot of other pieces in place before you can even attempt it — Kevin made the point that everyone wants to jump straight to scheduling because that's where all the visible benefit seems to be.

But I'd actually flip that argument around and make the case for why CAD integration isn't really in that same "nice to have" category.

Jeff: That's a good point — yes, maybe it's an extra thing to learn and implement, but what's the actual downside of waiting?

Scott: It really comes down to — let's back up for a second, since there are two scenarios we typically see when people are considering integration, whether it's CADTALK or otherwise. Integration tends to happen at one of two points: either (a) when you're implementing a brand-new ERP — a perfect opportunity to finally integrate things you've never connected before — or (b) after the fact, either once the ERP implementation itself wraps up, or pushed to a phase two or three down the road. The point of this conversation is really to explain why the two of us, and honestly most people who've actually run these projects, tend to advocate for the former over the latter — doing it right at the start of a new ERP project.

Jeff: Just wanted to make sure that framing was clear before we dig in — so, two scenarios: integrate during the initial ERP rollout, or kick that can down the road to phase two or three.

Why Foundational Data Belongs in Phase One
Scott: I think the fundamental distinction is this: I'd actually argue some things genuinely aren't worth doing on day one — some integrations, some advanced ERP capabilities are fine to defer on your first pass. But anything that directly affects the quality of your core data is something I wouldn't want to defer, because every single day you're not putting good data in, you're getting less value out of the system you just implemented. CADTALK is exactly that kind of tool — if we can automate getting engineering data into the ERP, which is the foundation everything else in the system depends on — scheduling, MRP, all the flashier tools — that's foundational data. Using a house analogy: if you get the foundation right from day one, everything you build on top of it comes out straighter and more square. If you wait, you can still go back and fix the foundation later, but it's much harder. If you didn't do it during the initial implementation, the next best time is right after — as close to day one as possible.

There are really two reasons I feel that strongly about it. One is getting that data foundation right from the start. The other is that the tooling you have available actually shapes the decisions you make. We're humans — we've evolved specifically to build and use tools — and what I've noticed repeatedly in ERP implementations is that once people buy a system, the way that system actually works starts to guide how they use it, sometimes in ways that compromise the bigger goal.

A classic example I've seen: people manipulating bills of material specifically to reduce the number of shop-floor jobs, because closing out jobs is a lot of manual work. But the entire point of having more granular jobs is to get more granular costing data — more information to actually run the ERP effectively. So you end up optimizing for the wrong thing: making job-closing easier, at the cost of the very data the ERP depends on to function well. People would push back on me about this, but that's genuinely what's happening — a micro-optimization at the expense of the bigger picture. If closing jobs had been easy in the first place — thanks to better tooling — you'd never have made that trade-off, and the planning and scheduling downstream would have worked far better. That's what I mean by tooling shaping decisions: introduce the right tool early, and it removes that friction point, which naturally leads to better decisions overall.

Jeff: Right, and you also end up making assumptions. Whenever you don't have a tool in place yet, and you don't fully understand how it works or the best practices baked into it, you tend to make decisions about how you set up the ERP assuming "we'll deal with that later, some other way" — without really understanding what you're committing to. You don't know what you don't know. That early decision about how to structure your system might not actually work well with the tooling you plan to bring in down the road — you might end up unwinding a bunch of earlier setup work, or you end up hamstringing the new tool's actual capabilities because of assumptions baked in earlier that just weren't good ones. And remember — when you buy a tool, you're not just buying the software, you're buying the expertise of the people who've run a hundred projects, talked to thousands of customers about how they do engineering, what the best transformation approach looks like, and what genuine success typically looks like. IT projects carry real failure risk — you want to follow guidance that's actually proven to work over time, not go off and improvise your own approach and later discover none of your assumptions held up.

Why Some Integrations Can Wait: The Nesting Example
Scott: It really comes down to how directly, and how early, an integration touches your core data. I don't want to disparage other integration types — take nesting integration, for example, which is one of the other tools we offer. This actually came up in a call today — a customer was weighing CADTALK's CAD-to-ERP integration against a nesting integration, connecting laser or CNC nesting software to the ERP, and considering both. Our take: CADTALK makes more sense first, because it sits at the front end of the process, where data quality originates — which is exactly what we discussed with Kevin. Nesting integration sits more toward the back end — you're optimizing material usage, getting cleaner transactions, better inventory accuracy. In my mind, that's a much more natural phase-two or phase-three project than something you need in phase one, because it's just not sitting at the front of the pipeline. Am I off base there?

Jeff: No, that's actually a great analogy — and it makes us look less biased, honestly, since nesting is one of our own products too. I remember actually building the original nesting integration solution myself, back around 2003, when I was still working in manufacturing. That was very much a phase-two project for us — something we tackled years after the ERP itself was already live. It was a genuine optimization over a more cumbersome manual process, and you could argue the data got better as a result — but the systemic ripple effect of that improvement was nowhere near what you get from fixing bill-of-material data. Improving material-utilization accuracy or costing accuracy makes the system run better, but it isn't foundational the way bills of material are — bills of material drive essentially everything downstream. It's more of a vitamin than medicine. In software, we talk about this the same way — you want to be building medicine, not just vitamins. Vitamins are genuinely good, plenty of great products are vitamins, and everyone probably should take theirs — but medicine is a must-have, vitamins are a should-have. I still consider myself one of the people who helped invent our nesting integration, and it's still a genuinely great thing to implement, and it does improve your data — but it's a vitamin. You can absolutely phase that in later. I wouldn't say the same about CAD integration, given how critical and pervasive that data is throughout the whole system.

Scott: I'd add two more things to that. First — it makes no sense to me to buy a brand-new car and then pile all the junk from your old car straight into it.

Jeff: That's a good point.

Scott: You're buying a new, shiny system — and part of the reason your old system underperformed might be aging technology, but it's often just as much about manual processes, missing integrations, less desirable tooling in general. So here you are, buying a brand-new system with all the modern capabilities, companion software like ours, AI-driven engines, everything tied together — and then choosing to keep manually keying in data by hand, when you have a far better source available. That never made sense to me — it felt exactly like piling trash into a brand-new system. When I bought a new car this year — actually, I ended up buying two, since my first one got stolen — for a while I kept my kids out of it, because I didn't want to trash it right away. Same idea: when you get that new system, you want to set it up so the way data gets in there is as clean and valuable as possible from day one. Data is genuinely the asset — we've said this before — the better your data, the better the whole system performs. If you want to leverage AI down the road, it all comes back to data quality — the better the data, the better the responses, the better the analysis. If you're hand-keying everything, you can still get pretty good data, sure, but you've given up all the efficiency gains, and now you're spending significant ongoing labor just to keep the data accurate.

Jeff: That connects to something we've talked about before — accuracy versus consistency. It's genuinely better to be consistently wrong than sporadically right when it comes to data, because consistent data is much easier to adjust and correct for. And the nice thing about integration is that it tends to produce consistently reliable, structured data, which you can actually plan and build on. That driver is foundational — same idea as your nesting analogy: nesting improves data quality, but at a point that's more downstream. Whereas items, bills of material, vendors — that's literally the basis of MRP, material resource planning, which is the actual core of what an ERP is. Everything else is really just MRP with accounting layered on top. Without correct items, bills of material, vendors, and routings, you genuinely can't do much of anything meaningful with the system. So anything that makes that specific data more accurate — or more consistent — deserves to be prioritized early.

Why Data Consistency Outweighs Even Labor Savings
Scott: We've had this conversation before too — what's the real value of an integration? Time savings is always the first answer people give, and labor savings genuinely matters — but I think the real center of gravity is shifting toward that consistent data itself. Consistent data is actually more valuable long-term than the labor savings alone. Don't get me wrong, the labor savings are significant — but we shouldn't underestimate how much that clean, consistent data pays off over time, especially as these systems get smarter. As AI becomes more embedded in ERP tooling, the quality of your underlying data becomes an even bigger competitive advantage.

Jeff: Right, and because that data gets used so pervasively throughout the ERP, it makes sense to prioritize it earlier. With nesting, the benefits are real but more localized — you're speeding up the transfer of job requirements to a laser or profile-cutting machine, passing raw material data over automatically instead of manually keying in part counts, and you're improving costing by properly allocating material and labor across the parts cut from a given sheet. Real benefits, genuinely improved data entry speed and labor savings — and you do get somewhat better costing information than before. But the leverage of that improvement is nowhere near the leverage you get from correct bill-of-material data. Leverage is really the question — how much value do you get back per unit of effort? Fix your bill of material, and it ripples through scheduling, MRP, essentially every corner of the ERP. Fix costing on a specific raw material or a handful of parts, and yes, you get a better picture there — but it doesn't have anywhere near the same organization-wide leverage that correct bills of material provide.

Scott: Exactly right. And there are other kinds of integrations too, depending on company size — especially now, with so much consolidation happening. I actually didn't take this call myself, but some of our team did today — a company that owns roughly 60 other companies, each running its own ERP, maybe 30 different systems total, all being consolidated down to just a handful. Getting the underlying data and processes right becomes critical in that kind of scenario, or the whole consolidation effort becomes exponentially harder.

Jeff: Absolutely. I understand the instinct consultants have to try to simplify a project scope — it ties back to what we discussed with Kevin, taking on too much at once during implementation. But you really have to identify where the highest-leverage points actually are. If you could only focus on a handful of things, what would give you the biggest return on that time and effort? That's exactly why we advocate so strongly for foundational data — your GL structure, your chart of accounts, vendor cross-referencing, the base data that everything else in the ERP depends on. Getting that right is genuinely the highest-leverage thing you can do. If an integration helps you get that foundational data right, prioritize it early — and there are absolutely other integrations that support that same foundational goal too. Anything touching that foundational layer pays outsized dividends.

How to Approach Scope for a New ERP Integration Project
Jeff: So it sounds like our overall framework really comes down to one question: is this foundational to how the ERP actually functions? If it's foundational to data quality and consistency, do it as early as you possibly can. If it's more of an optimization — like scheduling, or something dependent on data that first needs to be reliably in place — that can reasonably wait. But given that, if someone's about to implement a new ERP, how do they actually know what to prioritize, without overreaching and choking on scope the way we discussed earlier — and losing the value of both CADTALK and the ERP itself in the process? What would you recommend as an approach to that initial integration project?

Scott: Typically when someone buys an ERP, or any software really, they're trying to solve a specific problem — but what happens is they start with one clear problem in mind, then get distracted by all the bells and whistles they see during demos, and end up wanting things they didn't even know they needed. It's a lot like shopping — you go in for pants and walk out with shoes and socks too. So before you even start shopping, write down the actual problem you're trying to solve, and really understand it deeply. Say it's scheduling — a genuinely common pain point for manufacturers: "I can't figure out when I'm actually going to deliver this thing." That's a hard, complex problem with a lot of variables. To solve it, an ERP has to know what you're making, where the components come from, what steps are required to build it, how long each step takes, where you're sourcing materials — all of that has to be known and correct before it can feed into an algorithm that generates a usable schedule across your whole organization.

If you think about it that way, solving that one visible problem actually depends on roughly a hundred smaller problems being solved correctly first — and a small inaccuracy anywhere in that chain is systemic; it propagates all the way down and makes the resulting schedule less useful. So I always start with the primary problem I'm actually trying to solve, and work backward to identify everything that has to be correct or in place to make that outcome achievable — then make sure those prerequisites are genuinely solid. That's why we keep coming back to bills of material and item data specifically — that's foundational to most of the benefits people actually want from an ERP, scheduling being just one of them. Though context matters — if you're a distribution center doing light manufacturing, my advice might be completely different; you might genuinely prioritize warehouse management optimization over perfecting your bills of material, since they're a smaller part of your operation. But for a traditional manufacturer — job shops, companies that actually build things — bills of material being critical is usually the pattern we see, and materials planning is often the number one reason people buy an ERP in the first place.

Jeff: We shouldn't leave out that we also integrate with cloud-based PLM systems, which function similarly to an ERP in some respects. The same logic applies — the common use case people describe for cloud-based PLM is that it's meant to be the "single source of truth," the master data hub. Fine framing — but if engineering data is genuinely the most critical piece of what you're housing in that PLM system, and you're still planning to manually key that data in by hand, something doesn't add up. There's a real disconnect in spending hundreds of thousands, sometimes millions of dollars on a system, and then cutting corners — or pushing off — exactly how the most important data actually gets into it. It's like buying a Ferrari and then filling it with the cheapest, lowest-grade gas you can find.

Focus on Fundamentals First, Optimize Later
Scott: That actually reminds me of something more personal — I recently lost about 65 pounds, and for years people would ask how I did it. Honestly, it came down to following the fundamentals: eat less, move more, consistently — things I'd avoided actually committing to for years, while constantly chasing fancy widgets or specialty tools instead, because that stuff was more fun. I tried bulletproof coffee, every trendy hack imaginable — dabbling around the periphery of the actual problem because the periphery is more interesting to look at, more exciting than the boring, hard part: actually counting calories, doing consistent work day in and day out. That consistency is what actually drives results. Once that foundation is solid, then optimizing for something like a marathon starts to genuinely make sense — but everyone wants to skip straight to the marathon, because it looks exciting. If you're still 300 pounds trying to run a marathon, you're going to have real problems. Get the fundamentals first — calories, consistent movement, get the weight trending down — and then you can start optimizing the smaller things.

I'd apply that exact same analogy to ERP implementations, and honestly a lot of things in life. I think this connects to a conversation we may have had with Steve too — these projects really do reflect life in general: focus on fundamentals, focus on foundational work, and do that really well, repeatedly.

Jeff: And if you do that well and consistently, you build real capability and consistency — which, again, we keep circling back to with data specifically, at least from a CADTALK standpoint — that consistency in the underlying process makes everything downstream easier. Everything else is more like seasoning — the 80/20 rule — you sprinkle that on afterward. You can add all the extra capability later, but until the basics are solid, you're majoring in the minors. I say that phrase a lot — people get pulled toward "what about this thing over here," and honestly, none of that matters yet. It feels important because it's easier to focus on, but it genuinely isn't the priority yet.

Scott: Exactly your point — focus on fundamentals, execute them really well, and don't stop there — once the fundamentals are solid, then you layer on more, add the seasoning, chase that last 20%.

Jeff: Consistency drives efficiency — I love that framing, because it's genuinely true. You move so much faster, and accomplish so much more, just by being consistent and nailing the fundamentals first, like you said.

Scott: That's exactly why we frame integration the way we do — bring it back to the fundamentals of an ERP implementation, since the core data is what everything else is built on. Get those fundamentals right first.

A Real-World Example: Building on the Fundamentals Over Time
Jeff: One of the last projects I personally ran start to finish, before joining CADTALK full time, was actually with PLM and a different ERP, for a company doing water filtration and reverse osmosis treatment systems. I helped them get their engineering data cleanly into their ERP — built a repeatable, consistent process that took the data they'd cleaned up in their PLM system and moved it through testing into go-live, then set up automation to handle the ongoing transfer from PLM into the ERP.

That customer has now been with us for something like three or four years, and we've kept working together, continuously enhancing the process, making it more streamlined. It was never a "solve it all in one shot" effort — we got the data flowing cleanly with CADTALK, got the core process working, and then just kept improving it, iteration after iteration. To this day, I genuinely think of them as a pioneer in this space — though I don't think they even realize it themselves — because they move so much faster than any other manufacturing company I've worked with. They're releasing new products constantly, and there's a huge amount happening behind the scenes that most people never see. None of that happened overnight — in fact, when we actually went live, the initial integration was pretty basic, because we'd spent so much of our early effort testing and cleaning the data itself. But over the following months and years, we kept refining the process, kept improving the integration, and it just kept compounding, getting better and better because we focused first on the fundamentals — a process that reliably delivered clean, usable data — and built a real system for continuous improvement on top of that.

Scott: Absolutely — those two ideas, nail the fundamentals first, and have a real process for continuous improvement afterward, are the whole thing. It's not a big-bang rollout, it's ongoing refinement — refine, refine, refine. Approach it that way, and most implementations go pretty smoothly. It's when people get overly aggressive, or start majoring in the minors like you said, that things go sideways — focus gets split, effort gets diluted, people burn out and give up, and then you hear "I don't know why anyone does this, it's just too much work, this stuff doesn't work for us." Usually it's really just that the process never got the consistency, or the fundamentals, it actually needed.

Jeff: There's a lot of truth in that — these projects reflect the people running them, like we discussed with Steve. Continuous improvement, small wins compounding over time, consistently beats trying to do everything at once. Get the fundamentals right during implementation, get it live, start capturing real value and usage, and then keep pushing incrementally — keep improving, keep pushing. Do that consistently, and before long you'll have a system that's genuinely delivering the value you set out for, whether that's CADTALK, the ERP itself, or any software system.

Scott: Very well said.

Even If You Wait, It's Not Too Late
Jeff: This has been a genuinely great conversation — I feel strongly about this, honestly, because I've done plenty of demos where customers say "we'll handle that in phase two," and sure, that does happen sometimes. But I firmly believe that leveraging this on the front end — getting a solid process in place while you're already deep in change management anyway — is the right time to think through how you'll get data in cleanly, how you'll keep it consistent, and how you'll train staff on the new process once, rather than retraining them a year later when you finally get around to it. Keeping scope tight so you can actually get real wins is genuinely the best approach for most customers.

That said — even if you choose not to do this alongside a brand-new ERP rollout, and instead push it to a later phase, all is not lost. There's still real value available to you. You might miss some opportunities, and it might cost a bit more — additional configuration, more complex rule sets to retrofit around decisions already baked into the system — but in my experience, you can almost always still make it work within the existing process. The best time to do it is whenever you're actually able to — if that's alongside a new ERP, great, do it then. If it ends up being a little later in the project, or right after go-live, that window still works, and it's still genuinely valuable.

Scott: It's a bit like investing — the best time to start was ten years ago, the second-best time is right now.

Jeff: Exactly — the best time to implement is now; the next-best time is whenever you actually start.

Scott: It doesn't have to feel overwhelming, either. It's better to get something in place and get it consistent right out of the gate, even if you're not turning on every single CADTALK feature immediately. That's actually another common trap — people finally get integration in place and then try to flip on every bell and whistle at once, which is really just the same big-bang mistake in a different form. It's better, especially for anything foundational, to get it implemented — even a scaled-back version — and improve it over time, rather than deciding "we're not doing any of it now, we'll do the whole thing properly later." Waiting entirely still works eventually, it's just less ideal, because you lose the power of momentum. Once something's live and you're just making incremental improvements, you're building on existing momentum — versus starting cold and having to ramp everything back up from scratch. Inertia is a real, practical advantage.

Jeff: Absolutely. This was a genuinely great conversation, and I feel passionate about it, because I want our customers to actually succeed with their projects and their broader company goals. You and I are both living this daily — working to improve CADTALK, improve our relationships with customers, and helping them in turn improve their own relationships with their customers. It matters to me.

Closing Thoughts
Jeff: So, Scott, in closing — I'd encourage everyone to keep subscribing to the CADTALK podcast, and share it with anyone in manufacturing, ERP, or engineering who'd find this useful. Leave a comment if you've got new topic ideas or questions you'd like us to dig into — we'd love to hear them. Scott, it's getting late — anything else before we wrap up?

Scott: No, I think that covers it — thanks, everybody.

Jeff: Alright, till next time.

Scott: Till next time.