How to work with configurable items/options in a BOM?

[berg_lauritz]

Another of those inter-department connecting questions I've been asking:

How do you work with configurable items regarding BOM & how do you set them up in SolidWorks?

Example #1:
We have the option of adding an additional solar panel &/or a satellite dish to our roofs.
The holes are cut into the roof regardless.
But later on the holes get covered or they don't - depending on the chosen options.
This results in this case in 2^2 different options for the roof alone.
But additionally the wiring & connected parts are different in other assemblies.
I know that DriveWorks always usually works either with configuring dimensions or suppressing/un-suppressing parts/assemblies or changing configurations.
Is that the intended way? I can see applications for i.e. different sized cabinets where you just put in the measurements & you get a job for those exact dimensions.
Configuring those options (i.e. for the roof) across multiple assemblies is an insane job in my opinion to do in SolidWorks.

Example #2:
We have the option to put a generator onto our chassis. The 'standard option' is to have no generator. Having a generator is a huge difference across the hole structure though:
Components get obsoleted/added in multiple assemblies & depending on other options you may have to add/remove other things.
So the best way to tackle this would be to only manufacture the 'necessary' parts/have a BOM with the least amount of shared parts.
Do you add a 'placeholder' for all those things?
We currently have a 'standard option' & modify this according to the chosen options. We are not happy with this because we can not quickly change the BOMs if the customer decides to add something/remove something. This also means that BOM has to 'substract' something only to add something else.
How do you track those options & their changes across all assemblies?
It would be nice to have a 'super assembly' for a specific option with all the parts for this option in there. But how do you properly insert this into other assemblies? Or do you just 'throw it together'?
How do you link their placement in there? With the unfinished envelope publisher? Do you even link the placement?
How do you make sure into which assembly to put those pieces from the maser assembly? Custom properties? Instructions? Does you BOM deal with this?

[the_h4mmer]

Another of those inter-department connecting questions I've been asking:

How do you work with configurable items regarding BOM & how do you set them up in SolidWorks?

This results in this case in 2^2 different options for the roof alone.

Where I am at, each unique file is it's own part number (component or assembly). It creates quite a bit of file management, but it's simplistic enough to work. The biggest tradeoff is that like you said, it creates quite a few different configurations for assemblies. As an example, we have enclosures that are modeled with various components, but any single component or many can be specified to be replaced by a customer, which means that we must have a new assembly for any deviation from a "standard" or previously made assembly.

The interdepartmental component of that is that I have to temper the expectations of Sales to understand that when they have a customer asking for a fully custom designed enclosure for quote, that there is going to be multiple days before it's ready.

Regarding how to handle cut outs, that we do inside the assembly (assembly feature) so the base part number for an enclosure will always be the same, but the cutout is specific to the assembly (but this can be dicey depending on your stance with in-context references, or your vigilance is preventing them). Again, with the enclosures we have, the same base part gets used in multiple assemblies, so we don't want to have a part with cutouts for every specific iteration, so we only make the cutouts as part of the assembly and make sure to dimension them on the drawing.

Regarding the 'changes' you mention in example #2, I've been driving towards better project documentation and management. If you're seeing lots of mid-project changes, I'd highly recommend getting control of that and making them Design-Changes/Change-Orders or whatever you choose to call it. We've had a lot of projects with fuzzy scopes that were heavily burdened by the fleeting whims of a customer, which drove me mad with all the changes and rework. I've clamped down on that by making Sales get an agreed upon project scope that's signed off by the customer and Engineering so that we all agree with what the work will be moving forward; with the understanding that anything additional is going to cost more, move the schedule, and may not be able to be addressed up front.

I know what I wrote doesn't 100% answer your question, but from my read it seems like there are some process related controls that could be put in place (along with expectation tempering) to help. Perhaps others may chime in with more salient input, but I hope something I wrote is helpful.

[bnemec]

Edit: maybe I should have prefaced this with, "We don't use configurations for configurable items", instead each option gets its own part number as well as model and drawing file.

Sounds a little bit familiar, realizing that there can be factors outside of Design Engineering that affect modeling practices. We are rehashing how these things interact in a big way recently and IMO, this is consultant topic, not so much discussion in a forum, mostly because there's so many variables to explain and give context to that every post is TL,DR.

I'll try to explain some of our practices (wrong or right) in the example you brought up.

Every roof gets all the holes; for us that would be one set of part numbers, pc parts up through the "roof assembly" then at the assembly level that gets solar or antenna those would each be their own part number and file. So we would have three assemblies that use the roof assembly; one with plugs, one with the solar kit and one with antenna kit. Unless there is more than one option of solar or antenna, then we would have another assembly file for each of those. In other words, there's one part number per file. One the ERP side every part number has BOM and Routings, orders, inventory control, statistical data etc. Weldments are assembly files and the drawing has a BOM table, each component in the assembly has it's own part number in ERP and model and drawing in CAD.

At our top level we have a model and drawing for every combination that has ever been requested. In your example we would have:
generator: Y/N
solar: 20W, 40W, 80W
antenna_A: Y/N
antenna_B: Y/N


I failed statistics so I'm not good at counting patterns, but I think that's 24 possible top level part numbers?

Keeping all of it updated and minimizing duplicates is a lot of work. As I said, we're constantly looking for another "least bad" option.

[XHawkeye]

The part count on our assemblies isn't large so making every option a config isn't a problem. If it's on the ERP BOM it needs to be on the SW BOM. Loctite/solder/etc are in the SW assembly. Cables are done w/ ACAD so while there may be 4 different cables just need a correctly routed faked cable with 4 configs to drive the BOM p/n.

Examples:
1) An assembly with 35 configurations covers 2-6 channels over 7 frequency ranges. Each frequency range has a drawing because the base p/n is different. [ So there's (1) assembly file driving (7) drawings. The SW BOM has 26 items. ]

Capture132.JPG (19.16 KiB) Viewed 3441 times

2) Another assembly has 20 configurations but the same base number so there's only one drawing. [ The SW BOM has 13 items. ]

