Ep. 29: Can I Actually Integrate my ERP? Breaking Down the Barriers

Can You Actually Integrate Your ERP System? Breaking Down the Barriers, Pitfalls, and Common Fears
The Integrate Intelligently Podcast — with Jeff Bickler and Scott Bickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, again accompanied by my brother, founder and CEO of CADTALK, Scott Bickler. Today we're talking about one of my favorite topics: can I actually integrate my ERP system? Breaking down the barriers — can it work, will it work, what are the pitfalls, what are the dangers, what do I need to look out for. Scott, good to see you again — I'm sure you'll have a lot to say on this one.

Scott: Oh yeah, plenty to say. This one comes up a lot during the sales process and in discussions with customers, so I'm looking forward to getting into it.

Jeff: Good point — I was just on a discovery call with a prospect talking about this exact thing: how does it work, can I do it, what should we be thinking about. When you're integrating with an ERP system — especially around bills of material and parts — you're dealing with complex data structures, and engineers are involved. We've talked before about how engineers tend to think in complexity, so a lot of "what happens if this situation or that situation" questions come up. But I think once we get into it, people will see it's actually a lot simpler than they think.

Why Engineers Overthink ERP Integration — And Why That's Okay
Scott: I think it comes from a good place. People want to be prepared — if they're going to invest in a technology or solution, they want to make sure they're ready. But it's one of those things where preparation can tip into paralysis by analysis, and that's a common issue with engineers. I'm an engineer, so I can say this: you're used to being precise, and when things matter, you measure twice and cut once. You don't want to have to go back and fix something, because that's costly — true when you're building a bridge or designing machinery, where mistakes carry real costs.

But implementing software is different. It's mostly an iterative approach — you get into it, understand how it works, see the results, adjust, tweak, and keep going. That's the opposite of "big bang" thinking, where you try to figure everything out before you start. If you approach software with the same mentality you'd use to build a bridge, you're probably never going to start.

Jeff: That's the analogy you always use — it's like flying an airplane. You take off in New York headed to LA, and it's not a straight shot. You're constantly recalibrating.

Scott: Right — you're off course something like 95% of the time. People don't realize that in a plane, wind and other conditions are constantly pushing you off track, and the pilot is constantly making small adjustments. Those adjustments over the whole flight are what let you land precisely in LA. There's obviously planning involved, but there's also constant adjustment along the way.

Jeff: Exactly — it's not a big waterfall where you plan everything up front and then you're locked in. You're always adjusting as you go, and you can build on it over time. It doesn't have to be a one-time, big-bang event — unless you're running a fully custom integration, where every change means going back to a developer. A configurable platform lets you improve as you go and makes changes much easier.

Scott: Right, and a lot of it comes down to consistency — it's better to be consistently wrong than sporadically right, in a sense. You don't always know what you don't know until you're actually in it. You learn how things work and what the best process is by trying it. You go from uninformed pessimism to informed pessimism to informed optimism — and it's hard to get there without actually getting in the middle of it and doing the work.

The Most Common Objection: "Our Data Isn't Clean Enough"
Jeff: Let's talk about the common objections — or concerns, really — people raise, whether it's about integrating with CAD specifically or any system. I was on three calls this morning with customers or prospects, and a common question was about data: "our data isn't clean," "our models aren't structured properly." Is it really as complicated as people assume, or do we need a reality check?

Scott: It depends — which isn't a satisfying answer, but it's true. It depends on the data you're working with. If we're talking specifically about CAD, PDM, or PLM data — if you're using 3D CAD or some kind of PDM/PLM system, there's a certain amount of rigor and discipline just baked into having those systems in the first place. So if you have them, you're probably fine. You might not get every bit of value you could, but you have enough to do something meaningful.

Now, if you're in 2D CAD and things are really inconsistent, it gets tougher — you're basically talking about a digital drafting board with not much built-in intelligence. But once you're in 3D CAD, PDM, or PLM, you're in reasonably good shape. Not perfect — far from it — but there's a lot there to work with.

I actually think the real fear isn't "can you use my data." The real question people are asking is: "is there enough data here to make this purchase worth it?"

