Version 1 August 2015 · 2017-09-01 · Version 1 August 2015 Problem Management 08/31/2015....

Version 1

August 2015

Problem Management

08/31/2015

Problem Management of 51

©2014 Navvia, a division of Consulting-Portal, Inc. 8/31/2015

Table of Contents

Introduction ...............................................................................................................................................................................................4Overview ....................................................................................................................................................................................................5

Description ............................................................................................................................................................................................5Scope.....................................................................................................................................................................................................5Goal .......................................................................................................................................................................................................5Objectives..............................................................................................................................................................................................5Roles......................................................................................................................................................................................................6

Process Control ..........................................................................................................................................................................................7Controls .................................................................................................................................................................................................7Metrics ..................................................................................................................................................................................................8Policies ................................................................................................................................................................................................12

Workflow .................................................................................................................................................................................................13Inputs ..................................................................................................................................................................................................13Outputs ...............................................................................................................................................................................................14Activities..............................................................................................................................................................................................15

PRB 1.0: Identifying and Logging ....................................................................................................................................................16Cross-Functional Flow Diagram ......................................................................................................................................................17

PRB 1.1: Process Start................................................................................................................................................................18PRB 1.2: Create New Problem Record .......................................................................................................................................18PRB 1.3: Queue to Support Group.............................................................................................................................................19PRB 1.4: Review and Accept ......................................................................................................................................................19PRB 1.5: Queued Correctly?.......................................................................................................................................................20PRB 1.6: Review and Assign .......................................................................................................................................................20PRB 1.7: Accept Assignment ......................................................................................................................................................21PRB 1.8: Assigned Correctly? .....................................................................................................................................................21

PRB 2.0: Investigating and Updating ..............................................................................................................................................23Cross-Functional Flow Diagram ......................................................................................................................................................25

PRB 2.1: Valid Problem? ............................................................................................................................................................26PRB 2.2: Cancel Problem............................................................................................................................................................26PRB 2.3: Optimize Workaround.................................................................................................................................................27PRB 2.4: Problem Review...........................................................................................................................................................27PRB 2.5: Pursue Root Cause?.....................................................................................................................................................28PRB 2.6: Assign to Support ........................................................................................................................................................29PRB 2.7: Accept Assignment? ....................................................................................................................................................29PRB 2.8: Perform Root Cause Analysis.......................................................................................................................................30PRB 2.9: Root Cause Identified? ................................................................................................................................................30PRB 2.10: Known Error...............................................................................................................................................................31PRB 2.11: Budget Exhausted?....................................................................................................................................................32

PRB 3.0: Propose Fix .......................................................................................................................................................................33Cross-Functional Flow Diagram ......................................................................................................................................................34

PRB 3.1: Known Error Review ....................................................................................................................................................35PRB 3.2: Develop Fix? ................................................................................................................................................................35PRB 3.3: Assign to Support ........................................................................................................................................................36PRB 3.4: Accept Assignment? ....................................................................................................................................................36PRB 3.5: Identify & Propose Fix .................................................................................................................................................37PRB 3.6: Fix Identified? ..............................................................................................................................................................37PRB 3.7: Budget Exhausted?......................................................................................................................................................38

PRB 4.0: Resolving and Closing.......................................................................................................................................................39Cross-Functional Flow Diagram ......................................................................................................................................................41

PRB 4.1: Review Priority and Budget .........................................................................................................................................42PRB 4.2: Implement Fix? ............................................................................................................................................................42



PRB 4.3: Assign to Support ........................................................................................................................................................43PRB 4.4: Accept Assignment? ....................................................................................................................................................43PRB 4.5: Develop Fix ..................................................................................................................................................................44PRB 4.6: Implement the Fix .......................................................................................................................................................44PRB 4.7: CR Successful? .............................................................................................................................................................45PRB 4.8: Problem Fixed?............................................................................................................................................................46PRB 4.9: Close Problem..............................................................................................................................................................46PRB 4.10: Process End ...............................................................................................................................................................47

States .......................................................................................................................................................................................................48Process States .....................................................................................................................................................................................48

Process State Diagram....................................................................................................................................................................49Appendix ..................................................................................................................................................................................................50

Attachments and Links ........................................................................................................................................................................50Definitions ...........................................................................................................................................................................................51



IntroductionThe following Problem Management Process has been designed for the Stanford University IT Service Management program. Departments that participate in the University IT Service Management program will adhere to this Problem Process. Procedures developed around this Problem Management process will need to be validated by the Problem Process Owner and Process Manager(s) so as to standardize across the institution. This Process will have relationships with other Processes and those documents should be read and understood along with this, the primary related processes being Incident and Change Management.



OverviewA Process is a set of linked activities that transform specified inputs into specified outputs, aimed at accomplishing an agreed-upon goal in a measurable manner. The Process definition laid out in this document further breaks down these activities into tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

DescriptionA "problem" may be defined as the unknown cause of one or more Incidents.The Problem Management process manages the lifecycle of all problems. The main objective is to prevent Incidents from re-occurring in the future or, if they cannot be prevented, to ensure that they can be resolved in the most expedient manner.

ScopeAll P1 and P2 Incidents and any unresolved Incidents with no known root cause.

GoalThe process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each ITSM process has a specific focus and when combined with the other ITSM processes, forms a comprehensive framework for delivering and managing services.

The goal of Problem Management is to prevent Incidents from reoccurring by identifying the underlying cause of the incidents and providing a permanent fix to remove it or to minimize the impact of those recurring Incidents that cannot be prevented.

ObjectivesProcess objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

To identify and record all Problems discovered within University supported services or the infrastructure.To provide optimized Workarounds for Incidents that will allow users to continue to perform their jobs until a permanent fix is implemented.To identify the underlying cause of Incidents with sufficient impact to warrant the work effort.To prevent reoccurrence of Incidents through implementation of cost justified permanent fix.To maintain transparency by ensuring that timely and accurate information is provided to all stakeholders in a manner that meets their information requirements.



RolesEach process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

Name Description

Problem Process Owner

A Senior Leader with the ability and authority to ensure the process is rolled out and used by all departments within the Stanford University IT and other supported entities. Specific responsibilities include: Defining the overall mission of the process; establishing and communicating the process mission, goals and objectives to all stakeholders; resolving any cross-functional (departmental) issues; ensuring consistent execution of the process across departments; reporting on the effectiveness of the process to senior management; initiating any process improvement initiatives.

Problem Process Manager

Responsible for the day-to-day execution of the process. The Process Manager(s) take direction from the Process Owner in order to ensure consistent execution of the process across all areas of the organization. Specific responsibilities include: managing the day to day activities of the process; gathering and reporting on process metrics; tracking compliance to the process; escalating any issues with the process; acting as chairperson for process meetings

Problem Coordinator

This role is the "point person" within a support group that is accountable for all Problems assigned to their group. Responsible for monitoring their respective queues for assigned Problems, assessing them and assigning to the appropriate individuals with budgets for further investigation. Designates Problems and Known Errors as "Do Not Pursue" and removes that flag if warranted. Also plays a role in escalations to other groups. This role is also accountable for ensuring that the process is followed for the Problems assigned to their own support group

Problem Support

This role is responsible for various activities within the Process. Most notably, the role develops an optimized Workaround for the Problem, seeks a root cause and subsequently, seeks a suitable fix to eradicate the Problem. It should be noted that despite the same role designation, different individuals might be assigned during the life of the Problem (e.g., one person identifies the root cause, another the fix).

Submitter The person or system that creates the Problem record.

Incident Support

Responsible for Incident investigation and diagnosis for Incidents escalated from the Service Desk; development of Workarounds; identification and creation of Problems; the resolution and recovery of assigned Incidents; the creation of Incidents where they themselves detect a service failure or quality degradation or a situation that may result in one. Escalation of Incidents where necessary.

Incident Coordinator

This role is the "point person" within a support group that is accountable for all Incidents assigned to their group. Responsible for monitoring their respective queues for assigned Incidents, and re-assigning them to the appropriate individuals for further investigation. Also plays a role in escalations to other groups.

Service Desk Manager

Provides guidance to Service Desk staff on issues such as escalation and setting Priority. Also ensures that appropriate communications takes place ensuring that all affected stakeholders are kept abreast of Incident status. May have a key role to play in the Major Incident procedures. Often responsible for, or involved in producing management reports for the Incident Management process. Represents the Service Desk at Incident Management meetings.

Service Owner Individual who has responsibility and is Accountable for the services they own.



Process ControlProcess Controls represent the policies and guiding principles on how the process will operate along with the metrics for measuring the process and they provide direction over the operation of process by defining constraints or boundaries within which the process must operate.

Controls The controls listed are those identified by COBIT 5 as important for a Problem Management process.

Name DescriptionDSS03.01 Identify and Classify Problems

Define and implement criteria and procedures to report problems identified, including problem classification, categorization and prioritization

DSS03.02 Investigate and Diagnose Problems

Investigate and diagnose problems using relevant subject matter experts to assess and analyze root causes

DSS03.03 Raise Known Errors As soon as the root causes of problems are identified, create known-error records and an appropriate workaround, and identify potential fixes

DSS03.04 Resolve and Close Problems

Identify and initiate sustainable fixes addressing the root cause, raising change requests via the established change management process if required to resolve errorsEnsure that the personnel affected are aware of the actions taken and the plans developed to prevent future incidents from occurring

DSS03.05 Perform Proactive Problem Management

Collect and analyze operational data (especially incident and change records) to identify emerging trends that may indicate problems. Log problem records to enable assessment



MetricsMetrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

# of Problems currently Open

Description: Speaks to the backlog of problems. Presented by Status would be a better indication of the state distribution of open problems (i.e., why are they open?). Should also be presented by Priority.

Type: NumberMeasurement Procedure: Count all problem records where the status is not set to closedAdditional Details: Part of CSF: Maintain quality of IT services through elimination of recurring incidentsCategory: Efficiency

% of Problems resolved within target

Description: Appropriate if agreed upon targets have been established. Otherwise an informal target may be used on which to base this metric.

Type: Ratio

Measurement Procedure: Count of problems (and Known Errors) resolved within the target time / total number of problem and known error records created X 100

Category: Effectiveness

Average Problem Resolution Time

Description: An indication of the length of time that problems are taking to be root- cause identified and Known Errors resolved (i.e., root cause eliminated). This metric is best observed as a trend.

Type: Duration

Measurement Procedure: Calculate the average of the duration between the problem resolved time stamp and the problem created time stamp.


# of Pro-active Problem Records

Description: The percent of Problems that were declared as a result of a pro-active activity (as opposed to through Incident or Release Management). An increasing trend is desired.

Type: NumberMeasurement Procedure: Count of all problems not generated from pre-existing Incident recordsCategory: Compliance

# of Duplicate Problem records

Description: Speaks to poor Problem matching, procedures or training

Type: NumberMeasurement Procedure: Count of all problem records with a closure code = Duplicate




# Known Errors created

Description: Partial indicator of the degree of success of the process since a Known Error indicates that the root cause has been identified. May be of value to know the number/percent that were created from Release Management

Type: NumberMeasurement Procedure: Count of all Known Errors CreatedAdditional Details: Part of CSF: Minimize the impact to the business of incidents that cannot be preventedCategory: Effectiveness

Problem State Duration

Description: Problem State Duration. This metric captures how long the Problem was in a particular Problem State.

Type: DurationMeasurement Procedure: ServiceNow scriptCategory: Value

Problem - Create to Close Duration

Description: Problem - Create to Close Duration. This metric captures how long the Problem took to go from its Creation to Closed.

Type: DurationMeasurement Procedure: ServiceNow scriptCategory: Value

Total Number of Problems

Description: Presented (typically) by Period / by Priority and depicted over time will indicate a trend that can be observed and acted upon.

Type: Number

Measurement Procedure: Simply a count of all Problems created during the period. This count may be further grouped by Category, Assignment Group or any other relevant field.

Additional Details: A subset of this may be used for various ServiceNow reports.By itself, not terribly useful.

Category: Efficiency

Problems by Escalation

Description:Problems by Escalation - This metric captures a count of Problems broken out by Escalation.

Type: NumberMeasurement Procedure: The out of box report by the same name may be used for this metric.

Additional Details: There is a ServiceNow out-of-the-box report for this metric.Captures bounce count between groups.

Category: Value



Problems by State

Description: Problems by State (and Problems by State for My Group) - This metric captures a count of Problems broken out by State.

Type: NumberMeasurement Procedure: The out of box report by the same name may be used for this metric.

Additional Details: There is a ServiceNow out-of-the-box report for this metric.

Category: Value

Average Incident Resolution Time

Description: Capture resolution time for incidents that are linked to problem records.

Type: NumberOpportunity For Defect: Resolution time ought to be quicker for incidents linked to problem records.Additional Details: Part of CSF: Minimize the impact to the business of incidents that cannot be prevented.Category: Effectiveness

Problem Reviews

Description: Capture the number of Problems that have had reviews performed on them. Problems that have not had reviews performed run the risk of recurring.

Type: Percent

Additional Details: Part of CSF: Provide overall quality and professionalism of problem handling activities to maintain business confidence in IT capabilities


Problems Incorrectly Assigned

Description: Capture the number of times that a problem must be re-assigned. This can be an indicator of poor classification or investigation and diagnostic activities.

Type: CountOpportunity For Defect: The trend ought to be downward.

Additional Details:Part of CSF: Provide overall quality and professionalism of problem handling activities to maintain business confidence in IT capabilitiesBounce count between assignees.

Category: Efficiency

Last Updated

Description: Duration of time since last update per open problem record.Report on last activity within an open problem record.

Type: NumberAdditional Details: Report on last activity within an open problem record. Category: Efficiency



# of Incidents Associated with a Problem

Description: A count of the number of incidents associated with an open Problem record. The ability to focus on higher reoccurring instances to prioritize and focus on a permanent fix.

Type: NumberMeasurement Procedure: The ability to categorize top 10, 20, 30 by priorityCategory: Effectiveness



PoliciesPolicies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

Single Tool - Service-Now

Statement: There will be a single tool (Service-Now) to be used consistently by all Stanford University IT teams.

Rationale: To ensure consistency in process execution, as well as ease in exchanging information and generating reports on an enterprise wide basis

Value: Exceptions:

Problem Tracking

Statement: Problems must be tracked separate from Incidents.

Rationale: Provides clear separation between many problem management activities, which tend to be proactive. Incident Management activities tend to be reactive.

Problem Classification

Statement: Establish a standard, enterprise wide classification scheme for service management.

Rationale: Provide faster access to problems, better support for diagnostic and proactive trending activities.



WorkflowThe details pertaining to the information required to execute the process, the activities and tasks germane to the process, and the results of executing the process

InputsProcess inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

Name Description Supplier Is Trigger Task

A New Problem Declared

A new Problem has been declared. This occurs in the Incident Management process though Problems may be detected within the Problem Management process itself or from other processes (e.g., Capacity Management) or from the V3 CSI Phase.

Incident Management, Pro-Active Problem Management (CSI in ITIL), Capacity Management

Yes

A Known Error Declared

In addition to the normal creation of a Known Error during the course of the Problem Management process (once the root cause has been identified), Known Errors may also be introduced through software releases (Release Management)

Release Management; Software Development groups

No

Request for Status A query from a user or stakeholder on the status of an Incident or Problem User or stakeholder No

ReoccurrenceNotification of another Incident that has been linked to the Problem (or Known Error)

Incident Management No

Vendor Notification Notification of a Problem or Known Error from a vendor Vendor Yes

Configuration InfoConfiguration information to aid in root cause analysis & fix development (in the future)

Configuration Management System (CMS)

No

Progress Updates Ongoing updates to the Incident or Problem - captured in the Activity Log

Users, Service desk, network or computer operations, systems management tools

No



OutputsEach process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

Name Description Recipient Task

Status Update An update on the status/progress of an Incident or Problem Requester

Management Information

Management information to Availability, Capacity and Service Level Management

Availability, Capacity and Service Level Management

Permanent Fix

A permanent fix to eliminate further Incidents. A CR may be raised to implement the fix via Change Management.

Affected Users, Change Management, Incident Management

Workaround

An optimized or new Workaround that can be provided to users to allow them to continue using the service until a permanent fix is found or in case a permanent fix will not be implemented for whatever reason.

Affected users, Incident Management, Knowledge Management

Reports

Reports that aid management in spotting inefficiencies, non-compliance and other opportunities for improvement

Problem Process Manager, Problem Coordinator



