So fasst ein Unternehmen der Hotelbranche die Migration seines Teams von ServiceeDesk Plus zu Jira Service Management. Der Datentransfer erfolgte in zwei Phasen und erforderte einige Anpassungen. Die größte Herausforderung bestand darin, die Beteiligten ins Boot zu holen, ohne die erfahrenen Techniker zu enttäuschen.
Diese Fallstudie behandelt sowohl die Migrationen des Unternehmens im Rahmen der Help Desk Migration als auch die Frage, wie die Beibehaltung der Tickethistorie dem Team geholfen hat, die Unterstützung für die neue Plattform zu gewinnen.
Warum das Unternehmen von ServiceeDesk Plus migriert hat
Das Unternehmen hatte sich zum Ziel gesetzt, seine IT-Servicebereitstellung zu modernisieren und in einem einheitlichen Helpcenter zusammenzuführen. Die bestehende Ticketing-Software konnte das vom Team angestrebte ITSM-Framework nicht unterstützen
Das IT-Team hatte folgende Anforderungen an das neue System:
Dezentrales Service-Routing
Automatisierte Ticketumleitung durch integrierte Wissensartikel
Klare SLA-Strukturen
Vollständiger Kontext, mit Tickets, die direkt mit Benutzern und Systemressourcen verknüpft sind
Ein Kriterium kam von den IT-Mitarbeitern selbst: die alten Tickets sollten erhalten bleiben. Jahrelang gelöste Probleme enthielten den technischen Kontext, auf den die Techniker angewiesen waren, und ohne historische Daten konnten sie keine Berichte erstellen. Ein Neustart mit einem leeren IT-Servicedesk war keine Option.
Migrationsumfang: Die Daten in Zahlen
Tickets
Benutzer (Anforderer)
Agenten
Unternehmen
Herausforderungen bei der Migration von Jira Service Management
Die Schwierigkeit bestand nicht in der Migration der Tickets, sondern darin, sie zu übertragen, ohne dass dabei ihre Nützlichkeit verloren ging.
-
1
Die Geschichte war nicht verhandelbar.
Die Techniker benötigten abgeschlossene Tickets zur Fehlerbehebung und Berichterstattung. Sollte das Team historische Daten verlieren, könnte dies den internen Support des Projekts gefährden.
-
2
Screenshots waren in die Konversationen integriert.
In Ticket-Threads eingebettete Bilder wurden nicht standardmäßig in Jira Service Management übernommen. Ohne sie würden viele Tickets den Nachweis für die durchgeführte Fehlerbehebung verlieren.
-
3
Die E-Mail-Verläufe waren mit E-Mail-Signaturen überladen.
Bei vielen der eingebetteten Bilder handelte es sich um Logos aus E-Mail-Signaturen, nicht um Screenshots.
-
4
Resolutionen hatten keine direkte Heimat.
In ServiceeDesk Plus ist eine Lösung ein separater Datensatz mit eigenem Autor und Datum. Jira Service Management verfügt über kein entsprechendes Feld, sodass die Lösung und die damit verbundene Anerkennung verloren gehen konnten.
-
5
Die Felder stimmten nicht überein.
Das Team musste die Quellfelder den Zielfeldern zuordnen, und nicht jedes Feld hatte ein Gegenstück.
-
6
Die Arbeiten durften nicht unterbrochen werden.
Während das Team die historischen Daten übertrug, trafen ständig neue Tickets im ServiceeDesk Plus ein.
-
7
Die Leute mussten mitkommen.
Das Team benötigte die Zustimmung der Stakeholder für die neue Plattform, ohne dabei die erfahrenen Techniker zu enttäuschen.
ServiceeDesk Plus vs. Jira Service Management: Datenmapping
ServiceeDesk Plus und Jira Service Management benennen und strukturieren dieselben Helpdesk-Daten unterschiedlich. Im Folgenden wird dargestellt, wie die Datensätze zwischen den beiden Service Desks abgeglichen wurden. Zeilen mit der Kennzeichnung „(benutzerdefiniert)“ stellen individuelle Anpassungen für diese Migration dar.
| ServiceeDesk Plus | Jira Service Management | Was ändert sich? |
|---|---|---|
| Anfragen | Tickets | Anfragetypen und -status müssen im Jira Service Management -Projekt vorhanden sein und vor der Migration zugeordnet werden |
| Anforderer | Kunden | Name, E-Mail-Adresse und Organisation werden übernommen; Telefonnummern und benutzerdefinierte Kontaktfelder haben bei Jira Service Management Kunden keine Daseinsberechtigung |
| Abteilungen | Organisationen | Die Kunden werden nach Organisation und nicht nach Abteilung gruppiert |
| Techniker | Agenten | Agenten werden zunächst in Jira Service Management eingerichtet; mehrere Techniker können einem Agenten zugeordnet werden |
| Gespräche und Notizen | Öffentliche und private Kommentare | Kommentare behalten ihren Autor, die Datenschutzeinstellungen und das Erstellungsdatum |
| Auflösung | Öffentliche Stellungnahme | Jiraist ein Dropdown-Menü, daher wurde der Text in einen Kommentar mit dem ursprünglichen Autor und dem benutzerdefinierten |
| Inline-Bilder | Anhänge | Inline-Bilder wurden zu Anhängen |
| Selbsthilfegruppen | Tags (Etiketten) | Tickets haben kein Gruppenfeld, daher erhielt jedes Ticket ein benutzerdefiniertes |
Wie die Migration angepasst wurde
Das IT-Team testete zunächst und forderte dann Anpassungen an. Sie führten mehrere kostenlose Demo-Migrationen an Beispiel-Tickets durch und überprüften, wie die Daten auf der Zielplattform aussahen.
Jeder Test zeigte, wo die Standardeinstellungen Schwächen aufwiesen und eine individuelle Anpassung Abhilfe schaffen würde. Daher haben unsere Techniker jede der unten aufgeführten Anpassungen individuell auf Basis der tatsächlichen Kundendaten erstellt.
| Option | Was es tat | Warum das Team es brauchte |
|---|---|---|
| Inline-Bilder zu Anhängen | In Ticketkonversationen eingebettete Bilder wurden in Anhänge umgewandelt | Andernfalls wären die Screenshots verloren gegangen |
| Beschluss zur öffentlichen Stellungnahme | Jede Resolution wurde als öffentlicher Kommentar hinzugefügt, wobei der jeweilige Techniker als Autor und das ursprüngliche Einreichungsdatum beibehalten wurden | Die Korrektur bleibt im Ticket-Thread vermerkt und wird dem richtigen Techniker zum richtigen Zeitpunkt gutgeschrieben |
| Tag pro Gruppe | Jedem migrierten Ticket wurde basierend auf seiner Gruppe in ServiceeDesk Plus ein Tag hinzugefügt | Die ursprüngliche Gruppe bleibt in Jira Service Management sichtbar und durchsuchbar |
| Delta-Migration | Übertragene Tickets, die nach der vollständigen Migration erstellt oder aktualisiert wurden | Das Team arbeitete bis zur Umstellung ununterbrochen in ServiceeDesk Plus, ohne dass es zu einer Datenlücke kam |
Ergebnisse der Migration von Jira Service Management
Das neue Hilfecenter des Unternehmens ging mit vollständig erhaltener Historie online. Die Migration erfolgte in zwei Schritten: einer vollständigen Migration und anschließend einer Delta-Migration, die alle dazwischen erstellten Daten übernahm.
Expertentipps aus der Hotelbranche
Warum das Team Help Desk Migrationempfiehlt:
„Schneller und kompetenter Support. Das Tool ist einfach zu bedienen und günstiger als selbst entwickelte Migrationsskripte. Und das Testen ist kostenlos.“
Tipps für Teams, die eine Migration planen:
Überlassen Sie die Datenverarbeitung dem Tool
Mit einem automatisierten Tool wird der Datentransfer zum kleinsten Teil des Projekts. Der Erfolg hängt von allen anderen Faktoren ab: Planung, Kommunikation und den beteiligten Personen.
Bringen Sie Ihre Interessensgruppen in Einklang
Binden Sie die richtigen Stakeholder in das Projekt ein. Sie benötigen die Zustimmung zur neuen Plattform, aber nicht auf Kosten der erfahrenen Techniker, die auf die alten Tickets angewiesen sind.
Versprich, die Geschichte zu bewahren, und halte dich dann daran
Die Aufbewahrung der Tickethistorie war ein wichtiger Bestandteil des Change-Managements. Sie zeigte dem Team, dass eine neue Plattform nicht zu einem Verlust jahrelanger Daten führen würde.
Bewahre die Geschichte, gewinne das Team
Für dieses IT-Team waren die historischen Tickets mehr als nur Daten. Ihre Aufbewahrung war ein Versprechen an die Techniker, und die Einhaltung dieses Versprechens trug dazu bei, dass das gesamte Team die neue Plattform akzeptierte.
Ihre Techniker werden sich dieselbe Frage stellen: Was passiert mit unseren alten Tickets? Beantworten Sie diese Frage, bevor das Projekt startet. Testen Sie eine kostenlose Demo-Migration und zeigen Sie Ihrem Team die Tickets auf der neuen Plattform.
