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

[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…