Technologische Innovationsprozesse aus fachlicher Sicht

Präsentation zum Thema: "Technologische Innovationsprozesse aus fachlicher Sicht"—  Präsentation transkript:

1 Technologische Innovationsprozesse aus fachlicher Sicht
Ein Erfahrungsbericht am Beispiel Bebauungsplan agree® Basis Michael Ther, EUROGROUP CONSULTING | JBFOne 2008

2 Ziel dieses Vortrags Ein systematischer Innovationsprozess im Bereich der Bestandsanwendungen ist die Kernherausforderung für das Management großer Anwendungslandschaften. Rein technologisch getriebene Erneuerungsprogramme haben die Tendenz, die Kontinuität der fachlichen Weiterentwicklung auf die Seite zu drängen. Damit entstehen Risiken, die zum Kern eines Scheiterns werden können. Die FIDUCIA hat mit dem „Bebauungsplan agree® Basis“ ein Entwicklungsprogramm aufgesetzt, das diese Klippe umschifft. Der Erfolg dieses Programms liegt aber nicht nur in der Abarbeitung einer Planung, sondern auch in der „End-to-End“-Sicht auf der gesamten Wegstrecke. Dabei geht es immer wieder darum, fachliche und Engineering-Sichten in ein möglichst enges Miteinander zu bringen. Fazit: Gerade ein kräftiger Engineering-Antritt, wie mit Horizon und dem JBF verbunden, funktioniert nicht ohne eine starke fachliche Sicht, die funktional den Weg vorgibt.

3 Agenda Die laufende Erneuerung von Kernanwendungen als Management-Herausforderung Der Weg der FIDUCIA mit dem Bebauungsplan agree® Basis Der Erfolg kommt aber nicht nur aus dem großen Plan Wie geht es weiter?

4 Agenda Die laufende Erneuerung von Kernanwendungen als Management-Herausforderung Der Weg der FIDUCIA mit dem Bebauungsplan agree® Basis Der Erfolg kommt aber nicht nur aus dem großen Plan Wie geht es weiter?

5 Die Herausforderung: Unter dem Bunten graphischer Oberflächen ruht noch manch Althergebrachtes
In gewachsenen Anwendungslandschaften besteht der Bedarf, vorhandene Altkomponenten funktional und entwicklungstechnisch zu erneuern. Reine Software-Anbieter setzen dafür oft eine neue Produktlinie auf (und machen ihre Kunden damit nicht immer glücklich). Full Service-Anbieter wie die FIDUCIA müssen stärker Koexistenz auf Architekturebene managen. Dieses Spannungsfeld gilt auch für die längerfristige Weiterentwicklung der Backend-Komponenten FIDUCIA- Bankenverfahrens agree®. Das ist auf Seiten des Software-Enginee- rings ein Kraftakt, der jedoch die fachliche Dimension nicht unter sich begraben darf. Das „Legacy“-Problem: Sicher mittlerweile eher ein „Pappkamarad“, da die meisten Oberflächen auf GUIs umgestellt wurden. Aber noch immer ernst zu nehmen auf den „verborgenen“ Ebenen der zugrundeliegenden fachlichen Strukturen der Bestandsverwaltung.

6 Im Backend ist das Thema „Umstellung auf Spartenneutrales Gesamtsystem“ das Hauptthema
Bisher: Spartenorientierung Megatrend: Umbau zur “Spartenneutralität” KK Spar Darlehen TG etc. Workflow-Orientierung Einheitliche Sicht Konditionen (Produkt, Vertrag) Workflow Workflow Workflow Workflow Kundenmitteilungen Vertrag Vertrag Vertrag Vertrag Disposition und Cash Management Abrech-nung Abrech-nung Abrech-nung Abrech-nung Geschäftsvorfall-Dokumentation und Archivierung Kondi- tionen Kondi- tionen Kondi- tionen Kondi- tionen Einheitliches Reporting Reporting Reporting Reporting Reporting KK Spar Spar TG etc. Die Erneuerung der Bestandssysteme ist, auch jenseits moderner Anwendungsoberflächen, eine fachliche Zielsetzung genauso wie ein Ziel des Software-Engineerings. Eine Kernformel, die viele Einzelaspekte zusammenfasst, ist die Zielsetzung der “Spartenneutralität” der Kernkomponenten. Offen bleibt die Frage nach dem richtigen Weg zu diesem Ziel.

