Analysing behavioral patterns in your IT organization

A unique benefit of the PETE for JSM app is its ability to analyze behavioral patterns in your ITSM processes and recommend corrective measures. And don’t worry—PETE handles both the analysis and the suggestions for you!

One key feature on the PETE Dashboard is ‘Process Pitfalls,’ which highlights behavioral patterns that can be improved. The percentage shown represents the portion of issues in your JSM instance with patterns that PETE has identified as improvable.

Use the global filters to focus on specific projects or apply any other filters you’d like to view.

A lower percentage in ‘Process Pitfalls’ indicates that your organization has healthy behavioral patterns, while higher percentages suggest areas where improvement can be made. This can prompt a drill-down to better understand the specific Process Pitfalls.

Process Pitfalls are categorized into common behavioral patterns observed in IT organizations. For example, when issues are set to ‘Pending’ status right after being assigned to a Team or Expert, PETE refers to this behavior as a ‘Yoga Break.’

Clicking on ‘Yoga Break’ will reveal all the different paths incidents in your organization have taken that display this behavioral pattern. The Activity Map shows the path each incident followed. Every unique path is called a Process Variant, and PETE assigns a unique ID to each one, shown in the Variant ID column.

You can quickly assess the impact of a process variant by checking the ‘% of Total’ column, which shows the percentage of total issues that follow this specific variant. Additionally, the ‘Preventable Cost’ column provides an indicative monetary benefit that could be gained by addressing this inefficiency.

Definition of every process variant is provided below:

Process Pitfall	Description	Supported Processes
Yoga Break	When the issue status is set to ‘Pending’ immediately after assigning a Team or Expert.	INCIDENT REQUEST PROBLEM
Miraculous Healing	When an issue status moves directly to ‘Resolved’ after creation without any work being done.	INCIDENT REQUEST PROBLEMCHANGE
Boomerang	When an issue is reopened after being marked as resolved.	INCIDENT
Hot Potato	When an issue is reassigned from one Team or Expert to another without any work being done.	INCIDENT CHANGE PROBLEM
Ping Pong	When an issue is repeatedly assigned back and forth between two Teams or Experts.	INCIDENT CHANGE PROBLEM
Procrastination	When an issue status moves from ‘Pending’ to ‘Pending’ without any progress.	INCIDENT REQUEST PROBLEM
Labyrinth	When an issue undergoes numerous state changes.	INCIDENT REQUEST
Shit In Shit Out	When an issue starts with no information and goes through numerous state changes.	INCIDENT REQUEST
Marathon	When issue durations are excessively long.	INCIDENT REQUEST PROBLEM
Cold Case	When no root cause identified and issue closed.	CHANGE PROBLEM
Comeback	When issue is reopened after a excessively long time.	REQUEST PROBLEM
Ghost Entry	When issue is assigned to a team or expert, but never worked on and cancelled eventually.	REQUEST PROBLEM
Head in the Sand	When the issue was not successfull and no post implementation review was made.	CHANGE
Headless Chicken	Planned start and end dates of the issue are very differerent to the actual start and end dates.	CHANGE
In the Fog	When issue review preparation takes excessively long.	CHANGE
Last Minute Junkie	When the issue is created very shortly before the CAB approval was given.	CHANGE
Not My Cup of Tea	When the issue is assigned to another Team or Expert.	CHANGE
Paper Pusher	When issue took to many approval attempts.	REQUEST
Slacker	When there are too few updates to the issue status	CHANGE
Sleepy Joe	When issue approval durations are excessively long.	REQUEST CHANGE
The Unfinished	When issue is worked on but never fullfilled the request.	REQUEST
Treading Water	When the issue is approved but cancelled afterwords.	CHANGE
Wrong Call	When known error analysis was was done multiple times.	PROBLEM