Jeff: That's a good point — I hadn't thought of it that way. The fear is that their data might not be good enough to justify the investment.

Scott: Right, and we've found the opposite often happens — people correct their data because they got the tool, not the other way around. They didn't clean up their data to earn the tool; the tool framed the problem exactly the way they needed to see it, which showed them what needed fixing.

I'm going through this myself right now on some internal projects — we don't know exactly what the future state looks like once certain tools are in place, but we assume we need a bunch of extra pieces before we can start. It's like planning a vacation. My wife and I are headed to Hawaii in a couple months, and she's saying we need to buy all new clothes because I lost some weight this year and things don't fit. And I'm thinking — is that actually a requirement for going to Hawaii, or is it just something we want to do anyway? Probably a bit of both. But I will arrive in Hawaii with clothes on either way. I might not look as good as I could, but I'll get there. And they sell clothes in Hawaii — I could just go, see what the weather's like, and get what I need once I'm there.

It's the same with these systems. You can guess at what you'll need, but you won't know for sure until you're actually in it. People go off on a tangent trying to make everything perfect before they start, then realize once they implement that they didn't need to be perfect — and every day they delayed, they didn't get the benefit of the automation or integration they were putting off. It's like saying "I can't go to Hawaii until I buy the clothes," and then missing the flight because you were too busy shopping. At some point you just have to jump in and see if it works. If it turns out there's truly nothing that can be done, you can back out — but starting is how you learn what you actually need, instead of overbuilding for scenarios that never come up.

Is There a Minimum Data Standard to Get Started?
Jeff: I think that's the most common fear — "my data won't be good enough to get real benefit out of this" — and honestly, I rarely see that play out. So, Scott, is there some kind of minimum floor a customer should meet to get their systems talking?

Scott: The way I look at it: if someone is already doing this manually today — taking data out of CAD, PDM, or PLM and getting it into an ERP somehow — that process is happening one way or another, or nothing would ever get made. If there's enough information for a person to make that translation today, there's probably enough information for software to provide real benefit, especially with more modern technology. If you're doing it at all today, there's a path to get there with software.

Jeff: That matches what I used to tell customers — if you're doing it manually today, there's a way to get there with software. One thing I have seen, though, is workflow gaps — a rare case, but it happens — where an engineer isn't putting part numbers into their model at all. They hand off drawings or structure to someone else, who enters it into the ERP, and the ERP generates the number. Then the question becomes: how do you handle a revision change if you don't even know what the number is? Do you write that number back into the CAD system? There has to be some connection between the two systems, or it stays manual forever. That's one basic requirement I've seen come up — you need a part number, in some form. But I know we've built a solution for exactly that gap.

Scott: Right, that's a great example — and honestly, people tend to saddle software with requirements that a person doesn't even meet today. If a person doing this manually isn't using part numbers, they still have to handle revisions somehow — they're doing some kind of lookup to figure out whether what's in front of them is a new part or an existing one. Maybe it's a drawing number, a description, or something else — but there's logic happening, some decision being made about whether this is new or a revision. All we're really doing is replicating that same decision-making in software, because that decision has to happen either way. So yes, having a part number is a recommended approach — but the underlying need for some unique identifier exists no matter who, or what, is making the call.

How CADTALK DFM Solves the "No Part Numbers" Problem
Scott: On the writing-back-and-forth issue — we used to run into that a lot, and the way we solved it was by building a tool called CADTALK DFM, design for manufacturing. A lot of engineers weren't creating part numbers because those numbers actually come from the ERP, and there was no clean way to issue them mid-design. So we built a tool that works inside the CAD system and lets you request numbers from the target system — the ERP or PLM — while you're designing. It can also verify and look up other information in the ERP, not just issue numbers. The simplest example: "give me the next number in the ERP for the thing I'm about to design." It issues a new number that can't be reused, drops it into the model, and saves it to the part's properties — so everything's prepped ahead of the downstream integration.

That's usually what we recommend for customers who are worried their data isn't good enough — we implement design-for-manufacturing practices that put the process on rails, essentially populating the data correctly as you go so it's integration-ready. There are other approaches too — it doesn't have to be an issued number. You can use a lookup instead, as long as something in the model uniquely identifies that part: a drawing number, a GUID, whatever. As long as there's a reliable way to match one thing on one side to exactly one thing on the other, the same logic applies. There has to be some way to uniquely identify whether something is new, existing, or a revision — and that's true no matter whether software or a person is making that call.

The Three Things You Actually Need to Get Started
Jeff: So people don't always realize they need that decision point regardless of the system. When I'm talking with people — at a trade show booth or just in general conversation — I usually say there are three things you ideally want in place, as a bare minimum: part numbers, descriptions, and some kind of revision tracking (number or letter). None of these are strictly required — as we said, if there's another way to uniquely look something up, we can work with that, and descriptions can sometimes be pulled automatically from model data. But if you have those three things — part numbers, descriptions, and revision tracking — 99% of the time you're in good shape to integrate today and get real value out of it.

Out of the box, CADTALK can take the part numbers and descriptions you already have and create and update those parts in the target system. That said — is that the best approach, the one that gets you the highest value? No. With just three fields, you're not going to max out the value, but it's still meaningfully better than doing it manually. And that's not the end state — it's a starting point for continuous improvement.

Why "Our Data Isn't Ready" Is Usually an Excuse to Delay
Scott: I think this is broader than data, honestly. A lot of times when people raise the data question, they're really looking for a reason not to start — something outside their control, like "I don't have control over the engineers." What it usually comes down to is: you just start. There's a book behind me, Buy Back Your Time — great book, talks about exactly this. People won't delegate things early on because "I can do it myself" — mow my own lawn, whatever. And yes, you can. But when you start delegating or moving things off your plate, it frees up time to improve the next thing.

You could keep entering bills by hand because you can personally catch engineer mistakes and inconsistencies as you go — or you can automate the parts you're able to automate, which frees up your time to then improve the process and automate more. That's how improvement actually happens. You don't wait for things to be better later, or for the perfect moment — you have to start doing something, and doing something is what frees up the time to do the next thing better.

Jeff: Right — you've got to scaffold it. Get something going, get some time back, use that time to improve further, and keep scaffolding up until you're where you want to be.

"It's Too Much Work" — Why That's Not True
Jeff: Another common objection: it's going to take too much work, too many process changes. I know I've heard it, and I'm sure you have too. Why isn't it as much work as people think?

Scott: It's like saying, "I've put my pants on backwards for the last 30 years, I can't change now, I'll look like an idiot." You're not going back and fixing every pair of pants you ever put on backwards — you just start putting them on the right way today. There's a misconception about all the historical data sitting in the ERP. That data only actually matters when you change it. You can work through it via attrition — fix things as you go. There's no need for some massive retroactive cleanup of everything you've ever done. It only becomes relevant when you touch it — when you make a revision. You can implement a new process tomorrow and start "putting your pants on forwards" from that point on. Over time, as designs churn and revisions happen, old data naturally obsoletes and gets replaced. That inertia — "I have to fix everything before I can start" — is a typical all-or-nothing mentality a lot of engineers have. I've had it myself. It's just not true.

Jeff: Right, and I think it's a feeling more than a fact — when you're a high performer, an engineer who takes pride in craftsmanship, there's a perfectionist streak that says "I want this to be perfect," and all that historical bad data feels like a problem. But you don't need to fix that to start today and move forward — things improve over time as you put a better process in place. People want an easy button where everything is instantly perfect, and that's just not how it works.

Scott: Exactly — and letting that stop you from making an improvement is basically a sunk cost fallacy. Economists talk about this constantly: money you've already spent is gone, and it's irrelevant to future decisions. All you can control is whether you keep spending more on the wrong approach. I can only start doing it right going forward — that says nothing about how much I've done wrong in the past, but I get the benefit of doing it right from here on.

We've seen this play out on bigger ERP projects too — teams keep making decision after decision down a certain path, and even when it's clearly the wrong direction, the instinct is "we're too far along to turn around now." But if it's not going to work the way you're going, it's not going to work — no matter how far along you are.

Document Your Assumptions — Or You'll Repeat Old Mistakes
Scott: People also forget why they went down a certain road in the first place — the assumptions behind the original decision. That's why I think it's a good idea to document your assumptions as you go, because everything gets decided based on the tooling and environment you have at the time. Two years later, you might think "I can't change that" simply because you don't remember why it was decided that way — and you might be avoiding a problem that no longer exists. If you remember the original reasoning, you can revisit that decision point and ask: is this still true? Has the technology or environment changed enough that the old assumption no longer holds? If so, you can go back to that fork and take the other path.

Don't Re-Engineer Your Process — Just Insert the Tool
Jeff: One more thing that comes up: fear of changing the process itself — "implementing CADTALK is going to change how we work." I actually had this conversation today. Someone described how they currently send data by manually entering it into their ERP, and asked about CADTALK. I told them: I could integrate the data flow directly and walk through other value props, but honestly, in this case I'd just keep doing what you're doing today — just insert CADTALK into that existing flow. Don't try to re-engineer the process chasing perfection right out of the gate.

Scott: That's the same principle again — free up time first, then improve the process. This happens with ERP implementations too — there's usually a specific reason you bought the ERP, some improvement you were chasing. We've talked before about how ERP implementations tend to fail when teams try to pack too many requirements into the initial rollout. The better approach: identify the one big thing you're trying to fix, get that working and successful, then iterate on future improvements. Trying to pack everything in at once and implement something entirely new is asking for failure. Even if what you have today isn't ideal, if it's working, you can free up time through automation and improve it from there.

Jeff: That's exactly what I recommended to the person I was talking to today — take what you're doing right now and just make it easier to do, today. I remember them describing their dream end-state: full manufacturing BOMs, routings, run times, the works — way down the road. And I said, we're a long way from that. Why don't we just start with what you're doing today, get something working, and move the data from point A to point B without changing anything else? Over time, you'll build confidence, make improvements, watch how the data flows, and it'll get better. At some point, someone on the team will say, "I'm just pushing a button here — I could really benefit from having this do more." That's when you take the next step up.

Scott: Right — you level up as you go, just like buying back your time. There's a lot of value in just starting, and a lot of downside to overthinking it. There's planning, and there's reacting — you need both. Mike Tyson's line applies: "everybody has a plan until they get punched in the face." That doesn't mean you skip planning the fight — you still plan it. But you also go in, take action, and adjust as you learn the playing field.

Jeff: Successful change management works the same way in general — one small change, get used to it, then another small change. I'm literally standing on my walking pad right now, not walking on it, because I'd probably fall on my face mid-podcast — but the principle's the same: maybe I walk during one meeting a day if I want to get healthier. Pick the smallest change that gets things moving, and build from there. Same with software: what's the smallest thing you can do to get going, get some benefit, and buy back some time to do more?

Recap: The Three Big Objections, Answered
Jeff: I think that wraps it up. We covered the three common objections. First: "we can't change our process" — the answer is, change the smallest thing possible, or just keep your existing process and slot a tool into it. Second: "it's too much work" — the answer is, do the smallest thing that delivers value, get to ROI faster, and fix the one big thing first, the way you'd approach an ERP rollout. Third: "our data isn't ready" — and we broke that down to: if you're using an engineering system like CAD, PDM, or PLM, 99 times out of 100 you already have the right information to get real value, with plenty of room to improve from there.

Next Steps: How to Get Started With ERP Integration
Jeff: So, Scott, what would you recommend as a next step for someone listening who wants to learn more?

Scott: Reach out and talk to us — people do this multiple times a day, and we can get specific to your actual use case, because everyone's process is a little different. We've seen hundreds, if not thousands, of these situations over the years, and we've built up a lot of best practices that we know work. When you work with a company like CADTALK, you're not just getting software — you're getting the company: the processes, the expertise, the experience. Reach out, and we can give you ideas and real value just from that conversation.

Jeff: I'll also point you to our resources — the podcast has a lot of episodes on implementation, planning, and ERP or CAD best practices, so check those out. We also have a blog on our website covering integrations, ERPs, CAD, and design topics. And feel free to schedule a call with one of us or a team member — happy to talk through how integration works and what's possible for your specific use case.

That wraps it up for today. Please subscribe to the podcast wherever you listen, and feel free to comment, like, and share. Scott, we'll see you again next time.

Scott: Sounds great — thank you.