7 Andere Full Service-Dienstleister in den Finanz-Verbünden verfolgen verschiedene Ansätze
Sparkassen Informatik/OSPlus* FinanzIT (bis 2007)* GAD Frontend Frontend Front- end Back- end Frontend Backend Backend Backend Nachhaltiger, erfolgreicher Erneuerungsprozess mit umfangreichen Investitionen (OSPlus). Innovationsinitiative geht eher vom Backend aus, auf Basis der bestehenden Systeme. Deutlich geringerer Fokus auf Workflow-Themen im Vergleich z.B. zur FIDUCIA. Frontend-getriebene Erneuerung (Himalaya). Nach der ersten Lieferstufe aber keine systematische Fortsetzung. U.a. Fragen zum Kernbuchungssystem führten zu Fusionsbeschluss und Übernahme des OSPlus. Bisherige Fokus auf einer direkten Migration von BB3 auf Bank21. Seit 2006/07 Fokus auf Koexistenz Frontend/Backend; Managed Evolution-Aktivitäten für BB3. Nicht alle Ansätze waren erfolgreich. Nicht alle Ansätze führen zu einem durchgehenden Kundennutzen. *) In 2008 zur Finanz Informatik fusioniert

8 Der „Mehrfach-Tradeoff“ zur erfolgreichen Bewältigung von Innovationsprozessen geht nur als Gesamtanstrengung Grundvoraussetzung: Stringenter engineering-Pfad erforderlich (z.B. Horizon etc.) Auf gleicher Ebene steht aber: Fachliche Plausibilität muss insgesamt und auf dem Weg gewahrt sein! Oft vergessen wird: Der „Innovationsanteil“ im Projektportfolio darf nicht nur bei der Verabschiedung, sondern muss auch während der Umsetzung akzeptiert sein. Der Innovationsprozess funktioniert nur als Gesamthausanstrengung. Daher muss er eng durch die fachliche Seite mitgetragen und mitentwickelt werden.

9 Agenda Die laufende Erneuerung von Kernanwendungen als Management-Herausforderung Der Weg der FIDUCIA mit dem Bebauungsplan agree® Basis Der Erfolg kommt aber nicht nur aus dem großen Plan Wie geht es weiter?

10 Exemplarisches Thema in der FIDUCIA: Lösungsmodell zur schrittweisen Modernisierung aller Geschäftsarten (1/2) Zentrales Innovationsthema in der FIDUCIA ist die spartenübergreifende Flexibilisierung der bestandsführenden Kernkomponenten: Ursprünglich war eine spartenorientierte Neuentwicklung vorgesehen. In 2007 wurde dann die Konzeption einer schrittweisen horizontalen Ablösung von Funktionsbestandteilen und mehr Koexistenz-Elementen erarbeitet. Auch das überarbeitete Vorgehen bleibt logisch am Horizon-Komponentenmodell ausgerichtet: Z.B. Differenzierung Produkt-Vertrag als Konditionsbaustein. Die ursprüngliche Planung: Nach der Plan-Überarbeitung 2007: Dies dient nur als Beispiel – es geht nicht darum, den Innovationsprozess ausschließlich zur Frage des richtigen architektonischen „patterns“ zu erklären!

11 Exemplarisches Thema in der FIDUCIA: Lösungsmodell zur schrittweisen Modernisierung aller Geschäftsarten (2/2) Die ursprüngliche Planung: Nach der Plan-Überarbeitung 2007: KK SP TE GA DL EM DV KK SP TE GA DL EM DV Prozesse Prozesse Konditionsbaustein: Produkt/Vertrag Konditionsbaustein: Produkt/Vertrag 1 Avisbaustein Avisbaustein 2 3. Zahlungsvereinbarung 3. Zahlungsvereinbarung Limitbaustein Limitbaustein Auszugsschreibung / Mitteilungen Auszugsschreibung / Mitteilungen 2 Abrechnung Abrechnung Konto-Sparte für Konto-Sparte migrieren: + Risikoarm + Beherrschbare Abhängigkeiten - Kein Value-add for business Querschnittlich Teilthemen umsetzen: + Früher Nutzen am Markt - Zusatzfunktion + Ausschnittsweise schnell Spartenneutral - Weniger leicht „transportable“ Agenda 11

12 Aus der Kernüberlegung wurden entlang eines Schalenmodells weitere Themen abgeleitet
Struktur des Schalenmodells: Beispiele für einzelne Maßnahmenfelder: Kern der Weiterentwicklung Neuentwicklung Produktbaukasten Zusammenführung einzelner Sparten ... Bebauungsplan-Bausteine, aus denen sich die grundsätzliche Richtung der Vorgehensweise ergibt. Unterstützende Bausteine Optimierung Zahlungsverkehr Aufbau zentrale Buchungsengine Vereinheitlichen der Limitsteuerung ... E2-Bebauungsplan-Bausteine, die die grundsätzliche Vorgehensweise ergänzen, ohne für das Gesamtbild von agree® Basis Vollständigkeit zu erreichen. Ergänzende Bebauungsplan-Bausteine Prozessorientierung durch Workflow-Administration Integration Geschäftsvorfallnachbearbeitung ... Bebauungsplan-Bausteine, die den agree® Basis Innovationsprozess um wichtige Facetten ergänzen, aber dabei nicht zum logischen Kern des Vorgehens gehören. Direkt umsetzbare Bebauungsplan-Bausteine Optimierung Adressverwaltung Implementierung Vorgaben zu Abgeltungssteuer ... Bebauungsplan-Bausteine, die im Wesentlichen unabhängig bzw. vor Start des agree® Basis Innovationsprozesses möglich und mit der heutigen Architektur weitgehend vollständig umsetzbar sind. Schon geplante oder gestartete Vorhaben Implementierung Anforderungen SEPA Ausbau Vorgangssteuerung in agree® BAP ... Schon vorgesehene oder gestartete Vorhaben und Projekte, die im Sinne des agree® Basis Innovationsprozesses wichtig sind. Grundlegende strategische Infrastruktur-Bausteine Ablösung IMS durch relationale Datenbanksysteme Aufbau von Service- und Datenrepositories ... Bausteine, die ohne direkten fachlichen Bezug den Transformations-prozess hin zur Zielarchitektur unterstützen (z.B. RDBMS).

13 Erster wichtiger Umsetzungsschritt ist das Projekt „Konditionsbaustein“
Mit der Ablösung der „KOSL“-basierten Produktverwaltung geht es im Projekt Konditionsbaustein um die Ablösung einer wesentlichen fachlichen „Legacy“-Struktur: Neuentwicklung Produkt Kontokorrent Logik der Produkt- verwaltung (Standard- und Individualkonditionen) wird auf neue Beine gestellt Saubere Differenzierung zwischen Produkt- und Individualkonditionen Vertrag Kontokorrent Überarbeitung und Anbindung an die bestehenden weite- ren Teilsysteme der Gesamtarchitektur Monats-/Quartals- und Jahresabrechnung Anpassung an Änderungen aus neuer Konditionen- steuerung Bereinigung der bisherigen Abrechnung um Altlasten (z.B. DM-Phase) Bestandsverwaltung Lösungsmodell für die schrittweise Modernisierung für alle Geschäftsarten Schrittweise Überführung weiterer Sparten Nächster Schritt: Darlehen

14 Die Produktpflege wird vereinfacht, Systembrüche und Suche nach Referenzen werden abgeschafft
Alte Welt Neue Welt „Kondition“ BAP „Kondition“ „Zinsart“ BAP IKESA „Zinsart“ „Zinsart“ „Zins“ Medienbruch BAP / IKESA-Steuerung Logisch komplexe, mehrstufige Abhängigkeiten Numerische Schlüssel Einheitliche, logische Strukturierung In der neuen Welt findet der Nutzer zusammengehörige Daten an einem Ort Keine numerischen Schlüssel, sondern sprechende Bezeichnungen

15 Nicht geeignet, da dann 1. QA = JAB
Derzeitige Roll Out-Planung und Eckpunkte der Umstellung aus Sicht der Banken Q2/2009 Q3/2009 Q4/2009 Q1/2010 Q2/2010 Q3/2010 Q4/2010 BAP-Releases 3.5. 3.6. 3.7. 3.8. I. Pilotierung (mit BAP 3.5) Nicht geeignet, da dann 1. QA = JAB II. Umstellungs- Tranchen Tranche A Tranche B Tranche C ggf. Tr. D Vorgehen bei der Umstellung auf die neue Konditionenverwaltung Vollständige Umstellung der KK-Konditionen in einem Schritt: Alle KK-Produkte und Konten werden in das neue System überführt. Eine Pflege mit dem alten System ist danach nicht mehr möglich Fachlich vollständige Überleitung: Bei der Umstellung werden alle bestehenden Konditionseinstellungen vollständig übernommen Einfache und klare Produkt- und Vertragsstrukturen bleiben erhalten Verschachtelte Konditionsstrukturen werden bei der Überführung als zusätzliche Produkte abgebildet Bereinigung der Strukturen vor der Umstellung möglich: Testumstellung mit entsprechenden Auswertungen stellen den Banken vorab die neue Welt dar, inklusive zusätzlich resultierender Produkte aus der Migration Dies erlaubt den Banken eine Bereinigung ihrer Struktur VOR der endgültigen Umstellung

16 Nach dem „Konditionsbaustein“ werden in den Folgereleases weitere wesentliche Schritte folgen
Kern des agree® Basis Innovations-prozesses (Schematische Darstellung) Kombination aus horizontaler Abschichtung und Spartenablösung Der Neubau des spartenneutralen Konditionsbausteins und die Anpassung der Abrechnung für die Sparte Kontokorrent mit BAP 3.5 stellt den wichtigen ersten Schritt des Innovationsprozesses dar. Als nächstes erfolgt die komplette Ablösung der Sparte Darlehen inklusive Nutzung des Konditionsbausteins mit Release 3.7 durch Integration der Sparte Darlehen in KK. KK DL TE GA SP BAP 3.7 Konditionsbaustein BAP 3.5 BAP 3.8 Abrechnung Avisbaustein BAP 3.8 Zahlungsbaustein Die Kombination aus dem horizontalen Abschichten einzelner Bausteine durch Neuentwicklung und der Spartenablösung gestattet es, das gesetzte Innovationsziel in einfacher und kostengünstigerer Weise zu erreichen. Limitbaustein BAP 3.5 Auslieferungstermine gemäß aktueller Planung.

17 Zwischenfazit Projekt-Road Maps dürfen nicht nur aus der Logik von Engineering-Aspekten abgeleitet sein. Mit dem „Bebauungsplan agree® Basis“ hat die FIDUCIA eine Konzeption entwickelt, die diesen Anforderungen entspricht und in Kürze konkrete für die Nutzer fassbare Effekte haben wird. Der technokratische Plan allein sichert den nachhaltigen Erfolg dieses Ansatzes aber noch nicht. Es geht auch um die Form der Umsetzung. Ansätze, fachlich „durchs Tal der Tränen“ gehen zu müssen, ist nur durchhaltbar, wenn er nicht der Fachseite auferlegt wurde, sondern von ihr getrieben wurde.

18 Agenda Die laufende Erneuerung von Kernanwendungen als Management-Herausforderung Der Weg der FIDUCIA mit dem Bebauungsplan agree® Basis Der Erfolg kommt aber nicht nur aus dem großen Plan Wie geht es weiter?

19 Erfolgsfaktoren diesseits des richtigen „big pictures“ liegen auch im Modus der Umsetzung
Der Endbenutzer als Störfaktor: Den Endbenutzer kümmert normalerweise nicht, ob die Kommunikation zwischen dem Middle Tier und dem Backend asynchron ist oder synchron, sondern ob die fachlich richtigen Fehlermeldungen dargestellt werden. Endbenutzer wollen es „einfach“ – im Zweifel einfacher als bisher (KOSL) – aber auch nicht ganz anders als bisher (voraussichtlich dito KOSL, das wird sich zeigen). Sauber engineerte Architektur scheint leider oft inperformant zu sein: Den OO-Klassendesigner kümmert viel zu wenig, was der OO-Mapper an JOIN- Kaskaden daraus macht ... Der Service-Designer kennt normalerweise den Begriff „Latenzzeit“ als Umschreibung der Marktdurchdringung der neuesten JAVA- Standardversion ... Erstaunlicherweise haben die meisten Reengineering-Projekte erst mal signifikante Schwierigkeiten im Performance-Bereich! Modernes Software-Engineering erscheint oftmals zunächst als Auftürmen von Komplexität (100 generische Wrapper-Klassen für einen realen Aufruf ...). Die richtige Formel heißt dagegen: Durchgängiges Projektverständnis im Sinne einer „End-to-end“-Sichtweise.

