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

Variant management in engineer-to-order?

Many products come in a lot of different variants, for equally many different reasons. Growth in variance can be a big challenge, in the virtual world, as well as the physical world. Taking a structured approach to variant management can help you get back in control – if you do it right.


First of all: variant management is not equal to product configuration (even if it is a closely related topic which may very well be part of a variant management solution). Also, the solution for variant management might look very different depending on type of product and type of industry: Is it a highly industrialized product, like a car, where all variants are made from a finite set of standardized modules? Or, is it a complex, low volume product, where new variants are created “on-the-fly”, based on customer requirements?

Many industrial companies are in the latter category, supplying highly advanced products to demanding customers in industries like oil & gas, aerospace & defense and health care. Common to all of these are that they typically come from a very project oriented mode of working, which is reflected in the way they are organized and how information is managed. They do talk about products, they do have product catalogues, but every delivery of a product is organized as a project, which typically includes a substantial engineering effort. The product information tends to be treated as project specific, even if the major part stays unchanged between each delivery project. Reuse between projects is frequently done by copying rather than referencing, resulting in massive duplication of documentation as well as part numbers.

The economy of scale

Variant management in high volume manufacturing is driven by a desire to cover a wide variety of customer preferences with a limited number of products. This has resulted in products that are configurable by the end customer, as part of the ordering process. The emergence of product platforms has brought this concept further, allowing a large number of models to be derived from a common technical platform. One of the latest developments in automotive is "scalable platforms", from which car models of almost any size can be derived, with VW and Volvo as early movers with their MQB and SPA platforms respectively. It is no secret that these initiatives are huge investments, but both manufacturers expect to gain a significant competitive advantage through the economy of scale for shared components and modules, as well as shortened development cycles for future models.

For low volume products, where the typical mode of operation is engineer-to-order (ETO), variant management is not needed as an enabler to provide a larger number of variants, as each delivered product is anyway tailored to satisfy the requirements of each individual customer. Rather, variant management should be seen an approach to rationalize the way products are delivered, while maintaining the competitive advantage of being flexible towards the customer. The economy of scale is still a valid motivation for improved variant management, as far too many activities end up as a redundant effort, repeated in every single delivery project.

Where to start and what to do?

Although the streamlined configure-to-order (CTO) process of the automotive industry might be out of reach when you are dealing with low volume products, there are still many concepts which can be applied, if you are in the ETO-business.

First of all, you need to step back and take a look at your business model and strategy: are you aiming at speeding up your current delivery process, or are you looking for new ways to design and deliver your products? There might very well be a potential in automating repetitive tasks in the engineering process, employing for instance parameterized CAD-models to speed up drawing generation and CNC-preparation. In many cases, however, there is a much greater potential to be gained from avoiding repetitive tasks, rather than automating them. This is where modularization and product platform thinking can be of help. If most variants of a product can be made from a limited number of standardized modules, there are huge benefits to be harvested all along the product lifecycle, far beyond the engineering department. A few examples:

• It is easier to predict the cost of the complete product, when the cost of each individual module is known from experience.
• Component and material cost will be reduced when enabling the procurement to order larger volumes, gaining lower prices from suppliers. Better predictability for expensive, long lead items is another advantage.
• Quality cost is reduced, as each module has a standardized set of design documents, which can be improved over time.
• Production processes can be industrialized and optimized to a much larger extent, as the number of identical items increase.

Some companies might object that customer requirements will still force them to deliver unique products (and documentation) every time. This may be true today, but will it still be true if the customer was confronted with the choice of a standard product and a custom product at twice the price? Certain types of products are custom by nature, because of the surrounding environment. It would still make sense to standardize what can be standardized to reduce the engineering effort in the delivery process, saving time and money.

Success criteria

To succeed with variant management in a project oriented environment, it is critical that the organization is set up to properly manage the standardized building blocks, and that the information management systems in use support the new way of working. Most PDM and PLM systems have specific functionality for variant management, as well as the required support for engineering change management across projects. The single most important criterion, still, is to establish a dedicated organization for product management with sufficient funding to develop and maintain the standard product definition, to ensure that it is complete and up to date. Otherwise, there is a high probability that the project engineers will continue managing variants as they have always done: using "Save As".

Johannes Storvik
www.infuseit.com

How to select a PLM system

During my 15 years in the PLM industry, I have seen my share of PLM evaluation processes, both from the vendor’s side and from the customer’s side. Selecting an enterprise IT system is a comprehensive exercise. The selection of a PLM system is no exception. This is due to the wide range of functions and the fact that PLM can involve many departments (if not all) in a company; all the way from sales, through design and engineering, manufacturing, and even service and after-market.

