Managing a problem

A problem is the cause, still unknown or not yet fixed, of one or more incidents. Problem management in Portail ZAPP is used to find it, document it, give agents a workaround in the meantime, then have it fixed by a change. The screens are open to Service Desk agents, Problem Managers, administrators and, to view, create and link a problem, Major incident managers.

The problem list

The Problem list menu entry opens the Problems page: number, title, status, mode, impact, frequency and identification date. A badge flags Major problems and Known errors. Filter by text (number or title), by Status or by Mode; the Open only box is ticked by default. The list stops at the 200 most recent problems: refine the search if a message says so.

Creating a problem

There are three ways to create a problem:

New problem, from the list;
Create a problem, from an incident ticket (open or resolved: a problem is often identified afterwards). The form says so ("Problem created from incident") and the ticket is linked to the problem when you save;
Create a proactive problem, from a trend alert (see below).

The form groups:

Identification: a Title (the symptom in one sentence) and a Description (symptoms, services and users affected, since when);
Cause and workaround: the Root cause and the Workaround, often empty at first;
Qualification: the Mode (Reactive, arising from incidents; Proactive, anticipated by trend analysis), Impact (1–5), Frequency (1–5) and the Major problem box;
Owner: the Problem owner.

Problem Managers are notified by email of every new problem.

Moving the problem forward

The status changes through the buttons on the problem page:

Status	What it means	Possible next steps
Identified	The problem is recorded	Start investigation, Cancel the problem
Investigation	The cause is being sought	Declare known error, linked change, Mark as resolved, cancellation
Known error	The cause is known, the fix is not done yet	linked change, Mark as resolved, Resume investigation
Change planned	A corrective change is linked	Mark as resolved, back to known error or investigation
Resolved	The fix is done	Close, Reopen if the incidents come back
Closed, Canceled	The case is finished	—

A few rules apply, whatever the screen:

the Root cause must be written before moving to Known error or Resolved; the page reminds you while it is empty;
Change planned is not chosen by hand: the problem moves to it when you link a change (see below);
a cancellation requires a reason (duplicate, false alarm…);
Close and Cancel the problem are reserved for Problem Managers and administrators;
for everything else, the problem can be moved forward by its author, its owner, Problem Managers and administrators.

When the problem is resolved, its author and its owner are notified by email.

Linking incidents

The Linked incidents card groups the tickets showing the same symptom. Find them by number or title under Link tickets, tick them, then click Link the selection. The link also appears on each ticket. A ticket you are not allowed to see is shown without its title ("ticket outside your scope").

From an incident ticket, Link to a problem lists the open problems and those the ticket is already linked to.

This card only exists when the Service Desk module is installed.

Analyzing the root cause

The Analyze button of the Root cause analysis card opens two tools:

5 whys: start from the symptom and ask "why?" at each answer, until you reach the cause to act on. No need to fill in all five lines if the cause appears earlier;
Ishikawa diagram: list the possible causes by family (Methods, Hardware and infrastructure, Software and data, People, Measurement and monitoring, Environment), one per line. Not every family is necessarily relevant.

The analysis does not fill in the root cause: once the cause is found, write it in the problem's Root cause field (Edit button).

Qualifying a major problem

When impact and frequency place the problem in the high zone of the matrix, the page proposes it as major; Qualify as major confirms it. A major problem requires a Post-closure review (Deviations observed, Lessons learned) before it can be closed: the review card opens when the problem is Resolved.

Known error and KEDB

When the cause is known but not yet fixed, Declare known error moves the problem to Known error and publishes an article in the KEDB, the known error database kept in the knowledge base: symptom, root cause, workaround and a link to the problem. Problem Managers, the author and the owner are notified of the first publication.

Update the article republishes the article after the cause or the workaround has changed;
if the KEDB is not configured, the page says so: an administrator must choose the knowledge base in the Problem settings. The known error is recorded anyway, and the article can be published later from the problem page.

On an incident ticket, the Known errors panel offers agents the KEDB articles close to the ticket, with their workaround.

Fixing through a change

The Corrective change card links the problem to the change that fixes its cause (Change management module):

Link an existing change: find it by number or title, then Link;
Create a change: a draft change is created, pre-filled with the title and the root cause, and you open it to complete it.

The problem then moves to Change planned. When that change is closed successfully, the Problem Manager and the owner are notified, and the page invites you to check that the incidents no longer recur before you Mark as resolved: a problem is never resolved automatically. If the change is abandoned, Remove the link (change abandoned) sends the problem back to known error or investigation.

These actions follow your rights on the Changes module. If that module is not installed, the card only shows the stored number.

Trends

The Trends page spots recurring symptoms: when the number of incidents for the same Category or the same CI exceeds the threshold over the period (5 incidents over 7 days by default, adjustable by an administrator), an alert appears under Alerts to handle and Problem Managers are notified.

Create a proactive problem opens a problem in Proactive mode from the alert;
Dismiss files the alert with no follow-up.

An alert can also close on its own: Covered when a problem already covers the symptom, Subsided when the incidents stop. Handled alerts remain visible under Handled alerts. The chart shows the incidents over 30 or 90 days. Without the Service Desk module, no trend is computed.

Dashboard and board

Problem dashboard: indicators for the period, impact × frequency prioritisation matrix (click a cell to list its problems), problems proposed as major, known errors without a workaround or not published;
Problem board: problems by status. Drag a card to a highlighted column to apply the transition, with the same rules as on the problem page. Moving to Change planned is done from the problem page, by linking the change. The board requires the Data grids module; without it, use the list.

The AI assistant

When an AI provider is configured, three buttons help the analysis:

Suggest the probable cause, next to the root cause, from the symptom and the linked incidents;
Assisted writing, next to the workaround;
Propose the 5 whys, on the analysis screen.

The proposal appears in a box ("Assistant proposal — review before applying"): Apply (or Replace the whys) copies it into the field, Dismiss closes it. Nothing is saved until you click Save.

When AI is disabled, these buttons do not appear; everything else in problem management works. The Known errors panel on tickets keeps suggesting articles, through a search on the words of the ticket.