Mensch und KI – Team der Zukunft?

Mit großem Interesse habe ich Thomas aktuellen KI-Blogeintrag gelesen und muss auch mich selbst als #KI-fiziert outen. Im Gegensatz zu meinem geschätzten Kollegen werfe ich nun zum Jahressende jedoch einen weitaus weniger düsteren Blick auf das Thema Künstliche Intelligenz.

Dass sich dank des technologischen Fortschritts und der zunehmenden Menge an verfügbaren Daten bereits spektakuläre Ergebnisse mithilfe von KI-Algorithmen erzielen lassen, ist mittlerweile allgemein bekannt. Dabei stellte ich mir in der Vergangenheit jedoch oft die Frage: Wo bleibt angesichts dieser ganzen Entwicklung eigentlich der Mensch?

Irgendwie drängt sich mir beim Thema KI das Gefühl auf, dass der Mensch primär im Kontext der Arbeitskrafteinsparung gesehen wird. Dies ist aus meiner Sicht aber weder der einzige, noch der vielversprechendste Nutzen der Technologie. Also: Lasst uns doch mal den Fokus auf die optimierte Zusammenarbeit von Menschen und intelligenten Maschinen, die sogenannten intelligente Mensch-Maschine-Kollaboration (iMMK) legen. 

In Anlehnung an das Zitat „Computers are incredibly fast, accurate, and stupid. Humans are incredibly slow, inaccurate, and brilliant. Together they are powerful beyond imagination“ wird bei der iMMK die Intelligenz des Menschen um die Intelligenz der Maschine erweitert. 

Aber wie kann eine solche iMMK konkret aussehen und welchen Nutzen beschert sie uns?  Um das zu beantworten, blicken wir am besten erst einmal auf die Limitationen von KI. Zwar erreichen heute, rein statistisch betrachtet, die den KI-Anwendungen zugrundeliegenden Algorithmen in vielen Szenarien bereits sehr gute Ergebnisse. Dies bedeutet jedoch nicht, dass sie keine falschen Entscheidungen treffen. Auch vor Betrugsversuchen, bei denen die Entscheidungen von KI-Systemen bewusst beeinflusst werden und die im Finanzbereich ein großes Problem darstellen, sind diese Lösungen nicht geschützt. Des Weiteren arbeitet Machine Learning im Ansatz oft wie eine Black-Box, sodass der Mensch im Nachhinein keine Auskunft darüber erhält, wie die Maschine zu ihrem Ergebnis gelangt ist. Dies kann in sensiblen und besonders sicherheitskritischen Anwendungsbereichen zu Problemen führen, die durch das Einbinden des Menschen zur finalen Entscheidungsfindung adressiert werden können.

Ein perfektes Beispiel für den erfolgreichen Einsatz intelligenter Mensch-Maschine-Kollaborationen finden wir aktuell bereits in der Medizin. Bei der Entdeckung bestimmter Krebserkrankungen anhand von Bilddaten erzielen KI-Anwendungen bereits höhere Erfolgsquoten als Mediziner aus Fleisch und Blut. Positiver Nebeneffekt: Unerfahrene Ärzte lernen nach einer Unterstützung durch die KI, selbst bessere Diagnosen zu stellen. Der Mensch lernt also von der intelligenten Maschine. 

Geht es andererseits um das Trainieren von KI-Systemen, sehe ich im Ansatz des sogenannten Human-in-the-Loop-Lernens (HitL) einen weiteren Vorteil einer engen Zusammenarbeit von Mensch und KI. Hierbei interagiert der Mensch nicht nur zu Beginn bei der Datenverarbeitung oder am Ende bei der Dateninterpretation mit der KI, sondern ist ein fester Bestandteil eines interaktiven Lernkreislaufs. Sollte sich die KI beim Treffen einer Entscheidung unsicher sein, so kann der menschliche Trainingspartner unterstützend eingreifen. Weiterer Vorteil des engen Teamworks: Durch die integrierte menschliche Interaktion funktionieren auch solche KI-Anwendungsszenarien, für die vergleichsweise wenig Daten zur Verfügung stehen. Denn im Zweifel greift der menschliche Partner ja unterstützend ein. Aus diesem Feedback lassen sich wiederum neue Trainingsdatensets erstellen, die entweder direkt oder nachgelagert zur kontinuierlichen Verbesserung des KI-Systems verwendet werden können.

Dies sind nur einige Beispiele. Die Kollaboration von Menschen und intelligenten Maschinen bietet zahlreiche weitere Einsatzmöglichkeiten, um das menschliche Entscheidungsverhalten zu verbessern oder – dank der jeweiligen Stärken der beiden unterschiedlichen Partner – Aufgaben zu lösen, die weder die Maschine noch der Mensch alleine bewältigen kann. Der Einsatz von KI macht den Menschen meiner Ansicht nach daher keineswegs obsolet, sondern bildet in vielen Szenarien vielmehr eine Plattform, die unter Zuhilfenahme menschlicher Stärken erst ihr volles Potenzial entfalten kann.
Eigentlich keine schlechten Voraussetzungen für Mensch und Maschine, um das Team der Zukunft zu bilden. Oder?

Viele Grüße
Omar Hensel

RegTech News! 11. RegTech-Beitrag "Digitales Signieren" ist jetzt online

Liebe Leserinnen und Leser, 

RegTech ist im Dialog mit Finanzinstituten nicht mehr wegzudenken. Aber wofür steht der Begriff, was bedeutet er in der Praxis, welche Anwendungsfälle bestehen im Compliance-Umfeld, wie fügt sich RPA in den Themenkomplex ein?

All diese Fragen behandeln wir seit längerem in einer Reg-Tech Beitragsserie. Natürlich wollen wir Ihnen unseren Blog-Lesern diese Beiträge nicht vorenthalten!

Deshalb erhalten Sie ab sofort zu jedem neuen RegTech Beitrag News auf diesem Blog und heute geht es weiter mit dem 11. RegTech Beitrag:

Kontaktlos, effizient, zeitnah: digitales Signieren: Digitales Signieren

Gerade in unerwarteten Situationen wie der Pandemie im Jahr 2020 ist die Digitalisierung verschiedenster Geschäftsprozesse ein wichtiger Baustein für flexibles und erfolgreiches Handeln. Mangelnde Akzeptanz kann dabei schnell zum Hemmschuh werden: Kontaktloses Bezahlen wird bereits von vielen genutzt und ist eigentlich selbstverständlich. Dagegen gibt es bei der Benutzung der digitalen Signatur noch viel Verbesserungspotenzial, sowohl bei Privatpersonen als auch auf Seiten von Unternehmen und Banken. So wären beispielsweise im Rahmen der Vertragsbeziehung zwischen Bank und Kunde oder in der Kommunikation zwischen Bank und Aufsichtsbehörde die Nutzung elektronischer Unterschriften in der Breite ein echter Fortschritt. Doch was ist dabei zu beachten und wie funktioniert das technisch? Jetzt weiterlesen

Alle weiteren Informationen und Leistungen rund um das Thema RegTech erhalten Sie hier.

Viel Spaß beim Lesen
Ihre Sandra Reinhard


PS: Lesen Sie auch unsere anderen Beiträge zum Thema RegTech!

Teil 2: KI-fiziert! – Ich sehe was, was du nicht hörst – Es war einmal … die Evolution der Künstlichen Intelligenz und ihre bösartige Instrumentalisierung!

Und täglich grüßt erneut ein Fakt … ähm ich meine: ein neuer Fake!

Das letzte Mal haben wir festgestellt, dass der Mensch mit dem Einsatz von KI zwar bedeutend schneller Entscheidungen treffen und komplexe Sachverhalte gezielter lösen kann – aber eben intelligent im herkömmlichen Sinne ist KI deswegen noch nicht. Oder doch? Und dann war da ja noch die Frage nach intelligenten Maschinen die womöglich bereits telefonieren können.

#Fake Fakt Future

