S2, Ep 1: The Future of CAD-ERP Integration: CADTALK Acquires Elmo Solution

Why CADTALK Acquired Elmo Solutions: Two Approaches to CAD-to-ERP Integration (Season 2, Episode 1)
The Integrate Intelligently Podcast, Season 2, Episode 1 — with Jeff Brickler and Scott Brickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Brickler, joined again by my brother, Scott Brickler, founder and CEO of CADTALK Software. Some exciting news to announce today — and good to see you after a fair bit of travel for both of us.

Scott: Nine days straight, got back last night. Long trip, and it actually started in Quebec, which leads right into today's conversation.

Jeff: I was out on the West Coast myself, eight or ten days, and more than ready to get back to my own bed. So — today we're talking about the future of CAD and engineering integration with ERP, and we have some outstanding news. Do you want to tell listeners what that news is?

The Acquisition: CADTALK and Elmo Solutions
Scott: Happy to. After a good deal of work, negotiation, and process, CADTALK is announcing that we've acquired a competitor in the CAD/PDM/PLM-to-ERP integration space: Elmo Solutions. CADTALK and Elmo are now one organization, under the CADTALK brand.

Jeff: What are your thoughts, having just completed it?

Scott: It's a genuinely cool step in the direction we've been aiming. We want to be the leading integration solution for this problem in the market, and the way you get there is by expanding into more and more systems. Elmo and the Agni Link product are very complementary to what we do, and they have a similar philosophy about how they go to market — so it was a natural fit. We actually didn't run into each other much in sales situations, because they were in different ERPs and different systems. Coming together broadens our base of CAD, ERP, and PLM integrations, which is really how we grow.

Jeff: Worth stepping back for a second on who CADTALK is. CADTALK is a leader in integration between engineering software and the leading ERP systems — we have six or eight ERPs we integrate with. Elmo Solutions, which produces Agni Link, had roughly six or eight of their own. So we've meaningfully broadened the offering and increased the footprint of customers we can serve.

Expanded Integration Capabilities
Scott: To clarify the terminology — when we say "systems," the total number of integrations across both companies is probably 30 or 40 at this stage. But ERP is the driver for growth, because if you don't have both sides of the integration, most customers aren't interested. Between the two companies we now have essentially all the CAD systems, PDMs, and PLMs covered. ERP was the side that really drives expansion.

Jeff: If you look at all the combinations — permutations, technically — it's dozens, maybe hundreds, once you account for the fact that the target side is almost always ERP and the source side can be any number of things. A tremendous number of combinations customers can use to integrate their systems.

Scott: And Agni Link solves the problem a little differently than we do. We've traditionally approached it from the ERP perspective. I'm an engineer by training, and I worked with CAD systems and PDMs, but most of my experience was in the ERP world — which has served us well, because that's where the data ends up. We have to turn engineering intent into manufacturing execution, and that execution typically lives in a PLM or an ERP.

The Agni Link product is more engineering-focused. That's not to say we were weak there, but they come at it from a different perspective, and that's genuinely useful. There are customers who have exactly that need. It widens our ability to serve customers the way they want to be served.

Two Perspectives on the Same Problem
Scott: Our integration can work inside the CAD tool or standalone — it can be a pull from the engineer's work, or a push from the engineer. With Agni Link you see more focus on synchronization, keeping both systems in step, which isn't something we've emphasized heavily in the past. Having both perspectives is really good. One way isn't right and the other wrong; it depends on your needs and how you approach the problem.

Jeff: CADTALK was founded on your idea, working in manufacturing with an ERP mindset. Elmo Solutions and Agni Link have been around even longer — thirty-plus years. So you can come at this from one of two directions: from the ERP side, where you need quality data for manufacturing, finance, and the shop floor; or from the engineering side, where you don't want to do the work.

I always think about what our customers' pain points are, and you can usually tell who came up with a solution. If you're the ERP person, you were dealing with the downstream effects — data got dumped on your plate, thrown over the wall, and suddenly it's your problem. That was your experience. The other perspective is the company where engineers are tasked with entering the data themselves, and typically engineers want no part of ERP. I imagine the Agni Link founder either had to do that himself or was working with engineers saying, "I didn't go to university to learn design so I could manually key data into an ERP system."

Different perspectives, same pain point — but the driver for solving it was slightly different. And they complement each other.

Scott: Perspective shapes the solution. The problem is still the problem; the perspective shapes how you solve it. And different markets have genuinely different needs. I came from upper-mid-market ERP, usually larger companies with a manufacturing engineering function. I worked as a manufacturing engineer and as a design engineer, but the idea for CADTALK came from my time as a manufacturing engineer. Interestingly, early versions of CADTALK had more of the perspective Agni Link has — this idea of linking things together — before we moved toward transformation.

