Bill of Materials (BOM): process or technology challenge?

March 3, 2014

bom-process-vs-technology

The importance of Bill of Material in product development and manufacturing hardly can be undervalued. BOM is a cornerstone of almost all processes and activities – from early requirement and design and to manufacturing, services and support. Therefore, efficient BOM management is an absolutely important element of product development processes. PLM vendors are coming with different solutions to manage BOMs. Together with vendors’ solutions, manufacturing companies are developing practices (and sometimes a complete solutions) how to manage Bill of Materials.

I’ve been discussing the idea of "single BOM" for the last few years as a possible way to simplify BOM management. My earlier post – Severn Rules towards Single BOM is almost five years back (2009) raised very interesting debates. All of them are still relevant in my view. I wanted to highlight one very insightful post by Jim Brown here. Jim speaks about different aspects and advantages of single BOM management. As part of this conversation Jim introduced a concept he called – associated BOMs. Here is the passage I specially liked:

Companies have spent a lot of time and effort making logical connections between different BOMs, and developing tools to help develop and synchronize different BOMs. For example, PLM, MPM, and Digital Manufacturing software helps companies translate an engineering BOM into a manufacturing BOM and then further into a BOP. In fact, they have gone further upstream to match conceptual BOMs and requirement structures downstream to BOMs. Maybe you would call these “workarounds” to the real answer of a single BOM. But I would propose a different view based on history and my observations. Perhaps engineers have done what we do best – addressed the problem in the most practical way as opposed to the most elegant way to solve a problem.

I think, Jim’s post is absolutely relevant today. After few years of discussions on this topic, one of my hypothesizes is that companies are not ready for single BOM solution… yet. At the same time, I do believe companies can take realistic steps into single BOM management already today. The variety of ways companies are managing bill of materials can surprise even people with lot of experience in manufacturing and PLM. After many years, I’m always surprised to find "yet another way" to manage bills, configurations and associated manufacturing and production information.

My attention was caught by Teamcenter PLM blog few weeks ago – Bill of Materials concept. Author, posted a very good summary about different types of BOMs. Together with eBOM, mBOM, sBOM and few others, it outlines the idea of Master BOM as a centerpiece of BOM Management capable to provide "single source of truth" about BOM. The following passage explains the idea:

To overcome this challenge, the concept of Master BOM has come. Master Bill of Material can be defined as single source of BOM having all aspect of information for various configuration and discipline. Hence Master BOM by definition is single source of truth for all BOM. Industry is still struggling to find the exact solution in term of defining and managing Master BOM. Also it become more complex due to the facts that different BOM types are managed in different systems. PLM vendors including Siemens PLM has come various solution and tools, but still required to show the success and maturity of managing Master BOM as a single source of truth across various BOM lifecycle and discipline.

This post and exchange of comments made me think about potential two challenges in BOM management – technology and process. The way and technology to support and implement the idea of "master BOM" is quite complicated as well as PLM implementation attempts to integrated product data under the umbrella of "single point of truth". At the same time, the idea of "master" or "single" BOM management faces multiple political challenges including discussions about internal and external company processes. In my view, modern data management technologies (especially coming from web and open source) can introduce some advantages in BOM management. It can be related to scalability of data management solutions as well as improved collaboration features. Would it be enough to overcome process challenges? This is a good question to ask these days.

What is my conclusion? After decades of development in PDM, PLM and ERP, companies are still struggling with BOM management. The topic is quite complicated and introduce many technological and process challenges for companies. Future pressure around competition, customization and cost can bring BOM management challenges back. It will be interesting to see what (technology or processes) improvement will allow to unblock future of BOM management? No specific conclusion. Just thoughts today…

Best, Oleg


The Ugly Truth of Multi-BOM Management

December 18, 2013

multiple-bom-ugly-truth

