Ep. 21: The Hidden Costs of BOM Errors (And How to Avoid Them)

Common Bill of Material Errors: What They Cost and How to Calculate the ROI of Fixing Them
The Integrate Intelligently Podcast — with Jeff Bickler and Scott Bickler (CADTALK)

Welcome Back and Personal Updates
Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, once again joined by my brother and founder of CADTALK, Scott Bickler. Scott, I know we've both been traveling a lot lately — you're back home in Cincinnati, well, Northern Kentucky technically.

Scott: It's nice to be sleeping in my own bed again for a while. I used to travel something like 40 weeks a year, and I genuinely don't know how I did that — these last few weeks of travel wiped me out. Maybe I'm just getting old.

Jeff: Nothing says old and cranky quite like complaining about not being able to sleep in your own bed or eat your normal food. We sound like a couple of old men.

Scott: It really is nice to sleep at home, though. Side note — I have sleep apnea, used to wear a CPAP machine, and a couple weeks ago I switched to a dental appliance instead. Total game changer, my sleep's gotten even better. We're really going down the old-man-woes rabbit hole here.

Jeff: At least you can grow a beard — I'm what you'd call facial-hair disabled.

Scott: Well, the trade-off is mine would be gray. So, Scott — since I've been traveling a lot and we're back to talking bills of material again, imagine that — today we're focused on how critical bills of material really are for manufacturing.

Understanding Bills of Material
Jeff: Before we dive in, Scott — I didn't come from a manufacturing background myself, so for our listeners who might be new to the concept, can you give a quick overview of what a bill of material actually is? Today's topic is really about mistakes in the BOM, so it'd help to start with the basics — what is it, and at a fundamental level, how does a mistake there actually cause problems?

Scott: Absolutely — I'd actually recommend a book here, a short read called Bill of Materials: Structured for Excellence, which covers this in a lot of detail. We can link it in the show notes.

Jeff: I wouldn't call it a page-turner for most people.

Scott: Definitely not — but for a geek like me who loves bills of material and manufacturing, it's great. I read it back in the late '90s. But at the core, a bill of material is essentially a recipe for building something. Just like a cookie recipe has ingredients and instructions for putting them together, manufacturing has that same kind of recipe — parts made up of assemblies, assemblies made up of raw materials, and labor turning raw material into finished parts, all coming together into whatever you're building.

The example I like to use is a desk — the one you're sitting at right now. The bill of material for that desk would include the tabletop, the legs, the nuts and bolts holding it together — if it's a standing desk, maybe the motor mechanism, the control module, the keyboard tray. All of those individual parts make up your list of materials, or your recipe, for building a desk. Typically you'd have a parts list with quantities, and if you go into more detail, a bill of material often includes assembly steps too, similar to recipe instructions — "attach this part to this part."

One difference from a typical recipe: most recipes are what we'd call single-level — one flat list of ingredients. But complex products often have multi-level bills of material. Take that desk example — the tabletop itself might have its own bill of material: the plywood you cut, plus the laminate layered over top. That tabletop then becomes one component in the overall desk's bill of material. That's what we mean by multiple levels. Depending on complexity, you can have a lot of levels — I believe the record is something like seven levels deep, for the space shuttle — but most manufacturing companies operate around two or three levels. At its core, though, it's just a list of things and a list of steps to put them together, like a recipe.

Jeff: The way I've always explained it to people — my wife, my kids, anyone who asks what I actually do — is to think of IKEA furniture. You get that instruction sheet with the full parts list: here's everything you need to assemble this. That's essentially a bill of material. It's flat, sure, but it's a list of every screw, the motor, the legs, the top, the cam locks — whatever pieces are needed to put the thing together. We don't usually think of an IKEA parts list as a "bill of material," we just call it a parts list — but functionally, a parts list is a simple bill of material, and the assembly instructions are basically the operations.

Scott: Great example — everyone can relate to that. Technically, the IKEA box itself would be considered a "kit," since it's not assembled yet — that's a whole separate conversation about kitting. If you were selling it fully assembled, it'd still be a bill of material, but the actual assembly operation hasn't happened yet.

