Unsere Managed IT geht an den Start. Und bevor die erste Organisation ihr erstes Problem meldet, stand eine Grundsatzentscheidung an: Womit nehmen wir Anfragen entgegen?
Die naheliegende Antwort wäre gewesen: irgendein Ticketsystem, Hauptsache es zählt hoch. Die haben wir bewusst nicht genommen. Wir haben nicht gekleckert, sondern geklotzt: vier Systeme in die engere Auswahl, jedes davon aufgesetzt, konfiguriert und mit Testdaten bedient. Hier steht, wie wir vorgegangen sind und wofür wir uns entschieden haben.
Warum das keine Geschmacksfrage ist
Ein Ticketsystem ist nicht „ein Postfach mit Nummern“. Es ist die Stelle, an der sich entscheidet, ob ein Problem in zwei Stunden gelöst ist oder drei Wochen in einem Mail-Verlauf versauert.
Für den gemeinnützigen Sektor kommt etwas hinzu. In einer NPO sitzen selten Menschen, deren Job es ist, ein Ticketsystem zu bedienen. Da ist die Buchhaltungskraft, die zwischen zwei Rechnungsläufen meldet, dass der Drucker im zweiten Stock nicht mehr will. Da sind Ehrenamtliche, die zweimal im Jahr Kontakt mit der IT haben. Ein System, das diese Menschen meidet, produziert keine Tickets – sondern Zurufe im Flur, Handynummern und Wissen, das nirgends steht.
Und es geht um Daten: Support-Tickets enthalten Namen, Geräte, manchmal Gesundheitsangaben aus einer Personalmeldung. Wo dieses System läuft und wer darauf Zugriff hat, ist keine Detailfrage.
Unsere fünf Kriterien
Vor dem ersten Klick haben wir festgelegt, woran wir messen. Sonst gewinnt am Ende immer das System mit der längsten Funktionsliste.
- Bedienbarkeit und Akzeptanz. Können Menschen ohne IT-Hintergrund ein Ticket erstellen und den Stand verstehen – ohne Schulung?
- DSGVO und Self-Hosting. Läuft das System vollständig auf unserer Infrastruktur in Deutschland, ohne Umweg über eine fremde Cloud?
- Kanäle und Wissensdatenbank. Kommen E-Mail, Telefon und Chat in einem Posteingang zusammen? Und lässt sich aus gelösten Fällen eine Wissensdatenbank aufbauen, statt dieselbe Antwort zum vierten Mal zu tippen?
- Open Source und Kosten. Offener Code, kein Lizenzpreis pro Kopf, kein Vendor-Lock-in. NPO-Budgets vertragen keine Lizenzmodelle, die mit jeder neuen Kollegin teurer werden.
- KI-Unterstützung. Hilft das System, Anfragen zu sortieren und Antworten vorzubereiten – und bleibt die Entscheidung trotzdem beim Menschen?
Die vier Kandidaten
Znuny
Der Fork des klassischen OTRS und damit ein System mit sehr langer Betriebsgeschichte. Queues, Eskalationen, SLAs, Berichte – alles da, alles erprobt, und in großen IT-Organisationen zu Recht im Einsatz.
Genau das ist aber auch der Punkt. Znuny ist für Support-Abteilungen gebaut, die ihre Prozesse in Rollen und Berechtigungen gießen wollen. Die Oberfläche setzt voraus, dass man weiß, was eine Queue ist. Für unsere Zielgruppe ist das eine Hürde vor dem ersten Ticket.
GLPI
Beeindruckend breit: Ticketing, Asset-Management, Problems, Changes, ein Service-Katalog und Dashboards, die auf den ersten Blick mehr zeigen als mancher Business-Intelligence-Report. Wer eine CMDB braucht, bekommt sie hier mitgeliefert.
Für eine Organisation mit dreißig Mitarbeitenden ist das ein vollständiger ITIL-Apparat für eine Aufgabe, die keinen braucht. Der Aufwand entsteht nicht bei der Installation, sondern danach: Ein System, das so viel kann, will konfiguriert und gepflegt werden. Diese Zeit fehlt dann bei der eigentlichen Arbeit.
ITFlow
Der spannendste Kandidat im Feld – und der, über den wir am längsten diskutiert haben. ITFlow denkt nicht vom Ticket her, sondern vom Kunden: Ansprechpartner, Standorte, Assets, Netzwerke, Zugangsdaten, Domains, Zertifikate und Abrechnung in einer Oberfläche. Genau die Dinge also, die ein IT-Dienstleister sonst über drei Tools und eine Tabelle verteilt.
Für uns als Betreiber ist das stark. Nur: Das Ticketing selbst ist der schlankste Teil davon. Für die Stelle, an der unsere Kund:innen mit uns in Kontakt kommen, war es uns zu dünn. ITFlow ist damit nicht vom Tisch – nur nicht als Ticketsystem.
Zammad
Aus dem OTRS-Umfeld entstanden, aber konsequent neu gedacht. E-Mail, Telefon und Chat laufen in einem Posteingang zusammen. Die Wissensdatenbank ist Teil des Systems, nicht ein Anbau. Und die Oberfläche erklärt sich weitgehend selbst: Wer eine Mail schreiben kann, kann ein Ticket bearbeiten.
Dazu kommt eine KI-Unterstützung, die an der richtigen Stelle ansetzt: einordnen, zusammenfassen, Antworten vorschlagen. Die Entscheidung bleibt bei den Menschen.
Die Entscheidung: Zammad
Zammad hat gewonnen, weil es in vier von fünf Kriterien klar vorne lag und im fünften niemand.
Akzeptanz vor Funktionsumfang. Das mächtigste System ist selten das passende. Was zählt, ist, ob eine Kollegin im Ehrenamt um 19 Uhr ein Ticket aufmacht – statt am nächsten Morgen anzurufen.
Datenhoheit ohne Kompromiss. Zammad läuft vollständig bei uns. Keine Ticketdaten in einer fremden Cloud, keine Auftragsverarbeitung über drei Ecken, keine Diskussion über Drittlandtransfers.
Ein Posteingang statt drei. Mail, Telefon und Chat an einem Ort – und jede gelöste Anfrage kann zu einem Eintrag in der Wissensdatenbank werden. Support, der mit der Zeit weniger Arbeit macht statt mehr.
Kosten, die zu NPO-Budgets passen. Open Source, kein Preis pro Kopf. Wächst eine Organisation, wächst nicht automatisch die Rechnung.
KI als Entlastung, nicht als Blackbox. Vorsortieren und vorformulieren ja – automatisch entscheiden nein. Bei Daten aus dem gemeinnützigen Sektor ist das keine Vorsicht, sondern Pflicht.
Und die ehrliche Gegenrechnung: GLPI und Znuny sind gute Systeme. Sie sind nicht an Qualität gescheitert, sondern an Passung. Beide bringen einen Prozessapparat mit, den unsere Kund:innen nicht brauchen – und dessen Pflege Zeit kostet, die anderswo fehlt. ITFlow bleibt bei uns im Blick, aber für andere Aufgaben.
Was das für euch heißt
Wir haben diese Auswahl für uns getroffen. Das Ergebnis nutzt aber genau dann etwas, wenn es übertragbar ist – und der Weg dorthin ist es:
- Kriterien vor Kandidaten. Wer erst Systeme anschaut und dann überlegt, was wichtig ist, kauft die längste Funktionsliste.
- Installieren statt vergleichen. Feature-Tabellen sagen wenig darüber, wie sich ein System nach zwanzig Tickets anfühlt. Eine Testinstallation kostet einen Tag und ersetzt eine Menge Meinung.
- Den Ausschlussgrund benennen. Ein Kandidat, der nur „irgendwie nicht passte“, kommt in sechs Monaten zurück.
Und wenn ihr diese Entscheidung nicht selbst treffen wollt: Wir haben den Test schon gemacht. Was wir für uns können, können wir auch für euch.