ActivitiesHigh level description of the activities in the process

ID Name Description

PRB 1.0 Identifying and Logging This activity is focused on getting new Problems recorded and assigned to the correct group and analyst for investigation.

PRB 2.0 Investigating and Updating

1. Ensure that this is not a duplicate of an existing Problem. 2. Analyze existing Workarounds, accepting one as is, optimizing one for re-use or developing a new one as required.3. Determine the root cause of the Problem.4. Re-designate it as a Known Error. Consultations (including with vendors) may occur.

PRB 3.0 Propose Fix Having found the root cause, this activity now seeks to find a suitable permanent fix.

PRB 4.0 Resolving and Closing

Tasks in this activity include interfacing with other processes such as Release and Change Management to ensure that the identified fix is obtained or developed, tested and implemented. The activity concludes with the verification that the fix did in fact resolve the Known Error and if so the closure of the Known Error with advice to Incident Management to allow that process to perform any required clean up.



PRB 1.0: Identifying and LoggingThis activity is focused on getting new Problems recorded and assigned to the correct group and analyst for investigation.

PRB 1.1: Process Start

PRB 1.2: Create New Problem Record

A new Problem has been declared and a Problem record is now being created. If the Problem was declared during Incident Management, much of the information already captured in an Incident can be brought forward. Once created, the Problem record must be assigned to the appropriate support group for further investigation.Annotation: Majority of Problem records will originate from Incident Management

PRB 1.3: Queue to Support Group

The problem record is assigned to the correct support groupAnnotation: Best practice is to initially assign at the group level

PRB 1.4: Review and Accept

The Priority of the Problem is reviewed and modified as required. The Problem Coordinator reviews the suitability of the Support Group chosen, and may modify. If they change the Support Group, the Problem will be re-queued to that group.

Annotation: Ensure assignment is correct, if not re-categorize to allow the ServiceNow ITSM tool to automatically re-queue it

PRB 1.5: Queued Correctly?

PRB 1.6: Review and Assign

Once a support group has accepted a Problem the Problem Coordinator then reviews the Priority. If the Problem arose from an Incident, the Problem will have inherited the Impact and Urgency (and hence Priority) from the Incident. But the Incident count may have risen to a level where the priority of the Problem needs to be raised. Other factors, such as the availability of a Workaround and customer pressure may also influence the decision to adjust the Priority. Once the Priority is set, the Problem Coordinator establishes a time budget for reviewing any existing Workaround and designates a member of their team to do the work.

PRB 1.7: Accept Assignment

The designated Problem Support person accepts the assignment.

Annotation: May be returned if assignee determines they have too many higher priority problems or lacks desired expertise

PRB 1.8: Assigned Correctly?



Cross-Functional Flow Diagram



PRB 1.1: Process Start

PRB 1.1: Task WorkflowWhere we came from and where we are going

PredecessorsTask ID Task Name Diagram LabelSuccessorsTask ID Task Name Diagram LabelPRB 1.2 Create New Problem Record

PRB 1.1: Task RolesWho does what to complete the task

Name Duties RACISubmitter R/A

PRB 1.2: Create New Problem RecordA new Problem has been declared and a Problem record is now being created. If the Problem was declared during Incident Management, much of the information already captured in an Incident can be brought forward. Once created, the Problem record must be assigned to the appropriate support group for further investigation.

PRB 1.2: Task Inter ProcessInter Process defines the connections between external Processes.

Process Task ID Description Label DirectionIncident Management Problem Declared Problem Declared In


PredecessorsTask ID Task Name Diagram LabelPRB 1.1 Process StartSuccessorsTask ID Task Name Diagram LabelPRB 1.3 Queue to Support Group




Name Duties RACI

Submitter Create the Problem record and ensure that all necessary information has been provided (as mandated by policies and procedures). R/A

Incident Support Consultation with Incident Support may be necessary CIncident Coordinator Consultation with the Incident coordinator may be necessary. C

PRB 1.3: Queue to Support GroupThe problem record is assigned to the correct support group


PredecessorsTask ID Task Name Diagram Label

PRB 1.2 Create New Problem RecordSuccessorsTask ID Task Name Diagram LabelPRB 1.4 Review and Accept Queued


Name Duties RACI

Submitter Based on the problem classification and the identified failing CI (from Incident management) assign the problem to the correct Problem Support team R/A

PRB 1.4: Review and AcceptThe Priority of the Problem is reviewed and modified as required. The Problem Coordinator reviews the suitability of the Support Group chosen, and may modify. If they change the Support Group, the Problem will be re-queued to that group.



PRB 1.3 Queue to Support Group QueuedPRB 1.5 Queued Correctly? No, re-queued

SuccessorsTask ID Task Name Diagram LabelPRB 1.5 Queued Correctly?




Name Duties RACI

Problem Coordinator

Review categorization and CI information to verify the problem has been routed to the correct support group. If not, adjust the categorization to have the problem re-queued to the correct support group. May require consultation with the appropriate Incident Coordinator.

R/A

Incident Support Consultation with Incident Support to determine current group assignment CIncident Coordinator Consultation with the Incident Coordinator to determine current conditions. C

PRB 1.5: Queued Correctly?



PRB 1.4 Review and AcceptSuccessorsTask ID Task Name Diagram LabelPRB 1.4 Review and Accept No, re-queuedPRB 1.6 Review and Assign Yes


Name Duties RACIProblem Coordinator R

PRB 1.6: Review and AssignOnce a support group has accepted a Problem the Problem Coordinator then reviews the Priority. If the Problem arose from an Incident, the Problem will have inherited the Impact and Urgency (and hence Priority) from the Incident. But the Incident count may have risen to a level where the priority of the Problem needs to be raised. Other factors, such as the availability of a Workaround and customer pressure may also influence the decision to adjust the Priority. Once the Priority is set, the Problem Coordinator establishes a time budget for reviewing any existing Workaround and designates a member of their team to do the work.



PRB 1.8 Assigned Correctly? NoPRB 1.5 Queued Correctly? Yes



SuccessorsTask ID Task Name Diagram LabelPRB 1.7 Accept Assignment Assigned


Name Duties RACI

Problem Coordinator Review, and adjust, the priority, set the budget for identifying root cause and assign the problem to an individual support person R/A

PRB 1.7: Accept AssignmentThe designated Problem Support person accepts the assignment.



PRB 1.6 Review and Assign AssignedSuccessorsTask ID Task Name Diagram LabelPRB 1.8 Assigned Correctly?


Name Duties RACIProblem Coordinator Ensures that problems are accepted and work begins within an acceptable timeframe. A

Problem Support Accept the assignment and begin work on the Problem within the scope of the process and the budget bounds set by the Problem Coordinator. R

PRB 1.8: Assigned Correctly?



PRB 1.7 Accept AssignmentSuccessorsTask ID Task Name Diagram Label



Task ID Task Name Diagram LabelPRB 2.1 Valid Problem? YesPRB 1.6 Review and Assign No


Name Duties RACIProblem Support R



PRB 2.0: Investigating and Updating1. Ensure that this is not a duplicate of an existing Problem. 2. Analyze existing Workarounds, accepting one as is, optimizing one for re-use or developing a new one as required.3. Determine the root cause of the Problem.4. Re-designate it as a Known Error. Consultations (including with vendors) may occur.

PRB 2.1: Valid Problem?

Review the assigned Problem record against criteria for a valid New Problem.

PRB 2.2: Cancel Problem

Problem has been identified as invalid or a duplicate of a previously reported open problem

PRB 2.3: Optimize Workaround

Workaround optimization takes place at this task. If the Workaround developed in the Incident is deemed as inappropriate for future use, an alternative should be provided. Once a root cause has been determined, the Workaround may be re-optimized.

Annotation: The Incident Management developed workaround is optimized or flagged as invalid and an alternate resolution is defined

PRB 2.4: Problem Review

Once the Workaround has been optimized, the Problem Coordinator will re-evaluate the priority of the Problem and either assign the Problem to a Problem Support person with a budget to find Root Cause or decide not to proceed any further for now and put the Problem in a do not pursue state.

Annotation:No blank checks, an appropriate work effort budget should be established for attempting root cause determination.Budget= any or a combination of the following Cost/Effort/Resources

PRB 2.5: Pursue Root Cause?

Decision to pursue root cause determination at this time or put the problem on hold

Annotation: The impact of the re-occurring incidents may be limited and not warrant further work effort at this time

PRB 2.6: Assign to Support

Now that the decision to pursue root cause has been made and the initial budget for the work effort determined the problem record will be assigned to a support individual

PRB 2.7: Accept Assignment?

The designated Problem Support role accepts the assignment to look for Root Cause within the budget established.

Annotation:Assignee will review the Problem record and accept the assignment. If they do not have the requisite skill set or other commitments they may return the record to the queue

PRB 2.8: Perform Root Cause Analysis



What happens during this activity is highly dependent upon the area of specialization (e.g., Operating System, Application Development, Telecomm). The actual steps followed and tools used to identify the root cause will vary widely and will typically be localized to the assigned support group.

Annotation: Root cause determination will continue until the work effort budget is reached or root cause is identified

PRB 2.9: Root Cause Identified?

PRB 2.10: Known Error

Set the Known Error status. If there is no Workaround, "wait for the permanent fix" becomes the de-facto workaround and this should impact the urgency for pursuing a permanent resolution.

PRB 2.11: Budget Exhausted?

Decision to pursue or not to pursue



PRB 2.1: Valid Problem?Review the assigned Problem record against criteria for a valid New Problem.



PRB 1.8 Assigned Correctly? YesSuccessorsTask ID Task Name Diagram LabelPRB 2.3 Optimize Workaround YesPRB 2.2 Cancel Problem No


Name Duties RACI

Problem CoordinatorIn cases where the decision whether the Problem should be considered valid and not a duplicate is uncertain. In some environments this consultation should be required before rejection.

C

Problem Support

Review the problem record against the criteria for declaring a problem to verify its validity before beginning additional work.If it is a duplicate, notify Level "n" support of the duplicate, provide the correct problem number and cancel this record as a duplicate.If it does not meet the criteria for declaring a problem, notify Level "N" support and cancel this recordReview the assigned Problem record against criteria for a valid New Problem

R/A

Incident Coordinator The Incident coordinator is informed that the problem is being cancelled because it is either a duplicate or invalid. I

PRB 2.2: Cancel ProblemProblem has been identified as invalid or a duplicate of a previously reported open problem


Process Task ID Description Label DirectionIncident Management Not a problem Out


Predecessors



Task ID Task Name Diagram LabelPRB 2.1 Valid Problem? NoSuccessorsTask ID Task Name Diagram LabelPRB 4.9 Close Problem


Name Duties RACIProblem Coordinator Cancel the problem with reason for canceling or link to duplicate R/A

PRB 2.3: Optimize Workaround Workaround optimization takes place at this task. If the Workaround developed in the Incident is deemed as inappropriate for future use, an alternative should be provided. Once a root cause has been determined, the Workaround may be re-optimized.


Process Task ID Description Label DirectionIncident Management Develop a Workaround Workaround Optimized Out


PredecessorsTask ID Task Name Diagram LabelPRB 2.1 Valid Problem? YesSuccessorsTask ID Task Name Diagram LabelPRB 2.4 Problem Review


Name Duties RACIProblem Coordinator Ensure workaround is acceptable. AProblem Support Review and optimize previous Workaround or propose an alternative. RService Desk Manager Inform Service Desk of new optimized workaround I

PRB 2.4: Problem ReviewOnce the Workaround has been optimized, the Problem Coordinator will re-evaluate the priority of the Problem and either assign the Problem to a Problem Support person with a budget to find Root Cause or decide not to proceed any further for now and put the Problem in a do not pursue state.





PRB 2.11 Budget Exhausted? YesPRB 2.5 Pursue Root Cause? Not at this timePRB 2.3 Optimize Workaround

SuccessorsTask ID Task Name Diagram LabelPRB 2.5 Pursue Root Cause?


Name Duties RACI

Problem Coordinator

Re-evaluate the priority of the Problem (impact and urgency) in light of the optimized workaround and recurring incident counts and frequency.Develop a budget for the work effort to be expended in determining root cause and based on the priority and budget determine whether to assign the Problem to a Problem Support person or place the problem in a "do not pursue" state.Additionally, determine if the impact and urgency of the problem is higher or lower than originally reported in the incident and adjust accordingly.

R/A

Incident Coordinator Incident Coordinator is informed if a change in priority is made. I

Service Owner Will be consulted when and if a Problem should be placed or removed from "Do Not Pursue" state C

PRB 2.5: Pursue Root Cause?Decision to pursue root cause determination at this time or put the problem on hold



PRB 2.4 Problem ReviewSuccessorsTask ID Task Name Diagram LabelPRB 2.6 Assign to Support YesPRB 2.4 Problem Review Not at this time





PRB 2.6: Assign to SupportNow that the decision to pursue root cause has been made and the initial budget for the work effort determined the problem record will be assigned to a support individual



PRB 2.5 Pursue Root Cause? YesPRB 2.7 Accept Assignment? No

SuccessorsTask ID Task Name Diagram LabelPRB 2.7 Accept Assignment?


Name Duties RACI

Problem Coordinator Identify the most qualified support resource available and assign the problem for root cause identification R/A

Problem Support Review the assigned problem and accept or reject the assignment R

PRB 2.7: Accept Assignment?The designated Problem Support role accepts the assignment to look for Root Cause within the budget established.



PRB 2.6 Assign to SupportSuccessorsTask ID Task Name Diagram LabelPRB 2.8 Perform Root Cause Analysis YesPRB 2.6 Assign to Support No




Name Duties RACIProblem Coordinator Ensures Problem is accepted and work begins within an acceptable timeframe. AProblem Support R

PRB 2.8: Perform Root Cause AnalysisWhat happens during this activity is highly dependent upon the area of specialization (e.g., Operating System, Application Development, Telecomm). The actual steps followed and tools used to identify the root cause will vary widely and will typically be localized to the assigned support group.



PRB 2.11 Budget Exhausted? NoPRB 2.7 Accept Assignment? Yes

SuccessorsTask ID Task Name Diagram LabelPRB 2.9 Root Cause Identified?


Name Duties RACI

Problem Coordinator As required to advise on the involvement of other groups or vendors for assistance and review the current root cause analysis. A

Problem Support Any and all actions necessary to identify the Root Cause within the specified budget, including the use of diagnostic tools and models. R/A

Incident Coordinator Incident coordinator is informed when a root cause has been determined. I

PRB 2.8: Task Notes

DescriptionThere are many sound and proven methodologies for investigating the root cause(s) of Problems. These are useful across many disciplines and are trainable and transferable skills. A common approach to problem solving can be a very effective enhancement to the Problem Management process.

PRB 2.9: Root Cause Identified?

PRB 2.9: Task Workflow



Where we came from and where we are going

PredecessorsTask ID Task Name Diagram LabelPRB 2.8 Perform Root Cause AnalysisSuccessorsTask ID Task Name Diagram LabelPRB 2.10 Known Error YesPRB 2.11 Budget Exhausted? No



PRB 2.10: Known ErrorSet the Known Error status. If there is no Workaround, "wait for the permanent fix" becomes the de-facto workaround and this should impact the urgency for pursuing a permanent resolution.


Process Task ID Description Label DirectionIncident Management Root Cause Identified Root Cause Out


PredecessorsTask ID Task Name Diagram LabelPRB 2.9 Root Cause Identified? YesSuccessorsTask ID Task Name Diagram LabelPRB 3.1 Known Error Review


Name Duties RACI

Problem Coordinator The Problem Coordinator may need to review and adjust the budget for the Problem if it is seen to be desirable to re-optimize a Workaround. C



Name Duties RACI

Problem SupportRe-designate the Problem as a Known Error by setting the Known Error status to true. Review, and if necessary, re-optimize the associated workaround based on the knowledge of the Root Cause.

R/A

PRB 2.11: Budget Exhausted?Decision to pursue or not to pursue



PRB 2.9 Root Cause Identified? NoSuccessorsTask ID Task Name Diagram LabelPRB 2.8 Perform Root Cause Analysis NoPRB 2.4 Problem Review Yes



PRB 2.11: Task Notes

DescriptionMeans any or a combination of the following Cost/Effort/Resources



PRB 3.0: Propose FixHaving found the root cause, this activity now seeks to find a suitable permanent fix.

PRB 3.1: Known Error Review

Review the newly designated Known Error and determine whether to proceed with fixing the Root Cause, and if so how much to budget for it, what its priority is and who to assign it to.

