Today's CMMSs offer four powerful features earlier systems did not. Learn how they can increase your uptime and lower costs.

Your CMMS can show where you need to improve in training, testing, procedures, staffing, etc. That takes you beyond work order administration, which we covered in the March, 1998 issue. Let's rise to the next level: using the CMMS to improve the power and stature of maintenance within the larger organization.

Corporate and plant gatekeepers try to reduce the money you get for test equipment, training, and personnel. They are also tight on giving up any floor space or granting maintenance downtime.

Unfortunately, most companies accord lower status to maintenance groups than production groups. This is partly because it's been so easy for so long to use "maintenance failure" as a cover for quality or quantity shortfalls. However, this is not easy when you face a maintenance manager armed with hard data presented in a visually striking format. Let's see how you can use a CMMS to create such armament.

Justifying test equipment. How do you justify test equipment purchases? Often, you base justification on trade experience, projected savings, manufacturer's literature, someone else's case histories, and other information you hope will sway the gatekeepers. Sometimes, you must be more compelling than this.

Suppose you already own a hand-held oscilloscope and want to purchase another. Your purchase request comes back with a request for financial justification. You need numbers. So, you go to your CMMS and list completed work orders that involved motor drive repairs. You then pull up your test equipment data: You purchased your scope on June 15th, 1996. Now you divide up your work orders: those done before the 15th and those done after. Let's assume you kept track of which repairs used the scope and which didn't.

Suppose the numbers aren't as good as you'd hoped. You need to go into your CMMS again and view failure causes. Three drives "failed" because an operator "cleaned" them with a firehose. Your CMMS says only a few employees have drive training, but others attempted repairs. You filter things down to eliminate variables and come up with a "typical" drive repair time. Make sure you can explain which items you excluded. You can use the results to create a graph like that in Fig. 1, on page 64H (original article). List the various production lines separately, so the manager of each line can see the hit that line takes on its bottom line.

Explaining training. You can use the same approach you used for test equipment, but add a twist. Use your CMMS to correlate downtime codes with training completion codes by worker, and come up with a profile of downtime excess due to training deficit, by production line. This takes quite a few steps, but it can be worth the effort. Fig. 2, on page 64H (original article), shows what such a chart might look like. You may want to focus on PLC training and PLC-related downtime, for example.

Tracking non-value-added activities. Don't you wish you could show how an increase in maintenance-reserved floor space reduces breaker maintenance costs? Maybe with a "before" and "after" chart? The battle for floor space is intense, and you need scientific purity to be convincing. For before/after comparisons, don't send a crew of two rookies the first time and a crew of six experienced people the next. Consider asking an operations manager to watch at least the setup portion of some of the tests.

Perhaps the best way to attack this is to track non-value-added activities. After all, moving things out of the way just to get at equipment adds no value but does cost you. You'll need to have someone jot down the types of non-value-added activities taking place under constricted space (e.g., moving carts and equipment). Make a code for non-value-added activities, and track them collectively as in Fig. 3, on page 64J (original article).

Charting downtime by operator error. Fig. 4 (original article) is one tool no maintenance department should be without. When fingers start pointing toward maintenance, whipping out a chart like this does wonders. Even better: If an operations manager wants to know where the training and supervision weaknesses are, you can chart the downtime by shift. You can use charts like this for political self-defense or, better, to build helpful relationships with production.

Eliminating breaker maintenance barriers. When breakers need maintenance, you often get nuisance trips. Worse, breakers may not operate when they should. The bad news: If you have the second problem, you might not realize it until catastrophe hits. The good news: We can use the CMMS to track the first problem. Just report all breaker trips to the CMMS, then make a chart like that in Fig. 5 (original article).

Opening eyes and minds. This is just a hint of the power you can unleash from your CMMS. Consider making a list of the top three problems facing maintenance, three facing each production manager, and three facing the quality assurance department.

Think about the kinds of information you collect or can collect in your maintenance and repair efforts. Then look for ways to use that information in charts that will help everyone see what's really there. Doing so makes your maintenance department a necessary team member.

Sidebar: The Emergence of Open Database Compliance (ODBC)

In the early days of computers, there was DOS (Disk Operating System). With the advent of DOS came a transition from paperwork order systems to electronic ones: the early Computerized Maintenance Management System (CMMS). Fast forward to today's CMMS. It outclasses yesterday's star at every turn. Today's Open DataBase Compliance (ODBC) is one of the features allowing quantum leaps in maintenance management and performance. To understand the impact of OBDC, we must cover three other features: file standardization, advanced analysis, and graphical interfaces.

File standardization. Many of the first CMMSs used proprietary databases. Thus, to move from one CMMS to a newer, more powerful one, you had to ditch information you tediously keyed in. Fortunately, most vendors attacked this problem early on, by adopting dBase III and ASCII file standards, which made interfacing with larger systems and mainframes possible.

File standardization paved the way for other developments, such as advanced analysis, because developers could write one program to a standard file type.

Advanced analysis. In CMMS's infancy, you could tally up a few figures for a rough idea of where your maintenance resources went. But you had few tools that could sort and filter the information; reports from the system were often meaningless. CMMS companies realized end users wanted more than just the number of hours each craft spent on a work order. They responded by loading their programs with a wide array of measurement and analysis features, including accounting, trending, and predicting functions. Their real power came in the ability to tailor data collection to the end user's needs. Thus, if you want to know how many minutes of downtime your plant air motors suffer each month due to clogged air filters, you can set your system up to tell you that. If you want to compare that information to what happened last month, you can. Such functionality paved the way for advanced trending and prediction, based on real data.

Graphical interfaces. User interfaces were a major hurdle in using early CMMSs. Their text-only orientation forced the user to know complicated procedures and a long list of codes. Training costs were high, and errors were common. With the graphical interface, both training costs and error frequency plummeted. A quandary for CMMS developers was the platform problem. UNIX computers were, and still are, rare in maintenance shops. The same goes for Apple. Just a few years ago, nearly every maintenance department ran on Windows 3.0/311, which meant they could run only 16-bit applications. With Windows 95 (and then Windows NT 4.0 the following year), maintenance departments gained the ability to run 32-bit programs (most of which are ODBC-compliant). This ushered in a world of possibilities.

Reporting features. Before we discuss what you can do with ODBC, let's see what some vendors did prior to its emergence. In the 16-bit world, you had the Object Linking and Embedding (OLE) standard, which allowed you to paste information from one application into another. This alone was powerful, because you could use a spreadsheet to create customized charts based on data collected from your CMMS.

Some vendors created crude reporting functions to satisfy the needs internal to the maintenance department. Some reporting functions allowed you to make a decent-looking chart. But until the advent of ODBC, it was difficult to make a good PowerPoint, Excel, or Intranet presentation based on your CMMS. Enter, ODBC.