Ein Ticketsystem löst keine organisatorischen Probleme

Das sichtbare Problem ist selten nur das Ticketsystem

Tickets kommen auf Zuruf, per Telefon oder per E-Mail. Ein Teil der Arbeit steht im System, ein anderer Teil in persönlichen Postfächern oder in den Köpfen einzelner Administratoren. Nutzer fragen nach dem Bearbeitungsstand, während die IT selbst kaum belastbar sagen kann, welche Vorgänge offen sind und was als Nächstes bearbeitet werden muss.

In dieser Situation liegt der Gedanke nahe, das Ticketsystem auszutauschen. Das vorhandene Werkzeug wirkt unübersichtlich, wird nicht konsequent genutzt oder bildet die gewünschte Arbeitsweise nicht ab. Trotzdem ist der Toolvergleich häufig die falsche erste Reaktion. Ein neues System löst nicht automatisch, was die Organisation vorher nicht entschieden hat.

Das bedeutet nicht, dass das Werkzeug gleichgültig wäre. Es bedeutet: Bevor die IT ein Produkt bewertet, muss sie wissen, welches Problem es lösen, welchen Prozess es unterstützen und welche verbindlichen Regeln es abbilden soll.

Vor dem Toolvergleich stehen drei organisatorische Fragen

Die erste Frage lautet nicht: Welche Funktionen fehlen? Sie lautet: Verstehen IT-Team und Fachbereiche überhaupt, warum sich die Arbeitsweise ändern soll? In Projekten habe ich erlebt, dass die Notwendigkeit einer ITSM-Veränderung im Team nicht gesehen oder nicht verstanden wurde. Gleichzeitig waren Prozesse und selbst grundlegende Definitionen noch unklar. Unter diesen Voraussetzungen wird jede Tooldiskussion unscharf.

Danach müssen mindestens drei Dinge geklärt werden:

1. Welches konkrete Problem soll gelöst werden?
2. Wie soll der verbindliche Ablauf vom Eingang bis zum Abschluss aussehen?
3. Wer entscheidet, priorisiert, genehmigt und verantwortet Ausnahmen?

Erst diese Antworten ergeben prüfbare Anforderungen. Ohne sie entsteht schnell ein langer Funktionskatalog, in dem persönliche Wünsche und tatsächliche betriebliche Notwendigkeiten gleich behandelt werden.

Ein Hinweis auf ein Organisationsproblem ist für mich, wenn vergleichbare Organisationen eine ähnliche Aufgabe mit demselben oder einem ähnlich ausgestatteten Werkzeug lösen konnten, dafür aber ihre Prozesse und Zuständigkeiten angepasst haben. Das beweist noch nicht, dass das vorhandene Tool geeignet ist. Es zeigt jedoch, dass Konfiguration und Produktwechsel nicht die einzigen möglichen Stellhebel sind.

Rollen müssen vor den Berechtigungen geklärt sein

Ein Ticketsystem bildet nicht nur Arbeitsschritte ab. Es setzt auch Entscheidungsrechte technisch um. Deshalb dürfen Rollenbeschreibung, Prozessverantwortung und Systemberechtigung nicht unabhängig voneinander entstehen.

In dem von mir bevorzugten Organisationsmodell definiert HR die Stellen- und Rollenbeschreibungen einschließlich der vorgesehenen Tätigkeiten. Der ITSM Owner verantwortet das übergreifende Modell. Die jeweiligen Prozess Owner legen fest, wie ein Prozess funktioniert und wer darin welche Entscheidung treffen darf. Diese Verantwortung kann je nach Organisation bei Team- oder Abteilungsleitungen und in bestimmten Fällen bei der Geschäftsführung liegen.

Beim Change Enablement muss beispielsweise zwischen Wunsch, Antrag, Bewertung und Autorisierung unterschieden werden. Nicht jeder, der eine Änderung anstoßen möchte, darf sie deshalb auch freigeben. Ein Change-Prozess ist kein „Wünsch-dir-was“, sondern soll Änderungen kontrollierbar machen. Die offizielle ITIL-4-Beschreibung von Change Enablement stellt entsprechend Risikobewertung, Autorisierung und Change-Planung in den Mittelpunkt.

Wenn diese Entscheidungsrechte fachlich nicht geklärt sind, kann das Tool sie nur zufällig, widersprüchlich oder nachträglich politisch abbilden. Dann digitalisiert die Organisation ihre Unklarheit.

Wie aus einer benannten Rolle ein belastbares Entscheidungsrecht, eine passende Berechtigung und ein nachvollziehbarer Eskalationsweg werden, vertieft der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“.

Schulung informiert – sie erzeugt noch keine Anwendung

Schulungen sind notwendig, wenn neue Begriffe, Abläufe oder Funktionen verstanden werden müssen. Sie können erklären, wie ein Incident erfasst oder ein Change beantragt wird. Sie können aber kein Interesse erzwingen und keine Gleichgültigkeit beseitigen.

Nach meiner Erfahrung funktioniert deshalb ein reines Onboarding auf ein neues System oder ein Framework wie ITIL in der Regel nicht. Wer keinen Nutzen erkennt oder den neuen Ablauf für unverbindlich hält, überträgt das Gelernte nicht zuverlässig in die tägliche Arbeit.

Ich unterscheide deshalb drei Stufen von Befähigung und Verbindlichkeit:

1. Empowerment: Die Mitarbeitenden verstehen Problem und Ziel, erhalten die notwendigen Fähigkeiten und können die neue Arbeitsweise sinnvoll anwenden.
2. Bewusst gestaltete Folgen: Wer den vereinbarten Prozess ohne legitimen Ausnahmegrund umgeht, darf dadurch keinen einfacheren oder bevorzugten Weg erhalten. Regeln müssen transparent, verhältnismäßig und mit den organisatorischen sowie rechtlichen Rahmenbedingungen vereinbar sein.
3. Formale Anweisung: Wenn eine notwendige Arbeitsweise trotz Befähigung und klarer Regeln dauerhaft verweigert wird, muss die Geschäftsführung sie verbindlich anweisen und die Führungsverantwortung übernehmen.

Auf ein Ticketsystem übertragen könnte die zweite Stufe bedeuten: Normale Serviceanfragen außerhalb des vereinbarten Kanals erhalten keine bevorzugte Zurufbearbeitung, sondern werden in den regulären Eingang überführt. Für echte Störungen und Notfälle braucht es weiterhin eindeutig definierte Ausnahmen. Sonst wird aus Prozessdisziplin ein Betriebsrisiko.

Die letzten beiden Stufen sind keine Motivation im engeren Sinn. Sie schaffen Verbindlichkeit. Diese Unterscheidung ist wichtig, weil Akzeptanz nicht mit Gehorsam verwechselt werden sollte.

Ein pragmatischer ITSM-Kern reicht häufig aus

Mittelständische IT-Organisationen benötigen nicht jede ITIL-Praxis in voller Ausprägung. Besonders hilfreich sind aus meiner Sicht zunächst drei Bereiche:

• Incident Management, um den normalen Servicebetrieb nach Störungen möglichst schnell wiederherzustellen,
• Change Enablement, um Risiken zu bewerten, Änderungen zu autorisieren und ihre Umsetzung zu koordinieren,
• Problem Management, um Ursachen wiederkehrender oder potenzieller Incidents zu bearbeiten.

„Pragmatisch“ darf dabei nicht „beliebig“ bedeuten. Ein vereinfachter Prozess braucht weiterhin einen erkennbaren Eingang, klare Verantwortung, wenige verständliche Zustände und ein definiertes Ende. Weggelassen wird, was keinen ausreichenden Nutzen bringt – nicht das, was für Steuerbarkeit und Verantwortung notwendig ist.

Auch ISO/IEC 20000-1:2018 betrachtet Service Management nicht als einmalige Toolinstallation, sondern als Managementsystem, das geplant, umgesetzt, überwacht und fortlaufend verbessert wird. Daraus folgt nicht, dass ein mittelständisches Unternehmen die Norm vollständig umsetzen muss. Die Systemperspektive ist dennoch hilfreich: Prozesse, Menschen, Verantwortung, Information und Werkzeug wirken zusammen.

Wirkung muss beobachtbar werden

Die Einführung eines Systems ist noch kein Ergebnis. Entscheidend ist, ob sich die Arbeit messbar oder zumindest nachvollziehbar verbessert.

Für den Einstieg halte ich vier Beobachtungen für sinnvoll:

