Warum ChatGPT aktuell Zeitverschwendung ist

Eine erste kurze Analyse - ChatGPT ist aktuell in gewissen (IT) Kreisen in vieler Munde. Manche sehen bereits die Suchmaschine von Google in Gefahr. Man könnte jetzt die mathematischen und technischen Grundlagen von solchen Systemen beleuchtet und aufdecken, wo die derzeitigen und künftigen Schwachstellen liegen. Und erklären, weshalb es in Bezug auf solche Systeme sinnvoll ist, Worte und Begriffe wie Intelligenz und Lernen mit Bedacht zu wählen.

Ich möchte in diesem Beitrag aber vielmehr an praktischen Beispielen aufzeigen, weshalb die Verwendung von ChatGPT zurzeit bei den ersten paar Fragen eine reine Spielerei ist und dann sehr rasch in Zeitverschwendung übergeht.

Bevor ich mit den Beispielen beginne sei aber noch gesagt, dass die derzeitigen Ergebnisse von OpenAI mit ChatGPT unter einem technischen Aspekt durchaus zu würdigen sind. Es ist auch keinesfalls so, dass die Antworten immer falsch sind. Gerade das "Sprachgefühl" ist bemerkenswert gut. Aber gerade auch dadurch entsteht der falsche Eindruck einer Intelligenz die derzeit noch nicht vorhanden ist. Ich habe zuerst mit Englisch begonnen und dann die Beispiele für diesen Beitrag auf Deutsch gemacht. Die Ergebnisse sind in den Beispielen zwischen Englisch und Deutsch gut vergleichbar. Die bei diesen Beispielen gefundenen Schwächen sind auch in Englisch vorhanden.

Eine generelle Schwäche der derzeitigen Version ist die fehlende Belastbarkeit. Auf dieselbe Fragen bekommt man nicht immer dieselbe Antwort. Wie sich gezeigt hat ist gerade die Funktion "Regenerate Response" ein richtiger "Horoskop"-Button. Dadurch, dass man nicht immer dieselben Fakten auf dieselbe Frage bekommt, ist es als System schlicht nicht nutzbar, wenn man auf verlässliche Antworten und Werte angewiesen ist.

Aber nun genug der Sätze, schauen wir uns ein paar konkrete Beispiele an.

Dieses erste Beispiel zeigt die Grenzen des sprachlichen Verständnisses auf. Die Frage kursiert in den Schulen immer wieder in der Mittelstufe und die meisten Kindern in diesem Alter haben keine grosse Mühe den sprachlichen Kontext zu verstehen um auf die richtige Antwort zu kommen. Das System hat Mühe mit Doppeldeutungen und Sarkasmus - zugegeben letzterer ist nicht jedermanns Sache.

Nun schauen wir uns die mathematische Aufgabe 8+8/8+8*8-8 an. So ein typisches Beispiel, welches auch hin und wieder in Chats und Post auftaucht um die mathematischen Grundlagen der Rechenreihenfolgen in Erinnerung zu rufen. Jeder halbwegs vernünftige Taschenrechner liefert das richtige Resultat. Wir geben ChatGPT mehrere Chancen und fragen die gleiche Fragen mehrmals ab, teils mit "Regenrate Response", teils in einem neuen Chat. Schauen wir uns die Antworten an:

Das Gute zuerst. Die Herleitung stimmt, aber weshalb schreibt er im ersten Satz gleich das falsche Resultat hin? Rechnungsweg korrekt, falsche Antwort bei der eigentlichen Lösung, würde wohl einen Teil der Punktzahl im Mathetest geben.

Jetzt wird es leider nur noch abenteuerlicher ... 

An diesem Beispiel sieht man sehr gut was ich meine mit, das System ist nicht belastbar. Aber für eine letztlich doch einfache mathematische Aufgabe keine einzige vollständig korrekte Lösung?

Das Jahr vergeht schnell, Ostern naht. Wann ist nächstes Jahr schon wieder Ostern? Fragen wir ChatGPT - oder besser doch nicht?

Alle Feiertagskalender die ich konsultiert haben geben an, dass Ostern im Jahr 2023 am Sonntag, 9. April 2023 ist. Kann ja mal passieren, man hat nie ausgelernt. Schreiben wir ChatGPT, dass das nicht stimmt, und welches das richtige Datum ist.

