Work Orders – Make sense of maintenance, storeroom and purchasing reports

Private companies and public sector organizations spend significant sums of money and effort implementing Computerized Maintenance Management Systems (CMMS). The ultimate goal of these systems is to provide information to make important decisions about replacing equipment that is costing more to run than replace, or which maintenance repair and operations (MRO) spare parts should be marked as obsolete and removed from the storeroom. The reality is often that the systems fail to provide the needed information.

Typical implementations begin with collecting data from a previous CMMS (if applicable, for new installations this data must be created from scratch), such as work order types (emergency, inspection, preventative maintenance), work priority (that is, high, medium and low), or work order status (in planning, awaiting approval, completed.) failure codes specific to the equipment and organization. A team of representatives from various departments – maintenance, storeroom and purchasing – is usually assembled to make these decisions. After the data has been collected and decided upon, the next emphasis is bringing in existing data, such as equipment, parts, employees into the new program, via data conversion or import tools. Bringing in the data is labour and time intensive, as often it needs to be cleaned up before it can be brought into the new CMMS.

Configuration

Once the data is in the system, it is configured to meet the specific needs of the organization. This includes creating user groups and giving members of the group specific permissions to perform different tasks in the program, changing field labels to complement the names used in business operations and creating business processes for such tasks as creating emergency work orders, preventative and predictive maintenance and completing purchase orders.

Next, employees are trained and the system is rolled out, commonly referred to as “going live.” Work requests and work tickets are entered into the system, preventative maintenance work orders are generated and distributed to the maintenance staff and work orders generated based on equipment-based alerts (predictive maintenance) are created.

During this time, reporting requirements (data needed to be collected for reports) may be discussed but are often placed on the backburner, as the emphasis is on the massive data collection/decisions that are needed to set up the system. The company ends up with an expensive system that only tracks work requests and work orders but provides little or no information to make relevant decisions. This results in a lack of confidence in the newly implemented CMMS, frustration and the belief that the only way to solve this problem is to roll out a new CMMS, taking into consideration reporting requirements at the beginning of the process. Most organizations do not have the budget to implement a second CMMS, as the cost of buying software licenses from a second vendor is prohibitive, along with fees for professional services (including software configuration, end-user training and go-live support). In my role as a consultant, I have seen this scenario repeated over and over.

One proven solution is to determine the organization’s reporting requirements, examine the program’s setup to determine if that specific data is being collected and, finally, creating the reports. Most maintenance managers have difficulty enumerating a comprehensive list of reports they would like, along with reports requested by other departments, such as purchasing and stores. It is often beneficial to provide a list of commonly requested reports used by similar organizations – once the managers review this list, they can determine which ones are needed, and come up with their own reporting requirements.

Format of reports

The format of these reports and method of distribution also needs to be decided. Should the reports be generated from the program and converted into easy-to-decipher Microsoft charts and graphs? Should important data points be presented in the form of key performance indicators that convey company performance compared to a specific business metric?

Some examples of key performance indicators include:

• Percentage of emergency work compared to total work
• Percentage of preventive work orders not completed
• Percentage of open purchase orders compared to total purchase orders

Once the required reports have been determined, the next step would be to examine the software, screen by screen, to determine whether those data fields exist and are they currently being populated. This can be done in-house by a system administrator, someone familiar with the program or a third-party consultant. If the fields exist in the program and are being populated, the list of values available in each field should be reviewed to ensure the list is current and represents the data that the organization wishes to track.

Fill out all fields

The person or team reviewing the software should also determine, based on reporting requirements, if certain data fields should be required. If an organization is tracking reasons for failure, then the maintenance technician needs to fill this out on all work orders, or the state of the equipment won’t be accurately presented. The list of values should also include preventative and predictive maintenance, as not all jobs are the result of equipment failure.

Specific fields can also be protected as “read-only,” meaning that the program populates these fields automatically and it cannot be modified by end users. The date on a work request screen could be made read only, so that users are not allowed to change the date and indicate the request was entered before the actual date.

If reporting requirements ask for data fields that do not exist in the program, user defined fields can be used. Most software programs contain user-defined fields to be used for this purpose. These fields can be renamed and contain “yes” or “no’’ in the list of values. One of my clients asked the technicians to take photos of work needed to be done if this would assist in communicating the requirements of the job. If “yes” was selected, the maintenance planner would know to check the attached photo before scheduling the job. User-defined fields can also contain a list of values that the maintenance technician can choose from. One client needed the name of the contractor who performed work, if applicable. A complete list of the company’s contractors were listed as codes in the list of values for that user-defined field. The screens can also be customized if needed, however there are some significant disadvantages related to customization. Custom work is often very expensive and it may need to be redone every time there is a software upgrade. Keeping systems “vanilla” is the best option, if this is possible.

Following are examples of reports that are run very often, along with the data fields needed to run each report.

Work order history comprehensive

Summary of report – Detailed information for closed work orders, including the equipment number and description, labour and scheduling information, parts and comments for each work order.

Data fields needed – Equipment number and description, equipment downtime, reason for failure employee code, first and last name, regular, overtime and total hours worked part number and description, quantity used, work order type, scheduled start and finish dates, duration of work performed, priority, originator and close date.

Work order backlog

Summary of report – All overdue work orders, including preventative maintenance.

Data fields needed – Work order number, description, hours worked and hours remaining, and crew size

The work order backlog report shown above has been exported into Excel, which is an easy way to view reports.

Stock Movement

Summary of report – Inventory transactions, grouped by part or item number.

Data fields needed – Part number and description, warehouse, transaction quantity, type of transaction, issue to employee or charge to equipment/work order.

Stock movement report example.

Inventory Comprehensive

Summary of report – Provides basic part information, including type, manufacturer, unit cost, reorder information, location and quantity.

Data fields needed – part number and description, account codes, manufacturer, vendor(s), unit cost, unit of measure and purchase, warehouse location, date last counted and received, specifications.

Equipment report – full list

Summary of report – detailed equipment information, including manufacturer, spare parts, and safety notes.

Data fields needed – equipment number and description, serial and model number, location, manufacturer and vendor, purchase date and cost, spare parts needed to repair equipment- part number, description and quantity, service contract code, expiration date, time Remaining

Mean Time Between Failure (MTBF)

Summary of report – grouped by equipment type, this report includes the average time between equipment failure and Mean Time To Repair (MTTR), average time needed to repair the equipment. Preventative maintenance work orders included in the MTTR, not MTBF.

Data fields needed – Equipment number, description and type, reason for failure code and description, Number of work orders and completion dates between user specified range

(Note: MTBF is calculated from days from last failure divided by number of work orders. MTTR is calculated from days to repair divided by number of work orders.)

Companies that do not determine their reporting requirements from the CMMS at the very beginning of their software implementation don’t get the information they need via reports but can take the foregoing steps to rectify the situation to ensure that they receive all the necessary information needed.

Jennifer Ohl is a maintenance software consultant. As owner of Midwest Software Specialists, she provides training in inventory optimization, improving equipment performance and total productive maintenance. Reach her at 773-844-4831.

A version of this article ran in the June 2017 issue of Machinery and Equipment MRO.