ITSM-Tool Konsolidierung um jeden Preis?

In vielen Organisationen findet derzeit eine konsequente Konsolidierung der ITSM-Toollandschaft statt. Etablierte Enterprise-Service-Management-Plattformen wie ServiceNow oder Remedy werden durch schlankere Lösungen auf Basis von Jira Service Management ersetzt.
Getrieben wird diese Entwicklung durch nachvollziehbare Argumente: geringere Lizenz- und Betriebskosten, Cloud-Betrieb ohne spezialisiertes Plattform-Know-how, hohe Nähe zu Entwicklung und DevOps sowie eine moderne, vielen Mitarbeitenden vertraute Benutzeroberfläche.

Diese Argumentation greift jedoch zu kurz. Mit zusätzlicher Konfiguration und einer Vielzahl von Marketplace-Apps lassen sich zwar einzelne Funktionslücken schliessen, doch zentrale Fähigkeiten klassischer ITSM-Plattformen lassen sich nur schwer oder gar nicht gleichwertig ersetzen. Gerade für Organisationen mit hohen Anforderungen an Governance, Compliance und Revision entstehen strukturelle Risiken, deren Konsequenzen häufig erst Jahre nach der Ablösung sichtbar werden.

Der entscheidende Punkt ist nicht die Effizienz in der Ticketbearbeitung, sondern der schleichende Verlust integrierter Steuerungs-, Kontroll- und Nachweisfähigkeit entlang von Services, Configuration Items und Changes.

Der Kern des Service Managements gerät unter Druck

Klassische ITSM-Plattformen stellen einen zentralen, hierarchischen Servicekatalog bereit, der Services klar definiert, Verantwortlichkeiten zuordnet, SLAs verankert und Genehmigungsprozesse integriert. Dieser Katalog ist nicht nur ein Anfrageportal, sondern das Rückgrat für Steuerung, Kostenverrechnung und Transparenz über IT- und Business-Services hinweg.

In schlanken Ticket-Tools reduziert sich der Servicekatalog häufig auf eine Sammlung von Formularen für Requests. Komplexe Service-Strukturen, serviceübergreifende Abhängigkeiten oder mehrstufige Genehmigungen müssen individuell nachgebaut werden. Mit wachsender Anzahl von Services und Fachbereichen steigt die Komplexität dieser Konstrukte rapide an.

Konsequenzen:

• Services verlieren ihre klare Abgrenzung und Vergleichbarkeit.
• Verantwortlichkeiten werden unscharf, da Service Ownership nicht systemisch verankert ist.
• SLAs lassen sich nur noch eingeschränkt oder inkonsistent messen.
• Für Management und Revision fehlt eine belastbare Übersicht darüber, welche Services tatsächlich angeboten und gesteuert werden.

Eine CMDB ist mehr als ein Inventar. Sie bildet die technische und logische Abhängigkeit von Services, Applikationen, Infrastruktur und externen Lieferanten ab. In klassischen ITSM-Plattformen ist sie tief integriert, historisiert und eng mit Incident-, Problem- und Change-Prozessen verzahnt.

In Jira-basierten Setups wird CMDB-Funktionalität meist über Zusatz-Apps oder vereinfachte Asset-Modelle realisiert. Beziehungen, Versionierung und Historien sind oft unvollständig, uneinheitlich gepflegt oder nicht revisionssicher nachvollziehbar.

Konsequenzen:

• Impact-Analysen bei Incidents oder Changes werden ungenau oder entfallen ganz.
• Risiken werden subjektiv eingeschätzt, statt datenbasiert bewertet.
• Abhängigkeiten zwischen Services und CIs sind für Management und Audit nicht konsistent belegbar.
• Fehlerhafte oder unvollständige CMDB-Daten untergraben das Vertrauen in das gesamte Service Management.

Change Management entfaltet seinen Wert erst durch die enge Kopplung an Servicekatalog und CMDB. Risiken werden systematisch bewertet, Genehmigungen transparent dokumentiert und Auswirkungen auf Services nachvollziehbar gemacht.

In schlanken Ticket-Tools werden Changes häufig als einfacher Issue-Typ mit Workflow modelliert. Ohne belastbare Service- und CI-Verknüpfung fehlt die Grundlage für konsistente Risikoklassifizierung, standardisierte Genehmigungen und revisionssichere Dokumentation.

Konsequenzen:

• Changes werden schneller umgesetzt, jedoch mit steigender Betriebs- und Ausfallgefahr.
• Wiederkehrende Fehler und Incidents lassen sich schwerer auf vorangegangene Changes zurückführen.
• Für Revision und Risikomanagement ist nicht mehr nachvollziehbar, auf welcher Basis Entscheidungen getroffen wurden.
• Management verliert die Fähigkeit, das Gesamtrisiko der IT-Landschaft aktiv zu steuern.

Enterprise-ITSM-Plattformen sind explizit auf Governance, interne Kontrollen und Audits ausgelegt. Änderungen an Services, CIs, Changes, Rollen und Genehmigungen sind vollständig historisiert, auswertbar und konsistent reportbar. Damit lassen sich regulatorische Anforderungen wie ISO-, SOC- oder SOX-Vorgaben strukturiert und wiederholbar erfüllen.

In schlanken Ticket-Tools sind Protokollierung und Reporting zwar vorhanden, jedoch nicht auf durchgängige Compliance-Nachweise ausgelegt. Vollständige Audit Trails entstehen nur durch aufwendige Zusatzkonfigurationen, individuelle Erweiterungen oder manuelle Dokumentation.

Konsequenzen:

• Audit-Anfragen verursachen hohen manuellen Aufwand und Ad-hoc-Auswertungen.
• Nachweise sind fragmentiert und schwer reproduzierbar.
• Prüfungsfeststellungen und Risiken im internen Kontrollsystem nehmen zu.
• Vertrauen von Revision, Aufsicht und Management in die IT-Steuerung sinkt.

Die zentrale Management-Frage
„Wer hat wann welchen Change an welchem CI für welchen Service genehmigt und mit welchem Risiko?“
lässt sich nicht mehr konsistent, systemgestützt und revisionssicher beantworten.

Fehlende Funktionalitäten werden in der Praxis kompensiert: Excel-Listen für CIs, E-Mail-Freigaben für Changes, separate Dokumente für Audit-Nachweise. Diese Parallelstrukturen entstehen oft schleichend und ausserhalb der formalen Governance.

Konsequenzen:

• Medienbrüche und Inkonsistenzen nehmen zu.
• Wissen verteilt sich auf Personen statt auf Systeme.
• Steuerbarkeit und Transparenz gehen verloren.
• Das ursprüngliche Ziel der Tool-Konsolidierung wird faktisch verfehlt.

Die Ablösung einer integrierten ITSM-Plattform durch ein schlankes Ticket-Tool ist eine strategische Entscheidung mit langfristigen Auswirkungen. Sie verlagert den Fokus von Steuerbarkeit, Kontrolle und Nachweisfähigkeit hin zu operativer Geschwindigkeit und wahrgenommener Einfachheit.

Dies kann in Umgebungen mit geringer regulatorischer Dichte und überschaubarer Service-Landschaft sinnvoll sein. Für Organisationen mit hohen Anforderungen an Compliance, Auditierbarkeit und Risikomanagement liegt der zentrale Mehrwert jedoch weiterhin in einer integrierten Service-, CMDB- und Change-Governance.

Die entscheidende Frage lautet daher nicht:
Welches Tool ist moderner oder günstiger?

Sondern:
Welche Risiken sind wir bereit einzugehen, wenn wir auf integrierte Service- und Governance-Strukturen verzichten?

Diese Frage sollte im Zentrum jeder Entscheidung zur ITSM-Konsolidierung stehen.