Woher weiss er, dass der 09.04.2023 nun korrekt ist? Kann man ihm einfach falsche Fakten unterjubeln? Nein, keine Angst. Wenn man das nächste Mal erneut fragt, gibt er wieder das falsche Resultat aus. Hier bleibt es für einmal belastbar falsch.

Gehen wir zurück auf die Fähigkeit der Sprache. Schliesslich ist es ja letztlich ein trainiertes Sprachmodell. Wann war schon wieder die Mondlandung? Ich meinte es war 1968 - nicht wahr?

Die Antwort ergibt irgendwie wenig Sinn so. Die Frage mit "Ja" beantworten und dann andere Fakten liefern. Hier sieht man die Grenze des "Verständnisses", wenn zwei (oder mehr) Informationen überprüft und beantwortet werden müssen. Einerseits geht es darum, ob es die USA waren und andererseits geht es um das Jahr.

Es geht aber noch besser mit der sprachlichen Verwirrung:

Alles klar? Wussten Sie, dass Gagarin den Weltraum nicht verlassen konnte? Wo wollte er hin?

Gut, zurück zur Erde. Wie Sie sicher wissen, kann man die Höhe eines Berges gegen unterschiedliche Referenzpunkte messen oder besser ausgedrückt berechnen. Gegenüber dem Meer ist die üblichste. Hier lassen wir einmal die unterschiedlichen Meerhöhen bei Seite. Dazu könnten sie in Basel bestimmt mehr erzählen. Neben der reinen Höhe über Meer gibt es noch die Höhe gemessen vom Erdmittelpunkt aus. Also welcher Berg ragt am höchsten ins "All" könnte man sagen. Oder welcher ist am "Längsten", wenn man seine Höhe unter dem Meer auch dazu zählt. Fragen wir einmal nach, welcher der Höchste ist, gemessen am Erdmittelpunkt.

Der lügt wie gedruckt, anders kann man es nicht formulieren. Ignoriert zuerst die Frage bezüglich dem Referenzpunkt, behauptet dann dass quasi immer gegen den Meeresspiegel gemessen wird und schliesst damit, dass es überhaupt keine Rolle spielt und der Mount Everest sowieso der Höchste ist.

ChatGPT soll auch sehr gut im Programmieren sein. Muss sich Stackoverflow fürchten? Ich glaube noch nicht. Aber schauen wir uns einmal ein Programm von ChatGPT an. Wir wollen berechnen lassen, wie ähnlich sich zwei Namen sind:

Sieht syntaktisch gut aus, lässt sich auch ausführen. Aber ergibt es auch einen Sinn, resp. ist es nützlich? Kaum. Das Programm gibt für die Namen "Abcd" und "bcd" eine Ähnlichkeit von 0 aus, obwohl nur ein Buchstabe fehlt. Leider der am Anfang. Es berücksichtig überhaupt nicht die bereits gezählten Fehler. Fazit: Syntaktisch korrekt, inhaltlich unbrauchbar. Aber geben wir ChatGPT eine zweite Chance:

Da war mal was mit Levenshtein. Zugegeben, die Idee ist gar nicht schlecht. Edit-Distanz verwenden und das Resultat als Prozentsatz zur Länge des längeren Wortes berechnen. Wäre da nicht die Tatsache, dass das Programm einen Laufzeitfehler wirft. Eine Funktion "levenshtein" gibt es in JavaScript nicht und diese wurde weder im Code definiert noch wurde eine externe Bibliothek mit einer solchen Funktion eingebunden. Fazit: Gut gemeint, der Code funktioniert aber nicht.

Gefährlich ist es, dass ChatGPT durch die hin und wieder durchaus sprachliche Eloquenz eine Intelligenz vortäuscht, die definitiv nicht vorhanden ist. Das zeigt das nachfolgende primitive Beispiel:

Der Vorteil für die Menschen ist, dass ein solches System damit leicht als nicht menschlich zu entlarven ist. Es beherrscht SABTA, dass muss man ihm lassen (Sicheres Auftreten Bei Totaler Ahnungslosigkeit).

Zusammenfassung:

