Don’t Procrastinate…Innovate! Outside The Box: Conducting A Legacy Software Migration

By Ken Bannister, Contributing Editor

The time has arrived: Your Maintenance Management System (MMS) is now ready to be populated with data. Within industry, virtually all software purchases and implementations are driven by the corporate Information Technology (IT) group/individual whose job is to ensure the software runs as designed on your system. It is not IT’s job to set up the software-operating parameters and populate it on your behalf with meaningful data—it’s yours!

The IT department is on hand to facilitate the process of data population and provide technical assistance when required. Remember, though, that you usually only get one chance to implement your management software correctly. If you don’t control the implementation process, you’ll spend the next 3-7 years in frustration adapting your work process to the dictates and inadequacies of your software setup. Or you’ll spend a lot on unnecessarily “customizing” the application or building “workarounds” in small databases/spreadsheets outside the application. Sound familiar? True innovation in setting up management software is knowing how you want it to function and ensuring the system is tuned to deliver!

In the previous issue, we explored setting up the software framework through an innovative seven-step process in preparation for the data migration. If this is your first-ever MMS, you will have likely performed maintenance using a paper-based work-order and filing system. If this is a new MMS replacing an old computer-based system, you are faced with the challenge of migrating your existing maintenance information and history files over to the new system. To most, this seems a daunting task. Thus, responsibility for it is often abdicated to the IT department.

IT then proceeds to write a “mapping” program that plots the data registers’ current locations to their corresponding locations in the new software and produces instructions for them to transfer from the old location to the new one on command. Once the button is pushed to perform the migration exchange, any garbage data in the old system will immediately appear in your new one—i.e., “garbage in–garbage out (GIGO).” At this point, you now own a new system full of old data, something comparable to owning a shiny new car with an old clapped-out engine: Performance will be lacking! Don’t blame the IT department. It’s not THEIR responsibility to tune up YOUR data prior to migration.

Preparing data for migration
The first step in preparing data for migration starts well in advance of the software purchase: It is to ascertain what annoys you about your old MMS setup, as well as to solicit a list of things that “bug” the rest of the user population. Typical issues that surface include:

• PMs aren’t relevant.
• Inventory items remain in the system for equipment that’s been scrapped.
• An inventory item can be found under multiple SKUs with different names and numbers.
• When trying to make a pick list, parts that are known to be in the system can’t be found.
• The asset-nameplate file lacks details.
• Assets with no parents or children are set up in the hierarchy.

Trying to make these things right once data is migrated is difficult and expensive. This type of list speaks to redundancy, duplication, lack of meaningful data and poor setup of data relationships—the hallmarks of a challenged system.

You’re now ready to solicit assistance from IT to extract the existing system’s data into a spreadsheet format that can be manipulated and used for migration purposes. As you’ve already figured out the new data registers and report requirements, you need only the asset register and MRO inventory registers with their corresponding data fields. With your “bug list” and spreadsheet in hand, you’re ready to begin data-cleansing. Depending on the number of assets and inventory SKUs, you may need some outside expertise to help cleanse the data.

Asset data-cleanse
In an asset data-cleanse, we usually look to ensure that the asset names follow a defined naming convention, numbering convention and that the asset nameplate information is complete.

Over time, data will be entered into a system by different individuals who copy asset names from drawings and/or catalogs. With the diverse naming protocols that result, it can be hard to find an exact/specific asset quickly in a large database.  Simplifying this search ability is achieved by standardizing how the asset is named, using a naming convention.

Naming conventions are set up in a noun-descriptor format. For example: “Lathe, Engine, 15-inch swing, 60-inch bed, South Bend.” In this title, we start with the noun “Lathe” that denotes exactly what the asset is. What follows is a series of descriptors that accurately describe what type of lathe, its size and, in this example, the manufacturer’s name.

With naming conventions, if we are unsure of an asset’s title or identification number, we can confidently perform a search by any number of the descriptor attributes and focus in to the exact asset in seconds. For example, performing a wildcard search for “Lathe,” we get back a list of all lathes in the system. If we know the type of lathe, bed size or manufacturer, we should expect a very short list. Finding the exact asset is then a matter of opening up the nameplate data file for each selection to learn more details regarding its location in the plant, manuals, photographs of the asset, etc.

If your new MMS has additional asset fields, you can still refer to its old name by placing it in an alternate name field that can be searched on for those that recognize the asset by its old name. The number of descriptors used will also depend on the number of search filters that can be employed in the new software. For example, you may choose to use lathe as an asset type or sub type under an asset type named “Machine Tools,” or manufacturer—all of which can be filter-searched to quickly narrow the pick list. Your naming-convention detail will, therefore, be tailored accordingly to your search-field capability.

The asset number will follow a significant or non-significant numbering convention: All assets MUST follow the same convention. If your assets reflect a mix of conventions, you must decide which works best for you. Significant numbering that contains codes to indicate location, parent asset, asset type, date of manufacture, etc., can lose their meaning when an asset is moved to a different location. Non-significant numbering usually involves sequentially assigned numbers with no meaning other than to identify the asset. With a management system’s ability to define an asset in many ways through data-register fields and by name, most companies choose to set up a new asset-number register and place its old number in a vacant alternate search field in the asset setup screen of the system.

Eliminating grief
The asset register is the foundation of your MMS: Every piece of data in the system is intrinsically tied to one or more assets. Using innovative thinking to set up and successfully cleanse your data prior to migrating it will eliminate post-migration grief.

In the January issue, we’ll focus on cleaning up the MRO inventory database and how to be innovative in dealing with that asset history. MT

kbannister@engtechindustries.com