NexTool Solutions

IT-Prozesse passen selten in einen einzigen Schritt. Diagnose führt zur Umsetzung, Umsetzung führt zur Validierung, und jeder Schritt ergibt erst nach dem Ergebnis des vorherigen Sinn. Im Standard-GLPI entsteht jede dieser Aufgaben durch manuelle Eingabe des Technikers, was eine Standardisierung unmöglich macht, sobald das Volumen wächst. Ein Modul namens SubTask Flow verkettet diese Schritte: Wenn der Techniker die Lösung einer Aufgabe in der Timeline erfasst, wird die nächste automatisch anhand dieser Antwort erstellt.

Warum es nicht skaliert, die nächste Aufgabe von Hand anzulegen

Viele Bearbeitungsabläufe sind vorhersehbar: analysieren, umsetzen, validieren, kommunizieren. GLPI bietet Aufgabenvorlagen (TaskTemplates), um den Inhalt jedes Schritts zu standardisieren, weiß aber nicht, dass ein Schritt den nächsten auslösen soll. Ergebnis ist bekannt: Ein Techniker öffnet die richtige Vorlage, kopiert Verantwortlichen und Frist und legt die folgende Aufgabe von Hand an. In einer Umgebung mit Dutzenden Technikern führt dies zu drei chronischen Problemen: vergessene Schritte, abweichende Daten zwischen gleichartigen Tickets und keinerlei Nachvollziehbarkeit, "warum diese Aufgabe existiert". Fragt ein Audit, ob die Validierung erfolgt ist, hängt die Antwort von der individuellen Disziplin jedes Technikers ab, nicht von einem entworfenen Prozess.

Wie SubTask Flow Aufgaben anhand der Lösung verkettet

Ein Modul erstellt hierarchische Beziehungen zwischen TaskTemplates. Eine übergeordnete Vorlage verweist auf eine oder mehrere untergeordnete Vorlagen, und jede untergeordnete kann an eine bestimmte Lösung gebunden werden. Wenn der Techniker die Lösung in der Timeline der übergeordneten Aufgabe erfasst (oder, wenn die Vorlage keine Bedingung hat, die Aufgabe als "Erledigt" markiert), führt ein Modul drei Schritte aus:

1. Es ermittelt die untergeordneten Vorlagen, die mit dieser Lösung verknüpft sind;
2. Es erstellt die untergeordneten TicketTasks in der Timeline desselben Tickets;
3. Es kopiert Inhalt, Kategorie, Dauer und Verantwortlichen (Techniker und Gruppe), die in der untergeordneten Vorlage festgelegt sind.

Die Konfiguration liegt in der Vorlage, nicht im Ticket. Sie passen einen Ablauf einmal an, und er gilt für alle Tickets, die diese Vorlage verwenden, ohne Geschäftsregeln oder externe Automatisierungen anzufassen. Dies ist der Unterschied zwischen einem dokumentierten Prozess und einem, den ein System tatsächlich ausführt.

Konfiguration Schritt für Schritt

1. Standardisieren Sie die Liste der Lösungen in der Modulkonfiguration (zum Beispiel: "hardware", "software", "sem defeito"). Behandeln Sie sie als geschlossenes Vokabular, nicht als Freitext.
2. Öffnen Sie die übergeordnete TaskTemplate und verknüpfen Sie die untergeordneten Vorlagen im Reiter für die Verkettung.
3. Legen Sie für jede untergeordnete Vorlage fest, welche Lösung sie auslöst. Eine bedingte untergeordnete Vorlage setzt voraus, dass die übergeordnete Vorlage den Standardstatus "Information" hat.
4. Stellen Sie sicher, dass bei jeder untergeordneten Vorlage Gruppe oder Techniker als Verantwortliche sowie die Dauer ausgefüllt sind - dieses Feld verursacht später den meisten Ärger.
5. Testen Sie in einem Abnahme-Ticket, bevor Sie in Produktion freigeben: Erstellen Sie für jede mögliche Lösung eine übergeordnete Testaufgabe, erfassen Sie die Lösung in der Timeline und prüfen Sie, dass die richtige Unteraufgabe mit den korrekten Daten entsteht.

Zykluserkennung

