Ein Ticketsystem ist viel mehr als ein Nummernautomat – es strukturiert und begleitet alle Tätigkeiten von Supportmitarbeitern und Dienstleistern, hält Kunden bei Laune und überwacht Service-Zusagen. Das Linux-Magazin löst ein Ticket für eine Reise durchs Supporter-Land.

Meine Ausdrucke kommen nicht raus! Die von Ihnen gelieferte Waschmaschine macht einen Kurzschluss! Wo bleibt bitte mein bestelltes Paket?! In der Friedenstraße, Ecke Mühlenweg, hat ein Hydrant die Kreuzung unter Wasser gesetzt! Ich rufe jetzt das dritte Mal an, weil mein DSL ausgefallen ist! … Die Probleme zwischen Mensch und Technik in der Industriegesellschaft sind ebenso häufig wie mannigfaltig.

Auf der anderen Seite sitzen Supporter, Kundendienstler, Rettungskräfte oder anderes Personal, das – oft hauptberuflich – sich den Problemen widmen muss. Um nicht in einem Chaos zwischen Telefon, Mail-Inbox, Social-Media-Kanälen, Post-its und möglicherweise zuständigen Kollegen, die aber alle gerade im Urlaub zu sein scheinen, unterzugehen, sind Ticketsysteme erfunden worden.

Ticketsysteme sind übrigens nicht nur zum Bearbeiten von Störungen im Einsatz (Trouble Ticketsystem), sondern auch zum Handling anderer Anfragen (Service Requests), wie Änderungs- und Erweiterungswünsche (Change Request, Request for Change, Request for Enhancement) oder informative Anfragen (Request for Information, Request for Education). Issue-Tracking-Systeme, so lautet der Oberbegriff, decken einen Großteil oder alle folgenden Grundfunktionen ab:

• Erfassung von Störungen und Anfragen – entweder manuell oder automatisch (E-Mail Response Management System, Webformular, Alarm- oder Monitoringsystem)
• Zuordnung zu einem ersten Bearbeiter, der den Request entweder selbst zu Ende bringt oder das Ticket in einer Queue bereitlegt für einen neuen Bearbeiter
• Zwangssteuerung über Workflows
• Überwachung von Dauer und Qualität der Bearbeitung sowie deren Korrelation mit Service-Zusagen (Service Level Agreements)
• statistische Auswertung und Berichte
• Erfassen und Bereitstellen von Standardantworten
• Benutzer und Gruppen verwalten, Anbindung an Drittsysteme.

Darüber hinaus unterscheiden sich reale Systeme in den Detailfunktionen, die sie anbieten, in der Usability, in Art und Umfang der Erweiterungsmöglichkeiten und – soweit nicht reinrassig Open Source – im Preis.

Systeme, die Helfern helfen

Es lohnt also, Ausstattung und konzeptionelle Unterschiede von Ticketsystemen genauer anzuschauen – genau das tut dieser Magazin-Schwerpunkt. Die Redaktion hat ein paar gängige Vertreter ausgewählt, die unter Linux laufen und als Open Source verfügbar sind. Mit dabei ist natürlich das hierzulande bekannteste System OTRS, von dem es Forks gibt, da nach Meinung einiger Anwender wichtige Weiterentwicklungen zunehmend nur für zahlende Kunden zu haben sind.

Den Abschluss des Schwerpunkts bildet eine kleine Retrospektive von Linux-Magazin-Autor Stefan Wintermeyer, den viele als Linux-VoIP-Pionier in Erinnerung haben. Vor dieser Zeit jedoch war er bei Suse in Nürnberg angestellt und hatte dort den OTRS-Vorgänger STTS (Stefans Trouble Ticket System, später Suse Trouble Ticket System) erfunden.

Dazwischen sind zwei Beiträge, die sich speziell in zwei Sichtweisen auf die Testkandidaten hineinversetzten: Der eine nimmt die Rolle eines Ticketbearbeiters (Agent) ein. Der andere blickt aus der Perspektive der Hilfesuchenden auf die dazu angebotenen Möglichkeiten.

Zammad

Zammad punktet mit einer zeitgemäß wirkenden Weboberfläche, die HTML 5 und Websockets verwendet und mit sehr vielen gut durchdachten Features. Die hauptsächlich mit dem Ruby-on-Rails-Framework entworfene Software lässt sich nicht nur klassisch über Debian- und RPM-Pakete auf den üblichen Distributionen (etwa Debian, Ubuntu, Centos, Suse) installieren, es gibt auch zwei Versionen im Docker-Format.

Für Tests genügt es, das einfache Docker-Image (»docker run -ti –rm –name zammad -p 80:80 zammad/zammad«) aus dem Docker-Hub zu holen. Allerdings gehen nach dem Herunterfahren der Containerinstanz sämtliche Daten verloren. Der Weg über Docker Compose (Abbildung 1, [1]) funktioniert daher nachhaltiger und auch in Produktivumgebungen, weil er die beteiligten Dienste in verschiedene Container verpackt und die Daten speichert.

Zu den Komponenten von Zammad gehören neben Rails der Webserver Nginx (alternativ Apache), PostgreSQL als Datenbank (alternativ existiert Support für Maria DB und MySQL) und Elasticsearch als Suchfunktion. Der Client für die Kunden, Mitarbeiter und Admins läuft dann im Fenster eines aktuellen Browsers. Native Apps für Smartphones und Tablets gibt es bislang noch nicht, das Projekt will aber Updates liefern, sobald diese in Arbeit sind.

Abbildung 1: Docker Compose verpackt die einzelnen Zammad-Komponenten säuberlich in Container, wozu auch die Daten gehören.

Import und Kooperation

Wer Daten aus bestehenden Installationen integrieren will, kann gleich nach der Installation auf einen Migrationsassistenten zugreifen, der für OTRS und Zendesk funktioniert, wenn auch noch mit dem »Beta«-Zusatz versehen. Aber es sind Testimports möglich.

Alternativ lassen sich User, Organisationen und Textmodule auch über CSV-Dateien importieren. Bei Textmodulen handelt es sich um vorgefertigte Textschablonen, die sich über Kürzel in Antwortmails an die Kunden integrieren lassen. Das erspart den Mitarbeitern den Aufwand, Standardantworten jedes Mal neu eintippen zu müssen. Diese Form des Imports klappt mittlerweile auch über das Webinterface.

Auch verschiedene externe Dienste kann der Admin mit Zammad verknüpfen, was über das Zahnradsymbol links unten und dann die Auswahl von »System | Integrationen« gelingt (Abbildung 2). Die aktuelle Version bietet Schnittstellen für die Monitoring-Lösungen Nagios, Icinga, Monit und Check_mk an. Kontakte lassen sich über Exchange einbinden, die Benutzerverwaltung an LDAP koppeln. Daneben bringt Zammad Support für Sipgate.io, Slack, Clearbit und CTI mit. Letzteres steht für Computer Telephony Integration und erlaubt es, Anrufer anhand bestimmter Merkmale sofort zu identifizieren und die zugehörigen Tickets auf den Schirm zu holen. Das erfordert eine Anbindung der Zammad-Endpoints an die interne Telefonanlage (PBX).

Nicht zuletzt ist es über die I-Doit-Anbindung möglich, eine Configuration Management Database zu integrieren. Diese dokumentiert die Objekte in einer IT-Infrastruktur, für die sich über eine I-Doit-Sidebar dann Tickets schreiben lassen.

Abbildung 2: Zammad lässt sich an diverse Dienste anbinden, die sich um das Monitoring oder die Benutzerverwaltung kümmern.

Rollenspiele

Üblicherweise legt ein Admin nach dem erfolgreichen Aufsetzen des Systems, über den Menüpunkt mit dem Zahnrad unten links und »Verwalten | Benutzer« neue User an und steckt sie über »Verwalten | Gruppen« in eine dort definierte Benutzergruppe. Über die beiden Bildschirme findet dann auch der erwähnte CSV-Import statt, wobei die Dateien in UTF-8 kodiert sein müssen.

Über »Verwalten | Rollen« legt der Admin dann für die Nutzergruppen eigene Rollen an, deren Befugnisse unterschiedlich stark ausfallen dürfen. Das reicht vom einfachen Service-Desk-Agent mit wenigen Zugriffsrechten bis hin zu einem Mini-Admin [2], der in großen Setups als eine Art Hilfssheriff auftritt.

Für Admins ist es auch immer möglich, sich aus der Sicht eines Mitarbeiters im System anzumelden, um die Auswirkungen seiner Konfigurationen zu ergründen. Denn abhängig von den gesetzten Rechten verändert sich nach dem Anmelden für die Mitarbeiter die grafische Oberfläche von Zammad. So fallen etwa bestimmte Einstellungsdialoge weg, weil einfache Mitarbeiter diese nicht benötigen oder sie im Worst Case sogar die Zammad-Installation gefährden.

Apropos Zammad-Installation: Um bei mehreren verfügbaren Zammad-Instanzen die Tickets einer von diesen sicher zuzuordnen, weist der Admin seiner Zammad-Instanz bei Bedarf über »Einstellungen | System« eine System-ID zu. Die fließt dann auch stets in die Ticketnummern ein.

Rund ums Ticket

Die Historie von Tickets ist in Zammad auditierbar. Um sie anzuschauen, klicken Mitarbeiter auf ein Ticket und dann oben rechts in der Seitenleiste auf »Ticket | Historie«. Hier lässt sich der Bearbeitungsverlauf im Nachhinein rekonstruieren, auch wenn mehrere Mitarbeiter am Ticket gearbeitet haben. Eine Kollisionserkennung sorgt dafür, dass Mitarbeiter in Echtzeit erfahren, ob noch ein anderer Mitarbeiter gerade an einem Ticket arbeitet. Ist dies der Fall, erscheint im Fußbereich eines Tickets das Icon des Bearbeiters, bei dem das Ticket gerade offen ist.

In der Regel haben neue Tickets zunächst keinen Bearbeiter. Der Admin kann diese aber über »Einstellungen | Ticket | Automatische Zuweisung« aktivieren. In diesem Fall weist das System Tickets abhängig von ihrem aktuellen Status automatisch bestimmten Bearbeitern zu. Andernfalls müssen sich Mitarbeiter aktiv als Ticketbearbeiter eintragen. Ist ein Ticketbearbeiter im Urlaub, gibt es zudem einen Abwesenheits-Assistenten. Für die abwesenden Mitarbeiter lassen sich dann Zeiträume festlegen, in denen die Tickets vorübergehend an Kollegen gehen. Das legt der Admin unter »Übersichten« fest.

Genügen die Felder der Tickets den Anforderungen einer Firma nicht, kann der Admin auch eigene Felder definieren. Das gelingt, indem er in den Einstellungen unter »System | Objekte« für verschiedene Bereiche »Neue Attribute« anlegt, was wahlweise für Tickets, User, Organisationen und Gruppen möglich ist.

Über »Verwalten | Automatisierungen« darf der Admin nicht zuletzt verschiedene zeitbasierte Aktionen anlegen, die Zammad also zu einem festen Zeitpunkt für bestimmte Tickets ausführt. Welche das sind, bestimmt der Admin zum Beispiel über den Status. Ereignisbasierte Aktionen legt der Admin unter »Trigger« fest. Dazu gehören zum Beispiel automatisch generierte Antworten auf neu eintreffende Tickets. Unter »Makros« richtet er kurze Makros ein, die etwa in Aktion treten, wenn er zum Beispiel ein Ticket als Spam markiert.

REST im Boot

Zammad bietet auch ein REST-API an. Das erlaubt es etwa, sich als Nutzer anzumelden und Informationen abzufragen. Die Admin-Dokumentation zeigt verschiedene Beispiele dafür [3], wobei Zammad JSON für sein API verwendet. Bei einer lokalen Installation (hier ohne HTTPS), klappt das über:

curl -u Username:Passwort http://localhost/api/v1/users

In der Folge generiert Zammad eine Mitteilung, dass sich ein neues “Gerät” angemeldet hat, wobei Zammad Curl als Gerät nennt. Praktisch ist das dennoch, um den Überblick zu behalten, wenn Nutzer sich von verschiedenen Geräten aus anmelden.

Kommunikationskanäle

Standardmäßig kommunizieren Kunden und Mitarbeiter über E-Mail miteinander. Doch hier enden die Kommunikationsmöglichkeiten noch lange nicht. Auch Twitter, Facebook und Telegram kann der Admin an das Ticketsystem anbinden. Daneben kann er zum Beispiel eine Webform in die eigene Webseite einbetten, so dass Kunden ihre Beschwerden über Webformulare loswerden.

Auch ein Chatfenster lässt sich in die Webseite einbinden. Allerdings erscheint dieses nur, wenn tatsächlich ein Support-Mitarbeiter verfügbar ist. Zu negativ ist der Eindruck beim Kunden, wenn im angebotenen Chat nur ein Bot wartet oder lange keine Antwort von der Firma kommt. Die Chatlogs lassen sich dabei archivieren, zudem gibt es länderbasierte Sperrungen, beispielsweise abhängig von den Sprachkenntnissen der Supportmitarbeiter.