Also have the advantage in that I only deal with standard products. Specials (non-standard assemblies) are given a unique p/n and sales engineering redlined assembly drawings for mfg and enters the BOMs into ERP. I only get involved with they need a new part(s).

[the_h4mmer]

We are rehashing how these things interact in a big way recently and IMO, this is consultant topic, not so much discussion in a forum, mostly because there's so many variables to explain and give context to that every post is TL,DR.

It probably is consultant territory, but I think it's a good exercise to discuss it (I find value), since I couldn't find many resources on this very topic. Wonder how much and/or what it takes to be THAT consultant....feels like something I could really get into as I've spent a lot of effort in the exact area in my current role.

At our top level we have a model and drawing for every combination that has ever been requested. In your example we would have:
generator: Y/N
solar: 20W, 40W, 80W
antenna_A: Y/N
antenna_B: Y/N

I failed statistics so I'm not good at counting patterns, but I think that's 24 possible top level part numbers?

Keeping all of it updated and minimizing duplicates is a lot of work. As I said, we're constantly looking for another "least bad" option.

It's still early for me, but I think that's 36 total possible combinations. There are 4 options, with a total of 9 possible selections, which would give you 4*9 = 36. Definitely, maybe

[berg_lauritz]

Edit: maybe I should have prefaced this with, "We don't use configurations for configurable items", instead each option gets its own part number as well as model and drawing file.

Sounds a little bit familiar, realizing that there can be factors outside of Design Engineering that affect modeling practices. We are rehashing how these things interact in a big way recently and IMO, this is consultant topic, not so much discussion in a forum, mostly because there's so many variables to explain and give context to that every post is TL,DR.

I'll try to explain some of our practices (wrong or right) in the example you brought up.

Every roof gets all the holes; for us that would be one set of part numbers, pc parts up through the "roof assembly" then at the assembly level that gets solar or antenna those would each be their own part number and file. So we would have three assemblies that use the roof assembly; one with plugs, one with the solar kit and one with antenna kit. Unless there is more than one option of solar or antenna, then we would have another assembly file for each of those. In other words, there's one part number per file. One the ERP side every part number has BOM and Routings, orders, inventory control, statistical data etc. Weldments are assembly files and the drawing has a BOM table, each component in the assembly has it's own part number in ERP and model and drawing in CAD.

At our top level we have a model and drawing for every combination that has ever been requested. In your example we would have:
generator: Y/N
solar: 20W, 40W, 80W
antenna_A: Y/N
antenna_B: Y/N


I failed statistics so I'm not good at counting patterns, but I think that's 24 possible top level part numbers?

Keeping all of it updated and minimizing duplicates is a lot of work. As I said, we're constantly looking for another "least bad" option.

This is exactly what we would face. With the little difference that it would be exponential madness for us (too many changes across multiple assemblies going further up the tree) & it feels wrong to have this problem solved in SOILEDWorks.

So here are some ideas that we threw around recently (including this idea):

• no configurations in components!
  Have every difference (i.e. Generator y/n, Solar 20/40/80) as its own assembly & live with the exponential amount of assemblies. Maintain this structure i.e. in a table
• configurations in components!
  try to get hold of multiple configurations through design tables & linking it i.e. to external sources
• solve the problem at a different stage
  • put EVERYTHING always into the components! (could look messy...)
    kind of like having no configurations in components with the exception to list all the parts ALWAYS on the BOM. Tag them with their special option number (i.e. O-123456-A) & let BOM filter through it with those tags.
  • put a phantom component into the assembly (a placeholder)
    this would mean that there are special components in the assembly that BOM replaces depending on the option
    it would remove at least the component exponential side of things because there would only be configurations/new components for FEATURES but not for parts/assemblies - BOM would replace those depending on the option
    It seems a good concept because i.e. wood-colours are currently done like that for us (that does not mean that there are better/other ways!)

I already like the input from all of you @the_h4mmer , @bnemec, @XHawkeye

[bnemec]

This is exactly what we would face. With the little difference that it would be exponential madness for us (too many changes across multiple assemblies going further up the tree) & it feels wrong to have this problem solved in SOILEDWorks.

So here are some ideas that we threw around recently (including this idea):

• no configurations in components!
  Have every difference (i.e. Generator y/n, Solar 20/40/80) as its own assembly & live with the exponential amount of assemblies. Maintain this structure i.e. in a table
• configurations in components!
  try to get hold of multiple configurations through design tables & linking it i.e. to external sources
• solve the problem at a different stage
  • put EVERYTHING always into the components! (could look messy...)
    kind of like having no configurations in components with the exception to list all the parts ALWAYS on the BOM. Tag them with their special option number (i.e. O-123456-A) & let BOM filter through it with those tags.
  • put a phantom component into the assembly (a placeholder)
    this would mean that there are special components in the assembly that BOM replaces depending on the option
    it would remove at least the component exponential side of things because there would only be configurations/new components for FEATURES but not for parts/assemblies - BOM would replace those depending on the option
    It seems a good concept because i.e. wood-colours are currently done like that for us (that does not mean that there are better/other ways!)

I already like the input from all of you @the_h4mmer , @bnemec, @XHawkeye

You've gone over my head with the 3rd option. Honesly, someone would probably need to work in your company for a length of time, month, year? to be able to understand enough of your business model needs.

Your option 1 is what we have and you are hitting on why we have version issues. There's no way to update ALL the where used when a part is revised so everything is referenced at various versions, caching the correct version of the components is very very difficult and confusing.

