CA Service Management

Linking this to existing "idea" thread:  Total time spent in each status

Looking for more information on reporting on KPI data - If I'm understanding the below information correctly, it allows you to report on how long a ticket was in a various state (ie; Status is one of them, as well as Service Type) ---

Retrieve Ticket Data

To allow reporting on how long tickets remain in the various processing states, you can configure the KPI daemon to retrieve CA SDM ticket data whenever a ticket is opened or closed, and whenever any of the following fields values are changed:

• Active 
• Assignee 
• Area or Category 
• Group 
• Impact 
• Organization 
• Priority 
• Root Cause 
• Status 
• Service Type

To enable ticket retrieval, install the KPI Ticket Data Table option available in Options Manager KPI folder.

The collection of data from new and updated tickets is enabled. The ticket data is written into the usp_kpi_ticket_data database table, and is available for generating web-based reports.

So before I even venture down the path to install the KPI option and see how we can report on this, I have 2 questions: 

1)  We've been told that the only 'duration calculation' that is available in BOXI is the duration from 'ticket opened' to 'ticket resolved'.  If that's true, then how would you calculate the duration that a ticket was in each status?  Does the KPI data actually have the status durations already there?

2)  Does anyone know exactly what information regarding the 'Service Type' is available in the KPI data?  Can you report on the duration where the SLA clock was running on a ticket -- (excluding the times it wasn't running) ?

Turning on the KPI daemon is relatively painless (outside of a restart) and we have noticed no performance hit in the 2 years since enabling it.   All of the data collected here can be reported on with the objects in the Key Performance Indicator/Kpi Ticket Data class. 

There is so much valuable information captured here that typically requires manually sifting through Activity logs to investigate what really happened.  An investigation can trigger running a report against this data to find out trends or behaviors such as what types of records are being transferred back and forth between groups, what is the scale of the problem and which groups participate?  What type of records are typically escalated (or “de-escalated”) what is the scale of the problem and which groups participate?  Who/ where/why is changing these fields frequently etc.

1)The data collected for Status looks like this:

We have collected about 250K records for status changes in 2 years.

2) the only options for “Field Name” which map to the list you posted are:

Active

Assignee

Category

Group

Impact

Organization

Priority

Rootcause

Status

support_lev

template_name

and the data for support_lev looks like:

So looks like the KPI daemon only records where the service type changes (for us that is only when the priority of a record is changed which has a different service type attached). 

If there is a way to gather when the SLA timer was running or not as originally asked I would love to know as well!

Hope this helps some! – fred SDM12.7 CABI 3.2 (SP5)

Yes, that helps a lot, Fred -- thank you! 

It looks like it's capturing the duration for each status change.  So for example, if a ticket was moved to "Work in Progress" multiple times, you'd need to add up the durations associated when the "Next Value" is "Work in Progress" to show the total time it was in that status.  Hmm... Ok, that seems worth trying...

And for the service type, if the 'previous time' and 'end time' of the service type shows when it starts and stops, then I guess that might show when the SLA clock WAS running on the ticket -- right?

Tammy

Hi Tammy,

For me the service type duration is only the duration before the service type was changed (to a different service type\different priority).  I have not found out/if how the KPI daemon's default collected data measures when the clock stops and starts.  I have looked for it by locating an Incident where I know the clock was paused by both the assignee setting the Incident to a status that delays service type events and a time (where service type’s workshift delays events) and there were no records in the KPI ticket Data table.   -fred

*** there were no records in the in the KPI ticket Data table with regards to status type (Field Name = support_lev).  So I'm leaning towards the conclusion that the answer to #2 in the original post is that the OOTB data collected by the KPI daemon does not measure when the Service Type clock stops and starts. 

Ahh.. I see that now, that it's only showing when it stops and starts when the priority has been changed.  That's a shame that it doesn't show all start/stop times!

Thanks Fred!

Hi All,

Lots of great work here. So what's the conclusion? Do you have the information you need (even if not what you wanted)?

Does this need an "Idea" logged?

Is this still open for discussion - if so, around what point?

Thanks, Kyle_R.

Admin.

I marked Fred's very helpful detailed message on what the KPI data can provide as 'correct'.  Although I won't have time to turn this on and try it for awhile, I'll definitely be investigating this when I do have some time.

Thanks,

Tammy