question Technical Services/Business Services in Incident management in Common Service Data Model forum

Technical Services/Business Services in Incident management

Kristoffer Pari — Tue, 09 Feb 2021 09:36:57 GMT

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

Re: Technical Services/Business Services in Incident management

CasperJT — Tue, 09 Feb 2021 10:23:12 GMT

Hi Kristoffer,

I think you should see the sell/consume domain (business service portfolio, service and offering) as something offered to customers. In ITIL a customer is not necessarily an external entity, but can also be internal.

As an example Finance could be a business service portfolio or business service depending on the size of an organization and the need for granularity. So if you are managing an internal Finance service of some kind it would still be a business service. Your customers are just internal rather than external.

I think you will find this documentation useful as well: Common Service Data Model product view: Incident Management | ServiceNow Docs

I also recall that one of the white papers suggested the most natural starting point for an incident creation would be the application service, since this is the most obvious thing to the user 'I am not able to login to ServiceNow - Prod' or similar. Often end users reporting an incident will may not understand the hierarchy of services and just know what they are logging in to.

Hope this helps.

Best regards,

Casper

Re: Technical Services/Business Services in Incident management

Kristoffer Pari — Tue, 09 Feb 2021 10:42:51 GMT

Hi Casper, and thank you for your answer. I think you are correct for the Incident use case.

I think the issue for me is that i'm having a hard time understanding where Business service is then needed when we talk internal customers.

If end user reports incidents based on Application Services and are records they understand. What is then the use case for Business service?

Br,

Kristoffer

Re: Technical Services/Business Services in Incident management

Barry Kant — Tue, 09 Feb 2021 12:12:40 GMT

Hi Kristoffer,

I would use a decision model like this to judge to decide the audience:

So it is not necessarily and end-user offering to make it part of the Customer Catalog. That can be internal users as well. The distinct would be more on Technical Consumer level, which likely end up in the IT Catalog.

In relation to TBM model it can be visualized this way:

In this case the Green Offerings are still all internal (either end user services or shared services. The other green part will be Core Business services which is more customer facing).

Best regards,

Barry

Re: Technical Services/Business Services in Incident management

CasperJT — Tue, 09 Feb 2021 12:24:28 GMT

Hi Kristoffer,

To address why you would want to add offerings and services. I think you should see this as at least two parts.

Grouping / categorizing things just makes them easier to have an overview

What Applications Services provide what business functionality
When a supporter closes a ticket they are able to provide more detail by have more categorization options

Selling a service does not require the name of a specific product

When looking for a new service you are focusing on what you need rather than the particalur products that can deliver these

Of course nothing is black ad white, but in general I still think the actual end users who are often the ones reporting issues/incidents will not necessarily understand the hierarchies that we need to deliver their services.

Br.

Casper

Re: Technical Services/Business Services in Incident management

Paul Kilkelly — Tue, 09 Feb 2021 13:25:56 GMT

Hi. Another method that I find helpful is to consider the consumer/supplier model again and apply the following 'rules'. 1 - All supplier services are 'technical'. 2 - Consumer services who are not also suppliers are 'business' (consumer<supplier & consumer<supplier). Following this method I'd expect a 'business' service to contain 'business' service offerings. These might depend on application services that are 'owned' by other services (suppliers). I'd expect a 'technical' service to contain (own) 'technical' service offerings that manage infrastructure, and/or application services. A technical service might also contain service offerings that depend on other services that they don't own (those they consumer but don't manage). Hope that helps?

Re: Technical Services/Business Services in Incident management

Christian Prob2 — Tue, 09 Feb 2021 14:39:27 GMT

Hi @Kristoffer Parikka ,

as a super-simple starting point / rule-of-thumb I usually say that anything that is offered to outside IT should be a business service. As mentioned by @CasperJT it should not matter if the customer is 'internal' or 'external'.

You will end up with issues where services are sub-services that support true business services, but that may also be offered directly to the business. I have not yet looked into this in detail - it may result in having to add 'semi-artificial' business services in those cases.

Hope that helps a bit,

Christian

Please mark helpful or correct if deemed so.

Re: Technical Services/Business Services in Incident management

Kristoffer Pari — Tue, 09 Feb 2021 20:00:17 GMT

Hi, and thank you guys of all the great answers. What i’m still wondering about is that are there any use case where a Business service offering would be set as the ”Service Offering” of a incident. I understod from a servicenow PEAK webinar that the field shouls be always populated with a ”Technical Service Offering” and related ”Business services” wouls be as inpacted services?

Re: Technical Services/Business Services in Incident management

Barry Kant — Wed, 10 Feb 2021 06:05:45 GMT

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

Re: Technical Services/Business Services in Incident management

Paul Kilkelly — Wed, 10 Feb 2021 06:39:11 GMT

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:

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.
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.

Re: Technical Services/Business Services in Incident management

CasperJT — Wed, 10 Feb 2021 07:11:15 GMT

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

Re: Technical Services/Business Services in Incident management

Paul Kilkelly — Wed, 10 Feb 2021 08:03:47 GMT

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).

Re: Technical Services/Business Services in Incident management

CasperJT — Wed, 10 Feb 2021 11:06:16 GMT

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).

Re: Technical Services/Business Services in Incident management

kellyobrien — Wed, 10 Feb 2021 15:56:22 GMT

Hi Barry,

This is super helpful information. Is there a way you can share a clearer picture of the Technical and Business services? This is really great to help us start to make sense of how we can design our rollout.

Thanks!

Re: Technical Services/Business Services in Incident management

Barry Kant — Wed, 10 Feb 2021 18:04:09 GMT

I hope those are in better shape:

Enjoy,

Barry

Re: Technical Services/Business Services in Incident management

pellesnurr — Thu, 11 Feb 2021 06:37:08 GMT

Barry, I remember these pictures from some document, but I can´t find it, either in my memory or in my saved docs. What is the source for these?

BR/Per

Re: Technical Services/Business Services in Incident management

Barry Kant — Fri, 12 Feb 2021 06:14:45 GMT

Hi Per,

this is a part of the TBM model, mapped to the CSDM Managed and Sell/Consume domains.

Were specially the Technical Objects are quite common sense objects and also the Sell/Consume objects speak for it-selves. It is a nice starting point to open discussions in those areas.

In the Sell/Consume there is a 3th part :

End User Services
Shared Services
Core Business Services

which are more the industry specific services.

I am not sure if there is a public version of this to be honest.

Cheers,

Barry

Re: Technical Services/Business Services in Incident management

CasperJT — Fri, 12 Feb 2021 06:20:58 GMT

You can find the taxonomy here, but not the neat looking table that Barry has unfortunately. https://www.tbmcouncil.org/learn-tbm/tbm-taxonomy/

Re: Technical Services/Business Services in Incident management

pellesnurr — Fri, 12 Feb 2021 07:12:55 GMT

Thanks both of you for the info, Barry and Casper. I have a vague recollection of the pictures from a demo video, could be from a K20 session. I´ll give a try to find it.

BR/Per

Re: Technical Services/Business Services in Incident management

Kristine Naess — Tue, 02 Mar 2021 15:49:17 GMT

Hi all,

I think this slide from the CSDM primer pretty much explains it all:

Every Business application should have at least one Application service (instance) which again should be related to a Business service offering. The service offering should be scoped to providing the entire or just a specific part of the application service. So if you use service offerings on the incident form, you should be able to show related CI's in the form of related application services (instances) for that offering. You may choose to name the service offering identically to the BusApp (Online Banking Core) or the AppService (Online Banking Core Prod), or give the offering a name that the end user will understand, for example the name of a feature within the BusApp (Mobile Login).

Now, if the case is that there's something wrong with the database the application is utilizing, you need to use Technical service offering to show that. You may want to hide these technical service offerings from the service portal incident form if all you tech personel (vendors or employees) have access back end. If not, they may confuse the business end users. If you choose a tech service offering such as MySQL, the related CI's would be either a dynamic CI group showing only SQL-databases, or a flat list various named databases.