How do we get PLM right?

How do we get PLM right and who is the PLM expert? Who knows best how it fits the users and the company? Can we get it right without involving the end users?

I’m not claiming to be a user experience (UX) expert of any kind but I have reflected and learnt some during the years, and one thing is that the best way of really getting it right is by testing it on end-users. And I intentionally expressed this in plural – you need a group of people to validate the chosen solution. It is arrogant to think that you will get it right just because it states expert (or PLM advisor as in my case) on your business card.

But a UX expert wouldn’t ask an end-user; so what is it that you want? To put it into a classic T-Ford example: If you would have asked what the people would have wanted they would have said "faster horses", instead their need was faster transportation. So it's not solutions that one should ask for and seek, it is the underlying problem that you want to solve.

After having talked to the users about their challenges, wishes and dreams, she would bring a suggestion to the table to try it out, preferably before and during implementation. That’s where the UX expert has its domain; understanding the end-user, suggesting solutions and validating them (which is a craft of its own to master). 

So how is it with PLM? Should we consider that the same applies to this domain? That the crowd knows better than the expert? And the expert’s job is to suggest solutions and then validate them?

Who knows the customer best?

Well, I would say it would be strange if it wouldn’t be the customer itself. The customer though, might need some assistance in understanding, expressing, describing and documenting their needs, problems and challenges.

Who knows the domain best?

The customer knows how they are doing things but that is not necessarily the same thing as stating that it is the best way (even for that customer). External “experts” will bring ideas to the table, as they have experience from many different companies, thereby allowing them to have another view on the topic.

Who knows what to aim for, and what the vision should be?

Is it the ones working in the process day-to-day? Well, you need to have some perspective to your own work. And be exposed to input from others to be the one with a goal that has a trajectory which aims high enough.  Don’t get me wrong! You will get good initiatives going by listening to the end-users. But, you might find them to be “micro-ambitious” – targeting to solve the challenges and evolve the work of few, but not taking the enterprise view of the PLM agenda. Also, it is most likely that you will get feedback targeting to solve the problems of today which leads to a more reactive behavior than a proactive approach targeting to get your enterprise to the next "level".

Who knows the tools?

There is actually at least one more “expert” to this equation, at least once you actually talk about IT solutions and not just strategies and processes – The above questions don’t take into account that there are constraint in the IT tools, which are limiting your options. This is where the application expert finds his place. The platform/application will create constraints which the expert, whether it is UX or PLM, has to consider at least to some extent when it comes to deciding on solutions.

The other side of the coin can be processes or solutions in the application that you did not think about, but can give short term improvements with little effort.

Have we found all the “experts” now?

We have a good mix, but there is one more which could spice up things and could be used as a catalyst; the generalist. In some situation you will benefit from not being an expert in the field - an outside perspective will allow you to see new connections and reframing your situation with expertise and experience from other industries and business domains.

An interesting take on this is whether you are looking for someone who should help you solve a problem or find a problem. To truly take your PLM vision and strategy to another level it’s not enough to solve a known problem; you need to find problems that you didn’t know you have. Who is most suited to guide you in that quest?

But what happend to the crowd/the end-user?  

They are there. Because whether you are implementing processes or tools to support them the end-user will still be the judge if it fits with her needs or works in the reality of conducting her work. 

Conclusion

Implementing PLM (and knowing how and what to do) is not a one-man job. You need to ensure that your team is multi disciplinary; with both broad and deep knowledge in the domain, business, and technology. I would also emphasize that you need real end-user involvement to make sure that you, at the end, get their acceptance.

I leave you with a quote that stuck in my mind after a conversation with a colleague:

"A 'newbie' will look for evidence to guide her in the path to the most appropriate actions to a greater extent than an expert would. Therefore she will win in the long run."

What if you would have a team of experienced people which uses the tools and mindset of the newbie?

Robert Wallerblad

www.infuseit.com

When product design meets plant design

I’ve been fortunate enough to work with some EPCs (Engineering Procurement and Construction companies) that also owned product companies in order to control more of the value chain. In these companies I’ve witnessed some very interesting discussions between plant engineering and product engineering. They often have a really hard time understanding each other.

Communication Problems

A typical situation is when plant engineers and product engineers come together to discuss PLM, and a way to create a consolidation platform for both plant and product engineering in a project execution context. This often results in a failure to communicate. The tools, processes, language and culture usually differ between plant engineers and product engineers. They have different vocabulary and focus. This can be accommodated by learning the language and understanding the culture. It is more challenging when they think they talk about the same, but in reality talk about very different things. As an example: Systems Engineering is for a plant engineer very different from Systems Engineering for a product engineer even if both of them can talk about functional decomposition.

It is crucial that enough effort is spent on making them understand each other. Then you can start finding the points of interaction and overlaps.

The business objective

• Plant engineering: The general idea is usually that plant engineering wants to re-use more across projects. Every project (customer delivery) is Engineer To Order, but by copying parts of some other design that was similar, or modules from a “Best Practice” library the EPC can reduce the amount of engineering hours spent in proposal or FEED (Front End Engineering and Design) phase.
• Product engineering: Product engineering usually also delivers project specific product designs, but would like to move in the direction of standardization while still having control of the project specific product deliveries.

How can this be done?

Consolidating and integrating plant and product engineering

In most of the cases I’ve seen where they consolidate plant and product information, some kind of product master library or catalog is created. The catalog holds the plant aspect with tag structure and functional requirements seen from plant engineering (a tag structure).

In addition it contains the product aspects with at least a generic product design (generic EBOM ) for the product, and in some cases a commercial representation of the product (sales structure).

This would mean that plant engineering could pick products or systems from the library and get an auto generated tag structure with requirements corresponding to the plant view of the product or system, whereas product engineering could be notified if a demand for further product engineering is required for the product in that specific project.

This is all very well until plant engineering and product engineering start figuring out what the actual content of the library or catalog should be. There is a substantial language barrier there, and the main issue is that they will use the same terms but mean very different things. Terms like functional location, functional decomposition, systems engineering are similar in both plant engineering and product engineering.

The difference is that the plant person will think of tag structures, P&ID (Piping and Instrumentation Diagrams), functional decomposition and requirements needed to design, build, operate and maintain the plant as a whole which means that only a subset of information is needed for each individual product. The product person will think of the products requirements, functional, logical and physical views (RFLP) of the entire product.

This can lead to long discussions where everybody thinks that they understand each other. It seems that they agree and start implementing a solution. After some time it becomes evident that they need very different things from the product master library.

What is my conclusion?

It is extremely important to agree on definitions and terms. What they mean to different stakeholders and what they should mean to the company. Product engineering should show and explain how products are designed to the plant engineers, and the plant engineers should show and explain how plants are designed and what information is needed to the product engineers. This exercise should be done as early as possible to avoid costly misunderstandings between the two domains. I would even go as far as saying that it would be a good idea to do this even if the EPC does not own the product companies.

Bjørn Fidjeland
www.infuseit.com