Jeff: Left to the owner — an outside process, basically.

Scott: Exactly, an outside process — typically performed by Santa Claus on Christmas Eve.

Jeff: Dad-powered, whatever that operation's called.

Scott: Exactly. But essentially, it's all just a list of parts — and a lot of the time, when we're doing integrations, we're deriving that data directly from engineering software. If you're using SolidWorks or similar CAD software, the bill of material is essentially a byproduct of the 3D design itself — you're modeling reality, and we can extract the parts list directly from that model.

That said, we've talked before about how a bill of material coming out of CAD doesn't always match how it needs to look on the ERP side — there's a difference between an engineering bill of material and a manufacturing bill of material, and planning bills of material too. There's a lot of philosophy around exactly what should be included. That book I mentioned has a specific opinion on this, but there's real variation across companies — some don't track nuts and bolts as line items at all, treating them as consumables not worth tracking individually; others track down to the washer level, especially in something like aerospace. It really depends on your use case and what level of completeness your business actually needs.

Jeff: That's a good point — working with hundreds of customers, I've seen the full range. Consumables — nuts, bolts, even labels — sometimes aren't on the BOM at all, even from a CAD perspective, and sometimes they're not represented in the ERP either — companies will just keep them in a Kanban bin and expense them directly instead of tracking them formally.

Common BOM Errors and Their Origins
Jeff: Since today's topic is common BOM errors and where they come from — I keep coming back to that IKEA analogy. Think about how frustrating it is to open a box on Christmas morning and realize a part's missing. Your kid's excited to play with a new toy, and you don't have batteries, or a piece is missing, and they simply can't use it. That's a real-life BOM error.

Scott: "Batteries not included" — that's a classic. It's interesting, actually — when we were kids, it was almost inevitable a parent would forget the batteries entirely. Now, most toys ship with batteries included so kids can play immediately. Same idea with rechargeable devices — I think Apple started this with the iPod, shipping it pre-charged so there's no delay before you can actually use it. It's all about eliminating that friction. "Batteries not included" used to be a real Christmas letdown, and now a more complete bill of material basically means a happier Christmas morning.

Jeff: And no unnecessary trip to the hardware store the day after Christmas trying to track down the piece you're missing. It's a good real-world analogy for people outside manufacturing — a crying kid on Christmas morning is basically the consumer version of a BOM mistake. In manufacturing, it's not quite the same stakes, but the effect is similar — maybe it's not a crying baby, it's a frustrated shop floor, or worse, a part missing bolts by the time it reaches the actual customer.

Jeff: So what are some of the common mistakes that actually happen on a bill of material, and what causes them?

Scott: A very common one is simply leaving things out, like you mentioned. It's less of an issue with solid modeling than it used to be, but it still happens. Back in the two-dimensional CAD days, it was easy to miss something entirely — if a part wasn't dimensionally shown in the drawing, there was no built-in reason it would automatically appear on the BOM; someone had to manually verify it. Creating the drawing and creating the bill of material used to be two genuinely separate activities. Once design moved toward true 3D modeling — designing an actual virtual representation of the object in space — it became much easier for software to recognize each entity, count it, and generate the bill of material automatically. But the risk of forgetting things — hardware, glue, anything that isn't visually represented in the model — is still very real.

The other common issue is metadata — picking the wrong material, or not capturing enough surrounding data, which then doesn't translate cleanly into the manufacturing bill of material. That's part of what our translation process handles. Beyond that: choosing the wrong vendor, or getting the quantity wrong. Say there's an expensive part in the assembly, and someone enters three instead of two — if that part costs $50,000 each, you've just committed to $50,000 more than intended. Quantity errors, missing parts, missing metadata — usually it's missing or incorrect data that sends everything downstream haywire, because the ERP — the system driving all of manufacturing, running MRP, ordering all the parts — works entirely off the bill of material as its base data. If that's off, everything built on top of it is off too.

Think of it like laying a tile floor — remember that apartment we tiled together years ago? I laid the very first tile a little crooked, and by the time we got across the kitchen, every subsequent tile had drifted further off, even though the walls themselves were perfectly straight. That first crooked tile compounds through everything that follows. Same exact thing with a bill of material — it's the very first tile, and any error there gets magnified as it propagates through the ERP.

Jeff: Exactly right. Back when it was just AutoCAD, essentially digital drafting boards producing line drawings, and someone was manually building the bill of material separately — in the ERP, or even a spreadsheet — and handing that off to the shop floor, mistakes were much more common. Even today, with 3D modeling, you can export a BOM to Excel, but if you're still transferring that manually, you still carry the risk of dropping an item — not to mention things that were never in the CAD model to begin with that someone has to remember to add manually: paint, glue, or outside processes like galvanizing, plating, or powder coating. Doing all of that manually, it's very easy to miss a step, or you end up spending huge amounts of time on what one of our team members calls "stare and compare" — checking one sheet against another, back and forth, line by line, working off a checklist — a much higher-risk process for quality than an automated flow. And it's not just the core parts list — it's raw material, outside processes, paint, correct units of measure.

I was actually on a demo call recently where a customer described real trouble with units of measure on raw material — they needed three of something, meaning three sheets, but their system interpreted "three" ambiguously — was it three sheets, or three sticks, or some other unit entirely? If the unit of measure isn't set up correctly, you can end up ordering three full sheets or three full 10-foot sticks of bar stock when you only actually needed three inches. That kind of mistake really compounds — instead of ordering one stick and cutting three inches off it, you accidentally order three entire 10-foot sticks you didn't need at all.

Calculating ROI and Cost Implications
Jeff: Those are the hard costs — and we actually have an ROI calculator on our website that helps quantify exactly this kind of thing. The most common thing people focus on with ROI is time savings, because it's the easiest thing to measure — but I'd actually argue it's the less important piece. It's easy to measure, which is why people gravitate to it, but the real cost savings usually live in the soft costs, which are simply harder to quantify, so they get overlooked.

To define the difference: someone's time is a fairly hard cost — you can put a number on it. A mistake sits somewhere in between — you can at least estimate what a given mistake costs, even if some mistakes are obviously worse than others. But something like "how much better does your MRP or scheduling perform when your bill-of-material data is consistently accurate — or at least consistently wrong in a predictable way" — which we touched on in a previous episode, since consistent is actually more valuable than sporadically accurate — that's a genuine soft cost, hard to measure, but very real. One of the most underappreciated benefits of an integration like this is realizing all those secondary benefits your ERP was originally purchased to deliver in the first place — and those benefits are exactly the ones that are hardest to quantify, even though they're just as material as the hard costs. For every hard cost we talk about, there's probably five to ten times as much value sitting in the soft costs behind it.

Jeff: Let's actually walk through our ROI calculator, since we're showing it now. There are really two categories of cost tied to BOM mistakes: hard costs — time and money, direct labor savings from automation — and soft costs, which are much harder to calculate but reflect the value of everything running more smoothly: better MRP, better scheduling, all downstream of better upstream data quality.

Understanding Burden Rates and Employee Costs
Jeff: Scott, when you originally built an early version of this calculator in Excel to help educate people on the value of integration — walk me through the first input: hourly cost of data entry. I think you originally used around $50 an hour?

Scott: Depends heavily on who's actually doing the work — if it's an engineer, versus someone in operations, versus a manufacturing or design engineer, plus the full burden rate — the true cost of employing that person, not just their salary.

Jeff: Does $50 an hour still hold up, or has inflation pushed that number higher?

