Ep. 20: Why Your ERP is Holding Back Your Business (And What You Can Do About It)

Is Your ERP Holding You Back? Data Integrity, Right-Sizing, and Local Optimization Traps
The Integrate Intelligently Podcast — with Jeff Bickler and Scott Bickler (CADTALK)

Jeff: Welcome back to The Integrate Intelligently Podcast. I'm your host, Jeff Bickler, joined as always by founder and CEO, my brother, Scott Bickler. Scott, good to see you — new backdrop today?

Scott: Actually, same location, just recording in separate rooms — sometimes that's easier. We're in a nice apartment in Kelowna, BC, Canada — on the road again. Hopefully our last trip for a while before year-end, but we're here for some coaching this week, plus working through some planning together, so it's good to combine that with recording.

Jeff: We were on the road last episode too — seems like it's been a heavy travel stretch these past four to six weeks. I'll be glad to wrap up the travel and get back into day-to-day work, but good to be here again for another episode. This week's topic: how your ERP can actually be holding you back. As people watching or listening know, CADTALK is an integration platform between engineering systems and ERP, so we've built up a lot of cross-system experience — and there are some patterns and common issues that show up across essentially every ERP, regardless of the specific tool. Today we're digging into why that happens — leveraging your ERP properly, data integrity, that whole territory. Scott, you've been working in ERP since, what, 1998? What's your general take on how ERP systems can either drive or undermine a business's success?

Understanding ERP as a Tool
Scott: ERP is a genuinely fantastic tool — it really can help you run a manufacturing business better. But like any technology, it's only as good as the process and the data feeding it. I think the biggest thing that holds people back is the assumption that buying the tool makes the problem disappear — when really, that's exactly where the real work begins. The tool gives you a reason, or a project, around which to drive improvement — but without that actual improvement effort, the tool alone doesn't really deliver. Bill Gates put it well: apply automation to a bad process, and you just do bad things faster. That's often exactly what happens.

So a lot of what holds companies back is a lack of solid process, or incorrect data feeding the tool — and also a misunderstanding of what the tool is actually built to solve. Every ERP has its own flavor — strengths and weaknesses. One interesting pattern: as companies grow and "graduate" to bigger, more capable systems, they often assume the new system will automatically be faster or more efficient — and in some areas, it's actually slower than what they had before. QuickBooks is a great example — it's genuinely excellent for running a small business, because it's ruthlessly optimized around a narrow set of very fast, common operations. A small business doesn't need a huge accounting department or dozens of specialized functions, so QuickBooks streamlines invoicing and similar tasks to be extremely fast.

Those same operations in something like SAP might genuinely require two or three people to execute. That feels counterintuitive — "I'm paying 100 times more for this software, why does it now take more people to run it?" But that's exactly the trade-off: more capability and flexibility inherently brings more complexity, and that complexity adds real overhead. Whenever you're evaluating a software decision, you have to ask: what problem am I actually solving, and what's the real complexity-versus-flexibility trade-off I'm accepting?

Right-Sizing Your ERP Solution
Jeff: So it sounds like the tool genuinely needs to be right-sized for the problems you're solving and the size of your business — it's not just "pick whichever one, they're all roughly equivalent." Each has real strengths, but it has to be the appropriately sized tool for the job.

Scott: Exactly — like construction tools. You don't need a sledgehammer to drive a nail. A lot of companies fall into over-buying — sorry to any ERP reseller friends listening, but it's true — purchasing more capability than they currently need because "we might grow into it eventually." Sometimes that's a reasonable bet, but implementing one of these systems is a genuinely massive undertaking, and people understandably don't want to go through that pain twice. So they think ahead five years and try to buy for that future state upfront.

I'd actually push back on that instinct. If you have a solid process and clean data, transitioning to a bigger system in five or six years, when you've actually outgrown the current one, is often the better path — a stair-step approach rather than jumping levels. We've seen this repeatedly: companies are better off growing into each level of software complexity as their business actually grows into it. When people skip levels and over-buy up front, they tend to struggle significantly — sometimes ending up with a failed implementation, or a genuinely bad experience that sours them on the whole category of tool. A lot of ERP implementations fail because people didn't fully grasp the complexity they were signing up for — the tool wasn't correctly sized for their actual problem, they spent heavily to acquire it, and then the added overhead and complexity ate into whatever savings they expected. The benefit simply wasn't large enough, for their size of business, to justify the cost of the added complexity.

