BOM 101: How to modularize the Bill of Materials

February 14, 2013

I want to get back to my BOM 101. In my view, Bill of Material management is one of the fundamental processes in PDM/PLM and requires lots of attention. I want to take the feedback made by Jos Voskuil and turn the conversation to be more business oriented. One of the trends in manufacturing today is customization. And this is a big challenge for manufacturing companies. Life was good in mass-production world, when the goal was to provide large series of items with predefined configurations. Not anymore… Today, clients are interested to how customize everything. Companies dealing with ETO type of business are facing similar challenges.

Efficient Bill of Materials management system can solve this problem. If you have flexible BOM management system allowing you to manipulate BOM structures and integrated with you ERP environment, you are half way done. However, technology out of the box won’t help you. It requires to apply some best practices too. One of the practices I want to discuss is "modular Bill of Materials". Wikipedia provide a very short article about that, but I liked the definition.

Modular BOMs define the component materials, documents, parts and engineering drawings needed to complete a sub-assembly. While the terms BOM and modular BOM are most commonly used in association with physical products, the concept can be used in a variety of industries (e.g. software, medical records). Modular BOMs are used by modern information systems to serve a variety of purposes, such as defining the components needed to produce a sub-assembly, and providing cost information for each component and "rolled-up" cost information for the overall sub-assembly.

The core idea of modularization is to create a set of "modules" (aka sub-assemblies) that you can manipulate in order to create a final product. The product development process will be divided into two essential steps: create your modular bills and create a planning bill for a specific product. The last one will allow you to roll out cost and delivery time for a specific product order. Below I put five steps to follow in order to modularize the process of Bill of Material management in your company.

1. Identify family groups. This work can take time, but will allow you to make some steps to improve you product portfolio. Most probably you already have some portfolio management tools in house. Engineering has a tendency to complicate everything. So, you may find an overwhelming number of product families in your company. So, you must take some time and optimize that.

2. Identify options. These are elements of products and bill of materials that can be added to multiple product families. Usually represents additional features that can be added and can be replaced. The typical example of options is different configuration of car in-dash navigation and entertainment system. What is also important at this stage is to identify constraints between options (conflicts, incompatibilities, etc.)

3. Create Master Bill of Materials. This is a very important step. Master Bill of Materials represents all families and all options. This is "THE" bill of materials of all your products, which allows you to plan and to manufacture any product and configurations. In most of BOM management system you operate with ‘phantom’ feature to create an efficient master bill of materials. The reliability of BOM management system is very important at this stage.

4. Create planning BOM. Planning bill of materials represents a specific product, configuration, order, etc. You generate "planning BOM" out of your master BOM in order to create a specific delivery task for your manufacturing system. You practically derive your planning BOM out of Master BOM. Tools that allows you to copy/compare structures and BOM levels are absolute must to make it work.

5. End item bill. This is a final stage. End item bill represent the customer world and the way to translate planning bill of materials into the delivery. There are multiple ways to create end item bills – create bill for every SKU#, manually configure options or implement automatic rule based configurations. In my view, the last one is the most promising alternative. However, it requires additional efforts to implement. So, don’t be surprise many of customers are manually configuring end item bills.

What is my conclusion? Modern manufacturing practices require good technologies and best practices applied together. To me, BOM modularization is one of best examples. You need to have an efficient BOM management system with technologies and user experience allowing you to work collaboratively on BOM in a very granular way. At the same time, you need to apply some planning steps to rationalize and optimize the way you work with configurations, custom orders and product customizations. The cost is a fundamental driver in a modern manufacturing world. An efficient BOM modularization will allow you to follow demands of customers for customization and keep product cost down. Just my thoughts…

Best, Oleg

Image courtesy of Salvatore Vuono / FreeDigitalPhotos.net

Leave a Comment » | Daily PLM Think Tank | Tagged: , , , | Permalink
Posted by olegshilovitsky

Dogfooding and PLM APIs random thoughts

November 14, 2012

If you are long time enough in software business you should be familiar with the term "dogfooding" (or eat your own dog food). This term used to explain the situation or scenario in which company is using their own products to demonstrate their capabilities and quality. If you are not familiar with this process, navigate to the following Wikipedia article to read more. I liked some examples there, specifically, Apple one, which I wasn’t aware about -

Apple Computer president Michael Scott in 1980 wrote a memo announcing that "EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc." by the computer company, with a goal to eliminate typewriters by 1 January 1981.[9]

The following passage brings few more examples:

