Get Savvy about PLM

February 6, 2007

PLM: In house or Hosted?

Filed under: Cost and Benefits,Mythbusting — Laila Hirr @ 1:08 pm

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

On-Demand or In-House PLM

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

January 18, 2007

Should your PLM system live on Oracle or MS SQL?

Filed under: Enabling Technology,PLM,System Selection — Laila Hirr @ 9:54 pm

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

January 6, 2007

Traceability – can you find products affected by a component failure in the field?

Filed under: Cost and Benefits,Information Change Management — Laila Hirr @ 8:10 pm

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

December 18, 2006

Failed PLM Deployments – Part 3

Filed under: Lessons Learned,Success or Failure: Lessons Learned — Laila Hirr @ 12:25 pm

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

November 16, 2006

Failed PLM Deployments – Part 2

Filed under: Success or Failure: Lessons Learned — Laila Hirr @ 10:55 pm

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

November 2, 2006

Failed PLM Deployments – Part 1

Filed under: Lessons Learned — Laila Hirr @ 10:06 pm

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

October 26, 2006

Who really uses Product information?

Filed under: Mythbusting,Organization — Laila Hirr @ 7:36 pm

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

October 24, 2006

The hidden costs of exchanging production information

Filed under: Cost and Benefits,Mythbusting — Laila Hirr @ 12:12 pm

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

October 19, 2006

Myth or Fact? Your ERP system can manage Product Information

Filed under: Mythbusting — Laila Hirr @ 3:19 pm

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

October 12, 2006

Field Service needed Parts

Filed under: Cost and Benefits — Laila Hirr @ 5:13 pm

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:

Drawing to Microfiche Process

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:

Microfiche to CD

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

« Previous Page

Theme: Rubric. Get a blog at WordPress.com

Follow

Get every new post delivered to your Inbox.