That's true of any tool, not just ERP — you always have to weigh that trade-off carefully. If you're not confident doing that evaluation yourself, that's exactly where a selection consultant earns their value — helping right-size the solution. There are other levers too, like automation and integration through something like us, which can streamline the load further. But the key is making sure the expected benefits are clearly defined, and that the added overhead you're accepting genuinely nets out in your favor.

Jeff: So it sounds like step one is defining exactly which problems you're solving, and having a way to actually measure whether you solved them — otherwise you risk ending up with an expensive paperweight instead of the functionality you actually needed.

Scott: Exactly. Thinking back to when I started in manufacturing — the major driver behind our ERP purchase at the time was, and I'll date myself here, Y2K. We had an older system, and there was real concern the date rollover to the year 2000 would break things. That triggered a massive wave of ERP purchases at the time, replacing '70s- and '80s-era systems that had genuine date-handling risk. Selling ERP back then was almost easy by comparison — companies genuinely had to buy something. Layered onto that core problem were other aspirational goals — I don't recall every criterion my old company used, but I know getting more sophisticated with material requirements planning, and especially scheduling, were real drivers, since we were an engineer-to-order shop and scheduling was a perennial headache.

So people were looking at multiple problems simultaneously — "can this system also fix our chronic scheduling issue, while also solving the Y2K date risk?" And to some degree, it did help. Having that kind of clear goal, without piling on too many simultaneously, is a genuinely good approach to a selection process — it gives you something concrete to measure against, and helps justify the investment relative to the effort required. Implementing something like this reaches nearly every part of a company — almost everyone except engineers tends to touch the ERP directly — so it's a genuinely large undertaking, and you have to make sure you're actually capturing the intended benefit.

Change Management in ERP Implementation
Jeff: That's a huge change management exercise. Every conversation I have with partners or customers eventually comes back to change management — how do you manage process changes, and new ways of working, which inevitably require training, retraining, and ongoing support, because people have been doing their job a certain way for years, and now it looks different. The underlying concepts are the same, but the execution changes.

Being a language person by background, I always think of it like learning a new language — even if you already speak one, moving to a new one still means learning all the same fundamental building blocks: grammar, vocabulary, structure — it's recognizably "a language," but it's still a completely different one. Same idea here — new terminology, new software, new screens, new buttons to click. Similar conceptually, but different enough that it genuinely requires real change management.

Scott: Right — and I think something people underestimate is just how central data quality is to all of this. I've seen this constantly, especially with companies pursuing material requirements planning and scheduling — wanting to know when things will actually be done, wanting to give customers reliable promise dates. Data ends up being the real driver behind whether any of that works. Going back to what's core to CADTALK — bill-of-material data, item data, everything that defines what it takes to actually build something — that data is absolutely critical for every downstream function to work correctly. If I'm doing material requirements planning, I need to know exactly what a part is made of, what makes up the whole — the bill of material — plus lead times, vendors, all of it, known accurately enough that the system can be trusted to make decisions from it.

A lot of the time, when we see companies struggling with an ERP implementation, it's not because the system itself is bad — it's because the underlying process or data isn't reliable enough to support the decisions the system is being asked to make. You're automating a bad process, or automating on top of bad data — the classic garbage-in, garbage-out problem. And here's the more interesting nuance: it's often not that the data is flat-out wrong — it's that it's inconsistent. I've said this before, and I genuinely believe it: it's better to be consistently wrong than sporadically right. Humans, generally, tend to be sporadically right — we get things correct, but not consistently so. Software tends to be very consistent, even when it's not always accurate.

Consistency Over Accuracy in Data
Scott: If you're consistently wrong, you can adjust for it — "this measurement is off by 20% every time, so we correct for that 20%." It's the golf analogy I love: if I always hook the ball left, I just aim right to compensate — I know exactly how to adjust. But if I sometimes hit it left, sometimes right, sometimes straight, sometimes duff it entirely — there's nothing consistent to plan around. You can actually shoot a pretty solid round of golf if your miss is consistent, because you can plan for it and adjust. That's exactly how data works in these systems too. A lot of the value we deliver through integration and automation is making data consistently consistent — not necessarily perfectly accurate, but consistent, so you can measure exactly how far off it tends to be and correct for it — aim right because you know you'll pull left, and land in the middle of the fairway every time. Compare that to a person doing it manually, all over the place with no predictable pattern — there's no way to plan around that.

