ServiceNow Project Kickstart Foundation Prerequisite

[hharshkumar]

ServiceNow Project Kickstart Foundation Prerequisite. and incident module prerequisites

[Tanushree Maiti · Accepted solution]

Hi @hharshkumar 

Based on my understanding, the following areas need to be considered before setting up the Incident module:

1. Foundation Data
   Before setting up the Incident module, the required foundational data should be populated in the ServiceNow base tables, such as sys_user, sys_user_group, cmn_location, etc.
2. Roles and Access
   Define the appropriate roles for Support Desk users, Fulfillment users, and other relevant users. The corresponding ACLs should also be configured based on the required access levels.
3. CMDB Data
   The required CMDB data should be populated and maintained so that Configuration Items (CIs) / impacted services etc. can be properly associated with incidents.
4. Priority Lookup
   Based on the business requirements, define the priority determination rules/lookup logic for incidents.
5. SLA Configuration
   Define the response and resolution SLAs for incidents based on the applicable priority levels and business requirements.
6. Categorization
   Define the Incident Category and Sub-category structure according to the business requirements.
7. Auto-Assignment (Optional)
   If incidents need to be automatically assigned based on the selected CI or other criteria, the required Assignment Groups and assignment rules should be configured accordingly.

[yashkamde]

Hello @hharshkumar ,

If talking specifically about Incident Management prerequisites :

1) Unique Identification Each incident should have a system-generated unique ID (e.g., INC0010023) to track and reference the case from start to finish.

2)Incident Logging Users must be able to report incidents through multiple channels: Self-service portal Email or phone to the Service Desk API/system integration Logging must include caller info, date/time, impact details, and a brief description.

3) Categorization & Prioritization Every incident should be assigned a Category, Impact, and Urgency, which together calculate Priority — guiding SLA targets and assignment rules.

4) Assignment & Ownership Incidents must be routed to appropriate resolver groups with clear accountability. Automatic or manual assignment rules should be implemented.

5) SLA Monitoring Each incident should track response and resolution times using SLAs, with escalation paths if thresholds are missed.

6) Status Communication Real-time status updates should be shared with users as the incident progresses through states like New, In Progress, Resolved, and Closed.

Also for ServiceNow and ITSM you may refer this : 

https://www.servicenow.com/community/training-and-certifications/mandatory-prerequisites/m-p/2600039 

If my response helped mark as helpful and accept the solution.

[Dr Atul - LNG]

Hi @hharshkumar 

ServiceNow Project Discovery Approach

When starting any ServiceNow project, I believe there are three fundamental areas that need to be understood before we begin designing or configuring the platform:

1. Process

2. Data

3. TO-BE / Future State

The objective is not to immediately replicate the client's existing process in ServiceNow. Instead, we need to understand how the business operates today, identify gaps and opportunities, and then determine how the process should work in ServiceNow using platform capabilities and best practices.

---

1. Understand the Current Process

The first step is to understand the AS-IS process.

We need to establish:

• What business process is currently being used?

• How does the client perform the process today?

• Who is involved at each stage?

• What are the inputs and outputs?

• What decisions or approvals are required?

• What are the pain points and gaps?

• Where are manual activities taking place?

• What is working well today?

• What is not working well?

Once we understand the current process, we can compare it against what is currently available in ServiceNow.

The key question is:

What does the client do today, and how does ServiceNow support that process out of the box?

We should identify:

• What ServiceNow already provides OOTB (out of the box)

• Where the client's current process differs from the ServiceNow OOTB process

• Whether those differences are genuinely required

• Whether the client can adopt the ServiceNow OOTB approach

• Where configuration or customisation may actually be required

The OOTB capability should be the starting point rather than immediately designing a custom solution.

The outcome of this stage should be a clear AS-IS vs ServiceNow OOTB gap analysis that can be discussed with the client.

---

2. Understand and Validate the Data

The second fundamental area is data.

Even if the process is designed correctly, the solution will not work as expected if the underlying data is incorrect, incomplete or poorly structured.

We therefore need to understand what data the process depends upon.

For example:

• Users

• User groups

• Locations

• Companies

• Departments

• Categories

• Subcategories

• Configuration Items (CIs)

• Services

• Service offerings

• Assignment groups

• Approvers

• Cost centres

• Other reference/master data

We need to establish:

• What data currently exists?

• Where does the data come from?

• Who owns it?

• Is it accurate?

• Is it complete?

• How frequently is it updated?

• Is it already available in ServiceNow?

• Does ServiceNow have the correct relationships between the data?

• What data needs to be cleansed or created?

• What integrations are required?

A key principle is:

Data is foundational to the process.

For example, if the correct users, groups, locations, CIs or categories do not exist, then assignment, routing, approvals, reporting, notifications and automation may not work as intended.

Therefore, data discovery should happen early rather than being treated as something that can be resolved at the end of the project.

---

3. Define the TO-BE Process

Once we understand the current process and the underlying data, we can define the TO-BE process.

The TO-BE process should not simply reproduce the existing process in ServiceNow.

Instead, we should ask:

What should the process look like in the future, using ServiceNow capabilities and best practices?

The TO-BE design should consider:

• ServiceNow OOTB capabilities

• Simplification of the current process

• Automation opportunities

• Roles and responsibilities

• Approvals

• Assignment and routing

• SLAs

• Notifications

• Escalations

• Integrations

• Reporting

• Auditability

• Governance

• User experience

• Future scalability

The design should favour configuration over customisation wherever possible.

Where the client's existing process differs from the ServiceNow OOTB process, the difference should be understood and challenged rather than automatically reproduced.

---

Recommended Discovery Sequence

I would therefore use the following sequence for ServiceNow projects:

1. AS-IS Process

Understand what the business does today.

↓

2. ServiceNow OOTB

Understand how ServiceNow supports the process out of the box.

↓

3. Gap Analysis

Identify the differences and determine which gaps genuinely require addressing.

↓

4. Data

Validate the data required to support the process.

↓

5. TO-BE Process

Design the future process using ServiceNow capabilities and best practice.

↓

6. Solution Design

Determine configuration, automation, integrations and any justified customisation.

---

Example: Incident Management

The same approach can be applied to something like Incident Management.

AS-IS

Understand:

• How incidents are currently raised

• How they are categorised

• How priority is determined

• How incidents are assigned

• How escalation works

• How SLAs are managed

• How communication happens

• How incidents are resolved and closed

ServiceNow OOTB

Review what ServiceNow already provides for:

• Incident creation

• Assignment groups

• Categorisation

• Priority

• SLAs

• Notifications

• Escalations

• Knowledge

• Major Incident Management

• Resolution

• Closure

• Reporting

Gap Analysis

Determine:

• Which requirements are already available OOTB

• Which requirements can be achieved through configuration

• Which processes should change

• Which requirements genuinely need customisation

Data

Validate:

• Users

• Groups

• Locations

• Companies

• CIs

• Services

• Categories

• Assignment groups

• Service owners

TO-BE

Design the future Incident Management process around the ServiceNow model, incorporating the client's legitimate business requirements while avoiding unnecessary customisation.

---

The Core Principle

The approach can be summarised very simply:

Process first. Data second. TO-BE third. Technology follows.

We should not start a ServiceNow project by asking:

"How do we build what the client currently does?"

We should start by asking:

"What does the client do today, what does ServiceNow provide OOTB, what are the gaps, what data is required, and what should the future process look like?"

This approach helps ensure that ServiceNow is being used as a platform to improve and standardise the business process, rather than simply becoming a replacement interface for an existing process.

It also provides a strong foundation for subsequent design decisions around SLAs, notifications, approvals, automation, integrations, reporting and governance.