Process ITD Disaster recovery · 2020. 1. 22. · Customer or End-user ... Incident Management Page 2 of 31 1. Overview and purpose 1.1. Procedure overview This procedure document

Purpose

The purpose of this document is to document the procedures required to execute, manage

and govern the DoE ITD Incident Management 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 SMO 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 Endorsed by Role How approved Date

V3.0 IT LEADERSHIP GROUP Approver Leadership forum 06/11/2015

V4.0 IT LEADERSHIP GROUP Approver Leadership forum 16/06/2016

V5.0 IT Executive Team

Governance

authority

Endorsed at Ops

Meeting

26/06/2017

V6.0 IT Executive Team

Governance

authority

Endorsed at Ops

Meeting

22/07/2018

Document Change Control

Version Date Authors Description of changes

V6.0 28/07/2018 Stuart Owen Inclusion of references to MIM Process, Vendor

Support Process, Change Management Process and

detailed work instructions.

V6.1 30/08/2019 Stuart Owen Updated priority matrix and resolution to closure

grace period.

Incident management

Procedure document

Document Information

Details Name Email/Link

Process owner Stuart Owen [email protected]

[email protected]

Location Technology Service

Management Guides

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

forms/service-management-guides

mailto:[email protected]

mailto:[email protected]

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 - Incident Management Page 1 of 31

Table of content

1. Overview and purpose ................................................................................................... 2

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

1.2. Procedure purpose ................................................................................................. 2

1.3. Key process interfaces ............................................................................................ 5

2. Key Principles ................................................................................................................ 7

2.1. Taxonomy ............................................................................................................... 7

2.2. Incident Prioritisation ............................................................................................... 8

3. Incident Management Roles and Responsibilities ........................................................ 11

3.1. Process Owner ..................................................................................................... 11

3.2. Technical Support Manager/Team Leader ............................................................ 11

3.3. Service Desk Manager .......................................................................................... 12

3.4. Technical Support Analyst .................................................................................... 12

3.5. Incident Analyst .................................................................................................... 12

3.6. Customer or End-user ........................................................................................... 13

3.7. Service Delivery Manager ..................................................................................... 13

3.8. Vendor Operations Lead ....................................................................................... 13

3.9. RACI Matrix .......................................................................................................... 14

4. Incident Management Procedures ............................................................................... 15

4.1. Level 1 Process Flow ............................................................................................ 15

4.2. Incident management activity descriptions ............................................................ 16

4.3. Level 2 Process flow ............................................................................................. 23

4.4. Incident management activity descriptions ............................................................ 24

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

5.1. Reporting .............................................................................................................. 29


1. Overview and purpose

1.1. Procedure overview

This procedure document articulates how the DoE Incident Management Process will

operate. It describes where and when activities will be managed through the process

lifecycle and by whom. Detailed work instructions describing how to apply this process, along

with other supporting reference materials are accessible via the links provided within the

Incident Management Activity Description section of this document and via the Service

Management Essentials online training course (Accessible via the DoE Staff Portal below

the “My Training” section).

1.2. Procedure purpose

The Incident Management process, together with the Information Technology Service

Management (ITSM) toolset, underpins the identification, logging, categorisation,

investigation and resolution to ITD customers in a common and consistent manner.

The Incident Management process supports the ITD adoption and standardisation on the

industry good practice service management framework. This framework gives the necessary

standard foundations to manage the delivery and support of services from a Service

Provider to its customers.

The process consists of the following 6 lifecycle activities:

1. Detection and Recording;

2. Classification and Prioritisation;

3. Initial Diagnosis;

4. Investigation and Diagnosis;

5. Resolution and Recovery;

6. Closure


1.2.1. Detection and Recording

An event becomes an incident when it is detected and recorded in the DoE standard ITSM

toolset. Incidents may be recorded by:

A service desk support analyst receiving a phone call or other notification such as

email or fax;

A support analyst receiving a phone call, email or fax requesting support;

An affected user creating an incident ticket directly using a self-service electronic

form;

A system monitoring tool automatically generating an alert that results in an incident

being recorded in the DoE standard service management toolset;

A systems Engineer, or a support analyst at any level in the organisation detecting

an actual or potential system fault.

Upon notification, all incidents will be recorded in the DoE standard ITSM toolset. An

important and mandatory activity at this stage is to validate that the customer is indeed who

they say they are and to review and validate that their contact details are correct.

1.2.2. Classification and Prioritisation

Incidents will be initially categorised by:

Recording that the event was an incident;

Recording the product;

Recording a Query Type (Categorisation);

Recording an appropriate Summary of the incident then providing a full description

in Notes, , including, but not limited to any error messages that the customer may

have captured, key environment details such as home or office based at time of

issue, type of device, unique userID’s of associated staff or students;

The toolset provides a date and time for the incident when logged into the Service

Management toolset.

Incidents will be initially prioritised by a combination of business urgency and business

impact.

1.2.3. Initial Diagnosis

Initial diagnosis will involve searching the knowledge base for relevant articles and

searching the incident data base for duplicate and/or related incidents.

If a relevant knowledge article exists, it will be used and it’s content will provide guidance

as to the steps required to resolve or escalate (Re-assign) the incident, as required. If a


relevant knowledge article does not exist, then a framed knowledge article will be created

(Containing no solution details at this stage) and initial diagnosis steps undertaken, with

such steps and outcomes recorded within the incident.

If a solution is found then the customer is informed, the knowledge article updated (With

solution details) and the incident resolved. If at this stage a solution is not found or when

the target time for first point resolution has been exceeded, the incident will be updated

with the latest diagnostic steps taken and the outcomes of such steps, then the incident will

be escalated (Re-assigned) to another support team.

1.2.4. Investigation and Diagnosis

Investigation is undertaken when a solution cannot be immediately found. Here the

analyst has to decide whether to attempt resolution on their own or escalate (Re-assign)

to the most appropriately skilled support group.

The analyst to whom an incident is assigned, is expected to review and accept the

assignment. If not, the incident should be re-assigned to the most appropriate team. If

accepted, the analyst will respond to the assignment within the response target in the

OLA. Investigation is likely to include some or all of the following, but not limited to:

Establish what has gone wrong, or what is being requested by the user;

Understand the chronological order of events;

Identify any events that could have triggered the incident;

Knowledge searches looking for previous occurrences in incident/problem records

or knowledge databases or manufacturers’/suppliers’ error logs or knowledge

databases.

If a solution cannot be found and the service level target has not been breached, then the

incident should be escalated to the most appropriate support team or vendor.

If the incident is in danger of breaching its service level target, then the incident will be

escalated to the support group team leader or manager for remedial action.

1.2.5. Resolution and recovery

An incident is resolved where the service is restored.

Once a solution is found and has been tested, the incident analyst will update the

resolution details and resolution categorisation, update the relevant KA and resolve the

incident record. It should be noted that the resolution details will be communicated to the


customer and hence must be expressed in language that can be clearly understood by

the customer.

It is important that any recovery requirement(s) be identified and actioned prior to

resolving the incident. These should also be clearly documented in the resolution details.

1.2.6. Closure

Following incident resolution, the affected customer receives an automated resolution

notification.

If the customer is satisfied with the resolution they need do nothing more as the

record will be automatically closed after a grace period of 28 calendar days.

If the customer is unsatisfied with the resolution they should contact the relevant

Service Desk, with the original incident record number and have the incident

updated with the reasons why the incident was not rectified. The incident will then

be re-opened and re-assigned back to the resolving group for further investigation

and resolution.

1.3. Key process interfaces

The main interfaces between Incident Management and other ITD SM processes are:

1.3.1. Service Request Management (SRM)

SRM may trigger Incidents where a service request is incorrectly categorized requiring

conversion to an Incident.

1.3.2. Problem Management

Incident Management provides a triggering event for Problem Management to be

initiated. Problem Management uses incident trending information to proactively identify

potential problems. It also provides workarounds and eliminates causes of incidents to

assist in rapid resolution of incidents, thus contributing to increased availability of

services.

1.3.3. Knowledge Management

Assists Incident Management by iteratively providing knowledge on solutions and

workarounds. New incidents may trigger new knowledge requests via the Knowledge

Management process. Early Life Support and Knowledge Transfer aim to underpin

changing or new services with known errors ready for the service initiation and potential

incidents.


1.3.4. Change Management

Assists Incident Management by providing the Service Desk with information on current

and future change activity, as well as change history. It provides authorised and

controlled implementation of changes and providing up-to-date information on progress of

changes. Incident Management uses Change Management to implement changes to

restore services and provide traceability for all activities.

1.3.5. Configuration Management

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

Assists Incident Management by providing valuable information about the CIs contained

within the CMDB. The relationships and dependencies that exist between the CIs (and

related People, Services and Service Management) provide up-to-date information status

of CIs to quickly and efficiently assist in the process of diagnosis and resolution.

1.3.6. Major Incident Management

Is a sub-process of the Incident Management Process and is invoked to manage incidents

determined to be of the highest business priority, which demand a response beyond the

routine Incident Management Process. Barring exceptional circumstances, the Major

Incident Management process is triggered by incidents validated as being of the highest-

impact and highest-urgency within the ITSM toolset and seeks to ensure the right staff

across the organisation are co-ordinated to deliver the most timely restoration of service as

possible and to manage communications to key stakeholder during the life of the Major

Incident.

1.3.7. Vendor Support

Is a sub-process of the Incident Management Process and is invoked to manage

incidents that have been determined as hardware faults which require assignment to a

DoE 3rd party IT Hardware supplier for a warranty repair or out-of-warranty (OOW) repair

quote.


2. Key Principles

2.1. Taxonomy

2.1.1. Taxonomy Definition

Taxonomy (from Greek taxis meaning arrangement or division and nomos meaning law)

is the science of classification, naming conventions, according to a pre-determined

system, with the resulting catalogue used to provide a conceptual framework for

discussion, analysis, or information retrieval. All data stored within the DoE ITSM toolset

has been created in-line with a defined DoE Taxonomy model (Click here to view) and

naming conventions. Changes to such data will go through a formal governance control,

whereby each change is to be requested, reviewed and approved or rejected.

2.1.2. Record Type

The Record Type helps classify the nature of support requests received from customers.

ITIL has segmented support requests into Incidents and Service Requests. The record

type is automatically populated based on the selection of the query type.

2.1.3. Query

A query is the conceptual framework defining what the customer is contacting the Service

Management organisation for. In essence, the query is the nature of the support request,

from the customer’s perspective.

Queries allow for global reporting e.g.: How many logon queries are received annually on

all web applications? As all Applications and Systems require a logon, we can use the

Query as the primary reference and then filter down by the any other relevant field.

Queries define, and will automate the selection of the Record Type, which defines

whether the ticket is a Service Request or an Incident.

Billing | charging Functionality (how to?) Policy | process | procedures

Booking | Scheduling Install Uninstall | Upgrade Procure | Loan | Evaluate

Breach | Complaint | Dispute Content | Data Logon | Access Reporting

Documentation | Templates | Forms Lost | Damaged | Stolen Review | Audit | Test