That's exactly what happens when data comes in inconsistently: it's hard to plan against, the tool gets blamed as "useless," and everyone quietly reverts to manual workarounds, and things slowly go sideways. That's the pattern I usually see with companies that spent hundreds of thousands, sometimes millions, on a system, and are still leaning on spreadsheets or manual processes — not because they lack data, but because the data they have is too inconsistent to actually extract value from. That's exactly where we focus a lot of our effort: automating that data collection to make it consistent enough to actually plan against.

Jeff: Two things come to mind here. First — the fitness tracker analogy. Fitness trackers are everywhere now — Fitbit, Apple Watch, Google watch — and there's constant debate about how accurate they actually are: step counts, calories burned, sleep tracking. Research consistently shows these devices aren't perfectly accurate on any of those metrics. But your point holds — the watch is measuring the same way, consistently, every single day. Even if the absolute number is off, because it's applying the identical methodology day after day, you can still use it directionally. If I'm trying to live healthier, and my watch says I'm averaging 6,000 steps — who knows if that's exactly right — but if I make a change and that number consistently climbs to 8,000 or 10,000, I'm moving in the right direction. That consistent measurement, even if technically imprecise, is directionally trustworthy, and I can tailor my behavior to it and get real results, even though the absolute calorie count is probably not exactly right.

Second point, tying to data quality directly — a question I get constantly on demos, when customers are evaluating a new ERP: "when should we do the CADTALK integration — at the very start, or wait for a later phase?" My usual answer: you're buying a new system specifically because your old system had a data quality and consistency problem. If you bring that same manual, inconsistent data collection process into the brand-new system, you haven't actually fixed anything — you've just moved the same problem into a nicer-looking box. Your bill of material drives so much downstream — purchasing, scheduling, costing, labor tracking, material planning — and if you're still manually keying that in with no consistent process, semi-automated at best, exported here, imported there, you're carrying real risk forward.

Local Optimization vs. Global Efficiency
Jeff: You end up with the same fundamental issue — still sporadically right, just on a shinier new platform. You won't get different results from a different system if the underlying data collection habits don't change.

Scott: Exactly — and using your fitness tracker analogy further, if the underlying algorithm changed every single day, the device would be useless. I actually use an Oura Ring, and it explicitly flags in the data whenever their algorithm itself changes — because otherwise you'd look at a sudden jump, like "I'm suddenly sleeping half an hour longer with deeper sleep," and think something changed about you, when really the measurement methodology changed underneath you. They actually track before-and-after separately for that exact reason. Even though the newer algorithm might technically be more accurate, that shift can actually make the data less useful in the short term, because the real value comes from trend consistency over time, not any single accurate data point in isolation. A consistently-off measurement is often more genuinely useful than a technically-more-accurate one that keeps shifting its own baseline.

Jeff: That makes a lot of sense — consistent process and data quality matter enormously. Even though some people push integration to "phase two, we'll handle it later," you really have to weigh all of this when implementing a new system: should integration be part of the initial rollout, and just as importantly, what's your actual data quality situation, and do you want to start clean from day one, or take on that risk later? There's risk either way. Skip it up front, and you risk bringing inconsistent, unreliable data into a brand-new system from day one. Handle it up front, and sure, that's one more thing to fold into the project — with its own risk of falling off the priority list as you get closer to go-live, if it wasn't locked in as a hard requirement from the start. If that happens, you can easily end up right back at the same underlying problem with a shiny new system wrapped around it.

I lean toward handling it upfront — you're already deep in change management anyway, so you can piggyback the data-quality work onto that same effort, right-size the project scope around it, and deliver a genuinely consistent process from day one — then keep improving it over time, which ties back to the continuous-improvement culture we've talked about before. What we typically recommend to customers: get something solid and consistent working first, with reasonably good data quality, and then think long-term about ongoing improvement — not as one giant big-bang effort, but as continuous refinement.

Scott: I agree completely. If I were giving one general recommendation for implementing any system, it wouldn't just be "does this feature work for me" — it's "how am I actually going to get data into a state consistent enough to use this feature effectively in the first place." Don't just evaluate whether a feature exists — evaluate whether you have data clean and consistent enough to actually use that feature well. Then work on getting the data right first, and adopt system capabilities incrementally as your data supports them.