Scott: It really depends on the role. A lot of the time this work falls to engineers themselves, which is honestly the worst-case scenario — or a manufacturing engineer, since routing data and similar work often needs a similar skill set. People tend to underestimate this number, thinking "oh, it's just data entry, we'll use a junior person" — but that undersells it, because there's real domain knowledge being applied, not pure key-punching. It's part data entry, part applying judgment and knowledge — which, incidentally, is a lot of what a tool like ours can absorb. So realistically, it's often someone more expensive, like an engineer, and burden rate matters a lot — people think of hourly rate as just salary divided by hours, but with benefits, health insurance, taxes, 401k contributions, and everything else, true cost runs well above base salary. A $50-an-hour estimate implies roughly a $100,000-a-year role, and in today's market, plenty of engineers earn well above that. I'd say $75 an hour is a more realistic blended estimate across junior-to-senior engineering talent.

Before I forget — another soft cost people consistently underestimate is lead time reduction. Think about automation broadly: every day a bill of material or a piece of paperwork sits on someone's desk waiting to be processed is a day of lost lead time — literally a day you didn't deliver to the customer. Reducing lead time is often a better overall proxy for cost than measuring cost directly in a lot of contexts — there's a whole discipline called Quick Response Manufacturing built around exactly this idea. It's a significant soft cost that rarely gets its due credit.

Jeff: I always compare that to Amazon's two-day Prime shipping. It's not identical, but conceptually similar — think about how much value there is in clicking a button and getting something same-day or next-day versus waiting a week. Reducing lead time carries real intrinsic value for the customer, and it consistently drives increased sales — that's exactly why Amazon invests so heavily in it. People are willing to pay more, and buy more, when delivery is faster — that's just proven, we all vote with our wallets on Prime constantly.

The Importance of Lead Time Reduction
Scott: Same principle applies directly to manufacturing — reducing lead time genuinely increases sales by getting product to your customer faster.

Jeff: Absolutely — very important, genuinely hard to measure, but a real benefit and a real cost either way. You can't argue with Amazon's results — a trillion-dollar company, and Prime shipping speed was a massive driver of that.

Jeff: Okay, let's get into the actual hard costs in the calculator. We're using $75 an hour for data entry — anyone who disagrees can plug in their own number at cadtalk.com, since costs vary by region, and we work with customers globally, so this isn't US-dollar-only. Next input: number of new items created each month. Scott, from your time in manufacturing — you were at an engineering-to-order company — what's a reasonable estimate for new items per month?

Scott: That was admittedly an extreme case — we were creating around 3,000 new part numbers a month, which is well above what most companies see. It really depends on your specific flow, but with something like 150 engineers designing full-time, you're going to generate a huge volume of new parts. For a more typical company, I'd estimate a few hundred a month is reasonable.

Jeff: I'd tie that estimate to engineer headcount specifically — one engineer isn't going to generate much volume, but with 15 to 20 engineers, you'll easily see 500 to 600 new parts a month — roughly 10 new parts per engineer per month, which with 15 engineers lands around 150. I'd call 300 part numbers a reasonable middle estimate for creating new items.

Jeff: Next: time to enter a new item. I usually use 15 minutes, start to finish.

Scott: Some people will say they're much faster than that, one or two minutes — but that ignores the full process: opening the browser, logging in, actually entering everything correctly. It also depends heavily on scope — are you attaching drawings, entering pricing, vendor information? All of that adds time.

Jeff: 15 minutes is a reasonable baseline. Next input: number of new BOMs per month — this is distinct from items, since once you create the items themselves, you still have to build the bills of material that use them.

Scott: Technically, every manufactured part has some form of bill of material — even a single-component one — and then there are assemblies stacked on top of that. I'd estimate somewhere between 50–75% of your new item count also generates a new or updated bill of material.

Jeff: So working off 300 new items, that's roughly 150 new or updated BOMs — and that figure should include both brand-new BOMs and BOM edits or updates, not just net-new ones.

Jeff: Next: number of BOM errors — what's a reasonable error rate for manual entry, 10%?

Scott: It's genuinely hard to pin down precisely, but I'd go conservative — we're human, and roughly one mistake in ten feels like a fair, defensible estimate.

Jeff: So 90% accuracy on manual entry. And number of changes per month — this varies a lot; I know some of our customers run hundreds of changes a month.

