MAS Business Information Management. Diplomarbeit Geschäftsorientiertes IT-Architekturmanagement in der Zürcher Kantonalbank

Transkript

1 MAS Business Information Management Diplomarbeit Geschäftsorientiertes IT-Architekturmanagement in der Zürcher Kantonalbank Die IT-Architektur als Bestandteil der Unternehmensarchitektur Verfasser: Betreuer: Rainer Endl, FHS St. Gallen Korreferent: Dieter Bühler, Zürcher Kantonalbank Studiengang: NDS BI 7 Eingereicht: 30. Oktober 2006

2 Danksagung Herzlichen Dank an meine Frau Claudia und meine beiden Töchter Sarah und Nadine für die Geduld und Unterstützung während der Ausbildung an der FHS St. Gallen und der nun abgeschlossenen Entwicklung der Diplomarbeit. Gedruckt am Seite 2 von 95

3 Inhaltsverzeichnis 1 Vorwort Management Summary Einleitung Aufbau der Arbeit Erarbeitungsprozess und Vorgehensweise Themen-Abgrenzung Rahmenbedingungen Vorstellung der Zürcher Kantonalbank Geschichtlicher Rückblick Öffentlicher Leistungsauftrag Entwicklung von der Hypothekar- zur Universalbank Strategische Neuausrichtung Unternehmensprofil Marke ZKB Die ZKB in Zahlen Geschäftsstrategie Kundensegmente Produkte und Dienstleistungen Vertriebskanäle Geschäftsprozesse Organisation Situationsanalyse IT-Strategie und IT-Governance IT-Strategie IT-Governance IT-Architektur und IT-Architekturmanagement Aufbau des IT-Architekturmanagements Zielsetzungen des IT-Architekturmanagements Modell der IT-Architektur Strategische Software-Produkte Organisationsberatung Produktmanagement Komponentenbasiertes Produktmanagements Organisation des Produktmanagements Unternehmensentwicklung Risikosteuerung Bewertung der Situationsanalyse Stärken- / Schwächen-Analyse Ziel-Entwicklungsprozess Ziele Erhöhung der Geschäftsorientierung Strategisches Anforderungsmanagement Entwicklung eines IT-Architektur-Führungsmodells Zusammenfassung der Ziele Lösungsentwicklung Definition Architektur und Architekturmanagement Definition der Geschäftsorientierung Kontrollierte Entwicklung Nutzen für das Alignment Optimierung der Vernetzung Beschreibung und Bewertung von Architekturmodellen Beschreibung von Architekturmodellen Bewertung der Architekturmodelle Entscheidung für Architekturmodell Massnahmen zur Erhöhung der Geschäftsorientierung...56 Gedruckt am Seite 3 von 95

4 7.4.1 Vernetzung der wesentlichen Führungsbereiche Integration in die wesentlichen Führungsprozesse Lieferung von Führungsinformationen Stiftung eines nachhaltigen Nutzens Weitere Massnahmen Strategisches Anforderungsmanagement Strategisches Architekturmanagement Operatives Architekturmanagement Anforderungsmanagement und Architekturmanagement Entwicklung eines IT-Architektur-Führungsmodells Kerngeschäfte und Unternehmensarchitektur Aufgaben in den Architekturdomänen Linienorganisation Personalkapazität nach Rollen Umsetzung Umfang und Abgrenzung Umsetzungsplanung Beurteilung der Ziel-Erreichung...79 Literaturverzeichnis...80 Tabellenverzeichnis...81 Abbildungsverzeichnis...81 Anhang A: Durchgeführte Interviews...83 Anhang B: Weitere Architektur-Modelle...87 Anhang C: Ergänzende Grafiken...89 Anhang D: Abkürzungen und Begriffe...92 Gedruckt am Seite 4 von 95

5 1 Vorwort Die vorliegende Diplomarbeit ist im Rahmen des Studiums «Master of Advanced Studies (MAS) Business Information Management» an der FHS St. Gallen, Fachhochschule für angewandte Wissenschaften entstanden. Die Diplomarbeit wurde von August 2006 bis Oktober 2006 erarbeitet. Die Geschäftsorientierung des IT-Architekturmanagement bewegt mich. Mir ist es wichtig, dass das Management der Geschäftsseite versteht, warum eine Konstruktions- oder Gestaltungsmassnahme in der IT nach einem definierten Muster vorgenommen wird. Auch die Wechselwirkung ist für mich zentral: Die IT muss die kurzfristigen aber auch die mittel- und langfristigen Absichten des Geschäftes verstehen und entsprechend kundenfreundliche, tragfähige und bezahlbare Lösungen entwickeln. Es handelt sich bei dieser Arbeit um eine Analyse von verschiedenen softwareneutralen Modellen für den Aufbau von Unternehmensarchitekturen als konsequente Weiterentwicklung von in der ZKB bestehenden einzelnen, teilweise isolierten Architekturdisziplinen. Die IT-Architektur und das IT- Architekturmanagement werden dabei ein Bestandteil der Unternehmensarchitektur. Das IT- Architekturmanagement wird mit verschiedenen anderen Disziplinen im Unternehmen vernetzt, beispielsweise dem Produktmanagement oder dem Risikomanagement. Besonderes Augenmerk habe ich auf eine mehrschichtige Erhöhung der Geschäftsorientierung gelegt - dies soll neben der Nutzung eines integralen Modells durch optimierte Präsentationsformen, gemeinsame Sprache und Veränderungen in der Organisation erreicht werden. Die Entwicklung der Arbeit war fordernd - insbesondere weil sie parallel zum normalen Arbeitspensum und zu familiären und militärischen Engagements erarbeitet wurde. Die Prioritäten mussten entsprechend gesetzt und die Kräfte eingeteilt werden. Durch diese Diplomarbeit möchte ich die Diskussion rund um die Thematik der Unternehmensarchitektur in der ZKB lancieren. Ist die Bank bereit, eine Unternehmensarchitektur umzusetzen und in der Steuerung und Entwicklung konsequent anzuwenden, gewinnt das Unternehmen an Transparenz und die Abstimmung zwischen Geschäft und IT wird markant verbessert. An dieser Stelle möchte ich mich ganz herzlich bei meinem Korreferenten und Auftraggeber Dieter Bühler für seine Unterstützung und die wegweisenden Feedbacks bedanken. Weiterhin möchte ich bei den Interview-Partnern für die interessanten und intensiven Gespräche bedanken, der Meinungsaustausch war offen und der Dialog transparent. Um die Arbeit lesbarer zu gestalten habe ich darauf verzichtet, doppelte Nennungen für die weibliche und die männliche Form zu verwenden. Zudem wurde bewusst darauf geachtet, möglichst deutsche Begriffe zu verwenden und Anglizismen zu reduzieren. Wetzikon, im Oktober 2006 Stefan Lenz Gedruckt am Seite 5 von 95

6 2 Management Summary Die Situationsanalyse beleuchtet verschiedene Geschäftsbereiche der Zürcher Kantonalbank (ZKB), welche sich in ihrer täglichen Arbeit mit modellartigen Darstellungen und Analysen des Unternehmens und seinen Leistungen befassen. Eine gemeinsame Basis im Sinne eines einheitlichen Modells konnte noch nicht gefunden werden - dies obwohl es sich immer um das gleiche Unternehmen ZKB mit den gleichen Produkten und Leistungen für die definierten Kunden handelt. Die Entscheidungsträger werden so mit immer anderen - teilweise auch neuen - Darstellungen zu ihrem vertrauten Umfeld konfrontiert. Die Transparenz ist ungenügend, die Meinungsbildungs- und Entscheidungstätigkeit wird unnötig erschwert. Die Arbeit schlägt deshalb vor, verschiedene Modellentwicklungen und Analysebereiche in einer Unternehmensarchitektur nach dem Zachman-Rahmenwerk zu integrieren und diese nach der Methode TOGAF ADM aufzubauen. Nach einem Initialaufwand, welcher in Projektform geleistet werden muss, sind die Führungskräfte gefordert, das integrale Modell der Unternehmensarchitektur zu nutzen und zu unterstützen. Die Wahl des Rahmenwerks wird durch einen sorgfältigen Modell-Vergleich untermauert, für die Beurteilung der verschiedenen Rahmenwerke wird eine Nutzwert-Analyse verwendet - dies objektiviert die Bewertung. Verglichen wurden das Zachman-Framework, TOGAF der OpenGroup und Motion von Microsoft. Um die Geschäftsorientierung des IT-Architekturmanagements weiter zu erhöhen wurden Vorschläge für einen gemeinsame Sprache und optimierte Präsentationsformen entwickelt. Die Standardisierung dieser Elemente ist wichtig, da empfängergerechte Kommunikation ein kritischer Erfolgsfaktor der Architekturarbeit darstellt. Kommunikation benötigt eine verständliche Sprache und ansprechende Präsentationsformen. Ein weiterer Baustein in der Erhöhung der Geschäftsorientierung stellt das strategische Anforderungsmanagement dar, das es dem strategischen und operativen Architekturmanagement ermöglicht, Entwicklungen und Tendenzen frühzeitig zu erkennen und so eine kontrollierte Entwicklung des Unternehmens zu unterstützen: Zu extensive «Time-to-Market»- oder «Over- Engineering-Ansätze» müssen vermieden werden. Mit verschiedenen Interview-Partnern wurde die Geschäftsorientierung des IT-Architekturmanagements diskutiert, das Spektrum der Antworten ist in einzelnen Fragestellungen breit, bei Punkten wiei «Vernetzung der Architekturdisziplinen» oder der Beurteilung der heutigen Organisationsform waren die Antworten klar und nahezu einheitlich. In den Interviews konnte auch herausgeschält werden, dass Architekturmanagement für die ZKB eine wichtige Kompetenz darstellt. Damit die Unternehmensarchitektur auch mit den entsprechenden Rollen aufgebaut und weiterentwickelt wird, wurden zwei Führungsmodelle erarbeitet sowie der Personalbedarf nach bekannten Rollen des SwissICT geschätzt. Aufgrund der herrschenden Unternehmenskultur wurde ein dezentrales Führungsmodell als Umsetzungsvorschlag gewählt. Die Umsetzbarkeit einer Unternehmensarchitektur wird abschliessend mit einem Umsetzungsplan als strategisches Programm skizziert. Mit 10 Aktivitäten kann eine Unternehmensarchitektur basierend auf dem standardisierten Rahmenwerk von Zachman in rund 24 Monaten aufgebaut werden. Für die Umsetzung einer Unternehmensarchitektur ist ein Grundsatzentscheid und das Commitment der Geschäftsleitung zwingend. Gedruckt am Seite 6 von 95

7 3 Einleitung 3.1 Aufbau der Arbeit Die vorliegende Diplomarbeit ist in fünf Bereiche gegliedert: Vorstellung der Zürcher Kantonalbank Situationsanalyse Ziel-Entwicklungsprozess Lösungsentwicklung Umsetzung Im ersten Abschnitt wird die Zürcher Kantonalbank (ZKB) kurz geschichtlich beschrieben. Zudem werden ein Unternehmensprofil vermittelt, die Geschäftsstrategie und die wesentlichen Elemente der Organisation beschrieben. Die Situationsanalyse schildert den aktuellen Stand des IT-Architekturmanagements, der IT- Architektur und die Entwicklung und Positionierung im Unternehmen. Weiterhin werden verschiedene Organisationsbereiche erläutert, welche sich ebenfalls mit Architektur-Themen oder architekturnahen Themen befassen. Der Abschnitt des Ziel-Entwicklungsprozesses beinhaltet die Entwicklung der Ziele dieser Diplomarbeit. Die Ziele sind nicht quantitativ messbar, sie beschreiben einen anzustrebenden qualitativen Zustand für das IT-Architekturmanagement in der ZKB. Die Lösungsentwicklung befasst sich mit verschiedenen Modellen für Unternehmensarchitekturen und bewertet diese nach definierten Kriterien. Für die Themengebiete werden Lösungs- bzw. Optimierungsvarianten im Sinne eines Vorschlages ausgewählt. Der Abschnitt der Umsetzung skizziert den Umsetzungsprozess als strategisches Programm. Darin werden verschiedene Projekte zur Implementation der Lösungen geführt. Die Rahmenbedingungen und Entscheidungspunkte werden auf der Zeitachse dargestellt. 3.2 Erarbeitungsprozess und Vorgehensweise Die Situationsanalyse basiert einerseits auf Erkenntnissen aus Interviews, welche im persönlichen Gespräch mit verschiedenen Exponenten im Management der ZKB durchgeführt wurden. Andererseits wurden durch den Autor verschiedene Lieferobjekte und Dokumentationen der Architekturarbeit analysiert. Die verfügbaren Dokumente aus dem IT-Architektur-Kontext wurden analysiert und verglichen: Applikations-Architektur-Vertiefungen Prozess-Landkarten Technologie-Landkarten Beschreibungen des Produktmanagements Prozess-Dokumentationen und Ablauf-Diagramme 1 Fachanforderungen und Projektportfolio-Listen Architektur-Stellungnahmen zu Projektpflichtenheften 1 Die ZKB unterscheidet zwischen Prozess- und Ablaufdiagrammen. Während die Prozess relativ stabil sind, sind Ablaufdiagramm als eigentliche Arbeitsanleitungen häufigen Änderungen unterworfen. Gedruckt am Seite 7 von 95

8 Aus den Interviews konnten wertvolle Informationen zur Positionierung der IT-Architektur, zur Vernetzung der Organisation und der Prozesse sowie zu den Präsentationsformen gewonnen werden, die in den Zielentwicklungsprozess eingeflossen sind. Weiter einbezogen in die Situationsanalyse wurden die eigenen beruflichen Erfahrungen, in der Funktion als Leiter Business Technology. Ein wesentliches Element im Kontext der Erhöhung der Geschäftsorientierung ist die Analyse und Bewertung verschiedener Rahmenwerke für Architektur, welche den Aufbau einer Unternehmensarchitektur ermöglichen. Die öffentlich zugänglichen Dokumentationen zu diesen Rahmenwerken wurden analysiert, die Modelle verglichen und nach definierten Kriterien bewertet. Bild 1: Erarbeitungsprozess und Vorgehensweise für die vorliegende Diplomarbeit Für die Lösungsentwicklung wurden durch den Autor drei Schwerpunktthemen definiert, die basierend auf der Situationsanalyse und den Interview-Ergebnissen, verschiedene Schwachstellen optimieren und so das IT-Architekturmanagement und die IT-Architektur mittelfristig geschäftsorientierter gestalten. Die Beschreibung der Umsetzung beinhaltet einen selbständig entwickelten Masterplan für ein Programm, welches das IT-Architekturmanagement sukzessive zu einer Unternehmensarchitektur entwickelt bzw. die IT-Architektur in eine Unternehmensarchitektur integriert. Als Basis für die Umsetzung dienen das ausgewählte Architektur-Rahmenwerk und die entsprechenden Methoden. 3.3 Themen-Abgrenzung Im Rahmen dieser Diplomarbeit wird das Thema des IT-Architekturmanagements in der ZKB beleuchtet, der Fokus liegt auf der Optimierung des heutigen IT-Architekturmanagements um dieses geschäftsorientierter zu gestalten. Die stärkere Geschäftsorientierung soll mit verschiedenen Massnahmen, wie beispielsweise der gezielten Vernetzung von Prozessen und Organisationen, welche sich mit der Entwicklung des Unternehmens befassen oder einer Veränderung in der Art der Dokumentation und der Kommunikation, erreicht werden. Die vorliegende Arbeit vergleicht das in der ZKB angewendete Metamodell für die IT-Architektur mit den Standard-Modellen «OpenGroup TOGAF 2», dem «Zachman-Framework» und dem relativ neuen Modell «Motion» von Microsoft. 3.4 Rahmenbedingungen In der vorliegenden Dokumentation wird die vorhandene Organisationsstruktur als Ausgangslage betrachtet. Um die strategische Entwicklung des Unternehmens einheitlicher oder effizienter zu betrei- 2 Das TOGAF-, Zachman-Framework und das Modell Motion sind Modelle für Unternehmensarchitekturen Gedruckt am Seite 8 von 95

9 ben, müssen verschiedene Bereiche über definierte Prozesse enger zusammenarbeiten. In einzelnen Bereichen sind auch Überprüfungen der Aufbauorganisation oder des Mitarbeiterportfolios empfehlenswert. Hinweise in diesem Kontext sind als Empfehlungen zu verstehen. Gedruckt am Seite 9 von 95

10 4 Vorstellung der Zürcher Kantonalbank 4.1 Geschichtlicher Rückblick Am 15. Februar 1870 eröffnete die Zürcher Kantonalbank ihren ersten Schalter. Damit wurde die schon früh im 19. Jahrhundert gereifte Idee einer volksnahen Bank verwirklicht. Die privaten Aktienbanken (die späteren Grossbanken) hatten sich während der Industrialisierung vor allem lukrativen Investitionsvorhaben in Industrie und Handel zugewandt. Insbesondere wurden der Hypothekarkredit und die sonstigen Kapitalbedürfnisse für Arbeiter, Handwerker und Angestellte, für landwirtschaftliche und gewerbliche Betriebe sowie für kleinere und mittlere Industrieunternehmungen vernachlässigt. Hier sollte die «Bank des Zürcher Volkes» einspringen Öffentlicher Leistungsauftrag Der öffentliche Leistungsauftrag und die gesellschaftspolitische Verantwortung wurden denn auch gesetzlich festgeschrieben: Die neue Bank sollte zur Lösung der volkswirtschaftlichen und sozialen Aufgaben im Kanton Zürich beitragen. So steht es heute noch im ZKB-Gesetz. Als Träger kam für die Gründer nur der Staat in Frage. Dieser sollte das Dotationskapital zur Verfügung stellen, die Verbindlichkeiten der Bank garantieren (Staatsgarantie) und die obersten Organe bestimmen. So gehört die ZKB seit 1870 dem Staat, untersteht aber nicht der Regierung, sondern direkt dem Kantonsrat, der den Bankrat als Aufsichtsorgan wählt Entwicklung von der Hypothekar- zur Universalbank In der zweiten Hälfte des 20. Jahrhunderts wuchs die schweizerische Wirtschaftsmetropole Zürich zu einem der bedeutendsten internationalen Finanzplätze heran. Die Zürcher Kantonalbank hielt mit dieser Entwicklung Schritt, indem sie ihr Geschäftsvolumen stark ausdehnte und ihre Leistungen entsprechend den geänderten Bedürfnissen vielfältiger und breiter ausgestaltete. Zwischen 1960 und 1988 hatte sich die Bilanzsumme der ZKB fast verzehnfacht; sie stieg von 3,8 Mia. Franken auf fast 35 Mia. Franken. Gleichzeitig nahm die Zahl der Mitarbeiterinnen und Mitarbeiter von 986 auf 3740 zu. Die Schwerpunkte bildeten in dieser Zeit Spar- und Hypothekargeschäfte feierte die ZKB ihr 125-Jahr-Jubiläum. Aus der lokalen Hypothekarbank von einst ist längst eine Universalbank mit internationaler Ausstrahlung geworden. Sie hat ihre Geschäftstätigkeit im Laufe der Zeit immer wieder den wirtschaftlichen und gesellschaftlichen Veränderungen angepasst, unter anderem bot die ZKB 1994 als erste schweizerische Bank das Online-Banking an Strategische Neuausrichtung Die Konzentration im schweizerischen Bankensektor und der Preiseinbruch im Immobilienmarkt Mitte der 1990er-Jahre stellten die ZKB vor neue Herausforderungen: Unter dem Namen «FIT 1» und «FIT 2» wurden eine strategische Neuausrichtung und ein umfassender Umstrukturierungsprozess eingeleitet. 3 3 Siehe Geschäftsbericht 2005 der ZKB auf der Website der ZKB [ZKB 2005a] Gedruckt am Seite 10 von 95

11 4.2 Unternehmensprofil Marke ZKB Die Marke der ZKB umfasst drei prägnante Begriffe: «persönlich, kompetent, verantwortungsvoll». Diese Elemente gilt es in der Kundenbetreuung, der Beratung, in den Produkten und Prozessen sowie den Vertriebskanälen für den Kunden spürbar und erlebbar zu machen. Bild 2: Das blaue Logo der Zürcher Kantonalbank mit dem ergänzenden Claim. Als Ergänzung zum Logo «Zürcher Kantonalbank» hat die ZKB den Claim 4 «Die nahe Bank» definiert. Der Faktor «nahe» soll einerseits emotional andererseits auch physisch wahrgenommen werden. Das bedeutet, dass die ZKB nebst der Kundennähe auch ein sehr dichtes Filialnetz betreibt. Bild 3: Das dichte Filialnetz mit 109 Geschäftsstellen im Kanton Zürich Das Filialnetz ist unterteilt in fünf Regionen bzw. Marktgebiete, welche von den kundensegmentsorientierten Vertriebsorganisationen Firmenkunden und Privatkunden bearbeitet werden. Die Regionen ihrerseits führen die entsprechenden Filialen bzw. Agenturen. Jede Geschäftsstelle ist basierend auf der Kundenstruktur im nahen Umfeld in eine bestimmte Filialklasse eingeteilt und bietet entsprechende Produkte und Dienstleistungen an. Bild 4: Die ZKB als Berater für Firmen und Private - in allen Lebensphasen 4 Ein Claim definiert das Kompetenzfeld einer Marke näher und beschreibt auch ein Markenversprechen. Gedruckt am Seite 11 von 95

12 4.2.2 Die ZKB in Zahlen Kennzahl Veränderung Bilanzsumme CHF 79,9 Mrd CHF 85,9 Mrd + 6,9 % Bruttogewinn CHF 744 Mio CHF 795 Mio % Konzerngewinn CHF 695 Mio CHF 810 Mio % Eigenkapitalrendite (ROE) 13.7 % 14.5 % % Cost-Income-Ratio 61.8 % 64.0 % % Personalbestand 4'139 4' % Tabelle 1: Die Geschäftsjahre 2005 und 2004 der ZKB im Zahlenvergleich 4.3 Geschäftsstrategie Die Geschäftsstrategie 5 der ZKB beschreibt den Weg, zur Umsetzung der Vision «Finanzdienstleister Nr. 1 im Wirtschaftsraum Zürich». Der Wirtschaftsraum Zürich orientiert sich dabei nicht an den Kantonsgrenzen - insbesondere im Firmenkundengeschäft ist die ZKB weit über die Kantonsgrenzen hinaus aktiv und betreut Firmenkunden in der gesamten deutschsprachigen Schweiz. Die Vision der ZKB bedeutet, dass sie als grosse Schweizer Bank eine national führende Anbieterin ausgewählter Dienstleistungen für mittlere und grosse Unternehmen, Banken, Institutionelle und öffentlich-rechtliche Körperschaften werden will. Ein wichtiges Element der Geschäftsstrategie ist auch die Erreichung der Insourcingfähigkeit für Bankprozesse inkl. deren IT-Unterstützung. Das bedingt, dass sämtliche Prozess- und Applikations- Entwicklungen die Prinzipien befolgen, welche eine Nutzung durch mehrere Mandanten (unterschiedlichen Banken) ermöglichen Kundensegmente Die Kunden werden in verschiedene Haupt- und Untersegmente unterteilt: Privatkunden Firmenkunden Private Banking-Kunden Banken Das Segment der Privatkunden umfasst die breite Masse der rund 400'000 Kunden, bei einer relativ bescheidenen Komplexität. Die Firmenkunden inkl. Banken hingegen stellen laufend höhere Anforderungen an die Dienstleistungen der Bank durch zunehmende Automatisierung von Prozessen. Die Untersegmente differenzieren die Kundensegmente bezüglich ihrem Marktergebnis, beispielsweise werden die Privatkunden in Basiskunden, Privatkunden und vermögende Privatkunden unterteilt Produkte und Dienstleistungen Das Produkt- bzw. Dienstleistungsangebot der Universalbank ZKB umfasst die folgenden Kerngeschäfte: Immobilien- und Finanzierungsgeschäft Anlage- und Vermögensverwaltungsgeschäft 5 Zusammenfassung aus [ZKB2006a] Gedruckt am Seite 12 von 95

