S2, E14: Transform Instead of Link: CADTALK’s History and Philosophy

Transform, Don't Link: How CADTALK's Integration Philosophy Evolved (S2 E14)
The Integrate Intelligently Podcast, Season 2, Episode 14 — with Jeff Brickler and Scott Brickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Brickler. Today Scott and I are talking about some history — the evolution of the CADTALK product, how we see integration, and how Scott figured out how to do integrations in the first place, and why he chose to do it the way he did.

Scott: This stemmed from an internal discussion. We have a lot of new team members, and we have the Elmo acquisition, and the Agni Link product works a certain way while CADTALK works a different way, and other products on the market work differently again.

We get asked a lot how we're different, and I want to set the record straight. A lot of it comes from decisions I made back in the early days of the product, so it's worth talking about why we did it the way we did.

Today is a bit more of a presentation. This is a revised version of what we did internally to educate the team, explaining how the product evolved and why we're not just an import tool.

Jeff: What's interesting is that we've looked at a lot of the solutions out there — competitors, tools in different countries, even PLM integrations — and with the exception of us, everyone seems to approach the problem the same way. So this is a good discussion, not just about what makes CADTALK different, but about why you made those decisions in the first place.

Scott: For anyone on audio, I'll describe the slides as we go. If you're on YouTube you can see them.

Table Stakes vs. the Actual Job
Scott: Why does this story matter? Because we position ourselves as an intelligence engine, not an import tool. On the surface we get compared to other tools that seem very similar — they solve the same problem. But where they stop, CADTALK goes much further. What a lot of our competitors do, we consider table stakes. It's what you need to do to solve the problem at all.

When we first built the tool, nobody even understood why they'd want the table stakes thing. Let's link these together, copy data back and forth, save on data entry. That was genuinely hard to sell people on in the 2005 to 2008 time frame. Now people get it.

But you have to take the problem further and ask what the real job to be done is. It isn't just getting the thing imported into the ERP. That's where a lot of other tools stop — they get it into the ERP and save you those keystrokes. That is not the entire job. It's a small fraction of it.

Jeff: There are many jobs to be done in integration. Importing the data, syncing it, linking it, copying it — that's the beginning of the journey. You have to get the data in there. But beyond that there's much more work in the whole manufacturing process, the whole data enrichment process. It's more than copying data out of CAD or PLM into ERP.

The Linking Model, and Why It's Intuitive
Scott: Most tools work on this linking model, where you're linking CAD to ERP, or PDM to ERP.

The very first version of CADTALK worked that way. I built it that way. I think the first customer was a progress-based SyteLine system with Solid Edge — which is interesting, we don't see much Solid Edge anymore, but it's still out there. It worked inside the CAD, as an engineering tool, with this syncing idea where you take data from here and sync it there and back. It's just a link. Essentially an import tool.

And that's the most intuitive way to look at it if you're new to the problem. When I was in engineering I thought: why am I taking drawings that an engineer printed out of an engineering system and retyping them into an ERP? It's all electronic. It started electronic. Why am I going to paper and back to electronic? Why can't I save those keystrokes?

That's true, but it's a very engineering perspective. A lot of the tools out there, including Agni Link, which we acquired, come from the engineer's perspective of the problem.

At smaller companies especially, the engineer has to type that data in, and they hate it, and it's a poor use of their time. Bigger companies tend to have manufacturing engineers, which is more where I came from. But it's still a lousy job, particularly if you're the design engineer, because you're not adding value. You're putting the data in as you built it and hoping somebody else deals with it afterward.

If you're a manufacturing engineer, you're probably adding more value — routings and other useful data. There's actually value added during the transfer. But most of the tools out there are just trying to get the task off the engineer's plate, because they have the engineer's view of the problem: I have to do this, it sucks, please import it for me.

Jeff: You see it with PLM systems too. You're getting data from CAD and other places and enriching it, and you still have to get it to ERP if you're a manufacturer. Not every company with a PLM manufactures — they might use contract manufacturers. But either way the data has to get into the ERP, and there's this idea that you're just syncing it. That the data is the same, and you just populate it over there with no other work needed.

Scott: All that does is automate the silo.

You have the engineering silo and the manufacturing silo, and people talk about throwing things over the wall. All an import tool does is make it easier to throw it over the wall and make it somebody else's problem.

If you can't make the thing, you didn't solve the problem. You didn't get the job done. The whole purpose of a manufacturing company is to make things to sell to customers to collect money. If all you did was make it so the engineer didn't have to type, you solved his problem. You didn't solve the manufacturer's problem, which is getting it out of the engineer's head and into a good I can sell and make money on.

To get it made, somebody has to figure out who we're going to buy it from, how much it will cost, and what we need to do with it if we're manufacturing it. All of those things have to happen. The manufacturing organization figures them out so the thing can be made and sold.

The example I used internally: until we figure out how to create antimatter replicators like in Star Trek, where you take the idea you have and it materializes, somebody has to figure out how to make the darn thing. That's what the ERP does. Until then, an import tool is just throwing it over the wall for somebody else to figure out. CADTALK is trying to do more of that figuring out for you. That's the differentiation.

E-BOM and M-BOM Are Not the Same Thing
Jeff: What I see talking to customers is exactly that. The initial idea is: I need to get the data in there. They don't think about the fact that if you sync the data as it exists in engineering, that isn't always how you need it in manufacturing.

I've seen it many times — in manufacturing you need to change the structure of the bill. You may need to flatten it. Move things to different operations. Enrich it further. The structure can change quite a bit coming out of engineering.

I had a customer say: yes, we could import it, but once it was imported I'd basically have to delete everything and rebuild it, because it wasn't in the format I needed. We don't make it like that.

Scott: Right, and that's what this slide says — linking assumes CAD and ERP are symmetric. We have an engineering bill of materials and a manufacturing bill of materials, and the assumption is that they're the same thing, because the only way you can sync is to assume you're talking about the same thing.

A lot of the time the M-BOM and the E-BOM are not the same, by definition. Why would you have different names for them if they were the same thing?

So the syncing idea falls apart, because things like raw materials and routings aren't in CAD, and linking forces this symmetry. People say, well, I can't really do routings because I don't have routings in my CAD. Why do they have to be there? Why can't we derive them? We derive them when we do it manually — there's a manufacturing engineer figuring it out based on what's already in the model.

But if you say they have to be linked, then you're duplicating data in both places. And the engineer doesn't care how you make it. By the time he's designed it, he's decided. You really want that decision made while he's designing, not after.

The M-BOM is what drives the thing to get completed. The M-BOM is what the ERP needs.

Now, if you're a very simple manufacturer and the M-BOM and E-BOM are nearly identical, that's an easy case. Maybe you just need an import tool, and maybe we aren't a fit. That's fine. But generally, if you have an ERP, you're doing something more complex than printing a bill of materials — in that case, just print the drawing and tell the shop to make it. You don't need an ERP. If you have an ERP, you have some sophistication about how you make the thing, so you probably have some difference between an M-BOM and an E-BOM. Our job is to transform the E-BOM into the M-BOM, not to put the E-BOM in the ERP and say good luck.

"I Don't Keep Routings in My Model"
Jeff: When I'm educating the sales team, I'll say you can create routings in CADTALK, and the common objection is: I don't keep routings in my model. And I say, right — but do you use routings? Well, I don't know. Somebody in your organization uses routings, don't they? Let's get them on the call. And yes, we use routings.

Then I walk through it: how do you know what the routings are? Well, I look at the drawing.

Scott: So you derive them. You figure them out from what the drawing says. What a concept — you're deriving it from the design. You're transforming engineering intent into manufacturing execution.

People don't realize that. They think: I see it over here, and then somebody figures that out. And the question is, couldn't we help them figure that out?

So everybody thinks the job is this small thing, and the job is actually this much bigger thing. If you compare tools by asking "does this do the job for me," and both say yes, and the second one costs more — why? Because it does all of this. That's differentiation. You're not comparing the same thing.

The Breakthrough: Raw Material
Jeff: You built it the intuitive way first — copy the data, link them together. What made you think about it differently?

Scott: The raw material problem is what clued me in. It gave me the idea that this was really a transformation. I don't think I even knew the terms E-BOM or M-BOM back then; I'm not sure they existed for me.

Raw material in a CAD system is usually just a property on the design. But in an ERP, if you're making something, the raw material is a subcomponent. You're making the thing out of the raw material, and you usually have a routing. Take a saw: you cut the raw material at the saw, drill some holes at a vertical mill, and it becomes a part. Or you cut it with a laser. Something happens.

The way you model that in ERP is with a subcomponent and a quantity. To do that, you couldn't just take the property and make a subpart out of it — you're transforming it. A bill of materials on an engineering drawing doesn't show raw material. It's an attribute. You have to transform it into a completely different thing on its own bill.

