The PLM-user Pitch

The PLM system pitch and the related discussions is almost always focused on the decision makers - how should you convince the management to buy, and how should you show that you provide value with your implementation?

The topic is most often focused on the disconnect between IT and Business and how to bridge the gap.

It’s of course an important topic but today we will look at it from another angle.

There is another void to fill and that is the one between the benefit of the enterprise and the actual user of the system.

Neither vendors nor the companies looking for PLM systems have (enough of) this in focus. There is a functional focus, I can agree on that, but that is not necessarily the same thing as a user oriented PLM focus. It’s more about having a checklist to see that an application can fulfill the functional requirements, which is not really the same as having the user in the center.

So what would happen if we would focus on the users? Because once bought, a system such as PLM is not only good for the business as a whole, it is also intended to help users in their everyday work.

Tools and processes for the greater good

An enterprise tool is often emphasized as the tool which should support the complete company’s need and not necessarily the individual. We focus on overall process/information improvement and harmonization and not the end-users tasks and daily work.

A company oriented pitch is also often more future oriented, than what you would like to phrase it to an end-user. The employees are more focused on the present and solving the challenges of today. That’s where our pitch should be focused – the present and what it means for the individual.

An individual productivity tool

If you take the scope of PDM, you should be able to pitch the actual idea to make it about enabling the individual; making it easier to find the right information, enabling earlier transparency as well as collaboration. For complex data sets and/or tasks it will help out in keeping data integrity, and dependencies thereby offloading the workers from otherwise tedious and error prone tasks.

But unfortunately there are challenges with this pitch:

• The end user and the way they want a system to behave and support them in their daily work is diversified. What makes a good fit for one will not necessarily fit others. Basically I don’t believe that there is a “Heinz ketchup of PLM”, fitting all tastes. I rather believe that the need is as diverse as the salsas that you can buy in your local supermarket.
• If we talk about PDM systems - functions associated with PDM comes with quite a heavy baggage in terms of old system behavior which has not always been perceived as enabling. A shift in technology and the ability to work more seamlessly will most likely help out in making PDM applications less of a struggle in the future.

A Tool for Knowledge

The productivity pitch will not get that much traction if your PLM system is used to “only” specify your products once you have developed them, instead of being develop within it. Unfortunately this (mis)usage is not as uncommon as you might think. In many cases putting things into the system is an administrative task at the end of what one consider value adding activities, and this really undermines the individual’s perception of having the system support her needs.

But, independent of scenario you would probably gain one thing and that is a knowledge bank. The system will create transparency which would benefit the individual, as searchable and structured information will allow for higher productivity second time around.

This transparency will also benefit the people further down the chain. The earlier you manage to accomplish it the more power you will get of it, and it’s also an opportunity for business intelligence to analyze trends earlier which again could be used as a pitch for certain end users or consumers of information.

Democratization

By sharing knowledge we will enable decentralizing and distribution of tasks. Technology will enable this. Because by systemizing knowledge we can put it in the hands of “anyone”.

Think about simulation which previously was something that only highly specialized people worked with. Today software is taken the first hit through checking the output of the individuals work before integrating it with the rest of whatever solution one is working on. All domains have it; software, hardware, mechanical design, electronics, etc. And some will take the step to create mockups which brings multiple disciplines together.

There will always be a place for specialized skills but the frontier is and will continue to move as we manage to systemize knowledge. And this should appeal to the expert as it will allow her to focus on things which are less bread and butter, at the same time as it gives the non-expert more confidence in the output she produces.

A trendy phenomena is Internet of Things; think what we can do with data collected from products in the field and once we systemize that knowledge. How will that translate into the way we design our products or conduct or service and maintenance business? Once that data is cracked it can be used as BI put into the hands of the individual.

Could this bottom-up approach result in benefits on company level (for “the greater good”)?

Could we flip this around to make it about the company, and what is best for it? Of course we could. Thinking about and addressing the needs of the individual will at the end find its way to the bottom line, resulting in better overall quality, better flows, higher productivity, higher data quality, etc.

Conclusion

IT and PLM should not be seen as a support function next to the core business – your PLM processes is actually part of your business. In many companies today it is therefore within your PLM systems that you conduct your business. If we embrace that fact, the focus can’t always be on the benefits on company level, the day-to-day work has to find its way to the PLM pitch.

Robert Wallerblad

www.infuseit.com

A Picture is worth a Thousand Words

My professional path has allowed me to work with many industries and type of customers - looking at just my recent year and it has taken me into classic manufacturing, automotive, defense as well as apparel. Something that has been a signature of my work across all these customers is the fact that I’ve been very visual in the way that I’ve been communicating. I’ve been using mockups to illustrate my ideas from pre-study, architectural reviews, scoping workshops, concept discussions, down to developer input and user stories. What I can say is this – independent of industry or audience, these artifacts are always appreciated and well received.

Engineers, spare part catalogue editors, configuration managers,   pattern makers, buyers, controllers, designers, .... I can continue this list ... managers, project sponsors, project owners, project managers, business developers, SW architects, SW tester, and SW developers, .... what do they have in common? Well, they want (and need) to be able to understand at least to some extent the IT solution that will affect them or that they will be responsible for.

Here is a small prezi on the topic that might give you some more food for thought. Enjoy (and don't miss the movie clip at the end)!

As you might understand by now I’m quite clear on my view on this topic. Don't get me wrong, I'm not saying that you should stop writing all nice diagrams, charts, boxes, and lanes that you do today (as long as they have a good purpose ;). But the audience for those artifacts is limited to experts, and unlike what you might think even techies at the IT-side find visual illustrations of a topic useful.

If you haven't used mockups before there is one trap that you will fall into: your audience will look at the mockup as something finished and fully covering – end users expect the solution to look and behave as the mockup and developers will try to realize every little inch of the picture without questioning. To mitigate this behavior, it is very important to apply some expectation management. The purpose of the mockup, its usage and “how to read it” should be clear to the audience (and preferably repeated as often as the mockups are shown ;).

It feels great to be understood and even better for the audience at the receiving end to actually understand. So try it out!

One last thing regarding mockups - They don't replace human interaction and verbal communication. It's a complement to that and all your current tools to make yourself understood.

Robert Wallerblad

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