There's a lot we can learn from each other, and I'm excited about that. I'm a product and development guy originally, so I'm genuinely looking forward to seeing how somebody else solved the same problem I've been working on for 25 years. As an engineer you tend to hold strong opinions about how things should be done, and this has been a good reminder that yours is just one perspective. Maybe it's because I'm pushing 50, but I've come to really embrace strong beliefs, loosely held. You need a strong belief so you can guide customers in the right direction, but you have to stay open enough to learn something you hadn't thought of. Otherwise you can be blind to the customer, because you assume you already know.

Different Markets, Different Needs
Jeff: It's a great opportunity to learn from the collective knowledge of the combined team. We have thousands of customers using CADTALK across six continents, and Agni Link has customers all over the world too. Engineers in Europe and in other parts of the world see things differently — both where things are similar and where they diverge.

Scott: It's the same question as ERP generally. How do SAP and NetSuite and QuickBooks all exist and succeed simultaneously? Because not all companies have the same needs. QuickBooks serves a lot of companies at a certain scale. At the top end, the complexity of the companies being served is completely different, and the flexibility to handle that complexity carries overhead. People think, "I paid a million dollars for SAP, creating an invoice should be easier" — and it's actually ten times harder, because an invoice there might involve fifteen variables. QuickBooks assumes that complexity away, which lets it be simpler and faster for a different market. Same with CADTALK and Agni Link: there are markets that genuinely benefit from different approaches to the same problem.

Jeff: We see it in the integrations themselves. Some are less complex than others, because the target system is less complex — fewer places to integrate, fewer objects to connect to. And even within ERP, brands offer different products for different markets. Some ERPs are better for discrete manufacturing, others for process manufacturing. A bill of materials for a food and beverage manufacturer still has ingredients, but how you go about it differs from discrete.

Scott: It goes back to what you're optimizing for. The developers used to tease me for saying it like a broken record — someone would ask whether we should do this or that, and the answer was always "it depends what you're optimizing for." A large company with a lot of resources might optimize for data accuracy and the ability to handle variability. A small, lean shop optimizes for speed. How many orders do you get a day? A hundred is a very different business than ten thousand.

If you're selling into a company like Procter & Gamble, you have to submit through EDI — you don't email orders to those guys, because they receive so many that manual entry isn't viable. So EDI support is a hard requirement there. For a furniture maker doing a hundred orders a day, it's overhead they don't need. Everything has its place. And a product that tries to do too many things tends to be mediocre at all of them.

Jeff: Stay in your lane, focus on what you can really deliver, and do it well. A hammer is great for nails, less so for screws. You can do it, but you'll work hard and break a lot of screws.

Why Buy Instead of Build?
Jeff: We've built so many integrations ourselves. Why acquire rather than just build them all from scratch?

Scott: It comes back to a design philosophy I hold: every feature starts with negative value. Even an integration, even one we've done before. And there's the "great rewrite" that every developer tries to avoid.

What you get through acquisition is the collective knowledge already built into a system that's been running with real customers. Instead of relearning those lessons and shipping a less-than-ideal product for a period of time, we acquired those years of experience — embedded in the codebase and in the people who built it. Literally overnight, we're serving customers in markets where the product is proven and established. That's difficult to do from scratch.

It comes with its own challenges, of course. Now there are two products, some redundancy, decisions to work through. But ultimately it gives customers a better solution and lets us go to market faster without repeating bumps that have already been figured out.

Jeff: When I started at CADTALK ten years ago this year, there were a lot of lessons to learn just implementing a customer. You might have all the features and functionality, but you still have to learn what's specific about each ERP — how people deal with particular scenarios given a given system's design choices. In some ERPs you update a bill of materials and simply flag a different revision; you overwrite a field, and there's no history. You don't know that until you dig in. And in our business, revisioning and change are exactly what matter. Those nuances are already part of the acquired product.

Every Feature Starts With Negative Value
Scott: Let me finish the thought about features starting with negative value. On day one, all you have is the cost it took to build. And it's not just the build cost — it's the disruption to the customer, who now has a new thing to deal with. So everything you put into a product has to clear a real ROI bar, because it can actively get in the way.

I've seen it with ERPs I've worked with. One version was fast and let you do genuinely cool things; two versions later it had slowed down and become harder to work with — all in the name of improvement. Were there more features? Yes. But the daily experience of using the product deteriorated.

I was listening to Alex Hormozi recently, and he made a point I found fascinating: when you're constantly introducing improvements to a team, the improvement itself costs you. His rule of thumb was that a change should be worth 20, 30, 40 percent, not five, because the disruption alone will drop your team's efficiency by something like 20 percent while they relearn. Sometimes things improve by being left alone — people find their own faster way if you stop changing what's under them.

Jeff: Same with product. Sometimes the best thing you can do is make it a little faster, or do nothing and let people get comfortable. If you're constantly changing things, the time the tool was supposed to save gets eaten by relearning it every other week.

