Ep. 19: Why Getting Your CAD and ERP to “Talk” is Better than a CAD Link

Getting Your CAD and ERP Talking — Not Just Linking (Episode 19)
The Integrate Intelligently Podcast, Episode 19 — with Jeff Bickler and Scott Bickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm Jeff Bickler, your host, along with my brother, Scott Bickler, CADTALK's CEO and founder. It's been a bit — we're back in the office for another educational conversation about CAD integration, ERP, and PLM. This is a special one, episode 19: Getting Your CAD and ERP Talking, Not Linking. We're digging into the real difference between the idea of CADTALK — systems genuinely "talking" to each other — versus simply linking two things together. Kind of a niche topic, but it's our own personal nerd territory, so I'm excited. Quick reminder for context: we're talking about CAD, PDM, and PLM systems — engineering-based systems — connected to ERP and PLM systems for manufacturing companies. Integration matters because it speeds up processes, improves consistency, and we know consistency is the foundation for improvement. Getting these systems talking makes that possible. Scott, how's it going — just past election day, we were out of town last week.

Scott: Things are great — been a fun couple of weeks, did some traveling, got to attend the SaaStr event we mentioned on the last episode, and there's some exciting stuff coming up too. Really looking forward to this topic specifically, because it's a genuine deep dive — I think that format works well for us. A lot of customers, prospects, or just people generally interested in this space want to actually understand the idiosyncrasies and the deep mechanics of how this works, and I'm excited to get into the weeds on it.

Jeff: I've noticed that our more technical episodes — what is CAD, what is PDM, what is PLM — tend to get better audience engagement. So let's really get into the niche details here. Having been a teacher, I love educating people on this, especially something you've been working on in some form since the late '90s, and I've been involved with for close to a decade now.

The Evolution of CADTALK: From Linking to Transformation
Jeff: Scott, take us back to when you first came up with this idea — what were your original thoughts around "linking" your CAD system to everything else?

Scott: Linking is actually the most intuitive way to think about this problem — genuinely the natural first instinct, especially for an engineer. You think: I created this design, now I need to get it into another system to actually manufacture it, and I want any changes I make to persist across systems — form, fit, function, description, whatever changes, I want that synchronized all the way down the chain. That leads naturally to this idea of a single "master data" concept — one owner of the truth. It's intuitive, and it makes a lot of sense on the surface: it's the same underlying data, so why not just link the systems together directly?

The very first version of CADTALK actually worked that way — version one, version two had this shared-common-data concept, where fields like description or part number in the CAD or PLM system were directly tied to the same fields in the ERP, and changing one was meant to change the other. Made a lot of sense on paper. But by the third iteration, once I looked at the problem more closely, it turned out to be a lot more subtle than that — it really wasn't linking at all, it was more like a transformation, almost a derivation.

The better way to think about it, and how we approach it today: engineering or CAD data is the base, and the manufacturing or ERP data is a derivation of that base — not a mirror of it. It's less "move this data from here to here and tie them together," and more "take this source data and transform it into something else." Trying to link them directly is a bit like treating apples and oranges as the same thing — they're just not. A better analogy might be apples and applesauce: applesauce is made from apples, but it's not just apples — there's cinnamon, sweetener, other ingredients folded in.

Jeff: Good applesauce, anyway.

Scott: Exactly — a little maple syrup, something good. Same idea with engineering data versus ERP data. Linking becomes genuinely restrictive in that world. Take the classic example everyone gravitates toward: description. Everyone wants description and part number to link cleanly. Sure, in theory — but say in SolidWorks, the description field can be essentially unlimited in length. In your ERP or PLM, there's often a hard field-length restriction. So what happens if your SolidWorks description is 100 characters, and your ERP field caps at 50? By definition, they literally can't match.

