Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen >>Business-to-IT

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner Weitere Bände siehe www.springer.com/series/4...

Author: Robert Winter

21 downloads 1737 Views 10MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner

Weitere Bände siehe www.springer.com/series/4436

Robert Winter

Business Engineering Navigator Gestaltung und Analyse von Geschäftslösungen “Business-to-IT”

Unter Mitarbeit von Dr. Antonia Albani, Dr. Anke Gericke und Bettina Gleichauf

1C

Prof. Dr. Robert Winter Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8 9000 St. Gallen Schweiz [email protected]

ISSN 1616-0002 ISBN 978-3-642-15912-1 e-ISBN 978-3-642-15913-8 DOI 10.1007/978-3-642-15913-8 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2011 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort Zur Entwicklung und Weiterentwicklung des St. Galler Ansatzes des Business Engineering tragen seit Anfang der 1990er Jahre nicht nur die Forschenden am Institut für Wirtschaftsinformatik der HSG bei. Ein praxistauglicher Ansatz für die Analyse und Gestaltung von Geschäftslösungen bedarf der Unterstützung durch das Management und die Mitarbeitenden vieler Partner- und Anwenderunternehmen, um die Anforderungen richtig zu erfassen und den Ansatz immer wieder verproben und weiterentwickeln zu können. Nicht zuletzt hilft die Aus- und Weiterbildung in Business Engineering im Rahmen von Master- und ExecutiveStudiengängen in St. Gallen und anderswo nicht nur dabei, den Ansatz didaktisch aufzubereiten, Demonstrations-Fallstudien zu entwickeln und ein Unterstützungswerkzeug zu entwickeln; Die kritischen Diskussionen mit Lernenden, das wiederholte Üben und die Business Engineering Community leisten auch einen wichtigen Beitrag zur Weiterentwicklung. Der Wechsel von Forschenden, Praxispartnern und Studierenden an andere Orte sorgt schließlich auch dafür, dass Business Engineering zwar ein St. Galler Ansatz ist, aber unterdessen auch an vielen anderen Orten praktiziert, gelehrt und weiterentwickelt wird. Im Rahmen der Buchreihe „Business Engineering“ sind seit 2000 viele Bände zu den verschiedensten Spezialthemen des Business Engineering erschienen. Allerdings fehlte bisher ein gesamthafter Überblick über die Analyse- und Gestaltungsmethodik für Geschäftslösungen auf Strategie-, Organisations- und IT-Ebene in ihrer Gesamtheit. Der vorliegende Band schließt diese Lücke. Das Buch ist in fünf Kapitel gegliedert. In Kapitel 1 werden die Positionierung von Business Engineering (BE) und Business Engineering Navigator (BEN) konzeptionell beschrieben. Die Modellierung von Geschäftslösungen, d.h. der Gegenstand von BEN, wird in Kapitel 2 im Detail beschrieben. Neben dem GesamtMetamodell des BE werden auch alle Ebenenmodelle und Einzel-Modelltypen spezifiziert. Kapitel 3 widmet sich dem Modellieren selbst, d.h. dem Vorgehen zur Konstruktion von Geschäftslösungen. Neben grundsätzlichen Ausführungen zum Methodenengineering werden die Vorgehensmodelle für wichtige BE-Projekttypen vorgestellt. Das längste Kapitel 4 beschreibt die in verschiedenen Vorgehensmodellen wiederverwendeten acht BEN-Komponenten ausführlich. Während die Darstellungen der ersten vier Kapitel absichtlich werkzeugneutral sind, wird im 5. Kapitel die exemplarische Unterstützung von BEN mit einem Modellierungswerkzeug beschrieben. Sowohl für die werkzeugneutrale wie auch für die werkzeugspezifische Darstellung von BEN wird durchgehend das Anwendungsbeispiel einer Reiseveranstaltungsplattform benutzt. Ein Buchprojekt und insbesondere eines, dass eine komplexe Materie umfassend und konsistent darzustellen versucht, stellt parallel zum „Tagesgeschäft“ von grundlagen- und angewandter Forschung, Lehre/Weiterbildung und Management eine spezielle Herausforderung dar. Dieses Buch wurde lange geplant und in zwei intensiven Arbeitsphasen Anfang 2009 sowie Mitte 2010 umgesetzt. Seine Kon-

VI

Vorwort

zeption und Umsetzung wäre ohne die Mitarbeit von Dr. Antonia Albani, Dr. Anke Gericke und Bettina Gleichauf nicht denkbar gewesen, für die ich mich an dieser Stelle herzlich bedanke. Zusammen mit Dr. Anke Gericke habe ich in den ersten vier Monaten des Jahres 2009 das Buch konzipiert und die ersten drei Kapitel geschrieben. Zusammen mit Dr. Antonia Albani habe ich Mitte 2010 Kapitel 4 konzipiert und die ersten vier Kapitel miteinander integriert. Bettina Gleichauf steuerte Kapitel 5 zur Werkzeugunterstützung von BEN bei. Dr. Antonia Albani übernahm auch die Endredaktion des Gesamtmanuskripts. Die modell- und methodenbasierte Analyse und Gestaltung von Geschäftslösungen ist transdisziplinär, da diese Aufgabe betriebswirtschaftliches Fachwissen, systematisches Konstruieren und nicht zuletzt auch Sozial- und Kommunikationskompetenz erfordert. Business Engineering ist deshalb immer auch Teamarbeit. Ich freue mich, dass auch die Konzeption und Umsetzung dieses Buchs ein erfolgreiches Beispiel für Teamarbeit darstellt.

St. Gallen im August 2010

Prof. Dr. Robert Winter

Inhaltsverzeichnis Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

V

Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII 1

Notwendigkeit und Positionierung einer betriebswirtschaftlichen Konstruktionslehre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anke Gericke und Robert Winter

1

2

Geschäftslösungen – Gegenstand der Analyse und Gestaltung mit BEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Anke Gericke und Robert Winter

3

BEN-Gestaltungsmethodik für Geschäftslösungen . . . . . . . . . . . . . . . . 55 Anke Gericke und Robert Winter

4

BEN-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Antonia Albani und Robert Winter

5

Werkzeugunterstützung für die Analyse und Gestaltung von Geschäftslösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Bettina Gleichauf

85

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Abbildungsverzeichnis Abb. 1. Abb. 2. Abb. 3. Abb. 4. Abb. 5. Abb. 6. Abb. 7. Abb. 8. Abb. 9. Abb. 10. Abb. 11. Abb. 12. Abb. 13. Abb. 14. Abb. 15. Abb. 16. Abb. 17. Abb. 18. Abb. 19. Abb. 20. Abb. 21. Abb. 22. Abb. 23. Abb. 24. Abb. 25. Abb. 26. Abb. 27. Abb. 28. Abb. 29. Abb. 30. Abb. 31. Abb. 32. Abb. 33. Abb. 34.

Einordnung von BEN ins Business Engineering .................... 5 Zusammenhang zwischen Methoden und (Referenz-)Modellen (Winter et al. 2009) .............................. 7 BEN-Dimension „Fokus“ ....................................................... 8 BEN-Dimension „Aggregationsgrad“..................................... 9 BEN-Dimension „Spezifität“ ................................................ 10 Einordnung des Business Engineering Navigator................. 11 BEN-Metamodell (1. Abstraktionsebene)............................. 16 BEN-Metamodell (2. Abstraktionsebene)............................. 17 BEN-Metamodell (vollständig)............................................. 19 BEN-Metamodell (verkürzte Darstellung)............................ 21 BEN-Architekturebenen........................................................ 23 Lebenszyklen auf Strategie-, Organisations- und IT-Ebene . 24 IT/Business Alignment-Architektur für die entkoppelnde Zuordnung von Organisationsebene und IT-Ebene .............. 26 BE-Ebenen ............................................................................ 27 Mögliche weitere Umsetzungsebenen (neben der IT-Ebene)28 BEN-Metamodellausschnitt der Strategieebene ................... 30 Metamodellausschnitt Geschäftsnetzwerkmodell................. 32 Metamodellausschnitt „Geschäftspartnerprozessmodell“..... 34 Metamodellausschnitt „Produkt-/Servicemodell“................. 35 Metamodell „strategische Positionierung“............................ 36 Metamodellausschnitt „Zielsystem“ ..................................... 37 BEN-Metamodellausschnitt der Organisationsebene ........... 38 Metamodellausschnitt „Prozesslandkarte“............................ 40 Prozesskontextdiagramm ...................................................... 41 Metamodellausschnitt „Prozessleistungsmodell“ ................. 42 Metamodellausschnitt „Steuerungsmodell“ .......................... 43 Metamodellausschnitt „Ablaufmodell“................................. 44 Metamodellausschnitt „Aufbauorganisationsmodell“ .......... 45 Metamodellausschnitt „Informationsmodell“ ....................... 46 BEN-Metamodellausschnitt der IT/Business AlignmentEbene..................................................................................... 47 BEN-Metamodellausschnitt der Software- und ITInfrastrukturebene ................................................................. 50 Metamodellausschnitt „Softwarearchitektur“ ....................... 52 Metamodellausschnitt „Datenarchitektur“ ............................ 53 Metamodellausschnitt „IT-Infrastruktur“.............................. 54

X

Abbildungsverzeichnis

Abb. 35. Abb. 36. Abb. 37. Abb. 38. Abb. 39. Abb. 40. Abb. 41. Abb. 42. Abb. 43. Abb. 44. Abb. 45. Abb. 46. Abb. 47. Abb. 48. Abb. 49. Abb. 50. Abb. 51. Abb. 52. Abb. 53. Abb. 54. Abb. 55. Abb. 56. Abb. 57. Abb. 58. Abb. 59. Abb. 60. Abb. 61. Abb. 62. Abb. 63.

Metamodell einer Methode (in Anlehnung an Gutzwiller 1994) ..................................................................................... 56 Projekttypen, Kontexttypen und Situationen ........................ 60 Prozess der situativen Methoden-Komposition (Brinkkemper 1996) ........................................................................ 62 Erweitertes Metamodell einer Methode (Bucher u. Winter 2008) ..................................................................................... 63 Bezugsrahmen der Referenzmodellierung (Fettke u. Loos 2004) ..................................................................................... 64 Prozesse der Referenzmodellierung (Fettke u. Loos 2005) .. 66 Ordnungsrahmen der Adaptionsmechanismen (Becker et al. 2004) ................................................................................ 67 Grundsätzliche Projekttypen in BEN .................................... 73 Vorgehensmodell auf Strategieebene.................................... 75 Vorgehensmodell auf Organisationsebene............................ 76 Vorgehensmodell Prozess-Detailentwurf (IMG 1997b) ....... 77 Vorgehensmodell für vertikales Alignment .......................... 82 Vorgehensmodell für Servicedesign auf der IT/Business Alignment-Ebene (in Anlehnung an Dodd 2005) ................. 83 BEN-Modelltypen und besonders wichtige Zusammenhänge ..................................................................................... 86 BEN-Komponenten............................................................... 89 Beispiele für Konfigurationen von BEN-Komponenten....... 92 Konfiguration von BEN-Komponenten für verschiedene BE-Projekttypen.................................................................... 95 Beispiel Smart Travel............................................................ 96 Geschäftsnetzwerkmodell im Beispiel Smart Travel............ 99 Kundenprozessmodell für Leistungsbeziehung .................. 101 Zusammenführung des Leistungsprogramms im Beispiel Smart Travel........................................................................ 102 Ziellandkarte im Beispiel Smart Travel .............................. 111 Identifikation von Leistungsprozessen im Beispiel Smart Travel .................................................................................. 115 Prozessführungsgrößen im Beispiel Smart Travel.............. 116 Qualitätsprofil eines Prozess-Output im Beispiel Smart Travel........................................................................ 117 Ablaufdiagramm eines (Teil-)Prozesses im Beispiel Smart Travel........................................................................ 119 Stellenbeschreibung im Beispiel Smart Travel ................... 122 Organigramm im Beispiel Smart Travel ............................. 124 Kardinalitätsbeziehungen.................................................... 129


Abb. 64. Abb. 65. Abb. 66. Abb. 67.

Abb. 68. Abb. 69. Abb. 70. Abb. 71. Abb. 72. Abb. 73. Abb. 74. Abb. 75. Abb. 76. Abb. 77 Abb. 78. Abb. 79. Abb. 80. Abb. 81. Abb. 82. Abb. 83. Abb. 84. Abb. 85. Abb. 86. Abb. 87. Abb. 88. Abb. 89. Abb. 90. Abb. 91. Abb. 92. Abb. 93.

XI

ER-Diagramm in traditioneller Notation ............................ 130 ER-Diagramm in ssADM-Notation .................................... 130 Multidimensional beschriebenes Faktum (Schelp 2000) .... 133 Seriationsanalyse im Rahmen von Business Systems Planning (in Anlehnung an das Beispiel aus Heinrich 1996) ................................................................................... 139 Wirkung der Seriationsanalyse ........................................... 140 Zuordnungsnetz zwischen Softwaresystemen und Prozessen (in Anlehnung an Aier 2006) ............................ 141 Identifikation von Domänen-Kandidaten durch Zerlegung des Zuordnungsnetzes (in Anlehnung an Aier 2006)......... 141 Capability-Identifikationsgraph vor der Optimierung (Albani et al. 2008) ............................................................. 143 Capability-Identifikationsgraph nach dem Durchlauf des Optimierungsalgorithmus (Albani et al. 2008) ................... 144 „Gewachsene“ Applikationslandschaft (Winter 2006) ....... 147 „Architektierte“ Applikationslandschaft (Winter 2006) ..... 148 Fokussierung BEN und ADOben........................................ 161 Dialog Modell anlegen........................................................ 163 Modellierungsoberfläche mit Toolbox................................ 164 Notebook Leistungskomponente......................................... 164 Modellreferenz: Verfeinerung von Prozessen..................... 165 Modellelementreferenz: Geschäftsfeld und Organisationseinheit............................................................ 166 Modellelementreferenz: Referenzierter Prozess in einer Informationslandkarte ......................................................... 167 Modellexplorer mit Modellordnerstruktur .......................... 168 Realisierung der BEN-Komponenten durch ADObenModelltypen ........................................................................ 169 Beziehungen zwischen ADOben-Modelltypen................... 169 Beispiel Geschäftsnetzwerkmodell ..................................... 171 Geschäftspartner (Referenz) im Geschäftspartnerprozessmodell........................................... 172 Beispiel Geschäftspartnerprozessmodell ............................ 173 Beispiel Produktmodell....................................................... 174 Strategische Positionierung eines Geschäftsfelds ............... 174 Beispiel Ziellandkarte ......................................................... 175 Referenz zu Zielen, die ein Prozess unterstützt .................. 175 Referenz zu Produkten, die ein Prozess behandelt.............. 176 Beispiel für Process Compass ............................................. 176

XII


Abb. 94. Abb. 95. Abb. 96. Abb. 97. Abb. 98. Abb. 99. Abb. 100. Abb. 101. Abb. 102. Abb. 103. Abb. 104. Abb. 105. Abb. 106. Abb. 107.

Prozesslandkarte mit spezialisierten und detaillierten Prozessen............................................................................. 177 Beispiel Verfeinerung der Aufbauorganisation .................. 178 Verantwortliche Organisationseinheit in Prozesslandkarte 179 Verantwortlicher Geschäftsbereich des Produkts “Städtereise“........................................................................ 179 Beispiel Informationsmodell............................................... 180 Beispiel Informationslandkarte ........................................... 180 Beispiel Domäne in Applikationslandkarte ........................ 182 Beispiel Softwarelandkarte ................................................. 183 Referenz zu Datenobjekten in einem Informationsobjekt... 183 Beispiel Environment......................................................... 185 Listenauswertung Produkte................................................ 187 Zwei-dimensionale Analyse Prozesse und Produkte .......... 190 Zwei-dimensionale Analyse Prozesse und Produkte (Detailansicht Prozesshierarchie)........................................ 190 Drei-dimensionale Auswertung Produkte/Applikationen/Prozesse ....................................... 191

Abkürzungsverzeichnis ARIS BCI BE BEN BSP CMDB EAI EPK ER LDAP SOA UA UML

Architektur integrierter Informationssysteme Business Collaboration Infrastructure Business Engineering Business Engineering Navigator Business Systems Planning Configuration Management Database Enterprise Application Integration Ereignisgesteuerte Prozesskette Entity Relationship (z. B. ER-Diagramm, ER-Modell) Lightweight Directory Access Protocol Service Oriented Architecture Unternehmensarchitektur Unified Modeling Language

1 Notwendigkeit und Positionierung einer betriebswirtschaftlichen Konstruktionslehre Anke Gericke und Robert Winter

Das erste Kapitel widmet sich der Notwendigkeit und Positionierung einer betriebswirtschaftlichen Konstruktionslehre. Im ersten Abschnitt werden Business Engineering und Business Engineering Navigator definiert. Zwei weitere Abschnitte beschreiben die Grundkonzeption des Business Engineering Navigator.

1.1 Business Engineering und Business Engineering Navigator „Run the Business“ vs. „Change the Business“ Das Unternehmensmodell des neuen St. Galler Managementmodells versteht Organisationen als komplexe soziale Systeme, die unter den verschiedensten Blickwinkeln verstanden und gestaltet werden müssen. Einige dieser Blickwinkel sind einfach verständlich. So ist z. B. naheliegend, dass Anspruchsgruppen wie Kapitalgeber, Kunden, Mitarbeitende, Öffentlichkeit, Staat, Lieferanten und Mitbewerber sich jeweils für spezifische Aspekte von „Unternehmen“ interessieren (z. B. Ertrag, Risiko, gesellschaftlicher Nutzen, ökologische Nachhaltigkeit). Auch die Sicht auf Unternehmen als System vernetzter Management-, Geschäfts- und Unterstützungsprozesse ist naheliegend. Hinsichtlich anderer Blickwinkel wie z. B. Interaktionsthemen „Ressourcen“, „Normen/Werte“ und „Anliegen/Interessen“ oder Ordnungsmomente „Strategie“, „Strukturen“ und „Kultur“ sei auf die entsprechende Literatur verwiesen (vgl. Dubs et al. 2004). Für das Business Engineering ist ein weiterer Blickwinkel interessant, nämlich der sog. Entwicklungsmodus. Als grundlegende Entwicklungsmodi werden im St. Galler Managementmodell „Optimierung“ und „Erneuerung“ unterschieden (in Anlehnung an RüeggStürm 2002). Das heißt, dass bei der Gestaltung von Unternehmen oder Unternehmensteilen unterschieden werden muss, ob bestehende Strukturen und Prozesse inkrementell optimiert werden oder ob eine mehr oder weniger grundlegende Erneuerung von Strukturen und Prozessen im Mittelpunkt der Betrachtung steht. Die Unterscheidung von Optimierung und Erneuerung findet sich in der Wirtschaftspraxis auch im Begriffspaar „Run the Business“ vs. „Change the Business“. Die Unterscheidung zwischen „Run the Business“ und „Change the Business“ ist nicht immer trennscharf. Wie die Umschreibung „mehr oder weniger fundamentaler Wandel“ bereits andeutet, kann ein Veränderungsvorhaben von einigen Beteiligten bzw. Betroffenen durchaus noch als „inkrementell“ verstanden wer-

R. Winter, Business Engineering Navigator, DOI 10.1007/978-3-642-15913-8_1, © Springer-Verlag Berlin Heidelberg 2011

2

Business Engineering und Business Engineering Navigator

den, obwohl es andere als fundamental ansehen. Insofern werden sich auch methodisch zumindest in einigen Fällen Mischformen aus traditionellen Managementansätzen und der Business Engineering-Methodik finden. Verstehen vs. Gestalten Das Unternehmensmodell des neuen St. Galler Managementmodells ist sowohl als Verständnis- wie auch als Gestaltungsrahmen nutzbar. Als Verständnisrahmen unterstützt es die gesamthafte Analyse von (existierenden oder gedachten) Unternehmen bzw. Unternehmensteilen. Als Gestaltungsrahmen unterstützt es die Schaffung bzw. Veränderung solcher Systeme. Dabei ist klar, dass das Zusammenspiel von Menschen, Aufgaben und IT-Systemen nicht wie eine Maschine „gebaut“ und betrieben werden kann. Viele wichtige Aspekte soziotechnischer Systeme sind emergent und höchstens mittelbar gestaltbar. Allerdings gibt es andererseits auch viele wichtige Aspekte, die zielgerichtet gestaltet und verändert werden können. Dazu gehören nicht nur IT-Systeme, sondern auch wichtige Komponenten der Organisation und Strategie sowie, in geringerem Umfang, bestimmte Komponenten von Führung, Verhalten und Kultur. Business Engineering behandelt die zielgerichtete Gestaltung und Veränderung von Unternehmen bzw. Unternehmensteilen. „Engineering“ heißt, dass der Fokus dabei auf die Artefakte, d. h. die unmittelbar gestaltbaren Komponenten gerichtet ist und nicht auf Einstellungen, Verhalten, Machtverhältnisse etc. Notwendigkeit eines systematischen und ganzheitlichen Ansatzes Die traditionellen betriebswirtschaftlichen Funktionallehren (wie z. B. Marketing, Finanzmanagement, HR-Management, aber auch Informationsmanagement) lassen sich dem Entwicklungsmodus „Optimierung“ zuordnen („Run the Business“), weil nicht eine mehr oder weniger fundamentale Neustrukturierung im Mittelpunkt steht, sondern das Tagesgeschäft oder allenfalls dessen inkrementelle Weiterentwicklung. Im Gegensatz dazu versteht sich Business Engineering als „betriebswirtschaftliche Konstruktionslehre“, d. h. stellt Modelle und Methoden für den Entwicklungsmodus „Veränderung“ („Change the Business“) bereit. Die Auslöser fundamentaler Veränderungen sind oft Technologieinnovationen, und zwar in erster Linie aus dem Bereich der Informations- und Kommunikationstechnologie: Kapazität und Leistungsfähigkeit in der Chip- und Speichertechnologie wachsen immer noch entsprechend Moores Gesetz. Die Standardisierung von Applikationen und Diensten, die Verbilligung und Steigerung von Netzwerkbandbreiten, neue Formen der Verknüpfung und Nutzung von Informationen usw. führen zu neuen Potenzialen für Automatisierung, Standardisierung und Arbeitsteilung. Neben technologischen Auslösern treten aber auch veränderte Organisationsformen (z. B. virtuelle Organisation oder dezentralisierte Netzwerkorganisation), eine umfassendere Orientierung an Kundenprozessen, Verhaltensänderungen von Kunden und Mitarbeitenden oder Veränderungen ökonomischer Rahmenbedingungen (Globalisierung, Deregulierung von Branchen und enger gefasste Compliance-Regeln) auf.

Notwendigkeit und Positionierung einer betriebswirtschaftlichen Konstruktionslehre

3

Ein gutes Beispiel für die Vielschichtigkeit von Veränderungsvorhaben ist die Vernetzungsfähigkeit. Die Fähigkeit, Kooperationen innerhalb von Organisationen und vor allem zwischen Organisationen einzugehen und dynamisch weiterzuentwickeln, erscheint immer wichtiger. Das Informationszeitalter ist kundenseitig durch Wertschöpfungsnetzwerke geprägt, die Kundenprozesse ganzheitlich unterstützen (Kagermann u. Österle 2006). Andererseits ist auch das Informationszeitalter produktionsseitig auf „industrielle“ Strukturen angewiesen, die Effizienz durch Arbeitsteilung und Standardisierung erreichen. Vernetzungsfähigkeit ist aber nicht allein durch Daten-Schnittstellen, interorganisationale Prozesse, eine Netzwerkstrategie und Kooperationsbereitschaft der Mitarbeitenden realisierbar. Erst ein ganzheitliches Vernetzungskonzept ist erfolgversprechend, in dem Strategie, Prozesse und Informationssysteme aufeinander abgestimmt („konsistent“) gestaltet sind (Fleisch 2001). Die vielen Beteiligten, die Unterschiedlichkeit der Perspektiven und Ansprüche, die hohe Komplexität und die finanzielle Bedeutung vieler Veränderungsvorhaben verbietet ein intuitives oder einseitiges Vorgehen. Um komplexe Zusammenhänge systematisch abzubilden, die verschiedensten Perspektiven miteinander zu verknüpfen, mit den unterschiedlichen Anspruchsgruppen zu kommunizieren, arbeitsteilig vorzugehen und genügend Planungs-/Steuerungssicherheit zu erreichen, bedarf es eines systematischen, ganzheitlichen Ansatzes. Systematisch bedeutet dabei, dass der Ansatz modell- und methodenbasiert ist. Ganzheitlich bedeutet, dass die Sichten und Ziele aller relevanten Anspruchsgruppen und alle relevanten Beschreibungsebenen (z. B. fachliche vs. technische Beschreibung) einbezogen sind. Ingenieurmäßiges Vorgehen Business Engineering versteht sich als betriebswirtschaftliche Konstruktionslehre für Veränderungsvorhaben. Dazu werden Konzepte sowie Modell- und Methodenkomponenten aus Betriebswirtschaftslehre, Change Management, Systems Engineering und Innovationsmanagement integriert (Österle u. Winter 2003). Business Engineering setzt damit eine Tradition fort, die in den Ingenieurdisziplinen wurzelt und sich mit Software Engineering als Konstruktionslehre für Software (Balzert 2000) oder Information Engineering als Konstruktionslehre für Informationsflüsse und -nutzung (Martin 1989) auch im Umfeld des „Change the Business“ etabliert hat. „Ingenieurmäßiges Vorgehen“ bedeutet, dass das Vorgehen einem explizierten Vorgehensmodell folgt, dass abstrakte Lösungsrepräsentationen benutzt werden und dass die systematische Wiederverwendung von Lösungskomponenten unterstützt wird (vgl. z. B. Aier et al. 2008). Um arbeitsteilig und zielgerichtet Geschäftslösungen dokumentieren, analysieren und (um- oder neu-)gestalten zu können, muss ein entsprechender Problemlösungsansatz die folgenden Eigenschaften haben:

4


• Vorgabe einer konsistenten (aber nicht unbedingt komplett einheitlichen) Terminologie, die von allen Beteiligten benutzt wird • Vorgabe explizierter Vorgehensmodelle und Vorgabe klarer Vorschriften für die Dokumentation von Ergebnissen • Konsistente Abbildung aller relevanten Strukturen und Zusammenhänge aus allen relevanten Blickwinkeln („objektiv“ fachlich, realisierungsbezogen/technisch, subjektiv-individuell, aus Sicht von Gruppen) • Anpassbare Problemlösungstechniken zur Steigerung von Effektivität und Effizienz sowie zur Sicherstellung von Transparenz, Wiederholbarkeit und Skalierbarkeit • Kollaborationsunterstützung und Kommunikationsunterstützung (z. B. Visualisierung) Modelle und Modellierung spielen in einem ingenieurmäßigen Ansatz naturgemäß eine große Rolle. Modelle sind ein zentrales Kommunikationsinstrument der Business Engineers untereinander sowie zwischen Business Engineers und den relevanten Anspruchsgruppen. Business Engineering Navigator1 Auch wenn das ingenieurmäßige Vorgehen eine gemeinsame Grundlage von z. B. Software Engineering und Business Engineering ist, ist der Gegenstand des Business Engineering viel weiter gefasst als Softwaresysteme und Datenstrukturen. Der Gegenstand des Business Engineering sind Organisationen wie Unternehmen, die öffentliche Verwaltung und nichtstaatliche Institutionen – in Teilen, als Ganzes oder als Netzwerke (sog. „Extended Enterprise“). Der Gegenstand umfasst die jeweiligen fachlichen Lösungen („Geschäftslösungen“) einschließlich deren ITUnterstützung. Da der überwiegende Anteil der IT-Unterstützung in Unternehmen, der öffentlichen Verwaltung und in nichtstaatlichen Institutionen nicht aus Individualsoftware, sondern aus angepasster und integrierter Standardsoftware besteht, steht auch bei der IT-Unterstützung nicht die Softwareentwicklung im Vordergrund, sondern die gegenseitige Abstimmung und Integration fachlicher Unterstützungsbedarfe und eingesetzter bzw. einsetzbarer Standardsoftwarelösungen. Business Engineering umfasst verschiedenartige Aufgaben: 1. Veränderungsmöglichkeiten und -ziele müssen permanent analysiert und priorisiert werden. 2. Der Gegenstand der Veränderung, also fachliche und IT-Strukturen, muss als komplexer Zusammenhang einer Vielzahl von Artefakten dokumentiert werden (Ist-Repräsentation). 3. Auf dieser Grundlage sind verschiedenste Informationsbedarfe zu befriedigen, die mit „Run the Business“, insbesondere aber auch mit „Change the Business“ 1

Business Engineering Navigator ist eine geschützte Wortmarke der Transfer- und Weiterbildungszentrum GmbH. Die Verwendung dieser Marke in diesem Buch erfolgt mit freundlicher Genehmigung der Rechteinhaberin.


5

in Zusammenhang stehen (z. B. welche Auswirkungen hätte die Veränderung von A auf B), indem die Strukturen und ihre Zusammenhänge analysiert werden. 4. Das Ziel der Veränderung wird abgebildet, indem eine Vielzahl von Artefakten konsistent verändert und die entsprechenden Beziehungen/Abhängigkeiten konsistent nachgeführt werden (Soll-Repräsentation). Es kann alternative und auch untereinander abhängige Soll-Repräsentationen geben, und diese können sich zudem im Zeitverlauf verändern. 5. Die Umsetzung der Veränderung entwickelt die realen fachlichen und ITStrukturen zielgerichtet, d. h. in Richtung der Soll-Repräsentationen. Erst hierdurch werden Veränderungen nicht nur konzipiert, sondern realisiert. Der Business Engineering Navigator (BEN) umfasst die Ist-Repräsentation (2), die Analyse (3) und die Soll-Repräsentation(en) (4) von Geschäftslösungen einschließlich deren IT-Unterstützung im Kontext von Veränderungsvorhaben (vgl. Abb. 1). Dabei ist wichtig, dass nicht nur die fachlichen Strukturen und ihre Zusammenhänge, sondern stets auch die unterstützenden IT-Strukturen und ihre Zusammenhänge sowie der Zusammenhang zwischen fachlichen und IT-Artefakten beschrieben, analysiert und geplant wird.

Abb. 1.

Einordnung von BEN ins Business Engineering

6


Es ist durchaus denkbar, dass der Fokus des Business Engineering auf die ITUnterstützung durch weitere Umsetzungsdimensionen wie z. B. Fähigkeiten oder finanzielle Ressourcen erweitert wird. Dieses Buch erweitert Business Engineering jedoch nicht, sondern schränkt den Fokus vielmehr auf konstruktionsunterstützende Business Engineering-Komponenten im engeren Sinne ein – also auf Konzepte, Modelle, Methoden und Beispiele für die Dokumentation, die Analyse und Neu- bzw. Umgestaltung von Geschäftslösungen einschließlich deren ITUnterstützung. Die Umsetzung solcher Lösungen (im Sinne von Change Management), das begleitende Innovationsmanagement sowie Unterstützungsaspekte außerhalb der IT werden nicht betrachtet. Durch den Zusatz „Navigator“ wird in BEN verdeutlicht, dass sowohl die Dokumentation wie auch die Analyse und die Neu- bzw. Umgestaltung von Geschäftslösungen einschließlich deren IT-Unterstützung nicht allein durch einen monolithischen Ansatz geleistet werden können, sondern dass eine Vielzahl von Konzepten, Modellen und Methoden zum Einsatz kommen kann. BEN versteht diese Konzepte, Modelle und Methoden als Komponenten eines umfassenden, komplexen Problemlösungsansatzes und stellt nicht nur eine verbindende konzeptuelle Grundlage bereit, sondern unterstützt auch das am Veränderungsziel ausgerichtete „Navigieren“ in dieser Konzept-, Modell- und Methodenwelt. Positionierung dieses Buches Dieses Buch dokumentiert BEN als zentrale Komponente der betriebswirtschaftlichen Konstruktionslehre. Sein „Navigationsraum“ wird durch die inhaltliche Fokussierung, den Aggregationsgrad und die Spezifität aufgespannt (siehe Abschnitt 1.2). Der BEN-Gegenstand, d. h. die zu dokumentierenden, zu analysierenden bzw. zu verändernden Geschäftslösungen einschließlich deren IT-Unterstützung, werden in Form eines Basis-Metamodells – dem sog. BEN-Metamodell mit zielspezifischen Erweiterungen und problemspezifischen Sichten spezifiziert. Das BEN-Vorgehen, d. h. die Dokumentation, Analyse bzw. Gestaltung von Geschäftslösungen einschließlich deren IT-Unterstützung, hat als Problemlösungsansatz sowohl Methoden- wie auch Referenzmodellcharakter: • In Form von wiederverwendbaren, situativen Dokumentations-, Analyse- bzw. Gestaltungsmethoden und individuellen Anpassungen wird auf die Problemlösungsaktivitäten fokussiert. • In Form von (Referenz-)Modellen mit individuellen Anpassungen wird auf die Problemlösungsergebnisse fokussiert. (Wiederverwendbare) Methoden und (Referenz-)Modelle sind dabei untrennbar miteinander verbunden (vgl. Abb. 2). Als ein Beispiel sei auf die Dissertation von Hafner (2005) verwiesen, die neben einer Methode für das Management der Informationssystemarchitektur in Unternehmen ebenso Beschreibungen von Ergebnissen einzelner Aktivitäten/Techniken dieser Methode enthält.


7

Parallel zur problemneutralen Beschreibung des BEN-Metamodells, der BENMethoden und der BEN-(Referenz-)Modelle dient ein durchgehendes Beispiel zur Illustration.

Ausgangssituation (Problem)

Ziel (Problem lösung PLF 1

PLF2

PLF 3

PLF4

PLF 5

PLF6

PLF7

Problemlösung AS = Aktivitätssicht des

ES = Ergebnissicht des

Problemlösungsfragments

Problemlösungsfragments

Abb. 2.

PLF = Problemlösungsfragment

Zusammenhang zwischen Methoden und (Referenz-)Modellen (Winter et al. 2009)

BEN ist als Dokumentations-, Analyse- und Gestaltungsansatz für neue Geschäftslösungen einschließlich deren IT-Unterstützung werkzeugneutral. Das heißt einerseits, dass der Ansatz nicht auf ein einzelnes oder eine bestimmte Gruppe von Werkzeugen zugeschnitten ist, die Geschäftslösungen einschließlich deren ITUnterstützung dokumentieren, analysieren oder (um- oder neu-) gestalten helfen. Andererseits wird in vielen Veränderungsprojekten ein Werkzeugeinsatz auch nicht wirtschaftlich sein, so dass entsprechende Ansätze nicht nur werkzeugneutral sein sollten, sondern darüber hinaus auch ohne Werkzeugunterstützung sinnvoll anwendbar sein sollten. Für komplexe oder bedeutsame Veränderungsprojekte sowie bei regelmäßiger Nutzung legen die Vielzahl der in BEN zusammengeführten Konzepte, Methoden und Modelle jedoch die Dokumentations-, Analyse- und Gestaltungsunterstützung durch ein entsprechendes Werkzeug (bzw. eine Menge integrierbarer Werkzeuge) nahe. Aus diesem Grunde wurde für BEN auf Grundlage einer leistungsfähigen Metamodellierungsplattform der BOC AG, Wien, ein Unterstützungswerkzeug mit dem Namen ADOben2 implementiert. Da ADOben auf BEN zugeschnitten ist, bleibt das Buch zwar werkzeugneutral, kann aber andererseits auch als Grundla2

ADOben ist eine geschützte Wortmarke der BOC AG. Die Verwendung dieser Marke in diesem Buch erfolgt mit freundlicher Genehmigung der Rechteinhaberin.

8

BEN – ein Ansatz zur Dokumentation, Analyse und Gestaltung von Geschäftslösungen

gendokumentation für ADOben angesehen werden. Kap. 5 widmet sich der Werkzeugunterstützung von BEN und zeigt exemplarisch die Nutzung von ADOben zur Gestaltung und Analyse von Geschäftslösungen einschließlich deren ITUnterstützung.

1.2 BEN – ein Ansatz zur Dokumentation, Analyse und Gestaltung von Geschäftslösungen BEN stellt einen Ansatz zur Dokumentation, Analyse und Gestaltung von Geschäftslösungen einschließlich deren IT-Unterstützung dar, der durch drei Dimensionen aufgespannt wird (Winter 2010). Basierend auf den Ausführungen des vorangegangenen Abschnitts wird mittels der ersten Dimension eine inhaltliche Abgrenzung der zu beschreibenden, zu analysierenden bzw. zu gestaltenden Sachverhalte vorgenommen. Diese Dimension wird als Fokus [F] bezeichnet. Die mit Hilfe von BEN durchgeführte Dokumentation, Analyse und (Um- bzw. Neu-)Gestaltung kann mittels verschiedener Aggregationsgraden erfolgen. Der Aggregationsgrad [A] spannt die zweite Dimension auf. Schließlich unterstützt BEN die Navigation durch verschiedene Spezifitätsgrade [S], wodurch die dritte Dimension aufgespannt wird. Die drei Beschreibungs- bzw. Analysedimensionen werden im Folgenden erläutert.

Abb. 3.

BEN-Dimension „Fokus“

Beschreibungs- bzw. Analysedimension „Fokus“ [F] BEN basiert auf der betriebswirtschaftlichen Konstruktionslehre des Business Engineering. Parallel dazu existieren weitere Ansätze für „Change the Business“ wie


9

z. B. das Veränderungsmanagement. Im Gegensatz zu BEN legen diese Ansätze ihren Schwerpunkt jedoch nicht auf die Dokumentation, Analyse und (Neu- bzw. Um-)Gestaltung von Geschäftslösungen, sondern beispielsweise auf die Umsetzung ebendieser Lösungen (vgl. ebenso Abschnitt 1.1). „Change the Business“ kann als weitest gehende inhaltliche Basis verstanden werden. Auf dieser Grundlage stellt Business Engineering als modell- und methodengestützter Analyse- und Gestaltungsansatz die erste Fokussierung (F0 in Abb. 3) dar. Als weitere, einschränkende Fokussierung könnten u.a. IT/Business Alignment oder unternehmensweites IT-Architekturmanagement angesehen werden (F1 in Abb. 3). Unternehmensarchitekturmanagement kann aus dieser Perspektive als weitere Fokussierung betrachtet werden, die Teilaspekte des IT-Architekturmanagements mit Teilaspekten aus dem IT/Business Alignment verbindet (F2 in Abb. 3). Architektur-Governance ist auf nächster Fokussierungsebene eine Einschränkung von Unternehmensarchitekturmanagement (F3 in Abb. 3). Insgesamt ergibt sich eine mehrstufige Multihierarchie möglicher Fokussierungen (siehe Abb. 3).

Abb. 4.

BEN-Dimension „Aggregationsgrad“

Beschreibungs- bzw. Analysedimension „Aggregationsgrad“ [A] Die mit Hilfe von BEN angestrebte Dokumentation, Analyse und (Um- bzw. Neu-)Gestaltung von Geschäftslösungen einschließlich deren IT-Unterstützung kann mittels verschiedener Aggegrationsgrade erfolgen. Auf der Grundlage grobgranularer Modelle können schrittweise Verfeinerungen vorgenommen werden, die schließlich zu diversen Detail-Modellen führen. Andererseits können aggregierte Modelle durch Vergröberung zusammengeführter Detailmodelle gewonnen werden. Die Anzahl möglicher Aggregationsgrade hängt dabei von der Art des Modells und der gewünschten Detailtiefe ab. Abb. 4 veranschaulicht die Dimensi-

10

BEN – ein Ansatz zur Dokumentation, Analyse und Gestaltung von Geschäftslösungen

on „Aggregationsgrad“ anhand von fünf Stufen: Den Ausgangspunkt bildet ein unternehmensweites Modell wie beispielsweise eine gesamthafte Prozesslandkarte (A0 in Abb. 4). Diese Prozesslandkarte kann in verschiedene detailliertere Prozesslandkarten für Unternehmensteile zerlegt werden (A1 in Abb. 4). In einem folgenden Verfeinerungsschritt können für solche Prozesslandkarten Detaillierungen in Form von Modellen einzelner Prozesse vorgenommen werden (A2 in Abb. 4). Modelle, die einzelne Prozesse oder Teile von Prozessen beschreiben, können je nach Prozesskomplexität fast beliebig weiter verfeinert werden (z. B. Stufen A3 und A4 in Abb. 4). Aggregationsgrad und Fokus sind orthogonal: Modelle jeden Fokussierungsgrades können auf beliebigen Aggregationsgraden abgebildet werden.

Abb. 5.

BEN-Dimension „Spezifität“

Beschreibungs- bzw. Analysedimension „Spezifität“ [S] Innerhalb von BEN kann neben einer Verfeinerung der Modelle ebenso eine Navigation im Hinblick auf die Breite der abgedeckten Problemsituationen vorgenommen werden (vgl. Abb. 5). Die breiteste Situationsabdeckung (als Stufe S0 bezeichnet) ist „one size fits all“, d. h. der Anspruch, dass der jeweilige Problemlösungsansatz in allen Situationen einsetzbar ist. Eine Situation ist dabei durch die jeweils verfolgten Gestaltungs- bzw. Analyseziele einerseits sowie durch die relevanten Kontext-Rahmenbedingungen (wie z. B. die Größe oder die Branche des Unternehmens) andererseits definiert (Winter et al. 2009). In den meisten Fällen werden es jedoch die Unterschiedlichkeit der Gestaltungs- bzw. Analyseziele sowie die Unterschiedlichkeit der Kontexte erfordern, einen Problemlösungsansatz situativ anzupassen. So sind z. B. die Modelle und Methoden von BEN entsprechend der gewählten Spezifitätsstufe anzupassen, um der jeweiligen Problemsituation gerecht zu werden. Ausgehend von „one size fits all“ (S0 in Abb. 5) sind z. B. verschiedene Problemlösungs-Variationen mit jeweils unterschiedlichen Schwerpunkten zu unterscheiden (S1 in Abb. 5). Für die einzelnen GrundansatzVarianten können wiederum verschiedene Gestaltungssituationen konkretisiert werden (S2 in Abb. 5). In Abb. 5 wird als Beispiel die analytische Prozessunterstützung als Business Intelligence-Grundansatzvariante herangezogen, für die nach (Bucher 2009) vier Situationen und fünf Projekttypen unterschieden werden sollten, die sich durch jeweils unterschiedliche Kontexte und Projektziele differenzieren. Schließlich besteht die Möglichkeit, die Modelle und Methoden des


11

BEN-Ansatzes individuell an die Charakteristika eines konkreten Projekts anzupassen (Spezifitätsgrad S3 in Abb. 5). Für Migrationsprojekte im Integrationsmanagement bestehen solche Anpassungen z. B. darin, dass einzelne Aktivitäten/Aufgaben, wie z. B. die Definition von Domänen oder die Festlegung eines einheitliches Vokabulars, in Abhängigkeit der individuellen Projektsituation durchgeführt werden oder nicht (Winter 2009). Die Spezifität ist orthogonal zum Aggregationsgrad und Fokus: Modelle jeder Spezifität können auf beliebigen Aggregationsgraden abgebildet werden und beliebig fokussiert sein.

Abb. 6.

Einordnung des Business Engineering Navigator

Zusammenfassende Positionierung des Business Engineering Navigator Zusammenfassend kann festgehalten werden, dass BEN ausgehend von inhaltlich breiten, aggregierten und generischen Konzepten, Modellen und Methoden die sukzessive Erarbeitung einer konkreten Problemlösung erlaubt. Basierend auf dem breiteren Business Engineering bildet BEN die Dokumentations-, Analyse und (Um- bzw. Neu-)Gestaltungsgrundlage für inhaltlich weiter fokussierte Ansätze wie z. B. die Unterstützung von Integrationsprojekten oder das Unternehmensarchitekturmanagement (Dimension F). Darüber hinaus unterstützt BEN die Navigation innerhalb verschiedener Problemlösungen mittels unterschiedlicher Aggregations- und Spezifitätsstufen (Dimensionen A und S). Durch die Zusammenführung der drei Dimensionen „Fokus“, „Aggregationsgrad“ und „Spezifität“ entsteht ein Raum, der die Positionierung von BEN erlaubt (vgl. Abb. 6). Die hier präsentierte dreidimensionale „Artefaktwelt“ bietet darüber hinaus die Möglichkeit, unterschiedlich spezifische sowie unterschiedlich aggregierte Problemlösungen in Be-

12

Gegenstand und Methodik des Business Engineering Navigator

ziehung zueinander zu setzen. Dies ist die Grundlage für die „Navigation“ in komplexen Artefaktwelten und damit namensgebend für „Navigator“ in BEN. Wie bereits angesprochen (vgl. Abschnitt 1.1) erscheint bei komplexen Veränderungsprojekten die Verwendung eines entsprechenden Werkzeugs sinnvoll. Solche Werkzeuge können sich die von BEN aufgespannten Zusammenhänge bzw. Abhängigkeiten zu Nutze machen, indem sie bspw. Abhängigkeitsanalysen zwischen einzelnen Entitäten anbieten oder eine sog. „Drill-Down-Funktionalität“ ermöglichen, die eine schrittweise Verfeinerung hierarchisch angelegter Modelle erlaubt. Mittels solcher Funktionalitäten können Werkzeuge die Modellierenden bei der Analyse und Gestaltung von Geschäftslösungen einschließlich deren ITUnterstützung unterstützen und dazu beitragen, die Artefaktwelt systematisch verstehbar und konsistent gestaltbar zu machen.

1.3 Gegenstand und Methodik des Business Engineering Navigator Der Business Engineering Navigator wird durch den betrachteten Gegenstand – die Geschäftslösungen einschließlich deren IT-Unterstützung – sowie durch eine entsprechende Dokumentations-, Analyse- und (Um- bzw. Neu-)Gestaltungsmethodik charakterisiert. Der Gegenstand von BEN wird mittels eines Metamodells repräsentiert (vgl. Abschnitt 2.1), das als BEN-Metamodell bezeichnet wird. Obgleich der BENGegenstand durch das Metamodell grundsätzlich abgesteckt ist, können inhaltliche Fokussierungen nachvollzogen werden, indem das Metamodell entsprechend angepasst wird. Zum einen besteht die Möglichkeit, unter Anwendung festgelegter Adaptionsmechanismen domänenspezifische Erweiterungen für das BENMetamodell zu definieren. Als Beispiel sei die Erweiterung des BEN-Metamodells in Bezug auf Branchenspezifika, wie z. B. im Hinblick auf spezielle Aspekte des Gesundheitswesens, angeführt. Zum anderen können Sichten auf das BENMetamodell gebildet werden, um Metamodellelemente auszublenden. Hier ist es z. B. denkbar eine Informationssicht zu definieren, in dem lediglich die Bestandteile ausgewählt werden, die informationsbezogene Charakteristika aufweisen. Mittels dieser beiden Metamodell-Anpassungsmechanismen wird die Variabilität des Gegenstands des BEN-Ansatzes in Bezug auf die Dimension „Fokus“ deutlich. Die beiden verbleibenden Dimensionen von BEN werden durch dessen Gegenstand ebenso berücksichtigt: Die Situativität schlägt sich im Wesentlichen durch die jeweilige Spezifität der Inhalte der auf Grundlage des Metamodells repräsentierten Problemlösungen nieder. Die verschiedenen Aggregationsgrade werden dadurch repräsentiert, dass verschiedene Elemente des BEN-Metamodells rekursive Beziehungen aufweisen (vgl. Abschnitt 2.1), die eine schrittweise Verfeinerung des jeweiligen Elementtyps erlauben. So können bspw. Geschäftsprozesse, Organisationseinheiten oder Ziele schrittweise beliebig zerlegt werden.


13

Im Gegensatz zum BEN-Metamodell, das für den BEN-Ansatz die Frage nach dem „Was wird gestaltet?“ beantwortet, adressiert die Dokumentations-, Analyseund (Um- bzw. Neu-)Gestaltungsmethodik von BEN die Frage „Wie wird gestaltet?“. Die BEN-Methodik umfasst insbesondere • BEN-Vorgehensmodelle (vgl. Abschnitt 3.3), die beschreiben, wie bei der Beschreibung, Analyse oder (Um- bzw. Neu-)Gestaltung von Geschäftslösungen einschließlich deren IT-Unterstützung grundsätzlich vorzugehen ist, und • BEN-Komponenten (vgl. Kapitel 4), die als Problemlösungs-„Bausteine“ spezifische Aktivitäten und Ergebnisbeschreibungen kapseln. Bezüglich der inhaltlichen Dimension der Dokumentations-, Analyse- und (Um- bzw. Neu-)Gestaltungsmethodik von BEN (Dimension „Fokus“) kann folglich festgehalten werden, dass die Methodik Vorgehensmodelle sowie wieder verwendbare Gestaltungsergebnisse umfasst. Für den Einsatz der BEN-Methodik können diverse generische Projekttypen identifiziert werden, die von den BENVorgehensmodellen berücksichtigt werden. Dadurch wird dem situativen Charakter des BEN-Ansatzes Rechnung getragen (Dimension „Spezifität“). Schließlich besteht die Möglichkeit, sowohl die Vorgehensmodelle als auch die wieder verwendbaren Gestaltungsergebnisse zu verfeinern, indem diese in kleinere Einheiten zerlegt werden (Dimension „Aggregationsgrad“). Die in diesem Abschnitt vorgestellte Differenzierung zwischen dem Gegenstand sowie der Dokumentations-, Analyse- und (Um- bzw. Neu-)Gestaltungsmethodik des BEN-Ansatzes wird im weiteren Verlauf des Buchs zunächst aufrecht erhalten (vgl. die beiden folgenden Kapitel 2 und 3). Diese Entscheidung ist auf die mit der Differenzierung dieser beiden Aspekte verbundene Unabhängigkeit zurückzuführen. So können bspw. verschiedene BEN-Vorgehensmodelle auf ein und demselben Gegenstand – den Geschäftslösungen einschließlich deren IT-Unterstützung – angewendet werden. Für den praktischen Einsatz in Veränderungsprojekten sind die in sich geschlossenen Darstellungen des „was“ und „wie“ von BEN jedoch wenig praktikabel. Deshalb werden Metamodell-, Vorgehens-/Aktivitätsmodell- und Dokumentationsmodellfragmente zu kleinen, besser handhabbaren und im jeweiligen Projektkontext (in Grenzen) flexibel kombinierbaren Komponenten integriert. Diese sog. „BEN-Komponenten“ werden in Kapitel 4. beschrieben.

2 Geschäftslösungen – Gegenstand der Analyse und Gestaltung mit BEN Anke Gericke und Robert Winter

Das zweite Kapitel beschreibt den BEN-Gegenstand, nämlich Geschäftslösungen einschließlich ihrer IT-Umsetzung, im Detail. Die Komplexität des Gegenstands wird dadurch vermindert, in dem Analyse- und Gestaltungsebenen eingeführt werden. Für jede Ebene werden dann Modelltypen vorgestellt, welche die jeweils relevanten Gestaltungsobjekte und deren Beziehungen entsprechend der sachlogischen Zusammenhänge zusammenführen.

2.1 Repräsentation von Geschäftslösungen Den Gegenstand von BEN stellen Geschäftslösungen „Business to IT“ dar, d. h. die fachlichen Lösungsbeschreibungen wie auch die Spezifikationen der ITSysteme, welche die Geschäftslösungen unterstützen. Die Repräsentation von Geschäftslösungen einschließlich deren IT-Unterstützung erfolgt auf Grundlage des so genannten BEN-Metamodells. Das BEN-Metamodell umfasst Gestaltungsobjekte, die ein Unternehmen, eine Unternehmenseinheit oder ein Unternehmensnetzwerk beschreiben, sowie Beziehungen zwischen diesen Gestaltungsobjekten. Konkrete, mit der BEN-Methodik entwickelte Modelle tatsächlich realisierter oder geplanter Artefakte sind somit Instanziierungen des BEN-Metamodells. Die Basierung auf einem Metamodell garantiert Konsistenz, Einheitlichkeit, Vergleichbarkeit und Vollständigkeit von verschiedenen Modellinstanzen (Österle et al. 2007). Zur Dokumentation des BEN-Metamodells wurde die Modellierungssprache UML benutzt. Die Gestaltungsobjekte (und damit Entitätstypen) des Metamodells werden mittels UML-Klassen modelliert. Für die Darstellung der Beziehungen zwischen diesen Entitätstypen werden der UML folgend die Beziehungstypen Generalisierung, Assoziation und Aggregation verwendet (Österle et al. 2007; Oestereich 2001): • Generalisierung: Eine Generalisierung stellt ein Abstraktionskonzept dar, mit dessen Hilfe die Inhalte eines Modells hierarchisch strukturiert werden können. Mittels einer Generalisierung wird eine Beziehung zwischen einem allgemeinen und einem speziellen Gestaltungsobjekt beschrieben, wobei das spezielle Gestaltungsobjekt zusätzliche Eigenschaften besitzt und ansonsten kompatibel zum allgemeinen Gestaltungsobjekt ist. Die Generalisierung wird durch einen


16

Repräsentation von Geschäftslösungen

nicht ausgefüllten Pfeil dargestellt, der vom speziellen Gestaltungsobjekt auf das allgemeine Gestaltungsobjekt zeigt. • Assoziation: Eine Assoziation beschreibt eine allgemeine Beziehung zwischen zwei Gestaltungsobjekten und wird durch eine Kante dargestellt, welche die beiden Objekte miteinander verbindet. Durch die Beschriftung der Kante wird eine Präzisierung der Art der Beziehung vorgenommen. • Aggregation: Eine Aggregation stellt eine spezielle Form der Assoziation dar, mit deren Hilfe eine Ganzes-Teile-Beziehung abgebildet wird. Folglich wird unter einer Aggregation die Zusammensetzung eines Gestaltungsobjekts aus mehreren Teilen, d. h. anderen Gestaltungsobjekten, verstanden. Bei einigen Gestaltungsobjekten kann es sinnvoll sein, diese in Gestaltungsobjekte des gleichen Typs zu zerlegen – auch hier findet die Aggregation als eine Spezialform Anwendung. Als Beispiele seien die hierarchische Modellierung von Aufbauorganisationsstrukturen oder die Zerlegung des Zielsystems in Ziele angeführt. Eine Aggregation wird als Kante zwischen zwei Gestaltungsobjekten dargestellt, wobei diese Kante auf der Seite des Aggregats, d. h. des Ganzen, mit einer nicht ausgefüllten Raute versehen ist. Durch Generalisierung und Aggregation wird eine strukturierte Erschließung des BEN-Metamodells möglich (Österle et al. 2007). Werden die speziellen Entitäten und die detaillierenden Entitäten ausgeblendet, so verbleiben die drei Gestaltungsobjekte: Unternehmen, Markt und Geschäftsfeld (vgl. Abb. 7).

Abb. 7.

BEN-Metamodell (1. Abstraktionsebene)

Im Mittelpunkt der Betrachtung von Geschäftslösungen in BEN steht das Unternehmen, welches mit einer Vielzahl von Geschäftspartnern im Markt agiert. Die Tätigkeiten am Markt werden dabei durch einzelne Geschäftsfelder konkretisiert. Im BEN-Metamodell werden diese Geschäftsfelder durch die Assoziationsklasse Geschäftsfeld (attributierte Assoziation) repräsentiert, die zur Assoziation „agiert in“ zwischen Unternehmen und Markt modelliert wurde (Österle et al. 2007). In einem nächsten Verfeinerungsschritt wird das Metamodell durch Spezialisierung bzw. Zerlegung der drei Gestaltungsobjekte „Markt“, „Unternehmen“ und „Geschäftsfeld“ vorgenommen (vgl. Abb. 8). Für das Gestaltungsobjekt „Geschäftsfeld“ wird eine Verfeinerung in Hinblick auf (Österle et al. 2007)

Geschäftslösungen – Gegenstand der Analyse und Gestaltung mit BEN

17

• die Kundensegmente, die vom Unternehmen adressiert werden, • die Kooperationskanäle, die zum Informations- und Warenaustausch verwendet werden, sowie • die (Eigen-)Marktleistungen des Unternehmens, mittels derer die Bedürfnisse der Kunden befriedigt werden, • vorgenommen. Ferner können Geschäftsfelder hierarchisch strukturiert sein, indem sie bspw. den Bestandteil eines größeren, übergeordneten Geschäftsfelds bilden.

Abb. 8.

BEN-Metamodell (2. Abstraktionsebene)

Der Markt, in dem die Unternehmen agieren, wird primär durch die verschiedenen Geschäftspartner sowie durch Fremd-Marktleistungen charakterisiert, die in den Prozessen der Geschäftspartner erzeugt bzw. konsumiert werden. Bei den Geschäftspartnern können Kunden und Lieferanten unterschieden werden, die jeweils über individuelle Prozesse verfügen, d. h. die Geschäftspartnerprozesse lassen sich in Kundenprozesse und Lieferantenprozesse spezialisieren. Die Prozesse der Geschäftspartner sowie die darin erzeugten Fremd-Marktleistungen besitzen Abhängigkeiten mit den (Eigen-)Marktleistungen des betrachteten Unternehmens

18

Repräsentation von Geschäftslösungen

(Österle et al. 2007): Zum einen bedient das betrachtete Unternehmen die Prozesse seiner Geschäftspartner mit (Eigen-)Marktleistungen. Zum anderen fließen ebenso Marktleistungen der Geschäftspartner, die aus Sicht des betrachteten Unternehmens als Fremd-Marktleistungen bezeichnet werden, als Input in die Leistungserstellung des betrachteten Unternehmens ein. Die Gestaltbarkeit dieser wechselseitigen Abhängigkeiten sowie der Objekte, die dem Gestaltungsobjekt Markt zugehörig sind, variiert in Abhängigkeit der Machtposition des betrachteten Unternehmens und unterliegt im Allgemeinen verschiedenen Restriktionen (Österle et al. 2007). Ein Unternehmen kann in die Gestaltungsobjekte Ablauforganisation, ITSystem, Aufbauorganisation und Zielsystem (auch als Führung bezeichnet) zerlegt werden. Unter der Ablauforganisation werden dabei die Geschäftsprozesse eines Unternehmens verstanden, wobei die Ausführung ebendieser Prozesse durch das IT-System des Unternehmens unterstützt wird. Die Aufbauorganisation umfasst eine Beschreibung aller Organisationseinheiten eines Unternehmens, die an der Ausführung der Geschäftsprozesse beteiligt bzw. für diese verantwortlich sind. Schließlich dient das Gestaltungsobjekt Zielsystem dazu, sowohl die Aufbau- als auch die Ablauforganisation zu steuern. Da in BEN die Dokumentation, Analyse und (Um- oder Neu-)Gestaltung von Geschäftslösungen einschließlich ihrer IT-Unterstützung im Vordergrund steht, wird im Folgenden ein letzte Verfeinerung des BEN-Metamodells vorgenommen, die sich auf die Zerlegung der Gestaltungsobjekte Ablauforganisation, IT-System, Aufbauorganisation und Zielsystem bezieht (vgl. Abb. 9). Die Ablauforganisation eines Unternehmens kann durch die Geschäftsprozesse sowie die durch sie erzeugten (Prozess-)Leistungen charakterisiert werden. Die (Prozess-)Leistungen wiederum können „als Input in weitere Geschäftsprozesse eingehen oder als Teil von (Eigen-)Leistungen im Markt verwertet werden“ (Österle et al. 2007). Die Geschäftsprozesse lassen sich hierarchisch verfeinern – von Teilprozessen bis hin zu Aufgaben auf der untersten fachlichen Detaillierungsebene (Österle et al. 2007). Die Unternehmen befinden sich auf dem Weg vom Informations- zum Industriezeitalter (Österle u. Winter 2003). Der Weg ihrer Transformation wird dabei maßgeblich durch das IT-System beeinflusst, das die Ablauforganisation des Unternehmens unterstützt. Das IT-System kann in die Gestaltungsobjekte Applikations-(software-)Komponente, Datenelement und Informationstechnik-Komponente zerlegt werden. Applikations-(software-)Komponenten, die auf Datenelementen operieren, bilden dabei Bestandteile von fachlichen Services, mit denen Aufgaben innerhalb der Geschäftsprozesse unterstützt werden können. Fachliche Services lassen sich zu Applikationen gruppieren, die wiederum in Domänen geclustert werden können. Darüber hinaus operieren fachliche Services auf logischen Datenobjekten, die eine Repräsentation der Geschäfts-(Informations-)objekte darstellen. Die zuvor aufgeführten Informationstechnik-Komponenten können ebenso detailliert werden. Sie lassen sich in Systemsoftware(-Komponenten) und Hardware spezialisieren.


Abb. 9.

BEN-Metamodell (vollständig)

19

20

Strukturierung des Gegenstands mittels eines Ebenenkonzepts

Neben dem IT-System, das die Ablauforganisation unterstützt, geht die Aufbauorganisation ebenso eine Beziehung mit den Geschäftsprozessen ein, indem sie diese ausführt. Die Aufbauorganisation besteht aus einzelnen Organisationseinheiten, die jeweils an einem Standort lokalisiert sind und hierarchisch verfeinert werden können. Die Organisationseinheiten lassen sich in Stellen und allenfalls (bei überschaubaren Domänen) in Mitarbeitende zerlegen, wobei eine Stelle durch einen oder mehrere Mitarbeitende(n) besetzt wird. Innerhalb der Aufbauorganisation werden darüber hinaus Rollen definiert, die durch Mitarbeitende erfüllt werden. Eine Rolle, die hierarchisch verfeinert werden kann, ist an der Ausführung einer Aufgabe und damit eines Geschäftsprozesses beteiligt. Wie bereits angeführt, steuert das Gestaltungsobjekt Zielsystem sowohl die Aufbau- als auch die Ablauforganisation. Für ein Unternehmen müssen zunächst dessen Erfolgsfaktoren ermittelt werden, die die Grundlage für die Definition messbarer Kennzahlen bilden (Österle et al. 2007). Für diese Kennzahlen kann sodann jeweils ein individueller Zielwert (Soll-Wert) festgelegt werden. Erfolgsfaktoren, Kennzahlen und Zielwerte stellen Bestandteile des Gestaltungsobjekts Ziel dar. Unabhängig von seiner Zerlegung in verschiedene Komponenten kann das Gestaltungsobjekt Ziel ebenso hierarchisch verfeinert werden. Den Kombinationen der Zielwerte mit den im Unternehmen ermittelten Ist-Werten können schließlich Maßnahmen zugeordnet werden, mit deren Hilfe die Erreichung der übergeordneten strategischen Ziele sichergestellt werden soll (Österle et al. 2007). Bei den bisherigen Ausführungen zum BEN-Metamodell wurde bereits in Ansätzen deutlich, dass das Metamodell ebenso Entitäten enthält, die lediglich zum besseren Verständnis des Gesamtzusammenhangs eingeführt wurden (z. B. Unternehmen oder Markt). Dies gilt ebenso für einige Assoziationen (z. B. Aufbauorganisation führt Ablauforganisation aus). Im Folgenden soll deshalb das zuvor vorgestellte BEN-Metamodell verkürzt dargestellt werden, indem es lediglich die Entitäten und Beziehungen enthält, die im BEN-Ansatz auch als tatsächliche Artefakte bzw. deren -Referenzen bewirtschaftet werden (vgl. Abb. 10).

2.2 Strukturierung des Gegenstands mittels eines Ebenenkonzepts Das BEN-Metamodell ist wie alle Informationsmodelle inhärent „flach“. Zwar erleichtern auch in Informationsmodellen Aggregationsebenen das Verständnis der abgebildeten Sachverhalte. Solche Aggregationsebenen wurden ja bei der Erläuterung des BEN-Metamodells einführend auch benutzt. Im Gegensatz zu anderen Modellierungsdomänen (wie z. B. Prozessmodellierung) haben in der Informationsmodellierung Verfeinerungs- bzw. Vergröberungsbeziehungen gegenüber Beziehungen innerhalb einer Aggregationsebene eine stark untergeordnete Bedeutung.


Abb. 10. BEN-Metamodell (verkürzte Darstellung)

21

22


Angesichts des Umfangs des in Abschnitt 2.1 dargestellten BEN-Metamodells und der in diesem Fall lediglich didaktischen Bedeutung von Aggregaten sind andere Maßnahmen erforderlich, um das BEN-Metamodell in Komponenten zu zerlegen, die als Grundlage für Konstruktionskomponenten dienen können und das Metamodell handhabbarer machen. Die Kopplung der Modellinhalte, d. h. die Intensität der inhaltlichen Zusammenhänge zwischen Metamodellelementen spielt dafür eine wichtige Rolle. Zwar ist jede Referenz im BEN-Metamodell für die Konsistenz der repräsentierten Modelle gleich wichtig; Der Zusammenhang zwischen Erfolgsfaktoren und Organisationszielen, zwischen Aufgaben und Führungsgrößen oder zwischen IT-Funktionalitäten und Datenelementen auf der einen Seite ist jedoch weitaus enger als der Zusammenhang zwischen Organisationszielen und Prozess-Führungsgrößen, zwischen Aufgaben und IT-Funktionalitäten oder zwischen IT-Funktionalitäten und Hardwaresystemen auf der anderen Seite. Architekturebenen im Business Engineering Die Unterschiede in den Stärken der Zusammenhänge lassen sich damit begründen, dass manche Artefakte unter Berücksichtigung gleicher Ziele durch gleiche Personenkreise miteinander und in enger gegenseitiger Abstimmung untereinander gestaltet werden, während andere unter Berücksichtigung unterschiedlicher Ziele, durch unterschiedliche Personenkreise und/oder ohne unmittelbaren Zusammenhang zueinander gestaltet werden. Erfolgsfaktoren und Organisationsziele werden im Rahmen des Strategieprozesses gemeinsam erarbeitet bzw. überarbeitet; Aufgaben und Führungsgrößen werden im Rahmen der Prozessengineering gemeinsam erarbeitet bzw. überarbeitet. IT-Funktionalitäten und Datenelemente werden im Rahmen des Software Engineering gemeinsam erarbeitet bzw. überarbeitet. Im Gegensatz dazu werden Organisationsziele und Prozess-Führungsgrößen, Aufgaben und IT-Funktionalitäten oder IT-Funktionalitäten und Hardwaresysteme in unterschiedlichen Gestaltungsprozessen erarbeitet bzw. überarbeitet und ihre Gestaltung folgt dadurch auch unterschiedlichen Teilzielen. Die zentralen Gestaltungsebenen des Business Engineering sind (Winter 2003b): • Strategieebene: Hier werden für die betrachtete Einheit (Unternehmen, Geschäftseinheit, aber auch Wertschöpfungsnetz) die Positionierung im Wettbewerb und hinsichtlich Kompetenzen, die daraus folgenden Beziehungen mit Kunden und Wertschöpfungspartnern, das Produkt-/Leistungsprogramm und das Zielsystem betrachtet. Diese Gestaltungsfragen lassen sich auch als WASFragen bezeichnen. Implizit wird im Rahmen der (Um- bzw. Neu-)Gestaltung natürlich auch festgelegt, wie die WAS NICHT-Fragen zu beantworten sind. • Organisationsebene: Hier werden für die betrachtete Einheit Aktivitäten, Abläufe, Verantwortlichkeiten und Berichtswege (Governance), operative Führung, organisatorische Einheiten sowie Informationsbedarfe und -flüsse betrachtet. Diese Gestaltungsfragen lassen sich auch als WIE-Fragen bezeichnen, da sie die Umsetzung der strategischen Festlegungen beschreiben. Als Umset-


23

zung haben WIE-Aspekte einen kürzeren Lebenszyklus als WAS-Aspekte: Unter wechselnden Rahmenbedingungen kann das gleiche WAS mit unterschiedlichem WIE erreicht werden. Implizit wird im Rahmen der (Um- bzw. Neu-)Gestaltung natürlich auch festgelegt, wie die WIE NICHT-Fragen zu beantworten sind. • IT-Ebene: Hier werden für die betrachtete Einheit IT-Funktionalitäten, Datenstrukturen sowie Hardwarekomponenten betrachtet. Diese Gestaltungsfragen lassen sich auch als WOMIT-Fragen bezeichnen, da sie die Unterstützung der Organisation durch Informations- und Kommunikationstechnik behandeln. Zur weiteren Differenzierung von Modellen und Methoden kann die IT-Ebene in Unterebenen zerlegt werden, z. B. für IT-Infrastruktur (Hardwarekomponenten) einerseits und Softwaresysteme (IT-Funktionalitäten und Datenstrukturen) andererseits. Implizit wird im Rahmen der (Um- bzw. Neu-)Gestaltung natürlich auch festgelegt, wie die WOMIT NICHT-Fragen zu beantworten sind. • Politisch-kulturelle Ebene: Hier werden für die betrachtete Einheit Organisationskultur, Führung, Macht, Motivation und Verhalten betrachtet. Diese Gestaltungsfragen lassen sich auch als WARUM-Fragen bezeichnen, weil es hier um die Ursachen und Hintergründe für die Unterstützung oder Verhinderung von Veränderungen geht. Aufgrund der Wichtigkeit dieser Aspekte für den Erfolg von Veränderungsvorhaben ist es auf dieser Betrachtungsebene am sinnvollsten, analoge WARUM NICHT-Fragen nicht nur implizit (dadurch, was nicht modelliert wurde), sondern sogar explizit zu behandeln. Abb. 11 wiederholt die bereits in Abb. 1 vorgestellte Business EngineeringLandkarte, hier aber unter Hervorhebung der vorgestellten Architekturebenen.

Abb. 11. BEN-Architekturebenen

24


Verknüpfung der Architekturebenen im Business Engineering Einfache und kleine Veränderungsprojekte führen zur Veränderung einer begrenzten Zahl von Artefakten, idealerweise nur auf einer der beschriebenen Architekturebenen. Komplexe Projekte betreffen Artefakte auf mehreren, meist sogar allen Ebenen: (Fundamentale) Transformationen werden erst wirksam, wenn sie auf allen Ebenen umgesetzt werden (Österle 1995). Insofern stellt sich die Frage, wie die Artefaktgestaltung auf unterschiedlichen Ebenen methodisch verbunden werden kann. Dazu kann eine Betrachtung typischer Lebenszyklen der jeweils betrachteten Strukturen einen wichtigen Hinweis liefern. Die strategische Positionierung ist vergleichsweise langfristig ausgerichtet. Die Ausrichtung, das Leistungs- und das Zielsystem von Unternehmen bzw. Unternehmensteilen werden oft jährlich, seltener unterjährig angepasst und haben dann eine Lebensdauer von mitunter mehreren Jahren. Geschäftsprozesse und Organisationsstrukturen haben meist eine kürzere Lebensdauer und werden häufiger überarbeitet. Dies ist einerseits eine Folge der gewollten Abstraktion der WAS-Fragen von den WIE-Fragen und andererseits eine Konsequenz der begrenzteren Auswirkungen und der damit leichteren Änderbarkeit von Strukturen auf der Organisationsebene. Im Gegensatz dazu ist die IT-Ebene zwar von hoher technischer Innovationsdichte geprägt; Gleichzeitig sind die gewachsenen Strukturen jedoch so komplex, dass grundlegende Änderungen nur in Form mehrjähriger Großprojekte möglich sind und einmal geschaffene bzw. grundlegend angepasste Grundstrukturen oft für Jahrzehnte betrieben werden (müssen). Abb. 12 illustriert exemplarische Lebenszyklen auf Strategie-, Organisations- und IT-Ebene. Es wird deutlich, dass die methodische Abstimmung zwischen Strategieebene und Organisationsebene wegen der ähnlicheren Lebenszyklen deutlich einfacher ist als die methodische Abstimmung zwischen Organisationsebene und IT-Ebene.

Abb. 12. Lebenszyklen auf Strategie-, Organisations- und IT-Ebene


25

Artefakte auf der Organisationsebene bilden im Normalfall Vorgaben ab, die in Form von Artefakten auf der Strategieebene spezifiziert sind. So bilden beispielsweise Prozess-Führungsgrößen die Vorgaben von Strategie-Führungsgrößen ab und Prozessleistungen bilden die Vorgaben von Markt- oder Eigen-Leistungen ab. Bei Änderungen an Strategie-Artefakten sind die abgeleiteten OrganisationsArtefakte u. U. anzupassen. Die fachliche Führung stellt im Normalfall sicher, dass solche Anpassungen tatsächlich und schnell genug erfolgen – ein Unternehmen oder Unternehmensteil hat ja im Normalfall die Gestaltung der Ablauf- und Aufbauorganisation selbst in der Hand. Artefakte auf IT-Ebene und Artefakte auf Organisationsebene sind so einfach jedoch nicht zu verknüpfen. Erstens kann eine organisatorische Änderungen z. B. nicht oder nicht vollständig in die IT propagiert werden, wenn die aktuellen Softwaresysteme und Datenstrukturen nur mit immensem Aufwand zu ändern sind (z. B. aufgrund fehlender Dokumentation oder fehlender Fähigkeiten) oder wenn Standardsoftware im Einsatz ist, die nur beschränkt konfiguriert oder nur mit immensem Aufwand angepasst werden kann. Zweitens erfolgen Änderungen u. U. nicht nur aus Richtung Fachseite, sondern aufgrund von IT-Innovationen (z. B. Software-Updates durch Standardsoftwarehersteller, neue innovative Softwaresysteme) auch aus Richtung IT-Seite. Als Konsequenz können die Organisationsebene und die IT-Ebene nicht durch Vorgabebeziehungen integriert werden, sondern es müssen alternative Mechanismen gefunden werden. Für Systeme, deren Komponenten eine unterschiedliche Dynamik haben und in denen Veränderungen aus verschiedenen Richtungen erfolgen müssen, bietet sich hierfür das Konzept der Entkopplung an (Aier u. Winter 2009). Im Kontext der Integration von Organisations- und IT-Ebene im Business Engineering bedeutet das, dass Artefakte verschiedener Architekturebenen mit Hilfe indirekter Zuordnungen und idealerweise eines m:n-fähigen, flexiblen Zuordnungsmechanismus („Hub“) zu verknüpfen sind. Das Konzept „Enterprise Application Integration“ (Kaib 2002; Linthicum 2000) stellt ein gutes Beispiel für einen solchen Zuordnungsmechanismus dar. An die Stelle einer Vielzahl von direkten, in ihrer Integrität immer wieder gefährdeten Punkt-zu-Punkt-Verknüpfungen tritt ein Zuordnungssystem, zu dem alle beteiligten Artefakte nur eine einzige Verknüpfung (den sog. „Adapter“) haben. Wenn die Granularität der neu zu schaffenden Verknüpfungsartefakte deutlich geringer ist als die Granularität der zu verknüpfenden Strukturen auf Organisations- und IT-Ebene, kommt zu den Effekten der „Pufferung“ von Änderungen und der Toleranz unvollständiger Konsistenz auch eine starke Reduktion von Artefakt-Zuordnungen hinzu. Diese drei Effekte sollten den zusätzlichen Aufwand der Schaffung einer zusätzlichen Architekturebene und der Bewirtschaftung ihrer Artefaktstrukturen und -beziehungen mehr als aufwiegen. IT/Business Alignment-Ebene als Verknüpfung zwischen Organisations- und ITEbene Die Verknüpfungsartefakte „zwischen“ Organisations- und IT-Artefakte werden auf einer dedizierten IT/Business Alignment-Ebene angesiedelt. Das konzeptionel-

26


le (Struktur-)Modell eines solchen Zuordnungsmechanismus wird als IT/Business Alignment-Architektur bezeichnet. Zur strukturellen Beschreibung der IT/Business Alignment-Architektur sind Artefakttypen zu spezifizieren, welche die direkten Beziehungen zwischen den Artefakten der Organisations- und IT-Architekturen durch • m:1-Beziehungen zwischen den Artefakten der Organisationsebene und den Artefakten der IT/Business Alignment-Ebene sowie • 1:n-Beziehungen zwischen den Artefakten der IT/Business Alignment-Ebene und den Artefakten der IT-Ebene auflösen. Durch die m:1- bzw. 1:n-Abbildung wird ein ausreichend großes Komplexitätsgefälle zwischen der IT/Business Alignment-Architekturebene und den angrenzenden Ebenen erzeugt. Nur auf diese Weise kann eine Interdependenzunterbrechung zwischen Organisations- und IT-Architekturen erreicht werden. Ähnlich wie es innerhalb der fachlichen und IT-Architekturen Aggregationsebenen zur Vereinfachung gibt, müssen auch innerhalb der IT/Business AlignmentArchitektur Aggregationsebenen vorgesehen werden (Stünzer 1996). Organisationsebene Prozess P1 P2

Organisationsebene Prozess P1 P2 Aktivität 1.1

Aktivität 1.2

Aktivität 1.3

Aktivität … 1.4

Aktivität 1.1

Aktivität … 2.1

Aktivität 1.2

Aktivität 1.3

Aktivität … 1.4

Aktivität … 2.1

…

…

IT/Business Alignment-Ebene Domäne D1 D2 Applikation A1.1 Fachlicher Fachlicher Service Service 1.1.1 1.1.2

Softwarekomponente 1.1




…


Softwaresystem S1 S2 Softwareebene

…

…

A1.2 Fachlicher Service 1.2.1

A2.1 … …

Fachlicher Service 2.1.1

… … …

…





…


…

…

Softwaresystem S1 S2 Softwareebene Abb. 13. IT/Business Alignment-Architektur für die entkoppelnde Zuordnung von Organisationsebene und IT-Ebene

Die wichtigsten Artefakttypen auf IT/Business Alignment-Ebene sind fachlicher Service, Applikation und Domäne. Diese Artefakttypen stehen in einer hierarchischen Beziehung zueinander (vgl. Abb. 13). Diese Beziehung muss nicht streng hierarchisch sein und kann somit auch eine Polyhierarchie darstellen. Fachliche Services repräsentieren betriebswirtschaftlich abgeschlossene Funktionsbündel, die aufgrund der gemeinsamen Unterstützung von Geschäftsprozessen, der gemeinsamen Bewirtschaftung von Informationsobjekten oder gemeinsa-


27

mer Wiederverwendung zusammenhängen (Schelp u. Winter 2008) und die durch Applikations-(software-)Komponenten implementiert werden. Da es sich um Funktionsbündel handelt, werden sie durch eine oder mehrere Applikations(software-)Komponenten implementiert (1:n-Beziehung) und können in einem oder mehreren Geschäftsprozessen genutzt werden (m:1-Beziehung). Applikationen sind Gruppierungen fachlicher Services, die zusammen bestimmte Geschäftsprozesse unterstützen, zusammen bestimmte Informationsobjekte bewirtschaften oder zusammen wiederverwendet werden (Winter 2003a). Domänen sind Gruppierungen von Applikationen (und damit indirekt von fachlichen Services), welche aufgrund ihrer Nutzung in zusammenhängenden Geschäftsprozessen, ihrer Unterstützung durch zusammenhängende Applikations-(software-)Komponenten oder ihrer Nutzung zusammenhängender Informationsobjekte einen Integrationsbereich bilden (Hagen 2003). Abb. 13 illustriert die grundlegende Strukturierung der IT/Business AlignmentEbene. Die neue Architekturebene dient allein der „Übersetzung“ der verknüpften Strukturen und ist weder Teil der Organisationsebene noch Teil der IT-Ebene. Sie entkoppelt Artefakte verschiedener Typen. Direkte m:n-Zuordnungen werden zu m:1- bzw. 1:n-Zuordnungen aufgelöst. Die Artefakte auf den entkoppelten Ebenen können unabhängig voneinander verändert werden, ohne dass in jedem Fall die jeweils andere Ebene betroffen sein muss.

Abb. 14. BE-Ebenen

Im Ergebnis entsteht eine Mehrebenenarchitektur, die je nachdem, ob die ITEbene gesamthaft betrachtet oder in eine Software- und eine IT-Infrastrukturebene zerlegt wird, vier bzw. fünf Ebenen umfasst. Die Mehrebenenarchitektur des BE wird durch Abb. 14 illustriert.

28


Andere Umsetzungsebenen In diesem Buch wird allein die IT-Ebene als Umsetzungsebene für Strategie und Organisation betrachtet. Eine ähnliche Rolle wie IT zur Umsetzung fachlicher Strukturierungen von Unternehmen, öffentlicher Verwaltungen und nichtstaatlicher Organisationen haben auch – um einige wenige zu nennen – Mitarbeiterfähigkeiten, finanzielle Ressourcen oder Markenstärke. Insofern ist es denkbar, den hier präsentierten Business Engineering-Ansatz durch alternative Umsetzungsebenen für Mitarbeiterfähigkeiten, finanzielle Ressourcen und/oder Markenstärke zu ergänzen (vgl. Abb. 15). Im Falle solcher Ergänzungen sollten die Strategie- und die Organisationsebene unverändert bleiben können, weil die dortigen Erwägungen ja umsetzungsunabhängig sein sollten – nicht nur von IT, sondern auch von den anderen genannten Umsetzungsaspekten. Ähnlich wie zwischen Organisations- und IT-Ebene muss u. U. die Verknüpfung zu den anderen Umsetzungsebenen ebenfalls über Alignment-Architekturen erfolgen. Zusätzlich müssen Interdependenzen zwischen den Umsetzungsebenen berücksichtigt werden. Ob dies in Form von Ableitungen möglich ist oder ob auch hier entkoppelt werden muss, müssen zukünftige Forschungen untersuchen.

Abb. 15. Mögliche weitere Umsetzungsebenen (neben der IT-Ebene)

Modelltypen Die Architekturebenen strukturieren das BEN-Metamodell in vier bis fünf Submodelle – je eines für jede Ebene. Zwar sind die Kopplungen innerhalb dieser Architekturebenen intensiver als zwischen ebendiesen Ebenen, so dass die Ebenen gut als Komponenten des Metamodells dienen können. Selbst für eine einzelne Ebene sind die Metamodelle jedoch ziemlich komplex, so dass eine weitere Komponentenbildung sinnvoll erscheint.


29

Aus diesem Grund wird das Konzept des Modelltyps eingeführt. Ein Modelltyp ist ein Ausschnitt aus einer ebenenspezifischen BEN-Metamodellkomponente, der besonders stark gekoppelte Artefakttypen innerhalb der entsprechenden Architekturebene umfasst. Besonders stark sind Artefakttypen gekoppelt, die gemeinsam einen bestimmten Sachverhalt abbilden. Ein Beispiel für einen solchen Sachverhalt ist ein Geschäftsprozess, der nicht nur Aufgaben und ihre Abhängigkeiten umfasst, sondern auch die entstehende(n) Prozessleistung(en), die zur Steuerung des Geschäftsprozesses sinnvollen Ziele/Führungsgrößen sowie die für den Prozess verantwortliche(n) Organisationseinheit(en). In diesem Fall bilden die Artefakttypen Geschäftsprozess, Aufgabe, Prozessleistung, Ziel/Führungsgröße und Organisationseinheit sowie die zwischen diesen Artefakten relevanten Beziehungen den Modelltyp „Ablaufmodell“. Modelltypen sind definitionsgemäß immer einer bestimmten Architekturebene zugeordnet. Modelltypen können überlappen, da Artefakttypen zu verschiedenen Modelltypen gehören können.

2.3 Strategieebene 2.3.1 BEN-Metamodellausschnitt der Strategieebene In den vorangegangenen beiden Abschnitten wurden das BEN-Metamodell als Repräsentation des BEN-Gegenstands sowie ein Ebenenkonzept zur Strukturierung ebendieses Gegenstands vorgestellt. Ehe im Folgenden die Ziele, die mit der ersten Ebene – der Strategieebene – dieses Konzepts verbunden sind, und die dazugehörigen Modelltypen vorgestellt werden, wird eine Verknüpfung zwischen der Strategieebene und dem BEN-Metamodell hergestellt (vgl. Abb. 16). Auf der Strategieebene geht es um die strategische Ausrichtung des Unternehmens im Wettbewerb sowie im Hinblick auf die eigenen Kompetenzen. Folglich umfasst der BEN-Metamodellausschnitt der Strategieebene die Entitäten Unternehmen, Markt und Geschäftsfeld. Diese Betrachtung wird weiter vertieft, indem insbesondere die Beziehungen mit Kunden und anderen Geschäftspartnern sowie das Produkt- und Leistungsprogramm analysiert werden. Eine solche Analyse basiert demzufolge auf den Entitäten Geschäftspartner und Geschäftspartnerprozess sowie ihren jeweiligen Spezialisierungen, Fremd- und Eigen-Marktleistungen sowie Kundensegmenten und Kooperationskanälen.

30

Strategieebene

Abb. 16. BEN-Metamodellausschnitt der Strategieebene

2.3.2 Gestaltungsziele auf der Strategieebene und deren Modelltypen Das Gestaltungsziel der Strategieebene besteht darin, die betrachtete Einheit (Unternehmen, aber auch Unternehmensbereich oder Unternehmensnetzwerk) so zu positionieren, dass dessen Marktchancen und Kernkompetenzen optimal kombiniert werden. Um dies zu realisieren, wird auf die Managementlehre bzw. insbesondere auf Ansätze aus dem strategischen Management zurückgegriffen, wobei der Fokus auf solche Aspekte gelegt wird, die für die Analyse und Gestaltung von Geschäftslösungen notwendig sind. Im Detail geht es auf der Strategieebene darum, Ansätze zur Geschäftsnetzwerkkonstruktion (z. B. Hagel u. Singer 1999) mit Ansätzen zur Festlegung der relevanten Geschäftspartnerprozesse (z. B. Heinrich 2002b), Ansätzen zur Festlegung des Produkt- bzw. Leistungssystems (z. B. Jørgensen 2006) und vor allem klassischen Ansätzen zur strategischen Positionierung, wie z. B. „Market-based view“ (z. B. Porter 1999) und „Resource-based view“ (z. B. Prahalad u. Hamel 1990), sowie Ansätzen zur Zielsystem-Bildung (wie z. B. Balanced Scorecard (Kaplan u. Norton 1997)) zusammenzuführen (Alpar et al. 2008). Zur Beschreibung der strategischen Ausrichtung des betrachteten Unternehmens in einem Wertschöpfungsnetzwerk sind vor allem nachstehende fünf Modelltypen relevant, die im Folgenden genauer erläutert werden:


31

• Das Geschäftsnetzwerkmodell (vgl. Abschnitt 2.3.3) beschreibt das Zusammenwirken von Unternehmen oder Geschäftseinheiten in einem Wertschöpfungsnetzwerk mit dem Ziel, Kundenbedürfnisse ganzheitlich abzudecken und dazu entsprechende Einzelkompetenzen zu integrieren. • Das Geschäftspartnerprozessmodell (vgl. Abschnitt 2.3.4) strukturiert einzelne Leistungsbeziehungen in einem Geschäftsnetzwerkmodell durch die Zuordnung der Eigen- und Fremderstellung komplexer Leistungen zu den Bestandteilen komplexer Kundenbedürfnisse. • Das Produkt-/Service-Modell (vgl. Abschnitt 2.3.5) definiert die Produkt- bzw. Service-Architektur der betrachteten Einheit. Dabei stehen weniger die Eigenschaften der Produkte/Services im Vordergrund als vielmehr die grundlegende Strukturierung des Leistungssystems in Form von Produkt-/Servicegruppen und -familien, Produkt-/Serviceplattformen usw. • Das Modell der strategischen Positionierung (vgl. Abschnitt 2.3.6) aggregiert die verschiedenen abgedeckten Kundenprozesse und Leistungen in ein einziges Modell. Dieses positioniert die betrachtete Einheit hinsichtlich Marktverhältnissen und Kernkompetenzen. Hierfür stehen verschiedene Dimensionen inklusive entsprechender Ausprägungen zur Verfügung, die u. a. aus dem „Marketbased view“ und aus dem „Resource-based view“ abgeleitet werden. • Das Modell des Zielsystems (vgl. Abschnitt 2.3.7) definiert zunächst die Organisationsziele und Erfolgsfaktoren des betrachteten Unternehmens, welche die Grundlage für die Ableitung messbarer Kennzahlen bilden. Ferner werden für diese Kennzahlen entsprechende Zielwerte festgelegt. Das Zielsystem kann durch die Spezifikation von Zielzusammenhängen und die Berücksichtigung strategischer Projekte ergänzt werden.

2.3.3 Geschäftsnetzwerkmodell Das Geschäftsnetzwerkmodell stellt ein Grobmodell dar, in dem ein Kundenbedürfnis und die Rollen der verschiedenen Akteure in einem auf das Kundenbedürfnis bezogenen Wertschöpfungsnetzwerk sowie der Leistungsaustausch zwischen den Akteuren abgebildet werden. Im Geschäftsnetzwerkmodell werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Unternehmen: Das betrachtete Unternehmen (bzw. die betrachtete Einheit) übernimmt als Teil der Wertschöpfungskette im Normalfall die Rolle eines Service Integrators, der Vorleistungen integriert und Kundenbedürfnisse damit gesamthaft abzudecken versucht (vgl. Abschnitt 4.2.1.1). • Kunden: Als Kunden werden wichtige Kundenbedürfnisse oder wichtige Kundensegmente abgebildet, welche die strategische Positionierung des betrachteten Unternehmens (bzw. der betrachteten Einheit) determinieren.

32

Strategieebene

• Lieferanten: Lieferanten können je nach strategischer Positionierung aus Sicht des betrachteten Unternehmens (bzw. der betrachteten Einheit) und des betrachteten Kundenbedürfnisses/Kundensegments Service Integrators, Shared Service Providers, Exclusive Service Providers oder Public Services sein (vgl. Abschnitt 4.2.1.1). • Neben der konkreten Rolle in Bezug auf das jeweilige Kundenbedürfnis bzw. -segment wird der darauf bezogene Austausch von Leistungen zwischen den Akteuren sowie die entsprechenden Werteflüsse dargestellt. • Währenddessen Punkt-zu-Punkt-Vernetzungen zwischen den Akteuren des Wertschöpfungsnetzwerks möglich sind, erfolgen solche Vernetzungen im Normalfall aus Effizienzgründen über eine gemeinsame, offene Kollaborationsinfrastruktur („Business Collaboration Infrastructure“ (BCI) (Österle et al. 2001)). In diesem Fall tritt, ähnlich der bereits im Zusammenhang mit der IT/Business Alignment-Ebene beschriebenen Konzepte, an die Stelle einer Vielzahl von Punkt-zu-Punkt-Vernetzungen jeweils nur ein einziger „Adapter“ zur gemeinsamen Infrastruktur. Abb. 17 zeigt den Metamodellausschnitt für den Modelltyp „Geschäftsnetzwerkmodell“.

Abb. 17. Metamodellausschnitt Geschäftsnetzwerkmodell

2.3.4 Geschäftspartnerprozessmodell Die Beschreibungen innerhalb des Geschäftsnetzwerkmodells sind noch relativ grob. Zur feineren Spezifikation erfolgt durch das Geschäftspartnerprozessmodell


33

eine Fokussierung auf eine bestimmte Leistungsbeziehung (vgl. dazu ebenso Österle 2004). Diese kann zwischen der betrachteten Einheit und einem Kunden (Kundenprozess) oder einem Lieferanten (Lieferantenprozess) bestehen. Je nach Branche hat entweder das Kundenprozessmodell (bei vertriebsorientierten Unternehmen und Dienstleistern) oder das Lieferantenprozessmodell (bei großer Bedeutung dieses Aspekts) höhere Bedeutung. Im Geschäftspartnerprozessmodell wird im Rahmen einer im Geschäftsnetzwerkmodell abgebildeten Leistungsbeziehung detailliert, wie ein bestimmtes, komplexes Kunden-(bzw. Lieferanten-)bedürfnis aus der Sicht der betrachteten Einheit strukturiert ist. Zwar gehören Prozesse im Grundsatz auf die Organisationsebene. Da das WIE des Kunden bzw. Lieferanten aber für die strategische Positionierung (das WAS) der betrachteten Einheit wichtig ist, findet sich das Geschäftspartnerprozessmodell auf der Strategieebene. Im Geschäftspartnerprozessmodell werden die einzelnen Teilaspekte des abzudeckenden Kunden- bzw. Lieferantenbedürfnisses strukturiert. Auf dieser Grundlage werden Teilleistungen abgeleitet, die zu erbringen sind, um die verschiedenen Teilaspekte zu unterstützen. Danach ist für jeden Leistungsbestandteil zu prüfen, ob er durch die betrachtete Einheit selbst erbracht werden kann oder ob eine Fremdbeschaffung sinnvoller ist. Nach der Abklärung der Arbeitsteilung im Hinblick auf die zu erbringenden Leistungsbestandteile der betrachteten Einheit und seiner Geschäftspartner müssen geeignete Vertriebs- bzw. Bezugskanäle identifiziert werden, die sich nicht nur auf die Eigen-Marktleistungen, sondern ebenso auf die zu integrierenden Fremd-Marktleistungen beziehen. Folglich ermöglicht das Geschäftspartnerprozessmodell erste Festlegungen in Richtung eines Produktbzw. Servicekatalogs der betrachteten Einheit sowie eine grobe Beschreibung des Leistungsaustauschs mit Geschäftspartnern. Im Geschäftspartnerprozessmodell werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Kunden- bzw. Lieferantenprozess: Der betrachtete Kunden- bzw. Lieferantenprozess wird analysiert, um daraus die zu erstellenden bzw. zu beziehenden Leistungen nach den Prinzipien „one-stop“, „non-stop“ o.ä. abzuleiten (siehe z. B. Kagermann u. Österle 2006). • Eigen- bzw. Fremdmarktleistung: Im Rahmen der Analyse des Geschäftspartnerprozesses ergeben sich elementare Eigen- bzw. Fremdmarktleistungen, die später zum Leistungsprogramm bzw. zum Beschaffungsprogramm verdichtet werden (vgl. Abschnitt 4.2.1.3). • Durch möglichst umfassende Zuordnung von Eigen- bzw. Fremdmarktleistungen zu Kunden- bzw. Lieferantenbedürfniskomponenten wird eine möglichst gesamthafte Abdeckung dieser Bedürfnisse intendiert. • Auch in Kunden- bzw. Lieferantenprozessmodellen kann die Effizienz der Vernetzung erhöht werden, wenn standardisierbare Leistungskomponenten nicht Punkt-zu-Punkt, sondern über die Kollaborationsinfrastruktur ausgetauscht werden. Abb. 18 zeigt den Metamodellausschnitt „Geschäftspartnerprozessmodell“.

34

Strategieebene

Abb. 18. Metamodellausschnitt „Geschäftspartnerprozessmodell“

2.3.5 Produkt-/Service-Modell Das Produkt-/Service-Modell integriert die in einer Vielzahl von Geschäftspartnerprozessmodellen identifizierten Eigen-Marktleistungen. Es dient dazu, die identifizierten Marktleistungen in Form einer Landkarte zu systematisieren. Entsprechend dem BEN-Aggregationsgrad kann das Produkt-/Service-Modell das Leistungsangebot nicht nur einheitsweit umfassend beschreiben, sondern auch für Untereinheiten oder nach sonstigen Erwägungen die angebotenen Produkte bzw. Services in Teilmengen bzw. Leistungskomponenten zerlegen. Im Produkt-/Servicemodell werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Die (Markt-)Leistung entspricht Produkten und Services, die durch die Geschäftsprozesse erzeugt werden müssen. Diese dienen somit als Vorgaben für die Prozessgestaltung auf der Organisationsebene, wo sie Prozessleistungen zugeordnet werden (vgl. Abschnitt 4.2.1.3). • Produkte und Services können aus verschiedenen Komponenten bestehen bzw. in diese zerlegt werden. Im Produktmodell wird also eine Teil-Ganzes- bzw. Dekompositionsbeziehung dargestellt. Abb. 19 zeigt den Metamodellausschnitt „Produkt-/Servicemodell“. Zur Konfiguration von Produkten/Services auf der Grundlage von Komponenten vgl. Abschnitt 2.3.6.


35

Abb. 19. Metamodellausschnitt „Produkt-/Servicemodell“

2.3.6 Modell der strategischen Positionierung Die Geschäftsnetzwerkmodelle liefern erste, kundenbedürfnisspezifische Anhaltspunkte für die strategische Positionierung einer Einheit. Ergänzt werden diese Anhaltspunkte durch die Geschäftspartnerprozessmodelle (für die relevanten Geschäftspartnerprozesse) sowie durch die Produkt-/Service-Modelle auf verschiedenen Aggregations- und Fokusebenen. Allerdings stehen bei allen genannten Modelltypen die Vernetzung mit den Geschäftspartnern sowie die Abdeckung der Kundenbedürfnisse im Vordergrund. Folglich wird primär die Marktperspektive adressiert, was ja angesichts der geforderten „Outside-in“-Orientierung auch sinnvoll ist. Das Modell der strategischen Positionierung fasst die Marktperspektive der betrachteten Einheit in einem einzigen Modell zusammen und ergänzt es um die Ressourcenperspektive (Heinrich 2002a). Die Positionierung der betrachteten Einheit wird also zusammenfassend sowohl hinsichtlich des Wettbewerbs wie auch der eigenen Kompetenzen beschrieben (Heinrich 2002a). Es kann somit als Grundlage für die Diskussion zwischen Entscheidungsträgern sowie für die Prüfung der Konsistenz in Bezug auf die tatsächliche strategische Ausrichtung des betrachteten Unternehmens verwendet werden. Für das Modell der strategischen Positionierung wird der gleiche Konfigurationsmechanismus benutzt wie für Produkte/Services: Es werden zunächst abstrakte Dimensionen und mögliche Ausprägungen dieser Dimensionen definiert. Jedes konkrete Objekt (zu positionierende/s Unternehmen/Einheit, zu konfigurierendes/r Produkt/Service) wird dann den jeweils zutreffenden Ausprägungen zugeordnet. Positionierungs- bzw. Konfigurationsmodelle stellen damit einen Zusammenhang her zwischen: • Referenzierendes Objekt: Dies kann ein Unternehmen/eine Einheit oder ein Produkt/Service sein. • Beschreibungsdimension: Diese kann frei definiert werden.

36

Strategieebene

• Ausprägung: Hier wird festgelegt, welche möglichen Ausprägungen eine Beschreibungsdimension haben kann. • Die Zuordnung von referenzierenden Objekten zu Ausprägungen repräsentiert dann die Konfiguration bzw. Positionierung des jeweiligen Objekts. Abb. 20 zeigt das Metamodell von „Strategische Positionierung“. Aufgrund des generellen Charakters der Konfigurierung sind die entsprechenden MetamodellElemente nicht Teil des BE-Metamodells, sondern generisch.

Abb. 20. Metamodell „strategische Positionierung“

2.3.7 Modell des Zielsystems Das Modell der strategischen Positionierung enthält mit der Beschreibung der eigenen Kompetenzen des betrachteten Unternehmens bereits erste, wenn auch eher implizite Zielfestlegungen. Als Grundlage nicht nur für die strategische Führung, sondern auch für die operative Führung der Geschäftsprozesse bedarf es jedoch einer umfassenderen Beschreibung des Zielsystems der betrachteten Einheit. Das Zielsystem beinhaltet zunächst eine Festlegung von (Unternehmens-)Zielen, die ein ausgewogenes Portfolio an strategischen Zielen darstellen sollten. Darüber hinaus werden die positiven und negativen Zusammenhänge zwischen diesen Zielen analysiert und in einer Ziellandkarte veranschaulicht. Danach wird eine Operationalisierung der festgelegten Ziele in Form von Erfolgsfaktoren und Kennzahlen/Führungsgrößen vorgenommen. Diese bilden die Grundlage für die Umsetzung des Zielsystems in der Prozessmodellierung bzw. für die operative Führung der Geschäftsprozesse. Daneben besteht die Möglichkeit, das definierte Zielsystem sowohl mit der Maßnahmenplanung/-steuerung wie auch mit der Budgetplanung/-steuerung zu verknüpfen. Schließlich kann das definierte Zielsystem ebenso zur Rückführung von Ist-Werten aus PerformanceManagement-Systemen in die Unternehmenssteuerung genutzt werden.


37

Im Modell des Zielsystems werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • (Unternehmens-)Ziele stellen die grundsätzliche Zielstellung des Unternehmens dar. Sie können für Organisationseinheiten sowie für Geschäftsprozesse gelten (vgl. Abschnitt 0). • Die Messung der Ziele erfolgt an Hand von Erfolgsfaktoren. Beispielsweise kann die Erhöhung der Kundenzufriedenheit an Hand der Wiederholungskäufer im Retail-Geschäft gemessen werden. • Kennzahlen bzw. Führungsgrößen (diese beiden Begriffe werden in BEN als Synonyme verwendet) operationalisieren die Erfolgsfaktoren durch Größen, die eindeutig und willkürfrei „gezählt, gemessen oder gewogen“ werden können. • Zielwerte ordnen den Kennzahlen bzw. Führungsgrößen konkrete Werte zu, die zu einem bestimmten Zeitpunkt oder in einem bestimmten Zeitraum erreicht werden sollen. • Wenn Zielwerte und gemessene Ist-Werte differieren, können entsprechende Maßnahmen zur operativen Steuerung definiert werden. Abb. 21 zeigt den Metamodellausschnitt „Zielsystem“.

Abb. 21. Metamodellausschnitt „Zielsystem“

38

Organisationsebene

2.4 Organisationsebene 2.4.1 BEN-Metamodellausschnitt der Organisationsebene In Analogie zu Abschnitt 2.3.1 wird in diesem Abschnitt eine Verknüpfung des BEN-Metamodells mit der Organisationsebene hergestellt. Auf der Organisationsebene steht die Betrachtung des „wie“, d. h. die Umsetzung strategischer Festlegungen, im Vordergrund. Folglich lassen sich Ablauforganisation und Aufbauorganisation sowie die jeweiligen Entitäten, in die diese dekomponiert werden können, der Organisationsebene zuordnen. Sowohl die Aufbau- als auch die Ablauforganisation werden mittels eines Zielsystems gesteuert, in dessen Rahmen auf der Organisationsebene Prozessführungsgrößen definiert werden. Abb. 22 vermittelt einen Überblick über die Entitäten des BEN-Metamodells der Organisationsebene.

Abb. 22. BEN-Metamodellausschnitt der Organisationsebene


39

2.4.2 Gestaltungsziele auf der Organisationsebene und deren Modelltypen Ausgehend von der strategischen Ausrichtung der betrachteten Einheit ist es das Ziel der Organisationsebene, die Ablauf- und Aufbauorganisation sowie die Informationsverarbeitung (damit sind nicht IT-Systeme gemeint!) derart zu gestalten, dass diese unter Berücksichtigung der festgelegten Zielvorgaben (Effizienz, „Dinge richtig tun“) die spezifizierten Eigen-Marktleistungen in der spezifizierten Qualität und Quantität erzeugen (Effektivität, „das Richtige tun“). Hierfür wird zunächst „im Großen“ das Zusammenspiel der Geschäftsprozesse (Prozesslandkarte, vgl. Abschnitt 2.4.3) spezifiziert. Prozesslandkarten müssen u. U. mehrfach zerlegt werden, um die Ebene der Beschreibung einzelner Geschäftsprozesse zu erreichen. Für jeden Geschäftsprozess werden dann „im Detail“ die zu erbringenden Prozessleistungen (Prozessleistungsmodell, vgl. Abschnitt 2.4.4) aus den Produkt-/Service-Modellen abgeleitet, die auf der Strategieebene festgelegt wurden. Daneben erfolgt im Rahmen der Prozesssteuerung die Ableitung konkreter Prozess-Führungsgrößen (Steuerungsmodell, vgl. Abschnitt 2.4.5) aus den strategischen Führungsgrößen, die auf der Strategieebene festgelegt wurden. Beide Modelltypen bilden die Grundlage, um die für die Erbringung der Prozessleistungen notwendigen Aufgaben einschließlich ihrer Abfolge (Ablaufmodell, vgl. Abschnitt 2.4.6) festzulegen. Die einzelnen Aufgaben werden durch verschiedene Organisationseinheiten ausgeführt. Folglich ist auf der Organisationsebene die Aufbauorganisation (Aufbauorganisationsmodell, vgl. Abschnitt 2.4.7) festzulegen. Diese umfasst die Spezifikation von Organisationseinheiten (allenfalls auch mit Standorten), Stellen (allenfalls auch Mitarbeitenden) sowie Rollen. Für die Ausführung von Geschäftsprozessen werden Informationen benötigt und bei der Ausführung fallen auch Informationen an. Informationsflüsse verlaufen oft nicht parallel zum Prozessablauf. Deshalb müssen sie aus fachlicher Sicht spezifiziert und zwischen Prozessen und Stellen abgebildet werden (Informationsmodell, vgl. Abschnitt 2.4.8). Organisationsmodellierung basiert auf Vorgaben aus der Strategieebene. Andererseits erfordern die meisten Geschäftsprozesse intensive IT-Unterstützung, so dass eine intensive Abstimmung der fachlichen Modelle mit der IT-Ebene notwendig ist (IT/Business Alignment). Die Organisationsgestaltung stellt mithin das Bindeglied zwischen der Strategieentwicklung und der Gestaltung der IT-Ebene dar (Österle 1995).

2.4.3 Prozesslandkarte In einem Unternehmen wirken verschiedene Arten von Geschäftsprozessen zusammen: Leistungsprozesse (oder Geschäftsprozesse im engeren Sinne), Füh-

40

Organisationsebene

rungsprozesse und Unterstützungsprozesse (Dubs et al. 2004). Aufgabe der so genannten Prozesslandkarte, die auch als Prozessarchitekturmodell bezeichnet werden kann, ist es, die aggregierten Geschäftsprozesse und ihr Zusammenwirken „im Großen“ abzubilden. Prozesslandkarten können auf verschiedenen Aggregationsgraden definiert werden, wobei die einzelnen Prozesse auf jedem Aggregationsgrad spezialisiert und/oder dekomponiert werden können. Auf dem höchsten Aggregationsgrad werden Makroprozesse mit dem größten Einfluss auf die Wettbewerbsfähigkeit modelliert. Im Normalfall werden Prozesslandkarten auf den Aggregationsgraden A0 und A1, ggf. ebenfalls A2 abgebildet. Auf den nächst feineren Aggregationsgraden (also A1 und A2 oder A2 und A3) werden (Gesamt-)Geschäftsprozesse und schließlich auf den granularsten Aggregationsgraden (also ab A3 bzw. ab A4) Teilprozesse abgebildet (vgl. Abschnitt 2.4.6). Prozesslandkarten bilden folglich die Navigationsgrundlage in die Detailprozesse und diese in die Teilprozesse. In der Prozesslandkarte werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Die Prozesslandkarte erlaubt es, Prozesse in Teilprozesse zu zerlegen (Dekomposition). Bei der Definition von Prozessen können grundsätzlich Leistungsprozesse, Unterstützungsprozesse und Führungsprozesse unterschieden werden (vgl. Abschnitt 4.3.1.1). • Geschäftsprozesse werden von Organisationseinheiten ausgeführt. Dementsprechend findet in der Prozesslandkarte eine grobe Zuordnung der Prozesse über entsprechende Aufgaben zu den verantwortlichen bzw. ausführenden Rollen statt. • Prozesse können untereinander verbunden werden, um z. B. Reihenfolgebeziehungen abzubilden. Abb. 23 zeigt den Metamodellausschnitt „Prozesslandkarte“.

Abb. 23. Metamodellausschnitt „Prozesslandkarte“


41

2.4.4 Prozessleistungsmodell Basierend auf den zuvor definierten Prozessmodellen können in einem weiteren Schritt so genannte Prozesskontextdiagramme (vgl. Abb. 24) abgeleitet werden, die auf einen Geschäftsprozess fokussieren und diesen zusammen mit seinen Schnittstellen zu anderen Prozessen darstellen. Der Fokus von Prozesskontextdiagrammen ist nicht mehr die Dokumentation des Zusammenspiels von Prozessen oder Teilprozessen, sondern die Verfeinerung der Beschreibung des Leistungsaustausches zwischen Prozessen und damit die Grundlage des detaillierten Prozessleistungsmodells.

Abb. 24. Prozesskontextdiagramm

Die auf der Strategieebene und in der Prozesslandkarte bisher nur benannten Leistungen werden nun detaillierter beschrieben. Um zusätzliche Leistungsinformationen zu spezifizieren, wird das Leistungsverzeichnis benutzt (vgl. Tab. 1). Im Leistungsverzeichnis können Informationen wie z. B. adressierte Kundensegmente, geeignete Vertriebskanäle, grundlegende Qualitätsmerkmale, technische Produktspezifikationen oder finanzielle Kennzahlen zusammengetragen werden (IMG 1997b). Tab. 1.

Leistungsverzeichnis

Leistung

Beschreibung

Reisekonfiguration

Dem Kunden wird eine mögliche Konfiguration von Reisekomponenten angeboten.

Kontextabhängige Zusatzangebote

Der Kunde erhält nach seinen individuellen Wünschen Zusatzangebote vor Ort, z. B. Informationen über Stadtführungen, Touren oder Kulturangebote.

Hotline

Der Kunde kann sich über eine Hotline auch während des Reiseaufenthaltes an den Reiseveranstalter wenden.

42

Organisationsebene

Sowohl die Prozesskontextdiagramme wie auch die Leistungsverzeichnisse stellen wesentliche Bestandteile des Prozessleistungsmodells dar, mit denen die durch einen Geschäftsprozess erzeugten Leistungen bzw. deren Bestandteile genauer spezifiziert werden können. Daneben wird dem so genannten Qualitätsprofil ein hoher Stellenwert beigemessen. Mit diesem kann beurteilt werden, welche Bedeutung die identifizierten Leistungsbestandteile für die jeweiligen (Prozess-)Kunden haben (IMG 1997b). Ferner kann anhand dieses Profils die Qualität der Leistungen – ebenso im Vergleich zu den Leistungen des wichtigsten Mitbewerbers – eingeschätzt werden. Abb. 59 in Kapitel 4 zeigt in Anlehnung an (IMG 1997b) ein Beispiel für ein Qualitätsprofil für die Leistung Erholungsreise für Familien. Im Rahmen des Prozessleistungsmodells werden Prozessleistungen spezifiziert und Geschäftsprozessen zugeordnet. Abb. 25 zeigt den Metamodellausschnitt „Prozessleistungsmodell“.

Abb. 25. Metamodellausschnitt „Prozessleistungsmodell“

2.4.5 Steuerungsmodell Auf der Strategieebene werden mit der Definition des Zielsystems die (Unternehmens-)Ziele, die kritischen Erfolgsfaktoren sowie die (strategischen) Führungsgrößen festgelegt (vgl. Abschnitt 2.3.7). Um den direkten Bezug zwischen den strategischen Führungsgrößen und den im vorherigen Abschnitt spezifizierten Prozessleistungen bzw. den diese Leistungen direkt oder indirekt erzeugenden Aufgaben herstellen zu können, werden so genannte Prozess-Führungsgrößen eingeführt (IMG 1997b). Als Prozess-Führungsgröße sollten solche Größen ausgewählt werden, die zum einen geeignet sind, den Zustand einer Aufgabe zu charakterisieren, und zum anderen direkt, genau und zeitnah gemessen werden können. Im Rahmen des Steuerungsmodells werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Der Geschäftsprozess, welcher in der Prozesslandkarte definiert wurde, wird hier noch einmal aufgeführt. • Prozess-Führungsgrössen stellen operationalisierte Ziele dar, die den Prozessen zugeordnet werden. Sie geben Zielvorgaben für die Durchführung der Prozesse zur Erfüllung der geplanten Leistungen. • Der Zielwert bestimmt den konkreten Wert einer Kennzahl.


43

Abb. 26 zeigt den Metamodellausschnitt “Steuerungsmodell”.

Abb. 26. Metamodellausschnitt „Steuerungsmodell“

2.4.6 Ablaufmodell Mit Hilfe von Prozesslandkarten, Prozessleistungsmodellen und Steuerungsmodellen können Geschäftsprozesse bereits weitgehend hinsichtlich Effektivität und Effizienz strukturiert werden. Mit Hilfe von Ablaufmodellen wird nun die Aufgabenebene spezifiziert, d. h. es wird festgelegt, welche Aufgaben in einem Geschäftsprozess(teil) in welcher Reihenfolge bzw. welche gleichzeitig durchzuführen sind. Ein Beispiel für ein Ablaufmodell wird in Kapitel 4 in Abb. 60 dargestellt. Auch Ablaufmodelle können bei Bedarf immer weiter verfeinert werden. In den meisten Fällen werden Geschäftsprozesse zunächst in Teilprozesse zerlegt, ehe eine Verfeinerung bis auf die Ebene von Aufgaben und ihrer elementaren Zusammenhänge durchgeführt wird. Aufgaben werden dabei als kleinste Verrichtungseinheit aus fachlicher Sicht verstanden. Unter elementaren Zusammenhängen zwischen Aufgaben (bzw. Teilprozessen) sind insbesondere Reihenfolgeabhängigkeiten und Nebenläufigkeiten zu verstehen. Ebenso einen Bestandteil von Ablaufmodellen können Organisationseinheiten bilden, die den identifizierten Aufgaben zugeordnet werden. Sie bilden die Grundlage für die Ableitung der Aufbauorganisation, die im folgenden Abschnitt adressiert wird. Im Ablaufmodell werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Eine Aufgabe stellt einen Teil eines Geschäftsprozesses dar, der in der Prozesslandkarte (s. o.) spezifiziert wurde. Sie ist der kleinste, nicht mehr teilbare Bestandteil eines Prozesses und kann einer ausführenden Rolle zugeordnet werden. • Entsprechend der ausführenden Rolle wird der Aufgabe eine Organisationseinheit zugeordnet. • Abhängigkeit zwischen Aufgaben: Zwischen den Aufgaben können Vorgänger-Nachfolger sowie Nebenläufigkeiten definiert werden. Ein detailliertes Ab-

44

Organisationsebene

laufmodell definiert darüber hinaus logische Verknüpfungen mit „und“ bzw. „oder“-Verzweigungen. Abb. 27 zeigt den Metamodellausschnitt “Ablaufmodell”.

Abb. 27. Metamodellausschnitt „Ablaufmodell“

2.4.7 Aufbauorganisationsmodell Im Gegensatz zum Ablaufmodell, das die ablaufbezogenen Aspekte einer Organisation beschreibt, zielt das Aufbauorganisationsmodell darauf ab, strukturelle Aspekte zu beschreiben. Hierunter werden Organisationseinheiten verstanden, die die Aufgaben der im Ablaufmodell beschriebenen (Teil-)Prozesse durchführen. Durch das Aufbauorganisationsmodell werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Die Grundstruktur eines Unternehmens bilden Organisationseinheiten, die hierarchisch strukturiert sind. • Um die Organisationseinheiten auf abstrakter Ebene näher zu spezifizieren, können diesen Standorte zugewiesen werden. • Auf der niedrigsten Hierarchiestufe befinden sich Stellen, die von einem oder mehreren Mitarbeitenden besetzt werden. Unter einer Stelle wird dabei eine Zusammenstellung an Aufgaben verstanden, die von einem VollzeitMitarbeitenden übernommen werden kann und ihn/sie vollumfänglich auslastet. • Das Konzept der Rolle dient als Bindeglied zwischen der Aufbau- und Ablauforganisation (Fischer 2008). Eine Rolle stellt dabei eine aufbauorganisatorische Abstraktion dar, die mit einer oder mehreren Aufgaben verknüpft werden können (Fischer 2008). Durch Rollen werden die minimalen Qualifikationen, die für die Ausführung der Aufgabe(n) gefordert sind, sowie die Verantwortlichkeiten und Verfügungsrechte, die dem Träger der Rolle übertragen werden, spezifiziert (Fischer 2008). • Ein Mitarbeiter stellt genau eine Person dar, die Teil einer Organisationseinheit sein und eine Stelle oder Rolle ausfüllen kann.


45

Abb. 28 zeigt den Metamodellausschnitt “Aufbauorganisationsmodell”.

Abb. 28. Metamodellausschnitt „Aufbauorganisationsmodell“

Neben Weisungsrechten können in einem Aufbauorganisationsmodell ebenso Kommunikationsbeziehungen abgebildet werden. Diese sind jedoch nicht mit Informationsflüssen zu verwechseln, die im folgenden Abschnitt adressiert werden.

2.4.8 Informationsmodell In Geschäftsprozessen werden Informationen erzeugt und ebenso verarbeitet. Aufgrund diverser Unterschiede zwischen Informationen und physischen Gütern, die ebenso in Geschäftsprozessen erzeugt bzw. verarbeitet werden, ist zur Darstellung der Informationen eine gesonderte Modellierung erforderlich: Im Gegensatz zu physischen Gütern, die nur einmal existieren können, besteht bei Informationen die Möglichkeit, von ihnen Kopien vorzuhalten, deren Konsistenz sichergestellt werden muss. Dies kann durch die Modellierung von Abhängigkeiten zwischen Informationen gewährleistet werden. Neben solchen Abhängigkeitsbeziehungen können Informationen ebenso auf andere Art und Weise miteinander verknüpft sein. Zur Verdeutlichung sollen die folgenden Beispiele dienen: (1) Kostenstellenbudgets können als Zerlegung bestimmter Bereichsbudgets angesehen werden. (2) Jeder Kontostand repräsentiert eine Aggregation bestimmter Umsätze eines betrachteten Kontos. (3) Aufträge verweisen auf (bestellte) Produkte und (bestellende) Kunden und damit ebenso implizit auf deren Eigenschaften, wie z. B. Preise oder Lieferkonditionen. Folglich müssen Informationen anders modelliert werden als Aktivitäten oder Geschäftsprozesse.

46

IT/Business Alignment-Ebene

Um den beschriebenen Anforderungen und Besonderheiten von Informationen gerecht zu werden, wird auf der Organisationsebene ein Informationsmodell spezifiziert. Wie der Name schon sagt, bildet das Informationsmodell die Informationsobjekte und ihre Beziehungen untereinander ab. Ein Informationsobjekt repräsentiert eine für das Geschäft relevante Information. Es kann Beziehungen zu anderen Informationsobjekten haben. Diese können in Generalisierungs-/Spezialisierungsbeziehungen, Aggregations-/Dekompositionsbeziehungen sowie Assoziationsbeziehungen unterschieden werden. Abb. 29 zeigt den Metamodellausschnitt „Informationsmodell“.

Abb. 29. Metamodellausschnitt „Informationsmodell“

2.5 IT/Business Alignment-Ebene 2.5.1 BEN-Metamodellausschnitt der IT/Business AlignmentEbene Die IT/Business Alignment-Ebene beschreibt den Zusammenhang zwischen fachlichen Strukturen (z. B. Aktivitäten oder Informationen), die auf der Organisationsebene abgebildet werden, und IT-Strukturen (z. B. Softwarekomponenten oder Datenstrukturen), die auf der Softwareebene modelliert werden. Durch die Beschreibung dieses Zusammenhangs und folglich der Entkopplung von Punkt-zuPunkt-Verbindungen zwischen der Organisations- und der Softwareebene wird den Integrationserfordernissen des IT/Business Alignment explizit Rechnung getragen (Aier u. Winter 2009). Auf der IT/Business Alignment-Ebene werden Capabilities bzw. fachliche Services, Applikationen und Domänen repräsentiert. Es handelt sich dabei sämtlich um virtuelle Artefakte, die in einer hierarchischen Beziehung zueinander stehen (Aier u. Winter 2009). Capabilities bzw. fachliche Services stellen die elementarsten Artefakte auf der IT/Business Alignment-Ebene dar. Sie können zu Applikationen gruppiert werden; Applikationen wiederum können zu Domänen zusammengefasst werden (Aier u. Winter 2009).


47

Der Unterschied zwischen Capabilities und fachlichen Services besteht darin, wie die entsprechenden elementaren Zusammenhänge zwischen Organisationsund IT-Artefakten strukturiert sind: Capabilities sind traditionell entlang von Informationsstrukturen oder Prozessen strukturiert, fachliche Services dagegen serviceorientiert (vgl. Abschnitt 4.4.1). Im BEN-Metamodell werden Capabilities und fachliche Services vereinfachend als „Fachlicher Service“ dargestellt. Der Metamodell-Ausschnitt der IT/Business Alignment-Ebene wird in Abb. 30 dargestellt.

Abb. 30. BEN-Metamodellausschnitt der IT/Business Alignment-Ebene

2.5.2 Gestaltungsziele auf der IT/Business Alignment-Ebene und deren Modelltypen Da es sich bei den Entitäten der IT/Business Alignment-Ebene ausschließlich um virtuelle Artefakte handelt, sind mit der Gestaltung und dem Management dieser Ebene ebenso andere Zielstellungen verbunden als bspw. mit der Organisationsoder der Softwareebene (Aier u. Winter 2009). Grundsätzlich können fünf verschiedene Gestaltungsziele unterschieden werden, die aufeinander aufbauen (Alpar et al. 2008; Aier u. Winter 2009): • Transparenz: Die Grundlage aller folgenden Ziele bildet das Gestaltungsziel der Transparenz, das im Zusammenhang mit der IT/Business Alignment-Ebene die Dokumentation der Beziehungen zwischen fachlichen und IT-bezogenen Strukturen in den Vordergrund stellt. Dadurch soll es z. B. ermöglicht werden, eine fehlende Abdeckung von fachlichen Bedarfen oder nicht mehr benötigte IT-Funktionalitäten zu erkennen. • Konsistenz: Nach Erreichung des Transparenzziels kann das Gestaltungsziel verfolgt werden, Konsistenz zu schaffen bzw. zu erhöhen. Dies kann erreicht werden, indem optimale Kopplungen zwischen den fachlichen und den IT-

48

IT/Business Alignment-Ebene

bezogenen Strukturen identifiziert werden, wobei es stets den Integrationsaufwand im Verhältnis zum Integrationsnutzen abzuwägen gilt. • Vereinfachung: Wenn das Konsistenzziel erreicht wurde, kann das Gestaltungsziel der Vereinfachung verfolgt werden. Um dieses Ziel zu erreichen, sollten bspw. Redundanzen beseitigt werden. Darüber hinaus sollten – wo sinnvoll – Vereinheitlichungen, z. B. durch Standardisierungen, durchgeführt werden. • Flexibilisierung: Aufbauend auf der Erreichung der vorangegangenen Ziele, besteht das Flexibilisierungsziel darin, eine bessere Anpassbarkeit an heute bereits absehbare/planbare Anpassungsbedarfe zu erreichen. Dies kann zum einen dadurch gelingen, dass sowohl die fachlichen als auch die IT-bezogenen Strukturen explizit änderungsfreundlich gestaltet werden. Zum anderen unterstützt die IT/Business Alignment-Ebene dabei, dass nicht alle Änderungen der Organisationsebene zu Änderungen auf der Softwareebene führen und umgekehrt, da einige Änderungen durch eine Neuordnung der Artefakte auf der IT/Business Alignment-Ebene abgefangen werden können. • Agilität: Als letztes Ziel kann aufbauend auf dem Flexibilisierungsziel die Erhöhung der Agilität verfolgt werden. Im Unterschied zur Erhöhung der Flexibilität geht es bei der Agilität nicht darum, absehbare bzw. bekannte Anpassungsbedarfe zu adressieren, sondern auf zukünftige, noch nicht spezifizierbare Änderungsbedarfe vorbereitet zu sein. Um diese Ziele zu erreichen, stehen auf der IT/Business Alignment-Ebene drei Modelltypen zur Gestaltung der Beziehungen zwischen fachlichen und ITbezogenen Strukturen zur Verfügung. Hierzu zählen das Modell der Capabilities/Fachlichen Services (vgl. Abschnitt 2.5.3), die Applikationslandschaft (vgl. Abschnitt 2.5.4) und das Domänenmodell (vgl. Abschnitt 2.5.4).

2.5.3 Modell der Capabilities/Fachlichen Services Capabilities bzw. fachliche Services stellen die kleinste der hierarchisch strukturierten Entitäten der IT/Business Alignment-Ebene dar. Mittels dieser Entitäten werden (logische) betriebswirtschaftlich abgeschlossene Funktionsbündel repräsentiert, die einen Zusammenhang aufweisen, da sie als Bündel entweder Geschäftsprozesse unterstützen oder der gemeinsamen Bewirtschaftung eines Informationsobjekts dienen (Aier u. Winter 2009). Die Umsetzung von Capabilities/ Fachlichen Services erfolgt durch Softwarekomponenten, die Bestandteil der Softwareebene sind, wobei eine Capability bzw. ein fachlicher Service durch eine oder mehrere Softwarekomponenten (1:n-Beziehung) implementiert werden kann (Aier u. Winter 2009). Die Bündelung kann serviceorientiert erfolgen, wenn es wichtig ist (Alpar et al. 2008; Schelp u. Winter 2008), eine lose Kopplung zwischen fachlichen Services sicherzustellen und durch Re-Komposition bestehender fachlicher Services so


49

viele Varianten eines Geschäftsprozesses wie möglich zu unterstützen. Sachlogisch eng zusammen hängende Capabilities bzw. fachliche Services werden üblicherweise in Applikationen zusammengefasst, welche im Folgenden beschrieben werden.

2.5.4 Applikationslandschaft und Domänenmodell Für die Gestaltung von Applikationen auf der IT/Business Alignment-Ebene kann der Modelltyp Applikationslandschaft verwendet werden. Unter einer Applikationslandschaft wird ein aggregiertes Modell des Zusammenwirkens der Applikationen aus fachlicher Sicht verstanden, wobei die Abbildung der existierenden Applikationen einschließlich deren Schnittstellen im Vordergrund der Betrachtung steht (Alpar et al. 2008). Folglich dient die Applikationslandschaft dazu, sowohl Transparenz über die existierenden Applikationen als auch über die Abhängigkeiten zwischen ebendiesen Applikationen zu erhalten. Durch die Applikationslandschaft werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Applikationen stellen Gruppierungen von Capabilities/Fachlichen Services dar, die zusammen Geschäftsprozesse unterstützen oder zusammen der Bewirtschaftung von Informationsobjekten dienen (Aier u. Winter 2009). An den Schnittstellen zwischen den Applikationen, die zusammenarbeiten, werden Datenobjekte ausgetauscht, die als Informationsträger dienen. Diese Austauschbeziehungen darzustellen, ist Kernaufgabe der Applikationslandschaft. • Applikationen können nach fachlichen Gesichtspunkten in Domänen eingeteilt werden. Domänen werden üblicherweise ebenfalls (als Aggregate) in der Applikationslandkarte dargestellt und im Folgenden näher erläutert. Domänen stellen Gruppierungen von Applikationen dar und gruppieren folglich mittelbar fachliche Services (Aier u. Winter 2009). Domänen bilden logische Integrationsbereiche, die sich aufgrund der Nutzung in zusammenhängenden Geschäftsprozessen oder der zusammenhängenden Bewirtschaftung von Informationsobjekten ergeben (Aier u. Winter 2009). Domänen sind charakterisiert durch eine gekapselte Funktionalität, die innerhalb der Domänen redundanzfrei ist, sowie durch Informationsobjekte, die in Domänen konsistent enthalten sind. Für die Bildung von Domänen können verschiedene Dimensionen wegweisend sein: Die Domänenbildung kann sich bspw. an Geschäfts- oder Marktbereichen, an Geschäftsfunktionalitäten oder -prozessen, an Geschäftsobjekte, ggf. an Technologien oder der Kombination einzelner bzw. mehrerer dieser Dimensionen orientieren. Zum einen zielt die Bildung von Domänen auf die Strukturierung der Gesamtarchitektur und damit auf eine Reduktion bzw. die Handhabbarkeit der Komplexität ab. Gleichzeitig geht es bei der Domänenbildung darum, lokale Konsistenz zu

50

Software- und IT-Infrastrukturebene

schaffen sowie Redundanzen, z. B. in Bezug auf Funktionen oder Daten, aufzudecken. Darüber hinaus können auf Basis gebildeter Domänen organisatorische Verantwortlichkeiten zugewiesen werden und es besteht die Möglichkeit, Domänen als Leitbild für die Architekturentwicklung, z. B. im Hinblick auf das Konzept serviceorientierter Architekturen, zu verwenden.

2.6 Software- und IT-Infrastrukturebene 2.6.1 BEN-Metamodellausschnitt der Software- und ITInfrastrukturebene Die Software- und IT-Infrastrukturebenen beschreiben die Umsetzung der Geschäftslösungen, wobei auf der Softwareebene Softwarekomponenten sowie Datenstrukturen und auf der IT-Infrastrukturebene Hardwarekomponenten im Vordergrund stehen. Auf der Softwareebene spiegelt sich dies im BEN-Metamodell durch die Entitäten Datenelement und Applikations-(software-)Komponente wieder. Über Capabilities/Fachliche Services erfolgt die Kopplung von Applikations-(software-)Komponenten zur IT/Business Alignment-Ebene. Darüber hinaus können auf der Softwareebene auch Systemsoftware-Komponenten modelliert werden, falls dies für die Analyse bzw. Gestaltung von Geschäftslösungen wichtig sein sollte. Jede Art von Software benötigt zur Ausführung entsprechende Hardware bzw. IT-Netzwerke. Um diese abzubilden, steht auf der IT-Infrastrukturebene die Entität Hardware zur Verfügung. Mittels dieser Entität lassen sich beispielsweise physische und virtuelle Server sowie Servercluster abbilden.

Abb. 31. BEN-Metamodellausschnitt der Software- und IT-Infrastrukturebene


51

Abb. 31 zeigt den Ausschnitt des BEN-Metamodells der Software- und ITInfrastrukturebene.

2.6.2 Gestaltungsziele auf der Software- und ITInfrastrukturebene sowie deren Modelltypen Im Sinne eines ganzheitlichen Ansatzes des BE bzw. des BEN ist es u. U. notwendig, Software- und Datenstrukturen sowie die dazugehörige Hardware bzw. IT-Infrastruktur abzubilden. Für die Abbildung der Konstrukte auf der Softwareebene stellt BEN deshalb zwei Modelltypen zur Verfügung: die Softwarearchitektur (vgl. Abschnitt 2.6.3) und die Datenarchitektur (vgl. Abschnitt 2.6.4). Die Gestaltung von Softwarekomponenten und Datenelementen zielt dabei insbesondere darauf ab, eine hohe Änderungsfreundlichkeit sowie eine gute Wiederverwendbarkeit der Konstrukte auf der Softwareebene zu erreichen. Für die Abbildung der Hardware auf der IT-Infrastrukturebene stellt BEN das Modell der IT-Infrastruktur (vgl. Abschnitt 2.6.5) zur Verfügung. Mit der Gestaltung der IT-Infrastruktur sind dabei Ziele, wie Skalierbarkeit, Zuverlässigkeit und/oder Performanz, verbunden. Obgleich eine Abbildung der Konstrukte der Software- und der IT-Infrastrukturebene mit dem BEN-Ansatz möglich ist, so bildet die Gestaltung und Evolution ebendieser Konstrukte keinen Bestandteil mehr. Hierfür wird auf die entsprechende Gestaltungs- und Evolutionsmethodik aus dem Software Engineering einschließlich des Requirements Engineering verwiesen. Zusammenfassend kann festgehalten werden, dass die Softwareebene und die IT-Infrastrukturebene die Realisierungssicht der im BEN-Ansatz beschriebenen Geschäftslösungen bilden und nur insofern in BEN modelliert und bewirtschaftet werden, wie dies aus fachlicher Sicht sinnvoll erscheint.

2.6.3 Softwarearchitektur Die Modellierung der Softwarearchitektur stellt einen wesentlichen Bestandteil der Modellierung auf der Softwareebene dar. Sie bildet zusammen mit der fachlichen Modellierung die Grundlage für ein systematisches IT/Business Alignment. Eine Softwarearchitektur soll Transparenz hinsichtlich der relevanten Applikations-(software-)Komponenten sowie der relevanten Datenflüsse zwischen ebendiesen Komponenten ermöglichen. Aufgrund der oftmals hohen Komplexität der Softwarearchitektur der betrachteten Einheit werden im Normalfall lediglich Ausschnitte dieser Architektur modelliert. Der Begriff Applikationssoftwarekomponente wurde gewählt, um deutlich zu machen, dass in BEN keine Systemsoftware-

52


komponenten abgebildet werden. Im BEN-Kontext kann statt Applikationssoftwarekomponente deshalb auch der vereinfachte Begriff Softwarekomponente benutzt werden. Durch die Softwarearchitektur werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • (Applikations-)Softwarekomponenten können hierarchisch strukturiert sein. Sie bilden Bestandteile von (Applikations-)Softwaresystemen ab und sind nach technischen Gesichtspunkten strukturiert. Softwarekomponenten benötigen informationstechnische Komponenten (z. B. Server) für ihren Einsatz. • Zwischen den Softwarekomponenten werden Datenelemente über Schnittstellen ausgetauscht. Diese bilden die notwendigen Datenflüsse zwischen den Komponenten ab. Abb. 32 zeigt den Metamodellausschnitt „Softwarearchitektur“.

Abb. 32. Metamodellausschnitt „Softwarearchitektur“

2.6.4 Datenarchitektur Um ein systematisches IT/Business Alignment durchführen zu können, müssen nicht nur die Softwarekomponenten, sondern ebenso aggregierte Datenstrukturen abgebildet werden. Hierfür werden Datenarchitekturen verwendet, die im Normalfall „flach“ und in einem einzigen Modell abgebildet werden. Im Unterschied zur Informationslandkarte, die auf der Organisationsebene modelliert wird und fachlich strukturierte Informationsobjekte enthält, werden auf der Softwareebene mittels der Datenarchitektur implementierte Datenstrukturen abgebildet, die informationstechnisch strukturiert sind. Dieser Sachverhalt soll an einem Beispiel verdeutlicht werden, wobei davon ausgegangen wird, dass das betrachtete Unternehmen Kundeninformationen vorhält, die über verschiedene Systeme verteilt sind. Auf der Informationslandkarte sind diese Informationen nur einmal in Form des Informationsobjekts „Kunde“ wiederzufinden. Im Gegensatz dazu beschreibt die Datenarchitektur die Haltung von Teil-Kundendaten in den verschiedenen Datenbanken.


53

Durch die Datenarchitektur werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: • Logische Datenobjekte repräsentieren Informationsobjekte (s. o.) und werden wiederum von (technisch realisierten) Datenelementen dargestellt. • Datenobjekte sowie Datenelemente können logische Abhängigkeiten voneinander aufweisen. In einer Datenarchitektur können Generalisierungs-/ Spezialisierungsbeziehungen, Aggregations-/Dekompositionsbeziehungen sowie Assoziationsbeziehungen spezifiziert werden. Abb. 33 zeigt den Metamodellausschnitt „Datenarchitektur“.

Abb. 33. Metamodellausschnitt „Datenarchitektur“

2.6.5 Modell der IT-Infrastruktur Auf der IT-Infrastrukturebene wird die von der betrachteten Einheit verwendete Hardware bzw. IT-Infrastruktur mittels des Modells der IT-Infrastruktur abgebildet. Hierdurch soll die Transparenz hinsichtlich der als relevant betrachteten Teile der IT-Infrastruktur-Architektur und ihrer Verknüpfungen erhöht werden. Gleichzeitig gilt es jedoch abzuwägen, ob der Nutzen der Erfassung und Bewirtschaftung eines bzw. mehrerer dieser Modelle durch entsprechende, in der betrachteten Einheit vorhandene Informationsbedarfe gerechtfertigt ist. Durch das Modell der IT-Infrastruktur werden folgende Gestaltungsobjekte abgebildet und in einen Zusammenhang gebracht: Informationstechnikkomponenten ermöglichen die technische Umsetzung von Softwarekomponenten. Dabei kann zwischen Systemsoftware und Hardware unterschieden werden. • Systemsoftware stellt die notwendige Infrastruktur von der Software-Seite sicher. Unter Systemsoftware versteht man z. B. Betriebssysteme, Datenbankmanagementsysteme oder Software zur Verarbeitung von Druckaufträgen. • Die notwendige Hardware ist hauptsächlich in Form von Servern verfügbar. Dabei können physische und virtuelle Server sowie Servercluster unterschieden werden.

•

Abb. 34 zeigt den Metamodellausschnitt „IT-Infrastruktur“.

54


Abb. 34. Metamodellausschnitt „IT-Infrastruktur“

3 BEN-Gestaltungsmethodik für Geschäftslösungen Anke Gericke und Robert Winter

Auf Grundlage der Spezifikation des BEN-Gegenstands beschreibt das dritte Kapitel die BEN-Gestaltungsmethodik, d. h. das Vorgehen zur Analyse und Gestaltung von Geschäftslösungen einschließlich ihrer IT-Umsetzung. Zunächst wird das generelle Methoden- und Referenzmodellverständnis in BEN erläutert. Danach werden Vorgehensmodelle für die zentralen BE-Projekttypen vorgestellt.

3.1 Nutzung von BEN-Gestaltungsmethoden 3.1.1 Traditioneller Methodenbegriff Die Disziplin des Methoden-Engineering Innerhalb der gestaltungsorientierten Wirtschaftsinformatikforschung hat sich die Forschungsdisziplin des Methoden-Engineering etabliert, die sich mit der Konstruktion von Methoden zur Unterstützung der Anwendungssystem-Entwicklung beschäftigt (Gericke 2008; Brinkkemper 1996). Unter einem Anwendungssystem wird dabei ein automatisiertes Teilsystem eines sozio-technischen Informationssystems verstanden, das sowohl die notwendige Hardware, die Systemsoftware als auch die erforderlichen Kommunikationseinrichtungen und die Anwendungssoftware umfasst (Wissenschaftliche Kommission 2007). In Ergänzung dazu sind in der letzten Zeit ebenso Beiträge entstanden, die Methoden entwickeln, mit denen organisatorische bzw. nicht-technische Aspekte der Informationssystemgestaltung unterstützt werden sollen (Gericke 2008). Einer Aufzählung in Bucher und Winter (2008) folgend zählen hierzu u. a. Methoden zur Unterstützung des organisationalen Veränderungsmanagements (vgl. z. B. Baumöl 2005a; Baumöl 2005b) sowie Methoden zur Unterstützung der IT-Prozessgestaltung (Žvanut u. Bajec 2007). Charakterisierung einer Methode Grundsätzlich beschreiben Methoden ein systematisches Vorgehen, wie ausgehend von einer Problemsituation eine problemadäquate Lösung (oder ein entsprechendes Zwischenergebnis) erreicht werden kann (Bucher u. Winter 2008; Becker et al. 2001). Eine Literaturanalyse hat gezeigt, dass Methoden primär durch das Merkmal der Zielorientierung und das systemische Merkmal charakterisiert werden können


56

Nutzung von BEN-Gestaltungsmethoden

(Braun et al. 2005). Dabei wird unter dem Merkmal der Zielorientierung verstanden, dass Methoden eine Anleitung liefern, wie ein definiertes Ziel oder eine bestimmte Lösung zu erreichen sind (Braun et al. 2005). Dem systemischen Merkmal folgend müssen diese Anleitungen „derart strukturiert sein, dass sich konkrete Aufgaben und Aufgabenträger für ein Problem ableiten lassen“ (Greiffenberg 2003). Neben diesen beiden charakterisierenden Merkmalen werden von einigen Autoren weitere Merkmale, wie z. B. die Berücksichtigung von Gestaltungsprinzipien oder die intersubjektive Nachvollziehbarkeit der Methode, genannt (vgl. die Literaturanalyse in Braun et al. 2005). Elemente einer Methode Basierend auf den Arbeiten von Heym (1993) beschreibt Gutzwiller (1994) die Elemente einer Methode sowie deren Beziehungen in Form eines Metamodells. Danach besteht eine Methode aus den Elementen Aktivität, Rolle, Ergebnis, Technik und Informationsmodell. Diese Elemente werden durch Alt et al. (2001) um das Methoden-Element Werkzeug ergänzt. Abb. 35 veranschaulicht das Metamodell einer Methode.

Abb. 35. Metamodell einer Methode (in Anlehnung an Gutzwiller 1994)

Das zentrale Element innerhalb einer Methodenbeschreibung bilden Ergebnisse (Bucher u. Winter 2008). Diese können in Teilergebnisse zerlegt und somit hierarchisch strukturiert werden. Die Gesamtheit aller Ergebnisse einer Methode wird als Dokumentationsmodell bezeichnet (Gutzwiller 1994). Ergebnisse bilden das Resultat von Aktivitäten bzw. werden bei deren Ausführung verwendet. Aktivitäten stellen somit die eigentlichen Verrichtungseinheiten einer Methode dar, die ebenso wie Ergebnisse zerlegt werden können (Gutzwiller 1994). Darüber hinaus können Aktivitäten in eine definierte Reihenfolge gebracht

BEN-Gestaltungsmethodik für Geschäftslösungen

57

werden, d. h. es wird definiert, welche Aktivität vor oder nach einer anderen Aktivität auszuführen ist (Gutzwiller 1994). Diese sequentielle Anordnung von Aktivitäten wird ebenso als Vorgehensmodell bezeichnet, welches von Gutzwiller (1994) auch als das „Vorgehen im Großen“ bezeichnet wird. Jeder Aktivität wird mindestens eine Rolle zugewiesen. Dabei ist eine Rolle durch einen Träger und eine Partizipationsform (z. B. verantwortlich, ausführend, beratend, abnehmend (Gutzwiller 1994)) gekennzeichnet (Bucher u. Winter 2008). Die Erarbeitung von Ergebnissen wird durch Techniken unterstützt. Diese beschreiben detaillierter, wie die Ergebnisse zu erzeugen sind und stellen somit das „Vorgehen im Kleinen“ (Gutzwiller 1994) dar. Die Anwendung der Techniken kann dabei durch (computer-gestützte) Werkzeuge unterstützt werden (Bucher u. Winter 2008). Schließlich stellt das Informationsmodell das konzeptionelle Datenmodell der Ergebnisse dar und determiniert damit gleichzeitig den Gestaltungs- und Lösungsraum der Methode (Bucher u. Winter 2008). Konstruktion vs. Anwendung einer Methode Ebenso wie bei Referenzmodellen (vgl. Abschnitt 3.2.1) können bei Methoden der Prozess der Konstruktion und der Prozess der Anwendung einer Methode unterschieden werden. Diese beiden Prozesse werden stets nacheinander ausgeführt; in der Regel findet ebenso eine organisatorische und personelle Trennung statt (Fettke u. Loos 2005). In der Literatur werden diverse Vorschläge für die einzelnen Phasen des Konstruktionsprozesses gemacht (vgl. z. B. March u. Smith 1995; Peffers et al. 2006; Rossi u. Sein 2003), wobei in den meisten Ansätzen (zumindest implizit) die Phasen der Problemdefinition, der Entwicklung und der Evaluation vorzufinden sind. Ehe die Entwicklung einer Methode in Angriff genommen werden kann, ist es notwendig, die Problemsituation, in der die zukünftige Methode eingesetzt werden soll, zu definieren. Im Anschluss an die Problemdefinition und die Entwicklung der Methode erfolgt deren Evaluation, um die Nützlichkeit des entwickelten Artefakts zu zeigen. Im Bereich des Methoden-Engineering wird der Prozess der Anwendung einer Methode bisher wenig thematisiert. Gleichwohl sehen sich die Anwendenden einer Methode zunächst mit der Aufgabe konfrontiert, eine geeignete Methode für ihre individuelle Problemsituation auszuwählen. Hierfür können MethodenRepositories, in denen bereits entwickelte Methoden vorgehalten werden, eine nützliche Unterstützung bieten. Nach der Identifikation kommt es zur Anwendung der Methode, wobei die Anwendenden ggf. individuelle Veränderungen an der Methode vornehmen. Im Falle eines geplanten, wiederholten Einsatzes der Methode werden schließlich nach Abschluss des Projektes die Lerneffekte notiert, die bei einem erneuten Methodeneinsatz berücksichtigt werden sollten.

58


Rolle von Modellen Im Zusammenhang von Methoden spielen Modelle ebenso eine wichtige Rolle. Modelle können zum einen Input für einzelne Aktivitäten einer Methode darstellen (March u. Smith 1995). Zum anderen können Modelle ebenso das Ergebnis einzelner Methoden-Aktivitäten sein. Für den Fall, dass eine vollständige Methode auf die Erstellung eines Modells abzielt, wird von einer Modellierungsmethode gesprochen, die unter Anwendung einer Modellierungssprache beschreibt, wie ein bestimmtes Modell zu erstellen ist (Fill et al. 2007). Im Gegensatz dazu existieren Projektmethoden, die auf die Unterstützung eines Veränderungsprojekts (Fill et al. 2007) und damit auf die Transformation eines Sachverhalts innerhalb der Realwelt abstellen. Im Hinblick auf den Formalitätsgrad können formale, semi-formale und natürlichsprachliche Modelle unterschieden werden (Fill et al. 2007; Winter 2003b). Im Gegensatz zu natürlichsprachlichen Modellen sind formale Modelle durch eine hohe Exaktheit in Bezug auf die verwendeten Ausdrucksmittel gekennzeichnet (Fill et al. 2007). Semi-formale Modelle stellen eine Kombination aus formalen Modellen und natürlichsprachlichen Modellen dar, bei denen logisch beweisbare Aussagen mit nicht-formalen Aspekten kombiniert werden können (Fill et al. 2007). Somit besteht eine zusätzliche Ausdrucksmöglichkeit, ohne gleichzeitig auf die IT-basierte Umsetzbarkeit verzichten zu müssen (Fill et al. 2007). Darüber hinaus können statische und dynamische Modelle unterschieden werden (Winter 2003b). Während statische Modelle einen bestimmten Zustand abbilden (z. B. Aufbauorganisationsmodell), beschreiben dynamische Modelle einen Ablauf (z. B. Prozessmodell) (Winter 2003b). Einen Sonderfall bilden komparativ statische Modelle, mittels derer mehrere Zustände abgebildet werden können bzw. die einen Vergleich verschiedener Zustände erlauben (z. B. Reifegradmodell) (Winter 2003b).

3.1.2 Situative Methoden Notwendigkeit situativer Methoden Ursprünglich zielte das Methoden-Engineering auf die Konstruktion von Methoden zur Unterstützung der Anwendungssystementwicklung ab (vgl. die Ausführungen oben). In diesem Zusammenhang wurde bereits zu Beginn der 1990erJahre festgestellt, dass aufgrund der im Umfang und in der Komplexität stetig steigenden Softwareentwicklungsprojekte starre Methoden keine adäquate Unterstützung mehr bieten (Brinkkemper 1996). Stattdessen erfolgte die Konzentration auf eine situative Herangehensweise, die auf die Organisationstheorie zurückgeführt werden kann. Der in der Organisationstheorie entwickelte situative Ansatz begründet sich auf der Feststellung, dass es keine Lösung gibt, die sich in allen Situationen als die beste erweist, sondern das vielmehr Lösungen gefunden werden


59

müssen, die in Abhängigkeit der vorherrschenden Situation am besten geeignet sind (Kieser u. Walgenbach 2007; Hauswirth 2006; Bucher 2009). Vor diesem Hintergrund hat sich das Situative Methoden-Engineering etabliert, das auf die Konstruktion situativer Methoden fokussiert, d. h. auf Methoden, die an eine spezielle Problemsituation angepasst werden können (Brinkkemper 1996; Gericke u. Winter 2009). Nur durch die Verwendung solcher situativer Methoden können Projekte effizient und effektiv durchgeführt werden (Brinkkemper et al. 1999). Differenzierung verschiedener Problemsituationen Als Grundvoraussetzung für die Entwicklung situativer Methoden muss die Problemsituation bzw. deren verschiedene Ausprägungen genau spezifiziert werden. Obwohl dieser Aspekt der situativen Methoden-Konstruktion vielfach gefordert wird, haben bisher wenige Ansätze ebendiesen Aspekt tatsächlich adressiert (Bucher et al. 2007). Für die Beschreibung der Problemsituationen können zwei verschiedene Ansätze differenziert werden (Winter et al. 2009): Auf der einen Seite existieren Ansätze, die verschiedene vordefinierte, situative Faktoren, wie z. B. „Größe des Projekts“, „Anzahl der Anspruchsgruppen“ oder „verwendete Technologie“, vorschlagen (vgl. z. B. (Kornyshova et al. 2007) sowie (van Slooten u. Hodes 1996) zitiert nach (Rolland 1997)). Auf der anderen Seite können Ansätze unterschieden werden, die beschreiben, wie Problemsituationen individuell beschrieben werden können (vgl. z. B. Bucher et al. 2007; Mirbel u. Ralyté 2006). Folglich sind die situativen Faktoren nicht vordefiniert, sondern müssen für jede Problemsituation und/oder Anwendungsdomäne separat ermittelt werden. Im Folgenden wird dem Ansatz von Bucher et al. (2007) zur Beschreibung von Problemsituationen als Voraussetzung für die Konstruktion situativer Methoden gefolgt. Eine Problemsituation wird als Kombination so genannter Kontexttypen und Projekttypen definiert: Unter Kontexttypen werden diejenigen situativen Faktoren verstanden, die die Anwendung der Methode beeinflussen, ohne jedoch direkt verändert werden zu können (z. B. Unternehmensgröße oder Branche). Im Gegensatz dazu beschreiben Projekttypen solche situative Aspekte, die die Anwendung der eingesetzten Methode beeinflussen, aber durchaus verändert bzw. festgelegt werden können (z. B. Projektziele). Nicht jede Kombination aus Projekttyp und Kontexttyp muss auch tatsächlich existieren. In manchen Fällen können Situationen über verschiedene Kontexte hinweg durch einen bestimmten Projekttyp determiniert werden; In manchen Fällen kann es andersherum sein und der Kontexttyp determiniert die Situation über verschiedene Projekttypen hinweg. Der Zusammenhang zwischen Kontexttypen, Projekttypen und Situationen wird durch Abb. 36 illustriert.

60


Projekttyp A Kontexttyp A Kontexttyp B Kontexttyp C Kontexttyp …

Projekttyp B

Projekttyp C

Situation 2 Situation 1

Situation 3

Projekttyp … Situation … Situation …

Situation 4 Situation …

Situation …

Abb. 36. Projekttypen, Kontexttypen und Situationen

Prozesse zur Konstruktion situativer Methoden Um der Forderung nach situativen Methoden Rechnung zu tragen, wurden in der Vergangenheit zahlreiche Prozesse zur Konstruktion situativer Methoden vorgeschlagen. Hierbei können Prozesse der situativen Methoden-Konfiguration und Prozesse der situativen Methoden-Komposition unterschieden werden (Bucher et al. 2007). Mit der situativen Methoden-Konfiguration hat sich insbesondere die Arbeitsgruppe um Karlsson beschäftigt (vgl. Karlsson u. Ågerfalk 2004; Karlsson et al. 2001; Wistrand u. Karlsson 2004). Bei dem von dieser Arbeitsgruppe erarbeiteten Prozess des situativen Methoden-Engineering wird die Situationsspezifität dadurch erreicht, dass eine so genannte Base Method durch den Adaptionsmechanismus der Konfiguration an die gegebene Problemsituation angepasst wird (Karlsson u. Ågerfalk 2004). Jede Base Method enthält Methoden-Elemente, die einer der folgenden fünf Kategorien zugeordnet werden können (Ågerfalk et al. 2007): vorschreibende Aktivität, Konzept, Notation, Artefakt und Rolle. Darüber hinaus werden der Base Method ebenso die mit ihr verbundenen Ziele (sog. Rationale) zugeordnet (Ågerfalk et al. 2007). In Bezug auf die situative Methoden-Komposition haben sich insbesondere drei Ansätze etabliert, die im Folgenden kurz umrissen werden (Ågerfalk et al. 2007; Gericke u. Winter 2009): • Brinkkemper und seine Kollegen haben sich früh mit der situativen MethodenKomposition beschäftigt und das Konzept des Methoden-Fragments entwickelt (Ågerfalk et al. 2007). Methoden-Fragmente können bezüglich drei verschiedener Dimensionen klassifiziert werden: der Perspektive, dem Aggregationsgrad und dem Granularitätsgrad (Brinkkemper et al. 1999). In der Dimension der Perspektive werden Produktfragmente (z. B. Ergebnisse) von Prozessfragmenten (z. B. Aktivitäten) differenziert (Brinkkemper et al. 1999). Folglich stellt jedes Methoden-Fragment entweder ein Produkt- oder ein Prozessfragment dar. Die zweite Dimension differenziert zwischen konzeptionellen Methoden-Fragmenten, die Teile von Methoden repräsentieren, und technischen Methoden-Fragmenten in Form von Werkzeugen (Brinkkemper et al. 1999). Schließlich können die Methoden-Fragmente noch verschiedenen Granularitätsgraden zugeordnet werden (vgl. Brinkkemper et al. 1999). Um die Wieder-


61

verwendung einmal entwickelter Methoden-Fragmente zu erhöhen, werden diese in einer so genannten Method Base vorgehalten (Brinkkemper et al. 1999). Soll eine situative Methode entwickelt werden, so werden einzelne Methoden-Fragmente entsprechend der vorgegebenen Problemsituation aus der Method Base identifiziert und dann mittels des Adaptionsmechanismus der Aggregation zu einer situativen Methode zusammengesetzt (Brinkkemper 1996). • Die Arbeitsgruppe um Rolland entwickelte so genannte Method Chunks, die ebenfalls in einer Method Base vorgehalten werden und zu situativen Methoden entsprechend einer konkreten Problemsituation zusammengesetzt werden können (Ågerfalk et al. 2007). Im Gegensatz zu Methoden-Fragmenten integrieren Method Chunks sowohl Produkt- wie auch Prozessaspekte (Mirbel u. Ralyté 2006; Ralyté u. Rolland 2001). Neben diesen beiden Aspekten werden jedem Method Chunk ebenso Informationen bezüglich der Situation, in der es wiederverwendet werden kann, angehängt (Mirbel u. Ralyté 2006). Ähnlich wie bei Methoden-Fragmenten können bei Method Chunks verschiedene Granularitäts- und Abstraktionsgrade unterschieden werden, wobei bei letzteren zwischen einem Komponenten-Level, einem Muster-Level und einem Framework-Level differenziert wird (Ralyté u. Rolland 2001; Rolland u. Prakash 1996). • Die OPEN Process Framework Initiative hat das Konzept der OPF-Methoden/ Prozess-Komponenten vorgestellt, bei dem es sich um ein ähnliches Konstrukt wie die präsentierten Methoden-Fragmente bzw. Method Chunks handelt. Bei den OPF-Komponenten werden dabei Prozess-fokussierte, Produkt-fokussierte und Produzenten-fokussierte Komponenten unterschieden (Gonzalez-Perez 2007). Im Gegensatz zu den zuvor vorgestellten Konstrukten müssen OPFKomponenten aus Elementen eines zugrunde liegenden Metamodells abgeleitet werden (Ågerfalk et al. 2007), welches im internationalen Standard ISO/IEC 24744 „Software Engineering Metamodel for Development Methodologies“ beschrieben ist (Gonzalez-Perez 2007). Die OPF-Komponenten werden ebenso in einer Method Base vorgehalten und können bei Bedarf zu einer situativen Methode aggregiert werden. Bei der Beschreibung der einzelnen Ansätze wurde bereits deutlich, dass neben den Bausteinen einer Methode, d. h. Methoden-Fragmenten (bzw. Method Chunks, OPF-Komponenten), ebenso Prozesse zur Komposition situativer Methoden entwickelt wurden. Im Folgenden soll der von Brinkkemper und seiner Arbeitsgruppe entwickelte situative Methoden-Kompositionsprozess beispielhaft vorgestellt werden (Brinkkemper 1996; Bucher u. Winter 2008): • Identifikation situativer Einflussfaktoren: Situative Einflussfaktoren können dazu benutzt werden, um sowohl Problemsituationen aber auch Methoden bzw. Methoden-Fragmente zu charakterisieren. • Zerlegung von Methoden in Methoden-Fragmente: Methoden müssen in Methoden-Fragmente zerlegt werden, um mit ihnen die Method Base zu füllen.

62


Daneben müssen die Methoden-Fragmente und ihre Beziehungen um Informationen bezüglich der Problemsituationen, in denen sie eingesetzt werden können, ergänzt werden. Hierzu eignen sich die situativen Einflussfaktoren, die zuvor identifiziert wurden. • Komposition einer situativen Methode aus Methoden-Fragmenten: Die Komposition einer situativen Methode wird realisiert, indem MethodenFragmente identifiziert und unter Anwendung von Aggregationsprinzipien orchestriert werden. Dabei werden die Charakteristika der vorliegenden Problemsituation berücksichtigt. Abb. 37 veranschaulicht den Prozess der situativen Methoden-Komposition.

Abb. 37. Prozess der situativen Methoden-Komposition (Brinkkemper 1996)

Erweiterung des Metamodells einer Methode um situative Aspekte An die situative Methoden-Komposition anknüpfend wird im Hinblick auf ebendiesen situativen Ansatz eine Erweiterung des Metamodells einer Methode (vgl. Abschnitt 3.1.1) in Bezug auf situative Aspekte vorgenommen (Bucher u. Winter 2008). Wie zuvor beschrieben, setzt sich eine Problemsituation aus diversen Kontext- und Projekttypen zusammen, die jeweils hierarchisch verfeinert werden können. Die Kontext- und Projekttypen sowie die Problemsituation werden durch einzelne Entitäten im erweiterten Metamodell repräsentiert. Die Problemsituation beeinflusst die Anwendbarkeit von Methoden-Fragmenten, die ebenfalls im erweiterten Metamodell durch eine Entität berücksichtigt werden. Methoden-Fragmente bilden eine Kombination aus Aktivitäten und Techniken (Prozesssicht), die auf die Erstellung von Ergebnissen (Produktsicht) abzielen (Bucher u. Winter 2008). Abb. 38 veranschaulicht das erweiterte Metamodell einer Methode.


63

Abb. 38. Erweitertes Metamodell einer Methode (Bucher u. Winter 2008)

3.2 Nutzung wieder verwendbarer Gestaltungsergebnisse (Referenzmodelle) von BEN 3.2.1 Traditioneller Referenzmodellbegriff Die Disziplin der Referenzmodellierung Neben dem Methoden-Engineering stellt die Referenzmodellierung ebenso eine Forschungsdisziplin der gestaltungsorientierten Wirtschaftsinformatikforschung dar, die darauf abzielt, die Gestaltung von Informationssystemen mittels so genannter Referenzmodelle zu unterstützen. Referenzmodelle können in Bezug auf die Unterstützung der IS-Gestaltung sowohl für die Gestaltung der Organisation als auch die Gestaltung der Anwendungssysteme eingesetzt werden (Gericke 2008; Schütte 1998). Die Referenzmodellierung zielt darauf ab, die Konstruktion spezifischer Modelle zu beschleunigen (Becker et al. 2002a). Dies soll erreicht werden, indem vorgefertigte Modelle, d. h. Referenzmodelle bzw. Referenzmodellbausteine, als Ausgangslösung für die Konstruktion spezifischer Modelle verwendet werden (Fettke u. Loos 2005). Die Wiederverwendung solcher vorgefertigter Modelle

64

Nutzung wieder verwendbarer Gestaltungsergebnisse (Referenzmodelle) von BEN

bzw. Referenzmodelle kann folglich dazu beitragen, die Effizienz und Effektivität von Modellierungsprozessen zu erhöhen (Fettke u. Loos 2005). Der Begriff des Referenzmodells Ein Referenzmodell soll die Konstruktion von spezifischen Modellen unterstützen, indem es Empfehlungen für deren Gestaltung beinhaltet (Becker et al. 2002a; Goeken 2004). Folglich verfügt ein Referenzmodell über einen Empfehlungscharakter. Darüber hinaus stellen Referenzmodelle Lösungsvorschläge für eine (abstrakte) Klasse von Problemen dar (Goeken 2004; Gericke 2008). Referenzmodelle sind somit durch einen gewissen Grad an Allgemeingültigkeit charakterisiert. Wenngleich Referenzmodelle Empfehlungen aussprechen sowie für eine Klasse von Problemen Gültigkeit besitzen, kritisiert vom Brocke (2003), dass diese charakterisierenden Merkmale nur schwer intersubjektiv nachvollziehbar sind. Aus diesem Grund schlägt er vor, den Begriff des Referenzmodells nicht über diese Merkmale, sondern über den Aspekt der Wiederverwendung zu definieren (vom Brocke 2003). Zusammenfassend kann ein Referenzmodell definiert werden als „ein Informationsmodell, das Menschen zur Unterstützung der Konstruktion von Anwendungsmodellen entwickeln oder nutzen, wobei die Beziehung zwischen Referenzund Anwendungsmodell dadurch gekennzeichnet ist, dass Gegenstand oder Inhalt des Referenzmodells bei der Konstruktion des Gegenstands oder Inhalts des Anwendungsmodells wieder verwendet werden“ (vom Brocke 2003). Bezugsrahmen der Referenzmodellierung Im Rahmen der Referenzmodellierungsforschung werden u. a. Referenzmodellierungssprachen und Referenzmodellierungsmethoden entwickelt, die der Konstruktion von Referenzmodellen dienen. Für eine Systematisierung der verschiedenen Ansätze und Konzepte der Referenzmodellierung kann ein Bezugsrahmen verwendet werden, der in Abb. 39 dargestellt ist.

Abb. 39. Bezugsrahmen der Referenzmodellierung (Fettke u. Loos 2004)


65

Zu den Elementen des Bezugsrahmens zählen (Fettke u. Loos 2004): • Referenzmodellierungssprachen: Solche Sprachen stellen Modellierungssprachen dar, die Konzepte und Regeln zur Repräsentation von Referenzmodellen beinhalten. • Referenzmodellierungsmethoden: Solche Methoden stellen Modellierungsmethoden dar, die dem Konstrukteur Anweisungen geben, wie unter Verwendung einer Referenzmodellierungssprache ein Referenzmodell zu erstellen ist. • Referenzmodelle: Durch die Anwendung von Referenzmodellierungsmethoden inkl. Referenzmodellierungssprachen werden Referenzmodelle erstellt. • Kontext der Referenzmodellierung: Referenzmodelle werden stets im Rahmen einer realweltlichen Modellierungssituation erstellt, die durch psychologische, soziale, organisatorische, technische, wirtschaftliche und andere Faktoren beeinflusst wird. Konstruktion vs. Anwendung von Referenzmodellen Wie bereits für das Methoden-Engineering angedeutet, wird auch in der Referenzmodellierung der Prozess der Konstruktion eines Referenzmodells vom Prozess der Anwendung eines Referenzmodells unterschieden. Die beiden Prozesse werden stets nacheinander ausgeführt. Darüber hinaus findet oftmals ebenso eine organisatorische und personelle Trennung zwischen diesen beiden Prozessen statt. (Fettke u. Loos 2005) In der Vergangenheit sind diverse Prozesse für die Konstruktion von Referenzmodellen vorgeschlagen worden (vgl. z. B. Fettke u. Loos 2005; Schlagheck 2000; Becker et al. 2002b). Diese Vorgehensmodelle sind sich in den meisten Fällen sehr ähnlich und bestehen – genauso wie die Konstruktionsprozesse im Methoden-Engineering – aus den Phasen der Problemdefinition, der Entwicklung und der Evaluation/Bewertung (Fettke u. Loos 2005). Zusätzlich wird in der Referenzmodellierung oftmals ebenso die Phase der Pflege als vierte Phase des Konstruktionsprozesses genannt, in der die Weiterentwicklung und Verbesserung des Referenzmodells im Vordergrund steht (Fettke u. Loos 2005). Bei der Anwendung des Referenzmodells werden die Phasen der Auswahl, der Anpassung, der Nutzung und der Integration unterschieden (Fettke u. Loos 2005). Zunächst wird der Anwendende vor die Aufgabe gestellt, ein für seine Problemstellung adäquates Referenzmodell auszuwählen. Als Unterstützung dafür bieten sich so genannte Referenzmodellkataloge an (vgl. z. B. Deutsches Forschungszentrum für Künstliche Intelligenz 2008; Fettke u. Loos 2002b; Fettke u. Loos 2002a), in denen bereits entwickelte Referenzmodelle verzeichnet sind (Fettke u. Loos 2005). In einem nächsten Schritt ist das ausgewählte Referenzmodell an die spezifischen Charakteristika der Problemsituation anzupassen (Fettke u. Loos 2005). Hierfür stellen situative Referenzmodelle dedizierte Adaptionsmechanismen zur Verfügung, die im folgenden Abschnitt erläutert werden. Für den Fall, dass mehrere Referenzmodelle zur Lösung eines Problems eingesetzt werden, gilt es diese in einem dritten Schritt zu integrieren und allfällige Redundanzen aufzu-

66


lösen (Fettke u. Loos 2005). Schließlich kommt das Referenzmodell in der Nutzungsphase zum Einsatz. Abb. 40 veranschaulicht die Prozesse der Referenzmodellierung.

!

!$"

" $

$!"

"!%"

!!

!"! % #%

"

$" % #%

Abb. 40. Prozesse der Referenzmodellierung (Fettke u. Loos 2005)

3.2.2 Situative Referenzmodelle Das Referenzmodellierungsdilemma Ähnlich wie im Methoden-Engineering wurde auch in der Referenzmodellierungsforschung die Notwendigkeit eines situativen Ansatzes bereits früh erkannt, wobei die Notwendigkeit der Konstruktion situativer Referenzmodelle mittels des so genannten Referenzmodellierungsdilemmas aufgegriffen wird (Becker et al. 2002b; Delfmann 2006; vom Brocke u. Thomas 2006): In der überwiegenden Zahl der Fälle ist die Konstruktion eines Referenzmodells mit einem verhältnismäßig hohen Aufwand verbunden. Deshalb sollte diesem Aufwand eine entsprechend hohe Nutzungserwartung gegenüberstehen. Eine umfangreiche Nutzung eines Referenzmodells kann dann angenommen werden, wenn dieses in einer Vielzahl von Problemsituationen wiederverwendet werden kann. Um diesen hohen Wiederverwendungsgrad zu erreichen, sollte der Grad der Allgemeingültigkeit des Referenzmodells erhöht werden. Im Gegensatz zu dieser Sichtweise des Konstrukteurs wird der Anwendende bei der Auswahl eines Referenzmodells neben der inhaltlichen Qualität ebenso bewerten, inwieweit das ausgewählte Referenzmodell die aktuelle Problemsituation berücksichtigt bzw. ein entsprechender Anpassungsbedarf notwendig ist.


67

Aus dieser konträren Situation resultiert ein Zielkonflikt, der sich in dem Wunsch nach einem möglichst allgemeingültigen Referenzmodell auf der Seite des Konstrukteurs und dem Wunsch nach einem Referenzmodell, das die aktuelle Problemsituation so genau wie möglich adressiert, auf der Seite des Anwendenden äußert. In diesem Zusammenhang werden situative Referenzmodelle als geeignet erachtet, diesen Zielkonflikt aufzulösen bzw. zumindest zu verringern. Dies kann dadurch erreicht werden, dass ebendiese Modelle eine Lösung für eine Klasse von Problemen darstellen, jedoch mittels der integrierten Adaptionsmechanismen an konkrete Problemsituationen angepasst werden können. Adaptionsmechanismen der Referenzmodellierung Im vorherigen Abschnitt wurde bereits darauf eingegangen, dass situativ adaptierbare Referenzmodelle mittels integrierter Adaptionsmechanismen innerhalb des Anwendungsprozesses an eine konkrete Problemsituation angepasst werden können. Um dies zu ermöglichen, müssen im Konstruktionsprozess entsprechende Adaptionsmechanismen vorgesehen werden (vom Brocke 2007). Abb. 41 visualisiert einen Ordnungsrahmen für die verschiedenen Adaptionsmechanismen, die im Folgenden noch weiter ausgeführt werden.

Abb. 41. Ordnungsrahmen der Adaptionsmechanismen (Becker et al. 2004)

In der Literatur werden generierende und nicht-generierende Adaptionsmechanismen unterschieden (Becker et al. 2004; Gottschalk et al. 2006). Referenzmodelle, die über nicht-generierende Adaptionsmechanismen – wie die Aggregation, die Instanziierung, die Spezialisierung und die Analogiekonstruktion – verfügen, stellen Basis-Modelle dar, deren „Lücken“ durch die Anwendenden gefüllt werden müssen. Folglich wird der spezifische bzw. individuelle Teil des Referenzmodells durch die Anwendenden generiert und nicht durch im Referenzmodell integrierte Mechanismen (Gottschalk et al. 2006). Im Gegensatz dazu können Referenzmo-

68


delle, die über generierende Adaptionsmechanismen verfügen, konfiguriert und somit an die individuelle Situation der Anwendenden angepasst werden (Gottschalk et al. 2006). Hierfür stehen die Konfigurationsmechanismen Modelltypselektion, Elementtypselektion, Elementselektion, Bezeichnungsvariation und Darstellungsvariation zur Verfügung (Becker et al. 2004). Die Mechanismen der generierenden Adaption, d. h. die fünf genannten Kategorien der Konfigurationsmechanismen, spiegeln sich in einem Referenzmodell in der Form wieder, dass das Referenzmodell diverse Regeln enthält, mittels derer festgelegt wird, wie das Referenzmodell in Abhängigkeit der vorliegenden Konfigurationsparameterausprägungen anzupassen ist (Becker et al. 2004). Basierend auf einem integrierten Gesamtmodell werden somit spezifische Modelle generiert (Becker et al. 2004). Im Detail lassen sich die Konfigurationsmechanismen folgendermaßen beschreiben (Becker et al. 2004; Delfmann 2006; Knackstedt et al. 2006): • Modelltypselektion: Mit Hilfe der Modelltypselektion wird die perspektivenabhängige Auswahl von Modelltypen ermöglicht. Durch die Anwendung dieses Konfigurationsmechanismus wird eine grobgranulare Konfiguration der Gesamtheit der vorhandenen Modelltypen erreicht. Besteht ein Modellsystem beispielsweise aus einem Aufbauorganisationsmodell, einem Prozessmodell, einem Fachbegriffsmodell und einem Datenmodell, so kann für einen Organisationsgestalter der Modelltyp des Datenmodells ausgeblendet werden. • Elementtypselektion: Innerhalb eines Modelltyps erlaubt die Elementtypselektion die perspektivenspezifische Auswahl verschiedener Elementtypen. Neben den Elementtypen „Aktivität“ und „Ergebnis“ im Modelltyp „Prozessmodell“ können in ebendiesem Modelltyp z. B. ebenso die Elementtypen „Fachbegriff“, „Organisationseinheit“, „unterstützendes IT-System“ integriert sein. Je nach Fokus des Anwendenden können nun einzelne Elementtypen ausgeblendet werden, so dass beispielsweise dem Organisationsgestalter keine unterstützenden IT-Systeme angezeigt werden. • Elementselektion: Im Gegensatz zur Elementtypselektion werden bei der Elementselektion nicht vollständige Elementtypen, d. h. zum Beispiel alle unterstützenden IT-Systeme, sondern einzelne, konkrete Elemente des Referenzmodells ausgeblendet. Für die Selektion solcher Elemente werden weitere Kriterien vorgeschlagen, wobei für detaillierte Informationen auf die weiterführende Literatur verwiesen wird (vgl. z. B. Becker et al. 2004). • Bezeichnungsvariation: In Abhängigkeit der Konfigurationsparameterausprägungen ermöglicht es der Konfigurationsmechanismus der Bezeichnungsvariation, dass die im Referenzmodell verwendeten Bezeichnungen ausgetauscht werden. Als Beispiel sei die Verwendung der Begriffe „Rechnung“ oder Faktura“ bzw. „Auftrag“ oder „Bestellung“ in Abhängigkeit der jeweiligen Benutzergruppe angeführt. • Darstellungsvariation: Im Gegensatz zu den bisherigen Konfigurationsmechanismen, die auf unterschiedliche Art und Weise die Elemente bzw. deren Inhal-


69

te von Referenzmodellen adressieren, fokussiert die Darstellungsvariation auf eine Konfiguration der Notation, d. h. der Symbole, der verwendeten Referenzmodellierungssprache. Auch hier können verschiedene Typen der Variation unterschieden werden, für die auf weiterführende Literatur verwiesen wird (vgl. z. B. Becker et al. 2004). Die genannten Mechanismen der nicht-generierenden Adaption unterstützen ebenso die Konstruktion spezifischer Modelle, lassen dabei aber Gestaltungsspielräume, die der Anwendende selbstständig ausfüllen muss (Becker et al. 2004). Im Detail sind die nicht-generierenden Adaptionsmechanismen folgendermaßen charakterisiert (Becker et al. 2004; vom Brocke 2007; Fettke u. Loos 2005): • Aggregation: Mit Hilfe der Aggregation können einzelne Referenzmodellbausteine zu einer größeren Modellkomponente zusammengefügt werden. Die Aggregation ermöglicht somit die Wiederverwendung bereits existierender Modelle in neuen Problemsituationen. Der Adaptionsmechanismus der Aggregation entspricht dabei im Wesentlichen der situativen Methoden-Komposition im Methoden-Engineering (vgl. Abschnitt 3.1.2). Als Beispiel sei ein Prozessmodell eines Wertschöpfungsnetzwerks angeführt, das sich aus zwei Referenzmodellbausteinen, nämlich einem Referenzmodell für ein Handelsunternehmen und einem Referenzmodell für ein Industrieunternehmen, zusammensetzt. • Spezialisierung: Mittels des Adaptionsmechanismus der Spezialisierung wird eine spezifische Nutzung eines allgemeinen Referenzmodells in einer konkreten Problemsituation erlaubt. Beispielsweise kann ein Referenzmodell für den Handel in Bezug auf den Handel mit elektronischen Produkten spezialisiert werden. Um die Beziehung zwischen dem allgemeinen Referenzmodell und dem darauf basierenden spezifischen Modell auch noch zu einem späteren Zeitpunkt nachvollziehen zu können, beinhaltet der Spezialisierungsmechanismus Konstrukte, die die Dokumentation der vorgenommenen Änderungen erlauben. • Instanziierung: Der Adaptionsmechanismus der Instanziierung erlaubt es, Aspekte, die im Referenzmodell zunächst nur vage definiert oder frei gelassen wurden, in einer vorliegenden Problemsituation zu konkretisieren. Als Beispiel kann ein Referenzmodell für einen allgemeinen Geschäftsprozess zur Auftragsabwicklung angeführt werden, welches während der Anwendung mit einem speziellen Bezahlverfahren instanziiert wird. • Analogiekonstruktion: Bei der Analogiekonstruktion wird ein bereits existierendes Referenzmodell bzw. ein Ausschnitt daraus als Hilfsmittel für die Konstruktion eines anderen Referenzmodells verwendet. Die Beziehung zwischen diesen beiden Referenzmodellen ist dabei durch eine wahrgenommene Ähnlichkeit in Bezug auf einen bestimmten Aspekt charakterisiert. Beispielsweise kann ein in einem Industriebetrieb verwendetes Referenzprozessmodell zur Maschinenbelegung ebenso zur Belegungsplanung von Operationssälen in Krankenhäusern verwendet werden.

70

BEN-Vorgehensmodelle

Annäherung des Methoden-Engineering und der Referenzmodellierung In der jüngsten Vergangenheit hat es eine Annäherung der Forschungsdisziplinen des Methoden-Engineering und der Referenzmodellierung gegeben. Forschende beider Disziplinen fordern die Übertragung von entwickelten Konzepten auf das jeweils andere Forschungsgebiet. (Winter et al. 2009; Gericke 2008) Auf dieser Grundlage wurden erste Versuche unternommen, Forschungsergebnisse, die in den einzelnen Konstruktionsphasen, d. h. Problemdefinition, Entwicklung und Evaluation, erzielt wurden, gegenseitig zu übertragen, wobei auf erste Ergebnisse im Folgenden eingegangen wird (Winter et al. 2009; Gericke 2008): Innerhalb der Referenzmodellierungsforschung wurde das Thema der Spezifikation der Problemsituation, für die ein Referenzmodell entwickelt werden soll, bisher nur sehr knapp behandelt (vgl. z. B. Becker et al. 2007b). Im MethodenEngineering wurden im Gegensatz dazu bereits erste Ansätze für die Spezifikation und Identifikation situativer Faktoren vorgeschlagen (vgl. Abschnitt 3.1.2). Obwohl Schelp und Winter (Schelp u. Winter 2006; Winter u. Schelp 2006) die Übertragung dieser Erkenntnisse aus dem Methoden-Engineering auf die Referenzmodellierung fordern, konnten keine Arbeiten identifiziert werden, die eine solche Übertragung im Detail thematisieren. In Bezug auf die Übertragung von Adaptionsmechanismen – die einen Bestandteil der Entwicklungsphase darstellen – der Referenzmodellierung auf das Methoden-Engineering konnten erste Erfolge verbucht werden. Basierend auf der Annahme, dass sich sowohl Methoden als auch Referenzmodelle mittels Modellierungssprachen repräsentieren lassen, wurden die in der Referenzmodellierung entwickelten Konfigurationsmechanismen formal auf Methoden übertragen (vgl. Becker et al. 2007b). In Ergänzung dazu konnte die Anwendbarkeit der Elementselektion im Methoden-Engineering an einem Vorgehensmodell gezeigt werden (vgl. Schelp u. Winter 2006). Im Gegensatz dazu haben die in der Referenzmodellierung entwickelten nicht-generierenden Adaptionsmechanismen Instanziierung und Analogiekonstruktion im Methoden-Engineering bisher wenig Berücksichtigung erfahren (Becker et al. 2007b; Becker et al. 2007a). Obwohl die Evaluation in beiden Forschungsdisziplinen ein zentrales Thema darstellt, existieren bisher wenige Forschungsarbeiten, die diese Konstruktionsphase adressieren. Folglich konnten keine Beiträge identifiziert werden, die sich mit der gegenseitigen Übertragung von Evaluationskonzepten beschäftigen.

3.3 BEN-Vorgehensmodelle Nachdem generische Methoden und Referenzmodelle als konzeptionelle Basis der BEN-Gestaltungsmethodik vorgestellt wurden, liefert dieser Abschnitt eine Übersicht über die BEN-Vorgehensmodelle. Dabei beschränken sich die Darstellungen


71

zunächst auf eine Übersicht. Konkrete Aktivitäten und Ergebnisse werden in Kapitel 4 im Rahmen der einzelnen Konstruktionskomponenten präsentiert.

3.3.1 Grundsätzliche Projekttypen in BEN Geschäftslösungen werden auf den Ebenen „Strategie“ und „Organisation“ beschrieben, ihre Umsetzung auf der IT-Ebene (ggf. den Unter-Ebenen „Software“ und „IT-Infrastruktur“). Die „IT/Business Alignment“-Ebene verbindet den fachlichen Entwurf mit seiner IT-Umsetzung. Grundsätzliche Projekttypen lassen sich auf Grundlage dieses Ebenenkonzepts dadurch unterscheiden, auf welcher Ebene ein Veränderungsprojekt ausgelöst und auf welcher bzw. welchen Ebene/n es zu Veränderungen führt, um wirksam zu werden. Der „Klassiker“ der BE-Projekttypen ist die fachlich getriebene Innovation. Bei diesem Projekttyp wird zunächst eine Geschäftslösung verändert, wodurch aber meist auch Anpassungen bei der IT-Umsetzung notwendig werden. In der üblichen Darstellung des Business Engineering-Frameworks wirkt die Veränderung also von oben nach unten. Je nach Ausmaß der Veränderung kann die fachliche Innovation allein die Organisationsebene betreffen (z. B. Prozess-Redesign bei gleicher Strategie) oder aber von der Strategieebene (z. B. Neupositionierung, Änderungen des Leistungsprogramms) ausgehen, wobei automatisch immer auch die Organisationsebene betroffen sein wird. Je nach Ausgestaltung der IT/Business Alignment-Ebene kann die Veränderung der Geschäftslösung im Idealfall hier „aufgefangen“ werden; Ansonsten wird sie zu Anpassungen auf Softwareebene oder sogar auch auf IT-Infrastrukturebene führen. Ein zweiter grundlegender Projekttyp ist die technisch getriebene Innovation. So können Innovationen der Informations- und Kommunikationstechnik vollkommen neue Organisationslösungen ermöglichen (z. B. individuell angepasste Leistungen werden erst durch Einführung bestimmter IT-Lösungen möglich) oder sogar eine vollkommen neue strategische Positionierung ermöglichen (z. B. neue Geschäftsmodelle wie eBay, Prozessportale). In der üblichen Darstellung des Business Engineering-Frameworks wirkt die Veränderung in diesem Fall von unten nach oben. Je nach Ausmaß der Veränderung kann die technische Innovation allein die Softwareebene betreffen (z. B. Softwareanpassung auf gleicher ITPlattform) oder aber auch Auswirkungen auf die IT-Infrastruktur haben (z. B. Umstellung auf „Software as a Service“), wobei automatisch immer auch die Softwareebene betroffen sein wird. Je nach Ausgestaltung der IT/Business Alignment-Ebene kann die technische Innovation im Idealfall hier „aufgefangen“ werden; Ansonsten wird sie zu Anpassungen auf Organisationsebene (z. B. bei Einführung betriebswirtschaftlicher Standardsoftware) oder sogar auch auf Strategieebene führen (z. B. bei Anpassungen des Leistungssystems).

72


Als dritter grundlegender Projekttyp kann die gegenseitige Abstimmung angesehen werden. Während bei den beiden ersten Projekttypen Innovationen im Vordergrund standen, die auf den jeweils anderen Ebenen „umgesetzt“ werden müssen, steht hier die gegenseitige Anpassung von Strukturen im Vordergrund, die sich (1) aufgrund nicht oder nicht vollständig auf anderen Ebenen umgesetzten Innovationen oder (2) aufgrund unterschiedlich schneller Innovationszyklen „auseinander entwickelt“ haben. Ein weiterer Grund für Abstimmungsprojekte können strukturelle Änderungen wie z. B. Outsourcing, Insourcing, innerbetriebliche Integration oder Aufspaltung sein. In der üblichen Darstellung des Business Engineering-Frameworks wirkt die Veränderung in diesem Fall „aufeinander zu“ in entweder vertikaler Richtung (z. B. IT/Business Alignment) oder in horizontaler Richtung (z. B. Business Process Outsourcing, Integration von IT-Systemen). Im Normalfall sind eine oder (bei „vertikaler“ Abstimmung) zwei Gestaltungsebenen betroffen. Allerdings sind Projekte dieses Typs deshalb nicht unbedingt einfacher, da die Abstimmungen Strukturen in verschiedenen Unternehmensteilen oder sogar verschiedenen Unternehmen betreffen können. Einen vierten grundlegenden Projekttyp stellt die Schaffung von Potenzialen dar. Auch bei Projekten dieses Typs handelt es sich nicht um die Innovation von Geschäftslösungen bzw. deren IT-Unterstützung im engeren Sinne. Vielmehr wird durch Restrukturierung auf einer der Business Engineering-Ebenen ein Potenzial für Vereinfachung, Flexibilisierung und/oder Effizienzsteigerung auf der jeweils übergeordneten Ebene geschaffen. So wird z. B. durch serviceorientierte Strukturierung von sich dafür eignenden Teilen der IT/Business Alignment-Ebene ein Flexibilitätspotenzial für die darauf zugreifenden Geschäftsprozesse geschaffen. Ein anderes Beispiel ist die Schaffung von Flexibilisierungspotenzialen der strategischen Ausrichtung durch serviceorientierte Umstrukturierung sich dafür eignender Teile der Prozesslandschaft. In der üblichen Darstellung des Business Engineering-Frameworks wirkt die Veränderung in diesem Fall jeweils um eine Ebene nach „oben“. Ein wesentlicher Unterschied von Projekten dieses Typs gegenüber klassischen Innovationsprojekten und Abstimmungs-Projekten ist die Tatsache, dass die Nutzeffekte solcher Vorhaben nicht nur später eintreten als die Investitionen zu tätigen sind, sondern dass auch im Normalfall nicht die Stakeholder von einem Projekt profitieren, welche die Investitionen tätigen. Als Unterfall des vierten Projekttyps, aber durchaus auch als eigener Projekttyp kann die Schaffung von Potenzialen auf der gleichen Gestaltungsebene betrachtet werden. Die Restrukturierung führt in solchen Fällen nicht zu einem Potenzial für Vereinfachung, Flexibilisierung und/oder Effizienzsteigerung auf der jeweils übergeordneten Ebene, sondern auf der Ebene der Restrukturierung selbst. So wird z. B. durch den Ersatz von Punkt-zu-Punkt-Vernetzungen durch Adapter zu einem Integrationsmechanismus kurzfristig bzw. bei wenigen Vernetzungen die Komplexität erhöht. Mittelfristig bzw. bei vielen Vernetzungen werden jedoch massive Komplexitätsreduktionen erreicht. Beispiele für diese Art von Restrukturierungsprojekten sind der Ersatz direkter Datenzugriffe analytischer Informationssysteme durch Zugriff auf ein Data Warehouse, die Kopplung von Softwaresystemen durch


73

Enterprise Application Integration oder die Vernetzung von Geschäftseinheiten des gleichen wie auch unterschiedlicher Unternehmen durch eine KollaborationsInfrastruktur (von Maur et al. 2003). Im Gegensatz zu den als vierter Projekttyp beschriebenen Veränderungsprojekten hat die Schaffung von Potenzialen auf der gleichen Gestaltungsebene den Vorteil, dass die Nutzeffekte zwar auch später eintreten als die Investitionen zu tätigen sind, aber dass die Nutzeffekte im Normalfall wenigstens für den gleichen Stakeholder auftreten, welcher die Investitionen tätigt.

Abb. 42. Grundsätzliche Projekttypen in BEN

Die vier bzw. fünf grundsätzlichen BEN-Projekttypen werden in Abb. 42 auf Grundlage des Business Engineering-Framework visualisiert. Die Projekttypen sind so unterschiedlich, dass es kein „typisches“ Business Engineering-Vorgehen gibt. Da sich das Vorgehen in Gestaltungsprojekten entsprechend der grundsätzlichen Projekttypen stark unterscheidet, werden im Folgenden die Vorgehensmodelle für jeweils einen bestimmten Projekttyp beschrieben.

3.3.2 Vorgehensmodell fachlich getriebener Innovation Bei fachlich getriebenen Innovationen ist zu unterscheiden, ob die Veränderung auch strategische Aspekte berührt oder ob es sich „nur“ um eine organisatorische Veränderung handelt. Strategische Aspekte sind berührt, wenn die strategische Positionierung als Kombination von Kompetenzen und Kundenbedarfen verändert wird, wenn das Leistungsprogramm verändert wird oder wenn sich das Zielsystem

74


verändert. Ist dies der Fall, ist zunächst das Vorgehensmodell „Strategieebene“ zu durchlaufen, bevor das Vorgehensmodell „Organisationsebene“ durchlaufen wird. Ist dies nicht der Fall, wird mit dem Vorgehensmodell „Organisationsebene“ begonnen. Hinsichtlich der IT-Unterstützung ist mit dem Vorgehensmodell „IT/Business Alignment-Ebene“ zu prüfen, ob die fachliche Innovation mit bestehenden IT-Systemen und -Infrastrukturen ausreichend umgesetzt werden kann. Falls dies der Fall ist, sind Projekte dieses Typs an dieser Stelle abgeschlossen. Falls dies nicht der Fall ist, sind neue bzw. veränderte Anforderungen an Softwaresysteme und allenfalls auch IT-Infrastruktur zu formulieren und entsprechende Entwicklungsprojekte auszulösen. Vorgehensmodell „Strategieebene“ Die Vorgehensweise im Business Engineering ist generell „vom Ganzen zum Detail“, d. h. ausgehend von gesamthaften, aggregierten Analysen bzw. Spezifikationen werden spezifischere und/oder detailliertere Analysen durchgeführt bzw. Festlegungen getroffen. Auf Strategieebene erfolgt deshalb zunächst eine Geschäftsnetzwerkanalyse. Diese betrachtet die Positionierung der betrachteten Einheit gesamthaft und beschreibt adressierte Kundenbedürfnisse, wichtige Wertschöpfungspartner und die jeweils zentralen Leistungsflüsse. Wenn eine Einheit in verschiedenen Wertschöpfungsnetzwerken beteiligt ist und unterschiedliche Kundenbedürfnisse adressiert, sind entsprechend mehrere Geschäftsnetzwerkmodelle zu spezifizieren. Da in der Geschäftsnetzwerkanalyse Leistungsflüsse und Kundenbedürfnisse sehr aggregiert betrachtet werden, erfolgt im nächsten Schritt eine detailliertere Analyse in Form von Geschäftspartnerprozessmodellen. Jedes Geschäftspartnerprozessmodell detailliert eine Kunden- oder Lieferantenbeziehung eines Geschäftsnetzwerkmodells. Die Leistungsbeziehung wird in Leistungsbestandteile zerlegt, deren Zusammenhänge und Zuordnung zur betrachteten Einheit bzw. zu Lieferanten dokumentiert werden. Als Ergebnis aller jeweils relevanten Geschäftspartnerprozessmodelle liegen nicht nur besser verstandene Kundenbedürfnisse vor, die eine spätere Segmentierung und Zuordnung zu Zugangskanälen ermöglichen. Es ist darüber hinaus auch festgelegt, welche Leistungsbestandteile durch die betrachtete Einheit selbst erstellt werden und welche von Lieferanten bezogen werden. Damit sind auch die Bestandteile des Leistungsprogramms dokumentiert, wenn auch noch über eine Vielzahl von Geschäftspartnerprozessmodellen verteilt. Im nächsten Schritt kann deshalb ein Zusammenzug der dezentral spezifizierten Leistungen zu einem konsistenten und umfassenden Produkt- bzw. Servicemodell erfolgen. Dieses legt die Produkt- bzw. Servicetypen und -familien, die Einzelprodukte/-services und u. U. auch Produkt-/Servicevarianten oder mehrfach verwendete Produkt-/Servicekomponenten fest. Für die Modellierung physischer Produkte wie auch für die Modellierung von Dienstleistungen/Services liegen umfangreiche Arbeiten außerhalb des Business Engineering vor (z. B. Thomas u. Nüttgens 2009; Jørgensen 2006).


75

Die Aggregation der Produkte/Services wird im nächsten Schritt fortgesetzt und durch die Aggregation der adressierten Kundenbedürfnisse ergänzt. Ziel des Modells der strategischen Positionierung ist es, alle wesentlichen Positionierungsmerkmale der betrachteten Einheit aus Kunden- bzw. Bedarfssicht („Marketbased view“) genauso wie alle wesentlichen Positionierungsmerkmale der betrachteten Einheit aus Produktions- bzw. Kompetenzsicht („Resource-based view“) in einem einzigen Dokument zusammenzuführen. Aufgrund der Vielzahl der möglichen Variationen bietet sich dafür eine mehrdimensionale Darstellung z. B. als morphologischer Kasten an. Während die wichtigen Bedarfs- bzw. Produktionsmerkmale die Dimensionen dieses Modells bilden, wird die gewählte bzw. sich aus den vorangehenden Modellen ergebende Positionierung in Form von Dimensionsausprägungen/Werten abgebildet. $# !"

$# !

$ #"

$ #

"

#

"

Abb. 43. Vorgehensmodell auf Strategieebene

Nachdem nun eine ganzheitliche Positionierung der betrachteten Einheit wie auch eine aggregierte Abbildung des Produkt-/Serviceangebots vorliegt, sind als letzter Schritt auf Strategieebene die Organisationsziele, Erfolgsfaktoren, strategischen Führungsgrößen und allenfalls auch Zielwerte und strategische Projekte zu deren Erreichung zu definieren. Bei der Spezifikation des Zielsystems handelt es sich im Gegensatz zu den beiden vorherigen Schritten um eine verfeinernde Analyse, d. h. ausgehend von wenigen ganzheitlichen, aggregierten (Organisati-

76


ons-)Zielen werden sukzessive feinere und besser operationalisierbare Ziele abgeleitet. Auch für die Spezifikation des Zielsystems liegen, z. B. mit dem Balanced Scorecard-Ansatz (Kaplan u. Norton 1997), bewährte Ansätze vor, die in das Business Engineering integriert werden. Das Vorgehensmodell auf Strategieebene wird durch Abb. 43 zusammenfassend illustriert. Natürlich muss nicht immer jeder Schritt und nicht für jeden Schritt jede Verfeinerung bzw. Aggregation durchgeführt werden, sondern nur solche Analyse- und Gestaltungsschritte, die durch das jeweils betrachtete fachliche Innovationsprojekt berührt werden. Vorgehensmodell „Organisationsebene“ Auch auf der Organisationsebene ist die Vorgehensweise generell „vom Ganzen zum Detail“„top-down“, d. h. ausgehend von gesamthaften, aggregierten Analysen bzw. Spezifikationen werden spezifischere und/oder detailliertere Analysen durchgeführt bzw. Festlegungen getroffen. Das Vorgehensmodell der Organisationsebene wird schematisch durch Abb. 44 illustriert. Als Detaillierung davon wird das Vorgehensmodell des Prozess-Detailentwurfs durch Abb. 45 veranschaulicht.

Abb. 44. Vorgehensmodell auf Organisationsebene


Kundensegmente

Prozessarchitekturplanung

Produkt-/ Leistungsprogramm

77

Zielsystem

ProzessLandkarte

Prozess-Detailentwurf Leistungsanalyse

Prozessführung

OutputSpezifikation

Führungsgrössen Ablaufplanung Ablaufdi diagramm

Abb. 45. Vorgehensmodell Prozess-Detailentwurf (IMG 1997b)

Das Business Engineering folgt dem Prinzip, dass die Ablauforganisation alle anderen organisatorischen Aspekte (wie Aufbauorganisation und Informationsversorgung) dominiert. Deshalb wird zuerst die Ablauforganisation gestaltet und auf dieser Grundlage die dazu passende Aufbauorganisation abgeleitet. Die Informationsversorgung ist nicht allein in Abhängigkeit der Informationen erzeugenden und benötigenden Prozesse zu gestalten, sondern bezieht sich auch auf InformationsEigentümer und -Nutzer als Ergebnisse der Aufbauorganisationsgestaltung. Deshalb wird die Informationsversorgung nach Ablauf- und Aufbauorganisation in einem dritten, letzten Hauptschritt auf der Organisationsebene analysiert bzw. gestaltet. Als erster, ganzheitlich wirksamer Schritt der Ablauforganisationsgestaltung (= Prozessentwurf) findet die Prozessarchitekturplanung statt. Ausgehend vom Produkt-/Leistungsprogramm und den adressierten Kundensegmenten – beides Ergebnisse der Strategieebene – wird festgelegt, welche Geschäftsprozesse auf den ersten ein bis zwei Aggregationsebenen differenziert werden sollen. Weiterhin werden fundamentale Unterstützungs- und Führungsprozesse festgelegt. Während bei der Prozessarchitekturplanung Prozesse und deren Zusammenwirken betrachtet werden, steht beim Prozess-Detailentwurf ein bestimmter Prozess oder sogar ein Teilprozess im Mittelpunkt. Dieser Prozess bzw. Teilprozess wird in immer kleinere Teile und schließlich in immer elementarere Aufgaben zerlegt. Bei der Zerlegung stellen nicht „natürliche“ oder künstliche Eigenschaften der Aufgabenketten die Hauptrolle dar, sondern die Eigenschaften immer feingranular betrachteter Prozessleistungen (basierend auf dem Produkt-/Leistungsmodell der Strategieebene) und immer feingranular betrachteter Führungsgrößen (basierend auf dem Zielsystem der Strategieebene) (IMG 1997b; Österle 1995). Nur

78


wenn es die Zerlegung von Prozessleistungen oder die Verfeinerung von Führungsgrößen sinnvoll erscheinen lassen, können Aufgaben entsprechend verfeinert und neue Verfeinerungsstufen für den Prozess-Detailentwurf definiert werden. Diese Verfeinerungen finden dann ein Ende, wenn elementare Führungsgrößen und elementare Prozessleistungen und mithin auch elementare Aufgaben erreicht sind. Wenn nach Abschluss der Ablauforganisationsgestaltung feststeht, welche Ketten elementarer Aufgaben welche elementaren Prozessleistungen erzeugen und dabei durch welche elementaren Führungsgrößen gesteuert werden können, kann auf dieser Grundlage die Ableitung der Aufbauorganisation erfolgen. Fischer (2008) beschreibt dazu einen BE-kompatiblen Ansatz. Schließlich erfolgt als letzter Hauptschritt auf Organisationsebene die Festlegung der Informationsbedarfe und -flüsse. Informationen entstehen in Prozessen, werden in Prozessen (insbesondere, aber nicht nur in Führungsprozessen) benötigt, haben aber oft eine von der Verflechtung der Geschäftsprozesse abweichende Struktur. Es muss deshalb analysiert und festgelegt werden, welche Informationen wichtig sind, wo diese Informationen entstehen, wer für ihre Qualität verantwortlich ist, wer sie nutzen darf, wie sie genutzt werden können (z. B. Zusammenhänge mit anderen Informationen oder mit Bezugsgrößen) und in welche abgeleiteten Informationen sie eingehen. Genauso wie die Ableitung der Aufbauorganisation wird die Festlegung der Informationsbedarfe und -flüsse im Normalfall auf verschiedenen Aggregations- und Fokusebenen erfolgen. Vorgehensmodell „IT/Business Alignment-Ebene“ Nachdem nun die Auswirkungen der fachlichen Innovation auf Organisations- und allenfalls auch Strategieebene erfasst sind, ist auf der IT/Business AlignmentEbene zu prüfen, ob die neuen bzw. veränderten Aufgaben und Informationsobjekte/-flüsse mit bestehenden Softwarekomponenten (einschl. Datenstrukturen) unterstützt werden können oder ob Softwaresysteme geändert werden müssen. Müssen Softwaresysteme geändert oder neue/andere Softwaresysteme eingeführt werden, wird das Business Engineering zu Software Engineering, d. h. es kommen die bewährten Vorgehensmodelle dieser Disziplin für die Softwareentwicklung (z. B. Bunse u. von Knethen 2008; Balzert 1998) und/oder die Standardsoftwareeinführung (z. B. IMG 1997a) zum Tragen. Softwareentwicklung wie auch Standardsoftwareeinführung (bzw. Änderung der Standardsoftwarekonfiguration) sind aufwändig und die IT/Business Alignment-Ebene wurde gerade eingeführt, damit nicht jede organisatorische Änderung zu einer Änderung der Softwaresysteme führen muss. Der Umfang der „Pufferungs“-Möglichkeiten der IT/Business Alignment-Ebene hängt vom Umfang der entsprechenden Projekte der Typen „gegenseitige Abstimmung“ und „Potenziale schaffen“ ab. So bündeln fachliche Services verfügbare ITFunktionalitäten orientiert an der Datennutzung, am Prozessablauf oder an ihrer Wiederverwendbarkeit (Schelp u. Winter 2008) derart, dass möglichst viele organisatorische Variationen abgedeckt werden.


79

Bei professionellem Engineering der IT/Business Alignment-Ebene sollten die überwiegende Zahl der geänderten Aufgabenketten und der veränderten Informationsobjekte/-flüsse mittels mehrfachverwendbarer fachlicher Services auf bestehende IT-Funktionalitäten abbildbar sein, so dass Software Engineering nicht oder nur in beschränktem Ausmaß notwendig wird.

3.3.3 Vorgehensmodell der technisch getriebenen Innovation Technisch getriebene Innovationen führen zunächst zu Veränderungen der Softwaresysteme und allenfalls auch der IT-Infrastruktur. Die Gestaltung dieser Veränderungen ist – ähnlich der IT-Umsetzung nicht-„pufferbarer“ fachlicher Innovationen – Gegenstand des Software Engineering und der entsprechenden Vorgehensmodelle. Für das Business Engineering ist von Belang, ob die Veränderungen der ITUmsetzung 1. auf der IT/Business Alignment-Ebene „gepuffert“ werden können und deshalb keine oder zumindest keine signifikanten Auswirkungen auf Geschäftslösungen haben, 2. auf die Organisationsebene „durchschlagen“ und dort zu Anpassungen von Ablauforganisation, Aufbauorganisation und/oder Informationsversorgung führen oder gar 3. bis auf die Strategieebene „durchschlagen“, weil die implizierten organisatorischen Änderungen so groß sind, dass Aspekte der strategischen Positionierung, des Produkt-/Leistungsprogramms oder des Zielsystems berührt werden. Im Sinne eines „Backward Business Engineering“ werden also zunächst die im vorhergehenden Abschnitt skizzierten Abgleichsmechanismen der IT/Business Alignment-Ebene durchlaufen. Sind organisatorische Anpassungen notwendig, verbinden die fachlichen Services zunächst die Analyse der Informationsobjekt/-flüsse und die ProzessDetailentwürfe. Zu weiteren Rückwirkungen in die Aufbauorganisationsgestaltung und in die Prozessarchitekturplanung sollte es nur bei massiven technischen Innovationen, wie z. B. der Ablösung individueller betriebswirtschaftlicher Softwaresysteme durch betriebswirtschaftliche Standardsoftware, kommen. In diesen Fällen ist nicht auszuschließen, dass die veränderten Organisationsartefakte „nach oben“ in die Gestaltung des Zielsystems (z. B. neue/andere Führungsgrößen), in die Produkt-/Servicemodellierung (z. B. neue/andere Produkte) oder gar in die Kundenprozessanalyse (z. B. neue Partnerschaften, zusätzlicher/veränderter Kunden-Mehrwert) wirken. Auch nicht direkt berührte Analyse-/Gestaltungsschritte der Strategieebene müssen dann erneut ausgeführt werden, um die Konsistenz aller Ergebnisse dieser Ebene zu erhalten.

80


3.3.4 Vorgehensmodell für gegenseitige Abstimmung Gegenseitige Abstimmung dient zur Angleichung unterschiedlicher Strukturen unabhängig davon, ob die Strukturen unterschiedlicher Herkunft sind (z. B. nach Mergers & Akquisitions, aber auch zwischen auslagernder Einheit und Dienstleister oder zwischen Bereichen einer Einheit) oder ob sich die Strukturen auseinander entwickelt haben (z. B. bei massivem Projektgeschäft und wenig Aufwand für IT/Business Alignment). Da die Strukturen innerhalb der Business Engineering-Ebenen für die jeweils betrachtete Einheit auf der Grundlage der Vorgehensmodelle auseinander abgeleitet werden, ist innerhalb der Ebenen im Normalfall keine Abstimmung notwendig. Abstimmung kann für die betrachtete Einheit zwischen den Ebenen notwendig werden, wenn strategische Veränderungen nicht vollständig in organisatorische Änderungen überführt wurden (oder umgekehrt) oder wenn Änderungen von Geschäftslösungen nicht vollständig in Änderungen der unterstützenden IT-Systeme überführt wurden (oder umgekehrt). Diese Fälle werden als vertikale gegenseitige Abstimmung bezeichnet. Da sowohl strategische wie auch organisatorische Veränderungen auf der Fachseite verankert sind, ist die vertikale Abstimmung zwischen Strategie- und Organisationsebene im Normalfall weniger problematisch als die vertikale Abstimmung zwischen Geschäftslösungen und ihrer IT-Unterstützung. Diese Problematik, auch als das Problem des IT/Business Alignment bezeichnet, steht seit Jahren permanent ganz oben auf der Aufgabenliste von CIOs (Luftman u. Kempaiah 2008). Im Business Engineering wurde die IT/Business AlignmentEbene eingeführt, um durch geeignete Artefakte und Strukturen IT/Business Alignment zu unterstützen. Wenn mit Einheit A und Einheit B eines Unternehmens, mit auslagernder Einheit und Dienstleister oder mit kaufender Einheit und gekaufter Einheit unterschiedliche Betrachtungseinheiten ins Spiel kommen, werden neben Inkonsistenzen zwischen Ebenen und Inkonsistenzen zwischen Modellen einer Ebene auch Inkonsistenzen zwischen vergleichbaren Modellen (also z. B. Zielsystem A und Zielsystem B) auftreten. Diese Fälle werden als horizontales Alignment bezeichnet. Bei klaren Größen- und Machtverhältnissen zeigen Untersuchungen aus dem Finanzdienstleistungsbereich, dass eine einseitige, vollständige Anpassung wesentlich effizienter ist als andere anderen Alignment-Formen (Penzel u. Pietig 2000). Dies mag auch bei Outsourcing-Verhältnissen ein gangbarer Weg sein, zumindest solange die auslagernde Einheit groß und der Dienstleister klein ist. Für „normale“ Integrationsprojekte ergibt sich jedoch eine Vielfalt von UnterProjekttypen, deren methodische Unterstützung zwar auf theoretisch wiederverwendbaren Mustern basiert, aber in weit auseinander klaffende Vorgehensmodelle resultiert. Eine Auswahl methodischer Ansätze mit Umsetzung an praktischen Beispielen findet sich z. B. für das Thema des Integrationsmanagements in (Winter 2009). Auf die Präsentation eines stark generalisierten Vorgehensmodells für horizontales Alignment wird deshalb verzichtet.


81

Vorgehensmodell „Vertikales Alignment“ Für vertikales Alignment zwischen Organisations- und Softwareebene wurde die IT/Business-Alignment-Ebene eingerichtet. Auf der IT/Business-AlignmentEbene finden sich als zentrale Artefakttypen fachliche Services, (logische) Applikationen und Domänen. Fachliche Services können, müssen aber nicht allein im Hinblick auf Wiederverwendbarkeit entworfen sein; Es kann gute Gründe geben, fachliche Services entsprechend bestimmter Datenstrukturen (Funktionalitäten rund um diese Datenstruktur) oder entsprechend bestimmter Geschäfts(teil)prozesse (Funktionalitäten rund um diesen (Teil-)Prozess) zu entwerfen (Schelp u. Winter 2008). In allen Fällen sollten jedoch fachliche Services grobgranularer strukturiert sein als die Aufgaben (auf Organisationsebene) und IT-Funktionalitäten (auf Softwareebene), die sie verknüpfen (Aier u. Winter 2009). (Logische) Applikationen sind Aggregate fachlicher Services und Domänen sind Aggregate (logischer) Applikationen. Allerdings können je nach Komplexität der abzubildenden Strukturen Domänenmodelle in Unterdomänenmodelle, Applikationslandschaften und Teil-Applikationslandschaften, Applikationen in Applikationskomponenten und auch fachliche Services in feingranularere fachliche Services zerlegt werden. Für das Vorgehensmodell für vertikales Alignment gibt es drei verschiedene Varianten: 1. Bei der Top-down-Variante werden zunächst Domänen, auf deren Grundlage durch Zerlegung (logische) Applikationen und erst am Ende durch Zerlegung fachliche Services abgeleitet. 2. Bei der Bottom-up-Variante werden zunächst fachliche Services identifiziert, auf deren Grundlage durch Clusterung (logische) Applikationen gebildet und erst am Ende durch Clusterung Domänen abgeleitet werden. 3. Die Middle-out-Variante startet mit der Applikationsbildung. Auf Grundlage der Applikationslandschaft werden „nach unten“ fachliche Services gebildet und „nach oben“ Domänen geclustert. Alle Varianten haben ihre Berechtigung. Die Top-down-Variante entspricht am ehesten einem „architektonischen“ Vorgehen; Allerdings werden mögliche Doppelspurigkeiten bei (logischen) Applikationen und insbesondere bei fachlichen Services in Kauf genommen. Die Bottom-up-Variante garantiert eine konsistente Servicelandschaft, nimmt aber fachlich nicht ideal zugeschnittene (logische) Applikationen und insbesondere Domänen in Kauf. Die Middle-out-Variante baut auf der in den meisten Unternehmen etablierten Schicht der Applikationslandschaft auf und reduziert damit Anpassungsprobleme auf dieser Ebene. Das Vorgehensmodell für vertikales Alignment mit Hilfe der Artefakte und Strukturen der IT/Business Alignment-Ebene wird durch Abb. 46 illustriert.

82


Abb. 46. Vorgehensmodell für vertikales Alignment

3.3.5 Vorgehensmodell für die Schaffung von Potenzialen Bei diesem Projekttyp wird durch Restrukturierung auf einer der Business Engineering-Ebenen ein Potenzial für Vereinfachung, Flexibilisierung und/oder Effizienzsteigerung auf der jeweils übergeordneten Ebene geschaffen. Im Business Engineering-Framework sind vier Varianten solcher Potenzialschaffung denkbar: 1. Auf IT-Infrastrukturebene wird durch Redesign der Infrastrukturkomponenten die Möglichkeit geschaffen, dass Softwarekomponenten Infrastrukturdienste einfacher, flexibler oder effizienter nutzen können. Ein Beispiel dafür ist „Cloud Computing“. 2. Auf Softwareebene wird durch Redesign der Softwarekomponenten (einschl. Datenstrukturen) die Möglichkeit geschaffen, dass fachliche Services die Softwarekomponenten einfacher, flexibler oder effizienter nutzen können. Beispiele dafür sind serviceorientiertes Softwaredesign (SOA) oder „Software as a Service“. 3. Auf IT/Business Alignment-Ebene wird durch Redesign der (logischen) Funktionalitätsbündel die Möglichkeit geschaffen, dass (indirekt) Prozesse auf ITFunktionalitäten einfacher, aber vor allem flexibler zugreifen können. Das pas-


83

sende Beispiel stellen hier fachliche Services als Grundlage für die „Orchestrierung“ von Geschäftsprozessen dar. 4. Auf Organisationsebene wird durch Redesign der Prozesse die Möglichkeit geschaffen, dass Geschäftsmodelle Prozesse einfacher, flexibler oder effizienter nutzen können. Ein Beispiel hierfür ist die „service oriented enterprise“, d. h. die Bereitstellung von einbindbaren, standardisierten Vorleistungen für flexible Nutzung durch verschiedenste Geschäftslösungen. Die Unterschiedlichkeit der Varianten macht deutlich, dass die unterschiedlichen Business Engineering-Ebenen für das jeweilige Redesign deutlich unterschiedliche Vorgehensmodelle erfordern. Als Beispiel wird durch Abb. 47 ein Vorgehensmodell für den Entwurf fachlicher Services illustriert.

Abb. 47. Vorgehensmodell für Servicedesign auf der IT/Business Alignment-Ebene (in Anlehnung an Dodd 2005)

Als Unterfall des Projekttyps „Schaffung von Potenzialen“ wurden oben Projekte genannt, die Potenziale auf der gleichen Gestaltungsebene schaffen. Da Software Engineering und erst recht Hardware Engineering hier nicht betrachtet werden sollen, sind im Business Engineering-Framework in diesem Fall drei Varianten solcher Potenzialschaffung denkbar: 1. Auf IT/Business Alignment-Ebene wird durch Redesign der (logischen) Applikationen die Möglichkeit geschaffen, dass diese effizienter miteinander vernetzt werden können. Ein schönes Beispiel ist die Konzeption einer zentralen Autorisierungsapplikation, die alle Autorisierungsservices der verschiedenen

84


miteinander aus Geschäftssicht gekoppelten Applikationen bündelt (z. B. Wortmann 2006). 2. Auf Organisationsebene wird durch Redesign der Informationslandschaft die Möglichkeit geschaffen, dass Informationen effizienter miteinander vernetzt werden können. Ein Beispiel hierfür ist die Konzeption einer zentralen Performanceinformationen-Struktur, die verteilte Performanceinformationen der miteinander aus Strategiesicht verbundenen Prozesse bündelt. 3. Auf Strategieebene wird durch Redesign der Geschäftsmodelle die Möglichkeit geschaffen, dass diese effizienter miteinander vernetzt werden können. Ein Beispiel hierfür ist die Konzeption zentraler Unterstützungsdienste (z. B. Zahlungen, Logistik), die mehrfach verwendbar sind und dadurch nicht nur die redundante Realisierung in verschiedenen Geschäftsmodellen ersetzen, sondern die auch wirtschaftlicher erbracht werden können. Im Hinblick auf das Vorgehensmodell wird auch hier deutlich, dass die Unterschiedlichkeit der betrachteten Ebenen ausschließt, ein aussagekräftiges generisches Vorgehensmodell zu präsentieren. Allerdings fällt auch auf, dass es häufig um die Effizienz der Vernetzung und damit um den Ersatz von Punkt-zu-PunktVernetzungen durch Adapter zu einem Integrationsmechanismus und damit direkt oder indirekt um die Zentralisierung redundant realisierter Artefakte geht.

4 BEN-Komponenten Antonia Albani und Robert Winter

Kapitel 4 widmet sich der Zusammenfassung von eng zusammengehörenden Modelltypen zu BEN-Komponenten, um für das BE Problemlösungsfragemente für die Analyse und Gestaltung von Geschäftslösungen zur Verfügung zu stellen. Dafür werden zuerst die Zusammenhänge der in Kapitel 2 eingeführten Modelltypen analysiert und zu BEN-Komponenten zusammengefasst. Danach werden die Charakteristika der einzelnen Komponenten erläutert und deren Einsatz in den verschiedenen BE-Projekttypen illustriert. Ein großer Teil dieses Kapitels widmet sich am Schluss den Analyse- und Gestaltungsaufgaben der einzelnen BENKomponenten.

4.1 Das Konzept der BEN-Komponenten In Kapitel 2 wurden auf Grundlage des Business-Metamodells verschiedene Modelltypen beschrieben, deren Instanziierungen quasi als „kleinste (Modell-)Einheiten“ elementare Zusammenhänge abbilden. Die Umsetzung von Innovationen, die Lösung spezifischer Gestaltungsprobleme oder die Schaffung bestimmter (Vernetzungs- oder Flexibilitäts-)Potenziale beschränkt sich jedoch im Allgemeinen nicht auf die Erfassung elementarer Zusammenhänge. Vielmehr müssen komplexe Zusammenhänge erfasst werden, d.h. es werden verschiedene Modelltypen benötigt. Über die einzelnen Instanziierungen hinaus kommt dann deren Verbindung bzw. Verknüpfung eine wichtige Rolle zu. Allein die Verbindung bzw. Verknüpfung verschiedener Modelltypen stellt dabei noch keine Lösungskomponente dar. Erst wenn entsprechende Analyse- und Entwurfsaktivitäten zugeordnet werden, wird diese Kombination aus generischer Ergebnisbeschreibung und generischer Aktivitätsbeschreibung als BEN-Komponente bezeichnet. BEN-Komponenten stellen damit Methodenfragmente im Sinne des situativen Methodenengineering dar. Abb. 48 enthält alle in den vorausgegangenen Kapiteln eingeführten Modelltypen auf den verschiedenen Ebenen des Business Engineering. Die Pfeile zwischen den Modelltypen bezeichnen besonders wichtige Verbindungen bzw. Verknüpfungen zwischen jeweils zwei Modelltypen. Abb. 48 macht deutlich, dass bestimmte Modelltypen eine engere Zusammengehörigkeit haben als andere. Das Zusammenfassen von eng zusammengehörigen Modelltypen zu BENKomponenten ist eine große Hilfe, um nicht nur „Elementarbausteine“ für Analyse und Gestaltung zur Verfügung zu stellen, sondern sinnvoll anwendbare und


86

Das Konzept der BEN-Komponenten

kombinierbare Problemlösungsfragmente. Für die verschiedenen BE-Projekttypen werden die BEN-Komponenten in unterschiedlicher Weise, z.B. in einer bestimmten Auswahl und Reihenfolge, kombiniert. '!!% !&

%+&%$

%+&%#$&!$

%&'!!

% $"

&$& !

'!! % !&

% $

%&'!% %&!&

!

$&%&'!!

#

%+&%$ $&%&'!! -$'!%$,%%! $"*%%%&'!!

$!%&"!% !

$

$"*%%

$

-$'!% $,%%!

&(&+&!

$"*%% $"*%% $!%&"!%!&!

'%!%% ! !&!

!

"

$!%&"!% !&!

!"$ &"!%$ !"$ &"!%$

&(&+&!

%

$!%&"!%!&! $-'!%$& !"$ &"!% !&

$&'!! "&)$'!&"!!

!

&! !&

$&'!! &!

!% %&*'!

! % %&*'!

!"$ &"!% !&

&(&+&!

Abb. 48. BEN-Modelltypen und besonders wichtige Zusammenhänge

4.1.1 Zusammenhänge zwischen Modelltypen auf Strategieebene Die Betrachtung z.B. der Verbindungen/Verknüpfungen des Geschäftsnetzwerkmodells auf Strategieebene zeigt, dass die Geschäftsnetzwerkanalyse sowohl Einfluss auf die Geschäftspartnerprozessanalyse wie auch auf die Gestaltung der Prozesslandkarte und der Aufbauorganisation hat. Das Geschäftsnetzwerkmodell beschreibt gesamthaft das Zusammenwirken verschiedener Organisationen zur gemeinsamen Abdeckung von Kundenbedürfnissen. Dabei werden unter anderem sowohl die Netzwerkpartner und Mitbewerber als auch die eigenen Geschäftsfelder explizit definiert und modelliert. Die im Geschäftsnetzwerkmodell aggregiert modellierten Leistungsflüsse werden im Geschäftspartnerprozessmodell detailliert um die entsprechenden Leistungskomponenten zu spezifizieren. Die Leistungskomponenten, die im Geschäftspartnerprozessmodell identifiziert werden, bilden wiederum die Grundlage für deren Zusammenfassung im Produkt-/Servicemodell. Für die verschiedenen Kundensegmente, die aus dem Geschäftsnetzwerkmodell resultieren, werden in der Prozesslandkarte die entsprechenden Leistungsprozesse definiert. Die im Geschäftsnetzwerkmodell modellierten Geschäftsfelder finden sich in der Aufbauorganisation als Organisationseinheiten wieder. Während zwi-

BEN-Komponenten

87

schen Geschäftsnetzwerkmodell, Geschäftspartnerprozessmodell und Produkt/Servicemodell enge Verbindungen/Verknüpfungen in Form von direkt aufeinander bezogenen Zerlegungs- und Zusammenfassungsschritten bestehen, ist der Zusammenhang zwischen dem Geschäftsnetzwerkmodell und dem Modell der Aufbauorganisation deutlich lockerer: Hier findet zwar eine Referenzierung statt, aber die Analyse- bzw. Gestaltungsschritte stehen darüber hinaus in keinem unmittelbaren sachlogischen Zusammenhang. Bei der Bildung von BEN-Komponenten werden deshalb Geschäftsnetzwerkmodell, Geschäftspartnerprozessmodell und Produkt-/Servicemodell der gleichen Komponente Leistungsdefinition zugeordnet, während das Modell der Aufbauorganisation einer anderen Komponente zugeordnet wird. Das Modell des Zielsystems steht in keiner direkten Abhängigkeit mit den anderen Modelltypen auf Strategieebene und wird dementsprechend einer eigenen Komponente Zieldefinition zugeordnet.

4.1.2 Zusammenhänge zwischen Modelltypen auf Organisationsebene Die Prozesslandkarte auf Organisationsebene bildet sicherlich den wichtigsten Ausgangspunkt für die Analyse bzw. Gestaltung auf Organisationsebene. Die in der Prozesslandkarte definierten Leistungs-, Führungs-, und Unterstützungsprozesse werden im Ablaufmodell weiter detailliert und verfeinert. Zudem bilden die Prozesse der Prozesslandkarte die Grundlage für die detaillierte Leistungsanalyse, bei der nicht der Fokus auf das Zusammenwirken der verschiedenen Prozesse oder Teilprozesse gelegt wird, sondern auf die Verfeinerung der Beschreibung der jeweiligen Prozessleistung. Basierend auf den in der Prozesslandkarte definierten Prozessen sowie den Führungsgrößen des Zielsystems können im Steuerungsmodell sogenannte Prozessführungsgrößen definiert werden. Diese bilden wiederum zusammen mit den Prozessen der Prozesslandkarte und den in der Leistungsanalyse spezifizierten Prozessleistungen die Grundlage für die Gestaltung des Ablaufmodells. Die Organisationseinheiten, die in Form von „Kandidaten“ als Prozess-Owner in den Prozesslandkarten wie auch in den Ablaufmodellen auftauchen, werden im Rahmen der Analyse der Aufbauorganisation detailliert spezifiziert. Die Erzeugung und Nutzung von Informationen dürfen nicht nur „am Rande“ der Prozessanalyse bzw. -gestaltung betrachtet werden. Informationen fließen in Organisationen nämlich oft ganz anders als die (physischen) Leistungen – ein gutes Beispiel dafür sind entscheidungsunterstützende Informationsflüsse zwischen Leistungs- und Führungsprozessen. In Informationsmodellen werden deshalb nicht nur Informationsobjekte, sondern auch deren Abhängigkeiten und andere Beziehungen zwischen Informationen definiert. Da in den Prozessabläufen jeweils nur die „lokale“ Informationsgewinnung bzw. -nutzung beschrieben wird, braucht es zusätzliche Informationsmodelle zur Abbildung des Gesamtzusammenhangs. Die

88


Zusammenhänge zwischen Informationsobjekten implizieren die Konsistenzbedingungen und das Systemverhalten. Zwischen (kontextbezogen genutzten) Informationen und (in IT-Systemen implementierten) Daten besteht ein enger Zusammenhang: Je nach BE-Projekttyp werden Datenmodelle aus Informationsmodellen abgeleitet, Informationsmodelle aus Datenmodellen rekonstruiert, oder die Beziehungen zwischen Daten und Informationsobjekten wird über die IT/Business Alignment-Ebene hergestellt. Die direkten Zusammenhänge zwischen den Modelltypen der Organisationsebene und den Modelltypen der IT-Ebene sind in Abb. 48 gestrichelt abgebildet. Der Grund dafür ist, dass solche direkten Zusammenhänge nur in seltenen Fällen verwendet werden – wenn nämlich IT-Lösungen individuell gemäss fachlicher Spezifikationen entwickelt werden oder, was auch manchmal vorkommt, wenn eine fachliche Lösung auf Grundlage ihrer IT-Umsetzung rekonstruiert wird. Im Normalfall werden fachliche Lösungen (durch Unternehmen und Behörden) und Softwarelösungen (durch Standardsoftwarehersteller und Systemintegratoren) mehr oder weniger unabhängig entwickelt und können daher nur über die IT/Business Alignment-Ebene verbunden werden. Bei der Bildung der BEN-Komponenten auf Organisationsebene lassen sich anhand der eben beschriebenen Abhängigkeiten drei Komponenten identifizieren. Die Komponente Prozessgestaltung beinhaltet die Modelltypen Prozesslandkarte, Prozessleistungsmodell, Steuerungsmodell und Ablaufmodell. Diese Modelle stehen in enger Abhängigkeit, da die in der Prozesslandkarte auf höchstem Aggregationsgrad identifizierten Geschäftsprozesse mit Hilfe der anderen Modelltypen verfeinert werden. Die Aufbauorganisation wie auch die Informationslogistik können jedoch durchaus in separaten Komponenten isoliert werden. Somit wird das Aufbauorganisationsmodell der Komponente Aufbauorganisationsgestaltung und das Informationsmodell der Komponente Informationsgestaltung zugeordnet.

4.1.3 Zusammenhänge zwischen Modelltypen auf IT/Business Alignment-Ebene Kompakte, eng miteinander verbundene Zuordnungen elementarer Prozessaktivitäten zu elementaren Software-Funktionalitäten werden als Capabilities oder, wenn sie serviceorientiert strukturiert werden, als fachliche Services bezeichnet. Applikationen bündeln miteinander verbundene, primär nutzungsbezogene Zuordnungen von Prozessen (oder Prozessteilen) zu Softwaresystemen (oder Komponenten von Softwaresystemen). Aggregiert man Applikationen weiter unter fachlichen Gesichtspunkten, entstehen wenige hoch aggregierte Bereiche, die sog. Domänen. Damit stellen fachliche Services / Capabilities, Applikationen und Domänen ähnliche Zusammenhänge zwischen fachlichen und IT-Artefakten dar, wenn auch auf unterschiedlichem Aggregationsniveau und deshalb zwischen unterschiedlich aggregierten Artefakten. Die dominierende Zuordnung stellt dabei

BEN-Komponenten

89

die zu Aktivitäten (auf Organisationsebene, z.B. in Ablaufmodellen) und zur Softwarefunktionalitäten (auf IT-Ebene, z.B. in Softwaremodellen) dar. Ergänzend können Artefakte auf IT/Business Alignment-Ebene auch Zuordnungen zu Informationsobjekten (auf Organisationsebene, in Informationsmodellen) und Daten (auf IT-Ebene, in Datenmodellen) bzw. zu Verantwortlichkeiten (auf Organisationsebene, in Aufbauorganisationsmodellen) und Berechtigungen (auf ITEbene, in Softwarekomponenten) haben. Für die Bildung der BEN-Komponenten auf IT/Business Alignment-Ebene werden aufgrund des engen, unmittelbaren Zusammenhangs alle drei Modelltypen der IT/Business Alignment-Komponente zugeordnet.

4.1.4 Zusammenhänge zwischen Modelltypen auf IT-Ebene Auf IT-Ebene basiert die Gestaltung der Softwarearchitektur auf Softwarekomponenten und Daten mit dem Ziel, eine hohe Wiederverwendbarkeit dieser Konstrukte zu erreichen. Dementsprechend werden auf IT-Ebene die Modelltypen Softwarearchitektur und Datenarchitektur der BEN-Komponente Softwarelösungs-Fachkonzeption zugeordnet. Im Gegensatz dazu basiert die Gestaltung der IT-Infrastruktur auf Zielen wie Skalierbarkeit, Zuverlässigkeit oder Performanz, sodass der Modelltyp der IT-Infrastruktur einer separaten BEN-Komponente ITInfrastruktur-Konzeption zugeordnet wird. #

"#$"#

")#" #(&!

")#" !#! ! (""

!$# !%

!("""##$

!("" !#

!("" "#$"

! #" !%"

#" "#

#&!*"$"( #

#&! !##$!

# !##$!

Abb. 49. BEN-Komponenten

" "'"#"

$$!"#""##$ !#""##$

#$!$"

$"""#

! "#!#" "# !$

)

!"#!$#$!( #

!

!"#!$#$!

$

$$ !" #"

!#"

90


4.1.5 Charakteristika der BEN-Komponenten Wenn, wie in den oberen Abschnitten, alle engen, unmittelbaren Zusammenhänge zwischen den Modelltypen zur Komponentenbildung herangezogen werden, resultieren daraus die in Abb. 49 dargestellten BEN-Komponenten. Alle BEN-Komponenten integrieren im Sinne von Methodenfragmenten Gestaltungs- bzw. Analyseaufgaben mit bestimmten Modellierungskonstrukten. Sie lassen sich auf unterschiedlichen Aggregationsniveaus (z.B. Gesamt-, Kontextoder Detailmodell) nutzen. Auch können diese Fragmente mit verschiedenem Fokus eingesetzt werden. Die oben eingeführten BEN-Komponenten werden im Folgenden charakterisiert: 1. Leistungsdefinition: Die wichtigsten Aktivitäten zur Leistungsdefinition sind die Wettbewerbs- und Marktanalyse, die Analyse der Kundenbedürfnisse und in diesem Zusammenhang die Analyse des Leistungsaustausches sowie die Analyse der Kernkompetenzen. Als Ergebnisdokumente entstehen Geschäftsnetzwerkmodelle, Geschäftspartnerprozessmodelle, Produkt/Service-Modelle und Modelle der strategischen Positionierung. 2. Zieldefinition: Zu den zentralen Aktivitäten gehören die Analyse der Organisationsziele, der Werttreiber und der Erfolgsfaktoren, die Analyse der strategischen Maßnahmen sowie die Operationalisierung von Zielen in Form von Führungsgrößen. Das zentrale Ergebnis der Zieldefinition ist das Modell des Zielsystems. 3. Prozessgestaltung: Die zentralen Aktivitäten sind die Prozessarchitekturplanung, die Leistungsanalyse, die Analyse der Prozessführung, die Ablaufplanung und die Prozesszerlegung. Die wichtigsten Ergebnisdokumente sind Prozesslandkarten sowie diverse Prozess-Ablaufmodelle, die auch Prozessführung und Outputqualität spezifizieren. 4. Aufbauorganisationsgestaltung: Durch Aufgabenanalyse und Aufgabensynthese werden aufbauorganisatorische Strukturen gestaltet. Als Ergebnisdokumente entstehen die verschiedenen Strukturmodelle für Rollen, Stellen und Organisationseinheiten, die in den Aufbauorganisationsmodellen näher detailiert werden. 5. Informationsgestaltung: Zentrale Aktivitäten sind Informationsbedarfsanalyse (mit verschiedenen Techniken) und konzeptionelle Informationsmodellierung. Zu den wichtigen Ergebnisdokumenten gehören die Informationslandkarte, welche den Gesamtzusammenhang der Informationsobjekte beschreibt, sowie das Informationsobjektmodell, welches ein Informationsobjekt und seine möglichen Analyseperspektiven beschreibt. 6. IT/Business Alignment: Die zentralen Aktivitäten zur Sicherstellung des „Sich-gegenseitig-aufeinander-Ausrichtens“ von fachlichen und IT-Strukturen sind Kopplungsanalysen, die entweder bottom-up (d.h. durch Analyse detaillierterer Artefakte) oder top-down (d.h. nach übergeordneten Erwägungen wie

BEN-Komponenten

91

Prozessfluss, Informationsfluss oder Wiederverwendung) erfolgen können. Zentrale Ergebnisdokumente des IT/Business Alignment sind Domänenmodelle, Applikationslandschaften, Capability-Modelle bzw. Modelle fachlicher Services. 7. Softwarelösungs-Fachkonzeption: Die zentralen Aktivitäten sind aus dem Requirements Engineering bekannt. Diese gehören aber u.E. nicht mehr zum Kernbereich des Business Engineering, sondern zum Systems Engineering, und werden somit in diesem Buch nicht näher erläutert. Wichtige Ergebnisdokumente sind Daten- und Softwarearchitekturmodelle. Darüber hinaus werden im Systems Engineering verschiedene bewährte Detailmodelle wie z.B. Steuerungsmodelle (z.B. ereignisgesteuerte Prozessketten - EPKs), Funktionsbäume, Use-Case-Diagramme usw. erstellt und genutzt. 8. IT-Infrastruktur-Konzeption: Die Analyse- und Gestaltungsaktivitäten, welche die IT-Infrastruktur betreffen, werden ebenfalls dem Systems Engineering – und damit nicht dem Business Engineering – zugeordnet. Als zentrales Ergebnisdokument beschränkt sich das Business Engineering auf IT-Infrastrukturmodelle.

4.1.6 Einsatz von BEN-Komponenten in verschiedenen Projekttypen Betrachtet man nun die verschiedenen in Kapitel 3.3.1 eingeführten grundsätzlichen BE-Projekttypen, so muss festgestellt werden, dass abhängig von den verschiedenen Projekten nur gewisse, selten aber sämtliche BEN-Komponenten zur Anwendung kommen. Auch ist die Reihenfolge, in der die Komponenten zur Anwendung kommen, in verschiedenen BE-Projekttypen unterschiedlich. Im Folgenden werden anhand der verschiedenen BE-Projekttypen die zu verwendenden BEN-Komponenten sowie ihre empfohlene Reihenfolge erläutert. Ausgewählte Beispiele für verschiedene Konfigurationen von BEN-Komponenten werden in Abb. 50 zusätzlich noch graphisch dargestellt. Als erstes wird das Beispiel eines Textilunternehmens betrachtet, welches das Leistungspotential in dem Sinne erweitert, dass die textile Flächenproduktion durch chemisch behandelte Flächen als weiteres strategisches Produkt ergänzt wird. Die Umsetzung einer solchen Leistungsänderung hat nicht nur Auswirkungen auf den Absatzmarkt, sondern zieht auch Veränderungen in den Abläufen und der gesamten Organisation des Unternehmens nach sich. Zusätzlich muss ein neuer Standort für die Behandlung der Textilen mit chemischen Substanzen ausgewählt werden, was wiederum nicht nur Anpassungen des IT/Business Alignment bedingt, sondern u. U. sogar Änderungen auf der Software- und/oder ITInfrastrukturebene erfordert.

92


Abb. 50. Beispiele für Konfigurationen von BEN-Komponenten

Eine solche Veränderung wird in BEN als fachlich getriebene Innovation, d.h. Veränderung der Geschäftslösung und Anpassung ihrer IT-Umsetzung eingestuft. Die BEN-Komponenten Leistungsdefinition, Zieldefinition, Prozessgestaltung, Aufbauorganisationsgestaltung, Informationsgestaltung, IT/Business Alignment oder u. U. alternativ Softwarelösungs-Fachkonzept und/oder IT-Infrastruktur-

BEN-Komponenten

93

Konzeption werden in dieser Reihenfolge durchlaufen (siehe Beispiel 1 in Abb. 50). Im BE-Stack wirkt die Veränderung „von oben nach unten“. Natürlich gibt es verschiedene Ausprägungen fachlich getriebener Innovationen, die sich nicht über alle BE-Ebenen hinweg auswirken. Ein Beispiel dafür ist ein Prozess-Redesign bei gleichbleibender Strategie. Dies würde bedeuten, dass die Strategieebene davon gar nicht betroffen wäre, sondern im Idealfall nur die Komponenten Prozessgestaltung und IT/Business Alignment (siehe Beispiel 2 in Abb. 50). IT/Business Alignment sollte solche Änderungen im Idealfall auffangen, ohne dass Auswirkungen auf die „technischen“ BE-Ebenen notwendig werden. Wird eine technisch getriebene Innovation wie z.B. die Einführung von Selbstbedienungslösungen als Treiber für neue Geschäftslösungen betrachtet, so kann dies, wie beim Textilbeispiel, Auswirkungen über alle Ebenen hinweg haben. Bekannte Beispiele für derart umfassende technisch getriebene Innovationen sind die Erneuerung des Konsumgütervertriebs durch Amazon oder das breite Ausrollen von Mass Customization durch Dell. In derartigen Fällen würden die folgenden BEN-Komponenten durchlaufen: Softwarelösungs-Fachkonzeption und/oder IT-Infrastruktur-Konzeption, IT/Business Alignment, Prozessgestaltung, Aufbauorganisationsgestaltung, Informationsgestaltung und eventuell Leistungsdefinition und Zieldefinition (siehe Beispiel 3 in Abb. 50). Im BE-Stack wirken solche Innovationen also tendenziell „von unten nach oben“. Natürlich gibt es auch für diesen BE-Projekttyp Variationen: Bestimmte Software-Innovationen wie z. B. der Ersatz einer Standardsoftware durch eine andere Standardsoftware erfordern u. U. nicht nur keine Anpassung der IT-Plattform, sondern können durch Anpassung des IT/Business Alignment auch ohne Änderungen auf Organisationsebene auskommen. Somit wären in solchen Fällen nur die BEN-Komponenten Softwarelösungs-Fachkonzeption und IT/Business Alignment tangiert (siehe Beispiel 4 in Abb. 50). Während sowohl fachlich getriebene Innovationen wie auch technisch getriebene Innovationen zwei oder mehr BEN-Komponenten „von oben nach unten“ oder „von unten nach oben“ tangieren, beschränkt sich die Schaffung von Potenzialen unmittelbar auf eine Komponente, schafft aber Innovationspotenzial auf der jeweils darüber liegenden BE-Ebene. So ermöglicht die serviceorientierte Strukturierung von Software eine Flexibilisierung von Softwarelösungen (BENKomponente Softwarelösungs-Fachkonzeption), so dass diese einfacher an veränderte fachliche Bedarfe angepasst werden können. Ähnlich ermöglicht eine serviceorientierte Strukturierung von Capabilities im Sinne fachlicher Services (BEN-Komponente IT/Business Alignment) eine Flexibilisierung sowohl auf Seiten der nutzenden fachlichen Strukturen wie auch auf Seiten der unterstützenden Softwaresysteme. Schließlich ermöglicht die serviceorientierte Strukturierung von Ablauf- und Aufbaustrukturen der Organisation (BEN-Komponenten Prozess- und Ablauforganisationsgestaltung), dass darauf basierende Geschäftsarchitekturen schneller und einfacher verändert werden können. Ein gutes Beispiel hierfür ist die umgesetzte serviceorientierte Architektur der Firma SAP, die in Form der „Business Suite“-Software und der „NetWeaver“-Technologieplattform angeboten wird.

94


Ziel dieser Softwarearchitektur ist es, IT-Funktionalitäten in serviceorientierter Form verfügbar zu machen, so dass sie nicht nur in unterschiedlichster Weise genutzt werden kann (das ist ja das Ziel jeglicher Standardsoftwarelösung), sondern dass auch Nutzungsänderungen schnell und problemlos in Form von „ReOrchestrierung“ umgesetzt werden können, ohne dass (zumindest für die Mehrzahl der Nutzungsänderungen) Anpassungen auf Softwareebene notwendig würden. Potenziale können nicht nur auf jeweils benachbarten, sondern auch auf der gleichen Gestaltungsebene geschaffen werden: So werden durch die Einführung von Integrations-Infrastrukturen Schnittstellen reduziert und damit nicht nur kostengünstiger zu betreibende, sondern auch schneller und einfacher zu ändernde Strukturen auf der betreffenden BE-Ebene ermöglicht. Beispiele sind Data Warehousing oder Enterprise Application Integration auf Softwareebene, eine fachliche Vernetzungs-Infrastruktur (in Form von Standards und Shared Services) auf Organisations- bzw. Strategieebene sowie ein Integrationsbus auf IT/Business Alignment-Ebene. Allen BE-Projekten zur Schaffung von Potenzialen ist gemeinsam, dass zwar nur eine oder wenige BEN-Komponenten genutzt werden, aber aufgrund des speziellen Charakters dieser Projekte die Nutzeffekte der Innovationen über einen längeren Zeitraum und/oder an anderen Orten auftreten, als die Investition erfolgt. Im Gegensatz zu den fachlich und technisch getriebenen Projekten, bei denen Innovationen im Vordergrund stehen, steht bei den Projekten der gegenseitigen Abstimmung die gegenseitige Anpassung von Strukturen im Vordergrund. Dies basiert aufgrund von „auseinander entwickelten“ Strukturen, verursacht durch Innovationen, die nicht oder nicht vollständig auf anderen Ebenen umgesetzt wurden oder die sich in unterschiedlichen Zyklen entwickelt haben. Zu den Projekten der gegenseitigen Abstimmungen gehören sowohl die klassischen IT/Business Alignment-Projekte wie auch die Sourcing-Projekte. Zu den klassischen IT/Business Alignment-Projekten gehören z.B. die Abstimmung von Verfügungsrechten, welche auf Organisationsebene definiert werden, mit den Berechtigungen auf Softwareebene oder die Abstimmung der Softwarearchitektur mit der fachlichen Architektur. Solche Projekte werden auch als „vertikale“ Abstimmungsprojekte bezeichnet und betreffen die Anwendung von verschiedenen BEN-Komponenten auf unterschiedlichen Ebenen. In den eben genannten Beispielen währen sowohl die Komponenten „IT/Business Alignment“ wie auch „Softwarelösungs-Fachkonzeption“ tangiert. Unter Umständen könnten auch noch die Komponenten „Prozessgestaltung“ und/oder „Aufbauorganisationsgestaltung“ betroffen sein. Bei Sourcing-Projekten hingegen werden Strukturen eines Unternehmens (z.B. eines auslagernden Unternehmens) mit Strukturen eines anderen Unternehmens (z.B. eines Dienstleisters oder Service Providers) in Einklang gebracht. Solche Projekte werden als „horizontale“ Abstimmungsprojekte“ bezeichnet und es werden im Normalfall nur BEN-Komponenten auf der gleichen Ebene tangiert. Will man z.B. die Prozesse beider Unternehmen abstimmen, so würden die Prozessge-

BEN-Komponenten

95

staltungskomponenten betroffen sein. Sollen hingegen Softwarelösungen in Einklang gebracht werden, wäre die Komponente „Softwarelösungs-Fachkonzeption“ betroffen. Zusammengefasst heißt dies für BEN, dass das Engineering bei Projekten der gegenseitigen Abstimmung nicht von „oben nach unten“ oder von „unten nach oben“ stattfindet, sondern dass unterschiedliche Strukturen, seien diese in vertikaler oder horizontaler Richtung angeordnet, analysiert und in Einklang gebracht werden. Solche Projekte werden also quasi von „außen nach innen“ durchgeführt. Dementsprechend werden auch, wie in den oberen Abschnitten erläutert, unterschiedliche BEN-Komponenten tangiert. In Abb. 51 werden die oben eingeführten Konfigurationsmöglichkeiten der BEN-Komponenten für die verschiedenen BE-Projekttypen graphisch dargestellt. Da die Darstellung den klassischen, vertikal dargestellten BE-Stack verdreht, werden in Abb. 51 „vertikale Abstimmung“ in horizontaler Richtung und „horizontale Abstimmung“ in vertikaler Richtung dargestellt. !##'

#! %#

#!#

!"#"

!("" "##$

$""" #

$$! "#" "##$

!#" "##$

"#! %#

$""" #

$""" #

$% #( " % !%"

!("" "##$

$$! "#" "##$

!#" "##$

$""" #

"# "#$ %!# "#$

!("" "##$

$$! "#" "##$

!#" "##$

$""" #

#&!) "$" ( #

!"#!$ #$! ( #

#&!) "$" ( #

!"#!$ #$! ( #

#! !("" "##$

$$! "#" "##$

!#" "##$

!("" "##$

$$! "#" "##$

!#" "##$

"# "#$ !(# "#$

#!

Abb. 51. Konfiguration von BEN-Komponenten für verschiedene BE-Projekttypen

In den folgenden Abschnitten werden die in Kapitel 4.1 skizzierten BENKomponenten detailliert. Die Aktivitäten der BEN-Komponenten werden zum Teil anhand des Smart Travel Beispiels illustriert. Eine kurze Beschreibung des Smart Travel Beispiels findet sich in Abb. 52. Für detaillierte Information dazu wird auf die Arbeiten von (Kurpjuweit 2008; Gericke 2006) verwiesen.

96

BEN-Komponenten der Strategieebene

Abb. 52. Beispiel Smart Travel

4.2 BEN-Komponenten der Strategieebene Das Gestaltungsziel auf Strategieebene ist die Festlegung der Positionierung der jeweils betrachteten Geschäftseinheit unter Beachtung von Marktbedürfnissen und Kernkompetenzen. Auf Strategieebene wird das „was“ betrachtet, nicht das „wie“. Das bedeutet, dass – unabhängig von der organisatorischen Umsetzung der Abläufe und Strukturen – die Leistungen und Ziele der betrachteten Geschäftseinheit zu definieren sind. Gegenüber der organisatorischen Umsetzung, die möglichst flexibel sein sollte und damit auch häufigen Änderungen unterworfen ist, sollten die Leistun-

BEN-Komponenten

97

gen und Ziele einer Geschäftseinheit, zumindest im Großen und Ganzen, stabiler sein. In Abschnitt 4.2.1 werden die Analyse- und Gestaltungsaufgaben beschrieben, die in Zusammenhang mit der Leistungsdefinition stehen. In Abschnitt 0 werden die Analyse- und Gestaltungsaufgaben beschrieben, die in Zusammenhang mit der Zieldefinition stehen. Leistungen und Ziele können für verschieden umfassende Geschäftseinheiten definiert werden. Die umfassendste „Geschäftseinheit“ ist ein gesamthaft betrachtetes Wertschöpfungsnetzwerk; Kleinere Geschäftseinheiten sind z.B. ein Konzernverbund, ein Unternehmen, eine strategische Geschäftseinheit, ein Geschäftsbereich oder auch eine Abteilung. Die im Folgenden beschriebenen Analyse- und Gestaltungsaufgaben sind prinzipiell für Geschäftseinheiten beliebiger Größe anwendbar.

4.2.1 Leistungsdefinition Leistungen werden „top-down“ und „outside-in“ definiert. Top-down heißt, dass Leistungen zunächst grob skizziert und dann detaillierter analysiert und spezifiziert werden. Outside-in heißt, dass Leistungen ausgehend von Kundenbedürfnissen und nicht ausgehend von Kompetenzen definiert werden. Dabei ist es unerheblich, ob es sich um interne oder externe Kunden handelt. Im Folgenden werden die verschiedenen Aktivitäten erläutert, die zur Erstellung der Leistungsdefinition notwendig sind. Diese Aktivitäten umfassen: gesamthafte Analyse des Leistungsaustausches, Detailanalyse von Kundenbedürfnissen, Zusammenfassung des Leistungsprogramms, Kategorisierung der strategischen Positionierung einer Geschäftseinheit und die Kategorisierung des Leistungsprogramms.

4.2.1.1 Gesamthafte Analyse des Leistungsaustausches Die gröbste Analyse bzw. Festlegung von Leistungen erfolgt bei der Definition des Geschäftsnetzwerks, d.h. der Beziehungen zwischen der betrachteten Geschäftseinheit und anderen Geschäftseinheiten, welche die Rolle von Kunden, von Lieferanten, von Partnern oder von Mitbewerbern haben können. In Geschäftsnetzwerken gibt es verschiedene Rollen (in Anlehnung an Österle u. Winter 2003; Leist u. Winter 2000): 1. Service Integrators integrieren (im Normalfall nicht selbst erstellte) Leistungskomponenten, um damit bestimmte Kundenprozesse möglichst ganzheitlich zu unterstützen. Die Kernkompetenz eines Service Integrators ist deshalb die umfassende Kenntnis von Kundenbedürfnissen bzw. Kundenprozessen („Customer Intimacy“). Typische Beispiele sind im Business-to-Consumer-Bereich Portale

98


wie beispielsweise autobytel.com. Auch im Business-to-Business-Bereich finden sich vermehrt Service Integrators wie beispielsweise paintandcoatings.com für Prozesse rund um Oberflächenbehandlung. 2. Shared Service Providers produzieren standardisierte Leistungskomponenten für verschiedene andere Service Providers oder Service Integrators. Im Gegensatz zu Service Integrators decken sie keine komplexen Bedürfnisse ganzheitlich ab, sondern spezialisieren sich auf die effiziente Herstellung standardisierter Leistungskomponenten in großen Mengen. Typische Beispiele sind Outsourcing-Unternehmungen (z. B. EDS), Automobilzulieferer (z. B. VDO) oder Transaktionsbanken (z. B. Postbank). 3. Exclusive Service Providers erzeugen ebenfalls Leistungskomponenten für andere Service Providers oder Service Integrators; Im Gegensatz zu Shared Service Providers werden aber nicht große Mengen hochgradig standardisierter und wieder verwendbarer Leistungskomponenten für mehrere Abnehmer produziert, sondern spezifische Leistungskomponenten für einen oder wenige Abnehmer und damit eher kleinere Mengen hergestellt. An die Stelle von Kundenbzw. Kundenprozesskenntnis (Service Integrator) bzw. Kostenführerschaft (Shared Service Provider) treten als Haupt-Erfolgsfaktoren Schnelligkeit, Flexibilität und/oder spezifische Prozesskompetenzen. Typische Beispiele sind Ingenieurbüros, Zollabwicklungsbüros oder Produktentwicklungsspezialisten im Asset Management. 4. Public Services stellen Leistungskomponenten bereit, die keinen branchenoder kundenprozessspezifischen Charakter haben, aber zur Abwicklung der Leistungserstellung wichtig sind. Beispiele für Public Services sind Informationsdienste (z. B. Directories), Zahlungsabwickler (z. B. PayPal) oder Logistikabwickler. Ausgehend von den adressierten Kundenprozessen werden bei der Geschäftsnetzwerkanalyse die relevanten „Player“ im betrachteten Wertschöpfungsnetzwerk identifiziert sowie die zwischen ihnen ausgetauschten Leistungen skizziert. Die Wettbewerbsanalyse nach (Porter 1999) stellt konkrete Instrumente bereit, um die wesentlichen „Player“ und die relevanten Kundenprozesse zu identifizieren. Ausgangspunkt der Analyse des Wertschöpfungsnetzwerks sind die Kundenprozesse, hinter denen in den meisten Fällen auch spezifische Kundensegmente stehen. Jeweils bestimmte Kundenprozesse werden durch Service Integrators ganzheitlich unterstützt, wobei ein Kundenprozess (bzw. Kundensegment) auch durch verschiedene Service Integrators unterstützt werden kann. Über einen längeren Betrachtungszeitraum hinweg ist dies häufig der Fall, da sich die Unterstützung oft auf Kundenprozesse bezieht, die nur selten oder gar einmalig auftreten (wie z. B. Wohneigentumserwerb). Das Kundensegment „wandert“ dann entsprechend der jeweiligen Lebensphase bzw. der jeweils aktuellen Lebensereignisse von einem prozessspezifischen Service Integrator zum nächsten. Service Integrators sowie Service Providers beziehen Leistungskomponenten von Shared Service Providers, Exclusive Service Providers und Public Services.

BEN-Komponenten

99

Dabei werden im Normalfall mehrstufige Leistungsketten entstehen. Während Exclusive Service Providers nur einen oder wenige Service Providers bzw. Service Integrators beliefern und deshalb u. U. aus Effizienzgründen direkte Vernetzungen aufbauen, erfolgen alle anderen Vernetzungen im Idealfall über eine gemeinsame, offene Kollaborationsinfrastruktur („Business Collaboration Infrastructure“). An die Stelle einer Vielzahl bilateraler Vernetzungen zwischen Geschäftsmodellen tritt dann jeweils nur ein einziger „Adapter“ zu dieser gemeinsamen Infrastruktur. Der direkte Zugriff von Konsumenten auf Leistungskomponenten von Service Providers ist möglich, wenn seitens der Kunden die Nutzung eines Service Integrators nicht erwünscht ist oder wenn die zu unterstützenden Prozesse so spezifisch sind, dass sich eine individuelle Kombination von Leistungskomponenten nicht vermeiden lässt. In Abschnitt 2.3.3 wurde das Geschäftsnetzwerkmodell vorgestellt, mit dessen Hilfe die gesamthafte Abdeckung von Kundenbedürfnissen beschrieben werden kann. Ein Geschäftsnetzwerkmodell fokussiert immer auf bestimmte Kundenbedürfnisse und beschreibt die Zusammenarbeit zwischen Serviceprovidern gesamthaft und damit auf aggregierter Ebene. Wenn mehrstufige Integrations- bzw. „Veredlungsprozesse“ von Vorleistungen stattfinden, sollte dies auch in unterschiedlichen Geschäftsnetzwerkmodellen abgebildet werden. Damit nicht jeder Service Provider mit jedem Service Integrator individuelle Vernetzungen aufbauen und weiterentwickeln muss, sollte eine n:m-fähige Kollaborationsinfrastruktur aufgebaut und genutzt werden, wo immer möglich und sinnvoll (siehe hierzu auch Abb. 53).

Abb. 53. Geschäftsnetzwerkmodell im Beispiel Smart Travel

Obwohl der Begriffsteil „Infrastruktur“ hier technische Aspekte nahe legt (z. B. IP-Netz zur Datenübertragung, Web Service-Protokolle zur Abwicklung), liegt der differenzierende Schwerpunkt der Business Collaboration Infrastructure nicht auf

100


(allgemein verfügbaren und nutzbaren) technischen Komponenten, sondern auf organisatorischen Komponenten wie z. B. Leistungsbeschreibungsstandards oder standardisierten Anbahnungs- und Abwicklungsprozessen. Die einzige Ausnahme, die langfristig den Aufbau und die Weiterentwicklung individueller Vernetzungen rechtfertigt, ist Exklusivität. Da Exclusive Service Providers nur einen oder ganz wenige Service Providers oder Service Integrators bedienen (sonst wäre ja „Exclusive“ unzutreffend), kann eine individuelle Point-zu-Point-Vernetzung Sinn machen. Trotz der terminologischen Nähe wird durch ein Geschäftsnetzwerkmodell kein sog. Geschäftsmodell („Business Model“ (Zott u. Amit 2003)) repräsentiert. Beim Geschäftsnetzwerkmodell steht das Zusammenwirken von Unternehmungen zur Unterstützung von Kundenprozessen im Vordergrund. Dagegen soll ein Geschäftsmodell die Werttreiber und die Wertschöpfung abbilden, d. h. zusätzlich zu (oder an Stelle von) Leistungsbeziehungen insbesondere die Wertflüsse darstellen. Werte liegen jedoch außerhalb der Leistungsdefinition, weil sie spätere bzw. ergänzende, zielorientierte Erweiterungen bzw. Auswertungen darstellen.

4.2.1.2 Detailanalyse von Kundenbedürfnissen Die Beschreibung der Positionierung im Geschäftsnetzwerkmodell ist noch relativ grob. Zur feineren Spezifikation der zu erbringenden Leistungen und der Arbeitsteilung mit Wertschöpfungspartnern erfolgt im Geschäftspartnerprozessmodell (Heinrich 2002c) eine Fokussierung auf eine bestimmte, komplexe Leistung und auf ein bestimmtes, komplexes Kundenbedürfnis. Wenn dabei die Vorleistungsseite der Leistungserstellung betrachtet wird, entsteht ein Lieferantenprozessmodell; Wenn die Kundenseite betrachtet wird, entsteht ein Kundenprozessmodell. Pro Geschäftsnetzwerkmodell wird es deshalb viele Lieferanten- und Kundenprozessmodelle geben. Im Geschäftspartnerprozessmodell wird eine komplexe Leistung in Form mehr oder weniger elementarer Leistungsbestandteile strukturiert (siehe Abb. 54). Die prozessartige Strukturierung steht dabei zumindest auf Seiten des Leistungserbringers nicht im Vordergrund, da Abläufe ja erst auf Organisationsebene modelliert werden. Auf Kundenseite können grundlegende Abläufe jedoch Einfluss auf das gesamthafte Verständnis des Bedürfnisses haben: Das „Wie“ des Kunden wird zum „Was“ des Lieferanten. Zunächst werden die verschiedenen Teilaspekte des abzudeckenden komplexen Kundenbedürfnisses strukturiert (rechte Seite in Abb. 54). Auf dieser Grundlage wird für jeden Teilaspekt geprüft, welche Leistungskomponenten die betrachtete Geschäftseinheit erbringen sollte, um das jeweilige Teilbedürfnis bestmöglich zu unterstützen (linke Seite in Abb. 54). In einem nachfolgenden Schritt ist für jede Leistungskomponente zu prüfen, ob sie durch die jeweils betrachtete Geschäftseinheit selbst erbracht oder sinnvoller fremdbezogen werden sollte. Schließlich sind geeignete Bündelungen und Vertriebskanäle zu identifizieren, die

BEN-Komponenten

101

sich nicht nur auf die selbst erstellten Leistungskomponenten, sondern auch auf zu integrierende Fremdleistungen beziehen.

Abb. 54. Kundenprozessmodell für Leistungsbeziehung

4.2.1.3 Zusammenfassung des Leistungsprogramms Durch die überblicksartigen Geschäftsnetzwerkmodelle und die zur Detaillierung jeweils einer Leistungsbeziehung entwickelten Geschäftspartnerprozessmodelle wird das Leistungsprogramm einer Geschäftseinheit bereits sehr umfassend definiert – allerdings in verteilter Form und nicht in einem umfassenden, gesamthaften Modell, mit dessen Hilfe auch Konsistenz und Systematik gesichert werden könnte. Deshalb wird im Produkt-/Servicemodell zusammenfassend beschrieben, wie das Leistungsprogramm einer Geschäftseinheit strukturiert ist. Das Produkt/Servicemodell beschreibt das Leistungsprogramm dabei nicht annähernd im Detaillie-

102


rungsgrad eines ERP-Systems. Es geht vielmehr darum, die in den u.U. sehr vielen Geschäftspartnerprozessmodellen verteilten Informationen zu Produkten/Services (siehe Abb. 55) und zu Produkt/Service-Komponenten (siehe Tab. 3) in ein Gesamtmodell zusammenzuführen.

Abb. 55. Zusammenführung des Leistungsprogramms im Beispiel Smart Travel

Abb. 55 zeigt, wie die (Markt-)Leistungskomponenten der verschiedenen Geschäftspartnerprozessmodelle des Smart Travel-Beispiels in eine integrierte Auflistung der Produkte/Services des Reiseanbieters zusammengeführt werden. Gewisse Services, wie z.B. „Reisebuchung“, kommen in verschiedenen Geschäftspartnerprozessmodellen vor, und andere sind sehr spezifisch für bestimmte Geschäftspartnerprozessmodelle, wie z.B. „Individuelle Reisekonfiguration“. Tab. 2.

Produkt-/Servicefamilien

Produkt/Service Pauschalreise

Individualreise

…

Produkt-/Servicefamilie - Städtereise - Cluburlaub - Familienurlaub - Erlebnisreise - Aktivurlaub - … - Einzelkomponente - Flug & Hotel - …

BEN-Komponenten

103

Aus den zusammengeführten Produkten/Services werden viele verschiedene Produkt-/Servicevarianten konfiguriert und den Kunden angeboten. Ähnliche Varianten lassen sich dabei zu Produkt-/Servicefamilien zusammenfassen (siehe hierzu auch Tab. 2). So beinhaltet das Grundprodukt „Pauschalreise“ z.B. die Produktfamilien „Städtereisen“, „Club-Urlaub“ oder „Familienurlaub“. Eine Produktvariante von „Familienurlaub“ wäre z.B. eine konkrete Pauschalreise mit Flug und Vollpension an ein bestimmtes Ziel mit bestimmten Flug-, Hotel-Leistungen usw. Selbst diese Produktvariante kann noch weiter differenziert werden, wenn z.B. Hin- und Rückreisetermine, Buchungszeitpunkte (Frühbucher vs. reguläres Angebot vs. Last Minute) differenziert werden. Um diese Variantenvielfalt bewältigen zu können, ist es sinnvoll die einzelnen Produkt- bzw. Service-Komponenten zu identifizieren, damit diese in den verschiedenen Varianten wiederverwendet werden können. Dies ist sowohl auf Ebene von Produkten/Services wie auch für Produkt-/Servicefamilien wie auch für Varianten möglich. Ein Beispiel einer möglichen Zuordnung von Komponenten zu Varianten wird in Tab. 3 illustriert. Tab. 3.

Produkt-/Servicekomponenten für Smart Travel

Produkt-/Servicevariante

Komponente

Pauschalreise: Aktivurlaub in X, Hotel Y (***), Vollpension

Flug Zug Hotel Reiseversicherung …

Pauschalreise: Aktivurlaub in X, Hotel Z (****), Halbpension

Flug Mietwagen Hotel Kinderbetreuung …

…

4.2.1.4 Kategorisierung strategischer Positionierungen Geschäftsnetzwerkmodelle, Geschäftspartnerprozessmodelle und das Produkt-/Servicemodell liefern bereits viele Hinweise auf die strategische Positionierung. Allerdings stehen in allen diesen Modellen die Vernetzung mit Partnern und die Abdeckung von Kundenbedürfnissen im Vordergrund, nicht die Innensicht der betrachteten Geschäftseinheit. Das Modell der strategischen Positionierung erlaubt darüber hinaus, auch die Innensicht (z.B. Kompetenzen/Potenziale) zu modellieren.

104


In BEN orientiert sich das Modell der strategischen Positionierung an der Konzeption des morphologischen Kastens (Higgins u. Wiese 1996), d. h. beschreibt ein Artefakt anhand der Ausprägungen hinsichtlich bestimmter Dimensionen. Als Dimensionen sollten sowohl exogene Faktoren (d. h. äußere, nicht direkt beeinflussbare Rahmenbedingungen) wie auch endogene Faktoren (d. h. direkt beeinflussbare Aspekte der unternehmerischen Tätigkeit) berücksichtigt werden. Eine strategische Positionierung kann für eine Geschäftseinheit, aber auch für ein Produkt/einen Service oder einen Organisationsansatz erfolgen. BEN lässt im Grundsatz offen, welche Dimensionen und welche jeweiligen Ausprägungen als relevant und für die Kategorisierung zielführend betrachtet werden. Im Folgenden wird exemplarisch die Kategorisierung der strategischen Positionierung von Geschäftseinheiten und von Produkten/Services betrachtet.

Kategorisierung der strategischen Positionierung einer Geschäftseinheit Um die strategische Positionierung einer Geschäftseinheit zu kategorisieren, müssen entsprechende Dimensionen und Ausprägungen erlauben, die wesentlichen Aspekte der Positionierung darzustellen (Dimensionen) und unterschiedliche Positionierungen ausreichend (in Form unterschiedlicher Ausprägungen bzw. Ausprägungskombinationen) zu differenzieren. Je unterschiedlicher die Ausprägungen verschiedener Geschäftseinheiten in einer Dimension sind, desto besser ist die entsprechende Dimension und die gewählten Ausprägungen zur Kategorisierung der jeweiligen strategischen Positionierung geeignet. Im Folgenden werden exemplarisch Dimensionen und mögliche Ausprägungen für einen Reiseanbieter (am Beispiel Smart Travel), aufgelistet. Es wird unterschieden zwischen exogene, d.h. marktbezogene Faktoren und endogene, d.h. kompetenzbezogene Faktoren. Exogene Faktoren •

•

• •

Die Dimension Zielgruppe kann in Gruppen- oder Altersstrukturen unterteilt werden. Für die Gruppenstruktur können Ausprägungen wie „Alleinreisen“, „Paarreisen“, „Singlereisen“, „Familienreisen“ oder „Gruppenreisen“ unterschieden werden. Ausprägungen wie „Jugend“, „Studenten“, „Junge Berufstätige“, „Berufstätige“ oder „Senioren“ gehören zur Einteilung Altersstrukturen. Hinsichtlich der Markenkonzeption können die generischen Grundtypen „Traditionell“, „Convenience“, „Exklusiv“, „Fachkundig“, „Preiswert“ und „Modern und Innovativ“ unterschieden werden. Als Mitbewerber können Reisebüros, Online-Plattformen, Lokale Reiseanbieter oder Reisekonzerne in Frage kommen. Bezüglich der Preispolitik kann sich ein Reiseanbieter als Discounter, Mittelklasse-, Obere Mittelklasse- oder Luxus-Anbieter positionieren.

BEN-Komponenten

•

•

105

Hinsichtlich des Vertriebswegs (Kommunikation) können stationärer Vertrieb, mobiler Vertrieb und elektronische Vertriebswege unterschieden werden. Weiterhin kann es eine Rolle spielen, ob der Kundenkontakt hauptsächlich in Form von Selbstbedienung, passivem Kontakt (Kunde kommt in das Reisebüro oder ruft an) oder aktivem Kontakt (Aufbau der Kommunikation wird vom Reiseanbieter initiiert) stattfindet. Schließlich ist der Wert der Leistung aus Marktperspektive enorm wichtig. Es kann z.B. zwischen Erlebnis- & Abenteuer-Reisen, Erholungs-, Kunst- & Kultur-, Sport-, Party-, oder Bildungs-Reisen unterschieden werden.

Endogene Faktoren: •

•

•

Als Beispiel sei hier die Betreuungsintensität erwähnt. Diese zählt sicherlich zu den wichtigsten kompetenzbezogenen Faktoren in der Reisebranche. Verschiedene Ausprägungen sind hier denkbar: die Einrichtung einer Hotline für Problemlösungen und Frageklärungen oder die Organisation eines Ansprechpartners oder sogar eines Reiseleiters vor Ort. Zusätzlich stellt die Kompetenzquelle eine wichtige Dimension der strategischen Positionierung dar. Hier kann z.B. zwischen Ausprägungen wie erfahrene und kompetente Beratung durch die eigenen Mitarbeiter des Unternehmens oder aber exklusive Kooperationen mit Partnern unterschieden werden. Auch spielt die Organisation eines Unternehmens eine wichtige Rolle. So könnten z.B. zentralisierte Organisationen, die Skaleneffekte nutzen, oder vernetzte Organisationen mit auf jeweils bestimmte Leistungen oder Kundensegmente spezialisierten Partnerunternehmen als Ausprägungen in Frage kommen.

Aus der Analyse der in Dokumentenform (meist Fließtext) vorliegenden Geschäftsstrategie sowie aus Gesprächen mit Strategieverantwortlichen ergeben sich neben trivialen Einordnungen (z. B. Mitbewerber) auch schwierige Festlegungen wie z. B. die Zielgruppe (Gruppenstruktur oder Altersstruktur) oder unscharfe Abgrenzungen (z. B. bei der Markenkonzeption hauptsächlich „Convenience“, aber auch „Fachkundig“). Tab. 4 fasst die eben eingeführten Dimensionen und deren Ausprägungen auszugsweise in Form eines morphologischen Kastens zusammen und positioniert durch die hervorgehobenen Zellen einen Kultur-Reiseanbieter der oberen Mittelklasse.

106


Tab. 4.

Strategische Positionierung im Beispiel Smart Travel

Dimension

Ausprägung Alleinreisende

Altersstruktur

Jugend

Markenkonzeption

Traditionell

Preispolitik

Discounter

Vertriebswege

Stationärer Vertrieb

Leistungswert

Erlebnis- & AbenteuerReise

Betreuungsintensität

Hotline

Zielgruppe

Gruppenstruktur

Paarreisende

Studenten Convenience

Junge Berufstätige

Exklusiv

Mittelklasse Anbieter

ErholungsReise

Singlereisende

Fachkundig

Familienreisende

Berufstätige

Senioren

Preiswert

Obere Mittelklasse Anbieter

Modern & Innovativ LuxusAnbieter

Mobiler Vertrieb

Elektronischer Vertrieb

Kunst& KulturReise

PartyReise

SportReise

Ansprechpartner vor Ort

BildungsReise

Reiseleiter vor Ort

Je größer die betrachtete Einheit ist, desto mehr Ausprägungen treffen üblicherweise zu und umso unschärfer wird die Kategorisierung. Wenn auch bei kleineren Einheiten in vielen Dimensionen viele oder gar alle Ausprägungen zutreffen, sollte entweder das Kategorisierungssystem überarbeitet werden (neue Dimensionen, zusätzliche Ausprägungen, Zusammenlegung bestehender Ausprägungen); Fehlende Fokussierung kann aber auch ein Indikator für die Notwendigkeit sein, die strategische Positionierung zu überarbeiten und das Profil der betrachteten Einheit zu schärfen. Mit zunehmender Erfahrung in der Nutzung von Modellen der strategischen Positionierung wird es möglich werden, Regeln zu definieren. Bestimmte Ausprägungen einer Dimension werden manchmal bestimmte Ausprägungen in dieser oder anderen Dimensionen implizieren oder ausschließen. So wird z.B. die Markenpositionierung einer Geschäftseinheit starke Einflüsse auf Vertriebskanäle haben. Mit Hilfe solcher Erfahrungs-Regeln kann das Modell der strategischen Positionierung nicht nur zur Abbildung, sondern auch zu rudimentären Konsistenzprüfungen herangezogen werden.

BEN-Komponenten Tab. 5.

107

Kategorisierung einer Individualreise im Beispiel Smart Travel

Dimensionen

Ausprägungen

Reisebuchung

An-/Abreise

Hotel

Hoteltransfer

Mietwagen

Individuelle Reisekonfiguration

Fahrer

Reiseleiter

Ausflüge

Reiseroute

Kontaktpflege

Persönlich

Telefonisch

Schriftlich

Elektronisch

Reisebetreuung vor Ort

Empfang bei Ankunft

Verabschiedung bei Abreise

Betreuungsbesuch

Telefonische Nachfrage

Tab. 6.

Kategorisierung einer Pauschalreise im Beispiel Smart Travel

Dimensionen

Ausprägungen

Reisebuchung

An-/Abreise

Hotel

Hoteltransfer

Mietwagen

Individuelle Reisekonfiguration

Fahrer

Reiseleiter

Ausflüge

Reiseroute

Kontaktpflege

Persönlich

Telefonisch

Schriftlich

Elektronisch

Reisebetreuung vor Ort

Empfang bei Ankunft

Verabschiedung bei Abreise

Betreuungsbesuch

Telefonische Nachfrage

Kategorisierung von Produkten/Services Das Modell der strategischen Positionierung kann nicht nur für die Kategorisierung, die Konsistenzprüfung, den Vergleich etc. von ganzen Geschäftseinheiten, sondern auch für die Kategorisierung, die Konsistenzprüfung, den Vergleich etc. eines Leistungsprogramms benutzt werden. Da in BEN die Dimensionen und Ausprägungen frei definiert werden können, kann auch ein morphologischer Kasten für z.B. das Leistungsprogramm definiert werden. In diesem Fall wird nicht eine Geschäftseinheit, sondern ein Produkt oder ein Service (bzw. eine Pro-

108


dukt-/Servicefamilie) im Modell positioniert, d.h. hinsichtlich bestimmter Dimensionen und Ausprägungen kategorisiert. Diese Nutzung des Modells der strategischen Positionierung hat Ähnlichkeit mit einem Produkt-/Servicekonfigurator. Mit Hilfe eines solchen Modells kann systematisch beschrieben werden, wie bestimmte Leistungskonfigurationen hinsichtlich z.B. Vertragstyp, Preismodell usw. definiert sind. Auch in diesem Fall dienen die Positionierungsmodelle nicht nur der Repräsentation, sondern können auch zum Vergleich zweier Produkt-/Servicekonfigurationen, zur Prüfung der Vollständigkeit des Leistungsprogramms, zur Prüfung logischer Abhängigkeiten usw. eingesetzt werden. Für das Beispiel Smart Travel kann jedes Produkt (z.B. Cluburlaub oder Erlebnisreise) anhand einer oder mehrerer Ausprägungen in jeder Dimension eines solchen Modells eingeordnet werden. In Tab. 5 wird ein morphologischer Kasten für die Kategorisierung des Produkts „Individualreise – Erlebnisreise“ verwendet, in Tab. 6 hingegen wird das Produkt „Pauschalreise – Cluburlaub“ kategorisiert.

4.2.2 Zieldefinition Im Modell der strategischen Positionierung können, z.B. in Form von Erfolgsfaktoren oder Quellen von Kompetenzen bereits wichtige zielbezogene Festlegungen getroffen werden. Als Vorbereitung für die Prozessmodellierung ist es jedoch notwendig, das Zielsystem viel umfassender und viel detaillierter zu beschreiben. Ein detailliertes, konsistentes System von (strategischen) Führungsgrößen bildet die Grundlage, um Prozesse hinsichtlich der jeweiligen Effizienzziele steuern zu können. Für die jeweils betrachtete Geschäftseinheit enthält das Zielsystem die als relevant erachteten Organisationsziele sowie die diesen Zielen zuzuordnenden kritischen Erfolgsfaktoren und (strategischen) Führungsgrößen. Sowohl Organisationsziele wie auch Erfolgsfaktoren und (strategische) Führungsgrößen können bei Bedarf ein- oder mehrfach hierarchisch zerlegt werden. Organisationsziele legen langfristig die generelle Richtung der betrieblichen Aktivitäten für die Unternehmung fest, ohne jedoch unmittelbar umsetzbar zu sein. Typische Beispiele für Organisationsziele sind die Erhöhung der Kundenzufriedenheit oder größere Innovationskraft. Kritische Erfolgsfaktoren („Critical Success Factors“) konkretisieren die (langfristigen) Organisationsziele z. B. durch kürzere Fristigkeit, durch Bezug zu aktuellen Lösungen und/oder durch Quantifizierung. So lässt sich beispielsweise im eCommerce das Organisationsziel „Kundenzufriedenheit“ durch die Attraktivität der elektronischen Verkaufsplattform für Kunden konkretisieren. Das Organisationsziel „größere Innovationskraft“ könnte durch „Investitionen in Forschung und Entwicklung“ und/oder durch „Fähigkeiten der Mitarbeitenden“ konkretisiert werden.

BEN-Komponenten

109

Eine (strategische) Führungsgröße („Key Performance Indicator“) operationalisiert einen Erfolgsfaktor dadurch, dass die Zielerreichung konkret messbar wird. Für den kritischen Erfolgsfaktor „Attraktivität der elektronischen Verkaufsplattform für Kunden“ könnten konkret die Fluktuationsrate von Kunden, ein Zufriedenheitsindex für Kunden, Suchgeschwindigkeit (nach Produkten in der Plattform), Relevanz der Suchergebnisse sowie Korrektheit von Verfügbarkeitsinformationen (für Produkte) zur Messung benutzt werden. Für den Erfolgsfaktor „Fähigkeiten der Mitarbeitenden“ könnte man beispielsweise die Weiterbildungstage in einem bestimmten Zeitraum heranziehen. Organisationsziele, kritische Erfolgsfaktoren und (strategische) Führungsgrößen sind keine Erfindungen des BE, sondern wurden im Rahmen des sog. „Balanced Scorecard“-Ansatzes (Kaplan u. Norton 1996) als zentrale Elemente des Zielsystems vorgeschlagen. Das Balanced Scorecard-Konzept geht weit über eine Grundkonzeption hinaus, indem z.B. sowohl konkrete Analyse- und Gestaltungstechniken vorgeschlagen werden wie auch entsprechende Prinzipien definiert werden. So wird z.B. gefordert, dass das Zielsystem auch nichtfinanzielle und zukunfts-/potenzialorientierte Ziele enthalten soll (deshalb „balanced“). Während finanzielle Ziele und insbesondere Prozessziele gut operationalisierbar und damit auch messbar sind, ist dies für Kundenziele und insbesondere Potenzialziele allerdings oft schwierig. Beim Aufbau einer traditionellen Balanced Scorecard werden nach Kaplan und Norton grundsätzlich vier Perspektiven verwendet, die Finanz-, Kunden-, interne Prozess- und die Potenzialperspektive. Die Stärke der Balanced Scorecard liegt jedoch darin, dass ergänzend oder stattdessen auch Faktoren wie z.B. Umweltfaktoren oder branchenspezifische Faktoren als Perspektiven berücksichtigt werden können – die Anzahl der Perspektiven ist frei wählbar. Zu jeder dieser Perspektiven sollten ein bis zwei Ziele sowie korrespondierende Maßnahmen und die dazugehörigen Kennzahlen definiert werden. Wie in (Stutz 2009) zusammengefasst, umfasst die finanzwirtschaftliche Perspektive klassische Kennzahlen, welche letztendlich den wirtschaftlichen Erfolg der Strategieumsetzung ausdrücken. Im Mittelpunkt stehen Aspekte der Rentabilität und Liquidität. Indirekt wird dadurch zum Ausdruck gebracht, ob die Unternehmensstrategie und die daraus abgeleiteten Maßnahmen erfolgreich waren oder nicht. Die Kundenperspektive beinhaltet jene Ziele und Messgrößen, welche die Marktpositionierung betreffen. Entsprechend können z.B. Kennzahlen für die Zufriedenheit der Kunden oder für Marktanteile festgelegt werden. Innerhalb der internen Prozessperspektive findet eine Bewertung der internen Abläufe des Unternehmens unter strategischen Gesichtspunkten statt. Dazu werden die kritischen Prozesse betrachtet, welche für die Sicherstellung der Kundenanforderungen und zur Erreichung der finanziellen Ziele beitragen. Ziel ist die Identifikation von Optimierungspotentialen bei den bestehenden Abläufen oder die Entwicklung neuer Prozesse. Die Potenzialperspektive definiert Kennzahlen zum Erreichen der langfristigen Ziele der Organisation. Aufgrund dieser langfristigen Wirkung hat die Perspektive einen besonderen Einfluss auf die Entwicklung und das Wachstum des Unternehmens. Die Potentialperspektive trägt

110


mitunter dazu bei, dass eine leistungsstarke Infrastruktur geschaffen wird, welche kontinuierliches Wachsen und Lernen unterstützt. Für die Zieldefinition eines Unternehmens oder einer Geschäftseinheit sind folgende Prozessschritte notwendig: •

•

• •

Basierend auf der Vision und der definierten Strategie müssen für die verschiedenen Perspektiven gesamthafte (Unternehmens-)Ziele definiert werden. Auf dieser Basis sind Erfolgsfaktoren zu spezifizieren. Die Leistungen bzw. Services der einzelnen Organisationseinheiten müssen in Verbindung mit diesen Erfolgsfaktoren gebracht werden und anhand von Kennzahlen bzw. (strategischen) Führungsgrößen operationalisiert werden. Eine Kennzahl bzw. (strategischen) Führungsgröße ist dann operationalisiert, wenn sie weitgehend willkürfrei messbar ist. Für die Akzeptanz dieser Kennzahlen bzw. Führungsgrößen spielt die Kommunikation der Vision und der Strategie des Unternehmens eine große Rolle. Die definierten Kennzahlen bzw. Führungsgrößen für die verschiedenen Perspektiven müssen ins reguläre Controlling eingearbeitet werden. Die Kennzahlen bzw. Führungsgrößen müssen regelmäßig auf Relevanz für Erfolg überprüft werden und, falls notwendig, auch überarbeitet werden.

Das Konzept der Balanced Scorecard wird zur Umsetzung und zur Kommunikation der Unternehmensstrategie eingesetzt; Im Idealfall bildet es auch die Grundlage für das Controlling der Strategieumsetzung. Dafür muss das Zielsystem jedoch mit strategischen Projekten und konkreten Projektzielen verknüpft werden. Hierzu wurde z.B. das Konzept der Balanced Scorecard zur Project Scorecard weiterentwickelt (Selders 2009). Tab. 7.

Zielzerlegung im Beispiel Smart Travel

Unternehmensziele

Hierarchische Zerlegung der Unternehmensziele

Umsatzsteigerung

Erhöhung der Kundenzahlen

Erhöhung der Kundenzufriedenheit

Steigerung der Mitarbeiterkompetenz

Erhöhung der Motivation der Mitarbeiter Erhöhung der Produkt-/Servicequalität

Gewinnsteigerung

Reduktion der internen Kosten

Größere Innovationskraft

Einstellung fachkompetenter Mitarbeiter

BEN-Komponenten

111

Die Zieldefinition in BEN passt im Grundsatz gut zum Konzept der Balanced Scorecard. Die Unternehmensziele, Erfolgsfaktoren, Kennzahlen/Führungsgrößen und Zielwerte werden top-down verfeinert und damit sukzessiv operationalisiert. Zuerst werden die Unternehmensziele festgelegt, die ein ausgewogenes Portfolio an strategischen Zielen darstellen (siehe hierzu Tab. 7). So stellen z.B. Umsatzsteigerung, Erhöhung der Kundenzufriedenheit, Gewinnsteigerung oder größere Innovationskraft typische Unternehmensziele dar. Diese können dann weiter verfeinert werden, bis sie operationalisierbar sind. Z.B. kann die Erhöhung der Kundenzufriedenheit weiter zerlegt werden in Steigerung der Mitarbeiterkompetenz und weiter in höhere Motivation der Mitarbeiter und Erhöhung der Qualität. Die Unternehmensziele können dann weiter in eine Ziellandkarte durch positive und negative Zusammenhänge eingetragen werden (siehe Abb. 56). So kann z.B. eine Erhöhung der Qualität eine positive Auswirkung auf die Kundenzufriedenheit, jedoch eine negative Auswirkung auf die Steigerung der Gewinne haben. Weiter kann eine Erhöhung der Kundenzufriedenheit eine Erhöhung der Kundenzahlen mit sich ziehen und somit auch eine Umsatzsteigerung bewirken.

Abb. 56. Ziellandkarte im Beispiel Smart Travel

Die definierten Ziele werden dann anhand von Erfolgsfaktoren konkretisiert und durch Kennzahlen/Führungsgrößen operationalisiert. Bei Bedarf können auch konkrete Zielwerte definiert werden. So entsteht ein konkretes, vieldimensionales Zielsystem, welches mit strategischen Maßnahmen verknüpft werden kann.

112

BEN-Komponenten der Organisationsebene

4.3 BEN-Komponenten der Organisationsebene Auf der Strategieebene werden „Was“-Fragen beantwortet: Was sind die Leistungen der betrachteten Geschäftseinheit und was sind die Ziele, die bei der Leistungserstellung verfolgt werden sollen? Die Organisationsebene dient dagegen zur Festlegung des „Wie“, d.h. zur Umsetzung dieser strategischen Festlegungen in ablauf- und aufbauorganisatorische Strukturen. Auch auf Organisationsebene wird „top-down“ und „outside-in“ vorgegangen. Top-down heißt, dass zunächst grobe Strukturierungen entwickelt und später verfeinert werden; Outside-in heißt, dass die Prozessgestaltung und die Aufbauorganisation ausgehend von Leistungen und Zielen – und nicht etwa ausgehend von der Ablauflogik – entwickelt werden. Die Analyse- und Gestaltungsaufgaben auf Organisationsebene beschäftigen sich mit Geschäftsprozessen, Verantwortlichkeiten und Organisationsstrukturen sowie Informationen und Informationsflüssen. Die Reihenfolge, in der diese BENFragmente eingesetzt werden, richtet sich nach der Problemstellung und dem Lösungsansatz. Während Jahrzehnten stand die Festlegung der Aufbauorganisation im Vordergrund und die Organisationsstrukturen determinierten die Möglichkeiten und Grenzen der Prozessabläufe und des Informationswesens. In den 1990er Jahren folgte mit der Prozessorientierung ein Paradigmenwechsel, der die Prozessgestaltung in den Vordergrund rückte, dem die Aufbauorganisation zu folgen hat. Unter bestimmten Umständen kann es alternativ sogar sinnvoll sein, die Informationsversorgung als wichtigste Gestaltungsaufgabe anzusehen (z.B. für bestimmte „Crisis Management“- oder Informationslogistikorganisationen) und auf dieser Grundlage Prozessgestaltung und Aufbauorganisation abzuleiten.

4.3.1 Prozessgestaltung Zur Prozessgestaltung wird zunächst das Zusammenspiel der Prozesse beschrieben, die der Erstellung der auf Strategieebene spezifizierten Produkte/(Markt-)Leistungen unter Erreichung der auf Strategieebene spezifizierten Ziele dienen. Für jeden derart festgelegten Geschäftsprozess werden dann „im Detail“ die zu erbringenden Prozessleistungen spezifiziert, die zur Steuerung herangezogenen Kennzahlen definiert und die zur Leistungserbringung notwendigen Aktivitäten einschließlich deren Abfolge festgelegt. Die dominanten Gestaltungsziele der Prozessgestaltung sind Effektivität und Effizienz. Die Geschäftsprozesse sollen • •

die gewünschten Leistungen erzeugen (Effektivität, „das Richtige tun“) und dabei die gewünschten Zielvorgaben beachten (Effizienz, „die Dinge richtig tun“).

BEN-Komponenten

113

Zunächst ist es dabei unerheblich, welche Aktivitäten in welcher Form durch Softwaresysteme automatisiert bzw. unterstützt werden. Als Geschäftsprozess wird eine logisch zusammenhängende Folge von Aktivitäten verstanden, die in einer bestimmten Ablauflogik durchgeführt werden und eine Prozessleistung erzeugen, die einen Kundennutzen erzeugt und auf einem (internen oder externen) Markt angeboten werden kann (Marktleistung bzw. Produkt). Ausgelöst durch ein bestimmtes Ereignis werden bestimmte Einsatzfaktoren (Input) unter Beachtung bestimmter Regeln und durch Einsatz bestimmter Ressourcen zu bestimmten Arbeitsergebnissen (Output) transformiert (nach (Davenport u. Short 1990)). Zur Steuerung der Leistungserstellung werden dabei bestimmte (Prozess-)Führungsgrößen verwendet. Business Process (Re-)Design entwickelte sich in der ersten Hälfte der 1990erJahre als Disziplin zur systematischen, methoden- und modellbasierten (Um-)Gestaltung von Geschäftsprozessen. Neben Modellen zur Beschreibung arbeitsteiliger, verschiedene Funktionseinheiten berührender Abläufe werden auch eine Vielzahl von Techniken zur Identifikation „der richtigen“ Prozesse, geeigneter (Prozess-)Führungsgrößen und effizienter Abläufe vorgeschlagen (vgl. z. B. (Rummler u. Brache Alan 1995; Österle 1995; Davenport u. Short 1990)). Traditionell steht häufig die Beschreibung der Aktivitätslogik („Ablaufplanung“) im Vordergrund der Prozessmodellierung. Allerdings geht es im Business Engineering nicht primär darum, die zur Leistungserstellung notwendigen Aktivitäten in eine sinnvolle Reihenfolge zu bringen bzw. deren Reihenfolge zu erkennen oder zu optimieren. Die Aktivitätsfolgen sollten vielmehr das Ergebnis eines Gestaltungsprozesses sein, bei dem zunächst sicherzustellen ist, dass die spezifizierten Leistungen erbracht werden (Teilziel Effektivität) und dass dabei die spezifizierten Steuerungsziele beachtet werden (Teilziel Effizienz). Ähnlich dem Geschäftsnetzwerk auf Strategieebene dient als Ausgangspunkt der Prozessmodellierung die gesamthafte Beschreibung des Zusammenspiels der Geschäftsprozesse („Prozesslandkarte“). Als Grundlage für die Ablaufplanung werden die Prozesse auf Grundlage der Festlegungen auf Strategieebene verfeinert. Im Rahmen der „Prozessführung“ werden aus (strategischen) Führungsgrößen Prozess-Führungsgrößen konkretisiert und durch die „Leistungsanalyse“ werden die Prozessleistungen hinsichtlich ihrer Leistungsbestandteile sowie (Prozess-)Kunden und Distributions- bzw. Zugangskanäle analysiert. Auf dieser Grundlage erfolgt dann erst die eigentliche Ablaufplanung. Im Gegensatz zur Strategie-Festlegung, die aufgrund ihrer höheren Stabilität nur in größeren Abständen revidiert und angepasst werden wird, werden die Analyse- und Gestaltungsschritte auf Organisationsebene oftmals wiederholt, um Ablauf- und Aufbaustrukturen permanent zu verbessern und weiterzuentwickeln („Prozessentwicklung“ (Österle 1995)). Im Folgenden werden die verschiedenen Aktivitäten erläutert, die zur Prozessgestaltung notwendig sind. Diese Aktivitäten umfassen Prozessarchitekturplanung, Prozessführung, Leistungsanalyse und Ablaufplanung. Die Aktivitäten werden zum Teil am Beispiel Smart Travel illustriert.

114


4.3.1.1 Prozessarchitekturplanung In einer Geschäftseinheit wirken verschiedene Typen von Geschäftsprozessen zusammen: •

• •

Leistungsprozesse (oder Geschäftsprozesse im engeren Sinne) erzeugen Leistungen „nach außen“, d. h. für einen (normalerweise externen) (Prozess-)Kunden. Die Leistungen von Leistungsprozessen sind deshalb im Normalfall Marktleistungen. Unterstützungsprozesse unterstützen die Leistungsprozesse durch Erzeugung von Vorleistungen, d.h. bedienen normalerweise interne Kunden. Führungsprozesse koordinieren die Leistungserstellung, d. h. messen die Zielerfüllung von Leistungs- und Unterstützungsprozessen, intervenieren bei Zielabweichungen (operative Führung) und entwickeln das gesamte Leistungssystem weiter (Prozessentwicklung).

Geschäftsprozesse im weiteren Sinne können Leistungsprozesse, Unterstützungsprozesse oder Führungsprozesse sein. Zur Abbildung des Zusammenwirkens der Geschäftsprozesse „im Großen“ dienen Prozesslandkarten auf unterschiedlich hohem Aggregationsniveau. Besonders zu beachten ist bereits in dieser frühen Phase der Prozessbeschreibung die Tatsache, dass Geschäftsprozesse im Normalfall unterschiedliche Bereiche der Unternehmung berühren. So umfasst die Auftragsabwicklung z. B. Aktivitäten im Bereich der Produktion ebenso wie solche im Bereich Finanzen. Während Unterstützungsprozesse im Normalfall funktional strukturiert werden (z. B. Personaladministration oder Finanzadministration) und während Führungsprozesse im Normalfall nach Managementebenen strukturiert werden (z. B. operative Führung, Prozessentwicklung oder strategische Führung), liegt der Abgrenzung der Leistungsprozesse eine Analyse von Marktsegmenten, des Produkt/ Servicemodells und auch der Vertriebs-/Zugangskanäle zugrunde. Abb. 57 illustriert eine einfache Analyse des Zusammenhangs von Marktsegmenten und Produkt-/Servicetypen für das Beispiel Smart Travel, die zur Unterscheidung von fünf Leistungsprozessen führt. Dabei wird untersucht, ob ein Leistungsprozess für einen bestimmte Produkt-/Servicetyp über mehrere Marktsegmente hinweg oder eher für spezielle Marktsegmente definiert werden soll. Dominate Spezifika bestimmter Marktsegmente führen in solch einer Analyse zu eher marktbezogenen Strukturierungen der Leistungsprozesse wobei dominante Spezifika der Vertriebs-/Zugangskanäle dagegen zu eher kanalbezogenen Strukturierungen der Leistungsprozesse führen. Im Falle des Servicetyps Bildungsreise (siehe Abb. 57) zeigt sich, dass der Leistungsprozess 5 über mehrere Marktsegmente hinweg definiert wird, nämlich über die Marktsegmente Familien, Singles und Paare. Hingegen werden beim Servicetyp Erholungsreise zwei Leistungsprozesse – Leistungsprozesse 1 und 2 – für die einzelnen Marktsegmente Familien, bzw. Singles und Paare definiert. Im Falle der Marktsegmente Singles und Paare zeigt sich jedoch, dass die Leistungsprozesse 3 und 4 sowohl für den Servicetyp

BEN-Komponenten

115

Partyreise als auch für den Servicetyp Abenteuerreise gleich definiert werden, und somit beide Servicetypen umfassen.

Abb. 57. Identifikation von Leistungsprozessen im Beispiel Smart Travel

Prozesslandkarten können verschiedene Aggregationsgrade haben. Grobe Geschäftsprozesse können solange in feinere Prozesse zerlegt werden, wie es sich beim Zerlegungsergebnis noch um Geschäftsprozesse gemäß der obigen Definition handelt. Wenn das Ergebnis der Zerlegung kein „kompletter“ Prozess mehr wäre, sondern eine Prozesskomponente bzw. ein Aggregat aus Aktivitäten, ist die Grenze von der Prozessarchitekturplanung zur Prozesszerlegung im Rahmen der Ablaufplanung überschritten. Diese Grenze ist auch überschritten, wenn die Prozessleistung nicht mehr marktfähig wäre oder wenn ihr kein Kundennutzen zugeordnet werden kann.

4.3.1.2

Prozessführung

Im Kapitel 0 wurde beschrieben, wie das Zielsystem durch Organisationsziele, kritische Erfolgsfaktoren und (strategische) Führungsgrößen spezifiziert werden kann. Prozess-Führungsgrößen stellen den direkten Bezug zwischen (strategischen) Führungsgrößen und konkreten Prozessleistungen bzw. den diese Leistungen direkt oder indirekt erzeugenden Aktivitäten her. Eine Größe eignet sich dann als Prozess-Führungsgröße, wenn ihre Ausprägung den Zustand einer Aktivität gut charakterisiert und sie damit zur Steuerung der betreffenden Aktivität oder zur Steuerung des Übergangs zwischen zwei Aktivitäten herangezogen werden kann. Natürlich muss es möglich sein, die betreffende Größe direkt, exakt und zeitnah zu messen. Klassische Beispiele für Prozess-Führungsgrößen sind Läger (Übergang zwischen zwei Aktivitäten, sehr direkt mess- und steuerbar) und Produktionsintensitä-

116


ten (direkte Steuerung einer Aktivität, sehr direkt mess- und steuerbar). Im Smart Travel Beispiel können die (strategischen) Führungsgrößen „Erhöhung der Kundenzahl“ und „Erhöhung der Kundenzufriedenheit“, die den Erfolgsfaktor „Plattformattraktivität für den Kunden“ umsetzen, den Prozess-Führungsgrößen „Geschwindigkeit der Suche“ und „Relevanz der Suche“ zugeordnet werden (siehe Abb. 58). Wenn diese beiden Prozess-Führungsgrößen im zu definierenden Leistungsprozess unmittelbar gemessen werden können, sind sie hervorragende Kandidaten für dessen Steuerung, und finden sich somit im Steuerungsmodell wieder.

Abb. 58. Prozessführungsgrößen im Beispiel Smart Travel

4.3.1.3 Leistungsanalyse Löst man die Prozesslandkarte in einzelne Bestandteile auf, die jeweils auf einen Geschäftsprozess fokussieren und seine allfälligen Vernetzungen mit anderen Prozessen beschreiben, entstehen zunächst sog. Prozesskontextdiagramme. Diese dienen als Grundlage der späteren Verfeinerung der betreffenden Prozessbeschreibungen; Durch sie werden die auf Strategieebene und in der Prozesslandkarte zunächst nur benannten Leistungen erstmals näher spezifiziert. Zusätzliche Prozess-Informationen wie z. B. adressierte Kundensegmente, geeignete Distributions- bzw. Zugangskanäle, Qualitätseigenschaften, technische Produktspezifikationen oder finanzielle Kennzahlen können in einem sog. Leistungsverzeichnis zusammengetragen werden. Die durch einen Prozess zu erzeugenden Leistungen können einerseits bezogen auf Leistungsbestandteile und andererseits bezogen auf Leistungsmerkmale spezifiziert werden. Dabei sollte auch untersucht werden, welche Bedeutung die Leistungsbestandteile bzw. -merkmale für den jeweiligen Prozesskunden haben und wie ihre Qualität eingeschätzt wird – möglicherweise auch im Vergleich zu den Leistungen des wichtigsten Mitbewerbers. Abb. 59 zeigt in Anlehnung an (IMG

BEN-Komponenten

117

1997b) ein solches Qualitätsprofil für den Leistungsprozess Erholungsreise für Familien am Beispiel Smart Travel.

Abb. 59. Qualitätsprofil eines Prozess-Output im Beispiel Smart Travel

In Abb. 59 wird zwischen Leistungsbestandteilen und Leistungsmerkmalen unterschieden. Für den Kunden ist es wichtig zu wissen, welche Bestandteile die gekaufte Leistung beinhalten und auch welche Qualitätsmerkmale zu erwarten sind. Abb. 59 zeigt somit deutlich welche Erwartungen der Kunde hat (Soll-Zustand, gekennzeichnet durch eine gestrichelte Linie) und welche Leistungsqualität momentan angeboten wird (Ist-Zustand, gekennzeichnet durch eine durchgezogene Linie). Die Pfeile zeigen das mögliche Qualitätsverbesserungspotential für die angebotene Leistung auf. Zusätzlich kann ein Vergleich mit dem Mitbewerber gezogen werden (gepunktete Linien). Klar ersichtlich wird aus dem Qualitätsprofil, auf welche Qualitätsmerkmale eines Leistungsprozesses besonders Wert gelegt werden muss. Mit dem Qualitätsprofil werden Effektivitätsaspekte des Leistungsprozesses untersucht, bevor über dessen Umsetzung nachgedacht wird.

118


4.3.1.4 Ablaufplanung Nachdem sich die Prozessführung auf die Effizienz und sich die Leistungsanalyse auf die Effektivität eines Prozess konzentriert hat, wird auf dieser Grundlage im Rahmen der Ablaufplanung die Ablauflogik festgelegt. Die Ablauflogik beschreibt, wie Teilprozesse (und letztlich) Aktivitäten logisch miteinander verbunden werden müssen, damit die spezifizierten Prozessleistungen unter Beachtung der spezifizierten Prozess-Führungsgrößen erzeugt werden. Teilprozesse und (bei feinerer Betrachtung) Aktivitäten können durch ReihenfolgeAbhängigkeiten (Aktivität B startet, nachdem Aktivität A abgeschlossen ist) oder durch Parallelität/Nebenläufigkeit (Aktivitäten A und B laufen parallel ab) verbunden sein. Solange Prozesse noch gesamthaft betrachtet werden, ist es nur selten nötig, zwischen Teilprozessen bzw. Aktivitäten komplexe logische Verbindungen wie z. B. „und“, „oder“ oder „exklusives oder“ abzubilden. Durch die sog. Prozesszerlegung werden Prozesse sukzessiv in immer feinere Teilprozesse zerlegt, bis die Ebene elementarer Aktivitäten erreicht ist. Je detaillierter die Prozessbeschreibung dabei wird, umso eher wird es nötig werden, neben Aktivitätsbeschreibungen auch komplexe logische Verbindungen abzubilden. Die bei der Ablaufplanung identifizierten Teilprozesse bzw. Aktivitäten können Verantwortungsbereichen zugeordnet werden, um damit die Verbindung zur Aufbauorganisation herzustellen. Da die Aufbauorganisationsdefinition in einer anderen BEN-Komponente definiert wird, handelt es sich dabei entweder um eine Referenz (wenn Aufbauorganisationsgestaltung vor Prozessgestaltung stattfindet) oder um eine Referenz auf Strukturkandidaten (die bei der nachfolgenden Aufbauorganisationsgestaltung überarbeitet werden, so dass dann die Referenzen aktualisiert werden müssen). Bei der Ablaufplanung wird versucht, Teilprozesse bzw. Aktivitäten möglichst häufig wieder zu verwenden und nur dann neue Spezifikationen anzulegen, wenn das entsprechende Element nicht bereits in einem anderen Zusammenhang verwendet wurde. Modellierungswerkzeuge unterstützen die Wiederverwendung durch Datenbanken, die alle bisher definierten Teilprozesse bzw. Aktivitäten enthalten. In Abb. 60 wird am Beispiel von Smart Travel der Buchungsprozess für eine Familienreise auf grober Ebene beschrieben. Die verwendete Notation ist die der Ereignisgesteuerten Prozessketten (EPK) (Scheer u. Thomas 2005). Rechtecke mit abgerundeten Kanten bezeichnen Aufgaben bzw. Aktivitäten. Sechsecke bezeichnen Ereignisse, durch welche eine Aktivität ausgelöst werden kann oder die von einer Aktivität ausgelöst werden. Pfeile geben den Kontrollfluss an, welcher den zeitlich sachlogischen Ablauf von Aktivitäten und Ereignissen wiedergibt. Die Aktivitäten sind durch einfache Vorgänger-Nachfolger-Reihenfolgebeziehungen verknüpft. Diese Beziehungen können an Bedingungen geknüpft sein. Zum Beispiel muss nach dem Anlegen eines Reiseantrages sowohl der Flug, das Hotel wie auch der Transfer zum Hotel reserviert werden. Solche Bedingungen werden durch Konnektoren ausgedrückt. Die Konnektoren beschreiben unterschiedliche

BEN-Komponenten

119

Formen der Prozessverzweigungen. Neben den Verzweigungen muss es auch möglich sein, Ablaufketten zusammenzuführen. Dabei ist dann festzulegen, ob der Folgeschritt begonnen werden kann, wenn alle vorangehenden Schritte abgearbeitet sind (logisches „und“) – oder ob er schon begonnen werden kann, wenn mindestens einer der vorangehenden Schritte abgearbeitet ist (logisches „oder“).

Abb. 60. Ablaufdiagramm eines (Teil-)Prozesses im Beispiel Smart Travel

Modellierungswerkzeuge können die konsistente Verfeinerung komplexer Prozessmodelle effektiv durch Navigationsfunktionen in Modellhierarchien, Kopieren

120


von Modellelementen und/oder Referenzen in verfeinerte Diagramme usw. unterstützen. Um die Verbindung von Ablaufdiagrammen mit der Prozessführung herzustellen, müssen die Prozess-Führungsgrößen entsprechenden Aktivitäten zugeordnet werden. Um die Verbindung von Ablaufdiagrammen mit der Leistungsanalyse herzustellen, müssen die Prozessleistungen entsprechenden Aktivitäten zugeordnet werden. Darüber hinaus können Aktivitäten auch Standorten und/oder Organisationseinheiten zugeordnet werden, um Verantwortlichkeiten und/oder die räumliche Strukturierung des Geschäftsprozesses festzulegen. Für spätere Analysen sollte auch das Mengengerüst spezifiziert werden, d. h. es sollte festgelegt werden, wie oft eine bestimmte Aktivität pro Zeiteinheit ausgeführt wird und welche Einzel- und Gemeinkosten sowie Bearbeitungs-, Liege- und Transportzeiten damit verbunden sind. Fortgeschrittene Modellierungswerkzeuge erlauben auch, die Anzahl paralleler Ausführungen zu definieren sowie minimale und maximale Losgrößen zu definieren. Mit diesen und weiteren Angaben (z. B. zu Verteilungen und Entwicklungen im Zeitverlauf) können dann auch komplexe Abläufe simuliert werden. Die Ergebnisse solcher Simulationen sind neben kritischen Pfaden auch Prozesskosten und Durchlaufzeiten, so dass durch gezielte Parameterveränderung Durchlaufzeiten verkürzt, Kapazitätsüberschüsse minimiert und Kosten gesenkt werden können. Allerdings müssen Ablaufdiagramme oft sehr stark verfeinert werden und es müssen sehr genaue Angaben zur logischen Verknüpfung von Aktivitäten sowie zur relativen Häufigkeit verschiedener Zweige gemacht werden, damit eine sinnvolle Simulation (und Optimierung) ermöglicht wird.

4.3.2 Aufbauorganisationsgestaltung Die Gestaltung der Aufbauorganisation verfolgt das Ziel, die zur Durchführung der Aufgaben eines Prozesstyps erforderlichen Beteiligung menschlicher Akteure in differenzierter und zugleich abstrakter Art und Weise zu beschreiben. Unter einer Aufgabe versteht man eine Zielvorschrift für menschliches Handeln (Wöhe 2002). Ausgehend von der Gesamtaufgabe der Organisation, befasst sich die Aufbauorganisation mit der Aufspaltung dieser Gesamtaufgabe in viele Teil- oder Einzelaufgaben, damit durch eine anschließende Kombination dieser Teilaufgaben zu Stellen eine sinnvolle arbeitsteilige Gliederung und Ordnung der betrieblichen Prozesse entsteht. Eine Stelle wiederum bezeichnet eine Zusammenfassung von Aufgaben, die eine derartige Kapazitätsnachfrage bilden, dass sie einer Person übertragen werden können und diese dauerhaft auslasten (Rosemann u. zur Mühlen 1997). Die Stellen, zusammen mit ihren Verknüpfungen, bilden die organisatorische Struktur des Unternehmens. Die Stelle ist damit das Grundelement der Aufbauorganisation. Sie stellt die Zusammenfassung von Teilaufgaben zum Arbeitsbereich und Aufgabenbereich einer Person dar (Wöhe 2002). Die Zuordnung

BEN-Komponenten

121

von Teilaufgaben zu Stellen ist nicht trivial: Versucht man eine Stelle leicht beherrschbar zu machen, indem man ihr gleichartige Aufgaben zuordnet, hat es den Nachteil der Monotonie. Dies bedeutet, dass die Motivation und der Leistungswille des Stelleninhabers gehemmt werden kann. Laut Wöhe (2002) sind grundsätzlich zwei Möglichkeiten zur Elementaraufgabenkombination zur Bildung einer Stelle gegeben: •

•

Die Stellenaufgabe wird auf eine abstrakte noch zu suchende Person abgestellt. In diesem Fall ist man stark von den am Arbeitsmarkt anzutreffenden Kenntniskombinationen oder Fähigkeiten abhängig. Die Ausrichtung der Stelle kann nach der Kenntniskombination und Fähigkeiten eines bereits bekannten zukünftigen Stelleninhabers ausgerichtet werden. Dies ist jedoch häufig der Fall für Stellen, die in der Hierarchie des Unternehmens hoch angesiedelt sind. In diesem Fall läuft man jedoch Gefahr, dass beim Ausscheiden des Stelleninhabers oft eine Umstrukturierung einer Anzahl benachbarter Stellen notwendig werden kann.

Die Zuordnung der Teilaufgaben wird in sogenannte Stellenbeschreibungen festgehalten. Laut Schwarz (1995) charakterisiert sich die Stellenbeschreibung folgendermaßen: „Stellenbeschreibungen sind ein praktisches Hilfsmittel der zweckmäßigen Eingliederung von Aufgabenträgern in organisatorische Beziehungszusammenhänge. [...] Der Hauptzweck der Stellenbeschreibungen besteht in der Sicherung einer rationalen, reibungslosen und kontinuierlichen Aufgabenerfüllung. Sie stellen die höchstentwickelte Form der schriftlichen Festlegung organisatorischer Regelungen in der Unternehmung dar. Insbesondere erstrecken sich Stellenbeschreibungen auf folgende Komplexe: • • • •

Sachliche Festlegung der Aufgaben, Nähere Erläuterung der organisatorischen Eingliederung der Stelle und Angabe organisatorischer Beziehungen (Verkehrswege), Anleitung zur zweckmäßigen Aufgabenlösung und Darstellung personeller Anforderungen auf Grund der Aufgabenübernahme durch den Stelleninhaber.“

Abb. 61 zeigt exemplarisch, wie eine Stellenbeschreibung im Beispiel Smart Travel für eine/einen Kundenberater(in) für Familienurlaub aussehen kann.

122


Abb. 61. Stellenbeschreibung im Beispiel Smart Travel

Aus der Stellenaufgabe leitet sich die Kompetenz und die Verantwortung des Stelleninhabers ab (Wöhe 2002). Unter Kompetenz sind die Rechte und Befugnisse zu verstehen, die einem Stelleninhaber ausdrücklich zugeteilt wurden. Als Gegenstück dazu entstehen mit der Verantwortung Pflichten für den Stelleninhaber Aufgaben zielentsprechend zu erfüllen und Rechenschaft dafür abzulegen. Die in der Ablaufplanung festgelegten Verantwortungsbereiche dienen im Normalfall als Grundlage, um die Aufbauorganisation zu definieren. Durch die Kombination „passender“ Detail-Verantwortlichkeiten sind organisatorische Rollen zu definieren, die als atomare organisatorische Konstrukte und Bindeglieder zwischen der Aufbauorganisation- und der Prozessgestaltung fungieren. Eine Rolle ist eine Abstraktion, die mit der Zuständigkeit für eine oder mehrere Aufgaben der Prozessorganisation verbunden ist. Rollen repräsentieren die für die Ausführung der Aufgaben notwendige minimale Qualifikation und beschreiben die Kompetenzen, welche einem Rollenträger übertragen werden (Rosemann u. zur Mühlen 1997). Mehrere Rollen können einem Stellentyp zugeordnet werden. Unter einem Stellentyp versteht man die Zusammenfassung von Stellen mit gleichartigen Kompetenzen.

BEN-Komponenten

123

Um Verantwortungsbereiche auf Stellen-Vollzeitäquivalente umzurechnen sind Schätzungen zum Mengengerüst notwendig, d. h. es muss zum Beispiel festgelegt werden, wie häufig die verschiedenen Geschäftsprozesse durchlaufen werden und an welchen Entscheidungspunkten wie viel Prozent der Geschäftsvorfälle in welchen Teil-Ast verzweigen. Aus diesen Angaben kann der Kapazitätsbedarf der Verantwortungsbereiche (bzw. -unterbereiche) hochgerechnet und auf StellenVollzeitäquivalente umgerechnet werden. Auf Grundlage der geplanten Beschäftigungsgrade können dann Stellen gebildet werden. Unter Berücksichtigung der Leitungsspanne (5-10 Mitarbeitende pro Führungskraft) werden die Stellen-Mengen in Teams, Abteilungen etc. geteilt oder zu solchen Strukturen zusammengefasst. Dann werden Teamleiter/innen, Abteilungsleiter/innen usw. sowie als notwendig erachtete Stäbe definiert. Diese Rangbildung der Stellen, die daraus resultiert, dass die Aufgaben in Ausführungsaufgaben und Leitungsaufgaben aufgeteilt werden, ist das wichtigste formale Merkmal der Aufgabenverteilung. Die wichtigste Frage bei der Aufgabenverteilung nach dem Merkmal Rang ist, ob Leitungsaufgaben zu vereinigen oder möglichst zu trennen sind, d.h., ob man ein zentralisiertes oder dezentralisiertes Leitungssystem wählen soll. Bei der dezentralisierten Aufgabenverteilung werden Aufgaben auf mehrere Stellen übertragen. Dies bedeutet, dass es eine höhere Zahl von Fachkräften notwendig ist, die den entsprechenden Aufgaben gerecht werden können, gleichzeitig erhöht es aber auch das Verantwortungsgefühl und die Arbeitsfreude der Mitarbeiter. Im Gegensatz dazu steht die zentralisierte Aufgabenverteilung, bei der die Verantwortung bei wenigen Mitarbeiter liegt, und die untergeordneten Stellen bloße Befehlsempfänger sind, die keine eigene Initiative entwickeln können. Diese Art der Aufgabenverteilung ist zwangsläufig dann gegeben, wenn nicht genügend Fachkräfte zur Verfügung stehen. In der Praxis werden oft beide Organisationsprinzipien zusammen angewendet. Jedes Leitungssystem stellt ein hierarchisches Gefüge dar, in dem die einzelnen Stellen unter dem Gesichtspunkt der Weisungsbefugnis miteinander verbunden sind. Es wird zwischen verschiedenen Grundformen unterschieden, nach denen solch eine Hierarchie aufgebaut ist (Wöhe 2002). Beim Liniensystem z. B. darf eine Instanz nur von einer übergeordneten Instanz Anweisungen erhalten. Dies ist die straffeste Form der organisatorischen Gliederung einer Organisation. Beim Funktionssystem (oft auch Mehrliniensystem) wird der Weg der Aufträge nicht durch die übergeordnete Instanz bestimmt, sondern von der Art der betreffenden Aufgabe. So kann es vorkommen, dass ein Mitarbeiter von verschiedenen Leitungsträgern Aufträge erhält. Bei der divisionalen Organisation (Spartenorganisation) richtet sich die Struktur nicht mehr nach der funktionalen Organisation, sondern nach dem Objektprinzip, indem auf Produkte, Produktgruppen, Betriebsprozesse oder räumliche Gegebenheiten ausgerichtete Sparten (Divisionen) gebildet werden. Die Matrixorganisation entsteht durch die Überlagerung von funktionsorientierten und objektorientierten Organisationsstrukturen. Diese Organisationsstruktur gleicht formal einer Matrix und wird in der Praxis durch bestimmte Produkte oder Projekte bestimmt. Der Vorteil dieser Organisationsform

124


besteht in der Möglichkeit, das vorhandene Spezialwissen für Innovationsprozesse ausnutzen zu können. Für die Modellierung der Aufbauorganisation wird oft eine Sprache mit geringem Formalisierungsgrad verwendet (Fischer 2008). In der Praxis wird die Aufbauorganisation üblicherweise anhand von Stellenbeschreibungen, Funktionsdiagrammen und Organigrammen dokumentiert. Bei Stellenbeschreibungen handelt es sich um formalisierte verbale Beschreibungen einer Stelle hinsichtlich ihrer Aufgaben, Kompetenzen und der zur Aufgabendurchführung notwendigen Qualifikation (siehe Abb. 61). Funktionsdiagramme enthalten eine übersichtliche Darstellung der Zuordnung von Aufgaben zu einer Stelle sowie die entsprechende Zuständigkeitsart für jede Aufgabe (z.B. „führt durch“, „wirkt mit“, „prüft“). Organigramme bilden die hierarchischen Anordnungsbeziehungen von Organisationseinheiten, die Zugehörigkeit von Stellentypen zu ihnen sowie die fachlichen und disziplinarischen Weisungsbefugnisse zwischen Stellentypen in graphischer Form ab.

Abb. 62. Organigramm im Beispiel Smart Travel

BEN-Komponenten

125

Abb. 62 zeigt eines Ausschnitt des Organigramms für das Beispiel Smart Travel. Die Notation richtet sich an der von Scheer in Architektur Integrierter Informationssysteme eingeführten Notation für Organigramme (siehe hierzu auch (Scheer 2001)). Die Ellipsen stellen Organisationseinheiten dar und die Rechtecke Stellen. Es handelt sich hier um eine divisionale Organisationsstruktur; Bei der Organisationseinheit Familienurlaub ist die oben zur Illustration beschriebene Stelle „Kundenberater für Familienurlaub“ zu sehen.

4.3.3 Informationsgestaltung Geschäftsprozesse erzeugen Informationen und verarbeiten Informationen. In vielen Wirtschaftsbereichen (z. B. Finanzdienstleistungen, Tourismus) lässt sich die jeweilige geschäftliche Tätigkeit sogar hauptsächlich als Informationsverarbeitung abbilden, da die Bearbeitung und der Fluss physischer Güter unbedeutend ist oder im Extremfall gänzlich fehlt. Es gibt wichtige Unterschiede zwischen Informationen und physischen Gütern, die eine spezielle Analyse, Abbildung und Gestaltung notwendig machen: Während jedes physische Gut nur einmal existiert, können Informationen in beliebig vielen Kopien existieren, deren Konsistenz sichergestellt werden muss. Sowohl Informationen wie auch Güter werden zwar in Geschäftsprozessen schrittweise „veredelt“; die Güter befinden sind jedoch jeweils nur in einem Bearbeitungsschritt bzw. Lager, während alle Zwischenstadien der veredelten Informationen gesammelt werden können und deshalb ihre Abhängigkeiten modelliert werden müssen. Abhängigkeiten zwischen Informationen können verschiedenster Natur sein. So kann z. B. der Saldo eines Kontos zu einem bestimmten Zeitpunkt als die Aggregation aller Bewegungen auf dem betreffenden Konto während eines bestimmten Zeitraums angesehen werden. Kostenstellenbudgets für einen bestimmten Zeitraum können als Zerlegung bestimmter Bereichsbudgets für den betreffenden Zeitraum angesehen werden. Aufträge verweisen auf (bestellte) Produkte und (bestellende) Kunden und damit implizit auf deren Eigenschaften wie z. B. Preise und Lieferkonditionen. Umsätze können als Ableitung aus den Preisen gelieferter Produkte zum Auftragszeitpunkt, den Zahlungsbedingungen kaufender Kunden zu diesem Zeitpunkt usw. angesehen werden. Als Konsequenz muss die „informatorische Welt“ anders analysiert, abgebildet und gestaltet werden als die Welt der Geschäftsprozesse bzw. Aktivitäten. Wie immer sollte dabei zwischen Gesamtmodellen („Informationslandkarte“) und Detailmodellen („Informationsobjektmodell“) unterschieden werden. Ein wichtiges Merkmal von Informationslandkarten ist, dass sie – im Gegensatz z.B. zur Prozessarchitektur – weniger bzw. nicht hierarchisch ist. Während verschieden umfassende Prozessarchitekturen bzw. -modelle durch hierarchische Zerlegung verknüpft und deshalb fokussiert sind, sind Informationslandkarten meist „flach“, d.

126


h. haben keine oder wenige Hierarchieebenen. Informationsobjektmodelle wiederum sind zwar fokussiert, sollten aber eine Vielzahl verschiedener (Auswertungs-)Perspektiven auf ein Informationsobjekt abbilden. Dies kann z.B. in Form einer mehrdimensionalen Modellierung erfolgen. Ab Mitte der 70er-Jahre wurde in der Folge der Vorstellung des relationalen Datenmodells (Codd 1970) sowie des 3-Ebenen-Modells für Datenbanken (Tsichritzis u. Klug 1978) eine Vielzahl von Techniken vorgeschlagen, die es erlauben, Informationsobjekte und deren Abhängigkeiten aus fachlicher Sicht zu beschreiben. Entsprechende Beschreibungen werden als semantische Datenmodelle oder konzeptionelle Datenmodelle bezeichnet. Sie ermöglichen informatorische Gesamtzusammenhänge so abzubilden, dass •

•

das Modell von Realisierungsaspekten frei ist und deshalb bei Änderungen der Realisierung nicht angepasst werden muss (physische Datenunabhängigkeit) und das Modell auch von speziellen Verwendungsaspekten frei ist und deshalb bei Änderungen der Verwendung nicht angepasst werden muss (logische Datenunabhängigkeit).

„Datenmodellierung“ erfolgt als Teil der Fachkonzept-Spezifikation von Softwaresystemen, d. h. beschränkt sich auf die mittels IT-Systemen repräsentierten und verwalteten Informationsobjekte (also „Daten“) und gehört deshalb auf die IT-Ebene. Auf Organisationsebene werden die zur Aufgabenerfüllung notwendigen Informationsobjekte und ihre Abhängigkeiten ohne Einschränkung darauf spezifiziert, ob sie mit IT-Systemen, auf Papier oder sogar nur in den Köpfen der Mitarbeitenden abgebildet werden. Um diese Aufgabe von der Datenmodellierung abzugrenzen, wird sie als Informationsgestaltung bezeichnet.

4.3.3.1 Abbildung der Informationslandkarte Eine intuitiv verständliche und deshalb gut kommunizierbare Abbildung der Informationslandkarte ist ein graphisches Diagramm, das Informationsobjekte als Knoten und Abhängigkeiten zwischen Informationsobjekten als gerichtete Kanten abbildet. Als Quasi-Standardtechnik für die Abbildung der Informationslandkarte gilt das 1976 von Chen erstmals vorgestellte Entity-Relationship-Modell (ER-Modell, (Chen 1976)). Ursprünglich als Datenbankmodell gedacht, führte die leichte Verständlichkeit und hohe Benutzernähe dieser Modellierungstechnik sehr bald zu weiter Verbreitung. Der Ansatz wurde seither kontinuierlich weiterentwickelt, um zusätzliche Semantik (z.B. eine Vielzahl verschiedener Abhängigkeiten zwischen Informationsobjekten) abbilden zu können, um Konsistenzprüfungen durchführen zu können und/oder um ER-Diagramme systematischer verstehen oder kommunizieren zu können (siehe z. B. die Übersicht in (Winter 1998)).

BEN-Komponenten

127

ER-Diagramme dokumentieren, welche Informationsobjekte mit welchen anderen Informationsobjekten in welcher Beziehung stehen. Ein Informationsobjekt wird dabei als individuelles und identifizierbares Exemplar von Dingen der realen Welt verstanden und als Entität bezeichnet. ER-Diagramme enthalten die folgenden Elementtypen: •

•

•

Entitätstyp (Entitytyp): Jede Klasse „gleichartiger“ Entitäten (d.h. Informationsobjekte des gleichen Typs) wird als Entitätstyp abgebildet. Entitätstypen werden grafisch meist durch benannte Rechtecke repräsentiert. Als Name sollte ein Substantiv benutzt werden. So bildet z. B. die Klasse aller Produkte den Entitätstyp „Produkt“. Die Klasse aller Reiseveranstalter bildet den Entitätstyp „Reiseveranstalter“. Die Eigenschaften von Informationsobjekten werden in Form von Attributen des entsprechenden Entitätstyps beschrieben. Spezielle Bedeutung haben Schlüsselattribute: Jede Entität eines Entitätstyps muss durch die individuellen Werte ihrer Schlüsselattribute eineindeutig identifiziert werden können. Attribut: Die Tatsache, dass alle Informationsobjekte eines Entitätstyps „gleichartig“ sind, äußert sich u. a. darin, dass sie Ausprägungen hinsichtlich einer bestimmten, gemeinsamen Menge von Attributen haben. So haben z. B. alle Produkte eine Produktnummer, einen Produktnamen und einen Preis. Jedes Attribut hat einen Namen, einen Datentyp (z. B. ganze Zahlen, Zeichenkette) und eventuell einen bestimmten Wertebereich. Wenn Attribute in ER-Diagramme einbezogen werden, erfolgt dies in der klassischen Darstellung durch eine mit dem jeweiligen Entitätstyp verbundene, benannte Ellipse. In modernen Notationen werden die Attribute meist im Rechteck aufgelistet, das den jeweiligen Entitätstyp repräsentiert. Falls ein Attribut oder eine Attributkombination zur eineindeutigen Identifikation der Informationsobjekte eines Entitätstyps benutzt werden kann, spricht man von einem Identifikationsschlüssel (oder Primärschlüssel). Beziehungstyp (Relationshiptyp): Informationsobjekte stehen fast immer mit anderen Informationsobjekten des gleichen oder eines anderen Entitätstyps in einer Beziehung. Jede Klasse gleichartiger Beziehungen wird als Beziehungstyp modelliert, der die beteiligten Entitätstypen verbindet. So repräsentiert z. B. „Produkt“ die Klasse aller Beziehungen zwischen einem bestimmten Reiseveranstalter und einer bestimmten Produktkomponente. Falls sich ein Produkt aus mehreren Produktkomponenten zusammensetzten darf, ist zusätzlich ein Beziehungstyp „Zusammensetzung“ abzubilden, der die Klasse aller Beziehungen zwischen einem bestimmten Produkt und einer bestimmten Produktkomponente repräsentiert. Im letzteren Fall ist „Produkt“ dann kein Beziehungstyp mehr, sondern ein (schwacher) Entitätstyp (siehe hierzu auch die Ausführungen zu Existenzabhängigkeiten weiter unten). In der klassischen Notation werden Beziehungstypen grafisch durch be-

128


nannte Rauten repräsentiert, die mit den beteiligten Entitätstypen durch Kanten verbunden sind. In modernen Notationen werden Beziehungstypen wie Entitätstypen dargestellt, falls sie eigene Attribute haben (z. B. Attribut „Zeitpunkt“ des Entitätstyps „Zusammensetzung“). Falls ein Beziehungstyp keine eigenen Attribute hat (d. h. nur eine Abhängigkeit darstellt), wird er als benannte Kante dargestellt. Als Name des Beziehungstyps sollte möglichst ein Partizip oder Verb benutzt werden, falls ein geeignetes existiert. Semantisch reichhaltiger wird das Modell der Informationslandschaft, wenn die unterschiedliche Bedeutung des Beziehungstyps aus Sicht der beteiligten Entitätstypen durch unterschiedliche Namen verdeutlicht wird. Falls nur ein Name benutzt wird, sollte die Kante, die „Reiseveranstalter“ und „Produkt“ repräsentiert, als „anbieten“ benannt werden. Falls die Modellierungstechnik zwei Namen zulässt, sollte aus Sicht „Produkt“ der Name „angeboten von“ und aus Sicht „Reiseveranstalter“ der Name „anbieten“ benutzt werden (siehe hierzu auch Abb. 65). In manchen Fällen ist es nicht möglich, einen (oder gar mehrere) sinnvolle(n) Namen für einen Beziehungstyp zu finden. In diesem Fall kann der Name aus den Namen der beteiligten Entitätstypen (oder die entsprechenden Abkürzungen) kombiniert werden. Eine spezielle Art der Beziehung zwischen Entitätstypen ist die Generalisierungsbeziehung. Eine Generalisierungsbeziehung liegt vor, wenn alle Informationsobjekte eines (speziellen) Entitätstyps gleichzeitig auch zu einem (generellen) Entitätstyp gehören. Beispielsweise können alle Hotels und alle Flüge auch als Spezialisierungen des generellen Entitätstyps „Produktkomponente“ betrachtet werden. Grafisch wird die Generalisierungsbeziehung meist durch ein Dreieck repräsentiert, das die speziellen Entitätstypen über Kanten mit dem generellen Entitätstyp verbindet (siehe hierzu auch Abb. 64). Für die korrekte Modellierung eines Beziehungstyps ist zu klären, wie viele Informationsobjekte der beteiligten Entitätstypen jeweils an Beziehungen dieses Typs teilnehmen können (Kardinalität). Im einfachen ER-Modell werden 1:1, n:1, 1:n- und m:n-Beziehungen unterschieden. In Abb. 63 sind Beispiele für die verschiedenen Kardinalitätsbeziehungen abgebildet. Auf der linken Seite sind die Kardinalitätsbeziehungen zwischen Mengen ersichtlich, während auf der rechten Seite die Abbildungen auf Kardinalitäten in ER Diagrammen zu finden sind. Die Beispiele werden kurz erläutert. Ein Kunde darf genau einen Sitzplatz z.B. in einem Flugzeug reservieren, und ein Sitzplatz wird genau einem Kunden zugeordnet (1:1 Beziehungstyp). Ein Reiseveranstalter bietet mehrere Produkte an, während ein Produkt zu genau einem Reiseveranstalter gehört (n:1 Beziehungstyp). Ein Kunde bucht eine Reise, aber dieselbe Reise kann von mehreren Kunden gebucht werden (1:n-Beziehungstyp). Eine gebuchte Reise kann mehrere Produkte beinhalten, und ein Produkt kann auch in mehreren Reisen gebucht werden (m:n Beziehungstyp).

BEN-Komponenten

129

Abb. 63. Kardinalitätsbeziehungen

Weiterhin ist zu klären, ob Informationsobjekte eines Entitätstyps an einer Beziehung teilnehmen können oder müssen (Partizipation). So kann ein Produkt nur dann existieren, wenn ein Reiseveranstalter existiert, der diese Produkt anbietet. Eine derartige Existenzabhängigkeit (d. h. der Zwang, an einer Beziehung zu einem anderen Informationsobjekt teilnehmen zu müssen) kann durch eine zweite, sozusagen Minimal-Kardinalität modelliert werden. Zusammen mit der (Maximal-)Kardinalität 1 bzw. n entstehen damit für jeden an einem Beziehungstyp beteiligten Entitätstyp die folgenden vier kombinierten Kardinalitäten (sog. MinMax-Notation): • •

(0,1): Die Entitäten des betreffenden Entitätstyps können (müssen aber nicht) an maximal einer Beziehung teilnehmen. (0,n) oder alternativ (0,*): Die Entitäten des betreffenden Entitätstyps können (müssen aber nicht) an einer oder mehreren Beziehungen teilnehmen.

130


• •

(1,1): Die Entitäten des betreffenden Entitätstyps müssen an genau einer Beziehung teilnehmen (klassische Existenzabhängigkeit). (1,n) oder alternativ (1,*): Die Entitäten des betreffenden Entitätstyps müssen an einer oder mehreren Beziehungen teilnehmen.

Wie bereits erwähnt, wird häufig nicht mehr zwischen Entitätstypen und Beziehungstypen mit eigenen Attributen unterschieden. Als Konsequenz wird jede Klasse gleichartiger Informationsobjekte, egal ob vom Charakter her unabhängig oder abhängig, als Informationsobjekttyp modelliert, solange sie eigene Attribute hat. Abb. 64 zeigt ein einfaches ER-Diagramm in der traditionellen, im Wesentlichen auf der Originalarbeit (Chen 1976) beruhenden Notation.

Abb. 64. ER-Diagramm in traditioneller Notation

Abb. 65. ER-Diagramm in ssADM-Notation

BEN-Komponenten

131

Abb. 65 zeigt die in Abb. 64 dargestellten Informationsobjekte und ihre Beziehungen in der sog. ssADM-Notation. In Abb. 65 werden Beziehungstypen mit Attributen wie Entitätstypen abgebildet, während attributlose Beziehungstypen zu Referenzen werden. Außerdem werden Referenzen mit zwei Namen versehen, um im Diagramm möglichst viel Semantik zu repräsentieren. Generalisierungsbeziehungen werden impliziert, indem spezielle Entitätstypen als „Untertypen“ in der grafischen Repräsentation des generellen Entitätstyps dargestellt werden. •

•

Partizipation: Der (0,…)-Aspekt eines Beziehungstyps wird grafisch durch eine unterbrochene Kante beim Ausgangspunkt dargestellt, der (1,…)-Aspekt dagegen durch eine reguläre Kante. Kardinalität: Der (…,*)-Aspekt eines Beziehungstyps wird grafisch durch einen sog. Krähenfuß beim mehrfach auftretenden Entitätstyp dargestellt, der (…,1)-Aspekt dagegen durch eine reguläre Kante.

In den bisher gezeigten Techniken zur Informationsgestaltung gibt es weder Hierarchieebenen (zur Verfeinerung oder Vergröberung von Informationsmodellen) noch Anordnungsregeln oder methodische Integration mit anderen Teilaufgaben der Organisationsgestaltung. •

•

•

Die Einführung von Hierarchieebenen ist schwierig und widerspricht dem Charakter von Informationslandkarten als „flache“ Darstellungen von Gesamtzusammenhängen; gleichwohl gibt es in diesem Bereich verschiedene Ansätze (vgl. z. B. (Boßhammer u. Winter 1995)). Sinnvolle Erweiterungen der Informationsgestaltung wurden in Form von Anordnungsregeln vorgeschlagen, die eine strukturierte Erschließung der jeweiligen Diagramme unterstützen. So sieht z. B. das SERM-Modell (Sinz 1988) eine Anordnung der Objekttypen aufgrund von Existenzabhängigkeiten vor. Für komplexe, umfassende Informationslandkarten ist die Definition und der Einsatz solcher Anordnungsregeln unbedingt zu empfehlen. Die „informatorische Welt“ existiert nicht unabhängig von der Welt der physischen Leistungserstellung. Gleichwohl werden diese TeilRealitätsausschnitte mit unterschiedlichen Techniken (hierarchisch vs. „flach“) analysiert/gestaltet und in unterschiedlichen Modellen abgebildet. Verschiedene Ansätze versuchen z.B. die Gestaltung der Ablauforganisation und die Informationsgestaltung zusammenführen. Beispiele dafür sind Datenflussdiagramme der traditionellen „Strukturierte Analyse“ (Yourdon 1989), Informationsobjekt-Lebenszyklusdiagramme (vgl. z. B. (Österle 1995)) oder erweiterte Notationen und Techniken zur Informationsmodellierung (vgl. z. B. (Winter 1998)).

132


4.3.3.2 Detaillierte Abbildung einzelner Informationsobjekte Die bisher vorgestellten Techniken erlauben eine gesamthafte Darstellung der relevanten Informationsobjekte eines Realitätsausschnitts sowie deren Beziehungen/Abhängigkeiten, nicht jedoch die detaillierte Spezifikation von Informationsobjekten und Analysepfaden. Eine intuitiv verständliche und deshalb gut kommunizierbare Notation für Informationsobjekte ist deren Abbildung in Form als Fakten, die sich auf bestimmte Dimensionen beziehen und auf dieser Grundlage verknüpft, aggregiert und/oder zerlegt werden können. Als Beispiel wird „Absatz“ betrachtet: Jeder erfasste Abverkauf bezieht sich auf einen bestimmten Zeitraum, ein bestimmtes Produkt und eine bestimmte Kundenbeziehung („Vertriebsdimension“). Wenn dies mit dem Abverkauf erfasst (oder später zugeordnet) wird, können Absätze auch hinsichtlich Sonderaktionen, Vertriebskanal (z.B. bestimmte Filiale), Vertriebsorganisation (z.B. Verkäufer), beliebigen möglicherweise interessanten Dimensionen wie z.B. Wetter oder auch bestimmten betriebswirtschaftlichen Kennzahlen (z. B. Deckungsbeitrag) analysiert werden. Derart (multidimensional) erfasste Informationen können auf verschiedenste Weise analysiert werden: •

•

•

Verschiedene multidimensional erfasste Informationen können verknüpft werden (z.B. alle Absätze eines bestimmten Kunden in einem bestimmten Zeitraum), um komplexe Erkenntnisse zu gewinnen (z.B. Warenkorbanalyse). Informationen können für größere Zeiträume, ganze Produktlinien, ganze Vertriebsbereiche, Sonderaktionen und/oder zusammengesetzte Kennzahlen aggregiert werden. Alle Informationen können hinsichtlich bestimmter Zeiträume, bestimmter Produkte, bestimmter Vertriebskanäle, bestimmter Kennzahlen oder einer Kombination dieser Merkmale selektiert werden (z.B. PerformanceVergleich von Filialen oder Verkäufern, Kennzahlen-Vergleich von Produkten)

Da alle Bezugsgrößen jeweils Teil einer Hierarchie sind, kann man die Absatzinformationen durch Hinauf- oder Herabwandern in den verschiedenen Hierarchien beliebig verfeinern oder vergröbern. Abb. 66 illustriert nach (Schelp 2000) als Beispiel das Faktum „Absatz“: Jede erfasste Absatzinformation bezieht sich auf einen bestimmten Zeitraum, ein bestimmtes Produkt, eine bestimmte Kundenbeziehung („Vertriebsdimension“) und eine bestimmte Kennzahl.

BEN-Komponenten

133

Abb. 66. Multidimensional beschriebenes Faktum (Schelp 2000)

4.3.3.3 Aktivitäten der Informationsgestaltung Die Informationsmodellierung fokussiert häufig auf Modelle und Notationen, vernachlässigt aber das Vorgehen. Als generelles Gestaltungsprinzip kann die Gewährleistung möglichst umfassender Freiheitsgrade eingestuft werden: Die Möglichkeit, z.B. im ER-Diagramm einen Sachverhalt nach eigenem Ermessen als Entitätstyp oder als Attribut bzw. als Entitätstyp oder als Beziehungstyp abbilden zu können, wird als Vorzug oder zumindest als unvermeidlich angesehen. Informationslandkarten und Informationsobjektmodelle sollen ja einerseits von der Umsetzung abstrahieren (physische Datenunabhängigkeit) und andererseits eine Vielzahl unterschiedlicher Analysen und Perspektiven unterstützen (logische Datenunabhängigkeit); Sie werden deshalb oft als wesentlich offener und weniger konkret als vergleichbare Modelle der Aufbau- oder Ablauforganisation angesehen. Im Folgenden wird kurz auf die wichtigsten Teilaufgaben der Informationsgestaltung eingegangen:

134


•

•

Informationsbedarfsanalyse: Wie können konkrete Informationsbedarfe von Entscheidungsträgern (Aufgabenträger=Mensch) oder automatisierten Geschäftsprozessen (Aufgabenträger=IT-System) ermittelt werden? Konzeptionelle Informationsmodellierung: Wie lassen sich die Begriffe und Sachzusammenhänge eines Realitätsausschnitts systematisch analysieren und (re-)konstruieren?

Informationsbedarfsanalyse Anforderungsanalyse (Requirements Engineering) wird als Gesamtheit aller Aktivitäten verstanden, die Anforderungen an ein(e) Informationssystem(komponente) ermitteln, dokumentieren und aktuell halten. Während für die „normale“ Anforderungsanalyse (z.B. im Rahmen der Informationssystementwicklung) zwischen funktionalen und nicht-funktionalen Anforderungen unterschieden wird, unterscheidet man für die Informationsbedarfsanalyse analog zwischen informatorischen und nicht-informatorischen Anforderungen (Stroh et al.). Informatorische Anforderungen fokussieren insbesondere auf Informationsinhalte, -qualität und -visualisierung, während sich nicht-informatorische Anforderungen z.B. auf Informationssystemsicherheit, -performance, -datenschutz und -wartbarkeit beziehen (Goeken 2005). (Stroh et al.) identifizieren als Kernaktivitäten der Informationsbedarfsanalyse die Gewinnung, die Dokumentation, die Übereinstimmungsprüfung, die Validierung und das Management von Informationsbedarfen: •

•

•

•

Bei der Gewinnung sollten nicht nur Mitarbeitende mit operativem Tätigkeitsfeld, sondern explizit auch Personen mit mittlerer Führungsverantwortung und Entscheidungskompetenz wie beispielsweise Abteilungsoder Teamleitende involviert werden. Zur Gewinnung von Informationsbedarfen eignen sich neben Befragungen auch Dokument- und Berichtsanalysen. Einige Ansätze versuchen, Informationsbedarfe transparent aus Zielformulierungen bzw. Tätigkeitsbeschreibungen abzuleiten. Hinsichtlich der Dokumentation von Informationsbedarfen befassen sich nur wenige Ansätze mit der Problematik, Spezifikationen mit ausreichender Präzision zu erstellen und diese nicht nur für IT-, sondern auch involvierte Fachabteilungen verständlich zu gestalten. Die Kernaktivität Übereinstimmung findet in vergleichsweise wenigen Ansätzen Beachtung. Gerade die Priorisierung der Informationsbedarfe ist jedoch ein wichtiger Bestandteil beispielsweise bei unternehmensweiten Ansätzen, die eine Fülle von Informationsbedarfen ermitteln. Nur wenige Ansätze beschäftigen sich mit der Validierung von spezifizierten Informationsbedarfen beispielsweise in Form von Befragungen von Fachanwendern. Angelehnt an bestehende leichtwichtige Prozesse aus der Softwareentwicklung (vgl. z.B. (Ebert 2008; Shore u. Warden

BEN-Komponenten

•

135

2008)) kann die verstärkte Einbindung von Prototypen die Spezifizierung und insbesondere die Validierung von Informationsbedarfen erleichtern. Das kontinuierliche Management von Informationsbedarfen findet in den untersuchten Ansätzen kaum Beachtung. Nach Aussage von (Watson et al. 2004) zählt die kontinuierliche Identifikation und Ableitung von Informationsbedarfen zu den Themenfeldern, die durch definierte Governance-Prozesse und -Rollenbeteiligungen abgedeckt werden sollen.

Konzeptionelle Informationsmodellierung Die Objekttypenmethode (Wedekind 1981; Ortner u. Söllner 1989) hat das Ziel, Fachbegriffe und Sachzusammenhänge eines Realitätsausschnitts eindeutig und widerspruchsfrei festzulegen. Dabei wird unterstellt, dass sich die Semantik eines Realitätsausschnitts in der jeweils benutzten Fachsprache manifestiert und dass diese Fachsprache damit nicht nur die gemeinsame Kommunikationsgrundlage von Anwendern und Entwicklern darstellt, sondern auch als Basis aller zu entwickelnden Systeme angesehen werden muss. Daher sind die wesentlichen Aufgaben der konzeptionellen Datenmodellierung: • • •

Analyse und Beschreibung der Informationsobjekte und ihrer Eigenschaften. Rekonstruktion der Fachsprache, d. h. der Begriffe und ihrer Beziehungen zueinander. Anwendungsübergreifende Darstellung dieses Begriffssystems.

Eine konkrete Unterstützung der konzeptionellen Modellierung erfolgt in Form von Definitionen, Regeln und Arbeitsanweisungen, die zusammenfassend als Begriffskalkül bezeichnet werden. Die konzeptionelle Modellierung durchläuft mehrere Phasen: •

•

Erhebung relevanter Aussagen: Zunächst sind relevante Aussagen über die Gegenstände und Sach-zusammenhänge des Realitätsbereichs zu sammeln und zu klassifizieren (Aussagen über Informationsobjekte, über Operationen, über Ereignisse, über Konsistenzbedingungen etc.). Grobdatenmodellierung: Die Gegenstände sind zu klassifizieren und die sich ergebenden Klassen sind zu definieren (Rekonstruktion von Informationsobjekttypen). Danach sind die Beziehungen der Informationsobjekttypen untereinander und zu eventuell bestehenden Informationsmodellen zu analysieren, die jeweiligen Beziehungen sind zu definieren (Rekonstruktion von Sachzusammenhängen) und die Informationsobjekttypen sind entsprechend ihrer Beziehungen anzuordnen. Schließlich sind alle Informationsobjekttypen und ihre Beziehungen in ein Gesamtmodell zu integrieren.

136

BEN-Komponente IT/Business Alignment

•

Feindatenmodellierung: Auf der Grundlage der Abstraktionsbeziehungen zwischen Informationsobjekttypen werden identifizierende Attribute (Primärschlüssel) erzeugt und den jeweiligen Informationsobjekttypen mit „charakterisierenden Attributen“ (Nichtschlüsselattributen) zugeordnet. Soweit dies möglich ist, sind für Attribute Wertebereiche (Domänen) zu definieren. Schließlich wird das Gesamtmodell der Informationsobjekte und Abhängigkeiten durch semantische Konsistenzbedingungen (wie z. B. Aussagen über Kardinalitäten oder Voraussetzungen für Operationen) ergänzt.

Das Vorgehensmodell der Objekttypenmethode ist grundsätzlich auch für andere Techniken zur Abbildung der „informatorischen Welt“ anwendbar.

4.4 BEN-Komponente IT/Business Alignment Auf der IT/Business Alignment-Ebene geht es darum, die sich aufgrund einer Vielzahl von Veränderungsprojekten nicht immer konsistent und „im Gleichschritt“ weiterentwickelnden fachlichen und IT-Strukturen immer wieder gegenseitig aufeinander auszurichten. Die wesentlichen Aktivitäten dieser Komponente sind deshalb •

•

die Identifikation (und später Validierung und allenfalls Anpassung) geeigneter Alignment-Artefakte wie beispielsweise Capabilities/fachliche Services, Applikationen und Domänen (sowie der Beziehungen dieser Artefakte untereinander) und die Zuordnung der Alignment-Artefakte zu den Artefakten bzw. Strukturen, welche sie entkoppeln sollen – also die Zuordnung zu einerseits Artefakten der Organisationsebene und andererseits Artefakten der ITEbene.

Da Alignment-Artefakte konzeptionell als mehr oder weniger stark gebündelte Kopplungen von Organisations- mit IT-Artefakten verstanden werden können, zählt die Kopplungsanalyse zu den zentralen „bottom-up“-Techniken der Alignment-Komponente – Bottom-up deshalb, weil aggregierte Alignment-Artefakte aufgrund der Analyse feingranularer Artefakte bzw. deren Beziehungen gebildet werden. Ein Beispiel für „Bottom-up“-Kopplungsanalyse ist die Identifikation von Applikationen durch Analyse der Kopplungen zwischen IT-Funktionalitäten und Prozessaktivitäten. Alignment-Artefakte können auch durch „Top-down“Kopplungsanalyse identifiziert werden – Top-down deshalb, weil feingranulare Alignment-Artefakte aufgrund einer Analyse gleich oder geringer granularer Artefakte bzw. deren Beziehungen gebildet werden. Ein Beispiel für „Top-down“Kopplungsanalyse ist die Identifikation von fachlichen Services durch die Analyse

BEN-Komponenten

137

durch die Analyse der Prozess- oder Informationsstrukturen auf Organisationsebene. Zentrale Ergebnisdokumente des IT/Business Alignment sind Domänenmodelle, Applikationslandschaften, Capability-Modelle bzw. Modelle fachlicher Services.

4.4.1 Die Alignment-Artefakte Capability/fachlicher Service, Applikation und Domäne Bündel „zusammengehörender“ Zuordnungen elementarer Softwarefunktionalitäten zu elementaren Prozessaktivitäten bilden die elementarsten AlignmentArtefakte. Welche Zuordnungen dabei zusammen gehören und welcher Bündelungsgrad sinnvoll ist, wird mittels Kopplungsanalysen ermittelt bzw. – nach Änderungen – validiert. Es fällt schwer, eine passende Bezeichnung für diese Zuordnungsbündel zu finden, weil es sich ja weder um „richtige“ organisatorische Artefakte noch um „richtige“ IT-Artefakte handelt. Wir benutzen für diese Zuordnungsbündel die Bezeichnung „Capability“, weil sie der Definition von Capabilities in verschiedenen Ansätzen von Softwareherstellern sehr nahe kommen. Elementare Capabilities können, bei Bedarf mehrstufig, zu aggregierten Capabilities zusammengefasst werden. Eine Mehrfachaggregation erscheint dabei nicht sinnvoll zu sein, so dass eine einfache hierarchische Struktur entsteht. Allerdings stellen auch aggregierte Capabilities nichts anderes dar als (sehr große) Bündel von Zuordnungen elementarer IT-Funktionalitäten zu elementaren Prozessaktivitäten. Wenn bei der Spezifikation von Capabilities besondere Strukturierungsprinzipien angewandt werden, sind auch besondere Bezeichnungen gerechtfertigt. Serviceorientiert strukturierte Capabilities können als fachliche Services bezeichnet werden – der Zusatz „fachlich“ dient dabei der Unterscheidung zu Services auf Organisationsebene (serviceorientiert strukturierte Prozesse) sowie zu SoftwareServices (serviceorientiert strukturierte Softwarekomponenten). Wenn Prozesskomponenten oder Prozesse (anstelle von Prozessaktivitäten) der Organisationsebene auf der einen Seite Softwaresystemkomponenten oder Softwaresystemen (anstelle von IT-Funktionalitäten) der IT-Ebene auf der anderen Seite zugeordnet werden, handelt es sich um sehr grobgranulare Zuordnungen und damit um Applikationen und nicht mehr um Capabilities. Elementare Applikationen können, bei Bedarf mehrstufig, zu aggregierten Applikationen zusammengefasst werden. Eine Mehrfachaggregation erscheint dabei nicht sinnvoll zu sein, so dass eine einfache hierarchische Struktur entsteht. Allerdings stellen auch aggregierte Applikationen nichts anderes dar als (sehr große) Bündel von Zuordnungen von Prozessen zu Softwaresystemen. Der höchste Aggregationsgrad von Applikationen ist dann erreicht, wenn sich selbst bei unternehmensweiter Sicht eine nur noch geringe Anzahl (ca. 10-20) von

138


Zuordnungsbündeln ergibt, welche vorrangig fachlich strukturiert sind. In der Praxis werden diese fachlich strukturierten, hochaggregierten Zuordnungsbündel als „Domänen“ bezeichnet („domains“ oder „functional domains“, (Stock et al.)). Oft werden die Konstrukte der nächst detaillierteren Aggregationsebene als „UnterDomänen“ („sub-domains“) bezeichnet. Der Übergang von (aggregierten) Applikationen zu Unter-Domänen und letztlich Domänen ist fliessend. Im Gegensatz zu Applikationen, die im Normalfall „bottom-up“ identifiziert und validiert werden (Analyse der Kopplungen von Prozessen und Softwaresystemen), werden jedoch Domänen meist „top-down“ identifiziert und validiert (fachliche Dekomposition des Informationssystems). Capabilities (bzw. fachliche Services) können untereinander durch TeilGanzes-Beziehungen verknüpft sein. Sie müssen Beziehungen zu Prozessaktivitäten und Software-Funktionalitäten haben. Darüber hinaus können sie Beziehungen zu Organisationseinheiten („Ownership“, „Berechtigung“), Informationsobjekten und Daten haben. Applikationen können untereinander und mit Domänen durch Teil-GanzesBeziehungen verknüpft sein. Applikationen können untereinander durch Interaktionen verbunden sein („Schnittstelle/Abhängigkeit“). Applikationen müssen Beziehungen zu Prozessen und Softwaresystemen haben. Darüber hinaus können Applikationen bzw. Domänen Beziehungen zu Organisationseinheiten („Ownership“, „Berechtigung“), Informationsobjekten und Daten haben.

4.4.2 Bottom-up-Kopplungsanalyse Bei der Bottom-up-Kopplungsanalyse geht es darum bestehende Softwaresysteme zu IT/Business Alignment Artefakte zu bündeln. Solche Artefakte können Applikationen oder Domänen sein, die dann wiederum mit den Modellen der Organisationsebene in Verbindung gesetzt werden. Dadurch wird eine komplette Entkoppelung der Organisationsebenen und der IT-Ebene gewährleistet.

4.4.2.1 Identifikation von Applikationen Die Applikationslandschaft soll einerseits inhaltlich zusammenhängende ProzessSoftwaresystem-Zuordnungen bündeln und inhaltlich unverbundene ProzessSoftwaresystem-Zuordnungen davon getrennt halten. Andererseits sollen gut wieder verwendbare Zuordnungsbündel identifiziert werden, um Applikationen unter Nutzung dieser „Applikationskomponenten“ schneller konstruieren und leichter verändern zu können. Unter der Applikationslandschaft wird ein umfassendes Modell der identifizierten Zuordnungs-Bündel sowie ihrer (Teil-Ganzes- sowie sonstigen Abhängigkeits-)Beziehungen untereinander verstanden.

BEN-Komponenten

139

Die Gestaltung der Applikationslandschaft berücksichtigt die Ergebnisse der Organisationsgestaltung (insbesondere Prozesslandkarte, Aufbauorganisation, Informationsstrukturen) wie auch die Strukturierung der IT-Ebene (Softwaresysteme, Datenstrukturen). Die IT-Infrastruktur sollte jedoch keine Rolle spielen. Eine frühe, aber wegweisende Technik zur Bottom-up-Identifikation von Applikationen ist „Business Systems Planning“ (BSP) von IBM (IBM 1984). In mehreren Analyseschritten werden relevante Prozesse und Daten des betrachteten Realitätsausschnitts erhoben. Dann wird analysiert, welche Prozesse auf welche Daten zugreifen. Diese „Zuordnung“ bildet dann die Grundlage der Applikationsidentifikation. Durch Seriationsanalyse wird die Reihenfolge der Prozesse (vertikale Dimension in Abb. 67) oder der Daten (horizontale Dimension in Abb. 67) solange vertauscht, bis die Zuordnungen maximal nahe an der Hauptdiagonale liegen. Dadurch werden auf der Hauptdiagonale „inhaltlich verbundene“ Zuordnungen auch visuell deutlich, während wenig miteinander zu tun habende Prozess-DatenZuordnungen weitab liegen.

Abb. 67. Seriationsanalyse im Rahmen von Business Systems Planning (in Anlehnung an das Beispiel aus Heinrich 1996)

140


Abb. 67 zeigt das Ergebnis einer solchen Seriationsanalyse. Allerdings wird in dieser Abbildung nicht deutlich, dass BSP Kopplungen „entdeckt“, die zwar vorher schon vorhanden waren, aber wegen ungeeigneter Reihenfolgen der Artefakte und zu hoher Artefaktzahl nicht auffällig waren. Abb. 68 zeigt deshalb eine Zuordnungsmatrix a la BSP einmal vor der Seriation (linke Seite) und einmal nach der Seriation (rechte Seite). Stichproben machen deutlich, dass der Informationsinhalt der linken und der rechten Matrix identisch ist. Allein die Zeilen und Spalten wurden durch den Seriationsalgorithmus so geschickt vertauscht, dass die Kopplungsstruktur sichtbar wird und z.B. drei Applikationen identifiziert werden können.

Abb. 68. Wirkung der Seriationsanalyse

4.4.2.2 Identifikation von Domänen Ähnlich wie Applikationen können auch Domänen Bottom-up, d.h. durch Kopplungsanalyse verbundener Detailartefakte identifiziert werden. Das im Folgenden benutzte Beispiel „EA Builder“ (Aier 2006) verwendet keinen Seriationsalgorithmus zur Identifikation „versteckter“ Kopplungen, sondern ignoriert schrittweise die am wenigsten wirksame Kopplung innerhalb eines Zuordnungsnetzes. Dieses repräsentiert Zuordnungen zwischen Softwaresystemen und Prozessen. Die Identifikation und Elimination der „schwächsten“ Kopplung wird solange wiederholt, bis aus dem Gesamtnetz eine Zerlegung in Teilnetze entsteht, welche die „Modularität“ des Netzes maximiert. Die sich ergebenden Teilnetze (d.h. Softwaresystem-Prozess-Zuordnungen) stellen dann die Domänen dar.

BEN-Komponenten

Abb. 69. Zuordnungsnetz zwischen Softwaresystemen und Prozessen (in Anlehnung an Aier 2006)

Abb. 70. Identifikation von Domänen-Kandidaten durch Zerlegung des Zuordnungsnetzes (in Anlehnung an Aier 2006)

141

142


Abb. 69 illustriert den Ausschnitt eines Zuordnungsnetzes zwischen Softwaresystemen (große Knoten) und Prozessen (kleine Knoten). Der Eliminationsalgorithmus zerlegt dieses Netz sukzessiv. Das Ergebnis (allerdings für ein weit größeres Netz) wird in Abb. 70 illustriert. Oben rechts in Abb. 70 findet sich die Modularitätsfunktion, die ihr Maximum bei 12 Teilnetzen (= Domänen) hat.

4.4.3 Top-down-Kopplungsanalyse In diesem Unterkapitel wird gezeigt, wie ausgehend von Modellen der Organisationsebene IT/Business Alignment Artefakte identifiziert werden können. Zu den zu identifizierenden IT/Business Alignment Artefakte gehören die Capabilities, fachlichen Services, Applikationen oder Domänen. Diese Top-Down identifizierten Alignment Artefakte bilden dann die Grundlage für die Kopplung mit den Modellen der IT-Ebene.

4.4.3.1 Identifikation von Capabilities Im Gegensatz zu den Bottom-up Kopplungsanalysen, welche z.B. existierende Softwaresysteme zu Applikationen oder Domänen bündeln, werden mit der Topdown Kopplungsanalyse Capabilities aus den Modellen der Organisationsebene abgeleitet. Derart identifizierte Capabilities werden auch als fachliche Komponenten bezeichnet. Sie werden erst in einem zweiten Schritt mit Softwaresystemen verbunden, um das Alignment zwischen Organisationsgestaltung und IT zu gewährleisten. Auch wenn Capabilities „nur“ abstrakte Komponenten darstellen, die elementare Softwarefunktionalitäten z.B. elementaren Prozessaktivitäten zuordnen, sind sie wichtige Artefakte bei der Gestaltung von Informationssystemen. Einer der wichtigsten Kriterien bei der Identifikation von Capabilities ist die Wiederverwendbarkeit aus fachlicher Sicht. Um die Wiederverwendbarkeit zu ermöglichen, ist es wichtig, dass eng zusammengehörende Artefakte, wie z.B. Informationsobjekte oder Prozessabläufe, zu Capabilities zusammengefasst werden, um somit eine minimale Kommunikation zwischen fachlichen Komponenten und eine maximale Kompaktheit innerhalb fachlicher Komponenten zu erreichen. Ein weiterer wichtiger Faktor ist die Modularität, welche die Adaptierbarkeit der Komponenten bei sich fachlich ändernden Bedürfnissen ermöglicht. Es gibt verschiedene Ansätze, wie man zu fachlichen Komponenten gelangt. Diese Ansätze reichen von generellen Empfehlungen und strukturierten Methoden bis hin zu algorithmischen Prozeduren (Birkmeier u. Overhage 2009). Generelle Empfehlungen basieren meistens auf Praxiserfahrungen, die sich wiederholt bei der Identifikation von fachlichen Komponenten nach bestimmten Charakteristiken in verschiedenen Projekten bewährt haben (siehe hierzu z.B. Szyperski et al. 2002). Strukturierte Methoden hingegen geben klare und detaillierte Anweisun-

BEN-Komponenten

143

gen, welche Arbeitsschritte und in welcher Reihenfolge durchzuführen sind (siehe hierzu z.B. Cheesman u. Daniels 2001). Algorithmische Prozeduren unterstützen die verschiedenen Arbeitsschritte noch zusätzlich mit formalen Methoden um automatisiert fachliche Komponenten zu identifizieren (siehe hierzu z.B. Albani et al. 2008). Als Beispiel einer formalen Methodik zur Identifikation von fachlichen Komponenten wird nachfolgend kurz der Business Component Identification Ansatz von Albani et al. erläutert. Ausgangspunkt für die Identifikation bilden Modelle der Organisationsebene, und zwar sowohl Ablaufmodelle wie auch Informationsmodelle. An sich spielt es keine Rolle, welche Notation bei der Erstellung verwendet wurde; wichtig ist nur, dass die Modelle eine hohe Qualität aufweisen. Sowohl die Aktivitäten der Ablaufmodelle wie auch die Informationsobjekte aus den Informationsmodellen werden extrahiert und in einem dreidimensionalen Graphen als Knoten abgebildet. Abb. 71 zeigt beispielhaft solch einen Graphen, in dem die Aktivitäten im unteren Kreis angeordnet und die Informationsobjekten im oberen Kreis angeordnet sind.

Abb. 71. Capability-Identifikationsgraph vor der Optimierung (Albani et al. 2008)

Die Kanten stellen die Verbindungen zwischen jeweils zwei Aktivitäten, bzw. zwischen zwei Informationsobjekten dar. Da für die Ausübung einer Aktivität jeweils ein oder mehrere Informationsobjekte verwendet werden oder neue Informationsobjekte generiert werden, gibt es auch Verbindungen zwischen den Aktivitäten und den Informationsobjekten (Kanten, die von unten nach oben verlaufen). Alle Kanten werden entsprechend der Wichtigkeit mit Gewichten versehen. Die

144


Liste rechts im Bild listet beispielhaft solche Gewichtungen auf. So werden z.B. Kanten zwischen Informationsobjekten, die eng zusammengehören, mit einem höheren Gewicht versehen als die Kanten zwischen mehr oder weniger unabhängigen Informationsobjekten. Dasselbe gilt auch für die Gewichtung der Kanten zwischen zwei Aktivitäten oder zwischen einer Aktivität und einem Informationsobjekt. Die Übertragung von den Aktivitäten, Informationsobjekten und deren Verbindungen im Graphen ist unkompliziert. Hingegen erfordert die Gewichtung der Kanten Fachkenntnisse über die Prozess- und Informationsgestaltung. Die Gewichte bilden die Grundlage für die Entscheidung, ob zwei Knoten eines Graphs in eine fachliche Komponente gebündelt werden. Diese Entscheidung wird unterstützt durch das Ausführen von Graph-Partitionierungs-Algorithmen, die mit Hilfe von Start- und Verbesserungsheuristiken die Partitionierung anhand von verschiedenen Metriken, wie z.B. minimale Kommunikation und maximale Kompaktheit, durchführen (für Details dazu siehe (Albani et al. 2008)). Abb. 72 stellt das Resultat einer solchen Partitionierung nach Ausführung der Graph-Partitionierungs-Algorithmen dar. Deutlich zu erkennen sind zwei fachliche Komponenten mit den jeweils dazugehörenden Aktivitäten und Informationsobjekten, welche rechts im Bild auch aufgelistet sind. Die Abhängigkeiten zwischen den Komponenten stellen die Kanten dar, die zwischen den zwei Komponenten verlaufen. Solche Partitionierungen stellen Capabilities dar, die in weiteren Schritten mit der fachlichen Architektur und der Softwarearchitektur verbunden werden müssen.

Abb. 72. Capability-Identifikationsgraph nach dem Durchlauf des Optimierungsalgorithmus (Albani et al. 2008)

BEN-Komponenten

145

4.4.3.2 Identifikation fachlicher Services Die Bündelung von Softwarefunktionalitäts-Prozessaktivitäts-Zuordnungen zu fachlichen Services erfolgt, um neben dem Entkopplungseffekt von Capabilities auch die Vorteile serviceorientierter Strukturierung wie z.B. einfachere Rekonfiguration der nutzenden Strukturen unterstützen zu können. So können z.B. durch Nutzung von in geeigneter Weise strukturierten fachlichen Services sehr viele verschiedene Varianten eines Geschäftsprozesses unterstützt werden, d.h. bei Änderungen des Geschäftsprozesses im Rahmen dieser Varianten kann auf Anpassungen auf IT-Ebene verzichtet werden. Elementare fachliche Services können durch Software-Services wie auch durch konventionell implementierte Softwarekomponenten umgesetzt werden. Prozessaktivitäten können sowohl durch fachliche Services wie auch durch konventionell strukturierte Capabilities der IT-Ebene zugeordnet werden. Fachliche Services sind entweder „entlang“ von Geschäftsprozessen (d. h. für mehrere Informationsobjekte hinweg), „entlang“ von komplexen Informationsobjekten (d. h. über mehrere Geschäftsprozesse hinweg) oder „entlang“ einem gut wieder zu verwendenden Funktionalitätsbündel geschnitten (Schelp u. Winter 2008). Ein Beispiel für einen prozessorientierten fachlichen Service ist die Realtime-Bonitäts- bzw. Kundenwertbewertung während eines automatisierten Verkaufsprozesses, wie sie für die Bestimmung individueller Preise und Konditionen notwendig ist. Verschiedene Software-Funktionalitäten und Daten werden integriert, um den Preisbildungsprozess zu unterstützen. Der Preisbildungs-Service kann in verschiedenen Geschäftsprozessen benutzt werden. Ein Beispiel für einen informationsorientierten fachlichen Service ist die Bereitstellung von Kundenbeziehungs- oder Produkt-Stammdaten für die verschiedensten Prozesse. Ein Beispiel für einen funktionsorientierten fachlichen Service ist die Berechnung und Bereitstellung eines aktuellen Kontostands, der sowohl für eine DesktopAnwendung für Bank-Mitarbeitende wie auch für Geldautomaten oder eine WebAnwendung (E-Banking) für Kunden genutzt werden kann. (Schelp u. Winter 2008)listen folgende Prinzipien für die Identifikation von fachlichen Services auf: •

•

• •

Fachliche Services müssen grobgranular vollständig sein (logisch abgeschlossen bezüglich Funktionalität, eigenständig, ersetzbar, einem Business-Objekt zugeordnet, eindeutiger Owner benannt) Ein fachlicher Service kapselt atomare und stabile Daten- und Funktionalitätsblöcke; Funktionsblöcke können dabei auch ganze Applikationen sein Ein atomarer fachlicher Service bearbeitet nur ein einziges BusinessObjekt Ein aggregierter („komponierter“) fachlicher Service darf die Operationen der unterliegenden Software-Services nicht 1:1 exportieren

146


• • • • • • •

Eng gekoppelte fachliche Services sollten aggregiert („komponiert“), lose gekoppelte fachliche Services orchestriert werden Ein orchestrierter fachlicher Service muss ein eindeutig identifizierter Teilgeschäftsprozess sein Der neue fachliche Service wird genau einem Owner zugeteilt, auch wenn die Teilservices unterschiedliche Owner betreffen Datenownership steht bei der Festlegung der Ownership im Vordergrund Für die Definition der Schnittstellen muss ein übergeordnetes Geschäftsobjektmodell verwendet werden Die fachliche Servicegestaltung muss sich nach dem Geschäftsprozess richten Die fachlichen Serviceschneidepunkte entsprechen den von der Fachseite vorgegebenen Prozessschneidepunkten

Zurzeit werden serviceorientierte fachliche Architekturen in den meisten Unternehmungen erst aufgebaut. Für die Weiterentwicklung und Optimierung solcher Architekturen existieren deshalb nur wenig gesicherte Erkenntnisse.

4.4.3.3 Identifikation von Applikationen Aufgrund ihres Entstehens durch Bündelung inhaltlich zusammenhängender Zuordnungen lassen sich Applikationen hinsichtlich folgender Bezugsgrößen beschreiben: • • • • •

Unterstützte Geschäftsprozesse (z. B. Schadenabwicklung, Provisionierung, Risikomanagement) Bewirtschaftete Informationsobjekte (z. B. Kunde, Produkt, Vertrag, Ertrag, Risiko) Gekapselte IS-Funktionen (z. B. Anbahnung, Abschluss, Dokumentation, Autorisierung, kanalspezifische Funktionen) Unterstützte Produkte bzw. Marktbereiche (z. B. Hypothek, Kredit, Einlage) Verantwortliche Organisationseinheiten

In einem Koordinatensystem, das durch diese Bezugsgrößen gebildet wird, ließen sich Applikationen als mehrdimensionale Objekte abbilden. Als Kommunikationsund Diskussionsgrundlage sind jedoch keine mehrdimensionalen, sondern zweioder höchstens dreidimensionale Darstellungen sinnvoll: •

•

Hinsichtlich der Dimensionen Geschäftsprozess und Informationsobjekt lassen sich informatorische Kopplungen und Datenflüsse gut beschreiben. Die IS-Gestaltungsmethode Business Systems Planning (BSP) von IBM (1984) verwendet u. a. diese Darstellung. Hinsichtlich der Dimensionen Produkt/Marktbereich und Funktionalität lassen sich Wiederverwendungspotenziale gut beschreiben. Das „Buil-

BEN-Komponenten

147

ding Blocks“-Modell der Hypovereinsbank (Winter 2006) verwendet u. a. diese Darstellung. Dreidimensionale Darstellungen machen noch mehr als zweidimensionale Darstellungen die Zusammenhänge, Überlappungen und Inkonsistenzen einer Applikationslandschaft deutlich. Abb. 73 illustriert eine vereinfachte Applikationslandschaft, in der Geschäftsprozess-orientierte, Informationsobjekt-orientierte und funktional orientierte Applikationen nebeneinander und eher unsystematisch entwickelt wurden.

Abb. 73. „Gewachsene“ Applikationslandschaft (Winter 2006)

Solche Situationen entstehen, wenn über einen längeren Zeitraum hinweg kein systematisches Applikations-Architekturmanagement betrieben wird. Stattdessen werden Applikationen realisiert, die zwar aus der jeweiligen Partikularsicht heraus fachliche Anforderungen in sinnvoller Weise erfüllen, aber insgesamt betrachtet zu einer unbefriedigenden Gesamtstrukturierung führen. Abb. 74 zeigt eine „architektierte“ Applikationslandschaft. In diesem Fall wurden alle Applikationen so gestaltet, dass sie entweder bestimmte Geschäftsprozesse unterstützen oder bestimmte Informationsobjekte bewirtschaften oder bestimmte Funktionalitäten zur besseren Wiederverwendung kapseln; jede Funktionalität wurde aber nur einer einzigen Applikation zugeordnet, so dass sich die Applikationen nicht überschneiden. Analytische Applikationen sind als eigene Applikationsklasse aufgeführt, da sie Führungsprozesse unterstützen, während alle anderen Applikationen Leistungs- oder Unterstützungsprozesse unterstützen (sog. operative Applikationen).

148


Abb. 74 illustriert eine Zielsetzung, die sich u. U. nie erreichen lässt. Einerseits zwingen Personal- und finanzielle Kapazitäten dazu, bestehende Strukturen sukzessiv umzugestalten; revolutionäre Umgestaltungen der Applikationslandschaft gibt es nur selten. Andererseits ist die Ziellandschaft ein „Moving Target“, d. h. sie verändert sich mit jeder größeren Reorganisation und jedem größeren ITProjekt. Nichtsdestoweniger muss eine Architekturversion entwickelt und fortgeschrieben werden, um das Transparenzziel der fachlichen IS-Gestaltung zu unterstützen und als Bewertungsrahmen zu dienen, um die Beiträge einzelner Entwicklungsprojekte zum Gesamtziel zu messen und dadurch ein zielgerichtetes Projektportfoliomanagement zu unterstützen.

Abb. 74. „Architektierte“ Applikationslandschaft (Winter 2006)

4.4.3.4 Identifikation von Domänen Als „maximal aggregierte Applikationen“ können Domänen-Kandidaten nicht nur wie oben skizziert (Netzzerlegung in EABuilder (Aier 2006)) „bottom-up“ identifiziert werden, sondern auch aufgrund fachlicher Erwägungen top-down „geschnitten“ werden. Die möglichen Schnitte sind dabei nicht unähnlich zu fachlichen Services und Applikationen – nur eben grundsätzlicher und gröber: • • •

Entlang von Geschäfts- oder Marktbereichen Entlang von Geschäftsfunktionalitäten, -aktivitäten, Prozessen Entlang von Geschäfts-/Informationsobjekten

BEN-Komponenten

149

Natürlich sind auch Kombinationen dieser Aspekte denkbar. Allerdings sollte aufgrund des fachlichen Charakters von Domänen vermieden werden, Softwarearchitektonische oder Infrastruktur-bezogene Erwägungen in die Domänenbildung einzubeziehen.

4.5

BEN-Komponenten der IT-Ebene

Mit den BEN-Komponenten der IT-Ebene sollen die wesentlichen Strukturen der Software- und IT-Infrastrukturunterstützung von Geschäftslösungen erfasst werden. Die resultierenden Ergebnisdokumente der IT-Ebene unterscheiden sich deshalb völlig von den Ergebnisdokumenten der fachlichen Gestaltungsebenen. Ein erstes Mapping der Geschäftslösung auf Artefakte der IT-Ebene wird durch die IT/Business Alignment Ebene erreicht. Auch wenn die dort resultierenden Ergebnisdokumente „abstrakte“ Artefakte darstellen, die weder „richtige“ fachliche Artefakte noch „richtige“ IT-Artefakte darstellen, so erlauben die AlignmentArtefakte die Implementierung von Geschäftslösungen von den Geschäftslösungen selber zu entkoppeln. Auf der IT-Ebene wird die Realisierung von Applikations-/Softwarekomponenten beschrieben und es wird eine Verbindung zwischen diesen Artefakten und der IT/Business Alignment-Ebene hergestellt. Die eigentlichen Gestaltungsaktivitäten auf IT-Ebene gehören nicht zum Kernbereich des Business Engineerings, sondern zum System Engineering. Wir werden somit in diesem Abschnitt nur kurz auf die wichtigsten Aufgaben der BEN-Komponenten Softwarelösungs-Fachkonzeption und IT-Infrastruktur-Konzeption eingehen, ohne dabei ins Detail zu gehen.

4.5.1 Softwarelösungs-Fachkonzeption Zur Umsetzung von Geschäftslösungen können neue Softwarelösungen entwickelt und eingeführt werden, oder aber bestehende Softwarelösungen können weiterentwickelt werden. Die Aktivitäten, die bei der Neu- oder Weiterentwicklung von Softwarelösungen eine Rolle spielen, werden als Systementwicklung bezeichnet. Bei der Systementwicklung handelt es sich um eine strukturierte Art der Problemlösung mit klaren Aktivitäten, die aus Systemanalyse, Systementwurf, Programmierung, Test, Migration sowie Produktion und Wartung besteht (Laudon et al. 2006). Für die Komponente Sofwarelösungs-Fachkonzeption sind jedoch nur Systemanalyse und Systementwurf von Interesse.

150


4.5.1.1 Systemanalyse Die schwierigste Aufgabe bei der Systemanalyse ist sicherlich die spezifischen Anforderungen zu definieren, die von der angestrebten Softwarelösung erfüllt werden müssen. Diese spezifischen Anforderungen haben einen deutlich höheren Konkretisierungsgrad als die Anforderungen, die aus der Unternehmensanalyse auf Strategieebene und Organisationsebene hervorgehen. Zwei Arten von Anforderungen werden hier unterschieden, die Informationsanforderungen und die Systemanforderungen. Die Informationsanforderungen beschreiben, wer welche Information wo und wann bekommt; die Systemanforderungen beschreiben, wie das Softwaresystem den Benutzern die Information zur Verfügung stellt. Auch wenn z.B. die Informationsanforderungen durch das neue Softwaresystem erfüllt werden, aber die Systemanforderungen nicht, kann es dazu kommen, dass die Benutzer unzufrieden sind und die Softwarelösung nicht akzeptieren. So kann es z.B. sein, dass die notwendige Information zu langsam oder nur nach mühsamen und schwer zu erlernenden Interaktionen bereitgestellt wird. Eine mangelhafte Anforderungsanalyse ist oft der Grund für das Scheitern von IT-Projekten oder für die Entstehung enormer Entwicklungskosten. Wegen der großen Bedeutung der Anforderungsanalyse wurden Instrumente und Methoden entwickelt, die diese Aktivität unterstützen und unter dem Namen Requirements Engineering zusammengefasst werden. Unter Requirements Engineering versteht man das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Softwarelösungen (Fuchs et al. 2002). Eine der wichtigsten Techniken des Requirements Engineerings zum Erfassen von funktionalen Systemanforderungen ist die Erstellung von Use CaseDiagrammen (Anwendungsfalldiagrammen) (OMG 2007). Use Case- Diagramme erlauben funktionale Systemanforderungen in graphischer Form und aus Endbenutzersicht zu modellieren. In einem Use Case-Diagramm werden Akteure abgebildet, die mit dem betrachteten System interagieren. Akteure können sowohl menschliche Benutzer wie auch andere Systeme sein. Die Use Cases beschreiben auf abstrakter Ebene die Funktionen, welche das betrachtete System diesen Akteuren zur Verfügung stellt. Sie sind weitgehend technologieunabhängig, abstrakt, generalisiert und vereinfacht. Deshalb können Use Case-Diagramme auch übergreifend über mehrere Phasen des Entwicklungsprozesses eingesetzt und von unterschiedlichen Personengruppen (Analytiker, Anwender, Programmierer) benutzt werden.

4.5.1.2 Systementwurf Nachdem in der Systemanalyse beschrieben wird, was eine Softwarelösung tun soll, wird im Systementwurf gezeigt, wie die Softwarelösung dieses Ziel realisiert. Im Systementwurf werden für alle in der Systemanalyse identifizierten Funktionen

BEN-Komponenten

151

Spezifikationen erstellt. Insbesondere werden die Zerlegung der Softwarelösung in Softwarekomponenten und deren Interaktionen untereinander beschrieben. Ein Systementwurf stellt somit einen Bauplan der zu implementierenden Softwarelösung dar. Für jede Softwarelösung können jedoch mehrere Entwürfe existieren, die sich hinsichtlich Einfachheit, Effizienz, finanziellen und zeitlichen Bedingungen o.ä. unterscheiden. Zur Unterstützung des Systementwurfs existieren viele Modellierungsansätze, von denen im Folgenden zwei erwähnt werden. Mit der Datenmodellierung wird der Fokus auf die Struktur der Datenbasis eines Informationssystems gelegt. Ein weitverbreitetes logisches Modell für die Datenmodellierung auf Systemebene ist das Relationale Datenmodell (Codd 1970). Bei diesem Modell werden Informationsobjekte durch Tupel umgesetzt, die in Tabellen zusammengefasst werden. Die Tabellen können untereinander in Beziehung stehen, wenn bestimmte Tupel Bezüge zueinander haben. Für die Transformation von Entity Relationship-Informationsmodellen in relationale Datenmodelle existieren bewährte Verfahren (siehe z.B. Elmasri u. Navathe 2000); Allerdings sind die damit erzeugten Datenmodelle nur Ausgangslösungen, die z.B. zur Performance-Optimierung noch weiterentwickelt werden können oder müssen. Die Objektorientierte Systementwicklung ist sicherlich einer der wichtigsten Ansätze für die Modellierung von Softwarelösungen. Objektorientierte Ansätze kombinieren Daten und Operationen, die mit diesen Daten ausgeführt werden. Die Objektorientierung verwendet das Objekt als Grundeinheit für Systemanalyse und -entwicklung (Laudon et al. 2006). Die objektorientierte Sprache UML stellt über die bereits erwähnten Use Case-Diagramme sehr viele weitere Diagrammarten zur Verfügung, die für die Beschreibung eines Informationssystems eingesetzt werden können. So werden z.B. Aktivitäts- oder Sequenzdiagramme eingesetzt, um die Abläufe innerhalb einer Softwarelösung zu beschreiben. Im Gegensatz zu den Ablaufmodellen auf Organisationsebene enthalten die Ablaufdiagramme im Systementwurf jegliche technischen Details, die zur Software-technischen Umsetzung notwendig sind. Auch hier gibt es also – wie beim Datenmodell – wesentliche semantische Unterschiede, was als weiteres Argument für die Berechtigung einer entkoppelnden IT/Business Alignment angesehen werden kann.

4.5.2 IT-Infrastruktur-Konzeption Die IT-Infrastruktur stellt die Plattform dar, auf welche ein Unternehmen seine Informationssysteme aufbauen und betreiben kann. In diesem Zusammenhang bezeichnet der Begriff Plattform ein System, auf dem Softwarelösungen ausgeführt werden können. Meist ist damit eine Kombination von Hardware und Betriebssystem gemeint. Zur IT-Infrastruktur gehören somit Ressourcen wie z.B. Datenspeicherungs- und -verarbeitungstechnik, Kommunikationstechnik, Netzwerke, Betriebssysteme und unternehmensweite Anwendungssysteme.

152


Die physischen Geräte zur Datenspeicherung und -verarbeitung können unter dem Begriff Hardware zusammengefasst werden. Mithilfe von Kommunikationstechnik, welche physische Geräte und Software umfasst, werden Hardwarekomponenten verbunden und Daten von einer physischen Position zu einer anderen übertragen. Computer und Kommunikationsgeräte können in Netzwerke eingebunden werden, um die gemeinsame Nutzung von Daten (z.B. aus Datenbanken) und Ressourcen (z.B. Drucker) zu ermöglichen. Durch die Zunehmende Nutzung von Standards und Software zum Verbinden von heterogenen Netzwerken entstehen nicht nur unternehmensinterne Netzwerke, sondern auch gemeinsame Netzwerke kooperierender Unternehmen. Zu den Betriebssystemen auf Client-Ebene gehören sicherlich die Microsoft Betriebssysteme zu den am weitesten verbreiteten. Im Gegensatz dazu werden auf Serverseite meistens Unix oder Linux Betriebssysteme eingesetzt. Diese bilden in den meisten Ländern der Welt das Rückgrat der Unternehmensinfrastruktur, weil sie skalierbar, zuverlässig und auf vielen verschiedenen Prozessorentypen eingesetzt werden können (Laudon et al. 2006). Neben den Hardware- und Betriebssystemplattformen zählen die unternehmensweiten Anwendungssysteme sicherlich zu den wichtigsten Komponenten der IT-Infrastruktur von Unternehmen. Unernehmensweite Anwendungssysteme stellen eine fertig zusammengesetzte Sammlung von bereits entwickelten und lauffähigen Softwareprogrammen dar. Sie erlauben die Koordination von Aktivitäten und Entscheidungen im Unternehmen über verschiedene Ebenen und Geschäftseinheiten hinweg. Beispiele solcher unternehmensweiten Anwendungssysteme sind Enterprise-Resource-Planning-, Supply-Chain-Management-, oder Wissensmanagementsysteme. Die größten Anbieter hierfür sind heutzutage SAP und Oracle. Der Einsatz von unternehmensweiten Anwendungssystemen nimmt Unternehmen die Notwendigkeit ab, eigene Software für bestimmte Funktionen schreiben zu müssen. Der Aufbau und die Verwaltung einer IT-Infrastruktur stellt ein Unternehmen vor mehreren Herausforderungen, wie z.B. Management und Steuerung der ITInfrastruktur, sinnvolle Investitionen, Bewältigung von Skalierbarkeit und technischen Veränderungen.. Die Entscheidung ob die IT-Infrastruktur zentral oder dezentral gesteuert werden soll stellt oft ein immerwährender Streitpunkt in Unternehmen dar. Soll es eine zentrale Verwaltung für die Steuerung und das Management der ITInfrastruktur geben, oder sollen die einzelnen Abteilungen bzw. Geschäftsbereiche selber die Verantwortung tragen? Wie sollen die Kosten der IT-Infrastruktur auf die verschiedenen Geschäftsbereiche umgelegt werden? Dies sind alles wichtige Fragen, die jedoch die Unternehmen entsprechend ihren Bedürfnissen selber beantworten müssen. Um Entscheidungen über eine sinnvolle Investition der IT-Infrastrtuktur treffen zu können, müssen Fragen beantwortet werden, wie z.B. ob ein Unternehmen seine eigenen IT-Infrastrukturkomponenten kaufen oder diese von externen Anbie-

BEN-Komponenten

153

tern mieten soll, oder ob Standardsoftware eingesetzt oder eigene individuelle Software gebaut werden soll. Auch muss ein klarer Plan bestehen für die Bewältigung von Infrastrukturveränderungen, die sowohl durch technischen Veränderungen als auch durch Veränderungen im Unternehmen selber (wie z.B. Wachstum des Unternehmens) einhergehen können. Im Zusammenhang mit der IT-Infrastruktur ist jedoch festzuhalten, dass es in BEN nicht auf die Gestaltung der IT-Infrastruktur ankommt. Die wichtigste Aufgabe in BEN bezüglich der IT-Infrastruktur besteht in der Erfassung und Zuordnung von IT-Infrastrukturressourcen zu den in den höheren Ebenen entwickelten Geschäftslösungen.

5 Werkzeugunterstützung für die Analyse und Gestaltung von Geschäftslösungen Bettina Gleichauf

In den vorangehenden Kapiteln wurden Gegenstand, Methodik und Komponenten von BEN beschrieben. Ergänzend dazu soll in diesem Kapitel nun die Anwendung von Werkzeugen für die Analyse und Gestaltung von Geschäftslösungen behandelt werden. Grundsätzlich sind der vorgestellte Ansatz von BEN sowie die BENKomponenten unabhängig von einem Werkzeug. Dennoch ist der Einsatz von Werkzeugen für Gestaltungsaufgaben häufig sinnvoll, wie in Abschnitt 5.1 erläutert wird. Nachdem in Abschnitt 5.2 die wesentlichen Anforderungen an eine Werkzeugunterstützung erläutert werden, folgt die Beschreibung des Werkzeugs ADOben als ein Beispiel für die Unterstützung der BEN-Methode in Abschnitt 5.3. Abschließend wird in Abschnitt 5.4 die Umsetzung der BEN-Methode im Detail vorgestellt.

5.1 Die Rolle von Werkzeugen für die Analyse und Gestaltung von Geschäftslösungen Werkzeuge unterstützten generell die Modellierung, Speicherung, Darstellung und Weiterentwicklung von Modellen (Braun 2007). Im Kontext von BEN ist der Einsatz von Werkzeugen sinnvoll, weil die Ergebnisdokumente der Methodenanwendung, d. h. die Ergebnisdokumente, abgelegt und somit für eine Weiterverwendung und Wiederverwendung verfügbar gemacht werden. Ein Werkzeugeinsatz ist dann sinnvoll, wenn die Geschäftslösung komplex ist oder (Teil-)Ergebnisse wieder verwendet werden sollen. Ein Beispiel für Wiederverwendung ist die Zieldefinition auf Strategieebene, die Auswirkungen auf verschiedene Unternehmensbereiche und die dort notwendigen Neugestaltungen der Aufbauorganisation hat. Wird die Zieldefinition mit Hilfe eines Werkzeugs modelliert und abgelegt, kann sie von den einzelnen Unternehmensbereichen für die Ableitung der organisatorischen Veränderungen genutzt werden. Zur Unterstützung von Gestaltungsprojekten können Projektwerkzeuge zum Einsatz kommen. Diese unterstützen die Anwendung der gewünschten Projektmanagementmethode durch Abbildung des Vorgehensmodells und Funktionalitäten für die Projektdokumentation und das Projektmanagement. Da im Rahmen von BEN jedoch die Gestaltungsarbeit im Fokus steht, reichen Projektwerkzeuge nicht aus, um die Anwendung der BEN-Komponenten zu unterstützen.


156

Die Rolle von Werkzeugen für die Analyse und Gestaltung von Geschäftslösungen

Häufig werden einfache Visualisierungswerkzeuge (wie z. B. Microsoft Visio oder PowerPoint) genutzt, um Modelle von Prozessen, Organisationen oder ITSystemen darzustellen. Visualisierungswerkzeuge können die Gestaltung und komplexer Geschäftslösungen jedoch nicht optimal unterstützen, da sie dafür keine spezifischen Funktionalitäten (z. B. entsprechende Modelltypen) bereitstellen. Da keine Semantik hinter den Modellen liegt, sind beispielsweise keine Konsistenzprüfungen und keine Analysen möglich. Für Anwendungsgebiete wie Prozessmodellierung, Prozesssimulation, ITArchitekturmanagement, Softwareentwicklung, Strategieableitung oder Unternehmensarchitekturmanagement wurden in den letzten Jahren zahlreiche Modellierungswerkzeuge entwickelt. Ziel ist jeweils, die Komplexität der Anwendungsgebiete durch Dokumentation der Modelle zu reduzieren bzw. handhabbar zu machen. Beim Entwurf von Geschäftsprozessen ist das Ziel die Darstellung der Aufbau- und Ablauforganisation sowie die Dokumentation und Publikation der Ergebnisse. Die meisten Werkzeuge bieten jedoch keine (oder nur rudimentäre) Unterstützung konkreter Vorgehensmodelle oder Methoden. Beispiele für diese Werkzeug sind das ARIS Toolset von IDS Scheer und ADONIS der BOC AG (Junginger et al. 2000). Für den Anwendungsbereich Unternehmensarchitektur existieren zahlreiche Werkzeuge. Eine Übersicht und einen Vergleich liefert findet sich in (James 2008). Modellierungswerkzeuge können nicht nur die Erstellung, Speicherung und Weiter- bzw. Wiederverwendung von Ergebnisdokumenten unterstützen, sondern auch standardisierte (z. B. parametrisierbare) Analysen bereitstellen. In Anlehnung an Niemann (Niemann 2005), der Analysen für Unternehmensarchitekturmanagement klassifiziert, lassen sich für Geschäftslösungen folgende Analysen unterscheiden: • •

•

•

Abhängigkeitsanalysen beantworten Fragestellungen nach den Zusammenhängen zwischen verschiedenen Teilen von Geschäftslösungen Konformitätsanalysen können eingesetzt werden, um festzustellen, ob und wie stark geltende Standards oder Richtlinien bei der Gestaltung von Geschäftslösungen befolgt werden. Abdeckungsanalysen untersuchen, wie hoch der Grad der Abdeckung zwischen unterschiedlichen Strukturen ist (z. B. IT-Unterstützung von Geschäftsprozessen, IT-Unterstützung von Produkten). Hierbei können auch Artefakte der Business/IT Alignment-Ebene als Grundlage für die Analyse dienen. Komplexitätsanalysen geben Hinweise auf die Komplexität von (Teil-)Geschäftslösungen. Hierbei kann als Annäherung auf Metriken zur Messung der inneren Komplexität von Softwaresystemen zurückgegriffen werden. So errechnet beispielsweise die McCabe-Metrik die Komplexität an Hand der Anzahl der Knoten und Kanten im zu Grunde liegenden Graphen (McCabe 1976).

Werkzeugunterstützung für die Analyse und Gestaltung von Geschäftslösungen

•

•

•

157

Mit Hilfe von Kosten- und Nutzenanalysen können Geschäftslösungen auf ihre Wirtschaftlichkeit hin untersucht werden. Die Erhebung der Kosten kann sich dabei schwierig gestalten, weil sehr unterschiedliche Kostenarten, z. B. Personalkosten, Prozesskosten, IT-Beschaffungskosten, mit einbezogen werden, die teilweise nur schwierig zu beziffern sind. Für die Bewertung des Nutzens existieren verschiedene Ansätze, die u. a. bei Niemann (Niemann 2005) vorgestellt werden. Schnittstellenanalysen decken auf, ob die Schnittstellen zwischen Applikationen oder Systemen den fachlichen Schnittstellen bei Produkten und Geschäftsprozessen entsprechen. Heterogenitätsanalysen dienen dazu, bei IT-Artefakten die Anzahl unterschiedlicher Entwicklungsprozesse, Systemkomponenten oder eingesetzten Technologien aufzudecken. Analog können für fachliche Strukturen die Heterogenität der Partner im Geschäftsnetzwerk oder die Heterogenität von Geschäftsprozessen und Leistungsbündeln analysiert werden.

Der Einsatz eines Modellierungswerkzeugs zur Unterstützung von Methoden wie BEN kann umfassend, teilweise oder auch gar nicht sinnvoll sein. Beispielsweise können Diskussionen zwischen unterschiedlichen Stakeholdern durch Werkzeuge zwar unterstützt werden, diese jedoch nicht ersetzen. Dies ist häufig dann der Fall, wenn die zu verarbeitenden Informationen wenig strukturiert sind. Darüber hinaus schränkt die Nutzung eines Werkzeugs die menschliche Kreativität und damit potenzielle Gestaltungsoptionen mehr oder minder stark ein. Ein Workshop, in dem Flipcharts und Brainstormingtechniken eingesetzt werden, kann insbesondere zu Beginn eines Gestaltungsprojektes, wenn es um Ideensammlung geht, zielführender sein als die Dokumentation in einem Werkzeug. Werkzeuge sind außerdem häufig auf bestimmte Methodenansätze beschränkt, so dass eine ganzheitliche Unterstützung der Analyse und Gestaltung von Geschäftslösungen oft nicht möglich ist. Ein kritischer Punkt bei Werkzeugeinsatz ist der Aufwand, der durch die Einführung eines Werkzeugs sowie damit verbundene Anpassungen und Schulungen für die Werkzeugnutzenden entsteht. Bei kleineren Projekten ist dieser Aufwand ggf. nicht vertretbar. Dasselbe gilt für den Vorteil der Wiederverwendung: Bei wenig Weiter- oder Wiederverwendungspotential, wenn beispielsweise sehr spezielle Teile von Geschäftslösungen gestaltet werden, kann der Mehraufwand, der durch die Werkzeugnutzung entsteht, u. U. nicht gerechtfertigt sein. Ein Beispiel für ein solches Gestaltungsprojekt ist die für eine begrenzte Zeit notwendige Umstrukturierung eines Kundenanspracheprozesses für eine spezielle Marketingkampagne. Es ist davon auszugehen, dass diese Umgestaltung nur einen kleinen Ausschnitt einer Geschäftslösung betrifft, so dass es angebrachter wäre, mit Visualisierungswerkzeugen oder Textdokumentationen zu arbeiten.

158

Anforderungen an die Werkzeugunterstützung betriebswirtschaftlicher Konstruktion

5.2 Anforderungen an die Werkzeugunterstützung betriebswirtschaftlicher Konstruktion Die strukturelle Beschreibung der BEN-Komponenten stellt die Grundlage für die Konstruktion von Geschäftslösungen dar. Die Anwendung der BENKomponenten für Gestaltungs- und Analysezwecke erfordert von einem entsprechenden Werkzeug jedoch die Bereitstellung bestimmter Funktionalitäten. Dabei kann zwischen generellen, Technologie-bezogenen, Modellierungs-bezogenen und Projektunterstützungs-bezogenen Anforderungen differenziert werden. Generell sollte das Werkzeug auf einem integrierten Metamodell basieren, um die Konsistenz der verschiedenen Modelle auch in komplexen Geschäftslösungen sicherzustellen. Dieses Metamodell sollte darüber hinaus anpassbar an die genutzte Methode sein. Im Fall von BEN sollte dementsprechend das BEN-Metamodell zu Grunde liegen bzw. das Metamodell an das BEN-Metamodell angepasst werden können. Für die Überprüfung der Konsistenz zwischen den erstellten Modellen sollten entsprechende Mechanismen vorhanden sein. Durch eine Klassifikation, z. B. durch semantische Attribuierung der Modelle, kann ein Werkzeug die Wiederverwendung unterstützen. Zu den generellen Anforderungen zählt auch eine benutzerfreundliche Bedienungsoberfläche, welche die Einarbeitung der Anwender erleichtert. Aus technischer Sicht sind eine verteilte Architektur, Schnittstellen sowie die Konfigurierbarkeit wichtige Anforderungen an die Werkzeugunterstützung. Um eine kollaborative Modellierung und die Einbindung unterschiedlicher Nutzergruppen zu ermöglichen, sollte das Werkzeug auf einer verteilten Architektur basieren und z. B. Zugriff über eine Weboberfläche ermöglichen. Schnittstellen zu bestehenden Systemen, die Daten für die Gestaltung von Geschäftslösungen bereitstellen, z. B. CMDB, Prozessmanagementwerkzeuge oder Strategietools, können wertvollen Input für die Entwicklung neuer Geschäftslösungen liefern. Hinsichtlich der technologischen Realisierung sollte das Werkzeug möglichst plattformunabhängig und flexibel konfigurierbar sein. Hinsichtlich der Modellierungsunterstützung erfordern die meist komplexen Modelle der Geschäftslösungen ausgereifte Modellierungs-, Navigations- und Analysemechanismen. Dabei ist jedoch zu beachten, dass umfassende Geschäftslösungen meist von mehreren Stakeholdern bearbeitet werden, die unterschiedliche Ansprüche, Vorstellungen und Interessen haben. Für Veränderungsprojekte im Sinne des Business Engineering haben Baumöl und Winter (Baumöl u. Winter 2003) Rollen und Aufgaben der Beteiligten beschrieben: •

•

Treiber und Unterstützer initiieren die (Neu-)Gestaltung der Geschäftslösungen. Um einen politischen Rückhalt des Veränderungsprojektes zu gewährleisten, sollte diese Rolle durch ein Mitglied der Geschäftsleitung eingenommen werden. Architekten gestalten den Veränderungsprozess aus einer ganzheitlichen Sicht, d. h. setzen Ziele, machen Vorgaben über die Zielerreichung, pla-


• •

159

nen Ressourcen, prüfen Ergebnisse, berichten an die Treiber und Unterstützer und führen den Veränderungsprozess. Implementierer setzen die Veränderungen um und verfügen dazu über eine hohe fachliche Kompetenz. Bewahrer und Entwickler leben die neue Geschäftslösung nach der Umsetzung. Sie überprüfen sie und treiben eventuell notwendige Anpassungen im Nachgang.

Nach der Theorie des „Cognitive Fit“ sollte die Darstellung der für eine Aufgabe benötigten Informationen an die Aufgabe angepasst sein, um möglichst gute Ergebnisse zu erzielen (Vessey u. Galletta 1991). Für ein Werkzeug zur Unterstützung der Gestaltung und Analyse von Geschäftslösungen bedeutet dies, dass Modelldarstellungen und Analyseergebnisse an den verschiedenen Aufgaben der unterschiedlichen Nutzertypen ausgerichtet sein sollten. Auch sollten den verschiedenen Stakeholdern unterschiedliche, auf die jeweiligen Informationsbedarfe zugeschnittenen Abfrage- und Auswertungstypen angeboten werden. Die Herausforderung, verschiedenen Stakeholdern gerecht zu werden, ist aus der Software-Entwicklung bekannt. „Separation of Concerns“ bezeichnet ein Entwurfsprinzip für die für die Entwicklung komplexer Software-Systeme (vgl. Dijkstra 1982). Das Prinzip wird in der Programmierung, aber auch im Bereich der Modellierung der Unternehmensarchitektur verwendet (ter Doest et al. 2004; Kurpjuweit 2009). Die Grundidee des Separation of Concerns besteht darin, die Beschreibung eines Systems in Sichten aufzuteilen. Jede Sicht beschreibt dabei einen oder wenige Aspekte (Concerns) des Gesamtsystems. Idealerweise kann jede Sicht mit keinen oder nur wenigen definierten Abhängigkeiten zu anderen Sichten verstanden, entworfen und optimiert werden. Ein Concern umfasst dabei einen Aspekt von besonderem Interesse („matter of interest“) und beschreibt üblicherweise die Interessen eines Stakeholders oder einer Stakeholder-Gruppe des Systems. Ein Viewpoint erfasst den Interessensbedarf der Stakeholder und definiert eine Beschreibung eines Systems aus dieser spezifischen Sicht (Kurpjuweit u. Winter 2007). Die Ableitung der BEN-Komponenten aus eng zusammenhängenden Modelltypen entspricht in einer abgewandelten Form dem Prinzip des Separation of Concerns, da die Aufteilung z. B. nach der Aufgabe der Leistungsdefinition zur Abgrenzung einer BEN-Komponente führt. Folglich sollte ein Werkzeug zur Unterstützung betriebswirtschaftlicher Konstruktion den Entwurfsansatz des Separation of Concerns berücksichtigen und durch die Definition von Viewpoints verschiedene Sichten auf die zu gestaltende Geschäftslösung ermöglichen. Darüber hinaus sollte beachtet werden, dass die verschiedenen Stakeholder auch unterschiedliche Navigationspfade zwischen den unterschiedlichen Sichten benötigen. Um die Gestaltung neuer Geschäftslösungen als Veränderungsprojekt unterstützen zu können, sollte ein entsprechendes Werkzeug auch Projektunterstützungsfunktionalitäten bereitstellen. Zunächst sollte das Werkzeug mit bestehenden Projektmanagement-Tools integriert sein, um die Einhaltung der definierten Vor-

160

ADOben als Beispiel für ein Werkzeug zur Unterstützung der BEN-Methode

gehensweise und Zeitpläne sicherzustellen. Da im Laufe des Veränderungsprojekts unterschiedliche Entwürfe entstehen können, muss das Werkzeug zeitliche Versionierung, Variantenbildung und Historisierung der entworfenen Modelle ermöglichen. Entsprechend der o. g. Stakeholder, die gemeinsam am Entwurf der Geschäftslösung arbeiten, muss das Werkzeug die Rollenmodelle und Verantwortlichkeiten abbilden und diese in einem Autorisierungskonzept abbilden. Unterschiedliche Rollen sollten dabei entsprechend ihrer Aufgabe Rechte für das Anlegen, Lesen, Modifizieren und Löschen von Modellen erhalten.

5.3 ADOben als Beispiel für ein Werkzeug zur Unterstützung der BEN-Methode 5.3.1 Abgrenzung von BEN und ADOben Wie in Kapitel 1.2 erläutert, umspannt BEN einen sehr weiten Fokus, der die Dokumentation, Analyse und Neu- bzw. Umgestaltung von Geschäftslösungen beinhaltet. Da ein Werkzeug, welches Gestaltung unterstützt, jedoch immer Spezifika hinsichtlich der Modellierung berücksichtigen muss, kann es kaum breit und spezifisch zugleich sein. Aus diesem Grund kann ein bestimmtes Werkzeug nur Teile von BEN abdecken. Im den folgenden Abschnitten wird das Werkzeug ADOben vorgestellt, das wichtige Teile der BEN-Methode unterstützt. Kerneinsatzgebiet der Werkzeugs ADOben ist die Unterstützung des Unternehmensarchitekturmanagements. Unter dem Begriff Unternehmensarchitektur wird die formale Beschreibung der Grundstrukturen einer Organisation, ihrer Komponenten und deren Beziehungen, sowie die dafür notwendigen Entwicklungsprozesse und Gestaltungsprinzipien verstanden (The Open Group 2009). Die modellhafte Erfassung dieser Strukturen, ihrer Komponenten und deren Beziehungen untereinander erfolgt in einem Unternehmensarchitekturmodell. ADOben unterstützt nicht primär die Gestaltung, sondern vor allem die Dokumentation und Analyse von Geschäftslösungen und stellt dafür entsprechende Mechanismen und Auswertungsmöglichkeiten bereit. ADOben realisiert somit Teile von BEN, aber auch Teile von Veränderungsmanagement. Abb. 75 visualisiert die Abgrenzung von BEN und ADOben hinsichtlich ihrer Fokussierung. Aus der unterschiedlichen Fokussierung von BEN und ADOben folgt, dass ADOben nicht alle BEN-Komponenten unterstützt, wie sie in den Kapiteln 2 bis 4 beschrieben werden. Gleichzeitig beinhaltet ADOben spezielle Funktionalitäten, die für das Unternehmensarchitekturmanagement wichtig sind, jedoch für BEN nicht relevant sind. Die letzteren ADOben-Funktionalitäten werden in diesem Kapitel nicht thematisiert.


161

Abb. 75. Fokussierung BEN und ADOben

5.3.2 Übersicht des Architektur- und Modellierungsansatzes von ADOben ADOben ist auf der Metamodellierungsplattform ADONIS der BOC AG implementiert. Der in diesem Buch beschriebene Funktionsumfang von ADOben entspricht dem Release 1.0. Die ADONIS-Plattform basiert auf einem methodenunabhängigen Metamodellierungskonzept, das unterschiedliche Funktionalitäten für die Definition eines bestimmten Metamodells bereitstellt. Das zugrunde liegende Metamodell von ADOben ist eine Adaption des BEN-Metamodells (vgl. Kapitel 2.1). Sämtliche Ebenen sowie die Beziehungen innerhalb und zwischen den Ebenen des Business Engineering Frameworks sind folglich mittels ADOben gestaltbar. Zur Modellierung von Geschäftslösungen stellt ADOben auf Basis des Metamodells verschiedene Modelltypen zur Verfügung. Der Modellierer wird somit in der Erstellung und Pflege von grafischen (Teil-)Modellen unterstützt. Die Modelle bestehen aus grafischen Elementen, die innerhalb der Modelle entweder über spezielle Konnektoren (Verbindungselemente, z. B. Pfeile oder Aggregationsfelder) oder durch grafische Anordnung miteinander in Verbindung gesetzt werden können. Darüber hinaus sind Beziehungen zwischen verschiedenen Modelltypen durch Referenzen modellierbar. Eine Beschreibung der Modellierungsmechanismen erfolgt im folgenden Abschnitt. Um die Kommunikation mit Modellnutzern, d. h. Stakeholdern, zu erleichtern, werden für Modellerstellung und Modellnutzung die gleichen grafischen Elemente verwendet. Gleichzeitig ist jedoch eine Stakeholder-orientierte Bildung von Sich-

162


ten möglich, indem Analysen auf bestehende Modelle die jeweils relevanten Informationen auslesen, verdichten und in übersichtlicher Form mit Hilfe sogenannter „grafischer Auswertungen“ präsentieren (vgl. dazu Abschnitt 5.4.2). Diese Analysen werden in Form von Fragestellungen vorab definiert und können dann im Werkzeug umgesetzt werden. Die Modellierung in ADOben erfolgt mit Hilfe von ADOben-Modelltypen. Diese unterscheiden sich teilweise von den bereits vorgestellten BEN-Modelltypen. Dies liegt an der bereits beschriebenen unterschiedlichen Ausrichtung von ADOben als Unternehmensarchitekturwerkzeug und BEN als betriebswirtschaftlichem Konstruktionsansatz. Die ADOben-Modelltypen repräsentieren jedoch einen Großteil der Ergebnisdokumenteder BEN-Komponenten und ermöglichen somit die Modellierung von Geschäftslösungen entsprechend der BEN-Methode.

5.3.3 Modellierung in ADOben Anlegen von Modellen Der Modelleditor in ADOben dient zur grafischen Erstellung von Modellen. Er bietet unterschiedliche Ansichtsoptionen sowie Navigationsmöglichkeiten zwischen den unterschiedlichen Modellen. Jedes Modell wird in einem eigenen Modellfenster dargestellt und enthält je nach Modelltyp unterschiedliche grafische Elemente. Grafische Elemente können Objektklassen oder Konnektorklassen instanziieren. Instanzen von Objektklassen dienen dabei zur Darstellung von Modellelementen wie Prozessen, Personen oder Daten. Instanzen von Konnektorklassen (z. B. Pfeile) haben die Funktion, Modellelemente zu verbinden und somit die Semantik von Beziehungen zu modellieren. In einigen Fällen kann die Beziehung zwischen Instanzen von Objektklassen auch durch die grafische Anordnung auf der Modellierungsfläche bestimmt werden. Beispielsweise kann die Zuordnung zwischen einem Prozess und der Organisationseinheit, der den Prozess ausführt, durch Platzieren des Prozess-Modellelements innerhalb des Modellelements zur Darstellung der Organisationseinheit erfolgen. Beim Anlegen eines neuen Modells erscheint zunächst ein Dialog, welcher die einzelnen Modelltypen anzeigt (siehe Abb. 76). Nachdem ein zu modellierender Modelltyp ausgewählt wurde, wechselt die Ansicht zur Modellierungsoberfläche. In einer Toolbox werden die zur Verfügung stehenden Notationselemente angezeigt (linker Teil in Abb. 77). Diese können durch Auswählen und Ablegen auf der Modellierungsfläche (rechter Teil in Abb. 77) platziert werden. Die Attributwerte der Modellelemente werden über einen Attributdialog, das sogenannte Notebook, festgelegt, das über einen Doppelklick auf das entsprechende Modellelement geöffnet werden kann. Dort könnten entsprechend der Festlegungen des Metamodells Attributwerte für das entsprechende Modellelement erfasst werden. Attributtypen sind beispielsweise Text, Zahlen, Auflistungen


163

oder Referenzen auf andere Modelle oder Modellelemente. Abb. 78 zeigt das Beispiel-Notebook einer Leistungskomponente „Marketing“, die durch die Attribute Name (Attributtyp Text), Beschreibung (ebenfalls Attributtyp Text), Leistungsart (Attributtyp Optionsauswahl) sowie Referenzierte Produkte (Attributtyp Referenz) beschrieben wird.

Abb. 76. Dialog Modell anlegen

164


Abb. 77. Modellierungsoberfläche mit Toolbox

Abb. 78. Notebook Leistungskomponente

Anlegen von Referenzen Verbindungen zwischen Modellen werden durch modellübergreifende Referenzen abgebildet. Diese bieten die Möglichkeit, von einem Element eines Modells auf andere Modelle oder Elemente in anderen Modellen zu referenzieren. Im Folgenden werden die beiden Arten von Referenzen in ADOben erläutert.


165

Referenz Typ 1: Referenz auf andere Modelle Die Gestaltung der Prozessarchitektur kann beliebig granular vorgenommen werden (vgl. Abschnitt 5.3). Bei der Modellierung mit ADOben wird dies ermöglicht, indem Modelle des Modelltyps Prozesslandkarte auf andere Prozesslandkarten referenzieren können. Dadurch können für die verschiedenen Verfeinerungsstufen der Prozessarchitektur getrennte Modelle entwickelt und durch Referenzen aufeinander verbunden werden. Abb. 79 zeigt das Notebook des Prozesses „Unternehmensstrategie entwickeln“, welcher in einem weiteren Prozessmodell (Fenster rechts unten) verfeinert wird. Durch die Referenz im Attribut „Besteht aus folgenden Teilprozessen“ wird das verfeinerte Modell „Strategie entwickeln“ des Modelltyps Prozesslandkarte verbunden. Derselbe Mechanismus kann für die Verfeinerung von Produktmodellen verwendet werden.

Abb. 79. Modellreferenz: Verfeinerung von Prozessen

166


Abb. 80. Modellelementreferenz: Geschäftsfeld und Organisationseinheit

Referenz Typ 2: Referenz auf andere Modellelemente In einem Geschäftsnetzwerkmodell werden Geschäftsfelder des eigenen Unternehmens in ihrem Zusammenhang mit externen Geschäftspartnern abgebildet. Das Geschäftsfeld kann dabei einer Organisationseinheit zugeordnet werden, die im Modell Aufbauorganisation modelliert ist. Zu diesem Zweck wird im Notebook des Modellelements Geschäftsfeld im Attribut „Organisationseinheit“ eine Referenz auf das entsprechende Modellelement in einem Modell des Modelltyps Aufbauorganisation angelegt. Abb. 80 zeigt das im Geschäftsnetzwerkmodell angelegte Geschäftsfeld „Individualreisen“ und die Verknüpfung mit der Organisationseinheit „Anbieterwerbung“ aus dem (im Fenster unten rechts angezeigten) Aufbauorganisationsmodell. Die Modellelementreferenz wird auch dazu genutzt, um verschiedene Sichten auf dieselben Modellelemente zu erstellen. Zum Beispiel werden im Modell Prozesslandkarte einmalig Prozesse modelliert und mit Attributen beschrieben. Um den Informationsfluss zwischen den Prozessen darzustellen, werden in einem Modell des Modelltyps Informationslandkarte ebenfalls Modellelemente zur Darstellung von Prozessen angelegt. Diese Modellelemente bestehen aber lediglich aus einer Referenz auf ein Prozesselement in einer Prozesslandkarte (siehe Abb. 81).


167

Abb. 81. Modellelementreferenz: Referenzierter Prozess in einer Informationslandkarte

Organisation von Modellen Die existierenden Modelle werden in ADOben im sogenannten Modellexplorer in einer Baumstruktur angezeigt. ADOben ermöglicht mit Hilfe einer flexiblen Ordnerstruktur das strukturierte Ablegen von Modellen. Dadurch können auch mehrere BEN-Projekte parallel verwaltet werden. Die frei wählbare Benennung der Modellordner ermöglicht eine Strukturierung der Modelle nach unterschiedlichen Gesichtspunkten, z. B. nach den Ebenen des Business Engineering Framework. Aber auch eine Strukturierung nach unterschiedlichen Teillösungen ist denkbar, um beispielweise alternative Modelle für Geschäftslösungen, d. h. Varianten, abzulegen. Die Variation der Modelle kann außerdem durch eine entsprechende hierarchische Verschachtelung der Modellordnerstruktur ausgedrückt werden. Bei der Gestaltung von komplexen Geschäftslösungen kommt es vor, dass im Laufe eines Gestaltungsprojekts verschiedene Versionen von Modellen entstehen. Da ein Werkzeug üblicherweise auch für die Dokumentation bereits konstruierter (und implementierter) Modelle eingesetzt wird, ist die Entwicklung solcher Modelle über mehrere Versionen ein zentraler Vorteil der Werkzeugunterstützung. ADOben sieht vor, jedes Modell mit einer Versionsnummer zu versehen, welche hinsichtlich ihrer Nummerierung wiederum frei wählbar ist. Dadurch können Modelle mit demselben Namen in unterschiedlichen Versionen existieren. Die Versionsnummer wird neben dem Modellnamen in der Liste der Modelle angezeigt. Abb. 82 zeigt das Beispiel eines Modellexplorers, in dem für das Modell „Geschäftsnetzwerk smartTravel AG (gesamt)“ zwei unterschiedliche Versionen 1.0 und 2.0 existieren.

168

Umsetzung von BEN mit Hilfe von ADOben

Abb. 82. Modellexplorer mit Modellordnerstruktur

5.4 Umsetzung von BEN mit Hilfe von ADOben 5.4.1 Umsetzung der BEN-Komponenten in ADOben Wie bereits erläutert, deckt ADOben nur einen Teil von BEN ab. Dementsprechend ist auch das ADOben-Metamodell, auf dem die Werkzeugfunktionalitäten und die nutzbaren Modelltypen basieren, nicht identisch mit dem in Abschnitt 2.1 beschriebenen BEN-Metamodell. Neben einigen geringfügen Umbenennungen der Metamodellelemente sowie zum Teil vereinfachter Beziehungsgeflechte bestehen die Unterschiede insbesondere im Bereich IT-Infrastruktur. Auf Grund des traditionellen Schwerpunkts der Unternehmensarchitektur in der IT-Architektur ist das ADOben-Metamodell hinsichtlich Applikationskomponenten und Informationstechnik-Komponenten (BEN-Metamodellelemente) weitaus detaillierter als das BEN-Metamodell. Auf eine detaillierte Beschreibung des ADOben-Metamodells soll an dieser Stelle verzichtet und der Schwerpunkt auf die Beschreibung der Umsetzung der BEN-Komponenten gelegt werden. Abb. 83 zeigt, welche BEN-Komponenten (äußere Rechtecke) durch welche ADOben-Modelltypen (innere Rechtecke) realisiert werden. Hier spiegelt sich wider, dass das ADOben-Metamodell auf IT-Ebene mehr Modelltypen anbietet, als


169

dies die BEN-Beschreibung in Kapitel 4 erfordert. In Abb. 84 sind die wichtigsten Beziehungen zwischen den ADOben-Modelltypen dargestellt. Diese können durch die bereits beschriebenen Referenzmechanismen im Werkzeug instanziiert werden.

Abb. 83. Realisierung der BEN-Komponenten durch ADOben-Modelltypen

Kategorisierung Kategorisierung

St rategieebene

Geschäftsnetzwerkmodell

Geschäftspartnerprozessmodell

Leistung

Produkte (Bestandsführung)

Ziele

Strategische Positionierung (KonfiguratorModell)

Ziellandkarte

Zielverfeinerung

Erzeugte/Konsumierte Produkte Verantwortlicher Geschäftsbereich

Organisationsebene

Prozesslandkarte

Verantwortlicher Geschäftsbereich

Aufbauorganisationsmodell

Erzeugte/ Konsumierte Informationen

Genutzte Applikationen

Informationsmodell

Informationen

Informationslandkarte

Zielvorgabe Prozesse Zielvorgabe

IT/ Business Alignment Ebene

Applikationen (Bestandsführung)

Realisierung in Software

IT-Ebene

Softwarelandkarte

Applikationen

Applikationslandkarte

Technische Umgebung Realisierung in Software

Wiederverwendbare Komponenten

Erzeugte/Konsumierte Datenobjekte

Repräsentierte Informationen

SystemSoftware

Datenmodell

Servermodell

EnvironmentModell

Installation Installation

Abb. 84. Beziehungen zwischen ADOben-Modelltypen

Die folgenden Abschnitte beschreiben im Detail die Umsetzung der BENKomponenten in ADOben. Dabei wird jeweils auf die Ergebnisdokumente der

170


BEN-Komponente eingegangen und aufgezeigt, wie diese mit Hilfe von ADOben gestaltet werden können. Leistungsdefinition Als Ergebnisse entstehen bei der BEN-Komponente Leistungsdefinition Geschäftsnetzwerkmodelle, Geschäftspartnerprozessmodelle, Produkt/ServiceModelle und Modelle der strategischen Positionierung. Ziel der gesamthaften Analyse des Leistungsaustausches (vgl. Abschnitt 4.2.1) ist es, die Beziehungen zwischen Geschäftseinheiten, Lieferanten, Kunden und Partnern und so das Zusammenwirken der betrachteten Einheit mit internen und externen Partnern zu gestalten. ADOben stellt hierfür Modellelemente für Geschäftspartner sowie Geschäftsfelder im Modelltyp Geschäftsnetzwerkmodell zur Verfügung. Leistungsaustauschbeziehungen werden dabei auf aggregierter Ebene durch Verbindungen zwischen den Modellelementen festgelegt. In den Attributen der Modellelemente können auch die verschiedenen Rollen festlegt werden, die Kunden, Lieferanten, Partner oder Mitbewerber einnehmen können (Service Integrator, Shared Service Provider, Exclusive Service Provider, Public Service). Das Attribut „Typ“ eines Geschäftspartners besteht dabei aus einer Referenz zu einem Typisierungsmodell, in dem die möglichen Rollen spezifiziert werden können. Durch die Festlegung der möglichen Ausprägungen im Typisierungsmodell ist es, im Gegensatz zur Nutzung eines einfachen Textfelds, möglich, die Geschäftspartner gemäß ihrer Rollen zu klassifizieren. In ADOben wird beispielsweise eine typenabhängige Farbgebung der Geschäftspartner im Geschäftsnetzwerkmodell unterstützt. Abb. 85 zeigt das Beispiel eines Geschäftsnetzwerkmodells in ADOben. Im Zentrum steht das zu betrachtende Unternehmen Smart Travel mit seinen Geschäftsfeldern. Links sind die Lieferanten, rechts die Kunden (gruppiert in Geschäftspartnersegmenten) abgebildet. Geschäftsbeziehungen, symbolisiert durch Pfeile, können sowohl zwischen Segmenten als auch zwischen einzelnen Geschäftspartnern auf der einen und dem Gesamtunternehmen oder einzelnen Geschäftsfeldern auf der anderen Seite modelliert werden. Im Beispiel sind die Lieferanten entsprechend ihrer Rollen im Geschäftsnetzwerk unterschiedlich eingefärbt.


171

Abb. 85. Beispiel Geschäftsnetzwerkmodell

Die Detailanalyse von Kundenbedürfnissen wird in ADOben mit dem Modelltyp Geschäftspartnerprozessmodell unterstützt. Es detailliert die Geschäftsbeziehungen des Geschäftsnetzwerks; Daher sind die beteiligten Parteien (internes) Geschäftsfeld und Geschäftspartner im Geschäftspartnerprozessmodell Referenzen auf die korrespondierenden Elemente im Geschäftsnetzwerk (vgl. Abb. 86).

172


Abb. 86. Geschäftspartner (Referenz) im Geschäftspartnerprozessmodell

Die komplexe Leistung wird in Form von Bedarfs- und Leistungskomponenten definiert, die zwischen den Parteien ausgetauscht werden. Es ist auch möglich, eine logische Reihenfolge der Austauschbeziehungen zu definieren. An dieser Stelle ist nochmals darauf hinzuweisen, dass weder BEN noch ADOben an dieser Stelle eine Prozessdarstellung im engeren Sinn vorsehen. Vielmehr liegt der Fokus auf der Gestaltung und Darstellung der ausgetauschten Leistungen mit externen Partnern und nicht auf der detaillierten Spezifikation der dynamischen Aspekte von Geschäftspartnerschaften - Letzteres erfolgt erst im Rahmen der Organisationsgestaltung im Rahmen der hier festgelegten Grundsätze. Ein Beispiel eines Geschäftspartnerprozessmodells findet sich in Abb. 87. Die Zusammenfassung des Leistungsprogramms erfolgt in ADOben in einem Bestandsmodell über alle Produkte bzw. Services hinweg, die angeboten werden. Ein Beispielmodell findet sich in Abb. 88. Der Zusammenhang zwischen Leistungsaustausch und Produkten/Services wird in ADOben repräsentiert, indem Produkte bzw. Services durch Leistungsaustauschbeziehungen im Geschäftspartnerprozessmodell referenziert werden können. Abb. 78 zeigt ein Beispiel für die Produktkomponente „Marketing“. Um die strategische Positionierung von Geschäftseinheiten und Produkten/Services festzulegen, realisiert der ADOben-Modelltyp Konfigurator einen „morphologischen Kasten“ (vgl. Abschnitt 4.2.1). Das Modell definiert für beliebige Dimensionen (z. B. Zielgruppe, Image, Markt) je eine Reihe möglicher Ausprägungen (z. B. Alleinreisen, Paarreisen, Single-Reisen). Dabei sind Dimensionen und Ausprägungen frei wählbar, da je nach Geschäftslösung unterschiedliche Inhalte denkbar sind. Die Kategorisierung des Produkt-/Serviceprogramms und der Geschäftseinheiten wird in ADOben durch einen weiteren Referenzmechanismus realisiert: Sowohl Produkten bzw. Services (Leistungsprogramm) wie auch Geschäftsfeldern (Geschäftseinheiten) können beliebig viele Ausprägungen aus dem Modell der strategischen Positionierung zugeordnet werden. Dabei ist es möglich, für Produkte bzw. Services und Geschäftsfelder dieselben Ausprägungen zuzuordnen. Abb. 89 zeigt exemplarisch das Notebook eines Geschäftsfelds, in dem Referenzen zu den gewünschten Ausprägungen (z. B. Zielgruppe „Junge Be-


173

rufstätige“ oder Inhaltliches Angebot „Kunst & Kultur“) der strategischen Positionierung hinterlegt sind.

Abb. 87. Beispiel Geschäftspartnerprozessmodell

174


Abb. 88. Beispiel Produktmodell

Abb. 89. Strategische Positionierung eines Geschäftsfelds

Zieldefinition Zentrales Ergebnis der BEN-Komponente Zieldefinition ist das Modell des Zielsystems. Die Zieldefinition strebt an, ein detailliertes, konsistentes System von strategischen Führungsgrößen zu entwickeln, das es ermöglicht, die Prozesse hinsichtlich ihrer Effizienzziele zu steuern. Der ADOben-Modelltyp Ziellandkarte zeigt die Ziele des Zielsystems mit ihren Abhängigkeiten und Wechselwirkungen. Der Modelltyp Zielverfeinerung definiert Unternehmensziele sowie deren Opera-


175

tionalisierung in Erfolgsfaktoren und Kennzahlen. Die Darstellungen entsprechen dem Konzept der Balanced Scorecard und dienen primär der modellhaften Erfassung der strategischen und operationalen Ziele im Unternehmen. Abb. 90 zeigt ein Beispiel für eine Ziellandkarte.

Abb. 90. Beispiel Ziellandkarte

Prozessgestaltung Die Ergebnistypen der BEN-Komponente sind Prozesslandkarten sowie ProzessAblaufmodelle, die auch Prozessführung und Outputqualität spezifizieren. In ADOben erfolgt die Prozessarchitekturplanung mit dem Modelltyp Prozesslandkarte, in dem Modellelemente für Prozesse aggregierter Form angelegt werden. Da die Gestaltung der Geschäftslösung mit BEN darauf abzielt sicherzustellen, dass die spezifizierten Leistungen erbracht und die Steuerungsziele beachtet werden, bietet ADOben zahlreiche Attribute für Prozesse an. Im Attribut „Zielsystem“ kann auf strategische Führungsgrößen aus der Zielverfeinerung, im Attribut „behandelte Produkte“ auf Produkte aus dem Produktmodell referenziert werden. Abb. 91 und Abb. 92 zeigen Beispiele dieser Referenzen.

Abb. 91. Referenz zu Zielen, die ein Prozess unterstützt

176


Abb. 92. Referenz zu Produkten, die ein Prozess behandelt

Die Abbildung einer komplexen Prozessarchitektur im ADOben orientiert sich am „Process Compass“ von Malone, Crowston et al. (1999) (vgl. Abb. 93). Dieser unterscheidet auf der vertikalen Dimension den Detaillierungsgrad und auf der horizontalen Dimension den Spezialisierungsgrad eines Prozesses. In der vertikalen Dimension reicht das Spektrum von hochaggregierten Prozesslandkarten, die nur die zentralen Prozesse ohne spezifizierte Abläufe darstellen, bis hin zu detaillierten Prozessablaufdarstellungen. In der horizontalen Dimension kann zwischen generalisierten, z. B. branchenneutralen Prozessdarstellungen, branchenspezifischen Spezialisierungen und schließlich stark spezialisierten, z. B. unternehmens- oder bereichsspezifischen Prozessmodellen unterschieden werden.

Abb. 93. Beispiel für Process Compass


177

ADOben realisiert das Konzept des Process Compass durch mehrere Modelle des Modelltyps Prozesslandkarte, die aufeinander referenzieren. Die Attribute „besteht aus folgenden Teilprozessen“ und „wird spezialisiert durch folgende Prozesse“ ermöglichen die Gestaltung einer komplexen, zweidimensionalen Prozessarchitektur, in der zwischen Prozessmodellen verschiedener Aggregations- und Spezifitätsgrade navigiert werden kann. Die Dimensionen Dekomposition/Aggregation sowie Spezialisierung/Generalisierung werden im Modell Prozesslandkarte mit verschiedenen Symbolen visualisiert: Wie in Abb. 94 dargestellt, wird das Vorhandensein einer Spezialisierung durch einen Pfeil nach rechts angezeigt (z. B. beim Prozess „Kundengewinnung und –Beziehungsmanagement“), während das Vorhandensein eines Teilprozesses (z. B. beim Prozess „Unternehmensstrategie entwickeln“) durch einen Pfeil nach unten angezeigt wird. Durch Klick auf die Pfeile wird der Nutzer auf die Prozesslandkarten weitergeleitet, in denen die Spezialisierung bzw. Dekomposition des jeweiligen Prozesses modelliert ist. Durch sog. „Aggregationsflächen“ können die Prozesse einer Prozesslandkarte zusätzlich kategorisiert werden. So kann, wie in Abb. 94, z. B. zwischen Leistungs-, Führungs- und Unterstützungsprozessen (letztere sind in Abb. 94 nicht abgebildet) unterschieden werden.

Abb. 94. Prozesslandkarte mit spezialisierten und detaillierten Prozessen

Aufgrund der starken Orientierung an Architekturmanagement werden Leistungsanalyse und Ablaufplanung in ADOben nicht unmittelbar unterstützt. Die BEN-Modelltypen Prozessleistungsmodell und Ablaufmodell werden folglich nicht realisiert. Das Werkzeug erlaubt nur Prozesse, nicht jedoch Aktivitäten und

178


deren Abhängigkeiten abzubilden. Reihenfolgebeziehungen zwischen Prozessen können jedoch abgebildet werden, auch wenn diese Beziehungen keine weitere semantische Bedeutung haben. Aufbauorganisationsgestaltung Die BEN-Komponente Aufbauorganisationsgestaltung erzeugt Strukturmodelle für Rollen, Stellen und Organisationseinheiten. Aus der Prozessarchitekturplanung und der damit verbundenen Identifikation von Prozessen können Verantwortlichkeiten abgeleitet und Geschäftsbereichen zugeordnet werden. Der ADObenModelltyp Aufbauorganisationsmodell ermöglicht die Strukturierung von Organisationseinheiten sowie die Definition von Stellen, Rollen bis hin zu einzelnen Personen. Im Ergebnis können Organigramme mit beliebig engem oder weitem Bezug erstellt werden. Gleichzeitig können auch unterschiedliche Sichten auf Teile der Aufbauorganisation entwickelt werden. Durch eine hierarchische Verfeinerung von Aufbauorganisationsmodellen ist eine nach Detaillierungsgrad getrennte Modellierung (ähnlich der Prozessarchitektur) möglich. Abb. 95 zeigt ein Beispiel einer Verfeinerung der Aufbauorganisation. Im Gesamtunternehmensmodell wird eine Organisationseinheit „IT“ modelliert. Diese wird in einem getrennten Modell verfeinert und z. B. eine Organisationseinheit „Anwendungsentwicklung“ mit verschiedenen Stellen und Rollenprofilen definiert.

Abb. 95. Beispiel Verfeinerung der Aufbauorganisation

Der Zusammenhang zwischen Ablauf- und Aufbauorganisation wird in der Prozesslandkarte (s. o.) über ein Modellelement festgelegt, das eine Referenz darstellt. Die Zuordnung der verantwortlichen Organisationseinheit zu einem Prozess


179

wird durch Platzierung auf der grafischen Modellierungsfläche festgelegt (vgl. Abb. 96). Verantwortliche Geschäftsbereiche können in Form einer Modellelementreferenz auch für Produkte angegeben werden. Darüber hinaus können in den Attributen der Prozesse im Modelltyp Prozesslandkarte auch Rollen aus dem Aufbauorganisationsmodell zugeordnet werden (vgl. Abb. 97).

Abb. 96. Verantwortliche Organisationseinheit in Prozesslandkarte

Abb. 97. Verantwortlicher Geschäftsbereich des Produkts “Städtereise“

Informationsgestaltung Das Ergebnis der BEN-Komponente Informationsgestaltung sind eine Darstellung der Zusammenhänge der Informationsobjekte in einer Informationslandkarte sowie ein detailliertes Informationsobjektmodell. In ADOben wird die Definition der Informationsobjekte, die Gestaltung der Beziehungen zwischen diesen Informationsobjekten sowie Festlegung deren Attribute im ADOben-Modelltyp Informationsmodell vorgenommen. Es können Assoziations-, Aggregations- und Generalisierungsbeziehungen zwischen Informationsobjekten definiert werden. Die Beziehungen können jedoch keine weiteren Attribute, wie z. B. Kardinalitäten er-

180


fassen. Ebenso kann keine mehrdimensionale Beschreibung der Informationsobjekte vorgenommen werden. Informationsobjekte können Referenzen zu ein oder mehreren Datenobjekten haben, welche die informationstechnische Repräsentation der Information darstellen. Ein Beispiel für ein Informationsmodell findet sich in Abb. 98.

Abb. 98. Beispiel Informationsmodell

Abb. 99. Beispiel Informationslandkarte


181

Im Gegensatz zum BEN-Ergebnisdokument Informationslandkarte ermöglicht der ADOben-Modelltyp Informationslandkarte zusätzlich eine andere Sicht auf die Informationsobjekte: Es zeigt, welche Informationen zwischen welchen Prozessen fließen, d. h. welche Informationen von welchen Prozessen produziert und konsumiert werden. Die Informationslandkarte besteht dabei aus Modellelementen, die Referenzen auf Prozesse in Prozesslandkarten oder Referenzen auf Informationen in Informationsmodellen beinhalten. Ein Beispiel für eine Informationslandkarte findet sich ebenfalls in Abb. 99. IT/Business Alignment Zentrale Ergebnisdokumente der BEN-Komponente IT/Business Alignment sind Domänenmodelle, Applikationslandschaften, Capability-Modelle bzw. Modelle fachlicher Services. Ziel des IT/Business Alignment ist es, die fachlichen und ITStrukturen gegenseitig aufeinander auszurichten (vgl. Abschnitt 4.4). Dazu sollen einerseits geeignete Alignment-Artefakte identifiziert und anschließend zu den zu entkoppelnden Artefakten auf Organisationsebene und auf IT-Ebene zugeordnet werden. ADOben sieht keine Modellierungselemente für Capabilities oder fachliche Services vor, sondern fokussiert auf Applikationen als ein zentrales Element von Geschäftslösungen. Applikationen werden im Modelltyp Applikationen (Bestandsführung) abgebildet bzw. aufgelistet. Entgegen der Darstellung in diesem Buch, die Applikationen als Zuordnungsbündel zwischen Prozessen und Softwaresystemen versteht, ist orientiert sich ADOben eher am engeren Begriff der Anwendungssoftware. Daher werden Applikationen als Teil der Softwareebene behandelt. Gleichwohl ist das ADOben-Modellelement Applikation als eine Aggregation von Softwareelementen nach fachlichen Gesichtspunkten definiert. Im Applikationsmodell können Attribute wie Lebenszyklus, Art der Informationsverarbeitung oder Entwicklungstechnologie festgelegt werden. Über das Attribut „Komponentenarchitektur“ bilden Referenzen zu Modellen vom Typ Softwarelandkarte die Verbindung zu den zugehörige(n) Softwarearchitektur(en) der Applikation. Applikationen sollen fachliche Anforderungen erfüllen und nach ihnen geschnitten werden. Aus diesem Grund referenzieren Prozesse mit dem Attribut „genutzte Applikationen“ auf Applikationen. Diese Referenz ist das Kernelement des IT/Business Alignment, weil es die Organisationsebene mit der IT/Business Alignment-Ebene und mittelbar auch mit der Softwareebene verbindet. Der ADOben-Modelltyp Applikationslandkarte bietet eine andere Sicht auf Applikationen. Er stellt die Interaktionen zwischen den Applikationen in Form aggregierter Datenflüsse dar. Diese Datenflüsse entsprechen Schnittstellen und können durch Attribute wie Verarbeitungsart (batch/online) oder Automatisierungsgrad beschrieben werden. Zusätzlich kann hinter jedem Datenfluss eine sogenannte Konnektorarchitektur definiert werden, welche die Realisierung der Schnittstelle mit Softwarekomponenten abbildet.

182


In der Applikationslandkarte können auch Domänen grafisch abgebildet werden – dies aber nur mit Hilfe des Modellierungselements „Aggregationsfläche“, welches keine weitere semantische Bedeutung hat. Die Zuordnung von Applikationen zu Domänen geschieht dabei durch Platzierung des grafischen Modellelements der Applikation innerhalb der Aggregationsfläche der entsprechenden Domäne. Abb. 100 zeigt den Ausschnitt einer Applikationslandkarte mit der Domäne „Back-Office“, in der die Applikationen „Finanzsystem (SAP)“, „Finanzsystem (Individualentwicklung)“, „DWH“, „Internes Mitarbeiter-Informationssystem“ und „HR-System“ gruppiert sind. Zwischen diesen Applikationen bestehen verschiedene Datenflüsse, die ebenfalls in der Applikationslandkarte spezifiziert sind.

Abb. 100. Beispiel Domäne in Applikationslandkarte

Softwarelösungs-Fachkonzeption Die BEN-Komponente Softwarelösung-Fachkonzeption dient zur Abbildung von Datenmodellen und Softwarearchitekturmodellen (z. B. EPKs, Funktionsbäume und Use-Case-Diagramme), soweit dies zur gesamthaften Analyse und Gestaltung von Geschäftslösungen sinnvoll und notwendig ist. Die Gestaltung von Software-


183

lösungen ist jedoch primär Gegenstandsbereich des Systems Engineering bzw. Software Engineering und wird aus diesem Grund hier nur sehr oberflächlich behandelt. In ADOben werden Softwarelösungen mit Hilfe des Modelltyps Softwarelandkarte modelliert (vgl. Abb. 101). Softwarelösungen sind Komponenten-basiert aufgebaut und können hierarchisch verfeinert werden, indem die einzelnen Softwarekomponenten Referenzen auf weitere Softwarelandkarten enthalten. Neben den Softwarekomponenten können in der Softwarelandkarte auch die Implementierung auf möglichen Servern (IT-Infrastrukturebene) definiert werden. In Kombination mit dem Modelltyp Wiederverwendbare Komponenten können auch wiederverwendbare Softwarekomponenten modelliert werden. Zu diesem Zweck stellt ADOben ein Modellierungselement Komponenten (Referenz) in der Softwarelandkarte zur Verfügung, welches es erlaubt, die Komponenten aus dem Modell wiederverwendbarer Komponenten zu referenzieren.

Abb. 101. Beispiel Softwarelandkarte

Abb. 102. Referenz zu Datenobjekten in einem Informationsobjekt

184


ADOben ermöglicht auch die Definition von logischen Datenmodellen, in denen Datenobjekte und ihre Beziehungen untereinander dargestellt werden. Analog zum Informationsmodell (s. o.) können Assoziations-, Aggregations- und Generalisierungsbeziehungen modelliert werden. Datenobjekte werden zwischen Applikationen ausgetauscht (s. o.) und können von den in der Applikationslandkarten definierten Datenflüssen sowie von den Applikationen selbst referenziert werden. Die bereits erläuterten Informationsobjekte, welche fachlich strukturierte Informationen darstellen, werden üblicherweise durch ein oder mehreren Datenobjekte realisiert. Abb. 102 zeigt die Referenz zu den Datenobjekten im Notebook eines Informationsobjekts. IT-Infrastruktur-Konzeption Das Ergebnis der BEN-Komponente IT-Infrastruktur-Konzeption kann als ITInfrastrukturmodell bezeichnet werden. Analog zur Softwarelösungs-Konzeption liegt die Gestaltung der IT-Infrastruktur nicht im Fokus des Business Engineering und deshalb wird auch die Umsetzung in ADOben nur oberflächlich behandelt. Für die Gestaltung der IT-Infrastruktur stellt ADOben die Modelltypen SystemSoftware, Servermodell und Environment-Modell zur Verfügung. Zentrale ITInfrastrukturkomponenten sind die Server, welche im Servermodell definiert werden. Hier kann zwischen physischen und virtuellen Servern sowie Serverclustern unterschieden werden. Unter System-Software versteht ADOben beispielsweise Betriebssystemsoftware oder Webserver-Software. In Environments werden Laufzeitumgebungen für Softwaresysteme beschrieben, die aus Servern und Systemsoftware sowie ggf. weiteren Softwaresystemen bestehen können. Abb. 103 zeigt das Notebook eines Environment: Hier findet eine Zuordnung einer Applikation („Angebots- und Buchungssystem“) zu verschiedenen ITInfrastrukturkomponenten statt, die in den anderen Registern festgelegt wird (Web Server, Application Server, Datenbank Server, EAI Plattform, LDAP Server, Print Server, Weitere Environment-Elemente).


185

Abb. 103. Beispiel Environment

5.4.2 Analyse von Geschäftslösungen in ADOben Mit Hilfe der vorgestellten ADOben-Modelltypen können komplexe Geschäftslösungen abgebildet werden. Die komplexe Gesamt-Gestaltungsaufgabe wird dabei durch die BEN-Komponenten in Methodenfragmente aufgeteilt, durch die zunächst voneinander unabhängige Ergebnismodelle entstehen, die jedoch durch die aufgezeigten Referenzmechanismen in ADOben miteinander verbunden sind. Analysen benötigen auf Grund der Komplexität der Gesamt-Geschäftslösung spezielle Analysemechanismen, die im Folgenden vorgestellt werden. Grundsätzlich sollten die zu verwendenden Analysemechanismen sowie die möglichen Auswertungsmodelle eines Werkzeugs an den Bedürfnissen der Stakeholder ausgerichtet sein (vgl. Abschnitt 5.2). Gemäß der Concerns und Fragestellungen der Stakeholder können die notwendigen Diagramme definiert werden, die dann die entsprechenden Viewpoints für die Stakeholder darstellen. Diagrammtypen Das Konzept zur Visualisierung der Informationsstrukturen in den ADObenModellen folgt einem Framework, das im Detail in (Kurpjuweit 2009) beschrieben ist. Entscheidend für die Visualisierung ist die zu Grunde liegende Informationsstruktur, die analysiert werden soll. Die Modelle, wie sie in ADOben entwickelt werden, können als binäre relationale Informationsstrukturen bezeichnet werden, d. h. sie entsprechen mathematisch einem Graph aus Knoten (Objekten) und Kanten (Beziehungen). Relationale Informationsstrukturen sind z. B. unterschiedliche Graphen, Baumordnungen (es gibt für jedes Element jeweils genau ein übergeord-

186


netes Element), mengenwertige Abbildungen oder lineare Ordnungen. Für die Visualisierung kommen je nach Informationsstruktur eines oder mehrere der folgenden Diagrammtypen in Betracht: • • • • •

Bestandsführungsdiagramm besteht aus einer Menge von Objekten ohne Beziehungen zueinander Hierarchiebaumdiagramm bildet eine Baumstruktur ab Objektnetzdiagramm bildet beliebige Beziehungen zwischen Objekten durch Beziehungskanten ab Verschachtelungsdiagramm bildet eine hierarchische Struktur durch geometrische Anordnung der Elemente ineinander ab Zuordnungsdiagramm und Zuordnungsmatrixdiagramm bilden Zuordnungen zwischen zwei Typen von Objekten durch Kanten ab oder stellen dies in einer Matrix dar

Komplexe Diagrammtypen kommen durch Kombinationen dieser einfachen Diagrammtypen zustande. Analysemechanismen Analysemechanismen spezifizieren, wie grafische Modelle auf Basis eines zu Grunde liegenden Metamodells abgeleitet und zur Erzeugung verschiedener Analysedarstellungen manipuliert werden können. Folgende Analysemechanismen sind möglich und in ADOben implementiert: • • • • •

Visualisierung verändernde Operation beeinflusst die Anordnung und die Darstellung der grafischen Objekte innerhalb eines Diagramms Umfang verändernde Operation legt fest, welche Objekte und Beziehungen dargestellt werden Diagrammtyp verändernde Operation stellt die gleichen Informationen in einem anderen Diagrammtyp dar Metamodell-Ausschnitt verändernde Operation vergrößert oder verkleinert den im Modell dargestellten Metamodell-Ausschnitt Metamodell-Struktur verändernde Operation leitet transitive Beziehungen aus dem Metamodell ab und stellt sie im Modell dar

Umsetzung in ADOben ADOben unterscheidet zwischen grafischen Analysen und Analysen in Listenform. Die Listenform kann dabei als Vertreter des Diagrammtyps Bestandsführungsdiagramm verstanden werden, mit dessen Hilfe eine einfache Liste von Objekten ohne Beziehungen dargestellt wird. Der Benutzer kann für die Listenauswertung verschiedene Kriterien zur Einschränkung der anzuzeigenden Objekte angeben; es handelt sich somit um eine Umfang verändernde Analyseoperation. Neben einigen vordefinierten Kriterien, die durch das Werkzeug zur Verfügung gestellt werden, gibt es auch die Möglichkeit, völlig freie Abfragen zu generieren. Abb. 104 zeigt das Beispiel einer Listenauswertung für Produkte, welche der Or-


187

ganisationseinheit „Pauschalreisen“ als verantwortlichen Geschäftsbereich zugeordnet sind. Tab. 8 bis Tab. 10 zeigen die Listenauswertungen, die standardmäßig in ADOben Release 1.0 angeboten werden.

Abb. 104. Listenauswertung Produkte Tab. 8. Listenauswertungen in ADOben (Strategie- und Organisationsebene) Organisationseinheiten am Standort X Organisationseinheiten im Land X Mitarbeiter im Land X Produkte des Geschäftsbereichs X Ausprägungen (der strategischen Positionierung), für die es keine Produkte gibt Produkte, die von Prozess X bearbeitet werden Tab. 9. Listenauswertungen in ADOben (IT/Business Alignment-Ebene) Applikationen mit Namen X Applikationen, bei denen keine (Software-)Komponentenarchitektur hinterlegt ist Applikationen, bei denen eine (Software-)Komponentenarchitektur hinterlegt ist Applikationen mit dem Lebenszyklus X Applikationen mit der Erstellungsart X Applikationen mit der Verarbeitungsart X Applikationen mit der Anzahl zugelassener/gleichzeitiger Nutzer kleiner/grösser/gleich X Applikationen mit User Interface X Applikationen mit Entwicklungstechnologie X Applikationen mit Sicherheitsattribut X Applikationen, bei der ein Beteiligter der Rolle X hinterlegt ist Applikationen, bei der ein Beteiligter der Rolle X nicht hinterlegt ist Logische Datenflüsse, bei denen eine/keine Konnektorarchitektur hinterlegt ist Logische Datenflüsse mit der Verarbeitungsart Batch/Online Logische Datenflüsse, die automatisch/manuell ausgeführt werden Logische Datenflüsse mit der Integrationstechnologie X

188


Tab. 10. Listenauswertungen in ADOben (IT-Ebene) Softwarekomponenten mit der Erstellungsart X Softwarekomponenten mit der Verarbeitungsart X Softwarekomponenten mit der Entwicklungstechnologie X Softwarekomponenten vom Typ X Softwarekomponenten, bei denen ein Beteiligter der Rolle X hinterlegt ist Environments Environments, die das Environment X nutzen Environments, die der Applikation X zugeordnet sind Environments, die dem Owner X zugeordnet sind Environments mit dem Status X Server des Herstellers X vom Typ Y vom Modell Z Server mit installierter Systemsoftware X im Patch-Level Y Server, auf denen Systemsoftware X installiert ist Server mit Namen X Server, die vor/ab dem geliefert worden sind Server, die vor/ab dem installiert worden sind Server am Standort X Server mit der Seriennummer X Server mit der Anzahl CPUs = X/Taktfrequenz = X/Hauptspeicher = X/Festplattenspeicher = X Server mit freien CPU-Slots Server mit erweiterbarem Hauptspeicher Virtuellen Server, die die Virtualisierungssoftware X verwenden Servercluster, die die Clustermanagement-Software X verwenden Servercluster mit dem Redundanz-Typ OS-Cluster/App-Cluster Im Cluster X betriebene Server mit ihren Clusterpartnern

Darüber hinaus werden einige grafische Auswertungen vordefiniert zur Verfügung gestellt. Diese werden über das Menü ausgewählt. Anschließende Dialoge erlauben die Auswahl der zu analysierenden Modelle und die Einschränkung auf bestimmte Modellelemente. Grundsätzlich kann zwischen sogenannten zweidimensionalen und drei-dimensionalen Matrixauswertungen unterschieden werden. Zwei-dimensionale Matrixauswertungen zeigen die Relationen zwischen zwei ausgewählten Objekttypen. Drei-dimensionale Matrixauswertungen stellen grafisch Relationen zwischen drei verschiedenen Objekttypen dar. Beide Auswertungen sind somit vom Diagrammtyp Zuordnungsmatrixdiagramm und können zusätzlich, je nach Komplexität der Analyse, mit weiteren Diagrammtypen kombiniert werden. Tab. 11 Und Tab. 12 zeigen die grafischen Auswertungen, die in ADOben Release 1.0 standardmäßig angeboten werden.


189

Tab. 11. Zwei-dimensionale grafische Auswertungen in ADOben Organisationseinheiten/Personen Prozesshierarchie/Produkte Prozesshierarchie/Applikationen Strategische Ausprägungen/Produkte Strategische Ausprägungen/Geschäftsfelder Prozesshierarchie/Organisationseinheiten Server/Environments Tab. 12. Drei-dimensionale grafische Auswertungen in ADOben Prozesshierarchie/Produkte/Applikationen Prozesshierarchie/Organisationseinheiten/Applikationen Prozesshierarchie/Organisationseinheiten/Produkte Applikationen/Server/Environments

Ein Beispiel für eine zwei-dimensionale Matrix ist die Auswertung, welche Geschäftsprozesse für welche Produkte eine Rolle spielen. Wie in Abb. 105 dargestellt, sind auf der horizontalen Achse die Geschäftsprozesse und auf der vertikalen Achse die Produkte abgetragen. Dabei werden zusätzlich für den Prozess „Kundengewinnungs- und Beziehungsmanagement“ zwei Hierarchiestufen hinzugenommen, sodass ein in einer Dimension hierarchisches Zuordnungsmatrixdiagramm, d. h. eine Kombination aus Hierarchiebaumdiagramm und Zuordnungsmatrixdiagramm, entsteht (vgl. Abb. 106). Dies entspricht dem Analysemechanismus der Metamodell-Ausschnitt verändernden Operation. Als Erweiterung können auch für die Produkte (vertikale Achse) zusätzlich Hierarchiebäume, z. B. für Produkte und deren Produktkomponenten, eingeblendet werden. Diese Form des in beiden Dimensionen hierarchischen Zuordnungsmatrixdiagramms gehört allerdings nicht zum Standardlieferumfang von ADOben in Release 1.0.

190


Abb. 105. Zwei-dimensionale Analyse Prozesse und Produkte

Abb. 106. Zwei-dimensionale Analyse Prozesse und Produkte (Detailansicht Prozesshierarchie)


191

Abb. 107. Drei-dimensionale Auswertung Produkte/Applikationen/Prozesse

In einer drei-dimensionalen Analyse enthalten die Zellen der Matrix ebenfalls Gestaltungsobjekte. Hinter der Auswertung steht folglich ein Metamodellausschnitt von drei transitiv miteinander verbundenen Objekten. Ein Anwendungsfall für eine solche Analyse ist die Fragestellung, welche Applikationen in den einzelnen Prozessen, sortiert nach Produkten, genutzt werden. Abb. 107 ist ein Beispiel einer solchen Analyse. Die in den Matrixzellen aufgeführten Applikationen werden gruppiert nach den beiden Dimensionen dargestellt. Somit handelt es sich um ein Zuordnungsdiagramm mit gruppierten komplexen Objekten. Mit Hilfe der genannten ADOben-Analysen können verschiedene Analysetypen realisiert werden: Die Auswertung der Zusammenhänge zwischen Prozessen und Applikationen ist einerseits eine Form der Abhängigkeitsanalyse zwischen den ausgewählten Modellelementen. Andererseits können mit derselben Auswertung auch Fragestellungen nach der Abdeckung von Prozessen durch Applikationen beantwortet werden. Werden zusätzlich Produkte zur Auswertung hinzugezo-

192


gen, kann außerdem eine Schnittstellenanalyse hinsichtlich einer einheitlichen Verwendung von Applikationen bei ähnlichen Produkten durchgeführt werden. Die Heterogenität der Geschäftslösung sowie die Konformität zu geltenden Richtlinien kann durch entsprechend formulierte Listenauswertungen analysiert werden. Beispielsweise können durch die Abfrage nach Prozessen oder ITArtefakten ohne spezifizierten Owner eventuelle Lücken hinsichtlich ComplianceRichtlinien aufgedeckt werden. Heterogenität von Softwareartefakten drückt sich beispielweise in der Anzahl der unterschiedlichen, eingesetzten Entwicklungstechnologien aus, welche mit einer Listenauswertung abgefragt werden können. Kosten- und Nutzenanalysen sind mit ADOben nur eingeschränkt möglich, da standardmäßig keine Attribute für die monetäre Bewertung von Artefakten vorgesehen sind. Ebenso ermöglicht das Werkzeug nur indirekte Analysen zur Komplexität der Geschäftslösung. Eine Analyse der Knoten und Kanten in den ADObenModellen ist in Release 1.0 nicht vorgesehen.

5.4.3 Zeitaspekte in ADOben Wenn für die Gestaltung von Geschäftslösungen ein Werkzeug eingesetzt wird, kann nicht nur die einmalige (Neu-)Gestaltung, sondern auch die Weiterentwicklung der Geschäftslösung unterstützt werden. Zu diesem Zweck muss es zusätzliche Attribute und Funktionalitäten geben, welche die Modellierung von Zeitaspekten unterstützen. Um die kontinuierliche Weiterentwicklung der Geschäftslösungen zu planen, können Ist- und Soll-Modelle unterschieden werden, zeitliche Gültigkeitsdauern für Modelle oder Lebenszyklen einzelner Artefakte festgelegt werden. ADOben bietet in Release 1.0 keine expliziten Mechanismen an, um Modelle als Ist- oder Soll-Modelle zu kennzeichnen. Durch den Mechanismus der Versionierung (s. o.) können Ist- und Soll-Modelle jedoch „simuliert“ werden. Durch Analysen zwischen Ist- und Soll-Modellen können Vergleiche gezogen und Handlungsbedarf für die Weiterentwicklung abgeleitet werden.

Literatur Ågerfalk P J, Brinkkemper S, Gonzalez-Perez C, Henderson-Sellers B, Karlsson F, Kelly S, Ralyté J (2007) Modularization Constructs in Method Engineering: Towards Common Ground?, in: Ralyté J, Brinkkemper S, Henderson-Sellers B (Hrsg): IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME07), Springer, Geneva, S 359-368 Aier S (2006) How Clustering Enterprise Architectures helps to Design Service Oriented Architectures. In: Proceedings of the IEEE International Conference on Services Computing (SCC'06). IEEE Computer Society, Los Alamitos, CA, USA, S 269272 Aier S, Winter R (2009) Virtuelle Entkopplung von fachlichen und IT-Strukturen für das IT/Business Alignment – Grundlagen, Architekturgestaltung und Umsetzung am Beispiel der Domänenbildung. Wirtschaftsinformatik 51(2):175–191 Aier S, Kurpjuweit S, Schmitz O, Schulz J, Thomas A, Winter R (2008) An Engineering Approach to Enterprise Architecture Design and its Application at a Financial Service Provider, in: Loss P, Nüttgens M, Turowski K, Werth D (Hrsg): Proceedings Modellierung betrieblicher Informationssysteme (MobIS 2008), GI/Köllen, Saarbrücken, S 115-130 Albani A, Overhage S, Birkmeier D (2008) Towards a Systematic Method for Identifying Business Components. In: Chaudron M R V, Szyperski C, Reussner R (Hrsg) Components-Based Software Engineering. Springer, Berlin et al., S 262-277 Alpar P, Grob H L, Weimann P, Winter R (2008) Anwendungsorientierte Wirtschaftsinformatik. 5. Aufl Vieweg, Wiesbaden Alt R, Reichmayr C, Puschmann T, Leser F, Österle H (2001) An Engineering Approach to Develop Business Networks. In: Schmid B, Stanoevska-Slabeva K, Tschammer V (Hrsg) Towards the E-Society: E-commerce, E-businness, and E-government, Kluwer, Norwell, Zürich, S 209-228 Balzert H (1998) Lehrbuch der Software-Technik: Software-Management, SoftwareQualitätssicherung, Unternehmensmodellierung. Spektrum, Heidelberg, Berlin Balzert H (2000) Lehrbuch der Software-Technik – Software-Entwicklung. Spektrum Akademischer Verlag, Heidelberg Baumöl U (2005a) Strategic Agility through Situational Method Construction, in: Reichwald R, Huff A S (Hrsg): Proceedings of the European Academy of Management Annual Conference 2005, München Baumöl U (2005b) Situative Methodenkonstruktion für die organisationale Veränderung. Habilitation, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen Baumöl U, Winter R (2003) Qualifikation für die Veränderung. In: Österle H, Winter R (Hrsg) Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, Springer, Berlin etc., S 45-61 Becker J, Delfmann P, Knackstedt R (2004) Konstruktion von Referenzmodellierungssprachen – Ein Ordnungsrahmen zur Spezifikation von Adaptionsmechanismen für Informationsmodelle. Wirtschaftsinformatik 46(4):251-264 Becker J, Janiesch C, Pfeiffer D (2007a) Reuse Mechanisms in Situational Method Engineering, in: Ralyté J, Brinkkemper S, Henderson-Sellers B (Hrsg): IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME07), Springer, Geneva, S 79-93

R. Winter, Business Engineering Navigator, DOI 10.1007/978-3-642-15913-8, © Springer-Verlag Berlin Heidelberg 2011

194

Literatur

Becker J, Holten R, Knackstedt R, Schütte R (2002a) Referenz-Informationsmodellierung, in: Bodendorf F, Grauer M (Hrsg): Tagungsband der Verbundtagung Wirtschaftsinformatik 2000, Aachen, S 86-109 Becker J, Delfmann P, Knackstedt R, Kuropka D (2002b) Konfigurative Referenzmodellierung. In: Becker J, Knackstedt R (Hrsg) Wissensmanagement mit Referenzmodellen: Konzepte für die Anwendungssystem- und Organisationsgestaltung, Physica, Heidelberg, S 25-144 Becker J, Knackstedt R, Pfeiffer D, Janiesch C (2007b) Configurative Method Engineering – On the Applicability of Reference Modeling Mechanisms in Method Engineering: Proceedings of the 13th Americas Conference on Information Systems (AMCIS 2007), Keystone Becker J, Knackstedt R, Holten R, Hansmann H, Neumann S (2001) Konstruktion von Methodiken – Vorschläge für eine begriffliche Grundlegung und domänenspezifische Anwendungsbeispiele. Institut für Wirtschaftsinformatik, Universität Münster, Münster Birkmeier D, Overhage S (2009) On Component Identification Approaches – Classification, State of the Art, and Comparison. In: 12th International Symposium on Component-Based Software Engineering CBSE 2009. Springer, Berlin et al., S 1-18 Boßhammer M, Winter R (1995) Formale Validierung von Verdichtungsoperationen in konzeptionellen Datenmodellen - Zur konsistenten Verdichtung von Grafiken und Textdokumentationen der Datenbasis betriebswirtschaftlicher Anwendungssysteme am Beispiel des SAP R/3 PP- und SD-Schema. In: König W (Hrsg) Wirtschaftsinformatik '95, Physica, Heidelberg, S 223-241 Braun C (2007) Modellierung der Unternehmensarchitektur: Weiterentwicklung einer bestehenden Methode und deren Abbildung in einem Meta-Modellierungswerkzeug. Dissertation, Universität St. Gallen, St. Gallen Braun C, Wortmann F, Hafner M, Winter R (2005) Method Construction – A Core Approach to Organizational Engineering, in: Haddad H, Liebrock L M, Omicini A, Wainwright R L (Hrsg): The 20th ACM Symposium on Applied Computing (SAC2005), ACM Press, Santa Fe, S 1295-1299 Brinkkemper S (1996) Method Engineering – Engineering of Information Systems Development Methods and Tools. Information and Software Technology 38(4):275280 Brinkkemper S, Saeki M, Harmsen A F (1999) Meta-Modelling Based Assembly Techniques for Situational Method Engineering. Information Systems 24(3):209-228 Bucher T (2009) Ausrichtung der Informationslogistik auf operative Prozesse - Entwicklung und Evaluation einer situativen Methode. Dissertation, Universität St. Gallen, St. Gallen Bucher T, Winter R (2008) Dissemination and Importance of the "Method" Artifact in the Context of Design Research for Information Systems, in: Vaishnavi V, Baskerville R (Hrsg): Proceedings of the Third International Conference on Design Science Research in Information Systems and Technology (DESRIST 2008), Georgia State University, Atlanta, S 39-59 Bucher T, Klesse M, Kurpjuweit S, Winter R (2007) Situational Method Engineering – On the Differentiation of "Context" and "Project Type", in: Ralyté J, Brinkkemper S, Henderson-Sellers B (Hrsg): IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME07), Springer, Geneva, S 33-48 Bunse C, von Knethen A (2008) Vorgehensmodelle kompakt. 2. Aufl Spektrum, Heidelberg

Literatur

195

Cheesman J, Daniels J (2001) UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley, Upper Saddle River Chen P P-S (1976) The Entity-Relationship Model - Toward a Unified View of Data. ACM Transactions on Database Systems 1(1):9-36 Codd E F (1970) Relational Model of Data for Large Shared Data Banks. Communications of the ACM 13(6):377-387 Davenport T H, Short J E (1990) The New Industrial Engineering - Information Technology and Business Process Redesign. Sloan Management Review 31(4):11-27 Delfmann P (2006) Adaptive Referenzmodellierung: Methodische Konzepte zur Konstruktion und Anwendung wiederverwendungsorientierter Informationsmodelle. Dissertation, Westfälische Wilhelms-Universität Münster, Münster Deutsches Forschungszentrum für Künstliche Intelligenz (2008) Reference Model Catalogs. http://rmk.iwi.uni-sb.de/, Abruf am 09.04.2008 Dijkstra E (1982) On the role of scientific thought. In: Dijkstra E (Hrsg) Selected Writings on Computing: A Personal Perspective, Springer, New York, S 60-66 Dodd J (2005) Practical Service Specification and Design Part 1: Planning the Services. CBDi Journal(März):22-29 Dubs R, Euler D, Rüegg-Stürm J, Wyss C E (2004) Einführung in die Managementlehre. Haupt, Bern Ebert C (2008) Systematisches Requirements Engineering und Managements. 2. Aufl dpunkt Verlag, Heidelberg Elmasri R, Navathe S B (2000) Fundamentals of Database Systems. 3. Aufl Addison Wesley, Reading et al. Fettke P, Loos P (2002a) Der Referenzmodellkatalog als Instrument des Wissensmanagements: Methodik und Anwendung. In: Becker J, Knackstedt R (Hrsg) Wissensmanagement mit Referenzmodellen: Konzepte für die Anwendungssystem- und Organisationsgestaltung, Physica, Heidelberg, S 3-24 Fettke P, Loos P (2002b) Klassifikation von Informationsmodellen – Nutzenpotentiale, Methode und Anwendung am Beispiel von Referenzmodellen. Forschungsgruppe Information Systems Management, Johannes Gutenberg-Universität Mainz, Mainz Fettke P, Loos P (2004) Referenzmodellierungsforschung. Wirtschaftsinformatik 46(5):331-340 Fettke P, Loos P (2005) Der Beitrag der Referenzmodellierung zum Business Engineering. HMD – Praxis der Wirtschaftsinformatik(241):18-26 Fill H-G, Gericke A, Karagiannis D, Winter R (2007) Modellierung für Integrated Enterprise Balancing. Wirtschaftsinformatik 49(6):419-429 Fischer R (2008) Organisation der Unternehmensarchitektur. Entwicklung der aufbau- und ablauforganisatorischen Strukturen unter besonderer Berücksichtigung des Gestaltungsziels Konsistenzerhaltung. Dissertation, Kovač, Hamburg Fleisch E (2001) Das Netzwerkunternehmen: Theorien, Strategien und Prozesse zur Steigerung der Wettbewerbsfähigkeit in der "Networked economy". Springer, Berlin et al. Fuchs E, Fuchs K-H, Hauri C H (2002) Requirements-Engineering in IT – effizient und verständlich. Vieweg Gericke A (2006) Modelle der Strategie- und Organisationsebene einer Unternehmensarchitektur. Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen Gericke A (2008) Konstruktionsforschung und Artefaktkonstruktion in der gestaltungsorientierten Wirtschaftsinformatik: Ein Literaturüberblick. Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen

196

Literatur

Gericke A, Winter R (2009) On the Application of the ISD Method Engineering Approach to Organizational Engineering. Institut für Wirschaftsinformatik, Universität St. Gallen, St. Gallen Goeken M (2004) Referenzmodellbasierte Einführung von Führungsinformationssystemen: Grundlagen, Anforderungen, Methode. Wirtschaftsinformatik 46(5):353-365 Goeken M (2005) Anforderungsmanagement bei der Entwicklung von Data WarehouseSystemen - Ein sichtenspezifischer Ansatz. In: Schelp J, Winter R (Hrsg) Auf dem Weg zur Integration Factory, Proceedings der DW2004 - Data Warehousing und EAI. Physica-Verlag, Heidelberg, S 167-186 Gonzalez-Perez C (2007) Supporting Situational Method Engineering with ISO/IEC 24744 and the Work Product Pool Approach, in: Ralyté J, Brinkkemper S, HendersonSellers B (Hrsg): IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME07), Springer, Geneva, S 7-18 Gottschalk F, van der Aalst W M P, Jansen-Vullers M H (2006) Configurable Process Models: A Foundational Approach, in: Lehner F, Nösekabel H, Kleinschmidt P (Hrsg): Proceedings of the Multikonferenz Wirtschaftsinformatik 2006 (MKWI '06), Passau Greiffenberg S (2003) Methoden als Theorien der Wirtschaftsinformatik, in: Uhr W, Esswein W, Schoop E (Hrsg): Wirtschaftsinformatik 2003 Band II – Medien, Märkte, Mobilität, Physica, Dresden, S 947-968 Gutzwiller T A (1994) Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen. Physica, Heidelberg Hafner M (2005) Entwicklung einer Methode für das Management der Informationssystemarchitektur im Unternehmen. Dissertation, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen Hagel J, III, Singer M (1999) Unbundling the Corporation. Harvard Business Review 77(2):133-141 Hagen C (2003) Integrationsarchitektur der Credit Suisse. In: Aier S, Schönherr M (Hrsg) Enterprise Application Integration – Flexibilisierung komplexer Unternehmensarchitekturen, GITO-Verlag, Berlin, S 61-81 Hauswirth I A (2006) Effective and Efficient Organisations? – Government Export Promotion in Germany and the UK from an Organisational Economics Perspective. Physica, Heidelberg Heinrich B (2002a) Das Geschäftsmodell als Instrument zur Positionierung des Unternehmens. In: Leist S, Winter R (Hrsg) Retail Banking im Informationszeitalter – Integrierte Gestaltung der Geschäfts-, Prozess- und Applikationsebene, Springer, Berlin et al., S 53-72 Heinrich B (2002b) Die konzeptionelle Gestaltung des Multichannel-Vertriebs anhand von Kundenbedürfnissen. In: Leist S, Winter R (Hrsg) Retail Banking im Informationszeitalter – Integrierte Gestaltung der Geschäfts-, Prozess- und Applikationsebene, Springer, Berlin et al., S 73-92 Heinrich B (2002c) Methode zur wertorientierte Analyse und Gestaltung der Kundeninteraktion. Dissertation, St. Gallen, Augsburg Heinrich L J (1996) Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur. 5. Aufl R. Oldenbourg Verlag, München Heym M (1993) Methoden-Engineering – Spezifikation und Integration von Entwicklungsmethoden für Informationssysteme. Dissertation, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen Higgins J, Wiese G (1996) Innovationsmanagement: Kreativitätstechniken für den unternehmerischen Erfolg. Springer, Berlin et al.

Literatur

197

IBM (1984) Business Systems Planning – Information Systems Planning Guide, IBM-Form GE20-0527-4. 4. Aufl IBM, Atlanta IMG (1997a) PROMET SSW, Methodenhandbuch für die Einführung von Standardanwendungssoftware, Version 3.0. Information Management Group/Institut für Wirtschaftsinformatik Universität St. Gallen, St. Gallen IMG (Hrsg.) (1997b) PROMET BPR, Methodenhandbuch für den Entwurf von Geschäftsprozessen, Version 2.0. Information Management Group/Institut für Wirtschaftsinformatik an der Universität St. Gallen, St. Gallen James G A (2008) Magic Quadrant for Enterprise Architecture Tools. Gartner Research, G00156427 Jørgensen K A (2006) Product Modelling on Multiple Abstraction Levels. In: Blecker T, Friedrich G (Hrsg) Mass Customization: Challenges and Solutions, Springer, New York, S 63-84 Junginger S, Kühn H, Strobl R, Karagiannis D (2000) Ein GeschäftsprozessmanagementWerkzeug der nächsten Generation. Wirtschaftsinformatik 42(5):392-401 Kagermann H, Österle H (2006) Geschäftsmodelle 2010 – Wie CEOs Unternehmen transformieren. F.A.Z.-Institut für Management- Markt- und Medieninformationen, Frankfurt am Main Kaib M (2002) Enterprise Application Integration – Grundlagen, Integrationsprodukte, Anwendungsbeispiele. DUV, Wiesbaden Kaplan R S, Norton D P (1996) The balanced scorecard : translating strategy into action. Harvard Business School Press, Boston, MA Kaplan R S, Norton D P (1997) Balanced Scorecard. Schäffer-Poeschel, Stuttgart Karlsson F, Ågerfalk P J (2004) Method Configuration – Adapting to Situational Characteristics while Creating Reusable Assets. Information and Software Technology 46(9):619-633 Karlsson F, Ågerfalk P J, Hjalmarsson A (2001) Method Configuration with Development Tracks and Generic Project Types: Proceedings of the 6th CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in System Analysis and Design (EMMSAD'01), Interlaken Kieser A, Walgenbach P (2007) Organisation. 5. Aufl Schäffer-Poeschel, Stuttgart Knackstedt R, Janiesch C, Rieke T (2006) Configuring Reference Models – An Integrated Approach for Transaction Processing and Decision Support: Proceedings of the 8th International Conference on Enterprise Information Systems (ICEIS 2006), Paphos, Cyprus, S 135-143 Kornyshova E, Deneckère R, Salinesi C (2007) Method Chunks Selection by Multicriteria Techniques: an Extension of the Assembly-based Approach, in: Ralyté J, Brinkkemper S, Henderson-Sellers B (Hrsg): IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME07), Springer, Geneva, S 64-78 Kurpjuweit S (2008) Modellierung und Analyse der Unternehmensarchitektur in ADOben am Beispiel der Reise-Plattform smartTravel AG: Kurpjuweit S (2009) Stakeholder-orientierte Modellierung und Analyse der Unternehmensarchitektur unter besonderer Berücksichtigung der Geschäfts- und IT-Architektur. Dissertation, Universität St.Gallen, Kurpjuweit S, Winter R (2007) Viewpoint-based Meta Model Engineering. In: Reichert M, Strecker S, Turowski K (Hrsg) Enterprise Modelling and Information Systems Architectures – Concepts and Applications, Proceedings of the 2nd Int'l Workshop EMISA 2007. Gesellschaft für Informatik, Köllen, Bonn, S 143-161 Laudon K C, Laudon J P, Schoder D (2006) Wirtschaftsinformatik - Eine Einführung. Pearson Studium, München

198

Literatur

Leist S, Winter R (2000) Finanzdienstleistungen im Informationszeitalter - Vision, Referenzmodell und Transformation. In: Belz C, Bieger T (Hrsg) Dienstleistungskompetenz und innovative Geschäftsmodelle, Thexis, St.Gallen, S 150-166 Linthicum D S (2000) Enterprise Application Integration. AWL Direct Sales, Reading, Massachusetts Luftman J N, Kempaiah R (2008) Key Issues For IT Executives 2007. MISQ Executive 7(2):99-112 Malone T W, Crowston K, Lee J, Pentland B T, Dellarocas C, Wyner G M, Quimby J, Osborn C S, Bernstein A, Herman G A, Klein M, O'Donnell E (1999) Tools for Inventing Organizations: Toward a Handbook of Organizational Processes. Management Science 45(3):425-443 March S T, Smith G F (1995) Design and Natural Science Research on Information Technology. Decision Support Systems 15(4):251-266 Martin J (1989) Information Engineering Vol. 1: Introduction. Prentice-Hall, Englewood Cliffs McCabe T J (1976) A complexity measure. In: Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, S 308-320 Mirbel I, Ralyté J (2006) Situational method engineering: combining assembly-based and roadmap-driven approaches. Requirements Engineering 11(1):58-78 Niemann K D (2005) Von der Unternehmensarchitektur zur IT-Governance: Leitfaden für effizientes und effektives IT-Management. (Edition CIO). Aufl Vieweg Oestereich B (2001) Die UML-Kurzreferenz für die Praxis – kurz, bündig, ballastfrei. Oldenburg, München OMG (2007) OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2. http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/, Abruf am 11.02.2009 Ortner E, Söllner B (1989) Semantische Datenmodellierung nach der Objekttypenmethode. Informatik-Spektrum 12(1):31-42 Österle H (1995) Business Engineering - Prozess- und Systementwicklung (Band 1: Entwurfstechniken). 2. Aufl Springer, Berlin Österle H (2004) Der Übergang zur Informationsgesellschaft (New Economy). In: Dubs R, Euler D, Rüegg-Stürm J, Wyss C E (Hrsg) Einführung in die Managementlehre, Haupt, Bern, Stuttgart, Wien, S 507-529 Österle H, Winter R (2003) Business Engineering. In: Österle H, Winter R (Hrsg) Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl, Springer, Berlin, Heidelberg, New York, S 3-19 Österle H, Fleisch E, Alt R (2001) Business Networking: Shaping Collaboration Between Enterprises. 2. Aufl Springer-Verlag, Berlin et al. Österle H, Winter R, Höning F, Kurpjuweit S, Osl P (2007) Business Engineering: CoreBusiness-Metamodell. WISU – Das Wirtschaftsstudium 36(2):191-194 Peffers K, Tuunanen T, Gengler C E, Rossi M, Hui W, Virtanen V, Bragge J (2006) The Design Science Research Process: A Model for Producing and Presenting Information Systems Research, in: Chatterjee S, Hevner A (Hrsg): Proceedings of the First International Conference on Design Science Research in Information Systems and Technology (DESRIST 2006), Claremont, CA, S 83-106 Penzel H-G, Pietig C (2000) MergerGuide. Gabler, Wiesbaden Porter M E (1999) Wettbewerbsvorteile: Spitzenleistungen erreichen und behaupten. Campus Verlag, Frankfurt a.M. Prahalad C K, Hamel G (1990) The Core Competence of the Corporation. Harvard Business Review 68(3):79-91

Literatur

199

Ralyté J, Rolland C (2001) An Approach for Method Reengineering, in: Hideko S K, Jajodia S, Sølvberg A (Hrsg): 20th International Conference on Conceptual Modeling, Yokohama, Japan, November 27-30, 2001, Proceedings, Springer, Yokohama, Japan, S 471-484 Rolland C (1997) A Primer for Method Engineering: Proceedings of the Informatique des Organisations d'Information et de Décision (INFORSID), Toulouse Rolland C, Prakash N (1996) A Proposal for Context-Specific Method Engineering, in: Brinkkemper S, Lytinnen K, Welke R J (Hrsg): Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, 26-28 August 1996, Atlanta, USA, Chapman & Hall, Atlanta, S 191-207 Rosemann M, zur Mühlen M (1997) Modellierung der Aufbauorganisation in WorkflowManagement-Systemen: Kritische Bestandsaufnahme und Gestaltungsvorschläge. In: Jablonski S (Hrsg) Proceedings of the EMISA-Fachgruppentreffen. S 78-84 Rossi M, Sein M K (2003) Design Research Workshop: A Proactive Research Approach.

http://www.cis.gsu.edu/~emonod/epistemology/Sein%20and%20Rossi% 20-%20design%20research%20-%20IRIS.pdf, Abruf am 2009-04-23 Rüegg-Stürm J (2002) Das neue St. Galler Management-Modell – Grundkategorien einer integrierten Managementlehre: Der HSG-Ansatz. Paul Haupt, Bern Rummler G A, Brache Alan P (1995) Improving Performance: How to manage the white space on the organizational chart. Jossey-Bass, San Francisco Scheer A-W (2001) ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. 4. Aufl Springer, Berlin Heidelberg Scheer A-W, Thomas O (2005) Geschäftsprozessmodellierung mit der ereignisgesteuerten Prozesskette. Das Wirtschaftsstudium 34(8-9):1069-1078 Schelp J (2000) Konzeptionelle Modellierung mehrdimensionaler Datenstrukturen analyseorientierter Informationssysteme. DUV, Wiesbaden Schelp J, Winter R (2006) Method Engineering – Lessons Learned from Reference Modeling, in: Chatterjee S, Hevner A (Hrsg): Proceedings of the 1st International Conference on Design Science in Information Systems and Technology (DESRIST 2006), Claremont Graduate University, Claremont, S 555-575 Schelp J, Winter R (2008) Entwurf von Anwendungssystemen und Entwurf von Enterprise Services – Ähnlichkeiten und Unterschiede. Wirtschaftsinformatik 50(1):6-15 Schlagheck B (2000) Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling: Grundlagen – Konstruktion – Anwendungsmöglichkeiten. Gabler, Wiesbaden Schütte R (1998) Grundsätze ordnungsmäßiger Referenzmodellierung – Konstruktion konfigurations- und anpassungsorientierter Modelle. Gabler, Wiesbaden Schwarz H (1995) Arbeitsplatzbeschreibungen. 13. Aufl Haufe, Freiburg i. Br. Selders M (2009) Project Scorecard - Ein Instrument zur Unterstützung des Managements von strategischen Projekten. Shaker Verlag Shore J, Warden S (2008) Agile Development. 1. Aufl O'Reilly, Sebastopol Sinz E J (1988) Das Strukturierte Entity-Relationship-Modell (SER-Modell). Angewandte Informatik 30(5):191-202 Stock D, Winter R, Mayer J H Functional Service Domain Architecture Management Building the Foundation for Situational Method Engineering. In: Pries-Heje J, Venable J J, Bunker D, Russo N L, DeGross J I (Hrsg) Human Benefit through the Diffusion of Information Systems Design Science Research. Springer, Berlin, S 245-262 Stroh F, Winter R, Wortmann F Methodenunterstützung der Informationsbedarfsanalyse analytischer Informationssysteme. Wirtschaftsinformatik / Business & Information Systems Engineering (forthcoming)

200

Literatur

Stünzer L (1996) Systemtheorie und betriebswirtschaftliche Organisationsforschung. Duncker & Humblot, Berlin Stutz M (2009) Kennzahlen für Unternehmensarchitekturen - Entwicklung einer Methode zum Aufbau eines Kennzahlensystems für die wertorientierte Steuerung der Veränderung von Unternehmensarchitekturen. Dissertation, Universität St. Gallen, Hamburg Szyperski C, Gruntz D, Murer S (2002) Component Software: Beyond Object-Oriented Programming. 2. Aufl Addison Wesley Longman, ACM Press, New York ter Doest H, Iacob M-E, Lankhorst M, Van Leeuwen D, Slagter R (2004) Viewpoints Functionality and Examples: The Open Group (2009) TOGAF (The Open Group Architecture Framework) Version 9. Thomas O, Nüttgens M (Hrsg.) (2009) Dienstleistungsmodellierung, Methoden – Werkzeuge und Branchenlösungen. Physika, Berlin, Heidelberg Tsichritzis D C, Klug A (1978) The ANSI/X3/SPARC DBMS Framework; Report of a Study Group on Data Base Management Systems. Information Systems 3(4):173191 van Slooten K, Hodes B (1996) Characterizing IS Development Projects, in: Brinkkemper S, Lyytinen K, Welke R J (Hrsg): Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, 26-28 August 1996, Atlanta, USA, Chapman & Hall, Atlanta, S 29-44 Vessey I, Galletta D (1991) Cognitive Fit: An Empirical Study of Information Acquisition. Information System Research 2(1):63-84 vom Brocke J (2003) Referenzmodellierung – Gestaltung und Verteilung von Konstruktionsprozessen. Logos, Berlin vom Brocke J (2007) Design Principles for Reference Modeling – Reusing Information Models by Means of Aggregation, Specialization, Instantiation, and Analogy. In: Fettke P, Loos P (Hrsg) Reference Modeling for Business Systems Analysis, Idea Group, Hershey, S 47-75 vom Brocke J, Thomas O (2006) Reference Modeling for Organizational Change: Applying Collaborative Techniques for Business Engineering: Proceedings of the 12th Americas Conference on Information Systems: Connecting the Americas, Acapulco, S 680-688 von Maur E, Schelp J, Winter R (2003) Integrierte Informationslogistik – Stand und Entwicklungstendenzen. In: von Maur E, Winter R (Hrsg) Data Warehouse Management, Springer, Berlin et al., S 3-23 Watson H J, Abraham D L, Chen D, Preston D, Thomas D (2004) Data Warehousing ROI: Justifying and Assessing a Data Warehouse. Business Intelligence Journal 9(2):617 Wedekind H (1981) Datenbanksysteme I. Eine konstruktive Einführung in die Datenverarbeitung in Wirtschaft und Verwaltung. 2. Aufl Bibliographisches Institut Mannheim, Mannheim Winter R (1998) Informationsableitung in betrieblichen Anwendungssystemen. Vieweg, Braunschweig/Wiesbaden Winter R (2003a) An Architecture Model for Supporting Application Integration Decisions, in: Ciborra C, Mercurio R, De Marco M, Martinez M, Carignani A (Hrsg): Proceedings of the 11th European Conference on Information Systems (ECIS 2003), Neapel Winter R (2003b) Modelle, Techniken und Werkzeuge im Business Engineering. In: Österle H, Winter R (Hrsg) Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, 2 Aufl, Springer, Berlin et al., S 87-118

Literatur

201

Winter R (2006) Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Informationssystem-Architekturplanung. In: Schelp J, Winter R (Hrsg) Integrationsmanagement, Springer, Berlin et al., S 1-29 Winter R (Hrsg.) (2009) Management von Integrationsprojekten, mit Grundlagenbeiträgen von Stephan Aier, Christian Fischer, Bettina Gleichauf, Christian Riege, Jan Saat, Joachim Schelp und Robert Winter. Springer, Berlin Winter R (2010) Organisational Design and Engineering - Proposal of a Conceptual Framework and Comparison of Business Engineering with other Approaches. Int. Journal of Organizational Design and Engineering (forthcoming) 1(1) Winter R, Schelp J (2006) Reference Modeling and Method Construction – A Design Science Perspective, in: Liebrock L M (Hrsg): Proceedings of the 21st Annual ACM Symposium on Applied Computing (SAC2006), April 23-27, 2006, Dijon, France, ACM Press, Dijon, S 1561-1562 Winter R, Gericke A, Bucher T (2009) Method versus Model – Two Sides of the Same Coin?, in: Albani A, Barjis J, Dietz J (Hrsg): Advances in Enterprise Engineering III: 5th International Workshop, CIAO! 2009, and 5th International Workshop, EOMAS 2009, held at CAiSE 2009, Amsterdam, Springer LNBIP 34, S 1-15 Wissenschaftliche Kommission W (2007) Rahmenempfehlung für die Universitätsausbildung in Wirtschaftsinformatik. Wirtschaftsinformatik 49(4):318-325 Wistrand K, Karlsson F (2004) Method Components – Rationale Revealed. In: Persson A, Stirna J (Hrsg) CAiSE 2004, Springer, Berlin, Heidelberg, S 189-201 Wöhe G (2002) Einführung in die Allgemeine Betriebswirtschaftslehre. 21. Aufl Vahlen, München Wortmann F (2006) Entwicklung einer Methode für die unternehmensweite Autorisierung. Dissertation, Institut für Wirtschaftsinformatik Universität St. Gallen, Yourdon E (1989) Modern Structured Analysis. Prentice-Hall, Englewood Cliffs Zott C, Amit R (2003) Successful entrepreneurs design innovative business models. European Business Forum(15):16-17 Žvanut B, Bajec M (2007) The Adoption of Method Engineering Principles for the Creation of Organization Specific IT Processes. In: Ralyté J, Brinkkemper S, HendersonSellers B (Hrsg) Poster Proceedings of the IFIP WG8.1 Working Conference on Situational Method Engineering – Fundamentals and Experiences (ME'07), Technical Report Department of Computer Science UU-CS-2007-026, Department of Information and Computing Sciences, University of Utrecht, Utrecht, S 34-46

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen >>Business-to-IT

Positionierung von Business-to-Business-Marken: Konzeption und empirische Analyse zur Rolle von Rationalität und Emotionalität

Gestaltung von Anreizsystemen und Unternehmensethik: Eine norm- und wertbezogene Analyse der normativen Principal-Agent-Theorie

Wissensorientierte Gestaltung von Wertschöpfungsnetzwerken

Navigator

Navigator

Navigator

Navigator

Produktions- und Logistikmanagement: Planung und Gestaltung von Wertschopfungsprozessen (Lehrbuch)

Prozesskostenorientierte Gestaltung von Wertschöpfungsketten German

Navigator

Navigator

Navigator

Navigator

The Navigator

Wasserbau: Grundlagen, Gestaltung von wasserbaulichen Bauwerken und Anlagen, 7. Auflage

Naturnaher Wasserbau: Entwicklung und Gestaltung von Fließgewässern, 3. Auflage

Massenpsychologie und Ich-Analyse

Churhill's Navigator

Gestaltung von Vertriebsstrukturen im Auslandsmarkt German

Elektronische Beschaffung: Stand und Entwicklungstendenzen (Business Engineering)

Steuerlich optimale Gestaltung von grenzüberschreitenden Umstrukturierungen

Churhill's Navigator

Navigator Quistus

Risikoverhalten von Fondsmanagern: Eine spieltheoretische und empirische Analyse

Die Besteuerung von Familienstiftungen nach dem Außensteuergesetz: Analyse und Perspektiven

Kampfzone Geschlechterwissen: Kritische Analyse populärwissenschaftlicher Konzepte von Männlichkeit und Weiblichkeit

Entwicklung und Abwicklung von Bauprojekten im Bestand: Analyse - Planung - Ausführung

Intrusion Detection effektiv!: Modellierung und Analyse von Angriffsmustern

Erfolgsfaktoren von Banken im Firmenkundengeschaft. Empirische Analyse und konzeptionelle Anwendung

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen &gt;&gt;Business-to-IT

Positionierung von Business-to-Business-Marken: Konzeption und empirische Analyse zur Rolle von Rationalität und Emotionalität

Gestaltung von Anreizsystemen und Unternehmensethik: Eine norm- und wertbezogene Analyse der normativen Principal-Agent-Theorie

Wissensorientierte Gestaltung von Wertschöpfungsnetzwerken

Navigator

Navigator

Navigator

Navigator

Produktions- und Logistikmanagement: Planung und Gestaltung von Wertschopfungsprozessen (Lehrbuch)

Prozesskostenorientierte Gestaltung von Wertschöpfungsketten German

Navigator

Navigator

Navigator

Navigator

The Navigator

Wasserbau: Grundlagen, Gestaltung von wasserbaulichen Bauwerken und Anlagen, 7. Auflage

Naturnaher Wasserbau: Entwicklung und Gestaltung von Fließgewässern, 3. Auflage

Massenpsychologie und Ich-Analyse

Churhill's Navigator

Gestaltung von Vertriebsstrukturen im Auslandsmarkt German

Elektronische Beschaffung: Stand und Entwicklungstendenzen (Business Engineering)

Steuerlich optimale Gestaltung von grenzüberschreitenden Umstrukturierungen

Churhill's Navigator

Navigator Quistus

Risikoverhalten von Fondsmanagern: Eine spieltheoretische und empirische Analyse

Die Besteuerung von Familienstiftungen nach dem Außensteuergesetz: Analyse und Perspektiven

Kampfzone Geschlechterwissen: Kritische Analyse populärwissenschaftlicher Konzepte von Männlichkeit und Weiblichkeit

Entwicklung und Abwicklung von Bauprojekten im Bestand: Analyse - Planung - Ausführung

Intrusion Detection effektiv!: Modellierung und Analyse von Angriffsmustern

Erfolgsfaktoren von Banken im Firmenkundengeschaft. Empirische Analyse und konzeptionelle Anwendung

Recommend Documents

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen >>Business-to-IT