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
0 Kommentare:
Kommentar veröffentlichen