Zombie-Firmen – Ergebnis langjähriger Niedrigzinspolitik

Wer bei Zombie-Firmen an Gruselschocker á la Hollywood denken, liegt gar nicht so falsch. Es handelt sich dabei um Unternehmen, die aus betriebs- und volkswirtschaftlicher Sicht nicht überlebensfähig sind, aber dennoch weiter existieren – „Untote“ sozusagen.

Lange Zeit existierten Zombie-Firmen nur im japanischen und chinesischen Wirtschaftsraum. Aufgrund der sehr lockeren Kreditvergabe- und einer anhaltenden Niedrigzinspolitik ist diese Art von Unternehmen auch im europäischen- und US-amerikanischen Wirtschaftsraum reale Existenz geworden.

Es gibt unterschiedliche Auffassungen, was eine Zombie-Firma ist. Die variierenden Ansichten zur Identifizierung von Zombie-Firmen, weichen jedoch grundsätzlich nur minimal voneinander ab.
Die OECD (1)  definiert ein Unternehmen als Zombie-Firma, wenn das Unternehmen seit mindestens zehn Jahren am Markt präsent ist und davon drei Jahre in Folge nicht in der Lage war die erforderliche Zinslast aus dem operativen Ergebnis zu leisten. Der Zinsdeckungsgrad (Betriebsergebnis zu Zinsaufwendungen) ist somit seit drei aufeinander folgenden Jahren kleiner als eins.
Die Bank für Internationalen Zahlungsausgleich (BIZ) erweitert diese Definition durch Berücksichtigung der jeweiligen Marktkapitalisierung, welche sich an den Börsen als überproportional niedrig darstellt. 

Eine weitere Definition bezeichnet Unternehmen dann als Zombie-Firma, wenn der Cashflow (2)  in drei aufeinander folgenden Jahren negativ ist.

Warum gibt es Zombiefirmen?

Der wesentlichste Grund warum Zombie-Firmen auch hier zu Lande existieren, resultiert aus der Aussetzung des Tatbestandes der Überschuldung als Insolvenzgrund. Bis zum Jahre 2009 mussten Unternehmen Insolvenz anmelden, wenn das Aktivvermögen nicht mehr ausreichte, um die Verbindlichkeiten zu decken und somit den Tatbestand der Überschuldung erfüllten. Seit diesem Zeitpunkt müssen Unternehmen trotz Überschuldung nur noch einen positiven Cashflow für das aktuelle Geschäftsjahr erwarten.  

Im Jahr 2020 wurde der Zeitraum aufgrund der Corona-Pandemie erneut verlängert und führt in der Konsequenz dazu, dass Firmen die zahlungsunfähig sind weiterhin keine Pflicht haben Insolvenz anzumelden. Sie werden künstlich am Leben gehalten und agieren als Zombie-Firma weiter am Markt.
Ein indirekter Indikator für die Zunahme der Zombie-Firmen ist die stark rückläufige Entwicklung der Unternehmensinsolvenzen in Deutschland (siehe Grafik).
 

Abbildung 1"Anzahl der Insolvenzen seit 2010" (3)

Für das erste Halbjahr 2020 meldeten die deutschen Amtsgerichte 9.006 Insolvenzen von Unternehmen. Laut des statistischen Bundesamtes sind das 6,2% weniger als im Jahr zuvor und das trotz Corona. Experten warnen: Das Insolvenzgeschehen hat sich von der realen wirtschaftlichen Situation der Unternehmen entkoppelt.

Gleichzeitig können sich Unternehmen immer leichter und immer billiger Kredite von Banken besorgen. Das Kreditwachstum erreichte mit ca. 6% Prozent einen Höhepunkt im Jahre 2018 .

Grund dafür sind das niedrige Zinsniveau sowie stark gelockerte Standards für die Vergabe von Krediten. Die Lockerung der Standards bedingen zwangsläufig die Erhöhung der Risiken in den Kreditbüchern der Banken. Ungeachtet dessen und zur Vermeidung von möglichen Abschreibungen und der damit einhergehenden Reduzierung von Gewinn und Eigenkapitalquote werden Zombie-Firmen auch weiterhin problemlos mit Liquidität in Form von Krediten versorgt.

Was macht Zombie-Firmen so gefährlich?

Zombie-Firmen binden die Kreditvergabekapazitäten von Kreditinstituten, die somit weniger bzw. zeitlich verzögert Kredite an gesunde Unternehmen vergeben können. Neben diesen volkswirtschaftlichen Aspekt stellen Zombiefirmen auch eine Gefahr für Banken dar, sobald sich der Leitzins wieder erhöht.

Eine aktuelle Bilanz zieht die WirtschaftsWoche mit Daten der Bank für Internationale Zusammenarbeit. Laut ihren Recherchen betrug der Anteil der Zombiefirmen an 32.000 börsennotierten Unternehmen aus 14 Industrieländern im Jahr 2017 knapp 16%. Die Wahrscheinlichkeit, dass diese Firmen auch weiterhin Zombies sind ist mit knapp 90% sehr hoch. 

