Best practice for using Service and CI fields together on Incident form?

[anand9]

Setting up context:- In considering the CSDM aspect, I am interested in understanding how ServiceNow and CI fields are used together. As organizations mature, they often begin utilizing a range of different products, such as Service Portfolio Management, Digital Portfolio Management, Vendor Management etc. The way in which Incident has been used in the past few years can be crucial for new products to efficiently access and utilize old incident data. Therefore, it is essential to properly utilize these fields from the outset.

Questions:-

1. If I have issue with "Leave Management Service" (Application Service), should I create incident with CI as application service? Or should I set application service in service field and use CI to pin point any specific CI part (like database server) of Leave Management deployed stack?
   
   if I use Service=Application Service, then this impact the reporting capability in other product. For example:-Digital Portfolio Management reports any incident under "run" tab only if the application service is associated with "CI" field (and not Service field, or affected/impacted service related list - is it not suppose to?). 
   If I use CI=Application Service, then what do I use service field for? or are we suppose to use only BS and TS in Service field?
2. Making Service and Service Offering mandatory - If you use Service Portfolio management or Vendor Management, have you made these fields mandatory to ensure accurate reporting?
3. How do I ensure Services and CI are related to each other? - Have you done any customization to ensure that CI selected is part of selected service dependency view to avoid data inconsistency? I understand not all the time selected CI will be part of dependency view, but trying to understand if someone made any effort?
4. Service for My asset issue - If I have issue with my laptop, my computer CI will be selected in CI field. what would be service field value? I am assuming it would be "IT Support" service and Service Offering depending on nature of issue (like hardware SO, software SO). How is it setup in your organization?
5. Is "IT Support" service example of BS or TS and why?

Thanks.

#CSDM

[Barry Kant · Accepted solution]

Hi,

lot of questions, 🙂 Hope this will help a bit.

see comments in line:

1. If I have issue with "Leave Management Service" (Application Service), should I create incident with CI as application service? Or should I set application service in service field and use CI to pin point any specific CI part (like database server) of Leave Management deployed stack?
   
   if I use Service=Application Service, then this impact the reporting capability in other product. For example:-Digital Portfolio Management reports any incident under "run" tab only if the application service is associated with "CI" field (and not Service field, or affected/impacted service related list - is it not suppose to?). 
   If I use CI=Application Service, then what do I use service field for? or are we suppose to use only BS and TS in Service field?
   An Application Service is a realized solution (can be dev, test, prod etc). The Business Service Offering(s) is/are how this is offered for consumption. The Business Service is parenting the Offering. 
   The Application Service will be in the Configuration Item field in the incident. The Application Service is in general the level of knowledge an end user might know if it comes to CIs. Continuing troubleshooting the root-cause might be some downstream CI. 
2. Making Service and Service Offering mandatory - If you use Service Portfolio management or Vendor Management, have you made these fields mandatory to ensure accurate reporting?
   Yes, at least when resolving an incident, however it would be kind of minimum input to start with for the first receiving party. 
3. How do I ensure Services and CI are related to each other? - Have you done any customization to ensure that CI selected is part of selected service dependency view to avoid data inconsistency? I understand not all the time selected CI will be part of dependency view, but trying to understand if someone made any effort?
   Services are parenting Service Offerings.
   Service Offerings have a depends on CI Relation to Application Services. 
   Application Services are supported by Applications and Infratructure.
   I would prefer to use the relations to look for a small set of supporting CIs. In big environments the CI Relations might be enormous. Then the Application Service of type Dynamic Service might help to flatten out a number of levels CI Relations. That way it becomes faster. 
4. Service for My asset issue - If I have issue with my laptop, my computer CI will be selected in CI field. what would be service field value? I am assuming it would be "IT Support" service and Service Offering depending on nature of issue (like hardware SO, software SO). How is it setup in your organization?
   Might be something like: End User Services > Workplace Solutions > Compute 
5. Is "IT Support" service example of BS or TS and why?
   Yes that could be a Technical service. BS are consumed Services, TS are managed Service (support)
   
   BR,
   
   Barry

[anand9]

Hello Barry, Thanks a lot. This will help me. So basically what I understand is - in more mature environment (CSDM -run/fly), probably its best to filter out the AS in Service field, and allow only TS and BS for selection.

[Barry Kant]

that is correct

[Jim Zeigler1]

I disagree.

In a mature environment(with ITOM Visibility and Event Management), if the Incident originated from operational infrastructure or applications (for example, an alert associated with a server or an application running on the server), you will want the Application Service on the incident Form.  SPM services don't show up on any of the operational dashboards used to resolve incidents.

If a low level CI alerts and a Service Map exists for the Application Services that depend on the CI, the Application Services should appear on the list of affected Services and be highlighted  because alerts are dynamically propagation up the ITOM Service hierarchy(consisting of Application Services and Application Service groups).

I would only add an SPM Service to the incident form if the incident concerns the Service Catalog (in which case the SPM Service or Service Offering might be the configuration Item for the incident). In my experience, most customers filter out SPM Services so they don't appear in the dropdown for the Service field. If you check the dictionary, the Column name for many of the "Service" fields on the task forms is business_service. It was always a reference to an Application Service (Application Services were always called Business Services before the Rome release).