Get Savvy about PLM

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

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