Joining Reports & Work orders

STATUS:UNDER WORK

Motivation

The main question NorfelloCMMS should answer as an Maintenance Managements system is: "What is the status of this asset and should we make some actions on it?" By automatically mining collected data, the software will be helping making the decisions. If the software could rapidly give the user a set os conclusions the users limited time would be targeted to right areas. Therefore it is essential to collect information that could be analyzed by computer easily.

Problem

As we wish to create domain independent tool it is quite often immosible to hard code anything specific about the information the software collects. We have extreamly flexible tools for reporting and lots of things could be customized by an end user. However this is a two-sided sword. On the other hand the software could be customized to meets specific needs of some domain, but on the other many tasks could become more difficult.

Approach

In most of the cases by splitting one big task to a many smaller ones, the tools built to solve a small tasks could remain ideal. The same approach works with the information too. By tagging the common denominator of information we are doing the same thing to the information. Making the conclusion should be possible with the tags.

Result

Work order (tagged: Repair) belongs to Report (tagged: Failure report) and one Report (tagged: Condition check)

It is now easy to make conclusion:

1. Something has been not fully functional (Failure report caused)
2. Some repairing actions have been done (Work order, repair caused)
3. The condition of asset has been changed because of the repair actions (Condition check report caused)

Conclusion

http://cmms.norfello.com/cmms/attachment/wiki/ReportWoPlan/report2wo2report.png?format=raw In a conclusion we should have predefined report categories and work order types or predefined tags to attach to report categories and work order types. Reports should have column in the database (if they have work order).

Tags and their causal chains

Ok, were are going to tag information. How the tags are chosen is going to define what kind of information we can get out from assets data and therefore how usefull the tagging system is. At the moment there are the following tag chains:

• "Failure report" -> "Repair work order" -> "Condition report".
• "Maintenance work order" -> "Maintenance report".

Please add your tag suggestions below:

Determining assets condition - Mining data

Now we have chosen some main tags, which constitute causal chains, for data types. Next we need to decide how we are going to determine assets condition, i.e. what are the criteria for assets condition. Below are few:

Failure-repair-condition chain

• If there are "Failure reports", which have not lead to creation of "Repair work orders", then the asset as is considered broken and it needs users immediate attention.
• If there are "Failure reports", which have lead to "Repair work orders", then the state of the work order(s) tells us about assets condition:
  • If the work order is not assigned or accepted then the asset needs immediate attention from an overseing or repairing user.
  • If the work order is assigned to the current user or accepted by the user then the user should be notified from it directed to the work order.
  • If the work order is closed then the failure is considered fixed and the asset should be functional.
• If a closed "Repair work order" has not lead to creation of "Condition report" then the asset is functional but its current condition is unknown and the user is notified from need to check assets condition.
• If all "Failure reports" have lead to "Repair work orders" which are closed and "Condition reports" has been created from them, then the asset is considered functional and its condition known.

Maintenance chain

• If there are new "Maintenance work orders" they need to be assigned or accepted.
• If there are assigned or accepted "Maintenance work orders" the asset is scheduled for maintenance.

Maintenance-time-interval of asset type

In order to define does an asset need maintenance, when there are no "Failure reports" or open work orders in the asset, we should add user supplied maintenance-time-interval attribute to asset types. This would the system better adaptable to assets with different maintenance needs. Maintenance-time-interval should approximately be the time interval between successive maintenance operations ("Maintenance work orders and reports"). Users should try to provide maintenance-time-interval as acurate as it is possible and sensible and preferable round down the maintenance-time-interval (if it is say 1.5 months, user should provide interval 1 month rather than 2 months) It could be used to estimate wether an asset needs maintenance. For example:

• If the maintenance on an asset was longer than the maintenance-time-interval ago, then the asset propably needs maintenance in the near future.
• If the time span between past maintenances has been significantly longer than the maintenance-time-interval, then maintenance of this asset might have negleted in the past, which of course is alarming.
• If the asset has been maintained recently compared to maintenance-time-interval and the asset has been regularly maintained in the past, then the asset is in good condition.

When data in the system accumulates we propably want to determine the maintenance-time-interval dynamically from assets reports and work orders (e.g. ~ avarage time span between maitenance work orders and maintenance reports). Even then we will need the user supplied maintenance-time-interval as an initial and/or fallback value (e.g. when there isn't enough data or calculated value is clearly invalid).

Maintenance-time-interval would also be used to choose the time span when assets past maintenances are examined and to define what is recent for an asset. I believe type specific maintenance-time-interval is accurate enough, especially if it is completed with dynamic maintenance-time-interval calculation.

It might also be a good idea to add created_at attribute to assets, so that we know how far back we can expect to find data in each asset. For example when an asset is new and there is no maintenance reports, then without creation time we can't know wether it is time for a maintenance or not.

Summary

Based on description above we have the following cases to monitor:

Failure -> Repair -> Condition:

• New failure report (unhandled).
• New repair work.
• Assigned/accepted repair work.
• Repair work done, condition unknown.
• Failure repaired, condition known (few last maintenance-time-intervals shown).

Maintenance:

• New maintenance work.
• Assigned/accepted maintenance work.
• Maintenance work done, condition unknown.
• Maintenance performed (these are generally not shown to user).

Maintenance need estimation (e.g six last maintenance-time-intervals examined):

• Maintenance immediately/shortly needed (last one at least two maintenance-time-intervals ago).
• Maintenance needed (last one at least maintenance-time-interval ago).
• Too long and/or irregular maintenance time intervals in the past.
• Regular maintenance time intervals in the past.
• Maintenance recently performed (during last maintenance-time-interval).

Presentation - User interface

How this information is presented is essentially important. Generally I think we should (one way or other) present absolute numbers of above cases, not statistics (percentages) as in "Executive overview". Presentation could be combination of color codes (e.g. red is bad, green is good and yellow something between the two), text and numbers and links to relevant reports and work orders (or links to views with links to relevant reports and work orders). I doubt that diagrams would help to illustrate this kind of information.

For example we could have a red text "Two new failures reported", which would be a link view containing short overview about the failures and links to relevant reports and work orders.

Future steps

• When NorfelloCMMS has report & WO joining and tagging the information should be used in asset/view.
• Fake user interface picture should be added ASAP to this page