PRB 3.2: Develop Fix?

Was the decision to pursue development of a permanent resolution or to defer work until the impact or urgency changes to a level sufficient to justify the work effort?


The decision to fix the problem has been made and an individual needs to be assigned to develop the permanent resolution.


Accept the assignment for developing fix specifications.

Annotation: Assignee will review the Known Error information and accept the assignment. If they do not have the requisite skill set they may return the record to the queue

PRB 3.5: Identify & Propose Fix

The focus of this task is not on the actual development of the fix, but rather on identifying a feasible approach. This may require consultation and collaboration with other colleagues and vendors.

Annotation: Fix determination will continue until the work effort budget is reached or a fix is proposed

PRB 3.6: Fix Identified?

Has a permanent resolution been identified or has the budget limit been reached


Annotation: Means any or a combination of the following Cost/Effort/Resources



PRB 3.1: Known Error ReviewReview the newly designated Known Error and determine whether to proceed with fixing the Root Cause, and if so how much to budget for it, what its priority is and who to assign it to.


PredecessorsTask ID Task Name Diagram LabelPRB 3.2 Develop Fix? Not at this timePRB 3.7 Budget Exhausted? YesPRB 4.8 Problem Fixed? NoPRB 2.10 Known ErrorSuccessorsTask ID Task Name Diagram LabelPRB 3.2 Develop Fix?


Name Duties RACI

Problem CoordinatorDetermine whether the Known Error should be fixed at this time or deferred and set a budget (in terms of work effort). R/A


PRB 3.2: Develop Fix?Was the decision to pursue development of a permanent resolution or to defer work until the impact or urgency changes to a level sufficient to justify the work effort?



PRB 3.1 Known Error ReviewSuccessorsTask ID Task Name Diagram LabelPRB 3.1 Known Error Review Not at this timePRB 3.3 Assign to Support Yes





PRB 3.3: Assign to SupportThe decision to fix the problem has been made and an individual needs to be assigned to develop the permanent resolution.



PRB 3.2 Develop Fix? YesPRB 3.4 Accept Assignment? No

SuccessorsTask ID Task Name Diagram LabelPRB 3.4 Accept Assignment?


Name Duties RACI

Problem Coordinator Identify the best-qualified available resource to develop the fix and assign the problem. R/A

Problem Support Review the assignment and accept or reject the assignment R

PRB 3.4: Accept Assignment?Accept the assignment for developing fix specifications.



PRB 3.3 Assign to SupportSuccessorsTask ID Task Name Diagram LabelPRB 3.5 Identify & Propose Fix YesPRB 3.3 Assign to Support No




Name Duties RACIProblem Coordinator Ensures the Known Error is accepted and work begins within an acceptable timeframe. AProblem Support Accept the responsibility to develop fix specifications if this can be done within budget R

PRB 3.5: Identify & Propose FixThe focus of this task is not on the actual development of the fix, but rather on identifying a feasible approach. This may require consultation and collaboration with other colleagues and vendors.



PRB 3.7 Budget Exhausted? NoPRB 3.4 Accept Assignment? Yes

SuccessorsTask ID Task Name Diagram LabelPRB 3.6 Fix Identified?


Name Duties RACIProblem Coordinator Consultation to determine the approach for identifying a fiix. C

Problem Support

Identify and document a viable permanent fix by employing whatever tools, techniques and resources are available within the assigned budget. Conduct additional investigation and research as required based on the nature of the identified root cause. Collaboration with colleagues and possibly vendors may also be initiated.

R/A

PRB 3.6: Fix Identified?Has a permanent resolution been identified or has the budget limit been reached



PRB 3.5 Identify & Propose FixSuccessorsTask ID Task Name Diagram LabelPRB 4.1 Review Priority and Budget YesPRB 3.7 Budget Exhausted? No








PRB 3.6 Fix Identified? NoSuccessorsTask ID Task Name Diagram LabelPRB 3.1 Known Error Review YesPRB 3.5 Identify & Propose Fix No



PRB 3.7: Task Notes

DescriptionMeans any or a combination of the following Cost/Effort/Resources



PRB 4.0: Resolving and ClosingTasks in this activity include interfacing with other processes such as Release and Change Management to ensure that the identified fix is obtained or developed, tested and implemented. The activity concludes with the verification that the fix did in fact resolve the Known Error and if so the closure of the Known Error with advice to Incident Management to allow that process to perform any required clean up.

PRB 4.1: Review Priority and Budget

A decision has to be made whether to actually proceed with implementing the permanent fix. Economics may sometimes preclude this or the risk of doing it may not be acceptable.

PRB 4.2: Implement Fix?

Decision point, implement or defer


The decision to implement the fix has been made and an individual must be assigned to carry out the work effort.


Accept the assignment to develop the fix and steer it through to completion, participating in the Change and Release processes as required and within the budget allocated

PRB 4.5: Develop Fix

The identified fix is now developedThis may include code development, software upgrades, acquisition of hardware, etc.

PRB 4.6: Implement the Fix

Required SDLC/CR(s) are prepared, submitted to Change ManagementAnnotation: Change Management will implement the permanent fix change

PRB 4.7: CR Successful?

Was the CR to implement the permanent fix successful? Has the Problem been eliminated?

PRB 4.8: Problem Fixed?

Change Management has reported a successful implementation of the change.

Annotation: Verification that the root cause has been eliminated is required as well as verification the Incidents no longer occur

PRB 4.9: Close Problem

The root cause has been eliminated

PRB 4.10: Process End



PRB 4.1: Review Priority and BudgetA decision has to be made whether to actually proceed with implementing the permanent fix. Economics may sometimes preclude this or the risk of doing it may not be acceptable.