20 „End-to-end“ bedeutet, sowohl von Fach- wie von IT-Sicht über den eigenen Bereich hinaus neugierig zu sein Pflichten- heft Fach- und DV-Spezifi- kation Implemen- tation Tests Schulung und Kommuni- kation Roll Out Herausforderungen für die Fach- und Produktsicht: In allen Schritten ist von der Fachseite aktiv „mitzudenken“, was aus veränderten Engineering-Ansätzen, z.B. neuen Komponentenschnitten, an Veränderungen resultiert. Herausforderungen für die Entwicklungssicht: Neugier darauf, wie die bestehenden Lösungen in der konkre- ten organisatorischen Realität bei den Nutzern aussehen und welche Nebenwirkungen sich aus einer Veränderung ergeben. Sensibilität für durchgängige Effekte: „End-to-end“-Sichtweise bei allen Projektbeteiligten stärken!

21 Beispiel: Fachkonzeption
Pflichten- heft Fach- und DV-Spezifi-kation Implemen-tation Tests Schulung und Kommuni-kation Roll Out Welche funktionalen Konsequenzen resultieren aus der Umsetzung von neuen Komponentenschnitten, zum Beispiel aus funktionalen Auftrennungen entlang des Horizon-Domänenmodells. Beispiel: Neue fachliche Strukturierung im Zahlungsverkehr zwischen Auftragsannahme, Sperrenprüfung und Ausführung; Aufnahme von Informationen in die Listen-Dokumentation. Die fachliche Spezifikation von Reengineering-Projekten geht über die Formel einzelne Topanforderungen („online-Buchung“) + „die Restfunktionalität allgemein as is“ hinaus – das durchzusetzen ist aber noch immer schwer! Vorausdenken, was sich für Mengengerüste für die Benutzer ergeben (z.B. Anzahl der Produktparameter). Welche Nebenwirkungen ergeben sich für scheinbar „entlegene“ Dritt-Themen (z.B. Reportingstrukturen, Druckoutput).

22 Agenda Die laufende Erneuerung von Kernanwendungen als Management-Herausforderung Der Weg der FIDUCIA mit dem Bebauungsplan agree® Basis Der Erfolg kommt aber nicht nur aus dem großen Plan Wie geht es weiter?

23 Wie geht es weiter? Die nächsten wichtigen Schritte:
Einführung Konditionsbaustein mit Pilotierungen im Frühjahr 2009 Einführung GVN Stufe I Entwicklung Spartenkonsolidierung Darlehen / KK Start Mitteilungsmanagement in 2009

24 Zusammenfassung Technologische Innovation wird nur erfolgreich sein bei einem engen Dialog; dies gilt insbesondere für Fach- und Technik-Seite. Koexistenzlösungen mit graduellen Schritten sind dazu eher geeignet als „harte“ Großprojekten mit entsprechenden Migrationen. Dieser graduelle Weg ist für agree® Basis in der FIDUCIA definiert. Er verlangt in der konkreten Umsetzung eine „End-to-End“-Sichtweise. Diese Sichtweise resultiert nicht automatisch aus der Nutzung von JAVA-Frameworks, sondern betrifft einen Modus der Arbeit in Projekten, der stark vom Blick über den Tellerrand und damit auch stark „anti-fordistisch“ geprägt ist. Innovation ist nicht gleichzusetzen mit dem richtigen Software-Engineering, dieses ist stattdessen als (wesentlicher) Teilaspekt eines umfassenderen Ansatzes zu verstehen.

25 Fragen? – Diskussion? Auszug Projekterfahrungen: Michael Ther Vorstand
EGC EUROGROUP CONSULTING AG Hessenring 89 61348 Bad Homburg Telefon: Telefax: Mobil: Mail: Internet: Auszug Projekterfahrungen: Mehrere Projekte Handlungsoptionen Kernbanksystem, u.a.: Einsatzoptionen Standardsoftware, Kooperationsoptionen Fachlicher Bebauungsplan Kernbanksystem Technische Zielarchitektur Kernbanksystem Migration Kernbanksystem einer Großsparkasse zum Verbandsrechenzentrum Weitere Schwerpunkte: IT-Strategie, ORG/IT- Assessment sowie Neuausrichtung ORG/IT

26 Ihr IT-Partner Vielen Dank