Example maybe, let's say you buy the generator as a purchased assembly. It's an Onan and they have a proposed model update that you're evaluating. Some engineer is confirming fit form and function. If we can assume it's just a mondain part in comparison of the entire RV so there's no need to assign new part number, it's just a new revision of the genny. The user that's validating fit form and function of the future genny will need the latest version of it in local cache.
The next user needs to have the current genny that we have in inventory in local cache because that's what is in use and if they get the new version their model will blow up or they just show the wrong thing, because they are releasing that camper soon to be built before the genny model change will happen.
Another user is working on next year's RV model and they have talked with the first engineer and they feel confident enough that the new genny will be implemented so this third designer is using the latest version of the genny so they have access to the dipstick and correct cable lengths, or whatever.
So we're doing ok so far. Now the second designer is ready to release the design for this custom unit that will be built with the current genny model. They sent it to review state and one of the other engineers open it up. Guess what!! broken stuff. Why? Because they have the wrong version of the genny. They need to manually get referenced version of the entire RV before reviewing. Now that they're done with that review they go back to what they were working on and it's all messed up. Oh yeah, wrong versions of common components again, ok, get latest. But things are still wrong. Well, it's probably because they got a referenced version of a file they have checked out and had saved changes to in local cache but when they got that referenced version to review some other camper it overwrote their local version that had never been checked in. So now you get to explain to someone how they lost work even though they had saved changes (because PDM overwrote cache), also a good time to go reset all the SW warnings they have suppressed.

[berg_lauritz]

You've gone over my head with the 3rd option. Honesly, someone would probably need to work in your company for a length of time, month, year? to be able to understand enough of your business model needs.

Your option 1 is what we have and you are hitting on why we have version issues. There's no way to update ALL the where used when a part is revised so everything is referenced at various versions, caching the correct version of the components is very very difficult and confusing.

Example maybe, let's say you buy the generator as a purchased assembly. It's an Onan and they have a proposed model update that you're evaluating. Some engineer is confirming fit form and function. If we can assume it's just a mondain part in comparison of the entire RV so there's no need to assign new part number, it's just a new revision of the genny. The user that's validating fit form and function of the future genny will need the latest version of it in local cache.
The next user needs to have the current genny that we have in inventory in local cache because that's what is in use and if they get the new version their model will blow up or they just show the wrong thing, because they are releasing that camper soon to be built before the genny model change will happen.
Another user is working on next year's RV model and they have talked with the first engineer and they feel confident enough that the new genny will be implemented so this third designer is using the latest version of the genny so they have access to the dipstick and correct cable lengths, or whatever.
So we're doing ok so far. Now the second designer is ready to release the design for this custom unit that will be built with the current genny model. They sent it to review state and one of the other engineers open it up. Guess what!! broken stuff. Why? Because they have the wrong version of the genny. They need to manually get referenced version of the entire RV before reviewing. Now that they're done with that review they go back to what they were working on and it's all messed up. Oh yeah, wrong versions of common components again, ok, get latest. But things are still wrong. Well, it's probably because they got a referenced version of a file they have checked out and had saved changes to in local cache but when they got that referenced version to review some other camper it overwrote their local version that had never been checked in. So now you get to explain to someone how they lost work even though they had saved changes (because PDM overwrote cache), also a good time to go reset all the SW warnings they have suppressed.

Oh my... We have not thought option 1 through in that direction. Would it be possible in your case to make a pack & go for those files at least? Or have different states to tackle this problem?

Some ideas to tackle some of your problems are the following:

• Design does not fully release anything. Everything gets shoved into a pre-release state until BOM actually releases it. Learning how to correctly branch/merge seems to be one of the key hurdles
• Export ready files to a different file location & ALSO a different format. If nothing changes you can just use the different format - if something changes you can at least swap the missing new parts with the new version & double check for mistakes.
• Automate the rebuild process. Nobody wants to check out, rebuild, save everything... It just takes too much time... But how to automate it?
• Force everybody to check in regularly & use comments properly

I'll try to elaborate on option 3:

A. Currently we put the jigs we use into the assembly. They are tagged as 'Jig'. They won't get purchased/manufactured every time we build a unit. Think of it like a molding - you want to have it on the drawing because you need the reference to produce the part - but you don't always need a new molding. BOM does all the work there. People can still look up the number & the jig connected to it. It can still be issued through BOM without our interference etc.It's also easily visible on the drawings & when you copy/branch you know that you have to make a new jig for it.

We could do the same for the parts: Generator A & Generator B are in the assembly & they have a tag (custom property) attached to it that shows which option they are for (i.e. "Gen A" or "Gen B"). All parts connected to this option would have the same tag.
BOM still would know where they belong etc. but would only issue them as needed.
A downfall of this is, that it will get VERY messy & it performance could take a big hit.

B. We would have a 'phantom' component in the assembly. BOM would ALWAYS replace this special part with a standard/option.
This way you could basically have a BOM that has ALL parts that are ALWAYS used on this RV. You would only add the ones that vary.
i.e. Generator + all the fittings etc. would be a phantom component
Generator A + all the fittings would be OPTION A
Generator B + all the fittings would be OPTION B
No Generator would be OPTION C
If you want to build the unit you HAVE TO choose an option. It's a placeholder that is not really a part.

Does that make sense?

[bnemec]

I think I follow that. I'm not qualified to give insight as to which might be better.

[the_h4mmer]

Oh my... We have not thought option 1 through in that direction. Would it be possible in your case to make a pack & go for those files at least? Or have different states to tackle this problem?

Some ideas to tackle some of your problems are the following:

• Design does not fully release anything. Everything gets shoved into a pre-release state until BOM actually releases it. Learning how to correctly branch/merge seems to be one of the key hurdles
• Export ready files to a different file location & ALSO a different format. If nothing changes you can just use the different format - if something changes you can at least swap the missing new parts with the new version & double check for mistakes.
• Automate the rebuild process. Nobody wants to check out, rebuild, save everything... It just takes too much time... But how to automate it?
• Force everybody to check in regularly & use comments properly

Does that make sense?

So here's my take on these points (I'm assuming PDM and Released designs are in use):

1. Using assemblies is going to get document management heavy, BUT it's probably the simplest means to accomplish what's being asked, the most difficult aspect being discipline.

2. The discipline part comes in where you must release components for the assembly from the bottom up, and they'll need to be fully updated (rebuilt) when you do. This way, every subassembly and assembly reference the correct versions when released. I know this sounds terrible, but it's the right way to go (from my standpoint) to ensure nothing is out of date.