13 Handel und Kapitalmarkt Geldverkehr Die ZKB bietet ihren Kunden segmentsübergreifend alle wesentlichen Finanzdienstleistungen in einer umfassenden Breite und Tiefe an. Dabei werden die Bedürfnisse der Kunden über den ganzen Lebenszyklus abgedeckt. Wo dies mit eigenen Produkten nicht möglich ist, werden diese durch ausgewählte Drittprodukte ersetzt oder ergänzt Vertriebskanäle Der Vertrieb der Produkte und Dienstleistungen erfolgt über einen definierten Mix in drei Vertriebskanälen: Filialbank = FIBA Contactbank = CONBA Onlinebank = ONBA Die Filialbank FIBA ist der primäre Vertriebskanal, über diesen Vertriebskanal erfolgt die Betreuung und Beratung sowie der Verkauf persönlich, kompetent und verantwortungsvoll durch den Kundenbetreuer: Für die Kundenbetreuung wird ein Betreuer/Berater-Prinzip angewendet, das heisst, dass jedem Kunden ein Kundenbetreuer zugewiesen wird, der für alle seine Wünsche, Pläne und Ziele zuständig ist. Für anspruchsvolle Beratungen (Finanzplanung, Nachfolgeregelung usw.) zieht der Kundenbetreuer bei Bedarf einen Experten als Berater bei. Die Kanäle CONBA und ONBA sind unterstützende Vertriebskanäle zur Filialbank, über die Kanäle ONBA und CONBA werden bewusst keine Beratungen angeboten, diese Vertriebskanäle sind auf Transaktionen (Zahlungen, Börsenaufträge) und Informationsbezug (Kontosaldo, Auftragsstatus) fokussiert. Die Vertriebskanäle sind untereinander vernetzt, das bedeutet, dass der Kunde seine Produkte und Dienstleistungen grundsätzlich auf jedem der drei Kanäle nutzen kann. Die Integration der Vertriebskanäle ist noch nicht vollständig abgeschlossen, je nach Kerngeschäft sind noch unterschiedliche Lücken vorhanden. 4.4 Geschäftsprozesse Für die Leistungserstellung in den Kerngeschäften (siehe Abschnitt 4.3.2, Produkte und Dienstleistungen) sind entsprechenden Kern- und Supportprozesse skizziert oder dokumentiert. Die Optimierung und Dokumentation von Prozessen erfolgt stark bedürfnisorientiert im Auftrag des Linienmanagements. Die aktuell verfügbaren Dokumentationen sind aufgeteilt in verschiedene Themenbereiche, die in der Vergangenheit neu strukturiert wurden - so beispielsweise in der Contactbank CONBA 6 oder im Bereich der Filialbank FIBA. Weitere Prozessbeschreibungen existieren in der Geschäftseinheit Logistik 7, im Bereich Investitionsgüterleasing 8 (Teil des Finanzierungsprozesses) oder bei den ZKB IT- Prozessen. Ein konsolidiertes Gesamtwerk in Form einer Prozess-Architektur wurde bisher nicht erarbeitet. Die Thematik der verstärkten Geschäftsprozess-Orientierung (im Gegensatz zur reinen Linienführung) ist in der ZKB noch nicht auf allen Ebenen verankert. Die Prozessorientierung und der Wille zur pro Das Call-Center wurde 1999/2000 aufgebaut, die Organisation ist prozessorientiert Der Treiber dafür war die beabsichtigte ISO-Zertifizierung der Logistik-Produktion sowie des Gebäudemanagements Das Produkt wurde im Mai 2006 neu lanciert, ein Team der GE Lisca Leasing wurde in die ZKB integriert Gedruckt am Seite 13 von 95

14 zessorientierten Steuerung und Entwicklung in Kombination mit der bewährten Kundensegments- Organisation ist je nach Geschäftseinheit unterschiedlich ausgeprägt. Während die Logistik bereits seit mehreren Jahren ein Qualitätsmanagement eingeführt hat, sind die Prozesse in den Vertriebseinheiten noch nicht einheitlich gestaltet und dokumentiert. Die Mitarbeiter und Führungskräfte der ZKB denken aus historischen Gründen stark in den Dimensionen der IT-Systeme. Für jedes IT-System sind so genannte System-Owner (Fachbereich) und System-Engineers (Informatik) definiert. Bei der Anforderungsentwicklung ist den Mitarbeitern jeweils schnell klar, welche Anpassungen in einem bzw. ihrem System nötig sind, die durchgängige Prozess- Sicht oder der Lebenszyklus von Applikationen im Sinne des Bebauungsplanes findet dabei wenig Beachtung. Die Rolle eines Prozess-Owners ist in der Bank noch nicht breit abgestützt, in einzelnen Themenbereichen (beispielsweise «ZKB IT-Prozesse») wird die Rolle aktuell eingeführt. 4.5 Organisation In der Zürcher Kantonalbank ist in der Linienorganisation in sechs Geschäftseinheiten aufgeteilt, davon stellen drei Geschäftseinheiten die Vertriebsorganisation nach den definierten Kundensegmenten dar. Bild 5: Organigramm der ZKB auf Ebene der Generaldirektion. 9 Die Vertriebsorganisationen für die Kundensegmente sind die Geschäftseinheiten Privatkunden, Firmenkunden, das Investment- und Private Banking. Sie bringen die wesentlichen Erträge der Bank ein. Die Geschäftseinheiten Finanz, Logistik und Gesamtleitung werden als Cost-Center geführt, ihre Aufwände werden über interne Leistungsverrechnung nach definierten Kostenschlüsseln auf die Vertriebseinheiten verteilt. Die Anzahl der Mitarbeiter über die Geschäftseinheiten, Bankpräsidium, Revision sowie Nebenbetriebe und Ausbildung hat sich im Verlauf von 2004/2005 wie folgt entwickelt: Geschäftseinheit Anzahl Mitarbeiter Privatkunden [P] 1'209 1'164 Firmenkunden [F] Investment- und Private Banking [I] Logistik [L] 1'425 1'514 Finanz [Z] Gesamtleitung [V] Vereinfachte Darstellung der ZKB-Organisation, erstellt auf Basis des «org.managers» im ZKB Intranet Neue Geschäftseinheit des CFO, welche Mitte 2005 aus der GE V ausgegliedert wurde Gedruckt am Seite 14 von 95

15 Geschäftseinheit Anzahl Mitarbeiter Revision [RI] Bankpräsidium [BP] 6 7 Nebenbetriebe und Ausbildung Total 4'139 4'276 Tabelle 2: Anzahl Mitarbeiter in den Geschäftseinheiten Die Geschäftseinheit Logistik beinhaltet sowohl die Produktions-Bereiche für die Zahlungsverkehrs-, Finanzierungs- und die Wertschriftenabwicklung wie auch die Informatik 11. Die Linienorganisation ist die dominierende Führungsstruktur im Unternehmen. Für die Führung von verschiedenen bankfachlichen oder fachbereichsübergreifenden Themen (Produktmanagement, Risikomanagement, IT-Organisation usw.) sind entsprechende Matrix-Strukturen vorhanden. 11 Die gesamte IT-Organisation (bestehend aus interner Informatik, externen Informatik-Mitarbeitern und der BT-Organisation) umfasst im 3. Quartal 2006 rund 1'050 Mitarbeiter. Gedruckt am Seite 15 von 95

16 5 Situationsanalyse Die Situationsanalyse beschreibt die wesentlichen Elemente der IT-Strategie und IT-Governance als Kontext der Diplomarbeit, sowie das IT-Architekturmanagement in der ZKB. Um eine möglichst umfassende Sicht bezüglich Geschäftsbereichen zu erhalten, welche die Bank und ihre Leistungen analysieren, verändern und weiterentwickeln, werden weitere Organisationen wie das Produktmanagement oder die Unternehmensentwicklung usw. beleuchtet. 5.1 IT-Strategie und IT-Governance Eine funktionale Strategie für die IT («IT-Strategie») wurde erstmals 1998 unter der Leitung von Dr. Hans F. Vögeli, damals neuer Leiter der GE Logistik, erarbeitet. Die IT-Strategie leitet sich aus folgenden übergeordneten Grundlagen ab: Leitbild/Marke, Gesamtbank-Strategie und Kundensegmentstrategien IT-Strategie Die IT-Strategie konkretisiert die Anforderungen an die IT auf Basis der Geschäftsstrategie. In der IT- Strategie sind folgende Kernaussagen dokumentiert: Unterstützung der Geschäftsprozesse Die IT der ZKB leistet einen wesentlichen Beitrag zur effizienten und effektiven Unterstützung der Geschäftsprozesse und damit zur Senkung der Prozesskosten bzw. Erreichung von geplanten Geschäftszielen. Die IT ist kein Kerngeschäft der ZKB Der IT-Betrieb sowie die Integration von Applikationen/Services, nicht aber die Applikations- Entwicklung, stellen jedoch eine Kernkompetenz dar. Die konsequente Ausrichtung der IT auf die Bedürfnisse des Bankgeschäftes wird erreicht, indem die leistungsbeziehenden Geschäftseinheiten die IT-Projekte gemeinsam priorisieren und finanzieren. Handlungsfreiheit/Flexibilität Die IT der ZKB unterstützt das Streben nach hoher Handlungsfreiheit, damit die Bank rasch auf Marktveränderungen reagieren und Handlungsoptionen wahrnehmen kann. Zu diesem Zweck verwendet die IT der ZKB wo immer möglich und wirtschaftlich sinnvoll internationale bzw. nationale Standards sowie am Markt verfügbare Applikationen/Services und Komponenten nach dem Grundsatz «Buy before make». Führendes Unternehmen Die IT der ZKB wird gemessen an definierten Kenngrössen. Zudem erfolgt die Validierung der führenden Stellung der IT der ZKB gegenüber ihren Mitbewerbern permanent durch geeignete Mittel wie Benchmarking. IT-Architektur Die IT-Architektur schafft den ordnenden Rahmen für die Integration von Prozessen, Applikationen/Services und Daten sowie technischen Systemen. Sie basiert auf einer bankweiten und durchgängigen Prozessarchitektur. Die IT-Architektur bringt Prozesse, bankfachlich-konzeptionelle Funktionalitäten, Daten sowie Applikationen/Services in eine gegenseitige Beziehung. Damit definiert sie die Struktur der Applikationen/Services in der ZKB, welche als Basis für die IT-Planung und damit für das IT- Gedruckt am Seite 16 von 95

17 Portfoliomanagement dient. Ziel ist die Förderung der Wiederverwendbarkeit (Abbau von Redundanzen bei Funktionen und Daten) sowie die Reduktion der Komplexität (Anzahl Schnittstellen). Applikationen müssen modular gegliedert sein, standardisierte Schnittstellen aufweisen sowie die bankweit definierte Integrationsinfrastruktur verwenden. Die IT-Architektur beschreibt weiter die anzuwendenden hard- und software-technischen Konstruktionsprinzipien sowie die Normen bezüglich Bau, Integration und Betrieb von Applikationen/Services sowie einzusetzender Systemplattformen. Die Ausgestaltung der IT-Architektur unterstützt die Anforderungen an eine wirtschaftliche, qualitätskonforme und den IT- Sicherheitsstandards genügende technische Basis durch eine geeignete Auswahl. Strategische Anforderungen als Treiber der Architektur Im geschäftlichen Kontext ist die Entwicklung der IT-Architektur getrieben von Anforderungen. Die bisherige Architektur der ZKB basiert auf folgenden strategischen Anforderungen 12 : Angebot einer breiten und tiefen Produktpalette einer Universalbank Konsistentes Produktangebot über alle Vertriebskanäle Abwicklung von hohen Volumen zu Spitzenzeiten Verwendung von Standard-Software anstelle von Eigenentwicklung Erreichung der Insourcing-Fähigkeit zur Erreichung von Skalen-Effekten Diese Anforderungen sind komplex, da es im Kern darum geht, eine sehr leistungsfähige Gesamtbank-Plattform (Vertrieb, Verarbeitung, Banksteuerung) für mehrere Mandanten aufzubauen. Für die Kerngeschäfte wurden verschiedene strategische Produkte (Siebel, SAP, Avaloq siehe 5.2.4, Strategische Software-Produkte) definiert. Über verschiedene Migrationsprojekte wurden und werden die Altsysteme durch Standard-Software-Produkte ersetzt. Die Migrationsprojekte 13 sind zum Zeitpunkt der Erstellung dieser Arbeit bereits weit fortgeschritten oder teilweise abgeschlossen IT-Governance In der IT-Strategie 14 ist für die IT-Governance ein Führungsmodell dokumentiert, welches auf drei E- benen beruht: Die Fachbereiche und Geschäftseinheiten stellen Anforderungen zu Anpassungen ihrer Geschäftsprozesse oder den Betrieb der Applikationen, welche durch die BTO gesammelt, koordiniert und über einen abgestimmten IT-Plan bei der internen Informatik zur Umsetzung in Auftrag gegeben werden. Vier dezentrale Business Technology-Einheiten 15 eingegliedert in die Linienorganisation der sechs Geschäftseinheiten beraten die Geschäftseinheiten in der Konkretisierung und Umsetzung ihrer IT-Anforderungen. Die BTO ist der Auftraggeber für sämtliche IT-Leistungen aus dem Fachbereich, die Business Technology-Einheiten werden fachlich aus der Logistik geführt Zusammenfassung aus [ZKB 2006b], Anforderungen an die IT Migration Wertschriften (MiWe): Abschluss im Q1/2006 erfolgt. Migration Bestandesführung Geld (MBFG): Migration Sparkonten Q1/2007, Migration Kontokorrent Q4/2007, Programm- Abschluss mit Fremdwährungs-Kontokorrent per Q4/2008 geplant. Finanzierungsprozess (FinPro): Abschluss per Q1/2007 Zusammenfassung aus IT-Strategie der ZKB [ZKB 2006b] Gegliedert in die Prozess-Dimensionen Logistik, Vertrieb, Investmentbanking, Banksteuerung Gedruckt am Seite 17 von 95

18 Die interne Informatik ist Auftragnehmer für die Umsetzung der IT-Anforderungen in Projekten («Change the bank») und den Unterhalt der laufenden Applikationen basierend auf SLA 16 («Run the bank»). Die Priorisierung und Freigabe von Anforderungen erfolgt entweder durch die Geschäftseinheiten selbst oder durch den IT-Steuerungsausschuss - dem obersten IT-Gremium der ZKB. Bild 6: Das IT-Führungsmodell der ZKB, definiert mit der IT-Strategie im Jahre Auf allen drei Ebenen sind Elemente für das IT-Controlling vorhanden. Die Geschäftseinheiten als effektive Kostenträger überwachen die Kostenverrechnung, die BTO und die Informatik als Auftraggeber bzw. Auftragnehmer steuern über das IT-Controlling die IT-Planung und Projektumsetzung und damit die Kostenentwicklung. 5.2 IT-Architektur und IT-Architekturmanagement Aufbau des IT-Architekturmanagements Die ZKB verfügt seit vielen Jahren über eine IT-Architektur, die im Verlauf der Strategie-Entwicklung («Buy before Make») auch grösseren Änderungen unterworfen war. Aus historischer Sicht ist das Kernstück der Architektur die so genannte SAR, die System-Architektur. In der SAR sind technische Grundsätze formuliert, um Applikationen zu entwickeln, sie auf definierten Plattformen zu betreiben und Komponenten von Partnern zu integrieren. Im Verlauf der Entwicklung der Bank hat die Disziplin des IT-Architekturmanagements unterschiedliche Zyklen erlebt, diese reichten von starker Kontrolle und sehr hohem Abstraktionsgrad zu Beginn der 1990er-Jahre 17 bis zum beinahe unkontrollierten Pragmatismus im e-business-hype gegen Ende des 20. Jahrhunderts. Mit der Definition der ersten IT-Strategie 1998 wurde die IT-Architektur in verschiedene Domänen aufgeteilt, nebst der System-Architektur wurde auch eine Applikations- Architektur (AAR) und eine Methodenarchitektur (MAR) entwickelt. Die Applikations-Architektur wurde erstmals umfassend im Jahr 2001 erarbeitet und publiziert, die Umsetzung der Bebauungspläne 18 in verschiedenen Bereichen wurde in Angriff genommen. Die Bebauungspläne zeigen die Entwicklung der Geschäftsprozess-Unterstützung durch Applikationen auf der Zeitachse auf (Applikations- Migrationen, Applikations-Konsolidierungen usw.) Die Service Level Agreements (SLA) beschreiben die zu erbringenden Dienstleistungen Damals wurden umfassende Konzepte wie das INGK entwickelt, INGK steht für das «Informatik-Gesamtkonzept» Die Bebauungspläne wurden für mehrere Ebenen entwickelt Gedruckt am Seite 18 von 95

19 Im Rahmen des Kostenoptimierungsprogramms «FOKUS» wurde 2001 der Personalbestand in der Business Technology Organisation (siehe 5.1, IT-Strategie und IT-Governance) reduziert. Die personellen Ressourcen für die Weiterentwicklung und Pflege der Applikationsarchitektur waren in der Folge nicht mehr vorhanden, die Architektur verlor sukzessive an Aktualität und dadurch auch an Akzeptanz. Der Einfluss von strategischen Projekten (Migration Wertschriften oder Bestandesführung Geld) auf die Architektur war gross, faktisch wurde die Architektur implizit in diesen Projekten weiterentwickelt. Zu Beginn des Jahres 2005 wurde eine Standortbestimmung der Applikations-Architektur (AAR) durchgeführt, die beschriebene Ist-Architektur wies zu vielen Bereichen der effektiven ZKB- Applikationslandschaft eine Differenz auf. Die Ziele und ein Plan zur Aufarbeitung der AAR wurden entwickelt und als strategische Massnahmen in der IT-Strategie verankert. Die bisherigen Teilbereiche der IT-Architektur wurden durch das Technologiemanagement (siehe Bild 7, Metamodell der IT-Architektur der ZKB) ergänzt. Technologiemanagement wird in der ZKB seit 1999 betrieben, eine definierte Vernetzung des Technologiemanagements mit der IT-Architektur wurde aber erst 2005 geschaffen Zielsetzungen des IT-Architekturmanagements Für das IT-Architekturmanagement wurden 2005 die folgenden Ziele durch den IT-Steuerungsausschuss verabschiedet: Wiederverwendung von einmal eingekauften/programmierten Funktionen Dokumentation und Abstimmung der Geschäftsprozesse auf Stufe Makroprozesse Schaffung von Transparenz in der komplexen Applikationslandschaft Reduktion der Anzahl betriebener Applikationen Fundierte Basis für IT-Planung und IT-Portfoliomanagement Die Aufarbeitung der IT-Architektur ist bis Ende 2006 abgeschlossen, primäres Lieferobjekt ist eine Ziel-Architektur, welche die bisherigen Analyse-Arbeiten zu Applikationen, Prozessen, Funktionen und Daten integral darstellt Modell der IT-Architektur Die IT-Architektur umfasst mehrere Teilbereiche oder Domänen mit entsprechenden Modellen. Im Mittelpunkt der IT-Architektur stehen die Geschäftsprozesse. Bild 7: Das Metamodell der IT-Architektur der ZKB Gedruckt am Seite 19 von 95

20 Die erarbeitete Prozesslandkarte (siehe , Modell der ZKB) und die Makroprozesse haben sich in der Bank bisher nicht durchgesetzt. Der Einsatz dieser Prozess-Optik fand nur in der IT Organisation (und dort primär in der BTO) statt. Neben der IT-Organisation arbeiten andere Unternehmensbereiche 19 mit eigenen Prozesslandkarten und Prozess-Dokumentationen: Organisationsberatung Produktmanagement Umweltmanagement-System (UMS) Operationelle Risiken (OpRisk) Die Prozesslandkarten dieser Bereiche unterscheiden sich auf Basis der gewählten Methode bzw. des Modells teilweise grundlegend (siehe dazu die Abschnitte 5.3, Organisationsberatung, 5.4, Produktmanagement). Eine Beschreibung der einzelnen Domänen (Prozesse, Funktionen, Applikationen usw.) der IT- Architektur ist im Abschnitt , Modell der ZKB verfügbar Prozesse des IT-Architekturmanagement Die Prozesse für das IT-Architekturmanagement sind Teil der ZKB IT-Prozesse. Die Prozesse wurden in den vergangenen Monaten entwickelt und dokumentiert, sie werden im operativen Betrieb mehrheitlich auch angewendet 20. Das IT-Architekturmanagement kennt vier Makroprozesse: IT-Architektur führen IT-Architektur entwickeln IT-Architektur beraten IT-Architektur durchsetzen In diesen vier Prozessen werden Architekturen neu entwickelt bzw. aktualisiert. Es werden Projektorganisationen oder Linien-Organisationen bezüglich Architektur-Fragestellungen beraten oder eine vorhandene Teilarchitektur wird durchgesetzt und ein Projekt muss beispielsweise seine Pläne bzw. Konzepte ändern. Das IT-Architekturmanagement besitzt somit einen ordnenden Charakter und hat gegenüber den Projekten Weisungsbefugnis. Das bedeutet, dass beispielsweise im Rahmen der Projektentwicklung definierte Lieferobjekte wie das Pflichtenheft eines Projektes von den Fachstellen der IT-Architektur (Bereich LTP), Systemarchitektur (Bereich LITA) und der IT-Sicherheit (Bereich LITS) geprüft werden. Stellen die Fachstellen im Dokument bzw. in den darin beschriebenen Konzepten Mängel oder Verstösse gegen geltende Architekturgrundsätze oder -vorgaben fest, so werden diese in einer Stellungnahme festgehalten. Jeder Mangel wird durch den IT-Architekten mit einem Schweregrad von 1 bis 4 taxiert, wobei 4 ein formaler Mangel und 1 faktisch einen Projekt-Stopp und eine Bereinigung der Situation bedeutet. Schwerwiegende Mängel müssen vor der Einführung des Projektes behoben sein. Kann ein Mangel nicht rechtzeitig beseitigt werden und handelt es sich um eine für das Geschäft wesentliche Funktion, so kann die Fachstelle eine Ausnahmebewilligung erteilen. Die zuständige BT-Einheit ist in der Folge verantwortlich, dass der Mangel in einem nächsten Release einer Applikation behoben wird Die Aufzählung dieser Bereiche ist nicht abschliessend. Die Prozessführerschaft für den Prozess «IT-Architektur führen» ist zur Zeit nicht geklärt. Gedruckt am Seite 20 von 95

21 Aufbau-Organisation des IT-Architekturmanagements Das IT-Architekturmanagement ist aus verschiedenen Gründen über mehrere Geschäftsbereichen verteilt. Die Systemarchitektur wird durch die ZKB Informatik geführt, die Prozess-, Applikations-, und Daten-Architektur durch die BTO. Bild 8: Die Geschäftsbereiche für das IT-Architekturmanagement der ZKB Die Umsetzung der definierten Architekturen erfolgt in Rahmen von IT-Projekten, welche durch die dezentral organisierte BTO (Teil der Fachbereiche) im Rahmen des IT-Portfoliomanagements definiert und in Auftrag gegeben werden Werkzeuge für das IT-Architekturmanagement in der ZKB Das Modell und der Inhalt der IT-Architektur wurden bis Mitte 2006 ausschliesslich mittels PowerPoint- Dokumentation (Präsentationszwecke) und dem «Architecture Management Framework» (AMF) verwaltet. Für die datenbankgestützte Weiterentwicklung und Nachführung der IT-Architektur wird AMF eingesetzt, AMF vernetzt die Dimensionen Prozesse, Applikationen, Daten, Funktionen und Technologien. Bild 9: Dokumentation der IT-Architektur mit AMF von Accenture, im Beispiel Informationen zur Applikation ZKBconnect Gedruckt am Seite 21 von 95

22 Präsentationsformen der IT-Architektur Die heutigen Präsentationsformen der IT-Architektur basieren weitgehend auf statischen Diagrammen, erstellt in PowerPoint oder generierten Auszügen aus AMF. Das folgende Beispiel beinhaltet das Funktionenmodell der ZKB als Universalbank: Bild 10: Funktionenmodell aus der IT-Architektur der ZKB, verwaltet mit AMF Im Rahmen der durchgeführten Interviews wurde verschiedentlich festgehalten, dass die heutigen Präsentationsformen für das Management ungenügend sind. Der Detaillierungsgrad der Darstellungen ist vielfach zu hoch, weiterhin fehlen kombinierte Sichtweisen (beispielsweise Prozesse und Applikationen). Zudem wurde angemerkt, dass das Vokabular der IT-Architektur oft von der in der Bank üblichen Sprache abweicht. Darunter leidet die Verständlichkeit der IT-Architektur und damit die Akzeptanz. Zu beachten ist dabei aber auch, dass die ZKB über kein verbindliches Unternehmensglossar verfügt. Es ist also durchaus möglich, dass für eine bestimmte bankfachliche Funktion 21 im Unternehmen mehrere unterschiedliche Begriffe zu Anwendung kommen. Das BT Vertrieb (Bereich PT) machte in der Vergangenheit bereits verschiedentlich Hinweise zum Optimierungsbedarf der IT-Architektur-Darstellungen und des Verwaltungswerkzeugs. Nach einer Analyse der Lieferobjekte, Methoden und Modelle aus der IT-Architektur mit Ergebnissen aus dem Projekt OpRisk (siehe 5.6, Risikosteuerung) konnte ein erhebliches Synergie-Potenzial bei Verwendung einer einheitlichen Rahmenwerks identifiziert werden. Da das Modell der IT-Architektur wie OpRisk die Prozesse ins Zentrum stellt, ergibt sich ein grosser gemeinsamer Nenner, auf dem die anderen Ebenen und Sichten aufgebaut werden können. 21 Beispielsweise «Basisdienstleistungen», «Geldverkehr» (Prozess- und Kerngeschäftsbezeichnungen), «Zahlungsverkehr» (eine Dienstleistung, ein Produkt). Alle drei Begriffe befassen sich mit dem Thema «Zahlen», der Leistungsumfang ist bei allen drei Bereichen jedoch unterschiedlich. Gedruckt am Seite 22 von 95

23 Nach der Evaluation von verschiedenen Standard-Softwareprodukten (IBO Ablaufprofi, ARIS-Toolset, Adonis, TopEase usw.) wurde die Applikation «TopEase» 22 als zukünftiges Modellierungswerkzeug ausgewählt. TopEase verwaltet die Objekte der Architektur in einer Datenbank und generiert sämtliche Diagramme zur Laufzeit - dadurch sind die Modelle immer konsistent und aktuell. Nebst einer Modellierungsumgebung stellt TopEase auch einen HTML-Client für die Mitarbeiter im Unternehmen zur Verfügung - so können sämtliche berechtigten Mitarbeiter in Zukunft die Architektur «erleben». Weitere Beispiele von Präsentationsformen der IT-Architektur mit der Applikation AMF sind im Anhang C verfügbar Strategische Software-Produkte Die wesentlichen Eckpfeiler der ZKB-IT-Architektur aus Sicht der Software-Produkte bilden die Lieferanten SAP, Avaloq und Siebel/Oracle mit ihren Produkten. Abgeleitet von der Anforderung «Betreuung und Beratung aus einer Hand» wird den Kundenbetreuern der ZKB ein so genannter «Vertriebsdesktop» auf Basis von Siebel/Oracle zur Verfügung gestellt. In diesem Portal («ZKBconnect») finden sie sämtliche Informationen über ihre Kunden, welche sie für die Betreuung benötigen. Beratungsprozesse für Anlagen, Finanzierungen und die Produktwahl im Zahlungsverkehr können ebenfalls auf dem Vertriebsdesktop durchgeführt werden. Bild 11: Vertriebsdesktop «ZKBconnect» auf Basis von Siebel Das Portal auf Basis von Siebel besitzt Schnittstellen zu verschiedenen Umsystemen wie auch zu den strategischen Bestandesführungssystemen für Geld (SAP) und Wertschriften (Avaloq). 22 Siehe Produktbeschreibung [TopEase 2006] Gedruckt am Seite 23 von 95

