Are we marching to a different drum?. Why is LRCM out of step with the established community of reliability experts and authors. If it is so good why haven’t the others caught on?
The obvious strategy of treating work orders as instances of RCM knowledge base records and growing the knowledge base dynamically as a result of daily experience should be a “no-brainer” for reliability software and CMMS developers. How have they missed it?
The answer emerges when we unfold the history of the maintenance technology industry. The CMMS came to light in the late seventies. This was about the same time RCM took final shape in aviation where it is called “MSG3”. Each of these commercial ventures flourished as independent streams. They were propelled by their respective proponents, vendors, thought leaders and consultants.
During the same period a third movement, that we can call “reliability analysis” attempted to migrate from the design and fabrication phases in order to penetrate the maintenance world. This group of experts, authors, and software vendors, were often associated with universities, developing their products (e.g. Weibull, and Monte Carlo simulation) largely independently of the other two groups. Reliability analysis floundered, however, in the maintenance shop in spite of a strong desire in the maintenance department to make effective use of these analytical tools. Maintenance engineers, keen to apply reliability theory, purchased these products and took the courses offered by the vendors. Inevitably they confronted the “data roadblock”. What was the obstacle?
Well, the CMMS developers came from having implemented information technology systems for the finance, accounting, and human relations departments. In those departments “codes” represent rather simple concepts (for example, cost allocation centers and so on). Such codification responded well to their users’ requirements. Now, these same IT professionals, having saturated the accounting system market, discovered a huge liability on the balance sheet called “maintenance” that was crying out for their computer savvy. Since mnemonic codes and lists of standardized short expressions worked so well in finance, accounting, and human relations, drop down filtered lists of “failure” codes should work in the “simpler” maintenance shop, or so they thought.
An RCM consultant is unlikely to have acquired the statistically oriented skills of a reliability analyst or chemist who may have worked in product design or manufacturing quality control. To add to this alienation, Moubray discouraged reliability analysis in Chapter 12 “Actuarial Analysis of Failure Data” of his RCM II book, and in his RCM training courses. Consequently the RCM consultant focused on human knowledge elicitation, only peripherally acknowledging that age or condition based failure behavior at the granularity of the failure mode is revealed ultimately from data. Such knowledge, of course, would require an analysis of statistically sound samples of data originating from, none other than, the CMMS.
Compounding the RCM consultant’s aversion to reliability analysis, the CMMS, sadly and for the reasons mentioned, offered “failure codes” as the reliability related work order attributes. The CMMS developers hadn’t considered the work order as instantiating an Item – Function – Failure – Mode – Effects (FMEA) record in the RCM knowledge repository. They labored, instead, under the false assumption that failure codes should “do the trick”. This mental blockage resulted in forty years of relentless yet futile effort by maintenance engineers, managers, consultants, and software vendors to analyze and draw verifiable conclusions from compilations of instances of failure codes. They failed dismally for the simple reason that failure codes, no matter how well presented by a software application’s user interface, cannot substitute for comprehensive RCM analysis. A failure mode is meaningful only in the context of the FMEA’s corresponding Function, Failure, and Effects. Inconsistency, confusion, resorting to the default “Other”, and lack of confidence in analysis were and still are the outward manifestation of a flawed and mistakenly applied “failure code strategy” in the management of maintenance information.
© 2011, Murray Wiseman. All rights reserved.