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

[Barry Kant]

hi Erick,


it is depending on the entry point of the incident. 
If it is initiated by the consumers then most likely this is how it is registered:

Attribute	Value
Service	Financial Services
Service Offering	General Ledger
Configuration Item	SAP-FICO (PRD)

If it is initiated by technical parties:

• 2nd line ticket
• Supplier ticket
• Event mgmt

then most likely this is how it is registered:

Attribute	Value
Service	Application Support
Service Offering	SAP Support
Configuration Item	A downstream CI of the SAP-FICO (PRD) Application Service

Hope this gives direction.

Barry

[Mark Bodman]

Yes, Barry has it right. I would only add that the Application Service should be the highest level CI as reported by a user.  When the specific CI causing the issue under that Application Service (network device, database server etc.) is identified.  This will make sure that incidents get assigned to the right Technical Service team as the specific CI that is causing the incident.

[Mark Bodman]

Also wanted to add that you can enable the Principle Class filter, explained here: https://docs.servicenow.com/bundle/tokyo-servicenow-platform/page/product/configuration-management/t...
Here is where you go in the CI Class manager to enable what CI classes you want to use as principle class  that will show up as options based on enabling the filter.

[CMDB Whisperer]

Subtle but important distinction is that the CI is not necessarily what caused the incident, but rather, the most specific CI that describes where the incident was observed.  It may in fact be what caused the incident, or there may be some deeper root cause, but the root cause is typically determined from Problem Management.

A typical scenario I have seen:

1. User submits incident but only specifies the Service, e.g. Financial Services, and possibly the Offering, e.g. General Ledger
2. Further service desk triage activity clarifies that the CI involved is the Application Service, SAP-FICO (PRD), so the CI field is updated on the Incident.
3. Second level support determines that a Server is down, causing an outage on the Application Service.  They log this as an Outage on the Application Service and they update the CI on the incident to be the Server that was down, and they reassign the incident to the Server team.
4. The Server team is aware of a major incident affecting a VMWare cluster, which was logged as a separate incident.  They associate the General Ledger incident as a child incident to the VMWare incident, and the VMWare cluster is listed as the CI of the parent incident.
5. The parent incident and all child incidents are resolved after services are verified as restored.  As this was a major incident with wide reaching impact, Problem Management is involved.  It is determined that the root cause of the major incident and all client incidents was an issue with a storage array that was used by the VMWare cluster.  The storage array is listed as the CI on the Problem record.

[Mark Harrison1]

Nuance, we're probably digressing:

---

@CMDB Whisperer wrote:

Subtle but important distinction is that the CI is not necessarily what caused the incident, but rather, the most specific CI that describes where the incident was observed.  It may in fact be what caused the incident, or there may be some deeper root cause, but the root cause is typically determined from Problem Management.

Agree that the CI will always necessarily be what's observed at the point in time when the field is populated, but would add that it should be updated to end on what caused the incident, because ultimately to manage our service we want to relate the "what was broken" (CI) to "how it was fixed" (incident). This is a unit of work: it has an object (CI) and a method/outcome (process and data).

The pitfall to avoid is having a mix of some incidents associated with the observed CI and others associated with the actually degraded CI, else service entry points (e.g. websites) will be unfairly shown as having lots of incidents when the reality is an upstream CI may be the cause (which is someone else's responsibility), and the data is inconsistent. We need to be clear what the CI field is for and IMO having an iterative journey where the CI ends up as the causing CI (as best as can be ascertained at closure) is preferable for data consistency.

Ultimately Service Management is about outcomes and value, so unless you're at a maturity to be making use of this data it's of little consequence (but data persists, so just because you may not need it now...!) 

It is also generally accepted that Incident is a valid record to restore service, and a problem is not required from an Incident unless structured root cause analysis is required (where the cause is not obvious), or a permanent fix after a workaround is needed to prevent future recurrence. (ITIL4 Principle 1: focus on value: records should offer a useful process and structure to facilitate work. [As an aside: you could automate the creation of closed problems from incident if you wanted a copy to track "root cause" per se to align with a strict interpretation (Principle 7), but the value of this would need to be justified]).

Hope this helps