Take costing as an example — what's the best way to get reliable costing data? If you're purchasing a part, that's fairly straightforward — you're buying from a vendor at a known price. But if you're manufacturing or assembling it yourself, there are multiple ways to measure that: manual time-and-labor tracking, or pulling data directly from machines. Machine-sourced spindle-time data might actually be more precise, simply because it removes human variability from the measurement. Whatever method you choose, the real question is how you're going to collect that data — and thinking hard about precision over raw accuracy, which ties right back to consistently-wrong-beats-sporadically-right. Precision matters more than accuracy here, because precision is what lets you actually adjust and plan. Planning your data collection and data cleanliness alongside the functionality you're trying to implement gives you the best real shot at success. People love the eventual outcome and the benefit — but that benefit only comes from the unglamorous work of making sure the underlying data has enough precision to actually plan and act on. Software genuinely loves consistency — it's able to work with inconsistency more and more thanks to better algorithms and AI, but fundamentally, it thrives on consistency.

Final Thoughts on ERP Implementation
Scott: It's a core principle of life, honestly — you can be extremely sharp, but if you're inconsistent, that inconsistency will usually undercut you. Plenty of brilliant, inconsistent people exist — but the person who shows up every single day and consistently grinds away will usually outperform the smart-but-erratic person over time.

Jeff: That's true in software too.

Scott: It is — these systems really do mirror the people using them. We've talked about this before: consistency beats a great idea, every time. You can have a brilliant idea, be extremely smart, or have a genuinely great tool — but if it's not applied consistently, it won't deliver the value you need, because inconsistent output is hard to measure and full of noise; you can't identify any real trajectory in it. Consistent output, even if imperfect, reveals a real pattern — and once you can see the pattern, you can actually make targeted improvements.

Jeff: People chase shiny-object syndrome — wanting every bell and whistle — without wanting to plan for the boring, unglamorous work that actually makes the tool useful, and that requires consistent action over time.

Scott: We keep circling back to the same theme — most of this comes down to sustained, consistent effort over time. "Consistency" might be the single most repeated word on this podcast.

Jeff: It's really the whole point of what CADTALK is trying to achieve — we talk about automation, we talk about better data, but underneath both of those, it's consistency. Consistent data transfer, consistent automation — that consistency is what actually drives real process improvement, and gives you the ability to make confident decisions based on what's genuinely happening, because you can actually see it clearly, all the time.

Local Optimization: When "Solving" a Problem Creates a Bigger One
Jeff: I want to touch on another area in the ERP where I've seen this play out — shop orders and jobs. When you create a bill of material in the ERP, then generate the actual shop floor work order, you often end up with a whole set of sub-jobs, or sub-work-orders — the level of granularity the shop floor works from, alongside the drawings and instructions to actually build the part. Those sub-jobs let you capture data like run time and setup time per work center — but each one also has to be individually closed out at completion, which then rolls up into the parent job. What I've seen happen a lot: people go back and actually restructure the underlying CAD or engineering data specifically to reduce the number of sub-jobs, purely to reduce the labor of closing them all out on the shop floor. Talk through how that kind of decision can quietly undermine a manufacturing operation, and how thinking about it differently can actually solve the real underlying problem without sacrificing the benefits of the ERP or CADTALK.

Scott: I think of this as a classic local optimization problem — everyone optimizes their own small piece of the process. Back when I worked in nesting software, there was a saying: a series of individually good decisions can add up to a genuinely bad overall result. Theory of Constraints covers this well too — everyone optimizing their own little corner of the world, when aggregated, can produce the worst possible outcome for the whole system. Simple example: if I'm trying to optimize a single work center with a high setup cost, I might batch a ton of parts through it at once — great for that one work center locally, but potentially disastrous for the overall shop, because that work center becomes a bottleneck, inventory piles up in front of it, and downstream assembly stalls waiting on parts that haven't finished.

The exact same dynamic happens with process decisions like this. Closing out every individual shop-floor job is genuinely a lot of manual labor — so the instinct is "I can't keep closing all these jobs, let me restructure the bill of material to reduce how many jobs get created." But doing that strips out a layer of data that's often genuinely valuable — remember, the whole point of the ERP is tracking all of this to produce accurate costing, so you actually understand what something truly costs. If your costs jump 20%, and you have granular job-level data, you can trace that increase all the way down to the specific raw material or operation responsible. If you've collapsed everything into one big job just to reduce closing effort, you've bucketed that data into a location where it's no longer useful for that kind of analysis.

