What may provide value to one specific end user, stakeholder group or function may not provide the same value to another. One universal ‘one-size-fits-all‘ solution does not exist or may not be perceived in the same way; therefore, it is fair to say that:
Value is expressed and measured in the eye of the beholder – actually, it is rarely constrained solely by time or cost.
Effective value management requires an understanding of what is valuable to one or a group of stakeholders, and the activities to create value should be focused on successfully delivering the anticipated value. In this context, value can have many different meanings.
For example: creating a report that only finance uses constitutes little or no value to a group of engineers – even if they are working on cost optimisation. This is because they might not have the same requirement for financial information compared to what accountants need, or they probably use different data points and sources to gather the cost information that they require. To create value for both stakeholder groups, it will be important to understand the basic input / output model, what information is required, when, for what purpose, how it is consumed and transformed, with which dependencies and constraints. It might be necessary to understand what the two groups are using, should it be two different views of the same data, at different points in time, what are the business rules which govern this data, etc.
Having said that, value can easily be converted into quantifiable metrics which can be contrasted and compared; as such:
Value = Benefits / Cost
The other key element relates to boundary conditions [i.e. the surrounding context]: what certain vendor, industry, analyst or even internal practices and standards may deliver is not necessarily contributing to perceived value to the end user.
For example: improving the creation time of a report from 1 day to 1 minute execution time, can prove to be a big saving in time if this report is used to validate certain Bill of Materials (BoM) changes. However, such improvement might have limited value if this report is only needed once a month or it does not have specific urgency requirement in terms of how and when it is executed. Or perhaps, the benefit from this improvement might be significant for accountants who need to make regular business case simulation, while engineers are more than happy to wait a day to perform whatever impact assessment this report provide them with (…).
One can also link to what value technology might bring to certain operations or process. Software are designed to add value and augment people’s ability to compute things. Product Lifecycle Management (PLM) or Enterprise Resource Planning (ERP) solutions are to bring value by providing tools to the end users in order to achieve a set of business benefits, such as:
- Do things faster.
- Do more with less or more with the same (operational efficiency).
- Learn, re-use data and share knowledge.
- Automate activities, reduce essential non value-added activities, remove non value-added ones.
- Simplify things, or manage more effectively complex things.
- Optimise resources and contribute towards the circular economy (which obviously links to one or more of the above).
It is therefore important that technologies continue to be used as enablers and sources of value. Optimising their implementation and maintenance needs to be considered in parallel to continuously assessing the benefits that they bring to the business. What software editors ‘throw over the wall’ in an ‘out of the box’ (OOTB) bundle may be completely off the mark if it is too generic or too broad to help end users realise value or benefit from technology. The value of PLM products relates mostly to how they are implemented, deployed and maintained, rather than what is in the box or vanilla software. Hence, performing OOTB PLM technology assessment have limited value when running digitalisation or toolset selection projects. Once gain, value will be derived from contextual implementation, deployment and maintenance, while benefits are realised from usage.
Good technology can be badly implemented or deployed, and bring no or limited value, while certain group of users might still be able to recover some benefits. It’s common sense, but it is worthwhile reminding oneself that:
- Value is in the mind of a specific organisation or set of stakeholders.
- Value can’t be separated from end-usage context (user experience).
- Value is always relative to alternatives.
- Value should be grounded in customer satisfaction.
On one hand, benefits exist only with a particular user or set of users in a particular business setting. On another hand, if there is no specific user and business setting, one cannot promote value. Value creation, value maximisation. value drivers: these are all catchy expressions being utilised in businesses. Each organisation is unique and must develop its own definition of PLM value by reconciling user expectations. What is value from PLM? This is difficult to define because what is valuable to one company may be worthless to another. The stakeholder theory relates that ‘value is in the eye of the beholder; and each stakeholder perceive it differently based on context‘.
What are your thoughts?
This post was originally published on LinkedIn on 2 September 2016.
About the Author
