procedure service request management

Purpose 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.

Audience & Applicability 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.

Context 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.

Document Approval List Version Approver name How approved Date

V2.1 IT Executive Team Endorsed at Ops

Meeting 26/06/2017

Document Change Control Version Date Authors Description of changes

V1.0 24/09/2015 Chris Halliday Version for SMO manager and SD&S director review.

V1.1 06/05/2016 Chris Halliday Updated for SMO standards based on EP DR review.

V1.2 21/12/2016 Jehad Batta Ensured document is compliant to accessibility requirements.

Acronym SRM updated to SR throughout document.

V2.1 22/05/2018 Jehad Batta Update of Process and Procedure location link.

V2.2 21/6/19 Stuart Owen Minor formatting changes, no content changes

Service Request Management Procedure document

Document Information Details Name Email

Process Owner Stuart Owen [email protected]

Location Technology Service

Management Guides

https://education.nsw.gov.au/technology/guides-and-forms/service-management-guides

https://education.nsw.gov.au/technology/guides-and-forms/service-management-guides

NSW DoE | ITD Commercial and Services | Procedure – Service Request Management 1 | P a g e

Table of content 1. Overview and purpose ................................................................................................... 2

1.1. Procedure overview ................................................................................................ 2

1.2. Procedure overview ................................................................................................ 2

1.3. Key process interfaces ............................................................................................ 3

2. Key Principles ................................................................................................................ 4

2.1. Request prioritisation .............................................................................................. 4

2.2. Priority level response and fulfilment table .............................................................. 5

2.3. Request lifecycle ..................................................................................................... 6

3. SR Process roles ........................................................................................................... 8

3.1. SR Process Owner ................................................................................................. 8

3.2. Request fulfilment lifecycle roles ............................................................................. 8

3.3. RACI (Responsible, Accountable, Consulted & Informed) Matrix .......................... 12

3.4. Service request register management ................................................................... 12

4. Service Request Management Procedures .................................................................. 14

4.1. Service request procedure descriptions ................................................................ 15

5. Process critical success factors and KPIs .................................................................... 22

5.1. Reporting .............................................................................................................. 24


1. Overview and purpose 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.

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.

2. Key Principles 2.1. Request prioritisation

The standard Impact/Urgency matrix below is used to determine the priority of a request. The

output from using this matrix is to formulate the associated Priority Allocation Table. The

resulting priority will direct SR procedures, targets and other integrated processes.


Impact / urgency matrix

Urgency 1

Urgency 2

Urgency 3

Urgency 4

Impact 1

1 1 2 2

Impact 2

2 2 3 3

Impact 3

2 3 3 4

Impact 4

3 3 4 4

Priority allocation table

No. Priority

1 Critical

2 High

3 Medium

4 Low

2.2. Priority level response and fulfilment table The tables below detail the response, fulfilment and escalation times for each level of priority.

Note: currently all requests are recorded as Priority 4. Formal service level targets will be

introduced once baseline information and targets are endorsed.

2.2.1. Response time The time it takes for the customer to be advised their request has been submitted and

actioned.

2.2.2. Fulfilment time The time taken for the fulfilment groups (Support Groups) to complete an assigned request.

This is the time taken from arrival in the Support Group queue to when the request status

is marked as “Completed” (the final child Incident is resolved). Standard queue

management practices used include:

• ensuring the correct request status is maintained e.g. “Initiated” and “In Progress”

• effective customer communications via the Work Info to Activity Log interaction

capability

Completed records will be automatically closed based on Service Management Standards.


2.2.3. Tolerance level It is the acknowledged that in some cases unforeseen circumstances prevent the resolution

of requests within the agreed Response and Resolution times. It is targeted that 80% of

requests are fulfilled within the times listed in the table below.

Table 1 – Priority response and fulfilment table

Priority Response (Days) Fulfilment (Days)

1 – Critical 0.5 4 hours

2 – High 1 2 days

3 – Medium 1.5 4 days

4 – Low 2 10 days

2.2.4. Hierarchic escalation table

Priority 1st escalation to… 2nd escalation to…

1 Next level of management Next level of management




Where possible escalations will be automated, however it is the responsibility of the

assigned Support Group to ensure requests are escalated.

2.2.5. Standard requests

Standard requests will have a pre-defined workflow and as such will have a defined

duration. This duration will be included as part of the request description in the Request

Register and pre-defined in Remedy SR.

The appropriate allocation of Impact and Urgency will be applied within the Remedy SR

Service Request Definition (SRD).

2.2.6. Non-standard requests

The resolution time target of a non-standard request is based on Impact and Urgency table

above. The department’s Service Desk will allocate impact and urgency to generate the

correct priority.

2.3. Request lifecycle The following table and lifecycle flowchart describes the lifecycle of a request record in the

Remedy SR system.

Note: Request fulfilment end-to-end will be managed by the Remedy SR technology.


Remedy SR – status codes

Request status Description

Draft The request has been created but has not been submitted

In Review The request has been submitted and is being reviewed

Pending Work on the request has been temporarily suspended. A status reason (Approval or More Information) must be specified, when the status is Pending

Waiting approval The request has been submitted and is pending approval. A request goes into Initiated status when all of the approvers have approved

Initiated The request has been arrived into the queue of the relevant Support Group

In Progress The request had been assigned to a member of the relevant Support group. They execute their standard activities to fulfil the request

Completed All request fulfilment activities have been completed and status updated to “Completed”

Cancelled The request is cancelled

Closed The request is closed according to Service Management standards

Remedy service request – service request lifecycle (Note: not all status codes are used in ITD)

Draft

In review

Waiting approval

Initiated

In progress

Rejected

Completed

Closed

Cancelled

Pending

Need more information

Needmore

information

Service request needs approval

Automatically closed

Cancelled by service request

coordinator

Service request does not need

approval

User cancels service request


3. SR Process roles The following section provides an overview of the roles involved in the SR process. They are

categorised into:

• day-to-day operational management of the process

• end-to-end governance and oversight

3.1. SR Process Owner The Process Owner is accountable for:

• The end-to-end operational capabilities of the SR process

• Acting as an escalation point for any issues

• Managing process changes and continual improvement of the process

• Ensuring all stakeholders understand their role and responsibilities

• Maintaining all process related documentation, training and process reporting

• Maintaining standards and process compliance

• Effective management of the Request Development Lifecycle

• Conducting periodic audits to confirm that the SR Request Register is up-to-date.

3.2. Request fulfilment lifecycle roles During the fulfilment lifecycle, the following roles are involved and engage as one virtual team.

3.2.1. Request Owner The Request Owner is accountable for:

• Business Requirements: provide and validate request requirements to ensure

adherence to the Department and ITD policy / standards. This includes the required

approval levels and flow plus the assignment rules for Support Group fulfilment

• UAT: selection of the correct testers and ensure successful completion plus act as

escalation point:

o select and endorse the UAT tester list

o assign testers to conduct testing within agreed timeframes and artefact completion

o ensure testers participate in defect remediation and re-testing, if necessary

o sign-off UAT testing prior to Go-live production

• Go-live into production: sign-off that the request is working in the production

environment as per requirements and testing. This could be a night time or weekend

exercise.

• Organisation Communications (ADKAR): responsible for effective organisation

communications in relation to their request(s)


• Request Training: endorse training artefacts, roles and delivery methods, if required

• BAU: receives request dashboard information as input into monitoring of SLAs and

identification of improvements. Activities during request BAU:

o Monitor Request status: means first to see issues or bottlenecks and any

improvements required

o Manage SLAs: means they as focused on agreed level of customer experience and

improvements to meet SLTs (Service Level Targets)

o Resolve Issues/Escalations: BAU operations across all request stakeholders

o Take-up and use: working with stakeholders to ensure no issues that impede

customer take-up and usage

• Improvements: provide improvements across the lifecycle of their request(s). Includes

any maturing of automation to assist customer experience and service level targets

• Escalations as a senior stakeholder

3.2.2. Customer or End-user The Customer or end-user is responsible to:

• Initiate requests via the approved channels

• Supply accurate and complete information

• Clarify and validate request requirements

• Nominate a role for required request reviews (Approve, Reject, Re-assign)

3.2.3. Request reviewers for approve / reject / re-assign Request reviewers of requests are responsible to:

• Review requests in a timely manner and within their delegated authority

• Ensure appropriate approval channels exist at all times e.g. annual or sick leave; out

of office

• Maintain their knowledge of relevant standards and processes associated with service

requests

• Delegate automated approvals and/or escalations when required and in a planned

manner

• Communicate with requestors regarding approval and non-approval reasons

• Provide suggestions that improve the request lifecycle, including initiation and approval

requirements, as part of the improvement of service level targets


3.2.4. Fulfilment (Support) Group Members The Fulfilment Group members are responsible to:

• Identify (verify) approvals for non-standard requests

• Identify and coordinate all actions required to fulfil assigned requests

• Update progress of Work Info or Activity Log interactions with the customer in a timely

manner

• Manage their queue efficiently

• Apply skills, experience and knowledge to fulfil requests

• Identify and resolve knowledge gaps e.g. trigger knowledge article/s

• Assist with the correct categorisation and assignment for non-standard requests that

may have been assigned incorrectly

• Trigger other related ITSM processes where necessary e.g. Change Management

• Provide suggestions that improve fulfilment workflows to improve service level targets

3.2.5. Fulfilment (Support) Group Managers The Fulfilment Group Managers are responsible to:

• Manage their queues in a timely manner, including:

o Responsibility for queue monitoring, reviewing and accepting requests assigned to

their group

o Prompt request allocation to and management of group members to complete

requests as part of the attainment of service level targets

o Prompt and correct re-assignment of incorrectly assigned requests.

• Act as the escalation point for their team

• Provide active engagement and communication with customers & end-users to meet

joint expectations

• Identify skills gaps across any request lifecycle, either within their own team or other

teams

• Provide suggestions that improve the request lifecycle, including fulfilment workflows,

as part of the improvement of service level targets

3.2.6. Request Designer The Request Designer is responsible to:

• Conduct business analysis tasks to:

o discover and validate request requirements

o develop documentation across the Request Development Lifecycle including

functional workflows and measures

o document the resulting Gap Analysis, with recommendations for closing the gap

o write-up, request endorsement and socialisation with all stakeholders.


• Design new and changed requests including elements such as data gathering with

logic flows, approvals and fulfilment workflows.

• Ensure the necessary documentation is developed for the Remedy Development

Team (Request Builders) to efficiently build Service Request Definition (SRD) files

needed to execute the request in the Remedy SR technology.

3.2.7. Request Builder

The Request Builder is the Remedy Development Team of developers who are responsible

for:

• Build and change of requests based on the design created by the Request Designer.

Any build work should only be completed based on signed off design documentation

• Implementing into production the new / changed SRD through the Service

Management Change Management process.

3.2.8. Functional Teams

The following are key functional teams that participate in the request lifecycle. These are

referenced for clarity and recognition.

EDConnnect

The EDConnect is the first point of contact for customer interactions by phone & email. In

context of the SR process this team is responsible to:

• Be the point of contact for customers and end-users requiring assistance with requests

• Accurately log and assign standard and non-standard requests received by phone or

email

• Qualify and accurately assign non-standard requests to the correct fulfilment groups

• Provide status updates to customers and end-users when requested by phone or email

• Resolve those requests within their scope, capability and authority

• Confirm completion of requests, if requested

• Provide suggestions that improve the request lifecycle, including fulfilment workflows

and knowledge, in order to improve service level targets.


Service Management Service Operations Team

The Service Operations Team is responsible to:

• Maintain oversight of active requests, throughout each request lifecycle, to ensure

service level targets are able to be met

• Identify trends or existing bottlenecks

• Engage request fulfilment groups to resolve bottlenecks

• Provide a point of escalation, as required

• Monitor the lifecycle of all requests to produce required SR operational metrics &

measures

• Engage the Service Level Manager with recommendations for enhancements to SLT

measures

