Why is it so difficult to measure PLM success?

Everybody talks about measuring the result of their PLM initiative but nobody does anything! This is of course exaggerated, but in general, there are too few companies knowing what PLM has given them (or cost them). Many companies do not really know if
the PLM project is a success or not. The result is that management only cares about PLM once a year when they see the cost in the budget. Why is it so and what can be done about it?

There are few numbers available

In my 18 years in the PLM business, I have seen very few monetary values of PLM achievements. Of course, the PLM solution providers have their slide decks with generic numbers and maybe a few concrete examples they use over and over again. It is difficult to use those numbers directly in another company. The KPI’s can be reused, but you have to have your own numbers to be able to trust them.

This quote from Accenture is quite illustrating:

“The CEO came to the department and asked: I have spent 100 million euros on the implementation – what are the business results? They couldn't give him a proper answer.”

Unfortunately, this CEO is not alone.

PLM vendors have Excel sheets where you fill in a predefined list of possible improvements. By magic, you get a huge number that nobody (except the PLM sales guy) trusts.

We use the lack of numbers also as an excuse. The others do not have the numbers so I will manage without them as well.

The engineer’s flaws

I think that one reason for this lack of measures is that it is mostly engineers (as me) which care highly about PLM. In addition, engineers have two flaws in this context:

• We are satisfied when things work (then we move to the next task)
• We want answers to be un-ambiguous

We engineers want efficient and consistent workflows and a CAD integration that works. Yes, it would be nice to know what value that brings, but what we really care about is getting it to work. We are satisfied when it works and we have a feeling that this is good for the company. We do not see the importance of measuring what value it brings.

Engineers also like things to be accurate and without uncertainty. Calculating a business benefit and ROI is not an exact science, thus we do not trust it and do not do it unless we have to. If we are forced to, we tend to look only at the benefits that we can measure and get an accurate number. E.g. number of documents stored, ECO throughput time etc. Such numbers can show how PLM progresses, but it does not tell so much about actual business value. We miss the big picture and do not put areas that maybe are more important but harder to measure. E.g. global collaboration enabling two sites to share resources and work together or increased service margins due to better access to information.

Do not know how to do it

Given the engineering background, we feel it is hard identifying what to measure and defining calculation methods that we trust. Many PLM people agree that it would be good to have these values, but do not know where to begin and give up before starting. Many PLM people think they lack the financial tools and understanding to attack this beast in a proper way. They focus instead on the things they know: Getting a good configuration management process in place.

Hard to measure

Yes, it can be hard to measure business benefits and you cannot always trust the numbers 100%. It is easier to measure reduced volume of products on storage or faster production processes than improved product information quality. ERP focus on physical products and things you have while PLM focus on virtual products and things you do not have. This is still no excuse. We have to start showing the value of PLM or it will continue to be a product development support tool or even just a CAD management tool.

A typical excuse is also that we lack the numbers from before PLM came in and do not have anything to compare with. That is the same as saying that PLM is cemented and will not improve beyond the initial improvement. If that is true, the management is right in not investing more in PLM.

Why do you need to measure PLM success?

PLM people always complain that ERP gets all the attention and PLM at the best gets the leftovers when it comes to management attention and budget. The typical complaint is that management (thus the budget owners) do not understand PLM and its importance. We can only blame ourselves. We are unable to talk to the management in a language they understand. My experience is that some ERP business values also can be tough to calculate, but the ERP guys and girls are much better at talking a language the management understands – business benefits, calculated savings, earnings and cost. If PLM people were able to do the same, PLM would be in a much better position.

You cannot expect management attention and large investments or operations budgets for PLM (at least not anymore) if you cannot show what PLM brings and an ROI that management trusts. A trend is that PLM investment decisions are done on C-level.

Another thing is that measures in itself give improvements as you put attention on the area and follow the progress.

What can you do?

We also touched this in a previous blog where we looked at data from PLM related processes with a method improvement focus. Here is another interesting blog from Melanie Manning about how to create effective metrics.

First, you have to agree on what to measure. Tie PLM to the business strategy. What is important for management? Where will your business go in the next 2 to 5 years? Identify the areas where PLM contribute to the overall business strategy. PLM can be an enabler for changing things. Identify KPI’s related to the business strategy.

Start thinking like the financial guys. Act like a business analyst. Is there is a business improvement somewhere supported by PLM? How can you measure it? Do not only focus on the bottom-up simple stuff. Look at the big picture and involve the business and management. Think about short-term, long-term, tangibles, intangibles, cost reduction and revenue increase. As a common exercise, you can find improvement areas. Get business and management to give their thoughts on possible improvements. If they give the numbers, they are more likely to trust the result.

