You don’t know what you don’t know about PLM

It is hard for non-PLM experts to know all the aspects and possibilities of PLM solutions. I have seen it over and over again. How can companies looking for a PLM solution make the right choices? Should they start specifying what they need or should they just trust their hunch and pick the one on top of their mind?

The topic is also valid for companies that have had PLM for a long time and are stuck. It is hard to know how and in which direction to go. In this blog I focus on first, or even second time buyers that don’t have large PLM organizations and a lot of internal PLM knowledge.

PLM can be so much

There are as many opinions about what PLM is as there are people. On an overall level you can probably agree that the core is:

• Part Management
• BOM Management
• Document Management
• Change Management

Throw in some CAD integrations and an ERP integration. Maybe variant management or project management. Or maybe PLM are all the tools and processes creating or managing product information?

An enterprise PLM solution like Teamcenter, Windchill, Agile and Enovia has an enormous breadth, but there is also a challenge to understand the details in a selected PLM area. For example CAD integration or the change management process.

The core functionality mentioned above is really not more than classical PDM and which what most companies still need the most. But it can be hard enough. There are so many details that you probably didn’t think you had to care about.

• What should the naming rules be? Running number? Any logic?
• What metadata do you want need, and can you agree on it? How does that match for instance ERP?
• What are the approval steps for different object types? What is an object type by the way?
• Easy revisioning in development and full blown change process in productionmanufacturing?
• How do you get a BOM from CAD? Can you use it directly?
• Etc.

There is so much detail in core PDM that you will not be able to cover it all during an evaluation phase. The devil is in the details and some of these differences can have significant impact on your way of working. Unless you really know what to look for you will not be able to identify the details that matters for you until you implement or even roll out the solution.

The evaluation process

Buying PLM is like buying a house. You visit the house one or maybe two times for half an hour. You read the prospect and then pay more than you planned. Then you get surprised a couple of months later when you get the house as there are so many details you see now that you could not possible see during the sales process. The good thing is that the human brain usually rationalizes bad decisions to look good. The good things about the house is exaggerated and the bad things are ignored. It can be the same with PLM. However, problems with PLM tends to be visible to others than the ones making the decisions, and that makes the bad things hard to ignore.

The problem with buying a PLM system, and a house, is that unless you are an expert you don’t know what to look for. You look at all and end up looking at nothing and make a decision based on who did the best demonstration and who you trusted most in the sales process. By the way: those people you trust the most are not likely to be part of the implementation anyway.

The sales presentations (and the information you find on the vendor’s websites) from the competitors can probably be switched without you noticing. On a sales level all solutions can do everything. You have to find the differences yourself. I like this quote from David Stewart at Zerowait-state: "..it’s hard to discern which is the better (PLM) choice. I still feel like the best way to know or choose is based on experience".

To compensate for not being able to see clear differences between the PLM solutions you typically describe what your requirements are and send out RFQs with a lot of details. If you are considering any of the enterprise tools the problem is that the solution providers probably can say yes to almost all and do the same things as the competitors. It is very hard to distinguish PLM solutions based on a list of requirements. See this blog for some insights to why traditional RFQ processes is a problem.

The typical tendencies when specifying needs/requirements as first time buyers are:

• Not to specify at all or on a so high level it does not give any value. The answers all look the same. You end up picking the one you know or the one you believe the most in.
• Or specifying in detail everything you can think of. You spend tremendous effort in detailing a very long list of requirements to be sure you cover all aspects. You end up with a complex solution.

The first one might be as good as the second. A big requirements phase is a danger in itself. You easily end up specifying today’s way of working. You don’t see all the changes a PLM solution should bring.

I suggest that you spend more time on reference visits and focus on the supplier, and not that much on the PLM solution itself. Find some of the references yourself. Don’t just take the ones that are picked by the suppliers. The key question: Is the supplier capable to be a long-term partner ensuring your success?

Hard to differentiate the PLM tools (even for experienced people)

I have been both on the specifying side as a customer, on the response side as an implementer and now on the customer side as an advisor in many PLM evaluations. And I see it again and again. The people evaluating PLM solutions are not able to distinguish clearly and rationally between the different options.

It is very hard to find facts about the differences. And the truth is that on a high level the differences among the enterprise PLM tools are quite small. You will see differences if you consider some lighter “PLM” solutions that are more CAD management oriented or ERP with PLM functionality. But even there it might be difficult. For CAD management oriented tools they might fall short on multi-CAD and integration to ERP. For ERP they might fall short on CAD integrations or on advanced PLM functionality like systems engineering. But for the core functionality it will seem that they all can do it.

