Bei ITSM-Daten trifft das Sprichwort „Dreimal umgezogen ist einmal abgebrannt“ einen konkreten Punkt. Jede Migration kann Informationen und Zusammenhänge verlieren. Was ein Unternehmen nie erfasst hat, kann es später auch nicht exportieren. Kein Migrationsskript kann eine fehlende Beziehung zwischen einem CI und einem Service nachträglich herstellen. Auch Wissen aus manuellen Workarounds und individuellen Workflows steht oft nicht im Datenmodell.

Viele Migrationsprojekte starten mit dem sichtbaren Datenbestand. Dabei bleiben wichtige Zuordnungen, Verantwortlichkeiten und Historien unklar. Ein Feldmapping überträgt Statuswerte. Es rekonstruiert keine fehlende Beziehung und erklärt keinen Workflow, dessen Zweck niemand dokumentiert hat.

Vor dem Migrationsdesign muss die Projektleitung vier Fragen beantworten:

1. Wo liegen die relevanten Daten?
2. Welches System führt die jeweilige Information?
3. Welche Daten übernimmt das Zielsystem bewusst nicht?
4. Welche Beziehungen tragen die geplanten Anwendungsfälle?

Erst die Klärung zeigt, welchen Datenbestand das Projekt tatsächlich migrieren kann. Einzelne Personen, Lokationen, Business-Services, technische Services und Systeme reichen für Incident und Change Management nicht aus. Ein Incident braucht gegebenenfalls den betroffenen Service, das verantwortliche Team und die unterstützenden Systeme. Bei einem Change müssen Abhängigkeiten und die betroffenen Nutzergruppen sichtbar sein. Für ein Asset zählen Identität, Besitzer, Standort, Status und Lebenszyklus. Fehlen diese Beziehungen, können Teams die Auswirkungen eines Tickets nicht zuverlässig aus den Daten ableiten.

Technische Funktionen können CIs aus mehreren Quellen zusammenführen und Dubletten vermeiden. Sie entscheiden aber nicht, welche Beziehungen für einen fachlichen Anwendungsfall relevant sind. Diese Entscheidung gehört in das Zielmodell und braucht eine verantwortliche Stelle. Das gilt ebenso für Assets in Jira Service Management.

Ein Service kann im Tool sauber angelegt sein. Ein Rollenmodell kann Zuständigkeiten festlegen. Beides schafft noch keine gelebte Verantwortung. Die betroffenen Personen müssen ihre Rolle kennen, ihren Zweck verstehen und im Alltag über die nötige Zeit und Entscheidungsbefugnis verfügen. Menschen verstehen den Sinn einer Veränderung meist besser, wenn ihr konkreter Nutzen erkennbar wird. Wird die Aufgabe nur als zusätzliche Pflicht erlebt, werden Daten und Beziehungen kaum dauerhaft gepflegt werden.

Für die Einführung hilft eine klare Reihenfolge:

1. Daten und Beziehungen bilden den Service ab.
2. Menschen übernehmen Verantwortung für diesen Service.
3. Tools unterstützen diese Verantwortung.
4. Prozesse und Funktionen können darauf aufbauen.

Tools können Verantwortliche, Services, CIs und Vorgänge miteinander verknüpfen. Sie allein schaffen aber keine gelebte Zuständigkeit. Service Owner brauchen aktuelle Informationen zu Incidents, Changes, Requests und Abhängigkeiten. Erst damit können sie Maßnahmen priorisieren und Verbesserungen steuern.

Jira Service Management kann bei den laufenden Lizenzkosten günstiger sein. Der Vergleich muss jedoch dieselbe funktionale Tiefe abbilden. Erweiterte Incident-, Change- und Asset-Funktionen hängen vom gewählten Plan ab. Auf der ServiceNow-Seite bestimmen gebuchte Module, Nutzerrollen und Vertragsbedingungen die Kosten.

Für jedes Customizing ist zu prüfen, ob es fachlich erforderlich, tatsächlich genutzt oder durch eine Standardfunktion ersetzbar ist. In die Rechnung gehören neben den Lizenzen auch Datenbereinigung, Migration, Schnittstellen, Tests, Schulungen, Parallelbetrieb und Ablösung. Fehlende Daten und Beziehungen sollten anhand konkreter Datenklassen und Anwendungsfälle bewertet werden, statt als pauschales Projektrisiko zu erscheinen.

Ein günstigerer Vertrag führt deshalb nicht automatisch zu niedrigeren Gesamtkosten. Entscheidend ist, welche Funktionen die Organisation wirklich braucht, welche Daten sie übernehmen kann und welchen Betriebsaufwand die neue Lösung verursacht.

Vor einer Plattformentscheidung sollte das Unternehmen vier Abläufe prüfen: einen Incident, einen Service Request, einen risikoreichen Change sowie die Übergabe oder Rückgabe eines Assets. Daraus lassen sich die benötigten Daten, Rollen, Workflows und Integrationen ableiten.

Eine belastbare Entscheidung braucht fünf Nachweise:

1. einen abgegrenzten Datenbestand, den das Zielsystem tatsächlich übernehmen kann;
2. belastbare Beziehungen zwischen Services, CIs und Assets;
3. Verantwortlichkeiten, die den betroffenen Personen bekannt sind und von ihnen wahrgenommen werden;
4. eine Bewertung der bestehenden Customizings und ihrer fachlichen Notwendigkeit;
5. eine TCO-Rechnung über den geplanten Betrachtungszeitraum.

Fehlt einer dieser Nachweise, überträgt ein Wechsel die bestehenden technischen und organisatorischen Lücken wahrscheinlich nur in eine andere Oberfläche.

Ihr Ansprechpartner zum Thema ITMS: