Nicht jede Störung braucht ein Formular: ITSM im Mittelstand zwischen Serviceportal und Selbstzweck

Ein Ticketsystem gehört zu den Werkzeugen, die sich in kleinen IT-Teams besonders schnell verselbstständigen. Die erste Woche ist von Ordnung geprägt: Jede Anfrage bekommt eine Nummer, jede Störung einen Status. Nach einigen Monaten existieren dann mehrere Eingänge, widersprüchliche Prioritäten und Berichte, die niemand liest. Aus einem Servicewerkzeug ist ein Formularfriedhof geworden.

Das Problem ist selten die Software allein. Es liegt meistens an fehlenden Regeln: Wer darf ein Ticket schließen? Wann eskaliert eine Störung? Welche Anfrage ist ein Incident, welche ein Service Request? Und welche Informationen braucht die IT, um ohne Rückfrage arbeiten zu können? Wer diese Fragen nicht beantwortet, automatisiert nur die Unordnung.

Vier typische Muster in kleinen IT-Teams

Das Schatten-ITSM per Mailpostfach. Anfragen kommen per E-Mail, Telefon, Chat und Zuruf. Ein Ticket wird nur angelegt, wenn jemand daran denkt. Das funktioniert bei sehr kleinen Teams, solange alle Beteiligten nah beieinander sitzen. Sobald Homeoffice, Teilzeit oder externe Dienstleister hinzukommen, gehen Zuständigkeiten verloren.

Das Tool ohne Prozess. Es gibt ein Ticketsystem, aber keine Triage. Jede Anfrage landet in derselben Warteschlange. Prioritäten setzt die lauteste Person. SLAs sind hinterlegt, aber niemand pflegt sie. Der Bericht zeigt viele Tickets, sagt aber nichts über servicequalität aus.

Das leichtgewichtige Serviceportal. Ein klarer Eingang, wenige Kategorien, definierte Zuständigkeiten und eine kleine Wissensdatenbank. Das Team nutzt das System täglich, weil es die Arbeit tatsächlich erleichtert. Reporting beschränkt sich auf wenige Kennzahlen.

Die ausgebaute Plattform. CMDB, Change-Management, Problem-Management, Asset-Inventar, SLA-Regeln und Automatisierung. Dieses Modell kann sinnvoll sein, wenn viele Systeme, regulatorische Anforderungen oder mehrere Standorte zusammenkommen. Es erzeugt aber auch Pflegeaufwand, der in einem Team von drei Personen schnell zur Belastung wird.

Welche Kennzahlen wirklich helfen

Viele ITSM-Berichte messen Aktivität statt Wirkung. Die Anzahl der Tickets sagt wenig darüber aus, ob der Service besser wird. Hilfreicher sind Kennzahlen, die sich mit überschaubarem Aufwand erheben lassen:

• Zeit bis zur ersten menschlichen Antwort statt reiner Automationsbestätigung.
• Anteil der Tickets, die ohne Rückfrage bearbeitet werden können.
• Wiedereröffnungsquote: Wie oft kommt ein geschlossenes Ticket zurück?
• Alter des Backlogs: Wie viele Tickets sind älter als vereinbarte Fristen?
• Selbstbedienungsquote: Wie viele Anfragen werden über Wissensartikel oder Formulare gelöst?
• Wiederkehrende Störungen: Welche Incident-Arten tauchen regelmäßig auf und lassen sich ursächlich beheben?

Diese Kennzahlen müssen nicht täglich kontrolliert werden. Ein monatlicher Blick reicht in den meisten KMU aus. Entscheidend ist, dass das Team aus den Zahlen eine konkrete Maßnahme ableitet.

Wann ein leichtgewichtiges Serviceportal reicht

Ein leichtgewichtiges Portal ist eine gute Wahl, wenn ein Team von zwei bis zehn Personen überwiegend Standardanfragen bearbeitet: Passwort zurücksetzen, Software installieren, Berechtigungen prüfen, Drucker störung melden. Es reicht, wenn es einen verbindlichen Eingang gibt, klare Kategorien, eine kleine Wissensbasis und eine nachvollziehbare Zuständigkeit.

Auch die Integration mit Monitoring kann leichtgewichtig ausfallen: Ein Alarm erzeugt automatisch ein Ticket, das einem System und einer Supportgruppe zugeordnet wird. Wichtig ist, dass nicht jeder Alarm ein Ticket erzeugt. Sonst wächst der Backlog schneller als die Fähigkeit zur Bearbeitung.

Wann der Wechsel sinnvoll ist

Ein Wechsel zu einer ausgebauten Plattform lohnt sich, wenn mindestens drei der folgenden Punkte zutreffen: Es gibt eine hohe Zahl unterschiedlicher Systeme und Abhängigkeiten; Änderungen müssen formal freigegeben und dokumentiert werden; regulatorische oder vertragliche Anforderungen verlangen Nachweise; mehrere Standorte oder Dienstleister arbeiten in einem gemeinsamen Prozess; Assets und Konfigurationen müssen eng mit Störungen verknüpft werden.

Auch dann gilt: Nicht alle Module gleichzeitig einführen. Ein sinnvoller Pfad beginnt mit Incident- und Request-Management, ergänzt eine Wissensdatenbank und führt erst danach Change- oder Asset-Funktionen ein. Die Reihenfolge sollte sich am Nutzen orientieren, nicht am Funktionsumfang des Anbieters.

Eine Entscheidungsliste für das Team

Vor der Werkzeugentscheidung sollten fünf Fragen beantwortet werden: Wie viele Anfragen erreichen uns pro Woche und über welche Kanäle? Welche drei Anfragearten verursachen den meisten Aufwand? Brauchen wir eine CMDB oder reicht eine einfache Asset-Liste? Welche Nachweise verlangen Kunden, Auditoren oder Versicherer? Wie viel Pflegeaufwand kann das Team pro Woche realistisch tragen?

Die letzte Frage wird oft unterschätzt. Ein ITSM-System ist kein Projekt mit einem Endtermin. Es ist ein Betriebsmittel, das gepflegt werden muss. Wer diese Pflege nicht einplant, bekommt nach einem Jahr ein teures Archiv vergangener Prozesse – aber keinen besseren Service.

Für FFM Plattform zählt deshalb nicht, wie viele Funktionen eine Plattform mitbringt. Entscheidend ist, ob sie den Alltag kleiner IT-Teams transparenter macht. Ein Serviceportal ist dann gut, wenn es Anfragen schneller an die richtige Stelle bringt und dem Team Zeit für die eigentliche Problemlösung verschafft.