Apropos Sprachkenntnisse: Über »System | Übersetzung« behebt der Admin Fehler, auf die er in Übersetzungen stößt. Mit der Tastenkombination [Strg]+[Alt]+[T] kann er eine Inline-Übersetzung einschalten und direkt aus dem Interface heraus Wörter verändern. Das klappte im Test allerdings nicht, weil [Strg]+[Alt]+[T] auf dem Test-Linux bereits belegt war. Hier fehlt offenbar auch eine einfache Möglichkeit, den Admin-Shortcut zu ändern.

Baustellen

Zammad wirkt aus einem Guss, verwendet zeitgemäße Technologien und Plattformen und wirkt dank seiner zahlreichen nützlichen Features vielversprechend. Die Plattform wächst offenbar recht schnell, was an einigen Stellen zu bemerken ist. So gehen deutsche und englische Übersetzungen und Dokumentation auf Read the Docs [4] zum Teil noch durcheinander.

Einige Features sind zudem noch in Arbeit. Verschlüsselte E-Mails für Tickets zu verwenden, ermöglicht Zammad bislang zum Beispiel noch nicht. Allerdings sammeln projektexterne Entwickler laut Bugtracker [5] zurzeit offenbar Sponsorengelder, um einen GPG- und S/MIME-Support zu finanzieren. Das wäre auch interessant, um Tickets zu signieren.

Zudem gibt es bislang keine Möglichkeit, empfangene SMS in dem Ticketsystem auszuwerten oder Informationen per SMS an Kunden zu versenden. Laut eigener Aussage arbeiten die Entwickler aber ebenfalls schon an diesem Feature.

Preise und Support

Das Geschäftsmodell von Zammad umfasst Hosting und Support, wobei der Anbieter alle Preise und Möglichkeiten transparent auf der Seite auflistet [6].

Wer Zammad nicht selbst installieren, aktualisieren und warten möchte (inklusive Backups), zahlt pro Agent im Starterpaket monatlich 5 Euro. Es ist auf fünf Agenten beschränkt, SLAs, individuelle Rollen und Felder fehlen.

Das Professional-Modell beginnt bei 15 Euro im Monat pro Agent und ist auf 35 Agenten limitiert. Schließlich gibt es das Plus-Modell, das unter anderem einen 24/7-Support mitbringt, kein Agenten-Limit und 24 Euro pro Monat pro Agent kostet. Nutzer dürfen sämtliche verfügbaren Support-Kanäle verwenden und Reporting ist inklusive.

Wer die Zammad-Version selbst hosten möchte, kann in Sachen Support zwischen einem Business-Tarif (2300 Europro Jahr), einem Enterprise-Tarif (4900 Euro pro Jahr) und einem Corporation-Tarif (10 000 Euro pro Jahr) wählen. Der drittgenannte Vertrag schließt dann unter anderem Bug-Eskalationen, sämtliche Formen von Patches und einen Support von 8 bis 20 Uhr mit ein.

Request Tracker

Ein gut funktionierendes Perl inklusive CPAN sollten Request-Tracker-Interessenten schon auf ihrem Server vorhalten, um das gern mit RT [7] abgekürzte freie Ticketsystem installieren und betreiben zu können. Manche Rezension im Internet berichtet von heftig hakenden Inbetriebnahmen. Vermutlich stolperten die über Perl-Modul-Abhängigkeiten – der aktuelle RT 4.43 verlangt mindestens nach Perl 5.10.1, ein bei der Herstellerfirma Best Practical Solutions verlinktes Dokument [8] führt in die CPAN-Voraussetzungen und -Tests ein.

Natürlich braucht der Admin eine Datenbank, als Standard nimmt der Installer MySQL ab Version 5.1 mit Inno-DB-Support; mit Maria DB, PostgreSQL, SQLight oder Oracle DB klappts auch. Auch beim Webserver ist der RT-Server nicht wählerisch, solange der Fast-CGI unterstützt oder Mod_perl eingebunden hat. Das ausgepackte Request-Tracker-Archiv ist gerade mal 33 MByte groß, die Installation startet mit »./configure —Parameter«, ein Readme beschreibt die »make«-Schritte.

Die Dokumentation im Paket informiert auch über die Vorgehensweisen für Update und Upgrades. Apropos: Bei der Software, die es seit 1996 gibt, fallen die sehr langen Entwicklungszyklen auf: Die aktuelle Stable-Version 4.4 kam im Februar 2016 heraus, im Moment ist 4.4.3 vom Juni 2018 die neueste. Das Schneckentempo verschafft Admins allerdings auch einen massiven Vorteil: Um die sechs Jahre versorgte Best Practical Solutions in der letzten Dekade jede Version mit Updates. Die Release-Policy sagt, dass das Supportende zum Beispiel der Version 4.2 (verfügbar seit Oktober 2013) erst nach dem Erscheinen der Version 4.6 liegen wird. Solch lange Zyklen freut den Betreuer der Infrastruktur natürlich – ein Ticketsystem ist keine Komponente, die man alle Nase lang mit ungewissen Ausgang upgraden will.

