I have been brought into numerous situations where a company that recently purchased a new PLM system is beginning the implementation process and almost immediately encounters a host of unexpected issues.  In many cases, it turns out the company did not do its homework and wakes up to the fact that what they chose does not meet some of their key requirements. A prime causative factor is that the company failed to define key company requirements for the PLM system. If those requirements are not clearly identified, the company will not achieve the desired PLM system functionality/behavior. This blog will discuss methods and the areas companies need to focus on when assessing alternative PLM systems.

Company Strategic Direction

A high-level assessment should be performed to understand where the company is currently and what its objectives are for future operations. Exploring whether the company is (i) looking to expand and manufacture globally, (ii) increase its product portfolio, and/or (iii) decrease the time to market are some of the areas that need to be discussed. A SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis is a great exercise to help define and verify strategic direction and goals. Key questions like “What keeps you up at night?” can also be asked. As answers to such questions are developed, it will become so much clearer as to the areas where the company needs to improve or change. Only after this information is obtained can the company intelligently consider the pros and cons of alternative software. While software vendors are very competitive and will work hard for your business, stay focused on the most important issue namely, whether the software the company selects will fulfill its requirements.

Identifying Your Requirements

One of the first yet key phases for PLM assessment is defining the requirements of what the PLM system needs to do and how it must behave. Commonly, companies will immediately focus on the tactical capabilities of a proposed PLM system.  But this is the wrong focus. Instead, companies need to think strategically. What does the company need in the way of a PLM system to accomplish its goals? Only then will the company look to the flexibility and functionality of the system and its other capabilities to determine if it will fulfill the company’s operational needs.

In many cases, we find the best way to define the requirements is to form a cross-functional team compromised of different functioning groups within the company. Team members may come from such diverse departments as Product Definition, Project Management, Sales/Marketing, Engineering, Design, Manufacturing, Product Support/Maintenance, and IT (though the composition of the team is usually skewed to engineering/manufacturing).  Individual interviews will then follow with each participating group to understand the group performs its role, what are the critical steps in performing its role, and what improvements can be made so they can perform their job more efficiently. Don’t hesitate to ask the same basic question of each group: “what keeps you up at night.” The answer to this question will provide much-needed clarity as to that particular group’s priority and concerns. When all groups have been interviewed, the data will be amalgamated and the key requirements of the PLM system can be captured and documented.

xLM has found that when we perform such interviews, we quickly surface key requirements. Interestingly, we sometimes identify simple process changes that can be immediately implemented to improve efficiency leaving us to wonder why no one thought of this until the deep dive interview.

Prioritization of Requirements

Once the PLM requirements are defined it is essential that they be prioritized based on relevance to the company as a whole. For example, consider how the requirements relate to the strategic direction of the company. Relevance should be given to those key activities that the company needs to perform today and those areas where the company wants to move into in the future. Let’s take the example of how the company wants to handle engineering changes. Is the current methodology the most effective or does the company need to move to a model-based engineering approach with the goal of eliminating engineering drawings within 5 years? Should the company’s IT strategy approach be that of running a cloud solution that supports SSO Single Sign-On with the company’s Active Directory?

In addition to prioritizing the requirements, key real-life examples should be associated with each key requirement. This will better formalize what the requirement is and not leave it open to interpretation.  In our opinion, this is a crucial step that is often not performed or, if performed, is not done correctly which will inevitably lead to ambiguity and errors down the road.

Finally, prioritizing the requirements will help to better scope out how the new PLM system should be rolled out. Rolling out or implementing PLM will be left to another blog but it is important to point out how accurately prioritizing requirements can reduce the problems encountered during the rollout. It will allow us to break down the rollout into manageable phases where initial phases would be geared to the most beneficial requirements.

Validation with PLM Vendors

Once the above steps are completed, it is time to send our RFI (Request for Information) to the various PLM players. In many cases, this will be in the form of an Excel file listing the different requirements and asking how well does the specific PLM system handle the requirements. Usually, there is some sort of rating scale associated with each requirement. We typically recommend limiting the requirement list to no more than 30 key requirements. Having too large of a requirement list will result in the vendors’ inability to really focus on the key ones. As we receive replies and review them we can eliminate some of the PLM companies. Not surprisingly, in most cases, we find the PLM vendors will state they can meet the requirements. So, keep in mind “meeting requirements” is open to interpretation and what you may have in mind for meeting the requirements is vastly different from the PLM vendors who are under pressure to sell products.   This is where having actual real-life examples come into play. You can very specifically address whether a particular software will solve the real-life issue. Once you can limit the number of PLM vendors to a manageable number of 3-4, it is best to have them demo their solution.

