A substantiated maintenance concept in six steps

In my work, I often come into contact with customers who feel that maintenance can be better and, above all, cheaper. Then there are those customers who are fine with everything and see maintenance more as a necessary evil. In this blog I will explain the usefulness and necessity of having a substantiated maintenance concept and how it can be managed.

At Stork Asset Management Technology, we work on the basis of our Asset Management Model (see figure). This also includes the Maintenance Concept component, by which we mean a substantiated maintenance concept.

Asset Management Model

Substantiated means nothing more than indicating why you're doing something. If we relate this to the "Maintenance" process, we map out the consequences of carrying out or not carrying out certain maintenance tasks or whether or not we have spare parts in stock. As a frame of reference, we use the risk matrices used by the company. This almost always concerns the aspects Safety, Environment, Availability (Loss of production) and (Maintenance) Costs. In addition, the Quality and Image are also considered, depending on the company.

Creating a maintenance concept

There are several methods to develop a good maintenance concept. One of the best known and also most widely used is John Moubray's RCM (Reliability Centered Maintenance) method. Stork Asset Management Technology applies a 6-step methodology within this framework. This method can be adapted in depth to the wishes of the customer, ranging from very detailed to "fairly global".  In general terms, the approach is as follows:

1. Define the object structure, this is the "coat rack" on which all work, documentation and other information is hung. This is a very important step on which you can justifiably spend a lot of time, because in the end all management reports regarding implementation, budgeting, improvement, etc. will be linked to it.
2. Then determine which systems are "critical". We do this at the lowest possible system level in the established object structure. We use the company's risk matrices for this purpose. This allows us to determine in advance what we will spend time on in the follow-up process in the form of performing FMECAs (Failure Modes Effect & Criticality Analyses).
3. Execute the FMECAs. This is a labor-intensive process. The forms and causes of failure are mapped out. That is why we always do these preparations first, so as to minimize the time the customer has to spend on this task. We carry out the actual implementation of the FMECA together with the staff, which include maintenance managers, planners, mechanics, operators, technologists, etc. This step actually determines why you should do something or not. So we're talking about the underpinning of our maintenance operations.
4. Define the maintenance strategies to reduce or even eliminate the risks. By this we mean determining the type of applied maintenance. We distinguish between failure-based maintenance (FBM), condition-based maintenance (CBM) and time-based maintenance (TBM). We also look at whether or not having spare parts is useful.
5. Stipulate the tasks to be performed. The maintenance task is now described in a "one-liner" for each cause of failure found. It states what has to be done, who has to do it, how often it has to be done, how long it will take and what has to be considered in terms of operational management.
6. Cluster the preventive and predicative tasks into "smart" maintenance rounds. The logical sequence of equipment activities is taken into account.

The steps described actually form the core of the maintenance concept, but that's not all. There is another important process behind this.  The clustered tasks now need to be "managed" and executed, meaning that we need a maintenance management system. Think of SAP, Maximo, Ultimo, Datastream, etc., etc. The tasks from the maintenance concept must be read into this system. Only then can we plan and execute.

Finally, an important addition. We are increasingly noticing that there is a strong demand from the market for work instructions. A maintenance concept is the trigger to perform the maintenance and describes Who, What, When, Where and Why. The How, on the other hand, describes the task steps in which the final maintenance task must be carried out. Which employees are needed, in what order should the work be carried out and what materials and equipment do they need? Especially if maintenance is outsourced, this is a welcome addition.

Application of an RCM application

There are several software programs on the market that allow you to easily record this methodology for a maintenance concept in a system. Examples are Meridium, Ivara, Isograph, SKF and Optimizer+. These are certainly good programs in themselves that can help you to record the maintenance concept. One program can do a bit more or a bit different than another program, and so each program has its own advantages and disadvantages. The consultants who work at Stork are very familiar with each of these programs. However, time and again it appears that when a project is delivered, a discussion arises about how the data should be delivered, despite the fact that this has been talked about beforehand. Think of Excel sheets and PDF files. The core issue appears to be that customers are often not inclined to buy the RCM software that was used during the project (see above) for price reasons.

Is there another way?

Yes, we think there is. We have developed a simple application for our customers who do not have their own application or do not want to buy one, which can store the most essential data . No, it's not a "real" RCM application, but the great advantage of this application is that the (limited!) data that you enter can be retrieved immediately through simple, clear reports.  Think, for example, of inspection lists.

The departure point for this application is that our consultant uses the application during the development of the maintenance concept and that afterwards the customer can take over the application for a small fee. In this way, the customer gets a very good understanding of the application's operation and functionality. This has the great advantage for the customer that he can, for example, carry out later expansions with the help of this application.

The application is made customer-specific, i.e. the company's own risk matrices are implemented and the reports are adjusted accordingly. Finally, it is worth mentioning that after delivery, a Help Desk will of course be available for support and for solving issues.