S2, E12: Does CADTALK Take the Place of a CAD, PDM, or PLM?

Does CADTALK Replace Your PDM or PLM? How CAD, PDM, PLM, and ERP Fit Together (S2 E12)
The Integrate Intelligently Podcast, Season 2, Episode 12 — with Jeff Brickler and Scott Brickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. Today is Season 2, Episode 12: does CADTALK take the place of a CAD, PDM, or PLM system?

Scott, welcome back after the Memorial Day weekend. Big doings in Cincinnati — we have this annual event called Taste of Cincinnati, where all the food vendors come downtown over the holiday weekend and you can walk around sampling. Did you go?

Scott: We went this year. My wife is a foodie, so we went down and checked it out. They had all kinds of things — banana pudding, ice cream, a chicken egg roll with curry sauce that was so good. We had a great time.

Jeff: I missed it this year, though we've gone in the past. My wife and boys enjoy the food, but they complain about the crowds, because it's packed.

Scott: The crowds weren't too bad this year, and I think they did a better job with the layout. The weather was perfect — I didn't even get a sunburn, which I wasn't expecting, since I get burned walking outside for a few minutes. It gets crowded toward the end, but it's a lot of fun. They block off the streets downtown and you walk around.

Jeff: I don't know whether other cities do this, but Cincinnati has done it every Memorial Day weekend for 30 or 40 years. Every dish is eight or twelve bucks, and you can sample a lot of restaurants at once.

Scott: We especially like the food trucks, because those are harder to get to. Restaurants stay in one place, but with a food truck you have to be lucky enough for it to be where you are. Some of the best food is on those trucks.

Today's Question
Jeff: Today is more tactical — less about the theory of manufacturing and more about CADTALK, CAD, PDM, PLM, and integration.

The question is: does CADTALK replace a PDM or PLM system? This came up recently on a webinar, and I've had it from customers a few times, especially around certain ERPs with different functionality.

If you work in manufacturing as an engineer, you have all these systems and it gets confusing. We've joked about the vocabulary before — PDM, PLM, ERP, CAD, CAM. So today is about why this question comes up so often, what each system does, and how they interact.

Scott: My first reaction is that it's a silly question — and it's only silly because I know the answer. It comes up a lot.

We don't get mistaken for CAD very often. PDM or PLM is the more common one. And part of the reason is that one of the use cases those systems were built around was solving the problem of integrating to another system, particularly an ERP. The problem is that it doesn't really solve it. Not completely.

PDM is product data management — handling the CAD files and organizing them. We had a past episode on this: files used to live on file drives, and sharing them was a problem. PDM was built to solve that. PLM was more about ECNs and the processes for managing the lifecycle of a product. That's where the line gets fuzzy between PLM and ERP, because there's also M-BOM data being stored there.

So the market has been educated to think PLM is the solution to integration, and it isn't. It could be part of it, or not. It's just one of the things involved, but it's been marketed as a combination. So when people see CADTALK they think: there are jobs to be done around this work — how many of them are you doing? Are you vaulting the parts? Are you handling the lifecycle of the thing?

A lot of solutions in the past tried to do traditional PDM or PLM functions along with the integration. Our strategy was different. It would be very difficult for us to do PDM or PLM functions better than the CAD vendors who build them. It's hard to out-SOLIDWORKS SOLIDWORKS.

Back in the '90s and early 2000s, when I was coming up, there were separate companies doing PDM, working with all the different CAD vendors. Then the CAD vendors started creating their own. There are still standalone PDMs, but people started buying the one that came with their CAD, because of bundling — Vault with Inventor, SOLIDWORKS PDM with SOLIDWORKS. It worked better because it was built for that product. Then PLM came along with lots of vendors, and those consolidated toward the CAD vendors too.

And they're really good at working with their own stuff. That's exactly the problem. The job that needs doing is what happens when they have to talk to things that aren't their stuff. That's where we sit well — as an independent in the middle that knows how to talk to all these systems. We become the translator.

That problem will probably always exist as long as there are multiple vendors selling things. We're not trying to be another system like a PDM or PLM. We're trying to be the intelligence that ties them together. There's this concept of a digital thread — we're the intelligent needle that threads these systems together.

