INCIDENT MANAGEMENT

PROCESS VERSION 7.0

Document Owner Security Level

Kieron Jones Internal use only

Incident Management Process

Version: 7.0

TABLE OF CONTENTS
1. DOCUMENT CONTROL....................................................................................................4 1.1 DOCUMENT KEY................................................................................................................4 1.2 REFERENCE DOCUMENTS.....................................................................................................4
1.2.1 ISE Reference Documents..........................................................................................4

1.3 DOCUMENT STRUCTURE......................................................................................................4 2. POLICY..............................................................................................................................5 2.1 OVERVIEW........................................................................................................................5 2.2 WHAT IS AN INCIDENT?.......................................................................................................5 2.3 WHAT IS A SERVICE REQUEST?............................................................................................5 2.4 WHAT IS INCIDENT MANAGEMENT?.........................................................................................5 2.5 RAISING INCIDENTS.............................................................................................................6
2.5.1 Requester is unable to raise an Incident.....................................................................6 2.5.2 Incident raised proactively..........................................................................................6 2.5.3 Out of Hours................................................................................................................6

2.6 RELATIONSHIP WITH OTHER SERVICE MANAGEMENT PROCESSES....................................................6

2.6.1 Problem Management.................................................................................................6 2.6.2 Change Management..................................................................................................6 2.6.3 Security Management.................................................................................................7

2.7 SCOPE............................................................................................................................7 3. REVIEWS...........................................................................................................................7 3.1 INCIDENT REVIEWS.............................................................................................................7 3.2 MAJOR INCIDENT REVIEWS...................................................................................................8 3.3 POLICY & PROCESS REVIEWS..............................................................................................8 4. REPORTING......................................................................................................................8 5. INCIDENT MANAGEMENT PROCESS.............................................................................9 5.1 INCIDENT PROCESS.............................................................................................................9 5.2 MAJOR INCIDENT PROCESS ...............................................................................................13 5.3 SERVICE REQUEST PROCESS.............................................................................................16 6. APPENDICES..................................................................................................................20 6.1 KEY ROLES AND RESPONSIBILITIES......................................................................................20
6.1.1 SCEE MIS Service Desk...........................................................................................20 6.1.2 Service Desk Manager (Incident Manager)...............................................................20 6.1.3 Requester..................................................................................................................20 6.1.4 MIS Support Teams..................................................................................................20 6.1.5 Major Incident Manager.............................................................................................21 6.1.5.1 Core Support Hours.......................................................................................21 6.1.5.2 Primary Responsibility...................................................................................21 6.1.5.3 Pool 1.............................................................................................................21 6.1.5.4 Pool 2.............................................................................................................21 6.1.6 Technical Major Incident Manager............................................................................21

6.2 PRIORITIES.....................................................................................................................22
6.2.1 Incidents....................................................................................................................22 6.2.2 Service Requests......................................................................................................22

6.3 ESCALATIONS..................................................................................................................23
6.3.1 Notifications...............................................................................................................23
Page 2 of 25

Incident Management Process

Version: 7.0

6.4 LIFE CYCLE....................................................................................................................24 6.5 RESOLUTION CODES.........................................................................................................24

6.5.1 Incident......................................................................................................................24 6.5.2 Service Request........................................................................................................24

6.6 CATEGORIES...................................................................................................................25 6.7 GLOSSARY.....................................................................................................................25

Page 3 of 25

Incident Management Process

Version: 7.0

1.
1.1

DOCUMENT CONTROL
Document Key
LC refers to the local controls identified as existing within this process. Details of these controls are provided in the Risk and Control Matrix (RCM) available in Risk Navigator. The step numbers in the left hand column of the process table in Section 5 correspond to the numbers in the flowcharts referenced in this section.

1.2
1.2.1

Reference Documents
Incident Management Process Flow Document (DMS) SDLC Methodology Document Problem Management Process Documentation (DMS) Change Management Process Documentation (DMS) Security Incident Handling Documentation (DMS) SMaRT v2.1 Category List (DMS) Service Catalogue (DMS) ISE Reference Documents The following documents can be found at http://isseweb.eu.sony.com ISE Incident Management Process Documentation (BSM/ISDG Processes) ISE Major Incident Management Process Documentation (BSM/ISDG Processes) ISE Service Request Process Documentation (BSM/ISDG Processes) ISE SLA Documentation (Central HelpDesk/SLA)

1.3

Document Structure
This document covers:
Page 4 of 25

Incident Management Process

Version: 7.0

The policy that governs Incident Management Review and compliance audits Reporting requirements Detailed description of the Incident management process including the process step, its description, and the role responsible for ensuring the step is performed. Appendices providing process supporting information

2.
2.1

POLICY
Overview
LC051 This is a mandatory process that all staff and external parties must agree to follow in order to manage Incidents on SCEE systems. Compliance with this process is specifically detailed in the external parties contract. In house employees are notified of the policies and procedures to ensure compliance. The Incident Management process applies to all SCEE systems, including SAP, PIN Point, SID and all infrastructure.

2.2

What is an Incident?
An Incident is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.

2.3

What is a Service Request?

A Service Request is a standard administrative/user support request which is not an incident, does not impact SOX significant systems, and is not within the scope of Change Management.

2.4

What is Incident Management?

Incident Management ensures that all Incidents are resolved and service is restored as soon as possible, according to defined priorities and within agreed timescales, with minimum disruption to the business. Incident Management covers both Incidents and Service Requests, due to Service Requests following a similar life cycle/process flow to that of Incidents. Throughout this document, the term Incident is used to cover both, or either, of these. Incident Management is provided by Service Desk Analysts (SDAs) and support groups. As users contact the Service Desk (SD), the relevant records are created; these are updated and assigned to different groups as specific expertise is required. During the life of an Incident, it will be set to various statuses (see Life Cycle, p24) which will reflect its progress and allow for reporting on how Incidents are handled. LC055 During the life of an Incident, it may be assigned to different groups for resolution, but the Service Desk retains ownership, due to their responsibility for monitoring, and escalating where necessary, all Incidents to ensure that deadlines and SLAs are not breached.

Page 5 of 25

Incident Management Process

Version: 7.0

2.5

Raising Incidents
LC055 All Incidents must be recorded and managed via the Service Management tool.

2.5.1

Requester is unable to raise an Incident If a requester is unable to raise a call (due a fault, which prevent access), the Service Desk must raise an Incident on their behalf. Should an Incident be raised in this situation, the Service Desk is responsible for correctly representing the requester in the appropriate fields in the Service Management tool. Incident raised proactively There are many occasions when MIS recognise a fault or issue well before the general user community will. In such cases, MIS should raise Calls under their own name (as requester) to record that the issue has occurred, and to ensure that the Incident is resolved (for example monitoring alerts). In these cases, the Service Desk are responsible for correctly representing the Company Affected within the Incident to ensure MIS management have a clear understanding of requirements and demands, through effective reporting.

2.5.2

2.5.3

Out of Hours Incidents which occur out of hours should be logged as soon as possible (and certainly no later than the next working day). If the Service Desk is oncall when the issue occurs, the Incident must be raised immediately, and managed through to resolution. If the Service Desk is not operating and MIS support teams are notified of an issue via alerts, the oncall support team member should raise the Call as soon as possible, in line with their teams out of hours operating procedures. The Service Desk will raise the appropriate Incident record as soon as possible. All relevant information should be included in the Incident (time of occurrence, all action taken, time of resolution etc).

2.6
2.6.1

Relationship with other Service Management processes

Problem Management Incident Management interfaces with Problem Management to detect the underlying causes of Incidents (and to provide their subsequent prevention). However, the resolution of an Incident takes priority over a Problem. Change Management Incident Management interfaces with Change Management to control any changes required to resolve Incidents.

2.6.2

Page 6 of 25

Incident Management Process

Version: 7.0

2.6.3

Security Management Incident management interfaces with security management to track any incidents that are deemed a security risk.

2.7

Scope
Incident Management is responsible for: Production Environments Incidents raised/managed by External Parties Operations Testing Environments (OTE) Batch Jobs Job schedules Note: Any Incidents caused/raised by an external party are within scope and must be logged within the Service Management tool. This is reflected in SLA and contracts

3.

REVIEWS
LC055 Scheduling of all reviews and compliance audits will be recorded in the DMS. The output of all reviews will be documented and recorded for auditing purposes. Incident records will be archived for a period of seven years. Any changes required to policy and or process documentation after a review has taken place must be recorded and approved following the change management process.

3.1

Incident Reviews
1) The Service Desk Manager will allocate a number of MIS Technical teams to the Service Desk Analysts (SDA) for ownership. Each SDA will be responsible for the open incidents assigned to each respective group to ensure that they are being managed, updated and escalated in a timely manner. The SDA will escalate any incidents that are not being actioned to the Service Desk Manager to own and escalate further if necessary. Any issues experienced will be discussed in the Weekly Service Desk Meeting. 2) Closed Incidents will be reported on Daily by the Service Desk Manager; this report will note any procedural failures and missed priorities as well as the following: Quality and quantity of information contained in the Incident (work history and resolution) Incident prioritisation Correct Support team allocation Incident escalation, where relevant Timely updates Linking of Incidents to related Problems and Changes Identification of any Incidents which have not followed process or policy

Page 7 of 25

Incident Management Process

Version: 7.0

The Closed Incident Review report will be presented on a weekly basis to the Service Delivery Manager and will be used to implement defined Key Performance Indicators (KPIs) and Service Improvement initiatives.

3.2

Major Incident Reviews

Once resolved, all Major Incidents undergo a review by the Major Incident Manager, and Problem Management. Considerations are to be given to what happened, what can be done better next time, was the right thing done at the right time, can Major Incident process be improved, etc. The outcome of these reviews may feed into the regular Policy and Process review, and potentially may prompt the need for an immediate review of these documents.

3.3

Policy & Process Reviews

The Service Desk Manager must review the Incident Management policy and process at least once a year. Input should be sought from a wide range of sources, including: The Service Level Manager The Problem Manager The Change Manager The Security Manager The Service Desk MIS service users

The review of the process should include: The usability of the process The efficiency and effectiveness of the process Interfaces into other processes The appropriateness of the KPI/metrics currently defined for the process

Any required changes must be approved by MIS Management prior to reissuing the updated documentation. The timing of the annual review is to be confirmed.

4.

REPORTING
Incident Management reports will be produced monthly, including the following facts and statistics: Number of Incidents and Service Requests requested by priority Number of Incident closed Number of Major Incidents Number of Incidents completed on time and those not completed on time

Note: The Service Desk Manager may produce ad-hoc reports as and when required. Details of the reports to be produced for service level reporting, and the frequency of their production, are defined in the Service Level Agreement under Service Reports.
Page 8 of 25

Incident Management Process

Version: 7.0

5.

INCIDENT MANAGEMENT PROCESS

The steps in the following table explain the Incident Management process flow diagram. The step numbers in the left hand column correspond to the numbers in this diagram.

5.1
Step

Incident Process
Description A call is created by the Requester, either through SMaRT, telephone or e-mail. An Incident is created/linked, by: Service Desk created/linked on behalf of requesters (SMaRT Call/phone/email), or due to a non-planned event/alert being raised/identified MIS Analyst The process continues at Step 3. Incident is categorised, and prioritised (see Priorities, p22, and Categories, p25). Should the priority change throughout the Incidents life cycle, the requester is notified. If the Incident is prioritised as a Major Incident (Priority 1) the MIS managers are notified automatically by email. The process continues at Step 4. If it has been identified that the issue is potentially of a critical nature (as defined in Priorities, p22), the Service Desk notifies the Service Desk Manager, and the Major Incident process is invoked. If the issue does not seem to be of a critical nature, the process continues at Step 5 If it has been identified that the issue is security related (as defined in Security Incident documentation), the Service Desk notifies the Security Manager, and the Incident is either handled in SMaRT the same way a normal incident would, or due to confidentiality issues, cross referenced from SMaRT to a separate database accessible only to the security manager. The process continues at Step 37. If the incident does not seem to be a security issue, the process continues at Step 6 or 19. If the Service Desk can deal with the Incident, the process continues at Step 7. If the Service Desk cannot deal with the Incident, the process continues at Step 13. The Incident is assigned to the SDA and they investigate All updates/findings are noted in the Incident. If required, further information should be gathered from the requester. Investigation may include raising issues with External providers (e.g. ISE. For incidents that are to be resolved by ISE, please see ISE SLA document and ISE Incident, Major Incident and Service Request
Page 9 of 25

1 Call raised 2 Incident raised

Responsibility Requester Service Desk / MIS Analyst

3 Categorise & prioritise LC052

Service Desk / MIS Analyst

4 Potential Major Incident? LC054 5 Potential Security Incident?

Service Desk/ MIS Analyst

Service Desk/ MIS Analyst

6 Can the SD deal with Incident? 7 Assign to SDA & investigate

Service Desk

Service Desk

Incident Management Process

Version: 7.0

8 Requester responds to info requests?

9 Solution identified? LC054

10 Change required?

11 Update Incident

12 Resolve Incident

13 Assign to relevant support team

14 Team picks up Incident 15 Correctly assigned?

Process documents, referenced in the Reference Document section). The process continues at Step 8. If the requester replies with required information within the appropriate timeline (as prompted), the process continues at Step 9 If the requester does not reply within the appropriate timeline (3 attempts are made to contact requester), process continues at Step 12, noting that contact could not be made with requester. If a solution is identified, the process continues at Step 10 If a solution is not identified within an appropriate amount of time, the process continues at Step 6. Note - Incidents are monitored regularly by the Service Desk to ensure that they are resolved within a timely manner. Should an Incident reach a defined escalation point, the Service Desk will escalate appropriately (see Escalations, p23). If a change is required the process continues at Step 11. If a change is not required, the process continues at Step 12. The Incident is updated with the relevant information. The process moves into Change Management. Once the Incident has been through Change Management, the process continues at Step 12. The Incident is reviewed to ensure that all required information is included. The resolution details are entered into the Incident, and the Incident is set to Resolved. The process continues at Step30. The Incident is assigned to the relevant support team. The Service Desk retains responsibility/ownership of the Incident throughout the duration of the Incident (including prompting for updates). The process continues at Step 14. The assigned team picks up and reviews the Incident. The process continues at Step 15. If the Incident has been correctly assigned to this team, the process continues at Step 19. If the Incident has not been correctly assigned to this team, the process continues at Step 16. If the correct support team is known, the process continues at Step 17. If the correct support team is not known, the process continues at Step 18 The Incident is reassigned to the relevant support team If assigned by a Support team member, the Service Desk is notified that an Incident has been reassigned by a non-SDA. This allows the Service Desk to monitor Incidents to ensure that they are investigated in a timely manner. The Service Desk retains responsibility/ownership of
Page 10 of 25

Service Desk

Service Desk

Service Desk

Service Desk

Service Desk

Service Desk

Support team Support team

16 Correct team known? 17 Reassign to relevant support team

Support team

Support team

Incident Management Process

Version: 7.0

18 Reassign to SD

19 Assign to team member 20 Initial Support investigation

21 Requester responds to info requests?

22 Potential Major Incident? LC054

23

24 Support investigate

the Incident throughout the duration of the Incident (including prompting for updates). The process continues at Step 14. The Incident is reassigned to the Service Desk with an update, noting incorrect assignation (and any other relevant information). Should an Incident have passed through this step a number of times, the Service Desk may discuss with the Service Desk Manager (for any necessary arbitration, and to ensure the Incident is resolved in a timely manner). The process continues at Step 6. The Incident is assigned to an appropriate member of the support team (considerations given to skill set, and current work commitments). The process continues at Step 20. Support performs initial investigation. All updates/findings are noted in the Incident. If required, further information should be gathered from the requester. Investigation may include raising issues with External providers (e.g. ISE), via the Service Desk where necessary. The process continues at Step 21. If the requester replies with required information within the appropriate timeline (3 attempts are made to contact requester) the process continues at Step 22. If the requester does not reply within the appropriate timeline, process continues at Step 30, noting that contact could not be made with requester. If it has been identified that the issue is potentially of a critical nature (as defined in Priorities, p22), Support should notify the Service Desk, who in turn notify the Service Desk Manager, and the Major Incident process is invoked. The process continues at Step 4. If the issue does not seem to be of a critical nature, the process continues at Step 23. If it has been identified that the issue is security related (as defined in Security Incident documentation), the Service Desk notifies the Security Manager, and the Incident is either handled in SMaRT the same way a normal incident would, or due to confidentiality issues, cross referenced from SMaRT to a separate database accessible only to the security manager. The process continues at Step 37. If the incident does not seem to be a security issue, the process continues at Step 24 Support performs further investigation. All updates/findings are noted in the Incident. If required, further information should be gathered from the requester. Investigation may include raising issues with External providers, via the Service Desk where necessary. The process continues at Step 25.

Support team

Support team

Support team

Support team

Support team

Support team

Support team

Page 11 of 25

Incident Management Process

Version: 7.0

25 Additional support required?

An incident may require input from another MIS support team in order for it to be resolved. If this is the case, the process continues at Step 16. If the Incident does not require input from another MIS support team, the process continues at Step 26.

Support team

26 Requester responds to info requests?

If the requester replies with required information within the appropriate timeline (3 attempts are made to contact requester the process continues at Step 27. If the requester does not reply within the appropriate timeline, process continues at Step 30 noting that contact could not be made with requester. If a solution is identified, the process continues at Step 28. If a solution is not identified, the process continues at Step 24. Note - Incidents are monitored regularly by the Service Desk to ensure that they are resolved within a timely manner. Should an Incident reach a defined escalation point, the Service Desk will escalate appropriately (see Escalations, p23). If a change is required, the process continues at Step 29 If a change is not required, the process continues at Step 30 The Incident is updated with the relevant information. The process moves into Change Management. Once the Incident has been through Change Management, the process continues at Step 30. The Incident is reviewed to ensure that all required information is included. The resolution details are entered into the Incident, and the Incident is set to Resolved. The process continues at Step 31. The requester/s must confirm that the service is restored (this includes all requesters, where one or more have reported the Incident). If the service is confirmed as restored or the automated timeout function is invoked, the process continues at Step 35. If the service is confirmed as still being affected, the process continues at Step 32. If the requester/s are experiencing the same symptoms/Incident, then the process continues at Step 33. If the requesters are experiencing different symptoms (a different Incident), then the process continues at Step 34. The Incident is set back to status In Progress and is updated with details of why the service is not believed to be restored. The process continues at Step 6. It is possible that one Incident may mask others.
Page 12 of 25

Support team

27 Solution identified? LC054

Support team

28 Change required?

Support team

29 Update Incident

Support team

30 Resolve Incident

Support team

31 Requester/s confirm service restored?

Requester/Servi ce Desk

32 Same symptoms/Incident?

Service Desk

33 Set status to In Progress 34

Service Desk

Service Desk

Incident Management Process

Version: 7.0

Unlink all relevant Calls

35 Incident Closed 36 Incident Reviews LC055

37 Does Incident have to be handled outside normal process?

Where an Incident is resolved, but the requester is still experiencing an issue (now showing to be different to that of the resolved Incident), the Service Desk must unlink the call from the resolved Incident. This detached call is now investigated in its own right, and the process continues at the beginning, with a new Incident being raised. The process continues at Step 35 The Incident is set to status Closed The process continues at Step 36 The Service Desk Manager selects Closed Incidents and reviews these to ensure that the SCEE Incident Management process has been followed, that all Incidents have been managed in a timely manner and have been escalated as required, following escalation procedures. Process end. As the requester has confirmed they are satisfied with the resolution of this Incident, any further issues will require a new Incident to be raised. The security manager determines whether a security incident has to be handled outside of the normal process for security related reasons. If it does, the incident investigation and resolution is handled by security management, and when this is complete, the process continues at Step 12. If it does not, the process continues at Step 6 (or Step 24 if security incident was identified by Support Team.)

Service Desk Service Desk Manager

Security Manager

5.2
Step

Major Incident Process

Description The owner of the service (in MIS) is contacted to discuss the potential major Incident. (For service owners please see Service Catalogue, listed in the reference document section).The impact is assessed again against the priority definitions (see Priorities, p22). The process continues at Step 2. If the Incident is confirmed as being of a Major nature, the process continues at Step 3. If the Incident is confirmed as not being of a Major nature, the process resumes in Incident Management, Step 6. A Major Incident Manager is contacted for the duration of the Major Incident The process continues at Step 4. Checks problem management database (managed outside of SMaRT by the problem manager). Add in incident record any pertinent information found, such as previous incident reference/resolution details, if necessary. The process continues at Step 5. Contact Service Desk to confirm Priority 1, and advise of plans. Contact with the Service Desk will continue
Page 13 of 25

1 Contact MIS service owner

Responsibility Service Desk Manager

2 Confirmed Major Incident?

Service Desk Manager

3 Contact Major Incident Manager LC054 4 Check Problem Database

Service Desk Manager Major Incident Manager

5 Communications &

Major Incident Manager

Incident Management Process

Version: 7.0

Major Incident management

6 Review and (re)assign if necessary

7 Team picks up Incident 8 Correctly assigned? 9 Reassign to SD

10 Assign to team member 11 Workaround available?

throughout the duration of the major Incident. Communication plan is compiled/initiated, and the Major Incident is managed through its duration. Considerations are given to escalations (when and who including functional, and hierarchical), and business communications (frequency, method including SID/Service Desk headlines, Events Calendar, email, phone, meetings etc), If deemed necessary, a Technical Major Incident Manager is identified, to micro-manage all technical efforts, and to act as a single point of contact in the relevant technical area. The process continues at Step 6. The Incident is reviewed to ensure all information is correctly logged, and the Incident is reassigned to the appropriate team if not already. The appropriate support team should also be contacted directly by phone, to advise a Priority 1 Incident has been assigned to them. Note that the Service Desk retains responsibility/ownership of the major Incident, along with the Major Incident Manager, throughout the duration of the Incident (including seeking updates). Relevant SDA is determined by SRM responsibilities. The process continues at Step 7. The assigned team picks up the Incident and reviews the Incident. The process continues at Step 8. If the Incident has been correctly assigned to this team, the process continues at Step 10. If the Incident has not been correctly assigned to this team, the process continues at Step 9. The Major Incident is reassigned to the Service Desk with an update, noting incorrect assignation (and any helpful information) Having the Service Desk responsible for assigning Major Incidents to support teams ensures a single point of contact/responsibility, and reduces confusion. The Support team may also contact the Service Desk by phone to advise that a Priority 1 Incident has been incorrectly assigned and noted as such in the Incident record. Should an Incident have gone through this step a number of times, the Service Desk may discuss with the Major Incident Manager (for any necessary arbitration, and to ensure the Major Incident is resolved in a timely manner). Note any reassigning of Major Incidents will more than likely be done as advised by the MIM. The process continues at Step 6. The Incident is assigned to an appropriate member of the support team (considerations given to skill set, and current work commitments). The process continues at Step 11 If a recognised workaround for the Incident is available, the process continues at Step 13.
Page 14 of 25

Service Desk

Support team

Support team

Support team

Support team

Support team

Incident Management Process

Version: 7.0

12 Support investigate

13 Solution identified? LC054

14 Change required?

15 Update Incident

16 Resolve Incident

17 Requester/s confirm service restored?

18 Same symptoms/Incident?

19 Set status back to In Progress 20 Unlink all relevant Calls

If a recognised workaround for the Incident is not available, the process continues at Step 12. Support investigates, to identify a resolution. All updates/findings are noted in the Incident. If required, further information should be gathered from the requester/s. Investigation may include raising issues with External providers, via the Service Desk where necessary. The process continues at Step 13. If a solution is identified, the process continues at Step 14. If a solution is not identified, the process continues at Step 12. Note Major Incidents are monitored regularly by the Service Desk/Major Incident Manager to ensure that they are resolved within a timely manner. Should an Incident reach a defined escalation point, the Service Desk/Incident Manager will escalate appropriately (see Escalations, p23). If a change is required, the process continues at Step 15. If a change is not required, the process continues at Step 16. The Incident is updated with the relevant information. The process moves into Change Management. Once the Incident has been through Change Management, the process continues at Step 16. The Major Incident is reviewed to ensure that all required information is included. After consultation with the Major Incident Manager, the resolution details are entered into the Incident, and the Incident is set to Resolved. The process continues at Step 17. The requester/s must confirm that the service is restored (this includes all requesters, where one or more have reported the Incident). The Major Incident manager instructs SDA to telephone requester if appropriate, to expedite resolution confirmation. If the service is confirmed as restored, the process continues at Step 21. If the service is confirmed as still being affected, the process continues at Step 18. If the requester/s are experiencing the same symptoms/Incident, then the process continues at Step 19. If the requesters are experiencing different symptoms (a different Incident), then the process continues at Step 20. The Major Incident is set back to status In Progress and is updated with details of why the service is not believed to be restored. The process continues at Step 6. It is possible that one Incident may mask others. Where an Incident is resolved, but the requester is still experiencing an issue (now showing to be different to
Page 15 of 25

Support team

Support team

Support team

Support team

Support team

Service Desk

Service Desk

Service Desk

Service Desk

Incident Management Process

Version: 7.0

21 Incident Closed 22 Review Major Incident LC055

that of the resolved Incident), the Service Desk must unlink the call from the resolved Incident. This detached call is now investigated in its own right, and the process continues at the beginning, with a new Incident being raised. The process continues at Step 21. The Major Incident is set to status Closed. The process continues at Step 22. The Major Incident is reviewed by Problem Management. Considerations are to be given to what happened, how could we do better next time, did we do the right thing at the right time, can we improve the Major Incident process? Further activities may take place within Problem Management. Major Incident Process end. As the requester/s have confirmed they are satisfied with the resolution of this Incident, any further issues will require a new Incident to be raised.

Service Desk Major Incident Manager

5.3
Step

Service Request Process

Description A call is created by the Requester. A Service Request is created, by: Service Desk created on behalf of requesters (phone/email), or due to a non-planned event/alert being raised/identified. MIS Analyst The process continues at Step 3. Service Request is categorised (see Categories, p25). A target due date (deadline) is included at this stage. The process continues at Step 4 or 15. If the Service Desk can deal with the Service Request, the process continues at Step 5. If the Service Desk cannot deal with the Incident, the process continues at Step 9. The Service Request is assigned to the SDA and they investigated. All updates/findings are noted in the Service Request. If required, further information should be gathered from the requester. The process continues at Step 6. If the requester replies with required information within the appropriate timeline (3 attempts are made to contact requester), the process continues at Step 7. If the requester does not reply within the appropriate timeline, process continues at Step 8, noting that contact could not be made with requester. If the requirements are identified, the process continues at Step 8. If the requirements are not identified within an appropriate amount of time, the process continues at
Page 16 of 25

1 Call raised 2 Service Request raised

Responsibility Requester Service Desk / MIS Analyst

3 Categorise LC052 4 Can the SD deal with Service Request? 5 Assign to SDA & investigate

Service Desk / MIS Analyst Service Desk

Service Desk / MIS Analyst

6 Requester responds to info requests?

Service Desk

7 Requirements identified? LC054

Service Desk

Incident Management Process

Version: 7.0

8 Resolve Service Request

9 Assign to relevant support team

10 Team picks up Incident 11 Correctly assigned?

12 Correct team known? 13 Reassign to relevant support team

14 Reassign to SD

15 Assign to team member 16 Initial Support investigation

Step 4. Note Service Requests are monitored regularly by the Service Desk to ensure that they are resolved within a timely manner. Should a Service Request reach a defined escalation point, the Service Desk will escalate appropriately (see Escalations, p23). The Service Request is reviewed to ensure that all required information is included. The resolution details are entered, and the Service Request is set to Resolved. The process continues at Step 21. The Service request is assigned to the relevant support team. The Service Desk retains responsibility/ownership of the Service Request throughout the duration of the Service Request (including prompting for updates). The process continues at Step 10. The assigned team picks up and reviews the Service Request. The process continues at Step 11. If the Service Request has been correctly assigned to this team, the process continues at Step 15. If the Service Request has not been correctly assigned to this team, the process continues at Step 12. If the correct support team is known, the process continues at Step 13. If the correct support team is not known, the process continues at Step 14. The Service Request is reassigned to the relevant support team. If assigned by a Support team member, the Service Desk is notified that a Service Request has been reassigned by a non-SDA. This allows the Service Desk to monitor Service Requests to ensure that they are investigated in a timely manner. The Service Desk retains responsibility/ownership of the Service Request throughout the duration of the Service Request (including prompting for updates). The process continues at Step 10. The Service Request is reassigned to the Service Desk with an update, noting incorrect assignation (and any other relevant information). Should a Service Request have passed through this step a number of times, the Service Desk may discuss with the Service Desk Manager (for any necessary arbitration, and to ensure the Service Request is resolved in a timely manner). The process continues at Step 4. The Service Request is assigned to an appropriate member of the support team (considerations given to skill set, and current work commitments). The process continues at Step 16. Support performs initial investigation. All updates/findings are noted in the Service Request. If required, further information should be gathered from the requester.
Page 17 of 25

Service Desk

Service Desk

Support team

Support team

Support team

Support team

Support team

Support team

Support team

Incident Management Process

Version: 7.0

17 Requester responds to info requests?

18 Support investigate

19 Requirements identified? LC054

20 Resolve Service Request

21 Requester confirms resolution?

22 Same symptoms/request?

23 Set status to In Progress 24 Raise New Call

25 Service Request Closed

The process continues at Step 17. If the requester replies with required information within the appropriate timeline (3 attempts are made to contact requester) the process continues at Step 18. If the requester does not reply within the appropriate timeline, process continues at Step 20, noting that contact could not be made with requester. Support performs initial investigation. All updates/findings are noted in the Service Request. If required, further information should be gathered from the requester. The process continues at Step 19. If the requirements have been identified, the process continues at Step 20. If the requirements have not been identified, the process continues at Step 18. Note - Service Requests are monitored regularly by the Service Desk to ensure that they are resolved within a timely manner. Should a Service Request reach a defined escalation point, the Service Desk will escalate appropriately (see Escalations, p23). The Service Request is reviewed to ensure that all required information is included. The resolution details are entered, and the Service Request is set to Resolved. The process continues at Step 21. The requester must confirm the resolution is satisfactory. If the resolution is confirmed as ok, the process continues at Step 25. If the resolution is not ok, the process continues at Step 22. If the requester is experiencing the same symptoms/requirements, then the process continues at Step 23. If the requester is experiencing different symptoms (different request), then the process continues at Step 24. The Service Request is set back to status In Progress and is updated with details of why the request is not believed to be resolved. The process continues at Step 4. It is possible that resolving one request may lead to additional requests). Where a Service Request is resolved, but the requester now has greater /additional requirements (now showing to be different, or in addition to that of the resolved Service Request), a new Call must be raised for the Requester to capture the additional requirements. The new call is investigated in its own right, and the process continues at the beginning, with a new Service Request being raised. The process continues at Step 25. The Service Request is set to status Closed. The process continues at Step 26.
Page 18 of 25

