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

Share

Share

Share This Post

  • 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.”
    Best,
    Jim

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

  • 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

  • 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 http://plmtwine.com/2010/03/04/plm-trends-in-pull-economy/) to optimize manufacturing processes was more important. Thanks for comments! Oleg

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

  • Krishna Badarla

    Good break fast for me!!!

    Nice posts Oleg,David, James,Chris!!

    Reg -Krishna

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

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

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

  • David Sherburne

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

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

  • 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

  • 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

  • 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

  • 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

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

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

    Jim

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

  • 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

  • Oleg,
    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,
    Jim

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

  • 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

  • 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

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

  • 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

  • Peter Stoffels

    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.

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

  • Peter Stoffels

    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.

  • 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

  • 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

  • Arun Joseph

    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?

  • Peter Stoffels

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

  • 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

  • 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

  • Pingback: PLM Complexity: What Does The Future Hold?()

  • Pingback: PLM Complexity: What Does The Future Hold? « Daily PLM Think Tank Blog()

  • Pingback: Playing King of the Hill with ERP and PLM : Beyond Search()

  • Pingback: PLM Perspective: The Fantastic Mr. Fox and Product Lifecycle Management Systems - Zero Wait State()

  • Pingback: PLM Perspective: A Product Lifecycle Web Tour and Critique of PLM sites - Zero Wait State()

  • Pingback: The Ugly Truth of Multi-BOM Management()

  • Pingback: The Ugly Truth of Multi-BOM Management | Daily PLM Think Tank Blog()

  • Pingback: Does PLM have a chance to win over ERP dominant position? | Daily PLM Think Tank Blog()

  • Pingback: Manufacturing future will depend on solving old PLM/ERP integration problems()

  • Pingback: Manufacturing future will depend on solving old PLM/ERP integration problems | Daily PLM Think Tank Blog()

  • Pingback: Mass customization is the real reason for PLM to want MBOM()

  • Pingback: Mass customization is the real reason for PLM to want MBOM | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM Blog » PLM + ERP = cloud… what?()

  • Pingback: PLM + ERP = cloud… what? | Daily PLM Think Tank Blog()

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll