Global MBT:
Login  |  Register          Free Newsletter Subscription
 
PLM and Profitability   


Recent Posts

Recent Comments

Most Commented On

Archives

Blog

Link This | Email this | Blog This | Comments (2)


One-to-One: How is SAP's Formula for Process PLM?
September 26, 2008

I had the chance to talk with ... SAP last week at their ASUG user meeting and analyst day in Nashville, read my first post Can SAP do PLM?  about my general thoughts. Along with the updates on the general SAP PLM offering, which is aimed primarily at discrete manufacturers, SAP gave an update on what they are planning for process manufacturers - for example CPG, food, beverage, household goods, etc. The key difference for these companies is that the heart of their product is a formulation or recipe as opposed to a bill of material (BOM). How is SAP's solution shaping up there?

Setting the Stage
This story can't even be started without one crucial fact - a lot of very large, very prominent process/CPG companies run SAP as their ERP system. Colgate Palmolive, Conagra, Hershey's, and General Mills are a few that I have spoken to recently. Many current SAP ERP customers are encouraged to use SAP PLM (if not mandated by internal IT policies) to take advantage of a single vendor and pre-built integration. For that reason, SAP has a large contingency of process and CPG companies that are very interested in the future of this solution. There are more that would like to use it, or are evaluating it, that are trying to understand where SAP stacks up in PLM for their industry. I am not aware of companies that are seriously looking at SAP PLM that are not currently running SAP.

The Unclear Truth (sorry)
The only clear truth on this matter, as Martin commented on my first post about SAP and PLM, is that it depends. Whether SAP PLM is right for you depends on how you define PLM and what you are trying to accomplish. For the sake of simplicity, I am going to take two extreme examples to show where SAP may or may not work. As with anything that you try to simplify, it will probably come back to haunt me... but here goes:

Example 1: Enabling the Innovator
Our first (fictitious) company has the following characteristics:

  • Complex formulations (multi-level, perhaps multi-phase)
  • A significant number of iterations of the formula before release
  • A significant number of variations of the formula (customer formulas, for example)
  • The company would like their product developers / chemists to use the system to help them actually create, calculate, and develop the formula
  • The company would like to replace their paper lab notebooks with the system, capturing all of the necessary discovery and innovation electronically
  • The company's products and product development processes are highly regulated

For this company, or one with some of these characteristics, they need to have the chemists, formulators, flavorists, biologists, etc. actively using the system in developing the recipe. Perhaps we can say they are looking for "CAD for Formulas" in addition to process and product data management. They will want to store a significant volume of "work in process" designs for historical and search/reuse purposes. These companies are likely to be better off with a vendor that specialized in formula management, such as Enginuity, Infor, or Selerant. Or perhaps Linx/AS, who is developing solution based on SAP's Netweaver platform in this area.

Example 2: Aligning the Organization
Our second (fictitious) company has the following characteristics and priorities: 

  • Providing supply chain information (cost, supplier data, sales information, etc.) to the designer
  • Easily transferring the recipe to manufacturing or production
  • Understanding the impact of a formula change on the rest of the business
  • Storing their recipes in a central location for the enterprise
  • Currently use SAP for ERP

In this case, the company is trying to integrate supply chain information into the design process and use SAP to manage final formulas. SAP's integration is a clear differentiator for companies like this.

Example 3: The "In Between"
Unfortunately, most companies will fall in between the examples. For these companies, SAP will continue to enhance their capabilities for the hands-on innovators, and the specialists will continue to enhance their ability to integrate easily with SAP (and other ERP systems). These companies will really need to spend some time evaluating. I just discussed this a week or two ago with my good friends at Kalypso who do a lot of consulting for PLM in the process industries, and I think they would agree based on how frequently they hear the question about whether SAP can "do PLM." For most companies, they should likely consider some of the specialists listed above, along with Dassault Systemes (for MatrixOne) and Oracle (for Agile and the Prodika solution acquired by Agile) and Siemens PLM (who are combining UGS solutions with existing solutions from Siemens and working with their customers like Unilever).

