Shared Service Center (SSC) mit GLPI

Wie Sie GLPI zu einem Shared Service Center für Personal, Recht, Facility Management und Finanzen machen: die Entscheidung zwischen Einheit und Kategorie, SLA je Bereich, externer Cron und der häufige Fehler bei der Sichtbarkeit.

In diesem Artikel6 Abschnitte

GLPI muss nicht auf die IT beschränkt bleiben. Mit gut durchdachten Einheiten, Kategorien und Geschäftsregeln bedient eine einzige Instanz Personal, Recht, Facility Management und Finanzen als Shared Service Center (SSC). Was ein funktionierendes SSC von einem Haufen Tickets unterscheidet, ist die Architekturentscheidung, die vor dem ersten Formular getroffen wird.

Architekturentscheidung: Einheit je Bereich oder Kategorie je Bereich?

Dies ist die erste Wahl und diejenige, deren Rückgängigmachung am teuersten ist. In GLPI ist eine Einheit (Entität) eine Mandantengrenze: Sie isoliert Daten, SLAs, Profile und Katalog. Eine ITIL-Kategorie ist lediglich ein Klassifizierungsetikett innerhalb einer Einheit. Eine Einheit je Bereich bietet starke Isolation, verlangt aber Verwaltungsaufwand; Kategorien halten alles einfach, sind aber auf Gruppen und Regeln angewiesen, um Tickets zu routen und Daten zu schützen.

KriteriumEinheit je BereichKategorie je Bereich
DatenisolationStark (ein nicht rekursives Profil sieht die Schwesterbereiche nicht)Schwach (hängt von Gruppe und Regel ab)
Unabhängiges SLA je BereichNativManuell, über Regel + SLA je Kategorie
Konsolidierter BerichtErfordert rekursives Profil oder StammeinheitTrivial (nur eine Einheit)
VerwaltungsaufwandHoch (Profile, Rechte, Cron)Gering
Geeignet fürPersonal und Recht (vertrauliche Daten)Facility Management und Finanzen (geringe Vertraulichkeit)

Faustregel: Nutzen Sie Einheiten, wenn eine echte Vertraulichkeitsanforderung besteht (Personal und Recht verlangen sie meist) oder SLAs und Profile sich stark unterscheiden. Nutzen Sie Kategorien, wenn die Bereiche denselben Pool an Bearbeitern teilen und die Vertraulichkeit gering ist. Häufig ist ein hybrides Modell: eigene Einheit für Personal und Recht, Facility Management und Finanzen als Kategorien innerhalb der Unternehmenseinheit.

Schritt für Schritt zum ersten Bereich außerhalb der IT

  1. Modellieren Sie die Grenze: Entscheiden Sie anhand der obigen Matrix zwischen Einheit und Kategorie, bevor Sie irgendetwas anlegen.
  2. Legen Sie die Einheit (Verwaltung > Einheiten) oder den Kategorienbaum (Einrichten > Ticketkategorien) an und aktivieren Sie immer die rekursive Sichtbarkeit, wenn die Struktur gemeinsam genutzt wird.
  3. Legen Sie je Bereich eine Bearbeitergruppe an (Verwaltung > Gruppen) und aktivieren Sie „Kann Tickets zugewiesen werden“.
  4. Definieren Sie SLA/OLA des Bereichs (Einrichten > Service-Levels) mit realistischen Reaktions- und Lösungszeiten.
  5. Konfigurieren Sie Geschäftsregeln (Regeln > Ticketregeln), um Gruppe, Kategorie und SLA je nach Herkunft eines Tickets automatisch zuzuweisen.
  6. Bauen Sie den Katalog auf: native Formulare (GLPI 11) oder Plugin Formcreator (GLPI 10) mit den Feldern des Bereichs.
  7. Passen Sie Profile und Rechte an: Bearbeiter aus der Personalabteilung sollen die Warteschlange der IT nicht sehen und umgekehrt.
  8. Aktivieren Sie den externen Cron (nächster Abschnitt), bevor Sie den Service ankündigen.

Diagnose: Wer nutzt die Servicezentrale wirklich?

Messen Sie vor und nach der Erweiterung. Die folgende Abfrage liest direkt aus der Datenbank und zeigt Volumen und Zeit bis zur Lösung je Einheit und Kategorie in den letzten 30 Tagen. Führen Sie sie auf einem Replikat oder außerhalb der Spitzenzeiten aus.

-- Volume e tempo até a solução por entidade/categoria (30 dias)
SELECT e.completename                                   AS entidade,
       IFNULL(c.completename, '(sem categoria)')        AS categoria,
       COUNT(t.id)                                      AS chamados,
       ROUND(AVG(TIMESTAMPDIFF(HOUR, t.date, t.solvedate)), 1) AS horas_ate_solucao
FROM glpi_tickets t
JOIN glpi_entities e            ON e.id = t.entities_id
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= NOW() - INTERVAL 30 DAY
  AND t.is_deleted = 0
GROUP BY e.completename, c.completename
ORDER BY chamados DESC;

Erscheinen viele Zeilen mit „(sem categoria)“, deutet dies auf einen unvollständigen Katalog oder auf Bearbeiter hin, die Tickets ohne Klassifizierung erstellen – erstes Symptom eines SSC, welches seine Nachverfolgbarkeit verlieren wird.

Externer Cron: Warum ein SLA der Personalabteilung nicht rechtzeitig auslöst

Beim Betrieb von Umgebungen mit mehreren Bereichen ist eine Einheit ohne externen Cron die Konstellation, die am häufigsten still versagt. Die IT mit hohem Datenverkehr löst den internen Cron bei jedem Seitenaufruf aus, und niemand bemerkt ein Problem. Die Einheit der Rechtsabteilung hingegen, mit wenigen Aufrufen pro Tag, sammelt SLA-Eskalationen an, die erst laufen, wenn jemand die Oberfläche öffnet. Ein Ticket, welches uns dann erreicht, lautet meist: „Die Fristen-E-Mails der Rechtsabteilung kommen alle gesammelt gegen 9 Uhr an“ – genau dann, wenn sich der erste Benutzer anmeldet und der interne Cron endlich die aufgestaute Warteschlange abarbeitet. Die Lösung ist immer, die Ausführung in den Cron des Betriebssystems zu verlagern (MODE_EXTERNAL) und die Abhängigkeit vom Auslöser beim Seitenaufruf zu verringern.

# /etc/cron.d/glpi - cron externo do GLPI (roda como o usuário do servidor web)
# Dispara notificações, escalonamento de SLA e fechamento automático.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/null

Öffnen Sie nach der Einplanung Einrichten > Automatische Aktionen und prüfen Sie, ob die kritischen Aufgaben (Versand von Benachrichtigungen, SLA-Eskalation und Schließen von Tickets) im Modus CLI laufen und nicht im Modus „GLPI“ (Ausführung beim Seitenaufruf). In einer Umgebung mit mehreren Bereichen ist der interne Modus die Hauptursache für „die Frist ist abgelaufen, aber niemand wurde benachrichtigt“.

Der häufige Fehler: nicht rekursive Kategorie und fehlerhafte Sichtbarkeit

Der Fehler, der im Betrieb am häufigsten auftaucht, ist subtil: Eine Kategorie, die in der Stammeinheit angelegt wurde, ohne die Sichtbarkeit für untergeordnete Einheiten zu aktivieren, erscheint im Formular des Bereichs einfach nicht. Ohne die richtige Kategorie erstellt der Bearbeiter ein Ticket als generische „Störung“ oder tippt die Klassifizierung in den Titel – und der Bericht des Bereichs ist von Anfang an lückenhaft. Gleiches gilt für Profile: Ein Bearbeiter der Personalabteilung mit nicht rekursivem Profilumfang sieht nur genau die Einheit, in der er sich befindet, nicht die Untereinheiten. Wenn Sie Kategorien in der Stammeinheit anlegen, aktivieren Sie „Untergeordnete Einheiten“ (sichtbar in den Untereinheiten), mit entities_id = 0 und is_recursive = 1; wenn Sie Profile für Bereiche anlegen, entscheiden Sie bewusst, ob ihr Umfang rekursiv ist.

Governance: Vermeiden Sie eine Explosion der Kategorien

  • Begrenzen Sie den Baum auf 2 Ebenen je Bereich; bei mehr klassifiziert niemand mehr sauber.
  • Benennen Sie Kategorien nach der Aktion des Anfragenden („Erstattung beantragen“), nicht nach internem Fachjargon.
  • Überprüfen Sie vierteljährlich die Zeilen „(sem categoria)“ der Diagnose.
  • Ein Verantwortlicher je Bereich, zuständig für Katalog und SLAs.
  • Replizieren Sie dieselbe Kategorie nicht manuell in mehreren Einheiten; machen Sie sie ab der Stammeinheit rekursiv.

Beginnen Sie mit der IT, die bereits an einen Service Desk gewöhnt ist, und erweitern Sie schrittweise. Jeder neue Bereich kommt mit definierter Grenze, Bearbeitergruppe, SLA und validiertem externem Cron hinzu – nicht mit einem improvisierten Katalog.

Sie möchten die Grenze zwischen Einheiten und Kategorien festlegen, bevor Sie Ihr SSC skalieren? NexTool führt GLPI für mehrere Bereiche bei B2B-Kunden ein und betreut es, von der Modellierung der Einheiten bis zu Cron und Routing-Regeln.


Geprüft vom Team von NexTool Solutions.

Häufig gestellte Fragen

Es hängt von der Vertraulichkeit ab. Nutzen Sie eine Einheit, wenn eine echte Vertraulichkeitsanforderung besteht (Personal, Recht) oder SLAs und Profile sich stark unterscheiden, denn eine Einheit isoliert Daten nativ. Nutzen Sie eine Kategorie, wenn die Bereiche dasselbe Bearbeiterteam teilen und die Vertraulichkeit gering ist (Facility Management, Finanzen). Hybride Modelle sind üblich und empfehlenswert.

Mit Einheiten weisen Sie den Bearbeiter der Einheit seines Bereichs mit einem Profil mit nicht rekursivem Umfang zu, damit er keine Schwestereinheiten sieht. Innerhalb einer Einheit nutzen Sie Bearbeitergruppen und Geschäftsregeln, um jedes Ticket nur an die zuständige Gruppe zu leiten und die Sichtbarkeit je Gruppe einzuschränken.

Fast immer, weil der Cron von GLPI im internen Modus läuft (Ausführung beim Seitenaufruf). Bereiche mit wenig Datenverkehr, etwa die Rechtsabteilung, stauen ihre Warteschlange auf, bis jemand die Oberfläche aufruft. Die Lösung ist, den externen Cron des Betriebssystems so zu konfigurieren, dass er front/cron.php aufruft, und die kritischen automatischen Aktionen im Modus CLI laufen zu lassen.

Ja. Mit Einheiten definiert jeder Bereich seine eigenen Service-Levels nativ. Mit Kategorien wenden Sie ein SLA per Geschäftsregel je nach Kategorie eines Tickets an. Facility Management kann 4 Stunden für „Klimaanlage defekt“ haben, während die Rechtsabteilung 5 Werktage für „Vertragsprüfung“ hat.

Über die native Suche von GLPI, gruppiert nach Einheit oder Kategorie, oder über eine direkte SQL-Abfrage auf glpi_tickets mit JOIN auf glpi_entities und glpi_itilcategories. Die Abfrage zeigt außerdem Zeilen „(sem categoria)“, die auf einen unvollständigen Katalog oder auf Bearbeiter hinweisen, die Tickets ohne Klassifizierung erstellen.

Brauchen Sie Hilfe?