In this blog I will share my top tips on what to focus on when selecting a PLM system.

• Define the strategy Before diving in to the detailed technical requirements of the PLM system, it is important to set the ambition level and to define the strategy. Start with the big questions: What shall the PLM system do? Is it a strategic enterprise-wide system or just a tool for a specific department? Is the focus on the extended enterprise and global collaboration, or just to have revision control of CAD models? There is no right or wrong answer here, but it is critical to have a clear view on what the focus should be and what you want to achieve.

• Plan ahead When selecting a PLM system, it is important to look at both the needs of the business today and for the future. Think both short-term (what is important to solve today?) and long-term (what do you want to achieve in the next 3-5 years?). Typical short-term needs can be CAD integration, document management and change management, while long-term needs can be supplier collaboration, installed base tracking and systems engineering. It is important to select a tool that caters for both short and long term requirements, and then evaluate solutions based on those ambitions and needs.

• Educate yourself Before starting the evaluation process you should gain knowledge of the PLM discipline. This is important in order to be able to define the requirements properly and to have productive discussions with others on PLM (internally and with vendors). You can gain this knowledge yourself by attending a training class or browsing the Internet, or you can hire an external consultant to assist you.

• Don’t underestimate the importance of usability At first sight, most PLM systems look flashy and quite similar. It is only when you look deeper that you see the differences and how user-friendly a system really is. To secure end user adoption of the system, it is critical that the system is intuitive, user-friendly and easy to learn. This is especially important for ad-hoc/light users of the system who will use the system only sporadically. My advice is to invite non-engineering users with no PLM experience to attend one of the demonstrations, and let them give input on usability.

• Focus on what’s important All the major PLM systems on the market today cover all the required basic PLM functionality. So there is no need to spend time specifying this in the evaluation process. Instead of over-specifying, focus on what is really important. This may be integration to a specific MCAD system, compliance management or other areas outside the PLM core (PDM). All PLM vendors claim they have this, but the level of support varies.

• Select an experienced partner A PLM system is an enterprise IT system that will be around for many years after it has been implemented. Selecting an experienced and solid supplier and implementation partner is an important criterion for a successful PLM installation. It doesn’t matter how good a PLM system is if it isn’t implemented in a proper way, so take a look at the track record of the supplier: Have they done similar implementations before? Are they financially solid? Will they be there in 5-10 years? These are important questions that need to be addressed.

• Talk to other PLM customers By looking at the websites of the PLM vendors, or by attending a demonstration, it can be difficult to distinguish the PLM systems from each other. The best way to really learn what a PLM system and the implementation partner are capable of is to talk to someone with experience of the specific tool and implementation partner. Ask the PLM vendors for a list of reference companies (with contact persons). Ask for references in the same industry and references that use the same functions/modules (e.g. integration to a specific ERP system) that you will be using. Take the time to talk to as many references as possible. They can give valuable input that you will not get from the sales guys.

Conclusion

When selecting a PLM tool it is as important to look at the non-functional requirements as it is to look at the functional requirements of a PLM system. All the major PLM systems on the market today deliver more or less the same functionality. Focus on the local supplier, their solidity and ability to implement. Talk to other companies using PLM systems. Don’t underestimate the importance of usability, especially for ad-hoc users. User adoption is critical for a successful implementation. And before diving into the technical details, spend time defining the PLM strategy, look at what role PLM should have both today and in the future, and make sure this is backed up by management.

Lars

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

The Strategy of Divide & Conquer and its pitfalls

Have you used the strategy of “Divide and Conquer” in your PLM (product lifecycle management) project? I’m sure you have – it’s the commonly used “best practice” to solve a problem by “slicing the elephant”.  Or as the Romans would phrase it: to break another power into smaller, more manageable pieces, and then take control of those pieces one by one.

• It’s used in software implementation projects to slice processes into activities which are realized through features and functions which are again sliced into technical tasks
• It’s used in problem solving to get a grip of the challenge in front of you
• It’s used in change management and rollout strategies both in terms of scope and organization

Losing the Big Picture

Dividing the world into manageable chunks is powerful and has become a de-facto approach to take on challenging tasks. It’s a reasonable thought and it is a good strategy in many cases but it has its pitfalls. And looking at the other side of the coin: The “Divide and conquer” strategy is about keeping smaller powers and governments from uniting. This might have been a winning concept for Romans and the British Empire to conquer their enemies. But PLM and software implementation projects using this strategy require some mitigation actions to avoid falling into a trap of sub-optimization, lack of transparency and losing the sight of the actual goal. Because, even though you want to cut your elephant into digestible chunks, you still need to be able to see what you are eating. You become the victim of the strategy itself as its whole purpose is to separate, while both PLM initiatives and most software projects require a holistic approach throughout its implementation.

Conveying the Big Picture

If you don’t keep the bigger picture in mind while working on the details, you will deviate from the guiding vision and strategies, the architectural principles, the business goals and actual business needs, the overall processes, and the UX (user experiance) guidelines. Let’s look at the symptoms for each of the listed areas above:

• Vision and Strategies – Sub-optimized efforts which doesn’t contribute to the overall vision or strategy
• Architectural Principles – Platform, application, design decisions breaking the IT strategy will create silos, interconnectability issues, customized solutions, and a diverse spectrum of used technologies. This results in high TCO (total cost of ownership) and a situation where it becomes hard to support and maintain solutions (read: higher risk)
• Business Goals and Needs – Functions and features might be developed according to guidelines and conform with good architectural principles but that doesn’t make anyone happy if it doesn’t help in achieving business goals or addressing business needs
• Processes – If you don’t know how things are stitched together, the risk is pretty big that you will miss something along the way, resulting in a set of “disconnected” features
• UX – The perceived usability of an application will suffer if the look and behavior diverge across functions. This will result in more need for support, more user errors, more training and lower efficiency

The Right Decision at the Right Time

So one challenge we have identified with the strategy is that we need to find ways to convey the “big” picture, so that we can make the right decisions while working on the details, as we want the pieces to still work together to achieve the objective of the whole.

But, we need to find the right level of details describing this big picture. And the timing of setting these details (= make certain decisions) is also crucial. Finding this balance is important as we will lose important freedom too early in the process and thereby our agility.

I hope that it’s clear that it’s not a waterfall approach that I’m promoting. It’s just that I don’t believe that you can work effectively with enterprise software implementations, such as PLM systems,  if you don’t have some ground work done both in terms of processes/methods and involved technology. The output is as much an artifact to be used further down the lane as it should be used to anchor the stipulated way forward and keeping stakeholders involved.

Conclusion

The challenge lies in the way we slice the elephant, while maintaining the big picture and manage the balance between too much or too little of the ground work: taking the right decision at the right time. The next trick is to actually use that knowledge to communicate and anchor our way forward and give input to activities further down the lane. That is what will cater for success.

Do you agree? Have you found this balance and do you have an effective way of conveying guidelines, principles and decisions?

Robert Wallerblad

www.infuseit.com

The Mountain Code for PLM

In this Easter time there are a lot of Norwegians going to the mountains to go skiing in the remaining snow. There are guidelines on how to behave to be safe in the mountains. They are called “Fjellvettreglene” or the Norwegian Mountain Code. As it turns out, they are also strangely relevant for PLM.

1. Be prepared (Don’t go on a long trip without practice)

A good plan is half the job. If you also have people with PLM experience and preferably some PLM implementation experience you are in a good position. It is hard doing a PLM selection and implementation if you don’t have any experience at all. Start small and learn along the way, don't try to take the whole elephant in one bite.

2. Leave word of your route

A twist on this is that you have a better chance of getting the rest of the organization along on your PLM journey if you inform and educate. Let the others know what you plan to do and why you do it. Communicate the visions, plans and achievements. Keep management informed along the way of both good and bad.

3. Be weather-wise (listen to the forecast)

Listen to the weather forecast and show respect for the weather. In a PLM context this can mean that there might be circumstances and events out of your control that can influence the PLM project in a negative manner. A typical one is: “we will do PLM after ERP. And, by the way, the ERP project is delayed”. Others kinds of “bad weather” can be: downsizing, financial troubles, the company is about to or recently has been sold. You should try to listen around for the most obvious ones and be prepared to handle them, and if the forecast is really bad: postpone the trip.

There is also a positive twist to this. Take the opportunity if the weather forecast looks good. If the financial situations is good, management is supportive and there are some clear areas where PLM can contribute: Start now and get a positive momentum.

4. Be equipped for bad weather and frost.

Even if the forecast is good, you might be surprised with bad weather. Be prepared for challenges and troubles. Do risk management properly and have plans for problems before they appear. If the company has financial troubles; how can you cope with a smaller budget and less people? What can you take out of scope if circumstances demand it?

5. Listen to experienced mountaineers

If this is your the first PLM project in your company and you don´t have people with PLM experience, you should listen to others who have done this before. Learn from others and avoid the mistakes done by others. Contact similar companies in your industry, companies in your neighborhood or personal network that have implemented PLM. There are amounts of good advice to get from others. And finally: don´t always trust the vendors ;-)

