Home
 > Research and Reports > TEC Blog > Filling the Holes and Breaking Down Artificial Walls in a...

Filling the Holes and Breaking Down Artificial Walls in a Process PLM Solution Set - Part 1

Written By: Predrag Jakovljevic
Published On: March 3 2011



The product lifecycle management (PLM) software market for process industries (food & beverage, life sciences, chemicals, paints, consumer products, etc.) is serviced by a plethora of solution providers, but it hasn’t been well-defined as compared to its counterparts in the discrete manufacturing and fashion (apparel) industry segments. Indeed, the Process PLM solution market is a mosaic of specialized vendors, starting with enterprise resource planning (ERP) vendors with some process PLM capabilities (i.e., SAP, Oracle, and Infor) and pure-play PLM vendors (i.e., Siemens Industry Automation Division and Dassault Systemes). In addition, there are many toolset-oriented niche vendors and document management system (DMS)-oriented point solutions.



Process PLM Market Background 

Unlike the discrete manufacturing PLM market that has several broad solution set providers (e.g., PTC, Dassault, Siemens, Autodesk, SAP, Oracle, Arena Solutions, Omnify Software, Infor, etc.), most process PLM solutions are partial (point) solutions. During the formation phase of this PLM software category most of these vendors had a highly specialized (narrow) expertise and have thus developed targeted solutions.

For example, Sopheon has mostly product & portfolio management (PPM) and product requirements expertise, while none of the main process PLM players have research applications, design of experiments (DOE)and/or lab notebook capabilities (see Figure 1 for the major Process PLM capabilities and requirements). Moreover, a few Prodika (now Oracle Agile Process PLM) or MatrixOne (now Dassault ENOVIA) customers have moved beyond product specification management, whereas most Infor Optiva PLM (formerly Formation Systems Optiva) and Selerant users have focused on formula modeling and compliance, with limited specification management or PPM usage.

For their part, Advanced Software Design (ASD) and Enginuity PLM mostly have (chemical) formula modeling and limited compliance management, while only a few SAP PLM Process users use formula modeling (although some have implemented composite applications, or “xApps” in SAP’s lingo, for recipe management and PPM). Last but not least, Dassault ENOVIA and Siemens Teamcenter users mainly use these PLM products for their collaborative product data management (PDM) or product authoring capabilities.

plm-1.jpg


Figure 1


What Have Process Companies Been Doing?

As the process PLM category has matured, a few of the aforementioned vendors have been able to expand beyond their original focus and stronghold. Without the required expertise, most of the aforementioned vendors have at best expanded their solution to manage other types of data objects but with limited applications’ functional depth for process industries.

This causes most companies to select a process PLM vendor for its primary area of expertise and “make do” with workarounds for less functional modules. The benefit of this approach was the ability of these process manufacturing enterprises’ ability to “go live” quickly but it has also limited their users’ ability to expand the breadth of their process PLM implementations.

Some large process companies have thus cobbled together many point PLM solutions that have required heavy customizations, since these solution sets have limited application breadth. As an example, Procter & Gamble (P&G) has PLM solutions from Dassault, Siemens, Enginuity, and others, which inevitably leads to developing custom applications. PTC, Siemens, and Dassault's request for proposal (RFP) responses typically have thousands of lines of text describing the need for PDM customization, collaboration tools, multiple coding tools (Microsoft .NET, Java, each of their multiple computer aided design [CAD] tools, etc.), and relatively much less about their process industry applications.

Moreover, each of these solutions focuses mostly on structured data. Yet, product specifications typically have only about 20 percent of data from formula modeling database tables and fields, and the remaining 80 percent of data is too “fluid” to work in a PLM system (i.e., the engineering change management overhead is too complex).

Along similar suite-cobbling lines, many companies that cannot make a functional tradeoff decision (i.e., cannot pull the trigger to make tough decisions), or whose data does not fit into the structured data model, cobble together Microsoft Office tools (i.e., Word, Excel, and Outlook). With no process validation and/or data integrity in place, the risk of a Microsoft Office-based solution is often prohibitively unacceptable.

Within each category of process PLM solution, process industry customers have achieved some gains. But with the lack of a complete landing solution, most companies have no real migration path. Types of support and value that one should expect are as follows:

  • PDM or tools-oriented solutions allow companies to configure data for each object and workflows. With limited process PLM applications, these solutions are not constrained by the needs of PLM applications and can be configured to capture any data. While these solutions can manage diverse data, their ability to have strategic business unit (SBU)- and/or product-specific data and data validation is limited. Often companies use Excel or legacy custom solutions to create formulas. This data is then manually entered into the PDM solution, which manages the approval and engineering change management processes.

  • Specification-oriented solutions provide a single place to find specification information (so-called product specs). These solutions (e.g., Oracle Agile PLM or Dassault ENOVIA) focus on capturing a wide variety of data from several departments and types of data objects, thus managing the approval process and publication of this data. Since each section of specification can be from different sources, and data needs to be published for wide consumption, these applications focus on gathering disparate data. But since their original orientation is a wide variety of static data, their modeling and design tools do not support most of the experimental needs and are thus not often deployed.

  • Formula modeling and compliance-oriented solutions (e.g., Infor Optiva PLM, Enginuity PLM, Selerant, etc.) provide applications that support experimental formula structure management and modeling capabilities. Some of these solutions manage formula and formula recipes. A formula recipe will include equipment and instructions but does not really support the S88 and/or S95 recipe standards. Some common modeling capabilities are cost rollups, allergen rollups, density, and yield calculations. These solutions have integrated modules to support project management, basic portfolio management, and specification management.

  • PPM-oriented solutions (e.g., Sopheon) are usually standalone solutions that manage business processes, are document-oriented, and provide better product and project portfolio management capabilities. Since they mainly manage documents, the time and cost to manage product ideation and other needs is very low.

  • S88 or S95 recipe management-oriented solutions are most of the time coupled to a downstream PDM, ERP and/or manufacturing execution system (MES) solution. These solutions (e.g., Siemens, SAP, OSIsoft, etc.) are used toward the end of the product design process and are optimized to feed a downstream transactional and execution solution. A few of the aforementioned formula modeling solutions have added a basic S88 recipe management capability. As hinted earlier, most process PLM vendors confuse a formula recipe management/modeling (i.e., formula, instructions, and equipment) vs. a S88 recipe. The latter recipe is mostly about depicting process parameters (i.e., pressure, heat, flow, etc.) and set points, and typically has thousands of detail lines. Conversely, formula recipes are mainly about materials (ingredients) or equipment, and have “only” hundred lines of detail.

  • Research, DOE, and lab notebook-oriented solutions are most often standalone or PC-based applications. These solutions, such as the Minitab and Stat-Ease DOE statistical tools and the CambridgeSoft and Accelrys lab notebook systems, are designed to capture information but lack the enterprise validation rigor. When the “secret sauce” concepts in the lab are approved for further development or commercialization, a downstream user will re-enter a subset of structured data into one of the solutions that are listed above. Unfortunately, most of the research knowledge (thought process) is not available to downstream users.


What Could Process Manufacturing Enterprises Do better in PLM?

As with other application categories, users need to break through traditional system boundaries and support a more horizontal (broader) process PLM solution. Examples of this include the following:

  • Research and Development (R&D) cost estimation modeling should be based on purchase price indexes or actual costs captured in the ERP system.

  • Published product specification documents should include both structured PLM, non-PLM data, and unstructured PLM data with metadata. For many business to business (B2B) industries, one formula (or a formula with a different application) is sold to multiple customers, markets, and applications. For each major customer, product, application, and market, each specification is likely to have “required data” and formatting. Since the data and formatting can even be “one off” data, they are rarely stored in the PLM database.  This is further complicated by material shortages or the need to offset rising commodity costs, all resulting in a continual flood of new formula versions. Prior to many of new specifications being used in production, a new formula version will supersede the old version and new specification must be created. Using a dynamic publishing strategy, these companies can pull any stored data, enter new data in the business process, and publish an approved specification. The published documents provide immutable proof that some ingredient can be sourced from multiple sources or from an approved claim for one particular customer, product, application and/or market. The metadata supports search or the ability to more easily update the documents. This approach allows companies to balance engineering change management costs, data maintenance costs, and the time to react.

  • A unified enterprise item, formula, recipe, and packaging maintenance process can fill the gaps between each of these point PLM solutions. When the item master or other data is incomplete or inaccurate, the diverse enterprise systems are not updated. Without this data, formulas or higher-level data objects-based integrations fail. When production lead-times are short, this can stop production of a batch, and cause lost sales and other customer issues.

  • Requirements management with proper processes to develop requirements, which ensure that these are validated in the product and that claims are substantiated, help minimize the time-to-market (TTM)  and ensure the brand protection.

  • Knowledge Binders improve project collaboration or minimize the time to find information about product, customers or production issues or performance. Without these capabilities, user waste time and are often operating on incomplete information.

  • Collaborative Workspaces improve project collaboration or minimize the time to find information about product, customers or production issues or performance. Often the PLM system’s security limits the ability to share data across divisions. For example, to maximize the performance of a paint formula, the paint chemist may need temporary access to a highly proprietary resin formula and test results. To improve performance in paint formulas, the resin chemist may need access to paint formulas. This is a common challenge for companies that sell to other divisions and to external customers, since they need to have controlled access to their highly confidential formulas. Without the ability to securely collaborate on products’ capabilities, users waste time and are often operating on incomplete information, while the product performance is not optimized.


With each of these solutions lacking a complete process PLM footprint or with only supporting limited basic features, companies could continue to drive more value with the availability of cloud-based and/or licensed add-on software solutions (in a hybrid deployment manner, if necessary) for S88 recipe management, collaborative material specification management, DOE, laboratory notebook, requirements management, and distributed cost rollup engines.

Part 2 of this series analyzes other typical shortcomings of process PLM solution mishmashes and talk about some novel potential remedies. Your views, comments, opinions, experiences, etc. about the abovementioned process PLM issues and solutions are welcome in the meantime.
 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.