Management Summary in Service Now

Okay, here's a detailed breakdown of key IT Service Management (ITSM) processes within ServiceNow, presented in Markdown format with examples. This covers Incident, Problem, Change, Request, Configuration, and Knowledge Management.

ServiceNow ITSM Processes - Detailed Notes

1. Incident Management

• Definition: The process of restoring normal service operation as quickly as possible after an unplanned interruption (an incident) and minimizing the adverse impact on business operations. The focus is on speed of resolution.

• Key Concepts:

  • Incident: An unplanned interruption to an IT service or a reduction in the quality of an IT service. Failure of a Configuration Item (CI) that has not yet impacted service is also an incident (e.g., failure of one disk in a mirrored set).
  • Priority: Determined by a combination of Impact (the effect on the business) and Urgency (how quickly resolution is needed). A matrix is often used (e.g., High Impact + High Urgency = Priority 1).
  • Service Level Agreement (SLA): A contract between the IT service provider and the customer that defines expected service levels (including incident resolution times). ServiceNow tracks SLAs and can trigger alerts/escalations if they are breached.
  • Major Incident: A high-impact, high-urgency incident that requires a dedicated, coordinated response. ServiceNow has specific major incident management capabilities.
  • Incident Task: Smaller tasks that may be created to help resolve a larger incident.

• Process Flow (Simplified):

  1. Identification & Logging: The incident is reported (by a user, monitoring system, etc.) and logged in ServiceNow. Key information is captured (caller, description, affected CI, etc.).
  2. Categorization & Prioritization: The incident is categorized (e.g., "Software," "Hardware," "Network") and prioritized based on impact and urgency.
  3. Initial Diagnosis: The assigned technician attempts to diagnose the issue, often using the Knowledge Base.
  4. Escalation (if needed): If the initial technician cannot resolve the incident, it's escalated to a higher-level support group or specialist.
  5. Investigation & Diagnosis: Further investigation and diagnosis are performed.
  6. Resolution & Recovery: The underlying cause is addressed, and service is restored.
  7. Incident Closure: The incident is closed, with details of the resolution documented. The user is notified.

• Example:

  • Incident: A user reports that they cannot access their email.
  • Logging: The user calls the service desk, and an agent creates an incident record in ServiceNow. The agent captures the user's details, a description of the problem ("Cannot access email"), and the affected service ("Email").
  • Categorization: The agent categorizes the incident as "Software" and subcategory "Email Client."
  • Prioritization: The agent determines the priority as "Medium" (impacts a single user, but email is business-critical).
  • Diagnosis: The agent checks the Knowledge Base for known issues with email access.
  • Resolution: The agent discovers that the user's email password has expired. The agent resets the password, and the user confirms they can now access their email.
  • Closure: The agent closes the incident, documenting the resolution ("Password reset").

• ServiceNow Features:

  • Incident form (highly customizable).
  • Assignment rules (automatically route incidents to the correct support group).
  • SLA management.
  • Major incident management.
  • Integration with other modules (Problem, Change, Knowledge).
  • Reporting and dashboards.

2. Problem Management

• Definition: The process of identifying and managing the root causes of incidents to prevent recurrence. While Incident Management focuses on restoring service, Problem Management focuses on preventing future incidents.

• Key Concepts:

  • Problem: The unknown underlying cause of one or more incidents.
  • Known Error: A problem with a documented root cause and a workaround.
  • Workaround: A temporary way to restore service or reduce the impact of an incident, even if the root cause is not yet resolved.
  • Problem Task: Tasks assigned to investigate the problem and identify the root cause.
  • Root Cause Analysis (RCA): The process of identifying the underlying cause of a problem. Techniques include 5 Whys, Ishikawa (fishbone) diagrams, etc.

• Process Flow (Simplified):

  1. Problem Identification: Problems can be identified proactively (e.g., through trend analysis) or reactively (e.g., after multiple similar incidents).
  2. Problem Logging: A problem record is created in ServiceNow.
  3. Categorization & Prioritization: The problem is categorized and prioritized.
  4. Investigation & Diagnosis: The problem team investigates the problem, often using data from related incidents.
  5. Root Cause Identification: The underlying cause of the problem is identified.
  6. Known Error Creation (if applicable): If a workaround is found, a known error record is created and linked to the problem.
  7. Resolution (via Change Management): A change request is typically created to implement a permanent fix for the problem.
  8. Problem Closure: The problem record is closed after the change has been successfully implemented and verified.

