The Ugly Truth About PLM-ERP Monkey Volleyball

I had the chance to read Jim Brown’s post about SAP achievements in PLM. As usual, when PLM and ERP words come to the interplay, a very good discussion can be generated. And this is what I’ve seen this morning. I enjoyed discussion and very interesting comments. Take a look, first and read that. The discussion became hot and separate post was done by Vuuch Voice this morning -PLM Is The Monkey In The Middle.

These posts made me think about what is the fundamental nature of the discussion about PLM and ERP. I see this discussion as a natural part of the overall system development in the organization. Since early beginning of MRP and MRP-II, systems started to accumulate product data in the electronic form. So, data moved from spreadsheets to databases and Excel  spreadsheets. In parallel, design data started to move from paper to CAD and other design systems. Since then, all engineering and manufacturing systems are managing the very interesting interplay on where is data located and how you move this data from one place to another. Now what means this movement? This is something everybody present as a ‘ business process’. Yes, processes are the blood movement in the organizational body. However, the blood cells are actually pieces of data that processes moves around.

The ugly truth is that everybody wants to own the piece of cheesy product data! ERP, PLM, PDM, CAD… Everybody pretends on the part of the product data, but mostly interested how to control it. Everybody in this volleyball game is trying to catch the ball and steer it to their side. ERP is saying Item Master belongs to me! Every time you want to do something, ask me. CAD and CAD-based PLM pretends to be the best in managing product design, configuration and revisions. ERP vendors are trying to steer Bill of Materials by managing overall ECO process. Social software is trying to steer the ball, by saying let’s organize Facebook of design files. Before that time PDM was trying to organize dashboards of data. In parallel, social product development is trying to put data inside of SharePoint… There is an endless number of examples I can bring…

So, what is my conclusion today? There is nothing new in this enterprise data life, but attempt to control data and accumulate data-tolls from enterprise processes’ toll-road. If you are good in organizing this toll-road, the ride won’t be bumpy and data arrives easy and customers will love it. Some of the tolls are mandatory. Try not to pay for CAD system or accounting, for example… It seems to me PLM road is a bit more bumpy in comparison to the ERP one.

Just my thoughts…
Best, Oleg


About these ads

42 Responses to The Ugly Truth About PLM-ERP Monkey Volleyball

  1. Jim Brown says:

    An interesting take on enterprise applications, Oleg. I wonder if our different views on data vs. process come from my background with ERP and supply chain systems. Data is important, but it is the planning and processing of the data (putting a price on a sales order with appropriate discounts or doing constraint-based planning on a production line) that stands out to me. Yes, those processes require and product data. But they are processes. CAD, on the other hand, is what creates the data in engineering (among other authoring tools) where PDM is primarily focused on managing the data. PLM, to me, has PDM / data management at the core but the bigger benefits come from the planning and processing functionality.
    Perhaps it is that difference in backgrounds that provides the different perspectives? Data in ERP is a means to an end. Data in PDM is the core concern.
    After all this time, I may be starting to understand from your perspective.
    As I said to Chris yesterday, “thanks for making me think.”

  2. Chris says:

    Easy to see you are a PLM guy. You say ERP claims to own the item master and the BOM. They do own these!

  3. Jim, For me the difference between data and processes are always was with questions who come first? Sort of eggs vs. chicken, but a little different :).. Can “data” exist without process? My answer is yes! Can “process” exist without data? The answer is no, because data is the fundamental prerequisite to the processes. You need to have data to define processes – all data to be used for rules, conditions, alerts, decision points… I think, enterprise apps – ERP, SCM and later PLM were moved to talk about processes since it is clearer and explainable to enterprise people, especially if you are on the C-level. However, in the current state of enterprise software, the ownership on data is they key to decide how successfully you can run your product. CAD, ERP, Mail/Exchange/Lotus systems are own data. In the companies where PLM keeps fundamental pieces of product information (i.e. Part, BOM) is very successful. Thank you for your great comments and contribution! Best, Oleg

  4. Chris, Yep :) I’m PLM guy now. Does it confirm that all enterprise volleyball game is about data? About ERP – I think, ERP historically came first to manage manufacturing data. Because of mass production trends and push economy (vs. pull – see to optimize manufacturing processes was more important. Thanks for comments! Oleg

  5. Fun conversation! Here is what I find funny. Many people draw circles to represent ERP, CRM, PLM SCM platforms and show them intersecting to open their presentations. You can tell where they work by the size of the circles. If they are engineers the PLM circle is big, others small. IT the ERP circle, sales the CRM circle. I think it’s really funny! My thinking is that they all play a critical role and all of them house process workflow and data critical to the company. The trick is to make sure you have one source of entry or a clear point of transfer such as release. Two points of entry is a recipe for bad data! So no one system really is above the others in a larger company.
    If I have to weigh in here and not sit the fence as far as the chicken and egg go…… if you don’t have a item to order than what are you ordering? :-)

    OK I’m a PLM bigot

    Good weekend folks!

  6. Krishna Badarla says:

    Good break fast for me!!!

    Nice posts Oleg,David, James,Chris!!

    Reg -Krishna

  7. Jim Brown says:

    ERP is processes. The reason ERP has data is to support processes. The customer master? To support orders and account receivable. The vendor master? To support purchasing and accounts payable. The item? To support just about everything. But the process comes first, and the data is used to support it. With PDM, it was a way to store data. The data was the purpose, not the enabler. Then, process built up around it. Totally different in my opinion.

  8. Jim Brown says:

    Now for Chris, let’s talk about the BOM. What is the ERP BOM to support? Manufacturing planning, costing, and purchasing. I bet you would say manufacturing too? How many ERP bills (or routings, for that matter) are detailed enough to produce from? Almost none. In fact, the rule of thumb tends to be “put in as simple of a bill and routing as you can and still support planning.”

    I love the pot calling the kettle black calling Oleg a PLM guy. And you are…

  9. Jim Brown says:

    David, thanks for the laugh. In the analyst community we call that the “center of the universe slide.” I would have PLM companies come in with a picture that has PLM the size of a bowling ball and SAP the size of a pea. Some of the smartest vendors I know have brought in a slide like that. Their solution (PLM, or something much smaller) right in the center and huge. Then, the other solutions are trivialized. They lack credibility. I want to have a niche vendor come to me with SAP the size of a bowling ball, twenty other applications on the slide, with theirs being the smallest and saying “see this tiny little bit over here? That’s us.”

    Hey wait, this isn’t my blog! Back to you Oleg. :-)

  10. David Sherburne says:

    Jim good to see you see the same crap at sales time! I do need to harass you a bit. PDM is a place for data but how that data gets to the enterprise from engineering is a process.

    Designers release designs to the PLM system with a process.

    Engineering changes are routed through a process. An event happens and the engineering gathers the data impacted and does an anaylsis. The change is then sent on for approval. Once approved it hits the ERP Process….

    So all of these platforms support process not just data IF they are implemented right.

    Guess we better give the helm back to Oleg! :-)

  11. Krishna, Thanks for your support and energy :)!! Best, Oleg.

  12. David, Your example with circles is good. Time ago, I draw such circles too. However, I think (again, the ugly truth for PLM bigots), PLM guys were very late and for the time they state to draw circles, already a lot been done by ERP, CRM and SCM bigots… In the end, this is all fight for data (and I will talk about processes later to answer on Jim’s comments). Best, Oleg

  13. Jim, I understand your point. So, if I will take it forward, ERP needs to own data to manage processes more effectively. As opposite, when PLM has no control for Item Master, the ability to drive processes that require this data will be somewhat problematic. With regards to PDM- I think most of the processes in the engineering weren’t formal and were driven by engineers, which only cared where to store data. This is how PDM was originally born. Engineering looked for electronic storage for documents, and they found it in the form of early EDM/PDM system. Best, Oleg

  14. Jim, those slides you called “center of the universe” in my view just confirms that’s whole enterprise story of last 10-15 years is about to “control” for data and… (as a result) processes. Best, Oleg

  15. David, nice to see how you joggling by data/process metaphor all the time. Certainly, organizations understand “process” metaphor better. Most of the top enterprise people are not going to “data resolution” level. This is too granular for them. They assume, if the process is right, then result will be good. However, what if data processes are taking into account was wrong…??? Hm… Time to think, in my view. Best, Oleg

  16. Jim Brown says:

    You said “what if data processes are taking into account was wrong…???”

    The answer is simple: the process that created the data is wrong.


    PS – Yes, I am a process bigot, maybe you can blame too many years at Andersen Consulting

  17. Jim, Thanks for made me think! I finally got you :)… From your standpoint, in an organization, everything is created and consumed by processes. It seems to me very funny. At least, now I can take it very far. Let me give you an example. When engineer extracts BOM from CAD and put it in the bunch of Excel files on the server, this is called Release process. When somebody else, make a change in this Excel file and sending mail to change model and update drawings, this is a Change Process. Is it the way “process bigots” see the world? Best, Oleg

  18. Jim Brown says:

    For the first part, you might want to consider that extracting a BOM from CAD is a process. There are a lot of business rules around when that happens, who can do it, and how it is accomplished.

    More importantly, you left out a minor point. Why are they changing the data? Did someone just randomly decide the data should change? Or was there some activity associated with it? For example, was the information in the Excel file a set of requirements that was changed because of a design review process with the customer? And why bother changing it? Do they have a process later in the lifecycle to compare requirements to actual designs specifications? And is it possible that they develop test plans from their requirements, in what some would call the “V model” or a requirements-driven validation process?

    You make a good point, though, in that sometimes the process is very simple. But the point I am trying to make is that if you don’t know what is happening with the data, you don’t even know if you need it. During the “re-engineering” craze, we would routinely find people generating reports and spreadsheets because “manufacturing needs them” and then follow the process flow and find out that the person that “absolutely needs” the report only uses it for one piece of information that could readily be found elsewhere.

    I will try to make friends. Can we both agree that centralized data and cross-functional processes go hand-in-hand? That one without the other is relatively pointless? While much of the time the “process” is not automated, there is a process associated with the data?

    And yes, that is how process bigots see the world. If there was not process, your data flow diagram would have no arrows on it. :-)

    Happy Monday,

  19. This has been a good thread to read thank to Jim and Oleg for this.

    I agree with Jim’s points on this in his post from this am. All data is associated with a process even if it is a very simple manual one. If you don’t “see” the process then you can easily create data that is useless to the company. Which data is core to the company operations needs to be carefully identified and then traced back and controlled through a process. If you work for a regulated company than certain data has to be very tightly generated and controlled through configuration management processes.

    So have a great day! I think we would all get along well if we had the pleasure to meet! We all have the same crazy passion for this plain topic to the average human!

  20. Jim, Thanks and Happy Monday too! I agree with all your points. However, since I’m a data bigot, I can only add one more thing. If you don’t have “data”, you have no place to put process arrows to convert it to “data flow” :). With such addition, I think, we finally turned this conversation to the chicken/eggs one :)… Best, Oleg

  21. David, Thanks for joining our discussion and your excellent comments! I’m now thinking how to take us to the next level of data-process discussion. Stay tuned :). And you are absolutely right, we can think how to get together to discuss one day. Best, Oleg

  22. David Fulton says:

    Although my first training was with ERP systems, the majority of my work and training since then has been with PDM and PLM systems — even going back to the early NASA IPAD project days when “RIM” stood for “Relational Information Manager”. (Ask me about that offline if you’re interested.)

    As a result, my perspective is pretty straight forward — designing complicated products is not an easy task and there are many situations where products never get completed or even if they are completed, they are never manufactured. You need a tool to help facilitate the design process that allows engineers to work effectively and efficiently — because during the design process, they are a huge element of the cost. Once the product has been designed and you decide to manufacture it, you need a tool that helps optimize the manufacturing process and can ensure that all of the “resources” in this process work best.
    Traditionally, PLM products have been used for the design process because they were designed for engineering environments where rapid change is a necessity. Similarly, ERP products have been used for the manufacturing side, because changes to a product have to be carefully controlled — for lots of regulatory, supply chain, customer satisfaction, etc. reasons. And since most ERP systems were designed specifically to manage and control change — this was a good fit.
    Lately, ERP systems have added more “design” capabilities and PLM systems have added more “manufacturing” features — but I still believe it is better in most cases to have 2 systems — each one optimized for its portion of the design process — and to have a formalized release process that transfers the ownership of the product BOM from the PLM system to the ERP system once the design has been completed and manufacturing is ready to begin.

  23. David, Thank you for your insight! I agree with you- both systems cover the specific niche, and you figured it pretty well.
    However, it becomes complex in a modern environment when product design and manufacturing are crossing their paths and requires some interplay. Engineering and Manufacturing environments cannot live in separate worlds behind the wall. But, when you try to create an integrated environment, you learn very fast, that all players are trying to keep data close to their own storages. In my view, companies will be looking for more options to streamline processes between design and manufacturing. For the moment, I don’t see any interest from PLM and ERP vendors to invest into openness. Best, Oleg

  24. Peter Stoffels says:

    At Oleg,

    You can discuss or data can exist without processes. Where is data coming from? Anyway, even if data could exist without processes and processes can not without data: data will always be data and no information that creates added value.
    So: both are needed and should be aligned. Processes are leading because they change data, add value.

    I also do not agree that there isn’t an interest in openness. especially som big ERP vendors (e.g. SAP) are investing heavily in openness, perhaps not fast enough but the trend is there. And since the real engineering will never been fully part of the ERP system there will always be a ” two” application landscape. Hopefully standards like SPEC 1000D, PLCS etc. will help to align.

  25. David Fulton says:

    At Peter,
    Your post prompted several thoughts…
    (1) The largest PLM vendors are also CAD vendors and they have never (!!) made it easy for others to interface with their products. Some say these vendors need the flexibility to evolve their CAD products to meet new challenges while others claim the CAD vendors are just unwilling (or even “unable”) to provide stable interfaces that others could use. Regardless of the rationale, the lack of open, stable APIs that would allow any PLM (or even ERP) system to correctly store, manage, and manipulate the artifacts of the most prevalent CAD systems is obvious.
    (2) Even if the CAD system interfaces were “open enough” (whatever that means), there are still problems with trying to exchange data between different PLM systems — due to data model differences, a lack of consistency between “relationship” definitions, and many other aspects. And while some people advocate data exchange using messaging protocols or even industry-standard XML data files — these approaches were tried decades ago by CAD vendors using tools such as IGES and STEP — and the results for these much simpler data structures were NOT encouraging.
    (3) As I have posted elsewhere, I believe that some products require 3 different products. PLM to handle the design process, ERP to handle the manufacturing process, and ARM to handle the creation of the software that “intelligent” devices require more and more frequently. And although I have simplified the model a bit — for ease of discussion — it seems clear to me that neither PLM or ERP systems have been designed to accommodate a multitude of software files (with their own versions and change history) that will eventually result in one or more software modules that are embedded in the finished hardware product.

  26. Peter Stoffels says:

    At David,

    I do follow you in your explanation. Yes there is still a long way to go. I myself was a strong contributor mid 90’s in the CALS initiative. The achievements were not that enourmous as we hoped. The good thing is that we are still heading the right way, slowly but still rolling.
    And yes, there will be never an only 2 or 3-based application landscape. Besides ERP, PLM, ARM there will be always a need for BoB specialities for those niche areas were companies will want to make the difference with their competition. Till is becomes common and is incorporated in one of the other 3 applications.

  27. Peter,
    About data: I think, data is coming from everywhere. If you will come to an average company, you can find lots of data that are not in use because of various reasons (legacy apps and systems, no access, etc.). I agree, if you can transform data into something meaningful, it becomes an information.
    About openness: There is an obvious interest in standards and related activities. But, I’m continuously stating, that in the enterprise world, the standards like toothbrushes. Everybody wants them, but nobody wants to use somebody else toothbrushes :). So, I’m not surprising big vendors are trying to create standards and invest into this activity. But, they are only interested in their own standards. Some of them are more successful and some of them not. I think all, what was done in the space of standards was done only under pressure of specific business needs. So, the opportunity is to identify these needs and bring vendors to agreements. However, this is a very costly process, in my view.
    Thanks for your comments! Great discussion!
    Best, Oleg

  28. David,
    I full agree on (1). The interface with CAD/PLM was never easy. There are few reasons why it is that way. Some of them are real. When you have such a complex system, to have an easy access to data is a very complicated task. Nobody was ready to pay for that.
    On (2). The integration was always a very complicated part of PLM/PDM environment. This is continuing to be the biggest pain in this space. And the ugly truth, is that ownership of data is considered as a competitive advantage. You can get good results and see successful implementations, but these are all ‘hand-made-job’.
    On (3). The organizational trend is towards integration in business processes and, as a result, will require better integration between systems. Think about design to manufacturing or any similar cross-organizational processes.
    Best, Oleg

  29. Arun Joseph says:

    Interesting read.
    Any best practices on planning BOM & the transfer to erp? Any thoughts on what aerospace industries look for in a plm app with resp to planning BOM?

  30. Peter Stoffels says:

    @Arun, Perhaps dig into the development of the A380. I don’t know the details, but seems to be a lot use of SAP – right from the design start, inclusive the handover form design, planning to manufacturing BOM.

    In this interesting discussion regards data vs processes, PLM vs ERP, I do want to introduce another aspect: since the most assets have to be maintained (and modified) during life time, there is a hugh need for continious synchronisation between to both. There is no one-time handover. Since to life cycle cost maily are defined in design this will continue.

  31. Arun, Thank you for your comment! This question is beyond something I can answer in few lines. The communication between engineering and manufacturing is very specific. What is very important to see is that Engineering/PLM is mostly revision management and ERP is mostly “effectivity” managed. Since all aerospace products are using Serial effectivity, you can think about how engineering is managing manufacturing and building relationships and business rules related to serial effectivities. It can be different, if you are talking about supply chain. Best, Oleg

  32. Peter, Thanks for comment! I think, you made a very good point related to handover between design/engineering and manufacturing. What you called synchronization is a very complicated process with multiple rules and validation points. It cannot be done automatically, and it reflects the way manufacturing shops is running. For aero-space (this is related to Arun’s question) the processes are even more complicated since almost everything is SN effective. Best, Oleg

  33. […] was probably the most dangerous and destructive for end users. As I wrote in my post – The Ugly Truth about PLM-ERP Monkey Volleyball, enterprise software companies are trying to control data and, as a result, limiting availability […]

  34. […] was probably the most dangerous and destructive for end users. As I wrote in my post – The Ugly Truth about PLM-ERP Monkey Volleyball, enterprise software companies are trying to control data and, as a result, limiting availability […]

  35. […] article gets at the root of an even deeper problem afflicting companies – competition between departments (and software) for reasons other than the […]

  36. […] then again who has? The discussion of the overlap has been handled thoroughly by Peter Strookman and Oleg Shilovistsky so there really isn’t a point in rehashing this discussion. I think the point is that there is […]

  37. […] is easy to find his blog in a number of places. His topics run the gamut. He has taken on the dicey PLM versus ERP topic and has posted several blogs on the future direction of PLM and incorporated social media into PLM. […]

  38. […] there is a trick here. Thinking about that, took me back to the post I wrote few years ago – The Ugly Truth About PLM-ERP Monkey Volleyball  The controlling of data is one of the fundamental enterprise software behavior and strategy. One […]

  39. […] there is a trick here. Thinking about that, took me back to the post I wrote few years ago – The Ugly Truth About PLM-ERP Monkey Volleyball The controlling of data is one of the fundamental enterprise software behavior and strategy. One of […]

  40. […] both system supposed to manage such as Bill of Materials. One of my older articles speaks about The ugly truth about PLM-ERP monkey volleyball. I think beyond specific data and process management aspects both ERP and PLM vendors are competing […]

  41. […] topic. I’ve been discussing it on the blog so many times. Here are just few of them – The ugly truth about PLM/ERP integration volleyball, BOM and CAD-PDM-PLM-ERP Integration Challenges, 3 steps how to put PLM / ERP each in their place. […]

  42. […] topic. I’ve been discussing it on the blog so many times. Here are just few of them – The ugly truth about PLM/ERP integration volleyball, BOM and CAD-PDM-PLM-ERP Integration Challenges, 3 steps how to put PLM / ERP each in their place. […]

Leave a Reply

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

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 273 other followers

%d bloggers like this: