Get Savvy about PLM

One of the big project level benefits of a PLM implementation is that most PLM solutions can be rolled out to the users in stages. New PLM processes and workflows and modules can be incrementally added after the foundation is laid - this is GREAT and it is TERRIBLE.

It is great that PLM can have core functionality within weeks or months of starting a deployment - systems like Arena Solutions or Teamcenter Express that target the small businesses can be rolled out literally in 1-2 weeks if your business can accept out of the box workflows for change management. For the mid-sized businesses systems such as Agile and Windchill can typically be deployed within 3 to 4 months with core functionality in place. What addes time to these types of deployments is typically dealing with preparing the training program and process documentation associated with implementing these solutions. With the larger enterprises implementing Windchill, Teamcenter or Enovia the enterprise complexities come into play earlier and take longer to deploy at 6-9 months, but even the large enterprises tend to only see a small piece of the PLM vision and only obtain limited benefit due to stopping at change management.

What is terrible is how many PLM systems get implemented without an enterprise roadmap that takes the implementation beyond the foundational deployment. Change management is put in place without enabling the part classification (to enable reductions of duplicated parts). BOMs are built without enabling Multisite or BOM variants (tracking the site specific build data or the engineering vs. manufacturing BOM). Manufacturer and Supplier data is managed with the product information, yet the external partners are still sent CD’s or paper and kept outside the loop on major changes that impact their contribution to the finished product.

Why is this? It is the curse of the initial success of a PLM deployment. When an ERP system is rolled out for the first time (after 2-3 years preparation) it gets turned on with 90% of the functionality in place and then is very cautiously modified mostly for tuning purposed. PLM on the other hand can be rolled out successfully with only 40-50% of the business functionality implemented and considered successful at which point the senior management often thinks the project is done - losing the vision for the other 50-60% of business benefits that have yet to be obtained.

It is this tendency that makes the initial long term roadmap so critical. Without defining what the long term business objectives are that the PLM deployment is to address the execution typically halts after the “engineering” system is in place yet the enterprise enabling capabilities have not even been tapped into. The selection of the system is often targeted at a short term objective, then the longer term benefits may be hindered or require a second PLM system to obtain the next tier of benefit. (See Gartner’s

Predicts 2008: Manufacturing IT Becomes More Than Business IT

, December 2007)

No company would deploy ERP without a 5 year plan. Yet PLM, which impacts 30-40% more end users than ERP, typically is deployed without a similar long term plan. Then the users and the management end up stymied about why the benefits expected from PLM have yet to be achieved. (See Aberdeen’s July 2007 report -

Profiting from PLM: Strategy and Delivery of the PLM Program

)

What is your PLM roadmap?
Have you tied the PLM implementation to true business benefit or are you just implementing a data vault?
Do you have a phased plan that identifies the business value obtained from each and every phase?

What many companies will find is that for true understanding of what is possible and what to do to build that roadmap - it takes experts in PLM and in your industry issues to help you build that vision. To expect the IT or Engineering department to vision cast is often not possible - as internal resources often do not have the subject matter or process expertise to cast the PLM initiative into a plan that ties the implementation to direct business strategy.

All PLM systems are not created equal. When we work with our customers to select a PLM system we evaluate the entire business situation not just the engineering department. Too often PLM is viewed as an engineering system only and yet in every case we’ve seen it put in place successfully, PLM rapidly outgrows the engineering department and becomes an enterprise wide, process changing, paradigm shifting, productivity enhancing system. Manufacturing users of PLM often exceed the engineering users, and Field Service also rapidly jumps on board to get proper information on the products they service.

The irony is that all too often, PLM selections are made in the shadow of a CAD selection, being viewed only as a means to handle CAD vaulting. This is a waste and will result in less than optimal use of the PLM system. In addition, it means that the system selection for PLM is driven by CAD and not by a systematic business benefits, enterprise wide justification, and then executives percieve that they have a “qualified” system and ignore the fact that key process needs are not met by the system.

In my opinion - these types of selections are as poorly advised as selecting your PLM solution based upon your ERP system. In both cases the PLM solution has not been selected to meet your full business needs but has been selected as a “default” decision.