The vendor’s tendency

The vendors tend to fall into one of two categories:

• The oversimplifyers – They oversimplify the message and the effort. This makes it easy to understand for management and other stakeholders that are not experts in this field.
• The scope-extenders – They want to extend the scope to show all the magnificent solutions they have that you didn’t ask for in the beginning

Be very aware of people in the extreme end of these two.

• The too good to be true is usually that. You will end up with a limited solution and realize you got less than you expected.
• The large scope might be too large. You end up with a very long and complex project which is more expensive than you thought and it is hard to get the organization on-board.

The sales guys anyway will paint a nice picture. The challenge for you is to see behind the fancy slide decks and prepared sales messages.

What should you do?

It is hard for first time PLM buyers to grasp the totality and at the same time identify the crucial details that can make or break your PLM project.

Don’t over-specify to compensate. You will not be able to specify up front how the solution and processes should be in 3 years. Even if you could the world will change in the meantime. It is more important to draw up the big lines and have a long term vision, strategy and plan. You should start with the most important areas and specify to such a level that you can differentiate. There are differences between the PLM solutions, you just have to know what to look for. If the differences is in an area that are of great importance to you it is better to find that out during the evaluation phase than in the implementation phase.

To be able to do this you could recruit or hire people who have done PLM evaluations and implementations before. It might seem expensive, but it will pay-off with a solution that is better fitted to your needs.

You might consider running a proof of concept (POC). But you risk going in the same trap. You have to know what to look for in the POC to get any value of it. Done properly a POC based on your data, products and your wanted way of working can be a really good approach.

You should look at other factors than just the feature list. The most important is the supplier itself: Have they done this many times before? Do they have understanding of your business? Do they act as real advisors guiding you in the right direction? Do they have references in your region?

See our How to select a PLM system blog post for more details about how to run a PLM evaluation.

Summary

PLM buyers: You don’t know what you don’t know about PLM. That means it is hard for you to distinguish the tools and the suppliers. Don’t try to specify everything. Have a clear vision of where you want to go and what you want to achieve and what is important for the business. Establish a commonly agreed strategy and a high level plan on how to get there.

Don’t go too much in detail, just where it matters. The challenge is to know which areas and details that are important for you and at the same time can differentiate the different tools and suppliers.

Focus instead on the suppliers and identify the one that is most likely to become a long-term partner ensuring your success. It is far more important to select the right supplier than selecting the right tool.

Tore Brathaug

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

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

Doing the Right Thing?



This post is inspired by a definition found in the comments which followed Oleg's post and a discussion with a friend of mine who is PLM responsible at a small car manufacturing company.

First, let's apply the definition of processes and practices, that Michael Grieves use:

“Processes are well defined routines that give organizations the outcomes they desire. However, a great deal of what companies do, such as innovation, is driven by a desired end result, which is what practices are all about. “

You could also rephrase this to "processes are about doing things the right way”; dictating how work should be done. Focusing on the what instead, we would allow decisions by knowledged workers and IT automation determine much of the how.   

To generalize, traditional PLM implementations are focused on data capturing and processes (according to the above definition). Capturing data in a common repository enables transparency, access and being able to connect the dots (data) in new ways. Usually, we then cover the data with a process layer, targeted for effective and repetitive management of that data. 

But what if we would focus on supporting “doing the right thing” instead? What would that mean? For me, that would mean focusing our effort on data, functions to manipulate, communicate and collaborate around it. Another critical role for a PLM tool would be to have capabilities to analyze that data, helping workers make informed decisions which would allow them to “do the right thing”.  

Are we on to something? What about "best practice" processes? Could we say that we can deliver value without them? Can we do this without being banged in the head by sales and marketing saying that we can't sell without a out of the box process support?

What if we state that "best practices" are on data level, basically how we choose to model the reality in a smart way? But to not become a consolidating integration hub, we would have to have tools to manage that data accordingly. With decoupled features we then address "best practices" of managing data without "tying it down" with processes.

To not "just" become a good data management tool we would need to wrap the whole thing with communication and analytic capabilities allowing the user to collaborate and making “the right” decisions.

What would we have then?

- A replacement to mail, excel and other data silos, which was exactly the thing that my friend at the car company was asking for; a tool which would allow him to still have the required flexibility but with transparency and the synergy of previously disconnected data sets. This would give him the means to reach the desired result in a perhaps unstructured way but secured via data and supported through communication and visual analytics. Wouldn't that add value? Wouldn’t that create an innovation pull as we then focus on "doing the right thing" rather than paving complicated cow paths?

Robert Wallerblad

www.infuseit.com