01Before the impact grows
A trend flags itself.
Above a threshold, five incidents in seven days by default, by category or by CMDB item, an alert suggests opening a proactive problem. The chart shows the rolling period and the threshold crossed.
Modules · Problem management
Recurring incidents have a cause. Ecaldima helps you find it.
Problem management groups incidents that keep coming back, structures the search for the root cause and makes the workaround available to support while the fix is on its way.
- Trend alert above a threshold
- 5 whys and Ishikawa diagram
- Known errors suggested on tickets
02During the analysis
The root cause is found with method.
The 5 whys and the Ishikawa diagram with six families structure the search; a root cause is required before declaring a known error or resolving the problem.
03For support
The workaround reaches the ticket.
The known error publishes an article with the symptom, cause and workaround; an incident record suggests the closest known errors. The fix goes through a change, and its success suggests resolving the problem.
A crisis leaves its lessons.
The post-incident review of a major incident creates the major problem, with the ticket linked and the cause already written; a crisis cannot be closed without a review.
Verification stays human.
Closure is suggested when the corrective change succeeds, never imposed: the team confirms that the problem is resolved.
I’m blown away!
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 Every detail of the module
- 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.