Copyright 2007 - All rights reserved LHirr

Okay - I’ve been biting my tongue long enough regarding the shifting sands of the PLM space. The past year has seen massive movement among the players and the question is not really how do these deals impact shareholders but how does it affect the longer term delivery by the vendors to the customers.

Here are my personal views of the changes…

Agile-Oracle
I have been up close and personal with Agile customers for years. I service systems that range from Agile 6 to Agile 9 and see the same trends over and over again - users tend to use Agile well - out of the box functionality is great BUT Agile has had ongoing issues regardless of version with system stability and with the responsiveness of the support desk. Every version of Agile has had some sort of workaround for stability that involves “restarting services” 3-5 times per week to keep the systems stable - that has always concerned me. In addition, Agile helpdesk has been notorious for assigning issues to “marketing” or “engineering” which customer after customer has described as a “black hole” from which the issue never gets resolved. The overall product is good - but for these components (stability and support) to remain issues for 6+ years as the most common complaint I encounter is surprising. So my biggest question on behalf of the customers would be - will Oracle do better? I would expect so. Oracle actually can make the connectivity between Agile and Oracle databases work - but will MS SQL be abandoned yet again? I also can’t imagine that Oracle helpdesk can be worse than Agile’s was - so I hold hope but it will take time for everything to shake out.

Siemens - UGS
UGS has been on the auction block many many times over the last 5 years - First the SDRC and UGS pull into EDS, then EDS spin off back to UGS (held by investment companies) and now being bought by Siemens. Like Agile - I’ve been up close and personal there too - but I see a big difference. UGS has maintained a rock solid product consolidation roadmap thru all the changes. Any one who talks to the management at Seimens/UGS will be getting a consistent message that has fundamentally not changed for the past 5 years - a commitment to making the customers succeed and to bringing about the synergy and merging of products. The main problem has been the distractions of change - no matter what - that much change means that cultures have to blend, work things out, settle - and it can’t help but slow things down. It is commendable that the roadmap has been carefully adhered to and that the customers have as a result remained highly loyal.

Dessault - MatrixOne - Connesio - … and what else
MatrixOne had all but disappeared from the PLM market space here in the Pacific Northwest. I maintain relationships with many of the vendors and their folks had vanished - next thing I knew Dessault had picked them up and also not long after picked up Connesio. That was on top of the already mixed up combination of Enovia, SmarTeam and PDMWorks. I honestly haven’t figured out the strategy. Now PDMWorks “Enterprise” is a repacked renamed form of Connesio. The analysts are confused, the customers are confused - which system will become the mainstay? How is scalability intended to be addressed? What is the flavor today? Dessault maintains presence thru it’s offering of Solidworks to the mid-market and leverages that presence to catch the unwary and most needy businesses into PLM solutions that are still partially complete.

What of the others…PTC, Arena, SAP - these haven’t had the acquisitions to deal with so I’ll talk about them next time.

Copyright 2007, All rights reserved - LHirr

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 CONSISTANCY 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 consistant is the presentation of the user interface so that relearning leverages that consistancy. Microsoft is a classic example and more an 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 consistancy 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 thru 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 dispite 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, CONSISTANCY, 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 is a historical tension between a corporations need to innovate and its need to produce. Fostering innovation is not possible within the rigor of production demands and successful production practices are not possible within the highly flexible framework of good innovation. This tension has been studied and analyzed over the years. The conclusions of the studies are that the most highly successful companies in the areas of both innovation and production, are the companies that embrace both sides of the coin - fostering a culture of innovation while observing the required rigor within the production framework.

When this is understood it becomes more clear why PLM and ERP system MUST support different corporate needs:

It is these very differences that show it is a myth to believe that the systems designed to manage your physical inventory with rigor and structure, could be manipulated to become the flexible systems needed to foster innovation. The PLM vendors don’t even pretend to do the business of ERP systems - why is it that ERP systems believe they know how innovation in design should be managed?

Copyright 2007, LR Hirr

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