Thank you for the reply! Really appreciated.
We are also using Inventor and the support for "UG GEOMETRY" = "no" BOMLine property is now in place to add non-CAD parts to the CAD-structure.
I am interested in hearing about the imprecise approach on the CAD models. Do you create a flat CAD structure? Do you know if you are using Inventor specific functionality like "Phantom" or "Reference" to create "Structurd View" for part lists?
If you are interested, I would like to share some experiences with you. I will send you a dm!
One thing to note is that Solidworks and Inventor (and to some degree Creo) create BOM tables on the drawing that are based on interpretations of the assembly that is being documented on that drawing. The BOM table is not the same information that will be mangaged in Teamcenter to represent the CAD data needed.
We use workarounds like No Geometry, Suppress, Hide and others to try and make the CADBOM that is save to the Teamcenter BVR to represent the BOM that will be good for downstream activities. Concepts like promote or special naming rules that can be used for a BOM on a drawing, do not work well when trying to reproduce in Teamcenter.
In general, CAD is used to design the shape of the product. There are many CAD tools and special applications (flat pattern, harness, tubing, weldments) and user defined programs, that can create good, coherent designs that do not have a BOM structure that is useful for downstream activities. You will need to make a business decision about how much you want to control how tha CAD systems is used to create a particular structure with how to use the PLM system to capture and adapt that structure.
- How do you manage an inseperable assembly? Teamcenter needs all of the "Parts" but Manufacturing/purchasing will see only one end item.
- How do you want to handle non-CAD data? With the structure manager, you can add non-CAD data to the assembly and it will remain evan after CAD changes.
- How should finish options be handled? One CAD model might have 100 colors. Is this a CAD property with a family table or an ERP end item tracked difference?
- Harness's are typically a part number for manufacturing assembly into a higher level product. But, the component list may be a text file stored with the harness.
- The CAD structure cannot be changed in Structure Manager to flatten or rearrage for manufacturing.
These are some of the reasons that CAD-Part alignment is used.
Amother aspect of this is to make sure that it is clear to the users where tasks are to be done. CAD for designing the best product possible. PLM for managing the transition from a CAD design to a manufacturable product with ties into MBOM for kitting, shop floor, purchasing, ERP, and factory planning.
So, remember that the BOM on the drawing is an evaluation of the assemlby and not necessarily representative of the data that needs to be saved and managed to create it.
When working with Design-Part separation the design and the part structure will differ, so the numbering of the BOM lines and the items on that line will, right? So how do you manage the ballooning and occasional parts list on the assembly drawing? This drawing will be used for assembly of the product but is part of the design structure and thereby referring to the design structure.
I experience the friction between engineering structures and the ones demanded by the down stream processes and see why design-part separation could be of help, but I don't understand how to split the structures while maintaining the (automated) link between documentation and BOM created in for downstream processes.
Ahhh, The joys of a Drawing based process.
What is illuminating for customers in these situations is to have a CAD user and an ERP/Configuration Managment person get together and review the structure. A CAD user creates the structure needed to design the product. They can then create a Table on the Drawing and link the Balloons to that table. This process has been going on for a lot of years. The limitation is the the Table is the result of a process that may or may not have much relationship to the files needed to manage that design. Also, Users may be able to edit data on the drawing and easily break or cause links to be ignored.
The Integrations for Creo, Solidworks, and Inventor does provide mapping between the Assemlby and the Find numbers in Teamcenter. However, that mapping and the related structure are dependent on a lot of other factors.
So, get a MCAD Assembly and look at the file structure and compare it to the EBOM/ERP BOM or whatever strucuture you think it should be and start to deal in real differences. There are a lot of other downstream BOM's (See Siemens MOM and MPP products) that come into play and are not able to be handled by the MCAD designer.
As long as Drawings are the end product of Engineering, data integrity is up for discussion. Model Based design is not just a buzz-word but a wholesale change in data integrity from start to finish. Drawings are one of the derived output used for communication, but the Model is the master.
OK, enough of my rambling for now...
We use Solid Edge and have synchronization of assembly structure enabled.
Drawings are linked to the assemblies, annotations like balloons and parts list properties are linked to the assembly occurrences.
And, yes, there is some collaboration on the structure. :smileyhappy:
Going model based would allow for some degree of flexibility but still has limits and introduces other challenges with suppliers etc. The model is also a design of the engineer that adds the annotations for assembly/production. As the structure of the Design could be different from the Product, the annotations are out of sync and the same issue arises. Or am I missing something?
(1) First, they are two works. One work is design work. The other one is downstream work. Design work use design BOM to manage the design structure and related information. Downstream work use downstream BOM (whatever BOM) to manage the downstream structure and related information.
(2) Second, best practice, they need two persons to do these two separated works. One person does the design work. One person does the downstream work.
(3) Third. Work around, If one person have to do these two works. Pay attention that they are two works, design work and downstream work. They are two different BOMs to manage different structures and related information. Do these two works at the same time and do them in one structure are prohibited.
(4) Appendix, my opinion, the process management is the value provided by the PLM/PDM system.
PLM and Model Based design is still in its infancy. Drawings have many years of process experience behind them.
The automotive indistry started down the Model Based path in the '90s and in many areas have achieved a major portion of the digital thread. As this learning and experiance expands out into other products and companies, more and more digitalization will occur. This is as much a cultural issue as a technical one. It's not easy to think through the entire product life-cycle and how the data can flow with all of the required disciplines. Siemens has the Advantedge process to help capture and provide guidance for this puzzle.
Like many others, I'm focused on my little world and can only provide some input to those responsible for architecting the overall big picture.
Most of the time Work 1 (design) and Work 2 (Downstream, ERP) exchange a list of data rather than an electronic generated data.
In the Teamcenter environment, this is the reason for MCAD data being Design Items, and Downstream/ERP data being Part items. You can start with the separated, compare as desired and over time mature your process to add CAD Part Alignment in MPP to create the electronic process. This mainly changes the Work 2 effort by electonically consuming the MCAD data instead of getting an excel sheet.
Many companies think this can be done with one structure. While there are exceptions, when companies really look at the CAD files that need to be managed and the Downstream BOM structures that are needed, they very rarely are as aligned as people hope.
Good point @Jason27!
We don't use design-part separation and i'm trying to understand the impact of such a approach. I see the flexibility this will bring, but also wonder how much extra overhead this will introduce and where (TC object) what (the "work" or deliverables) needs to be done. So do you (or @PeterH) have an example description/image of how objects like items and datasets are related in this multi structure product definition?
Heres an example I use. This Creo assemlby has things needed for the design, but not what is wanted in the ERP BOM.
Here you can see the CAD structure on Top and the ERP structure on the bottom after alignment. The Design Items and the Part Items have a Multi-Field Key definition of Item ID and Type so they can share the same Item ID's. This is of course optional. Having engineering numbers that are just sequential and then aligning with the ERP numbers can also be done and the reports will still indicate if anything was note consumed and other differences.
This MPP based approach is quite new and lots of folks are not aware of this new option. The basic alignment function is part of base Teamcenter.