86
8:10 pm
May 1, 1997
Print Friendly

Keeping Your CMMS Alive

After an organization has implemented a computerized maintenance management system (CMMS), a number of issues must be addressed to keep the system alive and well. Most CMMS failures occur during implementation. Yet a surprising number of systems do well during implementation only to die during operations because the system was not maintained properly (ironic given that it is a maintenance system) or because processes were not in place to promote system health.

These issues need to be addressed during the system selection process, revisited after implementation, and periodically reconsidered throughout the system life cycle. Successful management of these factors will not guarantee that a CMMS will succeed, but failure to manage any one of these areas will almost guarantee failure.

Vendor support
Every organization develops resident experts in part or all of the CMMS application. The level of knowledge varies depending on training, employee interest, management commitment, ease of use, and other factors. For a CMMS to stay alive, the resident experts need someone to turn to when they require help in maintaining the system and in adjusting the system to meet changing business needs.

If the system is implemented in phases, support from the CMMS vendor becomes even more important. Most vendors offer some type of application support. Proper support management is absolutely critical to successful CMMS operations. There are many types of support, including the following examples:

Pre-sale support, what you get before you buy, is sales oriented. Vendors place their best people on pre-sale support teams. If you have problems with demonstrations, prototypes, hardware and software interfaces, and other technical activities before you buy, the pre-sale team takes care of them. If you have trouble with pre-sale support, you can count on it not getting better after you buy. Pre-sale support should always be free.

Post-sale support kicks in after you buy. Several options are usually available. Vendors give the levels various names showing some incremental progression, for example, bronze, silver, gold, and platinum. The cost goes up as you move up the ladder of options, and the level of service also should go up. The level needed depends on the operation. Frequently the support features vary by when you can call and who will deal with your problem. For example, platinum service may mean that you can call 24 hours a day, 7 days a week. You also should receive the services of the highest technical experience available.

The level of support must be selected carefully. You may need a high level of support at some point in the system life cycle, such as during implementation, and then only a medium level after the operation is stable. The differences in levels can mean big differences in costs. And you must be sure you get what you pay for. Sometimes the highest level of support means that you get the number of an answering service; someone then calls you back the next day. Frequently the same service is available from the same company for a lot less money.

The best advice is to look carefully at the support options and keep records on support use. You may want to consider testing the support. Can you really reach a person? Can that person answer your questions? Does someone return your calls in a timely manner? Are there third party support options? Are there real differences in the various levels of support or do you just pay more for the same service? Organizations need to revisit support issues as the system’s life cycle changes.

Post-sale support can be obtained in two ways: planned or emergency. With planned support you have an action plan and procedures to obtain needed support:

1. You have planned for the support
2. You have negotiated a contract for service and price
3. The vendor recognizes that your account is current
4. The people needing support know how to obtain it.

Under emergency support, when nothing else works you call someone about a CMMS product problem:

1. You call the company support number given when you purchased the product
2. You give a credit card number
3. You pray you can get someone who can help you.

The method you choose depends on your situation. You may want to ask, “How much can we afford to have the system down?” Late nights and weekends are times when you usually cannot get emergency help no matter how much you are willing to pay. During the day you may get some help, but during the business hours of the vendor, who will want to bill the service to a credit card. Frequently, the person supposedly providing the support is a trainee who may not be able to help you without support from others.

Planned support provides the security of receiving help at specified times and usually provides an avenue to receive off-hours support. It also offers a better chance of reaching someone who can solve the problem.

There is a real difference between support and training. Too often management confuses the two. Support is the capability to answer questions about how a product works, not how you are using it. Training shows users how to use the product and can frequently be tailored to particular situations. Support gets you out of a bind. Training is an investment in smooth and well-run operations. Training gives long-term rewards. If you try to use support as a training vehicle, the vendor may cut off your service.

Data collection
Data collection is “the gathering of information for your CMMS.” Data must be collected correctly and input into the system in a timely manner. For a CMMS to remain alive and be of value, data collection and input must be kept current. A system is useless unless data collection is a well-defined process. A CMMS lives on data.

Too frequently, closed work orders pile up to be entered later. This situation produces erroneous results on team performance and can cause inventory shortages and a host of other problems. Automated tools such as bar-coding and radio frequency portable data collectors can assist with data collection but cannot work on their own unless good processes are in place.

Data quality
The problem of garbage in, garbage out applies to all systems, including CMMS. Many CMMSs have died because bad data gave bad results and dissatisfied organizational team members then scuttled the system. Data quality must be constantly reviewed. Too frequently this issue is never addressed after implementation. Successful systems have some process to review and improve data quality throughout the system life cycle. This process can take many forms, including user pride, user groups, total quality maintenance metrics, committees, system manager’s thinking about it on his day off, use of consultants, system performance results, audits, and process improvement initiatives.

A company should use whatever combination works best for its circumstances and budget constraints. It is important to address data quality throughout the system’s life.

Hardware, communications, and system level software support
Hardware, communications, and system level software make up the platform or automated foundation that a CMMS must have to operate. Failure in any of the parts that make up the platform will halt operation of the CMMS. A company must have a plan of action to follow when servers, operating systems, workstations, or other vital components fail. In large organizations there is usually a support group to perform hardware repair and maintenance. Most organizations subcontract technically complicated activities like big server repair to specialists. This support usually comes in the form of a service contract with options of service such as response times and service times. These companies also take on the burden of costly spare inventories.

With the advent of client/server technology and the growing interest in personal computing, many organizations are developing a hybrid approach to system maintenance. They may subcontract maintenance of critical, highly technical components and use internal resources to fix or replace the less technically complex components. This rationale is particularly true for workstation and printer components. Internal resources may consist of a spare personal computer, or the systems administrator or resident computer person may fix the less technically complex components.

The best guide to determine what options will work best for your organization is to consider the following: How critical is the system? What are the options? What can be budgeted? What skills are available? These issues must be considered throughout the life of the system, and your needs may change during the system life cycle.

The need for system level software support greatly depends on the compatibility of the operating system, database, CMMS application, and general hardware platform. Support is often needed when the version of the CMMS, database, or operation system is upgraded. When versions change, configuration files must be adjusted at many levels. If the changes are not made correctly, the system may work but perform poorly. CMMS vendors usually include instructions on what to change when upgrading their products. The skills, tools, and parts must be available to handle the needed maintenance or repair tasks.

CMMS administration
CMMSs need constant care and attention. Tasks required to keep a CMMS alive are listed in the accompanying section, “CMMS Administration.”

Training
Training cannot be limited to the implementation phase. Refresher training maintains proper use of the system and keeps employee confidence high. Training also can promote process improvements and system functionality enhancements. Release of a new CMMS version requires training at all levels of the user population and support groups. Training is frequently a budget problem. However, for a system to succeed you must have an active and long-term training program, whether it is a computer system or a paper system.

Buy-in
Staff buy-in is the most important component of a successful CMMS. Of all the considerations this one is the most tricky to manage. The support of management and of staff members in every affected department is very important. To manage buy-in you must communicate what is happening with the system, when it is going to happen, and what benefits it has for the department and each person. Above all else the schedule must be realistic.

In summary, these areas can be of risk to the life of your CMMS . Effective management of these risks can prolong and enhance the life of the CMMS and the benefits to the organization. Careful management of these factors will not guarantee a successful CMMS, but neglect in managing any one of these areas can almost guarantee failure. MT

Cullen Tilman is a partner in Enterprise Management Systems, 8033 Sudley Rd., Suite 155, Manassas, VA 22110; telephone (703) 437-7414; e-mail tilman@emcs.com.

CMMS ADMINISTRATION
User and general security systems
can sometimes be difficult to design and implement. The proper balance must be struck between protecting the system and its data and providing users with maximum assess to system functions. As the system life cycle changes, so do the needs of the system security setup. The system must be updated when new users need access, when the ability of users to access parts of the system changes, and when former users need to be restricted from the system.

The security system is always set up during implementation. During operations you need the capability to make adjustments quickly. If you rely on someone outside your organization to provide this function, be sure you obtain the service level required. If your organization performs this function, always have a backup. More than one person should have the passwords and capabilities to administer the system.

Archival and retrieval procedures are of paramount importance. System disaster recovery procedures should be performed and followed rigorously during the CMMS implementation phase until the system is declared dead. Backup frequency depends on how much you wish to risk data loss and user wrath. Heavily used systems should be backed up daily or have built-in redundancy (mirroring). Some systems can get by on a weekly backup. It is important to test the process before you need it.

A host of technical ghosts can allow archive procedures to work perfectly yet prevent successful retrievals. Bad media, incorrect file formats, and hardware device errors are only a few of the things that can happen. The archival and retrieval process should be tested each time a major hardware or software component changes. Even installing a software package that has nothing to do with the CMMS can affect the hardware and software platform the system relies on.

Offsite storage is the most frequently overlooked item in disaster recovery plans. It can protect the company from damage to the system and tape storage caused by fire, water, lightning, and employee vandalism. Without offsite storage there is always a risk.

Data administration is a maintenance function that must be performed periodically. The frequency depends on the complexity and size of the system. Very large systems employ a staff of database engineers to make adjustments to database structure, tuning, performance, and data content. Small and infrequently used systems may require data administration once a year.

Data volume limits are part of every system. Data archiving can be the sleeping dog that can easily awake and bite you. As you use the system, the record volume can increase until it collides with the maximum limits of system disk space, the application, or the database engine. The CMMS can come to a complete halt if these limits are reached and corrective action is not taken. You must have a plan of action to follow before these limits become a problem. It is important to know what the record volume thresholds are for system disk space, database system free space, database table space, table utilization, application record limits, and data obsolescence, and where you are in relation to those limits.


Navigation