≡ Menu

Why You Should (or Shouldn’t) use Multiple BOMs

Share the knowledge

Recently I was asked for my thoughts regarding using a one BOM or a two BOMs to represent parts and designs. In one approach you store a single BOM which contains all of your CAD and business data in a single BOM structure. In the other you use one BOM strictly for the CAD designs and another for the business data and associate the two. So, which approach is better? What are the pros and cons of each? What considerations should you think about?

I’m very much still figuring this stuff out myself; I have my opinions, but honestly I don’t the experience yet to back up my opinions. I’ll share what I currently think; hopefully it’ll spur your own thinking on the matter, if nothing else.

Why You Should Use Multiple BOMs

Multi-BOM is the future. The future, I say!

From what I’ve seen at the conferences, conversations I’ve had with Siemens PLM employees, discussions with colleagues, and from reading the documentation, Siemens is invested in having separate part and design structures. I think we’ll be seeing more and more features added to each new Teamcenter version to support the multi-BOM approach for the foreseeable future.

Revision Independence

Having separate part and design BOMs means that you can revise parts and BOMs independently. Some changes only require changes to the CAD model — e.g. updating attributes updated, hiding construction geometry, updating the model to design standards. And on the other hand, sometimes their may be updates that don’t require the CAD to update — adding new suppliers, changing

Let the designers design

Sometimes it makes sense for the CAD user to organize the design differently than how ERP organizes the data. For example, it might make sense to group a large assembly model into sub-assemblies that don’t represent any actual part, but make it easier to divide up work on the overall structure.


Different BOM Structures

A related reason is that having the part BOM separate from the CAD BOM isolates the part BOM from the inevitable messiness of the CAD files. I have yet to see the system that didn’t have some of the following issues:

  • Improperly named data (particularly when dealing with imported, legacy, data)
  • Duplicate data, usually in the standard parts library and particularly after merging sites.
  • Dummy data — design ideas that never went anywhere, test data, and the occasional design of someone’s back deck.

Having multiple BOMs isolates the ERP system from this data, cleanly. If the design is never associated with an actual part, the ERP system will never see it.

There are automations to support multiple-BOMs

In v10 you can create the associated parts automatically when you create a design, or vice-versa, create the design automatically when you create a part.

Why You shouldn’t use Multiple BOMs

You aren’t storing Part data in Teamcenter

If you have another system, such as Teamcenter Enterprise or an in-house system, where you store part data and it will continue to be the system of record for the foreseeable future, there’s no reason to store the part data in Teamcenter too. In this case you really do have two BOMs, but one of them is stored in an entirely different system.

Single-BOM is still a valid option

Even though Siemens is seems to be pushing the multi-BOM approach, they still support using a single BOM. In fact, there are enhancements in TC 10 specifically added to support using a single BOM. For example, the structure manager in 10 adds the ability to use closure rules to filter a structure. This lets you filter the BOM view to only see parts with CAD data attached, for example.

A single BOM is Simpler

It’s hard to say that one BOM isn’t in many ways simpler than having two. I will say though that you have to think about all the stuff you have to manage in that single structure that isn’t CAD data.

Aligning BOMs is work!

If you have two related BOMs someone is going to have to align the two BOMs. Who’s going to do that? Are they willing to do it? Can you convince then that there is a benefit to doing it? When the schedule is on the line will BOM alignment be the scapegoat? This might actually be the most important issue to address. The technical challenges are just work. The social-political challenges are a whole ‘nother ball of wax.

The automations are limited

Although it’s nice to create and associate designs and parts automatically, the real day-to-day challenge is in creating and aligning the BOMs. If I have a CAD BOM, how do I get the correct corresponding Part BOM? As of yet there aren’t any automations to help us in that regard. To be honest, I don’t expect that any will be forthcoming. Being able to know how to automatically align two BOMs depends heavily on the specific decisions you’ve made regarding your business practices. What is your part-to-design cardinality? Does the part structure drive the design structure or vice versa? Do you use collector assemblies or other dummy items in your structure and how are they differentiated from the real models? I touch on many of these topics below. Once you’ve answered these questions for yourself I think you can often create some customizations to align your BOMs for you automatically. But I don’t think there’s a one-size-fits all solution that everyone could use.

Decisions, decisions, decisions.

I want to close out by touching on some topics I think you need to consider when managing Part and Design BOMs.

What is your Part to Design cardinality?

