How Distributed PLM functionality in Planning Systems Differs from BOM Management
Executive Summary
- 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 hold 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 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 with, all master data is subject to constant change. New suppliers replace old suppliers, and people join and leave the company. 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 another article’s topic, 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 refer to the generic term of master data management (lower case) without all the connotations of MDM.
Thus master data of all types turn 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 too many individuals having access to making changes that may be suitable for one person or group but are not good for the company.
The Bill of Material
In the 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 is so essential, requires so many inputs from those inside and outside the company, and is so labor-intensive that software classification rose to manage them. However, along with the way product, life-cycle management becomes intertwined with the bill of material management, even though there are many other types of functionality related to the turnover of material spread through different applications that are not distinct from 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. They reside in planning systems that are not the record system for bills of material but only copy the material and bill of material records from the ERP system periodically. Secondly, this is not a complete list as there are life-cycle areas of functionality within ERP that are also unrelated to BOM management. I 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 material bills. Here again, a problem of both semantics and capability differences arise. Every ERP vendor can claim to have a 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 the rest of the ERP functionality can access them. However, this does not mean that they have BOM management software. It only means that they can 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 provides a high degree of functionality and control over the BOM. The BOM management software is continually being accessed, changed, updated, and used for collaboration. However, the ERP system only needs materials and BOMs when 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 Understand Them Properly
Without an appreciation for the life-cycle, PLM, and BOM management definition, it is tough to make the right decisions related to the 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 essential to ask these questions:
- Is the solution primarily focused on managing the material and BOM objects or something else?
- Is the solution presented as a separate application, or is it pieces of functionality distributed throughout this 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.
- 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. Arena has set the standard in this area, and acceptance of a lower level of collaboration functionality must have an excellent justification. Lessons from collaboration projects are that it generally won’t be used unless the software is easy to use. The collaborative capability of this class of software can’t be just “ok.” It must be exceptional.
These questions and approaches of thinking can help anyone understand that they are evaluating when assessing software classification.
The Arena has articles that explain the differences between PLM and BOM well.