Every manufacturing company has a version of the same story.
Sales needs product renderings before a customer call. Procurement needs dimensions and material data for an RFQ. Quality needs a dimensional report before a part ships.
Different requests, same problem: they all end up going back to Engineering.
And most organizations don’t think much of it.
Engineering owns the product design. The design contains information other teams need to do their jobs. So, they wait.
That’s just how we’ve always done it.
Except “the way we’ve always done it” has a significant cost.
Multiply that wait by the number of times it happens in a week, a quarter or a year – and across every team that depends on Engineering – and the impact starts to look a little different.
Quotes take longer to go out. Production planning stalls a day here and there. Marketing materials get pushed because nobody had time to pull the rendering. Engineers spend time retrieving and repackaging information instead of doing the work they were hired to do.
Waiting doesn’t show up as a line item on the P&L. But the cost is there.
People simply get used to saying, “That’s just how long it takes” or “It’s just how things work around here.” Maybe it shouldn’t be.
Let’s Put a Number to This
Two hours doesn’t sound like much.
But let’s say an engineer spends just two hours a day on routine, manual tasks – extracting data, generating reports, or packaging design information for someone else in the organization.
Over the course of a year, that adds up to roughly 500 hours per engineer.
Put a hypothetical fully loaded cost of $80-$120 per hour against that time, and you’re looking at $40,000-$60,000 per engineer, per year. For a team of ten engineers, that could mean $400,000-$600,000 worth of engineering time each year spent on work that could be automated.
And that’s only the cost you can calculate.
It doesn’t account for the quote that went out late, the production schedule that slipped or the higher-value engineering work that didn’t get done while someone was busy pulling information for another team.
We’ve seen this problem play out in the real world.
At a Tier 1 automotive supplier of body-in-white (BIW) parts with operations in the U.S. and Mexico, a three-person procurement team was fielding 15-20 RFQs each week. For every part, someone had to manually pull dimensions, material information, weight and screenshots from multiple angles and transfer everything into a custom costing template.
One part took about 45 minutes.
Across the team, that added up to roughly 34 hours every week – nearly the equivalent of a full-time employee – spent copying information out of CAD files and into quote templates.
At an estimated loaded cost of $50 per hour, that’s close to $88,000 a year. For copying and pasting. And remember: that’s one workflow, in one department, at one company.
When Knowledge Walks Out the Door
Time isn’t the only thing organizations lose to “that’s how we’ve always done it.”
There’s another risk that’s harder to put a number on: much of the knowledge behind how work gets done lives in people’s heads.
In complex manufacturing environments, especially in industries like automotive, aerospace and heavy equipment, the real process isn’t always documented. It lives in shortcuts, rules of thumb, workarounds and years of experience – the “we tried that once and it didn’t work” kind of knowledge that rarely makes its way into a manual.
And usually, that’s fine. Until “been here forever” Gary leaves.
Gary is the person everyone knows to ask. He knows which steps to take, which information matters, which workaround actually works and why something is done the way it is.
Then Gary retires, changes jobs, or moves into another role, and suddenly everyone realizes something:
Gary wasn’t just doing the process. Gary was the process.
Fans of the hit show, Severance might recognize the problem. At Lumon, employees leave everything they know at work when they walk out of the building. It’s only when they clock back in that their memory returns.
A surprising number of manufacturers have created their own accidental version of Lumon – except there’s one pretty significant difference.
Gary isn’t clocking back in Monday.
And neither is the knowledge trapped in his head.
Not All Automation Is Created Equal
At this point, the obvious answer might seem to be: just automate it.
And many companies have tried.
The problem is that most general-purpose automation tools are built for relatively straightforward business data and workflows – form submissions, approvals, emails, spreadsheets and the like.
Engineering data is different.
A CAD file isn’t just a picture of a part.
Inside that file can be the geometry itself, feature history, product structure, material properties, tolerances, datums, surface finishes and other information that tells you not only what a part looks like, but how it was designed and how it needs to be made.
That’s incredibly valuable information.
It’s also not particularly easy to get to.
Getting to that underlying information means understanding the native design data itself. And that gets complicated quickly. CATIA, NX, Creo and SOLIDWORKS don’t all speak the same language – each has its own format, structure and way of representing design information.
Historically, companies looking to automate work around that data have often had to build their own tools or rely on specialized CAD customization. Someone who knows the SOLIDWORKS API, for example, can spend weeks developing an automation around a specific process.
That’s fine. Until the next file comes from CATIA. Or NX. Or Creo.
Now you’re dealing with a different data model, different requirements, and potentially a different specialized skill set. The automation that solved one problem suddenly becomes another thing that has to be maintained, rebuilt or recreated.
You automated the process. You just didn’t necessarily solve the problem.
AI Can’t Use Data It Can’t Reach
And all of this becomes even more important when AI enters the conversation.
Almost every engineering and manufacturing leader is fielding some version of the same question:
“What’s your AI strategy?”
It might come from the C-suite, the board or an analyst on an earnings call. And for a lot of organizations, the honest answer might be: “We’re not ready yet.”
Not because they haven’t thought about AI. Not because they don’t see the potential. Because AI can’t do much with data it can’t reach.
Product design data is some of the most valuable—and commercially sensitive—intellectual property a manufacturer owns. Much of it also happens to be locked inside proprietary native CAD formats.
A general-purpose AI model can’t simply open a CATIA assembly and start reasoning over everything inside it. It can’t inherently infer material properties, identify every fillet or chamfer, understand tolerances or pull out the other engineering information a workflow might need.
Before AI can do something useful with that information, the relevant data has to be extracted, structured and made accessible.
In other words, you have to operationalize the data.
That’s the actual, decidedly unglamorous bottleneck sitting underneath a lot of very glamorous AI ambitions.
There are increasingly sophisticated frameworks capable of orchestrating multi-step, tool-using AI agents. That’s great. But an agent is only as good as what it can consume.
If the engineering data it needs is still trapped inside proprietary design files—or requires someone to manually find, interpret and repackage it—all that sophisticated orchestration doesn’t get you very far.
Before we start asking what AI can do with our engineering data, maybe there’s a more fundamental question:
Can it actually use the data in the first place?
So, Where Does Impact360 Fit?
This is exactly the kind of problem we built Impact360 to address.
Impact360 is a no-code automation platform built specifically for workflows that depend on product design data. It extracts the engineering information teams need, structures it and makes it accessible so people across the organization can turn repetitive, manual processes into automated workflows—without writing code or becoming CAD experts themselves.
In other words, it helps organizations operationalize engineering data and put it to work.
And that can mean solving a relatively mundane problem today or laying the groundwork for something much more sophisticated tomorrow.
Automate the Routine
Impact360 accesses design data wherever it lives, whether that’s local storage or a PDM/PLM environment, and extracts the geometry, features, material properties, product structure and other information inside it.
Once that data is accessible, people without coding or specialized CAD expertise can build automations around the routine work that depends on it.
Think back to that RFQ example.
Instead of someone spending 45 minutes opening a design file, finding dimensions, identifying materials, pulling weight and capturing screenshots from multiple angles, the process can be defined once and turned into a repeatable workflow.
What took roughly 45 minutes manually can take about two minutes, with most of that time spent waiting for the file to process.
Same work. Same information. A lot less clicking.
And here’s where the multi-CAD problem we talked about earlier matters.
Impact360 isn’t dependent on a single CAD system’s API. It’s built on CCE’s proprietary interoperability technology, allowing its data extraction layer to work across multiple native CAD formats and access geometry, feature history, product hierarchy, attributes and PMI/GD&T.
So, the workflow doesn’t have to be reinvented every time the design comes from a different CAD environment.
And because Impact360 operates in a non-destructive, read-only mode, the design IP representing years of engineering investment stays where it started.
Power What’s Next
Solving today’s repetitive work is one part of the equation.
The other is what becomes possible once engineering data is no longer trapped inside a proprietary file.
Because Impact360’s output is structured, that information can become usable by other systems, workflows and, increasingly, AI.
Take something as seemingly simple as a hole.
Impact360 can extract every hole in a design along with information such as its size, location, type, depth and tolerance requirements.
That’s useful on its own.
But once that information is structured, an agentic workflow could potentially use it alongside material properties, RPM, feed rate and drill-bit selection to calculate drilling time, recommend equipment, estimate cycle time and labor costs, or flag tolerances that require specialized tooling.
The hole didn’t change. What you can do with the data did.
And the same idea extends beyond hole data—to process sheets, BOM extraction, supplier documentation, simplified geometry and countless other downstream workflows.
That’s why we think the conversation about AI in engineering has to start one step earlier than AI itself.
Before you can ask increasingly sophisticated systems to reason over your engineering data, you have to make that data usable.
Each company is different, with its own stakeholders, systems and workflows, many of which depend on product design data. Yet across engineering and manufacturing organizations, people still spend countless hours asking around for information, waiting for someone else to provide it and ultimately doing work manually that could be automated.
Why? Often, because that’s how it’s always been done.
But it doesn’t have to be.
With Impact360, organizations can automate the routine work slowing them down today while creating a foundation for what comes next. And as more product design data becomes accessible and usable across the enterprise, the opportunities for automation only grow—limited less by the ability to write flawless C++ or Python code and more by what your teams can imagine doing differently.
