YOUR CART

WHITE PAPER

Home-grown RCM Software?

This paper is a parody[1] of several alternative ways of documenting your Reliability-centred Maintenance (RCM) analyses and explains why the best choice is dedicated RCM database software focused on the activities of the RCM facilitator.

Some organisations are tempted to document their RCM analyses using a word processor or spreadsheet or even to write their own database application. This is a false economy because these ‘home-grown’ alternatives to properly-designed RCM Software rarely have any specific time saving features. If the organisation is to get a good return on its investment in RCM, it must provide the RCM facilitator and analysis group with the right tools.

The description focusses on the temptation to develop home-grown software using a typical office style word processing or spreadsheet application. The following conclusions are drawn:

[1] A dictionary definition of ‘parody is: an imitation of the style of a particular genre with deliberate exaggeration for comic effect.​

Thankfully, the days of having to do everything on paper are gone: RCM analyses are usually conducted and documented using a PC (except for simplicity in a training environment).

Using a word processor to document an RCM analysis soon becomes a configuration and logistical mess! The scale of the disadvantages is overwhelming if you multiply the problems by the number of RCM Analyses that you plan to do.

Too many companies have the employee who is a ‘whizz’ at using spreadsheets and who knocks up an ‘application’ to address the immediate need. Organisations should ask themselves if this is an appropriate way to collate, manage and store key data relating to critical safety, environmental and operationally important physical assets in a multi-million pound enterprise?

Spreadsheets are not the answer - they tend to grow like weeds and spread like wildfire, contain many errors, broken links, formula errors etc. Uncontrolled copies are common and the printed output poor.

Spreadsheets are rarely consistent from one RCM analysis to another and are often inaccurate. If there was ever an incident which led to a court case, the organisation would struggle to uphold any semblance of order and control in relation to the data underpinning the management of their physical assets.

Dedicated RCM software has many other benefits over word processors and spreadsheets. The key advantage is that the RCM data is stored in a secure, dedicated RCM database.

Some companies have developed their own in-house database applications with varying degrees of success. In general, home-grown RCM database applications are a false economy and most are very inferior to the commercial packages available. You need to question whether the true development cost/effort for an in-house application is worth the investment – the answer is nearly always ‘no’!

Introduction...

RCM imposes an administrative workload which grows with the size of the organisation and with the complexity and variety of systems analysed. Certainly during the 1980s, and even as recently as the early 1990s, many RCM Analyses were documented only on paper. This would frequently involve the use of pre-printed worksheets filled in by hand by the RCM Facilitator during the RCM Analysis meetings.

Of course, with hand-written worksheets only the Facilitator can see what is being, and has been, written. This leaves the analysis group members relying on their memories if they need to refer to, say, another Failure Mode or the list of Functions.

This is almost certainly why flip charts were a popular alternative to desk-bound worksheets. They could be attached to the meeting room walls and remain there for the entire duration of the Analysis, providing a permanent overview of everything that the Facilitator wrote down.

At the end of an Analysis everything would need to be passed to a typist to convert the hand-written sheets and flip charts into presentable typed documents. This includes:​

Operating Context

Function list

Functional Failures

Failure Modes

Failure Effects

The analysis group’s responses to Decision Logic questions

Maintenance Task Descriptions including the Task Intervals and Who Does it

Operator Task Descriptions

Equipment Modifications

Training requirements

Revisions to Operating and Maintenance Procedures.

Once the documentation is complete, it can be photocopied and disseminated to those who need it in order to continue with the implementation of the analysis output.

So, What Was Wrong With Paper?

When pen and paper was the only option, few people bothered to consider what was wrong with it. That was quite understandable; with no other option, we just had to “get on with it”.

However, given the alternatives available today (which are discussed later), the disadvantages of a paper-only system are very apparent:

Speed of writing – if the source documentation is hand-written then it must be legible. This slows down the facilitator, which can lead them to write less than they should by way of explanation or audit trail

Legibility – if a facilitator thinks they are writing too slowly they may attempt to speed up or start using a lot of abbreviation and short-hand. This will affect legibility and, hence, increase the time taken to type up the analysis

