How Distributed PLM functionality in Planning Systems Differs from BOM Management

What This Article Covers

  • Why is PLM such a confusing subject for many people?
  • What is the status of master data generally and what are its needs?
  • What is the imbalance between the ability to create versus update master data?
  • Why is ERP often confused with BOM management software?
  • How does confusion among the different terms and functionality is holding companies back from getting the solutions that can benefit them?
  • Should companies accept weak BOM functionality just because a software vendor is a major brand?

Introduction

Of the different solutions that we cover (supply planning, demand planning, etc…), PLM is the most conflicted, and the most confusing to people. It took me several years to understand how PLM is different from BOM management. Having finally figured it out, I thought it would be good to write an article on it as others must be confused as well. I have found the comparison to be one of the best ways to understand a topic, so I will bring up other application categories to explain and differentiate PLM and BOM management.

The Master Data Relationship

To begin, all master data is subject to constant change. New suppliers replace old suppliers, and people join and leave the company, and this has always been how things worked since before computers and since the initial record keeping systems were maintained. An ancient topic, for some reason, master data has become extremely topical in roughly the past five years. Lately, anything to do with controlling and updating this master data has come under the moniker of master data management or MDM. This could be the topic of another article, as MDM how now become almost synonymous with a software solution, which it need not be. However, in the interests of clarity and topic separation, I will just refer to the generic term of master data management (lower case) without all the connotations of MDM.

Thus master data of all types turns over and must be changed. My experience and the experience of others indicate that more often than not companies have a far greater ability to create master data than to maintain master data correctly. Improper maintenance can be due to a lack of resources or focus or due to too many individual having access to make changes that may be suitable for one person or group but are not good for the company.

The Bill of Material

In supply chain, master data covers many topics. However, one of the most critical and most collaborative is the material and the bill of equipment. The maintenance of these objects are so important, requires so many inputs from those inside and outside the company and is so labor intensive that a classification of software rose to manage them. However, along with the way product life-cycle management become intertwined with the bill of material management, even though there are many other types of functionality related to the turnover of material that are spread through different applications that are not distinct to the bill of equipment. This comes partially from confusing messages brought by vendors and consultants and partly from a lack of familiarity with the nuts and bolts of how these different systems work. I have listed several of the life-cycle functionalities that exist in nonBOM management systems below.

None of these discrete areas of functionality have anything to do with turning over the bill of material records, in fact, they reside in planning systems that are not the system of record for bills of material, but only copy the material and bill of material records from the ERP system on a periodic basis. Secondly, this is not a complete list as their are life-cycle areas of functionality within ERP that are also unrelated to BOM management. I simply listed the areas of life-cycle functionality I am most familiar with.

Understanding BOM Management

BOM management is a distinct application that allows for the maintenance, sharing and controlling of the bill of material. Here again a problem of both semantics and capability differences arise. Every ERP vendor can claim to have bill of material management functionality, as all ERP vendors from the biggest to the smallest must develop functionality to keep materials and bills of materials in the system so they can be accessed by the rest of the ERP functionality. However, this does not mean that they have BOM management software. It only means that they have the ability to represent materials and bills of material, which is axiomatic.

What Are the Differences?

Leading solutions work as separate systems that create a collaborative environment, that provide a high degree of functionality and control over the BOM. The BOM management software is constantly being accessed, changed, updated, and used for collaboration. However, the ERP system only needs materials and BOMs when they are ready to be put into production. They also need to have old BOMs and materials removed from the system. So the distinction between a full BOM management system vs. the material requirements of an ERP system is another important distinction in understanding this space.

The Importance of Separating Things to Properly Understand Them

Without an appreciation for the definition of the lifecycle, PLM, and BOM management, it is tough to make good decisions related to acquisition and deployment of the software that resides in these multiple categories. Confusion among the different terms and functionality is holding companies back from getting the solutions that can benefit them.

When comparing “PLM” and BOM management solutions, it is important to ask these questions:

  1. Is the solution primarily focused on managing the material and BOM objects or something else?
  2. Is the solution presented a separate application, or is it pieces of functionality distributed throughout these larger ERP suite? PLM and BOM management are not the same things. Ask for an explanation as to what central problem the software is trying to solve.
  3. How strong are the collaborative capabilities of the software? BOM management requirements are inherently collaborative, and outside collaborative parties, in particular, must be able to quickly and easily use the application. The standard has been set by Arena in this area, and acceptance of a lower level of collaboration functionality must have an excellent justification. Lessons from collaboration projects are that unless the software is easy to use, it generally won’t be used. The collaborative capability of this class of software can’t be just “ok” it must be exceptional.

These questions and approach of thinking can help anyone understand that they are evaluating when assessing this classification of software.

Arena has articles that explain the differences between PLM and BOM well.