Problem Management is a process defined in the ITIL framework. The main goal of this process is to prevent Incidents from happening, and to minimize the impact of incidents that cannot be prevented.
Proactive problem management is an ongoing process that is focused on service improvement. It is all about identifying and solving problems and known errors before incidents occur, i.e. by looking at the environment, identifying potential problems, and then fixing those problems proactively before they impact any services.
Reactive problem management deals with resolving the underlying root cause of incidents and in response to events that occur.
What is a problem?
The underlying root cause of one or more incidents. Known errors are also problems and can be created proactively to share information/awareness.
What is not a problem?
A service request
...and so on...
Examples of proactive problem management
Analyzing log files
Trend analysis of used resources
...and so on...
What is the difference between incidents and problems?
Incidents are symptoms of problems
Incidents are the underlying error that cause incidents
Incidents does not become problems
Incidents and problems are managed as different issue/ticket types that are linked together
It is common that many incident issues/tickets are linked to one common problem issue/ticket.
How can problem management be managed in VisionFlow?
It is recommended that you create a separate issue/ticket type called Problem. By doing this you can create a report/filter to see all open "Known Errors" (KEDB) to easily share this information internally between different teams.
When a solution to a problem has been identified, a separate "Change" issue should be created to implement the solution. In a similar fashion to how problems are created from incidents, it is recommended that you create a Change as a separate issue with an "active link" to the problem. It is easiest to do this with an "action button" so it is quick and easy. It is recommended that the "action button" changes status on problem to "Pending change" or similar, i.e. they are still open and waiting for the change to be implemented. When the change has been implemented the status on the problem issue can be changed automatically via the active link to "Completed" so that it is clear to the Problem Manager or the Service Desk that it has been resolved and customers/end-users should be informed. If you have create an active link from the Problem to the Incident issue then this can be updated automatically also.
Customers/end-users can be informed automatically when their issues are resolved (by completing the Problem) if you use "active links" and notifications configured to send out emails about this. Alternatively, you can inform customers/end-users manually when incidents receives a "signal" that the problem is set to completed, for example by setting a status on such as "Problem resolved".
You can then add relevant fields to this type of issue. For example:
- Root cause: you can add separate text are fields for "Root cause" and "Workaround" if such exists, more info is available here about how to this.
- Severity (Impact)
- Priority: If you like you can create a matrix for Urgency/Severity so that Priority is set automatically based upon those
- Services(s) ("affected service"): Use standard field for Service and/or Component, but you can also add a custom field of type CI
- Affected/realated CI's: Use standard field for Service and/or Component, but you can also add a custom field of type CI if any of the previous are already used
- Category: Add a custom field of type CI for this
- Affected users / business areas: Reporter company (or company) will indicate the customer company (or department) affected, but you can also create custom fields for this if you like