Data loss – it’s not only computers that suffer from data loss. Hand-written papers and flip charts represent the only copy of an analysis until they are typed up or photocopied. Paperwork can get lost in transit, damaged, destroyed or inadvertently disposed of – often with no hope of recovery

Bulk – a completed RCM analysis can occupy a lot of paper, which soon adds up to a lot of physical storage space for a large RCM project. This problem is multiplied by the number of copies required by many different departments involved in subsequent implementation

Inconvenience – when it comes to making copies or amendments, paper is simply inconvenient, time-consuming and costly. For example, consider using one paper analysis as a template for another; it will have to be photocopied, amended by hand and then completely retyped.

That’s not an exhaustive list but, clearly, paper-based systems had several significant disadvantages which were happily tolerated by armies of clerical personnel at a time when there were no viable alternatives.

Thankfully, the days of having to do everything on paper are gone: RCM analyses are usually conducted and documented using a PC (except in a training environment where case studies are usually paper-based for simplicity).

Computers and RCM.... Word Processors

When RCM was first being applied in general industry there was no dedicated software available for documenting the application of the process. But that wasn’t a big concern for engineers at the time. The RCM worksheets looked like perfect candidates for a spreadsheet or a word processor form.

And for many facilitators today, that is still the case. After all, office software is now extremely capable with a whole host of advanced features so why not use it for RCM?

You have just finished RCM Facilitator training. Your first RCM Analysis is coming up. You don’t have a dedicated RCM software package but you do know how to get your word processor to produce forms that look just like those worksheets used on your course.

So, that's what you do. If you thought ahead then the tops of the forms are in the header section and you have saved the documents as reusable templates. When you start the Analysis you realise that you need somewhere to write the equipment's Operating Context. Quick, create another document. Type in the text and save it. Ideally, it should be linked to both the RCM Analysis and the associated Asset.

That implies that there should be a list of Assets somewhere. OK, better put something together to list the assets that will be analysed using RCM. That's another document - a big table with several columns.

Referring to the word processor help system first, you create links in the Operating Context document pointing to the Analysis documents. But how can you link to the relevant entry in the document with the big list of Assets? After reading the help again, you create a bookmark in the Asset List and reference it in the Operating Context document.

This is beginning to look like a bit of a headache in terms of keeping track of lots of different documents and the links between them; there are four documents already and the Analysis meetings haven't even started yet.

When you start typing in the Functions, Functional Failures, Failure Modes and Failure Effects, you realise that the way you have laid out the form doesn't allow very well for entries of varying length (eg some Failure Modes have a short set of Effects, some much longer). The form is going to look a bit of a mess when it is printed out.

Similar problems arise in your form for recording the Decision Logic Responses. Some need a lot of Supporting Comments (for the Audit Trail) and some need none. You find the same with Maintenance Tasks. What about Redesigns? Should they go in the same document as the Maintenance Tasks, or should they have their own document? You decide to create a new document, knowing that you will need to be able to produce a separate Redesigns report at the end of the analysis. Now that's another document-to-document link to be created and maintained.

Also, if your facilitation style is to take each Failure Mode through the process from start to finish then you need at least two documents open at the same time, frequently switching between them as required.

Managing several different documents for a single RCM Analysis has become quite a challenge and is taking up too much of your valuable time. However, you persevere and complete the Analysis. After reviewing the Analysis yourself you realise that there a number of corrections to be made - several Failure Modes have been recorded under the wrong Functional Failure so they need to be moved. Unfortunately, you discover that the layout of your document forces you to make several Cut/Paste trips through the "clipboard" in order to make the move - and that was just one document. You now need to make the same move in the Decisions document and check if it also needs doing in the Redesigns document.

And when you realise that the analysis would look more logical if some of the Functions were rearranged, the editing nightmare really begins. You decide not to bother.

Now, it's time to put together a report for the Asset Manager so that your Analysis can be audited. So, you print out several different Analysis documents individually and bind them all together, probably including an extra document you have created as a summary of the Analysis outcomes.

The Asset Manager starts to read the report. All is well until they reach the document in which you recorded the decision for each Failure Mode. 1A17 produced an on-condition task. What was 1A17 again? Keep a finger at the current page and go back twenty pages for a reminder of the Failure Mode's description and Effects. But what was the Function? Put a second finger in the report and thumb back another three pages. What's more, it produced a Redesign - where are those in the report? The reader begins to run out of fingers!