And then how do you link that? If I change that part on the bill, what CAD file am I updating? There's nothing there to work with.

So syncing became hard, because to solve more of the problem — the transformation — you broke the link.

What Do You Actually Want to Link?
Scott: This is the controversial part. Everybody says it should be linked, and that seems correct. But the linking is the problem.

Ask people what they want to link and they say quantity, description, part numbers. Anything else? No.

Then: if the description changes, we'll write it back. And I ask, why are you changing the description? Well, we like our description better. Does it matter? Yes. Then why isn't it going back to engineering as an engineering change? Well, it's just a description. It either matters or it doesn't. You can't have it both ways.

A lot of engineers say: if you change something in my design, you're changing my intent. So we should link, because I don't want you changing my intent. But they change the intent all the time. They dump their intent over here, and then it gets changed for the manufacturing process.

You're not changing the intent by creating the M-BOM. You're describing how you're going to execute their intent, which isn't described in their model, at least not directly.

So linking breaks down because you're assuming apples to apples, and it's apples and oranges. I think of it more as a derivative — to use calculus. The manufacturing BOM is a derivative of the engineering BOM. It has elements that are similar, but it has more.

That's why internally we don't even like the terms linking or mapping. We use transformation, because it describes what's actually happening. You're transforming engineering data into something that enables production. Engineering intent into manufacturing execution.

So to answer your question: it became really hard to make linking work and do the whole job. So we said, don't do that. Do we have solutions for the problems people worry about? Yes. But that's where the evolution came from — let's not link it, let's make it a transformation.

Data That Was Never in the CAD
Jeff: Raw material was one attribute, routing steps another, and now we handle documents, steps, revisions, and all kinds of other data beyond the CAD structure. That seems even more relevant now than when you started, because there's so much that isn't in the CAD model.

Scott: And it shouldn't be. If it has no value to the engineer and doesn't need to be on the drawing, there's no reason to put it there.

Product codes are the example. People ask how they set the product code in the ERP if it isn't in the CAD. Why would you put a product code in the CAD? You're asking the engineer to enter things they know nothing about. They weren't going to put a product code in before. It has no effect on the design. It's something the ERP needs.

All you need is a way to figure out what the product code is based on what they've already done. Somebody knows that. If somebody does it by hand, they look and say, this is such and such a thing, so it's product code two. They figured it out without the product code being in the drawing. Why can't the software do that?

And right there you've broken the link, because there aren't both sides. There's no CAD equivalent of a product code. Nobody in engineering cares what a product code is.

A lot of the time engineers don't even care whether something is manufactured or purchased. They care that they need this part made out of this material. You could argue whether they should care — if you're doing true manufacturing engineering, you'd work with the engineer during the design phase and design for manufacturing, which previews what we'll talk about later. But that's how you solve that problem, not by syncing something. Syncing is just a data issue. It doesn't solve the engineering problem. It makes you feel good because they're linked, but it doesn't really do anything.

I know that's a hard stance, and it's probably controversial — plenty of people would argue with me, especially engineers, because we have opinions. But really think about why it matters. I've had this discussion many times and it's hard to make the case. It's one of those things that feels like it should be right, but doesn't actually make sense.

So CADTALK isn't a syncing tool, it's a transformation engine, and it handles this complexity.

Why We Came at It Differently
Scott: The reason we're different from the other tools is that I worked all of these jobs. I worked as a manufacturing engineer. I worked on the ERP side. I worked as a design engineer. Most of the other tools come from engineers who design things and want it off their plate.

When you've lived in all those worlds, you understand the challenges in each. It isn't a silo anymore. Sometimes we'll look at a problem and say: yes, this is a little more work for the engineer, but it saves ten times the work downstream. A lot of other tools are trying to save the engineer ten minutes, and they don't care if it creates three hours downstream. That's what happens when you look at silos. You need to look at the whole process.

Jeff: Like a knock-on effect. You make a change here that seems reasonable, and over there it causes problems you didn't think about.

Scott: You see that in systems theory. A series of good micro decisions leads to a bad macro result.

You see it in nesting. You nest a part a certain way, then the most efficient placement for the next one gives you a crooked nest that creates a big remnant at the end. If you looked holistically first, you'd straighten that part — slightly less utilization on that piece, but more symmetrical for the next part.

