NexTool Solutions

Störungen, die sich wiederholen, sind Symptom eines Problems, welches noch niemand erfasst hat. Ob man in GLPI bemerkt, dass zehn WLAN-Tickets innerhalb von zwei Wochen am selben Standort aufgelaufen sind oder dass dasselbe Gerät zum vierten Mal in der Warteschlange landet, hängt davon ab, ob jemand zur richtigen Zeit auf den richtigen Bericht schaut. Problem Flow übernimmt diese Auswertung selbst und erstellt ein ITIL-Problem automatisch, sobald sich ein Muster bestätigt.

Ausgangslage: Die Brücke zwischen Störung und Problem ist manuell

Wer ITIL betreibt, weiß: Probleme sind die Grundursache hinter wiederholten Störungen. GLPI kennt den Itemtype Problem und erlaubt es, Störungen damit zu verknüpfen, erkennt aber keine Wiederholung: Dieser Teil bleibt menschlich. Jemand muss bemerken, dass mehrere Tickets dieselbe Kategorie, denselben Standort oder dasselbe Gerät im selben Zeitraum haben – und erst dann ein Problem erstellen und die Störungen verknüpfen.

Diese Lücke kostet. Die Zeit zwischen dem Auftreten eines Musters und der Erstellung eines Problems füllt sich mit weiteren Störungen, mehr Nacharbeit und mehr Last in der Warteschlange. In Umgebungen mit hohem Volumen bleibt ein Muster meist unbemerkt, bis die Auswirkungen bereits groß sind – und dann stellt die Leitung immer dieselbe Frage: „Warum hat niemand dies früher gesehen?“

So funktioniert Problem Flow

Problem Flow wertet bereits gelöste und geschlossene Tickets aus und erkennt wiederkehrende Störungen mit Regeln nach GLPI-Muster: Kategorie, Standort, zugeordnetes Element, Lösungstyp, Priorität, Quelle, Gruppen, Anforderer sowie Text im Titel, in der Beschreibung oder in der Lösung. Wird die Mindestzahl an Tickets einer Regel im Zeitraum erreicht, wird in GLPI ein ITIL-Problem erstellt, mit den auslösenden Tickets bereits verknüpft.

• Doppelte Auslöser – die Auswertung läuft jedes Mal, wenn ein Ticket gelöst oder geschlossen wird, und zusätzlich über die automatische Aktion von GLPI, standardmäßig alle 6 Stunden; so ist die Abdeckung auch bei Lastspitzen gesichert.
• Regeln nach GLPI-Muster – jede Regel legt die Kriterien fest, mit denselben Operatoren wie die nativen Regeln (einschließlich „unter“ für Unterkategorien und untergeordnete Standorte), die Mindestzahl an Tickets im Zeitraum, die Gruppierung (Element, Standort, Kategorie, Technikergruppe, Anforderer oder Abteilung), die Mindestzahl verschiedener Anforderer, den Mindestabstand zwischen Problemen und wie ein Problem entsteht (Titel, Vorlage, Kategorie, Dringlichkeit, Auswirkung, Technikergruppe, Techniker, Beobachtergruppe). Mehrere Regeln können parallel bestehen, um unterschiedliche Szenarien abzudecken.
• Ein Problem pro gemeinsamer Ursache – bei Gruppierung nach Standort und einem Minimum von 5 erzeugen fünf WLAN-Störungen am Standort Zentrum und fünf am Standort Nord zwei Probleme, eines pro Standort. Die Mindestzahl verschiedener Anforderer verhindert, dass eine einzelne Person den Alarm auslöst, und der Mindestabstand verhindert doppelte Probleme.
• 27 fertige, inaktive Vorlagen – Gerät mit wiederholten Ausfällen; WLAN, Druck, Strom und Telefonie am selben Standort; E-Mail, VPN, Login, Backup, Sicherheit und digitales Zertifikat; dieselbe Kategorie; wiederkehrende Workarounds; und jede kritische Störung. Sie werden deaktiviert ausgeliefert: Sie aktivieren nur, was in Ihrer Umgebung sinnvoll ist.
• Wiederkehrende Workarounds – eine der Vorlagen liest den Lösungstext der Tickets: Wiederholt sich derselbe Workaround, wird daraus ein Problem, der „Kandidat für einen bekannten Fehler“ nach ITIL.
• Schaltfläche „Testen“ – simuliert die Regel auf den Tickets des Zeitraums, ohne etwas zu erstellen: Sie zeigt jede Gruppe, wie viele Tickets und Anforderer sie im Vergleich zum Minimum gezählt hat, und eine Vorschau auf ein Problem, welches erstellt würde.
• ITIL-konformer Umfang – die 27 fertigen Vorlagen zählen nur Störungen, wie ITIL es empfiehlt; in einer eigenen Regel ist der Tickettyp ein Kriterium, welches Sie wählen.
• Vollständige Nachvollziehbarkeit – der Reiter Logs protokolliert für jede Erkennung die Regel, ein erzeugtes Problem, die Gruppe und die auslösenden Tickets.

Welches Muster Problem Flow automatisiert

Um zu verstehen, was Problem Flow tut, lohnt sich ein Blick auf die manuelle Erkennung. Die folgende Abfrage listet nach Kategorie und Einheit die in den letzten 30 Tagen gelösten oder geschlossenen Störungen auf und hebt Gruppen mit fünf oder mehr Vorkommen hervor – genau die Kandidaten für ein Problem. Führen Sie sie auf einem Lese-Replikat oder in einem Zeitfenster mit geringer Nutzung aus:

-- Deteccao MANUAL do padrao que o Problem Flow automatiza:
-- incidentes resolvidos/fechados nos ultimos 30 dias, agrupados por categoria e entidade.
-- Grupos com 5+ ocorrencias sao candidatos a virar um Problema ITIL.
SELECT c.completename          AS categoria,
       e.completename          AS entidade,
       COUNT(*)                AS ocorrencias
FROM glpi_tickets t
JOIN glpi_itilcategories c     ON c.id = t.itilcategories_id
JOIN glpi_entities e           ON e.id = t.entities_id
WHERE t.type = 1                       -- 1 = Incidente
  AND t.status IN (5, 6)               -- 5 = Solucionado, 6 = Fechado
  AND t.is_deleted = 0
  AND t.solvedate >= NOW() - INTERVAL 30 DAY
GROUP BY t.itilcategories_id, t.entities_id
HAVING COUNT(*) >= 5
ORDER BY ocorrencias DESC;

Problem Flow erledigt diese Arbeit selbst, bei jeder Auswertung und für jede Regel, und nicht nur nach Kategorie und Einheit: Jede Kombination von Kriterien ist möglich (Standort, zugeordnetes Element, Anforderer, Lösungstext und die übrigen), mit getrennter Zählung nach der von Ihnen gewählten Gruppierung und ohne darauf angewiesen zu sein, dass jemand an den Bericht denkt.

Funktion von Problem Flow vs. natives Verhalten

So aktivieren Sie es

1. Öffnen Sie bei installiertem NexTool-Plugin in GLPI 11 NexTool > Module und aktivieren Sie Problem Flow.
2. Wählen Sie im Reiter Regeln eine der 27 fertigen Vorlagen (sie werden inaktiv ausgeliefert) oder erstellen Sie eine eigene Regel.
3. Klicken Sie auf Testen: Die Simulation läuft auf den Tickets des Zeitraums und erstellt nichts.
4. Ist ein Ergebnis kalibriert, aktivieren Sie die Regel.
5. Verfolgen Sie im Reiter Logs, welche Regel jedes Problem erstellt hat, für welche Gruppe und mit welchen Tickets.

Was wir im Betrieb gelernt haben

Im Betrieb von ITIL-Umgebungen steht und fällt Problem Flow mit der Kalibrierung der Mindestzahl an Tickets, nicht mit der Technik. Ist ein Minimum zu niedrig, erzeugt Problem Flow ein Problem pro Kategorie und Woche – Rauschen, um welches sich niemand kümmert; ist es zu hoch, löst es nie aus, und Sie sind zurück bei der manuellen Erkennung. Wir haben standardisiert, konservativ zu beginnen und vor der Aktivierung die Schaltfläche „Testen“ zu nutzen: Die Simulation zeigt auf Ihren eigenen Tickets jede Gruppe, welche die Regel bilden würde, wie viele Tickets und Anforderer im Vergleich zum Minimum gezählt wurden, und eine Vorschau auf ein Problem. Die Feinabstimmung geschieht dort, ohne etwas zu erstellen, statt wochenlang auf Logs zu warten. Zwei Details zeigen sich erst im Betrieb: Erstens bläht ein Zählen noch offener Tickets die Zahl auf, weil dieselbe wiedereröffnete Störung mehrfach erscheint – deshalb ist eine Analyse gelöster und geschlossener Tickets korrekt. Zweitens war der häufigste Fehler in der Praxis, die Regel auf eine übergeordnete Kategorie zu richten in der Erwartung, dass die untergeordneten mitgezählt werden, und dann zu sehen, dass sich Störungen in benachbarten Unterkategorien nicht gruppieren. In den aktuellen Regeln löst man dies über den Operator: Verwenden Sie „unter“, um Unterkategorien einzuschließen; mit „ist“ zählt nur die gewählte Kategorie. Gleiches gilt für Standorte.

Für wen es geeignet ist (und wann nicht)

Problem Flow eignet sich für Organisationen, die ITIL formal einsetzen und die Lücke zwischen Störungsmanagement und Problemmanagement schließen wollen, insbesondere:

• Umgebungen mit hohem Volumen, in denen eine manuelle Mustererkennung nicht praktikabel ist;
• Organisationen mit mehreren Einheiten, Standorten oder verteilten Teams;
• Führungskräfte, die für Audits einen nachvollziehbaren Nachweis der ITSM-Reife benötigen.

Nicht sinnvoll ist es in Organisationen, die noch kein Problemmanagement betreiben oder ein sehr geringes Volumen haben: Ein Minimum wird selten erreicht, und Problem Flow bleibt untätig. Schlecht kalibriert erzeugt es zudem übermäßig viele Probleme, die ein Team nicht bewältigen kann – Nebenwirkung ist eine Warteschlange verwaister Probleme, schlimmer als gar keine Automatisierung. Erst kalibrieren (dafür gibt es die Schaltfläche „Testen“), dann vertrauen.

Kompatibilität

• GLPI: 11
• Plan: lizenziertes Modul
• Plugin: NexTool 6.24.1 oder höher (die aktuelle öffentliche Version erfüllt dies)

Problem Flow ist Teil von NexTool, einem modularen Plugin für GLPI. Um ITIL-Problemmanagement mit automatischer, nachvollziehbarer Erkennung einzuführen, sprechen Sie mit unserem Team.

Geprüft vom Team der NexTool Solutions.