(IT) Service Management und (Enterprise) Architecture

Transkript

1 (IT) Service Management und (Enterprise) Architecture Ein akademischer Blick auf die Themen Run the Business und Change the Business Dr. Stephan Aier Projektleiter Institut für Wirtschaftsinformatik Universität St. Gallen Müller-Friedberg-Strasse 8, CH-9000 St. Gallen Tel: Fax:

2 Wer Was Wie Standort Ist lokalisiert an Stelle ist Teil von enthält Ablauforganisation Aufbauorganisation Organisationseinheit besetzt Rolle ist Teil von erfüllt Mitarbeiter führt aus ist verbunden mit Geschäftsprozess führt aus Aufgabe ist Teil von erzeugt, konsumiert Leistung Aktivität erzeugt/ konsumiert Geschäftsobjekt Informationsobj. ist Teil von ist Teil von Hintergrund Integrations- und IWI-HSG Kompetenzzentrum Integration Factory (CCIF) Management Unternehmensarchitektur Modellierung Analyse Planung Management Integration Integrations- Patterns Integrationsmethoden Modelle Methoden ADOben Workshops Projekte Schulungen Veröffentlichungen Netzwerk Konferenzen Seite 2

3 IT Service Management und Enterprise Architecture Bestandsaufnahme: IT Service Management (ITIL) und EA (TOGAF) in der Praxis St. Galler Sicht auf das Verhältnis IT Service Management, EA, ITIL und TOGAF Konsequenzen für das gemeinsame Thema: Business/IT Alignment Fazit und Ausblick Seite 3

4 Worum geht es? Kritische Erfolgsfaktoren für das IT/IS-Management The first, and most obvious, IS critical success factor is service 2. Communication (two-way) 3. IS Human Resources Repositioning the IS function from a limited automated back office to a more ubiquitous function involved in all aspects of the business. Quelle: Rockart, J.: The Changing Role of the Information Systems Executive - A Critical Success Factors Perspective, in: Sloan Management Review, 24, 1, 1982, pp Seite 4

5 Worum geht es? Es geht um Business/IT Alignement Unter den verschiedenen Integrationsausprägungen kommt der Integration zwischen fachlichen Architekturen und IT-Architekturen besondere Bedeutung zu. Quelle: Aier, S.; Winter, R.: Virtual Decoupling for IT/Business Alignment Conceptual Foundations, Architecture Design and Implementation Example, in: Business & Information Systems Engineering, 51, 2, 2009, pp Business/IT Alignment stellt seit mehreren Jahren über alle Unternehmens-Grössenklassen und über alle Branchen hinweg das Hauptthema der CIOs dar. Quelle: Luftman, J.; Kempaiah, R.; Rigoni, E.: Key Issues for IT Executives 2008, in: MISQ Executive, 8, 3, 2009, pp Seite 5

6 Welche Benefits werden von ITIL erwartet? Improvement of Hochstein et al., 2005 Potgieter et al Kießling et al Cater-Steel et al Cervone 2008 Service Quality X X X X X Standardization of Service Customer Satisfaction Return on Investment Reduction of Downtime Best Practice Financial Contribution Control Call Fix Rate X X X X X X X X X X X X X X Morale of IT Quelle: Mauricio Marrone, Lutz M. Kolbe: Providing More than Just Operational Benefits: An Empirical Research, Schumann, M., Kolbe, L., Breitner, M., Frerichs, A. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI 2010), Göttingen, , Universitätsverlag Göttingen, Göttingen, 2010, S X Seite 6

7 Wie die korrelieren ITIL-Reife und Erfolg: Innerhalb der IT und beim Business? Total realized benefits Total realized benefits backed by metrics Total realized benefits acknowledged by business Business/IT Alignment Level 1: Ad Hoc Processes are ad hoc and disorganized 0: trifft gar nicht zu 5: trifft vollständig zu Level 3: Defined Processes are documented and monitored for compliance Level 5: Optimized Good practices are followed and automated Quelle: Mauricio Marrone, Lutz M. Kolbe: Providing More than Just Operational Benefits: An Empirical Research, Schumann, M., Kolbe, L., Breitner, M., Frerichs, A. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI 2010), Göttingen, , Universitätsverlag Göttingen, Göttingen, 2010, S Seite 7

