Good morning and welcome to Maximo Bite Size, a podcast on the functionality of Maximo Manage. Today is the eleventh episode in the series on Service Management, and today we will look at the Incidents and Problems applications and how they differ from Service Requests.
The three Ticket based applications Service Requests, Incidents and Problems are based on database views of the TICKET table and were designed to work together using common code that works against the TICKET object. You’ll find some differences in the common code, for example, each has its own domain set of statuses, but in general, you’ll find that the additional functionality which is on the Incidents and Problems applications will also work on the Service Requests application if it is transferred across.
The Incidents and Problems applications won’t be found unless you install the Health, Safety and Environment Manager (HSE) add-on. They are the applications found in the Service Desk module, they are the applications without the (HSE) suffix in the application name, the applications were originally developed as part of Maximo 6 (MXES).
These two applications were once sold as an add-on called Corrective Actions and Preventive Actions, together known as CAPA, and were bundled in with the Life Sciences Industry Solution. The Incidents application provides the Corrective Actions, and the Problems application provides the Preventive Actions. Both products have ceased to exist, because the functionality has been included in core Maximo Manage and HSE.
Incidents
The Incidents application has three main differences when compared with the Service Requests application.
The Activities tab allows multiple activities to be associated with the Incident. Each activity is like a cut-down version of a work order, it isn’t a task, because a job plan can be applied to an activity and the activity can have multiple tasks, a cut-down work order is therefore a better description. If you want to resolve the Incident without creating work orders, then this can be achieved using activities. The Activities table window has two inline buttons for Select Owner and Change Activity Status.
Activities are great if there are multiple actions that need to be carried out by multiple teams or people, think of an investigation into something. If the Activities tab is added to a Service Request, then this can be used for the initial investigation into an emergency or urgent event before you create the work order. The Activities tab is where the Time Tracking table will be found, on Service Requests it is at the bottom of the main tab. There is a hidden YORN field HASACTIVITY which is populated when an Incident has activities.
The Solution Details tab allows you to enter Symptom, Cause and Resolution of the Incident, three long description fields each with the rich text formatting toolbar. You can then create a Solution from this using the Create Solution action, the solution will be at DRAFT status. Alternatively, you can apply an existing active Solution to the Incident and the text for the Symptom, Cause and Resolution is copied from the solution. Think of a Solution as a knowledge base document, a solution can have a specification to help users find the right solution, and attachments, which can be viewed at the bottom of the Solution Details tab. There is also a Search Solutions action which the Service Requests application does not have. There is a hidden YORN field HASSOLUTION which is populated when an Incident has a solution.
The Failure Reporting tab will look familiar as it has the same layout as found on the Work Order Tracking application, the Failure ClassA Failure Class is the top-level Failure Code of a Failure Hierarchy. More will be copied from the asset or locationA physical place where assets exist and where work can be performed. More and then you can enter the Problem, Cause and Remedy codes. The INCIDENT record has a few hidden fields, PROBLEMCODE, FR1CODE and FR2CODE, that store the Problem, Cause and Remedy making it easier to create KPIs or reports without doing complicated subqueries to the FAILUREREPORT table.
Apart from these three quite big differences between the Service Requests and Incidents applications, the others are subtle and some would only be found if you dived around Database Configuration.
- Duplicate – When duplicating an Incident, if there are no activities the Incident is just duplicated, however, if there are activities a dialog appears asking whether you wish to duplicate the Incident or the Incident and its Activities.
- Inherit Status – The INHERITSTATUS field defaults to 0, it will not inherit its status from changes to a follow-up Problem or Work Order. For Service Requests this field defaults to 1.
- SiteA structural element of a Maximo database that is used for data separation. More Visit – The SITEVISIT check box can be added to the main tab, this is more likely to be used on an Incident if you will use an activity to request someone to make the visit.
- Impact and Urgency are other hidden fields which might be used more on an Incident than a Service Request especially after an investigation has been performed. There is no matrix between these fields to derive the Internal Priority, but a script or formula could be added.
Problems
You would find it hard to find a difference between the Problems application and Incidents application. There is one check box – Is Known Error on the main tab just above the Dates section. There is also a hidden field ISKNOWNERRORDATE which is populated when the Is Known Error attribute is checked.
If you report a Maximo Support case you may be issued with an APAR, this is a Known Error, a fix may not be available yet. The use of the Is Known Error flag would then be used when the Problem has a Solution, but the Change or Work Order that will permanently address the problem has not yet been completed. When completed the Problem status would be set to Resolved, but the Is Known Error flag is not removed as the field is used to create the Known Error Database (KEDB).
Apart from that everything is the same although several of the synonym domains are different allowing you to set up different values to those you might use on the Incident.
So why are there two applications? The Incidents application is used to record an event or non-conformity and the activities needed to return the asset, location or configuration item back to service, a reactive process. A Problem is used to investigate the root cause of one or more similar incidents and to initiate the change or work order that will provide a permanent solution to eliminate or reduce the frequency of those incidents. The Problems application can also be used in a proactive sense to review the cause of potential events or non-conformity; the proactive side of Problem Management is associated with the Service Management process of Continual Service Improvement.
I hope you enjoyed this podcast and I look forward to seeing you back on the next episode when we will look at the Self Service – Service Requests application.
The music is called Duck in the Alley from the talented group called TrackTribe, please check them out on TrackTribe.com, all one word.
Until another time, goodbye.
Links
Incidents and Problems – https://maximosecrets.com/2021/11/19/incidents-and-problems/