• Wie lange dauert es vom Eingang bis zur ersten qualifizierten Reaktion?
• Wie lange dauert es bis zur Wiederherstellung oder tatsächlichen Lösung?
• Treten weniger vermeidbare Fehler in der Bearbeitung auf?
• Werden weniger Vorgänge vergessen oder nur durch Nachfragen wieder sichtbar?

Response- und Resolve-Zeiten sind nur brauchbar, wenn Start, Ende und Unterbrechungen einheitlich definiert sind. Auch Priorität und Auswirkung müssen berücksichtigt werden. Eine kurze Durchschnittszeit sagt wenig aus, wenn kritische Incidents darin mit einfachen Anfragen vermischt werden.

Bei Fehlern und vergessenen Vorgängen ist zunächst nicht zwingend eine perfekte Kennzahl nötig. Eine nachvollziehbare Ausgangslage, ein begrenzter Beobachtungszeitraum und eine konsequente Nachschau können für die erste Entscheidung ausreichen. Scheingenauigkeit hilft nicht; fehlende Beobachtung aber ebenso wenig.

Ein Praxismuster: Transparenz vor Optimierung

In einem Projekt wurden Tickets unübersichtlich auf Zuruf, telefonisch oder per E-Mail abgearbeitet. Dadurch fehlte nicht nur der IT der Gesamtüberblick. Auch die Nutzer wussten nicht zuverlässig, ob ihr Anliegen aufgenommen worden war oder welchen Stand es hatte.

Mit einem selbst entwickelten Ticketsystem entstand ein gemeinsamer Informationsstand. Administratoren und Nutzer erhielten fortlaufende Informationen über ihre Tickets. Dadurch wurde sichtbar, woran die IT arbeitete und wie die Bearbeitung voranging.

Dieses Beispiel ist kein Beleg dafür, dass ein selbst entwickeltes System grundsätzlich besser ist. Es liegen auch keine belastbaren Vorher-nachher-Zahlen vor, aus denen sich eine bestimmte Effizienzsteigerung ableiten ließe. Der beobachtete Nutzen lag zunächst in der Transparenz. Genau diese Transparenz ist jedoch eine Voraussetzung, um Arbeitsweise, Engpässe und Wirkung überhaupt beurteilen zu können.

Wann ein Toolwechsel trotzdem richtig ist

Ein Toolwechsel ist gerechtfertigt, wenn das vorhandene System die grundsätzlichen Anforderungen nicht erfüllen kann. Dafür müssen diese Anforderungen vor der Produktauswahl verbindlich beschrieben und priorisiert werden.

Die entscheidende Prüfung lautet nicht, ob ein anderes Produkt mehr Funktionen besitzt. Sie lautet, ob das vorhandene Werkzeug einen notwendigen Ablauf, ein erforderliches Rollen- und Berechtigungsmodell oder eine andere unverzichtbare Rahmenbedingung auch bei angemessener Konfiguration nicht abbilden kann.

Vor einer Entscheidung sollte die IT-Leitung deshalb dokumentieren:

• welche Anforderung zwingend ist,
• welcher betriebliche Schaden oder welches Risiko bei Nichterfüllung entsteht,
• ob Prozessvereinfachung oder Konfiguration die Lücke vertretbar schließen kann,
• und anhand welcher Abnahmekriterien ein neues Tool die Anforderung tatsächlich erfüllt.

Kann das bestehende System eine solche Grundanforderung nicht erfüllen, ist der Toolwechsel keine Flucht vor der Organisationsarbeit. Er ist eine begründete technische Entscheidung. Fehlen dagegen Problemdefinition, Prozess und Verantwortung, wird ein neues Produkt voraussichtlich nur eine neue Oberfläche für dieselbe Unklarheit liefern.

Die bessere Entscheidung beginnt vor der Produktauswahl

Ein Ticketsystem kann Sichtbarkeit, Verbindlichkeit und Steuerbarkeit erheblich verbessern. Es kann aber nicht selbst entscheiden, was wichtig ist, wer Verantwortung trägt und welche Regeln im Alltag gelten.

Vor dem nächsten Toolvergleich sollte eine IT-Leitung deshalb zuerst das Problem, den gewünschten Ablauf, die Rollen, die verbindlichen Folgen und die erwartete Wirkung festhalten. Danach lässt sich unterscheiden, ob die Organisation ihren Prozess schärfen, die Einführung konsequenter führen oder tatsächlich das Werkzeug ersetzen muss.