PLM and ERP: Why it doesn’t fit?

Reading Jim Brown’s blog post “Choosing an ERP to Fit PLM?”, I started to ask myself why these systems fit or don’t fit. For many organizations, I had chance to see in my professional life, PLM and ERP integration was always on the level of “love and hate” relationships. People wanted this integration to happen and on the other side discovered a lot of conflicting topics that prevented them from the ability to organize smooth fit and integration between PLM and ERP.

I’d like to figure out the list of issues that in my view prevent these systems from good fit and, actually these issues make systems from being competitive rather than work together.

1. Control of product master record. The constant question of “who owns what” is the first and most important. Both systems compete in the organization on the ability to manage product master record. This competition pattern is different in the different organization, but you can discover a presence of this “control war”.

2. Cross organizational process handling. Organizations are driven by processes. It can be the engineering change, configuration or any other processes. However, in most of the cases, these processes are rarely belonged to a single system in the enterprise. Processes are spanning across various organizational boundaries. PLM and ERP are competing on the ability to plan, build and manage these processes.

3. Enterprise Backbone. This is related to my previous post. How many enterprise backbones we need? PLM and ERP are both interested to keep the role of enterprise backbone. So, they can be very competitive in this role. If IT and engineering organization are not making right arrangement, overall organization can overspend on this a lot of internal dollars.

There is set of additional specific characteristics that we need to keep in mind from my standpoint. PLM and ERP fit is very dependent on the organization. Personal topic plays a very significant role. There are too many systems in existing enterprises. This enterprise system’s zoo, brings us to the point where integration is physically impossible or very costly.

So, what is the solution for PLM and ERP fit? Is it the next place for PLM (or may be ERP) innovation? What is the role of professional service and partner’s organization in the processes of making PLM to fit ERP or vice versa?

Best, Oleg


Share This Post

  • milt

    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

  • milt, thanks for your comment! Indeed, this is something related to “control,” and I think it comes from business owners of these systems in the company. They look like fighting for ownership of the data, process, people etc… Don’t you think so? Best, Oleg

  • 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!).

  • Hervé, Thanks for your comment! Certainly will take a look on your blog. Google translate removes language barrier… What you mentioned about EBOM and MBOM is very precise def of root cause. ERP and PLM providers are pushing functions on both side and as a result customers confused and fighting about how to implement tools.
    Best, Oleg

  • Alec Gil

    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! 🙂

  • Alec, thanks for your comment. I want to stress one point you mentioned. Processes. In order to have well defined processes that have cross-system and system-internal span, you need to have enough meta-data or just data to define and operate such processes. Most of today’s process systems that belong to specific enterprise app, use data managed by the system to organize processes. The problem starts when overall process definition needs to be done on the organizational level. This is time when the question of the data ownership and master system comes normally. Rest is driven by competition in most of the cases. Enterprise Apps sell features and lock-in data inside. As a result – those systems that have data ownership conflict and overlap cannot fit. PLM and ERP are one example. Happy Holiday! Best, Oleg

  • 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.

  • Another point that comes to mind on this topic is the idea of making your application more socialble. The facts are clear, business cuts across organizations and applications and therefore adding social features to an application does not solve a business problem and does not provide business value. I would say the enterprise social solutions is a new platform that can connect to the content of other applications making them socialble and allowing a cross enterprise and cross application approach. Imagine the case where customer service logs a customer complaint (say in Microsoft Dynamics CRM) and then works with marketing, sales and engineering to resolve the problem. Maybe sales uses CRM but most likely not the customer servie modules and certainly marketing is using nothing but emial and Office and engineering we know are using many applications and certainly not the CRM tool.

    If this use case is going to become socialble it needs an enterpirse social solution, not social features added to each application.

  • Douglas

    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.


  • Chris, Very interesting point. I think mashup can reduce the ownership problem. But, if on the fundamental level, BOM and Part Master ownership will continue to be an issue for ERP and PLM (as it happens these days), mashup will not be able to provide a good solution. How do you know what source of data to mash-up? Thanks! Oleg

  • 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

  • Douglas, Great thoughts! Thank you for your deep insight. I agree, the most interesting topic is future morphing of EBOM and MBOM in somewhat allowing 1/efficient manufacturing; 2/allowing a modular approach in product design and manufacturing. Is it about what people calling lean? I think your examples with WW2 just confirm that lean is the only way when you are in the extreme situation. Best, Oleg

  • Martijn Dullaart

    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.

  • Martijn, Thank you! Your D4x is an excellent example. Not to build multiple Bill of Materials, but to create single one for all. I’m sure you had chance to read

    Seven Rules Towards Single Bill of Materials ( and BOM: Overstructured, Understructured or Lean? ( I just see it so in place of what you said about your practice.

    Best, Oleg

  • AndyF

    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.

  • Andy, Certain system behavior driven by a functional scope. The segmentation between ERP and PLM becomes more and more problematic as soon as both systems coming to Bill of Material story from both sides (manufacturing and design). Do you have a specific tool in your mind when you are saying “system where the EBOM and MBOM can co-exist and share data elements”. Conversely, you just talking about possible service/custom development? I see an interesting contradiction between what you said and today’s trend of OOTB (Out of the Box) functionality demands in PLM world. I can imagine that customers are interested to low their expenses during implementation. However, from your perspective it locks them on a specific system (either PLM or ERP). Frankly saying, I never had chance to see out-of-the-box integration between PLM and ERP. This is something that doesn’t exist, for the moment. Best, Oleg

  • 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.


  • Krishna, Thanks for your comments and insight! I agree with you, PLM started as a “product development” oriented and never been “product information” oriented. PLM pushed towards business processes to fulfill demands on enterprise organization to sell to the C-level. In the end, organization is driven by processes and this is what PLM is trying to do. However, PLM data platforms are weak and cannot support marketing demands for PLM. As opposite, ERP built strong business foundation on top of the ability to manage financial and operational assets in the organization. Both PLM and ERP are fighting for dominance… The potential future path contains two possible options – PLM will develop stronger product data backbone to absorb ERP systems; ERP will push towards their better capabilities to manage engineering data and leave PLM systems in “design space” only. Great discussion! Best, Oleg

  • Pingback: Indies()

  • Pingback: 4 Reasons Why It Is Hard to Deliver MBOM in PLM?()

  • Pingback: 4 Reasons Why It Is Hard to Deliver MBOM in PLM? « Daily PLM Think Tank Blog()

  • 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