Why People Ask the Question
Jeff: A lot of people are involved in these conversations, and it isn't just engineering. Even with CAD and PDM, those are jobs to be done. Then a PLM has jobs to be done that aren't engineering jobs — quality, purchasing, other things. Then ERP includes manufacturing, POs, financials.

An engineer understands CAD and PDM very well: I need CAD to do my designs, I need PDM to lock them down, check in and check out, workflow, automation for drawings, PDFs, revisioning, sharing files.

But people in the conversation who aren't in that world don't know engineering systems. So if you're an IT director or a CIO, you come in and ask: can I consolidate? Can I get rid of PDM or PLM and just use CADTALK with ERP? Can I just use CAD with no PDM?

They all have different jobs to be done. There are some overlaps, which is what makes it confusing. CADTALK specializes in the integration — the intelligent needle that weaves the thread.

To have a digital thread, that thread has to go from CAD into some engineering system, PLM or PDM, into an ERP, and back again for changes. You have to connect them somehow. And there are many vendor combinations — SOLIDWORKS, Dassault products, Autodesk products, Siemens products, PTC products, and then all the various ERPs you can mix and match.

So people say: we need a PLM. Maybe because they want a quality module, or manufacturing steps, or process and quality documentation. They buy a PLM and assume it will be connected to their ERP — and they don't realize PLMs often aren't connected to ERPs at all.

Even with the biggest vendors. Multi-billion dollar companies run on SAP and Oracle, and aerospace and defense companies have a PLM plus SAP. But even something like Teamcenter connecting to SAP isn't connected out of the box. There's a framework you can use. Teamcenter builds one for SAP and for Oracle, but they don't build one for Infor, or Acumatica, or all the other ERPs a customer might have.

Scott: And it's difficult for them to do. There are too many.

So in the case where somebody bought a PLM specifically to make it easier to integrate to their ERP, and that's the only reason — then yes, there's a case where we could replace it, because we can work with the PDM, we can work directly with CAD. It depends what you're using the tool for.

But at the end of the day, if you bought the PLM, you still have to integrate it to the ERP. That still has to happen, because they don't integrate natively. Somebody is building that integration. The PLM vendor might have something for a select few ERPs where they see volume. If they don't, they come to somebody like us.

And the reason we can do it is that we integrate all the PLMs and PDMs and CADs with all the ERPs, so there's enough volume to sustain a business and keep those integrations alive. If you're Teamcenter or Windchill and you have to worry about 75 different ERPs, you're not going to do that, because you don't know which combinations will come up. Hence why there's a thing called CADTALK.

"Can I Just Build It Myself?"
Scott: I understand the IT perspective. Can I get rid of this thing, buy one thing, save money? Totally valid question to ask as an IT director. Unfortunately it isn't that simple — you never get away from paying for that piece.

Our biggest competitor is doing nothing. The next biggest is a custom integration, where somebody writes it for your application.

The value we add over that is this: the hard part of integration isn't only that the integration software has maintenance. It's that all the other systems you integrate to have maintenance going on, outside of your control.

So with CADTALK, we could have bugs we created ourselves. We also have to deal with bugs created by all the systems we integrate to. And those systems are being upgraded constantly — new version of SyteLine, new version of IFS, new version of SOLIDWORKS. We have to make sure everything works across those versions, and several versions back, because not everybody upgrades at the same time.

The beauty of an off-the-shelf integration is that we absorb the complexity of multiple systems changing and evolving at once. With a custom integration, you'd have to re-evaluate it on some cadence to make sure it keeps working.

We've seen this a lot. Customers write their own, and then they can't maintain it, because the person who wrote it wins the lottery or takes another job, and nobody knows how it works. Then they're locked into certain versions of the other systems. A lot of headaches.

Jeff: And the business changes too. Business requirements and business logic change — we talked about that with tariffs recently. When you've written your own, or even bought a custom integration from a vendor, you have real challenges adapting.

But to your point, it doesn't replace those systems, because the jobs to be done in PDM and PLM are specific and don't usually include integration.

Scott: Or they try to make integration easier, but they don't solve it.

The whole purpose of the ERP is to get things made, keep track of it, and handle the accounting. A lot of our competitors are worried about just getting the bill of materials across — a BOM import tool. We don't consider ourselves a BOM import tool. We're a tool to go from engineering intent to manufacturing execution. How do we get the engineer's design made?

