Diese Webseite verwendet Cookies. Durch die Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Datenschutzinformationen

09.03.2018Elmar BorgmeierUnternehmen

Sind wir bereit für Agile Compliance?

Agile Compliance. Ernsthaft.

Agil sollen sie sein, innovativ und schnell am Markt: die Digitalisierungs-Teams, mit denen Banken heute den FinTechs Paroli bieten wollen. Doch wenn die Teams dann loslegen und voller Energie und Tatendrang mit der SCRUM-Methode „Minimum Viable Products“ erstellen, die sie mit DevOps in Betrieb nehmen wollen – spätestens dann trifft die Keule der Compliance die Innovationsteams mit voller Härte.

Security, Datenschutz, MaRisk, Bankgeheimnis, wesentliche Auslagerung, prozesskonformes Konzept und nachgewiesene Funktionsprüfung, BaFin-Meldung neuer Produkte, … die Liste der Aufgaben und Prüfungen scheint endlos. Man kann förmlich sehen, wie jeder Esprit die Innovatoren verlässt und sich eine lähmende Starre im Team ausbreitet.

Muss das so sein? Ja und nein. Sauberes Arbeiten und Einhalten der Spielregeln müssen sein – Verbraucher haben Anspruch darauf, dass ihre Rechte auch von Schnellbooten in FinTech-Manier gewahrt werden. Die Art und Weise hingegen, wie Compliance in den Unternehmen umgesetzt wird, ist keineswegs alternativlos. Hier besteht erheblicher Gestaltungsspielraum. Nutzt man ihn, kann man die Frontenbildung zwischen Agilität und Compliance vermeiden - und damit bei den Innovationsteams erst gar nicht das Gefühl aufkommen lassen, in einem Käfig gefangen zu sein, der keinen Raum zur Entfaltung lässt.

Klassische Vorgehensweisen sowohl bei der Geschäftsentwicklung als auch bei der Softwareentwicklung drehen tendenziell ein großes Rad und gehen am Ende dieses aufwändigen Weges mit Wucht an den Start. Die heutigen Verfahren, mit denen man Compliance einfordert und durchsetzt, haben sich an diese Arbeitsweise angepasst. Sie haben selbst einen ebenso gewichtigen Mechanismus etabliert, der seine Kraft zu einem guten Teil aus seiner Allgemeingültigkeit bezieht nach dem Motto: „An uns kommt keiner vorbei, also versucht es erst gar nicht“. Deshalb sind die Regeln zentral vorgegeben, für alle verbindlich und unausweichlich. Nur so sind sie stark genug, um mit dem großen Rad mitzuhalten, dass die klassischen Vorgehensweisen drehen.

Agile Ansätze werden davon platt überrollt. Klassische Compliance auf agile Geschäftsentwicklung anzuwenden, ist ungefähr so sinnvoll, als würde man den Einsatz kleiner Drohnen exakt so regulieren, wie man den Flugverkehr mit Jumbojets reguliert. „Der Spielzeug-Heli des kleinen Timmy erbittet Starterlaubnis. Tower, bitte kommen!“ Unsinn? Ja sicher. Aber Unsinn, dem sich agile Projekte tagtäglich gegenüber sehen.

Wie kann man es besser machen? Indem Compliance-Verantwortliche und agile Teams aufeinander zugehen und miteinander Formen der Kontrolle vereinbaren, die besser zur agilen Kultur passen. Das klingt nett, nach miteinander kuscheln. Aber seien Sie gewarnt: Das wird alles andere als kuschlig. Im Gegenteil, es bedeutet, dass sich beide Seiten der harten Realität stellen und die daraus resultierenden Notwendigkeiten akzeptieren.

Agile Compliance – Herausforderung für die Compliance

Für diejenigen, die in der Bank über die Einhaltung der Vorgaben wachen, bedeutet Agilität zweierlei: Zum einen müssen sie neben ihrer Rolle als Wächter auch die Rolle des Beraters einnehmen, der den agilen Teams hilft, Minimum Viable Products (MVPs) auch mit „Minimum Viable Compliance Overheads“ zu erreichen. Pilotphasen mit eingeschränkten Nutzergruppen können ein guter Weg sein, um offizielle Prozesse für neue Produkte so lange zu verschieben, bis man weiß, dass sich die Produkteinführung auch wirklich lohnen wird. Bei der Wahl des richtigen Weges für Produktentwicklung und Markteinführung sollte man darauf achten, dass in den frühen Phasen nur geringe Schutzbedarfe bestehen mit überschaubaren Risiken – dann können die Risiken zuerst einmal ganz offiziell getragen werden. So kann man bei neuen Konzepten für die Vermarktung von kreditartigen Produkten anfangs das Volumen strikt begrenzen. Bei technischen Risiken kann man sich anfangs auf die sicherste Plattform beschränken. (In Bezug auf manche Faktoren wird z.B. das iPhone als sicherer eingeschätzt als Android-Smartphones, da Apple den eigenen App-Markt effektiver kontrolliert.) Die Erfahrungswerte aus dem Einsatz des MVP können wiederum helfen, die Risiken des neuen Produktes treffsicherer zu bewerten. So verhindert man, dass unrealistische Befürchtungen zu unwirtschaftlich teuren Sicherheitsmaßnahmen führen.