Enquiry | Suggestion | Feedback Move | Add | Change System Message | Error Message

Fulfilment | Reconciliation Performance Enhancement

2.1.4. Product Categorisation Tiers

The Product Categorisation tiers are a broad tier based approach to grouping the types of

records that are raised with the Service Management organisation.


The desired objective is to limit the Product Type tiers to only two tiers, with the option of a

third tier if absolutely necessary.

The product types will be used to align to the service catalogue, segment the

knowledgebase, empower trending and problem management and provide the ability to

AutoRoute records.

For example, the below diagram illustrates the product categorisation tiers for the ITSM

toolset:

ApplicationsTier 1

Online

applications

Tier 2

Remedy

Product

name

2.1.5. Product Name

The Products are organised and arranged within a three tiered approach as outlined above.

The Product names are structured using the above tiers.

2.2. Incident Prioritisation

2.2.1. Impact Assessment

Business Impact is generally based on the number of sites and/or customers affected by

the incident. The following table provides guidance in determining the Business Impact

rating to be applied to the incident ticket.

Table - Business Impact

IMPACT (Scale)

Criteria Rating

(DoE-wide) 50-100% of SITES and/or USERS affected* Extensive/Widespread

35-49% of SITES and/or USERS affected Significant/Large

10-34% of SITES and/or USERS affected Moderate/Limited

<10% of SITES and/or USERS affected Minor/Localized

*+VIP = DoE Secretary-level and above.


2.2.2. Urgency Assessment

Business Urgency is based on the customer being able to complete a business activity.

The following table provides guidance in determining the Business Urgency rating to be

applied to the incident ticket:

Table - Business Urgency

URGENCY

Criteria Rating

Essential work/function that cannot be performed by users is highly time sensitive.

The damage caused by the Incident increases rapidly. Critical

Essential work/function that cannot be performed by users is time sensitive.

The damage caused by the Incident increases considerably over time. High

Essential work/function that cannot be performed by users can be completed upon

service restoration.

The damage caused by the Incident increases marginally over time.

Medium

Work that cannot be completed by users is not time sensitive.

The damage caused by the Incident does not increase over time. Low

2.2.3. Priority Matrix

The incident priority will be set using a combination of impact and urgency described in the

following table.

Table – Prioritisation Matrix

PRIORITISATION MATRIX

URGENCY

Critical High Medium Low

IMP

AC

T

Extensive / Widespread Critical Critical High Medium

Significant / Large Critical High Medium Medium

Moderate / Limited High Medium Medium Low

Minor / Localised Medium Medium Low Low

The “ITD Major Incident Management Process” will be invoked for any Incidents set with

a “Critical” priority. As such, for any incident that has a “Critical” priority, the support

analyst must escalate the incident to their supervisor who would confirm the priority and

immediately notify the ITD Major Incident Manager on duty. The incident will be handled

according to the provisions of the ITD Major Incident Management (MIM) Process.


2.2.4. Priority Level Response Resolution table

Incident management service level objectives are based on priority and cover response

targets, customer updates and restoration targets.

Priority Submission method Response target Customer update

frequency Restoration target

Critical Phone <30 minutes 1 business hour 4 business hours

High Phone, email, fax or web form < 4 business hours 1 business day 2 business days

Medium Phone, email, fax or web form < 8 business hours 2 business days 4 business days

Low Phone, email, fax or web form < 16 business hours 5 business day 10 business days

The Impact/Urgency matrix below is used to determine the priority of an Incident.

2.2.5. Resolution Reason options table

The reason the customer had the query and what action was performed to either resolve

or fulfil the incident or request.

Additional resources Fault | bug | conflict Release | deploy | install

Advice | Info | Consult Functional Limitation Reset | Re-activate

Backup | Restore | Recovery Human Error Service Request Fulfilment

Cancel | Disable | Remove Maintain | Repair | Replace System Alerts & Monitors

Capacity Related Malware Testing

Change Related Migration | Relocation Training | Assist

Comms | Notification Non IT Cause Transfer | Refer

Configuration Outage Uninstall/Reinstall

Connectivity Patch | Update | Development Policy | Process

Duplicate Call Removal Process Related Issue User Provisioning

Enhancement Request Records Management


3. Incident Management Roles and

Responsibilities

The Incident Management process requires a number of specific roles with specific

responsibilities. They include Incident Analysts and Technical Support Analysts providing

response and resolution services and Support Team Leaders/Managers and Service

Delivery Managers for escalations where appropriate.

3.1. Process Owner

The Incident Management Process Owner has responsibility for:

Ensuring the Incident Management process is fit for use, fit for purpose and scalable

to be adopted across whole of DoE.

Ensuring that the Incident Management process consistently achieves the purpose

and objectives. Producing incident management information for operational support

and performance, customer engagement, stakeholder management, process

adherence and governance;

Monitoring the effectiveness of the Incident Management process;

Coordinating internal quality reviews to identify gaps in process compliance;

Developing of a continuous improvement plan for the Incident Management process;

Ensuring the alignment of the incident management process with all other processes.

3.2. Technical Support Manager/Team Leader

The Technical Support Manager/Team Leader can be covered by a number of functional

roles across the DoE and may also be referred to as a Queue Manager or Support Group

Owner. Such a role has responsibility for the following activities:

Overall queue management

Responsible for calls escalated to their team;

Responsible for allocating incidents within their team and ensuring they are dealt with

in an appropriate order;

Responsible for ensuring that all are responded to within OLA;

Responsible for ensuring all calls are resolved within Service Level Objective (SLO);

