Technical Services/Business Services in Incident management

[Kristoffer Pari]

Hi,

i have a case where ServiceNow is used purely for managing a Company internal Application needs. 

Users who report e.g. incidents are internal users or vendors. 

We would like to use service offering in some cases for users to choose when reporting incidents. 

Now the question is, should i use Technical Service offerings or Business Service offerings?

From different materials i have read, i get the understanding that Business Service Offerings are used mainly when you have a service that a company Sells and should only show the Business Impact for a incident? Are there any reason why a Business Service Offering  would be created for a internal Application if it is not related to any sold/provided customer faced service, and populated to the Service offering field on a incident?

Regards,
Kristoffer

[Barry Kant]

Hi Kristoffer,

I do not agree with that.

It depends what the entry point is of the ticket:

If it is a technical initiated incident:

• via event
• via a supplier/partner
• via 2nd-line groups

Then it is registered on a technical service offering. This triggers SLA (OLA or UC). The Impacted Service capability will list all potentially impacted business services (offerings)

If it is customer initiated incident:

• via portal/end user/customer

then it is registered on a business service offering. This triggers SLA. This entry point you might not know the CI level impacted, so you know the Service Offering, maybe the application service, or sometimes the CI (eg: your laptop, or a printer). What you want to gain from the CSDM service model is the chain of support for the business service offering. This helps the triage/routing.

Best regards,

Barry

[Paul Kilkelly]

You aren’t alone with this question.  I’ve had a few conversations with people about the purpose of the ‘service’ and ‘service offering’ on the Incident form.  My answer is to ignore them until they’ve built the necessary logic around the only field that holds the ‘affected CI’: the ‘Configuration Item’.

 The affected CI can be any class, though for clients seeking to adopt CSDM I advise excluding Business Apps and possibly the Service, but allow Service Offerings - as the brand offered to end users - and other classes (including application services) for technical users.  The affected CI should be used to drive assignment for the Incident, and the SLA (off the affected CI’s managing tSO’s service commitments, if not already a SO). 

The only use cases for the ‘service’ and ‘service offering’ on the Incident form that make sense to me are:

1. to reflect the ownership hierarchy of the affected CI (so for non-service class CIs these will the Tech Service and Tech Service Offering). In this case the ‘service’ and ‘service offering’ are read-only and slaved to the affected CI. 
2. As a set of filters to help narrow down the list of CIs presented to the user for the ‘Configuration Item’. In this case, the three fields are linked, so selecting the ‘configuration’ also sets the other two. Setting the ‘service’ limits the set of ‘offerings’ available, and both limit the set of CIs presented.  

This approach is consistent with the CSDM paper for Incident Management. 

Hopefully someone here will put me right if I’ve missed something.  

[CasperJT]

I would argue it still comes back to your requirements.

• Adding a Technical Service and Technical Service Offering will tell you about the hierarchy responsible for managing the incident.
• Adding a Business Service and Business Service Offering will tell you who was affected by the Incident.

Both approaches have merit, but from different perspectives, though I would lean more towards the business impact than the technical, since that is what incident management is about.

Again I don't necessarily think the reporting user should be adding the affected Service and Offering, but rather the technician resolving the incident, since they will likely have a better understanding of the whole hierarchy.

Best,

Casper

[Paul Kilkelly]

Casper, I think we need to be really careful about those approaches, especially when it comes to the use of the words ‘affected by’ and ‘business impact’.  They aren’t the same thing. And we can’t assume the ‘service’ and ‘service offering’ on the Incident form tells us anything about who was affected by the incident: the reporter may have nothing to do with the ‘hierarchy responsible for managing the incident’.   

I do agree that incident management is related to managing business impacts. However that doesn’t mean we treat the affected CI any differently if it is managed within a business or technical service hierarchy, or change the valid use of the ‘service’ and ‘service offering’ on the incident form.  

I’ll give you my opinion based on my reading of CSDM.  I may be horribly wrong 🙂

It is ok to allow incident reporters to use the service and service offering to help them navigate to the best Configuration Item. However, once the CI is set those fields should be set to the ‘management hierarchy’ of the CI (using the data we hold in the CMDB). Not OOTB, but as shown by the K20 ‘gift’ we should then add code to automatically assign the Incident to the support group for the affected CI. 

Requiring technicians to manually add that data suggests a data quality issue (unmanaged CI) or missing logic on the form.  We follow the CSDM to avoid manually entering data that should already be derivable from the CMDB.  

I also believe it is important never to use the ‘service’ and ‘service offering’ on the incident form to determine ‘business impact’.  That is not the purpose of these fields (within CSDM anyway).  The correct (if following CSDM) source of information on the ‘business impact’ is derived from the Incident (or Change) ‘impacted services’ related list.  

Note that if the Incident configuration item is itself a member of the ‘service’ class family that it will also appear in the ‘Impacted services’ list.  

Another way to look at this:

• the Incident ‘service’, ‘service offering’ are driven by the ‘Configuration item’. They hold information about the ownership/management of the CI affected by the Incident. They can be manually entered by the reporter to help localise the Configuration Item, but become read-only and slaved to the CI when set. Note: that logic is not OOTB but is how I read CSDM.
• the Incident (or Change) related list of ‘Impacted Service’ - derived from the CI relationships that lead to the set of dependent consuming services - gives us the data we need to determine the impact of the incident (or Change).

[CasperJT]

As I see it the Business Service and Offering are oriented towards the consuming application services. So the Business Service Offering is intended to tell you who uses a service.

The technical service manages the technical aspects of the service.

I remember an example with ServiceNow, where you have a technical service offering named something like platform management containing ServiceNow and you had business service offerings called 'Normal Change', 'Emergency Change' and 'Standard Change' that depended on the ServiceNow application service.

So in an incident raised by a 'user' I would expect they would report the inability to work with for example normal changes on a particular ServiceNow instance, thus giving a quite clear impact understanding of that particular incident.

I will not claim there is a single true method to doing this, I think it depends on the company and the maturity of their model. I also agree that the impacted services related list is an important feature in understanding the broader impact of an incident (or problem or change).