# Problem Management A problem is an underlying root cause of one or more tickets. Recurring incidents with common issues lead to a problem. \*A problem can be linked to tickets(reported for the same underlying issue), a request, or a change(part of a future release). Problem Management is the process responsible for managing the lifecycle of the problem from its creation till its closure. Problem management aims to provide solutions or workarounds to problems so they have a minimum impact on the organization. Problem Management also seeks to prevent a problem from reoccurring. ## How does it work? Only a technician or users with the required permissions can log a Problem. While adding a problem in the Problem module, a technician records the source of the problem. The source can be one of the following: * Web portal * Mobile app * Email * By a technician on call Streamlined problem-to-ticket association. Create a problem, log a ticket from the problem view page, add internal notes, and submit to establish the relationship. Click on the ticket ID, and the ticket will open on a new page for seamless navigation and management. ## Benefits of Problem Management Efficient Problem Management can have several benefits for an organization. It can also add substantial value to a business. Some of the benefits of Problem Management are: * Increase in Service Availability * Increase in Productivity * Customer Satisfaction * Decrease in the number of tickets * Cost Saving ## Problem Management Process Infraon's Problem Management module enables organizations to achieve their goals through the following steps: * **Problem Detection** - This is the first step of Problem Management. A problem can be detected in two ways. * Suppose different requesters raise multiple tickets for the same issue. This means there is an underlying issue that needs to be further analyzed, and a problem is recorded. * If a completely new issue arises with an unknown underlying cause, then a problem is recorded. * **Problem Recording**  - Only a technician or users with the required permissions can log a Problem in the module. * **Classification & Prioritization**  - It is essential to capture all the problem details, such as problem type and description. A problem has a category and sub-category. Capturing and classifying the details makes it easier to assign & monitor the problem. * **Investigation & Diagnosis** - Problem management is finding the root cause of an issue. A detailed Root Cause Analysis(RCA) is performed based on the urgency and severity of the problem. Multiple analyses can be added until the root cause is identified. The various methods used for analysis are: * 5-Whys * Chronological * Kepner Tregoe * **Create a Known Error Record** - In ITIL, a Known Error is "a problem with a documented root cause and a workaround." It is essential to record this information in a known error database (KEDB) so that if this issue or problem arises, the service desk technician can quickly look into the KEDB and provide a quick resolution or associated workaround. This leads to less downtime. * **Create a workaround, if necessary** - A workaround is a temporary solution to a problem so that it can reduce the impact on a business. A workaround for a problem can be created and documented in the KEDB. * **Escalation & Notification**—When a problem requires more significant expertise, a technician escalates it to L2/L3-level technicians or engineers. Notification emails keep the technicians well-informed of these proceedings. * **Resolution** - A resolution is a permanent fix for a problem such that it can no longer cause another ticket. * **Review & Closure -** The resolution is reviewed to ensure its effectiveness. Once the technicians are satisfied with it, the problem can be closed.
ITSM Problem Workflow

Problem Workflow

### **Problem Management and relation with other processes** | **Process** | **Relation with Problem Management** | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ticket Management |

Different requesters raising multiple tickets for the same issue denotes an underlying issue that needs to be further analyzed.

A new issue is raised with an unknown underlying cause

In the above cases, a problem is logged. These tickets can be linked to the problem. The tickets are put on hold until a workaround/solution is provided.

| | \*Request Management |

A service request raised by a user to install new software in the laptop may have disrupted/corrupted other software.

Implementing a resolution to a problem may require a user to raise a service request to install a software patch.

In the above cases, the service requests can be linked to the problem.

| | \*Change Management |

Sometimes, a change may disrupt service. This leads to logging a ticket and, subsequently, a problem in analyzing the cause.

Problem Management may initiate resolution through a change request. The approval/implementation of the change is beyond the scope of Problem Management. This needs to be done in Change Management.

In this case, a change request is linked to the problem.

| | \*Knowledge Management |

Important information regarding workarounds, resolutions and Known Errors (KE) is often the output of Problem Management.

Similarly, information and documents available in Knowledge Base(KB) can serve as a beginning point to diagnose and investigate a problem.

In these cases, Knowledge Management comes into the picture. KBs can be attached to the problem, or a resolution or Known Error information can be turned into a Knowledge Base article.

| **Recurring Incidents Auto-Conversion** Problems can be automatically created when incidents with the same requester, service, or asset occur multiple times within a short period of time. If **five or more** related incidents are logged within **14 days,** the most recent incident is converted into a Problem, and all associated incidents are linked for better traceability. [Click here](/infraon-help/infinity-user-guide/ticket-management/tickets.md#relation) to know more. Infraon also covers problem ownership, monitoring, tracking, and communication throughout each problem's life cycle. Problems are managed through the "Problem" module. Technicians or users with the required permissions, referred to as requesters, can raise problems. Problems follow multiple state(s) and status(es) throughout their life cycle. {% hint style="info" %} The relationships here work in the same way as they do in the [Ticket](/infraon-help/infinity-user-guide/ticket-management.md), [Request](/infraon-help/infinity-user-guide/request-management/request.md), [Change](/infraon-help/infinity-user-guide/change-management/change.md), and [Release ](/infraon-help/infinity-user-guide/release-management.md)modules, ensuring consistency across the system. {% endhint %} #### State and Status | **State** | **Status** | **Status Scenario** | | ----------- | -------------------- | ------------------------------------------------------------------------------------------------------------------- | | Open | New | When a new problem is logged in the system. The status of the associated tickets is put "On-Hold." | | Open | Waiting for Assignee | When a problem is newly created, it is next waiting to be assigned to a technician. | | In Progress | Investigation | When the Root-Cause Analysis of the problem is in progress. | | In Progress | Diagnosis | When the problem analysis is in progress and misses the "Due By" date. Then it is escalated to the next technician. | | On-Hold | Waiting for Customer | The status can only be ‘Pending’ when the problem is kept on hold either for Customer input. | | On-Hold | Pending Changes | If any changes are pending to be implemented. | | Resolved | Resolution Applied | When a resolution(permanent fix) is applied to the problem. The users are notified. | | Resolved | Solved | When the users are satisfied with the resolution provided by the technicians. | > Customized Status(es) can be configured from the 'Workflow' module to suit the requirement. Easily convert resolved Problems to Knowledge Base articles. KB icon appears post-resolution, ensuring efficient knowledge management. **Demo data for ITSM module Problem KB for new Org** Knowledge Base Modules! Explore added knowledge articles to understand the functionality and purpose of KB modules. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.infraon.io/infraon-help/infinity-user-guide/problem-management.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.