Bill of Material (BOM) management is always fascinating topic. It sparks so many debates and introduce a large set of diverse opinions. I can even say that I have a special passion to speak about BOM on my blog. If you want to catch up on my recent posts about BOM, you can try these few links – Will PLM manage enterprise BOM? and Will SaaS and Open API solve BOM management problems? My special passion is "single BOM". I started this conversation few years ago. Here is my last writeup about single BOM- Single BOM in 6 steps.

Few days ago, my attention was caught by PLM dojo article about pros and cons is Multiple BOM management – Why You Should (or Shouldn’t) use Multiple BOMs. I highly recommend you to have a read the article including comments (the number is growing). It brings an interesting set of strategies relasted to BOM management. From my side, I can clearly see advantages of both approaches. And I can generally say it depends on many factors – industry, product, organization, processes and… (what is not less important) people. Here is my favorite passage:

Sometimes it makes sense for the CAD user to organize the design differently than how ERP organizes the data. For example, it might make sense to group a large assembly model into sub-assemblies that don’t represent any actual part, but make it easier to divide up work on the overall structure. A related reason is that having the part BOM separate from the CAD BOM isolates the part BOM from the inevitable messiness of the CAD files.

While there is nothing wrong in division and separation of CAD design and Part structures, I still believe there is a trick here. Thinking about that, took me back to the post I wrote few years ago – The Ugly Truth About PLM-ERP Monkey Volleyball The controlling of data is one of the fundamental enterprise software behavior and strategy. One of the "negative" aspects of single BOM strategies is the need (and complexity) to share responsibilities and control over the shared "single BOM". It can create lots of organizational constraints, especially if departments and/or divisions are using multiple systems.

At the same time, Single BOM containing multiple dimensions of product information can become a place to share data among organization and optimize processes. However, in order to make it happen organization will have to agree how to manage "shared space", and shared responsibilities. People management becomes a critical function to make it successful.

What is my conclusion? Technology is easy part, but people are really hard. This is one of my favorite quotes. The ugly truth of BOM management is the fact it requires people management and agreement across organization. Multiple BOM can be done using separation and data island controlling. Very often you can hear about technological challenges of single BOM organization. Much rare situation is when organization is moving to people and organizational constraints. People’s ego and organizational issues are often playing a key role in decision to go with one of BOM management strategies. Just my thoughts…

Best, Oleg


Will SaaS and Open API solve BOM Management problem?

September 27, 2013

where-is-my-bom

I like the way BOM discussion usually sparks. From my experience, "BOM management" topic has the ability to ignite conversation almost immediately. Therefore, I wasn’t too much surprised when I got blog attention from Hardi Meybaum, CEO of GrabCADmost buzzed about company in Boston if you trust Venturefizz. Here is the article – Why single BOM is not the answer for you. Read it and draw your own conclusion. My favorite passage is the one that explains "BOM problem":

Recent posts on bill of materials (BOM) like Oleg’s ‘Will PLM Manage Enterprise BOM,’ make me [Hardi] remember my first conversation about BOM management. It was when I was in charge of IT in a mid-size manufacturing company. Then, and now, Procurement Specialists said that BOM should live in ERP, Engineering Managers said it should live in PLM, Engineers said that it should live in spreadsheets, and PLM vendors said it should live in PLM. This is where today’s BOM problems start.

According to Hardi, BOM management problem will disappear because of SaaS and API availability. He promotes open exchange of data between GrabCAD and other SaaS applications and out-of-the-box integration. It will finally make right information available to everyone in an organization. From what I can see, GrabCAD’s believe that companies will move from integrated large product suites into lean and granular applications. Actually, I like the idea very much. Granularity is a very good thing. Two years ago, Chad Jackson addressed granularity on his Lifecycle Insight blog -Point Solutions, Integrated Solutions and the Granularity Value Proposition. This is how Chad explains the granularity:

The fundamental idea is that you layer on different solutions that each do something very specific and well. Basically it is the point solution approach but from an ecosystem perspective. It would include something like leaving your workgroup PDM software in place. Layer on top of that a workflow. Then add some social computing solution for collaboration. Then you can add in a project management solution. You get the idea. Leave what you have in place. Add in other point solutions where needed. And integrate them as lightly as you can.

