A Red BOM Rises

theoden-BOMTensions in the larger enterprise war between Product Lifecycle Management (PLM) and Enterprise Resource Planning (ERP) appear to be on the rise, and the latest battleground is apparently waving the Master Data Management (MDM) banner. The genesis of this conflict stems from the intersection of two different visions, PLM and ERP born from opposite ends of the enterprise. To understand how we got here, check out The Multi-Headed Dragon. Remember how I told you not to taunt happy-fun multi-headed dragon? Well, Multi-Headed Dragon is cranky. Increasingly, it looks like new battle lines are being drawn on the stage of a very old war. An important question to ask: will territory finally be ceded one way or another, or is this just another episode of Bill of Material (BOM) Groundhog Day? Integrations shall be shaken! BOMs shall be splintered! Migrate now to ruin, and the world’s ending!

Engineering.com reports from the front lines including recent Gartner analysis:

“Do you manage your master data with spreadsheets? Throw them out. The analyst firm Gartner recommends that you use a Master Data Management (MDM) solution instead.

They cite good reasons for making the switch; “MDM has the most impact on things like cost and quality.” Master Data Management is a hot topic with large manufacturing companys and as a result, it is also an important development path for the PLM and ERP vendors.

In fact, it’s boling [sic] down to a “battle over ownership of the mBOM”, pitting the PLM vendors against the ERP players.”

We’ll facepalm the whole spreadsheet thing for now – of course MDM is superior. But quite frankly the very firms that are still primitively banging together Excel sheets are having equally huge difficulty sorting through the PLM, ERP, MDM alphabet soup. They will wonder why can’t there be just one (isn’t it master Data Management after all?) and will be equally disappointed to find out that such an end-to-end solution is exceptionally rare. There’s certainly to be a bit of confusion regarding MDM. Is it PLM? It is ERP? The answer is unequivocally yes. Well that’s just great. For most manufacturing companies, master data will necessarily cross both domains. And therein lies the rub – MDM in its perfect form is all about a single master – a clear source of truth. But when two or systems are competing or handing off that information, it’s not really MDM now is it? It’s more like MMDM – Multi Master Data Management. And what according to Gartner is the top reason manufacturers need MDM?

“Master data has too many masters.”

Well, crap. What can men do against such reckless hate? In a multi-master system (a federated system) information and data must migrate from one domain to another. In order to remain true to the spirit of MDM, that migration must be omnidirectional – because the product lifecycle isn’t necessarily linear. It’s reasonable to expect that data may make multiple round trips across the enterprise from department to department and function to function. That’s many potential migrations in a federated system. However, technical complexity arises in communications between systems that aren’t rigged to be the best of friends. Usually trouble occurs not when handing data down towards the end of the lifecycle, but rather when it has to backtrack. Concessions must be made because data models are not seamlessly compatible, bridges must be built and API’s maintained. With that level of complexity, no doubt mistakes are made and inconsistencies arise. The Engineering.com article highlights this fact when talking about the root causes driving errors in product data:

“Product development teams are all-too-familiar with how these errors occur given the various systems that manage the data. Generally cBOMs (configuration BOMs) and eBOMs (engineering BOMs) are created in the PLM systems, whereas mBOMs (manufacturing BOMs) and sBOMs (service BOMs) emanate from ERP or/and MES systems. But there’s no rule here. Several variants and combinations are “on the map.”

The critical point here – present hostilities over Manufacturing Bill of Material (MBOM) ownership (traditionally an ERP stronghold) does little to solve the larger MDM issue over disparate players, it only shifts the warfront. Even assuming PLM interests somehow manage to capture the MBOM, will that give them the momentum to push ERP out? Or will the momentum shift in the other direction? Certainly entrenchment is a powerful thing, and we’ve been soaking in it for a good, long time. But the problem goes well beyond entrenchment, it’s about consolidating a transaction centric model with a product centric model and neither side has the chops to storm that castle. Companies already in the MDM fray will likely continue as they are, new entrants will no doubt be a bit skeptical at all of this if not a bit confused. And so it begins.

  • Ross Bernheim

    You hit the nail on the head. ERP and PLM have different and incompatible goals. It is notable in the different access rules between the two. Accounting and materials management programs handle change from the standpoint that you cannot undo a transaction. You can enter another transaction to nullify the transaction by going in the other direction. PLM will let you undo a transaction, but documents who did it when.

    The problems are having the two databases talk to each other, but more importantly is who transfers what and when. A large portion of the problem is cultural and a lack of understanding of the whole enterprise and how what is done fits into the overall enterprise.

    My take is that BOM’s should only be generated in the PLM and transferred to ERP. Vender information can be pushed both ways, but quite often the information will be different. PLM will quite often have technical contact information and information about different divisions of the vendor while ERP will have contact information for financial purposes. PLM is not inherently concerned with price or availability or cost or inventory. PLM is concerned with specifications, data sheets, meds, RoHS, etc.

    I would be happy to only have one interface between the two programs to manually move data.

  • Pingback: Put Your PLM in the Box | E(E)()