So you've locally optimized the labor of closing jobs, but compromised the actual planning value the ERP exists to provide — which arguably makes the whole system less useful overall, even though the specific step you optimized got easier. People get into real trouble this way constantly: fixating on saving one specific step, and unintentionally undermining the larger benefit they were originally trying to capture. What we generally recommend instead: keep your eye on the actual goal. If closing jobs is genuinely too labor-intensive, don't compromise the underlying data collection to work around that — find a way to make the closing process itself faster instead, so you keep the full data benefit without the excess labor. That tends to be counterintuitive for a lot of people. We often see companies restructuring bills of material and job structures specifically to reduce job count, when the better path is usually: leave the ERP working the way it was actually designed to work, and instead find a way to speed up execution within that design — rather than reinventing the workflow itself, which means taking on all the unforeseen bugs and side effects that come with deviating from a well-tested, intended process.

Model First, Then Modify
Jeff: So a genuinely good takeaway here: when you're designing how your system operates, work with how it was actually built to function, rather than immediately reworking your entire process around a shortcut. That doesn't mean you can't change how you work at all — but get the data flowing into the ERP the way it was designed to be used first, and then look for ways to speed that up. We see the exact same instinct with CADTALK implementations — people ask, right out of the gate, "can we speed this up, can we fully automate everything immediately?" Our usual answer: let's first get it working the way it's actually designed to work, get that baseline established — then we can layer in speed and automation improvements. Get it functioning correctly first, then optimize the slow parts — rather than redesigning the whole workflow around a shortcut just to hit one specific goal faster.

Good hot tip here: implement the process the way it's actually designed to run, inefficiencies and all, first. Once that baseline is working correctly and reflects best practice, then ask where the real bottlenecks are, and figure out how to eliminate those — through automation, targeted customization, or some other modification — while preserving all the underlying benefit. Compare that to redesigning the process from scratch chasing one goal, which is like going off-roading: you're off the established trail, and you inevitably hit boulders and obstacles nobody anticipated, because you left the path other people already tested.

Scott: Exactly — model first, then modify. Get the baseline result working correctly first, then modify it to improve. People often try to modify before they've actually modeled anything — before they truly understand how the process works — and end up unintentionally compromising all the benefit, because they didn't understand the system well enough yet to safely change it. Then they blame the solution itself for not working, when really, they skipped the modeling step entirely.

Jeff: That's a genuinely good tip — model it first. Get it running correctly, without overreacting to every small inefficiency or minor bottleneck right away. Once that's working smoothly as designed, then look for targeted opportunities to speed it up.

Closing Thoughts
Jeff: Great conversation again, Scott — some real things to think through around ERP implementation. To sum up, it really comes down to two connected ideas: the importance of process and data quality — consistency — and modeling before modifying, which really go hand in hand, because once you've modeled something consistently, you can start making targeted micro-improvements from a stable baseline. My two takeaways: first, get a consistent, measurable process in place, and carry that consistency all the way through — model it, execute it consistently, get the data collection right. Then, layer in the micro-improvements elsewhere that compound over time into the outcome you actually want — rather than trying to engineer the perfect end state from the very beginning.

Scott: That's a great way to frame it.

Jeff: Great conversation, Scott — a bit nerdy again, but hopefully genuinely useful for anyone evaluating an ERP or rethinking their processes. CADTALK is really built around automating the engineering-to-manufacturing handoff — pulling information from CAD, PDM, and PLM systems into the ERP. Working across so many different platforms and customers, we get to see the patterns that repeat regardless of the specific tools involved, and we're trying to help listeners map their own path through that, with useful frameworks for thinking it through — so whether or not you end up using CADTALK specifically, you're set up to make the best decisions for your situation. Anything else you'd want to leave listeners with, Scott?

Scott: Not really — just, if you've got thoughts on this, leave a comment. We're genuinely trying to build more engagement — I love seeing the comments, we got some great ones on the last episode, and it gives us real feedback on how useful these ideas actually are for people going through these processes, implementing an ERP, or just trying to improve their business. We want that feedback, so we know what to lean into more, and what to do less of.

Jeff: Agreed — subscribe, comment, let us know what you'd like to hear more about. I'd genuinely love to hear where people are running into real challenges, so we know where we can add the most value by sharing what we've learned. Looking forward to next week's conversation, Scott — and just a reminder, we're CADTALK software, you can find us at cadtalk.com, with plenty of blog content and other resources there. Feel free to check out the site, and Scott, we'll see you next time.