3. Branch and Merging is great and I highly recommend it! Example would be that if you need to make an update to a design, but need that design to remain in use, you can branch what needs to change to do the work, then when the branch has passed the initial review, move the Source design into a working state and merge the Branch back to the Source file, then review to release.

4. There is an automatic rebuild process but it comes with a BIG liability waiver. I understand the urge to automate this, but if you follow #2, you shouldn't have to do this. If a component is changing, you have to update it, review and release, then update all the assemblies where that component is used. Sounds a bit tedious, but it's proper due diligence (again, that's my take)

5. Regular check-ins and commenting should absolutely be standard practice. It makes worlds of difference when you're looking back at someone else's work 2 years after they left if they wrote out what they did, why they did it, and/or how they did it, instead of leaving 'made changes' as the comment. Information/documentation is the key to moving quicker while maintaining knowledge or without having to backtrack, regardless of anything else, this should be standard practice.

I think the other options are viable, but they come with other drawbacks like you cited, but also with more room for human error or subjectivity. If we're looking to ensure that designs are properly updated/released, it's going to be a bit of a slog, but the first option would probably be the simplest to follow AND to catch errors/deviations (since files will be marked as needing Rebuilding). I've started this process at my organization, along with updating the drawing format/standard so I have to open every design anyhow, and it's been amazing how many problems it's fixed with out-of-date references!

[berg_lauritz]

1. Using assemblies is going to get document management heavy, BUT it's probably the simplest means to accomplish what's being asked, the most difficult aspect being discipline.

Heavy is an understatement especially in times like this where we regularly have to swap out parts & change cut out sizes.
I.e.
for the roof we have 3 options - i.e. two are y/n one is Solar panels 100w/200w/800w - that would make 12 different assemblies for the roof for each option. Who knows how many other assemblies would be affected (i.e. wire harnesses etc.). I'm also excluding that you'd have to maintain possibly different possibly shared sub assemblies in those roofs.
If you have 10 different Units (& we assume the best case - nothing else changes!) that would be up to 120 different roofs. Only for the roof alone! We still need to build the rest of the unit!
If we decide to switch out i.e. the manufacturer for the solar panels & we need a different sized cutout - we have to take care of up to 120 different assemblies instead of 10. It just adds up too quickly!

Also what do you do with the main assembly then? Do you have different assemblies for ALL versions then?

To me this seems to be a very common problem in the industry & I thought that a solution to this would exist already but you seem to struggle with the same... Oof!

[bnemec]

So here's my take on these points (I'm assuming PDM and Released designs are in use):

1. Using assemblies is going to get document management heavy, BUT it's probably the simplest means to accomplish what's being asked, the most difficult aspect being discipline.

2. The discipline part comes in where you must release components for the assembly from the bottom up, and they'll need to be fully updated (rebuilt) when you do. This way, every subassembly and assembly reference the correct versions when released. I know this sounds terrible, but it's the right way to go (from my standpoint) to ensure nothing is out of date.

3. Branch and Merging is great and I highly recommend it! Example would be that if you need to make an update to a design, but need that design to remain in use, you can branch what needs to change to do the work, then when the branch has passed the initial review, move the Source design into a working state and merge the Branch back to the Source file, then review to release.

4. There is an automatic rebuild process but it comes with a BIG liability waiver. I understand the urge to automate this, but if you follow #2, you shouldn't have to do this. If a component is changing, you have to update it, review and release, then update all the assemblies where that component is used. Sounds a bit tedious, but it's proper due diligence (again, that's my take)

5. Regular check-ins and commenting should absolutely be standard practice. It makes worlds of difference when you're looking back at someone else's work 2 years after they left if they wrote out what they did, why they did it, and/or how they did it, instead of leaving 'made changes' as the comment. Information/documentation is the key to moving quicker while maintaining knowledge or without having to backtrack, regardless of anything else, this should be standard practice.

I think the other options are viable, but they come with other drawbacks like you cited, but also with more room for human error or subjectivity. If we're looking to ensure that designs are properly updated/released, it's going to be a bit of a slog, but the first option would probably be the simplest to follow AND to catch errors/deviations (since files will be marked as needing Rebuilding). I've started this process at my organization, along with updating the drawing format/standard so I have to open every design anyhow, and it's been amazing how many problems it's fixed with out-of-date references!

If point #2 can actually be done, that makes PDM and versions much simpler to deal with. Since we very seldom release an entire tree, top down or bottom up we simply cannot do point #2. Actually, we don't have reference trees, they are more like a tree-mesh-star hybrid.
When I was doing some PDM API exploration in file searching I set up a test crawler bot that kept a list of files it found from the file references, first by children then by parents; given a random start file it found over 99% of the not deleted files in the vault.

image.png (82.65 KiB) Viewed 3316 times

[the_h4mmer]

Heavy is an understatement especially in times like this where we regularly have to swap out parts & change cut out sizes.

I was suggesting that the cutouts be made in the various assemblies where they're needed, not in the roof "part" itself. That way the roof can be released as is, and each assembly variant is where the roof variant design lives; the assembly drawing would have to show the cutouts needed. That way you only have one part number for the roof, but can make modifications based on the options selected for the final assembly. Of course that's assuming this method is feasible with other aspects of the business.

Heavy is an understatement especially in times like this where we regularly have to swap out parts & change cut out sizes.
I.e.
for the roof we have 3 options - i.e. two are y/n one is Solar panels 100w/200w/800w - that would make 12 different assemblies for the roof for each option. Who knows how many other assemblies would be affected (i.e. wire harnesses etc.). I'm also excluding that you'd have to maintain possibly different possibly shared sub assemblies in those roofs.
If you have 10 different Units (& we assume the best case - nothing else changes!) that would be up to 120 different roofs. Only for the roof alone! We still need to build the rest of the unit!
If we decide to switch out i.e. the manufacturer for the solar panels & we need a different sized cutout - we have to take care of up to 120 different assemblies instead of 10. It just adds up too quickly!

Also what do you do with the main assembly then? Do you have different assemblies for ALL versions then?

To me this seems to be a very common problem in the industry & I thought that a solution to this would exist already but you seem to struggle with the same... Oof!

