Last Updated on November 19, 2022 by maximosecrets
In the ticket-based applications it is good practise of Service Management to record who is taking responsibility whether a person or a team, we call this Ticket Ownership. For analysis of some aspects of Service Management the recording of time taken can be a useful metric, this can be achieved simply with a few clicks.
When a Service Request, Incident or Problem has just been received, it needs to be assigned to a team or someone needs to take responsibility for it. There are two read-only fields at the top of each application Owner and Owner Group and they also appear on the List tab.
There are two actions. The Take Ownership action makes the logged in user the Owner of the ticket. The Select Owner action allows you to select a Person or Person Group to become the Owner or Owner Group. The two fields are mutually exclusive, only one may have a value at any one time. An Ownership History is tracked and is found as part of the action View History.
There are in fact three attributes OWNER, OWNERGROUP and ASSIGNEDOWNERGROUP. The last of these is not displayed in the Maximo user interface but is set behind the scenes as the Person Group of the Person who is made the Owner. It tells you the team that is owning the ticket when the screen shows the individual who is taking responsibility, the owner.
When you use the Select Owner action there are two tabs Person and Person Group. On the Persons tab unless there is a filter by Person Group then a Person may appear multiple times if they belong to multiple Person Groups. The row which is selected will populate the OWNER field and the ASSIGNEDOWNERGROUP will be set to the Person Group for the row selected.
If the status is NEW the status is advanced to QUEUED when an Owner or Owner Group is first assigned. It will change to QUEUED from other statuses as well, hence normal practise is to set ownership at NEW status.
If the Take Ownership is the first of the two ownership actions to be used the ASSIGNEDOWNERGROUP is not set. If the Select Owner action is the first to be used and an Owner Group is selected, then behind the scenes the ASSIGNEDOWNERGROUP is also set. Now if a user uses the Take Ownership action, then ASSIGNEDOWNERGROUP remains set, including if the Person who took ownership is not a member of the Person Group that is the Assigned Owner Group.
When you use the Select Owner action the Owner Group field will be populated if the ticket currently has an Owner Group, and the table window will show the Persons that belong to that Person Group including anyone in the table window ‘Alternates for’ that you find in the Person Group application. The table window also shows the person’s shift and a number for Open Work. This is the number of tickets and work orders of all classes that the owner has been assigned, it excludes tickets and work orders at RESOLVED or COMP status or their synonyms and any records that have entered history. There is only one place to verify this and that is on the Work View application which you can find in the Administration module.
The Select Owner dialog also has a Date field and a Refresh button, this determines who in the Person Group is available. It is using the calendar/shift of the team members. If a person is a member of a team but they do not appear when using this, then you need to check the Person has a Calendar and Shift and that the End Date of the calendar is not in the past and that the shift has been applied to cover the date chosen. Then try changing the time element of the Date field to make sure that it is within the time of the shift on that day.
There is an Organizations application action that is used by this dialog, it is called Ownership Assignment Options. This is a Site based setting with two options ‘Do not check Person Availability’ and ‘Check Person Availability’. The default is set not to check Person Availability. However, if you do have this set to check availability and the person is on holiday or other non-working time as of the date and time shown in the Select Owner dialog then they will no longer be displayed as being available.
There are two actions Start Timer and Stop Timer that can be used to record the amount of time spent on each ticket. For this to work you will need a Labor record associated with the Person record of the logged in user. The time record is also being written to the LABTRANS object which is a Site based object. If the Site field is not already set on the ticket, then it will be set to the Default Site of the logged-in user.
When the Start Timer action is used a Time Tracking record is created with a Start Date/Time but no End Date/Time or Regular Hours. The Craft is the Default Craft of the user’s Labor record. When the Stop Timer action is used a Confirm Timer dialog opens where you can adjust the start and end date and times. The Hours are calculated as the difference between the Start Time and Finish Time. You can ignore the Complete Work Order field as this is a common dialog that can also appear on the Activities and Tasks application. It doesn’t exist in the Work Order Tracking or Quick Reporting applications.
When looking at the Time Tracking record at the bottom of the Service Requests main tab the Type field will default to WORK but it could be set to TRAV (travel) or WMATL (Waiting for Materials). There is a supporting Synonym Domain called LTTYPE, Labor Time Type. After the normal hours have been calculated and saved then the Maximo default setting for Internal Labor is to automatically approve the labor time, in which case the whole record becomes read-only and cannot be modified.
The Confirm Timer dialog is based on a non-persistent object CONFIRMLABTRANS that doesn’t allow you to say whether the time is normal time or overtime. If the period of time overlaps into an overtime period, then in the Confirm Timer dialog modify the Finish Time attribute at the end of normal time and then use the New Row button on the Time Tracking table to add in the overtime period. If the whole period is outside of normal time, then do not use the Start/Stop Timer actions but use the New Row button as after entering the Premium Pay Code you can set the Regular Hours to zero and add Premium Pay Hours instead.
If you manually complete the time record from the Time Tracking table, the timer will have been stopped. You cannot record time in the future, for example time now is 15:40 on a Friday and we finish at 16:00, you would not be able to enter 16:00. There is a setting in the Organizations application and Labor Options action called ‘Future Labor Transaction Tolerance in Hours’ where the number of hours or minutes that you set determines how far advanced of time now a user can enter their time.
The View Costs action will show the total of labor hours and costs and any labor, material, service, and tool costs that are on associated activities.
For recording time against a ticket’s activities, you can do this manually from the Activities tab on the Incidents and Problems applications, to use the Start Timer and Stop Timer buttons you would need to navigate to the Activities and Tasks application. The activity must have at least reached the status of APPR (Approved) to record time, this is different to a ticket where time could be recorded against a Service Request which is still at NEW status.
If you are using the Activities and Tasks application, you might find that the status is automatically set to INPRG (In Progress) or COMP (Complete) depending on the settings in the Organizations application and System Settings action under the Timer section.