Welcome to this week's TBT blog post,
continuing our series on the PLM Vendor Code of Conduct,
originally published in 2011.

I must admit growing up I was quite the Sting fan. I had two chances to see him live. First in college when he was still with the Police but I couldn't find anyone who wanted to go with me and then later my wife actually bought tickets to his concert as a surprise for me but he canceled. I even enjoyed his brief acting career as the bellboy in Quadrophenia and as the evil prince in Dune. Apparently, some PLM vendors are more inclined to listen to the verse from the song "if you want to keep something precious you got to lock it up" rather than the title. Last week I wrote about the first PLM Code of Conduct Principle: Leave No Man Behind. I received several responses, including one from the Virtual Dutchman, Jos Voskuil, a seasoned PLM consultant and blogger. To paraphrase, Jos was somewhat pessimistic about the prospect of PLM vendors adhering to a code of conduct given how much leverage they have over customers. He was particularly concerned about what he called "vendor lock-in". I too think this is a big problem for companies using Product Lifecycle Management (PLM) software. Once you have chosen to use one PLM solution, it can be very difficult to move off this platform and onto another. Moreover, beyond just trying to move from one system to another, it can be very difficult to get information out of a PLM solution to use in other environments. This state of affairs leads to the PLM Vendor Code of Conduct Principle 2- If You Love Somebody Set Them Free.

I do understand that PLM vendors operate as for-profit enterprises and want to do everything in their power to maintain their market share and maximize profitability. As a small business, we have similar goals. However, using artificial means to hold your customer hostage and prevent other companies from competing is probably not the best way to go about things. The ultimate arbiter for whether a company continues to do business with you should be the value that is generated from the products or services you provide. PLM vendors should be committed to enhancing their products to maintain their competitive advantage over their rivals. By working with their clients to understand what they need to be successful, PLM vendors can create a relationship built on loyalty and value. I think this better serves the vendor and the customer. Creating proprietary schemas and restricting the ability to output information to prevent clients from leveraging other technology is not the path to success. Additionally, PLM is typically one piece of a larger enterprise infrastructure and it is important that the content and capability of the PLM application is accessible by other enterprise applications like ERP and CRM. Most PLM systems are becoming more open as the market demands it but there are still vestiges of control where certain types of information are restricted or vendors demand clients purchase expensive access licenses to be able to use their own information outside of the PLM system. Some PLM vendors will restrict third party access to their platform to discourage competition and even cooperation which is a shortsighted strategy that will leave them pigeonholed as a niche application as the use cases for PLM continue to expand.

CAD-based PLM vendors are particularly aggressive at attempting to parlay their engineering foothold into an enterprise PLM presence. Siemens, Dassault and PTC make it very difficult for other PLM tools to manage their data. As I mentioned in an earlier blog, "Why Can't We All Just Get Along", some vendors have actually resorted to lawsuits to prevent other PLM vendors from trying to manage their data. I think it would behoove all of these vendors to call a truce, at least among themselves, if not other non-CAD-based PLM vendors and let their clients choose what PLM solutions best suit their needs. I would think that even without artificial restrictions, these vendors should excel at managing their own CAD information and shouldn't need to resort to legal and technical maneuvers to hinder competition. In fact, I would expect healthy competition would push these vendors further to offer even better solutions to their clients to differentiate themselves. The reality with acquisitions and mergers is companies will most likely own multiple CAD tools and will need to find some common ground to manage the information. The overall health and viability of PLM would be positively impacted if there were more standards and cooperation among vendors.

The bottom line is that typically the best products will win out and the solution that delivers value and addresses the market's needs is the ultimate goal. If CAD data management becomes too problematic or hinders the enterprise in its adoption of productivity-enhancing technology, companies will figure out a way to move forward without it. Many companies today have done quite well with PLM without CAD and based on my experience, I would say there are more companies out there using PLM without CAD than with it. By this I mean companies that are truly managing bills of material (BOMs) and changes via PLM systems and then driving this information into ERP tools more often than not use other system to manage their CAD data. I think that making it easier to manage various types of CAD data in one system would encourage more companies to integrate CAD data management into their PLM environment. I do realize opening up PLM systems and making it easier to move data in and out and to manage CAD data will erode some of the artificial advantages some vendors enjoy today, but it will also drive PLM vendors to offer better solutions across the board to keep their customers happy and productive; this is a far better business model for all. If the PLM customer base is successful, they will generate more revenue and grow faster and can invest far more money into their product development infrastructure. So, by "setting these companies free", PLM vendors will ultimately drive more revenue to their own bottom lines.