NexTool Solutions

Eine gut gesteuerte Änderung in GLPI ist nicht diejenige mit den meisten ausgefüllten Feldern, sondern diejenige, die Sie um 2 Uhr nachts rückgängig machen können, wenn sie fehlschlägt. Dieser Leitfaden geht den vollständigen Lebenszyklus von Änderungen in GLPI durch: aus welchem Abschnitt und welcher Spalte jede Information stammt, wie Sie Änderungstypen modellieren, die natives GLPI nicht kennt, und welche Fallstricke wir bereits Wartungsfenster in Umgebungen haben sprengen sehen, die wir für Kunden betreuen.

Datenmodell hinter einer Änderung

Jede Änderung liegt in Tabelle glpi_changes. Neben den offensichtlichen Feldern (Name, Inhalt, Dringlichkeit, Auswirkung, Priorität) unterscheiden sich Änderungen von einem gewöhnlichen Ticket durch die Textspalten, die GLPI im Abschnitt Analyse und Pläne des Formulars anzeigt:

• impactcontent – Auswirkungsanalyse: Was bricht, wenn etwas schiefgeht.
• controlistcontent – Kontrollliste: Prüfpunkte.
• rolloutplancontent – Bereitstellungsplan (im Core als „Deployment plan“ bezeichnet): die Schritt-für-Schritt-Anleitung für ein Deployment.
• backoutplancontent – Rückfall-/Rollback-Plan (im Core als „Backup plan“ bezeichnet): wie man rückgängig macht.
• checklistcontent – Checkliste zur Validierung nach der Umsetzung.

Wer weiß, dass diese Informationen getrennte Spalten sind und kein loser Text in der Beschreibung, kann die Governance direkt in der Datenbank prüfen, wie wir weiter unten zeigen.

„Änderungstyp“ in GLPI: ein Feld, welches nicht existiert

Der häufigste Fehler von Umsteigern aus Tools wie ServiceNow ist die Suche nach einer Auswahl „Typ: Normal / Notfall / Standard“. Sie existiert in nativem GLPI nicht. Eine Änderung hat Kategorie (itilcategories_id), Dringlichkeit, Auswirkung und Priorität, aber kein ITIL-Typfeld. Sie modellieren die Klassifizierung über eigene ITIL-Kategorien, die zusätzlich Berichte und Geschäftsregeln speisen.

Lebenszyklus, Status für Status

GLPI führt eine Änderung durch einen eigenen Zustandsautomaten, umfangreicher als beim Ticket. Der aktuelle Zustand steht in Spalte status von glpi_changes:

1. Neu (1) – Erfassung unter Unterstützung > Änderungen, mit Beschreibung, Begründung, Auswirkung und Risiko.
2. Bewertung (4) – Analyse von Auswirkung und Risiko; Ausfüllen der Abschnitte Analyse und Pläne.
3. Genehmigung (11) – Genehmigungsrunde mit den Genehmigenden.
4. Akzeptiert (12), Test (13), Qualifizierung (14) – Planung und Ausführung der Aufgaben (glpi_changetasks), jede in der Zeitleiste erfasst.
5. Gelöst (5) – Überprüfung nach der Umsetzung; bestätigt den Erfolg und hält Lessons Learned fest.
6. Geschlossen (6) – abschließende Dokumentation und Abschluss.

Jede Änderungsaufgabe trägt actiontime (tatsächliche Zeit) und state (zu erledigen/erledigt), womit sich geplanter und tatsächlicher Aufwand vergleichen lassen – Daten, mit denen wir die Schätzungen für die nächsten Wartungsfenster kalibrieren.

Genehmigung: nativ vs. mehrstufig

Die native Genehmigung wird in glpi_changevalidations gespeichert (Status 2 = wartend, 3 = genehmigt, 4 = abgelehnt). Ein Detail, über welches fast jeder stolpert: Die Genehmigung in GLPI ist informativ, keine Schranke. Nichts hindert Sie daran, eine Änderung von Genehmigung auf Test zu setzen, während die Genehmigung noch aussteht; GLPI blockiert diesen Übergang nicht. Wenn Ihre Governance verlangt, dass niemand ohne erfasste Genehmigung umsetzt, reicht die native Genehmigung allein nicht aus. Hier kommt Approval Flow ins Spiel, mit mehrstufiger Genehmigung und bedingten Routen, die den Fortschritt tatsächlich sperren.

Benachrichtigungsvorlage für die Genehmigungsanfrage

Unter Einrichten > Benachrichtigungen verwendet die Vorlage für ein Genehmigungsereignis einer Änderung die Tags von GLPI. Ein schlanker Text reduziert Rückfragen:

Assunto: [Mudança ##change.id##] Aprovação solicitada - ##change.title##

Olá,

Uma mudança aguarda a sua aprovação.

Título:     ##change.title##
Categoria:  ##change.category##
Urgência:   ##change.urgency##
Impacto:    ##change.impact##
Prioridade: ##change.priority##

Descrição:
##change.content##

Aprovar ou recusar em:
##change.url##

Wenn Dringlichkeit, Auswirkung und Priorität im Text stehen, muss die genehmigende Person eine Änderung nicht erst öffnen, um zu entscheiden. Dies verkürzt die Zeit im Status Genehmigung, wo sich die meisten Wartungsfenster verzögern.

Diagnose: Änderungen ohne Rollback-Plan

Im Betrieb finden wir genau beim kritischsten Feld am häufigsten nichts eingetragen: backoutplancontent. Der Abschnitt mit den Plänen ist in der Oberfläche eingeklappt, also füllt ein Techniker Beschreibung und Aufgaben aus, aber nie einen Rückfallplan, und der Fehler zeigt sich erst, wenn eine Änderung schiefgeht und niemand weiß, wie man sie zurücknimmt. Wir führen dieses SELECT jeden Freitag vor dem Wartungsfenster am Wochenende aus:

SELECT c.id,
       c.name AS mudanca,
       c.status,
       IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
          'SEM ROLLBACK', 'ok') AS plano_retrocesso
FROM glpi_changes c
WHERE c.is_deleted = 0
  AND c.status NOT IN (5, 6)          -- exclui Resolvido e Fechado
ORDER BY c.date DESC;

Jede Zeile mit SEM ROLLBACK ist eine Änderung, die nicht in ein Wartungsfenster gehört. Wir haben daraus eine Geschäftsregel gemacht: Ohne ausgefüllten Rückfallplan keine Genehmigung.

Best Practices aus dem Betrieb

• Dokumentieren Sie backoutplancontent, bevor Sie eine Genehmigung anfordern, nicht nach der Umsetzung.
• Verknüpfen Sie eine Änderung mit dem auslösenden Problem (glpi_changes_problems), um die Nachverfolgbarkeit von der Grundursache zur Korrekturmaßnahme zu erhalten.
• Legen Sie Vorlagen für wiederkehrende Änderungen (Standard) an und verzichten Sie bei ihnen auf eine Genehmigung.
• Planen Sie außerhalb der Spitzenzeiten und erfassen Sie die tatsächliche actiontime, um Schätzungen zu kalibrieren.
• Schließen Sie den Zyklus mit der Überprüfung nach der Umsetzung ab, auch wenn alles gut gegangen ist; daraus entsteht Wissen für die Wissensdatenbank.

Wenn Ihr Betrieb eine Genehmigungsschranke braucht, die den Fortschritt wirklich sperrt, und eine prüfbare Governance von Änderungen, konfiguriert der Betrieb durch NexTool diesen Ablauf mit Modul Approval Flow auf dem GLPI, welches Sie bereits nutzen.

Geprüft vom Team von NexTool Solutions.