Myth Busting: We Need Our Old Data

You’ve acquired and are now implementing a new CMMS/EAM (Computerized Maintenance Management System/Enterprise Asset Management) computer software program to help you manage maintenance. It may be a simple functional system that only looks after maintenance and likely Maintenance, Repair and Operating (MRO) spares, or it may be part of a much bigger enterprise system that handles many business functions. Regardless, one question almost always arises when converting from one to another system – what should we do about our old data?

The old system has served you well (we hope) for some time. Perhaps you’ve outgrown its capabilities, perhaps your underlying computer operating systems or corporate data base systems are changing and you are now forced to upgrade, perhaps your new system is a newer version of your old system. The old system will hold a lot of data, some useful and some not so useful. Some users will want to keep the old data because they are familiar with it and can find their way around in it. Indeed there will be some useful data, but familiarity with how to find things won’t necessarily come into your new system even if you bring all the data over. Each system has its own way of storing and presenting information.

Bringing that data over will require some effort to map old system fields to the new system. Differences in field lengths (e.g., 120 vs 80 characters) or data types (text vs. alpha-numeric) or free flow text vs. drop down boxes will need to be resolved. Your old system may have stored trade information by name, the new system may store it by trade designation and leave the personal data to the HR system. If your work crew lists are out of date you may find they don’t migrate and stop the migration process because of differences. That’s just an example; there can be all sorts of data complications. Expect data clashes and the need to do some work to decide what to do when they occur. Transferring old data into a new system is seldom achieved easily nor without some pain. So, is it worth it?

What you want in the new system is as much of the truly useful information from the old system as you can get, without creating more work. But ask yourself, was the old data truly useful?

In one company that was upgrading from several out-of-date versions of a particular software package to a much new version, same version across multiple sites, there was a desire to bring over parts data and work order data. The volume of parts data was huge and re-entry manually would have been a massive job. The work order data was seen as a source of valuable reliability information. We questioned if migrating both would truly save any effort or time.

The parts data was heavily flawed. Each site (and there were over a dozen sites) typically had over 20,000 parts identified in its MRO database. There were known to be many duplicates due to poor nomenclature and part numbering discipline. We estimated that about 6,000 parts were actually unique, the rest were duplicates. The duplicates had to be eliminated eventually – either now (when migrating data) or later after the new system is live. Some, but very little, work would be saved, so we had a parts data service overseas handle data scrubbing. It didn’t eliminate all duplicates as hoped, but it did clean up many and made the job a bit easier. With that scrubbing, we brought the data over.

The work order data was another story though. It was seen to be useful to reliability improvement, and since we were also instigating a new reliability program, the company wanted as much data as possible to feed that program. We asked their existing reliability engineers if the data they had was useful. The answer – NO. The existing data was missing key pieces of information, it was inconsistently recorded and lacked proper coding to identify when work executed was actually a repair. There was no data related to any specific failure modes and in many cases, work orders had been created against wrong equipment or against classes of equipment. The engineers had given up on it long ago and resorted to their own data gathering methods – much of it on spreadsheets. After more discussion, that work order data was left behind. By the time the system was fully implemented using new processes and practices (likely 2 years later), they’d probably have up to a year or more of new data anyway.

In another company we were migrating Proactive Maintenance standing jobs (PMs) from the old system to the new. There were two large sites and two smaller sites involved. At one of the larger sites they had a planner who was truly an expert in the old system. When it was time to decide whether to bring the data across in a transfer to manually, he insisted that the data was good, that they had been following the PMs closely, and concluded that an electronic transfer would be sufficient and a lot faster. The other sites didn’t have anyone with his level of expertise and they knew that they were not following the old PMs very closely. They opted to manually transfer the PMs and review them as they went along.

The one large site proceeded to carry out its electronic transfer of PMs. Field mapping was done but field types and coding were different and much of the transferred data came across poorly or clashed and didn’t come across at all. Cleaning that up required manual intervention by other planners and supervisors who all recognized that many of the PMs were no longer valid, were actually not being followed, and needed a big cleanup.

The other sites printed old PMs and reviewed each one manually with a small team. They took some RCM training so that they would understand what sort of criteria made for a good PM. In their PM Review, many PMs were eliminated, task frequencies were modified and updated based on experience, and some tasks were modified to match equipment changes that had taken place over the preceding few years. PMs existed for equipment that had been removed – the asset register (which had been migrated electronically) was updated as they reviewed PMs. All three of those sites started up their new system with little trouble and had the benefit of completely overhauled PM programs that they were happy to follow. After “go live” the new PM program went into effect and asset reliability started to improve.

Beware the temptation to migrate data to a new system in an entirely electronic manner. On the surface, it may seem to save effort but there is a good chance it will result in more problems than it is worth. Your parts information may be flawed and your maintenance work history may simply be unfit for purpose in the new system. A careful review of information, particularly your PMs, before transferring is always warranted and worth the extra manual effort.