1 / 17

Problem Management Overview

Problems use the same prioritisation as incidents. In order to prioritise, the impact and severity

Marval
Download Presentation

Problem Management Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Problem Management ITIL

  2. Contents Purpose of Problem Management Roles Process Policy 2

  3. Contents Purpose of Problem Management 3

  4. Terms (Service Operations) 2 1 3 Incident Problem Service Request Something is broken or about to break. Repair as quickly as possible. Open incidents are measured against SLAs. Underlying “root-cause.” Remains open until underlying issue is resolved. Open Problems are not measured against SLAs. Creates “work-around.” Routine pleas for help – but nothing is broken. These include items like “can you tell me Joe Blow’s phone number”, “can you unlock my account”, and “will you reset my password.”

  5. Problem Guidelines There is no time SLA target associated with problem resolution. Resolution of the root cause of a problem may take hours or days or even years Problems do not need prior approvals to be worked and resolved. They only need to be prioritised to work the most critical problems first If it appears that root cause identification and resolution are not readily apparent and the impact is medium or high, effort should be focused first on providing a suitable documented work around 5

  6. Problem Prioritisation Problems use the same prioritisation as incidents. To prioritise, the impact and severity must be assessed. Severity 2-Medium User cannot perform critical time sensitive functions Problem Priority Impact: People & Service Severity: Time 3-Low processing within SLA constraints 3-Low 1-High User cannot perform a portion of their duties. Major portion of a critical service is unavailable   One or two personnel Degraded Service Levels but still 3-Low 3-Low 2-Medium  Multiple personnel in one physical location Degraded Service Levels at or below SLA constraints Cause of problem falls across multiple functional areas 2-Medium Impact  2-Medium2-Medium 1-High    All users of a specific service Personnel from multiple agencies are affected Public facing service is unavailable Any item listed in the Crisis Response tables 1-High 1-High 1-High 1-High   6

  7. Contents Roles 7

  8. Roles  Problem Reporter  Anyone can request a problem case to be opened  The typical sources for problems are the Service Desk, Service Provider Groups, and proactive problem management through Quality Assurance 8

  9. Roles  Service Desk  Ensure that all problems received/ identified by the Service Desk are recorded in your ITSM software  Delegates responsibility by assigning problems to the appropriate provider group for resolution based upon the categorisation rules  Performs post-resolution customer review to ensure that all work services are functioning properly  Quality Assurance  Owns all reported problems  Prepare reports showing statistics of problems resolved / unresolved 9

  10. Roles  Service Provider 2nd Line Groups  Composed of technical and functional staff involved in supporting services  Perform root cause analysis of the problem and develop potential solutions  Test potential solutions and develop implementation plan  Service Provider 3nd Line Groups  Composed of external technical staff involved in supporting services  Perform root cause analysis of the problem and develop potential solutions  Test potential solutions and assist in development of implementation plan 10

  11. Contents Process 11

  12. Process Flow 12

  13. Process Flow - Identification Anyone within 1st, 2nd 3rd line can request that a problem record be opened All initial information relative to a problem will be logged, especially related incidents Before continuing, the Service Desk will verify the related service having the issue and correlate it with an existing service and SLA After problem verification, the Service Desk will attempt to establish urgency and impact which define priority.     13

  14. Process Flow – Analyze & Resolve Primary root cause analysis will be performed by the Service Provider Group As soon as the problem is clearly documented with identifying symptoms, linked to the incident, a known error record can be created within the ITSM software so that if additional incidents occur, they can be related to the existing problem Once the solution is determined, it should be implemented following the Change Management Process Once the solution is implemented and verified, the problem record may be closed     14

  15. Contents Policy 15

  16. Problem Policy Problems must be logged with the Service Desk before they are worked on There is no SLA target date connected to problem resolution (e.g. a start and complete by date) If a work around for the problem has been discovered, it should be provided to the Service Desk and logged into the ITSM software and a known error recorded 16

  17. 17

More Related