Introduction

What is commonly referred to, as PLM is one of the most confusing areas of enterprise software. Given the limited published information available on the bill of materials (BOM), one initially wonders where decision makers are getting their information about how to intelligently manage the this essential master data object.

Some History on Terminology

Several years ago the concept of PLM became very popular. SAP introduced a PLM “product,” that was not actually a product but merely a listing of pre-existing functionality that controlled life-cycle aspects of the product. The solution never existed and never made any sense, and gradually fell into the dustbin of failed SAP products that both no one seems to remember and no one discusses. I wrote on this topic back in 2009 and this article.

When PLM began to become a popular term, vendors like Arena Solutions and Siemens that had software that managed the bill of material (that of course has many life-cycle attributes) adopted the term PLM for their product. This was a problem because software that manages the BOM, but controls for life-cycle and ERP systems that also have life-cycle functionality are not in the same application category, yet they both used the same terminology. This confusion persisted for years, with vendors like Arena trying to explain the terminology they had selected. Eventually, Arena moved away from the term to BOM management. Unfortunately there are still many BMS vendors, like Siemens that still use the term PLM.

The nomenclature of PLM was actually an unfortunate but deliberate linguistic obfuscation made by the management at some software vendor and then copied by other software vendors. It eventually became standard terminology in the field. This decision never made any sense logically, but at any time there are illogical and terminologically incorrect marketing initiatives at many enterprise software vendors. In the enterprise software space, product sales success trumps all reasonable accuracy standards. This is why it is quite dangerous for company executives to read vendor literature without having it screened by content experts in the literature’s field that are paid by the implementing company, but also do not receive a financial benefit (i.e. a consulting company) from uncritically analyzing information provided by the software vendor. With the right PLM/BOM Management software, many of the old techniques that have been applied to BOMs for decades, such as modularizing the BOM, flattening the BOM or creating phantom BOMs are no longer necessary.

Standardizing the Term

The decision to standardize around the term has actually resulted in slowed development in this software category. Because the term PLM is so poorly defined, vendors who don’t really have a solution have been able to pose as if they do, resulting in a great deal of confusion for buyers. What has become evident is that many marketing professionals at software vendors have been unconcerned with even elementary accuracy, which is accuracy in terminology.

However across the software segment, it is a mixed bag with regards to terminology, as Siemens and Agile still use the term PLM to describe their applications. Unfortunately, using the term PLM to describe a single application little sense because lifecycle planning is comprised of a large swath of functionality, which is distributed throughout a wide variety of enterprise applications. For instance lifecycle functionality exists in product design systems, demand planning, supply planning and also production planning, as well as ERP and the BMMS. Demand planning applications typically have a segment of their functionality dedicated to lifecycle management, however the BOM for the most part is never part of demand planning applications.

The Lifecycle of a BOM (or Recipe)

The BOM begins its life in the design and engineering systems as the engineering BOM or EBOM. The rest of the company is usually oblivious to—and has little reason to be concerned with—the many BOMs and changes to BOMs made by design and engineering. For the rest of the organization the BOM only becomes relevant when it is approved to be an actual manufactured or ordered (in the case of contract manufacturing) product. Of course a great deal of work occurs before this happens:

1. The product must be conceived.
2. It must go through many design revisions and design changes.
3. Suppliers must either bid on many of the input parts (in the case of products that are manufactured internally) or on both the input parts and the overall manufacturing (in the case of contract manufacturing).

The BOM will experience the most dynamic changes during the engineering and design stage. During this stage, design and graphics files are included into the process and added to the BOM. Not all the information that is created in this stage is included in the manufacturing BOM (MBOM). While the BMMS represents multimedia files, the files are initially produced in a separate system, often a Computer Aided Design (CAD) system. Examples of CAD systems include AutoCAD and SolidWorks. These systems may store their data in another system called a product data management (PDM) system. The PDM can be thought of as the central organizing store for the CAD systems. Some companies have the BMMS connected to the PDM.

Multi-dimensional Relationships