Putting it in the ERP is table stakes. We have to get it into the ERP in a format where you can actually make the thing, because that's what manufacturers care about — making it so they can sell it and collect money. Importing a bill of materials is step five. Figuring out how to make the thing, and getting it into the ERP in a position where you can make money on it, is the complete job. That's the hard part, and that's the part we want to solve.

Is CADTALK Just an ETL Tool?
Scott: We've had this debate internally. There are lots of tools that do ETL — extract, transform, load. Is CADTALK just a standard ETL tool?

I'd argue it isn't. It's a very specialized, niche ETL. You get the benefit of not maintaining the integration, and you also get the best practices baked in about how to actually solve the problem. There's an enormous amount of flexibility, but there's also a way to do this that stays maintainable over time, because some fundamentals don't change.

Also, it's much easier to fully automate something from a code perspective. A lot of ETL tools assume there's no human interaction, and that's not a correct assumption for this problem. There's a lot of semi-automated work here, with decisions made along the way in the context of the design and the ERP. Depending on the situation there are more handoffs, so you have semi-automation and a user interface and a lot going on.

From a principle standpoint, yes, it's an ETL tool — but one designed around this problem. Part of the value is that we've figured out the gotchas people don't think about.

Here's something interesting about building a custom integration. Customers say, I can build that, because it's easy to write a program that does exactly what you want in that moment. The problem is that 90 percent of the time spent on software is maintaining it, not the 10 percent it took to build.

What happens is they say: right now we only do it like this. All the parts go on one bill, we never put them on multiple bills, every part is new. There's a hidden, baked-in rule about their process that gets embedded in the software they build. Then they forget the rule was ever there. They keep going, and then the business changes and they want to do something different — and everything they built that depended on that assumption breaks, and they don't know how to deal with it.

As a software vendor, we have to handle many different ways of doing things, and have the flexibility to adjust. That's the other benefit: you can change your process and still use the same tools. You may have to change configuration, but it isn't a complete rewrite.

Jeff: I don't know that I'd call it easy to build your own — easier than building a product, sure. But people build their own process intelligence into it in a way that isn't transferable to anyone else. It isn't a product. It's a unique thing done for them, maybe good enough, but it locks them into that process and that way of working. It makes it hard to adjust to market conditions and new ways of working. And it's brittle.

Scott: Even the software you're integrating to changes. We see customers taking advantage of a bug, or doing something atypical in the CAD that really helps the way they work — and then they upgrade and it isn't allowed anymore, or that thing isn't exposed. And the house of cards folds, because they depended on something atypical.

What we hope to bring is: here's the best practice we've seen.

Years ago I worked on ERP modifications, and customization — or personalization, whatever term you want — is an interesting subfield of development. You don't just have to make a change that works, which is table stakes. You have to make your modification resilient enough to survive the new version of the ERP.

In the old days people would buy the source code of the ERP, change it, and then be locked in forever, unable to upgrade. Over time they figured that out and swung the other way: we aren't making any changes, because then we can't upgrade. But then they can't make it their own and work for them.

What you see today is frameworks for modifying the ERP in a way that still lets you upgrade. But that takes developers who are focused on it. You could build the thing ten ways, and one of the constraints during the build is: will this work, and will it upgrade?

Like any engineering problem, it's a game of compromises. First it has to work. But I could make it faster, or easier to understand. When I did those modifications, the number one thing I optimized for was upgradability — which isn't something you worry about as much when you own the whole siloed system. When you're integrating, the question is: how do I build this so it just absorbs the change? The customer upgrades their ERP and our thing keeps working.

That's a different way of framing the problem. A lot of people make it work for today and forget about tomorrow, and tomorrow is where all the work is.

Jeff: It makes sense if you work at a company. You have a problem to solve, and you might not think long term — I just have to get this to last two or three years, I might not even be here. You may not worry about the future, because the consequences aren't yours.

For us, we have to live with the consequences, because if it doesn't work, they won't keep it. So it has to be upgradeable and handle upgrades to the ERP, the CAD, the PDM. Some of the partners we work with change their systems four times a year.

The Three Ways an Integration Can Behave on Upgrade
Scott: There's a hierarchy here, a kind of triage around upgradability.

The best case is that it just works. I upgrade my ERP, and the integration keeps working. From a design perspective — without getting too far in the weeds — a lot of that comes from asking the ERP what it has, and adjusting. CADTALK dynamically adjusts to what the ERP says about itself. I'm version two and now I have these fields, and CADTALK adjusts. That's a technique for future-proofing: instead of hard-coding for this version, ask the system what it has and deal with it. You build ERP modifications the same way.

If you can't do that, the second best is that it breaks loudly. I am broken, I no longer work. Do not pass go, do not collect $200. Because then you can test during your upgrade path, see it doesn't work, and fix it — and ideally it tells you where it broke.

The worst case is that you upgrade and it breaks silently. It does weird things, misses some data, doesn't do something quite right, and you don't detect it. Then six months or a year later you find out your costs have been wrong, or you haven't been accounting for something, and your margins were off. Those are really bad situations. People get sued over that. And if you listened to our episode on data being the asset, that's extremely bad.

So optimizing for upgradability in that order is a good way to think about it. I want it to just work. I'll accept it breaking loudly. I don't want number three, where it breaks silently.

That's the other thing we see with custom integrations. It breaks silently — oh, that thing was supposed to be there, it's not, that's okay, we'll skip it. Nobody notices for six months, and then there's a write-off.

How Integration Differs Across CAD, PDM, and PLM
Jeff: Are these systems different from an integration standpoint? Does integrating to CAD work differently than a PDM or a PLM?

Scott: Mostly you just have more to work with. At the end of the day, it's parts and bills of materials. We're not reinventing anything.

On the PLM side you have more data. If you're using M-BOMs you have concepts you don't officially see in CAD — some things with operations, for example. PLM tends to bring things closer to an M-BOM than CAD does. So there's extra, but it's still parts and bills of materials. It's engineering data, starting from the same place. You're not designing something new in a PLM. You design in CAD, it goes to PLM, and that's another step where you augment the data.

As far as integrating goes, the question is where you're pointing and where the source data is. From a PDM perspective it's easier, because you don't have to figure out where the files are in the directories. With CAD directly you have to find the thing, make sure all the files are where they're supposed to be and linked correctly, and there's complexity there. With a PDM you just query and get it, like a database.

There are nuances at each level, but at the end of the day it's source data. It all comes from the engineering design, just at different iterations.

Jeff: The way I think about it is that the data gets enriched as it moves.

You start in CAD — that's the foundation. Parts, structure, and some data about that structure: part numbers, quantities, descriptions. The basics.

Then in PDM you usually get a workflow system, revisioning, additional information. Maybe a materials list. Who last modified this, who has it checked out.

Then you can check that data into a PLM and enrich it further — quality data, suppliers, operations. Some PLMs have a manufacturing or operations side. Supplier lists. Documents, both drawings and specification or material sheets. You keep piling it on.

From there, depending on how much data you have, that data set or some portion of it goes to the ERP. But along the way you need an integration at every step.

With CAD and PDM, because they're bundled, that integration is usually already there. From CAD or PDM into PLM, an integration has to happen — the vendor may provide it if you bought from the same vendor, but if it's a different vendor you need another step. Then in the PLM you enrich further with suppliers, documents, workflow. And then you say, now I have cleaner, more regularized data, and I take all or a subset of it over to the ERP.

And the ERP has its own data. Even if you have operations, routings and suppliers in the PLM, you have the same things in the ERP. They're going to buy out of the ERP, cut a PO, track the cost, invoice from there. So you have to decide where that data lives and who manages it.

Buildings and Streets
Scott: Exactly. People think about the systems rather than what's between them. They think about the buildings instead of the roads between the buildings. How do I get from this building to that one? I cross the street, or I go through a tunnel. And they abstract away the street and the tunnel and ask whether you're replacing the building. And I say no — we are the street. We are the tunnel.

Here's an interesting thing I heard: in Japan they don't name streets, they name blocks. Why would you name an empty space? There's nothing there, it's a street.

People think about these systems the same way. The thing that connects the systems is just nothing. All I care about is PDM, CAD, ERP. But there are streets that connect them, a communication layer, the thread. We're the streets, not the blocks.

