Last Updated on November 19, 2022 by maximosecrets
This is the start of a series of articles discussing various aspects of the Service Requests application. In this article we will first provide a bit of context around what a Service Request is and why it should be used. We will follow up with describing the creation of a new Service Request in the application.
Why use a Service Request?
A Service Request is a type of ticket in Maximo and the application is used by clients as a Service Desk or Help Desk. Many years ago, it replaced the Work Request application in Maximo and naturally Service Requests (SR) flow through to work orders.
But why should you use a Service Request over a Work Order at Waiting to be Approved (WAPPR) state? When you break down what a service request is used for, it might be a request, but it could be an issue, defect, incident, observation, etc. Some of these may never materialise as a work order that needs to be approved, planned, and executed. Some of these may eventually become work orders, but they can’t be justified to be performed alone, they effectively need to be put on hold and grouped with other potential work. If this volume of records were created as work orders, it makes it difficult to see the work that should be processed from that which doesn’t, and consequently work which should be performed in the near future can easily be lost. So, think of the Service Request application as the funnel of potential work and the Work Order Tracking application as the work that really should be done, this will provide a better reflection of the work backlog and stop so many work order records from being cancelled.
The other big reason for using a service request is when you consider service management, your responses to your customers whether they be internal or external. Multiple people could raise a Service Request for the same issue, incident, etc. These should be related together, and all requesters informed of progress equally. In the old world of work requests, only one work order would flow through to being approved, all others would be cancelled, the requesters were not treated equally and as a requester it was not possible to follow the progress of the issues I had raised. The Service Request then becomes the first steppingstone in introducing service management.
Service Requests
The Service Request application is at the System level and can be easily used as a central service desk for multiple sites. The application is based on the SR object which is a database view on the TICKET table where the CLASS=’SR’. The Incident and Problem applications are based on different views of the TICKET table.
The three applications share business functionality that is written against the Ticket object. This was a core design principle, all three applications needed to work in the same way, but with additional functionality for Incidents and Problems. When you create an Incident from a Service Request Maximo is effectively duplicating the SR record and changing the class.
The functionality behind the three ticket based applications is similar to the work order based applications which also have a class and are based on database views, Change (WOCHANGE), Release (WORELEASE) and for Activities and Tasks the view is WOACTIVITY. A slight difference is that the Work Order Tracking application allows you to see all classes of records in the WORKORDER table, whereas there is no application that looks at all classes of records in the TICKET table. There is, however, the Work View application which looks across all tickets and work order based records and allows you to navigate to the relevant application.
There is functionality on tickets and work order applications which work identically, and we will only discuss these in the articles on Service Management, with a brief reference when Work Management is discussed. Some of the functionality between Tickets and Work Orders is intertwined and it only makes sense to discuss this together.
When a new SR is created in the Service Requests application the Service Request number uses the autokey and the status is set to NEW. The Address Information will be skipped by many clients or repositioned lower in the main screen. For a Service Desk user, the first thing is to verify the caller in the User Information section.
There are two columns of fields the Reported By and Affected Person, each has a Person reference, Name, Phone and E-mail address. The Affected Person is defaulted from the Reported By field. The top field in each column is a person that can be found in the People application. As a Service Desk user, you can type straight into the Name field in the Reported By column and Maximo will look up a person if it exists and fill in the Reported By field. If the name does not exist, you can process the SR with only the name. If you enter the first name, or the family name preceded with a % sign, which is a wildcard, then the Select Value can be used to narrow a search for the person.
The Phone and E-mail fields are the primary records for the person, Maximo allows multiple phone numbers or email addresses to be referenced for each person, only one of which can be the primary. You can modify the phone and email after they have been defaulted. If the person reporting the SR is not listed in Maximo, then the phone and email fields are free text but not mandatory, although many Maximo clients will make them mandatory through configuration.
Incidentally, the Self-Service View Service Request application uses the Affected Person field to filter the records for the logged in user and not the Reported Person.
After picking up the details of the person who is calling (Reported By) and whether they are making the call on behalf of another person (Affected By) then you are likely to be capturing the reason for the call in the Details field in the Service Request Details section. This is the long description of the SR Description with a rich text formatting tool bar.
The next most likely field to complete is to ask the requester the urgency and to complete the Reported Priority, a value from 1 to 4 where 1 is Urgent and 4 is Low.
Ideally during the service desk call you would use the Classification or Class Description to search for the classification to apply as this may reveal additional questions in the Specifications tab that you may wish to ask the requester. The Classification field has a drilldown, but often performing a word-based search in the Class Description field will prove quicker.
The Location and Asset search fields will filter by the Affected Person as a User or Custodian which quickly narrows the search if your organisation has gone to the effort of associating locationsA physical place where assets exist and where work can be performed. More and assets with people using the Associate Users and Custodians action. Until this has been done you should configure the Filter By field to default to All, which you can do from the Database Configuration application and attribute ASSETFILTERBY setting the Default Value to !ALL!.
The other setting is Public which will find locations or assets with no user or custodian.
If you enter an Asset the Location field will be populated. If you enter a Location and the location has one asset it will be populated. If you are using Configuration Items which are used by IT departments and highly regulated environments for documents, software and other items under configuration and change control, then this field may be populated from the associated location or associated asset. The reverse is also true, if you enter the Configuration Item first the Asset or Location fields may be populated from the association you find in the Configuration Items application.
The population of the Location and/or Asset fields should have populated the Address Information fields allowing you to verify the address with the requester. The Address Information fields can be entered but if you later select a location or asset with a service address you will receive a warning message asking you to choose which to keep which is why positioning this section below the location and asset fields makes sense.
The Service Address can be derived. Maximo looks up the asset hierarchy and then the location hierarchy using the Address System until it finds an asset or location with a service address. The Service Address once copied and populated onto the Service Request can then be modified, the full set of address fields is found in the Service Address tab.
If there is no Service Address, you can use the lookup or navigate to the Service Address and create a new one, or if you believe the address will never be used again you can use the address fields on the Service Address tab. You can also find the address from the Map tab if this is configured, by searching and then zooming in until you find the exact position. A right click on the map will provide the Set Record Location option which when used will write the address to the Formatted Address field along with the Latitude/Longitude or Y/X coordinates.
The other fields in the main Service Request tab and particularly the Service Request Details section are probably completed after the call with the requester.
- The Summary field if it has not been set up to auto-populate from the chosen classification should be entered, the default width is 100 characters.
- The Internal Priority has the same four values as for the Reported Priority field, but it may be set to a different value, often higher and less urgent than that requested. There are two hidden fields Impact and Urgency which can be used with a configured formula to derive the Internal Priority through a matrix.
- The Service Group and Service fields is the high-level service being requested and it is important for service management that this is completed. The detail menu on these fields has an action of View Related Records for Service Group or View Related Records for Service which allows you to relate similar records.
- The SiteA structural element of a Maximo database that is used for data separation. More field is often the same as the Asset Site which is derived from the chosen location or asset. You will not be able to apply a Service Level Agreement until it has been completed.
For frequent requests, a Ticket Template can be created and applied using the Apply Service Request Template action, this copies the fields from the Ticket Template to the Service Request. The Ticket Template would typically copy the Summary, Internal Priority, Service Group, Service, and Classification fields. The Owner or Owner Group would also be populated but we’ll discuss that and many other features of the Service Request application in other articles.
Leave a Reply