GLPI als Open Source hat keine monatliche Gebühr, aber „ohne Lizenz“ ist noch lange nicht „ohne Kosten“. Wer nur den Listenpreis von GLPI self-hosted mit dem von ServiceNow vergleicht, verrechnet sich in beide Richtungen: Er unterschätzt, was self-hosted im Betrieb verbraucht, und überschätzt, was SaaS ab Werk liefert. Dieser Vergleich stellt die vier Modelle gegenüber, die wir am häufigsten einführen – GLPI self-hosted, GLPI Cloud, ServiceNow und Jira Service Management –, und zwar entlang der Achse, die die TCO tatsächlich bestimmt: Abrechnungseinheit und Betriebsaufwand.
Die vier Modelle in je einem Satz
- GLPI self-hosted (Open Source): kostenlose Software ohne Benutzerlimit; Sie bezahlen Infrastruktur und Arbeitszeit.
- GLPI Cloud (Teclib): dasselbe GLPI, gehostet und gewartet von Teclib, mit Abonnement pro Techniker.
- ServiceNow: ITSM-Enterprise-Plattform, Lizenz pro Agent auf Anfrage, ausgerichtet auf Automatisierung und Governance im großen Maßstab.
- Jira Service Management: ITSM von Atlassian, Abonnement pro Agent in Tarifen, stark für alle, die bereits im Jira/Confluence-Ökosystem arbeiten.
Die drei kostenpflichtigen Modelle rechnen pro Agent oder Techniker ab: Die Kosten wachsen annähernd linear mit der Größe des Support-Teams. Self-hosted kehrt diese Logik um – die Software liegt fix bei null, und die Kosten entstehen im Betrieb. Dieser grundlegende Unterschied, nicht der Preis eines einzelnen Monats, entscheidet, welches Modell über drei Jahre günstiger ist.
Direkter Vergleich
| Kriterium | GLPI self-hosted | GLPI Cloud | ServiceNow | Jira SM |
|---|---|---|---|---|
| Lizenzmodell | Open Source (kostenlos) | Abonnement pro Techniker | Enterprise-Lizenz, auf Anfrage | Abonnement pro Agent (Tarife) |
| Wo es läuft | Ihre Infrastruktur | Cloud von Teclib | Cloud des Anbieters | Cloud von Atlassian |
| Wer betreibt (Infrastruktur, Backup, Update) | Sie | Teclib | Anbieter | Atlassian |
| Abrechnungseinheit | Keine (nur Infrastruktur + Stunden) | Pro Techniker | Pro Agent | Pro Agent |
| Anforderer (Self-Service) | Unbegrenzt und kostenlos | Unbegrenzt | Je nach Vertrag | Je nach Tarif |
| Natives Inventar / CMDB | Ja, stark | Ja | Ja, umfassend | Eingeschränkt (Add-on) |
| Anpassung / Plugins | Vollständig (offener Code + Marketplace) | Hoch (dieselben Plugins, Infrastrukturgrenzen) | Hoch, über die Plattform (komplex und teuer) | Mittel (Atlassian-Apps) |
| Einführungsaufwand | Mittel bis hoch | Mittel | Hoch | Mittel |
| Daten-Lock-in | Gering (die Datenbank gehört Ihnen) | Mittel | Hoch | Hoch |
| Datenhoheit / On-Premises | Vollständig | Verwaltete Cloud | Cloud des Anbieters | Cloud von Atlassian |
| Versions-Update | Ihre Verantwortung | Inklusive | Inklusive | Inklusive |
| Kostenentwicklung mit dem Team | Praktisch flach | Linear pro Techniker | Linear (hohes Niveau) | Linear pro Agent |
| Relative Kosten (vs. self-hosted) | Basis | Höher | Am höchsten | Mittel |
Wie viele „Agenten“ Sie wirklich bezahlen
Hier liegt die Falle, die erst bei der Rechnung sichtbar wird: In Modellen pro Agent kostet der Benutzer mit technischer Oberfläche (Central), nicht der Anforderer, der nur über den Self-Service Tickets erstellt. Anforderer sind bei allen drei Anbietern meist unbegrenzt und kostenlos. Die Zahl, die Ihre Rechnung bestimmt, lautet also nicht „wie viele Personen nutzen GLPI“, sondern „wie viele haben ein Technikerprofil“.
Bei self-hosted ist diese Zahl unsichtbar – niemand berechnet sie, also verteilen Organisationen das Central-Profil großzügig: an den Koordinator, der nur Dashboards sehen will, an den Manager, der „manchmal in die Warteschlange schauen muss“, an den Praktikanten, der im letzten Jahr zwei Tickets geschlossen hat. Bei der Migration zu einem SaaS mit Abrechnung pro Agent wird jeder von ihnen zu einer Zeile auf der Rechnung. Bevor Sie ein Angebot anfordern, führen Sie diese Abfrage in der Datenbank Ihres GLPI aus, um die tatsächliche Zahl zu kennen:
-- Quantos "agentes" você pagaria num SaaS por agente?
-- Agente faturável = usuário com perfil de interface central (técnico),
-- não o usuário de autoatendimento (helpdesk), que costuma ser ilimitado.
SELECT COUNT(DISTINCT pu.users_id) AS agentes_faturaveis
FROM glpi_profiles_users pu
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_users u ON u.id = pu.users_id
WHERE p.interface = 'central' -- interface técnica (exclui helpdesk)
AND u.is_active = 1
AND u.is_deleted = 0;Wir haben schon erlebt, dass diese Zahl 40 % über der Schätzung des Kunden „aus dem Kopf“ lag. Bevor Sie Preise mit SaaS vergleichen, räumen Sie auf: Stufen Sie alle auf Self-Service herunter, die nicht tatsächlich Support leisten. Dies senkt die künftige Rechnung und bereinigt nebenbei die Produktivitätsberichte in GLPI selbst.
Die versteckten Kosten, die in keiner Tabelle stehen
Beim Betrieb von GLPI-Installationen für Kunden ist der Posten, der die TCO von self-hosted am stärksten sprengt, in keiner Tabelle zu finden: die Update-Schuld. Der Kunde setzt GLPI auf, es funktioniert, und zwei Jahre lang rührt es niemand an. Wenn dann endlich eine neue Funktion oder ein kompatibles Plugin gebraucht wird, stellt sich heraus, dass der Sprung von 9.5 auf 11 kein „Klick auf Aktualisieren“ ist – es bedeutet Schema-Migration, Überprüfung kaputter Plugins und Tests in einer Testumgebung. Aus 2 Stunden Wartung pro Monat wird ein Projekt. Der typische Fehler: self-hosted nur nach dem VPS zu kalkulieren und Updates als seltenes Ereignis zu behandeln; sie wiederholen sich und erfordern ein Wartungsfenster, ein getestetes Backup und eine Testumgebung.
Und es gibt einen weiteren Kostenfaktor, den niemand einrechnet: das Backup, für eine Wiederherstellung noch nie verwendet. Bei self-hosted liegt das Disaster Recovery vollständig in Ihrer Verantwortung – und ein Dump, den niemand getestet hat, ist ein Backup, für den Ernstfall wertlos. Minimal sinnvoll ist ein täglicher Dump von Datenbank und Dateien mit regelmäßiger Prüfung:
# /etc/cron.d/glpi-backup - dump diário do banco + arquivos do GLPI.
# No self-hosted, backup e DR são 100% seus; um dump nunca restaurado não conta.
30 2 * * * root mysqldump --single-transaction glpi | gzip > /backup/glpi-$(date +\%F).sql.gz
45 2 * * * root tar czf /backup/glpi-files-$(date +\%F).tar.gz /var/www/glpi/files
# Guarde cópia FORA do host e teste o restore ao menos uma vez por trimestre.Bei GLPI Cloud, ServiceNow und Jira SM sind Updates, Backup und Verfügbarkeit im Abonnementpreis enthalten – genau dafür bezahlen Sie pro Agent. Die richtige Frage lautet nicht „was ist günstiger“, sondern „bleibt diese Betriebsarbeit in meinem Team oder wird sie über die Monatsgebühr ausgelagert?“.
Fazit je Szenario
- Nutzen Sie GLPI self-hosted, wenn Sie jemanden haben (oder beauftragen), der Linux, Datenbank und Backup betreibt, Ihnen Datenhoheit wichtig ist und Sie eine planbare Kostenobergrenze wollen, selbst wenn sich das Agententeam verdoppelt. Bei den Kosten pro Agent ist es unschlagbar, je größer das Team wird; wenn Sie diesen Weg gehen, beginnen Sie mit der Installation per Docker.
- Nutzen Sie GLPI Cloud, wenn Sie dasselbe GLPI wollen – gleiche Basis, gleiche Konzepte, gleiche kompatible Plugins –, ohne Infrastruktur zu pflegen, und das Technikerteam klein genug ist, dass das Abonnement immer noch günstiger ist als ein eigener Sysadmin.
- Nutzen Sie ServiceNow, wenn der tatsächliche Bedarf Automatisierung und Governance auf Enterprise-Niveau ist (komplexe Abläufe, Unternehmensintegrationen, Compliance) und Budget für das höchste Preisniveau am Markt vorhanden ist. ServiceNow nur zum Erstellen von Tickets einzusetzen heißt, ein Flugzeug zu bezahlen, um die Straße zu überqueren.
- Nutzen Sie Jira Service Management, wenn das Unternehmen bereits mit Jira/Confluence arbeitet und ITSM eng an dieses Ökosystem anbinden will – unter Inkaufnahme der Abrechnung pro Agent und der Grenzen bei Inventar/CMDB im Vergleich zu GLPI.
Kosten und Aufwand, mit ehrlichen Spannen
Die Entscheidungsachse ist nicht die Lizenz – sondern wohin die Betriebsarbeit wandert. Bei self-hosted ist der finanzielle Aufwand gering (ein VPS für einige Dutzend bis einige Hundert Reais pro Monat, je nach Größe), erfordert aber wiederkehrende Technikerstunden: Eine saubere Einführung passt selten in weniger als einige Arbeitstage, und der laufende Betrieb braucht ein monatliches Fenster für Updates und Backup-Prüfung. Bei den Modellen pro Agent ist der Aufwand höher und wächst linear mit dem Team, aber die Betriebsstunden für Infrastruktur gehen gegen null. Die Drei-Jahres-Rechnung begünstigt self-hosted meist umso mehr, je größer das Agententeam und je günstiger die verfügbare Technikerstunde ist; sie begünstigt SaaS, wenn das Team schlank ist und niemand Infrastruktur betreiben kann. Legen Sie sich auf keine feste TCO-Zahl fest, bevor Sie die Gesamtzahl abrechenbarer Agenten und die tatsächlichen Kosten Ihrer Technikerstunde kennen – ohne diese beiden Werte ist jeder Vergleich geraten.
Bei NexTool führen wir alle vier Szenarien bei Kunden ein und betreuen sie – vom schlanken GLPI self-hosted bis zur Migration in die Cloud –, und die Entscheidung, die sich am meisten auszahlt, ist immer dieselbe: die Kosten nach der richtigen Einheit (abrechenbare Agenten) und nach dem Betriebsaufwand zu bemessen, den Ihr Team stemmen kann. Wenn Sie eine ehrliche TCO für Ihren Fall wollen, ohne Tabellenschätzung, erstellt unsere Beratung diesen Vergleich mit Ihren Zahlen.
Geprüft vom Team von NexTool Solutions.