Granularity and best-of-breed application set usually comes with two additional price tickets – IT/setup and integration.I can see an interesting and new perspective in the way Hardi presents the advantage of granular solution. It comes together with SaaS, which makes a lot of sense to me. Installation, setup, updates – all these things will go away with SaaS approach. However, I have a doubt about integration. Out of the box integration is a tricky part. I never seen it works well. If you want to create a custom integration, you eventually coming down to nuts and bolts. API plays an important role in the ability of systems to be integrated. I mentioned the importance of Web APIs in PLM last year – Why PLM Need To Lean Web APIs? Even if APIs are available, integration is an expensive thing. From that standpoint, it doesn’t really matter if your PLM and ERP systems are running as SaaS applications or installed in you datacenter. My hunch, traditional RDBMS technologies allows more options to build hardwired integration compared to multi-tenant cloud applications. BOM implementations are complex and required lots of business rules to be implemented to synchronize multiple bill of materials. This is pure integration question and hardly can be handled as custom-made work.

What is my conclusion? SaaS is a game changer in terms of how systems can be deployed and maintained. It creates a completely different view on IT spending and TCO. It is also creates a different perspective of openness and importance of APIs. It was easy to hack ERP or PLM RDBMS with direct SQL call to solve your integration needs. It is completely different for SaaS apps. You cannot do integrations without custom code or flexible integration frameworks and middleware. In my view, the real BOM management problem is not related to the fact your system runs on the cloud or on premise. It is about how to connect multiple BOMs into a single meaningful solution. This task is complex and cost money. Cloud is an excellent foundation to simplify solution available and making information easy accessible. Will it solve BOM management problems across organizational silos. I’m not sure about that. Just my thoughts. What is your take?

Best, Oleg


Will PLM manage enterprise BOM?

August 26, 2013

Bill of Materials is a huge topic. It is hard to underestimate the importance of BOM management in general as well as specifically for PLM systems. I’ve been blogging about BOM many times. Use this custom Google search to browse my previous beyond PLM articles about BOM.

One of the topics I’m debating already long time is so called "single BOM". I explained my early view on a problem of a single BOM back in 2009 in my post – Seven Rules Towards Single Bill of Materials. Despite most of people you talk to would agree with the idea, the implementation of single BOM in modern enterprise is complicated and challenging. Take a look on another post to get a glimpse of what I’m talking about – Why companies are not ready for single BOM? One of the biggest problem towards achieving of single BOM idea is integration challenges. Today, BOM data resides in many systems in enterprise. Each of these systems provides a specific functional view on BOM management – design, engineering, supply chain, manufacturing, finance, etc. However, the integration of these systems is a very complicated task. In addition to that, the attitude of vendors to lock data to improve the competitiveness of their systems applies additional integration and communication difficulties.

Manufacturing companies have many challenges these days. BOM management is one of them. Despite the fact of complexity of single BOM management strategies, businesses need to have a holistic view of bill of materials. I touched it in my 3 modern BOM management challenges blog post – lean manufacturing, heavy customization, supply and contract manufacturing.

In my view, the problem of BOM management is well understood by industry. I stumble upon one of the old Siemens PLM blog posts written by Nick Pakvasa – BOM Challenges in Automotive Industry. In addition to (obvious) recommendation to use TeamCenter as for enterprise BOM management, article nails down the problem of single BOM. Here is my favorite passage:

The requirement to get the BOM under control at the enterprise level is reaching a critical stage. Exponential increase in software content is driving the requirement to eliminate legacy BOM applications that were structured purely to support older product architectures which were predominantly based on mechanical parts, to an environment that has to deliver integrated BOM management capability for all content in the product. And, to deliver this capability with lifecycle BOM management needs incorporated into the application, and to manage this BOM data starting in the Product Planning phase, through designing, building, selling, servicing and retiring the product. Without integrated enterprise level BOM management supporting all functional areas, geographical locations and external suppliers, partners and joint ventures, actions such as traceability of quality and other imperatives, reuse, BOM access for Service, and lifecycle enterprise change management are either cumbersome, with redundant or non-value added effort, and potential for errors, or in some cases, cannot be executed.

