IM and T Problem Management Policy. Contents

Transcription

1 IM and T Problem Management Policy Classification: Policy Lead Author: Jym Bates, Head of Information Assurance Additional author(s): Richard Wakefield, Authors Division: IM&T (Corporate) Unique ID: Info3(12) Issue number: 3 Expiry Date: July 2017 Contents Section Page Who should read this document 2 Key Messages 2 Background/ Scope 2 What is new in this version 2 Policy/Procedure/Guideline 2 Review of Process 2 Identification of a Problem 3 Declaration of a Problem 3 Minimum Data Set 3 Prioritisation 4 Investigative Actions 4 Create or Validate Workarounds 4 Change Status of Problem to Known Error (KE) 4 Protocol 5 Standards 6 Explanation of terms/ Definitions 6 Roles and Responsibilities 6 Document control information (Published as separate document) Document Control Policy Implementation Plan Monitoring and Review Endorsement Equality analysis Page 1 of 7

2 Who should read this document? Staff performing Problem Management activities or roles and the technical support teams Key Messages The purpose of Problem Management is to prevent problems and the resultant incidents they cause from happening, and thus improving the quality of service experienced by our users. This is to be primarily achieved by working with Incident Management to identify problems and their cause in order to implement and by working with Change and Release management to formulate a permanent solution. Where it is not possible in a timely or cost effective manner, to identify the cause of a problem or implement a permanent solution, a work-a-round may be considered provided it is acceptable to the customer. Background & Scope A Problem is the unknown cause of one or more Incidents. The cause is not usually known at the time a Problem record is created, and the Problem Management process is responsible for further investigation What is new in this version? No key changes (format changes only in this revision) Policy/ Guideline/ Protocol Review of Process 1. The Problem Management process should be reviewed on a yearly basis to ensure it is, current, applicable and being adhered to as part of an overall continuous improvement programm 2. e for our ITIL related processes and to identify how it can be improved 3. There will be one Problem Management Process for all of IM&T 4. The problem management process needs to be efficient and cost effective and deliver problem solutions or work-a-rounds in a timely manner, in order for IT to deliver a good service to the Business. 5. There will be one Problem Management tool used for the logging and tracking of Problems and Known Errors, this will be the HPOV system. Identification of a Problem Problems will be identified through the following means: 6. A Service Desk Analyst may become aware of a problem through the type, volume and repetition of calls received. Page 2 of 7

3 7. The Service Desk Manager, through problem management meetings will undertake proactive problem management as part of CSI. 8. Problem management team review all Sev 1 and 2 calls to identify any resident problems. 9. Departmental managers will review information through the problem management meetings to undertake proactive problem management. Reports used include: 9.1. By service code By volume of calls By user survey feedback. 10. IT Departmental Managers will review their incidents logged to their own team and review associated trends to understand if a problem is occurring, this will occur at least on a monthly basis and be brought to problem management meetings, if not identified then null return is required. Declaration of a Problem 11. If a Problem has been created as a result of a Major Incident ensure the Incident Records that have been created by the Service Desk are linked to the Problem Record 12. If a Problem has been created as a result of proactive Problem Management trending, link the Incident Records that have been created by the Service Desk to the Problem Record 13. If a Problem Record has been created by a Technical Expert, review and associate the ticket with existing Problem Records 14. An IAO or Business Service Owner may inform the problem manager of an issued associated with their system or service. Minimum Data Set Unique identifier, Date and time stamps Name and contact information of the Problem initiator Incident count/linking incidents Linked Request for Change RFCs Problem details/description Problem category Priority Service and SLAs affected Links to further information History/ Details of all diagnostic or attempted recovery actions taken Status Workarounds Prioritisation 15. Priority and pain value based upon Duration of problem to date Page 3 of 7