The way it would work is that parts and subassemblies are reviewed/released that make up you various assemblies, before making the assemblies. Once all the parts and subassemblies are released, you're free to make assemblies as you please, since the parts should all be in a fixed state design-wise. If/when a part requires a design change (universal change, otherwise it should probably be a new part number), that's where the heavy document management comes in, because you'll have to update the part, then every assembly it goes into.

Hopefully that makes sense, but if not I can try to build a flowchart to better illustrate it. Shared parts between assemblies is not a hassle until you have to revise the part, then the roof assembly and everyone above it will need to be updated. If there are lots of levels above, maybe that could mean there is some work that could be done in the structure of the assemblies? I know for our organization, there were way too many subassemblies, which were driven by the ERP system, but by eliminating the CAD files for these and just letting the subassemblies be virtual for the ERP system, I cut down the number of documents that required updating when changes were needed. An example of this was when they wanted to change a pair of screws on all our major products (x12 assemblies), which should have been 24 documents to update (assembly and drawing), but because of the interim subassemblies, it ended up being 106 documents that needed updating! When I communicated this and how long it would take to update (bottom up), the change order was cancelled.

Again, I know this all sounds terrible, but (to me) there's cost of doing things right, usually that's time. Your organization can choose to tradeoff having things done right to gain short term speed, but there will be downstream costs that will be more time and/or money that will likely cause more issues. I've experienced this first hand as a predecessor made an out-of-band change to a part, without updating any assemblies, and nearly cost the company $50k in product loss; we were lucky by the skin of our teeth that we could modify the design to make it work, but only because there was enough material present. Of course, that's the basis of my argument to our leadership and because we had a disruption to our production, I was able to start fixing this, but if you're trying to do something like this while keeping everything moving, it will be VERY difficult or nearly impossible.

A bit of a tangent, but engineering design, quality, and safety are not things to be rushed. I know businesses and nontechnical individuals will push for faster, but I'm a strong proponent of pushing back against this idea; and if I can't win that I make those who force me accountable for their demands. Moving too fast or cutting corners have historically led to mistakes that have built the guidelines that are considered best-practice, and some of them are literally written in blood. The work I do has a safety element to it, but not as much as something like a roof/house, and if I were in your position I would push back very hard to make sure that the due diligence was put into proper maintenance for all these designs. It's a mitigation risk for the organization and personally it's a moral/ethical issue as I don't want to be responsible or contribute to someone getting injured or dying. It may seem like a stretch, but as designers and engineers we're generally so close to things that it can be difficult to see, but I find that these risks are usually much closer than you may think.

<climbs off high-horse>

[the_h4mmer]

If point #2 can actually be done, that makes PDM and versions much simpler to deal with. Since we very seldom release an entire tree, top down or bottom up we simply cannot do point #2. Actually, we don't have reference trees, they are more like a tree-mesh-star hybrid.

When you say you seldom release an entire tree, does that mean that there are parts/assemblies that are not in a release state being built? That seems counter-intuitive to me, as it would defeat the purpose of having a released state. I'm guessing that there's something I'm misunderstanding with the statement, but if the top-level assembly is released, I would say that a condition for that would be that all child components must be released as well.

To your point of structure complexity, yes it does and will get complicated, however if everything follows the guidelines of bottom-up release, then a part being updated would be changed along with every assembly it goes into. The part would need to be released before the assemblies, but if you have one part going into 50 assemblies, there are 51 designs to update. Even if some other method was used, it wouldn't change the number of designs that should be updated (more of a matter of what will get updated or not).

[bnemec]

When you say you seldom release an entire tree, does that mean that there are parts/assemblies that are not in a release state being built? That seems counter-intuitive to me, as it would defeat the purpose of having a released state. I'm guessing that there's something I'm misunderstanding with the statement, but if the top-level assembly is released, I would say that a condition for that would be that all child components must be released as well.

To your point of structure complexity, yes it does and will get complicated, however if everything follows the guidelines of bottom-up release, then a part being updated would be changed along with every assembly it goes into. The part would need to be released before the assemblies, but if you have one part going into 50 assemblies, there are 51 designs to update. Even if some other method was used, it wouldn't change the number of designs that should be updated (more of a matter of what will get updated or not).

The portions that I highlighted are assumptions made by many, but it's a bad assumption in our use case. Those assumptions may be "best practice" but it's just not something we can do. I'm learning more and more that PDM Pro really wasn't intended to be used in this way, I don't know that any PDM solution is.

If a part is revised, most of the time only one layer above is revised. Sometimes only the part is revised, the parents are all left at the current revision. Sometimes the entire where used tree is revised, usually when the change is customer request. Before PDM we were able to use Solid Edge Design Manager to update the where-used to pull the new rev, but now with workflow and versions we still have not found a way to accomplish this. We're still trying to work out how to do a mass where used update to the next released version. One big problem is it cascades if each layer of where used is checked in with a new version, so either the entire where used tree needs updated to new versions or do a version overwrite on check in so the next layer of where used don't need updated to new version.

As for releasing top level products, frequently parts in the tree will be in various workflow states for various ongoing concurrent ECs. The previous released revision is what the floor is making and inventoried and shipped, so the new versions are future versions. We don't stop production if a part will potentially be affected by active ECR. We don't do stop releasing new products if some part is under ECR either. Changes are implemented on the fly.

When you say you seldom release an entire tree, does that mean that there are parts/assemblies that are not in a release state being built? That seems counter-intuitive to me, as it would defeat the purpose of having a released state. I'm guessing that there's something I'm misunderstanding with the statement, but if the top-level assembly is released, I would say that a condition for that would be that all child components must be released as well.

There are other systems at play, not just CAD and PDM. PDM just manages files it is not aware of part object; systems like PLM, ERP and MES manage part data. Just because the file is in WIP doesn't mean the part is not in production being made at the current revision. Changes take time, inventory must be consumed or balanced out, tooling lead times can be a couple of months, changed to a purchased component can take months to get through logistics. Branch and Merge has merit and certainly some place of use but I've heard some mixed messages about Branching that indicate it's best used with discretion for the sake of database integrity.

