8 get-ready activities to prepare for CMMS replacement

David Berger explores the steps needed for a successful CMMS implementation.

By David Berger

Whenever you upgrade or replace your CMMS, there are usually a large number of one-off tasks that must be completed, in some cases, long before you even begin implementing the new software. These required steps are known as “get ready” activities (GRAs), and they’re important to a successful CMMS implementation.

1. Hierarchies: Every CMMS package has a number of hierarchies that must be defined. For example, there are hierarchies for the organizational structure, locations, charge codes, equipment or assets, spare parts, and position. For each hierarchy, determine the structure that makes sense for your organization. What do you like or dislike about your current hierarchy? The one hierarchy with which companies struggle the most is the equipment hierarchy, especially around the level of granularity that is required.

For example, suppose you have a small fleet of vehicles or other mobile equipment such as forklift trucks. How should you organize the hierarchy of assets, components, and parts? Let’s start by clarifying some terms. You do not charge work orders to a part for the purpose of tracking its history. The exhaust system might be considered an asset because we would like to track its work history. However, the clamps used to hold the exhaust system in place are parts, because we will never charge time or materials against them on a work order.

But what about the muffler? Herein lies the debate about level of granularity. The muffler might be considered a component of the exhaust system, where a component is simply a child asset. Components are treated in the same way as parent assets in that work orders can be charged to them, and tombstone data describing them sits on the asset master not the parts master. But why not gather history at the parent level and treat the muffler like a part and charge the exhaust system? How often will you repair or replace the muffler? If the answer is not very often, then why expend the extra effort? Even if you did, the cost is minimal.

Another option is to create rotating assets, which are treated like assets when they are in production but are treated like parts when out of service and sitting in inventory. They are serialized and assigned both asset and part numbers. Examples of common rotating assets are motors, pumps, engine kits, circuit board or computer assemblies, and fire extinguishers. Just like parts, rotating assets are typically interchangeable, but it is important to keep track of their unique work history, like you would for assets or components.

Another issue in determining the hierarchy is if and when to group assets. For example, do you need history on each of the four tires on every vehicle, on the four tires as a group for each vehicle, on all identical tires as a group on all of the same vehicles, on all tires as a group regardless of make/type on all of the same vehicles, on all tires of any make/type on all vehicles, or on each of the four wheel assemblies for each vehicle? The key factors to consider in determining the right grouping and level of granularity are:

  • whether or not there will be sufficient history each year to warrant that group/level
  • if it will be statistically significant
  • how easy it will be to collect the data
  • whether the additional benefit outweighs the added cost and effort of tracking at that level of detail.
David Berger, a Certified Management Consultant (C.M.C.) registered in Ontario, Canada, is a Principal of Western Management Consultants, based in the Toronto officeDavid Berger, a Certified Management Consultant (C.M.C.) registered in Ontario, Canada, is a Principal of Western Management Consultants, based in the Toronto office. David has written more than 200 articles on a variety of topics such as maintenance management, operations management, information technology, e-commerce, organizational design, and strategy. In Plant Services magazine, he has written a monthly column on maintenance management in the United States, as well as three very extensive reviews of maintenance management systems available in North America. David has done extensive work in the areas of strategy, information technology and business process re-engineering. He can be reached at
Subscribe to the Asset Manager RSS feed

Some of the more advanced CMMS packages also have a position hierarchy. This provides you with greater flexibility in establishing the asset hierarchy. In the vehicle example above, the position hierarchy can be used to distinguish between the front passenger wheel assembly and the left rear wheel assembly. This is different from the location hierarchy, which is the physical or geographical position, as opposed to logical position.

2. Failure tree: It would be difficult to determine level of granularity and groupings for your asset hierarchy without consideration of an asset’s failure tree. Each asset or component has a hierarchy of problem, cause, and action codes associated with it. For example, a light assembly might have a small number of common problem codes, such as flickering light, light out, and humming noise. Each of these problem codes might then have a short list of cause codes that are associated with it. For example, the problem code “flickering light” might have cause codes such as loose wire, worn out ballast, and power source irregularity. In turn, if the cause is “loose wire,” a small set of possible action codes might include tighten connection, replace wire, and replace connector.

Once you have determined the failure tree hierarchy for each asset, it is easier to determine the most appropriate level of granularity. In the light assembly example above, it would not be necessary to go any lower in the hierarchy because the history is tracked through the problem, cause, and action codes of the parent asset. Thus, if I need to know when the ballast was last repaired or replaced, I can search for the associated action codes of the light assembly, rather than tracking history against the ballast itself.

3. Work program: As described in greater detail in my previous two columns, determine the optimal maintenance policies — fail-based, condition-based, or use-based maintenance — for each asset/component, starting with the most critical and based on a cost/benefit analysis. Then define job plans aligned with each policy that outline standard operating procedures, relevant safety procedures and checklists, frequency, standard time to complete each task, standard quality measures, skills/certification required, standard materials required, standard tools required, special instructions, and relevant documentation required such as drawings. Job plans can be prepared for any critical or repetitive work including demand work, ongoing project or capital work, and even possible breakdown or emergency work.

4. Numbering systems: Optimize and finalize numbering systems as they relate to hierarchies — for example, equipment numbers, part numbers, charge codes. Avoid significant numbering schemes wherever possible, such as US-MA-BLD2-1542-C, where each segment in the number denotes the object’s location or its attributes. The information embedded in significant numbers will be stored in many individual fields in the CMMS and will always be accessible by cross-referencing a random or insignificant number tied to the object — asset, component, part, vendor. Furthermore, significant numbers are longer, and the location or attributes embedded in the number — for example, if an asset is moved to another location —may change over time.

5. Templates: Define the families of objects that share common attributes, such as pumps, motors, pipe, drywall, doors, bearings, and belts. Then define the fields needed to differentiate each family, such as length, RPM, flow rate, weight, and material.

6. Master data: Although the simplest to state, this can be one of the most time-consuming GRAs. Based on the templates and the desired attributes defined above, all tombstone data must now be collected for every asset and component on the asset master. Similarly, tombstone data must be collected for other master files, such as parts, vendors, and employees.

7. Data conversion: Determine if tombstone data can be ported from existing systems, that is, if data is complete and clean. Try to avoid porting over transactional data from legacy systems, such as work order history, since it can be very costly for little benefit. There are cheaper ways to provide access to the data, such as printing it out, maintaining limited access to the legacy system, and archiving the data.

8. Reporting: Define key performance indicators (KPIs), reports, graphs, dashboards, and queries that you want to see in the new system.

Read David Berger's monthly column, Asset Manager.