• Provide suggestions that improve the request lifecycle, including fulfilment workflows

and knowledge, as part of improving service level targets.

3.3. RACI (Responsible, Accountable, Consulted & Informed) Matrix Key roles across the request lifecycle:

Activity/role Process owner

Request owner

Request designer

Request builder

Customer Request reviewer

Fulfilment groups

Governance of end-to-end SR environment

A R I C C C C

Appropriateness of request to Department & ITD processes

R A I I I

Accurate submission of request R A

Timely and effective review of request to approve, reject or re-assign

C A

Timely and accurate fulfilment of request

C A

Timely and accurate development of request SRDs

C I R R C

3.4. Service request register management The Service Request Register is the source of truth of all Service Management requests

across:

o SR Pipeline

o Available requests for customer consumption

o Retired requests.

The following roles are involved in the Service Request Register management.


3.4.1. Service Management The Service Management is responsible for:

• Execution and governance of the Request Development Lifecycle for on-boarding and

modification of requests to the Service Request Register

• Gap Analysis of new requests and enhancements to existing requests

• Impact analysis of each new, enhanced or retired requests

• Governance activities to ensure endorsement for any updates to the register

• Communication to relevant stakeholders of updates to the register, including

dashboards.

3.4.2. SR Process Owner The SR Process Owner is responsible for:

• Governance of the Service Request Register end-to-end

• Communication of the Service Request Register effectiveness, including dashboards

• Communication of all request performance against requirements, including

dashboards.

3.4.3. Request Designer The Request Designer is responsible for:

• Discovery, documentation and validation of detailed requirements for all modifications

to the register

• Business analysis across the Request Development Lifecycle

• Testing all modifications required for new/updated/retired requests

• Packaging of request modification releases to minimise changes

• Updating the Service Request Register across the Request Development Lifecycle.


4. Service Request Management Procedures The procedures used to move a production request through its lifecycle:

Fulfilment for completion

REQ. 101Data entry &

submit

REQ. 102Customer

notification

REQ. 103Standard?

REQ. 301Approval(s) required?

REQ. 201Discover & triage

request information

REQ. 206Re-direct request?

REQ. 202Request

categorisation REQ. 205Valid request?

REQ. 203Request

prioritisation

REQ. 204Assign to support

group

REQ. 302Reviewer

notification

REQ. 303Review request

REQ. 304Approve, reject,

re-assign?

REQ. 305Customer

notification

REQ. 401Assignment rules

applied

REQ. 501Standard queue &

fulfilment workflow(s)

REQ. 506Customer

notification

REQ. 502CI impact?

Change management

REQ. 503New/updated

Ka(s)?

REQ. 504Resolve child

incidents

REQ. 505Request

completed?

Knowledge management

Yes

No

Yes

No

Yes

Re-assign

REQ. 602Close request

End

Fulfi

lmen

t (su

ppor

t) gr

oups

Req

uest

revi

ewer

(s)

Serv

ice

Des

k Fu

nctio

nC

usto

mer

ClosureAssignmentRequest ReviewFor approve, reject & re-assign

Initiate & submit

Request Management Procedures

No

Yes

No

No

Yes

YesNo

Yes

Reject

Approve


4.1. Service request procedure descriptions This section describes the specific procedures (work activities) referenced in the Service

Request procedure diagram (previous page) and provides some level of detail as to how these

activities are performed.

4.1.1. Initiate and submit

REQ. 101 Data entry and submit

Purpose Provides a mechanism for customers to raise and submit requests

Trigger Customer requires the fulfilment of a request or has a query

Inputs Details of the request

Description

A request may be raised through:

• The Remedy SR interface

• Phone or email call to the EDConnect

• Department’s Insight staff portal (future state)

Note: the Remedy SR functionality of ‘On Behalf Of’ (OBO) is used to ensure an audit trail of

the role that submitted the request and the role that required the request.

Outputs A submitted request record in the customers ‘My Requests’ list

REQ. 102 Customer notification

Purpose To ensure that the customer is notified of successful request submission together with the

Remedy SR (REQ) number for the parent request

Trigger Submission of Remedy SR request

Inputs Submission data of request

Description

Takes the form of:

• Visual notification on the customers screen

• Email notification in the customer mailbox

Outputs Email confirmation of REQ number and request summary

REQ. 103 Standard?

Purpose To determine if this request is a standard ‘predefined’ request as per the Request Register or

non-standard General Support request

Trigger Customer has submitted a request

Inputs The request record

Description

If identified as standard, it will trigger a specific workflow for that request.

Otherwise, the generic request option will be assigned to the IT Service Desk Function for further triage and Support Group assignment.

Outputs If Yes, go to REQ.301 Approval(s) Required?

If No, go to REQ.201 Discover & triage request information


REQ. 201 Discover & triage request information

Purpose For non-standard (General Support) requests, to enable the EDConnect to personally follow-up

with the customer and validate the exact nature and request requirements.

Trigger Customer has submitted a General Support request

Inputs A General Support request

Description

The IT Service Desk Function engages the customer and applies standard triage techniques to

ensure complete information is gathered for:

• Correct Support Group assignment

• Efficient fulfilment of the request by the Support Group.

Outputs • Completed with all necessary fulfilment information

• Updated request record

REQ. 202 Request categorisation

Purpose To correctly categorise a non-standard request

Trigger The logging of a non-standard request usually through submitting a ‘General Support’ request

Inputs • A request record

• Knowledge Article/s

Description

The EDConnect will categorise the request and may refer to appropriate knowledge article(s)

for guidance. The categorisation will assist to determine:

• what levels of request review is required for approval / reject decisions

• which fulfilment group(s) are needed to fulfil the request.

Outputs A categorised non-standard request record with sufficient information to fulfil the request.

REQ. 203 Request prioritisation

Purpose To correctly prioritise a non-standard request

Trigger The submission and categorisation of a non-standard request

Inputs

• A complete request record

• Relevant Knowledge Article(s)

• Impact and Urgency definitions

Description

The EDConnect will prioritise the request and may refer to appropriate knowledge article/s for

guidance.

If the request is submitted by phone, then the Service Desk analyst will ask the submitter a number of appropriate questions to determine the content plus the Impact and Urgency of the

request.

Outputs A prioritised non-standard request record.


REQ. 204 Assign to support group

Purpose To assign a non-standard request to the appropriate Support Group

Trigger A non-standard request has been submitted

Inputs A categorised and prioritised non-standard request

Description

The IT Service Desk must now determine which fulfilment group(s) would be required to fulfil

the request.

If the request can be fulfilled within the initial interaction, then it will be assigned to the IT Service

Desk.

If not, then the IT Service Desk will need to ensure they gather the correct and accurate information to determine the Support Group(s) to assign the request.

Note: The IT Service Desk should query the knowledge base for any existing article(s) that may

provide guidance.

Outputs A non-standard request assigned to the correct Support Group

REQ. 205 Valid request?

Purpose To validate if a non-standard request should be handled through the SR process

Trigger A customer has submitted a non-standard request

Inputs A Remedy SR request record

Description The IT Service Desk must assess if the request raised should be handled through the SR

process and Remedy SR system

Outputs If Yes, go to REQ.206 Redirect Request

If No, go to REQ.201 Discover & triage request information

REQ. 206 Re-direct request?

Purpose To direct a request outside the scope of the Remedy SR environment to the appropriate area

e.g. SSC Contact Centres

Trigger The IT Service Desk has assessed a request

Inputs A triaged and valid request

Description

The IT Service Desk will work with the customer to either:

• direct the request to the correct Support Group or functional area, or

• assist the customer with clear redirection instructions

The request record will be set to a status of “Complete”

Outputs If Yes, go to REQ.505 Request Completed?

If No, go to REQ.102 Customer notification


4.1.2. Request review

REQ. 301 Approval(s) required?

Purpose To determine if a request must be approved before proceeding

Trigger Submitted standard request

Inputs Submitted standard request

Description

The scope and type of request will determine the approval level(s) required.

Note: the types of approval could include line manager or other role, business, technical and financial

