Is a PLM Change in Your Future?

The announcement early this summer that the Chrysler Group LLC will switch its computer-aided design (CAD) and product lifecycle management (PLM) software from Dassault Systèmes’s Catia and Enovia to Siemens PLM Software’s NX and Teamcenter is surprising only in the track record of the user companies. Otherwise, changing engineering and design software happens more than just occasionally, even though switching product data management (PDM) and PLM systems in particular are “not trivial” tasks, says Paul Downing, vice president of ProStep, Inc. (prostep.com), a vendor of software for integrating product data in a variety of third-party and in-house engineering, design, and simulation applications.
 

Why switch?
Downing ticks off a number of reasons for switching, some seemingly in jest. The response from information technology (IT) is, “If it’s decentralized, centralize it. If it’s centralized, decentralize it.” Managers might decide, “If you’re getting yelled at for your Siemens implementation, switch to Dassault. If you’re getting yelled at for your Dassault implementation, switch to Siemens.” Then there’s the general rule: “The grass is always greener in the other camp.”
 

Fact is, companies and their data requirements change. As data systems age, as companies merge and consolidate, as companies realize cost savings in consolidating their IT environments, as new software programs need to access new and diverse data sources, and as users demand their IT be open to sharing data with partners and suppliers, the existing PDM and PLM systems might get stuck and have to be replaced. In the case of Chrysler, all of that could be true, starting with the merger: Fiat, which has standardized on NX for CAD, now controls Chrysler, which has been using CATIA for just over two decades.
 

“It’s not as easy to start over again within the same system,” says Downing. “Sometimes it’s better to start with a clean slate.” Many companies think they can install new PDM/PLM software, do a flat-file data migration, and they’re done. It doesn’t work that way. The data in PDM/PLM systems have complex relationships. Orders of precedence must be maintained. For example, import the raw parts data first and then build the assemblies? Or import the framework of the assemblies first, then the parts relationships and add the CAD files later? These issues depend on how the new PDM/PLM system stores data. Often, says Downing, “the people tasked with this thing realize [the PLM migration] is much bigger than what they were bargaining for or what management realizes. This typically happens at the tail-end of the migration.” (In project-management terms, that would be the “oh-[expletive deleted]” moment.)
 

Help is on the way
System resellers and consultants typically help migrate existing PDM/PLM data to whatever system they offer. Also, the major PDM/PLM players have migration tools, although Downing admits that these vendors often approach ProStep for help. “At any given time, they love us or hate us depending on whether we’re helping them gain market or lose market share.”
 

One of the things that distinguishes ProStep is its PDM Migration Toolkit, a set of open standards-based software for transferring data between in-house and proprietary PDM/PLM systems. Companies with long-term, persistent, interoperability projects can buy a perpetual license for the toolkit for $120,000. Companies with smaller, “Big Bang” or incremental migration projects can rent the toolkit. (For example, three months for $25,000.) A third option is to contract ProStep for a fixed-price migration. (Figure $90,000 to $100,000.)
 

There are caveats. The biggest cost driver in data migration is the differentiation in datasets. Companies that have been bought and sold over the years may have an “old” PDM with several, if not dozens, of numbering schemes for different types of data (such as CAD drawings, bills of materials, word processed documents, and spreadsheets). Much of the deployment schedule will be spent uncovering all the file types, sorting through the complexities, determining part numbering and file name conventions, cleaning and reconciling the data, and then mapping the data to a new schema for the new PDM/PLM system. Another consideration: What to convert? Some companies begin wanting to migrate all their existing data to the new system. But converting and migrating all the data for obsolete products might not be reasonable. And it would be an unnecessary cost. Last, add in time for trial runs to export and import data files to confirm everything works. The actual volume of data is the least of a company’s worries. Says Downing, “that can be mitigated by throwing more processors, more boxes, and more RAM to crunch through the data more quickly.”
 

Dowing says the most important part of a PLM migration is the “upfront planning in mapping out every little nook and cranny in your old system to how you want it in your new system. You have to spend the time. It’s ugly and it’s painful. It’s hard and it’s boring. But you have to do it.”