[the_h4mmer]

@bnemec all valid and great points, that I want to tackle, but will probably take some time for me to construct thoughtfully.

In the meantime (but feel free to hold off on posting a reply until I reply to your last message), I'm curious if everything is in such a state of flux, then how are designs managed/released? Additionally, how much time is required to trace out which revision is used in a given assembly and/or discover that the wrong revision was used for an assembly? To my naive view, it seems like you're going to end up expending time/effort somewhere...

[bnemec]

@bnemec all valid and great points, that I want to tackle, but will probably take some time for me to construct thoughtfully.

In the meantime (but feel free to hold off on posting a reply until I reply to your last message), I'm curious if everything is in such a state of flux, then how are designs managed/released? Additionally, how much time is required to trace out which revision is used in a given assembly and/or discover that the wrong revision was used for an assembly? To my naive view, it seems like you're going to end up expending time/effort somewhere...

We are currently working with a 3rd party consultant firm concerning ERP (and several other three letter acronyms) system(s). Thankfully, I'm not directly involved but I hear bits of the mapping process and when the data management, project management and QMS components bump into CAD data. With modern computing systems, moreso user interface advancements, the line between CAD file management and those other functions is getting more fuzzy and thin. I'm curious to see where this plays out as the design department is just one spoke in the wheel and does operate within bounds set by the all of the departments as a whole.

[the_h4mmer]

The portions that I highlighted are assumptions made by many, but it's a bad assumption in our use case. Those assumptions may be "best practice" but it's just not something we can do. I'm learning more and more that PDM Pro really wasn't intended to be used in this way, I don't know that any PDM solution is.

Apologies, I may have misread something or missed something entirely, to which assumptions are you referring? Do you mean the assumption that it would be possible to take an approach to releasing designs from the bottom-up?

If a part is revised, most of the time only one layer above is revised. Sometimes only the part is revised, the parents are all left at the current revision.

If I'm following the logic here, a part gets updated and only the first assembly level it goes into would get updated? If that's the case, when there's a revision of the part, and the first level assembly it goes into, then wouldn't the remaining parent assemblies reference the previous revision of that assembly? If the change doesn't propagate up, then how is the kept straight?

We're still trying to work out how to do a mass where used update to the next released version. One big problem is it cascades if each layer of where used is checked in with a new version, so either the entire where used tree needs updated to new versions or do a version overwrite on check in so the next layer of where used don't need updated to new version.

Procedurally, this is would be solved by bottom-up releasing. The lowest level parts get released and their version is set, then the next layer up, and so on until reaching the top-level. The next parent assembly would have the correct version of the parts, and as long as you're not trying to release assembly and part/sub-assembly at the same time, the versions will all be good. Progamatically, this could be quite the task and I don't know enough of the Solidworks or PDM API to know if this is feasible to accomplish (safely),

As for releasing top level products, frequently parts in the tree will be in various workflow states for various ongoing concurrent ECs. The previous released revision is what the floor is making and inventoried and shipped, so the new versions are future versions. We don't stop production if a part will potentially be affected by active ECR. We don't do stop releasing new products if some part is under ECR either. Changes are implemented on the fly.

I understand that you can't stop production because of an ECR, and from my standpoint, the changeover process should be incorporated as part of the ECO process. Planning that out, will likely make the production transition and file management simpler. Certainly it won't work out every time, but the planning should help it run smoother even if the plan gets terribly upset. Also, the Branch and Merge function seems like a perfect opportunity to use here (I know it's mentioned in the next section).

There are other systems at play, not just CAD and PDM. PDM just manages files it is not aware of part object; systems like PLM, ERP and MES manage part data.

I certainly appreciate this and am working, at my organization, to understand how these all interconnect. This aspect feels like it would be highly subjective from company to company, so I won't go further than this.

Just because the file is in WIP doesn't mean the part is not in production being made at the current revision. Changes take time, inventory must be consumed or balanced out, tooling lead times can be a couple of months, changed to a purchased component can take months to get through logistics. Branch and Merge has merit and certainly some place of use but I've heard some mixed messages about Branching that indicate it's best used with discretion for the sake of database integrity.

Agreed, a lot must be taken into account and things take time. I am working on balancing out the Engineering side of things, because everything is expected to turn around in an extremely short amount of time, but we have so many broken designs and assemblies, that it takes a week to figure out what's even wrong with them! I have a believe (perhaps overly idealistic) that it's feasible to do things 'right' and have a sanitary vault, but pressure has to be put back up the chain that more time/consideration is needed (at least where I'm at). I'd venture that many other organizations could do the same, but choose the route of sacrificing quality for speed, and you know I think I'll just steer clear of those places personally.

All in all @bnemec, I've very much enjoyed the conversation here. I would be very interested to actually chat someday to engage in a true live conversation, as I feel I could learn a great deal and that it might be easier to convey certain concepts. Additionally, if it's possible to learn some of what results from the consultant, I'd be curious to hear the high-level recommendations/ideas; or at minimum the name of the consultant.

[bnemec]

I feel that I've stolen the thread here. I understand our use case is rather unique so many of the concerns and constraints that we operate within do not apply to others. However, if we all understand that this is NOT a best practice thread, rather a discussion over a hypothetical scenario then maybe we're ok.

Apologies, I may have misread something or missed something entirely, to which assumptions are you referring? Do you mean the assumption that it would be possible to take an approach to releasing designs from the bottom-up?

No need to apologize, I'm probably not communicating it very well. The two that I set to bold font when I quoted you in my 2022 Mar 17, 9:33 am reply. Snippets:
1) "...but if the top-level assembly is released, I would say that a condition for that would be that all child components must be released as well."
2) " ..then a part being updated would be changed along with every assembly it goes into."

Both of those are things we seldom do. I tried to expand on it but maybe not doing a good job of it. In short, we release new Seats while parts in the contains tree are not in Released state. That happens regularly. Second is we seldom revise the entire where used tree for a small change to a part or subassembly/weldment.

