Make smart and accurate
software selection decisions
Podcasts, Webinars, and Videos
Interactive Case Studies
ERGO Decision Support System
Private Label Partnerships
TEC Case Studies
Software Evaluation Reports
Meet TEC's Experts
News and Press Releases
Working at TEC
Partner with TEC
Filling the Holes and Breaking Down Artificial Walls in a Process PLM...
Filling the Holes and Breaking Down Artificial Walls in a Process PLM Solution Set - Part 1
March 3 2011
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
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.,
) and pure-play PLM vendors (i.e.,
Siemens Industry Automation Division
). 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.,
, Dassault, Siemens,
, 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.
product & portfolio management (PPM)
and product requirements expertise, while none of the main process PLM players have research applications,
design of experiments (DOE)
capabilities (see Figure 1 for the major Process PLM capabilities and requirements). Moreover, a few
Oracle Agile Process PLM
) customers have moved beyond product specification management, whereas most
Infor Optiva PLM
Formation Systems Optiva
users have focused on formula modeling and compliance, with limited
management or PPM usage.
For their part,
Advanced Software Design (ASD)
modeling and limited compliance management, while only a few
SAP PLM Process
users use formula modeling (although some have implemented
, or “xApps” in SAP’s lingo, for recipe management and PPM). Last but not least, Dassault ENOVIA and
users mainly use these PLM products for their collaborative
product data management (PDM)
or product authoring capabilities.
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
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 (
, 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
. 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
). With no process
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:
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.
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.
(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
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.
(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
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,
, 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
DOE statistical tools and the
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
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
. 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 l
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
and ensure the
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.
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.
comments powered by
Interested in a better way to make software decisions?
Give us a call now: 1-800-496-1303 ext:404
Software Requirements Sets and Comparison Reports
Click here to leverage the experience of our 360 industry perspective