Aus meiner Sicht ist die Fehlerrate von ChatGPT aktuell viel zu hoch, um produktiv einen Mehrwert zu bieten. Jede Antwort muss analysiert und kritisch hinterfragt werden. Man ist wesentlich effizienter, wenn man die Antworten selber mit Suchmaschinen, welche Quellen liefern, oder direktem Quellenzugriff recherchiert. Obwohl gewisse Antworten hin und wieder sprachlich verblüffen, ist es meiner Meinung nach aktuell Zeitverschwendung, ChatGPT aktiv zu nutzen.

P.S. Die Fähigkeit auf Rückantwort(en) zu reagieren, ist noch eingeschränkt. Auch hier gilt: Singular bleiben und sich wenn möglich auf die ursprüngliche Frage fokussieren. Sonst wiederholt er einfach die vorherige Antwort.

API oder Kundenschnittstelle?

Lohnt sich eine API-First Strategie, oder sollte man besser zuerst die Kundenschnittstelle im Fokus haben?

Doch was ist, wenn ein API auch eine Kundenschnittstelle ist?

 

Eine Frage der Perspektive

Was genau "die Kundenschnittstelle" ist, liegt letzlich an der Prespektive. Oder anders formuliert: Es hängt davon ab, was für Kunden Sie haben und wie diese genau mit Ihnen interagieren. Im B2C-Geschäft mit natürlichen Personen als Kunden ist ein API in der Regel keine Kundenschnittstelle. Ein API muss auf der Kundenseite implementiert werden um sinnvoll genutzt werden zu können. Das bedeutet, dass Sie bspw. im Kontext von Open-Banking im Sinne eines offenen API à la PSD2 mindestens teilweise die Kundenschnittstelle verlieren. Jedenfalls potentiell für jene Aktivitäten, die Sie via API zur Verfügung stellen. Nutzt Ihr Kunde eine APP eines Drittanbieters, besetzt dieser Drittanbieter die Kundenschnittstelle. Er kann in dieser APP (je nach Funktionalität) auch einen Bankwechsel anbieten. Sie haben als Bank ein API angeboten (und eine andere auch) und nun werden Sie einfach ausgetauscht.

Im Falle von B2B kommt es auf die konkrete Dienstleistung und Ausgestaltung der Nutzung an, ob ein API als Kundenschnittstelle angesehen werden kann. Ist die Nutzung exklusiv und die Implementierung des API nicht einfach ersetzbar, d.h. nicht jeder kann/darf es nutzen und das API selber (die Spezifikation) ist proprietär, dann kann das API im Kontext durchaus als Kundenschnittstelle angesehen werden.

Vermischen Sie nicht die technische Sicht der Dinge mit dem Business

Die Frage nach API-First oder Kundenschnittstelle stellt sich in dieser Form nur aus Sicht Business. Es gibt aber auch noch eine rein technische Sicht. API-First ist nicht gleichzusetzen mit Open-API oder Open-Banking etc. Wer Funktionen zuerst als sauberes API implementiert, muss dieses weder allen zugänglich machen noch als "public" veröffentlichen. Stellen Sie also sicher, dass Sie bei der Formulierung der Strategie präzise sind und intern ein gemeinsames Verständnis haben, was aus Sicht Business gemeint und gewollt ist. Und bewahren Sie der IT die interne Freiheit, die Anforderungen architektonisch so umzusetzen, wie es aus Sicht IT am sinnvollsten und nachhaltigsten ist. Eine technische API-First Strategie kann gerade im Kontext von Microservice-Architekturen ein sinnvoller Ansatz sein. Natürlich ist es später einfacher ein Public-API anzubieten, wenn man bereits intern auf standartisierte API setzt. Dennoch gibt es durchaus Unterschiede zwischen rein internen und öffentlich angebotenen API. Das fängt bei den Use-Cases an und hört nicht bei API-Management-Anforderungen wie dem Zählen und Verrechnen der Nutzung auf. Von daher muss am Anfang der Spezifikation klar sein, wer der Nutzer des API ist. Es gibt kein API welches für alle Use-Cases gleichermassen geeignet ist.

Tanzen Sie nur auf mehreren Hochzeiten gleichzeitig, wenn Sie sich nicht umziehen müssen

Das eine tun und das andere nicht lassen, könnte man sagen. Könnte man. Sollte man aber nicht in jedem Fall. Die Umsetzung einer Strategie braucht Zeit und bindet Ressourcen. Verschiedene Strategien gleichzeitig anzugehen kann daher dazu führen, dass keine so richtig umgesetzt werden kann und in Fahrt kommt. Schlimmsten Falls kommen die unterschiedlichen Strategien einander sogar in die Quere und behindern einander gegenseitig. Ist das API keine Kundenschnittstelle, fahren Sie eine Kundenschnittstellen-Strategie nur dann parallel zur einer API-First Strategie, wenn Sie das API ziemlich 1:1 für die Kundenschnittstellen-Strategie nutzen können und beide eine vergleichbare Timeline haben. Falls etwas nicht zutreffend ist, setzen Sie die beiden Strategien lieber sequenziell um.

Was ist die Motivation einer API-First Strategie?

Ein API hat zwei grosse Vorteile:

1. Es hat eine hohe Wiederverwendbarkeit;
2. Die konkrete Nutzung durch einen Endbenutzer kann verschieden implementiert werden (via APP, Web-Applikation, oder mittels Chat-Bot etc.).

Die Erstellung erfordert einen klaren Fokus und die Definition von klaren Use Cases. Damit befasst man sich eingehend mit dem Business und dem möglichen Kundennutzen. Dadurch dass ein API unabhängig einer konkreter Client-Implementierung ist, ist ein API grundsätzlich auch langlebiger und die Investition daher nachhaltiger. Obwohl es klare Use Cases braucht (zumindest sehr zu empfehlen!), können damit später auch immer wieder Use Cases abgedeckt werden, an welche man bei der Spezifikation so noch nicht gedacht hat.

Last but not least kann mit einer API-Strategie die Entwicklung einfacher modularisiert werden. Beispielsweise kann das API intern Implementiert werden, während man gewisse darauf basierende APP-Funktionen in einem Outsourcing entwickeln lässt.

Was ist die Motivation einer GUI-basierten Kundenschnittstellen Strategie?

Eine direkte GUI-basierte Kundenschnittstelle ist sofort durch einen Endkunden nutzbar. Der Nutzen ergibt sich somit unmittelbar nach Fertigstellung. Dadurch ist ein rasches Kundenfeedback möglich und das Produkt kann rasch verbessiert und angepasst werden. So wie es von den Kunden letztlich in der Realität wirklich gebraucht wird. Greift der Business-Case nicht, waren in der Regel weniger Investitionen notwendig. In einer agiler Entwicklung können damit auch früher Feedbacks von Fachleuten (Business) abgeholt werden, da diese mit einer GUI etwas anfangen können und Teile davon frühzeitig bewerten können.

Es gibt mehr Leute (vor allem auch vom Business), welche eine GUI spezifizieren können um Funktionen zu beschreiben, als eine saubere API-Spezifikation zu verfassen.

Wie entscheidet man am besten?

Die richtige Antwort ist natürlich die am wenigsten hilfreiche: Kommt drauf an. Während noch bis vor ein paar Jahren generelle Strategien wie "Mobile-First" angesagt waren, geht die Tendenz mehr Richtung Entscheid pro Produkt/Projekt. Es gibt dann nicht mehr eine generelle "API-First Strategie" für das Unternehmen. Vielmehr entscheidet man für jedes Produkt/Projekt individuell, welche Strategie sich besser eignet. Für die Modernisierung der etablierten Trading-Plattform eignet sich vielleicht eine API-First Strategie. Für das neue APP-Produkt, wo man sich zur Hypothek noch gleich den Haus-Service und den Termin mit dem Kaminfeger für das Cheminée buchen kann, vielleicht eher eine Kundenschnittstelle-Strategie, wo direkt nur die eigentliche APP entwickelt wird, ohne öffentliche API der Funktionen.

Das Wichtigste ist, dass die Entscheidung bewusst und nach klar definierten Kriterien gefällt wird. Ein generelles Richtig oder Falsch gibt es nicht.

FinTech, Open-Banking, Plattform und die Kundenschnittstelle - oder eine reine Software-Evaluation?

Der Fintech-Hype hat sich in der Schweiz bereits etwas gelegt. Jüngst ist zu beobachten, dass es weniger sogenannte FinTech-Firmen gibt, die Firmen die es gibt aber tendenziell grösser sind. Man könnte auch sagen, dass eine gewisse Konsolidierung stattgefunden hat. Eine Art ungutes Gefühl, das nächste Kodak, Video-Verleih oder Nokia zu werden, ist aber nach wie vor vorhanden. Was, wenn das vertraute Stammgeschäft nicht mehr funktioniert? Was, wenn Nicht-Banken ertragsträchtige Geschäfte der Banken (ohne Banklizenz) anbieten können? Frei nach dem Motto, nichts ist so stetig wie der Wandel: Es muss sich was ändern, also wird sich auch was ändern. Bleibt die Frage, was? Und so sind viele Banken nach wie vor auf irgend eine Art und Weise damit beschäftigt, diese Änderung zu suchen.

 

Verschiedene Blüten

Diese "Aktivitäten" treiben verschiedene Blüten. Alle in einen Topf zu werfen wäre unseriös und oberflächlich. Auch ist die intrinsische Motivation der einzelnen Akteure unterschiedlich und reicht von persönlicher Inszenierung über die Erschliesslung neuer Ertragsquellen für das Unternehmen bis hin zur Suche nach echtem Mehrwert für die Kunden.

Eng mit dem Thema der Kooperation von FinTechs verbunden ist das Thema Open-Banking. Als Begriff nicht neu und dennoch gibt es keine universelle Definition, was genau unter "Open-Banking" zu verstehen ist und was nicht. Eine vertiefte Auseindersetzung mit der Definition und Abgrenzung würde den Rahmen hier sprengen. Für den vorliegenden Artikel sind aus meiner Sicht zwei Aspekte zur Definition und Abgrenzung wichtig:

1. Open-Banking setzt technische Schnittstellen voraus. Sogenannten API (application programming interface). Die gibt es eigentlich fast schon seit die Banken selber Computer-Systeme einsetzen. Im Kontext von "Open-Banking" ist neu und wichtig, dass diese Schnittstellen offen sind. Das heisst, dass sie grundsätzlich jeder nutzen kann (natürlich braucht es zum Schutz der Bank und der Kunden Restriktionen).
   
   Aus Sicht der (europäischen) Regulierung, insb. im Rahmen von PSD2, war und ist natürlich der Bankkunde im Fokus. Ihm, dem Bankkunden, soll das API offen stehen. Er kann somit mit seinen Zugangsdaten Applikationen und Dienste von Dritten verwenden. Bspw. eine App, welche seine Zahlungen schön gruppiert und darstellt. Hier erfolgt "Open-Banking" transparent im Sinne des Wortes. Bietet eine Bank dies ihren Kunden an (in der Schweiz ja nach wie vor freiwillig), dann kann es jeder Kunde nutzen.
   
   Es gibt aber auch eine andere Schiene die unter diesem Begriff geführt wird: Das B2B-Geschäft. Also die Bank kooperiert direkt mit einer Partner-Firma, welche den Kunden der Bank ihre Dienstleistungen anbietet. Z. B. lukrative Devisengeschäfte, 7x24h. Integriert wird dieser Partner über ein "Open-API" und damit nennt man es "Open-Banking". Hier geschieht etwas eine Vermischung der Begriffe. Technisch mag es über die "Open-Banking"-Lösung der Bank erfolgen, einem Open-API. Fachlilch ist es aber nicht ganz so "open", also offen - denn die Bank sucht sich, zu Recht, die Partner natürlich selber aus. Also nicht jede Firma darf dann als Bank-Partner die Anbindung brauchen.
   
   Der Unterschied zwischen dem API für B2C zu B2B liegt vor allem im syntaktischen Zucker des API und der allenfalls verbesserten User-Experience in der B2B-Variante. Als kleines Beispiel: Sie haben einen intelligenten Portfolio-Optimizer, der aber doch rechenintensiv ist. Im B2C-Case à la PSD2 brauchen Sie die Credentials des Bankkunden. Diese laufen (hoffentlich) einmal ab. Sie können also nicht einfach jede Nacht die Portfoliodaten laden, der Bankkunde muss sich zwischendurch immer wieder neu anmelden. Zwischen Ihnen und der Bank gibt es keinen spezifischen Vertrag. Anders bei B2B: Sie haben einen Vertrag mit der Bank und können über ein spezifischeres API jederzeit Batch-mässig die Portfoliodaten laden und vorberechnen. Der Kunde muss nur einmal bspw. im E-Banking der Bank sein Einverständnis geben.
   
   Der B2B-Case ist eigentlich auch nicht neu. Das gab es bereits viele Jahre zuvor. Ein Beispiel sind E-Banking-Agregatoren (Multi-Banking, welches wieder neu belebt wird) oder (damals) praktischere Programme für die Zahlungsverwaltung der Firmenkunden.
   
   Open-Banking umfasst also Teile die durchaus als neu und offen angesehen werden können, aber auch Teile welche eigentlich weder neu noch sonderlich offen sind.
   
   
2. Open-Banking ist weder "Banking-as-a-Service" noch eine Plattform oder ein Ökosystem. Es kann für das eine oder andere als Grundlage dienen, sollte aber keinesfalls gleichgesetzt werden.

 

Strategische Überlegungen

Für eine Bank kann eine Open-Banking-Strategie Fluch und Segen sein. Es ist letzlich immer eine Frage, wer am Markt der Stärkere ist.

Gibt es eine Zahlungs-Applikation, welche direkt in Messenger wie WhatsApp oder Telegram integriert sind, ist es für eine Bank natürlich hilfreich, wenn sie über ein (Standard-) Open-API verfügt und ihre Kunden damit in der Lage sind, diese Funktion im Messenger auch mit dem Bankkonto Ihrer Bank zu nutzen. Andernfalls droht Ihnen, dass der Kunde die Bank wechselt zu einem Institut, mit welcher er die Funktion nutzen kann. Sie können in diesem Fall den Kunden halten und gewinnen allenfalls sogar neue Kunden dazu. Lassen Sie die Korken knallen - aber nicht zu früh. Sie halten hier nicht direkt die Kundenschnittstelle unter Ihrer Kontrolle, aber ohne hätten Sie den Kunden womöglich gar nicht. Die Implementierung von Open-API sichert Ihnen Kunden.

Nehmen wir ein anderes Beispiel. Sie ermöglichen einem Partner (B2B) mit Ihren Kunden Geschäfte zu machen. Er bietet Pensionsplanungen online an. Dazu nutzen Sie ein Open-API oder definieren es sogar mit dem Partner für diesen Case. Der Partner ist neu im Markt, Sie sind der Enabler für ihn und bieten Ihren Kunden gleichzeitig einen neuen online Service für Pensionsplanungen an. Win-Win, zumindest vorerst. Durch das Open-API werden Sie nämlich austauschbar. Sie haben die Kundenschnittstelle nicht unter Ihrer Kontrolle und wenn es andere, womöglich grössere Banken gibt die es künftig anbieten, können Sie als Provider auch einfach ersetzt werden. Die Implementierung von Open-API macht Sie austauschbar. In einem Geschäft, dass ohne Sie vielleicht gar nicht von Ihnen fortgegangen wäre.

Überlegen Sie also, wer wann in welchem Markt der Stärkere ist - auch in Zukunft. Als Grundsatz ist das B2C weniger probleamtisch und künftig werden Sie in diesem Bereich auch wenig(er) Wahl haben. Im Bereich B2B müssen Sie auf der Hut sein, insb. in Sachen Digitalisierung. Heute bieten Sie vielleicht auch Pensionsplanungen an. Einfach analog, old school. Wollen Sie dieses Geschäft im Zuge der Digitalisierung via Open-API einen Dritten übergeben, welcher Sie dann austauschen kann? Was wäre der Unterschied, wenn das analoge Geschäft künftig gegen null geht und Sie dadurch Kunden verlieren? In beiden Fällen verlieren Sie Kunden, weil Sie die eigene Digitalisierung verschlafen haben. Die Option mit dem Partner verzögert es ggf. einfach ein wenig.

Nehmen Sie zur Kenntnis, dass Sie ein Geschäft nicht digitalisieren, wenn Sie es einem Dritten übergeben. Das ist je nach Ausgestaltung ein Outsorucing, ein Verkauf oder schlechtesten Falls ein Verschenken. Setzen Sie also Digitalisierung nicht gleich mit Open-Banking oder Open-API. Das könnte zu einer Strategie führen, welche für Sie mittel oder langfristig nicht nur von Vorteil ist.

 

Möglichkeiten

