7. Fallstudie Vontobel: «Digitalisiertes Service Management schafft Kundennutzen»

Vontobel ist ein führender Schweizer, international agierender Private Wealth und Asset Manager, der sich zum Ziel gesetzt hat, die anvertrauten Kundenvermögen langfristig zu schützen und zu mehren. Spezialisiert auf das aktive Vermögensmanagement und massgeschneiderte Anlagelösungen berät Vontobel verantwortungsvoll und vorausschauend. Rund 1500 Mitarbeitende erbringen an weltweit 22 Standorten erstklassige und massgeschneiderte Dienstleistungen für international ausgerichtete Kunden. Per Ende 2015 verwaltete Vontobel CHF 187,2 Mrd. an Kundenvermögen, bei einer Kapitalbasis von CHF 1,43 Mrd. und einer CET1‐Kapitalquote von 17,9 %. Die Namenaktien der Vontobel Holding AG sind seit 1986 an der SIX Swiss Exchange kotiert. Die Familie Vontobel und die gemeinnützige Vontobel‐Stiftung besitzen die Aktien‐ und Stimmenmehrheit und stehen damit für Unabhängigkeit, unternehmerisches Denken und Weitsicht.

Die Supporteinheit «Operation» erbringt weltweit alle IT‐Dienstleistungen. Die Sparte «Operation Services» stellt hauptsächlich alle 1st‐ und 2nd‐Level Support‐Dienstleistungen bezüglich des Electronic Workplace bereit, ist die primäre Anlaufstelle für die Benutzer bezüglich IT‐Fragen und ist für den IT‐Betriebsprozess verantwortlich.

Eine im Jahr 2013 intern durchgeführte Erhebung der Benutzerzufriedenheit ergab ein tieferes Resultat als angestrebt. Ausserdem wurden die Kosten als verhältnismässig hoch eingeschätzt, wobei eine genaue Zuordnung und Begründung der Kosten aufgrund des Fehlens einer transparenten Kostenstruktur nicht möglich war.

Ein wichtiger Aspekt zum Verständnis dieser Fallstudie sind die eingesetzten betrieblichen Standardsysteme. Wie in viele Unternehmen der Finanzbranche, zeichnen sie sich durch eine grosse Heterogenität aus Diese Heterogenität bezieht sich einerseits auf die Phasen des Lebenszyklus, in welchen die einzelnen Applikationen stehen, andererseits aber auch auf die Plattformen, auf welchen diese betrieben werden. Damit einhergehen typischerweise auch heterogene Supportstrukturen, welche die unterschiedliche IT‐Landschaft widerspiegeln. Ein standardisiertes Incident‐ und Problemmanagement existierte nicht. Dies führte dazu, dass Mitarbeitende informelle Kanäle für die Lösung ihrer konkreten Anliegen nutzten, was einem effizienten Einsatz von Ressourcen widersprach und sich in den Kosten niederschlug.

Die nachfolgenden Aussagen über Kundenzufriedenheit beziehen sich auf die Mitarbeitenden von Vontobel. Die Bankkunden sind indirekt betroffen und daher nicht Gegenstand der Fallstudie.

Die statistische Auswertung der Mitarbeitendenumfrage vor der Durchführung von Verbesserungsmassnahmen ergab ein Mittelwert von 4.8 auf einer Skala von 1 bis 6, was beinahe dem angestrebten Wert von 5.0 entsprach. Der Mittelwert ergab also keinen Grund zur Sorge. Doch die Standardabweichung war auffallend gross, was Anlass zu einer detaillierteren Auswertung gab. Diese weitergehende Analyse zeigte auf, dass vor allem im Bereich Störungsbehebung und Kundeninformation die grössten Verbesserungspotenziale lagen. In diesen Bereichen waren die Teilresultate wesentlich schlechter. Ausserdem gab es grössere Abweichungen zwischen den einzelnen Geschäftsfeldern, was auf stark unterschiedliche Supportbedürfnisse bzw. auf unterschiedliche Supportqualitäten hindeutete. Die in der Umfrage abgegebenen Kommentare von Mitarbeitenden liessen Rückschlüsse auf konkrete Problemstellungen zu. So war vor allem die lange Bearbeitungszeit von Incidents ein Problem, sofern die Störung nicht direkt durch telefonischen Support gelöst werden konnte.

Kundenzufriedenheit, mehr Transparenz und Effizienz in der Leistungserbringung und eine bessere Verfügbarkeit von Informationen in kritischen Supportprozessen standen im Mittelpunkt der Transformation.

Ausgehend von der geschilderten Ausgangssituation und einer Vielzahl von Interviews mit den Stakeholdern wurden folgende Kernfragen und Hypothesen formuliert:

