Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.First time visiting? Here are some places to start:
- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
Part Releases, Revision Management, and Release Cascade up the Product Structure
My team has been using Onshape now for about 18 months and it has resulted in much more agile and rapid development on the whole. We build regulated products in the aviation/aerospace market and precise configuration management is very important to our business.
Our company's biggest challenge with Onshape currently is revision management and the apparent necessity to cascade every released revision up through the entire product structure to maintain a pristine released product structure. The large majority of changes cascading up the tree are unnecessary and create many, many 'no value' revisions to assemblies just to keep Onshape aligned on the released product configuration. These cascading revisions then have to be cascaded further to downstream systems such as MRP/ERP. This creates a lot of needless churn. In addition, in our regulated industry we normally have to engage the regulators on any product change and also gain their approval on changes. This is a long process that can take weeks or months, so we cannot afford to have phantom changes propagating up through the product structure that the regulator does not understand since there is no 'real' change.
Best practice in product configuration management say that "parts do not have revisions" from the standpoint that revisions to P/Ns cannot impact form/fit/function or interchangeability. A revision to a part should not impact any assembly where it is used and part numbers of any revision status should be stored in inventory in the same bin. If a change will impact a higher level assembly then it should be assigned a new part number. A part number change then only cascades as many levels up the assembly tree as required before no longer affecting form/fit/function or interchangeability. In many cases this is only one level. Part revisions should never have a need to cascade up the chain as those revisions should not impact form/fit/function/interchangeability.
We've been heavy users of Onshape for the last 18 months, but I could certainly be missing something here--I hope so!! Has anyone managed to tackle this problem in Onshape in an elegant manner that avoids non-value-added revision cascades? Overall we're loving Onshape and have found it to be a "breath of fresh air" from a development standpoint. The ongoing configuration control and change management after the development process is where we're struggling.
I'd love to see a new Company setting that allows for uniqueness in parts to be determined by P/N and not revision. In other words, the Product Structure (or BOM) should only need to include the P/N of item and should not need to include the revision level. Part revisions should be automatically absorbed by the higher level assembly. This change would solve my company's biggest challenge with Onshape and make both engineering and production personnel very happy. It would probably save our relatively small team 20-25 hours of labor per month that could be applied to product development efforts.
Any ideas or thoughts would be greatly appreciated.