Get Savvy about PLM

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

June 7, 2007

Impacts of the mergers and acquisitions of PLM vendors

Filed under: PLM, System Selection — Laila Hirr @ 5:13 pm

Okay – I’ve been biting my tongue long enough regarding the shifting sands of the PLM space. The past year has seen massive movement among the players and the question is not really how do these deals impact shareholders but how does it affect the longer term delivery by the vendors to the customers.

Here are my personal views of the changes…

Agile-Oracle
I have been up close and personal with Agile customers for years. I service systems that range from Agile 6 to Agile 9 and see the same trends over and over again – users tend to use Agile well – out of the box functionality is great BUT Agile has had ongoing issues regardless of version with system stability and with the responsiveness of the support desk. Every version of Agile has had some sort of workaround for stability that involves “restarting services” 3-5 times per week to keep the systems stable – that has always concerned me. In addition, Agile helpdesk has been notorious for assigning issues to “marketing” or “engineering” which customer after customer has described as a “black hole” from which the issue never gets resolved. The overall product is good – but for these components (stability and support) to remain issues for 6+ years as the most common complaint I encounter is surprising. So my biggest question on behalf of the customers would be – will Oracle do better? I would expect so. Oracle actually can make the connectivity between Agile and Oracle databases work – but will MS SQL be abandoned yet again? I also can’t imagine that Oracle helpdesk can be worse than Agile’s was – so I hold hope but it will take time for everything to shake out.

Siemens – UGS
UGS has been on the auction block many many times over the last 5 years – First the SDRC and UGS pull into EDS, then EDS spin off back to UGS (held by investment companies) and now being bought by Siemens. Like Agile – I’ve been up close and personal there too – but I see a big difference. UGS has maintained a rock solid product consolidation roadmap through all the changes. Any one who talks to the management at Seimens/UGS will be getting a consistent message that has fundamentally not changed for the past 5 years – a commitment to making the customers succeed and to bringing about the synergy and merging of products. The main problem has been the distractions of change – no matter what – that much change means that cultures have to blend, work things out, settle – and it can’t help but slow things down. It is commendable that the roadmap has been carefully adhered to and that the customers have as a result remained highly loyal.

Dessault – MatrixOne – Connesio – … and what else
MatrixOne had all but disappeared from the PLM market space here in the Pacific Northwest. I maintain relationships with many of the vendors and their folks had vanished – next thing I knew Dessault had picked them up and also not long after picked up Connesio. That was on top of the already mixed up combination of Enovia, SmarTeam and PDMWorks. I honestly haven’t figured out the strategy. Now PDMWorks “Enterprise” is a repacked renamed form of Connesio. The analysts are confused, the customers are confused – which system will become the mainstay? How is scalability intended to be addressed? What is the flavor today? Dessault maintains presence through it’s offering of Solidworks to the mid-market and leverages that presence to catch the unwary and most needy businesses into PLM solutions that are still partially complete.

What of the others…PTC, Arena, SAP – these haven’t had the acquisitions to deal with so I’ll talk about them next time.

Copyright 2007, All rights reserved – LHirr

May 2, 2007

Definition of Usability

Filed under: System Selection — Laila Hirr @ 3:08 pm

I saw a chart the other day being used to describe usability and it was one of the most concise images on the importance of usability I have ever seen, yet the presenter did not really explain the chart which was unfortunate. I did not notice a reference source on his presentation yet I know it came from other sources (which is why I am not citing the presenter directly). So in the spirit of research (being information from many sources) I’ll attempt to review the points the chart was making.

The definition of Usability is a time based definition. Initially DISCOVERABILITY and CONSISTENCY are most important. How easy is it for an application user to discover functionality without resorting to manuals and training materials. When moving from area to area of an application how consistent is the presentation of the user interface so that relearning leverages that consistency. Microsoft is a classic example as more and more non-Microsoft applications boast of the “Outlook” interface. But that interface is not best for all systems – so when looking at Usability – look for discoverability and consistency initially.

The problem however, is that the definition of usability often stops there – and later when the honeymoon is over, the other components of usability become more evident. After the initial learning – how much is EFFICIENCY and CAPABILITY expanded. After discovery – do efficiency improvements continue or go flat? Can you expand your use of the tools through leveraging the additional capabilities of the tool beyond the initial need? These aspects of usability are not readily addressed in product demos and are not realized until the user has completed the honeymoon or nightmare of the first side of the usability question.

In the best of both worlds you would want to look at solutions that have the near term and longer term definitions of usability being satisfied. In reality it may be a compromise – The paradoxical definition of usability explains why difficult to learn systems are adopted and have productivity gains despite the lack of discoverability and it also explains why highly discoverable systems become flat for efficiency gains downstream yet may be widely adopted by the masses.

So when you go into your system selection process with Usability criteria – be sure to include all 4 components of usability – not just how easy is it to use initially. Again look for DISCOVERABILITY, CONSISTENCY, EFFICIENCY and CAPABILITY. When you have all 4 you have a system that will serve you as a longer term solution.

Copyright 2007, LR Hirr, All Rights Reserved

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 22, 2007

Pardon the dust

Filed under: Uncategorized — Laila Hirr @ 9:31 am

Sorry for the confusion on changing the setup of this site, but the layout I had was not conducive to having tables and images. This new layout allows my content onto the site much more cleanly. Now that this is working better I will be updating some of the older postings to make the images more legible.

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

March 14, 2007

Top level criteria for PLM System Selections

Filed under: System Selection — Laila Hirr @ 12:08 pm

There are many readily available references to ERP Selections, CRM Selections and so on… The principles are generally the same for PLM. First and foremost – technical requirements and technical qualifications are not the ONLY criteria by which to judge a system. Neither is price. The canned demonstration is also not the best means to select a system (it’s too easy for vendors to use smoke and mirrors).

Generally when we examine solutions for the customer we make sure the following criteria are included in the analysis and we work with the customer to assess:

Technical Qualification – The technical qualification is still a first qualification and always will be. But the qualification should be based upon a clearly defined requirements matrix that the vendors must show evidence of meeting, making distinctions between out of the box functionality, configurable functionality, and customized functionality. Requirements should be weighted based upon business need and vendors should be evaluated with regards to those needs. Do not use the canned demo as evidence of meeting the requirements. Walk thru every requirement in detail with the vendor showing you exactly how that requirement is met.

Business Standing – How long has the vendor existed, how have they funded growth and development? What percentage of the customers are paying maintenance (i.e remaining current)? If publicly held – what are the analysts saying. Are their customers in the same industry verticals as your company or are the customers similarly modeled as your business? Will the vendor be there for you in 5 years? in 10 years?

Customer Support – How well are the customers supported? How is helpdesk support provided for you as a customer. What forms of training are available? Is there an “active” user community and how is it controlled/supported by the vendor? Are there local groups or readily available forums for end-users, administrators, etc. Are there larger events where training, exchange of experiences, and networking is supported?

Referenceable – Does the vendor have referenceable customers in your business sector or of your business size, using versions of the system you would be considering? When a vendor gives you a reference name it is often an executive who purchased the system, ask to speak with members of the deployment team, and to end users – that is where you will get the real story. How long has that customer been a customer – are they actually in live production use of the system or are they still in the honeymoon of getting the system set up?

Roadmap – Does the vendor’s roadmap provide a path for your company to grow with the vendor as a “partner”- what happens with your data when you “outgrow” the current toolset. Are there modules that scale with your business growth? Does the platform support appropriate technologies to remain current on your overall enterprise infrastructure requirements? How has the vendor demonstrated commitments to past roadmaps?

A system could meet every one of the technical requirements and come up severely lacking in the other criteria and without a thorough examination of all aspects of the relationship you could be throwing good money into a system that will fail due to the non-technical aspects listed above.

Copyright 2007, LRHirr

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

« Previous Page — Next Page »

Blog at WordPress.com.