Get Savvy about PLM

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

I recently did an examination of the tradeoffs of using hosted versus on-site PLM systems.  The decisions are challenging and there is no particular right or wrong answer but figured it was time to share my findings. 

Traditionally PLM systems have been implemented at a manufacturing site with very much a similar business implementation paradigms as used with ERP systems. However, as with CRM and ERP systems, there is an “on-demand” (that is a hosted) option. So which to use? Small emerging businesses have very different decision based issues than the established businesses. So here are some of the issues that the range of companies would need to examine in the decision of what type of deployment to consider (pick on image to see full sized view):

The challenge is to make a decision when a company is sitting near the boundaries of one profile or another. This discussion has not even covered the cost tradeoffs in the selection process - only the business factors that should be weighed in on.

Copyright 2007, LR Hirr, All Rights Reserved

I was preparing to set up the basic framework of a commercial PLM system at a customer site recently and ended up finding a engineering vs IT debate in progress. Engineering wanted the most pre-built quick to deploy system the selected vendor could provide so readily signed a PO with the vendor for a solution that required the use of MS SQL 2005. When I arrived to do the readiness check, I found that IT was adamantly opposed to MS SQL and would prefer the route of implementing the next tier PLM system (requiring more configuration work) in order to remain with their database environment - Oracle. Thus the age old debate renewed itself. Personally I don’t have a preferance - there are business decisions that warrant the use of either system. It was getting past the hyperbole that I realized was really the issue as this topic does come up often.

So first what are the top tier PLM Vendor trends with supporting the two environments.

Agile - Supported Oracle and MS SQL when they first launched, withdrew support for MS SQL 5 years later, and recently renewed support, September 2006(see http://www.agile.com/pressreleases/index.asp?view=566
Dessault - Supports MS SQL as of November 2005 (see http://www.3ds-microsoft.com/news/2005%2011%2007.pdf)
PTC - Hot off the press - announcing MS SQL support as of Jan. 17, 2007 (see http://www.tenlinks.com/NEWS/PR/PTC/011707_microsoft.htm)
UGS - Has supported MS SQL since October 2004 (see http://www.ugs.com/about_us/press/press.shtml?id=3856)

Why is it that these companies are willing to invest in the architectual changes required to add the support for MS SQL. Obviously this was not a decision to be taken lightly. The NUMBER ONE reason is that the buyers of PLM systems today are in the “mid-market” and the majority of mid-market companies struggle with Total Cost of Ownership (TCO). While many may argue that Oracle is very cost effective, it tends to be the long term costs of skilled Oracle DBA’s that drive the TCO up.

Yet the bias I hear “against” the use of MS SQL - is often based in the historical distrust of Microsoft and concerns about security holes - so I found the linked report by David Lichtfield, fascinating in that it really addresses the question of the security holes “myth”

As I said - I don’t really care which database server I setup customers PLM systems on. The ones I’ve deployed that use both - don’t seem much different from the adminstration of the PLM applications in and of themselves. The vast majority of the time the configuration does not involve even interacting with the database at the database server level after the initial database creation. So if the install scripts work, and the customer wants one over the other - I’ll make sure I understand the reasons, advise them on any issues and move on.

Copyright 2007, LR Hirr, All Rights Reserved

One company I spoke with had a problem that was far from unique.  The company had complex machines in factories around the world.  One line of their machines had numerous computer components in it - including an OEMed CPU board (of a specific revision) that was recalled by the manufacturer for safety reasons.  Not surprisingly all systems had to be checked to see if the specific board revision was on the system for replacement.  Because the company had relatively low product volumes it had never considered tracking the system assemblies to the revision level of the components on their machines nor to the serial numbers of the OEM’d parts.  So the only solution was to send field engineers to each machine that had been shipped in a 6 month window (that was as tight as the window could be narrowed to to find the boards).

 So the company stocked the field personnel with replacement boards and sent them around the world to replace the unsafe boards.  Lets look at some of the costs associated with that effort

1) shipping boards to field offices

2) field personnel scheduling with each customer

3) travel and lodging for most customer visits

4) shutting customer production down for “inspection”

5) discovering X% of boards were not affected

6) replacing Y% of boards

7) running short of replacement boards and waiting on shipments

and the list goes on.  Multiply the time, cost, disruption by every machine or customer affected.

Has this ever happened to your company?   Revision tracking of components to serial numbered final assemblies (knowing the AS-BUILT configuration) is a core functionality for many PLM systems.  If you believe that a PLM system  is too costly - consider the above scenario and how much is saved by knowing each exact system affected and being able to work directly with the customers with affected systems and not disrupting the customers that are not affected.

 We all remember the battery recalls on laptops recently - think of what would have happened if the affected lots were not identified.  In a matter of minutes one could check their laptop, do a lookup on the web and know whether thier laptop was affected.

Copyright 2007, LR Hirr, All Rights Reserved

Danger #3 - Stopping at end of Phase 1

Time and time again I see the same thing happen on deployments.  The beauty of PLM is that the benefits begin almost as soon as the initial installation and configuration is done (many midsized companies can have a live system in 1-3 months) unlike ERP deployments which at best will take 6 months and often over a year to implement.  The danger of PLM is that when the initial system is deployed the project is “stopped” because it’s implemented - but the true power has not even yet been touched.  Here are some real cases I’ve encountered:

Company A:

Using Agile 6.5 the company had determined that they needed to upgrade to Agile 9.X in order to extend change management to their outsourced partners.  The analysis of the business benefit showed that the straight upgrade would only meet 50% of their system requirements and that by leveraging the newer features (which required continued process changes and configuration changes) they could obtain over 95% of their business system requirements with the newer release.  The project was laid out in 4 phases in order to manage the business impact on the company as a whole rather than try a big bang approach.  Phase 2 would meet another 30% of the requirements, Phase 3 would meet about another 15% and a final 10% of the requirements would be met by Phase 4.  Each phase was shorter in project demands and lower in cost - and the original executive approval was based upon these findings, but each phase was to be funded as each phase was started.  But as feared - phase 1 was completed and the “urgency” of the remaining 45% of the business benefits was lost - the momentum dried up and the remaining phases were not pursued.  Overall the users had a perception that the tool never met their expectations as it was never fully deployed.

Company B:

This company deployed MatrixOne as an engineering department change management tool yet did not pursue leveraging it as a enterprise product information management system.  As a result when discussing product change management with the manufacturing organization, the perception was that they had only manual change processes because the tool was not extended across the enterprise but was only deployed as a departmental solution.  Engineering would toss a bill of materials to production and it would no longer be managed within the enterprise level vault that the company owned.

Copyright 2006, LR Hirr, All Rights Reserved

My apologies for the lapse resulting in no update last week.  To continue our case studies on failed deployments - note these are not listed in any ranked order. 

Danger #2 - Lacking top leadership

This is a common issue for all major systems implementations, however tends to plague PLM deployments more than the typical ERP or CRM deployments.  Why is that?  Often because the executives have failed to acknowledge that PLM is an enterprise issue and relegate it to being an “engineering” system.  I’ve mentioned before having a CIO refer to the corporate PLM system as E-PDM, the irony of it is that while he was touting the success of his ERP implementation, he didn’t seem to know how unsuccessful the PLM deployment was.  The exact same company was struggling to deal with change management and keeping information current between engineering and manufacturing, yet they had a system in place - the problem was the system was viewed only as an engineering vault. No one had ever considered that it would assist them in resolving change control for their product structures yet they had an E-class PLM system.  Was this unusual? Unfortunately no.  The roots of a successful or failing PLM system go hand in hand with the level of executive involvement.  The successful deployments have active engagement of the executive management and a program manager that reports to the top.

PLM systems serve the enterprise.  If in doubt go back to the article I posted on where product information is used.  And dispite the fact that most change management occurs within a document control department - having the document control department lead the charge on PLM deployments is the second most common error I’ve seen in setting the direction.  Document control departments do what they do VERY well, manage the details and painstaking processes required to manage change - the department function does not lend itself well to enterprise visioning, nor to being able to step back from the tree to see the forest.

The reality is that there needs to be top level regular visibility of the PLM deployment (not once per quarter, but more like weekly or at worst twice a month) that is clear to the entire enterprise.  I heard a CIO say recently that for a enterprise deployment he was involved in - he crafted every memo that went out to the organization regarding the status and progress, he attended the planning meetings, he championed at the executive table, for the duration of the deployment - he had a program manager yes - but he OWNED the communication to the corporation and he owned the success or failure - which guarenteed the success.  To expect a program manager at any level to gain the buy in of the company without that level of executive commitment will not succeed. 

Copyright 2006, LR Hirr, All Rights Reserved

The unfortunate reality is that some deployments fail, and they predictably fail.  I will share some case studies of deployments we’ve seen fail and the top reasons why.

Danger #1 -  Bypassing the Discovery/Feasibility Phase

At Company A we were contracted to assist with the requirements gathering and initial qualification list of PLM suppliers.  The company was bracing for major outsourcing, trying to address RoHS issues, and living with an older PDM system that was sorely in need of updating.  They had extensive workarounds to having limited workflows and had a strong need to leverage product change management with their supply chain.  They had a clear and sound business case for investing in the next generation of PLM systems and wanted to do their due diligence in assessing candidate applications.  They contracted with us to conduct the Discovery phase of their PLM initiative.  We met with stakeholders from each department, gathering requirements and developing a prioritized list of feature/functions that they would need and the business benefits to be gained from each level of capability and based upon that list began culling the list of 7 PLM providers down to a target list of three who would then have to provide a full capability evaluation to be considered as potential solutions.  This was all consistant with Company A’s IT project management directives. 