Verkettung ohne Sperre wird zur Falle. Eine Vorlage A, die B erzeugt, welche C erzeugt, welche wieder zu A führt, würde bei jedem Durchlauf dieselben Aufgaben neu anlegen, und der Ablauf würde nie enden. Beim Speichern einer neuen Verknüpfung führt ein Modul eine Tiefensuche (DFS) über den Graphen der Vorlagen aus. Findet es einen Zyklus, zeigt es eine Warnung mit dem Pfad der Schleife an, doch die Verknüpfung bleibt gespeichert: Es ist Aufgabe der konfigurierenden Person, sie zu entfernen. Nur die Verknüpfung einer Vorlage mit sich selbst wird blockiert. Deshalb gilt die Disziplin jeder Automatisierung: Kurze und lesbare Ketten erleichtern die Diagnose, wenn etwas vom Erwarteten abweicht.

Nachvollziehbarkeit: der Reiter mit den Protokollen

Automatisierung ohne Protokoll ist eine Blackbox. SubTask Flow führt eine Historie der Ausführungen mit Ticket, übergeordneter Aufgabe, erzeugter Unteraufgabe, wer ausgelöst hat, wer abgeschlossen hat, und Zeitstempeln. In einem Audit beantwortet dies die häufigste Frage - "wurde diese Unteraufgabe von jemandem oder vom Ablauf erstellt, und ausgehend von welcher Aufgabe?" - ohne vom Gedächtnis irgendeiner Person abzuhängen. Es ist auch die erste Anlaufstelle, wenn ein Kunde meldet, "der Schritt ist verschwunden": Ein Protokoll zeigt, ob der Auslöser gefeuert hat und ausgehend von welcher Aufgabe.

Diagnose: den Ablauf per SQL prüfen

Stille Automatisierung erfordert aktive Überwachung. Die folgende Abfrage listet noch offene Unteraufgaben, die ohne festgelegten Verantwortlichen entstanden sind, das klassische Symptom einer unvollständigen untergeordneten Vorlage. Führen Sie sie auf einem Lese-Replikat oder in einem Zeitfenster mit geringer Last aus:

-- Subtarefas em aberto (state=1) sem tecnico nem grupo responsavel.
-- Sinaliza TaskTemplate filho sem users_id_tech/groups_id_tech preenchido.
SELECT t.id                       AS chamado,
       tt.id                      AS task_id,
       tmpl.name                  AS modelo,
       tt.state,
       tt.users_id_tech,
       tt.groups_id_tech,
       tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t               ON t.id  = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
  AND tt.users_id_tech  = 0
  AND tt.groups_id_tech = 0
  AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;

In GLPI bedeutet state = 1 "Zu erledigen" und state = 2 "Erledigt". Wächst diese Liste jede Woche, liegt es nicht am Modul: Es ist eine ohne Verantwortlichen veröffentlichte untergeordnete Vorlage, die Aufgaben erzeugt, die niemand in der Warteschlange sieht.

Wann einsetzen (und wann nicht)

Der häufigste Fehler in der Praxis

Im Betrieb von Umgebungen mit vielen Technikern ist das häufigste Problem kein technisches, sondern eines der Modellierung. Jemand konfiguriert eine untergeordnete Vorlage so, dass sie bei der Lösung "Hardware" auslöst, doch die Option, die der Techniker auf dem Bildschirm tatsächlich auswählt, ist "hardware" in Kleinbuchstaben - oder "HW" in einer Umgebung, die ihr Vokabular von einem anderen Tool geerbt hat. Der Auslöser greift nicht, die Unteraufgabe entsteht nicht, niemand erhält einen Fehler, und der Umsetzungsschritt verschwindet einfach aus dem Prozess, ohne sichtbare Spur. Die Korrektur, die wir standardisiert haben: Lösungsbezeichnungen als kontrolliertes Vokabular behandeln, alle in Kleinbuchstaben, in einer einzigen Zuordnungstabelle dokumentiert, und die untergeordneten Vorlagen jedes Mal prüfen, wenn jemand eine neue Lösung hinzufügt. Der zweite wiederkehrende Fehler ist eine untergeordnete Vorlage ohne Verantwortlichen: Die Aufgabe entsteht verwaist, geht mitten in der Timeline unter und taucht erst wieder auf, wenn die SLA bereits gerissen ist. Deshalb gehört die obige SQL-Abfrage in die Checkliste des Betriebs, nicht in ein einmaliges Audit.

NexTool implementiert und betreibt GLPI-Umgebungen mit Automatisierungen wie SubTask Flow, die für den realen Betrieb jedes Kunden entworfen sind. Sprechen Sie mit unserem Team, um den Aufgabenablauf Ihres Teams abzubilden und zu automatisieren.

Geprüft vom Team der NexTool Solutions.