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.