What is my conclusion? The recommendation of all PLM vendors is to use PLM as a central system to manage all BOMs. The recommendation is obvious. However, my hunch is that problem is bigger than it presented by PLM companies and other vendors developing systems producing and requesting data about of BOMs. The complexity of integration, implementation legacy and variety of requirements are creating a very complex application space to manage. In addition to that, high level of competition together with political influence inside of every manufacturing company, make the decision about BOM management one of the most complicated in modern enterprise systems. Just my thoughts…

Best, Oleg


PLM, Bill of Materials and Silo Syndrome

April 26, 2013

PLM-info-silos.png

Are you familiar with term “silo”. When it comes to enterprises and large organizations, we often can hear about different silos of information. Here is the definition of information silo as it appears in Wikipedia.

An information silo is a management system incapable of reciprocal operation with other, related information systems. For example, a bank’s management system is considered a silo if it cannot exchange information with other related systems within its own organization, or with the management systems of its customers, vendors, or business partners. “Information silo” is a pejorativeexpression that is useful for describing the absence of operational reciprocity. In Information Technology, the absence of operational reciprocity is between disparate systems also commonly referred to as disparate data systems. Derived variants are “silo thinking”, “silo vision”, and “silo mentality”.

Very often, you can hear about “information silos” in a very negative context. Here are typical reasons why silos are bad – productivity killer, bad information transparency, etc. Recently published by PR Newswire article defines a new term called silo syndrome. Navigate to the following link to read Thousands of Companies Diagnosed with Dreaded ‘Silo Syndrome’. Article defines list of so called “silo syndrome symptoms”:

- An inability to immediately access business information
- Searching for answers but never really finding them
- Problems processing terms like “unstructured content”
- A penchant to unnecessarily flatten relational data
- Inability to join concepts together in real-time
- Needlessly accessing multiple systems for “what” and “why” answers

PLM propaganda very often use the value of PLM in overcoming the problem of organizational silos. Here is one of many marketing examples of PLM value connected to org silos coming from Oracle Agile PLM article on IT Toolbox article.

PLM by definition is concerned with tracking and controlling product-related business processes that span multiple departments across an extended period of time. Each of these departments may utilize differing systems. Tracking a products lifecycle will often present the need to gather and share information with ERP, CRM, inventory, manufacturing, supply chain, logistics and other systems. While some off the shelf integration may be available, current PLM users often find themselves faced with a frustrating level of manual re-entry or poor visibility of information and processes trapped in so-called silos. Overcoming these integration challenges can mean that an organization is liberated to find the true value of PLM: more innovative, market-responsive products, faster-time-to-market, faster time-to-volume, more efficient change management, better customer care, and superior obsolescence strategies. These benefits can be achieved by both process and discrete manufacturers.

The reality of PLM and silos are difficult. The main place where PLM is facing organizational silos is Bill of Materials (BOM) management. For manufacturing organizations, to create and manintain multiple Bill of Materials is a straightforward way to split responsibilities and control. Requirements, Engineering, Manufacturing, Sales, Support, Supply… you name it. Every department and organization is requesting to have “my BOM”, which will allow them to control and manage the information in the way they want. The real challenge come after when people demand PLM system to take care of multiple BOMs and information transformation between these BOM-silos.

What is my conclusion? Today, PLM has a limited success in eliminating organizational silos by introducing support for multiple Bill of Materials. In many situations PLM is not eliminating the needs to re-creating information. The demand of customers is to have sophisticated BOM management tools that allows to maintain multiple BOM silos in organization. In practice, manufacturing organizations are not interested to eliminate BOM silos. People want to keep information silos, but have PLM system that can help them to manage silos. Result is skyrockeing complexity of the PLM systems and implementation. So, do we need to preserve silos? It is a good question you can ask before approaching you next PLM BOM implementation. What is your take? Speak up.