Same in process. If you optimize for what the engineer has to do, you'll compromise what's downstream.

Another example from design for manufacturing: people want parts to be cheaper, so they optimize every part and end up using six or ten different raw materials in one assembly. Each part is cheaper, which is a good micro decision. But all the parts are made on a laser. If I use seven different materials, I have to change out seven sheets to make one assembly, ship the thing, and make money. If I say I might be slightly over-engineering it and make everything out of seven gauge, or everything out of quarter inch, now I have two material changes. I get the assembly created, put together, sold, and the money collected faster.

Optimizing on lead time saved more money than optimizing on material. Standardizing on those things can do a lot for you as a manufacturer. Same with thinking about this process — think about the macro, the whole thing you're trying to accomplish, not just saving the engineer some keystrokes. That's table stakes, and honestly it isn't that interesting, because you're not solving the real problem.

Market Confusion and How It Shows Up in Sales
Scott: So there's market confusion. The market sometimes sees us as a fancier linking tool, when we're solving a much bigger problem. We solve a deeper problem with a smarter architecture. You see a lot of this on the sales side, don't you?

Jeff: I do. Every product comes from a problem somebody is trying to solve. Customers don't care about your product. They have problems they need solved, and they want a tool that solves them.

So first the customer has to be problem-aware. And the first problem they're aware of is that a person has to do the work. Engineers can be tough people — I don't want to do this work, I don't want to be in the ERP, I don't want to be in the PLM, I just want to do my CAD. So they raise their hand: I have a problem, I don't want to enter this data.

And they're right. It isn't valuable to have them typing things manually.

So what we typically get, on nine out of ten calls, is: I'm trying to save time and reduce manual entry. That's what comes to that person first. But if you're an engineer, you're not thinking about what the data needs to look like at the other end.

When my team is on a sales call, you need to invite more than the engineering team. You need downstream people, because it affects them. Then the scope broadens. We're not just solving an engineer's problem — we're solving the whole problem, from design all the way to a fully manufactured BOM.

So people come to us with one problem, and you have to ask: what's the real problem? Can we get people downstream into this conversation? Even if I get that data in there, what else has to happen before you can release it to the shop floor? Once you see all of that, you realize there's a bigger problem and more jobs to be done.

Scott: People optimize for what they know about, and that isn't their fault.

We actually have different workflows we can enable. There are cases where the engineer doesn't have to be involved at all — we can read the CAD data directly, without the CAD system. The assumption that this has to live in a CAD system is another area where we're different. We don't require it. We can read the data directly from the files.

Just because an engineer designed it doesn't mean it has to be an engineer's tool. You have to figure out how to get their intent into something you can make. There are lots of ways to get there, depending on who best knows what should happen. In some cases it can be fully automated — it runs on a server somewhere and just happens, assuming we can figure everything out from the design.

Jeff: The first step on the ladder is eliminating manual entry. Okay — does that solve the whole problem? If you ask, you'll hear that it solves the main problem but not the whole problem. And then: what's the whole problem? Well, I need to add routings. Raw materials. Paint and outside processes. All these other aspects, after the fact.

People don't even consider that those could be done too. All they can think about is getting it over there so they can do something with it. The idea that you could automate large portions of it, or figure things out the way a person would using AI and other tools, isn't something people considered in the past.

A Preview: Design for Manufacturing
Scott: We're short on time, but I want to raise one more concept. We have a tool called design for manufacturing, which is a different way of looking at this.

A lot of syncing arguments come from part numbers and raw material part numbers. And a lot of what forces tools to live inside the CAD is that syncing requires write access to the CAD models or the PDM. The file has to be checked out. There's all this rigmarole, because you need access to edit it.

The question is: why are we doing that at the moment we bring the data over? Should that be determined earlier?

So we have a tool that sits inside the CAD, called DFM, that lets you put this data into the model to prepare it to be imported. People can issue part numbers from the ERP, or pick the raw material from the ERP, during the design stage. It populates the model so it's ready to come into the ERP later — instead of syncing back and forth afterward.

We issue the numbers up front. We pick the raw material up front. It makes it easy for the engineer to make good decisions during design, which prevents most of the syncing problem people are trying to solve.

Jeff: We'll go into more detail on DFM in a future episode, since we're short on time today.

Thanks, Scott — good conversation for understanding the thought process behind transformations in integration. I look forward to talking about design for manufacturing next time, and helping people think about the whole process, not just getting data into the target system.