How to solve file-based dependency in Manufacturing

How to solve file-based dependency in Manufacturing

Ever since I started my engineering career in the mid-90’s, one of the least appreciated pain points I’ve experienced is the problem with files. As a product moves through the lifecycle, product information passes from engineering to downstream teams, including procurement, manufacturing, marketing, sales, and service. This downstream information flow is extremely challenging, with significant time spent preparing and packaging files to facilitate workflows. But is that fair for the downstream users? Although it may be assumed that they have access to the same tools and data that engineering has, most don’t have the same hardware or level of experience using the tools as engineering does. And, often these tools are not well suited for the downstream personas and workflows to do their job correctly.

These are the core challenges that a file-based dependency creates. Every company experiences this pain in some form or another, but most don’t know how to address it. A question I pose to many of the customers I speak to at Vertex is, “What do you need a file for?” If the answer is, “So downstream teams and I can see the product,” then you don’t really need a file. There’s a better way.

How Engineers Share Data Downstream Today

Every engineer knows that when they are working with one tool and a supplier works in another tool, they must use a neutral file format to exchange data. In fact, that’s why the first neutral file format (IGES) was created. ANSI published IGES in 1980 to encourage interoperability and make it easier to exchange files between engineers using different design tools. Fast forward 40 years, and neutral file formats are still one of the most common ways for individuals and teams with different technology toolsets to exchange information. 

Challenge 1: The “Ease” of Sharing Neutral Files Outside of Engineering

There are two major challenges with sharing neutral files. The first is: how easy is it to actually share a neutral file outside of engineering? Neutral files are a compromise at best. Most of the time, the sender can’t deliver high fidelity files due to end-use tool constraints, so they have to simplify a file prior to sharing, which means they need to strip out important details to make the file smaller. After the file is sent, receivers still have significant dependencies to view and understand the file:

• The most obvious requirements include the right hardware and software to view the file in the correct context. There is an expectation to view information with a web-based experience, a far-flung comparison to most PLM or CAD tools.
• The ability to iterate with engineering. Downstream teams may want changes or require a different way to view the file, but the ability to share that information back upstream is extremely challenging (I discussed this at length in a separate blog that I encourage you to read here).

Challenge 2: Sharing Files to Teams Without CAD or PLM

Now, let’s look at the second major challenge with neutral files. The assumption is that the recipient can access the file through the CAD or PLM tools. What if they can’t? They are then forced to ask the engineering teams for help. Assuming the leadership team approves, engineers have to drain valuable time into preparing the data—such as exporting to common formats and stripping out sensitive components—so they can send it to downstream teams. Recipients often feel like they have to beg for a small percentage of what they actually need to make decisions. Even with CAD or PLM access, the downstream teams rarely have the skills to prepare these on their own. 

Files also don’t generally provide the flexibility to deliver the product data in a context that the recipient needs to make decisions. Each team tends to have its own “language” around their BOMs or toolsets. For example, engineers might refer to part numbers, while sales might refer to the marketing terminology. That context—whether it be in a manufacturing BOM, sales CPQ, or service assembly sequence—is critical for each team to get work done quickly and efficiently. Sending files from engineering means that every team has to attempt to “decode” engineering’s language to get the expected value that the file can provide. 

Stop Depending on Files to Visualize Product Data

Everyone knows this is a challenge, but companies and teams can feel resignation that there’s not a better way. This complicated and cumbersome process of file sharing opens the door for miscommunication, loss of feedback, orphaned data, and IP risk. The workflows are time-consuming and very expensive. I’ve talked to some companies who have an entire group or hire a third party dedicated to this kind of work. Depending on the model complexity, it can take months to prepare data to share. 

With all this in mind, we have to go back to the root of the problem: why are we even sending files to begin with? That’s what we’ve been doing since the 1980’s, but in 2021 there could be a better way. The first step is to understand what exactly downstream needs to do their job. That then directs what the best and right way to deliver information should be. In many cases, it might not even be by sharing a file at all. It might be as simple as sending a 3D visual. The 3D visuals can show intent for engineering, manufacturing, sales, service, and every workflow in between. Every team can look at the visual—whether it be on a phone, desktop, laptop, or tablet—and know it is a direct relation to the product in the physical world. Some would consider this to be a digital twin.

Originally this article was published here.

 

About the author

This article was written by Jim Zwica. Jim serves as a solutions architect and strategic product expert and voice of the customer for Vertex Software. He has extensive experience in product lifecycle management (PLM) and collaboration throughout the supply chain, giving him unique insight into customer needs.Jim’s experience with PLM began in the late ‘90s, and developed into a strong strategic and consultative approach..