This is a whole other level of complexity compared to, say, accounting, where a single payment is recorded as a standalone item. Subsequent payments are tabulated and recorded but don’t affect the previous one. The record of each payment is what it is, and entries are never revised, only added to.

But when you are in a manufacturing environment it’s essential to accommodate the underlying structure of your data, the history of revisions, and the sheer complexity of the multi-stage processes needed to deliver a product. If you don’t do so your data becomes problematic.

The link between knowledge and quality

There are of course significant quality implications to controlling this volume of data—in production-quality intervention as well as quality forensics.

For example, it’s not just the overall details of a widget design, Part Number X. It’s about specific details of this widget X, at this revision, using these optional manufacturing toolsets, on this date, and maybe even at a specific time on that date. You need to be able to comprehend the entire DNA of that item to fully understand the scope of your data and how different phases in its evolution can impact the outcome.

Times have changed in the manufacturing world. At one point in the past, when just-in-time manufacturing was less of a thing, and we had warehouses full of 10-years’ worth of widgets, you could squirrel away a drawing of that widget in your desk drawer and it was fine forever.

Source: Razorleaf

That’s just not the case anymore; the way we make things today has changed dramatically. Now products are designed by teams—updated, improved, customized, discontinued—constantly changing status over time. Automation has certainly improved production speeds, but the challenges of making today’s products now extend to questions like “Are we getting this product data in real time?” and “Are we accessing it from the entire system of records to ensure we have the right items at the right revisions at the right time?”

Digital software tools that enable the creation and capture of manufacturing data come in many flavors: CAD, PLM, ERP, MES, and more—these provide an enhanced foundation for thriving and competing as a manufacturing enterprise today. But if you don’t integrate these systems so they can accurately hand off information to each other, you may be creating internal inefficiencies, roadblocks and workarounds that will surely impact final product quality.

Source: Razorleaf

Source: Razorleaf

Sea Box mechanical engineer Korey Greene works on the CAD design of a custom container. Integrating their digital design tools with their PLM and ERP software is boosting ROI at the company. Source: Sea Box

Now, if you’re making wooden legs for a table—and that’s the only thing you make in your business—you can get around this need. But if you’re making anything more complex than a single piece of wood you need today’s digital tools—properly integrated to optimize your product.

Advanced tools are great—if they’re connected

Here’s a hypothetical example of a complex manufacturing enterprise that has begun embracing advanced digital tools. They’re using a CAD system for their design engineers. An enterprise resource planning (ERP) system that tracks finance, HR, supply chain, and inventory. There’s also an MES (manufacturing execution system) that monitors, tracks, and controls complex manufacturing systems and data flows on the shop floor in real-time. Sounds promising.

But now suppose the MES picks up data that says something’s not right in one of the work cells. A drilled hole isn’t big enough for a connector. Yet MES isn’t connected back to design to raise a change order. So someone makes a quick fix on the floor by simply changing a hole size out—and nobody else in the enterprise knows it happened.

Now you have a real problem. From a quality perspective, control has been lost; in the future there will be ongoing issues with this part because the original issue will not have registered upstream with design engineering, and the on-the-fly solution will not be known outside that single work cell. If the different disciplines are not fully connected, you are making decisions in a vacuum. This certainly affects throughput, and even your “product as a service” offerings, for which you need to be certain that what was designed for a specific customer is actually being built.

I remember an example of this from my early days in engineering. I would draw a product, create an exploded assembly, and go out on the shop floor to watch the team put it together. I’d say, “Hey, what are you doing, that’s not the way you’re supposed to route that wire harness.” And they’d say, “Pfft, you can’t route it the way you drew it so we’re doing it this way.”

Again, quality is being affected: because the design wasn’t followed, wires are chafing and we’re getting shorts. I designed the layout to avoid shorts but manufacturing can’t build it that way. Because there’s no communication between us, they just do what they think is best. Bless them for trying but meanwhile we don’t even know what product we’ve shipped out.

The imperative for middleware

At least there’s now general agreement among manufacturers that issues like these persist and must be addressed. And, as the complexity of systems has increased over the past several decades, a host of commercial “middleware” solutions have been created to help connect and integrate systems in a variety of industries.

But do these solutions truly understand the uniqueness and scope of manufacturing data? Can they track Bills of Materials (BOM) from a PLM system to an ERP system, starting with loading the “children” and then doing the sub-assemblies, then the higher-level assemblies and creating the links between them? Do they know that a revision is actually a facet of the part identifier, not just the part number? Given the parametric and associative relationships between families of CAD, beware the hazards of moving a single file without understanding what the impact of doing so will be.

What is needed is product-aware middleware for manufacturing. Yes, you have to connect your systems, but you must do that with tools that completely understand the nature of what’s being connected.

Source: Razorleaf