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