What CI should be filled out on an incident record?

[Erick18]

What class of CI should be filled out on the Incident record? Technical Service Offering, Business Application, or Application Service? For example if there is an issue with SAP Production Application and we have a business application called SAP, an Application Service called SAP Production and a Technical Service Offering called SAP Production Support which one should be selected in the CI field on the incident record. 

Thanks,

Erick

[Peter Kindbom]

How about, as a starting point, thinking "outside-in" (the viewpoint of the consumer/customer) instead of diving down in technology?

A Business Service have at least one Service Offering. A Service Offering should have a Service Committment (e.g opening hours, availability). The commitment should be agreed with the customer. The customer should be able to decide if a particular Service offering is critcal on the weekend or not. 

If the Service Offering has a Service Committment saying that this is very critical eg. supporting planning of heart surgery this is what IT should act on. The Service Offering is reported as not working during surgery and manual routines is envoked then IT shold treat this as a major incident and use the CMDB and find and fix the incident. When solved the "caused by" CI should be indentified and maybe a Problem Management and/or Continual Improvement should be used.

It is a mystery to me why something like the above is not implemented as Out of the box in Service now and obvious to our community. Comments on this? 

[CMDB Whisperer]

Always good to think about the bigger picture, although I'm not sure I see where the Service Commitment helps to answer the question of which CI to identify in the incident.

From the view of the customer the best thing you can do is to indicate where the problem was observed.  Most likely this would be on the service or the service offering, but possibly on the application service.  There are fields for each of these so we don't necessarily have to ask the user to specify the CI.  But the service desk (or whatever team is triaging the incident) should be working to specify the CI and/or Service fields.  But still, both of these fields should indicate the primary area where the problem was observed, and assuming it was on some instance of an business application, the CI should specify the Application Service.  If the specific infrastructure CI is known then you can enter that instead; that would typically be due to the incident being raised by event management/monitoring tool, but even there, we are indicating where the issue was observed, we're not necessarily the CI that was the root cause of the incident.  That's really the job of problem management, as you rightly point out.

So back to the OP question: what CI should I specify?  You should specify the CI or Application Service that indicates where the incident was observed, and if you don't know it, just specify the Service or Offering in the respective fields, and then the support team(s) should work to make sure that the CI is specified correctly, and this should be an Application Service or a CI within the Application Service.  The CI field should not be a Technical/Business Service or Offering, nor should it contain a Business Application.

[Peter Kindbom]

This is an interesting issue and it of course depends on which principles you have done your Service Now implementation. There are alot of options (too many?) for basic incident management. This is how I see it: 

Business Service has at least one Service Offering and this is what is customer facing. It on the Service Offering we can have a negotiation on what servicel levels are required and agreed.

If there is an incident causing an Outage it its on the service offering this is reported and measured.

The incident can be caused by a specific Application Instance (Application "Service") or maybe by a specific whatever CI (eg. server). This is useful information for resolving the incident and later doing a permanet fix or prevention.

The priciple that according to med should be OOB is tha an incident always sould registred on a Service Offering which can be reported and used for measuring SLA-breach (compare it to Service Committment). Then you can also register the "caused by" CI as any CI (e.g. server).

[Mark Harrison1]

As per Barry's reply it depends on who is logging.

The most important concept is that CI selection should be an iterative journey. Users can't be expected to know what the affected CI is down to the server, and neither can the tech teams sometimes for their initial triage.

If you discourage manual assignment, and encourage auto-assignment to the support team listed on the CI, then you incentivise users to update the CI to step the record on. through triage. to the correct resolver team. A prompt on resolution to confirm the final CI then provides a final data quality check. 

With accurate CI data, you have the context required to understand your service management record data: the what (CI) and the how (incident). You can certainly record the difference between what the user selects initially and the final CI - very useful feedback.

Hope this helps