How to configure incident management to align with CSDM; a leading practice guide

[Chris Shakespea]

ServiceNow has made several changes to how incidents integrate with CSDM.  This lays the foundations for Service Portfolio Management, Digital Portfolio Management, and ability to tie Events to Business Services.

Ensuring first line agents capture and record incidents so that they align with CSDM will reduce data entry time and maximize the capabilities of ServiceNow platform.

Summary of Recommendations:

We recommend 5 configuration and operational changes to maximize the potential of CSDM in the incident process

1. Consider three use cases for incident creation: agents, IT staff, system-generated
2. Configure your incident form so that Services are automatically derived from service offerings
3. Get started with CSDM by creating Service offerings, linked to Services
4. Populate the Service Offering first when creating new incidents
5. Auto-populate the Service. Examples are included below.

Following those recommended changes the form should look similar to below. Representative data is shown in the form to show how this might also be populated in practice :-

1. Consider three use cases for incident creation: agents, IT staff, system-generated

There are 3 main perspectives to consider when raising an incident. The use case will have a significant effect on the approach taken to populate the fields and whether that is manual entry or driven by the system.

User Perspective	IT Staff	System Perspective
End users do not have a concept of business services or business service offerings They will often refer to an application that has been offered to them e.g. Outlook , Workday or device e.g. Printer	Users in the support groups (e.g. network, middleware, database) raising incidents either for systems they own or systems affecting those	System generated incidents ·       alert and event management systems ·       outages ·       Caused by change

Here we will focus on then user perspective as this is likely to be an interaction with first line agents to capture and record incidents, though the others should be considered (see CSDM Workshop for further detail).

Out of the box it is possible to populate 3 fields (Service, Service Offering and Configuration Item) with data intended for one of the other fields. E.g. Service entered into CI field. This leads to inconsistent data entry impacting quality of service. 

2. Configure your incident form so that Services are automatically derived from Service Offerings

These simple changes to the incident form will reduce data inaccuracies and inconsistency, making incident reporting more reliable:

1. Make the Service field read-only
2. Configure the form to auto-populate the Service once the Service Offering is populated.
3. Add filtering on CI classes to display those that relate to a typical IT environment

The configuration changes required to achieve this are enumerated here: 

Following those recommended changes the form should look similar to below. Representative data is shown in the form to show how this might also be populated in practice :-

* form layout may differ slightly for workspace

The fields on the Incident form directly related to CMDB/CSDM are :

• Service
• Service Offering
• Configuration Item

These fields relate to each other as described in the CSDM Whitepaper

3. Get started with CSDM by creating service offerings, linked to Services

Mapping services is key to taking advantage of the recommended changes and can feel like a big task but it can be broken down into key steps that reflect your organizational needs and maturity.

There is no one single model that suits all organizations, think of CSDM as a compliance framework for the model that suits your organization.

Set up some service offerings, using our CSDM workshop and Service Portfolio Management Workshop as guidance

• this can be application or service focused dependent on what fits your organization best
• ensure you stay in alignment with CSDM

Where you have Discovery it is recommended to populate and have these classes as Principal CI’s

• Application Service, Server, Computer, Network Gear, Data Center, Database, PDU, UPS
  • further detail see CMDB process guide

For further guidance see:

• What is a Service and Service Offering
• Define and map out your business services
• CSDM workshop
• CMDB workshop
• CSDM Data model examples

4. Populate the Service Offering first when creating incidents

The hierarchy described in CSDM needs to be reflected and asserted within the incident form

The critical field on the record is the service offering. Taking a one up / one down perspective, populating this provides filtering for

• Business Service
• Application Service / CI

This reduces the potential for level of error in populating these fields and time required. The diagram below shows how the modified form and CSDM relate to each other and the required actions to populate.

5. Auto-populate the Service

There are a range of scenarios that apply to when an incident is created, for illustration purposes 3 of the most common to incident creation for end users are illustrated :-

• End user device issue
• Cloud Native (SaaS) Application
• Infrastructure / Cloud Hosted App

Scenario 1

End user device issue

Service Offering is entered by agent

