Is there anything you can do with an Incident item in OVSD that you cannot also do with a Service Call?
Other than the fact that you cannot relate a Service Call to a Service Call (in SP8), is there any real reason to use Incident items in OVSD? Why not do everything with Service Calls? If Incidents did not exist in OVSD what would be impossible to do?
We have a slightly different view to Mark. The key difference is that there doesn't need to be a customer waiting on the result of a Incident (We renamed them System Incident to reduce confusion). It allows administrators to record incidents that the customers may not even know about. (eg Tape Drive or backup failures, low disk space etc). Service Calls are either Requests for Service or Customer Incidents.
We also have escalation notification based on the Service Calls (a customer is waiting) but don't have escalations on System Incidents. Also reporting on Service Calls is then reporting purely on those things directly affecting your customers - administrators can still handle non customer incidents without throwing the SLA reporting out.
We also intend (one day) to customise System Incidents to record outages of CIs. Eg custom fields Outage Start Time, Finish Time, Outage Reason and then use this to help do basic availability stats.
We are even considering flagging some Incidents as "Customer Viewable" and listing these on Service Pages. So if there is a major outage of a system people can see before they log another Service Call.
oh and as per ITIL theory, by recording these non customer incidents - problem management can do trending to see if particular CIs or CI types are having issues.
Also capacity related Incidents (performance counters exceeding a threshold fo a period) can also be tracked and trends fed back into the Capacity planning cycle. (But often there are other tools for this.)
I take your point about not needing incidents and that you can do everything you need using service calls.
We (Fox) use incidents (renamed as events) typically for automatically generated incidents (where there is no caller) mainly to reinforce that a different process/procedure is followed for such events.
My advice would be to use whatever fits your processes and if using only SC does that, then leave out incidents.
Hi Josh. Strangely enough I just had this very discussion with a client before coming home and reading your post. He has several Incident Managers who manage Sev 1 Incidents - either reported by callers or detected manually. We haven't yet implemented SD so trying to decide how best to handle these. Service Calls are good because you can create them by email (their business units use a Sev 1 email address now), and have the caller. Incidents (which we usually rename System Incidents) are good because you don't need a caller and can then link all the related Service Calls to them....but you can't create them from inbound email. A big change with V5 is that you can link SC's to SC's so it becomes possible for the first Sev 1 SC to be marked the master (and used by the Incident Manager to record progess) and all other SC's to be linked to it. Under 4.5 you needed to create an Incident Record to be the master if you wanted to link all the SC's that resulted from the Incident. I had 3 options - just use SC's for serious incidents, just use System Incident records, or use both. From your post and the other replies, I think I'll just use SC's for all these, maybe with a separate category. That leaves two questions: - what to do with auto-detected faults....I still think these should logged as "System Incidents" - ie in the Incident module. - what to do with internally manually detected incidents (ie by IT) that don't have customer impact - not sure about these but inclined to use Incident module as long as the separation is not too confusing for IT staff. By the way, in SD5 there is a big difference: for Service Calls, you only have one Service (as with V4.5), but with Incidents you have a table of affected Services. So I suspect the mechanism determining SLA will be quite different. HTH.........Cheers, Ken.
Your remark about being able to relate an incident to multiple services in 5.0, whilst a service call can only be related to 1 service, is a very significant difference. Thanks for pointing it out.
It raises this question, though. Using 5.0, to which service does H-P expect you to relate a service call when a user calls the service desk to say that his or her PC doesn't work at all (and hence ALL services to which that user is entitled are not available) ?
Hi Josh, most of my clients have a Service like "Desktop Service" which covers PC hardware (incl monitor), SOE software, network connection etc - in other words everything that supports a PC working. So that would be the service selected in your example. Most have Email Service, Printing Service, Internet Service also. Others wrap some of these into the Desktop Service as well. Depends what works best for the Business and IT together.