Zur Beraterrolle gehört auch, zusammen mit den Teams zu überlegen, wie man Produkte so umsetzt, dass sie gerade nicht von bestimmten Regulierungen betroffen sind. Was darf ein „Robo Advisor“ tun, ohne dass die Beraterrichtlinie greift? Darauf brauchen die jungen Wilden dringend Antworten von den alten Hasen der Compliance. 

Zum Zweiten müssen die Compliance-Abteilungen bereit sein, ihre Funktion auch zu delegieren. Agilität und Innovation gedeihen in kleinen, lokalen Einheiten besser als in unternehmensweitem Liniendenken – deshalb müssen wir auch die Einhaltung der Vorgaben in diese kleinen Einheiten hineingeben und dort ins Team integriert umsetzen.

Wenn man das sagt, erntet man stets erschreckte Blicke. Wie, die Teams sollen sich selbst kontrollieren? Da könne man ja gleich den Bock zum Gärtner machen! Keine Angst, so schlimm kommt es nicht. Eigentlich geht es nur darum, das auf andere Formen der Compliance zu übertragen, was wir bei der Funktionsprüfung bereits gelernt haben:

Klassischerweise entwickeln Programmierer die Software und der Fachbereich testet. Das klingt gut, weil zwei getrennte Einheiten mit separaten Zuständigkeiten sich gegenseitig prüfen. In der Praxis hat der Fachbereich aber keinen Einblick in die internen Details der Software und auch nicht immer Zeit, die nötigen Regressionstests durchzuführen (d.h. bei Neuerungen auch alle alten Funktionen auf unveränderte Korrektheit zu prüfen.) Deshalb hat es sich bewährt, techniknahe Tests (Unit-Tests) und Regressionstests zu automatisieren – d.h. zu programmieren und damit faktisch in die Hände der Entwickler zu geben.

Die Kontrollfunktion verschiebt sich dabei von der direkten Kontrolle – dem Testen – zur indirekten Kontrolle darüber, dass Testfälle von den Entwicklern erstellt werden und die automatischen Tests Fehler auch wirksam finden – es findet also eher prozessorientierte Qualitätssicherung als manuelles Testen statt.

Das lässt sich auf andere Bereiche übertragen: Man kann den Teams mehr Eigenverantwortung und damit mehr Gestaltungsspielraum geben, solange die Verantwortung effektiv angenommen wird und nachprüfbar bleibt, dass die Verantwortungsübernahme im Team auch gelebt wird.

Agile Compliance – Herausforderung für agile Teams

Im ersten Moment jubeln die agilen Teams bestimmt, wenn man ihnen erklärt, dass sie die konzernweiten Vorgaben an ihre spezifische Arbeitsweise adaptieren dürfen. Aber das ist ähnlich wie der Jubel darüber, dass beim agilen Arbeiten kein Projektmanager dem Team mehr unrealistische Vorgaben macht – der Jubel vergeht recht schnell, wenn das Team merkt, dass die Vorgaben nicht entfallen – es ist jetzt nur selbst dafür verantwortlich, sie zu machen und einzuhalten. Commitment ist ein zentraler und anstrengender Wert jeden agilen Arbeitens.

Frei ist das Team vor allem in der Art und Weise, in der es die Compliance in seiner Arbeitskultur verankert. Manches werden die Teckies in Technik gießen – das ist dann in der Regel die härteste Kontrolle überhaupt. Wenn das Build-System die Software schlicht nicht herausrückt, solange bestimmte Vorgaben nicht eingehalten sind, dann kommt man daran nicht vorbei, ohne wirklich aktiv die eigene Programmierung zu fälschen. Vieles wird in den teaminternen Spielregeln vereinbart werden – so können Security-Reviews Teil der „Definition of Done“ sein, also der Vereinbarung, wann die Entwickler eine Funktion als fertig melden. 

Oft können die Teams aber auch von den Erfahrungen der unternehmensweiten Compliance profitieren und Erfolgsmuster im Kleinen nachbilden. Die Trennung von Zuständigkeiten etwa lässt sich durchaus mit Teamarbeit vereinbaren. Code-Reviews sind ohnehin Bestandteil jeder guten agilen Software-Entwicklung. Es ist nur eine kleine Weiterentwicklung dieses Mechanismus, dem Review-Vorgang immer auch einen übergeordneten Review-Aspekt mitzugeben. Dann schaut man eben nicht nur auf die Code-Qualität, sondern zusätzlich darauf, ob durch den Code Datenschutzaspekte betroffen sind. Im Idealfall identifiziert man Problemfälle gleich an der Quelle und löst sie mit minimalem Aufwand (zum Beispiel vermeidbare personenbezogene Daten in Logfiles).

Aktives Risikomanagement kann man direkt in die Refinements integrieren. So, wie Aufwände im „Planning Poker“ durch die Teamintelligenz besser geschätzt werden, so können auch Risiken durch dasselbe „Spiel“ intelligent bewertet werden. Klar getrennte Zuständigkeiten beim Go Live und aktives Monitoring des Systemverhaltens durch die Experten aus der Software-Entwicklung können oft mehr zum Schutz vor Manipulationen und Hacks beitragen als alle Papier-Checks vorab.

Vor allem aber müssen die agilen Teams das Erreichen von Compliance-Zielen wertschätzen lernen. Das Ziel, den Verbraucherschutz sauber umgesetzt zu haben, muss einen ebenso hohen Stellenwert haben wie eine benutzerfreundliche Bedienung und ansprechendes Design. Erst dann ist das Team intrinsisch motiviert, sich der Herausforderung Compliance zu stellen. Gelingt die Verankerung der Compliance-Ziele in der Vision des Teams, dann darf man sich auf innovative Lösungen freuen. Betrug ist ein wesentliches Risiko bei Kreditkarten? Dann zeigen wir dem Kunden doch jede Transaktion sofort auf dem Smartphone an – die Kunden wissen in dem Moment ja, ob sie die Transaktion gerade ausgeführt haben oder nicht. Eine einfache, wirksame und gleichzeitig auch noch benutzerfreundliche Strategie, Kreditkartenbetrug gleich bei der ersten irregulären Abbuchung zu blocken – solche Lösungen können nur aus den Innovationsteams selbst kommen. Kein unternehmensweites Regelwerk, und sei es noch so sorgfältig aufgesetzt und wirksam durchgesetzt, bringt so etwas hervor.

Fazit

Agile Compliance klingt verrückt. Ist sie aber nicht – im Gegenteil wird sie mehr und mehr zur Notwendigkeit. Agile Compliance bedeutet, die Verfahren der unternehmensweiten Kontrollen in die agilen Teams hineinzugeben und dort wirksam zu verankern, dabei die Art und Weise der Umsetzung aber dem Team zu überlassen. Es geht um kontrollierte Dezentralisierung von Kontrolle, um den Übergang vom Prüfen zur ganzheitlichen Qualitätssicherung.

Das ist nicht einfach, weil es Verhaltensänderungen erfordert, von den Kontrolleuren ebenso wie von den agilen Teams. Aber es lohnt sich, weil die riesige Frustration vermieden werden kann, die unweigerlich entsteht, wenn sich Innovationsteams im feinmaschigen Käfig der Compliance gefangen finden.

Und letzten Endes ist Agile Compliance unausweichlich – denn es ist der einzige Weg, die Verheißungen der Agilität wie schneller Markteintritt und flexibles Reagieren auf sich ändernde Märkte Realität werden zu lassen, ohne dabei die Kontrolle zu verlieren.


Begleiten Sie unseren Mitarbeiter Syngenius

Beiträge filtern

 

nach Kategorie

UnternehmenKarriereDigital PaymentDigitaler KundenzugangSoftware Manufaktur

nach Autor

Alexander LazarevićChristian RäderDirk MögenburgJörg SteinElmar BorgmeierMark SpiesslMichael AitaMichael MaleikaNicole KunzeDr. Stefan ReisnerTanja Everartz

nach Themen

Es sind Themen dabei, die Sie besonders interessieren?

Dann ist unser Infodienst was für Sie. Geben Sie einfach Ihre E-Mail-Adresse an und wählen Sie Ihre Themen aus. Wir benachrichtigen Sie, sobald es dazu etwas Neues gibt.

© SYNGENIO AG EXZELLENZ. BEGEISTERUNG. VERANTWORTUNG. INNOVATION.