PLM+ERP: How to Prevent a Divorce?

I’d like to start new discussion this week with this challenging topic. In my post about “Top Five Disappointing PLM Technologies” last week, I mentioned PLM/PDM -ERP integration as #2 and actually got lots of interesting comments on this. And as I mentioned, this topic, in my opinion, has remained the same for at least the last 5-10 years. So, I came to the conclusion that there is something fundamentally wrong and it will be really good to make open up a more detailed discussion on this.

So, I’d like to put the reasons that have brought us to our present situation regarding the PLM/PDM and ERP world into 4 groups:

  1. Bill of Materials Management. The way a Bill of Materials need to be managed in both systems is different. While PDM/PLM is more oriented on “work in progress”, such as the design Bill of Materials and Engineering stuff, ERP is more of an “effectivity-oriented” model. The bridge between these two models is the Part Number, but this is not always simple to coordinate between multiple manufacturing facilities and different Engineering /Design views. So, the fundamental models are different. Therefore, the connection and mutual life of these systems together is very problematic.  
  2. System and Process product supports. PDM/PLM and ERP support a different community of people (and processes) in the organization. Their work goals are unfortunately defined separately, and processes are not always well integrated. When they belong to different organizations, it’s very hard to make them work together since they are disconnected sequentially (input-output) and not designed to work in parallel. This causes major dissatisfaction and loss of interest among people, followed by #4.
  3. Concurrent Management. In many cases, people get the feeling they are working ‘on the same’ topic (BOM, Product, Part etc.). In this concurrent mode, systems (or people working with systems) are trying to establish a way to say their “final word on change”. Although the overall process spans across PLM and ERP, this process requires concurrent work.  In order to work concurrently, the integration between PLM and ERP needs to be robust.  If it is not robust enough, the process is not optimal and becomes a bad and unnatural process.
  4. People’s nature and various organizational issues. As you, probably know, in the end it’s all about people. When we have all the problems I just mentioned in #1-3, it causes people in the organization to resolve problems in the way they think will be appropriate – they do not always take organizational goals into account. They are driven by their position in organizations, organization political influence and various short and long trends. This is normally ends with organizational failure or one system dominance.

So, will the PLM/ERP marriage end in divorce or end-up as a happy partnership? What I see for a long future is happy ERP and PDM/PLM relationship, if they can find a good find way to live together. If this happens, it will provide huge advantages for customers from the standpoint of streamlining organizational processes and the ability to decrease the cost of the products they manufacture. Alternatives are very complicated and in most cases can be separated as 1/competitive dominance – one of the systems will be dominant in organization; 2/an extremely high price will be paid to integrate systems: 3/inefficient organizational processes.

I’m sure there is potential to solve this problem and that the solution can come from the technological side as well from the organizational side. I’d like to hear your voices and it will be great if you will share your experience and opinion on this problem.

Share

