Get Savvy about PLM

November 21, 2011

Consultaphobia

Filed under: Lessons Learned,Mythbusting,Organization — Laila Hirr @ 12:11 pm

I have observed some interesting dynamics around the use of consultants – what makes them valued, what makes them effective, reasons people avoid them.  Note that I DO make a distinction between Consultants and Contractors – Consultants should be bringing value, business level expertise, leadership, and a point of view and should be considered as a partner of the company engaging the Consultant.  Contractors are typically brought on for task level activities, specific technical solutions, to address gaps in capacity to complete a given level of effort (commonly thought of as Staff Augmentation).

1) Team member and Partner?? In this economy, when engaged on a project/program, having deliberate endorsement of the consultant is mandatory.  On this engagement – a contractor was frequently pointed to as a shining example of a success while the consultant not -  yet the consultant brought more to the table at a strategic level.  So why was the customer perception reversed – first of all the two were handled differently by the customer in terms of how they were introduced and engaged with the program stakeholders.  The contractor level resource was escorted by the director to every program meeting, introduced and given a vocal endorsement.  The consultant, interestly enough was viewed as a leader and therefore was let loose to go it on his own – having to forge a relationship path to every doorway.  Only after several months did the customer realize the impact this had on the consultant’s ability to drive for strategic results.

2) Not Invented Here – is the resistance to leveraging the knowledge of a consultant team related to NIH mentality or is it fear of revealing one’s laundry?  Both are motivations that are based upon the desire to prove one’s value at the cost of missing strategic opportunities.  One group was so focused upon doing it themselves that even when offered knowledgeable consulting support that would yield millions on ROI the team was adamant that they could not even spare the time to use the help (even though the help was funded).  Another team, realizing that they could leverage the help, made the same consulting team integral to their work.  The value of the consultant is only realized if engaged.

3) Can’t afford it – resource, time, or dollars.  Repeatedly I see organizations say this – and as a result they end up requiring years instead of months to gather the knowledge, the practices, and the expertise required to execute major strategic initiatives that can be easily documented as having tremendous ROI and business impact.  By proper identification of the business value, the benefits, etc – the cost of the consultants can be clearly offset by an accelerated path to delivery of the solution that is bringing value.

4) Disregarding the counsel given when it is unpopular – this one always surprises me.  Why pay for a consultant who has industry knowledge, expertise, and understanding of the myriad of complexities for the area of their specialization, and then minimize the importance of the issues they call out – whether risks, costs, recommendations, or opportunities.

If you are interested in further perspectives on the use of consultants, I recommend the book “Taking Advice: How Leaders Get Good Counsel and Use it Wisely” by Dan Ciampa

June 20, 2007

Should your CAD system result in a default selection of PLM?

Filed under: Mythbusting,Organization,PLM,System Selection — Laila Hirr @ 9:33 am

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

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

Theme: Rubric. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.