Scott: There's a balance, because customers paying every year should see improvement. But people really underestimate the value of a thing that reliably works every day. Think about the old green-screen AS/400 systems — you'll still find manufacturers running them. No point and click, everything on the keyboard. I'd ask people why they stayed on them so long, and the answer was always: it never goes down, and once you learn the keystrokes you can move incredibly fast, because your hands never leave the keyboard.

The learning curve was steep, but the reliability was high and the ceiling was high. We changed those systems to make them easier to pick up, and then people were slow forever. Which is better depends on your situation — if you have high turnover, you want the thing that's easy to learn. It always comes back to what you're optimizing for.

Jeff: That reminds me of the first house I bought. The furnace was an old Millan gravity-fed gas furnace, no blower, just a big burner — probably fifty, sixty, seventy years old. I asked why nobody had replaced it, and the answer, maybe from our dad, was: the thing never breaks. It's simple. Basically a controlled fire in a fire box with a pilot light. Not efficient, took forever to heat up, but it always worked. Replace it with a modern furnace and you get electronics and zoning and air conditioning — real value — but you've also bought real complexity.

Simplicity in Design: A Robotics Story
Scott: That reminds me of something. Back in high school, what got me interested in engineering was the US FIRST robotics competition — this was 1994. Procter & Gamble sponsored two teams in Cincinnati: mine, from Aiken, and Walnut Hills, the smart kids' school, where you went.

The challenge involved collecting colored soccer balls and scoring them in a goal. Our machine was like a tank — it drove over the balls, ran them up a chute, sorted our color to the front and the opponents' to the back, so we could hoard theirs and keep them out of play. Then in the last ten seconds we'd drive to the goal, raise a forklift-style lift on cables, lean over the top, block the goal, and drop our balls in. We were killing everybody. The thing was so fast it would pop a wheelie and smoke the carpet.

The other P&G team, Walnut Hills, built something slow. It crept around, picked up one ball at a time, queued them in a little chute, drove to the edge of the goal, and a spring-loaded cam tipped each one in. Perfect, every time. We drove circles around them.

We got to the final rounds as the favorite. Up against Walnut Hills, we did all our tricks, ran up to score at the end — and the line on the pulley jumped the track and locked up, about that far from scoring. We lost. Came in fifth in the country. They went on to win the whole thing.

We improved the design afterward, got rid of the pulley, used different materials, and beat them every time in local exhibitions. But not the time that mattered.

That's simplicity of design in action. Their machine didn't do much, but what it did, it did perfectly. The same applies to software. It's fun to build the thing that does everything, and when it works it's impressive — but sometimes the line jumps the track.

Jeff: And you learned from it and changed the design. Which ties back to the acquisition: you're leveraging someone else's learnings. Software design is iterative, and every pass teaches you something. It also reflects CADTALK's philosophy, and I think Agni Link's too — one of the reasons we bought them. Those hard-fought lessons go back into the product, over and over.

Scott: Start simple. Simple scales.

Jeff: What's strange, looking back from middle age, is that you don't recognize those moments at the time. You don't know it's part of your origin story.

What Changes for Customers
Jeff: So what's next? Does anything change for our customers, our partners, or Elmo's customers and partners? Will people get a different product?

Scott: In the short term, it's the same great product you're used to. Over time we have plans to take the best of both and bring them together, but there will be a transition, and it won't happen overnight. Our first priority is keeping customers running, happy, and getting value. Anything we do too quickly is disruption — we don't want to wreak havoc. The plan is only to improve what we do, not detract from it.

Jeff: And we'll gain knowledge in both directions. What we've learned can help Elmo's customers, and what they've learned can help ours. It's like traveling abroad — you get a new perspective and bring it home. Over time we can take the best ideas from both products and merge them, or keep them separate. That depends on what we find as we go. The acquisition is still new; we're getting to know the customers and the staff.

What's Next for CAD-to-ERP Integration
Jeff: Anything else you'd like to share about where you see the product going?

Scott: Nothing I want to give away on the podcast. But I'll tease that there are some genuinely exciting things coming over the next few years around integration — things that will make these solutions meaningfully faster and better, and impress a lot of people.

Jeff: Technology is moving fast. I was working with ChatGPT today, and there are powerful tools out there. Listen to enough podcasts and the sky is falling and the AI overlords are coming, but I think there are real opportunities to improve use cases and experiences for customers. At the end of the day it has to add value — solve a pain point, make something easier or faster. Otherwise it's hype, and it's just a bunch of techno nerds, of which we are a part, sitting around saying isn't this cool. We're not in the market to sell shelfware. We want to help our customers deliver for their customers.

Scott: You got it.

Jeff: As you said before we started recording — when you hear about an acquisition, you ask what's going to change, and the answer is usually just the name on the sign. That's about right for now.

This was episode one of season two. We made it to season two, we're 25 or 30 episodes in, and apparently that puts us in the top few percent of all podcasts. Scott, thanks for the time, and we'll catch you next time.