Now multiply the above by the number of RCM Analyses that you plan to do and the scale of the disadvantages of word processor documents looks overwhelming. The project would soon become a configuration and logistical mess.

It looks like a more structured approach is required. What about using a spreadsheet?

Computers and RCM.... Spreadsheets

Yes, surely a spreadsheet will be the answer. The data can be placed neatly in rows and columns. We can have a worksheet for each part of the Analysis and maybe one entire Analysis can be saved in a single spreadsheet file – sounds perfect. That is what you do for your second wave of RCM analyses.

For the first of these, you start with the Operating Context and create a worksheet for it. In this worksheet you create labels and cells for the Asset Name, maybe its CMMS Tag Number and the Operating Context. Realising that a full Operating Context description can require a very large number of words, you resize the cell to occupy most of the available screen space.

But where does this Asset fit in the site Asset Hierarchy and how are you going to convey this in the spreadsheet? You decide that you will need a big list of assets – but you already have one in that large word processor document created 18 months ago. After an hour searching for this document you open it only to find that the table isn’t structured well enough for you to create reliable bookmarks and cross references.

So, you begin editing it to tidy it up. After struggling with it for two days you abandon the idea and decide that a separate Asset Register spread-sheet is required and that each Analysis spreadsheet will link back to the relevant Asset cell on the Asset Register spreadsheet.

For the first Asset’s Operating Context, you copy text from various sources to paste into the Operating Context cell in the spreadsheet. The text quickly grows and requires more screen space than a single spreadsheet cell can display. But you persevere, finally getting it all in after much frustrating manipulation of cursor keys and scroll bars.

That was the easy part. Now you have to think about how to design the rest of the spreadsheet. Some possibilities for the rest of the Analysis data are:

A -A second worksheet contains the all Functions, Functional Failures, Failure Modes, Failure Effects, Decision Logic Responses, Mainte-nance Tasks and Redesigns. This option has some appeal – it’s easy to comprehend and nearly everything is in one place.

B - The second worksheet contains only Functions, Functional Failures, Failure Modes & Effects – much like a traditional paper-based Infor-mation Worksheet. The third worksheet contains the Decision Logic Responses, Maintenance Tasks and Redesigns – much like a traditional paper-based Decision Worksheet. This option has merit and “feels” right because the output looks like the worksheets in your training course case studies.

C - The rest of the Analysis has a separate worksheet for each of the remaining entities (ie Functions, Functional Failures, Failure Modes & Effects, Decision Logic Responses, Maintenance Tasks and Rede-signs) – so at least another 5 worksheets (depending how you organise it). This option looks like it would need a disproportionate amount of effort to make it work successfully.

You decide that you are most comfortable with Option B.

Whichever option you choose, each Function needs an identifying number. Now spreadsheets are good at arithmetic so you arrange cell formulae to automatically number each Function. It is similar for Functional Failures – they need a unique reference. Again, you use formulae to generate their reference letters automatically (not quite as simple as incrementing numbers, but you eventually work out how to do it). Failure Modes also need a unique reference so formulae are used again to generate these.

Now it is time for your first RCM Analysis meeting. You want to print a few copies of the Operating Context for the review group members – that’s when you discover that the spreadsheet cannot print all of the text stored in the Operating Context worksheet. You resort to copying it into a word processor document in order to print it. During the meeting the group suggest a few amendments and you type them into the word processor document, hoping you will remember to copy them into the spreadsheet later (or maybe you won’t bother because of the printing issues).

After Operating Context, you work with the group to write a list of Functions and key them into the spreadsheet. Then you enter the first Functional Failure and the first Failure Mode & Effects. The Effects require a lot of words to explain what happens after the Failure Mode occurs so you resize the spreadsheet cell several times to fit them in.

Analysis of the Failure Mode took it into an On-condition Task box in the Decision Logic. There was a lot of discussion about the potential warning signs, the methods of detecting them and how much warning they would give. This needs to be paraphrased and captured in the spreadsheet. Realising there is nowhere for this information, you hastily create another column in the spreadsheet and type it in.

The group are unsure if the task is cost effective so you need to do a worth-doing calculation. Perfect – you are in a spreadsheet – what better tool for a calculation? In fact, you thought ahead and have a separate template spreadsheet for worth-doing calculations. You input the numbers and copy the calculation to the clipboard. Then you paste it onto the end of the existing Comments for this Decision Logic box. Well, the information is there but it is no longer laid out like it was in the template calculator - and the formulae are gone – it is now just plain text. If you want to amend any numbers you’ll have to start again – a bit of a pain but easier than having multiple links to template spreadsheets that have all the formulae.

At the end of that first day you have a number of Failure Modes entered and analysed – but the data looks extremely untidy. You subsequently spend 2 hours adjusting fonts and cell sizes until it all becomes vaguely presentable.

Over the course of the next few meetings, it becomes clear that you often need to write the same words over and over again in places like Failure Effects and Task Descriptions. This requires a large amount of scrolling around the (now very large) spreadsheet and multiple trips through the clipboard. It works but it also consume a lot of time and the RCM analysis group members get restless waiting for you to master the problems.

Eventually, you have to do a Failure-finding Interval (FFI) calculation. For this you have already prepared a separate worksheet with templates for the FFI formulae you learned about on your Facilitator course. The relevant template needs to be copied and pasted in the FFI worksheet. For each calculation you have to point the reference cell back to the Failure Mode on the Information Worksheet worksheet. Then you need a reference cell in the Failure Mode row pointing to the relevant calculation in the FFI worksheet.

In fact, in order to help with navigating around the analysis, every row in every worksheet requires reference cell(s) pointing to row(s) in several other worksheets. All these cross-referencing links are fragile and easily corrupted.

Then the problems really start to escalate:

After the analysis is complete, in response to the Auditor’s com-ments, it is necessary to move Functional Failure 2B to Function 4 and to move three of 2B’s Failure Modes to Functional Failure 3A. Your attempts to do this result in a large number of corrupted cross references and formulae which take hours to correct

The Auditor’s review may lead you to delete Function 7. So you go to the Information Worksheet worksheet and delete Function 7’s text. But the number “7” is still there in the Reference cell. Should you just delete the content of that cell, should you delete the whole row or should you just leave it as it is? You also face the same questions for Functional Failure 7A and Failure Modes 7A1 to 7A4. Then you have to go to the Decision Worksheet worksheet to delete accordingly. Same for the Redesigns worksheet, the FFI Calculations worksheet, etc. The spreadsheet now looks messy, with gaps and/or error messages

Half way through this project, a member of your team accidentally deletes the Asset Register spreadsheet. You ask IT to restore it from a backup, only for them to tell you that a configuration error means the most recent available backup is from 6 weeks ago. You salvage old print outs and spend a couple of days re-entering as much of the data as you can, hoping you have correctly recreated all the cross-referencing links

Then a colleague asks for a copy of the spreadsheet so that he can check some of the data – there is now an uncontrolled copy of the data on the loose and before you know it others are passing on versions of the data with corrupted links, data etc etc.

At the end of this 2nd wave of RCM Analyses, you now have a significant number of spreadsheets plus uncontrolled copies. It is likely that those spreadsheets are not fully consistent with each other – some have columns missing, some have extra columns, the formulae in some are slightly different from others, some cells have plain text rather than a calculated value, etc, etc.

Is this really an appropriate way to collate, manage and store key data relating to critical safety, environmental and operationally important physical assets in a multi-million pound enterprise? If there was ever an incident which led to a court case, the organisation would struggle to uphold any semblance of order and control in relation to the data underpinning the management of their physical assets.

Dedicated RCM Software...

After struggling with both the Word Processor and Spreadsheet approaches, it is clear that your RCM analyses would best be documented in a properly-designed RCM database. The data held in a database is driven and managed by the database engine software. The interface between you and the database is the RCM software application.

The RCM database, the database engine and the software application work together to provide enormous benefits compared with word processors or spreadsheets.

A Place for Everything, Everything in Its Place

With a database, the structure of all the entities and the relationships between them are pre-defined and enforced by the database engine itself. This ensures that every RCM Analysis is documented in the same consistent format.

All your RCM Analysis data is in one database. Because of this, everything is easy to find – no more searching through dozens or hundreds of separate files in your computer’s filing system. No more uncontrolled copies of the underlying data.

With word processors and spreadsheets, any user can type anything they like in any part of the document without any regard for its purpose. A database ensures that data cannot be entered “gratuitously” – it can be entered only in the labelled boxes provided on the screen and will be stored in the appropriate field and table in the database.

Data Integrity

To a large extent, data can be validated (and rejected if necessary) on entry, either by the software application or by the database engine. For example, you would not be able to put text into a field that is expecting a number (like a cost of a spare part).

If you do have to delete a Function then the database will automatically delete all of its Functional Failures, Failure Modes, Tasks, Redesigns, etc.

The cross-referencing links between all the entities (Assets, Analyses, Functions, Failure Modes, etc etc) are hidden from the end user and automatically maintained/enforced by the database and the database engine. (This is known as “referential integrity”.)

This means that if you wish to move data or change the human-readable Reference for any entity (eg change a Function’s number) then you can do so instantly and without worrying about the consequences.

With a database there is guaranteed to be only ever one live copy of the RCM data. Compare this with word processors and spreadsheets where individual files can be copied (or deleted) at any time, either intentionally or unintentionally.

Reporting

Before the output of an RCM Analysis is implemented it should be reviewed/audited by someone with overall responsibility for the Asset(s). Auditors have to satisfy themselves that the Analysis as a whole is acceptable and that the analysis of each Failure Mode is both sensible and defensible. This could be done either on paper or electronically.

Either way, the Analysis output in a quality RCM database application will be well presented and easy to read and comprehend. This is difficult to achieve if the Analysis is distributed across multiple word processor documents or spreadsheets.

A well-designed database and associated full-featured software application, however, can present the entire Analysis in a single document in a way that allows the Auditor to progress logically through it page by page, with all of the information associated with each Failure Mode all in the same place – no more running out of fingers to keep place at various pages in the report!

Copying Information

RCM Facilitators frequently find that the information they need to record about a Failure Mode is very similar to that which they have already entered for a previous Failure Mode (either in the current RCM Analysis or a different one).

To copy 4 pieces of information from another Failure Mode (eg Effects, Downtime, Decision Logic Responses and Maintenance Task) in word processor documents or spreadsheets, the Facilitator must struggle through the following:

Open another document or spreadsheet if the information to be copied is in a different RCM Analysis

Scroll to the appropriate page or worksheet

Select the Failure Effect text and copy it into the clipboard

Return to the current Analysis (possibly having to find it amongst several other open documents or spreadsheets)

Paste the copied text into the correct location

Repeat all of the above at least 3 times (potentially up to a dozen times) for the other pieces of information.

To copy the same 4 pieces of information using quality RCM software, the Facilitator will have to do something like:

Open another RCM Analysis window if necessary

Instantly locate the required Failure Mode using advanced search features

Right-click on the Failure Mode and tick check boxes for the 4 required items

Click on OK.

If the Facilitator wishes to copy an entire Failure Mode (either within one Analysis or between two Analyses) then this would be a major operation in a word processor or spreadsheet (with plenty of scope for mistakes). It will also consumes a lot of time – meanwhile the RCM analysis group members get restless waiting….. Again, in a quality RCM software package this can be achieved with a single drag’n’drop operation, taking only a few seconds!

Speed of Data Entry

RCM Facilitators frequently find that they often need to write the same text many times (often specific to each individual Analysis).

The Facilitator types the following text into the Failure Effects field and realises it will save them time if they store it as an Auto Text entry:

‘The failure will be obvious to the operator, who will report to maintenance. The machine will be taken out of service and the backup will be brought online.’

The Facilitator wishes to set up an Auto Text so that, say, ‘oto’ is automatically replaced by the above text. Here is a comparison of the procedure for setting an Auto Text definition in a word processor and dedicated RCM software:

For a state-of-the-art word processor the procedure is something like:

Select the above text

Copy it into the clipboard

Click on the “File” menu

Click on “Options”

Click on “Proofing”

Click on “AutoCorrect Options”

Enter ‘oto’ into the “Replace” box

Paste the copied text into the “With” box

Click on “OK”

Click on “OK”.

The procedure for creating a similar Auto Text definition in a modern RCM application might be as follows:

Select the above text

Press Alt-S on the keyboard

Enter ‘oto’ into the box labelled “Shortcut Text”

Click on “OK”.

Cumulatively these snippets of time saving all add up; the overall result is that RCM facilitator productivity is increased massively and the RCM analysis group members no longer have time get restless!

User Authentication

Much of the information contained in an RCM analysis is commercially sensitive – access to the data is, understandably restricted within an organisation.

If an RCM analysis is documented using a word processor or spreadsheet it is possible to control the access of individual users to networked folders. However, this is often a topic not fully understood by the average office application user. IT departments need to get involved in configuring folders and controlling permissions to them. This also relies on RCM team members storing their documents in the correct folders but does not prevent them from copying files into unrestricted folders.

In a dedicated RCM database, User Management can be simplified sufficiently to enable an average user to manage the creation and access rights of other database users. Commercially sensitive information can be readily restricted to only those who are authorised to access the data.

Additional Benefits

Dedicated RCM software has many other benefits over word processors and spreadsheets that are a by-product of the fact that the RCM data is stored in a dedicated RCM database.

Examples include:

Querying of Data: the database can be queried to the full extent of the capabilities of the SQL query language. Queries operate on the entire database, extracting the desired information from multiple RCM Analyses at the same time. This is simply impossible if your data is distributed across dozens of documents or spreadsheets

Lookup Tables and Data Validation: dedicated software running over a database allows the users to control the lists of available entries for certain data fields. For example, a drop-down box can be used for the user to select from a list of Skills for a Maintenance Task, ensuring all Maintenance Task skills are documented in a consistent way. With word processors and spreadsheets the user can enter almost anything in this field, making subsequent processing (such as looking to combine all the “Mechanic” tasks together) much more difficult

Ancillary Data: companies often wish to collect and store ancillary data that is not a formal requirement of the RCM process but which aids the overall management of the RCM project. Examples include:​

A list of Significant or Urgent Findings from the Analysis

A record of meeting dates and attendees (ie a diary)

A list of documentation errors discovered during the Analysis

A record of symptoms and alarms that may be produced by each Failure Mode in order to generate a Fault-finding Guide

A list of spares requirements

Failure Mode criticalities etc

Data such as the above are easily incorporated into a well-designed database, which can link it to the appropriate RCM entities, ensuring it is always readily accessible as and when required.

Attempting to gather such data with word processors or documents just adds to difficulties associated with maintaining even more cross references between even more individual files.

Home-grown RCM Database...

Some companies have developed their own in-house database applications with varying degrees of success. In general, home-grown RCM database applications are a false economy for the following reasons:

The development cost/effort is rarely understood before it is too late and the on-going upkeep is not insignificant. The best RCM software databases have thousands of hours development behind them

The home-grown alternatives to properly-designed RCM Software rarely have any specific features that can shorten the time taken to conduct an RCM analysis. Experience has shown that these features can reduce the time taken to document an analysis by as much as 50%. Taking into account the other RCM group members, every hour of time saved in an RCM analysis meeting equates typically to 3-4 man hours saving in time!

If the organisation is to get a good return on its investment in RCM, it must provide the RCM facilitator and analysis group with the right tools to get the job done.

A few home-grown database applications work well (and overcome many of the difficulties encountered with word processors and spreadsheets) but most are very inferior to the commercial packages available. You need to question whether the development cost/effort for an in-house application is worth the investment – the answer is nearly always ‘no’!

Conclusion....

Quality dedicated RCM software running over a well-designed RCM database will always produce the following benefits when compared with home-grown word processors, spreadsheets or database applications:

Massively improved Facilitator productivity

Increased data integrity

Decreased risk of data loss

Simpler user management

Ease of querying and reporting

Ability to store much more useful ancillary information

Review & Auditing of Analyses is much easier and, therefore, more efficient.

Do yourself and your company a favour – follow the links to RCM software!

Further Information...

This paper was written by Simon Deakin and Steve Bailey of Mutual Consultants Ltd. Please do not hesitate to contact either of us for more information on RCM software: