Last Updated on April 23, 2024 by maximosecrets

The Service Management functionality of Maximo was designed to support the IT Information Library (ITIL) v3 processes. The main application is the Service Request which is based on the Ticket object. There are Incident and Problem applications which are also ticket based, these are available as part of some Maximo add-on products, for example Health, Safety and Environment (HSE). There is another add-on Maximo IT (formerly known as IBM Control Desk) which is used by IT operations and provides a comprehensive suite of applications and functions, it has deeper functionality to support a service desk.

Ticket Template

The Ticket Template application allows an administrator to build a template for commonly requested Services or Incidents. For example, a new or departing employee, meeting room request, password reset, etc. The Ticket Template references a class of ticket (Service Request, Incident, Problem) and its status must be made Active before it can be used.

The fields on the Ticket Template are copied to the ticket record when the ticket template is applied to it. There are standard fields for Owner or Owner Group, Service Group and Service, Internal Priority, and a Vendor field which is used if the work is performed by an external provider. The Ticket Template can be classified, and the attributes of the classification form the Ticket Template Specification. The classification hierarchy allows an end user to be guided towards requesting the right type of service or identifying the type of incident and the specification is then used to capture additional details specific to that classification. For example, a meeting room request might ask for date, preferred start time, duration, and number of people.

The ticket template can contain multiple activities. For example, the meeting room request template might have activities for confirming the room, arranging any IT equipment, arranging refreshments and an activity for the pre-meeting check by the facilities team. Each activity has similar fields to that on the ticket template header and each activity can be classified, so that the activity for arranging refreshments might ask a set of questions with regards to teas, coffees, water, and catering arrangements. When the Service Request is approved the activities would be directed to each team using the Owner Group field, confirming the room to be carried out by the Service Desk team, arranging refreshment to be carried out by Catering, etc.

The Specification tab shows the attributes for both the ticket template and the ticket template activities. The standard Crossover Domain TKTEMPLATE is used for extending the fields that are copied from the ticket template when it is applied to a ticket. Impact and Urgency are standard fields, but they are not displayed. As an activity is a class of work order a Job Plan can be automatically applied to the activities when they are created as the ticket template is applied to the Service Request or Incident.

For Service Requests the classification will normally be used on a ticket template. When the classification hierarchy is built to support the Service Request Role Based Application then the ticket template will be applied if it matches the selected classification.

Create and View Service Request

The Create Service Request and View Service Requests applications will be found in the Self Service module under the Service Request menu, they are designed for Maximo users to be able to create a request with minimal training and then to follow the progress of that request.

On opening the Create Service Request application the Service Request is in insert mode and the Reported By, Phone and Email will be populated and taken from the profile of the person making the request. These fields can be modified, a change does not affect the person’s profile, to do this the user must go to Profile – Personal Information in the Maximo banner at the top of the screen. The Affected Person can also be entered if the user is making a request on behalf of another person.

The user enters a summary of the request and the details. The details field could contain a screen shot or other embedded image, the user can also attach one or more attachments, for example, photos. The user optionally enters the asset or location if known and a reported priority. 

The classification hierarchy should be searched to identify the type of request or incident and if the classification has attributes, then these will be displayed. Classification attributes can have defaults and the attributes can be made mandatory forcing the requester to enter additional information needed to understand the request more fully. 

If the Maximo product set includes the Linear Asset option, then a feature can be referenced, and linear measurements entered. The purpose here is to create a service request when there is a defect, for example, to indicate the position of a pothole on a road, to indicate that a part of the road needs to be resurfaced, or to indicate a stretch of road where litter picking, or tree clearance is needed. 

A ticket template can be automatically applied from the Quick Insert portlet on a user’s Start Center. This is particularly useful as it means that the Create Service Request application opens with the classification already found and when the service request is submitted it can be automatically routed to the right team. In this way the Create Service Request application can be used for multiple purposes, IT requests, facility requests, engineers reporting defects found on assets, etc.

The View Service Request application shows the Service Requests which the Maximo user has either raised themselves or has been raised on their behalf and which remain open. Other queries can be set to find other Service Requests that may have been raised for the user’s team. Fields are available for helping to filter the Service Requests. The View Service Request application will be mainly read-only for a user. The user can see some of the log notes that have been raised on the Service Request or subsequent records, they can see the status, attach additional documents, or raise a log note to request an update. If the user can resolve the Service Request, then they can apply a solution to it.

Role Based Applications

Service Receipts – This application can be used instead of the Create and View Service Request applications. There is also a mobile application which works offline. The user is guided to select from a set of categories and sub-categories (classifications), or to describe the request and then will be presented with a set of fields including a description of the request, contact person, location, asset, service address or other fields specific to the selected category, and this can include date fields. The Role Based Application provides location and asset drill down, you can indicate the service address by selecting the device’s GPS position, you can find assets using the map or by scanning a barcode, or QR code, and you can take a photo or video or select one from your device.

