ITSM Building Blocks - Identify Foundation Data! Implementation Consideration!

[ersureshbe]

Use Case: Kick Start ITSM Solution within ServiceNow. What foundational data should be taken into account to establish a Minimum Viable Product (MVP) delivery?

Description: The specified use case is relevant when the customer is undertaking a migration to ServiceNow from a legacy ITSM system, specifically transitioning from Back 2 Box SN to ServiceNow as part of a re-platforming initiative. The foundational data referenced is instrumental in achieving the minimum viable product (MVP) based engagements.

Please find below the checklist of 'Foundation Data'

1. User:
To utilize the ServiceNow platform, it is essential for a user to possess a record in the user table. Users may be categorized as either Customers—External or Internal—or as End Users. The corresponding user record will be established in the sys_user table. In instances where a user lacks an entry in the sys_user table, they will be classified as a 'Generic User.'

As a best practice in business operations, the creation of tickets in ServiceNow should be limited. However, certain business scenarios allow for exceptions, permitting ticket creation within the platform. User information will be reflected in each ticket under the fields Caller, Requested By, Requested For, and others.

2. User Associated Data (Skills, Company, Department, Location, Delegates):
When a user entry is created in the sys_user table, it is linked to various child tables. This linkage is commonly referred to as the 'Meta Data' of the user. Such meta data is essential for comprehensively understanding the user's details. It aids in:

i. Identifying areas where efforts should be concentrated to decrease ticket volume,
ii. Determining alternative personnel who can assume secondary roles in the absence of the primary authority,
iii. Controlling data visibility,
iv. Generating reports that facilitate the identification of ticket counts, among other real-time applications.

The following tables are integral to the user table's meta data structure: cmn_skill, cmn_company, cmn_department, and cmn_location. When appropriate values are populated in these tables, they seamlessly map to the user table and support the aforementioned use cases.

3. Group:
It is also called as "resolver group." When an issue is transformed into a ticket, it is subsequently assigned to this group. Once the ticket is allocated, all members of the group collaborate to address the ticket, either by providing an appropriate workaround or identifying the root cause. This group is also considered a piece of metadata associated with the user, as it is linked to 'sys_user_group.'

Access to this group is restricted to support users, excluding end users. Access to the 'Resolver Group' is typically granted to individuals who possess an 'ITIL'  role and have an 'admin' role mapping.

4. Roles:
Roles play a significant role in ServiceNow. They assist in categorizing users into various types, such as end users, support users, and approvers. According to the out-of-the-box (OOB) configuration, licenses are governed by these roles, which are referred to as role-based licenses. ServiceNow consistently operates with 'fixed' roles, and there is no provision for 'floating' roles within the platform.

There are 2 categories of roles:
a. OOB Roles - These are available upon the installation of plugins.
b. Custom Roles - These are created based on specific business needs, allowing for the creation of numerous custom roles to meet organizational requirements. The roles are managed under 'sys_user_role' table.

5. CI / Assets:
The assets and Configuration Items (CIs) serve as the fundamental components of your platform. These CIs and assets are consolidated within a single repository known as the Configuration Management Database (CMDB). When a ticket is generated, it is associated with the relevant CI or asset, facilitating a comprehensive understanding of the issue at hand, including which CIs or assets are affected and their respective locations.

Configuration and assets are organized within distinct tables, with numerous CI and asset tables existing within the ServiceNow environment. However, all of these tables are derived from the primary tables, namely cmdb_ci and alm_asset.

6. SLA Definitions:

The definition of the Service Level Agreement (SLA) is designed to ensure that tickets are addressed and resolved promptly. This framework contributes to enhancing customer satisfaction. The efficiency of the resolver is measured by the speed at which they respond to and resolve the ticket once it has been created. ServiceNow facilitates the establishment of both Response SLA and Resolution SLA.

The 'contract_sla' table underpins these SLAs through the utilization of the 'Target' field. It is essential for business stakeholders to confirm the conditions under which the SLA should commence, conclude, pause, or be reset. All of these parameters are configured within the 'contract_sla' table itself.

7. SLA Metrics:

Many customers desire visibility into the ticket details for each state, specifically regarding the time spent with each resolver group and technician. I have encountered several use cases in real-time, including:
i. A ticket where the Service Level Agreement (SLA) was breached, leading to its reassignment to the appropriate queue.
ii. A situation where the SLA was on the verge of breaching within a short timeframe, prompting its reassignment to the correct queue.

The solutions for these use cases are organized within the 'metric_definition' table.

8. Notification Templates:

A business user, whether an internal or external customer, has submitted a ticket, and it is essential for them to comprehend the ticket status through email notifications. The out-of-the-box (OOB) system provides its own templates; however, each business utilizes its own specific template and anticipates that these templates will be aligned with the ServiceNow notification templates.

In this scenario, it is necessary to gather the templates corresponding to each ticket status and establish the configuration within the 'sysevent_email_action' table.

9. Auto Assignment:

When a ticket is generated by a requester or the ServiceDesk via omni channels, it should be automatically assigned to ensure a quicker response and resolution. The routing of the ticket should be determined by its category, subcategory, business unit, department, and other relevant factors, directing it to the appropriate queue. This logic is constructed based on the 'dl_u_assignment' table.

10. Branding:

This functionality allows for the presentation of customer logos within ServiceNow. Modifications to customer slogans, logos, and other related elements can be made in the 'system_properties_ui' table.

11. Knowledge Articles:

It facilitates a more expedited resolution and response from the perspective of the agent or resolver. The knowledge articles can be accessed through the following URL, which enables users to select the relevant category of the knowledge article. Depending on the chosen category, it directs the user to the corresponding table.
https://instance-name.service-now.com/now/nav/ui/classic/params/target/wizard_view.do

Furthermore, the requester has the option to resolve the issue without the necessity of creating a ticket.

12. Category, Sub Categories - Incident & SR:

Determine the appropriate business category and subcategory for customer tickets, and configure them within the relevant module such as incident, change, problem, service requests, or task, among others.

13. Templates - Incident, Change, Task and Case:

The system facilitates the resolution of challenges faced by agents in ticket creation. It enables agents to generate tickets in a brief period. The templates are developed and revised in accordance with the 'sys_template' table.

14. Key Performance Indicators - KPIs:

Every organization possesses its own set of business Key Performance Indicators (KPIs). However, ServiceNow offers a selection of default KPIs out of the box (OOB). If these default KPIs do not meet specific needs, it is advisable to reference the OOB options and develop KPIs tailored to the business requirements. For further understanding of the OOB KPIs, please refer to the following link:

https://Instance-name.service-now.com/now/workspace/agent/analytics_center

15. Attachment Size and Type:

The type and size of attachments will be managed through the ServiceNow system properties. Kindly refer to the links provided below for further information.

Attachment Types  | Attachment Size 

16. Approvals:

Approval assists in validating the issues documented in the tickets. This is particularly relevant for tickets related to costs, business criticality, and similar factors. It primarily pertains to Change and Service Request tickets.It is governed by the principles of Workflow and Flow Designer.

17. Integration Data Points:

Examine the integration of the target system and seek clarification regarding whether the integration is uni-directional or bi-directional. Gain an understanding of the various integration methodologies pertinent to the target system. Utilize the provided link to facilitate the integration process. Gather essential information such as endpoint URLs, service accounts, and requirements for mid-server installation.

18. Surveys:

The ServiceNow out-of-the-box (OOB) solution offers a set of default survey questions. While some customers may choose to utilize these default options, a greater number prefer to tailor the survey questions to meet specific business needs.

It is advisable to gather the desired survey questions and set them up using the survey designer. Furthermore, it is essential to establish the appropriate trigger conditions. Please refer to the provided link for detailed configuration steps.

19. Data Visibility:

Data security plays a crucial role in the management of information across various business units, roles, and operating companies. The following out-of-the-box (OOB) capabilities are utilized to ensure effective data security:

1. Domain Separation
2. Query Business Rule
3. Access Control Lists (ACLs)
4. ServiceNow Vault

Among these four options, it is essential to identify and implement those that align with the specific business requirements of the customer within the operational framework.

20. Cost Center:

The financial framework for information technology is organized in conjunction with catalogues to facilitate the procurement of laptops, desktops, and associated expense lines related to requests. The expenses are recorded in the 'cmn_cost_center' table. Configuration will be carried out with the assistance of key business stakeholders. It is essential to distribute the Excel template and gather the necessary information for the configuration process.

21. Holiday Calendar:

The customer holiday calendar will be managed according to geographic location. It will be administered and regulated via the 'cmn_schedule' table.

#servicenow #foundationdata #itsm #itsmbuildingblock #mvpdelivery #coremealitsm

Hope you like it. If any questions or remarks, let me know!

If this helped you in any way, I would appreciate it if you hit bookmark or mark it as helpful.

Regards,

Suresh.

[Sujatha V M]

Thanks for taking time and mentioning the details elaborately! Very nice articl