Deutschland: Schwerpunkt PLZ 6 und 7, bei Bedarf temporär bundesweit
Wir haben zur Verbesserung der Zusammenarbeit und Information im Stadtteil eine Vernetzungsplattform konzipiert (Projekt 71). Diese Vernetzungsplattform soll nun implementiert werden. Dazu führten wir eine Ausschreibung durch. Wir definierten notwendige Dokumente und Prozesse. Durch das Vergabeverfahren zielten wir zusätzlich darauf ab, dass der zu beauftragende Dienstleister eine Qualitätssicherung der Ergebnisse des Projektteams vor der Umsetzung durchführt. Am Ende wählten wir einen Anbieter aus.
Projektkontext:
Die Bank und Tochtergesellschaften vertreiben im Zuge der Kreditvergabe Sicherheitspakete und Anlageprodukte, die aus Versicherungen bestehen oder enthalten. Daher war im Rahmen dieser Prozesse die neue EU Versicherungsvertriebsrichtlinie IDD anzuwenden. Die IDD bietet einen Regelungsrahmen für die nationalstaatliche Umsetzung des Versicherungsvertriebs und ist daher für den deutschen Versicherungsvertrieb von eminenter Bedeutung. Daher wurde das Programm IDD implementiert.
Programmaufgabe:
Als ich die Programmleitung für die Domänen Investment und Lending übernahm, waren einige organisatorische Vorbereitungen bereits durchgeführt sowie das Budget beantragt und bereitgestellt. Alle weiteren Aufgaben sollten mir obliegen. Daher implementierte ich umgehend eine Projektorganisation. Für die Projektarbeit im Bereich Finance setzte ich einen Projektleiter ein, der alle in diesem Bereich erforderlichen Projektaufgaben managen und an mich berichten sollte. In der Domäne Lending implementierte ich drei Projekte. Die Leitung des Projektes für das Onlinekreditsystem Consumer Finance übernahm ich, um Bezug zu den fachlichen Inhalten und dem Team zu halten. Parallel zu meinen Tätigkeiten als Projektleiter führte ich alle Aufgaben eines Programmanagers aus. Dabei führte ich die synchronisierende Planung und Steuerung meiner im Programm verbundenen Projekte durch. Zusätzlich verwaltete ich das Programm- und das Lending Projektbudget. Die Verwaltung des Budgets für die Domäne Finance hatte ich meinem Projektleiter übertragen. Weiterhin stellte ich neben der Budgetplanung die Ressourcenplanung sicher und führte alle Projekt- und Programmreportings durch. Auch hier hatte ich das Reporting für den Financebereich meinem Projektleiter übertragen. Ferner fungierte ich als Schnittstelle zu allen involvierten Stakeholdern und Gremien.
Für die Lending Projekte im Bereich Kredit- und Finanzierungsplanung Private Kredite sowie Restkreditversicherung Baufinanzierung setzte ich jeweils einen Projektleiter ein, der alle in diesem Bereich erforderlichen Projektaufgaben managen und an mich berichten sollte. Mit meinen Projektleitern vereinbarte ich Aufgabenbereiche sowie Vorgehensmodell inklusive der von mir erwarteten Deliverables. Zusätzlich richtete ich die erforderlichen Jour Fixes für die Projekte und das Programm ein. Besonderen Wert legte ich auf den regelmäßigen fachlichen Austausch mit dem Programmleiter der Businessseite. Dies insbesondere deshalb, da die Versicherungsrichtlinie noch in der Entstehung war. Die daraus resultierende Unschärfe mussten wir immer wieder aktuell technisch und fachlich bewerten und in unsere Gesamtplanung einbeziehen. Diese Abstimmung gelang exzellent und trug deutlich zum Projekterfolg bei. Wir haben im Zuge des Gesamtprogramms auf Basis des damals aktuellen Referentenentwurfs und unter Einbeziehung der politischen Diskussion Arbeitshypothesen abgeleitet. Auf Basis dieser Arbeitshypothesen haben wir für die fachliche und technische Umsetzung für die Bereiche Investment und Lending analysiert, welche Produkte, Prozesse und Systeme betroffen sind. Die Analyseergebnisse nutze ich, um daraus Arbeitspakete zu schnüren und Budgetschätzungen zu erstellen und anzupassen. Wir bündelten die Erkenntnisse in fünf Clustern für Geschäftsmodell, Registrierung sowie Aus- und Weiterbildung, Beratungsprozesse, Produkte und Vergütung. Zusätzlich teilten wir die Handlungsfelder in solche mit IT-Auswirkung und solche ohne ITAuswirkung ein. Die Arbeitsergebnisse ließ ich laufend mit dem Gesamtprogramm und der Rechtsabteilung diskutieren, um stets auf abgestimmten Hypothesen aufsetzen zu können. Aus unseren Arbeiten resultierten erhebliche neue fachliche Anforderungen, die sich in prozessualen und inhaltlichen Auswirkungen auf Seiten der IT-Systeme niederschlagen würden. Diese Anforderungen waren unter anderem neue Informationspflichten, Offenlegung von Art und Quelle der Vergütung, Ausweitung der Beratungs- und Informationspflichten – speziell für den Vertrieb von Versicherungsanlageprodukten. Das deutsche Gesetz brachte auch Anforderungen, die in der EU-Richtlinie IDD nicht angelegt sind, mit sich. Für Restschuldversicherungen wurden zusätzliche Transparenzvorschriften und Maßnahmen eingeführt, die den Vertrieb verbraucherfreundlicher gestalten sollten. Damit sollte sichergestellt sein, dass bei Beratung und Vermittlung auch künftig Kundenbedürfnisse und Produktqualität im Mittelpunkt stehen und die Versicherungen zu den Wünschen und Bedürfnissen der Kunden passen, die sie abschließen. Den durch die Digitalisierung veränderten Kundenerwartungen – insbesondere an den Online-Vertrieb – wurde das Gesetz nur teilweise gerecht. Es führte eine Beratungspflicht für Versicherer im Fernabsatz ein. Diese Anforderung stellte uns gerade für die Onlinetochter der Bank vor große Herausforderungen, da die Kunden die Antragsstrecke beratungsfrei selbst durchliefen. Immerhin können Kunden im Fernabsatz ohne Medienbruch auf die Beratung verzichten – beispielsweise per E-Mail oder Online-Formular. Das Design dieses Prozesses und insbesondere die Abstimmung der finalen Ausprägung mit der Rechtsabteilung waren für unser Programm sehr aufwändig. Die Abstimmung mit Vertriebspartnern der Bank, wie Finanzvertriebe und Vergleichsportale, war ebenfalls ein großes Arbeitspaket in meinem Programm. Die Schwierigkeit lag insbesondere darin, dass sich die spezialisierten Einheiten noch nicht mit der Versicherungsvertriebsrichtlinie auseinander gesetzt hatten. Dies war der Fall, da diese Vertriebspartner regelmäßig kürzere Umsetzungsund Releasezyklen haben als eine große Bank. Daher ließ ich unsere Annahmen mit der Rechtsabteilung abstimmen und über das jeweilige Kooperationspartnermanagement mit den Vertriebspartnern kommunizieren. In den Fachkonzeptionen ließ ich zusätzlich Alternativlösungen beschreiben für den Fall, dass sich die Vertriebspartner im Zuge ihrer IDDProjekte für eine andere als die abgesprochene Vorgehensweise entscheiden müssten. Ein weiterer großer Punkt der IDD war das Thema Qualifizierung. Jeder Vertriebsmitarbeiter muss eine ausreichende Qualifizierung nachweisen und sich regelmäßig weiterbilden. Dies müssen die Unternehmen sicherstellen. Mitarbeiter, die die Basisqualifizierung oder Weiterbildung nicht nachweisen können, dürfen keine Versicherungsprodukte mehr verkaufen. Dies hatte unmittelbare Auswirkungen auf die Prozesse und Systeme der Bank. Ich ließ ausarbeiten, wie sich diese Anforderungen organisatorisch und technisch abbilden ließen und die Lösungen in den Fachkonzepten beschreiben. Für die Mitarbeiter der Bank ließ ich dieses Themengebiet intern abdecken und alle Erfordernisse sicherstellen. Für die Mitarbeiter externer Vertriebseinheiten war das Thema sehr komplex. Ich stelle sicher, dass sich die Fachseite gemeinsam mit dem Kooperationspartnermanagement und der Rechtsabteilung abstimmten, einen Lösungsansatz ausarbeiteten und mit den Vertriebspartnern abstimmten. Ein weiterer großer Arbeitsblock, den ich im Programm abarbeiten ließ, war die Kooperation mit dem Produktpartner. Die Bank selbst ist nicht Produktgeber für die Versicherungsprodukte. Die Versicherungen werden von einem Produktgeber, einer großen Versicherung, gestellt. Die Bank selbst handelt als Vertriebspartner und hat selbst wieder Vertriebspartner. Diese Aufstellung verursachte eine hohe Komplexität, da unter anderem die rechtlichen Konstrukte der Vermittlerketten oder Gruppenversicherung zu beachten waren.
Hinzu kam, dass der Produktgeber viele Druckstücke, wie beispielsweise Produktinformationen, bereitstellt. Meine Teams hatten bereits identifiziert, dass eine große Zahl von Druckstücken und Vertragsunterlagen im Zuge der IDDUmsetzung angepasst oder neu erstellt werden mussten. Daher ließ ich einen Jour Fixe mit dem Produktgeber einrichten und das Team für das Outputmanagement der Bank mit einbeziehen. Ferner mussten wir die technische Schnittstelle zur Versicherung beachten. Es existiert eine bidirektionale Schnittstelle zwischen Bank und Versicherung. Diese enthielt alle auch zukünftig notwendigen Daten, so dass ich im Zuge des Programms die Schnittstelle nicht anpassen lassen musste. Trotz aller Unsicherheiten konnte ich mit meinen Teams die Aufgaben der IDDUmsetzung im Rahmen des Programms gut vorantreiben. Alle erforderlichen Fachkonzepte konnten von meinen Teams erstellt werden. Zur finalen Qualitätssicherung hatte ich eine Prüf- und Korrekturschleife nach Inkrafttreten des Gesetzes eingeplant. So war es uns möglich, alle Konzepte nach deren Abnahme zur Umsetzung an die IT und die externen Vendoren zu übergeben und die fachliche Programmphase erfolgreich abzuschließen.
Projektkontext:
Die derzeitige Automatisierungsplattform sollte auf Basis einer Initiative des Group Chief Operating Officers abgeschaltet werden, um die Anzahl der Betriebssysteme zu reduzieren. Der Bereich Lending musste daher seine Applikationen, insbesondere die Kreditanwendungen und Applikationskomponenten, die derzeit in der bestehenden Umgebung betrieben wurden, auf eine neue technische Plattform migrieren. Dazu wurde im Jahr 2016 eine Bestandsaufnahme durchgeführt, um die betroffenen Systeme und Komponenten zu identifizieren, zu katalogisieren und zu priorisieren. Dabei wurden die Anwendungen in 9 Cluster zusammengefasst, um sie gruppenweise umzustellen. Parallel dazu wurde die neue Automatisierungsplattform als Infrastrukturkomponente implementiert und für die Übernahme der Systemcluster vorbereitet. Anfang 2017 war die Plattform vollständig betriebsbereit und die Migration konnte beginnen.
Projektaufgabe:
Mein Team und ich übernahmen die Umstellung eines der neun Cluster für das System einer der beiden großen Consumer Finance Kreditanwendungen. Dafür ermittelten wir für das Online Kreditsystem an Hand von Dokumentationen, Systembeschreibungen und Handbüchern die dazugehörigen Prozesse, Schnittstellen und verbundene Systeme. Die Ergebnisse konsolidierten wir und nutzten sie zusätzlich zum Erstellen der erforderlichen Projektund Antragsdokumente wie Onboardingformulare oder Servicetickets. Da erfahrungsgemäß der Dokumentationsstand vom tatsächlichen Zustand der Systeme abweicht, ließ ich den Sourcecode, die Jobketten und Logfiles analysieren, um Vollständigkeit und Richtigkeit der dokumentenbasierenden Untersuchung zu überprüfen und zu bestätigen. Dadurch waren wir in der Lage ein aktuelles Bild der von uns umzustellenden Umgebung zu erstellen und die notwendigen Arbeitspakete sowie deren technische und zeitliche Abhängigkeiten zu erkennen und zu planen.
Von unserer Umstellung waren ebenfalls Umsysteme, Datenlieferanten und Datenabnehmer, betroffen. Auf Basis unserer nunmehr aktuellen Systemkenntnis konnte ich auf alle betroffenen Systemverantwortlichen zugehen und unsere Arbeiten abstimmen. So war ich in der Lage einen übergreifenden Projektplan zu erstellen und die Arbeitspakete entsprechend auszurichten. Nachdem mein Team und ich die Vorarbeiten abgeschlossen hatten, begannen wir, die zu migrierenden Prozesse in die entsprechenden Jobketten auf dem Zielsystem zu transformieren. Dabei mussten wir nicht nur die drei Kernprozesse umstellen, sondern auch begleitende Abläufe, wie beispielsweise Housekeeping. Ein Teil der Batchjobs waren bankeigene Entwicklungen, die ich von den internen Entwicklerteams anpassen lassen konnte. Der andere Teil der Automatisierungsskripte war von einem externen Vendor. Da diese Softwarekomponenten unter der Hoheit des Vendors standen, trat ich mit dem Zulieferer in Verbindung und beauftragte die für die Umstellung erforderlichen Anpassungen. Im Zuge unserer Analysen hatten wir einige Punkte identifiziert, die wir verbessern lassen wollten, um das System als Ganzes zu optimieren und zu aktualisieren. Ferner legten wir in der weiteren Abstimmung fest, dass die intern gepflegten Skripte ebenfalls in die Verantwortung des Vendors übergehen sollten. Dazu stimmte ich die kaufmännischen und organisatorischen Rahmenbedingungen ab und veranlasste die Übergabe. Da unser Zielsystem neu implementiert wurde, waren keine Berechtigungen für technische Anwender und personenbezogene User vorhanden. Ich stellte sicher, dass das System im globalen Berechtigungssystem der Bank entsprechend eingebunden wurde, dass die erforderlichen Gruppen und Benutzer samt Berechtigungen eingerichtet und dokumentiert wurden. Zusätzlich ließ ich die erforderlichen Konfigurationen auf dem Golden Host einrichten. Der Golden Host ist ein zentrales Loginsystem, das besonders gesichert ist und den Zugriff auf Zielsysteme kontrolliert. Schlussendlich musste ich sicherstellen lassen, dass die zuständigen Teams des Production Supports Zugang zu allen Systemen, insbesondere auch zur Bedienoberfläche des neuen Automatisierungssystems, eingerichtet bekamen. Nachdem wir alle Berechtigungen sichergestellt hatten und die Skripte auf den Entwicklungssystemen vollständig und fehlerfrei ausführbar waren, bereiteten wir den Systemintegrationstest vor. Dazu ließ ich die Systeme konfigurieren und vorbereiten sowie das Softwaredepolyment einleiten. Dabei musste ich einen weiteren Knackpunkt lösen lassen. Da wir eine Erstinstallation vornahmen, war das zu schnürende Paket zu groß für den Softwareverteilmechanismus. Jedoch gab es genau für solche Fälle einen anderen Prozess, den wir identifizieren und nutzen konnten. Somit konnten wir alle erforderlichen Vorbereitungen erfolgreich abschließen Parallel zum Systemintegrationstest ging ich auf das Testteam zu. Diese Gruppe unterstützt Projekte bei der Durchführung des User Acceptance Tests UAT. Da es sich bei unserer Umstellung um eine rein technische Änderung handelte, konnten wir keine Endanwender aufbieten, die einen fachlich getriebenen Abnahmetest durchführen konnten. Daher nahm ich die Expertise des Testteams für solche Fälle in Anspruch, um anschließend auch die für den Produktivgang erforderliche Produktionsfreigabe erhalten zu können. Ich konnte das Testteam dafür gewinnen, Testfälle für uns durchzuführen, um das UAT-Signoff erhalten zu können. Nachdem wir die organisatorischen Rahmenbedingungen abgeklärt und vereinbart hatten, führte ich zwei Workshops mit meinem Projektteam, den Testern und dem Production Support durch, um zu ermitteln, welche Testfälle für den UAT erforderlich waren und, um diese auszuarbeiten und abzustimmen. Am Ende des Zweiten Workshops hatten wir ein Set von Testfällen für Positiv- und Negativtests erarbeitet. Die Positivtests sollten das korrekte Systemverhalten im Erfolgsfall prüfen und belegen. Die Negativtests sollten sicherstellen, dass sich das System im Fehlerfall, beispielsweise bei einem Abbruch, wie gewünscht verhält. Dazu gehörten unter anderem, dass automatisiert Tickets erstellt und der richtigen Assignmentgruppe zugewiesen werden und, dass das Supportteam die Möglichkeit hatte, abgebrochene Prozesse erneut zu starten. Den UAT Testbeginn plante ich unmittelbar nach Pfingsten. Jedoch führten Krankheiten und Unfälle zum fast vollständigen Ausfall der für die Testdurchführung eingeplanten Personen, so dass wir erst zwei Wochen später mit dem UAT beginnen konnten. Dies hatte auch zur Folge, dass ich den Produktivnahmetermin nach hinten verschieben musste. Ich konnte sicherstellen, dass alle erforderlichen Personen am neu geplanten Zieltermin verfügbar waren. Hinzu kam, dass wir mit unserm Golivetermin unabhängig von anderen Releaseterminen waren und ich daher unkompliziert den zeitlichen Verlauf des Projektes abstimmen und anpassen konnte. Der zweite Anlauf des UAT war ein Jumpstart. Mein Team war in der Lage, gleich am ersten Tag alle Positivtests durchzuführen. Auf unserer Seite liefen alle Jobketten ohne Abbruch und fehlerfrei. Auch die Datenübertragung zum Datawarehouse funktionierte. Lediglich das dort nach der Datenübertragung anzustoßende Postprocessing startete nicht. Ich ließ eine Team übergreifende End-to-End-Analyse durchführen. Dabei identifizierten wir ein interessantes Berechtigungsproblem, das ich beheben ließ. Die daraus gewonnenen Erkenntnisse nutze ich, um das Vorgehen für die Produktivnahme anzupassen. Die Durchführung der Negativtests gestaltete sich dagegen schwieriger. Die Prozesskette arbeitete zuverlässig und brach an der gewünschten Stelle, wie vorgesehen, ab. Der Fehler löste auch plangemäß die gewünschten Notifications und Tickets aus. Jedoch konnten wir, nach Beseitigung des Abbruchpunktes im Ablauf, die Jobs nicht wieder starten. Dazu veranlasste ich die zur Fehlerbehebung notwendige Analyse. Mein Team ermittelte, dass der Fehler durch den Versionsstand der Software bedingt war. Vor Beginn unseres UAT wurde das System auf die neueste Softwareversion umgestellt. Nachdem wir das System auf Basis der Analyseergebnisse parametrisiert hatten, konnten wir die Negativtestfälle ebenfalls ausführen und dabei gezielt abgebrochene Prozesse wieder starten. Das ermöglichte es uns, alle Negativtest erfolgreich abzuschließen. Für unsere Tests hatten wir nur für einzelne Tage die alten Prozesse ausgeplant und durch die neuen Prozesse ersetzt. Nachdem alle Testfälle erfolgreich absolviert waren, ließ ich das UAT System komplett auf den neuen Belieferungsweg umstellen, um auszuschließen, dass die alten Prozesse nachträglich Fehler der neuen Prozesse korrigierten. Diese Umstellung verlief problemlos und belegte, dass die neuen Prozesse optimal die alten Prozesse ersetzen konnten. Da wir die Prozesse verbessert und optimiert hatten sowie vollständig an den Vendor übergeben hatten, ließ ich eine Softwarelieferung vom Zulieferer durchführen, um diese über den geregelten Deploymentprozess auf der UAT Umgebung einzuspielen. Danach veranlasste ich einen Regressionstest, um sicherzustellen, dass nach wie vor alle Prozesse fehlerfrei und voll funktional abliefen. Dies war der Fall und ich konnte von allen erforderlichen Parteien das für die Produktionsfreigabe erforderliche UAT-Signoff erhalten. So konnte mein Team kurz darauf die abschließende Umstellung des Produktivsystems auf die neue Automatisierungsplattform vornehmen und das Projekt erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Onlinekreditsystem im Bereich Lending Consumer Finance. Über dieses System werden bis auf Baufinanzierungen alle Privatkredite abgewickelt, die über eine Onlinestrecke in die Bank prozessiert werden. Angebunden sind somit alle Onlineangebote der Bank, ihrer Töchter sowie Vertriebspartner und Vergleichsportale. Dieses System wird ständig verbessert und erweitert. Die dabei entwickelten Softwarekomponenten werden im Zuge von großen Releases in Produktion gebracht.
Projektaufgabe:
Die Arbeiten am Release waren bei meinem Eintreten bereits in vollem Gange und wurden von einem Projektleiter hervorragend organisiert. Jedoch sollte dieser Projektleiter auf Grund der damaligen Umorganisation absehbar nicht mehr zur Verfügung stehen. Daher sollte ich diese Funktion übernehmen und in einer der Aufgabe angemessenen Übergangsphase von 6 Wochen in das komplexe Umfeld eingewiesen werden, um einen reibungslosen Wechsel zu gewährleisten. Tatsächlich stand dann nicht einmal die halbe Zeit für die Übergabe zur Verfügung, da der bisherige Projektleiter früher ausschied. So übernahm ich die Projektleitung mit dem Eintreffen der ersten Softwareanlieferung der beiden externen Vendoren. Ein Vendor liefert die Komponenten für den Frontendteil der Anwendung, der andere die Bestandteile für das Backendsystem. Die Softwarelieferung galt es nun über die definierten Wege auf den Systemen einzuspielen und testen zu lassen. Ich koordinierte die Qualitätskontrolle der Software, das Deployment über die verschiedenen Stufen der Implementierung sowie die technischen und fachlichen Tests mit allen im Projektprozess involvierten Parteien. Ursprünglich war das Release als eine rein technische Version geplant. Jedoch wurde auf Grund fachlicher Notwendigkeiten zusätzlich die Aufnahme fachlicher Funktionalitäten priorisiert. Daher hatte der vorherige Projektleiter vier, bei Bedarf fünf, Zyklen für Softwareanlieferung, Deployment und Test eingeplant. Schon nach der zweiten Lieferung erkannten wir, dass die Anzahl der Zyklen möglicherweise nicht ausreichen könnte, da eine für die Umsetzung der fachlichen Anforderungen notwendige Anbindung eines externen Webservices eine Vielzahl an Problemen und daraus resultierenden Defects verursachte. Aus diesem Grund trat ich in die enge Abstimmung mit den Vendoren ein, um dieses Thema voranzubringen. Zu diesem Zeitpunkt war es ein Showstopper und für das Release produktivnahmeverhindernd. Ich sicherte die vollständige Unterstützung der Softwarelieferanten und stellte intern sicher, dass zusätzliche Zyklen für Softwareanlieferung, Deployment und Test ermöglicht wurden. Dadurch verdichtete sich mein Projektplan erheblich. Durch die zusätzliche Aufnahme der fachlichen Themen in das Release resultierte ein weiteres Problemfeld. Die Erstellung der für die Kreditabschlüsse erforderlichen Unterlagen, beispielsweise Checklisten, Produktinformationsblätter, Verträge, stellte sich im Test als stark fehlerbehaftet heraus. Vertragsunterlagen, die nicht korrekt sind, sind ebenfalls ein Showstopper und für das Release produktivnahmeverhindernd. Somit hatte ich ein zweites großes Themengebiet, das ich in Ordnung bringen lassen musste, um das Release erfolgreich in Produktion bringen zu können. Zur Lösung dieser Fehlerpunkte führte ich Workshops mit dem Fachbereich, den externen Vendoren und dem bankinternen Team für das Outputmanagementsystem durch. Wir ermittelten in Analysen die Fehlerursachen, konnten die Fehlerbehebung spezifizieren und die Umsetzung bei den externen Vendoren beauftragen. Jedoch griff unser erster Lösungsansatz auf Grund der Komplexität in diesem Umfeld nicht vollumfänglich. Ich musste weitere Iterationen zur Fehlerbehebung moderieren und umsetzten lassen. Zusätzlich stellte ich intern sicher, dass weitere Zyklen für Softwareanlieferung, Deployment und Test ermöglicht wurden. Diese Zyklen brachte ich in Synchronisation mit den durch den anderen Showstopper erforderlich gewordenen Zyklen, um die ohnehin stark belasteten Projektmitarbeiter für beispielsweise Deployment und Test möglichst wirkungsvoll einzusetzen. Dadurch verdichtete sich mein Projektplan zusätzlich. Im Zuge dieses ursprünglich rein technisch geplanten Releases sahen wir vor, einige Technologieupgrades vorzunehmen. Dazu hatten wir unter anderem Upgrades für die Application Server und Oracle Datenbanken geplant. Die Application Server wurden von bankinternen Teams betreut, die Oracle Datenbanken von einem externen Dienstleister. Das Upgradevorgehen war derart in die Liefer- und Testzyklen eingeplant, dass wir sicherstellen konnten, dass die technischen Infrastrukturveränderungen keinen Einfluss auf die technische Funktion und die fachliche Funktionalität des Systems haben. So führten wir die Technologieupgrades im Umfeld des ersten Softwarelieferungszyklus durch. Als erstes System stellten wir die Integrationsumgebung um und testeten ausführlich. Die Tests attestierten, dass alles in bester Ordnung war und wir promoteten die Upgrades auf die UAT-Umgebung. Auch hier ergaben die Tests keine Auffälligkeiten. So konnten wir sicherstellen, dass die technischen Infrastrukturveränderungen keinen Einfluss auf die technische Funktion und die fachliche Funktionalität des Systems haben. Die Umstellung der Produktionssysteme plante ich mit dem GoLive des Releases vornehmen zu lassen. Jedoch führte die Bank eine Reduzierung des Tagessatzes für die meisten externen Mitarbeiter im Zuge von Einsparmaßnahmen durch. Dies führte dazu, dass externe Mitarbeiter die Bank verließen, unter anderem auch mein Projektmitarbeiter, der die Schnittstelle zum externen Dienstleister bezüglich des Oracleupgrades war. Ein Ersatz für diesen Mitarbeiter oder einen Stellvertreter gab es nicht. Damit war ein GoLive, wie geplant, Anfang April nicht mehr möglich. Ich setzte alle Hebel in Bewegung, um einen Oracleupgrade durchführen lassen zu können, leider ohne Erfolg. Damit ergaben sich genau zwei Alternativen. Zum einen konnten wir mit dem GoLive eine unbestimmte Zeit warten, bis das Oracleupgrade von einem neu zu rekrutierenden Mitarbeiter durchgeführt werden konnte. Oder, wir führten den GoLive ohne das Datenbankupgrade durch. Ich veranlasste eine Unbedenklichkeitsprüfung hinsichtlich der Option des GoLives ohne Datenbankupgrade bei den Datenbankspezialisten und den Vendoren. Nach Erhalt aller Unbedenklichkeitsbescheinigungen, entschlossen wir uns, den GoLive entsprechend durchzuführen und ich plante die Produktivnahme in Abstimmung mit allen Stakeholdern auf Anfang Mai um. Inzwischen ließ ich mit Hochdruck weitertesten und Fehler beheben, denn bis Anfang Mai war nur noch eine kurze Zeitspanne. Nach dem achten Softwarelieferungszyklus konnten alle Retests erfolgreich durchgeführt und alle verbleibenden Defects geschlossen werden. Auch den erforderlichen Last- und Performancetest konnte ich mit einigen Iterationen ebenfalls erfolgreich durchführen lassen. Mein Team hatte gemeinsam mit den externen Vendoren das unmöglich erscheinende möglich gemacht. Chapeau! Das für die Produktivnahme erforderliche UAT-Signoff erhielt ich für alle 41 Releasescopeitems ohne Einschränkungen im Rahmen einer Telefonkonferenz mit schriftlicher Emailbestätigung am Nachmittag vor dem für unser Projekt letztmöglichen Termin des Change- und Releaseboards. Das UAT-Signoff ist Voraussetzung für die Teilnahme am Change- und Releaseboard, die Freigabe des Change- und Releaseboards ist Voraussetzung für den GoLive. Somit erhielten wir alle erforderlichen technischen und formalen Freigaben punktgenau zu unserem GoLive Termin. Inzwischen hatte ich alle Vorbereitungen für das Deployment und den GoLive von den Exekutoren und dem Application Owner detailliert planen und abstimmen lassen. Zusätzlich hatte ich die Vendoren für Rufbereitschaft am Releasewochenende beauftragt und sichergestellt, dass alle notwendigen Parteien informiert und involviert sind. Anfang Mai führte mein Team die Produktivnahme erfolgreich durch. Alle Anwendungskomponenten wurden wie geplant vollständig installiert und in Betrieb genommen. Die Technology Upgrades von Weblogic, Java und Tomcat wurden deployed. Die Businessverifikation wurde ohne Auffälligkeiten erfolgreich durchgeführt. Lediglich einige kleine technische Fehler ohne Business Impact hinsichtlich Systemmonitoring und Überwachung waren am Releasewochenende direkt nicht zu beheben. Diese Restarbeiten ließ ich im Zuge einer Nachbetreuung in der Folgewoche durchführen. So konnte ich das Projekt Produktionsrelease des Onlinekreditsystems Consumer Finance exklusiv Datenbankupgrade Mitte Mai erfolgreich abschließen. Nachrichtlich: Ende Mai stand ein neuer Mitarbeiter für das Oracleupgrade zur Verfügung und ich konnte das Upgrade auf Mitte Juli planen.
Projektkontext:
Die Abteilung des Kunden bearbeitet Dienstleistungsaufträge mit Schwerpunkt Sicherheit. Dabei wird fokussiert auf Protection (Schutz, gestützt auf Softwarewerkzeuge), Detection (Erkennung, gestützt auf Methodik) sowie Reaction (Gegenmaßnahmen, gestützt auf Automatisierung). Die Aufgaben sollen konform zum Code of Business Conduct des Kunden gelöst werden. Je nach Aufgabe und Erfahrungshintergrund hat jeder Mitarbeiter eine individuelle Vorstellung der zur Aufgabenerledigung geltenden Vorgehensrichtlinien.
Projektaufgabe:
Ziel waren die Strukturierung des Ansatzes sowie Erarbeitung eines Grobkonzeptes für die Aufgabenerledigung der Mitarbeiter bei der Dienstleistungserbringung gegenüber den internen Kunden, den anderen Abteilungen, mit Schwerpunkt auf Beratung. Der interne Kunde soll eine echte Unterstützung ohne unnötigen Mehraufwand und eine strukturierte, nachvollziehbare Vorgehensweise empfinden. Dabei soll das Unternehmen einen chronologisch nachvollziehbaren Mehrwert erhalten, die Beratungsergebnisse digitalisiert erarbeitet und der Fortschritt dargestellt werden. Der Ansatz sollte sich am Vorgehen des Design Thinking, angepasst als Security Thinking, ableiten. Insbesondere sollte dabei geklärt werden, welche Fragen und Rahmenbedingungen sich daraus ableiten. Um dieses Ziel zu erreichen, bereitete ich einen Workshop zum Vorstellen des Design Thinking Prozesses vor. Dabei erarbeite ich, dass Design Thinking auf interdisziplinäre Teams, Visualisierung und klar umrissene Schritte zur Ideenfindung setzt. Im Design Thinking Prozess werden Probleme gelöst und durch kreative Techniken zielgerichtet Innovationen entwickelt, bei denen betriebswirtschaftliche Faktoren wie unterschiedliche Stakeholder oder Umsetzungsfähigkeit in den Problemlösungsprozess einbezogen werden. Die Methode des „Design Thinking“ stellt einen exzellenten Ansatz dar, sowohl Produkte als auch Services zu entwickeln, die am Menschen und dessen Bedürfnissen orientiert sind. Im Workshop und in Gesprächen mit den Mitarbeitern der Abteilung diskutieren wir den derzeitigen Beratungsprozess und spielgelten ihn als Security Thinking Prozess, um Ansatzpunkte abzuleiten und Handlungsfelder auszuarbeiten. Ergebnisse waren, dass wir erkannten, dass das Wertvolle und die Herausforderung ein Team aus verschiedenen Disziplinen, Abteilungen, Hierarchieebenen in einer absoluten Ergebnisoffenheit sind. Daraus leiteten wir unter anderem ab, dass eine stärkere Einbindung der internen Kunden in den Prozess ergebnisentscheidend ist. Hierbei steigern sich Wirkung und Effizienz durch den Einsatz der Iteration. Dabei kann aber nicht sichergestellt werden, dass jeder Beteiligte durchgängig den Prozess begleitet. Daraus entsteht beispielsweise auch ein Wechselspiel aus aktiver Mitarbeit und Interpretation des Dokumentierten und erfordert eine Offenheit gegenüber der Abfolge der Prozessschritte, die auch ineinandergreifen können. Dies führte zur Erkenntnis, dass Sehen den Lösungsfindungsprozess intensiviert und, dass in jeder visuellen Form Wissen und Problemlösungen enthalten sind und deswegen Visualisierungsformen so wertvoll sind. Ergebnis auf Basis dieser Erkenntnis war ein Modell zum Erweitern der bisherigen Dokumentations- und Kommunikationsformen. Die bestehende Dokumentation war bereits sehr ausgereift und sollte erweitert werden, um stärkere Transparenz zu erreichen und jederzeit reportingfähig zu sein. Durch technische Unterstützung sollte der Zusatzaufwand minimiert werden.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war eine Vielzahl umzusetzender kleiner und geringfügiger Anforderungen. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Das Workflowsystem bestand bereits über acht Jahre. In dieser Zeit wurde es stetig durch Projekte, Upgrades oder Systemumstellungen erweitert oder verändert. Im Zuge dieser Aktivitäten können Fehler auftreten, die nicht gravierend sind und daher nicht zeitnah behoben werden können oder müssen. Oder, es können geringe funktionale Fehler vorhanden sein. Oder, es resultiert eine erweiterte Anforderung, die zusätzlich umgesetzt werden soll. Oder, die Anforderung konnte in einem Release nicht mitabgedeckt werden. Diese Erweiterungen oder Anforderungen sollten in Systemanpassungen oder Erweiterungen umgesetzt werden, die die Fähigkeiten des Workflowsystems erhöht und verbessert. Diese Verbesserungen sollten beschrieben, mit dem Fachbereich priorisiert und im Zuge des Majorreleases umgesetzt werden. Ich hatte in diesem Fall 22 Small and Minor Enhancements . (SME). Diese SME bewertete ich in einer ersten Iteration mit dem Leiter der Entwicklung sowie den für diese Themenbereiche zuständigen Lead Business Analysten.Anschließend priorisierte ich diese SME in einem weiteren Schritt mit dem Fachbereichskoordinator. Damit erreichte ich eine Vorsortierung, die es den tatsächlich betroffenen Fachbereichen erleichtert, die endgültige Priorisierung vorzunehmen. Insbesondere stellte ich mit diesem Priorisierungsprozess sicher, dass alle wirklich wichtigen SME im Rahmen des dafür bereitgestellten Budgets umgesetzt werden konnten. Durch die Priorisierung mit dem Fachbereichskoordinator konnten wir die Liste der SME auf 19 Stück reduzieren. Diese SME stimmte ich mit den Fachbereichen ab. Daraus erarbeiteten wir eine abgestimmte Liste von 14 SME, die die wichtigsten Erweiterungen und Fehlerbehebungen abdeckten und im Rahmen des Budgets umgesetzt werden konnten. Diese 14 SME ließ ich spezifizieren, entwickeln und testen. Parallel dazu stimmte ich mit dem Releasemanager die Aufnahme dieser SME in den Releaseprozess ab. Anfang November brachte ich diese 14 SME im Zuge des Majorreleases erfolgreich in Produktion.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt waren die Erkenntnisse, die im Zuge des Projektes 50 „Digitalisierung – Vorstudie für eine Notfallinfrastruktur für das zentrale Workflowsystem der Bank“ gewonnen wurden. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Aus den Erkenntnissen wählten wir die Ansätze aus, die die größte Wirkung versprachen. Durch die Maßnahmen sollten die Geschäftsauswirkungen durch System- oder Komponentenausfälle verringert oder vermieden werden. Ebenfalls sollten die Startzeiten des Workflowsystems verringert und Probleme beim Wiederanlauf vermieden werden. Daraus leiteten wir drei Handlungsfelder ab. Das erste Handlungsfeld konzentrierte sich den Autostart der TibcoKomponenten Business Works (BW), iProcess und Enterprise Message Service (EMS) . Das zweite Handlungsfeld fokussierte auf die Desaster Recovery Fä- higkeiten des Systems. Dazu sollten insbesondere die Wiederanlauffähigkeit von Services optimiert und die Wiederverbindung zu Datenbanken sichergestellt werden. Das dritte Handlungsfeld sollte die Anzahl der CaseStarter und RequestFeeder Instanzen reduzieren, diese umfangreich konfigurierbar und insbesondere sicherer machen. In diesem Zuge sollte auch das Reporting. über Tibco Spotfire an die erweiterten Fähigkeiten der CaseStarter und RequestFeeder angepasst werden. Damit ich sicherstellen konnte, dass sich alle Maßnahmen ergänzen und nicht gegenseitig unmöglich machen, habe ich zusätzlich zu den Jour Fixes der Einzelstränge übergreifende Abstimmungstermine einberufen. Dieser Ansatz hat sich als sehr hilfreich herausgestellt, da der Kreis der Stakeholder komplex war. Zudem benötigten wir für alle Themenbereiche übergreifende Instanzen, wie beispielsweise das Deployment-, Test- oder Releasemanagement , die damit wirksam eingebunden wurden. Mir als Projektleiter erleichterte der integrative Ansatz die Ressourcenplanung und das Budgetmanagement .
Autostart:
Für den Autostartbereich entwickelten wir mehrere Lösungsansätze . Diese stimmten wir mit den Architekten, Application Ownern und Production Support ab . Dazu führte ich mehrere Lösungs- und Abstimmungsworkshops durch. Die Ergebnisse der Arbeitsmeetings flossen direkt in die Lösungsentwicklung ein. Daraus erarbeiteten wir einen mehrstufigen Lösungsansatz. Wir entwickelten ein Autostartframework , das im Zuge eines Systemstarts aktiviert werden sollte. Dieses Framework stellt sicher, dass die TibcoKomponenten Business Works, iProcess und Enterprise Message Service ordnungsgemäß gestartet werden. Dazu sollte das Framework die bereits im Einsatz befindliche Komponente Tibco Hawk , ein Werkzeug zur Überwachung und regelbasierten Steuerung von (Tibco-) Services, ansprechen und nutzen. Ein Teil der dafür erforderlichen Hawkregeln war bereits vorhanden. Einige fehlerhafte Regeln musste ich korrigieren sowie noch nicht vorhandene Regeln entwickeln und testen lassen. Dabei erkannten wir, dass zusätzliche nicht-Tibco Komponenten für einen erfolgreichen Autostart ebenfalls erforderlich sind. Diese Services ließ ich genauso durch Hawkregeln starten, um einen vollständigen Systemstart sicherstellen zu können. Während der Umsetzung der Autostartregeln für BW und EMS erkannten wir, dass wir für iProcess nicht ohne Unterstützung von Tibco auskommen würden. Daher klammerten wir den Autostart von iProcess aus und planten die Umsetzung in einem Folgeprojekt im nächsten Jahr. Das Autostartframework sowie die Autostartregeln für BW und EMS implementierten wir erfolgreich.
Wiederanlauf:
Zur Problemanalyse beim Wiederanlauf von Services ließ ich mehrere Tests durchführen. Schwerpunkt ließ ich dabei auf die Wiederverbindung von Services an Datenbanken legen. Diese Tests sind nicht einfach durchzuführen, da ein zweizügiges System für aussagekräftige Erkenntnisse erforderlich ist. In der Regel verhindern zwei Knoten bereits die meisten Probleme, da erfahrungsgemäß nur ein Knoten von einem Ausfall betroffen ist. Es muss jedoch sichergestellt sein, dass beispielsweise bei Datenbankschwenks die Verbindungen sauber mitgezogen werden oder Komponenten, die nur eine aktive Node erlauben, nicht plötzlich durch zwei aktive Köpfe Fehlerkonstellationen hervorrufen. Vorbereitungen und Entwicklung von Testprogrammen ließ ich auf den einzügigen Entwicklungsmaschinen durchführen. Damit die Tests ausgeführt werden konnten, stimmte ich die Nutzung der zweizügigen Integrationsumgebung mit Test, Entwicklung und Releasemanagement ab. Es gelang mir einen zweiwö- chigen Testzeitraum für die exklusive Nutzung der Integrationsumgebung mit ausreichendem Vorlauf zum Majorrelease auszuhandeln. Da dieser Testzeitraum in der Zukunft lag, ließ ich reguläre und im Rahmen des Releases durchgeführte Desaster Recovery Tests mitnutzen, um bisherige Fehlersituationen zu bestätigen und neue zu ermitteln. Somit konnten wir insbesondere in der Konfiguration von Verbindungsparametern Ansatzpunkte erkennen und mittels Anpassung, beispielsweise der Connection Factories, beheben. Die Wirksamkeit und insbesondere die Unschädlichkeit dieser Maßnahmen konnten wir während der folgenden Tests auf der Integrationsumgebung belegen und sicherstellen. Weitere Fehlersituationen konnten wir nicht feststellen. Dies ließ sich ursächlich auf die in der Zwischenzeit durchgeführten wirksamen Infrastrukturmaßnahmen zurückführen. Die Anpassungen an den Konfigurationen der Verbindungsparameter implementierten wir erfolgreich.
CaseStarter:
4.0 Jeder Eingangskanal des Workflowsystems ist in der Regel über einen CaseStarter und einen RequestFeeder angebunden. Diese Instanzen sind die Schnittstellen zur Außenwelt der Zuliefersysteme. Über diese Eingänge wird das System mit allen Daten und Dokumenten versorgt. Bislang wurde regelmä- ßig jedes Zuliefersystem über eine eigene Instanz angebunden. Damit die Anzahl der CaseStarter und RequestFeeder Instanzen reduziert werden konnte entwickelten wir einen ganz neuen Ansatz und wählten ein agiles, an Scrum angelehntes, Vorgehen mit mehreren Sprints. In Workshops mit Entwicklung, Application Owner, Architektur und Production Support fixierten wir die Anforderungen und Projektziele. Daraus erkannten wir, dass wir umstellen mussten von eingangskanalspezifischen hin zu protokollspezifischen CaseStarter und RequestFeeder Instanzen. Damit konnten wir die Anzahl von 16 auf 5 Einheiten reduzieren. Diese fünf Einheiten für HTTPS, REST, CIFS, sFTP und JMS sollten grundsätzlich im Kern gleich aufgebaut werden. Dabei sollten konfigurierbare Funktionalitäten, wie beispielsweise das An- und Abschalten von Kanälen oder eine Mengenbegrenzung, ebenso implementiert werden wie Sicherheitsprüfungen, etwa Whitelisting oder Token-Prüfung. Die Administration sollte über eine Bedienoberfläche möglich sein, die Konfigurationen sollten in einer unabhängigen Datenbank vorgehalten werden. Auch hier konnte ich Erkenntnisse aus dem Projekt 51 „Digitalisierung – Vorstudie für eine Notfallinfrastruktur für das zentrale Workflowsystem der Bank“ einbringen. Daher ließ ich den Datenstrom der Eingangskanäle duplizieren und eine Sicherheitskopie in einer ebenfalls unabhängigen Datenbank, dem Message Saver, ablegen. Weiterhin nutzen wir die Erfahrung von Releasewochenenden. Zu diesen Terminen wird die reguläre Datenbelieferung abgeschaltet und erst nach erfolgreichem Einsetzen des Releases wieder aktiviert. In der Zwischenzeit müssen jedoch Testfälle prozessiert werden, unabhängig von den gepufferten Eingangsdaten. Dieser Vorgang war jedoch bisher mit viel Aufwand verbunden. Daher optimierten wir den Prozess und implementierten eine Umschaltmöglichkeit, die einen Regelbetrieb und einen Releasemodus anbot. Im Releasemodus können bei abgeschaltetem Eingangskanal dediziert (Test-)Fälle erkannt und gezielt prozessiert werden. Am Ende jedes vierwöchigen Sprints stellten wir die Ergebnisse im großen Stakeholderkreis vor, um Rückmeldungen und Anregungen aufzunehmen und einzubeziehen. Dies führte insbesondere dazu, dass wir die Dokumentenprüfung und den Duplikatecheck deutlich verbessern konnten. Ebenso konnten wir die Priorisierung und Zeitplanung einvernehmlich abstimmen. Daher fokussierten wir uns auf die Umsetzung des CaseStarters HTTPS. Die Entwicklung der Bedienoberfläche, die Erweiterung des Reportings mittels Dashboard und Spotfire sowie die Umsetzung der weiteren protokollspezifischen Eingangskanäle planten wir zum ersten Masterrelease des Jahres 2017 fertigzustellen. Zu diesem Release sollte der erste Eingangskanal ebenfalls auf den neuen CaseStarter 4.0 aufgeschaltet werden und diesen produktiv nutzen. Ende November war die grundlegende Entwicklung abgeschlossen. Wir konnten den HTTPS-Stream testweise vollständig prozessieren. Dabei waren die Komponenten Security Check, Inputchannel Check mit Activity und Threshold, Document Check, Message Saver und Duplicate Check funktional implementiert und konnten Entwicklertestsunterzogen werden. Damit konnte ich die erste Phase des Projekts erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war die Erkenntnis, dass im Zuge des Prozesses durch die Verarbeitung und Konvertierung verschiedener Dateiformate Probleme auftreten. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Projektziel war die Reduzierung und Beseitigung auftretender Fehler auf Grund von verschiedenen Dateiformaten. Dies war insbesondere im Hinblick auf die Digitalisierungsmaßnahmen wichtig, da in diesem Rahmen das papierlose Banking, beispielsweise das maschinelle Erkennen und Auslesen von Dokumenten und Formularen, sowie Robotics im Sinne von Automatisierung, beispielsweise die automatische Übernahme von vorhandenen Daten über technische Schnittstellen inklusive Dunkelverarbeitung von Geschäftsvorfällen, nur bei störungsfreien Prozessen effektiv und wirksam durchgeführt werden können. Zusätzlich mussten wir eine Anzeigeschwäche in der Benutzeroberfläche beseitigen, die durch Probleme in der Darstellung verschiedener Dateiformate auffällig wurde. Dazu planten wir den bisher im Einsatz befindlichen Multiformatviewer durch eine auf ein Dateiformat spezialisierte Anzeigesoftware zu ersetzen.Um diese Aufgaben zu erfüllen, ließ ich von meinen Business Analysten den Prozess analysieren und dokumentieren. Dies insbesondere darauf hin, welche Dateiformate über welche Eingangskanäle zugeliefert und, wie diese im weiteren Prozess verarbeitet werden. Im Zuge dieser Prozess- und Formatanalyse stellten wir fest, dass es durchaus auch Formate gab, die ausschließlich transportiert und nicht angezeigt werden. Diese Formate konnten wir aus der weiterführenden Betrachtung ausschließen. Wichtig dabei war nicht nur die Datenversorgung des Workflowsystems, sondern ebenfalls die Weiterverarbeitungder Daten in Folgesystemen. Besondere Anforderungen identifizierten wir im Bereich Kundenkommunikation und Archivierung. Die Druckstrecke der Bank benötigt ein definiertes Format, damit die Schriftstü- cke optisch einwandfrei im Massendruck verarbeitet werden können. Bei Formatfehlern sieht im besten Fall das Druckstück unschön aus, im schlechtesten Fall bricht die Verarbeitung der Druckstraße ab und hat somit negative Auswirkungen auf andere Druckprozesse. Ebenso stellt das Archivsystem der Bank hohe Anforderungen. Das Zielformat muss beispielsweise archivierungsfähig sein, das heißt, beispielsweise in 30 Jahren anzeig- und verarbeitbar sein. Ebenso muss das Format sicher gegen Manipulationen sein. Die Anforderungen aus Druck- und Archivbereich waren bei der aktuellen Lösung umgesetzt und durften nicht außer Kraft gesetzt werden. Parallel ließ ich die Funktionalitäten des sich im Einsatz befindlichen Viewers analysieren. Es musste sichergestellt werden, dass die einzusetzende Software ebenfalls alle Funktionen bietet, um die bestehenden Arbeitsprozesse vollumfänglich zu unterstützen. Wir identifizierten 79 Funktionen, die nach der Umstellung wieder zur Verfügung stehen mussten. Bei näherer Analyse stellte sich heraus, dass der Viewer selbst davon nur 64 Stück zur Verfügung stellte; die anderen Funktionalitäten wurden vom System zusätzlich bereitgestellt und wä- ren vom Tausch der Anzeigekomponente nicht betroffen. Eine Vorgabe war, dass die neue Anzeigekomponente aus dem Pool der Standardsoftware der Bank stammen musste. Im Rahmen dieser Vorgabe wählten wir eine Software aus. Die Funktionsanalyse ergab, dass damit jedoch nur 52 Funktionen abgedeckt werden konnten. Durch Erweiterung des Frameworks des Workflowsystems konnten wir bis auf 3 Funktionen alle fehlenden Funktionalitäten durch Eigenentwicklungen ergänzen. Meist ergeben sich in solchen Analysephasen weitere Anforderungen das Fachbereichs. Diese sind jedoch in der Regel nicht im Projektumfangvorgesehen. Da ich aber zusätzliche Funktionen im Framework entwickeln lassen musste und 3 bisher bestehende Funktionen nicht abdecken konnte, traf ich mit dem Fachbereich eine Absprache. Wir einigten uns darauf die 3 fehlenden Funktionen durch die zusätzliche Entwicklung von 7 neuen Funktionalitäten überzukompensieren. Neben der reinen funktionalen Abdeckung sollte insbesondere sichergestellt werden, dass die Anzeigequalität deutlich verbessert wird, um auch die Anzeigeschwäche endgültig beheben zu können. Dazu entwickelten wir verschiedene Lösungsansätze. Ein Modell war, die Umstellung aller Eingangskanäle auf das für die Anzeigekomponente erforderliche Zielformat zu betreiben. Damit könnten Prozesse und Anzeige auf nur ein Datenformat optimiert werden. Der Ansatz wurde nicht weiterverfolgt, da eine Vielzahl von Eingangskanälen in zu kurzer Zeit umgestellt werden müssten. Ebenso müsste die Verarbeitung in den Folgesystemen, wie Druckstraße oder Archivsystem, sichergestellt werden. Dieser Ansatz würde den zeitlichen und monetären Rahmen des Projektes sprengen, wurde aber für jede Anpassung oder Neuaufschaltung eines Eingangskanals als strategische Lösung beschlossen. Daher ließ ich ein alternatives Vorgehen ausarbeiten. Rahmenbedingung dabei war, dass die bisherigen Formate beibehalten werden sollten. Ausschließlich für die Anzeige sollten die Formate, falls erforderlich, in das Zielformat der Anzeigekomponente konvertiert werden. Damit reduzierte sich der Scope des Projektes deutlich. Zu diesem Lösungsansatz entwickelten wir grundsätzlich zwei Alternativen. Die Konvertierung zur Ansicht kann zentral oder dezentral erfolgen wenn ein Dokument angezeigt werden muss. Das Workflowsystem wird über die Eingangskanäle versorgt und schreibt alle Dokumente direkt ins Archivsystem. Zusätzlich versorgt es einen Dokumentenspeicher, um die Dokumentenversorgung bei Ausfall oder Performanceengpässen des Archivsystems sicherzustellen. Ein Dokument liegt dann sowohl im Archiv als auch im Dokumentenspeicher vor und muss je nach Prozesskette aus unterschiedlichen Quellen bereitgestellt und angezeigt werden. Damit eine einheitlich gute Anzeigequalität sichergestellt werden konnte, entschlossen wir uns, in einem ersten Schritt einen einheitlichen Konverter dezentral einzusetzen. In einer folgenden Ausbaustufe sollte dieser Konverter zentral als redundanter Service angeboten werden. Somit implementierten wir an zwei verschiedenen Stellen (sowohl für Archivsystem als auch Dokumentenspeicher) einen einzigen Softwarestand des Anzeigekonverters unter Nutzung des Singlesourceansatzes. Da die Bank virtuelle Arbeitsplatzrechner einsetzt, ist es nicht möglich, vorab Last- und Performancetests der Benutzeroberfläche durchzuführen. Um eine erste Einschätzung zu erhalten, haben wir den Konverter getestet und dabei Antwortzeiten mit und ohne Konvertierung verglichen. Die Konvertierung verlängert die Dokumentenauslieferung kaum, da wir diese als Streaming konzipiert und implementiert haben. Somit konnten wir sicher sein, dass die Backendkomponente performant genug war, konnten aber nicht abschließend einschätzen, wie der Gesamtprozess sich verhalten würde. Daher beschlossen wir im Rahmen der Einführungsplanung eine Pilotierung durchzuführen. Damit wollten wir in einer zeitlich begrenzten Phase eine limitierte Anzahl von Benutzern mit dem neuen Systemumfeld arbeiten lassen, um Antwortverhalten und Systemstabilität zu überprüfen. Aus den Ergebnissen wollten wir extrapolieren, wie sich das System nach einer Vollumstellung verhalten würde. Meine Businessanalysten erstellten gemeinsam mit den Fachbereichen ein Einführungskonzept sowie Schulungsunterlagen. Dabei setzten wir auf den Multiplikatorenansatz, denn es waren mehrere tausend Anwender zu schulen. Am ersten Novemberwochenende gingen wir erfolgreich in Produktion und starteten die Pilotphase. Mitte November beendeten wir die Pilotphase erfolgreich. Die Performanz und Stabilität des Systems sind unverändert auf hohem Niveau. Die deutlich verbesserte Anzeigequalität machte sich positiv bemerkbar. Einige kleine Fehler waren noch zu beheben; unter anderem musste auch eine Veränderung am virtuellen Arbeitsplatz vorgenommen werden. Ich ließ die Fehlerkorrekturen erstellen, testen und abnehmen. Da wir gemeinsam mit der Umstellung des virtuellen Arbeitsplatzes die Vollaufschaltung vornehmen mussten, beschlossen wir, mit dem nächsten Release des virtuellen Arbeitsplatzes zum Februar produktiv zu gehen. Damit konnten wir die erste Phase des Projektes erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war eine Datenbelieferungsstrecke, die nicht mehr den erhöhten IT Security Richtlinien entsprach. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe: Das Workflowsystem wird über eine Vielzahl von Eingangskanälen mit Daten und Informationen versorgt. Auch der papiergebundene Eingangskanal ist an das Workflowsystem angebunden. Über diesem Eingangskanal wird das Workflowsystem unter anderem mit sämtlicher Briefpost der Kunden an die Bank versorgt. Diese Schreiben werden von einem externen Scandienstleister digitalisiert und über eine Datenbelieferungsstrecke dem Workflowsystem zur Verfügung gestellt. Diese Datenbelieferungsstrecke besteht bereits länger. In dieser Zeit wurden IT Security Richtlinien angepasst und die Sicherheitsstandards erhöht. Aus diesem Grund entsprach die Datenversorgung nicht mehr den erhöhten IT Security Anforderungen. Damit die Richtlinien wieder eingehalten werden, musste die technische Ausgestaltung der Datenbelieferungsstrecke angepasst werden. Zusammen mit meinem Team musste ich sicherstellen, dass alle notwendigen Parteien einbezogen wurden. Dies war insbesondere deshalb wichtig, da die Datenbelieferung von einem externen Dienstleister durchgeführt wurde. Daher war eine sichere Datenverbindung zu schaffen, die ein Ende innerhalb des sicheren Banknetzes besitzt, das potentiell unsichere Internet quert und im gesicherten Netz des Dienstleisters endet. Ich ließ alle Rahmenbedingungen ermitteln und von den Spezialisten fünf verschiedene Anbindungsalternativen erarbeiten. Schwerpunkt war, eine sichere Verbindung zu entwerfen, die im bestehenden Systemumfeld wirtschaftlich zu implementieren war. Dabei mussten wir jedoch großes Augenmerk auf die Performance richten, da der Papierkanal sehr großvolumig ist. Wir erarbeiteten für alle fünf Alternativen die technischen und organisatorischen Rahmenbedingungen sowie die dazugehörigen Prozesse. Ebenso ließ ich Performance- und Sicherheitseinschätzungen vornehmen und auch die zugehörigen Projektkosten abschätzen und dokumentieren. Die erstellten Unterlagen übergaben wir dem verantwortlichen Fachbereich im Rahmen einer Lösungspräsentation zur Entscheidung und Beauftragung der Umsetzung.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war die Erkenntnis, dass in der Vergangenheit zwischen den technisch vereinbarten und den fachlich zugesagten Serviceleveln Abweichungen bestanden. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Die Abweichung traf insbesondere auf kritische Geschäftsprozesse zu, die regelmäßig in kürzerer Zeit abzuwickeln sind als die zugesicherte Wiederherstellungszeit des Systems. Im Falle einer Systemstö- rung oder bei Performanceengpässen wäre somit die Einhaltung der fachlichen Service Level Agreements gefährdet. Da das System grundsätzlich sehr stabil und performant arbeitete sowie in näherer Vergangenheit wirksame Infrastrukturmaßnahmen durchgeführt wurden, bestand kein akuter Handlungsbedarf. Daher konzentrierten wir uns auf strategische Maßnahmen. Mit der Durchführung des Projektes schafften wir die Voraussetzung für organisatorische und prozessuale Verbesserungen und definierten damit die notwendigen Leitplanken und Anforderungen für technische und organisatorische Verbesserungen. Mein Team und ich haben wirksame Alternativprozesse für Systemausfälle definiert, adäquate Ausfallkritikalität und Wiederherstellungszeit abgebildet und damit die Notfallplanung signifikant verbessert. Als ersten Schritt haben wir gemeinsam mit den Fachbereichen eine Businessprozessanalyse durchgeführt und dabei die kritischen Geschäftsprozesse für die einzelnen Geschäftseinheiten identifiziert sowie daraus die Zeitschwelle für kritische Vorgänge abgeleitet. Auf dieser Basis haben wir uns auf Prozesscluster konzentriert, die ein gegenüber den Auftraggebern vereinbartes Servicelevel von kleiner als der definierten Zeitschwelle besitzen. Wir haben dabei die Annahme getroffen, dass die bestehenden Notfallmaßnahmen ausreichend sind, um die Ausfallzeit für die Prozesscluster oberhalb dieser Zeitschwelle hinreichend zu mitigieren. In der Businessprozessanalyse erarbeiteten wir Einzelheiten zu den betroffenen Geschäftseinheiten und Benutzergruppen, den ausgeführten Funktionen und Prozessen, den kritischen Geschäftszeiten sowie internen und externen Abhängigkeiten der Geschäftseinheiten unter Berücksichtigung von weiteren Bereichen der Bank und externen Dienstleistern, von technischen Applikationen und sonstigen technischen Ressourcen. Das Workflowsystem ist über eine Vielzahl von Eingangskanälen angebunden. Über diese Eingangskanäle werden dem System die Vorgänge zugeführt. Dabei kann es sich um kritische oder unkritische Vorgänge handeln. Es existieren Eingangskanäle, die nur kritische, nur unkritische oder kritische sowie unkritische Vorgänge enthalten. Eingangskanäle mit ausschließlich unkritischen Vorgängen wurden von der Analyse ausgenommen. So ermittelten mein Team und ich 23 Prozesscluster mit 29 Businessprozessvarianten, deren Abarbeitung über das Workflowsystem initiiert und begleitet wird. Für jede Businessprozessvariante identifizierten wir Infrastrukturtypen, Hardware und Software, die für die Vorgangsversorgung im Rahmen der Produktionsvorbereitung und des Prozessings über das Workflowsystem erforderlich sind. Wir erkannten 12 Abhängigkeiten zu Infrastrukturtypen. Zusätzlich haben wir weitere sechs IT-Komponenten identifiziert, die zwar für den Ablauf des Bearbeitungsprozesses benötigt werden, aber technisch nicht zum Workflowsystem gehören. Daraus haben wir insgesamt 18 Abhängigkeiten bei den Infrastrukturtypen sichtbar gemacht und davon die Anforderung an die Verfügbarkeit dieser Infrastrukturtypen abgeleitet. In der darauf durchgeführten Geschäftsauswirkungsanalyse haben wir erarbeitet, welche direkten finanziellen und operativen Auswirkungen eine Unterbrechung des Geschäftsbetriebs auf die Geschäftseinheiten hat. Anschließend haben wir Strategien, Ressourcen und Kapazitäten aufgezeigt, die nach einer Geschäftsunterbrechung zur Wiederherstellung des Geschäftsbetriebs auf akzeptablem Niveau benötigt werden. Als zugehörigen Bestandteil der Wiederherstellungsstrategien definierten wir ebenso bewusste Entscheidungen des Managements zur Tolerierung von Risiken und die Akzeptanz möglicher Auswirkungen. Um die Auswirkungen eines Ausfalls der Infrastrukturtypen oder einer fehlenden Verfügbarkeit der Dienstleister je Businessprozessvariante umfänglich zu betrachten und somit die Analyse der Risikosituation abzuschließen, haben wir weiterführende Informationen herangezogen. Dabei haben wir vorrangig Volumen und Abarbeitungsgeschwindigkeit betrachtet, um die Abarbeitungszeiten für die während einer Krise nicht bearbeiteten Vorgänge zu bestimmen. Mit der Geschäftsauswirkungsanalyse erarbeiteten wir eine Einschätzung potentieller direkter finanzieller und operativer Auswirkungen bei einer Unterbrechung des Geschäftsbetriebs der gesamten Geschäftseinheit. Zusätzlich haben wir eine Einschätzung zum finanziellen und reputativen Schaden bei Nichteinhaltung der SLA pro Businessprozessvariante durch die Geschäftseinheiten eingeholt. Den aufsichtsrechtlichen Schaden haben wir nach Abstimmung pauschal für jeden Prozess als gering eingestuft. Anschließend haben wir die Eintrittswahrscheinlichkeit ermittelt. Als Wesentliche Parameter bei der Berechnung der Eintrittswahrscheinlichkeit haben wir die Anzahl der abhängigen Infrastrukturtypen angesehen. Darüber hinaus haben wir das Delta zwischen der durchschnittlichen Wiederanlaufzeit der Infrastrukturtypen gegenüber dem ursprünglichen Servicelevel, welcher dem Auftraggeber gegenüber zugesagt wurde, ins Verhältnis gesetzt. Die Businessprozessvarianten haben wir anschließend gemäß dem Rahmenwerk zur Bewertung von Risiken der Bank strukturiert. Dabei ermittelten mein Team und ich sechs kritische und vier signifikante Prozesscluster, die die Basis aller weiteren Aktivitäten bildeten. Die restlichen Prozesscluster haben wir von der Betrachtung ausgeschlossen. Auf dieser Basis haben wir geeignete Wiederherstellungsstrategien abgeleitet. Dies unter der Prämisse, dass die aktuell vereinbarten Servicelevel als Konstante vorgegeben sind. Daraus haben wir Wiederherstellungsmaßnahmen (BCM-Maßnahmen) abgeleitet, die beschreiben, wie die Geschäftseinheiten ihre kritischen Prozesse während einer Geschäftsunterbrechung fortsetzen und oder wiederherstellen. Wir haben diese BCM-Maßnahmen in vier organisatorische und zwei funktionale Maßnahmen untergliedert. Zur weiteren Projektarbeit haben wir das Gesamtteam auf organisatorische und funktionale Maßnahmen aufgeteilt. Mein Team verantwortete die funktionalen Maßnahmen. Als konkrete BCM-Maßnahme haben wir vereinbart, dass Notfallinfrastrukturen definiert und aufgebaut werden, die beim Ausfall von kritischen Komponenten die Abarbeitung der kritischen Prozesscluster ermöglichten. Zusätzlich sollten zwei weitere organisatorische Maßnahmen technisch unterstützt werden. Dabei haben wir insbesondere auf die identifizierten kritischen Komponenten abgestellt. Diese Maßnahme haben wir für alle Prozesscluster vereinbart, die wir als signifikante und kritische Risiken eingestuft haben. Damit wir sicherstellen konnten, alle Anforderungen zu erfassen, haben wir die Prozesscluster in Use Cases unterteilt und beschrieben. Daraus haben mein Team und ich gemeinsam mit den Fachbereichen die Anforderungen ermittelt und dargestellt. Dazu haben wir mehrere Workshops mit allen Stakeholdern durchgeführt. Auf Basis der abgestimmten Requirements habe ich IT-interne Lösungsworkshops durchgeführt. Dabei haben wir zuerst Architekturrichtlinien erarbeitet. Beispielsweise sollte die Notfalllösung systemisch unabhängig vom bestehenden Workflowsystem sein und daher keine seiner Komponenten, beispielsweise die Tibco Workflowengine, verwenden und damit auch keine zusätzliche Komplexität im Workflowsystem erzeugen oder die Stabilität sowie Performance beeinträchtigen. Daraus leiteten wir ab, dass es ein Auftragsduplikat geben musste und das Versenden des Auftragsduplikats direkt von der Quelle übernommen muss. Eine weitere Vorgabe war, dass nur Standardinfrastruktur der Bank genutzt werden sollte. Zusätzlich sollten wir ausarbeiten, welche Arbeitspakete und Kosten entstehen würden, wenn das vorhandene Workflowsystem dupliziert und als Notfallinfrastruktur implementiert werden würde. Auf dieser Basis erarbeiteten mein Team und ich eine Notfallinfrastruktur aus funktionalen Blöcken, wie beispielsweise einem Duplikator für Eingangskanäle, die nur ein Ziel beliefern können (7 verschiedene Ansätze), einem Identifikator zum Erkennen von beispielsweise Kritikalität oder Auftragstyp (2 verschiedene Ansätze), einer Komponente zur Vorgangsbearbeitung (3 verschiedene Ansätze) oder einem Modul zum Krisenabschluss (2 verschiedene Ansätze). Daraus leiteten wir einen technischen Lösungsansatz auf Basis von Bankstandardinfrastruktur ab und erarbeiteten detailliert die Anbindung und Datenflüsse der Notfallinfrastruktur. Anschließend führten wir eine Prüfung durch, ob die Annahmen, die im Lösungsvorschlag getroffen wurden, mit der Standardinfrastruktur erfüllt werden können. Im Zuge der Prüfung stellten wir fest, dass unsere Lösungsansätze bei genauer Analyse mit Standardinfrastruktur nicht umzusetzen waren. Wir mussten beim Systemdesign drei Ansätze für die Notfallinfrastruktur sowie für den Datentransport und für die Logik fünf Ansätze auf Basis von Standardinfrastruktur erarbeiten. Die Gründe dafür, dass die jeweils betrachtete Standardinfrastruktur schlussendlich doch nicht in Frage kam waren, dass wir sehr viele Daten, Daten mit großem Volumen und Daten in hoher Frequenz zu verarbeiten hatten. Da mit dem erforderlichen Mengengerüst und zeitlichen Profil die Nutzung von Standardinfrastruktur nicht möglich war, stimmte ich mit Architektur und Management einen Lösungsansatz auf Basis einer Eigenentwicklung ab. Diesen Lösungsansatz verfeinerten wir und erstellten eine detaillierte Anforderungsspezifikation sowie eine Systemarchitektur. Parallel zur technischen Lösungsfindung erstellte ich zu jedem Lösungsansatz einen Zeitplan für die Durchführung sowie eine umfangreiche Kostenkalkulation. So erstellte ich eine Kalkulation für die Dopplung des vorhandenen Workflowsystems sowie acht Kalkulationen unterschiedlicher Granularität für die jeweiligen Lösungsalternativen. Zu jeder Lösungsalternative ermittelten wir die Anforderungsabdeckung, um sicherzustellen, alle notwendigen Requirements der Fachbereiche abzudecken. Lösungsansätze, Zeitpläne, Kostenkalkulationen und Anforderungsabdeckungen stellten wir in Workshops dem Fachbereich und beim Management vor, um die erforderlichen Gremienabstimmungen und Entscheidungen durchzuführen und zu erhalten. Im Zuge der Lösungsabstimmung haben wir erkannt, dass der vorgeschlagene Weg gangbar, aber ein langer ist. Deshalb haben wir uns auf eine Ziellösung verständigt und für diesen Ansatz einen Phasenplan erarbeitet. Wir haben ein Vorgehensmodell entwickelt, um zuerst die Basisnotfallinfrastruktur aufzubauen und nur an einen der 23 Eingangskanäle anzuschließen. Im nächsten Schritt wollten wir zwei weitere wichtige Eingangskanäle aufschalten, Die restlichen Eingangskanäle planten wir sukzessive anzuschließen. Nachdem wir das Vorgehensmodell und den Leistungsumfang definiert hatten, waren die Fachbereiche in der Lage, die mit der Notfallinfrastruktur zu motivierenden Risiken zu ermitteln. Wir haben erkannt, dass die Risiken der zehn Prozesscluster mit der Ziellösung aus Sicht des Fachbereichs noch nicht in gewünschtem Umfang mitigiert werden können. Daher haben wir weitere Ausbaustufen konzipiert und für diese ebenfalls Kostenindikationen und Umsetzungspläne erarbeitet. Wir entwickelten vier weitere Leistungspakete und integrierten diese in unser Vorgehensmodell. Damit waren die Fachbereiche in der Lage zu erkennen, welche Risiken mitigiert werden können und welche Kosten für die Einführung einer Notfallinfrastruktur dafür aufzubringen waren. Auf dieser Basis erstellten die Fachbereiche Wirtschaftlichkeitsberechnungen. Die daraus gewonnenen Ergebnisse legten nahe, aus wirtschaftlichen Gründen das Projekt zu beenden. Positiv stellte sich heraus, dass im Rahmen des Projektes eine Vielzahl von Erkenntnissen über tatsächliche Schadenshöhen und organisatorische Mitigation gewonnen wurden. Zusätzlich wurde das Durchführen weiterer technischer Stabilisierungsmaßnahmen vereinbart. Mehr dazu befindet sich unter Projekt 55
Projektkontext:
In einer ersten Phase, siehe Projekt 49, habe ich eine Anwendung für die Produktlebenszyklusüberprüfung entwickeln lassen. Ziel war es nun, diese Software mit den erforderlichen MiFiD-relevanten Eigenschaften und Funktionalitäten erweitern zu lassen. Die Bank musste dabei regulatorische Anforderungen erfüllen. Diese Lösung sollte als Release der Produktlebenszyklusüberprüfung zur Verfügung gestellt werden.
Projektaufgabe:
Auf Basis von internen Revisionsanforderungen und externen regulatorischen Anforderungen habe ich mit dem Fachbereich ein grobes fachliches Vorgehensmodell entwickelt. Auf dieser Grundlage konnten wir abschätzen, welche MiFiD-relevanten Auslöser beispielsweise Ad-HocPrüfungen veranlassen würden. Zusätzlich zogen wir etwa Profitabilitätsbetrachtungen des Produktmanagements in die Betrachtungen mit ein. Die zu implementierende Lösung sollte beide Themenbereiche abdecken und Doppelarbeit vermeiden. Weiterhin wollten wir bestehende manuelle Dateiladevorgänge durch automatisierte Mechanismen ablösen. Dazu wollten wir die relevanten Datenquellen anbinden. Für dieses Projekt erstellte ich eine erste Planung und Kostenschätzung. Da jedoch zu dieser Zeit eine erhebliche Neuordnung des Bankkonzerns durchgeführt wurde, konnten uns die erforderlichen Budgets nicht bereitgestellt werden. Die Tätigkeiten sollten bis zu einem neu zu definierenden Termin ins neue Jahr verschoben werden. Ich ließ alle in Bearbeitung befindlichen Dokument ordentlich abschließen, stornierte alle angestoßenen Bestellungen, kündigte allen externen Dienstleistern oder ließ die Verträge auslaufen (auch meinen) und schloss das Projekt sauber ab.
Nachrichtlich:
Gegen Ende des ersten Halbjahres wurde das Projekt, aufbauend auf unseren Arbeitsergebnissen wieder aufgenommen und fortgeführt. Es wurde weiteres Budget bewilligt.
Projektkontext:
Das derzeit beim Kunden in der Fachabteilung Operational Risk Management verwendete Toolset für Analysen und Management Reporting genügte nicht mehr den Anforderungen an IT Systeme der Bank und barg Risiken in Hinsicht auf Verfügbarkeit und Wissenstransfer. Die Anwendung war eine sogenannte End-User Developed Application und wurde gemäß eines Regelprozesses ordnungsgemäß im Application Repository registriert. Um die Anwendung wieder auf den erforderlichen Systemlevel zu heben, sollte sie durch eine Standardsoftwarelösung ersetzt werden. Dieses neue System sollte dann dem geregelten Systembetrieb der Bank IT unterliegen. Daher wurde in einer Vorstudie 2014 vom Fachbereich SAS Visual Analytics als Werkzeug für ein zentrales Management Information System (MIS) ausgewählt, dies in einem Proof of Concept erfolgreich getestet sowie der Aufbau eines MIS beantragt und genehmigt.
Projektaufgabe:
Mein Projektziel war der Aufbau dieses Management Information Systems für Operational Risk Management mit dem Bereitstellen einer zentralen Datenhaltung als Basis für das MIS, einer automatisierten Anbindung aller relevanten Datenquellen, die Integration zusätzlicher manueller Datenfeeds über einen kontrollierten Prozess sowie die Erstellung standardisierter Reports inklusive Historisierung in der Datenbank, Einbindung einer AuditFunktion und dem Tracking der Zugriffe. Ein weiterer wichtiger Punkt, der über die bisher vorhandenen Funktionalitäten hinausging, war das Ziel, eine Self-Service-BI zur Erstellung und Änderung von Reports inklusive umfangreicher Analysefunktionen (Explorative-, Trend-, Forecast- und Predictive Analyse) bereitzustellen. Zusätzlich war eine iPadAnbindung zum Nutzen der Reports, Drill-Down und Analyse gefordert. Da die Bank IT und mein Projektteam nicht in Toolauswahl und Proof of Concept eingebunden waren, haben wir das Projekt in zwei Phasen aufgeteilt. Schwerpunkte der ersten Phase waren die Erarbeitung der Business Requirements (funktionale und nichtfunktionale Anforderungen) im Rahmen von 6 Workshops mit der Fachabteilung, die Erarbeitung eines Designkonzepts für die Software- und Architekturempfehlung, das Ermitteln von zu hebenden Synergien wie die Nutzung von Infrastruktur- und Lizenzkomponenten gemeinsam mit anderen Projekten, die Projektplanung zur Bereitstellung der Applikation und de Reports, sowie die finale Schätzung des Umsetzungsprojektes auf Basis der Anforderungen und des Designentwurfs, inklusive einer Schätzung der Betriebskosten für Infrastruktur und Applikation Management in den Folgejahren. Zur Unterstützung bei der Durchführung der ersten Phase kaufte ich Dienstleistungen bei einem externen Dienstleister ein. Nach erfolgreicher Freigabe der Bestellung im Einkaufsportal und Onboarding der Projektmitarbeiter, führte ich eine Kickoffveranstaltung durch. Die externen Berater bekamen von mir die Aufgabe, die 6 Workshops mit den Schwerpunkten fachliche Anforderungen (Requirements), Datenversorgung (Data Management) und Zielbild (Solution Design) gemeinsam mit dem Fachbereich durchzuführen. Als Ergebnisdokumente vereinbarte ich die Erstellung eines Zielbildes, die Ausformulierung eines Projektanforderungsdokumentes (Fachkonzept) und das Ausarbeiten eines Architekturvorschlages (High Level Architecture). Diese Ergebnisdokumente unterzog ich einem Überprüfungs- (Review) und Freigabeprozess (Approval), um sie fachlich abgenommen und qualitätsgesichert als Basis für die Erstellung der technischen Konzeption zu verwenden. Weiterhin nutzte ich diese Dokumente, um die erforderliches Freigabe der Quality Gates durch das Qualitätsmanagement zu erhalten. Parallel zur Durchführung der Workshops und dem Erstellen der Ergebnisdokumente plante ich die zweite Phase des Projekts, die Durchführung des Umsetzungsprojekts. Ich ermittelte und stellte die erforderlichen Teilaufgaben zusammen und leitete daraus die notwendigen Arbeitspakete ab. Für die benötigte Datenversorgung planten wir ein sich im Aufbau befindliches Operational Risk Datawarehouse nutzen. Ich stimmte die Datenverfügbarkeit und die von diesem Projekt gegebenen zeitlichen Rahmenbedingungen ab und brachte sie in Einklang mit unserer eigenen Zeitplanung. Dieses Operational Risk Datawarehouse wird von einem weiteren externen Dienstleister aufgebaut. Daher beschloss ich zur Unterstützung auch von dieser Firma Leistungen für unser Projekt einzukaufen. Das von unserem Projekt als Zielsystem festgelegte SAS Visual Analytics wurde zur gleichen Zeit von einem anderen Projekt validiert und implementiert. Da dieses Projekt SAS Visual Analytics als Plattform aufsetzen und diese anderen Projekten zur Nutzung zur Verfügung stellen wollte, trat ich in Abstimmung mit dessen Projektleitung ein. In mehreren Workshops konnten wir die Anforderungen und Zeitplanungen synchronisieren und vereinbarten, die Plattform gemeinsam zu projektieren und zu nutzen. Damit konnte ich für unser Projekt erhebliche Synergien hinsichtlich Infrastruktur-, Lizenz- und Betriebskosten heben. Am Anfang des dritten Quartals stellte ich den Lösungsansatz, das Vorgehensmodell und die Kostenschätzung beim Projektsponsor und Lenkungsausschuß vor. Die Präsentation erzielte große Zustimmung und wurde in das OpCo-Meeting eingebracht, um für die bisherige Budgetzusage nun die Budgetfreigabe für den Umsetzungsteil im nächsten Jahr zu bekommen. Es sollte eine reine Formsache sein, das Budget zu erhalten. Leider war dies nicht der Fall. Uns wurde eine erhebliche Budgetkürzung auferlegt, die Bank musste sparen. Wir sollten mit viel weniger Mitteln zum Ziel kommen, oder wenigstens „zeigen, was wir können“, um im Nachgang möglicherweise die restlichen Gelder zu erhalten. Wir entschlossen uns, nur einen Teil der Datenquellen anzubinden und so die Möglichkeit zu bieten, die volle Funktionalität auf einer Teilmenge der Daten produktiv vorzuführen, zu „zeigen, was wir können“, um dann das Restbudget für die vollständige Implementierung zu erhalten. Da ich eine detaillierte Kostenaufstellung im Zuge der Projektplanung erarbeitet hatte, war es für mich nur eine Fleißaufgabe, unter Einbeziehung aller involvierten Parteien, die für dieses eingeschränkte Vorgehen notwendige Planung und Kostenschätzung zu erarbeiten und in den Gremien vorzustellen. Die Planung wurde als valide angesehen, aber uns wurden weitere Budgeteinschränkungen auferlegt. Diese machten den Ansatz unmöglich. Wir planten erneut um und entschlossen uns, einen sinnvollen Datenhaushalt mit der entsprechenden Bewirtschaftung aufzubauen und auf ein Anbinden eines Frontends zu verzichten. Dies wollten wir nach Freigabe weiterer Gelder projektieren. Da ich eine detaillierte Kostenaufstellung im Zuge der Projektplanung erarbeitet hatte, war es für mich nur eine Fleißaufgabe, unter Einbeziehung aller involvierten Parteien, die für dieses weiter eingeschränkte Vorgehen notwendige Planung und Kostenschätzung zu erarbeiten und in den Gremien vorzustellen. Die Planung wurde als valide angesehen, aber uns wurden weitere Budgeteinschränkungen auferlegt. Diese machten auch diesen Ansatz unmöglich. Daher trafen wir in den Gremien die Entscheidung, den aktuellen Arbeitsstand sauber zu dokumentieren und die weitere Projektarbeit zum Ende des Jahres definiert einzustellen. Ich ließ alle in Bearbeitung befindlichen Dokument ordentlich abschließen, stornierte alle angestoßenen Bestellungen, kündigte allen externen Dienstleistern oder ließ die Verträge auslaufen (auch meinen) und schloss das Projekt sauber ab.
Nachrichtlich:
Vier Monate später wurde das Projekt, aufbauend auf unseren Arbeitsergebnissen wieder aufgenommen und fortgeführt. Es wurde weiteres Budget bewilligt.
Projektkontext:
Zur Erfüllung ihrer Aufgaben benötigt die Europäische Zentralbank (EZB) länderspezifische und vergleichende Zahlungsverkehrsstatistiken. Auf Basis der EU-Verordnungen Nr. 2533/98 und insbesondere 1409/2013 sollen ab dem Berichtsjahr 2014 Zahlungsverkehrsdaten und Daten über Zahlungsverkehrssysteme erhoben werden. Das Ziel der neuen Zahlungsverkehrsstatistik liegt in der größeren Harmonisierung von Definitionen und Meldeinhalten innerhalb des Euroraums. Die Meldung zur jährlichen Zahlungsverkehrsstatistik (ZV-Statistik) ist eine regulatorische Anforderung. Das Recht zur Überprüfung oder Zwangserhebung statistischer Daten wird von den nationalen Zentralbanken ausgeübt. Die ZVStatistik selbst enthält Positionen über Anzahl und Wert von Transaktionen, die über das ganze Berichtsjahr zu kumulieren sind, sowie Positionen, die sich auf den Bestand zum Jahresende beziehen. Die erstellte Meldedatei wird im XML Format über das Extranet der Deutschen Bundesbank eingereicht. Die technische Spezifikation sowie die Richtlinien zu den Inhalten der einzelnen Meldepositionen wurden von der Deutschen Bundesbank vorgegeben.
Projektaufgabe:
Projektziel waren die Ermittlung und Bereitstellung der statistischen Daten auf Basis der neuen regulatorischen Anforderungen. Statistiken über den Zahlungsverkehr von 2007 bis 2013 dienten vor allem als Datenquelle zur Einrichtung, Steuerung und Überwachung von Zahlungsverkehrs- und Wertpapierabrechnungssystemen des Kreditgewerbes in Deutschland. Bisher waren ausschließlich alle inländischen Banken (MFI – Monetary Financial Institute) meldepflichtig. Diese MFI haben einen Großteil der Zahlungsverkehrsgeschäfte erbracht und gemeldet, da für das Betreiben des Girogeschäftes eine Banklizenz Voraussetzung war. Mit Inkrafttreten des Zahlungsdiensteaufsichtsgesetzes (ZAG) im Jahr 2009 können europaweit Zahlungsdienste auch von sogenannten Zahlungsdienstleistern (ZDL) angeboten werden. Der Begriff des Zahlungsdienstleisters beinhaltet sowohl die bisherigen MFI als auch neue meldepflichtige Marktteilnehmer wie beispielsweise E-Geld Institute. Aufgrund dieser Änderung in den rechtlichen Rahmenbedingungen dürfen mit der neuen ZV-Statistik Transaktionen dieser ZDL nicht mehr in der Bundesbankmeldung aufgeführt werden. Dies bedeutete für mich und mein Projektteam, dass wir den bestehenden Meldeprozess, zur Gewährleistung der Kontinuität der Meldungen gegenüber der Bundesbank, zu analysieren hatten. Dabei haben wir auf die aktuelle Datenermittlung, deren Inhalte und Abläufe zurückgegriffen. Auf Basis dieser Analyseergebnisse und den weiterführenden regulativen Vorgaben der Bundebank erstellten wir ein Konzept, um die Compliance für die Bank sicherzustellen. Unsere grundsätzliche Annahme dabei war, dass die Kennzahlen bisher korrekt ermittelt wurden und deshalb darauf aufgebaut werden konnte. Im Rahmen der Analyse und der fachlichen Anforderungserhebung haben wir jede Position auf eine mögliche Wiederverwertung hin überprüft. Dieses Vorgehen führte dazu, dass fachlich identische Kennzahlen lediglich mit der korrekten Positionsangabe, bezogen auf das entsprechende Zahlungsverkehrsmeldeschema (ZVS), in eine neue Schnittstelle an der richtigen Position aufgenommen werden mussten. Jedoch mussten wir auf Grund geänderter Richtlinien Statistikpositionen anpassen. Zusätzlich kamen neue Anforderungen hinzu. In diesem Zuge mussten wir eine Vielzahl von Plausibilitäten berücksichtigen und die Meldungen getrennt nach Gesellschaften (Legal Entitys) abgeben. Zur Sicherheit und Vergleichbarkeit planten wir, die maschinelle Aufbereitung nach dem alten Meldeschema weiterhin parallel zu prozessieren. Diese Ergebnisse meldeten wir jedoch nicht mehr an die Bundesbank. Derzeit liefern verschiedene Systeme statistische Informationen über Konten, Karten, Bankensysteme und Transaktionen im Zuge des jährlichen Statistikreports. Dieser Report wird als XML Datei in das Extranet der Bundesbank eingespielt. Die geplanten Änderungen können deshalb externe Datenlieferanten sowie interne Providersysteme betreffen. Aus diesem Grund haben wir die Aufgaben auf verschiedene Teams verteilt. Mein Team und ich fokussierten uns auf zwei Datenlieferungsstränge. Zum einen bearbeiteten wir die Kartentransaktionen und zum anderen den Auslandszahlungsverkehr. Dazu erstellte ich für die mir zugeordneten Entwicklerteams ein Dokument mit detaillierten Softwareanforderungen. In diesem Dokument beschrieb ich, wie die Requirements, beispielsweise das Zählen von Kartentransaktionen, Überweisungen oder Schecks sowie das Bilden von Summen oder Herausrechnen der ZDL, in der Umsetzung durchgeführt werden sollten. Unter meiner Steuerung programmierten die Entwickler die entsprechende Software für die betroffenen Systeme auf Basis meines Anforderungsdokuments. Die im Zuge der Entwicklung aufkommenden Fragen klärte ich mit den Entwicklern. Dort, wo es erforderlich war, band ich die Fachabteilung oder andere Teilprojekte zur inhaltlichen Klärung der Sachverhalte ein. Ein weiterer Schwerpunkt meiner Arbeit war das Anpassen der Lieferschnittstellen sowie das Einrichten der Datenlieferprozesse. Diese neuen Schnittstellen und Prozesse sollten für eine gewisse Zeit lang als Parallelversorgung zur bestehenden Lieferstrecke betrieben werden. Die Aufgabe war insbesondere wichtig, da von der Gesamtprojektleitung geplant war, einen End-to-End-Test durchzuführen. Dies war besonders deswegen eine Herausforderung, da wir zum Test ausschließlich synthetische Daten zu verwenden hatten. So organsierte ich die Erzeugung und Bereitstellung von synthetischen Testdaten und veranlasste die notwendigen Systemverbindungen inklusive der erforderlichen Datentransferjobs zur Übertragung der Dateien. Da wir keine Produktivdaten verwenden durften, ließ ich analysieren, welche Auswirkung dies auf Ablaufsteuerungen im Systemverbund hatte und veranlasste die erforderlichen Anpassungen, um den Test zu ermöglichen. In einigen Teilbereichen der Lieferstrecke war es nicht möglich, die synthetischen Daten automatisiert zu verarbeiten. Daher vereinbarte ich mit Testmanagement und Operating die notwendigen manuellen Eingriffe, die im Rahmen der Tests erforderlich sein würden. Eine weitere Aufgabe war die Erstellung von Testdaten. Dazu stimmte ich Anforderungen an die und Umfang der Testaktivitäten mit dem Testmanagement ab. Auf Basis dieser Anforderungen und des Mastertestplans ließ ich die notwendigen Testfälle erstellen und im Rahmen eines Prüfungs- und Freigabeprozesses von den verantwortlichen Personen abnehmen. Nach der Abnahme der Testfälle veranlasste ich ein Hochladen der Testfälle in HP ALM und ein Verknüpfen mit den dazugehörigen Anforderungen. Zur weiteren Testvorbereitung stimmte ich mit meinem Team, dem Testmanagement und der Gesamtprojektleitung den Zeitplan und das Vorgehen ab. Nach Abschluss der Entwicklungsarbeiten stellte ich gemeinsam mit den Entwicklern sicher, dass die erforderlichen Entwickler- sowie Systemintegrationstests fehlerfrei und erfolgreich durchgeführt wurden. Im Nachgang an diese Tests führten wir im Zuge des End-to-End-Tests im Rahmen der Testorganisation eine Verarbeitung der Daten entlang der ganzen Lieferstrecke durch. Dabei mussten wir noch einige Details zum fehlerfreien Prozessieren der Daten klä- ren, abstimmen und umsetzen lassen. Danach konnten wir gemeinsam mit Fachtestern die Testfälle durchführen. Dabei stellte sich heraus, dass einige Fachanforderungen nicht präzise gestellt waren. Einige wenige Anforderungen änderten sich zudem, da die Fachabteilung neue Erkenntnisse aus dem Dialog mit der Bundesbank erlangt hatten. Hinzu kamen Abweichungen in den Ergebnissen, die auf Fehler in Zuordnungstabellen zurückzuführen waren. Ich veranlasste im Rahmen eines Changeprozesses die notwendige Softwareentwicklung zur Korrektur und die Bereitstellung der prozessierten Testdaten. Die Abläufe der Fachtests stimmte ich dabei mit den Entwicklern und Testern ab. Nach erfolgreichem Abschluss aller Testaktivitäten sorgte ich mit meinem Team für die Paketierung der Software zur Übergabe in den Produktivbetrieb. Dabei mussten wir uns mit dem Releasemanagement sowie dem Deploymentteam abstimmen. Da wir unsere Software so zum Einsatz bringen mussten, dass der vollständige Berichtsmonat abgedeckt ist, konnten wir nicht im Zuge eines an SAP ausgerichteten Regelreleases in Produktion gehen. Daher beantragten wir beim Change Advisory Board ein Exceptional Release. Nach der Freigabe unseres Exceptional Releases konnten wir zum passenden Termin Live gehen und unsere Software erfolgreich produktiv setzen. Nach erfolgreicher Produktivnahme mussten wir lediglich noch einige Vorbereitungen treffen, um die Jahresmeldung für das Berichtsjahr 2015 auf Basis der neuen Softwarekomponenten sicherzustellen. Der Abschluss dieser Tätigkeiten war für uns auch der erfolgreiche Abschluss unseres Projektes.
Projektkontext:
Die Einführung des Euros stellte einen wichtigen Schritt für die Schaffung eines europäischen Binnenmarktes dar. Die Euroeinführung wurde durch die schrittweise Standardisierung der in Europa existierenden Bezahlverfahren begleitet. Dies mündete in der Schaffung eines einheitlichen europäischen Zahlungsverkehrsraumes, der sogenannten Single European Payments Area – kurz SEPA. Mit der Implementierung der SEPA Zahlungsverfahren wurden einheitliche Technologien, aber auch einheitliche Datenformate umgesetzt. Ein elementarer Datenbestandteil ist dabei der SEPA Purpose Code, auch als Textschlüssel bekannt.
Projektaufgabe:
Im Jahr 2015 wurde die Spezifikation der Datenformate auf die Version 2.9 umgestellt. Diese Umstellung war terminiert auf den November 2015. Kernaufgabe dabei war die Integration neuer Purpose Codes. Mit Hilfe dieser Textschlüssel ist es möglich, Überweisungen und Lastschriften nach der Art der Zahlung zu klassifizieren, zu unterschieden und eine Automatisierung von Prozessen und Abläufen zu implementieren. Natürlich nutzt die Bank ebenfalls diese Textschlüssel, um darauf aufbauend Geschäftslogik und Ablaufsteuerungen zu prozessieren. Daher betraf die notwendige Umstellung eine Vielzahl von Systemen. Die Umstellung der vorgelagerten Operativsysteme wurde von einem anderen Team durchgeführt. Mein Team war dafür verantwortlich, die korrekte Umstellung der dispositiven Business Intelligence Systeme durchzuführen. Beginnen mussten wir mit einer klassischen Businessanalyse der Prozesse, Datenströme und involvierten Systeme. Basierend auf dem im Projekt 44 erstellten BI-Master identifizierten wir die möglicherweise von der Änderung betroffenen Systeme. Dabei konnten wir die zu untersuchenden Systeme bereits eindeutig ermitteln und die Gesamtanzahl dadurch deutlich reduzieren.Gemeinsam mit den technischen und fachlichen Ansprechpartnern klärten mein Team und ich die Datenversorgung der Systeme, den auf den Textschlüsseln basierenden Programmablauf und die daraus erzeugten Ergebnisdaten. So konnten wir die Anzahl der zu bearbeitenden Systeme nochmals eingrenzen, da nicht alle Anwendungen von der geplanten Umstellung auf die neuen Textschlüssel tatsächlich fachlich betroffen waren. Für die umzustellenden Systeme analysierten wir gemeinsam mit den zuständigen Programmierern den Programmcode und identifizierten die zu ändernden Bestandteile der Software. Für die notwendigen Programmanpassungen ließ ich fachliche Anforderungen (Requirements) erstellen. Dieses Fachkonzept unterzog ich einem Überprüfungs- (Review) und Freigabeprozess (Approval), um es qualitätsgesichert als Basis für die Erstellung der technischen Konzeption zu nutzen. Weiterhin nutzte ich dieses Papier, um die erforderliche Freigabe des Quality Gates durch das Qualitätsmanagement zu erhalten. Als nächsten Schritt plante und ließ ich durchführen die Erstellung der technischen Konzeption. In diesem Dokument ließ ich detailliert die Softwareanforderungen spezifizieren und beschreiben, wie technisch die erforderlichen Änderungen der entsprechenden Softwarekomponenten für die betroffenen Systeme auf Basis des Anforderungsdokuments umzusetzen sind. Auch dieses Dokument führte ich durch die notwendigen Prüf- und Freigabeschritte, um unter anderem die Anforderungen des Quality Gates zu erfüllen. Anschließend stellte ich die Programmierung der Softwareanpassung durch das Entwicklerteam auf Basis der Spezifikationsdokumente sicher. Dabei standen mein Team und ich im ständigen Dialog mit den Entwicklern, der Fachabteilung oder anderen Teilprojekten zur inhaltlichen Klärung von Sachverhalten und zur Abstimmung von Abhängigkeiten sowie Terminen. Eine weitere Aufgabe war die Bereitstellung von Testdaten. Dazu stimmte ich Anforderungen an die und Umfang der Testaktivitäten mit dem Testmanagement ab. Auf Basis dieser Anforderungen und des Mastertestplans ließ ich die notwendigen Testfälle erstellen und im Rahmen eines Prüfungs- und Freigabeprozesses von den verantwortlichen Personen abnehmen. Nach der Abnahme der Testfälle veranlasste ich ein Hochladen der Testfälle in HP ALM und ein Verknüpfen mit den dazugehörigen Anforderungen. Zur weiteren Testvorbereitung stimmte ich mit meinem Team, dem Testmanagement und der Gesamtprojektleitung den Zeitplan und das Vorgehen ab. Nach Abschluss der Entwicklungsarbeiten stellte ich gemeinsam mit den Entwicklern sicher, dass die erforderlichen Entwickler- sowie Systemintegrationstests fehlerfrei und erfolgreich durchgeführt wurden. Danach konnten wir gemeinsam mit Fachtestern die Testfälle durchführen. Die dabei entdeckten fachlichen Fehler ließ ich korrigieren und die Software erneut testen. Nach erfolgreichem Abschluss aller Testaktivitäten sorgte ich mit meinem Team für die Paketierung der Software zur Übergabe in den Produktivbetrieb. Dabei mussten wir uns mit dem Releasemanagement sowie dem Deploymentteam abstimmen. Nach der Freigabe unseres Releases konnten wir zum Zieltermin Live gehen und unsere Software erfolgreich in den Produktivbetrieb überführen. In den letzten Jahreswochen 2015 standen wir für eine Unterstützung des Produktionsteams zur Verfügung. Im realen Produktivbetrieb und mit echten Daten stellten sich doch noch einige kleine Fehler heraus, die ich analysieren und beseitigen ließ. Diese Maßnahmen waren jedoch nicht sehr umfangreich und wir konnten die Betriebsunterstützung im Dezember beenden. Der Abschluss dieser Tätigkeiten war für uns auch der erfolgreiche Abschluss unseres Projektes.
Projektkontext:
Im Bankenumfeld ist ein Product Lifecycle Review ein wichtiger Prozess. Produktlebenszyklusüberprüfungen werden unter anderem zu zwei Zwecken durchgeführt. Zum einen, um regulatorische Anforderungen zu erfüllen, und zum anderen, um das Produktmanagement zu unterstützen. Die dabei genutzten und entstehenden Daten wurden bislang in unterschiedlichen Ausprägungen und an verschiedenen Stellen gespeichert. Die Datenhaltung sollte in eine zentrale Datenbank mit einheitlicher Geschäftslogik überführt werden.
Projektaufgabe:
Auf Basis eines vom Fachbereich erstellten Konzeptes sollte ein externer Dienstleister beauftragt werden, der die Erstellung der Applikation für die erste Phase übernehmen konnte. Die Anwendung sollte als zentrale Applikation für die Verwaltung und Steuerung des Reviewprozesses für die Produkte der Bank dienen. Das Lösungskonzept gründete auf bewährte State-of-the-Art Technologien, die Architektur basierte auf einem klassischen 3-Tier-Modell. Zuunterst lag die Persistenzschicht in Form einer Datenbank, die Business-Logik wurde in einem JBoss Applikationsserver implementiert und für die Anwender wurde ein webbasiertes Frontend bereitgestellt. Dazu habe ich eine Projektplanung sowie eine Kostenstruktur ausgearbeitet und abgestimmt. Ausgewählt habe ich einen Dienstleister, der sich in diesem Umfeld der Bank bereits bewährt hatte. Das hatte den Vorteil, dass ich die Aufgabe als Gewerk vergeben konnte. Meine Aufgaben in diesem Projekt konzentrierten sich daher vorrangig auf klassisches Projektcontrolling zur Steuerung des Dienstleisters. Organisatorisch stellte ich sicher, dass die Anwendung nach Ende der externen Entwicklung und umfassenden Tests in den Regelbetrieb der Bank übernommen werden konnte. Dazu stimmte ich die erforderlichen Dokumentationen ab und ließ diese erstellen sowie abnehmen. Zusätzlich führte ich Übergabetermine mit den Entwicklern und dem Production Support durch, um sicherzustellen, dass der Anwendungsbetrieb mit allen erforderlichen Informationen ausgestattet wurde. Parallel zur erfolgreichen Übergabe in den Produktivbetrieb plante ich die zweite Phase des Projektes. Dazu sollte die Anwendung MiFiD-fähig gemacht werden; die Beschreibung des Projektes finden Sie unter Projekt 50.
Projektkontext:
Der Kunde plante die Ablösung des selbstentwickelten Operativsystems zur Verwaltung und Abwicklung von Girokonten und Einlagegeschäften durch die Standardsoftware SAP DM (Deposit Manager) im Rahmen des größten, europäischen IT-Programmes. Dabei sollten alle im System geführten Girokonten und Einlagegeschäfte der größten Kundengruppe der Privat- und Geschäftskunden (PGK) vom Alt- in das Neusystem migriert werden. Dies betraf die Verträge von rund 6.000.000 Kunden. Zusätzlich sollten die dann im SAP DM vorliegenden Verträge nicht mehr über das eigenentwickelte Financesystem sondern über den SAP BA (Bank Analyzer) verarbeitet werden. Damit sollten die buchhalterischen Zahlen dieser Verträge zukünftig über das Neusystem ermittelt werden. Parallel dazu war geplant, die nicht migrierten Verträge über die alten Systeme zu verarbeiten. Dies bedeutete, dass die Daten sowohl der migrierten als auch der nicht migrierten Verträge im BI-Umfeld wieder zusammengeführt werden sollten.
Projektaufgabe: Der Schwerpunkt meines Teams war dabei die Aufrechterhaltung aller Funktionalitäten des zentralen BI Datawarehouses und dessen Abnehmersysteme im Rahmen des Programmes BI Maintain. Zur Auswertung der Girokonten und Einlagegeschäfte durch Business Intelligence waren neun operative Liefersysteme, vier Datawarehouses und 52 auswertende BIApplikationen, versorgt über mehr als 100 Schnittstellen, zu analysieren und anschließend umzustellen. Wichtig war insbesondere die Festlegung des Scopes, da das Systemumfeld nicht einheitlich verantwortet wurde. Wir haben ermittelt, welche Systeme tatsächlich von der Umstellung betroffen waren, wer diese Systeme technisch betreut und fachlich nutzt. Dabei konnten wir Erkenntnisse (BI-Master) und Erfahrungen aus dem Projekt CML (Projekt 44 in dieser Liste) als Basis für die Projektplanung und die Ausarbeitung der Vorgehensweise nutzen. Damit wir die Unterstützung aller relevanten Stakeholder sicherstellen und wir unsere Vorgehensweise sowie die erforderliche fachliche und technische Unterstützung transparent machen konnten, führten wir mehrere Workshops mit den Mitarbeitern der betroffenen Abteilungen und Bereiche durch. Als Arbeitsergebnisse konnten aus den 84 in Scope liegenden BI-Applikationen 39 direkt und 13 indirekt betroffene Anwendungen inklusive ihrer Relationen identifiziert werden. Weiterhin konnten wir den aus dem CML-Projekt stammenden BI-Master erweitern sowie das Ist-Bild der betroffenen Systemlandschaft ermitteln und darstellen. Alle von den BI-Applikationen benötigten Informationen aus den Altsystemen haben wir in einer Applikations-Feld-Matrix dokumentiert. Damit haben mein Team und ich herausgearbeitet, welche Schnittstelleninhalte von welchen Anwendungen genutzt wurden – ein Kernthema für die notwendige Umstellung. Eine weitere Rahmenbedingung war, dass die BI-Welt über zwei Hauptstränge mit Daten versorgt werden sollte. Zum einen sollten Daten direkt aus dem Operativsystem SAP DM innerhalb von BI verwendet werden und zum anderen sollte BI die Finance-Zahlen über den SAP BA erhalten. Beide Stränge sollten nach Architekturvorgabe über SAP BW (Business Warehouse) an die BI-Welt angebunden werden. Um der Komplexität der Themen gerecht zu werden, haben wir diese jeweils einem Teilteam zugeordnet. Das Team, das für die Datenversorgung aus SAP DM zuständig war, stellte fest, dass die Datenmodellierung in SAP BW für das BI-Umfeld noch nicht geeignet war. Daraufhin haben wir in Zusammenarbeit mit dem Team DMIntegration ein konzeptionelles Datenmodell auf Basis der fachlichen Anforderungen ausgearbeitet. Dieses nutzten wir als Grundlage für die logische Datenmodellierung in SAP BW. Als weit schwieriger stellte sich die Ausarbeitung der Alt-Neu-Überleitung heraus. Die Alt-Neu-Überleitung über die Migrationsstrecke lieferte nicht für alle benötigten Informationen hinreichend verwendbare Aussagen. Deshalb erarbeiteten wir eine alternative Vorgehensweise. Auf Basis der inhaltlich fachlichen Anforderungen der einzelnen BI-Applikationen erstellten mein Team und ich eine Lieferanforderung und adressierten diese an das SAP DM-Team. Somit konnten wir die benötigten Informationen aus SAP DM identifizieren und uns diese über SAP BW bereitstellen lassen. Das Team, das für die Datenversorgung aus SAP BA zuständig war, erstellte auf Grundlage der benötigten Informationen eine Datenanforderung an das SAP BA-Team. Zusammen mit dem BA-Team haben wir neue Lieferstrecken vereinbart und für den Großteil der benötigten Attribute eine Alt-Neu- Überleitung ausgearbeitet. Für die restlichen Attribute konnten wir Alternativen aus dem Neusystem ermitteln und bereitstellen lassen. Die verbliebenen Altattribute konnten nach fachlicher Klärung aus der Anforderungsliste herausgenommen werden. Zusätzlich haben wir vereinbart, dass für einige benötigte Altschlüssel Rückableitungen über das SAP BW bereitgestellt werden sollten. Parallel zum Aufsetzen der beiden Datenversorgungsstränge habe ich an der technischen Anbindung des BI-Umfeldes an SAP BW gearbeitet. Hierzu arbeiteten mein Team und ich unterschiedliche technische Lieferwege aus und stimmten diese mit dem Domänenarchitekten ab. Für den vereinbarten Lieferweg beauftragten wir die Entwicklung und Umsetzung der technischen Schnittstellen bei den zuständigen Entwicklerteams. Zur Unterstützung der Umsetzung erstellte ich Jobhandbücher für die UC4-Prozesse, definierte die erforderlichen Transformationsregeln für die Datenkonvertierung von SAP nach Host und tauschte mich regelmäßig mit allen beteiligten Personen in Workshops aus. Ich konnte termingerecht im Dezember 2014 die technische Anbindung von SAP BW auf Midrange an das BI DWH auf Mainframe in Betrieb nehmen. Im ersten Quartal 2015 wurde vom Management die IT-Strategie überprüft und das weitere Vorgehen im Programm hinterfragt. Dies hatte für uns zur Folge, dass wir die laufenden Aktivitäten begrenzen und die bis dahin erzielten Ergebnisse sichern mussten. Zentrale Arbeitsunterlagen habe ich mit meinem Team in einen definierten Zustand überführt, abgestimmt und dokumentiert. Zusätzlich erstellten wir für 23 ausgewählte Applikationen Konzepte, um die von uns ausgearbeiteten Lö- sungsoptionen für die jeweilige Anwendung für eine mögliche spätere Umsetzung festzuhalten. Auf Basis unserer Erkenntnisse haben wir für das Management alternative Vorgehensweisen für die Projektfortführung ausgearbeitet. Dabei skizzierten wir zwei unterschiedliche Vorgehensmodelle, jeweils mit einem Basis- und einem erweiterten Szenario. Wir haben zu diesen Szenarien Aufwandschätzungen sowie Projektkalkulationen erarbeitet und dem Program Management vorgestellt. Im Februar 2015 wurde vom Management entschieden, die Projektaktivitäten einzustellen und alle zielrelevanten Informationen und Dokumente zu archivieren. Diese Tätigkeiten führten wir bis Ende Februar durch.
Projektkontext:
Der Kunde plante die Ablösung des selbstentwickelten Operativsystems zur Verwaltung und Abwicklung von Baufinanzierungen durch die Standardsoftware SAP CML im Rahmen des größten europäischen ITProgrammes. Dabei mussten alle Baufinanzierungsverträge vom Alt- in das Neusystem migriert werden. Dies betraf die Verträge von rund 600.000 Kunden mit einem Gesamtvolumen von etwa 50.000.000.000 Euro. Mit der Einführung von SAP CML sollte für das Baufinanzierungsportfolio ein großer Schritt in Richtung einer zukunftsfähigen Kreditfabrik unternommen werden.
Projektaufgabe:
Der Schwerpunkt meiner Arbeit und der meines Teams war dabei die Sicherstellung der Aufrechterhaltung aller Funktionalitäten des zentralen BI Datawarehouses und dessen Abnehmersysteme im Rahmen des Programmes BI Maintain. Zur Auswertung der Baufinanzierungen durch Business Intelligence (BI) waren fünf operative Liefersysteme, vier Datawarehouses und 47 auswertende BI-Applikationen, versorgt über 75 Schnittstellen, zu analysieren und anschließend umzustellen. Wichtig war insbesondere die Festlegung des Scopes, da das Systemumfeld nicht einheitlich verantwortet wurde. Wir haben ermittelt, welche Systeme tatsächlich von der Umstellung betroffen waren, wer diese Systeme technisch betreut und fachlich nutzt. Dabei erstellten wir eine Landkarte (BI-Master, A0) zur Darstellung der Systeme, Schnittstellen und Datenflüsse. Diese Darstellung nutzten wir als Basis für die Projektplanung und die Ausarbeitung der Vorgehensweise. Zusätzlich konnte ich auf Grundlage dieser Erhebung eine erste Projektkalkulation und Resourcenplanung aufstellen.
Damit wir die Unterstützung aller relevanten Stakeholder sicherstellen und unsere Vorgehensweise sowie die erforderliche fachliche und technische Unterstützung transparent machen konnten, veranstalteten wir mehrere Informationsveranstaltungen. Im Nachgang führten wir dedizierte Einzelgespräche, sogenannte Kleeblattgespräche, durch. Als Arbeitsergebnisse hieraus konnten mein Team und ich die Identifizierung aller BI-relevanter Systeme und Systemrelationen (insgesamt 40 BI Applikationen waren direkt betroffen und weitere 7 indirekt) abschließen. Weiterhin konnte ich die finale Darstellung des BI-Masters sowie die des Ist-Bildes und die Erhebung aller benötigter Informationen aus den Altsystemen in einer Applikations-FeldMatrix erstellen. Damit haben wir unter anderem herausgearbeitet, welche Schnittstelleninhalte von welchen Anwendungen genutzt wurden – ein Kernthema für die notwendige Umstellung. In Zusammenarbeit mit dem CML-Integrationsteam erarbeitete mein Team für die rund 500 betroffenen Datenfelder eine Beschreibung wie die benötigten Daten im neuen Umfeld zur Verfügung stehen würden. Dabei stellten wir fest, dass es neben Informationen, die 1:1 abgebildet werden konnten, eine Vielzahl von Inhalten in anderer Ausprägung und oder Struktur bereitgestellt werden sollten. Ferner bemerkten wir, dass mache Inhalte nicht mehr lieferbar waren und weitere, neue Inhalte hinzukommen sollten. Dies machte es für uns erforderlich, Rückableitungsvorschriften zu erarbeiten und Daten zusätzlich in speziellen Lieferformaten für die Abnehmer bereit zu stellen. Bei der Konzeption mussten wir insbesondere beachten, dass eine fachliche Umstellung vom Ist- auf das Soll-Prinzip vorgenommen werden sollte. Dies brachte Auswirkungen auf die Test- und Überprüfbarkeit der neuen Daten und Rechenergebnisse mit sich. Ferner sollte die Lieferkette an die BI-Welt umgestellt werden. Wir planten, die Datenversorgung nicht mehr direkt aus den Operativsystemen heraus zu bewerkstelligen, sondern auf eine Anbindung über SAP BW (Business Warehouse) und eine ETL-Plattform (Extract, Transform, Load) , basierend auf Informatica, umzustellen. Weiterhin mussten wir berücksichtigen, dass die Datenbereitstellung zukünftig in Form eines Datenmodells, im Gegensatz zur bestehenden denormalisierten Struktur, vorgesehen war. Die Anpassung der einzelnen Systeme wurde durch Entwicklerteams vorgenommen. Um diese Arbeiten zu unterstützen und letzte Detailfragen zu klären, führte ich mit meinem Team Deep Dive Gespräche zur Weitergabe applikationsspezifischer Informationen mit den involvierten Personen durch. Weiterhin begleiteten wir die Entwicklungsphase beratend und standen jederzeit als Ansprechpartner für Problemlösungen zur Verfügung. Da im Rahmen des Projektes die erforderliche Testorganisation noch nicht zur Verfügung stand, wurden wir von der Programmleitung in die Testplanung und –durchführung eingebunden, da wir im Umfeld die umfassendsten Kenntnisse hatten. Mein Team und ich arbeiteten an der Festlegung des Testumfangs und der zu bereitstellenden Testumgebungen mit. Zusätzlich klärten wir die Verfügbarkeit und Bereitstellung von Testdaten. Wir informierten die Verantwortlichen der betroffenen BI-Applikationen über die vorgesehene Testdurchführung und unterstützen sie bei der Erstellung von Testfällen. Während der Tests standen wir zur Klärung von Detailfragen zur Verfügung, erfassten die erkannten Fehler (Defects) in der Datenbank von HP ALM und veranlassten die Behebung von Mängeln. Manche Fehler, die beseitigt werden mussten, zogen Softwareanpassungen nach sich. Weiterhin mussten wir vereinzelt Konzeptadjustierungen erarbeiten und abstimmen. Durch die hohe Qualität unserer Tests identifizierten wir zwei Fehler in Vorsystemen, die bislang unentdeckt geblieben waren. Bei der Planung der Inbetriebnahme (cut over) waren wir ebenfalls aktiv eingebunden. Schließlich galt es, eine reibungslose Systemintegration mit dem Releasemanagement aufzuplanen. Fokus dabei war die Einbettung des Neusystems in die bestehende Umsystem- und Prozesslandschaft. Hinsichtlich der Abläufe war eine Prozessharmonisierung erforderlich, die eine weitgehende Angleichung der neuen Prozesse an die bestehenden Standardprozesse zum Ziel hatte. Bei der Gestaltung der Prozesse arbeiteten mein Team und ich aktiv mit. Wir hatten vorgesehen, die von unserem Programm betreuten Anwendungen zum Jahreswechsel in Betrieb zu nehmen. Damit nicht alle Umstellungsaufgaben in einem engen Zeitfenster stattfinden mussten, entzerrten wir den Zeitplan dahingehend, dass wir die täglich laufenden Prozesse zum 06.01.2014 und die monatlich laufenden Vorgänge zum 31.01.2014 in den Produktivbetrieb überführten. So stellten wir 38 der 40 direkt betroffenen Applikationen ohne signifikante Produktionsprobleme um. Für eine Applikation mussten Nachbesserungen in den Vorsystemen durchgeführt werden. Für eine weitere Applikation mussten wir erneut fachliche Vorgaben einholen, abstimmen und entsprechende Anpassungen vornehmen lassen. Daher führten wir eine Nachbetreuung bis Ende des ersten Quartals durch. Alle Umstellungen haben reibungslos funktioniert und konnten erfolgreich abgeschlossen werden.
Projektkontext:
Die Sozietäten planten, die bestehende Serverinfrastruktur zu erneuern und hochverfügbar auszulegen.
Projektaufgabe:
Dazu mussten meine IT-Spezialisten die bestehende Infrastruktur analysieren und katalogisieren lassen. Parallel dazu erarbeitete mein Business Analyst gemeinsam mit dem Kunden die Anforderungen an die neue IT-Infrastruktur. Schwerpunkt dabei war die Definition der Hochverfügbarkeit. Wir identifizierten die bestehenden Services und bewerteten sie. Anschließend legten wir für die Services mit genügender Kritikalität die Hochverfügbarkeit fest. Nach dieser fachlichen Bewertung konnte ich meinen Business Analyst Vorgaben erstellen lassen, damit meine IT-Spezialisten ein technisches Konzept erarbeiten konnten. Auf Basis dieses Lösungsentwurfes mit Umsetzungsvarianten erstellte ich eine Wirtschaftlichkeitsbetrachtung. Gemeinsam mit dem ITVerantwortlichen des Kunden diskutierte ich die Lösungsansätze und spiegelte sie gegen die Wirtschaftlichkeitsberechnung. Wir erstellten gemeinsam eine Entscheidungsvorlage für die Gesellschafterversammlung. Nach der Entscheidung und Freigabe des Lösungsansatzes durch die Gesellschafterversammlung organisierte ich die Hardwarebeschaffung. Parallel dazu erstellte ich die Projektplanung. Die Herausforderung dabei war, dass der Umbau der Kanzleiinfrastruktur eine gewisse Zeit benötigt und der Geschäftsbetrieb möglichst nicht beeinträchtigt werden sollte. Insbesondere die Datenmigration inklusive Datensicherung benötigte viel Zeit. Durch einen pfiffigen Ansatz mit Full- und Incremental Backups konnten wir eine pragmatische Lösung anbieten. Da der Tag der Deutschen Einheit in diesem Jahr ein Mittwoch und die Kanzlei die Restwoche für ein Offsite nutzen wollte, führten wir die Umstellung in diesem Zeitraum durch. Ich steuerte die Umsetzung inklusive Servermigration im Rechenzentrum des Kunden bis zur Inbetriebnahme der neuen und Abschatung der alten Systeme. Wir konnten die Migration in diesem Zeitraum erfolgreich abschließen. Nach der Umstellung stellte ich sicher, dass die berühmten Kleinigkeiten noch behoben wurden. Einige kleine Fehler musste ich abstellen lassen. Weiterhin waren Systemtuning und reibungsloserer Ablauf Schwerpunkt der Arbeiten. Insbesondere musste ich sicherstellen lassen, dass die Datensicherung sowie die Synchronisation der Netzwerkspeicher einhundertprozentig funktionierten. Weiterhin ließ ich einige Notfalltests durchführen, um zu prüfen, ob alle Maß- nahmen der Hochverfügbarkeit auch greifen. Dies war der Fall. So ließ ich die Tests dokumentieren und abnehmen. Nach Ende der Umstellungsarbeiten ließ ich die Dokumentation der Systemlandschaft aktualisieren, ergänzen und abnehmen. Mit dieser Übergabe beendete ich das Projekt erfolgreich.
Berufsausbildung:
1988 - 1991
Studium:
1994 - 1996
1991 - 1994
Deutschland: Schwerpunkt PLZ 6 und 7, bei Bedarf temporär bundesweit
Wir haben zur Verbesserung der Zusammenarbeit und Information im Stadtteil eine Vernetzungsplattform konzipiert (Projekt 71). Diese Vernetzungsplattform soll nun implementiert werden. Dazu führten wir eine Ausschreibung durch. Wir definierten notwendige Dokumente und Prozesse. Durch das Vergabeverfahren zielten wir zusätzlich darauf ab, dass der zu beauftragende Dienstleister eine Qualitätssicherung der Ergebnisse des Projektteams vor der Umsetzung durchführt. Am Ende wählten wir einen Anbieter aus.
Projektkontext:
Die Bank und Tochtergesellschaften vertreiben im Zuge der Kreditvergabe Sicherheitspakete und Anlageprodukte, die aus Versicherungen bestehen oder enthalten. Daher war im Rahmen dieser Prozesse die neue EU Versicherungsvertriebsrichtlinie IDD anzuwenden. Die IDD bietet einen Regelungsrahmen für die nationalstaatliche Umsetzung des Versicherungsvertriebs und ist daher für den deutschen Versicherungsvertrieb von eminenter Bedeutung. Daher wurde das Programm IDD implementiert.
Programmaufgabe:
Als ich die Programmleitung für die Domänen Investment und Lending übernahm, waren einige organisatorische Vorbereitungen bereits durchgeführt sowie das Budget beantragt und bereitgestellt. Alle weiteren Aufgaben sollten mir obliegen. Daher implementierte ich umgehend eine Projektorganisation. Für die Projektarbeit im Bereich Finance setzte ich einen Projektleiter ein, der alle in diesem Bereich erforderlichen Projektaufgaben managen und an mich berichten sollte. In der Domäne Lending implementierte ich drei Projekte. Die Leitung des Projektes für das Onlinekreditsystem Consumer Finance übernahm ich, um Bezug zu den fachlichen Inhalten und dem Team zu halten. Parallel zu meinen Tätigkeiten als Projektleiter führte ich alle Aufgaben eines Programmanagers aus. Dabei führte ich die synchronisierende Planung und Steuerung meiner im Programm verbundenen Projekte durch. Zusätzlich verwaltete ich das Programm- und das Lending Projektbudget. Die Verwaltung des Budgets für die Domäne Finance hatte ich meinem Projektleiter übertragen. Weiterhin stellte ich neben der Budgetplanung die Ressourcenplanung sicher und führte alle Projekt- und Programmreportings durch. Auch hier hatte ich das Reporting für den Financebereich meinem Projektleiter übertragen. Ferner fungierte ich als Schnittstelle zu allen involvierten Stakeholdern und Gremien.
Für die Lending Projekte im Bereich Kredit- und Finanzierungsplanung Private Kredite sowie Restkreditversicherung Baufinanzierung setzte ich jeweils einen Projektleiter ein, der alle in diesem Bereich erforderlichen Projektaufgaben managen und an mich berichten sollte. Mit meinen Projektleitern vereinbarte ich Aufgabenbereiche sowie Vorgehensmodell inklusive der von mir erwarteten Deliverables. Zusätzlich richtete ich die erforderlichen Jour Fixes für die Projekte und das Programm ein. Besonderen Wert legte ich auf den regelmäßigen fachlichen Austausch mit dem Programmleiter der Businessseite. Dies insbesondere deshalb, da die Versicherungsrichtlinie noch in der Entstehung war. Die daraus resultierende Unschärfe mussten wir immer wieder aktuell technisch und fachlich bewerten und in unsere Gesamtplanung einbeziehen. Diese Abstimmung gelang exzellent und trug deutlich zum Projekterfolg bei. Wir haben im Zuge des Gesamtprogramms auf Basis des damals aktuellen Referentenentwurfs und unter Einbeziehung der politischen Diskussion Arbeitshypothesen abgeleitet. Auf Basis dieser Arbeitshypothesen haben wir für die fachliche und technische Umsetzung für die Bereiche Investment und Lending analysiert, welche Produkte, Prozesse und Systeme betroffen sind. Die Analyseergebnisse nutze ich, um daraus Arbeitspakete zu schnüren und Budgetschätzungen zu erstellen und anzupassen. Wir bündelten die Erkenntnisse in fünf Clustern für Geschäftsmodell, Registrierung sowie Aus- und Weiterbildung, Beratungsprozesse, Produkte und Vergütung. Zusätzlich teilten wir die Handlungsfelder in solche mit IT-Auswirkung und solche ohne ITAuswirkung ein. Die Arbeitsergebnisse ließ ich laufend mit dem Gesamtprogramm und der Rechtsabteilung diskutieren, um stets auf abgestimmten Hypothesen aufsetzen zu können. Aus unseren Arbeiten resultierten erhebliche neue fachliche Anforderungen, die sich in prozessualen und inhaltlichen Auswirkungen auf Seiten der IT-Systeme niederschlagen würden. Diese Anforderungen waren unter anderem neue Informationspflichten, Offenlegung von Art und Quelle der Vergütung, Ausweitung der Beratungs- und Informationspflichten – speziell für den Vertrieb von Versicherungsanlageprodukten. Das deutsche Gesetz brachte auch Anforderungen, die in der EU-Richtlinie IDD nicht angelegt sind, mit sich. Für Restschuldversicherungen wurden zusätzliche Transparenzvorschriften und Maßnahmen eingeführt, die den Vertrieb verbraucherfreundlicher gestalten sollten. Damit sollte sichergestellt sein, dass bei Beratung und Vermittlung auch künftig Kundenbedürfnisse und Produktqualität im Mittelpunkt stehen und die Versicherungen zu den Wünschen und Bedürfnissen der Kunden passen, die sie abschließen. Den durch die Digitalisierung veränderten Kundenerwartungen – insbesondere an den Online-Vertrieb – wurde das Gesetz nur teilweise gerecht. Es führte eine Beratungspflicht für Versicherer im Fernabsatz ein. Diese Anforderung stellte uns gerade für die Onlinetochter der Bank vor große Herausforderungen, da die Kunden die Antragsstrecke beratungsfrei selbst durchliefen. Immerhin können Kunden im Fernabsatz ohne Medienbruch auf die Beratung verzichten – beispielsweise per E-Mail oder Online-Formular. Das Design dieses Prozesses und insbesondere die Abstimmung der finalen Ausprägung mit der Rechtsabteilung waren für unser Programm sehr aufwändig. Die Abstimmung mit Vertriebspartnern der Bank, wie Finanzvertriebe und Vergleichsportale, war ebenfalls ein großes Arbeitspaket in meinem Programm. Die Schwierigkeit lag insbesondere darin, dass sich die spezialisierten Einheiten noch nicht mit der Versicherungsvertriebsrichtlinie auseinander gesetzt hatten. Dies war der Fall, da diese Vertriebspartner regelmäßig kürzere Umsetzungsund Releasezyklen haben als eine große Bank. Daher ließ ich unsere Annahmen mit der Rechtsabteilung abstimmen und über das jeweilige Kooperationspartnermanagement mit den Vertriebspartnern kommunizieren. In den Fachkonzeptionen ließ ich zusätzlich Alternativlösungen beschreiben für den Fall, dass sich die Vertriebspartner im Zuge ihrer IDDProjekte für eine andere als die abgesprochene Vorgehensweise entscheiden müssten. Ein weiterer großer Punkt der IDD war das Thema Qualifizierung. Jeder Vertriebsmitarbeiter muss eine ausreichende Qualifizierung nachweisen und sich regelmäßig weiterbilden. Dies müssen die Unternehmen sicherstellen. Mitarbeiter, die die Basisqualifizierung oder Weiterbildung nicht nachweisen können, dürfen keine Versicherungsprodukte mehr verkaufen. Dies hatte unmittelbare Auswirkungen auf die Prozesse und Systeme der Bank. Ich ließ ausarbeiten, wie sich diese Anforderungen organisatorisch und technisch abbilden ließen und die Lösungen in den Fachkonzepten beschreiben. Für die Mitarbeiter der Bank ließ ich dieses Themengebiet intern abdecken und alle Erfordernisse sicherstellen. Für die Mitarbeiter externer Vertriebseinheiten war das Thema sehr komplex. Ich stelle sicher, dass sich die Fachseite gemeinsam mit dem Kooperationspartnermanagement und der Rechtsabteilung abstimmten, einen Lösungsansatz ausarbeiteten und mit den Vertriebspartnern abstimmten. Ein weiterer großer Arbeitsblock, den ich im Programm abarbeiten ließ, war die Kooperation mit dem Produktpartner. Die Bank selbst ist nicht Produktgeber für die Versicherungsprodukte. Die Versicherungen werden von einem Produktgeber, einer großen Versicherung, gestellt. Die Bank selbst handelt als Vertriebspartner und hat selbst wieder Vertriebspartner. Diese Aufstellung verursachte eine hohe Komplexität, da unter anderem die rechtlichen Konstrukte der Vermittlerketten oder Gruppenversicherung zu beachten waren.
Hinzu kam, dass der Produktgeber viele Druckstücke, wie beispielsweise Produktinformationen, bereitstellt. Meine Teams hatten bereits identifiziert, dass eine große Zahl von Druckstücken und Vertragsunterlagen im Zuge der IDDUmsetzung angepasst oder neu erstellt werden mussten. Daher ließ ich einen Jour Fixe mit dem Produktgeber einrichten und das Team für das Outputmanagement der Bank mit einbeziehen. Ferner mussten wir die technische Schnittstelle zur Versicherung beachten. Es existiert eine bidirektionale Schnittstelle zwischen Bank und Versicherung. Diese enthielt alle auch zukünftig notwendigen Daten, so dass ich im Zuge des Programms die Schnittstelle nicht anpassen lassen musste. Trotz aller Unsicherheiten konnte ich mit meinen Teams die Aufgaben der IDDUmsetzung im Rahmen des Programms gut vorantreiben. Alle erforderlichen Fachkonzepte konnten von meinen Teams erstellt werden. Zur finalen Qualitätssicherung hatte ich eine Prüf- und Korrekturschleife nach Inkrafttreten des Gesetzes eingeplant. So war es uns möglich, alle Konzepte nach deren Abnahme zur Umsetzung an die IT und die externen Vendoren zu übergeben und die fachliche Programmphase erfolgreich abzuschließen.
Projektkontext:
Die derzeitige Automatisierungsplattform sollte auf Basis einer Initiative des Group Chief Operating Officers abgeschaltet werden, um die Anzahl der Betriebssysteme zu reduzieren. Der Bereich Lending musste daher seine Applikationen, insbesondere die Kreditanwendungen und Applikationskomponenten, die derzeit in der bestehenden Umgebung betrieben wurden, auf eine neue technische Plattform migrieren. Dazu wurde im Jahr 2016 eine Bestandsaufnahme durchgeführt, um die betroffenen Systeme und Komponenten zu identifizieren, zu katalogisieren und zu priorisieren. Dabei wurden die Anwendungen in 9 Cluster zusammengefasst, um sie gruppenweise umzustellen. Parallel dazu wurde die neue Automatisierungsplattform als Infrastrukturkomponente implementiert und für die Übernahme der Systemcluster vorbereitet. Anfang 2017 war die Plattform vollständig betriebsbereit und die Migration konnte beginnen.
Projektaufgabe:
Mein Team und ich übernahmen die Umstellung eines der neun Cluster für das System einer der beiden großen Consumer Finance Kreditanwendungen. Dafür ermittelten wir für das Online Kreditsystem an Hand von Dokumentationen, Systembeschreibungen und Handbüchern die dazugehörigen Prozesse, Schnittstellen und verbundene Systeme. Die Ergebnisse konsolidierten wir und nutzten sie zusätzlich zum Erstellen der erforderlichen Projektund Antragsdokumente wie Onboardingformulare oder Servicetickets. Da erfahrungsgemäß der Dokumentationsstand vom tatsächlichen Zustand der Systeme abweicht, ließ ich den Sourcecode, die Jobketten und Logfiles analysieren, um Vollständigkeit und Richtigkeit der dokumentenbasierenden Untersuchung zu überprüfen und zu bestätigen. Dadurch waren wir in der Lage ein aktuelles Bild der von uns umzustellenden Umgebung zu erstellen und die notwendigen Arbeitspakete sowie deren technische und zeitliche Abhängigkeiten zu erkennen und zu planen.
Von unserer Umstellung waren ebenfalls Umsysteme, Datenlieferanten und Datenabnehmer, betroffen. Auf Basis unserer nunmehr aktuellen Systemkenntnis konnte ich auf alle betroffenen Systemverantwortlichen zugehen und unsere Arbeiten abstimmen. So war ich in der Lage einen übergreifenden Projektplan zu erstellen und die Arbeitspakete entsprechend auszurichten. Nachdem mein Team und ich die Vorarbeiten abgeschlossen hatten, begannen wir, die zu migrierenden Prozesse in die entsprechenden Jobketten auf dem Zielsystem zu transformieren. Dabei mussten wir nicht nur die drei Kernprozesse umstellen, sondern auch begleitende Abläufe, wie beispielsweise Housekeeping. Ein Teil der Batchjobs waren bankeigene Entwicklungen, die ich von den internen Entwicklerteams anpassen lassen konnte. Der andere Teil der Automatisierungsskripte war von einem externen Vendor. Da diese Softwarekomponenten unter der Hoheit des Vendors standen, trat ich mit dem Zulieferer in Verbindung und beauftragte die für die Umstellung erforderlichen Anpassungen. Im Zuge unserer Analysen hatten wir einige Punkte identifiziert, die wir verbessern lassen wollten, um das System als Ganzes zu optimieren und zu aktualisieren. Ferner legten wir in der weiteren Abstimmung fest, dass die intern gepflegten Skripte ebenfalls in die Verantwortung des Vendors übergehen sollten. Dazu stimmte ich die kaufmännischen und organisatorischen Rahmenbedingungen ab und veranlasste die Übergabe. Da unser Zielsystem neu implementiert wurde, waren keine Berechtigungen für technische Anwender und personenbezogene User vorhanden. Ich stellte sicher, dass das System im globalen Berechtigungssystem der Bank entsprechend eingebunden wurde, dass die erforderlichen Gruppen und Benutzer samt Berechtigungen eingerichtet und dokumentiert wurden. Zusätzlich ließ ich die erforderlichen Konfigurationen auf dem Golden Host einrichten. Der Golden Host ist ein zentrales Loginsystem, das besonders gesichert ist und den Zugriff auf Zielsysteme kontrolliert. Schlussendlich musste ich sicherstellen lassen, dass die zuständigen Teams des Production Supports Zugang zu allen Systemen, insbesondere auch zur Bedienoberfläche des neuen Automatisierungssystems, eingerichtet bekamen. Nachdem wir alle Berechtigungen sichergestellt hatten und die Skripte auf den Entwicklungssystemen vollständig und fehlerfrei ausführbar waren, bereiteten wir den Systemintegrationstest vor. Dazu ließ ich die Systeme konfigurieren und vorbereiten sowie das Softwaredepolyment einleiten. Dabei musste ich einen weiteren Knackpunkt lösen lassen. Da wir eine Erstinstallation vornahmen, war das zu schnürende Paket zu groß für den Softwareverteilmechanismus. Jedoch gab es genau für solche Fälle einen anderen Prozess, den wir identifizieren und nutzen konnten. Somit konnten wir alle erforderlichen Vorbereitungen erfolgreich abschließen Parallel zum Systemintegrationstest ging ich auf das Testteam zu. Diese Gruppe unterstützt Projekte bei der Durchführung des User Acceptance Tests UAT. Da es sich bei unserer Umstellung um eine rein technische Änderung handelte, konnten wir keine Endanwender aufbieten, die einen fachlich getriebenen Abnahmetest durchführen konnten. Daher nahm ich die Expertise des Testteams für solche Fälle in Anspruch, um anschließend auch die für den Produktivgang erforderliche Produktionsfreigabe erhalten zu können. Ich konnte das Testteam dafür gewinnen, Testfälle für uns durchzuführen, um das UAT-Signoff erhalten zu können. Nachdem wir die organisatorischen Rahmenbedingungen abgeklärt und vereinbart hatten, führte ich zwei Workshops mit meinem Projektteam, den Testern und dem Production Support durch, um zu ermitteln, welche Testfälle für den UAT erforderlich waren und, um diese auszuarbeiten und abzustimmen. Am Ende des Zweiten Workshops hatten wir ein Set von Testfällen für Positiv- und Negativtests erarbeitet. Die Positivtests sollten das korrekte Systemverhalten im Erfolgsfall prüfen und belegen. Die Negativtests sollten sicherstellen, dass sich das System im Fehlerfall, beispielsweise bei einem Abbruch, wie gewünscht verhält. Dazu gehörten unter anderem, dass automatisiert Tickets erstellt und der richtigen Assignmentgruppe zugewiesen werden und, dass das Supportteam die Möglichkeit hatte, abgebrochene Prozesse erneut zu starten. Den UAT Testbeginn plante ich unmittelbar nach Pfingsten. Jedoch führten Krankheiten und Unfälle zum fast vollständigen Ausfall der für die Testdurchführung eingeplanten Personen, so dass wir erst zwei Wochen später mit dem UAT beginnen konnten. Dies hatte auch zur Folge, dass ich den Produktivnahmetermin nach hinten verschieben musste. Ich konnte sicherstellen, dass alle erforderlichen Personen am neu geplanten Zieltermin verfügbar waren. Hinzu kam, dass wir mit unserm Golivetermin unabhängig von anderen Releaseterminen waren und ich daher unkompliziert den zeitlichen Verlauf des Projektes abstimmen und anpassen konnte. Der zweite Anlauf des UAT war ein Jumpstart. Mein Team war in der Lage, gleich am ersten Tag alle Positivtests durchzuführen. Auf unserer Seite liefen alle Jobketten ohne Abbruch und fehlerfrei. Auch die Datenübertragung zum Datawarehouse funktionierte. Lediglich das dort nach der Datenübertragung anzustoßende Postprocessing startete nicht. Ich ließ eine Team übergreifende End-to-End-Analyse durchführen. Dabei identifizierten wir ein interessantes Berechtigungsproblem, das ich beheben ließ. Die daraus gewonnenen Erkenntnisse nutze ich, um das Vorgehen für die Produktivnahme anzupassen. Die Durchführung der Negativtests gestaltete sich dagegen schwieriger. Die Prozesskette arbeitete zuverlässig und brach an der gewünschten Stelle, wie vorgesehen, ab. Der Fehler löste auch plangemäß die gewünschten Notifications und Tickets aus. Jedoch konnten wir, nach Beseitigung des Abbruchpunktes im Ablauf, die Jobs nicht wieder starten. Dazu veranlasste ich die zur Fehlerbehebung notwendige Analyse. Mein Team ermittelte, dass der Fehler durch den Versionsstand der Software bedingt war. Vor Beginn unseres UAT wurde das System auf die neueste Softwareversion umgestellt. Nachdem wir das System auf Basis der Analyseergebnisse parametrisiert hatten, konnten wir die Negativtestfälle ebenfalls ausführen und dabei gezielt abgebrochene Prozesse wieder starten. Das ermöglichte es uns, alle Negativtest erfolgreich abzuschließen. Für unsere Tests hatten wir nur für einzelne Tage die alten Prozesse ausgeplant und durch die neuen Prozesse ersetzt. Nachdem alle Testfälle erfolgreich absolviert waren, ließ ich das UAT System komplett auf den neuen Belieferungsweg umstellen, um auszuschließen, dass die alten Prozesse nachträglich Fehler der neuen Prozesse korrigierten. Diese Umstellung verlief problemlos und belegte, dass die neuen Prozesse optimal die alten Prozesse ersetzen konnten. Da wir die Prozesse verbessert und optimiert hatten sowie vollständig an den Vendor übergeben hatten, ließ ich eine Softwarelieferung vom Zulieferer durchführen, um diese über den geregelten Deploymentprozess auf der UAT Umgebung einzuspielen. Danach veranlasste ich einen Regressionstest, um sicherzustellen, dass nach wie vor alle Prozesse fehlerfrei und voll funktional abliefen. Dies war der Fall und ich konnte von allen erforderlichen Parteien das für die Produktionsfreigabe erforderliche UAT-Signoff erhalten. So konnte mein Team kurz darauf die abschließende Umstellung des Produktivsystems auf die neue Automatisierungsplattform vornehmen und das Projekt erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Onlinekreditsystem im Bereich Lending Consumer Finance. Über dieses System werden bis auf Baufinanzierungen alle Privatkredite abgewickelt, die über eine Onlinestrecke in die Bank prozessiert werden. Angebunden sind somit alle Onlineangebote der Bank, ihrer Töchter sowie Vertriebspartner und Vergleichsportale. Dieses System wird ständig verbessert und erweitert. Die dabei entwickelten Softwarekomponenten werden im Zuge von großen Releases in Produktion gebracht.
Projektaufgabe:
Die Arbeiten am Release waren bei meinem Eintreten bereits in vollem Gange und wurden von einem Projektleiter hervorragend organisiert. Jedoch sollte dieser Projektleiter auf Grund der damaligen Umorganisation absehbar nicht mehr zur Verfügung stehen. Daher sollte ich diese Funktion übernehmen und in einer der Aufgabe angemessenen Übergangsphase von 6 Wochen in das komplexe Umfeld eingewiesen werden, um einen reibungslosen Wechsel zu gewährleisten. Tatsächlich stand dann nicht einmal die halbe Zeit für die Übergabe zur Verfügung, da der bisherige Projektleiter früher ausschied. So übernahm ich die Projektleitung mit dem Eintreffen der ersten Softwareanlieferung der beiden externen Vendoren. Ein Vendor liefert die Komponenten für den Frontendteil der Anwendung, der andere die Bestandteile für das Backendsystem. Die Softwarelieferung galt es nun über die definierten Wege auf den Systemen einzuspielen und testen zu lassen. Ich koordinierte die Qualitätskontrolle der Software, das Deployment über die verschiedenen Stufen der Implementierung sowie die technischen und fachlichen Tests mit allen im Projektprozess involvierten Parteien. Ursprünglich war das Release als eine rein technische Version geplant. Jedoch wurde auf Grund fachlicher Notwendigkeiten zusätzlich die Aufnahme fachlicher Funktionalitäten priorisiert. Daher hatte der vorherige Projektleiter vier, bei Bedarf fünf, Zyklen für Softwareanlieferung, Deployment und Test eingeplant. Schon nach der zweiten Lieferung erkannten wir, dass die Anzahl der Zyklen möglicherweise nicht ausreichen könnte, da eine für die Umsetzung der fachlichen Anforderungen notwendige Anbindung eines externen Webservices eine Vielzahl an Problemen und daraus resultierenden Defects verursachte. Aus diesem Grund trat ich in die enge Abstimmung mit den Vendoren ein, um dieses Thema voranzubringen. Zu diesem Zeitpunkt war es ein Showstopper und für das Release produktivnahmeverhindernd. Ich sicherte die vollständige Unterstützung der Softwarelieferanten und stellte intern sicher, dass zusätzliche Zyklen für Softwareanlieferung, Deployment und Test ermöglicht wurden. Dadurch verdichtete sich mein Projektplan erheblich. Durch die zusätzliche Aufnahme der fachlichen Themen in das Release resultierte ein weiteres Problemfeld. Die Erstellung der für die Kreditabschlüsse erforderlichen Unterlagen, beispielsweise Checklisten, Produktinformationsblätter, Verträge, stellte sich im Test als stark fehlerbehaftet heraus. Vertragsunterlagen, die nicht korrekt sind, sind ebenfalls ein Showstopper und für das Release produktivnahmeverhindernd. Somit hatte ich ein zweites großes Themengebiet, das ich in Ordnung bringen lassen musste, um das Release erfolgreich in Produktion bringen zu können. Zur Lösung dieser Fehlerpunkte führte ich Workshops mit dem Fachbereich, den externen Vendoren und dem bankinternen Team für das Outputmanagementsystem durch. Wir ermittelten in Analysen die Fehlerursachen, konnten die Fehlerbehebung spezifizieren und die Umsetzung bei den externen Vendoren beauftragen. Jedoch griff unser erster Lösungsansatz auf Grund der Komplexität in diesem Umfeld nicht vollumfänglich. Ich musste weitere Iterationen zur Fehlerbehebung moderieren und umsetzten lassen. Zusätzlich stellte ich intern sicher, dass weitere Zyklen für Softwareanlieferung, Deployment und Test ermöglicht wurden. Diese Zyklen brachte ich in Synchronisation mit den durch den anderen Showstopper erforderlich gewordenen Zyklen, um die ohnehin stark belasteten Projektmitarbeiter für beispielsweise Deployment und Test möglichst wirkungsvoll einzusetzen. Dadurch verdichtete sich mein Projektplan zusätzlich. Im Zuge dieses ursprünglich rein technisch geplanten Releases sahen wir vor, einige Technologieupgrades vorzunehmen. Dazu hatten wir unter anderem Upgrades für die Application Server und Oracle Datenbanken geplant. Die Application Server wurden von bankinternen Teams betreut, die Oracle Datenbanken von einem externen Dienstleister. Das Upgradevorgehen war derart in die Liefer- und Testzyklen eingeplant, dass wir sicherstellen konnten, dass die technischen Infrastrukturveränderungen keinen Einfluss auf die technische Funktion und die fachliche Funktionalität des Systems haben. So führten wir die Technologieupgrades im Umfeld des ersten Softwarelieferungszyklus durch. Als erstes System stellten wir die Integrationsumgebung um und testeten ausführlich. Die Tests attestierten, dass alles in bester Ordnung war und wir promoteten die Upgrades auf die UAT-Umgebung. Auch hier ergaben die Tests keine Auffälligkeiten. So konnten wir sicherstellen, dass die technischen Infrastrukturveränderungen keinen Einfluss auf die technische Funktion und die fachliche Funktionalität des Systems haben. Die Umstellung der Produktionssysteme plante ich mit dem GoLive des Releases vornehmen zu lassen. Jedoch führte die Bank eine Reduzierung des Tagessatzes für die meisten externen Mitarbeiter im Zuge von Einsparmaßnahmen durch. Dies führte dazu, dass externe Mitarbeiter die Bank verließen, unter anderem auch mein Projektmitarbeiter, der die Schnittstelle zum externen Dienstleister bezüglich des Oracleupgrades war. Ein Ersatz für diesen Mitarbeiter oder einen Stellvertreter gab es nicht. Damit war ein GoLive, wie geplant, Anfang April nicht mehr möglich. Ich setzte alle Hebel in Bewegung, um einen Oracleupgrade durchführen lassen zu können, leider ohne Erfolg. Damit ergaben sich genau zwei Alternativen. Zum einen konnten wir mit dem GoLive eine unbestimmte Zeit warten, bis das Oracleupgrade von einem neu zu rekrutierenden Mitarbeiter durchgeführt werden konnte. Oder, wir führten den GoLive ohne das Datenbankupgrade durch. Ich veranlasste eine Unbedenklichkeitsprüfung hinsichtlich der Option des GoLives ohne Datenbankupgrade bei den Datenbankspezialisten und den Vendoren. Nach Erhalt aller Unbedenklichkeitsbescheinigungen, entschlossen wir uns, den GoLive entsprechend durchzuführen und ich plante die Produktivnahme in Abstimmung mit allen Stakeholdern auf Anfang Mai um. Inzwischen ließ ich mit Hochdruck weitertesten und Fehler beheben, denn bis Anfang Mai war nur noch eine kurze Zeitspanne. Nach dem achten Softwarelieferungszyklus konnten alle Retests erfolgreich durchgeführt und alle verbleibenden Defects geschlossen werden. Auch den erforderlichen Last- und Performancetest konnte ich mit einigen Iterationen ebenfalls erfolgreich durchführen lassen. Mein Team hatte gemeinsam mit den externen Vendoren das unmöglich erscheinende möglich gemacht. Chapeau! Das für die Produktivnahme erforderliche UAT-Signoff erhielt ich für alle 41 Releasescopeitems ohne Einschränkungen im Rahmen einer Telefonkonferenz mit schriftlicher Emailbestätigung am Nachmittag vor dem für unser Projekt letztmöglichen Termin des Change- und Releaseboards. Das UAT-Signoff ist Voraussetzung für die Teilnahme am Change- und Releaseboard, die Freigabe des Change- und Releaseboards ist Voraussetzung für den GoLive. Somit erhielten wir alle erforderlichen technischen und formalen Freigaben punktgenau zu unserem GoLive Termin. Inzwischen hatte ich alle Vorbereitungen für das Deployment und den GoLive von den Exekutoren und dem Application Owner detailliert planen und abstimmen lassen. Zusätzlich hatte ich die Vendoren für Rufbereitschaft am Releasewochenende beauftragt und sichergestellt, dass alle notwendigen Parteien informiert und involviert sind. Anfang Mai führte mein Team die Produktivnahme erfolgreich durch. Alle Anwendungskomponenten wurden wie geplant vollständig installiert und in Betrieb genommen. Die Technology Upgrades von Weblogic, Java und Tomcat wurden deployed. Die Businessverifikation wurde ohne Auffälligkeiten erfolgreich durchgeführt. Lediglich einige kleine technische Fehler ohne Business Impact hinsichtlich Systemmonitoring und Überwachung waren am Releasewochenende direkt nicht zu beheben. Diese Restarbeiten ließ ich im Zuge einer Nachbetreuung in der Folgewoche durchführen. So konnte ich das Projekt Produktionsrelease des Onlinekreditsystems Consumer Finance exklusiv Datenbankupgrade Mitte Mai erfolgreich abschließen. Nachrichtlich: Ende Mai stand ein neuer Mitarbeiter für das Oracleupgrade zur Verfügung und ich konnte das Upgrade auf Mitte Juli planen.
Projektkontext:
Die Abteilung des Kunden bearbeitet Dienstleistungsaufträge mit Schwerpunkt Sicherheit. Dabei wird fokussiert auf Protection (Schutz, gestützt auf Softwarewerkzeuge), Detection (Erkennung, gestützt auf Methodik) sowie Reaction (Gegenmaßnahmen, gestützt auf Automatisierung). Die Aufgaben sollen konform zum Code of Business Conduct des Kunden gelöst werden. Je nach Aufgabe und Erfahrungshintergrund hat jeder Mitarbeiter eine individuelle Vorstellung der zur Aufgabenerledigung geltenden Vorgehensrichtlinien.
Projektaufgabe:
Ziel waren die Strukturierung des Ansatzes sowie Erarbeitung eines Grobkonzeptes für die Aufgabenerledigung der Mitarbeiter bei der Dienstleistungserbringung gegenüber den internen Kunden, den anderen Abteilungen, mit Schwerpunkt auf Beratung. Der interne Kunde soll eine echte Unterstützung ohne unnötigen Mehraufwand und eine strukturierte, nachvollziehbare Vorgehensweise empfinden. Dabei soll das Unternehmen einen chronologisch nachvollziehbaren Mehrwert erhalten, die Beratungsergebnisse digitalisiert erarbeitet und der Fortschritt dargestellt werden. Der Ansatz sollte sich am Vorgehen des Design Thinking, angepasst als Security Thinking, ableiten. Insbesondere sollte dabei geklärt werden, welche Fragen und Rahmenbedingungen sich daraus ableiten. Um dieses Ziel zu erreichen, bereitete ich einen Workshop zum Vorstellen des Design Thinking Prozesses vor. Dabei erarbeite ich, dass Design Thinking auf interdisziplinäre Teams, Visualisierung und klar umrissene Schritte zur Ideenfindung setzt. Im Design Thinking Prozess werden Probleme gelöst und durch kreative Techniken zielgerichtet Innovationen entwickelt, bei denen betriebswirtschaftliche Faktoren wie unterschiedliche Stakeholder oder Umsetzungsfähigkeit in den Problemlösungsprozess einbezogen werden. Die Methode des „Design Thinking“ stellt einen exzellenten Ansatz dar, sowohl Produkte als auch Services zu entwickeln, die am Menschen und dessen Bedürfnissen orientiert sind. Im Workshop und in Gesprächen mit den Mitarbeitern der Abteilung diskutieren wir den derzeitigen Beratungsprozess und spielgelten ihn als Security Thinking Prozess, um Ansatzpunkte abzuleiten und Handlungsfelder auszuarbeiten. Ergebnisse waren, dass wir erkannten, dass das Wertvolle und die Herausforderung ein Team aus verschiedenen Disziplinen, Abteilungen, Hierarchieebenen in einer absoluten Ergebnisoffenheit sind. Daraus leiteten wir unter anderem ab, dass eine stärkere Einbindung der internen Kunden in den Prozess ergebnisentscheidend ist. Hierbei steigern sich Wirkung und Effizienz durch den Einsatz der Iteration. Dabei kann aber nicht sichergestellt werden, dass jeder Beteiligte durchgängig den Prozess begleitet. Daraus entsteht beispielsweise auch ein Wechselspiel aus aktiver Mitarbeit und Interpretation des Dokumentierten und erfordert eine Offenheit gegenüber der Abfolge der Prozessschritte, die auch ineinandergreifen können. Dies führte zur Erkenntnis, dass Sehen den Lösungsfindungsprozess intensiviert und, dass in jeder visuellen Form Wissen und Problemlösungen enthalten sind und deswegen Visualisierungsformen so wertvoll sind. Ergebnis auf Basis dieser Erkenntnis war ein Modell zum Erweitern der bisherigen Dokumentations- und Kommunikationsformen. Die bestehende Dokumentation war bereits sehr ausgereift und sollte erweitert werden, um stärkere Transparenz zu erreichen und jederzeit reportingfähig zu sein. Durch technische Unterstützung sollte der Zusatzaufwand minimiert werden.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war eine Vielzahl umzusetzender kleiner und geringfügiger Anforderungen. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Das Workflowsystem bestand bereits über acht Jahre. In dieser Zeit wurde es stetig durch Projekte, Upgrades oder Systemumstellungen erweitert oder verändert. Im Zuge dieser Aktivitäten können Fehler auftreten, die nicht gravierend sind und daher nicht zeitnah behoben werden können oder müssen. Oder, es können geringe funktionale Fehler vorhanden sein. Oder, es resultiert eine erweiterte Anforderung, die zusätzlich umgesetzt werden soll. Oder, die Anforderung konnte in einem Release nicht mitabgedeckt werden. Diese Erweiterungen oder Anforderungen sollten in Systemanpassungen oder Erweiterungen umgesetzt werden, die die Fähigkeiten des Workflowsystems erhöht und verbessert. Diese Verbesserungen sollten beschrieben, mit dem Fachbereich priorisiert und im Zuge des Majorreleases umgesetzt werden. Ich hatte in diesem Fall 22 Small and Minor Enhancements . (SME). Diese SME bewertete ich in einer ersten Iteration mit dem Leiter der Entwicklung sowie den für diese Themenbereiche zuständigen Lead Business Analysten.Anschließend priorisierte ich diese SME in einem weiteren Schritt mit dem Fachbereichskoordinator. Damit erreichte ich eine Vorsortierung, die es den tatsächlich betroffenen Fachbereichen erleichtert, die endgültige Priorisierung vorzunehmen. Insbesondere stellte ich mit diesem Priorisierungsprozess sicher, dass alle wirklich wichtigen SME im Rahmen des dafür bereitgestellten Budgets umgesetzt werden konnten. Durch die Priorisierung mit dem Fachbereichskoordinator konnten wir die Liste der SME auf 19 Stück reduzieren. Diese SME stimmte ich mit den Fachbereichen ab. Daraus erarbeiteten wir eine abgestimmte Liste von 14 SME, die die wichtigsten Erweiterungen und Fehlerbehebungen abdeckten und im Rahmen des Budgets umgesetzt werden konnten. Diese 14 SME ließ ich spezifizieren, entwickeln und testen. Parallel dazu stimmte ich mit dem Releasemanager die Aufnahme dieser SME in den Releaseprozess ab. Anfang November brachte ich diese 14 SME im Zuge des Majorreleases erfolgreich in Produktion.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt waren die Erkenntnisse, die im Zuge des Projektes 50 „Digitalisierung – Vorstudie für eine Notfallinfrastruktur für das zentrale Workflowsystem der Bank“ gewonnen wurden. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Aus den Erkenntnissen wählten wir die Ansätze aus, die die größte Wirkung versprachen. Durch die Maßnahmen sollten die Geschäftsauswirkungen durch System- oder Komponentenausfälle verringert oder vermieden werden. Ebenfalls sollten die Startzeiten des Workflowsystems verringert und Probleme beim Wiederanlauf vermieden werden. Daraus leiteten wir drei Handlungsfelder ab. Das erste Handlungsfeld konzentrierte sich den Autostart der TibcoKomponenten Business Works (BW), iProcess und Enterprise Message Service (EMS) . Das zweite Handlungsfeld fokussierte auf die Desaster Recovery Fä- higkeiten des Systems. Dazu sollten insbesondere die Wiederanlauffähigkeit von Services optimiert und die Wiederverbindung zu Datenbanken sichergestellt werden. Das dritte Handlungsfeld sollte die Anzahl der CaseStarter und RequestFeeder Instanzen reduzieren, diese umfangreich konfigurierbar und insbesondere sicherer machen. In diesem Zuge sollte auch das Reporting. über Tibco Spotfire an die erweiterten Fähigkeiten der CaseStarter und RequestFeeder angepasst werden. Damit ich sicherstellen konnte, dass sich alle Maßnahmen ergänzen und nicht gegenseitig unmöglich machen, habe ich zusätzlich zu den Jour Fixes der Einzelstränge übergreifende Abstimmungstermine einberufen. Dieser Ansatz hat sich als sehr hilfreich herausgestellt, da der Kreis der Stakeholder komplex war. Zudem benötigten wir für alle Themenbereiche übergreifende Instanzen, wie beispielsweise das Deployment-, Test- oder Releasemanagement , die damit wirksam eingebunden wurden. Mir als Projektleiter erleichterte der integrative Ansatz die Ressourcenplanung und das Budgetmanagement .
Autostart:
Für den Autostartbereich entwickelten wir mehrere Lösungsansätze . Diese stimmten wir mit den Architekten, Application Ownern und Production Support ab . Dazu führte ich mehrere Lösungs- und Abstimmungsworkshops durch. Die Ergebnisse der Arbeitsmeetings flossen direkt in die Lösungsentwicklung ein. Daraus erarbeiteten wir einen mehrstufigen Lösungsansatz. Wir entwickelten ein Autostartframework , das im Zuge eines Systemstarts aktiviert werden sollte. Dieses Framework stellt sicher, dass die TibcoKomponenten Business Works, iProcess und Enterprise Message Service ordnungsgemäß gestartet werden. Dazu sollte das Framework die bereits im Einsatz befindliche Komponente Tibco Hawk , ein Werkzeug zur Überwachung und regelbasierten Steuerung von (Tibco-) Services, ansprechen und nutzen. Ein Teil der dafür erforderlichen Hawkregeln war bereits vorhanden. Einige fehlerhafte Regeln musste ich korrigieren sowie noch nicht vorhandene Regeln entwickeln und testen lassen. Dabei erkannten wir, dass zusätzliche nicht-Tibco Komponenten für einen erfolgreichen Autostart ebenfalls erforderlich sind. Diese Services ließ ich genauso durch Hawkregeln starten, um einen vollständigen Systemstart sicherstellen zu können. Während der Umsetzung der Autostartregeln für BW und EMS erkannten wir, dass wir für iProcess nicht ohne Unterstützung von Tibco auskommen würden. Daher klammerten wir den Autostart von iProcess aus und planten die Umsetzung in einem Folgeprojekt im nächsten Jahr. Das Autostartframework sowie die Autostartregeln für BW und EMS implementierten wir erfolgreich.
Wiederanlauf:
Zur Problemanalyse beim Wiederanlauf von Services ließ ich mehrere Tests durchführen. Schwerpunkt ließ ich dabei auf die Wiederverbindung von Services an Datenbanken legen. Diese Tests sind nicht einfach durchzuführen, da ein zweizügiges System für aussagekräftige Erkenntnisse erforderlich ist. In der Regel verhindern zwei Knoten bereits die meisten Probleme, da erfahrungsgemäß nur ein Knoten von einem Ausfall betroffen ist. Es muss jedoch sichergestellt sein, dass beispielsweise bei Datenbankschwenks die Verbindungen sauber mitgezogen werden oder Komponenten, die nur eine aktive Node erlauben, nicht plötzlich durch zwei aktive Köpfe Fehlerkonstellationen hervorrufen. Vorbereitungen und Entwicklung von Testprogrammen ließ ich auf den einzügigen Entwicklungsmaschinen durchführen. Damit die Tests ausgeführt werden konnten, stimmte ich die Nutzung der zweizügigen Integrationsumgebung mit Test, Entwicklung und Releasemanagement ab. Es gelang mir einen zweiwö- chigen Testzeitraum für die exklusive Nutzung der Integrationsumgebung mit ausreichendem Vorlauf zum Majorrelease auszuhandeln. Da dieser Testzeitraum in der Zukunft lag, ließ ich reguläre und im Rahmen des Releases durchgeführte Desaster Recovery Tests mitnutzen, um bisherige Fehlersituationen zu bestätigen und neue zu ermitteln. Somit konnten wir insbesondere in der Konfiguration von Verbindungsparametern Ansatzpunkte erkennen und mittels Anpassung, beispielsweise der Connection Factories, beheben. Die Wirksamkeit und insbesondere die Unschädlichkeit dieser Maßnahmen konnten wir während der folgenden Tests auf der Integrationsumgebung belegen und sicherstellen. Weitere Fehlersituationen konnten wir nicht feststellen. Dies ließ sich ursächlich auf die in der Zwischenzeit durchgeführten wirksamen Infrastrukturmaßnahmen zurückführen. Die Anpassungen an den Konfigurationen der Verbindungsparameter implementierten wir erfolgreich.
CaseStarter:
4.0 Jeder Eingangskanal des Workflowsystems ist in der Regel über einen CaseStarter und einen RequestFeeder angebunden. Diese Instanzen sind die Schnittstellen zur Außenwelt der Zuliefersysteme. Über diese Eingänge wird das System mit allen Daten und Dokumenten versorgt. Bislang wurde regelmä- ßig jedes Zuliefersystem über eine eigene Instanz angebunden. Damit die Anzahl der CaseStarter und RequestFeeder Instanzen reduziert werden konnte entwickelten wir einen ganz neuen Ansatz und wählten ein agiles, an Scrum angelehntes, Vorgehen mit mehreren Sprints. In Workshops mit Entwicklung, Application Owner, Architektur und Production Support fixierten wir die Anforderungen und Projektziele. Daraus erkannten wir, dass wir umstellen mussten von eingangskanalspezifischen hin zu protokollspezifischen CaseStarter und RequestFeeder Instanzen. Damit konnten wir die Anzahl von 16 auf 5 Einheiten reduzieren. Diese fünf Einheiten für HTTPS, REST, CIFS, sFTP und JMS sollten grundsätzlich im Kern gleich aufgebaut werden. Dabei sollten konfigurierbare Funktionalitäten, wie beispielsweise das An- und Abschalten von Kanälen oder eine Mengenbegrenzung, ebenso implementiert werden wie Sicherheitsprüfungen, etwa Whitelisting oder Token-Prüfung. Die Administration sollte über eine Bedienoberfläche möglich sein, die Konfigurationen sollten in einer unabhängigen Datenbank vorgehalten werden. Auch hier konnte ich Erkenntnisse aus dem Projekt 51 „Digitalisierung – Vorstudie für eine Notfallinfrastruktur für das zentrale Workflowsystem der Bank“ einbringen. Daher ließ ich den Datenstrom der Eingangskanäle duplizieren und eine Sicherheitskopie in einer ebenfalls unabhängigen Datenbank, dem Message Saver, ablegen. Weiterhin nutzen wir die Erfahrung von Releasewochenenden. Zu diesen Terminen wird die reguläre Datenbelieferung abgeschaltet und erst nach erfolgreichem Einsetzen des Releases wieder aktiviert. In der Zwischenzeit müssen jedoch Testfälle prozessiert werden, unabhängig von den gepufferten Eingangsdaten. Dieser Vorgang war jedoch bisher mit viel Aufwand verbunden. Daher optimierten wir den Prozess und implementierten eine Umschaltmöglichkeit, die einen Regelbetrieb und einen Releasemodus anbot. Im Releasemodus können bei abgeschaltetem Eingangskanal dediziert (Test-)Fälle erkannt und gezielt prozessiert werden. Am Ende jedes vierwöchigen Sprints stellten wir die Ergebnisse im großen Stakeholderkreis vor, um Rückmeldungen und Anregungen aufzunehmen und einzubeziehen. Dies führte insbesondere dazu, dass wir die Dokumentenprüfung und den Duplikatecheck deutlich verbessern konnten. Ebenso konnten wir die Priorisierung und Zeitplanung einvernehmlich abstimmen. Daher fokussierten wir uns auf die Umsetzung des CaseStarters HTTPS. Die Entwicklung der Bedienoberfläche, die Erweiterung des Reportings mittels Dashboard und Spotfire sowie die Umsetzung der weiteren protokollspezifischen Eingangskanäle planten wir zum ersten Masterrelease des Jahres 2017 fertigzustellen. Zu diesem Release sollte der erste Eingangskanal ebenfalls auf den neuen CaseStarter 4.0 aufgeschaltet werden und diesen produktiv nutzen. Ende November war die grundlegende Entwicklung abgeschlossen. Wir konnten den HTTPS-Stream testweise vollständig prozessieren. Dabei waren die Komponenten Security Check, Inputchannel Check mit Activity und Threshold, Document Check, Message Saver und Duplicate Check funktional implementiert und konnten Entwicklertestsunterzogen werden. Damit konnte ich die erste Phase des Projekts erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war die Erkenntnis, dass im Zuge des Prozesses durch die Verarbeitung und Konvertierung verschiedener Dateiformate Probleme auftreten. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Projektziel war die Reduzierung und Beseitigung auftretender Fehler auf Grund von verschiedenen Dateiformaten. Dies war insbesondere im Hinblick auf die Digitalisierungsmaßnahmen wichtig, da in diesem Rahmen das papierlose Banking, beispielsweise das maschinelle Erkennen und Auslesen von Dokumenten und Formularen, sowie Robotics im Sinne von Automatisierung, beispielsweise die automatische Übernahme von vorhandenen Daten über technische Schnittstellen inklusive Dunkelverarbeitung von Geschäftsvorfällen, nur bei störungsfreien Prozessen effektiv und wirksam durchgeführt werden können. Zusätzlich mussten wir eine Anzeigeschwäche in der Benutzeroberfläche beseitigen, die durch Probleme in der Darstellung verschiedener Dateiformate auffällig wurde. Dazu planten wir den bisher im Einsatz befindlichen Multiformatviewer durch eine auf ein Dateiformat spezialisierte Anzeigesoftware zu ersetzen.Um diese Aufgaben zu erfüllen, ließ ich von meinen Business Analysten den Prozess analysieren und dokumentieren. Dies insbesondere darauf hin, welche Dateiformate über welche Eingangskanäle zugeliefert und, wie diese im weiteren Prozess verarbeitet werden. Im Zuge dieser Prozess- und Formatanalyse stellten wir fest, dass es durchaus auch Formate gab, die ausschließlich transportiert und nicht angezeigt werden. Diese Formate konnten wir aus der weiterführenden Betrachtung ausschließen. Wichtig dabei war nicht nur die Datenversorgung des Workflowsystems, sondern ebenfalls die Weiterverarbeitungder Daten in Folgesystemen. Besondere Anforderungen identifizierten wir im Bereich Kundenkommunikation und Archivierung. Die Druckstrecke der Bank benötigt ein definiertes Format, damit die Schriftstü- cke optisch einwandfrei im Massendruck verarbeitet werden können. Bei Formatfehlern sieht im besten Fall das Druckstück unschön aus, im schlechtesten Fall bricht die Verarbeitung der Druckstraße ab und hat somit negative Auswirkungen auf andere Druckprozesse. Ebenso stellt das Archivsystem der Bank hohe Anforderungen. Das Zielformat muss beispielsweise archivierungsfähig sein, das heißt, beispielsweise in 30 Jahren anzeig- und verarbeitbar sein. Ebenso muss das Format sicher gegen Manipulationen sein. Die Anforderungen aus Druck- und Archivbereich waren bei der aktuellen Lösung umgesetzt und durften nicht außer Kraft gesetzt werden. Parallel ließ ich die Funktionalitäten des sich im Einsatz befindlichen Viewers analysieren. Es musste sichergestellt werden, dass die einzusetzende Software ebenfalls alle Funktionen bietet, um die bestehenden Arbeitsprozesse vollumfänglich zu unterstützen. Wir identifizierten 79 Funktionen, die nach der Umstellung wieder zur Verfügung stehen mussten. Bei näherer Analyse stellte sich heraus, dass der Viewer selbst davon nur 64 Stück zur Verfügung stellte; die anderen Funktionalitäten wurden vom System zusätzlich bereitgestellt und wä- ren vom Tausch der Anzeigekomponente nicht betroffen. Eine Vorgabe war, dass die neue Anzeigekomponente aus dem Pool der Standardsoftware der Bank stammen musste. Im Rahmen dieser Vorgabe wählten wir eine Software aus. Die Funktionsanalyse ergab, dass damit jedoch nur 52 Funktionen abgedeckt werden konnten. Durch Erweiterung des Frameworks des Workflowsystems konnten wir bis auf 3 Funktionen alle fehlenden Funktionalitäten durch Eigenentwicklungen ergänzen. Meist ergeben sich in solchen Analysephasen weitere Anforderungen das Fachbereichs. Diese sind jedoch in der Regel nicht im Projektumfangvorgesehen. Da ich aber zusätzliche Funktionen im Framework entwickeln lassen musste und 3 bisher bestehende Funktionen nicht abdecken konnte, traf ich mit dem Fachbereich eine Absprache. Wir einigten uns darauf die 3 fehlenden Funktionen durch die zusätzliche Entwicklung von 7 neuen Funktionalitäten überzukompensieren. Neben der reinen funktionalen Abdeckung sollte insbesondere sichergestellt werden, dass die Anzeigequalität deutlich verbessert wird, um auch die Anzeigeschwäche endgültig beheben zu können. Dazu entwickelten wir verschiedene Lösungsansätze. Ein Modell war, die Umstellung aller Eingangskanäle auf das für die Anzeigekomponente erforderliche Zielformat zu betreiben. Damit könnten Prozesse und Anzeige auf nur ein Datenformat optimiert werden. Der Ansatz wurde nicht weiterverfolgt, da eine Vielzahl von Eingangskanälen in zu kurzer Zeit umgestellt werden müssten. Ebenso müsste die Verarbeitung in den Folgesystemen, wie Druckstraße oder Archivsystem, sichergestellt werden. Dieser Ansatz würde den zeitlichen und monetären Rahmen des Projektes sprengen, wurde aber für jede Anpassung oder Neuaufschaltung eines Eingangskanals als strategische Lösung beschlossen. Daher ließ ich ein alternatives Vorgehen ausarbeiten. Rahmenbedingung dabei war, dass die bisherigen Formate beibehalten werden sollten. Ausschließlich für die Anzeige sollten die Formate, falls erforderlich, in das Zielformat der Anzeigekomponente konvertiert werden. Damit reduzierte sich der Scope des Projektes deutlich. Zu diesem Lösungsansatz entwickelten wir grundsätzlich zwei Alternativen. Die Konvertierung zur Ansicht kann zentral oder dezentral erfolgen wenn ein Dokument angezeigt werden muss. Das Workflowsystem wird über die Eingangskanäle versorgt und schreibt alle Dokumente direkt ins Archivsystem. Zusätzlich versorgt es einen Dokumentenspeicher, um die Dokumentenversorgung bei Ausfall oder Performanceengpässen des Archivsystems sicherzustellen. Ein Dokument liegt dann sowohl im Archiv als auch im Dokumentenspeicher vor und muss je nach Prozesskette aus unterschiedlichen Quellen bereitgestellt und angezeigt werden. Damit eine einheitlich gute Anzeigequalität sichergestellt werden konnte, entschlossen wir uns, in einem ersten Schritt einen einheitlichen Konverter dezentral einzusetzen. In einer folgenden Ausbaustufe sollte dieser Konverter zentral als redundanter Service angeboten werden. Somit implementierten wir an zwei verschiedenen Stellen (sowohl für Archivsystem als auch Dokumentenspeicher) einen einzigen Softwarestand des Anzeigekonverters unter Nutzung des Singlesourceansatzes. Da die Bank virtuelle Arbeitsplatzrechner einsetzt, ist es nicht möglich, vorab Last- und Performancetests der Benutzeroberfläche durchzuführen. Um eine erste Einschätzung zu erhalten, haben wir den Konverter getestet und dabei Antwortzeiten mit und ohne Konvertierung verglichen. Die Konvertierung verlängert die Dokumentenauslieferung kaum, da wir diese als Streaming konzipiert und implementiert haben. Somit konnten wir sicher sein, dass die Backendkomponente performant genug war, konnten aber nicht abschließend einschätzen, wie der Gesamtprozess sich verhalten würde. Daher beschlossen wir im Rahmen der Einführungsplanung eine Pilotierung durchzuführen. Damit wollten wir in einer zeitlich begrenzten Phase eine limitierte Anzahl von Benutzern mit dem neuen Systemumfeld arbeiten lassen, um Antwortverhalten und Systemstabilität zu überprüfen. Aus den Ergebnissen wollten wir extrapolieren, wie sich das System nach einer Vollumstellung verhalten würde. Meine Businessanalysten erstellten gemeinsam mit den Fachbereichen ein Einführungskonzept sowie Schulungsunterlagen. Dabei setzten wir auf den Multiplikatorenansatz, denn es waren mehrere tausend Anwender zu schulen. Am ersten Novemberwochenende gingen wir erfolgreich in Produktion und starteten die Pilotphase. Mitte November beendeten wir die Pilotphase erfolgreich. Die Performanz und Stabilität des Systems sind unverändert auf hohem Niveau. Die deutlich verbesserte Anzeigequalität machte sich positiv bemerkbar. Einige kleine Fehler waren noch zu beheben; unter anderem musste auch eine Veränderung am virtuellen Arbeitsplatz vorgenommen werden. Ich ließ die Fehlerkorrekturen erstellen, testen und abnehmen. Da wir gemeinsam mit der Umstellung des virtuellen Arbeitsplatzes die Vollaufschaltung vornehmen mussten, beschlossen wir, mit dem nächsten Release des virtuellen Arbeitsplatzes zum Februar produktiv zu gehen. Damit konnten wir die erste Phase des Projektes erfolgreich abschließen.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war eine Datenbelieferungsstrecke, die nicht mehr den erhöhten IT Security Richtlinien entsprach. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe: Das Workflowsystem wird über eine Vielzahl von Eingangskanälen mit Daten und Informationen versorgt. Auch der papiergebundene Eingangskanal ist an das Workflowsystem angebunden. Über diesem Eingangskanal wird das Workflowsystem unter anderem mit sämtlicher Briefpost der Kunden an die Bank versorgt. Diese Schreiben werden von einem externen Scandienstleister digitalisiert und über eine Datenbelieferungsstrecke dem Workflowsystem zur Verfügung gestellt. Diese Datenbelieferungsstrecke besteht bereits länger. In dieser Zeit wurden IT Security Richtlinien angepasst und die Sicherheitsstandards erhöht. Aus diesem Grund entsprach die Datenversorgung nicht mehr den erhöhten IT Security Anforderungen. Damit die Richtlinien wieder eingehalten werden, musste die technische Ausgestaltung der Datenbelieferungsstrecke angepasst werden. Zusammen mit meinem Team musste ich sicherstellen, dass alle notwendigen Parteien einbezogen wurden. Dies war insbesondere deshalb wichtig, da die Datenbelieferung von einem externen Dienstleister durchgeführt wurde. Daher war eine sichere Datenverbindung zu schaffen, die ein Ende innerhalb des sicheren Banknetzes besitzt, das potentiell unsichere Internet quert und im gesicherten Netz des Dienstleisters endet. Ich ließ alle Rahmenbedingungen ermitteln und von den Spezialisten fünf verschiedene Anbindungsalternativen erarbeiten. Schwerpunkt war, eine sichere Verbindung zu entwerfen, die im bestehenden Systemumfeld wirtschaftlich zu implementieren war. Dabei mussten wir jedoch großes Augenmerk auf die Performance richten, da der Papierkanal sehr großvolumig ist. Wir erarbeiteten für alle fünf Alternativen die technischen und organisatorischen Rahmenbedingungen sowie die dazugehörigen Prozesse. Ebenso ließ ich Performance- und Sicherheitseinschätzungen vornehmen und auch die zugehörigen Projektkosten abschätzen und dokumentieren. Die erstellten Unterlagen übergaben wir dem verantwortlichen Fachbereich im Rahmen einer Lösungspräsentation zur Entscheidung und Beauftragung der Umsetzung.
Projektkontext:
Die Bank betreibt ein zentrales Workflowsystem mit dem alle technisch darstellbaren und automatisierbaren Vorgänge gesteuert und abgewickelt werden. Täglich werden mit diesem System einige Hunderttausend Vorgänge bearbeitet. Auslöser für das Projekt war die Erkenntnis, dass in der Vergangenheit zwischen den technisch vereinbarten und den fachlich zugesagten Serviceleveln Abweichungen bestanden. Im Zuge der Digitalisierung wächst die Bedeutung des Workflowsystems. Insbesondere, da weitere Prozesse und Länder auf diese Infrastruktur aufgeschaltet werden sollten und eine zunehmende Automatisierung (Robotics) sowie eine noch stärkere Unterstützung der digitalisierten Geschäftsprozesse vorgesehen war.
Projektaufgabe:
Die Abweichung traf insbesondere auf kritische Geschäftsprozesse zu, die regelmäßig in kürzerer Zeit abzuwickeln sind als die zugesicherte Wiederherstellungszeit des Systems. Im Falle einer Systemstö- rung oder bei Performanceengpässen wäre somit die Einhaltung der fachlichen Service Level Agreements gefährdet. Da das System grundsätzlich sehr stabil und performant arbeitete sowie in näherer Vergangenheit wirksame Infrastrukturmaßnahmen durchgeführt wurden, bestand kein akuter Handlungsbedarf. Daher konzentrierten wir uns auf strategische Maßnahmen. Mit der Durchführung des Projektes schafften wir die Voraussetzung für organisatorische und prozessuale Verbesserungen und definierten damit die notwendigen Leitplanken und Anforderungen für technische und organisatorische Verbesserungen. Mein Team und ich haben wirksame Alternativprozesse für Systemausfälle definiert, adäquate Ausfallkritikalität und Wiederherstellungszeit abgebildet und damit die Notfallplanung signifikant verbessert. Als ersten Schritt haben wir gemeinsam mit den Fachbereichen eine Businessprozessanalyse durchgeführt und dabei die kritischen Geschäftsprozesse für die einzelnen Geschäftseinheiten identifiziert sowie daraus die Zeitschwelle für kritische Vorgänge abgeleitet. Auf dieser Basis haben wir uns auf Prozesscluster konzentriert, die ein gegenüber den Auftraggebern vereinbartes Servicelevel von kleiner als der definierten Zeitschwelle besitzen. Wir haben dabei die Annahme getroffen, dass die bestehenden Notfallmaßnahmen ausreichend sind, um die Ausfallzeit für die Prozesscluster oberhalb dieser Zeitschwelle hinreichend zu mitigieren. In der Businessprozessanalyse erarbeiteten wir Einzelheiten zu den betroffenen Geschäftseinheiten und Benutzergruppen, den ausgeführten Funktionen und Prozessen, den kritischen Geschäftszeiten sowie internen und externen Abhängigkeiten der Geschäftseinheiten unter Berücksichtigung von weiteren Bereichen der Bank und externen Dienstleistern, von technischen Applikationen und sonstigen technischen Ressourcen. Das Workflowsystem ist über eine Vielzahl von Eingangskanälen angebunden. Über diese Eingangskanäle werden dem System die Vorgänge zugeführt. Dabei kann es sich um kritische oder unkritische Vorgänge handeln. Es existieren Eingangskanäle, die nur kritische, nur unkritische oder kritische sowie unkritische Vorgänge enthalten. Eingangskanäle mit ausschließlich unkritischen Vorgängen wurden von der Analyse ausgenommen. So ermittelten mein Team und ich 23 Prozesscluster mit 29 Businessprozessvarianten, deren Abarbeitung über das Workflowsystem initiiert und begleitet wird. Für jede Businessprozessvariante identifizierten wir Infrastrukturtypen, Hardware und Software, die für die Vorgangsversorgung im Rahmen der Produktionsvorbereitung und des Prozessings über das Workflowsystem erforderlich sind. Wir erkannten 12 Abhängigkeiten zu Infrastrukturtypen. Zusätzlich haben wir weitere sechs IT-Komponenten identifiziert, die zwar für den Ablauf des Bearbeitungsprozesses benötigt werden, aber technisch nicht zum Workflowsystem gehören. Daraus haben wir insgesamt 18 Abhängigkeiten bei den Infrastrukturtypen sichtbar gemacht und davon die Anforderung an die Verfügbarkeit dieser Infrastrukturtypen abgeleitet. In der darauf durchgeführten Geschäftsauswirkungsanalyse haben wir erarbeitet, welche direkten finanziellen und operativen Auswirkungen eine Unterbrechung des Geschäftsbetriebs auf die Geschäftseinheiten hat. Anschließend haben wir Strategien, Ressourcen und Kapazitäten aufgezeigt, die nach einer Geschäftsunterbrechung zur Wiederherstellung des Geschäftsbetriebs auf akzeptablem Niveau benötigt werden. Als zugehörigen Bestandteil der Wiederherstellungsstrategien definierten wir ebenso bewusste Entscheidungen des Managements zur Tolerierung von Risiken und die Akzeptanz möglicher Auswirkungen. Um die Auswirkungen eines Ausfalls der Infrastrukturtypen oder einer fehlenden Verfügbarkeit der Dienstleister je Businessprozessvariante umfänglich zu betrachten und somit die Analyse der Risikosituation abzuschließen, haben wir weiterführende Informationen herangezogen. Dabei haben wir vorrangig Volumen und Abarbeitungsgeschwindigkeit betrachtet, um die Abarbeitungszeiten für die während einer Krise nicht bearbeiteten Vorgänge zu bestimmen. Mit der Geschäftsauswirkungsanalyse erarbeiteten wir eine Einschätzung potentieller direkter finanzieller und operativer Auswirkungen bei einer Unterbrechung des Geschäftsbetriebs der gesamten Geschäftseinheit. Zusätzlich haben wir eine Einschätzung zum finanziellen und reputativen Schaden bei Nichteinhaltung der SLA pro Businessprozessvariante durch die Geschäftseinheiten eingeholt. Den aufsichtsrechtlichen Schaden haben wir nach Abstimmung pauschal für jeden Prozess als gering eingestuft. Anschließend haben wir die Eintrittswahrscheinlichkeit ermittelt. Als Wesentliche Parameter bei der Berechnung der Eintrittswahrscheinlichkeit haben wir die Anzahl der abhängigen Infrastrukturtypen angesehen. Darüber hinaus haben wir das Delta zwischen der durchschnittlichen Wiederanlaufzeit der Infrastrukturtypen gegenüber dem ursprünglichen Servicelevel, welcher dem Auftraggeber gegenüber zugesagt wurde, ins Verhältnis gesetzt. Die Businessprozessvarianten haben wir anschließend gemäß dem Rahmenwerk zur Bewertung von Risiken der Bank strukturiert. Dabei ermittelten mein Team und ich sechs kritische und vier signifikante Prozesscluster, die die Basis aller weiteren Aktivitäten bildeten. Die restlichen Prozesscluster haben wir von der Betrachtung ausgeschlossen. Auf dieser Basis haben wir geeignete Wiederherstellungsstrategien abgeleitet. Dies unter der Prämisse, dass die aktuell vereinbarten Servicelevel als Konstante vorgegeben sind. Daraus haben wir Wiederherstellungsmaßnahmen (BCM-Maßnahmen) abgeleitet, die beschreiben, wie die Geschäftseinheiten ihre kritischen Prozesse während einer Geschäftsunterbrechung fortsetzen und oder wiederherstellen. Wir haben diese BCM-Maßnahmen in vier organisatorische und zwei funktionale Maßnahmen untergliedert. Zur weiteren Projektarbeit haben wir das Gesamtteam auf organisatorische und funktionale Maßnahmen aufgeteilt. Mein Team verantwortete die funktionalen Maßnahmen. Als konkrete BCM-Maßnahme haben wir vereinbart, dass Notfallinfrastrukturen definiert und aufgebaut werden, die beim Ausfall von kritischen Komponenten die Abarbeitung der kritischen Prozesscluster ermöglichten. Zusätzlich sollten zwei weitere organisatorische Maßnahmen technisch unterstützt werden. Dabei haben wir insbesondere auf die identifizierten kritischen Komponenten abgestellt. Diese Maßnahme haben wir für alle Prozesscluster vereinbart, die wir als signifikante und kritische Risiken eingestuft haben. Damit wir sicherstellen konnten, alle Anforderungen zu erfassen, haben wir die Prozesscluster in Use Cases unterteilt und beschrieben. Daraus haben mein Team und ich gemeinsam mit den Fachbereichen die Anforderungen ermittelt und dargestellt. Dazu haben wir mehrere Workshops mit allen Stakeholdern durchgeführt. Auf Basis der abgestimmten Requirements habe ich IT-interne Lösungsworkshops durchgeführt. Dabei haben wir zuerst Architekturrichtlinien erarbeitet. Beispielsweise sollte die Notfalllösung systemisch unabhängig vom bestehenden Workflowsystem sein und daher keine seiner Komponenten, beispielsweise die Tibco Workflowengine, verwenden und damit auch keine zusätzliche Komplexität im Workflowsystem erzeugen oder die Stabilität sowie Performance beeinträchtigen. Daraus leiteten wir ab, dass es ein Auftragsduplikat geben musste und das Versenden des Auftragsduplikats direkt von der Quelle übernommen muss. Eine weitere Vorgabe war, dass nur Standardinfrastruktur der Bank genutzt werden sollte. Zusätzlich sollten wir ausarbeiten, welche Arbeitspakete und Kosten entstehen würden, wenn das vorhandene Workflowsystem dupliziert und als Notfallinfrastruktur implementiert werden würde. Auf dieser Basis erarbeiteten mein Team und ich eine Notfallinfrastruktur aus funktionalen Blöcken, wie beispielsweise einem Duplikator für Eingangskanäle, die nur ein Ziel beliefern können (7 verschiedene Ansätze), einem Identifikator zum Erkennen von beispielsweise Kritikalität oder Auftragstyp (2 verschiedene Ansätze), einer Komponente zur Vorgangsbearbeitung (3 verschiedene Ansätze) oder einem Modul zum Krisenabschluss (2 verschiedene Ansätze). Daraus leiteten wir einen technischen Lösungsansatz auf Basis von Bankstandardinfrastruktur ab und erarbeiteten detailliert die Anbindung und Datenflüsse der Notfallinfrastruktur. Anschließend führten wir eine Prüfung durch, ob die Annahmen, die im Lösungsvorschlag getroffen wurden, mit der Standardinfrastruktur erfüllt werden können. Im Zuge der Prüfung stellten wir fest, dass unsere Lösungsansätze bei genauer Analyse mit Standardinfrastruktur nicht umzusetzen waren. Wir mussten beim Systemdesign drei Ansätze für die Notfallinfrastruktur sowie für den Datentransport und für die Logik fünf Ansätze auf Basis von Standardinfrastruktur erarbeiten. Die Gründe dafür, dass die jeweils betrachtete Standardinfrastruktur schlussendlich doch nicht in Frage kam waren, dass wir sehr viele Daten, Daten mit großem Volumen und Daten in hoher Frequenz zu verarbeiten hatten. Da mit dem erforderlichen Mengengerüst und zeitlichen Profil die Nutzung von Standardinfrastruktur nicht möglich war, stimmte ich mit Architektur und Management einen Lösungsansatz auf Basis einer Eigenentwicklung ab. Diesen Lösungsansatz verfeinerten wir und erstellten eine detaillierte Anforderungsspezifikation sowie eine Systemarchitektur. Parallel zur technischen Lösungsfindung erstellte ich zu jedem Lösungsansatz einen Zeitplan für die Durchführung sowie eine umfangreiche Kostenkalkulation. So erstellte ich eine Kalkulation für die Dopplung des vorhandenen Workflowsystems sowie acht Kalkulationen unterschiedlicher Granularität für die jeweiligen Lösungsalternativen. Zu jeder Lösungsalternative ermittelten wir die Anforderungsabdeckung, um sicherzustellen, alle notwendigen Requirements der Fachbereiche abzudecken. Lösungsansätze, Zeitpläne, Kostenkalkulationen und Anforderungsabdeckungen stellten wir in Workshops dem Fachbereich und beim Management vor, um die erforderlichen Gremienabstimmungen und Entscheidungen durchzuführen und zu erhalten. Im Zuge der Lösungsabstimmung haben wir erkannt, dass der vorgeschlagene Weg gangbar, aber ein langer ist. Deshalb haben wir uns auf eine Ziellösung verständigt und für diesen Ansatz einen Phasenplan erarbeitet. Wir haben ein Vorgehensmodell entwickelt, um zuerst die Basisnotfallinfrastruktur aufzubauen und nur an einen der 23 Eingangskanäle anzuschließen. Im nächsten Schritt wollten wir zwei weitere wichtige Eingangskanäle aufschalten, Die restlichen Eingangskanäle planten wir sukzessive anzuschließen. Nachdem wir das Vorgehensmodell und den Leistungsumfang definiert hatten, waren die Fachbereiche in der Lage, die mit der Notfallinfrastruktur zu motivierenden Risiken zu ermitteln. Wir haben erkannt, dass die Risiken der zehn Prozesscluster mit der Ziellösung aus Sicht des Fachbereichs noch nicht in gewünschtem Umfang mitigiert werden können. Daher haben wir weitere Ausbaustufen konzipiert und für diese ebenfalls Kostenindikationen und Umsetzungspläne erarbeitet. Wir entwickelten vier weitere Leistungspakete und integrierten diese in unser Vorgehensmodell. Damit waren die Fachbereiche in der Lage zu erkennen, welche Risiken mitigiert werden können und welche Kosten für die Einführung einer Notfallinfrastruktur dafür aufzubringen waren. Auf dieser Basis erstellten die Fachbereiche Wirtschaftlichkeitsberechnungen. Die daraus gewonnenen Ergebnisse legten nahe, aus wirtschaftlichen Gründen das Projekt zu beenden. Positiv stellte sich heraus, dass im Rahmen des Projektes eine Vielzahl von Erkenntnissen über tatsächliche Schadenshöhen und organisatorische Mitigation gewonnen wurden. Zusätzlich wurde das Durchführen weiterer technischer Stabilisierungsmaßnahmen vereinbart. Mehr dazu befindet sich unter Projekt 55
Projektkontext:
In einer ersten Phase, siehe Projekt 49, habe ich eine Anwendung für die Produktlebenszyklusüberprüfung entwickeln lassen. Ziel war es nun, diese Software mit den erforderlichen MiFiD-relevanten Eigenschaften und Funktionalitäten erweitern zu lassen. Die Bank musste dabei regulatorische Anforderungen erfüllen. Diese Lösung sollte als Release der Produktlebenszyklusüberprüfung zur Verfügung gestellt werden.
Projektaufgabe:
Auf Basis von internen Revisionsanforderungen und externen regulatorischen Anforderungen habe ich mit dem Fachbereich ein grobes fachliches Vorgehensmodell entwickelt. Auf dieser Grundlage konnten wir abschätzen, welche MiFiD-relevanten Auslöser beispielsweise Ad-HocPrüfungen veranlassen würden. Zusätzlich zogen wir etwa Profitabilitätsbetrachtungen des Produktmanagements in die Betrachtungen mit ein. Die zu implementierende Lösung sollte beide Themenbereiche abdecken und Doppelarbeit vermeiden. Weiterhin wollten wir bestehende manuelle Dateiladevorgänge durch automatisierte Mechanismen ablösen. Dazu wollten wir die relevanten Datenquellen anbinden. Für dieses Projekt erstellte ich eine erste Planung und Kostenschätzung. Da jedoch zu dieser Zeit eine erhebliche Neuordnung des Bankkonzerns durchgeführt wurde, konnten uns die erforderlichen Budgets nicht bereitgestellt werden. Die Tätigkeiten sollten bis zu einem neu zu definierenden Termin ins neue Jahr verschoben werden. Ich ließ alle in Bearbeitung befindlichen Dokument ordentlich abschließen, stornierte alle angestoßenen Bestellungen, kündigte allen externen Dienstleistern oder ließ die Verträge auslaufen (auch meinen) und schloss das Projekt sauber ab.
Nachrichtlich:
Gegen Ende des ersten Halbjahres wurde das Projekt, aufbauend auf unseren Arbeitsergebnissen wieder aufgenommen und fortgeführt. Es wurde weiteres Budget bewilligt.
Projektkontext:
Das derzeit beim Kunden in der Fachabteilung Operational Risk Management verwendete Toolset für Analysen und Management Reporting genügte nicht mehr den Anforderungen an IT Systeme der Bank und barg Risiken in Hinsicht auf Verfügbarkeit und Wissenstransfer. Die Anwendung war eine sogenannte End-User Developed Application und wurde gemäß eines Regelprozesses ordnungsgemäß im Application Repository registriert. Um die Anwendung wieder auf den erforderlichen Systemlevel zu heben, sollte sie durch eine Standardsoftwarelösung ersetzt werden. Dieses neue System sollte dann dem geregelten Systembetrieb der Bank IT unterliegen. Daher wurde in einer Vorstudie 2014 vom Fachbereich SAS Visual Analytics als Werkzeug für ein zentrales Management Information System (MIS) ausgewählt, dies in einem Proof of Concept erfolgreich getestet sowie der Aufbau eines MIS beantragt und genehmigt.
Projektaufgabe:
Mein Projektziel war der Aufbau dieses Management Information Systems für Operational Risk Management mit dem Bereitstellen einer zentralen Datenhaltung als Basis für das MIS, einer automatisierten Anbindung aller relevanten Datenquellen, die Integration zusätzlicher manueller Datenfeeds über einen kontrollierten Prozess sowie die Erstellung standardisierter Reports inklusive Historisierung in der Datenbank, Einbindung einer AuditFunktion und dem Tracking der Zugriffe. Ein weiterer wichtiger Punkt, der über die bisher vorhandenen Funktionalitäten hinausging, war das Ziel, eine Self-Service-BI zur Erstellung und Änderung von Reports inklusive umfangreicher Analysefunktionen (Explorative-, Trend-, Forecast- und Predictive Analyse) bereitzustellen. Zusätzlich war eine iPadAnbindung zum Nutzen der Reports, Drill-Down und Analyse gefordert. Da die Bank IT und mein Projektteam nicht in Toolauswahl und Proof of Concept eingebunden waren, haben wir das Projekt in zwei Phasen aufgeteilt. Schwerpunkte der ersten Phase waren die Erarbeitung der Business Requirements (funktionale und nichtfunktionale Anforderungen) im Rahmen von 6 Workshops mit der Fachabteilung, die Erarbeitung eines Designkonzepts für die Software- und Architekturempfehlung, das Ermitteln von zu hebenden Synergien wie die Nutzung von Infrastruktur- und Lizenzkomponenten gemeinsam mit anderen Projekten, die Projektplanung zur Bereitstellung der Applikation und de Reports, sowie die finale Schätzung des Umsetzungsprojektes auf Basis der Anforderungen und des Designentwurfs, inklusive einer Schätzung der Betriebskosten für Infrastruktur und Applikation Management in den Folgejahren. Zur Unterstützung bei der Durchführung der ersten Phase kaufte ich Dienstleistungen bei einem externen Dienstleister ein. Nach erfolgreicher Freigabe der Bestellung im Einkaufsportal und Onboarding der Projektmitarbeiter, führte ich eine Kickoffveranstaltung durch. Die externen Berater bekamen von mir die Aufgabe, die 6 Workshops mit den Schwerpunkten fachliche Anforderungen (Requirements), Datenversorgung (Data Management) und Zielbild (Solution Design) gemeinsam mit dem Fachbereich durchzuführen. Als Ergebnisdokumente vereinbarte ich die Erstellung eines Zielbildes, die Ausformulierung eines Projektanforderungsdokumentes (Fachkonzept) und das Ausarbeiten eines Architekturvorschlages (High Level Architecture). Diese Ergebnisdokumente unterzog ich einem Überprüfungs- (Review) und Freigabeprozess (Approval), um sie fachlich abgenommen und qualitätsgesichert als Basis für die Erstellung der technischen Konzeption zu verwenden. Weiterhin nutzte ich diese Dokumente, um die erforderliches Freigabe der Quality Gates durch das Qualitätsmanagement zu erhalten. Parallel zur Durchführung der Workshops und dem Erstellen der Ergebnisdokumente plante ich die zweite Phase des Projekts, die Durchführung des Umsetzungsprojekts. Ich ermittelte und stellte die erforderlichen Teilaufgaben zusammen und leitete daraus die notwendigen Arbeitspakete ab. Für die benötigte Datenversorgung planten wir ein sich im Aufbau befindliches Operational Risk Datawarehouse nutzen. Ich stimmte die Datenverfügbarkeit und die von diesem Projekt gegebenen zeitlichen Rahmenbedingungen ab und brachte sie in Einklang mit unserer eigenen Zeitplanung. Dieses Operational Risk Datawarehouse wird von einem weiteren externen Dienstleister aufgebaut. Daher beschloss ich zur Unterstützung auch von dieser Firma Leistungen für unser Projekt einzukaufen. Das von unserem Projekt als Zielsystem festgelegte SAS Visual Analytics wurde zur gleichen Zeit von einem anderen Projekt validiert und implementiert. Da dieses Projekt SAS Visual Analytics als Plattform aufsetzen und diese anderen Projekten zur Nutzung zur Verfügung stellen wollte, trat ich in Abstimmung mit dessen Projektleitung ein. In mehreren Workshops konnten wir die Anforderungen und Zeitplanungen synchronisieren und vereinbarten, die Plattform gemeinsam zu projektieren und zu nutzen. Damit konnte ich für unser Projekt erhebliche Synergien hinsichtlich Infrastruktur-, Lizenz- und Betriebskosten heben. Am Anfang des dritten Quartals stellte ich den Lösungsansatz, das Vorgehensmodell und die Kostenschätzung beim Projektsponsor und Lenkungsausschuß vor. Die Präsentation erzielte große Zustimmung und wurde in das OpCo-Meeting eingebracht, um für die bisherige Budgetzusage nun die Budgetfreigabe für den Umsetzungsteil im nächsten Jahr zu bekommen. Es sollte eine reine Formsache sein, das Budget zu erhalten. Leider war dies nicht der Fall. Uns wurde eine erhebliche Budgetkürzung auferlegt, die Bank musste sparen. Wir sollten mit viel weniger Mitteln zum Ziel kommen, oder wenigstens „zeigen, was wir können“, um im Nachgang möglicherweise die restlichen Gelder zu erhalten. Wir entschlossen uns, nur einen Teil der Datenquellen anzubinden und so die Möglichkeit zu bieten, die volle Funktionalität auf einer Teilmenge der Daten produktiv vorzuführen, zu „zeigen, was wir können“, um dann das Restbudget für die vollständige Implementierung zu erhalten. Da ich eine detaillierte Kostenaufstellung im Zuge der Projektplanung erarbeitet hatte, war es für mich nur eine Fleißaufgabe, unter Einbeziehung aller involvierten Parteien, die für dieses eingeschränkte Vorgehen notwendige Planung und Kostenschätzung zu erarbeiten und in den Gremien vorzustellen. Die Planung wurde als valide angesehen, aber uns wurden weitere Budgeteinschränkungen auferlegt. Diese machten den Ansatz unmöglich. Wir planten erneut um und entschlossen uns, einen sinnvollen Datenhaushalt mit der entsprechenden Bewirtschaftung aufzubauen und auf ein Anbinden eines Frontends zu verzichten. Dies wollten wir nach Freigabe weiterer Gelder projektieren. Da ich eine detaillierte Kostenaufstellung im Zuge der Projektplanung erarbeitet hatte, war es für mich nur eine Fleißaufgabe, unter Einbeziehung aller involvierten Parteien, die für dieses weiter eingeschränkte Vorgehen notwendige Planung und Kostenschätzung zu erarbeiten und in den Gremien vorzustellen. Die Planung wurde als valide angesehen, aber uns wurden weitere Budgeteinschränkungen auferlegt. Diese machten auch diesen Ansatz unmöglich. Daher trafen wir in den Gremien die Entscheidung, den aktuellen Arbeitsstand sauber zu dokumentieren und die weitere Projektarbeit zum Ende des Jahres definiert einzustellen. Ich ließ alle in Bearbeitung befindlichen Dokument ordentlich abschließen, stornierte alle angestoßenen Bestellungen, kündigte allen externen Dienstleistern oder ließ die Verträge auslaufen (auch meinen) und schloss das Projekt sauber ab.
Nachrichtlich:
Vier Monate später wurde das Projekt, aufbauend auf unseren Arbeitsergebnissen wieder aufgenommen und fortgeführt. Es wurde weiteres Budget bewilligt.
Projektkontext:
Zur Erfüllung ihrer Aufgaben benötigt die Europäische Zentralbank (EZB) länderspezifische und vergleichende Zahlungsverkehrsstatistiken. Auf Basis der EU-Verordnungen Nr. 2533/98 und insbesondere 1409/2013 sollen ab dem Berichtsjahr 2014 Zahlungsverkehrsdaten und Daten über Zahlungsverkehrssysteme erhoben werden. Das Ziel der neuen Zahlungsverkehrsstatistik liegt in der größeren Harmonisierung von Definitionen und Meldeinhalten innerhalb des Euroraums. Die Meldung zur jährlichen Zahlungsverkehrsstatistik (ZV-Statistik) ist eine regulatorische Anforderung. Das Recht zur Überprüfung oder Zwangserhebung statistischer Daten wird von den nationalen Zentralbanken ausgeübt. Die ZVStatistik selbst enthält Positionen über Anzahl und Wert von Transaktionen, die über das ganze Berichtsjahr zu kumulieren sind, sowie Positionen, die sich auf den Bestand zum Jahresende beziehen. Die erstellte Meldedatei wird im XML Format über das Extranet der Deutschen Bundesbank eingereicht. Die technische Spezifikation sowie die Richtlinien zu den Inhalten der einzelnen Meldepositionen wurden von der Deutschen Bundesbank vorgegeben.
Projektaufgabe:
Projektziel waren die Ermittlung und Bereitstellung der statistischen Daten auf Basis der neuen regulatorischen Anforderungen. Statistiken über den Zahlungsverkehr von 2007 bis 2013 dienten vor allem als Datenquelle zur Einrichtung, Steuerung und Überwachung von Zahlungsverkehrs- und Wertpapierabrechnungssystemen des Kreditgewerbes in Deutschland. Bisher waren ausschließlich alle inländischen Banken (MFI – Monetary Financial Institute) meldepflichtig. Diese MFI haben einen Großteil der Zahlungsverkehrsgeschäfte erbracht und gemeldet, da für das Betreiben des Girogeschäftes eine Banklizenz Voraussetzung war. Mit Inkrafttreten des Zahlungsdiensteaufsichtsgesetzes (ZAG) im Jahr 2009 können europaweit Zahlungsdienste auch von sogenannten Zahlungsdienstleistern (ZDL) angeboten werden. Der Begriff des Zahlungsdienstleisters beinhaltet sowohl die bisherigen MFI als auch neue meldepflichtige Marktteilnehmer wie beispielsweise E-Geld Institute. Aufgrund dieser Änderung in den rechtlichen Rahmenbedingungen dürfen mit der neuen ZV-Statistik Transaktionen dieser ZDL nicht mehr in der Bundesbankmeldung aufgeführt werden. Dies bedeutete für mich und mein Projektteam, dass wir den bestehenden Meldeprozess, zur Gewährleistung der Kontinuität der Meldungen gegenüber der Bundesbank, zu analysieren hatten. Dabei haben wir auf die aktuelle Datenermittlung, deren Inhalte und Abläufe zurückgegriffen. Auf Basis dieser Analyseergebnisse und den weiterführenden regulativen Vorgaben der Bundebank erstellten wir ein Konzept, um die Compliance für die Bank sicherzustellen. Unsere grundsätzliche Annahme dabei war, dass die Kennzahlen bisher korrekt ermittelt wurden und deshalb darauf aufgebaut werden konnte. Im Rahmen der Analyse und der fachlichen Anforderungserhebung haben wir jede Position auf eine mögliche Wiederverwertung hin überprüft. Dieses Vorgehen führte dazu, dass fachlich identische Kennzahlen lediglich mit der korrekten Positionsangabe, bezogen auf das entsprechende Zahlungsverkehrsmeldeschema (ZVS), in eine neue Schnittstelle an der richtigen Position aufgenommen werden mussten. Jedoch mussten wir auf Grund geänderter Richtlinien Statistikpositionen anpassen. Zusätzlich kamen neue Anforderungen hinzu. In diesem Zuge mussten wir eine Vielzahl von Plausibilitäten berücksichtigen und die Meldungen getrennt nach Gesellschaften (Legal Entitys) abgeben. Zur Sicherheit und Vergleichbarkeit planten wir, die maschinelle Aufbereitung nach dem alten Meldeschema weiterhin parallel zu prozessieren. Diese Ergebnisse meldeten wir jedoch nicht mehr an die Bundesbank. Derzeit liefern verschiedene Systeme statistische Informationen über Konten, Karten, Bankensysteme und Transaktionen im Zuge des jährlichen Statistikreports. Dieser Report wird als XML Datei in das Extranet der Bundesbank eingespielt. Die geplanten Änderungen können deshalb externe Datenlieferanten sowie interne Providersysteme betreffen. Aus diesem Grund haben wir die Aufgaben auf verschiedene Teams verteilt. Mein Team und ich fokussierten uns auf zwei Datenlieferungsstränge. Zum einen bearbeiteten wir die Kartentransaktionen und zum anderen den Auslandszahlungsverkehr. Dazu erstellte ich für die mir zugeordneten Entwicklerteams ein Dokument mit detaillierten Softwareanforderungen. In diesem Dokument beschrieb ich, wie die Requirements, beispielsweise das Zählen von Kartentransaktionen, Überweisungen oder Schecks sowie das Bilden von Summen oder Herausrechnen der ZDL, in der Umsetzung durchgeführt werden sollten. Unter meiner Steuerung programmierten die Entwickler die entsprechende Software für die betroffenen Systeme auf Basis meines Anforderungsdokuments. Die im Zuge der Entwicklung aufkommenden Fragen klärte ich mit den Entwicklern. Dort, wo es erforderlich war, band ich die Fachabteilung oder andere Teilprojekte zur inhaltlichen Klärung der Sachverhalte ein. Ein weiterer Schwerpunkt meiner Arbeit war das Anpassen der Lieferschnittstellen sowie das Einrichten der Datenlieferprozesse. Diese neuen Schnittstellen und Prozesse sollten für eine gewisse Zeit lang als Parallelversorgung zur bestehenden Lieferstrecke betrieben werden. Die Aufgabe war insbesondere wichtig, da von der Gesamtprojektleitung geplant war, einen End-to-End-Test durchzuführen. Dies war besonders deswegen eine Herausforderung, da wir zum Test ausschließlich synthetische Daten zu verwenden hatten. So organsierte ich die Erzeugung und Bereitstellung von synthetischen Testdaten und veranlasste die notwendigen Systemverbindungen inklusive der erforderlichen Datentransferjobs zur Übertragung der Dateien. Da wir keine Produktivdaten verwenden durften, ließ ich analysieren, welche Auswirkung dies auf Ablaufsteuerungen im Systemverbund hatte und veranlasste die erforderlichen Anpassungen, um den Test zu ermöglichen. In einigen Teilbereichen der Lieferstrecke war es nicht möglich, die synthetischen Daten automatisiert zu verarbeiten. Daher vereinbarte ich mit Testmanagement und Operating die notwendigen manuellen Eingriffe, die im Rahmen der Tests erforderlich sein würden. Eine weitere Aufgabe war die Erstellung von Testdaten. Dazu stimmte ich Anforderungen an die und Umfang der Testaktivitäten mit dem Testmanagement ab. Auf Basis dieser Anforderungen und des Mastertestplans ließ ich die notwendigen Testfälle erstellen und im Rahmen eines Prüfungs- und Freigabeprozesses von den verantwortlichen Personen abnehmen. Nach der Abnahme der Testfälle veranlasste ich ein Hochladen der Testfälle in HP ALM und ein Verknüpfen mit den dazugehörigen Anforderungen. Zur weiteren Testvorbereitung stimmte ich mit meinem Team, dem Testmanagement und der Gesamtprojektleitung den Zeitplan und das Vorgehen ab. Nach Abschluss der Entwicklungsarbeiten stellte ich gemeinsam mit den Entwicklern sicher, dass die erforderlichen Entwickler- sowie Systemintegrationstests fehlerfrei und erfolgreich durchgeführt wurden. Im Nachgang an diese Tests führten wir im Zuge des End-to-End-Tests im Rahmen der Testorganisation eine Verarbeitung der Daten entlang der ganzen Lieferstrecke durch. Dabei mussten wir noch einige Details zum fehlerfreien Prozessieren der Daten klä- ren, abstimmen und umsetzen lassen. Danach konnten wir gemeinsam mit Fachtestern die Testfälle durchführen. Dabei stellte sich heraus, dass einige Fachanforderungen nicht präzise gestellt waren. Einige wenige Anforderungen änderten sich zudem, da die Fachabteilung neue Erkenntnisse aus dem Dialog mit der Bundesbank erlangt hatten. Hinzu kamen Abweichungen in den Ergebnissen, die auf Fehler in Zuordnungstabellen zurückzuführen waren. Ich veranlasste im Rahmen eines Changeprozesses die notwendige Softwareentwicklung zur Korrektur und die Bereitstellung der prozessierten Testdaten. Die Abläufe der Fachtests stimmte ich dabei mit den Entwicklern und Testern ab. Nach erfolgreichem Abschluss aller Testaktivitäten sorgte ich mit meinem Team für die Paketierung der Software zur Übergabe in den Produktivbetrieb. Dabei mussten wir uns mit dem Releasemanagement sowie dem Deploymentteam abstimmen. Da wir unsere Software so zum Einsatz bringen mussten, dass der vollständige Berichtsmonat abgedeckt ist, konnten wir nicht im Zuge eines an SAP ausgerichteten Regelreleases in Produktion gehen. Daher beantragten wir beim Change Advisory Board ein Exceptional Release. Nach der Freigabe unseres Exceptional Releases konnten wir zum passenden Termin Live gehen und unsere Software erfolgreich produktiv setzen. Nach erfolgreicher Produktivnahme mussten wir lediglich noch einige Vorbereitungen treffen, um die Jahresmeldung für das Berichtsjahr 2015 auf Basis der neuen Softwarekomponenten sicherzustellen. Der Abschluss dieser Tätigkeiten war für uns auch der erfolgreiche Abschluss unseres Projektes.
Projektkontext:
Die Einführung des Euros stellte einen wichtigen Schritt für die Schaffung eines europäischen Binnenmarktes dar. Die Euroeinführung wurde durch die schrittweise Standardisierung der in Europa existierenden Bezahlverfahren begleitet. Dies mündete in der Schaffung eines einheitlichen europäischen Zahlungsverkehrsraumes, der sogenannten Single European Payments Area – kurz SEPA. Mit der Implementierung der SEPA Zahlungsverfahren wurden einheitliche Technologien, aber auch einheitliche Datenformate umgesetzt. Ein elementarer Datenbestandteil ist dabei der SEPA Purpose Code, auch als Textschlüssel bekannt.
Projektaufgabe:
Im Jahr 2015 wurde die Spezifikation der Datenformate auf die Version 2.9 umgestellt. Diese Umstellung war terminiert auf den November 2015. Kernaufgabe dabei war die Integration neuer Purpose Codes. Mit Hilfe dieser Textschlüssel ist es möglich, Überweisungen und Lastschriften nach der Art der Zahlung zu klassifizieren, zu unterschieden und eine Automatisierung von Prozessen und Abläufen zu implementieren. Natürlich nutzt die Bank ebenfalls diese Textschlüssel, um darauf aufbauend Geschäftslogik und Ablaufsteuerungen zu prozessieren. Daher betraf die notwendige Umstellung eine Vielzahl von Systemen. Die Umstellung der vorgelagerten Operativsysteme wurde von einem anderen Team durchgeführt. Mein Team war dafür verantwortlich, die korrekte Umstellung der dispositiven Business Intelligence Systeme durchzuführen. Beginnen mussten wir mit einer klassischen Businessanalyse der Prozesse, Datenströme und involvierten Systeme. Basierend auf dem im Projekt 44 erstellten BI-Master identifizierten wir die möglicherweise von der Änderung betroffenen Systeme. Dabei konnten wir die zu untersuchenden Systeme bereits eindeutig ermitteln und die Gesamtanzahl dadurch deutlich reduzieren.Gemeinsam mit den technischen und fachlichen Ansprechpartnern klärten mein Team und ich die Datenversorgung der Systeme, den auf den Textschlüsseln basierenden Programmablauf und die daraus erzeugten Ergebnisdaten. So konnten wir die Anzahl der zu bearbeitenden Systeme nochmals eingrenzen, da nicht alle Anwendungen von der geplanten Umstellung auf die neuen Textschlüssel tatsächlich fachlich betroffen waren. Für die umzustellenden Systeme analysierten wir gemeinsam mit den zuständigen Programmierern den Programmcode und identifizierten die zu ändernden Bestandteile der Software. Für die notwendigen Programmanpassungen ließ ich fachliche Anforderungen (Requirements) erstellen. Dieses Fachkonzept unterzog ich einem Überprüfungs- (Review) und Freigabeprozess (Approval), um es qualitätsgesichert als Basis für die Erstellung der technischen Konzeption zu nutzen. Weiterhin nutzte ich dieses Papier, um die erforderliche Freigabe des Quality Gates durch das Qualitätsmanagement zu erhalten. Als nächsten Schritt plante und ließ ich durchführen die Erstellung der technischen Konzeption. In diesem Dokument ließ ich detailliert die Softwareanforderungen spezifizieren und beschreiben, wie technisch die erforderlichen Änderungen der entsprechenden Softwarekomponenten für die betroffenen Systeme auf Basis des Anforderungsdokuments umzusetzen sind. Auch dieses Dokument führte ich durch die notwendigen Prüf- und Freigabeschritte, um unter anderem die Anforderungen des Quality Gates zu erfüllen. Anschließend stellte ich die Programmierung der Softwareanpassung durch das Entwicklerteam auf Basis der Spezifikationsdokumente sicher. Dabei standen mein Team und ich im ständigen Dialog mit den Entwicklern, der Fachabteilung oder anderen Teilprojekten zur inhaltlichen Klärung von Sachverhalten und zur Abstimmung von Abhängigkeiten sowie Terminen. Eine weitere Aufgabe war die Bereitstellung von Testdaten. Dazu stimmte ich Anforderungen an die und Umfang der Testaktivitäten mit dem Testmanagement ab. Auf Basis dieser Anforderungen und des Mastertestplans ließ ich die notwendigen Testfälle erstellen und im Rahmen eines Prüfungs- und Freigabeprozesses von den verantwortlichen Personen abnehmen. Nach der Abnahme der Testfälle veranlasste ich ein Hochladen der Testfälle in HP ALM und ein Verknüpfen mit den dazugehörigen Anforderungen. Zur weiteren Testvorbereitung stimmte ich mit meinem Team, dem Testmanagement und der Gesamtprojektleitung den Zeitplan und das Vorgehen ab. Nach Abschluss der Entwicklungsarbeiten stellte ich gemeinsam mit den Entwicklern sicher, dass die erforderlichen Entwickler- sowie Systemintegrationstests fehlerfrei und erfolgreich durchgeführt wurden. Danach konnten wir gemeinsam mit Fachtestern die Testfälle durchführen. Die dabei entdeckten fachlichen Fehler ließ ich korrigieren und die Software erneut testen. Nach erfolgreichem Abschluss aller Testaktivitäten sorgte ich mit meinem Team für die Paketierung der Software zur Übergabe in den Produktivbetrieb. Dabei mussten wir uns mit dem Releasemanagement sowie dem Deploymentteam abstimmen. Nach der Freigabe unseres Releases konnten wir zum Zieltermin Live gehen und unsere Software erfolgreich in den Produktivbetrieb überführen. In den letzten Jahreswochen 2015 standen wir für eine Unterstützung des Produktionsteams zur Verfügung. Im realen Produktivbetrieb und mit echten Daten stellten sich doch noch einige kleine Fehler heraus, die ich analysieren und beseitigen ließ. Diese Maßnahmen waren jedoch nicht sehr umfangreich und wir konnten die Betriebsunterstützung im Dezember beenden. Der Abschluss dieser Tätigkeiten war für uns auch der erfolgreiche Abschluss unseres Projektes.
Projektkontext:
Im Bankenumfeld ist ein Product Lifecycle Review ein wichtiger Prozess. Produktlebenszyklusüberprüfungen werden unter anderem zu zwei Zwecken durchgeführt. Zum einen, um regulatorische Anforderungen zu erfüllen, und zum anderen, um das Produktmanagement zu unterstützen. Die dabei genutzten und entstehenden Daten wurden bislang in unterschiedlichen Ausprägungen und an verschiedenen Stellen gespeichert. Die Datenhaltung sollte in eine zentrale Datenbank mit einheitlicher Geschäftslogik überführt werden.
Projektaufgabe:
Auf Basis eines vom Fachbereich erstellten Konzeptes sollte ein externer Dienstleister beauftragt werden, der die Erstellung der Applikation für die erste Phase übernehmen konnte. Die Anwendung sollte als zentrale Applikation für die Verwaltung und Steuerung des Reviewprozesses für die Produkte der Bank dienen. Das Lösungskonzept gründete auf bewährte State-of-the-Art Technologien, die Architektur basierte auf einem klassischen 3-Tier-Modell. Zuunterst lag die Persistenzschicht in Form einer Datenbank, die Business-Logik wurde in einem JBoss Applikationsserver implementiert und für die Anwender wurde ein webbasiertes Frontend bereitgestellt. Dazu habe ich eine Projektplanung sowie eine Kostenstruktur ausgearbeitet und abgestimmt. Ausgewählt habe ich einen Dienstleister, der sich in diesem Umfeld der Bank bereits bewährt hatte. Das hatte den Vorteil, dass ich die Aufgabe als Gewerk vergeben konnte. Meine Aufgaben in diesem Projekt konzentrierten sich daher vorrangig auf klassisches Projektcontrolling zur Steuerung des Dienstleisters. Organisatorisch stellte ich sicher, dass die Anwendung nach Ende der externen Entwicklung und umfassenden Tests in den Regelbetrieb der Bank übernommen werden konnte. Dazu stimmte ich die erforderlichen Dokumentationen ab und ließ diese erstellen sowie abnehmen. Zusätzlich führte ich Übergabetermine mit den Entwicklern und dem Production Support durch, um sicherzustellen, dass der Anwendungsbetrieb mit allen erforderlichen Informationen ausgestattet wurde. Parallel zur erfolgreichen Übergabe in den Produktivbetrieb plante ich die zweite Phase des Projektes. Dazu sollte die Anwendung MiFiD-fähig gemacht werden; die Beschreibung des Projektes finden Sie unter Projekt 50.
Projektkontext:
Der Kunde plante die Ablösung des selbstentwickelten Operativsystems zur Verwaltung und Abwicklung von Girokonten und Einlagegeschäften durch die Standardsoftware SAP DM (Deposit Manager) im Rahmen des größten, europäischen IT-Programmes. Dabei sollten alle im System geführten Girokonten und Einlagegeschäfte der größten Kundengruppe der Privat- und Geschäftskunden (PGK) vom Alt- in das Neusystem migriert werden. Dies betraf die Verträge von rund 6.000.000 Kunden. Zusätzlich sollten die dann im SAP DM vorliegenden Verträge nicht mehr über das eigenentwickelte Financesystem sondern über den SAP BA (Bank Analyzer) verarbeitet werden. Damit sollten die buchhalterischen Zahlen dieser Verträge zukünftig über das Neusystem ermittelt werden. Parallel dazu war geplant, die nicht migrierten Verträge über die alten Systeme zu verarbeiten. Dies bedeutete, dass die Daten sowohl der migrierten als auch der nicht migrierten Verträge im BI-Umfeld wieder zusammengeführt werden sollten.
Projektaufgabe: Der Schwerpunkt meines Teams war dabei die Aufrechterhaltung aller Funktionalitäten des zentralen BI Datawarehouses und dessen Abnehmersysteme im Rahmen des Programmes BI Maintain. Zur Auswertung der Girokonten und Einlagegeschäfte durch Business Intelligence waren neun operative Liefersysteme, vier Datawarehouses und 52 auswertende BIApplikationen, versorgt über mehr als 100 Schnittstellen, zu analysieren und anschließend umzustellen. Wichtig war insbesondere die Festlegung des Scopes, da das Systemumfeld nicht einheitlich verantwortet wurde. Wir haben ermittelt, welche Systeme tatsächlich von der Umstellung betroffen waren, wer diese Systeme technisch betreut und fachlich nutzt. Dabei konnten wir Erkenntnisse (BI-Master) und Erfahrungen aus dem Projekt CML (Projekt 44 in dieser Liste) als Basis für die Projektplanung und die Ausarbeitung der Vorgehensweise nutzen. Damit wir die Unterstützung aller relevanten Stakeholder sicherstellen und wir unsere Vorgehensweise sowie die erforderliche fachliche und technische Unterstützung transparent machen konnten, führten wir mehrere Workshops mit den Mitarbeitern der betroffenen Abteilungen und Bereiche durch. Als Arbeitsergebnisse konnten aus den 84 in Scope liegenden BI-Applikationen 39 direkt und 13 indirekt betroffene Anwendungen inklusive ihrer Relationen identifiziert werden. Weiterhin konnten wir den aus dem CML-Projekt stammenden BI-Master erweitern sowie das Ist-Bild der betroffenen Systemlandschaft ermitteln und darstellen. Alle von den BI-Applikationen benötigten Informationen aus den Altsystemen haben wir in einer Applikations-Feld-Matrix dokumentiert. Damit haben mein Team und ich herausgearbeitet, welche Schnittstelleninhalte von welchen Anwendungen genutzt wurden – ein Kernthema für die notwendige Umstellung. Eine weitere Rahmenbedingung war, dass die BI-Welt über zwei Hauptstränge mit Daten versorgt werden sollte. Zum einen sollten Daten direkt aus dem Operativsystem SAP DM innerhalb von BI verwendet werden und zum anderen sollte BI die Finance-Zahlen über den SAP BA erhalten. Beide Stränge sollten nach Architekturvorgabe über SAP BW (Business Warehouse) an die BI-Welt angebunden werden. Um der Komplexität der Themen gerecht zu werden, haben wir diese jeweils einem Teilteam zugeordnet. Das Team, das für die Datenversorgung aus SAP DM zuständig war, stellte fest, dass die Datenmodellierung in SAP BW für das BI-Umfeld noch nicht geeignet war. Daraufhin haben wir in Zusammenarbeit mit dem Team DMIntegration ein konzeptionelles Datenmodell auf Basis der fachlichen Anforderungen ausgearbeitet. Dieses nutzten wir als Grundlage für die logische Datenmodellierung in SAP BW. Als weit schwieriger stellte sich die Ausarbeitung der Alt-Neu-Überleitung heraus. Die Alt-Neu-Überleitung über die Migrationsstrecke lieferte nicht für alle benötigten Informationen hinreichend verwendbare Aussagen. Deshalb erarbeiteten wir eine alternative Vorgehensweise. Auf Basis der inhaltlich fachlichen Anforderungen der einzelnen BI-Applikationen erstellten mein Team und ich eine Lieferanforderung und adressierten diese an das SAP DM-Team. Somit konnten wir die benötigten Informationen aus SAP DM identifizieren und uns diese über SAP BW bereitstellen lassen. Das Team, das für die Datenversorgung aus SAP BA zuständig war, erstellte auf Grundlage der benötigten Informationen eine Datenanforderung an das SAP BA-Team. Zusammen mit dem BA-Team haben wir neue Lieferstrecken vereinbart und für den Großteil der benötigten Attribute eine Alt-Neu- Überleitung ausgearbeitet. Für die restlichen Attribute konnten wir Alternativen aus dem Neusystem ermitteln und bereitstellen lassen. Die verbliebenen Altattribute konnten nach fachlicher Klärung aus der Anforderungsliste herausgenommen werden. Zusätzlich haben wir vereinbart, dass für einige benötigte Altschlüssel Rückableitungen über das SAP BW bereitgestellt werden sollten. Parallel zum Aufsetzen der beiden Datenversorgungsstränge habe ich an der technischen Anbindung des BI-Umfeldes an SAP BW gearbeitet. Hierzu arbeiteten mein Team und ich unterschiedliche technische Lieferwege aus und stimmten diese mit dem Domänenarchitekten ab. Für den vereinbarten Lieferweg beauftragten wir die Entwicklung und Umsetzung der technischen Schnittstellen bei den zuständigen Entwicklerteams. Zur Unterstützung der Umsetzung erstellte ich Jobhandbücher für die UC4-Prozesse, definierte die erforderlichen Transformationsregeln für die Datenkonvertierung von SAP nach Host und tauschte mich regelmäßig mit allen beteiligten Personen in Workshops aus. Ich konnte termingerecht im Dezember 2014 die technische Anbindung von SAP BW auf Midrange an das BI DWH auf Mainframe in Betrieb nehmen. Im ersten Quartal 2015 wurde vom Management die IT-Strategie überprüft und das weitere Vorgehen im Programm hinterfragt. Dies hatte für uns zur Folge, dass wir die laufenden Aktivitäten begrenzen und die bis dahin erzielten Ergebnisse sichern mussten. Zentrale Arbeitsunterlagen habe ich mit meinem Team in einen definierten Zustand überführt, abgestimmt und dokumentiert. Zusätzlich erstellten wir für 23 ausgewählte Applikationen Konzepte, um die von uns ausgearbeiteten Lö- sungsoptionen für die jeweilige Anwendung für eine mögliche spätere Umsetzung festzuhalten. Auf Basis unserer Erkenntnisse haben wir für das Management alternative Vorgehensweisen für die Projektfortführung ausgearbeitet. Dabei skizzierten wir zwei unterschiedliche Vorgehensmodelle, jeweils mit einem Basis- und einem erweiterten Szenario. Wir haben zu diesen Szenarien Aufwandschätzungen sowie Projektkalkulationen erarbeitet und dem Program Management vorgestellt. Im Februar 2015 wurde vom Management entschieden, die Projektaktivitäten einzustellen und alle zielrelevanten Informationen und Dokumente zu archivieren. Diese Tätigkeiten führten wir bis Ende Februar durch.
Projektkontext:
Der Kunde plante die Ablösung des selbstentwickelten Operativsystems zur Verwaltung und Abwicklung von Baufinanzierungen durch die Standardsoftware SAP CML im Rahmen des größten europäischen ITProgrammes. Dabei mussten alle Baufinanzierungsverträge vom Alt- in das Neusystem migriert werden. Dies betraf die Verträge von rund 600.000 Kunden mit einem Gesamtvolumen von etwa 50.000.000.000 Euro. Mit der Einführung von SAP CML sollte für das Baufinanzierungsportfolio ein großer Schritt in Richtung einer zukunftsfähigen Kreditfabrik unternommen werden.
Projektaufgabe:
Der Schwerpunkt meiner Arbeit und der meines Teams war dabei die Sicherstellung der Aufrechterhaltung aller Funktionalitäten des zentralen BI Datawarehouses und dessen Abnehmersysteme im Rahmen des Programmes BI Maintain. Zur Auswertung der Baufinanzierungen durch Business Intelligence (BI) waren fünf operative Liefersysteme, vier Datawarehouses und 47 auswertende BI-Applikationen, versorgt über 75 Schnittstellen, zu analysieren und anschließend umzustellen. Wichtig war insbesondere die Festlegung des Scopes, da das Systemumfeld nicht einheitlich verantwortet wurde. Wir haben ermittelt, welche Systeme tatsächlich von der Umstellung betroffen waren, wer diese Systeme technisch betreut und fachlich nutzt. Dabei erstellten wir eine Landkarte (BI-Master, A0) zur Darstellung der Systeme, Schnittstellen und Datenflüsse. Diese Darstellung nutzten wir als Basis für die Projektplanung und die Ausarbeitung der Vorgehensweise. Zusätzlich konnte ich auf Grundlage dieser Erhebung eine erste Projektkalkulation und Resourcenplanung aufstellen.
Damit wir die Unterstützung aller relevanten Stakeholder sicherstellen und unsere Vorgehensweise sowie die erforderliche fachliche und technische Unterstützung transparent machen konnten, veranstalteten wir mehrere Informationsveranstaltungen. Im Nachgang führten wir dedizierte Einzelgespräche, sogenannte Kleeblattgespräche, durch. Als Arbeitsergebnisse hieraus konnten mein Team und ich die Identifizierung aller BI-relevanter Systeme und Systemrelationen (insgesamt 40 BI Applikationen waren direkt betroffen und weitere 7 indirekt) abschließen. Weiterhin konnte ich die finale Darstellung des BI-Masters sowie die des Ist-Bildes und die Erhebung aller benötigter Informationen aus den Altsystemen in einer Applikations-FeldMatrix erstellen. Damit haben wir unter anderem herausgearbeitet, welche Schnittstelleninhalte von welchen Anwendungen genutzt wurden – ein Kernthema für die notwendige Umstellung. In Zusammenarbeit mit dem CML-Integrationsteam erarbeitete mein Team für die rund 500 betroffenen Datenfelder eine Beschreibung wie die benötigten Daten im neuen Umfeld zur Verfügung stehen würden. Dabei stellten wir fest, dass es neben Informationen, die 1:1 abgebildet werden konnten, eine Vielzahl von Inhalten in anderer Ausprägung und oder Struktur bereitgestellt werden sollten. Ferner bemerkten wir, dass mache Inhalte nicht mehr lieferbar waren und weitere, neue Inhalte hinzukommen sollten. Dies machte es für uns erforderlich, Rückableitungsvorschriften zu erarbeiten und Daten zusätzlich in speziellen Lieferformaten für die Abnehmer bereit zu stellen. Bei der Konzeption mussten wir insbesondere beachten, dass eine fachliche Umstellung vom Ist- auf das Soll-Prinzip vorgenommen werden sollte. Dies brachte Auswirkungen auf die Test- und Überprüfbarkeit der neuen Daten und Rechenergebnisse mit sich. Ferner sollte die Lieferkette an die BI-Welt umgestellt werden. Wir planten, die Datenversorgung nicht mehr direkt aus den Operativsystemen heraus zu bewerkstelligen, sondern auf eine Anbindung über SAP BW (Business Warehouse) und eine ETL-Plattform (Extract, Transform, Load) , basierend auf Informatica, umzustellen. Weiterhin mussten wir berücksichtigen, dass die Datenbereitstellung zukünftig in Form eines Datenmodells, im Gegensatz zur bestehenden denormalisierten Struktur, vorgesehen war. Die Anpassung der einzelnen Systeme wurde durch Entwicklerteams vorgenommen. Um diese Arbeiten zu unterstützen und letzte Detailfragen zu klären, führte ich mit meinem Team Deep Dive Gespräche zur Weitergabe applikationsspezifischer Informationen mit den involvierten Personen durch. Weiterhin begleiteten wir die Entwicklungsphase beratend und standen jederzeit als Ansprechpartner für Problemlösungen zur Verfügung. Da im Rahmen des Projektes die erforderliche Testorganisation noch nicht zur Verfügung stand, wurden wir von der Programmleitung in die Testplanung und –durchführung eingebunden, da wir im Umfeld die umfassendsten Kenntnisse hatten. Mein Team und ich arbeiteten an der Festlegung des Testumfangs und der zu bereitstellenden Testumgebungen mit. Zusätzlich klärten wir die Verfügbarkeit und Bereitstellung von Testdaten. Wir informierten die Verantwortlichen der betroffenen BI-Applikationen über die vorgesehene Testdurchführung und unterstützen sie bei der Erstellung von Testfällen. Während der Tests standen wir zur Klärung von Detailfragen zur Verfügung, erfassten die erkannten Fehler (Defects) in der Datenbank von HP ALM und veranlassten die Behebung von Mängeln. Manche Fehler, die beseitigt werden mussten, zogen Softwareanpassungen nach sich. Weiterhin mussten wir vereinzelt Konzeptadjustierungen erarbeiten und abstimmen. Durch die hohe Qualität unserer Tests identifizierten wir zwei Fehler in Vorsystemen, die bislang unentdeckt geblieben waren. Bei der Planung der Inbetriebnahme (cut over) waren wir ebenfalls aktiv eingebunden. Schließlich galt es, eine reibungslose Systemintegration mit dem Releasemanagement aufzuplanen. Fokus dabei war die Einbettung des Neusystems in die bestehende Umsystem- und Prozesslandschaft. Hinsichtlich der Abläufe war eine Prozessharmonisierung erforderlich, die eine weitgehende Angleichung der neuen Prozesse an die bestehenden Standardprozesse zum Ziel hatte. Bei der Gestaltung der Prozesse arbeiteten mein Team und ich aktiv mit. Wir hatten vorgesehen, die von unserem Programm betreuten Anwendungen zum Jahreswechsel in Betrieb zu nehmen. Damit nicht alle Umstellungsaufgaben in einem engen Zeitfenster stattfinden mussten, entzerrten wir den Zeitplan dahingehend, dass wir die täglich laufenden Prozesse zum 06.01.2014 und die monatlich laufenden Vorgänge zum 31.01.2014 in den Produktivbetrieb überführten. So stellten wir 38 der 40 direkt betroffenen Applikationen ohne signifikante Produktionsprobleme um. Für eine Applikation mussten Nachbesserungen in den Vorsystemen durchgeführt werden. Für eine weitere Applikation mussten wir erneut fachliche Vorgaben einholen, abstimmen und entsprechende Anpassungen vornehmen lassen. Daher führten wir eine Nachbetreuung bis Ende des ersten Quartals durch. Alle Umstellungen haben reibungslos funktioniert und konnten erfolgreich abgeschlossen werden.
Projektkontext:
Die Sozietäten planten, die bestehende Serverinfrastruktur zu erneuern und hochverfügbar auszulegen.
Projektaufgabe:
Dazu mussten meine IT-Spezialisten die bestehende Infrastruktur analysieren und katalogisieren lassen. Parallel dazu erarbeitete mein Business Analyst gemeinsam mit dem Kunden die Anforderungen an die neue IT-Infrastruktur. Schwerpunkt dabei war die Definition der Hochverfügbarkeit. Wir identifizierten die bestehenden Services und bewerteten sie. Anschließend legten wir für die Services mit genügender Kritikalität die Hochverfügbarkeit fest. Nach dieser fachlichen Bewertung konnte ich meinen Business Analyst Vorgaben erstellen lassen, damit meine IT-Spezialisten ein technisches Konzept erarbeiten konnten. Auf Basis dieses Lösungsentwurfes mit Umsetzungsvarianten erstellte ich eine Wirtschaftlichkeitsbetrachtung. Gemeinsam mit dem ITVerantwortlichen des Kunden diskutierte ich die Lösungsansätze und spiegelte sie gegen die Wirtschaftlichkeitsberechnung. Wir erstellten gemeinsam eine Entscheidungsvorlage für die Gesellschafterversammlung. Nach der Entscheidung und Freigabe des Lösungsansatzes durch die Gesellschafterversammlung organisierte ich die Hardwarebeschaffung. Parallel dazu erstellte ich die Projektplanung. Die Herausforderung dabei war, dass der Umbau der Kanzleiinfrastruktur eine gewisse Zeit benötigt und der Geschäftsbetrieb möglichst nicht beeinträchtigt werden sollte. Insbesondere die Datenmigration inklusive Datensicherung benötigte viel Zeit. Durch einen pfiffigen Ansatz mit Full- und Incremental Backups konnten wir eine pragmatische Lösung anbieten. Da der Tag der Deutschen Einheit in diesem Jahr ein Mittwoch und die Kanzlei die Restwoche für ein Offsite nutzen wollte, führten wir die Umstellung in diesem Zeitraum durch. Ich steuerte die Umsetzung inklusive Servermigration im Rechenzentrum des Kunden bis zur Inbetriebnahme der neuen und Abschatung der alten Systeme. Wir konnten die Migration in diesem Zeitraum erfolgreich abschließen. Nach der Umstellung stellte ich sicher, dass die berühmten Kleinigkeiten noch behoben wurden. Einige kleine Fehler musste ich abstellen lassen. Weiterhin waren Systemtuning und reibungsloserer Ablauf Schwerpunkt der Arbeiten. Insbesondere musste ich sicherstellen lassen, dass die Datensicherung sowie die Synchronisation der Netzwerkspeicher einhundertprozentig funktionierten. Weiterhin ließ ich einige Notfalltests durchführen, um zu prüfen, ob alle Maß- nahmen der Hochverfügbarkeit auch greifen. Dies war der Fall. So ließ ich die Tests dokumentieren und abnehmen. Nach Ende der Umstellungsarbeiten ließ ich die Dokumentation der Systemlandschaft aktualisieren, ergänzen und abnehmen. Mit dieser Übergabe beendete ich das Projekt erfolgreich.
Berufsausbildung:
1988 - 1991
Studium:
1994 - 1996
1991 - 1994