24 Bild 12: Eckpfeiler der IT-Architektur aus Sicht der strategischen Produkte für die Kerngeschäfte 23 Die Produkte Siebel, SAP und Avaloq sind in der IT-Architektur stark verankert. Die strategischen Migrationsprojekte, welche die Kernbankenfunktionen für die Bestandesführung Geld und Wertschriften aktualisieren, sind teilweise bereits abgeschlossen (Wertschriften) oder weit fortgeschritten (Bestandesführung Geld). Ein ebenfalls wichtiges Feld der IT-Architektur ist der Block «Verschiedene andere IT-Services», in diesem Bereich sind zahlreiche Support-Prozesse verankert, welche heute durch unterschiedliche Produkte und Lieferanten unterstützt werden: Dokumenten-Management Internes Reporting Kundenreporting Pricing und Billing Finanzinformationen In diesen wesentlichen Support-Prozessen muss Klarheit über die strategischen Produkte und Partner geschaffen werden. Die heutige Komplexität ist zu reduzieren und die Kosten der Support-Prozesse sind mittelfristig zu senken, die vorhandene Produkt- bzw. Plattform-Strategie ist zu erweitern und die Produkte sind zu konsolidieren. 5.3 Organisationsberatung Der Bereich der Organisationsberatung ist wie die Fachführung der BTO und die Informatik in der GE Logistik angesiedelt. Dieser Fachbereich unterstützt auf Anfrage andere Bereiche bei der Konzeption und Durchführung von Veränderungen («Change Management»), beispielsweise bei der Anpassung von Prozessen oder bei der Einführung neuer Produkte 24. In diesem Kontext werden jeweils die Geschäftsprozesse der Bereiche aufgenommen und im Softwaretool «IBO Ablaufprofi» dokumentiert. Die Prozesslandkarte, welche auch in der Organisationsberatung der Einordnung der Geschäftsprozesse dient, wurde in den letzten Jahren kontinuierlich aufgebaut, sie weicht von der Prozesslandkarte der IT-Organisation ab (siehe , Modell der ZKB) Eigene modellhafte Darstellung mit den strategischen Produkten für den Vertrieb und die Bestandesführungssysteme. Siehe auch 4.4, Geschäftsprozesse Gedruckt am Seite 24 von 95

25 Bild 13: Prozesslandkarte der Organisationsberatung 25 Durch verschiedene Aufträge der Fachbereiche sind in den letzten Jahren eigenständige Dokumentationen entstanden. Die Dokumentationen sind sehr detailliert beschrieben und darauf ausgelegt, als Arbeitsanweisungen verwendet werden zu können. 5.4 Produktmanagement Komponentenbasiertes Produktmanagements Im Rahmen des Kostenoptimierungsprogramms «FOKUS» wurde 2001 der Begriff «Komponentenbasiertes Produktmanagement» lanciert. Das Projektteam von FOKUS war der Auffassung, die Produktentwicklung finde nicht systematisch statt und weise Verbesserungspotenziale auf. Das Produktmanagement bei Zeno Bauer (Bereich PP) wurde beauftragt, eine Konkretisierung dieser Idee und deren Umsetzbarkeit zu überprüfen und vor allem, deren Nutzen für das Produktmanagement aufzuzeigen. Aus Sicht ZKB wird die Produktkomponente wie folgt definiert: Ein Prozess erbringt klar definierte Leistungen (Leistung A, Leistung B usw.) Das Produkt (Beispiel Produkt XY) setzt sich aus Leistungen zusammen und stellt ein Leistungsbündel dar Leistungen sind Produktkomponenten bzw. die Produkte sind Leistungsbündel Produkte lassen sich zu einem individuellen Produktangebot kombinieren Die Nutzung der Produkte wird in einem Vertrag mit dem Kunden geregelt 25 Darstellung der ZKB-Prozesslandkarte der Organisationsberatung, Auszug aus der IBO-Prozessdokumentation Gedruckt am Seite 25 von 95

26 Bild 14: Zusammenhang der Begriffe Funktion, Prozessschritt, Leistung, Leistungsbündel und Produkt 26 Bei Umsetzung des Konzeptes ist im Zusammenhang mit der neuartigen Produktentwicklung der gesamte Produktmanagementprozess davon betroffen, inklusiv Überwachung und Überarbeitung bestehender Produkte und Leistungen. Die Kernaufgaben des komponentenbasierten Produktmanagements sind somit wie folgt dargestellt: die Produktentwicklung die Komponentenentwicklung die Pflege bestehender Leistungen und Prozesse Das Konzept des komponentenbasierten Produktmanagements umfasst aus Sicht des Produktmanagements unter anderem eine Arbeitsoberfläche für die Produktentwicklung und Produktverbesserung, welche aufzeigt, welche Leistungen in welchen Produkten verwendet werden. Mit diesem Hilfsmittel lassen sich sowohl Vertriebskanäle und Kundensegmente abbilden. Damit ist die Basis für verschiedenste Auswertungen und Reports sowie auch für eine Produktrechnung gelegt. Das Konzept des komponentenbasierten Produktmanagements wurde Mitte 2003 ausgearbeitet und verabschiedet. Eine Produktarchitektur bzw. ein Komponentenmodell, welche die Umsetzung des Konzepts ermöglicht, wurde bisher nicht erarbeitet Organisation des Produktmanagements Das Produktmanagement der ZKB ist grundsätzlich nach den bankfachlichen Themen der Kerngeschäfte Immobilien- und Finanzierungsgeschäft, Anlagen, Handel und Kapitalmarkt und Geldverkehr aufgebaut. Durch die dynamische Marktentwicklung im Anlage- und Handelsgeschäft sind die Produktmanagement-Aktivitäten heute über verschiedene Organisationsbereiche verteilt. 26 Grafik aus dem ZKB-Konzept «Komponentenbasiertes Produktmanagement» Gedruckt am Seite 26 von 95

27 Bild 15: Organisationsbereiche, welche neue Produkte für definierte Kundensegmente erstellen 27 Die Fachführung für Produktmanagement wird aus der Geschäftseinheit Privatkunden und Investment- und Private Banking (je nach Kerngeschäft) vorgenommen. Für definierte Kundensegmente wie etwa externe Vermögensverwalter werden Dienstleistungen direkt durch den Bereich Firmenkunden- Beratung konzipiert und am Markt angeboten. 5.5 Unternehmensentwicklung Die Unternehmensentwicklung (Bereich VSE) verantwortet die strategische Planung und Steuerung der Bank und prüft im Auftrag des CEO mittels Business Analysen Chancen und Risiken von Akquisitionen oder Kooperationen auf strategischer Ebene. Die Unternehmensentwicklung verfügt über kein eigenes Modell der Bank, sie referenziert bei verschiedenen Analysen, die als Entscheidungsgrundlagen erarbeitet werden, auf Modelle der einzelnen Geschäftsbereiche. Der Prozess für die strategische Planung und das Controlling wird von der Unternehmensentwicklung verantwortet und gesteuert. Die wesentlichen Eckpunkte des Prozesses sind wie folgt definiert: Bild 16: Der «Fahrplan» des Prozesses strategische Planung und Controlling in einem Jahreszyklus Der Start des Prozesses erfolgt auf der Ebene der Strategie im Januar mit der Lagebeurteilung und der Validierung der Strategie der Gesamtbank (GB-Strategie) sowie der Balanced Scorecard (BSC), 27 Vereinfachte Darstellung der ZKB-Organisation im Produktmanagement, erstellt auf Basis des «org.managers» im ZKB Intranet Gedruckt am Seite 27 von 95

28 parallel dazu werden die Kundensegments-Strategien überprüft und die entsprechenden SWOT- Analysen und BSC's 28 aktualisiert. In einem dritten Schritt sind die funktionalen Strategien (Risiko, Eigenmittel, HR, IT usw.) zu überprüfen und die strategischen Vorhaben zu definieren. Die Ebene der Planung beginnt im Juli mit der Grobplanung der Gesamtbank (Erträge, Kosten und Risiken), daraus werden die IT-Jahresplanung und die Jahresplanung angestossen, diese werden in den Zielvereinbarungen (MbO) operationalisiert. 5.6 Risikosteuerung Das zentrale IT-Controlling (Bereich ZCI) hat im Verlauf des Jahres 2004 die Aufgabe übernommen, ein Rahmenwerk für die Identifikation und das Management der operationellen Risiken nach Basel II aufzubauen. Die operationellen Risiken wurden in Basel II wie folgt definiert: Die Gefahr von Verlusten, die in Folge der Unangemessenheit oder des Versagens von internen Verfahren, Menschen und Systemen oder in Folge von externen Ereignissen eintreten. Diese Definition schliesst Rechtsrisiken ein, beinhaltet aber nicht strategische Risiken oder Reputationsrisiken 29. Das Rahmenwerk wird in Projektform im Projekt «OpEx/Risk» entwickelt. Das Rahmenwerk aus diesem Projekt bildet die Basis für die Erreichung von Operational Excellence und das Management der operationellen Risiken. Nach Definition des CEO der ZKB ist das Management der operationellen Risiken untrennbar mit Operational Excellence verbunden. Die Erreichung von Operational Excellence fordert durchgängige Vertriebs-/ Verarbeitungs- und Beschaffungsprozesse. Im Projekt OpEx/Risk wurden für die beiden Disziplinen Operational Excellence und das Management der operationellen Risiken folgende Definitionen entwickelt: Operational Excellence Wir sind operational excellent, wenn wir die Leistungserwartungen unserer Kunden bezüglich P (Preis), I (Inhalt) und E (Emotion) auf kosten- und risikooptimale Art und Weise erfüllen. Operational Risk Die Leistungserstellung ist mit operationellen Risiken verbunden, das heisst Ereignisse wie Ausfall, Fehler oder Fehlverhalten der Leistungsträger gefährden unsere Leistungen und damit unsere Unternehmensziele und -strategien. Um das Rahmenwerk auf Praxistauglichkeit zu prüfen wurden bereits zwei so genannte «Proof of Concepts» (PoC) durchgeführt. Ein erstes «PoC» war auf den Umfang der Prozess-Dokumentation fokussiert, dabei wurde der Finanzierungsprozess aus gesamtbanklicher Sicht mit allen beteiligten Personen, Rollen, Bereichen und Systemen sowie den Leistungen dokumentiert. Das zweite PoC hatte zum Ziel, eine dynamische Vernetzung der Disziplinen Prozesse (inkl. Personen, Rollen usw.) und Systeme zu prüfen. Dazu wurden die Prozess- und System-Dokumentationen sowie Personal- Informationen für ein geschäftskritisches System und deren Umsysteme in der Modellierungsapplikation «TopEase» verknüpft. Die Angaben wurden erweitert um die Konfigurations-Management- Datenbank (CMDB), welche technische Informationen zu den Client- und Server-Systemen liefert. Die Die ZKB nutzt die «Balanced Scorecard» als Planungs- und Reporting-Instrument für die Strategie-Umsetzung Definition gemäss Dokumentation des Basler Ausschusses für Bankenaufsicht [BIS2006a] Gedruckt am Seite 28 von 95

29 Bewirtschaftung der CMDB ist in die Prozesse für die IT-Infrastruktur (basierend auf ITIL) eingebunden und dadurch laufend aktuell. Innerhalb der Applikation TopEase ist es durch die vielen Vernetzungen für den Endanwender (Bankmitarbeiter) nun möglich, durch die Architektur zu «surfen» und von einem Begriff oder Thema zum anderen zu springen. Das Kernstück des Rahmenwerks von OpRisk ist ein Informationsmodell mit drei Ebenen, welches die Prozessketten mit Leistungen «vom Kunden/zum Kunden» beinhaltet: Legende: Bild 17: Informationsmodell aus OpEx/Risk mit drei Ebenen Für die Dokumentation dieses Rahmenwerks werden die Leistungen gegenüber Kunden, die Geschäftsprozesse und die dazu notwendigen Ressourcen in Form von Menschen, Systemen, Material, Gebäuden, Räumen usw. dokumentiert. Beide PoC's (Bereich Leistung/Prozesse und Bereich Vernetzung Leistung/Prozess/Systeme/Rollen) waren erfolgreich, die Fachbereiche haben die Methoden und die Ergebnisse begrüsst. Der Risiko- Steuerungsausschuss (RSA) unter Leitung von Dr. Hans F. Vögeli hat deshalb im August 2006 das Projekt OpRisk beauftragt, das Rahmenwerk weiter auszuarbeiten und TopEase als Standard- Modellierungswerkzeug bestätigt. 5.7 Bewertung der Situationsanalyse In der ZKB werden in verschiedenen Geschäftsbereichen Modelle über das Unternehmen, die Produkte und Leistungen, die Applikationen, Funktionen oder Prozesse entwickelt und gepflegt. Die Modelle werden weitgehend unabhängig voneinander weiterentwickelt, haben aber mit den Kundensegmentsund den funktionalen Strategien des Unternehmens alle eine einheitliche und verbindliche Basis. Gedruckt am Seite 29 von 95

30 Wird nun beispielsweise eine neue Marktleistungen - wie das Investitionsgüterleasing für Firmenkunden 30 - eingeführt, so muss diese in den Modellen (IT-Architektur, Prozess-Management, OpEx/Risk usw.) einzeln eingearbeitet werden. Ein ganzheitliches Modell im Sinne einer Unternehmensarchitektur, das verschiedene Sichten - je nach Fragestellung oder dem Zielpublikum entsprechend - zulässt, existiert nicht. Den Entscheidungsträgern im Management werden dadurch verschiedene Modelle als Entscheidungsgrundlagen geliefert, welche unterschiedliche Methoden, Begriffe, Bezeichnungen, Granularität usw. aufweisen Stärken- / Schwächen-Analyse Die folgende Stärken- / Schwächen-Analyse bewertet die Ergebnisse aus der Situationsanalyse in einer internen Sicht. Stärken ST1 Modell der IT-Architektur deckt wesentliche Dimensionen ab ST2 In einzelnen Themenbereiche der IT-Architektur wurden umfassende Dokumentationen erarbeitet ST3 In verschiedenen Disziplinen sind unterschiedliche Modelle möglich, was eine unabhängige Analysen und Weiterentwicklung ermöglicht. ST4 Unterschiedliche Sichten auf das Unternehmen oder auf Teilbereiche sind möglich ST5 Die Lernfähigkeit der Organisation ist vorhanden, in den letzten Jahren wurden die Strategieentwicklungsprozesse laufend weiterentwickelt Schwächen SW1 Die ZKB verfügt aktuell über kein einheitliches Modell und Verzeichnis ihrer Geschäftsprozesse. Daraus ergeben sich Inkonsistenzen durch verschiedene Modelle und Vokabulare SW2 Mehrere Organisationseinheiten befassen sich mit ähnlichen und verwandten Aufgaben, die Bereiche sind aber ungenügend vernetzt, eine Verzettelung in Modellwelten und Methoden ist die Folge SW3 Der Aufwand durch die mehrfache Nachführung von Veränderungen im Unternehmen (Mitarbeiter, Organisation, Prozesse, Produkte, Applikationen usw.) ist hoch 31 SW4 Präsentationsform für Management-Ebene zuwenig attraktiv SW5 Ungenügende Vernetzung von IT-Architekturmanagement und Anforderungsmanagement SW6 Strategische Softwareprodukte für Supportprozesse noch lückenhaft SW7 Das Unternehmen verfügt für die interne Kostenverrechung über keine aktuelle und durchgängige Basis der Prozesskosten, sie kennt deshalb die Kosten bzw. Risiken ihrer Geschäftsprozesse nicht genau Das Investitionsgüterleasing wurde im Mai 2006 als eigenes Produkt lanciert, die Kooperation mit GE Lisca Leasing wurde aufgehoben. Annahme des Autors, der Aufwand wurde nicht vertieft analysiert oder quantifiziert Erkenntnis des Autors aus dem beruflichen Umfeld, eine explizite Anforderung zum Aufbau einer Prozesskosten-Rechnung besteht zur Zeit nicht Gedruckt am Seite 30 von 95

31 Im Rahmen dieser Diplomarbeit werden im Kontext der «Geschäftsorientierten IT-Architekturmanagements» nicht für alle im Rahmen der Situationsanalyse identifizierten Schwächen Lösungsvorschläge erarbeitet und im Vorschlag für das Umsetzungsprogramm eingeplant. Der Fokus liegt auf der Behebung der Schwächen SW1 bis SW5. Die Schwächen SW6 und SW7 werden im weiteren Verlauf der Arbeit nicht weiter berücksichtigt. Gedruckt am Seite 31 von 95

32 6 Ziel-Entwicklungsprozess 6.1 Ziele Erhöhung der Geschäftsorientierung Die Erhöhung der Geschäftsorientierung des IT-Architekturmanagements ist das primäre Thema dieser Diplomarbeit. Die Geschäftsorientierung wird in der Fachliteratur oft auch als «Alignment» oder gemeinsame Ausrichtung bezeichnet. 33 Darunter wird ein Alignment zwischen Business und IT verstanden, so dass die Unterstützung aller Unternehmensaktivitäten auf aktuellen und potenziellen Märkten optimal ist. Bild 18: Die drei Bereiche für Alignment zwischen Business und IT und einer Geschäftsorientierung der Architektur 34 Um die IT-Architektur geschäftsorientierter zu gestalten, ist in die gemeinsame Ausrichtung zwischen Geschäft und IT zu investieren 35 bzw. sind die heutigen Präsentationsformen und Abstimmungsprozesse zwischen Modellen und Vokabularen zu optimieren. Oftmals wird nicht die gleiche Sprache gesprochen, obwohl man zunächst das Gefühl hat, man habe sich verstanden (siehe 5.7.1, Stärken- / Schwächen-Analyse). Effektive Vernetzungs- und Präsentationsformen unterstützen die Erhöhung der Geschäftsorientierung entscheidend, die empfängergerechte Kommunikation ist ein Schlüsselfaktor für ein akzeptiertes und positiv verankertes IT-Architekturmanagement Strategisches Anforderungsmanagement Die Entwicklung der Architektur geschieht nicht willkürlich, sie ist getrieben von Anforderungen 36. Das bedeutet, dass die strategischen Anforderungen von der Geschäftsseite frühzeitig erfasst und analysiert werden müssen, um die Auswirkungen und die Abhängigkeiten dieser Anforderungen in der mittel- und langfristigen Weiterentwicklung der Architektur zu berücksichtigen. Strategie Prozesse Organisation Anforderungen Bild 19: Anforderungen aus Strategie, Prozesse und Organisation wirken auf die Architekur Siehe [Masak 2005a], Seite 10 Darstellung nach [Masak2005a] In diesem Kontext sind keine finanziellen Investitionen gemeint Siehe [Vogel 2005a], Seite 92 Gedruckt am Seite 32 von 95

33 Dadurch besitzt die Architektur den notwendigen Vorsprung zu laufenden Projekten und kann die Konstruktionsprinzipien und Rahmenbedingungen für Entwicklungen definieren anstelle sie nachzudokumentieren (siehe 5.2.1, Aufbau des IT-Architekturmanagements). Die frühzeitige Erfassung der Anforderungen fordert den Dialog zwischen dem Management auf der Geschäftsseite und dem IT-Architekturmanagement im Rahmen der Strategieentwicklung und Umsetzungsplanung. Der Einsatz von Mitarbeitern, welche die Sprache der Geschäftsseite sprechen und geeignete Organisationsformen unterstützen diesen Prozess positiv Entwicklung eines IT-Architektur-Führungsmodells Die effektivere Entwicklung und Durchsetzung der IT-Architektur im IT-Architekturmanagement erfordert ein Führungsmodell, welches die gemeinsame Ausrichtung der IT-Architektur auf das Geschäft optimal unterstützt. Die Diplomarbeit schlägt ein Führungsmodell vor, das Organisationselemente für die Durchführung des IT-Architekturmanagements sowie entsprechende Führungsprozesse beinhaltet. 6.2 Zusammenfassung der Ziele Die fachlichen und inhaltlichen Ziele dieser Diplomarbeit sind zusammenfassend wie folgt definiert und gewichtet: Definiertes Ziel Referenz zur Gewichtung Stärken/Schwächen- Analyse Erhöhung der Geschäftsorientierung SW1, SW3, SW4 50 % Aufbau eines strategischen Anforderungsmanagements SW5 20 % Vorschlag eines Führungsmodells für das IT- SW2 30 % Architekturmanagement Tabelle 3: Die Ziele der Diplomarbeit und ihre Gewichtung. Die Entwicklung von Lösungen zu den bisher dokumentierten Schwachstellen und den hier gesetzten Zielen ist im nächsten Kapitel beschrieben. Gedruckt am Seite 33 von 95

34 7 Lösungsentwicklung 7.1 Definition Architektur und Architekturmanagement Die Definition einer Architektur nach ANSI/IEEE-Standard lautet wie folgt: Eine Architektur beschreibt die grundlegende Organisation eines Systems, dargestellt in den einzelnen Bestandteilen mit der Vernetzung untereinander und den Prinzipien für die Konstruktion und die Entwicklung. 37 In dieser Definition ist unter dem Begriff «System» kein (einzelnes) IT-System zu betrachten. Das System kann durchaus ein vollständiges Unternehmen oder eine unternehmensübergreifende Wertschöpfungskette umfassen. Die Architektur als Objekt besitzt also primär einen beschreibenden Charakter zur Strukturen in einem Unternehmen. Das Architekturmanagement stellt den Führungsprozess dar, der für den Unterhalt, die Weiterentwicklung, die Kommunikation und damit auch für die Akzeptanz und Durchsetzung der Architektur angewendet wird. 7.2 Definition der Geschäftsorientierung Im Rahmen der Interviews hat der Autor die Thematik der Geschäftsorientierung diskutiert. Die Erwartungshaltung bezüglich Umfang und Nutzen der Architektur ist breit gefächert, dennoch wurden einige Aussagen der Interview-Partner immer wieder genannt, so dass eine Signifikanz feststellbar war. Basierend auf dieser Signifikanz wurde die folgende Definition zur Geschäftsorientierung entwickelt: Das Architekturmanagement ist dann geschäftsorientiert, wenn es die wesentlichen Führungsbereiche eines Unternehmens miteinander in Beziehung setzt in die wesentlichen Führungsprozesse des Unternehmens eingebunden ist relevante und aktuelle Führungsinformationen frühzeitig und verständlich liefert einen nachhaltigen Nutzen stiftet Kontrollierte Entwicklung Ein wesentlicher Auftrag des IT-Architekturmanagement ist (bereits heute) die Einhaltung des «Prinzips der kontrollierten Entwicklung». Beitrag zur Effizienz Treiber: Engineering Betriebssicherheit anzustrebende Enwicklung Treiber: Fachanforderungen Time To Market Beitrag zur Effektivität Bild 20: Prinzip der kontrollierten Entwicklung, die IT-Architektur sorgt für Definition und Einhaltung von Leitplanken Siehe IEEE-Standard-Dokumente auf der Website der [IEEE 2006a] Eigene Definition der Geschäftsorientierung ZKB-interne Darstellung der anzustrebenden Entwicklung der IT-Architektur von Daniel Voser Gedruckt am Seite 34 von 95

35 Diese Kontrolle der Entwicklung verhindert, dass die IT-Architektur der ZKB sich einerseits nicht zu stark in Richtung des «Over-Engineering» verbunden mit einer absoluten Betriebssicherheit, andererseits auch nicht zu stark nur nach Fachanforderungen und «Time to Market» entwickelt. Um diese Kontrolle zu wahren, werden Entwicklungsvorgaben durch die Fachstellen der IT-Architektur geprüft und von diesen zur Umsetzung freigegeben. Die Einhaltung des Prinzips der kontrollierten Entwicklung stellt einen wesentlichen Beitrag zur Umsetzung der IT-Strategie im Spannungsfeld von Effizienz und Effektivität dar Nutzen für das Alignment Der Nutzen aus den zu schaffenden Beziehungen zwischen den Führungsbereichen kann anhand folgender Fragestellungen untermauert werden: 40 Geschäftsführung Weisen die IT-Investitionen eine Parallele zur Entwicklung der Erträge in den Kerngeschäften aus? Welches Deckungsbeitragsvolumen wird von welchem Prozess bzw. welcher Applikation beeinflusst? Welche Geschäftsrisiken entstehen, wenn wir die IT-Kosten kontinuierlich um 10% pro Jahr senken? Welchen Einfluss hat eine Akquisition im Kerngeschäft Anlage- und Vermögensverwaltung auf unsere IT-Applikationen? Strategisches Sourcing Welche Auswirkungen hat das Insourcing eines Mandanten auf die Logistik/Produktion? Wie flexibel sind die Schnittstellen bei Prozessen und Applikationen für alternative Sourcing- Szenarien? IT-Architektur Welche Prozesse werden für die Leistungserstellung gegenüber Kunden verwendet? Welche Leistungen bzw. Produkte basieren auf welchen Applikationen? Wie viele Schnittstellen sind zur Abwicklung des Geschäftsprozesses Z notwendig? Welche Kundendaten werden in welchen Applikationen als Lead-Daten geführt und warum? Service-Management Sind die Service-Levels der Applikation A und der Applikation B mit dem von den Kunden erwarteten Service-Level des Geschäftsprozesses Z abgestimmt? Ist die Rollenstruktur des Geschäftsprozesses Z korrekt in der Berechtigungsstruktur der Applikationen A und B abgebildet? Sind die Verfügbarkeitsanforderungen in den SLA's mit den Prioritäten der Marktleistungen abgestimmt? 40 In Anlehnung an [Winter2006a] Gedruckt am Seite 35 von 95

