I wrote this blog back in 2010, and invite your comments about how pricing has changed (or not) over the past 6 years.

A blog written by Oleg Shilovitsky titled "How to Manage ECO's without paying $1500 per seat?" triggered an analysis of current Product Life Cycle Management (PLM) pricing models in my mind. Companies like Oracle with Agile PLM and PTC with Windchill and even ERP players like SAP dominate this industry with a cost per client model. Oleg's point was to take a fresh look at today's technology and suggest potential ways to address market needs. This blog reminded me of the numerous clients in the past and present who have struggled with traditional pricing models based on their usage of PLM. I have often been struck how we have a "one size fits all" mindset about PLM software pricing. There have been some trends recently that are starting to erode traditional vendor pricing models such as "Software as a Service" or SaaS from Arena and the pseudo shareware/open source model from Aras. Both of these models lend themselves to a wider propagation of clients for PLM which makes the solution more viable and valuable. Having a PLM system with limited access really doesn't work very well. Even Oracle has started to recognize the problem and now offers enterprise pricing which is basically an "all you can eat" plan for bigger customers. The bottom line is a single price per client model doesn't really fly in today's increasingly complex product development world. Even designating light or heavy seats or supplier licenses doesn't necessarily resolve the dynamic nature of product development. This blog will analyze the history of PLM and pricing models to determine how we arrived at this point and what could be done to adjust PLM pricing models to track better to how customers should be using the application.

As a cautionary tale we can look back several years to the web and the use of database technology with web sites. At that time Oracle was as they still are today a dominant player in database technology. Oracle's perspective of clients accessing data via the web did not differ much from a tradition client. As far as Oracle was concerned if you're hitting the database Oracle should get paid. Due to the potential volume of clients, this created big problems for a lot of companies. Theoretically they could have been on the hook to Oracle for millions of dollars. This situation drove products like OpenSQL and Coldfusion to the market. These products were not as robust as Oracle but based on the type of usage and the economics a lot of companies flocked to these types of tools and Oracle lost significant marketshare. Ultimately I think Oracle recognized the situation and adjusted but it would have been better for everyone if they had been out front of this instead of in a reactive mode.

History is starting to repeat itself as the product development environment becomes more widespread and companies look to take advantage of Internet based technologies to improve collaboration and leverage resources. Crowdsourcing, social product development, and outsourcing all lend themselves to a broader adoption of PLM. Oracle still sits in the middle of everything given the fact that most PLM Vendors use Oracle as their database. The ones that don't use Oracle most likely use Microsoft's SQL Server which is also a per use database so it really doesn't matter too much. The point is that having a per client model for PLM when the types of clients are varied and the duration someone may be a client varies creates some real challenges for companies leveraging the tool. Some companies respond by limiting access to the PLM and creating secondary systems that utilize extracted content like PDFs and spreadsheets or a PLM output called PDX. Once this data is outside the PLM it becomes impossible to trace and you lose a lot of the value of PLM. The problem is companies can't afford to purchase clients for every vendor or customer. Additionally, given the fact that some of these users are just consuming the data and are not permanent users it doesn't really make sense to have to deal with the overhead most systems require to set them up like a traditional client.

Fortunately, today almost all PLM systems use a thin client so IT issues are not the problem. It comes down to the architecture of the access control logic and the user creation tools and the cost. All of the elements exist in most systems to create ad hoc users and assign permissions. Agile PLM definitely could support it and at least ProjectLink from PTC has the capability but I suspect it could be adapted to Windchill as a whole if PTC were so inclined. On Demand systems charge per month based on the created logins but the problem is you are charged the same whether someone uses the system for one day or the entire month. If the user is created, you are charged. It also doesn't matter whether they are creating information or just looking so SaaS doesn't really address the issue. Open Source still has a database charge associated with it so while it might be less expensive you still have a uniform cost per user which doesn't really reflect the true variety of use cases.

The other problem is that you need to be able to predict cost both for the vendor and the client. Open ended usage models while probably fair creates issues for both parties. Customers need to control cost and Vendors need to be able to predict revenue. The other challenge is if you create a model with a bunch of tiered roles it becomes difficult to sell and purchase. This fact is reflected in the basic nature of most PLM vendor's products. Most have experimented with different types of clients but in the end it becomes a headache to sell and to administer. This problem warrants further consideration but I don't think breaking up functions into discrete products is the answer. You still want the overarching structure of PLM to control the flow of information. In fact, you need a model that encourages wide adoption of PLM because this increases the value of the product. I would propose a per user model for internal creators of information, like CAD users or Configuration Management types. For external consumer types with limited input you could price it in lots of 20 or 50 or 100 depending on what makes sense and price it in a way that is viable. I know some vendors have supplier licenses that are sort of like this but it should be broader (I suspect this type of license gets used for other functions).

I am sure there are other potential ways to address the issue but the point I am trying to bring home is that the nature of product development is changing and a per use model discourages the adoption of PLM technology. This dynamic limits the value that PLM can provide and if PLM vendors ultimately want to tap the value that their solutions provide they need to break the mold and come up with new ways for companies to adopt their technologies in a broader context.

[Edit: repost from 2010]