PLM Design Patterns: A better PLM for less than half the price

18/12/2014 13:15
When an organization contemplates the task of transitioning from existing data management systems to a PLM methodology they often request support from PLM consultants to define  supporting procedures  for their specific business process. Using PLM best practices, often industry specific, the consultants offer a strategy to transition to new procedures from the legacy procedures. PLM consultants then figure out together with the process stakeholder the organizational needs and design PLM procedures based on today's procedures. They recommend a PLM system, which is configured to support the PLM procedure execution. From a design process point of view it's like going to a cabinetmaker and asking for the construction of a table.

Reason for Change

The cabinetmaker will ask his client's needs (table in the kitchen to prepare meals, table for playing Ping-Pong) and will develop a drawing. After going through several refinement loops the cabinetmaker will produce and then deliver the table. A client could quickly get a much cheaper table, if he went to a shop specializing in tables and select one specific to his needs: kitchen table, Ping-Pong table, etc.. Another advantage in seeing a variety of tables is that the client would see tables, fulfilling needs he never was aware of, for example a Ping-Pong table with a safe and easy-to-use folding mechanism.
In the process of transitioning to a PLM system, organizations consume a great deal of time and resources developing their own PLM procedures from scratch. Very often they become stuck in their current practice paradigm without developing the full potential of the PLM methodology. Even when it is very clear that the specific businesses process of an organization is the starting point for the development of specific procedures, it would be nice to have a set of generic PLM design patterns (for example for item approval, engineering change, costing) related to standard business process patterns (for example Engineer to Order (ETO)) using PLM tools. Then an organization could align PLM design patterns having the best fit for the organization, it could develop a plan and implement a PLM methodology supporting the full potential of the new practice.

Example 1