8 Unsere pauschale Wahrnehmung der ITIL-Praxis (Aus einem ITIL V2 Crash Course) Quelle: Steinberg, R.; Goodwin, M.: ITIL Crash Course, in: Infoworld, , 2006, pp Seite 8

9 Enterprise Architecture Management und TOGAF Architecture Development Method (ADM) TOAGF ist in unserer Wahrnehmung der Standard für EAM in der Praxis. Wir sehen aber auch, dass TOGAF weit davon entfernt ist Enterprise Architecture Management zu beschreiben auch nicht in TOGAF 9. Seite 9

10 EAM-Literatur: Häufig IT-fokussiert, selten Stakeholder- und Nutzungsorientiert [Aier/Schönherr 2004] [Aier/Schönherr 2005] [Aier/Schönherr 2006] [Aier/Schönherr 2007] ARIS [Scheer 1996] [Scheer 2001] [Scheer/Jost 2002] [Scheer/Schneider 2005] SEAM [Wegmann 2002] [Balabko/ Wegmann 2006] [Lê/Wegmann 2006] [Rychkova/ Wegmann 2006] [Ekstedt 2004] [Simonsson et al. 2006] [Lindström et al. 2006] [Johnson/Ekstedt 2007] MEMO [Frank 1994] [Frank 1995] [Frank 1999a] [Frank 1999b] [Frank 2002] [Jonkers et al. 2003] [Jonkers et al. 2004] [Lankhorst et al. 2004] [Lankhorst 2005] [van der Torre et al. 2006] SOM [Ferstl et al. 1994] [Ferstl/Sinz 1995] [Ferstl/Sinz 1996] [Ferstl/Sinz 2005] [Ferstl/Sinz 2006] [Leist 2004] [Winter 2005] [Braun/Winter 2005] [Bucher et al. 2006] [Winter/Fischer 2006] [Braun/Winter 2007] [Fischer/Winter 2007] [Fischer et al. 2007] [Bernard 2005] [Bernard 2006] [Ross 2003] [Ross 2006] [Ross/Beath 2006] [Ross et al. 2006] [Keller 2000] [Keller 2001] [Keller 2002] [Keller 2005] [Keller 2006] TOGAF [The Open Group 2001] [The Open Group 2003] [The Open Group 2007] Verständnis der EA Strategieebene Organisationsebene Integrationsebene Softwareebene Infrastrukturebene Herkunft Organisationslehre Architekturgestaltung Prozessgestaltung Systementwicklung Organisationslehre Systemtheorie IT-Architektur Systementwicklung Wissensmanagement IT-Architektur Organisationslehre Business Engineering ERP, Governance Management Science IT-Architektur IT-Architektur Stakeholder/ Zielgruppe IT, Fachbereiche Fachbereiche IT, Fachbereiche IT IT, Fachbereiche IT, Fachbereiche IT IT, Fachbereiche, Geschäftsleitung IT, Fachbereiche, Geschäftsleitung IT, Fachbereiche, Geschäftsleitung IT, Fachbereiche, Geschäftsleitung IT Abbildung der EA Notation eepk (modifiziert) eepk eigene Modellierungssprache - eigene Modellierungssprache eigene Modellierungssprache Archimate SOM EA3 Cube Keine Keine Keine Toolunterstützung EA Builder ARIS Toolset SEAMCad - MEMO Center verschiedene verschiedene [Ferstl et al. 1994] ADOben Living Enterprise Keine Keine Keine Nutzung der EA Dokumentation und Analyse Dokumentation und Planung Basis für Entscheidungsfindung Business/IT- Integration Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Dokumentation und Planung Analyse der EA Analysen auf Basis der EA Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S Seite 10

11 EAM-Praxis (1): Fachliche Schwerpunkte wichtig aber nicht umgesetzt Geschäftsprozesse Schnittstellen Produkte/Dienstleistungen Strategische Vorhaben / Projekte Applikationen Strategische Unternehmensziele Applikationsdomänen Interaktion mit Kunden Informationsflüsse Fachliche Services Datenstrukturen Softwarekomponenten Software-Plattformen IS-Funktionalitäten Informationsobjekte Rollen und Verantwortlichkeiten Organisationseinheiten Marktsegmente Vertriebskanäle Hardwarekomponenten Netzwerkkomponenten Interaktion mit Zulieferern Standorte Wichtigkeit Umsetzungsgrad unwichtig/ nicht existent teilweise wichtig/ partiell vorhanden mehrheitlich wichtig/ definiert wichtig/ kontrolliert sehr wichtig/ optimiert Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S Seite 11

12 EAM-Praxis (2): Viele Analysen und Nutzungsszenarien wichtig, wenige umgesetzt Schnittstellenanalyse Abdeckungsanalyse Planung IT Strategie IT-Business-Alignment Abhänigkeitsanalyse Prozessoptimierung Architekturkonformität von Projekten Heterogenitätsanalyse Management des Anwendungsportfolios Qualitätsmanagement Wichtigkeit Umsetzungsgrad unwichtig/ nicht existent teilweise wichtig/ partiell vorhanden mehrheitlich wichtig/ definiert Security Management wichtig/ kontrolliert sehr wichtig/ optimiert Business-Continuity-Planning Planung Unternehmensstrategie IT-Konsolidierung Standardsoftware-Einführung Compliance Management Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S Wichtigkeit Umsetzungsgrad Sourcing-Entscheidungen unwichtig/ nicht existent teilweise wichtig/ partiell vorhanden mehrheitlich wichtig/ definiert wichtig/ kontrolliert sehr wichtig/ optimiert Seite 12

13 IT Service Management und Enterprise Architecture Bestandsaufnahme: IT Service Management (ITIL) und EA (TOGAF) in der Praxis St. Galler Sicht auf das Verhältnis IT Service Management, EA, ITIL und TOGAF Konsequenzen für das gemeinsame Thema: Business/IT Alignment Fazit und Ausblick Seite 13

14 Positionierung von ITIL und TOGAF strategisch, ganzheitlich, change TOGAF IT-fokussiert ITIL Ausgeglichen zwischen Business/IT operativ, detailliert, run Seite 14

15 Heisst Business/IT Alignment das Business mit IT glücklich zu machen? Business/IT Alignment im Grossen IT Effizienz Treiber: IT-/Unternehmensarchitektur, Effizienz Plattformmigration Applikationskonsolidierung Abschaltung App Z Neues schönes CRM Schnelle kleine Geschäfts- Anwendung App X Treiber: Fach-/Funktionsbereiche, Time-to-Market, Effektivität App Y App Z Geschäftsnutzen Effizienz im Grossen lässt sich nur dauerhaft nur durch Konsistenz, Konsolidierung und Vereinheitlichung also Infrastruktur schaffen. Quelle: Hagen, C., Integrationsarchitektur der Credit Suisse, in: Aier, S., Schönherr, M. (Hrsg.), Enterprise Application Integration - Flexibilisierung komplexer Unternehmensarchitekturen, GITO-Verlag, Berlin, 2003, S Seite 15