Scott: Sometimes more than the number of new parts themselves. When I was in manufacturing, our engineering change volume roughly matched our new-part volume — they tended to track together.

Jeff: So if we set changes roughly equal to new items — 300 a month — that's a reasonable balancing estimate, though obviously this varies by business and people are welcome to plug in their own numbers.

Jeff: Last input: time to enter or update an existing bill of material.

Scott: Updates are sometimes actually harder than creating something new, because you have to carefully distinguish what's changed versus what's staying the same — more cognitive load, not less.

Jeff: I'd put that around 20 to 30 minutes per change.

Scott: I'd go with half an hour.

Calculating Hard Costs in Manufacturing
Jeff: So running the hard-cost numbers — people might quibble with some of our specific inputs, but looking at this, monthly labor cost lands around $23,000. If CADTALK-style automation saves roughly 80% of that time — which is genuinely a common result for us — that's the cost avoided each month.

Scott: Right, that's the projected cost once automation is in place. And sometimes we actually automate closer to 100%, particularly with a fully service-based, hosted setup — which is worth noting, because if you can only get to 80% automated, that remaining manual 20% can still represent a disproportionate amount of ongoing work for comparatively little benefit, as the numbers here show. That's exactly where the lead-time soft cost becomes really significant — once you're closer to fully automated.

Jeff: So: annual labor cost, and then the projected savings percentage with CADTALK or similar automation in place — that's a substantial number. Typically, whatever CADTALK actually costs is significantly lower than that projected savings, so purely on hard costs, the automation case tends to justify itself pretty easily. Once you factor in the soft costs on top, it really becomes a no-brainer.

Scott: It really does — that's exactly why this is so popular to implement, honestly, it makes a lot of sense on paper and in practice.

Jeff: In past conversations, people sometimes push back — "it doesn't really take that long," or "we're not going to save 80%." Fine — even if you only save 50%, or 40%, you're still looking at a massive amount of savings and real hard-cost benefit. It becomes a pretty easy call. And beyond the raw numbers, the quality of the work itself improves significantly — manually entering bills of material isn't exactly exciting work. Nobody wakes up thinking, "today's the day I get to enter a thousand-line bill of material, best week ever." So there's a real soft cost tied to lead time, increased sales, but also employee satisfaction and freeing people up for genuinely valuable work.

The Value of Time Savings and Employee Satisfaction
Jeff: That's a soft cost worth naming directly — if you're improving data quality and process, people generally enjoy their jobs more when they're solving more engaging problems instead of doing manual corrections or firefighting shop-floor issues caused by bad data. That's a much better use of anyone's time, and we shouldn't discount that. I don't think anyone genuinely enjoys keying in bill-of-material data by hand.

Scott: There's a common counterargument I used to hear a lot from a colleague — "if I only save 50% of one person's time, it's not like I'm going to cut them to part-time and pay them half as much, I'm still paying full salary either way." That's a common misconception about time savings — there's actually a great book on this, Buy Back Your Time — but the real value comes from what that freed-up time gets reinvested into. It genuinely does translate, because it opens up capacity to fill that time with more valuable work.

Jeff: Right, and you're constantly leveling that person up toward higher-value work. One thing we've discussed before — if someone's fully consumed just keying in BOMs, or doing administrative tasks, they simply don't have the bandwidth to think about a better process, let alone propose one. Every time you free up that time, that's another soft cost benefit — the opportunity for that person to surface a genuinely better idea, improve a process, or spot a bigger opportunity out on the shop floor opens up.

Scott: Whereas historically, if everyone's working at full capacity on purely administrative tasks, you'd have to add headcount just to create the space to even consider doing something better — which, running a business myself, I know is genuinely difficult to do. But if you can free up your already skilled, experienced people from administrative overhead, you open up the possibility of letting humans actually do what humans are best at: creative problem-solving and genuinely improving the business, instead of purely administrative work.