Share This Post

  • Chad Jackson / Aberdeen

    Oleg, I think you make some really good points here. But I’d like to add a comment.

    I think an important aspect of the issue is that the PDM/PLM system tends to act as the BOM system of record prior to design release. ERP acts as the BOM system of record post design release. Obviously post design release changes need to be coordinated with the PDM/PLM system, but I see a more fundamental problem.

    Too often, engineering sees PDM/PLM as ‘their’ system. Manufacturing (and finance) sees ERP as ‘their’ system. I think a useful mindset to follow is if you want to modify with the BOM prior to design release, then you need to engage the PDM/PLM system. Likewise, if you change the BOM post design release, well, it may start in the PDM/PLM sytem, or even run parallel in both the PDM/PLM system, but eventually the source of truth is the ERP system. Unfortunately, I think too many organizations see these systems as their own as opposed to playing a role in different phases of the product development process.

  • Hello Chad,
    Thanks for this important note. I think organizational issues and these complex dependencies between people and processes in organization brings such cumbersome situations. I think the point should be taken with regards to how to break organizational and systems silos and PLM and ERP is one of the use cases to do so. Regards, Oleg.

  • Steve Calvert

    I would tend to agree with what Chad Jackson has said above. The different groups like “Their” method for solving problems.

    And to answer your question about “How to prevent a divorce” we must first think we’re married. Our U.S. operations are fairly new with using Smarteam as our PDM system but our European operations have been using it for a while now. The problem occurs because the U.S. operations has been using Oracle as our ERP system for several years and right now they don’t see eye to eye.

    Both sides of the pond are having troubles adapting, we have some that don’t think that the CAD Library (my terminology) should be integrated with the EPR system and others across the pond that think the ERP system is secondary.

  • Hi Steve, I like your point that need to be married first (before divorce :)). You actually put additional strong point that organizational reasons are dominant when discussing PLM and ERP integration. So, in order to improve it, we need to think about organization first. Thanks for your comments! Oleg.

  • The problem with integrating PLM to ERP or other business systems is not can it be done, but EXACTLY what should be done. The vision that people have before they embark on this integration is that of synchronization. It is a problem of practical vs. impractical expectations.

    Synchronization is problematic because the PLM and ERP, as Oleg has pointed out, model the information in different ways for different purposes. The complexity of truly synchronizing systems drives the cost is so high that it is not practical.

    The frustration people have is retyping and accuracy of the transfer. The solution is to transfer information between systems as a transaction when it is appropriate for the business process. It may sound like a cop out, but sometimes the best solution is to reduce the scope to make the project practical and productive.

  • I wonder if there is a difference between the PLM systems that were developed from a CAD-centric view (e.g. SmartTeam, UGS, etc.) and those that were stand-alone PLM systems (Agile, Arena, Omnify)? My own experience (from Arena) was that the PLM systems used by our customers were viewed to be cross-functional and were developed with a mentality around getting a BOM into production and managing it through post-release ECO’s. I believe all three of the “stand-alone” vendors have spent considerable time in synchronizing BOM’s with ERP and this is less of an issue for them. I would be interested to see comments from some of these customers that have installed one of these systems with an ERP integration.

  • Rod, you made right point! business process and transfer/transformation is probably key to success. Don’t synchronize, since it doesn’t make any sense. -Best Oleg.

  • Mark, I believe there are 3 possible PLM-flavors: CAD-based, neutral and ERP based. And, yes, I see differences in approaches. In my view CAD-based are system that built from initial design-BOM conceptual balance. These systems by definition try to manage both CAD and BOM structures. The drawback is that they normally lack on support ERP model well. neutral (and you mentioned these companies) have very good BOM foundation, but in my view have lack of influence in organization. ERP-based are too influenced by ERP model. Normally have lack of ability to manage non-effectivity based BOMs and revisions on Items. I’d be interested too to hear from people involved in various implementation related to these different systems. Thanks! Oleg.

  • Alec Gil

    First, an observation. I believe the reason that PLM-ERP integrations, in general, have not succeeded is due to the inherent conflict between general purpose “off-the-shelf” technologies and business processes of a particular enterprise. Whatever constitutes “best practices” for an ERP system may be anathema for “lean design practices” of a particular company, although this same ERP system may be perfectly suitable for the company’s manufacturing and operational environment.

    So, how do we resolve this apparent contradiction? I believe there are two solutions that must work in concert: 1) create an off-the-shelf system that is flexible enough to capture organization’s process rules and 2) have enough organizational willpower to make the integration happen because, inherently, it is a good thing. Why inherently one may ask? Because BOM or Product Structure – take your pick – is principally a single, unified entity that is product, NOT system based. Yes, we need to manage configurations, effectivities, etc. and CAD/PLM systems provide good mechanics for BOM creation and ERP uses the BOM for planning, but, I believe that, to integrate successfully, we need to divorce (here is this word again 🙂 ourselves from the systems and concentrate on processes.

    In this regard, I fully agree with Oleg’s point 3. People in different organizational roles contribute to either product structures themselves or to the decision making that affect changes to the product structures. For example, engineers are obviously in charge of product changes, and they generally execute these changes in the PLM system. However, people in Operations may be in charge of effectivity because they generally have better visibility of resources, demand, availability of purchased components, etc. So, while engineers need to be able to communicate the intent to change (via an ECO that starts in a PLM system, for example), Production Control assigns effectivity in the ERP system because something in their process tells them that there is a transferred ECO that they need to react to.

    Conversely, assignement of the effectivity dates and subsequent ECO implementation in the ERP system must mean something to PLM, i.e if ECO (and the related changes) are implemented in ERP, they should also be implemented (released?) in PLM. So, certain events in one system trigger actions in the other and vice versa. All of these role based interactions must be thoroughly worked out and become parts of the PROCESS based integration. In my company, we no longer ask questions about who owns master BOMs, Items, etc. We have an integrated system (a combination of PLM and ERP) that tells all of the interested stakeholders (through the appropriate data abstractions) what to do and when.

  • Alec, thanks for your comments! I really like your position about “process” vs. BOM ownership. I think years of “divorce-war” on BOM explains why this is wrong way to go. You need to establish process that can flow between system and people in the organization. Here is my question – “How do you see these processes implemented in company”? -Regards, Oleg.

  • You can improve your business performance, facilitate new financial processes, reduce possible errors, streamline existing financial procedures and improve your data analysis. Gain a strong fiscal control over your business with SAP Business One.

  • The main reason of Error code 0X9a in Epson printers is due to wrong configuration of system files in the Windows operating system. This study manual shows you the steps to fix Epson printer error code 0x9a both automatically and manually. It also assists you to resolve some of the error messages related to the Epson error 0X9a error code that you might get.

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll