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

May 17, 2010

Quality Management Systems (QMS), Document Management (DMS) or PLM? What are the differences?

Filed under: Mythbusting,PLM,System Selection — Laila Hirr @ 1:55 am

Copyright 2007, LRHirr

Definition of QMS/DMS/PLM

This topic has been sitting in my notes as a to-do for a very long time.  From a very high level perspective, terms like knowledge management, document management, quality management and product management just create confusion for folks – are they all referring to the same thing?

Quality Management Systems (QMS) are considered to be focused upon a company’s quality records, often including the ability to manage basic workflows around corrective actions/preventative actions (CAPA), statistical process controls, non-conformance reports.  Most QMS systems are industry focused and are often tied to the medical device industry and the pharmacology industry.  QMS systems may or may not have document management system (DMS) level capabilities.

DMS systems are focused upon managing documents electronically.  The systems are typically structuring to support “file folder” based information and have workflows to support revision history and change processes around those electronic files.  DMS systems typically cannot support product structures and the more complex relationships of tying documents to a bill of materials. Some document management systems will “build” a compiled content site for large scale web environments that are sensitive to rollouts of new art, press releases, special offers and such.

Product Lifecycle Management(PLM) systems  may or may not have QMS level templates, however they support a broad range of workflows, are highly adaptive and handle the change management of documents, folder based file management and the product structure related file management.  PLM systems often include capabilities to manage CAD data, Bills of Material, program management, requirements management, view and markup capabilities, and supplier access to key product related data.  PLM will not “build” a content site.

April 22, 2009

Successful Implementations – Invest in Phase 1 – Establish the Business Case for PLM

Filed under: Cost and Benefits,Lessons Learned,Mythbusting,Success or Failure: Lessons Learned — Laila Hirr @ 2:46 pm

A reader recently asked me to share perspectives on successful PLM deployments – what are the common themes across successful implementations.

The thought that comes to mind first and foremost is the upfront planning.  By planning I don’t mean the development of a project schedule or of the system requirements - it’s the investment in taking the time to really make sure the business justification is well understood.

There is a process I have used repeatedly that involves managing expectations very carefully before engaging the software vendor.  Too often it seems that the PLM decision is reactive – as sold by the software vendor, not based upon a clear set of business drivers.

To be successful with the process steps executive level endorsement is critical as it has a lot in common with a business process assessment in that it probes the entire organization, however, the assessment is focused upon the product record, not operations or production.  The challenge for many however having someone who knows  PLM well enough to be able to see the opportunities is often not a skill set contained within your company.  The cost of having consulting done for this stage is often well worth the initial investment when taking into account the overall investment you may end up making in the implementation.

The single most significant thing to be done is to look at the PLM project with the same kind of rigor as a product development project.  Too often IT projects (coming from a non revenue perspective) fail to use simple PMO types of processes.  It all starts with the business case phase.

phasedprojectplans

But on the successful implementations – the business case stage would include the following activities:

  1. Take your organization chart and mark every department that handles product related information, identify key external partners that are also interacting with your product records (note – do not count your financial transactions here – just focus on the product information).
  2. Evaluate each department around it’s  handling of product information or the product record look for manual transactions, duplicated entries, printouts, markups, shadow databases, network storage of product information.  Include examining what IT infrastructure components are involved.
  3. Dollarize the impact of the “non-value” added activities associated with these product record related transactions – the caution is that executives will readily let you turn this into a blame game rather than a financial business case – so be careful how this is framed (Read the Dollarization Discipline for more on this).
  4. As in product development project management practices – develop a high level specification (similar to a Market Requirements Document) that ties business objectives to the functionality requirements – this is NOT where to say it must run on xyz database, or have n tier architecture.  This is a market level specification for executive consumption.
  5. Obtain executive buy-in for the next stage – do not go too deep into specification definition until this phase is approved.

July 30, 2008

IT invests in Collaboration Tools – so where is PLM?

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

I was reading this weeks issue of Information Week – following an article on one of my favorite topics – IT spending (in an uncertain economy)…and was heartened to see several key comments. See

In the article from July 28th, 2008 – Stare down the bear it is stated that companies are viewing the present uncertainties with a view to “leap ahead of weakened competitors” and are “plowing ahead on collaboration technologies” while conserving in the tactical areas.

This should hearten those of us who work extensively in PLM – yet it doesn’t. The frustration is that too many executives view PLM as an “engineering system” not as an enterprise necessity. While many PLM systems get implemented within engineering departments it’s typical to find that in short order, the rapid access to product information, the supply chain enabling, the multi-site collaboration capabilities – more employees within a company will be accessing the PLM environment than any other enterprise application.

Many of the PLM systems enable design reviews, assembly instructions, site specific component designations, hazard tracking, safety notices, policies, and processes all to be maintained across the business. Any business that has multiple facilities and produces products, should not forget that PLM is a highly critical collaboration solution (some even include conferencing systems embedded within them).

If your business is looking for efficiencies and reduction of costs associated with communications and collaboration – hopefully you are looking at your information flow in that context as well and examining what can be done to eliminate the overheads associated with transfer, loss, duplication of product information. After all – your business is based upon your products, right?

December 1, 2007

PLM challenges according to Dr. Grieves

Filed under: Enabling Technology,Mythbusting,PLM — Laila Hirr @ 7:16 pm

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 paralyze 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 virtual 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.

July 21, 2007

The problem with PLM Polls

Filed under: Mythbusting,PLM — Laila Hirr @ 12:30 pm

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 their 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:
CIMDATA Poll 07202007

should be viewed as positive evidence that PLM is coming into the forefront of corporate understanding. They conclude that 60% of the respondents 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 respondents 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.

July 2, 2007

Waste in the information stream

Filed under: Information Change Management,Mythbusting,PLM — Laila Hirr @ 2:47 pm

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

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

April 4, 2007

The Part Numbering Conundrum

Filed under: Information Change Management,Mythbusting — Laila Hirr @ 2:12 pm

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 – “intelligent” and “sequential”.

Intelligent 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 intelligent 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 intelligent part numbers in maturing businesses. The conclusion of the study was that as a business matures and grows – the viability of maintaining intelligent 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 intelligent 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 availability 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 intelligent part numbers (in part because the customers demand it) but they will all acknowledge that intelligent part numbers are not a recommended business practice. In fact to implement automated generation of “intelligent” 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 intelligent 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

March 20, 2007

The Key Differences between PLM and ERP in meeting corporate objectives

Filed under: Information Change Management,Mythbusting,System Selection — Laila Hirr @ 9:50 am

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:

Development and Innovation

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

Next Page »

Theme: Rubric. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.