Best, Oleg


BOM 101: 5 “Don’ts” for Bill of Materials Management

January 21, 2013

BOM is fascinating. After posting 3 Modern BOM Management Challenges a week ago, I keep getting back to Bill of Materials management topic. If you missed my previous BOM 101 posts, here are links to get up to speed: BOM 101- The four pillars of every BOM management solution, BOM 101- How to optimize Bil of Materials. You can also take a look on this post as well – Single BOM in 6 steps. Today, I’d like to take a bit different angle by stating my 5 top most important "don’ts" you need to follow when designing and implementing bill of materials solution in your company. These topics are not necessarily reflecting PLM system. You can face the same problems when implementing BOM solutions using Excel spreadsheets, homegrown DIY data management and large ERP solution.

1. Don’t use significant numbers for Part Numbers – Use Classification

The discussion about "significant" vs. "non-significant" part numbers is probably endless. If you are new in this discussion (or just came out of computer science college), a significant Part Number looks like this 60-44-FN400587-60-NM-40-DWG-CHI. The information in this number is coded and different groups of this number are representing different meaning. Is there something wrong here? No, it is absolutely fine to have significant part number. Even more, if you are still using Excel spreadsheets or legacy data management system, this is probably the only way you can do it. However, it is complicated and eventually will lead you to mistakes. These days, most of PLM systems will provide you with the easy way to use insignificant part numbers. One of the features of good data management system is advanced classification mechanism. Such type of mechanism will help you to define all meaningful terms and characteristics of your Parts, Assemblies and Materials.

2. Don’t use supplier’s part number – use your own Item Master number

When working with suppliers, you may decide to use supplier’s part numbering schema. Especially if you are small company, it sounds very reasonable and it can simplify the communication with suppliers. However, this is a wrong thing to do, in my view. Again, PDM / PLM system maintaining item master record with cross-reference mechanism between parts and supplier part numbers can easy solve this problem and simplify your life in the future. What will happen with your system and processes if supplier will decide to change their number schema one day? it will be probably a very complicated day for you. So, use your own item master numbering schema and don’t rely on suppliers.

3. Don’t use the same ID for Part Numbers and Drawing Numbers

This is another question often asked during implementations. To use the same number for items and for drawings as well as process sheets, specification documents, etc. Initially sounds like something that could be simple enough to support and manage, can potentially lead to significant complexity and limitation in managing of change processes. The same drawing can be used for different part numbers. At the same time, changes of part numbers related to materials, stock, etc. won’t require drawing changes. Keep separate numbers and manage relationships between them is a good data management practice to follow.

4. Don’t be afraid to use extra part numbers

Identification is a very important mechanism. Sometimes, the assembly process is quite complicated and requires some temporarily pre assembled elements of the equipment to be maintained separately. In addition, you might have materials such as service parts, replacements, process result chemicals, etc. Bottom line – you don’t want materials in your bill to fly without identification. Everything needs to be included into the bill. Today’s data management systems are powerful enough to manage "extra Part Numbers" to identify everything you need in your bill.

5. Don’t put Bill of Materials on the drawings

Another topic coming from historical usage of paper drawing. In the past, it was the only way to share information. Obvious decision back that days was to put Bill of Materials on the drawing list. In modern digital life, such practice can create a lot of complications and additional procedures (such as updates of drawing when only part list will be changed). The good practice today is to keep cross reference links between drawings and bill of materials. It will allow you to manage your changes process efficiently and optimize your and your company time.

