• Home
  • All Episodes
  • S2, Ep. 3 – From Customer to Solutions Architect: Bryce Ludwig’s Journey with CADTALK

S2, Ep. 3 – From Customer to Solutions Architect: Bryce Ludwig’s Journey with CADTALK


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

In this Integrate Intelligently episode, Jeff and Scott Brickler interview Bryce Ludwig, who transitioned from CADTALK customer to Solutions Architect. Bryce shares his manufacturing engineering background and implementation experience, discussing how integration needs differ between high-volume/low-mix and low-volume/high-mix environments. The conversation highlights CADTALK's key benefits: speed for engineer-to-order operations and consistency for mass production. Bryce emphasizes the value of configurability without constant consultant involvement and concludes with practical advice—start simply, achieve immediate benefits, then build iteratively—demonstrating CADTALK's mission to bridge engineering and manufacturing systems.

Full Episode Transcript

From Customer to Solutions Architect: CAD-to-ERP Integration From Both Sides (S2 E3)
The Integrate Intelligently Podcast, Season 2, Episode 3 — with Jeff Brickler, Scott Brickler, and Bryce Ludwig (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Brickler, and today is Season 2, Episode 3: from customer to solutions architect. I'm joined by my co-host Scott Brickler, founder and CEO of CADTALK, and by one of our solutions architects, Bryce Ludwig, to talk about his journey to CADTALK. Bryce, good to see you.

Bryce: Thank you for having me.

Jeff: Today is unique in that Bryce was a customer and now works here as a solutions architect — so he's seen it from the customer side and then moved over to the dark side, if you will, working with customers like himself.

I always like to start with: what is CADTALK? With the exception of me, it feels like a bunch of nerd engineers. But really, we're engineering and manufacturing people who work with manufacturing companies that want to streamline their operations, improve their processes, and get their systems talking — specifically engineering systems and ERP.

Bryce, that's how you came to us, and it's how Scott got started building the solution in the first place. People who end up in manufacturing and engineering tend to have interesting backgrounds, so tell us about yours — where you grew up, what drew you to engineering, and how that led you here.

Growing Up Curious: Legos, Hot Wheels, and Car Design
Bryce: Happy to. I grew up in the greater Kansas City metro area. Born here, lived a couple of other places in early childhood, and we were back by the time I was about ten. Growing up, I gravitated toward how things worked — big on Lego, big on Hot Wheels, anything with wheels or anything you could build. And I got a lot of encouragement on that as a young person.

By high school I was taking math classes and thinking that was cool. I loved geometry, loved art, and was doing a lot in that space. So I figured I'd go be a car designer — that's the dream job. I got encouragement from my parents and from one of my art teachers who'd wanted to do the same thing, and I looked into it. It's a bit like saying you want to be a surgeon in space. To a high school student it seems like something you could go do, but you'd spend all the money you'll ever make just getting the education for it.

That's when I found out the stuff I liked designing wasn't just cars. So I went to the University of Kansas for industrial design — consumer product design. On my college visit, after I was already signed up and ready, I heard the engineering team was building a race car, and I thought, I want to go do that. They allowed non-engineering students to volunteer on the Formula SAE team, so I did that, and I also spent a year majoring in mechanical engineering before going back to consumer product design. I had exposure to both at that point.

I liked the creative side — the brainstorming, adding value to products by looking at how people actually use them.

Designing Things and Then Having to Make Them
Bryce: After college I did exhibit design for several years, and as part of that we were also manufacturing things. All custom one-offs. We did a children's museum for the Kansas City Chiefs at one place I worked, designing things like ten-foot-tall football helmets that were also play structures, and all kinds of weird things. So you get this mixture where you're designing these things and then also figuring out how to make them.

That was quite an education in every manufacturing methodology you can think of — whether we'd do it ourselves or contract it out. How do you even know who to find? How do you know what to do? At a smaller company I got a crash course in everything manufacturing. It was a lot of fun, and very flexible and open, but once we'd made the thing once, we pretty much never made it again.

So the lesson of "now do it twice" hit hard later. If you start out in manufacturing, I think you take that for granted, because you're coming into a system where people have already figured it out — there's an assembly line, a process, tools. When you don't have any of that and someone says "now do it again," it's like, whoa, this is really hard. You get educated very quickly on how much goes into setting up manufacturing, and what a discipline manufacturing engineering really is.

As a designer, that was something I thought I understood until I was asked to make another instance of something. The decisions you make to do something once and the decisions you make to do it ten or a hundred times are often wildly different.

From there I worked with a couple of other manufacturing companies, one for about ten years, where I did a lot of engineering leadership roles — including helping select an ERP, helping implement it, and then implementing CADTALK. Which is where I met you all.

Why the Best Engineers Embrace Manufacturing
Jeff: Something I've noticed talking to customers, and to people like you and Scott who came to work here, is that not all engineers embrace manufacturing. Manufacturing engineers do, and industrial engineers — which is Scott's background — do. But I've talked to hundreds and hundreds of engineers over the years, and plenty of them see themselves purely as designers. I design this thing, that's what I do, and how it gets made is someone else's problem.

The most successful people I've met embrace both. Yes, I'm a designer, yes, I'm an engineer — but also, how does this thing get made, and how does what I do here affect what happens downstream? To your point, if I'm making ten thousand of these, I design it very differently than if it's a one-off.

We were at Universal recently — our sister works there, and everything in the new park is one of a kind, whether it's a roller coaster or a themed environment.

Scott: Our sister has an industrial design degree too. She started at a company in Louisville that did the Crayola Experience in Florida, then ended up at Universal and was involved in designing the new park, which just opened. Jeff was walking around with her while she pointed out the things she designed and how they were made. It's funny talking to her, because what she describes is a mix between manufacturing and construction.

Engineer-to-Order, Mass Production, and Everything Between
Bryce: Absolutely. I used to be an electrician, so I worked construction before going back to college to become an engineer, and engineer-to-order feels much more like construction than like assembly-line work.

Scott: Making cars or cell phones is a completely different set of problems from making four or five of something. We used to make packaging machines — we made the parts more than once, but a lot was customized. Going from engineering intent to manufacturing execution looks different when you're doing it constantly. In mass manufacturing you have time to really refine how you build something. In engineer-to-order or construction, you get one shot, maybe two, and then it's a question of how fast you can figure it out and get the job done.

We traditionally see a lot of engineer-to-order with CADTALK, but there's good diversity now, because the problem still needs solving regardless — it's just solved slightly differently depending on where you sit. We have customers doing construction, all the way through to mass-market work.

I came from the same background you did, Bryce — engineer-to-order — and when I moved into consulting I assumed everybody was the same. You have to do it this way, because that's how we did it in engineer-to-order. I got humbled pretty fast. In mass market, making the same thing over and over, they don't think about the problem the same way at all.

Bryce: That was one of the exciting things about coming to work for CADTALK. I'd seen the super-custom, low-volume world with exhibit design and themed environments; then medium-to-high-volume product manufacturing, where we had a mix of engineer-to-order and high-volume product families — 250,000 units a year for electrical products. Then in the role where I first met you, we were building construction truck vehicles: water trucks, crane trucks. Medium volume on some, very low volume and highly specialized on others.

So you see standard products, fully custom products, and everything in between. And then you talk with other manufacturing people at networking events and see how they go about it, and that's fascinating. I could do that all day, every day — and I'm lucky that I get to.

High Volume, Low Mix vs. Low Volume, High Mix
Jeff: When I started at CADTALK ten years ago it was mostly engineer-to-order, but over those ten years I've seen the whole spectrum. One of our PLM partners puts it as high volume, low mix on one end and low volume, high mix on the other, with all the gradations in between. CADTALK fits in all of them, and the use cases are broadly the same — but which use cases matter most changes depending where you sit.

Bryce: Some are always the same, but a lot differ. On the low-volume, high-mix side, routings make a big difference — how you're going to make this thing. Those folks are very manufacturing-minded, because they're making it once and they have to do it the best way possible. They can't iterate.

The routing piece is critical, because that setup time gets the thing scheduled properly so everything sequences through. It may not be the perfect way — if you did it a hundred times you'd find a better one — but it's your normal way, so things go the way people on the shop floor expect and parts show up on time. Getting things sequenced in the right order matters a lot, and being able to do it the same way every time.

That consistency in how you launch products to the floor is huge, whether it's a whole new product family or a variant for one customer who'll order between one and ten. Making this one in basically the same way you made the last one and will make the next one means you can launch predictably. You can tell a customer: we finished the design, we're dropping this onto the floor, it'll be done three weeks from now. And lo and behold, it ships in three weeks.

What Pushed a Manufacturer Toward Integration
Jeff: In the role where I first met you, you had both — some high volume, low mix, and some high mix, low volume. Why did you consider an integration in the first place? What was the impetus, and what was the decision-making process?

Bryce: The groundwork came a few years earlier, when we were told by our previous ERP provider that the system we had was no longer going to be supported. So we had to go get a new one. We had a really great CFO who knew they'd have to support their old ERP unofficially for at least seven years anyway, to have that overlap of auditing and transaction history — what a financially responsible company has to do.

That pushed us toward a more modern ERP that would allow CAD integrations, tax integrations, that sort of thing. Getting onto a modern platform was the big impetus.

But even before that, we were looking at manufacturing automation — integrated cutting, stamping, and panel bending machines. We'd visited your neighbors in the Cincinnati area, Salvagnini, and some others. On that trip they showed us that if your CAD data is set up a certain way, you can drop a SOLIDWORKS file in and it will unfold everything, figure it out, and put it together.

Well, our CAD files weren't set up that way. They weren't set up the modern one-part, one-model, one-print way a lot of people use now. We had a lot of configurations, named according to whatever convention this engineer or that engineer used at the time. That's not uncommon, especially as companies grow — you start smaller, this person's the expert on one thing and that person on another, and everyone has the reign to do their own job.

So we got the message from them, and from a couple of other people, that we needed to take better advantage of our 3D modeling system and do things more consistently.

Then a new VP of engineering came in who'd been at Fortune 500 companies — Pella, Ingersoll Rand. He'd seen how these things were set up to work with SAP and Oracle integrations back in the early 2000s, fully custom. So we had external pressure saying we needed a new ERP, and a mentor saying that if we get a new ERP and fix our CAD data the way we'd been told to, we can use modern tools and be a much more effective engineering team.

On the low-volume, high-mix side, that meant launching products and getting them from design to shop floor much faster, getting better at design reuse, and giving the floor everything it needs to understand the design intent so they can execute it. On the other side, my role at the time was value analysis and value engineering — how do we make our higher-volume, lower-mix products more material- and time-efficient? The answer was that we needed to make design changes and implement them cleanly. We're launching this revision as of this date, and it's cut over smoothly.

So we had both use cases, on both axes, but the tool was the same for both: we could either launch something new quickly, or make a change quickly and completely.

Speed on One Side, Consistency on the Other
Scott: You touched on something interesting. For high volume, low mix, the speed and consistency of the data transfer weigh heavier than the time savings of the transfer itself.

In high mix, low volume, what you're after is speed — typically lead time reduction. There's a book called Quick Response Manufacturing, which is essentially lean for people doing engineer-to-order, and they treat lead time rather than cost as the metric. The reasons are beyond the scope here, but they look at how fast you can go from one thing to the next.

What's interesting in what you said is that on the high-volume side it's still speed, but it's the speed of change and, more than that, the consistency of the change. You can implement a change into a complex process much faster because the software executes consistently. That's a distinction I've never heard put that way, and I want to make sure we capture it.

Jeff: Let me dig into that, since I have the least manufacturing experience here. On engineer-to-order, where we're making something once or twice, getting it into the system fast matters because of lead time — it might take six months to get a part ordered and made by an outside process and delivered so we can hit our customer's date.

Scott: And lead time is one of the competitive advantages in engineer-to-order.

Jeff: Take our sister's work at the park. You're designing a coaster with a new ride scenario, and some complex part of that might take six months to source. Everything has to come together at a certain time so the whole thing can ship to the site, get installed, tested, constructed, and hit a date. Every day it doesn't open is a day they lose revenue — and the published figure for that park was over six billion dollars. Every day without what they need is burning money.

Bryce: And when you scale that down to a regular engineer-to-order manufacturer, the same thing holds. Think about conveyor — that takes up space while you're assembling and testing it. You don't have unlimited room to put together a customer's equipment, do the trial commission, set it up, run it, pack it, and ship it. Any day that's sitting in your test zone, you can't test the next project. When you're constrained on one resource, you can't do the next thing. Speed is king in engineer-to-order.

Scott: The converse is that in mass production there's a lot more overhead. When you're designing a line, there are lots of little switches and throttles to tune to exactly where they need to be, so every design change is a big process. That's why you typically see PLM more in mass production — it's managing the complexity of change management.

So if you automate with integration, you drive consistency up, because the software does it the same way every time, checks all the boxes, and turns all the knobs correctly. That change management process becomes much easier to manage. CADTALK produces a benefit on both sides; it's just speed on the engineer-to-order side and consistency on the mass production side.

Jeff: That tracks with one of the last customers I implemented — they do water filtration systems. Not engineer-to-order at all; they make mass-produced products sold through places like Costco. But they make a lot of changes to labels and to mixes of filtration products, and they can implement those changes quickly because they have a PLM. Once it's approved, it needs to get into the ERP fast so the new revision is in production, with all the compliance boxes checked.

Alternates, Substitutes, and Supply Chain Resilience
Bryce: Funny you bring them up, because I had a conversation with a couple of people from that organization about a week and a half ago. They asked a support question: we have alternate and substitute parts in PLM, could we use those in ERP too? They're looking at a complete package of data that gives them more flexibility and redundancy in how they execute on the floor, and they've already defined it — they just want to pull that data over as well.

On the high-volume side it comes down to how complete your change can be. How thoroughly can you do it, and how clearly can you express everything you're changing? If my top-level item goes to rev B of one of its subassemblies, and rev B contains things that weren't in rev A, how do I express that so you can see all of it — order the right material, have one production run be the previous rev and the next one different in all the ways that count?

Jeff: It makes me think of the conversation Scott and I had a week or two ago about supply chain disruptions. A complete bill of materials with alternates de-risks production. If certain parts aren't available, or tariffs hit, you can switch to one of those alternates much faster than you could without it.

Bryce: And the alternate and substitute piece helps on the low-volume, high-mix side too. If you're using a galvanized steel part and you have the same gauge and strength in 304 stainless, you could use the stainless raw material for a run. To the point we were discussing yesterday about nesting and optimization — I've got half a sheet of stainless, I can use it for these parts, it's more than good enough. Otherwise it gets scrapped. So you're using material that would have gone to waste.

Where AI Changes the Math
Scott: I was talking with one of our partners about this yesterday. Think about where computers are genuinely good. Until recently, computers were good at being fast and consistent, but not at being creative or generating things. Now you have generative AI.

But even generative AI and machine learning are fundamentally about correlation — it's a huge correlation machine doing pattern recognition. And that lets you do things you couldn't before. A manufacturing engineer has to sit down and figure out how to make a thing. If software can do that, it can do it fifty times and tell you which is best.

Which means you can start applying principles from high production to low production, because it costs you almost nothing. I have to make this one-off thing, but I can run fifty scenarios through the routing engine and find out which is most cost effective and which fits the current schedule. A person wouldn't have spent that time in the past. It's a very interesting moment, because you'll see more blending — why can't an engineer-to-order product actually be cheaper than normal, because the software simulated all the scenarios and figured out how to make it 20 percent cheaper? Simulating it rather than actually making it is a wild concept. A bit of a tangent, but I tend to think ahead like that.

Related to routings: they're getting to where they can predict when a machine will go down, so you can redirect to an alternate routing on the fly, automatically. In mass production you handle that with redundant lines — multiple assembly lines. In engineer-to-order, if your laser goes down, most of the time you just outsource. But you might be able to put it on a shear and then mill it. More expensive, but it gets the job done.

Bryce: That's a great example. If you have a laser and a plasma table, you could theoretically use either, or a water jet. It may not be your best way, but it's a way to keep going. Or your rule might be that for everything you laser cut, you also maintain the ability to send it out to a small group of external suppliers — and you give them some work anyway, to keep that capacity and flexibility available.

That's where setup matters. Using IFS as an example, IFS lets you make a part, buy a part, and choose the mix. Us being able to set up data that supports both processes — pulling things from the CAD side of the data that give you those abilities — matters if somebody can say, here's the rule I want to apply. If a person were doing that, it's time-consuming to input all that data. But if you're applying the same thing every single time, or every time you encounter a category, we can do that very quickly and efficiently. It takes some time to set up, but once it's working you get the benefit of multiple options for shop floor execution — making it, buying it, moving it across different machines.

Anything where you can think through how you'd always handle this type of part or this type of assembly gives you much more flexibility to execute and to navigate when things aren't the way you want them to be, but you still have a path forward.

The 80 Percent That Isn't the Happy Path
Scott: This goes back to something people ask us all the time, and there's a lot of crossover between manufacturing and software here. People ask how long it'll take to build a thing. It follows the Pareto principle: 20 percent of the time is spent solving the problem under normal conditions, and 80 percent is spent dealing with edge cases.

It's the same in manufacturing. Sure, I could create a routing for this assuming all my machines are running, everything's in a perfect state, everybody's working today, and there are no holidays. But actually making a plant run under normal conditions — where things go wrong, things break, material doesn't arrive — that's what makes manufacturing hard. Not the perfect case. And all of our planning tools plan for the perfect case. Opening these tools up lets you deal with the real world, which is the 80 percent.

The analogy is so close. You could build the integration very quickly assuming a perfect world; it's the edge cases that take the time. Making something once in your garage is pretty easy. Making it a thousand times, day in and day out, is really hard.

Bryce: Repeatability is tough in any world — manufacturing, software, solution architecture, meetings with clients, project management. Doing these things again and again and getting consistency out of it is challenging. It's a problem everyone has, and a competitive advantage for those who learn to do it well.

Scott: You don't have to have the best thing, you have to have the most consistent thing. McDonald's is the perfect example — not the best burger, but go to a McDonald's anywhere in the world and it's pretty much the same burger. Starbucks is even better at it. It's amazing how you can package up consistency and make a killing doing it.

Why This Customer Chose CADTALK
Jeff: Bryce, what led you to choose CADTALK as a customer? You were looking at a new ERP, and your VP of engineering was advising you. What made CADTALK stand out in the selection — beyond whatever my pitch was at the time?

Bryce: Great question. The company I was at was very due-diligence-oriented, sometimes to a fault, so we looked at all the options. We were at SOLIDWORKS World, which I think is where we met you, and we met all the competitors too — CAD Link, OpenBOM, Agni Link, Elmo, who are now part of the CADTALK family. We got all the sales pitches and did the analysis.

What helped us make the decision and feel comfortable with it was the partnership picture. I don't know whether you were an official IFS partner at the time — IFS was the ERP we were implementing — but IFS, Ultra Consultants, everyone was saying CADTALK is who you want to talk to. Whether the partnerships were official yet, they were there and they were strong. Anytime somebody vouches that this works with what I'm providing you, that's a good thing. It's the "made to work with Apple" or "made to work with Samsung" idea. It gives you credibility.

But the thing that really made sense from our perspective came from people I worked with who had experience with Windchill and other software that's very consultant-heavy. You can't do anything on your own. Everything you do, you have to get somebody involved, get your reseller involved. You may get a fantastic solution out of it, but you don't have much control, things don't happen on your schedule, and when something stops working you're stuck until you can get help.

Of the solutions we saw at the time, CADTALK gave us the option that once we had things configured, if we needed to change something because our business changed, we could do that. We could get advice from you if we needed it, but we could also try it ourselves in a test environment. Make a change to our SOLIDWORKS PDM environment in test, change how we use CADTALK, see how that connects to IFS — we could go verify that and run our own experiments as our business processes evolved.

We knew adopting a modern ERP was going to require a lot of other changes well past go-live. There would be a ton of continuous improvement opportunities in how we design and manufacture things. So the ability to grow and change with some control of our own was really appealing.

Crossing Over: Life as a Solutions Architect
Jeff: That configurability is something I talk about often — you have the control, so you're not beholden to the vendor or to an outside consultant.

For background, a solutions architect at CADTALK is someone like Bryce with experience in engineering and manufacturing, who knows CAD and PDM and engineering processes, and also knows the dark side — manufacturing and ERP — and how those fit together. It's stereotypical but true that most engineers don't see the value of ERP. It's just this thing they have to feed all their data to.

Now that you're on this side, how has the role changed for you? You're helping people not just implement CADTALK but identify their processes and improve them. Scott talks all the time about how CADTALK isn't just software — the product is all of us.

Bryce: It was around September that we reconnected on LinkedIn and had a conversation that turned into a discussion about whether I'd be interested. Your intuition was good, because after finishing an ERP implementation you naturally start asking what's next. I thought it would be really cool to do this from the other side, see how a lot of other people approach it, and help people make the choices I got good help with — while also fixing the places where I thought, I can probably help people with this too. So it was something I already wanted to do, and the timing was right for me and I think for CADTALK.

One thing I noticed in the transition is how much growth there's been — not just at CADTALK, but in CADTALK as part of an engineering, design, and ERP ecosystem. That whole engineering data ecosystem has grown tremendously in the last five or six years: the people who know each other, the partners across the different ERPs, the CAD and PLM companies, the consultants we end up on the same projects with as customers change their processes. Those relationships are deeper, broader, and more productive. It's not that they didn't exist five years ago, but there's much more of it now, and far more people working together.

We can do things now, with a larger solution architecture and implementation team, that we couldn't have done five years ago, when it was mostly you and a couple of other people, Jeff. We were doing awesome things then — and from here I can see the effort it must have taken, because now I can see how we do it with great partnerships in place. We work a lot with PTC, with Arena, a ton with IFS, and with Infor and many others in those ecosystems. We get great results because everyone's working together.

Advice From Both Sides: Start Simply
Jeff: You have a unique perspective, having been the customer and now working with customers. What's your advice, or the best practice, for someone looking at CAD-to-ERP integration?

Bryce: I love that question. What I always tell people is: start simply.

This is very much what a design engineer needs to hear — a manufacturing engineer usually already knows it. Start with something you can do, and do that. For us, start with parts. If that's all you can do, do it. If you can do parts and bills of materials, do that. Let's not worry yet about importing PDFs and other documents. We can do that, but let's get something working first, get it working really well, and make it something that delivers real benefit early. Take the thing that eats a lot of time to enter, or where there's a lot of room for inaccuracy, and get that done. Then come back as a quick follow-up and do the next thing — add change orders, add documents, add other stuff.

Start small. Start simple. Get something done. Use it.

As a design engineer, I needed to hear that at various points in my career, because the instinct is: but I could make it perfect. If I spend a little more time, I can do the next thing too, I can get it all done at once. And yes, you could — but you also run more risk of never getting done. Pick a reasonable scope, get it done, pick another reasonable scope, get it done, and keep going.

That's becoming more normal with ERP implementations too. Ten years ago it was a one-shot deal. Now, with things in the cloud and more flexibility, you can add functionality as you go in ways that weren't possible before.

Jeff: No wiser words. It's so easy to want to do it all, so easy to try to perfect it. I had a conversation today where someone asked what risk they don't know about, and I said the risk is that you try to do too much. It's the Archimedes line — give me a place to stand and I'll move the earth. Yes, you can do everything, but everything on a schedule, at a pace. You can do anything you want. Just not today.

Bryce: Exactly. Do anything you want, just not today.

Jeff: Bryce, this was a great conversation. Thanks for joining, and thanks to everyone for listening. Leave comments, subscribe wherever you get your podcasts, and watch us on YouTube. Feel free to reach out to Bryce or to us with questions about how CADTALK works, or just about how to make a decision or set up your systems so they can start talking.

Contact Us • 833-422-3825 • Copyright 2021 CADTALK Software • Privacy Policy