Responsible for escalations where any calls are likely to breach SLO;

Management of the customer experience and the resulting customer satisfaction.


3.3. Service Desk Manager

The Service Desk Manager can be covered by a number of functional roles across the DoE,

such as the leadership of the Service Desk, or Share Service Centre. Their responsibilities

include:

Queue management of incidents reported to their Service Desk or Support Group to

comply with OLAs and customer SLOs;

Management of the customer experience and the resulting customer satisfaction;

Managing the work of first level incident support staff and potentially second and third

level support functions also;

Managing compliance to the Knowledge Management components of Incident

Management process.

3.4. Technical Support Analyst

The Technical Support Analyst role can be covered by a number of functional roles across

DoE, examples include, but are not limited to; ITD Technical Support teams and ITD School

Support teams. Their collective responsibilities include:

The technical support analyst has responsibility for:

Responding to all incidents assigned to them within the service level target in their

OLA;

Resolving all incidents assigned to them within service level targets in the SLO;

Updating and reviewing Knowledge Articles (KAs) as and when appropriate;

Creating a framed KAs where one does not exist, update a KAs where appropriate

and/or rate a KAs and/or mark when a KAs requires a review;

Updating the work info section of the incident record with details of any investigations

and the results that were undertaken;

Updating the resolution details of the incident record when remediation and recovery

are complete;

Adding value to the customer experience and resulting customer satisfaction.

3.5. Incident Analyst

The Incident Analyst role can be covered by a number functional roles across DoE,

examples include, but are not limited to; the EDConnect Service Desk, or Shared Services

Centre. Their collective responsibilities include:


Recording all relevant incidents and/or service request details, contact details,

allocating categorisation, products from the Service Catalogue and business impact

and urgency to establish a priority;

Providing first level investigations and diagnosis including searching for relevant KAs

and similar incidents;

Creating Framed KAs where one does not exist, use KAs where appropriate and/or

rate a KAs and/or mark requires review;

Resolving those incidents or service requests where they are able;

Escalating incidents or service requests that cannot be resolved within agreed

timeframes;

Communicating with users keeping them informed with progress and impending

changes;

Adding value to the customer experience and resulting customer satisfaction;

Closing all resolved incidents or service requests;

Conducting customer satisfaction call-backs or surveys.

3.6. Customer or End-user

The Customer or end-user is responsible to:

Initiate Incidents via the approved channels

Supply accurate and complete information

Clarify and validate incident information when required;

Confirm successful resolution of incidents

3.7. Service Delivery Manager

The Service Delivery Manager is responsible for:

Reviewing incident records identified as “Potential Major Incidents”.

Using their delegated authority to declare a Major Incident and invoke the Major

Incident Management process.

Directing the actions required by the Major Incident Management process

3.8. Vendor Operations Lead

The Vendor Operations Lead is responsible for:

Managing the operational relationship with 3rd party hardware vendors

Handles all Customer Escalations with respect to Vendor Support


Working with DoE incident management operational staff to ensure the Vendor

Support sub-process is known and adhered to

3.9. RACI Matrix

Activity/role Customer Incident

analyst

Technical

support

analyst

Service

desk

manager

Technical support

manager/ team

leader

Process

owner

Governance End-to-End C/I C/I C/I C/I A/R

Report Incident R R R R R A/R

Review and Log Incident C R A/R

Classification and

Prioritisation C R A/R

Initial Diagnosis R R R R A

Investigation and

Diagnosis

R

R

R

R

A

Resolution and Recovery R R R R A

Accept Closure R


4. Incident Management Procedures

4.1. Level 1 Process Flow

The following diagrams illustrate Knowledge Management as it is embedded in the Incident Management Process workflow. Each Process flow

illustrates the responsibilities for each of the Levels within the Incident Management process.

Initial

diagnosis

Identification

logging,

categorisation,

prioritisation

Resolution &

closure

Investigation &

diagnosis

Incident identified

(from customer or

ICT source)

1. Log incident

2. Categorise

incident

3. Request or

incident?

4. Prioritise

incident

5. Major

incident?

Request

Yes

Incident

6. Knowledge

framing

7. Knowledge

searching

8. Knowledge

matching

8a. KA exists?

10. Escalation

required?

8b. KA search

policy

exceeded?

8d. Solution

identified?

10a. Knowledge

rating and/or

update

10b. Knowledge

usage

8e. Create a new

WIP KA

8c. Perform initial

diagnosis & update

work log

No

No

No

Yes

Yes

No

13. Review and

update linked

knowledge

10c. Assign

Incident to

relevant group

11. Knowledge

usage8f. Solution

Successful?

12. Solution

successful?

12a. Rate KA & flag

any modifications

requirements

8g. Create a new

draft KA

14. ‘Use’ KA for

resolution and

resolve indicent

Resolved

No

Level 2/3

No

Yes

Yes

Yes

No

ProceduresProcess Stage

KeyKnowledge

management-

specific process

step

Incident

management-

specific process

step

Level 1: ICT Incident Management process

(inc Knowledge Management) V0.3

4a. Parent

incident

exists?

4b. Link to parent

incidentYes

No

End

9. Hardware

fault confirmed?

Yes

No

Yes

Request

Management

process

5a. Major

Incident

Management

process

9a. Vendor

Support

Process

A

B

A

B


4.2. Incident management activity descriptions

This section of the document lists the specific activities as referenced in the Incident

Management workflow diagram and provides some level of detail as to how these activities

are performed.

Procedure

Activity

Number

Procedure

Activity Procedure Activity Description

Detailed Work

Instruction / Other

reference

(Technology

Specific)

0 Incident

Identified

An incident has either been reported by a colleague or

detected by the IT organization.

1 Log Incident

Incidents will be fully logged regardless of whether they are

raised through a Service Desk telephone call, business

personnel “walk up”, or whether it was automatically detected

via an event alert.

DOC12IM01-Log-

and-Assign-or-Log-

and-Resolve

DOC15IM01-

Searching-Locating-

and-Linking-a-Valid-

Customer-Profile

DOC18IM01-Using-

the-Alternate-

Contact-Fields

DOC13IM01-How-to-

Correctly-Update-

Remedy-Profile-Data

2 Categorise

Incident

A suitable incident categorization code is selected and priority

is allocated so that the exact type of the support request is

recorded. This allows Service Desk staff to research the

correct known solutions and immediately escalate critical

incidents as required.

Refer to Work

Instruction links at

“Procedure Activity 1”

3 Request or

Incident?

The support analyst should review the nature of the support

request and select the appropriate ‘Query’ field option which in

turn will determine if the ‘Record Type’ field is set as an

‘Incident’ or ‘Service’ Request’, then the Request management

process should be followed. If the query is an incident then the

step 4 should be followed.

Refer to Work

Instruction links at


4. Prioritise

Incident

A priority will be automatically assigned based on a matrix

defined by the selections made when choosing the appropriate

‘Urgency’ and ‘Impact’.

Refer to pages 8 and

9 of this document.

https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC12IM01-Log-and-Assign-or-Log-and-Resolve.pdf



https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC15IM01-Searching-Locating-and-Linking-a-Valid-Customer-Profile.pdf




https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC18IM01-Using-the-Alternate-Contact-Fields.pdf



https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC13IM01-How-to-Correctly-Update-Remedy-Profile-Data.pdf




Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

4a. Parent Incident

Exists?

If there are multiple incidents of the same nature a Parent

Incident is created and communicated. As an example, a

Parent ticket may be created during a Major Incident event,

whereby the first Incident Record captured would become the

Parent, to which Child incidents (Reports about the exact

same incident) will be linked via a “Duplicate Of” relationship

type.

4b. Link to Parent

Incident

Child linked to Parent Incident with the appropriate

relationship.

5. Major

Incident?

Does the priority coupled with the other details of the incident

qualify as a potential Major Incident? If they do, then the Major

Incident Management process at step 5a should be followed. If

not, then step 6 should be followed.

5a

Major incident

Management

Process

The Major Incident Management process will provide guidance

as to:

Sending “Early Alert” communications

Contacting the Major Incident Phone

Validating and confirming actual business priority

Determining whether:

o a Major incident is to be declared, therefore

invoking the remaining steps in the MIM Process

to manage the Major incident to resolution.

o a Major Incident is NOT to be declared, therefore

handing the Incident back to the regular incident

Management process to manage to a resolution

6 Knowledge

Framing

The analyst should seek to capture the question or symptom in

the language of the customer (customer’s context), not

necessarily every word verbatim but rather the key essence of

the question or symptom (Complete thoughts, not complete

sentences). The text entered will be used to search the

knowledgebase, so the length of text string should be limited to

only 2 lines.

DOC6KM06-

Creating-Knowledge-

Articles

https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents?viewpath=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents&id=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions%2FDOC6KM06%2DCreating%2DKnowledge%2DArticles%2Epdf&parent=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions




Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

7 Knowledge

Searching

Searching the Knowledgebase should be the first thing that

occurs in the support workflow, to ensure that the support

analyst will leverage off the knowledge already gathered by the

organisation and reduce the risk of re-solving issues that are in

progress or have previously been solved. The act of searching

forms the basis for refining and improving knowledgebase

search ability and findability. Keywords and/or additional

phrases can be added to the search string to enrich or filter

search results. Unsuccessful search strings should be

recorded in the system logs and used to frame new WIP (Work

In Progress) Articles.

8 Knowledge

Matching

Knowledge articles returned in the search results should be

viewed for relevancy. Irrelevant knowledgebase articles should

be updated to reduce the likelihood of returning at the top of

the search results. Relevant KAs should be updated to

improve its knowledge search ranking.

8a KA Exist?

If a suitable knowledge article displays in the search list, then

move to step 9. If there are no suitable KAs then move to step

8b.

8b Search Policy

Exceeded?

There are no hard and fast rules on the number of acceptable

searches that should be performed before creating new

knowledge articles. Each organisation will have their own

policy, but a general rule of thumb is no more than 3. If you are

unable to find a suitable KA within this time, then a new WIP

article should be created and linked to the incident record and

escalated to 2nd/3rd level support. Any duplicate KAs found

should be merged together as part of weekly knowledgebase

maintenance tasks.

8c

Perform Initial

diagnosis &

Update Work

If there are no suitable KAs, then the support analyst should

perform Initial diagnosis which may involve

Validation and Replication of the issue

Capture the environment

Testing thoughts, concepts and scenarios.

Consider workarounds.

Each activity performed should be clearly recorded within the

incident work log within the incident record, along with

outcomes of each activity performed or attempted.

8d Solution

Identified?

If no resolution is found move to step 8e. If a resolution is

found immediately, then move to step 8f.


Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

8e

Create

Knowledge

(WIP Status)

Before escalation, the incident record should be updated with

the appropriate information from steps 2, 4 and 6. A new Work

in Progress (WIP) KA should be created from the details of the

incident record by selected the ‘Create Knowledge’ Button.

This will copy the incident content into a new KA and then

link it to the incident record before escalation to 2nd or 3rd level

support.

All of the required fields should be completed with the

exception of ‘Cause’ and ‘Resolution’. This is because we are

yet to find a resolution for the incident. The resolution will be

entered by the support team who actually resolves the

incident.

The KA’s status should be specified as Work In Progress

(WIP) before saving. The status will immediately notify other

support analysts who encounter the same issue, that the

support organisation is aware of the issue, and they should

also link the WIP KA and escalate the incident as well.

Refer to Work

Instruction link at


8f Solution

Successful?

Has the incident been resolved? Customer validation is

required to qualify this.

8g Create a new

DRAFT KA

If a solution is found during step 8c, then the solution that has

been verified by the customer should be recorded into the

Resolution field of the Incident Record.

When all of the Resolution data has been finalised, the support

analyst should create a knowledge article from the Incident

Record by selecting the ‘Create Knowledge’ button. This will

automatically capture the;

Framed Question / System,

The Environment details,

The cause,

The work around or solution

The operational classifications, and,

The product classifications into a new Knowledge

Article.

The knowledge Article status should be set to ‘Draft’.


Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

Saving the new KA will automatically link the KA to the Incident

Record which should be viewable via the relationships tab in the

incident record.

9 Hardware fault

confirmed?

Diagnostic and troubleshooting steps are to be performed.

Steps within the relevant KA(s) will provide guidance as to the

diagnostic and troubleshooting steps relevant to the issue

reported. If after diagnostic and troubleshooting steps:

a) the issue has been identified as been a hardware fault,

then, capture all troubleshooting steps taken and their

outcomes within the notes of the ticket and progress to step

9a to follow the Vendor Support Process.

b) the issue has been identified NOT to be a hardware fault,

then capture all troubleshooting steps taken and their

outcomes within the notes of the ticket an then proceed to

step 10.

9a

Vendor

Support

Process

The Vendor Support process will provide guidance on:

1. Confirming if the device is within scope for support

2. Confirming if the device is within warranty or not

3. Confirming if it relates to an out-of-warranty (OOW)

repair.

4. Configuring the Incident ticket with required details,

documented or visual attachments,

5. Assigning the ticket to ITD Vendor Support queue

and/or direct to the Vendor

Vendor Support

Process

10 Escalation

Required?

Some knowledge articles are procedural based; they may

notify 1st level that incidents of this nature need to escalate to

2nd or 3rd level support. If escalation is required, then the KA

should be rated (10a) and then escalated in accordance to the

escalation procedure. Prior to escalation (Assignment to

another Support Group), ensure the relevant details have been

validated with the customer and captured within the ticket

(UserID, contact details, troubleshooting/request details etc.).

Refer to Work Instruction for specific guidance.

DOC1IM10-Content-

Requirements-For-

Ticket-Escalations

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


https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC1IM10-Content-Requirements-For-Ticket-Escalations.pdf




Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

10a

Knowledge

Rating &

Update

It is good practice to rate the usefulness of knowledge articles

when viewed or used. This ensures the article is still relevant

and helpful, and also draws attention to authors who need to

improve their authoring skills.

Concurrently if the Support analyst has the appropriate rights

and privileges they should make the required updates

immediately. If the Support analyst does not have the

appropriate rights and privileges they should flag the

knowledge article for update, and comment on the desired

changes.

10b Knowledge

If a KA was available and step 9a was completed, the

knowledge article should be linked to the incident record. This

is achieved by selecting the ‘Use’ button in the KA. The KA

will record into the Relationships tab of the incident.

10c

Assign

Incident

to Relevant

Group

The incident record is assigned to the appropriate 2nd or 3rd

level support group.

DOC19IM10C-

Choosing-the-Most-

Relevant-Assigned-

Group-When-

Assigning-a-Ticket

11 Knowledge

Usage

Relevant Knowledge articles should be viewed, and linked to

the incident record by selecting the ‘Use’ button in the KA.

Subject to the support analyst’s Knowledge role, the

Knowledge Articles should have been rated, updated or

flagged for update where appropriate (see step 9a).

12. Solution

Successful?

Has the incident record been resolved? Customer validation is

required to qualify resolution.

12a

Rate KA & flag

any

modification

requirement

The solution specified in the KCS article was not successful.

The KA should be rated by the Support analysts and modified

if appropriate. It’s also worth flagging the KA for an update,

because you will need to escalate the incident to 2nd or 3rd

level support.

13

Review &

Update Linked

Knowledge

Article

The solution specified in the KCS article was successful. KCS

defines reuse as review. If the knowledge article is used, then

it should be validated as relevant. If the knowledge article is

out of date, unclear, or hard to read, then it should be updated

immediately, or flagged for review.

https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Forms/AllItems.aspx?viewpath=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents&id=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions%2FDOC19IM10C%2DChoosing%2Dthe%2DMost%2DRelevant%2DAssigned%2DGroup%2DWhen%2DAssigning%2Da%2DTicket%2Epdf&parent=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions






Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

14

Use KA for

resolution and

resolve the

incident.

Clicking on the KA’s ‘Use’ button will automatically copy the

Resolution categories into the incident’s resolution tab. It will

also copy the ‘Customer Friendly Resolution’ into the incident’s

‘solution’ field.

DOC14IM14-

Populating-the-

Resolution-Field-

With-High-Quality-

Infromation

https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents/Work_Instructions/DOC14IM14-Populating-the-Resolution-Field-With-High-Quality-Infromation.pdf






4.3. Level 2 Process flow

Initial

diagnosis

Resolution &

closure

Investigation &

diagnosis

1. Assess assigned

incident

2. Correctly

assigned?

3. KA attached to

incident?

12a. Change

Management

Process

4. Search knowledge

base for

corresponding KA in

your group

7. Apply solution as

per KA

8. Solution

successful?

8a. Requires

escalation?

8b. Refine KA

Yes

11. Complete/flag any

necessary

amendments to KAs

9. Rate KA and (if

required) flag for

update

5d. Solution

successful?

10. ‘Use’ KA to

resolve incident

5f. Update KA and (if

applicable) promote

to draft

13. Resolve incident

KM review &

mod.

ProceduresProcess Stage

Key Knowledge management-specific process stepIncident management-specific process step

Inc. Mgmt.

level 1

3a. Was a KA

available?

2a. Update incident,

attach KA & assign

to appropriate group

3b. Flag that a viable

KA was not used

Yes

No

No

Escalated group

perform the

same sequence

Yes

A

5. KA exists in

your group?

Yes B

A

B

12. Change

required?

5a. Frame/draft a KA5b. Investigate

incident

5c. Solution

found?

5e. Required

escalation?

5g. Assign visibility/

create KA for

previous level

5h. ‘Use’ KA to

resolve incident

Yes

No

No

Yes

No

No Yes

Yes

No

No

No

Level 2 / 3: ICT Incident Management Process (inc. Knowledge Management) V0.2

6. Hardware fault

confirmed?

Yes

No

6a. Vendor

Support ProcessYes


4.4. Incident management activity descriptions

This section of the document lists the specific activities as referenced in the Incident

Management workflow diagram and provides some level of detail as to how these activities

are performed.

Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

1

Assess

assigned

incident

This is a pre-defined process that will take into account

details of the incident record to determine the necessary

party to escalate to. At this stage Operational Level

Agreements should be triggered to ensure a fair response

time so that resolution time is met.

2 Correctly

assigned?

The escalation group should analyse the content of the

Incident record and determine if the record was correctly

assigned.

Incorrect assignment would require judgement on behalf of

the support analyst and adherence to the incident

management policy which states that the owner of the

incident is the current assignment group.

All actions should be made with the customer’s experience

in mind. If the escalation group knows who should receive

the incident they should assign it to them immediately. If

they do not know the correct assignment group, they

should assign it back the previous group.

2a

Update incident,

attach KA &

assign to

appropriate

group

Each of the support groups involved with the incident

handling will investigate and diagnose what has gone

wrong – and all such activities need to be recorded into the

work log of the incident record. This includes details of any

actions taken to try and resolve or re-create the Incident

3

KA

attached to

incident?

Each escalated incident should contain a linked KA.

The Incident record will provide a graphical indication that a

KA has been attached.

The types of KAs that should be attached are:

1. A new framed KA

2. A Draft KA that has been ‘Flagged for Update’

A Published KA that has been ‘Flagged for Update’.

If there is not a KA attached then this will be recorded as a

breach of the KM process, and step 3a should be followed.

DOC2KM03-

Identifying-and-

Updating-Framed-

KAs

https://schoolsnsw.sharepoint.com/sites/ServiceThinking/cop/Incident/Shared%20Documents?viewpath=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents&id=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions%2FDOC2KM03%2DIdentifying%2Dand%2DUpdating%2DFramed%2DKAs%2Epdf&parent=%2Fsites%2FServiceThinking%2Fcop%2FIncident%2FShared%20Documents%2FWork%5FInstructions





Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

3a Was a

KA available?

There are two scenarios where the escalation group should

investigate Knowledge linking.

1. There was no KA for the previous group to use, so

there should have been a Framed KA.

2. There was linked KA but it was not relevant to the

incident.

In both cases the escalation group should double check if

there actually was a relevant KA available for this group to

use.

If there was not, then the escalation group should create a

framed WIP article immediately and make it available to the

previous group. If there was relevant knowledge they

should indicate that Knowledge was not used (See 3b).

3b

Flag that a

viable KA was

not used

In the case where the relevant knowledge was available

but not used by the previous support group, there should

be the ability to indicate that knowledge was not used. The

question needs to be asked: ‘Why was it not used?

The answer could be:

Lack of adherence to the KM policy

The relevant KA was not searchable or findable and will

need to be enhanced. For both scenarios ‘Knowledge was

not used’ should be noted within the incident record.

4

Search

Knowledge

Base for

corresponding

KA in your group

It is common for 2nd and 3rd level support teams have

knowledge articles segmented from other teams. This

could be due to additional skills, privileges or tools required

to perform diagnostic and resolution activities. On receiving

escalated support event records, they should immediately

check their own knowledge repository to ensure they

leverage off the knowledge already captured by the

organisation. They should use, create, update and improve

any new knowledge required.

5 KA Exists in

your group?

If there is not a relevant KA for the escalation group then

step 5a should be followed. If there is a relevant KA the

step 6 should be followed.


Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

5a Frame / Draft a

KA

Before additional investigation and diagnosis is performed,

the incident details should be copied into a new Work In

Progress (WIP) KA by selecting the ‘Create Knowledge’

Button. This will copy the incident content into a new KA

and then link it to the incident and will be made available to

the escalation group.

All of the required fields should be completed with the

exception of ‘Cause’ and ‘Resolution’. This is because we

are yet to find a resolution for the incident. The resolution

will be entered by the support team who actually resolves

the incident.

The KA’s status should be specified as Work In Progress

(WIP) before saving.

The status will immediately notify other support analysts

who encounter the same issue that the support

organisation is aware of the issue, and they should also link

the WIP KA and escalate the incident as well.

DOC6KM06-

Creating-Knowledge-

Articles

5b Investigate

incident

Investigate and diagnose what has gone wrong – and all

