Incident Management Process

PURPOSESCOPEPROCESS DESCRIPTIONROLES AND RESPONSIBILITIESSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owner: VP, Information Technology

Note: An owner must be a PCES-level manager.

This process establishes standard tools and processes for incident management within the Postal Service Technical Environment.

PURPOSE

This process is a structured set of activities designed to accomplish a defined objective.

All Incidents are reported through the approved Incident management software. This process focuses on reporting and resolving Incidents reported through the approved Incident management software.

SCOPE

The Incident Management process applies to all Postal Service employees, contracted vendors, and organizations who report Incidents through the approved Incident management software. It ensures Incidents are managed in a uniform and predictable manner.

Transition

Incident Management replaces Help Desk tickets. This process includes:

PROCESS DESCRIPTION

Incident Management cases are created to restore a service as quickly as possible. Incidents may be transitioned to:

Note: Change Management or Release Management may generate Incidents.

Recording Incidents

Before you begin: To record an Incident in the approved Incident Management software, you must have access to the software. To gain access to Incident Management, submit an eAccess request and select the Incident module.

Assigning, Managing, and Resolving Incidents

The sections outlined below provide a high-level overview of the Incident Management process.

  1. Incident Identification and Logging.

    The Service Desk Analyst receives and logs the incident through an approved method.

  2. Incident Categorization and Prioritization.

    The Service Desk Analyst assigns impact and urgency to the incident.

  3. Initial Diagnosis and Escalation.

    The Service Desk Analyst determines whether the incident can be resolved by the Service Desk or whether escalation to Technical Support is required. If the incident priority is critical (major), the Critical (Major) Incident Process is followed.

  4. Investigation and Diagnosis.

    The Service Desk Analyst or Technical Support assesses the incident, escalates it if necessary, and communicates status to users impacted by the incident.

  5. Resolution and Recovery.

    The Service Desk Analyst or Technical Support analyzes the incident, applies a resolution, and notifies users of the resolution.

  6. Incident Closure.

    The Service Desk Analyst or Technical Support confirms the resolution with the originator and completes the incident. The incident is automatically closed after seven days of inactivity.

  7. Incident Reopening.

    The Service Desk Analyst may reopen an incident up to seven days after incident resolution. Once the incident is closed, it cannot be reopened.

Communicating Incidents

The Incident Management software provides a notification of the status of the Incident.

Critical (Major) Incident Process

A critical (major) incident has significant impact or urgency for the business and demands a response beyond the routine incident management process. An incident can be declared critical (major) only for applications in Tier 1 (business critical production services) and Tier 2 (high level support services). One of the following must be true:

The process is as follows:                                   

  1. The Service Desk Analyst identifies the business impact and the support teams required for resolution.

  2. When the incident is opened, the tool notifies the CIO of the incident.

  3. The Critical (Major) Incident Validator determines whether the incident meets the criteria for a critical (major) incident and engages support teams (which may include the Crisis Team and Technical Support) as required.

  4. The process continues through Resolution and Recovery.

ROLES AND RESPONSIBILITIES

Defined roles and responsibilities are key elements to the effective execution of the incident management process. Roles reflect a functional group of logical responsibilities for a given process. Responsibilities reflect the assignment of a set of duties to be implemented to complete an Incident request. Users may be assigned one or more roles.

Crisis Team

Critical (Major) Incident Manager

Critical (Major) Incident Validation Team

Critical (Major) Incident Validator

End User

Process (Incident) Manager

Process Owner

Service Desk Analyst (Level 1 Support)

Service Desk Management Team

Service Manager

Service Owner

Technical Support (Tier 2 and Tier 3)

SUPPORTING DOCUMENTATION

Access Supporting Documentation from ITWEB (internal):

Access Supporting Documentation from USPS.com (external):

REVISION HISTORY

Version
Date
Description
1.0 10.07.2011 Initial release
2.0 09.20.2012

Supporting Documentation: Changed "IT Service Operation Prioritization Configuration" link to "Incident Management Prioritization Configuration."

Note: This document was made Section 508 compliant and was converted to HTML.

2.1 07.25.2014 Supporting Documentation: Created redirect link from ITWEB and updated Supporting Documentation hyperlinks, so document is only published on USPS.com.
3.0 12.08.2016

Updates:

  • Updated Assigning, Managing, and Restoring Incidents to include seven high-level steps.
  • Added a new section: Critical (Major) Incident Process.
  • Replaced roles and responsibilities with a new set to coincide with the latest incident management tool.
  • Removed the Incident Management User Guide as a supporting document.

CR #234566

Powered By OneLink