Service request management

Process

The purpose of this document is to outline, at a high level, the process together with the roles and responsibilities to execute, manage and govern the ITD SR Process. It describes the overall positioning, break down and resources needed to complete the SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

The intended audience are those stakeholders throughout DoE that have a role to play in this process either directly or indirectly as dependent stakeholders. As well as those stakeholders who are interested in the process for execution and governance reasons.

This process document inherits the definitions contained in the ITD Glossary for Managing Services.

This document is created to provide a framework that underpins the execution and governance of this process. It is the definitive reference material for this process.

1.1. Process overview

This process document articulates the why and what practices are required for the SR Process to operate. Detailed procedures and work instructions describing how to apply this process are available within the ITD SMO (Service Management Office) SharePoint site.

1.2. Process purpose

The purpose of this process is to fulfil requests for repeatable workflow in a timely, accurate and cost effective manner. Thus maintaining customer satisfaction through the efficient and professional handling of all requests end-to-end.

In doing so, this process will:

  • Resolve requests within SLA timeframes ensuring a quality outcome is achieved
  • Align IT fulfilment activities with real-time business priorities
  • Ensure that all stakeholders receive appropriate and timely communication
  • Ensure that resources are available at the appropriate times during the request fulfilment lifecycle
  • Provide a mechanism for capturing and routing non-standard requests to support teams for resolution.

1.3. SR process goal

The goal of the Service request process is to fulfil requests end-to-end to the satisfaction of the customer within agreed service levels.

1.4. Guiding principles

In designing this process, the following guiding principles were applied:

  • Purpose: manage the data gathering, approvals and fulfilment lifecycle of all requests through a single ITD process.
  • Usage: the process will target scaling up to whole of the department request needs in order for ITD to directly support the departments business processes, in an end-to-end manner.
  • Management technology:  all requests will be logged and managed in the ITD SMO technology, namely, Remedy SR[1]
  • Measuring: agreed response and fulfilment targets will apply and be measured across all teams.
  • Request Ownership:
    • each service request will have one assigned Request Owner who represents the end-to-end business process across the fulfilment lifecycle. This approach ensures seamless end-to-end BAU execution and governance
    • individual task ownership across the request fulfilment workflow will also be implemented.
  • Automation: at the business analysis stage automation opportunities will be leveraged in an end-to-end manner to handle the scale & complexity of requests:
    • poor fulfilment processes will not be automated.
    • improvement opportunities to fulfilment processes will be highlighted to request owner.
  • Excellent customer service: engagement and communications with stakeholders will drive service request data gathering, approvals and fulfilment.

1.5. Process objectives

The objectives of the SR Process are to:

  1. Align SR activities, priorities and outcomes with those of the business requirements as endorsed by the Request Owner.
  2. Match service request fulfilment in an end-to-end manner to support delivery of ITD service thinking outcomes to ITD customers.
  3. Implement adequate mechanisms to scope and resolve non-standard requests.
  4. Implement an SR measurement framework that ensures:
  • governance & management mechanisms that track request fulfilment to agreed service targets.
  • measurement of customer satisfaction per service request approvals and fulfilment workflow.
  • identification of opportunities to automate and streamline fulfilment.
  • produce process reports to benchmark current performance, support continual process improvement and integrate to the ITD CSI (Continual Service Improvement) process.

1.6. Scope

See the Service Request Management process scope page for further information.  

1.6.1. Service requests escalated to department vendors

Requests directed to Vendors will be managed in accordance with the SR Process. Where support is provided by a Vendor then requests will be:

  • Updated and resolved by the Vendor – if access is available to Remedy SR
  • Updated and resolved by an ITD or department Support Group – MUST have access to Remedy SR
  • Updated and resolved by the department Service Desk (based on formal information provided by the vendor)
    • if access is NOT available to Remedy SR and ITD do not have a team that manages the relationship with the supplier.

 

The standards for this process apply to the end-to-end management of any request as part of ITD service delivery to its customers.

Note:  this process inherits all standards from the SMO Standards document and then includes the following standards.

2.1. Single process standard

A single SR process will be used to manage the E2E nature of service request fulfilment and is based on best practice for a IT service provider.

2.2. Process ownership

The SR process is owned by the ITD Service Management Office, who is functionally accountable for the process. The Process Owner is the role titled Service Request Management Process Owner.

2.3. SR Process design

The SR process shall:

  • Manage the lifecycle of all requests
  • Be owned and governed by the SMO to ensure its fit for purpose, accurate and underpinned by an integrated toolset through which all requests are submitted
  • Align requests to the services defined by ITD Service Thinking
  • Ensures that requests are logged, resolved and closed consistently
  • Standardise the way all teams adhere to the agreed response & resolution targets for standard service requests
  • Support best practice customer service and communications
  • Leverage automation as much as possible but under defined measures and governance in order to ensure effective process control
  • Define the requirements for the architecture, design and deployment of ITD automation technology.

 

The ITD SR process MUST be used when:

  • Requests are raised by customers and end-users, including internal ITD roles, for:
    • Service and business process fulfilment
    • Changes to existing services
    • Access to a service, resource or capability.
  • A customer makes an inquiry that is not related to an Incident.

The process is NOT to be used to:

  • Manage any other SMO process
  • As a means to manage changes in the Change Management process (other than operational changes not requiring a change record)
  • To track or resolve issues with testing of ITD Service Elements under development.