16 Architekturziele bauen aufeinander auf und haben Tradeoffs Ohne Zielbildung kein konsequentes Management! Agilität und Flexibilität sind die Königsdisziplinen dafür müssen aber die (mühsamen) Hausaufgaben gemacht sein. Agilität und Innovation Gute Vorbereitung auf zukünftige, noch nicht spezifizierbare Änderungsbedarfe Flexibilität Bessere Anpassbarkeit an heute schon spezifizierbare Anpassungsbedarfe Vereinfachung, Konsolidierung Schaffung feingranularer, wiederverwendbarer Funktionalitätsbündel Ziel: Mehrfachverwendung von Funktionalitäten Transparenz Aktualisierung und Vervollständigung veralteter, lückenhafter, inkonsistenter Dokumentationen Ziel: Messbarkeit von Nicht-Alignment, von fehlender Abdeckung fachlicher Bedarfe, nicht benötigter IT-Funktionalitäten Seite 16

17 Es gibt genügend Partial- und Detailarchitekturen Es braucht eine breite und flache Gesamtsicht Unternehmensarchitektur Unternehmensstrategie Datenstrukturen Software- Komponenten Server und Plattformen Märkte Prozesse Detail-Strukturen Unternehmensarchitektur sollte die Abhängigkeiten von Business-to-IT transparent machen. Dies wird nur dann nachhaltig gelingen, wenn man sich nicht in Details verliert. Seite 17

18 Outside-In vs. Inside-Out Warum nicht einfach TOGAF nehmen? Geschäftsleitung Strat. Optionen Projekt Selekt. Future Screening Kooperationsmgt. Controlling Informatik Bus. Inform. Mgt. Op. Risk Mgt. Architek. SignOn Appl. Portfolio Mgt. IT Alignment Service Mgt. Incident Mgt. EA Unternehmensentwicklung Schutzobj- Inventar Prozess-Arch Proj. Scanning Metadatenmgt. Business Continuity Planning Betrieb Compliance ProjektMgmt Outside-in ist der anstrengendere aber auch nachhaltigere (weil partizipative) Weg zur Transparenz. Seite 18

19 IT Service Management und Enterprise Architecture Bestandsaufnahme: IT Service Management (ITIL) und EA (TOGAF) in der Praxis St. Galler Sicht auf das Verhältnis IT Service Management, EA, ITIL und TOGAF Konsequenzen für das gemeinsame Thema: Business/IT Alignment Fazit und Ausblick Seite 19

20 Die Alignment-Architektur entkoppelt fachliche und IT-Architekturen nn Quartale Weiterentwicklung der Strategie Geschäftsnetzwerkmodelle Kundenprozessmodelle Leistungsmodelle Zielsystem Strategieebene Softwareebene Organisationsebene Alignmentebene Infrastrukturebene nn Monate Business und IT sind unterschiedlich! z.b. in ihrer Änderungsfrequenz. Es braucht eine strukturelle Antwort für ein nachhaltiges Business/IT Alignment nn Jahre * Gestalten = Prozess der Erst- und Weiterentwicklung Weiterentwicklung der Organisation Prozesslandkarten Prozessmodelle Aufbauorganisationsmodelle Informationslandkarten Permanentes Business/IT Alignment Domänenmodelle Applikationslandschaften Capabilities und fachliche Services Weiterentwicklung der Software Softwarekomponenten und Software-Services Datenmodelle Weiterentwicklung der IT-Infrastruktur Plattforminfrastruktur Netzwerkinfrastruktur Seite 20

21 Business Engineering: Transformation ist vielgestaltig Alignment: Mehr als nur fachlich getriebene Projekte Strategieebene Softwareebene Organisationsebene Alignmentebene Infrastrukturebene Fachlich getriebene Projekte (Top-down) Technisch getriebene Projekte (Bottom-up) Alignment-Projekte Vereinfachungs-/ Flexibilisierungsprojekte (SOA) Vernetzungsprojekte (Fast) jedes Veränderungsprojekt ist anders und braucht daher eine andere informatorische und methodische Unterstützung. Seite 21

