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/