6. Use map and compass

Create a vision, a roadmap and a plan. And follow it. Of course you might have to adjust the course along the way, but you should always know where you are and where you want to go. You might have to change the destination as well, if you are surprised by bad weather. But that is better than getting lost.

7. Don't go solo

PLM is not a one-man or a one-team job. You must ensure that your project group consists of people from several departments and disciplines. You need involvement of and commitment of all key stakeholders. Make sure that they share your vision and trust your plans.

8. Turn back in time; sensible retreat is no disgrace

PLM projects can be hard and you will meet some trouble. If the trouble is big enough you should consider turning back. In a small scale it can be a new module or functional area just ready for roll-out, which turns out to not be of good enough quality. In a larger scale it can be the whole PLM solution. Turning back to stop the whole implementation is a tough decision, but in some cases it must be done. And it should be done sooner rather than later. Whether it is possible to turn back gracefully is another matter ;-)

9. Conserve energy and build a snow shelter if necessary

Instead of turning back you can stay where you are and conserve energy. Instead of continuing at high speed you take a break and evaluate your position. Did the map or direction change? Are there any unforeseen obstacles? Maybe it is time to re-visit the vision and plan. If worst comes to worst; you can of course book a one-way ticket to Hawaii and relax in the sun. Or, as the Norwegians do during Easter; Go up in the mountains and enjoy the last remnants of snow.

Conclusion

Mountain trekking or skiing has a lot in common with PLM. Following common-sense guidelines is helpful in both cases. From time to time you meet problems, but the better prepared you are; the more likely it is that you can handle it and progress without any danger. Respect the challenge and don’t plan for a harder route than you are trained and equipped to take.

Enjoy the PLM journey and have a nice Easter

Tore Brathaug
www.infuseit.com

PLM Success – Knowledge within the operational data that you produce

This blog continues a discussion which has been the topic of two other blogs; PLM – Vision or micro-ambition? and  PLM Success - Think Inside the Box. Previous blogs was about the importance of embracing changes and input along the way of implementing PLM and not only working blindly towards a set goal.  And the usage of your employees and cross-fertilization as a source for input.

Today we will deal with the usage of operational data as input for process improvements. 

I’m talking about the data generated while executing the company’s processes, and not “product data”. I believe that this is one of the “untapped” or at least underestimated sources for input we have, as it’s already collected to a large extent, to manage the company’s day-to-day business.

IT is traditionally a service and infrastructure provider for the business-side of the company; giving them the tools to execute their work and make well founded decisions. But, what if we could use IT to also provide the means to turn the “eye” inwards in terms of methods? Providing that a PLM system doesn’t always force a process and way of working upon you (read: not controlled in detail by the system), there is potential work to be done to see how the stipulated methods are followed. What if we analyzed how work is done and thereby receive feedback on current working methods and potential areas for improvements or alignment to reality (does it look shiny enough?).

Data warehouse analysis related to PLM processes, that I’ve seen, usually has their focus in time, money, quality and risk. Sometimes you’ll find this type of analysis in dashboard in today’s PLM systems and other enterprise systems. But they are almost always used to support the operational aspect of the business. What if we looked at the list but with method improvement focus?

• Time – How many iterations does it take to get to a certain status in the development and what are the underlying reasons for it (communication, education, etc)?
• Money – are we selling to the right price in the different markets? Are we able to get our “raw material” to the right price? How is our sourcing affecting transportation cost?
• Quality – sustainable sourcing and material statistics, scrap- and recall-statistics
• Risk – are we placing our orders “right” to get the right risk exposure? How is our in-stock volume? Could we use more low fair transportation alternatives? How good are we at forecasting and thereby being able to book, buy and commit so that we get better in-price?

With the information that we get from the data; processes and practices could be followed up to see how they are adopted and applied by business. We could also analyze good performing teams, and thereby improve company methods and best practices.

We could even take this one step further – with tools such as dynaTrace we could analyze on application level what functions are being used and how to optimize the flow and usability within the specific application in a prioritized way.

The important point here is that we could get input for the PLM journey by looking at how the company is performing and acting in its current processes. Changes doesn’t always have to be revolutionary and ground breaking, in this case they are evolutionary. Derived from the knowledge we get by analyzing data.

This is definitely not science fiction. All technology is there to be used; it’s more a question of maturity and determination to use the data with long term strategic focus and not only making the coming quarter look good.

Robert Wallerblad
www.infuseit.com