IT Architecture-Driven Program Management. IT-Architektur als Grundlage zur Steuerung großer IT-Transformationen

Transkript

1 IT Architecture-Driven Program Management IT-Architektur als Grundlage zur Steuerung großer IT-Transformationen Oktober 2013

2 Die Entwicklung neuer Industrieperspektiven unterstreicht die Kernaufgabe von Ritzenhoefer & Company: die Unterstützung unserer Klienten, unverwechselbare, nachhaltige und wesentliche Verbesserung in ihrer Leistung zu erzielen. Wir veröffentlichen unsere Ansichten und die von externen Experten, um die Praxis zu verbessern und unseren Lesern Einblicke zu gewähren und sie mit Fakten zu versorgen, auf Basis derer Geschäfts- und Richtlinienentscheidungen getroffen werden können. Im Übrigen entspricht die von Dritten geäußerte Meinung nicht zwangsläufig der Meinung von uns. Dementsprechend übernehmen wir für fremde Meinungen keine Verantwortung. 2

3 Die Ausgangslage bei komplexen IT-Transformationen Unternehmerische Transformationen wie z. B. die Akquisition eines Wettbewerbers, das Outsourcing von Geschäfts- und IT-Prozessen oder die Erneuerung von IT-Kernsystemen bedingen signifikante Änderungen der bestehenden IT-Landschaft. Die Durchführung einer solchen Transformation ist oft mit erheblichen finanziellen und operativen Risiken für das Unternehmen insgesamt verbunden, denn sie bedeutet einen massiven Eingriff in die häufig über Jahre gewachsene feine Abstimmung der IT-Systeme untereinander und die damit verbundene Abbildung der Geschäftsprozesse. Die IT-Transformation erweist sich damit als eine komplexe Gesamtaufgabe, die in großen Teilen nicht durch lokal gekapselte Einzelaktionen bewältigt werden kann, sondern die durchgängige Betrachtung und Strukturierung des Gesamtbildes erfordert. Das Wissen darüber, wie die einzelnen Komponenten sowohl fachlich als auch technisch zusammenwirken und was zu tun wäre, um neue Komponenten sinnvoll in die bestehende Landschaft zu integrieren bzw. bestehende Komponenten aus dieser herauszulösen, ist jedoch meist über verschiedene fachliche und technische Organisationseinheiten verteilt. Mehr noch, es existiert in den meisten Fällen keine gemeinsame Sprache, die eine schnelle und übergreifende Abstimmung der Know-how-Träger und damit die konsistente Formulierung eines Zielbilds inklusive der vielfältigen Abhängigkeiten ermöglichen würde. Eine reine Top-down-Planung ohne vorausgehende fundierte Zielbild-Abstimmung gerät damit zum Vabanquespiel mit hohem Risiko in Bezug auf Kosten, Zieltermine und letztendlich das Gelingen der gesamten Transformation. Akquisitionen bedingen oft größere Änderungen an der IT-Landschaft Die hohe Komplexität großer IT- Transformationen birgt erhebliche Risiken für die Planung Depot- Bank Zertifikate/ Derivate Kredite Transactionservices Stamm/ Markt- Daten Vertrieb Depotbank- Systeme Groß- und Millionenkredite Produkt- Datenbank Zertifikate CRM-System Pricing CashPooling Karten Kreditportal Front- Office Back- Office Depotbankfunktion, Ordermanagement, Bestandsführung Förderkr. Front Arena Summit Bloomberg Disposition Sicherh. Bankrechner Bewertung SEPA Swift Kredite Auslands-ZV Clearing Dokumentengesch. Abwicklung Vorsorge Steuer Passiv-Verw. WP-Services Kunden, Konten, Geschäfte, Kontokorrent KERNBANKENSYSTEM Banksteuerung (Rechnungswesen, Meldewesen, Risiko-Controlling,...) Börsen, Ratings, sonstige Marktinfodaten Gattungsdaten Reuters / Bloomberg Terminals BloombergO IFRS / HGB SAP Rechnungswesen / FI Bilanzierung Konsolidierung Abgeltungssteuer Konzernsteuerung Meldewesen Marktpreisrisiko Risiko Warehouse Risiko Liqui-Mgmt. Limitsystem Länderrisiko Adressenausfallrisiko Planung & Contr. Compliance Rating AML SAP-Rechnungswesen / CO Management-Informations-System Aktiv- Passiv Zentrales Dispositionssystem Rückfluss- / Zinsmgmt. Das High-Level-IT-Zielbild dient als Leuchtturm, an dem sich die IT- Transformation ausrichtet System ohne Änderung System betroffen System zu übernehmen Neues System Externer Service Abbildung 1: Beispiel eines High-Level-IT-Zielbilds Startpunkt für die Umsetzungsplanung einer IT-Transformation ist häufig die Vereinbarung eines High-Level -Zielbilds (siehe 2

4 Abbildung 1), das zumindest die wesentlichen Ziel-Anwendungen neue Anwendungen zusammen mit den verbleibenden Anwendungen enthält. Ein solches High-Level -Zielbild dient der anschaulichen Vermittlung des Ziels für das Management sowie als klar sichtbarer Leuchtturm, an dem sich das Transformationsvorhaben ausrichtet. Für die konkrete Umsetzungsplanung und Strukturierung erweist es sich jedoch als nur bedingt geeignet, da es die dahinterliegende Komplexität nicht abbildet. Zur Beherrschung solch hochkomplexer Aufgaben bietet sich stattdessen ein dreistufiges Vorgehen an, das die konsistente Zerlegung der komplexen Gesamtaufgabe in parallel ausführbare Teilaufgaben sowie ein durchgängiges Projektmonitoring ermöglicht: Das Repository-basierte Management der IT- Transformation besteht aus drei Stufen 1. Vereinbarung einer gemeinsamen Beschreibungssprache 2. Repository-basierte Integrationsanalyse 3. Repository-basierte Projektsteuerung Die einzelnen Stufen dieses auf Architektur-Repository basierten Management-Ansatzes werden im Folgenden erläutert. Gemeinsame Sprache für die Transformationsaufgabe Eine wesentliche Voraussetzung, die die umsetzungstaugliche und sowohl für Fachseite als auch für IT nachvollziehbare Formulierung der IT-Transformationsaufgabe ermöglicht, ist die Vereinbarung einer gemeinsamen projektübergreifenden Sprache. Diese ermöglicht es, die Elemente des Zielbilds klar zu benennen und hierauf eine Umsetzungsplanung und ein Projektmonitoring aufzusetzen. Voraussetzung für die Formulierung eines übergreifend konsistenten Zielbilds ist eine gemeinsame Sprache Abbildung 2: Beispiel für die Beschreibung des Zielbilds durch die Elemente Anwendungen, Services und Schnittstellen Hier hat sich bewährt, eine möglichst einfache Sprache mit nur wenigen, aber allseits verständlichen Elementen zu wählen. 3