Teamcenter allows you have a single part represented by 0, 1 or multiple designs. Conversely, each design can represent, 0, 1 or many parts. The 1 Part to 0 Designs and the 0 Parts to 1 design cases simple. An example of the former case is a part like paint or glue that doesn’t need to have a CAD model. The latter case could be a CAD model that is just an experimental design idea that was never turned into a part.

A part may have multiple designs because it legitimately has multiple valid physical representations. A flexible electrical cable is a common example. For the drawing it may be modeled as straight cable of a particular length. When used in a particular assembly though it will be routed as necessary to make its connections and avoid all obstacles. Every assembly it is used in may require a different model specific to that assembly. You may also have multiple designs for the same part after merging sites that each had their own model for a particular part — this is common when dealing with standard library parts. Everyone has their own models of all the same common libraries.

How are non-aligned designs differentiated?

Let’s say you have a CAD BOM with some components which shouldn’t be aligned with anything in the Part BOM. How do you know they shouldn’t be aligned? If the parts don’t actually have any associated parts then that’s easy. But what if you have a component that really does represent a part, but just not a part in the other BOM? Here’s an example. I modeled an assembly that mounts to the side of a vehicle. To make sure I have the mounting correct I brought in the pieces from the vehicle that my assembly will be mounting to as reference geometry. I don’t want those reference components showing up my Part BOM however. I can think of the following ways to make sure that doesn’t happen.

  • The user just knows

    It’s not fancy, but one one way is just to put the responsibility on the user to make sure the reference geometry isn’t represented in the Part BOM.

  • Mark the component as Reference in NX

    A NX-only solution is to mark the component as reference-only in the assembly tree inside of the assembly model itself. Using this option will cause the NX integration to not represent the design in Teamcenter’s BOM for the assembly. But again, this is an NX only option so if you support other CAD systems this won’t work for you.

  • Set the quantity to zero

    You could set the quantity to zero in the CAD BOM for the reference geometry. Anyone, or anything, seeking to create and align a Part BOM from the CAD BOM would use a quantity of zero as a signal to not align that component.

  • Reference Only occurrence notes

    The last idea I have is that you could create a special note type that would indicate that a particular occurrence in a BOM was for reference only.

The first solution pretty much requires you to be doing manual CAD and Part BOM alignment. The others could be used to support automatic BOM generation and alignment.

Will you revise BOMs independently or not?

I gave Part and Design revision independence as a reason to consider having multiple BOMs. That doesn’t necessarily mean that you will revise the BOMs independently. Personally I’ve encountered many people who think that everything should be revised in sync. Personally I don’t agree with that, but you might encounter that resistance as well.

How are multiple designs updated?

Let’s go back to the multiple-designs-for-one-part example of flexible cable I have earlier. Let’s say that the primary CAD model needs to be updated. How do you make sure that all of the other CAD models are updated as well? What if the length of the cable was increased by a half-inch? How would you make sure your routings are all updated properly? Whatever workflows your using for you designs need to be able to handle their being more than one design for the same part.

What do you think?

Hopefully I’ve given you some food for thought. It’s not a easy decision to make with a clear cut answer. I personally know very capable and intelligent people who are currently implementing both types of solutions. Each have their own reasons. I’d love to hear from you. Have you implemented a Teamcenter solution that manages both parts and designs? Did you go single BOM or Multiple BOMs? Were there any other issues you had to consider? How did you address the issues? Leave a comment below to let me know; I appreciate it.

  • Jeremie FEBURIE

    Hi, again a very nice post ! (thank you)
    CAD Part Alignment was a feature introduced in TC2007.1 (AKA In Teamcenter Unified)

    For previous customers : There are two cases :
    - use all Parts and Design in the same BOM
    - use Part and Design in separate BOM (but those items are not derived from COTS “Part” and “Design” objects introduced in TC2007) so they don’t benefit from automations.

    According to me the most important automation are :
    1) Bidirectionnal relationship (“Represented By” Relation + “Representation for” runtime)
    This allows to always be able to navigate from the Part to Design and vice versa.
    2) Accountability Checks to reflect changes from one structure to another

    At the end, I completely agree with you : Managing 2 BOM is a (hard) work.
    But, in your company, if CAD data has a different lifecycle from the Part, managing 2 BOM is the best choice …

    • http://plmdojo.com/ Scott Pigman

      And thank you for the comments, Jeremie! I always appreciate them.

      Thanks for mentioning accountability checks. That is an important topic. I can see that things could get very out of hand very quickly without some strict controls and/or automations. Are there any tools currently in TC that support this? I don’t know what exactly, but I’m imagining that perhaps you could put a check in a workflow to not allow the process to proceed if there are unaccounted for nodes in either structure. Is there anything like that?

      • Jeremie FEBURIE

        Unfortunattely, I don’t think so …

      • Teamcenter Heretic

        The concept of a “tracelink” is used in the Requirements Module but this could be useful anywhere. Basically the tracelink is used to connect the requirement with the object which fulfills it.

        • http://plmdojo.com/ Scott Pigman

          Is it currently usable anywhere as-is, or is it somehow hard-coded to only work with Requirements right now?

          • Teamcenter Heretic

            tracelinks can be added for anything.
            You can subclass these for specialization also.

    • J-Fabien

      Hi,

      I think Siemens approach fits with large companies : multiple design offices spread around the globe, multiple factories…
      I think the approach is to clearly separate the representation of an assembly that only concerns CAD people from the product definition where many stakeholders can have a interest : product engineer, sales & marketing people who need a more concise view of the product.
      I’m currently working on the whole downstream BOMs:

      CAD BoM –> 150% BOM –> EBOM –> MBOM –> BOP (bill of process) etc…

      Because a product can have more and more possibilities to be configured (ref options & variants in TC, my 150% BOM), the CAD BOM is definitively multiple in order to represent a Part BOM.

      The cardinality we have the most is n Design for 1 Part.

      Because there’s not only Mechanical but also Electrical design offices, the trickest part is to merge these practises into one BOM.

      The only way I’d see only single BOM is when a product is not “variable” and the company organization is simple : designers and product engineers in the same room ;-)

      BTW, not sure the accountability check works betwen CAD BOM and EBOM.
      Between EBOM & MBOM yes and also between MBOM & BOP.

      • http://plmdojo.com/ Scott Pigman

        Thank you for the information and comments. One question, I’m not familiar with the term “15% BOM” – could you explain what that is?

        • http://www.eng-eng.com/ Ed Lopategui

          Scott, 150% BOM is a term frequently used with respect to variants to refer to the unconfigured structure (i.e. all the variants superimposed). That’s a whole other barrel of monkeys in this discussion. It’s more than one BOM technically, hence > 100%.

          • http://plmdojo.com/ Scott Pigman

            ah, thanks. Variants are not something we use where I work, hence my ignorance.

  • Menk Slot

    Scott, You don’t think it will be more complex. I know from other PLM Systems that they use CAD-Structure and BOM. In a lot of cases the structure is the same, even the metadata is the same. Then the end users want to change the metadata (In the CAD Structure but also in the BOM) and the system should keep it in sync. Another discussion is what about the EBOM and the MBOM.So do you have in that case 3 Structures?

    An advantage can be that it will be more simple to handle Mechanical Structures and Electronic Structures. The CAD Models will be separated and the part bom can bring them together

    • http://www.virtualdutchman.com/ Jos Voskuil

      Scott, Menk, I am not a Teamcenter expert, but from my experiences in the field on the functional level is that we probably talk about 2 BOM structures in most cases (depending on the industry). BOM structures are my hobby.
      In the case where the CAD structure and the EBOM structure are identical, it feels like a kind of overload. But often these companies have also other parts that are not necessary come from the CAD structure but from another MCAD system or ECAD system. The EBOM in general should contain more than a CAD structure (and potentially in the future – so do not treat them as a single structure unless you are sure)
      Next do you need an MBOM ? Sometimes yes, in particular when you large or modular products, where the design is not directly connected to manufacturing anymore. In typical engineering to order projects the design is often already done in the context of manufacturing and therefore the EBOM might already have an MBOM flavor.
      However when design and manufacturing are disconnected in time as a sequential process (modularity / long lifecycle) it becomes wise to manage the EBOM and the MBOM separate as structures.
      Personally I believe the EBOM and MBOM could be handled in the best manner in the PLM system, to allow a better transformation, comparison and potential automation inside a single system.
      As most companies manage (historically) their MBOM in their ERP system, there is always a complex interface project between PDM and ERP. On purpose I call it PDM as in this type of approach the PLM system is more treated as an engineering tool, not as an enterprise PLM system.
      BOM discussions are the most popular in the PLM community – also in my blog http://www.virtualdutchman.com, the MBOM discussion is the most read post.
      So far my functional thoughts, where hopefully it is clear the whole discussion is very much depending on the major primary business model of the company

      • http://plmdojo.com/ Scott Pigman

        Thanks for the comments, Jos; they’re very educational.

        I came to Teamcenter via the iMan/Teamcenter Engineering branch of its ancestory, the other branch being the Metaphase/Teamcenter Enterprise branch. From what I can tell iMan/TcEng were always more focused on CAD management and PDM than Metaphase/TcEnt, which to me seems to have been more focused on “business” side of things. At least as TcEng was configured where I worked on it, it was very much a PDM engineering tool, not an enterprise PLM solution.*

        Now that we’re in Teamcenter, which wants to be a soup (requirements) to nuts (MRO), and everything (design, manufacturing, etc.) in between PLM solution, I have some learning to do to make sense of how that is supposed to work.

        *Disclaimer: To be honest, it’s hard for me to tell how much of my impression of how the legacy systems were supposed to be used is based on their actual design vs. based on my experience regarding how we happened to actually use them.

      • http://plmdojo.com/ Scott Pigman

        I meant to add, I found your comments about when as separate MBOM is or is not needed to be especially helpful.

    • http://plmdojo.com/ Scott Pigman

      Thanks for the comments, Menk.

      I have conflicting opinions about keeping the same metadata on both structures. From a pure logic point of view I don’t see the need and it violates the principle that programmers call DRY – “Don’t Repeat Yourself”. Put in practical terms it means that if you try to do or store the same thing in multiple places there’s a chance that sooner or later one of those places won’t match the others — hence the need for the system to keep things in sync. But from the end-users’ perspective I can see that they often will want to see part meta-data when they’re working on their CAD models and won’t want to have to navigate TC to get to the corresponding structure. In TC compound- or runtime- properties can give the appearance of duplicated data without actually storing it in two different places, but you do have performance considerations to at least check into.

      The ECAD vs MCAD and EBOM vs. MBOM are also good points, thanks.

  • Teamcenter Heretic

    I recently completed an implementation that used V10.1 and Nx 8.5 and we decided to go the multi-BOM approach. With any luck you may hear a presentation at PLM World discussing this and other thoughts on Architecture.

    BTW, out cardinality is 1 part for 0-1 CAD Designs. You can have a part without a design, but not the other way.

    Here are my thoughts on this:

    The Part BOM is the linchpin of all the future capabilities. Multi-Structure Manager plays a strong role also.
    Using Multi-BOMs is made easier by the Multi-Field Key. If your Part BOM and Design BOMS are in separate domains they can share the same part number. This is a HUGE step forward.
    There are some limited settings in the BMIDE that allow a part to be created form a Design OR vise-versa. This is a nice start but we needed this to happen in both directions as well as when either get revised so this meant some User exit automation needed to be written.
    If you are headed down the MRO road you will be really glad you used the multi-BOM approach. while the MRO module can be configured to use a design object as the Neutral Part it seems to work better with the Part object.
    Vendor Management (once I can get is working) also is happier with a Part instead of a design.

    Downsides:

    As Scott mentions, BOM alignment is a mess. Sure there are tools, but my CAD designers are already making statements like: “I want my CAD BOM to always create a Part BOM. If I have a CAD part in an assembly I want it updated in the Part BOM assembly also.

    I’ve forwarded these statements off to Siemens but I get the sense that they think that the CAD guys are kinda behind the times with their synchronization desires.

    The multi-BOM is worth doing if you have other organizations using Teamcenter in any sophisticated fashion.

    BOMs away!

    • http://plmdojo.com/ Scott Pigman

      Okay, first of all, I’m a little disappointed in myself for not thinking to use “BOMs Away!” in my post title.

      Thanks for mentioning Multi-field Keys. That is a big deal. How far would you be willing to take MFKs? Take the case of the multiple Designs to One Part cardinality. What I’ve seen in one design named with the “pure” part number and the others named with a descriptive suffix, much like we have to do for parts vs. designs vs. drawings in the pre-MFK world. Using MFK though could we not have a MFK field on designs that was Item ID + Item Type + unique description and have all the designs use the same item ID but use the extra field to differentiate them?

      Thanks for the information about MRO and Vendor management. Those are on my distant horizon but I do not know enough about them to have considered the BOM question in relation to them.

      RE: the CAD guys wanting to create the part BOM. We’re dealing with the same mindset. In fact they’ve said to us that they want to model the BOM 100% in CAD — including things like adhesives and reference documents — that don’t have CAD models. So to appease them we’re creating design items that act as placeholders for those items and then our automations that build the part BOM (currently held in another system but eventually moving to TC) will build the complete part BOM from the CAD BOM. I have my doubts about this solution, but we’ll see.

      • Teamcenter Heretic

        The concept of an MFK domain is pretty powerful.

        We have a use the Item domain for all Designs since right now (Nx8.5) you can only support a single domain.

        Call me superstitious but I decided it was best to leave these MFK setting as-shipped because I’m pretty sure nobody tested too much in this area. I also know that few folks have even dipped a toe in the water because I wrote several PRs on the docs being mis-leading ;)

        Since a Design object comes down the Item tree all “Design” BOs must maintain a separate item id. We have a standard Nx Design object, one for Legacy parts (converted from system XorY into Nx) and another for Standard Hardware. sharing a single domain with the multiple BOs allows for enforced uniqueness of the Id but separate cardinality, workflow filters, name rules etc…

        After that we have separate domain for Parts which easily allows us to have a an ACME_Part and an ACME_NxDesign to share an item Id (or an ACME_ComlPart and an ACME_NxHardware), but prevents a ACME_NxHardware and ACME_NxDesign from clashing.

        We do all this with the domain ObjectType{item_id}, however you could use any combination of fields. I like the object type differentiators since I can associate an icon with these as opposed to using a single type but adding something like object_name to the domain.

        Now you can cross out of the tree with domain assignments but in my case I decided not to do so until I make some decisions about my Neutral and Physical Part architectures for MRO.

    • Jeremie FEBURIE

      very interesting answer ! thx

  • Jeremie FEBURIE

    I think it depends how design phases are adressed at each company.

    1rst case : Designer are in charge of CAD structure AND Part structure, in this way managing a single BOM is maybe the best choice. And if they need 2 BOM structures, I think automations are not enougth strong in the system (like Teamcenter Heretic said)

    2nd case : there are 2 stakeholders : CAD Designer who are in charge of CAD Structure Only and Product Engineer that are in charge of managing Part Structure

    And in this 2nd case, there are 2 ways to do it :
    Case 2a) First Product Engineer build their Part structure, then CAD Designer modelize step by step each needed design for each Part that require a 3D Model (and attach them to existing Parts)
    Case 2b) First CAD Designer build CAD Structure, then Product engineer build a Part structure from scratch and link existing designs to newly created parts

    From my point of view, the 2 approaches work …

  • Jeremie FEBURIE

    I think it depends how design is managed.
    1srt case : Designer have to manage Design BOM AND Part Structure.
    In this way, the best choice would be to manage only 1 structure
    But if 2 structures are really needed, I think COTS automations provided are not sufficient (as Teamcenter heretic said)

    2nd case : There are different stakeholders :
    - CAD Designer who are in charge of CAD Structure ONLY
    - Product Engineer who are in charge of Part Structure
    (like J-Fabien said)
    In this case, managing 2 structures is the best way.
    And you could have 2 different way of doing :

    Case 2a) CAD designer first build their CAD Structure.
    Then Product Engineer create a separate Part structure and assign existing CAD items to corresponding Part (they could decide to add a Part that doesn’t require any design Item)
    Case 2b) Product Engineer first build the Part Structure
    Then CAD Designer build a CAD Structure and link each design Item to existing Part.

  • Pingback: The Ugly Truth of Multi-BOM Management | Daily PLM Think Tank Blog

  • Don Knab

    Scott, it’s probably just me, but we seem to be throwing around a few different variations of the terminology.
    What is your interpretation of Part BOM, CAD BOM, EBOM, CAD Structure, Part Structure, and Design BOM (I left out ECAD and MBOM just for simplicity). How do those relate to the different Item Types in Teamcenter (OOTB)?

    Mark, I’d be interested if you used OOTB Item Types on your project.

    • http://plmdojo.com/ Scott Pigman

      naw, I probably have been playing fast and loose with the terminology and probably don’t have the definitions as clear in my own mind as I should have them. At risk of revealing that I’ve got some wildly mistaken interpretations of some of these terms, here’s my attempt at them:

      (By the way, wherever I say, “Instance of [some type]” I really mean “instance of [some type or a sub-type of some type]“)

      * BOM I use BOM to refer to the product structures as stored by Teamcenter. These would be instances of the BOMView/BomViewRevision object types

      * CAD structure The CAD files assembled by the CAD tool to make an assembly. What you’d see in the CAD tool’s internal assembly structure navigator, e.g. the Assembly Navigation Tool, ANT, in NX.

      * CAD BOM The BOM created in Teamcenter for a particular CAD structure. Usually the CAD structure and the CAD BOM are the same, but in NX at least components in the CAD structure could be omitted from the CAD BOM by marking them as “Reference” in the CAD tool.

      If using two BOMs, the components of the CAD BOM would usually be instances of type Design. If using a single BOM I’d expect them to be instances of type Part or just Item.

      * Design BOM A CAD BOM specifically made of instances of type Design.

      * EBOM Engineering BOM. I pretty much use it interchangeably with CAD BOM, but I wonder if that isn’t a mistake.

      * Part BOM In a single-BOM environment, a CAD BOM comprised of instances of type Part. In a multi-BOM environment this is a BOM constructed outside of the CAD tool and aligned with the CAD BOM.

      Maybe can help me with the wording, but to me Parts are the things that go on the actual Bill of Material and are what’s ordered. Parts are what are ordered by the customer, built by the manufacturing department or vendor.

      * ECAD (nice job, btw, of “leaving it out” but actually including it ;-) Electrical CAD. Those tools that are used for designing circuit boards and such.

      * MCAD Mechanical CAD. NX, Catia, Solidworks, Pro-E/Creo, etc.

      * MBOM Manufacturing BOM. Something the manufacturing engineers put together to plan how to build an assembly.

      If we arrive at an agreeable set of definitions I’ll update the post with a sidebar containing the definitions.

      • Jeremie FEBURIE

        well explained !

    • Teamcenter Heretic

      >> Mark, I’d be interested if you used OOTB Item Types on your project.

      Never!

      If you use OOTB Business objects you are left at the whims of the TC developers on what they think you need for stuff.
      Better to sub-class their stuff.

      We created an bstract type for Design. then we created a NxCad Design, LegacyCadDesign, andf a NxComlParteDesign (note that the types are limited to 16 chars).

      I’ve also created a subtype of PhysicalPart for each of ACMEPart and ACMEComlPart.

  • http://www.eng-eng.com/ Ed Lopategui

    My thoughts – CAD and EBOM need to be very closely coupled, though making them exactly the same is probably pointless. As you mentioned, if you are using NX within TC, it’s pretty achievable in that anything in the CAD that doesn’t belong in the EBOM can be handled with reference only while the opposite is handled by BOM items with CAD Geometry set to NO. In the case of multiple designs for one part, like an electrical harness, deformable parts are also an option.

    We did just that at a prior employer – including a customized program that compared what was in the CAD and what was in the PSE and flagged anything that didn’t fit the rules of the company and needed attention. This made the alignment immune to manual shenanigans.

    But why do that, you might ask? Plenty of good reasons. We found that tying the part knowledge from the manufacturing side early in the process was tremendously beneficial. It helped identify long lead items early in design as new parts where cataloged over on the SAP side at the instance they were included in the assembly. Engineers would get costing, supply, and lead time info as their designs developed (and while they could still do something about it!) It drove everyone to use the same set of validated standard parts. And the big one for me – you know that mess in the CAD file with someone’s back deck modeled in there somewhere? This process, though painful at first, finally brought the banhammer down on all the garbage – and our data quality was vastly improved. You couldn’t imagine how many people where destroying their own productivity by including half the airplane in their assemblies. The only way to quash this is to forcibly align.

    Finally, you’re already going to have quite a few BOMs down the line, MBOM, BOP, As-Maintained, why add yet another potential avenue for reconciliation activities?

  • Jeremie FEBURIE
    • Teamcenter Heretic

      So, why not post here directly instead of pointing folks back to Oleg’s blog?
      This is kinda a Teamcenter specific topic and the comments are worthy of posting here and not some other location.

      The dilution of content really drive me crazy!! Seems like Oleg’s comments belong here, not somewhere else IMNSHO….

  • Pingback: The BOMinomicon | E(E)

  • Colin Bull

    I think that it is pointed out but the one advantage of the separation of the CAD structure and the EBOM structure is that we now live in a multi-cad world, this means that some parts of the organisation run with NX, CATIA, Inventor. Also ECAD requires specific management capabilities and cannot be easily joined with a MCAD BOM as such. So the only way to join these up is in the EBOM.
    Windchill has had this concept for a while now, the CAD is just a document and you link that document to the WTPart.

Optimization WordPress Plugins & Solutions by W3 EDGE