Why PLM is failing to manage multi-disciplinary BOM?

Why PLM is failing to manage multi-disciplinary BOM?


Products are getting complex these days. Look on every small electronic gadget in your hands. It is actually combined from multiple pieces – mechanical parts, plastics, electronic and software. Traditionally you are using separate tools to design these parts – MCAD, PCB design, software tools. Then it gets tricky a bit – you need to put together right information about the product, manage changes, coordinate with suppliers, etc. PLM tools are here to help. But, for some reasons, it is a difficult problem to handle.

Engineering.com article In High-Tech Electronics, Managing Three Lifecycles As One is a New Key to Product Development by Laila Hirr speaks exactly about that problem. Here is my favorite passage from the article explaining the problem:

HTE’s need for PLM is straightforward—a firmer grasp of the information generated before and during product development and subsequently “in the field.” Many information needs go unmet when products go into assembly operations of original equipment manufacturers (OEMs) and built into other manufacturers’ components in complex supply chains. Users and system integrators may also be slow to share information.

For many reasons, PLM has repeatedly fallen short in this industrial sector. At CIMdata, the reason we see most often is a lack of integration with the full information set that defines the product. Achieving this integration is a multidisciplinary challenge and in PLM’s twenty-plus year history with the high tech industry, the challenge has yet to be resolved. This largely accounts for the scarcity of compelling PLM successes in HTE and the ongoing skepticism about PLM.

Article speaks about absence of integration between tools and dependencies on homegrown spreadsheets to manage bill of materials and change. Which made me think about core problem in PLM tools – management of multi-disciplinary BOM. I addressed this problem in the keynote presentation at ProSTEP iViP Symposium few weeks ago – PLM and ERP: separated by a common Bill of Materials (BOM). PLM systems today are addressing BOM management. Most of them are taking an approach to manage multiple bill of materials view. However, these tools are not efficient enough to manage a BOM which contains mechanical, electronic and software pieces together.  The complexity of BOM is driven by multiple disciplines, change management and product lifecycle as I presented on the following slide


What is my conclusion? Technical difficulties and disagreement between people often can lead to problems in establishment of cohesive BOM management solutions. PLM fails to provide a way to manage multi-disciplinary BOM and changes. High-tech and electronic industry is specific because of high diversity of design tools – mechanical, electronic, software. PLM tools are not integrated well with design tool, which leads to poor BOM management. There are several reasons why it happens – limits of BOM management tools, complexity of integrations between design tools provided by multiple suppliers, UI complexity. Just my thoughts..

Best, Oleg

Image courtesy of Toa55 at FreeDigitalPhotos.net



Share This Post

  • Hi Oleg, what about Arena PLM, do you think they are in advance in that field? Based on their customer references it would be interesting to see how BOMs are managed and is software involved. My company mydatalinx, is actually working on this. Trying to browser code repository and link the right tag to the right electronic board,…

  • beyondplm

    Yoann, this is a good question! I’ve heard about many examples of Arena managing BOM. Most of them are about electronic industry. I think, Arena is a best fit for the scenario of “one BOM” with multiple suppliers. I’m not sure understand your case with right tags on electronic board. But I’m open to discuss – contact me at oleg at beyondplm dot com.

  • The biggest challenge involves how change is managed between the mechanical world and the software world. The difference is night and day. The former is more serial, the latter is a branching complex interrelated web. The former are usually self-contained products, the latter almost never is. A truly multi-disciplinary BOM has to understand both methods of change and freely move between them, building relationships which will almost never be 1:1. Electrical change reflects mechanical more closely which is why ECAD/MCAD synthesis has often been the first step in multi-domain design.

  • beyondplm

    Ed, you are right- there are many challenges in multi-disciplinary design. MCAD/ECAD is more achievable and MCAD is often leading changes. Software is too much disconnected. I never seen a company that combined two in a practical way. Did you?

  • I’ve seen a few noble attempts, but nothing really robust. One additional challenge in most projects that integrate both hardware and software – usually when the software organization is really churning on changes, the mechanical design has long been completed and de-staffed. Rarely have I seen both disciplines operate completely in parallel.

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Future competition of PLM in Electronic Design  ()

  • Pingback: Future PLM competition in Electronic Design | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Common product lifecycle between hardware and software()

  • Pingback: Common product lifecycle between hardware and software | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Who needs single source of truth for BoM?()