such activities need to be recorded. This includes details

of any actions taken to try and resolve or re-create the

Incident

5c Solution found?

Is there a relevant Draft or Published KA available or are

you able to identify a potential solution that may not yet be

documented? If yes, the follow step 5d. If no, then follow

step 5e

5d Solution

successful?

If there is a relevant KA, was the solution successful?

If yes, follow step 5f. If no, then follow step 5e

5e Requires

escalation?

Is further investigation required?

If yes, follow step 2a. If no, follow step 5b.

The loop back to step 5b occurs in the scenario where you

have tried one potential solution, found it to be

unsuccessful, then seek to continue investigating another

potential solution rather than escalating to another support

group.

Prior to escalation, ensure the relevant details have been

validated with the customer and captured within the ticket

(UserID, contact details, troubleshooting/request details

etc.). Refer to Work Instruction for specific guidance.

DOC1IM10-Content-

Requirements-For-

Ticket-Escalations

DOC19IM10C-

Choosing-the-Most-

Relevant-Assigned-

Group-When-

Assigning-a-Ticket













Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

5f

Update KA and

(if applicable)

promote to Draft

If the solution in the existing KA was successful, then the

KA should be promoted to Draft, promoted to Published,

Rated, updated, or flagged for update. Or, if you created a

WIP (“Framed KA) at step 5a, then ensure the solution is

detailed within the framed article and that the articles is

saved and promoted to a Draft or Published status.

5g

Assign visibility /

create KA for

previous level

It should be considered as to which groups in the support

chain should have permissions to view the KA. There may

be a need to create multiple KAs for the one issue but in

the context of each support group. Level 1 KAs could

mention preparation and escalation procedures, and Level

2/3 KAs could mention resolution and recovery.

5h ‘Use’ KA to

resolve incident

If the KA used by the escalation group was successful,

then the KA should be used and related to the incident

record by selecting the ‘Use’ button. This will auto populate

the incident resolution details, and created a link in the

incident’s relationship tab.

6 Hardware fault

confirmed?

Steps within the relevant will provide guidance as to the

diagnostic and troubleshooting steps relevant to the issue

reported.

If after following these steps the issue has been identified as

been a hardware fault, then, capture all troubleshooting

steps taken and their outcomes within the notes of the ticket

and progress to step 9a to follow the Vendor Support

Process.

If after following these steps it was determined NOT to be a

hardware fault, then capture all troubleshooting steps taken

and their outcomes within the notes of the ticket an then

proceed to step 10.

6a Vendor Support

Process

The Vendor Support process will provide guidance on:

6. Confirming if the device is within scope for support

7. Confirming if the device is within warranty or not

8. Confirming if it relates to an out-of-warranty (OOW)

repair.

9. Configuring the Incident ticket with required details,

documented or visual attachments,

Vendor Support

Process




Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

Assigning the ticket to ITD Vendor Support queue and/or

direct to the Vendor

7 Apply solution

as per KA

If the escalation group has a relevant Draft or Published KA

(Step 5) they should apply the solution to resolve the

incident.

8 Solution

successful?

Did the applied solution successfully resolve customer’s

incident? If Yes, then follow step 8. If No, then follow step

8a.

8a Requires

escalation?

Is further escalation required?

If Yes, then follow the on page reference “A” and complete

step 2a.

8b Refine KA

Given the applied solution did not successfully solve the

issue, the KA should be updated to specify the exception

details, and move to step 5b

9

Rate KA and (if

required) flag for

update

If the solution in the KA was successful, then the KA should

be promoted to Draft, promoted to Published, Rated,

updated, or flagged for update.

10 ‘Use’ KA to

resolve incident

If the KA used by the escalation group was successful,

then the KA is to be applied to the incident record by

selecting the ‘Use’ button. This will auto populate the

incident resolution details, and created a link in the

incident’s relationship tab.

11

Complete/Flag

any necessary

amendments to

KAs

Finalise any last minute updates to the KA or flag for

update, and/or add any appropriate comments.

12 Change

Required

Is a change request required to resolve the incident? If a

change is required to resolve the incident, then follow step

11a. If not then follow step 12.

12a Follow Change

Process

Follow the agreed Change Management process. Upon

completion of the change, validate with the customer that

the change and solution applied has now resolved their

incident.

13 Resolve Incident

After resolution confirmation from the customer. Follow the

Incident Resolution procedures as specified in the incident

management policy.

DOC14IM14-

Populating-the-

Resolution-Field-





Procedure

Activity

Number

Procedure


Detailed Work

Instruction / Other

reference

(Technology

Specific)

With-High-Quality-

Infromation

5. Process critical success factors and KPIs

The following table illustrates the Incident Management Critical Success Factors and Key

Performance Indicators.

CSFs KPIs

Resolve incidents as quickly as

possible minimising impact to the

business

Increase in the percentage of incidents resolved at the Service Desk without

reference to other levels of support

Decrease in mean elapsed time to achieve incident resolution or circumvention

(by impact code)

Increase in percentage of incidents handled within agreed response time as per

service level targets

Maintain customer satisfaction with

IT services

Decrease in backlog of incidents for each service / customer

Decrease in number and percentage of major incidents per service / customer

Increase visibility and

communication of incidents to

business and ICT support staff

Decrease in the number of Service Desk calls or other contacts from customers

for incidents already reported

Decrease in the number of Service Desk calls for status updates on incidents

already reported

Align incident management

activities and priorities with those of

the business

Increase in percentage of incidents handled within agreed response time as per

service level targets

5.1. Reporting

Refer to the current endorsed incident management governance report from the ITD Service

Management team.