22 Komponenten der Alignment-Architektur Welche IT-Artefakte realisieren welche Capabilities/Services und welche Capabilities braucht es für welche Geschäftsprozesse? Welche organisations- und realisierungsunabhängigen Schnitte sollten gewährleistet sein? Wo ist Serviceorientierung sinnvoll, wo nicht? Wo kann standardisiert werden, wo nicht? Es braucht die Bereitschaft, in Services zu denken, die nicht Software sind. Prozessservice 1.1 fachliche Architektur Prozess P1 Domäne D1 Applikation A1.1 A1.2 Fachlicher Service Softwareservice 1.1 Prozessservice 1.2 Alignment-Architektur Fachlicher Service Softwareservice 1.2 Prozessservice 1.3 Prozessservice 1.4 Capability Traditionell gestaltetes Softwaresystem Softwaresystem S1 IT-Architektur P2 Aktivität 2.1 Software- serice 2.1 S2 D2 A2.1 Fachlicher Service Quelle: Aier, S.; Winter, R.: Virtuelle Entkopplung von fachlichen und IT-Strukturen für das IT/Business Alignment Grundlagen, Architekturgestaltung und Umsetzung am Beispiel der Domänenbildung, in: Wirtschaftsinformatik, 51, 2, 2009 Seite 22

23 Entwicklungsrichtungen Positionierung von ITIL und Enterprise Architecture strategisch, ganzheitlich, change Enterprise Architecture IT-fokussiert ITIL Ausgeglichen zwischen Business/IT operativ, detailliert, run Seite 23

24 Unternehmen sind nicht-lineare Systeme, sie benötigen nicht-lineare Optimierungen Muster wie ein neues Requirement führt zu einer neuen Applikation stellen lokale Sichtweisen dar welche für die lokale Umsetzung wichtig sind aber auf lange Sicht destruktiv wirken Auf lange Sicht braucht es zusätzlich die Sicht auf das Grosse Ganze Nur so lassen sich globale Optima finden Seite 24

25 Um das grosse Ganze zu managen braucht es eine Reihe zum Teil anspruchsvoller Produkte Kernprodukte Transparenz: Ein Bild vom grossen Ganzen. Konsistenz und Konsolidierung herstellen: Welche Quickwins für Konsolidierung und Kostensenkung gibt es? Konsistenz und Konsolidierung sichern: Überblick über wichtige Projekte und Abstimmung, durch Prinzipien/Richtlinien/Standards und Vorstrukturierung, durch Domänen- /Capabilitymodelle Umsetzung begleiten: Durch aktive Mitarbeit der Architekten (!) in den Projekten. Kompetenz beweisen: Geschätzter Ansprechpartner für Entscheidungen sein Anspruchsvollere Produkte Laufende und proaktive Identifikation von Verbesserungsmöglichkeiten Bereitstellung von verbindlichen EA-Roadmaps Festschreibung einer gelebten EA-Governance Wichtige Ansatzpunkte Nachhaltige Transparenz Die richtige Qualifikation von Architekten und Nicht-Architekten Nicht alles auf einmal wollen Seite 25

26 Was bedeutet das für das Verhältnis von EA und ITIL? divide et impera strategisch, ganzheitlich, change Enterprise Architecture IT-fokussiert ITIL Ausgeglichen zwischen Business/IT operativ, detailliert, run Every successful process will grow until it dies under it s own weight Quelle: Ivar Jacobson. Seite 26

27 IT Service Management und Enterprise Architecture Bestandsaufnahme: IT Service Management (ITIL) und EA (TOGAF) in der Praxis St. Galler Sicht auf das Verhältnis IT Service Management, EA, ITIL und TOGAF Konsequenzen für das gemeinsame Thema: Business/IT Alignment Fazit und Ausblick Seite 27

