Is the casual or “read-only” user in PLM an outdated concept?
From my discussions with industry analysts, the value of a full-blown PLM user is approximately $80 per month, or $960 per year. My experience is that you are being charged significantly more, but given the complicated pricing models many vendors use, it is almost impossible to figure out what you are actually paying for.
A recent prospect wanted to reduce their license costs and said, "Nearly 50% of our expected productive users are rarely using the system. They would access the system once in a month or rarely. Can you provide the corresponding subscription model?"
Another colleague similarly had his eye on the license costs. "30% of our user base will access the system as read-only users. They are expected to get the information from the system, but not leave any trace of their actions. How can you bring down your license costs by incorporating ‘read-only’ users who do not ‘author’ anything in the platform PLM system we want to establish?"
The percentages may vary, but given the vendors they have dealt with in the past, I totally understand that they are doing their due diligence. In my many years of PLM engagements on both sides, I have been involved in countless discussions like this with concurrent and named user perpetual licensing schemes, tokens, various bundles, and yes, role-based pricing. All different ways to slice and dice the user community to get the best deal. But do we?
In a world defined by growing connectivity, more data, and growing complexity, is it really a good thing to save a couple of dollars by limiting certain users from collaborating with, and having access to, product data? If they see a problem, they can email someone in engineering. Not a big deal, right?
But in the long run, it will impact the efficiency of your team. Networked and collaborative work, with stakeholders exchanging information is going to be the mantra to achieve a competitive advantage over your market peers. This new technology not only enables the “Connected Product,” but also the "Connected Enterprise.” Unless the front-loading role of Requirements Definition is brought into the loop with downstream processes (e.g., results of an Engineering Simulation), neither the Connected Product nor the Connected Enterprise will be realized.
Limiting people and teams’ access to information will encourage the development of "underground" tools that are convenient in the moment, but despite appearances, will hamper efficiency. This only adds to organizational silos, and makes it harder for data to travel, across an array of disparate legacy applications on rigid technology stacks. The dependencies and lack of up-to-date information is also a contributing factor in the cost of quality of the product being developed. Pricing software that segments different types of roles at a given point in time is actually counterproductive.
To be transparent, the Aras pricing is on our website and we understand not everyone will be accessing the data full-time, which is factored in: https://www.aras.com/en/services/subscription-pricing.
With increasing "democratization" of product information, one success factor will be how you involve expertise in the product development chain. Roles like marketing and service, which were once considered ancillary roles, are becoming more and more involved to reduce feedback loops and late lessons learned from market.
Yes, access control is critical to IP protection, but this should not be confused with limiting casual users access to data. Many of them are casual users because of antiquated legacy applications and processes. While data can be changed by a given role (i.e. no one can change the part number), limiting such roles to "read-only" will keep them from providing timely feedback to a stream lined digital thread.
In today’s increasingly connected world, we should not consider certain roles as non-contributing. That is outdated thinking. Instead, we should strive to increase their ability to collaborate with the right data at the right time with right access permissions.