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.
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).
||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-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
||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
||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: 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:
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.
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.
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.
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.
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.
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.
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.
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.
Process: Increasing Operation Efficiency
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.
We have discussed product, project, process, and "people dimensions" for analytics based on available data in the PLM system. However, you should be aware that in some cases, analytics become more meaningful if we combine PLM data and data from other areas (e.g., inventory, shop-floor operations, sales and marketing) together.
The above four Ps are not an exhaustive shopping list of PLM analytics, but a loose template for exploring the different possibilities of using PLM data. For companies that have PLM systems implemented, I hope the four Ps model will help you strategize your analytics by seeing different possible areas. For organizations that are planning their PLM implementation, it may help you to determine which data should be captured and maintained within your future PLM systems—starting your analytics from planning the source data (rather than using whatever is available) should be rewarding.