Get Savvy about PLM

I attended an incredible meeting of some of the top minds in PLM at Purdue University’s PLM Center of Excellence last week and while there was far too much discussion to cover in detail, I found Dr. Grieve’s closing comments to be worth noting. With his permission, I am including just a few highlights - very paraphrased as he is an orator worth taking note of and I just can’t take notes that fast…

Some of the key points he raised were:
* The need to understand that PLM involves a paradigm shift - from atoms to bits - as our technology allows for more and more simulation of the real world - we can do more “virtually” to pre-build our designs and even our manufacturing plants - without physical prototypes - a savings of time, material, energy and more.
* People issues with PLM are bigger than the technical issues - to extract value from PLM means educating people about the possibilities that the PLM tool training alone does not provide (investing in the subject matter training is as important as the software training and perhaps more so).
* The absence of PLM related metrics is concerning but we should not allow the absence of metrics to paralize us.
* The CXO’s who are investing in PLM KNOW it is NOT optional and they KNOW that business survival depends upon their execution of PLM.
* Multicultural teams and virual teams pose new challenges to business. Isolated groups of people are not equal to globalized teams where literally everyone is working on the same development work around the world. Dealing with the time zones for globalized team communication is a problem we haven’t even begun to address.
* The vendors have been focused on PROCESS - yet innovation does not conform to processes. By definition process stifles innovation. PLM needs to enable PRACTICE - the creative side of product development. Innovation does not come from workflows and process maps.

I enjoyed meeting the folks at Purdue and the participants of their PLM Advisory Board. Keep your eyes open for good things in PLM from Purdue.

Copyright 2007, LHirr, All rights reserved.

Yesterday I got my weekly email from CIMDATA with their PLM Industry Summary - I regularly peruse it for updated information and particularly tend to find thier weekly polls informative. This week’s poll however concerned me and it surprised me when I read the analysis.

This week’s article is not yet posted on their website - however it should be located at http://www.cimdata.com/newsletter/archive.html in the next few days.

The bottom line was that CIMDATA concluded that the following:

should be viewed as positive evidence that PLM is coming into the forefront of corporate understanding. They conclude that 60% of the respondants place PLM in the “strategic” bucket. I disagree with the analysis. CIMDATA polls are fed by consumers of CIMDATA’s weekly updates on PLM - therefore their predominant respondants ARE knowledgeable regarding PLM regardless of what department is responding. What the poll does NOT do is have evidence that companies that are not engaged in leverage PLM actually would answer the question the same way. My concern about the poll results and the analysis is that it could lead people to be complacent regarding the need to educate senior management regarding the business impact and benefits of PLM.

So many companies I see still regard PLM as not well understood, as an engineering issue, or lacking value - not because of the consumers but because of the need to show clear evidentiary proof that PLM is a financially necessary business investment for the executive buyers. As I have mentioned before - too often I see the PLM decision being driven by the CAD decision, and when that happens the PLM system will rarely shine as a productivity and process enabler.

So be careful what you read into poll results such as these.

Copyright 2007, LHirr, All Rights Reserved.

I was reading a book authored by my friend Steve Bell today. In his book

Lean Enterprise Systems

he raised an issue that resonates with me. He cited a study in the International Journal of Logistics from which he concludes “in many organizations 99% of the information processing activity is wasteful…” as a result of the “improper use of IT.” His comments resonated with me due to the fact that PLM systems can be viewed as product information “meta” data vaults or “file” vaults or a combination thereof.

The question of what information belongs where plagues corporations and the enterprise systems that they use. Which system is the master and what system is the master of what data. Some simple rules to live by are related to how the “change” of that information impacts the resulting product. Some examples are:

Changing warehouse and bin locations - does not change the actual product so should not be controlled with PLM workflows

Changing suppliers - “may” change the output product depending upon whether the supplier is a distributor of standard stock items or whether the supplier is actually a contract manufacturer who uses production methods that rely on a “recipe” to produce the output - so the vendor must be qualified and the recipe would need validating.

Changing coatings - qualifies as a form, fit, function change and must be treated as revision controled - yet may be managed at a metadata level not in vaulted files, thus is a change control issue for PLM workflows.

Changing lifecycle status - crosses a boundary zone - defines purchasing decisions, yet some companies will treat this as revision controlled (board changes from prototype revision to production revision. But it changes the design change rules followed by a company.

Changing buyer designations - again this is procurement information that is not to be controlled by the PLM system - yet impacts product change decision processes in terms of when changes occur - who should be reviewing the changes.

So the challenge is to define what data is “owned” by which systems, and what data is “consumed” by which systems. The resulting systems integration requirements can be very significant - and need to be thought out very carefully. And perhaps even ask the question is it integration that is truly needed or is it that the data is needed to be merged for specific repeatable processes - but let each system own its own data and use the right tools to access and view the right data. The tools exist…

Copyright 2007 - LHirr, All rights reserved

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

One business practice we get asked about frequently by our customers is what to do about part numbering and how PLM systems work with various part numbering schemes.

I won’t hide the fact that I am very biased about part numbering methodology. There are two primary forms of part numbers - “intellegent” and “sequential”.

Intellegent numbers have meaningful significance within the number - and in that they serve as a quick means for visual recognition of part type, product class, supplier, operation process, production phase, or other similar breakdowns. There is often some “sequential” component within the part number. The intellegent part number is a favorite in the small -mid sized businesses that have had to operate predominantly manual engineering practices and have a mid-ranged ERP system that is not particularly restrictive about part numbering. So the part number itself acts as a “database” of the part information. The problem that frequently arises is that a part may change “classification” but not really change form fit or function - such as switching from manufactured to procured so the company faces a process decision - change the part number just to keep the data “correct” or leave the number as is and live with the incorrect meaning behind the number.

Many years ago Hewlett Packard conducted a study on the role of intellegent part numbers in maturing businesses. The conclusion of the study was that as a business matures and grows - the viability of maintaining intellegent part numbers as a business practice became increasingly costly and in the end the companies with sequential numbers were able to more easily adapt and evolve as business entities. Businesses that have grown by merger and acquisition find the intellegent part numbers mire the business down as each entity brings a different “decoder” to the numbering scheme - making things more and more complex.

The benefit PLM brings is that part numbers are a unique identifier - the availabilty and access to all of the classifications that were being manipulated within the part number are actually captured as their own data fields. Changes to those data sets that are not changing form fit or function are not forced to remain faulty nor does a new part number have to be generated. Thus the sequential number is easy to leverage. Most PLM vendors will allow the enablement of using intellegent part numbers (in part because the customers demand it) but they will all acknowledge that intellegent part numbers are not a recommended business practice. In fact to implement automated generation of “intellegent” part number schemes in PLM systems often requires custom rule sets or even custom SDK code to deploy within some PLM systems.

The challenge exists for companies “converting” from intellegent numbering systems to sequential numbering systems. Some companies have hard coded integrations that parse the numbers for other systems - and that means to go to a sequential system some integrations may have to be reworked. But for many companies - it is not a requirement to renumber legacy parts - but rather to pick a time and move sequential from that time forward. For cultural acceptance it is often easiest to mark that “time” as being when the company deploys PLM for the first time - setting a best business practice in place along with the tools rather than forcing the tool to perpetuate a bad practice.

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

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

Over the years this topic comes up at every customer we work with.  CEO’s are getting told time and time again that SAP, Oracle, even Great Plains and Fourthshift can manage corporate product information either as effectively or better than the PLM vendors who have established the offerings.

ERP is strong for what it does:

• 10-20% of product costs are controllable after development phase
• Production asset management – physical warehouse 

ERP FOCUS:

• Build and plan
• Order management
• Forecasting
• Lightweight data handling
• Data object and data field integrations
• Reporting and analysis tools
• Transaction centric

PLM has different but compatible strengths:

• 80% of product costs are defined in development phase
• Information asset management – data warehouse 

PLM FOCUS:

• Change management
• Design and collaborate
• Security
• File vaulting
• Heavyweight file handling
• Deep file level integrations
• Complex object relationships
• Process and workflow centric

Here are situations we’ve encountered that show these differences:

EXAMPLE 1:

A major aerospace company was planning on implementing a tier 1 ERP system complete with PLM functionality.  The project team had a well established set of requirements for managing product information, change control, bill of material structures etc.  They had down selected the PLM suppliers to a Tier 1 ERP company and a Tier 1 PLM company and put both products thru a serious set of qualifications scripts - the ERP product did well on the functionality stand point however because it is a transactional system at it’s core - it failed miserably on the delivery of files and product information to end users due to poor file management performance.

EXAMPLE 2:

Another company, an equipment manufacturer was assured throughout their ERP deployment that the system would be more than capable of replacing the existing in house PDM system.  After 9 months spent preparing the ERP system, 2 weeks prior to production cutover the project team discovered that core workflows used in the PDM system would not work within the new ERP system.  Because ERP is very rules based and forward transaction focused, the concept of modifying a change order while in a routing was not supported, nor could a change order be backed out to make the updates - the only solution would be to fully process a change order, then issue a second change order with the correct.

EXAMPLE 3:

A mid tier ERP company claimed to offer a work in process system to provide change management and document control for bills of material.  The initial assessment based upon the vendor claims was that the customer, a small electronics manufacturer would be able to use the system for change management to assist with their needs to conform to FDA, RoHS and other regulatory information management situations.  With moderate investigation, it was found that the workflow was an approval routing with no associativity to documents and/or item masters - it was purely a signoff router.  In addition, the items and associated documents were not version controled at all, nor were permissions for access selective to protect “released” items more tightly than in-process items.  Once again, an ERP company treated information as if it was a transaction, not subject to version control or change control and could not adequately act as an information vault.

Some of my favorite quotes over the past several years are:

“You know too much about what PLM should do for you to be satisfied with our offering - our system is really intended for our captive customers who have never had a change management system before” - a Tier 1 ERP sales representative

“If I used our ERP system for change management I’d have to triple my document control resources or take 3 times as long to process the change orders we handle.  The ERP system was a box, and empty box with 4 sides, and we would have had to define everything in the box to even begin to use it for it’s PLM functionality” - Doc control manager at an equipment manufacturer in reference to a Tier 1 ERP system.

It is encumbant upon the customers of ERP to understand what ERP systems can or can not do - beyond what the ERP companies are telling the CXO’s and the ERP Shareholders, because the reality often does not match the sales pitch.

Copyright 2006, LR Hirr, All Rights Reserved