Wie ergeht es euch eigentlich mit der sich immer mehr und mehr verzerrenden Grenze zwischen Fiktion und Realität? Ich muss zugeben, dass die Differenzierung zwischen Fake und Fakt heutzutage zunehmend komplexer wird. Wie ich darauf komme? Erst im Jahr 2018 hatte der Konzern Alphabet (zu dem Google gehört) verlautbaren lassen, dass seine KI-Innovation namens Google Duplex mit Hilfe von NLP (Natural Language Processing) im Namen des Nutzers Anrufe tätigen und Termine planen könne. Anders gesagt, eine Maschine soll – ohne mein wesentliches Zutun – selbstständig beim Restaurant, Friseur oder Arzt anrufen und einen Termin in meinem Namen organisieren können. Bemerkenswert ist, dass Google bereits seine Maps-Einträge auf diesem Wege aktuell hält. Eigenen Angaben zufolge hat die KI-Telefonie seit Beginn der COVID-Pandemie schon über Dreimillionen Updates in acht Ländern vorgenommen. Genial! Damit aber nicht genug! Bereits 2017 hatte das kanadische Startup Lyrebird verkündet, KI zu nutzen, um einen Stimmenklon zu erstellen. Und das in kürzester Zeit: Es reichen bereits weniger als fünf Minuten Sprachaufnahme – was gerade einmal 30 bis 60 Sätzen entspricht – und man erhält einen recht adäquaten Klon seiner persönlichen Stimme.

 #Kann man den eigenen Augen und Ohren noch trauen?  

Immer noch nicht futuristisch genug? Okay, dann weiter … Das chinesische Äquivalent zu Google, Baidu, nutzt KI unter anderem in seiner Anwendung Deep Voice. Auch dieses Programm soll im Stande sein, mit bereits geringem Audiomaterial eine Stimme anwendungstauglich und täuschend echt zu klonen. Im Ergebnis können diese digitalen Stimmen-Fakes automatisiert jedweden Text wiedergeben, ohne dass diese vorher real gesprochen worden sein müssten. In gewisser Weise praktisch, wenn man zum Beispiel an die Erstellung von Audiobüchern denkt. Dies wäre in Zukunft ohne Aufnahmestudio oder Autor möglich, da lediglich das Buch in digitaler Form und wenige Minuten der Stimme des Autors ausreichen. Andererseits hat jeder von euch schon mindestens ein sogenanntes Fake-Foto oder sogar Fake-Video gesehen. Solche für das bloße menschliche Auge täuschend echt wirkende Bilder oder eben Bildsequenzen (in Echtzeit!) existieren zuhauf im Internet und stellen jeden Laien vor enorme Herausforderungen, Fälschungen auch als solche zu enttarnen.

 

#Sorgenfrei in die Zukunft oder doch Grund zur Sorge? 

Ihr fragt euch gerade „Und was hat das jetzt alles mit Banking zu tun?!“. Also Vorhang auf für die Transition-Szene. Diese spielt im Frühjahr 2019 und könnte durchaus auch aus einem Science-Fiction-Drehbuch stammen. In der Hauptrolle: Next-Gen-Social-Engineering. Die vorweg erwähnte KI-Software Lyrebird ermöglichte es Kriminellen, die nächste Generation des Human-Hackings einzuläuten. Fast eine Viertelmillion Euro wurden ergaunert, weil der falsche Geschäftsführer am Telefon vom Echten wohl nicht zu unterscheiden war. Dank der überzeugenden Fake-Stimme erhielten die Gauner prompt ihren Wunschbetrag per Überweisung. Der offenbar erste CEO-Betrug (auch bekannt als Fake-President oder BEC-Fraud) der Geschichte durch eine KI-Stimmenimitation! 

#Fight Fire With Fire

Es ist unbestritten, zu was KI fähig ist. Und auch, dass kriminelle Angreifer zügig die vorschreitende Technik adaptieren und im Zusammenhang mit Social Engineering ein mögliches Aufkommen von Zweifel bei Unternehmensmitarbeitern in einer solch speziellen Situation verhindert. Selbst Internetgiganten wie Google und Twitter waren in diesem Jahr schon Opfer von Social Engineering. Diese Erkenntnis bringt mich zum Grübeln, inwiefern analoge Präventionsmaßnahmen heutzutage noch zeitgemäß sind. Sensibilisierung durch Plakate oder Informationskampagnen im Intranet sind ganz klar zu hinterfragen. Aber wie sich effizient davor schützen, Opfer einer CEO-Attacke durch KI zu werden? Die Antwort ist eindeutig: Bekämpfe Feuer mit Feuer. Oder, anders gesagt: Ihr kommt nicht umhin, euch selbst zu KI-fizieren ... also euch mit Künstlicher Intelligenz, ihren Potenzialen sowie Lösungsmöglichkeiten auseinanderzusetzen und schlussendlich diese auch tatsächlich zu nutzen. 

#Prädikat: Faszinierend

In puncto Cybercrime haben wir bei PPI die KI-Fizierung genutzt und einen ersten Prototyp zur wirksamen und echten Prävention von zum Beispiel Social Engineering entwickelt. Von Continues-Smart-Learning bis hin zur hellseherischen Predictive Analytics in Echtzeit loten wir alle KI-Potenziale aus. In unserem jüngsten RegTech-Beitrag haben wir diesen zukunftsweisenden Pfad unbegrenzter Möglichkeiten beschritten und für euch ein Stück weit detaillierter ausgeführt. Schaut doch mal rein! Und wer es vor lauter Spannung nicht abwarten kann und mehr erfahren möchte, kommt einfach direkt auf mich zu. In diesem Sinne zitiere ich zum Schluss Captain Kirk mit den Worten „Ende der Ansprache, an die Arbeit“!
 

Euer Thomas

KI-fiziert! – Evolution der Künstlichen Intelligenz – Macht sie uns wieder zum Affen?

Photo by Nick Bolton on Unsplash
Teil 1: Virus KI – Herkunft und Übertragung 

#Zurück in die Zukunft
Der Cyberraum, unbegrenzte Möglichkeiten. Wir schreiben das Jahr 2200 – ich meine natürlich 2020. Nein, dies sind nicht die Abenteuer des Raumschiffs Enterprise, ich hatte lediglich in der COVID-Lockdown-Phase zu viel Fernsehen geschaut! Irgendwie packte mich das Science-Fiction-Genre, da hier bereits seit mehreren Dekaden das vermeintlich „Undenkbare“ oder gar „Unmögliche“ eindrucksvoll vermittelt wird. Egal ob in Kassenschlagern wie „Passengers“ oder Klassikern wie „2001: A Space Odyssey“, in denen ein Raumschiff über intelligente Bordcomputer verfügt. Oder irdische Legenden der Traumfabrik wie „Metropolis“, die das faszinierende Potenzial synthetischen Intellekts in Form von Robotern veranschaulichen. Geradezu evolutionär geht es in Sci-Fi-Blockbustern wie „Blade Runner“ und „Terminator“ zu. Sie illustrierten Maschinen mit Künstlicher Intelligenz (KI), die fähig sind, sich letztlich wie ein Mensch zu verhalten, also selbstständig und abstrakt zu agieren und obendrein zweckvolles Handeln situationsbedingt abzuleiten – intelligent eben.

#Achtung die Türen schließen
Ganz offensichtlich bin ich bereits KI-fiziert! Entgegen jener Zukunftsvisionen möchte ich hervorheben, dass wir dieses technische Evolutionsstadium noch nicht erreicht haben. Nichtsdestotrotz fahren wir auf dem immer rasanter werdenden Digitalisierungszug und sind Zeugen einer „KI-fizierung“ unserer Umwelt. Dies zeigt sich insofern, indem mit Roboterunterstützung wiederkehrende Aufgaben/Prozesse schon heute automatisiert werden und damit deutlich effektiver und effizienter sind, als es wir Menschen je abbilden könnten.

#Top Skills der Überträger
Aber auch digitale Helfer wie Siri, Alexa oder Google Assistent sind längst fester Bestandteil unseres Alltages geworden. Sie bedienen sich unterschiedlicher Methoden des künstlichen Intelligenzspektrums – speziell dem maschinellen Lernen oder auch Machine Learning (ML), dem vertieften/mehrschichtigen Lernen alias Deep-Learning (DL) sowie der maschinellen Verarbeitung natürlicher Sprache respektive Natural Language Processing (NLP).

Seit dem Ende der industriellen Revolution im späten 19. Jahrhundert haben wir Technik neu erfunden und immer weiterentwickelt. Heute, im Jahr 2020 verstehen Maschinen unzählige Sprachen, können darauf basierende Ergebnisse herleiten und sogar relativ authentisch antworten. Das Computerprogramm „Watson“ von IBM besitzt die Fähigkeit, den Sinn einer in natürlicher Sprache gestellten Frage zu erfassen und in kürzester Zeit relevante Fakten darzulegen. Und das ist nur eines von vielen KI-Beispielen.

#Doch nur Logik und Mathematik?
Aber losgelöst von Watson, Alexa oder Siri – die vermeintlich natürliche Unterhaltung mit dem Handy entspringt letztendlich „doch nur“ den Auswertungen von Unmengen an historischen Daten. Die Maschinen erkennen algorithmenbasiert etwaige Muster und Querverbindungen in jenen Daten und generieren darauf basierend „Wissen“ beziehungsweise „Erfahrungen“. Okay, das klingt jetzt erstmal alles ziemlich futuristisch. Intelligenz im herkömmlichen Sinne repräsentieren diese Algorithmen wohl noch nicht. Sonst könnten jene Maschinen anhand von generierten „Erfahrungen“ Unbekanntes bewerten und eigenständig darauf angepasst sowie situationsabhängig Entscheidungen ableiten.

#Was die Maschinen wohl dazu sagen
Ergo ist es dem Menschen heute zwar möglich, mit dem Einsatz von KI bedeutend schneller Entscheidungsoptionen abzuwägen, komplexe Sachverhalte gezielter sowie wirksamer zu lösen und sogar herkömmliche Abläufe zu automatisieren – nur autonom agieren, auf Unbekanntes reagieren oder gar reell telefonieren können diese scheinbar intelligenten Maschinen eben nicht. Zumindest noch nicht. Oder doch?

Die Antwort auf diese Frage gibt’s in meinem zweiten Teil! Und was das Ganze mit Banking zu tun hat, werde ich auch lüften. Seid also gespannt!


Euer Thomas

Teil 3: Agile Transformation in Banken und - die Schildkröte: Achillesferse des Scrum #agile

Die Geschichte aus der griechischen Mythologie ist ein bekanntes Paradoxon: Ein Wettrennen zwischen Achilles und einer Schildkröte. Beide starten zum selben Zeitpunkt, aber die Schildkröte bekommt einen Vorsprung, da sie vermeintlich langsamer ist. Obwohl Achilles schneller ist, wird er die Schildkröte nicht einholen können. Auch im Scrum sind die Schildkröten die Achillesferse, allerdings findet hier kein wirklicher Wettlauf statt und es handelt sich nicht um tatsächliche Schildkröten, sondern um IT-Prozesse. 


Was nützt jemand, der schnell mauern kann, wenn derjenige, der die Steine anreicht, eine lahme Schildkröte ist?


Scrum beschreibt ja nur einen Teil der IT-Prozesse, nämlich den der Softwareentwicklung, um eine Software erfolgreich einzusetzen benötigt man jedoch auch die angrenzenden IT-Prozesse wie Release-Management, Testmanagement, Service Desk oder Infrastruktur Management. Auch diese Prozesse muss ich „agilifizieren“ oder aber zumindest klare Schnittstellen zu ihnen definieren. Warum das so ist, mache ich gerne an einem Beispiel klar. Wir wollen ein Haus bauen und unser Scrum Entwicklerteam ist ein Maurer, der unglaublich schnell mauern kann. Dieser nützt mir aber nichts, wenn derjenige, der ihm die Steine zum Mauern anreicht eine lahme Schildkröte ist. Der Maurer wird nie in der Lage sein, seine Schnelligkeit ausspielen zu können, sondern die meiste Zeit auf neue Steine warten.

Warum diese Prozesse so wichtig sind in der agilen Entwicklung zeige ich anhand einiger Beispiele. Da der Punkt Infrastruktur managen sehr weit weg von den Entwicklungsprozessen von Scrum zu sein scheint, zeige ich hier mal die erste IT-Schildkröte auf. 


Mal eben eine neue virtuelle Testumgebung bestellen? Hardware bei Amazon bestellen, geht schneller…


Folgendes Szenario: Für ein neues Feature benötige ich zwingend eine neue Version der Programmiersprache. Da in der Produktion aktuell diese Version nicht läuft, ich aber bis zu deren Upgrade auch Bugfixes auf dieser Version erstellen muss, muss ich parallel auf verschiedenen Testumgebungen arbeiten. Dauert die Bestellung einer solchen Testumgebung sechs bis acht Wochen, wie ich es schon erlebt habe, kann ich drei bis vier Sprints diese Funktionalität nicht implementieren, obwohl hoch priorisiert und auch genügend Kapazität bei den Entwicklern vorhanden ist. Die schnellste Bereitstellung, die ich bislang bei Banken erlebt habe, war eine Bereitstellung innerhalb von 24 Stunden, aber kaum eine Bank schafft dies. Das Zauberwort an dieser Stelle ist Infrastructure as a Service, kurz IaaS, also die Bereitstellung einer Infrastruktur „per Knopfdruck“.


Die Hardware ist da, aber ich teste nach dem Chinesenprinzip…


Aber bleiben wir mal realistisch und sagen, die Umgebung steht nach sechs Wochen bereit und ich beginne nun dieses Feature zu entwickeln. Jetzt kommt aber mein Testmanager und sagt, ich müsse aufgrund der neuen Version einen kompletten Regressionstest der Anwendung durchführen. Glücklicherweise stehen gerade zehn Fachbereichstester zum Testen bereit. Und falls mich jetzt jemand fragt, in welchem Universum ich lebe, dass zehn Tester „Gewehr bei Fuß“ bereitstehen, das ist eine rein hypothetische und unrealistische Annahme. Aber selbst mit dieser unrealistischen Annahme bräuchte man mindestens zwei Sprints, um die Regressionstests durchzuführen. Damit wäre die Software nicht fertig und damit nicht releasefähig. Viel schlimmer noch, in den zwei Sprints kann ich ausschließlich Bugs in der Produktion fixen und keine neuen Features entwickeln.


Wenn der Releasetrain von Vogonen geleitet wird, renne ich diesem sechs Monate hinterher…

 
Aber denken wir den Prozess ruhig weiter. Die Regressionstests sind nach zwei weiteren Sprints erfolgreich durchgeführt worden und das Scrum Team sagt stolz, dass die Software nun releasefähig für die Produktion ist. Freudestrahlend begibt sich der Product Owner zum Release Management und möchte seine Software in Produktion bringen. Dieser entgegnet aber nur lapidar, man hätte den Termin zur Anmeldung zum Release leider um eine Woche verpasst und könne erst zum übernächsten Release in sechs Monaten seine Software in Produktion bringen. In solchen Situationen fühle ich mich übrigens häufig an eine Figur aus dem Buch „Per Anhalter durch die Galaxis“ erinnert, den Vogonen: Mies gelaunt, bürokratisch und gefühllos. Geht das eigentlich nur mir so? Um die Kollegen aus dem Release Management mal in Schutz zu nehmen, bei den IT-Prozessen zur Produktivstellung von Software wäre ich auch mies gelaunt, würde mich auf die miesen Prozesse zurückziehen und alle Sonderanfragen rigoros ablehnen.


Von der Entwicklung bis zum Go Life, eine schwere Geburt…


Schauen wir in diesem Beispiel mal auf die Zeitschiene. Zuerst habe ich sechs Wochen gewartet, bis ich die erforderliche Infrastruktur bekommen habe, dann hatte ich in zwei Wochen das Feature entwickelt, um dann weitere vier Wochen auf die Regressionstests zu warten und schließlich 24 Wochen auf die Produktivstellung zu warten. In Summe also 36 Wochen, also neun Monate, für die produktive Nutzung eines Features. In dieser Zeit werden auch ganze Kinder geboren. Natürlich habe ich es in diesem Beispiel ein wenig auf die Spitze getrieben, aber so ganz unrealistisch ist es leider auch nicht. Vielleicht wird jetzt besser klar, was ich mit den Schildkröten meine. 


Wie ich die Schildkröte knacke


Das Zauberwort für deren Beschleunigung heißt Automatisierung. Haben Banken bislang immer die Fachlichen Prozesse im Fokus, Stichwort Industrialisierung, rücken mehr die IT-Prozesse in den Vordergrund, da die Produktivstellung neuer Features oder Produkte für den Kunden immer mehr zum Wettbewerbsvorteil wird. FinTechs machen es vor, hier wird nicht nur schnell entwickelt, die IT-Prozesse sind schlank und meistens auch automatisiert. Ziel muss es sein, die Industrialisierung der IT-Prozesse zeitnah zu ermöglichen, um fachliche Prozessänderungen schnell umsetzen zu können. Scrum ist hier nur ein Teilprozess, Fokus müssen aber immer die End-to-End Prozesse sein, genau wie bei allen fachlichen Prozessen. Das heißt ich muss z.B. auch Infrastrukturen, Tests und Deployments bestmöglich automatisieren, um neue Features zeitnah produktiv einsetzen zu können.


Mein Fazit zu IT-Schildkröten-Prozessen: IT-Prozesse sind ein wesentlicher Faktor bei der Anpassung von fachlichen Prozessen, da diese immer weniger manuelle Tätigkeiten beinhalten. Ziel ist es, die IT-Prozesse durch Standardisierung und Automatisierung zu industrialisieren, um sich dauerhaft gut im Wettbewerb aufzustellen. Grenzen sind hier teilweise durch die Regulatorik gegeben. Darauf gehe ich im nächsten Beitrag ein.

#agil #scrum #it-prozesse #schildkröte #industrialisierung #automatisierung #continuusdeployment #iaas #automatisiertestesten #prozessautomatisierung #agileprozesse

Beste Grüße
Andreas Milanese

PS: Wer nicht abwarten kann oder an einer Beratung interessiert ist, darf auch gerne meine Website besuchen unter: http://www.ppi.de/banken/compliance/agiles-projektmanagement/


 

RegTech News! 10. RegTech-Beitrag "Predictive Analytics" ist jetzt online

Liebe Leserinnen und Leser, 

RegTech ist im Dialog mit Finanzinstituten nicht mehr wegzudenken. Aber wofür steht der Begriff, was bedeutet er in der Praxis, welche Anwendungsfälle bestehen im Compliance-Umfeld, wie fügt sich RPA in den Themenkomplex ein?

All diese Fragen behandeln wir seit längerem in einer Reg-Tech Beitragsserie. Natürlich wollen wir Ihnen unseren Blog-Lesern diese Beiträge nicht vorenthalten!

Deshalb erhalten Sie ab sofort zu jedem neuen RegTech Beitrag News auf diesem Blog und heute starten wir mit dem druckfrischen 10. RegTech Beitrag:

Die nächste Generation der Künstlichen Intelligenz: Predictive Analytics

Gerade in Zeiten wie diesen zeigt sich, dass nahezu alle Branchen die Digitalisierung ihrer Geschäftsprozesse und Geschäftsmodelle beschleunigen. Dabei spielt besonders das Thema der Künstlichen Intelligenz (KI) eine bedeutende Rolle. In diesem Beitrag möchten wir Predictive Analytics vorstellen; eine Technologie, die aus unserer Sicht vor allem bei Banken einen enormen Mehrwert schaffen kann. Gerade im Bereich Compliance beim Einsatz zur Vorhersage von Regelverstößen könnten damit Maßnahmen zur Betrugsprävention ein ganz neues Level erreichen und so effizient sein wie nie zuvor. Jetzt weiterlesen

Alle weiteren Informationen und Leistungen rund um das Thema RegTech erhalten Sie hier.

Viel Spaß beim Lesen
Ihre Sandra Reinhard


PS: Lesen Sie auch unsere anderen Beiträge zum Thema RegTech!

Teil 2: Agile Transformation in Banken- oder die wahre Geschichte der agilen Frustration?! Und was ist Bananensoftware? #agile

Scrum: Just another f** method? Der Agile Change in den Köpfen ist der schwerere

 Ach was habe ich schon alles an unterschiedlichen Methoden kennen lernen dürfen, Wasserfall, V-Modell, Inkrementell iterativ und wie sie nicht alle heißen. Was macht man dann? Natürlich eine Schulung oder schlaue Bücher lesen. Gleiches dachte ich am Anfang auch über Scrum, das wohlgemerkt keine Methode, sondern ein Framework ist. Ich habe mir den Scrum Guide durchgelesen, später dann meine Zertifizierungen zum Scrum Master und Product Owner gemacht, wie so viele andere. Während aber Methoden Ergebnistypen definieren und auch sehr viele Vorlagen hierfür existieren, gibt es so etwas bei Scrum nicht und das ist volle Absicht. Scrum versteht sich, wie oben erwähnt, als ein Framework.

Agile, the new way of thinking.

Das bedeutet, es vermittelt im Wesentlichen eine Idee und einen Rahmen, wie man diese umsetzt. Leider führt das auch dazu, dass Scrum häufig schlecht eingesetzt wird, da die Grundideen nicht erkannt oder umgesetzt werden. Es geht also nicht nur darum, seinen eigenen Werkzeugkoffer zu erweitern, sondern ein Umdenken im bisherigen Handeln herbei zu führen, was wesentlich schwieriger zu erreichen ist. Im Folgenden beschreibe ich meine Sichtweise dieser Grundideen und wie man diese in seiner täglichen Arbeit berücksichtigen kann.

Schon die alten Römer wussten: Divide et impera

Das Agile Framework eignet sich besonders gut in komplexen Umgebungen, bei denen die Kenntnisse der Anforderungen als auch der eingesetzten Technologie nicht sehr hoch sind. In solchen Fällen nimmt man sich einen (Geschäftsvor-) Fall und fängt an, ihn mal zu detaillieren, indem man ihn in kleine Themen zerteilt. Das Konzept ist in der Informatik auch unter dem Stichwort „Divide & Conquer“ bekannt. Ich zerteile ein großes Problem in viele kleine, welche sich einfach lösen lassen. Aber anstatt das große Problem schon mal vollständig zu detaillieren, fange ich schon mal mit der Umsetzung des ersten kleinen Problems an. Habe ich nun so ein kleines Problem gelöst, hole ich mir sofort Feedback ein, welches ich dann wiederum in die weitere Entwicklung einfließen lasse. Dieses Vorgehen wird als Empirisches Vorgehen bezeichnet und unterscheidet sich grundsätzlich von Vorgehensweisen wie dem Wasserfall, bei denen ich die gesamte Lösung komplett beschreiben muss, ohne aber zu dem Zeitpunkt zu wissen, ob dies auch in der Umsetzung funktionieren wird.

Überlebensfähige Software erstellen heißt keine Bananensoftware erstellen

Kenne ich also weder die Anforderung oder die Technologie sehr gut, ist es sinnvoll, erst einmal kleine Funktionen umzusetzen und diese Erfahrung in die weitere Entwicklung einfließen zu lassen, um das Risiko falscher Entwicklung zu minimieren. Der Kunstgriff ist hierbei, die einzelnen Funktionen klein genug zu schneiden, dass diese schnell umgesetzt werden können diese aber groß genug zu schneiden, dass es funktional sinnvoll ist. In diesem Zusammenhang taucht dann auch sehr gerne der Begriff „Minimum Viable Product“ (MVP) auf, der nicht aus dem agilen Framework, sondern dem Lean Management stammt. Es bezeichnet ein minimales überlebensfähiges Softwareprodukt. Kling toll, aber was steckt eigentlich hinter dieser Idee? Ich entwickle ein Softwareprodukt mit einem funktionierenden Funktionsumfang, welcher meinem Kunden eine gute und stabile Funktionalität bietet, die ich dann sukzessive erweitern kann. Es heißt nicht, dass ich möglichst viel Funktionalität mit schlechter Qualität ausliefere. In diesem Fall erstelle ich „Bananensoftware“ (die beim Kunden reift) und verärgere meine Kunden.

Fachbereich und IT, zwei Welten prallen im Agilen aufeinander

Als Bank bedeutet das für mich, dass ich meinen Mitarbeitern diese Denkweise vertraut machen muss und dass ich ihnen den Raum lasse, hier in der Praxis Erfahrung zu sammeln. In der Konsequenz bedeutet dies auch, dass eine Trennung von IT und Business Line nicht sinnvoll ist, denn sowohl das zerteilen der Funktionen als auch die Rückmeldung hierzu bedarf zwingend beider Fraktionen. Der „große Graben“ zwischen IT und Business Lines muss also zugeschüttet werden.

Der große Graben ist auch ein Widerspruch zu einer weiteren Grundidee, das Scrum keinen Unterschied zwischen IT und Business Line macht. In einem Entwicklungsteam sind alle Skills vorhanden, die zur Erstellung des Softwareproduktes erforderlich sind. Das betrifft insbesondere IT und Business Line Mitarbeiter.

Agilität: Gräben zuschütten und miteinander und nicht gegeneinander arbeiten

Ich habe diesbezüglich in einem Projekt die Erfahrung gemacht, dass die daraus resultierenden Verhaltensmuster aufgebrochen werden müssen. Was war passiert? Wir starteten ein agiles Projekt in dem sowohl Mitarbeiter der IT als auch der Business Line waren. Das Ergebnis war, dass am Anfang die umgesetzte Lösung schlichtweg Schrott war und in gelernte Verhaltensmuster zurückgefallen wurde: „Die Implementierung ist schlecht“. „Du hast die User Story nicht gut beschrieben“ und so weiter. Es ging also das übliche Fingerpointing los, jeder hatte Schuld, nur nicht man selber. In der Tat dauerte es mehrere Wochen, bis das Team begriff, dass sie gesamthaft für das Ergebnis verantwortlich sind. Ab da arbeitete man miteinander und es wurde sehr effektiv.

„Der Soldat hat selbsttätig mit Schwimmbewegungen anzufangen.“ Warum selbstorganisierende Teams in Banken Mangelware sind

OK, zwei wesentliche Grundideen haben wir schon, nämlich große Probleme in kleine zu zerlegen und sich deren Umsetzung zeitnah anzusehen, um für die weitere Umsetzung zu lernen sowie gemeinsames Handeln und Denken, um ein gutes Softwareprodukt zu erstellen. Eine weitere neue Grundidee ist die der selbstorganisierenden Teams. Leider beobachte ich immer wieder, dass man Mitarbeitern selbstständiges Handeln über Jahre hinweg abgewöhnt hat. Das Symptom äußert sich meist darin, dass Mitarbeiter selbst kleine Entscheidungen, z.B. ob man etwas linksrum oder rechtsrum entwickeln soll, nicht treffen und diese an das Management in Form von Projektmanagern oder Linienvorgesetzten delegieren. Meist ist dies in sehr hierarchischen Bankinstituten unabhängig von deren Größe zu beobachten. In solch einer Firmenkultur ist agiles Arbeiten schlichtweg nicht möglich, da Scrum keine Hierarchien kennt. In Scrum werden Entscheidungen über die Entwicklung vom Entwicklungsteam getroffen, das Entwicklungsteam ist als Ganzes für das Ergebnis verantwortlich.

Shit happens, aber Agilität hilft, diese schnell zu beseitigen

Dass dabei Fehler passieren, kommt vor, im Gegensatz zu den klassischen Vorgehensmodellen werden diese aber zeitnah im Review identifiziert und können entsprechend zeitnah korrigiert werden. Kein Grund also, ihnen den Kopf abzureißen. In die Hierarchiekerbe schlägt auch, dass der Product Owner die volle Entscheidungsfreiheit darüber hat, was in welcher Reihenfolge umgesetzt wird. Diese Denkweise erfordert, neben einer organisatorischen Änderung, eine bestimmte Firmenkultur, welche ich über einen Change Prozess im Unternehmen einführen und der von allen Führungskräften gelebt werden muss.

Mein Fazit zu Scrum als Framework: Dass sich Scrum als Framework bezeichnet hat seinen Grund, es geht mehr darum, die Grundidee dahinter zu verstehen, als neue Werkzeuge (a fool with his tool) einzuführen. Dies bedeutet aber auch, dass man hierfür einen organisatorischen und auch kulturellen Wandel im Unternehmen durchführen muss. Wird dies unterlassen, ist Agilität zum Scheitern verurteilt.

 

Beste Grüße
Andreas Milanese

PS: Wer nicht abwarten kann oder an einer Beratung interessiert ist, darf auch gerne meine Website besuchen unter: http://www.ppi.de/banken/compliance/agiles-projektmanagement/

 

Agile Transformation in Banken- oder die wahre Geschichte der agilen Frustration?! Und was ist Bananensoftware? #agile

Schnelles Time-to-Market, Flexibilität bei Anforderungen und selbstentscheidende Teams sind hier schlagende Argumente. Es gibt kaum eine Bank, die agile Methoden heutzutage nicht einsetzt.
Es basiert auf den agilen Grundprinzipien:
•    Inspektion
•    Adaption
•    Transparenz

Klingt doch alles sehr verlockend, oder etwa nicht?!

Warum begegne ich in den Banken dennoch so vielen frustrierten Menschen? Da gibt es Mitarbeiter, die am liebsten „die alten Zeiten“ wieder her wünschen, ein Management, das kaum mehr ansprechbar ist, da es zwischen verschiedenen Teams die Fäden zusammenzuhalten versucht und Kunden , die sich über wachsende Probleme mit der Software beschweren und diese als Bananensoftware (Software, die beim Kunden reift) bezeichnen.

Agile Frustration
Ich habe mich gefragt, was diese agile Frustration bei den Menschen auslöst. Liegt es an dem Framework selber, wird es falsch eingeführt oder stehen die strengen regulatorischen Anforderungen an Banken hier im Widerspruch? Wie so häufig ist nicht immer nur ein Faktor ausschlaggebend, sondern mehrere.

Agile Software(bananen)entwicklung…
Leider ein häufiger Grund, warum eine agile Softwareentwicklung für die Bank nicht sinnvoll eingesetzt wird. In dem folgenden Fall hatte sich die Bank löblicherweise eine agile Softwareentwicklung auf die Fahne geschrieben. Es wurden die Scrum-Rollen Mitarbeitern zugewiesen und die Scrum-Events und Artefakte eingeführt. Allerdings arbeitete man bei genauer Betrachtung in einem „agilen Wasserfall“, d. h. mehrere Sprints Konzeption, dann Umsetzung, dann Test, dann Release.

und agile Frameworks oder sowas in der Art…
Meine erste Vermutung war, dass man das agile Framework nicht verstanden hatte, aber die Ursachen waren andere. In erster Linie hat das Institut den Grundgedanken einer agilen Softwareentwicklung nicht verstanden bzw. umgesetzt. Nehmen wir mal das Beispiel Vertrieb. Dieser machte in der Diskussion von Zwischenergebnissen mit dem Product Owner klar, dass seinen Kunden maximal einmal pro Jahr funktionale Änderungen zuzumuten wären und er das volle Funktionspaket benötigte.
 

und zu späte Reviews
Dementsprechend tauchte er dann auch erst zum letzten Review-Termin vor dem Release auf, um seine Anmerkungen zu geben. Die Konsequenz war, dass ca. ein halbes Jahr an Softwareentwicklung zurückgebaut werden musste, weil erst zu einem viel zu späten Zeitpunkt festgestellt wurde, dass die vehement eingeforderte und hoch priorisierte Funktionalität nicht sinnvoll und viel zu komplex für den Kunden ist.
 

Verpasste Inspektionen und zu spät erstellte Anforderungen
Hier wird ein wesentlicher Punkt der agilen Softwareentwicklung vernachlässigt, nämlich der Punkt Inspektion. Rückmeldung kommt immer erst kurz vor dem Release, was dazu führt, dass neue Anforderungen erst nach dem release-bedingten Code Freeze gestellt und dann hektisch nachentwickelt wurden. Hier hat das agile Framework nur die Legitimation geliefert, Anforderungen sehr spät zu stellen, um beim gewohnten Verhalten bleiben zu können. In diesem Fall führte das zu wachsender Frustration bei den Entwicklern, da sie nun keine Argumente mehr hatten, späte Anforderungen abzuweisen. Aber auch die Kundenseite sah keinen Mehrwert - es wurde ja gearbeitet wie immer.

Kardinalsfehler und nicht angepasste IT-Prozesse
Erschwerend wurden auch die IT-Prozesse nicht angepasst, die immer von festen Releasezyklen ausgehen und eine agile Entwicklung nicht unterstützen, da man z. B. feste Quality Gates für Fachkonzepte und andere klassische Ergebnistypen einfordert. In der Konsequenz musste man im „agilen Wasserfall“ entwickeln. Der Kardinalsfehler bei der Einführung von Scrum war, dass das Unternehmen im Ganzen nicht auf die agile Reise mitgenommen wurde.

Ist das nun „Agile Transformation“ oder nur `ne PR-Nummer?
Agile Entwicklung war nur Teil der IT-Entwicklung. Es wurden weder Stakeholdern – wie dem Vertrieb – das neue Mindset und die geänderte Arbeitsweise vermittelt, noch wurden die bestehenden IT-Prozesse einer agilen Entwicklung angepasst. Agile Entwicklung diente ausschließlich der Legitimation später Anforderungen aufgrund später Feedbacks und als Marketingaussage, dass man moderne Softwareentwicklung könne. 


Mein Fazit: „agilifizieren“
In diesem Fall wäre es besser gewesen, inkrementell Iterativ zu arbeiten und vielleicht erst in der Folge pilothaft auf agile Softwareentwicklung umzustellen. Nicht immer wird der Einsatz des agilen Frameworks ein Unternehmen weiter bringen. Wichtig ist es, zu verstehen, ob ich damit meinen Kunden einen Mehrwert bieten kann, oder ob diese, da z. B. sehr konservativ geprägt, sogar verschreckt werden. Sehr wichtig ist es auch, die IT-Prozesse zu „agilifizieren“. Ist man überzeugt, den agilen Weg gehen zu wollen, muss das komplette Institut auf diese Reise mitgenommen werden. Aber dazu mehr in meinem nächsten Blogbeitrag.


Beste Grüße
Andreas Milanese

PS: Wer nicht abwarten kann oder an einer Beratung interessiert ist, darf auch gerne meine Website besuchen unter: http://www.ppi.de/banken/compliance/agiles-projektmanagement/

MiFID II Quick Fix: die Erfüllung eines Traums oder nur eine neue technische Herausforderung? – Teil II

Und hier kommt die Fortsetzung meines ersten Blogs. Ich hatte schon über meine persönlichen Erfahrungen in den Anfängen der (Compliance-)Digitalisierung berichtet, einen Blick in die Historie geworfen und wesentliche Herausforderungen aufgezeigt.
 

 

Was ist nun nach der MiFID II-Einführung im Thema Digitalisierung bei Banken passiert?


MiFID II – Banken werden digitaler

Ein klassisches Projektthema mit hitzigen Diskussionspunkten war (und auch hier: ist es heute noch) die Kostentransparenz. In den Projektanfängen wurde teilweise noch gerätselt, ob dies wirklich für Käufe und Verkäufe, tatsächlich für alle Kundenklassen und alle Wertpapierdienstleistungen gelten soll und immer vor Auftragserteilung auf einem dauerhaften Datenträger zur Verfügung gestellt werden muss. Und wie soll das praktisch gehandhabt werden, wenn viele Gespräche telefonisch erfolgen (ich spare mir an dieser Stelle Ausführungen zum Vorlesen – eine Option, die zunächst geduldet wurde und schließlich durch die ESMA im Rahmen eines Q&A[1] aufgenommen wurde). Aber auch diese Herausforderungen wurden gemeistert und entsprechende technische Prozesse geschaffen, die den Anlageberater idealerweise end-to-end durch die Anforderungen – inhaltlich und ablauftechnisch – führen. Die Kritik jedoch, auch von Endkundenseite, blieb: Die Dauer der Gespräche erhöhte sich. Und nicht nur das, sondern auch die zeitliche Verzögerung der Platzierung von Orders am Markt wurde jetzt erst wirklich sichtbar.

Der Quick Fix aus dem Blickwinkel der Automatisierung

Nun hat die EU-Kommission Ende Juli Änderungsvorschläge publiziert, die losgelöst vom grundsätzlich anstehenden MiFID-Review ad hoc implementiert werden und Erleichterung schaffen sollen: Jetzt erfolgt u. a. eine Unterscheidung zwischen der Informationspflicht für Privatkunden und der für professionelle Kunden (siehe Ex-ante-Kostentransparenz und Ex-post-Reporting). Zur Beschleunigung von Prozessen und Vermeidung weglaufender Wertpapierkursnotierungen ist geplant, unter bestimmten Voraussetzungen in der Fernkommunikation Informationspflichten auch im Nachgang erfüllen zu können.

Klingt irgendwie fast nach der Erfüllung eines großen Wunsches. Aber ist das tatsächlich so? Klar ist, für den professionellen Kunden bieten die neuen Regelungen die notwendige Transparenz und den Marktzugang, den er typischerweise erwartet. Auch aus Vertriebssicht sind die neuen Prozesse sehr zu begrüßen, da die bisherigen Einschränkungen und Fehlerquellen deutlich reduziert werden. Aber sind die Quick Fixes auch so fix in der IT zu ändern? Bei vielen Instituten steht nun entweder ein Rückbau (bspw. Kostentransparenz) oder ein Neubau (bspw. elektronische Kommunikation als neuer Standard anstelle von Papier) an.

Wie so oft steckt der Teufel im Detail: Was auf den ersten Blick so schön einfach klingt, wird tricky, wenn ganze Prozesse nun deutlich mehr Weggabelungen benötigen, weil erst jetzt wirklich zwischen Kundenkategorie und Kommunikationsmitteln unterschieden wird. Ganz zu schweigen davon, wenn End-to-End-Prozesse inklusive der dahinterliegenden Kontrollhandlungen durchgängig anzupassen sind. So trivial die Opt-in-Möglichkeiten in den neuen Richtlinien klingen (bspw. muss ein professioneller Kunde teilweise kein Ex-post-Reporting mehr erhalten, auf Wunsch muss es jedoch möglich sein), ist das aus IT-Sicht weitaus weniger trivial. Modulare Systeme mit Parametrierungsmöglichkeiten, Customizing und Regelwerken sind dabei auf jeden Fall im Vorteil gegenüber monolithischen Systemen.

Mein persönliches Fazit: Die – längst fälligen – Anpassungen an dem komplexen und nicht immer der Praxis entsprechenden aktuellen MiFID-II-Regelwerk sind zu begrüßen. Noch schöner wäre gewesen, sie initial zu berücksichtigen. Sie bedeuten jedoch auch einen erneuten, nicht zu unterschätzenden (technischen) Implementierungsaufwand in den Instituten. Die Quick Fixes sind also nicht zwingend auch ein Quick Win für die Institute. Fangt am besten frühzeitig mit der Planung an!

Und für 2021 ist ja dann auch schon der eigentliche MiFID-II-Review geplant. Ich bin gespannt, welche „Erleichterungen“ mit erneutem Anpassungsbedarf in Prozessen und Systemen diese dann bringen …


Ich hoffe, mein erster Blog hat Euch gefallen und ich freue mich über Feedback. Ihr möchtet  das auf keinen Fall verpassen? Dann  am besten unseren Blog direkt abonnieren!


Herzliche Grüße
Sandra Reinhard



PS: Weitere Informationen zum Thema MiFID-II finden Sie auch hier: https://www.ppi.de/banken/compliance/mifid/


[1] Siehe Questions and Answers on MiFID II and MiFIR investor protection and intermediaries topics |
ESMA35-43-349, Stand: 28.05.2020.

Sind Software Roboter gekommen um zu bleiben? #RPA

Da ich das Thema Robotic Process Automation (RPA) nun schon seit einigen Jahren hautnah bei Kunden in Finance und Risk erlebe und mit großem Interesse verfolge, möchte ich hier einmal von meinen Erfahrungen und Einschätzungen berichten.

RPA ist sicherlich in den letzten Jahren zu einem großen Hypethema in vielen Branchen und vor allem im Banking-Bereich geworden – nicht zuletzt da die Assoziation von Robotern häufig dazu führt, dass Entscheider denken, nach einer Umstellung via RPA laufen alle Prozesse automatisch ab und es können massenhaft Mitarbeiter eingespart werden.

Ausgangspunkt für eine Prozessumstellung via RPA ist meist eine regelmäßig wiederkehrende Aufgabe, bei der viel Zeit für Datenbeschaffung und Datenaufbereitung aufgewendet werden muss und die eigentliche komplizierte Analysearbeit z. B. nur im Falle von auftretenden Abweichungen durchgeführt wird.

Diese Tätigkeit lässt sich gut durch Softwareroboter abbilden, die sich eigenständig in Systemen anmelden, periodische Datendownloads und -uploads durchführen, Daten zwischen Bestandssystemen, dem DWH und Excel-Anwendungen hin- und herkopieren und vieles mehr. Sofern ein menschlicher Benutzer in den Prozess eingreifen muss, kann dieser darüber bspw. per Mail unterrichtet werden.

Offensichtliche Vorteile von RPA liegen auf der Hand, z. B. die Einsparung wertvoller Ressourcen von Experten, die ihre Aufmerksamkeit auf die Lösung fachlicher Sachverhalte konzentrieren können, Vermeidung von Fehlern durch menschliche Eingriffe in Prozessen, Ablösung von ermüdenden und stupiden Aufgaben.

Die Ansätze zur Umstellung der Prozesse unterscheiden sich sehr stark in der Praxis. Es gibt einerseits die Umsetzung, die sich 1:1 am bestehenden Prozess orientiert und eigentlich nur die Bewegungen und Klicks des Mauszeigers nachprogrammiert, um den fachlichen Prozess durch den Softwareroboter durchführen zu lassen. Dabei werden weder die zugrundeliegenden Verarbeitungsprozesse angepasst noch irgendeine fachliche Logik analysiert, sondern nur umgesetzt, was der Benutzer sonst auch tun würde. Ich würde sagen, das ist die aller einfachste Art der Umsetzung mittels RPA.

Werden bei der Analyse des Business-Prozesses auch Potenziale zur Vereinfachung des bestehenden Prozesses evaluiert, evtl. sogar zur Zusammenlegung mehrerer gleichartiger Prozesse, handelt es sich nicht mehr nur um reine RPA-Programmierung sondern um eine vorausgehende Business-Analyse mit gleichzeitigem Redesign der Prozesse. Dadurch wird die Aufgabe der Umstellung komplexer und aufwändiger, aber auch der lieferbare Mehrwert der Umstellung steigt damit deutlich.

Ich frage mich dann, ob es bei der Umstellung bzw. dem Redesign nicht manchmal sinnvoller wäre, einen Prozess komplett auf die Datenbank zu heben und ein professionelles Reporting zu implementieren. Hierdurch lassen sich ganz andere Effizienzen realisieren, als mit einer Umsetzung auf Basis von RPA. Der Aufwand für die Analyse und Konzeption wächst dadurch natürlich nochmal – nicht zu vergessen, dass bei einer Umsetzung auf einmal ganz andere Bereiche involviert werden müssen. Es ist also doch immer eine Abwägung zwischen Kosten und Nutzen notwendig.

Die RPA-Technologie wird nun erst seit einigen Jahren intensiv in der Bankenbranche angewendet. Die Langzeitfolgen von RPA auf die Prozesslandkarte sind bisher noch gar nicht abschätzbar. Die ersten RPA-Prozesse sind in der Regel schnell umgesetzt. In den ersten Jahren von RPA liefen die Anwendungen sogar noch auf dem Desktop des Abteilungsleiters, um die Technik zu verproben. Hier wurde bereits viel professionalisiert in den letzten Jahren, mit eigenen Accounts für Roboter und eigenen Rollen- und Berechtigungsprofilen. Mittlerweile laufen RPA-Prozesse auf eigenen Servern oder in eigenen Umgebungen, wie es für einen sicheren Betrieb notwendig ist.

Doch beim Betrieb einer großen Anzahl von RPA-Lösungen im Unternehmen gibt es immer noch Verbesserungspotenziale:

Wie wird beispielsweise das Abhängigkeitsmanagement gelöst, d. h. welche Roboter müssen angefasst werden, sollte sich eine bestimmte Software im Unternehmen ändern?
Wer behält die Übersicht über den Status der einzelnen Roboter.
 Was ist die Umgehungslösung, wenn Roboter einmal plötzlich ausfallen? Im Prinzip sollte man sich über Kontroll-Dashboards und vielleicht sogar RPA-Lösungen Gedanken machen, welche die Roboter kontrollieren und überwachen.

Für mich persönlich ist die lustigste Vorstellung für die Zukunft bzgl. RPA, dass durch den RPA-Hype ein ganz neues Berufsbild entstehen wird: das Berufsbild des RPA-Re-Engineers. Wenn irgendwann mal eine Vielzahl von fachlichen Prozessen auf Roboter umgestellt sind und das entsprechende Know-how dann gegebenenfalls auch irgendwann aus dem Unternehmen abwandert, gibt es evtl. niemanden mehr, der eigentlich weiß, was dieser Roboter genau fachlich tut. Dann muss der RPA-Re-Engineer aktiv werden und den Roboter Schritt für Schritt debuggen, um herauszufinden, was er genau tut und wie er es tut.

Das Thema RPA bleibt also spannend zu beobachten. Es ist definitiv innovativ, aber ist es auch eine Technologie, die uns länger begleiten wird oder ist es nur eine vorübergehende Erscheinung?


Beste Grüße
Michael Herbst

PS: Weitere Informationen zum Thema Risikomanagement finden Sie auch hier: ppi.de/banken/banksteuerung-und-risikomanagement/risikomanagement/

Alle 11 Minuten verliebt sich ein Kunde in Ihr Unternehmen – dank #KI im Kundenmanagement

Während meines Auslandaufenthaltes in Amerika wurde mir ohne Vorankündigung meine Kreditkarte gesperrt. Ich wusste, dass ich dort ohne Kreditkarte aufgeschmissen bin, war panisch und ratlos. Also schnell den Kundenservice kontaktiert, damit mir – so die Hoffnung – möglichst schnell geholfen wird. Nach kurzem Klingeln werden mir die automatischen Standardfragen – wie z. B.:
  • „Dürfen wir dieses Gespräch aufzeichnen?“ – gestellt, bevor ich zum richtigen Kundenberater weitergeleitet werde. 
  • Kurzerhand flötet eine freundliche Damenstimme ins Telefon „Guten Tag Frau Vu, mein Name ist Anja. Was kann ich heute für Sie tun?“
>> Ich erkenne ihren Namen und ihre Stimme vom letzten Kontakt zum Servicecenter. Noch bevor ich mein Problem schildern möchte, fragt sie mich, ob es um die Sperrung meiner Kreditkarte geht. Ich bestätige dies und sie erklärt mir, warum meine Kreditkarte gesperrt wurde. Die Begründung ist plausibel und so bitte ich sie, meine Karte wieder zu entsperren, da ich mich momentan im Auslandssemester befinde und daher viele Transaktionen aus dem Ausland von meiner Kreditkarte getätigt werden. Sie versteht den Sachverhalt, entsperrt meine Kreditkarte und fragt mich, ob ich noch einen weiteren Wunsch habe. Ich bin super erleichtert und habe keine weiteren Fragen. Mein Anliegen wurde sehr zügig und kompetent bearbeitet, ich fühlte mich als Kunde sehr gut verstanden und bewerte das Gespräch mit 5/5 Sternen.


Kennen Sie das? Nein? Ich auch nicht!

Meine Erfahrungen mit unterschiedlichen digitalen Kundenservices waren meist eher negativ geprägt. Endlose Warteschleifen, mehrere Weiterleitungen zum nächsten Kundenberater – und ich, wie ich genervt und verzweifelt zum dritten Mal meine Kundendaten vorlese und mein Problem schildere. Positive Customer Experience? Eher weniger.

Dass die Bankenlandschaft nach wie vor mit vielen Herausforderungen zu kämpfen hat, ist nichts Neues mehr. Das anhaltende Niedrigzinsniveau, hoher Wettbewerbsdruck durch neue Konkurrenten, wie z.B. FinTechs oder Big Techs und das sich verändernde Kundenverhalten, sind nur wenige der vielen Gründe hierfür. Die Kunden wollen heutzutage jederzeit und überall Bankservices in Anspruch nehmen können. Flexibel und unabhängig von Zeit und Ort müssen die Angebote der Banken sein, und natürlich passgenau auf jeden Kunden zugeschnitten.

Doch funktioniert das? Kann die Kundenkommunikation immer mehr auf digitale Kanäle verlagert werden, ohne dass der Kundenkontakt zunehmend unpersönlicher wird? Muss Digitalisierung = unpersönlich sein? Können die Vorzüge der Digitalisierung und die hohen Datenmengen, die im Kundenservice und auf anderen Kanälen gesammelt werden, nicht effizienter eingesetzt werden, um das Kundenerlebnis zu optimieren?

Wie soll ein solches Szenario funktionieren?
Ich wähle die Nummer vom Kundenservice. Aufgrund meiner hinterlegten Rufnummer in meinen Kundenstammdaten erkennt mich das System. Noch während ich mich durch die Standardbegrüßung und -fragen drücke, erscheint dem Servicemitarbeiter auf der anderen Seite mein Kundenprofil. Anhand der Datenanalyse meiner vergangenen Anrufe (Stimme, Keywords, Bewertung, …) konnte außerdem festgestellt werden, welche Servicemitarbeiter mich zuletzt am meisten zufrieden stellen konnten, als ich ein Problem oder Anliegen hatte. Es erfolgt eine bevorzugte Weiterleitung zu genau diesen Mitarbeitern – sofern diese verfügbar sind. Für mich als Kundin ist das durchaus positiv, da ich nicht mit immer wieder wechselnden Mitarbeitern sprechen muss. Obwohl die Kommunikation digital stattfindet, fällt es mir leichter, Vertrauen zu einem Mitarbeiter aufzubauen. Mithilfe meiner Kundenstammdaten und der Anreicherung von historischen Daten aus vergangenen Kundengesprächen konnte ein Kurzprofil von mir generiert werden, welches beispielsweise alle relevanten Informationen sowie meine letzten Transaktionen anzeigt. Der Servicemitarbeiter sieht also in meinem Kurzprofil, dass mir meine Kreditkarte gesperrt wurde. Auch der Grund wird angezeigt: „Es wurden innerhalb eines kurzen Zeitraumes auffällig viele Auslandstransaktionen getätigt. Aus Sicherheitsmaßnahmen wurde die Kreditkarte der Kundin vorläufig gesperrt.“ Ich muss also nicht lange mein Problem schildern, weil der Servicemitarbeiter schon vorher alle Informationen sieht bzw. nur noch Detailinformationen von mir benötigt. Für mich als Kundin eine durchaus positive Customer Experience.

Das obige Beispiel zeigt, dass meine Vorstellung kein Wunschdenken sein muss. Der Anruf im Kundenservice muss nicht immer frustrierend und nervenaufreibend sein. Mit dem richtigen Einsatz von künstlicher Intelligenz (KI) im Kundenmanagement kann der Datenschatz, den Banken heute bereits besitzen, einen erheblichen Wettbewerbsvorteil versprechen. Dieser Vorsprung kann nicht nur für die Optimierung bestehender Geschäftsmodelle, sondern auch zur Erschließung neuer Ertragspotenziale genutzt werden. KI kann Banken helfen, ihre Kunden besser zu verstehen und Daten als wertvolles Asset für sich zu nutzen. Es zeigt sich, dass die Analyse und Anreicherung der vorliegenden Kundendaten dazu beitragen kann, das Kundenerlebnis und die Kundenzufriedenheit wesentlich zu beeinflussen. Richtig eingesetzt, können KI-Analysen dazu beitragen, dass das Kundenerlebnis wieder persönlicher wird und der Kunde sich verstanden fühlt, obwohl er nicht seinem Kundenberater des Vertrauens in der Bankfiliale gegenübersitzt.

Bei dem Einsatz von KI im Kundenmanagement gibt es noch viele weitere Anwendungsfälle und Luft nach oben, da die Zuverlässigkeit der Analysen mit wiederholter Durchführung und der wachsenden Ansammlung von Daten stetig verbessert wird. Zwar kann KI nicht alle Probleme der Banken lösen, doch kann sie – vielfach eingesetzt – einen großen Mehrwert bringen. Dabei sollte beim Einsatz von KI nicht nur die Kostenreduktion im Vordergrund stehen, sondern vor allem die Verbesserung von Angeboten und Services aus Sicht des Kunden, um sich von anderen Anbietern abzuheben.

Weitere Anwendungsfälle und Informationen finden Sie auch in unserem Whitepaper „Künstliche Intelligenz im Vertriebs- und Kundenmanagement“.






Viele Grüße
Lilli Jo Horn & Thi Hong Dung Vu

PS: Weitere Informationen zum Thema Risikomanagement finden Sie auch hier: https://www.ppi.de/banken/kuenstliche-intelligenz/

MiFID II Quick Fix: die Erfüllung eines Traums oder nur eine neue technische Herausforderung? – Teil I

Praxisorientierte Anpassungen im MiFID-Regelwerk

„Endlich“ möchte ich fast sagen, hat die EU-Kommission Ende Juli Vorschläge zur Anpassung einiger MiFID-II-Regeln veröffentlicht. Diese sollen nun im Eilverfahren (konkret heißt das voraussichtlich Q4/2021 nach Abschluss des Trilogs und nationaler Umsetzung) geändert werden und zielen vor allem darauf ab, den Umgang mit professionellen Anlegern zu erleichtern und die negativen Effekte aus der Pandemie abzufedern. Eigentlich war es ja auch der ursprüngliche Gedanke der MiFID, unterschiedlichen Erfahrungswerten von Kunden differenziert Rechnung zu tragen. So heißt es in den Erwägungsgründen der MiFID-II-Richtlinie: „Ein Ziel dieser Richtlinie ist der Anlegerschutz. Die Vorkehrungen zum Schutz der Anleger sollten den Eigenheiten jeder Anlegerkategorie … angepasst sein“ [1]. Nun stelle ich mir die Frage, mit welchen Herausforderungen Banken konfrontiert sind, wenn sie die Anpassungen jetzt „fix“ implementieren.


MiFID aus der Digitalisierungsbrille – ein Blick in die Historie

Auch wenn aus Vertriebssicht die Freude im Hinblick auf die Prozesserleichterungen und die Beschleunigung bei Wertpapierorders überwiegt, sieht das aus IT-Perspektive möglicherweise ganz anders aus. Neben den Erfahrungen aus MiFID-I-Projekten erinnere ich mich noch gut an die Einführung des Beratungsprotokolls in Deutschland Anfang 2010. Hier steckten die Themen IT und Digitalisierung (eigentlich kaum zu glauben) noch in den Kinderschuhen, und wir haben zeitintensive Diskussionen über die Anzahl von Durchschlägen – ja, ich rede vom klassischen Durchschlagpapier – eines solchen Protokolls geführt.

Mit immer größerer Komplexität war es für Banken unvermeidlich, mit entsprechenden Initiativen die deutlich zunehmenden regulatorischen Anforderungen in digitale Anlageberatungs- und Orderausführungsprozesse zu überführen. Auch (menschliche) Fehlerquellen, die bei größerer Komplexität naturgemäß entstehen, wurden dadurch minimiert. Und natürlich galt es, Prozesse zu verschlanken und eine State-of-the-Art-IT zur Verfügung zu stellen.



MiFID II – Herausforderungen, Chancen und Readiness

Spätestens ab 2014 wurde klar, dass MiFID II vor der Tür steht. Zunächst mit Starttermin Anfang 2017 wurde das neue Regelwerk dann auf Januar 2018 verschoben. Bei PPI haben wir die MiFID-II-Entstehung mit einem Readiness-Index begleitet: Von 2014 bis 2018 haben wir regelmäßig in insgesamt sieben Wellen den Fertigstellungsgrad gemessen, den Grad der Herausforderungen und Chancen beleuchtet und (ohne die Spannung nehmen zu wollen) u. a. die kostenintensiven Systemumstellungen sowie den erheblichen Diskussionsbedarf mit Kunden als Kostentreiber und Pain Points identifiziert. Nachstehend die wesentlichen Erkenntnisse über alle Wellen hinweg – wer noch mehr darüber erfahren möchte, findet hier weitere Informationen.


Die Studienergebnisse haben deutlich gemacht, dass IT-, System- und Prozessanpassungen die wesentlichen Herausforderungen waren (und sind) und der Druck zur Automatisierung zwangsläufig erhöht wurde.

Darüber, inwieweit Banken durch MiFID II tatsächlich digitaler geworden sind, berichte ich im zweiten Teil dieses Blogs (heute genau in zwei Wochen). Und ich gebe meine persönliche Einschätzung, ob der MiFID II Quick-Fix die Erfüllung eines großen Traums ist.

Ihr möchtet  das auf keinen Fall verpassen? Dann  am besten unseren Blog direkt abonnieren!

Ich wünsche viel Lesevergnügen mit unserem PPI Banking Blog, freue mich über Feedback und bis zum nächsten Teil am 22.09.2020!

Beste Grüße
Sandra Reinhard

PS: Weitere Informationen zum Thema MiFID-II finden Sie auch hier: https://www.ppi.de/banken/compliance/mifid/


[1] Richtlinie 2014/56/EU, ErwGr 86.

Neue Banking-Perspektiven gefällig? Hier sind Sie richtig.

Liebe Leserinnen und Leser,

ich freue mich sehr, Ihnen unseren brandneuen PPI-Blog „Banking Experts“ zu präsentieren.

An dieser Stelle teilen wir ab jetzt unser Expertenwissen mit Ihnen, den Fachleuten der Banking-Branche. Unsere Autoren vereinen ihr fachliches Know-how in den zentralen Bereichen des Bankgeschäfts mit praktischen Erfahrungen aus IT- und Kundenprojekten. Der Blog wird von drei Autorenteams im zweiwöchigen Rhythmus für Sie bespielt.

Unser Ziel: Ihre fachliche Perspektiven auf das Bankenumfeld zu erweitern. Gewinnen Sie neue, spannende Erkenntnisse – vom Risikomanagement über Regulatorik und Compliance bis hin zur Künstlichen Intelligenz und zu innovativen Ansätzen. Dynamik der Veränderung und Komplexität nehmen in unserer Branche weiter zu. „Banking Experts“ hilft Ihnen dabei, mit dieser Entwicklung Schritt zu halten.

Diskutieren Sie mit uns und bereichern Sie den Austausch mit Ihren Perspektiven und Fragen!

Wir freuen uns auf Ihr Feedback und zum Blogstart beglücken wir Sie diese Woche gleich mit einem Blog-Beitrag aus jedem Team. Den Start macht das Compliance Team mit "MiFID II Quick Fix: die Erfüllung eines Traums oder nur eine neue technische Herausforderung?".

Viel Spaß beim Lesen und herzliche Grüße,

Peter Hoffner
(Vorstand | PPI AG)