Abbildung 2 "Anteil der Zombiefirmen an 32.000 börsennotierten Unternehmen aus 14 Industrieländern"

Sollte es zu einer Leitzinserhöhung durch die EZB kommen, würden diese Firmen endgültig „sterben“ – und eine Welle von Insolvenzen würde einen enormen volkwirtschaftlichen Schaden verursachen. Darüber hinaus wird es zu einer Progression bei den Abschreibungen von Forderungen der Banken kommen mit entsprechender negativer Wirkung auf das Eigenkapital. 

Was ist jetzt präventiv das beste Vorgehen?

Gefahr erkannt – Gefahr gebannt? Im klassischen Zombiefilm plündern die Protagonisten häufig frühzeitig einen Baumarkt, um an die begehrte Axt zu kommen – die Allzweckwaffe gegen Zombies. So einfach ist es in der Banksteuerung leider nicht. Wer erkennt, dass Zombie-Firmen ein Risiko für das Portfolio darstellen, ist schon mal schon einen Schritt weiter als viele andere, aber nun beginnt die eigentliche Arbeit.

Analog zu dem Umgang mit Non-Performing-Loans sollten detaillierte Portfolio-Scans durchgeführt werden. Dazu kann man sich der erwähnten Kennzahlen bedienen, wie Zinsabdeckungsgrad oder Marktkapitalisierung.  Negative Cashflows können verwendet werden, um Warnindikatoren für das Portfolio aufzubauen.

Zombiefirmen sind eine reale Gefahr für das Bankportfolio, eine Gefahr, die durch die globale Pandemie nur vergrößert wird. Dieser Gefahr gilt es durch geeignete Erweiterung des Risikomanagements zu begegnen. Denn die Risiken der Zombiefirmen werden sich materialisieren – wenn nicht in diesem Jahr, dann in dem nächsten.  

Aber das ist meine persönliche Meinung – die Diskussion ist eröffnet!

Bleiben Sie gesund,

Daniel Settgast

Frustrationsfaktor oder Mehrwert – die neuen Spielregeln und das Ende des Bankmonopols?

Gehören Sie auch zu den Menschen, die am 14. September 2019 vor einem gesperrten Online Banking saßen? Zu denjenigen, die sämtliche Briefe und Mails der Bank bezüglich der neuen PSD2-Richtlinie ignoriert haben? Glauben Sie uns: Sie sind nicht allein.

„PSD2? Was soll das jetzt schon wieder?“ - wir möchten nicht wissen, wie vielen Kundenberatern und Servicemitarbeitern seit Einführung der neuen Richtlinie graue Haare gewachsen sind. Bei steigenden Sicherheitsstandards, einem intensivierten Wettbewerb und verwirrten Kunden stehen die Banken jedoch erst am Anfang. 

Haben Sie sich bereits mit der Zweiten Zahlungsdiensterichtlinie (PSD2) beschäftigt? Haben Sie die Briefe Ihrer Bank gelesen und auch verstanden? Oder ist Ihnen erst aufgefallen, dass etwas anders ist, als Ihr Online Banking Sie bei der Anmeldung das erste Mal nach einem zweiten Faktor gefragt hat? Nun ist der 14. September 2019 und das Inkrafttreten dieser neuen Richtline schon ein wenig her und Sie fragen sich bestimmt: „Welchen Mehrwert hat dieser doch sperrige Begriff „Zweite Zahlungsdiensterichtlinie“ jetzt eigentlich für mich?“ 

Wie bereits geschildert, hat die Einführung der PSD2 viele Fragen aufgeworfen und gewiss auch einige Frustration mit sich gebracht.  Es geht in diesem Blog-Beitrag weder um die Rechtsprechung der PSD2, noch können wir Ihnen eine Auswertung darüber geben, was Ihre Bank davon nutzt.
An dieser Stelle möchten wir aber auf die Möglichkeiten und Chancen der Richtlinie eingehen, denn unter Umständen gibt es auch einige Mehrwerte, die Sie noch gar nicht kennen.

Das Bankgeschäft im historischen Wandel

Aber um das Ganze ein wenig einordnen zu können, hier ein kurzer Rückblick. Die Banken in Europa waren bislang in einer doch sehr guten Position, was den Umgang mit ihren Kundendaten betrifft. Die Daten gehörten der Bank und mussten mit niemandem geteilt werden. Dies änderte sich mit Einführung der PSD2. Ziel der Richtlinie ist es, nicht nur den europäischen Zahlungsverkehr für Kunden sicherer und komfortabler zu gestalten, sondern auch für mehr Wettbewerb zu sorgen. Die Innovationsfähigkeit im Bereich Banking zu erhöhen. Möglichkeiten zu schaffen, die Waage zwischen Sicherheit und neuen Technologien zu halten und dies in ein sicheres, innovatives und kundenfreundlicheres Banking im digitalen Zeitalter von FinTechs und Co. zu transportieren. Kurz gesagt, dass klassische Bankengeschäft für neue Ideen und vor allem neue Wettbewerber zu öffnen.  Um dies zu ermöglichen, bedarf es Informationen, Kundendaten und Schnittstellen - auf einer Grundlage, die für alle einen fairen Wettbewerb garantiert. Das klingt zunächst vielleicht nach Spielereien in einem doch so klassischen und jahrtausendealten Geschäft wie dem Bankwesen. Im 4. Jahrhundert v. Chr. war Athen das größte Bankenzentrum der griechischen Welt und nun stehen wir im Jahr 2021 vor der Herausforderung, das Bankgeschäft zeitgemäß und so digital wie nie zuvor zu gestalten. 

