PLM vs. ERP: Demand for Business Process

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, 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 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, 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

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?

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.

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

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.

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.

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.

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,

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.

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.