One easy way of understanding the highly linked nature of a BOM and its subcomponents is to consider that one subcomponent is often part of more than one parent component. Therefore, by using a relational BOM configuration, which is different from a relational database; you can use a relational database, but still follow a restricted hierarchical model in your BOM configuration. When the subcomponent is changed in one location, it immediately affects all parent components; immediacy in that change and how it affects other BOMs is the desired end state. The goal is for all parent products (i.e., BOMs) to be updated instantly when a subcomponent is changed, regardless of the product’s life-stage. The updated part data is then sent over to the planning system, where a flag is changed to tell the planning system that the part should no longer be planned. Updating this data is as important as the algorithms you use to produce a forecast. Some of the principles discussed up to this point are demonstrated in the following screen shots in the PLM/BOM management software vendor Arena Solutions.

In Arena, BOM, parts, suppliers, etc. can be easily searched and are easily interrelated.

We can select the item...

…or we can search by supplier.

The search by supplier very quickly leads to the parts supplied by the supplier. In Arena, it is never difficult to get to related objects.

While a BOM is a complete representation of a final product, it is made up of a hierarchy of parts that are all inter-related (or should I say, that is one way of interpreting or showing the BOM).

The ERP BOM Model

BOMs as implemented in ERP systems are increasingly dated and based upon a time when design, engineering, manufacturing and supply chain were all performed by one company at one location. ERP systems are by design, focused internally. Generally speaking, people do not login to the ERP system of another company, and the ERP system interacts with systems external to the company primarily through transactions such as purchase orders. In today’s environment, functions previously performed in-house are increasingly spread out across multiple companies, and ERP systems do not work very well in this environment. Furthermore, ERP BOMs have stayed static, even as the BOM functionality in the engineering and design side of the business has drastically improved. At this point, a BOM that is adjusted and reviewed by internal employees only is really an anachronism in an environment where engineering, design and manufacturing is spread out among many companies. BOMs today need to be highly collaborative and therefore a highly collaborative environment to enable the work that needs to be done. Never before has maintaining BOMs in ERP systems or spreadsheets been so out of touch with what is happening in business.

Spreadsheet Search Capabilities

When a company says they manage their BOMs or recipes in an ERP system, what this actually means is that they use a combination of ERP and spreadsheets. Searching can work pretty well on a small spreadsheet with low complexity. However, as the spreadsheet becomes more massive (and BOM spreadsheets must be large unless the company makes only a few products), the ability to effectively search through them is limited. , Further limitations in performing useful searches exist if some identical parts have different numbers.

Companies will often use advanced functions in Excel, with the purpose of making the program more capable of managing the BOM. One example is the ability to search for components that are used across products for the purpose of negotiation with suppliers. Finding all of the components is a challenge, particularly when an identical component has been assigned different part numbers, meaning that applying a simple filter to the spreadsheet may not work. Advanced functions inside of Excel may be required to enable the planning engineer to perform these types of searches. However as pointed out by Arena Solutions, this solution is filled with problems.

Companies often try to solve that problem by adding complexity into their Excel spreadsheet BOMs. They use tactics like item master tabs, lookup formulas, cross-referenced spreadsheets and Visual Basic programming — especially if they have an Excel guru on staff. This works as long as your Excel master keeps the connections up to date so they correctly fill in the cells. But this person is now also a single point of failure in an intricate web of files. The BOM management process is in his or her head and buried in the details of an unknown number of hidden tabs on countless spreadsheets. – “Using Excel for Bill of Materials (BOM) Management”, Arena Solutions

With a PLM/BOM management system, the search for product components is a simple query that can be performed across the entire BOM database in order to aggregate all of the components in the different products that will be required within specific time frames. The next step is to combine the forecast for each component by the number of components per BOM for all the BOMs in the BOM database, as represented by the formula below:

The Number of Final Products

X

The Number of Components Per Final Product

X

The Time Phased Forecast for the Final Product

=

 The Total Component Demand Communicated to the Supplier 

By providing the ability to perform this calculation quickly and with little effort, the PLM/BOM management system helps the user to avoid missing any of the components, translating to an improved components forecast. The more comprehensive the unit estimate, the higher the number of units, the greater the negotiating leverage and the lower the price of each component. Therefore, the ability to easily obtain this information with queries on the PLM/BOM management system results in lower costs to the company. In fact, a good PLM/BOM management system will be able to show relationships in BOMs very naturally, as the “Where Used” view below demonstrates.

The Arena “Where Used” view allows a user to quickly trace where a part is used across any BOM in the system. This showcases the active associative linking within Arena Solutions. Finding associations like this in Arena Solutions is very natural, and does not require going to any special area within the application. The application allows a natural flow between the data elements.

While BOMs are often spoken of as being managed in spreadsheets, this is an oversimplification of what happens in reality. While the BOM’s connection logic, and naming and numbering information, is contained or modeled in a spreadsheet, many other pieces of related information necessary to understanding the BOM in its totality are kept in different files and different file formats. The user then uses the spreadsheet as an index to find the names of these associated files. All of this is a great deal of overhead and maintenance. While the tools to manage a BOM this way are either free or very inexpensive, the costs in time and inefficiency are quite significant.

The Need for an Application to Manage your Recipe/Formula/BOM

In the Brightwork Research & Analysis Press book Bill of Materials in Excel, Planning, ERP and BMMS/PLM Software provides ample evidence, which is laid out in a complete form that every company requires an application for managing their BOM/recipe/formulas. The use of these types of systems allows the company using the application to more efficiently perform the following activities.

1. Improve design efficiency
2. Allows for more simulation and trial and error – promoting creativity in the design process – all without the necessity of creating permanent records in process of developing new designs.
3. Improves internal understanding and coordination on recipes – some applications like Hamilton Grant allow for manufacturer’s instructions and trial notes to be stored.
4. Groups working in different geographies can more efficiently work as teams and coordinate their efforts. Workers that are not in the office, but which may need to provide review input can access the system remotely to provide critical and timely input.
5. Improves the speed of recipe/formula development
6. Allows companies to better manage their product costs
7. Allows companies to more efficiently integrate with suppliers by sharing and providing access to either the entire recipe/formula or just to portions of the recipe/formula. In fact, these types of systems double as supplier management systems as well as product data management systems. Once product data is in a highly organized and sharable form, it has numerous uses.
8. Related to the previous point, allows the company to work with more suppliers as the costs of interacting with any one supplier is lower.
9. Keeps all of the ingredient, packaging, recipe, process and quality information in one place.
10. Improves recipe/formula re-usability
11. Improves compliance with legislative standards (which vary significantly by industry – but are quite important in food and beverage and pharmaceuticals)
12. Simulate the effect on essential indicators during potential redesigns.

We estimate that BOM/recipe/formula management applications to have the highest return on investment of any enterprise software category that we cover. A primary reason for this is so many parts of the business rely upon product information and therefore can benefit from a single application. Design and engineering, supply chain, finance, supplier relations – all of these sides of the business benefit. Furthermore each side of the business, as well as external parties, are better integrated through the use of this type of application. Here is an example from one vendor of how their recipe management software works:

Recipe management can even create least-cost recipes from scratch. You can reuse your knowledge by using templates. These templates define the ingredients that can be used and the constraints on nutritional content and ingredient quantities (even for rework). –  Adifo Software

Secondly, the better applications in the PLM software category can be brought up more quickly than most of the other software categories.

Traditionally, a BOM is considered to be a master data object, more limited than what has been described up to this point. Whether you agree with the limited definition of a more expanded view may change based upon which software is being discussed. For example, in applications with a limited representation of the BOM, the traditional definition is correct. However, the broader definition is more applicable to advanced applications that specialize in BOM management. As such, PLM/BOM management system software has permanently enlarged what is represented by a BOM. In fact a significant strength of a PLM/BOM management system is that it integrated the master data object with the other data associated with the BOM, making the PLM/BOM management system a compelling application for understanding, storage and collaboration on the BOM.

Without understanding the definitions of lifecycle, PLM and BOM management, good decisions regarding the acquisition and deployment of the software in these categories are very difficult to make. Confusion between the different terms and functionalities prevents companies from getting the appropriate solutions to improve how they manage the BOM. When comparing “PLM” and BOM management solutions, it’s important to ask software vendors these questions:

1. Is the solution primarily focused on managing the material and BOM objects or something else?
2. Is the solution presented as a separate application, or as functionality that is distributed throughout the larger ERP suite?
3. PLM and BOM management are not the same thing. Ask for an explanation as to what central problem the software is trying to solve, and then how the software solves it. For instance, the solution offered by SAP does not address BOM management and incorporates areas of functionality and a CAD application related to engineering and design, which is not part of BOM management. Some of the solutions offered in this space don’t make any sense. They are the result of a software vendor cobbling together a product with whatever is handy, and pushing it out even though it doesn’t actually meet the real requirements of BOM management. The fact that a PLM vendor happens to be the same software vendor that makes the company’s current ERP system is not a good enough reason to select their application, particularly if they have a low probability of meeting the business requirements. Attention to business requirements detail is essential for all software selections, but is of particular importance in the BMMS/PLM market.

Accessing Collaborative Software for the BOM and Recipe

BOM management requirements are inherently collaborative and outside parties in particular must be able to quickly and easily use the application. The standard has already been set in this area, and acceptance of a lower level of collaboration functionality must be well-justified.

The Differences Between BOMs and Recipes and Formulas

If one thinks of the standard discrete manufacturing BOM it begins with many parts and culminates in a single finished good item. This is shown in the graphic below:

A typical discrete manufacturing ERP system, such as ERPNext, will have one field for the finished good, as can be seen in the screen shot below.

Here one can see that the BOM functionality in ERPNext is designed for discrete and repetitive manufacturing as one can only input a single finished good.

Although interestingly enough, ERPNext has the second functionality required to manage recipes, which is the ability to use a fraction as an input product on the BOM. 

If the number of output/finished goods is limited to one, then this application will unsuitable for most process manufacturing environments. The following quotation explains why this is the case.

In food, pharmaceutical and chemical plants, many processes result in multiple outputs which looks more like an “X” structure. Take for example, a chicken disassembly process where the one chicken can produce 20-30 separate end products that can be sold or used for further processing. Another example is an oil refinery in which the raw material (crude oil) is refined into several types of product such as natural gas, rich oil, light cycle oil and decanted oil resembling a “V” structure.  – Process Industry ERP Requirements

Recipes and Formulas

While the term “formula” is sometimes used interchangeably with the term “recipe,” a formula and a recipe is not the same thing. A formula is in fact a subcomponent of a recipe. Formulas can be completely separate objects and a formula can be a production schedule all by itself—that is it can stand different from a recipe. In most cases a formula does not stand separately, and is combined as part of a subordinate object to a larger recipe, which contains multiple formulas. It is common to have numerous formulas within a recipe because each formula relates to the manufacturing configuration of a semi-finished good. It is also quite common for semi-finished goods to have complex formulas of their own that must be processed as part of the in-process manufacturing steps. Let us now get into how recipes are used in SAP ERP (as an example of how recipes are used in ERP systems generally). But before we do that we need to explain the concept of a production version.

Process industry companies face the same challenges with respect to managing the product information as discrete and repetitive manufacturing companies when it comes to recipe and formula variants. Many companies undermine their capabilities by attempting to manage these objects in ERP systems – to which the Brightwork Research & Analysis Press book Bill of Materials in Excel, Planning, ERP and BMMS/PLM Software, is focused on explaining why is an ineffective approach. The fact that process industry finished goods can be disassembled while discrete and repetitive finished goods cannot has no interaction here, because finished products are not in fact disassembled—this is merely a way to differentiate between manufacturing categories. For instance, there can be a wide variety of formulas for the same recipe. All companies face the need for costing BOMs/recipes, which are driven by finance.

The case must be made that it makes the most sense to treat recipes and formulas as if they are BOMs. Most material on this topic takes a different view, but in this chapter I hope to prove to you that there is no difference between the recipe, formula and the BOM aside from nomenclature, and that by thinking of them as different, one will tend to place unnecessary limitations on how you manage them.

Software Category Summary

We rate the software category of PLM/BOM/Recipe Management to be the highest ROI of all enterprise software categories. Client ability to implement PLM is low compared to other solution areas analyzed in this site. The first reason is the great confusion regarding what PLM actually is and bad experiences with vendors like SAP that were selling vapor as a solution. However, the low cost of the leading PLM solution vs. the financial and organizational benefits of this software make the paucity of PLM implementations one of the great value opportunities in enterprise software.

The software in this category can be implemented quickly, is relatively inexpensive, changes the entire process of how these master data objects are managed for the better and improves the efficiency of all of the applications that work with the BOM or recipe, which is quite a few applications. Selection of the right software allows for extensive collaboration on the BOM and recipe both internally and with external partners. There are several excellent applications to choose from and many buyers that are not even thinking of PLM/BOM/Recipe Management should put this software category at the top of their list.

MUFI Rating & Risk

See the MUFI Ratings & Risk below for all of the applications we cover.