9. Januar 2015Tags: Keine Kommentare Simon Krüger

Ein Erfahrungsbericht von Daniel Schäfer

Hier geht es zu Teil 1 des Erfahrngsberichts

Follow Up

> Doch wie wird sich dieses Training auf meine Arbeit im Projekt auswirken?

Der vierwöchige Intensivkurs zum Thema Bankwirtschaft hat sich als echter Gewinn und solide Grundlage für die Arbeit in der Bank-IT erwiesen. Mit dem Verständnis für Bankprozesse bin ich besser auf die funktionalen Erfordernisse von IT-Entwicklungen vorbereitet als manche meiner Kolleginnen und Kollegen, die sich diese Kenntnisse erst „on the job“ aneignen mussten.

> Kann man wirklich erwarten, dass ich in 3 Monaten alles relevante für meinen neuen Job lerne?

Nein, das kann man natürlich nicht. Ein Quartal ist gerade genug Zeit um zu lernen, was ich noch alles lernen muss. Unter Quereinsteigern – und von dieser Spezies gibt es sehr viele – hat mir diese Zeit jedenfalls einen deutlichen Vorteil verschafft.

> Und wie werde ich die ersten Tag im Projekt überstehen?

Der erste Tag ging so schnell um, dass von „überstehen“ überhaupt nicht die Rede sein kann. Es hilft dabei, dass von mir überhaupt nicht gefordert wird, gleich zu Beginn Bäume auszureißen. Vielmehr wird von mir erwartet, zuzuhören und so viel in mich aufzunehmen, wie mir mein Umfeld vermitteln kann – und dieser Anforderung fühle ich mich als Akademiker ganz sicher gewachsen.

Vom Trainingslager zum Kunden

Nach zehn Wochen Ausbildung in Bankwirtschaft und SAP Grundlagen/Vertiefung steht nun der Wechsel an – oder, wie es nun in der schnelllebigen Welt der IT-Projekte heißt, der „Cut-Over“.

Vielleicht sollte ich zunächst einige grundlegende Dinge erklären, bevor ich weiterschreibe – grundlegende Dinge über die IT-Struktur einer Großbank und grundlegende Dinge über die Applikation, mit der ich mich befassen werde.

Vereinfacht ausgedrückt wird die IT einer Großbank aufgrund regulatorischer Erfordernisse in zwei Bereiche unterteilt , die durch einen hohen Zaun voneinander getrennt sind – „Change the Bank“ und „Run the Bank“.  Dem zugrunde liegt das „Vier-Augen-Prinzip“, das besagt, dass an allen wichtigen Entscheidungen wenigstens zwei Personen beteiligt sein müssen um zu vermeiden, dass Einzelpersonen durch Nachlässigkeit (oder gar böse Absicht) der Bank schaden – man betrachte den Fall Nick Leeson bei der Barings Bank (1995) wenn man sehen möchte, welche Konsequenzen die Nicht-Beachtung dieses Prinzips haben kann. Folglich trennt man den Betrieb der Produktivsysteme von deren (Weiter-)Entwicklung und stellt auf diese Weise sicher, dass alle Änderungen zunächst auf Seite der Projektentwicklung sorgfältig konzipiert, umgesetzt und getestet werden, bevor sie abgenommen und auf die Produktionsseite übertragen werden.

Behalten wir dies nun für einen Moment im Hinterkopf, während ich die zweite grundlegende Sache erkläre. Die Applikation, mit der ich mich in meiner Tätigkeit bei der Bank beschäftigen soll, ist ein SAP-Modul, das als „Bank Analyzer“ (BA) bezeichnet wird. Der Bank Analyzer ist ein sogenanntes „Dezidiertes Nebenbuch“ und ermöglicht (u.a.) das zeitnahe, effiziente und umfassende regulatorische Reporting (also vor allem das Aufstellen der Bilanz). Als Nebenbuch führt der BA die Bewertung und Aggregation von Finanzpositionen durch, die dann in kompakter Form ins Hauptbuch geschrieben werden. Aufgrund dessen sitzt der Bank Analyzer ziemlich im Zentrum eines komplexen Geflechts aus Abhängigkeiten und Datenströmen der IT-Systeme der Bank (obwohl ich den Verdacht hege, dass jede andere Applikation das ebenfalls von sich behauptet).

Führen wir nun die beiden vorangegangenen Gedankenstränge zusammen: im Rahmen eines großen IT-Projekts hat die Großbank, bei der ich arbeite, also beschlossen, ihre IT-Landschaft auf den SAP-Standard umzustellen. Diese Umstellung erfolgt in Schritten, so dass sich aus Sicht des Bank Analyzers folgendes Bild ergibt: mit jedem der sogenannten „Major Release“ (halbjährliche Entwicklungs-Meilensteine) werden dem BA mehr und mehr Funktionalitäten übertragen, indem Stück für Stück mehr Vorsysteme in die Produktion integriert werden. Für die Entwicklung dieser Releases ist das Bank Analyzer-Projektteam zuständig, das sich auf der „Change the Bank“-Seite befindet. Dem gegenüber steht das Bank Analyzer-Support-Team auf der „Run the Bank“-Seite, also diejenigen Personen, die mit dem täglichen Betrieb des BA betraut sind und sicherstellen, dass die Produktion ungestört laufen kann.

Was aber hat das alles mit mir, dem angehenden SAP-Berater, zu tun? Nun, die Antwort stellt sich wie folgt dar: ich werde die kommenden 18 Monate im Projekt-Team verbringen und an der Entwicklung des Release 2/2015 beteiligt sein, um nach Abschluss dieser Phase auf die andere Seite des Zauns zu wechseln und im Support zu arbeiten. Die Idee dahinter ist, dass wohl niemand die „Bank Analyzer“-Applikation besser in der Produktion unterstützen könnte als die Entwickler selbst – oder jemand, der den Entwicklern über die Schultern schauen konnte.

TLAs und ITIL

Schon nach dem ersten Meeting der Entwickler, an dem ich teilnehmen durfte, ist klar, wie groß die Komplexität ist – die Komplexität des Bank Analyzers und seiner vielen Abhängigkeiten und die Komplexität des Raums der TLA, der „Three Letter Abbreviations“; für den ersten Monat habe ich nämlich den Eindruck, dass es zunächst weniger darum geht, die genaue Funktionsweise des Bank Analyzers als vielmehr die Sprache der Entwickler verstehen zu lernen.

Der Bank Analyzer ist ein Nischenprodukt, womit klar ist, dass es keinen einfachen, linearen Weg und schon gar kein didaktisches Konzept geben kann, sich die nötigen Kenntnisse anzueignen. Vielmehr ist Eigeninitiative gefordert, sich selbst in das Thema einzuarbeiten, indem ich das, was ich höre, sehe und tue, sinnvoll mit dem verknüpfe, was der SAP-Online-Kurs (der „LearningHub“) über den Bank Analyzer sagen kann (was, verglichen mit den SAP-Modulen, die größere Verbreitung gefunden haben, nicht viel ist und bestenfalls eine unterstützende Rolle darstellt). Damit lässt sich die Art und Weise, in der ich mir das nötige Fachwissen über diese Applikation aufbaue, auf zwei Konzepte zurückführen: „Osmose“ (ungerichtetes „Aufschnappen“ von Informationen in Meetings und Diskussionen mit den Entwicklern) und „Akkumulation“ (zielgerichtetes Lernen, wobei dieser Aspekt den deutlich kleineren Anteil meines Lernprozesses darstellt).

Nachdem ich dann aber herausgefunden habe, dass praktisch alle meine Kolleginnen und Kollegen „Quereinsteiger“ in das Thema Bank Analyzer sind und ich folgere, dass sie alle durch diese steile Lernkurve steuern mussten (ohne von den Fliehkräften hinausgetragen zu werden), wächst meine Zuversicht, dass auch ich dieses Thema bewältigen kann.

Aber natürlich soll mein persönlicher Entwicklungsprozess als SAP-Berater nicht völlig unstrukturiert und informell ablaufen, denn es liegt auch im Interesse der Talentschmiede und der Bank, dass wir nachprüfbare Ergebnisse erzielen. Ein wichtiger Meilenstein auf diesem Weg ist daher die dreitägige ITIL-Grundlagen-Zertifizierung. Diese Schulung dient zur Entwicklung eines besseren Verständnisses von (und größerer Wertschätzung für) IT-Prozesse in Großorganisationen, denn hinter den vielen willkürlich erscheinenden Strukturen und Abläufen steckt oft eine tiefere organisatorische Wahrheit, die erst durch viele schmerzliche Erfahrungen ans Licht kam und nun als „Best Practice“ weitergegeben wird.

Splitting the Atom

Nach wenigen Wochen auf Projektseite wird meine Flexibilität unversehens auf die Probe gestellt: aufgrund von Personalengpässen auf der Support-Seite wird in Absprache mit meiner Kollegin und mir beschlossen, dass wir fortan unsere Zeit nach einem zweiwöchigen Rotationsschema zwischen Support und Projekt aufteilen. Einerseits sammle ich damit mehr als ein Jahr früher als geplant Erfahrung auf Produktionsseite, andererseits wird dadurch die fachliche Ausbildung auf Projekt-Seite sicherlich nicht ganz so umfangreich und intensiv ausfallen, wie ursprünglich vorgesehen. Allerdings sollte man auf solche notwendigen Änderungen innerhalb einer Großorganisation mit der nötigen Flexibilität und Optimismus reagieren und die Chancen solcher Entwicklungen sehen.

Und in der Tat erwies sich dieser „split“ für mich als außerordentlicher Beschleuniger des Lernprozesses, denn so habe ich die Gelegenheit, dieselben Themen von zwei Seiten zu sehen – aus der Sicht der Entwickler und durch die Brille der Produktion. Nach ungefähr zwei Monaten bemerke ich, dass sich die Menge an (un- oder nur teilweise zusammenhängenden) Einzelfakten zu einer kritischen Masse verdichtet und sich zu einem Gesamtbild zusammenfügt hat, das die Funktionalität der Applikation beschreibt. Auch haben sich eine Reihe von Synergien aufgetan, die vorher nicht abzusehen waren, was die Zeit, bis ich erstmals selbst zum Geschehen beitragen kann, verkürzt hat.

Es ist außerdem höchst spannend, die Auswirkungen (neue Funktionalitäten, geänderte Strukturen) eines neuentwickelten Release unmittelbar auf die Produktions-Seite zu sehen. Das ist auch der tiefere Sinn des Splittings: unmittelbar sehen, welche Probleme Entwickler für die Produktion verursachen können – die nicht immer ganz glückliche, wiewohl notwendige, Trennung zwischen „Change the Bank“ und „Run the Bank“ wird dadurch ein wenig aufgeweicht.

Dadurch, dass meine Kollegin und ich unsere Zeit zwischen Projekt und Support aufteilen, entsteht eine informelle Brücke zwischen den beiden Seiten des Zauns – etwas, was schon lange als erstrebenswert galt, nun aber erst konkret realisiert wird.

Wie wird sich das Projekt weiterentwickeln?

Wie wirkt sich die Doppelbelastung im Support und der Entwicklung auf mein zukünftiges Lernen aus?

Wann trage ich selbst noch mehr zum Geschehen bei und wie wird es mir dabei ergehen?

Und wie fällt mein Resümee nach mehr als einem halben Jahr bei der Talentschmiede aus?