Tips for Maintenance Computer System Implementation and Improvement

This article contains a list of a few of the things that should be considered when implementing a maintenance computer system, with some good and bad examples. Many of these tips can also be used to address some common problems in existing systems.

These guidelines are based on the principle that the primary purpose of a maintenance computer system is always to help maintenance people at all levels to provide the best possible support to their operation. While still important it should be a secondary objective to provide a measurement of maintenance activity, including costs.

Tips:

Field value (or “drop-down” lists)

The most common error in implementing systems is to use illogical drop-down lists for important fields in the database. There are three kinds of drop-down lists, as follows:

a. Lists where only one value can be selected.

This is the most common type of value list, and usually the options are codes that are used for filtering, sorting and reporting records, such as work orders, purchased or inventoried materials, equipment locations (or “assets”), etc.

There are some very important principles that must be observed when developing drop-down lists for these fields

A knowledgeable person must always be able to select one and only one value that applies.

For example, if a field named “Type” applies to a number of objects of different shapes and colours, and the drop-down list includes options such as “blue”, “square”, “triangular”, “green”, etc, a knowledgeable person would be able to select two values that apply for a square blue object. For this reason, fields named “Type”, “Class”, “Category” or any other non-specific descriptions should always be avoided.

In this simple case, for these objects there needs to be two fields, one named “Shape” and the other named “Colour”. Shape and colour are the “characteristics” of the objects and the general principle is that there must be one field for each characteristic.

Field titles must always name the characteristic described by the options in the value list.

Here’s an actual (very bad) example of a drop-down list for a “Work Order Type”

Capital
Warranty
Process mod.
Corrective
Modification
Preventive
Contractor
Machine/tooling
Spares
Emergency
Maint. project
Safety
Environment
Production support
Standing WO

The characteristics of these values include the source of funding, the reason for the work, the resources required, the type of asset and the action to be taken by the tradespeople. A knowledgeable person would be able to select four or five that would apply to many work orders. Each of the characteristics should have its own field with the appropriate field name.

If lists contain a mixture of characteristics where more that one value can apply, the data collected will be of little value, and perhaps completely useless, for managing and reporting information. If, for example, you’ve promised your Health and Safety Committee members a list of all safety work orders, it won’t be complete if some work that’s being done for safety reasons is coded as “Capital”.

These principles apply to all fields in any database, not just work orders.

Illogical value lists are very common. I have seen “Failure codes” and “Material Category codes” with over 100 options in the value lists. If the value list is long, it will invariably break the “one characteristic” principle and provide little value.

Field names and value lists must be very carefully designed and equally carefully controlled. Value lists of this type must never be open for editing by unauthorized people.

For more on field names and value lists for work orders see the article “Work Order Coding“.

b. Lists where multiple values can be selected.

These are less common and have some value, but their use requires additional filters to produce useful reports.

c. List where the values are entities

For example, clicking on the “drop-down” arrow may open a list of assets, catalogued materials, employees, etc. In this case there will almost always be an intermediate step providing a search function, so these are not really “drop-down”‘ lists in the true sense.

Equipment location, work order and parts descriptions

There are two, distinct purposes for work order, equipment location and parts (and some other) descriptions

a. To enable a word search to find the work order, equipment location or part in the appropriate database.

For this purpose, the description must not contain abbreviations. It is very difficult to search if you don’t know that “coupling” has been entered as “cplg” or “transmitter” has been entered as “tx”.

b. To identify the work order, equipment location or part on standard reports or screens.

Consider the people who will be using these reports, which include backlog lists, work schedules and so on. It will almost always be experienced people such as area operating supervisors, maintenance supervisors and planners who are thoroughly familiar with the work.

Managing lists of work, such as backlogs, is much easier if the maximum amount of relevant information can be shown on a single page or screen, without scrolling. The descriptions here should be abbreviated as much as possible and will still be recognized by the local experts who will read them.

Work order descriptions and equipment locations descriptions require two fields, one with no abbreviations and one with maximum abbreviations.

There are some other important principles that apply to descriptions

