Ticketsysteme in der Praxis: JIRA, Freshservice, OTRS
Ein Ticketsystem ist die technische Umsetzung dessen, was die vorigen Lektionen konzeptionell beschrieben haben: Incident Management, Problem Management, Change Management, Service Desk, SLM. Ohne Tool zerfällt das in Mail-Threads und Excel-Listen – mit Tool wird daraus ein nachvollziehbarer Prozess mit Suche, Auswertung und Automatisierung. Diese Lektion zeigt dir den typischen Aufbau eines Tickets (Felder, Workflow), die wichtigsten am Markt verfügbaren Produkte – JIRA Service Management, Freshservice und OTRS als Vertreter unterschiedlicher Ansätze – und Auswahl-Kriterien für die Tool-Entscheidung. Was du nicht hier lernst: Bedienung im Detail. Das ist Hersteller-spezifisch und lernt sich am besten am System selbst.
1) Was steht in einem Ticket?
Egal welches Tool – die Felder sind weitgehend gleich. ITIL definiert die wichtigsten Tickettypen und welche Felder pro Typ relevant sind:
| Tickettyp | Beispiel | Spezielle Felder |
|---|---|---|
| Incident | „Mail funktioniert nicht" | Severity, Impact, Urgency, Affected CI, Workaround |
| Service Request | „Neue Mailbox bitte" | Service Catalog Item, Approval Status, Beneficiary |
| Problem | „VPN-Zertifikat-Fehler häuft sich" | Related Incidents, Root Cause, Workaround, Status (RCA in progress / Known Error / Resolved) |
| Change | „Firmware-Update Switch core-3" | Change Type, Risk Assessment, CAB Approval, Implementation Plan, Backout Plan |
| Knowledge Article | „Wie setze ich mein Passwort zurück?" | Author, Visibility (intern/extern), Tags, Review-Datum |
Pflicht-Felder in jedem Ticket: ID, Betreff, Beschreibung, Erfasser, Erstellungsdatum, Status, Priorität, Zuständiger, betroffener Service. Optional, aber oft sinnvoll: Affected CI (Verbindung zur CMDB), gewünschter Erledigungstermin, SLA-Frist (automatisch aus Priorität abgeleitet), Anhänge.
2) Der Ticket-Lifecycle
Jedes Ticket durchläuft einen festen Workflow. Die Status-Namen können variieren, aber das Modell ist überall ähnlich. Klick die Stati an, um zu sehen, was in jeder Phase passiert:
3) Die wichtigsten Tools am Markt
Klick die Tools an, um Details zu sehen. Jeder hat seinen Sweetspot und einige typische Schwächen:
4) Auswahlkriterien
Wie entscheidet man, welches Tool? Eine Checkliste, die in jedes Auswahlverfahren gehört:
| Kriterium | Worum es geht |
|---|---|
| ITIL-Konformität | Sind die ITIL-Kerntypen out-of-the-box dabei? PinkVerify-Zertifizierung der Hersteller hilft als Indiz. |
| Unternehmensgröße | Kleine Teams: schlanke Cloud-Tools (Freshservice). Konzerne: ServiceNow oder BMC. |
| Hosting | Cloud (schneller Start, geringer Aufwand, Datenschutz prüfen) vs. On-Premises (volle Kontrolle, höherer Aufwand). Bei sensiblen Daten oft On-Premises Pflicht. |
| Integration | Wie gut spielt es mit AD, CMDB, Monitoring, Mail, Confluence/SharePoint zusammen? |
| Self-Service-Portal | Wie sieht es aus, ist es responsive, wie viele Sprachen? |
| Reporting & KPIs | Vorgefertigte Dashboards? Eigene KPIs einfach anlegbar? |
| Automatisierung | Workflow-Engine, SLA-Regeln, Eskalation, Ticket-Routing per Conditions? |
| Mobile | Native App? Wie nutzbar für Außendienst-Agents? |
| Lizenz / Kosten | Pro Agent, pro Endanwender, pro Ticket? Versteckte Kosten (Add-ons, Storage)? |
| Anpassbarkeit | Custom-Felder, Custom-Workflows, eigene Statusübergänge? |
| API / Erweiterbarkeit | REST-API für eigene Integrationen, Webhook-Support? |
| DSGVO / Compliance | Wo werden Daten gespeichert? AVV? Bei EU-Datenschutz Pflicht. |
5) Workflow-Automatisierung – die größte Hebelwirkung
Moderne Ticketsysteme können viel mehr als nur Ticket-Eingabe und -Anzeige. Drei Automatisierungs-Pattern, die du kennen solltest:
- SLA-Eskalation. Wenn ein Prio-1-Ticket nach 15 Min. keine Reaktion hat → automatisch an Teamleiter eskalieren. Nach weiteren 30 Min. → an Manager. Spart manuelles Beobachten.
- Auto-Routing. Ein Ticket mit Schlagworten „VPN", „Verbindung" geht automatisch an das Netzwerk-Team; eines mit „Drucker" an Hardware-Support. Spart 1st-Level-Triage.
- Self-Service mit Approval-Flow. „Ich brauche eine neue Mailbox" → Antrag im Self-Service → automatische Vorgesetzten-Genehmigung → Erzeugung durch Ansible/Skript → User wird informiert. Ohne Menschen-Beteiligung im Service Desk.
Diese Patterns gehören zur „Optimize and automate" der ITIL-Grundprinzipien – aber Vorsicht: erst den Prozess verstehen, dann automatisieren. Schlecht gestaltete Workflows automatisiert man besser nicht.
6) Datenschutz und Ticketsysteme
Ein Ticket-System verarbeitet praktisch immer personenbezogene Daten – Namen, Mailadressen, IPs, manchmal Inhalte (Screenshots können Patientendaten, Vertragsentwürfe etc. enthalten). Konsequenz:
- Aufbewahrungsfristen klären. Wie lange dürfen geschlossene Tickets archiviert werden? Typisch 1-3 Jahre für operative Tickets, länger nur bei rechtlich begründbarem Bedarf. In den TOMs dokumentieren.
- Zugriff einschränken. Wer sieht welche Tickets? RBAC für Agents, Project-basierte Sicht.
- Auftragsverarbeitungsvertrag bei Cloud-Tools. Bei JIRA Cloud, Freshservice etc. läuft die Verarbeitung auf Hersteller-Servern – AVV mit dem Anbieter ist Pflicht (Art. 28 DSGVO).
- Recht auf Löschung. Wenn ein Ehemaliger sein Recht auf Vergessenwerden geltend macht, müssen seine Daten gefunden und gelöscht werden können – auch in geschlossenen Tickets.
- Beschäftigtendatenschutz. Performance-Auswertungen anhand von Ticket-Statistiken sind Leistungskontrolle – das braucht Betriebsrat-Beteiligung. Mehr in Beschäftigtendatenschutz.
7) Anti-Patterns in der Praxis
- Ticket-Friedhof. Tausende Tickets im Status „Closed-Won't-Fix" oder „Stale" – niemand schaut mehr rein. Lösung: regelmäßige Audits, klare Archivierungs-Regeln.
- Workflow-Wahnsinn. 12 Stati, 30 Pflichtfelder, mehrstufige Genehmigungen für jeden Triviafall. Agents lernen, das System zu umgehen.
- Eigenes Ticket-Universum pro Team. Netzwerk-Team nutzt JIRA, Server-Team OTRS, Helpdesk Freshservice. Wenn ein Ticket eskaliert wird, beginnt der Sport „mein Tool spricht nicht mit deinem". Lösung: ein zentrales System, Subprojekte für Teams.
- SLA-Reset-Spielchen. Agents schließen Tickets vorzeitig, um SLA-Statistik zu schönen. Lösung: ehrliche Lösungs-Bestätigung durch User, Reopen-Quote messen.
- Self-Service ohne Kommunikation. User wird zu Self-Service-Portal genötigt, das aber nicht beworben, nicht geschult und nicht intuitiv ist. Resultat: alle rufen weiter an. Lösung: gutes Onboarding, Akzeptanz-Test.
Zusammenfassung
Ticketsysteme sind die technische Umsetzung der ITIL-Practices. Standardtypen: Incident, Service Request, Problem, Change, Knowledge Article. Standardfelder pro Ticket: ID, Betreff, Status, Priorität, Zuständiger, betroffener Service, Affected CI. Lifecycle: New → In Progress → Pending/Resolved → Closed (mit möglichem Reopen). Marktübersicht: JIRA Service Management (entwickler-nah, anpassbar, mittlere bis große Setups), Freshservice (cloud-natives Komfort-Tool, schneller Start, SaaS), OTRS/Znuny (Open Source mit Enterprise-Variante, behördentauglich, On-Premises), zusätzlich Markt-führer ServiceNow. Auswahl-Kriterien: ITIL-Konformität, Unternehmensgröße, Cloud vs. On-Premises, Integration, Reporting, Automatisierung, Lizenzmodell, DSGVO. Workflow-Automatisierung als Hauptnutzen: SLA-Eskalation, Auto-Routing, Self-Service-Approvals. Antipatterns: Ticket-Friedhof, Workflow-Wahnsinn, Tool-Inseln pro Team, SLA-Schönrechnen, Self-Service ohne Schulung.
Verwandte Lektionen: Service Desk · Incident Management · Ticket-Priorisierung · und mehrWeitere relevante LektionenChange ManagementProblem ManagementSLACMDBTOMsRBACAnsible