ITIL Problem Management - Revision history

User at 10:42, 17 January 2023

2023-01-17T10:42:16Z

User at 10:36, 17 January 2023

2023-01-17T10:36:54Z

Show changes

User at 13:38, 12 January 2023

2023-01-12T13:38:21Z

User at 14:43, 23 November 2022

2022-11-23T14:43:38Z

User at 16:34, 23 March 2021

2021-03-23T16:34:19Z

User at 16:25, 22 March 2021

2021-03-22T16:25:21Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T16:16:59Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

Show changes

User at 17:32, 29 January 2021

2021-01-29T17:32:33Z

User at 17:30, 29 January 2021

2021-01-29T17:30:12Z

User at 17:08, 29 January 2021

2021-01-29T17:08:16Z

@@ Line 30: / Line 30: @@
 ''Scope''<br />
-Problem Management includes the activities required to diagnose the root cause of incidents identified through the [[Incident Management]] process, and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially [[Change Management]] and [[Release Management]].
+Problem Management includes the activities required to diagnose the root cause of incidents identified through the Incident Management process, and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially Change Management and [[Release Management]].
-Problem Management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. In this respect, Problem Management has a strong interface with [[Knowledge Management]], and tools such as the Known Error Database will be used for both. Although Incident Management and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related incidents and problems.
+Problem Management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. In this respect, Problem Management has a strong interface with Knowledge Management, and tools such as the Known Error Database will be used for both. Although Incident Management and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related incidents and problems.
 ''Value to Business''<br />
@@ Line 59: / Line 59: @@
 source: Paldesk
-Proactive problem management is a continuous process that doesn’t wait for an incident to happen to react. This type of problem management is always active and always on guard. “Proactive problem management can be extremely challenging.” Especially in an environment where you have lots of services, different technologies, and when many things are going on. With proactive problem management, the focus is on continuous [[data]] analysis, and to do that, you need a large volume of quality data.
+Proactive problem management is a continuous process that doesn’t wait for an incident to happen to react. This type of problem management is always active and always on guard. “Proactive problem management can be extremely challenging.” Especially in an environment where you have lots of services, different technologies, and when many things are going on. With proactive problem management, the focus is on continuous data analysis, and to do that, you need a large volume of quality data.
@@ Line 74: / Line 74: @@
 ***Review the list of ideas to clarify and remove any duplicates
 ***Prepare an action plan to communicate to stakeholders
-*[[Cause and Effect Analysis|Ishikawa / Fishbone / Cause and Effect Analysis]]: The cause-effect analysis describes relationships between a problem and its possible causes. For example [[network]] downtime is a problem which might have possible reasons such as router malfunction, network error, disaster, etc. Therefore, this method analyses various causes and defines relationships. This method is also known as [[Cause and Effect Diagram|Ishikawa or fishbone diagram]] that analyses primary and secondary causes of a problem. Causes, in turn, have different categories such as people, product, process, and partners. This method is used for reactive problem management. Therefore, it is essential to define the problem statement precisely.
+*[[Cause and Effect Analysis|Ishikawa / Fishbone / Cause and Effect Analysis]]: The cause-effect analysis describes relationships between a problem and its possible causes. For example network downtime is a problem which might have possible reasons such as router malfunction, network error, disaster, etc. Therefore, this method analyses various causes and defines relationships. This method is also known as [[Cause and Effect Diagram|Ishikawa or fishbone diagram]] that analyses primary and secondary causes of a problem. Causes, in turn, have different categories such as people, product, process, and partners. This method is used for reactive problem management. Therefore, it is essential to define the problem statement precisely.
 **Get a thorough picture of all possible causes for an effect/situation
 **Ideal for complex problems
@@ Line 84: / Line 84: @@
 ***Use traditional brainstorming techniques to fill in possible reasons for the “ribs.”
 ***Classify and prioritize primary and secondary causes as trunks
-*[[Kepner-Tregoe Matrix|Kepner Tregoe Problem Analysis]]: A logical approach to problem-solving, starting with defining and then describing the problem. Possible causes are established, and then tested, and finally, the exact cause is verified. Systematic four phase [[Root Cause Analysis|Root Cause Analysis (RCA)]] for complex problem analysis. Kepner Tregoe focuses on finding the root cause before getting into solutions. It is a group problem-solving technique to identify actual root cause with the help of evidence. KT enables group problem solving, speed and precision. KT framework includes “is” and “is not” kind of analysis. Kepner Tregoe (KT) is applicable for both proactive and reactive problem management. It involves problem analysis as well as potential problem analysis.
+*[[Kepner-Tregoe Matrix|Kepner Tregoe Problem Analysis]]: A logical approach to problem-solving, starting with defining and then describing the problem. Possible causes are established, and then tested, and finally, the exact cause is verified. Systematic four phase Root Cause Analysis (RCA) for complex problem analysis. Kepner Tregoe focuses on finding the root cause before getting into solutions. It is a group problem-solving technique to identify actual root cause with the help of evidence. KT enables group problem solving, speed and precision. KT framework includes “is” and “is not” kind of analysis. Kepner Tregoe (KT) is applicable for both proactive and reactive problem management. It involves problem analysis as well as potential problem analysis.
 **What’s going on – Situation Appraisal
 **Why did this occur – Problem analysis
 **Actual cause for the problem and alternatives – Decision analysis
 **What is the plan of action and risk associated – Potential problem analysis
-*[[Five Whys|5 Whys]]: Five why strategy is a simple and effective mechanism to understand the root cause of a problem by asking subsequent “why” questions. It is one of the six sigma techniques to identify the actual root cause of a problem and take appropriate countermeasures to prevent from occurring in future. It defines the relationships between different root causes. However, it is significant to frame the questions properly to find out the actual root cause. Asking why question five times is just a rule of thumb, and it varies depending on the problem complexity.
+*5 Whys: Five why strategy is a simple and effective mechanism to understand the root cause of a problem by asking subsequent “why” questions. It is one of the six sigma techniques to identify the actual root cause of a problem and take appropriate countermeasures to prevent from occurring in future. It defines the relationships between different root causes. However, it is significant to frame the questions properly to find out the actual root cause. Asking why question five times is just a rule of thumb, and it varies depending on the problem complexity.
 **Gather a group of people who are familiar with the problem
 **Ask “why” questions – ‘n’ times depending on the complexity and type of answers
