.png?width=250&height=56&name=stonewater-logo%20(1).png)
DSP - Incident Management
October 2024 - V1.0
Kevin Blackshaw - Group Head of Service Management
Review Cycle - Annually - Q3
Contents
- Document Control
- Section 1 - Introduction
- Section 2 - Incident Management at DSP
- Section 3 – Incident Resolution and Closure
- Section 4 - Incident Communications
- Section 5 - Incident Priority
- Section 6 - Major Incident Management
- Section 7 - Incident & Problem Management
- Section 8 - DSP & ITIL Aspects of Incident Management
- Section 9 - Incident Management Templates
Confidentiality and Copyright
The information contained in this document is confidential and is issued by DSP on the understanding that it will be used only by the staff of, or consultants to, the Client and where consultants are employed, the use of this information is restricted to use in relation to the business. In particular, the contents of this document may not be disclosed in whole or in part to any other party without the prior written consent of DSP © - Database Service Provider Global Limited. All rights reserved.
Validity of Information
DSP has made every effort to ensure that all statements and information contained herein are accurate as per the document release date. Any questions regarding the content of this document should be directed to our Service Delivery Department - ServiceDelivery@dsp.co.uk
| Version | Date | Update | Owner |
|---|---|---|---|
|
1.0
|
10/10/2024
|
Process live
|
KB
|
Document Review
| Reviewers | Date | Update | Owner |
|---|---|---|---|
|
PA/RS/HM
|
07/10/2024
|
Reviewed and aligned with other DSP Group Processes
|
KB
|
Section 1 - Introduction
Welcome to the DSP Community, we offer award-winning IT consultancy and managed services for Oracle, Microsoft and Google technologies. We specialise in data platform management, application development, engineered systems and Cloud with a strong presence in Oracle RDBMS, OCI, Exadata, SQL Server, Azure, APEX, and GCP. DSP is a leading technology partner in the UK and has been recognised for that by our technology partners and industry through a wide range of awards and accolades.
As a DSP Managed Services Customer – DSP Offer a range of ITIL based processes to provide Customer Excellence and a standardised our approach to our IT Service Management offering. The following document is a brief overview of Incident Management and how the Incident Management Process works at DSP.
If you are interested in learning more than this brief overview please contact your Account Manager.
Section 2 - Incident Management at DSP
Incident Definition
- An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).
The DSP Incident Process governs DSP’s operating procedure for Service Interruptions (Incidents) to client services. DSP Operate separate, but linked, Standard Operating Procedures (or SOPs) for Request Fulfilment, Customer Escalations and Major Incident Management. DSP follow ITIL Guidance and distinguish between Incidents (service interruptions) and Service Requests (customer or user requests that do not represent a service disruption, such as a password reset, request for information or a request for change to a supported service). As such Service interruptions are handled through Incident Management, and Service Requests through Request Fulfilment.
The DSP Incident Management process can be initiated as follows:
- A user, customer or supplier may report an issue either via DSP’s 24x7 Support Telephone Number, via DSP’s 24 x 7 ITSM Portal or via direct engagement with a DSP member of staff (where an Incident will need to be logged following verbal engagement)
- Technical staff may identify a (potential or actual) failure as direct result of proactive maintenance, housekeeping or via data provided in the Health Check Portal
- An Incident may be raised automatically by an event monitoring system
All Incidents are logged as Incident records within DSP’s ITSM toolset where their status can be tracked, as well as their Service Level Agreement (SLA) adherence, and a complete historical record maintained for reporting and auditing purposes. Initial categorisation and prioritisation of Incidents is a critical step for determining how the Incident will be handled and how much time is available for its resolution
Where possible, Incidents should be matched to other Incidents, Problems and Known Errors by the L2 Technical Teams.
In accordance with ITIL best practice DSP defines a standalone process for Major Incident Management. (emergencies that affect business-critical services and processes that require immediate attention). Major Incidents at DSP typically require a temporary Major Incident Team to identify and implement the resolution.
Section 3 – Incident Resolution and Closure
Once Incidents are resolved by the SME and, in agreement with the ticket raiser, the ITSM toolset will automatically close the Incident record after 72 hours. This includes verifying that the users are satisfied and ensuring that the Incident record is fully documented (see Incident Closure and Evaluation below). Any new Problems, Workarounds or Known Errors identified during an Incident’s Life Cycle should be forwarded to the Problem Management process. Where a separate Problem Record is raised. DSP detail the key differences between Incidents and Problems within their Problem Management Process document but have included a brief summary in Section 7.
Findings from the resolution of the Incident are always recorded for future use.
It is imperative incident records are robustly maintained by DSP as the information (updates) within an incident record can be used to:
- Inform on other incidents and incident resolution
- Used for periodic reporting to the customer
- Contributes to trend analysis and problem management
- Demonstrates effective communication and issue management to the customer
- Demonstrate SLA adherence
Section 4 - Incident Communications
In line with DSP's Core Values and deliverying Customer Excellence all DSP Subject Matter Experts (SMEs) are trained to given detailed and cohesive incident updates as per our CANE method below.
However - where a Major Incident is declared a member of the Major Incident Management Team is aligned to the MI alongside all SMEs to provide structure and communications as detailed in DSP's Major Incident Management Process.
C - Current Situation (What are DSP Seeing)
A - Actions (What are DSP Doing)
N - Next Steps (What do DSP Plan to Do)
E - Expectation Setting (When will I be communicating next)
Section 5 - Incident Priority
DSP use four tiers of Incident Priority as defined below
Impact and Urgency Matrix
Impact – how critical the downtime is for the business. Usually, it is measured by the number of impacted users or criticality of a missing key business process (such as bank payments)
Urgency – it is usually defined in SLA for the specific IT service. If more than one service is impacted, parameters for the higher urgency service will be taken into account
Only a P1 can become Major Incident as per the DSP Impact and Urgency Matrix
Section 6 - Major Incident Management
DSP operate a standalone Major Incident Management Process where a customer summary is available here - Major Incident Management.
Section 7 - Incident & Problem Management
Problem Management at DSP is governed by the Problem Management Process as a standalone ITIL process. A customer summary is available here - Problem Management.
Shown below is an extract from DSP Problem Management process highlighting the key differences between an Incident and Problem -
"Problem Management seeks to minimise the adverse impact of Incidents by preventing Incidents from happening. For Incidents that have already occurred, Problem Management tries to prevent these Incidents from happening again.
ITIL defines a "Problem" as "the underlying cause of one or more Incidents".
Problem Management works closely with Incident Management, but it is not the same:
- Incident Management is about restoring services as quickly as possible to ensure business continuity, sometimes by applying temporary solutions (workaround)
- Problem Management is tasked with analysing root causes and preventing Incidents from happening in the future
All Problems should be logged as Problem Records within DSP’s ITSM toolset, where their status can be tracked, and a complete historical record maintained."
Section 8 - DSP & ITIL Aspects of Incident Management
- Incident Logging: When a user or automated monitoring system detects an issue (service interruption), it is reported as an incident. This incident is logged in the DSP ITSM Toolset, which includes details such as the description of the incident, its impact, and the affected services / Configuration Items
- Categorisation and Prioritisation: Incidents are categorised based on their urgency and impact. This categorisation determines the priority of the incident, so that critical incidents with high impact are addressed before those with lower impact.
- Initial Diagnosis and Escalation: The incident is initially diagnosed to understand its cause and potential solution. If the issue cannot be resolved immediately, it might be escalated to higher-level support teams or experts who have the necessary knowledge to address the incident.
- Resolution and Workaround: The incident is worked on to find a solution or workaround that restores the affected IT service to normal operation. If a permanent solution is not immediately available, a temporary workaround might be implemented to minimise service disruption. Once service is returned via a workaround the incident can be closed. The permanent fix / or root cause analysis if needed is then worked via the Problem Management Process.
- Communication: Throughout the incident management process, communication is key (Section 1.3). Stakeholders, including end-users, are kept informed about the incident's status, progress, and estimated time to resolution.
- Resolution Confirmation and Closure: Once the incident is resolved, the solution or workaround is tested to ensure that the IT service is functioning as expected. After successful validation, the incident is formally closed, and relevant documentation is updated. A resolving SME should also consider if the fix needs to be applied proactively to other services, environments or customers via the problem Management Process.
- Incident Record Keeping: All details related to the incident, including its description, impact, resolution steps, and any lessons learned, are documented for future reference. This documentation can help improve incident management processes and provide insights for preventing similar incidents in the future.
- Continuous Improvement: Incidents are analysed as part of the Service Reporting Process to identify trending and underlying causes and patterns, leading to continuous improvement of IT services and the incident management process itself.
Did you know we do more than Managed Services?
Meet the Customer Excellence Team
At DSP-Explorer, we have a dedicated team to ensure our customers are happy with the service we're providing. If you'd like to meet with the team, get in touch today!