Das Banking von morgen… oder doch schon von heute?

Möchten Sie nicht auch dieses Banking, dass Sie vom Hocker haut? Welches nicht nur die langweiligen Überweisungen und Daueraufträge abbilden kann, sodass Sie sich gleich wieder ins 4. Jahrhundert nach Griechenland versetzt fühlen, sondern Banking mit wirklichem Mehrwehrt?
Eine Plattform, in der all Ihre Konten von verschiedenen Banken, einfach und unkompliziert verwalten werden können? Funktionen wie die Analyse Ihres Zahlungsverhaltens und Ihrer Umsätze zur Optimierung der eigenen Finanzen? Vertragsmanager, die einfach durch Ihre Umsätze scrollen und Ihnen aufzeigen, welche Verpflichtungen Sie in welchen Verträgen haben? Kennen wir nicht alle diese Ordner und Papierhaufen voller Informationen über unsere laufenden Verträge, die man sich maximal für die Kündigung oder für die Steuer anschaut? Wie cool wäre es, wenn dieser Vertragsmanager einem dann noch zusätzlich Angebote bzgl. bestehender Verträge anzeigt und wir nicht nur Zeit, sondern auch Geld sparen!

All diese Funktionen gibt es bereits auf dem Markt. Sehen wir das als Anfang, für ein durch Effizienz und Innovationen gestaltetes Banking, welches hoffentlich nicht nur durch die PSD2 beeinflusst wird, sondern auch durch jeden einzelnen Kunden, der diese vielfältigen Möglichkeiten nutzt. Um nochmal zum Anfang zu kommen: Ja, die Eingabe der TAN bei jedem Login oder auch nur alle 90 Tage ist lästig. Auch das Sie jetzt eine TAN eingeben müssen, obwohl Sie nur Ihre Umsätze sehen wollen. Aber sehen Sie das Ganze vielleicht auch ein wenig als Chance für neue Möglichkeiten um FinTechs einen Weg zu ebnen oder Ihrer Bank neue Denkanstöße zu geben. Sehen Sie es als Spielregeln, die notwendig sind, um die Sicherheit im digitalen Zeitalter sicherzustellen und Innovationen in einem fairen Wettbewerb zu ermöglichen.
Und am Ende bleibt uns abzuwarten, welche großartigen Ideen und Produkte im Laufe der Jahre vielleicht mit Hilfe des ersten Anstoßes der PSD2 geschaffen wurden, welche Kritik berechtigt war und welche Herausforderungen noch auf uns zukommen werden.

Gehen Sie auf Erkundungsreise! 

Entdecken Sie bei Ihrem nächsten Login in Ihr Online Banking Funktionen, welche im Rahmen der PSD2 hinzugekommen sind. Suchen Sie zum Beispiel nach der Möglichkeit eine Berechtigung zur Verfügbarkeitsabfrage für einen Dritten in Ihrem Online Banking anzulegen. Was finden Sie bei Ihrer Bank? 

Fragen Sie sich, wie Ihr Online Banking der Zukunft aussehen soll – was fehlt Ihnen zum idealen Online Banking?

Mehrwert oder Frustrationsfaktor – was empfinden Sie beim Verwenden Ihres Online Bankings?

Wir freuen uns über Ihre Kommentare und Anmerkungen – egal ob Ihre Wünsche in Bezug auf ein innovatives Online Banking oder einen Einblick in Ihre Vision eines Online Bankings der Zukunft sind.

Bleiben Sie gesund!  

Lilli Jo Horn und Thi Hong Dung Vu

Scrum – What’s new Pussycat?

Kaum einer hat es gemerkt, aber Scrum ist im vergangenen Jahr glatt 25 Jahre alt geworden. Und um so ein Jubiläum gebührend zu feiern, wurde dem Scrum Guide ein entsprechendes Update verpasst, nachdem die letzte Version aus dem Jahr 2017 stammt. Man merke also: Eine Sprintlänge bei Scrum beträgt 3 Jahre 😉. Nun kann man (fast) überall nachlesen, welche Neuerungen es gibt – wer sie wirklich noch nicht kennt, kann sie sich schnell mal auf der Scrum.org-Webseite anschauen. Ich habe die Änderungen für mich sacken lassen und will zu den Unterschieden mal Stellung beziehen und sie aus meiner Sicht bewerten.


Product und Sprint Goal – I like

 Der neue Fokus auf Product und Sprint Goal ist aus meiner Sicht eine der besten Neuerungen bei Scrum. Hier wird endlich mal der Blick auf das aktive Management eines Softwareproduktes gerichtet. Höre ich die alten Produktmanager-Hasen hier sagen: „Mache ich schon seit 20 Jahren“? Exakt – aber während bislang das Softwareprodukt in der agilen Welt ausschließlich über die Priorisierung der Anforderungen gemanagt wurde, liegt nunmehr der Fokus auf einem strategischen Management der Software, wie man im Beratersprech sagen würde. Endlich wurden hier mal die klassischen Elemente eines Softwarelebenszyklus berücksichtigt, die sich über Jahrzehnte bewährt haben und absolut sinnvoll sind. 

Jedes Softwareprodukt bekommt nun ein strategisches Ziel, welches es erfüllen soll. Das führt zum einen dazu, dass neue Anforderungen in Bezug auf dieses Ziel genauer bewertet werden können. Und zugleich macht es aber auch dem kompletten Scrum-Team transparent, was das lang- bis mittelfristige Ziel der Software sein soll. Etwas, was man in der täglichen Routine der Sprints schnell aus dem Auge verlieren kann. Damit gebe ich zugleich den Entwicklern einen Rahmen vor, wohin die Reise gehen soll und Fortschritte sind klarer zu identifizieren. Entsprechend bekommt nun auch jeder Sprint ein Ziel, welches auf das Product Goal einzahlt. Ich glaube, dass hiermit die Fragestellung „Was mache ich im nächsten Sprint?“ im Rahmen des Plannings viel transparenter wird.

Commitments – da lege ich mich fest, die sind gut

Commitments sind ebenso neu in Scrum. Sie sind Zusagen des gesamten Scrum-Teams auf das Product Goal, das Sprint Goal und die Definition of Done. Commitments kennt man aus dem klassischen Projektmanagement, dort werden diese aber anders verwendet. Im klassischen Projekt lässt man sich als Projektmanager beispielsweise von den auszuführenden Personen bestätigen, dass sie ihre Aufgaben im gegebenen Zeitraum und Aufwand umsetzen werden. Das wäre in der agilen Welt in dieser Form nicht anwendbar. Der Grundgedanke ist aber ähnlich, nur ohne den Kontrollgedanken.
Das komplette Scrum-Team verpflichtet sich, das Product Goal, die jeweiligen Sprint Goals sowie die Einhaltung der Definition of Done umzusetzen. Während solche Zusagen beim Product Goal eher die Transparenz fördern, das Ziel in Bezug auf das Softwareprodukt zu verstehen und einzuhalten, wird es beim Sprint Goal und der Definition of Done schon konkreter. Das Team legt sich fest, beide Artefakte verstanden zu haben und deren Inhalte zu berücksichtigen. Das betrifft insbesondere das Sprint Planning, bei dem sich das Team festlegt, das Sprint Goal mit den ausgewählten User Stories zu erreichen und die User Stories gemäß Definition of Done im Sprint fertig zu stellen. Das geschah bislang nur implizit oder auf Nachfrage. Als Scrum Master kennt man die schon gebetsmühlenartige Abfrage bei der Aufwandschätzung, ob die Anforderungen aus der Definition of Done für die jeweilige User Story berücksichtigt wurden. Dieser Part wurde nun formalisiert und wird als Commitment entsprechend dokumentiert.

Commitments schaffen aus meiner Sicht mehr Verbindlichkeit aber auch Transparenz, da durch die Formalisierung explizit auf die Artefakte Bezug genommen wird. Späteres Zurückrudern, im Sinne von: „Ach, ich wusste gar nicht, dass die Definition of Done als Anforderung umzusetzen ist“ gilt damit nicht mehr. Ebenso finde ich aber gut, dass die Commitments das komplette Scrum-Team betreffen, sodass weder Kontrollwahn oder eben auch Finger Pointing („Du hast aber gesagt, Du schaffst es, die Story im Sprint umzusetzen“) entstehen können.

Self-managing Scrum Team – Der Manager ist tot, lang lebe der Manager

