3rd Annual “Creating a 21st Century Maintenance Organization Conference”

The sub-title of this presentation  "Reliability-centered knowledge" is meant to convey that the central purpose of knowledge in maintenance is to improve reliability[1] at lowest cost. And the title implies that we intend to extract such knowledge from our maintenance databases – particularly from the CMMS.

By-in-large, maintainers have failed to use, effectively, the information they collect, despite elaborate, expensive computerized maintenance management systems. Question 1: “How may we exploit rich historical information to make better maintenance decisions?”. Question 2: “In doing so, how can we leverage the computer systems that we already have in place?”

Slide 1

Attacking these questions, we’ll describe just what a reliability-centered knowledge base is.  Then we’ll discuss how we might convert the typically discordant data in most CMMSs into a true intellectual asset.

Once we have set up procedures for building a knowledge base, we'll discover how to extract wisdom. Note the escalation of terminology – data – information – knowledge – wisdom. My definition of wisdom is the ability to exploit knowledge to accomplish stated objectives, in this case effective maintenance. We define “effective” as producing high Overall Equipment Effectiveness (Availability x Productivity x Quality) safely at lowest cost.

Slide 2

One may begin by defining what recorded information we might be collecting. And secondly, in broad terms, by asking, what  we intend to do with it. The information that we routinely record comes from just two sources. 1. Failure data – information surrounding a failure[2], and 2. Inspection findings – the information that we collect when a failure hasn't occurred. The latter includes pro-active monitoring tasks, scheduled overhauls, and operational data.

We respond to recorded information in order to improve OEE in five ways: They are: ... [see right of Slide 3]. What role should our CMMS play in accomplishing these 5 continuous improvement activities?

Slide 3

Approaching this question as we would in an RCM analysis, we might perform a functional analysis on our CMMS. Functions begin with the word “to”, followed by a verb and one or more performance specifications. Here are some functions (Slide 4 and Slide 5) that our CMMS must deliver to the satisfaction of our users. 

Slide 4

Does anyone of you know of an operating CMMS that fulfills most these functions? Any of these functions? I contend that this knowledge potential has been overlooked by vendors, implementers, and users of computerized maintenance management systems.

Slide 5

I  propose, then, the adjacent [Slide 6] as a central objective for any maintenance operation ...

Slide 6

When we build any system, especially a complex one, we would wish to use a language that communicates the details of that system to everyone involved. The system development community has agreed upon the Unified Modeling Language (UML)[3] to convey, through diagrams, the multitude of perspectives of an evolving business solution. The UML “context diagram” of Slide 7 shows a proposed system and the actors who interrelate with it. Other actors such, as equipment vendors, maintenance or process specialists may likewise appear on the context diagram. Even other systems and intelligent agents might be shown,  as interacting with our “reliability-centered knowledge system”.

Slide 7

Slide 8 contains the unified modeling language’s class diagram of a work order. The work order is the “maintenance action form” – the fundamental record of what happened. The work order class diagram represents the work order class. A class is simply a specification of what a work order should be and do. Notice that the diagram has three parts. The top part holds the class name. The middle part specifies what it should be – its attributes. And the bottom part, what it should do – its operations.

Slide 8

For example, the work order class diagram of Slide 9 indicates that a work order should have a number, refer to a particular equipment, and expose the working age of the equipment.

One of the things it might do is to calculate cost, or perhaps, estimate time.

Note that a UML class diagram never exposes everything there is to know about its entity, but only those aspects that are of importance to the discussion of the moment. (In techno-speak we might say that the diagram is an abstraction from the totality of the work order class.)

Question: What attributes should should a work order have, to support reliability (OEE) analysis and improvement?

Slide 9

Answer: The 7 knowledge elements (questions) of reliability-centered maintenance (RCM.) Here we abstract the first 5 elements as work order class attributes. While the RCM question asks, “What are the item’s functions?”, the work order asks, “Which function was lost or compromised in this instance?”.

The work order continues to ask: In what way was it compromised?, what was the cause?, what were the effects?, and what were the consequences?

Slide 10

Let us switch views, for a moment, from the unified modeling language to the data modeling language of an entity relationship diagram. In Slide 11 we propose a structure for the relationship of a work order to the knowledge base, which, we encapsulate in a table called “RCM_table”. The properties of that table, include, not unsurprisingly, the seven knowledge elements of reliability centered maintenance.

The one-to-many cardinality relationship (represented by the three-pronged reverse arrowhead) is telling us that each work order instance corresponds to one record in the knowledge base.

Slide 11

Now return to the UML. Imagine the actors who need to perform certain functions within our knowledge based system. The “maintainer”, for example, must accomplish the function “To close the work order” by capturing all the relevant information required by our knowledge base. He must  represent his observations and actions consistently in the right format. Furthermore, he should avoid any extraneous information that adds no value to the knowledge repository. A tall order in itself.

Yet there is a further problem. We said (in Slide 11) that a work order must correspond to a unique record in the RCM table. What if no such record exists? Either the RCM team did not yet get to that item, or they overlooked the particular failure mode that has actually occurred. Thus, we should extend the use case “Close the work order” with an additional use case “Insert an RCM record”.[4] The maintainer needs to insert a new record in the RCM table. The steps he will follow mirror the 7 question process of RCM analysis.

Question: Can we seriously expect the maintainer to update the RCM analysis, on his own, with adequate care and attention, in little time, where a dedicated RCM team performs this task benefitting from properly allocated resources and time? The answer, obviously, is no. Yet, our knowledge base must, somehow, assimilate this invaluable information at this opportune moment. What can we do?

Our system must provide collaborative functionality that will support the integrity and accuracy of our knowledge base. In particular it must provide the six functions listed in the shaded box of Slide 12.

Slide 12

The UML sequence diagram of Slide 13 describes the ways that objects in our system may collaborate with one another with regard to knowledge integrity.  An, object (or instance) of the maintainer class, say “Joe”, inserts a new record in RCM_Table. This is represented, in the diagram, by the appearance (creation) of the RCM_record object slightly lower down on the sequence timeline. That object sends a message to the maintenance supervisor invoking his “verification” operation. The RCM object sends a message to the maintainer activiting his review of the changes. The maintainer may initiate a face-to-face discussion with the supervisor, perhaps at the regular daily or weekly meeting.[5]

Slide 13

Now that we have conceptualized a reliability-centered knowledge base embedded in our CMMS processes,  what do we want to do with the knowledge? We would like to use that knowledge to analyze current data. Specifically, we  desire to help the maintenance planner, charged with taking stock of the myriad factors influencing his decisions, in order  to  plan maintenance optimally.

Slide 14

In defining the knowledge functions of a CMMS (in Slide 4 and Slide 5), we stipulated the requirement of assessing the effectiveness of our CBM programs. When a CMMS is used and configured as a reliability knowledge base we may generate, using reliability software, analyses such as this one (Slide 15). The conditional probability of failure is plotted against an asset's working age. The CMMS record (via the 7 knowledge elements) records and discriminates potential failures as well as functional failures. By definition, potential failures have no dire consequences. We note, in the case illustrated in Slide 15, that the functional failure (conditional probability) curve is low and flat – the characteristic shape of a well maintained item.  The difference between the “Total removals” curve and the “functional failures” curve represents the value (effectiveness) of the CBM program for that item. CBM detects potential failures in order to avoid the consequences of functional failure.

Slide 15

Here is a similar age-reliability analysis that discriminates among failure modes of a given failure because our CMMS now records the  work order attribute “cause of failure”.

Failure mode “A” displays infant mortality. Failure mode B displays random failure[6] behaviour and failure mode C displays wearout. Such an analysis may direct our maintenance managerial attention to training or to quality problems in the case of failure mode A, or to the possible requirement for scheduled asset renewal in the case of failure mode C. A process or physical redesign might be appropriate to reduce the random conditional probability of failure mode B.

Thus, a CMMS configured and operated as a reliability-centered knowledge base can generate information that will support a variety of reliability analyses that will allow it to meet many of the desirable functions listed in Slide 4 and Slide 5.

Slide 16[7]

An advanced form of age exporation is implemented by OMDEC’s software product, “EXAKT”. It enables the continuous assessment and improvement of an organization’s condition based maintenance programs. See the article "The Elusive P-F Interval"[8]

Slide 17