Identify
From an incident or a trend alert, a problem is created and the related incidents are attached to it.
Modules · Problem management
Treat the cause, not only the symptom.
Problem management goes back to the origin of recurring incidents, documents the cause and the workaround, and makes them available to the support teams.
Benefits
- Fewer recurring incidentsRecurring incidents are grouped under a problem whose root cause is analysed, then corrected.
- A workaround everyone knowsA known error publishes an article, and an incident’s record suggests the closest known errors.
- Trends spotted in timeA symptom that repeats beyond a threshold raises an alert before the impact grows.
- A managed resolutionThe fix goes through a change; closure is suggested once it succeeds, and the check stays human.
How it works
Analyse
The 5 whys and the Ishikawa diagram structure the search for the root cause.
Work around
The cause and the workaround are written up; the known error is published in the knowledge base.
Fix
A change resolves the problem; the post-closure review keeps the lessons learned.
Related modules
- Service Desk Incidents are attached to the problem from its record or from the ticket, several at once; beyond a threshold (five incidents in seven days by default, by category or by item), an alert suggests opening the problem.
- Change management The corrective change is created from the problem, with the root cause; when it succeeds, the record offers to resolve the problem.
- Major incidents The post-incident review creates the major problem, with the ticket attached and the cause already written up; a crisis cannot be closed without a review.
- CMDB Trend detection groups incidents by repository item: a device that keeps coming back flags itself.
Functional scope
- Two modesReactive, from incidents (a single significant incident is enough); proactive, from a trend.
- Life cycleIdentified, investigation, known error, change planned, resolved, closed; a root cause is required for a known error or a resolution.
- Root cause analysisThe 5 whys and the Ishikawa diagram in six families, as an input structure.
- Attached incidentsSearch for and attach several incidents at once; the link is visible from both sides.
- Known error databaseAn article published with symptom, root cause and workaround, updated in one click, archived if the error is disproved.
- Trend detectionAn adjustable threshold of incidents over a period, an alert to problem managers and a graphical trend view.
- Management reportingOpen problems, recurrence, known errors without a workaround, resolution time, impact × frequency matrix and a Kanban board.
- Post-closure reviewMandatory for a major problem: deviations noted and lessons learned.
Integrations
- Service Desk, to attach incidents
- Change management, for the fix
- Knowledge base, to publish known errors
- E-mail notifications, with editable templates
- AI assistance to suggest the cause and draft the workaround, when the AI module is configured
Prerequisites
- The problem managers, to be designated
- A knowledge base for known errors, preferably internal
The essentials of this page in PDF, to keep or pass on.
Download the sheetWant to see this module on your own processes?
We will build the demonstration around your operational reality.