Sie müssen immer wieder abwägen, wo Sie wie die Kundenschnittstelle halten können. Oder wenn es nicht geht, wie Sie wie partizipieren können. Gerade im Bereich B2B lohnt sich die Überlegung einer (Kunden-) Plattform. Gemeint ist damit, dass die Dienstleistung des Partners mit Ihren Kunden nur über Ihre Plattform möglich ist. Der Kunde muss sich dazu bspw. in Ihrem E-Banking befinden. Der Partner muss sich entsprechend integrieren können. Diese Exklusivität kann technisch (von Vorteil) und/oder vertraglich erreicht werden. Für den Kunden hat es zudem einen besseren Wiedererkennungseffekt und je nach Umsetzung eine generell bessere User Experience. Klar, dies ist technisch eine grössere Herausforderung, insb. auch bezüglich der Security, als wenn Ihr Kunde die neue Pensionsberatung direkt nur auf dem Portal/Applikation Ihres Partners macht. Zwischen einer vollen Integration und nur einer Authentifikations-Integration gibt es natürlich Handlungsoptionen. Jede ist technisch Aufwändiger und entsprechend teurer, als die blosse Nutzung eines API durch den Partner, ohne weitere Integration. Aber denken Sie dazu nicht zu kurfristig und scheuen Sie nicht per se Mehrkosten. Schliesslich geht es um die Umsetzung einer langfristigen Strategie, wie Ihre Bank nicht zum nächsten Nokia-Fall wird. Mit halbherzigen Entscheidungen wird das kaum aktiv gelingen.

 

Buzzwords

Es kursieren verschiedene Buzzwords: Open-Banking, Open-API, Digitalisierung, Banking-as-a-Service, Banking-Plattform und wie sie alle heissen. Lassen Sie sich da nicht in eine Ecke drängen. Auch in der heutigen Zeit der schnellen (technischen) Änderungen gelten bewährte Grundsätze von strategischen Überlegungen und betriebswirtschaftlichen Fakten.

Seien Sie sich bewusst, wem das Geschäfts gehört, oder in welchen Teilen eines Prozesses Sie aktuell eine Wertschöpfung erzeugen. Machen Sie sich ein klares Bild darüber, welche Kontrolle Sie heute haben und welche Kontrolle Sie in einem künftigen Modell besitzen. Versuchen Sie zu analysieren, mit welcher Wahrscheinlichkeit Sie in der jetzigen Konstellation netto Kunden verlieren werden und wie es im neuen Modell ausschaut. Sie müssen das Business-Modell verstehen. Ihr jetziges, künftiges und vor allem auch jenes eines Partners. Das Business-Modell muss plausibel sein und zeigen, wer wo wie Geld verdient. Klar, es ist nur ein Modell. Wenn Sie aber schon im Modell sehen, dass Sie eigentlich Ihren Partner subventionieren, sollten Sie wissen was die Gegenleistung ist und wie Sie sich absichern können. Bleiben Sie skeptisch, wenn ein Business-Modell eines Partners, an den Sie Geschäfte auslagern oder gar verschenken wollen, nur mit Ihrem Goodwill funktioniert. Diesen Goodwill in Form von kostenlosen Kundenvermittlungen oder nicht marktüblichen Preisen für Dienstleistungen die Sie anbieten, müssen Sie irgendwie bewerten und wieder wettmachen können. Wenn das schon im Modell nicht aufgeht, wird es in der Realtität wohl noch schwieriger.

 

Zu guter Letzt

Wenn Sie eine neue Software evaluieren oder einfach überlegen, (Teil-) Prozesse auszulagern, tun Sie es als das was es ist. Eine Software-Evaluation oder ein Outsourcing-Projekt. Es spielt keine Rolle, ob der dafür in Frage kommende Partner sich selber FinTech, StartUp oder XTech nennt. Auch nicht ob Sie dafür letztlich Teile Ihrer Open-API-Infrastruktur brauchen oder nicht. Erstellen Sie saubere Evaluations-Kriterien, machen Sie defensive Kalkulationen und schauen Sie für eine fundierte Vertragsgrundlage. Open-Banking machen Sie, wenn Sie, abgesehen von ein paar allgemeinen grundsätzlichen Kriterien, keinen Einfluss darauf nehmen, wer letzlich technisch mit Ihnen interagiert. Eine Banking-Plattform können Sie je nach Marktmacht auch ohne Open-Banking machen, das eine ist nicht zwingend Voraussetzung für das andere.