What is my conclusion? Control and efficiency. These are two important words to remember when you deal with Parts, BOMs and Documents. Many processes in this space were developed in the past and can trail lots of complexity if you not update them to "digital era". To streamline processes and make change management simple are important goals to following when creating the foundation of your BOM management solutions. Just my thoughts. I’m sure missed some issues and useful tips. Speak your mind and share your experience….

Best, Oleg


Single Bill of Materials in 6 Steps

January 16, 2013

Last week I started the discussion about about modern BOM challenges. That discussion made me think more about the idea of unified and consistent Bill of Materials that can be shared across the company (single BOM). In my view, this is a clear paradigm shift from what we know today as "multiple BOMs". How to move from well-known multiple BOM paradigm to single BOM? If you are PLM manager, IT or implementation service company, you need to be prepared for the discussion that will involve all organizational stakeholders. In the post, I’m trying to identify steps in this discussion. I identified 6 steps – structure, part numbers, extensions, end items, ECO and BOM sharing with some comments.

1. Structure: Phantoms, Modularization, Planning Bills

The "beauty" of multiple BOM strategy is in segmentation. In your silo, you decide how to organize Bill of Material. Historically it gave a lot of advantages. By trying to combine it together, you can face discussions about how to create BOM compartment to fill a particular process and/or organization needs.

2. Part Numbering

One of the fundamental conversation about BOM is related to Part Numbers. In the past, discussion about part numbering schema raised lots of controversy. Many companies historically tied to using so-called intelligent part numbers. Be prepared to switch towards something more easy and straightforward. The process of Part Number assignment is also very important.

3. Specific extensions to the BOM

Each company has their own little secrets about what to add/exclude items to BOM. In most of the companies, this is a place that will be very hard to transform. The discussion about adding "nuts and bolts" as well as some other specific materials to BOMs can be endless. Be prepared.

4. End items

Large amount of end items can make your BOM strategy very cumbersome. The sales and business people need to take a part in this discussion. In most of the cases, you can delete end items and switch to the strategy to use options for the same purpose.

5. How to deal with ECO?

The question of dealing with engineering changes is critical. You need to have an ability to make a change easy without restructuring of BOMs (or, at least, with a very small effort). The ability to find a way to present ECO process will be critical. Another critical process to clear is new product introduction.

6. BOM sharing

The effort to create a single BOM experience is useless if you cannot share BOM holistically in an organization. If people are not accessing the same model, the same data at the same time it will destroy the idea of a single BOM.

What is the conclusion? Depends on the nature of your business, one of these topics can become a key and showstopper for your organization to transform into the single BOM. Some of you will disagree of structures and some you will not have a system to share BOM across the organization. The multi-BOM paradigm evolved during many years as a result of fundamental organization silos. However, these days, the efficiency how organization can resolve the problem of connected cross department processes is a dominant one. BOM is a lifeblood in these cross-department processes. If you switch to a single BOM, you have an opportunity to optimize processes. Just my thoughts…

Best, Oleg


BOM 101: How to optimize Bill of Materials

January 14, 2013

Last week, I started the conversation about Bill of Materials and modern challenges. BOM is a heavy topic. Previous blog made me think about few additional things related to BOM management and I decided to share it with you too. One of the concepts I see as important in modern PLM and other enterprise systems is to maintain the idea and implementation of single BOM. For many years, I’ve seen multiple-BOM concept as one of the fundamental ideas to implement BOM management in many enterprise systems – PDM, PLM, MRP, ERP, etc. However, I believe, we need to start revising BOM management systems towards usage of one consistent BOM.

Function oriented BOM

The simple definition of BOM is not functional. The wikipedia article about BOM defines it a list of raw materials, parts, components and sub-assemblies required to build a product. In my view, you can see many BOMs in organizations reflecting "product structure" as a main driving behind how BOM organized. As a result of this, many companies are experiencing difficulties with operations and processes that involve these BOMs. Opposite to that, you should think about BOM from a functional standpoint. Form of BOM follows functions. The final form of the BOM or structure of the BOM is a reflection of what we want the BOM to do.

Wide Company Usage