5 Konkret hat sich die Verwendung der folgenden Elemente als effizient und einfach vermittelbar erwiesen: 1. Anwendungen: Anwendungen entsprechen dem verbreiteten Anwendungsbegriff und können häufig einem bereits vorhandenen Anwendungsverzeichnis entnommen werden. Die Sprache zur Beschreibung des Zielbilds besteht aus drei einfachen Elementen 2. Services: Ein Service ist Teil einer Anwendung und bezeichnet die Fähigkeit der Anwendung, Daten oder Funktionen für andere Anwendungen zur Verfügung zu stellen bzw. diese von anderen Anwendungen entgegenzunehmen. Wichtiger Teil der Beschreibung eines Service ist seine fachliche Aufgabe. 3. Schnittstellen: Eine Schnittstelle bezeichnet den konkreten Austauschweg von Daten oder Berechnungen zwischen (zwei) Services. Diese drei Elemente bilden die Basis für eine durchgängige, konsistente und weitgehend vollständige Beschreibung des Zielbilds. Alle drei können jeweils durch geeignete fachliche und technische Beschreibungsattribute weiter detailliert werden (siehe Abbildung 2). Ein wesentlicher Vorteil dieser speziellen Wahl der Beschreibungssprache besteht darin, dass die genannten Elemente keine abstrakten Größen, sondern implementierbare Objekte darstellen. Für jedes dieser Objekte lässt sich eindeutig feststellen, ob es konzipiert, implementiert oder getestet ist. Ein Zielbild- Repository, das auf Grundlage solcher Elemente formuliert ist, bildet damit auch gleichzeitig die Gesamtheit aller zu erbringenden Arbeitspakete zur Implementierung des Zielbilds ab. Dies eröffnet, wie weiter unten erläutert, die Möglichkeit der Repository-basierten Projektsteuerung. Die Repository-basierte Integrationsanalyse Auf Grundlage der vereinbarten Beschreibungssprache wird das Zielbild mit den beteiligten Wissens- und Entscheidungsträgern erstellt und in einem zentralen Repository zusammengeführt. Diese sog. Repository-basierte Integrationsanalyse ist ein hochgradig iterativer Prozess, bei dem man typischerweise zunächst mit den schnell greifbaren Informationen startet z. B. mit Informationen aus bereits vorhandenen Schnittstellen oder Anwendungsverzeichnissen und diese dann in Form von Workshops und Expertengesprächen aktualisiert und ergänzt. Die Informationen zum Zielbild werden in einem zentralen Repository konsistent zusammengeführt 4

6 Wichtig ist, die dynamisch wachsende Informationsfülle in einem zentralen Repository, dem sog. Repository Master, während des gesamten Prozesses konsistent zusammenzuführen. Ggf. ist es erforderlich, in Workshops an Teilausschnitten des Repository zu arbeiten, jedoch können aufgrund der hohen Vernetzung letztendlich Vollständigkeit, Richtigkeit und Konsistenz der identifizierten Elemente nur in der Gesamtsicht sichergestellt werden. Durch die Visualisierung werden Konvergenzgeschwindigkeit und Nutzungsgrad des Repository erhöht Abbildung 3: Grafische Darstellung des Zielbild-Repository Die Speicherung des Repository-Dateninhalts kann durchaus in einer einfachen Datenbank oder in Form von Excel-Tabellen erfolgen. Zusätzlich ist jedoch die Möglichkeit einer grafischen Darstellung (Abbildung 3) inklusive vielfältiger Detailansichten ein immenser Vorteil für eine schnelle Konvergenz und durchgehende Wahrnehmung des Zielbilds. Durch diese Veranschaulichung finden die Elemente des Repository schnellen Eingang in Fach- und IT-Konzepte das Zielbild-Repository wird zur Lingua franca des Gesamtprojekts. Bleibt letztlich die Frage, ob und mit welcher Geschwindigkeit die Repository-basierte Integrationsanalyse auf ein weitgehend stabiles Zielbild hin konvergiert. Messungen des Stabilisierungsverhaltens in konkreten Projekten, dargestellt in Abbildung 4, zeigen einen charakteristischen Verlauf in drei Phasen: Phase 1 Initialanalyse: Die einzuführenden und von der Einführung betroffenen Systeme werden in ihrer Ursprungsumgebung analysiert. Die Zahl der identifizierten Services und Schnittstellen steigt zunächst stark an. 5

7 Phase 2 Einbettungsanalyse: Identifizierte Services und Schnittstellen werden mit der Zielumgebung abgeglichen. Da die Zielumgebung bereits über eine reichhaltige Funktions- und Schnittstellenlandschaft verfügt, werden viele der zunächst als neu zu implementierend identifizierten Elemente obsolet die Zahl der zu implementierenden Elemente sinkt dadurch wieder und schwankt um einen sich stabilisierenden Mittelwert. Phase 3 Stabilisierung: Die Schwankungen aufgrund von Detailerkenntnissen nehmen weiter ab, das Zielbild-Repository wird stabil und kann schließlich in vollem Umfang für die Projektumsetzung genutzt werden. Die Integrationsanalyse konvergiert in drei Phasen zu einem stabilen Zielbild Abbildung 4: Typischer Verlauf der Konvergenz des Zielbild-Repository in drei Phasen. Dargestellt ist hier der Verlauf bezüglich der Services und der Schnittstellen. Die Dauer vom Beginn der Initialanalyse bis zum Abschluss der Stabilisierung liegt in einem Bereich von wenigen Wochen bis zu einigen Monaten, je nach Komplexität des Transformationsprojekts. Bezogen auf eine Gesamtdauer großer Transformationsprojekte von mehreren Jahren erscheint damit die Investition in die Repositorybasierte Integrationsanalyse als ein durchaus vertretbarer Aufwand. Repository-basierte Projektsteuerung Im dritten Schritt des Repository-basierten Vorgehens wird die umzusetzende IT-Transformation auf Grundlage der weitgehend vollständig und konsistent erfassten Zielbild-Elemente strukturiert und ein Projektmonitoring zur faktenbasierten Projektsteuerung aufgesetzt. Zwei Aspekte sind hierbei von besonderer Bedeutung: Zunächst kann das Repository als Liste der umzusetzenden Arbeitspakete genutzt werden und dient deshalb als Grundlage zur Auf Grundlage des Repository werden Projektplanung und -steuerung aufgesetzt 6

8 Strukturierung des Projekts in Form von Teilprojekten und ggf. auch Bauabschnitten. Jedes Teilprojekt erhält seinen Arbeitsvorrat in Form von umzusetzenden Services und Schnittstellen sowie von einzuführenden, zu modifizierenden oder abzulösenden Anwendungen. Teilprojektintern kann damit die Umsetzung dieser Arbeitspakete geplant werden. Abbildung 5 zeigt schematisch eine solche Verteilung. Die Zuordnung von Arbeitspaketen zu Teilprojekten erfolgt auf Basis der Repository-Information Abbildung 5: Zuordnung von Services und Schnittstellen des Repository zu Teilprojekten (schematische Darstellung) Darüber hinaus wird der Umsetzungsfortschritt über den an die Teilprojekte vergebenen Arbeitsvorrat faktenbasiert gemessen und mit der Umsetzungsplanung abgeglichen. Engpässe und Verzögerungen werden dadurch frühzeitig erkannt. Über eine Extrapolation auf Grundlage des gemessenen Projektfortschritts lässt sich zusätzlich der erwartete Umsetzungsgrad zum geplanten Zieltermin bestimmen. Abbildung 6 zeigt schematisch ein solches Projektmonitoring. Abbildung 6: Fortschritts-Monitoring am Beispiel der Schnittstellen. Ins Monitoring werden die Umsetzungsphasen Konzeption, Implementierung und Test einbezogen. 7

