Zammad als EU-souveräne Alternative zu Jira Service Management

Die Suche nach einem Ticketsystem endet erstaunlich oft bei Jira Service Management, ServiceNow oder Freshservice — und danach beginnt die Diskussion über Lizenzkosten pro Agent, über Datenverarbeitung in den USA und darüber, welchen Teil der eingekauften Funktionen man je benutzen wird.

Zammad ist die naheliegende Gegenfrage. Ein Open-Source-Helpdesk aus Berlin, unter AGPL, selbst hostbar. Wir betreiben es für uns und für Kunden. Und wir sagen genauso deutlich, wo es nicht reicht.

Was Zammad gut macht

Ticketing über alle Kanäle. E-Mail, Webformular, Telefon, Chat auf der eigenen Website, Messenger — alles landet im selben Posteingang mit einer gemeinsamen Historie. Der Kunde schreibt eine Mail, ruft am nächsten Tag an, und der Mitarbeiter sieht beides in einem Vorgang. Das klingt selbstverständlich, ist es in gewachsenen Setups aus Sammelpostfach und Telefonnotizen aber nicht.

Eine Oberfläche, die Mitarbeiter ohne Schulung bedienen. Der praktische Unterschied zu den großen Suiten liegt weniger im Funktionsumfang als in der Einstiegshürde. Zammad ist an einem Vormittag erklärt. Wer schon einmal eine ITSM-Einführung mit Prozessberatung und Schulungswochen erlebt hat, weiß, was dieser Punkt wert ist.

SLAs, Automatisierung, Textbausteine. Reaktions- und Lösungszeiten je Kunde oder Ticketart, Eskalation bei Überschreitung, Trigger für automatische Zuweisung und Antworten, geplante Aktionen für wiederkehrende Aufgaben. Das deckt den Alltag eines Support-Teams ab.

Wissensdatenbank inklusive. Intern für das Team, öffentlich für Kunden — ohne ein zweites Produkt zu lizenzieren. Bei Atlassian ist die Wissensdatenbank Confluence, also ein eigenes Abonnement.

Anbindung an die vorhandene IT. LDAP und Active Directory für Benutzer, SAML und OpenID Connect für Single Sign-on, eine vollständige REST-API und Webhooks. Damit lässt sich Zammad an das anschließen, was schon da ist — bei uns hängt etwa die Ticketerstellung aus Monitoring-Alarmen daran.

Keine Lizenzkosten pro Agent. Die selbst gehostete Version ist vollständig nutzbar. Bei den kommerziellen Suiten skalieren die Kosten mit jedem Mitarbeiter, der auch nur gelegentlich ins System schaut — was in der Praxis dazu führt, dass Kollegen keinen Zugang bekommen und Informationen wieder per Mail weitergereicht werden.

Der Souveränitäts-Punkt

Zammad wird von der Zammad GmbH in Berlin entwickelt, steht unter AGPL v3 und läuft auf Ihrem Server — oder in einem gehosteten Angebot mit Rechenzentrum in Deutschland. Für ein Ticketsystem ist das relevanter als bei den meisten anderen Werkzeugen: In den Vorgängen stehen Kundennamen, Telefonnummern, Vertragsdetails, Fehlerbeschreibungen aus internen Systemen, gelegentlich Zugangsdaten und Screenshots aus Fachanwendungen. Es ist eines der personenbezogensten Systeme im Haus.

Bei Jira Service Management, ServiceNow und Freshservice sind das US-Anbieter. Der Transfer läuft derzeit über den Angemessenheitsbeschluss zum EU-U.S. Data Privacy Framework — die Nutzung ist damit möglich. Der Vorbehalt ist derselbe wie bei jedem US-Dienst: Es ist der dritte Anlauf nach Safe Harbor und Privacy Shield, und die Grundlage hängt an politischen Voraussetzungen in den USA. EU-Datenresidenz bieten die großen Anbieter an, allerdings meist erst in den höheren Tarifstufen — und Datenresidenz ist nicht dasselbe wie Datenhoheit, solange der Betreiber US-Recht unterliegt.

Beim Selbsthosten stellt sich die Frage gar nicht. Kein Auftragsverarbeiter, kein Drittlandtransfer, kein Transfer Impact Assessment. Für öffentliche Auftraggeber, Kanzleien, Arztpraxen und alle mit Berufsgeheimnis ist das häufig kein Komfort-, sondern ein Ausschlusskriterium. Das ist eine technische Einordnung, keine Rechtsberatung — die Bewertung für Ihr Haus gehört zum Datenschutzbeauftragten.

Wo Zammad an Grenzen stößt

Das ist der Abschnitt, den Anbieterseiten weglassen. Zammad ist ein sehr gutes Ticketsystem. Eine vollständige ITSM-Suite nach ITIL ist es nicht, und diese Unterscheidung entscheidet über Erfolg oder Scheitern der Einführung.

Keine ausgebaute CMDB. Jira Service Management bringt mit Assets eine Konfigurationsdatenbank mit Abhängigkeitsgraph mit: Welcher Server trägt welchen Dienst, wer hängt an welchem Vertrag, welche Lizenz läuft wann aus. Zammad kennt Objekte und eigene Felder, aber keine gleichwertige CMDB. Wer Asset- und Konfigurationsmanagement im Ticketsystem erwartet, braucht ein zweites Werkzeug — etwa i-doit oder iTop.

Kein echtes Change- und Problem-Management. Change-Prozesse mit Genehmigungsstufen, Change Advisory Board, Freigabekalender und Rückfallplänen sind nicht abgebildet. Ebenso wenig die formale Trennung von Incident, Problem und Change. Mit Ticketarten und Triggern lässt sich vieles nachbauen — wer aber gegen ein zertifiziertes ITIL-Prozessmodell auditiert wird, baut hier an der falschen Stelle.

Genehmigungsworkflows fehlen. „Neuer Mitarbeiter braucht Zugriff auf X, Vorgesetzter muss freigeben, dann Umsetzung“ — solche mehrstufigen Freigaben sind nicht nativ vorgesehen.

Auswertungen sind einfach gehalten. Es gibt Berichte, aber keine frei konfigurierbaren Dashboards und keine tiefe Auswertung über beliebige Dimensionen. Wer monatlich gegen zugesagte Kennzahlen berichten muss, exportiert und arbeitet extern weiter.

Kein Service-Katalog mit strukturierten Anforderungen. Ein Portal, in dem Mitarbeiter aus einem Katalog wählen und je Leistung ein passendes Formular ausfüllen, ist eine Stärke der großen Suiten. Zammad hat ein Kundenportal, aber keinen vergleichbaren Katalog.

Kleineres Ökosystem. Der Atlassian Marketplace hat für nahezu jedes Randproblem eine App. Bei Zammad schreibt man in vergleichbaren Fällen selbst etwas gegen die API — was mit Entwicklungskapazität gut funktioniert und ohne sie gar nicht.

Betriebsaufwand. Zammad braucht PostgreSQL, Elasticsearch, Redis und Memcached. Elasticsearch ist dabei der hungrigste Teil und der häufigste Grund, warum eine zu klein dimensionierte Instanz auffällig wird. Ein SaaS-Produkt hat diesen Aufwand nicht — dieser Punkt gehört ehrlich in die Rechnung, auch wenn keine Lizenzkosten anfallen.

Die Einordnung

Zammad passt sehr gut, wenn: ein bis dreißig Personen im Support arbeiten, der Schwerpunkt auf Anfragen von Kunden oder Kollegen liegt, Datenhoheit ein Thema ist, Lizenzkosten pro Kopf stören und niemand ein ITIL-Zertifikat verlangt. Das beschreibt den größten Teil des Mittelstands, dazu Agenturen, IT-Dienstleister, Kanzleien, Praxen, Vereine und kommunale Einrichtungen.

Zammad passt nicht, wenn: eine CMDB mit Abhängigkeiten gebraucht wird, Change-Management mit formalen Freigaben läuft, gegen ITIL auditiert wird, Service-Kataloge mit Genehmigungsketten nötig sind oder ein internationaler Konzern hundert Teams mit unterschiedlichen Prozessen abbilden muss. Dann ist Jira Service Management oder ServiceNow trotz Kosten und Drittlandfrage die sachlich richtige Wahl — ein Ticketsystem gegen einen Prozess zu biegen, für den es nicht gebaut ist, wird teurer als die Lizenz.

Ein häufiger Zwischenweg im Mittelstand: Zammad für den Support-Alltag, daneben ein spezialisiertes Werkzeug für Inventar und Dokumentation, verbunden über die API. Das ist weniger elegant als eine Suite, aber deutlich billiger als eine Suite, von der zwei Module genutzt werden.

Zum Betrieb

Zammad läuft über Paketquellen, per Docker Compose oder im Kubernetes-Cluster über das offizielle Helm-Chart. Drei Punkte aus der Praxis:

Elasticsearch großzügig ausstatten. Ohne funktionierenden Suchindex fühlt sich Zammad zäh an, und die Symptome sehen zunächst nicht nach Elasticsearch aus. Speicher ist hier die falsche Stelle zum Sparen.

Zwei Dinge sichern: die PostgreSQL-Datenbank und den Speicher für Anhänge. Der Suchindex lässt sich neu aufbauen, die anderen beiden nicht.

E-Mail-Anbindung zuerst testen. Der häufigste Stolperstein bei der Einführung ist nicht Zammad, sondern das Zusammenspiel mit dem vorhandenen Mailsystem: Weiterleitungen, Absenderadressen, SPF und DKIM. Das gehört vor den Produktivstart geklärt, nicht danach.

Fazit

Zammad ist kein abgespecktes Jira Service Management. Es ist ein anderes Werkzeug für einen anderen Zuschnitt: hervorragend dort, wo Anfragen sauber und nachvollziehbar bearbeitet werden sollen — unzureichend dort, wo formale ITIL-Prozesse mit CMDB und Freigabeketten gefordert sind. Für viele mittelständische Unternehmen fällt der eigene Bedarf genau in die erste Kategorie, und dann sind Datenhoheit und wegfallende Agentenlizenzen ein doppelter Gewinn.

Wir führen Zammad ein, migrieren aus Sammelpostfächern oder bestehenden Systemen und betreiben die Instanz mit — inklusive der ehrlichen Vorabprüfung, ob es zu Ihren Abläufen passt. Sprechen Sie uns an.