Incident Management
Implementing Incident Management in ASM - From the beginning
Last updated
Was this helpful?
Implementing Incident Management in ASM - From the beginning
Last updated
Was this helpful?
Audience: Incident Manager, Service Desk Manager, Service Delivery Manager, Alemba Service Manager Administrator(s)
Time to Complete: Varies, Average 3-5 days (Including screens build and UAT)
Incident Management in ITIL V4 aims to restore normal service operation as quickly as possible while minimizing the impact on the business. It emphasizes a systematic approach where incidents are logged, prioritized based on urgency and impact, and resolved or escalated as needed. Key stages in the Incident Management process include identification, recording, analysis and diagnosis, resolution and recovery, and closure.
Incident Management involves more than just handling individual incidents; it encompasses a spectrum of related ticket types, including Problems, Known Errors, and Major Incidents.
Here's why these are included:
Unified Approach: By managing all related ticket types within a single framework, organizations can ensure consistency and thoroughness in their incident response strategies.
Root Cause Analysis: Problems are investigated to find the root cause of Incidents, facilitating long-term solutions rather than temporary fixes.
Proactive Management: Known Errors allow for preemptive identification and documentation of issues, improving response times for recurring incidents.
High Impact Incidents: Major Incidents represent a collection of related incidents with significant business impact, necessitating prioritized and coordinated response efforts.
Implementing and configuring these ticket types in Incident Management processes streamlines workflow, enhancing efficiency and ensuring comprehensive service delivery.
The IPK Tiers in ASM align with ITIL V4 by structuring incidents into manageable categories—Incidents, Problems, Major Incidents, and Known Errors primarily (I-P-K), but you are also able to define your own. ASM supports incident management through its integration of IPK tiers, enabling efficient tracking, matching, and resolving of incidents. Moreover, it enables the identification of potential problems early, thus facilitating proactive measures.
To understand this system better, you should have an understanding of the tiers, specifically, Incidents and Problems as this is where most organizations choose to start.
Incidents are call records ("tickets") where a fault (about a service) reported by a User is logged. The objective is to get the User’s issue resolved.
When a number of Incidents pertaining to the same service is logged, one of them is promoted to a Major Incident.
A Major Incident occurs when the impact of a fault affects a number of Users.
Problems are logged when they require an investigation to determine the cause of an Incident. The objective is to get the service operational. Problems can also be logged proactively, before there is an impact to your user(s).
When the cause is identified and a Request for Change is initiated to rectify the issue if appropriate,
a Problem record can be converted to or cloned to a Known Error.
Using this concept, when an Analyst logs a new Incident, the Incident is matched against existing Incidents, Problems, and Known Errors. Available workarounds are applied to ensure that the Incident is resolved quickly. The benefits that this approach provides include an improvement in the quality of service provided by the service desk, a reduction in the turnaround time in providing a resolution, and subsequently reducing the volume of Incidents logged.
IPK Streams take the Tiers one step further. You can define your IPK Streams (such as "Support", "Cyber-Security", "Facilities", and/or "HR") and link them to IPK Statuses (including Incident, Major Incident and Problem). You would then have Security Incidents, HR Incidents, Support Incidents, or Facilities Incidents. If this level of separation is not necessary, you need not configure them. One stream is typically sufficient and most organizations use the ASM Field for 'Type Tier' instead to further classify the ticket.
When Analysts log a call in ASM Core, they can select the IPK status and a corresponding stream for the call. For example, if you create two IPK streams, Cyber-Security, and Support, and link both streams to the IPK status, Incident, when an analyst logs a call as an Incident, they will be able to select either Cyber-Security or Support as the stream.
The purpose of defining streams and linking them to statuses is the following:
to make only specific streams available to particular IPK statuses
to simplify the call logging process by allowing you to configure your call logging screen based on an IPK status/stream/type combination
to allow you to restrict access to the streams to which an Analyst has access through their IPK security role
For a specific call screen to be displayed for an IPK Stream, the call screen set must be linked to the IPK stream through the matrix on either the Link Stream/Status to Call Screen Set, or Link Type/Stream/Status to Call Screen Set window. The matrix you will use will depend on your IPK Settings.