Service auto-populated from Service Offering and read-only

CI selection from those associated to service offering

The agent should fill in the service offering first for consistency and then fill in the CI.

Changing the Service Offering should update the Service

Scenario 2

Cloud Native (SaaS) Application

Service Offering populated on

Service auto-populated from Service Offering and read-only

CI not populated for cloud native

With cloud native the value of CI is limited value as the service offering represents the key artifact

Scenario 3

Infrastructure / Cloud Hosted App

Service Offering populated on

Service auto-populated from Service Offering and read-only

CI populated post initial incident by technical team, which may impact Service Offering

Initial raising of the incident the Infrastructure CI is unlikely to be known unless monitoring systems have previously raised an event / outage.

Child incident can be raised for the Technical Service Offering

Addendum : Example Scripts

Clear service on changing offering

Make “Clear Offering on changing Service” to Active = false

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

   if (isLoading || newValue === '') {

      return;

   }

var service_offering = g_form.getReference('service_offering', setBusinessService);

}

function setBusinessService(set_service_offering) { //reference is passed into callback as first arguments

  g_form.setValue('business_service',set_service_offering.parent);

}

[KKrabbenhoft]

This is great!! I am very green when it comes to the CSDM/CMDB ServiceNow space. Thank you so much. 

[Mathew Hillyard]

This is an interesting article that sparks a few questions:

1. Where is the Application Service? This is what is referenced more than anything when talking about focus for Incident, Problem and Change. If we enter a Service Offering that populates the Service field with a Business Service. Application Service is inside a child table of the top-line Service [cmdb_ci_service] table so in theory could be referenced from the Service field. After all, Business, Technical and Application are all types of Service.
2. How about APM? How will APM Indicators be populated as they currently rely on the Business Application (field) breakdown on these IPC tables? The quickest and most reliable way to determine the Business Application on a record is from the Application Service as it is a single CI relationship away (unless you are using SDLC Components, which I suspect the majority of customers will not for the foreseeable future), and also because the link between Design and Sell/Consume domains is not made until the final Fly stage
3. CSDM implementation recommendation does not establish Business Services and Business Service Offerings until the Run phase. The recommended approach above would therefore not be possible for a customer's operational processes until a long way into a customer's CSDM journey, which doesn't seem practical or workable.

Whilst I largely agree with this article's content, I feel there is a gap where Application Services have no consistent way to be represented within IPC. The text above and the CSDM 4 draft whitepaper suggests it is normally entered into the Configuration Item field but this then loses the ability to associate the record directly with an infrastructure CI (remember, even the most advanced customers may have a CI that rolls up to multiple records in CSDM) - sure, an agent may not know which infra CI the incident comes from but other sources like event management it most definitely is possible. 

Some clarification on this would be very helpful.

[RubenFuertes]

Hi Chris,

This Guide was very very interesting and useful, could you help us with the extension of this same and the service catalog ???? It would be interesting to know your opinion and tips, best practices about it.

[Chris Shakespea]

To respond to @Mathew Hillyard 

Question:

Where is the Application Service? This is what is referenced more than anything when talking about focus for Incident, Problem and Change. If we enter a Service Offering that populates the Service field with a Business Service. Application Service is inside a child table of the top-line Service [cmdb_ci_service] table so in theory could be referenced from the Service field. After all, Business, Technical and Application are all types of Service.

Response:

While the Application Service is name “Service” it is admittedly not a great naming standard.  It is more of a system or stack.  The Application Service is considered a CI as it represents the whole of all the pieces and parts of an deployed stack

From: Incident Management Product View CSDM V3

The Incident is for an Application issue – In this scenario the Application Service may be populated in the configuration_item attribute on the Incident form representing the unique deployment of an application stack.

Example, the Application Service of MyApp 3.0 Prod has been reported has being unavailable.

The Incident on an infrastructure CI is impacting Services – in this scenario the Application Service may be populated on the Incident’s Impacted Services related list,  _task_cmdb_ci_service, to identify the Application Service as one of the Services impacted. Example, the Server OMG124 may be impacting my Application Service of MyApp 3.0 Prod and other related Services.

Question:

How about APM? How will APM Indicators be populated as they currently rely on the Business Application (field) breakdown on these IPC tables? The quickest and most reliable way to determine the Business Application on a record is from the Application Service as it is a single CI relationship away (unless you are using SDLC Components, which I suspect the majority of customers will not for the foreseeable future), and also because the link between Design and Sell/Consume domains is not made until the final Fly stage

Response:

Set the Incident Properties. Business Applications are not to be used in ITSM processes. See CSDM 3.0 Whitepaper for APM

Examples of the properties for Incident and Business Applications

Copy Incident and Create Child Incident Properties

List of attributes (comma-separated) from Business Applications (task_cmdb_ci_business_app) related list that will be copied from the originating incident

business_application

Incident Related List Properties

Populate the Business Application related list for incidents

(set to Yes)

Question:

CSDM implementation recommendation does not establish Business Services and Business Service Offerings until the Run phase. The recommended approach above would therefore not be possible for a customer's operational processes until a long way into a customer's CSDM journey, which doesn't seem practical or workable.

Response:

I recommend CSDM Workshop – Getting Started (and other CSDM content on Now Create)

https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=dde64c62875255d0f2f443f7dabb354b

In the workshop deck customers may need to do more than just crawl, there are “business service offerings”  that do not depend on a Application Service (thinking conference rooms, printing, desktop apps) .  Customers if they can define a Application Service, then they would easily be able to define an Service Offering

example:

Application Service:  MYAPP Prod

Business Service Offering: MYAPP (or friendly business name)

There is not really  way to “go live” with just Application Services for ITSM.

[Mathew Hillyard]

Hi Chris,

I appreciate you taking the time to provide a detailed response to my thoughts.

App Services

What you've said makes perfect sense, it may just be a little tricky for customers expecting to see all the relevant detail "on the form". However I could argue that if App Service belongs on the Impacted Services/CIs related list why have the Business/Technical Service on a field on the form? Both are just as relevant to the Incident Management process (the App service potentially more relevant on the form from a troubleshooting point of view). My concern is that if some Incidents have the App Service in the Configuration Item field but others on the Impacted Services/CIs related list, it could complicate reporting.

APM

Your reply mentions the Impacted Business Applications table and Incident Properties that presumably enter values in this related list based on CI relationships against the values for Configuration Item/Service Offering etc. on the Incident. That makes perfect sense, but it doesn't enable APM Indicator data collection. That still relies on a value on Incident/Problem/Change in the (deprecated) Business Application field. I understand this is in line to be resolved at some point. Please see this thread for more information: APM Indicators for Incident, Problem and Change: Business Application Breakdown.

CSDM implementation

I don't think the existing collateral really addresses how to migrate to CSDM from something existing. The crawl/walk/run/fly approach only makes sense if Business Apps, Capabilities, Processes Services and Offerings are all empty (in effect, they're only using the CMDB for a subset of what's in Manage Technical Services). It's not just that a customer may need to look at other aspects of the framework - my practical experience is that a customer may have to implement most of the key elements of CSDM (assuming foundational data is in place first) in one hit to avoid production impact because of all the dependencies in their current setup. Finally, if the source and destination data belong in different fields it's possible to identify where data needs to migrate to, and migrate it independently (and prior to) of the refactoring of coding dependencies. 

[TeriM3]

This was an excellent Chris & you too Mike!  Really thought out details and great screenshots with info as well!  As CSDM has become the major factor for uses of CIs, this post really helps in that understanding.

Very much appreciated!  Thanks so much!

~Teri

[TeriM3]

Oops...meant Matthew too!  Thanks again!  🙂

[bigfissy]

Thank you for this detailed explanation  Chris Shakespea

[Jori]

what kind of reference qualifier is needed for Configuration item field to filter only the CI's related to users company and selected service offering? also what is the needed relation between dynamic ci group and the service offering?

[Robin Chytil]

Hi @Chris Shakespea , 

(nice to read you, as we met several years ago in Zurich)

Thank you very much for the post, very useful, and very much aligned to my understanding of a correct configuration of the incident form. In my opinion it should almost be the default behaviour of the form OOTB!

One case I wanted to check with you: when IT staff want to log an incident on a Technical service, do you confirm it works the same way?

1. Service Offering is Storage Management --> Service is automatically set to Infrastructure Management
2. CI can be for example a storage bay, or an application service.

I would then recommend only L2/L3 support staff should be allowed to log tickets on technical services. Service desk should always refer a Business service offering.

Another question: Technical service Offering "Contains" Application services or Dynamic groups, as they are responsible of managing these CI. But I believe some Technical services can "Depend on" on Application service. An example would be "Server management and deployment" (a TSO) depending on "SCCM" to work. Would that be correct?

Could we then have the Technical Service automatically impacted when SCCM goes down?

Is this working with technical services as described in the "Alert Impact Calculation" documentation?.

And could we then display a subset of Technical services in the Availability dashboard (e.g. Hosting services)?

Thank you to share your views.

Robin

[Karl Rohde]

Thanks Chris. This is really useful.

If you could do one for Problem and Change it would be great, however I can infer (somewhat sheepishly) from this article on how we can apply it.

Re: Incident

Question 1: I see you use "Business Service Offerings" in the incident form which makes sense. If we make the "service" field read-only should we limit the "Service Offering" field to show only "business service offerings"?

Question 2: If your response is yes to question 1, where do we use "Technical Service Offerings"? I read in another blog that it's used in Incident or Problem tasks. Is this correct? 

Question 3: If your response to question 2 is yes it creates confusion for the agent, no? How does an agent easily identify the "technical service offerings" for an incident task for an incident that references a "business service offering"? We would have to modify the task form layout to show "service" and "service offering". I can see that the key is the CI; where I put an Application Service in the CI field I can look up the dependency map to identify a Technical Service Offering.  This seems like a lot of clicks and will drive agents mad especially ones who do not have an in-depth understanding of CSDM which most will not. Thoughts?

Thanks kindly,

[Mathew Hillyard]

@Karl Rohde 

Incident Management can be accessed by a range of different use cases - helpdesk walk-ins, self-service, automation and integration and event management, among others. Therefore it makes most sense not to limit what offerings can be chosen to just Business Service Offerings. So long as the customer uses a sensible and communicated naming convention, and appropriate enablement, it should be relatively easy to find the right offering.

For Incident/Problem Tasks, these would usually reference a CI as you mention. This could be a Service, Offering, App Service or CI. Rather than over-complicate (and customise) the form and associated logic, use the parent Incident for the (Business or Technical) Service part and use the CI reference for the object that is most useful to the Task. The agent can always look up the Incident fields via popup.

[Karl Rohde]

To ensure the CI field is aligned with the Service Offering, we would need to modify the filter of the CI field, correct? Based on what you're saying above I think it would look something like this:

• Display hardware CI's and Application Services
• If a Service Offering is populated display hardware CI's and Application Services only where a CMDB relationship exists with the Service Offering.

Can someone confirm or advise on this?

[Chris Shakespea]

Recommend that the CI field is configured such that the Service / Service Offering is not selectable in that field. This can be done through the Principal Class Filter.

Some further details in https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=606d1ad94772f594c00af235126d4312&n...

[Robert Duca]

Question on scenario one above. Why on the form for an 'end user device' issue would an offering of 'adobe acrobat' being selected as the offering? 

I would think the offering would be something like 'hardware support' or something no?

[Chris Shakespea]

I did get asked the question - 

How does the SD retain initial ownership if we populate the Incident ticket with the Support group (Tier 2)?

In the article (and ServiceNow default behaviour) is that by selecting the service offering the assignment group gets set to the support group of the service offering.  That group would then work on the incident, ideally to resolution.

The business rule "Populate Assignment Group based on CI/SO" sets the assignment group.

In some cases where you want the service desk to carry on with the work then having the assignment group set this way is not what is required.  The easiest way to do this is that the agent sets the assignment group to the service desk group and then saves the incident.  This prevents the assignment group being populated from the support group.