Im neuen Scrum Guide ist der Begriff „self-organizing Teams“ durch „self-managing Teams“ ersetzt worden. Das klingt erstmal nicht spektakulär. Laut Wikipedia steht Organisation „auch für den Prozess des Organisierens, „durch den fortlaufende unabhängige Handlungen zu vernünftigen Folgen“ zusammengefügt werden, „sodass vernünftige Ergebnisse erzielt werden“ bzw. so zusammengefügt werden, dass sie zu gewünschten Zielen bzw. Ergebnissen führen.“ Und über Management ist dort zu lesen: „Management (['mænɪdʒmənt]; lateinisch manus, „Hand“ und lateinisch agere, „führen“, „an der Hand führen“), zu Deutsch Verwaltung, ist ein Anglizismus für jede zielgerichtete und nach ökonomischen Prinzipien ausgerichtete menschliche Handlungsweise der Leitung, Organisation und Planung in allen Lebensbereichen.“ Ich denke, aus diesen Definitionen wird der kleine, aber feine Unterschied klar: Zur eigentlichen Selbstorganisierung sind nun auch die Themen Leitung und Planung hinzugekommen.

Heißt das nun, dass Manager in der agilen Welt nicht mehr existieren? Natürlich nicht. Scrum definiert nicht die Organisations- und Managementstruktur von Unternehmen. Allerdings liegt der Fokus auf der Arbeitsweise des Scrum-Teams, die selbst entscheiden sollen, wie was wann am Produkt verändert wird. Heißt eben auch, dass das Scrum-Team Leitung, Organisation und Planung selbst erledigt und eben nicht nur die tägliche Organisation der Tätigkeiten.

Accountabilities – Scrum ist von der Rolle

Bislang war im Scrum immer von Rollen die Rede, also Scrum Master, Product Owner und Entwicklungsteam. Das führte leider in der Vergangenheit oft zu Verwirrung. So schufen Personalabteilungen neue Jobbeschreibungen, die es vielleicht in dieser Form gar nicht für das Unternehmen gab und die sich in der Organisationsstruktur auch nicht wiederfanden. Viele Mitarbeiter werden beispielsweise mal als Scrum Master und mal als Entwickler eingesetzt – müssten daher, formal gesehen, jeweils eine neue Jobbeschreibung bekommen, was schlicht nicht praktikabel ist. Daher wurde der Begriff ‚Rolle‘ durch den Begriff ‚Accountability‘, also Verantwortlichkeit, ersetzt, um klar zu stellen, wer welche Verantwortlichkeit in einem Scrum-Team hat. Wie das Ganze dann in einem Unternehmen in eine Jobbeschreibung mündet, ist nicht das Thema von Scrum, daher begrüße ich diese Begriffsschärfung, da sie klarer macht, wer was im Rahmen von Scrum zu machen hat. Der Begriff ‚Rolle‘ war hier schon historisch zu sehr vorbelastet und führte mehr zur Verwirrung als zu Transparenz.
In der neuen Ausprägung gibt es nun drei Accountabilities: 

  • Scrum Master
  • Product Owner 
  • Entwickler

Das Entwicklungsteam wurde entsprechend durch die Accountability eines Entwicklers ersetzt, worüber ich nicht glücklich bin. Der Begriff wird aus meiner Sicht zu sehr mit einem Software-Entwickler gleichgesetzt, was ja an der Realität vorbei geht. Ich benötige ebenso Spezialisten aller Couleur, welche das entsprechende Inkrement implementieren. Selbst neben „Full-Stack-Entwicklern“, welche in der Realität rar gesät sind, benötige ich immer noch Tester, Administratoren etc.

Ja ist denn schon Weihnachten? – Meine Wunschliste für Scrum

Insgesamt finde ich die Änderungen sehr gut, sie sind ein Schritt in die richtige Richtung. Und auch wenn Weihnachten gerade vorbei ist, ich hätte da noch ein paar Punkte für meine Wunschliste an Scrum:

  1. Mehr Fokus auf das strategische Management eines Softwareproduktes legen! Klassische Produktmanager machen seit Jahren vor, wie man Softwareprodukte erfolgreich managt. Hier wünsche ich mir von Scrum mehr Input. Man muss das Rad ja nicht neu erfinden, es würde ja auch reichen, auf bestehende Standards zu verweisen. Aber wir reden hier von dem Brot-und-Butter-Geschäft eines Product Owners, den Scrum hier leider ziemlich im Regen stehen lässt. Etwas mehr zu Themen wir Produkt Vision, Produktstrategie, Produkt Roadmap würde sehr hilfreich sein, die Accountabilities von Product Ownern besser zu verstehen und sie im Sinne einer guten Softwareentwicklung einzusetzen.
  2. Self-managing Teams sind in fast jedem agilen Projekt die Sollbruchstelle. Ich kann nicht einerseits fordern, dass Scrum Teams sich selbst verwalten, aber das Thema agile Führung dabei vernachlässigen. Hier wünsche ich mir dringend von Scrum, mehr Fokus auf die Scrum Teams und das Führen von Scrum Teams im agilen Kontext zu legen. Ansonsten sehe ich schwarz, Scrum in großen hierarchischen Unternehmen einzuführen.
  3. Entwickler statt Entwicklungsteam ist zwar im Sinne der Accountabilities korrekt, aber der Begriff ist sehr schlecht gewählt. Ich würde mir für den nächsten Scrum Guide wünschen, diesen Terminus durch einen neutraleren zu ersetzen – wie wäre es zum Beispiel mit Implementierer?

#agil #scrum #rollen #newscrumguide #scrum #whatsnew #productgoal #produktmanagement #sprintgoal #commitments #entwickler #accountabilities

 Andreas Milanese

RegTech News! 12. RegTech-Beitrag "Informationssicherheit im Homeoffice" 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 12. RegTech Beitrag:

Informationssicherheit im Homeoffice

War Homeoffice bis vor Jahresfrist eher ein Schlagwort aus dem Dunstkreis Work-Life-Balance, so hat die Corona-Pandemie das Arbeiten von zu Hause in den Fokus der öffentlichen Wahrnehmung gerückt. In kürzester Zeit entstanden in Unternehmen die notwendigen Infrastrukturen, um den Geschäftsbetrieb aus den Wohn-, Arbeits-, Esszimmern oder Küchen der Mitarbeiter fortzuführen. Cyberkriminelle nutzen die entstehenden Angriffsflächen aus, die Zahl der Attacken auf Unternehmensnetzwerke stieg stark an. Wie Banken bei Homeoffice-Lösungen auf der sicheren Seite bleiben zeigt unsere zweiteilige Beitragsserie!  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!

ESG – haben Sie den Schuss schon gehört?

Kürzlich fiel mir eine meiner ersten Bewerbungen aus dem Jahr 1986 in die Hand. Darin war zu lesen, dass „es in unserer Volkswirtschaft noch viele Probleme zu bewältigen gibt, bis wir im Stande sind, nicht nur ökonomisch vorteilhaft, sondern auch ökologisch sinnvoll zu produzieren …“. Weiter hieß es, dass es Ziel sein sollte, den Wohlstand zu heben und das Leben sicherer und lebenswerter zu machen. „Sieh mal einer an“, dachte ich mir. Der Kerl war damals noch keine 18 Lenze alt und stand schon dort, wo die EU jetzt hin will. Seinerzeit haben saurer Regen und Tschernobyl einen ersten tiefen Graben im Bewusstsein vieler Menschen hinterlassen und eine erste Ahnung, dass es wohl so nicht endlos weitergehen kann.

Nun, über drei Jahrzehnte später, haben wir einen „Green Deal“ der EU und diverse internationale und nationale Vorhaben und Regulierungsansätze, die offen darauf ausgerichtet sind, die Finanzströme in Richtung eines nachhaltigen Wirtschaftens zu leiten. ESG ist hier das Schlagwort, das immer mehr Raum in der öffentlichen Diskussion der Finanzbranche einnimmt und viele neue und alte Akteure auf den Plan ruft. Dahinter stecken die auch als Nachhaltigkeitsaspekte bezeichneten Themen von E für Environment, S für Social und G für Governance.

Diese Materie ist uns in der Finanzindustrie nicht unbekannt. Sie steht bereits seit einigen Jahren hauptsächlich im Fonds- und Anlageberatungsgeschäft auf der Agenda. Hier geht es im Wesentlichen darum, die sich zunehmend ändernden Präferenzen von Investoren in Bezug auf ökologische Nachhaltigkeit, soziale Mindestnormen und Aspekte der Unternehmensführung zu berücksichtigen. Ganz banale Beispiele sind Investitionen, die auf Waffengeschäfte, Kinderarbeit, Gen- oder Kerntechnik verzichten. Hierfür gibt es schon eine Menge Gütesiegel mit unterschiedlichen Schwerpunkten und unterschiedlicher Akzeptanz.

Ich selbst beschäftige mich mit den recht jungen Anforderungen an das eigene Risikomanagement der Institute. Hierbei geht es nicht allein um die Interessen von Kunden und anderen Stakeholdern, sondern vielmehr um das Eruieren der möglichen und konkreten Auswirkungen von Veränderungen in Umwelt, Gesellschaft und Politik auf die eigenen Risikopositionen. Während die meisten Menschen häufig den „moralischen“ ESG-Score kennen, der hauptsächlich auf Kaufentscheidungen von Investoren abzielt und seine größte Wirkung in der Reputation von Unternehmen entfaltet, geht es zukünftig im Risikomanagement eher darum, diejenigen Treiber zu identifizieren, die die wesentlichen Risiken in den Banken beeinflussen. Aus diesen Kerntreibern wird dann der ESG-Impact-Score gebildet. Er beeinflusst Kreditentscheidungen und fließt in neue Szenarioberechnungen ein.

Das alles ist bei weitem nicht so trivial wie es den Anschein hat. Zudem drängt die Zeit: Die Umsetzung der neuen Datenanforderungen und auch die Implementierung neuer Methoden dauern einfach. Daneben schmerzt mich sehr, dass bei vielen Beteiligten das grundlegende Verständnis für den Umfang des Wandels zu fehlen scheint. Es sind nämlich die gesamte Organisation und sämtliche operativen Prozesse betroffen, angefangen vom Aufsichtsorgan über sämtliche operative Einheiten bis hin zum Hausmeister. Viele Marktteilnehmer scheinen aber den Startschuss immer noch nicht gehört zu haben – schlimmer noch: Sie bewegen sich nicht einmal in Richtung Startblock!

Auch wenn die Branche gerade dabei ist, den zweiten Schritt hin zu mehr Nachhaltigkeitsbewusstsein zu wagen, so ist der Weg zum Ziel noch weit. 

Etwas Orientierung auf dem Pfad liefern hier unsere aktuellen Whitepaper: www.ppi.de/banken/regulatorische-anforderungen/qualitative-bankenaufsicht/whitepaper-esg-risiken/

Thomas Maul
 

Teil 4: Agile Transformation in Banken - Warum regulatorisch agil nicht agile Regulatorik bedeutet

Die Bankenwelt unterliegt einer strengen Regulatorik, was an sich genommen ja erst einmal nicht schlecht ist: Diese verbessert die Marktintegrität, stärkt Anlegervertrauen und formuliert klare Anforderungen an das Risikomanagement der Institute. Die bankaufsichtlichen Anforderungen an die IT (BAIT) sind dabei Verwaltungsanweisungen für die sichere Ausgestaltung der IT-Systeme sowie der zugehörigen Prozesse und diesbezüglicher Anforderungen an die IT-Governance. Zugegeben: Das war jetzt direkt zu Beginn eine Menge Juristerei. Wer aber schon mal versucht hat, einen großen Einkauf zu tätigen und weder EC-Karte noch Geldautomat funktionierten, weiß, dass diese Regelungen durchaus Sinn machen.

Das Papier wurde elektrifiziert, die Regulatorik blieb

Die Zeiten, in denen Kundenaufträge auf einem Papierformular notiert und per Kurier an die bearbeitende Einheit gesendet wurden, sind, bis auf ganz wenige Ausnahmen, vorbei. Kreditinstitute bilden vernünftigerweise ihre bankfachlichen Prozesse mit IT-Systemen ab. Zugegebenermaßen ist aber nicht alles dadurch einfacher geworden: So reichte es früher aus, einen Antrag auf Formularänderung zu stellen und ein neues Formular mit neuer Versionsnummer drucken zu lassen. Heute müssen solche Änderungen an der IT-Landschaft akribisch dokumentiert werden. Ohne Fach- und IT-Konzept, Release Notes oder Testabnahmeprotokolle geht nichts mehr – und das ist auch gut so. Denn damit wird sichergestellt, dass die in Produktion befindliche Software auch nachvollziehbar dokumentiert ist und sie genau das tut, was sie tun soll.

Augen auf bei der Einführung agiler Frameworks, denn ohne Regulatorik keine Produktivstellung!
Die sogenannten „Betrieblichen Anweisungen“ regeln die Erstellung dieser Dokumentationen und sind somit auch Gegenstand von Prüfungen durch einen Revisor. Dumm nur, dass sie in der agilen Softwareentwicklung gar nicht mehr explizit vorkommen. Was passiert? Spätestens bei der Produktivstellung rennt man ohne die erforderliche Dokumentation schlicht gegen die Wand. Ist Agilität bei Finanzdienstleistern also unmöglich? Natürlich nicht, allerdings muss diese sehr eng mit der Revision abgestimmt werden. Die Lösung ist ein agiles Governance-Modell, das auch die Anforderungen aus Sicht des Regulators erfüllt. So weit, so gut. Aber was bedeutet das jetzt konkret für mich, wenn ich agil arbeiten möchte? Fallen die bestehenden Dokumentationen etwa einfach weg?

Entwickler und Dokumentation – zwei Welten treffen aufeinander

Das gängige Vorurteil lautet: Entwickler dokumentieren nicht gerne. Als der Punkt „Funktionierende Software mehr als umfassende Dokumentation“ im Agilen Manifest veröffentlicht wurde, löste dies einen Jubelsturm unter Entwicklern aus. Endlich mal voll auf die Programmierung fokussieren und nicht auch noch auf die lästige Erstellung von Konzepten oder so grausamen Dingen wie Sourcecode-Dokumentationen. Schließlich beweisen ja Compiler und die sehr umfangreichen funktionalen Tests, dass die Entwicklung allerhöchste Qualität hat. Dummerweise verzweifelten genau jene Entwickler dann aber am Betrieb, auch Run-The-Bank genannt, aus, die eben solche Dinge vehement einforderten, bevor sie bereit waren, sie produktiv einzusetzen. Da diese nicht im Rahmen der agilen Softwareentwicklung erstellt wurden, weigerte sich der Betrieb in seiner Rolle als Quality Gate, die Software auch wirklich produktiv zu stellen. Dahinter stecken regulatorische Anforderungen, die sicherstellen sollen, dass Entwickler Software nicht in betrügerischer Absicht manipulieren, sodass sie selbst oder Außenstehende davon profitieren. Leider führt das oftmals dazu, dass in einem förmlichen Kontrollwahn viele nicht sinnvolle Dokumentationen eingefordert werden, die sich sehr stark am historischen Wasserfallmodell orientieren. 

Schon Immanuel Kant sagte: „Habe den Mut, dich deines eigenen Verstandes zu bedienen.“
Klar ist: Die bisherigen Ergebnisdokumente scheinen wenig tauglich für die agile Vorgehensweise. Natürlich kommen jetzt ein paar Schlaumeier und fangen an, alte Ergebnistypen einfach auf neue abzubilden, um so die regulatorischen Anforderungen zu erfüllen. Wer aber schon mal versucht hat, alle User Stories als ein Fachkonzept zusammen zu bekommen, weiß, dass das nicht funktionieren kann. Spätestens beim DV-Konzept steht man dann mit leeren Händen da.
Da ist es doch durchaus sinnvoller, zu verstehen, warum diese Dokumente regulatorisch verpflichtend sind und wie sich diese regulatorische Anforderung auf die agile Welt projizieren lässt. Anders gesagt, es hilft mehr, die Ursache zu verstehen, als die Symptome zu reduzieren. Ich mache es mal an einem Beispiel klar: Bislang erstellte der Fachbereich ein Fachkonzept. Die IT prüfte dieses ausgiebig und nahm es schlussendlich ab. So wurde im Wasserfallmodell sichergestellt, dass die fachliche Anforderung von der IT verstanden wurde. Dieses ganze Procedere stammt aus einer Zeit, zu der ich noch gar nicht im Berufsleben stand, also schon fast prähistorisch. Klar, seinerzeit gab es noch die Bankmitarbeiter, für die IT ein Fremdwort war, und ITler, deren bankfachliches Verständnis sich auf das eigene Girokonto beschränkte. Dummerweise halten alle Beteiligten nach wie vor an dieser Umsetzung der regulatorischen Anforderung starr fest, anstatt zu überlegen, wie man diese sinnvoll auf die agile Welt anpasst.

Das regulatorische Gebot lautet nicht: „Du sollst ein Fachkonzept schreiben“

Wer in der agilen Welt noch Fachkonzepte und deren Freigabe durch die IT fordert, hat die eigentliche regulatorische Anforderung nicht verstanden oder kurz: hat den Schuss noch nicht gehört. In agilen Teams werden User Stories zur Umsetzung geschrieben. Diese werden nicht mehr explizit durch die IT freigegeben, sondern in Form des Backlog Groomings vom Product Owner dem Entwicklungsteam erläutert. Haben diese alles verstanden, werden User Stories auf „ready“ für die Umsetzung gesetzt. Hier gibt es also ein Quality Gate, welches das gemeinsame Verständnis von Fachseite (Product Owner) und IT-Seite (Entwicklungsteam) dokumentiert, analog einer Freigabe des Fachkonzeptes. Solange eine User Story nicht verständlich für das Entwicklungsteam ist, kann sie nicht in ein Sprint Backlog überführt und umgesetzt werden. 

Wer regulatorische Anforderungen effizient erfüllen möchte und nicht einfach nur historische Umsetzungen dieser Anforderungen blind übernehmen will, muss zwangsläufig das agile Governance-Modell anpassen. Die entsprechenden Kontrollmechanismen, etwa in Form von Quality Gates oder Seggregation of Duties, sind folglich so einzusetzen, dass sie die Regulatorik an diesem Prozessschritt bestmöglich unterstützen. Das bedeutet beispielsweise, dass im Agilen über die Definition of Done festgelegt ist, welche Dokumente zu erstellen sind, um eine Software produktiv zu setzen. Die eigentliche Produktivsetzung erfolgt dann aber durch gesondertes Personal. Das erfordert zunächst einmal, dass man sich ernsthafte Gedanken über die wahrhaftigen Anforderungen machen muss, anstelle Bestehendes blind zu übernehmen. Dies würde ich mir im Übrigen nicht nur von der Change-the-Bank-Organisation, sondern insbesondere auch von den Revisoren und Prüfern der Bank wünschen.

 Gib dem Prüfer Futter – Das betriebliche Anweisungswesen

Wie in meinem vorherigen Blog-Artikel schon erwähnt, erfordert agiles Arbeiten die „Agilifizierung“ der IT-Prozesse. Damit ändern sich aber die Prozesse und diese Änderungen müssen auch über betriebliche Anweisungen abgesichert sein. Ansonsten führt jede §44-Prüfung zu fatalen Ergebnissen. Denn: Prüfer beurteilen nicht die Sinnhaftigkeit eines Prozesses, sondern die Einhaltung dessen Vorgaben aus den Arbeits- und Verfahrensanweisungen. Selbstverständlich müssen neben den bankfachlichen auch die IT-Prozesse im Rahmen der Betrieblichen Anweisungen beschrieben werden. Somit erhalten die Prüfer eine saubere Grundlage für ihre Arbeit, die Mitarbeiter einen Rahmen zur agilen Vorgehensweise und zudem lassen sich Schnittstellen zu anderen Organisationseinheiten beschreiben. Besonders die Einhaltung regulatorischer Quality Gates und die Seggregation of Duty sind als Anforderung hier zu formulieren und deren Umsetzung zu beschreiben.



Mein Fazit zur Regulatorik: Agiles Vorgehen bedarf keiner Aufweichung der regulatorischen Anforderungen, es kann auch regulatorisch konform eingesetzt werden. Insbesondere die Definition of Ready und die Definition of Done stellen hier gute Quality Gates dar, deren Einhaltung über den Prozess einfach sicherzustellen und nachzuweisen ist. Ein agiles Governance-Modell liefert hierbei den Rahmen.

#agil #scrum #it-prozesse #it-dokumentation #agileprozesse #agilesgovernancemodell #it-governance #governancemodell #regulatorik #qualitygates #seggregationofduties

Andreas Milanese