“Der Fachbereich einer Bank kann Agil – ne, oder??” – der IT-Praxis-Bericht des Raiffeisenverbands Salzburg

Wir arbeiten im SCRUM oder LESS, bauen SAFE, wandeln uns zu Scrum-Mastern und fixieren einheitliche Sprintzyklen – und bekommen dann zu hören, dass trotzdem nichts vorangeht, nichts fertig wird, nichts beim Kunden ausgerollt ist? Der IT-Praxis-Bericht

von Michael Baldauf und Wolfgang Schmidt, Raiffeisenverband Salzburg

Wie kann das sein? Ok, wir wissen alle, wie es sein kann. Seit Jahren diskutieren die IT Communities, wie wir eine bessere time-to-market realisieren können und damit besser auf kurzfristige Änderungen von Anforderungen aus den Fachbereichen reagieren können. Haben wir es endlich geschafft, uns aus unserer eigenen Lethargie zu befreien, treffen wir auf Arbeitsanweisungen, starre Prozesse, überladene IKS-Systeme und – leider viel zu oft – unklare Strategieanforderungen, die sich mit jedem neuen FinTech, das gehypt wird, ändern.

Wie oft haben wir das Thema der langfristigen Visionen gehört, der Mittelfrist- oder Jahresstrategien. Im täglichen Leben sind sie kaum umsetzbar, wenn eine immer schneller werdende IT-Organisation mit immer selbständigeren Mitarbeitern auf eine in Starrheit verharrende Business Organisation trifft, die in veralteten Regeln und Hierarchien arbeitet.

Ist die Lösung also SCRUM im Fachbereich?
Können wir SAFE über eine Bank stülpen?”

Natürlich ist es nicht so einfach. Es war bei unseren IT-Einheiten nicht einfach – es ist auf Fachseite noch weniger einfach. Nicht, weil die Fachbereiche weniger intelligent oder weniger wendig sind. Marketing ist oft ZU wendig. Die Welt der Abwicklung folgt indes oft noch anderen Regeln, geprägt vom §25a KWG (Deutschland) bzw. §39 (2) BWG (Österreich) – oder jedem beliebigen Pendant dazu in allen anderen EU Ländern.

Prozesse, Re­geln und kla­re, star­re Kon­troll­sys­te­me – über Jahr­zehn­te ha­ben wir sie auf­ge­baut. Der Spa­gat zwi­schen schnel­lem Kun­den­nut­zen und prüf­ba­rer Ent­schei­dungs­fin­dung/Re­gel­än­de­rung scheint unüberbrückbar.”

Scheint so – es gibt aber auch Möglichkeiten, die beiden Welten zu verbinden. Dem Fachbereich SCRUM zu verordnen reicht nicht. Auch nicht, die Product Owner ausschließlich aus dem Fachbereich zu rekrutieren.

Der Kern der Lösung liegt – wie so oft – in einem genaueren Studium der Anforderungen, dem die Fachbereiche unterworfen sind. Sie benötigen Dokumentation, offiziell beschlossene Prozessänderungen, zentrale Regelwerke – im Endeffekt sprechen wir von den verschiedenen Ebenen der Unternehmensarchitektur (EAM – Enterprise Architektur Management) mit einigen leichten Anpassungen. Die uns bekannten vier Ebenen des EAM müssen um die fachbereichsrelevanten Anforderungen ergänzt werden.

Zu Prozessen, Daten, Anwendungen und Technologie kommen Geschäftsarchitektur, Security und Governance hinzu.

Prozesse konzentrieren sich auf die Frage, wer was in welcher Reihenfolge abarbeitet. Für die Fachbereiche und die Prüfer ein unabdingbares Gut, sind sie doch erst vor wenigen Jahren wörtlich in die entsprechenden Paragrafen aufgenommen worden.

Weder Prozess noch Organisationsstruktur können direkt infrage gestellt werden – durch das Einbeziehen einer übergeordneten Ebene gelingt es aber, die Diskussion zu versachlichen und eine einheitlichere, zukunftsorientierte Sicht auf die fachlichen Anforderungen zu bekommen und gleichzeitig eine gute Gliederungsebene für die IT-Organisation zu erhalten.

Auf der Ebene der Geschäftsarchitektur betrachten wir Blöcke von Geschäftsfunktionen und bewerten sie nach ihrer Relevanz heute und in der Zukunft, der Qualität ihrer technischen, fachlichen und personellen Ausstattung heute und in der Zukunft, und – voilà – haben wir eine offene Diskussionsbasis für Fachbereichsanforderungen.

Dabei stehen erst einmal Fragen der Skalierung im Vordergrund: Welche Geschäftsfunktionen müssen wir als erstes anpassen, an welchen müssen wir nicht arbeiten?

Auf dieser Basis können wir Prozessmanager mit in die Diskussion einbeziehen und ihnen ermöglichen, von Anforderung bis Umsetzung zu denken und ihre eigenen Anpassungen zu planen. Dazu müssen wir den Planungshorizont von Sprint auf Etappe erhöhen – in unserem Fall 6 Sprints gleich 3 Monate.

Dabei kommt den Prozessmanagern als Bindeglied und Katalysator eine besondere Aufgabe zu. Ihre Tätigkeitsgebiete erweitern sich von der Prozessgestaltung und -optimierung zu einem ganzheitlichen Bindeglied.

Durch diese Erweiterung und der Diskussion auf der Ebene Geschäftsarchitektur lassen sich auch rechtliche/Compliance Anforderungen leicht abbilden und sogar mit Risiken für die Bank versehen.

Einerseits erleichtert das die Planung, andererseits ermöglicht es den Fachbereichen, selbst in Lieferstrecken zu denken und so ihr eigenes – und damit unser – WiP (Work-in-Progress) erst transparent zu machen und dann zu reduzieren.

In unserem Fall war Scrum/SAFE zu starr, aber die klassischen Kanban-Boards haben in den Fachbereichen hervorragende Dienste geleistet.

Dem Fachbereich war die Aufteilung in Backlog, To-Do, Doing, Done sehr schnell eingängig – und erlaubte gleichzeitig, die Anforderung an geregelte Prozessänderungen einzuhalten.

In den Etappen-Planungstagen sind jetzt nicht nur die IT-Organisation, sondern auch die Fachteams vollständig vertreten. Zum Start werden die aktuellen Unternehmenskennzahlen und ggf. abweichende/neue Anforderungen durch Markt, Aufsicht oder Geschäftsleitung präsentiert – inzwischen in der Regel durch einen Geschäftsleiter/Vorstand. So kann auf anstehende Prüfungen oder ungewöhnliche Marktbewegungen relativ schnell reagiert werden.

Geplant wird jeweils eine Etappe (3 Monate/6 Sprints). Längere Lieferstrecken als Verbindung zwischen Fachbereichs- und IT-Backlog erlauben, die Lieferstrecke an sich als WiP zu betrachten und zu steuern. Keine neuen Lieferstrecken öffnen, bis die alten nicht abgearbeitet sind. Und innerhalb der Lieferstrecke ist die Anpassung der Compliance-Anforderungen, sei es IKS, Risikohandbuch oder Prozessdokumentation, ein integraler Bestandteil.

Die Abstimmung mit allen zuliefernden Einheiten erfolgt im Marktplatz, an dem alle Abteilungsleiter aus IT und Fachbereichen, alle Anforderer größerer Leistungspakete teilnehmen. Die Dokumentation dieser Beschlüsse dient als Abnahme gemäß der oben genannten Gesetze und diverser Zertifizierungen.

Als nächste Ausbaustufe werden die fachlichen und technischen Engpässe über die Lieferstrecken gemappt. Wo können wir starten, da wir keine Engpassressourcen belasten? Wie können wir Engpässe optimieren, indem wir IT und Fachbereiche erst temporär, dann immer regelmäßiger zusammen in einen Raum setzen? Wie können wir neben Cross-(funktionalen/bereichsübergreifenden) Teams aus Fachbereichen und IT auch im operativen Geschäft Mitarbeiter – und damit Wissen und Kapazitäten – austauschen?

Eine intensive Schulungsreihe für alle „Cross-Teams“, bestehend aus 5 Modulen von Unternehmenssteuerung bis Gesprächsführung, ist für Zusammenarbeit und Verständnis sehr förderlich.

Durch die regelmäßige Planung und die gemeinsamen Schulungstage können Fachbereiche, Entwickler, Prozess- und Risikomanager sehen, wann und wo sie Geschwindigkeit aufnehmen müssen, Dokumentationen, Schulungen und Regelwerke kurzfristig anpassen müssen – und wo man langsamer voranschreiten kann/muss. Gemeinsam gestalten sie Planning Days und Sprint-Reviews.

Fazit – Scrum und agile Methoden funktionieren!

Der Fachbereich kann – trotz aller Regeln und Vorgaben der Aufsicht – agile Methoden nutzen und vor allem ein agiles Mindset entwickeln. Es braucht nur sehr viel mehr Arbeit und Geduld, für jede Regel eine entsprechende Lösung zu finden.Michael Baldauf und Wolfgang Schmidt, Raiffeisenverband Salzburg