If you're strictly linking, you're forced to constrain to the lowest common denominator — truncate the SolidWorks description down to 50 characters just to keep them synced. But what if instead you added a second, extended-description field in the ERP? If you're purely linking, now you also need that extended field mirrored back in SolidWorks just to keep everything tied together. But if you're thinking in terms of transformation — systems genuinely talking to each other, which is where the product name comes from — you can take that single field in CAD and transform it into two separate fields in the ERP. Same underlying data, but split intelligently into two destinations, because you're dealing with two genuinely different things — the apple and the applesauce — rather than forcing both sides to just be "apples" so they sync cleanly.

Description is actually one of the few cases where you might legitimately want a direct sync — that's a valid decision to make. But once you go beyond that, there's a lot of other data that can be derived from engineering without needing to be stored there at all — routing information, vendor data, things that are implicit in the design logic but don't need to physically live inside the CAD file. That data is often better suited to live entirely on the ERP side. Transformation lets you take that "genesis" of data and apply rules to derive something new from it, rather than storing duplicate copies in both places. Linking assumes the data is identical on both sides; transformation lets you derive the destination data from the source, so you're never trying to keep two separate copies perfectly synchronized — you're just regenerating it from the source each time.

Take routing as an example: if I can look at the geometric features of a design and determine it needs to go to a laser, then get deburred, then go through a press brake — I can derive that routing directly from the design features. Do I need to manually embed literal routing steps inside the CAD model to make that work through linking? Yes, if you're linking. Through talking, I don't — I derive it directly from features that are already inherently part of the design. If the design changes, those features change, and the derivation updates automatically — instead of maintaining duplicate routing data in two separate places by hand. Fundamentally different way of approaching the same problem. Does that track?

Venn Diagrams and Data Overlap
Jeff: Completely — and I explain this a couple of different ways, given our different backgrounds; you're deeply engineering-centric, I came from teaching. One way I put it to customers: picture two Venn diagram circles, one for each system's data set. There's real overlap in the middle — some data genuinely exists in both, like part number, maybe description — but there's also a lot on each side that doesn't overlap at all, with no one-to-one equivalent. And even the "overlap" isn't always as clean as people assume — sometimes you're dealing with multiple languages, added complexity, or combining several CAD fields into a single ERP description. Even quantities, which people assume overlap cleanly, don't always — you might have phantom parts, or handle quantity differently on the ERP side entirely.

Linking assumes one big overlapping circle — like two CRMs where one calls something "customers" and the other "clients," but functionally it's the exact same concept: first name, last name, street address, apartment number — same data, same underlying language. Coming from a language background, I think of it the way English and Italian share loanwords but aren't remotely the same language — knowing "gelato," "tiramisu," and "pizza" doesn't make you fluent.

Scott: Right — and linking can genuinely restrict flexibility. We see this constantly with customers during implementation: "what data do I need to add into my CAD model to make this integration work?" — because they're already assuming that Venn-diagram overlap has to be total, that anything needed on the ERP side must also exist in CAD. That's actually not true unless you're strictly linking. It kind of blows people's minds sometimes — "is there real value in storing that data here in CAD?" "No." "Can I derive what that value should be on the ERP side from what's already here?" "Yes." "Then why add anything extra at all?" That question alone massively simplifies things, because you're only storing the data each system actually needs for its own role.

People always ask "who's the master of the data?" — and honestly, it depends entirely on what the data is. If it's design data, CAD is the master. If it's manufacturing data, the ERP is the master. There isn't one universal owner — ownership shifts depending on the specific field.

Jeff: We touched on this master-data concept in a previous episode too — it really does depend on the data. Vendor lists, approved suppliers, raw-material options — those often genuinely belong on the ERP or PLM side, and that's the authoritative master list. But which specific material grade to use — 304 stainless versus something else — or the actual tolerances on a part, that's fundamentally an engineering decision, and engineering owns that data. There's no single universal master — it depends entirely on which piece of data you're talking about.

Scott: Right, and that Venn-diagram framing, or thinking of it as a derivation pipeline — data originates here, flows into this, derives into that — helps explain why a change upstream ripples predictably downstream. We ask customers a lot of pointed questions here: "if I change the description in the ERP, should it flow back and change it in CAD, or back to the true source?" First — if that data doesn't actually live in the source because it's not relevant there, then no, there's nothing to flow back to. But if it is relevant and does live there, you want to start at the actual source, not at the endpoint.

If description genuinely matters — and I'll take a bit of a stand here, this tends to get people fired up — changing it is, technically, an engineering change. You're altering something about the design. If it doesn't actually matter to engineering, then why would you need it flowing back there at all? Whichever side actually owns that piece of data is where the change should originate. If it matters to engineering, that's a conscious engineering decision that then flows forward through the process into manufacturing. If it only matters to manufacturing and engineering genuinely doesn't care, don't bother storing it upstream in the first place. Description tends to be the one field that generates real debate — work centers or other purely manufacturing-side data, nobody argues about that. Description is the one everyone circles back to. Part number comes up too, but it's usually less politically charged than description.

Jeff: I've run implementations where the engineering number and the ERP number were intentionally different — CAD-1234 becomes ERP-1234, just enough differentiation to avoid any possible numbering clash. Totally legitimate transformation, and I've built that exact pattern before. But you're right, description is the one people get most attached to — "these absolutely have to match exactly." And then the real question surfaces: what happens if someone downstream in manufacturing edits that description — does the engineer's next revision just silently overwrite their change? That's exactly where transformation logic shines — you get to explicitly decide whether that's allowed. Maybe the engineer's original description is just a starting placeholder, manufacturing or document control enriches it downstream, and on the next revision, the rule says: leave the enhanced description alone, don't overwrite it.

Scott: Right — and I think the underlying anxiety around description specifically comes from something like: "I generate a paper drawing, and the description on that drawing has to match what prints on the traveler coming out of the ERP." Fair concern — but walk through what actually happens if it doesn't match exactly. If the part number is ERP-1234 on both the drawing and the traveler, and one says "bracket," the other says "flange bracket" — does that genuinely break anything? No. But if one says "bolt" and the other says "flange" — that's a real red flag, but it's a sign the part number itself got reused incorrectly, which is a completely different underlying problem. Synchronizing or linking the description field wouldn't fix that root cause at all — it's a bigger issue hiding underneath.

I'd be curious what people say in the comments on this one, honestly — this is a spot where we're taking a genuine stance, and maybe we'll learn something new after 20 years in this. Possible. But the real underlying fear usually traces back to a pre-digital mindset — descriptions used to be how people physically located and identified things before databases and structured part numbers existed. Descriptions still matter, but not the way they used to. The only thing that genuinely has to be reliable is having some unchanging way to identify: is this thing I'm working with new, or does it already exist? That's what a part number does — reliably, consistently. A description is inherently subjective and unreliable for that purpose — "flange" versus "bolt" is a judgment call, but part number 1234 is always, unambiguously, 1234. That's the one thing that has to stay consistent — everything else can be legitimately transformed.

I know this can sound like a strong personal opinion, and it is — we have real opinions about how this should work, informed by pattern-matching across hundreds, thousands of customer implementations over the years. Our opinion might not fit every single use case, and that's fine — CADTALK is flexible enough to accommodate a lot of different philosophies. But in our broad experience, this approach tends to work best and gives manufacturers the most usable flexibility, compared to more rigid, strictly-linked alternatives we've seen elsewhere.

The Importance of Data Transformation
Jeff: That connects back to my language analogy — when you're integrating systems, each one has genuinely different data needs: what engineering needs versus what manufacturing needs, versus what PLM needs. You need something intelligent enough to figure out what's actually required on each side — simply copying data verbatim from one place to another often isn't the right solution, because you still end up needing manual cleanup or reformatting on the receiving end.

Sticking with the language analogy — think about idioms. "Six of one, half a dozen of the other" translated literally into Italian would mean nothing to an Italian speaker. But someone who genuinely speaks both languages fluently — who can actually talk across both — would translate the underlying idea, using the equivalent Italian idiom instead of a literal word-for-word translation.

Scott: Exactly right — that's true flexibility. Italian has its own version of "break a leg" — something like "in bocca al lupo," literally "in the mouth of the wolf," meaning good luck. Every language has its own idioms for conveying the same underlying intent, and engineering-to-manufacturing data works the same way — you're trying to convey the same underlying intent, but expressed correctly in the "language" of the destination system.

Jeff: That's exactly where linking boxes you in over time.

Scott: Right — linking made one narrow thing easier: bidirectionally syncing something like description back and forth. But it solved that small, specific problem while creating a lot of bigger ones by sacrificing flexibility elsewhere. Our overall philosophy has always leaned toward more flexibility — treating one system's data as a derivation of the other, rather than assuming they're the same data wearing two hats. The whole reason you have two separate systems in the first place is that they serve fundamentally different roles in the organization — if they held truly identical data serving identical purposes, you wouldn't need two systems at all.

Jeff: Right — different use cases, different needs, different "languages," essentially. I told someone earlier today: sharing a word doesn't mean you speak the language. Knowing how to say "cappuccino" doesn't make you fluent in Italian. Knowing "pizza" doesn't make you Italian. Having a Latin phrase tattooed on your arm doesn't make you fluent in Latin, or a Spartan, however popular that particular phrase has gotten lately.

Navigating Complex Data Structures
Jeff: I've run plenty of projects where this "talking" philosophy solved real problems that strict linking simply couldn't. What are some concrete, real-world examples you've seen where transformation solved something linking genuinely couldn't handle?

Scott: A great one is just fundamental differences in how each system structures the same conceptual data. Raw material is a perfect example. In CAD, raw material is essentially a property — an attribute of a part. "This part happens to be made of mild steel." In the ERP world, raw material is often actually a subcomponent — a separate line item entirely: you take a raw material, apply an operation to it, and produce a new part number. Part 1234 becomes part 4567 once a laser operation is applied to it. What's essentially an attribute at the CAD level becomes a distinct subcomponent record at the ERP level. How would you even "link" those directly? One's a property tag on the part record; the other is a completely separate item at a different structural level, with its own quantity field that doesn't exist as a discrete concept in CAD at all — instead it's implicitly derived from a dimension in the model, like square inches of material consumed.

No matter how you slice it, there's an inherent structural transformation happening — even if the underlying data itself is conceptually identical, the way each system structures it is fundamentally different, so a transformation is required regardless. That flexibility to take what's conceptually a property in one system and turn it into a full subcomponent record in another — that structural transformation is exactly what talking is built to handle. Otherwise you'd have to hardcode every one of these scenarios individually. Instead, we handle it through our expression language, which gives us the flexibility not just to transform one thing into another, but to derive entirely new records purely from existing data.

Another genuinely unique problem we've solved well: a single design producing multiple distinct end items. The canonical example is a sink available in multiple finishes — brass, copper, stainless — where the underlying CAD design is fundamentally identical, just manufactured from different materials. You really can't cleanly represent that in most ERPs without a configurator or something similar, and typically each variant still needs to resolve down to its own distinct part number. That's a textbook transformation case: one source design needs to fan out into multiple distinct end items. That's genuinely difficult with linking, because linking assumes something close to a one-to-one relationship — maybe one-to-many with real difficulty — whereas transformation lets you say "I need to generate several related-but-distinct items, swapping specific attributes based on which raw material variant applies," all derived consistently from one shared source. Talking handles that natively; linking really doesn't.

That's a fairly sophisticated use case, but I also think about simpler, very common scenarios from recent projects — customers without traditional part numbers at all, for whatever historical reason, or generating a huge volume of new part numbers that need real-time lookup logic, with real complexity in how the bill of material gets structured that isn't knowable in advance. You genuinely need the ability to look up existing data and make contextual decisions based on other attributes in the model — it's rarely as simple as "this part exists identically on this BOM in both systems."

Jeff: The logic really has to reflect how companies actually operate in practice — as Mike Tyson put it, everyone has a plan until they get punched in the mouth. In theory, everything should line up cleanly — in practice, it often doesn't. Sometimes there's real organizational inertia — companies do things a certain way for historical reasons, and while you obviously want to guide them toward best practice, sometimes you have to meet them exactly where they currently are.

Scott: Our philosophy has always been: promote best practice, but stay flexible enough to handle how things actually work in the real world.

Jeff: That resonates a lot with my teaching background — a huge part of the job is meeting students exactly where they are, and helping them build real, incremental value from there. Sometimes the "right" answer is teaching a foreign language properly from first principles, but a student's still struggling with basic grammar in their own native language — so you have to meet them where they actually are and help them improve day by day. It's never enough to just say "you're doing it wrong, here's the correct way" — you find what actually works for their current situation, and guide them steadily toward best practice, making that path as low-friction as possible. If getting to best practice is genuinely difficult, most people simply never get there. But if you make the path incrementally easier, you get people meaningfully closer to that ideal.

Flexibility vs. Restriction in Data Integration
Scott: That's really "strong beliefs, loosely held" — I think that phrase comes from Reid Hoffman at LinkedIn, and it applies well here. We hold strong opinions about best practices and how things should work, but we don't let that become the enemy of real progress — you have to stay flexible. That's exactly why the talking-based architecture gives us the best of both worlds: enough flexibility to let customers evolve incrementally toward best practice, without being so restrictive that they get zero benefit until they've achieved perfection. There's a lot of all-or-nothing thinking out there.

Jeff: So much all-or-nothing thinking.

Scott: I'm an engineer, I can say this about my own tribe — we tend to think fairly binary: it's either great, or it's broken, with not much acknowledged in between. That's not really how the world works. In software specifically — I think I've said this on another episode — an 80%-complete bridge doesn't function at all; it either holds the load it's rated for, or it collapses. Engineers naturally think in those absolute terms, because for something like a bridge or an airplane, that binary thinking is genuinely correct and necessary.

But when you're talking about process improvement or automation and integration, there are real, meaningful gradations — 80% automated is still an enormous win, not a failure state. Meeting people where they currently are, giving them a real, achievable path to the next level, and having an actual roadmap toward eventual best practice delivers far more real-world value than being dogmatic and insisting on all-or-nothing perfection from day one.

Jeff: That's a great mantra — any parent, teacher, or anyone who works closely with people learns that incremental improvement is the way forward, and you can't let perfect become the enemy of good. Get some real improvement moving. It's like fitness — you're not going to work out hard today, fine, just go for a walk. You're not going to turn into a bodybuilder overnight, but small, consistent improvements compound over time.

Closing Thoughts and Future Directions
Jeff: Great conversation, Scott — this really represents our overall thinking on engineering integration well. Thanks, everyone, for listening — find us at cadtalk.com, subscribe to the podcast on YouTube with video, or wherever you get your podcasts, Apple Podcasts, Spotify. I genuinely enjoy watching those YouTube subscriber numbers climb. Leave a comment if you want to join the conversation — let us know what you think about our take on descriptions, or integration philosophy generally. Next episode, we're digging further into ERP — specifically, how your ERP might be holding your business back, and what you can actually do about it. Before we wrap, any last thoughts, or anything big coming up for you?

Scott: We've got some trips coming up, but mainly — I'm genuinely glad you mentioned the comments, please keep them coming. I'm sure people won't agree with everything we said today, and we're always genuinely open to learning — we talked in an early episode about relentless reinvention, continuous improvement, that's a mantra we actually try to live by. If something we said sparks a thought, or you've got a solid example where our thinking might be off, or could use updating, please leave a comment. We genuinely enjoy that engagement — we're just trying to keep getting better. This reflects what's worked well for us so far, but it's not dogma, just an ongoing discussion — we'd love to see the comments, everyone.

Jeff: Scott, we'll see you next time — and thanks, everybody, for listening and watching.