Ticketing oder ITSM? Wann Systemhäuser den Schritt zum Serviceprozess gehen sollten

Ein Ticketsystem bringt Ordnung in Anfragen. Sobald Systemhäuser wachsen, kann schlichtes "Tickets abarbeiten" jedoch zur Wachstumsbremse werden. Woran erkennen Systemhäuser, dass Ticketing an Grenzen stößt und was sollten sie beim Umstieg beachten?

Viele Systemhäuser und MSPs kommen irgendwann an denselben Punkt: Das Ticketsystem läuft, die Anfragen werden bearbeitet und trotzdem wächst das Gefühl, den Service nicht wirklich unter Kontrolle zu haben. Die Einhaltung von SLAs lässt sich kaum verlässlich nachverfolgen, Wissen steckt in einzelnen Köpfen und ein vollständiger Überblick über laufende Vorgänge, Gerätehistorien und Vertragszusammenhänge fehlt. Das ist nicht unbedingt ein Zeichen schlechter Arbeit. Es weist allerdings darauf hin, dass ein Werkzeug an seine Grenzen stößt.

In solchen Situationen lohnt es sich, die eigene Tool-Wahl zu hinterfragen. Ein Ticketsystem kann hervorragend dabei helfen, Ordnung zu halten. Viele Teams stellen jedoch fest, dass Ordnung allein nicht mehr ausreicht, sobald SLAs, Freigabeprozesse, Eskalationen, Vertragslogik und Dokumentationspflichten zusammenkommen. Dann geht es darum, den Service so aufzustellen, dass Zuständigkeiten, Prozesse, Regeln und Fristen im Alltag zuverlässig automatisiert greifen. Ein ITSM-Tool, das Ticketing, Asset-Management und Vertragslogik in einem System zusammenführt, kann hier die richtige Lösung sein.

Zwei Werkzeuge, zwei Ansätze

Ein Ticketsystem erfüllt seinen Zweck, solange es vor allem darum geht, Anfragen strukturiert zu erfassen und abzuarbeiten. Das funktioniert gut, wenn die Komplexität überschaubar bleibt und die Kundenanforderungen es zulassen. Im Kern unterscheiden sich beide Ansätze in ihrer Zielsetzung: Ticketing ist auf die strukturierte Abarbeitung von Anfragen ausgelegt. Ein ITSM-Tool dagegen zielt darauf ab, den gesamten Serviceprozess durch mehr Kontext, Steuerungslogik und Automatisierung planbar und skalierbar zu machen.

Dabei ist der Umstieg keine reine Größenfrage. Auch ein kleines Team kann von einem ITSM profitieren, abhängig davon, welche Kundenanforderungen es erfüllen muss und wie komplex die eigenen Serviceprozesse bereits sind. Das Ticket bleibt auch im ITSM die zentrale Hülle, in der Arbeit dokumentiert und gesteuert wird. Der entscheidende Unterschied liegt darin, was an Kontext und Steuerungslogik dahinter liegt. Dazu gehören zum Beispiel der Bezug zu Assets, Regeln aus Wartungsverträgen und Managed Services, geführte Workflows für Incidents, Changes und Service Requests sowie ein Eskalations- und Monitoringmechanismus.

Wann Ticketing an seine Grenzen stößt

Die Signale zeigen sich meist schleichend. Ein erstes Anzeichen ist, dass Prioritäten zunehmend situativ gesetzt werden: Wenn keine hinterlegten Regeln und SLAs aus Verträgen und Assets automatisch greifen, entscheiden oft Verfügbarkeit oder (gefühlte) Dringlichkeit darüber, welches Ticket als nächstes bearbeitet wird. Das hat direkte Auswirkungen auf Qualität und Teambelastung. Gleichzeitig nehmen Eskalationen zu, weil Transparenz und automatische Warnmechanismen fehlen.

Ein weiteres Signal zeigt sich in der Dokumentation: Wenn Geräteinformationen, Lösungshistorien und Zuständigkeiten nicht zentral und strukturiert erfasst werden, was mit einem reinen Ticketsystem oft schwer umsetzbar ist, wird das spätestens dann zum Problem, wenn Mitarbeitende das Unternehmen verlassen oder neue Kolleg*innen eingearbeitet werden müssen.

Hinzu kommt häufig, dass Tool-Hopping zum Normalzustand wird: Tickets hier, Assets dort, Dokumentation im Wiki, Vertragslogik im ERP. Fehlt die Vertragslogik im Ticketsystem, kann ein erbrachter Service nicht vollautomatisch dem richtigen Vertrag zugeordnet werden. Die Folge sind manuelle Nacharbeit und mögliche Abrechnungsfehler; dafür muss Zeit aufgewandt werden, die an anderer Stelle fehlt.

