Last week we had some high quality responses to a couple of our blog articles. The first article, "The Top 5 Simple Factors to Consider in a PDM/PLM Service Provider" resulted in a very thorough response from Jim Lake that emphasized the key element in a successful relationship is to be reasonable in setting initial expectations. Client's expectations may not necessarily be realistic and many service providers are reluctant to jeopardize projects by correcting the client's misperceptions. This can lead to projects that are destined to fail. Jos Voskul also chimed in on this point as well, saying that knowing when to say "No" is a valuable trait for a PLM partner. The second article, titled "A Flow Graph of PLM, CRM, SCM and ERP during Product Life"(catchy huh?) was sort of a collaborative effort between Steve Ammann from Zero Wait-State and the prolific Oleg Shilovitsky. Oleg had written an article titled "ERP vs. PLM: More Competition in The Future?" and Steve thought the graph in his article added some clarity to the discussion. A number of people chimed in on the graph and Jim Lake promised to provide us with another relevant chart that he thought would further highlight the relationship between various enterprise tools in the product development process. This article will review the chart and the book it is featured in, Product Lifecycle Management: Driving the Next Generation of Lean Thinking, by Michael Grieves and hopefully generate some equally high quality discussions.
I wrote an article back in March reviewing a couple of PLM books but somehow I missed this one. I must confess I haven't read the entire book but the parts I did read were quite good. I am sure like most books on a dynamic topic like PLM there is some dated material but the underlying theory about PLM was very accurate. One of the interesting things about this book is that the author really discusses PLM independent from any specific PLM technology. He is more focused on the function for PLM and the process as opposed to the enabling technology. He writes about what PLM yields instead of how PLM works. The chart that Jim Lake shares from the book is interesting. As you can see it identifies 4 major business systems- Customer Relationship Management(CRM) which includes products like Salesforce.com and Seibel, Product Lifecycle Management (PLM) with the usual suspects like Oracle Agile PLM, Windchill, Team Center, Enovia, etc., Enterprise Resource Planning (ERP) which includes a cast of thousands but the majors include Oracle's EBS and JD Edwards, SAP, Microsoft Dynamics and many, many, many others and finally Supply Chain which would include companies like I2 I assume. I agree with this categorization for the most part but I think a lot of companies have folded supply chain into ERP or PLM depending upon the size of the company and the capabilities of their PLM or ERP system. I don't see too many companies with dedicated supply chain applications.
On the function side the author breaks it down into five categories; Design and Development, Engineering, Production, Sales and Service, and Recycling. I am not sure these are really universal since there is a lot of variety in these areas from company to company. I would probably lump design and development with engineering and change production to manufacturing and break sales and service into separate entities since they have unique requirements. I am not sure recycling warrants its own category although compliance which could include recycling might be worthy of a category. I think this area is very subjective and really depends on the company but I do think it is worth analyzing at a high level to understand how your systems map to your organization.
He then lists the domains of knowledge which are; Product, Customer, Employee and Supplier. I think at least from the way I interpret this he over simplifies it and really limits PLM's reach. I think an argument could be made that PLM spans all four categories just like ERP. It may be different information but I think a decent argument can be made that PLM contains information from all four of these categories. I think this may be one of the reasons there is perceived friction and overlap between PLM and ERP per Oleg's article. Another interesting fact regarding these systems is that integration between PLM and ERP is fairly common which reinforces the idea that they contain different information about the same process. Returning to my puzzle motif ERP and PLM are just different pieces of the same puzzle and you need all the pieces to assemble it. CRM and supply chain are less critical particularly when the critical pieces of information from these two areas are duplicated in either PLM or ERP. To further this point I have rarely encountered integrations between CRM and PLM. In fact I am not sure I agree with CRM's position on the chart. If anything it should intersect with design and development not engineering unless it is in a quality loop for engineering change.
To wrap it up I think the chart and the book do a decent job of portraying the relationship between business processes and the systems that govern them. Obviously one size does not fit all but if you are trying to communicate at a high level I think this chart works. I would make a few changes and I am sure there are a lots of opinions about how this might be reworked but that is part of the fun. The puzzle analogy isn't too far off from how we typically architect solutions for product development. You try different pieces of technology and process until you get a good fit and then move onto the next piece. I hope this helps further clarify things and feel free to add your own perspective.
[Edit: Repost from 2011]
[clear][clear-line]