4 Impact (cost) to date Whether the service can be recovered, or whether it needs to be replaced How much it will cost to fix How long it will take to fix How extensive the problem is Investigative Actions 16. Problem analysis to identify the root cause, workarounds, and potential solutions to the problem should include: Identify the team as necessary Using tools as available, document findings and store evidence As necessary, utilize problem analysis techniques, such as Ishikawa diagrams or Kepner-Tregoe 17. Problem analysis will be co-ordinated by the Problem Manager 18. Other actions in this section include: Identify workarounds Determine Root Cause(s) and record in data record Assess the problem and recommend action to resolve problem Record details in data record Update Knowledge Base Create or Validate Workarounds 19. Problem Management will review and validate workarounds that have been submitted by Incident Management and other processes or functional groups. If no workaround exists, Problem Management will create one where feasible or practical. Change Status of Problem to Known Error (KE) 20. After successful identification of the root cause and identification of a workaround the Problem status will be changed to that of a Known Error (KE) Protocol 21. A Problem will be declared and logged into the Problem Management database by the Problem Manager with appropriate authority when it meets any of the following criteria: Multiple incidents showing the same symptoms where the cause is unknown Where a significant incident requiring further investigation has been identified by other processes or management Potential problems identified by industry trends and other processes (e.g. Analysis of existing service infrastructure, Root Page 4 of 7

5 cause analysis or solution investigation processes of Problem Management). All severity one and severity 2 incidents 22. Every Problem will be categorised using the best available category within HPOV. 23. All Problems will be prioritised based on impact and urgency as they are defined in the Priority Model for Incident, Problem and Change Management. 24. The Problem Management process will comply with the Change Management process by submitting a Request for Change (RFC) to facilitate the removal of identified error(s) from Configuration Items (CIs). 25. IM&T managers or team leads will commit appropriate resources to conduct root cause analysis or other problem management activities, such as pro-active trend analysis and validation or creation of workarounds or solutions as requested by Problem Management. 26. IM&T will investigate problems using a standardized root cause methodology as part of the Problem Management Process. Root Cause Analysis (RCA) will only occur after a problem has been declared. 27. After successful identification of the root cause and identification of a workaround the Problem status will be changed to that of a Known Error (KE) and any resolution actions added to the appropriate documentation. 28. Problem Management will be responsible for populating, reviewing and assessing potential and existing Problem Management knowledge within the IT Service Management tools. Specifically this will include Problem Records, Known Errors, validated workarounds, checklists, and solution records. 29. Problem Management will participate in Post Implementation Reviews (PIR) for changes that were initiated by Problem Management, and also whenever requested by Change Management. 30. Known Errors (KE) and associated Problems will only be closed after a successful PIR resulting from either A successful implementation of the corresponding Request(s) for Change (RFC) and the verification that no further incidents are occurring as a result of the Known Error or its correction A successful implementation of a work around where it is deemed that the work around is sufficient and no permanent solution should be pursued. Page 5 of 7

6 Quorum: 1st Line, including Service Desk 2nd Line Desktop Services Server Network App Support Invite people as required, depending on problem Frequency: Every 2 weeks unless pressing problem requires immediate attention How are problems raised: Service Desk Manager / Supervisors to provide trends of issues Anybody can raise an issue via NC who will sense check and add to HPOV problem management section Standards The Data Protection Act 1998, The Freedom of Information Act 2000, The Regulation of Investigatory Powers Act Privacy and Electronic Communications Regulations ITIL ITIL is the widely accepted approach to IT service management in the world. ITIL can help individuals and organizations use IT to realize business change, transformation and growth. Explanation of terms & Definitions KE Known Error RFC Request for Change RCA Root Cause Analysis PIR Problem Implementation Review CI Configuration Item Roles and responsibilities The following roles are defined within Problem Management:- Problem Management Owner:- Responsible for reviewing the Policy and Process on a 6 monthly basis. Problem Manager:- Responsible for the day to day operation of Problem Management. Problem Analyst:- Page 6 of 7

7 Responsible for driving individual problems through the problem management process. It is the responsibility of each individual within the IT department to ensure they adhere to the Problem Management policy. Page 7 of 7