36 7.2.3 Optimierung der Vernetzung Für ein Unternehmen in der Grösse und Komplexität der ZKB ergibt sich auf Basis der Definition im Abschnitt 7.2, Definition der Geschäftsorientierung und der möglichen offenen Fragestellungen (7.2.2, Nutzen für das Alignment) eine wesentliche Konklusion: Die heutigen Analyse- und Entwicklungs-Disziplinen IT-Architekturmanagement, IT-Portfoliomanagement, Produktmanagement, Operationelle Risiken und die Organisationsberatung in den verschiedenen Geschäftsbereichen müssen in einer Unternehmensarchitektur 41 vernetzt werden. Eine Unternehmensarchitektur bringt Transparenz, zeigt Abhängigkeiten und Wirkungen, hilft zu erkennen, wie Strategien, Ziele, Produkte, Geschäftsprozesse, Applikationen, Plattformen und Infrastruktur miteinander verwoben sind 42. In der Fachliteratur spricht man von einer Unternehmensarchitektur, wenn die Summe aller Architekturen einer Organisation betrachtet wird. Eine Unternehmensarchitektur beinhaltet im wesentlichen folgende Elemente: 43 Bild 21: Bereiche einer Unternehmensarchitektur auf oberster Ebene nach [Niemann 2005] 7.3 Beschreibung und Bewertung von Architekturmodellen Für den Aufbau einer Unternehmensarchitektur bietet es sich an, anstelle eigener Architektur-Modelle ein bereits vorhandenes umfassendes Modell zu verwenden, das prinzipiell lösungsneutral 44 eingesetzt werden kann. Auf dem Markt sind verschiedene Modelle und Rahmenwerke für Unternehmensarchitekturen verfügbar, welche auf entsprechenden Internet-Seiten (siehe Anhang A bzw. Anhang B) ausführlich dokumentiert sind Wird in der englischen Fachliteratur als «Enterprise Architecture» bezeichnet Vergleiche [Niemann 2005], Seite 72 Vergleiche [Niemann 2005], Seite 77 Mit «lösungsneutral» ist gemeint, dass keine feste Verknüpfung zwischen Architekturmodell und einem Software-Tool besteht. Gedruckt am Seite 36 von 95

37 7.3.1 Beschreibung von Architekturmodellen In der Lösungsentwicklung dieser Diplomarbeit wird nun das heute in der ZKB verwendete Modell der IT-Architektur mit drei ausgewählten Referenz-Modellen verglichen. Als Referenz-Modelle wurden dabei gewählt TOGAF der Open Group Zachman-Framework der ZIFA-Foundation Motion-Modell von Microsoft Weitere öffentlich zugängliche und dokumentierte Modelle sind kurz in Anhang B dieser Arbeit beschrieben Modell der ZKB Das IT-Architektur-Modell der ZKB ist eine Eigenentwicklung, das Modell wurde durch mehrere Entwicklungsschritte aus verschiedenen Teilmodellen zusammengefügt. Folgenden Teilmodelle sind aktuell Bestandteil der IT-Architektur: Prozesse Funktionen Applikationen Daten Technologien Das Modell stellt die Geschäftsprozesse ins Zentrum, lässt jedoch eine definierte Sichtweise auf jedes andere Teilmodell zu. Die Bezeichnungen und Begriffe im Modell-Inhalt sind abgestimmt auf die in der ZKB üblichen Begriffe, wobei zu beachten ist, dass diese Begriffe von der BTO als Teil der IT- Organisation geprägt sind. Bild 22: Das Architektur-Modell der ZKB Prozesse Die heutige IT-Architektur beinhaltet eine Prozesslandkarte inkl. entsprechender Beschreibung der Makroprozesse. Gedruckt am Seite 37 von 95

38 Bild 23: Prozesslandkarte aus der Applikations-Architektur der IT-Organisation Die Kernprozesse der ZKB sind fokussiert auf die Leistungen gegenüber den Kunden im Vertrieb, sie beinhalten hauptsächlich die Akquisition, Kundenbetreuung, Kundenberatung und die Geschäftsverwaltung. Applikationen Die Applikations-Architektur wird in so genannten AAR-Vertiefungen suksessive aufgebaut. Für jeden Prozessbereich aus der Prozesslandkarte («Kundenberatung Finanzierungen», «Zahlungsverkehr unbar» usw.) wird eine AAR-Vertiefung erarbeitet, diese beinhaltet die für die Prozessdurchführung notwendigen Applikationen und Services in einem Ist- und einem Soll-Zustand. Die effektive Planung und Durchführung dieser Veränderungen im Applikations-Portfolio erfolgt in den Prozessen der IT-Planung und des IT-Portfoliomanagement. Daten- und Funktionsmodell Um die Strategie «Buy before Make» auch in der Dimension der Daten optimal umsetzen zu können, verwendet die ZKB ein Referenz-Datenmodell mit der Bezeichnung «TOP100». Dieses Referenzmodell abstrahiert die sich verändernden Datenmodelle der Lieferanten (beispielsweise Siebel oder SAP) auf eine neutrale Ebene. Sämtliche Datenmodelle von eingekauften Applikationen müssen zu diesem Datenmodell referenziert werden, damit die vorhandenen Daten für das Unternehmen bekannt und auch anderen Applikationen zugänglich gemacht werden können. Technologiemanagement Das Modell des Technologiemanagements in der IT-Architektur positioniert die in den Applikationen und Services zu verwendeten Technologien in einem Reifegrad-Modell. Gedruckt am Seite 38 von 95

39 Bild 24: Reifegradmodell für das Technologiemanagement in der IT-Architektur der ZKB Das Reifegradmodell bildet den Lebenszyklus einer Technologie im Unternehmen ab. Dabei werden für wesentliche neue Positionierungen (beispielsweise von «Studieren/Analysieren» zu «Investieren/Nutzen») einer Technologie im Reifegradmodell bewusste Entscheidungsprozesse durchlaufen. Das Modell wird im Sinne eines Frühwarnsystems dazu eingesetzt, technologische Entwicklungen bezüglich Chancen und Risiken für die ZKB zu erkennen und die notwendigen Massnahmen bezüglich Skills, Ressourcen und damit Kompetenzen einzuleiten Modell der OpenGroup TOGAF Das «The Open Group Architecture Framework» (TOGAF) 45 stellt einen umfassenden Ansatz für den Entwurf, Planung, Implementierung, Unterhalt und die Weiterentwicklung einer Unternehmensarchitektur dar. Das Architektur-Modell der OpenGroup ist typischerweise in die vier Domänen aufgeteilt: Geschäftsebene Daten Anwendung Technologie Architektur-Entwicklung mit der Architecture Development Method Das Kernstück von TOGAF stellt die sehr detaillierte Methode zur Architekturentwicklung («Architecture Development Method», ADM) dar. Die Methode kann auf die Bedürfnisse der jeweiligen Organisation zugeschnitten und dann bei der Durchführung der Architekturentwicklungsaktivitäten eingesetzt werden. Da TOGAF die Architektur-Arbeit als kontinuierlichen Prozess versteht, besitzt die Methode zur Architektur-Entwicklung eine entsprechend hohe Bedeutung. Die ADM in TOGAF umfasst folgenden Elemente: 45 Siehe Online-Dokumentation auf der Website von [TOGAF 2006a] Gedruckt am Seite 39 von 95

40 Bild 25: Architektur-Entwicklungs-Zyklus nach TOGAF ADM Die Architektur-Entwicklungsmethode von TOGAF stellt das Anforderungsmanagement ins Zentrum des Architektur-Geschehens. Im gesamten Entwicklungs-Zyklus der Unternehmensarchitektur werden folgende Architekturteile entwickelt: Vorbereitungsphase Architektur-Vision Geschäfts-Architektur Informationssystem-Architektur Technologie-Architektur Lösungs-Varianten Bebauungsplanung für die Migration Führungsmodell für die Implementierung Prozess für das Änderungswesen der Architektur Vorbereitungsphase Die Vorbereitungsphase ist ein wichtiges Element des Zyklus. In diesem Schritt werden die wesentlichen Prinzipien der folgenden Architektur-Arbeit festgelegt. Die wesentlichen Ziele dieser Phase sind: Abholen des Commitments der Mitwirkenden und der Stakeholder Definition der Rahmenbedingungen wie Organisation, Verantwortungen, Kompetenzen, Dokumentationsform usw. Festlegung des Umfanges und der Methode zur Entwicklung der Architektur (üblicherweise als Anpassung der ADM) Festlegung eines Pilot-Projektes, um die spätere Praxistauglichkeit sicherzustellen Definition von Kriterien und Auswahl von Architektur-Management-Werkzeuge (falls diese noch nicht vorhanden) Gedruckt am Seite 40 von 95

41 Wird diese Vorbereitungsphase umfassend durchlaufen, so ist für die folgende Architektur-Arbeit ein wichtiger Grundstein gelegt. In den folgenden Abschnitten werden die Bereiche Architektur-Vision und Business-Architektur aus der ADM beschrieben. Architektur-Vision Die Architektur-Vision beschreibt den Umfang der Architektur und grenzt diesen auch zum Umfeld ab, zudem wird auch festgehalten, mit welchen Rahmenbedingungen die Vision erarbeitet wird/wurde. Die Zielsetzungen dieser Phase aus der ADM sind: Sicherstellung der Unterstützung durch die Geschäftsleitung und das Linien-Management Diskussion der Prinzipien des Geschäftsmodells, Geschäftsziele, strategische Geschäftstreiber und Einflussfaktoren um ein gemeinsames Basis-Verständnis zu schaffen Festlegung des Umfangs der Architektur-Basis sowie Identifikation und Priorisierung des Umfanges der einzelnen Komponenten Aufstellung der relevanten Stakeholder mit deren Zielen und möglichen Vorbehalten Identifikation der elementaren Geschäftsanforderungen und Rahmenbedingungen die im Lauf der Architektur-Arbeit adressiert/einbezogen werden müssen Skizze des Lieferobjektes Architektur-Vision, welches auf die Geschäftsanforderungen und Rahmenbedingungen eine Antwort liefert Festlegung des Review- und Abnahme-Prozesses Aufzeigen des Verständnisses, wie anderen, parallel vorangetriebenen Unternehmensarchitektur- Entwicklungen umgegangen wird 46 Geschäfts-Architektur Die Anforderungen von der Geschäftsseite sind ein wesentliches Element der weiteren Architektur- Arbeit. Aus diesem Grund wird bereits in der Phase B Business Architecture von TOGAF die Geschäfts-Architektur konkretisiert. Die Ziele dieser TOGAF-Phase lauten wie folgt: Beschreibung des Ist-Zustandes als Ausgangslage Beschreibung der Ziel-Architektur des Geschäftsmodells inkl. Produkt- und Dienstleistungs- Portfolio auf strategischer Ebene, basierend auf den Ergebnissen der Architektur-Vision Analyse der Differenzen zwischen Ist-Zustand und Ziel-Architektur Identifikation der relevanten Sichtweisen und Ansichten, welche es den Architekten ermöglichen aufzuzeigen, wie auf Vorbehalte eine Antwort geliefert wird Auswahl der relevanten Werkzeuge und Techniken, um diesen Sichtweisen und Ansichten Rechnung zu tragen Die Arbeiten und Ergebnisse dieser Phase sind für den Erfolg im Aufbau der Unternehmensarchitektur zentral. Denn in dieser Phase werden verschiedenste Bereiche des Unternehmens mit teilweise bereits bestehenden Objekten (Produktkatalog, Geschäftsfeld-Strategie usw.) in die Architektur-Arbeit einbezogen. Gelingt der so genannte «Buy-In» dieser Stakeholder nicht, so ist die Akzeptanz der Unternehmensarchitektur gefährdet. 46 Beispielsweise ein Strategie-Entwicklungsprozess eines bestimmten Geschäftsfeldes Gedruckt am Seite 41 von 95

42 Um den Einbezug der Stakeholder strukturiert zu gestalten stellt die ADM von TOGAF eine Vorgehensweise zur Verfügung, mit welcher so genannte Geschäftsszenarien beschrieben werden können. Die Geschäftsszenarien umfassen dabei: Geschäftsprozesse und notwendige Hilfsmittel Umfeld aus den Sichtweisen Geschäft und Technologie Personen und Rollen Erwartete Ergebnisse Diese Geschäftsszenarien werden dabei schrittweise mit Architekten und Vertretern der Geschäftsseite erarbeitet: Begonnen wird mit der Diskussion des Problems bzw. der Herausforderung und des Umfelds sowie der Ziele. Daraus folgt die Identifikation der menschlichen und systemtechnischen Akteure mit den Rollen und Verantwortlichkeiten sowie den Ergebnissen des Geschäftsszenarios in der Abstimmungsphase. Als Abschluss der jeweiligen Geschäftsszenazenario-Entwicklung wird eine Überprüfung als Rückkoppelung und Qualitätssicherung durchgeführt. Bild 26: Entwicklung eines Geschäftsszenarios zur Erhebung von Anforderungen 47 Für die Beschreibung der Geschäftsszenarien empfiehlt die ADM die Verwendung existierender Methoden wie beispielsweise Use Case-Modelle aus der UML. Sind in der Architektur die Geschäftsszenarien beschrieben, so ist die Basis für die Entwicklung der Informationssystem-Architektur gelegt. Informationssystem-Architektur In der Phase C wird die Ziel-Architektur der Architektur-Domänen Daten und Applikationen entwickelt. Dabei ist darauf zu achten, dass die Geschäftsszenarien für sämtliche IT-unterstützten Geschäftsprozesse und Schnittstellen aus Phase B vorhanden sind 48. Zu beachten ist, dass bei der Domäne Daten nicht ein logisches oder physisches Datenmodell entstehen soll, vielmehr geht es darum, die relevanten Daten-Entitäten für das Unternehmen zu identifizieren. Domäne Applikations-Architektur ein Inventar der Ziel-Applikationen mit folgenden Informationen erarbeitet werden soll: Name der Applikation Verantwortlicher für Betrieb Verantwortlicher für Geschäfts- und Anforderungs-Seite Benutzerkreis / -gruppe Applikationszweck Status der Applikation (in Betrieb, in Planung, in Ablösung) Unterstützte Geschäftsfunktionen Eigene Darstellung, basierend auf TOGAF-Dokumentation [TOGAF 2006a] Der Umfang ist abhängig vom in der Vorbereitungsphase definierten Architektur-Projektumfang Gedruckt am Seite 42 von 95

43 Unterstützte Geschäftsbereiche Hardware- und Software-Plattformen Netzwerk-Ressourcen Notwendige Umsysteme Mit diesen Informationen besteht bereits eine gute Übersicht über die im Unternehmen vorhanden Applikationen und ihren Status. Technologie-Architektur In dieser Phase der Architektur-Entwicklung werden die relevanten Ziel-Technologien definiert. Diese Informationen sind auch für das strategische Skills- und Ressourcenmanagement einer IT- Dienstleisters relevant. Bei einer gewählten «Buy before Make»-Strategie (wie in der ZKB) wird die Technologie-Architektur teilweise von den Lieferanten der Produkte getrieben. Das Hauptziel dieser Phase ist die Weiterentwicklung von einer reinen Technologie-Beschreibung in den Produkten zu einer service-orientierten Beschreibung. Vorhandene Applikationen sollen bezüglich Wiederverwendungs-Potenzial (beispielsweise durch Auftrennung in einzelne Services) überprüft werde. Lösungs-Varianten In dieser Phase werden die verschiedenen Lösungs-Varianten zur Umsetzung der Ziel-Architektur diskutiert und beschrieben. In dieser Phase wird auch geprüft welche Komponenten eingekauft und welche selbst gebaut werden können/sollen (beispielsweise Komponenten mit sensitiven Berechnungsfunktionen im Kerngeschäft). Zudem werden in diesem Schritt auch die strategischen Parameter für die Umsetzung der Ziel- Architektur festgelegt, darunter sind inhaltliche, zeitliche und finanzielle Vorgaben zu verstehen. Auf dieser Basis gilt es verschiedene Arbeitspakete auf Top-Level oder Projekte zu schnüren, welche das Aufsetzen eines Migrations-Programms ermöglichen. Dabei sind funktionale, terminliche und finanzielle Rahmenbedingungen (Kosten/Nutzen) sowie die Abhängigkeiten der Projekte zu analysieren. Bebauungsplanung für die Migration Der Bebauungsplan stellt das Kernstück der Migrationsplanung dar und ist ein wichtiges Kommunikations-Instrument. Dieser Plan bringt die einzelnen Projekte des Programms in eine sinnvolle Reihenfolge, welche mit den Stakeholdern aus Sicht Geschäftsanforderungen, Risiken, Finanzen und Terminen besprochen werden muss. Bild 27: Muster eines Bebauungsplanes für ein Migrations-Programms zur Umsetzung einer Ziel-Architektur Eigene modellhafte Darstellung mit voneinander abhängigen Projekten, die Projekte sind gebündelt zu einem Programm, welches eine strategische Zielerreichung unterstützt. Gedruckt am Seite 43 von 95

44 Bei der Priorisierung der Projekte ist auf die Abhängigkeiten untereinander und zum Umfeld zu achten. Die Entwicklung von Zwischenlösungen und Provisorien ist möglichst zu vermeiden. Führungsmodell für die Implementierung In dieser Phase findet die eigentliche Stabsübergabe der Architektur-Arbeit an die Umsetzungs- Verantwortlichen statt. TOGAF empfiehlt diese Stabsübergabe mit einem so genannten Architecture- Contract zu untermauern. Das Rollenmodell (Auftraggeber, Auftragnehmer, Programm-Manager, Projektleiter usw.) für die Implementierungsphase ist in diesem Vertrag festzuhalten. Auch das Steuerungsgremium und die Rapportierungslinien sind transparent aufzuzeigen. Dabei ist darauf zu achten, dass sich die Governance möglichst an bereits bestehenden Modellen orientiert, dies erleichtert die Kommunikation und fördert die Akzeptanz. Weiterhin sind für sämtliche Projekte, welche im Rahmen des Programms umgesetzt werden müssen, mindestens folgende Daten zu dokumentieren: Projekt-Name Projekt-Beschreibung und -Umfang Projekt-Ziele Lieferobjekte in Phasen und beim Projektabschluss Rahmenbedingungen und Abhängigkeiten Messkriterien für die Fortschrittskontrolle Abnahme-Kriterien Risiken Mit Unterzeichnung dieses Vertrags übernimmt die Umsetzungs-Organisation die Verantwortung, die Projekte erfolgreich ins Ziel zu bringen. Prozess für das Änderungswesen der Architektur In dieser letzten Phase geht es darum, einen Change Management-Prozess für das Änderungswesen der Architektur zu verankern. Dieser Prozess ist notwendig um notwendige Veränderungen während der Umsetzung der Ziel-Architektur (seien diese von Seite Technologie oder Geschäft) kontrolliert durchzuführen. Veränderungen können ausgelöst werden durch: Neue Technologien, welche einen Nutzen stiften Technologien die abgekündigt werden Standardisierungs-Initiativen Innovation von neuen Produkten Erweiterung des Marktgebietes Neue Auflagen des Regulators Hinweis: Die ausführlichen Beschreibungen zu den einzelnen Entwicklungsphasen der ADM sind auf der TOGAF-Website der Opengroup 50 in englischer Sprache verfügbar Unternehmensarchitektur als Enterprise Continuum Das Rahmenwerk TOGAF stellt ein so genanntes «Enterprise Continuum» mit zwei Hauptbereichen «Architecture Continuum» und «Solutions Continuum» zur Verfügung. Das Enterprise Continuum stellt 50 Ausführliche Dokumentation der OpenGroup unter [TOGAF 2006a] Gedruckt am Seite 44 von 95

45 in TOGAF eine wichtige Unterstützung für die Kommunikation und das Verständnis der Architektur sowohl im Unternehmen wie auch über Unternehmensgrenzen hinweg dar. Zudem ist das Enterprise Continuum aufgrund der Vernetzung auch für Wiederverwendung von Architektur-Komponenten geeignet. Architecture Continuum In diesem Bereich sind so genannte Architecture Building Blocks (ABB) vorhanden, die über das «Architecture Continuum» in einem gemeinsamen Kontext gestellt werden, die Ebenen oder Elemente beeinflussen sich dabei gegenseitig. Das Architecture Continuum illustriert wie Architekturen auf einer definierten Basis mit Unterstützung der ADM kontinuierlich entwickelt werden. Die Entwicklung führt dabei von den Basis-Architekturen (Foundation Architectures) über die allgemeinen System- Architekturen, die industriespezifischen Standards zu einer individuellen Unternehmensarchitektur. Bild 28: Das Enterprise Continuum von TOGAF, mit Architecture Continuum und Solutions Continuum Das Kontinuum stellt keinen formalen Prozess von links nach rechts dar (siehe Pfeile), vielmehr symbolisiert das Kontinuum, einen zeitlichen Verlauf mit Rückkopplungen und Abhängigkeiten. Die Entwicklung geschieht dabei auf verschiedenen Stufen: logische Ebene physische Ebene horizontal (IT-fokussiert) vertikal (geschäftsorientiert) Generalisierung Spezialisierung Im Architecture Continuum signalisieren die bidirektionalen Pfeile die Beziehung zwischen den verschiedenen Architektur-Bausteinen (ABBs). Die einzelnen ABBs beschreiben Anforderungen des Unternehmens, welche aufgrund der Geschäftsstrategie und des operativen Geschäftsbetriebs vorhanden sind. Beispielsweise werden das Thema E-Commerce und Supply-Chain-Management im ABB «Common Systems Architectures» definiert. Dabei ist zu beachten, dass der Detaillierungsgrad der Architekturbeschreibung von links nach rechts ansteigend ist. So kann im Beispiel für E-Commerce bei einer Bank-Architektur im ABB «Industry Architectures» kein neuer Prozess für SWIFT- Gedruckt am Seite 45 von 95

46 Datenaustausch 51 implementiert werden, wenn nicht zuvor im ABB Common System Architectures grundsätzlich eine E-Commerce-Infrastruktur definiert wurde. Die vier ABBs im Architecture Continuum illustrieren, wie breit gefächert, die Architekturtypen und - Fragstellungen sind, welche im Verlauf der kontinuierlichen Architektur-Entwicklung geklärt werden müssen. Für das Architektur-Kontinuum zentral sind die Foundation Architectures. Dieser ABB beinhaltet ein technisches Referenzmodell (TRM) mit einem Modell und einer einheitliche Taxonomie 52 sowie eine so genannte «Standards Information Base» (SIB). Die SIB stellt eine Dokumentation von Standards zur Verfügung, welche für die Definition der Services und Komponenten angewendet werden kann. Bild 29: Das technische Referenzmodell im Architektur-Kontinuum von TOGAF. Darunter sind im Bereich der Infrastructure Applications beispielsweise wie Services -Client, Kalenderdienste, Workflow-Komponenten, Tabellenkalkulation, Präsentationssoftware, Textverarbeitung usw. gemeint. Die Business Applications stellen spezifische Anwendungen des jeweiligen Unternehmens dar. Solutions Continuum Das Solutions Continuum repräsentiert die Implementation der Architekturen auf den entsprechenden Stufen im Architektur-Kontinuum. Auf jeder Stufe entstehen so nach und nach die Bausteine, die (gekaufte oder entwickelte Bestandteile) die eine Lösung für Anforderungen des Unternehmens darstellen. Ein entwickeltes Lösungs-Kontinuum kann somit als inventarisierte und öffentlich zugängliche Bibiliothek von wieder verwendbaren Lösungs-Komponenten angesehen werden. Die einzelnen Komponenten stellen für das Unternehmen einen wichtigen Wert (auch als «Asset» bezeichnet) dar. Es ist deshalb notwendig, die Architektur in einem entsprechenden Managementprozess zu unterhalten und so das Asset Management sicherzustellen. Die einzelnen ABBs beinhalten: SWIFT ist die Abkürzung für «Society for Worldwide Interbank Financial Telecommunication». Es handelt sich dabei um eine 1973 gegründete, internationale Genossenschaft der Banken, die ein Telekommunikationsnetz (SWIFT-Netz) für den Nachrichtenaustausch unterhält. Die einheitliche Taxonomie stellt sicher dass die Architektur bezüglich der verwendeten Fachbegriffe konsistent entwickelt wird. Gedruckt am Seite 46 von 95

47 Products and Services Leistungen des Unternehmens in Form von Dienstleistungen (Beratung, Schulung usw.), Hardware, Software usw. Systems Solutions Ein definiertes Bündel von Produkten oder Dienstleistungen, die zu einer Lösung geschnürt werden. Eine solche Lösung wird durch die «Common Systems Architecture» unterstützt53. Die Lösungen aus dem ABB «Systems Solution» repräsentieren den höchsten gemeinsamen Nenner für eine oder mehrere Lösungen im Industriezweig - beispielsweise skalierbare Datawarehouse- Lösungen oder hochverfügbare und hochvolumige Transaktionsverarbeitung für Finanzdienstleistungen. Industry Solutions Eine «Industry Solution» stellt eine konkrete Implementierung einer «Industry Architecture» dar. Der ABB Industry Architecture definiert dabei die Rahmenbedingungen für die Industry Solution, die welche wieder verwendbare Komponenten eines Industriezweigens beinhaltet. Die könnte beispielsweise eine für verschiedene Partner wieder verwendbare Schnittstelle für B2B-Prozesse sein. Organization Solutions Eine «Organization solution» umfasst eine Implementation einer Unternehmensarchitektur, welche die notwendigen Geschäftsfunktionen zur Verfügung stellt. Der Hauptgrund für die Vernetzung des Architecture Continuum mit dem Solutions Continuum ist der durchgängige Aufbau einer Unternehmensarchitektur auf Basis der Industry Solutions, Systems Solutions und der Products and Services. Der Entwicklungsprozess wird durch Architekten geführt Modell des Zachman-Framework Das Zachman-Framework wurde von John A. Zachman 1987 als Framework für Enterprise Architecture oder Unternehmensarchitektur entworfen und publiziert. John A. Zachman war über 20 Jahre für IBM tätig, er hat das Unternehmen 1990 verlassen und sich vollständig dem Gebiet der Unternehmensarchitektur zugewandt. Heute führt er das ZIFA, «The Zachman Institute for Framework Advancement». Als das Framework publiziert wurde fand es nur geringe Beachtung, da die Mainframes die wesentlichen Funktionen für Unternehmen bereitstellten und die Architekturen somit weitgehend gefestigt waren. Das Modell des Zachman-Frameworks ist als Matrix aufgebaut, einerseits werden in den Spalten, die Dimensionen aufgeführt, andererseits stellen die Zeilen des Rahmenwerks definierte Perspektiven für bestimmte Zielgruppen dar Siehe Wechselwirkung zwischen Common Systems Architecture (Architecture Continuum) und Systems Solutions (Solutions Continuum) Siehe [Grässle 2006], Abschnitt 9.2 Gedruckt am Seite 47 von 95

48 Was / Daten Wie / Funktionen Wo / Orte Wer / Personen Wann / Ereignisse Warum / Treiber Abgrenzung [Planer] Unternehmens modell [Fachver-antwortl icher] Fachliches System-Modell [Analyst] Dimensionen Technisches System-Modell [Designer] System- Komponenten [Implementierer] Perspektiven Laufendes Unternehmen [Mitarbeiter, Partner und Kunden] Bild 30: Das Zachman-Framework bietet unterschiedliche Dimensionen und definierte Perspektiven Die Struktur des Modells umfasst 6x6-Zellen, werden alle 36 Zellen bzw. Teilarchitekturen bewirtschaftet, ergibt sich eine sehr umfassende Sicht auf ein Unternehmen. Das Zachman-Framework ermöglicht Sichten, welche für die ganzheitliche Betrachtung heutiger komplexer Unternehmen notwendig sind. Bild 31: Das Zachman-Framework für Unternehmens-Architekturen Das Management nutzt Sichten im Bereich der Geschäftsarchitektur für die Führung des Unternehmens und die IT für die Entwicklung der Applikationen, Business und IT können dadurch miteinander in Beziehung gebracht werden. Gedruckt am Seite 48 von 95

49 Die folgende Tabelle beschreibt die einzelnen Bereiche des Modells beispielhaft: Was / Daten Wie / Funktionen Wo / Orte Wer / Personen Wann / Ereignisse Warum / Treiber Abgrenzung [Planer] Objekte, die relevant sind Aufgaben, welche relevant sind (Kerngeschäfte usw.) Orte, in denen das Geschäft abgewickelt wird Personen und Strukturen, welche relevant sind Ereignisse, die relevant sind Ziele und Einflüsse, die relevant sind Unternehmensmodell [Fachverantwortlicher] Beziehungsmodell der Daten, Fakten Geschäftsprozessmodell Geschäftsgeographie (Wirtschaftsräume, Rohstoffe usw.) Organisati- ons- Diagramme (Linie, Matrix, Rollen, Skills usw.) Planungs-, Steuerungsund Abrechnungs-Zyklen Business Plan zur Strategie- Umsetzung Fachliches System-Modell [Analyst] Logisches Datenmodell Applikationsarchitektur Aufbau verteilter Systeme Aufbau der Benutzer- Schnittstellen (Rollen, Rechte, Daten) Ereignisse und Abhängigkeiten im System Modell für Geschäftsregeln Technisches System-Modell [Designer] Physisches Datenmodell System- Design System- Architektur (Hardware, Software- Typen usw.) Benutzerschnittstelle (Verhalten, Sicherheitsvorgaben) Steuerungs- Diagramme Geschäftsregel-Design System- Komponenten [Implementierer] Daten- Definition Applikationen und Services Netzwerk- Architektur Masken, Menüs, Steuerungselemente Ablauf- Steuerung Regeln- Definition Programm- Logik in Laufendes Unternehmen [Mitarbeiter, Partner und Kunden] Effektive Daten (Kunden, Produkte, Transaktionen usw.) Ausführbare Applikationen und Services Laufende Kommunikati- ons- Einrichtungen Arbeitende Personen definierten Rollen in Aktuelle und mittelfristige Unterneh- mens- Planung Geschäftsstrategie Umsetzung in Tabelle 4: Beispielhafte Aufstellung der Elemente aus dem Zachman-Framework, übersetzt in die deutsche Sprache Die Abgrenzung im Zachman-Rahmenwerk ist wichtig, da diese erste Zeile beschreibt, was effektiv der Inhalt der Architektur ist. Das Rahmenwerk kann aufgrund seines Umfanges «skalierbar» eingesetzt werden, das Arbeitsfeld in der Abgrenzung definiert den Betrachtungsgegenstand. Es kann also beispielsweise nur ein Bereich eines Unternehmens (ein Kerngeschäft oder eine Geschäftseinheit) als Objekt gewählt werden, um das Rahmenwerk inhaltlich zu erarbeiten. Folgende sieben Regeln wurden für die Erarbeitung und Interpretation des Zachman-Rahmenwerks definiert: Regel 1: Die Spalten haben keine feste Reihenfolge, sie sind bezüglich Wichtigkeit alle gleich gestellt. Regel 2: Jede Spalte repräsentiert ein eindeutiges Modell Regel 3: Jede Spalte ist eindeutig, dennoch sind sie untereinander verbunden Regel 4: Jede Zeile stellt eine eindeutige Perspektive dar Regel 5: Jede Zelle ist eindeutig, kein Objekt sollte in mehr als einer Zelle vorkommen Regel 6: Jede Zeile stellt ein komplettes Modell für die Perspektive der Zeile dar Regel 7: Die Logik ist rekursiv und generisch Hinweis: Das Zachman-Rahmenwerk selbst ist keine Architektur und beinhaltet auch keine Methode. Es stellt aber einen vollständigen Ordnungsrahmen für den Aufbau einer Unternehmensarchitektur zur Verfügung. Gedruckt am Seite 49 von 95

50 Modell von Microsoft Das Unternehmen Microsoft bietet in seiner Geschäftssparte («Microsoft Business & Industry») auch Beratungsdienstleistungen an. Die Unternehmensberater haben die Wichtigkeit und das Potenzial der Thematik Unternehmensarchitektur erkannt und selbst ein Rahmenwerk entwickelt. Microsoft nennt das Modell «Motion». Aus Sicht Microsoft sind Prozessmodelle aufgrund der häufigen Änderungen 55 als Basis für Unternehmensarchitekturen ungeeignet, darum hat Microsoft einen anderen Weg eingeschlagen. Motion basiert dabei auf einem neuen Modell des Unternehmens, einer so genannten «Business Capability Map». Diese Business Capabilities sind Fähigkeiten oder Funktionen, auf die sich das Unternehmen stützt, um seine Geschäftsziele zu erreichen. Dabei betrachtet man nicht «Wie» eine Funktion implementiert ist, sondern vielmehr, «Was» im Geschäft in Bezug auf Menschen, Prozesse und IT passiert. Damit wird eine umfassende und stabile Sicht auf das Unternehmen erreicht, was wiederum die Entwicklung und Nachführung einer stabileren Unternehmensarchitektur unterstützt. Im Gegensatz zu einem statischen Modell ist Motion eine Vorgehensweise, die sowohl das Unternehmen, dessen «Key Performance Indicators» und dessen Geschäftpartner betrachtet und auf Basis einer «Business Capabililty Map» Handlungsoptionen sowohl in den Prozessen als auch in der Unternehmensarchitektur aufzeigt. Bild 32: Die Business Capability-Map aus dem Motion-Framework von Microsoft 56 Das Motion-Modell ist nicht durch die Unternehmensgrenzen eingeschränkt. Es ist ein Modell, das stark auf Zusammenarbeit von Unternehmen ausgerichtet ist, also auf kollaborative Leistungserstellung durch mehrere Firmen innerhalb einer Wertschöpfungskette. Dabei stehen immer die Fähigkeiten/Funktionen der einzelnen Leistungserbringer im Zentrum. Die so genannte Anatomie einer Capability (Beschreibung einer Fähigkeit) besteht nach Microsoft aus drei Elementen: aus Personen, Prozessen und einer Plattform. Die Business Capability-Map ist in mehrere Ebenen aufgeteilt, die Grafik zeigt die Übersicht auf der Ebene 1, welche als «Grundlegende Funktionalitäten» bezeichnet wird. Die drei Ebenen sind wie folgt unterteilt: Nach Definition von Microsoft sind Prozessmodelle vor allem auf den unteren Ebenen (Ablauf-Diagramme) häufigen Änderungen unterworfen. Eigene Übersetzung aus dem englischen Motion-Framework nach [Microsoft 2006a] Gedruckt am Seite 50 von 95

51 Bild 33: Die drei Ebenen der Business Capability Map Werden die Ebenen weiter aufgegliedert so beinhaltet beispielsweise «2. Nachfrage erzeugen» auf der Ebene der Funktionalitätsgruppen: 2. Nachfrage erzeugen 2.1 Kundenbeziehungsmanagement 2.2 Marketing 2.3 Verkauf Da bei diesem Modell bewusst die Fähigkeiten oder Funktionen des Unternehmens und nicht die Prozesse im Zentrum stehen, ist ein direkter Vergleich dieser beiden Dimensionen sinnvoll: Kriterium Prozessmodell Business Capability Map Umfang Eine Instanz von Aktivitäten innerhalb einer Fähigkeit/Funktion Liefert ein Verständnis welche Fähigkeiten/Funktionen wann, wie, wo und wofür benötigt werden Inhalt Wie eine Leistung erstellt wird Welche Leistungen erbringt welchen Wertbeitrag? Stabilität Prozesse sind nicht stabil, früher Fähigkeiten/Funktionen, ausgerichtet auf oder später ändern viele Elemente von Prozessen den Markt und den Kunden, sie bleiben über lange Zeit stabil Vernetzung Verflechtungen, Beziehungen und Verflechtungen, Beziehungen und Abhängigkeiten Abhängigkeiten zwischen den Prozessen zwischen den Fähigkei- werden dargestellt ten/funktionen werden dargestellt Granularität Detaillierte Gliederung von Einzelschritten Kapselung von Funktionen in Bausteinen, Funktionsbeschreibung in Dienstverträgen Tabelle 5: Vergleich Prozessmodell und Business Capability Map aus dem Motion-Modell Die Vorgehensweise von Motion ist darauf ausgerichtet, zu verstehen, welches die Fähigkeiten oder Funktionen eines Unternehmens und seines Umfeldes sind. Diese können durch Motion quantifiziert und mit den relevanten Prozessen verknüpft werden. Die Vorgehensweise nach «Motion» umfasst also primär eine andere Optik bzw. einen anderen Weg, die Prozesse sind auch in Motion eine elementare Information (siehe Anatomie eine Capability). Die Vorgehensweise nach Motion und der Einsatz einer Business Capability Map können im Kontext einer Service Orientierten Architektur (SOA) von Vorteil sein, da die Business Capability Map auf einzelne, notwendige Funktionen ausgerichtet ist, welche gekapselt sind. Aus der dritten Ebene der Business Capability Map (betriebswirtschaftliche Funktionen) können die einzelnen Services einer SOA abgeleitet werden. Zusammenfassend beinhaltet Microsoft Motion zwei wichtige Elemente: Gedruckt am Seite 51 von 95

52 Business Capability Map als Grundlage Die Projektschritte in der Vorgehensmethode von Motion zielen darauf ab, eine bestimmte Aufgabenstellung zu lösen oder Ansatzpunkte für Verbesserungen zu identifizieren. Kern der Methode ist die Erstellung und Bewertung der Business Capability Map. Werkzeuge und Metriken Verschiedene Werkzeuge (auf Basis von Excel) unterstützen dabei, Schlüsselmetriken und andere Daten mit den Capabilities zu verknüpfen. Dadurch kann die Performanceverbesserung einer Capability quantifiziert werden. Microsoft hat im Jahr 2004 mehrere Patentanträge zum Schutz der Methode Motion eingereicht. Bild 34: Phasenmodell eines Motion-Projekts mit vier Phasen, drei Gates und so genannten Off-Ramps für den Abbruch Die Methode selbst wurde Ende der 1990er-Jahre entwickelt und schon mehrfach Microsoft-intern angewendet - beispielsweise wenn es um den Kauf eines Unternehmens ging. Die Business Capability Map hilft in diesem Kontext fehlende Fähigkeiten auf einer sogenannten «Heat-Map» darzustellen. Die Heat-Map ist mit einer Landkarte der Fähigkeiten vergleichbar, Schwachstellen werden «heiss» (rot) eingefärbt. Aus der Heat-Map kann das erforderliche Projektportfolio für die Behebung von Schwachstellen gebildet werden Bewertung der Architekturmodelle Die in den vorhergehenden Abschnitten beschriebenen Architektur-Modelle (ZKB, TOGAF, Zachman und Microsoft Motion) werden nach verschiedenen Kriterien mit der Methodik der Nutzwertanalyse verglichen Nutzwertanalyse Die Kriterien für den Vergleich sind wie folgt definiert: Geschäftsorientierung: Ist das Modell umfassend geeignet als Informationsbasis für eine Unternehmensarchitektur? Anerkannter Standard: Handelt es sich beim Modell um einen anerkannten Standard? Verschiedene Perspektiven: Lässt das Modell verschiedene Perspektiven für die Stakeholder zu? 57 Die Bewertung wurde durch den Autor selbständig durchgeführt und stellt somit eine persönliche Ansicht dar. Gedruckt am Seite 52 von 95

53 Methodik für Entwicklung: Ist eine Methodik für die Architektur-Entwicklung vorhanden und beschrieben? Strukturiertheit: Ist das Modell übersichtlich strukturiert? Verständlichkeit: Sind die vorhandenen Dokumentationen verständlich? Aufwand Der Aufwand für die Umsetzung/Einführung ist in einem sinnvollen Rahmen Die Kriterien wurden gewichtet, so dass den Kriterien Geschäftsorientierung, anerkannter Standard und verschiedene Perspektiven entsprechend Bedeutung zukommt. Tabelle 6: Nutzwertanalyse für den Vergleich der Architektur-Modelle Die vorgenommene Bewertung der einzelnen Kriterien wird im folgenden Abschnitt in Worten kommentiert und begründet Kommentar zur Bewertung ZKB IT-Architektur Das Modell der ZKB erfüllt die Kriterien praktisch in alle Bereichen teilweise. In der Strukturiertheit erfüllt das Modell die Anforderungen. Geschäftsorientierung: Bezüglich der Geschäftsorientierung fehlen dem Modell jedoch wichtige Elemente wie beispielsweise die Zeitachse (Zachman: Wann) oder die Motivatoren (Zachman: Warum). Anerkannter Standard: Das ZKB-Modell stellt keinen anerkannten Standard dar, es ist eine Eigenentwicklung, basierend auf verschiedenen Referenzmodellen. Verschiedene Perspektiven: Die Perspektiven des ZKB-Modells sind nicht auf Stakeholder im Sinne von Rollen zugeschnitten, sie basieren auf Perspektiven in den einzelnen Domänen (Applikationen, Prozesse, Daten usw.) Methodik für Entwicklung: Eine Methodik für die Entwicklung der Architektur ist aktuell nicht offiziell dokumentiert, die Prozesse sind erarbeitet, aber noch nicht in Kraft gesetzt. Gedruckt am Seite 53 von 95

54 Strukturiertheit: Die Strukturiertheit des Modells ist gut, die Domänen sind mit verschiedenen Referenzmodellen vergleichbar Aufwand für Implementierung: Der Aufwand für die Implementierung hält sich in einem sinnvollen Rahmen, das Ergebnis ist aber auf die IT-Architektur beschränkt Verständlichkeit: Bezüglich Verständlichkeit ergibt sich ein grösseres Entwicklungspotenzial. Insbesondere die Fachbegriffswelt der IT-Architektur sollte sich gegenüber dem Bankgeschäft vermehrt öffnen. TOGAF - The OpenGroup Das Modell der OpenGroup besticht vor allem durch seine Methodik, die Architecture Development Method, ADM. Geschäftsorientierung: Die einzelnen ABBs von TOGAF im Architektur-Kontinuum wie auch im Lösungs-Kontinuum sind nur teilweise genügend für eine Unternehmensarchitektur. Wie beim ZKB-Modell fehlen auch bei TOGAF die Rollen, die Zeitachse und die Ziele. TOGAF ADM stellt jedoch die Anforderungen des Geschäftes ins Zentrum der Architektur-Entwicklung. Eine «Architecture Governance» ist grundsätzlich beschrieben, es fehlen jedoch klare Rollenprofile. Anerkannter Standard: TOGAF ist ein anerkannter Standard der OpenGroup, welche weltweit Akzeptanz für offene Standards im Bereich der Software-Entwicklung geniesst. Verschiedene Perspektiven: Die Perspektiven sind primär unterteilt in zwei Bereiche: Architektur und Lösung, beides wird als Kontinuum 58 verstanden. Perspektiven für die Stakeholder sind nicht vorhanden. Methodik für Entwicklung: Die ADM stellt das Herzstück von TOGAF dar. Jeder Schritt der Entwicklungs-Methode ist sehr ausführlich beschrieben. Strukturiertheit: Die Methodik wiederum ist sehr gut aufgebaut. Für die einzelnen ABBs ist die Dokumentation mehrheitlich gut strukturiert, die Struktur des Gesamtmodells wirkt aber noch nicht sehr übersichtlich: Es kann an jedem Objekt im Kontinuum gearbeitet werden, die Einflüsse auf andere Objekte sind durch Abhängigkeitsanalysen entsprechend nachzuvollziehen. Aufwand für Implementierung: Der Aufwand für die Implementierung ist bezüglich Umfang ist auch bei TOGAF nicht zu unterschätzen, aus Sicht der vorhandenen Methode und der Durchgängigkeiten der Beschreibungen aber ganz klar in einem sinnvollen Aufwand/Nutzen-Verhältnis. Verständlichkeit: Die Verständlichkeit der Dokumentation ist gut, die Beziehungen und Wechselwirkungen zwischen den einzelnen ABBs sollten besser herausgearbeitet werden. 58 Ein Kontinuum nach TOGAF ist ein «vollständiges Objekt» welches keine Risse oder Brüche, Löcher oder Hohlräume aufweist Gedruckt am Seite 54 von 95

55 Microsoft Motion Das Modell von Microsoft liefert so genannte Business Capability Maps, die Vorgehensweise dazu heisst Motion. Es handelt sich dabei um eine relativ neue Entwicklung, welche insbesondere in Europa bzw. der Schweiz noch nicht sehr bekannt ist. Geschäftsorientierung: Die Geschäftsorientierung ist sehr hoch, da Motion sich auf die Fähigkeiten eines Unternehmens fokussiert. Anerkannter Standard: Motion ist in Europa erst wenig bekannt, die Entwicklung zum Beratungsunternehmen im Bereich Unternehmensarchitektur bei Microsoft ist noch jung. Verschiedene Perspektiven: Die Business Capability Maps unterstützen verschiedene Perspektiven nur bedingt. Das Modell kann in drei verschiedenen Ebenen vertieft werden, die Sichtweise ist aber primär auf die betriebswirtschaftlichen Funktionen beschränkt. Methodik für Entwicklung: Die Methodik ist gut aufgebaut und präsentiert sich attraktiv. Verschiedene Fallstudien mit Musterdokumenten sind auf dem Web öffentlich zugänglich und erleichtern den Zugang zur Methode. Strukturiertheit: Die Methode und das Modell sind gut strukturiert, es müssen verschiedene klare Entscheidungspunkte (so genannte «Gates») durchlaufen werden. Aufwand für Implementierung: Der Aufwand für die Implementierung ist bei Microsoft Motion hoch, die Erarbeitung der Business Capability Map und die Bewertung der Fähigkeiten und Funktionen sind je nach Unternehmenskultur sehr aufwändig. 59 Verständlichkeit: Die Verständlichkeit der Beschreibungen ist gut, auf technische Details wird weitgehend verzichtet. Die Übersetzungen in die deutsche Sprache sind noch lückenhaft (starke Verwendung von Anglizismen). Zachman Framework Das Rahmenwerk nach Zachman ist der Standard für Unternehmensarchitekturen. Dementsprechend sind zahlreiche Dokumentationen (auch von Drittanbietern) verfügbar. Was dem Modell fehlt, ist eine beschriebene Methodik, um die Architektur zu entwickeln und zu unterhalten. Geschäftsorientierung: Das Modell ist vollständig und kann skalierbar für einzelne Projekte, Kerngeschäfte oder ganze Unternehmen eingesetzt werden. Anerkannter Standard: Es handelt sich um den bekanntesten Standard für ein Rahmenwerk. Verschiedene Perspektiven: Unterschiedliche Perspektiven sind für verschiedene Rollen in den Zeilen und für die Modelle in den Spalten der Matrix vorhanden. 59 Es sei denn, ein CFO erarbeitet und bewertet die Business Capability Map selbständig mit den Beratern von Microsoft, was nicht unbedingt zur Akzeptanz beiträgt. Gedruckt am Seite 55 von 95

56 Methodik für Entwicklung: Eine Methodik ist nicht öffentlich verfügbar, verschiedene Beratungshäuser bieten entsprechende Unterstützung an. Strukturiertheit: Das Rahmenwerk ist stark strukturiert, die Matrix mit 36 Feldern grenzt die einzelnen Objekte klar voneinander ab. Aufwand für Implementierung: Bei Zachman ergibt sich bezüglich Umfang ein recht hoher Aufwand - analog TOGAF, durch die klare Strukturiertheit wird dieser bei Nutzung einer geeigneten Methode aber vertretbar ausfallen. Verständlichkeit: Die Verständlichkeit der Dokumentationen ist gut. Insbesondere durch die hohe Akzeptanz im Markt finden sich ansprechende Beschreibungen von Dritt-Herstellern Entscheidung für Architekturmodell Auf Basis der gewonnenen Erkenntnisse aus den Modell-Beschreibungen und der Ergebnisse aus der Nutzwertanalyse wird für die Lösungsentwicklung folgender Entscheid für das Architekturmodell und die Methode getroffen. Als Referenzmodell für die Unternehmensarchitektur wird das Zachman-Framework empfohlen. Als Methode für die Erarbeitung der Unternehmensarchitektur wird die Architecture Development Method (ADM) aus dem TOGAF-Framework empfohlen. Als Werkzeug für die Modellierung wird vorgeschlagen, weiterhin TopEase zu verwenden. Die Entscheidung bezüglich Methode zwischen Microsoft Motion und TOGAF ADM fällt zu Gunsten von TOGAF aus, weil TOGAF bereits ein anerkannter Standard ist und bezüglich Methodik über sehr gute Dokumentationen verfügt. Weiterhin stellt TOGAF die Anforderungen des Geschäfts (Requirements) in den Mittelpunkt der Architektur-Entwicklung. 7.4 Massnahmen zur Erhöhung der Geschäftsorientierung Nebst dem Aufbau und der Anwendung einer Unternehmensarchitektur sind für die Erhöhung der Geschäftsorientierung des IT-Architekturmanagements weitere flankierende Massnahmen notwendig. Wesentliche Schlüsselfaktoren sind die Vernetzung von Führungsbereiches sowie die Integration des IT-Architekturmanagements in die wesentlichen Führungsprozesse. Die Massnahmen zur Erhöhung der Geschäftsorientierung auf Basis der im Abschnitt 7.2, Definition der Geschäftsorientierung vorgenommenen Definition werden nachfolgend beschrieben. Das Architekturmanagement ist dann geschäftsorientiert, wenn es die wesentlichen Führungsbereiche eines Unternehmens miteinander in Beziehung setzt in die wesentlichen Führungsprozesse des Unternehmens eingebunden ist relevante und aktuelle Führungsinformationen frühzeitig und verständlich liefert einen nachhaltigen Nutzen stiftet Eigene Definition der Geschäftsorientierung Gedruckt am Seite 56 von 95

57 7.4.1 Vernetzung der wesentlichen Führungsbereiche Die Vernetzung der wesentlichen Führungsbereiche im Zachman-Framework wird mit konkreten Beispielen der ZKB durchgeführt, dabei werden Führungsbereiche und -prozesse der ZKB strukturiert in die Matrix eingeordnet, die dokumentierte Zusammenstellung ist nicht abschliessend. 61 Abgrenzung [Planer] Unternehmensmodell [Fachverantwortlicher] Was / Daten Wie / Funktionen Wo / Orte Wer / Personen Wann / Ereignisse Geschäftsmodell Universalbank Kundenbedürfnisse: zahlen, anlegen/sparen und finanzieren usw. Vision Finanzdienstleister Marke persönlich, kompetent, verantwortungsvoll Ganze Schweiz Marktgebiete Firmenkunden Marktgebiete Privatkunden Geschäftseinheiten Vertrieb Verarbeitung Banksteuerung Dachkampagne Kundensegmentskampagne Themenkampagnen Sponsoring Planungsprozess Warum / Treiber Gesamt- bank- Strategie Kunden- segments- Strategien Funktionale Strategien (IT-Strategie usw.) Fachliches System-Modell [Analyst] Leistungen Produkte Kundensegmente Vertriebskanäle Prozess- Landkarte Makroprozesse Mikroprozesse (Ablaufdiagramme) Corporate Center Geschäfts- Lokalitäten Notfall- Arbeitplätze Rollen Organisation Abteilungen Berufsbilder Skills- Management Personal- Entwicklung Kontakt Bank Kunde, Kunde/Bank Beratungsgespräch Auftrag des Kunden SLA der Geschäftsprozesse Kundenzufriedenheit Mitarbeiterzufriedenheit Zielerreichung MbO Weisungen und Regeln, Anleitungen und Checklisten Technisches System-Modell [Designer] Aufträge und Bestände Transaktionsverarbeitung Vertriebska- nal- Integration Business Intelligence Applikations- Architektur (AAR) Service- Architektur Services zentral, dezentral Ausweich- Rechenzentren Verbindungen zu Lieferanten/ Partnern Vertriebsdesktop Verarbeitungssysteme Banksteuerungsssysteme Rechteverwaltung Bebauungspläne SLA der Applikationen Operating Level Agreements der Dienste Architekturvorgaben der SAR Implementierungskonzepte Betriebskonzepte System- Komponenten [Implementierer] Stammdaten Bewegungsdaten Klassifikation Technologien Betriebssysteme, Datenbanken Protokolle Service- Verzeichnis Mainframe Zentrale Server- Infrastruktur Netzwerk- Struktur für Produktion und Entwicklung SAP HR ADS/LDAP CMDB ACS Ablauf- Steuerung Mainframe Ablaufsteuerung dezentrale Systeme Ablaufsteuerung ADB Betriebshandbücher Fehlermeldungen von Systemen Problemtickets von Benutzern Laufendes Unternehmen [Mitarbeiter, Partner und Kunden] ZKBconnect Stammdaten-Service ADB, BRE, METRO WSA BFGeldBox Betreuungsund Beratungsversprechen BBV Geschäftshäuser Filialen Automatenstandorte OpenNet Management, Mitarbeiter Externe Mitarbeiter Lieferanten Partner End- Verarbeitung (MEV, QEV, JEV) Einführungsfenster Weisungen und Regelwerke Reporting und Massnahmen Tabelle 7: Das Zachman-Framework mit vernetzten Führungsbereichen der ZKB 61 Eine «Abgrenzung» ist nicht notwendig, da es diese Vernetzung auf oberster Ebene das ganze Unternehmen umfasst. Gedruckt am Seite 57 von 95

58 Die hier dokumentierte Zusammenstellung der vernetzten Führungsbereiche und -prozesse in den Perspektiven und Dimensionen des Zachman-Rahmenwerks erfordert eine gemeinsame Sichtweise auf die Synergien und Abhängigkeiten über alle Management-Ebenen, denn das verwendete Rahmenwerk liefert nicht «die Unternehmensarchitektur von der Stange» 62, die Verwendung des Rahmenwerks bringt Transparenz und reduziert «Ehrenrunden» für die Abstimmung von einzelnen Bereichen Aufbau der Vernetzung mit TOGAF ADM Wird der Inhalt des Rahmenwerks mit der standardisierte Methode ADM nach TOGAF erarbeitet, so wird der Prozess zur Entwicklung der Unternehmensarchitektur oder einzelner Bereiche daraus strukturiert durchgeführt. Der folgende Abschnitt beschreibt den Entwicklungsprozess auf Basis TOGAF ADM. Bild 35: Eigene Prozess-Darstellung für Aufbau der Unternehmensarchitektur nach TOGAF ADM TOGAF ADM für den Aufbau nach Zachman Die folgenden Abschnitte beschreiben den Aufbau einer Unternehmensarchitektur nach dem Rahmenwerk von Zachman mit der Methode von TOGAF ADM. Vorbereitungsphase Die Entwicklung einer Unternehmensarchitektur muss in Projektform durchgeführt werden, um möglichst viele Stakeholder in das entsprechende Projektteam einzubeziehen - dies nach dem Prinzip «Die Betroffenen zu Beteiligten machen» 64. Die Zielsetzungen der Initiierung der Unternehmensarchitektur sind wie folgt: Schaffen eines gemeinsamen Verständnisses zur «Unternehmensarchitektur» Definition der Rahmenbedingungen für den Aufbau der Unternehmensarchitektur: Projekt- Organisation, Rollen und Vertreter der Fachbereiche, Dokumentationsform Abholen des Commitments zur vernetzten Führungsarbeit über verschiedene Fachbereiche Elementarer Wissensaufbau über das Zachman-Framework Entwicklung einer ersten Landkarte des Zachman-Frameworks als Themenübersicht Dieser erste Schritt ist für den Aufbau elementar, er beinhaltet die Definition des Umfanges der Architektur und die breite Abstützung der Architektur-Aktivität. Die Aktivitäten dieser Phase entsprechen im Zachman-Rahmenwerk der Perspektive Abgrenzung. Architektur-Vision In dieser Phase wird die Grundlage für die Entwicklung der Geschäftsarchitektur gelegt. Die Prinzipien des Geschäftsmodells der Universalbank ZKB mit den jeweiligen Zielen, Strategien und Geschäfts Vergleiche [Niemann 2005], Seite 193 Originaldarstellung siehe Bild 26 Offizielle Quelle unbekannt, auch ein persönlicher Grundsatz des Autors Gedruckt am Seite 58 von 95

59 treibern werden diskutiert. In der Entwicklung der Architektur-Vision wird die erste Landkarte des Zachman-Rahmenwerks (Artefakt aus der Vorbreitungsphase) überprüft. Basierend auf der ersten Landkarte werden die relevanten Stakeholder identifiziert und deren möglichen Motivationen bzw. Vorbehalte aufgenommen. Die frühzeitige Auseinandersetzung mit diesen Aspekten ist für die Akzeptanz und den Fortschritt der Architekturarbeiten ein kritischer Erfolgsfaktor. Die Stakeholder werden in die Erarbeitungs-, Review- und Abnahmeprozesse eingebunden. Die Architektur-Vision umfasst inhaltlich die elementaren Geschäftsanforderungen im Unternehmensmodell. Die Ergebnisse dieser Phase entsprechen im Zachman-Rahmenwerk der Perspektive Unternehmensmodell. Geschäfts-Architektur Eine Geschäfts-Architektur ist eine «Kollektion von Plänen» 65 wie beispielsweise Strategien und Massnahmen oder Produkte und Leistungen gegenüber Kunden und Partnern. Diese Pläne sind im Unternehmen bereits vorhanden, aber noch wenig vernetzt. Somit sollte als Ausgangslage zunächst der Ist-Zustand des Unternehmens vernetzt aufgearbeitet werden. Ein weiterer Artefakt der Geschäfts-Architektur ist die Ziel-Architektur des Geschäftsmodells und die darauf folgende Abweichungs-Analyse des Ist-Zustands mit der Ziel-Architektur. Ein wesentliches Element der Geschäfts-Architektur bzw. des fachliche System-Modells sind die Geschäftsszenarien, sie liefern die Geschäftsprozesse und Hilfsmittel, die erforderlichen Rollen und Personen und die erwarteten Ergebnisse des Szenarios. Das Umfeld des Szenarios wird zusätzlich aus Sicht Geschäft und Technologie erarbeitet. Der detaillierte Erarbeitungsprozess der Geschäftsszenarien ist im Abschnitt beschrieben. In der ZKB sind Geschäftsszenarien aus Sicht der Leistungen gegenüber den Kunden zu erstellen, beispielsweise die Abwicklung eines Zahlungsauftrags Inland, die Erneuerung einer Hypothek oder die Beratungsleistung für die Nachfolgeregelung eines Unternehmens. In der Phase der Geschäfts-Architektur werden die wesentlichen Inhalte für das fachliche System- Modell aus dem Zachman-Framework erarbeitet. Informationssystem-Architektur Die Informationssystem-Architektur beinhaltet die Ziel-Architektur für die Daten und Applikationen. Sie definiert somit auch, welche Applikationen für welche Daten verantwortlich sind, diese Verantwortlichkeiten, müssen von den Geschäftsszenarien abgeleitet werden, entsprechende Daten-Entitäten sind zu definieren. In der Phase der Informationssystem-Architektur wird auch eine umfassende Beschreibung der Applikationen der Ziel-Architektur wie im Abschnitt aufgeführt erarbeitet. Noch nicht vorhandene Applikationen sind soweit möglich zu beschreiben. Die Hauptperson in dieser Phase nach Zachman ist der so genannte Designer. Er entwickelt in dieser Architektur den Verbund von Applikationen über das ganze Unternehmen, in der ZKB entspricht dies einer Architektur der Prozesse und Applikationen/Services mit den Schnittstellen aus der Sicht «vom 65 Siehe [Niemann 2005], Seite 87 Gedruckt am Seite 59 von 95

60 Kunden/zum Kunden». Als Präsentationsform eignet sich die im Abschnitt definierte vernetzte Präsentationsform pro Geschäftsszenario. Die Ergebnisse der Phase Informationssystem-Architektur entsprechen im Zachman-Rahmenwerk der Perspektive Technisches System-Modell. Technologie-Architektur Die Ziel-Architektur für die Applikationen, Services und Schnittstellen dient als wertvolle Basis für die Technologie-Architektur. Die Technologien sollten in diesem Kontext möglichst unabhängig von Produkten und Lieferanten betrachtet werden. Das bedeutet, dass nicht SAP oder Siebel eine Technologie darstellen, sondern die effektiv verwendeten Technologien wie relationale Datenbanken, verteilte Anwendungen, Web-Technologien usw. Die Technologie-Architektur aus der ADM entspricht der Perspektive der System-Komponenten im Zachman-Rahmenwerk. Die Technologie-Architektur ermöglicht es, die relevanten Daten, Applikationen, Services, Netzwerke, Benutzeroberflächen, Ablauf- oder Prozess-Steuerung und Regeln zu identifizieren. Ein wesentlicher Zusatznutzen stellt die Möglichkeit dar, auf Basis der Informationen aus dieser Perspektive das strategische Skills- und Ressourcenmanagement für die IT aufzubauen. Dieser Aspekt wird in der weiteren Arbeit nicht weiter vertieft, da er nicht primär zur Thematik der Geschäftsorientierung gehört Integration in die wesentlichen Führungsprozesse Um die Vernetzung von Führungsbereiche optimal zu unterstützen ist eine Integration des Gedankengutes einer Unternehmensarchitektur sowie der Verantwortlichkeiten in die wesentlichen Führungsprozesse und -strukturen notwendig. Die Entwicklungen im Unternehmen erfolgen bei konsequenter Nutzung einer Unternehmensarchitektur abgestimmter und kontrollierter. Das Führungsmodell einer Unternehmensarchitektur beinhaltet die fachliche Führung wie auch die Linienführung. Bei der Entwicklung eines Führungsmodells sind für verschiedene Themenbereiche besonders zu beachten, da sich diese teilweise gegenseitig beeinflussen. Strategische Themenbereiche für die Geschäftsleitung Geschäftliche Themenbereiche für das Management im Business IT-Themenbereiche für das Management in der IT Die Integration der Unternehmensarchitektur in die Führungsprozesse wird nun in einem konkreten Prozess weiter vertieft. Für die konsequentere Strategie-Umsetzung hat sich in der ZKB bei IT-Projekten die Methodik des Programm-Managements bewährt. Unter Programm-Management wird aktuell das Zusammenfassen von verschiedenen IT-Projekten verstanden, welche ein strategisches Ziel unterstützen, wobei das strategische Ziel nur erreicht werden kann, wenn alle IT-Projekte gemäss den vorgegeben Zielen umgesetzt werden. Dieser zurzeit stark auf IT-Projekte fokussierte Ansatz kann über die konsequente Anwendung einer Unternehmensarchitektur auch auf bankfachliche Themen ausgedehnt werden. Das folgende fachli- Gedruckt am Seite 60 von 95

61 che Führungsmodell 66 zeigt auf, wie die Strategie-Umsetzung über ein ganzheitliches Programm- Management besser unterstützt wird und bankfachliche Projekte und IT-Projekte zusammenfasst. Strategie des Unternehmens Bankfachliches Soll-Modell Bankfachliche Anforderungen Finanzplanung Strategische Schwerpunkte Bankfachlicher Bebauungsplan inkl. Projekte IT-Bebauungsplan inkl. IT-Projekte Programme zur Strategie- Umsetzung inkl. Bu sine ss Ca se IT-Soll-Architektur Skills-Management Bild 36: Fachliches Führungsmodell für Strategie-Umsetzung über Programm-Management In diesem fachlichen Führungsmodell werden die roten Bereiche (Strategie, Finanzplanung und strategische Schwerpunkte) primär durch die Geschäftsleitung definiert. Die blauen Bereiche sind in Verantwortung des Managements auf der Geschäftsseite. Das «bankfachliche Soll-Modell» wird getrieben durch die Strategie und die bankfachlichen Anforderungen. 67 Als Ableitung dieses Soll-Modell wird ein konkreter bankfachlicher Bebauungsplan erstellt, der die Strategie- Umsetzung auf der Zeitachse darstellt. Soweit möglich werden im Bebauungsplan Projekte bereits formuliert. Das IT-Management verantwortet die grauen Bereiche also die IT-Soll-Architektur, den IT- Bebauungsplan mit den IT-Projekten sowie das Skills-Management. Der IT-Bebauungsplan wird massgeblich durch den bankfachlichen Bebauungsplan und die IT-Soll-Architektur beeinflusst. Wie der bankfachliche Bebauungsplan stellt auch der IT-Bebauungsplan die Projekte auf der Zeitachse dar. 68 Die Umsetzung des bankfachlichen Bebauungsplanes sowie des IT-Bebauungsplanes erfolgt über Programme, welche durch das Management auf der Geschäftsseite verantwortet werden. Die Programme fassen Projekte von Seite Bankfach mit IT-Projekten zusammen und beinhalten auch einen verbindlichen Business Case bezüglich Ertragssteigerungen oder Kostenreduktionen. Dieser Business Case fliesst in das MbO des Linienmanagements auf Seite Geschäfts und in der IT ein. Werden in diesem fachlichen Führungsmodell nun einheitliche Präsentationsformen, eine einheitliche Sprache und transparenter Informationsaustausch zwischen den Teil-Architekturen wahrgenommen, so ist die Unternehmensarchitektur in die wesentlichen Führungsprozess von «Change the Bank» integriert. Das Unternehmen entwickelt sich kontrollierter - im Spannungsfeld zwischen Time to Market und Over-Engineering (siehe 7.2.1, Kontrollierte Entwicklung) Fachliches Führungsmodell in Anlehnung an ein IT-Governance-Modell von Anton Allemann, Leiter Logistik Nach dem Zachman-Framework sind dies die Perspektiven Unternehmensmodell und fachliches System-Modell. Im Zachman-Framework sind dies die Perspektiven des technischen System-Modells sowie der System-Komponenten. Gedruckt am Seite 61 von 95

62 7.4.3 Lieferung von Führungsinformationen Die Lieferung von Führungsinformationen aus bzw. in einer Unternehmensarchitektur ist im wesentlichen davon abhängig, wie aktiv vernetzt die Unternehmensarchitektur in den Führungsprozessen ist. Ein Beispiel für die Vernetzung im Kontext der Strategie-Umsetzung über Programm-Management ist im vorangehenden Abschnitt dokumentiert. Bei einer aktiven Vernetzung der Führungsbereiche liefert die Unternehmensarchitektur den Stakeholdern konsistente Führungsinformationen für die Aufbereitung von Entscheidungsgrundlagen - beispielsweise für Potenzial- und Risikoanalysen. Diese Führungsinformationen können genutzt werden, um die richtigen Entscheide zu fällen und entsprechende «Change the Bank»-Massnahmen zu initiieren. Was / Date n Wie / Funk tionen Wo / Orte Wer / Pers onen Wann / Er e ignisse Warum / Treiber Abgrenzung [Planer] Unternehmens modell [Fachver-antw ortl icher] Fachliches System-Modell [Analyst] Lieferung von vernetzten Führungsinformationen über die Unternehmensarchitektur Technisches System-Modell [Designer] System- Komponenten [Implementierer] Laufendes Unternehmen [Mitarbeiter, Partner und Kunden] Entscheide fällen Ist-Zustand «Run the Bank» «Change the Bank» Soll-Zustand «Run the Bank» Bild 37: Die Unternehmensarchitektur liefert und vernetzte Führungsinformationen aus allen Ebenen Vernetzung am Beispiel Strategie-Umsetzung Aus Sicht des Geschäfts werden im Unternehmensmodell (Zachman) und im fachlichen System- Modell beispielsweise Daten- und Geschäftsfunktionen mit Orten und Personen/Rollen verknüpft, dies basierend auf einer Zeitachse. Diese Zeitachse stellt einen «Business-Plan» dar, welcher die Massnahmen für die Strategie-Umsetzung beinhaltet. Die konsequente Führung über eine Unternehmensarchitektur ermöglicht es beispielsweise, Informationen aus dem operativen Geschäft für die Validierung laufender Massnahmen in der Strategie-Umsetzung zu nutzen. Vernetzung am Beispiel IT-Portfoliomanagement Im Kontext der IT werden über die Unternehmensarchitektur die Prozesse des IT-Architekturmanagements und des IT-Portfoliomanagements vernetzt. Geplante oder laufende Projekte im IT- Gedruckt am Seite 62 von 95

63 Projektportfolio können strukturiert Informationen aus dem IT-Architekturmanagement aufnehmen und in der Umsetzung berücksichtigen. Das Management der operativen Applikationen im Applikationsportfolio wird ebenfalls durch das IT- Architekturmanagement beeinflusst, Migrationsstrategien können so rechtzeitig entwickelt werden. Die folgende Grafik illustriert die Vernetzung beispielhaft: Der Ist-Zustand mit Produkten und Leistungen in einem Kerngeschäft ist nicht wettbewerbsfähig. Die Stückkosten sind mittelfristig zu senken, damit die Leistungen günstiger angeboten werden können. Ein Veränderung durch «Change the Bank» in diesem Kontext ist notwendig: Ist-Zustand «Run the Bank» Bestehende Produkte und Leistungen IT-Portfoliomanagement und IT-A rchitekturmanagement Vernetzung liefert Erkenntis «Change the Bank» Anforderungen sollen umgesetzt werden! SLA können nicht erfüllt werden IT-Architektur analysieren/ anpassen Soll-Zustand Applikatons- Migration «Run the Bank» Wettbewerbsfähige Produkte auf Basis günstigerer Leistungen IT-Portfoliomanagement und IT-A rchitekturmanagement SLA Bild 38: Vernetzung von Geschäfts- und IT-Management Verschiedene funktionale und nicht funktionale Anforderungen an die Organisation und an die Applikationen werden entwickelt (1), um die gleich bleibende Leistung kosteneffizienter zu erstellen. Die Informationen aus dem technischen System-Modell und den System-Komponenten (IT- Portfoliomanagement) zeigen auf, dass die Applikationen im Ist-Zustand diese Anforderungen nicht abdecken können, die geforderten SLA's können nicht erfüllt werden. Das IT- Architekturmanagement zeigt den Ist-Zustand mit den Kostentreibern auf (2). Um die Anforderungen umsetzen zu können und die SLA's einhalten zu können, muss die IT- Architektur angepasst werden (3). Auf Basis von Informationen aus dem IT-Architekturmanagement und den strategischen Anforderungen des Geschäfts aus dem Unternehmensmodell macht in einem Kernbankensystem eine Migration auf ein Standardprodukt Sinn (4). Nach Abschluss der Migration können die vereinbarten SLA eingehalten werden, die Leistungen sind kosteneffizienter und die Produkte können wettbewerbsfähig angeboten werden (5). Im wesentlichen besteht der qualitative Nutzen einer Unternehmensarchitektur darin, Transparenz zu schaffen, unnötige Heterogenität zu vermeiden, die Komplexität beherrschbar zu machen und so die Effizienz zu steigern Siehe [Niemann 2005], Seite 59 Gedruckt am Seite 63 von 95

64 7.4.4 Stiftung eines nachhaltigen Nutzens Die Aktivitäten des Unternehmensarchitekturmanagements binden Ressourcen. Aus betriebswirtschaftlicher Sicht stellt sich automatisch die Frage, welchen quantitativen Nutzen diese Architekturarbeiten für ein Unternehmen bringen. Im Grundsatz muss dieser Nutzen eher nachhaltig ausfallen, da operatives oder strategisches Architekturmanagement oft nicht sofort einen sichtbaren Nutzen bringt. Wie kann also der Wertbeitrag der einer IT-Architektur bzw. eines IT-Architekturmanagements gemessen werden? Die Kernaufgaben des IT-Architekturmanagements sind Komplexität beherrschbar halten und Heterogenität einschränken Verhinderung des Over-Engineerings 70 Zulassen einer kontrollierte Entwicklungen mit akzeptabler Time to Market Der Nutzen des IT-Architekturmanagements ist somit in diesen Aspekten zu messen. Eine mögliche Lösung für die Nutzenmessung stellt die Anwendung von Kennzahlen zu diesen Aspekten dar. Die folgende Tabelle stellt beinhaltet so genannte Kennzahlen oder Key Performance Indicators (KPI) 71, um den Nutzen des IT-Architekturmanagements messen zu können. Kennzahl / KPI Beschreibung Messung Komplexität Anzahl Schnittstellen zwischen Applikationen Anzahl Schnittstellen-Services werden gezählt Halbjährlich Anzahl Schnittstellen zwischen Infrastrukturkomponenten Heterogenität Reduktion der Anzahl Betriebssystem-Versionen Reduktion der Anzahl Datenbank-Versionen und Systeme Kontrollierte Entwicklung Architektur-Konformität Projekte Anzahl Schnittstellen-Services werden gezählt Betriebssystem-Versionen welche gewartet werden, werden gezählt: Windows-Versionen AIX-Versionen LINUX-Versionen Mainframe-Umgebungen Datenbank-Versionen welche gewartet werden, werden gezählt: DB2-Versionen Oracle-Versionen MS-SQL-Versionen MySQL-Versionen Prozentual erfüllte Konformitätsauflagen mit Severity 1 oder 2 zwei Monate nach Halbjährlich Halbjährlich Halbjährlich Jährlich Siehe «Kontrollierte Entwicklung» im Abschnitt In Anlehnung an das vorhandene Kennzahlensystem für die IT in der ZKB Gedruckt am Seite 64 von 95

65 Kennzahl / KPI Beschreibung Messung Komplexität Einführung Architektur-Konformität Betrieb Anzahl bedeutender Applikationen 72 im Jährlich Betrieb mit erheblichen Architektur- Abweichungen Durchgeführte Beratungen bei komplexen Projekten Verhinderung Over-Engineering Betriebsausfälle Prozentual durchgeführte Beratungen für bedeutende Projekte 73 SLA für Geschäftsprozess durch Betriebsausfall nicht eingehalten Halbjährlich Halbjährlich Tabelle 8: KPI's für die Messung des nachhaltigen Nutzens des Architekturmanagement Der über diese KPI's erhobene Nutzen muss dem quantitativen Aufwand eines Architekturmanagements gegenübergestellt werden (im wesentlichen Personal-, Raum und Sachkosten) Weitere Massnahmen Optimierung der Präsentationsformen Die Optimierung der Präsentationsformen stellen einen wesentlichen Beitrag zur Akzeptanz und damit Um- und Durchsetzungsfähigkeit der IT-Architektur dar. In den Interviews wurde von verschiedentlich darauf hingewiesen, dass die Präsentationsformen heute nicht managementtauglich sind. Insbesondere die Darstellungen von Applikations- oder Systemarchitekturen oft zu detailliert, technokratisch, sie verwenden ein eigenes Vokabular oder stellen teilweise nur eine technische Sichtweise ohne Bezug zum Geschäft dar. Strukturierung einer Architektur-Darstellung Die Präsentation einer Architektur-Darstellung muss standardisiert werden, so dass der Kontext aus der Unternehmensarchitektur transparent dargestellt wird. Wesentliche inhaltliche Elemente sind: Geschäftsprozess Benutzeroberfläche Applikations/Service-Ebene Datenhaltungs-/Infrastruktur-Ebene Die Darstellung des Geschäftsprozesses soll auf Makro-Ebene stattfinden und den Geschäftsprozess vom Kunden/zum Kunden als Wertschöpfungskette darstellen. Formale Aspekte einer Architektur-Darstellung Auch bezüglich formaler Aspekte sind Standards zu definieren und einzuhalten: Bezeichnung der Architektur mit Bezug zu Projekt oder IT-Betrieb Autor und Organisationsbereich Ausgabedatum und Dokumentversion Status (Entwurf, in Vernehmlassung, gültig) In der ZKB sind dies Applikationen mit dem Rating A oder B In der ZKB sind dies Projekte mit dem Rating A oder B Gedruckt am Seite 65 von 95

66 Klassifizierung Einheitliche Farbgebung für jeweilige Ebenen (Geschäftsprozess, Applikations-Ebene usw.) Einheitliche Symbole für jeweilige Elemente (Prozess-Schritt, Service-Objekt, Datenspeicher usw.) Diese Standardisierungs-Vorgaben werden in der folgenden Muster-Darstellung 74 einer IT-Architektur aufgenommen: Geschäftsprozess 1. Schritt A Vertrieb 2. Schritt B 3. Schritt C 4. Schritt D 5. Schritt E Verarbeitung 6. Schritt F 7. Schritt G Privatkunde Privatkunde Benutzeroberfläche B2B-Portal Vertriebsdesktop Verarbeitungs-Systeme Auftrag Auftrag Prozess-Steuerung Zentrale Auftrags- und Produktions-Steuerung Vertriebs -interne Ablaufsteuerung Verarbeitungs-interne Ablaufsteuerung Services Service #1 Service #2 Service #3 Service #4 Service #5 Service #6 Service #7 Infrastruktur/Datenhaltung Clients Vertriebssysteme Anonymisierung Verarbeitungssysteme De- Anonymisierung Bezeichnung Architektur für Musterprozess Klassifizierung INTERN Bezug Projekt MUSTER Rel. 1.0 Status Entw urf Autor Stefan Lenz/PT Datum/Version / V1.0 Bild 39: Muster-Darstellung einer Architektur mit mehreren Ebenen Diese Muster-Darstellung kombiniert verschiedene Sichten aus dem Rahmenwerk der Unternehmensarchitektur. Das Unternehmensmodell bzw. das fachliche System-Modell werden über die Prozess-Optik referenziert, die Benutzerschnittstellen, die Auftragssteuerung und die Services sind Teile fachlichen und technischen System-Modells, die Infrastruktur- und Datenhaltungs-Komponenten spiegeln die System-Komponenten des Zachman-Frameworks wieder. Die verwendeten Symbole sind zu standardisieren und zu dokumentieren. Architektur-Darstellungen für die Kerngeschäfte, für die der Anspruch besteht, eine durchgängige Sicht auszuweisen, müssen sich an diese Standards halten Gemeinsame Sprache für Geschäft und IT Ein wesentliches Element in der Optimierung der Präsentationsformen ist die Verwendung einer verbindlichen Fachsprache für Geschäft und IT. Diese Fachsprache soll auf definierter Literatur und einem verbindlichen Unternehmensglossar aufbauen. Der Schlüssel für eine gegenseitig verständliche und somit gemeinsame Sprache ist der dokumentierte Geschäftsprozess, dies erfordert aber bereits vorhandene Prozessbeschreibungen und eine ein- 74 In Anlehnung an die Architektur-Darstellung des IT-Projektes FinPro Gedruckt am Seite 66 von 95

67 heitliche Sichtweise auf diese Beschreibungen. Die Verwendung eines Unternehmensglossars welches die gültigen Begriffe enthält, unterstützt den durch Geschäft und IT gemeinsam getragenen Aufbau von Prozessbeschreibungen. Der Einsatz einer für beide Seiten einheitlichen Metasprache (beispielsweise einer Sprache aus der Quartier- oder Städteplanung) wird nicht empfohlen. Sowohl das Geschäft, wie auch die IT verfügen naturgemäss über eine eigene Fachsprache mit entsprechendem Vokabular, welche im Rahmen der Ausbildung an höheren Fachschulen, Hochschulen, Universitäten usw. vermittelt wird. Bis zu einem gewissen Grad muss jede Partei die Sprache der Gegenseite verstehen und entsprechende Kompetenzen aufbauen. Dementsprechend muss sich die Gegenseite bemühen Sachverhalte dennoch möglichst einfach zu beschreiben. 7.5 Strategisches Anforderungsmanagement Im Abschnitt des fachlichen Führungsmodells zur Integration der wesentlichen Führungsprozesse 75 wird aufgezeigt, wie die Strategie eines Unternehmens, das bankfachliche Soll-Modell und die IT-Soll- Architektur über Bebauungspläne und Programm-Management sukzessive umgesetzt werden. Strategie des Unternehmens Bankfachliches Soll-Modell Bankfachliche Anforderungen Finanzplanung Strategische Schwerpunkte Kontext des strategischen Anforderungsmanagements Bankfachlicher Bebauungsplan inkl. Projekte IT-Bebauungsplan inkl. IT-Projekte Programme zur Strategie- Umsetzung inkl. Busine ss Ca se IT-Soll-Architektur Skills-Management Bild 40: Strategisches Anforderungsmanagement im fachlichen Führungsmodell Das strategische Anforderungsmanagement ist auf Ebene der strategischen Schwerpunkte positioniert, Ergebnis des strategischen Anforderungsmanagements sind die Bebauungspläne. Der Prozess des Anforderungsmanagements umfasst im wesentlichen vier Schritte: Anforderung erfassen Anforderung analysieren Anforderung bewerten Anforderung realisieren Bild 41: Wesentliche Schritte des Anforderungsmanagements Die Erfassung der Anforderungen erfolgt strukturiert in einer zentralen Anforderungssammlung oder - datenbank. Die Erfassung ist für die Kontrolle des Prozesses wesentlich. Für eine Anforderung müssen in der Anforderungssammlung mindestens folgende Informationselemente verfügbar sein: Eindeutige Referenznummer Erfassungsdatum 75 Siehe Abschnitt Gedruckt am Seite 67 von 95

68 Anforderungsbezeichnung Anforderungsstatus Verantwortlicher Fachbereich und Autor Kurze textliche Beschreibung Bezug zu regulatorischen Auflagen Bezug zur Geschäftsstrategie Kontext der Geschäftsprozesse Kontext der Applikationen Bekannte Termine, insbesondere Einführungstermin Quantitativer Nutzen Qualitativer Nutzen Maximale Kosten für die Anforderungsumsetzung Die Anforderungssammlung soll dabei für alle Stakeholder transparent sein, damit bekannt ist, welche Anforderungen von welchen Fachbereichen vorhanden sind. Die Analyse der Anforderung beinhaltet eine umfassende Untersuchung über den Einfluss einer Anforderung auf die Prozesse, die Organisation oder bereits laufende Programme oder Projekte. Basierend auf der Analyse muss die Anforderung bewertet werden, so dass der Nutzen einer Anforderung (nach Realisierung) bereits zu diesem Zeitpunkt bekannt ist. Diese Informationen fliessen in den Bebauungsplan und in die Programme ein, insbesondere in den Business Case. Als letzter Schritt wird die Anforderung innerhalb eines einzelnen Projektes oder eingebettet in ein Projekt eines Programms umgesetzt. Für die Implementierung des strategischen Anforderungsmanagements ist im Optimalfall bereits eine Unternehmensarchitektur entwickelt und im Unternehmen verankert - dies erleichtert die Analyse- und Bewertungs-Arbeiten entsprechend. Ist dies nicht der Fall, so muss die Unternehmensarchitektur zuerst grundlegend entwickelt werden, da ein impliziter Aufbau einer Unternehmensarchitektur parallel zu strategischen Vorhaben aus Ressourcengründen meist nicht möglich ist Strategisches Architekturmanagement Der Aufbau einer Unternehmensarchitektur erfolgt im Kontext des so genannten strategischen Architekturmanagements 76, inhaltlich wird die Architektur von den strategischen Anforderungen getrieben. Wesentliche Artefakte des strategischen Architekturmanagements sind die Struktur, der vernetzte Inhalt und die Visualisierung der Unternehmensarchitektur, also das Rahmenwerk nach Zachman, aufgebaut nach TOGAF ADM. Ein weiteres Thema ist die Organisation des Architekturmanagements, dies wird im Abschnitt 7.6, Entwicklung eines IT-Architektur-Führungsmodells aufgenommen. Das strategische Architekturmanagement zeichnet somit verantwortlich für den effizienten Einsatz der IT-Mittel und unterstützt das IT-Portfoliomanagement. Dabei wird der Einsatz der IT-Mittel nicht nur aus Neuprojekten gestaltet, es wird auch darauf geachtet, aus dem vorhandenen Portfolio von Applikationen und Services das Beste zu machen. 76 Siehe [Niemann 2005], Seite 172 Gedruckt am Seite 68 von 95

69 7.5.2 Operatives Architekturmanagement Das operative Architekturmanagement stellt die Umsetzung der Vorgaben aus dem strategischen Architekturmanagement sicher. Das operative Architekturmanagement wirkt sowohl in Linienaufgaben wie in der Projektarbeit mit, dabei werden oft aufgabenspezifische Lösungen entwickelt, die aber trotzdem architekturkonform sind. Dabei müssen die Architekten die Anforderungen von Seite Geschäft und IT aufnehmen und die Umsetzung in die Realität unter den gegebenen Rahmenbedingungen unterstützen. Diese Aufgabe wird einerseits in Form von Beratungsleistungen erbracht, andererseits ist teilweise auch eine Durchsetzung von Architekturvorgaben notwendig, um die Komplexität beherrschbar zu halten und die Heterogenität einzuschränken Anforderungsmanagement und Architekturmanagement Ein strategisches Anforderungsmanagement für die Hauptbereiche der Unternehmensarchitektur ist von besonderer Bedeutung, da Architekturen getrieben sind von Anforderungen. Bild 42: Das strategische und das operative Architekturmanagement als wichtige Verbindungselemente 77 Dabei ist zu beachten, dass das Architekturmanagement als wichtiges Verbindungselement auch Entwicklungen «verhindern» kann und soll. Nämlich dann, wenn aus bestimmten Anforderungen voreilig neue Applikationen/Services entwickelt werden, wenn bestehende Applikationen oder Services durch Wiederverwendung und gezielte Anpassungen die Anforderungen erfüllen können. Das strategische Architekturmanagement wirkt somit präventiv und definiert die Vorgaben, das operative Architekturmanagement liefert Führungsinformationen an das strategische Architekturmanagement, um Architekturvorgaben weiterzuentwickeln. So wird die Aktualität und Umsetzbarkeit und damit die Akzeptanz von Architekturen sichergestellt. Das strategische Anforderungsmanagement ist also primär als Frühwarnsystem zu verstehen, welches durch das Architekturmanagement unterstützt wird. Durch Implementierung eines solchen Prozesses wird frühzeitig erkannt bzw. aufgezeigt, in welche Richtung sich das Unternehmen und damit auch die IT entwickeln müssen und wo die strategischen Schwerpunkte liegen. 77 Siehe [Niemann 2005], Seite 174 Gedruckt am Seite 69 von 95

70 7.6 Entwicklung eines IT-Architektur-Führungsmodells Das Unternehmensarchitekturmanagement benötigt eine dauerhafte und verbindliche Organisation, welche in den Strukturen gut positioniert, stark vernetzt und verankert ist. Eine Unternehmensarchitektur ist nicht statisch, sie entwickelt das Unternehmen kontinuierlich weiter. Im Folgenden wird ein Führungsmodell für das Architekturmanagement einer Universalbank wie die ZKB vorgeschlagen, das IT-Architekturmanagement ist dabei ein Bestandteil des Unternehmensarchitekturmanagements Kerngeschäfte und Unternehmensarchitektur Auf oberster Ebene wird das Unternehmensarchitekturmanagement mit den Kerngeschäften kombiniert sowie dem Kundenbeziehungsmanagement, der Vertriebssteuerung und Banksteuerung kombiniert. Dadurch werden so genannte «Architektur-Domänen» gebildet, die im Sinne der Unternehmensarchitektur vernetzt und architekturübergreifend entwickelt werden. Kundenbeziehungsmanagement Vertriebssteuerung Immobilien- und Finanzierungen Anlage- und Vermögensverwaltung Geldverkehr Handel- und Kapitalmarkt Banksteuerung Unternehmensarchitekturmanagement Bild 43: Kombination der Kerngeschäfte als Architektur-Domänen mit der ganzheitlichen Unternehmensarchitektur In den Architektur-Domänen werden durch verschiedene Rollen drei wesentliche Leistungsbereiche wahrgenommen. Die Leistungsbereiche sind für die Wertschöpfung des Architekturmanagements verantwortlich, in jeder Architekturdomäne sind die folgenden Rollen 78 vorhanden: Strategisches Architekturmanagement Produkt-Manager Business Architekten Business Engineers Programm-Manager ICT-Architekten Operatives Architekturmanagement 78 Die Rollenbezeichnungen und die Einordnung der Rollen basieren auf [ICT 2004] Gedruckt am Seite 70 von 95

71 Projektleiter Business Analysten Die Produkt-Manager entwickeln neue Produkte und Leistungen oder passen bestehende Leistungen an geänderte Kundenbedürfnisse an. Das Produktmanagement besitzt einen expliziten Markt- und Kundenfokus. Die Business Architekten beraten die Geschäftsleitung bezüglich Strategie, Prozessen und Strukturen im Sinne des Gesamtüberblicks. Sie haben den Status eines Unternehmensberaters und haben die Verantwortung über das strategische Architekturmanagement. Die Produkt-Manager und die Business Architekten sind Fachverantwortliche im Zachman- Rahmenwerk und verantworten das Unternehmensmodell. Die Business Engineers beraten das Produktmanagement und die Geschäftsbereiche in der Gestaltung und Entwicklung der Geschäftsarchitektur mit den Bestandteilen Prozessen, Produkten und Leistungen. Dabei steht die Optik der durchgängigen Wertschöpfungskette vom Kunden/zum Kunden im Vordergrund. Die ganzheitliche Prozessverantwortung («Prozess-Owner») ist im Produktmanagement angesiedelt. Eine Prozess-Verantwortung ist auf ein Kerngeschäft (Finanzierungen, Geldverkehr oder Kundenbeziehungsmanagement) fokussiert, umfasst aber die Bereiche Vertrieb und Verarbeitung. Die Programm-Manager formulieren mit den Business Engineers die entsprechenden Programme und Projekte zur Umsetzung von Anforderungen an die Architektur. Die Projektleiter führen die einzelnen Projekte und verfügen dazu in der Linien- oder Matrixstruktur über Business Analysten, welche prozessuale und fachliche Sachverhalte detailliert ausarbeiten. Die Business Engineers und die Programm-Manager bebauen im Zachman-Rahmenwerk das fachliche System-Modell. Die Programm-Manager übernehmen die Umsetzungs-Verantwortung. Die ICT-Architekten sind in das strategische Architekturmanagement und in der Umsetzung in das operative Architekturmanagement eingebunden. Die ICT-Architekten entwickeln und gestalten System-Komponenten wie Applikations- und Datenbankserver, Middleware, Internet-Gateways usw. Zudem sind sie für die Um- und Durchsetzung der IT-Sicherheitsvorgaben verantwortlich. Die ICT-Architekten verantworten das technische Systemmodell und die System-Komponenten aus dem Zachman-Rahmenwerk Aufgaben in den Architekturdomänen Die Aufgaben im Leistungsbereich [Plan] umfassen die konkrete Massnahmenentwicklung und Umsetzungsplanung aus der Strategie: Leistungsbereich [Plan] Definition von neuen o- der angepassten Leistungen Analyse von Geschäftsprozessen Erhebung von Optimie- Beschreibung Produkt-Manager definieren neue oder angepasste Leistungen für den Markt. Business Architekten und Business Engineers beraten die Geschäftsbereiche und das Produkt-Management bezüglich Strategie-Umsetzung, die Anforderungen werden konkretisiert, erfasst und analysiert. Die Anforderungen werden durch die Business Engineers un- Gedruckt am Seite 71 von 95

72 Leistungsbereich [Plan] rungspotenzial Beschreibung ter Mitwirkung der Stakeholder bewertet. Es werden unterschiedliche Lösungsvarianten oder Szenarien entwickelt und bewertet. Fachliche Entscheide bezüglich Geschäftsprozessen sind durch das Produktmanagement zu fällen. Für die ausgewählten Szenarien werden in Zusammenarbeit mit den Programm-Managern die Programme formuliert, welche die einzelnen Projekte beschreiben und voneinander abgrenzen. Die Geschäftsprozesse zur Leistungserstellung werden bis auf Makro-Ebene definiert, die Optimierungspotenziale werden qualitativ und quantitativ erhoben, sie dienen als Grundlage für die Business Cases der Programme Tabelle 9: Leistungsbereich [Plan] im fachlichen Führungsmodell des Architekturmanagements Die Aufgaben im Leistungsbereich [Build] umfassen die Umsetzung der Programme und Projekte innerhalb der definierten Rahmenbedingungen: Leistungsbereich [Build] Definition funktionale und nicht-funktionalen Anforderungen Definition Geschäftsprozesse und -Abläufe Definition Lösungsarchitektur in allen drei Architekturbereichen Umsetzung der Lösungsarchitektur in den Projekten Integrations-Test, Systemtest und Abnahme Produktionseinführung Garantiearbeiten Beschreibung Die einzelnen Projekte werden zu Programmen gebündelt, der Programm-Manager übernimmt die Umsetzungsverantwortung. Für jedes Programm ist ein Programm-Sponsor auf Geschäftsseite definiert, das Programm liefert für die Strategie-Umsetzung des Sponsors einen entscheidenden Beitrag. Einzelne Projekte, welche sich nicht zu einem Programm bündeln lassen, werden in einem Projektportfolio-Kontext kontrolliert umgesetzt. Der Projektleiter strukturiert sein Projekte und entwickelt mit den Business Analysten die funktionalen und nichtfunktionalen Anforderungen. Diese werden durch Review- Zyklen mit den fachverantwortlichen Stellen überprüft. Die Lösungsarchitekturen für die betroffenen Ausschnitte aus der Domäne werden entworfen und diskutiert, Entscheide von grosser Tragweite werden durch den Architekturausschuss gefällt. Die Umsetzung der Lösungsarchitekturen erfolgt durch Software-Spezialisten für die entsprechenden Standard-Software- Pakete und die Middleware. Die Business Analysten führen mit den Entwicklern die Unittests durch. Die weiteren Testzyklen werden durch Business Analysten geführt, da in diesem Kontext bereits ein umfassendes Geschäftsverständnis notwendig ist. Die Software-Spezialisten unterstützen in diesen Testprozessen und übernehmen die Korrektur von Fehlern. Gedruckt am Seite 72 von 95

73 Leistungsbereich [Build] Beschreibung Die Abnahme wird durch den Programm-Manager und den Projektleiter durchgeführt. Die Produktionseinführung wird durch die Software- Spezialisten vorgenommen. Tabelle 10: Leistungsbereich [Build] im fachlichen Führungsmodell des Architekturmanagements Der Dienstleistungsbereich [Run] umfasst die Umsetzung der Programme und Projekte innerhalb der definierten Rahmenbedingungen: Leistungsbereich [Run] Analyse der Geschäftsprozess-Performance, Vergleich zu den Planwerten Analyse der Einhaltung der SLA für Geschäftsprozesse Analyse der OLA für die Applikationen/Services Rapportierung der SLA- Einhaltung gegenüber dem Management Beschreibung Die Leistungserstellung am Markt wird durch das Produkt- Management analysiert, die Kundenzufriedenheit erhoben, das Unternehmen wird mit Mitbewerbern verglichen, Opportunitäten für neue Geschäftschancen und Geschäftsmodelle werden identifiziert Die operativen Geschäftsprozesse und Applikationen/Services werden in einer End-zu-End-Betrachtung der Wertschöpfungskette laufend überprüft, Schwachstellen werden identifiziert und Anforderungen für Optimierungen werden formuliert. Die Einhaltung der Service-Levels wird überprüft, dem Management werden entsprechende SLA-Reportings zur Verfügung gestellt. Tabelle 11: Leistungsbereich [Run] im fachlichen Führungsmodell des Architekturmanagements Im folgenden Abschnitt wird ein Vorschlag für eine Linienorganisation zu den Leistungsbereichen und Rollen skizziert Linienorganisation Bei der Linienorganisation werden zwei Varianten vorgeschlagen, einerseits eine zentrale Struktur für die ganzheitliche Führung der Unternehmensarchitektur, andererseits eine dezentrale Struktur Zentrales Führungsmodell Bei der zentralen Struktur wird davon ausgegangen, dass diese Struktur in der Geschäftseinheit Gesamtleitung angesiedelt wird. Die Organisation ist intern in die erwähnten Domänen gegliedert. Die Unternehmensarchitektur für die Banksteuerung ist analog strukturiert (ohne Produktmanagement), aber direkt beim CFO in der Geschäftseinheit Finanz angesiedelt. Das strategische Architekturmanagement wird hauptsächlich von Business Architekten wahrgenommen. Der Bereich des Produktmanagements ist primär für die Perspektive Unternehmensmodell zuständig. Das Business Engineering verantwortet das fachliche System-Modell. Das Produktmanagement und das Business Engineering sind für den beschriebenen Leistungsbereich [Plan] verantwortlich, wobei die Prozessverantwortung beim Produktmanagement liegt. Das Programm- und Projekt-Management setzt die definierten Programme und Projekte um, aus dem Business Engineering werden dabei die erforderlichen Business Analysten rekrutiert. Die Durchset- Gedruckt am Seite 73 von 95

74 zung der Architekturvorgaben in Programmen im Sinne des operativen Architekturmanagements liegt in der Verantwortung der Programm-Manager. Das Programm- und Projekt-Management ist für den Leistungsbereich [Build] verantwortlich. Leitung Unternehmensarchitektur Strategisches Architekturmanagement Controlling und Führungsunterstützung Leitung Produktmanagement Leitung Programm- und Projekt-Management Leitung Business Engieering Kundenbeziehungsund Vertriebsmanagement Kundenbeziehungsund Vertriebsmanagement Kundenbe ziehungsund Vertriebsmanagement Immobilien- und Finanzierungen Immobilien- und Finanzierun gen Immobilien- und Finanzierungen Anlage- und Vermögensv erwaltungsgeschäf t Anlage- und Vermögensv erwaltungsgeschäf t Anlage- und Vermögensv erwaltungsgeschäf t Geldv erkehr Geldv erkehr Geldv erkehr Handel- und Kapitalmarkt Handel- und Kapitalmarkt Handel- und Kapitalmarkt Bild 44: Zentrales Führungsmodell für das Architekturmanagement Die Steuerung einer Architekturdomäne (siehe 7.6.1, Kerngeschäfte und Unternehmensarchitektur) wird von einem Architektur-Steuerungsausschuss wahrgenommen. Die Geschäftsführung eines Architektur-Steuerungsausschuss wird vom Produktmanagement wahrgenommen Dezentrales Führungsmodell Bei der dezentralen Struktur wird von der heutigen Struktur der Geschäftseinheiten der ZKB als Basis ausgegangen. Das strategische Architekturmanagement ist direkt dem CEO unterstellt. Es wird geführt von den verantwortlichen Business Architekten und führt die Mitarbeiter im Business Engineering fachlich. Die Geschäftseinheiten im Vertrieb haben die Ergebnisverantwortung, die Entwicklung der Unternehmensarchitektur durch das Produktmanagement, das Business Engineering ist auf die Vertriebseinheiten verteilt. Eine Einheit aus Produktmanagement sowie Business Engineering stellt ein Kompetenzcenter dar. Die Kompetenzcenter werden fachlich durch einen Kompetenzcenter-Leiter koordiniert, die fachliche Führung ist auf die Abstimmung der Methoden fokussiert. In diesem dezentralen Führungsmodell sind die bankfachlichen Themenbereiche so auf die Vertriebseinheiten verteilt, wie andere Rollen im fachlichen Kontext angesiedelt sind. So ist beispielsweise in der Geschäftseinheit Firmenkunden das Credit Office angesiedelt, das Produktmanagement für Finanzierungen wird analog positioniert. Gedruckt am Seite 74 von 95

75 Das Programm- und Projektmanagement ist dem Kompetenzcenter gleichgestellt, es ist jedoch für den ganzen Vertrieb in der Geschäftseinheit Privatkunden positioniert, dies um in der Umsetzung von Programmen oder Projekten Redundanzen zu vermeiden. Im Bereich Programm- und Projektmanagement werden die für die Programme erforderlichen Ressourcen für Business Analyse und Projektleitung als temporäre Teams (für die Projektdauer) auch in der Linienorganisation geführt. Das Programm- und Projektmanagement ist nicht als Stabsstelle ausgebildet, da es für die erfolgreiche Durchführung der Programme Ergebnisverantwortung besitzt. Gesamtle itung / CEO Strategisches Architekturmanagement Privatkunden Firmenkunde n Investment- und Private Banking weitere Kompetenzcenter Kompetenzcenter Kompetenzcenter Produktmanagement Basisprodukte, Geldvekehr Finanzplanung Produktmanagement Finanzierungen Produktmanagement Anlage- und Vermögensverw altung Buisiness Engineering Buisiness Engineering Buisiness Engineering Programm- und Projekt- Management Vertrieb Bild 45: Dezentrales Führungsmodell für das Architekturmanagement Aus Sicht der Unternehmenskultur der ZKB sind dezentrale Führungsmodelle geeigneter als zentrale Strukturen Personalkapazität nach Rollen Die Personalkapazität nach Rollen ist an der Strategie der Bank auszurichten, das bedeutet, dass in einzelnen Rollen wie beispielsweise Business Analyse bei einem strategischen Themenschwerpunkt «Anlagegeschäft» über eine bestimmte Zeit mehr Personen auf diesem bankfachlichen Thema eingesetzt werden. Rolle Personalkapazität in FTE 79 Bemerkungen Produkt-Manager 15 4 Kerngeschäfte mit 3 Produkt-Managern pro Kerngeschäft 3 Produktmanager für Beratungs- und Betreu- 79 FTE bedeutet Full Time Equivalent, was einer Vollzeitstelle entspricht Gedruckt am Seite 75 von 95

76 Rolle Personalkapazität in FTE 79 Bemerkungen ungsleistungen Business Architekten 4 4 Kerngeschäfte Business Engineers 16 4 Kerngeschäfte mit je 3 Business Engineers pro Kerngeschäft 4 Business Engineers für das Kundenbeziehungs- und Vertriebsmanagement Business Analysten 26 4 Kerngeschäfte mit 6 Business Analysten pro Kerngeschäft Programm-Manager 8 4 Kerngeschäfte mit je 2 Programm-Managern Projektleiter 16 4 Kerngeschäfte mit je 4 Projektleitern ein Projektleiter führt oft mehr als ein Projekt parallel ICT-Architekten 6 4 ICT-Architekten für die IT-Services der Kerngeschäfte 2 ICT-Architekten für IT-Sicherheit Total 91 FTE für die Unternehmensarchitektur Tabelle 12: Geschätzte Personalkapazität für Aufbau und Unterhalt einer Unternehmensarchitektur nach Rollen Die geschätzten 91 FTE in den verschiedenen Rollen stellen teilweise bereits existierende Stellen dar, beispielsweise Produkt-Manager, Programm-Management oder bei den ICT-Architekten. Die Besetzung der Stellen mit Mitarbeitern erfordert in gegenseitigem Interesse eine Überprüfung von Mitarbeiter-Fähigkeiten, Team-Konstellation und Anforderungen auf Basis Stellenbeschreibung. In verschiedenen Organisationsbereichen müssen Mitarbeiter aus dem bestehenden Portfolio transferiert werden. Insbesondere im Bereich Business Architekten, Business Analyse und Business Engineering ist aber ein personeller Aufbau notwendig. Um kurzfristige, projektbedingte Personalengpässe zu überbrücken oder um spezifisches Know-how einzukaufen, werden die vorhandenen internen Ressourcen mit externen Ressourcen verstärkt dabei ist aber dem Wissenstransfer entsprechende Beachtung zu schenken. 7.7 Umsetzung Umfang und Abgrenzung Die im Abschnitt 7 entwickelten und dokumentierten Lösungen zum Aufbau einer Unternehmensarchitektur werden im Rahmen Programms umgesetzt. Folgende Massnahmen sind Bestandteil des Programms: Nr. Massnahme Bemerkungen Zeitdauer 1 Grundsatzentscheid zum Aufbau einer Unternehmensarchitektur Aufbereitung von Entscheidungsgrundlagen Durchführen von Vorbesprechun- 3 Monate Gedruckt am Seite 76 von 95

77 Nr. Massnahme Bemerkungen Zeitdauer gen Entscheid durch die Geschäftsleitung zu fällen 2 Entscheid Führungsmodell Aufbereitung von Entscheidungsgrundlagen Durchführen von Vorbesprechungen Entscheid durch die Geschäftsleitung zu fällen 3 Neu-Gestaltung Neu-Strukturierung des Produkt- Produkt-Management Managements nach definiertem Führungsmodell Entwicklung einer methodischen Führung 4 Neu-Gestaltung Neu-Strukturierung des Programm- Programm-Management und Projekt-Managements nach definiertem Führungsmodell 5 Aufbau Business Engineering Umfasst Business Engneering und und Business Analyse Business Analyse Konsolidierung von internen Strukturen, Rekrutierung von neuen Mitarbeitern Entwicklung von Standards Methodische Ausbildung 6 Aufbau Grundfassung der Unternehmensarchitektur Aufbau nach Methode von TOGAF ADF 7 Grundausbildung Methodische Ausbildung Architekturmanagement Zielpublikum Produkt-Manager, Business Engineers, Business Analysten 8 Strategisches Prozesse für Anforderungen erfassen, Anforderungsmanagement analysieren und bewerten Zentrale Anforderungsdatenbank aufbauen Methodische Ausbildung 9 Optimierung der Entwicklung von Präsentationsvorlagen- Präsentationsformen und Standards Methodische Ausbildung 10 Gemeinsame Sprache Definition der für Geschäft und IT verbindlich gültigen Literatur als 3 Monate 6 Monate 3 Monate 16 Monate 12 Monate 2 Monate 8 Monate 2 Monate 6 Monate Gedruckt am Seite 77 von 95

78 Nr. Massnahme Bemerkungen Zeitdauer Fachsprache Aufbau eines verbindlichen Unternehmensglossars Tabelle 13: Aktivitäten zur Umsetzung und Abgrenzung Umsetzungsplanung Die folgende Umsetzungsplanung stellt einen Zeitplan für das Programm im Sinne einer Empfehlung dar. Strategie Grundsatzentscheid Unternehmensarchitektur Entscheid Führungsmodell Entscheid Grundmodell Unternehemensarchitektur Standortbestimmung Prozesse Organisation Prozesse Strategisches Anforderungsmanagem ent Gemeinsame Sprache Neu-Gestaltung Produktmanagement Neu-Gestaltung Programm - Management Grundausbildung Optimierung Architekturmgmt der Präsentatonsform en Grundfassung Unternehmensarchitektur Organisation Prozesse als Treiber Abstimmung Prozesse/Organisation Neu-Gestaltung Neu-Gestaltung Programm - Produktmanagement Management Aufbau Business Engineering Aufbau Business-Analyse Zeit t0 t+6 t+12 t+18 t+24 Bild 46: Umsetzungsplan für Aufbau der Unternehmensarchitektur, Zeitachse in Monaten Gedruckt am Seite 78 von 95

79 8 Beurteilung der Ziel-Erreichung In diesem Abschnitt wird die Zielerreichung durch den Auftraggeber und den Autor einzeln beurteilt. Die Beurteilung wurde anlässlich der Sitzung vom vorgenommen. Zielsetzung Ziel-Erreichung Auftraggeber Autor Erhöhung der Geschäftsorientierung 3 3 Aufbau eines strategischen Anforderungsmanagements Vorschlag eines Führungsmodells für das IT-Architekturmanagements Tabelle 14: Beurteilung der Ziel-Erreichung Als Beurteilung der Ziel-Erreichung wird eine 4stufige Skala verwendet. 1 = Ziel nicht erreicht, Analyse/Lösung vorhanden 2 = Ziel teilweise erreicht, Analyse/Lösung weist Lücken auf 3 = Ziel erreicht, nachvollziehbare Analyse/Lösung vorhanden 4 = Ziel übertroffen, Analyse/Lösung umfassend beschrieben/sehr gut nachvollziehbar Gedruckt am Seite 79 von 95

80 Literaturverzeichnis Im Literaturverzeichnis werden sowohl Quellenangaben zu schriftlichen Referenzen wie auch Quellenangaben zu Internet-Publikationen aufgeführt. Quellenangaben Literatur Referenz [Dobiéy 2004] [Grässle 2006] [ICT 2004] [Krüger 2003a] [Krupinski 2005] [Masak 2005a] [Niemann 2005] [Vogel 2005a] [Winter 2006a] [ZKB 2006a] [ZKB 2006b] Quellenangabe Dirk Dobiéy, Thomas Köplin, Wolfram Mach (2004). Programm-Management. Weinheim: Wiley-Vch Verlag GmbH & Co, KGaA Markus Schacher, Patrick Grässle (2006). Agile Unternehmen durch Business Rules. Berlin: Springer Science und Business Media. SwissICT (2004). Berufe der ICT. Zürich: vdf Hochschulverlag AG an der ETH Zürich Krüger Sascha (2003). IT-Architektur-Engineering. Bonn: Galileo Computing. Krupinski Andreas (2005). Unternehmens-IT für Banken. Wiesbaden: Friedrich Vieweg & Sohn Verlag Masak Deiter (2005). IT-Alignment. Berlin: Springer Science und Business Media. Niemann Klaus D. (2005). Von der Unternehmensarchitektur zur IT-Governance. Wiesbaden: Friedrich Vieweg & Sohn Verlag Vogel Oliver (2005). Software-Architektur. Anforderungen als Motivatoren. Heidelberg: Spektrum Akademischer Verlag Winter Robert (2006). Freie Sicht auf Unternehmensstrukturen. St. Gallen: Universität St. Gallen ZKB (2006). Gesamtbankstrategie der Zürcher Kantonalbank. Zürich: ZKB. ZKB (2006). Funktionale Strategie Information Technology der Zürcher Kantonalbank. Zürich: ZKB. Quellenangaben Internet-Publikationen Referenz Quellenangabe Beschreibung [BIS 2006a] Bank for International Settlements mit dem Basler Ausschuss für Bankenaufsicht, welcher die Umsetzung von Basel II kontrolliert [IEEE 2006a] IEEE, Institute of Electrical and Electronics Engineers [Microsoft 2006a] [TOGAF 2006a] architecture/fokusthemen/motion.mspx togaf8-doc/arch/index.html Business in «Motion» - das Framework der Microsoft Unternehmensarchitektur Dokumentation zum Rahmenwerk TOGAF 8 Enterprise Edition der OpenGroup [TopEase 2006] Die Firma pulinco engineering ag, Zollikofen ist Autor der Methode «TopEase Approach» und Hersteller des Produktes «TopEase» [Zachmann 2006a] [ZKB 2005a] geschaeftsbericht_2005.pdf The Zachman Institute for Framework Advancement Geschäftsbericht der ZKB, 2005 Gedruckt am Seite 80 von 95

81 Tabellenverzeichnis Tabelle 1: Die Geschäftsjahre 2005 und 2004 der ZKB im Zahlenvergleich...12 Tabelle 2: Anzahl Mitarbeiter in den Geschäftseinheiten...15 Tabelle 3: Die Ziele der Diplomarbeit und ihre Gewichtung...33 Tabelle 4: Beispielhafte Aufstellung der Elemente aus dem Zachman-Framework, übersetzt in die deutsche Sprache...49 Tabelle 5: Vergleich Prozessmodell und Business Capability Map aus dem Motion-Modell...51 Tabelle 6: Nutzwertanalyse für den Vergleich der Architektur-Modelle...53 Tabelle 7: Das Zachman-Framework mit vernetzten Führungsbereichen der ZKB...57 Tabelle 8: KPI's für die Messung des nachhaltigen Nutzens des Architekturmanagement...65 Tabelle 9: Leistungsbereich [Plan] im fachlichen Führungsmodell des Architekturmanagements...72 Tabelle 10: Leistungsbereich [Build] im fachlichen Führungsmodell des Architekturmanagements...73 Tabelle 11: Leistungsbereich [Run] im fachlichen Führungsmodell des Architekturmanagements...73 Tabelle 12: Geschätzte Personalkapazität für Aufbau und Unterhalt einer Unternehmensarchitektur nach Rollen...76 Tabelle 13: Aktivitäten zur Umsetzung und Abgrenzung...78 Tabelle 14: Beurteilung der Ziel-Erreichung...79 Abbildungsverzeichnis Bild 1: Erarbeitungsprozess und Vorgehensweise für die vorliegende Diplomarbeit...8 Bild 2: Das blaue Logo der Zürcher Kantonalbank mit dem ergänzenden Claim Bild 3: Das dichte Filialnetz mit 109 Geschäftsstellen im Kanton Zürich...11 Bild 4: Die ZKB als Berater für Firmen und Private - in allen Lebensphasen...11 Bild 5: Organigramm der ZKB auf Ebene der Generaldirektion Bild 6: Das IT-Führungsmodell der ZKB, definiert mit der IT-Strategie im Jahre Bild 7: Das Metamodell der IT-Architektur der ZKB...19 Bild 8: Die Geschäftsbereiche für das IT-Architekturmanagement der ZKB...21 Bild 9: Dokumentation der IT-Architektur mit AMF von Accenture, im Beispiel Informationen zur Applikation ZKBconnect...21 Bild 10: Funktionenmodell aus der IT-Architektur der ZKB, verwaltet mit AMF...22 Bild 11: Vertriebsdesktop «ZKBconnect» auf Basis von Siebel...23 Bild 12: Eckpfeiler der IT-Architektur aus Sicht der strategischen Produkte für die Kerngeschäfte...24 Bild 13: Prozesslandkarte der Organisationsberatung...25 Bild 14: Zusammenhang der Begriffe Funktion, Prozessschritt, Leistung, Leistungsbündel und Produkt...26 Bild 15: Organisationsbereiche, welche neue Produkte für definierte Kundensegmente erstellen...27 Bild 16: Der «Fahrplan» des Prozesses strategische Planung und Controlling in einem Jahreszyklus...27 Bild 17: Informationsmodell aus OpEx/Risk mit drei Ebenen...29 Bild 18: Die drei Bereiche für Alignment zwischen Business und IT und einer Geschäftsorientierung der Architektur...32 Bild 19: Anforderungen aus Strategie, Prozesse und Organisation wirken auf die Architekur...32 Bild 20: Prinzip der kontrollierten Entwicklung, die IT-Architektur sorgt für Definition und Einhaltung von Leitplanken...34 Bild 21: Bereiche einer Unternehmensarchitektur auf oberster Ebene nach [Niemann 2005]...36 Bild 22: Das Architektur-Modell der ZKB...37 Bild 23: Prozesslandkarte aus der Applikations-Architektur der IT-Organisation...38 Bild 24: Reifegradmodell für das Technologiemanagement in der IT-Architektur der ZKB...39 Bild 25: Architektur-Entwicklungs-Zyklus nach TOGAF ADM...40 Bild 26: Entwicklung eines Geschäftsszenarios zur Erhebung von Anforderungen...42 Bild 27: Muster eines Bebauungsplanes für ein Migrations-Programm zur Umsetzung einer Ziel-Architektur...43 Bild 28: Das Enterprise Continuum von TOGAF, mit Architecture Continuum und Solutions Continuum...45 Bild 29: Das technische Referenzmodell im Architektur-Kontinuum von TOGAF...46 Bild 30: Das Zachman-Framework bietet unterschiedliche Dimensionen und definierte Perspektiven...48 Bild 31: Das Zachman-Framework für Unternehmens-Architekturen...48 Bild 32: Die Business Capability-Map aus dem Motion-Framework von Microsoft...50 Bild 33: Die drei Ebenen der Business Capability Map...51 Bild 34: Phasenmodell eines Motion-Projekts mit vier Phasen, drei Gates und so genannten Off-Ramps für den Abbruch...52 Bild 35: Eigene Prozess-Darstellung für Aufbau der Unternehmensarchitektur nach TOGAF ADM...58 Bild 36: Fachliches Führungsmodell für Strategie-Umsetzung über Programm-Management...61 Bild 37: Die Unternehmensarchitektur liefert und vernetzte Führungsinformationen aus allen Ebenen...62 Bild 38: Vernetzung von Geschäfts- und IT-Management...63 Bild 39: Muster-Darstellung einer Architektur mit mehreren Ebenen...66 Gedruckt am Seite 81 von 95

82 Bild 40: Strategisches Anforderungsmanagement im fachlichen Führungsmodell...67 Bild 41: Wesentliche Schritte des Anforderungsmanagements...67 Bild 42: Das strategische und das operative Architekturmanagement als wichtige Verbindungselemente...69 Bild 43: Kombination der Kerngeschäfte als Architektur-Domänen mit der ganzheitlichen Unternehmensarchitektur...70 Bild 44: Zentrales Führungsmodell für das Architekturmanagement...74 Bild 45: Dezentrales Führungsmodell für das Architekturmanagement...75 Bild 46: Umsetzungsplan für Aufbau der Unternehmensarchitektur, Zeitachse in Monaten...78 Bild A1: Informationen zu ZKBconnect in der Applikation AMF...89 Bild A2: Applikationslandkarte im Ist-Zustand in AMF...89 Bild A3: Applikationslandkarte im Soll-Zustand in AMF...90 Bild A4: Beschreibung einer Funktion «Kreditfinanzierung beantragen» in AMF...90 Bild A5: Beschreibung der Technologie «Tablet Computers» in AMF...91 Gedruckt am Seite 82 von 95

83 Anhang A: Durchgeführte Interviews Für die Erarbeitung dieser Diplomarbeit wurden verschiedene Interviews durchgeführt. Zielsetzung der strukturierten Interviews war es, von Stakeholdern aus dem Management der ZKB (Fachbereich sowie IT-Organisation) eine persönliche Würdigung zur Thematik IT-Architektur und IT-Architekturmanagement abzuholen. Die Würdigung war fokussiert auf eine persönliche Meinung über den aktuellen Stand der IT-Architektur-Arbeit den Nutzen dieser Aktivitäten und der Artefakte aus der IT-Architektur sowie die Erwartungshaltung für die Zukunft der IT-Architektur Interview-Partner Die Interviews wurden mit folgenden Personen im Management der ZKB durchgeführt: Datum Interview-Partner Organisation, Funktion und Methode Anton Allemann Leiter Logistik, Mitglied der Geschäftsleitung Martin Scholl Leiter Privatkunden, Mitglied der Geschäftsleitung Roland Scheck Leiter IT-Portfolio- und Architekturmanagement Dieter Bühler Leiter Integrations-Architektur Zeno Bauer Leiter Produktmanagement Stefan Bösch Leiter Implementation Produkte Anlagen Markus Weishaupt Leiter Produktion Lucien Berlinger Leiter Unternehmens-Entwicklung - Robert Stadler 80 Leiter System-Architektur Die Ergebnisse der Interviews sind schriftlich festgehalten, sie sind beim Autor der Diplomarbeit verfügbar. Den Interview-Partnern wurden die Ergebnisse zur Gegenlesung zur Verfügung gestellt. Interview-Ergebnisse Aus den strukturierten Interviews werden die Ergebnisse festgehalten, welche eine Signifikanz ergeben haben. Quantitative Zusammenfassung von Aussagen Beurteilen Sie die Aussagen zum IT-Architekturmanagement in der ZKB aus Ihrer Sicht Organisationsform des IT-Architekturmanagements ist zw eckmässig IT-Architekturmanagement ist ausreichend bankfachlich kompetent Stellungnahmen des IT-Architekturmanagements transparent und nachvollziehbar IT-Architekturmanagement ist dienstleistungsorientiert IT-Architektur ausgerichtet an Unternehmensstrategie Nicht zutreffend Trifft teilweise zu Trifft zu Nicht beurteilbar Definierte IT-Architektur ist zukunftsorientiert 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 80 Das Interview mit Robert Stadler musste kurzfristig verschoben werden, ein neuer Termin konnte nicht gefunden werden Gedruckt am Seite 83 von 95

84 Kernaussagen: Die Organisationsform des IT-Architekturmanagements ist für 80% der Interview-Partner nicht zweckmässig Die bankfachliche Kompetenz kann nur 60% der Interview-Partner überzeugen Das IT-Architekturmanagements arbeitet mehrheitlich dienstleistungsorientiert Die Ausrichtung der IT-Architektur an der Unternehmensstrategie wird von 80 % der Teilnehmer mehrheitlich positiv beurteilt Die Zukunftsorientierung der IT-Architektur ist nur teilweise zutreffend Wie beurteilen Sie die Möglichkeiten des IT-Architekturmanagements zur Steuerung in der Projektabwicklung? Rolle der Systemarchitektur ist akzeptiert Nicht zutreffend Rolle der Applikationsarchitektur ist akzeptiert Trifft teilw eise zu Trif ft zu Nicht beurteilbar Operative Steuerung zur Durchsetzung der IT-Architketur ist spürbar 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Kernaussagen: Die Rolle der Applikationsarchitektur ist nicht akzeptiert Die Rolle der Systemarchitektur ist mehrheitlich akzeptiert Die operative Steuerung zur Durchsetzung der IT-Architektur ist nicht befriedigend Wie beurteilen Sie die Vernetzung des IT-Architekturmanagements mit anderen Funktionen der Bank? Eine Vernetzung der verschiendenen Funktionen in der Bank ist nicht notw endig IT-Architekturmanagement ist mit dem Risikomanagement ausreichend vernetzt IT-Architekturmanagement ist mit der Unternehmensentw icklung ausreichend vernetzt Nicht zutreffend Trifft teilw eise zu Trifft zu Nicht beurteilbar IT-Architekturmanagement ist mit dem Produktmanagement ausreichend vernetzt 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Gedruckt am Seite 84 von 95

85 Kernaussagen: Eine Vernetzung der Funktionen ist für 100 % der Interview-Partner notwendig Die Vernetzung des IT-Architekturmanagements mit dem Produktmanagement und der Unternehmensentwicklung ist für 80 % der Interview-Partner nicht ausreichend Die Vernetzung des IT-Architekturmanagements mit dem Risikomanagement wird unterschiedlich beurteilt Qualitative Zusammenfassung von Aussagen Für die Zusammenfassung der qualitativen Aussagen welche im Interview von mindestens 3 Personen erfasst werden konnten, wird die Methodik Aussage Erkenntnis Konsequenz (AEK) 81 verwendet. Die abgeleiteten Konsequenzen sind als Empfehlungen zu verstehen. Aussage Erkenntnis Konsequenz Das IT-Architekturmanagement muss die Werttreiber und/oder Kostentreiber der Bank kennen In der laufenden Projekten ist die IT-Architektur nicht spürbar Für ein wirkungsvolles IT- Architekturmanagement sind starke Kommunikationsfähigkeiten gefordert Die Präsentationsformen sind mehrheitlich zu technokratisch und detailgetreu und nicht managementgerecht Das IT-Architekturmanagement muss die Prioritäten besser auf die Ertrags- und Kostenziele der Bank ausrichten Die Aktivitäten des IT- Architekturmanagements sind fokussiert auf Konformitätsprüfungen und dadurch primär reaktiv. Eine proaktive Beratung der Projekte / Stakeholder findet nicht oder zuwenig statt Beratung, Akzeptanz und Durchsetzung fordern Kommunikationsfähigkeiten Die Präsentationsformen als Unterstützung für Akzeptanz und Durchsetzung der IT-Architektur werden von den Stakeholdern nicht Einsatz der vorhandenen Ressourcen nach wirtschaftlicher Optik Verstärkte Ausrichtung des IT- Architekturmanagements auf Beratungsaktivitäten, Abkehr von der «Polizisten-Rolle» Überprüfung des Mitarbeiterportfolios (in Abhängigkeit zur Optimierung der Organisationsform), Aufbau wenn notwendig Überprüfung der kommunikativen Fähigkeiten im Mitarbeiterportfolio Aufbau und Durchführung von Ausbildungen / Coachings Personeller Ausbau des IT- Architekturmanagements mit kommunikativen Persönlichkeiten Diskussion der vorhandenen Präsentationsformen (Bebauungspläne, Landkarten) mit Erklärung der Analyse- und Lesearten Einheitliche Sprache, Sprache an üb- 81 Die Methode wird in der ZKB nicht breit verwendet, der Autor kennt diese aus der militärischen Weiterbildung Gedruckt am Seite 85 von 95

86 Aussage Erkenntnis Konsequenz liche Begriffe in der ZKB angleichen bzw. Aufbau und Verbreitung einer einheitlichen «Architektursprache» in der ZKB Weniger Details in Landkarten, Informationen nur auf Anforderung anzeigen (Tooltipps, Layer verwenden) Managementgerechte Präsentationsform Vergleich von Aufgaben, Kompetenzen und Verantwortungen mit dem Mitarbeiterportfolio in qualitativer und quantitativer Optik Aufbau und Umsetzung eines Ausbildungsprogramms für IT-Architekten, basierend auf den Wertschöpfungsketten Organisationsform optimieren ein zuständiges Kompetenzzentrum schaffen Bankfachliche Kompetenz ist das A und O eines auf Fachseite akzeptierten IT- Architekturmanagements Die Organisationsform des IT- Architekturmanagements ist unnötig kompliziert akzeptiert oder nicht verstanden Beratungsleistungen auf Seite Fachbereich zu Prozessen und Applikationen sind erwünscht Die Aufteilung/Abgrenzung von Applikations- und Systemarchitektur ist schwer nachvollziehbar Gedruckt am Seite 86 von 95

87 Anhang B: Weitere Architektur-Modelle Im Verlauf der Erarbeitung der Diplomarbeit wurden nebst den beschriebenen Modellen verschiedene weitere Modelle für die Unternehmensarchitektur gefunden und analysiert. Auf einer vertiefte Beurteilung der folgenden Modelle wurde verzichtet: Modell Autor Kurzbeschreibung DoDAF Amerikanische Regierung Department of Defense Architecture Framework FEAF Federal Enterprise Architecture Framework Das Framework des amerikanischen Verteidigungsministeriums ist ein Rahmenwerk zur Entwicklung von System- und Unternehmensarchitekturen. Alle relevanten Regierungsstellen im DoD müssen DoDAF bei Entwicklungsarbeiten an Waffen oder IT-Systemen anwenden. Das DoDAF-Rahmenwerk beinhaltet verschiedene Sichten: All View (AV) Operational View (OV) Systems View (SV) Technical Standards View (TV) Das Rahmenwerk ist auf Grund seiner Herkunft für den Einsatz in einer Schweizer Universalbank nicht geeignet. Das Federal Enterprise Architecture ist eine Initiative des «Office of Management and Budget». Die Initiative soll die Auflagen des so genannten «Clinger-Cohen Act» erfüllen. Es bietet eine allgemeine Methodologie für den IT-Einsatz an. Es ist darauf ausgelegt, den Informationsaustausch mit anderen Regierungsstellen zu optimieren, Kosten zu senken und die Dienstleitungs-Qualität für die Bürger zu erhöhen. Aufgrund seiner Herkunft aus dem Regierungsumfeld ist FEAF für den Einsatz in einer Schweizer Universalbank nicht geeignet. RM-ODP ISO/IEEE Das Akronym «RM-ODP» steht für «Reference Model of Open Distributed Processing». Es handelt sich um eine ISO/IEEE-Norm, mit einem generischen Referenzmodell für verteilte, objektorientierte Systeme - es stellt aber auch ein für andere Systeme (wie ein Unternehmen) nutzbares Architektur-Modell zur Verfügung. Der Kern von RM- ODP besteht aus folgenden Teilen: Unternehmenssicht Informationssicht Gedruckt am Seite 87 von 95

88 Modell Autor Kurzbeschreibung Systemsicht Konstruktionssicht Technologiesicht Aufgrund der starken Orientierung am Themenbereich Software-Architektur und technische System- Architektur ist RM-ODP für den Einsatz in einer Schweizer Universalbank nicht geeignet. Gedruckt am Seite 88 von 95

89 Anhang C: Ergänzende Grafiken In diesem Anhang sind verschiedene ergänzende Grafiken zum IT-Architekturmanagement in der ZKB verfügbar. Bild A1: Informationen zu ZKBconnect in der Applikation AMF Bild A2: Applikationslandkarte im Ist-Zustand in AMF Gedruckt am Seite 89 von 95

90 Bild A3: Applikationslandkarte im Soll-Zustand in AMF Bild A4: Beschreibung einer Funktion «Kreditfinanzierung beantragen» in AMF Gedruckt am Seite 90 von 95