Build vs. Buy – ein heikles Thema für Banken

Die Digitalisierung hat in den letzten zehn Jahren nahezu jeden Lebens- und Arbeitsbereich verändert und dabei vor allem etablierte Branchen drastisch durcheinander geschüttelt. Auch der traditionell sehr konservative Bank-Sektor wurde davon nicht verschont. Internet, FinTechs & Mobile Computing sind nur drei Trends, die nahezu jeden Bereich des Retail-Bankings verändert haben. Konten werden schon lange nicht mehr in der Bank eröffnet sondern meist vom heimischen PC aus. Aber selbst dieser wurde bereits Mitte 2017 vom Smartphone von Platz 1 verdrängt. Heute wird die Mehrheit neuer Einlagenkonten vom Handy aus beantragt.

Selber machen oder kaufen?

Der Drang, Bankprodukte digital einsatzbereit zu machen (und dies möglichst schnell), hat die alte „Buy vs. Build“-Debatte in den IT-Abteilungen der Banken neu angestoßen. Die Kernfragen dabei lauten: Sollen wir die digitale Onboarding-Software von Grund auf selbst entwickeln? Oder kaufen wir Standardlösungen von Drittanbietern, die dann angepasst und in unsere Systeme integriert werden müssen?

Es ist kein Geheimnis, dass die Mehrheit der heutigen IT-Projekte im Bankenbereich sowohl Build als auch Buy verwendet. Aber dennoch neigen Banken dazu, sich häufig für die „Build“-Option zu entscheiden. Der Grund: Die Entwicklungsteams denken, dass sie neue Lösungen schneller selber entwickeln können, als wenn sie externe Produkte in die bestehende IT integrieren müssen. Aber das ist ein Missverständnis. Forschungen von Forrester zeigen, dass mehr als die Hälfte aller Projekte länger als erwartet dauern und in unfassbaren 88% der Fälle das geplante Budget sprengen.

Build ist (meist) zu teuer und zu langsam

Dies führt zu einem sprunghaften Anstieg der „technischen Verschuldung“ – ein Problem, mit dem sich die Banken vertraut machen und welches sie genauso ernst nehmen sollten wie eine monetäre Verschuldung. Die “Total cost of ownership” (TCO) für intern entwickelte Lösungen ist in 64% aller Fälle laut Forrester höher, als wenn man sich extern hätte helfen lassen.

Das Ganze führt darüber hinaus zu einem negativen Schneeballeffekt: Projekte mit problematischer Umsetzung erfordern meist endloses Nacharbeiten und verursachen hohe Wartungskosten. Dies entzieht dem Entwicklungsteam Zeit und Ressourcen, die besser in die Aktualisierung des bestehenden Angebotes investiert würden. Denn die sich ständig ändernden Bedürfnisse der Kunden erfordern regelmäßige Updates und Anpassungen der IT-Systeme. Kein Wunder also, dass laut Forrester nur ein Drittel der Anwendungen den jährlich benötigten Facelift erhält.

Buy vs. Build ist überholt

Wenn Banken in einer sich schneller drehenden Welt weiterhin erfolgreich sein wollen, dann müssen sie wegkommen vom schwarz-weiß sehen und die „Buy vs. Build“-Debatte, die so oft zu internen Kurzschlussreaktionen á la “Selbstbaukasten” führt, beenden. Die noch immer weit verbreitete Tendenz, die digitale Transformation als eine Reihe von Off-One-Projekten zu sehen, muss endlich überwunden und das ganze als eine ganzheitliche, kontinuierliche Evolution betrachtet werden.

Die Abneigung gegen “Buy” stammt aus einer Zeit, in der Third-Party-Produkte quasi Black Boxen waren, die wenig Flexibilität boten und sich nur schwer anpassen bzw. in die bestehende Architektur integrieren ließen.

Doch diese Zeiten sind längst passé. Das Aufkommen von Plattform-Technologie und APIs sorgt dafür, dass Banken heute relativ einfach externe Fintech-Entwicklungen in ihre bestehenden Lösungen integrieren können. Und das sogar oft so, dass es den Kunden gar nicht auffällt, so dass das eigene Branding bestehen bleibt. Es macht daher heute mehr Sinn, bestehende Lücken im eigenen Angebot modular und frei nach dem Motto „mix and match“ zu schließen.

Der Neue heißt BBEA

Wie also sollten Banken ein neues Projekt zur digitalen Transformation idealerweise angehen? Die Antwort heißt BBEA: „Buy, Build, Extend and Assemble“ (Kaufen, Bauen, Erweitern und Zusammenfügen).

Die Faustregel lautet hier, dass Dienstleistungen und Fähigkeiten, die allgemein und nicht nur für die Bank bestimmt sind, von Experten mit nachgewiesenen Fähigkeit bezogen werden sollten. Warum sollte man einen längeren Entwicklungszyklus und höhere Gesamtbetriebskosten in Kauf nehmen, indem man das Rad neu erfindet? Dadurch werden interne Ressourcen der Bank frei, um an Services zu arbeiten, die wirklich einzigartig für das Wertangebot der Bank sind.

Die Nutzung von externen Lösungen reduziert die technische Verschuldung und verteilt die Kosten für Forschung und Entwicklung auf externe Akteure. Der Plattformansatz erleichtert es den Banken, diese externen Komponenten an ihre eigene Marke und die spezifischen Gegebenheiten anzupassen, und macht die Adaption an sich ändernde Bedürfnisse wesentlich einfacher.

Banken, die in ihren digitalen Transformationsstrategien vorankommen wollen, müssen ihre alten Entwicklungsgewohnheiten aufgeben und einen Plattformansatz verfolgen, denn Build vs. Buy ist tot – es lebe BBEA !

Wie stehen Sie zu der „Buy vs. Build“-Debatte?

Sprechen Sie uns gerne an!

Autor Steve Demchuk

Steve Demchuk

Chief Product Officer bei Avoka Avoka

Artikel teilen

Kommentare

Eine Antwort auf “Build vs. Buy – ein heikles Thema für Banken

  • Sebastian

    Netter Sales-Artikel. Gerade die großen Banken haben mit massiv überhöhten „Buy-Quoten“ in den vergangenen Jahrzehnten massiv interne Kompetenzen für die Entwicklung innovativer, differenzierender Produkte eingebüßt. FinTechs und Challenger Banks setzen jetzt wieder bewusst auf interne Entwicklungsteams die mit modernen Methoden und Technologien schnell Produkte entwickeln. Commodity wie Reg Reporting u.ä. wird selbstverständlich eingekauft. Aber gerade Integrations-Know-How und die Frontends/Workflows aus der Hand zu geben halte ich für grob fahrlässig.

    Antworten

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

BankingHub-Newsletter

Analysen, Artikel sowie Interviews rund um Trends und Innovationen
im Banking alle 2 Wochen direkt in Ihr Postfach

Send this to a friend