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.