We have created a new status named "Waiting User Response".
Is it possible to factor in the time that a request is in that state into an SLO? As while a request is in that state the SLO target time might be reached through no fault of the assigned analyst.
Todas as Respostas
I have another post also relating to this as i found a piece to the puzzle...
But with no reply i have decided just to crack on with it and see what happens :-)
The idea is pretty simple a runbook which fires maybe every hour, pulls out any incidents with a certain status, and adds an hour to the target end time and warning end time. I wanted to be more clever and find the time the ticket had been in that status and factor that in, but looks to be impossible... well at least not from what i can see :-)
You'll be able how frequently you want the task to run, maybe only adding 24 hours on at end of day for all applicable incidents. At least it's something.
The only issue i can see is if the urgency or priority changes after that modification what the new SLO applied will do, but that's extremely unlikely to happen in our environment.
Once i get a chance i'll set it up and post back here it went.
This is causing a major headache for us, we have also created a "Waiting on Customer" status. The problem is how we exclude these calls from a reporting perspective.
For example, every month we run a report to show us how many Incidents have breached their SLA. Quite simple to do via the OLAP Cubes, however how do we exclude the calls that have breached SLA when the status was equal to "Waiting on Customer", remembering that when these calls are eventually resolved they change status from "Waiting on Customer" to "Resolved" which skews the report.
We can't extend our SLA's like you can Andrew, so we need a different solution. Like automatically resolving or cancelling the call if Status is equal to "Waiting on Customer" and the Target End Date "for a specific SLO" is < 1 hour or something.
Sounds tricky, not too sure what's completely possible from a reporting side as haven't needed to do any of that yet. But let me throw a couple of ideas out to see if any help...
You're probably aware of this already, but there are Resolution lists, so you can add a an extra category for example Resolved - Waiting on Customer. This may provide something extra you can report on if you allow the pending tickets to go past their SLA.
You could create a runbook which runs every hour, pulls out any incident where the status equals "Waiting on Customer", compares the Target End Time to the current time, and if it's < 1 hour set the status to resolved with a specific category and reason. That's definitely achievable and i could help with that. However this would be auto resolving tickets that may or may not be resolved.
I have already created a runbook which auto closes resolved tickets after 2 days, as affected users never do this, and it's very similar to what you've suggested.
Using the Resolution Category in addition to the status would be a good workaround, it would skew some of our problem analysis but I think it would workaround the problem for now, thanks for that suggestion.
Very interested in the Orchestrator runbooks, not sure how you could share the auto resolve after 2 days runbook that you created on here? Maybe skydrive......
- Editado SJM_ sexta-feira, 15 de junho de 2012 14:12
Yeah course, i created it as the powershell script i put in a custom MP didn't seem to do anything, this was much simpler...
Thanks for uploading, I downloaded and imported the run book into my Orchestrator lab and had a look. I'm connecting Orchestrator RTM to a SCSM 2012 Beta install, I need to upgrade it as I'm getting Service Manager connection errors. I'll let you know how I get on once I've done that :-)
The way we used to resolve this (from a reporting perspective) is to create a report and look into the table IncidentStatusDurationFactvw
That table captures the changes on status for an incident, so you should be able to check amount of time on each status (and filtering out the waiting on customer) to get the real numbers.