Jeff: That's the "buy back your time" idea, essentially — giving yourself, or your team, more bandwidth to look at bigger problems, ones you'd never even attempt to tackle if you were fully consumed by day-to-day tasks. If you're that buried, you're not even mentally open to noticing a bigger opportunity, because you're too consumed by what's directly in front of you.

Scott: It's genuinely hard to convince people of that value, though — the instinct is "if I give someone more free time, they'll just do less." I think better of people than that, honestly — most people, given real capacity, will find ways to improve things. A huge amount of lost time in general comes from task-switching and communication overhead. There's a well-known concept from software development called The Mythical Man-Month — the idea that if one person takes 100 hours to do something, two people won't each take 50, and three people won't each take 33.3 — you can't just throw 100 people at a task and finish it in an hour, and we intuitively know that's absurd. The math doesn't actually scale that way, because communication cost between people rises — almost logarithmically — as you add more people. Beyond a certain point, added people create more communication overhead than the task itself saves. In software specifically, the fastest total development time for something is often genuinely one person working alone — you're not optimizing lead time there, you're optimizing total effort. Add a second developer, and total time might drop meaningfully in terms of calendar time, but total effort actually goes up.

Same principle applies to task-switching. If I'm an engineer designing all day, and I have to stop and manually enter data into another system, that's a real inefficiency from the context switch alone. If I hand it off to someone else instead, now there's a communication cost — I have to explain exactly what I did and my full intent, clearly enough that they understand it correctly. With automation, both of those costs shrink dramatically — you're able to carry the original design intent forward automatically, and you avoid the task-switching cost entirely, because the work either happens automatically or gets meaningfully batched, letting the person doing the actual design work stay in flow. Cutting both task-switching and communication overhead genuinely reduces total time spent, without consuming more of any individual's time.

Balancing Hard and Soft Costs in Business Decisions
Jeff: That's a great point — and it illustrates exactly why soft costs are so hard to measure, and why they're less persuasive in conversations even though they matter enormously. People tend to dismiss them as hand-wavy, but they're genuinely significant — just difficult to quantify, and sometimes difficult to justify to a business stakeholder. If you understand how systems and organizations actually work, the cost of communication overhead and task-switching is enormous, especially in today's environment with everyone juggling multiple responsibilities.

So — BOM mistakes and manual entry can be genuinely expensive, and the benefit of an automated or semi-automated integration process like CADTALK compounds across both hard costs — time, money, fewer errors, faster processing — and soft costs — lead time, reduced task-switching, broader process improvements, and better employee satisfaction. Anything else you'd add, Scott, or other key takeaways?

Scott: I think about this the way I learned to evaluate any investment or project back in my MBA coursework — figuring out hard costs, understanding time value of money, present value calculations. When you're evaluating whether to take an action or invest in a solution, one useful approach is: even if you can only formally quantify the hard-cost case, and it already clears the bar on its own, that's often a strong signal the soft-cost upside — even though it's unmeasured — is genuinely there too. If something has a positive net present value based purely on hard costs, factoring in reasonable risk and probability, that alone often justifies moving forward, because life rarely unfolds exactly as modeled — there's always a probability distribution around outcomes. If you can already justify something on hard costs alone, you're probably looking at another two to five times that value sitting in soft costs you can't even fully measure. People should probably be a bit more bullish on this than they typically are — while still being realistic that as a project gets more complex, your probability of full success naturally goes down, so you're always balancing complexity against likely return, trying to optimize for the best outcome per dollar invested, same as any other kind of decision.

Closing Thoughts
Jeff: Scott, thanks for joining today — glad to have you back home, and glad we got to have this conversation. Good discussion on hard and soft costs around ERP integration. I'd encourage everyone to visit cadtalk.com and try the ROI calculator yourself — plug in your own numbers, see what it tells you. It's a tool we built specifically to help business leaders, operations managers, and engineering managers actually quantify how much time their teams are spending on this, and what an integration solution could realistically return. Scott, anything else before we sign off?

Scott: No, I think that was a great discussion.

Jeff: Sounds good — we'll see you next time.