Is it worth changing PLM tools?

Introduction

I thought it would be interesting to look at why people and companies might consider changing PLM tool. You might not think it is usual but it can happen for a number of reasons. I'd like to make some comments and suggestions on how to do this.

Why change

Choice or necessity?

Choice

It might be that you realize that you made a mistake in choosing the current tool and/or it might not be fit for purpose. Clearly this is a big step and I would always suggest trying to avoid this. I'd recommend working with the current vendor to see if the situation can be remedied. It is very likely that your company has already made significant investments in the tool and training so to throw all this away should be avoided at all cost. I think most vendors would do all they could to help you in sorting out problems with the current system.
It might be that there are irreconcilable issues between you and the vendor and their tool and you decide to move to another system.

Necessity

There could be instances where it is a necessity to move to another tool, for example the current tool is about to become obsolete and not supported by a vendor. I would really recommend moving data from obsolete systems as quickly as possible. I have seen many companies who have key data in a system that is no longer supported, this is a ticking time bomb!
Of course in some defense contracts the vendor specifies a system and it is part of the contract that you have all the data stored in product X version Y. I would still look into migrating a copy of the data to a supported system just in case.

Consolidation

I've seen quite a lot of companies who have (for a number of reasons) multiple PLM tools in their possession. At some stage it is both cost effective and desirable to consolidate all data into one system. It might even be that there are multiple installations of the same tool that need consolidation.
In the case of consolidation there are number of specific considerations. You will need to do a detailed audit of what data is in each system and where is there overlapping data e.g. CAD data in multiple systems with the same (or different) part numbers; in these cases you will need to determine which is th master. You may also have multiple copies of standard parts, fasteners etc. that might already exist in the target system. You will need to decide what is the master data and which data will be overwritten in which systems.

Acquisition/Merger/Divesting

Many companies need to either merge data from acquired companies or when a company re-organizes; also if a division or unit is being spun off as a separate entity you will have to decide how to approach the split. These can be difficult operations and will need expert skills to insure that data is not lost in the transformation. Again I would suggest a thorough data audit and detailed plans for what data needs to be where.

New technology/Cloud

You actually might not be changing tools, just paradigms! Consider what is needed to move from a company based system to a cloud version of the same PLM product. You need to insure all your data will be there and in a usable state. The cloud vendor should be able to help you do this and insure that there is a smooth transition.

Clean sweep

You may have totally had enough of your current PLM tool and want a clean sweep, be careful though since you could be incurring a lot of costs, and it might not be the tool that is at fault. It could be your processes and implementation that is the problem – so be very careful to assess where the problems are before embarking on this approach!

Approaches

How to tackle the move? As I already suggested the data audit should be the first thing to tackle. You need to understand what data (not forgetting meta-data and workflows and processes) are tied up in the legacy system. You need to insure you have documented how you will manage all these facets in the “to be” system
I'll cover tools in the next section, but clearly you will need to evaluate approaches for data transfer e.g. big bang, phased approach. You will also need to determine the time-frame for the move. Can you accomplish what you need in a weekend or will you need to perform the production move over a period of time. How will you manage a long transition? You may be able to make use of a company shutdown e.g. public holidays.
You will also need to insure that the folks who are moving to the new system are involved in the process and that they will have all they need to do their jobs when the new system goes live. As I've mentioned in various other papers you need to insure that the users are on board otherwise your implementation will fail or at the best not realize its full potential.

Migration tools and approaches

Most PLM systems have some form of mechanism for exporting and importing data. The challenge may come with metadata rather than physical file data. Siemens has a de-facto XML standard format (PLMXML), I liked this idea but I'm not sure how many folks have tried to use this for large scale migrations. Clearly you would need to develop tools for both systems to map data and import or export tools for non Siemens systems.
PTC (and others) have bulk loading tools to accomplish migrations and these are valuable since they reduce the risk and cost of “building your own” import tools. You do still need to invest time and effort into getting the data into your new system, but the heavy lifting is achieved through a supported tool so data integrity risks are mitigated to some extent. Also if you hit data integrity problems the vendor should be able to help.
Determine how many rehearsals your are planning to do. This will be determined by a number of factors such as size and complexity of the data you are moving and also the number of systems you are consolidating. Rehearsals will also help you assess how long the migrations/loading will take so you can determine how long your production systems will be offline.
You will also need to determine how you will deal with data created between the rehearsals. You will need to insure that you do not miss any recent data.
Don't overlook what you do with the old system you are moving from. If you don't move 100% of the data you might want to keep the old system alive for a while to insure you have not missed any vital information.

Cost versus benefit

Please insure you do a cost versus benefit analysis. You will be investing a lot of time and effort so it is key to insure that the investment is worthwhile.

Lessons learned from old PLM implementation

As I mentioned earlier you will need to learn as many lessons from earlier experiences. It is good not to make the same mistakes twice. Also understand why you are changing systems. In certain cases you will need to make sure your earlier implementation was not the main issue.

Data validation

You will need to insure that you complete a comprehensive data validation on any target system. Clearly during your rehearsals is the time to do the validation.
Develop a comprehensive test plan and insure that all the roles who will be consuming the data are covered from a testing standpoint.

CAD

CAD data is complex and is one of the most risky types of data to move. Most PLM systems need data to be imported and not just loaded on a file-by-file basis. You should insure that the engineering team has time to validate the data.

BOM

BOM data needs to be assessed once imported. You need to check for data consistency and integrity. Again this will need someone who is familiar with the data from the previous system.
If you have multiple BOM types this will need to be checked to insure that all were moved successfully.

Metadata

Again you will need to insure that all the migrated data is validated, insure that all attributes are present, there might be CAD attributes that need to be populated from the CAD files.
If you are consolidating part numbers or renumbering or renaming you need to check that these operations were completed successfully.

Workflows/Change Management

Any data that is in the middle of a process needs to be treated carefully. It is essential that when data is moved it is in a state where people can pick up their jobs as quickly as possible after the migration is done.

And finally – TEST TEST TEST!