Get Savvy about PLM

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

A case study:

Company Profile:      Semiconductor Equipment Manufacturer

                                    $120M Revenue

                                    Field Service Engineers providing warrantee service globally

Labor savings from PLM: minimum $24,000/yr

Situation:

Field service personnel often have to replace parts on customer systems.  The parts are large and highly specialized.  The FSE has to identify the correct part number to place orders for airfreight delivery to assure a rapid resolution to the customer situation.  To facilitate their work, their department head instituted a process to provide part drawings for his personnel on CD’s.

Process:

The company developed its product designs on advanced 3D CAD systems and the designers and drafters had complete electronic drawings within the CAD system, however were not generating formats that were readable outside the CAD application.  As a result drawings were being plotted using a D size printer, filmed to microfiche and placed in microfiche files at various locations within the manufacturing environment.  So all parts were put through the following steps:

Note that at no point is the initial plotted drawing retained.

Once the cards were in the files then the field service process would step in.  Their process looked like this:

Note again the paper drawing and even the microfiche do not serve any purpose other than a transition data set.  This process would be repeated quarterly for hundreds of parts to assure that the part record held by the FSE’s was reasonably up to date. 

So to look at the cost of this process lets’ make some basic assumptions which may be simplifications however they will get the point across.  Assume a clerk is performing the work so might be earning $14/hr or $20/hour burdened.  This is a reasonable estimate for most high tech companies. 

The document control portion of the process for generating each microfiche card and filing it is roughly 45 minutes.  The field service clerk is then spending approximately 15 minutes per item.  So for each drawing one hour is spent taking an electronic file to paper to film to paper and back to electronic format.  Multiply that by 300 drawings per quarter or 1200 hours per year. Which means that $24,000 is spent on this one process per year, not including the risks that a part has changed in the interim and that the FSE obtains out of date information.

With a PLM System in place a few months later, the same situation looked more like this:

And the total process takes minutes rather than hours with direct access to the latest information needed by the FSE.

So with one minor process, not highly visible to the corporation, a minimum of $24,000 of labor cost was recovered for more valued activities per year.

Copyright 2006, LR Hirr, All Rights Reserved