Posted: Thu Jul 13, 2006 8:00 am Post subject: HPOV Service Desk service call VS incident process
I have been reading the forum for some time but this is my first post. I have been unable to find a clear answer to my question here or elsewhere on the web including the HP forums. We are using the HP OpenView Service Desk application which provides us with several "ticket" types. Service calls, Incidents, and problems. There are are changes too but that doesn't relate to this question.
basicaly the question is how are the service calls used as opposed to the incidents?
Currently our IT dept. has a service desk located in Seattle that takes calls. They currently only open service call tickets of which there are a couple type. Service interuptions, requests for information, request for administration. invalid call. For the service interuption calls they open a SC and assign it the the group owning the service. My group is in denver and we monitor the infrastructure and open incidents which are assigned out to the appropriate group.
The intent was that SC's record the user impact of an outage from the user perspective. An IN records the actual infrastructure failure from an IT perspective. But the current process does not support that in my opinion. When an SC is assigned to the group owning the service and they work against that SC, at the resolution of the sc they either leave the service and CI as it was reflecting the user perspective or they change it to the actual service and CI that failed thus losing the user perspective.
My position has been that for every service interuption type service call that is opened there should be a corresponding incident that is related to the SC. The SC will maintain the user perspective and the IN will be the IT perspective. If the failure results in multiple calls to the help desk then multiple SC's are created and all of the related to the incident. From there the standard incident and problem management processes take place. When the incident has been resolved the related SC's should inherit the root cause classification and closure code of the incidents and the status of the SC should go to complete and assigned to either the opener of the SC or to a closure group to get user agreement to close.
So first off, should the help desk be assigning the service calls to the groups or should they contact the group (via phone or work order) and determine if there is actually a failure. Are they using the service calls correctly?
Generaly ITIL seems to not see service calls and incidents seperatly. It seems to just address service requests and incidents. Should the help desk be opening incidents when a service interuption call is recieved.
How does a service call about an interuption turn into an incident or does it?
Since HP provides service calls, incidents, and problems how is it that these are supposed to work together? Do the SC's and IN's overlap eachother?
Hopefully you guys can understand what I'm driving at here and can provide some sort of direction.
Is this a stupid question or just not making sense?
What we have tried to do is cature the user perspective with a service call for example their e-mail died so the SC has service e-mail and CI might be the mail server. When the problem is found it might be the switch that the e0-mail server is on is down. So should the SC be changed to the actual service and CI that failed IE data network and switch therby losing the user perspective. Should only the CI change to the switch and service remain? Keep in mind that there are say 20 calls from users and 20 service calls with any number of services that may rely on that switch, which would all need changed. OR do these remain as they are as the record of the symtoms (and an ioncident created for the switch failure, all SC related to it and the incident is filled in with the acual failure info. This way we have the user symtoms and the actual failure.
I think we have worked out a process that I hope is right.
The first call to the help desk generates a service call of the type “service interruption” (SI). This is escalated to the appropriate support group for investigation. If an actual failure is found then an Incident is generated for the failure. The service call is related to the IN and they are essentially worked together. The failure incident is communicated to IT and the help desk via a message board. Any addition calls to the HD for the same issue generate service calls of the type “request for information” about the outage. These are immediately closed and related to the incident without being reassigned out of the help desk.
This I think works OK. But the problem I see is if the help desk receives a bunch of calls all at once. And no incident has been opened yet. Which service call is the type “service interruption” and escalated? How are the other calls handled untill the incident
Any suggestions or are we totally off the mark here?
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Thu Jul 20, 2006 5:11 pm Post subject:
I have read your posts a number of times, and have held back, mainly because I was not sure that I had really grasped your problem. On re-reading I am still not sure, but will try to assist - I suspect that there is almost too much info to soak up.
Here goes then
Firstly a Service interruption is an Incident, it doesn't turn into one!
If the user(customer) raises a fault call, then from his/her perspective, something is broken and needs fixing.
I think you are getting confused between Service Calls (Requests) and Fault Calls (Incidents) both need assigning to a workgroup for resolution, they just affect different metrics.
All info at this point is going to be based on business needs and not technological needs. The user doesn't care if the fault is caused by a dodgy router, switch or cable - all he knows is that he cannot connect to his E-Mail server.
As far as the multiple calls for the same Incident goes, RJP has covered this elsewhere in great detail, so I won't attempt to improve on his offering.
I appreciate that this probably does not address all your concerns, but I hope it is a start, and is a help
Thanks for the reply. If I read you right it sounds like our Help Desk should be opening incidents when a user reports a system fault?
Are you familur with the HPOV service desk product? It seems like part of this is related to some particulars with their product.
There are some reasons we have used the service call ticket for reporting system faults.
1) HPOVSD provides a service call category of "service interruption" which we understood to be for reporting just that. You suggest those should be "incidents"
2) We want to keep the user perspective separate from but related to the IT perspective. One user may see the e-mail service down, another the inventory management service down, but the root cause was the data network service. The service calls capture the services that failed because of the data network service on which they rely. How can you capture both the user service and the actual service in one ticket? Or is it understood that if the parent service fails then all the services relying on it fail? I see a problem with that in that routing or QOS are function of the network service and a routing problem might impact one service relying on network while others are not impacted.
3) We are assuming the position that an incident should reflect actual failures as much as possible. If user calls with problem and the Help Desk (I use the term Help Desk to avoid confusion since our Application is call "service desk") starts opening an incident and then it turns out that the caller had just done something wrong and there is no actual failure, only a training issue.
4) We define a service call as a user report or request, an incident is something that happened and a problem is a chronic issue or something for which there is not a solution currently available. Perhaps out definition of problem is too restrictive and should be more like what we use incidents for?
Perhaps the problem is that we are using incidents only for actual infrastructure failures? I don't know. I think it makes sense that a service call is a user report of something happening and is the input from the user/ business perspective whether it is a request or a report of trouble, and an incident is something that actually happened.
I would really like to talk to someone who is very familur with HP's service desk application.
I really appreciate your help.
PS If by too much info you mean that I need to shorten it up a bit I can assure you that my boss is driving that same message into me. I'm just so detail oriented that I can't seem to get away from it.
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Fri Jul 21, 2006 6:11 pm Post subject:
No I am not familiar with the HP Openview offering, another reason for hanging back, hoping that someone else would dive in. I am a Change & Config Manager with 30 plus years of experience in IT, so hoped I might be able to assist you.
I believe that yes, you should be opening an incident for a user fault call. It can always be reclassified later if root cause analysis indicates that lack of training is the issue.
As we are trying to get IT closer to the business requirements, we should be making the business side of the call more important than the technology side.
For me if a service is not available for any reason, then an incident has occurred, and I would be considering opening an incident report.
I have tried to see this from an ITIL point of view.
Question 1 - See above
Question 2 - I think that it is understood as a good CMDB will show the relationship between the parent service and the child services that are dependent upon it. Until you have investigated your routing issue - you don't know and it is safer to assume all is affected, until proved otherwise
Question 3 - See above
Question 4 - I suspect that the problem here might be too much silo mentality - If the user cannot use a service then there is a Service interuption - something has happened - there is an incident.
Joined: Jul 07, 2006 Posts: 1 Location: Amsterdam, The Netherlands
Posted: Fri Jul 21, 2006 10:28 pm Post subject:
I think Ed is right from the "ITIL description" point of view.
Point is, that the names of the different modules of OVSD can be a bit misleading.
I only got to work with OVSD since a few months, and I also was a bit confused by the way OVSD's incidentmanagement is designed. But after some study I think this is the way you should use OVSD:
In both the OVSD-Service Call and OVSD-incident modules you can register ITIL-incidents. HP distinguishes two kinds (SC and INC). The main difference is that the source of a Service Call is a customer, while the source of an (OVSD-)incident is a system.
So you should register every customer contact in the SC module, and people monitoring systems should register incidents in the incident module.
Why the difference?
In the SC module the deadline is calculated through the SLA related to the caller, whilst the INC module calculates the deadline with "shortest" SLA.
To make it less confusing, we renamed the INC module to "Events".
In the Service Call module we have a category list of "Incident, calamity, Information request, Complaint, Request".
Service Request are registered in the change module. Because we user version 5, we prefer to register Service Request in the change module because you can build a "workflow" of underlying workorders.
Thanks for all the input. I think thisis what is being said and maybe Elvis can confirm since he seems to be the HPSD expert. The SC reflects user perspective and the assigned group should create problem tickets once the actual problem is identified. Whether it is a single service call or multiple calls on different individual issues. As long as the root cause of those various service calls can be attributed to a single point of failure for which the problem is opened. this means that every SC or IN for a service interuption should have a problem for it. I see that process working but it seems a little overly tedious to open a problem for a single SC or IN ticket. But that is fine if that is the process. in essence the model is that an SC is a report of a user "issue" and an IN is a report of a system alert, the problem is what the actual problem is that was found when investigating the reports of trouble.
For the main group I work in this means that we will have to wear two hats. First is as a monitoring group openeing incidents. Second, we support level 2 - 3 network issues so so for routers. switches, and WAN circuit incidents we would basicaly assign then to ourselves and open a problem ticket on it.
Elvis, is that how you guys are doing it?
That is a clean process that I understand.
Thanks guys. This is a big help. It was a little tough getting to it but I think we found the problem. What you all are saying makes sense. I will share this with the rest of my team. Thank you for your help.
And as an after thought, As a dual role group what would stop us from just opening a problem for an alert rather than openeing the incident for the alert than a problem to work against? Is that just a matter of proceedure? Or would it be OK to open an incident if it is going to be assigned out of my group and jump right to the problem ticket if it will be handled internaly by my group?
Joined: Nov 01, 2004 Posts: 83 Location: Sask, Canada
Posted: Wed Jul 26, 2006 9:11 am Post subject:
my 2 cents. For dealing with an incident, open an incident record. For dealing with a problem, open a problem record. SO much easier!
Skipping the incident step and going directly to a problem ticket might seem like it is saving time, but may skew your metrics. Also, consistency between group processes helps as people move around - shortens learning curve, reinforces use of best practices - all that good stuff....
Now that I have a better understanding I see this is a topic better suited to the PM forum. And reading through there is getting me a much clearer picture. I still have trouble with the fact that HPOVSD tool has confused things by separating service calls and incidents. I can't get a clear answer about whether the service call record should be for any report received from a "caller" as some indicate or if it should be used only for a call requesting some service be performed as some seem to suggest (not necessarily in the forum)
Joined: Aug 20, 2006 Posts: 25 Location: Indonesia
Posted: Wed Aug 23, 2006 11:39 pm Post subject:
In ITIL, the Service Desk is treated as a function separated from Incident Management. Incident Management is one of the management processes in ITIL. This is reflected in HPOV SD as the Service Call and Incident. Thinking simple, the service call ticket is the one that will be used by the Service Desk's agent in logging the call from customer (outside IT division) while incident ticket is used in IT division to log an incident occurs on IT asset that can impact the service delivered to the customer. For example, if you use use NNM and integrate it with SD and one node is down, this will trigger an event that will create an incident ticket automatically in SD.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum