People: Measuring Employee Performance and More

The intent of having this category is to cover business processes other than product development and introduction processes that are managed within a PLM system. For example, sourcing can be a task managed in a product development project. However, within the project management environment, the main interests include managing those involved in the assigned task and being updated on the current status of the task. However, there might be other data (e.g., transactional data and communication records with suppliers) in the sourcing process that are not included in project management. If interpreted appropriately, this additional data may reflect valuable information that will improve sourcing practices. Some examples include: What is the most efficient way to invite suppliers in a bid? Who are the most responsive suppliers?

Depending on the scale of a PLM system being used in an organization, the types of analytics that can be performed may vary. Based on data availability, companies need to use their own judgment to discover what insights they can acquire from PLM data. Possibilities may be located in ideation and conception process, manufacturing process management, sourcing, and others. In order to make the analytics more powerful, data from other systems, such as enterprise resource planning (ERP) systems and supply chain management (SCM) systems may be involved.

People: Measuring Employee Performance and More

There are two situations that come to mind when thinking about the "people" element in PLM analytics:

1) Recently, the PLM industry started talking about the concept of "people PLM" following the discussion of using Web 2.0 capabilities in PLM.

2) About two months ago, I had a chance to talk to a project delivery team for a large industrial equipment manufacturer in China. One interesting topic discussed during the meeting was that the project delivery team was exploring the possibility of using PLM data to evaluate productivity and performance of the company's engineers.

It is true that PLM data is generated by system users and almost every data and document entry is associated with users. It makes sense that an organization evaluates its designers by the number of parts they borrow from existing designs, the number of their designs being reused by others, and the number of their designs becoming corporate standards.

It is important to remember that as PLM systems (as innovation platforms) are strengthened by embracing Web 2.0 capabilities, knowledge collaborations may surge. Hence, employees' participation and contribution to knowledge sharing and exchange might be included in performance evaluation in the future. Following this idea, PLM analytics along with the "people dimension" will become useful when companies include knowledge management methodologies in their PLM strategies.

Project: Improving Product Development Process

Within the PLM setting, "project" mainly refers to product development and introduction endeavors. Common methodologies such as integrated product development (IPD), Product And Cycle-time Excellence® (PACE®), and Stage-Gate® have been developed to manage innovation processes and to facilitate project collaboration. The purposes of applying analytics to project-related data are to improve product development processes and to achieve the best project output.

1.

Project portfolio management: Project portfolio management adds discipline and structure to determining which product innovations should be pursued. While product portfolio management functionality focuses on the best assortment of products, project portfolio management functionality deals with project risks and returns in order to achieve the best combination of product innovation efforts.
2.

Project performance measurement: Besides helping people make "go" or "no-go" project decisions, analytics can also help evaluate projects that are in progress. Project completion status, resource usage, and cost allocation are some possible areas that project performance measurement can cover. Based on these analytics, project managers will be better equipped in making sound decisions.
3.

Project task measurement: Project managers can allow for finer granularity of the task (or activity) level within a project and evaluate task performance, whether it is related to a team, a role, an individual, or a lab resource. By doing so, productivity patterns can be revealed so project managers will be able to assign the most appropriate resources to a certain development task.

Product: Developing Better Products

There are multiple areas where people can use product data to make better decisions for existing and future products. These areas include, but are not limited to, the following:

1.

Product quality improvement: Based on quality incidents, customer complaints, test results, design scenarios, computer-aided design (CAD) model analysis, and all other relevant information, analytics will help manufacturers determine root causes of product problems and address product quality issues more efficiently.
2.

Product risk management: Compared to product quality improvement, product risk management takes a more proactive approach towards product sustainability. By analyzing historical product data as well as product requirements data, manufacturers will be able to identify risk factors (e.g., underperforming suppliers, high production costs for parts, and non-compliant products) and address them before a product reaches the production stage.
3.

Product portfolio management: Based on quality, risk, and performance analysis, manufacturers are able to determine which products should be pursued. The result may include portfolios of existing and future products, which will affect product innovation investments in project portfolio management.
4.

Part portfolio management: Using standard parts is a long-term practice in various manufacturing areas. Based on part performance and usage data, analytics may help companies build an optimized parts library that contains standard parts (on international, regional, national, industrial, and organizational levels) and non-standard parts.

Different Data Sets Within a PLM System

Data is the raw material that needs to be processed in order to produce the final output of PLM analytics. Hence, before heading for analytics, taking a look at the different orientations of PLM data may help conceptualize what PLM analytics can provide (see table 1).

Orientation	Description	Example
Product	This is the most prominent group of data within the PLM system. Product data (i.e., product definition information) is the backbone of the entire PLM data set. Other data exists and is organized around product data.	Product requirements Product structure data Product document data Product document metadata
Project	Project-oriented data is used to define and help execute product development projects and processes. This group of data exists for the purposes of facilitating the creation of product definition information, but it is not categorized as product data.	Work breakdown structure (WBS) Resource information Work progression data Project risk data
Process	This group of data refers to PLM users' specific business processes. In general, there are overlaps between this group and the previous group (project data). Process data refers to the daily operational activities that are not managed as projects.	Routing and approval activities Problem-solving activities Collaboration records Transactional data associated with business processes
People	User information (with regard to PLM systems) may be associated with all the previous categories. However, it is necessary to treat the user-oriented data as the fourth data set since the "people" element is an important part of a PLM system.	System user information Roles and groups User login data User participation records

Table 1. Four orientations of PLM data

The above table separates PLM data into four groups: product, project, process, and people. This is not a scientific way of categorizing PLM data since there may be overlaps, dependences, and consequences between one group and another. However, these four sets of data represent four different facets when we look at the entire collection of PLM data, and each of these facets explores an area of PLM analytics.

Product, Project, Process, and People: The Four Ps of PLM Analytics

After a product lifecycle management (PLM) system has been implemented and used for a while, the accumulated data within the system becomes valuable. This data not only supports daily operations but it also has the potential to help companies to better understand historical performance and predict the future, if it can be interpreted properly. In fact, reporting and analytics has been a part of some PLM offerings for a while. For instance, Siemens PLM Software has included this capability in its Teamcenter solution since 2006. However, because most PLM adopters are still focusing on improving product design and development productivity, analytics remains a relatively quiet area.

Recently, following a series of activities such as PTC's acquisition of Relex Software Corporation (a vendor focusing on providing analytics in product reliability and safety), Aras and Microsoft's collaboration on enterprise business intelligence (BI) for product-driven companies, and Oracle Agile PLM 9.3 highlighting its product risk management capability as the extension of its analytics platform, PLM analytics may receive more attention from the PLM community.

Although the PLM industry has not reached a consensus on the definition of PLM analytics, it doesn't prevent us from discussing what insights PLM users should expect after mining through available data within a PLM system. The main purpose of this article is to propose a framework that may help you comb through possible areas that PLM analytics may apply to.

Are ERP and PLM Talking About the Same Thing

Some may argue that the yield and scrap factors mentioned in the previous section are not truly semantic differences, and they are probably correct. This type of issue highlights a conceptual difference between the PLM and ERP systems. A scenario that highlights the need for conceptual alignment between the product design in the PLM system and the production information in the ERP system is the selection of alternates.

A specific revision of a design may allow for alternate parts to be used in production. Some of these alternates can be applied independently, while others can only be used in conjunction with other alternates. For example, an alternate power supply can be substituted for the primary power supply for a piece of equipment, but only if an additional capacitor or resistor is also substituted on the same unit. Couple this requirement with the potential that a specific customer may have an approved supplier list. The customer, for regulatory, commercial, or quality reasons, may only allow components from particular suppliers. This is another constraint on the alternates that can be used for a particular production order. A final complexity to be considered in alternates is the identification of required replacements by geographical or organizational boundaries. For commercial or regulatory reasons, it is common to have alternative part requirements in certain geographies or for certain commercial entities.

Without strong conceptual alignment in how alternates are defined between the product design and the production order, and therefore the PLM and ERP systems, material planning to accommodate multiple substitutions and approved supplier lists would be cumbersome if not impossible. If both systems don't understand alternates in the same way, or if they have different ways to characterize geographic and organizational entities, technical integration will not provide the additional business logic to correct the mismatch. In this case, inefficient and error-prone manual intervention will be required.

PLM solutions have to work with many other systems, not just ERP, so integration is not a new issue for PLM vendors. Most PLM vendors recognize the need for integration and have addressed the need in their toolkits. The additional work comes from integrating the concepts and semantics of one system to the next, if this business level integration has not already been provided between the two systems. This can be a big challenge for best of breed vendors, who may need to rely on systems integrators for much of this conceptual and semantic integration

Are ERP and PLM Speaking the Same Language

Costs are an excellent example of semantic confusion. Accountants know that "cost" is a not a single characteristic of an item but a category of characteristics. Without answering a series of questions about the cost, the meaning of it is vague. Is the cost the procurement cost from the supplier? Does it include shipping? Does it include tax and duty? Does it include internal overhead, or is it just direct costs? If it is an assembled item, does the cost include only material costs of the components or does it include labor or processing costs? Does the cost assume a particular volume of purchase?

The same issue shows up in seemingly simple things like status codes, dates, and numerical values. For example, is the "quantity per" on a Bill of Material in the PLM system compatible with the one in the ERP system? Is the quantity per parent unit or batch/lot? Do the units of measure align? Is the decimal precision compatible? Does it include yield and scrap factors for production? Another example that has caused problems in past ERP integration projects is the definition of effectivity dates. If a component has an effectivity ending date of December 15, is the component active on that day? Is it inclusive, going out of effectivity at 11:59:59 PM (23:59:59) in the evening, or exclusive, going out of effectivity at 12:00:00 AM (00:00:00) in the morning?

These are usually simple questions to ask and to answer, but the right questions have to be asked for semantic alignment. Ideally, the questions will have been asked and answered by the vendor in advance, whether it is through standard integration or an integrated application suite.

Integration Might Be Queen

If innovation is the highest priority, then integration is not far behind. Integrating the business processes and information flow across the enterprise and the supply chain is a key component of enabling PLM. Many of the benefits from a PLM implementation come from better communication between departments and trading partners and the integration of different people and perspectives on the new product introduction processes. An enterprise level view of the design process promises to result in a design that takes into account the strengths and possibilities of all departments and business partners involved, and a design that can be efficiently and effectively introduced into current operations.

While some business processes rely solely on the PLM system, others cross the line between innovation and execution. Let's explore the engineering change process, for example. Assuming that some simple file transfers between ERP and PLM are in place, it is a relatively easy task to populate the PLM system with the current Bill of Material or Recipe, if it is not already there. As the new design is developed, many tools provide a compare utility that will show the net change between the new and old structure. That defines one important aspect of the engineering change, the changes in materials used in production.

The next aspect of change is the timing of when the change should be implemented. In order to plan the execution of the engineering change, information about levels and locations of inventory, costs, planned production, planned purchases and current demands for the product must be taken into account. This information resides in the ERP application, and is critical to making the optimal decision on when to introduce an engineering change. Without that information, the impact of making this change based on a set date, the date when existing inventory is consumed, or for a particular production run could not be understood.
Integration is more than just transferring data between two systems. Integration requires that both information and business processes be supported across multiple systems (see What's Wrong With Applications Business Processes Cross Application Boundaries). One of the key challenges of integrating PLM with other enterprise applications is semantics. "Semantics" is a term that is sometimes not very well understood, but a semantics problem could be summarized by the phrase "It's not that I didn't hear the words that you spoke, I just don't understand what you meant". Different systems have different ways of representing concepts, and associate different meaning with their data. In order to integrate systems, you have to know more than how the data are stored; you have to know what it means. While standards efforts like RosettaNet for the discrete industries and ISA S95 for the process industries have helped to standardize data structures, they still do not guarantee semantic compatibility.

Can ERP Speak PLM:Innovation is King

PLM is not just another module of the ERP system. At the risk of simplifying things too much, PLM enables innovation and relies on flexibility and loosely structured information while ERP enables control and relies on discipline and structure.

Without getting into a philosophical debate, let's examine what that means in practical terms by looking at an example. During the process of developing a new product, companies typically go through multiple iterations of the design. The designers may procure or produce component materials to use in the product and go through many different sets of specifications before delivering the final design. In addition to the product design, information about internal design reviews, market analysis, customer preferences, supplier input, pricing and other documentation is generated. Many finished designs will never see production, however, let alone the components, ingredients, or specifications.

ERP applications supply the discipline to control these materials on a large scale from an inventory, costing and regulatory view. This level of control, which is required to plan and execute a global supply chain, may not be appropriate for the product innovation environment. In addition to avoiding too much "ERP overhead" in the design process, we also don't want to pollute the ERP system with a lot of experimental material definitions and documentation that may never be used again.

PLM - The Next Enterprise Application Suite

Product Lifecycle Management (PLM) promises significant benefits to manufacturers and the market is full of vendors claiming to provide faster new product introductions, reduced product costs, reduced product development costs, increased revenue, better quality products, enhanced product innovation and other valuable benefits. Because of the high appeal of these benefits and their associated ROI, PLM has become one of the fastest growing categories of enterprise applications.

The PLM market today consists of vendors offering a variety of solutions that in some way offer value to the product lifecycle, but there is no single vendor that is supplying all of the solutions required to support a full PLM Program (see The PLM Program) October 28, 2002>. Many of the PLM solutions have their roots in the engineering department, but make no mistake; PLM is an enterprise application suite and has all of the additional requirements that come with enterprise class applications.

The PLM concept pulls together information and business processes from multiple disciplines within the enterprise and across enterprises. While product design plays a crucial role in the product lifecycle, PLM is not just a series of add-on tools for Computer Aided Engineering (CAD) and Product Data Management (PDM). But it is not just another module for ERP, either. PLM is a suite of applications that can be used by a company to get the highest value from their products to improve their business results. And like any other new suite of enterprise applications, as learned from SCM and CRM, companies may have to choose between the potential tradeoffs between best of breed solutions and solutions from their ERP vendors.