Advertisement

Fallstudie Vontobel: «Digitalisiertes Service Management schafft Kundennutzen»

  • Markus Schneider
  • Philipp Klauser
  • Thomas Keller
Open Access
Chapter

Zusammenfassung

Die Fallstudie aus den Operation Services des Schweizer Private Wealth und Asset Managers Vontobel zeigt, dass auch die digitale Transformation interner Bereitstellungsprozesse ein hohes Nutzenpotenzial birgt und dazu beiträgt, dass sich Servicefunktionen in der Organisation neu positionieren und ihre Rolle in der Organisation verändern können. Kundenzufriedenheit, mehr Transparenz und Effizienz in der Leistungserbringung und eine bessere Verfügbarkeit von Informationen in kritischen Supportprozessen standen im Mittelpunkt der in dieser Fallstudie beschriebenen Transformation des IT‐gestützten Service Managements bei Vontobel.

Die Fallstudie aus den Operation Services des Schweizer Private Wealth und Asset Managers Vontobel zeigt, dass auch die digitale Transformation interner Bereitstellungsprozesse ein hohes Nutzenpotenzial birgt und dazu beiträgt, dass sich Servicefunktionen in der Organisation neu positionieren und ihre Rolle in der Organisation verändern können. Kundenzufriedenheit, mehr Transparenz und Effizienz in der Leistungserbringung und eine bessere Verfügbarkeit von Informationen in kritischen Supportprozessen standen im Mittelpunkt der in dieser Fallstudie beschriebenen Transformation des IT‐gestützten Service Managements bei Vontobel.

7.1 Kontext und Ausgangssituation

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.

7.2 Motivation und Zielsetzung

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:
  1. 1.

    Kann die Kundenzufriedenheit gesteigert werden, indem das gleiche Angebot rascher, qualitativ hochstehender und idealerweise zu tieferen Kosten angeboten wird?

    Die Annahme, dass dies möglich sein muss, beruht auf der Erkenntnis, dass die Ursache für die teilweise fehlende Kundenzufriedenheit oftmals in der sehr langen Reaktionszeit des Supports bzw. in sehr unterschiedlichen Reaktionszeiten lag. Ein anderer Grund für eine fehlende Kundenzufriedenheit lag teilweise in einer nicht einwandfreien Lösungsfindung. Das heisst, das gemeldete Problem konnte nicht, nur teilweise oder nicht befriedigend gelöst werden. Dies schlug sich auch in höheren Kosten nieder, da das gleiche Problem mehrfach und auf unterschiedliche Weise gelöst wurde. Ebenso fehlte eine gemeinsame Wissensbasis.

     
  2. 2.

    Können die bestehenden Ressourcen effizienter und effektiver eingesetzt werden, um mehr Aufgaben bei gleichzeitig höherer Qualität zu bewältigen?

    Die Hypothese lautet, dass durch die informalen Strukturen und die heterogene IT‐Landschaft der Anteil an unproduktiver Zeit grundsätzlich höher ist als in einer standardisierten Supportorganisation. Selbstverständlich verursacht jedes System Sockelkosten, welche nur schwer reduzierbar sind. Mit einem standardisierten Vorgehen können definitiv Synergien genutzt werden, welche zu einer höheren Dienstleistungsqualität, weniger Systemen und somit auch tieferen Kosten führen können.

     
  3. 3.

    Wie können die vorhandenen betrieblichen Informationen aus den eingesetzten IT‐Systemen wie z. B. Logdateien genutzt werden, um den anvisierten Verbesserungsprozess effektiv zu unterstützen?

    Die eingesetzten betrieblichen Informationssysteme produzieren Daten, mit welchen die Vergangenheit recht lückenlos nachvollzogen werden kann (z. B. Logfiles). Es stellt sich weniger die Frage nach der Verfügbarkeit solcher Daten, sondern vielmehr nach der gezielten und nachvollziehbaren Nutzung dieser Informationen und den daraus gezogenen Schlüssen, wie z. B. das Überwachen von betrieblichen KPIs.

     
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:
  1. 1.

    Wie können die betroffenen Supportmitarbeitenden motiviert werden, mit einem gemeinsamen Support‐Werkzeug, z. B. einem einheitlichen Ticketsystem, zu arbeiten?

    Diese Fragestellung impliziert, dass die eingesetzten Werkzeuge im Support durch ein Werkzeug ersetzt werden, mit dem alle Mitarbeitenden arbeiten müssen. Das bedeutet, dass die meisten Supportmitarbeitenden auf ihr angestammtes Werkzeug verzichten und sich mit einem Wechsel abfinden müssen. Üblicherweise wird ein solcher Wechsel nur unter Zwang erfolgen und somit nicht als etwas Positives empfunden, was sich allenfalls in einer höheren Fluktuation oder in einer temporär schlechteren Supportqualität manifestieren kann.

     
  2. 2.

    Kann eine verbesserte Transparenz durch Standardisierung und Harmonisierung zu einer höheren Benutzerzufriedenheit führen?

    Transparenz wird von Supportmitarbeitenden und Kunden unterschiedlich wahrgenommen. Beide profitieren von Nachvollziehbarkeit und Vergleichbarkeit, wobei Vergleichbarkeit aus Sicht des Leistungserbringers auch negativ wahrgenommen werden kann. Aus Kundensicht ist Transparenz jedoch eindeutig ein Qualitätsmerkmal und eine wichtige Grundlage für eine partnerschaftliche Zusammenarbeit und letztlich für eine höhere Benutzerzufriedenheit.

     
  3. 3.

    Kann trotz Standardisierung und Harmonisierung ein ausreichendes Mass an Agilität gewahrt bleiben?

    Agilität bezeichnet die Fähigkeit, auf Ereignisse und/oder Anforderungen situativ zu reagieren. Standardisierung und Harmonisierung hingegen verlangen, dass auf ähnliche Ereignisse und/oder Anforderungen in einer wohldefinierten Form reagiert wird. Durch die historisch gewachsene Vielfalt an Werkzeugen und individuellen Vorgehensmethoden ist die Gefahr gross, dass Supportmitarbeitende einer Standardisierung skeptisch bis ablehnend gegenüberstehen. Dabei ist jedoch bei adäquatem Tooleinsatz, welcher beispielsweise auch Case Management umfassen kann, die Funktionalität gegeben, um Agilität gezielt und nachhaltig zu unterstützten.

     

