Any lessons learned from implementing MBOMs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Any lessons learned from implementing MBOMs
We are investigating to introduce MBOMs to our Windchill configuration. Today, we only manage an EBOM driven from our cad structure.
For anybody who has introduced MBOMs to Windchill, what were your findings and things that we should prepare for?
- Labels:
-
Manufacturing_Transformation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I am not using MPMLink but have introduced view versions for almost 19 years now. I am still dealing with the legacy version scheme of A.- when creating a Mfg view from A Design (eBOM). There is a job I can run to convert but I will discuss what this introduces down below.
So, we originally used this since CAD was locking the EBOM from modification. By creating a view version, it broke this relationship to the CAD and allowed modification like add/remove components or changing Qty/UOM. Since then, things have gotten much more flexible and these issues have largely gone away. Today, the use case for introducing these is cases when the as-Designed departs from as-Manufactured however, 90% of the time, they are identical. What we publish to SAP is the mBOM which gets a bit more review and this is done via ESI.
An example of where they might differ would be use of screen part numbers on a BOM. The CAD model may call out fasteners or EEE components but our the MBOM might call out a different part number that indicates we've internally screened it. The engineers would prefer to use common industry numbers in their day to day but the mBOM will show different numbers to swap them out.
Another use case is clarity. When you have auto-associate and auto-create parts enabled, every junk CAD Assembly that users check in will create a Part structure and crap eBOM. The mBOM allows to separate this junk from the real BOMs but to be honest, we've been going back and trying to clean those up. For example, say a user gets a huge STEP import from a vendor that is an assembly but we would buy complete. This may add a mess to your structure and often, they dump it in before we get a chance to clean up. To clean up the eBOM, you have to clear its components and fix CAD associations. We've just ignored the eBOM as a rule and only trust mBOMs.
Now, when you create that view version, its a branch off that eBOM iteration. This will impact purging and other things. You cannot remove that iteration without first deleting that mBOM version. This will impact purging and deletion. A bit of a pain especially if you continue to work on the eBOM and iterate it. Once you create it, now you need to keep them in sync. MPMLink has some tools for this. @dgraham might have some tools to up date these branch links but I do not muck with that.
Current installations, follow a single letter version scheme for eBOM and mBOM version. So A Manufacturing would be derived from A Design. In my case, older systems would be A goes to A.- (dash is out first letter). Now, you can revise a mBOM. This sets up an interesting situation. Its possible to revise A Manufacturing to B Manufacturing? What then happens if you create a new view version from B Design later? I think I tested this and it would create C Manufacturing (what what whaaaaaatttt!). My recommendation would be to wrap a business rule around that to avoid confusion.
That's a quick summary. Let me know if you have more questions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Did you have to recreate your searches to include the view criteria? We’re only known Design so when we introduce the other views I’m sure that will create a lot of confusion for our engineers.
Thanks for the quick reply!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
In some cases, yes. Very easy to add a filter on that. I would recommend making them experts in how this model works so they understand the complexity. Looks like you have an older instance like mine. In that version model, you will have to define that that means if the MBOM went to an A.B.1 or if you even want to support that. On my list is a customization to block revising of MBOMs since it has no purpose in our business. We always go back and start with Design view and move forward again. Don't forget about Query Builder reports since they can now report different versions or duplicate lines. Lastly, you need to look at your product structure filters. View is another criteria when pulling multilevel BOMS. If you filter for Manufacturing Views, It will try to find the latest rev of that view. If it does not find that, it will drop down the the Design View. Most of your COTS and library items will likely not have MFG views.