PLM vs. ERP: Demand for Business Process

Picture 1I want to start today with twitter quote “PLM vs ERP – ERP a transactional system, not suited to manage development of product, integration of all info such as ingredients”. Well, PLM/PDM vs. ERP discussion is old, and I remember it for the last 10-15 years or even more… However, I’d expect some changes in this non-stop confrontation.

The original capabilities of PLM and ERP came respectfully out of their business roots – CAD Design/Data Management for PLM and manufacturing transaction from MRP/MRPII/ERP. However, both domains had demands to grow and make an expansion in organizations. PLM is looking for attractive domains such as requirements, manufacturing, supply chain. ERP is interested to expand toward product development. Both system domains (PLM and ERP) are looking how to establish connected space for enterprise organization business. So, how to achieve it?

I think, very interesting is that both classes of systems are very in favor of business processes. Even if PLM and ERP have a different notion of business processes, I’d say Business Processes can provide good synergy between both systems. PLM traditionally focused on very high level of people involvement in processes. Human based and hybrid processes is something that PLM requires. On the opposite side, ERP is focusing on automation and streamline of processes in organizations.

I think vendors on both (PLM and ERP) sides need to look very pro-actively how adopt Business Process Management technologies. This will be the key to success in organizations. From a technological standpoint, maturity of standards like BPMN and BPEL can provide a solid technological foundation for this work. But, at the same time, both PLM and ERP need to worry about growing capabilities of dedicated BPM vendors. They can take an attractive $$$ from aged PLM and ERP providers and establish strong BPM leadership in organization. I wrote about this in my previous PLM prompt.

So, what is my conclusion today? Business process have strong demand from both sides- PLM and ERP. The road toward successful BPM implementation can be very bumpy for PLM and ERP. Need to watch it out. Multiple vendors can still business and establish success business in front of enterprise behemoths.

What do you think about it? What are your practices with regards to process management in organization?

Best, Oleg

Share

Share This Post

  • Oleg I cannot see how you can say PLM is more people centric than ERP. They both engage people in very much the same way and PLM is not at all more collaborative than ERP. In my post (http://blog.vuuch.com/?p=472) I tried to draw this point out. ERP and PLM are both transactional tools which is a point I was trying to make in my post (http://blog.vuuch.com/?p=448) about People Centric and Process Centric solutions. This is why ERP companies are looking to puch the PLM vendors out of the market. In MHO the ERP vendors do not see any need for customers to complicate thier environment by purchasing a seperate PLM solution from another vendor. I am sure that in many PLM solution pitches done by ERP vendros that the slide deck contains a set of slides that states why add a new vendor, another technology and more expense, why not just extend what you have…

  • Pingback: Twitted by vuuch()

  • Chris, I think nature of work around design and CAD make PLM vendors coming with these origins more people-oriented, collaborative if you will. However, PLM is pro-actively looking for “business process orientation”. Nature of design and engineering, in my view, is more collaborative and less formal work. We can say – PLM is not collaborative enough, and, therefore, “new social PLM” is coming – this is ok! I believe both ERP and PLM are striving to 1/to become more business oriented (for ERP it easier); 2/to control organization micro and macro processes. PLM pitches for ERP companies is the way to expand to business areas they see attractive, since processes need to cross various business domains (PLM, ERP are two of them). Thanks for comments and blog posts! Oleg

  • Roberto Picco

    I’ve often defined my company in my internal papers as “ERP-centric enterprise”. ERP is the waypoint for every internal business process, much more than any PLM/PDM system in use. This is not true for all companies, but it is for most of them. Consider that here in Italy most of companies are small…

  • Roberto, I agree, ERP is leading in maturity and implementation of business processes in organization. However, PLM is focusing on something often positioned as “collaborative business processes”. The underline implementation can be different in PLM, but I think, demand for business processes is clear, at least to me.
    Thanks for you comments! Oleg.

  • I agree that prodcut development is less process oriented than most of the procedures supported by ERP. But both the ERP and PLM tools are very process centric and this is one of the reason the ERP vendors beleive they can enter the PLM market space.

    In my post from yesterday (http://blog.vuuch.com/?p=490) I picked up on this. The danger for current PLM solutions is they become dominated by ERP and Design, Release and Manufacture becomes just Design and Manufacture which I see as a very real situation since Release and Manufacture are both highly process oriented.

  • I would make two points. 1. The elements that both PLM and ERP support are business processes. Just because a work element is not captured in workflow or BPEL does not mean it is not a business process. To the contrary, I have seen many companies retreating from the computer managed business process world to more old fashioned manual approaches because the effort to manage some processes and exception cases was far greater than the benefit. From my experience, these cases seem to happen more in the traditional PLM focused world than the ERP focused world.
    2. In a previous post, someone mentioned 3 fundamental stages, Design, Release and Manufacture. The later 2 are in my opinion transactional centric. The Design stage is non-transaction centric. All three elements do have some transaction and non-transaction portions. The point that often gets lost though is that from a traditional PLM space, most of the value that PLM should be providing happens before the transaction centric piece but most of the focus is on the Release/transaction centric phase.

  • Alan relative to your first point I think you are right on target, and this is why PLM has been confind to just release. Everything in the Design phase is an exception. Relative to your second point do you think ERP will eventually take over the Release phase and therefore change the landscape to Design and Manufacture?

  • Alan, I agree with you. Focus on transactional phase is because it case be easier managed and, this is very much in focus. However, more and more businesses understood they need to have Design involved. In my view #1 reason why, is because, Design is where major part of product cost is defined. Without ability to influence product cost future product optimization won’t be possible in current business and competitive situation. Just additional thoughts… Thanks! Oleg

  • Chris, what do mean by “everything in Design phase is an exception”? What I read between lines is that you are saying there is not formal “design process” similar to “release process” you can build using formal process technologies… I’d agree, Design process is much more collaborative with lots of people interaction. However, it doesn’t mean systems supporting these processes cannot be “process connected”… Your view? Thanks, Oleg.

  • Design is about discovery so it is not possible to make this a canned set of actions. Certainly you can have things you must achieve and things you must check against, but this will never be a predefined workflow. In my view Design productivity is delivered by enhancing the way people interact. This is is what is behind my idea of “People Centric PLM” (http://blog.vuuch.com/?p=472). And if there is a People Centric PLM opportunity then it is very different than the Release based PLM. Extending this thinking and looking at what happens during Release and Manufacture tools/application is what gets me questioning if Release and Manufacture will ultimately merege (http://blog.vuuch.com/?p=490). Which I have further defined as possible through the post about opposites (http://blog.vuuch.com/?p=497).

    So yes your “reading between the lines” would be accurate. But I am not sure “Process Connected” is required becuase as you have written about Mashups and Big Bang etc… it is more about data sharing than process integration. For example if I am working in a People Centric PLM solution and as part of what I am doing I need to understand inventory, do I need the data or do I need a process?

  • Oleg your response to Alan got me thinking – in your reply you talk about Design involvement as a way to reduce prodcut cost and you imply that PLM has done this… I know this is something PLM markets to but I cannot think of anything I have read that proves this point. Do you have any data/links that show how PLM has reduce product cost during Design?

  • Chris, I would not say that PLM has been confined to release but I would say that has been the focus. My opinion is that is because it is the easiest to automate. I do believe that some companies will move the release process into ERP, particularly SAP shops. I do not see that as a huge trend though. It more or less depends on your organization structure and responsibilities. The gating factor is often how many people have to be trained in multiple systems. If it were my company, in most cases I would keep Release in the PLM system because release is still an engineering function. As we look toward collaborative design and design for manufacturing, the more interesting question becomes where do you author the Manufacturing BOM.

  • Oleg, I agree with your comment that PLM functionality in the design phase is more valuable. It is also much harder to implement effectively. Therefore the quest goes on.

    Chris, I will give you two examples related to PLM and cost management. 1. One of the major ways to reduce engineering and manufacturing cost is through platform strategies and part reuse. From the part reuse perspective, PLM can play a huge role via cataloging, reporting, auto checking, design review color coding… In the broader PLM scheme, KBE functionality is used to manage platform strategies/ reusable design concepts, design features… These are typically huge cost savings drivers.
    2. I see several smaller PLM entries that are being built to manage the cost side of equation. Most start from a point in the process such as a quote or milestone. I have not seen a commercial product that works from product concept like a true Target Costing process.

    Just to close the loop a bit, the good news is many companies are embracing and driving reuse. The bad news is that some implementations can have trouble in the release process when a part is used in 1,000+ assemblies. Making a change to such a part, though rare, can often bring an automated change process to its knees.

  • Chris, very valid question, in my view – data vs. process. I can see data without process, but I hardly can see process without data. This is, in my view, the biggest challenge of all process-oriented tools today. But enterprise community is very positive about process, so PLM vendors are jumping on this trend and hope it will be beneficial. Also, because, two biggest PLM providers these days (Oracle and SAP) are obviously will continue to push “process” orientation. Best, Oleg

  • Chris, I don’t have links, but I’ve seen customer’s implementation. If you can get control of manufacturing bill from design and opposite, you can “predict” cost and make it controllable. I still don’t see it as a main stream, but this is happens with PLM approach. Best, Oleg

  • Alan, in my view “authoring of manufacturing BOM” is key question if you want to control you product cost. And you need to do it from PLM-related perspective (design) otherwise your control is not complete and you will make not optimal design from cost standpoint. This is related to my previous comment to Chris. -Oleg.

  • Alan, I agree, Part Reuse is key. As for commercial products – cost function is normally placed in xBOM/MBOM modules in today PLM Suites. If *Cost* function requires more focus? Yes, I think so. What is your opinion why it’s not in mainstream of PLM implementations today? Too complex? No time? Busy with basic deployment? What is your experience with that? Thanks! Oleg.

  • True, production cost is typically maintained in the MBOM, which typically means in MRP. However in my experience this data does not get loaded till just before production ramp. So Excel is stil the king of cost management during the design/pre-production stage. Data may come from all over but the master models are still in Excel. There are multiple reasons why cost has not been mainstream PLM. 1. As we have discussed, PLM has traditionally been engineering centric. While cost management is traditionally owned by finance, program management or manufacturing. 2. PLM vendors have been engineering centric and apps reflect this. Until the PLM cost modules are similar to Excel in ease of use, the drivers aren’t as clear cut. 3. The Financial BOM is often different structurally from the EBOM or MBOM. Until the reconciliation process is determined, the automation benefits are weak. There are some non-mainstream PLM vendors focused on this space but I believe still needing to address these core issues.

  • Alan, Thanks for your insight! I think I got your point- cost analyzes is function that can be disconnected from overal stream as soon as you know how to get data there and reconcile results. So, we back to the topic of Excel kingdom – usability, flexibility and data ownership. There is definitely value in overall cost control, but in today ecosystem customer need 1/buy additional PLM licenses (instead of Excel); 2/Get new people (finance, PM) into PLM user experience; 3/allow integration to make data flowing back and forth. All together sounds like a very expensive project compare to MS Excel with some import/export functions…. So, key questions:

    1. Is it really so cheap, to manage BOM cost in Excel on the long term?
    2. How to make PLM experience adjusted to that?

    and the last one – I’m sure BOM cost analyzes make a lot of sense for the long term. When PLM approach allows you to make these analyzes and see what decision was and what are outputs and impact, the MS Excel approach is very fragmented. You cannot handle excels and corresponded decisions for long term (ah… you can say – SharePoint does)…

    So, my bottom line. Value of PLM in cost analyzes is obvious. Approach sounds like NO.

    Best. Oleg

  • Oleg,

    I am not sure I follow your last post. Perhaps it was my previous post was not that clear so let me clarify in no particular order.
    1. Data comes from multiple sources. Consider an assembly made in Plant A which uses parts from your Plants B & C and well as outside suppliers. In many cases, determining the cost for parts from Plants B&C is the responsibility of the plants or component divisions. Costs for purchased components comes from Purchasing/Procurement. Costs to do the assembly in Plant A may come from Plant A or Assembly division.

    2. PLM applications have not been involved in the cost management arena as long as they have been with engineering. Cost/Finance types do not think the same way engineers think. They often structure their data differently. Just like Design Engineers often think and structure their data differently than manufacturing engineers. It is not as simple as hanging some cost fields off of the EBOM. Until PLM providers think and develop apps the way Finance/Cost guys think then short of corporate mandate, Excel will prevail.
    3. What is the problem to be solved? A solution for a 12 part assembly is probably different from an offering comprised of 120 End Saleable configurations with 1200 parts. A Target Costing/Design to cost process requires a different solution than a back end roll-up. Going back to part of your original post topic Business Process (not necessarily workflow) needs to be understood before automation solution has enough benefit to move beyond the Excel kingdom. In my opinion, PLM providers are not there yet.

  • Alan, I agree with you. Most of PLMs have “engineering” roots. However, you are right, we shifted topic a little. Back to original “process” focus, process solution for cost management can provide much more then just “few cost field in BOM”. I never seen such solution out of the box coming from PLM vendor. Best, Oleg

  • Cost certainly seems like an issue that unravels the nicely knit PLM pitch. Cost is one of those things that cuts across so many in the organization. Certainly a designer sets cost based on the geometry and tolerance the specify, but manufacturing, inventory, quality, regulatory and even those marketing guys define/add to the cost of the product. Alan is it fair to say cost is something that is highly collaborative? With so many adding to the cost is there anyone you can point the finger at for ownership? Certainly we record component cost in the ERP system but who as an individual owns responsibility for cost? Certainly finance qualifies what the “true” or “real” cost is but who is responsible for cost?

    I imagine there are other product attributes there are just like cost. What about quality and inspection procedures and inventory levels and requirements? Are all these things highly collaborative or should I say “people centric” versus file centric?

  • Chris, I think there are many “variables” that have cross-application ownership. Cost is just one of them. Regulatory compliance, customer information and many others should come to this list as well. I’d not call them “people-centric”. In my view this is just business information that crosses domains as we set them up. But these boundaries becomes more and more fuzzy, as I see them. Best, Oleg.

  • Chris,

    From my experience in a more complex product, total product cost ownership lies with either a Product Manager or Program Manager. A good design engineer is aware and responsible for all costs related to design/development and production of his/her part(s)including regualatory, quality… As you say, most of these costs are recorded in the ERP system either in the manufacturing or finance modules, after the fact. The real challenge is having a “system” that can be used to predict, analyze and strategize what the costs will be before they are too committed. This is still a gap in my opinion.

    The remaining costs of sales and marketing and projecting sales and profitability is a whole other piece of the puzzle that still needs addressing.

    I would not call cost management collaborative as much as I would call it distributed. The data comes from multiple sources. The collaboration comes when one area can’t hit their cost target and other areas pitch in to help. This assumes the use of some sort of target costing approach and the ability to roll the data up to see where things are at. Historically, this has not been a strength of PLM or ERP.

  • Alan, I think all enterprise systems (PLM and ERP are on the list, of course) are doing very bad with distributed data management. Some mashup ideas can may be work, but we come to data ownership and complexity of solution very soon. Have you had chance to experience with such approach? Best, Oleg

  • I would say the reason people use Excel is because cost is distributed and in flux. Like Alan states one group will pitch in to help the other and the applications are built to only catch the end state.

  • Chris, I’d say, in addition, Excel is always good compromise, when people cannot agree about system usage, ownership etc… Oleg