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.

Choosing PLM Technology

So your company has embarked on the PLM journey. Strategy is agreed, budget is approved, the preliminary plan for execution is in place and Return on Investment (ROI) has been computed.

The next step in the process is choosing a software suite and an associated vendor. Unfortunately, the nature of software is such that one cannot mix and match programs or modules to suit specific requirements; the major vendors design their solutions is such a way that organizations are locked into a specific monolithic offering. The choice of vendor, then, has long term ramifications, and, on the face of it appears to be a momentous decision.

So, how does one choose a PLM technology vendor? For the purposes of answering, let us submit two potential techniques:

1. Undertake a comprehensive study to evaluate the merits of each vendor's solution against requirements, conduct benchmarks and produce recommendations (The Bake Off)
2. Meet in the main boardroom of the company, ensure attendance of auditors and all interested parties and toss a coin to decide which vendor to choose (The Coin Toss)

Before debating the merits and demerits of each technique, it is instructive to outline a methodology for the bake off option. The high level steps required to conduct a study are as follows:

1. Outline business imperatives and goals (e.g. global engineering)
2. Identify the PLM processes that have to be put in place or facilitated to meet these goals (e.g. extended design reviews)
3. Create use cases to illustrate the processes (e.g. ability to load complete product into webex session and have geographically dispersed teams critique)
4. Evaluate each technology against the use case and score its capability to support the use case (e.g. how long does it take to load a product into a review session)
5. Total up all the scores and make a recommendation.

Clearly the Bake Off would be the conventional business approach. It offers the advantages of rigor, objectivity and a comprehensive approach. By following the evaluation methodology, an organization is guaranteed of having a technology that supports its needs.

So why even consider the Coin Toss? Any business person worth his salt would recoil at the thought of employing such a sloppy and unscientific method. But before dismissing this out of hand, consider a few items. Firstly, technology changes at an alarming pace and what is good today in one vendors solution will be outpaced by next year’s release. Secondly, the tough part of PLM implementations is managing organizational change and this has nothing to do with technology. Thirdly, agonizing over decisions is probably worse than making a snap decision – fortune favors the bold.

So consider the Coin Toss or a at least a compressed Bake Off; it can certainly save time and maybe allow an organization to leap ahead of its competition.

Who invented PLM?

In keeping with the past dimension of this blog’s mission, perhaps it is important to ask the question: who invented Product Lifecycle Management (PLM)?

On the face of it, this may seem a frivolous question, but if it is legitimate, the answer does have implications for the usage in the industry. Consider a quotation on this question by Carl Bass of Autodesk (search YouTube for “Carl Bass anti-PLM rap”) in which he states that the only companies with a PLM problem are Dassault Systèmes, PTC and UGS (now Siemens PLM).

So, this leads one to pay more attention to the question and formulate two potential answers:

1. PLM was invented by the vendors as a strategy to scare manufacturing customers into buying expensive software (push model)
   
2. PLM was an industry competitive imperative and software vendors are fulfilling a genuine need (pull model)

If your preference is for the push model, then organizations should be looking seriously at their so-called “PLM strategy” and questioning what they really need. Does the ability to tie together all product data from conception to manufacture actually improve business? Or is it better to deploy targeted software at strategic points in the design process where it can be clearly demonstrated that this brings efficiencies?

There are a couple of proof points that tend to answer the questions above in favor of the push model. Firstly, many large, successful companies who are considered industry leaders often have a patchwork of software solutions that don’t actually tie product data together. If it was a business imperative, this situation would not exist. Secondly, it is well known that some PLM implementations do not succeed, but do not necessarily result in taking the company out of business. Finally, PLM software vendors will often have a core product that generates most of their profits and the rest of their “strategic” offerings are not widely adopted.

Alternatively, if your preference is for the pull model, then organizations best be focused on a PLM strategy or else they will be out of business. There is evidence that supports this view. Firstly, organizations have increased productivity dramatically, and there is an explosion of consumer choices for physical products. Secondly, consider the automobile of today compared to 20 years ago and compare the level of sophistication. Finally, one can look at the revenue growth of PLM software vendors and extrapolate this into a real need by industry.

Perhaps the pragmatic answer lies somewhere in between the two extremes. PLM as conceived by the strategists is actually only a vision and by definition unobtainable. So while it is important to keep it in mind, companies are better served by critically examining processes and implementing technology where it makes sense for their business.