Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Part Releases, Revision Management, and Release Cascade up the Product Structure

aeromorrisonaeromorrison Member Posts: 7 PRO
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.

Comments

  • S1monS1mon Member Posts: 884 PRO
    I very much feel your pain. I'm still wrapping my head around the best way to manage these issues, compounded with working with top-down design and development.

    Other places I've worked and various configuration/change management books etc that I've read would agree with your best practices. I'm trying to drive things that way at my current company. One caveat is that I like to pull P/N as early as possible in development so that prototypes are made from things with P/Ns. I'm ok with violating the form/fit/function rule during development, and keeping the same part number even with some major revisions. As soon as we get to EVT/DVT/PVT, then a form/fit/function change should drive a new P/N.

    Can you be a little more explicit about your document structures?
    1. Does your company use a document per part, or document per assembly or document per project? 
    2. When you do releases, how many parts and drawings are rev'd at the same time?
    3. When do you create versions of assemblies vs revisions?
    4. How are you integrating Onshape with your MRP/ERP system(s)? (and what one(s) are you using?)
    5. If there is an update mark in an assembly, when do you chose to update the part(s)?
    6. What sort of history do you need to retrieve when it comes to BOMs? Do you need to be able to pull up all the correct revisions of parts at a particular snapshot in time, or are you just looking for the assembly to show the latest part revisions all the time.
    One way to keep the documentation easier that I've seen is that the assembly drawings have exploded views and a BOM table with item numbers, but no part numbers. Manufacturing SOPs also refer to item numbers. Typically the assembly drawings and SOPs only get updated if there are part quantity changes, or part revisions are so different, or the assembly process is so different that it no longer makes sense. If the draft on a part changes, you don't rev the assembly drawing. Then there is a separate BOM document with item numbers and part numbers which does get revised to track the revisions of the parts.

  • tim_hess427tim_hess427 Member Posts: 648 PRO
    I think I mentioned this in another thread, but you CAN make a BOM table that just doesn't show the revision level. So, it would be possible to release an assembly, and if something below it changes, but you determine the assembly does not need to be revised, you can just leave it as-is and ignore the prompts to update it. OR you could "update" the assembly in the workspace so that it has the most up-to-date data, but just not release it. 

    Would that process work for you?

    I'm actually really curious about this issue, as I have dealt with the same thing with medical devices. In our system, the process was to always roll the changes all the way up to make sure even the smallest change at the bottom could be seen by looking at the top-level changes at the top. It was not an efficient process. 
  • aeromorrisonaeromorrison Member Posts: 7 PRO
    One caveat is that I like to pull P/N as early as possible in development so that prototypes are made from things with P/Ns. I'm ok with violating the form/fit/function rule during development, and keeping the same part number even with some major revisions. As soon as we get to EVT/DVT/PVT, then a form/fit/function change should drive a new P/N.
    I completely agree. I've added a custom field into my Onshape metadata that is called "Lifecycle Phase". This is where I set business rules for item usage such as 'prototype', 'production', etc. If an P/N is assigned and released as 'Prototype', for instance, our team knows via our quality system documentation that they're only allowed to do prototyping with that time. It still has a P/N, though, to support clarity with development.

    Can you be a little more explicit about your document structures?
    1. Does your company use a document per part, or document per assembly or document per project? 
    2. When you do releases, how many parts and drawings are rev'd at the same time?
    3. When do you create versions of assemblies vs revisions?
    4. How are you integrating Onshape with your MRP/ERP system(s)? (and what one(s) are you using?)
    5. If there is an update mark in an assembly, when do you chose to update the part(s)?
    6. What sort of history do you need to retrieve when it comes to BOMs? Do you need to be able to pull up all the correct revisions of parts at a particular snapshot in time, or are you just looking for the assembly to show the latest part revisions all the time.
    We're still defining our processes and learning. Onshape is obviously very flexible, which is great but does require wrapping some business practices around it. Right now we're generally doing an Onshape document for all of the parts that might go into an assembly and then keeping the actual assembly in a separate document. However, I'm still not totally happy with our practices in this regard. We're learning new things and discovering new problems all the time. We're very much on the learning curve still. Some of the fundamental behaviors in Onshape regarding visibility of changes and 'out-of-date' files are making this pretty challenging.

    We generally use the Gitflow strategy with our branches, but the fact that versioning happens at the whole document level causes us to have to break out more layers of documents than we would prefer given Onshape's powerful capabilities. We use a version numbering scheme in our branches to maintain some thread of clarity and things develop. This scheme also ties to releases, but it's obviously at the whole document level. The concept of numbered Engineering Change Notices in releases would be a nice addition.

    Ideally we could keep a release branch which really only includes released items and a development branch (with sub-branches) that includes the latest development work. The merging process does not make this easy.

    On the MRP/ERP front, we don't have a digital integration at this point. Our production personnel are included as followers on releases and then they make the changes on the production side to keep things aligned. Eventually we plan to automate this process but we need to have stable practices before we can accomplish this. The current need to revise everything up the chain leads to many production MRP/ERP changes that don't add any value.

    As far as history, our regulated aviation products require us to be able to have a traceable history of the product design and all changes. For product support and safety issues we need to be able to pull up the 'correct revision' of assemblies and not just the 'latest revision'. That said, the correct revision of assemblies is only pointing to component P/Ns (without revision). The same is true as you go up the chain of assemblies.

    I agree with your exploded views and item numbering ideas with drawings. We certainly use this technique with service documentation. For fully detailed engineering drawings for critical assemblies we need them to be fully detailed with the P/Ns.

  • aeromorrisonaeromorrison Member Posts: 7 PRO

    Yes. I agree that it's possible to hide the part revision in BOM tables. That's certainly helpful. The challenge with ignoring prompts highlighted when there are changes is that it become very convoluted to really know where things stand on larger and larger assemblies (like a whole aircraft) when these prompts are all cascading up the product structure. However, this is basically what we're doing. It's difficult to not make mistakes when selectively updating things through the tree.

Sign In or Register to comment.