@@ Line 145: / Line 145: @@
 == Problem Management Vs. Key ITIL Processes<ref>The Relationship Between Problem Management and Other Key ITIL Processes [https://www.atlassian.com/itsm/problem-management Atlassian]</ref> ==
-Problem management works alongside incident management and other ITIL practices to form an overall [[IT Service Management (ITSM)|ITSM]] strategy.
+Problem management works alongside incident management and other ITIL practices to form an overall ITSM strategy.
 ''Problem Management vs. Incident Management''<br />
@@ Line 156: / Line 156: @@
 [[Knowledge Management|Knowledge management]] creates a repository of solutions and documentation for common procedures and even incident workarounds. When used together, a healthy knowledge management practice can enable faster incident resolution and fewer incidents altogether.
-''Problem Management and [[Service Request Management]]''<br />
+''Problem Management and Service Request Management''<br />
 [[Service Request Management|Service request management]] is the practice of processing a request from a user for something to be provided, such as access to applications, software enhancements, and information. It can sometimes be difficult to distinguish a service request from an incident. In fact, the two were not distinguished and both lumped into the category “incidents” until the release of ITIL V3 in 2007. ITIL now defines an incident as ‘an unplanned interruption to an IT service or reduction in the quality of an IT service.’ It defines a service request as “a formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user.”

@@ Line 190: / Line 190: @@
 == See Also ==
 <div style="column-count:2;-moz-column-count:3;-webkit-column-count:3">
-[[ITIL Availability Management]]<br />
 </div>

@@ Line 1: / Line 1: @@
 == Definition of Problem Management ==
-'''Problem Management''' is an [[IT Service Management (ITSM)|IT service management]] [[process]] tasked with managing the life cycle of underlying "Problems." Success is achieved by quickly detecting and providing solutions or [[Workaround|workarounds]] to Problems in order to minimize [[impact]] on the [[organization]] and prevent recurrence. Problem Management also attempts to find the error in the [[IT Infrastructure|IT infrastructure]] that is causing the Problem and contributing to the Incidents that users may have. The [[ITIL (Information Technology Infrastructure Library)|IT Infrastructure Library (ITIL)]] provides the following definitions for usage within this process:
+'''Problem Management''' is an [[IT Service Management (ITSM)|IT service management]] [[process]] tasked with managing the life cycle of underlying "Problems." Success is achieved by quickly detecting and providing solutions or [[Workaround|workarounds]] to Problems in order to minimize impact on the [[organization]] and prevent recurrence. Problem Management also attempts to find the error in the [[IT Infrastructure|IT infrastructure]] that is causing the Problem and contributing to the Incidents that users may have. The [[ITIL (Information Technology Infrastructure Library)|IT Infrastructure Library (ITIL)]] provides the following definitions for usage within this process:
 *Problem: “The cause of one or more Incidents. The cause is not usually known at the time a Problem record is created"
 *Error: “A [[design]] flaw or malfunction that causes a failure of one or more [[IT Services (Information Technology Services)|IT services]] or other [[Configuration Item (CI)|configuration items]]”

@@ Line 1: / Line 1: @@
 == Definition of Problem Management ==
-'''Problem [[Management]]''' is an IT [[service]] management [[process]] tasked with managing the life cycle of underlying "Problems." Success is achieved by quickly detecting and providing solutions or workarounds to Problems in order to minimize [[impact]] on the [[organization]] and prevent recurrence. Problem Management also attempts to find the error in the [[IT Infrastructure|IT infrastructure]] that is causing the Problem and contributing to the Incidents that users may have. The [[ITIL (Information Technology Infrastructure Library)|IT Infrastructure Library (ITIL)]] provides the following definitions for usage within this process:
+'''Problem Management''' is an [[IT Service Management (ITSM)|IT service management]] [[process]] tasked with managing the life cycle of underlying "Problems." Success is achieved by quickly detecting and providing solutions or [[Workaround|workarounds]] to Problems in order to minimize [[impact]] on the [[organization]] and prevent recurrence. Problem Management also attempts to find the error in the [[IT Infrastructure|IT infrastructure]] that is causing the Problem and contributing to the Incidents that users may have. The [[ITIL (Information Technology Infrastructure Library)|IT Infrastructure Library (ITIL)]] provides the following definitions for usage within this process:
 *Problem: “The cause of one or more Incidents. The cause is not usually known at the time a Problem record is created"
 *Error: “A [[design]] flaw or malfunction that causes a failure of one or more [[IT Services (Information Technology Services)|IT services]] or other [[Configuration Item (CI)|configuration items]]”
@@ Line 204: / Line 204: @@
 [[ITIL Service Value System (SVS)]]<br />
 [[Service Portfolio Management]]<br />
 [[IT_Governance|IT Governance]]<br />
 [[IT Infrastructure]]<br />

@@ Line 186: / Line 186: @@
 *Encourages IT services to mature as the organization develops by the learning from the resolved problems.
 *Develops IT talent within the organization through technical awareness and valuable insights.
 == References ==
 <references/>

@@ Line 3: / Line 3: @@
 *Problem: “The cause of one or more Incidents. The cause is not usually known at the time a Problem record is created"
 *Error: “A design flaw or malfunction that causes a failure of one or more [[IT Services (Information Technology Services)|IT services]] or other [[Configuration Item (CI)|configuration items]]”
-*Known Error: “A Problem that has a documented root cause and workaround”
+*[[Known Error]]: “A Problem that has a documented root cause and workaround”
-*Root Cause: “The underlying or original cause of an incident or problem”.<ref>Definition - What Does Problem Management Mean in ITIL? [https://www.cherwell.com/it-service-management/library/essential-guides/essential-guide-to-itil-problem-management/#:~:text=Back%20to%20top-,What%20is%20ITIL%20Problem%20Management%3F,the%20organization%20and%20prevent%20recurrence. Cherwell]</ref>
+*[[Root Cause]]: “The underlying or original cause of an incident or problem”.<ref>Definition - What Does Problem Management Mean in ITIL? [https://www.cherwell.com/it-service-management/library/essential-guides/essential-guide-to-itil-problem-management/#:~:text=Back%20to%20top-,What%20is%20ITIL%20Problem%20Management%3F,the%20organization%20and%20prevent%20recurrence. Cherwell]</ref>