RTs Web-UI

Die Weboberfläche von Request Tracker glänzt nicht gerade durch modernes Design und überraschende dynamische Features, ist im Grunde funktional gestaltet und in der aktuellen Version auch fast ausnahmslos ins Deutsche übersetzt. Aus Eingabefeldern entfaltet sich, wo sinnvoll, eine klickbare Vorgabeliste. Das horizontale Hauptmenü oben ist kontextsensitiv und wandert beim Runterscrollen mit.

Eines war für RT schon sehr früh in seiner Entwicklung selbstverständlich: PGP-Verschlüsselung und -Signieren für ein- und auch ausgehende E-Mails. Mehr noch als ums Verbergen der Inhalte geht es bei diesem Feature um Authentizität. Für den Benutzer sind auf der Oberfläche in den frei definierbaren Dashboards alle relevanten Vorgänge und Stati sofort sichtbar. Auch die Historie von Tickets ist in der Einzelticket-Ansicht am Ende auditierbar (Abbildung 3). Für Dienstleister essentiell ist, ob sie vereinbarte SLAs eingehalten haben, hierfür ist RT vorbereitet.

Abbildung 3: Wer wann was mit einem Ticket getan hat, ist in der Historie leicht erkennbar.

Einstellungssachen

Queues, Workflows, Artikel und deren Abhängigkeiten (Abbildung 4) und zeitliche Gültigkeit, die Einordnung und Behandlung von E-Mails sowie die Rollen und Rechte der Personen und Gruppen sind in weiten Teilen flexibel konfigurierbar – zweifellos eine Stärke von RT. Sogar eine Benutzergruppe als Ganzes kann Mitglied einer anderen Gruppe werden – zweifellos eignet sich Request Tracker für große Teams. So haben die Entwickler der Sprache Perl Request Tracker im Einsatz. In Deutschland soll es bei Hostern und Softwareherstellern beliebt sein. Hinzu kommen als Perl-Code hinterlegte so genannte Scrips (das “T” fehlt wirklich), die sich der Benutzer auf der Weboberfläche zusammenklickt. Ein Scrip kann das RT-API benutzen, um Ereignissen im System eine Sequenz von Aktionen zuzuweisen.

Für Administratoren verbergen sich alle relevanten Einstelloptionen im Menü »Admin«. Hier automatisieren sie Prozesse, verwalten SLAs und Eskalationsstufen. Die einzelnen, sehr zahlreichen Untergruppen gestatten auch die gesamte Systemverwaltung inklusive der Rechtevergabe an Agenten und der Kommunikationseinstellungen.

Abbildung 4: Tickets, aber auch Queues und Workflows, Artikel und so weiter pflegen in RT Beziehungen zu anderen Komponenten.

Erweiterungen

Einerseits durch die lange Produktgeschichte und andererseits durch Perl mit seinen vielen verfügbaren Modulen muss sich die Überraschung, dass es eine Menge Erweiterungen für RT gibt, in Grenzen halten. Unter der Such-URL [9] tauchen mehr als 100 Fundstellen für in Perl verfasst Extensions auf, die mit »RT::Extension::« beginnen. Der praktische Nutzen ist freilich nicht ganz klar, da ein erheblicher Teil davon schon länger keine Codepflege mehr erhalten hat. Der Anwender muss also von Fall zu Fall prüfen, ob das gefundene Modul noch in seiner RT-Version Dienst funktioniert.

Request Tracker for Incident Response

Parallel zu RT bietet Best Practical Solutions das Produkt RTIR an – ebenfalls frei lizensiert. Das Kürzel steht für Request Tracker for Incident Response und ist mit RT weitgehend Code-identisch. Der hauptsächliche Unterschied besteht darin, dass die Queues, Workflows und Reports von RTIR für ein Incident Management (IT-Störungsmanagement) vorkonfiguriert sind. Die Software richtet sich vor allem an CERTs und CSIRTs (Computer Emergency und Computer Security Incident Response Teams).

Preise und Support

Best Practical Solutions ist keine Open-Source-Firma, die Quasi-Nutzungsrechte pro CPU-Core und User als Service getarnt lzensiert. Das Geschäftsmodell der Amerikaner besteht tatsächliche aus drei Supportpaketen, von denen die Nutzung der Software unabhängig ist. Außerdem kann man Schulungen buchen. Europa jedoch besteht diesbezüglich im Wesentlichen aus weißen Flecken, die Homepage kündigt vage für das Frühjahr 2019 in Italien eine Veranstaltung an.

Die Ausgestaltung der drei Supportstufen (5000, 20 000 und 60 000 US-Dollar) beschreibt [10] ausführlich. Es scheint, dass Anwender sich auch individuelle Programme oder Einzelaktionen anbieten lassen können. Docker-Files oder vorinstallierte VM-Images stehen auf der Homepage keine bereit. Neben dem Quellcode gibt es aber registrierungsfrei einen Demo-Account.

OTRS

Open Technology Real Services [11] ist ein Veteran unter den Ticketsystemen, ursprünglich entwickelt von Martin Edenhofer, der auch Autor des späteren Konkurrenten Zammad ist. Edenhofer begründete 2003 die OTRS GmbH mit, die 2007 in der OTRS AG aufging, zu deren Vorstand oder Aufsichtsrat er heute aber nicht mehr gehört. Derzeit bietet die Firma das Produkt weiter unter Open-Source-Lizenz sowohl in einer kostenfreien Community Edition [12] an, als auch bei verschiedenen Hostern, als auch durch die OTRS AG. Die gehört inzwischen zu einer Firmengruppe mit 100 Mitarbeiter und Niederlassungen in den USA, Mexiko, Deutschland, Brasilien, Hongkong, Singapur und Ungarn.

Nach ihren Angaben sollen weltweit um die 170 000 Organisationen OTRS nutzen, darunter Toyota, Huawei, Lufthansa, Airbus, IBM, Porsche oder Siemens. Die Firma selbst offeriert eine Art SaaS-Variante (“Konzeptionell betreute Lösung”) mit Hard- und Softwarewartung. Außerdem sind etliche jeweils neue Features exklusiv nur in dieser kommerziell vermarkteten Version nutzbar.

Komplette Palette

OTRS unterstützt den kompletten Arbeitsablauf eines Helpdesk von der Kundenverwaltung, über die Annahme von Anfragen und die Eröffnung eines Tickets (Abbildung 5) via SMS, Telefon, Chat, E-Mail oder Kunden-Portal im Internet, über die Sortierung und Priorisiserung der Tickets, alle Stadien ihrer Bearbeitung, individuelle und automatische Benachrichtigungen bis zum Reporting und der Erstellung von Statistiken (Abbildung 6). OTRS arbeitet dabei revisionssicher, was bedeutet, dass sich alle Aktionen jederzeit nachvollziehen lassen und einmal eingegebene Daten nachträglich nicht mehr löschbar sind.

Abbildung 5: Ansicht eines Tickets in der Weboberfläche von OTRS 6.

Abbildung 6: Für die Auswertung der Arbeit mit dem Help Desk stehen zahlreiche vorgefertigte Berichte bereit.

Sicherheit und Rechte

Ein besonderes Augenmerk legt OTRS auf die Datensicherheit. So lassen sich E-Mails und Benachrichtigungen mit S/MIME oder PGP verschlüsseln, Daten sind auf dem Übertragungsweg mit SSL schützbar. Ein Rollen-, Gruppen- und ACL-gestütztes Rechtemanagement sorgt in Verbindung mit einer Zwei-Faktor-Authetifizierung dafür, dass nur Berechtigte auf sensible Informationen zugreifen.

Die Software kann Agenten anhand spezieller Workflows (Prozesse) durch den Bearbeitungsablauf eines Tickets leiten und dabei kundenspezifische Formulare verwenden oder eine Wissensdatenbank anbieten. Dabei lassen sich Lösungszeiten anhand der Vorgaben aus SLAs überwachen und der Vorgang bei Bedarf eskalieren. Es existieren Schnittstellen zu anderen Softwarelösungen wie SAP, Baramundi, Jira oder Bugzilla oder zu Monitoringsystemen wie Nagios oder Icinga.

OTRS ist in weiten Grenzen konfigurier- und erweiterbar. Das äußere Erscheinungsbild lässt sich passend zur Corporate Identity gestalten, individuelle Dashboards oder Felder in Tickets oder in Kundendatenbanken sind möglich und über Protokolle wie SOAP, REST oder SQL sind weitere Anwendungen mit OTRS koppelbar.

Kix

Kix ist als browserbasiertes System für Linux und Windows verfügbar. Der Nutzer findet auf der Kix-Webseite [13] für die im Unternehmensbereich gängigen Linux-Gespanne wie Ubuntu und Debian, Open Suse und Suse Linux Enterprise, Centos und Red hat Enterprise Linux fertige Pakete. Als Open-Source-Software steht Kix auch in den Quellen bereit. Für Windows-Instanzen ist eine Exe-Datei vorhanden.

Das als Fork von OTRS 5 entstandene Kix war zuvor nach Angaben des Herstellers Cape IT, als größtes aus der Communitie beigesteuertes OTRS-Modul »KIX4OTRS« bekannt. Im Jahr 2015 forkte Cape IT OTRS und stellt im darauffolgenden Jahr Kix erstmals auf der Cebit vor. Kix ist als Baisversion und als Kix Professional [14] zu haben. Kix Professional gilt mit einigen Zusatzmodulen versehen als die Out-of-the-Box-Lösung für einen schnellen Einstieg in den ITIL-konformen Service. Mit Kix Professional MRO (Maintenance, Repair, Overhaul) gibt es noch eine weitere Ausführung, die speziell auf die Verwaltung von Maschinen und Produktionsanlagen ausgelegt ist.

Kix bietet durch den Fork den Umfang von OTRS 5 und sucht sich durch diverse Zusatzmodule und Services sein Alleinstellungsmerkmal. Das Ticketsystem (Abbildung 7) kann der Kunde sich dann etwa auch komplett vom Hersteller betrieben bestellen und auf seine Bedürfnisse anpassen lassen.

Abbildung 7: Klassische Aufgabe für Kix: Das Anlegen eines Tickets. © Cape IT

Es geht voran

Seit dem Fork hat sich Kix stetig weiterentwickelt. Es steht aktuell ein weiteres Featurerelease auf Version 17.4 an, das zum Erscheinen des Hefts bereits verfügbar sein sollte, das Zwischenrelease in der Version 2017 soll Volltextsuche auf Attachments mitbringen. Die in Entwicklung befindliche neue Major-Version Kix 2018 soll bei der Anwenderkonferenz zum Jahresende präsentiert werden.

Laut dem Anbieter bringt das neue Kix dann ein komplett überarbeitetes grafisches Benutzerinterface mit. Zudem will Cape IT die Kernanwendung überarbeiten. Das Performance-Verhalten sei teilwiese nicht mehr zufreiedenstellend gewesen, teilt das Untrnehmen mit. Das habe am technisch teils veralteten Unterbau gelegen. Mit Version 18 soll sich das ändern, indem Cape IT mit einem neuen Ansatz zwischen Applikationskern und den verschiedenen Frontends trennen will. Zudem stelle die neue Ausgabe ein vollständiges REST-API mit differenzierbaren Berechtigungen bereit.

Testbetrieb

Kix lässt sich als lokale Installation (On-premise) oder in der Cloud betreiben. Interessierten bietet Cape IT eine Online-Testversion [15] an, die sich auf Wunsch auch gleich mit Beispieldaten füllt. Der Test ist unverbindlich, erfordert aber Angabe von Kontaktaktdaten und einer E-Mail-Adresse. Die ist für die Übermittlung der Zugangsdaten nötig. Zudem steht ein Docker-Image zur Verfügung, das abernur für Kix in der freien Baisversion. Die Online-Testmöglichkeiten basieren auf Kix Professional und liefert auch die kostenpflichtigen Zusatzmodule mit.

Kix kann mit den gängigen Datenbank (Abbildung 8) umgehen und unterstützt PostgreSQL, MySQL, Maria DB und auch Oracle. Windows-Admins können auch den SQL-Server von Microsoft einsetzen. In der Kompatibilitätsmatrix des ITSM-Systems lassen sich die Grundvoraussetzungen für die beteiligten Datenbanken ablesen. Zudem sind dort auch die kompatiblen Betriebssysteme und Browserversionen genannt. [16]

Ohne besondere Vorgabe kommt Kix mit der PostgreSQL-Datenbank an Bord. Soll stattdessen MySQL zum Zuge kommen, muss der Admin bei der Installation noch Umgebungsvariablen setzen, damit Kix dann den MySQL-Nutzer und die MySQL-Datenbank anlegt. Der Anbieter weist daraufhin, beim Einrichten des MySQL-Administrator-Passwortes zwingend dasjenige einzugegeben, das bereits mit der Einrichtung der Umgebungsvariablen »KIXMYSQL_PASSWORD« ins Spiel kam.

Kommt Maria DB zum Einsatz, hängt der Administrationaufwand von der Art der Datenbankinstallation ab. Erfolgte diese unter dem Root-Nutzer, kann der sich ohne Passwort am Maria-DB-Server anmelden. In dem Fall sei es nicht nötig, die Umgebungsvariablen zu setzen, teilt der Hersteller mit.

Abbildung 8: Das Nutzerinterface der Gerätedatenbank in Kix. © Cape IT

Erweiterungsmöglichkeiten

Nach der Installation ist Kix einsatzbereit und über eine URL »/kix/index.pl« erreichbar. Für eine erste Anmeldung steht ist ein vorkonfigurierte Administrator-Nutzer »root@localhost« bereit.

Das Prinzip der freien Software setzt Kix möglichst auch bei den Schnittstellen fort und bietet Support für eine Reihe davon. Es unterstützt unter anderem LDAP, CSV, REST, Json und SOAP. Auf der Admin-Konsole lassen sich zudem Skripte ausführen, etwa um eigene Prüfungen durchzuführen. Kix bietet dem Admin zudem die Option, seine CRM-, ERP- und Monitoringsysteme zu integrieren. Über ein eingebautes Integrationsmodul kann er zudem Tools für die technische Adminis-tration ausführen, etwa für den Fernwartungszugriff per VNC und SSH.

Migration

Da der Fork von Kix auf OTRS 5 basiert, ist die Migration von OTRS zu Kix laut dem Machern eine einfache Sache. Allerdings müssen dafür zwei Voraussetzungen erfüllt sein:

• Das Ausgangssystem muss eine OTRS-Version 5 sein.
• Die Engines von Ausgangs- und Ziel-Datenbank müssen gleich sein, da ein Datenbank Ex- und Import stattfindet.

Der Administrator muss zudem darauf achten, dass diverse Pakete in der Ausgangsinstallation von OTRS vorhanden sind, etwa »ITSMCore«, »ITSMConfigurationManagement« und »ITSMIncidentProblemManagement«. Die Migration selbst läuft dann über ein Skript ab. Ein ähnlicher Weg führt auch zu einem Upgrade von Kix 2016 auf Kix 2017.

Für die Versionen Kix Professional und Kix MRO verläuft die Migration von OTRS dagegen nicht auf diese Weise, weil die Professional-Ausgabe diverse Zusatzmodule mitbringt, die in OTRS nicht enthalten sind. Admins sollten sich für einen solchen Migrationsplan dann überlegen, ob sie den Support des Herstellers bemühen. Der Migrationsleitfaden findet sich jeweils nach der Installation von Kix im Verzeichnis »/opt/kix/MIGRATING_OTRS.md« zum nachlesen.

Vorläufiges Fazit

Ohne der Bewertung der Oberflächen und Kommunikationskanäle aus Sicht der Ticketbearbeiter (Agenten) sowie der Hilfesuchenden (Kunden) vorgreifen zu wollen, die in den hier folgenden beiden Artikeln passiert lässt sich als Zwischenfazit Folgendes sagen: OTRS hat bei den Open-Source-Ticketsystemen im deutschsprachigen Raum eine Vormachtstellung inne – und das nicht von ungefähr. Die lange Präsenz und der Funktionsreichtum haben zu einer sehr breiten Userbase geführt, die ihrerseits einen eigenen Wert darstellt. Insoweit kann sich der Interessent schlicht ergooglen, inwieweit andere OTRS-Anwender, die in derselben Branche wie er selbst tätig sind, zufrieden sind.

Eher von Unzufriedenheit mit OTRS hat wohl den Kix-Anbieter Cape IT dazu veranlasst, seinen OTRS-Fork auf den Weg zu bringen. Inzwischen sind die Chemnitzer mit dem Umbau nach eigenen Vorstellungen schon recht weit.

Wer auf seine Kunden sowieso im Social Web trifft und sich an den flotten Entwicklungssprüngen von Zammad eher freut, der sollte eine Installation des Newcomers ein paar Wochen als Begleiter laufen lassen. Ob die Fahrt in eine lichte Zukunft führt, kann zwar keiner sagen. Bisher jedoch stimmt die Richtung.

Das pure Gegenteil von Zammat offeriert Request Tracker. Die Wahrscheinlichkeit, dass es die Software in zehn oder gar 20 Jahren noch geben wird, ist hoch. UI-Optisch eher gewöhnlich und in Sachen hipper Features unverdächtig, punkten die Amerikaner mit einem sehr hohen Reifegrad und Enterprise-Features. Tabelle 1 fasst die Eckdaten der vier Kandidaten nochmal zusammen.