For demonstration purpose I chose a first simple example for a pattern, which is anyhow somehow implemented in most of the PLM systems again and again. The pattern is classified as a general pattern.
Problem: In a PLM system users manage information related to items in one repository. It is essential for the PLM system usage, that all users know, when an item is finalized and does not change any longer. Only if the item is in a frozen state, the users are sure about the content and can use it as input for their task execution.
Solution: The "Item Documentation" pattern checks rules prior to the status change (for example formatting rules of a drawing) and sets the status to . Depending on the item type (or following other rules) the pattern may manage a technical approval following the 4 eyes principle. After the status change modifications of the item are only possible in revising it.
For the specific implementation of the pattern the organization has to decide the following:
  • Status names: "Working" or no status, "Finalized" and/or "Approved", "Rework", which must fit in the overall definition of status of items
  • Rules for status change (for example correctness of a drawing, all related children or secondary items have to have at least the status "Finalized"
  • Decision about rules for mandatory item reviews
  • Reviewer's access right to modify and then approve the item
  • etc.
Related to a pattern there may be recommendations for example:
  • Implement rule for status change: all related children or secondary items must have at least the status "Finalized".
  • The reviewer does not have the right to modify the item, but has to reject it. The item owner reworks the item.
In looking to the example first you see the general PLM design problem and its general solution. Business should not care about, but PLM theorists. Then you see business related stuff. Business has to decide about a predefined set of implementation details required to execute their specific business process using the pattern. 

General PLM Design Patterns

As far as I see there are 4 general PLM design patterns, which could be used as building blocks to derive business process specific supporting procedures.

Item Documentation

(the one I used as an example)
  • Checks an item regarding following rules and assigns a status indicating, that the item (and its related dependent content) will no longer change. After a status change a user can only revise the item. Based on rules a review is supported (4 eyes principle).

Task Execution

  • Formalizes the task execution for single tasks and sequences of tasks in schedules.
  • Gets repetitive tasks executed in following template schedules. Each task may have deliverables and targets for result item linkage: all required information to perform the task is related to it.

Decision Implementation

  • Controls the implementation of a product increment consisting of a set of new and/or changed items.
  • Documents its intent.
  • Supports planning and execution of implementation events regarding sequence, resources used and effectivities. A "Product Owner" manages the product increment implementations.

Business Decision

  • Collects impacted new or marked up items to come to a business decision about a proposed product increment. A "Moderator" manages the decision making regarding proposed product increments.
  • Supports the analysis of its business impact and the technical feasibility.
  • Documents the business decision. 
(People familiar with CMII will see expanded elements of the change management process.)

Example 2

To show how to use the general PLM design patterns as building blocks to derive business process specific supporting procedures I would like to use in a second example a quotation process in an Engineer to Order (ETO) business process. I use this quotation process, because it is - from a structural point of view - very similar in a lot of organizations and you can read it as a draft of a specific procedure pattern.
The tasks are the following:
  1. Implement customer requirements
  2. Make engineering assumptions
  3. Make manufacturing assumptions
  4. Perform cost calculation
  5. Write business case
  6. Create quotation
  7. Approve quotation
  8. Implement customer award
  9. Set up project
Tasks 1 to 6 are preparations to come to a business decision. Task 8 and 9 are implementation activities of the decision and the baseline for product development.
In most of the organizations the quotation process is a structured process. You will find procedures to come to a costing sheet, which you could manage in PLM in using schedule templates. After getting the costs, sales or controlling writes a business case resulting in a quote. Depending on the size of the business the quote needs a business approval. As soon as the organization gets the customer award, again a sequence of events is launched.
Each task results in an item containing the requested output, for example engineering and manufacturing assumptions, cost sheets etc., which may need a technical approval or at least a status change telling the item is finalized. The implemented items are used for the next task (for example engineering and manufacturing assumptions used for costing).
Following the PLM design patterns a "Moderator" is coordinating the business decision activities and a "Product Owner" takes care of the proper implementation of the award and the project setup.


In general you can setup all required supporting procedures in using the PLM design patterns. Even for specific supporting procedures of a business process pattern like Engineer to Order (ETO) you can derive patterns, which consists of a framework of general PLM design patterns and are adapted to the specific business needs. There is enough freedom to derive based on these patterns supporting procedures to fulfill specific business needs.
Based on PLM design patterns PLM theorists derive supporting procedure patterns for business process patterns. They propose organizational changes for execution of the supporting procedure patterns as far as they are better adapted to PLM inherent requirements. They initiate the reduction of PLM system complexity in proposing optimizations to essential features required to run the PLM design patterns.
Business selects out of a supporting procedure catalog the ones fitting to their specific business and adapts them to their specific needs.


If some organizations would have implemented supporting procedures based on patterns already, then consultants in introducing PLM to an organization could refer to "state of the art" implementation examples of these organizations. The target is to convince an organization, that the decision for a new practice requesting organizational change is required and works. Only then the organization can enable the full potential of the PLM methodology without remaining stuck in the current practice.
By evaluating supporting procedure patterns related to business process patterns, managers of organizations could assess the impact of the change to their department and envision the new practice in their department. This allows proper action planning and execution transitioning from the current practice to the new practice.
Based on supporting procedure patterns PLM trainers could develop training units for procedure and tool training, which could be re-used in many organizations. Using their experience and going through continuous improvement cycles they could develop proper training plans. Consequently a user could learn the new PLM practice faster and easier.


Now instead of inventing a Ping-Pong table "from scratch" with a cabinetmaker we can make a clear decision based on all the options available, fulfilling and probably exceeding our originally perceived needs (with a safe and easy-to-use folding mechanism). And we can afford it, because a stock table is cheaper than a custom built one.
The time saved in avoiding the endless discussions and continual redesign of processes because of paradigm paralysis, based on current methods, could be better used in a well-planned, strategic deployment of the new processes leading to an improved business solution.
Automated procedures requiring only a few clicks to enter our decisions could be available in modular form. Because the procedures are based on patterns, software vendors can deliver specific solutions more affordably because they are reused from many organizations.
The management of change will be easier than today because a simple model of the proposed final solution can be presented to colleagues convincing them, because they see, that they get, what they really need.
For our management it is good news as well: achieving a better PLM for less than half the price.

The ideas presented here are the result of discussions with Felix Nyffenegger (Prof. for CAx, PLM and Product Design, University of Applied Sciences Rapperswil (HSR)) and inspired by: Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994-10-31). Design Patterns: Elements of Reusable Object-Oriented Software. Pearson Education.