One perceived advantage beyond marketing is that dogfooding allows employees to test their company’s products in real-life scenarios,[3][5] and gives management a sense of how the product will be used, all before launch to consumers.[5] In software development, the practice of dogfooding with build branches, private (or buddy) builds, and private testing can allow several validation passes before the code is integrated with the normal daily builds. The practice leads to more stable builds[citation needed], and proactive resolution of potential inconsistency and dependency issues, especially when several developers or teams work on the same product. For example, Microsoft and Google emphasize the internal use of their own software products[citation needed]. For Microsoft, especially during the development stage, all employees across the corporation have access to daily Software builds of most products in development, including the Windows operating system.[citation needed]

Today, I want to speak about specific "dogfooding", which is related to PDM/PLM APIs or (Application Programming Interfaces). In the world of PLM implementations, the role of Open API becomes very important. Usually, when I’m working with customer requirements, I can see the following notes – external programming or customization as a way to resolve features or function absence available in the product. Yesterday, I had a chance to read the following TechCrunch article – 5 Rules for API Management. Even if you are not programmer or software engineer, have a read and make your opinion.

The article made me think of the complexity of API delivery in PDM/PLM as well as about "lifecycle". The latest is important – PDM/PLM products live very long period of time, and the development of stable APIs is a separate and almost "must have" a prerequisite. The 5 rules – design, documentation, analytics, universal access and uptime made a perfect sense to me. I found interesting note about the relationships between IT and business group (which is also very typical for many PDM/PLM implementations):

Enterprise API Management must include the entire Enterprise, not just the techies in IT. The SOA solution, and the other gateways as well, is focused on the IT person and not the business owner of the API program. This is reflected in the UI that they present in their free version as well as their language that includes things like “policies”; too much of the business rules are codified in complex policies that require a technical expert to really use.

However, I found the notion of analytics, mostly interesting, since it can address the idea and requirements of API management through the lifecycle of the product. Here is the passage to think about:

…[how to] think about the collection and processing of all the statistics associated with the use of the API, with an eye toward supporting and encouraging effective usage and discouraging/limiting usage that is counter to your business or technology goals.

What is my conclusion? The days of single PLM platforms are almost gone. The future belongs to Networks. Data networks, product and cloud services networks. The ability to adapt a product to customer needs, to continue product development in a fast-changing customer environment and strategic goal for cloud, deployment set new goals in front of PDM / PLM developers. The importance of having agile and flexible API that can sustain many product releases and development cycles was never as important as of today. Just my thoughts…

Best, Oleg

Image is courtesy of TechCrunch article (Feature image courtesy of XPlane – under Creative Commons.)

Leave a Comment » | Daily PLM Think Tank | Tagged: , , , | Permalink
Posted by olegshilovitsky

PDM/PLM and Customization

April 21, 2010

Customization is a topic in Product Lifecycle Management that always raises discussions. There are multiple aspects related to customization of PLM systems, and I decided to explore them. In my view, the nature of PLM system customization is deeply related to engineering and product development aspects that in most of the manufacturing organizations are related to their core competencies and touch many processes in the organization. To be able to support them PLM systems are providing various customization capabilities. On the other side, the total cost of PLM systems and especially cost of changes becomes crucial for many companies and implementations. When it comes to implementation cost, need to customize PLM system becomes a negative factor.

Early Monsters
In the early beginning, PDM started as a completely customizable toolkit-oriented systems. In order to implementation and customize them, the significant amount of work needs to be done. For most of the early cases, vendors provided unique production builds of the systems dedicated to a particular customer. PDM was considered as 1M dollars project.

Flexible Data Models and API
Since demand on PDM/PLM systems started to grow, vendors looked how possible to deliver PDM system that will not require a significant effort in order to be customized and tailored to customer needs. The concept of “a flexible data model” was born and few very innovative systems were introduced to the market in late 80s and early 90′s. They provided set of customization tools to modify data schema and additional parameters as well as advanced APIs to support customer-oriented environment. Later in the mid of 90s, more PDM systems were created under significant influence of Microsoft Windows environment.

Out-Of-The-Box PLM
Next step in the PDM customization story was so called “out-of-the-box” system, yet fully customizable. Most of these systems were born as a modification of “a toolkit”-oriented implementations and providing their configuration tuned with a specific parameters and data schema. In my view, it was a beginning of “PLM industrialization” bubble. When systems still provided all options to be flexible configured and customized, the marketing story always emphasized their ability to be ready-to-implementation AS IS. Unfortunately, because of a significant emphasizing of out-of-the-box, technological and  development focus shifted from innovation in providing of flexible, customizable systems towards “packaging” and selling of boxed PLM for industries.

Cloud and PLM
Customization is considered as one of the most significant risks and problems related to PDM/PLM systems in what called ASP model in the beginning and later became OnDeman/Cloud systems. I don’t think, there is a Cloud/SaaS PDM/PLM system today that can provide the same level of customization as a system-on-premise. I think, an effort need to be made to learn Salesforce.com environment and specifically their Force.com platform in order to understand the “secret sauce” of their success story.