Support team

Support team

Support team

Support team

Service Desk

Service Desk

Service Desk

Service Desk

Service Desk

Incident Management Process

Version: 7.0

Page 19 of 25

Incident Management Process

Version: 7.0

6.
6.1
6.1.1

APPENDICES
Key Roles and Responsibilities
SCEE MIS Service Desk Provides first point of contact for all SCEE MIS-related issues. Ensures all Incidents/Service Requests are raised in the Service Management too. Seeks further information from the requester, if Incident requirements are unclear Seeks appropriate approval from SCEE Management, if relevant Assigns categorisation & prioritisation to Incident/Service Request, using information provided by the requester Monitors open Incidents/Service Requests to ensure they meet the due date (in Support Relationship Management (SRM) responsibilities). Resolves Incidents/Service Requests at first point of contact, where possible. If unable to resolve, assigns to MIS support teams. Escalation of high priority Incidents to relevant SCEE MIS Management Distributes communications to SCEE business, if required Distributes information within the Service Desk, where appropriate. Hands over daily responsibilities to remaining SDAs upon completion of shift (including any Incidents/Service Requests which must be resolved that day).

6.1.2

Service Desk Manager (Incident Manager) Reviews closed Incidents to ensure the Incident Management process is being followed, and to provide audit reports. Drives the efficiency and effectiveness of the Incident Management process. Produces management information. Manages the work of the Service Desk Analysts. Monitors the effectiveness of Incident Management and makes recommendations for improvement. Develops/maintains the Incident Management systems.

6.1.3

Requester Raises all Incidents/Service Requests directly with the SCEE MIS Service Desk. Provides all information necessary to allow MIS to resolve the Incident/Service Request. Verifies Incident/Service Request resolutions.

6.1.4

MIS Support Teams Investigates all Incidents/Service Requests according to their priority/due date. Changes priority/due date if investigations show that it is misrepresented. Ensures Incidents/Service Requests are updated with all investigations/findings in a timely manner.
Page 20 of 25

Incident Management Process

Version: 7.0

Ensures Incidents/Service Requests are resolved within the appropriate timescale, where possible. Distributes information to the Service Desk, where appropriate. 6.1.5 Major Incident Manager The Major Incident Manager is responsible for coordinating and managing all macro efforts to resolve the Major Incident in a timely manner, including identifying and coordinating the appropriate resources, communications and escalations, and reviewing the Major Incident, with Problem Management, once services are restored. This role is an extension to that of Incident Management, which leaves the Service Desk / Incident Manager free to perform first line activities, and any other Major Incident activities as instructed. 6.1.5.1 Core Support Hours This role will only formally in place during core support hours. Outside of support hours (24/7 services, or short-term increases in support hours due to specific business requirements/requests) will be managed/coordinated independently. 6.1.5.2 Primary Responsibility The responsibility of Major Incident Manager will primarily default to the Problem Manager. 6.1.5.3 Pool 1 Where the Problem Manager is "Out of the Office", the 1st Pool is consulted, and the most appropriate (or available) member of the MIS Management team takes the role (with the focus to fulfil all requirements of this role). 6.1.5.4 Pool 2 In the unlikely event that the all members of the MIS Management team are unavailable, the 2nd Pool is consulted, and the most appropriate (or available) member of the Process Management team takes the role. This should be a last resort, due to the fact that these Process Managers will be heavily involved in their 'Major', or 'Urgent' processes during the lifetime of the Major Incident. Therefore, it is recommended that the first selection from this pool be the Incident Manager. 6.1.6 Technical Major Incident Manager An additional role of Technical Major Incident Manager may also be assigned, if appropriate, to micro manage the efforts within the specific technical area. They are responsible for resolution, co-ordination, and decision making on all technical aspects of the fix, and act as a single point of contact for the Major Incident Manager. The decision to assign this additional role is taken on a case-by-case basis, and is done in agreement with the relevant MIS service owner/manager/team leader. If a
Page 21 of 25

