A PLM Christmas List

In keeping with the spirit of the season, why not set out a wish list for PLM? If we sent it off to the North Pole, perhaps some of them would come to fruition.

Before we define the list, let’s set out a few objectives of PLM so that we clearly understand what we are trying to achieve before we wish for our imagined gifts. The following is an incomplete list but sometimes these objectives are lost in the daily struggle for survival lost in the technology:

1. Store data in a secure and controlled manner
2. Enable collaboration
3. Pass unambiguous and correct information to a manufacturing process

Based on the above, here is a list of PLM moves that many organizations could make with small investment and good returns:

• Free 3D viewers – In the spirit of collaborative design, it is strange how many organizations have a PLM system that only allows CAD designers to view 3D geometry. This leads to scenarios were other participants in the design process have to find a cooperative CAD designer to interrupt his current task and “pull up the geometry.” Long discussions can then ensue around design issues exposed by the geometry. Is this productive? – No. Many of the PLM vendors provide free 3D viewers that can be deployed to all participants in the design process. Some infrastructure may be required to create the correct file formats; but a for a small investment, CAD designers can focus uninterrupted on their business. Imagine the productivity gains! 

•  Ban Excel BOMS – Central to any organization that manufactures tangible goods is a Bill of Material. Without this information, nothing would leave the factory. In addition, BOM information usually feeds multiple downstream processes from procurement to service to ERP systems. So, why keep this vital information in a general software tool like Excel that is not designed to perform this function? In addition, the security and access controls that can be achieved are definitely deficient. For a modest investment, one can install a PLM system that has a robust and targeted BOM system designed to deliver correct and complete information to an organization.

• Close down FTP sites – There is no denying FTP is a very useful piece of software that has multiple applications, but it requires multiple manual interventions to be successful and can potentially be a security risk. If you drilled into any organization, there would probably be a few FTE equivalents of time spent using FTP. Modern PLM systems can offer many alternatives to this method of data transfer: collaboration servers, web portals, cache systems, or automated mailboxes are some examples. Looking for a good ROI opportunity? – close your FTP site.

• Automate PLM to ERP transfer – Typically, a BOM and related information is created in the PLM environment and then transferred to an ERP system for manufacture. Odds are that this transfer is entirely manual or, if partially automated, requires significant manual intervention. All manual interventions are prone to error and manufacturing errors are always costly. So why not put some effort into automating this crucial organizational interface?

Are there additional items that could be added to the wish list? Have a look in your organization and the list will grow.

The Version Revision Conundrum

You have a PLM system. Fundamental to this system is the concept of a version and a revision. However, it is probably the most misunderstood process in the PLM realm. Also these terms mean a wide variety of things to different people and are often used interchangeably and without consistency.

For the purposes of the rest of this piece, we will use the following definitions:

Version – represents a small incremental change in the design that would be saved in the database. Versions are not necessarily saved permanently beyond a revision.

Revision – represents a significant event in the design process and is saved permanently in the database for reference throughout the design process.

Diagrammatically, the difference is illustrated by the following diagram.

It is often confusing to talk to about this subject because the terms are used interchangeably. Also, the clear distinction between a version and a revision is not clearly understood; even to the extent that participants think that they are the same thing. Because of this, it is important that any organization with a PLM system ensure that all the participants clearly understand the definition and what the difference is.

In a collaborative PLM environment, participants are very dependent on viewing or using data generated by other participants. For example, a headlamp engineer needs the position of locating holes in the sheet metal to be able to design his locating pins (if this is the order of precedence). In this scenario, the headlamp engineer will say “I need the latest sheet metal to begin my design.” This statement is common in design and engineering teams. However, it is inherently imprecise because it begs the question: Do you need the latest version or latest revision?

Based on the definition given earlier, what is really required is the latest revision. A version is work in progress and could be incomplete or half done because the responsible author may be in the middle of a redesign or new concept. For this reason, a version should not be visible to the larger organization, only revisions should be accessible as they satisfy the definition of “best so far.” This concept is very difficult to get across to a lot of people and represents the conundrum referred to in the title. It takes some courage to work on data that will change sometime in the future but this is absolutely required in an efficient design process.

The version revision conundrum also leads to some interesting human psychology. Consider any collaborative design environment where multiple participants have to submit data into a PLM system to progress a large project. It is important in these environments that all participants follow the mantra of “publish early, publish often” or in the nomenclature of this piece: create many revisions. This is based on the principle that incomplete or slightly inaccurate data is better than no data at all.

However, process managers often put in systems that highlight inaccuracies or incomplete data, effectively punishing early publishers. So data authors hold back and only create revisions when they are certain of accuracy, late in the process. This is counterproductive.

So, pay attention to the version revision conundrum; clear definitions and policies of this simple issue can greatly improve a PLM process.

Tata Technologies PLM internet page.