VON DER KUNST, AN ZIELEN FESTZUHALTEN Regulatorik, Industrialisierung und Digitalisierung als Treiber von Transformationen Christian Böhning Dr. Mirko Schiefelbein Christian Schneider
Dezember 2013 White Paper Copyright © COREtransform GmbH
1 Einleitung Finanzinstitute stehen angesichts der Entwicklungen im Bankenmarkt weiterhin vor großen Herausforderungen. Die regulatorischen Vorgaben, die dynamisch fortschreitende Industrialisierung, die zunehmende Bedeu tung internationaler Märkte und das sich im Rahmen der Digitalisierung wandelnde Kundenverhalten erfordern ein hohes Maß an Agilität. Gleich zeitig führen die verschärften Eigenkapitalanforderungen an die Finanzin stitute zu einer Konzentration auf Kostensenkung, die Handlungsspiel räume einengt und die Gestaltungsmöglichkeiten verknappt. Für Banken ist in dieser Situation erfolgskritisch, die Voraussetzungen für ein effektives und effizientes Agieren im Markt zu schaffen. Neben der Diversifizierung des Produktportfolios und der Kooperation mit Partnern spielt die Standardisierung von Produkten, Prozessen und Plattformen im Rahmen der IT eine Schlüsselrolle. Finanzinstitute können ihre Kosten basis stabilisieren und ihre Effizienz steigern; sie erschließen sich darüber hinaus ein neues Nutzenniveau, das mit auf Individualsoftware basie renden Systemen nicht zu erreichen ist (Abb. 1). Für Banken bedeutet dies, über Jahrzehnte gewachsene Strukturen zu modernisieren und sich gemäß heutigen und zukünftigen Erfordernissen zu transformieren. Abschlüsse Standardsoftwareverträge für Banken
Erschließung eines neuen Nutzenniveaus S-Curve current platform
Benefit of IT platform
302
Standardisierung der IT als Schlüssel für Agilität
S-Curve new platform
Step change 350 Individual software approach
390
Standard software approach
1.908 439
427 2007 2008 2009 2010 2011 Total Quellen: IBS 2012; COREinstitute
Window of opportunity for platform change
Incremental investment
Abbildung 1: Transformation auf Standardsoftware
Neben den ökonomischen und nutzenorientierten Erwägungen sind zwei weitere Faktoren zentral, um eine Entscheidung für eine Transformation treffen zu können. Zum einen ist zu identifizieren, welche der am Markt für Standardsoftware verfügbaren Systeme die optimale Lösung für den Geschäftsfokus der Bank bieten. Zum anderen ist entscheidend, über die Fähigkeit und das Know-how zu verfügen, die mit der Transformation verbundenen Herausforderungen zu bewältigen und die Transformation zum Erfolg zu führen.
Fähigkeit und Know-how zur Transformation entscheidend
Im Folgenden erörtern wir unsere Erfahrungen hinsichtlich dieser Heraus forderungen und thematisieren die Migration von Kernbanksystemen auf Standardsoftware vor dem Hintergrund der Gestaltung und Steuerung hochkomplexer Programme. Dazu gehen wir zunächst auf die Situation im Bankenmarkt ein, geben einen Überblick zu den Lösungsanbietern von Standardsoftware für Banken und skizzieren die zentralen Herausforde rungen der Transformation. Anschließend entwickeln wir Lösungsmuster, die unserer Erfahrung nach eine tragfähige Basis bilden, um hochkomplexe 2 An Zielen festhalten © CORE 2013
Programme adäquat und zielgerichtet steuern zu können. Wir orientieren uns zunächst an den Phasen der Transformation und konzentrieren uns dann auf die thematischen Schwerpunkte des Entscheidungsmanage ments, der Methoden und Tools, der am Programm intern und extern Betei ligten und ihrer Fähigkeiten sowie des Go-lives, um damit zentrale Instru mente für das Management von Komplexität aufzuzeigen. In einem letzten Schritt konsolidieren wir diese Aspekte mit Blick auf die Herausforderungen der Transformation.
2 Herausforderungen einer technologiegetriebenen Transformation Transformationen sind eine Antwort auf die Herausforderungen im Banken markt und bilden zugleich eine Herausforderung für die Bank selbst. Die Herausforderungen im Bankenmarkt liegen erstens in der Verschärfung der regulatorischen Vorgaben. Die zunehmende Frequenz der Regulie rungsmaßnahmen (Basel, IFRS, SOX, SEPA, FATCA) bindet Energien und engt Handlungsspielräume ein. Die Herausforderungen liegen zwei tens in der notwendigen Industrialisierung. Sie ist gekennzeichnet durch hohe Kosteneffizienz, standardisierte Prozesse und Produkte, Skalierbar keit sowie durch hohe Flexibilität. Hinzu kommt schließlich das Eintreten neuer, teils branchenfremder Teilnehmer in den Markt für Finanzdienst leistungen. Im Rahmen der Digitalisierung greifen Bank Attacker mit inno vativen Konzepten das Geschäft etablierter Banken an, fragmentieren deren Wertschöpfungsketten und kreieren dadurch Mehrwert für Kunden bzw. schöpfen bisher den Banken zufließende Erträge ab. Für diese Herausforderungen müssen sich Banken flexibilisieren, um umfassend und schnell auf Änderungen reagieren zu können. Die Industrialisierung der Geschäftsmodelle und Wertschöpfungsketten von Finanz instituten hat deren Abhängigkeit von Technologien deutlich gesteigert. Zugleich hat sich gezeigt, dass sich Retailbanken nicht primär durch die IT im Kernbankbereich von Wettbewerbern abheben können. Mit der IT im Sinne eines Enablers sind vielmehr die Voraussetzungen zu schaffen, damit sich Banken durch Produkte und Services in Verbindung mit ihren Marken von Wettbewerbern differenzieren können.
Regulatorik, Industrialisierung und Digitalisierung als Treiber
Voraussetzungen für Agilität schaffen
Die gegenwärtige Technologiebasis der Banken erfüllt diese Anforderungen zumeist nicht oder nicht ausreichend. Die die Prozesse der Fachbereiche abbildenden und unterstützenden IT-Landschaften sind zumeist proprietär gewachsene Individualentwicklungen, deren Kernsysteme auf Host-Tech nologien mit veraltenden Programmiersprachen wie COBOL oder PL/1 basieren. Gemäß sich ändernden Geschäftsanforderungen wurden diese Kernsysteme sukzessive durch neue Funktionen und Technologien erwei tert. Zudem wurden selten semantische oder technologische Standards für die Kommunikation zwischen den Systemen definiert. Im Ergebnis sind fragmentierte Softwarelandschaften aus Hunderten IT-Applikationen entstanden, in denen sich das Technologiespektrum der letzten Jahrzehnte wiederfindet. Daher entschließen sich viele Finanzinstitute, ihre IT auf Standardsoftware zu transformieren, und greifen auf Gesamtbanksysteme oder Spezial lösungen für einzelne Segmente zurück. In den letzten fünf Jahren sind trotz der eskalierenden Krise mehr als 1.900 Neuverträge zwischen Ban
Kosten senken – Potentiale erschließen
3 An Zielen festhalten © CORE 2013
ken und Providern von Standardsoftware geschlossen worden (Abb. 1, links). Ziel der Transformation ist, mit den ohnehin notwendigen Ressour cen und Investitionen sowohl Effizienz als auch Effektivität zu steigern und sich ein im Vergleich zu den Altsystemen überproportionales Nutzen niveau zu erschließen, wofür zunächst ein geringerer Nutzen bei höheren Investitionen in Kauf genommen werden muss (Abb. 1, rechts). Übersicht Anbieter von Standardsoftware für Banken Europe
Asia
North- & South America
Oceania
Quellen: IBS 2012; COREinstitute. Die abgebildeten Logos stehen im Eigentum der jeweiligen Unternehmen
Abbildung 2: Globale Übersicht über Standardsoftware-Provider
Um auf dem mit mehr als 90 Anbietern und über 100 Systemen diversifi zierten Markt für Standardsoftware-Systeme (Abb. 2 sowie Übersicht im Anhang) die optimale Softwarelösung und -kombination zu identifizieren, stehen Banken verschiedene Datenpools und Analysequellen zur Verfü gung. Mit ihrer Hilfe lässt sich für spezifische Segmente von Finanzin stituten bestimmen, inwiefern einzelne Geschäftsfelder durch Standard software adressiert und funktionale Domains realisiert werden können. Dies erlaubt, passgenaue Lösungen für Prozesse und Bankfunktionen zu identifizieren.
IT- und Business-seitig die optimale Standardsoftware identifizieren
Die mit der Entscheidung für eine Transformation verbundenen Heraus forderungen für Banken deuten sich in der Größenordnung an, in der sich die Transformation eines Kernbanksystems typischerweise bewegt: eine Gesamtlaufzeit von mehreren Jahren, in denen Hunderte Schnittstellen angepasst und Tausende Projektmeilensteine abgearbeitet werden, in denen Tausende Workshops und Zehntausende Testfälle anstehen, an denen Zehntausende Mitarbeiter sowie Millionen Kunden und Konten mit Milliarden Transaktionen beteiligt sind und in denen es um Hunder te Millionen Einsparungen und Milliarden-Investitionen geht. Damit soll eine Reduktion der Time-to-Market von mehreren Monaten zu wenigen Wochen, eine Steigerung der Prozess-Sicherheit und eine Implementie rung der neuesten Realtime-fähigen Standardsoftware mit neuem Frontend für Bankmitarbeiter und Kunden erreicht werden. Banken stehen damit vor Aufgaben, die die gesamte Organisation for dern, Ressourcen auf Jahre binden und die Steuerung und Steuerungs fähigkeit des Programms im Kern betreffen. Während in gewachsenen Umgebungen die Komplexität graduell zunimmt und nur in Verbindung mit geeigneten Steuerungsinstrumenten aktiv gemanaged werden kann,
Die Transformation als Herausforderung des Managements begreifen
4 An Zielen festhalten © CORE 2013
brechen Transformationen mit dieser sukzessiven Entwicklung und zeich nen sich durch ein Höchstmaß an Komplexität aus. Da in Transformatio nen das Alt-, das Neu- sowie die Umstellung vom Alt- auf das Neusystem zu berücksichtigen sind, das Neusystem jedoch zumindest in Teilen eine Unbekannte ist, liegen Informationen nicht vollständig vor, so dass Pla nungen, Entscheidungen und Maßnahmen durch inhärente Unsicherhei ten gekennzeichnet sind. Für das Management von Transformationen folgt daraus, die struktur immanenten Faktoren der Komplexität und Unsicherheit nicht zu eliminie ren. Es ist vielmehr ein dynamischer und anpassungsfähiger Gestaltungs raum zu definieren und durch Steuerungsmechanismen in Form von klar definierten und erprobten Methoden und Prozessen zu flankieren. Dies ermöglicht Orientierung, Information und Kontrolle. Für eine effektive Im plementierung dieser Mechanismen bedarf es Transformationserfahrung, um die spezifischen Herausforderungen zu adressieren. ›› Orientierung bieten: Projektumfang und Organisationsgröße erfordern die Vermittlung von Orientierung und Konstanz über die gesamte Projekt dauer hinweg, um den Beteiligten den Kontext innerhalb der Phasen der Transformation transparent zu machen.
Herausforderungen identifizieren und differenziert adressieren
›› Entscheidungen treffen: Die hohe Problemkomplexität und die unvoll ständige Informationsgrundlage bedürfen eines faktenbasierten Entscheidungsmanagements, um sachliche Expertise und verständliche Informationen zu gewährleisten. ›› Tools nutzen: Einzelne Bereiche und Faktoren im Projekt tendieren zu Ineffizienzen, solange sie nicht durch differenzierte, den Problemen angemessene Methoden und Tools unterstützt und gesteuert werden. ›› Experten vernetzen: Die für die Transformation notwendigen Experten und Fähigkeiten können nicht vollständig von der Bank vorgehalten werden. Es bedarf daher eines eigenständigen Ansatzes zur Vernetzung bankinterner und -externer Spezialisten. ›› Projekte zum Abschluss führen: Um am Ende des Projekts zielführend agieren zu können, müssen die operativen Prozesse auf ihr Ergebnis hin ausgerichtet werden, bei gleichzeitiger Sicherstellung einer alle Stake holder berücksichtigenden Entscheidungsfähigkeit. Das Management von Fachseite und IT kann diese Herausforderungen mit Hilfe von spezifischen Lösungsmustern angehen, um die Konvergenz der geplanten und der erreichten Ziele zu gewährleisten. In der Definition und Steuerung dieses Gestaltungsraums besteht die Kunst, an Zielen festzu halten und die Transformation zum Erfolg zu führen.
5 An Zielen festhalten © CORE 2013
3 Erfahrungen und Lösungsmuster in Kernbanktransformationen 3.1
Phasen, oder: Das Koordinatensystem
Für komplexe Programme ist es notwendig, einen verbindlichen Rahmen für den gesamten Prozess vom Entwurf eines Zielbildes am Reißbrett bis hin zum Post-Go-live vorzugeben. Dieses Framework fungiert als Koor dinatensystem, das eine strikte Unterscheidung nach Programmphasen mit der Definition von phasenübergreifenden Aufgaben verbindet. In den Phasen stehen spezifische Aufgaben und Ergebnisse im Fokus, die durch adäquate Herangehensweisen und Ansätze sichergestellt werden.
Transparenz sicherstellen und Orientierung vermitteln
3.1.1 Das CORE Transformation Framework Das CORE Transformation Framework konsolidiert vielseitige Erfahrungen und Lösungsmuster in einem übergreifenden Rahmen (Abb. 3). Phasen und Disziplinen der Transformation Modelling
Phases
Preparation
Target Concept
Disciplines Strategy Development
Transformation Setup
Sequence Definition Guideline Determination
Product Specification Architecture Specification Masterplan Development
Model Definition Masterplanning Sourcing Strategy Definition Enterprise Architecture Adoption Business Case Ramp-up and Mobilisation Audits, Assessments and Reviews
Execution Implementation Go-live Decomissioning
Benefit Collection Compliance Management
Target Model Engineering Requirements Engineering Sourcing Management Quality Management Risk Management Architecture Management Project Management Change Management
Trans formation Engineering
Task Force Management Operational Controlling Test Management Rollout Management
Operational Management Transformation Tool Services
Quelle: COREtransform
Abbildung 3: Das CORE Transformation Framework
Das Framework kombiniert die Phasen Modelling, Preparation und Execu tion auf der Zeitachse mit einer Disziplinenachse, auf der die relevanten Scopes den jeweils notwendigen Management- und Controlling-Fokus bestimmen. Beide Achsen zusammen konstituieren eine Fokus: Dedizierte Vorbereitung – Matrix, die die Steuerbarkeit erfolgreiche Umsetzung komplexer Projekte in den Phasen durch funktionale Um Rückkopplungen aus der Umset Scope-Definitionen sicher zung in die Planung zu vermeiden, stellt. Das Framework integ sind die Phasen der detaillierten riert speziell für Transforma Aufplanung des Projekts einer- und der tionen konzipierte Methoden Umsetzung andererseits strikt vonein und Werkzeuge, die standar ander zu trennen. Stattdessen sollten disiert und aufeinander abge Task Forces eingesetzt werden, die stimmt sind, um strukturierte sich in der Umsetzung um Nachhol Verfahrensweisen durchzu bedarfe kümmern und damit zu einer setzen und die Holistik des Entlastung des Projektmanagements Projekts zu gewährleisten. beitragen. Dadurch gelingt es, neuralgi
Standardisiertes Vorgehen für Fokussierung nutzen
6 An Zielen festhalten © CORE 2013
sche Punkte gezielt zu steuern und sich auf die Übertragung von Ergeb nissen zwischen den Phasen zu konzentrieren, um die Transparenz zu erhöhen, Risiken zu adressieren, die Effizienz zu steigern und damit insge samt die Konvergenz zwischen geplanten Zielen und tatsächlichen Ergeb nissen zu sichern. 3.1.2 Zielbestimmung durch Machbarkeitsstudie und Business Case Im Rahmen von Machbarkeitsstudie und Business Case-Rechnung werden die notwendigen Abstimmungen zwischen den internen und externen Betei ligten durchgeführt und die wesentlichen Konturen des Zielbilds und der Sequenzfolge festgelegt. Sie bilden die zentralen Elemente, anhand derer eine Entscheidung zur Transformation getroffen wird.
Strategische Ziele mit den intern und extern Beteiligten abstimmen
Die Machbarkeitsstudie beurteilt anhand einer funktionalen Gap-Analyse, der Bestimmung und Integration der Zielarchitektur sowie eines Infrastruk turkonzepts mitsamt Sizing- und Operating-Modell, inwiefern die Standard software und der Provider die bankseitigen Anforderungen erfüllen. Die Studie muss ihre Ergebnisse in hinreichender Granularität aufbereiten, damit die notwendigen Entscheidungen hinsichtlich weiterer Detaillierungs arbeiten wie Kooperationen für Standarderweiterungen und Validierungen der architekturellen Einzelheiten getroffen werden können. Die Business Case-Rechnung bildet das komplementäre Instrument zur bankinternen Abstimmung zwischen Fach- und IT-Seite. Anhand Kosten senkung und qualitativen Faktoren bestimmt die IT-Seite das zu hebende Synergiepotential durch Dekommissionierung bisheriger Systeme, verbes serte Funktionalität und geringere Wartungsaufwände. Die Fachseite legt die funktionalen Entscheidungskriterien fest und bewertet einzelne Faktoren, z. B. eine Verringerung des operativen Risikos oder eine kürzere Time-to-Market sowie Potentiale zur Ertragsteigerung. Die Business CaseRechnung unterstützt die Entscheidung, womit begonnen werden sollte und in welchen Feldern weitere Planungen nötig sind, etwa weil sie Unter scheidungsmerkmale von Wettbewerbern mit singulären Anforderungen betreffen. Die in den letzten Jahren initiierten Transformationsprojekte von Groß banken sind auf mehrere Jahre ausgelegt und bewegen sich in einem Investitionsbereich bis zu 1 Mrd. EUR. Ihr Ziel ist stets, die Run the Bank (RtB)- und Change the Bank (CtB)-Kosten zu senken und die Erträge zu steigern. Da sich diese Effekte jedoch nur langfristig realisieren lassen, tritt in tatsächlich umgesetzten Transformationen mindestens ein addi tiver Faktor hinzu: in Form einer Mergers & Acquisitions (M&A)-Situation, eines auslaufenden Supports respektive eines Major Upgrades durch den Provider oder einer fundamentalen Veränderung der Geschäftsstrategie. Machbarkeitsstudie und Business Case bilden zwar notwendige, nicht aber hinreichende Bedingungen für eine Transformation. Ein additiver Faktor gibt den Ausschlag für die Entscheidung und übt innerhalb des Transfor mationsprozesses den notwendigen Druck aus, an der Transformation fest zuhalten.
Additive Faktoren der Transformation berücksichtigen
3.1.3 Ausrichtung des Programms auf das Ziel In der Preparation-Phase spielt der Ramp-up des Programms eine zentrale Rolle. In dieser bis zu neun Monate dauernden Planungsphase entscheidet
7 An Zielen festhalten © CORE 2013
sich, ob die wesentlichen Weichen richtig gestellt sind, damit die spätere Umsetzung planmäßig verläuft. Im Ramp-up sind insbesondere das Projekt vorgehen und die Projektinhalte zu definieren. Parallel sind die Roadmap für die Execution-Phase auszuarbeiten, die Zielarchitektur zu bestimmen, die Detailinhalte für den Vertrag mit dem Software-Provider festzulegen und eine auf die Transformationsbedürfnisse angepasste Strategie zur Einbeziehung externer Spezialisten zu definieren (Abb. 4). Inhalte und Zeitplan für Preparation-Phase Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 Month 8 Program setup
Target Model Engineering Initialization methods, processes, tools Setup core team
Business analysis
Operative PMO Pilotation methods, processes, tools
Month 9
Roll out methods, processes, tools
Onboarding project resources, training project team for standard software
Ramp-up project teams for execution phase
ajor decisions concerning M business strategy rioritization proP cesses and products
Roadmap/ Planning
efinition roadmap D on basis feasibility study
Refinement roadmap on basis strategic decisions and process/ product prioritization
Spezification process and product architecture Consolidation plans for subprograms
Finalization corebanking roadmap for start of implementation
Reconciliation corebanking roadmap with overarching masterplan
Architecture design
Conception solution architecture Definition integration architecture
Innovation topics Contracts, Sourcing
Refinement solution architecture Refinement integration architecture
Execution PoC Frontend Phase 1 Execution PoC Frontend Phase 2 Definition PoC Big Data Architecture Execution PoC Big Data Architecture Contract negotiations corebanking software provider Definition work packages and shortlist vendors
Selection vendors and closure contracts
Quelle: COREtransform
Abbildung 4: Themen für die Execution-Readiness
Mit Blick auf das Vorgehen ist die Governancestruktur des Projekts mit allen Gremien auf Senior Management-Ebene abzustimmen, was auch Management- und Eskala tionsprozesse zur Schlie Fokus: Rollierende Planung ßung funktionaler Gaps bein haltet. Daneben sind ein Um einerseits an den definierten Kern detaillierter Realisierungsplan meilensteinen festzuhalten, ande mitsamt Sour cing-Mix vorzu rerseits die Dynamik der Entwick legen und das Vorgehens lungen berücksichtigen zu können, modell hinsichtlich Methoden, ist mit einer rollierenden Planung Pro zessen und Werkzeugen unter Ägide des Project Management gemeinsam mit dem Provider Office (PMO) zu arbeiten. Dafür sind festzulegen. Um in Verbin die Beteiligten in den Projekten früh dung mit diesem Vorgehen zeitig einzubinden, um detailliert zu die Inhalte des Projekts zu planen und die Meilensteine konkret bestimmen, sind vonseiten zu terminieren. Spätere Projekt der IT die Zielarchitektur und phasen sind in adäquater Granula die Roadmap mitsamt Proofrität zu planen und diese Planungen of-Concept (PoC) von inno sukzessive zu verfeinern. vativen Technologien inklusive Pilotierung vorzulegen, während von der Fachseite die banksei tigen Prozesse und Produkte mit der Struktur der Standardsoftware zu synchronisieren sind. Parallel dazu sollten hinsichtlich des Vertrags mit dem Software-Provider die Inhalte so weit festgelegt werden, dass eine Übereinkunft sowohl über ein langfristig tragfähiges Lizenzmodell für die Softwarelösung als auch über die notwendige Unterstützung im Rahmen der Umsetzung des Programms erzielt werden kann.
Konzertierte und umfassende Aufplanung im Ramp-up erarbeiten
8 An Zielen festhalten © CORE 2013
3.1.4 Zielerreichung durch fokussierte Umsetzung Die Phase der Execution erstreckt sich von der Analyse, dem Design und der Realisierung über das Test-Management bis zum Go-live. Während der Imple mentierung liefern alle Beteiligten Ergebnisse in ihre Teilprojekte ein. Darüber hinaus konkretisiert die Fachseite die Realisierungsanforderungen hinsichtlich Produkten, Funktionen und Prozessen. Maßstab für diese Konkretisierung sind die anvisierten Geschäftsprozesse, deren Abbildung auf der neuen Platt form kontinuierlich realisiert und im Resultat sichergestellt werden soll. Der im Ramp-up erarbeitete Meilensteinplan bildet die Basis für die Implementierung (Abb. 5).
Fach- und IT-Seite spezifisch einbinden
Roadmap/Projektplan für Execution-Phase mit kritischem Pfad Critical path Month
Overarching topics
1
2
3
4
Architecture blueprint
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21
Overall concept/architecture
Migration/Transformation readiness
Process/ functional analysis
Functional analysis Replication/ Migration Analysis data cleansing
Data cleansing
Process analysis
Go-live processes
Cleansing terminating products
Frontend design Backend design and realization
Analysis Design & development
0.1
0.2 0.3 0.4 0.5 0.6 Pilot
Integration test
Go-live Rel. 1.0 0.6
0.5 0.4 0.3 0.2 0.1
Acceptance test
User acceptance test
Introduction management
Preparation Change Change assessment calendar
Theme modules
Result presentation
Training Customer communication
Acceptance test Change Governance Final structure Roadmap structure and process model Sales: qualification, communication, etc.
Infrastructure setup
Environment Environment component integration tests tests Environment development
Environment Environment acceptance production tests
Environment training
Quelle: COREtransform
Abbildung 5: Plan für die Execution mit Kernmeilensteinen
Der Meilensteinplan legt die Arbeitsschritte mit konkreten Ergebnistypen und -terminen fest und bestimmt den kritischen Pfad. Gemäß Vorgehens modell werden die Zielprozesse und -produkte unter Beteiligung der Fach seite analysiert, modelliert und realisiert. Analyse und Realisierung sollten parallelisiert werden, um den Abschluss von Teilergebnissen sicherzu
Aktivitäten parallelisieren und konkret koordinieren
9 An Zielen festhalten © CORE 2013
stellen und spätere Verzögerungen zu vermeiden. Um die parallelen Tätig keiten zu koordinieren, den Beteiligten Orientierung zu bieten und syste matisch Kontrollpunkte zu installieren, sind Subreleases mit definiertem Umfang und teilprojektübergreifenden Lieferzeitpunkten zu bilden. 3.2
Entscheidungen, oder: Abzweigungen auf dem Weg
Entscheidungen bilden ein zentrales Steuerungselement in Projekten. Sie bestimmen, ob und inwiefern welche Optionen realisiert werden, sie legen Richtungen fest, schärfen Ziele und stellen – zum Teil Widerstände über windend – Einigkeit her. Aufgrund der hohen Komplexität und der inhä renten Unsicherheit in Transformationen sind die Verantwortlichen damit konfrontiert, Entscheidungen auf Basis nicht vollständiger, zum Teil unzu reichender Informationen treffen zu müssen. Die Herausforderung besteht darin, diesen Faktor nicht durch Intuition zu kompensieren, sondern Mittel für möglichst sachbezogene und informierte Entscheidungen zu finden und im Rahmen eines Entscheidungsmanagements zu konsolidieren. In den von uns begleiteten Transformationen wurde dieses Management auf unterschiedliche Weise erfolgreich realisiert: durch Ad-hoc-Entschei dungen, durch die strikt zeitliche Taktung von Meetings sowie durch einen gleichermaßen bedarfs- und steuerungsorientierten Ansatz, der für erfolgskritische Entscheidungen in Transformationen zumeist herange zogen wird. In den folgenden Überlegungen berücksichtigen wir sowohl Entscheidungen des Managements der Bank als auch die zwischen dem Senior Management der Bank und dem des Standardsoftware-Providers. Wir konzentrieren uns zunächst auf die Verteilung der Entscheidungen und Steering Committee-Sitzungen und gehen auf ihre inhaltliche Dimension ein, um abschließend die Resultate dieser Analysen zu resümieren.
Entscheidungen möglichst faktenbasiert treffen
Organisation zum Management der Entscheidungen definieren
3.2.1 Entscheidungen als Kernaufgabe des Managements Die Häufigkeit der Entscheidungen und Sitzungen auf Ebene der Programm leitung ist über die einzelnen Projektphasen unterschiedlich verteilt. Sie nimmt mit späteren Phasen deutlich zu. So werden unter 10 % der Entscheidungen in der Modelling-, unter 25 % in der Preparation- und damit fast zwei Drittel der Entscheidungen in der Execution-Phase getroffen. Die Zahl der Entscheidungen in der Execution- gegenüber der Modelling-Phase steigt damit bis um das Sechsfache. In der gleichen Zeit vervierfacht sich etwa die Zahl der Sitzungen. Während Meetings zu Beginn des Projekts quartalsweise anberaumt sind, finden sie in der Spätphase vor dem Go-live zweiwöchentlich statt. Dem entspricht, dass anfänglich wenige Grundsatz entscheidungen getroffen werden, während es in der späteren Umsetzung um die zeitnahe Klärung von stärker einzelorientierten Punkten geht. Die höhere Frequenz der Sitzungen stellt bei steigender Entscheidungs zahl sicher, dass die Anzahl der pro Sitzung zu treffenden Entschei dungen relativ konstant bleibt. Auf diese Weise kann ein „Durchwinken“ von Entscheidungen aufgrund ihrer Menge verhindert und ein sachlicher Fokus organisatorisch sichergestellt werden. Zudem unterstützt die höhere Sitzungsfrequenz in späteren Phasen eine möglichst zeitnahe Entschei dung und stärkt so die Informationsbasis, da Fragen thematisiert werden, solange die Beteiligten aktiv in das Projektgeschehen involviert sind.
Konstanz und Sachbezug durch Erhöhung der Sitzungsfrequenz sicherstellen
10 An Zielen festhalten © CORE 2013
Über diese rein an den Projektphasen orientierten Erkenntnisse hinaus zeigt eine vertiefende Analyse, inwiefern sich innerhalb der einzelnen Phasen ein charakteristisches Muster der Entscheidungs- und Sitzungsverteilung ergibt (Abb. 6). So kommt es besonders zur Mitte der Modelling-Phase zu einer hohen Anzahl von Entscheidungen, während in der Preparation die Entscheidungen am Ende getroffen werden und sie sich in der Execution im ersten Drittel häufen, um sich danach auf relativ hohem Niveau einzu pendeln. Diese Ergebnisse werden durch eine differenziertere Betrachtung nach Entscheidungen der Bank mit dem Provider einer- und bankinternen Entscheidungen andererseits bestätigt. Anzahl der Entscheidungen und Steering Committees über die Projektphasen Number Steering Committees 1
2
1
1
1
1
4
3
4
3
5
21
21
Number Decisions 2
3
6
39 35
16 14
12
2
9 2
2
Modelling Q1
14
Q2 Q3 Year 1
Q4
5
2
Preparation
Execution
Q1
Q4
Q2 Q3 Year 2
Q1
Q2 Q3 Year 3
Q4
Q1 Q2 Year 4
Quelle: COREtransform
Abbildung 6: Verteilung Entscheidungen und Sitzungen
Die Feststellung, dass es nicht zu einer sukzessiven Steigerung, sondern zu einer charakteristischen Verteilung der Entscheidungen und Sitzungen kommt, ist zentral. Darin spiegelt sich wider, dass Entscheidungen zu ganz bestimmten Zeiten für das Projekt getroffen werden müssen, um es voran zutreiben. Käme es zu einem linearen oder gar exponentiellen Anstieg der Entscheidungen, wäre eher zu vermuten, dass die Entscheider vom Fort schritt des Projekts überrannt würden, statt dass sie das Projekt mit ihren Entscheidungen steuern und kontrollieren.
Die Verteilung der Entscheidungen berücksichtigen
Um die Entscheidungen mit Blick auf ihre inhaltliche Dimension zu analy sieren, bieten sich zwei Unterscheidungsraster an. ›› Eine erste Unterscheidung orientiert sich an den projektbezogenen Kriterien Scope, Budget und Time. ›› Eine zweite Unterscheidung zielt darauf ab, Entscheidungen hinsichtlich des Vorgehens im Projekt von solchen über Inhalte zu differenzieren. In der Analyse der projektbezogenen Kriterien (Abb. 7) zeigt sich eine klare Dominanz der Scope-Entscheidungen. Auffällig ist, dass es zum Ende der Preparation zu einer Akkumulation aller drei Dimensionen Scope, Budget und Time kommt, die bis auf die Zeit-Dimension fast gleichwertig sind. In der Execution überwiegen eindeutig die Entscheidungen zum Scope, während Budget und Time nur im ersten Drittel und dann ein letztes Mal etwa zur Hälfte der Execution-Phase thematisiert werden.
Scope, Budget und Time am Ende der Preparation entscheiden
11 An Zielen festhalten © CORE 2013
Anzahl der Entscheidungen zu Scope, Budget, Time Scope
Time
Budget
28
21 16
16 14
14 12
12 9
9
9 12
2
2
2
2
2
Modelling Q1
Q2 Q3 Year 1
Q4
2
2
2
Preparation
Execution
Q1
Q4
Q2 Q3 Year 2
5 5
2
Q1
Q2 Q3 Year 3
Q4
Q1 Q2 Year 4
Quelle: COREtransform
Abbildung 7: Entscheidungen nach Scope, Budget, Time
Ein ähnliches Muster zeigt die Unterscheidung nach Projektvorgehen und Projektinhalten (Abb. 8). Die Entscheidungen im Modelling gehen auf die Inhalte des Projekts, erst am Ende wird das Vorgehen festgelegt. Entschei dungen zum Vorgehen bleiben während der ersten Phase der Preparation im Fokus, während es am Ende dieser Phase wieder zu einer Häufung von Entscheidungen kommt, die beide Dimensionen betreffen. Entscheidungen zum Projektvorgehen spielen nur noch zu Beginn der Execution sowie gegen Ende eine Rolle, werden jedoch von inhaltlichen Entscheidungen dominiert.
Vorgehen und Inhalte gemeinsam entscheiden
Anzahl der Entscheidungen zu Projektinhalt und -vorgehen Project content
Project approach
35
25 21 14
12
2
2
Modelling Q1
14
14
9 5
2
21
Q2 Q3 Year 1
Q4
7
5 2
2
Preparation
Execution
Q1
Q4
Q2 Q3 Year 2
Q1
Q2 Q3 Year 3
Q4
2
Q1 Q2 Year 4
Quelle: COREtransform
Abbildung 8: Entscheidungen zum Inhalt und zum Vorgehen
3.2.2 Umfassendes und konsequentes Entscheiden in kritischen Phasen Diese Typologie der Entscheidungen, wie sie sich sowohl hinsichtlich der Verteilung der Entscheidungen und Meetings als auch mit Blick auf die inhaltlichen Differenzierungen darstellt, lenkt den Blick auf den Übergang zwischen Preparation- und Execution-Phase. Am Ende der Preparation und zu Beginn der Execution kommt es zu einer Häufung der Entscheidungen. Bemerkenswert ist nicht allein der sprunghafte Anstieg der Entscheidungen, sondern dass die Entscheidungen in dieser Zeit alle Faktoren und Dimensi onen des Projekts im Verbund festlegen. Sie betreffen Scope, Budget und Time gleichermaßen; und sie richten sich genauso auf Fragen der Inhalte wie auf solche des Vorgehens. 12 An Zielen festhalten © CORE 2013
Mit Blick auf die Differenzierung nach Vorgehen und Inhalten ist entschei dend, dass die zentralen Linien für die Umsetzung des Projekts nur in Verbindung beider Dimen sionen gezogen werden Fokus: Entscheidungen können. Kernentscheidungen subsidiär treffen zum Inhalt und zum Vorgehen des Projekts sind voneinander Um den vielfältigen Anforderungen an abhängig, die Festlegung des Entscheidungen gerecht zu werden, Gestaltungsraums am Ende sind neben Steering Committees der Preparation und zu Beginn eigenständige, subsidiäre Entschei der Execution betrifft beide dungsgremien zu etablieren. Sie Dimensionen gleichermaßen. fungieren zum einen als Ansprech partner für die (Teil-)Projekte und Im Kontext der Differenzierung konsolidieren deren Bedarfe zu Infor nach Scope, Budget und Time mationen und Entscheidungsvorlagen; zeigt sich darüber hinaus, sie sind zum anderen Ansprech dass Budget und Time in der partner für die Steering Committees späteren Execution eine nur und vermitteln deren Entscheidungen untergeordnete Rolle spielen, an die Beteiligten in den Projekten. allerdings zur Mitte der Execu Mit Hilfe der Entscheidungsgremien tion noch einmal relevant gelingt es, Entscheidungen zugleich werden. Aufgrund spezifi faktenbasiert und zielgerichtet treffen scher Scope-Verschiebungen sowie interpretationsfest und wirksam werden in dieser Phase typi umsetzen zu können. scherweise Überlegungen virulent, das Budget oder die zeitliche Planung zu modifizieren, um die aktuelle Situation zu berücksichtigen. Dem ist durch eine strikte Konzentra tion auf den Scope zu begegnen. Entwickeln sich in der Execution-Phase Budget und Time zu dominanten Faktoren, weist das auf eine kritische Entwicklung des Projekts hin. 3.3
Budget und Time festhalten, Scope schärfen
Methoden und Tools, oder: Landkarten und Schilder
Methoden und Tools sind wesentliche Mittel zur Unterstützung des Projekts und des Projektmanagements, mit deren Hilfe relevante Informationen – teilweise automatisiert – gesammelt und aufbereitet werden. Sie dienen der Steuerung des Projekts und leisten über das kontinuierliche Vorhalten von Informationen einen essentiellen Beitrag zur Steuerungsfähigkeit. Sie kommen in unterschiedlichen Kontexten des Projekts zum Einsatz und unterstützen teils in spezifischen Projektphasen, teils werden sie über die gesamte Dauer des Projekts eingesetzt. Ihr Nutzen lässt sich üblicherweise mindestens einer von drei Kategorien zuordnen.
Methoden und Tools kontext abhängig und differenziert nutzen
›› Durch den Zugang zu Methoden und Ressourcen werden Prozesse und Vorgehensweisen innerhalb des Projekts strukturiert, standardisiert und koordiniert sowie außerhalb des Projekts gelegene Bedarfe ermittelt und einer Entscheidung zugeführt. ›› Tools sammeln Informationen aus Teilprojekten und bereiten sie konsoli diert auf, wodurch sie die operative Arbeit der Teilprojekte direkt unterstützen und eine Selbstkontrolle und -evaluation für die Projekte ermöglichen. ›› Tools werden eingesetzt, um Daten aus Teilprojekten zu erhalten, die diese nicht oder nur begrenzt von sich aus erheben würden, weil sie orthogonal zur operativen Arbeit liegen. Diese Informationen sind für die Koordinierung der Teilprojekte, Entscheidungen des Managements 13 An Zielen festhalten © CORE 2013
und eine Kontrolle des Projektverlaufs notwendig. Der Einsatz von Tools unterstützt die kontinuierliche Einlieferung der relevanten Daten von den Teilprojekten. 3.3.1 Vorgehensmodell Aufgabe der (Teil-)Projekte ist, die Standardsoftware einzuführen und die notwendigen Anpassungen und Erweiterungen vorzunehmen, insbeson dere Schnittstellen und fehlende Funktionen. Um die Qualität der Ergeb nisse sicherzustellen, werden diese im Rahmen eines standardisierten Prozesses erarbeitet. Das Vorgehensmodell dient dazu, diesen Prozess von der ersten Grobkonzeption der Ergebnistypen über die fachseitige Detaillierung und das Design bis hin zur Einführung und dem Projektab schluss zu beschreiben und für alle Projektbeteiligten verbindlich festzu legen. Da es kein singuläres und allgemein gültiges Vorgehensmodell für Trans formationen gibt, versuchen die am Projekt Beteiligten, ihre eigenen, jeweils praxiserprobten und bewährten Vorgehensmodelle durchzusetzen: die Bank, der Software-Provider und weitere externe Berater, die Fachund die IT-Seite, die Entwicklung gegenüber den Testverantwortlichen. Die Diskussion konkurrierender Vorgehensmodelle ist nicht zielführend und kann sich zu wahren „Methodenkriegen“ auswachsen.
Diskussionen um Methoden ergebnisorientiert steuern
Vorgehensmodell mit Detaillierung der Requirements-Analyse
High-level requirements analysis & design Project initiation
Requirements analysis
Functional solution design
Design & Development
Technical solution design
Process Analysis
Best practice identification
Solution build incl. unit test
SIT incl. E2E test
Go-live/ Deployment
Project closure
Final test
UAT
Functional Analysis
Analysis conducted for all business processes that are affected by project scope
Business processes selection
Test
Activities and tasks definition
Business requirements documenta tion
Analysis conducted according module structure of standard software Business Partner
Account Management
Pay ments Services
Loans Management
Cards Management
Analytics
Quelle: COREtransform
Abbildung 9: Vorgehensmodell mit Fokus Requirements-Analyse
Fokus: Ein Vorgehensmodell für alle Um Diskussionen zum „richtigen“ Vorgehen nachhaltig zu steuern, ist das Vorgehensmodell hinreichend detail liert und verständlich dokumentiert von der Bank festzulegen. Dazu sind in der Preparation-Phase intensive Diskus sionen, in denen auch die Möglichkeit einer Synthese aus konkurrierenden Modellen erwogen werden kann, strin gent abzuschließen.
Um konfliktären Diskussionen um Methoden entgegenzu steuern, ist eine frühzeitige und umfassende Klärung nötig. So ist für das Projekt management festzulegen, welche Tools für welche Steu erungsaufgaben zum Einsatz kommen, welche Informa tionen die (Teil-)Projekte über diese Tools einsteuern und welche Informationen die Tools in welcher Weise aufbe reiten (siehe Kapitel 3.3.2). Für die Prozessmodellierung
Vorgehensmodell vor der Execution verbindlich festlegen
14 An Zielen festhalten © CORE 2013
und die funktionale Analyse ist zu beschreiben, mit Hilfe welcher Analysen welche Sichten abgebildet werden, etwa die Perspektive der Geschäfts prozesse durch eine Prozess-, die Perspektive der Lösungskomponenten durch eine funktionale Analyse (Abb. 9). Mit Blick auf die Realisierung ist das Vorgehen für die Anpassungen der Standardsoftware und für die Implementierung von Eigenentwicklungen (z.B. für Schnittstellenanpas sung) festzulegen. Hier muss zudem geklärt werden, welche Ergebnis typen wann zu liefern sind. Für das Testen und das Test-Management ist zu bestimmen, welche Teststufen in welcher Reihenfolge von den (Teil-) Projekten für die einzelnen Releases durchlaufen werden müssen. Auf einem weiteren Detaillierungsniveau ist zu beschreiben, inwiefern die (Teil-) Projekte im Anschluss an die Implementierung funktionaler Bereiche ihre Arbeitspakete einem Systemintegrationstest (SIT) respektive einem User Acceptance Tests (UAT) unterziehen müssen (siehe Kapitel 3.3.4). 3.3.2 Projektplan und Abhängigkeiten Der Projektplan dient dazu, die Steuerung des Projekts zu unterstützen, den Projektbeteiligten schnell und zielführend Informationen zur Verfügung zu stellen und die Abhängigkeiten innerhalb des Projekts transparent zu machen. Dazu werden einzelne Steuerungsaufgaben zusammengefasst und durch entsprechende Planungs- bzw. Steuerungswerkzeuge unter stützt. Die Projekte und Teilprojekte werden darauf verpflichtet, Daten in den Tools zu hinterlegen, aus denen heraus automatisiert Reports generiert werden können, um über Fortschritte, Risiken, Probleme und Abhängig keiten zu informieren (Abb. 10).
Tools differenziert nach Aufgaben festlegen
Projekt-Reporting orientiert am CORE Transformation Framework Modelling
Phases
Preparation
Target Concept
Implementation Go-live
Product Specification
Decomissioning
Architecture Specification
Guideline Determination
Disciplines
Strategy Development
Execution
Transformation Setup
Sequence Definition
Masterplan Development Model Definition
Masterplanning
Benefit Collection
Sourcing Strategy Definition
Enterprise Architecture Adoption
Compliance Management
Business Case
Ramp-up and Mobilisation
Audits, Assessments and Reviews Target Model Engineering Requirements Engineering
Tool-based reporting (selected views) Sourcing Management
Transformation Engineering
Quality Management Risk Management Architecture Management Project Management Change Management Task Force Management Operational Controlling
Operational Management
Test Management Rollout Management Transformation Tool Services
Quelle: COREtransform
Abbildung 10: Reporting mit Hilfe des Programm-Management-Werkzeugs
Ein zentrales, serverbasiertes Tool sollte für Programmplanung, -monito ring und -reporting bereitgestellt werden. Auf dieses Tool werden bestimmte Projekte und Teilprojekte verpflichtet, die ihre Planung von der Baseline
Projektplan und Abhängigkeiten in einem zentralen Tool realisieren 15
An Zielen festhalten © CORE 2013
bis zu den jeweiligen Aktualisierungen in einer definierten Granularität im Tool hinterlegen und durchführen. Für die Granularität maßgebend sind die Meilensteine, die für das Reporting als notwendig erachtet werden und die die Abhängigkeiten zu anderen (Teil-)Projekten beinhalten. Die zwischen den (Teil-)Projekten abgestimmten Abhängigkeitsvereinbarungen werden in den Lieferstücken hinterlegt. Indem die Verknüpfung der verschiedenen Level über die Meilensteine hergestellt wird, bietet der Projektplan verschie dene Planungslevel, die von der Gesamtprogramm- über die Programm roadmap bis zu den Projekt- und Teilprojektplänen reichen und für die aus dem Tool heraus Reports erstellt werden können, die als Basis für das Management-Reporting dienen. Für das Financial- und das Ressourcen-Controlling bieten sich einfachere Lösungen an, auch für das Information-, insbesondere das DocumentManagement, sowie das Change Request- und das Defect-Management können unterschiedliche Tools eingesetzt werden. Die Aufgaben und Anfor derungen können in diesen Bereichen spezifisch definiert werden, um Informationen durch unterschiedliche Tools zielgerecht bereitzustellen. 3.3.3 Reporting Das Reporting ist eines der zentralen Kommunikationsmittel in der Execu tion-Phase. Mittels standardisierter Reports werden Fakten aufbereitet und abgebildet. Ziel der Reports ist, über Status, Fortschritt und Steuerungs bedarfe der (Teil-)Projekte zu informieren und dadurch Transparenz für die (Teil-)Projekte und die Leitungsebenen zu schaffen. Eine möglichst granu lare Darstellung unterstützt die Analyse von eventuellen Fehler- und Fehl entwicklungsursachen.
Reporting phasen- und zielgruppengerecht nutzen
Verschiebung der Lieferungen in spätere Phasen (abzuschließende Arbeitspakete pro KW) 140 120 100 80 60 40 20 0
Plan as of cw 1
Is
Plan as of cw 8
Current cw -34
1
+2
-11
2
3
4
-24
5
-2
6
7
8
9
10
11
12
13
14
Bugwelle der kumulierten Verzögerungen und Top-3-Projekte mit nicht abgeschlossenen Arbeitspaketen New delays
100 80
59
60 40 20 0 -20
Cumulated delays 83
16 0 16
14
1
2
16 -2
25 11 14 3
34
24 59
85 2
85 0
83
85
6
7
Top 3
24 17
Integration
25 4
85
Total Savings/Current Account Development
14
Migration 5
Rest
30
Quelle: COREtransform
Abbildung 11: Arbeitspaket-Statistik als Frühwarnsystem
Die Arbeitspaket-Statistik verschafft einen Überblick über das Verhältnis zwischen den geplanten und den tatsächlich eingelieferten Arbeitspaketen (Abb. 11). Damit lässt sich ein Frühwarnsystem installieren, das auf Fehlent wicklungen und Scope-Verschiebungen aufmerksam macht, die anderenfalls unterhalb der Wahrnehmungsschwelle blieben. Der Gegenüberstellung von ursprünglich geplanten und aktualisiert geplanten Einlieferungen ist zu entnehmen, inwiefern sich aus der Verschiebung von Lieferterminen eine Bugwelle bildet. Die Arbeitspaket-Statistik indiziert diese Verschiebungen
Frühwarnsystem für Steuerungs bedarfe installieren
16 An Zielen festhalten © CORE 2013
anschaulich, so dass ihnen entgegengesteuert werden kann. Weitere Reporttypen wie die Earned Value-Analyse und die Testfallausführung weisen ebenfalls auf Abweichungen zwischen Planung und Erreichtem hin. Integration Readiness-Report Applications Cluster Channels
Banking
Lending Investments
Interfaces
Application 1 Branch Frontend
71
2 Online Banking
56
3 Call Center
42
4 Self-services
96
5 Operations Frontend
70
6 Foreign currency Frontend
47
7 Cashier Backend 8 Banking Terminal Backend
54
9 ATM 10 Statement printing
63
11 Domestic payments
76 90 69
14 Business partner 15 Cards management
63
16 Collaterals
35
17 Claims management 18 Ordering system
75
19 Depot management 20 Pricing
tbd
37
91
100%
53%
86% 17%
21 Workflow management
tbd
22 Document archive
78
Enterprise systems
23 Authorization system 24 Data Warehouse
tbd
25 Tax 27 Group consolidation 28 Risk management
n/a 73
75–90%
50–74%
90%
75–90%
Quelle: COREtransform
Abbildung 12: Integration/Schnittstellen im Fokus
Andere Reports konzentrieren sich auf den qualitativen Status innerhalb der (Teil-)Projekte. Status- und Integrations-/Schnittstellen-Reports informieren anhand von Kennzahlen über den Fortschritt; ein Ampelsystem zeigt an, in welchen Bereichen Handlungsbedarfe bestehen (Abb. 12). Auch der aus dem Program Management Tool heraus erzeugte Abhängigkeiten-Report sowie der Early Life-Report (Abb. 13), der nach dem Go-live Informa tionen nach Fach- und IT-Seite aufbereitet, basieren auf diesem Schema. Entscheidungs- und Freigabekaskaden (spätere Abb. 18) kulminieren in der binären Zuspitzung von Entscheidungen.
Status und Fortschritt scopespezifisch abfragen
Early Life-Report G On track IT
System availability
G
Standard software solution
G
Frontend
G
ETL
G
Core data
Incidents
Emergency activities
Quantity framework
R Critical
Sales Number customer complaints
G
5
G
Waiting time
15 sec
G
Availability
96 %
G
0
G
Accounts
1.900
G
Savings
1.400
G
Call money
2.500
Availability hotline / Ø Call duration
G
91% / 2:05 min
System relevant calls
G
~350 (FC: 400)
G
Post-process.ing core data
30
G
Post-process.ing contracts
104
G
Open records dispo
G
Open records CpD
Number of calls
G
Maximum response times 1,52 sec within 95% percentile
Complaints to board
G
Amount of frontend calls within scope of SLAs
Number of new contracts
Frontend response times
End of day processing
A Under surveillance
Business
98,7%
A
Amount of achieved SLAs (out of 10)
9
G
Stage 1
0
G
Stage 2
0
G
Reports ticket system
1
G
G
Emergency changes Amount users in dedicated environment
Services
0 Special cases processing ~10.000
278 1.215
Quelle: COREtransform
Abbildung 13: Messung der Nachhaltigkeit des Erfolgs
17 An Zielen festhalten © CORE 2013
Test-/Defect-Reports (spätere Abb. 15) bilden Daten zeitlich, nach Kategorien und nach Schwere geordnet für einzelne und zusammenhängende Um den sich ändernden Anforderungen Anwendungen ab. Grund an Informationen und Transparenz über für diese vielfältige Aufberei die Projektdauer gerecht zu werden, tung ist, dass der Fokus in sind von den Projekten etappendieser Phase vollständig auf spezifische Reports zu erstellen. Dies Defects und ihrer Beseitigung stellt sicher, dass die Reports nicht liegt. Weitere Reports stellen zur bloßen Routine verkommen, vom Größen ins Verhältnis zuein Sender wie vom Empfänger ernstge ander. So beschreibt der Risk-/ nommen werden und die aktuell im Issue-Report die Relevanz Fokus stehenden Herausforderungen eines Risikos als Kombination betreffen. von Gefahrenpotential und Eintrittswahrscheinlichkeit und setzt das Risiko ins Verhältnis zur zeitlichen Dringlichkeit. Fokus: Kontext- und phasenabhängiges Reporting
3.3.4 Testen und Test-Management Das Testen dient der kontinuierlichen Prüfung der Qualität erreichter Ergeb nisse einzelner Umsetzungsschritte. Die Komplexität des Projekts, die sukzessive Entwicklung der Funktionalitäten und das Vorgehen in (Sub-) Releaseschritten erfordern ein systematisches Test-Management, um die in Transformationen typischen Tausende Testfälle über fast die gesamte Dauer der Execution koordinieren und steuern zu können. Das Test-Management bildet eine der zentralen Methoden in der Execu tion, das als Steuerungs- und Kontrollmittel die Integration und Synthese der einzelnen Komponenten zum Gesamtsystem sicherstellt. Es legt zum einen fest, was getestet wird. In diesem Rahmen werden die spezifischen Tests bestimmt, Inhalte, Umfang und Zeitschiene des Testens geplant und zugleich Testfälle definiert. Dabei sollten die IT-Seite und der Softwarelie ferant einbezogen werden, um das Testen von bereits durch den Provider qualitätsgesicherter Standardfunktionalität zu vermeiden. Komponententests schließen unmittelbar an die Entwicklung der jeweiligen Komponente an (Abb. 14). Sie finden von allen Testaktivitäten zuerst statt und starten früh in der Umsetzungsphase. Die weiteren Teststufen beginnen zeitlich versetzt. Komponententests machen typischerweise etwa die Hälfte aller Testfälle aus. Mit Abstand folgen Migrations- und Replikationstests (20 %), Systemintegra tions- und Frontend-Tests mit je 10 % sowie nicht-funktionale (5 %), End-toEnd (3 %) und schließlich Abnahmetests mit 2 %. 90 % der Testfälle dienen somit allein der Prüfung der Funktionen und der Datenmigration.
Qualität durch systematisches Testen sicherstellen
18 An Zielen festhalten © CORE 2013
Testaktivitäten nach Anteilen und Zeit Test activity/test level
Share of test cases
Timetable
Test cases total
Go-live
Component tests
17 months
50% 10%
System integration tests
10 months
20%
Migration/replication tests
11 months
5%
Non-functional tests
10 months
10%
Frontend tests
8 months
3%
End-to-end tests
8 months
2%
User acceptance tests
6 months
Quelle: COREtransform
Abbildung 14: Überblick über Testaktivitäten
Das Test-Management legt zum anderen in Form von Testumgebungen, Koordinierungen, Reporting- und Defect-Management-Anforderungen fest, wie getestet und wie mit den Ergebnissen der Tests verfahren wird. Hierbei spielt das Test-/DefectReporting (Abb. 15) eine Fokus: Frühzeitiges und besondere Rolle, da die Anzahl strukturiertes Testen der Testfälle je Teststufe mit zunehmender Release Um in der Umsetzung die kontinuier zahl deutlich zunimmt, von liche Messung der Qualität zu gewähr wenigen Hundert zu Beginn leisten, ist mit dem Testen zeitnah bis zu mehreren Tausend nach der Entwicklung zu beginnen. Testfällen im letzten Drittel. Ur sache hierfür ist die Zunahme der mit jedem Release implementierten und zu testenden Funktionalität. Zudem müssen weitere Regressions tests durchgeführt werden, weil im vorherigen Release festgestellte Defects im aktuellen Release daraufhin geprüft werden müssen, ob sie tatsächlich behoben worden sind und ob durch die Fehlerbehebung eventuell ander weitige Fehler entstanden sind. Anzahl Fehler mit Severity Critical und High
Fehlerhistorie (nach KWs) Critical
478 2 2
144
19 6 13
48
High
49 20 3 2
434
100
168
-100
22
482
200
0
72
1
96
-102
234
498
593
Closed in cw 618
463
Opened in cw 700
467 512
478
600
241 178 157 173 142 199 197 178 142
500
539
433
400
-154 -162 -112 -138 -183
-139
-135 -182
-225
300
-351
-200 50
Total
Open cumulated 300
29
Detailliertes Test-Reporting konzipieren
200
-300
Critical/ Test data/ Current Postponed New, Not defect accepted Retests High Open, Accepted
Anzahl Fehler pro Anwendung
-400
100
1
4
3
2
5
6
7
8
0
11
10
9
Drilldown: Fehler Anwendung A1 auf Komponenten
22
Critical
High
6
Critical
5
High
8 3
9 14
3
7 2
6
6
6 2 3
6 0 6
5 1 4
4 1 3
3 1 2
2 1 2
2 1 2 1 2
2 1 1 1 2 1 1 1 2
1 1
2
1 1
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17
Quelle: COREtransform
K1
2 K2
2
5
K3
2 1
1
1
1
1
1
K4
K5
K6
2
K7
1
1
1
1
K8
K9
2
No allocation
Abbildung 15: Test-/Defect-Reporting
19 An Zielen festhalten © CORE 2013
3.4
Netzwerk, oder: Menschen und Fähigkeiten
Für eine Transformation bedarf es einer das Gesamtprojekt in Phasen glie dernden Systematik, eines differenzierten Entscheidungsmanagements sowie spezifischer und in sich flexibler Methoden und Tools. Dennoch wird eine Transformation nicht ohne die Mitarbeiter und Partner gelingen, die sich mit ihrem Wissen in das Projekt einbringen, es mit ihren Fähigkeiten gestalten und mit ihrer Erfahrung zum Erfolg führen. Die Bank kann die für die Transformation notwendige vielfältige und spezifische Expertise und die entspre Um die in der Execution-Phase aufchenden Fertigkeiten nicht tretenden Skill-Bedarfe optimal abzu durch eigene Ressourcen decken, sind anhand von typischen allein bereitstellen. Die Sour Gesamtlastkurven spezifische Skillcing-Strategie dient dazu, Felder Phasen-orientiert zu identifi die aus der Transformation zieren. Damit wird eine Skill Sour resultierenden bankseitigen cing-Matrix (Abb. 16) konstituiert, Bedarfe extern unterstüt die differenziert Auskunft über Skillzender Ressourcen und Bedarfe und ihre Integration gibt. Kräfte festzustellen und einen Ansatz zu entwickeln, diese Kräfte adäquat in die Strukturen und Prozesse der Transformation zu integrieren. Fokus: Phasen-orientiertes Sourcing
Skill-Bedarfe identifizieren und strategisch einplanen
Verteilung der Skill-Bedarfe in der Execution-Phase Load curve skill type
Management discipline
Type of skill scope
Project management
1 Experience in major projects to manage scope, budget, time
Functional management
2 Business consulting
Plan
Build
Integration
Test
Typical overall load curve
Roll-out
Run
1 3 Requirement management/engineering 4 Quality and test management Technical management
3
4
5 Architecture management 6 Solution know-how standard software 7 Expertise system integration
Organizational management
2
8 Support communication and decision management 9 Expertise IT transformation with focus on methods and process
6
5 7
8 9
Quelle: COREtransform
Abbildung 16: Skill Sourcing-Matrix
Die Skill Sourcing-Matrix bildet die Grundlage, um die Integration der unter stützenden Berater zu organisieren und die entsprechenden Auswahlpro zesse transparent und nachvollziehbar für alle Beteiligten zu kommuni zieren. Die hierfür notwendige Detailtiefe der Planung ist im Rahmen der Preparation-Phase herzustellen und das Onboarding der notwendigen Spezialisten zielgerichtet in der Preparation beginnend zu steuern.
20 An Zielen festhalten © CORE 2013
3.5
Go-live, oder: Das Ziel
Alle Methoden, Prozesse, Tools sowie Fähigkeiten dienen dem Ziel, das Neusystem ein- und das Altsystem abzuschalten. Um dieses Ziel zu errei chen, reicht die Fortführung der vorab geplanten Umsetzung nicht, weil die entsprechenden Prozesse aktiv gesteuert werden müssen. Es bedarf eines komplementären Managements, das von der Perspektive des Go-lives aus gedacht wird. Dieses Go-live-Management koordiniert die einzelnen Projekte und Teilprojekte von ihrem Ende her und führt sie steuernd zum Abschluss.
Dediziertes Go-live-Management als Bedingung für den erfolgreichen Abschluss verstehen
Die strategische Planung des Rollouts beginnt etwa sechs Monate vor dem Go-live. Das Management richtet den operativen Fokus auf die Beseitigung der Defects und legt die sachlichen Anforderungen hinsichtlich der Go-liveReadiness fest. In diesem Rahmen formuliert es zum einen spezifische Abnahmekriterien, die sukzessive gemessen und abgearbeitet werden, und stellt zum anderen die Entscheidungsfähigkeit für den Go-live her. Schließlich wird durch das Go-live-Management der Post-Go-live geplant. Go-live-Kriterien Risk for Go-live
High
Medium
Low
To clarify
Ready for Go-live
Software scope ready
Software quality ready
Integration ready
Infrastructure ready
Drill-down criterion for software quality SIT completed
Data/ migration ready
Processes/ trainings ready
Organization ready
Communication ready
Risks addressed
Test case coverage sufficient Bugfixing completed Production readiness
Software quality ready
Test case cover- Current (% of age sufficient KPI Go-live criterion)
Detail assessment for bugfixing completed UAT Cycle 1 completed Test cases 1 Cycle 2 completed
Bugfixing Test cases completed completed
Quality criteria satisfied
Go-live criterion (% of total) 1,871 (90%)
Total
Current plan
2,079
2,079
Test cases Production completed readiness
///////////////////// Test cycle not started /////////////////////
Test cases completed
///////////////////// Test cycle not started /////////////////////
Lasttest Cycle 3 … bestanden Showstopper criteria satisfied
Bugfixing completed
1,598 (85%)
Defects fixed
44 (53%)
83 (100%)
83
n/a
Defects fixed
30 (43%)
70 (95%)
74
n/a
Defects fixed Cosmetic defect Defects criteria satisfied fixed
13 (52%)
25 (90%)
28
n/a
1
n/a
Major defect criteria satisfied Minor defect criteria satisfied
1 (n/a)
0
(0%)
Quelle: COREtransform
Abbildung 17: Abnahmekriterien für den Go-live
Die konsolidierte Aufbereitung des Programmfortschritts anhand von Go-live-Kriterien ermöglicht eine faktenbasierte Betrachtung und verknüpft den Status der Arbeiten innerhalb der (Teil-)Projekte mit dem übergrei fenden Status der Go-live-Readiness. Das erlaubt es, Handlungsbedarfe zu identifizieren und zu gewichten, um Maßnahmen zu ihrer gezielten Steu erung ergreifen zu können.
21 An Zielen festhalten © CORE 2013
Mit Blick auf die Abnahmekriterien werden für einzelne Bereiche spezi fische und in mehreren Ebenen detaillierte sowie nach Risiko gewich tete Anforderungen formu liert, deren Umsetzungsgrad Fokus: Sachbezogene und kontinuierlich berichtet wird sukzessive Freigaben (Abb. 17). Die daraus resultie renden Kennzahlen ermögli Um die finale Entscheidung zur Frei chen eine jeweils genaue und gabe des Go-lives durch den Vorstand faktenbasierte Entscheidung zu ermöglichen, können Entschei zur Abnahme. Zugleich ist dungskaskaden (Abb. 18) die koordi durch das Projekt-Manage nierte Berücksichtigung aller Stake ment dafür zu sorgen, dass holder sowie der Fach- und IT-Seite sämtliche Stakeholder über sicherstellen. den Fortschritt informiert und ihre Erwartungen berücksichtigt werden. Die Abnahmekriterien stellen die notwendige Transparenz dafür her.
Anhand detaillierter Kriterien Entscheidungsfähigkeit herstellen
Entscheidungen zur Freigabe vor dem Go-live Sign-off program
Sign-off line organization
Sub-programs
Business & Operations
Banking Investment
Sales
Lending
Product management
Channels
Services
Sales Bank controlling
Finance
Introduction management
Sign-off overall program Program/ release management
Go-live sign-off
IT
Program steering committee
Business Finance
Business management IT
Deposits
Overall program management
Go/ No-Go COO CFO
Point of no return
CIO
IT Business
Payments
Application management Production management Standard S/W provider
Services Organization management Finance Business units
T-23 days
Quelle: COREtransform
T-16 days
T-13 days
T-12 days
T-9 days T
Abbildung 18: Freigabe- und Entscheidungskaskade
Die koordinierende Strukturierung der Entscheidungen aller Stakeholder anhand der Freigabekaskade erlaubt, zum einen die Abhängigkeiten der Zuständigkeiten zu berücksichtigen; sie dient zum anderen dazu, even tuelle Bedarfe unter Wahrung der Verantwortlichkeiten transparent zu machen und gezielt zu adressieren.
22 An Zielen festhalten © CORE 2013
4
Transformationen zielgerichtet zum Erfolg führen
Die Steuerbarkeit des Projekts und die Steuerungsfähigkeit des Manage ments sind kritisch für den Erfolg der Transformation. Komplexität und Unsi cherheit des Projekts sind nicht zu eliminieren, sondern kontextabhängig zu adressieren. Es bedarf eines seinerseits komplexen Managements, das auf Basis von Wissen, Fähigkeiten und Erfahrungen und mit Hilfe diffe renzierter Mechanismen und Instrumente vielseitig agieren kann, um die zentralen Herausforderungen zielgerichtet und erfolgreich zu steuern.
Fokus auf kritische Erfolgsfaktoren stets beibehalten
›› Orientierung bieten: Ein adäquates Framework, das eine Einteilung nach verschiedenen Phasen mit spezifischen Management- und ControllingScopes kombiniert, stellt die Orientierung über die gesamte Dauer des Programms und die Konstanz des Vorgehens für alle Beteiligten sicher. ›› Entscheidungen treffen: Das Entscheidungsmanagement sorgt für eine ausgewogene Basis sowohl der notwendigen Informationen als auch der wesentlichen Scopes der Entscheidungen in Abhängigkeit von einzelnen Projektphasen, um so ein konsequentes Entscheiden zu ermöglichen. ›› Tools nutzen: Differenzierte Methoden und Tools sichern die Ergebnis qualität und verschaffen detaillierte Informationen über Status und Fort schritt insbesondere kritischer Bereiche, um in ihnen Steuerungsbedarfe zu identifizieren und Entwicklungen granular zu justieren. ›› Experten vernetzen: Die Identifikation und Vernetzung der für die Trans formation notwendigen Mitarbeiter und Fähigkeiten stellt sicher, dass die jeweils besten Spezialisten die identifizierten Bedarfe sowohl scopespezifisch als auch phasenübergreifend optimal erfüllen. ›› Projekte zum Abschluss führen: Das Go-live-Management konsolidiert die Ergebnisse der Projekte anhand spezifischer Go-live-Kriterien und stellt komplementär die Entscheidungsfähigkeit unter Beteiligung aller Stakeholder her, um die nötige Kraft für den Abschluss der Transforma tion aufzubringen. Mit Hilfe dieser Steuerungsmechanismen gelingt es dem Management, am Ziel der Transformation des Kernbanksystems durch alle Phasen des Programms hindurch festzuhalten und damit die Transformation zielge richtet und effizient zum Erfolg zu führen – um mit der Standardisierung der IT einen wichtigen strategischen Baustein für die Herausforderungen des Strukturwandels im Bankenmarkt zu setzen.
23 An Zielen festhalten © CORE 2013
Anhang Anbieter von Banking-Standardsoftware Europa ABIT
G&H Bankensoftware
afb Application Services
iBS – Innovative Banking Solutions
Asseco South Eastern Europe
ICS Financial Systems
Avaloq
International Financial Systems
b+m Informatik
Intertech
B+S Banksysteme
Inversia
Banking Information Systems
Knowis
Bavaria Banken Software
Misys
BearingPoint
msg Gillardon
Bosch Software Innovations
Murex
Capital Banking Solutions
Neptune Software
Center of Financial Technologies
PASS Consulting Group
Colvir Software Solutions
Probanx
Commercial Banking Applications
Prof. Schumann
COR&FJA Alldata Systems
Profile
CPU Bankensoftware
R-Style Softlab
Delta Informatique
SAB Ingenierie Informatique
Diasoft
Sage
DIE SOFTWARE Peter Fitzon
SAP
e.stradis
SmartStream
EFDIS
SOPLEX Consult
ERI Bancaire
Sopra Banking Software
EVRY
Subito
Exictos
Temenos Group
FERNBACH Financial Software
Torstone Technology
Finnova
UNiQUARE Software Development
Forbis
zeb/rolfes.schierenbeck.associates
FORS-Banking Systems Nord- & Südamerika Accenture Software
Fundtech
ACI Worldwide
Harland Financial Solutions
Calypso Technology
International Private Banking Systems
Calyx Software
Kyriba
CLS Group
Mimics
Cobiscorp
Open Solutions
Computer Sciences Corporation
Openlink Financial
Datapro
Premium Technology
De Larrobla & Asociados (DL&A)
Provenir
Financial Software Systems
Sungard
FIS
Top Systems
FISA Systems
TwoFour Systems
Fiserv
Wall Street Systems
Asien 3i Infotech
International Turnkey Systems
Agile Financial Technologies
Nucleus Software
Autosoft Dynamics
Oracle Financial Services Software
BML Istisharat
Path Solutions
HCL Technologies
Polaris Financial Technology
Infopro
Silverlake Axis
Infosys
Tata Consultancy Services
InfrasoftTech Ozeanien CCK Financial Solutions
New Technology Business Solutions
Eine Datenbank mit weiteren Informationen zum Produktportfolio der Anbieter ist verfügbar unter http://www.coretechmonitor.com.
24 An Zielen festhalten © CORE 2013
Autoren Christian Böhning ist Managing Director von CORE. Er hat zuvor in mehreren internationalen Projekten die Transformation von Kernbanksystemen in verantwort licher Funktion begleitet. Schwerpunkt seiner Arbeit ist das IT-Transformationsmanagement, insbesondere in den Aspekten Technologie, Prozesse, Umsetzungspla nung und -steuerung in geschäftskritischen Bereichen.
Dr. Mirko Schiefelbein ist Knowledge Manager bei CORE. Er wurde in Philosophie promoviert und verfügt über eine Vielzahl an Referenzen zu interdisziplinärer Forschung. Er hat mehrere wissenschaftliche Projekte begleitet und den Aufbau eines Wissensportals im Bil dungsbereich verantwortet. Er ist spezialisiert auf integ rierte Wissenstransformation.
Christian Schneider ist Transformation Associate bei CORE. Er hat an der Maastricht University einen Master of Science in Financial Economics erworben und zum Zusammenhang zwischen Motivation und Verhalten ge forscht. Er bringt seine Markt- und Managementkompe tenz schwerpunktmäßig im Bereich der Steuerung kom plexer IT-Transformationsprojekte ein.
Christian Böhning
Dr. Mirko Schiefelbein
Christian Schneider
Über das COREinstitute Das COREinstitute erforscht die Dynamik und Systematik komplexer Transformationen in verschiedenen Industrien und Sektoren, um neue Lösungsansätze im Transformationsmanagement für Industrieexperten, Wissenschaftler und Ingenieure zu entwickeln. Die Resultate seiner inter disziplinären Forschungen stellt das COREinstitute in verschiedenen Medien und Publikationen einer breiteren Öffentlichkeit zur Verfügung. Disclaimer Die abgebildeten Logos stehen im Eigentum der jeweiligen Unternehmen. Die COREtransform GmbH hält keine Rechte an den Logos und nutzt diese ausschließlich zu wissenschaftlichen Zwecken.
25 An Zielen festhalten © CORE 2013
COREtransform GmbH Am Sandwerder 21 14109 Berlin | Germany Web: www.coretransform.com Blog: www.coretechmonitor.com Phone: +49 30 26344 020 Email:
[email protected] Copyright © COREtransform GmbH Dezember 2013
