ITSM-Verbesserung und Cloud-Migration in der Finanzbranche

Lösung

ITSM-Strategieoptimierung

Railsbank bereitete eine Reihe von allgemeinen Anforderungen für unser Atlassian-Team vor, auf deren Basis wir den Weg zu ihrer ordnungsgemäßen Umsetzung definierten und entsprechende Änderungen an der ursprünglichen Strategie vorschlugen.

Prozessanalyse

Die Jira Service Management-Instanz des Kunden verfügte über drei grundlegende Issue-Typen, nämlich Feature, Bug und Support, die sich als unzureichend erwiesen, um Standardanfragen von Incident-, Problem-, Change- und Service-Benutzern korrekt zu verarbeiten und auf die Support-Teams zu verteilen. Die vorhandenen Issue-Typen entsprachen auch nicht vollständig den internen Prozessen des Kunden, wie Service Request Management, Knowledge Management, Incident Management, Change Management und anderen.

Bei der Prozessanalyse haben wir folgende Engpässe aufgedeckt:

• Die begrenzte Anzahl von Zwischenstatus für Tickets
• Das Fehlen von Benutzerberechtigungen
• Genehmigungen, die über verschiedene Kommunikationskanäle gesammelt werden, statt über Jira Service Management

Kundenserviceoptimierung

Um die Prozesse im Kundenservice zu straffen, hat Itransition fünf zusätzliche Issue-Typen und entsprechende Workflows erstellt und implementiert. Dadurch konnten wir auch neue, stärker fragmentierte Status für Anfragen einführen, da Jira Service Management nur einen Workflow pro Vorgangsart zulässt.

Wir richteten auch Workflows mit Genehmigungen für verschiedene Aufgabentypen ein, um die Transparenz des Genehmigungsprozesses zu verbessern. Darüber hinaus erstellte unser Team 19 neue Anfragetypen, konfigurierte das Webportal und die Anfrageformulare für den Benutzersupport und verschob alle bestehenden 15.000 Tickets auf die neuen Workflows, Problem- und Anfragetypen.

Fähigkeit zur Selbstbedienung

Wir haben alle Anfragetypen angemessen klassifiziert, um die Navigation intuitiv zu gestalten, die Weiterleitung von Anfragen vereinfacht und relevante Beschriftungen auf Wiki-Seiten aktiviert, um die Suche zu vereinfachen. Außerdem fügten wir dem Support-Portal eine Suchfunktion hinzu, mit der die Benutzer ihr Problem oder ihre Frage leicht nachschlagen können. All diese Konfigurationen halfen der Railsbank, ihren Kunden einen besseren Self-Service zu bieten.

Automatisierung der Ticketzuweisung

Da der Kunde mehrere Support-Teams hat, die Benutzeranfragen bearbeiten, benötigte er die Funktionalität für die Zuweisung von Tickets zu Gruppen, die dem Standard-Jira Service Management fehlte. Unsere Experten schlugen vor, ein zusätzliches Feld für die Gruppenzuweisung zu erstellen, lieferten einen Proof of Concept, um die Idee zu demonstrieren, und implementierten das Feld.

Wir haben auch die automatische Zuweisung von Tickets zu Gruppen in Abhängigkeit von der Art der Benutzeranforderung eingerichtet, indem wir ein benutzerdefiniertes Zuweisungsgruppenfeld für den Group Picker-Typ erstellt haben. Das Feld wird auch für Benachrichtigungen verwendet, so dass Benutzer aus einer entsprechenden Gruppe benachrichtigt werden können, wenn eine Anfrage erstellt oder geändert wird.

Zusätzlich haben wir das System so konfiguriert, dass Ticket-Warteschlangen auf der Grundlage der Werte des Feldes Zuweisungsgruppe anstelle der zuvor verwendeten Mitarbeiterfilter eingerichtet werden. Diese Änderung ermöglichte es dem Kunden, die Bearbeitung von Anfragen zu optimieren und die Kennzeichnung neuer Supportmitarbeiter in Tickets zu automatisieren.

Schutz sensibler Ticket-Daten

Aufgrund der sensiblen Daten in Tickets musste der Kunde den Zugriff auf Anfragen für Supportmitarbeiter einschränken. Um dies zu erreichen, schuf Itransition die Rolle Ticket Type Agent, die denjenigen Agenten zugewiesen wurde, die einen begrenzten Zugriff auf Anfragen benötigten. Wir haben auch die zusätzliche Rolle "Read-Only Agent" eingeführt, die verhindert, dass der zugewiesene Mitarbeiter irgendwelche Aktionen an Tickets durchführen kann.