Another approach that works well is to filter the PLM vendors list down to 1 or 2 and have them validate the requirements live with the actual user scenarios defined above (note some PLM vendors may charge for such a detailed exercise as this will take time and resources to accomplish. This cost may be well worth it to see the system in action using specific company user stories). We really believe in the statement “Trust But Verify.”   You must be sure that your requirements can be met. Blind reliance on a salesperson’s statements can prove costly. And pay attention to the details. A general statement that “our software can satisfy all your needs” is not the same as observing in real-time how it will solve real existing company issues. Take a simple example of handling auto part numbers creation. I am sure all PLM vendors will claim their software can handle auto part number creation. But the “real” problem is how auto part numbers work across different ‘classified’ parts like mechanical, electrical, and software with each classification having its own specific auto-number format. And don’t let your guard down. PLM vendors may respond and challenge such requirements stating that such concerns will no longer be valid because the PLM system can handle the requirement in another method or is not required when using the PLM system. When confronted with such statements, drill-down and have your potential vendor show in detail how its software can circumvent the issues.

In many cases the PLM vendor will offer to demonstrate their software capabilities and how it will specifically solve the company’s problems or provide the additional functionality needed… often free of charge. This presentation can be very useful to the company’s evaluation process as many of the PLM vendors are well-trained in performing such demonstrations. Though, it is important to keep in mind that PLM vendors’ primary motive is to sell their PLM systems.  And that is why we believe it is best when such analysis is performed by a neutral party that does not sell PLM.  xLM Solutions is the type of company that can perform this analysis and provides an objective determination as to which PLM system best satisfies a company’s needs.

Choosing the PLM System

Once the demos are completed,  it will be time to choose the PLM system the company will purchase. It is at this time that all of the factors must be considered. The following are what we consider among the most important inquiries:

1. How well will the PLM system meet your company’s requirements and is it sufficient to accommodate the needs of the company as it grows and evolves in accordance with its overall strategic direction? We believe this is the key factor. Although not an exact science, having the cross-functional team providing input and with their ranking of the various alternative PLM systems presented, the company should have the information it requires to make this key decision.
2. What will be the cost of the PLM system and the annual maintenance/subscription fee in the future? How negotiable are the terms?
3. Speak to reference customers. Don’t treat this task as a check the box matter. This is not a 5-minute phone call. Discussing the system’s capabilities with reference customers in your industry is invaluable. These people have implemented the system and know how it works, its strengths, and its weaknesses. What was their biggest disappointment? Obtaining their feedback on the PLM system will impact your decision. If feasible, visit with your counterpart, and spend a few hours learning everything you can.
4. How do you see your relationship with the PLM vendor? Do they address your questions and concerns in an easy and timely manner? Do you have a good working relationship with them? Do you feel that if you have issues/requests after your purchase of the software they will make your issues a priority? Your reference customers may be the most important source of this information.

Both the executive team and the key stakeholders should understand that there will be trade-offs when selecting the PLM vendor. For instance, it must be understood and acknowledged that where the PLM system that will best meet the company’s functionality requirements cannot be purchased due to cost constraints, expectations must be reduced.

Conclusion

We have discussed some key issues in performing a PLM purchase analysis. Keep in mind:

• Do your homework and properly define the key requirements
• Make sure requirements are related to the company’s processes and strategic direction
• Associate the requirements to actual use cases within the organization
• Demonstrations of functionality and evidencing that the software’s capability is sufficient to satisfy defined requirements should be an absolute condition before signing on the dotted line; or where the vendor states that the software will eliminate existing company problems insist on the vendor proving this out in a real-life presentation

With the requirements analysis/ranking and evaluation of the non-technical factors, the company should be in a good position to make a decision.

xLM Solutions has 20 years of experience performing successful independent PLM implementations. We would be happy to consult with you on how best to conduct your PLM assessment or help you choose your next PLM system. Contact us today.