Outputs • If No, then go to REQ.401 Assignment rules applied

• If Yes, then go to REQ.302 Reviewer Notification

REQ. 302 Reviewers notification

Purpose

To ensure the nominated reviewer is aware they have a request to review. The speed of

response to this notification will determine:

• identification of any bottleneck at this step in the request fulfilment workflow

• overall request fulfilment target attainment

Trigger Submitted request requiring review to approve, reject or re-assign

Inputs Submitted request

Description

The reviewer will receive an email notification that informs the reviewer of:

• their nomination as reviewer of a particular request

• the request number

• hyperlink to the reviewer’s Approval Central console

Outputs Notification email

REQ. 303 Review request

Purpose To determine if the contents of a request supports a decision on whether it should progress

Trigger A request has a need to be reviewed to determine if it should be approved, rejected, re-assigned

Inputs Submitted request and notification email

Description The reviewer(s) will assess the request prior to a decision, based on the department’s policy

and rules for follow-on action and governance reasons

Outputs Assessment decision, with supporting document if necessary, for follow-on actions and

governance reasons


REQ. 304 Approve, reject, re-assign?

Purpose Move the request forward based on the reviewers assessment decision

Trigger Assessment decision

Inputs Assessment decision

Description

If the decision is:

• Approve: then the request is automatically forward to the assign Support group, the status

set to ‘Approved’ and a notification is sent to the customer

• Reject: then the request is closed, the status set to ‘Rejected’ and a notification is sent to

the customer with an explanation in the ‘Justification’ field

• Re-assign: then the request is forwarded for review to the role nominated by the current

reviewer with an explanation in the ‘Justification’ field

Outputs • If Approve or Reject: go to REQ.305 Customer Notification

• If Re-assign: go to REQ.303 Review Request


Purpose Communicate the reviewers assessment decision to the customer

Trigger Assessment decision

Inputs Assessment decision

Description The Remedy SR notification engine sends all notifications

Outputs • If Approve: go to REQ.401 Assignment rules applied

• If Reject: go to REQ.601 Close Request

4.1.3. assignment

REQ. 401 Assignment rules applied

Purpose To ensure the assignment rules are applied. These rules are generated as part of the business

analysis phase of request development, with the request owner

Trigger An approved request

Inputs An approved request

Description The assignment rules are input to the Remedy ITSM technology and automatically applied

Outputs • A child Incident is placed in the relevant Support Group(s) queue.

• The parent Request status is set to ‘Initiated’


4.1.4. Fulfilment to completion

REQ. 501 Standard queue & fulfilment workflow(s)

Purpose Initiate standard fulfilment workflow(s) by the relevant Support group(s)

Trigger A request arrives in the relevant Support Group(s) queue

Inputs A child Incident in the Support Group(s) queue

Description

• All Support Group(s) will have their standard and endorsed workflows and activities to

resolve a child Incident.

• Where possible, Remedy SR will automatically trigger a pre-defined workflow as defined in

the business analysis phase with the Request Owner

• This workflow will include all necessary approvals and activities required to resolve the child

Incident(s)

• Remedy ITSM and other technologies will be used to enhance automation of the request fulfilment

• As part of good queue management practices all Support Group member(s) will ensure each

child Incident is assigned to themselves in order for the Request status to be progressed

and set to ‘In Progress’

Note 1: This will also include interfacing with the Change Management process where completion of the request has an impact on any CIs

Note 2: At any time during the fulfilment procedure the customer may check on the status of the

request. This ‘Self-manage’ capability of Remedy SR will allow the customer to be aware of the progression of their request

Outputs

• A resolved child Incident(s)

• A fulfilled request

• Updated request and incident record(s)

REQ. 502 CI impact?

Purpose Determine if a request has an impact on any configuration items (CIs)

Trigger An activity in the Support Groups standard workflow that impacts on a CI

Inputs Support Group’s decision that a CI will be impacted

Description

The Support Group will check to see if any CIs will be impacted as part of their standard fulfilment

workflow.

Note: If CIs will be impacted then the Change Management process must be invoked in order for the appropriate change/s to be raised