Incident Management Process

Version: 7.0

Technical Major Incident Manager has been assigned, all communication with users should be agreed by both the Major Incident Manager and the Technical Major Incident Manager to ensure that it is accurate, appropriate and up-to-date.

6.2
6.2.1

Priorities
Incidents Due date 4 working hours

Priority Description 1 Fatal business impact Major Incident. An incident which has interrupted, significantly degraded, or caused a security compromise in a service defined as business critical, during core service hours. 2 High business impact System degraded Process failure High cost implications to the business 3 Medium business impact Process failure or fault with minor impact Services are still maintainable High impact & low urgency, or low impact & high urgency Examples: Many user impacted but not really urgent, or Only one user impacted but needs attention Low business impact Process failure or fault with minor impact Services are still maintainable Low impact & low urgency Examples: Not urgent Can wait until the end of the week. 6.2.2 Service Requests Service requests Password reset Mail release Request for information, advice, documentation (How do I?). Request for admin (report/statistics production, communications, etc). Standard day-to-day operational requests (which are not under Change/Release management). Note: These are neither Incidents nor changes.
Page 22 of 25

1 working day

2 working days

5 working days

No priority

Note: The target due date is agreed on a case-by-case basis, unless otherwise stated on service level agreement

Incident Management Process

Version: 7.0

6.3

Escalations
Escalations will occur to the appropriate level of management depending on the proportion of the target resolution time that has passed.

Level 1 Assignee Level 2 Support Team Leader, Service Delivery Manager and Service Desk Manager Level 3 MIS Service Owner, Service Delivery Manager and Service Desk Manager Level 4 Director of Transactional and Information Systems Formal escalation by the Service Desk occurs at 50%, 75% (approx) and 100% Priority 1 Target Deadline 4 working hours When Escalates Immediately 50% 2 hours 75% (approx) 3 hours 100% 4 hours 50% 4 hours 75% (approx) 6 hours 100% 8 hours 50% 8 hours 75% (approx) 12 hours 100% 16 hours 50% 2.5 days 75% (approx) 3 days 100% 5 days 100% of Due date Escalates To Major Incident Manager Up to level 2 Up to level 3 Up to level 4 Up to Level 1 Up to Level 2 Up to Level 3 Up to Level 1 Up to Level 2 Up to Level 3 Up to Level 1 Up to Level 2 Up to Level 3 Up to Level 1

1 working day

2 working days

5 working days

Service As agreed with Request requester

6.3.1

Notifications Relevant Managers will be notified (FYI) whenever a high priority Incident is raised. Priority 1 2 Notification All MIS Mgrs All MIS Mgrs
Page 23 of 25

Incident Management Process

Version: 7.0

6.4

Life Cycle
Status New Assigned In Progress Awaiting Info Info Received Resolved Closed IM Process Step New Record Assigned to Team/Individual Investigation commenced Request Info from user Info received from user Issue Resolved Issue Closed

6.5

Resolution Codes
Resolution codes are mandatory and will be set by the assignee during resolution. These codes will be used to specify what the cause was, and to allow trending to be performed by Problem Management.

6.5.1

Incident Resolution code User Error Unable to contact Duplicate Hardware Software Network Service/App Environmental Voice Other

Description Incident caused by user error. Incident unable to be resolved due to being unable to make contact with user / user not returning calls. Incident exact duplicate of another Standard h/w fault e.g. server, HDD, modem, router Standard s/w fault e.g. MS Office, Notes etc Network fault - e.g. connectivity (AT&T network problems) SCEE specific service/app fault - e.g. SAP, PIN Point, SID etc Caused by environmental fault e.g. aircon, power failure Voice fault e.g. telephony (pabx, or phone fault) Other fault - should be used with care. IM process owner should report regularly on this category to identify gaps in Resolution code selection, and aim to keep the use of this particular selection to a minimum. Incident record raised in error (e.g. Service Request, or Change required, rather than Incident).

Raised in Error

6.5.2

Service Request Resolution code Advice/Guidance Unable to contact Duplicate Admin Other

Description Service Request resolved through advice/guidance Service Request unable to be resolved due to being unable to make contact with user / user not returning calls. Service Request exact duplicate of another Service Request resolved through administration (e.g. report/statistic production, co-ordination of work, communications - email, post, & basic user management etc). Other issue - should be used with care. IM process owner
Page 24 of 25

Incident Management Process

Version: 7.0

Raised in Error

should report regularly on this category, and aim to keep the use of this particular selection to a minimum. Service Request record raised in error (e.g. Incident, or Change required, rather than Service Request).

6.6

Categories
Categorisation is used to aid both initial diagnosis/investigation (where to assign the Incident, or Service Request), and to provide reporting statistics/trending. Categorisation will be separated into two to three levels, will be held as selectable options within the Service Management tool and will be reviewed regularly to ensure that they remain relevant. Please see the SMaRT v2.1 Category list, listed in the reference documents section.

6.7

Glossary
MIS KPI SD SDA SR CRR Managed Information Systems (SCEEs IT Department) Key Performance Indicator Service Desk Service Desk Analyst Service Request Change Request Record

Page 25 of 25