Some examples are: Product introductions per engineering hour, degree of collaboration, engineering efficiency, number of executed projects, project execution time, increased service revenue, reduced number of applications, product error costs, degree of CTO vs ETO, amount of manual entries of information. You have to agree on what makes sense for your company. The trick is turning such KPI’s into money values.

The most important is to start measuring. Agree on some KPI’s and follow them over time. And show what the KPI’s mean in money.

Tore Brathaug

www.infuseit.com

This %&$#?@! PLM Application!

Have you ever encountered bad user experience in a PLM tool? I have a few times. So how do we address user experience in enterprise software such as PLM Systems?

UI is only one part of UX

When thinking about user experience (UX) of an application you might associate it with words like nice and modern looking graphical user interface (GUI). But it is so much more – in its core it’s about understanding the end-users need and to make the work-tasks as simple, effective, and intuitive as possible. Level 1 is to address things such as consequent usage of interaction patterns, wording, icons and other features that you might associate with the GUI. But that doesn’t necessarily mean that you will develop the right features. You might still miss the actual goal of your implementation.

Understanding the user and the context

So, back to what I considered core – it´s all about understanding the context and the usage. Is the target an expert user? Then it might be important to have an effective pixel-usage, and advanced features, which might have some threshold to learn, but which is motivated by the value it provides. Or, is it aimed for the broader audience, where it has to be intuitive, self-explaining and with zero thresholds? To understand this you need to more or less work in the same way as any business analyst, grasping the essence and details of the tasks that you are about to develop a support for. To know the business impact goal of the implementation is an important part of this, as it sets the framework for whatever feature or function you are about to develop.  You can probably implement “a thing” in hundred different ways but only a few of them will match the desired outcome (e.g. better overview, higher efficiency, transparency, or traceability).

Another important thing, which is put to its extreme when working with customers in the fashion industry (as I do now), is the amount of data that the user is exposed to, and the speed in which the user has to perform his/her tasks. This means that every click counts – if you do thousands of product developments per season you will have some demand on the tools which is supporting your processes. Things which normally might be considered annoying become critical issues. And bad performance becomes show stoppers as the users find other ways to conduct their daily work. If you think about it, it’s not any different to any other industry. It’s just that the situation is more extreme which makes UX a good focal point for efforts made to make life easier to the end-user.

Don't lay the load on the user

A typical trap is to make things over-complicated. This is often found in PLM tools. Tools providing out-of-the-box capabilities often take the path to provide a function which is as generic as possible, allowing as flexible usage as possible. This flexibility is also manifested in the fact that every screen comes fully loaded with features. Something that you most probably can either configure, or use preferences to adjust. The issue is that none of that is actually done to enhance the experience. Actually, you will most likely find this in a lot of highly customized or bespoke software as well, and for the same reason – it is hard to take decisions which limits your options even if it for a good cause; to keep it simple. In many cases you need to take a stand and choose a path for the usage of the software to make it work in a streamlined and effective way - by not taking the decision yourself, you force it upon the end user.

To quote Steve Jobs;

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

There is money to make from good design

The value of good design is not only about pleasing the end-user. Areas which contribute to a faster ROI are:

• Less need for support
• Less error prone
• Less need for user training
• More through-put
• More time spent on value adding tasks

But I have also heard some “softer” reasons for pushing for good design and that is to be able to appeal new, young, co-workers; you need to provide tools which don’t make the hair on their back stand up. That fight is not easy won as applications from the “consumer world” have transformed what we expect from an application in terms of usability. And mobile and cloud has done the same with availability, as we demand access from anywhere at any time.

What can we ask from the future?

I will not take the consumer and mobile path on this one, and I won’t take you to “star trek” millennia either…

Steve Krug’s book “Don’t make me think” is often mentioned when usability is discussed. Isn’t it time for someone to write the book “Don’t make me enter more information, please I beg you!”? I hope and believe that a lot of today’s tedious clicking and entering will be replaced by capabilities which will allow the user to shift focus from administrative to more value adding tasks. Aren’t we soon in the age of more intelligent PLM applications, which could enable more automated metadata creation? I'm not talking about mind-reading applications. It's more about utilizing the context in which the data resides, releasing data by moving out of the boundaries of native file formats, and borrow some from predictive coding. In short - don't make a human do the work that a machine can do.

Robert  Wallerblad
www.infuseit.com

*The title was inspired by the book "Jävla skitsystem" by Jonas Söderström