Wie einleitend erwähnt, wurde der Support für jede Applikation bzw. Infrastrukturplattform verschieden gelöst. Diese Heterogenität wurde durch den Einsatz unterschiedlichster Support‐Werkzeuge und Arbeitsmethoden noch akzentuiert. Aus dieser historisch gewachsenen Situation ergaben sich folgende Herausforderungen:

Bereits zu Beginn der Lösungssuche wurde deutlich, dass nur die gesamtheitliche Betrachtung von vier Lösungselementen zu einer erfolgreichen Verbesserung der Situation führen konnte: klar definierte Prozesse, die sich auf korrekte und vollständige Stammdaten in einer Configuration Management Database (CMDB) abstützen, die Abbildung dieser Prozesse in einem Tool und der Zugriff der User über das zentrale Intranetportal (Abb. 7.1).

Die Konzeption und Umsetzung des Vorhabens orientierte sich am klassischen Vorgehen eines kontinuierlichen Prozessmanagements (Abb. 7.2).

In einem ersten Schritt wurden Ist‐Prozesse dokumentiert. Die Methodik hierzu stützte sich auf Interviews, Workshops und Dokumentenstudium ab. In einem zweiten Schritt wurden dann kritische Bereiche identifiziert. Diese kritischen Bereiche konnten über qualitative Analysen gefunden werden. Hierbei wurden Six‐Sigma‐Methoden angewendet. Aber auch quantitative Analysen wie beispielsweise von Durchlaufzeiten führten zur Identifikation von kritischen Bereichen. Aus der Kenntnis dieser kritischen Bereiche wurden dann Soll‐Prozesse abgeleitet. In einem weiteren Schritt wurden diese Soll‐Prozesse in der Organisation implementiert.

Bevor jedoch der geschilderte Verbesserungsprozess starten konnte, wurde eine geeignete Notation für die Prozessmodellierung evaluiert und der Fokus der Prozessmodellierung definiert. Von besonderer Relevanz war die Festlegung von Prozessverantwortlichen. Um die Voraussetzungen für eine breite Akzeptanz zu schaffen, wurden die Prozesse in die übergeordnete OP Prozesslandkarte integriert und auf diese Weise transparent kommuniziert, breit abgestützt und insbesondere an bestehenden und etablierten informellen Prozessen ausgerichtet. Durch die Einführung einer verbindlichen Notation konnte mit allen Beteiligten auf derselben Grundlage diskutiert werden. Allfällige Probleme an den Schnittstellen zwischen den Prozessschritten konnten rasch erkannt und mit deren Beseitigung begonnen werden.

Die Frage nach einer adäquaten Automatisierung der Supportprozesse war aus Sicht der Effizienzsteigerung sehr zentral. Entsprechend zentral wurde auch die Evaluation eines geeigneten Werkzeugs zur Unterstützung der Supportprozesse betrachtet. Die Wahl fiel auf Jira ServiceDesk. Ein wichtiges Auswahlkriterium war dabei die bereits vorhandene Anwenderakzeptanz von Attlassian Jira. Zum Zeitpunkt der Entscheidung war Jira ServiceDesk aus einer funktionalen Sicht nicht das beste, aber aus Sicht der Mitarbeitenden das wohl akzeptierteste Werkzeug.

Im Kontext einer möglichst hohen Automatisierung sind die Identifikation von Steuer‐ und Stammdaten für die Supportprozesse zentral. Diese bestanden zu diesem Zeitpunkt nicht und mussten von Grund auf erhoben werden. Um sie professionell verwalten und unterhalten zu können, wurde eine Configuration‐Management‐Datenbank (CMDB) aufgebaut. Der Aufbau dieser Datenbank erforderte sehr viel Zeit und musste mit hoher Qualität erfolgen, um später keine Probleme bei der Prozessausführung zu erhalten.

Dabei stand eine automatisierte Bereitstellung der Daten im Vordergrund, um immer aktuelle Daten in hoher Qualität zur Verfügung zu haben. Es wurden daher die bestehenden Systeme in Abhängigkeit zueinander gestellt und eine sogenannte konföderierte CMDB erstellt (Abb. 7.3).

Auf dem Weg in Richtung optimierte IT‐Unterstützung waren in einem nächsten wichtigen Schritt Fragen bezüglich der Usability zu klären. Es existierten keine Standards hierzu. Entsprechend bestand auch bezüglich diesem Kriterium eine grosse Heterogenität. Bei aller Beachtung methodischer Erkenntnisse stellte das Prinzip der Praxisorientierung und der realen Machbarkeit eine wichtige Orientierungshilfe dar.

Aus Sicht IT war es zwingend, die Supportwerkzeuge nahtlos in die Systemlandschaft zu integrieren. So wurde grossen Wert auf die Einhaltung von Standards und deren Interoperabilität gelegt. Ziel war es, einen möglichst hohen Automatisierungsgrad in den Hauptprozessen Incident‐und Request‐Management zu erreichen. Diese Hauptprozesse bergen die grössten Potenziale für Einsparungen, Effizienzsteigerungen und eine Verbesserungen des Benutzernutzens.

Die mangelnde Benutzerzufriedenheit war ein zentraler Auslöser für die Transformation. Folglich wurde dem Kunden bei der Erarbeitung der IT‐gestützten Lösung grosse Beachtung geschenkt und der Zugang zu dieser Lösung in das zentrale Intranetportal integriert. Dieses Portal dient als zentrale Anlaufstelle für sämtliche Supportanfragen. Auf diesem Portal finden sich zudem sämtliche für den Support relevanten Dokumente. Mit der Einführung dieses zentralen Zugangs ergaben sich auch neue Anwendungs‐ und Informationsmöglichkeiten. So ist es jederzeit möglich, den Status von Anträgen einzusehen und die Portalseiten zu personalisieren. Weitergehende Auswertungsmöglichkeiten, welche auf Daten beruhen, die durch die einheitlichen Tickets und Arbeitsweisen entstanden sind, konnten so geschaffen werden. Diese dienen der kontinuierlichen Verbesserung des Dienstleistungsangebotes und der Sicherstellung einer gleichbleibend hohen Servicequalität, indem Schwachstellen und deren Ursachen rascher und einfacher eruiert werden können.

Neu können nicht nur IT‐Support‐Services über das Service‐Center‐Portal bezogen werden, sondern alle Geschäftsfelder organisieren ihre Support‐Aktivitäten über dieses Portal (Abb. 7.4), was aus Benutzersicht eine Vereinfachung darstellt und gleichzeitig auch die Usability stark erhöht. Im Fokus stehen dabei auch HR‐Prozesse wie beispielsweise der Eintritt oder der Austritt von Mitarbeitenden. Um die Usability weiter an den Kundenbedürfnissen auszurichten, wurden innovative Suchfunktionen implementiert (Abb. 7.5).

Nach erfolgreicher Einführung der beschriebenen Neuerungen und Verbesserungen verbleiben noch einige Herausforderungen. Diese umfassen im Wesentlichen:

Die Einführung der oben geschilderten Lösungselemente (Prozesse, CMDB, Tool, einheitlicher Kundenzugang) hatte eine markante Steigerung der Kundenzufriedenheit zur Folge. Bereits ein Jahr nach Einführung waren die Kundenzufriedenheitswerte innerhalb des gesetzten Zielbandes (Veränderung um 0.3 Punkte von 4.8 auf 5.1 auf einer Skala von 1 bis 6). Der Support erfolgte schneller, zu tieferen Kosten und mit einer grösseren Anwenderfreundlichkeit. Eine positive Dynamik konnte sich etablieren.

Fehlende Kennzahlen waren ein wesentliches Defizit der Ausgangssituation. Mit der eingeführten Lösung sind diese Kennzahlen nun automatisiert verfügbar und auch nachvollziehbar. Auf der Grundlage dieser neu gewonnenen Transparenz können nun quantitative Entscheidungsgrundlagen für die Entwicklung des Betriebs zur Verfügung gestellt werden. Das wiederum resultiert in einer höheren Zufriedenheit der Supportmitarbeitenden und letztlich in messbar tieferen Kosten.

Rückblickend ist auch der Aufbau einer CMDB als zentraler Erfolgsfaktor zu betrachten. Obwohl der Aufbau sehr ressourcenintensiv war, ist der Nutzen definitiv höher einzuschätzen. Auch das Verständnis der Kundenbedürfnisse ist als wesentlicher Erfolgsfaktor zu werten. Eine grosse Rolle spielt bei Vontobel hierbei die Internationalität der Anwender, die durch das Wachstum in Asien und USA zunehmend an Bedeutung gewinnt. Dieser Internationalität wird zunehmend Rechnung getragen, indem Servicezeiten angepasst, diese Standorte besucht und aktiv die lokalen Kundenbedürfnisse erhoben werden. Das war in der Anfangsphase der Transformation aus Ressourcengründen noch nicht in der gleichen Intensität möglich.

Die Fallstudie deckt ein schmales Spektrum der im Rahmen der Studie erforschten Aspekte der digitalen Transformation ab. Das Vorhaben verändert primär die Domäne Business Operations und macht die Relevanz der Prozessdigitalisierung in dieser Domäne deutlich. Auch wenn Systeme wie Jira ServiceDesk schon seit vielen Jahren bekannt sind und auch eingesetzt werden, zeigt dieses Fallbeispiel deutlich, dass vielfach operative Optimierungspotenziale über lange Zeit brach liegen und diese mit herkömmlicher Technik realisiert werden können. Die wesentlichen Erkenntnisse sind in Abb. 7.6 gekennzeichnet und nachfolgend dargestellt.