• Example:

  • Incident: Multiple users report intermittent network connectivity issues.
  • Problem Identification: The service desk notices a trend of similar incidents and creates a problem record.
  • Investigation: The problem team investigates and discovers that a faulty network switch is causing packet loss.
  • Known Error: A workaround is identified (rebooting the switch temporarily restores connectivity). A known error record is created.
  • Resolution: A change request is created to replace the faulty network switch.
  • Problem Closure: After the switch is replaced and the network is stable, the problem record is closed.

• ServiceNow Features:

  • Problem form.
  • Relationship to incidents (one problem can be linked to many incidents).
  • Known error database.
  • Problem task management.
  • Integration with Change Management.
  • Reporting and dashboards.

3. Change Management

• Definition: The process of controlling the lifecycle of all changes to the IT infrastructure and services, minimizing disruption and ensuring that changes are implemented in a controlled and authorized manner.

• Key Concepts:

  • Change: The addition, modification, or removal of anything that could have an effect on IT services.
  • Change Request (RFC): A formal request to make a change.
  • Change Types:
    • Standard Change: Pre-authorized, low-risk, repeatable change (e.g., password reset, software installation from a catalog).
    • Normal Change: A change that follows the full change process (assessment, approval, scheduling, implementation, review).
    • Emergency Change: A change that must be implemented immediately to resolve a major incident or prevent a major incident. Bypasses some of the normal approval steps.
  • Change Advisory Board (CAB): A group of stakeholders who review and approve (or reject) change requests.
  • Change Schedule: A calendar that shows planned changes and maintenance windows.
  • Risk Assessment: Evaluating the potential impact and likelihood of failure of a change.
  • Backout Plan: A plan to revert a change if it fails or causes problems.

• Process Flow (Normal Change - Simplified):

  1. Request for Change (RFC) Creation: A change request is created, documenting the details of the change.
  2. Assessment: The change is assessed for impact, risk, and resource requirements.
  3. Approval: The change request is reviewed and approved by the appropriate authorities (e.g., CAB, technical approvers).
  4. Scheduling: The change is scheduled for implementation, taking into account the change schedule and any dependencies.
  5. Implementation: The change is implemented according to the plan.
  6. Review: The change is reviewed to ensure it was successful and met its objectives.
  7. Closure: The change request is closed.

• Example:

  • Change Request: A request to upgrade the operating system on a group of servers.
  • Assessment: The change team assesses the impact on applications running on the servers, the risk of failure, and the resources required.
  • Approval: The change request is reviewed and approved by the CAB and the application owners.
  • Scheduling: The change is scheduled for a weekend maintenance window to minimize disruption.
  • Implementation: The operating system is upgraded on the servers.
  • Review: The change team verifies that the servers are functioning correctly and that applications are running as expected.
  • Closure: The change request is closed.

• ServiceNow Features:

  • Change request form (highly customizable).
  • Change types (Standard, Normal, Emergency).
  • Workflow-driven approval process.
  • CAB Workbench.
  • Change schedule.
  • Risk assessment tools.
  • Integration with Problem Management and Configuration Management.
  • Reporting and dashboards.

4. Request Management

• Definition: The process of handling service requests from users. A service request is a formal request for something to be provided – a new service, a change to an existing service, information, advice, or access to a service. It's not about fixing something broken (that's Incident Management).

• Key Concepts:

  • Service Request: A request for a pre-defined service or item, often from a service catalog.
  • Request (REQ): The overall request (e.g., "Request for new laptop").
  • Requested Item (RITM): A specific item within the request (e.g., "Dell Latitude 5530").
  • Catalog Task (SCTASK): Tasks assigned to fulfill the request (e.g., "Order laptop," "Configure laptop," "Deliver laptop").
  • Service Catalog: A user-friendly interface where users can browse and request available services and items.

• Process Flow (Simplified):

  1. Request Submission: The user submits a request through the Service Catalog.
  2. Request & RITM Creation: A Request (REQ) and one or more Requested Items (RITM) are created.
  3. Approval (if required): The request may require approval (e.g., manager approval for a new laptop).
  4. Task Assignment: Catalog Tasks (SCTASK) are created and assigned to the appropriate fulfillment teams.
  5. Task Completion: Fulfillment teams complete their assigned tasks.
  6. Request Fulfillment: Once all tasks are complete, the request is fulfilled.
  7. Closure: The RITM and REQ are closed.

• Example:

  • Request: A user requests a new software license through the Service Catalog.
  • RITM: An RITM is created for the specific software license.
  • Approval: The request may require approval from the user's manager.
  • Tasks: Tasks are created for:
    • Procuring the license.
    • Installing the software on the user's computer.
    • Providing the user with license keys.
  • Fulfillment: Once all tasks are complete, the user has the software license and can use the software.

• ServiceNow Features:

  • Service Catalog.
  • Request, RITM, and Catalog Task records.
  • Workflow-driven fulfillment process.
  • Integration with other modules (e.g., Procurement, Asset Management).
  • Reporting and dashboards.

5. Configuration Management

• Definition: The process of identifying, controlling, and tracking all Configuration Items (CIs) in the IT environment, and their relationships. This provides an accurate, up-to-date view of the IT infrastructure.

• Key Concepts:

  • Configuration Item (CI): Any component that needs to be managed in order to deliver IT services. This includes hardware (servers, laptops, network devices), software (applications, operating systems), services, documentation, and even people (in some cases).
  • Configuration Management Database (CMDB): The database that stores information about CIs and their relationships.
  • CI Attributes: Properties of a CI (e.g., serial number, IP address, operating system version).
  • CI Relationships: Connections between CIs (e.g., a server runs an application, an application depends on a database).
  • Discovery: Automated tools that scan the network and identify CIs, populating the CMDB.
  • Baseline: A snapshot of the CMDB at a particular point in time, used for comparison and change tracking.

• Process Flow (Simplified):

  1. Identification: CIs are identified and defined.
  2. Control: Changes to CIs are managed through Change Management.
  3. Status Accounting: The current status of CIs is tracked (e.g., "In Production," "In Maintenance," "Retired").
  4. Verification & Audit: Regular audits are performed to ensure the accuracy of the CMDB.

• Example:

  • CI: A web server (hardware CI).
  • Attributes: Server name, IP address, operating system, installed software, location, owner.
  • Relationships:
    • The web server hosts a web application (software CI).
    • The web application depends on a database server (hardware CI).
    • The web server is connected to a network switch (hardware CI).
  • Discovery: ServiceNow Discovery automatically finds the web server on the network and populates its attributes and relationships in the CMDB.
  • Change Management: If the web server's operating system needs to be upgraded, a change request is created, referencing the CI record in the CMDB.

• ServiceNow Features:

  • CMDB.
  • Discovery.
  • Service Mapping (visual representation of CI relationships).
  • Dependency Views.
  • Integration with other modules (Incident, Problem, Change, Request).
  • Reporting and dashboards.

6. Knowledge Management

• Definition: The process of creating, sharing, using, and managing the knowledge and information within an organization. In the context of ITSM, this focuses on capturing and sharing solutions to incidents and problems, best practices, and other information that can help improve service delivery.

• Key Concepts:

  • Knowledge Base (KB): A repository of articles, FAQs, troubleshooting guides, and other information.
  • Knowledge Article: A document within the Knowledge Base that provides information on a specific topic.
  • Knowledge Categories: A way to organize knowledge articles (e.g., "Hardware," "Software," "Networking").
  • Knowledge Workflow: The process of creating, reviewing, approving, publishing, and retiring knowledge articles.
  • Feedback: Users can provide feedback on knowledge articles (e.g., ratings, comments).

• Process Flow (Simplified):

  1. Creation: A knowledge article is created (often based on a resolved incident or problem).
  2. Review: The article is reviewed for accuracy and completeness.
  3. Approval: The article is approved for publication.
  4. Publication: The article is published to the Knowledge Base.
  5. Usage: Users and IT staff can search and use the knowledge articles.
  6. Feedback & Improvement: Users provide feedback, and articles are updated as needed.
  7. Retirement: Outdated or irrelevant articles are retired.

• Example:

  • Incident: A user reports that they cannot print to a network printer.
  • Resolution: The service desk agent discovers that the printer driver needs to be reinstalled.
  • Knowledge Article: The agent creates a knowledge article titled "How to Reinstall a Network Printer Driver," documenting the steps to resolve the issue.
  • Publication: The article is reviewed, approved, and published to the Knowledge Base.
  • Usage: The next time a user reports a similar issue, the service desk agent can search the Knowledge Base and quickly find the solution.

• ServiceNow Features:

  • Knowledge Base.
  • Knowledge article templates.
  • Workflow-driven review and approval process.
  • Search capabilities.
  • Feedback mechanisms.
  • Integration with Incident and Problem Management.
  • Reporting and dashboards.

Summary Table

This detailed breakdown provides a comprehensive overview of these core ITSM processes within ServiceNow, including their definitions, key concepts, process flows, examples, and key ServiceNow features. This should be a valuable resource for understanding how these processes work together to deliver effective IT services.