9 Insgesamt dient das Repository-basierte Vorgehen dazu, die hohe Komplexität großer IT-Transformationen besser beherrschbar zu machen. Dazu trennt die Repository-Methodik die Identifikation der Arbeitspakete und Abhängigkeiten von der Umsetzungsplanung. Durch die Vereinbarung einer gemeinsamen Sprache und den Aufbau eines konsistenten Gesamtzielbilds im zentralen Repository wird zunächst die Identifikation von Arbeitspaketen und Abhängigkeiten sehr erleichtert. Danach dient das Repository als faktenbasierte Datenbasis zur Steuerung und zum Monitoring der IT- Transformation. Zusammenfassung Die Komplexität großer IT-Transformationen kann durch den Einsatz eines auf Architektur-Repository basierten Vorgehens deutlich besser beherrscht werden. Notwendige Voraussetzung zum Aufbau des Repository ist die Vereinbarung einer einfachen gemeinsamen Sprache zur detaillierten Beschreibung des Zielbilds. Über den Prozess der Repository-basierten Integrationsanalyse werden die von der Transformation betroffenen Anwendungen, Services und Schnittstellen identifiziert und ein konsistentes Zielbild wird als Blaupause für die Umsetzung erstellt. Das Repository dient dann sowohl der Projektplanung als auch der konkreten Projektsteuerung als wertvolle Informationsbasis. Insbesondere wird es genutzt: o zur eindeutigen Verteilung der Arbeitspakete auf Teilprojekte o zur faktenbasierten Messung des Projektfortschritts auf Teilprojekt- und auf Gesamtprojekt-Ebene o zur frühzeitigen Erkennung von Engpässen und Verzögerungen sowie zur Projektion auf den erwarteten Umsetzungsgrad zum Zieltermin o als Ausgangsbasis für die Planung und Umsetzung späterer Erweiterungen der IT-Landschaft und zur schnellen Beseitigung von Störungen im Betrieb Komplexität großer IT- Transformationen besser beherrschen Repository-basiertes Programmmanagement in drei Schritten aufsetzen Projekt über den Abgleich mit Repository faktenbasiert steuern 8

10 Ritzenhoefer & Company Ritzenhoefer & Company ist eine Management-Beratung, die sich auf Transformation Consulting spezialisiert hat. Zu unseren Klienten gehören vornehmlich Großbanken und Versicherungen. Wir konzentrieren uns auf Themen, die die Umsetzung von Transformationen erfolgreicher machen. Insofern verstehen wir uns als Spezialist unter den Beratern. Management-Beratung Für Unternehmen sind Großtransformationen oft einmalige Programme. Durch unsere Spezialisierung auf genau diese einmaligen Transformationen helfen wir unseren Klienten besonders effektiv und zielorientiert. Fokus auf Großtransformationen Alle unsere Berater haben Großtransformationen als Programmleiter verantwortet oder hochspezialisiert unterstützt. Jeder von uns kennt die Herausforderungen und Risiken auf dem Weg zum erfolgreichen Abschluss von Transformationen. Wir unterstützen in allen Phasen der Transformation mit spezialisierten Teams. Wir messen uns daran, Großtransformationen erfolgreicher zu machen. Langjährige Projekterfahrung Dr. habil. Stephan Güsken ist Expert Associate Principal bei Ritzenhoefer & Company und war nach seiner Promotion in theoretischer Physik an der Bergischen Universität Wuppertal über mehrere Jahre als Wissenschaftler und Dozent tätig. Er habilitierte in theoretischer Physik mit den Schwerpunkten computergestützte Simulation komplexer Systeme und High-Performance-Computing. Bei der Postbank AG war Dr. Güsken als Chefarchitekt verantwortlich für die Multikanaltransformation und begleitete als Leiter des Service- und Interface-Centers und Head of Architecture des internationalen Banking Industry Architecture Network BIAN den Aufbau eines zukunftsweisenden Architekturmanagements. Nach mehreren Jahren als Consultant mit Schwerpunkt serviceorientierte High-Performance- Architekturen ist Dr. Güsken heute auf IT-Großtransformationen im Finanzsektor spezialisiert. Sie erreichen Dr. Güsken unter Derek Zeiler ist Principal bei Ritzenhoefer & Company. Er verfügt über langjährige Erfahrung in der IT-Projekt- und IT-Strategie-Beratung sowie in der Durchführung und dem Management komplexer IT-Projekte. Vor dem Wechsel zu Ritzenhoefer & Company war er mehrere Jahre als Programm- und Projektleiter bei großen Umsetzungsprojekten in verantwortlichen Positionen tätig. Auf Grundlage dieser Erfahrungen entstand seine Expertise im Management komplexer IT- Transformationen, sowohl unter dem Blickwinkel der IT als auch unter dem Aspekt von Organisations- und Kulturveränderungen. Sie erreichen Herrn Zeiler unter 9

11 Ritzenhoefer & Company Hafenspitze Speditionstraße Düsseldorf Phone: