Erfolgsfaktoren bei der Einführung von Standardsoftware in Banken

Von Ralf Keuper

Anders als in der Industrie, wo sich vor allem SAP als Standardsoftware durchgesetzt hat, konnte sich in der Finanzbranche bis heute kein vergleichbares Produkt etablieren. Viele Banken ziehen es vor, für ihre Kernprozesse eigene Software zu entwickeln, wie die Santander mit Partenón. Die Deutsche Bank wollte mit dem Magellan-Projekt auf SAP wechseln – das Vorhaben geriet jedoch, u.a. wegen des Zick-Zack-Kurses bei der Integration der Postbank, ins Stocken. Die Erfahrungen anderer Banken liefern ein ähnliches Bild: Die Erfolgsbilanz ist bestenfalls durchwachsen.

An Studien, die versuchen, die Ursachen von Fehlschlägen bei der Einführung von Standardsoftware/Kernbankensysteme zu ermitteln, hat es in der Vergangenheit nicht gefehlt. Beispielhaft dafür ist Success Factors in the Introduction of Standard Software in Core Processes of Banks aus dem Jahr 2004/2005.

Die Banken sind in gewisser Hinsicht Opfer ihrer Vorreiterrolle bei der Einführung neuer Informationstechnologien:

… the financial services industry had been an early adopter of software support in its core business processes, which has resulted in many legacy applications still being in use today.

Die Einführung eines neuen Kernbankensystems ist technisch durchaus anspruchsvoll, die eigentlichen Herausforderungen liegen jedoch auf der organisatorischen Ebene, im Auswahlprozess und auf der Investitionsseite:

Critical challenges can often be found in organizational rather than in technical aspects. The first major decision concerning the introduction of standard software is the vendor selection. Brenner (1990) identifies three major types of selections of standard software: strategic selection, selection according to corporate policies and standards and selection of an isolated solution. The first type is a selection that a company only makes once. If a strategic decision concerning a vendor has already been made, subsequent solutions can only attempt to comply with the standard or to select an isolated solution. The latter is only recommended in a few cases.

Die Wahl eines Kernbankensystem hat eine hohe strategische Bedeutung; sie zieht eine Reihe weiterer Entscheidungen und Weichstellungen nach sich, die auf die Organisationsstruktur und die Unternehmenskultur einwirken. Erfolgt die Wahl überwiegend aus politischen Gründen, dann ist der Misserfolg in den meisten Fällen vorprogrammiert.

In der erwähnten Studie untersuchten die Autoren Einführungsprojekte bei der Postbank, der Wfa (WestLB), der DZ Bank und der Münchener Hyp; auf den ersten Blick ein guter Querschnitt der deutschen Bankenlandschaft: Eine bundesweit aktive Retail-Bank (Postbank), das Spitzeninstitut einer Regionalbankengruppe (DZ Bank), eine Spezialbank bzw. öffentlich-rechtliche Bank (Wfa) und eine mittlere Regionalbank (Münchenener Hypothekenkbank).

Folgende Problemfelder konnten identifiziert werden:

  • greater testing efforts than initially planned
  • more functionality requirements than covered by the standard software,
  • leading to greater customization efforts than expected,
  • ensuring operational business functionality during the project
  • greater data migration complexity than expected, and
  • general resistance to changes in the employee body, which required specific change management measures.

Das dürften auch heute noch die größten Knackpunkte sein.

Als Erfolgsfaktoren wurden ermittelt:

  • Top management support,
  • High motivation of project staff
  • Rigid project management,
  • Early involvement of business units,
  • Mixed teams including IT and business functions,
  • Management of expectations, and
  • Open communication.

Success factors not identified as such in studies on other industries and thus apparently specific to core banking software introduction were mainly:

  • Step-by-step introduction to control complexity and risk,
  • Thorough definition of requirements and target architecture,
  • Extensive test management,
  • Cross-project coordination to reflect the complex interdependencies typical of banking software support processes across business units,
  • Release management coordinating the roll-out of new releases across multiple modules and business units,
  • Good cooperation with the implementation partners, and
  • Process redesign reflecting the standard processes as supported by the standard software

Auch das dürfte noch weitgehend aktuell sein.

Dennoch reißen die Meldungen, die von fehlgeschlagenen, deutlich über den Plan liegenden oder fehlerhaften Einführungsprojekten von Standard-Software berichten, nicht ab, wie im Fall der Raiffeisenbank in der Schweiz. Für internationale Schlagzeilen sorgte kürzlich das “Migrationsdebakel” der britischen TSB Bank.

Wie es aussieht, hält die Suche nach den Erfolgsfaktoren an – bzw. die Beherzigung derselben lässt weiter auf sich warten.

Als Fazit ihrer Studie hielten die Autoren fest:

To improve the findings’ empirical generalizability, more case studies and more detailed data are needed. Further research will therefore strive to broaden the empirical basis of the academic analysis. Subsequently, those results need to be reconciled with and compared to findings from ERP research conducted in other industries. This may lead to a better understanding of how standard application software in an enterprise’s business critical core processes is selected, introduced and managed.

Unterdessen sind die Anforderungen an Standardsoftware im Banking nicht geringer geworden, wie das Beispiel TSB zeigt. Es stellt sich die Frage, ob die Banken sowohl technisch wie auch organisatorisch noch in der Lage sind, die Komplexität des (online) Banking abzudecken. Wenn dann noch der Informationsaustausch mit Dritten über Offene Schnittstelle, Open Innovation, Echtzeitverarbeitung, Künstliche Intelligenz/Sprachassistenten, Digitales Onboarding und weitere Aspekte hinzu kommen, erscheint es fraglich, ob die Banken das bisherige Spektrum an Funktionen und Dienstleistungen aufrecht erhalten können. Das Konzept der Universalbank stösst auch in der IT an fundamentale Grenzen.

Bemerkenswert auch, dass selbst Genossenschaftsbanken nicht immer die IT-Systeme der gruppeneigenen IT-Dienstleister wählen, wie bei der Apobank, die sich gegen die Fiducia & GAD und für Avaloq entschieden hat.

Bei der Fiducia & GAD IT sollen die bislang getrennt von einander bestehenden Kernbankensysteme agree und Bank 21 bis zum Jahr 2019 auf eine gemeinsame Plattform, agree, migriert werden. Ob sich die Fiducia & GAD mit dem Wechsel auf agree einen Gefallen getan hat, und vielleicht doch besser Bank21 genommen oder gleich ein neues System entwickelt hätte, darüber kann man durchaus geteilter Meinung sein (Vgl. dazu: Dauerbaustelle Bank-IT).

Ende offen. Fortsetzung folgt.

Weitere Informationen:

What can banks learn from the TSB IT disaster?

Dieser Beitrag wurde unter Bank-IT, Banking veröffentlicht. Setze ein Lesezeichen auf den Permalink.