What Is Next?
I have a feeling, we are in the middle of debates about flexibility and customization vs. out-of-the-box flavors of PLM. When it became clear, out-of-the-box systems cannot provide what customers need, industry is still continuing to promote ready-to-go solutions, industrial verticals and other sales and marketing oriented speeches. Nevertheless, I can hear strong voices to revise experience of the past 4-6 years and focus on technological development that can provide a platform for the future flexible and customization PDM/PLM system.

What is my conclusion today? Product Lifecycle Management is in the critical situation. It started as a complete customizable environment and, since 1990s moved towards out-of-the-box packages and non-customizable solution. The last happened based on the strong message about making implementation faster and cost reducing. It seems to me that out-of-the-box PLM is a marketing and sales dreams. Engineering and product development cannot be done “out-of-the-box” and even so, companies are doing similar things, their strong believe in the uniqueness and benefits of the engineering and manufacturing environments. The key word for me in PLM customization today is a granularity. To make it work is hard. How to bring it up remains a completely technical topic.

Just my thoughts…
Best, Oleg

13 Comments | Daily PLM Think Tank, PLM Basics, PLM Implementation, Technology | Tagged: , , | Permalink
Posted by olegshilovitsky

Is PLM Customization a Data Management Titanic?

February 26, 2010

PLM implementations are not simple. At the time when PLM vendors are working how to improve their out-of-the-box product offerings, PLM customization plays a very significant role. According to the analysts, customizations and services can be estimated as about 40-50% of total revenues in PDM/PLM domain.

What is behind these numbers and why it happens? In order to understand it, I think, we need to get short round-trip in the history of Product Lifecycle Management. The roots of PLM are in the first implementations made by large aerospace, defense and automotive manufacturers. This is the birth place of PLM and origin of PLM ideas. Since then, PLM started their journey downstream by proliferating ideas, software products and implementations. I can identify the following three trends in Product Lifecycle Management these days:

Maturity of the basic product offering
The PLM core functionality came to the stable form and mostly represented by product data management, lifecycle components and additional modules related to the business process activities – requirements, program, project, services and other processes. Interesting is that PDM and Lifecycle are considered as the most mature components of these portfolios.

Industry specialization
Initially, PLM started in aero/auto domains. However, nowadays it is moving towards all industries. In order to play industry game well, PLM vendors decided to invest into industry orientation. This trend can be characterized by a wide range of options starting from industry marketing and ending by providing packaged PLM solutions for the specific industries (i.e. Apparel, CPG, Food and Beverage, etc.)

Emerging trends
I can identify two main emerging trends – SaaS / OnDemand and Open Sources. Both are focused on how to satisfy needs of customers differently utilizing new software technologies  and deployment as well as by investing in the alternative form of business models.

When PLM industry focused mostly on providing out-of-the-box functionality, I didn’t find any technological trends focused on core data management capabilities of existing and future PLM systems. This is a very bad sign, in my view. Looking backwards, I can see significant improvements that were made in PLM software by the introduction of flexible data modeling. It allowed to decrease cost of PLM implementations, but created the huge amount of today’s customizations and implementations based on existing PDM/PLM platforms.  And this is a growing conflict between customized PLM software and upgrades to the coming releases of PLM portfolios.

I found the following Develop3D’s article as a very interesting. Al Dean is writing about replacement of highly customizable instance of MatrixOne by Open Source PLM Aras. There is more information about this event on Aras website. Read it. It looks like customer made the decision in favor of Open Source because of absence of alternatives to move to the next version of out-of-the-box MatrixOne version. I want to point out on the discussion about PLM software upgrades – PLM, Cloud, SaaS and Software Upgrades. My conclusion was simple – technology and architecture matter. If PLM data management capabilities could manage the upgrade event from highly customizable solution, I doubt the customer’s decision was to dump out existing vendors. Does it mean Aras has such technology? I don’t know. However, coupled with Open Source business model it crushed existing PLM implementation.

So, what is my conclusion? My hunch is that PLM vendors forgot to invest into data management technologies. PLM data management technologies were created 10-15 years ago. Since then, industry developed huge amounts of customized implementations. I see these implementations as Titanic pushing forward… Do you think they will be able to achieve port of destination or will die in front of icebergs of upgrades? I see it as a real and dangerous problem.

Just my thoughts…
Best, Oleg

Share

29 Comments | Daily PLM Think Tank, PLM Implementation, Technology | Tagged: , , | Permalink
Posted by olegshilovitsky

Follow

Get every new post delivered to your Inbox.

Join 115 other followers