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 - Request Fulfilment at DSP

Service Requests (REQs) are formal user inquiries for either information or specific services where the customer / end user is not reporting a fault or issue with service (Incident). REQs are managed via a specific event / ticket type (REQ) within the ITSM toolset. A REQ can be pre-approved where complexity is low or the governance for the REQ is already detailed in the contract or; require specific event approval either technically via a Change Request (CHG) (See DSP Change Management Process) or commercially via the Banked Days / SOW internal Standard Operating Procedures (SOP). DSP will always qualify all customer raised REQs as either covered within the scope of the contract, commercially chargeable via banked days or requiring new governance paperwork in the form of an SOW and specific billing. Requests where a change of state to service is required leads to the creation of one or more CHGs such as a request for patching, a request for an uplift of resources or a request for an upgrade. A REQ can have a 1 to 1 (preferred) or 1 to many relationship with CHG Requests (i.e. REQ to deploy patch 1.x to all customer environments leads to specific changes per Environments such as CHG 1 - UAT / CHG 2 - PROD / CHG 3 -DR).

In its most simple form, a Request is generated when a DSP customer requires something they previously did not have.

The DSP Request Process governs DSP’s operating procedure for Service Requests. DSP Operate separate, but linked, Standard Operating Procedures (or SOPs) for Incident Management, Major Incident Management, Problem Management, Change Management and Continual Service Improvement.

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, a request for change to a supported service or a request to add or remove a new / exisiting service). As such Service interruptions are handled through Incident Management (and where applicable Major Incident Management), and Service Requests through Request Fulfilment.

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 – Raising a Request

The DSP Request Fulfilment process can be triggered as follows:

• A user, customer or supplier may raise a new REQ via DSP’s 24x7x365 Support Telephone Number during UK business hours only. New Requests are not supported 24x7x365 via the telephone line and will not be passed to an On Call Engineer outside of UK business hours. However, a user, customer or supplier can raise a new request 24x7x365 via DSP’s ITSM Portal which with then be reviewed during UK business hours. A user may also raise a Request via direct engagement with a DSP member of staff (where a REQ will need to be logged following verbal engagement)

• Technical staff may raise a REQ as direct result of proactive maintenance, housekeeping or via data provided in the Health Check Portal

• Unlike Incidents REQs cannot be raised by monitoring tooling

All Customer Requests are logged as REQ 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 REQs is a critical step for determining how the REQ will be handled and how much time is available for its resolution. REQs are also reported on to each customer in their periodic Service Review Meetings via their relationship owner.

Once REQs are resolved by the SME and in agreement with the ticket raiser, the ITSM toolset will automatically close the REQ record after 72 hours.

Section 3.1 – Typical Request Stages

• Recording and categorising requests ensures the appropriate team or technology deals with them
  
  
• Assessing the request to determine its nature, complexity and if the request is within the contract scope
  
  
• Fulfilling the request following predefined steps or procedures
  
  
• Closing the request after ensuring the user's need has been adequately met

Section 5 - Request Management and ITIL

• In ITIL V3.0 – Request Management was one of 26 Service Lifecycle Processes. Request Management was a Process within the Service Operation stage of the Service Lifecycle.
• In ITIL V4.0 - Request Fulfilment remains an important part of the framework and is now part one of the 34 Management Practices and resides with Service Management Practices

Request Management Process Interfaces

Request Management interfaces with a number of other DSP ITIL processes:

• Request Management is an input to Problem Management
• Request Management is an input to Change Management
• Request Management is an input Continuous Service Improvement
• Request Management is an input to the Billable/Chargeable work SOP

Request Management can also act as an unintended input to Incident and Major Incident Major Management should request actions lead to an impact to service.