In the course of product development, there are stages a product goes through and changes that take place over time. The following article is intended to provide an overview of software driven processes, which are often referred to as Product Lifecycle Management (PLM). Before investing in a particular technology, understanding the possible complexities associated with a successful PLM deployment can aid executives and managers in understanding the details involved, as well as setting a level of functional expectation. In the following quote, Product Lifecycle Management has been broadly defined:

"PLM is a strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination, and use of product and plant definition information across the extended enterprise from concept to end of life-integrating people, processes, business systems, and information. PLM creates and manages the digital product or plant and provides an information backbone for a company and its extended enterprise."

This definition conveys the basic tenets of PLM, however, while we notice that it captures the high-level concepts and grand promise of PLM in an ideal world, what is truly needed is a basic understanding of how elements of PLM would be applied in business processes. Because this type of grandiose approach is often used at the management level to explain PLM, the reality of business process is often left behind. PLM explained in simpler terms will give a clearer view of the concept.

Types of Information

For the purposes of this discussion regarding PLM, there are two kinds of information in business: a concrete type of information, in the form of documents or files, and a type of information that is used to sort information into categories. For example, a spreadsheet can be considered tangible information, a file. Simultaneously, another set of information related to the spreadsheet, called the file properties, is captured within the file describing the file content. This description includes such elements as the file name, the date it was created, and the name of the program required to open it.

The idea of making information (files and properties) accessible in a controlled manner is one of several primary goals of PLM. To achieve this, all relevant information is placed into a centralized location, a database. The file "properties" are used exclusively as the means to classify and locate information within a PLM system. A software program, such as Microsoft Word, used to create a file, generates its own set of properties. In PLM we expand the use of the "properties" concept to include additional categorical objects and attributes (the individual properties) focusing on the classification of files into various subgroups. Each subgroup and attribute is a searchable field. The term used in database terminology and more broadly PLM, to describe properties is "metadata" (data about data). For example, we might create a generic object that we call a "design document" in the database. We would then define the name attribute of the design document as "paint specification". We can find this document by searching the database for "design documents", or "paint", or "specification". This searchable classification system is just the beginning of PLM.

Establishing Relationships

Furthering the benefit of PLM, we broaden the ideas related to classification with the introduction of relationships between objects. Throughout a business, there are pieces of information everywhere. Each department, such as engineering design, sales, marketing, and sourcing, all have their required documents or data formats. When we begin to review how information flows through a business, it becomes apparent that many pieces of information are interdependent, but the relationship is not visible to the end user. As a function of PLM, we want to capture the relationships between business items, so we create software features that allow this to occur. Examples of relationship types would be, "Describes", "Attaches", "Is Supplied By", and "References". These relationship types are presented to the user in the form of selection menus during the creation of their business data, and the user can add the appropriate relationship to other data while they are creating or editing their own information.

Whenever we create a document in the context of one discipline such as engineering, another discipline such as sourcing can locate the engineering information in the PLM environment and build the correct relationship. For example, assume Design Engineering has designed a bolt, created a bolt drawing, and written a bolt specification. Design Engineering would create a Part object in the database, and attach the bolt drawing file to the bolt object by selecting an "Attaches" relationship. Similarly, the bolt specification could be attached to the bolt object by selecting the relationship "Describes". The sourcing department will want to find a supplier for this bolt, and they in turn will create and attach a bolt supplier object to the bolt object by selecting the relationship "Has supplier". This process continues as needed for the creation of entire projects and products. The end result is that, regardless of business discipline, you can find data that concerns you, and you can locate all of its related information.

Mapping Business Process (Workflow)

Workflow, the mapping of processes relating to the flow of information through a business is another core function of PLM. The addition of workflow in PLM adds value beyond relationships. Businesses have formal and informal procedures that they execute manually which can become the maps for the design of workflows. For example, new part design gets initiated in engineering and goes through to production release. In establishing a workflow, we describe the manual process in its full detail in the form of a flow chart, a graphical representation of the definition, analysis, and solution to a task(s). A PLM system will come equipped with a comprehensive tool to graphically build and apply logic to the workflow processes that are required to accomplish business tasks. Because a business may have many workflows, which can vary in complexity, workflow planning is a critical process requiring careful analysis.

Creating Rules

PLM is rules driven. What this means is that every object within the PLM database is controlled by access rules. Determining who has access to what data is an integral part of implementing a PLM system. PLM systems typically assign people (users?) into the categories of User, Group, and Role. For example, Joe User is in the "Group" called Sourcing, and has the "Role" of Buyer. The complexity of an organization and its business processes can determine the quantity of rules the PLM system must provide. People in a PLM system will also be defined as Authors and Consumers, those who can create and edit information, as opposed to those who may only view information. Similar to people access, work flows also are controlled by rules. Work flow rules specify actions required in order to move an object(s) through its specified process. This can be as simple as determining who needs to be notified for a review task, and as complex as executing a change of state (such as change pending to be released) on objects and moving them to new locations.

Shared Access

So far we have classified objects and made them searchable. We have built relationships so that we can assign them to objects and tie them together in arrangements that are correct for our business. We have built work flows to map out how information flows through our business, and finally we have created a dynamic rules system to be certain that we build, revise, and view our business objects in a controlled manner, thereby maintaining the integrity of our data. Together these features combine to form an environment that allows many users to interact with business information simultaneously in a controlled manner.


The concepts of PLM are not difficult to grasp, but careful planning is the most significant consideration required for a successful PLM implementation. The concepts of PLM have been generalized, as there are many areas in a PLM deployment that can be configured according to varieties of business, types of information, and exact processes needed for each. The goal of this article has been to convey basic concepts of PLM, to give a clearer understanding of its potential benefits in business, and to provide a sense of the effort needed to successfully implement even the most rudimentary aspects of PLM.

About the Author

Steven Rashkow is a process consultant for a major provider of PLM software tools and services. Steve has over twenty years of experience in engineering design, software support and consultation. He enjoys writing about technical topics for non-technical readers.