If there is doubt as to whether a request or a ITD Service Element lies within the scope of SR, a General Support request should be logged and advice should be sought from the SR Process Owner.

3.1. Process triggers

The process is triggered through the following means:

3.1.1. Department end-user 'Self-service; Self-manage; Self-help' principle

All ITD customers and staff can raise AND track the progress of their requests through:

  • DEC Insight portal (future state requirement)
  • Remedy SR portal.
3.1.2. Level 2 and Level 3 Support Teams

The SR self-service capability (Work Info to Activity Log) is the preferred method of 2-way interaction with customers and end-users. It is envisaged that, as the SR self-service portal matures over time, it will be the most effective channel for customers and end-users to track all their requests and interact with fulfilment teams.

Stakeholders will be actively engaged to enable this outcome. SR benefits of speed, ease of use and functionality will reinforce this outcome.

3.2. SR process support model

Refer to the process support model page for further information.  

 

Email notifications will be issued to the stakeholders across the end-to-end lifecycle of each request. These will be delivered to their primary email address.

The format (banner, words and layout) will be based on the standard ITD notification template.

Refer to the automatic notifications page for further information.   

Print version for process service request management (PDF)

Procedure

The purpose of this document is to document the procedures required to execute, manage and govern the ITD SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

 

The intended audience are those stakeholders throughout DoE that have a role to play in this process either directly or indirectly as dependent stakeholders. As well as those stakeholders who are interested in the process for execution and governance reasons.

This procedure document inherits the definitions contained in the ITD Glossary for Managing Services.

This document is created to provide a framework that underpins the execution and governance of this process. It is part of the definitive reference materials for this process.

1.1. Procedure overview

This procedure document articulates how the SR Process will operate. It describes where, who and when activities will be managed through the process lifecycle. Detailed work instructions describing how to execute this process will be available in the Service Management portal.

1.2. Procedure overview

The SR process, together with the Remedy SR technology, underpins access and fulfilment of service requests to ITD customers in a common and consistent manner.

The SR process supports the ITD adoption and standardisation of the industry best practice ITIL process framework. This framework gives the necessary standard foundations to manage the delivery of services from an IT Service Provider to its customers.

The process consists of the following 4 main procedures to progress requests through to completion and subsequent closure. Each is potentially dependent on other external processes.

[ Insert Diagram ]

1.2.1. Initiate and submit

Used by customers to initiate and submit standard requests or to make general enquires (generic or non-standard requests).

1.2.2. Request review for approval / reject / re-assign

A formal review of the request is conducted by a role nominated by the customer prior to submission. This department employee will decide whether to approve, reject or reassign the request to another role. This review procedure ensures that Department and ITD policy and standards are adhered to.

1.2.3. Assignment

This procedure uses established and approved assignment rules to allocate the request to the correct fulfilment group.

For non-standard requests the EDConnect will assign these requests.

1.2.4. Fulfilment to completion

This procedure empowers fulfilment groups to use standard, endorsed and repeatable workflows to execute request fulfilment. These groups are also responsible for generating and updating knowledge articles that enable further improvements in the fulfilment workflows.

This enables ITD to obtain expected and consistent outcomes from the SR process.

1.2.5. Closure

This procedure is used to formally close requests. It may also trigger execution of the Knowledge Management process.

1.3. Key process interfaces

The main interfaces between SR and other service management ITSM processes include:

1.3.1. Incident Management

Triggers service requests as a result of incidents incorrectly categorised requiring:

  • conversion to a non-standard request, or
  • closed and a standard request raised.
1.3.2. Knowledge Management

Knowledge Management will be applied for the customers and end-users to have the capability of ‘Self-Service; Self-Manage; Self-help’.

It is the preferred first point of interaction and can be used to fulfil requests speedily and potentially without further interaction with the SR environment.

The EDConnect function will use knowledge articles to assist with assignment and non-standard request fulfilment (where appropriate).

1.3.3. Service Level Management (SLM)

Once established, service level targets will be defined and agreed for request fulfilment. The SR process will provide the necessary measures to SLM in order to determine performance against these targets.

Note: SLM is currently not a formal and operationalised process.

1.3.4. Change Management

Change Management is triggered based on the following conditions:

  • request requirements dictate a fulfilment workflow that includes the Change Management process in order to fulfil the request. Change Management policy and standards will be complied with as part of these procedures.
  • any changes (add/modify/delete) to the SR Register will be facilitated by the Change Management process.
1.3.5. Configuration Management

Once established, SR will inherit CIs (Configuration Items) populated into the CMDB (Configuration management Data Base) under Configuration Management control.

Note: Configuration Management is currently not a formal and operationalised process.

1.3.6. IT Asset Management

Once established, IT Asset Management (ITAM) will deliver IT Asset (CI) information to enable IT processes such as Procurement, Warehouse Management, and Disposals.

Note: IT Asset Management is currently not a formal and operationalised process.

 

The purpose of this document is to document the procedures required to execute, manage and govern the ITD SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

The purpose of this document is to document the procedures required to execute, manage and govern the ITD SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

The purpose of this document is to document the procedures required to execute, manage and govern the ITD SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

The purpose of this document is to document the procedures required to execute, manage and govern the ITD SR Process.

The goal is to provide a level of standardisation and control that is critical for reasons related to customer experience, regulatory and policy issues, efficiency / effectiveness, monitoring and reporting on the process.

Return to top of page Back to top