Walk into almost any mid-size manufacturer and ask who moves the engineering data into the ERP. You’ll usually get a name. One name.
Maybe it’s a senior engineer. Maybe it’s a small group of specialists who sit between design and the rest of the business. Whoever it is, they hold something in their heads that the whole operation runs on, and most of the time nobody has written it down.
That arrangement works. Right up until that person takes a two-week vacation.
What the handoff actually requires
It’s easy to underestimate the job, because from the outside it looks like data entry. It isn’t.
Dylan Olson, a solutions architect at CADTALK who spent more than a decade as a manufacturing engineer, described what really sits in those people’s heads. They know how each part needs to be set up and configured in the ERP. They know how those parts behave when MRP runs through them. They know which routings to attach, which procurement fields matter, how to handle a revision, how to phase a part in and phase another out without breaking the downstream plan.
Call it what it is: a working model of how engineering intent becomes a manufacturable, purchasable, schedulable thing inside the business system. And in a lot of shops, that model lives entirely in one or two people.
The tale of two cities
Tim Ryan, an ERP sales executive at WIA Systems, framed the same risk from the construction side with an image that travels well beyond construction. He calls it a tale of two cities. There’s the field and the back office. And inside the back office there’s another township: estimating, modeling, the people who set the data up. They tend to live in their own world.
When those worlds aren’t connected by data and process, and there’s no feedback loop between them, you get the line that should make any manager uneasy: “we don’t know what we don’t know.” Decisions get made on gut feel. Experience matters, and experience is real, but gut feel can’t tell you about the long-lead item nobody flagged or the part that quietly got built wrong.
The risk is concentration. The more the handoff depends on specific people, the more your visibility depends on those same people being present, consistent, and right every single day.
Why tribal knowledge feels safe and isn’t
“My team has a process for this” is a comfortable answer. It’s also the answer that breaks the quietest.
A process that depends on people being consistent every day is exposed to every normal thing that happens to people. Someone gets sick. Someone takes the two weeks they earned. Someone makes a different call on a Friday afternoon than they’d have made on a Tuesday morning. And eventually, someone gets a better offer and leaves, taking the undocumented process with them.
The talent market makes this sharper. The engineers coming up now grew up with tools that strip out friction. They notice when a job asks them to do manual data work that a system could handle, and they have options. Research from Tech-Clarity finds engineers lose roughly a third of their time to non-value-added data work, and the shops that keep their best people tend to be the ones that respect their time.
What it costs when it breaks
A handoff error doesn’t stay where it started. A wrong part number or a missed revision flows into purchasing, into production planning, onto the shop floor. By the time anyone notices, it’s a cross-functional fire drill: wrong parts ordered, a line waiting, a rework cycle, a schedule slipping.
And it always seems to land on the manager. When a BOM error reaches production, the person accountable for the team is the one explaining how it happened, not the system that let it through.
The fix is a documented, repeatable rules engine
The way out is to convert what’s in those few heads into logic the whole team can use.
A configurable rules engine reads the part data from the CAD or PDM environment and applies your business rules to set each part up correctly in the ERP, automatically, on every release and every engineering change. The knowledge stops being tribal. It becomes documented, repeatable, and owned by the team rather than by one irreplaceable person.
Dylan made the human point clearly: a rules engine doesn’t call in sick, doesn’t make a different decision on a Friday afternoon, and doesn’t leave when someone gets a better offer. It applies the same logic every time. So anyone on the team can run the handoff, because the system carries the model that used to live in someone’s memory.
That also changes the manager’s day. Instead of reviewing every transfer, you manage by exception. The standard cases flow through. The system flags only what’s genuinely unusual. You spend your attention on the handful of real edge cases, not on babysitting the routine.
“But everything we do is an exception”
Operations leaders often resist automation here with a version of the same line: our work is too variable to systematize. Every job is different.
Tim’s advice is worth repeating: don’t fall into the illusion that everything’s an exception. Most of the time, what looks like endless variability is a lack of clarity about what the process actually needs to be. Once you get clear on the rules, the genuine exceptions turn out to be rare. And rare exceptions are exactly what a human should be handling, while the rules engine takes the rest.
You also don’t need pristine data to begin. A visual BOM interface surfaces what needs attention before anything commits to the ERP, so you fix the gaps upstream instead of discovering them on the floor. Shops that make this shift typically see data accuracy climb to 95 to 100% and the manual entry burden fall to a fraction of what it was.
What this does to onboarding and growth
The hidden tax on tribal knowledge shows up when you try to grow.
Add an engineer, and someone has to teach them the unwritten rules of the handoff: how parts get set up, which fields matter, how revisions are handled. That training takes weeks, it pulls your expert off their real work, and the new hire’s version is never quite identical to the original. Every person you add is another slightly different copy of a process nobody wrote down. The variability compounds as the team grows, which is the opposite of what you wanted from hiring.
A documented rules engine flips that. The process lives in the system, so a new engineer is productive on the handoff almost immediately. They work in their design environment, and the rules carry the part data into the ERP correctly whether it’s their first week or their fifth year. You scale the team without scaling the risk.
There’s a second benefit when something does go wrong. A rules engine makes the same decision every time, so when it produces an error, it produces a consistent one you can find and correct at the source. Human error is random. It hides until it surfaces downstream, and by then you’re tracing a single bad part back through purchasing and production to work out where it began. Consistent and fixable beats sporadic and invisible.
Trust your process, because right now you’re trusting a person
Here’s the question to carry out of this. How many people does your CAD-to-ERP handoff actually depend on? And what happens to your week when one of them is out?
If the honest answer makes you a little uncomfortable, that’s the signal. The goal isn’t to remove the expertise. It’s to capture it, so the expertise belongs to the company instead of walking out the door with whoever holds it.
A process you can stand behind is one that runs the same way no matter who’s at the desk.
Want to see what your handoff looks like as a documented rules engine? Watch it run at cadtalk.com/demo, browse walkthroughs on CADTALK’s YouTube channel, or reach the team at sales@cadtalk.com.