Wherever a number, such as an equipment location number or a work order number is shown, it must always be accompanied by the short description. A list of numbers alone forces the person managing the information to open each record to identify the work or equipment. This principle applies to all databases.
The system should be configured to limit the number of characters permitted in the short description, and all reports and screens that include these descriptions should be designed to show the same number of characters. This avoids reports with work descriptions such as “Please send a mechanic to inspect and repair the…” (a real example).
Finally, work order lists, such as backlogs, should always show the equipment location number and the short equipment location description as well as the work order short description. This allows the work description to be very brief. For example, if the work is to check the alignment of a hot water pump, the work order short description can be just “Check alignment” and not “Check alignment of No. 3 hot water pump”.

Hide unnecessary fields and other information

To make all screens and reports as useful as possible, unnecessary information should be hidden. Examples includes:

– leading zeroes on work order and part numbers

– fields that are not required for common transactions

As an example, I have seen a practical and inexpensive system where a single screen contained all the fields required to add a new item to Stores inventory and all these fields required a useful entry. I have seen another (incidentally, very much more expensive) system where adding an inventory item required 22 screens. Some of these screens had up to 40 fields of which only one needed an entry. Two of the screens had fields which were mandatory but the information entered was of no value for managing the inventory item – an extreme example of a very poor system implementation.

Naming standards

The standards used for naming equipment locations and materials catalogue items should be carefully designed before this data is entered. And the design must take into account the system’s search functionality. A couple of things to consider are:

– “Search” (unabbreviated) vs “Identifying” (abbreviated) information

– dimensioning standards (for inventory items this needs to include both “order” and “issue” quantities)

See “Naming parts” for a full description of naming standards.

Configure the system for the most common types of transactions

Make sure that there is a simple, ideally “single screen” process for:

– requesting maintenance work

– checking the status of maintenance work

– requesting inventory items and

– purchasing items

These are all functions that may be required by people who are not frequent system users.

Select the fields that are needed before populating the materials catalogue database

Beside the common fields for catalogue items, such as order quantity, repairable/non-repairable, etc, consider the many other possibilities that exist which include:

– does it have an MSDS?

– shelf life

– interchangeability with other parts. Some may be interchangeable for temporary use, such as mild steel parts to replace stainless steel parts for long enough to purchase a replacement or the use of critical spares in non-critical locations. It should also include interchangeability with parts that require modification for use, such as motors that need an adaptor base. This field may contain a link to interchangeability details, including instructions, standards, drawings, etc. This is important maintenance information.

– size, weight and volume

– storage environment

– security requirements

and many more.

Understand the system before designing the database

Examples that resulted from a lack of understanding of system functionality include:

– purchasing additional stand-alone software for tracking critical repairable parts (such as paper machine rolls) because the system’s ability to manage repairable, serialized parts was not understood.

– entering inappropriate information, such as drawing numbers, in the “For this equipment” field in spare parts lists. This field should be used for describing how a spare part is used on a piece of equipment, e.g. for a pump impeller it could show “Trim to 15-1/2 in. and balance G2.5”.

– purchasing stand-alone scheduling software when the system includes a functional scheduling process that is not understood.

Use one system for managing all maintenance information

This includes work orders, the equipment location register, maintenance employee data and Stores data.

Ideally, it should also include all maintenance costs, including the cost of downtime for each equipment location. Many systems do not have this functionality, but it is important because the cost of production losses caused by an item of equipment may greatly exceed its maintenance cost (see “Measuring reliability“).

Make the system as “friendly” as possible

Imagine yourself searching for a book on a computer terminal in a public library. If the desktop is covered with icons such as “Oracle”, “Hermes”, and so on, would you know that “Lucidea” was the library management system where you start a search for a book?

The same applies to the people who depend on you for maintenance service in your operation, including temporary employees. So instead of showing “SAP”, “Maximo” etc on the desktop, show “Request maintenance work” or something equally easy to understand.

For more on this, see “Make your maintenance software user-friendly“.

The better systems can be configured to suit your needs, whatever they are, and are very capable of hiding or displaying selected fields, setting field sizes, modifying screen displays and many other possibilities. This is a mixed blessing, because there are so many options that you need to put a lot of thought into what it is you really want the system to do for you before it can be properly configured. This is a critical part of the system implementation process and it is at this stage that most mistakes are made and opportunities missed. It is extremely important that your implementation team includes someone who can decide what your true maintenance needs are, in a very logical way, as well as someone who fully understands the system’s functionality.

This is a very brief look at just a few aspects of maintenance system implementation and there are many other possibilities to increase your system’s value. For more on this subject contact us.

Navigation