Last Updated on November 19, 2022 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 also a sister product called IBM Control Desk which can be used by IT operations and provides a comprehensive suite of applications and functions, it uses the same base services layer as Maximo and 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 to be 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 Facilities 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.

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 also 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 and if the classification has attributes then these will then be displayed. Classification attributes can have defaults and the attributes can be made mandatory forcing the requester to enter additional information needed to more fully understand the request. 

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 current 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.

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 Address 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 a number of additional steps, some of these can be automated using a Maximo work flow 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 out 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.
• 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 particular 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. However, SLAs can be applied to other Maximo objects, for example an asset where the commitment type might be availability or reliability.

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 if and 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 of time, 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 is 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.