If I'm following the logic here, a part gets updated and only the first assembly level it goes into would get updated? If that's the case, when there's a revision of the part, and the first level assembly it goes into, then wouldn't the remaining parent assemblies reference the previous revision of that assembly? If the change doesn't propagate up, then how is the kept straight?

We're not a job shop. Parts are not ordered/manufactured from top-down print release. When a part comes off a punch press it goes in a bin and is stocked; depending on what the part is it could wind up in one of several catalog numbers or go to as many as a couple hundred top level catalog numbers that we ship. There are shop orders being created for parts, weldments, sub-assemblies all the time; based on forecast, inventory levels and demand from open orders of finished product with due dates based on customer order ship dates and the time it takes to get through the work centers.

Those parts are all made per BOMs, Routings, work instructions and the drawing attached in the ERP system. We could do whatever we Design Engineers want in CAD but it's 100% irrelevant until Manufacturing Engineering connects the drawings, updates the rev numbers, BOM and routings, as well as writing work orders for new/changed tooling. Cranking up revs in CAD is just one relatively small component of the entire revision process. So if I do a Revision Required transition on a file in PDM and make edits and submit to review and it even gets approved sending it to Released state with pdf and dxf being generated that still changes nothing on the floor. That approval of files in PDM just says MFG ENG can go ahead with their actions. So if the change is not visible on the print and doesn't require any change of BOMs, Routing, Tooling, fixturing etc of the of the next where used there's no point in making a revision.

Does that explain how parts are made and how a part can be revised and that change implemented without revising the entire where used tree?

Procedurally, this is would be solved by bottom-up releasing. The lowest level parts get released and their version is set, then the next layer up, and so on until reaching the top-level. The next parent assembly would have the correct version of the parts, and as long as you're not trying to release assembly and part/sub-assembly at the same time, the versions will all be good. Progamatically, this could be quite the task and I don't know enough of the Solidworks or PDM API to know if this is feasible to accomplish (safely),

What you're saying is true and the same practice that we've heard over and over, which is why I'm wondering if PDM can even function outside of that "best practice"
As for programmatically through API we would not do a revision, just check out, update the version of the revised file, check in. I've been working through workflows for that process for ~18 months now and I keep waffling over just checking in the first where used with version overwrite so I don't have to keep going up the tree. I keep running in to scenarios where there are collisions or double updates due to a part being used a different levels. Incase you're thinking cyclic ref, no; an example would be a metal part that goes to a weldment but also goes to paint then used in assembly that also includes the other weldment. Trying to travers the tree using recursion isn't to bad without those, but trying to identify those cases so the parents don't get updated several times for one change. Also the case of several parts being changed, they wind up going to a group of say 100 top level assemblies. If I recurse up each branch of the where used tree the assemblies that contain all of those revised parts would be updated once for each. So the API tool would need to parse the tree to establish layers of files to update, checking if each file is already in a layer; if it's in the current layer fine, it will be updated, if it's in a layer above or below the current then we start to run into a race. That's way too much about that.

