Fail fast? What? Why would you want to find problems in your designs? While it may be uncomfortable to admit mistakes, it is important to examine why it is actually a good thing to find problems earlier rather than later. Think of your mistakes as opportunities for iterating and improving on your designs, ultimately resulting in better products.
Let’s review what happens in a typical design and manufacturing workflow for the next greatest Internet of Things (IoT) product. Take a look at the graph below. In this scenario, the first engineer comes up with the project specification and basic design, and puts the design into a CAD system. The initial design is made up of numerous files representing individual parts and assemblies. The second engineer to interact with the design picks up where the first engineer left off, adding more mechanical elements to the housing part files for the product.
Enter the third engineer, who is more involved in the electronics that drive the device, and discovers that the style and some of the initial mechanical concepts will not allow for proper airflow through the device. Furthermore, he determines that the locations of the interface need to move, which affects the styling – requiring several more edits to the part and assembly files.
Notice in the diagram that only one person at a time can work on the assembly or a part file. The interactions between the three engineers on the design team are not happening in real time. First, a copy of the files are opened on a copy of the CAD system. Then the engineer saves a new copy of the CAD files, closes the files and then uploads the files to some sort of server. If the engineer does not have a copy of the CAD system, he or she is forced to use either a separate viewer product or separate PDF file copies of the original CAD files.
This workflow is much like a relay race, passing the baton to the next runner. Only one person at a time can actually open these files to view, comment or iterate on the design. Now, imagine this “relay race” design and manufacturing workflow happening across a globally distributed supply chain. Sharing large CAD files with a complex reference structure makes it much tougher to communicate and work together efficiently.
Working in Parallel
The above scenario is by far the most common workflow being used today. It’s a design approach defined by a sequential, stage-based process, versus teams working in parallel. When teams work in parallel, they can start their tool design as soon as the detailed product design has started. They can start on detailed design solid models before the concept design surface models are complete. Although working in parallel does not necessarily reduce the amount of manpower required for a project, it does drastically reduce lead times and thus time to market.
Feature-based CAD systems have for many years allowed simultaneous work on 3D solid models and 2D drawings by means of two separate files. Some CAD packages also allow associative copying of geometry between files. This allows, for example, the copying of a part design into the files used by the tooling designer. The manufacturing engineer can then start work on tools before the final design freeze; when a design changes size or shape the tool geometry will then update. Concurrent engineering also has the added benefit of providing better and more immediate communication between departments, reducing the chance of costly, late design changes. It adopts a problem prevention method as compared to the problem solving and re-designing method of traditional sequential engineering.
As supply chains are now much more distributed and work is accomplished by multiple organizations in different locations around the world, concurrent engineering makes a lot of sense. But it cannot safely happen as there is no centralized data store that people can work on simultaneously. Why? Because file-based CAD systems rely on local files that are locked once a single user wants to edit the information. This forces collaboration to wait until later in the design cycle. To add insult to injury, the further along in the design cycle a problem is discovered, the more the cost of correcting that issue goes up. This phenomenon is known as the “Cost of Change.”
The Cost of Change
So let’s talk about the “Cost of Change” when new iterations can be most costly. Imagine if a design problem was found in the manufacturing process with an external vendor. Since file-based iteration is happening inside your corporate firewall, the vendors that you work with for quoting and manufacturing a design are not part of the process until much later. If the vendor notices a manufacturing improvement or issue, the cost of that change would be high because large amounts of billable hours have occurred ahead of the vendor’s proposed change. This cost would be even higher if tooling had been cut. So the earlier a change in the design happens, the less costly the change.
There are also other benefits to finding design issues earlier in the lifecycle of a product. First is reducing the time it takes to get a product into production. Next is a metric called “Cost of Delay,” coined by Don Reinertsen, that can help create urgency within the product development process. Since your development timeline is reduced by iterating sooner internally and externally, you will most likely be releasing your product ahead of competitors.
More and more companies are now discovering the value of adopting parallel workflows in the product development process. As you can see in the graph above, the cost of iterating gets lower as more people are involved simultaneously. Suppliers can have design input much earlier. There is a lower total cost of delay and cost of change.
Onshape’s cloud design platform – which includes CAD, release management, built-in version control and collaboration tools – fully supports this iterative, parallel workflow that helps companies speed up their time to market.