Very often BOM starts in a single department. The compartmental organization logic made BOM separation very natural. When it is done, you feel pain relief, since you think it removes cross department conflicts about BOM structure. However, it is not true. It hits you back immediately when you start planning your cross functional processes. BOM needs to be structured to support the way product will be manufactured. Also important to include business view by structuring BOM around end items that imply some business view on a product you are creating.

Part numbers and Documentation

Don’t mess with these two main groups of identification parameters. Don’t try to combine them. Build BOM around part numbers and think about how to simplify the relationships between Parts and Drawings. The complexity of these relationships will make your future change process messy and complicated. Traditionally, BOM ends up in the drawing sheet. It was in the past. With massive adoption of 3D CAD systems and computer automation, you can re-think it. Managing part numbers is a separate topic that I will address in another post.

Modules and Flattening

Use grouping techniques to create part of BOM that can be easy handled and replaced. Use logically combined parts that belongs to specific configurations. It will help you to simplify your ordering system. Modern tools allows you to deal with hierarchies much easier. However, think twice before you introduce an additional level in BOM hierarchy. Flat BOM is much easy to handle. It is very important to create a BOM structure that allows you to run change processes as easy as possible. Analyze your change processes upfront.

What is my conclusion? The simplicity is an ultimate sophistication. It is very easy to create a complex, hierarchical BOM structure trailing all 3D CAD structures as well as engineering structures. However, to make a simple BOM that can be used by all department is not a simple task. Think bottom up – first about function of your BOM in terms of what you are manufacturing, second about change processes and only after about BOM structure (form). Just my thoughts…

Best, Oleg

Image courtesy of [just2shutter] / FreeDigitalPhotos.net


BOM and CAD-PDM-PLM-ERP Integration Challenges

November 3, 2011

I want to talk about Bill of Material and integration today. The reason why I’m coming to this topic is largely because I have a feeling "integration" will play a significant role in the future of product lifecycle management and enterprise systems in general. Two days ago, I’ve been writing about two approaches "unification" and "integration" in PLM. One of the main reasons why, I think, CAD/PLM companies decided to focus on "unification" is a struggle with integration. Time ago it started from integration between CAD and PDM. Since then, multiple other topics were added to the story of integration between multiple systems. So, one of the objectives companies put in front of them investing into unification was to simplify deployment of integrated systems.

BOM and Integrations

What I learned from multiple integration projects I’ve been involved for the last 10 years? Bill of Materials is the central piece of every integration story. The majority of integration topics are around how to handle BOM during all scenarios. The processes and implementation practices related to Bill of Materials are impacting in a significant way how a company will operate multiple systems (CAD, PDM, PLM, ERP).

Interesting enough, Bill of Material is also a centerpiece of all battles around how manage product data in various forms in multiple systems. It comes in a form of BOM synchronization between systems, definition of multiple BOM views, Product representations and many others. After thinking about possible integration scenarios, I’d like to come with three main challenges that exist in most of the integration projects (in most of the cases regardless on what systems are involved) – BOM Transfer, Item Data Synchronization and Single Bill of Material representation.

Integration Challenges

Challenge 1: BOM Transfer

This is a very complicated topic. Bill of Materials are everywhere. Drawings, CAD Systems, Engineering databases, ERP and Manufacturing systems. Even sales configurations requires a certain representation of BOM. The top waste, people want to eliminate is a need to entering information manually from one system to another system. Therefore, to automate the transfer is No.1 priority for many integration projects. However, it requires mapping of data and a lot of "hand-wiring".

Challenge 2: How to keep Item Data in Sync

Item information (or how ERP-related people saying Item Master) is a second important topic for the integration. In most of the companies, it is originated and maintained by ERP/MRP systems. However, when company is moving more towards cross-functional processes, the need to have item master information replicated and, sometime originated outside of ERP system, is growing.

Challenge 3: Where is my single BOM?