Outputs • If Yes: invoke the Change Management process

• If No: go to REQ.503 New/Updated KA(s)?


REQ. 503 New/updated KA(s)?

Purpose To ensure KA(s) (Knowledge Articles) are generated, updated or retired to further improve the

‘Self-service; Self-manage; Self-help’ nature of SR

Trigger A review by the Support Group(s) as a standard activity in their fulfilment workflows

Inputs • Completion of the necessary child Incident workflow activities

• Any Change record(s)

Description

The Support Group(s) carry out the necessary review to ensure currency of Knowledge Article(s)

that:

• enhance their fulfilment activities

• knowledge sharing across the relevant Support Group members

Outputs

• If Yes: invoke the Knowledge Management process for any new, updated or retired

Knowledge Article(s)

• If No: go to REQ.504 Resolve child Incident(s)

REQ. 504 Resolve child incident(s)

Purpose To review and record that all workflow activities for the child Incident have been carried out

Trigger All the Support Group(s) standard activities have been carried out

Inputs • Change record(s)

• Knowledge record(s)

Description The Support Group(s) carry out a review that all workflow activities are complete and the

assigned child Incident is marked as ‘Resolved’

Outputs The child Incident is resolved then go to REQ.505 Request Completed?

REQ. 505 Request completed?

Purpose To confirm that all child Incidents have been resolved

Trigger A resolved child Incident

Inputs A resolved child Incident

Description The resolved child Incident is reviewed to ensure it is, or is not, the final child Incident in the

parent request workflow

Outputs • If Yes: go to REQ.506 Customer Notification

• If No: go to REQ.501 Standard queue & fulfilment workflow(s)



Purpose Inform the customer their request is successfully completed

Trigger Final child Incident has been resolved

Inputs Final child Incident has been resolved

Description

The Remedy SR notification engine sends notifications. The customer receives a standard

‘Completed’ notification.

During an agreed timeframe the request will be deemed to be in a warranty period.

Completed records will be automatically closed based on Service Management Standards

Outputs • Customer notification

4.1.5. Closure

REQ. 601 Close request

Purpose To advise the Customer that their completed or rejected request has been formally set to a

status of ‘Closed’

Trigger • The Request Reviewer has rejected the request

• The standard 10 days has elapsed from when the parent request was ‘Completed’

Inputs • Rejected request from the request reviewer

• A completed parent request

Description

The status of the request will be set to “Closed”

Note: during the standard timeframe from completion of the parent request, the request is

deemed to be in a warranty period. The Customer can raise questions about the rejection or completion standards during this warranty period.

Outputs • Request record is set to ‘Closed’

5. Process critical success factors and KPIs The following image has been developed using a Metric Correlation Model. This model assists

to expose management metrics and supports the tracking of their health. This approach

demonstrates correlations between system health metrics in order to allow errors to be

detected and causes localised.


Service request metric correlation model v1.1

Objective 1E2E lifecycle efficiency

Objective 2E2E lifecycle effectiveness

Objective 3Customer value

Pipeline management(by number, value &

speed to charter)

E2E request lifecycle development improvement

(per simple, medium, high complexity)

Request productivity impacts

Linked to SMO roadmap

Request bundles & offered measured &

communicated

Customer request governance results

Request take-up by…- Business area

- Change in source

Speed thru SRM Dev lifecycle per stage

Productivity gains per…- Time saved

- Dollar savingsResource savings

Customer analysis & trends

# Identified & # Deployed

- Business & ITD SRM Dev lifecycle- Stage statistics

SRM Dev lifecycle- Resources

statistics

Metrics perrequest

- per requeststage

Automation adoption by…

- Type- Impact on benefits

Business benefits- per request

Customer governance

- Engagement meetings- Surveys

Outcome metricsDid we go there?

Indicator metricsWhere do we look?

Diagnostic metricsWhat do we improve?


5.1. Reporting Refer to the current endorsed SR Process Reporting Specification Document for detailed

requirements on each metric and their supporting measures and reporting criteria.

procedure service request management

Documents