2 years of PLM blogging – pick a future topic

Time flies. We have a 2 years anniversary as bloggers. Here are some reflections about the previous blogs. What is getting the most attention? What is a bit scary? You also get the opportunity to vote for a future blog topic.

Some statistics

• 26 blogs in two years.
• Close to 15000 readings. We aim higher the next 2 years.
• Most of the readers are in USA, Sweden, Norway or France. Our main market is in the Nordics. Hello Denmark and Finland! You are not even in top 10…

What gets most attention?
As independent PLM advisors we have had very different topics. Some of them are generic views of PLM challenges and how to overcome them. Others are deep dive into specific processes, industries or solutions. Others are on the outskirt of PLM.

The 3 with most attention (percentage of total readings):

• PLM vs ERP – the everlasting trench war or the best PLM ROI? – 6%
• Why PLM often fails to reach its potential – 5%
• You don’t know what you don’t know about PLM – 4%

It is a bit scary that the top topic is PLM vs ERP. This has been on top of the mind in most PLM implementations and clearly one of the selling points of PLM; Get control with PLM and feed downstream processes automatically with quality data. This is still a struggle, 20 years after I started with PLM. It should not be so.

The other two topics are related to PLM challenges in general. Why is it so hard with PLM? And what do you need to know in order to succeed? This is less as a surprise as people struggling will look for tips and tricks and learn from other failures. These are still on a very generic level.

Some other of the top ones:

• The Strategy of Divide & Conquer and its pitfalls – 3%
• PLM – Vision or micro-ambition? – 3%
• How to select a PLM system – 3%

These are more to the point and explains or discusses pros and cons of a strategy or method. There is a hunger out there to get inspiration or tips in their PLM tasks. Maybe we should be even more concrete and deep dive into some of our experiences?

Some reflections
I have been working with PLM for two decades. It is a bit sad that many of the topics are the same today as when we started. And there is not commonly agreed definition of what PLM is? Is it a tool, an approach, a process or what? And many companies seem to have to do the same mistakes as many have done before them.

I don’t know, but I guess that many of our readers are really interested in PLM and have some specific PLM responsibility. Then it is like kicking in an open door for some of the topics. Sometimes it seems that the PLM community is for a secluded group of men in their 40’s and 50’s, with a white shirt and little hair, and have been working with PLM for at least 15 years – like myself and my colleagues. Where are the hipsters and our better halves?

It would be very nice if some of the posts also would be read by senior managers or non-PLM people. Then we could have some interesting discussions. There is still a need for raising PLM awareness and understanding. It is fully up to us to attract new audience.

Many are happy to share their experience and there are some really good sources for PLM inspiration. Here are some of the ones that I appreciate the most.

• Beyond PLM
• The virtual Dutchman
• Tech Clarity
• Engineering (Engineering)

We want to focus on PLM as an approach covering many tools and processes and not that much on PLM solutions as such.

Vote for a future topic
We want to share our experience and want your input on what topics that are of biggest interest. The topic with the most votes will be a future blog post. Please spend a minute and vote for a topic.

Summary
It seems that the interest is in both strategic high level, process or industry specific and deep dive into solution areas. There are a lot of possible topics. Please help us select the most interesting topics.

Thanks for reading our blogs and interacting in discussions. We will continue as long as there is an interest in our posts.

Tore Brathaug
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

Looking beyond the Social Hype of Enterprise Collaboration Tools

Starting a discussion about enterprise collaboration tools the “visionary” individual in the group says: “I want Facebook for me and my colleagues”. And as Ed Lopategui and Oleg Shilovitsky pointed out in their blogs last weekend - Facebook and social platforms are probably not exactly what she should be looking for. So instead of getting fooled by the allure of marketing promises of social enterprise tools what should she be looking for? 

What Facebook and actually most other social applications are providing is not only a real-time chat but something that is asynchronous and persistent and doesn’t require that someone is actually receiving the message at the point in time when it is sent. Due to the global environment in which companies are working in today this is a “must have” as time zones would be a too much of an obstacle otherwise.

Many collaboration tools are coming from vendors already offering CAD, ERP, CRM, PLM, etc but these are primarily focused on the users and practices of that specific system. It’s basically not user centric! If you would take the users standpoint in such a solution you would easily see that you would allow for cool collaboration but only within the island of that application … and for the end user that is not enough - how many are there living in a one-app or even a one-suite world? So we need something that has crossed the application barriers and can work stand alone or integrated depending on need.

Moving towards a “neutral” collaboration platform would also be a step forward to enable a nowadays quite popularly addressed part of enterprise collaboration – the one towards the suppliers. Not only would we have the “normally” implemented structured exchange of information in place, it would also enable us to support the more unstructured and ad-hoc part of it. Moving away from mail and creating a more transparent way of communicating.

This takes me to the next point – Transparency. When I say transparency I don’t necessarily mean that everything is accessible to anybody. But you can share and you can collaborate across disciplines and multiple users without having to cc each other like you do with a mail! This is a key feature and required if we want to break out from the silos that emails are creating.

So what about mail then? Well, I wouldn’t be so bold to say that mail will disappear the next coming years, but we could definitely fight to reduce the volume of messages going back and forth. With good hooks and APIs to import and generate emails and to plugin and expose features in other tools and portals I bet we could give it a good fight too ;)

Another thing with mails is that it allows the user to structure her things in her way. Creating folders and tasks are features which allow the user to create her world and semantics. Allowing her to find and organize the information in her way.

The thing that neither Facebook nor email has is context – the user is the context in these applications. To bring the features of email and Facebook into enterprise collaboration we need to hook it into an item context. And that is exactly what the vendors of the CAD, ERP, CRM, PLM tools offers – the right data context! But only from their application point of view! Users are working within processes supported by multiple applications. In reality “the context” is something moving across multiple applications and across functional domains and we need to treat the communication the same way.

Tying together most of the features implied above is the accessibility and searchability – for the communication, collaboration, transparency, email, and context to be worth anything you really need to be able to find stuff.

So now I have stated some features I consider important when thinking about collaboration tools. Although being good, they bring some softer challenges to the table, which might be easier to mitigate in current collaboration solutions.

One challenge is to do the right thing in the right place and in the right forum ... and still making it understandable to the user.

• Data in the “right” place - will we create a mess and store important information in a too unstructured way?
• Decisions in the “right” place - will decision be made invisible and will we lose the formality required of some decisions? Statuses, do we need them anymore ;)

Then we have an obvious challenge - getting people to move from a silo mail-world to a world which is no longer under “my” control. Transparency is scary. There is no way around that.

So to summarize; Facebook is probably not the way forward for enterprise collaboration tools and there are some challenges to address on both technical and a human level with today’s collaborative tools. One thing is for sure - just because we might re-label "the solution" from time to time the need will still be there. The problem is when the label brings assumptions to the table which are not suited for an enterprise collaboration tool. I'm sure that we will get past the current misconceptions and as collaboration and digital technologies are advancing it will allow us to solve our challenges though new influences and tools. 

Robert Wallerblad

www.infuseit.com