Darüber hinaus hat unser Team eine Standardsicherheitsstufe geschaffen, die der Kunde allen Tickets zuweisen kann, um deren Sichtbarkeit einzuschränken, sowie zusätzliche Sicherheitsstufen, die jeweils einer bestimmten Gruppe von Supportmitarbeitern zugeordnet sind und nur den Zugriff auf bestimmte Ticketarten erlauben. Wenn ein Ticket erstellt oder aktualisiert wird, weist das System ihm automatisch die entsprechende Sicherheitsstufe zu, abhängig von der Art der Anfrage, dem Wert der Zuweisungsgruppe oder der Bezeichnung. Darüber hinaus haben wir die Sicherheitsstufen weiter anpassbar gemacht und das Team des Kunden darin geschult, die bestehenden Schutzmechanismen zu erweitern.

Automatische SLA-Berechnung

Da die Kunden der Railsbank in verschiedenen Zeitzonen ansässig sind und unterschiedliche Service-Levels nutzen, musste das Unternehmen die SLAs für "Zeit bis zur ersten Reaktion" und "Zeit bis zur Lösung" individuell auf der Grundlage des Wertes dieser beiden Parameter und ihrer Priorität berechnen.

Zu diesem Zweck erstellte Itransition zwei benutzerdefinierte Felder - Region und Service Level. Bei der Erstellung einer Anfrage prüft die Automatisierungsregel, zu welcher Organisation sie gehört, und setzt die Werte für Region und Service Level, während der Kunde die Priorität selbst definiert. Auf der Grundlage der Werte dieser Felder legt das System dann das entsprechende SLA-Ziel fest. Insgesamt haben wir etwa 60 SLA-Ziele erstellt und die Erstellung von SLA-Berichten eingerichtet.

Automatisierungsregeln

Um die Arbeitsabläufe im Jira Service Management zu automatisieren, hat Itransition insgesamt 15 Automatisierungsregeln erstellt. Hier sind die wichtigsten von ihnen:

• Wenn ein Ticket als "Zur Genehmigung anstehend" gekennzeichnet ist, markiert das System die Genehmiger.
• Wenn ein Rückbuchungsanfrage-Ticket als "In Bearbeitung" gekennzeichnet ist, markiert das System die Person, die den Status in den Kommentaren geändert hat.

• Wenn die Rückbuchungsanfragen vom Treasury-Team bearbeitet werden sollen, werden die Tickets mit dem Status "In Bearbeitung" automatisch dieser Gruppe zugewiesen.
• Wenn die Rückbuchungsanfragen vom Risk Ops Team überprüft werden sollen, werden die Tickets mit dem Status "Under Review" dieser Gruppe zugewiesen.

• Tickets werden automatisch geschlossen, nachdem sie fünf Tage lang den Status "Gelöst" oder "Erledigt" hatten.
• Tickets wechseln zu "In Bearbeitung", wenn sie jemandem zugewiesen werden.
• Tickets wechseln in den vorherigen Status, nachdem der Kunde geantwortet hat.
• Wenn das Feld "Zuweisungsgruppe" des Tickets geändert wird, werden Empfänger, die nicht zu dieser Gruppe gehören, entfernt.

Außerdem haben wir die Standardvorlage für Kundenbenachrichtigungen durch eine benutzerdefinierte Vorlage ersetzt, den Standardinhalt geändert und ihr ein ansprechenderes Aussehen verliehen.

Cloud-Migration

Aus Gründen der Datensicherheit und der Compliance-Vorschriften konnte uns Railsbank keinen Zugang zu ihrem Server gewähren. Stattdessen sicherten wir ausgewählte Dateien in einem sicheren Dateispeicher, den wir nach der Migration in die Cloud-Umgebung laden konnten. Außerdem reservierten wir im Voraus Domainnamen für die Jira- und Confluence-Sites von Railsbank.

Aufgrund des engen Zeitplans führten wir die Migration von Jira und Confluence parallel durch, wobei wir das Tool Cloud Migration Assistant verwendeten. Bei der Migration von Confluence haben wir zunächst die Version des Kunden auf unserem lokalen Server eingerichtet und anschließend das zuvor vom Kunden extrahierte Backup mit allen Daten eingespiel. Dann erstellten wir eine Test-Cloud-Instanz und migrierten die Daten dorthin. Nachdem das Railsbank-Team die Benutzerakzeptanztests abgeschlossen hatte, erstellten wir eine Produktionsinstanz und migrierten die Daten aus der Testumgebung dorthin.

Für die Jira-Migration stellten wir das System zunächst lokal bereit, installierten das spezielle Plugin zur Wiederherstellung von Daten aus dem Backup und migrierten es in die Test-Cloud-Umgebung. Anschließend überprüften wir die Integrität der Benutzer-, Gruppen- und Berechtigungsdaten und löschten die Daten abgeschlossener Projekte mit dem Bulk Delete Tool. Nach der Benutzerakzeptanzprüfung durch den Kunden übertrugen wir die Daten in die Produktionsinstanz in der Cloud.

Nach der Migration bot unser Team dem Kunden Support-Services an, um eine nahtlose Übernahme des Cloud-basierten Systems sicherzustellen.