PLM vs. ERP: Weird or Different?

Discussion started last week with Jim Brown got me think more about ERP and PLM. I have to say, this is not a new topic, but thinking about it, I’m always finding new angles to see differences between ERP and PLM viewpoints. I want to make some breakdown on how things different in both systems, but before, I’d like to suggest you to watch the following video from TED.

Identification: Documents, Parts, Item Masters

When you think about identification systems, you can clearly see that PLM and ERP starts from different foundations. PLM (especially systems that got founded around CAD) think first about Documents and related Parts. Even for systems that taking Item centric approach, definition of Item is pretty much similar to Document. On the opposite side, ERP is all about Item Master, Bill of Materials and Dates (!). Everything starts and ends with “The Date”. Without the assumption about what date you are talking about, you won’t be able to get anything done in ERP.

Versions vs. Effectivitiy

The main identification mechanism in PLM systems is a version. Documents, Parts have versions on it. This is how work-in-progress environment works. Whatever you change, you put version on it. On the opposite side, everything is effectivity oriented. You have a date on everything you are going to change. This date will show when it is effective. It is pretty complicated to combine these two opposite sides to work together.

Changes

This is last in top three core different fundamentals of PLM and ERP, but for sure not least. When you think about changes in CAD and PLM, you can be pretty flexible. You can always get new version of almost everything you are doing. World of PLM structured information comply with your will to change, and you are getting to the next level. The previous one easy becomes obsolete. The life is absolutely different on ERP side of the world – everything you want to change – think dates. Your manufacturing system is up-to-date to manufacturing life. All your change may and will impact manufacturing production systems. All processes are formal, requires ECN/ECOs, signatures, confirmation, etc.

So, Where we can go from here?

These bits and bytes are, in my view, fundamentals of differences between two worlds of PLM and ERP. On the upper levels, buzzwords of execution and innovation are flying, but here inside Bill of Materials, Parts and Items are struggling to live together and magically represents the same product company is doing business on. I think it is very logical that everything PLM people like to see as normal, seems different (or weird) on ERP side. Opposite is also true. Now, my question is how to balance this system? There are few possible ways, and I will try to analyze them.

Data Exchange

This is the old and straightforward way to do PLM/ERP business. If you’re familiar with “drop over the wall” approach – here you go. Just drop Bill of Material from PLM to ERP and forget. But, I’m not sure this is the most efficient one.

Process Orchestration

The most complicated. You don’t care about data first – you think the process wise. This is the right way to do business in the organization. However, compare to the construction industry, if you build you house on the badly prepared foundation (enterprise data) you are in the high accident zone.

Mashups

This is the potential alternative. This option is not developed much these days. Instead of fighting about how to own data, let’s try to focus on how to consume data in the way that users will be less worry where information resides and more focused on decision making. However, this option is still requiring a lot of investigation and research.

What is my conclusion today? It is hard to say “where PLM stops and ERP begin”. Things are getting connected, weird and unbreakable if you want to insure your organizational processes are running smooth. And this is probably less about PLM, ERP and even other systems. This is about how your organization work. And connecting it to the video you had chance to see before, think about your product and not about how it represented in different siloed systems.

So, how do you see? Does it make sense? What are your experience and view on how things need to be connected?

Best, Oleg

Share

About these ads

24 Responses to PLM vs. ERP: Weird or Different?

  1. Bhushan says:

    Hi Oleg,
    Great Post…thanks to JIM & you for the discussion.

    I look to this as ‘PLM & ERP’ rather than ‘PLM Vs ERP’.

    Both PLM & ERP have proved independently their strength in Managing Product Data & executing the process.
    For the Industries both have proved beneficial, but maintaining both of them is costly; Even if you are ready to manage them Integration Remains the Key.

    Looking from the Industry perspective; I don’t want to invest in multiple enterprise software’s. I want a single Solutions [i.e. 'Single Version of Truth'...what we usually look for].

    I would like to see one single application with both PLM & ERP features. This seems achievable – example is of SAP – Top player in ERP segment & it has SAP-PLM too.

    I think Future is in “ERP & PLM” not “ERP Vs PLM”.

    …just my thoughts.

    Regards
    -Bhushan

  2. Thanks Oleg for starting a very interesting debate.
    I believe this will answer many questions which most people keep wondering about.
    In my view there are two approaches:
    The first, bottom up approach, which can focus on how data (or content) gets generated and how effectively you can store it in structured or unstructured form so as to provide the basic entity for any informations systems like PLM, ERP, CRM and SCM.
    The second the top down approach which focuses on business processes. Organization can first decides or acknowledge(sometime they exist and people aren’t aware of it) the business process and then work out the need of data capture, workflow and reporting mechanism.
    Coming back to the only PLM and ERP, I believe these are going to expand into each others territory and fight for larger reach across the departments and supply chain networks.

  3. [...] PLM vs. ERP: Weird or Different? « Daily PLM Think Tank Blog [...]

  4. Bhushan, Thanks for your thoughts! I like your definition ERP & PLM… Actually, I even prefer ERP+PLM. I believe, that both systems collectively own separate pieces of the information that have huge value when it can be connected, stitched together. So, at this point we are in the agreement. However, I don’t see how customers today will invest in “singularity” strategy – to replace all systems they have in the organization to the “next one big system”. Do you see it as a possible scenario? In my view, what will happen in the future conversation to more granular “enterprise services?”. This is something more similar to salesforce.com. Does it make sense to you? Best, Oleg

  5. Shekhar B says:

    Oleg,

    What I have seen in implementation at various customers is that though everyone is in denial, interoperability is the truth. All these system will continue to live because they meet a specific business requirement extremely well and hence cannot be replaced by one singular system. The business process passes through various systems and at each step in the process, the interface requirement as well as business requirement are different. I think the way forward will be that Mashup system in cloud which will deliver the content as per the end user’s context and requirement.

    Let me know your views

    –shekhar

  6. Lokendra, Thank you for comments and welcome to PLM Think Tank discussion! I agree with your view on top-down and bottom up approaches. I believe both are valid, and they will co-exist for the long period of time. Bottom up approach is important to build “rock solid data foundation” for processes. Top-down is important as a way to optimize how company work. With regards to the PLM vs. ERP fight, I see it as not positive things. For the moment, I can see lots of fights about data ownership and less focus on how effectively consume data. And this is something that terrible missed in today’s enterprises. Therefore, I see technologies and approaches like “mashups” as something promising that can bring new ways to solve old problems of PLM and ERP integrations. Best, Oleg

  7. Shekhar, Thanks for comments! Mashups can be definitely the way to go. I agree, ERP, PLM and other business systems, satisfies particular business needs and hardly can be replaced by a single dream system. So, we need to prepare to co-existence of the systems rather than replacement. Best, Oleg

  8. Martijn Dullaart says:

    Hi Oleg,
    We see PLM and ERP become more and more PLM+ERP as you put it. However we still a long way to go. You already mentioned the difference in identification (btw not all PLM systems use versions, one of our homegrown PLM systems uses what we call date versions, which is basically an effectivity date) and also versions vs effectivity. So that still requires work.
    But what also is an important difference is the sequence in which changes are applied. In engineering, we just have the engineering sequence and that is usually the sequence in which changes are offered to a manufacturing environment. But in manufacturing they might not introduce the changes in the same sequence, because of cost, priority, remaining stock, ability of suppliers, etc.
    So an important step is to synchronize the differences that are created when the engineering sequence is no longer used in production. Because how do you know if your product will still work within the set quality standards, when you change the sequence of the introduction of changes in manufacturing?

  9. Martijn Dullaart says:

    I just remembered a discussion I had last week, with a colleague about differences in definition and use of data. What is an itemnumber, findnumber, position number, location id, reference designator, linenumber, etc. Some systems use the same word but have a different meaning or different words for the same thing.
    Secondly in our case we have a pdm system that can have multiple materials on one bomline (same itemnumber (findnr in SAP) and same reference designator, indicating that they are alternatives from one and another (you can pick either one). But if you send that to for instance SAP and would process it as such, it would become a different BOM. SAP would see that as if you need both materials instead of one of them. So you need to do something extra to make it understand.
    It would be nice if there was one dictionary that would already solve a lot of the confusion and would make interfacing BOM related data a lot easier.

  10. Andy says:

    I think you did a nice job of identifying the key differences between the systems. I’ve worked in this area a long time and I’ve never seen anyway to really merge the two tools. ERP is focused on steady state production and assumes that the BOM is fairly stable. Engineering PDM or PLM assumes a rapid state of change and therefore is built with a totally different command structure. You need both tools in a normal environment. The real trick is trying to figure out how to do the handoff between the tools.

    Our current approach is to focus on the fact that the information is the same between the PLM and ERP world even if the data strutures are different. For example, both systems should reference the same part when they call up part ABC. Both systems should be able to know what part ABC cost, who designed it, who the vendor is, where the drawing is, what rev level is the drawing at, what is the field failure rate, etc.

    Sad to say that today in most companies that I’m aware of the PLM system and the ERP system cannot share this level of data. Most tools are built by vendors who have a monolithic approach to the world and they refuse to share data. The software vendors want all of the revenue for themselves and are unwilling to accomodate other tools. So we have a situation where nothing works nearly as well as it could.

    It isn’t really a difficult technical problem to have multiple tools all sending data back and forth. The problem is that the vendors don’t seem to want to allow their code to be used for data sharing.

  11. Jim Brown says:

    Oleg,
    I like the way you point out that ERP needs dates. One of the biggest functions of an ERP system (I know, everybody likes to say accounting, but I will go against the trend) is balancing supply with demand. ERP is the central planning system for most manufacturers. Customer orders, purchase orders, manufacturing orders – all have dates. And getting them right is the difference between hitting/missing customer expectations. Of course, they are also the key to balancing customer expectations with the cost of carrying inventory (including the potential for obsolescence). Well said.

    Jim

  12. Jim, Thanks! I will even take it a little forward. It is always important to measure performance of any system. So, Date is the main criteria to measure performance of ERP, in my view. For PLM, I’d try to measure “match” of product and customer requirements. Now, the biggest question how to measure? In my view “social tools” can be very helpful here. I will try to blog about it separately… Best, Oleg

  13. Andy, I think you made very precise definition related to the common pieces of data between PLM and ERP. At the same time, yes, systems behave completely different from the process standpoint. Changes in PLM and ERP are taking different process routes. The problem of data sharing is simple and complex at the same time. What looks simple on the surface (send data back and forth) isn’t simple when you try to implement it. Think, as an example, about how you align data and processes in enterprise organization. It is not a simple task. Now, try to move to relationships between vendors. You are actually back to the “standard development”. And I think it was big failure. So, I see it more as a difficult technical problem with no obvious resolution, for the moment. “Integration projects” are expensive, time consuming and not repeatable. However, I do think there are some positive things too. PLM XML format is not bad. If vendors will find business more to invest into standards and exchange, it can improve the situation. It not happens today…. Thanks for your comments! Best, Oleg

  14. Martijn, You explained very well the actual semantic difference between systems. Different names and complexity of data make “integration work” cumbersome and expensive. As a result business processes stack between engineering and manufacturing. Today’s solution for very big companies is “hand-made” integration between different systems. Your idea with “one dictionary” can put a company in a very long “agreement cycle”. Not sure this is the right way to go. Have you seen companies doing such things practically? Thanks for discussion! Best, Oleg

  15. Martijn, The vision of PLM+ERP is important. However, today it looks as a dream. Those systems that work more efficiently are based completely on ERP platforms and at the same time missing points and capabilities related to product development. Mixed PLM/ERP implementations are expensive and not happens in the mainstream. The need of both systems today is obvious (before the main point was about no actual need for PLM). So, both systems need to work in their environment. To make integration cheaper from the technological standpoint can be an interesting step to see. Best, Oleg

  16. Andy says:

    Oleg, from what I’ve seen the issue gets complicated when someone demands a “single source of record”. When one system has to be the official source of record then things get sticky.

    On the other hand, the mashup concept of delivering information to the desktop for decision making is much easier to implement. In the mashup model you can grab info from multiple sources of record without disturbing the existing processes. In the mashup model the engineer gets the necessary info to design the part and everyone still gets to plug info into their existing systems.

    I don’t see any way today to integrate PLM and ERP systems in a large company other than some sort of mashup approach. Existing ERP systems such as Oracle are a joke in the PLM space, especially as you get over to PDM functions. PLM systems such as TeamCenter or Windchill can’t run a planning system or handle the financial transactions.

    About the only thing that can be implemented without spending a fortune is some sort of data mashup where information is pulled out of the big systems as needed and routed to the desktop for consumption.

  17. Andy, Thanks! What you are saying make a perfect sense to me. However, the obvious mashup’s problem (and not only for PLM, but for the enterprise in general too) is the complexity of data you need to mash-up. If you haven’t had chance to see one of my posts about that, please take a look here – http://plmtwine.com/2009/02/23/is-plm-too-complex-to-mashup/

    What do you think about that?
    Best, Oleg

  18. I agree with Lokendra. When PLM and the correct ERP are working in sync, there is better communications, leading to a ‘cleaner’ system.

  19. Catherine, Thanks for your comment and welcome to PLM Think Tank! Yes, I agree, PLM and ERP should work together. However, approaches might be different. To have them work in sync can create a situation when systems can be literally blocked. So, my preference is to have the most flexible connection between systems. Mashup, as a technological approach is the most interesting. Best, Oleg

  20. Madhusudan says:

    Hi Oleg
    Where do you place Enterprise Asset Management solutions in this paradigm. For e.g. OEMs use a PLM tool to develop power generation equipment and this equipment is in turn maintained by a power utilities with a EAM tool.

  21. Madhusudan, Thanks for commenting! In my view, Enterprise Assets Management has no clear position space. I had chance to see multiple approaches – ERP, PLM… Most of them works and hugely depends on whole environment of deployed systems. Best, Oleg

  22. [...] between PLM and ERP in this white paper reminded me one of my old posts from the last year - PLM vs. ER: Weird or Different? Even so, I discussed few very specific differentiations, in my view, it becomes less relevant in a [...]

  23. [...] between PLM and ERP in this white paper reminded me one of my old posts from the last year – PLM vs. ER: Weird or Different? Even so, I discussed few very specific differentiations, in my view, it becomes less relevant in a [...]

  24. [...] between PLM and ERP in this white paper reminded me one of my old posts from the last year – PLM vs. ER: Weird or Different? Even so, I discussed few very specific differentiations, in my view, it becomes less relevant in a [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 218 other followers

%d bloggers like this: