NexTool Solutions

Problemmanagement trennt einen Betrieb, der jede Woche denselben Brand löscht, von einem, der ihn endgültig beseitigt. Beim Betrieb von GLPI-Umgebungen unserer Kunden ist das häufigste Muster kein fehlender Prozess, sondern das Problem, das erstellt, umgangen und noch am selben Tag als Gelöst markiert wird - womit der Zyklus geschlossen wird, bevor die Grundursache dokumentiert ist. Dieser Leitfaden zeigt, wo jede Information des Problems im GLPI liegt, wie Sie klassifizieren, ohne ein Feld zu erfinden, das es nicht gibt, und welche Fallstricke dazu führen, dass die Untersuchung im Sande verläuft.

Störung vs. Problem: Der Unterschied liegt in den Daten, nicht nur im Sprachgebrauch

Das klassische Missverständnis im ITSM ist die Annahme, dass „die Störung zum Problem wird“. Im GLPI teilen sie sich nicht einmal dieselbe Tabelle: Die Störung liegt in glpi_tickets, das Problem in glpi_problems, jeweils mit eigener Zustandsmaschine. Es sind unterschiedliche Objekte mit entgegengesetzten Zielen:

• Störung: den Service so schnell wie möglich wiederherstellen. Sie ist kurativ und hat ein Lösungs-SLA.
• Problem: die Grundursache finden und beseitigen, damit die Störung nicht wiederkehrt. Es ist präventiv und folgt einem anderen Rhythmus.

Ein Beispiel aus der Praxis: Der E-Mail-Server fällt jeden Montag aus. Jeder Ausfall ist eine Störung, die durch einen Neustart des Dienstes gelöst wird. Die Untersuchung, die herausfindet, dass das wöchentliche Backup den Arbeitsspeicher erschöpft und den Dienst zum Absturz bringt, ist das Problem. Wer die Störungen schließt, ohne das Problem zu erstellen, garantiert, dass der nächste Montag dasselbe Ticket bringt.

Der Abschnitt Analyse: wo die Grundursache wirklich liegt

Was das Problemformular von einem gewöhnlichen Ticket unterscheidet, ist der Abschnitt Analyse, der in drei eigene Textspalten von glpi_problems schreibt (bereitgestellt in den Suchoptionen 60, 61 und 62):

• impactcontent - Auswirkungen: was das Problem betrifft, solange es nicht gelöst ist.
• causecontent - Ursachen: Hier liegt die Grundursache. Es ist das wichtigste Feld des gesamten Prozesses.
• symptomcontent - Symptome: wie sich das Problem für diejenigen äußert, die Störungen melden.

Der häufigste Fallstrick, den wir in der Praxis antreffen: Der Abschnitt Analyse ist im Formular eingeklappt. Der Techniker füllt Titel und Beschreibung aus, dokumentiert den Workaround in der Timeline und öffnet den Abschnitt nie - daher bleibt causecontent leer. Ergebnis: Sechs Monate später weiß niemand, warum dieses Problem erstellt wurde und was herausgefunden wurde. Eine Grundursache, die nicht in causecontent landet, wird nicht zu Wissen in der Wissensdatenbank, sondern zu einem Gerücht.

Störung, Problem oder Änderung: Entscheidungsmatrix

Bevor ein Datensatz erstellt wird, muss das Team wissen, was es da erstellt. Diese Matrix verwenden wir bei der Triage:

Beachten Sie, dass Problem und Änderung nicht konkurrieren: Der ausgereifte Ablauf ist Problem (findet die Ursache) - Änderung (setzt die Korrektur um) - Wissensdatenbank (dokumentiert), alles miteinander verkettet.

Störungen verknüpfen: der Reiter Tickets und der Verknüpfungstyp

Substanz bekommt ein Problem durch die damit verknüpften Störungen. Im Problemformular ordnet der Reiter Tickets die zugehörigen Tickets zu und schreibt in die Tabelle glpi_problems_tickets. Das Detail, das fast alle ignorieren: Die Verknüpfung hat einen Typ. Eine Verknüpfung als „Verknüpft mit“ unterscheidet sich von einer als „Duplikat“, und das verändert die Auswertung der Wiederholungsberichte. Standardisieren Sie den Verknüpfungstyp im Team, sonst wird die Anzahl der Störungen pro Problem bedeutungslos - das war eine der ersten Anpassungen, die wir in Umgebungen vorgenommen haben, die wir ohne Governance übernommen haben.

Der Lebenszyklus und die Falle des zu frühen „Gelöst“

Das Problem hat eine eigene Zustandsmaschine in der Spalte status von glpi_problems, und sie ist nicht identisch mit der einer Änderung. Die Status, die ein Problem tatsächlich verwendet, sind:

1. Neu (1) - erfasst, noch ohne Untersuchung.
2. Angenommen (7) - triagiert und vom Team übernommen.
3. In Bearbeitung / zugewiesen (2) und geplant (3) - Untersuchung läuft.
4. Wartend (4) - wartet auf Dritte, Lieferanten oder ein Wartungsfenster.
5. In Beobachtung (8) - Workaround angewendet, es wird beobachtet, ob die Ursache tatsächlich beseitigt wurde.
6. Gelöst (5) und Geschlossen (6) - Ursache beseitigt und Zyklus abgeschlossen.

Hier liegt der häufige Fehler, der am teuersten wird: den Workaround anwenden und das Problem noch am selben Tag als Gelöst markieren. Gelöst bedeutet „die Grundursache ist beseitigt“, aber ein Workaround beseitigt keine Ursache - er verdeckt nur das Symptom. Im Betrieb verwenden wir den Status In Beobachtung (8) genau dafür: Der Workaround steht, das Problem bleibt im Dashboard sichtbar, und erst nachdem die endgültige Korrektur umgesetzt ist und eine Zeit ohne Wiederauftreten vergangen ist, setzen wir es auf Gelöst. Zu früh zu schließen ist, als würde man den Sieg erklären, während es hinter der Wand noch qualmt.

Workaround, endgültige Lösung und die Brücke zur Änderung

Ein Problem hat zwei Ergebnisse, die nicht verwechselt werden dürfen:

• Workaround: stellt den Service wieder her, ohne die Ursache anzurühren. Dokumentieren Sie ihn in der Timeline oder als Aufgabe des Problems (glpi_problemtasks) zur sofortigen Nutzung durch das First-Line-Team.
• Endgültige Lösung: beseitigt die Grundursache. Sie wird im Reiter Lösung erfasst, schreibt in glpi_itilsolutions (mit itemtype = 'Problem') und erfordert für die Umsetzung häufig eine Änderung.

Wenn die Korrektur die Infrastruktur betrifft, erstellen Sie die Änderung direkt aus dem Problem heraus: Die Verknüpfung wird in glpi_changes_problems gespeichert und erhält die Nachvollziehbarkeit Grundursache - Korrekturmaßnahme. Genau diese Linie ermöglicht es später nachzuweisen, dass das Problem tatsächlich gelöst und nicht nur geschlossen wurde.

Vorlage für die Benachrichtigung zum Abschluss eines Problems

Unter Einstellungen > Benachrichtigungen verwendet die Vorlage für das Problem-Ereignis die Tags des GLPI. Ein Abschlusstext, der die Erfassung der Grundursache erzwingt, reduziert geschlossene Probleme ohne Lessons Learned:

Assunto: [Problema ##problem.id##] Encerrado - ##problem.title##

Olá,

O problema abaixo foi encerrado.

Título:      ##problem.title##
Categoria:   ##problem.category##
Status:      ##problem.status##
Incidentes:  ##problem.numberoftickets##

Sintomas:
##problem.symptoms##

Causa raiz:
##problem.causes##

Detalhes: ##problem.url##

Die Tags ##problem.causes## und ##problem.symptoms## lesen direkt aus causecontent und symptomcontent. Wenn die Abschlussbenachrichtigung mit leeren Blöcken ankommt, ist das ein klares Zeichen, dass das Problem ohne dokumentierte Grundursache geschlossen wurde - und die E-Mail selbst wird zum Prüfer des Prozesses.

Diagnose: Probleme mit vielen Störungen und zu wenig Ursache

Im Betrieb führen wir regelmäßig ein SELECT aus, das das Wichtigste verknüpft: noch offene Probleme mit vielen verknüpften Störungen, aber ohne ausgefüllte Grundursache. Das ist die Warteschlange der drohenden Nacharbeit:

SELECT p.id,
       p.name AS problema,
       p.status,
       COUNT(pt.tickets_id) AS incidentes,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'SEM CAUSA RAIZ', 'ok') AS causa
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- exclui Resolvido e Fechado
GROUP BY p.id
HAVING causa = 'SEM CAUSA RAIZ'
    OR incidentes >= 3
ORDER BY incidentes DESC;

Jede Zeile mit SEM CAUSA RAIZ und mehreren Störungen ist ein Problem, das Aufwand für Workarounds verbraucht, ohne der Lösung näherzukommen. Wenn Sie diese Abfrage in ein wöchentliches Dashboard verwandeln, ändert sich das Gespräch in der Betriebsbesprechung: Statt „wie viele Tickets haben wir geschlossen“ heißt es dann „welche Ursachen haben wir beseitigt“.

Bewährte Vorgehensweisen im Betrieb

• Warten Sie nicht auf Dutzende Störungen: 3 Vorkommen mit demselben Symptom rechtfertigen bereits ein Problem.
• Füllen Sie causecontent vor dem Abschluss aus, auch wenn die Ursache offensichtlich erscheint; daraus entsteht die Wissensdatenbank.
• Verwenden Sie In Beobachtung, solange der Workaround läuft; markieren Sie Gelöst erst, wenn die Ursache beseitigt ist.
• Standardisieren Sie den Verknüpfungstyp der Störungen, damit die Wiederholungszählung etwas aussagt.
• Verknüpfen Sie das Problem mit der Änderung (glpi_changes_problems), wann immer die Korrektur die Infrastruktur betrifft.
• Überprüfen Sie offene Probleme wöchentlich; ein vergessenes Problem ist eine garantierte Störung in der Zukunft.

Wenn der Betrieb wiederkehrende Probleme automatisch erkennen soll - statt darauf angewiesen zu sein, dass jemand das Muster bemerkt -, identifiziert das Modul Problem Flow wiederholte Störungen nach Kategorie und Häufigkeit und erstellt das Problem gleich mit den verknüpften Tickets. Der NexTool-Betriebssupport richtet diesen Ablauf auf dem GLPI ein, das Sie bereits nutzen, vom Erkennungsauslöser bis zum Dashboard der beseitigten Ursachen.

Geprüft vom Team von NexTool Solutions.