This is of the most challenging topic. Lots of companies are spending tons of time trying to decide how to maintain different flavors of BOMs in multiple systems, how to synchronize it and how to define what is the "ultimate single BOM". Some of the companies are taking a different approach and starting to manage so called "multiple BOM". Time ago, I spent some time discussing these topics. Read the following two blog post I published before: Is it a time for synchronized BOM? and Non-linear BOM perspective. Companies are spending lots of resources trying to find what is the right BOM management strategy. Lots of tools (including customized tools) are focusing on how to maintain bill of materials handling across multiple representations (aka systems).

What is my conclusion? BOM is a centerpiece of everything. You may lose control of 3D drawings’ versions and do everything in 2D. You can maintain change tracking manually. You may decide not to manage requirements. However, in my view, you cannot lose the control of items and bill of materials. As the number of systems involved into this process is growing, the complexity of keeping BOM under control becomes and more complicated. Many companies are avoiding management of Bill of Materials in multiple systems just because of this reason. As, one of my readers mentioned earlier this week – "you rarely can satisfy all your needs with a single system". So, I’m expecting more "integration challenges" in coming years from implementing CAD, PDM, PLM, ERP in various flavors and combinations. Just my thoughts…

Best, Oleg


Not-Linear BOM Perspectives

September 2, 2010

Summer is finally over. This is a good reason to stop talking about fancy social software and cool Apple’s features. Let’s move back to the core of design, engineering and manufacturing. Yes, I’d like to talk about Bill of Materials. The following blog article drove my attention earlier this week – BOM: An ENOVIA V6 Perspective. Vik Paranjpe of Razorleaf is discussing details about V6 BOM specifics. I found his initial passage very interesting:

By now companies have accepted the reality that product creation is not a linear task going from Design department to manufacturing and beyond. All the departments (including Design, Development, Quality, and Manufacturing) provide input to the product development process, e.g. Quality might have an opinion on the types of components to be used which in turn will impact the design being produced. This increases the need for a centralized BOM management solution that provides a single source of truth for the bill of materials with different “views” of the BOM for each department.

What I specially like is a definition of product creation as “not linear task“. It fits my perspective on the need to consolidate Bill of Material management effort. My last take on this was about a year ago in my post – Seven Rules Towards Single Bill of Materials. Since then, I had a chance to discuss a concept of Bill of Material consolidation with customers and experts. I think, companies need to make an effort in consolidating their Bill of Materials related tasks. However, the software available today on the market contains multiple gaps that can make implementation very complicated.

Single BOM vs. Multiple BOMs
This is one of the key questions people is asking when trying to analyze the capability of BOM Tools. In my view, this question is very misleading. The real question should be related to the ability of software to handle the complexity of tasks related to product structure modeling for all users in the organization. Designers, Engineers, Manufacturing planners and all other relevant people need to have an ability to access the product structure and BOM Information.

Automatic vs. Manual
I can see a “not-linear” product creation as the ability of Bill of Material tools to handle multiple synchronization and change steps related to performing various tasks in design, engineering and manufacturing planning. BOM provides you with the ability to consolidate it. One of the usual mistakes is trying to provide a fully automated process of Bill Material synchronization rules. The appropriated balance of automatic and manual tasks is absolutely important to make BOM tool fit the needs.

BOM Tools – Devil in Details
In order to perform BOM-related tasks successfully, BOM software needs to provide a diverse set of tools. The granularity of these tools is a key, in my view. You need to be able to perform a variety of BOM slice&dice, changes and reviews. The usability and availability of rich set of functions is the key.

What is my conclusion? Despite a long history, Bill of Material management is a still very challenging task. PDM/PLM vendors are working for decades to provide improved software modules to satisfy user demands. Each time, we see new modules and approaches in Bill of Material management. Lately, I can see a trend to provide better vertical integration in PLM tools. BOM management is a central part of this vertical integration. However, implementation of complex PLM suites is an expensive task. A good question could be what is the potential alternative of vertical integration?

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 217 other followers