Last Updated on December 28, 2022 by maximosecrets
The music is called Busy City from a group called TrackTribe.
Hello, and welcome back to Maximo Bite Size. A series of videos on the functional aspects of Maximo Manage.
Good morning, I’m Andrew Jeffery and this is the eleventh episode in the series on Asset Management. Today we’ll look at another asset feature that you won’t find with A physical place where assets exist and where work can be performed. – asset downtime.
Please subscribe to the Maximo Secrets channel so that you don’t miss out on new episodes as they are being published.
Asset Downtime can be reported on both the Assets application as well as on the work order based applications Work Order Tracking and Quick Reporting, and so we’ll cover both in this video. There are slight differences between how it works on assets versus work orders.
There are two aspects to Asset Downtime, the changing of the asset up/down status, and the reporting of downtime. We’ll see that the two do create the same records behind the scenes. There are some rules around how downtime hours are calculated, and we will be covering this.
Finally, we’ll discuss a few settings in the A structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More application that effect the work order based applications. So, let’s get started.
Assets – Report Downtime
Change Status – Assets
We are in the Assets application and the Report Downtime dialog and in the header section it is telling us that for asset 12100 a Forklift truck its ‘Is Running’ status is set to UP. Some call this the asset status but that can be a little confusing because there is a Status field that provides the lifecycle states of an asset, a subject which will be the focus for the thirteenth video in this Asset Management series. I call this field the UP/DOWN state or Is Running status because the attribute’s name is ISRUNNING.
In the Downtime Report section, you can choose whether to Change Status or Report Downtime, a radio button. Use the Change Status when you have been alerted to a change in asset state, use Report Downtime when you are recording downtime retrospectively, perhaps from the notes made on an operator’s clipboard. The default is to Change Status and on pressing OK it toggles to the opposite state, DOWN in this case. The Status Date, the date and time when the asset’s Is Running state was known to have changed, is defaulted to date/time now but it can be changed to an earlier date/time. It can also be set to a later time if you know the asset is due to be stopped at a specific time. As you change state you can enter a downtime code , supported by an ALN domain called DOWNCODE. We will select BRKDWN – Breakdown, other default values are Adjust, Minor Stop, Setup, but you will want to change this to suit your organisation.
In the Assets application at the bottom of the main tab, you’ll find a Downtime section showing the Asset Up status, now set to Down (0), the Status Date when this state was last changed and the Total Downtime hours, this is the accumulated hours over the life of the asset.
If you use the Report Downtime action again, you’ll find that the Is Running state will be toggled to Up (1) and the Downtime Code of BRKDWN – Breakdown is carried forward but can be changed if required.
Each change of the asset’s is running state is written as a record to the ASSETSTATUS object and table.
Report Downtime – Assets
The Report Downtime radio button allows you to report downtime after it has occurred. The Start Date and End Date will both default to date and time now, but they can be modified, if the Start Date is before the End Date. A Downtime Code can be selected.
When you press OK two transactions will be written to the ASSETSTATUS object/table. The Start Date is used to write a transaction when the asset went Down (0) and the End Date is used to write a transaction when the asset is moved to an Is Running status of Up (1).
The Hours field is read-only and is calculated if the asset has no calendar, or the asset has a calendar and shift, in which case the hours is the time between Start Date and End Date that is within the shift’s work periods, the operational hours of the asset. If the asset has a calendar and no shift Maximo assumes that the asset is not operational and will not calculate downtime hours. If you do use a calendar and shift to represent operational hours, and Operations decide to add extra time after a shift or at the weekend, then don’t forget to reflect this in the hours of the calendar by changing the work periods in the Calendars application.
Further down the dialog you see a Downtime Type of Operational or Non-Operational. This defaults to Operational on the Assets application. You use this setting if the downtime had an effect on production, for example, lost time, or lost units, otherwise mark it as non-operational. This is a manually set field and is not derived from the calendar and shift which determines operational hours, the two are not linked. If an asset goes down, downtime should be recorded for the asset, however, if there is a standby asset that kicks in automatically then there would be no lost time and hence you would mark this as non-operational. If a manual action is needed to connect the standby asset, then you may record two downtime records, one operational and the other non-operational.
When you define your Downtime Codes it is worth playing through some scenarios and determining what would be marked as Operational and Non-operational downtime, and how planned and unplanned downtime will be derived, there is no field in Maximo that indicates this.
The Manage Downtime History action in the Assets application allows you to see all the downtime records for the asset, whether made direct against the asset or via a work order. It is how you can verify the accumulated hours that is shown in the Total Downtime field on the Assets main tab. Most of the fields in this dialog can be modified including the Start Date and End Date but there are validations to ensure that you do not overlap the records.
Work Orders – Report Downtime
Report Downtime – Work Order
The Report Downtime and Manage Downtime History actions will be found in both the Work Order Tracking and Quick Report applications. The dialogs are like those found in the Assets application but not quite the same.
In the Report Downtime dialog, you have the same two radio buttons Change Status and Report Downtime. The visual difference is the Start Date Default section at the bottom which is only accessible when the Report Downtime radio button is active, for Change Status it will be greyed out. We’ll see in the next section that there are Organization application settings that define which radio button is the default.
The observant of you might notice that the Downtime Type defaults to Non-Operational on a work order, it was Operational on the Assets application. This is controlled from the Library.XML file.
When you choose Change Status then when you return to the Report Downtime action to bring the asset back to an Is Running state of Up there will be a few additional fields in the header of the dialog to indicate the work order, the Downtime Start date and time, Downtime Code and who originally reported that the asset was down.
The Report Downtime action functions in the same way as for the Assets application except when using the Report Downtime radio button, you can copy either the Reported Date or the Actual Start Date to the Start Date field using the radio button in the Start Date Default section. None simply blanks the Start Date. The Start Date defaults to the Reported Date and the End Date to date and time now, so often when the dialog opens, you’ll see the Hours already calculated.
There are settings in the Organizations application that can provide a warning when changing work order status to COMP – Completed, when the referenced asset is still marked as down. The same applies if you tried to change status to closed.
It may seem obvious but unless the work order has an asset you will not be able to use the Report Downtime or Manage Downtime History actions.
Manage Downtime History – Work Order
The Manage Downtime History action from the work order based applications is a little different from that in the Assets application as it only shows the downtime records for the work order.
The work order may have multiple periods of downtime. There might be a period of operational downtime and a period of non-operational downtime. There might be a period when a temporary fix was put in place, and another period when a part was replaced to create a permanent fix, if that was all performed on the same work order.
The work order used to report the asset was down, need not be the same work order which reported the asset as now up. It is the details area of the Manage Downtime History action which helps to show that each downtime record is, in fact, made up from two transactions from the ASSETSTATUS object/table.
One final thought, do you use the work order applications or the Assets application to record downtime? If Maintenance is involved, then I would use a work order so that it is tied to other useful information like labor hours, parts used and the failure report. For operator initiated downtime, for example a minor stop, or tooling changes, use the Assets application to record downtime.
In the Organizations application, Work Order Options and Work Type action the dialog allows you to set whether to provide a Downtime Prompt for the work type when you attempt to complete or close a work order and the asset is still marked as down. The prompt is in the form of a message ‘BMXAA4546E – The asset currently has a status of Down. To change the status of the asset now, you must cancel the current status change and report downtime.’.
You would be returned to the Change Status action, but there is nothing stopping you from completing the status change and then using the Report Downtime action afterwards.
In the Work Order Options – Other Organization Options action the dialog has two settings that effect Downtime Reporting. The field ‘Display Downtime Report Prompt upon WO Completion for asset in a ‘Down’ Status?’ provides the same error message as we have just seen when changing status to completed or closed. Making this setting saves having to make the same change for each work type, it also works when the work type is null.
The Default Downtime Start provides the default to the Report Downtime dialog in the work order based applications and sets how the Start Date is derived when the Report Downtime radio button is used.
There is a System Property that you should also be aware of, called mxe.asset.assetInUserTimeZone. When the asset has a calendar and shift defined it uses the Start Date and End Date to derive the downtime hours, and by default, when the property is set to zero, it uses the server’s time zone to make this calculation. You should set the property to one if you work across multiple time zones so that it uses the time zone of the user who reports downtime to make the calculation.
Thank you for watching
I hope you have enjoyed this episode on Asset Downtime and thank you for watching. Next up in this series on Asset Management we’ll be reviewing Failure Codes and Failure Reporting. You can receive notifications if you Subscribe to this channel, which of course we hope you will do. If you enjoyed this video, please also give it a thumbs up.
The music is called Busy City from the talented group called TrackTribe, please check them out on TrackTribe.Com, all one word.
Until another time, Goodbye.