7.3 Umsetzung und Wirkung

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).
Abb. 7.1

Die vier Lösungselemente

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

BPM Lifecycle in Anlehnung an. (Dumas et al. 2013)

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).
Abb. 7.3

Konföderierte Configuration Management Datenbank

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).
Abb. 7.4

Portallösung

Abb. 7.5

Service Center IT

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

    Datenschutz: Der Inhalt von Tickets könnte in einem anderen Anwendungskontext vertraulich sein. Diesem Umstand wird mit der aktuellen Version nur teilweise Rechnung getragen.

     
  2. 2.

    Der Supportprozess bzw. die Verarbeitung von Tickets kann als Muster auch ausserhalb von Supportprozessen angewendet werden. Es braucht deshalb auch eine Abgrenzung zu klassischen Geschäftsprozessen.

     
  3. 3.

    Vereinheitlichung der noch nicht berücksichtigten Service Requests in Bezug auf Look & Feel.

     
  4. 4.

    Umgang mit Prozessen, für welche eine Automatisierung aus ökonomischer Betrachtung nicht sinnvoll erscheint.

     
  5. 5.

    Unterstützung von mobilen Endgeräten wie Smartphones und Tablets.

     
  6. 6.

    Sicherstellung eines kontinuierlichen Kundenfeedbacks und systematisches Analysieren von schlechten Bewertungen von Tickets zur Wahrung der Glaubwürdigkeit.

     

7.4 Fazit

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.
Abb. 7.6

Vontobel Fallstudie – Kernaspekte im Kontext des Studienframeworks

Mit welcher Zielsetzung und mit welcher Wirkung wird digital transformiert? Welcher Kundennutzen wird angestrebt bzw. wurde bereits realisiert?

Open image in new window Kundennutzen: einheitliche Supportprozesse

Unabhängig vom konkreten Supportfall werden die relevanten Daten einheitlich in das System eingetragen und der Status ist auf Kundenseite ersichtlich. Dies erhöht die Transparenz und schliesslich das Vertrauen, auch wenn der persönliche Kontakt mit dem Supportmitarbeitenden kürzer wird oder gar ganz wegfällt.

Open image in new window Operational & Service Excellence: Transparenz und Schnelligkeit

Ein Auslöser für das Vorhaben waren die Mehraufwände, die durch mangelhafte Bearbeitung von Supportanfragen verursacht wurden. Durch die Transparenz der für alle einzusehenden Supportanfragen werden diese zeitnaher erledigt. Ebenso führt die Möglichkeit des Kunden, die Lösung zu bewerten, zu einem Feedbackloop, der sich positiv auf die Qualität auswirkt.

Was wurde bzw. wird digital transformiert?

Open image in new window Business Operations: durchgehend digital und asynchron

Durch den flächendeckenden Einsatz von Jira ServiceDesk laufen die Supportprozesse primär asynchron ab. Eine synchrone Kommunikation beispielsweise über Telefon ist nur noch in Ausnahmefällen nötig. Dies spielt eine wichtige Rolle bei der Einführung erweiterter Supportzeiten.

Wie und wodurch wird transformiert?

Open image in new window Prozessdigitalisierung: Automatisierung und Integration im Back‐End

Um einen qualitativ hochstehenden und raschen Support anbieten zu können, müssen eine Vielzahl von Informationssystemen eingebunden sein. Ein Supportsystem ohne Anbindung an die bestehenden betrieblichen Informationssysteme (CMDB, Monitoring, etc.) kann nicht die flächendeckenden Informationen anbieten wie eine hoch integrierte Lösung.

Literatur

  1. Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2013). Fundamentals of business process management. Heidelberg: Springer.Google Scholar

Copyright information

© Der/die Autor(en) 2018

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.

Authors and Affiliations

  • Markus Schneider
    • 1
  • Philipp Klauser
    • 1
  • Thomas Keller
    • 2
  1. 1.VontobelZürichSchweiz
  2. 2.Institut für WirtschaftsinformatikZHAW School of Management and LawWinterthurSchweiz

Personalised recommendations