PredecessorsTask ID Task Name Diagram LabelPRB 3.6 Fix Identified? YesPRB 4.2 Implement Fix? Not at this timePRB 4.4 Accept Assignment? NoSuccessorsTask ID Task Name Diagram LabelPRB 4.2 Implement Fix?


Name Duties RACI

Problem Coordinator

Review permanent fix with all associated resources (infrastructure, software, hardware, vendor, etc) and the impact and urgency related to the problem, the work effort associated with developing and implementing the fix and determine whether to implement the fix at this time or not.

R/A

Problem Support Consulted for decisions on proposed permanent fix. C


PRB 4.2: Implement Fix?Decision point, implement or defer



PRB 4.1 Review Priority and BudgetSuccessorsTask ID Task Name Diagram LabelPRB 4.3 Assign to Support YesPRB 4.1 Review Priority and Budget Not at this time





PRB 4.3: Assign to SupportThe decision to implement the fix has been made and an individual must be assigned to carry out the work effort.



PRB 4.2 Implement Fix? YesSuccessorsTask ID Task Name Diagram LabelPRB 4.4 Accept Assignment?


Name Duties RACI

Problem Coordinator Identify the best resource available and assign the problem to have the fix implemented. R

Problem Support Review the problem and accept or reject the assignment R

PRB 4.4: Accept Assignment?Accept the assignment to develop the fix and steer it through to completion, participating in the Change and Release processes as required and within the budget allocated



PRB 4.3 Assign to SupportSuccessorsTask ID Task Name Diagram LabelPRB 4.5 Develop Fix YesPRB 4.1 Review Priority and Budget No




Name Duties RACI

Problem Coordinator Ensure known error has been accepted and work has begun within an acceptable timeframe. A

Problem Support R

PRB 4.5: Develop FixThe identified fix is now developedThis may include code development, software upgrades, acquisition of hardware, etc.


Process Task ID Description Label Direction

SDLC Output to SDLC to develop proposed fix if needed Out


PredecessorsTask ID Task Name Diagram LabelPRB 4.4 Accept Assignment? YesPRB 4.7 CR Successful? No, CR failedSuccessorsTask ID Task Name Diagram LabelPRB 4.6 Implement the Fix


Name Duties RACIProblem Coordinator Review permanent fix with the Problem Support and implementation team. RProblem Support Perform the tasks necessary to prepare the identified fix for implementation R

PRB 4.6: Implement the FixRequired SDLC/CR(s) are prepared, submitted to Change Management



Change Management Determine if Standard Change Submit CR Out




PredecessorsTask ID Task Name Diagram LabelPRB 4.5 Develop FixSuccessorsTask ID Task Name Diagram Label


Name Duties RACIProblem Coordinator Ensure amendments/creation of the CR is appropriate. A

Problem Support

Define the implementation planDefine the Remediation planCreate and submit the CR to implement the fixMonitor Progress of the CR through Change Management

R

PRB 4.7: CR Successful?Was the CR to implement the permanent fix successful? Has the Problem been eliminated?


Process Task ID Description Label DirectionChange Management CR results Results In


PredecessorsTask ID Task Name Diagram LabelSuccessorsTask ID Task Name Diagram LabelPRB 4.8 Problem Fixed? YesPRB 4.5 Develop Fix No, CR failed




Name Duties RACI

Problem Support Review the results of the CR completion supplied by Change ManagementVerify that the Problem has been eliminated. C

PRB 4.8: Problem Fixed?Change Management has reported a successful implementation of the change.



PRB 4.7 CR Successful? YesSuccessorsTask ID Task Name Diagram LabelPRB 4.9 Close Problem YesPRB 3.1 Known Error Review No


Name Duties RACIProblem Coordinator Determine whether the root cause of the incidents has been removed or not R

PRB 4.9: Close ProblemThe root cause has been eliminated



Knowledge ManagementCreate knowledge management entry for future use

Out


PredecessorsTask ID Task Name Diagram LabelPRB 4.8 Problem Fixed? YesPRB 2.2 Cancel ProblemSuccessors



Task ID Task Name Diagram LabelPRB 4.10 Process End


Name Duties RACIProblem Coordinator Signs off on the closure R/A

Problem SupportThe Problem Support assignee will have accomplished the notifications required and have posted the required closure information in the record and creates a knowledge entry for future use.

C

PRB 4.10: Process End



PRB 4.9 Close ProblemSuccessorsTask ID Task Name Diagram Label





StatesStates are used to indicate points of progress of an instance through the lifecycle of the Process.

Process StatesThe following lists the discrete State values that can be assumed by a specific instance in this process.

Name DescriptionOpen Open Problem

Do Not Pursue Problem records that have been determined as do not pursue, either because of financial or other reasons.

Under Investigation Problem record has been assigned and is currently being investigated for known error or workaround

Known Error Root cause has been identified and appropriate knowledge article updates are being worked onPending Change Management For implementation of workaround or permanent fix

Closed/Resolved Problem record closed



Process State Diagram



Appendix

Attachments and Links



Definitions

Term Definition

RACI Model

The RACI Model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are:R Responsible for the action (may do the task)A Accountable for the action (including approval)C Required to be Consulted on the actionI Required to be Informed of the action

If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.

Budget Means any or a combination of the following Cost/Effort/Resources

Version 1 August 2015 · 2017-09-01 · Version 1 August 2015 Problem Management 08/31/2015....

Documents

Transcript of Version 1 August 2015 · 2017-09-01 · Version 1 August 2015 Problem Management 08/31/2015....