I understand that you can't stop production because of an ECR, and from my standpoint, the changeover process should be incorporated as part of the ECO process. Planning that out, will likely make the production transition and file management simpler. Certainly it won't work out every time, but the planning should help it run smoother even if the plan gets terribly upset. Also, the Branch and Merge function seems like a perfect opportunity to use here (I know it's mentioned in the next section).

The ECR/O/N pretty much exists and is all in the ERP system. But it's antiquated system that was designed over two decades ago to replace paper. It did a great job at that but not much data object linking. But the ECO process you speak of is the mechanism that allows the changes. Pretty much what I said above about how MFG ENG has all their actions, to do. That is all documented in the ECR evaluation and action assignments. There is evaluation, approval, action and completion phases of the ECR. All the affected departments are involved to some extent on each change; from Sales, Purchasing, Inventory Control, Logistics, Tooling, MFG ENG, Shop Floor supervision, QMS are typically involved in evaluation, approval and actions.

I certainly appreciate this and am working, at my organization, to understand how these all interconnect. This aspect feels like it would be highly subjective from company to company, so I won't go further than this.

Sometimes sounding boards can be helpful to work through thoughts. In programming it's called "Rubber Ducky Debugging"
Yes, this is highly subjective from place to place. There are job shops where the project is designed and built and done, no part numbers assigned, and very little model reuse. They might have duplicate file names in all the project folders. We don't have much problem with duplicate file names because the part is all set up in ERP so we use that part number and that file in our new development assembly. We only copy the files that we intend to make new part numbers for, the rest of the parts we use as they are.

Agreed, a lot must be taken into account and things take time. I am working on balancing out the Engineering side of things, because everything is expected to turn around in an extremely short amount of time, but we have so many broken designs and assemblies, that it takes a week to figure out what's even wrong with them! I have a believe (perhaps overly idealistic) that it's feasible to do things 'right' and have a sanitary vault, but pressure has to be put back up the chain that more time/consideration is needed (at least where I'm at). I'd venture that many other organizations could do the same, but choose the route of sacrificing quality for speed, and you know I think I'll just steer clear of those places personally.

All in all @bnemec, I've very much enjoyed the conversation here. I would be very interested to actually chat someday to engage in a true live conversation, as I feel I could learn a great deal and that it might be easier to convey certain concepts. Additionally, if it's possible to learn some of what results from the consultant, I'd be curious to hear the high-level recommendations/ideas; or at minimum the name of the consultant.

[berg_lauritz]

you didn't steal the thread. I am following it closely but we just got presented with an impossible schedule for the next 10-12 weeks.

[the_h4mmer]

@berg_lauritz I'm glad we haven't stolen the thread, because this conversation has been very helpful for me, and I hope it can aid others who may come across it as well! Sorry to hear about the impossible schedule, that's always brutal and I wish you the best of luck (with Murphy as far away as possible).

We're not a job shop. Parts are not ordered/manufactured from top-down print release. When a part comes off a punch press it goes in a bin and is stocked; depending on what the part is it could wind up in one of several catalog numbers or go to as many as a couple hundred top level catalog numbers that we ship. There are shop orders being created for parts, weldments, sub-assemblies all the time; based on forecast, inventory levels and demand from open orders of finished product with due dates based on customer order ship dates and the time it takes to get through the work centers.

So parts are manufactured, moved to stock/inventory, and the assemblies using those parts are later built to fulfill orders, or are the assemblies also built based on projections? Just trying to wrap my brain around the build process, but I'm going to assume for now it's the former.
This (to me) sounds like a perfect instance to use a bottom up release cycle. Since the parts are regularly produced, they should all be in the released state. No question, what I'm saying is ideal/optimistic, and naive to the other (I'm sure numerous) constraints that prevent this from occurring.

Those parts are all made per BOMs, Routings, work instructions and the drawing attached in the ERP system. We could do whatever we Design Engineers want in CAD but it's 100% irrelevant until Manufacturing Engineering connects the drawings, updates the rev numbers, BOM and routings, as well as writing work orders for new/changed tooling. Cranking up revs in CAD is just one relatively small component of the entire revision process. So if I do a Revision Required transition on a file in PDM and make edits and submit to review and it even gets approved sending it to Released state with pdf and dxf being generated that still changes nothing on the floor. That approval of files in PDM just says MFG ENG can go ahead with their actions. So if the change is not visible on the print and doesn't require any change of BOMs, Routing, Tooling, fixturing etc of the of the next where used there's no point in making a revision.

Does that explain how parts are made and how a part can be revised and that change implemented without revising the entire where used tree?

To answer your question, yes, kind of. I know it's my own lack of knowledge, but the ERP side of things is really where things start to break down for me. Presently I'm working to try to wrap my head around the one we use, how it's used, and if it can be used better (which if it can, how likely could I convince others to change). Looking at how the parts are manufactured first and then stocked, I could see why the entire where used tree might not get updated. If I imagine myself in that circumstance, then I would want to ensure the where used tree was updated before the assembly was built to ensure if there were notable changes, they would be properly updated.
When you don't have anything changing significantly on a drawing/design, then does it need to Revision? If you have to fix a spelling error or add a generic note, does it require a Rev? For me, it wouldn't, a Rev would be needed if a feature was updated (while remaining backwards compatible), which means something on the drawing would have to change. Maybe our threshold of what requires Revisioning is different.

What you're saying is true and the same practice that we've heard over and over, which is why I'm wondering if PDM can even function outside of that "best practice"

I suppose it can function, but I think it becomes an argument of subjectivity as to how much utility does it offer relative to how close the "best practice" is followed. Would be interesting if there could be a utility function derived to show that, but I'm certainly not smart enough to create something like that.

As for programmatically through API we would not do a revision, just check out, update the version of the revised file, check in. I've been working through workflows for that process for ~18 months now and I keep waffling over just checking in the first where used with version overwrite so I don't have to keep going up the tree. I keep running in to scenarios where there are collisions or double updates due to a part being used a different levels. Incase you're thinking cyclic ref, no; an example would be a metal part that goes to a weldment but also goes to paint then used in assembly that also includes the other weldment. Trying to travers the tree using recursion isn't to bad without those, but trying to identify those cases so the parents don't get updated several times for one change. Also the case of several parts being changed, they wind up going to a group of say 100 top level assemblies. If I recurse up each branch of the where used tree the assemblies that contain all of those revised parts would be updated once for each. So the API tool would need to parse the tree to establish layers of files to update, checking if each file is already in a layer; if it's in the current layer fine, it will be updated, if it's in a layer above or below the current then we start to run into a race. That's way too much about that.

I see what you mean with a part existing in multiple levels, there would have to be some fairly fancy programming to make that work properly. One means of a work around could be to set a timestamp for when the script began running then for any given part, compare the last save time of the part to the start time of the script; if the last save time was after the start of the script, then you could bypass an update. Not sure how reliable it would be, just a thought.
For me, a check-in with version overwrite would be only when the Revision isn't changing. This would be an instance where you had a drawing with a spelling error, missing a basic note, or the approval note moved (because Solidworks likes to do that sometimes). Design Revision would mean a full update and review cycle (for me).

The ECR/O/N pretty much exists and is all in the ERP system. But it's antiquated system that was designed over two decades ago to replace paper. It did a great job at that but not much data object linking. But the ECO process you speak of is the mechanism that allows the changes. Pretty much what I said above about how MFG ENG has all their actions, to do. That is all documented in the ECR evaluation and action assignments. There is evaluation, approval, action and completion phases of the ECR. All the affected departments are involved to some extent on each change; from Sales, Purchasing, Inventory Control, Logistics, Tooling, MFG ENG, Shop Floor supervision, QMS are typically involved in evaluation, approval and actions.

ERP based Engineering Changes sounds like a big oof. My organization is still too small to have separate design and manufacturing engineers, over even PDM Admins for that matter; I'm wearing all of those hats. I feel quite allergic to the ERP system, so I'm keeping as much as I can inside of PDM as I can, which includes the Engineering Change process. Duly noted tho, elsewhere that might not be feasible...

Sometimes sounding boards can be helpful to work through thoughts. In programming it's called "Rubber Ducky Debugging"
Yes, this is highly subjective from place to place. There are job shops where the project is designed and built and done, no part numbers assigned, and very little model reuse. They might have duplicate file names in all the project folders. We don't have much problem with duplicate file names because the part is all set up in ERP so we use that part number and that file in our new development assembly. We only copy the files that we intend to make new part numbers for, the rest of the parts we use as they are.

The Rubber Ducky method is handy, but it's even better (to me) when I can get someone else's perspective, especially when it comes to my blind-spots. This thread has been helpful there, as I'm seeing more of the world/industry via a perspective I don't have and may never get. And there's been a very interesting thought raised, how do you use PDM or tools like it, when the process can't match the "best practice" and how useful does it end up being if that's the case? My sense is that someone could make a lot of money coming up with a means to answer that question and/or solution to resolve the issue.

Also, working in a job shop sounds kinda nice...