Increasingly, variations of PLM definitions appear replacing the earlier Product Data Management (PDM). It is the nature of the software industry to replace acronyms regularly for marketing positioning purposes. Legitimate differences do abound. Bryan Stolle, CEO of Agile Software, once said: “Our fundamental problem with PLM as a term is that it is unfortunately synonymous with the second generation of product data management (PDM). So PLM is still very engineering-centric in terms of practice and application.” 

The current definitions of PLM from those software suppliers with roots in PDM and CAD imply total management of the product lifecycle is possible with their PLM products. For activities centered on Bill of Material management after release through obsolescence, however, some elements of Enterprise Resource Planning (ERP) systems are required. Several stages of a BOM may exist: As-Planned, As-Ordered, As-Built, As-Shipped, As-Maintained, to cite a few. Maintaining the accuracy of these stages requires extensive transaction processing for issuing with lot and serial recording. In addition, the system needs to account for in-process waivers and substitutions. Proper timing of changes is also a paramount consideration. 

In other words, the proper maintenance of these configuration stages requires both PLM and ERP working together. Product-centric information and capabilities of ERP systems must be included in a company’s definition of the product lifecycle for complete perspective. Why is this important? For one, prospective software buyers must understand what they are buying before they buy. An anonymous consultant emphasized the point: “Vendors take an expansive view of reality.”

Questions and comments: Contact us!

Oh, how many software buyers have endured the post-selection trauma of “It’s not what we thought we were getting, now we have to go back to the Executive Steering Committee for more money?” The cause is often software selection based on superficial demonstrations, fueled by emotion instead of logic, with eager buyers listening for what they want to hear instead of what they should hear. 

Out-of-the-Box (OOTB) is the popular mantra posed to prospective buyers. The appeal is fast implementation and rapid Return on Investment (ROI). There is no arguing the validity of achieving fast implementation. It fuels enthusiasm for the grueling work that may be necessary to gain the benefits. Another consideration is that software suppliers are claiming their software represents “best practices.” 

How should a company separate fact from fiction? One way is to insist on a Proof of Concept (POC) before signing a contract. Simply stated, a POC is exercising the software to validate whether the software operates as claimed. It is definitely more than a canned demonstration, which is usually presented at no cost to the prospect. However, a prospect company should not expect a supplier to participate in a free POC. 

A company project team needs to gain a complete perspective before presenting the final business case to an Executive Steering Committee. The recommended implementation plan must be realistic for the team to retain management’s confidence and support. The differences between fast installation of the software and the expected time-to-benefit must be clearly understood to avoid hindsight disappointment. For instance, if there is a great deal of data cleanup and BOM restructuring, time-to-benefit will be much more than just time-to-install. Software suppliers often dance around this implementation reality. 

The bottom line here is that OOTB is a two-edge sword: great potential with some risks. A POC is a prudent step in software evaluation.

Questions and comments: Contact us!