There is currently no support for linear assets.

Service Request

The Service Request application is the application that supports a service or help desk, a service request is a type of ticket. Maximo supports a centralised service desk; the tickets are created at the System level. Some functions will require the entry of a SiteA structural element of a Maximo database that is used for data separation. More before they can be applied, for example the action Apply SLA. Some of the fields will already be completed if the Self Service – Create Service Request application is being used or the system has been set to receive service requests via email and the Email Listener has been configured.

When a call is received by the Service Desk agent, they create a new service request and enter the requester’s details, the summary, and details of the request. On understanding the nature of the call, a suitable classification will be chosen or if this is a common request the action Apply Service Request Template is used, and a ticket template selected and applied. The selected or applied classification may have a set of additional attributes to be completed on the Specifications tab.

The location or asset where the service needs to be performed should be chosen. A Service AddressA Service Address is a postal address and/or a record that positions a point on a map. More may be automatically located, Maximo traverses up the asset and location hierarchies in the address location system until a service address is found. If the service address has been geospatially located, then it will show on the map tab. Sometimes the service request might involve multiple assets or locationsA physical place where assets exist and where work can be performed. More, for example, to clean the whiteboards in a set of conference rooms, each room being selected and added to the service request.

After the service request has been created and saved the service desk agent will then perform several additional steps, some of these can be automated using a Maximo workflow process.

• The internal priority is assessed this may be different from the reported priority.
• A Site is selected, normally this is the same as the site of the location or asset.
• The action Apply SLA is used. This will use the reported date to calculate one or more target dates reflecting the Contact, Response or Resolution commitments that have been made corresponding to the type of request, the priority, or other criteria, for example, the time of day.
• Ownership of the ticket will either be transferred to another party using the Select Owner action or the service desk agent may use the action Take Ownership so that they own the service request for the time being. Ownership can transfer between owner groups (a Person Group) and owners (a Person). An ownership history is retained to record the change of ownership over the life of the service request.
• The action Show Similar Tickets by default uses the classification to look for duplicate requests, if found the user can relate them. If this request or incident is being reported by multiple users, then a global issue may be declared on the originating request and then new requests related to the global issue. A change of status to the global issue can ripple through to those requests that are related to it.
• Email communications may be sent to the requester or other parties to keep them informed of progress or actions that they need to take. A service desk agent will also want to record a note in the work log so that others can easily take over the request. A log note can be marked as client viewable which will allow the requester to see this note on the Self Service – View Service Request application, or the Service Request Role Based Application.
• There are start and stop timer buttons that can record the amount of time being spent on each request by a service desk agent. This can help supervisors analyse requests to see what improvements can be made in the business to help reduce the impact on the service desk. This is useful when new services are introduced.

A service request by default does not have an activities table window although it is a simple change to provide this. In many cases, one or more work orders are created to fulfil the requirements of the service request. If the service request references multiple assets or locations then there is an option to determine how to create the work orders, for example you could create a set of child work orders one for each asset or location. There are business rules which help to synchronise the service request status from the change of work order status depending on which option has been chosen. The work orders created will be visible on the Related Records tab and it is from here that a user navigates to see the full history of the related work orders. Log notes created on a related work order will be visible on the originating service request. The full details of an activity will be visible within the Activities and Tasks application.

Service Level Agreements

A service level agreement (SLA) is a commitment to provide a service within an agreed specification that you define in the Service Level Agreements application. From a Maximo perspective SLAs are generally applied to classes of ticket (service request, incident, problem) or classes of work order (work order, activity, change, release) where the commitments are used to calculate target dates on those records. 

You measure an SLA commitment using an escalation. If, for example, an SLA has been applied to a service request and a response commitment has calculated a target start date then the escalation can notify users that a breach is imminent and again when a breach has occurred. An action might be applied to increment the priority when a breach has occurred. Escalations can be defined to monitor each commitment and each escalation can have multiple notification events and multiple actions to be performed.

There may be multiple SLAs and knowing which one to apply is part of a matching process. An SLA applies to a particular Maximo object, it may be associated with a branch of a classification hierarchy, particular assets, or locations or even a period, for example an SLA between 9-5 M-F may be different to that outside of core hours. The matching process can also consider other conditions that you define in a SQL where clause, for example to say that an SLA only applies if the priority is 1 – an emergency.

When you apply an SLA to a record Maximo searches the bank of SLAs related to the object of the record, e.g. SR (service request) and then compares each SLA record against the SR record to see if it matches the criteria defined on the SLA. There could be multiple SLAs that are a match, Maximo does allow multiple SLAs to be applied, but if only one can be applied then Maximo decides based on either a ranking factor or if it is a time-based SLA then on stringency, how soon the SLA would be in breach if it were applied. Having decided which SLA is a match and which to apply then if the SLA is time based the target dates on the SR record will be calculated.

The target dates to be calculated are based on the SLA commitment and the calculation calendar to use. For example, an SLA response commitment of 16 hours may calculate a date using a calendar that only counts core hours. For example, a SR reported at midday on Thursday might calculate a target start of midday Monday and not Saturday as that is outside of core hours. 

SLAs can be related to each other and if it is a vendor-based SLA then the SLA can be associated with vendor contracts.

Service Groups

There is a two-level hierarchy of commodity groups and commodity codes that are used in the inventory and purchasing applications. Service groups and codes use the same Commodities table and relate to services that are provided, procured or both provided and procured. 

Service groups and codes can be used in various places throughout Maximo including tickets and work orders, but it is only the service groups and codes that are marked as provided or both that can be selected, not those service groups and codes that are defined to be procured.

Service groups and codes provide an alternate way of defining the type of ticket or work order to a classification, although some clients use both. Service groups and codes can also be associated with locations, assets, configuration items, asset types, SLAs, and contracts. When used with tickets and work orders other records that match the same service group or service code can be related to the current ticket or work order.

A service group or service code can have an associated contact group (person group) or contact (person). This is normally used when the service is being procured and represents the buyer group or buyer.

Solutions and Search Solutions

A solution is a knowledge base document that is searchable. A solution can be applied to an incident, problem and with some configuration a service request. A solution has a descriptive symptom, cause, and resolution. A solution cannot be applied to a work order, a failure hierarchy (problem, cause, remedy) performs a similar function but is based on failure codes and not descriptive text. 

A solution can have a classification and the associated attributes form a solution specification when applied. 

The main driver behind solutions is to provide a self-help for requesters of services or reporters of incidents, there is a Search Solutions application available for this. In an IT world self-service searching for solutions to issues is common, but it can also be applied in an enterprise asset management world to provide guidance as to what might be needed when a defect is found. A solution may have associated documents.

Activities and Tasks

An activity is a record related to a class of ticket; a task is related to a class of work order. There is an application designed for Maximo users who only complete activities or tasks and are not concerned with the overall ticket or work order except that this provides context. The application covers both activities and tasks because a Maximo user may be the recipient of either and they would only want one application to use. 

Both Activities and Tasks are stored in the Workorder table and consequently have very similar characteristics. The main difference is that an activity can have a job plan applied or tasks created for it, this is not allowed if the record is already a task.

Activities and Tasks have similar functionality to tickets and work orders. 

• They have a status and ownership can be assigned or a Maximo user can take ownership. The status history and ownership history are maintained. 
• Activities and tasks can be classified, and a specification is created if the classification has attributes defined for it.
• Activities and tasks have target, schedule, actual and constraint dates.
• Activities and tasks can have labor, materials, services, and tools defined as part of a plan and then the actual records can be recorded as part of activity or work completion.
• An activity or task can be related to a location and/or asset. Multiple locations and assets can also be associated with both an activity and a task.
• Activities and tasks can have an associated service address and be located on a map.
• Activities and tasks can have associated notes (work log) and emails can be created from it (communication log)
• An SLA can be applied to both an activity and a task.
• Other classes of ticket or work order can be created from an activity or task and relationships can be created to link different types of records.

The main observation that will be made when entering the application is that there is no insert button, there is always a parent ticket or work order. When compared with a work order a user might struggle to find differences but a work order can have a safety plan applied, a work order can have assignments, a work order can be added to a work package or have a route applied both of which change the work order hierarchy.

Incidents and Problems

The Incidents and Problems applications are most likely to be found when the Health, Safety and Environment (HSE) add-on is installed. These are the original core applications and not the extended Incident (HSE) and Investigations (HSE) applications which use the same ticket-based object but are focused on other types of processes. It might be that if a user already has access to Service Desk applications, then the use of Incidents and Problems become available to be used without increasing the number of required AppPoints.

The Service Requests, Incidents and Problems are three views on the TICKET object. They were designed to have a similar set of functions but in three separate applications which could be enabled with their own workflow processes. They are designed to work together and for one record to create a follow-up on another record or on a work order. They provide a much greater degree of flexibility over just a service request and a work order. For example, the initial call out could be handled on an incident instead of a work order, and analysis of root cause carried out on a problem record, with the work order used to execute the work. The service management ITIL processes that follow through to Change and optionally Release have much to offer traditional enterprise asset management clients.

The Incidents and Problems applications have an Activities tab, making it much easier to work with activities. Incidents and Problems both have a Solution Details tab, making it easier to work with solutions. They have a Failure Reporting tab and in the Problems application you can declare the problem as a Known Error. If you take a defect, you will report it on a service request, send someone to investigate on an incident, hopefully to also bring any asset back into service, then either investigate the root cause on a Problem record, or fully rectify the issue on a work order. 

Note, you can report time on an incident and problem, but materials can only be reported on a child activity or a work order.