PLM and ERP: Why it doesn’t fit?

I think most people who work in PLM (and CAD for that matter) are afraid of ERP. Most users of PLM don’t tend to be regular ERP users so there is a fear that they will “mess something up” when they execute a process that touches the ERP system. There is also a feeling that the process leaves their control when it spans the ERP system

With a systemic perspective, PLM and ERP are two tools that helps company teams collaborating towards the delivery of a product to the customer:
– PLM helps the engineering team organizing itself to construct the definition of the product so it satisfies the needs of the customer (the product is designed to run the way the customer expects), and so it can be produced by the production teams (if the designed product cannot be produced by the company, the designed solution remains just a dream, it won’t never be delivered to the customer!)
– ERP helps the production team organizing itself to physically construct the product that has been defined by the engineering team.
Why people have some difficulties with these concurrency ? My opinion is because of the hinge between both teams, the so-called “bill-of-materials” (see previous discussions), in fact the engineering configuration of the product.
The engineering configuration, as its name suggests it, is built and maintained by the engineering teams, and exploited by the production teams, but expresses the solution to the “how-to-produce” question raised during the development activities.
On the other side, the design configuration expresses the solution to the “how-to-run” question.
The “manufacturing” flavour (“how-to-produce” means “what are the production processes, by manufacturing or/and by procurement, to make the designed product AND that my company production team can run”) lets some people think that the engineering configuration must be elaborated by manufacturing people (confusion with routing in particular). The result is that for most organizations, development and production teams fight together on the non-ending discussion about the difference between the EBOM and the MBOM, which is in fact a pure creation of software vendors, each of which is promoting the features of their software, according to the viewpoint these vendors see the collaboration hinge.

If you are interested in this argumentation, please see details on my blog (sorry, it is in french!).

Oleg, I really like your first two points. Perhaps at issue here are not the systems themselves – although greater level of integration always helps – but the organizational behaviors that allow to perpetuate the issue of “Master” ownership and control wars. The company owns data, not by a particular department, system or silo. PLM is used to create content that is relevant for this context (such as BOM), ERP uses BOM. I do not know what is the master system and I should not really care.

Which leads us to the issue of the process. You are absolutely right, most processes do cross systems and organizational boundaries, but parts of well defined processes appear to the users as components of one organic whole with no competition between the systems. The ECO process implemented at our company is one such example. ERP and PLM systems each have their purpose and relative strengths and dealing with multiple systems is a reality of every day business. What we really need is not the competition between them, but the tools that resolve their semantic differences and bring them closer together. Happy Thanksgiving! 🙂

This war would be reduced IF the tools used were WEB solutions making it easier for the business to mash together functionality that a user needs and maybe even allow the user to create thier own mashup. I also think the war has to do with the fact that there is a clear owner, ERP and PLM has been trying now for 10 plus years to wrestle some control away from ERP. The PLM fight is forcing an un-natrual approach into the mix and this is why it has struggled to gain control and gain a foot hold. Reguardless of the level of deployment PLM has in any one organization it is clear that ERP is what the business runs on.

PLM and ERP are two different tool sets for completely different processes within a (manufacturing) organisation:
PLM-tools are aimed at managing product requirements, -design and -definition data, product structures, product change management, parts classification and parts management

So PLM tools are managing the product development process and the content of “the product”.

ERP is a tool set that is aimed at managing transactions within the organisation: manufacturing, financial, logistical, etc. For this it needs to manage a set of master data and a definition many standard transaction processes.

So, ERP is about transactions, “defined once performed many times”

To be able to manage a design process, its product data and configurations, the process needs different views on the product and this means creation of different structures this is particularly important as a design process is synthesizing (creating solutions from requirements) and iterative:

First, we need to structure customer requirements and translate them into Product requirements, maening we have a Requirements Structure

Then we need to create a product concept, structured along functional lines in order to be able to validate if the concept conforms to the requirements , so we have a Functional Product Structure

Next, we create the Product Definition based on the Product Concept. Here is where the production drawings or CAD models for production are defined. It is also the process where the Engineering Bill Of materials is defined. But an EBOM is in fact just a view on the Engineering Product Structure.

Now, you would expect that a Product Definition (product drawings) created by Engineering could be used right-away by the Manufacturing organization.
This, however is not true, because in many organizations Manufacturing needs to make a translation of the Engineering Product Definition into “producible” and “outsourceable” parts, components, assemblies.

It is interesting to note that the act of creating product drawings became necessary in the past because of the division of labor between the persons creating the product design and those that manufactured the product.

Manufacturing thus creates its own product structure (MBOM) and often also content in order to be able to create a manufacturing routing, purchase parts and manage manufacturing orders. The content for example may be created in the shape of manufacturing (assembly) tooling, CAM files, Robot tasking files, Inspection and test requirements.

Because PDM in the past and currently PLM is mostly regarded as “something for Engineers”, the manufacturing structures are often stored and managed in ERP and the translation from EBOM to MBOM is done when Product definitions are released for production.

So EBOM and MBOM are by no means inventions of software vendors, on the contrary, they are part of industrial processes with a long tradition.

That it can be done in a different way, however, has been demonstrated when War production in WW2 necessitated highly modularly defined products of which manufacturing could be decentralized . When B17 and B24 bombers and Liberty ships hade to be produced in large quantities, they hed to be completely re-engineered for mass production. This meant defining, on the drawing, those monoparts, sub assemblies and assemblies that had to be subcontracted.
The result was a highly modularized Engineering Product Structure which was optimum in terms of “design for logistics”.

It seems that we forgot all about that when MRP, later ERP was developed.
My solution: Engineering should define products and product structures in such a way that they can be manufactured, technically as well as logistically.

This means the use of organizational solutions like Concurrent Engineering or Multidisciplinary Product Development Teams, techniques like DFM/DFA, Software tools that do all the required analysis and validation (like 3D Mockups) . But most importantly, it means creating a modular Product Definition and structure and providing part data which in Manufacturing Process Planning can be used right away without translations additional data can be added, though.

Douglas

Chris, Do you think ‘social’ will become a new universal hammer to resolve enterprise software problems we have today? Some of my thoughts on this in another post about “social platforms for enterprise”. I see adding of social features as an interesting approach, but in the end, social features and capabilities will migrate to sort of platforms (with few major players)…. Today I see all social features as a very nice add and right direction to make platforms more mature in the future. Best, Oleg

Oleg, Douglas. Great post. I want to come back to your “design for logistics” statement. Because I agree. At my company in one of the divisions we introduced what we called D4x (Design for “Anything”), what we mean by this is that we wanted the engineers to design the EBOM in such a way that it would represent not only the requirements from a customer and Engineer perspective, but also all requirements from Manufacturing/Logistics/Service.

Also we currently have an PDM/PLM application (custom build) that supports the Functional and product structure approach. This works really well, also for easily configuring new variants within a family of products.

The “war” between PLM and ERP is one that has been created by the software vendors. The various vendors want to grab all of the business for themselves and therefore they create code which is monolithic in nature. These large applications are designed to hold the data hostage within the application rather than sharing.
If you reject the usual solutions to PLM and ERP then you can find tools that avoid the “war”. It is possible to build a system where the EBOM and MBOM can coexist and share data elements. That actually isn’t a difficult problem to solve but you probably have to solve it yourself. If you’re buying off the shelf tools from the major software vendors then you’ll have an issue. The software vendors aren’t really interested in solving business problems, they are busy trying to lock their competitors out of the market.

A wonderful post in deed!
If geeks allow, I want to express here my thoughts,on PLM and ERP- a ill tuned love song,I put PLM more as product centric view, where as the ERP is business process centric view.These two should be separated while understanding the both.As of now there is no such solution which fulfills both the requirements, Just every S/W vendor is trying to make his mark and keeping sockets for plug ins (an extra buck from third party S/W),do these things really help manufacturers or business houses in their product Life cycle /business planning?
Have the S/W vendors really understood the PLM or just because it is buzz word as on date so lets-make-most-of it while the sun still shines?
Have the Manufactures/Engineers really understand what they want from PLM in terms of technology and management system? are they clear about it?
As of now, no one ever talked about product management after the product is sold out and is with the user/consumer
As of now PLM only refers to Product development, cost control/management of production, manage it as an asset, and disposal(if it is an internal asset) what about products that are sold to consumers/users how to manage it, how to get the data on the usage? durability,condition monitoring, disposal plans disposal compliance?

I am of the opinion that ERP should be built on the PLM Base as an extension, rather than PLM as an extension to ERP, whcih should solve all the Problems of EBOM and MBOM
I agree with the olegshilovitsky.

Regards

Hey There. I found your blog using msn. This is a really well written
article. I will be sure to bookmark it and return to read more of
your useful info. Thanks for the post. I will certainly
return.