The problem arose when the internal program manager decided he needed an exit strategy - he was preparing to leave the company and did not want to leave an “open” ended status on the selection process.  Upon learning that 2 of the 7 PLM solutions had been disqualified based upon early assessment of the capabilities compared to requirements - he convinced his management that a straight upgrade of the existing PDM system was the best path and halted the discovery process and procured approvals to move forward with the upgrade, and then he left.

The problem was multifold -

1. The end users had the perception, due to the information gathering that had taken place, that the upgrade was a “qualified” selection.
2. The upgrade would not have passed the qualification process based upon the requirements to demonstrate functionality - but the vendor never had to show they could do what they said they could do.
3. The vendor would not have passed the due diligence process in that it could not provide any referenceable customers for the solutions they were offering.

In the end the deployment was considered a corporate wide failure due to lack of user acceptance and due to the “bugginess” of the upgraded offering.

At Company B we were contracted to assess the feasibility of using their existing ERP system which boasted workflows and document management as a change control tool.  We evaluated the business processes and regulations that the company had to adhere to along with accepted change management processes.  We also delved into the actual functionality of the ERP system’s solution by building a sandbox to test various concepts considered to be core to change management workflows.  This took several weeks - by which time the Director of Engineering began pressing for the “ECO” design that would be implemented with the system.  We paused and pushed back - reminding him that we were still in the feasibility phase and that any process design would be premature if developed without understanding what the tool could or could not do.  He agreed to wait, very wisely too.  Less than a week later it was evident to every member of the company team assigned to champion the effort that the ERP system would fail as a long term solution for change management and a new path was quickly taken with full executive management support.

In the second case - dispite the eagerness for a rapid solution, waiting and commiting to the feasibility process saved this company years of potential struggles. 

Copyright 2006, LR Hirr, All Rights Reserved

I attended a presentation about a successful ERP deployment corporate wide for a global company and was very interested in the various metrics used by the CIO to demonstrate how effective they had been with their deployment.  He threw organizational charts up showing where he had champions and subject matter experts throughout the corpation. His approach was very forward thinking and demonstrated he understood how important his role was at the executive table in bringing IT value to a strategic level. He then showed network diagrams to show how various business systems had been consolidated and integrated.  In a small box off by itself he had ePDM (engineering Product Data Management) as a system of it’s own.  His diagram was all the proof of his lack of understanding of what product information management was and where it was used. 

 To fully understand your business use of product information - I give you a challenge exercise:

 1) Gather a list of all documentation types in your business that contain any aspect of product information - some examples might include:

• Instruction manuals
• Assembly Instructions
• Test Instructions
• Quality worksheets
• Training books
• Marketing collateral
• Field Service Bulletins
• Engineering drawings
• CAD files
• Compiled software releases
• and the list goes on….

2) Take your organizational chart and put a mark on every box that uses product information (note this is not about CAD files or engineering drawings only).

3) Look at your external partners - suppliers and customers - and identify what percentage of them require access to your product information.

Our experiences with implemented PLM systems (which manage multiple document types, change control, version management) show that the typical organization will have no less than 50% of the employee base touching, reading, authoring product related information and often far more. While the typical ERP system is actively leveraged by 10-20% of the employee base. So if you view product information management as an engineering department or quality department issue this exercise should make it clear that your products which are your corporate lifeblood have information to be examined through almost ever facit of your business. 

 Copyright 2006, LR Hirr, All Rights Reserved

While developing a business case for one company to invest in PLM tools, we took a look at the data transfers to the supply chain.  The company had complex product structures and would use suppliers to prebuild many of the assemblies to design specifications.  Because of the product complexity, the company typically processed 60 change orders per week which then had to be communicated to the suppliers. 

 The process of communicating to the supply chain required that procurement personnel create an electronic package of the drawings, work instructions, and specifications all of which may have been updated by a change order, and send the package (either on a CD or via FTP) to the supplier.  The supplier in turn would update their files with the newer files and begin production based upon the change instructions.

 The problems came in when the supplier would fail to remove legacy files and file naming conventions were not observed so that the supplier was not always sure which documents were correct.  In addition, sometimes a more recent change would have been delivered before a earlier change order and the information gets out of sequence.

 In our discussions with the procurement team, each of the 10 buyers indicated that they spent approximately 20% of their time generating package files to send to the suppliers yet the data was already fully contained within the company PDM system (PDM having limited external capabilities compared to PLM).  To top it off, the top three suppliers each indicated that they had to keep 2 full time resources dedicated to the company due to the rate of change and the need to manage the files being sent to them daily.  Each supplier estimated that if they had direct access to the production information they could reduce the manpower costs they passed to the company by over 50%.

So for this one company - they realized they would be able to gain the equivalent of 2 resources internally and also experience cost savings from the supplier with a more mature PLM system.

The challenge however becomes then the “acceptance” of a new system that has the potential for taking jobs away if the company is in a cost savings initiative.  The flip side of the coin is when a business is facing growth - making peoples jobs more effective reduces the need to increase hiring in response to the growth.

Copyright 2006, LR Hirr, All Rights Reserved