Jeff: I think of us a bit like plumbing. And to your point, PDM and CAD are one building, PLM is its own building, ERP is its own building — and you still have to get the stuff from each building into the next. Somebody has to carry it, and sometimes you have to rearrange it for the new building.

That's an interesting analogy. I'm moving from this building to the new one. I have to rearrange the furniture, put things in different places, get more furniture, put more pictures on the wall. Then take it all down and carry it over and put it up again. This one has more space and more areas, so I have to fill it in. Somebody has to do that.

That's why we exist. It doesn't happen naturally. It's natural to assume it just happens — and it does happen, with a product, because something does that part.

Like plumbing. When people buy their first house and have a problem with their lines, they understand they have plumbing in the house and have to take care of it. But they don't realize until there's a problem that they're also responsible for the plumbing in their yard, all the way out to the street. And if you're building a house, part of the construction is figuring out how to get water and sewage into it. Somebody is responsible for that.

Scott: People buy land and say they'll build a house there. And then: well, the city water main is three miles away. Will you bring the line to me? No. And by the way, there's no sewage either. So you're digging a well, pumping your own water, building a cistern, putting in a septic tank. All of that changes, because you don't realize the connection to the system is something you have to solve.

It's the same type of thing. A traditional response from a lot of vendors is that they can't control the complexity of all the other systems. They have no control over which ERP you have. So if you say you want to integrate to your ERP, they say: I can sell you this other thing that makes it easier to integrate. But they don't package it that way — it's "you can integrate if you have PLM." What they're doing is making the data look closer to what the ERP expects. You still have to get it into the ERP, which they aren't solving in most cases.

Same thing with nesting integration, which I worked in. They'd say, we have our ERP integration module — and you'd think, great, it's solved. No. It just gets the data into a format that makes it easier for somebody to write a custom integration.

Nobody is in the business of figuring out how to integrate to 50 things. Zapier does that for simpler systems, and some products integrate to the most common things. But with ERPs, just learning the system well enough to integrate to it is a project. It isn't like a CRM where you're creating a customer record and the concept is the same everywhere. These systems have idiosyncrasies. They're complex.

So vendors aren't in that business. They say they have an integration, and what they have is a way for you to integrate. They dump a file, they populate a table, they do something that lets you — and then there's a hand-wave — integrate it to your system.

What we do is connect to them already. The APIs are built, everything is pre-built, the data is already flowing. It isn't a framework to use, it's an actual thing that moves data from day one.

Jeff: It's the equivalent of the customer saying, I need a hole, and the vendor saying, cool, here's a shovel. We say, hole's done.

Scott: Right. Back to the drill. I need holes, and somebody hands you a drill. The vendor is giving you a drill. They aren't giving you the holes. Our job is to complete the job, which is creating the hole.

And that's nothing against the people selling those systems. They want to sell systems, and if you ask them to solve your problem, everything looks like a hammer. Oh, you need a PLM. You need the thing that makes it easier to do the thing you want to do. They aren't getting you to the thing you want. They're getting you closer, and getting you closer lets them sell something. So look at the incentives.

Best of Breed, Tied Together
Jeff: At the end of the day, we're not here to replace those systems. We're here to tie them together so each customer can use best of breed — the engineering system they want, the PLM they want, the ERP they want — and connect them.

It used to be big monolithic systems: I'm an ERP and I do everything, the everything app. The trend now is toward using each vendor for what it's best at and integrating them, so you get the best of all worlds without compromising. You can't get everything you want from one system, because there are different jobs to be done. It's hard to do multiple things really well. You can do a lot of things adequately, or a few things extremely well.

Unfortunately I won't be able to tell CTOs, CIOs and IT directors anytime soon that they can get rid of their engineering systems. You won't get rid of CAD, PDM, PLM or ERP. The key is making them all work for you, getting the value out of each one for what it does best, and then integrating them — and leveraging them in the best way possible.

It won't change the IT budget, but each of those has unique needs for a manufacturing and engineering company.

Scott: Absolutely.

Jeff: That analogy of roads, or pipes, is a good one. These systems are buildings, but they need to be connected, and that's what we do.

Good talking to you. We'll have another one next week — I don't know whether we have a guest coming up, but either way, I look forward to it.