Get Savvy about PLM

I saw a chart the other day being used to describe usability and it was one of the most concise images on the importance of usability I have ever seen, yet the presenter did not really explain the chart which was unfortunate. I did not notice a reference source on his presentation yet I know it came from other sources (which is why I am not citing the presenter directly). So in the spirit of research (being information from many sources) I’ll attempt to review the points the chart was making.

The definition of Usability is a time based definition. Initially DISCOVERABILITY and CONSISTENCY are most important. How easy is it for an application user to discover functionality without resorting to manuals and training materials. When moving from area to area of an application how consistent is the presentation of the user interface so that relearning leverages that consistency. Microsoft is a classic example as more and more non-Microsoft applications boast of the “Outlook” interface. But that interface is not best for all systems – so when looking at Usability – look for discoverability and consistency initially.

The problem however, is that the definition of usability often stops there – and later when the honeymoon is over, the other components of usability become more evident. After the initial learning – how much is EFFICIENCY and CAPABILITY expanded. After discovery – do efficiency improvements continue or go flat? Can you expand your use of the tools through leveraging the additional capabilities of the tool beyond the initial need? These aspects of usability are not readily addressed in product demos and are not realized until the user has completed the honeymoon or nightmare of the first side of the usability question.

In the best of both worlds you would want to look at solutions that have the near term and longer term definitions of usability being satisfied. In reality it may be a compromise – The paradoxical definition of usability explains why difficult to learn systems are adopted and have productivity gains despite the lack of discoverability and it also explains why highly discoverable systems become flat for efficiency gains downstream yet may be widely adopted by the masses.

So when you go into your system selection process with Usability criteria – be sure to include all 4 components of usability – not just how easy is it to use initially. Again look for DISCOVERABILITY, CONSISTENCY, EFFICIENCY and CAPABILITY. When you have all 4 you have a system that will serve you as a longer term solution.

Copyright 2007, LR Hirr, All Rights Reserved

There are many readily available references to ERP Selections, CRM Selections and so on… The principles are generally the same for PLM. First and foremost – technical requirements and technical qualifications are not the ONLY criteria by which to judge a system. Neither is price. The canned demonstration is also not the best means to select a system (it’s too easy for vendors to use smoke and mirrors).

Generally when we examine solutions for the customer we make sure the following criteria are included in the analysis and we work with the customer to assess:

Technical Qualification – The technical qualification is still a first qualification and always will be. But the qualification should be based upon a clearly defined requirements matrix that the vendors must show evidence of meeting, making distinctions between out of the box functionality, configurable functionality, and customized functionality. Requirements should be weighted based upon business need and vendors should be evaluated with regards to those needs. Do not use the canned demo as evidence of meeting the requirements. Walk thru every requirement in detail with the vendor showing you exactly how that requirement is met.

Business Standing – How long has the vendor existed, how have they funded growth and development? What percentage of the customers are paying maintenance (i.e remaining current)? If publicly held – what are the analysts saying. Are their customers in the same industry verticals as your company or are the customers similarly modeled as your business? Will the vendor be there for you in 5 years? in 10 years?

Customer Support – How well are the customers supported? How is helpdesk support provided for you as a customer. What forms of training are available? Is there an “active” user community and how is it controlled/supported by the vendor? Are there local groups or readily available forums for end-users, administrators, etc. Are there larger events where training, exchange of experiences, and networking is supported?

Referenceable – Does the vendor have referenceable customers in your business sector or of your business size, using versions of the system you would be considering? When a vendor gives you a reference name it is often an executive who purchased the system, ask to speak with members of the deployment team, and to end users – that is where you will get the real story. How long has that customer been a customer – are they actually in live production use of the system or are they still in the honeymoon of getting the system set up?

Roadmap – Does the vendor’s roadmap provide a path for your company to grow with the vendor as a “partner”- what happens with your data when you “outgrow” the current toolset. Are there modules that scale with your business growth? Does the platform support appropriate technologies to remain current on your overall enterprise infrastructure requirements? How has the vendor demonstrated commitments to past roadmaps?

A system could meet every one of the technical requirements and come up severely lacking in the other criteria and without a thorough examination of all aspects of the relationship you could be throwing good money into a system that will fail due to the non-technical aspects listed above.

Copyright 2007, LRHirr