28 Fazit IT-Services welche die realen Bedürfnisse des Business treffen sind der kritische Erfolgsfaktor der IT Diese Bedürfnisse können jedoch oft nicht präzise formuliert werden, ändern sich über Zeit, mit oft viel zu hoher Dynamik, darum sehen wir drei Stossrichtungen: Stossrichtung 1: Mehr Gesamtsicht und besseres Alignment Unterstützung bei der Abstimmung von Strategie, Organisation und IT durch Nachführung und Analyse der Abhängigkeiten zwischen den Schlüsselelementen der verschiedenen Ebenen so, dass sich Änderungen konsistent umsetzen und strategische Optionen fundiert diskutieren lassen. Stossrichtung 2: Bessere Anpassbarkeit im Grossen Identifikation anpassungskritischer Kernstrukturen auf Organisations-, Alignment- und Softwareebene sowie serviceorientierte Restrukturierung dieser Kernstrukturen. Stossrichtung 3: Professionalität im Detail Gestaltung, Betrieb und Management der Strukturen im Detail muss professionell gestaltet sein Best Practices sind vorhanden Messbarkeit ist die Voraussetzung für Management Diese Stossrichtungen sind im Kern verschieden und benötigen darum auch unterschiedliche Ansätze. Ab einem gewissen Integrationsgrad überwiegen die Integrationskosten den Integrationsnutzen Seite 28

29 Ausblick Theoretisches Verständnis erlangen ist das eine Impact generieren ist manchmal etwas anderes (aber komplementäres) Darum arbeiten wir in zwei Richtungen Erweiterung des Body of Knowledge in unserer Community (Beispiele: EA- Planung, Geschäftsprozesssteuerung, prinzipiengeleitetes Design) Anwendung, Validierung und Verbesserung des Body of Knowledge (Beispiele: Aufbau von EA-Programmen, Tooleinsatz, Wiederbelebung von Architektur) IWI-HSG hat dafür eine solide Basis geschaffen durch das Business Engineering Framework, Methoden und Modelle für Unternehmensarchitekturmanagement und serviceorientierte Restrukturierung, Werkzeuge für Unternehmensarchitekturmanagement Business-to-IT : ADOben sowie die Plattform und das Netzwerk für professionellen Austausch und Weiterentwicklung der Themen: Kompetenzzentrum Integration Factory. Seite 29

30 Kontakt Dr. Stephan Aier Seite 30

31 Regelmässige Veranstaltungen über das F&E-Netzwerk hinaus Dreimal jährlich: St. Galler Anwenderforum nächste Veranstaltung am 31. Mai 2010: Informationslogistik und Business Intelligence Alle zwei Jahre: Konferenz DW/EA /10. November 2010 Informationen und Anmeldung: Seite 31

32 Zum Nachlesen Aktuelle Bände der Business Engineering- Reihe Winter, R. (Hrsg.): Management von Integrationsprojekten, Berlin etc.: Springer, erscheint Mai 2009 Dinter, B.; Winter, R. (Hrsg.): Integrierte Informationslogistik, Berlin etc.: Springer 2008 EA-Forschungs-Web Sites CC IF: ADOben: Ausgewählte deutschsprachige Aufsätze (meist PDF-Download auf oder Aier, S.; Riege, C.; Winter, R: Unternehmensarchitektur Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S Fischer, R.; Winter, R.: Ein hierarchischer, architekturbasierter Ansatz zur Unterstützung von IT-Business Alignment, in: Oberweis, A. et al. (Hrsg.): eorganisation Service-, Prozess-, Market-Engineering, Band 2, Karlsruhe: Universitätsverlag Karlsruhe 2007, S Hafner, M.; Schelp, J.; Winter, R.: Architekturmanagement als Basis effizienter und effektiver Produktion von IT- Services, in: HMD - Praxis der Wirtschaftsinformatik, 41, 237, 2004, S Winter, R.; Schelp, J.: Dienst-Orientierung im Business Engineering, HMD 241 (2005), S Aier, S.; Winter, R.: Virtuelle Entkopplung von fachlichen und IT-Strukturen für das IT/Business Alignment Grundlagen, Architekturgestaltung und Umsetzung am Beispiel der Domänenbildung, in: Wirtschaftsinformatik, 51, 2, 2009, S Seite 32