Build a better BOM using PLM and what not to say in an airport

Tweet

 

During a recent business trip, I was sitting in an airport café with some colleagues while discussing how to build and manage BOMs.  We got some strange looks.  Then I mentioned something about exploding the BOM.  More strange looks.  Nervous glances.  Finally, we decided it was best to avoid using the B word in airports.  But since you probably know a thing or two about BOMs and PLM (otherwise, uh,  why are you reading this?), I'll assume you know what I'm talking about and I can use my normal Nerd-speak of PLM acronyms.  (My nickname around the office is "Big Nerd", because I'm six foot four and I think BOMs are interesting).

As a nerd, I'd like to write a 200 page essay about BOMs in PLM, but the marketing folks tell me that I'm really not that interesting and even interesting blogs should only be a few hundred words longs.  So let me start by making a few provocative statements, and then I'll try to cover just one of them briefly and save the rest for future articles, at which time I expect to have legions of devoted readers hanging on my every word.

Do you disagree with any of the following?

• BOM management should be a key foundational element of any PLM/QMS system (for companies that do discrete manufacturing, and not just processes manufacturing) .
• Parts and BOMs should be mastered and change controlled in PLM, not ERP.  PLM should be the "boss" of the BOM, not ERP.
• Don't waste your time worrying about engineering BOMs (EBOMs) or CAD BOMs unless your PLM system can manage complete manufacturing BOMs, including plant-specific variations, item level effective dates, and automated integration to your ERP system(s).
• If possible, implement BOM management during the very first phase of your PLM roadmap, or else you'll reduce your ROI and increase your risk of failure.

Today I'll focus on just the first topic:

Unless you want a wimpy PLM system, get serious about managing your BOMs in PLM

The BOM is perhaps the single most important structural element that helps tie together the various pieces of your product and quality data into an intelligent web of information.   Sure, you can do a basic PLM system that has document management and change control, without having the actual BOM structures in PLM.  You can do project management.  You can manage your DHFs (Design History Files for you non-nerds - come on, keep up with me now), and you can implement various quality management capabilities like NCR (Non Conformance Reports - do I have to spell out everything), Complaints, Regulatory Submissions/eMDR,  and CAPA .  You can do Supplier Collaboration, Requirements Management, Audit Management, Validations Management and Training Management.  Plus a whole lot more.  These are all key pieces of a mature and integrated PLM/QMS system.  And it would be reasonable for you to pick any one or more of these capabilities as the starting place of your PLM journey.  But without parts and BOMs as foundational elements, all of these other PLM capabilities are vastly less powerful.

As a sarcastic colleague once said to me: "The last time I checked, our customers make Parts, not CAPAs".    Obviously you need to manage CAPAs, but what's the purpose of a CAPA or any other PLM/QMS capability?  Answer: To help you make parts - to help you define, build and support world class products that are safe, effective, and profitable.  And for that, you need BOMs.

Let me give some examples.

DMR Management - The only sane way to manage your Device Master Records is to structure them around your manufacturing BOMs (notice I didn't say engineering BOMs - more about that another day).  Documents are linked to parts, which in turn are linked to other parts via the BOM.  The DMR for any given product is just an exploded view of the BOM that includes all the document links.  This enables the DMR to be kept up to date automatically as BOM changes are made - it reduces errors and omissions while decreasing tedious manual effort to create and maintain the DMR.

Change Impact Assessment  - Without complete DMR structures in PLM, you cannot do proper "where used" analysis.  If you manage documents in one system and parts and BOMs in another system, how can you do a full Where Used on a document?  You can't.  Without proper change impact assessment, you dramatically increase the risk that a change made to a part or document can have unintended negative consequences.

Quality Issue Impact Assessment - In a mature PLM/QMS system, you want all of your quality issues (CAPAs, Complaints, NCRs, etc.) linked to all of your product data (Parts, BOMs, Documents, ECOs, DHFs, Requirements, Risk Analysis, Suppliers,  etc.).  With all of these linkages, you can more easily determine the root causes of issues, understand which parts, processes and suppliers are affected, and determine the best course of action to address and pro-actively prevent quality issues.  Here is an illustration of just a small subset of the types of data and process interactions in a mature PLM system:

BOM Change Management - Many companies use PLM to control creation and changes to ERP parts and BOMs, but don't actually store the parts and BOMs as objects and relationships in the PLM database.  I could write a book about all the reasons this is a sub-optimal approach, but let me focus on just three:  tedious, error-prone and non-compliant.  I have done at least a half dozen data migration projects that have uncovered severe data quality issues related to discrepancies between what was approved in PLM and what actually exists in ERP:  BOMs with obsolete parts, BOMs with part numbers for which the documentation is out of date, and huge discrepancies between what people think the BOM is (according to documents stored in PLM) and what the BOM actually is in ERP.  Not to mention changes made to critical ERP data without using the proper change control procedures (i.e. non-compliance).

Single Version of the Truth - How many different versions of a BOM does your company have?  BOMs on drawings (Engineering Parts List).  BOMs in spreadsheets. BOMs in CAD models.  DMRs,  EBOMs, MBOMs and XBOMs,  oh my!  The only logical place to put the single version of the truth (including different views of the BOM) is in the system responsible for change control - PLM.

OK, I'm way past my word limit.  Thanks for staying with me.  I'd like to know what you think and I'm looking forward to expanding more on these topics in future blogs.

So long for now,

Big Nerd