LP4.7: Resolve problems: Difference between revisions
From YaSM Service Management Wiki
No edit summary |
No edit summary |
||
| Line 118: | Line 118: | ||
<hr /> | <hr /> | ||
<p><i><u>Notes</u>:</i> | <p><i><u>Notes</u>:</i> | ||
</p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM data objects"</i> are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see <a href="https://yasm.com/wiki/en/index.php/Problem_Record_-_Template" title="Problem record document template"> | </p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM data objects"</i> are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see <a href="https://yasm.com/wiki/en/index.php/Problem_Record_-_Template" title="Problem record document template">'Problem record' template</a> and <a href="https://yasm.com/wiki/en/index.php/Service_Management_Checklists#yasm-template-example" title="Examples: YaSM checklists and document templates">more examples</a>) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see <a href="https://yasm.com/wiki/en/img/yasm-project/Yasm-object-lifecycle-diagram.jpg" title="Example: YaSM object lifecycle diagram (.JPG)">example</a>).</span> | ||
</p><p><i>"Other objects"</i> are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.</html> | </p><p><i>"Other objects"</i> are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.</html> | ||
| Line 129: | Line 129: | ||
==Roles and responsibilities== | ==Roles and responsibilities== | ||
<span id="responsible">Process owner: The '''problem manager''' is responsible for managing the lifecycle of all problems, where the primary objective is to prevent incidents from happening if possible, and to minimize the impact of incidents that cannot be prevented. Apart from resolving the underlying causes of (potential) incidents, the problem manager often provides workarounds while a full solution is not yet available.</span> | |||
<p> </p> | <p> </p> | ||
{| class="wikitable" style="background: white | {| class="wikitable" style="background: white; font-size: 95%" | ||
|+ | |+style="background:#465674; color:#ffffff; font-size: 110%"|<span id="raci-matrix-lp4-7">Responsibility matrix: 'LP4.7: Resolve problems'</span> | ||
|- style="vertical-align:top" | |- style="vertical-align:top" | ||
! colspan="2"| YaSM role / sub-process | ! colspan="2"| YaSM role / sub-process | ||
| Line 180: | Line 179: | ||
<html><div itemid="https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg" itemscope itemtype="https://schema.org/ImageObject"> | <html><div itemid="https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg" itemscope itemtype="https://schema.org/ImageObject"> | ||
<a href="https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg" title="Problem management: process objectives" itemprop="contentUrl"> | <a href="https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg" title="Problem management: process objectives" itemprop="contentUrl"> | ||
<img style="display: block; float: left; margin- | <img style="display: block; float: left; margin-bottom: 10px; margin-right: 10px" srcset="https://yasm.com/wiki/en/img/yasm-process/goal-definition/400px/yasm-problem-management-process.jpg 400w, https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/en/img/yasm-process/goal-definition/yasm-problem-management-process.jpg" decoding="async" width="400" height="209" class="thumbimage" title="Problem management: process goal" alt="The problem management process in YaSM manages the lifecycle of all problems, where a problem is the underlying cause of one or several (potential) incidents. The primary objective of this process is to prevent service incidents from happening, and to minimize the impact of incidents which cannot be prevented." /> | ||
<meta itemprop="caption" content="Process objective: YaSM problem management - Resolve problems (LP4.7)." /> | <meta itemprop="caption" content="Process objective: YaSM problem management - Resolve problems (LP4.7)." /> | ||
<meta itemprop="width" content="1200" /> | <meta itemprop="width" content="1200" /> | ||
<meta itemprop="height" content="627" /> | <meta itemprop="height" content="627" /> | ||
<meta itemprop="dateCreated" content="2021-09-21" /> | <meta itemprop="dateCreated" content="2021-09-21" /> | ||
<meta itemprop="datePublished" content="2021-09-22" /></ | <meta itemprop="datePublished" content="2021-09-22" /> | ||
< | <span itemprop="thumbnail" itemscope itemtype="https://schema.org/ImageObject"> | ||
<p style="margin-top: 0; word-wrap:normal;">Is based on: The problem resolution process from the <a href="https://yasm.com/en/products/yasm-process-map" title="YaSM Process Map">YaSM Process Map</a>.</p> | <meta itemprop="url" content="https://yasm.com/wiki/en/img/yasm-process/goal-definition/400px/yasm-problem-management-process.jpg" /> | ||
<meta itemprop="width" content="400" /> | |||
<p>By:  Stefan Kempter <a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Stefan Kempter | Profile on LinkedIn" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a>  and  Andrea Kempter <a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Andrea Kempter | Profile on LinkedIn" alt="Contributor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/ | <meta itemprop="height" content="209" /> | ||
</span></a></div> | |||
<p style="margin-top: 0; word-wrap:normal;">Is based on: The problem resolution process from the <a href="https://yasm.com/en/products/yasm-process-map" title="YaSM Process Map">YaSM Process Map</a>.</p> | |||
<p>By:  Stefan Kempter <a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Stefan Kempter | Profile on LinkedIn" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a>  and  Andrea Kempter <a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Andrea Kempter | Profile on LinkedIn" alt="Contributor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/><p></html> | |||
==Related articles== | ==Related articles== | ||
<html><a href="https://yasm.com/wiki/en/index.php/Service_Operation"><img src="https://yasm.com/wiki/en/img/yasm-service-management/service-operation.jpg" title="Service operation according to YaSM" alt="Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of ITSM best practice." | <html><a href="https://yasm.com/wiki/en/index.php/Service_Operation"><img style="display: block; float: left; margin-bottom: 10px; margin-right: 10px" srcset="https://yasm.com/wiki/en/img/yasm-service-management/400px/service-operation.jpg 400w, https://yasm.com/wiki/en/img/yasm-service-management/480px/service-operation.jpg 480w, https://yasm.com/wiki/en/img/yasm-service-management/service-operation.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/en/img/yasm-service-management/service-operation.jpg" title="Service operation according to YaSM" alt="Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of ITSM best practice." decoding="async" width="400" height="225" class="thumbimage" /></a> | ||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/en/index.php/Service_Operation" title="From the YaSM Blog: Service operation according to YaSM">Service operation according to YaSM</a></p> | |||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/en/index.php/Service_Operation" title="From the YaSM Blog: Service operation according to YaSM">Service operation according to YaSM</a></p> | |||
<p><small>by: Stefan Kempter</small></p> | <p><small>by: Stefan Kempter</small></p> | ||
<p>Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of IT service management best practice. <a href="https://yasm.com/wiki/en/index.php/Service_Operation">[...]</a></p | <p>Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of IT service management best practice. <a href="https://yasm.com/wiki/en/index.php/Service_Operation">[...]</a></p><p> | ||
<br style="clear:both;"/> | <br style="clear:both;"/> | ||
Revision as of 16:31, 29 January 2024
Process name: Resolve problems - Part of: Service lifecycle processes - Operate the services
Previous process: Resolve incidents and service requests
Process description
The problem management process in YaSM (fig. 1) is about managing the lifecycle of all problems, where a problem is the underlying cause of one or several (potential) incidents. The primary objective of the problem resolution process is to prevent service incidents from happening, and to minimize the impact of incidents which cannot be prevented.
Compatibility: YaSM problem management is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, section 8.6), and it corresponds to the practice of 'ITIL 4 problem management'.
Sub-processes
YaSM's problem management process has the following sub-processes:
- LP4.7.1: Pro-actively identify problems
- Process objective: To improve overall availability of services by proactively identifying problems. This process aims to identify and solve problems and/ or provide suitable workarounds before (further) service incidents occur.
- LP4.7.2: Categorize and prioritize problems
- Process objective: To record and prioritize the problems with appropriate diligence, in order to facilitate a swift and effective resolution.
- LP4.7.3: Analyze and resolve problems
- Process objective: To identify the underlying causes of problems and to determine the most appropriate and economical problem solution. If possible, a temporary workaround should be supplied while no full solution is available.
- LP4.7.4: Monitor outstanding problems
- Process objective: To constantly monitor outstanding problems with regards to their processing status, and to take corrective action as required.
- LP4.7.5: Close problems
- Process objective: To ensure that the problem resolution has been successful and all related information is up-to-date.
Process outputs
This section lists the documents and records produced by the problem resolution process. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.
- Incident model
- An incident model contains the pre-defined steps that should be taken for dealing with a particular type of incident. The aim of providing incident models is to ensure that recurring incidents are handled efficiently and effectively. [*]
- Problem record
- A set of data with all details of a problem, documenting the history of the problem from registration to closure. A problem is defined as the underlying cause of one or more (potential) incidents, although the cause may not be known at the time a problem record is created. Often, a workaround is provided for a problem while a full resolution is not yet available. See also: Problem record checklist. [*]
- Recovery plan
- Recovery plans contain detailed instructions for returning specific services and/ or systems to a working state, which often includes recovering data to a defined consistent state. [*]
- Service operation manual
- A service operation manual specifies the activities required for the operation of a service and its underlying infrastructure. The information in the service operation manual is meant to describe the day-to-day tasks in a way that is useful for operational staff. Some instructions related to the operation of particular applications, systems or other infrastructure components may be documented in separate technical manuals or 'standard operating procedures (SOPs)'. [*]
- Suggested process modification
- A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.
- Suggested service modification
- A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.
- Support request
- A request to support the resolution of an incident or problem, usually issued from the incident or problem manager when further assistance is needed from technical experts or external suppliers.
Notes:
[*] "YaSM data objects" are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see 'Problem record' template and more examples) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see example).
"Other objects" are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.
Process metrics
Process metrics are used, for example, to assess if the service management processes are running according to expectations.
For suggestions of suitable metrics, please refer to the list of metrics for the problem resolution process.
Roles and responsibilities
Process owner: The problem manager is responsible for managing the lifecycle of all problems, where the primary objective is to prevent incidents from happening if possible, and to minimize the impact of incidents that cannot be prevented. Apart from resolving the underlying causes of (potential) incidents, the problem manager often provides workarounds while a full solution is not yet available.
| YaSM role / sub-process | Problem manager | Service owner | Technical domain expert | |
|---|---|---|---|---|
| LP4.7.1 | Pro-actively identify problems | AR | - | - |
| LP4.7.2 | Categorize and prioritize problems | AR | - | - |
| LP4.7.3 | Analyze and resolve problems | AR | R | R |
| LP4.7.4 | Monitor outstanding problems | AR | - | - |
| LP4.7.5 | Close problems | AR | - | - |
Notes
Is based on: The problem resolution process from the YaSM Process Map.
By: Stefan Kempter 
and Andrea Kempter , IT Process Maps.
Related articles
Service operation according to YaSM
by: Stefan Kempter
Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of IT service management best practice. [...]
Process description › Sub-processes › Process outputs › Metrics › Roles
