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

aeromorrison

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.

S1mon

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_hess427

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. 

aeromorrison

@S1mon

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.

aeromorrison

@tim_hess427

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.

Pierre_Lin

I'm also curious about potential solutions to this problem.

I've been wondering if use of major and minor revision numbers for assemblies could help e.g. 1.1, 1.2, 2.1, A.1, etc.

It would not address the fundamental issue of having to cascade every released revision to the top but might help distinguish what is a minor change (form/fit/function the same) to a major change (form/fit/function different).

aeromorrison

I could see this possibly helping some, but I wouldn't want this functionality to mask the underlying cascade issue.

adrian_vlzkz

You are asking for a solution that is typically in Change Management, which in my experience is a component of PLM system(software),  the concept of all revisions being interchangeable is unique to every company or even process within companies, it is not a standard.

In change management there's the concept of Material Disposition, which indicates how the new and old revision are to be handled, in WIP and in inventory.

In the Medical Device regulated industry we definitely need for Parts to have Revisions, since introducing new Part Numbers to a BOM that is in a Commercial state will require extensive testing, trials, validation and documentation, where as a revision inherits a lot of the data in those stages.

My recommendation would be to look at Arena, and see what solution they offer for Lifecycle and Change Management

aeromorrison

Thanks @adrian_vlzkz

I certainly understand that business practices and industry demand specific solutions in some cases. There are certainly well recognized best practices in popular publications and industry standards related to these revision interchangeability concepts including: Manufacturing Data Structures, CMII for Business Process Infrastructure, Configuration Management Deskbook, MIL-STD-100G, etc. that would all support the revision concepts I'm describing, and it's quite prevalent. I work in the aerospace industry which is similarly regulated to the medical industry and this approach is very common here.

However, my key thrust in this thread is that Onshape provides no flexibility in what is identified as a 'change'. If I change the hue of the display color of a component to make it easier to see when modeling, for example, and create a version then every higher-level assembly now will indicate an out-of-date condition. The only way to resolve this is to process formal revisions up through every higher-level assembly that uses this item and none of that is value-added work in this example, especially as it cascades its way into the manufacturing systems. There seems to be no means to indicate whether a change should trigger the need for a revision or not in accordance with the "Formal Release Management" function in Onshape. I've also not discovered/developed any procedural approach (although I'm continuing to think on this) using branches, versions, etc. that provides a compelling work-around.

I'd love to hear how others are handling this as this may spur new ideas and solutions. It seem that selective merging may provide some opportunity to lessen the occurrence of this.

Nath_McC

As the release management has the issues you describe, I don't use versions of a part and see them as a snapshot in time. Versions are used differently from how I use revisions on drawings.

As you describe, my models will have a new version every time a change is made. This change would update a drawing, but if the drawing does not "technically" change, the drawing will not change revision (via the revision table). My MRP system is what is managing the revisions, not Onshape.

If I make a change, that means the drawing needs to be updated; I will update my drawing and the revision table. This, in turn, will be saved on the next release. I name that release either the new drawing revision or the ECO.

I may work on version V1234 of the model, but my drawing may only be revision C. This way, when I get the message that other parts need updating, I can update them without any issues. Development work would also be branched off and combined if It was found to be helpful following an ECO.

In the short term, I don't use the model versions to determine my part's revision.

I don't work in the aerospace industry, and my workflow is rather primitive for my small assemblies, but I can understand your issues with the lack of flexibility.

aeromorrison

Thanks @Nath_McC for these insights. It's good to hear about other's workflows as well. I'm only using formal revisions as revisions. I also use versions as a snapshot in time. The behavior of these versions as they trickle up through the rest of the higher level assemblies is what creates the big challenge here. In addition, the types of changes that Onshape flags as requiring a revision in the formal release processes result in non-value-added changes up through the product structure and therefore into our downstream ERP system.

Cary_Bettenhausen

For our purposes as a contract manufacturer of medical devices (where the customer "owns" the design) we simply need the flexibility to keep higher-level assemblies up-to-date with the option to up-rev these higher-level assemblies if desired. We do not want (or need) to bother our customers with every Mickey-Mouse change we make internally because these must be pushed uphill to the top-level assembly every time.

A simple "Minor Change" function with full audit trail in the Versions and History would be all we need.

aeromorrison

As a current workaround, we've ended up implementing a custom revision scheme that implements a major/minor revision concept. We basically use XX.YY where XX revisions (e.g. 01, 02, 03) require full change management and YY revisions (e.g. 02.01, 02.02, 02.03) can just be implemented and released by the designer within Onshape on an as-needed basis and have no bearing on anything downstream. Major revisions have different business rules around them from minor revisions. So far this has worked adequately and have saved a lot of headaches.