Nächste Seite: ITSM und Fehler bei der Einführung …

Was ITSM zusätzlich abbilden muss

Wenn Ticketing nicht mehr genügt, liegt das selten am Ticket selbst. Meist fehlen Kontext und Prozessrahmen. Ein zentraler Hebel ist der direkte Bezug zwischen Asset und Vertrag: Ein Ticket gewinnt an Aussagekraft, wenn es mit dem betroffenen Asset verknüpft ist, mit vollständiger Historie und dokumentierten Maßnahmen, und wenn gleichzeitig die dazugehörige Vertragslogik automatisch greift.

Viele Systemhäuser arbeiten je nach Kunde mit unterschiedlichen Reaktionszeiten, Prioritäten und Leistungsumfängen. Diese Regeln im System zu hinterlegen und automatisch auszulösen, inklusive Eskalationsmechanismen, wenn Fristen zu reißen drohen, entlastet Teams erheblich und macht Service steuerbar statt reaktiv.

Für eine saubere Abrechnung müssen Zeiten und Leistungen automatisch dem richtigen Ticket, Projekt und Vertrag zugeordnet werden, und zwar mit allen zugehörigen Parametern wie Preisen, Pauschalen oder Zeitzuschlägen. Fehlt diese Automatisierung, steigt das Risiko, Fehler bei der Abrechnung zu machen. Die manuelle Nacharbeit, die dann nötig wird, kostet Zeit und kann Diskussionen über Nachweise nach sich ziehen. Dann wird aus einem organisatorischen schnell ein Businessproblem.

Die häufigsten Fehler beim Umstieg

In der Praxis scheitert ITSM selten daran, dass ein System etwas grundsätzlich nicht kann. Meist liegt es an zwei gegensätzlichen Vorgehensweisen. Der erste Fehler: Ein neues Tool wird eingeführt, die Arbeitsweise bleibt unverändert. Zuruf, Bauchgefühl und optionale Dokumentation bleiben bestehen; das Ergebnis ist eine neue Oberfläche bei alten Problemen. Der zweite Fehler ist Perfektionismus vor Produktivität: Manche Teams möchten vor dem Go-live alles vollständig abbilden und verlieren sich dabei in der Konfiguration, bevor das System überhaupt produktiv genutzt wird.

Erfolgreicher ist ein pragmatischer Ansatz: ein startfähiges Setup definieren, schnell an realen Fällen testen, im Livebetrieb iterativ verbessern. Erst mit echten Tickets und echten Sonderfällen zeigt sich, ob das System wirklich entlastet. Eine solche Einführung gelingt am besten, wenn die Führungsebene klare Rahmenbedingungen setzt und den Rollout aktiv mitträgt.

Mindestens genauso wichtig wie die Toolwahl selbst ist die Wahl des Anbieters. Die Entscheidung für ein ITSM-System ist immer auch eine Entscheidung für eine langfristige Zusammenarbeit. Deshalb lohnt es sich, genau hinzuschauen: Wurde das Tool speziell für Systemhäuser und MSPs entwickelt oder handelt es sich um eine generische Lösung? Versteht der Anbieter die Branche wirklich und ist verlässlich erreichbar? Und gibt es eine aktive Community oder andere Möglichkeiten zum Austausch mit anderen Anwendern? Eine ausgedehnte Demophase kann helfen, genau das zu testen: das Produkt ebenso wie den Anbieter dahinter.

Fazit

Ein Ticketsystem ist für viele Teams nach wie vor das richtige Werkzeug, solange die Komplexität überschaubar bleibt. Wer absehbar skalieren möchte, sollte die Toolwahl jedoch langfristig denken, denn ein späterer Systemwechsel ist immer mit Aufwand verbunden. ITSM wird dann relevant, wenn Service als Prozess steuerbar sein muss: mit Vertrags- und SLA-Logik, Asset-Bezug, geführten Workflows, Eskalationsmechanismen und sauberem Leistungsnachweis. Eine ITSM-Plattform, die zunächst nur für das Ticketing genutzt und bei Bedarf schrittweise ausgebaut wird, kann für wachsende Systemhäuser eine sinnvolle Option sein.

Chris Huck ist CEO der HUCK IT GmbH. Das Unternehmen entwickelt mit TANSS eine ITSM-Plattform für IT-Dienstleister, Systemhäuser und MSPs. Chris Huck kennt die Branche aus eigener Erfahrung: HUCK IT hat seine Wurzeln im Systemhausgeschäft. Heute begleitet das Unternehmen Serviceorganisationen dabei, Serviceprozesse zu standardisieren und skalierbar aufzusetzen.

CRN-Newsletter beziehen und Archiv nutzen - kostenlos: Jetzt bei der CRN Community anmelden