The Roadmap
CPG is clearly in the roadmap for the new version of PLM. They are actively looking to customers for their input and guidance. The first release of the new interface it primarily focused toward discrete manufacturers, but there is no doubt in my mind that they have always intended to follow up quickly with process. This new interface will likely come with some new functionality that is welcomed by the installed base, and they have the chance to help define it.

The net is that SAP PLM for the process industries:

a) Is in use and in demand
b) Is not at parity with formulation specialists for enabling chemists, formulators, flavorists, etc.
c) Should be carefully evaluated before use in storing large volumes of "work in process" design
d) Is an option that needs to be considered for managing recipes if you are an SAP ERP user
e) Is a solution worth keeping an eye on as it evolves, and as we all get more experience with how the recent cross-industry advances in the PLM roadmap play out

Still more questions need to be answered on SAP and PLM, it is an important topic. Expect more in the next week or two. If you let me know what you want to hear about, I'll do my best to accommodate. So that's what I hear from SAP, I hope you found it useful. What do you think? What else should I have asked them?


Posted by Jim Brown on September 26, 2008 | Comments (2)


September 27, 2008
In response to: One-to-One: How is SAP's Formula for Process PLM?
Dan Vougsted commented:

In my humble opinion working in this industry (CPG) for 12 years,whatever concepts we read about PLM for CPG, it's a recycle of the same stupid information coming from the Vendor->Analyst->Consultant->Vendor->Analyst 1. Analysts who are starved to learn more about this area receive their information mostly from vendors. They create fancy reports with this information and sell it to.... 2. Exclusive PLM CPG "Consultants" study these reports go around fooling their customers along with their favorite vendors 3. PLM vendors who in the first place are new to CPG needs fool analysts and consultants by promoting what the industry does not need. Like 3D CAD drawing for CPG packaging. This stupidity is what makes PLM adoption slow in the CPG industry




September 29, 2008
In response to: One-to-One: How is SAP's Formula for Process PLM?
Jim Brown commented:

First, I thank you for the post. I have to admit, I have seen some of that myself. But in candor, I don't agree that is what is making adoption slow for CPG in PLM. Before I go on and share my thoughts, I will ask you one question. What do you suggest would help adoption? Or, do you think adoption is not valuabe? Sorry, it's a two-part question. I hope you have the chance to reply. The part I agree with is the classic PLM players (consultants, analysts, vendors, etc.) that try to address the issue without domain knowledge. I was on the phone the other day with a CIO from a very large PLM company (I can' share the name, but it is Fortune 500 and it will appear along with the quote in in my upcoming report on "CAD for Formula-based Industries"). What he said spoke to me directly, because a big part of my background is in "specialist" software written for specific industries. His comment was that if you don't understand the way the people think and the process in which they do things - really understand it, not just study it - then you can't write software to support them. I chuckled during the interview when he said it. Now before you react to "CAD for Formula-based Industries" and think I am talking about talking about 3D CAD for packaging, I am not. I am talking about taking the same principle behind mechanical CAD (or EDA/electronic design automation for that matter) of applying rich tools that eliminate the grunt-work and enable more focus on innovation. They are not 3D, they are based on the core priciples of chemistry in the same way that MCAD is based on the core principles of mechanical engineering. So if someone comes talking about PLM for CPG, ask their credentials. Not just the sales person or the analyst, but the rest of the organization and their knowledge base. I think you will see very big differences in certain vendors that really "get it." I will make sure to post a link to my study up in the next few weeks so you can react/respond. How do you break the cycle? Insist on domain and industry expertise from the people you are willing to learn from. Thanks for the post. I really wanted to disagree with you, but I am not sure I disagreed as strongly as I wanted to. I think there are lot of vendors, consultants, and analysts that are trying to understand and communicate - and I believe that a number of them really know their stuff. Contact me directly and we can name names and compare notes...





POST A COMMENT
Display Name or Registered Users Login Here.
Please restrict submissions to less than 7,000 characters (including any HTML formatting).

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive:


Advertisement

Advertisements





About Us    |    Advertising Info    |   Site Map    |   Contact Us    |    FREE Subscription    |   Affiliate Links    |    RSS
©2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites